On Tue, 14 Mar 2006 22:30:38 -0800, Marc Singer [EMAIL PROTECTED] wrote:
e0865c40 984320233 S Co:057:00 s 40 5b 0100 256 = 00010203
04050607 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e
Glued lines mean some old version. I think I saw a bug like that.
There was also
Am Mittwoch, 15. März 2006 05:23 schrieb Bob Copeland:
hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
acm_tty_unregister if=cee8896c dev=cee88980 ref=2
class_device_del call sysfs_remove_link class_dev=c9a6aec4 ref=2
dentry=c8f7a2b4
class_device_del call
Hello,
Lsusb is reporting wrong size for configuration descriptor on big endian
system.
I join a small patch to fix it.
Regards,
--
Frédéric Leroy [EMAIL PROTECTED]
Index: lsusb.c
===
RCS file:
On Wed, 2006-03-15 12:30:04 +0800, Lanslott Gish [EMAIL PROTECTED] wrote:
did you mean like that? thx.
That's basically the same patch as before?! What was ment is to move
inverting the axes into usbtouch_process_pkt().
MfG, JBG
--
Jan-Benedict Glaw [EMAIL PROTECTED].
Peter Chubb wrote:
I figured if we already knew that the device was a disk or flash from
the USB signature, why bother probing?
Sorry, I read over your patch too quickly. It would be nice if it was
that simple. Unfortunately, some of the flash devices are based on the
USBAT chip, and some HP
Alan Stern wrote:
On Mon, 13 Mar 2006, Craig W. Nadler wrote:
I've put together a patch demonstrating how Interface Association
Descriptors could be supported with a minimal amount of changes the
current USB stack. When a USB device is enumerated the descriptors are
parsed by the code in
Greg KH wrote:
On Mon, Mar 13, 2006 at 09:11:11PM -0500, Craig W. Nadler wrote:
I've put together a patch demonstrating how Interface Association
Descriptors could be supported with a minimal amount of changes the
current USB stack. When a USB device is enumerated the descriptors are
Oliver Neukum wrote:
Am Mittwoch, 15. März 2006 05:23 schrieb Bob Copeland:
acm_tty_unregister if=cee8896c dev=cee88980 ref=2
class_device_del call sysfs_remove_link class_dev=c9a6aec4 ref=2 dentry=c8f7a2b4
class_device_del call sysfs_remove_link class_dev-dev=cee88980 ref=1
dentry=ceaaa1a4
Am Mittwoch, 15. März 2006 15:44 schrieb Paul Fulghum:
Oliver Neukum wrote:
Am Mittwoch, 15. März 2006 05:23 schrieb Bob Copeland:
acm_tty_unregister if=cee8896c dev=cee88980 ref=2
class_device_del call sysfs_remove_link class_dev=c9a6aec4 ref=2
dentry=c8f7a2b4
class_device_del call
On Tue, 14 Mar 2006, Marc Singer wrote:
On Tue, Mar 14, 2006 at 11:07:02AM -0800, Marc Singer wrote:
Test 14 is returnng an error 22, EINVAL. It looks like this is due to
the parameters used in that test:
usbtest 2-2:3.0: TEST 14: 1000 ep0out, 1..512 vary 512
The call is being
On Wed, 2006-03-15 at 16:17 +0100, Oliver Neukum wrote:
Yes, this is removing the back link to the
tty class device which also has a good reference count.
So device (really the associated kobject) reference counting
is not the problem.
This is an unproven conjecture. Kobjects have their
On Wed, 15 Mar 2006, Alan Stern wrote:
On Tue, 14 Mar 2006, Marc Singer wrote:
Using the test.sh script, I get a different result. According to USBMON,
the test transmits the following:
e0865c40 984311403 S Co:057:00 s 01 0b 0
e0865c40 984318037 C Co:057:00 0 0
Am Mittwoch, 15. März 2006 16:34 schrieb Paul Fulghum:
On Wed, 2006-03-15 at 16:17 +0100, Oliver Neukum wrote:
Yes, this is removing the back link to the
tty class device which also has a good reference count.
So device (really the associated kobject) reference counting
is not the
On Wed, 15 Mar 2006, Paul Fulghum wrote:
On Wed, 2006-03-15 at 16:17 +0100, Oliver Neukum wrote:
Yes, this is removing the back link to the
tty class device which also has a good reference count.
So device (really the associated kobject) reference counting
is not the problem.
On Wed, 2006-03-15 at 09:34 +0100, Oliver Neukum wrote:
hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
acm_tty_unregister if=cee8896c dev=cee88980 ref=2
class_device_del call sysfs_remove_link class_dev=c9a6aec4 ref=2
dentry=c8f7a2b4
class_device_del call
On Wed, 15 Mar 2006, Paul Fulghum wrote:
This is becoming clearer:
1. usb device is disconnected (usb/core/hub.c:usb_disconnect)
2. usb_disconnect calls usb_disconnect recursively for child devices
3. usb_disconnect calls drivers/base/core.c:device_unregister() for dev
4.
On Wed, 2006-03-15 at 11:56 -0500, Alan Stern wrote:
Should driver core defer sysfs_remove_file until
last dev-kobj reference is dropped?
No. The files should be deleted. James Bottomley refers to this as
removing from visibility. There's no point leaving the symlink visible
once it
My computer always freezes after a few minutes with the following
workload:
- watching TV with xawtv
- backup to an external USB disk using backup2l
As long as I'm not doing both at the same time there are no problems.
Freeze means:
- X is completely frozen
- TV sound continues to be correctly
On Wed, 15 Mar 2006, Paul Fulghum wrote:
On Wed, 2006-03-15 at 11:56 -0500, Alan Stern wrote:
Should driver core defer sysfs_remove_file until
last dev-kobj reference is dropped?
No. The files should be deleted. James Bottomley refers to this as
removing from visibility. There's
On Wed, 15 Mar 2006, Adrian Bunk wrote:
My computer always freezes after a few minutes with the following
workload:
- watching TV with xawtv
- backup to an external USB disk using backup2l
As long as I'm not doing both at the same time there are no problems.
Freeze means:
- X is
Adrian,
hmm... VIA vt8237... We have several similar reports with current VIA
chipsets (KT800 and KT880) and PCI2PCI transfers (Overlay mode in
xawtv). Would you please download the latest Mercurial development tree
at
http://linuxtv.org/hg/v4l-dvb and try modprobing saa7134 with the
Am Mittwoch, 15. März 2006 20:29 schrieb Alan Stern:
On Wed, 15 Mar 2006, Paul Fulghum wrote:
On Wed, 2006-03-15 at 11:56 -0500, Alan Stern wrote:
Should driver core defer sysfs_remove_file until
last dev-kobj reference is dropped?
No. The files should be deleted. James
I'm upgrading to a newer kernel, currently using 2.6.15, and
investigating.
Unable to handle kernel NULL pointer dereference at virtual address 000d
printing eip:
f1937684
*pde =
Oops: [#1]
PREEMPT
Modules linked in: usbmon nfs lockd sunrpc radeon drm agpgart vmnet parport_pc
On Wed, Mar 15, 2006 at 09:18:17PM +0100, Duncan Sands wrote:
My computer always freezes after a few minutes with the following
workload:
- watching TV with xawtv
bttv? overlay or grabdisplay? What motherboard?
- saa7134
- overlay
- Asus A7V600-X
Ciao,
cu
Adrian
--
Is
On Wed, Mar 15, 2006 at 01:11:42PM -0800, Marc Singer wrote:
I'm upgrading to a newer kernel, currently using 2.6.15, and
investigating.
EIP is at choose_configuration+0x31/0xa1 [usbcore]
The fault is here:
/* heuristic: Linux is more likely to have class
On Wed, 15 Mar 2006, Oliver Neukum wrote:
You know, another possibility is that cdc_acm should call
tty_unregister_device as soon as the USB device is disconnected. It would
make sense; no point leaving a tty visible in sysfs if it's no longer
accessible (except through already-opened
On Wed, Mar 15, 2006 at 01:23:58PM -0800, Marc Singer wrote:
On Wed, Mar 15, 2006 at 01:11:42PM -0800, Marc Singer wrote:
I'm upgrading to a newer kernel, currently using 2.6.15, and
investigating.
EIP is at choose_configuration+0x31/0xa1 [usbcore]
I wonder if this is a clue:
hub
On Wed, 15 Mar 2006, Marc Singer wrote:
On Wed, Mar 15, 2006 at 01:11:42PM -0800, Marc Singer wrote:
I'm upgrading to a newer kernel, currently using 2.6.15, and
investigating.
EIP is at choose_configuration+0x31/0xa1 [usbcore]
The fault is here:
/*
Alan Stern wrote:
I don't know. I'm not familiar with the details of how sysfs is supposed
to work. Maybe the existence of the symlink should prevent the dentry
from being freed during sysfs_remove_dir. Or maybe sysfs_remove_dir
should modify the symlink data structure so that the other
On Wed, 15 Mar 2006, Marc Singer wrote:
On Wed, Mar 15, 2006 at 01:23:58PM -0800, Marc Singer wrote:
On Wed, Mar 15, 2006 at 01:11:42PM -0800, Marc Singer wrote:
I'm upgrading to a newer kernel, currently using 2.6.15, and
investigating.
EIP is at choose_configuration+0x31/0xa1
On Wednesday 15 March 2006 05.30, Lanslott Gish wrote:
did you mean like that? thx.
regards,
Lanslott Gish
===
--- linux-2.6.16-rc6.patched/drivers/usb/input/usbtouchscreen.c
+++
hi
here the updated version of the patch. changes since first version:
- only advertise ABS_PRESSURE when device supports it
- handle input_register_device() errors
- allow vendor specifc init to fail.
- add invert_x/invert_y modparams
- only care about 12 bits for panjit
thanks for all the
On Wed, Mar 15, 2006 at 04:52:14PM -0500, Alan Stern wrote:
On Wed, 15 Mar 2006, Marc Singer wrote:
On Wed, Mar 15, 2006 at 01:23:58PM -0800, Marc Singer wrote:
On Wed, Mar 15, 2006 at 01:11:42PM -0800, Marc Singer wrote:
I'm upgrading to a newer kernel, currently using 2.6.15, and
On Wed, Mar 15, 2006 at 10:54:37PM +0100, Daniel Ritz wrote:
hi
here the updated version of the patch. changes since first version:
- only advertise ABS_PRESSURE when device supports it
- handle input_register_device() errors
- allow vendor specifc init to fail.
- add invert_x/invert_y
On Wed, 15 Mar 2006, Paul Fulghum wrote:
If my reading of the code is correct, an existing symlink
does keep the dentry valid. In our case, there is no
symlink at the time sysfs_remove_link() is called. (see next paragraph)
And if the dentry is valid, sysfs looks to be smart enough to
not do
On Wed, 15 Mar 2006, Marc Singer wrote:
Here Linux get the 9-byte header for descriptor 1. It says wTotalLength =
0x09, which means there are no interface or endpoint descriptors
following. Hence the warning message and the oops.
In other words, your gadget driver doesn't set
Hi,
I just want to state, for your knowledge, I know nothing of USB
development at all.
I just have this question about USB HID Alphanumeric Devices
http://www.usb.org/developers/devclass_docs/Hut1_11.pdf (page 108, 18
Alphanumeric Display Page (0x14))
Is there any support for it in Linux, if
On Wed, Mar 15, 2006 at 05:25:39PM -0500, Alan Stern wrote:
On Wed, 15 Mar 2006, Marc Singer wrote:
Here Linux get the 9-byte header for descriptor 1. It says wTotalLength
=
0x09, which means there are no interface or endpoint descriptors
following. Hence the warning message
On Wed, Mar 15, 2006 at 05:25:39PM -0500, Alan Stern wrote:
On Wed, 15 Mar 2006, Marc Singer wrote:
Here Linux get the 9-byte header for descriptor 1. It says wTotalLength
=
0x09, which means there are no interface or endpoint descriptors
following. Hence the warning message
On Wed, 15 Mar 2006, Marc Singer wrote:
Ah. I misunderstood. Besides, the patch I wrote is wrong. It isn't
desc that is NULL, it's udev-config[i].intf_cache[0].
That's right.
I'll try your patch, but it looks like you made the same mistake I did
in assuming that it was the desc that is
On Wed, 15 Mar 2006, Marc Singer wrote:
Isn't that the responsibility of the gadget itself and not the UDC?
Yes, it is. What gadget driver were you using for your test?
ether.c
That's your problem. You should be using g_zero. Then test 14 would work
as expected.
I don't know why
On Wed, Mar 15, 2006 at 02:29:48PM -0500, Alan Stern wrote:
On Wed, 15 Mar 2006, Paul Fulghum wrote:
On Wed, 2006-03-15 at 11:56 -0500, Alan Stern wrote:
Should driver core defer sysfs_remove_file until
last dev-kobj reference is dropped?
No. The files should be deleted.
On Wed, 15 Mar 2006, Greg KH wrote:
(It wouldn't be a bad idea to set dev-kobj-dentry to NULL as soon as the
dentry is deallocated anyway. Doing that would make bugs a little easier
to spot.)
Due to the way that sysfs rebuilds dentrys and inodes on the fly after
memory pressure pushes
On Wed, Mar 15, 2006 at 10:24:49AM -0600, Paul Fulghum wrote:
On Wed, 2006-03-15 at 09:34 +0100, Oliver Neukum wrote:
hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
acm_tty_unregister if=cee8896c dev=cee88980 ref=2
class_device_del call sysfs_remove_link
On Wed, Mar 15, 2006 at 11:00:47AM -0600, Paul Fulghum wrote:
On Wed, 2006-03-15 at 11:56 -0500, Alan Stern wrote:
Should driver core defer sysfs_remove_file until
last dev-kobj reference is dropped?
No. The files should be deleted. James Bottomley refers to this as
removing from
On Wed, Mar 15, 2006 at 05:47:05PM -0500, Alan Stern wrote:
On Wed, 15 Mar 2006, Marc Singer wrote:
Isn't that the responsibility of the gadget itself and not the UDC?
Yes, it is. What gadget driver were you using for your test?
ether.c
That's your problem. You should be
On Wed, 2006-03-15 at 14:58 -0800, Greg KH wrote:
So dev-kobj-dentry should be set to NULL in
device_remove_file() and other code should be
fixed to check for dev-kobj-dentry == NULL ?
No, the kobject core should do it for us.
Here's a patch that should fix this up. Bob, can you try
On Wed, Mar 15, 2006 at 05:52:39PM -0500, Alan Stern wrote:
On Wed, 15 Mar 2006, Greg KH wrote:
(It wouldn't be a bad idea to set dev-kobj-dentry to NULL as soon as the
dentry is deallocated anyway. Doing that would make bugs a little easier
to spot.)
Due to the way that sysfs
On Wed, 2006-03-15 at 14:53 -0800, Greg KH wrote:
Ok, this is the problem right here. Now, how has this ever worked in
the past? Why don't cdc-acm devices with the other configuration not
also cause this issue?
Most people don't run with slab debug turned on.
Most people don't unplug the
On Wed, Mar 15, 2006 at 05:47:05PM -0500, Alan Stern wrote:
I don't know why g_ether would have a configuration with no interfaces.
A good question to ask the maintainer. Dave?
I found out what the problem is. The ether.c file has explicit code
to enable the CDC configuration for every UDC
On Wed, Mar 15, 2006 at 03:24:40PM -0600, Ballentine, Casey wrote:
I would bet we could add the vt8235 to the list of broken chipsets
as well, if it's not already there. My company has completely
Works for me 8)
A lot of this is BIOS dependant and if we can isolate cases where one
BIOS
On Wed, Mar 15, 2006 at 05:18:10PM -0600, Paul Fulghum wrote:
On Wed, 2006-03-15 at 14:53 -0800, Greg KH wrote:
Ok, this is the problem right here. Now, how has this ever worked in
the past? Why don't cdc-acm devices with the other configuration not
also cause this issue?
Most people
I've posted a first pass at a revised UDC driver to support the Sharp
LH7 processors. At the moment, only the LH7A404 parts are tested.
The hooks are in place for the LH79524 which has more endpoints and
some shuffling of the registers. Before I finalize the driver, I'll
add DMA support for all
On Wed, Mar 15, 2006 at 06:44:21PM -0500, Alan Cox wrote:
On Wed, Mar 15, 2006 at 03:24:40PM -0600, Ballentine, Casey wrote:
I would bet we could add the vt8235 to the list of broken chipsets
as well, if it's not already there. My company has completely
Works for me 8)
A lot of this
On Wed, Mar 15, 2006 at 02:58:51PM -0800, Greg KH wrote:
No, the kobject core should do it for us.
Here's a patch that should fix this up. Bob, can you try it out?
Indeed, this patch kills the oops. Thanks for everyone's diagnostics on
this one. I'll try to be more careful with my data
On Wed, Mar 15, 2006 at 07:50:52PM -0500, Bob Copeland wrote:
On Wed, Mar 15, 2006 at 02:58:51PM -0800, Greg KH wrote:
No, the kobject core should do it for us.
Here's a patch that should fix this up. Bob, can you try it out?
Indeed, this patch kills the oops. Thanks for everyone's
On Wed, Mar 15, 2006 at 05:27:28PM -0300, Mauro Carvalho Chehab wrote:
Adrian,
hmm... VIA vt8237... We have several similar reports with current VIA
chipsets (KT800 and KT880) and PCI2PCI transfers (Overlay mode in
xawtv). Would you please download the latest Mercurial development tree
i'm not sure if any touch device need this.
If some need, please move any code to general part. thx.
On 3/15/06, Jan-Benedict Glaw [EMAIL PROTECTED] wrote:
On Wed, 2006-03-15 12:30:04 +0800, Lanslott Gish [EMAIL PROTECTED] wrote:
did you mean like that? thx.
That's basically the same patch
58 matches
Mail list logo
