Disks on internal SCSI bus offlined during Feisty boot, no I/O thereafter

Bug #118319 reported by Tye
10
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Undecided
Unassigned
linux-source-2.6.20 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: linux-image-2.6.20-16-powerpc

On my PowerPC Mac with an internal Fast SCSI-2 bus built-in on the motherboard (uses 'mesh' driver as do all pre-IDE Macs), the Feisty kernel (2.6.20-series) during boot detects and then promptly offlines all except one SCSI device on the bus, out of 3 total hard disk drives and 2 CD drives, and leaves those devices offlined in the post-booted system. This happens both during a Feisty install (clean install tested via both the Netboot and CD methods, altho' the CD installer stops at failing to detect a CD) and also in the complete Feisty system as installed on that one accessible drive

In the past, Edgy was able to detect and access all drives flawlessly, as do Debian Sarge, Etch and Lenny; thus, it appears that something different about Feisty has broken what was working perfectly before. I might conjecture that it may have something do with the 'mesh' driver's interface to the kernel, or perhaps the initrd is misloading something, or loading a conflicting module, or loading modules in a problematic order?

The lone disk that ~is~ left accessible to Feisty is different in one obvious way: it is a Wide-Fast SCSI drive connected to the internal Fast SCSI-2 bus by a small port-converter adapter board (which has no active circuitry to speak of, just converts pinouts from the Micro-D port on the Wide drive to the 50-pin SCSI ribbon connector on the bus). It also appears to have been originally mfd for use in Sun applications, if the distant *nix-family association there may (not) be at all relevant to why this one works and all the others don't. This drive (at SCSI ID:1) and its partitions show up at /dev/sdc[1-7] during install (changes to /dev/sdb[1-7] in the installed system), which indicates that Feisty is at least detecting the presence of an sda and sdb (also sdd), albeit without any partitions, before it offlines them for any I/O access. Physically unplugging this drive does not restore access to any of the other devices; removing it results in ~no~ drives accessible to Feisty.

Of the two PCI cards in my system (one USB and one FireWire), unplugging all peripherals from those cards made no difference, nor did swapping their slot-order around, nor did physically removing either or both cards. Thus, it appears PCI is not relevant to this issue. I have read one report that using a SCSI controller PCI card worked fine, which reinforces my suspicion that the Mac internal SCSI bus and its 'mesh' driver module, or the loading of modules, are still the most likely places to investigate.

dmesg attachment to follow; relevant lines look like this contiguous excerpt:

mesh: target 0 synchronous at 5.0 MB/s
sd 0:0:0:0: scsi: Device offlined - not ready after error recovery
sd 0:0:0:0: rejecting I/O to offline device

Revision history for this message
Tye (webmaster-htdoctor) wrote :
Revision history for this message
Tye (webmaster-htdoctor) wrote :
Revision history for this message
Pete (pxw) wrote :

I confirm the same "offlined" scsi bug with ubuntu704 on an OldWorld powermac 7300/180, resulting in failure to mount cdrom and one hard disk.

Comparison with ubuntu 610 installer shown in attached listings of dmesg, /proc/scsi/scsi and /dev/s*

Revision history for this message
Pete (pxw) wrote :
Revision history for this message
Tye (webmaster-htdoctor) wrote :

I notice you have partitions /dev/sdc[1-7] listed in Feisty, but no partitions on /dev/sd[abd]. If you could dmesg | grep for lines matching 'scsi' OR 'mesh' (sorry, don't know the correct grep syntax for this) -- or maybe just do 'dmesg | grep -A1 -B1 scsi' -- that could give clearer context of what's happening at boot.

I bet if you'd used the netboot initrd for Feisty, the partitioner would offer you /dev/sdc (but nothing else) for partitioning and installation. Apparently it's counting the external SCSI as Bus 0, so the Zip drive got /dev/sda, then the internal IBM drive ID:0 got /dev/sdb, which means your internal Quantum drive (heh, sounds like something from Star Trek!) at ID:1 would be the accessible one at /dev/sdc? If you installed, I reckon the assignments of sd[a-d] would change in the installed system. Any chance that Quantum disk is an adapter-converted Wide device like my Seagate?

Revision history for this message
Pete (pxw) wrote :
Download full text (4.6 KiB)

What you see is what you get.

The only drive that feisty installer can mount is /dev/sdc.
feisty does not make nodes for partitions which exist on the other drives.
and they are not available in feisty.

internal scsi bus (ID) drivename.
(0) sdb1-8 IBM 4GB, (1) sdc1-7 Quantum 2GB,(3) scd0 cdrom
external scsi
(5) sda1-5 zip drive 98MB.
external scsi-usb
(0) sdd Flash stick

feisty installer - only sdc is available for install
scsi ID is (1). The drive is standard configuration interface.

ls -l /dev/s*

brw-rw---- 1 root root 11, 0 Jun 3 16:28 /dev/scd0
brw-rw---- 1 root root 8, 0 Jun 3 16:28 /dev/sda
brw-rw---- 1 root root 8, 16 Jun 3 16:28 /dev/sdb
brw-rw---- 1 root root 8, 32 Jun 3 16:28 /dev/sdc
brw-rw---- 1 root root 8, 33 Jun 3 16:28 /dev/sdc1
brw-rw---- 1 root root 8, 34 Jun 3 16:28 /dev/sdc2
brw-rw---- 1 root root 8, 35 Jun 3 16:28 /dev/sdc3
brw-rw---- 1 root root 8, 36 Jun 3 16:28 /dev/sdc4
brw-rw---- 1 root root 8, 37 Jun 3 16:28 /dev/sdc5
brw-rw---- 1 root root 8, 38 Jun 3 16:28 /dev/sdc6
brw-rw---- 1 root root 8, 39 Jun 3 16:28 /dev/sdc7
brw-rw---- 1 root root 8, 48 Jun 3 16:28 /dev/sdd
crw-rw---- 1 root root 21, 0 Jun 3 16:28 /dev/sg0
crw-rw---- 1 root root 21, 1 Jun 3 16:28 /dev/sg1
crw-rw---- 1 root root 21, 2 Jun 3 16:28 /dev/sg2
crw-rw---- 1 root root 21, 3 Jun 3 16:28 /dev/sg3
crw-rw---- 1 root root 21, 4 Jun 3 16:28 /dev/sg4
crw-rw---- 1 root root 10, 231 Jun 3 16:27 /dev/snapshot

edgy installer - all drives can be mounted, available.

 ls -l /dev/s*

brw-rw---- 1 root root 11, 0 Jun 3 19:48 /dev/scd0
brw-rw---- 1 root root 8, 0 Jun 3 19:48 /dev/sda
brw-rw---- 1 root root 8, 1 Jun 3 19:48 /dev/sda1
brw-rw---- 1 root root 8, 2 Jun 3 19:48 /dev/sda2
brw-rw---- 1 root root 8, 3 Jun 3 19:48 /dev/sda3
brw-rw---- 1 root root 8, 4 Jun 3 19:48 /dev/sda4
brw-rw---- 1 root root 8, 5 Jun 3 19:48 /dev/sda5
brw-rw---- 1 root root 8, 16 Jun 3 19:48 /dev/sdb
brw-rw---- 1 root root 8, 17 Jun 3 19:48 /dev/sdb1
brw-rw---- 1 root root 8, 18 Jun 3 19:48 /dev/sdb2
brw-rw---- 1 root root 8, 19 Jun 3 19:48 /dev/sdb3
brw-rw---- 1 root root 8, 20 Jun 3 19:48 /dev/sdb4
brw-rw---- 1 root root 8, 21 Jun 3 19:48 /dev/sdb5
brw-rw---- 1 root root 8, 22 Jun 3 19:48 /dev/sdb6
brw-rw---- 1 root root 8, 23 Jun 3 19:48 /dev/sdb7
brw-rw---- 1 root root 8, 24 Jun 3 19:48 /dev/sdb8
brw-rw---- 1 root root 8, 32 Jun 3 19:48 /dev/sdc
brw-rw---- 1 root root 8, 33 Jun 3 19:48 /dev/sdc1
brw-rw---- 1 root root 8, 34 Jun 3 19:48 /dev/sdc2
brw-rw---- 1 root root 8, 35 Jun 3 19:48 /dev/sdc3
brw-rw---- 1 root root 8, 36 Jun 3 19:48 /dev/sdc4
brw-rw---- 1 root root 8, 37 Jun 3...

Read more...

Revision history for this message
Pete (pxw) wrote :

I added a copy of the pm7300 syslog from the feisty installer for the record. The story is in there somewhere, just needs looking at by someone very familiar with initrd I think.

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 bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. 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
Pete (pxw) wrote :

This bug was fixed for me in hardy with kernel -2.6.24-16-powerpc and now
with -2.6.25-1-powerpc, currently latest binary available at ports.ubuntu.com for powerpc.
I think it may have been fixed in gutsy.

Note that the bug related to OldWorld macs with scsi.

Will be very interested to try linux-image 2.6.27-x as soon as a binary powerpc package is available.

Very impressed to see continuing compatibility for old mac ppcs (1998).

/proc/cpuinfo

processor : 0
cpu : 604e
clock : 180.000000MHz
revision : 2.4 (pvr 0009 0204)
bogomips : 22.46
timebase : 11250250
platform : PowerMac
machine : Power Macintosh
motherboard : AAPL,7500 MacRISC
detected as : 16 (PowerMac 7500)
pmac flags : 00000000
L2 cache : 256K unified
pmac-generation : OldWorld

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

Thanks PeterXw,

I'm going to tentatively mark this "Fix Released" then. If you notice any regressions once you are able to teset 2.6.27, feel free to reopen this by setting the status back to "New". Also, Tye, since you are the original bug reporter, if this is not resolved for you with Hardy or Intrepid please feel free to set the status back to "New". Thanks.

Changed in linux:
status: Incomplete → Fix Released
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.