Hi,
i've found some usb_buffer_alloc with GFP_KERNEL on in a probe function (kernel
2.5.70).
Since "probe" isn't ever called in process context... is that correct?
Hi,
going through the drivers, it seems that there are drivers which legitimately
use usb_set_configuration. It seems that we have to deal with it.
Some drivers, cdc-acm, -ether, really take the whole device and try
all configurations.
Some like empeg and other serial drivers use it where altsett
Hi,
you should not drop errors.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[EMAIL PROTECTED],
Hi,
you always set the same configuration. This makes doing so quite pointless.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
Hi Greg,
this cuts out old cruft.
Please apply.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[E
Hi,
setting the configuration is pointless in dabusb, isn't it?
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
Greg, if this doesn't apply to your 2.4.x tree, could you please send me
an updated tarball of your tree?
--- linux/drivers/usb.new/hid-input.c Thu May 22 22:47:00 2003
+++ linux/drivers/usb/hid-input.c Tue Jun 3 20:35:46 2003
@@ -73,8 +73,11 @@
hidinput = list_entry(lh
Ben Collins wrote:
>>Ben, it looks like your patch broke something for USB keyboards, any
>>idea?
>
>
> Yep, my patch killed hid-input from scanning HID_OUTPUT_REPORT's. Fixed
> with this patch for 2.5.70+bk. I'll send one for 2.4.x in a few minutes.
>
>
Yup, with that patch in place my keyboar
> Ben, it looks like your patch broke something for USB keyboards, any
> idea?
Yep, my patch killed hid-input from scanning HID_OUTPUT_REPORT's. Fixed
with this patch for 2.5.70+bk. I'll send one for 2.4.x in a few minutes.
--- linux/drivers/usb/input/hid-input.c 3 Jun 2003 02:53:07 -
I've narrowed this down. I'll have a patch shortly.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
---
This SF.net email is sponsored b
On Tue, Jun 03, 2003 at 06:18:13PM -0500, Jordan Breeding wrote:
> Ben Collins wrote:
> >>Hm, I just tested this on a keyboard here, and can duplicate it.
> >>
> >>Ben, it looks like your patch broke something for USB keyboards, any
> >>idea?
> >
> >
> > My patch alone on 2.4.21-rc4-i386 has work
> Can you send any debugging log information? Either USB debugging or
> usb-storage debugging. The little bit shown here doesn't say anything
> about what went wrong or how the kernel tried to fix it.
OK, here we go. I put in blank lines to make it clear where a
noticable pause occurred.
> J
On Tue, Jun 03, 2003 at 04:59:31PM -0400, Alan Stern wrote:
> I've been told it's not a good idea to put transfer buffers on the stack,
> as that's not DMA-able on some architectures. Nevertheless, it's done in
> the USB core (well, I found one place in hub.c that does it -- but that's
> after onl
>
> Hm, I just tested this on a keyboard here, and can duplicate it.
>
> Ben, it looks like your patch broke something for USB keyboards, any
> idea?
My patch alone on 2.4.21-rc4-i386 has working LED's. My patch in your
tree that you sent me with 2.4.21-rc6-sparc64 has broken LED's.
Veeery inte
Am Dienstag, 3. Juni 2003 22:59 schrieb Alan Stern:
> I've been told it's not a good idea to put transfer buffers on the stack,
> as that's not DMA-able on some architectures. Nevertheless, it's done in
> the USB core (well, I found one place in hub.c that does it -- but that's
> after only 1 minu
> Hm, I just tested this on a keyboard here, and can duplicate it.
>
> Ben, it looks like your patch broke something for USB keyboards, any
> idea?
No idea. I'm using a USB keyboard in conjunction with the patch. Let me
try a 2.5.70+bk build tonight to make sure there were no bad
interactions bet
> Hm, I just tested this on a keyboard here, and can duplicate it.
>
> Ben, it looks like your patch broke something for USB keyboards, any
> idea?
Damn. Surprised I never noticed this. Confirmed even with my 2.4
patches.
Give me an hour or so and I'll get you a fix.
--
Debian - http://www
I've been told it's not a good idea to put transfer buffers on the stack,
as that's not DMA-able on some architectures. Nevertheless, it's done in
the USB core (well, I found one place in hub.c that does it -- but that's
after only 1 minute of looking).
Does this need to be cleaned up?
Alan Ster
On Tue, Jun 03, 2003 at 01:56:19PM -0700, Greg KH wrote:
> On Tue, Jun 03, 2003 at 09:27:05AM -0700, Jordan Breeding wrote:
> > Hello,
> >
> > I have an issue with the two current USB updates --
> > they stop my keyboard LEDs from working properly. I
> > run a box with only a USB keyboard and m
On Tue, Jun 03, 2003 at 09:27:05AM -0700, Jordan Breeding wrote:
> Hello,
>
> I have an issue with the two current USB updates --
> they stop my keyboard LEDs from working properly. I
> run a box with only a USB keyboard and mouse attached.
> With 2.5.70-mm1 everything works fine, then with
>
> > 2. Reset should not mean disconnecting the other interfaces. The
> > properties internal to the drivers of the other interfaces should be
> > retained and restored. Suspend/resume is the correct model, not
> > disconnect/probe. Kicking off all drivers but restoring the altsettings
> > like we
On Tue, 3 Jun 2003, Major A wrote:
> I couldn't make sense of the cset directory, so I took the bk8
> snapshot. I still can't do anything useful with the harddrive -- it
> mounts ok, but then after the first few accesses the disk stops (the
> activity light goes dark) while the computer waits (wit
On Tue, Jun 03, 2003 at 01:01:22PM -0400, David T Hollis wrote:
> I've started looking into what it will take to port the ax8817x driver
> to 2.5 and the largest issue appears to be with subtle API changes that
> are easily resolved. However, is there any preferred manner to write it
> in 'port
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
> I mean 2.5.71 (although usb-2.5.70.bk-patches* will probably do just as
> well -- and I think you do need both). You can get 2.5.70 at
> ftp.kernel.org, and the combined patches up to the current 2.5.71 are in
> the pub/linux/kernel/v2.5/testing/cset directory.
I couldn't make sense of the cset
On Tue, 3 Jun 2003, Major A wrote:
> > Indeed. Andras or Mitch, please let us know when you've had a chance to
> > try the new version of the USB drivers (as of Monday June 2).
>
> Where can I get it from? Do you mean usb-2.5.70.bk-patches*? Do I need
> both of them?
On Tue, 3 Jun 2003 [EMAIL
Hello,
I have an issue with the two current USB updates --
they stop my keyboard LEDs from working properly. I
run a box with only a USB keyboard and mouse attached.
With 2.5.70-mm1 everything works fine, then with
2.5.70-mm3 (after then main BK branch had picked up
some USB updates) the LEDs
David:
I got three messages from you all at once on this topic; I'll try to reply
to them all together.
On Mon, 2 Jun 2003, David Brownell wrote:
> I'm not really clear how usb_device_altered() would really
> need to be different from usb_device_reset() ... except
>
> (a) reset() tries to pr
Alan Stern wrote:
On the other hand, I'd certainly expect that the fault
recovery code would work ... so fixing that oops should
get past the problem Andras reported. We don't know that
there'd be a "next problem".
I have this recurring fantasy that the fault recovery will get so good no
one wi
> > We don't have testing feedback from that new 2.5 code yet.
> > Yes, maybe it'll help us get a better handle on what's
> > going on in the earlier stages.
>
> Indeed. Andras or Mitch, please let us know when you've had a chance to
> try the new version of the USB drivers (as of Monday June 2
On Mon, 2 Jun 2003, David Brownell wrote:
> Alan Stern wrote:
>
> > Yes, maybe the original error is just a random fault, and the
> > usb_bulk/control_msg timeouts are the only real problem. However, the new
> > changes mean that usb_control_msg() is no longer called by usb-storage.
> > Maybe
Joschua:
Although you didn't say what version of the kernel you were running, the
log you just sent must have been from 2.4.20. Try sending a log from
2.4.21-rc1 or anything more recent.
> Jun 2 23:31:34 debian kernel: sdb: test WP failed, assume Write Enabled
This message is harmless.
> Ju
Please see the attached file.
33 matches
Mail list logo
