(sorry to spam everyone, but I can't seem to reply to this
message and have it appear on lkml)
On Thu, 6 Jul 2006 23:44:25 +0200 J.A. Magallón wrote:
> On Thu, 6 Jul 2006 16:48:02 +0200, "J.A. Magallón" <[email protected]> wrote:
>
> > On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <[email protected]> wrote:
> >
> > > On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <[email protected]> wrote:
> > >
> > >
> > > This a shot till I can try to get a full dmesg.
> > >
> > > http://belly.cps.unizar.es/~magallon/tmp/shot.jpg
> > >
> > > Anyways, what I wanted to point above was that previous kernels talk
> > > about 'sda1(8,1)', and newer use 'dev(8,19)'.
> > > Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ?
> > >
> >
> > Hey !!. I disabled md and usb to get more useful messages in my screen, and
> > now I have realized that libata is managing my IDE drive !! And I did not
> > boot with any 'libata.atapi_enable'....
> >
> > In -mm1,
> > sda -> 200Gb sata
> > hda -> HL-DT-ST DVDRAM GSA-4120B
> > hdb -> (zip drive)
> > hdc -> 120Gb ide
> > hdd -> DVD-ROM
> >
> > In -mm6,
> >
> > sda -> (zip drive) ?
> > sdb -> 120Gb
> > sdc -> 200Gb
> >
>
> Well, booting onto sdc1 let me get to single user mode at least so I got
> a full dmesg. Relevant parts for -mm1 and -mm6 are below (if you want it
> full I can provide). Basically it looks like libata 2.0 by default handles
> PATA drives. This can break a lot of systems. In my opinion, PATA hosts
> should be detected _after_ real sata hosts in the same chipset (now it
> looks like its done _before_). What is handled by IDE will break anyways,
> but this way at least real SATA will stay at the same /dev/sdX devices.
>
> -mm1:
> ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> ICH5: IDE controller at PCI slot 0000:00:1f.1
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
>
> -mm6:
>
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
Yep, adding all of the libata-pata drivers mucked up the
/dev/sd* boot order. :(
Perhaps they should follow all of the SATA drivers. ?
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
