BUG: Current 2.5-BK tree dies on boot!

BUG: Current 2.5-BK tree dies on boot!

Post by Anton Blanchar » Fri, 20 Sep 2002 08:10:04



Quote:> This is without preempt. I tried both with and without SMP, with and without
> large TLB pages, with and without pte highmem, all die in the same place.

I needed this to boot the latest BK on my ppc64 box. The question is
why we are suddenly ending up with prev == NULL, hch mentioned his
patch was only a cleanup in this area.

Anton

===== mm/mprotect.c 1.16 vs edited =====
--- 1.16/mm/mprotect.c  Wed Sep 18 04:05:14 2002

                }
        }

-       if (next && prev->vm_end == next->vm_start &&
+       if (prev && next && prev->vm_end == next->vm_start &&
                        can_vma_merge(next, prev->vm_flags) &&
                        !prev->vm_file && !(prev->vm_flags & VM_SHARED)) {
                spin_lock(&prev->vm_mm->page_table_lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Jens Axbo » Fri, 20 Sep 2002 17:50:07



> This is without preempt. I tried both with and without SMP, with and without
> large TLB pages, with and without pte highmem, all die in the same place.

You have highmem, and bouncing does not get correctly enabled on the ide
drives. This, in combination with broken bouncing (woops), will probably
make it die fairly quickly.

I attach two patches, one fixes the bouncing, the other fixes IDE bounce
enable.

--
Jens Axboe

  ide-high-2
2K Download

  bounce-end_io-2
2K Download

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Anton Altaparmako » Fri, 20 Sep 2002 18:40:05




> > This is without preempt. I tried both with and without SMP, with and
> without
> > large TLB pages, with and without pte highmem, all die in the same place.

>You have highmem, and bouncing does not get correctly enabled on the ide
>drives. This, in combination with broken bouncing (woops), will probably
>make it die fairly quickly.

>I attach two patches, one fixes the bouncing, the other fixes IDE bounce
>enable.

BK as of this morning already contains the bounce patch, so I only applied
the IDE bounce enable and it worked fine. - Thanks!

Note there is something odd wrt IDE initialization. The driver seems to be
trying to initialize twice and there quite a few messages output which
don't reflect reality (probably a consequence of the double init). For
example it says DMA disabled but checking with hdparm and in /proc/ide/via
DMA is enabled just fine. And it says neither IDE port enabled (BIOS) which
isn't true either.

Here is the current IDE output on boot:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
     ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
     ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: IC35L040AVER07-0, ATA DISK drive
hda: DMA disabled
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: LITE-ON LTR-12102B, ATAPI CD/DVD-ROM drive
hdd: Maxtor 90288D2, ATA DISK drive
hdc: DMA disabled
hdd: DMA disabled
ide1 at 0x170-0x177,0x376 on irq 15
VP_IDE: IDE controller at PCI slot 00:07.1

VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
VP_IDE: port 0x01f0 already claimed by ide0
VP_IDE: port 0x0170 already claimed by ide1
VP_IDE: neither IDE port enabled (BIOS)
hda: host protected area => 1
hda: 80418240 sectors (41174 MB) w/1916KiB Cache, CHS=5005/255/63, UDMA(100)
  hda: hda1 hda2 < hda5 hda6 hda7 >
hdd: host protected area => 1
hdd: 5627664 sectors (2881 MB) w/256KiB Cache, CHS=5583/16/63, UDMA(33)
  hdd: hdd1 hdd2 < hdd5 hdd6 hdd7 hdd8 hdd9 hdd10 >
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
   Vendor: LITE-ON   Model: LTR-12102B        Rev: NS1D
   Type:   CD-ROM                             ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12

But it all seems to works just fine, despite the slightly confused init...

Best regards,

         Anton

--
   "I haven't lost my mind... it's backed up on tape." - Peter da Silva
--

Linux NTFS Maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Jens Axbo » Fri, 20 Sep 2002 18:50:07





> >> This is without preempt. I tried both with and without SMP, with and
> >without
> >> large TLB pages, with and without pte highmem, all die in the same place.

> >You have highmem, and bouncing does not get correctly enabled on the ide
> >drives. This, in combination with broken bouncing (woops), will probably
> >make it die fairly quickly.

> >I attach two patches, one fixes the bouncing, the other fixes IDE bounce
> >enable.

> BK as of this morning already contains the bounce patch, so I only applied
> the IDE bounce enable and it worked fine. - Thanks!

Good

Quote:> Note there is something odd wrt IDE initialization. The driver seems to be
> trying to initialize twice and there quite a few messages output which
> don't reflect reality (probably a consequence of the double init). For
> example it says DMA disabled but checking with hdparm and in /proc/ide/via
> DMA is enabled just fine. And it says neither IDE port enabled (BIOS) which
> isn't true either.

Yes you are right, it does seem to try and init twice. Wonder why. I'll
take a look at that.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Jens Axbo » Fri, 20 Sep 2002 19:20:06



> > Note there is something odd wrt IDE initialization. The driver seems to be
> > trying to initialize twice and there quite a few messages output which
> > don't reflect reality (probably a consequence of the double init). For
> > example it says DMA disabled but checking with hdparm and in /proc/ide/via
> > DMA is enabled just fine. And it says neither IDE port enabled (BIOS) which
> > isn't true either.

> Yes you are right, it does seem to try and init twice. Wonder why. I'll
> take a look at that.

Seems to be ide probe calling the pci probe functions, and then they get
called by the pci layer later when they register. Dunno what the best
way to handle this is. Alan quotes ordering constraints as the reason.
Then maybe the easiest fix is to just do

chipset_init(bla)
{
        if (chipset already setup)
                return;

        do_init();

Quote:}

Alan?

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Alan Co » Fri, 20 Sep 2002 20:00:10



> Seems to be ide probe calling the pci probe functions, and then they get
> called by the pci layer later when they register. Dunno what the best
> way to handle this is. Alan quotes ordering constraints as the reason.
> Then maybe the easiest fix is to just do

Something is very wrong if they initialize twice. Hacking chipset_init
is not a fix its an ugly hack.

They should end up on the ide queue to init, then transfer to the core
PCI hotplug layer. The hotplug layer won't call the setups again because
the device is already owned by the driver that grabbed it.

In 2.4 at least pci_register_driver checks that it doesnt do that

    pci_for_each_dev(dev) {
                if (!pci_dev_driver(dev))
                        count += pci_announce_device(drv, dev);
        }

2.5 should do the same

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Jens Axbo » Fri, 20 Sep 2002 20:20:07




> > Seems to be ide probe calling the pci probe functions, and then they get
> > called by the pci layer later when they register. Dunno what the best
> > way to handle this is. Alan quotes ordering constraints as the reason.
> > Then maybe the easiest fix is to just do

> Something is very wrong if they initialize twice. Hacking chipset_init
> is not a fix its an ugly hack.

True :-)

Quote:> They should end up on the ide queue to init, then transfer to the core
> PCI hotplug layer. The hotplug layer won't call the setups again because
> the device is already owned by the driver that grabbed it.

> In 2.4 at least pci_register_driver checks that it doesnt do that

>     pci_for_each_dev(dev) {
>                 if (!pci_dev_driver(dev))
>                         count += pci_announce_device(drv, dev);
>         }

> 2.5 should do the same

2.5 is reorged big time it seems, pci_register_driver() ->
drier_attach() -> do_driver_attach() -> found_match() calls ->probe()
unconditionally...

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Alan Co » Fri, 20 Sep 2002 22:30:19



> 2.5 is reorged big time it seems, pci_register_driver() ->
> drier_attach() -> do_driver_attach() -> found_match() calls ->probe()
> unconditionally...

That would appear to be a bug in the 2.5 driver layer then. I'd suggest
fixing it there. Attempting to probe a device that already has a driver
attached to it doesn't seem to make sense.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Jens Axbo » Fri, 20 Sep 2002 22:40:05




> > 2.5 is reorged big time it seems, pci_register_driver() ->
> > drier_attach() -> do_driver_attach() -> found_match() calls ->probe()
> > unconditionally...

> That would appear to be a bug in the 2.5 driver layer then. I'd suggest
> fixing it there. Attempting to probe a device that already has a driver
> attached to it doesn't seem to make sense.

Agree. Pat?

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Patrick Moche » Sat, 21 Sep 2002 02:50:07





> > > 2.5 is reorged big time it seems, pci_register_driver() ->
> > > drier_attach() -> do_driver_attach() -> found_match() calls ->probe()
> > > unconditionally...

> > That would appear to be a bug in the 2.5 driver layer then. I'd suggest
> > fixing it there. Attempting to probe a device that already has a driver
> > attached to it doesn't seem to make sense.

> Agree. Pat?

Yes, and that's the way it's set up: we check if the device has a driver
before we bind to it. However, dev->driver doesn't get set before the
device is registered with the core for PCI devices. That's fixed easily
enough.

But, I'm a bit confused on where this is happening. The PCI layer will
probe for devices before any drivers are registered. The drivers are
registered, then they're attached to devices that were already discovered.
So, how are they getting init'ed twice?

        -pat

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

BUG: Current 2.5-BK tree dies on boot!

Post by Alan Co » Sat, 21 Sep 2002 03:10:03



> Yes, and that's the way it's set up: we check if the device has a driver
> before we bind to it. However, dev->driver doesn't get set before the
> device is registered with the core for PCI devices. That's fixed easily
> enough.

> But, I'm a bit confused on where this is happening. The PCI layer will
> probe for devices before any drivers are registered. The drivers are
> registered, then they're attached to devices that were already discovered.
> So, how are they getting init'ed twice?

The IDE layer has to preserve ordering. It does that by doing pci device
ordered scans at boot then handing the driver registrations over to the
pci hotplug layer for new inserts.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. 2.5.bk no longer boots from NFS root after bk pull this morning

2.5 has been booting fine over NFS for ages, but after getting latest
stuff with a bk pull this morning, it no longer works

Do I need to do something new, or has something busted?

The relevant bits from dmesg are

Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 10.0.0.1, my address is 10.0.0.103
IP-Config: Complete:
       device=eth0, addr=10.0.0.103, mask=255.255.0.0, gw=10.0.0.1,
      host=hal3.office, domain=office, nis-domain=(none),
      bootserver=10.0.0.1, rootserver=10.0.0.1,
rootpath=/eboot/slash/hal.office
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 10.0.0.1
Looking up port of RPC 100005/1 on 10.0.0.1
net/sunrpc/rpc_pipe.c: rpc_lookup_path failed to find path
/mount/clntc398a880
RPC: Couldn't create pipefs entry /mount/clntc398a880
Root-NFS: Server returned error -13 while mounting /eboot/slash/hal.office
VFS: Unable to mount root fs via NFS, trying floppy.
Kernel panic: VFS: Unable to mount root fs on 02:00

Andrew Walrond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. FTP to Directory

3. timer hang with current 2.5 BK

4. PPP and ProxyARP

5. fix 3c59x for current 2.5-bk

6. How to test string for pattern

7. 2.5.xx (BK current) hangs executing rpcinfo

8. dumb bootrecord

9. EHCI Kernel panic on current BK 2.5

10. 2.5 bk current ohci1394 breakage

11. Compile fix for current 2.5 BK.

12. DAC960 breakage, 2.5 bk current

13. compile problem in current BK 2.5