hm, actually, i think the issue is related to the pci latency of the cardbus controller.
after changing the latency timer of the card to 0xff, i am running the system for about an hour without freeze. the new output of lspci is:
06:01.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller (rev 01) Subsystem: ENE Technology Inc CB1410 Cardbus Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 255, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at fb600000 (32-bit, non-prefetchable) [size=4K] Bus: primary=06, secondary=07, subordinate=0a, sec-latency=176 Memory window 0: c4000000-c7fff000 (prefetchable) Memory window 1: c8000000-cbfff000 I/O window 0: 0000e000-0000e0ff I/O window 1: 0000e400-0000e4ff BridgeCtl: Parity+ SERR+ ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 Kernel driver in use: yenta_cardbus Kernel modules: yenta_socket
i am not sure, whether it is related, but the hdsp driver sets its latency timer to 0xff as well, commented with:
/* From Martin Bjoernsen : "It is important that the card's latency timer register in the PCI configuration space is set to a value much larger than 0 by the computer's BIOS or the driver. The windows driver always sets this 8 bit register [...] to its maximum 255 to avoid problems with some computers." */
maybe the ene bridge doesn't like to have devices connected, with a higher latency timer value, that it is using itself?
tim