[Bug 17897] 2.6.12-9-686 and SMP kernel and Ubuntu Live CD Panic During Boot with DPT/Adaptec I2O Controller - Cause: Loads both dpt_i20 and the i2o drivers.

bugzilla-daemon at bugzilla.ubuntu.com bugzilla-daemon at bugzilla.ubuntu.com
Fri Dec 16 12:21:53 UTC 2005


Please do not reply to this email.  You can add comments at
http://bugzilla.ubuntu.com/show_bug.cgi?id=17897
Ubuntu | linux


chris at csamuel.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




------- Additional Comments From chris at csamuel.org  2005-12-16 12:21 UTC -------
(In reply to comment #9)

> This bug has been fixed in the latest kernel in our Dapper release. There are no
> plans to fix this in breezy.

Just tried Dapper Flight CD 2.

I'm afraid that I still get a crash during boot on my system, although now
with what looks like an Oops rather than a panic, this time it's saying
"scheduling while atomic".

The system appears to boot normally and problems only start when it reaches the
"Detecting and activating hardware..." script.

The Adaptec DPT I2O driver appears to load with no problems, finds the RAID-5,
then the I2O subsystem tries to load and fails because it's already claimed, and
then the system crashes.

Here's the text of the lead up and the failure from the Dapper Flight CD 2 boot
with the "quiet" option removed.  Thankfully I could still scroll back unlike
previous panics so I could get the messages prior to the crash.  I've had to
transcribe manually so I've ommitted the leading timestamps and any typos
are likely to be mine.


TID 008:   Vendor: ADAPTEC     Device: AIC-7899  Rev: 00000001
TID 519:   Vendor: ADAPTECT    Device: RAID-5    Rev: 370F

scsi0 : Vendor: Adaptec Model:2100S     FW: 370F
  Vendor: ADAPTEC   Model: RAID-5     Rev: 370F
  Type:   Direct-Access               ANSI SCSI revision: 02
SCSI device sda: 143372288 512-byte hdwr sectors (73407MB)
SCSI device sda: drive cache: write back
SCSI device sda: 143372288 512-byte hdwr sectors (73407MB)
SCSI device sda: drive cache: write back
 sda: sda1
sd 0:0:0:0: Attached scsi disk sda
I2O subsystem v1.288
i2o: max drivers = 8
i2o: checking for PCI I2O controllers...
ACPI: PCI Interrupt 0000:02:01.1[A] -> GSI 21 (level, low) -> IRQ 193
iop0: controller found (0000:02:01.1)
PCI: Unable to reserve mem region #1:2000000 at dc000000 for device 0000:02:01.1
iop0: device already claimed
iop0: DMA / IO allocation for I2O controller  failed
ACPI: PCI interrupt for device 0000:02:01.1 disabled
dpti0: Trying to Abort: cmd=42
scheduling while atomic: scsi_eh_0/0xffffffff/3654
 [<c02e7722>] schedule+0x5c2/0x690
 [<c011bab3>] vprintk+0x1d3/0x340
 [<f8a3164e>] adpt_i2o_post_wait+0x1ae/0x250 [dpt_i2o]
 [<c0117b20>] default_wake_function+0x0/0x20
 [<f8a309c2>] adpt_abort+0x92/0x120 [dpt_i2o]
 [<f8a1134e>] scsi_eh_abort_cmds+-x4e/0x100 [scsi_mod]
 [<f8a1217b>] scsi_unjam_host+0xab/0x200 [scsi_mod]
 [<f8a122d0>] scsi_error_handler+0x0/0x120 [scsi_mod]
 [<f8a12399>] scsi_error_handler+0xc9/0x120 [scsi_mod]
 [<c012fdf3>] kthread+0x93/0xa0
 [<c012fd60>] kthread+0x0/0xa0
 [<c0101385>] kernel_thread_helper+0x5/0x10

It then says the following:

                                                          [fail]
 * Loading modules...                                     [ ok ]
 * Setting the system clock                               [ ok ]
 * Cleaning up ifupdown...                                [ ok ]
 * Setting the system clock                               [ ok ]
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel at redhat.com
 * Setting up LVM Volume Groups...                        [ ok ]
 * Starting Enterprise Volume Management System...              

and hangs with the cursor at the right hand side of the screen,
waiting for the EVMS script to complete or fail.

All the best,
Chris

-- 
Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.




More information about the kernel-bugs mailing list