There seems to be some movement in the driver and the latest one
is not working for me (again), so I'm giving a subjective status report
for the versions I have tried lately:
Working epic100 drivers:
- 2.4.0
- 2.4.0-ac9
Broken epic100 drivers:
- 2.4.0-ac4
- 2.4.1-ac2
- 2.4.1-ac4
I have not yet looked at the source to find the problem, but the other
kernels between that each seem to contain one of the those versions above.
The symptom is always that after 'ifconfig eth0 up', the system slows down
to the point where I can hardly type on the keyboard and even 'ifconfig
eth0 down' takes serveral seconds (on an Athlon-800)!
The boot message is:
eth0: SMSC EPIC/100 83c170 at 0xd091e000, IRQ 11, 00:e0:29:6c:36:6f.
eth0: MII transceiver #3 control 3000 status 7849.
eth0: Autonegotiation advertising 01e1 link partner 0001.
epic100.c:v1.11 1/7/2001 Written by Donald Becker <[email protected]>
http://www.scyld.com/network/epic100.html
(unofficial 2.4.x kernel port, version 1.1.6, January 11, 2001)
PCI: Found IRQ 11 for device 00:0d.0
PCI: The same IRQ used for device 00:04.2
PCI: The same IRQ used for device 00:04.3
PCI: The same IRQ used for device 00:09.0
The device on 00:04:[23] is a VT82C586B USB and on 00:09:0 an
Ensoniq 5880 AudioPCI (rev 02). I can not change the IRQ settings
right now without physical access to the machine (it is locked).
At least with some broken versions, I also got these messages in
syslog (every 4 seconds):
Feb 7 21:10:06 project kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 7 21:10:06 project kernel: eth0: Transmit timeout using MII device,
Tx status 000b.
Feb 7 21:10:10 project kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 7 21:10:10 project kernel: eth0: Transmit timeout using MII device,
Tx status 000b.
Feb 7 21:10:14 project kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 7 21:10:14 project kernel: eth0: Transmit timeout using MII device,
Tx status 000b.
...
The card is acoording to lspci:
00:0d.0 Ethernet controller: Standard Microsystems Corp [SMC] 83C170QF
(rev 08)
Subsystem: Standard Microsystems Corp [SMC]: Unknown device a020
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 7000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 9800 [size=256]
Region 1: Memory at df800000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Arnd <><
ARND BERGMANN <[email protected]> ?crit :
> There seems to be some movement in the driver and the latest one
> is not working for me (again), so I'm giving a subjective status report
> for the versions I have tried lately:
>
> Working epic100 drivers:
> - 2.4.0
> - 2.4.0-ac9
Could you give a look at ac12 (fine here) ?
--
Ueimor <[email protected]>
Cogenit T?l : +33 (0) 1 40 20 08 43
53 rue Sainte Anne Fax : +33 (0) 1 40 20 08 45
75002 Paris <URL:http://www.cogenit.fr>
On Thu, 8 Feb 2001, Francois Romieu wrote:
> >
> > Working epic100 drivers:
> > - 2.4.0
> > - 2.4.0-ac9
>
> Could you give a look at ac12 (fine here) ?
>
No, does not work, same problem.
Arnd <><
ARND BERGMANN <[email protected]> ?crit :
> On Thu, 8 Feb 2001, Francois Romieu wrote:
>
> > >
> > > Working epic100 drivers:
> > > - 2.4.0
> > > - 2.4.0-ac9
> >
> > Could you give a look at ac12 (fine here) ?
> >
> No, does not work, same problem.
The modifications between ac9 and ac12 come from the new DMA
mapping. They added a bug for the (already buggy ?) big-endian
machines. I would be surprised that something has *always* been
missing in the driver and your hardware triggers it*. IMHO the culprit
is to be found elsewhere.
I'd like to know what it's worth to share an irq with a pio audio card.
--
Ueimor
On Fri, 9 Feb 2001, Francois Romieu wrote:
> ARND BERGMANN <[email protected]> ?crit :
> > On Thu, 8 Feb 2001, Francois Romieu wrote:
> >
> > > >
> > > > Working epic100 drivers:
> > > > - 2.4.0
> > > > - 2.4.0-ac9
> > >
> > > Could you give a look at ac12 (fine here) ?
> > >
> > No, does not work, same problem.
>
> The modifications between ac9 and ac12 come from the new DMA
> mapping.
What about 2.4.0-ac5? That had the same problem as -ac12. Did it also have
the new DMA mapping?
> They added a bug for the (already buggy ?) big-endian
> machines. I would be surprised that something has *always* been
> missing in the driver and your hardware triggers it*. IMHO the culprit
> is to be found elsewhere.
Yes, I'm pretty sure the problem is not only the epic100 driver, now that
I have done some more investigation. With the broken drivers (I tried
2.4.0-ac12 and 2.4.1-ac5), something generates an enourmous amount of
interrupts as soon as I run 'ifconfig eth0 up'. Within 10 seconds, I got
roughly 950000 interrupts on IRQ11, instead of 30!
After disabling the usb-uhci (I was using the JE driver) in the BIOS
setup, the system reproducibly locked up hard a few seconds after
'ifconfig eth0 up' instead of just getting slow.
Unfortunately, I have no way to also disable the sound card, but at least
it does not make a change if the sound driver is loaded or not.
> I'd like to know what it's worth to share an irq with a pio audio card.
On Monday I can ask the system administrator for the keys so I can open
the machine and put the card into another slot. Right now, USB, sound and
network are hardwired to the same IRQ, that's how the system arrived here.
Arnd <><
ARND BERGMANN <[email protected]> ?crit :
[...]
> > > > > Working epic100 drivers:
> > > > > - 2.4.0
> > > > > - 2.4.0-ac9
> > > >
> > > > Could you give a look at ac12 (fine here) ?
> > > >
> > > No, does not work, same problem.
> >
> > The modifications between ac9 and ac12 come from the new DMA
> > mapping.
> What about 2.4.0-ac5? That had the same problem as -ac12. Did it also have
> the new DMA mapping?
Yes. For completness (though irrelevant):
2.4.0-ac2 -> ac6 : DMA mapping + rev9 fixes from Andreas Steinmetz
2.4.0-ac7 -> ac10: Merge becker version 1.11 + pci_enable. No DMA mapping
2.4.0-ac11 : Merge becker version 1.11 + pci_enable + DMA mapping
[...]
> > They added a bug for the (already buggy ?) big-endian
> > machines. I would be surprised that something has *always* been
> > missing in the driver and your hardware triggers it*. IMHO the culprit
> > is to be found elsewhere.
> Yes, I'm pretty sure the problem is not only the epic100 driver, now that
> I have done some more investigation. With the broken drivers (I tried
> 2.4.0-ac12 and 2.4.1-ac5), something generates an enourmous amount of
> interrupts as soon as I run 'ifconfig eth0 up'. Within 10 seconds, I got
> roughly 950000 interrupts on IRQ11, instead of 30!
^^^^^^
No wonder the system feels sluggish.
> After disabling the usb-uhci (I was using the JE driver) in the BIOS
> setup, the system reproducibly locked up hard a few seconds after
> 'ifconfig eth0 up' instead of just getting slow.
The following informations may help:
- motherboard type
- bios revision
- lspci -x
- 2.4.2pre3 + whatever recent ac epic100 = ?
--
Ueimor
Sorry for the delay, I could not get physical access to the machine
for the last days.
I was able to do some more testing today and found this:
- The problem is not the IRQ /sharing/, after getting rid of all the
other PCI cards, the problem was still there.
- The only thing that seems to have any effect on the symptoms is the
presence of the USB driver, either usb-uhci or uhci. I am not using
USB at all. As described before, the system behaves is either of those
ways:
* epic100 driver without DMA mapping (e.g. 2.4.0-ac9): normal operation
* driver with DMA mapping+USB driver loaded: lots of interrupts -> slow
* driver with DMA mapping, USB driver not loaded: hang after ~2 seconds
- I sometimes get 'spurious interrupt: IRQ7', even though no device is
connected there. Probably not important.
On Sat, 10 Feb 2001, Francois Romieu wrote:
>
> The following informations may help:
> - motherboard type
Asus A7V, onboard USB hub and Promise ATA/100 chip
> - bios revision
Can't see right now, system was bought in October 2000
I think it was 1.004, but I am not sure.
> - lspci -x
see attachment, this was when I ripped out sound, tv and scsi
> - 2.4.2pre3 + whatever recent ac epic100 = ?
Still no improvement until latest -ac (2.4.1-ac13)
Arnd <><
I noticed that there have been updates to epic100 again and just wanted
to note that the problem remains:
2.4.2-ac3 still crashes, but it works fine when I use the epic100.c
from 2.4.0-test9, which was the last working version for me.
Arnd <><
On Thu, 15 Feb 2001, ARND BERGMANN wrote:
> Sorry for the delay, I could not get physical access to the machine
> for the last days.
>
> I was able to do some more testing today and found this:
> - The problem is not the IRQ /sharing/, after getting rid of all the
> other PCI cards, the problem was still there.
> - The only thing that seems to have any effect on the symptoms is the
> presence of the USB driver, either usb-uhci or uhci. I am not using
> USB at all. As described before, the system behaves is either of those
> ways:
> * epic100 driver without DMA mapping (e.g. 2.4.0-ac9): normal operation
> * driver with DMA mapping+USB driver loaded: lots of interrupts -> slow
> * driver with DMA mapping, USB driver not loaded: hang after ~2 seconds
> - I sometimes get 'spurious interrupt: IRQ7', even though no device is
> connected there. Probably not important.
>
> On Sat, 10 Feb 2001, Francois Romieu wrote:
>
> >
> > The following informations may help:
> > - motherboard type
> Asus A7V, onboard USB hub and Promise ATA/100 chip
>
> > - bios revision
> Can't see right now, system was bought in October 2000
> I think it was 1.004, but I am not sure.
>
> > - lspci -x
> see attachment, this was when I ripped out sound, tv and scsi
>
> > - 2.4.2pre3 + whatever recent ac epic100 = ?
> Still no improvement until latest -ac (2.4.1-ac13)
>
> Arnd <><
>
>
>