Bug 5808

On Sun, 2006-01-01 at 16:41 -0800, bugme-daemon@bugzilla.kernel.org
wrote:
> Most recent kernel where this bug did not occur: 2.6.12.6
> Distribution: Debian 3.1r1 - Sarge

Do you have the dmesg showing the domain validation commands for these, please?

And also could you tell me what's in

/sys/spi_transport/target<...>/min_period

Thanks,

James


> Hardware Environment: Dell PowerEdge 4200/300
> 
> Software Environment:
> ver_linux:
> Linux GW 2.6.13 #1 SMP Sun Jan 1 21:13:01 CET 2006 i686 GNU/Linux
> 
> Gnu C                  3.3.5
> Gnu make               3.80
> binutils               2.15
> util-linux             2.12p
> mount                  2.12p
> module-init-tools      3.2-pre1
> e2fsprogs              1.37
> jfsutils               1.1.7
> xfsprogs               2.6.20
> Linux C Library        2.3.2
> Dynamic linker (ldd)   2.3.2
> Procps                 3.2.1
> Net-tools              1.60
> Console-tools          0.2.3
> Sh-utils               5.2.1
> Modules Loaded
> 
> 
> proc/cpuinfo:
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 3
> model name      : Pentium II (Klamath)
> stepping        : 4
> cpu MHz         : 299.170
> cache size      : 512 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov mmx
> bogomips        : 599.32
> 
> processor       : 1
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 3
> model name      : Pentium II (Klamath)
> stepping        : 3
> cpu MHz         : 299.170
> cache size      : 512 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov mmx
> bogomips        : 598.36
> 
> 
> /proc/modules:
> 
> 
> /proc/ioports:
> 0000-001f : dma1
> 0020-0021 : pic1
> 0040-0043 : timer0
> 0050-0053 : timer1
> 0060-006f : keyboard
> 0070-0077 : rtc
> 0080-008f : dma page reg
> 00a0-00a1 : pic2
> 00c0-00df : dma2
> 00f0-00ff : fpu
> 0330-0333 : i2c-pca-isa
> 03c0-03df : vga+
> 0400-0407 : pnp 00:0f
> 040a-040c : pnp 00:0f
> 0410-043f : pnp 00:0f
> 0461-0462 : pnp 00:0f
> 0464-0465 : pnp 00:0f
> 0481-048b : pnp 00:0f
> 04c6-04c6 : pnp 00:0f
> 0c80-0c83 : Dell System PowerEdge 4200
> 0cf8-0cff : PCI conf1
> e000-efff : PCI Bus #01
>   e000-e0ff : 0000:01:0d.0
>     e000-e0ff : 8139too
>   e400-e4ff : 0000:01:0b.0
>   e800-e8ff : 0000:01:0a.0
> f4a0-f4bf : 0000:00:13.0
>   f4a0-f4bf : ne2k-pci
> f800-f8ff : 0000:00:14.0
> 
> 
> /proc/iomem:
> 00000000-0009fbff : System RAM
> 0009fc00-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000c8000-000cc7ff : Adapter ROM
> 000f0000-000fffff : System ROM
> 00100000-0fffffff : System RAM
>   00100000-0049816c : Kernel code
>   0049816d-005b31c7 : Kernel data
> 10000000-100fffff : PCI Bus #01
>   10000000-1000ffff : 0000:01:0a.0
> 10100000-1010ffff : 0000:00:14.0
> 10110000-10113fff : 0000:00:13.0
> fc000000-fcffffff : 0000:00:14.0
> fde00000-fdffffff : PCI Bus #01
>   fdefe000-fdefefff : 0000:01:0a.0
>     fdefe000-fdefefff : aic7xxx
>   fdffe000-fdffefff : 0000:01:0b.0
>     fdffe000-fdffefff : aic7xxx
>   fdfff800-fdfff8ff : 0000:01:0d.0
>     fdfff800-fdfff8ff : 8139too
> fec00000-fec00fff : reserved
> fee00000-fee00fff : reserved
> fff80000-ffffffff : reserved
> 
> 
> lspci -vvv:
> 0000:00:00.0 Host bridge: Intel Corp. 440FX - 82441FX PMC [Natoma] (rev 02)
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR+ FastB2B-
>         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort+ >SERR- <PERR-
>         Latency: 32
> 
> 0000:00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 02) 
> (prog-if 00 [Normal decode])
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR+ FastB2B-
>         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 255, Cache Line Size: 0x08 (32 bytes)
>         Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
>         I/O behind bridge: 0000e000-0000efff
>         Memory behind bridge: fde00000-fdffffff
>         Prefetchable memory behind bridge: 0000000010000000-0000000010000000
>         BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
> 
> 0000:00:0f.0 Non-VGA unclassified device: Intel Corp. 82375EB/SB PCI to EISA 
> Bridge (rev 15)
>         Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B-
>         Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 248
> 
> 0000:00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
>         Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B-
>         Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>         Interrupt: pin A routed to IRQ 10
>         Region 0: I/O ports at f4a0 [size=32]
>         Expansion ROM at 10110000 [disabled] [size=16K]
> 
> 0000:00:14.0 VGA compatible controller: ATI Technologies Inc 264VT [Mach64 VT] 
> (rev 40) (prog-if 00 [VGA])
>         Subsystem: ATI Technologies Inc Mach64VT Reference
>         Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop+ ParErr- 
> Stepping+ SERR- FastB2B-
>         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>         Region 0: Memory at fc000000 (32-bit, prefetchable) [size=16M]
>         Region 1: I/O ports at f800 [size=256]
>         Expansion ROM at 10100000 [disabled] [size=64K]
> 
> 0000:01:0a.0 SCSI storage controller: Adaptec AIC-7880U
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
> Stepping- SERR+ FastB2B-
>         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 64 (2000ns min, 2000ns max), Cache Line Size: 0x08 (32 bytes)
>         Interrupt: pin A routed to IRQ 15
>         Region 0: I/O ports at e800 [disabled] [size=256]
>         Region 1: Memory at fdefe000 (32-bit, non-prefetchable) [size=4K]
>         Expansion ROM at 10000000 [disabled] [size=64K]
> 
> 0000:01:0b.0 SCSI storage controller: Adaptec AIC-7860 (rev 01)
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
> Stepping- SERR+ FastB2B-
>         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 64 (1000ns min, 1000ns max), Cache Line Size: 0x08 (32 bytes)
>         Interrupt: pin A routed to IRQ 15
>         Region 0: I/O ports at e400 [disabled] [size=256]
>         Region 1: Memory at fdffe000 (32-bit, non-prefetchable) [size=4K]
> 
> 0000:01:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-
> 8139/8139C/8139C+ (rev 10)
>         Subsystem: Realtek Semiconductor Co., Ltd. RT8139
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR+ FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 64 (8000ns min, 16000ns max)
>         Interrupt: pin A routed to IRQ 9
>         Region 0: I/O ports at e000 [size=256]
>         Region 1: Memory at fdfff800 (32-bit, non-prefetchable) [size=256]
>         Capabilities: [50] Power Management version 2
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-
> ,D1+,D2+,D3hot+,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 
> /proc/scsi/scsi:
> Attached devices:
> Host: scsi0 Channel: 00 Id: 00 Lun: 00
>   Vendor: SEAGATE  Model: ST34573LC        Rev: 5702
>   Type:   Direct-Access                    ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
>   Vendor: SEAGATE  Model: ST19171W         Rev: 2219
>   Type:   Direct-Access                    ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 02 Lun: 00
>   Vendor: SEAGATE  Model: ST19171W         Rev: 2219
>   Type:   Direct-Access                    ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 03 Lun: 00
>   Vendor: SEAGATE  Model: ST19171W         Rev: 2224
>   Type:   Direct-Access                    ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 04 Lun: 00
>   Vendor: SEAGATE  Model: ST39173LC        Rev: 5702
>   Type:   Direct-Access                    ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 05 Lun: 00
>   Vendor: SEAGATE  Model: ST19171W         Rev: 2224
>   Type:   Direct-Access                    ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 06 Lun: 00
>   Vendor: DELL     Model: 6UW BACKPLANE    Rev: 7
>   Type:   Processor                        ANSI SCSI revision: 02
> Host: scsi1 Channel: 00 Id: 05 Lun: 00
>   Vendor: NEC      Model: CD-ROM DRIVE:464 Rev: 1.05
>   Type:   CD-ROM
> 
> 
> /proc/scsi/aic7xxx/0:
> Adaptec AIC7xxx driver version: 6.2.36
> Adaptec aic7880 Ultra SCSI adapter
> aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
> Allocated SCBs: 36, SG List Length: 128
> 
> Serial EEPROM:
> 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338
> 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338
> 0x18b6 0x005e 0x2807 0x0010 0xff00 0xffff 0xffff 0xffff
> 0xffff 0xffff 0xffff 0xffff 0xffff 0xffff 0x00ff 0x74a1
> 
> Target 0 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Curr: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Channel A Target 0 Lun 0 Settings
>                 Commands Queued 1283
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 1 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Curr: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Channel A Target 1 Lun 0 Settings
>                 Commands Queued 46
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 2 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Curr: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Channel A Target 2 Lun 0 Settings
>                 Commands Queued 37
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 3 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Curr: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Channel A Target 3 Lun 0 Settings
>                 Commands Queued 36
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 4 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Curr: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Channel A Target 4 Lun 0 Settings
>                 Commands Queued 36
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 5 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Curr: 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
>         Channel A Target 5 Lun 0 Settings
>                 Commands Queued 45
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 6 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 3.300MB/s transfers
>         Curr: 3.300MB/s transfers
>         Channel A Target 6 Lun 0 Settings
>                 Commands Queued 6
>                 Commands Active 0
>                 Command Openings 1
>                 Max Tagged Openings 0
>                 Device Queue Frozen Count 0
> Target 7 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 8 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 9 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 10 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 11 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 12 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 13 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 14 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 15 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> 
> 
> /proc/scsi/aic7xxx/1:
> Adaptec AIC7xxx driver version: 6.2.36
> Adaptec aic7860 Ultra SCSI adapter
> aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs
> Allocated SCBs: 4, SG List Length: 128
> 
> Serial EEPROM:
> 0x0318 0x0318 0x0318 0x0318 0x0318 0x0318 0x0318 0x0318
> 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338
> 0x18b5 0x005e 0x2807 0x5008 0xff00 0xffff 0xffff 0xffff
> 0xffff 0xffff 0xffff 0xffff 0xffff 0xffff 0x00ff 0xc398
> 
> Target 0 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 1 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 2 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 3 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 4 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 5 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
>         Goal: 10.000MB/s transfers (10.000MHz, offset 15)
>         Curr: 10.000MB/s transfers (10.000MHz, offset 15)
>         Channel A Target 5 Lun 0 Settings
>                 Commands Queued 16
>                 Commands Active 0
>                 Command Openings 1
>                 Max Tagged Openings 0
>                 Device Queue Frozen Count 0
> Target 6 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 7 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> 
> 
> /proc/scsi/aic7xxx/0 - from kernel 2.6.12.6:
> 
> Adaptec AIC7xxx driver version: 6.2.36
> Adaptec aic7880 Ultra SCSI adapter
> aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
> Allocated SCBs: 8, SG List Length: 128
> 
> Serial EEPROM:
> 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338
> 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338
> 0x18b6 0x005e 0x2807 0x0010 0xff00 0xffff 0xffff 0xffff
> 0xffff 0xffff 0xffff 0xffff 0xffff 0xffff 0x00ff 0x74a1
> 
> Target 0 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Channel A Target 0 Lun 0 Settings
>                 Commands Queued 1459
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 1 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Channel A Target 1 Lun 0 Settings
>                 Commands Queued 48
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 2 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Channel A Target 2 Lun 0 Settings
>                 Commands Queued 38
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 3 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Channel A Target 3 Lun 0 Settings
>                 Commands Queued 37
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 4 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Channel A Target 4 Lun 0 Settings
>                 Commands Queued 37
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 5 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
>         Channel A Target 5 Lun 0 Settings
>                 Commands Queued 47
>                 Commands Active 0
>                 Command Openings 32
>                 Max Tagged Openings 32
>                 Device Queue Frozen Count 0
> Target 6 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
>         Goal: 3.300MB/s transfers
>         Curr: 3.300MB/s transfers
>         Channel A Target 6 Lun 0 Settings
>                 Commands Queued 6
>                 Commands Active 0
>                 Command Openings 1
>                 Max Tagged Openings 0
>                 Device Queue Frozen Count 0
> Target 7 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 8 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 9 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 10 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 11 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 12 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 13 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 14 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> Target 15 Negotiation Settings
>         User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit)
> 
> 
> /proc/scsi/aic7xxx/1 - from kernel 2.6.12.6:
> Adaptec AIC7xxx driver version: 6.2.36
> Adaptec aic7860 Ultra SCSI adapter
> aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs
> Allocated SCBs: 4, SG List Length: 128
> 
> Serial EEPROM:
> 0x0318 0x0318 0x0318 0x0318 0x0318 0x0318 0x0318 0x0318
> 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338 0x0338
> 0x18b5 0x005e 0x2807 0x5008 0xff00 0xffff 0xffff 0xffff
> 0xffff 0xffff 0xffff 0xffff 0xffff 0xffff 0x00ff 0xc398
> 
> Target 0 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 1 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 2 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 3 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 4 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 5 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
>         Goal: 20.000MB/s transfers (20.000MHz, offset 15)
>         Curr: 20.000MB/s transfers (20.000MHz, offset 15)
>         Channel A Target 5 Lun 0 Settings
>                 Commands Queued 16
>                 Commands Active 0
>                 Command Openings 1
>                 Max Tagged Openings 0
>                 Device Queue Frozen Count 0
> Target 6 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> Target 7 Negotiation Settings
>         User: 20.000MB/s transfers (20.000MHz, offset 127)
> 
> Problem Description:
> If use kernel 2.6.13 or newer, all SCSI discs/cdrom work only on half 
> speed/frequency.
> 
> Steps to reproduce:
> Only boot... cat /proc/scsi/aic7xxx/0

Reply-To: James.Bottomley@SteelEye.com

Could you keep the cc: list when replying, otherwise we lose the
tracking information in the bug database and on the list.

Could you try this again with 2.6.15, and then I can try giving you some
sysfs settings to prod to see if the driver can be forced up to 50ns.

Thanks,

James


On Tue, 2006-01-03 at 01:30 +0100, Miroslav Zaj

Reply-To: Zajsoft@Zajsoft.NET

  Hi,
in 2.6.15 is same problem :o(

The please try say me some sysfs settings.

Thanks,
  Zajsoft

bugme-daemon@bugzilla.kernel.org napsal(a):

>http://bugzilla.kernel.org/show_bug.cgi?id=5808
>
>
>
>
>
>------- Additional Comments From anonymous@kernel-bugs.osdl.org  2006-01-04 09:47 -------
>Reply-To: James.Bottomley@SteelEye.com
>
>Could you keep the cc: list when replying, otherwise we lose the
>tracking information in the bug database and on the list.
>
>Could you try this again with 2.6.15, and then I can try giving you some
>sysfs settings to prod to see if the driver can be forced up to 50ns.
>
>Thanks,
>
>James
>
>
>On Tue, 2006-01-03 at 01:30 +0100, Miroslav Zaj

Reply-To: James.Bottomley@SteelEye.com

On Thu, 2006-01-05 at 15:36 +0100, Miroslav Zaj

Reply-To: Zajsoft@Zajsoft.NET

James Bottomley napsal(a):

>On Thu, 2006-01-05 at 15:36 +0100, Miroslav Zaj

Reply-To: James.Bottomley@SteelEye.com

On Fri, 2006-01-06 at 20:45 +0100, Miroslav Zaj

I have the same problem since kernel 2.6.13 on a "Fedora" system but verified it
by means of a "Ubuntu" live CD. Only "FAST-10" mode is negociated for a Quantum
Atlas 10k3 disk connected to the on-board AIC-7880 UW-SCSI chip of my PR440FX
mainboard. For 2.6.12 kernels and earlier, the nominal transfer mode was 40
MB/s. See the attached "dmesg" output for the "Ubuntu" (2.6.15-15-386) kernel. I
had posted the original bug back in October 2005 at:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171282

PS: Please do not reply to a post and include the old message(s). This bug
record is already really too big, thanks!

Created attachment 7475 [details]
"Ubuntu" log file dmesg-(2.6.15-15-386) for AIC-7880 and Quantum Atlas 10k3

I tried:

  $ echo 50 > /sys/class/spi_transport/target0:0:0/period
  $ fdisk /dev/sda 
  $ cat /sys/class/spi_transport/target0:0:0/period

on my PR440FX box. No improvement. The value of "period" still equals 100. This
issue is due to a regression of 2.6.13 and later. Why would one need to "force"
50ns, when the controller is an U-SCSI one for which 20 MHz (50ns) should be the
default value?

This extremely annoying bug is still present in 2.6.17rc2-git3.

Still only half speed for 2.6.17rc3-git12.

Still present in 2.6.17rc6.

Kernel version 2.6.18rc4 still negotiates "FAST-10" whereas it should be
"FAST-20" for my on-board "AIC-7880" controller connected to a "QUANTUM Atlas
10k3" disk. The system board is an "INTEL PR440FX".

Is this issue still present in kernel 2.6.19?

Yes, it is, at least for "kernel-2.6.19-1.2788.fc7.i686". Just before the 
kernel panic which occurs because of "initrd" issues with current "Fedora 
Development", the already known message "FAST-10 ..." is issued.

Still only half speed for 2.6.21.2.

Any updates on this bug?
Thanks.

(In reply to comment #17)
> Any updates on this bug?

No, still only half speed for kernel version 2.6.23-rc0-git16.

Joachim, please have a look at http://bugzilla.kernel.org/show_bug.cgi?id=8366,
see if this is the same (or a related) problem?

In case of bug #8366, it's problem of wrong detection of wide/narrow devices, right? In my case, it's a matter of synchronous vs. asynchronous mode which leads to an effective 50% loss in transfer rate.
However, following some hints borrowed from the other bug report, I tried the following:

  echo 50 > /sys/class/spi_transport/target0:0:0/min_period
  echo 50 > /sys/class/spi_transport/target0:0:0/period
  echo  1 > /sys/class/spi_transport/target0:0:0/revalidate

After issuing these commands, additional lines appear in /var/log/dmesg, namely:

  target0:0:0: Beginning Domain Validation
  target0:0:0: asynchronous
  target0:0:0: wide asynchronous
  target0:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 8)
  target0:0:0: Domain Validation skipping write tests
  target0:0:0: Ending Domain Validation

whereas -before- it would have read:

 target0:0:0: Beginning Domain Validation
 target0:0:0: asynchronous
 target0:0:0: wide asynchronous
 target0:0:0: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
 target0:0:0: Domain Validation skipping write tests
 target0:0:0: Ending Domain Validation

This is interesting, since instead of FAST-10 mode, now FAST-20 mode appears to have been negociated. The strange thing is that even in single user mode, this increases the transfer rate as measured by 'hdparm' from a mere 18 MB/s to about 20 MB/s whereas up to kernel version 2.6.12, I easily achieved 28 MB/s even in multiuser mode.
However, there is this suspicious 'asynchronous' attribute reported by 'dmesg'. Is there a way to force snychronous mode?

Reply-To: James.Bottomley@SteelEye.com

On Sat, 2007-07-28 at 02:50 -0700, bugme-daemon@bugzilla.kernel.org
wrote:
> In case of bug #8366, it's problem of wrong detection of wide/narrow devices,
> right? In my case, it's a matter of synchronous vs. asynchronous mode which
> leads to an effective 50% loss in transfer rate.
> However, following some hints borrowed from the other bug report, I tried the
> following:
> 
>   echo 50 > /sys/class/spi_transport/target0:0:0/min_period
>   echo 50 > /sys/class/spi_transport/target0:0:0/period
>   echo  1 > /sys/class/spi_transport/target0:0:0/revalidate

Could someone (anyone) seeing this bug please provide the information
requested in comment no 6:

---
So you need to do

echo 50 > /sys/class/spi_transport/target0:0:0/period

fdisk /dev/sda 

cat /sys/class/spi_transport/target0:0:0/period

the fdisk will force a partition table read down to the device.
---

with (the values of targetX;X:X and sdX suiting your configuration)

James

(In reply to comment #21)
> So you need to do
> 
> echo 50 > /sys/class/spi_transport/target0:0:0/period
> 
> fdisk /dev/sda 
> 
> cat /sys/class/spi_transport/target0:0:0/period

Are you sure about that? The crucial quantity in my case actually is:

  /sys/class/spi_transport/target0:0:0/min_period

because unless I set this quantity to 50, it's simply impossible to reduce the value in '../target0:0:0/period'. Btw, after writing 1 to '../target0:0:0/revalidate', the value in '../target0:0:0/period' is actually updated, so this seems to be equivalent to 'fdisk /dev/sda'. I hadn't mentioned it explicity, but I am of course able now to set '../target0:0:0/period' to both 50 and 100 which is verified by dumping its content and checking the corresponding entries in '/var/log/dmesg'.

(In reply to comment #21)
The correct procedure is definitely to issue the two following commands:

  echo 50 > /sys/class/spi_transport/target0:0:0/min_period
  echo  1 > /sys/class/spi_transport/target0:0:0/revalidate

The content of 'period' is then automatically updated accordingly as I have verified by writing 50 and 100 alternately to 'min_period' followed by a revalidation. It is -not- necessary to write a new value to 'period' after modifying the content of 'min_period'. The suggestion to modify 'period' only and to issue 'fdisk /dev/sda' thereafter does -not- work because the current value of 'min_period' blocks application of any smaller value to 'period'.
In the meantime, I have verified that switching to 'FAST-20' actually -does- the right thing. By using a 'Ubuntu' live CD where the hard disk is not at all used by the system itself, I obtain a satisfactory transfer rate of 32 MB/s for my U160 hard disk connected to an onboard AIC7880 controller.
The lower values reported in comment #20 where due to using a 'Fedora' -development- kernel [2.6.23-0.49.rc1.git3.fc8] which appears to have many nefarious debug options turned on. After booting the latest 'F7' update kernel [2.6.22.1-33.fc7], the transfer went up from 20 MB/s to about 28 MB/s which is reasonable. The remaining issue is thus to make the kernel negociate the correct mode. Once it is set, operation continues as expected.

Reply-To: James.Bottomley@SteelEye.com

On Mon, 2007-07-30 at 02:33 -0700, bugme-daemon@bugzilla.kernel.org
wrote:
> The correct procedure is definitely to issue the two following
> commands:
> 
>   echo 50 > /sys/class/spi_transport/target0:0:0/min_period
>   echo  1 > /sys/class/spi_transport/target0:0:0/revalidate
> 
> The content of 'period' is then automatically updated accordingly as I
> have
> verified by writing 50 and 100 alternately to 'min_period' followed by
> a
> revalidation. 

The purpose of the test isn't to fix anything it's to get me more
information about the problem.  I theorise it's related to speed bounce
negotiation that some devices do (get shocked by too low a period then
bounce up to the safe 100ns).

However, if your min_period for this device comes up as 100 then your
particular problem is pilot error: you have the device set to 10MHz in
the adaptec bios.  If it comes up as < 50, then the nsvram routines
aren't pulling the right value out.

James

(In reply to comment #24)
> However, if your min_period for this device comes up as 100 then your
> particular problem is pilot error: you have the device set to 10MHz in
> the adaptec bios.  If it comes up as < 50, then the nsvram routines
> aren't pulling the right value out.

The relevant BIOS settings [I haven't found any other] of my onboard AIC-7880 controller currently are:

  - Initiate Sync Negotiation: yes
  - Maximum Sync Transfer Rate: 40.0
  - Support for Ultra SCSI Speed: enabled

Nothing questionable here, and yet, the initial value of 'min_period' is 100 when it should be 50. As a matter of fact, this is what this bug report is all about! Moreover, as I had pointed out in comment #7, the transfer rate got always negociated correctly up to kernel 2.6.12 [2.6.12.6 according to the original reporter], situation that ceased to exist for 2.6.13 and later versions. I can boot a sufficiently old Ubuntu live CD at any time, and it -does- provide the correct transfer rate without tweaking. I checked this many times in the past, the last time several weeks ago.

Reply-To: James.Bottomley@SteelEye.com

> The relevant BIOS settings [I haven't found any other] of my onboard AIC-7880
> controller currently are:
> 
>   - Initiate Sync Negotiation: yes
>   - Maximum Sync Transfer Rate: 40.0
>   - Support for Ultra SCSI Speed: enabled

Those look like controller settings.  There should also be a device
settings page you get into lower down which allows these to be set on a
per device basis.

> Nothing questionable here, and yet, the initial value of 'min_period' is 100
> when it should be 50. As a matter of fact, this is what this bug report is
> all
> about! Moreover, as I had pointed out in comment #7, the transfer rate got
> always negociated correctly up to kernel 2.6.12 [2.6.12.6 according to the
> original reporter], situation that ceased to exist for 2.6.13 and later
> versions. I can boot a sufficiently old Ubuntu live CD at any time, and it
> -does- provide the correct transfer rate without tweaking. I checked this
> many
> times in the past, the last time several weeks ago.

Amazingly enough, I managed to dig out an old 2940UW .. but it
definitely works with the correct bios settings:

scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

scsi 0:0:0:0: Direct-Access     QUANTUM  ATLAS IV 9 WLS   0B0B PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 8
 target0:0:0: Beginning Domain Validation
 target0:0:0: wide asynchronous
 target0:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 8)
 target0:0:0: Domain Validation skipping write tests
 target0:0:0: Ending Domain Validation

It's possible the motherboard bios is broken in your case, in which case
the workaround would be to do the manual echo in the boot sequence.

James

(In reply to comment #26)
> >   - Initiate Sync Negotiation: yes
> >   - Maximum Sync Transfer Rate: 40.0
> >   - Support for Ultra SCSI Speed: enabled
> 
> Those look like controller settings.  There should also be a device
> settings page you get into lower down which allows these to be set on a
> per device basis.

I hadn't mentioned it explicity, but parameters #1 and #2 are of course set on a per-device basis, thus there are 16 different entries for each of them.

> Amazingly enough, I managed to dig out an old 2940UW .. but it definitely
> works with the correct bios settings:
> 
> scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
>         <Adaptec 2940 Ultra SCSI adapter>
>         aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
> 
> scsi 0:0:0:0: Direct-Access     QUANTUM  ATLAS IV 9 WLS   0B0B PQ: 0 ANSI: 3
> scsi0:A:0:0: Tagged Queuing enabled.  Depth 8
>  target0:0:0: Beginning Domain Validation
>  target0:0:0: wide asynchronous
>  target0:0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 8)
>  target0:0:0: Domain Validation skipping write tests
>  target0:0:0: Ending Domain Validation
> 
> It's possible the motherboard bios is broken in your case, in which case
> the workaround would be to do the manual echo in the boot sequence.
> 
> James

The board is an INTEL PR440FX with the latest BIOS including Adaptec SCSI BIOS version 1.25 of the onboard AIC-7880 controller compared to versions 1.34.3 and 2.20 of the 1.x and 2.x BIOS series respectively [albeit a priori available for the retail AHA-2940UW controller only].

Miroslav, Joachim, it is possible to try git bisecting this, starting from 2.6.12?

I have recently installed Fedora 9 w/updates on my PR440FX system, and up to kernel 2.6.25.x, I still do have to update the value of min_period [100 by default, now set to 50] in order to switch to the maximum allowd transfer of a nominal 40 MB/s.
The system was out of service for a longer period of time, but I will follow the suggestion from comment 28 to pin down the culprit.