Juha Ruotsalainen [EMAIL PROTECTED] writes:
I shut down the machine after 38 hours oops-free running.
I had to reboot after 23 days. I did not get any disconnects during
that time but for some reason vdr had become unresponsive. I could not
shut down vdr cleanly and killing it left a zombie
Eduard Huguet [EMAIL PROTECTED] writes:
So, in a nutshell: the official 2.6.20 kernel driver + the original
firmware file doesn't seem to provoque USB disconnects here, even
with EIT on.
My kernel is ubuntu dapper 2.6.15, dvb drivers from hg (4d012cd162f5)
and I can run days without problems
Patrick Boettcher [EMAIL PROTECTED] writes:
I have the feeling, that you spending your time for nothing - and that
this is my fault.
No problem. I have this funny idea that learning is never in vain :-)
Have you ever tried to use the Nova-T 500 in Windows with the same
intensity as it is
Patrick Boettcher [EMAIL PROTECTED] writes:
I think you simply made a mistake extracting the firmware from the log.
Definitely. One particularly stupid mistake seems to be that the fw
loader wants addresses to be little endian but in the trace they show
as big endian. So the addresses in my fw
Antti P Miettinen [EMAIL PROTECTED] writes:
I'll try deciphering the log more later.
OK, here's a little snippet more.
After the GPIO settings there seems to be some I2C traffic. But again
not exactly the same what the linux driver would be doing. The first
packet is a control packet:
c0 02
Henrik Beckman [EMAIL PROTECTED] writes:
Are there any differences in the windows stream ?
Well, I've only managed to look at the beginning so far, but there
seem to be at least some minor differences.
The trace starts (after some descriptor reads) with firmware
loading. The firmware seems to
I got this off list, Henrik I hope you don't mind me going back to the
list..
From: Henrik Beckman [EMAIL PROTECTED]
If someone could run usbsnoop on their windows installed nova-t 500 it might
be useful to look on how it looks in the windows stream ?
Since I have another PC with windows
Eduard Huguet [EMAIL PROTECTED] writes:
I don't know if kernel oops is related to USB disconnection.
Just look for USB disconnect in /var/log/kern.log* or dmesg output.
However, it
seems reasonable to suspect that the EIT reception has something to do with
this problems, as I never
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
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
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
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
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
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, token
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
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
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, token
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 sometimes
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
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
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
25 matches
Mail list logo
