[linux-usb-devel] Problem with Ali chipset M 5273
Hi, is there any known quirk with that Aliu chipset? I've gotten a report about random crashes of a drive enclosure with this controller that go away if a NEC controller is used. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
On Sunday, 3 June 2007 17:31, Alan Stern wrote: > On Sun, 3 Jun 2007, Rafael J. Wysocki wrote: > > > Hi, > > > > One of my test boxes suspends to RAM just fine except that if ehci_hcd is > > loaded before the suspend, the box resumes immediately after going to sleep. > > Evidently the hardware thinks a wakeup event has occurred. It is > possible to disable remote wakeup via sysfs, but it would be more > interesting to find out the real reason for the wakeup. > > I don't know how to go about doing that, however. It might be some > interaction at the ACPI level, and it might involve the PCI PME# > signal. > > Do you have any USB devices attached when you suspend? Not that I know of. > You can try using the patch below to see what happens when you manually > suspend the controller. It enables PCI devices to respond to the > legacy power/state attribute. You should look at what "lspci -vv" says > about the controller's power management signals, both before and after > suspending the PCI device entry. Maybe also see what ACPI reports. I'll be able to do this in a couple of days, when I have access to the machine again. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
Pete Zaitcev wrote:
>
> BTW, here's the recipy I use for my GPS (I use it as timing source,
> so ntpd has to be able to find it in fixed place):
>
> [EMAIL PROTECTED] ~]$ cat /etc/udev/rules.d/70-gps.rules
> KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20" SYSFS{idProduct}=="0406",
> SYMLINK+="gps0"
> [EMAIL PROTECTED] ~]$
How much of the precise do u believe, in the GPS time, that is presented
to you?
When I get a datum, i never know how long the time info has been sitting
inside the unit. And with the street & trips gps-360 receiver, u can
actually ( visually ) notice that some time reports are off.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
Alan Stern wrote: > On Sun, 3 Jun 2007, Uncle George wrote: > >> Alan Stern wrote: >> >>> Another way of thinking about it: Suppose an existing device entry was >>> not removed (or least made inaccessible) when you unplugged the device >>> -- the idea being that the existing entry could be reused if you >>> plugged the device back in. Then if you never did plug it back in, the >>> old entry would hang around indefinitely, using up resources for no >>> good reason. >>> >>> Alan Stern >> How about thinking this way: >> Got a GPS hockey puck plugged into a hub. the ttyUSB0 is created, and >> the user program sees that there is a ttyUSB0. >> Application opens ttyUSB0. Application processes data from ttyUSB0. >> Everybody happy, till someone yanks the USB cord so that the connection >> is broken. >> >> Kernel sees I/O error. Application program sees I/O error. >> Application program has no idea what happened. 5 seconds later tries to >> reestablish communications with device ( still gets I/O error ). >> /dev/ttyUSB0 still alive because the application still has it opened. >> >> Now User realises that the cable was unplugged. plugs it back in. Now >> there is a ttyUSB1, and an effectively a >> dead ttyUSB0. > > Actually ttyUSB0 has been dead ever since the cable was unplugged. Not sure what you mean by that. The device may not be dead, as it may be plugged into a powered usb hub. > >> Even though the user has plugged in the USB device, the application >> still reports error. Application does not know or understand that the >> USB device is now connected to ttyUSB1. > > Nor does the kernel. All it knows is that _some_ device is now > connected to ttyUSB1. There's no way to tell that this device is in > fact the same as the one which used to be connected to ttyUSB0. Well, all it knows is that some device has connected. The kern then calls the various drivers to see is the usb device belongs to it. Garmin_gps claims device. the driver module. garmin_gps for example, then has to deceide what to do. garmin_gps knows that now a device with an identical signature is back. Is it the same as what was plugged? I dont think that has much relevance. > >> After some arbitrary while, application thinks the device is dead ( or >> user has told application so, presuming that user has any idea as to >> what happened ). Application closes FD channel. Now /dev/ttyUSB0 disappears. >> User says to application - go open ttyUSB0. Its plugged back in. its the >> only USB device. ttyUSB0 is not to be found ( under this scenario ). > > Why did the user tell the application to go open ttyUSB0? He should > have told it to go open ttyUSB1. Or better yet, to go look for any > available ttyUSB* device and present a list of possible choices if > there's more than one. > > Think about it. What would happen if you had 2 GPS devices and plugged > them both in simultaneously? One would become ttyUSB0 and the other > would become ttyUSB1. Now suppose you unplugged the ttyUSB0 device. > How would you start up the application at this point? I think its more interesting on how the user would determine which ttyUSB? is driving which device. But back to your example. The user knows that there are 2 usb devices, and 2 ttyUSB? got created. Application, at startup knows that there are 2 ttyUSB's, as the application, at startup scanned /dev/ Now, all of a sudden, there are 3 ttyUSB's . I was thinking of changing the udev .conf file to recognize the garmin_gps devices as /dev/GPS%d . But I perceive that there will be the same issues. > >> I suppose one can ask about the resources allocated for a file that has - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
On Sun, 03 Jun 2007 12:32:50 -0400, Uncle George <[EMAIL PROTECTED]> wrote:
> How about thinking this way:
>
I am quite sure that having the device to vacate the namespace upon
a disconnect is eminently doable. It's just not as simple as it looks.
I have investigated actually doing it instead of just suggesting others
to do it, and I found that I didn't care enough to overcome all
difficulties. If you care, you have to do it.
BTW, here's the recipy I use for my GPS (I use it as timing source,
so ntpd has to be able to find it in fixed place):
[EMAIL PROTECTED] ~]$ cat /etc/udev/rules.d/70-gps.rules
KERNEL=="ttyACM*", SYSFS{idVendor}=="0b20" SYSFS{idProduct}=="0406",
SYMLINK+="gps0"
[EMAIL PROTECTED] ~]$
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
On Sun, 3 Jun 2007, Uncle George wrote: > Alan Stern wrote: > > > > > Another way of thinking about it: Suppose an existing device entry was > > not removed (or least made inaccessible) when you unplugged the device > > -- the idea being that the existing entry could be reused if you > > plugged the device back in. Then if you never did plug it back in, the > > old entry would hang around indefinitely, using up resources for no > > good reason. > > > > Alan Stern > > How about thinking this way: > Got a GPS hockey puck plugged into a hub. the ttyUSB0 is created, and > the user program sees that there is a ttyUSB0. > Application opens ttyUSB0. Application processes data from ttyUSB0. > Everybody happy, till someone yanks the USB cord so that the connection > is broken. > > Kernel sees I/O error. Application program sees I/O error. > Application program has no idea what happened. 5 seconds later tries to > reestablish communications with device ( still gets I/O error ). > /dev/ttyUSB0 still alive because the application still has it opened. > > Now User realises that the cable was unplugged. plugs it back in. Now > there is a ttyUSB1, and an effectively a > dead ttyUSB0. Actually ttyUSB0 has been dead ever since the cable was unplugged. > Even though the user has plugged in the USB device, the application > still reports error. Application does not know or understand that the > USB device is now connected to ttyUSB1. Nor does the kernel. All it knows is that _some_ device is now connected to ttyUSB1. There's no way to tell that this device is in fact the same as the one which used to be connected to ttyUSB0. > After some arbitrary while, application thinks the device is dead ( or > user has told application so, presuming that user has any idea as to > what happened ). Application closes FD channel. Now /dev/ttyUSB0 disappears. > User says to application - go open ttyUSB0. Its plugged back in. its the > only USB device. ttyUSB0 is not to be found ( under this scenario ). Why did the user tell the application to go open ttyUSB0? He should have told it to go open ttyUSB1. Or better yet, to go look for any available ttyUSB* device and present a list of possible choices if there's more than one. Think about it. What would happen if you had 2 GPS devices and plugged them both in simultaneously? One would become ttyUSB0 and the other would become ttyUSB1. Now suppose you unplugged the ttyUSB0 device. How would you start up the application at this point? > I suppose one can ask about the resources allocated for a file that has > been opened, and someone else deletes file. The application still sees > the file, but the rest of the world does not. a new file, with same name > can be created which wont affect the deleted, but still present file. > Once the deleted file is closed, those resources will be returned to > their respective pools. Unfortunately, tty device nodes are treated differently by the kernel from regular file nodes. I don't know why that is or what would be needed to change it; it might have to do with the inner workings of the tty subsystem -- with which I am completely unfamiliar. There are others on this mailing list who know more about it. > Garmin_GPS, the device handler for the hockey puck GPS device, knows > that the newly plugged in USB device is inder its wings. Does garmin_gps > know that the device has disconnected? It certainly knows when the USB > device gets connected. Yes, the device driver is notified about both connect and disconnect events. > I suppose we can play mix & match for some time with when and how USB > devices get connected and assigned /dev/ names. But if you cannot get > garmin_gps to reconnect to ttyUSB0 when the device is unplugged ( but > not closed) then maybe the special dev should be erased, and the > internal names erased. I'm not familiar enough with either the tty subsystem or with the way the USB subsystem interacts with it to provide much help. What happens if you plug in the GPS device, unplug it (without running any programs), and then plug it back in again? Does it return as ttyUSB0, or does it become ttyUSB1 in spite of the fact that there is no more ttyUSB0? Different subsystems are inconsistent in the way they number devices. For example, the SCSI subsystem numbers host adapters in increasing order, always. The next host adapter gets the next number, even if some earlier numbers have become available again. By contrast, SCSI disks are assigned the first available disk letter, so if a disk is removed and then reconnected its letter will be reused. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ __
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
Alan Stern wrote: > > Another way of thinking about it: Suppose an existing device entry was > not removed (or least made inaccessible) when you unplugged the device > -- the idea being that the existing entry could be reused if you > plugged the device back in. Then if you never did plug it back in, the > old entry would hang around indefinitely, using up resources for no > good reason. > > Alan Stern How about thinking this way: Got a GPS hockey puck plugged into a hub. the ttyUSB0 is created, and the user program sees that there is a ttyUSB0. Application opens ttyUSB0. Application processes data from ttyUSB0. Everybody happy, till someone yanks the USB cord so that the connection is broken. Kernel sees I/O error. Application program sees I/O error. Application program has no idea what happened. 5 seconds later tries to reestablish communications with device ( still gets I/O error ). /dev/ttyUSB0 still alive because the application still has it opened. Now User realises that the cable was unplugged. plugs it back in. Now there is a ttyUSB1, and an effectively a dead ttyUSB0. Even though the user has plugged in the USB device, the application still reports error. Application does not know or understand that the USB device is now connected to ttyUSB1. After some arbitrary while, application thinks the device is dead ( or user has told application so, presuming that user has any idea as to what happened ). Application closes FD channel. Now /dev/ttyUSB0 disappears. User says to application - go open ttyUSB0. Its plugged back in. its the only USB device. ttyUSB0 is not to be found ( under this scenario ). I suppose one can ask about the resources allocated for a file that has been opened, and someone else deletes file. The application still sees the file, but the rest of the world does not. a new file, with same name can be created which wont affect the deleted, but still present file. Once the deleted file is closed, those resources will be returned to their respective pools. Garmin_GPS, the device handler for the hockey puck GPS device, knows that the newly plugged in USB device is inder its wings. Does garmin_gps know that the device has disconnected? It certainly knows when the USB device gets connected. I suppose we can play mix & match for some time with when and how USB devices get connected and assigned /dev/ names. But if you cannot get garmin_gps to reconnect to ttyUSB0 when the device is unplugged ( but not closed) then maybe the special dev should be erased, and the internal names erased. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
On Sun, 3 Jun 2007, Uncle George wrote: > Robert Hancock wrote: > > > It's because you haven't done anything to handle the error which is > still persisting. Likely the only thing sane you can do in this case is > close the fd and try to reopen it later. > > > This seems to be true, but not for what you might think. > > It appears that if u plug the USB/serial device back into the usb-hub, > the code creates a /dev/ttyUSB1 ( if you have not yet closed the > disconnected /dev/ttyUSB0. ) When you do close /dev/ttyUSB0, then the > device is erased from the /dev directory. > > Now /dev/ttyUSB1 is the device. And /dev/ttyUSB0 disappeared. This does > not seem proper. As now the program has no idea or capability to re-open > the GPS device. > > I have been informed that this was an approved kernel feature. Is this > suppose to happen? Or was it an unintended consequence? It is supposed to happen. The old ttyUSB0 device can't disappear so long as the program is using it. Hence the new device entry needs to use a different name. > NOTE: this was a continuing discussion on what select() should be > returning if a USB device is physically pulled from its socket. Then, of > course, what happens when you plug the device back in. I received no > reply to what (should) happen when the device is plugged back in, but > the FD has not yet been closed. The system has no way of knowing whether you plugged the same device back in or plugged in a different but similar device. So all new plug-in events are treated as new devices. Another way of thinking about it: Suppose an existing device entry was not removed (or least made inaccessible) when you unplugged the device -- the idea being that the existing entry could be reused if you plugged the device back in. Then if you never did plug it back in, the old entry would hang around indefinitely, using up resources for no good reason. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Proofreading your professional documents
Dear Professor/Researcher Please excuse us for contacting you directly. We are offering an efficient service to help you ensure your academic and professional work is written in perfect English. We will check the grammar and style of your work and return it to you to meet your requirements and deadlines. Proof-Reading-Service.com can provide you with a professional proofreading service at a very reasonable rate. All our proofreaders are highly qualified native English speakers. Many work as leading academics in their fields and all have extensive experience of proofreading to the highest standards. If you are interested in our service, please take a look at our website: www.proof-reading-service.com All you have to do is send us your document as a word attachment with the deadline and we will guarantee delivery of a perfectly written document to give you complete confidence when you submit your work. The fee is worked out on a flat rate (£6.95 per thousand words or 0.695 pence per word), so you know exactly how much the proofreading will cost in advance. Once we have received your document(s) we will confirm the word count, the price and the deadline. If you have not heard from us within 2 hours during normal business hours after you have sent your work please resend it from a different email account or send the file to [EMAIL PROTECTED] We look forward to hearing from you! Yours faithfully Proof-Reading-Service.com - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
On Sun, 3 Jun 2007, Rafael J. Wysocki wrote: > Hi, > > One of my test boxes suspends to RAM just fine except that if ehci_hcd is > loaded before the suspend, the box resumes immediately after going to sleep. Evidently the hardware thinks a wakeup event has occurred. It is possible to disable remote wakeup via sysfs, but it would be more interesting to find out the real reason for the wakeup. I don't know how to go about doing that, however. It might be some interaction at the ACPI level, and it might involve the PCI PME# signal. Do you have any USB devices attached when you suspend? You can try using the patch below to see what happens when you manually suspend the controller. It enables PCI devices to respond to the legacy power/state attribute. You should look at what "lspci -vv" says about the controller's power management signals, both before and after suspending the PCI device entry. Maybe also see what ACPI reports. Alan Stern Index: usb-2.6/drivers/base/power/sysfs.c === --- usb-2.6.orig/drivers/base/power/sysfs.c +++ usb-2.6/drivers/base/power/sysfs.c @@ -45,10 +45,6 @@ static ssize_t state_store(struct device pm_message_t state; int error = -EINVAL; - /* disallow incomplete suspend sequences */ - if (dev->bus && (dev->bus->suspend_late || dev->bus->resume_early)) - return error; - state.event = PM_EVENT_SUSPEND; /* Older apps expected to write "3" here - confused with PCI D3 */ if ((n == 1) && !strcmp(buf, "3")) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
Uncle George wrote: > Robert Hancock wrote: >> It's because you haven't done anything to handle the error which is > still persisting. Likely the only thing sane you can do in this case > is close the fd and try to reopen it later. >> > This seems to be true, but not for what you might think. > > It appears that if u plug the USB/serial device back into the usb-hub, > the code creates a /dev/ttyUSB1 ( if you have not yet closed the > disconnected /dev/ttyUSB0. ) When you do close /dev/ttyUSB0, then the > device is erased from the /dev directory. > > Now /dev/ttyUSB1 is the device. And /dev/ttyUSB0 disappeared. This > does not seem proper. As now the program has no idea or capability to > re-open the GPS device. Sure it does. The days of programs being able to blindly assume static device names are gone. Hotplug is upon us and it necessitates a different way of thinking, even in userspace. Apps need to be smart enough to re-enumerate compatible devices and pick one. Even if the kernel were to maintain the illusion of a static device name in the simple case, the app still needs smarts to handle the general case. And I say this as the maintainer of an app that is going thru exactly this evolution. It's painful, but necessary. --Adam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Kernel 2.6.22-rc3 breaks USB: Unable to get HID descriptor (error sending control message: Operation not permitted)
On Sun, 3 Jun 2007, Oliver Neukum wrote:
> Am Sonntag, 3. Juni 2007 12:36 schrieb Justin Piszcz:
>>
>> On Sun, 3 Jun 2007, Jiri Kosina wrote:
>>
>>> On Sat, 2 Jun 2007, Justin Piszcz wrote:
>
failed to claim USB device, trying 2 more time(s)...
detaching kernel driver from USB device...
>>>
>>> Could you please provide strace outputs (or put it on the web somewhere if
>>> it's too big) for the failing and succeeding claiming of the device?
>
> static int usbdev_ioctl(struct inode *inode, struct file *file, unsigned int
> cmd, unsigned long arg)
> {
> struct dev_state *ps = file->private_data;
> struct usb_device *dev = ps->dev;
> void __user *p = (void __user *)arg;
> int ret = -ENOTTY;
>
> if (!(file->f_mode & FMODE_WRITE))
> return -EPERM;
>
> That check fails as your application falls back to opening read only in
> case of insufficient permissions. Did you change some udev rules?
>
> Regards
> Oliver
>
Nope and just to verify that I made sure I tested this a couple times.
Booted 2.6.21.3 no problems, then booted 2.6.23-rc3 w/out your patch,
problem happens again.
Justin.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Kernel 2.6.22-rc3 breaks USB: Unable to get HID descriptor (error sending control message: Operation not permitted)
Am Sonntag, 3. Juni 2007 11:55 schrieb Jiri Kosina: > I have looked into NUT source and it seems that this error message is > output after interaction with libusb, not hiddev. It looks like libusb's > usb_claim_interface() or usb_control_msg() in in 2.6.22-rc3 is failing > with -EPERM. Yes, strace and lsusb -v please. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Kernel 2.6.22-rc3 breaks USB: Unable to get HID descriptor (error sending control message: Operation not permitted)
Am Sonntag, 3. Juni 2007 12:36 schrieb Justin Piszcz:
>
> On Sun, 3 Jun 2007, Jiri Kosina wrote:
>
> > On Sat, 2 Jun 2007, Justin Piszcz wrote:
> >> failed to claim USB device, trying 2 more time(s)...
> >> detaching kernel driver from USB device...
> >
> > Could you please provide strace outputs (or put it on the web somewhere if
> > it's too big) for the failing and succeeding claiming of the device?
static int usbdev_ioctl(struct inode *inode, struct file *file, unsigned int
cmd, unsigned long arg)
{
struct dev_state *ps = file->private_data;
struct usb_device *dev = ps->dev;
void __user *p = (void __user *)arg;
int ret = -ENOTTY;
if (!(file->f_mode & FMODE_WRITE))
return -EPERM;
That check fails as your application falls back to opening read only in
case of insufficient permissions. Did you change some udev rules?
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] reincarnation of /dev/ttyUSB0 as /dev/ttyUSB1
Robert Hancock wrote: > It's because you haven't done anything to handle the error which is still persisting. Likely the only thing sane you can do in this case is close the fd and try to reopen it later. > This seems to be true, but not for what you might think. It appears that if u plug the USB/serial device back into the usb-hub, the code creates a /dev/ttyUSB1 ( if you have not yet closed the disconnected /dev/ttyUSB0. ) When you do close /dev/ttyUSB0, then the device is erased from the /dev directory. Now /dev/ttyUSB1 is the device. And /dev/ttyUSB0 disappeared. This does not seem proper. As now the program has no idea or capability to re-open the GPS device. I have been informed that this was an approved kernel feature. Is this suppose to happen? Or was it an unintended consequence? NOTE: this was a continuing discussion on what select() should be returning if a USB device is physically pulled from its socket. Then, of course, what happens when you plug the device back in. I received no reply to what (should) happen when the device is plugged back in, but the FD has not yet been closed. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] Oops in khubd
>From time to time I get the following oops message after booting. I get this since quite some time. 2.6.21 also had this problem. I think earlier kernels, too. I think that's a use-after-free bug or something like that. Look at the magic numbers [ 76.480701] Unable to handle kernel paging request for data at address 0x6b6b6b6b It doesn't happen on every boot and the machine still seems usable after it. [0.00] Using PowerMac machine description [0.00] Total memory = 512MB; using 1024kB for hash table (at cff0) [0.00] Linux version 2.6.22-rc3-wldev ([EMAIL PROTECTED]) (gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)) #43 PREEMPT Sat Jun 2 12:32:27 CEST 2007 [0.00] Found UniNorth memory controller & host bridge @ 0xf800 revision: 0xd2 [0.00] Mapped at 0xfdfc [0.00] Found a Intrepid mac-io controller, rev: 0, mapped at 0xfdf4 [0.00] Processor NAP mode on idle enabled. [0.00] PowerMac motherboard: PowerBook G4 15" [0.00] Entering add_active_range(0, 0, 131072) 0 entries of 256 used [0.00] Found UniNorth PCI host bridge at 0xf000. Firmware bus number: 0->1 [0.00] Found UniNorth PCI host bridge at 0xf200. Firmware bus number: 0->1 [0.00] Found UniNorth PCI host bridge at 0xf400. Firmware bus number: 0->1 [0.00] via-pmu: Server Mode is disabled [0.00] PMU driver v2 initialized for Core99, firmware: 0c [0.00] nvram: Checking bank 0... [0.00] nvram: gen0=478, gen1=479 [0.00] nvram: Active bank is: 1 [0.00] nvram: OF partition at 0x410 [0.00] nvram: XP partition at 0x1020 [0.00] nvram: NR partition at 0x1120 [0.00] Top of RAM: 0x2000, Total RAM: 0x2000 [0.00] Memory hole size: 0MB [0.00] Zone PFN ranges: [0.00] DMA 0 -> 131072 [0.00] Normal 131072 -> 131072 [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -> 131072 [0.00] On node 0 totalpages: 131072 [0.00] DMA zone: 1024 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 130048 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Built 1 zonelists. Total pages: 130048 [0.00] Kernel command line: root=/dev/hda5 ro [0.00] mpic: Setting up MPIC " MPIC 1 " version 1.2 at 8004, max 4 CPUs [0.00] mpic: ISU size: 64, shift: 6, mask: 3f [0.00] mpic: Initializing for 64 sources [0.00] PID hash table entries: 2048 (order: 11, 8192 bytes) [0.00] GMT Delta read from XPRAM: 0 minutes, DST: off [0.00] time_init: decrementer frequency = 18.432000 MHz [0.00] time_init: processor frequency = 1499.94 MHz [ 20.172436] Console: colour dummy device 80x25 [ 20.172954] console handover: boot [udbg0] -> real [tty0] [ 20.173493] [ 20.173502] | Locking API testsuite: [ 20.173509] [ 20.173520] | spin |wlock |rlock |mutex | wsem | rsem | [ 20.173531] -- [ 20.173546] A-A deadlock:failed|failed| ok |failed|failed|failed| [ 20.173584] A-B-B-A deadlock:failed|failed| ok |failed|failed|failed| [ 20.173619] A-B-B-C-C-A deadlock:failed|failed| ok |failed|failed|failed| [ 20.173653] A-B-C-A-B-C deadlock:failed|failed| ok |failed|failed|failed| [ 20.173688] A-B-B-C-C-D-D-A deadlock:failed|failed| ok |failed|failed|failed| [ 20.173724] A-B-C-D-B-D-D-A deadlock:failed|failed| ok |failed|failed|failed| [ 20.173760] A-B-C-D-B-C-D-A deadlock:failed|failed| ok |failed|failed|failed| [ 20.173797] double unlock: ok | ok |failed| ok |failed|failed| [ 20.173827] initialize held:failed|failed|failed|failed|failed|failed| [ 20.173864] bad unlock order: ok | ok | ok | ok | ok | ok | [ 20.173902] -- [ 20.173920] recursive read-lock: | ok | |failed| [ 20.173948]recursive read-lock #2: | ok | |failed| [ 20.173976] mixed read-write-lock: |failed| |failed| [ 20.174003] mixed write-read-lock: |failed| |failed| [ 20.174032] -- [ 20.174050] hard-irqs-on + irq-safe-A/12:failed|failed| ok | [ 20.174073] soft-irqs-on + irq-safe-A/12:failed|failed| ok | [
[linux-usb-devel] ehci_hcd causes box to resume immediately after suspend to RAM
Hi, One of my test boxes suspends to RAM just fine except that if ehci_hcd is loaded before the suspend, the box resumes immediately after going to sleep. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Kernel 2.6.22-rc3 breaks USB: Unable to get HID descriptor (error sending control message: Operation not permitted)
I have looked into NUT source and it seems that this error message is output after interaction with libusb, not hiddev. It looks like libusb's usb_claim_interface() or usb_control_msg() in in 2.6.22-rc3 is failing with -EPERM. So I am adding USB devel mailinglist into CC and leaving the original message below for reference. On Sat, 2 Jun 2007, Justin Piszcz wrote: > I use nut-2.0.4-4 with a UPS attached via USB and from 2.6.21.3 -> 2.6.22-rc3 > it stops working, see below. My .config is attached. > > 2.6.21.3: > > p34:~# /lib/nut/newhidups -u nut -DD auto > Checking device (050D/0912) (005/002) > - VendorID: 050d > - ProductID: 0912 > - Manufacturer: > - Product: UPS > - Serial Number: unknown > - Bus: 005 > Trying to match device > Device matches > HID descriptor retrieved (Reportlen = 820) > Size read for the report descriptor: 820 > Report descriptor retrieved (Reportlen = 820) > Found HID device > Network UPS Tools: New USB/HID UPS driver 0.28 (2.0.4) > > Report Descriptor size = 820 > Report Descriptor: (200 bytes) => 05 84 09 04 A1 01 05 86 09 26 A1 02 85 01 75 > 08 > Detected a UPS:/UPS > Using subdriver: Belkin HID 0.1 > Looking up 00840004 > Looking up 00860026 > Looking up 00860040 > entering string_to_path() > parsing UPS > Looking up UPS > hid_lookup_usage: found 840004 > parsing BELKINConfig > Looking up BELKINConfig > hid_lookup_usage: found 860026 > parsing BELKINConfigVoltage > Looking up BELKINConfigVoltage > hid_lookup_usage: found 860040 > Path depth = 3 > 0: UPage(84), Usage(4) > 1: UPage(86), Usage(26) > 2: UPage(86), Usage(40) > Entering libusb_get_report > =>> Before exponent: 120, 0/0) > =>> After conversion: 120.00 (120), 0/0) > Report : (8 bytes) => 01 78 80 00 00 00 00 00 > Path: UPS.BELKINConfig.BELKINConfigVoltage, Type: Feature, Value: 120.00 > Looking up 00840004 > Looking up 00860026 > Looking up 00860042 > > (works fine) > > 2.6.22-rc3: > > p34:~# /lib/nut/newhidups -u nut -DD auto > Checking device (050D/0912) (005/002) > - VendorID: 050d > - ProductID: 0912 > - Manufacturer: unknown > - Product: unknown > - Serial Number: unknown > - Bus: 005 > Trying to match device > Device matches > failed to claim USB device, trying 2 more time(s)... > detaching kernel driver from USB device... > failed to detach kernel driver from USB device... > trying again to claim USB device... > failed to claim USB device, trying 1 more time(s)... > detaching kernel driver from USB device... > failed to detach kernel driver from USB device... > trying again to claim USB device... > failed to claim USB device, trying 0 more time(s)... > detaching kernel driver from USB device... > failed to detach kernel driver from USB device... > trying again to claim USB device... > Unable to get HID descriptor (error sending control message: Operation not > permitted) > > -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
