Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
Hello folks, following up to this bugreport as I experience similar problems... I have an ASUS P2B-S mainboard featuring an Adaptec AIC-7890 Ultra2 chipset with a single device connected, a TEAC CD-R55S cd-writer, both working reliably ever since I bought them in 1998. The transport setting are as follows: | Adaptec AIC7xxx driver version: 6.2.36 | Adaptec aic7890/91 Ultra2 SCSI adapter | aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs | Allocated SCBs: 4, SG List Length: 128 | | Serial EEPROM: | 0x01bb 0x01bb 0x01bb 0x03f8 0x01f8 0x01bb 0x01bb 0x01bb | 0x01bb 0x01bb 0x01bb 0x01bb 0x01bb 0x01bb 0x01bb 0x01bb | 0x18a6 0x1c5e 0x2807 0x3010 0x0300 0x 0x 0x | 0x 0x 0x 0x 0x 0x 0x0300 0xb140 | | Target 0 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 1 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 2 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 3 Negotiation Settings | User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit) (I had an old CD-ROM drive here, but it finally broke a few weeks ago.) | Target 4 Negotiation Settings | User: 10.000MB/s transfers (5.000MHz, offset 127, 16bit) | Goal: 10.000MB/s transfers (10.000MHz, offset 15) | Curr: 10.000MB/s transfers (10.000MHz, offset 15) | Channel A Target 4 Lun 0 Settings | Commands Queued 48 | Commands Active 0 | Command Openings 1 | Max Tagged Openings 0 | Device Queue Frozen Count 0 | Target 5 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 6 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 7 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 8 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 9 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 10 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 11 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 12 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 13 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 14 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) | Target 15 Negotiation Settings | User: 80.000MB/s transfers (40.000MHz, offset 127, 16bit) Kernels up to 2.6.13.3 worked just fine (thanks guys!). However, when using kernel source 2.6.14.3 from kernel.org, 2.6.14-4 or 2.6.14-5 from Debian Sid (the latter both with and without James' patch, I just naively assumed it might help) the freshly-built kernel will allow me to mount any discs just fine, but when I start a CD recording program (k3b in my case) it won't come up at first, only to claim no writer device has been found later on. During this the syslog shows: | Dec 12 17:40:04 live k3b: resmgr: communication failure: No such file or directory | Dec 12 17:41:04 live kernel: scsi0:0:4:0: Attempting to queue an ABORT message | Dec 12 17:41:04 live kernel: CDB: 0x12 0x0 0x0 0x0 0x24 0x0 0x0 0x0 0x0 0x0 0x0 0x0 | Dec 12 17:41:04 live kernel: scsi0: At time of recovery, card was not paused | Dec 12 17:41:04 live kernel: >> Dump Card State Begins < | Dec 12 17:41:04 live kernel: scsi0: Dumping Card State in Command phase, at SEQADDR 0xb7 | Dec 12 17:41:04 live kernel: Card was paused | Dec 12 17:41:04 live kernel: ACCUM = 0x80, SINDEX = 0xa0, DINDEX = 0xe4, ARG_2 = 0x0 | Dec 12 17:41:04 live kernel: HCNT = 0xc SCBPTR = 0x0 | Dec 12 17:41:04 live kernel: SCSISIGI[0x44]:(BSYI|IOI) ERROR[0x0] SCSIBUSL[0x20] | Dec 12 17:41:04 live kernel: LASTPHASE[0x80]:(CDI) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) | Dec 12 17:41:04 live kernel: SBLKCTL[0x6]:(SELWIDE|ENAB20) SCSIRATE[0x18]:(SINGLE_EDGE) | Dec 12 17:41:04 live kernel: SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x0] SSTAT0[0x0] | Dec 12 17:41:04 live kernel: SSTAT1[0x3]:(REQINIT|PHASECHG) SSTAT2[0x40]:(SHVALID) | Dec 12 17:41:04 live kernel: SSTAT3[0xf]:(OFFCNT) SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) | Dec 12 17:41:04 live kernel: SXFRCTL0[0x80]:(DFON) DFCNTRL[0x24]:(DIRECTION|SCSIEN) | Dec 12 17:41:04 live kernel: DFSTATUS[0x80]:(PRELOAD_AVAIL) | Dec 12 17:41:04 live kernel: STACK: 0x0 0x167 0x17d 0x35 | Dec 12 17:41:04 live kernel: SCB count = 4 | Dec 12 17:41:04 live kernel: Kernel NEXTQSCB = 3 | Dec 12 17:41:04 live kernel: Card NEXTQSCB = 3 | Dec 12 17:41:04 live kernel: QINFIFO entries: | Dec 12 17:41:04 live kernel: Waiting Queue entries: | D
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
James Bottomley <[EMAIL PROTECTED]> wrote: > OK, try the attached. If it works out, I'll soak it in -mm for > a while and then try to put it in as a bug fix for 2.6.15. This works for me. The DV write tests are skipped and the system boots cleanly. The boot messages are the same as when we ifdef'd out the "get echo buffer" call. -- graham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
James Bottomley wrote: On Sun, 2005-11-20 at 21:21 -0500, Graham Knap wrote: Sure enough, the kernel now boots. I'll attach the "dmesg" output here. Do you guys have a "final" patch in mind? Let me know if there are other tests you'd like me to run. Now that I know how to do this, I should be able to turn around test results fairly quickly. OK, try the attached. If it works out, I'll soak it in -mm for a while and then try to put it in as a bug fix for 2.6.15. [ snip ] Nice patch, looks like the correct thing to do to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Sun, 2005-11-20 at 21:21 -0500, Graham Knap wrote:
> Sure enough, the kernel now boots. I'll attach the "dmesg" output here.
>
> Do you guys have a "final" patch in mind?
>
> Let me know if there are other tests you'd like me to run. Now that I
> know how to do this, I should be able to turn around test results
> fairly quickly.
OK, try the attached. If it works out, I'll soak it in -mm for a while
and then try to put it in as a bug fix for 2.6.15.
James
diff --git a/drivers/scsi/scsi_transport_spi.c
b/drivers/scsi/scsi_transport_spi.c
--- a/drivers/scsi/scsi_transport_spi.c
+++ b/drivers/scsi/scsi_transport_spi.c
@@ -812,12 +812,10 @@ spi_dv_device_internal(struct scsi_devic
if (!scsi_device_sync(sdev) && !scsi_device_dt(sdev))
return;
- /* see if the device has an echo buffer. If it does we can
-* do the SPI pattern write tests */
-
- len = 0;
- if (scsi_device_dt(sdev))
- len = spi_dv_device_get_echo_buffer(sdev, buffer);
+ /* len == -1 is the signal that we need to ascertain the
+* presence of an echo buffer before trying to use it. len ==
+* 0 means we don't have an echo buffer */
+ len = -1;
retry:
@@ -840,11 +838,23 @@ spi_dv_device_internal(struct scsi_devic
if (spi_min_period(starget) == 8)
DV_SET(pcomp_en, 1);
}
+ /* Do the read only INQUIRY tests */
+ spi_dv_retrain(sdev, buffer, buffer + sdev->inquiry_len,
+ spi_dv_device_compare_inquiry);
+ /* See if we actually managed to negotiate and sustain DT */
+ if (i->f->get_dt)
+ i->f->get_dt(starget);
+
+ /* see if the device has an echo buffer. If it does we can do
+* the SPI pattern write tests. Because of some broken
+* devices, we *only* try this on a device that has actually
+* negotiated DT */
+
+ if (len == -1 && spi_dt(starget))
+ len = spi_dv_device_get_echo_buffer(sdev, buffer);
- if (len == 0) {
+ if (len <= 0) {
starget_printk(KERN_INFO, starget, "Domain Validation skipping
write tests\n");
- spi_dv_retrain(sdev, buffer, buffer + len,
- spi_dv_device_compare_inquiry);
return;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
Hi guys, This week I recreated the Debian kernel per Horms' instructions. I then applied James' source patch, and recompiled. > --- a/drivers/scsi/scsi_transport_spi.c > +++ b/drivers/scsi/scsi_transport_spi.c > @@ -816,8 +816,10 @@ spi_dv_device_internal(struct scsi_devic >* do the SPI pattern write tests */ > > len = 0; > +#if 0 > if (scsi_device_dt(sdev)) > len = spi_dv_device_get_echo_buffer(sdev, buffer); > +#endif > > retry: Sure enough, the kernel now boots. I'll attach the "dmesg" output here. Do you guys have a "final" patch in mind? Let me know if there are other tests you'd like me to run. Now that I know how to do this, I should be able to turn around test results fairly quickly. -- grahamLinux version 2.6.14-p () ([EMAIL PROTECTED]) (gcc version 4.0.3 2005 (prerelease) (Debian 4.0.2-4)) #1 Fri Nov 18 22:01:49 EST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 17ffd000 (usable) BIOS-e820: 17ffd000 - 17fff000 (ACPI data) BIOS-e820: 17fff000 - 1800 (ACPI NVS) BIOS-e820: - 0001 (reserved) 0MB HIGHMEM available. 383MB LOWMEM available. On node 0 totalpages: 98301 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 94205 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI 2.0 present. ACPI: RSDP (v000 ASUS ) @ 0x000f7dd0 ACPI: RSDT (v001 ASUS P2L-B0x58582e31 ASUS 0x31303030) @ 0x17ffd000 ACPI: FADT (v001 ASUS P2L-B0x58582e31 ASUS 0x31303030) @ 0x17ffd080 ACPI: BOOT (v001 ASUS P2L-B0x58582e31 ASUS 0x31303030) @ 0x17ffd040 ACPI: DSDT (v001 ASUS P2L-B0x1000 MSFT 0x0101) @ 0x ACPI: PM-Timer IO Port: 0xe408 Allocating PCI resources starting at 2000 (gap: 1800:e7ff) Built 1 zonelists Kernel command line: root=/dev/sda3 ro Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (01302000) Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 501.146 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 385200k/393204k available (1803k kernel code, 7400k reserved, 512k data, 180k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1002.80 BogoMIPS (lpj=501404) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0183f9ff CPU: After vendor identify, caps: 0183f9ff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K CPU: After all inits, caps: 0183f9ff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: Intel Celeron (Mendocino) stepping 05 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0200 (from 0a00) checking if image is initramfs... it is softlockup thread 0 started up. Freeing initrd memory: 1144k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xf06d0, last bus=1 PCI: Using configuration type 1 ACPI: Subsystem revision 20050902 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 PCI quirk: region e400-e43f claimed by PIIX4 ACPI PCI quirk: region e800-e81f claimed by PIIX4 SMB PIIX4 devres B PIO at 0290-0297 Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 12 devices PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report pnp: 00:01: ioport range 0xe400-0xe43f could not be reserved pnp: 00:01: ioport range 0xe800-0xe80f has been reserved pnp: 00:01: ioport range 0x294-0x297 has been reserved PCI: Bridge: :00:01.0 IO window: disabled. MEM window: d600-d7df PREFETCH window: d7f0-e3ff Simple Boot Flag at 0x46 set
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Mon, Nov 14, 2005 at 07:45:20PM -0500, Graham Knap wrote: > James Bottomley <[EMAIL PROTECTED]> wrote: > > Can you try with the attached patch, which will force DV to ignore > > the echo buffer write tests? > > I'll certainly try. > > The kernel I was using was a prebuilt Debian kernel. I'm not sure how > to rebuild it from source. Horms, if you could point me in the right > direction, I'll give it a try. That depends exactly what you want to build. To just make an image for testing, upacking the tarball supplied by linux-source-2.6.14, using the config that came with linux-image-XYZ in /boot, and optionally using make-kpkg, should work. Though I think you have most of that happening. > > For now, I've built a kernel using the linux-source-2.6.14 package > (version 2.6.14-2). It's massively stripped down so that it compiles in > a semi-reasonable amount of time on this very slow PC. There isn't a great deal I can suggest in order to speed up builds, except perhaps using ccache, or trimming the config as you have done. If you need me to build stuff for you, I'm happy to oblige, though obviously there are extra email round-trips involved. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
James Bottomley <[EMAIL PROTECTED]> wrote: > Can you try with the attached patch, which will force DV to ignore > the echo buffer write tests? I'll certainly try. The kernel I was using was a prebuilt Debian kernel. I'm not sure how to rebuild it from source. Horms, if you could point me in the right direction, I'll give it a try. For now, I've built a kernel using the linux-source-2.6.14 package (version 2.6.14-2). It's massively stripped down so that it compiles in a semi-reasonable amount of time on this very slow PC. Strangely, this one boots. It throws out a lot of error messages, but it boots. I'll attach the configuration and the log here. Is there still any need to try this patch? > --- a/drivers/scsi/scsi_transport_spi.c > +++ b/drivers/scsi/scsi_transport_spi.c > @@ -816,8 +816,10 @@ spi_dv_device_internal(struct scsi_devic >* do the SPI pattern write tests */ > > len = 0; > +#if 0 > if (scsi_device_dt(sdev)) > len = spi_dv_device_get_echo_buffer(sdev, buffer); > +#endif > > retry: The boot log shows that execution is getting past there, to line 846: target0:0:0: Domain Validation skipping write tests Sorry for the confusion. Let me know what I should try next. -- graham config-2.6.14-test1 Description: 2957028909-config-2.6.14-test1 Linux version 2.6.14-test1 () ([EMAIL PROTECTED]) (gcc version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3)) #1 Sun Nov 13 15:45:23 EST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 17ffd000 (usable) BIOS-e820: 17ffd000 - 17fff000 (ACPI data) BIOS-e820: 17fff000 - 1800 (ACPI NVS) BIOS-e820: - 0001 (reserved) 383MB LOWMEM available. On node 0 totalpages: 98301 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 94205 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI 2.0 present. Allocating PCI resources starting at 2000 (gap: 1800:e7ff) Built 1 zonelists Kernel command line: root=/dev/sda3 ro Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (01302000) Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 501.231 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 386876k/393204k available (1440k kernel code, 5728k reserved, 475k data, 144k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1003.66 BogoMIPS (lpj=2007329) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0183f9ff CPU: After vendor identify, caps: 0183f9ff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K CPU: After all inits, caps: 0183f9ff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. mtrr: v2.0 (20020519) CPU: Intel Celeron (Mendocino) stepping 05 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. softlockup thread 0 started up. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xf06d0, last bus=1 PCI: Using configuration type 1 Linux Plug and Play Support v0.97 (c) Adam Belay PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00fd1a0 PnPBIOS: PnP BIOS version 1.0, entry 0xf:0xd1d0, dseg 0xf PnPBIOS: 15 nodes reported by PnP BIOS; 15 recorded by driver SCSI subsystem initialized PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI quirk: region e400-e43f claimed by PIIX4 ACPI PCI quirk: region e800-e81f claimed by PIIX4 SMB PIIX4 devres B PIO at 0290-0297 Boot video device is :01:00.0 PCI: Using IRQ router PIIX/ICH [8086/7110] at :00:04.0 pnp: 00:0f: ioport range 0x290-0x297 has been reserved pnp: 00:0f: ioport range 0xe400-0xe43f has been reserved pnp: 00:0f: ioport range 0xe800-0xe83f could not be reserved PCI: Bridge: :00:01.0 IO window: disabled. MEM window: d600-d7df PREFETCH window: d7f0-e3ff Initializing Cryptographic API Limiting direct PCI/PCI transfers. isapnp: Scanning for PnP cards... pnp: SB audio device quirk - increasing port range isapnp: Card 'Creative SB16 PnP' isapnp: 1 Plug & Play card detected total PNP: PS/2 Controller [PNP0303,PNP0f13] at 0x60,0x64 irq 1,12 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Sun, 2005-11-13 at 14:42 -0500, Doug Ledford wrote: > The device is on a non-LVD bus. Certain devices were created back when > the spec still stated that using PPR negotiation messages on a non-LVD > bus was a no-no. As the echo buffer was an addition to support DV, and > originally DV wasn't intended to be used on non-LVD busses, it might > stand to reason that this device simply is going tits up because we are > attempting to use the echo buffer while in SE mode. Checking that > PPR/DT is valid (not just between controller and device, but also given > bus mode) and only using echo buffer DV when all LVD conditions are met > would likely solve the problem (assuming that the problem is what you > are referring to). I think so (pending confirmation of the patch working). The current DV code assumes that if the device claims DT support in the INQUIRY data *and* it returns a valid descriptor to the READ_BUFFER descriptors command then enhanced DV should be attempted. What I'm contemplating doing (which is what you also suggest) is tightening up the check so if the standard DV read tests produce a negotiation that doesn't set DT then we won't attempt enhanced DV James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
James Bottomley wrote:
On Sun, 2005-11-13 at 13:03 -0500, Graham Knap wrote:
Doug Ledford <[EMAIL PROTECTED]> wrote:
You already said it didn't help with the problem,
I meant that I don't think I successfully disabled DV, because the boot
messages were *identical*, except for the line where the kernel shows
the "Kernel command line".
I had added this argument at the end of the line: aic7xxx=dv:{0}
I've re-read "aic7xxx.txt" and I'm not sure what I'm doing wrong. If
you can tell me how to disable DV, I'd be happy to give it a try.
aic7xxx.txt is out of date. The aic7xxx (and 79xx) drivers use the
generic domain validation code now rather than the old aic specific ones
(which is what the dv:{0} option is referring to). If you try the code
in the prior email, I think that will disable the piece of DV that's
causing the problem.
If the test code succeeds, the problem is pretty nasty: Apparently the
device claims DT support but in fact rejects DT in the negotiation. We
use DT support to begin the check for an echo buffer, which starts with
READ_BUFFERS for the descriptor. Apparently this device returns a valid
descriptor with a reasonable echo buffer size and then promptly throws a
wobbly when we try to use it.
James
The device is on a non-LVD bus. Certain devices were created back when
the spec still stated that using PPR negotiation messages on a non-LVD
bus was a no-no. As the echo buffer was an addition to support DV, and
originally DV wasn't intended to be used on non-LVD busses, it might
stand to reason that this device simply is going tits up because we are
attempting to use the echo buffer while in SE mode. Checking that
PPR/DT is valid (not just between controller and device, but also given
bus mode) and only using echo buffer DV when all LVD conditions are met
would likely solve the problem (assuming that the problem is what you
are referring to).
--
Doug Ledford <[EMAIL PROTECTED]>
http://people.redhat.com/dledford
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Sun, 2005-11-13 at 13:03 -0500, Graham Knap wrote:
> Doug Ledford <[EMAIL PROTECTED]> wrote:
> > You already said it didn't help with the problem,
>
> I meant that I don't think I successfully disabled DV, because the boot
> messages were *identical*, except for the line where the kernel shows
> the "Kernel command line".
>
> I had added this argument at the end of the line: aic7xxx=dv:{0}
>
> I've re-read "aic7xxx.txt" and I'm not sure what I'm doing wrong. If
> you can tell me how to disable DV, I'd be happy to give it a try.
aic7xxx.txt is out of date. The aic7xxx (and 79xx) drivers use the
generic domain validation code now rather than the old aic specific ones
(which is what the dv:{0} option is referring to). If you try the code
in the prior email, I think that will disable the piece of DV that's
causing the problem.
If the test code succeeds, the problem is pretty nasty: Apparently the
device claims DT support but in fact rejects DT in the negotiation. We
use DT support to begin the check for an echo buffer, which starts with
READ_BUFFERS for the descriptor. Apparently this device returns a valid
descriptor with a reasonable echo buffer size and then promptly throws a
wobbly when we try to use it.
James
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
Doug Ledford <[EMAIL PROTECTED]> wrote:
> If the drive is unaccessible after the DV failure, even on a warm
> reboot (which includes a SCSI bus reset), then the drive is flat
> hung. Something done in the current code is breaking it.
Ah. I had wondered if that was possible.
> Can you get a boot with DV turned off and capture the log messages
> and post them here please?
I certainly can, but...
> You already said it didn't help with the problem,
I meant that I don't think I successfully disabled DV, because the boot
messages were *identical*, except for the line where the kernel shows
the "Kernel command line".
I had added this argument at the end of the line: aic7xxx=dv:{0}
I've re-read "aic7xxx.txt" and I'm not sure what I'm doing wrong. If
you can tell me how to disable DV, I'd be happy to give it a try.
-- graham
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Sun, 2005-11-13 at 12:41 -0500, Doug Ledford wrote: > If the drive is unaccessible after the DV failure, even on a warm reboot > (which includes a SCSI bus reset), then the drive is flat hung. > Something done in the current code is breaking it. Can you get a boot > with DV turned off and capture the log messages and post them here > please? You already said it didn't help with the problem, but I'd like > to see the failure scenario with it off, that might help determine the > true root cause of the issue. Yes, you're right ... the sequencer code seems to identify the WRITE_BUFFER as the failing command. Can you try with the attached patch, which will force DV to ignore the echo buffer write tests? Thanks, James diff --git a/drivers/scsi/scsi_transport_spi.c b/drivers/scsi/scsi_transport_spi.c --- a/drivers/scsi/scsi_transport_spi.c +++ b/drivers/scsi/scsi_transport_spi.c @@ -816,8 +816,10 @@ spi_dv_device_internal(struct scsi_devic * do the SPI pattern write tests */ len = 0; +#if 0 if (scsi_device_dt(sdev)) len = spi_dv_device_get_echo_buffer(sdev, buffer); +#endif retry: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
Graham Knap wrote: James Bottomley <[EMAIL PROTECTED]> wrote: My best guess would be that the bus is slightly marginal. The aic7xxx drivers are notoriously sensitive to bus problems. Could you try lowering the bus speed to 10MHz in the aic7xxx bios and see if that helps? Sure. I changed the device to 20MByte/s max. Now the driver shows 10MHz, 16-bit wide... and DV still fails, with what looks like the same messages. I would expect this given what you state later... As for the bus being marginal, I don't see why it would be, but anything is possible. Host adapter termination is set to "Automatic". If I understand things correctly, since there's no cable attached to the internal 50pin connector or the external connector, I could try forcing it to "Low ON / High ON"... right? The cabling looks like this: [HBA] -- [disk] -- [unused connector] -- [terminator] Termination should be fine as automatic, but yes, you could force both on. I'm pretty sure the cable is U160 rated (it wasn't cheap). The terminator isn't integrated into the cable -- it's a plug-in Active SE terminator. The drive is LVD capable, but I've never had trouble running it in SE mode. The "Force SE" jumper is not installed, but I suppose I could try that too. Don't bother. http://www.hitachigst.com/tech/techlib.nsf/products/Ultrastar_36LZX BTW -- Another oddity I should mention is that if I warm-reboot the system after DV fails, the drive isn't detected during POST. Power cycling fixes it. (In other cases, warm-rebooting works fine.) Let me know what I should try next. If the drive is unaccessible after the DV failure, even on a warm reboot (which includes a SCSI bus reset), then the drive is flat hung. Something done in the current code is breaking it. Can you get a boot with DV turned off and capture the log messages and post them here please? You already said it didn't help with the problem, but I'd like to see the failure scenario with it off, that might help determine the true root cause of the issue. -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
James Bottomley <[EMAIL PROTECTED]> wrote: > My best guess would be that the bus is slightly marginal. The > aic7xxx drivers are notoriously sensitive to bus problems. Could you > try lowering the bus speed to 10MHz in the aic7xxx bios and see if > that helps? Sure. I changed the device to 20MByte/s max. Now the driver shows 10MHz, 16-bit wide... and DV still fails, with what looks like the same messages. As for the bus being marginal, I don't see why it would be, but anything is possible. Host adapter termination is set to "Automatic". If I understand things correctly, since there's no cable attached to the internal 50pin connector or the external connector, I could try forcing it to "Low ON / High ON"... right? The cabling looks like this: [HBA] -- [disk] -- [unused connector] -- [terminator] I'm pretty sure the cable is U160 rated (it wasn't cheap). The terminator isn't integrated into the cable -- it's a plug-in Active SE terminator. The drive is LVD capable, but I've never had trouble running it in SE mode. The "Force SE" jumper is not installed, but I suppose I could try that too. http://www.hitachigst.com/tech/techlib.nsf/products/Ultrastar_36LZX BTW -- Another oddity I should mention is that if I warm-reboot the system after DV fails, the drive isn't detected during POST. Power cycling fixes it. (In other cases, warm-rebooting works fine.) Let me know what I should try next. -- graham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Tue, 2005-11-08 at 20:47 -0500, Graham Knap wrote: > 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) That's a bit unfortunate ... it shows that the domain validation code negotiated identical settings in the old kernel, so it doesn't look like that's the problem. My best guess would be that the bus is slightly marginal. The aic7xxx drivers are notoriously sensitive to bus problems. Could you try lowering the bus speed to 10MHz in the aic7xxx bios and see if that helps? Thanks, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
Graham Knap <[EMAIL PROTECTED]> wrote: > Recent versions of the aic7xxx driver will not boot on my secondary > PC. The 2.6.8 kernel shipped with sarge works, but neither the 2.6.12 > kernel in testing nor the 2.6.14 kernel in unstable will boot. > This is an older system: > Asus P2L-B, Celeron 500MHz, 384MB RAM, GeForce2 MX AGP > Adaptec 2940UW, IBM DDYS-T09170 (9GB disk) Horms <[EMAIL PROTECTED]> wrote: > This does smell a lot like a driver bug, and as such, its proably > best passed onto the upstream maintainers. James Bottomley <[EMAIL PROTECTED]> wrote: > This is an older drive, so it looks like it passes domain validation > (read only) but then chokes on the next command. On 2.6.8, what do > the transport settings report? (that's cat /proc/scsi/aic7xxx/0)? Thanks for responding so quickly. Here's what I see on 2.6.8. [EMAIL PROTECTED]:~$ uname -a Linux testbox 2.6.8-2-686 #1 Thu May 19 17:53:30 JST 2005 i686 GNU/Linux [EMAIL PROTECTED]:~$ cat /proc/scsi/aic7xxx/0 Adaptec AIC7xxx driver version: 6.2.36 Adaptec 2940 Ultra SCSI adapter aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs Allocated SCBs: 12, SG List Length: 128 Serial EEPROM: 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x02f8 0x18a6 0x005f 0x2807 0x0010 0xff00 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x00ff 0x7092 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 49075 Commands Active 0 Command Openings 8 Max Tagged Openings 8 Device Queue Frozen Count 0 Target 1 Negotiation Settings User: 40.000MB/s transfers (20.000MHz, offset 127, 16bit) ... Target 0 is the only device, so I assume that the remaining output is meaningless. Let me know if there's anything else I can do to help. -- graham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Tue, 2005-11-08 at 12:31 +0900, Horms wrote:
> On Mon, Nov 07, 2005 at 09:45:23PM -0500, Graham Knap wrote:
> > Package: linux-image-2.6.14-1-686
> > Version: 2.6.14-2
> >
> > Recent versions of the aic7xxx driver will not boot on my secondary PC.
> > The 2.6.8 kernel shipped with sarge works perfectly, but neither the
> > 2.6.12 kernel in testing nor the 2.6.14 kernel in unstable will boot.
> >
> > This is an older system:
> > Asus P2L-B, Celeron 500MHz, 384MB RAM, GeForce2 MX AGP
> > Adaptec 2940UW, IBM DDYS-T09170 (9GB disk)
> >
> > I can't understand what exactly is failing, but I will attach a boot
> > log. (So null modem cables *are* still useful for something!)
> >
> > I've tried adding "aic7xxx=dv:{0}" to the boot arguments but that
> > doesn't seem to make a difference. Also, "aic7xxx=verbose" doesn't seem
> > to do anything either.
> >
> > I don't know if this makes a difference but my 2940UW reports its BIOS
> > revision as "1.34.3" during POST.
> >
> > Any help would be much appreciated.
>
> Hi Graham,
>
> thanks for your detailed report. This does smell a lot like a driver
> bug, and as such, its proably best passed onto the upstream maintainers.
> As such I've CCed James Bottomley and linux-scsi for comment.
>
> The other main possiblility, is that perhaps the aic7xxx_old driver would
> work. Or perhaps some other module loading foo, though its seems the
> module is loaded fine, it just doesn't like your card very much.
This is an older drive, so it looks like it passes domain validation
(read only) but then chokes on the next command. On 2.6.8, what do the
transport settings report? (that's cat /proc/scsi/aic7xxx/0)?
Thanks,
James
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
On Mon, Nov 07, 2005 at 09:45:23PM -0500, Graham Knap wrote:
> Package: linux-image-2.6.14-1-686
> Version: 2.6.14-2
>
> Recent versions of the aic7xxx driver will not boot on my secondary PC.
> The 2.6.8 kernel shipped with sarge works perfectly, but neither the
> 2.6.12 kernel in testing nor the 2.6.14 kernel in unstable will boot.
>
> This is an older system:
> Asus P2L-B, Celeron 500MHz, 384MB RAM, GeForce2 MX AGP
> Adaptec 2940UW, IBM DDYS-T09170 (9GB disk)
>
> I can't understand what exactly is failing, but I will attach a boot
> log. (So null modem cables *are* still useful for something!)
>
> I've tried adding "aic7xxx=dv:{0}" to the boot arguments but that
> doesn't seem to make a difference. Also, "aic7xxx=verbose" doesn't seem
> to do anything either.
>
> I don't know if this makes a difference but my 2940UW reports its BIOS
> revision as "1.34.3" during POST.
>
> Any help would be much appreciated.
Hi Graham,
thanks for your detailed report. This does smell a lot like a driver
bug, and as such, its proably best passed onto the upstream maintainers.
As such I've CCed James Bottomley and linux-scsi for comment.
The other main possiblility, is that perhaps the aic7xxx_old driver would
work. Or perhaps some other module loading foo, though its seems the
module is loaded fine, it just doesn't like your card very much.
Content-Description: 2066060778-bootlog-2.6.14.txt
> Linux version 2.6.14-1-686 (Debian 2.6.14-2) ([EMAIL PROTECTED]) (gcc version
> 4.0.3 20051023 (prerelease) (Debian 4.0.2-3)) #1 Tue Nov 1 15:51:43 JST 2005
> BIOS-provided physical RAM map:
> BIOS-e820: - 0009fc00 (usable)
> BIOS-e820: 0009fc00 - 000a (reserved)
> BIOS-e820: 000f - 0010 (reserved)
> BIOS-e820: 0010 - 17ffd000 (usable)
> BIOS-e820: 17ffd000 - 17fff000 (ACPI data)
> BIOS-e820: 17fff000 - 1800 (ACPI NVS)
> BIOS-e820: - 0001 (reserved)
> 0MB HIGHMEM available.
> 383MB LOWMEM available.
> DMI 2.0 present.
> ACPI: PM-Timer IO Port: 0xe408
> Allocating PCI resources starting at 2000 (gap: 1800:e7ff)
> Built 1 zonelists
> Kernel command line: root=/dev/sda3 ro single console=tty0
> console=ttyS1,38400n8
> Local APIC disabled by BIOS -- you can enable it with "lapic"
> Initializing CPU#0
> PID hash table entries: 2048 (order: 11, 32768 bytes)
> Detected 501.254 MHz processor.
> Using pmtmr for high-res timesource
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 385200k/393204k available (1803k kernel code, 7432k reserved, 512k
> data, 180k init, 0k highmem)
> Checking if this processor honours the WP bit even in supervisor mode... Ok.
> Calibrating delay using timer specific routine.. 1002.82 BogoMIPS (lpj=501412)
> Security Framework v1.0.0 initialized
> SELinux: Disabled at boot.
> Capability LSM initialized
> Mount-cache hash table entries: 512
> CPU: L1 I cache: 16K, L1 D cache: 16K
> CPU: L2 cache: 128K
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> mtrr: v2.0 (20020519)
> CPU: Intel Celeron (Mendocino) stepping 05
> Enabling fast FPU save and restore... done.
> Checking 'hlt' instruction... OK.
> ACPI: setting ELCR to 0200 (from 0a00)
> checking if image is initramfs... it is
> softlockup thread 0 started up.
> Freeing initrd memory: 1176k freed
> NET: Registered protocol family 16
> ACPI: bus type pci registered
> PCI: PCI BIOS revision 2.10 entry at 0xf06d0, last bus=1
> PCI: Using configuration type 1
> ACPI: Subsystem revision 20050902
> ACPI: Interpreter enabled
> ACPI: Using PIC for interrupt routing
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
> ACPI: PCI Root Bridge [PCI0] (:00)
> PCI: Probing PCI hardware (bus 00)
> ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
> PCI quirk: region e400-e43f claimed by PIIX4 ACPI
> PCI quirk: region e800-e81f claimed by PIIX4 SMB
> PIIX4 devres B PIO at 0290-0297
> Linux Plug and Play Support v0.97 (c) Adam Belay
> pnp: PnP ACPI init
> pnp: PnP ACPI: found 12 devices
> PnPBIOS: Disabled by ACPI PNP
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
> pnp: 00:01: ioport range 0xe400-0xe43f could not be reserved
> pnp: 00:01: ioport range 0xe800-0xe80f has been reserved
> pnp: 00:01: ioport range 0x294-0x297 has been reserved
> PCI: Bridge: :00:01.0
> IO window: disabled.
> MEM window: d600-d7df
> PREFETCH window: d7f0-e3ff
> Simple Boot Flag at 0x46 set to 0x1
> audit: initializing netlink socket (disable
Bug#338089: New aic7xxx driver fails spectacularly on 2940UW
Package: linux-image-2.6.14-1-686
Version: 2.6.14-2
Recent versions of the aic7xxx driver will not boot on my secondary PC.
The 2.6.8 kernel shipped with sarge works perfectly, but neither the
2.6.12 kernel in testing nor the 2.6.14 kernel in unstable will boot.
This is an older system:
Asus P2L-B, Celeron 500MHz, 384MB RAM, GeForce2 MX AGP
Adaptec 2940UW, IBM DDYS-T09170 (9GB disk)
I can't understand what exactly is failing, but I will attach a boot
log. (So null modem cables *are* still useful for something!)
I've tried adding "aic7xxx=dv:{0}" to the boot arguments but that
doesn't seem to make a difference. Also, "aic7xxx=verbose" doesn't seem
to do anything either.
I don't know if this makes a difference but my 2940UW reports its BIOS
revision as "1.34.3" during POST.
Any help would be much appreciated.
-- grahamLinux version 2.6.14-1-686 (Debian 2.6.14-2) ([EMAIL PROTECTED]) (gcc version
4.0.3 20051023 (prerelease) (Debian 4.0.2-3)) #1 Tue Nov 1 15:51:43 JST 2005
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 17ffd000 (usable)
BIOS-e820: 17ffd000 - 17fff000 (ACPI data)
BIOS-e820: 17fff000 - 1800 (ACPI NVS)
BIOS-e820: - 0001 (reserved)
0MB HIGHMEM available.
383MB LOWMEM available.
DMI 2.0 present.
ACPI: PM-Timer IO Port: 0xe408
Allocating PCI resources starting at 2000 (gap: 1800:e7ff)
Built 1 zonelists
Kernel command line: root=/dev/sda3 ro single console=tty0 console=ttyS1,38400n8
Local APIC disabled by BIOS -- you can enable it with "lapic"
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 501.254 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 385200k/393204k available (1803k kernel code, 7432k reserved, 512k
data, 180k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1002.82 BogoMIPS (lpj=501412)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel Celeron (Mendocino) stepping 05
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0a00)
checking if image is initramfs... it is
softlockup thread 0 started up.
Freeing initrd memory: 1176k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf06d0, last bus=1
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region e400-e43f claimed by PIIX4 ACPI
PCI quirk: region e800-e81f claimed by PIIX4 SMB
PIIX4 devres B PIO at 0290-0297
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
pnp: 00:01: ioport range 0xe400-0xe43f could not be reserved
pnp: 00:01: ioport range 0xe800-0xe80f has been reserved
pnp: 00:01: ioport range 0x294-0x297 has been reserved
PCI: Bridge: :00:01.0
IO window: disabled.
MEM window: d600-d7df
PREFETCH window: d7f0-e3ff
Simple Boot Flag at 0x46 set to 0x1
audit: initializing netlink socket (disabled)
audit(1131398011.104:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
pnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug & Play card detected total
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3
