Doh! I meant 2.5.21.
> -Original Message-
> From: Jean Tourrilhes [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 6:14 PM
> To: Christopher Hoover
> Cc: 'David Brownell'; [EMAIL PROTECTED]; 'Greg KH'
> Subject: Re: [linux-usb-devel] HCD testing with irda-usb
>
>
> On Mon, J
On Mon, Jun 10, 2002 at 06:10:11PM -0700, Christopher Hoover wrote:
>
> No, I haven't tried my Opti card (yes, jt, I have my own now :-))
And when I gave you mine, I told you that the Opti did contain
a hardware bug. I guess the cheapest at Fry's is the cheapest...
> I'm getting a littl
> Am I right to conclude that Christopher Hoover was able to
> get that very same card working in a different system?
No, I haven't tried my Opti card (yes, jt, I have my own now :-)) in
quite some time. It is certainly possible that some of the recent
changes broke x86.
I'm getting a little
> I've seen at Fry's some pretty cheap EHCI cards. Maybe it's
> time for an upgrade.
Maybe -- those NEC cards seem fine to me, and I could really use some
testing with EHCI going through USB 2.0 hubs using the transaction
translators -- but at the same time those strange ohci-hcd timeouts
s
On Mon, Jun 10, 2002 at 05:42:38PM -0700, David Brownell wrote:
>
> Such symptoms have been seen before with the usb-ohci driver, so it's
> likely that something has just made them more likely. Am I right to
> conclude that Christopher Hoover was able to get that very same card
> working in a di
> Now, back to OHCI. In 2.5.21, things are somewhat different
> than in 2.5.20, and it fails even before the IrDA driver enter in
> action. The full log is below.
> I also tries 2.5.20 on the same box with a non-SMP kernel, and
> that didn't make any difference.
> Yes, I know abo
On Tue, Jun 11, 2002 at 09:44:33AM +1000, Brad Hards wrote:
> On Tue, 11 Jun 2002 09:22, Greg KH wrote:
> > On Tue, Jun 11, 2002 at 07:46:24AM +1000, Brad Hards wrote:
> > > On Tue, 11 Jun 2002 07:20, Greg KH wrote:
> > > > On Tue, Jun 11, 2002 at 07:11:19AM +1000, Brad Hards wrote:
> > > > > Ah,
On Mon, Jun 10, 2002 at 04:47:00PM -0700, Jean Tourrilhes wrote:
> usb-uhci-q.c: Watchdog timeout, defibrillating...
> Expect disconnections...
> => total freeze of my PC
> -
> So, I guess you just need to defibrillate the de
On Mon, Jun 03, 2002 at 08:49:13PM -0700, Greg KH wrote:
> On Mon, Jun 03, 2002 at 07:17:49PM -0700, Jean Tourrilhes wrote:
> > Hi,
> >
> > It seems that we should test the new USB code. So, I did a bit
> > of testing with the various HCD drivers and the irda-usb dongle
> > driver. Bad ne
On Tue, 11 Jun 2002 09:22, Greg KH wrote:
> On Tue, Jun 11, 2002 at 07:46:24AM +1000, Brad Hards wrote:
> > On Tue, 11 Jun 2002 07:20, Greg KH wrote:
> > > On Tue, Jun 11, 2002 at 07:11:19AM +1000, Brad Hards wrote:
> > > > Ah, since it so easy, I guess you won't need any assistance to clean
> > >
On Tue, Jun 11, 2002 at 07:46:24AM +1000, Brad Hards wrote:
> On Tue, 11 Jun 2002 07:20, Greg KH wrote:
> > On Tue, Jun 11, 2002 at 07:11:19AM +1000, Brad Hards wrote:
> > > Ah, since it so easy, I guess you won't need any assistance to clean up
> > > the others :)
> >
> > I can _always_ use assis
On Mon, Jun 10, 2002 at 03:33:37PM -0700, David Brownell wrote:
> This patch:
>
> - Delays or eliminates some IRQs It'll mostly affect control
> or iso transfers, which typically have multiple TDs per URB,
> by making only the last TD generate an IRQ.
>
> - Shortens some of the submit path
On Mon, Jun 10, 2002 at 11:54:33PM +0200, Duncan Sands wrote:
> If you like I will try to find exactly out when the bug appeared.
I would appreciate it.
thanks,
greg k-h
___
Don't miss the 2002 Sprint PCS Application Developer's Conf
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.583 -> 1.584
# drivers/usb/usb.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.582 -> 1.583
#drivers/usb/wacom.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.579 -> 1.580
#drivers/usb/se401.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.580 -> 1.581
# drivers/usb/dabusb.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.581 -> 1.582
# drivers/usb/scanner
Pull from: bk://linuxusb.bkbits.net/m-2.4
The individual patches will be sent in follow up messages to this email.
thanks,
greg k-h
drivers/usb/catc.c|7 +++
drivers/usb/dabusb.c |1 +
drivers/usb/devices.c |4 +++-
drivers/usb/scanner.c | 23 +++
On Tue, 11 Jun 2002 08:12, Christopher Hoover wrote:
> Here's the trace.
> hub.c: new USB device SA--1, assigned address 2
> usb.c: new device strings: Mfr=1, Product=2, SerialNumber=0
> Manufacturer: Griffin Technology, Inc
> Product: iMic USB audio system
> usb.c: USB device 2 (vend/prod 0x
This patch:
- Delays or eliminates some IRQs It'll mostly affect control
or iso transfers, which typically have multiple TDs per URB,
by making only the last TD generate an IRQ.
- Shortens some of the submit path that needs to run with
IRQs disabled ... no need to use the dma_to_td has
> I'd really like to know why you need this patch. Just
> patching a symptom is not a good idea here. I'm more
> interested in why your hardware platform causes this problem
> to happen.
Yeah, well I'm working on that. :-)
Patching a symptom is clearly the wrong way to go, I agree. I thin
On Monday 10 June 2002 11:10 pm, Greg KH wrote:
> On Thu, Jun 06, 2002 at 09:12:39AM +0200, Duncan Sands wrote:
> > I use the userspace driver for my Alcatel USB speedtouch modem.
> > On system shutdown I get the following oops. I have attached some
> > system info to this email.
>
> But while th
On Tue, 11 Jun 2002 07:20, Greg KH wrote:
> On Tue, Jun 11, 2002 at 07:11:19AM +1000, Brad Hards wrote:
> > Ah, since it so easy, I guess you won't need any assistance to clean up
> > the others :)
>
> I can _always_ use assistance :)
>
> Which other .config items are missing .help entries?
>From
On Tue, Jun 11, 2002 at 07:11:19AM +1000, Brad Hards wrote:
> Ah, since it so easy, I guess you won't need any assistance to clean up the
> others :)
I can _always_ use assistance :)
Which other .config items are missing .help entries?
thanks,
greg k-h
___
On Tue, 11 Jun 2002 04:17, Greg KH wrote:
> On Sun, Jun 09, 2002 at 09:45:49PM +1000, Brad Hards wrote:
> > On Fri, 7 Jun 2002 07:43, Greg KH wrote:
> > > [EMAIL PROTECTED], 2002-06-05 16:49:34-07:00, [EMAIL PROTECTED]
> > > Added usb-midi driver from NAGANO Daisuke with some porting from me.
>
On Thu, Jun 06, 2002 at 09:12:39AM +0200, Duncan Sands wrote:
> I use the userspace driver for my Alcatel USB speedtouch modem.
> On system shutdown I get the following oops. I have attached some
> system info to this email.
But while the machine is up, it works ok? There were some disconnect
i
On Mon, Jun 10, 2002 at 07:32:02PM +1000, Brad Hards wrote:
> Patch for 2.5.21 attached, for se401 fixes.
Applied, thanks.
greg k-h
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
htt
On Mon, Jun 10, 2002 at 05:28:13PM +1000, Brad Hards wrote:
> These are some of the usb relevant bugs from the latest round of checker
> reports, posted to lkml. I compared these reports to 2.4.19-pre10 and 2.5.21.
> Patches are _compile_ tested only, but look good to me. Please review and
> co
On Mon, Jun 10, 2002 at 08:49:59PM +1000, Brad Hards wrote:
> More fixes for bugs found by the Checker.
> Semaphore's really aren't my thing. But I think these fixes (against
> 2.4.19-pre10 and 2.5.21) in the error paths are OK. Please review and merge
> if appropriate.
Applied to both trees, t
Petr Slansky writes:
> Hello!
>
> I have a noname enclosure for 2.5" HD with USB 1.1 interface.
> There is a chip ScanLogic SL11R-IDE inside. It doesn't work under
> Linux, it works in windows.
>
> Orginal usb id was: 0x04ce/0x0002/0x0260
> I found a recomandation to update firmware. I did it,
> From: Oliver Neukum <[EMAIL PROTECTED]>
> Date: Mon, 10 Jun 2002 20:46:17 +0200
> > See my other post ... start of next structure is controlled by a
> > structure level alignment attribute (forcing extra padding at end),
> > while start of next _member_ is controlled by member level attributes.
> > Does this mean that gcc will _not_ pad the end of such a member
> > of a structure to ensure that the next one will not share a cache
> > line, if an ordinary alignment directive is issued ?
>
> When I saw what "info gcc" said about __aligned__ variable attributes,
> it talked about aligning
On Mon, Jun 10, 2002 at 12:23:47AM +0200, Nemosoft Unv. wrote:
>
> This patch is again 2.5.20. Attempts at patching 2.5.21 resulted in
> unresolved vmalloc()s (which got changed between 2.5.20 and 2.5.21 and
> somehow trashes half the modules I use)
Applied, thanks.
greg k-h
On Sun, Jun 09, 2002 at 05:09:54PM -0700, David Brownell wrote:
> One could get to like "KBUILD_VERBOSE=0 make" ... :)
Yes, the kbuild changes are quite nice :)
> This gets rid of a compile warning.
Applied, thanks.
greg k-h
___
Don
On Sun, Jun 09, 2002 at 09:45:49PM +1000, Brad Hards wrote:
> On Fri, 7 Jun 2002 07:43, Greg KH wrote:
> > [EMAIL PROTECTED], 2002-06-05 16:49:34-07:00, [EMAIL PROTECTED]
> > Added usb-midi driver from NAGANO Daisuke with some porting from me.
> >
> > drivers/usb/class/Config.in |1
> > dr
On Mon, Jun 10, 2002 at 08:00:11PM +0200, Oliver Neukum wrote:
> Am Montag, 10. Juni 2002 19:46 schrieb Tom Rini:
> > On Mon, Jun 10, 2002 at 07:33:18PM +0200, Oliver Neukum wrote:
> > > this change set against 2.4 introduces a #define to be used by the
> > > driver who are concerned by this issue
On Mon, Jun 10, 2002 at 08:00:56PM +0200, Oliver Neukum wrote:
> Am Montag, 10. Juni 2002 19:48 schrieb David Brownell:
> > > - u8 status; /* status returned from ep_response after command
> > > completion */ + u8 status __atribute__((aligned(INCOHERENT_DMA))); /*
> > > status returned from ep_r
Am Montag, 10. Juni 2002 19:48 schrieb David Brownell:
> > - u8 status; /* status returned from ep_response after command
> > completion */ + u8 status __atribute__((aligned(INCOHERENT_DMA))); /*
> > status returned from ep_response after command completion */
>
> How about
> (a) spelling "a
Am Montag, 10. Juni 2002 19:46 schrieb Tom Rini:
> On Mon, Jun 10, 2002 at 07:33:18PM +0200, Oliver Neukum wrote:
> > this change set against 2.4 introduces a #define to be used by the
> > driver who are concerned by this issue.
>
> Can we wait abit for this please? Defining it to SMP_CACHE_BYTES
> (b) making the #define do more of the annoying typing like
>
> #define DMA_ALIGNED __attribute__((aligned(SMP_CACHE_BYTES)
... or maybe even
#define DMA_ALIGNED __cacheline_aligned
Though I agree with Tom Rini, this needs a kernel-wide solution.
- Dave
_
Oliver Neukum wrote:
>>(Using SMP_CACHE_BYTES I guess, though it's not clear to me that
>>synchronizing with other CPUs would have the same requirement as
>>synchronizing to various devices.) Might be good to stick such
>>data at the end of structures, since when they're kmalloced in
>>cacheline-
> - u8 status; /* status returned from ep_response after command completion */
> + u8 status __atribute__((aligned(INCOHERENT_DMA))); /* status returned from
>ep_response after command completion */
How about
(a) spelling "attribute" right, and
(b) making the #define do more of the annoy
On Mon, Jun 10, 2002 at 07:33:18PM +0200, Oliver Neukum wrote:
> this change set against 2.4 introduces a #define to be used by the driver
> who are concerned by this issue.
Can we wait abit for this please? Defining it to SMP_CACHE_BYTES is
counter-intuitive since these machines don't do SMP.
> (Using SMP_CACHE_BYTES I guess, though it's not clear to me that
> synchronizing with other CPUs would have the same requirement as
> synchronizing to various devices.) Might be good to stick such
> data at the end of structures, since when they're kmalloced in
> cacheline-aligned chunks, alig
Hi,
this is the fix for 2.4 for kaweth.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[EMAIL P
Hi,
this is the fix for 2.4 for hpusbscsi.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[EMAIL
Hi,
this is the fix for 2.4 for microtek.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
[EMAIL
Hi,
this change set against 2.4 introduces a #define to be used by the driver
who are concerned by this issue.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
>>Replying to myself Anyway, I realized that even my idea above is
>>wrong. I don't see _any_ safe way to share a cache line between a DMA
>>buffer and other data. Access to the cache line might pull the cache
>>line back in and write it back at any time, which could corrupt the
>>DMA'ed da
Hi,
some more on that issue in 2.4
clean: acm, audio, auerswald, CDCEther, dc2xx, printer, rio500, scanner,
unclean: bluetooth, brlvger, catc, dsbr100, hid, hpusbscsi, hub, kaweth,
mdc800, microtek, pegasus, rtl8150,
unknown: dabusb, emi26, ibmcam, ov511, pwc, se401, stv680
HTH
> Replying to myself Anyway, I realized that even my idea above is
> wrong. I don't see _any_ safe way to share a cache line between a DMA
> buffer and other data. Access to the cache line might pull the cache
> line back in and write it back at any time, which could corrupt the
> DMA'ed d
On Sat, Jun 08, 2002 at 07:10:51PM -0700, Christopher Hoover wrote:
> This one fell through the cracks according to bk usb-2.5 -- this
> prevents a bogus array access when the active configuration contains
> no interfaces. It isn't clear why this happens to me on ocassion, but
> when it does the
Hi,
here are the words of the wise concerning the DMA problems.
I'd suggest that we #define a macro for the time being.
Regards
Oliver
-- Weitergeleitete Nachricht --
Subject: Re: PCI DMA to small buffers on cache-incoherent arch
Date: Mon, 10 Jun 2002
More fixes for bugs found by the Checker.
Semaphore's really aren't my thing. But I think these fixes (against
2.4.19-pre10 and 2.5.21) in the error paths are OK. Please review and merge
if appropriate.
Brad
-- Forwarded Message --
Subject: [CHECKER] 18 potential missing unl
On Mon, 10 Jun 2002 17:28, Brad Hards wrote:
> These are some of the usb relevant bugs from the latest round of checker
> reports, posted to lkml. I compared these reports to 2.4.19-pre10 and
> 2.5.21. Patches are _compile_ tested only, but look good to me. Please
> review and consider merging ups
On Mon, 10 Jun 2002 18:25, navinb wrote:
> can I connect a host to slave by a usb cable(high speed) both side
> terminted by series A (flat one) connector,
It will physically work as long as you really have a host and a device (there
is nothing special about the connectors), but is an illegal con
can I connect a host to slave by a usb cable(high speed) both side
terminted by series A (flat one) connector,
since i an running through a special case two identical
boards(mpc823) one running host and another slave image
both have USB port series A receptable where as ,
normally a slave (usb
These are some of the usb relevant bugs from the latest round of checker
reports, posted to lkml. I compared these reports to 2.4.19-pre10 and 2.5.21.
Patches are _compile_ tested only, but look good to me. Please review and
consider merging upstream, ideally before 2.4.19.
Brad
-
59 matches
Mail list logo
