Greg KH wrote:
On Thursday 30 September 2004 4:14 pm, you wrote:
I'm getting the following errors with my latest gregkh-2.6 kernel tree.
The current 2.6.9-rc3 doesn't have these errors, and I don't see them on
my ohci/ehci based laptop, only on a uhci/ehci based desktop.
I get them when I plug a
Alan Stern wrote:
According to subject of those mails, those reports are of a finepix 1300. While
i've got a finepix 4900 Zoom.
Is there some way so i can check how my camera really behaves, because it seems
to work both as a UFI device and as an 8070.
The way to tell is to turn on the
On Thu, Sep 30, 2004 at 11:23:39PM -0700, Phil Dibowitz wrote:
Greg KH wrote:
On Thursday 30 September 2004 4:14 pm, you wrote:
I'm getting the following errors with my latest gregkh-2.6 kernel tree.
The current 2.6.9-rc3 doesn't have these errors, and I don't see them on
my ohci/ehci based
On Thursday 30 of September 2004 23:58, David Brownell wrote:
On Thursday 30 September 2004 1:51 pm, Rafael J. Wysocki wrote:
Hi,
It seems there's a problem with USB OHCI driver that causes these traces
to
appear on suspend on an AMD64-based box:
Not all parts of power management
I am seeing strange behaviour with my USB stick. I can mount it
the first time it is inserted, but after unmounting, unplugging, and
plugging in again, it can't be mounted.
I have also seen one case where it was possible to mount it the second
time round, but got a kernel bug report dumped to
Am Freitag, 1. Oktober 2004 11:34 schrieb Jon Kåre Hellan:
I am seeing strange behaviour with my USB stick. I can mount it
the first time it is inserted, but after unmounting, unplugging, and
plugging in again, it can't be mounted.
I have also seen one case where it was possible to mount it
On Thursday 30 September 2004 23:40, David Woodhouse wrote:
On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
I will check it all out tonight.
Any comments?
I'm deep in the reference counting...
Duncan.
---
This SF.net email is
On Gwe, 2004-10-01 at 11:40, Al Borchers wrote:
Unfortunately, many USB serial drivers' set_termios functions
send an urb to change the termios settings and sleep waiting for
it to complete.
I just looked quickly, but it seems belkin_sa.c, digi_acceleport.c,
ftdi_sio.c, io_ti.c,
On Gwe, 2004-10-01 at 01:02, Lonnie Mendez wrote:
This patch adds the cypress_m8 usb-serial driver for the Delorme Earthmate usb gps
and the Cypress hid-com rs232 adapter to the kernel tree.
Signed-off-by: Lonnie Mendez [EMAIL PROTECTED]
Please don't add this yet. Firstly fix the fact the
Please don't add this yet. Firstly fix the fact the bogus call to
set_ldisc in the code. Secondly mask_to_rate is wrong. The mask to rate
conversions depend upon the platform (long story of compatibility) and
you should use the tty layer one.
The ioctl todo's for termios also need doing. Having
On Thu, Sep 30, 2004 at 11:27:07PM -0700, Phil Dibowitz wrote:
Alan Stern wrote:
So if you can post the dmesg output showing the system log for when you
plug in the camera, that might do the trick.
I spoke to Alan offline about a few things -- this included.
I'll wait to get the dmesg
On Thursday 30 September 2004 23:40, David Woodhouse wrote:
On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
I will check it all out tonight.
Any comments?
Here is an incremental patch. It uses a kref for reference counting,
and fixes a reference counting bug in udsl_firmware_start.
On Gwe, 2004-10-01 at 16:48, Lonnie Mendez wrote:
look at pl2303_set_termios, it's almost the exact same setup except I
exported some of the code into another function 'cypress_serial_control'. I
do not see any platform dependent code here in regards to the line setting
code. If that is
On Gwe, 2004-10-01 at 17:24, Al Borchers wrote:
Its a design decision for the tty layer. You should choose whatever is
best there and the drivers will have to adapt.
From a tty layer I don't think there is a motivation to enforce no
sleep. Hopefully nobody has a reason to need to fiddle with
On Thursday 30 September 2004 4:53 am, martin f krafft wrote:
I have a USB device (a built-in 7-in-1 Maxxtro USB 2.0 card reader)
in this 2.6.8.1 machine of mine, and it's acting up. I am seeing
messages such as the following every couple of seconds:
usb 4-6: new high speed USB device
On Fri, Oct 01, 2004 at 12:36:09PM +0100, Alan Cox wrote:
On Gwe, 2004-10-01 at 11:40, Al Borchers wrote:
Unfortunately, many USB serial drivers' set_termios functions
send an urb to change the termios settings and sleep waiting for
it to complete.
I just looked quickly, but it seems
also sprach David Brownell [EMAIL PROTECTED] [2004.10.01.1930 +0200]:
This suggests UHCI (or the hub driver?) confused usbcore somehow.
Can you find out what's at that line? There's some GDB command
that'll turn that into a line of C code if your kernel is
appropriately compiled; doesn't come
On Fri, 1 Oct 2004, martin f krafft wrote:
also sprach David Brownell [EMAIL PROTECTED] [2004.10.01.1930 +0200]:
This suggests UHCI (or the hub driver?) confused usbcore somehow.
Can you find out what's at that line? There's some GDB command
that'll turn that into a line of C code if your
Hi,
I finally tracked down one of the oopses I'm having with the latest usb
tree to the ub driver. If I revert the three patches Pete has sent me
(going back to a clean 2.6.9-rc3 version), it works. Otherwise I get
the following oops when plugging in a usb hard drive:
(copied by hand, so it
also sprach Alan Stern [EMAIL PROTECTED] [2004.10.01.2026 +0200]:
One way to do this is to run gdb hcd.o from within the
drivers/usb/core directory, and then do disass
hcd_endpoint_disable at the prompt. The output isn't very
readable because no external addresses will be given. But it's
On Thu, Sep 30, 2004 at 11:27:07PM -0700, Phil Dibowitz wrote:
Alan Stern wrote:
According to subject of those mails, those reports are of a finepix 1300.
While i've got a finepix 4900 Zoom.
Is there some way so i can check how my camera really behaves, because it
seems to work both as a
On Fri, 1 Oct 2004, Sjoerd Simons wrote:
Ok. dmesg output is attached (probably a lot more then needed)..
In this output i completely removed my cam from unusual devices and it still
works fine. So i guess my cam has a good usb implemention. Stupid hardware
vendors, putting all those
On Fri, 1 Oct 2004, martin f krafft wrote:
Are we talking about the modules directory, or the kernel source
tree? I have the former (obviously), but the latter does not exist
-- this is the Debian stock kernel after all.
I was talking about the kernel source tree. But the modules directory
also sprach Alan Stern [EMAIL PROTECTED] [2004.10.01.2113 +0200]:
No, you should use usbcore.ko.
Okay, that worked.
Now, the function starts at 0x5320, so +0x74 (from the oops) gives
0x5394... so with +/- 5 lines of context:
0x537e hcd_endpoint_disable+94: movl $0x0,0x44(%edx,%edi,4)
On Fri, Oct 01, 2004 at 03:18:23PM -0400, Alan Stern wrote:
On Fri, 1 Oct 2004, Sjoerd Simons wrote:
Ok. dmesg output is attached (probably a lot more then needed)..
In this output i completely removed my cam from unusual devices and it still
works fine. So i guess my cam has a good
Alan Cox wrote:
In a waiting case the driver will get
-chars_in_buffer
until it returns zero
-wait_until_sent
-change_termios
which serializes with respect to the one writer. If you have a writer
during a termios change by another well tough luck, you lose and I've
no
2.6.9-rc3 changes the locking in the tty_ioctl.c function
change_termios(). It gets a spin_lock_irqsave(tty_termios_lock,...)
before calling the tty driver's set_termios function.
This means that the drivers' set_termios functions cannot sleep.
Unfortunately, many USB serial drivers' set_termios
On Monday 27 September 2004 2:35 pm, Alexander Stohr wrote:
Hello,
just for your information. when compiling most recent
BK snapshot of linux kernel, i do get the below warning.
-Alex
CC [M] drivers/usb/host/ohci-hcd.o
In file included from drivers/usb/host/ohci-hcd.c:134:
From: [EMAIL PROTECTED]
Its a design decision for the tty layer. You should choose
whatever is
best there and the drivers will have to adapt.
I agree.
..Stu
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
This change definitely puts my driver into a headlock. I must call
cypress_write to set the control line within cypress_set_termios.
cypress_write locks several times when accessing the private data.
cypress_serial_control also must be called from within cypress_set_termios
which locks
On Fri, 1 Oct 2004 10:44:20 -0700 David Brownell wrote:
| On Monday 27 September 2004 2:35 pm, Alexander Stohr wrote:
| Hello,
| just for your information. when compiling most recent
| BK snapshot of linux kernel, i do get the below warning.
| -Alex
|
|CC [M]
Hello.
I am making a device driver for USB printer and I am using zero.c for this
driver.
However, I have some problems.
In zero.c, source_sink_complete() handles usb_request, and buf in
usb_request has datas sent by host.
Because I want datas received from host to be a file, so I think that, in
Please merge.
- Dave
Basic HID driver support for USB suspend/resume. At least one keyboard
works OK as a remote wakeup source ... unless when you write the sysfs
power/state attribute using that USB keyboard, in which case the input
subsystem reports an endless stream of newlines! :)
Someone
On Friday 01 October 2004 7:28 pm, wrote:
Hello.
I am making a device driver for USB printer and I am using zero.c for this
driver.
However, I have some problems.
You'd be better off writing a user mode driver with gadgetfs.
Then you can just open() the OUT file descriptor and write to
Please merge.
- Dave
Some of the recent changes to change how descriptors are read have managed
to confuse one USB keyboard. It recovers OK with a few retries though.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- 1.146/drivers/usb/core/hub.c Thu Sep 16 10:56:12 2004
+++
On Fri, 1 Oct 2004 11:39:17 -0700
Greg KH [EMAIL PROTECTED] wrote:
Pete, any ideas? Oh, it also happens on my UP laptop.
[...]
kernel BUG at kernel/timer.c:413!
I have a suspicion. Actually, it was pointed to me by a kind soul before,
but I forgot who he was, unfortunately. I'm not sure if
36 matches
Mail list logo
