On Mon, 14 Jan 2013 12:23:05 -0800
Greg KH wrote:
> >Forgot to mention the side effect of the patch: one can't submit read and
> > write URB simultaneously via USBDEVFS_BULK ioctl(). That has been dealt in
> > 2.4
> > by later patch by Pete, which I can try to port if needed.
>
> That's not
On Fri, 18 Jan 2013 11:59:45 -0800
Greg KH wrote:
> >Don't forget that the same code is working in 2.4 for several years.
>
> In mainline? Or some random vendor-specific kernel branch where we have
> no visiblity into? :)
Yes, it's in mainline since 2006. However, I am in full agreement w
On Sun, 26 Aug 2012 14:12:17 -0700
Greg Kroah-Hartman wrote:
> > Unless you have other plans, I would take this and send it you together
> > with the
> > removal of libusual as you asked.
>
> Why not just send a follow-on patch to do the libusual fixups instead?
Sending it in one go seems more
On Thu, 11 Jul 2013 17:05:26 +0800
Ming Lei wrote:
> Complete() will be run with interrupt enabled, so change to
> spin_lock_irqsave().
>
> Cc: Pete Zaitcev
> Signed-off-by: Ming Lei
Signed-off-by: Pete Zaitcev
Good luck with that, Ming. I think the spin_lock_irqsave thing
On Sun, 18 Aug 2013 00:24:30 +0800
Ming Lei wrote:
> Complete() will be run with interrupt enabled, so change to
> spin_lock_irqsave().
>
> Signed-off-by: Pete Zaitcev
> Signed-off-by: Ming Lei
Still looks good.
-- P
--
To unsubscribe from this list: send the line "unsub
use the storage, looks like a winner. Unfortunately, it leaves ub for dead,
because ub cannot invoke the necessary initializer unless we move it to
libusual. But oh well, I'll think about it.
Took me this long to test because I had to ask kind people in England
to replug the modem.
Signed-off
On Wed, 5 Dec 2007 19:23:14 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 5. Dezember 2007 17:34:23 schrieb Pete Zaitcev:
> > Looks good to me, shorter than my patch, has no duplication, allows to
> > use the storage, looks like a winner. Unfortunately,
On Wed, 5 Dec 2007 16:35:26 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> Host controller IRQs are supposed to be serviced with interrupts
> disabled. This patch (as1025) adds an IRQF_DISABLED flag to all the
> controller drivers that lack it.
OK, if you prefer to use a crew-fired weapon
On Wed, 5 Dec 2007 10:15:44 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9335
>
> The problem appears to be that ohci-hcd (and also ehci-hcd) calls
> spin_lock() in its IRQ handler instead of spin_lock_irqsave(). A
> deadlock occurs becaus
On Wed, 5 Dec 2007 17:31:20 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> [...] In fact every HCD _must_ keep interrupts disabled
> while doing most of its IRQ processing. This is because an interrupt
> could cause some random driver to submit an URB -- and URB submission
> can't be don
On Tue, 18 Dec 2007 16:27:28 +, "Brian Murphy" <[EMAIL PROTECTED]> wrote:
> sda:<6>usb 1-2: reset full speed USB device using uhci_hcd and address 8
> usb 1-2: device descriptor read/64, error -84
Try to insert a self-powered hub.
-- Pete
-
To unsubscribe from this list: send the line "unsu
On Thu, 20 Dec 2007 21:59:52 +0100, Matthias Schniedermeyer <[EMAIL PROTECTED]>
wrote:
> With every 3 of this hubs i just successfully copied 7GB of data with no
> errors.
I'm very glad.
> So i will throw >dozen of the faulty hubs into the box where i collect
> my e-waste.
What's the chipset
On Fri, 21 Dec 2007 10:50:06 +, "Brian Murphy" <[EMAIL PROTECTED]> wrote:
> I just discover some thing, If I ouput the trace to
> a serial port the system works fine. However If I output the trace to
> the disk I have the same problem as before. [...]
I think your device is asking for US_FL_G
On Sat, 29 Dec 2007 22:15:21 +0100, Martin Mares <[EMAIL PROTECTED]> wrote:
> I am currently playing with HP LaserJet P2015D connected over USB and
> I have a slight problem with the usblp driver there. Whenever I try to
> read from /dev/usb/lp0 and no data are available, it immediately returns
>
On Sun, 30 Dec 2007 22:48:39 +, "Brian Murphy" <[EMAIL PROTECTED]> wrote:
> I install Win XP on the system and the drive works fine.
Great. I hope it was a dual-boot setup.
> Is there any way I can modifie the driver so I see the same result as
> when I put the debug output to the serial por
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
Fi
The ISO descriptors are allocated separately in proc_submiturb for a fetch
from user mode, then tucked at the end of URB. This seems like a dead code.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 1f4f6d0..d51980a
On Mon, 7 Jan 2008 15:51:39 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> I am using my usb flash stick as a swap space. If I use a few hundred mb
> I get a hang in about 30% of the tests. Can anybody replicate this result?
Does ub work? :-)
Seriously though, it's a long-standing problem. So
On Mon, 7 Jan 2008 21:51:18 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> I must admit that testing ub didn't occur to me. I will do so tomorrow. Ub
> does not use a kernel thread, does it?
I used to harp on the thread but I really shouldn't have. It is a part
of the story, the other part is
On Mon, 7 Jan 2008 16:36:56 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> I'm afraid I'm out of good ideas. You can try playing around with the
> code in drivers/usb/storage/transport.c, adding delays here and there
> to see if they make any difference.
Sorry for repeating this, but usbmo
On Tue, 08 Jan 2008 18:56:03 -0500, Sean Darcy <[EMAIL PROTECTED]> wrote:
> head -20 /tmp/1.mon.out
> 810037f38d80 3045534577 S Ii:2:001:1 -115:128 2 <
> 81000fe64cc0 3045534596 S Ci:2:001:0 s a3 00 0001 0004 4 <
20 lines is never sufficient with usbmon. It's more like 20 thousand.
On Fri, 18 Jan 2008 19:03:15 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> That's why I was somewhat suspicious that the disconnects are being
> caused by software. What happens if the scheduler doesn't have the
> data ready in time? Could it cause the reset I am seeing?
Since all three go toge
On Fri, 18 Jan 2008 16:25:51 -0500, "Jon Smirl" <[EMAIL PROTECTED]> wrote:
> I guess I have to buy another hub. The USB 2.0 hubs I have aren't
> multi-tt and don't work right with the audio devices.
I would rather think about adding a USB bus or two. The thought of
three isochronous devices on th
Hi, Greg:
I think the berry_charge is your baby. Please direct me to the
right person if it's not so.
I have a bug in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=379341
It's pretty long, but the summary is this. When Blackberry is hooked
to a hub, it seems to try to re-initialize again
On Mon, 28 Jan 2008 14:15:23 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
>[...]
> I just tried it again, and it did the same thing, resetting like you
> describe, until it resets itself and then the device dies, Linux works
> just fine.
Thanks for trying this for me. The important thing is that you
On Fri, 1 Feb 2008 11:59:56 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> You missed the point. Windows does _not_ do it -- i.e., does not clear
> a halt on either bulk endpoint. Linux does so only because somebody
> (either Pete Zaitcev or Pat Lavarre, I can't rem
On Fri, 1 Feb 2008 11:54:12 -0800, Matthew Dharm <[EMAIL PROTECTED]> wrote:
> There's no way to know until Robert tests with no clear-halt at all.
Which is very easy to do: enable ub, run usbmon... voila.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body
On Mon, 04 Feb 2008 08:30:37 -0800, Alan Nisota <[EMAIL PROTECTED]> wrote:
> [...] If I do
> this using blocking reads, the device never sends any data back It
> appears to be waiting for multiple bulk request URBS in the queue. This
> apparently eliminates my ability to use libusb, so now I
On Mon, 04 Feb 2008 14:01:21 -0800, Alan Nisota <[EMAIL PROTECTED]> wrote:
> > This implies that endpoint 0x82 is a bulk endpoint. So what type is
> > it really?
> It's identified as bulk.
If would be really nice if you sent us your /proc/bus/usb/devices
to begin with, but if 82 is indeed a bu
On Tue, 5 Feb 2008 11:17:46 -0800 (PST), Siddharth Choudhuri <[EMAIL
PROTECTED]> wrote:
> - Linux 2.6.19 on ARM
> The problem is, I see the following in /tmp/log (no data words):
> c04087dc 57025 C Bo:002:02 0 31 >
> c000ec14 57209 S Bo:002:02 -115 512
On Tue, 5 Feb 2008 14:05:06 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Looks like you deadlocked in ub_request_fn(). I assume that you were using
> ub.c in 2.6.23 and that it worked OK? If so, we broke it, possibly via
> changes to the core block layer.
>
> I think ub.c is basically aban
On Tue, 5 Feb 2008 17:02:58 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> In such cases the page number is stored in a scatter-gather entry.
> Should we modify the core to keep a copy of the page number in the URB,
> for use by mon_dmapeek()?
If you ask me, I'd say that rules of what is
On Tue, 05 Feb 2008 18:32:35 -0800, Alan Nisota <[EMAIL PROTECTED]> wrote:
> Well, this hack allows me to read without babble on my newer machines,
> but the one I really need it to work on has an older motherboard, and
> refuses to accept the 1024 byte packets. I'll need to either work iwth
>
t's just Tomo or Jens made a mistake when converting to
the new s/g API. Nothing to be too concerned about. I know I should've
reviewed their patch closer, but it seemed too simple...
-- Pete
Fix up the conversion to sg_init_table().
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED
On Tue, 12 Feb 2008 10:46:12 +0900, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On a serious note, it seems that two scatter lists per request leaded
> to this bug. Can the scatter list in struct ub_request be removed?
Good question. It's an eyesore to be sure. The duplication exists
for the sak
On Tue, 12 Feb 2008 19:08:30 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
> if (handle_bidir(usblp) < 0) {
> + usb_autopm_put_interface(intf);
> usblp->used = 0;
Signed-Off-By:
On Wed, 13 Feb 2008 13:31:54 -0600, Andrew McKay <[EMAIL PROTECTED]> wrote:
>spin_lock_bh(&port->lock);
>if (port->write_urb_busy) {
If you lock against callbacks and do not trigger tasklets yourself,
you must use spin_lock_irqsave (or spin_lock_irq if you are belong
to Oliver's denominat
On Wed, 13 Feb 2008 15:53:48 -0600, Andrew McKay <[EMAIL PROTECTED]> wrote:
> Once the callback function has been called does this guarantee that the URB
> has already been sent to hardware?
Yes (if the returned status was zero).
> I'll definitely look into this usbmon app. I have timed thi
On Fri, 16 Nov 2007 14:22:56 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:
> > > The difference with huaweiAktBbo.c seems that kernel uses a nonzero
> > > length.
> > > Can you try zero length with the kernel? It's the second argument to the
> > > last.
> >
> > I tried with the git patch p
On Fri, 15 Feb 2008 09:38:14 +0100, "Paolo Abeni" <[EMAIL PROTECTED]> wrote:
> I'm again playing with usbmon and I think it would be useful, at least
> for testing purpose, being able to compile the usbmon device code as an
> external module. []
This can easily be accomplished by building USB cor
On Wed, 20 Feb 2008 07:57:23 +0100, Norbert Preining <[EMAIL PROTECTED]> wrote:
> > that you did, after taking care of detection and initialization.
> > Look at his dmesg in comment #44 in this:
>
> Yes, that looks very similar.
Someone reported on the bug that a firmware update exists to resolv
On Fri, 19 Jun 2015 11:37:08 +0200
Krzysztof Opasiak wrote:
> Kernel provides very nice defines for USB device class
> so it's a good idea to use them in suitable places.
> It is much easier to grep for such define instead of 7.
> static const struct usb_device_id usblp_ids[] = {
> - { USB_
hat mutex_lock_interruptible()
can set the state, or it didn't do it back then (it was in 2007), and
the 7f477358e introduced the existing code.
Acked-By: Pete Zaitcev
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 6 Aug 2019 16:44:55 +0200
Greg Kroah-Hartman wrote:
> Cc: Pete Zaitcev
> Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Pete Zaitcev
Always hated that irregular error unrolling, but was too lazy to fix it.
-- Pete
On Tue, 29 May 2018 17:30:50 +0200
Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Okay, fair enough. And the code works, surprisi
On Fri, 29 Dec 2017 16:24:20 +0300
"Kirill A. Shutemov" wrote:
> Looks like MON_IOCT_RING_SIZE reallocates ring buffer without any
> serialization wrt mon_bin_vma_fault(). By the time of get_page() the page
> may be freed.
Okay. Who knew that you could fork while holding an open descriptor. :-)
On Wed, 3 Jan 2018 12:26:04 +0300
"Kirill A. Shutemov" wrote:
> > > +++ b/drivers/usb/mon/mon_bin.c
> > > @@ -1228,15 +1228,24 @@ static void mon_bin_vma_close(struct
> > > vm_area_struct *vma)
> > > static int mon_bin_vma_fault(struct vm_fault *vmf)
> > > {
> > > struct mon_reader_bin *rp =
On Wed, 3 Jan 2018 13:08:12 -0800
Matthew Wilcox wrote:
> > + mutex_lock(&rp->fetch_lock);
> > offset = vmf->pgoff << PAGE_SHIFT;
> > if (offset >= rp->b_size)
> > + mutex_unlock(&rp->fetch_lock);
> > return VM_FAULT_SIGBUS;
> > chunk_idx = offset / CHUNK_SIZE;
On Fri, 29 Dec 2017 16:24:20 +0300
"Kirill A. Shutemov" wrote:
> Looks like MON_IOCT_RING_SIZE reallocates ring buffer without any
> serialization wrt mon_bin_vma_fault(). By the time of get_page() the page
> may be freed.
As an update: I tried to make a smaller test for this, but was unsuccessf
lock fixes it. That said, your test
suite may be more comprehensive, or you may have a device that
generates enough USB traffic with associated monitoring callbacks.
But I don't see it.
At this point, I'm going to post the patch with a Signed-Off-By.
-- Pete
(this reproduces very quick
Automated tests triggered this by opening usbmon and accessing the
mmap while simultaneously resizing the buffers. This bug was with
us since 2006, because typically applications only size the buffers
once and thus avoid racing. Reported by Kirill A. Shutemov.
Signed-off-by: Pete Zaitcev
.
Now, you have to know the foo_show convention. But if you think
it's worth being a bit more explicit about "this is intended to
be a RO attribute", then okay.
Acked-by: Pete Zaitcev
-- P
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
This change fixes buffer overflows and silent data corruption with the
usbmon device driver text file read operations.
Signed-off-by: Fredrik Noring
Signed-off-by: Pete Zaitcev
---
diff --git a/drivers/usb/mon/mon_text.c b/drivers/usb/mon/mon_text.c
index f5e1bb5e5217..984f7e12a6a5 100644
_struct *tty,
> divisor = mct_u232_calculate_baud_rate(serial, value, &speed);
> - put_unaligned_le32(cpu_to_le32(divisor), buf);
> + put_unaligned_le32(divisor, buf);
> rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
Acked-By: Pete Zaitcev
-
sblp->lock, flags);
Code is correct, addresses the stated problem, no forgotten parts
found left to fix.
Acked-by: Pete Zaitcev
-- P
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
55 matches
Mail list logo
