Bug 4929
Summary: | problem with aic7xxx driver on 2.6.x | ||
---|---|---|---|
Product: | SCSI Drivers | Reporter: | Igor Duda (duda) |
Component: | Other | Assignee: | Mike Anderson (andmike) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | akpm, bunk, duda, hare, jejb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.12.3 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Igor Duda
2005-07-22 13:43:15 UTC
Well there's been a bit of activity with that driver recently. Could you please test 2.6.13-rc4 and if that also fails, test 2.6.13-rc3-mm3? Thanks. Let's see if this email thingy works. James Bottomley <James.Bottomley@SteelEye.com> wrote: > > On Sat, 2005-07-23 at 19:51 +0100, Christoph Hellwig wrote: > > This message is totally useless. If you want to forward bugzilla reports > > please include all relevant information. > > OK, let me try. > > The format I'd like is for the text of the bug report to go over the > list with a cc to the bugzilla so that it captures any email > conversation about it. Martin has already set this up, I just can't > figure out what the bugzilla email address is for this report. > > Anyway, this is what looks to be the issue in the trace > > > target2:0:1: Ending Domain Validation > > SCSI device sdc: 2788016128 512-byte hdwr sectors (1427464 MB) > > (scsi2:A:1:0): Handled Residual of 4 bytes > > SCSI device sdc: drive cache: write back > > SCSI device sdc: 2788016128 512-byte hdwr sectors (1427464 MB) > > (scsi2:A:1:0): Handled Residual of 4 bytes > > SCSI device sdc: drive cache: write back > > sdc: sdc1 sdc2 sdc3 sdc4 > > Attached scsi disk sdc at scsi2, channel 0, id 1, lun 0 > > (scsi2:A:1:0): Handled Residual of 3960 bytes > > scsi: host 2 channel 0 id 1 lun 0x00000200080c0400 has a LUN larger than > > currently supported. > > scsi: host 2 channel 0 id 1 lun 0xff010000ffffffff has a LUN larger than > > currently supported. > > scsi: host 2 channel 0 id 1 lun 0x0002202020202020 has a LUN larger than > > currently supported. > > scsi: host 2 channel 0 id 1 lun808529923 has a LUN larger than allowed by the > > host adapter > > (scsi2:A:1:4): Handled Residual of 4 bytes > > (scsi2:A:1:5): Handled Residual of 4 bytes > > scsi: host 2 channel 0 id 1 lun3078 has a LUN larger than allowed by the host > > adapter > > So I think it's not an aic7xxx error (it seems the new DV actually works > whereas the old DV failed). It seems to be a bug in REPORT LUNS. > Either in the device or in the kernel code. > > The curious thing is why after the report luns failure, we apparently > jump to sequential LUN scanning, but choose to begin at LUN 4. > > I think as a work around, a simple > > echo scsi add-single-device 2 0 1 1 > /proc/scsi/scsi > > should bring the missing LUN back again > > James >Could you please test 2.6.13-rc4 and >if that also fails, test 2.6.13-rc3-mm3? yes , I found that these problems persist with this patches. > I think as a work around, a simple > echo scsi add-single-device 2 0 1 1 > /proc/scsi/scsi > should bring the missing LUN back again Certainly it works. But it would be desirable to resolve the problem with incorrect scanning LUN at loading the driver. If you need additional information about driver loading process , please email me with any questions. Reply-To: James.Bottomley@HansenPartnership.com > ------- Additional Comments From duda@matrix.odessa.ua 2005-07-29 09:50 ------- > >Could you please test 2.6.13-rc4 and > >if that also fails, test 2.6.13-rc3-mm3? > yes , I found that these problems persist with this patches. > > > > I think as a work around, a simple > > echo scsi add-single-device 2 0 1 1 > /proc/scsi/scsi > > should bring the missing LUN back again > > Certainly it works. > But it would be desirable to resolve the problem with incorrect scanning LUN at > loading the driver. > > If you need additional information about driver loading process , please email > me with any questions. Well, it can simply be fixed by blacklisting this array for the REPORT LUNS command. However, it would be nice to know what the reason for the problem is. The array claims to support REPORT LUNS but then apparently returns rubbish when the command is sent. The only people who would know definitively what's going on is the manufacturer, can someone get hold of them and ask? Thanks, James How come 2.4.x works OK? It alse seems to use REPORT_LUNS? Reply-To: James.Bottomley@SteelEye.com On Wed, 2005-09-14 at 23:48 -0700, bugme-daemon@kernel-bugs.osdl.org wrote: > How come 2.4.x works OK? It alse seems to use REPORT_LUNS? Actually I wasn't aware that someone had backported REPORT_LUNs to 2.4 ... it certainly didn't use to have this. James Yup, it's there in 2.4.31 and Igor says 2.4.31 runs OK. Reply-To: James.Bottomley@HansenPartnership.com > Yup, it's there in 2.4.31 and Igor says 2.4.31 runs > OK. Erm, which vendor kernel is this? REPORT LUN scanning definitely isn't in Marcelo's vanilla 2.4 tree. I'd be curious to know how whoever this is managed to massage the bogus report luns information to make sense. James James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > Yup, it's there in 2.4.31 and Igor says 2.4.31 runs > > OK. > > Erm, which vendor kernel is this? REPORT LUN scanning definitely isn't > in Marcelo's vanilla 2.4 tree. I'd be curious to know how whoever this > is managed to massage the bogus report luns information to make sense. > Maybe I'm wrong - I merely grepped the 2.4.31 tree for report_luns. Is this problem still present in kernel 2.6.19? Please reopen this bug if it's still present with kernel 2.6.20. |