* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
@ 2005-05-19 6:25 ` Antonino A. Daplas
2005-05-19 6:25 ` Miles Lane
` (40 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Antonino A. Daplas @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Friday 18 March 2005 03:10, Jean Delvare wrote:
> Hi Tony, hi all,
> I think I found the problem. If count is less than in_row1, bad things
> will happen with the code above. Shame on me for not noticing when I
> wrote it in the first place.
>
> Suggested fix would be:
>
> --- linux-2.6.11.4/drivers/i2c/chips/eeprom.c.orig 2005-03-13
> 10:00:01.000000000 +0100 +++
> linux-2.6.11.4/drivers/i2c/chips/eeprom.c 2005-03-17 19:54:07.000000000
> +0100 @@ -130,7 +130,8 @@
>
> /* Hide Vaio security settings to regular users (16 first bytes) */
> if (data->nature = VAIO && off < 16 && !capable(CAP_SYS_ADMIN)) {
> - int in_row1 = 16 - off;
> + size_t in_row1 = 16 - off;
> + in_row1 = min(in_row1, count);
> memset(buf, 0, in_row1);
> if (count - in_row1 > 0)
> memcpy(buf + in_row1, &data->data[16], count - in_row1);
>
>
> Please test and report.
>
Tested on nvidiafb. No more hang, thanks.
I can test on savagefb too, if you want, but I expect the same result.
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
2005-05-19 6:25 ` Antonino A. Daplas
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Jean Delvare
` (39 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
I narrowed the problem down.
In the following scenario, the OOPS occurs:
CONFIG_I2C=y
CONFIG_FB_NVIDIA=y
CONFIG_FB_NVIDIA_I2C=y
If CONFIG_I2C is changed to build as a module, no crash occurs.
If CONFIG_FB_NVIDIA_I2C is not set, no crash occurs.
If CONFIG_FB_NVIDIA is changed to build as a module, no crash occurs.
Here is start of my dmesg output for a successful boot with CONFIG_FB_NVIDIA=m:
[4294667.296000] Linux version 2.6.11-mm3 (root@Monkey100) (gcc
version 3.3.5 (Debian 1:3.3.5-12)) #25 Tue Mar 15 17:58:18 EST 2005
[4294667.296000] BIOS-provided physical RAM map:
[4294667.296000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[4294667.296000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[4294667.296000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[4294667.296000] BIOS-e820: 0000000000100000 - 000000005fff0000 (usable)
[4294667.296000] BIOS-e820: 000000005fff0000 - 000000005fff3000 (ACPI NVS)
[4294667.296000] BIOS-e820: 000000005fff3000 - 0000000060000000 (ACPI data)
[4294667.296000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[4294667.296000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[4294667.296000] BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
[4294667.296000] Warning only 896MB will be used.
[4294667.296000] Use a HIGHMEM enabled kernel.
[4294667.296000] 896MB LOWMEM available.
[4294667.296000] On node 0 totalpages: 229376
[4294667.296000] DMA zone: 4096 pages, LIFO batch:1
[4294667.296000] Normal zone: 225280 pages, LIFO batch:16
[4294667.296000] HighMem zone: 0 pages, LIFO batch:1
[4294667.296000] DMI 2.2 present.
[4294667.296000] ACPI: RSDP (v000 Nvidia
) @ 0x000f75f0
[4294667.296000] ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD
0x00000000) @ 0x5fff3000
[4294667.296000] ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD
0x00000000) @ 0x5fff3040
[4294667.296000] ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD
0x00000000) @ 0x5fff74c0
[4294667.296000] ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT
0x0100000e) @ 0x00000000
[4294667.296000] ACPI: Local APIC address 0xfee00000
[4294667.296000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[4294667.296000] Processor #0 6:10 APIC version 16
[4294667.296000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[4294667.296000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[4294667.296000] IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
[4294667.296000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[4294667.296000] ACPI: BIOS IRQ0 pin2 override ignored.
[4294667.296000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[4294667.296000] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
[4294667.296000] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
[4294667.296000] ACPI: IRQ9 used by override.
[4294667.296000] ACPI: IRQ14 used by override.
[4294667.296000] ACPI: IRQ15 used by override.
[4294667.296000] Enabling APIC mode: Flat. Using 1 I/O APICs
[4294667.296000] Using ACPI (MADT) for SMP configuration information
[4294667.296000] Allocating PCI resources starting at 60000000 (gap:
60000000:9ec00000)
[4294667.296000] Built 1 zonelists
[4294667.296000] mapped APIC to ffffd000 (fee00000)
[4294667.296000] mapped IOAPIC to ffffc000 (fec00000)
[4294667.296000] Initializing CPU#0
[4294667.296000] Kernel command line: BOOT_IMAGE=Linux ro root06
video=vesafb init=/etc/initlang=us apm=power-off nomce
[4294667.296000] PID hash table entries: 4096 (order: 12, 65536 bytes)
[ 0.000000] Detected 1829.782 MHz processor.
[ 22.394917] Using tsc for high-res timesource
[ 22.394943] Console: colour dummy device 80x25
[ 22.395595] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 22.396201] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 22.416825] Memory: 905116k/917504k available (2283k kernel code,
11932k reserved, 1145k data, 176k init, 0k highmem)
[ 22.416836] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[ 22.416920] Calibrating delay loop... 3612.67 BogoMIPS (lpj\x1806336)
[ 22.438853] Mount-cache hash table entries: 512
[ 22.438960] CPU: After generic identify, caps: 0383fbff c1c3fbff
00000000 00000000 0000000000000000 00000000
[ 22.438968] CPU: After vendor identify, caps: 0383fbff c1c3fbff
00000000 00000000 00000000 00000000 00000000
[ 22.438976] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 22.438981] CPU: L2 Cache: 512K (64 bytes/line)
[ 22.438985] CPU: After all inits, caps: 0383fbff c1c3fbff 00000000
00000020 00000000 00000000 00000000
[ 22.438991] CPU: AMD Athlon(tm) XP 2500+ stepping 00
[ 22.438996] Enabling fast FPU save and restore... done.
[ 22.439000] Enabling unmasked SIMD FPU exception support... done.
[ 22.439006] Checking 'hlt' instruction... OK.
[ 22.464614] ENABLING IO-APIC IRQs
[ 22.464807] ..TIMER: vector=0x31 pin1=0 pin2=-1
[ 22.575777] softlockup thread 0 started up.
[ 22.576062] NET: Registered protocol family 16
[ 22.592317] PCI: PCI BIOS revision 2.10 entry at 0xfb470, last bus=3
[ 22.592328] PCI: Using configuration type 1
[ 22.592332] mtrr: v2.0 (20020519)
[ 22.592654] ACPI: Subsystem revision 20050309
[ 22.606938] ACPI: Interpreter enabled
[ 22.606944] ACPI: Using IOAPIC for interrupt routing
[ 22.607498] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 22.607505] PCI: Probing PCI hardware (bus 00)
[ 22.607570] PCI: nForce2 C1 Halt Disconnect fixup
[ 22.609141] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 22.609452] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
[ 22.610018] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
[ 22.610249] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB1._PRT]
[ 22.611241] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 22.611580] ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11
12 14 15) *0, disabled.
[ 22.611930] ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 22.612265] ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 22.612604] ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11
12 14 15) *0, disabled.
[ 22.612954] ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 22.613289] ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 22.613633] ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 22.613977] ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 22.614312] ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 22.614657] ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11
12 14 15) *0, disabled.
[ 22.614994] ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 22.615329] ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[ 22.615676] ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 22.616015] ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[ 22.616352] ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11
12 14 15) *0, disabled.
[ 22.616681] ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled.
[ 22.616974] ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled.
[ 22.617264] ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled.
[ 22.617553] ACPI: PCI Interrupt Link [APC4] (IRQs *19), disabled.
[ 22.617855] ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
[ 22.618237] ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0, disabled.
[ 22.618623] ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0, disabled.
[ 22.618999] ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0, disabled.
[ 22.619375] ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0, disabled.
[ 22.619760] ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0, disabled.
[ 22.620133] ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled.
[ 22.620425] ACPI: PCI Interrupt Link [APCS] (IRQs *23), disabled.
[ 22.620811] ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0, disabled.
[ 22.621187] ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0, disabled.
[ 22.621562] ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled.
[ 22.621950] ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled.
[ 22.625775] Linux Plug and Play Support v0.97 (c) Adam Belay
[ 22.625827] pnp: PnP ACPI init
[ 22.632352] pnp: PnP ACPI: found 16 devices
[ 22.632512] PCI: Using ACPI for IRQ routing
[ 22.632519] PCI: If a device doesn't work, try "pci=routeirq". If
it helps, post a report
[ 22.697115] pnp: 00:00: ioport range 0x4000-0x407f could not be reserved
[ 22.697122] pnp: 00:00: ioport range 0x4080-0x40ff has been reserved
[ 22.697127] pnp: 00:00: ioport range 0x4400-0x447f has been reserved
[ 22.697132] pnp: 00:00: ioport range 0x4480-0x44ff could not be reserved
[ 22.697137] pnp: 00:00: ioport range 0x4200-0x427f has been reserved
[ 22.697141] pnp: 00:00: ioport range 0x4280-0x42ff has been reserved
[ 22.697148] pnp: 00:01: ioport range 0x5000-0x503f has been reserved
[ 22.697153] pnp: 00:01: ioport range 0x5500-0x553f has been reserved
[ 22.698053] inotify device minorc
[ 22.698066] VFS: Disk quotas dquot_6.5.1
[ 22.698093] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 22.698131] NTFS driver 2.1.23-WIP [Flags: R/W].
[ 22.698164] Initializing Cryptographic API
[ 22.698358] vesafb: framebuffer at 0xd0000000, mapped to
0xf8880000, using 3072k, total 131072k
[ 22.698366] vesafb: mode is 1024x768x16, linelength 48, pages=1
[ 22.698371] vesafb: protected mode interface info at c000:f530
[ 22.698375] vesafb: scrolling: redraw
[ 22.698380] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[ 22.712150] Console: switching to colour frame buffer device 128x48
[ 22.712241] fb0: VESA VGA frame buffer device
[ 22.713496] Linux agpgart interface v0.101 (c) Dave Jones
[ 22.713617] agpgart: Detected NVIDIA nForce2 chipset
[ 22.721844] agpgart: AGP aperture is 128M @ 0xe0000000
[ 22.722046] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at
0x60,0x64 irq 1,12
[ 22.734958] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 22.735379] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 22.735449] Serial: 8250/16550 driver $Revision: 1.90 $ 46 ports,
IRQ sharing enabled
[ 22.735689] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 22.735874] ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 22.737526] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 22.738030] ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 22.738291] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 22.738503] ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 22.738661] io scheduler noop registered
[ 22.738729] io scheduler anticipatory registered
[ 22.738797] io scheduler deadline registered
[ 22.738865] io scheduler cfq registered
[ 22.741223] ACPI: PCI Interrupt Link [AP3C] enabled at IRQ 22
[ 22.743245] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [AP3C] ->
GSI 22 (level, high) -> IRQ 22
[ 22.745348] 3c59x: Donald Becker and others.
www.scyld.com/network/vortex.html
[ 22.747469] 0000:02:01.0: 3Com PCI 3c920 Tornado at 0xc000. Vers LK1.1.19
[ 22.782505] forcedeth.c: Reverse Engineered nForce ethernet driver.
Version 0.31.
[ 22.785001] ACPI: PCI Interrupt Link [APCH] enabled at IRQ 21
[ 22.787146] ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCH] ->
GSI 21 (level, high) -> IRQ 21
[ 22.789401] PCI: Setting latency timer of device 0000:00:04.0 to 64
[ 23.299982] eth1: forcedeth.c: subsystem: 01043:80a7 bound to 0000:00:04.0
[ 23.302282] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[ 23.304614] ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
[ 23.307113] NFORCE2: IDE controller at PCI slot 0000:00:09.0
[ 23.309597] NFORCE2: chipset revision 162
[ 23.312086] NFORCE2: not 100% native mode: will probe irqs later
[ 23.314595] NFORCE2: BIOS didn't set cable bits correctly. Enabling
workaround.
[ 23.317153] NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
[ 23.319695] ide0: BM-DMA at 0xf000-0xf007, BIOS settings:
hda:DMA, hdb:DMA
[ 23.322281] ide1: BM-DMA at 0xf008-0xf00f, BIOS settings:
hdc:DMA, hdd:DMA
[ 23.324831] Probing IDE interface ide0...
[ 23.584601] hda: WDC WD2000BB-00DAA0, ATA DISK drive
[ 24.192764] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[ 24.195279] Probing IDE interface ide1...
[ 24.859095] hdc: JLMS XJ-HD165H, ATAPI CD/DVD-ROM drive
[ 25.573250] hdd: SONY DVD RW DRU-500A, ATAPI CD/DVD-ROM drive
[ 25.624700] ide1 at 0x170-0x177,0x376 on irq 15
[ 25.627274] hda: max request size: 1024KiB
[ 25.636996] hda: 390721968 sectors (200049 MB) w/2048KiB Cache,
CHS$321/255/63, UDMA(100)
[ 25.640847] hda: cache flushes supported
[ 25.643381] hda: hda1 hda2 < hda5 hda6 hda7 >
[ 25.705759] mice: PS/2 mouse device common for all mice
[ 25.708256] i2c /dev entries driver
[ 25.711559] i2c-core: driver dev_driver registered.
[ 25.711618] i2c_adapter i2c-0: Registered as minor 0
[ 25.711641] i2c_adapter i2c-0: registered as adapter #0
[ 25.711645] i2c_adapter i2c-0: nForce2 SMBus adapter at 0x5000
[ 25.714349] i2c_adapter i2c-1: Registered as minor 1
[ 25.714373] i2c_adapter i2c-1: registered as adapter #1
[ 25.714376] i2c_adapter i2c-1: nForce2 SMBus adapter at 0x5500
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
2005-05-19 6:25 ` Antonino A. Daplas
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
` (38 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Tony,
> I've only seen the savage bug report. Yes, unfortunately, this is the
> case of 2 drivers attempting to control a single device since the
> savagefb and the i2c prosavage drivers will attempt to ioremap the
> same mmio region. If you need the i2c prosavage bus, then savagefb
> must be completely disabled, as setting CONFIG_FB_SAVAGE_I2C to n will
> not help. If both savagefb and i2c are needed, then you just have to
> use the i2c bus registered by savagefb.
I understand the problem you describe, and it should certainly be
addressed by Kconfig dependencies. However, I don't think this is the
problem here. If you look at the configuration file, you'll see that
neither i2c-prosavage nor i2c-savage4 are enabled:
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
> And yes, there is code duplication, but unfortunately savagefb cannot
> use the i2c-prosavage bus since one of them will fail to acquire the
> io regions.
I wonder if the standalone i2c drivers are needed at all anymore, now
that the framebuffer driver includes the same functionality.
> I haven't seen the nvidiafb report, but it is probably something
> similar.
Note that there is no i2c bus driver for nvidia graphics adapters in the
kernel tree. The conflicting driver is rivatv and it lives outside the
kernel tree.
Miles, are you by any chance using rivatv?
Tony, Miles' original report is here:
http://marc.theaimsgroup.com/?l=linux-kernel&m\x111076667232062&w=2
Sorry for providing the link before.
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (2 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Miles Lane
` (37 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Tony, hi all,
> > I've tracked this to eeprom_read in drivers/i2c/chips/eeprom. I
> > don't know exactly what happens but commenting out this part in
> > eeprom_read():
> >
> > if (data->nature = VAIO && off < 16 && !capable(CAP_SYS_ADMIN))
> > {
> > #if 0
> > int in_row1 = 16 - off;
> > memset(buf, 0, in_row1);
> > if (count - in_row1 > 0)
> > memcpy(buf + in_row1, &data->data[16], count -
> > in_row1);
> > #endif
> >
> > at least, prevents the hang.
I think I found the problem. If count is less than in_row1, bad things
will happen with the code above. Shame on me for not noticing when I
wrote it in the first place.
Suggested fix would be:
--- linux-2.6.11.4/drivers/i2c/chips/eeprom.c.orig 2005-03-13 10:00:01.000000000 +0100
+++ linux-2.6.11.4/drivers/i2c/chips/eeprom.c 2005-03-17 19:54:07.000000000 +0100
@@ -130,7 +130,8 @@
/* Hide Vaio security settings to regular users (16 first bytes) */
if (data->nature = VAIO && off < 16 && !capable(CAP_SYS_ADMIN)) {
- int in_row1 = 16 - off;
+ size_t in_row1 = 16 - off;
+ in_row1 = min(in_row1, count);
memset(buf, 0, in_row1);
if (count - in_row1 > 0)
memcpy(buf + in_row1, &data->data[16], count - in_row1);
Please test and report.
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (3 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Jean Delvare
` (36 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hello all,
> Miles, are you by any chance using rivatv?
I am not using RivaTV. I will send along a decoded OOPS asap.
Thanks,
Miles
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (4 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Miles Lane
` (35 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Tony, hi all,
> I was able to also duplicate the bug with eeprom with nividiafb-i2c, and
> the bug only appears when running sensors as a regular user, not as root.
Correct, that's what was reported in bug #4347 also.
> I've tracked this to eeprom_read in drivers/i2c/chips/eeprom. I don't know
> exactly what happens but commenting out this part in eeprom_read():
>
> if (data->nature = VAIO && off < 16 && !capable(CAP_SYS_ADMIN)) {
> #if 0
> int in_row1 = 16 - off;
> memset(buf, 0, in_row1);
> if (count - in_row1 > 0)
> memcpy(buf + in_row1, &data->data[16], count -
> in_row1);
> #endif
>
> at least, prevents the hang.
First thing I noticed is that you should never enter this portion of
code, since it is there only for Vaio laptops. I found that this is
caused by a bug I introduced recently in a different part of the code.
Missing curly braces cause *all* EEPROMSs at address 0x57 to be
considered as Vaio EEPROMS, regardless of their content. I will submit a
patch to fix this soon. I apologize deeply for introducing this bug :(
However, this side bug does NOT explain the behavior observed here, it
only allowed the oops to happen. It would be great if we could
understand why the oops happens, so that we can really fix the problem.
Could you please add some printks on off, count and in_row1 in various
places so that we can find out which values are passed to memset and
memcpy?
I guess that either memset or memcpy is causing the oops. It would be
great if you could isolate which one exactly does.
I'll do some additional tests this evening. I do have a Vaio laptop and
also a monitor with an EEPROM at 0x57. Both systems use radeonfb.
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (5 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Antonino A. Daplas
` (34 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
My full .config file is listed here:
http://marc.theaimsgroup.com/?l=linux-kernel&m\x111076667232062&w=2
I will test again with the i2c core built as a module.
Thanks,
Miles
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (6 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Antonino A. Daplas
2005-05-19 6:25 ` Jean Delvare
` (33 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Antonino A. Daplas @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Thursday 17 March 2005 00:37, Jean Delvare wrote:
> Hi Tony,
>
>
> Tony, Miles' original report is here:
> http://marc.theaimsgroup.com/?l=linux-kernel&m\x111076667232062&w=2
> Sorry for providing the link before.
>
Before I go on debugging, a few questions, as my knowledge of the i2c
framework is quite limited:
This particular bug seems to be triggered in i2c_dev_init when calling
i2c_add_driver.
1. nvidiafb gets loaded before i2c_dev_init(), and when setting up i2c,
calls i2c_bit_add_bus. Is this safe to do?
2. In i2c_add_driver, there is a call to list_add_tail. Is this acceptable
without doing a LIST_HEAD_INIT first? Or is the list_head initialized
somewhere?
Tony
> Thanks,
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (7 preceding siblings ...)
2005-05-19 6:25 ` Antonino A. Daplas
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
` (32 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Mike, Antonio & all,
> I narrowed the problem down.
> In the following scenario, the OOPS occurs:
> CONFIG_I2C=y
> CONFIG_FB_NVIDIA=y
> CONFIG_FB_NVIDIA_I2C=y
>
> If CONFIG_I2C is changed to build as a module, no crash occurs.
Hardly relevant, since this means CONFIG_FB_NVIDIA!=y as well.
> If CONFIG_FB_NVIDIA_I2C is not set, no crash occurs.
> If CONFIG_FB_NVIDIA is changed to build as a module, no crash occurs.
I guess the driver won't auto-load, so you should try to modprobe it
afterwards. Maybe it'll crash as well then.
Mike, can you please provide a decoded oops? There's not much we can do
without that.
I wonder if this problem could be related to this one:
http://bugme.osdl.org/show_bug.cgi?idC47
This too is a bit-banging I2C adapter, part of a framebuffer driver
(savage there instead of nv here).
Antonio, any idea? You wrote both drivers recently.
I'm rather ignorant when it comes to IRQs so I'm not sure I can really
help.
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (8 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Antonino A. Daplas
` (31 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Tony,
> Before I go on debugging, a few questions, as my knowledge of the i2c
> framework is quite limited:
>
> This particular bug seems to be triggered in i2c_dev_init when calling
> i2c_add_driver.
Were you able to reproduce this one as well? I couldn't.
> 1. nvidiafb gets loaded before i2c_dev_init(), and when setting up
> i2c, calls i2c_bit_add_bus. Is this safe to do?
Looks OK to me. nvidiafb, like other framebuffer drivers, declares i2c
busses. i2c-dev declares an i2c driver. Both are rather independent, and
supposedly don't interract before an i2c client is created (that would
happen in i2cdev_open()).
i2c-dev isn't really part of i2c-core, it's more like a priviledged i2c
pseudo-chip driver.
> 2. In i2c_add_driver, there is a call to list_add_tail. Is this
> acceptable without doing a LIST_HEAD_INIT first? Or is the list_head
> initialized somewhere?
The list is declared with:
static LIST_HEAD(drivers);
at the top of i2c-core.c.
Looks OK to me but I am no list expert.
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (9 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Antonino A. Daplas
[not found] ` <20050317154226.24c1f8f8.akpm@osdl.org>
2005-05-19 6:25 ` Antonino A. Daplas
` (30 subsequent siblings)
41 siblings, 1 reply; 46+ messages in thread
From: Antonino A. Daplas @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Friday 18 March 2005 06:03, Jean Delvare wrote:
> Hi Tony,
>
> > Before I go on debugging, a few questions, as my knowledge of the i2c
> > framework is quite limited:
> >
> > This particular bug seems to be triggered in i2c_dev_init when calling
> > i2c_add_driver.
>
> Were you able to reproduce this one as well? I couldn't.
Can't either.
>
> > 1. nvidiafb gets loaded before i2c_dev_init(), and when setting up
> > i2c, calls i2c_bit_add_bus. Is this safe to do?
>
> Looks OK to me. nvidiafb, like other framebuffer drivers, declares i2c
> busses. i2c-dev declares an i2c driver. Both are rather independent, and
> supposedly don't interract before an i2c client is created (that would
> happen in i2cdev_open()).
>
> i2c-dev isn't really part of i2c-core, it's more like a priviledged i2c
> pseudo-chip driver.
Ok, just making sure.
>
> > 2. In i2c_add_driver, there is a call to list_add_tail. Is this
> > acceptable without doing a LIST_HEAD_INIT first? Or is the list_head
> > initialized somewhere?
>
> The list is declared with:
> static LIST_HEAD(drivers);
Ok, I mistakenly interchanged the parameters of list_*. I thought the second
parameter is the entry to be added to the list_head, the first parameter.
> at the top of i2c-core.c.
> Looks OK to me but I am no list expert.
I was talking about driver->list, because of my mistaken belief as mentioned
above, where it is initialized. Anyway, after checking the i2c code, I
don't see where driver->list used anywhere, so I don't think it will hit a
bug.
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (10 preceding siblings ...)
2005-05-19 6:25 ` Antonino A. Daplas
@ 2005-05-19 6:25 ` Antonino A. Daplas
2005-05-19 6:25 ` Antonino A. Daplas
` (29 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Antonino A. Daplas @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Thursday 17 March 2005 00:37, Jean Delvare wrote:
> Hi Tony,
>
> > I've only seen the savage bug report. Yes, unfortunately, this is the
> > case of 2 drivers attempting to control a single device since the
> > savagefb and the i2c prosavage drivers will attempt to ioremap the
> > same mmio region. If you need the i2c prosavage bus, then savagefb
> > must be completely disabled, as setting CONFIG_FB_SAVAGE_I2C to n will
> > not help. If both savagefb and i2c are needed, then you just have to
> > use the i2c bus registered by savagefb.
>
> I understand the problem you describe, and it should certainly be
> addressed by Kconfig dependencies. However, I don't think this is the
> problem here. If you look at the configuration file, you'll see that
> neither i2c-prosavage nor i2c-savage4 are enabled:
>
> # CONFIG_I2C_PROSAVAGE is not set
> # CONFIG_I2C_SAVAGE4 is not set
I was able to also duplicate the bug with eeprom with nividiafb-i2c, and the
bug only appears when running sensors as a regular user, not as root.
I've tracked this to eeprom_read in drivers/i2c/chips/eeprom. I don't know
exactly what happens but commenting out this part in eeprom_read():
if (data->nature = VAIO && off < 16 && !capable(CAP_SYS_ADMIN)) {
#if 0
int in_row1 = 16 - off;
memset(buf, 0, in_row1);
if (count - in_row1 > 0)
memcpy(buf + in_row1, &data->data[16], count - in_row1);
#endif
at least, prevents the hang.
>
> > And yes, there is code duplication, but unfortunately savagefb cannot
> > use the i2c-prosavage bus since one of them will fail to acquire the
> > io regions.
>
> I wonder if the standalone i2c drivers are needed at all anymore, now
> that the framebuffer driver includes the same functionality.
>
> > I haven't seen the nvidiafb report, but it is probably something
> > similar.
>
> Note that there is no i2c bus driver for nvidia graphics adapters in the
> kernel tree. The conflicting driver is rivatv and it lives outside the
> kernel tree.
>
> Miles, are you by any chance using rivatv?
I'll try investigating this also, but can you also try disabling
CONFIG_I2C_NFORCE2?
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (11 preceding siblings ...)
2005-05-19 6:25 ` Antonino A. Daplas
@ 2005-05-19 6:25 ` Antonino A. Daplas
2005-05-19 6:25 ` Antonino A. Daplas
` (28 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Antonino A. Daplas @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Wednesday 16 March 2005 17:54, Jean Delvare wrote:
> Hi Mike, Antonio & all,
>
> > I narrowed the problem down.
> > In the following scenario, the OOPS occurs:
> > CONFIG_I2C=y
> > CONFIG_FB_NVIDIA=y
> > CONFIG_FB_NVIDIA_I2C=y
> >
> > If CONFIG_I2C is changed to build as a module, no crash occurs.
>
> Hardly relevant, since this means CONFIG_FB_NVIDIA!=y as well.
>
> > If CONFIG_FB_NVIDIA_I2C is not set, no crash occurs.
> > If CONFIG_FB_NVIDIA is changed to build as a module, no crash occurs.
>
> I guess the driver won't auto-load, so you should try to modprobe it
> afterwards. Maybe it'll crash as well then.
>
> Mike, can you please provide a decoded oops? There's not much we can do
> without that.
>
> I wonder if this problem could be related to this one:
> http://bugme.osdl.org/show_bug.cgi?idC47
>
> This too is a bit-banging I2C adapter, part of a framebuffer driver
> (savage there instead of nv here).
>
> Antonio, any idea? You wrote both drivers recently.
>
> I'm rather ignorant when it comes to IRQs so I'm not sure I can really
> help.
>
I've only seen the savage bug report. Yes, unfortunately, this is the
case of 2 drivers attempting to control a single device since the savagefb
and the i2c prosavage drivers will attempt to ioremap the same mmio region.
If you need the i2c prosavage bus, then savagefb must be completely
disabled, as setting CONFIG_FB_SAVAGE_I2C to n will not help. If both
savagefb and i2c are needed, then you just have to use the i2c bus
registered by savagefb.
And yes, there is code duplication, but unfortunately savagefb cannot use
the i2c-prosavage bus since one of them will fail to acquire the io regions.
I haven't seen the nvidiafb report, but it is probably something similar.
This is similar to the fbdev/DRM problem of who owns the device. We can
also throw in i2c bus drivers in the mix, at least for VGA devices. Perhaps a
low-level VGA driver (as proposed by Alan Cox) will be needed to resolve
this problem.
Tony
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (12 preceding siblings ...)
2005-05-19 6:25 ` Antonino A. Daplas
@ 2005-05-19 6:25 ` Antonino A. Daplas
2005-05-19 6:25 ` Jean Delvare
` (27 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Antonino A. Daplas @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Friday 18 March 2005 20:07, Jean Delvare wrote:
> Hi Tony,
>
> Tony, could it be that the i2c_adapter structures that were allocated in
> the nvidiafb driver and registered with the i2c core (using
> i2c_bit_add_bus() in nvidia_setup_i2c_bus()) are no more reachable at
> this point? I am not familiar with the framebuffer code so I have a hard
It is reachable. i2c_bit_add_bus is only called after setup of the
hardware, otherwise nvidiafb will be consistently hitting a bug.
> time figuring out when the memory is allocated and when it is freed. I
> think I understand it is allocated by framebuffer_alloc() and freed by
> framebuffer_release()?
Yes all required memory is allocated during framebuffer_alloc().
>
> I note that you never actually unregister the i2c_adapters. The function
> nvidia_delete_i2c_busses() is #if'd out. This means that
> framebuffer_release() can free the memory while the i2c_adapters are
> still in i2c-core's adapters list. This would certainly explain the
> crash Miles observed.
Yes, this is a bug, already fixed in my tree. I forgot to cleanup i2c in
nvidiafb, which should be done on driver unload. But a framebuffer device
cannot be unloaded if compiled statically or if fbcon is using it. The only
way to unload a framebuffer driver is to call rmmod.
>
> Now, when is framebuffer_release() called? I think I understand it should
> only be called if:
> * the nvidia device detection somehow failed in nvidiafb_probe(); or
> * the driver is unloaded, in nvidiafb_remove().
> Could either case happen in Miles' case? Miles, do you actually get the
> nvidiafb driver to work? If not, then the oops is easily explained by
> what I just described (i2c_adapters still listed at the i2c-core level,
> but freed from memory at the nvidiafb level).
Yes this is possible, but is extremely rare. The only point nvidiafb
will fail after setting up i2c is when ioremap fails or register_framebuffer
fails.
Anyway, I'm attaching a patch that allows nvidiafb to cleanup i2c on failure
to see if it helps.
Tony
diff -Nru a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
--- a/drivers/video/nvidia/nv_i2c.c 2005-03-12 23:25:10 +08:00
+++ b/drivers/video/nvidia/nv_i2c.c 2005-03-18 21:06:28 +08:00
@@ -146,7 +146,6 @@
nvidia_setup_i2c_bus(&par->chan[2], "BUS3");
}
-#if 0
void nvidia_delete_i2c_busses(struct nvidia_par *par)
{
if (par->chan[0].par)
@@ -162,7 +161,6 @@
par->chan[2].par = NULL;
}
-#endif /* 0 */
static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan *chan)
{
diff -Nru a/drivers/video/nvidia/nv_of.c b/drivers/video/nvidia/nv_of.c
--- a/drivers/video/nvidia/nv_of.c 2005-03-12 23:25:11 +08:00
+++ b/drivers/video/nvidia/nv_of.c 2005-03-18 21:06:28 +08:00
@@ -28,6 +28,7 @@
#include "nv_proto.h"
void nvidia_create_i2c_busses(struct nvidia_par *par) {}
+void nvidia_delete_i2c_busses(struct nvidia_par *par) {}
int nvidia_probe_i2c_connector(struct nvidia_par *par, int conn, u8 **out_edid)
{
diff -Nru a/drivers/video/nvidia/nv_proto.h b/drivers/video/nvidia/nv_proto.h
--- a/drivers/video/nvidia/nv_proto.h 2005-03-12 23:25:12 +08:00
+++ b/drivers/video/nvidia/nv_proto.h 2005-03-18 21:06:28 +08:00
@@ -33,10 +33,12 @@
/* in nvidia-i2c.c */
#if defined(CONFIG_FB_NVIDIA_I2C) || defined (CONFIG_PPC_OF)
void nvidia_create_i2c_busses(struct nvidia_par *par);
+void nvidia_delete_i2c_busses(struct nvidia_par *par);
int nvidia_probe_i2c_connector(struct nvidia_par *par, int conn,
u8 ** out_edid);
#else
#define nvidia_create_i2c_busses(...)
+#define nvidia_delete_i2c_busses(...)
#define nvidia_probe_i2c_connector(p, c, edid) \
do { \
*(edid) = NULL; \
diff -Nru a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
--- a/drivers/video/nvidia/nvidia.c 2005-03-15 18:42:12 +08:00
+++ b/drivers/video/nvidia/nvidia.c 2005-03-18 21:22:39 +08:00
@@ -1566,8 +1566,9 @@
err_out_iounmap_fb:
iounmap(info->screen_base);
- err_out_free_base1:
fb_destroy_modedb(info->monspecs.modedb);
+ nvidia_delete_i2c_busses(par);
+ err_out_free_base1:
iounmap(par->REGS);
err_out_free_base0:
pci_release_regions(pd);
@@ -1597,9 +1598,10 @@
info->fix.smem_len);
#endif /* CONFIG_MTRR */
+ iounmap(info->screen_base);
fb_destroy_modedb(info->monspecs.modedb);
+ nvidia_delete_i2c_busses(par);
iounmap(par->REGS);
- iounmap(info->screen_base);
pci_release_regions(pd);
pci_disable_device(pd);
kfree(info->pixmap.addr);
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (13 preceding siblings ...)
2005-05-19 6:25 ` Antonino A. Daplas
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Andrew Morton
` (26 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Tony,
> I was talking about driver->list, because of my mistaken belief as
> mentioned above, where it is initialized. Anyway, after checking the i2c
> code, I don't see where driver->list used anywhere, so I don't think it
> will hit a bug.
I am just learning how lists work in Linux, and it seems to me that list
items only exist as their own address (they don't contain any data). So
it's not surprising that you don't see any use of driver->list.
The list itself is used in i2c-core:i2c_add_adapter():
/* inform drivers of new adapters */
list_for_each(item,&drivers) {
driver = list_entry(item, struct i2c_driver, list);
if (driver->flags & I2C_DF_NOTIFY)
/* We ignore the return code; if it fails, too bad */
driver->attach_adapter(adap);
}
And similarly in i2c-core:i2c_del_adapter().
That being said, I think we are looking at the wrong list. The oops
happens when inserting an i2c_driver, not an i2c_adapter, so the list
that will be notified is the adapters list. In i2c_add_driver() we have
the following:
/* now look for instances of driver on our adapters */
if (driver->flags & I2C_DF_NOTIFY) {
list_for_each(item,&adapters) {
adapter = list_entry(item, struct i2c_adapter, list);
driver->attach_adapter(adapter);
}
}
Since this is the only part of the function which deals with adapters,
and the oops does not occur if CONFIG_FB_NVIDIA_I2C is not set, I assume
the oops happens just here. This would mean that either we aren't able
to walk the adapters list, or i2cdev_attach_adapter dies - but I would
then expect to see it in the stack when the oops occur. For this reason
I do think that the problem is on the list walk itself, rather than the
function call in the loop.
Miles, could you please try to modify your oopsing configuration in the
following way:
CONFIG_I2C_CHARDEV=n
CONFIG_SENSORS_EEPROM=y
I would expect if to oops in i2c_add_driver() as well.
Tony, could it be that the i2c_adapter structures that were allocated in
the nvidiafb driver and registered with the i2c core (using
i2c_bit_add_bus() in nvidia_setup_i2c_bus()) are no more reachable at
this point? I am not familiar with the framebuffer code so I have a hard
time figuring out when the memory is allocated and when it is freed. I
think I understand it is allocated by framebuffer_alloc() and freed by
framebuffer_release()?
I note that you never actually unregister the i2c_adapters. The function
nvidia_delete_i2c_busses() is #if'd out. This means that
framebuffer_release() can free the memory while the i2c_adapters are
still in i2c-core's adapters list. This would certainly explain the
crash Miles observed.
Now, when is framebuffer_release() called? I think I understand it should
only be called if:
* the nvidia device detection somehow failed in nvidiafb_probe(); or
* the driver is unloaded, in nvidiafb_remove().
Could either case happen in Miles' case? Miles, do you actually get the
nvidiafb driver to work? If not, then the oops is easily explained by
what I just described (i2c_adapters still listed at the i2c-core level,
but freed from memory at the nvidiafb level).
Hope that helps,
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (14 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Andrew Morton
2005-05-19 6:25 ` Miles Lane
` (25 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Andrew Morton @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Miles Lane <miles.lane@gmail.com> wrote:
>
> Hello,
>
> I think I decoded this Oops correctly. The crash occurs before the
> disk is mounted, so I am unable to access the contents of /proc/ksyms
> and /proc/modules. However, the decoding using the modules and
> System.map looks reasonable. Is the decoding accurate?
Thanks for doing this.
CONFIG_KALLSYMS does all the decoding for us, so we normally don't need
ksymoops.
However the EIP wasn't decoded, and that's the most important datum.
Could you do:
gdb vmlinux
(gdb) x/30i 0xc028bba0
so we can work out what's at 0xc028bbc2?
> ksymoops -o /lib/modules/2.6.12-rc1-mm1/ -m
> /boot/System.map-2.6.12-rc1-mm1 < oops
> ksymoops 2.4.9 on i686 2.6.11-bk5. Options used
> -V (default)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -o /lib/modules/2.6.12-rc1-mm1/ (specified)
> -m /boot/System.map-2.6.12-rc1-mm1 (specified)
>
> Error (regular_file): read_ksyms stat /proc/ksyms failed
> ksymoops: No such file or directory
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> C028bbc2
> *pde = 00000000
> Oops: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c028bbc2>] Not tainted VLI
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010282 (2.6.11-mm3)
> Eax: 00000000 ebx: 00000000 ecx: 00000000 edx: f7e99504
> Esi: c03f5260 edi: 00000000 ebp: f7c21fa4 esp: f7c21f90
> Ds: 007b es: 007b ss: 0068
> Stack: f7c00540 c03f5264 00000000 00000000 00000000 f7c21fbc c0480695 c03f5260
> c03724f8 c03f5140 c048d204 f7c21fd8 c04668ab c01002d0 00000000 00000000
> c01002d0 00000000 f7c21fec c0100302 0000007b 0000007b ffffffff 00000000
> Call Trace:
> [<c010404f>] show_stack+0x7f/0xa0
> [<c01041ea>] show_registers+0x15a/0x1c0
> [<c01043e0>] die+0xf0/0x190
> [<c011450b>] do_page_fault+0x31b/0x670
> [<c0103c83>] error_code+0x2b/0x30
> [<c0480695>] i2c_dev_init+0x55/0xa0
> [<c04668ab>] do_initcalls+0x2b/0xc0
> [<c0100302>] init+0x32/0x130
> [<c0101351>] kernel_thread_helper+0x5/0x14
> Code: e5 e8 ff f6 46 2c 01 74 30 8b 1d a0 4e 3f c0 8b 03 0f 18 00 90
>
>
> >>EIP; c028bbc2 <pnp_assign_mem+82/140> <==>
> >>edx; f7e99504 <pg0+37936504/3fa9b400>
> >>Esi; c03f5260 <__func__.2+1edc5/3adbd>
> >>ebp; f7c21fa4 <pg0+376befa4/3fa9b400>
> >>esp; f7c21f90 <pg0+376bef90/3fa9b400>
>
> Trace; c010404f <irq_entries_start+183/880>
> Trace; c01041ea <irq_entries_start+31e/880>
> Trace; c01043e0 <irq_entries_start+514/880>
> Trace; c011450b <_setbad+401/6f6>
> Trace; c0103c83 <ret_from_fork+3/14>
> Trace; c0480695 <texts.16+5/8>
> Trace; c04668ab <__devices_8086+acb/eb0>
> Trace; c0100302 <init+32/130>
> Trace; c0101351 <kernel_thread_helper+5/14>
>
> Code; c028bbc2 <pnp_assign_mem+82/140>
> 00000000 <_EIP>:
> Code; c028bbc2 <pnp_assign_mem+82/140> <==> 0: e5 e8 in $0xe8,%eax <==> Code; c028bbc4 <pnp_assign_mem+84/140>
> 2: ff f6 push %esi
> Code; c028bbc6 <pnp_assign_mem+86/140>
> 4: 46 inc %esi
> Code; c028bbc7 <pnp_assign_mem+87/140>
> 5: 2c 01 sub $0x1,%al
> Code; c028bbc9 <pnp_assign_mem+89/140>
> 7: 74 30 je 39 <_EIP+0x39>
> Code; c028bbcb <pnp_assign_mem+8b/140>
> 9: 8b 1d a0 4e 3f c0 mov 0xc03f4ea0,%ebx
> Code; c028bbd1 <pnp_assign_mem+91/140>
> f: 8b 03 mov (%ebx),%eax
> Code; c028bbd3 <pnp_assign_mem+93/140>
> 11: 0f 18 00 prefetchnta (%eax)
> Code; c028bbd6 <pnp_assign_mem+96/140>
> 14: 90 nop
>
> <0>Kernel panic ??" not syncing: Attempted to kill init!
>
> 1 error issued. Results may not be reliable.
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (15 preceding siblings ...)
2005-05-19 6:25 ` Andrew Morton
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Andrew Morton
` (24 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Fri, 18 Mar 2005 13:07:08 +0100 (CET), Jean Delvare
<khali@linux-fr.org> wrote:
> Miles, could you please try to modify your oopsing configuration in the
> following way:
> CONFIG_I2C_CHARDEV=n
> CONFIG_SENSORS_EEPROM=y
> I would expect if to oops in i2c_add_driver() as well.
I had to copy this by hand, but I think I got it all down correctly.
ksymoops -o /lib/modules/2.6.12-rc1-mm1/ -m
/boot/System.map-2.6.12-rc1-mm1 < oops2
ksymoops 2.4.9 on i686 2.6.11-bk5. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.12-rc1-mm1/ (specified)
-m /boot/System.map-2.6.12-rc1-mm1 (specified)
Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel NULL pointer dereference at virtual address 00000020
c02f094f
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c02f094f>} Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010292 (2.6.12-rc1-mm1)
eax: 00000000 ebx: f7c076fc ecx: 00000001 edx: f7c07558
esi: c047c8e0 edi: 00000000 epb: f7c33f80 esp: f7c33f38
Warning (Oops_set_regs): garbage 'epb: f7c33f80 esp: f7c33f38' at end
of register line ignored
ds: 007b es: 007b ss: 0068
Stack: c02416fb c047bcc8 c047c94c f7c33f54 c047c94c ffffffea c047c920 f7c33f70
00000246 c047c94c 00000000 c047bc64 c047bc00 c047c920 f7c33f94 f7c076fc
c047c8e0 00000000 f7c33f94 c02f1aa1 f7c07558 c047c8c8 c02f1ab0 f7c33fb0
Call trace:
[<c0104d7f>] show_stack+0x74/0xa0
[<c0104f1a>] show_registers+0x15a/0x1c0
[<c0105184>] die+0x164/0x2e0
[<c0119936>] do_page_fault+0x356/0x68d
[<c0104853>] error_code+0x4f/0x54
[<c02f1aa1>] eeprom_attach_adapter+0x21/0x30
[<c02ee704>] i2c_add_driver+0xb4/0xe0
[<c050a652>] eeprom_init+0x12/0x40
[<c04ee8ab>] do_initcalls+0x2b/0xc0
[<c0100302>] init+0x32/0x130
[<c0101351>] kernel_thread_helper+0x5/0x14
Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 55 89 e5 57 56 53 83 ec 3c 8b 55 08 8b 42 0c <81>
78 20 00 00 05 00 c7 45 e4 e7 23 00 00 0f 94 c0 0f b6 c0 85
>>EIP; c02f094f <i2c_detect+f/500> <==
>>ebx; f7c076fc <pg0+376a46fc/3fa9b400>
>>edx; f7c07558 <pg0+376a4558/3fa9b400>
>>esi; c047c8e0 <eeprom_driver+0/e0>
Trace; c0104d7f <show_stack+7f/a0>
Trace; c0104f1a <show_registers+15a/1c0>
Trace; c0105184 <die+164/2e0>
Trace; c0119936 <do_page_fault+356/68d>
Trace; c0104853 <error_code+4f/54>
Trace; c02f1aa1 <eeprom_attach_adapter+21/30>
Trace; c02ee704 <i2c_add_driver+b4/e0>
Trace; c050a652 <eeprom_init+12/40>
Trace; c04ee8ab <do_initcalls+2b/c0>
Trace; c0100302 <init+32/130>
Trace; c0101351 <kernel_thread_helper+5/14>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; c02f0924 <.text.lock.i2c_core+1be/1da>
00000000 <_EIP>:
Code; c02f0924 <.text.lock.i2c_core+1be/1da>
0: 90 nop
Code; c02f0925 <.text.lock.i2c_core+1bf/1da>
1: 90 nop
Code; c02f0926 <.text.lock.i2c_core+1c0/1da>
2: 90 nop
Code; c02f0927 <.text.lock.i2c_core+1c1/1da>
3: 90 nop
Code; c02f0928 <.text.lock.i2c_core+1c2/1da>
4: 90 nop
Code; c02f0929 <.text.lock.i2c_core+1c3/1da>
5: 90 nop
Code; c02f092a <.text.lock.i2c_core+1c4/1da>
6: 90 nop
Code; c02f092b <.text.lock.i2c_core+1c5/1da>
7: 90 nop
Code; c02f092c <.text.lock.i2c_core+1c6/1da>
8: 90 nop
Code; c02f092d <.text.lock.i2c_core+1c7/1da>
9: 90 nop
Code; c02f092e <.text.lock.i2c_core+1c8/1da>
a: 90 nop
Code; c02f092f <.text.lock.i2c_core+1c9/1da>
b: 90 nop
Code; c02f0930 <.text.lock.i2c_core+1ca/1da>
c: 90 nop
Code; c02f0931 <.text.lock.i2c_core+1cb/1da>
d: 90 nop
Code; c02f0932 <.text.lock.i2c_core+1cc/1da>
e: 90 nop
Code; c02f0933 <.text.lock.i2c_core+1cd/1da>
f: 90 nop
Code; c02f0934 <.text.lock.i2c_core+1ce/1da>
10: 90 nop
Code; c02f0935 <.text.lock.i2c_core+1cf/1da>
11: 90 nop
Code; c02f0936 <.text.lock.i2c_core+1d0/1da>
12: 90 nop
Code; c02f0937 <.text.lock.i2c_core+1d1/1da>
13: 90 nop
Code; c02f0938 <.text.lock.i2c_core+1d2/1da>
14: 90 nop
Code; c02f0939 <.text.lock.i2c_core+1d3/1da>
15: 90 nop
Code; c02f093a <.text.lock.i2c_core+1d4/1da>
16: 90 nop
Code; c02f093b <.text.lock.i2c_core+1d5/1da>
17: 90 nop
Code; c02f093c <.text.lock.i2c_core+1d6/1da>
18: 90 nop
Code; c02f093d <.text.lock.i2c_core+1d7/1da>
19: 90 nop
Code; c02f093e <.text.lock.i2c_core+1d8/1da>
1a: 90 nop
Code; c02f093f <.text.lock.i2c_core+1d9/1da>
1b: 90 nop
Code; c02f0940 <i2c_detect+0/500>
1c: 55 push %ebp
Code; c02f0941 <i2c_detect+1/500>
1d: 89 e5 mov %esp,%ebp
Code; c02f0943 <i2c_detect+3/500>
1f: 57 push %edi
Code; c02f0944 <i2c_detect+4/500>
20: 56 push %esi
Code; c02f0945 <i2c_detect+5/500>
21: 53 push %ebx
Code; c02f0946 <i2c_detect+6/500>
22: 83 ec 3c sub $0x3c,%esp
Code; c02f0949 <i2c_detect+9/500>
25: 8b 55 08 mov 0x8(%ebp),%edx
Code; c02f094c <i2c_detect+c/500>
28: 8b 42 0c mov 0xc(%edx),%eax
This decode from eip onwards should be reliable
Code; c02f094f <i2c_detect+f/500>
00000000 <_EIP>:
Code; c02f094f <i2c_detect+f/500> <== 0: 81 78 20 00 00 05 00 cmpl $0x50000,0x20(%eax) <==Code; c02f0956 <i2c_detect+16/500>
7: c7 45 e4 e7 23 00 00 movl $0x23e7,0xffffffe4(%ebp)
Code; c02f095d <i2c_detect+1d/500>
e: 0f 94 c0 sete %al
Code; c02f0960 <i2c_detect+20/500>
11: 0f b6 c0 movzbl %al,%eax
Code; c02f0963 <i2c_detect+23/500>
14: 85 .byte 0x85
<0>Kernel panic - not syncing: Attempted to kill init!
1 warning and 1 error issued. Results may not be reliable.
(gdb) x/30i 0xc02f094f
0xc02f094f <i2c_detect+15>: cmpl $0x50000,0x20(%eax)
0xc02f0956 <i2c_detect+22>: movl $0x23e7,0xffffffe4(%ebp)
0xc02f095d <i2c_detect+29>: sete %al
0xc02f0960 <i2c_detect+32>: movzbl %al,%eax
0xc02f0963 <i2c_detect+35>: test %eax,%eax
0xc02f0965 <i2c_detect+37>: mov %eax,0xffffffe8(%ebp)
0xc02f0968 <i2c_detect+40>: je 0xc02f0e1c <i2c_detect+1244>
0xc02f096e <i2c_detect+46>: mov 0xffffffe8(%ebp),%eax
0xc02f0971 <i2c_detect+49>: test %eax,%eax
0xc02f0973 <i2c_detect+51>: je 0xc02f0df7 <i2c_detect+1207>
0xc02f0979 <i2c_detect+57>: mov 0xc(%ebp),%edx
0xc02f097c <i2c_detect+60>: movl $0xc047bf00,0xffffffd8(%ebp)
0xc02f0983 <i2c_detect+67>: movl $0xc047bf00,0xffffffd4(%ebp)
0xc02f098a <i2c_detect+74>: movl $0xc047bf04,0xffffffdc(%ebp)
0xc02f0991 <i2c_detect+81>: mov (%edx),%eax
0xc02f0993 <i2c_detect+83>: test %eax,%eax
0xc02f0995 <i2c_detect+85>: cmove 0xffffffd8(%ebp),%eax
0xc02f0999 <i2c_detect+89>: mov %eax,0xffffffe0(%ebp)
0xc02f099c <i2c_detect+92>: mov 0x4(%edx),%eax
0xc02f099f <i2c_detect+95>: test %eax,%eax
0xc02f09a1 <i2c_detect+97>: cmove 0xffffffdc(%ebp),%eax
0xc02f09a5 <i2c_detect+101>: mov %eax,0xffffffdc(%ebp)
0xc02f09a8 <i2c_detect+104>: mov 0x8(%edx),%eax
0xc02f09ab <i2c_detect+107>: test %eax,%eax
0xc02f09ad <i2c_detect+109>: cmove 0xffffffd8(%ebp),%eax
0xc02f09b1 <i2c_detect+113>: mov %eax,0xffffffd8(%ebp)
0xc02f09b4 <i2c_detect+116>: mov 0xc(%edx),%eax
0xc02f09b7 <i2c_detect+119>: movl $0x0,0xfffffff0(%ebp)
0xc02f09be <i2c_detect+126>: test %eax,%eax
0xc02f09c0 <i2c_detect+128>: cmove 0xffffffd4(%ebp),%eax
I hope this helps,
Miles
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (16 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Andrew Morton
2005-05-19 6:25 ` Miles Lane
` (23 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Andrew Morton @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Miles Lane <miles.lane@gmail.com> wrote:
>
> On Fri, 18 Mar 2005 13:07:08 +0100 (CET), Jean Delvare
> <khali@linux-fr.org> wrote:
>
> > Miles, could you please try to modify your oopsing configuration in the
> > following way:
> > CONFIG_I2C_CHARDEV=n
> > CONFIG_SENSORS_EEPROM=y
> > I would expect if to oops in i2c_add_driver() as well.
>
> I had to copy this by hand, but I think I got it all down correctly.
Is worthwhile.
>
> >>EIP; c02f094f <i2c_detect+f/500> <==>
> >>ebx; f7c076fc <pg0+376a46fc/3fa9b400>
> >>edx; f7c07558 <pg0+376a4558/3fa9b400>
> >>esi; c047c8e0 <eeprom_driver+0/e0>
>
> Trace; c0104d7f <show_stack+7f/a0>
> Trace; c0104f1a <show_registers+15a/1c0>
> Trace; c0105184 <die+164/2e0>
> Trace; c0119936 <do_page_fault+356/68d>
> Trace; c0104853 <error_code+4f/54>
> Trace; c02f1aa1 <eeprom_attach_adapter+21/30>
> Trace; c02ee704 <i2c_add_driver+b4/e0>
> Trace; c050a652 <eeprom_init+12/40>
> Trace; c04ee8ab <do_initcalls+2b/c0>
> Trace; c0100302 <init+32/130>
> Trace; c0101351 <kernel_thread_helper+5/14>
Ah. adapter->algo is NULL in i2c_detect(). I don't think i2c_adapters are
allowed to do that. It could have been any old adapter, registered at some
earlier time.
If I'm right, this debug patch should point us at the culprit.
diff -puN drivers/i2c/i2c-core.c~a drivers/i2c/i2c-core.c
--- 25/drivers/i2c/i2c-core.c~a 2005-03-21 22:38:00.000000000 -0800
+++ 25-akpm/drivers/i2c/i2c-core.c 2005-03-21 22:39:27.000000000 -0800
@@ -150,6 +150,13 @@ int i2c_add_adapter(struct i2c_adapter *
struct list_head *item;
struct i2c_driver *driver;
+ if (adap->algo = NULL) {
+ printk("%s: adap->algo is NULL\n", __FUNCTION__);
+ dump_stack();
+ for ( ; ; )
+ ;
+ }
+
down(&core_lists);
if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) = 0) {
_
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (17 preceding siblings ...)
2005-05-19 6:25 ` Andrew Morton
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Greg KH
` (22 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Unable to haUnable to handle kernel paging request at virtual address f8e813d4
c020c94d
*pde = 00000000
Oops: 0002 [#1]
CPU: 0
EIP: 0060:[<c020c94d>} Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202 (2.6.12-rc1)
eax: f8e81000 ebx: f7c00240 ecx: f7c00538 edx: 0000003f
esi: 00000001 edi: 00000001 epb: f7c21db0 esp: f7c21da8
Warning (Oops_set_regs): garbage 'epb: f7c21db0 esp: f7c21da8' at end
of register line ignored
ds: 007b es: 007b ss: 0068
Stack: f7c00708 00000001 f7c21dc4 c027f225 f7c00538 00000000 f7c00540 f7c21e20
c027fcca f7c00708 00000000 f7c21e35 ffffffff c0334220
30000000 f7c23530
f7c21e08 c0115d41 c17fca20 f7c21e08 c17fca20 00000086
f7c21e20 f7c00540
Call trace:
[<c010400f>] show_stack+0x7f/0xa0
[<c01041aa>] show_registers+0x15a/0x1c0
[<c01043ac>] die+0xfc/0x190
[<c011438b>] do_page_fault+0x31b/0x670
[<c0103c43>] error_code+0x2b/0x30
[<c027f225>] i2c_start+0x25/0x60
[<c027fcca>] bit_xfer+0x1a/0x690
[<c027bb88>] i2c_transfer+0x68/0xb0
[<c027cb79>] i2c_smbus_xfer_emulated+0xb9/0x3b0
[<c027cf9f>] i2c_smbus_xfer+0x12f/0x220
[<c027e0ba>] i2c_detect+0x23a/0x500
[<c027ef91>] eeprom_attach_adapter+0x21/0x30
[<c027b243>] i2c_add_driver+0xd3/0x100
[<c0466452>] eeprom_init+0x12/0x40
[<c044c8ab>] do_initcalls+0x2b/0xc0
[<c0100302>] init+0x32/0x130
[<c0101301>] kernel_thread_helper+0x5/0x14
Code: 00 00 8b 74 24 04 8b 1c 24 c9 c3 8d 76 00 55 89 e5 83 ec 08 8b
>>EIP; c020c94d <nvidia_gpio_setsda+1d/70> <==
>>eax; f8e81000 <pg0+389c7000/3fb44400>
>>ebx; f7c00240 <pg0+37746240/3fb44400>
>>ecx; f7c00538 <pg0+37746538/3fb44400>
Trace; c010400f <show_stack+7f/a0>
Trace; c01041aa <show_registers+15a/1c0>
Trace; c01043ac <die+fc/190>
Trace; c011438b <do_page_fault+31b/670>
Trace; c0103c43 <error_code+2b/30>
Trace; c027f225 <i2c_start+25/60>
Trace; c027fcca <bit_xfer+1a/690>
Trace; c027bb88 <i2c_transfer+68/b0>
Trace; c027cb79 <i2c_smbus_xfer_emulated+b9/3b0>
Trace; c027cf9f <i2c_smbus_xfer+12f/220>
Trace; c027e0ba <i2c_detect+23a/500>
Trace; c027ef91 <eeprom_attach_adapter+21/30>
Trace; c027b243 <i2c_add_driver+d3/100>
Trace; c0466452 <eeprom_init+12/40>
Trace; c044c8ab <do_initcalls+2b/c0>
Trace; c0100302 <init+32/130>
Trace; c0101301 <kernel_thread_helper+5/14>
Code; c020c94d <nvidia_gpio_setsda+1d/70>
00000000 <_EIP>:
Code; c020c94d <nvidia_gpio_setsda+1d/70> <== 0: 00 00 add %al,(%eax) <==Code; c020c94f <nvidia_gpio_setsda+1f/70>
2: 8b 74 24 04 mov 0x4(%esp),%esi
Code; c020c953 <nvidia_gpio_setsda+23/70>
6: 8b 1c 24 mov (%esp),%ebx
Code; c020c956 <nvidia_gpio_setsda+26/70>
9: c9 leave
Code; c020c957 <nvidia_gpio_setsda+27/70>
a: c3 ret
Code; c020c958 <nvidia_gpio_setsda+28/70>
b: 8d 76 00 lea 0x0(%esi),%esi
Code; c020c95b <nvidia_gpio_setsda+2b/70>
e: 55 push %ebp
Code; c020c95c <nvidia_gpio_setsda+2c/70>
f: 89 e5 mov %esp,%ebp
Code; c020c95e <nvidia_gpio_setsda+2e/70>
11: 83 ec 08 sub $0x8,%esp
Code; c020c961 <nvidia_gpio_setsda+31/70>
14: 8b 00 mov (%eax),%eax
<0>Kernel panic - not syncing: Attempted to kill init!
ndle kernel paging request at virtual address f8e813d4
c020c94d
*pde = 00000000
Oops: 0002 [#1]
CPU: 0
EIP: 0060:[<c020c94d>} Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202 (2.6.12-rc1)
eax: f8e81000 ebx: f7c00240 ecx: f7c00538 edx: 0000003f
esi: 00000001 edi: 00000001 epb: f7c21db0 esp: f7c21da8
Warning (Oops_set_regs): garbage 'epb: f7c21db0 esp: f7c21da8' at end
of register line ignored
ds: 007b es: 007b ss: 0068
Stack: f7c00708 00000001 f7c21dc4 c027f225 f7c00538 00000000 f7c00540 f7c21e20
c027fcca f7c00708 00000000 f7c21e35 ffffffff c0334220
30000000 f7c23530
f7c21e08 c0115d41 c17fca20 f7c21e08 c17fca20 00000086
f7c21e20 f7c00540
Call trace:
[<c010400f>] show_stack+0x7f/0xa0
[<c01041aa>] show_registers+0x15a/0x1c0
[<c01043ac>] die+0xfc/0x190
[<c011438b>] do_page_fault+0x31b/0x670
[<c0103c43>] error_code+0x2b/0x30
[<c027f225>] i2c_start+0x25/0x60
[<c027fcca>] bit_xfer+0x1a/0x690
[<c027bb88>] i2c_transfer+0x68/0xb0
[<c027cb79>] i2c_smbus_xfer_emulated+0xb9/0x3b0
[<c027cf9f>] i2c_smbus_xfer+0x12f/0x220
[<c027e0ba>] i2c_detect+0x23a/0x500
[<c027ef91>] eeprom_attach_adapter+0x21/0x30
[<c027b243>] i2c_add_driver+0xd3/0x100
[<c0466452>] eeprom_init+0x12/0x40
[<c044c8ab>] do_initcalls+0x2b/0xc0
[<c0100302>] init+0x32/0x130
[<c0101301>] kernel_thread_helper+0x5/0x14
Code: 00 00 8b 74 24 04 8b 1c 24 c9 c3 8d 76 00 55 89 e5 83 ec 08 8b
>>EIP; c020c94d <nvidia_gpio_setsda+1d/70> <==
>>eax; f8e81000 <pg0+389c7000/3fb44400>
>>ebx; f7c00240 <pg0+37746240/3fb44400>
>>ecx; f7c00538 <pg0+37746538/3fb44400>
Trace; c010400f <show_stack+7f/a0>
Trace; c01041aa <show_registers+15a/1c0>
Trace; c01043ac <die+fc/190>
Trace; c011438b <do_page_fault+31b/670>
Trace; c0103c43 <error_code+2b/30>
Trace; c027f225 <i2c_start+25/60>
Trace; c027fcca <bit_xfer+1a/690>
Trace; c027bb88 <i2c_transfer+68/b0>
Trace; c027cb79 <i2c_smbus_xfer_emulated+b9/3b0>
Trace; c027cf9f <i2c_smbus_xfer+12f/220>
Trace; c027e0ba <i2c_detect+23a/500>
Trace; c027ef91 <eeprom_attach_adapter+21/30>
Trace; c027b243 <i2c_add_driver+d3/100>
Trace; c0466452 <eeprom_init+12/40>
Trace; c044c8ab <do_initcalls+2b/c0>
Trace; c0100302 <init+32/130>
Trace; c0101301 <kernel_thread_helper+5/14>
Code; c020c94d <nvidia_gpio_setsda+1d/70>
00000000 <_EIP>:
Code; c020c94d <nvidia_gpio_setsda+1d/70> <== 0: 00 00 add %al,(%eax) <==Code; c020c94f <nvidia_gpio_setsda+1f/70>
2: 8b 74 24 04 mov 0x4(%esp),%esi
Code; c020c953 <nvidia_gpio_setsda+23/70>
6: 8b 1c 24 mov (%esp),%ebx
Code; c020c956 <nvidia_gpio_setsda+26/70>
9: c9 leave
Code; c020c957 <nvidia_gpio_setsda+27/70>
a: c3 ret
Code; c020c958 <nvidia_gpio_setsda+28/70>
b: 8d 76 00 lea 0x0(%esi),%esi
Code; c020c95b <nvidia_gpio_setsda+2b/70>
e: 55 push %ebp
Code; c020c95c <nvidia_gpio_setsda+2c/70>
f: 89 e5 mov %esp,%ebp
Code; c020c95e <nvidia_gpio_setsda+2e/70>
11: 83 ec 08 sub $0x8,%esp
Code; c020c961 <nvidia_gpio_setsda+31/70>
14: 8b 00 mov (%eax),%eax
<0>Kernel panic - not syncing: Attempted to kill init!
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (18 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Greg KH
2005-05-19 6:25 ` Jean Delvare
` (21 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Greg KH @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
On Mon, Mar 21, 2005 at 06:16:41PM -0800, Andrew Morton wrote:
> Jean Delvare <khali@linux-fr.org> wrote:
> >
> > Hi Tony,
> >
> > > I've only seen the savage bug report. Yes, unfortunately, this is the
> > > case of 2 drivers attempting to control a single device since the
> > > savagefb and the i2c prosavage drivers will attempt to ioremap the
> > > same mmio region. If you need the i2c prosavage bus, then savagefb
> > > must be completely disabled, as setting CONFIG_FB_SAVAGE_I2C to n will
> > > not help. If both savagefb and i2c are needed, then you just have to
> > > use the i2c bus registered by savagefb.
> >
> > I understand the problem you describe, and it should certainly be
> > addressed by Kconfig dependencies. However, I don't think this is the
> > problem here. If you look at the configuration file, you'll see that
> > neither i2c-prosavage nor i2c-savage4 are enabled:
> >
> > # CONFIG_I2C_PROSAVAGE is not set
> > # CONFIG_I2C_SAVAGE4 is not set
> >
> > > And yes, there is code duplication, but unfortunately savagefb cannot
> > > use the i2c-prosavage bus since one of them will fail to acquire the
> > > io regions.
> >
> > I wonder if the standalone i2c drivers are needed at all anymore, now
> > that the framebuffer driver includes the same functionality.
> >
> > > I haven't seen the nvidiafb report, but it is probably something
> > > similar.
> >
> > Note that there is no i2c bus driver for nvidia graphics adapters in the
> > kernel tree. The conflicting driver is rivatv and it lives outside the
> > kernel tree.
> >
> > Miles, are you by any chance using rivatv?
> >
> > Tony, Miles' original report is here:
> > http://marc.theaimsgroup.com/?l=linux-kernel&m\x111076667232062&w=2
> > Sorry for providing the link before.
>
> (I'm getting in a mess here. bugzilla is good for some things after all)
>
> Do we consider this to all be fixed up now?
I thought so. Jean?
greg k-h
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (19 preceding siblings ...)
2005-05-19 6:25 ` Greg KH
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Miles Lane
` (20 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
> > I think we would spare a significant amount of time if Miles could
> > test Tony's patch to nvidiafb - unless he already tried and I am
> > not aware? Miles?
>
> Perhaps you could resend it?
Sure.
diff -Nru a/drivers/video/nvidia/nv_i2c.c b/drivers/video/nvidia/nv_i2c.c
--- a/drivers/video/nvidia/nv_i2c.c 2005-03-12 23:25:10 +08:00
+++ b/drivers/video/nvidia/nv_i2c.c 2005-03-18 21:06:28 +08:00
@@ -146,7 +146,6 @@
nvidia_setup_i2c_bus(&par->chan[2], "BUS3");
}
-#if 0
void nvidia_delete_i2c_busses(struct nvidia_par *par)
{
if (par->chan[0].par)
@@ -162,7 +161,6 @@
par->chan[2].par = NULL;
}
-#endif /* 0 */
static u8 *nvidia_do_probe_i2c_edid(struct nvidia_i2c_chan *chan)
{
diff -Nru a/drivers/video/nvidia/nv_of.c b/drivers/video/nvidia/nv_of.c
--- a/drivers/video/nvidia/nv_of.c 2005-03-12 23:25:11 +08:00
+++ b/drivers/video/nvidia/nv_of.c 2005-03-18 21:06:28 +08:00
@@ -28,6 +28,7 @@
#include "nv_proto.h"
void nvidia_create_i2c_busses(struct nvidia_par *par) {}
+void nvidia_delete_i2c_busses(struct nvidia_par *par) {}
int nvidia_probe_i2c_connector(struct nvidia_par *par, int conn, u8 **out_edid)
{
diff -Nru a/drivers/video/nvidia/nv_proto.h b/drivers/video/nvidia/nv_proto.h
--- a/drivers/video/nvidia/nv_proto.h 2005-03-12 23:25:12 +08:00
+++ b/drivers/video/nvidia/nv_proto.h 2005-03-18 21:06:28 +08:00
@@ -33,10 +33,12 @@
/* in nvidia-i2c.c */
#if defined(CONFIG_FB_NVIDIA_I2C) || defined (CONFIG_PPC_OF)
void nvidia_create_i2c_busses(struct nvidia_par *par);
+void nvidia_delete_i2c_busses(struct nvidia_par *par);
int nvidia_probe_i2c_connector(struct nvidia_par *par, int conn,
u8 ** out_edid);
#else
#define nvidia_create_i2c_busses(...)
+#define nvidia_delete_i2c_busses(...)
#define nvidia_probe_i2c_connector(p, c, edid) \
do { \
*(edid) = NULL; \
diff -Nru a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
--- a/drivers/video/nvidia/nvidia.c 2005-03-15 18:42:12 +08:00
+++ b/drivers/video/nvidia/nvidia.c 2005-03-18 21:22:39 +08:00
@@ -1566,8 +1566,9 @@
err_out_iounmap_fb:
iounmap(info->screen_base);
- err_out_free_base1:
fb_destroy_modedb(info->monspecs.modedb);
+ nvidia_delete_i2c_busses(par);
+ err_out_free_base1:
iounmap(par->REGS);
err_out_free_base0:
pci_release_regions(pd);
@@ -1597,9 +1598,10 @@
info->fix.smem_len);
#endif /* CONFIG_MTRR */
+ iounmap(info->screen_base);
fb_destroy_modedb(info->monspecs.modedb);
+ nvidia_delete_i2c_busses(par);
iounmap(par->REGS);
- iounmap(info->screen_base);
pci_release_regions(pd);
pci_disable_device(pd);
kfree(info->pixmap.addr);
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (20 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Miles Lane
` (19 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Good news!
The OOPS is gone with your patch. I tested with both the EEPROM and
NVidia drivers built into the kernel. I have included the debugging
output from your latest patch below:
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y
CONFIG_I2C_ISA=y
CONFIG_I2C_NFORCE2=y
CONFIG_I2C_SENSOR=y
CONFIG_SENSORS_ADM1021=y
CONFIG_SENSORS_ADM1025=y
CONFIG_SENSORS_ADM1026=y
CONFIG_SENSORS_ADM1031=y
CONFIG_SENSORS_LM63=y
CONFIG_SENSORS_LM75=y
CONFIG_SENSORS_LM77=y
CONFIG_SENSORS_LM78=y
CONFIG_SENSORS_LM80=y
CONFIG_SENSORS_LM83=y
CONFIG_SENSORS_LM85=y
CONFIG_SENSORS_LM87=y
CONFIG_SENSORS_LM90=y
CONFIG_SENSORS_EEPROM=y
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y
Linux version 2.6.12-rc1 (root@Monkey100) (gcc version 3.3.5 (Debian
1:3.3.5-12)) #2 Tue Mar 22 13:40:51 EST 2005
i2c /dev entries driver
i2c-core: driver dev_driver registered.
i2c_adapter i2c-0: Registered as minor 0
i2c_adapter i2c-0: registered as adapter #0
i2c_adapter i2c-1: Registered as minor 1
i2c_adapter i2c-1: registered as adapter #1
i2c_adapter i2c-1: nForce2 SMBus adapter at 0x5000
i2c_adapter i2c-2: Registered as minor 2
i2c_adapter i2c-2: registered as adapter #2
i2c_adapter i2c-2: nForce2 SMBus adapter at 0x5500
i2c-core: driver adm1021 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 18
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 19
input: AT Translated Set 2 keyboard on isa0060/serio0
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 1a
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 29
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2a
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2b
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4e
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 18
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 19
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 1a
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 29
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2a
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2b
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4d
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4e
i2c-core: driver adm1025 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2e
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2d
i2c_adapter i2c-2: ADM1025 detection failed at 0x2d.
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2e
i2c_adapter i2c-2: ADM1025 detection failed at 0x2e.
i2c-core: driver adm1026 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2e
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2d
: Detecting device at 2,0x2d with COMPANY: 0x00 and VERSTEP: 0x19
: Autodetecting device at 2,0x2d ...
: : Autodetection failed
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2e
: Detecting device at 2,0x2e with COMPANY: 0xff and VERSTEP: 0xff
: Autodetecting device at 2,0x2e ...
: : Autodetection failed
i2c-core: driver adm1031 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2e
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2d
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2e
i2c-core: driver eeprom registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 50
i2c_adapter i2c-1: client [eeprom] registered to adapter
registering 1-0050
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 51
i2c_adapter i2c-1: client [eeprom] registered to adapter
registering 1-0051
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 52
i2c_adapter i2c-1: client [eeprom] registered to adapter
registering 1-0052
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 53
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 54
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 55
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 56
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 57
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 50
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 51
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 52
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 53
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 54
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 55
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 56
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 57
i2c-core: driver lm63 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4c
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4c
i2c-core: driver lm75 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 48
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 49
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4a
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4b
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4e
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4f
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 48
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 49
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4a
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4b
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4d
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4e
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4f
i2c-core: driver lm77 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 48
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 49
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4a
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4b
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 48
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 49
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4a
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4b
i2c-core: driver lm78 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
i2c_adapter i2c-0: found normal isa entry for adapter 9191, addr 0290
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 20
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 21
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 22
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 23
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 24
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 25
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 26
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 27
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 28
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 29
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2a
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2b
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2e
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2f
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 20
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 21
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 22
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 23
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 24
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 25
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 26
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 27
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 28
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 29
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2a
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2b
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2d
i2c-core: driver lm80 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 28
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 29
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2a
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2b
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2e
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2f
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 28
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 29
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2a
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2b
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2d
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2e
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2f
i2c-core: driver lm83 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 18
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 19
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 1a
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 29
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2a
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2b
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4e
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 18
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 19
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 1a
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 29
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2a
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2b
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4d
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4e
i2c-core: driver lm85 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2e
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2d
i2c_adapter i2c-2: Detecting device at 2,0x2d with COMPANY: 0x00 and
VERSTEP: 0x00
i2c_adapter i2c-2: Autodetecting device at 2,0x2d ...
i2c_adapter i2c-2: Autodetection failed
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2e
i2c_adapter i2c-2: Detecting device at 2,0x2e with COMPANY: 0x00 and
VERSTEP: 0x00
i2c_adapter i2c-2: Autodetecting device at 2,0x2e ...
i2c_adapter i2c-2: Autodetection failed
i2c-core: driver lm87 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2d
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 2e
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2d
i2c_adapter i2c-2: LM87 detection failed at 0x2d.
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 2e
i2c_adapter i2c-2: LM87 detection failed at 0x2e.
i2c-core: driver lm90 registered.
drivers/i2c/busses/i2c-isa.c:59: c03eede0
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4c
i2c_adapter i2c-1: found normal i2c entry for adapter 1, addr 4d
drivers/i2c/busses/i2c-nforce2.c:332: c03ef000
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4c
i2c_adapter i2c-2: found normal i2c entry for adapter 2, addr 4d
-- Miles
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (21 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Jean Delvare
` (18 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hello,
I think I decoded this Oops correctly. The crash occurs before the
disk is mounted, so I am unable to access the contents of /proc/ksyms
and /proc/modules. However, the decoding using the modules and
System.map looks reasonable. Is the decoding accurate?
ksymoops -o /lib/modules/2.6.12-rc1-mm1/ -m
/boot/System.map-2.6.12-rc1-mm1 < oops
ksymoops 2.4.9 on i686 2.6.11-bk5. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.12-rc1-mm1/ (specified)
-m /boot/System.map-2.6.12-rc1-mm1 (specified)
Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel NULL pointer dereference at virtual address 00000000
C028bbc2
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c028bbc2>] Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282 (2.6.11-mm3)
Eax: 00000000 ebx: 00000000 ecx: 00000000 edx: f7e99504
Esi: c03f5260 edi: 00000000 ebp: f7c21fa4 esp: f7c21f90
Ds: 007b es: 007b ss: 0068
Stack: f7c00540 c03f5264 00000000 00000000 00000000 f7c21fbc c0480695 c03f5260
c03724f8 c03f5140 c048d204 f7c21fd8 c04668ab c01002d0 00000000 00000000
c01002d0 00000000 f7c21fec c0100302 0000007b 0000007b ffffffff 00000000
Call Trace:
[<c010404f>] show_stack+0x7f/0xa0
[<c01041ea>] show_registers+0x15a/0x1c0
[<c01043e0>] die+0xf0/0x190
[<c011450b>] do_page_fault+0x31b/0x670
[<c0103c83>] error_code+0x2b/0x30
[<c0480695>] i2c_dev_init+0x55/0xa0
[<c04668ab>] do_initcalls+0x2b/0xc0
[<c0100302>] init+0x32/0x130
[<c0101351>] kernel_thread_helper+0x5/0x14
Code: e5 e8 ff f6 46 2c 01 74 30 8b 1d a0 4e 3f c0 8b 03 0f 18 00 90
>>EIP; c028bbc2 <pnp_assign_mem+82/140> <==
>>edx; f7e99504 <pg0+37936504/3fa9b400>
>>Esi; c03f5260 <__func__.2+1edc5/3adbd>
>>ebp; f7c21fa4 <pg0+376befa4/3fa9b400>
>>esp; f7c21f90 <pg0+376bef90/3fa9b400>
Trace; c010404f <irq_entries_start+183/880>
Trace; c01041ea <irq_entries_start+31e/880>
Trace; c01043e0 <irq_entries_start+514/880>
Trace; c011450b <_setbad+401/6f6>
Trace; c0103c83 <ret_from_fork+3/14>
Trace; c0480695 <texts.16+5/8>
Trace; c04668ab <__devices_8086+acb/eb0>
Trace; c0100302 <init+32/130>
Trace; c0101351 <kernel_thread_helper+5/14>
Code; c028bbc2 <pnp_assign_mem+82/140>
00000000 <_EIP>:
Code; c028bbc2 <pnp_assign_mem+82/140> <== 0: e5 e8 in $0xe8,%eax <==Code; c028bbc4 <pnp_assign_mem+84/140>
2: ff f6 push %esi
Code; c028bbc6 <pnp_assign_mem+86/140>
4: 46 inc %esi
Code; c028bbc7 <pnp_assign_mem+87/140>
5: 2c 01 sub $0x1,%al
Code; c028bbc9 <pnp_assign_mem+89/140>
7: 74 30 je 39 <_EIP+0x39>
Code; c028bbcb <pnp_assign_mem+8b/140>
9: 8b 1d a0 4e 3f c0 mov 0xc03f4ea0,%ebx
Code; c028bbd1 <pnp_assign_mem+91/140>
f: 8b 03 mov (%ebx),%eax
Code; c028bbd3 <pnp_assign_mem+93/140>
11: 0f 18 00 prefetchnta (%eax)
Code; c028bbd6 <pnp_assign_mem+96/140>
14: 90 nop
<0>Kernel panic ??" not syncing: Attempted to kill init!
1 error issued. Results may not be reliable.
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (22 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Andrew Morton
` (17 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Andrew,
> > >>EIP; c02f094f <i2c_detect+f/500> <==> >
> > >>ebx; f7c076fc <pg0+376a46fc/3fa9b400>
> > >>edx; f7c07558 <pg0+376a4558/3fa9b400>
> > >>esi; c047c8e0 <eeprom_driver+0/e0>
> >
> > Trace; c0104d7f <show_stack+7f/a0>
> > Trace; c0104f1a <show_registers+15a/1c0>
> > Trace; c0105184 <die+164/2e0>
> > Trace; c0119936 <do_page_fault+356/68d>
> > Trace; c0104853 <error_code+4f/54>
> > Trace; c02f1aa1 <eeprom_attach_adapter+21/30>
> > Trace; c02ee704 <i2c_add_driver+b4/e0>
> > Trace; c050a652 <eeprom_init+12/40>
> > Trace; c04ee8ab <do_initcalls+2b/c0>
> > Trace; c0100302 <init+32/130>
> > Trace; c0101351 <kernel_thread_helper+5/14>
>
> Ah. adapter->algo is NULL in i2c_detect().
Forgive a possibly stupid question, but how did you manage to come to
this conclusion from the stack above alone? Is there any magic I am not
aware of?
My first impression was that the adapter itself was missing, like it had
been deleted without being removed from the main i2c adapters list.
Anyway, this test at leasted proved one thing: the i2c-dev driver isn't
involved in the oops per se. Using a different i2c chip driver (eeprom
here) triggers it as well. This tends to confirm that the problem is
related to a specific i2c adapter driver.
> I don't think i2c_adapters are allowed to do that.
Correct, they are not.
> It could have been any old adapter, registered at some earlier time.
Except that we have a strong suspicion that it is nvidiafb, instead of
just any old adapter.
> If I'm right, this debug patch should point us at the culprit.
I doubt it will help (but let's still try). The nvidiafb i2c adapters
are added by i2c-algo-bit:i2c_bit_add_bus(), which does set
adapter->algo to &i2c_bit_algo right before it calls i2c_add_adapter. I
don't think that algo is NULL when the adapter is added. Rather, it
becomes NULL later, most possibly because adapter itself point to a now
gone structure. Just my theory though.
Maybe it would help if Miles could give a try to Tony's patch here and
report?
http://archives.andrew.net.au/lm-sensors/msg30044.html
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (23 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Andrew Morton
2005-05-19 6:25 ` Andrew Morton
` (16 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Andrew Morton @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Miles Lane <miles.lane@gmail.com> wrote:
>
> Unable to haUnable to handle kernel paging request at virtual address f8e813d4
> c020c94d
> *pde = 00000000
> Oops: 0002 [#1]
> CPU: 0
> EIP: 0060:[<c020c94d>} Not tainted VLI
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010202 (2.6.12-rc1)
> eax: f8e81000 ebx: f7c00240 ecx: f7c00538 edx: 0000003f
> esi: 00000001 edi: 00000001 epb: f7c21db0 esp: f7c21da8
> Warning (Oops_set_regs): garbage 'epb: f7c21db0 esp: f7c21da8' at end
> of register line ignored
> ds: 007b es: 007b ss: 0068
> Stack: f7c00708 00000001 f7c21dc4 c027f225 f7c00538 00000000 f7c00540 f7c21e20
> c027fcca f7c00708 00000000 f7c21e35 ffffffff c0334220
> 30000000 f7c23530
> f7c21e08 c0115d41 c17fca20 f7c21e08 c17fca20 00000086
> f7c21e20 f7c00540
> Call trace:
> [<c010400f>] show_stack+0x7f/0xa0
> [<c01041aa>] show_registers+0x15a/0x1c0
> [<c01043ac>] die+0xfc/0x190
> [<c011438b>] do_page_fault+0x31b/0x670
> [<c0103c43>] error_code+0x2b/0x30
> [<c027f225>] i2c_start+0x25/0x60
> [<c027fcca>] bit_xfer+0x1a/0x690
> [<c027bb88>] i2c_transfer+0x68/0xb0
> [<c027cb79>] i2c_smbus_xfer_emulated+0xb9/0x3b0
> [<c027cf9f>] i2c_smbus_xfer+0x12f/0x220
> [<c027e0ba>] i2c_detect+0x23a/0x500
> [<c027ef91>] eeprom_attach_adapter+0x21/0x30
> [<c027b243>] i2c_add_driver+0xd3/0x100
> [<c0466452>] eeprom_init+0x12/0x40
> [<c044c8ab>] do_initcalls+0x2b/0xc0
> [<c0100302>] init+0x32/0x130
> [<c0101301>] kernel_thread_helper+0x5/0x14
aargh. That's a totally different crash :(
Were you using this patch?
diff -puN include/linux/i2c.h~i2c-debugging include/linux/i2c.h
--- 25/include/linux/i2c.h~i2c-debugging 2005-03-22 02:02:53.000000000 -0800
+++ 25-akpm/include/linux/i2c.h 2005-03-22 02:06:50.000000000 -0800
@@ -244,6 +244,8 @@ struct i2c_adapter {
char name[I2C_NAME_SIZE];
struct completion dev_released;
struct completion class_dev_released;
+ char *file;
+ int line;
};
#define dev_to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
#define class_dev_to_i2c_adapter(d) container_of(d, struct i2c_adapter, class_dev)
@@ -314,7 +316,9 @@ struct i2c_client_address_data {
/* administration...
*/
-extern int i2c_add_adapter(struct i2c_adapter *);
+#define i2c_add_adapter(a) __i2c_add_adapter(__FILE__, __LINE__, a)
+
+extern int __i2c_add_adapter(char *file, int line, struct i2c_adapter *);
extern int i2c_del_adapter(struct i2c_adapter *);
extern int i2c_add_driver(struct i2c_driver *);
diff -puN drivers/i2c/i2c-core.c~i2c-debugging drivers/i2c/i2c-core.c
--- 25/drivers/i2c/i2c-core.c~i2c-debugging 2005-03-22 02:02:53.000000000 -0800
+++ 25-akpm/drivers/i2c/i2c-core.c 2005-03-22 02:02:53.000000000 -0800
@@ -144,12 +144,15 @@ static struct device_attribute dev_attr_
* when a new hw adapter registers. A new device is register to be
* available for clients.
*/
-int i2c_add_adapter(struct i2c_adapter *adap)
+int __i2c_add_adapter(char *file, int line, struct i2c_adapter *adap)
{
int id, res = 0;
struct list_head *item;
struct i2c_driver *driver;
+ adap->file = file;
+ adap->line = line;
+
down(&core_lists);
if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) = 0) {
@@ -310,6 +313,11 @@ int i2c_add_driver(struct i2c_driver *dr
if (driver->flags & I2C_DF_NOTIFY) {
list_for_each(item,&adapters) {
adapter = list_entry(item, struct i2c_adapter, list);
+ printk("%s:%d: %p\n", adapter->file, adapter->line,
+ adapter->algo);
+ if (adapter->algo = NULL)
+ for ( ; ; )
+ ;
driver->attach_adapter(adapter);
}
}
@@ -1246,7 +1254,7 @@ int i2c_check_functionality (struct i2c_
return (func & adap_func) = func;
}
-EXPORT_SYMBOL(i2c_add_adapter);
+EXPORT_SYMBOL(__i2c_add_adapter);
EXPORT_SYMBOL(i2c_del_adapter);
EXPORT_SYMBOL(i2c_add_driver);
EXPORT_SYMBOL(i2c_del_driver);
diff -puN drivers/i2c/algos/i2c-algo-bit.c~i2c-debugging drivers/i2c/algos/i2c-algo-bit.c
--- 25/drivers/i2c/algos/i2c-algo-bit.c~i2c-debugging 2005-03-22 02:03:15.000000000 -0800
+++ 25-akpm/drivers/i2c/algos/i2c-algo-bit.c 2005-03-22 02:04:31.000000000 -0800
@@ -528,10 +528,12 @@ static struct i2c_algorithm i2c_bit_algo
/*
* registering functions to load algorithms at runtime
*/
-int i2c_bit_add_bus(struct i2c_adapter *adap)
+int __i2c_bit_add_bus(char *file, int line, struct i2c_adapter *adap)
{
struct i2c_algo_bit_data *bit_adap = adap->algo_data;
+ adap->file = file;
+ adap->line = line;
if (bit_test) {
int ret = test_bus(bit_adap, adap->name);
if (ret<0)
@@ -558,7 +560,7 @@ int i2c_bit_del_bus(struct i2c_adapter *
return i2c_del_adapter(adap);
}
-EXPORT_SYMBOL(i2c_bit_add_bus);
+EXPORT_SYMBOL(__i2c_bit_add_bus);
EXPORT_SYMBOL(i2c_bit_del_bus);
MODULE_AUTHOR("Simon G. Vogl <simon@tk.uni-linz.ac.at>");
diff -puN include/linux/i2c-algo-bit.h~i2c-debugging include/linux/i2c-algo-bit.h
--- 25/include/linux/i2c-algo-bit.h~i2c-debugging 2005-03-22 02:03:33.000000000 -0800
+++ 25-akpm/include/linux/i2c-algo-bit.h 2005-03-22 02:05:08.000000000 -0800
@@ -48,7 +48,8 @@ struct i2c_algo_bit_data {
#define I2C_BIT_ADAP_MAX 16
-int i2c_bit_add_bus(struct i2c_adapter *);
+#define i2c_bit_add_bus(a) __i2c_bit_add_bus(__FILE__, __LINE__, a)
+int __i2c_bit_add_bus(char *file, int line, struct i2c_adapter *);
int i2c_bit_del_bus(struct i2c_adapter *);
#endif /* _LINUX_I2C_ALGO_BIT_H */
_
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (24 preceding siblings ...)
2005-05-19 6:25 ` Andrew Morton
@ 2005-05-19 6:25 ` Andrew Morton
2005-05-19 6:25 ` Miles Lane
` (15 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Andrew Morton @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
"Jean Delvare" <khali@linux-fr.org> wrote:
>
>
> Hi Andrew,
>
> > > >>EIP; c02f094f <i2c_detect+f/500> <==> > >
> > > >>ebx; f7c076fc <pg0+376a46fc/3fa9b400>
> > > >>edx; f7c07558 <pg0+376a4558/3fa9b400>
> > > >>esi; c047c8e0 <eeprom_driver+0/e0>
> > >
> > > Trace; c0104d7f <show_stack+7f/a0>
> > > Trace; c0104f1a <show_registers+15a/1c0>
> > > Trace; c0105184 <die+164/2e0>
> > > Trace; c0119936 <do_page_fault+356/68d>
> > > Trace; c0104853 <error_code+4f/54>
> > > Trace; c02f1aa1 <eeprom_attach_adapter+21/30>
> > > Trace; c02ee704 <i2c_add_driver+b4/e0>
> > > Trace; c050a652 <eeprom_init+12/40>
> > > Trace; c04ee8ab <do_initcalls+2b/c0>
> > > Trace; c0100302 <init+32/130>
> > > Trace; c0101351 <kernel_thread_helper+5/14>
> >
> > Ah. adapter->algo is NULL in i2c_detect().
>
> Forgive a possibly stupid question, but how did you manage to come to
> this conclusion from the stack above alone? Is there any magic I am not
> aware of?
Well it oopsed at one of the first statements in i2c_detect(), and the
faulting address was 0x00000020. And the offset of i2c_algorithm.id is 32.
So adapter->algo is NULL in i2c_is_isa_adapter().
> My first impression was that the adapter itself was missing, like it had
> been deleted without being removed from the main i2c adapters list.
>
> Anyway, this test at leasted proved one thing: the i2c-dev driver isn't
> involved in the oops per se. Using a different i2c chip driver (eeprom
> here) triggers it as well. This tends to confirm that the problem is
> related to a specific i2c adapter driver.
I'd say so.
> > I don't think i2c_adapters are allowed to do that.
>
> Correct, they are not.
>
> > It could have been any old adapter, registered at some earlier time.
>
> Except that we have a strong suspicion that it is nvidiafb, instead of
> just any old adapter.
Could be.
> > If I'm right, this debug patch should point us at the culprit.
>
> I doubt it will help (but let's still try). The nvidiafb i2c adapters
> are added by i2c-algo-bit:i2c_bit_add_bus(), which does set
> adapter->algo to &i2c_bit_algo right before it calls i2c_add_adapter. I
> don't think that algo is NULL when the adapter is added. Rather, it
> becomes NULL later, most possibly because adapter itself point to a now
> gone structure. Just my theory though.
urgh. That explains why the patch didn't work.
Miles, there's a new debug patch below.
> Maybe it would help if Miles could give a try to Tony's patch here and
> report?
> http://archives.andrew.net.au/lm-sensors/msg30044.html
That too.
25-akpm/drivers/i2c/algos/i2c-algo-bit.c | 6 ++++--
25-akpm/drivers/i2c/i2c-core.c | 12 ++++++++++--
25-akpm/include/linux/i2c-algo-bit.h | 3 ++-
25-akpm/include/linux/i2c.h | 6 +++++-
4 files changed, 21 insertions(+), 6 deletions(-)
diff -puN include/linux/i2c.h~i2c-debugging include/linux/i2c.h
--- 25/include/linux/i2c.h~i2c-debugging 2005-03-22 02:02:53.000000000 -0800
+++ 25-akpm/include/linux/i2c.h 2005-03-22 02:06:50.000000000 -0800
@@ -244,6 +244,8 @@ struct i2c_adapter {
char name[I2C_NAME_SIZE];
struct completion dev_released;
struct completion class_dev_released;
+ char *file;
+ int line;
};
#define dev_to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
#define class_dev_to_i2c_adapter(d) container_of(d, struct i2c_adapter, class_dev)
@@ -314,7 +316,9 @@ struct i2c_client_address_data {
/* administration...
*/
-extern int i2c_add_adapter(struct i2c_adapter *);
+#define i2c_add_adapter(a) __i2c_add_adapter(__FILE__, __LINE__, a)
+
+extern int __i2c_add_adapter(char *file, int line, struct i2c_adapter *);
extern int i2c_del_adapter(struct i2c_adapter *);
extern int i2c_add_driver(struct i2c_driver *);
diff -puN drivers/i2c/i2c-core.c~i2c-debugging drivers/i2c/i2c-core.c
--- 25/drivers/i2c/i2c-core.c~i2c-debugging 2005-03-22 02:02:53.000000000 -0800
+++ 25-akpm/drivers/i2c/i2c-core.c 2005-03-22 02:02:53.000000000 -0800
@@ -144,12 +144,15 @@ static struct device_attribute dev_attr_
* when a new hw adapter registers. A new device is register to be
* available for clients.
*/
-int i2c_add_adapter(struct i2c_adapter *adap)
+int __i2c_add_adapter(char *file, int line, struct i2c_adapter *adap)
{
int id, res = 0;
struct list_head *item;
struct i2c_driver *driver;
+ adap->file = file;
+ adap->line = line;
+
down(&core_lists);
if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) = 0) {
@@ -310,6 +313,11 @@ int i2c_add_driver(struct i2c_driver *dr
if (driver->flags & I2C_DF_NOTIFY) {
list_for_each(item,&adapters) {
adapter = list_entry(item, struct i2c_adapter, list);
+ printk("%s:%d: %p\n", adapter->file, adapter->line,
+ adapter->algo);
+ if (adapter->algo = NULL)
+ for ( ; ; )
+ ;
driver->attach_adapter(adapter);
}
}
@@ -1246,7 +1254,7 @@ int i2c_check_functionality (struct i2c_
return (func & adap_func) = func;
}
-EXPORT_SYMBOL(i2c_add_adapter);
+EXPORT_SYMBOL(__i2c_add_adapter);
EXPORT_SYMBOL(i2c_del_adapter);
EXPORT_SYMBOL(i2c_add_driver);
EXPORT_SYMBOL(i2c_del_driver);
diff -puN drivers/i2c/algos/i2c-algo-bit.c~i2c-debugging drivers/i2c/algos/i2c-algo-bit.c
--- 25/drivers/i2c/algos/i2c-algo-bit.c~i2c-debugging 2005-03-22 02:03:15.000000000 -0800
+++ 25-akpm/drivers/i2c/algos/i2c-algo-bit.c 2005-03-22 02:04:31.000000000 -0800
@@ -528,10 +528,12 @@ static struct i2c_algorithm i2c_bit_algo
/*
* registering functions to load algorithms at runtime
*/
-int i2c_bit_add_bus(struct i2c_adapter *adap)
+int __i2c_bit_add_bus(char *file, int line, struct i2c_adapter *adap)
{
struct i2c_algo_bit_data *bit_adap = adap->algo_data;
+ adap->file = file;
+ adap->line = line;
if (bit_test) {
int ret = test_bus(bit_adap, adap->name);
if (ret<0)
@@ -558,7 +560,7 @@ int i2c_bit_del_bus(struct i2c_adapter *
return i2c_del_adapter(adap);
}
-EXPORT_SYMBOL(i2c_bit_add_bus);
+EXPORT_SYMBOL(__i2c_bit_add_bus);
EXPORT_SYMBOL(i2c_bit_del_bus);
MODULE_AUTHOR("Simon G. Vogl <simon@tk.uni-linz.ac.at>");
diff -puN include/linux/i2c-algo-bit.h~i2c-debugging include/linux/i2c-algo-bit.h
--- 25/include/linux/i2c-algo-bit.h~i2c-debugging 2005-03-22 02:03:33.000000000 -0800
+++ 25-akpm/include/linux/i2c-algo-bit.h 2005-03-22 02:05:08.000000000 -0800
@@ -48,7 +48,8 @@ struct i2c_algo_bit_data {
#define I2C_BIT_ADAP_MAX 16
-int i2c_bit_add_bus(struct i2c_adapter *);
+#define i2c_bit_add_bus(a) __i2c_bit_add_bus(__FILE__, __LINE__, a)
+int __i2c_bit_add_bus(char *file, int line, struct i2c_adapter *);
int i2c_bit_del_bus(struct i2c_adapter *);
#endif /* _LINUX_I2C_ALGO_BIT_H */
_
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (25 preceding siblings ...)
2005-05-19 6:25 ` Andrew Morton
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Andrew Morton
` (14 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
I tried building nvidiafb into the kernel and using nvidiafb in the
"append" arguments. I set "CONFIG_I2C_CHARDEV=m" to get around the
immediate crash. When I booted, the nvidiafb driver worked, but the
crash still occurred when the DS1621 sensor driver came into
operation. The Code: listing is identical to the previous scenario.
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=y
CONFIG_I2C_ISA=y
CONFIG_I2C_NFORCE2=y
CONFIG_SENSORS_DS1621=y
drivers/is/i2c-algo-pca.c:382: c0434240
drivers/i2c/algos/i2c-algo-bit.c:553: c04341a0
Unable to handle kernel paging request at virtual address f8e813d4
printing eip:
c020cccd
*pde = 37e4d067
*pte = 00000000
Oops: 0002 [#1]
PREEMPT DEBUG_PAGEALLOC
Modules linked in:
CPU: 0
EIP: 0060:[<c020cccd>} Not tainted VLI
EFLAGS: 00010206 (2.6.12-rc1)
EIP is at nvidia_gpio_setsda+0x1d/0x70
eax: f8e81000 ebx: f7c00244 ecx: f7c0053c edx: 0000003f
esi: 00000001 edi: 00000001 epb: f7c21db0 esp: f7c21da8
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, threadinfo÷c20000 taskÁ7fca20)
Stack: f7c0070c 00000001 f7c21dc4 c02be0a5 f7c0053c 00000000 f7c00544 f7c21e20
c02beb4a f7c0070c 00000000 f7c21e35 ffffffff c0373a20
30000000 f7c23438
f7c21e08 c0115d41 c17fca20 f7c21e08 c17fca20 00000086
00000000 f7c00544
Call trace:
[<c010400f>] show_stack+0x7f/0xa0
[<c01041aa>] show_registers+0x15a/0x1c0
[<c01043ac>] die+0xfc/0x190
[<c011438b>] do_page_fault+0x31b/0x670
[<c0103c43>] error_code+0x2b/0x30
[<c02be0a5>] i2c_start+0x25/0x60
[<c02beb4a>] bit_xfer+0x1a/0x690
[<c027bf88>] i2c_transfer+0x68/0xb0
[<c027cf79>] i2c_smbus_xfer_emulated+0xb9/0x3b0
[<c027d39f>] i2c_smbus_xfer+0x12f/0x220
[<c027d8fa>] i2c_detect+0x23a/0x500
[<c029c251>] ds1621_attach_adapter+0x21/0x30
[<c027b643>] i2c_add_driver+0xd3/0x100
[<c04cb0b2>] ds1621_init+0x12/0x40
[<c04b08ab>] do_initcalls+0x2b/0xc0
[<c0100302>] init+0x32/0x130
[<c0101301>] kernel_thread_helper+0x5/0x14
Code: 00 00 8b 74 24 04 8b 1c 24 c9 c3 8d 76 00 55 89 e5 83 ec 08 8b
4d 08 89 1c 24 89 74 24 04 8b 19 0f b6 51 04 8b 83 00 09 00 00 42 <88>
90 d4 03 00 00 8b b3 00 09 00 00 0f b6 86 d5 03 00 00 0f b6
<0>Kernel panic - not syncing: Attempted to kill init!
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (26 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Andrew Morton
2005-05-19 6:25 ` Miles Lane
` (13 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Andrew Morton @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Jean Delvare <khali@linux-fr.org> wrote:
>
> Hi Tony,
>
> > I've only seen the savage bug report. Yes, unfortunately, this is the
> > case of 2 drivers attempting to control a single device since the
> > savagefb and the i2c prosavage drivers will attempt to ioremap the
> > same mmio region. If you need the i2c prosavage bus, then savagefb
> > must be completely disabled, as setting CONFIG_FB_SAVAGE_I2C to n will
> > not help. If both savagefb and i2c are needed, then you just have to
> > use the i2c bus registered by savagefb.
>
> I understand the problem you describe, and it should certainly be
> addressed by Kconfig dependencies. However, I don't think this is the
> problem here. If you look at the configuration file, you'll see that
> neither i2c-prosavage nor i2c-savage4 are enabled:
>
> # CONFIG_I2C_PROSAVAGE is not set
> # CONFIG_I2C_SAVAGE4 is not set
>
> > And yes, there is code duplication, but unfortunately savagefb cannot
> > use the i2c-prosavage bus since one of them will fail to acquire the
> > io regions.
>
> I wonder if the standalone i2c drivers are needed at all anymore, now
> that the framebuffer driver includes the same functionality.
>
> > I haven't seen the nvidiafb report, but it is probably something
> > similar.
>
> Note that there is no i2c bus driver for nvidia graphics adapters in the
> kernel tree. The conflicting driver is rivatv and it lives outside the
> kernel tree.
>
> Miles, are you by any chance using rivatv?
>
> Tony, Miles' original report is here:
> http://marc.theaimsgroup.com/?l=linux-kernel&m\x111076667232062&w=2
> Sorry for providing the link before.
(I'm getting in a mess here. bugzilla is good for some things after all)
Do we consider this to all be fixed up now?
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (27 preceding siblings ...)
2005-05-19 6:25 ` Andrew Morton
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Andrew Morton
` (12 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
> I think we would spare a significant amount of time
> if Miles could test Tony's patch to nvidiafb - unless
> he already tried and I am not aware?
Hi,
I will test the nvidia patch as soon as I get home (it'll be a few hours).
Miles
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (28 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Andrew Morton
2005-05-19 6:25 ` Miles Lane
` (11 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Andrew Morton @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Jean Delvare <khali@linux-fr.org> wrote:
>
> I think we would spare a significant amount of time if Miles could test
> Tony's patch to nvidiafb - unless he already tried and I am not aware?
> Miles?
Perhaps you could resend it?
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (29 preceding siblings ...)
2005-05-19 6:25 ` Andrew Morton
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Miles Lane
` (10 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
I tried compiling the nvidiafb driver as a module. I was able to boot
the machine successfully and then both add and remove the driver.
However, when I modprobe the driver, I get the following error:
ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
ACPI: PCI interrupt 0000:03:00.0[A] -> GSI 19 (level, high) -> IRQ 19
PCI: Unable to reserve mem region #2:10000000@d0000000 for device 0000:03:00.0
nvidiafb: cannot request PCI regions
Here is the output of lspci -vv (I hope this is helpful information):
0000:00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different
version?) (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at e0000000 (32-bit, prefetchable) [size\x128M]
Capabilities: [40] AGP version 3.0
Status: RQ2 Iso- ArqSz=2 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x4
Capabilities: [60] #08 [2001]
0000:00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [48] #08 [01e1]
0000:00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at e000 [size2]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller
(rev a4) (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 21
Region 0: Memory at ee087000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller
(rev a4) (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 20
Region 0: Memory at ee082000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller
(rev a4) (prog-if 20 [EHCI])
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin C routed to IRQ 22
Region 0: Memory at ee083000 (32-bit, non-prefetchable) [size%6]
Capabilities: [44] #0a [2080]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
Controller (rev a1)
Subsystem: Asustek Computer, Inc. A7N8X Mainboard onboard
nForce2 Ethernet
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 21
Region 0: Memory at ee086000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at e400 [size=8]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:05.0 Multimedia audio controller: nVidia Corporation nForce
MultiMedia audio [Via VT82C686B] (rev a2)
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 3000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ee000000 (32-bit, non-prefetchable) [sizeQ2K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:06.0 Multimedia audio controller: nVidia Corporation nForce2
AC97 Audio Controler (MCP) (rev a1)
Subsystem: Asustek Computer, Inc.: Unknown device 8095
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin A routed to IRQ 22
Region 0: I/O ports at d000 [size%6]
Region 1: I/O ports at d400 [size\x128]
Region 2: Memory at ee080000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI
Bridge (rev a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary\0, secondary\x01, subordinate\x01, sec-latency2
I/O behind bridge: 0000a000-0000bfff
Memory behind bridge: ec000000-edffffff
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
0000:00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
(prog-if 8a [Master SecP PriP])
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 4: I/O ports at f000 [size\x16]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:0c.0 PCI bridge: nVidia Corporation nForce2 PCI Bridge (rev
a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary\0, secondary\x02, subordinate\x02, sec-latency2
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: e8000000-e9ffffff
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
0000:00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire
(IEEE 1394) Controller (rev a3) (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc.: Unknown device 809a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 22
Region 0: Memory at ee084000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at ee085000 (32-bit, non-prefetchable) [sized]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
0000:00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 16
Bus: primary\0, secondary\x03, subordinate\x03, sec-latency2
Memory behind bridge: ea000000-ebffffff
Prefetchable memory behind bridge: d0000000-dfffffff
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
0000:01:06.0 Network controller: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller (rev 03)
Subsystem: Motorola: Unknown device 7110
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16
Interrupt: pin A routed to IRQ 16
Region 0: Memory at ed000000 (32-bit, non-prefetchable) [size=8K]
0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD
Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller
(rev 02)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) Asus A7N8X
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 16, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at a000 [size=8]
Region 1: I/O ports at a400 [size=4]
Region 2: I/O ports at a800 [size=8]
Region 3: I/O ports at ac00 [size=4]
Region 4: I/O ports at b000 [size\x16]
Region 5: Memory at ed002000 (32-bit, non-prefetchable) [sizeQ2]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
0000:02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB
Integrated Fast Ethernet Controller [Tornado] (rev 40)
Subsystem: Asustek Computer, Inc. A7N8X Deluxe onboard
3C920B-EMB Integrated Fast Ethernet Controller
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at c000 [disabled] [size\x128]
Region 1: [virtual] Memory at e9000000 (32-bit,
non-prefetchable) [disabled] [size\x128]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D3 PME-Enable- DSel=0 DScale=2 PME-
0000:03:00.0 VGA compatible controller: nVidia Corporation NV31
[GeForce FX 5600] (rev a1) (prog-if 00 [VGA])
Subsystem: Micro-Star International Co., Ltd.: Unknown device 9123
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 19
Region 0: Memory at ea000000 (32-bit, non-prefetchable) [size\x16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size%6M]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different
version?) (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at e0000000 (32-bit, prefetchable) [size\x128M]
Capabilities: [40] AGP version 3.0
Status: RQ2 Iso- ArqSz=2 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x4
Capabilities: [60] #08 [2001]
0000:00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [48] #08 [01e1]
0000:00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at e000 [size2]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller
(rev a4) (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 21
Region 0: Memory at ee087000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller
(rev a4) (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 20
Region 0: Memory at ee082000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller
(rev a4) (prog-if 20 [EHCI])
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin C routed to IRQ 22
Region 0: Memory at ee083000 (32-bit, non-prefetchable) [size%6]
Capabilities: [44] #0a [2080]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
Controller (rev a1)
Subsystem: Asustek Computer, Inc. A7N8X Mainboard onboard
nForce2 Ethernet
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 21
Region 0: Memory at ee086000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at e400 [size=8]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:05.0 Multimedia audio controller: nVidia Corporation nForce
MultiMedia audio [Via VT82C686B] (rev a2)
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 3000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ee000000 (32-bit, non-prefetchable) [sizeQ2K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:06.0 Multimedia audio controller: nVidia Corporation nForce2
AC97 Audio Controler (MCP) (rev a1)
Subsystem: Asustek Computer, Inc.: Unknown device 8095
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin A routed to IRQ 22
Region 0: I/O ports at d000 [size%6]
Region 1: I/O ports at d400 [size\x128]
Region 2: Memory at ee080000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI
Bridge (rev a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary\0, secondary\x01, subordinate\x01, sec-latency2
I/O behind bridge: 0000a000-0000bfff
Memory behind bridge: ec000000-edffffff
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
0000:00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
(prog-if 8a [Master SecP PriP])
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 4: I/O ports at f000 [size\x16]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:0c.0 PCI bridge: nVidia Corporation nForce2 PCI Bridge (rev
a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary\0, secondary\x02, subordinate\x02, sec-latency2
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: e8000000-e9ffffff
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
0000:00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire
(IEEE 1394) Controller (rev a3) (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc.: Unknown device 809a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 22
Region 0: Memory at ee084000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at ee085000 (32-bit, non-prefetchable) [sized]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
0000:00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 16
Bus: primary\0, secondary\x03, subordinate\x03, sec-latency2
Memory behind bridge: ea000000-ebffffff
Prefetchable memory behind bridge: d0000000-dfffffff
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
0000:01:06.0 Network controller: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller (rev 03)
Subsystem: Motorola: Unknown device 7110
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16
Interrupt: pin A routed to IRQ 16
Region 0: Memory at ed000000 (32-bit, non-prefetchable) [size=8K]
0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD
Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller
(rev 02)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) Asus A7N8X
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 16, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at a000 [size=8]
Region 1: I/O ports at a400 [size=4]
Region 2: I/O ports at a800 [size=8]
Region 3: I/O ports at ac00 [size=4]
Region 4: I/O ports at b000 [size\x16]
Region 5: Memory at ed002000 (32-bit, non-prefetchable) [sizeQ2]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
0000:02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB
Integrated Fast Ethernet Controller [Tornado] (rev 40)
Subsystem: Asustek Computer, Inc. A7N8X Deluxe onboard
3C920B-EMB Integrated Fast Ethernet Controller
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at c000 [disabled] [size\x128]
Region 1: [virtual] Memory at e9000000 (32-bit,
non-prefetchable) [disabled] [size\x128]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D3 PME-Enable- DSel=0 DScale=2 PME-
0000:03:00.0 VGA compatible controller: nVidia Corporation NV31
[GeForce FX 5600] (rev a1) (prog-if 00 [VGA])
Subsystem: Micro-Star International Co., Ltd.: Unknown device 9123
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 19
Region 0: Memory at ea000000 (32-bit, non-prefetchable) [size\x16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size%6M]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different
version?) (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at e0000000 (32-bit, prefetchable) [size\x128M]
Capabilities: [40] AGP version 3.0
Status: RQ2 Iso- ArqSz=2 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=x4
Capabilities: [60] #08 [2001]
0000:00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1)
Subsystem: Asustek Computer, Inc.: Unknown device 80ac
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
0000:00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a4)
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [48] #08 [01e1]
0000:00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at e000 [size2]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller
(rev a4) (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 21
Region 0: Memory at ee087000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller
(rev a4) (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 20
Region 0: Memory at ee082000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller
(rev a4) (prog-if 20 [EHCI])
Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin C routed to IRQ 22
Region 0: Memory at ee083000 (32-bit, non-prefetchable) [size%6]
Capabilities: [44] #0a [2080]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
Controller (rev a1)
Subsystem: Asustek Computer, Inc. A7N8X Mainboard onboard
nForce2 Ethernet
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 21
Region 0: Memory at ee086000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at e400 [size=8]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:05.0 Multimedia audio controller: nVidia Corporation nForce
MultiMedia audio [Via VT82C686B] (rev a2)
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 3000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ee000000 (32-bit, non-prefetchable) [sizeQ2K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:06.0 Multimedia audio controller: nVidia Corporation nForce2
AC97 Audio Controler (MCP) (rev a1)
Subsystem: Asustek Computer, Inc.: Unknown device 8095
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin A routed to IRQ 22
Region 0: I/O ports at d000 [size%6]
Region 1: I/O ports at d400 [size\x128]
Region 2: Memory at ee080000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI
Bridge (rev a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary\0, secondary\x01, subordinate\x01, sec-latency2
I/O behind bridge: 0000a000-0000bfff
Memory behind bridge: ec000000-edffffff
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
0000:00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
(prog-if 8a [Master SecP PriP])
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 4: I/O ports at f000 [size\x16]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:0c.0 PCI bridge: nVidia Corporation nForce2 PCI Bridge (rev
a3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary\0, secondary\x02, subordinate\x02, sec-latency2
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: e8000000-e9ffffff
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
0000:00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire
(IEEE 1394) Controller (rev a3) (prog-if 10 [OHCI])
Subsystem: Asustek Computer, Inc.: Unknown device 809a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 22
Region 0: Memory at ee084000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at ee085000 (32-bit, non-prefetchable) [sized]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
0000:00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1)
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 16
Bus: primary\0, secondary\x03, subordinate\x03, sec-latency2
Memory behind bridge: ea000000-ebffffff
Prefetchable memory behind bridge: d0000000-dfffffff
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
0000:01:06.0 Network controller: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller (rev 03)
Subsystem: Motorola: Unknown device 7110
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 16
Interrupt: pin A routed to IRQ 16
Region 0: Memory at ed000000 (32-bit, non-prefetchable) [size=8K]
0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD
Technology Inc) SiI 3112 [SATALink/SATARaid] Serial ATA Controller
(rev 02)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) Asus A7N8X
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 16, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at a000 [size=8]
Region 1: I/O ports at a400 [size=4]
Region 2: I/O ports at a800 [size=8]
Region 3: I/O ports at ac00 [size=4]
Region 4: I/O ports at b000 [size\x16]
Region 5: Memory at ed002000 (32-bit, non-prefetchable) [sizeQ2]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
0000:02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB
Integrated Fast Ethernet Controller [Tornado] (rev 40)
Subsystem: Asustek Computer, Inc. A7N8X Deluxe onboard
3C920B-EMB Integrated Fast Ethernet Controller
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 20
Region 0: I/O ports at c000 [disabled] [size\x128]
Region 1: [virtual] Memory at e9000000 (32-bit,
non-prefetchable) [disabled] [size\x128]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D3 PME-Enable- DSel=0 DScale=2 PME-
0000:03:00.0 VGA compatible controller: nVidia Corporation NV31
[GeForce FX 5600] (rev a1) (prog-if 00 [VGA])
Subsystem: Micro-Star International Co., Ltd.: Unknown device 9123
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 19
Region 0: Memory at ea000000 (32-bit, non-prefetchable) [size\x16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size%6M]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 3.0
Status: RQ2 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64-
HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit-
FW- Rate=<none>
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (30 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Miles Lane
` (9 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
I will rebuild the kernel with the necessary options, reproduce the
OOPS and then decode the code using gdb, as you have requested.
BTW, I seem to have been requested to add printks and whatnot into the
kernel code. Since I am just a tester, would someone else do this for
me, if that particular information is needed?
Thanks,
Miles
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (31 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Jean Delvare
` (8 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi,
I won't include the gdb code listing, since I checked and it hasn't
changed as a result of the patches.
Here is what I get with Jean and Andrew's patches combined:
Unable to handle kernel paging request at virtual address f8e813d4
c020c98d
*pde = 00000000
Oops: 0002 [#1]
CPU: 0
EIP: 0060:[<c020c98d>} Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202 (2.6.12-rc1)
eax: f8e81000 ebx: f7c00240 ecx: f7c00538 edx: 0000003f
esi: 00000001 edi: 00000001 epb: f7c21db0 esp: f7c21da8
Warning (Oops_set_regs): garbage 'epb: f7c21db0 esp: f7c21da8' at end
of register line ignored
ds: 007b es: 007b ss: 0068
Stack: f7c00708 00000001 f7c21dc4 c027f2e5 f7c00538 00000000 f7c00540 f7c21e20
c027fd8a f7c00708 00000000 f7c21e35 ffffffff c03342e0 30000000 f7c23530
f7c21e08 c0115d41 c17fca20 f7c21e08 c17fca20 00000286 00000000 f7c00540
Call trace:
[<c010400f>] show_stack+0x7f/0xa0
[<c01041aa>] show_registers+0x15a/0x1c0
[<c01043ac>] die+0xfc/0x190
[<c011438b>] do_page_fault+0x31b/0x670
[<c0103c43>] error_code+0x2b/0x30
[<c027f2e5>] i2c_start+0x25/0x60
[<c027fd8a>] bit_xfer+0x1a/0x690
[<c027bc48>] i2c_transfer+0x68/0xb0
[<c027cc39>] i2c_smbus_xfer_emulated+0xb9/0x3b0
[<c027d05f>] i2c_smbus_xfer+0x12f/0x220
[<c027e17a>] i2c_detect+0x23a/0x500
[<c027f051>] eeprom_attach_adapter+0x21/0x30
[<c027b303>] i2c_add_driver+0xd3/0x100
[<c0466452>] eeprom_init+0x12/0x40
[<c044c8ab>] do_initcalls+0x2b/0xc0
[<c0100302>] init+0x32/0x130
[<c0101301>] kernel_thread_helper+0x5/0x14
Code: 00 00 8b 74 24 04 8b 1c 24 c9 c3 8d 76 00 55 89 e5 83 ec 08 8b
4d 08 89 1c 24 89 74 24 04 8b 19 0f b6 51 04 8b 83 00 09 00 00 42 <88>
90 d4 03 00 00 8b b3 00 09 00 00 0f b6 86 d5 03 00 00 0f b6
>>EIP; c020c98d <nvidia_gpio_setsda+1d/70> <==
>>eax; f8e81000 <pg0+389c7000/3fb44400>
>>ebx; f7c00240 <pg0+37746240/3fb44400>
>>ecx; f7c00538 <pg0+37746538/3fb44400>
Trace; c010400f <show_stack+7f/a0>
Trace; c01041aa <show_registers+15a/1c0>
Trace; c01043ac <die+fc/190>
Trace; c011438b <do_page_fault+31b/670>
Trace; c0103c43 <error_code+2b/30>
Trace; c027f2e5 <i2c_start+25/60>
Trace; c027fd8a <bit_xfer+1a/690>
Trace; c027bc48 <i2c_transfer+68/b0>
Trace; c027cc39 <i2c_smbus_xfer_emulated+b9/3b0>
Trace; c027d05f <i2c_smbus_xfer+12f/220>
Trace; c027e17a <i2c_detect+23a/500>
Trace; c027f051 <eeprom_attach_adapter+21/30>
Trace; c027b303 <i2c_add_driver+d3/100>
Trace; c0466452 <eeprom_init+12/40>
Trace; c044c8ab <do_initcalls+2b/c0>
Trace; c0100302 <init+32/130>
Trace; c0101301 <kernel_thread_helper+5/14>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; c020c962 <nvidia_gpio_setscl+62/70>
00000000 <_EIP>:
Code; c020c962 <nvidia_gpio_setscl+62/70>
0: 00 00 add %al,(%eax)
Code; c020c964 <nvidia_gpio_setscl+64/70>
2: 8b 74 24 04 mov 0x4(%esp),%esi
Code; c020c968 <nvidia_gpio_setscl+68/70>
6: 8b 1c 24 mov (%esp),%ebx
Code; c020c96b <nvidia_gpio_setscl+6b/70>
9: c9 leave
Code; c020c96c <nvidia_gpio_setscl+6c/70>
a: c3 ret
Code; c020c96d <nvidia_gpio_setscl+6d/70>
b: 8d 76 00 lea 0x0(%esi),%esi
Code; c020c970 <nvidia_gpio_setsda+0/70>
e: 55 push %ebp
Code; c020c971 <nvidia_gpio_setsda+1/70>
f: 89 e5 mov %esp,%ebp
Code; c020c973 <nvidia_gpio_setsda+3/70>
11: 83 ec 08 sub $0x8,%esp
Code; c020c976 <nvidia_gpio_setsda+6/70>
14: 8b 4d 08 mov 0x8(%ebp),%ecx
Code; c020c979 <nvidia_gpio_setsda+9/70>
17: 89 1c 24 mov %ebx,(%esp)
Code; c020c97c <nvidia_gpio_setsda+c/70>
1a: 89 74 24 04 mov %esi,0x4(%esp)
Code; c020c980 <nvidia_gpio_setsda+10/70>
1e: 8b 19 mov (%ecx),%ebx
Code; c020c982 <nvidia_gpio_setsda+12/70>
20: 0f b6 51 04 movzbl 0x4(%ecx),%edx
Code; c020c986 <nvidia_gpio_setsda+16/70>
24: 8b 83 00 09 00 00 mov 0x900(%ebx),%eax
Code; c020c98c <nvidia_gpio_setsda+1c/70>
2a: 42 inc %edx
This decode from eip onwards should be reliable
Code; c020c98d <nvidia_gpio_setsda+1d/70>
00000000 <_EIP>:
Code; c020c98d <nvidia_gpio_setsda+1d/70> <== 0: 88 90 d4 03 00 00 mov %dl,0x3d4(%eax) <==Code; c020c993 <nvidia_gpio_setsda+23/70>
6: 8b b3 00 09 00 00 mov 0x900(%ebx),%esi
Code; c020c999 <nvidia_gpio_setsda+29/70>
c: 0f b6 86 d5 03 00 00 movzbl 0x3d5(%esi),%eax
Code; c020c9a0 <nvidia_gpio_setsda+30/70>
13: 0f .byte 0xf
Code; c020c9a1 <nvidia_gpio_setsda+31/70>
14: b6 .byte 0xb6
<0>Kernel panic - not syncing: Attempted to kill init!
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (32 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Miles Lane
` (7 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Greg, Andrew, all,
> > Do we consider this to all be fixed up now?
>
> I thought so. Jean?
No, not all is fixed. There were originally two different bug reports. In
the first place I thought they were related, but in turns out that I was
wrong.
So, the eeprom oops that was reported on bugzilla (#4347) by Salah
Coronya is now fixed, with the critical part of the fix already in
2.6.12-rc1 and candidate for 2.6.11.6, the other part being on its way
to Greg's bk-i2c tree. But the other oops, reported by Miles Lane on
LKML and then discussed on the sensors list, is not fixed yet, although
we are probably not so far from a fix now.
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (33 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Miles Lane
` (6 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Sorry for pasting the decoded output twice in the last message.
Here is what gdb shows for nvidia_gpio_setsda.
c020c94d(gdb) x/30i 0xc020c94d
0xc020c94d <nvidia_gpio_setsda+29>: mov %dl,0x3d4(%eax)
0xc020c953 <nvidia_gpio_setsda+35>: mov 0x900(%ebx),%esi
0xc020c959 <nvidia_gpio_setsda+41>: movzbl 0x3d5(%esi),%eax
0xc020c960 <nvidia_gpio_setsda+48>: movzbl %al,%eax
0xc020c963 <nvidia_gpio_setsda+51>: mov %eax,%edx
0xc020c965 <nvidia_gpio_setsda+53>: and $0xe0,%eax
0xc020c96a <nvidia_gpio_setsda+58>: and $0xf0,%edx
0xc020c970 <nvidia_gpio_setsda+64>: or $0x10,%edx
0xc020c973 <nvidia_gpio_setsda+67>: cmpl $0x0,0xc(%ebp)
0xc020c977 <nvidia_gpio_setsda+71>: cmove %eax,%edx
0xc020c97a <nvidia_gpio_setsda+74>: movzbl 0x4(%ecx),%eax
0xc020c97e <nvidia_gpio_setsda+78>: or $0x1,%edx
0xc020c981 <nvidia_gpio_setsda+81>: inc %eax
0xc020c982 <nvidia_gpio_setsda+82>: mov %al,0x3d4(%esi)
0xc020c988 <nvidia_gpio_setsda+88>: mov 0x900(%ebx),%eax
0xc020c98e <nvidia_gpio_setsda+94>: mov %dl,0x3d5(%eax)
0xc020c994 <nvidia_gpio_setsda+100>: mov 0x4(%esp),%esi
0xc020c998 <nvidia_gpio_setsda+104>: mov (%esp),%ebx
0xc020c99b <nvidia_gpio_setsda+107>: leave
0xc020c99c <nvidia_gpio_setsda+108>: ret
0xc020c99d <nvidia_gpio_setsda+109>: lea 0x0(%esi),%esi
0xc020c9a0 <nvidia_gpio_getscl>: push %ebp
0xc020c9a1 <nvidia_gpio_getscl+1>: mov %esp,%ebp
0xc020c9a3 <nvidia_gpio_getscl+3>: mov 0x8(%ebp),%eax
0xc020c9a6 <nvidia_gpio_getscl+6>: mov (%eax),%ecx
0xc020c9a8 <nvidia_gpio_getscl+8>: movzbl 0x4(%eax),%edx
0xc020c9ac <nvidia_gpio_getscl+12>: mov 0x900(%ecx),%eax
0xc020c9b2 <nvidia_gpio_getscl+18>: mov %dl,0x3d4(%eax)
0xc020c9b8 <nvidia_gpio_getscl+24>: mov 0x900(%ecx),%eax
0xc020c9be <nvidia_gpio_getscl+30>: movzbl 0x3d5(%eax),%edx
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (34 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Miles Lane
2005-05-19 6:25 ` Jean Delvare
` (5 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
I tested it and still get the Oops.
I backed out Andrew's patch. Now I'll add it back in and send the output.
Miles
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (35 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-19 6:25 ` Jean Delvare
2005-05-19 6:25 ` Miles Lane
` (4 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Jean Delvare @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Hi Andrew,
> aargh. That's a totally different crash :(
Isn't is exactly what would happen in the case I described, i.e.
adapters freed but still in the list? The freed area could be
overwritten randomly, causing crashes at different locations each time
we slightly change the code?
> Were you using this patch?
I think we would spare a significant amount of time if Miles could test
Tony's patch to nvidiafb - unless he already tried and I am not aware?
Miles?
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 46+ messages in thread* Who should I write to about this OOPS in 2,6,11-mm3?
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (36 preceding siblings ...)
2005-05-19 6:25 ` Jean Delvare
@ 2005-05-19 6:25 ` Miles Lane
2005-05-26 9:05 ` [lm-sensors] Re: Who should I write to about this OOPS in 2, 6, Andrew Morton
` (3 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-19 6:25 UTC (permalink / raw)
To: lm-sensors
Sorry, I was wrong. I had forgotten to enable to NVidia framebuffer
driver. I am copying down the Oops message now.
Miles
^ permalink raw reply [flat|nested] 46+ messages in thread* [lm-sensors] Re: Who should I write to about this OOPS in 2, 6,
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (37 preceding siblings ...)
2005-05-19 6:25 ` Miles Lane
@ 2005-05-26 9:05 ` Andrew Morton
2005-05-26 9:05 ` Greg KH
` (2 subsequent siblings)
41 siblings, 0 replies; 46+ messages in thread
From: Andrew Morton @ 2005-05-26 9:05 UTC (permalink / raw)
To: lm-sensors
Miles Lane <miles.lane@gmail.com> wrote:
>
> I tried building nvidiafb into the kernel and using nvidiafb in the
> "append" arguments. I set "CONFIG_I2C_CHARDEV=m" to get around the
> immediate crash. When I booted, the nvidiafb driver worked, but the
> crash still occurred when the DS1621 sensor driver came into
> operation. The Code: listing is identical to the previous scenario.
Holy cow, this was a huge email thread.
Are there still any outstanding bugs related to this which we need to fix
in 2.6.12-rc5?
If so, can we please have a fresh report?
Thanks.
> CONFIG_I2C=y
> CONFIG_I2C_CHARDEV=m
> CONFIG_I2C_ALGOBIT=y
> CONFIG_I2C_ALGOPCF=m
> CONFIG_I2C_ALGOPCA=y
> CONFIG_I2C_ISA=y
> CONFIG_I2C_NFORCE2=y
> CONFIG_SENSORS_DS1621=y
>
> drivers/is/i2c-algo-pca.c:382: c0434240
> drivers/i2c/algos/i2c-algo-bit.c:553: c04341a0
> Unable to handle kernel paging request at virtual address f8e813d4
> printing eip:
> c020cccd
> *pde = 37e4d067
> *pte = 00000000
> Oops: 0002 [#1]
> PREEMPT DEBUG_PAGEALLOC
> Modules linked in:
> CPU: 0
> EIP: 0060:[<c020cccd>} Not tainted VLI
> EFLAGS: 00010206 (2.6.12-rc1)
> EIP is at nvidia_gpio_setsda+0x1d/0x70
> eax: f8e81000 ebx: f7c00244 ecx: f7c0053c edx: 0000003f
> esi: 00000001 edi: 00000001 epb: f7c21db0 esp: f7c21da8
> ds: 007b es: 007b ss: 0068
> Process swapper (pid: 1, threadinfo÷c20000 taskÁ7fca20)
> Stack: f7c0070c 00000001 f7c21dc4 c02be0a5 f7c0053c 00000000 f7c00544 f7c21e20
> c02beb4a f7c0070c 00000000 f7c21e35 ffffffff c0373a20
> 30000000 f7c23438
> f7c21e08 c0115d41 c17fca20 f7c21e08 c17fca20 00000086
> 00000000 f7c00544
> Call trace:
> [<c010400f>] show_stack+0x7f/0xa0
> [<c01041aa>] show_registers+0x15a/0x1c0
> [<c01043ac>] die+0xfc/0x190
> [<c011438b>] do_page_fault+0x31b/0x670
> [<c0103c43>] error_code+0x2b/0x30
> [<c02be0a5>] i2c_start+0x25/0x60
> [<c02beb4a>] bit_xfer+0x1a/0x690
> [<c027bf88>] i2c_transfer+0x68/0xb0
> [<c027cf79>] i2c_smbus_xfer_emulated+0xb9/0x3b0
> [<c027d39f>] i2c_smbus_xfer+0x12f/0x220
> [<c027d8fa>] i2c_detect+0x23a/0x500
> [<c029c251>] ds1621_attach_adapter+0x21/0x30
> [<c027b643>] i2c_add_driver+0xd3/0x100
> [<c04cb0b2>] ds1621_init+0x12/0x40
> [<c04b08ab>] do_initcalls+0x2b/0xc0
> [<c0100302>] init+0x32/0x130
> [<c0101301>] kernel_thread_helper+0x5/0x14
> Code: 00 00 8b 74 24 04 8b 1c 24 c9 c3 8d 76 00 55 89 e5 83 ec 08 8b
> 4d 08 89 1c 24 89 74 24 04 8b 19 0f b6 51 04 8b 83 00 09 00 00 42 <88>
> 90 d4 03 00 00 8b b3 00 09 00 00 0f b6 86 d5 03 00 00 0f b6
> <0>Kernel panic - not syncing: Attempted to kill init!
^ permalink raw reply [flat|nested] 46+ messages in thread* [lm-sensors] Re: Who should I write to about this OOPS in 2, 6,
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (38 preceding siblings ...)
2005-05-26 9:05 ` [lm-sensors] Re: Who should I write to about this OOPS in 2, 6, Andrew Morton
@ 2005-05-26 9:05 ` Greg KH
2005-05-26 9:05 ` Andrew Morton
2005-05-26 9:05 ` Miles Lane
41 siblings, 0 replies; 46+ messages in thread
From: Greg KH @ 2005-05-26 9:05 UTC (permalink / raw)
To: lm-sensors
On Wed, May 25, 2005 at 03:59:40PM -0700, Andrew Morton wrote:
> Miles Lane <miles.lane@gmail.com> wrote:
> >
> > I tried building nvidiafb into the kernel and using nvidiafb in the
> > "append" arguments. I set "CONFIG_I2C_CHARDEV=m" to get around the
> > immediate crash. When I booted, the nvidiafb driver worked, but the
> > crash still occurred when the DS1621 sensor driver came into
> > operation. The Code: listing is identical to the previous scenario.
>
> Holy cow, this was a huge email thread.
>
> Are there still any outstanding bugs related to this which we need to fix
> in 2.6.12-rc5?
I think it was all handled. Miles?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 46+ messages in thread* [lm-sensors] Re: Who should I write to about this OOPS in 2, 6,
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (39 preceding siblings ...)
2005-05-26 9:05 ` Greg KH
@ 2005-05-26 9:05 ` Andrew Morton
2005-05-26 9:05 ` Miles Lane
41 siblings, 0 replies; 46+ messages in thread
From: Andrew Morton @ 2005-05-26 9:05 UTC (permalink / raw)
To: lm-sensors
Miles Lane <miles.lane@gmail.com> wrote:
>
> Yes, this is all fixed in the recent mm series trees.
> I haven't checked 2.6.12-rc5 and 2.6.12-rc5-mm1
> gave me a build error, which I have reported to
> Andrew. I will test within the next couple of days
> on 2.6.12-rc5, but I am pretty certain that all is
> working well now that nvidiafb defaults to using
> 64MB at boot time. Also, the problems with the i2c
> stuff getting mucked up when the nvidiafb driver
> was automatically unloaded, due to vesafb being
> used instead, is fixed.
>
Sweet, thanks.
^ permalink raw reply [flat|nested] 46+ messages in thread* [lm-sensors] Re: Who should I write to about this OOPS in 2, 6,
2005-05-19 6:25 Who should I write to about this OOPS in 2,6,11-mm3? Greg KH
` (40 preceding siblings ...)
2005-05-26 9:05 ` Andrew Morton
@ 2005-05-26 9:05 ` Miles Lane
41 siblings, 0 replies; 46+ messages in thread
From: Miles Lane @ 2005-05-26 9:05 UTC (permalink / raw)
To: lm-sensors
Yes, this is all fixed in the recent mm series trees.
I haven't checked 2.6.12-rc5 and 2.6.12-rc5-mm1
gave me a build error, which I have reported to
Andrew. I will test within the next couple of days
on 2.6.12-rc5, but I am pretty certain that all is
working well now that nvidiafb defaults to using
64MB at boot time. Also, the problems with the i2c
stuff getting mucked up when the nvidiafb driver
was automatically unloaded, due to vesafb being
used instead, is fixed.
Miles
^ permalink raw reply [flat|nested] 46+ messages in thread