OK, I admit to my mistake. It is not the acip that needs to be disabled, it is apci. Once I corrected myself the recompiled kernel works correctly with the USB and the VIA-Rhine devices. Sorry about my mis-information.
>> John Allen wrote: >> >>>On Thursday 23 January 2003 12:19, Chmouel Boudjnah wrote: >>> >>> >>>>John Allen <[EMAIL PROTECTED]> writes: >>>> >>>> >>>>>The via-rhine driver loads fine, and ifstatus says there is a link >>>>> heartbeat, but no traffic ever goes through the interface. >>>>> >>>>> >>>>via-rhine works fine, are you sure you have your network properly >>>> configured ? >>>> >>>> >>> >>>Maybe it is just the Chaintech 7VJL then. (I have installed a 3Com >>> card >>> and it works fine). I have also tried the VIA driver from Chaintech, >>> and the one directly from VIA, same result. >>> >>>It does however work perfectly under Windows XP. >>> >>>I hopefully will be getting another 7VJL, and if works on that I can >>> just send the current one back. >>> >>>Thanks. >>> >>> >> Under THOSE circumstances, you might also see if the BIOS has the >> embedded LAN turned off. Linux can detect things that the computer >> BIOS will not flow data to, then users wonder why the heck data >> traffic cannot happen until they either use an add-on card or check >> the BIOS (sometimes in peripherals, sometimes advanced setup, >> sometimes PNP area). I have also had Linux not like defaulted >> resources that conflict but which windows treats as non-dedicated and >> uses with less efficiency if conflicted. I lost LAN, then sound, then >> both, and finally after telling my BIOS to reconfigure itself yet >> AGAIN (actually time 6, and a BIOS Flash) most conflicts were resolved >> and things worked in Linux. Chaintechs do this, some Soyo boards that >> are modern do this, Intel boards that are modern do this. >> The south bridges mitigate such things to a large degree, and I know >> this because of two things that area growing-in-frequency pattern: the >> BIOSs are coded to stack SB routed traffic first if must, and Windows >> uses SB drivers that turn conflicts over to the SB of modern boards >> rather than direct access. Internal to Windows the SB stacked IRQs are >> separated out, that is why you can see Windows using IRQs 16-20 >> internally these days-- this sacrifices efficiency per stream for >> compatibility with modern boards that in essence use the SB as a very >> good resource conflict mitigator for media and LAN data streaming, and >> they typically chunk USB into that, and firewire-- the combo of IRQ >> plus >> port set is used to determine what resource is wanted, not primarily >> just IRQ any more or IRQ foremost with I\O port second, they are used >> TOGETHER now. Over the long haul, linux will have to recognize changes >> that have descended into chipware and firmware. >> >> Thumbnail Linguistic XREF\Perspective: >> >> SOUTH BRIDGE is secondary chipset controller of resource flows, paired >> with North Bridge, or primary chipset controller. In England, it is >> called a southbridge by some, in the US two words are used for this >> chipset chip. In Europe, closest equiv. I can think of in English is >> Ancillary main chipset controller, or multimedia controller (while >> north >> bridge would be the main chipset controller). I would like to be >> enlightened as to how you folks differentiate the chips in a now-dual >> main-chipset board structure, so we can understand each other better. >> >> John. > > I have the Soyo SY-KT400 Dragon Ultra and it has the same problem, only > it does not stop at the VIA-RHINE NIC. I also loose use of my USB > devices. However when I recompile the kernel with apic disabled I > regain use of the USB and the NIC. The only drawback (with the mandrake > kernel)is that the recompiled NVIDIA kernel driver does not function > correctly. If I recompile a Vanilla kernel with the same basic options > that I use with the Mandrake kernel I have full functionality. This has > been true with both Beta 1 and Beta 2.
