On Wed, 25 Aug 2004 22:10:29 -0400
Jason Scott Musits <[EMAIL PROTECTED]> wrote:
> Aug 25 21:54:49 particle usb-storage: GetMaxLUN command result is 0, data is 0
I thought Alan Stern sent a patch for it just yesterday.
Although it's curious that it worked in 2.4 somehow.
-- Pete
--
I recently made the jump from the 2.4 kernel tree to the 2.6 and I am
having a problem with my HP Photo Scanner 1000. In the 2.4.x kernels it
was recognized as a usb mass storage device and was bound to /dev/sdX
which I could then mount and get the scan off of. In kernel 2.6.8.1
/dev/sdX never ge
Hello,
On Wednesday 25 August 2004 01:04, Greg KH wrote:
> On Wed, Aug 25, 2004 at 12:58:24AM +0200, Nemosoft Unv. wrote:
> If you want to send me a patch to tell me to rip the whole driver out,
> fine I will, no problems, I completly understand.
I don't think you do.
> But realize that anyone c
Francesco,
A saw your post that you have a fix for ISO transfers with the otg243
drivers. I have a project that requires a USB headset connected to a
cerfcube. I need to get a demo put together quickly but audio record
does not work and I suspect that it may be the ISO transfer problem you
menti
On Wed, 25 Aug 2004, Victor wrote:
> >What does /proc/scsi/scsi show when the drive is plugged in?
> >
> Thanks for your prompt reply
> /proc/scsi/scsi displays
> Attached devices:
> and nothing more while lsmod shows:
Are you sure that's with the drive plugged in? There should be an entry
for
On Wed, 25 Aug 2004, Victor wrote:
> Please help.
> I attached my HDD enclosure to my usb port and dmesg desplayed:
>
> usb 1-1: new full speed USB device using address 4
> scsi2 : SCSI emulation for USB Mass Storage devices
> scsi scan: 37 byte inquiry failed with code 458752. Consider
> BLIST_
Please help.
I attached my HDD enclosure to my usb port and dmesg desplayed:
usb 1-1: new full speed USB device using address 4
scsi2 : SCSI emulation for USB Mass Storage devices
scsi scan: 37 byte inquiry failed with code 458752. Consider
BLIST_INQUIRY_36 for this device
WARNING: USB Mass Storag
On Wednesday 25 August 2004 10:27 am, Greg KH wrote:
> > But until seq_file works over sysfs, I'd rather see this
> > sort of thing stick to the "/proc/driver/udc" convention.
>
> Hm, ok. But I'd really like it to be a "DEBUG" option, as that's what
> it really is.
You mean a Kconfig flag like
Hi,
sorry I must say I messed up two things in my last mail:
1. The debug messages I wrote are not from the Tango Version, but from
isp1161 USB HCD for Linux Version 0.9.5 (10/28/2001)
But it was reported to me that the Tango driver doesn't work either.
2. My vocabulary was messed up for a moment:
On Wed, Aug 25, 2004 at 10:37:20AM -0400, Alan Stern wrote:
> On Tue, 24 Aug 2004, Greg KH wrote:
>
> > Hm, I'm going to hold off on this patch (and the other 3 patches you
> > just send me) for a week or so, if you don't mind. They will stay in my
> > queue, and I'll apply them after I get the n
Quoting "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> Ouch. That explains things. Cat hung after some time, and I got
>
> gs_flush_chars: NULL port pointer
> gs_recv_packet: port=0, bad tty magic
>
> Messages at some point. g_serial hung after that. Reconnect solved that.
That does not look like a
I will build a 2.6.5 kernel tomorrow and perform the tests you
described.
-RLU
Alan Stern wrote:
> On Wed, 25 Aug 2004, Robert Urban wrote:
>
> >
> > Hi Alan,
> >
> > Alan Stern wrote:
> > > In short, everything is working as it should, except for your EHCI
> > > controller. You may need to
On Wed, Jul 14, 2004 at 02:59:20PM -0400, Alan Stern wrote:
> Greg:
>
> This patch adds some simple cleanups that are missing for one of the error
> case in usb_register_root_hub(). I would be very surprised if this code
> ever gets executed, but we might as well be correct.
>
> Please apply.
A
On Wed, Jul 14, 2004 at 02:55:23PM -0400, Alan Stern wrote:
> Greg:
>
> This patch changes the size of the buffer allocated for each hub's status
> URB from 3 bytes to 8. The purpose is to avoid "babble" errors with
> certain buggy hubs. Although I only know of one type of device which does
>
On Tue, Aug 24, 2004 at 05:02:24PM -0700, David Brownell wrote:
> On Tuesday 24 August 2004 4:38 pm, Greg KH wrote:
> > On Tue, Aug 24, 2004 at 04:05:17PM -0700, David Brownell wrote:
> > > +#ifdef UDC_PROC_FILE
> > > +
> > > +static const char proc_node_name[] = "driver/udc";
> >
> > Ick. Please
On Tue, Aug 24, 2004 at 04:52:27PM -0700, David Brownell wrote:
> Add this over the other two OMAP patches you got from me today,
> and that'll wrap up this first OTG implementation!
>
> Some non-USB portions are needed to actually use this, like the
> I2C support in the linux-omap bkbits tree ...
On Wed, 25 Aug 2004, David Brownell wrote:
> When to power back up is an interesting issue, and it sounded
> like you had a procedure in mind that could handle that well
> in certain common cases.
I didn't. But having khubd do it during the logical disconnect processing
seems like the logical c
On Wed, 25 Aug 2004, Robert Urban wrote:
>
> Hi Alan,
>
> Alan Stern wrote:
> > In short, everything is working as it should, except for your EHCI
> > controller. You may need to get a replacement for it.
>
> Do you mean the driver or the hardware?
Could be either one. Although if the hardw
Hi Alan,
Alan Stern wrote:
> In short, everything is working as it should, except for your EHCI
> controller. You may need to get a replacement for it.
Do you mean the driver or the hardware?
It seems to me significant that the external disk (OneTouch) was
working fine under 2.6.5, however, o
On Wed, Aug 25, 2004 at 11:57:02AM -0400, Kyle Harris wrote:
> On Wednesday 25 August 2004 02:55 am, Greg KH wrote:
> >> How does this work for your device? Your driver isn't the
> > usb_serial_generic_device, right? What kernel version are you using?
>
> Yes, usb_serial_generic_device. I had re
On Wed, 25 Aug 2004, Robert Urban wrote:
> Hi Alan,
>
> please see:
>
> http://www.unix-wissen.de/usb/
>
> for the debugging information you requested. The excerpt for the
> external drive, "kernel.onetouch.gz" is rather large, which is why
> it's compressed. I didn't want to trim possi
On Wednesday 25 August 2004 8:38 am, Alan Stern wrote:
> On Tue, 24 Aug 2004, David Brownell wrote:
>
> > > +/*
> > > + * Disable a port and mark a logical connnect-change event, so that
some
> > > + * time later khubd will disconnect() any existing usb_device on the
port
> > > + * and will re-e
On Wednesday 25 August 2004 02:55 am, Greg KH wrote:
>> How does this work for your device? Your driver isn't the
> usb_serial_generic_device, right? What kernel version are you using?
Yes, usb_serial_generic_device. I had rebuilt the kernel with usb_serial hard
linked and forgot that hotplug w
On Tue, 24 Aug 2004, David Brownell wrote:
> > +/*
> > + * Disable a port and mark a logical connnect-change event, so that some
> > + * time later khubd will disconnect() any existing usb_device on the port
> > + * and will re-enumerate if there actually is a device attached.
> > + */
>
> What w
On Wed, Aug 25, 2004 at 10:44:47AM -0400, Alan Stern wrote:
> The real question is: Is there sufficient demand for these timers outside
> of usb_control/bulk_msg() to make it worth the effort of supporting them?
I don't think so. But then again, I've never had to write a driver that
needs this
On Wed, 25 Aug 2004, Laurent Pinchart wrote:
> Hi everybody,
>
> I'm trying to debug a userspace device driver (ACR30U Smart Card Reader) which
> uses "simple" control transfers to send data to the device, and an input bulk
> endpoint to read the response.
>
> An error occurs when sending the
On Wed, 25 Aug 2004, Oliver Neukum wrote:
> > > You can still take a lengthy irq or system management call in between.
> > > Depending on this never be the case is very dangerous.
> >
> > I can take it after the return from the repositioned add_timer as well.
> > This is why I said that although
On Wed, 25 Aug 2004, Oliver Neukum wrote:
> Am Dienstag, 24. August 2004 23:18 schrieb Alan Stern:
> > On Tue, 24 Aug 2004, Oliver Neukum wrote:
> >
> > > Where would you put the struct timer? Into the URB?
> >
> > No, it would have to go in a separately allocated block. The problem, of
> > cou
On Tue, 24 Aug 2004, Greg KH wrote:
> Hm, I'm going to hold off on this patch (and the other 3 patches you
> just send me) for a week or so, if you don't mind. They will stay in my
> queue, and I'll apply them after I get the next round of usb bugfixes
> out to Linus.
>
> I want these patches to
Nemosoft Unv. wrote:
Actually, I've got a little surprise for you. The NDA I signed with Philips
has already expired a year ago. Yet, I didn't just throw the decompressor
code on the Internet. First, there could still be legal remedies since the
cams are still in production to this very day. Sec
Hi,
Is anyone [successfully] using an ISP116x or ISP1362?
Which kernel are you using?
Yes, we use a ISP116x on a SuperH platform running under 2.4.22 and it
works.
A snapshot can be found at:
http://www.bennee.com/~alex/software/kernel/index.php
Its based on some old code that we hacked up to run o
On Fri, 20 Aug 2004, Guennadi Liakhovetski wrote:
> As for our problem, there's no IOMMU of course, and the only buffers I
> know of are post-write buffers on the PCI controller, and I do flush
> them... So, do you think there's still some (possibly undocumented)
> inconsistent buffering / caching
Am Mittwoch, 25. August 2004 05:04 schrieb Phil Dibowitz:
> Hmmm, I saw that comment by Linus, and I am obviously by no means as
> emersed in kernel development as ... well, either of you ... but I took
> Linus' comment to mean more that the kernel will not be changed to work
> around odd behavi
On Wed, Aug 18, 2004 at 10:56:09PM -0400, Kyle Harris wrote:
> Hi,
>
> I'm trying to make this work. The driver only creates mulitple ports if there
> are multiple bulk_out endpoints. My device has 2 bulk_in and one bulk_out.
> So I made the following change:
>
> #ifdef CONFIG_USB_SERIAL_GENE
34 matches
Mail list logo
