Antti P Miettinen [EMAIL PROTECTED] writes:
The transaction error is for EP 3, we manage to schedule the halt
clear but the hard failure happens for EP 0. Hmm.. where are the
control urbs sent.. maybe I'll look into adding halt clearing for
those too..
Nah.. that's not correct. Comments for
Chris Johns [EMAIL PROTECTED] writes:
localhost kernel: urb completition error -32.
localhost kernel: urb completition error -71.
localhost last message repeated 347 times
localhost kernel: usb 8-1: USB disconnect, address 2
Hmm.. any comment to
Having set the buffersize to 40504, my machine is running for more
than 18 hours now, without a usb disconnect...
Kernel 2.6.21-rc1-git1
Firmware dvb-usb-dib0700-01.fw
Disconnect after 27 hours. Still local record ;-)
From syslog:
Mar 2 21:27:29 router kernel: ehci_hcd :00:0d.2:
Nils Segerdahl [EMAIL PROTECTED] writes:
The change [increasing buffer size] made the problem worse for me to.
Less than an hour, compared to about once a day before.
Hmm.. I'm running now with 40504 size buffer and dvb-usb-dib0700-01.fw
firmware and there have been no transaction
A ls -l gives this size:
29955 Feb 7 17:07 dvb-usb-dib0700-01.fw
And:
$ sum dvb-usb-dib0700-01.fw
3227130
Im quite confident its the right version. Unless i got the wrong one
when downloading.
But i will try again when im at home later.
/Nils
Antti P Miettinen wrote:
Nils
Hi Patrick,
Can you please try to increase the URB buffer size by 1KB?
Having set the buffersize to 40504, my machine is running for more
than 18 hours now, without a usb disconnect...
Kernel 2.6.21-rc1-git1
Firmware dvb-usb-dib0700-01.fw
Thats local record. Halleluja. As Richard Lithvall
Hi Antti,
beside the XactErr which is not OK, there is maybe the chance to fix the
disconnect issue:
Can you please try to increase the URB buffer size by 1KB?
in the define DIB0700_DEFAULT_STREAMING_CONFIG
you change .buffersize = 39480, to 40504.
thanks,
Patrick.
On Wed, 28 Feb 2007,
Patrick Boettcher [EMAIL PROTECTED] writes:
Can you please try to increase the URB buffer size by 1KB?
in the define DIB0700_DEFAULT_STREAMING_CONFIG
you change .buffersize = 39480, to 40504.
Did not prevent USB disconnect.
I'll be running with the original firmware for a while now to
Patrick Boettcher wrote:
Hi Antti,
beside the XactErr which is not OK, there is maybe the chance to fix the
disconnect issue:
Can you please try to increase the URB buffer size by 1KB?
in the define DIB0700_DEFAULT_STREAMING_CONFIG
you change .buffersize = 39480, to 40504.
I've
Antti P Miettinen [EMAIL PROTECTED] writes:
Antti P Miettinen [EMAIL PROTECTED] writes:
[17301248.172000] ehci_hcd :03:0c.2: XactErr, token=8038c948
[17184437.868000] ehci_hcd :03:0c.2: XactErr, token=0038c948
Aha.. looks like the new firmware (dvb-usb-dib0700-02-rc1.fw) might be
Antti P Miettinen [EMAIL PROTECTED] writes:
[17182959.448000] ehci_hcd :03:0c.2: XactErr, token=cd08
[17186270.50] ehci_hcd :03:0c.2: XactErr, token=4d08
[17192204.628000] ehci_hcd :03:0c.2: XactErr, token=4d08
[17207488.564000] ehci_hcd :03:0c.2: XactErr,
Hi Antti,
thanks for your debugging it is very helpful.
Attached you'll find the latest firwmare for the dib0700. It should reduce
the XactErr and maybe behave better all the way. Can you please check it?
Thanks a lot,
Patrick.
On Wed, 28 Feb 2007, Antti P Miettinen wrote:
Antti P
Antti P Miettinen [EMAIL PROTECTED] writes:
[17301248.172000] ehci_hcd :03:0c.2: XactErr, token=8038c948
[17184437.868000] ehci_hcd :03:0c.2: XactErr, token=0038c948
One interesting point is that the transfer length for the second last
transaction error is the same (0x38c==908) and
Patrick Boettcher [EMAIL PROTECTED] writes:
Attached you'll find the latest firwmare for the dib0700. It should reduce
the XactErr and maybe behave better all the way. Can you please check it?
Sure.
With this firmware the transaction errors seem to be pouring in:
[17179743.308000] ehci_hcd
On Wed, 28 Feb 2007, Antti P Miettinen wrote:
Patrick Boettcher [EMAIL PROTECTED] writes:
Attached you'll find the latest firwmare for the dib0700. It should reduce
the XactErr and maybe behave better all the way. Can you please check it?
Sure.
With this firmware the transaction
Patrick Boettcher [EMAIL PROTECTED] writes:
On Wed, 28 Feb 2007, Antti P Miettinen wrote:
I did not power cycle the machine, but I did override the cold/warm
check in the dvb-usb module and log shows that the new fw got
loaded. But I'll also check after power cycling the machine when I get
Antti P Miettinen [EMAIL PROTECTED] writes:
But anyway - I'll be power cycling the machine real soon now :-)
I'd say the dvb-usb-dib0700-02-rc2.fw makes the transaction errors
more frequent for me me. Here's the latest kernel log:
[17179744.028000] ehci_hcd :03:0c.2: XactErr, ep3in,
On Sun, 2007-02-25 at 12:11 +0200, Antti P Miettinen wrote:
Chris Johns [EMAIL PROTECTED] writes:
I see the same sequence that you do. Here is the specific part that
matches what I see. Your trace has:
Hmm.. I guess I need to learn to decipher the logs. Meanwhile there's
another log at
It seems that the XactErr bit gets set occasionally but does
not always lead to hard failure:
But then it seems that eventually it occasionally does:
[17182959.448000] ehci_hcd :03:0c.2: XactErr, token=cd08
[17186270.50] ehci_hcd :03:0c.2: XactErr, token=4d08
Antti P Miettinen [EMAIL PROTECTED] writes:
Anyone have a handy way of generating interrupt load?
At least flood ping is not any better in provoking the disconnect than
scp, dd'ing from disk with small packets, busylooping shell script
with and without nice etc. It just seems to happen
On Monday 26 February 2007 09:12:38 Antti P Miettinen wrote:
Are people seeing
USB disconnects without nvidia proprietary drivers? :-)
Yes, even without running X.
Janne
___
linux-dvb mailing list
linux-dvb@linuxtv.org
Janne Grunau [EMAIL PROTECTED] writes:
On Monday 26 February 2007 09:12:38 Antti P Miettinen wrote:
Are people seeing
USB disconnects without nvidia proprietary drivers? :-)
Yes, even without running X.
OK - yet another random piece of information. I added some more
ehci_dbg() calls to the
Chris Johns [EMAIL PROTECTED] writes:
I see the same sequence that you do. Here is the specific part that
matches what I see. Your trace has:
Hmm.. I guess I need to learn to decipher the logs. Meanwhile there's
another log at
http://www.hut.fi/~apm/usb-disconnect2.txt.gz
where the
Janne Grunau [EMAIL PROTECTED] writes:
I'm setting now usbmon+debugfs up to capture all usb traffic. Maybe we
could see something suspicious in there just before the disconnect.
Just trying to pitch in my humble contribution to this noble
effort.. you might be able to observe the Nova-T 500
Antti P Miettinen [EMAIL PROTECTED] writes:
I started this up about noon today (24.4.2007 EEST) so ignore anything
older.
That should be 24.2. - sorry for the time warp.
But anyway - I just got an oops so I stopped the logging. The
disconnect/oops happened at 14:23. The kernel log is at
Antti P Miettinen [EMAIL PROTECTED] writes:
http://brigitte.dna.fi/~apm/usblog.txt.gz
It's 58M so it will take a bit too long to download that via my 1280K
link. I'll try to strip irrelevant stuff as soon as I have some
time. Our kids just returned from a trip and the youngest one seems to
Antti P Miettinen wrote:
The part of the log that should contain the disconnect (according to
above reasoning) is at
http://www.hut.fi/~apm/usb-disconnect.txt.gz
it should start about minute before and stop about a minute after the
disconnect.
I see the same sequence that you do. Here is
27 matches
Mail list logo
