at least for me :-) [and sorry for the cross posting] old (March 12 , i know need the svn rev number but...) dmesg | grep amr amr0: <LSILogic MegaRAID 1.53> mem 0xfbef0000-0xfbefffff,0xfe580000-0xfe5fffff irq 27 at device 0.0 on pci4 amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: <LSILogic Intel(R) RAID Controller SRCU42X> Firmware 414I, BIOS A100, 128MB RAM amr0: delete logical drives supported by controller amrd0: <LSILogic MegaRAID logical drive> on amr0 amrd0: 34857MB (71387136 sectors) RAID 0 (optimal) amrd1: <LSILogic MegaRAID logical drive> on amr0 amrd1: 280024MB (573489152 sectors) RAID 5 (optimal) and a resent 7.2 (same host): amr0: <LSILogic MegaRAID 1.53> mem 0xfbef0000-0xfbefffff,0xfe580000-0xfe5fffff irq 27 at device 0.0 on pci4 amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: <LSILogic Intel(R) RAID Controller SRCU42X> Firmware 414I, BIOS A100, 128MB RAM amr0: adapter is busy amr0: adapter is busy amr0: delete logical drives supported by controller (probe0:amr0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:amr0:0:6:0): CAM Status: SCSI Status Error (probe0:amr0:0:6:0): SCSI Status: Check Condition (probe0:amr0:0:6:0): ILLEGAL REQUEST asc:24,0 (probe0:amr0:0:6:0): Invalid field in CDB (probe0:amr0:0:6:0): Unretryable error btw, since I also have similar problems with another kind of raid card (iir), I suspect some related changes are the cause. danny
Danny Braniss wrote:> at least for me :-) > [and sorry for the cross posting] > > old (March 12 , i know need the svn rev number but...)None of the commit activity on March 12 is jumping out at me as being suspicious. However, you are now the second person who has told me about AMR problems in 7.1 recently. If you have a precise svn change number, it would help greatly. Scott
Danny Braniss danny at cs.huji.ac.il writes:> at least for me :-) > [and sorry for the cross posting] >[...]> > amr0: <LSILogic MegaRAID 1.53> mem 0xfbef0000-0xfbefffff,0xfe580000-0xfe5fffff > irq 27 at device 0.0 on pci4 > amr0: [ITHREAD] > amr0: delete logical drives supported by controller > amr0: <LSILogic Intel(R) RAID Controller SRCU42X> Firmware 414I, BIOS A100, > 128MB RAM > amr0: adapter is busy > amr0: adapter is busy > amr0: delete logical drives supported by controller > (probe0:amr0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:amr0:0:6:0): CAM Status: SCSI Status Error > (probe0:amr0:0:6:0): SCSI Status: Check Condition > (probe0:amr0:0:6:0): ILLEGAL REQUEST asc:24,0 > (probe0:amr0:0:6:0): Invalid field in CDB > (probe0:amr0:0:6:0): Unretryable errorFWIW, I have a an amr device (Dell PERC 3/DC) which is working fine with a -STABLE dated after March 12th: FreeBSD 7.2-PRERELEASE #2: Thu Mar 26 09:41:58 EDT 2009 terry@test4.tmk.com:/usr/obj/usr/src/sys/PE1550 [snip] amr0: <LSILogic MegaRAID 1.53> mem 0xf0000000-0xf7ffffff irq 25 at device 0.0 on pci3 amr0: [ITHREAD] amr0: delete logical drives supported by controller amr0: <LSILogic PERC 3/DC> Firmware 199D, BIOS 3.35, 128MB RAM amr0: delete logical drives supported by controller amrd0: <LSILogic MegaRAID logical drive> on amr0 amrd0: 69360MB (142049280 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: <DELL 1x3 U2W SCSI BP 1.21> Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device Trying to mount root from ufs:/dev/amrd0s1a This is on a dual-processor Dell PowerEdge 1550. So this may only affect certain models or firmware revisions of amr devices. Of course, since each LSI OEM uses their own firmware and BIOS numbering scheme, it'll be hard to tell which one is newer than the other. I have a bazillion of these cards if one would be helpful to a de- veloper. Terry Kennedy http://www.tmk.com terry@tmk.com New York, NY USA
> Danny Braniss wrote: > > it seems March 12 was a bit off :-) > > it took some time, but I managed to close the gap: > > 189100 ok > > 189150 fails > > I will continue tomorrow, but this should be helpful. > > > > > > 189150 is in the middle of a big string of related commits. Try > updating to the following change numbers and retesting: > > 189088 > 189107 > 189161 > > If the last one does not work, try editing /sys/dev/amr/amr.c to change > > #define AMR_ENABLE_CAM 1 > > to > > #define AMR_ENABLE_CAM 0 > > Scott189161 works, also for the iir now what? danny
Danny Braniss wrote:>> Danny Braniss wrote: >>> it seems March 12 was a bit off :-) >>> it took some time, but I managed to close the gap: >>> 189100 ok >>> 189150 fails >>> I will continue tomorrow, but this should be helpful. >>> >>> >> 189150 is in the middle of a big string of related commits. Try >> updating to the following change numbers and retesting: >> >> 189088 >> 189107 >> 189161 >> >> If the last one does not work, try editing /sys/dev/amr/amr.c to change >> >> #define AMR_ENABLE_CAM 1 >> >> to >> >> #define AMR_ENABLE_CAM 0 >> >> Scott > > 189161 works, also for the iir > now what? >Next set to try: 189219 189229 189253 189402 189531 189569 189591 Scott
> Danny Braniss wrote: > >> Danny Braniss wrote: > >>> it seems March 12 was a bit off :-) > >>> it took some time, but I managed to close the gap: > >>> 189100 ok > >>> 189150 fails > >>> I will continue tomorrow, but this should be helpful. > >>> > >>> > >> 189150 is in the middle of a big string of related commits. Try > >> updating to the following change numbers and retesting: > >> > >> 189088 > >> 189107 > >> 189161 > >> > >> If the last one does not work, try editing /sys/dev/amr/amr.c to change > >> > >> #define AMR_ENABLE_CAM 1 > >> > >> to > >> > >> #define AMR_ENABLE_CAM 0 > >> > >> Scott > > > > 189161 works, also for the iir > > now what? > > > > Next set to try: > > 189219broken> 189229broken any point in going on? danny> 189253 > 189402 > 189531 > 189569 > 189591 > > Scott