Hi...
I still get:
usb 2-1: USB disconnect, address 3
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C02134B4 LR: F205D414 SP: EFE87DD0 REGS: efe87d20 TRAP: 0600Not tainted
MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 6B6B6BB7, DSISR: 0120
TASK = effa4030[5] 'khubd' THREAD: ef
User mailbox exceeds allowed message count: [EMAIL PROTECTED]
Original message follows.
Received: from elive.com.tw [61.216.71.230] by mail.elive.com.tw with ESMTP
(SMTPD32-7.15) id AF4D19430372; Thu, 29 Apr 2004 09:50:05 +0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Approve
RNDIS works! :)
I did have to change the cp[28] to an if(1) in the rndis.c file, and
then I found another bug in my udc driver, but all is well now
Thanks David Brownell for all your help
I just have to start cleaning up my udc driver now, and do a little more
testing/debugging for robustnes
Alan Stern wrote:
That means changing the code that populates the devices file and changing
the code that adds and removes USB device structures. This patch takes
care of the first part. I'm delaying the second part because that section
of usbcore is still under change -- David Brownell's rev
Am Donnerstag, 29. April 2004 00:39 schrieb John Tyner:
> On Wed, 28 Apr 2004, Oliver Neukum wrote:
> > We are, at least nominally, in a stable kernel series.
> > If you do this a seamless kernel upgrade is no longer possible.
> > Is there a technical reason to do this right now?
>
> Not really. It
Am Donnerstag, 29. April 2004 01:02 schrieb Pete Zaitcev:
> On Thu, 29 Apr 2004 00:33:28 +0200
>
> Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > 2. Is there objection to introducing a 'phase' field to struct urb?
>
> The URB is way overbloated as it is. How do you want to use it?
To determine how u
On Thu, 29 Apr 2004 00:33:28 +0200
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> 2. Is there objection to introducing a 'phase' field to struct urb?
The URB is way overbloated as it is. How do you want to use it?
-- Pete
---
This SF.Net email is
On Wed, 28 Apr 2004, Oliver Neukum wrote:
> We are, at least nominally, in a stable kernel series.
> If you do this a seamless kernel upgrade is no longer possible.
> Is there a technical reason to do this right now?
Not really. It was mostly because I read the Debian people are getting
ready to
> > > finished. That's why usb_wait_for_urb() is needed.
> >
> > But is very poorly implemented.
>
> Can you come up with something better in terms of both space and time?
I am still thinking, but I am shaping thoughts. Now for some questions:
1. Does waiting for the completion handler actually
Hi Oliver,
> I never looked seriously into it. Frankly, I find it confusing.
> But the dirty deed has been done. In fact you've approved it. So for 2.6
> we'll have to live with it. For 2.7 however, I am whetting my blades and
> will do emergency surgery on that driver, if it still should need it.
Hi Greg,
> > I know that Max accepted this. So I also have to accept this, but this
> > doesn't count for the bfusb driver and inserting this hack prevents it
> > from oopsing on a UHCI controller, too.
>
> If you unlink the urb synchronously there should be no more problems, as
> Alan has fixed
On Wed, 28 Apr 2004 15:09:39 -0400 (EDT)
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Apr 2004 [EMAIL PROTECTED] wrote:
> > Perhaps I could keep the proc_ioctls from running until the device isn't
> > being used by usb-storage,
>
> That sounds feasible.
This looks like something for which
Am Mittwoch, 28. April 2004 22:17 schrieb John Tyner:
> Resend, since the first didn't appear to make it to the list. Sorry if you
> get it twice.
>
> Attached is a patch that removes the vicam firmware from the kernel
> source and moves it out to userspace to be loaded by the hotplug system.
>
> I
Am Mittwoch, 28. April 2004 22:27 schrieb Alan Stern:
> [CC: list pruned]
>
> On Wed, 28 Apr 2004, Oliver Neukum wrote:
> > > But the first case still applies. (As does the case of maverick
> > > drivers like Bluetooth that don't use usb_free_urb().) So there has to
> > > be a way for a driver to
[CC: list pruned]
On Wed, 28 Apr 2004, Oliver Neukum wrote:
> > But the first case still applies. (As does the case of maverick drivers
> > like Bluetooth that don't use usb_free_urb().) So there has to be a way
> > for a driver to wait until an URB's completion handler has finished.
> > That's
Resend, since the first didn't appear to make it to the list. Sorry if you
get it twice.
Attached is a patch that removes the vicam firmware from the kernel
source and moves it out to userspace to be loaded by the hotplug system.
It works for me. More testing would be ideal, but I think it's read
> However... Suppose you want to cancel an outstanding URB and then reuse
> that URB for a new request. Or suppose a driver's disconnect() routine
> has been called and it needs to cancel all outstanding URBs before
> allowing the driver to be unloaded from memory. In both cases it's
> necessar
> Heh, now you understand my frustration with the bluetooth code :)
I never looked seriously into it. Frankly, I find it confusing.
But the dirty deed has been done. In fact you've approved it. So for 2.6
we'll have to live with it. For 2.7 however, I am whetting my blades and
will do emergency s
On Wed, 28 Apr 2004, Greg KH wrote:
> On Wed, Apr 28, 2004 at 01:25:08PM -0400, Alan Stern wrote:
> > Greg:
> >
> > Your recent change to struct urb broke this function in the bluetooth
> > driver.
>
> I know. I really hate what the Bluetooth driver does, and it's up to
> them to keep up with
On Wed, 28 Apr 2004 [EMAIL PROTECTED] wrote:
> I think one of the threads is updfstab, lsusb, or kudzu, which access
> the device's pipe 0 through the /proc directory, while the other thread
> is just cdrom.c trying to do some stuff with the drive. I'm not sure
> how
> one could keep these thi
On Wed, Apr 28, 2004 at 08:51:38PM +0200, Oliver Neukum wrote:
>
> > > I think we should add the usb_wait_for_urb() for now, because I have to
> > > use it in two driver now (hci_usb and bfusb) and so USB interna can be
> > > changed without fixing the drivers.
> >
> > No, see my previous objectio
On Wed, Apr 28, 2004 at 02:28:56PM -0400, Alan Stern wrote:
> On Tue, 27 Apr 2004, Greg KH wrote:
>
> > So, what's next in this patch series? :)
>
> Funny you should ask...
>
> While writing those patches I noted a problem, that the USB device tree
> can change while a process reading /proc/bus
On Tue, 2004-04-27 at 18:22, David Meggy wrote:
> On Tue, 2004-04-27 at 18:07, David Brownell wrote:
> > What does /proc/rndis/0 (or whatever) have to say? At a guess,
> > I'd say that it'll NOT be in the RNDIS_DATA_INITIALIZED state,
> > it'll be in RNDIS_INITIALIZED instead.
>
> yep, that's cor
> > I think we should add the usb_wait_for_urb() for now, because I have to
> > use it in two driver now (hci_usb and bfusb) and so USB interna can be
> > changed without fixing the drivers.
>
> No, see my previous objections to this function (wrong, and broken.)
>
> Again, any reason why you can
Alan Stern wrote:
> On Wed, 28 Apr 2004 [EMAIL PROTECTED] wrote:
>
>>
>> Hello...
>>
>> I'm seeing a problem where I have an empty CD-ROM drive (or two)
>> connected to the system, and, every now and then, I get hangs during
>> boot (or issues with commands not completing once the system is up
On Tue, 27 Apr 2004, Greg KH wrote:
> So, what's next in this patch series? :)
Funny you should ask...
While writing those patches I noted a problem, that the USB device tree
can change while a process reading /proc/bus/usb/devices is traversing it,
leading to an oops when a pointer to a no-lon
On Wed, Apr 28, 2004 at 08:08:53PM +0200, Marcel Holtmann wrote:
> Hi Greg,
>
> > I know. I really hate what the Bluetooth driver does, and it's up to
> > them to keep up with the changes in urbs due to them statically
> > including a urb in their structures. That is what they agreed to when
> >
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
[EMAIL PROTECTED]
This message has been rejected because it has
a potentially e
Hi Greg,
> I know. I really hate what the Bluetooth driver does, and it's up to
> them to keep up with the changes in urbs due to them statically
> including a urb in their structures. That is what they agreed to when
> they did this a while ago. They are on their own here...
I know that Max a
On Wed, Apr 28, 2004 at 07:40:33PM +0200, Marcel Holtmann wrote:
> Hi Alan,
>
> > Your recent change to struct urb broke this function in the bluetooth
> > driver. You know, I think usb_wait_for_urb() would make an excellent
> > addition to usbcore. At some future time we could consider replac
On Wed, Apr 28, 2004 at 01:25:08PM -0400, Alan Stern wrote:
> Greg:
>
> Your recent change to struct urb broke this function in the bluetooth
> driver.
I know. I really hate what the Bluetooth driver does, and it's up to
them to keep up with the changes in urbs due to them statically
including
Hi Alan,
> Your recent change to struct urb broke this function in the bluetooth
> driver. You know, I think usb_wait_for_urb() would make an excellent
> addition to usbcore. At some future time we could consider replacing
> synchronous unlink_urb with asynchronous unlink plus wait_for_urb.
On Wed, 28 Apr 2004, Martijn Thijssen wrote:
> Hi all,
>
> I get a stacktrace with kernel 2.6.5 and a usb bluetooth dongle from 3com.
> First I load the affix kernel module then I load affix_usb and this
> results in the following stacktrace.
> I am using affix-kernel 2.1.2 It works on another pl
Hello.
There is http://www.linux-usb.org/gadget/
I read the web page's contents and I have some background to testing USB
driver.
However, now I have some questions.
Simply, in host, if I type testusb -a, dose this code make testing data for
gadget device?
That would run a bunch of tests using sta
Grzegorz Kulewski wrote:
Is anybody going to look at it? It prevents my system from shuting down.
Looks like one of the problems already fixed in the latest bk-usb.patch
found in the MM kernels ...
- Dave
On Tue, 27 Apr 2004, Grzegorz Kulewski wrote:
Hi,
I experienced this oops. I have uhci-hcd
Greg:
Your recent change to struct urb broke this function in the bluetooth
driver. You know, I think usb_wait_for_urb() would make an excellent
addition to usbcore. At some future time we could consider replacing
synchronous unlink_urb with asynchronous unlink plus wait_for_urb.
Alan Stern
尊敬的女士/先生您好：请原谅我们用此方式给您带来实惠：
IP长途电话卡、特价邮票优惠：http://www.linghuo.com
IP长途电话卡：
名称
适合地区
面值（元）
批发价（元）
联通17910
北京
100
32
联通17910
全国
100
34
北京电信17968
北京
100
37
联通17911充值卡
北京
100
On 28 Apr 2004, Rajesh Kumble Nayak wrote:
> On Wed, 2004-04-28 at 15:30, Paulo Marques wrote:
>
> >
> > - remove your line and leave Klaus Mueller's line as it was
> >
> > - your handycam seems to fail the INQUIRY message. you can try to add
> > US_FL_FIX_INQUIRY to the list of flags.
>
On Wed, 28 Apr 2004, Brett Nash wrote:
> Hello,
> Just plugged in my Casio QV-R51 camera, and got the following output:
>
> Apr 28 20:02:05 nightstar kernel: usb-storage: This device
> (07cf,1001,1000 S 05 P 01) has unneeded SubClass and Protocol entries in
> unusual_devs.h
> Apr 28 20:02:
On Wed, 28 Apr 2004 [EMAIL PROTECTED] wrote:
>
> Hello...
>
> I'm seeing a problem where I have an empty CD-ROM drive (or two)
> connected
> to the system, and, every now and then, I get hangs during boot (or
> issues with commands not completing once the system is up).
>
> I've tracked down
Rajesh Kumble Nayak wrote:
On Wed, 2004-04-28 at 15:30, Paulo Marques wrote:
- remove your line and leave Klaus Mueller's line as it was
- your handycam seems to fail the INQUIRY message. you can try to add
US_FL_FIX_INQUIRY to the list of flags.
I added this flag. Same still no success.
w
Hi all,
I have problems using my HID device. I've seen many questions on similar
topics but still I can not find any solution.
I have HID device based on ATMEL 89C5131 chip. It is a HID device. Host must
exchange 32 bytes frames with the device.
Under Windows using this device is as simple as read
Hello...
I'm seeing a problem where I have an empty CD-ROM drive (or two)
connected
to the system, and, every now and then, I get hangs during boot (or
issues with commands not completing once the system is up).
I've tracked down the issue to a sequence of events similar to the
following:
--
On Wed, 2004-04-28 at 15:30, Paulo Marques wrote:
>
> - remove your line and leave Klaus Mueller's line as it was
>
> - your handycam seems to fail the INQUIRY message. you can try to add
> US_FL_FIX_INQUIRY to the list of flags.
I added this flag. Same still no success.
when I plug the
Did you notice there was already this on unusual_devs.h?
> /* Submitted by Klaus Mueller <[EMAIL PROTECTED]> */
> UNUSUAL_DEV( 0x054c, 0x002e, 0x0106, 0x0310,
>
"Sony",
>
"Handycam",
>
US_SC_SCSI, US_PR_DEVICE, NULL,
>
US_FL_SINGLE_LUN | US_FL_MODE_XLATE),
This is supposedly the same dev
HI,
I have following out put from dmesg while plugging
Sony HC-85 Handycam to Linux USB port.
system is Linux 2.6.5
usb-storage 2-1:1.0: usb_probe_interface
usb-storage 2-1:1.0: usb_probe_interface - got id
usb-storage: USB Mass Storage device detected
usb-storage: altsetting is 0, id_ind
Is anybody going to look at it? It prevents my system from shuting down.
On Tue, 27 Apr 2004, Grzegorz Kulewski wrote:
> Hi,
>
> I experienced this oops. I have uhci-hcd and two devices. One is usb
> camera (TC111 - probably not supported under linux?) and the
> second is speedtouch modem. Ev
Hi. This is the qmail-send program at mars.net-itech.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
lists.sourceforge.net rejected recipient: [EMAIL PROTECTED]"
lists.sourcef
Hi. This is the qmail-send program at ittalent.com.cn.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. (#5.1.1)
--- Below this line is a copy
Hello,
Just plugged in my Casio QV-R51 camera, and got the following output:
Apr 28 20:02:04 nightstar kernel: usb 2-2: new full speed USB device
using address 2
Apr 28 20:02:05 nightstar kernel: Initializing USB Mass Storage
driver...
Apr 28 20:02:05 nightstar kernel: usb-storage: This de
Hello.
There is http://www.linux-usb.org/gadget/
I read the web page's contents and I have some background to testing USB
driver.
However, now I have some questions.
Simply, in host, if I type testusb -a, dose this code make testing data for
gadget device?
Of course, in gadget, it is assumed that p
51 matches
Mail list logo
