> Martin, Chrisitan, I'd like to experiment with lowering the inter-urb
> gap time a bit. The initial patch set it to 100 msec, which hopefully is
> far longer than it really needs to be. Would you be willing to test
> another patch or two with lower timeouts?
Sure.
C.
-
Still up with just the apcupsd patch - I'm getting optimistic :)
C.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Ge
> Christian, any news from your tests?
So far, looking good:
20:37:26 up 1 day, 20:35, 1 user, load average: 0.00, 0.00, 0.00
- apcaccess status still works
- no "queue full" messages in the log
C.
---
SF.Net email is sponsored by: Discove
> Christian, any news from your tests?
Well, it's still running, but it's not even been 12 hours yet. (I had
to repeat the test because the 2.6.12-rc that I had installed because
of usbmon has had some major usb problems of its own.)
C.
---
SF
> As I'm pressured to release my hardware, could you test it as well Christian??
Sorry it took so long. With just the apcupsd-enforce-urb-delay2.patch:
apcupsd gets stuck right on startup, i. e. status queries just hang.
It can't be killed by regular kill, but kill -9 works (didn't before)
C.
> How it the testing of Christian doing?
To be honest, I had no time to test patches in the last few days - I
have a deadline to meet on Monday. Will try patches ASAP.
C.
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategi
> Christian, if you're using a UHCI controller like Martin
No, this one is OHCI.
:02:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-768 [Opus]\
USB (rev 07) (prog-if 10 [OHCI])
Subsystem: Advanced Micro Devices [AMD] AMD-768 [Opus] USB
Flags: bus master, medium devsel,
Sorry it took so long ... attached is an short usbmon snippet which
was taken with apcupsd already in the unkillable D state. Would you
like the transition working-nonworking captured?
C.
apcusb-dead.log
Description: Binary data
