Hello,
At first, sorry for the long e-mail.
I'm having a serious problem with a VA Linux system (i440BX chipset) and a
MMIO-based card (Cyclom-8YoP) and after some investigation, it seems to be
a kernel problem. I'd like to ask for your advising on this case.
Info about the system:
- System: VA Linux StartX MP workstation
- Dual Processor capable Tyan 1832 motherboard
- Intel 440BX chipset
- AMI BIOS: TYAN TIGER 100 V1.16A
- Single P-III 450MHz
- 128MB RAM
- Trident TG 9660 VGA card
- Intel EtherExpress Pro 10/100 Ethernet card
- VA Linux OS with stock kernel 2.2.14 (tried 2.3.99pre3 w/ same
results)
- Card: Cyclades Cyclom-8YoP
Problem: once the driver is loaded, the system locks up at driver
initialization. System locks up hard, not even Alt-SysRq works.
After some troubleshooting, I got some interesting information.
First, the customer's original configuration:
- /proc/pci:
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel 440BX - 82443BX Host (rev 3).
Medium devsel. Master Capable. Latency=32.
Prefetchable 32 bit memory at 0xf8000000 [0xf8000008].
Bus 0, device 1, function 0:
PCI bridge: Intel 440BX - 82443BX AGP (rev 3).
Medium devsel. Master Capable. Latency=32. Min Gnt=128.
Bus 0, device 7, function 0:
ISA bridge: Intel 82371AB PIIX4 ISA (rev 2).
Medium devsel. Fast back-to-back capable. Master Capable. No
bursts.
Bus 0, device 7, function 1:
IDE interface: Intel 82371AB PIIX4 IDE (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=64.
I/O at 0xffa0 [0xffa1].
Bus 0, device 7, function 2:
USB Controller: Intel 82371AB PIIX4 USB (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=32.
I/O at 0xef80 [0xef81].
Bus 0, device 7, function 3:
Bridge: Intel 82371AB PIIX4 ACPI (rev 2).
Medium devsel. Fast back-to-back capable.
Bus 0, device 18, function 0:
Ethernet controller: Intel 82557 (rev 8).
Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable.
Latency=32. Min Gnt=8.Max Lat=56.
Non-prefetchable 32 bit memory at 0xfe7df000 [0xfe7df000].
I/O at 0xef00 [0xef01].
Non-prefetchable 32 bit memory at 0xfe600000 [0xfe600000].
Bus 0, device 19, function 0:
Communication controller: Cyclades Cyclom-8Y above 1Mbyte (rev 1).
Medium devsel. Fast back-to-back capable. IRQ 11.
Non-prefetchable 32 bit memory at 0xfe7def80 [0xfe7def80].
I/O at 0xec00 [0xec01].
Non-prefetchable 32 bit memory at 0xfe7d8000 [0xfe7d8000].
Bus 0, device 20, function 0:
VGA compatible controller: Trident TG 9660 / Cyber9385 (rev 211).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=32.
Non-prefetchable 32 bit memory at 0xfe800000 [0xfe800000].
Non-prefetchable 32 bit memory at 0xfe7f0000 [0xfe7f0000].
Non-prefetchable 32 bit memory at 0xfe000000 [0xfe000000].
- /proc/bus/pci/devices:
0000 80867190 0 f8000008 00000000 00000000
00000000 00000000 00000000 00000000
0008 80867191 0 00000000 00000000 00000000
00000000 00000000 00000000 00000000
0038 80867110 0 00000000 00000000 00000000
00000000 00000000 00000000 00000000
0039 80867111 0 00000000 00000000 00000000
00000000 0000ffa1 00000000 00000000
003a 80867112 0 00000000 00000000 00000000
00000000 0000ef81 00000000 00000000
003b 80867113 0 00000000 00000000 00000000
00000000 00000000 00000000 00000000
0090 80861229 a fe7df000 0000ef01 fe600000
00000000 00000000 00000000 fe500000
0098 120e0105 b fe7def80 0000ec01 fe7d8000
00000000 00000000 00000000 00000000
00a0 10239660 0 fe800000 fe7f0000 fe000000
00000000 00000000 00000000 fe7e0000
In this case, the driver is able to ioremap the MMIO area, then detect the
CD1400 chips on board (which means it successfully accesses the MMIO area
during the detection). However, once it continues in its init function and
then later tries to read a register in the CD1400 chips (a register
which, BTW, had been successfully accessed before by the same driver), the
system locks up on the first read.
If you want to refer to the code, please refer to the Cyclades driver src
code (drivers/char/cyclades.c) and follow the function cy_init(): during
the cyy_init_card() in cy_detect_pci(), all accesses to the MMIO area work
fine; however, when later in cy_init() the driver tries to read the CD1400
version register (which BTW had been successfully accessed in
cyy_init_card()), the system locks up.
HOWEVER, if I put another card in the system that causes the
BIOS-assigned memory address to shift, then the board works fine:
- /proc/pci:
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel 440BX - 82443BX Host (rev 3).
Medium devsel. Master Capable. Latency=32.
Prefetchable 32 bit memory at 0xf8000000 [0xf8000008].
Bus 0, device 1, function 0:
PCI bridge: Intel 440BX - 82443BX AGP (rev 3).
Medium devsel. Master Capable. Latency=32. Min Gnt=128.
Bus 0, device 7, function 0:
ISA bridge: Intel 82371AB PIIX4 ISA (rev 2).
Medium devsel. Fast back-to-back capable. Master Capable. No
bursts.
Bus 0, device 7, function 1:
IDE interface: Intel 82371AB PIIX4 IDE (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=64.
I/O at 0xffa0 [0xffa1].
Bus 0, device 7, function 2:
USB Controller: Intel 82371AB PIIX4 USB (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=32.
I/O at 0xef80 [0xef81].
Bus 0, device 7, function 3:
Bridge: Intel 82371AB PIIX4 ACPI (rev 2).
Medium devsel. Fast back-to-back capable.
Bus 0, device 17, function 0:
Communication controller: Cyclades Cyclom-Y above 1Mbyte (rev 1).
Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable.
Latency=32.
Non-prefetchable 32 bit memory at 0xfe7dff80 [0xfe7dff80].
I/O at 0xec00 [0xec01].
Non-prefetchable 32 bit memory at 0xfe7d8000 [0xfe7d8000].
Bus 0, device 18, function 0:
Ethernet controller: Intel 82557 (rev 8).
Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable.
Latency=32. Min Gnt=8.Max Lat=56.
Non-prefetchable 32 bit memory at 0xfe7dd000 [0xfe7dd000].
I/O at 0xef00 [0xef01].
Non-prefetchable 32 bit memory at 0xfe600000 [0xfe600000].
Bus 0, device 19, function 0:
Communication controller: Cyclades Cyclom-8Y above 1Mbyte (rev 1).
Medium devsel. Fast back-to-back capable. IRQ 9.
Non-prefetchable 32 bit memory at 0xfe7dff00 [0xfe7dff00].
I/O at 0xe880 [0xe881].
Non-prefetchable 32 bit memory at 0xfe7d4000 [0xfe7d4000].
Bus 0, device 20, function 0:
VGA compatible controller: Trident TG 9660 / Cyber9385 (rev 211).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=32.
Non-prefetchable 32 bit memory at 0xfe800000 [0xfe800000].
Non-prefetchable 32 bit memory at 0xfe7f0000 [0xfe7f0000].
Non-prefetchable 32 bit memory at 0xfe000000 [0xfe000000].
- /proc/bus/pci/devices:
0000 80867190 0 f8000008 00000000 00000000
00000000 00000000 00000000 00000000
0008 80867191 0 00000000 00000000 00000000
00000000 00000000 00000000 00000000
0038 80867110 0 00000000 00000000 00000000
00000000 00000000 00000000 00000000
0039 80867111 0 00000000 00000000 00000000
00000000 0000ffa1 00000000 00000000
003a 80867112 0 00000000 00000000 00000000
00000000 0000ef81 00000000 00000000
003b 80867113 0 00000000 00000000 00000000
00000000 00000000 00000000 00000000
0088 120e0101 a fe7dff80 0000ec01 fe7d8000
00000000 00000000 00000000 fe7de000
0090 80861229 b fe7dd000 0000ef01 fe600000
00000000 00000000 00000000 fe500000
0098 120e0105 9 fe7dff00 0000e881 fe7d4000
00000000 00000000 00000000 00000000
00a0 10239660 0 fe800000 fe7f0000 fe000000
00000000 00000000 00000000 fe7e0000
In this case, both boards are initialized and work fine in the system.
More info:
1)The problem seems to happen only with PLX9050-based cards. The card
used to shift the memory address was PLX9060-based, and although it got
the same memory address that the other card had previously (when the
system locked up), it didn't lock up the system this time.
2)The problem does NOT happen with all motherboards, and the only
system in which we were able to replicate the problem here was this one.
3)I tried using "BIOS", "Direct" and "Any" i nthe PCI Access Mode in the
Linux kernel config., with no changes in the behavior.
4)If I boot Windows NT in the same system configuration that locks up
Linux, the system does NOT lock up and the Cyclom-Y card works fine.
(1) and (2) made me think that the problem was related to our hardware
(i.e., some incompatibility between this PCI chipset and our PLX9050-based
boards), but (4) shows that this HW combination works.
Could anybody give any suggestions on this problem, please?!?!?! Comments
/ suggestions / questions / requests for more info / anything would be
really appreciated.
Thanks in advance for your help.
Regards,
Ivan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:11 EST