On Tue, 13 Jan 2004, Loic Jaquemet wrote:
> Hello,
>
> I've bought a Philips-Nike psa128max, which is a 128 Mo mp3 player, with
> firmware update capacity.
>
> Briefly : It doesn't work. ( ~2.4.20 to 2.6.1 )
What is it supposed to do? Is it supposed to function like a USB disk
drive, so you
Le Tue, 13 Jan 2004 17:23:11 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> a écrit:
> On Tue, 13 Jan 2004, Loic Jaquemet wrote:
>
> > actually , there is a similar device, at least by brand & name :
> > the Vendor=0471 ProdID=1120 ( mine is 1125 )
> > its a Philips & Nike mp3 player too..
> >
> > s
On Tue, Jan 13, 2004 at 05:29:10PM -0500, Alan Stern wrote:
> On Tue, 13 Jan 2004, Nemosoft Unv. wrote:
>
> > Hmm, that raises the question: which device gets removed first on unplug?
> > the usb_device or the video_device? This has been indeed quite difficult to
> > fix in the past, as either d
On Tue, Jan 13, 2004 at 11:02:32PM +0100, Nemosoft Unv. wrote:
> > Memory needs to be freed up in this function. If not it will either
> > leak, or we can easily oops the machine (due to the driver not
> > implementing reference counting properly).
>
> Hmm, that raises the question: which device
On Tue, 13 Jan 2004, Nemosoft Unv. wrote:
> Hmm, that raises the question: which device gets removed first on unplug?
> the usb_device or the video_device? This has been indeed quite difficult to
> fix in the past, as either device could disappear any time. If this solved
> that problem, only t
On Tue, 13 Jan 2004, Loic Jaquemet wrote:
> actually , there is a similar device, at least by brand & name :
> the Vendor=0471 ProdID=1120 ( mine is 1125 )
> its a Philips & Nike mp3 player too..
>
> see :
> http://marc.theaimsgroup.com/?l=linux-usb-devel&m=104887595829212&w=2
Well, if your dev
Hello,
On Tuesday 13 January 2004 18:41, Greg KH wrote:
> On Mon, Jan 12, 2004 at 09:42:05PM -0800, Randy.Dunlap wrote:
> > -static int pwc_video_release(struct video_device *vfd)
> > +static void pwc_video_release(struct video_device *vfd)
> > {
> > Trace(TRACE_OPEN, "pwc_video_release() cal
Le Tue, 13 Jan 2004 21:05:14 + Daniel Drake <[EMAIL PROTECTED]> a écrit:
> Are you sure this is a kernel bug?
> I wasn't aware of any kernel support for this device, and a grep for "nike"
> doesnt return anything in the way of MP3 player support.
>
it's more the usb-storage support that i'm
Le Tue, 13 Jan 2004 15:57:39 -0500 (EST) Alan Stern
<[EMAIL PROTECTED]> a écrit:
> On Tue, 13 Jan 2004, Loic Jaquemet wrote:
>
> > Hello,
> >
> > I've bought a Philips-Nike psa128max, which is a 128 Mo mp3 player,
> > with firmware update capacity.
> >
> > Briefly : It doesn't work. ( ~2.4.20
Are you sure this is a kernel bug?
I wasn't aware of any kernel support for this device, and a grep for "nike"
doesnt return anything in the way of MP3 player support.
These things are most commonly controlled in userspace. For example, my
current MP3 player is controlled by an app named "riouti
On Tue, 13 Jan 2004, Axel Waggershauser wrote:
> I found that uhci_urb_dequeue gets called and calls
> uhci_unlink_generic() which in turn processes about 350 TDs, calls
> uhci_delete_queued_urb(), where it seems to find
> list_empty(&urbp->queue_list) to be true and immediately exits
> uhci_delet
David Brownell wrote:
> Hmm, that symptom could be caused by a bug I noticed a while back.
> I didn't have a chance to test the fix, but it compiles and runs
> OK in "normal" operations.
>
> See if this patch makes a difference:
Yes, it does.
After usb storage hangup, removing module ehci-hcd wo
On Tue, 13 Jan 2004, David Brownell wrote:
> Axel Waggershauser wrote:
> > On Tue, 2004-01-13 at 16:36, Alan Stern wrote:
> >
> >>>I still have these printks in giveback() and found to my surprise that
> >>>this function gets called repeatedly for an other urb with a frequency
> >>>of about 4/sec
Axel Waggershauser wrote:
On Tue, 2004-01-13 at 16:36, Alan Stern wrote:
I still have these printks in giveback() and found to my surprise that
this function gets called repeatedly for an other urb with a frequency
of about 4/sec. This starts about the same time the unplugging is
detected, that me
On Maw, 2004-01-13 at 12:35, Paulo Marques wrote:
> 1 - we can let the kernel trap and correct all unaligned accesses. This way
> applications (and the kernel itself) would run slower but with no other problems.
>
> 2 - we can let the kernel just "count" unaligned accesses and let developers
> c
Hello,
I've bought a Philips-Nike psa128max, which is a 128 Mo mp3 player, with
firmware update capacity.
Briefly : It doesn't work. ( ~2.4.20 to 2.6.1 )
So if I can help in any kind of way, i would be delighted ;)
relevant /proc/bus/usb/devices :
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 De
On Tue, 2004-01-13 at 16:36, Alan Stern wrote:
> > I still have these printks in giveback() and found to my surprise that
> > this function gets called repeatedly for an other urb with a frequency
> > of about 4/sec. This starts about the same time the unplugging is
> > detected, that means shortly
On Mon, Jan 12, 2004 at 09:42:05PM -0800, Randy.Dunlap wrote:
> -static int pwc_video_release(struct video_device *vfd)
> +static void pwc_video_release(struct video_device *vfd)
> {
> Trace(TRACE_OPEN, "pwc_video_release() called. Now what?\n");
> }
No, this function _really_ needs to be
On Tue, 13 Jan 2004, Stavros Markou wrote:
> I am using that patch but now I am facing problems during disconnect
> because inside usb_disable_device after device_del I get a crash.
That sounds like something new. Can you post the details of what happens
when the crash occurs?
Alan Stern
-
On Tue, 13 Jan 2004, Axel Waggershauser wrote:
> > Are you sure your wait_event() logic is working correctly? One
> > explanation for these questions is that it missed the event.
>
> Lets say, I am pretty sure. If it would merely miss the event and the
> URB would have successfully been unlinked
On Mon, 12 Jan 2004, David Brownell wrote:
>
> > OK, I'll have to redo this anyway. Do you agree that we need to use
> > GFP_NOIO in usb_ctrl_msg() due to usb_clear_halt() ?
>
> It would seem so. Though someone pointed out that it ought
> to take GFP flags as a parameter ... that's likely a bit
On Tue, 2004-01-13 at 05:20, David Brownell wrote:
> Neither; for now, disconnect() should wait until all the urbs complete.
> Definitely no timeout.
I patched my driver to use asynchronous unlinking and to
wait_for_completion() for the unlinked URB. There are two places now
where I do that. First
Hello,
i am testing my USB interface logic code modelled in vhdl for version
1.1. I need help on how to generate test data for testing the interface. i
have tested the enumeration type of transfer by using a
Pete Zaitcev wrote:
On Mon, 12 Jan 2004 22:04:16 +0100 (MET)
[EMAIL PROTECTED] wrote:
> So everybody who does not want to know how integers are represented
> on the current architecture writes
> start = p[0] + (p[1] << 8) + (p[2] << 16) + (p[3] << 24);
> And it just works.
Real
Hello
Looks like the hc_sl811 driver in 2.6 is badly broken. Are there any
patches / plans to fix it?
Thanks
Guennadi
-
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
--
>On Mon, 12 Jan 2004, Axel Waggershauser wrote:
>> Yes, of course, I should get the completion handler called. Since I
>> called the usb_unlink_urb synchronously, I should have expected it to be
>> called before the unlink call returns, right?
I misconception is that usb_unlink_urb() is synchronou
26 matches
Mail list logo
