Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Jan 3, 2008 12:08 AM, Alan Stern <[EMAIL PROTECTED]> wrote: > On Tue, 1 Jan 2008, Greg KH wrote: > > > For most cases, yes, I agree with this, but due to the lockdep issues > > that occur here, and the whole mess with the suspend path and locking > > the device tree, that has been hashed out many times in the past, I am > > interested in trying to see if there is any real reason why this is > > absolutely necessary to convert. > > > > If no one has noticed any issues in this area, I think the complexity > > that will be involved in any such conversion will strongly outweigh any > > simplicity that might be expected. > > > > I'm very open to potential patches to do this, just don't ignore the > > issues that others have run into in the past when attempting this. > > There are two separate things to consider here. One is struct device > and the other is struct class. > > We know that replacing semaphores with mutexes in struct device doesn't > sit well with lockdep. However the replacement may work perfectly > smoothly for struct class. It would be worthwhile for Dave Young to > separate out just that part and try it. > Ok, let me try a new patch only for struct class. Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] libusb / in-kernel usb driver criteria (was: USB driver for talking to the Microchip PIC18 boot loader)
Xiaofan Chen wrote: On Dec 30, 2007 11:53 AM, mgross <[EMAIL PROTECTED]> wrote: [...] What is the linux-usb policies on new drivers that could be implemented in user space? When does a kernel driver make sense over a libusb one? That would be interesting to know. I myself have been faced with this question before, and I think we should try to clarify this by adding a document with some guidelines to Documentation/usb. So, to get the ball rolling, here are some factors that IMHO help decide in which side to implement a driver: - if the driver ties a hardware device to an existing in-kernel interface (network, block, serial, bluetooth, video4linux, etc.), it should probably be implemented in-kernel. - on the other hand, if the driver doesn't use an existing kernel interface and creates a new user-visible interface that is going to be used by a single userspace application, it should probably be done in userspace. - if it is going to be used by several applications it could still be implemented as a library, but it starts moving into the gray area. - performance might be a reason to move to kernel space, but I don't think it matters for transfer rates below 10Mbytes/sec or so. Anyway, this is just MHO, so feel free to discuss this further. I'm simply volunteering to sum up this thread into a patch to add a Documentation/usb/userspace_drivers.txt (or something like that), so that we can help future developers decide where to write their drivers. -- Paulo Marques - www.grupopie.com "Very funny Scotty. Now beam up my clothes." - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usblp not waiting for read data
On Wed, 2 Jan 2008 15:25:11 +0100, Martin Mares <[EMAIL PROTECTED]> wrote:
> | open("/dev/usb/lp0", O_RDONLY|O_LARGEFILE) = 3
> | fstat64(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(180, 0), ...}) = 0
> | read(3, "", 4096) = 0
> | close(3)= 0
Figures...
> albireo:/sys/kernel/debug/usbmon# cat 1u
> # (ran cat for the first time)
> ddbeb7c0 1940101507 S Bi:1:003:1 -115 1024 <
> ddbeb7c0 1940101645 C Bi:1:003:1 0 0
This is where your zero length comes from: printer returns zero bytes.
> ddbeb7c0 1940101675 S Bi:1:003:1 -115 1024 <
> ddbeb7c0 1940101766 C Bi:1:003:1 -2 0
This is an unlink on close, but it's interesting that either printer is
not fast enough to send another zero data reply or it begins NAK-ing for
the second time around.
I checked the old driver, it does not seem to retry either and should
return EOF happily too. Although it should not make any difference in
view of the trace above, is there a box with something like 2.6.21 to try?
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
On Wednesday 02 January 2008, Alan Stern wrote: > BTW, I don't recall ever seeing Tony's patch announced on > linux-usb or linux-usb-devel. Did I simply miss it? I think he didn't post it. I got some questions from him at one point, which I answered, but as I recall he decided for some reason to stop that work. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [Bug 8094] ipaq oops on connecting "Vodafone VPA-II"
On Wednesday 02 January 2008, Oliver Neukum wrote: > Hi, > > it looks like this RNDIS derived devices really needs jumbo frames. > What is to be done? I'm not sure there's a realistic expectation that 16 KBytes can regularly be allocated through the network stack ... and I'm fairly sure the rndis_host code won't actually unbundle all the Ethernet packets that would be bundled into such a huge buffer! I'd like to see some developer in Europe (i.e. one who can benefit from the EU interop agreements with MSFT) get the documentation on ActiveSync, to see exactly what it's supposed to be doing. It's clear that it doesn't conform to the (incomplete/inaccurate) RNDIS specs, but there should be more information in the ActiveSync docs. > http://bugzilla.kernel.org/show_bug.cgi?id=8094 > > --- Comment #32 from [EMAIL PROTECTED] 2008-01-01 16:34 --- > Today i tested now. > > this patch helped me :-) > http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/linux-2.6.22-rndis_host-wm5.patch That is: > --- linux-2.6.22-rc3-orig/drivers/net/usb/rndis_host.c2007-05-25 > 22:55:14.0 -0400 +++ > linux-2.6.22-rc3/drivers/net/usb/rndis_host.c 2007-05-27 17:06:16.0 > -0400 @@ -499,8 +499,7 @@ > net->hard_header_len += sizeof (struct rndis_data_hdr); > dev->hard_mtu = net->mtu + net->hard_header_len; > > - dev->rx_urb_size = dev->hard_mtu + (dev->maxpacket + 1); > - dev->rx_urb_size &= ~(dev->maxpacket - 1); > + dev->rx_urb_size = (dev->udev->speed == USB_SPEED_FULL) ? 16384 : 8192; > u.init->max_transfer_size = cpu_to_le32(dev->rx_urb_size); > > net->change_mtu = NULL; Looks broken in more ways than just assuming huge packets can be sent/received. High speed devices need less buffering than full speed ones??? - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Tue, 1 Jan 2008, Greg KH wrote: > For most cases, yes, I agree with this, but due to the lockdep issues > that occur here, and the whole mess with the suspend path and locking > the device tree, that has been hashed out many times in the past, I am > interested in trying to see if there is any real reason why this is > absolutely necessary to convert. > > If no one has noticed any issues in this area, I think the complexity > that will be involved in any such conversion will strongly outweigh any > simplicity that might be expected. > > I'm very open to potential patches to do this, just don't ignore the > issues that others have run into in the past when attempting this. There are two separate things to consider here. One is struct device and the other is struct class. We know that replacing semaphores with mutexes in struct device doesn't sit well with lockdep. However the replacement may work perfectly smoothly for struct class. It would be worthwhile for Dave Young to separate out just that part and try it. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Wed, 2 Jan 2008, Dave Young wrote: > > Around a month ago I had a discussion with Peter Zijlstra about the > > problems in converting the device semaphores to mutexes; you may be > > able to find it in the LKML archives. Doing the conversion while > > keeping lockdep happy is a very hard problem and we were not able to > > solve it. > > > > It's unfortunate to know this, I will search and read your thread. Here's a pointer to that thread: http://marc.info/?t=11941194222&r=1&w=2 Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb regression] Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
On Tue, 1 Jan 2008, Greg KH wrote: > On Mon, Dec 31, 2007 at 11:26:43AM -0800, Greg KH wrote: > > On Mon, Dec 31, 2007 at 12:49:52PM -0500, Alan Stern wrote: > > > On Sun, 30 Dec 2007, Greg KH wrote: > > > > > > > > It looks like Greg misused the debugfs API -- which is ironic, because > > > > > he wrote debugfs in the first place! :-) > Ok, no, I didn't write that patch, I'm getting very confused here. > > In 2.6.24-rc6 there is no usage of debugfs in the ohci driver. > > In the -mm tree there is a patch, from Tony Jones, that moves some debug > code out of sysfs and into debugfs where it belongs. It does it for > both the ehci and ohci USB host controller drivers, and this is the code > that is incorrect if CONFIG_DEBUGFS is not enabled. My mistake; I got the impression you had written that new code rather than Tony. BTW, I don't recall ever seeing Tony's patch announced on linux-usb or linux-usb-devel. Did I simply miss it? > So, for the 2.6.24 release, nothing needs to be changed, all is good, > and there is no regression. > > Right? Or am I still confused about this whole thing? Correct. The problem exists only in -mm and your development tree. > I will go fix up Tony's patches in the -mm tree that do not handle the > error return values from debugfs properly, but that is not such a rush, > as Tony is on vacation for a few weeks, and those patches are going to > be going in only after 2.6.24 is out. The fix I posted earlier in this thread should simply be merged into Tony's patches. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SD card reader problem
On Tue, 1 Jan 2008, Matthew Dharm wrote: > > You need to do a low-level format of the card. Delete and then > > recreate the first partition. And then of course you'll have to > > recreate the VFAT filesystem on it. > > That will work, but I don't think it's optimal. > > Looking at the logs provided, I think this might be one of those devices > that doesn't like reading the last sector if it's part of a multi-sector > request. > > Didn't we add a new flag type recently to cope with this condition? There was a proposal for it. It was quite hacky, involving changes at the usb-storage level for things that should have been set up differently to begin with at the sd_mod level. IIRC the proposal was never accepted. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usblp not waiting for read data
Hello!
> You aren't opening it with O_NDELAY by any chance?
Hopefully not :) Even plain cat exhibits the problem.
> Please look with strace.
| albireo:/home/mj# strace cat /dev/usb/lp0
| execve("/bin/cat", ["cat", "/dev/usb/lp0"], [/* 34 vars */]) = 0
| uname({sys="Linux", node="albireo", ...}) = 0
| brk(0) = 0x804d000
| access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
| mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7fbb000
| access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
| open("/etc/ld.so.cache", O_RDONLY) = 3
| fstat64(3, {st_mode=S_IFREG|0644, st_size=97571, ...}) = 0
| mmap2(NULL, 97571, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fa3000
| close(3)= 0
| access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
| open("/lib/tls/libc.so.6", O_RDONLY)= 3
| read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1"..., 512) =
512
| fstat64(3, {st_mode=S_IFREG|0644, st_size=1245488, ...}) = 0
| mmap2(NULL, 1251484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7e71000
| mmap2(0xb7f99000, 28672, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x128) = 0xb7f99000
| mmap2(0xb7fa, 10396, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fa
| close(3)= 0
| mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7e7
| mprotect(0xb7f99000, 20480, PROT_READ) = 0
| set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e708e0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
| munmap(0xb7fa3000, 97571) = 0
| brk(0) = 0x804d000
| brk(0x806e000) = 0x806e000
| open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
| fstat64(3, {st_mode=S_IFREG|0644, st_size=1673120, ...}) = 0
| mmap2(NULL, 1673120, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7cd7000
| close(3)= 0
| fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
| open("/dev/usb/lp0", O_RDONLY|O_LARGEFILE) = 3
| fstat64(3, {st_mode=S_IFCHR|0660, st_rdev=makedev(180, 0), ...}) = 0
| read(3, "", 4096) = 0
| close(3)= 0
| close(1)= 0
| exit_group(0) = ?
| Process 4888 detached
> If that looks ok, a usbmon trace would be helpful.
> Please send me both traces.
albireo:/sys/kernel/debug/usbmon# cat 1u
# (ran cat for the first time)
ddbeb7c0 1940101507 S Bi:1:003:1 -115 1024 <
ddbeb7c0 1940101645 C Bi:1:003:1 0 0
ddbeb7c0 1940101675 S Bi:1:003:1 -115 1024 <
ddbeb7c0 1940101766 C Bi:1:003:1 -2 0
# (2nd time)
ddbebec0 1943391766 S Bi:1:003:1 -115 1024 <
ddbebec0 1943391838 C Bi:1:003:1 0 0
ddbebec0 1943391881 S Bi:1:003:1 -115 1024 <
ddbebec0 1943391959 C Bi:1:003:1 -2 0
Have a nice fortnight
--
Martin `MJ' Mares <[EMAIL PROTECTED]>
http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Maintenance-free: When it breaks, it can't be fixed...
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH 0/3] ehci-hcd: complete iso urbs sooner, take 5
Am Mittwoch, 2. Januar 2008 schrieb David Brownell: > On Tuesday 01 January 2008, Karsten Wiese wrote: > > How about: > > Urbs stopping/starting at (uFrame % 8) != 0 can share ITDs, > > If there's a problem in that area, it should get fixed in a > patch just addressing that issue. Did you mention such an > issue before? Don't know. Its a feature to let n ITD's suffice, where currently n + 1 are used. I.e. streaming urbs with nr_of_packets=22. It might make things easier for the ehci-silicon too: Only 1 ITD to look at for a given pipe and frame. > > > > The finishing urb doesn't recycle its last ITD, instead the starting urb > > takes care of that. > > Also a different issue. The patch I posted to defer the recycling > on URB completion paths suffices, Not I think. I don't mean its wrong, there's 1 thing missing though, see below. > given the assumptions that only > completions will add to the schedule and that drivers aren't doing > silly stuff like more than two URBs per frame (for a given endpoint). > > > > IIRC it was also necessary to never change a running (USB1.1) frame's > > hardware schedule... > > A frame is a frame is a frame; USB 2.0 didn't change that! > > Again, not an issue given those assumptions. Disagree: with your patches ITDs can still be removed from ehci's hardware schedule, while a frame is active, no? In scan_periodic()'s case Q_TYPE_ITD: those lines: *q_p = q.itd->itd_next; *hw_p = q.itd->hw_next; IMO should only execute once the frame has elapsed. > > > > I've once succesfully tested this scheme. > > It made ITD (de)scheduling a bit more complex. > > Good is it needs less memory and DMA bandwith. > > It's not clear to me what you mean by these comments. I meant: "It worked fine here some month ago streaming iso urbs containing odd nr_of_packets" + some course cost/benefit analysis. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [Bug 8094] ipaq oops on connecting "Vodafone VPA-II"
Hi, it looks like this RNDIS derived devices really needs jumbo frames. What is to be done? Regards Oliver -- Weitergeleitete Nachricht -- Betreff: [Bug 8094] ipaq oops on connecting "Vodafone VPA-II" Datum: Mittwoch 02 Januar 2008 Von: [EMAIL PROTECTED] An: [EMAIL PROTECTED] http://bugzilla.kernel.org/show_bug.cgi?id=8094 --- Comment #32 from [EMAIL PROTECTED] 2008-01-01 16:34 --- Today i tested now. this patch helped me :-) http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/linux-2.6.22-rndis_host-wm5.patch it works now ! for me is the bug closed. thanks. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- http://bugzilla.kernel.org/show_bug.cgi?id=8094 --- Comment #32 from [EMAIL PROTECTED] 2008-01-01 16:34 --- Today i tested now. this patch helped me :-) http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/linux-2.6.22-rndis_host-wm5.patch it works now ! for me is the bug closed. thanks. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On Wed, Jan 02, 2008 at 01:39:38PM +0100, Jarek Poplawski wrote: > On 02-01-2008 08:00, Greg KH wrote: > ... > > If no one has noticed any issues in this area, [...] BTW, if 'we' are sure there are no issues, and only lockdep is not clever enough yet, why not do such a change partially, e.g. with lockdep_on/off, at least to -mm, for testing? Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] Use mutex instead of semaphore in driver core
On 02-01-2008 08:00, Greg KH wrote: ... > If no one has noticed any issues in this area, [...] ...Could also mean there are hidden issues, so it doesn't look like very convincing argument. ...Unless after the change there will be found no hidden issues, then, of course, it looks like convincing enough. Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
