I got oops in 2.6.0-test6 while rebooting to 2.6.0-test8 :)
I will try to reproduce it later with -test8, but in the meantime...
drivers/usb/class/usblp.c: usblp0: removed
printing eip:
c02296e5
Oops: [#1]
CPU:0
EIP:0060:[usb_buffer_free+21/96]Not tainted
EFLAGS: 00010202
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> So, my boss asks me today, "why can't we send a usb message out every
> single millisecond?" in response to my statement that there is an
> approximately 4 millisecond delay between a message being sent and
> getting a reply from the device. The curr
This fixes the memory stick SCSI access for Sony Clie SJ33 with SanDisk
memory stick. It worked in 2.4 because the usb-storage seemed to be less
picky about inquiry responses. Rather than changing the inquiry response
processing, I opt'd to put it in the busted device list.
Patch against 2.6.0-
So, my boss asks me today, "why can't we send a usb message out every
single millisecond?" in response to my statement that there is an
approximately 4 millisecond delay between a message being sent and
getting a reply from the device. The current driver we're using utilizes
the newest version of u
No, IPR is set _implicitly_ when the FIFO fills ... that's
why it's only set _explicitly_ to send short packets.
Interesting.. The UDC docs say for me that I need to set it to send the first
packet... And once I removed the printk's, I no longer had the resetting
issue.
If you're thinking about
Damien McGivern wrote:
After what I thought was a successful upgrade to
2.6.0.test8 from 2.4.22-xfs I found that my USB cable
modem, Motorola Surfboard SB4200 is not working. After
trying the following command I'm still none the wiser.
A workaround that probably suffices:
http://marc.theaimsgrou
Alan Stern wrote:
The proper fix is to change releaseintf() -- and maybe some other routines
in the usbdevfs code as well -- to use ifnum_to_if() for mapping interface
numbers to interfaces. It also won't hurt to add considerably more
locking code (dev->serialize).
Actually if you look around,
David Brownell wrote:
Damien McGivern wrote:
After what I thought was a successful upgrade to
2.6.0.test8 from 2.4.22-xfs I found that my USB cable
modem, Motorola Surfboard SB4200 is not working. After
trying the following command I'm still none the wiser.
A workaround that probably suffices:
.
Here are fixes for a couple of different big endian problems that showed up on one of
our MIPS32 board which prevented USB 2.0 from working big endian. Without these
patches, I don't think USB2.0 could have worked on any big endian architecture, unless
the length and hci_version were by coincide
On Mon, 20 Oct 2003, R2D2 wrote:
> Hello!
>
> I'm trying to develop an driver for the TUSB3410-Serial To
> USB-Converter-IC. But I'm still having problems developing the firmware
> for the IC. I always get the following message:
> usb-uhci.c: interrupt, status 2, frame# 962
> Where 962 can be a
Greg & Matt:
I'm not entirely sure about this patch. An earlier patch caused trouble
because it effectively removed the US_FL_FIX_INQUIRY flag for devices with
release number higher than 0x5009. This one might cause problems because
it explicitly goes against the immediately preceding comment in
After what I thought was a successful upgrade to
2.6.0.test8 from 2.4.22-xfs I found that my USB cable
modem, Motorola Surfboard SB4200 is not working. After
trying the following command I'm still none the wiser.
mount -t usbdevfs none /proc/bus/usb
I've included the dmesg output from both 2.4 an
Holger Schurig wrote:
Hi !
On an embedded target I have to use the SL 811 HS (sigh!).
The driver is using sl_811_rh.c, this is basically a "root-hub in software".
Now, since some time I have the following error and don't know why:
Which version of that driver are you using? As I understand,
the
Hello!
I'm trying to develop an driver for the TUSB3410-Serial To
USB-Converter-IC. But I'm still having problems developing the firmware
for the IC. I always get the following message:
usb-uhci.c: interrupt, status 2, frame# 962
Where 962 can be any number.
I'd don't know what's the reason for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > Anyway, handhelds.org CVS seems to "work". Well, except for that, uh,
> > issue where, uh, OUT packets in bulk just stopped working. But I'll debug
> > that Soon. :)
>
> Do you see that only on pxa250 B1 silicon? How about C0?
I only have B1 sili
On Sun, 19 Oct 2003, Phil Dibowitz wrote:
> I was excited there for a second, but that patch already made it into
> test8 which I'm running.
>
> I guess I should take this over the SCSI guys though. Thanks.
Yes, the patch is in -test8. I just tried it myself, plugging and
disconnecting a USB
> As I see it, we've got a bunch of things that need locking protection,
> including:
>
> 1. connect and disconnect events (device creation and deletion
> and also address-0 handling);
> 2. driver probe() and disconnect() calls, also binding and
> unbind
Alan Stern wrote:
On Sun, 19 Oct 2003, Phil Dibowitz wrote:
I was excited there for a second, but that patch already made it into
test8 which I'm running.
I guess I should take this over the SCSI guys though. Thanks.
Yes, the patch is in -test8. I just tried it myself, plugging and
disconne
On Sun, 19 Oct 2003, Greg KH wrote:
> On Sun, Oct 19, 2003 at 11:16:37AM -0400, Alan Stern wrote:
> > Greg:
> >
> > Do you have any idea when serious new development will re-commence?
>
> Has it ever really stopped? :)
Sometimes I wish it would, just for a little while...
> > There's a bunc
On Mon, 20 Oct 2003, David Brownell wrote:
> Actually if you look around, you'll notice usbcore uses about four
> different locks (including dev->serialize) to protect critical
> sections against changes to device binding ... but the only lock
> that's _correct_ to use is usb_bus_type.subsys.rwsem
Hi !
On an embedded target I have to use the SL 811 HS (sigh!).
The driver is using sl_811_rh.c, this is basically a "root-hub in software".
Now, since some time I have the following error and don't know why:
# modprobe hc_sl811
usb.c: registered new driver usbdevfs
usb.c: registered new drive
On Sun, 19 Oct 2003, Andrei Lahun wrote:
> Hello . I just found out that with latest 2.6 test i have hard lock when
> i remove my Alcatel USB cable. I managed to found a reason: when i
> remove cable - usb_disconnect function called which call
> usb_disable_device at the same time usbdefvs try to
Hello Vojtech,
Two gameport drivers need __devexit_p wrapped around their remove functions. A
newer binutils caught this is a link error. This patch fixes that.
The patch is against linux-2.5 BK as of 0700 UTC 10/20/2003 and for about two
months prior to that. The modified drivers compile clea
23 matches
Mail list logo
