Luis, thanks for your thoughts.
Luis.F.Correia wrote:
I didn't do that particular check but I know who was getting what interrupts and no-one was sharing.Hi!
Without any cable attached to the network cards, try to cat /proc/interrupts
and check if there is any interrupt sharing...
... In all fairness though I should check specifically what you took the time to recommend, so here's the cat (after unplugging the cable which I forgot to do in my first retest)...
[BTW, can I ask why you suggested I have no network cable plugged in - this shouldn't make a difference, right?]
[EMAIL PROTECTED] /root> # cat /proc/interrupts CPU0 0: 4547 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 4: 650 XT-PIC serial 8: 0 XT-PIC rtc 10: 0 XT-PIC eth0 14: 134 XT-PIC ide0 NMI: 0 ERR: 0
Yup, got the problem (error msg et al) again.
Odd though, that COM2 isn't showing up with an IRQ... ??? ... It's active in BIOS and shows up in the boot-up messages.
Maybe if you swap that card to another PCI slot, it would get a differentFor one test I had reserved the normally-assigned IRQ 10 for ISA (via BIOS), which forced the card to get IRQ 11, but the problem remained. As well in another test I recall moving this net card to the neighbouring slot and it still got IRQ 10 (i.e. mobo-based IRQ assignment algorithm).
interrupt and then
stop behaving like that.
FWIW I had also removed all cards except the VGA and the D-Link and the problem persisted (and the VGA was, via a jumper on the card, told not to get an interrupt and indeed it was not ... but would when I changed the jumper setting ... I mention this only because my experience is that IRQ assignment for VGA cards is usually done via BIOS, but not the crappy Phoenix BIOS on my mobo ... instead it was done via the jumper on the VGA card itself - and via watching the POST screen I saw that the jumper on/off did what was expected in terms of assigning, or not, an interrupt).
Did you disable the USB controller on the motherboard? You would gain an extra interrupt.
Never enabled it at all, since I have no use for USB on the mobo.
Here's my IRQ usage (all cards inserted): 3 - COM2 4 - COM1 5 - COM 3 (ISA modem, IRQ reserved for ISA in BIOS) 7 - LPT - mobo 9 - ETH0 (ISA, IRQ reserved for ISA in BIOS) 10 - ETH1 (PCI) 11 - ETH2 (PCI) 12 - available (since PS/2 mouse is disabled via mobo jumper)
I do have a second LPT port (ISA card) in the machine but the jumper on it - IRQ5 or IRQ 7 or <none> (=unjumpered, and the /only/ officially recommended setting, per the doc'n for the card) seemed to have no effect from what I could tell in terms of running an old DOS util called IRQStat - also confirmed via checking /proc/interrupts with various jumper configs tested). The DMESG info from boot-up indicates that IRQ 7 is assigned for LPT1 but makes no mention of an IRQ for LPT2, though it recognizes both LPT's and does polling on both of them. I only have IRQ 7 assigned because the BIOS gives no choice of "no-IRQ" for the built-in LPT port.
It (/net/via-rhine) not working sure confounded me, since I was pretty darned fastidious about my IRQ assignments, given how full my slots are.
scott; canada
----Original Message-----
From: freeman groups [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 16, 2004 9:50 PM
To: LEAF
Subject: [leaf-user] uClibc 2.2.0_b4 - Caution using via-rhine - "kernel BUG at slab.c:1130!"/"In interrupt handler - not syncing"/"Kernel panic"
My net card in question is a D-Link DFE-530TX Rev A1. I have been placing the modules into the modules package (/lib/modules folder) and backing up.
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html