If a crash occurs, most of the time I have to poweroff the machine, pull
out the powercord, power the machine on so that it discharges and then
the linksys will work again :) Else it won't find my ap. Anyway, I
digged through my pile of cables but haven't found a null-modem cable
yet, so I can't produce any serial logs (yet).
What I did notice on the epia's is that it tends to share irq with the
pci slot. I tried windows on it but the machine would just freeze if the
linksys was connected and the pvr 250 in the pci slot used. So it can
also be a irq sharing issue. I found no way however to move either the
pci or the usb to a separate irq.
The patch you sent me yesterday didn't crash on me at all while
transfering about 2gb from my epia using ftp. One thing I noticed is
that the transfer stops once in a while. This was also the case with the
unpatched/release version. I don't know for sure if this is ndiswrapper
related or something in oftpd so I need to investigate that.
I'll go shopping for a null modem cable now :)
Jan Kiszka wrote:
> Hugo Visser wrote:
>> I actually had better results not modprobing but putting an alias in
>> modules.conf. First I had ndiswrapper loaded (modprobed) at startup,
>> but for some reason this seems to be more stable, though it looks
>> quite the same to me. I guess its due to the timing of loading the usb
>> modules, but anyway you might try that too...
> Mmh, will try this. However, it remains mysterious. Yesterday I gave it
> a try on my notebook with USB 2.0 (Thinkpad R40): no chance to crash it
> here, it simply works in every order to plug/load the device and driver.
> But on the VIA system, there is a very high chance to get either a USB
> timeout or even a crash (always at the same position inside the windows
> driver) when you load the driver the second time, and a medium change
> when you load at system startup. As soon as it runs, it seems to be
> rock-stable (the EPIA system runs permanently as a router/server). The
> best chance for a successful startup is to power-cycle the USB device
> (unplug once) before booting.
> I will try to have another look at it again next week. In the meantime,
> some crash logs from other users could be helpful, maybe they point a
> bit closer to the core of the issue. My system is not that useful in
> this regard :(