> 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.
-
(I've added apcupsd-users to the cc: list. Let's stop copying the kernel
guys after this message and move the discussion to apcupsd-users.)
Christian Pernegger wrote:
Still up with just the apcupsd patch - I'm getting optimistic :)
Excellent. To recap, for anyone who got lost in all the patch
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 Pernegger wrote:
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.
Well, good. I have removed the kernel patch and run only
[I've dropped the Linux USB guys from the cc...yell if you want back on.
I'll leave linux-usb-devel on there for now, for the sake of the
archives.]
Christian Pernegger wrote:
Christian, any news from your tests?
So far, looking good:
20:37:26 up 1 day, 20:35, 1 user, load average: 0.00,
> 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
Adam Kropelin wrote:
Christian Pernegger wrote:
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 r
Christian Pernegger wrote:
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
> 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.
Adam Kropelin wrote:
Martin Kessler wrote:
Have to correct my last email, I just wasn't patient enough, it took
20min between starting service apcupsd and "NIS server startup
succeeded" message. Could also be that the communication came up because
we had a few voltage fluctuations right before
Martin Kessler wrote:
Have to correct my last email, I just wasn't patient enough, it took
20min between starting service apcupsd and "NIS server startup
succeeded" message. Could also be that the communication came up
because
we had a few voltage fluctuations right before the message. Its
defi
Martin Kessler wrote:
Adam Kropelin wrote:
Martin Kessler wrote:
The kernel patch alone did not work , I'm still having the same
problem. I started testing the apcupsd patch yesterday on one of our
production servers w/o kernel patch.
It would be best to test them together as I said above.
> 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
Adam Kropelin wrote:
Martin Kessler wrote:
Adam Kropelin wrote:
Martin Kessler wrote:
Adam Kropelin wrote:
I've attached a rather ugly hack to fix the problem in hid-core. I
don't know if this alone will solve Martin's lockup, but I'm
hoping it
does.
I disregarded your earlier patc
Adam Kropelin wrote:
Martin Kessler wrote:
Adam Kropelin wrote:
Martin Kessler wrote:
Adam Kropelin wrote:
I've attached a rather ugly hack to fix the problem in hid-core. I
don't know if this alone will solve Martin's lockup, but I'm
hoping it
does.
I disregarded your earlier patc
Adam Kropelin wrote:
Martin Kessler wrote:
Adam Kropelin wrote:
Martin Kessler wrote:
Adam Kropelin wrote:
I've attached a rather ugly hack to fix the problem in hid-core. I
don't know if this alone will solve Martin's lockup, but I'm
hoping it
does.
I disregarded your earlier patc
Martin Kessler wrote:
Adam Kropelin wrote:
Martin Kessler wrote:
Adam Kropelin wrote:
I've attached a rather ugly hack to fix the problem in hid-core. I
don't know if this alone will solve Martin's lockup, but I'm hoping
it
does.
I disregarded your earlier patch, don't think it makes s
Adam Kropelin wrote:
Martin Kessler wrote:
Adam Kropelin wrote:
I've attached a rather ugly hack to fix the problem in hid-core. I
don't know if this alone will solve Martin's lockup, but I'm hoping it
does.
I disregarded your earlier patch, don't think it makes sense to patch
too much ;-
Martin Kessler wrote:
Adam Kropelin wrote:
I've attached a rather ugly hack to fix the problem in hid-core. I
don't know if this alone will solve Martin's lockup, but I'm hoping
it
does.
I disregarded your earlier patch, don't think it makes sense to patch
too much ;-) I assumed this is what
Adam Kropelin wrote:
Alan Stern wrote:
On Sun, 12 Jun 2005, Adam Kropelin wrote:
So the basic algorithm means we should expect to see bursts of 16
control transfers once every 60 seconds, plus additional bursts
generated in response to interrupt transfers. What's happening in
That does f
Alan Stern wrote:
On Sun, 12 Jun 2005, Adam Kropelin wrote:
So the basic algorithm means we should expect to see bursts of 16
control transfers once every 60 seconds, plus additional bursts
generated in response to interrupt transfers. What's happening in
That does fit the pattern in the log.
On Sun, 12 Jun 2005, Adam Kropelin wrote:
> These calls did appear when we did hid-core debug, and they're normal.
> An UPS typically supports dozens of reports containing everything from
> simple boolean flags (on-battery) to line quality (line-voltage,
> line-frequency) to environmental data
Alan Stern wrote:
On Sun, 12 Jun 2005, Martin Kessler wrote:
Well here it is, 'control queue full' appeared around 22:48 I took a
snapshot from my logfile and have attached it. its 5MB so I
compressed
it, hope thats ok ;-) If you need data prior to 21:00 as well, let me
know.
This helps. T
On Sun, 12 Jun 2005, Martin Kessler wrote:
> Well here it is, 'control queue full' appeared around 22:48 I took a
> snapshot from my logfile and have attached it. its 5MB so I compressed
> it, hope thats ok ;-) If you need data prior to 21:00 as well, let me know.
This helps. The log clearly s
Martin Kessler wrote:
Alan Stern wrote:
The next step should be to find out where they do come from.
Patched the urb.c, but i'm getting this dump's more or less once every
minute already and not only when the device went active. The apcupsd
seems to work fine though, hmm maybe its normal???
Alan Stern wrote:
On Fri, 10 Jun 2005, Martin Kessler wrote:
Here another one, btw I did pass usbfs_snoop on to the kernel during
boot, but have no entries in my logfile. Hmmm, usbcore is not a module
so usbcore.usbfs_snoop=1 should have done the job isn't it??? Currently
my apcupsd is ha
Olav Kongas wrote:
On Fri, 10 Jun 2005, Adam Kropelin wrote:
S: Product=Back-UPS CS 500 FW:808.q3.I USB FW:q3
Ah, Interesting. Is this the 120V North American model? If so, this
is
the first report I've heard of the control queue full error with a
non-European version of the BackUPS CS. Tha
On Fri, Jun 10, 2005 at 08:13:05AM -0700, David Brownell wrote:
> On Friday 10 June 2005 7:43 am, Alan Stern wrote:
> > On Fri, 10 Jun 2005, Martin Kessler wrote:
> >
> > The next step should be to find out where they do come from. It's not so
> > easy to do that,
>
> Do we know they don't come
On Friday 10 June 2005 7:43 am, Alan Stern wrote:
> On Fri, 10 Jun 2005, Martin Kessler wrote:
>
> The next step should be to find out where they do come from. It's not so
> easy to do that,
Do we know they don't come from the control queue logic inside hid-core?
That's the source of the "queue
On Fri, 10 Jun 2005, Martin Kessler wrote:
> Here another one, btw I did pass usbfs_snoop on to the kernel during
> boot, but have no entries in my logfile. Hmmm, usbcore is not a module
> so usbcore.usbfs_snoop=1 should have done the job isn't it??? Currently
> my apcupsd is hanging in state '
On Fri, 10 Jun 2005, Adam Kropelin wrote:
> > S: Product=Back-UPS CS 500 FW:808.q3.I USB FW:q3
>
> Ah, Interesting. Is this the 120V North American model? If so, this is
> the first report I've heard of the control queue full error with a
> non-European version of the BackUPS CS. That would be
On Fri, 10 Jun 2005, Martin Kessler wrote:
> Good Morning, here the requested debug output, problem finally showed up
> at around 9pm ;-) hope this will help to trace the problem.
Here is the relevant part of the file:
- skel_ls_control_qh
[db2f9180] link (1b2f9272) element (0001)
On Fri, Jun 10, 2005 at 01:24:34PM +0300, Olav Kongas wrote:
> On Thu, 9 Jun 2005, Adam Kropelin wrote:
> >
> > Indeed. I'm certain the UPS is a crucial factor since it
> > only seems to occur with certain models (two so far) and APC
> > UPS firmware is far from bug-free.
>
> Just for the record:
On Thu, 9 Jun 2005, Adam Kropelin wrote:
> David Brownell wrote:
> > On Thursday 09 June 2005 1:43 pm, Christian Pernegger
> > wrote:
> > > > Christian, if you're using a UHCI controller like
> > > > Martin
> > >
> > > No, this one is OHCI.
> > >
> > > :02:00.0 USB Controller: Advanced Mic
Alan Stern wrote:
On Thu, 9 Jun 2005, Adam Kropelin wrote:
Pete Zaitcev wrote:
OK, here is the interesting part of the trace.
Thanks for the decode...
Up to this point, something hits the UPS with control messages every
4ms
(sounds crazy, but here it is: the daemon is o
Alan Stern wrote:
On Thu, 9 Jun 2005, Martin Kessler wrote:
so far the problem did not show up, but I had the uhci_result_control:
failed with status 40 twice today during normal operation hmmm,
based on your info, I should only see it during startup isn't it???
I have attached the li
On Thu, 9 Jun 2005, Adam Kropelin wrote:
> Pete Zaitcev wrote:
> > OK, here is the interesting part of the trace.
>
> Thanks for the decode...
>
> > Up to this point, something hits the UPS with control messages every
> > 4ms
> > (sounds crazy, but here it is: the daemon is obviously out of
>
Pete Zaitcev wrote:
OK, here is the interesting part of the trace.
Thanks for the decode...
Up to this point, something hits the UPS with control messages every
4ms
(sounds crazy, but here it is: the daemon is obviously out of
control).
That is insane. No wonder the thing locks up eventual
David Brownell wrote:
On Thursday 09 June 2005 1:43 pm, Christian Pernegger wrote:
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: Adva
On Thursday 09 June 2005 1:43 pm, Christian Pernegger wrote:
> > 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
> 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,
On Thu, 9 Jun 2005, Adam Kropelin wrote:
> I'll dig into this more when I get home and have the proper tools at
> hand. I think it's unlikely that apcupsd has gone wild because we don't
> see a barrage of control messages passing thru the HID layer.
It's possible that those messages originated f
On Thu, Jun 09, 2005 at 03:34:02PM -0400, Alan Stern wrote:
> On Thu, 9 Jun 2005, Pete Zaitcev wrote:
>
> > OK, here is the interesting part of the trace.
> >
> > Up to this point, something hits the UPS with control messages every 4ms
> > (sounds crazy, but here it is: the daemon is obviously ou
On Thu, 9 Jun 2005, Pete Zaitcev wrote:
> OK, here is the interesting part of the trace.
>
> Up to this point, something hits the UPS with control messages every 4ms
> (sounds crazy, but here it is: the daemon is obviously out of control).
Weird. Those 4 ms delays are just the time it takes the
On Thu, 9 Jun 2005 10:27:27 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 9 Jun 2005, Christian Pernegger wrote:
> (Which won't be much help until Pete can decode it for us...)
OK, here is the interesting part of the trace.
Up to this point, something hits the UPS with control me
On Thu, 9 Jun 2005 10:27:27 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> (Which won't be much help until Pete can decode it for us...)
I thought you concluded that we know now that the last URB was submitted
and not completing, so I wasn't following closely. I'll dig the trace
from MARC a
On Thu, 9 Jun 2005, Christian Pernegger wrote:
> > Anyhow, thats how it looks
> > at the moment w/o errors. I'll send you another one once I see the problem.
>
> [...]
>
> > HC status
> > usbcmd= 00c1 Maxp64 CF RS
> > usbstat =
> > usbint= 000f
> > usbfrnum =
On Thu, 9 Jun 2005, Martin Kessler wrote:
> so far the problem did not show up, but I had the uhci_result_control:
> failed with status 40 twice today during normal operation hmmm,
> based on your info, I should only see it during startup isn't it???
> I have attached the lines from the logf
Alan Stern wrote:
On Wed, 8 Jun 2005, Martin Kessler wrote:
Ok, thanks its done. I do have a uhci_hcd :00:1d:1:
uhci_result_control: failed with status 40 when the USB port comes
alive (startup apcupsd), it repeats itself a few times. Is that normal
It does happen common
Alan Stern wrote:
On Wed, 8 Jun 2005, Martin Kessler wrote:
Ok, thanks its done. I do have a uhci_hcd :00:1d:1:
uhci_result_control: failed with status 40 when the USB port comes
alive (startup apcupsd), it repeats itself a few times. Is that normal
It does happen common
On Wed, Jun 08, 2005 at 09:34:03PM +0200, Christian Pernegger wrote:
> 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.
I believe the transition is th
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
On Wed, 8 Jun 2005, Martin Kessler wrote:
> Ok, thanks its done. I do have a uhci_hcd :00:1d:1:
> uhci_result_control: failed with status 40 when the USB port comes
> alive (startup apcupsd), it repeats itself a few times. Is that normal
It does happen commonly, even though in theor
On Tue, 7 Jun 2005, Martin Kessler wrote:
> I'm using uhci, again there is no usbmon in 2.6.11, nor do I know what
> exactly you want me to printk, I still have the equipment for a few days
> so I can do some test here.
> Perhaps someone can send me patch and/or tell me what you exactly need?
I
David Brownell wrote:
On Monday 06 June 2005 10:05 pm, Pete Zaitcev wrote:
On Tue, 07 Jun 2005 11:24:25 +0800, Martin Kessler <[EMAIL PROTECTED]> wrote:
I'm relying on the afflicted users to send debug traces. Sticking in a
printk might be a quicker way for Martin and Christian to ge
On Monday 06 June 2005 10:05 pm, Pete Zaitcev wrote:
> On Tue, 07 Jun 2005 11:24:25 +0800, Martin Kessler <[EMAIL PROTECTED]> wrote:
>
>
> > > I'm relying on the afflicted users to send debug traces. Sticking in a
> > > printk might be a quicker way for Martin and Christian to get infoif
> > >
On Tue, 07 Jun 2005 11:24:25 +0800, Martin Kessler <[EMAIL PROTECTED]> wrote:
> > I'm relying on the afflicted users to send debug traces. Sticking in a
> > printk might be a quicker way for Martin and Christian to get infoif
> > usbmon is proving troublesome. How's it going, guys?
> Any activ
Adam Kropelin wrote:
Alan Stern wrote:
On Thu, 2 Jun 2005, Adam Kropelin wrote:
It would certainly help to know exactly where the blockage occurs. Is
it in the HID queuing code, in the HCD (unlikely), or in the UPS
device? Suitable debugging statements ought to settle that pretty
easily.
Adam Kropelin wrote:
Alan Stern wrote:
On Thu, 2 Jun 2005, Adam Kropelin wrote:
It would certainly help to know exactly where the blockage occurs. Is
it in the HID queuing code, in the HCD (unlikely), or in the UPS
device? Suitable debugging statements ought to settle that pretty
easily.
Alan Stern wrote:
On Thu, 2 Jun 2005, Adam Kropelin wrote:
It would certainly help to know exactly where the blockage occurs.
Is
it in the HID queuing code, in the HCD (unlikely), or in the UPS
device? Suitable debugging statements ought to settle that pretty
easily.
Yes, that's a crucial de
On Thu, 2 Jun 2005, Adam Kropelin wrote:
> > It would certainly help to know exactly where the blockage occurs. Is it
> > in the HID queuing code, in the HCD (unlikely), or in the UPS device?
> > Suitable debugging statements ought to settle that pretty easily.
>
> Yes, that's a crucial detail
On Thu, Jun 02, 2005 at 10:07:12AM -0400, Alan Stern wrote:
> On Wed, 1 Jun 2005, Adam Kropelin wrote:
>
> > Poking thru hid-core.c I did see a number of things that look buggy in
> > the queuing logic. For example, this bit in the control pipe completion
> > handler...
>
> It would certainly hel
On Wed, 1 Jun 2005, Adam Kropelin wrote:
> Poking thru hid-core.c I did see a number of things that look buggy in
> the queuing logic. For example, this bit in the control pipe completion
> handler...
> ...which appears to reset the queue on successful transfers rather than
> continuing on with s
On Wed, Jun 01, 2005 at 08:20:07AM -0700, David Brownell wrote:
> On Tuesday 31 May 2005 5:12 pm, Adam Kropelin wrote:
> > ...
> >
> > Problem
> > After some period of time (minutes to hours), the BackUPS CS 650 and
> > BackUPS BR 800 models cease to respond to control transfers. Based on
> > HID
On Tuesday 31 May 2005 5:12 pm, Adam Kropelin wrote:
> ...
>
> Problem
> After some period of time (minutes to hours), the BackUPS CS 650 and
> BackUPS BR 800 models cease to respond to control transfers. Based on
> HID debug I can see that a control transfer is sent by apcupsd but a
> response ne
Hi All,
I'm the USB driver maintainer for the Apcupsd project and I currently
have 2 users (cc:ed) who are experiencing lockups (apcupsd hangs,
usually in an unkillable state) on particlar model UPSes after anywhere
from minutes to hours of uptime. I've debugged about as far as I can
without enlis
67 matches
Mail list logo
