Re: 2.6.8.1-mm2 (nvidia breakage)

Re: 2.6.8.1-mm2 (nvidia breakage)

[Bjorn Helgaas]

Hi Michael,

> kernel 2.6.8.1-mm2 booting here with acpi_os_name=Linux and pci=routeirq.
> Without pci=routeirq hangs at startx (nvidia).

I assume this problem is with the Nvidia binary-only driver?  My guess
is that the driver doesn't call pci_enable_device() before using
pci_dev->irq.  I don't have source for that driver, so I can't verify
this.

If the driver is from Nvidia, please contact their technical support
and request that they fix the driver.  I can help explain the issue if
necessary.

I also noticed this in your dmesg:

	floppy: controller ACPI FDC0 at I/O 0x3f7-0x3f7 irq 6 dma channel 2
	Using anticipatory io scheduler
	Floppy drive(s): fd0 is 1.44M
	floppy0: no floppy controllers found

I hope that you have the floppy controller disabled in your BIOS,
or at least have no floppy drives connected.  Can you confirm that?
I expected that ACPI would not report the controller at all in such
a case, but it looks like yours reports the controller with a zero-
length I/O port region.  I probably should check for that.

If you do have a floppy drive, it probably doesn't work anymore
unless you specify "floppy=no_acpi".  If this is the case, we'll
have to figure out a quirk or something to make it work.

Thanks for the testing report!

Re: 2.6.8.1-mm2 (nvidia breakage)

[Alan Cox]

On Iau, 2004-08-19 at 17:51, Bjorn Helgaas wrote:
> I assume this problem is with the Nvidia binary-only driver?  My guess
> is that the driver doesn't call pci_enable_device() before using
> pci_dev->irq.  I don't have source for that driver, so I can't verify
> this.

An obvious test would be for someone with an Nvidia to write a little
module that does nothing but pci_enable_device it. Load and unload that
then see what happens

Re: 2.6.8.1-mm2 (nvidia breakage)

[Terence Ripperda]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]


the original bug report was during module load time, when we're
probing our devices via the pci_driver's probe callback. this is well
before we hook up interrupts or do anything in our closed source code.

I'm attaching a trimmed down version of our driver that pretty much
only does this probe (complete source is included). I don't know if
this will reproduce the original bug or not.

Let me know if I can help anymore.

Thanks,
Terence

On Thu, Aug 19, 2004 at 06:53:56PM +0100, alan@lxorguk.ukuu.org.uk wrote:
> On Iau, 2004-08-19 at 17:51, Bjorn Helgaas wrote:
> > I assume this problem is with the Nvidia binary-only driver?  My guess
> > is that the driver doesn't call pci_enable_device() before using
> > pci_dev->irq.  I don't have source for that driver, so I can't verify
> > this.
> 
> An obvious test would be for someone with an Nvidia to write a little
> module that does nothing but pci_enable_device it. Load and unload that
> then see what happens
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[-- Attachment #2: nv_mini.tar.gz --]
[-- Type: application/octet-stream, Size: 7676 bytes --]

Re: 2.6.8.1-mm2 (nvidia breakage)

[Bjorn Helgaas]

On Thursday 19 August 2004 3:51 pm, Terence Ripperda wrote:
> the original bug report was during module load time, when we're
> probing our devices via the pci_driver's probe callback. this is well
> before we hook up interrupts or do anything in our closed source code.
> 
> I'm attaching a trimmed down version of our driver that pretty much
> only does this probe (complete source is included). I don't know if
> this will reproduce the original bug or not.

Thanks, this is enough to show the problem:

	nv_kern_probe(struct pci_dev *dev, ...)
	{
		...
		nv->interrupt_line = dev->irq;
		...
		if (pci_enable_device(dev) != 0)

The driver is looking at dev->irq before calling pci_enable_device().
But dev->irq is not necessarily initialized before pci_enable_device().

I'm not a PCI expert, but I'm not sure you should be looking at
all the other dev->resource[] stuff before pci_enable_device()
either.  Most of the "modern" drivers in the tree seem to do
pci_enable_device() very early in the probe() function, i.e., 
see tg3.c.

Re: 2.6.8.1-mm2 (nvidia breakage)

[Alan Cox]

On Iau, 2004-08-19 at 23:03, Bjorn Helgaas wrote:
> The driver is looking at dev->irq before calling pci_enable_device().
> But dev->irq is not necessarily initialized before pci_enable_device().
> 
> I'm not a PCI expert, but I'm not sure you should be looking at
> all the other dev->resource[] stuff before pci_enable_device()
> either. 

Indeed. pci_enable_device may assign the actual BARs as well as the
interrupt lines to the device. I suspect its harmless here because the
base video device is BIOS configured.

Re: 2.6.8.1-mm2 (nvidia breakage)

[Terence Ripperda]

Thanks Bjorn,

I'll move that call to pci_enable_device to earlier in the probe call.

but in Kevin's original email, he's hitting an oops within the
pci_enable_device call. is that likely due to pci_enable_device being
called late?

Thanks,
Terence

On Thu, Aug 19, 2004 at 04:03:55PM -0600, bjorn.helgaas@hp.com wrote:
> On Thursday 19 August 2004 3:51 pm, Terence Ripperda wrote:
> > the original bug report was during module load time, when we're
> > probing our devices via the pci_driver's probe callback. this is well
> > before we hook up interrupts or do anything in our closed source code.
> > 
> > I'm attaching a trimmed down version of our driver that pretty much
> > only does this probe (complete source is included). I don't know if
> > this will reproduce the original bug or not.
> 
> Thanks, this is enough to show the problem:
> 
> 	nv_kern_probe(struct pci_dev *dev, ...)
> 	{
> 		...
> 		nv->interrupt_line = dev->irq;
> 		...
> 		if (pci_enable_device(dev) != 0)
> 
> The driver is looking at dev->irq before calling pci_enable_device().
> But dev->irq is not necessarily initialized before pci_enable_device().
> 
> I'm not a PCI expert, but I'm not sure you should be looking at
> all the other dev->resource[] stuff before pci_enable_device()
> either.  Most of the "modern" drivers in the tree seem to do
> pci_enable_device() very early in the probe() function, i.e., 
> see tg3.c.

Re: 2.6.8.1-mm2 (nvidia breakage)

[Bjorn Helgaas]

On Thursday 19 August 2004 4:58 pm, Terence Ripperda wrote:
> I'll move that call to pci_enable_device to earlier in the probe call.

Thanks.

> but in Kevin's original email, he's hitting an oops within the
> pci_enable_device call. is that likely due to pci_enable_device being
> called late?

I don't seem to have an email from Kevin.  Can you forward it to
me?  The thread I know about started with mail from Michael Geithe
that Andrew Morton forwarded to me:

> kernel 2.6.8.1-mm2 booting here with acpi_os_name=Linux and pci=routeirq.
> Without pci=routeirq hangs at startx (nvidia).

I didn't see any oops there.

Re: 2.6.8.1-mm2 (nvidia breakage)

[Michael Geithe]

On Friday 20 August 2004 17:53, you wrote:

> I didn't see any oops there.

Hi Bjorn,

i searched my logs and found that.

Aug 20 18:03:53 stargate kernel: irq 16: nobody cared!
Aug 20 18:03:53 stargate kernel:  [<c0106520>] __report_bad_irq+0x24/0x7b
Aug 20 18:03:53 stargate kernel:  [<c01065f9>] note_interrupt+0x64/0x88
Aug 20 18:03:53 stargate kernel:  [<c010694d>] do_IRQ+0x1af/0x1fb
Aug 20 18:03:53 stargate kernel:  [<c0104890>] common_interrupt+0x18/0x20
Aug 20 18:03:53 stargate kernel: handlers:
Aug 20 18:03:53 stargate kernel: [<f9a11145>] (usb_hcd_irq+0x0/0x5d [usbcore])
Aug 20 18:03:53 stargate kernel: [<f9a11145>] (usb_hcd_irq+0x0/0x5d [usbcore])
Aug 20 18:03:53 stargate kernel: Disabling IRQ #16


-- 
Michael Geithe

-

Re: 2.6.8.1-mm2 (nvidia breakage)

[Terence Ripperda]

sure, I meant to include this link in the earlier email and forgot:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0408.1/0127.html

On Fri, Aug 20, 2004 at 09:53:11AM -0600, bjorn.helgaas@hp.com wrote:
> I don't seem to have an email from Kevin.  Can you forward it to
> me?  The thread I know about started with mail from Michael Geithe
> that Andrew Morton forwarded to me:

Re: 2.6.8.1-mm2 (nvidia breakage)

[Bjorn Helgaas]

On Thursday 19 August 2004 4:58 pm, Terence Ripperda wrote:
> but in Kevin's original email[1], he's hitting an oops within the
> pci_enable_device call. is that likely due to pci_enable_device being
> called late?

[1] http://www.uwsg.indiana.edu/hypermail/linux/kernel/0408.1/0127.html

Kevin, I suspect the oops you're seeing is due to the problem mentioned
here (add_pin_to_irq() is __init but shouldn't be):

    http://groups.google.com/groups?dq=&start=75&hl=en&lr=&ie=UTF-8&group=fa.linux.kernel&c2coff=1&selm=fa.j8igrci.1fgg680%40ifi.uio.no

Can you try Randy's patch without using "pci=routeirq" and see whether
it resolves the oops?  Of course, the nvidia driver still won't work
because it's looking at pci_dev->irq before calling pci_enable_device(),
but that's a separate issue.

Re: 2.6.8.1-mm2 (nvidia breakage)

[Terence Ripperda]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On Mon, Aug 23, 2004 at 09:30:18AM -0600, bjorn.helgaas@hp.com wrote:
> Of course, the nvidia driver still won't work
> because it's looking at pci_dev->irq before calling pci_enable_device(),
> but that's a separate issue.

as Alan pointed out, the video device is bios configured, so may not
be hit by this. nonetheless, we've applied a patch along these lines
to our internal codebase.

Thanks,
Terence


[-- Attachment #2: nv_enable_pci.patch --]
[-- Type: text/plain, Size: 3640 bytes --]

--- nv/nv.c	2004-08-23 13:58:15.000000000 -0500
+++ nv.new/nv.c	2004-08-23 13:58:35.000000000 -0500
@@ -1225,6 +1225,7 @@
         {
             nv_state_t *nv = NV_STATE_PTR(&nv_linux_devices[i]);
             release_mem_region(nv->bar.regs.address, nv->bar.regs.size);
+            pci_disable_device(nv_linux_devices[i].dev);
         }
     }
 
@@ -3516,6 +3517,28 @@
         return -1;
     }
 
+    // enable io, mem, and bus-mastering in pci config space
+    if (pci_enable_device(dev) != 0)
+    {
+        nv_printf(NV_DBG_ERRORS,
+            "NVRM: pci_enable_device failed, aborting\n");
+        return -1;
+    }
+
+    // request ownership of our bars
+    // keeps other drivers from banging our registers.
+    // only do this for registers, as vesafb requests our framebuffer and will
+    // keep us from working properly
+    if (!request_mem_region(dev->resource[0].start,
+                            dev->resource[0].end - dev->resource[0].start + 1,
+                            "nvidia"))
+    {
+        nv_printf(NV_DBG_ERRORS,
+            "NVRM: pci_request_regions failed, aborting\n");
+        goto err_disable_dev;
+    }
+    pci_set_master(dev);
+
     /* initialize bus-dependent config state */
     nvl = &nv_linux_devices[num_nv_devices];
     nv  = NV_STATE_PTR(nvl);
@@ -3545,7 +3568,7 @@
         nv_printf(NV_DBG_ERRORS, "NVRM: Please check your BIOS settings.         \n");
         nv_printf(NV_DBG_ERRORS, "NVRM: [Plug & Play OS   ] should be set to NO  \n");
         nv_printf(NV_DBG_ERRORS, "NVRM: [Assign IRQ to VGA] should be set to YES \n");
-        return -1;
+        goto err_zero_dev;
     }
 
     /* sanity check the IO apertures */
@@ -3569,39 +3592,9 @@
                 nv->bar.fb.address, nv->bar.fb.size);
         }
 
-        /* Clear out the data */
-        os_mem_set(nvl, 0, sizeof(nv_linux_state_t));
-
-        return -1;
-    }
-
-    // request ownership of our bars
-    // keeps other drivers from banging our registers.
-    // only do this for registers, as vesafb requests our framebuffer and will
-    // keep us from working properly
-    if (!request_mem_region(nv->bar.regs.address, nv->bar.regs.size, "nvidia"))
-    {
-        nv_printf(NV_DBG_ERRORS,
-            "NVRM: pci_request_regions failed, aborting\n");
-
-        /* Clear out the data */
-        os_mem_set(nvl, 0, sizeof(nv_linux_state_t));
-
-        return -1;
+        goto err_zero_dev;
     }
 
-    // enable io, mem, and bus-mastering in pci config space
-    if (pci_enable_device(dev) != 0)
-    {
-        nv_printf(NV_DBG_ERRORS,
-            "NVRM: pci_enable_device failed, aborting\n");
-
-        pci_release_regions(dev);
-        os_mem_set(nvl, 0, sizeof(nv_linux_state_t));
-
-        return -1;
-    }
-    pci_set_master(nvl->dev);
 
 #if defined(NV_BUILD_NV_PAT_SUPPORT)
     if (nvos_find_pci_express_capability(nvl->dev))
@@ -3618,13 +3611,7 @@
     if (nv->bar.regs.map == NULL)
     {
         nv_printf(NV_DBG_ERRORS, "NVRM: failed to map registers!!\n");
-
-        pci_release_regions(dev);
-
-        /* Clear out the data */
-        os_mem_set(nvl, 0, sizeof(nv_linux_state_t));
-
-        return -1;
+        goto err_zero_dev;
     }
     nv->flags |= NV_FLAG_MAP_REGS_EARLY;
 #endif
@@ -3641,6 +3628,15 @@
     num_nv_devices++;
 
     return 0;
+
+err_zero_dev:
+    os_mem_set(nvl, 0, sizeof(nv_linux_state_t));
+    release_mem_region(dev->resource[0].start,
+                       dev->resource[0].end - dev->resource[0].start + 1);
+
+err_disable_dev:
+    pci_disable_device(dev);
+    return -1;
 }
 
 int NV_API_CALL nv_no_incoherent_mappings

Re: 2.6.8.1-mm2 (nvidia breakage)

[Bjorn Helgaas]

On Monday 23 August 2004 1:01 pm, Terence Ripperda wrote:
> On Mon, Aug 23, 2004 at 09:30:18AM -0600, bjorn.helgaas@hp.com wrote:
> > Of course, the nvidia driver still won't work
> > because it's looking at pci_dev->irq before calling pci_enable_device(),
> > but that's a separate issue.
> 
> as Alan pointed out, the video device is bios configured, so may not
> be hit by this. nonetheless, we've applied a patch along these lines
> to our internal codebase.

To be pedantically clear about this, looking at pci_dev->irq before
calling pci_enable_device() is *guaranteed* to fail, regardless of
what the BIOS does.  So nvidia users will have to use "pci=routeirq"
until there's a new version of the nvidia driver.

Alan was specifically referring to the BAR configuration that may
be done by the BIOS.

I'm assuming your patch makes the driver call pci_enable_device()
before using either irq or BAR information.  That's the best way
to future-proof the driver.

Re: 2.6.8.1-mm2 (nvidia breakage)

[Terence Ripperda]

On Tue, Aug 24, 2004 at 09:26:42AM -0600, bjorn.helgaas@hp.com wrote:
> To be pedantically clear about this, looking at pci_dev->irq before
> calling pci_enable_device() is *guaranteed* to fail, regardless of
> what the BIOS does.  So nvidia users will have to use "pci=routeirq"
> until there's a new version of the nvidia driver.

ah, ok. thanks for clarifying.

> I'm assuming your patch makes the driver call pci_enable_device()
> before using either irq or BAR information.  That's the best way
> to future-proof the driver.

yes, that's exactly what we've done.

Thanks,
Terence

Re: 2.6.8.1-mm2 (nvidia breakage)

[Roland Dreier]

    Bjorn> To be pedantically clear about this, looking at
    Bjorn> pci_dev->irq before calling pci_enable_device() is
    Bjorn> *guaranteed* to fail, regardless of what the BIOS does.  So
    Bjorn> nvidia users will have to use "pci=routeirq" until there's
    Bjorn> a new version of the nvidia driver.

Terence, correct me if I'm wrong, but the change to add
pci_enable_device() goes in the part of the nvidia driver that has
source available.  So users can apply this patch themselves even
without another Nvidia release.

 - Roland

Re: 2.6.8.1-mm2 (nvidia breakage)

[Terence Ripperda]

On Tue, Aug 24, 2004 at 10:36:14AM -0700, roland@topspin.com wrote:
> Terence, correct me if I'm wrong, but the change to add
> pci_enable_device() goes in the part of the nvidia driver that has
> source available.  So users can apply this patch themselves even
> without another Nvidia release.

correct.

Thanks,
Terence

Re: 2.6.8.1-mm2 (nvidia breakage) [u]

[Martin Schlemmer [c]]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

On Wed, 2004-08-25 at 00:03, Terence Ripperda wrote:
> On Tue, Aug 24, 2004 at 10:36:14AM -0700, roland@topspin.com wrote:
> > Terence, correct me if I'm wrong, but the change to add
> > pci_enable_device() goes in the part of the nvidia driver that has
> > source available.  So users can apply this patch themselves even
> > without another Nvidia release.
> 
> correct.
> 

Should just pass it along to minion.de ...


-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.8.1-mm2 (nvidia breakage)

[Michael Geithe]

[-- Attachment #1: Type: text/plain, Size: 113 bytes --]

Hi,
kernel 2.6.8.1-mm2 now booting here without pci=routeirq and
nv_enable_pci.patch. :-)


-- 
Michael Geithe



[-- Attachment #2: dmesg-2.6.8.1-mm2 --]
[-- Type: text/plain, Size: 15352 bytes --]

                      ) @ 0x000fa380
ACPI: RSDT (v001 AMIINT INTEL875 0x00000010 MSFT 0x00000097) @ 0x3fff0000
ACPI: FADT (v001 AMIINT INTEL875 0x00000011 MSFT 0x00000097) @ 0x3fff0030
ACPI: MADT (v001 AMIINT INTEL875 0x00000009 MSFT 0x00000097) @ 0x3fff00c0
ACPI: DSDT (v001  INTEL     I875 0x00001000 MSFT 0x0100000d) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:2 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:2 APIC version 20
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Initializing CPU#0
Kernel command line: root=/dev/hda1 acpi_os_name=Linux floppy=no_acpi video=vesafb:ypan,vram:16 vga=0x317
floppy0: no_acpi=1
CPU 0 irqstacks, hard=c03ca000 soft=c03c8000
PID hash table entries: 4096 (order 12: 32768 bytes)
Detected 2801.068 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1035616k/1048512k available (1967k kernel code, 12316k reserved, 666k data, 188k init, 131008k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 5537.79 BogoMIPS (lpj=2768896)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000
CPU: After vendor identify, caps:  bfebfbff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps:        bfebfbff 00000000 00000000 00000080
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: Overriding _OS definition Linux
CPU0: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
per-CPU timeslice cutoff: 1462.66 usecs.
task migration cache decay timeout: 2 msecs.
Booting processor 1/1 eip 2000
CPU 1 irqstacks, hard=c03cb000 soft=c03c9000
Initializing CPU#1
Calibrating delay loop... 5586.94 BogoMIPS (lpj=2793472)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000
CPU: After vendor identify, caps:  bfebfbff 00000000 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After all inits, caps:        bfebfbff 00000000 00000000 00000080
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 2.80GHz stepping 09
Total of 2 processors activated (11124.73 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
CPU0:  online
 domain 0: span 3
  groups: 1 2
  domain 1: span 3
   groups: 3
CPU1:  online
 domain 0: span 3
  groups: 2 1
  domain 1: span 3
   groups: 3
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfdb81, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040715
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.ICHB._PRT]
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
vesafb: framebuffer at 0xe0000000, mapped to 0xf8880000, size 16384k
vesafb: mode is 1024x768x16, linelength=2048, pages=1
vesafb: protected mode interface info at c000:e9d0
vesafb: pmi: set display start = c00cea15, set palette = c00cea9a
vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03
vesafb: scrolling: ypan using protected mode interface, yres_virtual=8192
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb0: VESA VGA frame buffer device
Machine check exception polling timer started.
Starting balanced_irq
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
ACPI: Processor [CPU1] (supports C1, 8 throttling states)
ACPI: Processor [CPU2] (supports C1, 8 throttling states)
Console: switching to colour frame buffer device 128x48
Real Time Clock Driver v1.12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Using anticipatory io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <saw@saw.sw.com.sg> and others
ACPI: PCI interrupt 0000:02:08.0[A] -> GSI 20 (level, low) -> IRQ 20
eth0: 0000:02:08.0, 00:0C:76:27:61:10, IRQ 20.
  Board assembly 000000-000, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0xed626fe2).
Linux video capture interface: v1.00
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: WDC WD600AB-00CDB0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: ST340015A, ATA DISK drive
hdd: LITEON DVD-ROM LTD163D, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 117231408 sectors (60022 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hda: cache flushes supported
 hda: hda1
hdc: max request size: 128KiB
hdc: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdc: cache flushes supported
 hdc: hdc1 hdc2 hdc3
hdd: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ACPI: PCI interrupt 0000:02:03.0[A] -> GSI 19 (level, low) -> IRQ 19
scsi0 : AdvanSys SCSI 3.3K: PCI Ultra: IO 0xC800-0xC80F, IRQ 0x13
  Vendor: YAMAHA    Model: CDR400t           Rev: 1.0q
  Type:   CD-ROM                             ANSI SCSI revision: 02
sr0: scsi3-mmc drive: 6x/6x writer xa/form2 cdda tray
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 3, lun 0,  type 5
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
NET: Registered protocol family 2
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
ReiserFS: hda1: found reiserfs format "3.6" with standard journal
ReiserFS: hda1: using ordered data mode
ReiserFS: hda1: journal params: device hda1, size 8192, journal first block 18,max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda1: checking transaction log (hda1)
ReiserFS: hda1: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 188k freed
Adding 847720k swap on /dev/hdc3.  Priority:-1 extents:1
nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module  1.0-6111  Tue Jul 27 07:55:38 PDT 2004
ReiserFS: hdc2: found reiserfs format "3.6" with standard journal
ReiserFS: hdc2: using ordered data mode
ReiserFS: hdc2: journal params: device hdc2, size 8192, journal first block 18,max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hdc2: checking transaction log (hdc2)
ReiserFS: hdc2: Using r5 hash to sort names
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ACPI: PCI interrupt 0000:02:01.0[A] -> GSI 17 (level, low) -> IRQ 17
USB Universal Host Controller Interface driver v2.2
ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.0: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: irq 16, io base 0000e000
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: irq 19, io base 0000e400
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: irq 18, io base 0000e800
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI interrupt 0000:00:1d.3[A] -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.3: UHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: irq 16, io base 0000ec00
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4
usb 1-1: new full speed USB device using address 2
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
scsi1 : SCSI emulation for USB Mass Storage devices
usb 2-1: new low speed USB device using address 2
  Vendor: SAMSUNG   Model: SV1296A           Rev:  0 0
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 25238304 512-byte hdwr sectors (12922 MB)
sda: assuming drive cache: write through
 sda: sda1
Attached scsi disk sda at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0,  type 0
USB Mass Storage device found at 2
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver hiddev
usb 4-2: new low speed USB device using address 2
input: USB HID v1.10 Keyboard [Logitech Logitech USB Keyboard] on usb-0000:00:1d.1-1
input: USB HID v1.10 Mouse [Logitech Logitech USB Keyboard] on usb-0000:00:1d.1-1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
input: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-0000:00:1d.3-2
ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.7: EHCI Host Controller
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: irq 23, pci mem f9a2cc00
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
usb 1-1: USB disconnect, address 2
usb 4-2: USB disconnect, address 2
usb 2-1: USB disconnect, address 2
ohci1394: $Rev: 1226 $ Ben Collins <bcollins@debian.org>
ACPI: PCI interrupt 0000:02:01.2[B] -> GSI 18 (level, low) -> IRQ 18
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18]  MMIO=[feaff000-feaff7ff]  Max Packet=[2048]
bttv: driver version 0.9.15 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
ACPI: PCI interrupt 0000:02:02.0[A] -> GSI 18 (level, low) -> IRQ 18
bttv0: Bt878 (rev 17) at 0000:02:02.0, irq: 18, latency: 32, mmio: 0xefefe000
bttv0: detected: Pinnacle PCTV [card=39], PCI subsystem ID is 11bd:0012
bttv0: using: Pinnacle PCTV Studio/Rave [card=39,autodetected]
bttv0: gpio: en=00000000, out=00000000 in=00ff67ff [init]
bttv0: i2c: checking for MSP34xx @ 0x80... not found
bttv0: miro: id=25 tuner=1 radio=no stereo=no
bttv0: using tuner=1
bttv0: i2c: checking for MSP34xx @ 0x80... not found
bttv0: i2c: checking for TDA9875 @ 0xb0... not found
bttv0: i2c: checking for TDA7432 @ 0x8a... not found
tuner: Ignoring new-style parameters in presence of obsolete ones
tuner: chip found at addr 0xc0 i2c-bus bt878 #0 [sw]
tuner: type set to 1 (Philips PAL_I (FI1246 and compatibles)) by bt878 #0 [sw]
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950 .. ok
usb 5-1: new high speed USB device using address 2
scsi2 : SCSI emulation for USB Mass Storage devices
  Vendor: SAMSUNG   Model: SV1296A           Rev:  0 0
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 25238304 512-byte hdwr sectors (12922 MB)
sda: assuming drive cache: write through
 sda: sda1
Attached scsi disk sda at scsi2, channel 0, id 0, lun 0
Attached scsi generic sg1 at scsi2, channel 0, id 0, lun 0,  type 0
USB Mass Storage device found at 2
usb 2-1: new low speed USB device using address 3
input: USB HID v1.10 Keyboard [Logitech Logitech USB Keyboard] on usb-0000:00:1d.1-1
input: USB HID v1.10 Mouse [Logitech Logitech USB Keyboard] on usb-0000:00:1d.1-1
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00023c0151028a1f]
usb 4-2: new low speed USB device using address 3
input: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-0000:00:1d.3-2
hdd: CHECK for good STATUS