Correct modules for I2O-based raid are not loaded

Can't guarantee that this will get fixed for breezy, but since it's a regression I'm pushing it to P1 in the
hopes that it will get fixed.

Please could you send me the actual kernel panic? Taking a picture with a digital camera will suffice.

Thanks

I still need the actual kernel panic for this bug. Without it, I can't do much
to fix it. Also, attaching lspci -vv and lspci -vvn output would be appreciated.

Hi -

I did not have a digital camera available at the office last week; I have
acquired one and will photograph the display for you.

Thank you,
Stu

(In reply to comment #2)
> I still need the actual kernel panic for this bug. Without it, I can't do much
> to fix it. Also, attaching lspci -vv and lspci -vvn output would be appreciated.

Created an attachment (id=4173)
Screenshot of Kernel Panic

Screenshot of the kernel panic... Prevents Ubuntu installer from booting off
CD.

I can also reproduce this with a DPT PM3754U2 RAID controller (also i2o) using
the 29th Sept Breezy installation iso.

Peter

Created an attachment (id=4276)
lspci -vv output

Created an attachment (id=4277)
lspci -vvn output

This is happening with a SuperTrak100, I think it's worth saying that it panics
the kernel (different panic) when you load the i2o_block module in hoary. I've
attached my lspci -vv and lspci -vvn.

This computer has software raid on the MoBo, but I have that disabled in the
computer bios.

If you need any further information or testing, I should be able to help.

This bug is also happening on my Dell PowerEdge 1300 which is a pretty common
servers out there.
NOTE: *** THIS IS NOT HAPPENING IN HOARY ***

SCSI storage adapter: Adaptec AHA-2940U2/U2W using AIC-7890 v.2.01 driver.

Breezy install method: I updated from hoary (2.6.10-5) using apt-get
dist-upgrade on 10/6/2005

Let me know if you need more info specific on my setup.

Whoops, upon looking at the output of lspci -vv, I realize that the I2O is not
the Adaptec,
rather it's a MegaRAID 466, PERC 2/SC.

Sorry for the confusion. To clarify things, I attached my lspci -vv output.

Created an attachment (id=4452)
lspci -vv output for comments no 9 and 10

Has anyone reconfirmed this with the release candidate, or gathered a trace?

https://wiki.ubuntu.com/DebuggingSystemCrash

Created an attachment (id=4517)
LSPCI -VVN from original bug (Comment 1) on Ubuntu 5.04 Hoary

Finally got 5.04 installed on this box again - 5.04 works without a hitch. Even
installing 5.04 and then upgrading to 5.10 w/ the latest kernel from apt
produces the same panic.

- Stu

I, too, am getting this panic in Breezy. Hoary works unbelieveably well.

Please tell me someone is still working on this, as this is on a server at my
workplace. Is there a more advanced universe kernel out there?

What additional information and/or resources are needed to resolve this issue? We are most
interested in getting this resolved, and would love to help fix this.

Please let me know what I can do to help!

- Stu

If possible, please upgrade to Dapper's 2.6.15-7 kernel. If you do not want to
upgrade to Dapper, then you can also wait for the Dapper Flight 2 CD's, which
are due out within the next few days.

Let me know if this bug still exists with this kernel.

I did a test with flight 2 and things are improved, but there are still problems
that would prevent the average user (or even sysadmin) from completing an install...

Here's a summary - I'll post additional info as I play around with it...

a) Module detection: Loads i2o_core from the new i2o subsystem layer but forgets
i2o_block, et al and therefore can not autodetect connected i2o disks. The
installer only presents dpt_i2o as an option, but since i2o_core has already
claimed the device dpt_i2o can not bind to the card. The Distribution needs to
settle on the new i2o layer or the traditional dpt_i2o driver. The new i2o layer
does have some compelling things going for it - namely an active development
path in the 2.6x kernels.

It should be noted that once the new i2o layers are hand-loaded, the installer
does successfully install to the disk!

b) The device mappings for GRUB are broken with the new i2o layers. They default
to /dev/sda instead of /dev/i2o/hda, etc. This prevents an automated grub install.

c) Once installed, the initrd does not (of course - due to my manual
installation) include the proper i2o_* drivers.

I'll do the same tests with the dpt_i2o drivers and see if we have better success.

- Stu

Ok, since things are working, this has now become a userspace issue. I'm not
sure if this needs to be addressed in the installer itself, or in udev. I'll
send it to udev, since it does most of the module loading.

I don't see any udev bugs here, the bugs that I can see are:

1) the kernel doesn't specify any devices (via MODALIAS or map files) for i2o_block and it isn't a dependency of anything

2) grub device mappings are broken

3) installer giving the wrong driver

as noted, once these are overcome the userland (initramfs and udev) work fine

I've fixed hw-detect upstream to offer i2o_block et al as well if disk devices weren't detected properly.

This is fixed in the dapper kernel. The fix could be backported to breezy's kernel.

BenC: This is not fixed -- read the comments

Sorry, please delete this "bug". Am just getting acquinted with this website.

> Sorry, please delete this "bug". Am just getting acquinted with
> this website.

Done.

grub (0.97-1ubuntu6) dapper; urgency=low

  * Build-depend on libc6-i386-dev on amd64 in preference to ia32-libs-dev.
  * Add I2O support (patch from i2o.shadowconnect.com; closes: Malone
    #15466, #22220).

 -- Colin Watson <email address hidden> Wed, 15 Mar 2006 12:25:17 +0000

Are we any closer to gettin rid of this bug? I can confirm it on a FSC Primergy L200 with dapper-server 606

hw-detect 1.38ubuntu1 uploaded to edgy, including:

hw-detect (1.33) unstable; urgency=low

  [ Martin Michlmayr ]
  * Add a description of Intel's IXP400 Ethernet driver.

  [ Colin Watson ]
  * Replace another udevsynthesize call with update-dev.
  * Remove old DEB_HOST_ARCH_* and CFLAGS_ARCH cruft.
  * Fix CFLAGS so that the apparently-intended version formerly in
    debian/rules actually gets used; no impact on size, though.
  * Offer disk devices from drivers/message/fusion and drivers/message/i2o
    (https://launchpad.net/distros/ubuntu/+bug/22220).

  [ Frans Pop ]
  * Add support for detecting sbus devices on sparc now that we are not using
    discover anymore. May need to be extended to also add the drivers to the
    initramfs initrd or /etc/modules. Uses prtconf from sparc-utils-udeb.

  [ Updated translations ]
  * Catalan (ca.po) by Jordi Mallach
  * Spanish (es.po) by Javier Fernández-Sanguino Peña
  * Finnish (fi.po) by Tapio Lehtonen
  * Japanese (ja.po) by Kenshi Muto
  * Latvian (lv.po) by Aigars Mahinovs
  * Punjabi (Gurmukhi) (pa_IN.po) by Amanpreet Singh Alam
  * Romanian (ro.po) by Eddy Petrişor
  * Slovak (sk.po) by Peter Mann
  * Slovenian (sl.po) by Jure Cuhalev
  * Albanian (sq.po) by Elian Myftiu
  * Turkish (tr.po) by Recai Oktaş
  * Vietnamese (vi.po) by Clytie Siddall

 -- Frans Pop <email address hidden> Wed, 1 Feb 2006 15:40:33 +0100

Hi, I can confirm the same kernel panic on an Adaptec 2000S I2O controller with the standard Breezy 5.10 install CD.

Dapper kernel side is fixed according to Ben Collins, only hw-detect is still broken, opening a task for it.

Colin, is the hw-detect fix for this backportable easily for dapper?

Easy and safe to fix according to Colin, just needs testing.

hw-detect 1.32ubuntu8 uploaded to dapper-proposed for approval. This will also need a trivial debian-installer upload afterwards to rebuild the initrd against it.

Accepted into dapper-proposed, thank you!

Can we actually build d-i in -proposed and then copy it over to -updates somehow?

hw-detect (1.32ubuntu8) dapper-proposed; urgency=low

  * Backport from trunk (LP: #22220):
    - Offer disk devices from drivers/message/fusion and
      drivers/message/i2o.

 -- Colin Watson <email address hidden> Tue, 07 Aug 2007 10:31:38 +0100

We should be able to copy d-i from -proposed, but it will require some manual work to copy the image directories under main/installer-*.

(debian-installer 20051026ubuntu36.7 uploaded to -proposed and waiting for acceptance.)

Hi Colin,

Colin Watson [2007-08-10 21:10 -0000]:
> We should be able to copy d-i from -proposed, but it will require some
> manual work to copy the image directories under main/installer-*.

Splendid.

> (debian-installer 20051026ubuntu36.7 uploaded to -proposed and waiting
> for acceptance.)

Accepted, thanks!

Copied to dapper-updates, since we need to have it there for netinstall testing.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.