On Mon, 4 Jan 2010, Sean wrote:
Alan Stern wrote:
Um, when you say it does the job, what do you mean?
It traps the error and prevents the kernel from crashing.
As did some of the earlier patches, right?
The job it was _intended_ to do was to prove that your problems are
caused by
On Tue, 5 Jan 2010, Sean wrote:
Thanks so much for your help Alan. I also think this is definitely a bug
in the hardware. Let's leave it at that, I'm happy.
Okay. You should mark the Bugzilla report as REJECTED and close it
out.
Alan Stern
--
To unsubscribe from this list: send the line
On Mon, 4 Jan 2010, Sean wrote:
Alan Stern wrote:
Try inserting a line saying:
td_check(ohci, hash, #2c);
two lines above the #2b line, i.e., just after the wmb(). That'll help
narrow down the search for the bug.
Alan,
I put the extra line in and ran capture-example twice.
Alan Stern wrote:
...
All right. Let's try this patch in place of all the others, then.
Alan Stern
Index: usb-2.6/drivers/usb/host/ohci-q.c
===
--- usb-2.6.orig/drivers/usb/host/ohci-q.c
+++ usb-2.6/drivers/usb/host/ohci-q.c
@@
On Mon, 4 Jan 2010, Sean wrote:
Alan,
This last patch seems to do the job. Thanks so much for your help! Where
do I donate/send beer?
Um, when you say it does the job, what do you mean?
The job it was _intended_ to do was to prove that your problems are
caused by hardware errors rather than
Alan Stern wrote:
Um, when you say it does the job, what do you mean?
It traps the error and prevents the kernel from crashing.
The job it was _intended_ to do was to prove that your problems are
caused by hardware errors rather than software bugs. If the patch
causes the problems to stop,
On Sat, 2 Jan 2010, Sean wrote:
Hmm, I applied the changes and I did not see a place where *prev differs
from td-td_hash. I have run memtest86+ on this box and it has passed 16
times, so I do not suspect a hardware memory error. What do you think?
Attached is the latest dmesg output.
I
Alan Stern wrote:
Here is a completely new patch. This one is more directed, to catch
the sort of errors we now know to look for.
Alan Stern
Alan,
I applied the patches and ran capture-example twice. On the second run
of capture-example a circular pointer popped up. I did not need to
Alan Stern wrote:
Got it. It's not good enough; the initial error occurred before the
start of your extract. Here's yet another version of the patch; this
one will stop printing the debug messages when an error is first
detected so maybe it won't overrun your log buffer.
Alan Stern
On Sat, 2 Jan 2010, Sean wrote:
Alan,
Thanks again. I was able to get the full dmesg output this time. I ran
capture-example three times and each time removing the webcam before
capture-example finished. On the third time I got the poisoned hash
message and I captured the output to a
Alan Stern wrote:
In other words, I'm guessing that you're suffering from hardware memory
errors. A possible way to test this is to modify the patch. In
td_free() where it adds the line:
+ ohci_dbg(hc, (%d %d) %p - %p\n, hash, n, prev,
*prev);
instead add this code:
+
Alan Stern wrote:
The patch doesn't fix anything. The point was to gather enough
information to figure out what's going wrong. Without the debug
messages, there's no information.
Perhaps things will slow down less if you change the new ohci_info()
calls in the patch to ohci_dbg(). Or
On Tue, 29 Dec 2009, Sean wrote:
I changed the debug statements to ohci_dbg and I was able to capture
the full output with klogd. It is attached.
You did not get the full output. That's why I tell people to use dmesg
instead of klogd or the kernel log files. If necessary you can always
Alan Stern wrote:
You did not get the full output. That's why I tell people to use dmesg
instead of klogd or the kernel log files. If necessary you can always
increase the size of the dmesg log buffer by changing
CONFIG_LOG_BUF_SHIFT. I tend to set it to 18; you might want to go
even higher.
On Tue, 29 Dec 2009, Sean wrote:
Alan,
Thanks for the debug patch. I'll send you the dmesg.log output in
another email. It is 2MB.
Got it. It's not good enough; the initial error occurred before the
start of your extract. Here's yet another version of the patch; this
one will stop
On Wed, 16 Dec 2009, Sean wrote:
Thanks, that patch definitely traps the bug. Unfortunately there are so
many debug messages that the capture-example.c times out trying to
connect to the webcam. The debug messages slow down the process enough
to make that happen. But if I modify your patch
Thanks, that patch definitely traps the bug. Unfortunately there are so
many debug messages that the capture-example.c times out trying to
connect to the webcam. The debug messages slow down the process enough
to make that happen. But if I modify your patch and take out the extra
debug
On Wed, 2 Dec 2009, Sean wrote:
Is there anything I can do to help? This is a show stopping bug for me.
Here's a patch you can try. It will add a _lot_ of debugging
information to the system log. Maybe it will help pin down the source
of the problem.
Alan Stern
Index:
Is there anything I can do to help? This is a show stopping bug for me.
Thanks,
Sean Lazar
Alan Stern wrote:
On Wed, 11 Nov 2009, Andrew Morton wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=14564
Summary: capture-example sleeping function called from invalid
19 matches
Mail list logo
