Dapper cciss driver doesn't handle over 2TB devices.

Bug #135075 reported by Niklas Edmundsson
4
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: linux-image-2.6.15-28-amd64-server

The Dapper cciss driver doesn't handle devices larger than 2TB in size.

This is becoming a real problem in environments like ours where we prefer having all our servers on the Ubuntu LTS track. For example, the HP DL320s with 12 large SATA drives is a rather cheap box that's hits this limit really hard.

Given that people on the LTS track prefers stable environments I understand if you don't want to upgrade the cciss driver in Dapper, but for those who needs it a newer version that provides this functionality should be available.

I have hacked the cciss 2.6.18-5 driver (available from http://cciss.sourceforge.net/) so it compiles cleanly and seems to work with Dapper, no warranties but it at least seems to work. I'll try to attach the tarball to the bug if it's possible.

One solution might be to package this and having it divert the cciss.ko available in the kernel package. I'm sure there are lots of other options too. In any case, people really want to be able to install a package that solves the problem and not having to track stray modules.

In any case, Ubuntu LTS needs to have some way to handle this class of problems in order to be considered a viable long-term server distribution.

Revision history for this message
Niklas Edmundsson (niklas-edmundsson) wrote :

cciss 2.6.18-5 driver (available from http://cciss.sourceforge.net/) hacked so it compiles cleanly on Ubuntu Dapper AMD64. Only tested on Dapper AMD64 in a HP DL320s with SmartArray P400 controller and a raid6 set consisting of 11x750GB SATA drives.

To build:
apt-get install module-assistant
m-a prepare
mkdir /tmp/dir
cd /tmp/dir
tar -xzf /path/to/cciss-2.6.18-5_dapper.tar.gz
make

NOTE! IF SOMETHING GOES WRONG YOUR SYSTEM MIGHT NOT BOOT. YOU HAVE BEEN WARNED.
To install:
cp /lib/modules/`uname -r`/kernel/drivers/block/cciss.ko /lib/modules/`uname -r`/kernel/drivers/block/cciss.ko.bak
cp cciss.ko /lib/modules/`uname -r`/kernel/drivers/block/cciss.ko
depmod -a
update-initramfs -u

Revision history for this message
Niklas Edmundsson (niklas-edmundsson) wrote :

Debian packaging of the cciss 2.6.18-5 driver.

This is the driver above, I have only added some packaging to produce a source package that can be used by module-assistant. The module-assistant target also produces a meta package which depends on the latest (ie. newly built) module package.

The module package diverts cciss.ko and replaces it with the updated version, and updates module dependencies and initramfs.

It seems to work for us, hopefully someone else finds it useful.

Revision history for this message
Gareth Fitzworthington (mapping-gp-deactivatedaccount) wrote :

Confirming.
Looks like 2TB fix made it into Linux v2.6.21-rc3. See below link:
http://lkml.org/lkml/2007/3/6/565

Now upto Kernel Team to decide upon "Fix" or "Won't Fix".
If anyone is able to test this against Gutsy and/or Hardy then please report results on this issue.
Thanks for the report.

Changed in linux-source-2.6.15:
assignee: nobody → kernel-team
status: New → Confirmed
Changed in linux-source-2.6.15:
assignee: kernel-team → ubuntu-kernel-team
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Seth Chandler (sethbc) wrote :

I'm still having this problem on hardy running a P400 with the newest firmware and 5 1TB sata drives in a RAID 5 array.

Revision history for this message
Seth Chandler (sethbc) wrote :

correction - it does work on 2tb+ partitions. I had to relabel the disk.

Changed in linux-source-2.6.15:
assignee: ubuntu-kernel-team → colin-king
Changed in linux-source-2.6.15:
assignee: colin-king → nobody
Revision history for this message
Launchpad Janitor (janitor) wrote : This bug is now reported against the 'linux' package

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this linux-source-2.6.15 kernel bug to the new "linux" package. We appreciate your patience and understanding as we make this transition. Also, if you would be interested in testing the upcoming Intrepid Ibex 8.10 release, it is available at http://www.ubuntu.com/testing . Please let us know your results. Thanks!

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
Seth Chandler (sethbc) wrote :

This works under both Hardy (2.6.24-21-generic) and Intrepid.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Per the last comment I'm marking this "Fix Released". Thanks.

Changed in linux:
status: Triaged → Fix Released
Revision history for this message
Niklas Edmundsson (niklas-edmundsson) wrote :

That's funny, since the bug is that the cciss-driver on _dapper_ doesn't support large devices.

The main issue here is what kind of support we really can expect for the LTS releases, you should keep in mind that the LTS-releases are the ones mainly deployed in larger environments where you don't want diverging installations all over the place. Support for newer hardware is essential to be able to use an LTS release for a longer period where new hardware acquisitions are likely to be made.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.