amr driver changes in FreeBSD 7.1-RELEASE

Steve Polyack korvus at comcast.net
Fri Jan 16 09:51:58 PST 2009


In case anyone is interested, the situation has only gotten weirder.  
Booting 7.1-R with 'boot -v' mysteriously adds:
(probe32:amr1:1:6:0): error 22
(probe32:amr1:1:6:0): Unretryable Error

However, amr1 is not the one that is giving us issues.  It appears to 
work fine.  amr0 is the one on which 7.1-R fails to find any volumes.  
Even stranger, a 'camcontrol devlist' manages to display all off the 
individual SCSI drives attached to amr0.

Finally, this problem was solved whilst writing this e-mail.  The 
default for kern.cam.scsi_delay (5000ms) appears to be too aggressive in 
my circumstances.  Increasing it to 15000 solves my issue (and gets rid 
of "amr0: adapter is busy" messages).

Steve Polyack wrote:
> Hello,
>
> We have a Dell PowerEdge 1850 server.  It contains two PERC4 RAID 
> controllers.  One is a PERC4e/Si, and the other is a PERC4/DC.  Right 
> now we are running FreeBSD 6.3-RELEASE, with a 36GB RAID-1 on the 
> PERC4e/Si (amr0), and both a 1TB RAID5 and a 136GB RAID1 on the 
> PERC4/DC(amr1). Both adapters are running the latest firmware revision.
>
> When we boot FreeBSD7.1 install media, the amr driver fails to detect 
> any volumes (disks) attached to amr0, the PERC4e/Si.  However, it 
> picks up the attached disks on the PERC4/DC just fine.  However, if I 
> boot 7.0-RELEASE install media, it picks up all of the attached 
> volumes, leading me to believe the issue is due to changes in the amr 
> driver between 7.0 and 7.1.  During the 7.1 boot process, before 
> probing disks, we see the message "amr0: adapter is busy" show up 
> twice.  This also does not occur on the 6.3, 6.4, or 7.0 releases.
>
> We also have another PE1850 with a very similar configuration, except 
> the two PERCs get probed in a different order, and it detects all of 
> the attached volumes without any issues.
>
> Any suggestions? These are semi-critical systems, so we aren't always 
> able to test things like this.  But, we can schedule downtime once or 
> twice a week if necessary.
>
> -Steve Polyack
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>



More information about the freebsd-stable mailing list