Re: Scan past lun 7 in 2.4.0

2001-02-08 Thread Ishikawa
Douglas Gilbert wrote: The attached patch builds on top of the one Eric posted a few days ago for lk 2.4.1 . As well as Eric's changes this patch: - puts the above lun check in: mid-level, sd, st, osst, sg, sr (sr_ioctl + sr_vendor) - implements the lun 0 scsi_level inheritance discussed

Re: scsi_unjam_host and scsi_try to abort_command

2001-02-08 Thread Eric Youngdale
The behavior you are seeing is by design. Essentially the problem is that when the mid-level keeps timers and aborts a pending abort, the host adapter itself can become quite confused. This is essentially what was happening with the old error handling code, and it resulted in a sort of

Re: Scan past lun 7 in 2.4.0

2001-02-08 Thread Douglas Gilbert
Douglas Gilbert wrote: Just to catalog other scsi patches floating around for lk 2.4 there is: - scsi reservations + reset [James Bottomley] James mentioned there might be a patch problem with reservations; has this been sorted? - scsi device detection message correction (was in

Re: Scan past lun 7 in 2.4.0

2001-02-08 Thread James Bottomley
[EMAIL PROTECTED] said: James mentioned there might be a patch problem with reservations; has this been sorted? I believe so. A problem still shows up on an IA-64 system with an AHA2944UW SCSI card but cannot be duplicated on an x86 system with the same configuration. All of the tests on

Re: Scan past lun 7 in 2.4.0

2001-02-08 Thread Ishikawa
Ishikawa wrote: It seems that there is no problem with this configuration: All the luns were recognized. No visible error/warning message in dmesg or syslog files. (Except that there is a slight problem. I have been using devfs for about a week.. Is it possible that