On Fri, Sep 06, 2019, Borislav Petkov wrote:
> On Fri, Sep 06, 2019 at 08:46:18AM -0700, Johannes Erdfelt wrote:
> > That said, we very much rely on late microcode loading and it has helped
> > us and our customers significantly.
>
> You do realize that you rely on an updat
On Fri, Sep 06, 2019, Borislav Petkov wrote:
> On Fri, Sep 06, 2019 at 07:40:39AM -0700, Johannes Erdfelt wrote:
> > I ask because we have successfully used late microcode loading on tens
> > of thousands of hosts.
>
> How do you deal with all the mitigations microcode loade
On Fri, Sep 06, 2019, Thomas Gleixner wrote:
> What your customers are asking for is a receipe for disaster. They can
> check the safety of late loading forever, it will not magically become safe
> because they do so.
>
> If you want late loading, then the whole approach needs to be reworked
On Mon, May 20, 2019, Josh Poimboeuf wrote:
> I think you must have been looking at an old version.
>
> [(v5.2-rc1)] ~/git/linux $ grep jeyu MAINTAINERS
> M:Jessica Yu
Operator error on my part. I was looking at a different directory with
an old branch checked out. Sorry!
> Can you try
:49 PM, Johannes Erdfelt wrote:
> > [ ... snip ... ]
> >
> > I have put together a test case that can reproduce the crash using
> > KVM. The tarball includes a minimal kernel and initramfs, along with
> > a script to run qemu and the .config used to build the ke
There exists a race condition between livepatch and ftrace that can
cause an oops similar to this one:
BUG: unable to handle page fault for address: c005b1d9
#PF: supervisor write access in kernel mode
#PF: error_code(0x0003) - permissions violation
PGD 3ea0c067 P4D 3ea0c067 PUD
On Thu, Jul 28, 2005, Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> diff --git a/drivers/usb/host/uhci.c b/drivers/usb/host/uhci.c
> --- a/drivers/usb/host/uhci.c
> +++ b/drivers/usb/host/uhci.c
> @@ -2924,7 +2924,7 @@ static int alloc_uhci(struct pci_dev *de
> }
>
>
On Thu, Jul 28, 2005, Marcelo Tosatti [EMAIL PROTECTED] wrote:
diff --git a/drivers/usb/host/uhci.c b/drivers/usb/host/uhci.c
--- a/drivers/usb/host/uhci.c
+++ b/drivers/usb/host/uhci.c
@@ -2924,7 +2924,7 @@ static int alloc_uhci(struct pci_dev *de
}
/* Only
On Thu, Jan 27, 2005, DervishD <[EMAIL PROTECTED]> wrote:
> Didn't knew about that... Thanks a lot for the info!. Is there
> any documentation available for the ioctl USB interface to the
> kernel? Any API guide or something like that?
You can use the kernel sources to see how to use it.
JE
On Thu, Jan 27, 2005, DervishD [EMAIL PROTECTED] wrote:
Didn't knew about that... Thanks a lot for the info!. Is there
any documentation available for the ioctl USB interface to the
kernel? Any API guide or something like that?
You can use the kernel sources to see how to use it.
JE
-
To
On Wed, Jan 26, 2005, DervishD <[EMAIL PROTECTED]> wrote:
> * Oliver Neukum <[EMAIL PROTECTED]> dixit:
> > Am Mittwoch, 26. Januar 2005 13:20 schrieb DervishD:
> > > ? ? My question is: which interface should be used by user space
> > > applications, or ioctl's? Is the ioctl interface
> > >
On Wed, Jan 26, 2005, DervishD [EMAIL PROTECTED] wrote:
* Oliver Neukum [EMAIL PROTECTED] dixit:
Am Mittwoch, 26. Januar 2005 13:20 schrieb DervishD:
? ? My question is: which interface should be used by user space
applications, linux/usb.h or ioctl's? Is the ioctl interface
On Tue, Jul 03, 2001, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> I was reading through the ACPI spec, to see what was required to obtain
> the IRQ routing table from AML.
FWIW, ia64 already does this, if you're looking for the code to do it.
JE
-
To unsubscribe from this list: send the line
On Tue, Jul 03, 2001, Jeff Garzik [EMAIL PROTECTED] wrote:
I was reading through the ACPI spec, to see what was required to obtain
the IRQ routing table from AML.
FWIW, ia64 already does this, if you're looking for the code to do it.
JE
-
To unsubscribe from this list: send the line
On Tue, Jun 19, 2001, Dylan Griffiths <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
> > Could you load uhci with the debug=1 option?
>
> I did an 'insmod uhci.o debug=1' but the dmesg output did not alter.
>
> My easy steps to reproduce it is to 'delete
On Tue, Jun 19, 2001, Dylan Griffiths [EMAIL PROTECTED] wrote:
Johannes Erdfelt wrote:
Could you load uhci with the debug=1 option?
I did an 'insmod uhci.o debug=1' but the dmesg output did not alter.
My easy steps to reproduce it is to 'delete selected images' in gphoto
i.c: USB UHCI at I/O 0xd000, IRQ 5
> usb.c: new USB bus registered, assigned bus number 2
> hub.c: USB hub found
> hub.c: 2 ports detected
> uhci.c: Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti
> Fliegl, Thomas Sailer, Roman Weissgaerber
> uhci.c: USB Unive
, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
uhci.c: Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti
Fliegl, Thomas Sailer, Roman Weissgaerber
uhci.c: USB Universal Host Controller Interface driver
hub.c: USB new device connect on bus1/2, assigned device
On Fri, Jun 15, 2001, Kelledin Tane <[EMAIL PROTECTED]> wrote:
> Apologies if this has been posted before. I imagine it has.
>
> In kernel 2.4.5 stock, ov511.c fails to compile. A little intelligent
> searching through 2.4.4 source reveals that the following line in 2.4.4:
>
> static const
On Fri, Jun 15, 2001, Kelledin Tane [EMAIL PROTECTED] wrote:
Apologies if this has been posted before. I imagine it has.
In kernel 2.4.5 stock, ov511.c fails to compile. A little intelligent
searching through 2.4.4 source reveals that the following line in 2.4.4:
static const char
On Thu, May 24, 2001, Prasanna P Subash <[EMAIL PROTECTED]> wrote:
> Without the patch below the boot up would hang right after it detected the
> ide devices.
>
> After applying the patch it booted all the way but the keyboard would hang.
>
> BTW I'm trying to port this patch back to the 2.2.18
On Thu, May 24, 2001, Prasanna P Subash <[EMAIL PROTECTED]> wrote:
> I have a dual athlon on the 760MP chipset.
> 2.2.20pre1 and 2 dont work. I got it to work partly after applying Johannes
> Erdfel's 760MP patch in io_apic.c. Even after applying the patch, there
> are messages like
2.2.20pre1
On Thu, May 24, 2001, Prasanna P Subash [EMAIL PROTECTED] wrote:
Without the patch below the boot up would hang right after it detected the
ide devices.
After applying the patch it booted all the way but the keyboard would hang.
BTW I'm trying to port this patch back to the 2.2.18
On Thu, May 24, 2001, Prasanna P Subash [EMAIL PROTECTED] wrote:
I have a dual athlon on the 760MP chipset.
2.2.20pre1 and 2 dont work. I got it to work partly after applying Johannes
Erdfel's 760MP patch in io_apic.c. Even after applying the patch, there
are messages like
2.2.20pre1 and
On Thu, May 17, 2001, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > But no, I don't actually like sockets all that much myself. They are hard
> > > to use from scripts, and many more people are familiar with open/close and
> > > read/write.
> >
> > Agreed.
> >
> > It would be nice to use
On Thu, May 17, 2001, Pavel Machek [EMAIL PROTECTED] wrote:
But no, I don't actually like sockets all that much myself. They are hard
to use from scripts, and many more people are familiar with open/close and
read/write.
Agreed.
It would be nice to use open/close/read/write for
On Thu, May 17, 2001, Kai Henningsen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Johannes Erdfelt) wrote on 15.05.01 in
><[EMAIL PROTECTED]>:
>
> > I had always made the assumption that sockets were created because you
> > couldn't easily map IPv4
On Thu, May 17, 2001, Kai Henningsen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Johannes Erdfelt) wrote on 15.05.01 in
[EMAIL PROTECTED]:
I had always made the assumption that sockets were created because you
couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
On Wed, May 16, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> On Wed, May 16, 2001 at 12:56:55PM -0700, Johannes Erdfelt wrote:
> > Could you try this patch? It applies on top of 2.2.20pre1
> >
> > It also cleans up a couple of comments
>
> That fixes it alr
On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
> > On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> > >
> > > That does indeed correct the problem.
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote:
On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote:
That does indeed correct the problem. 2.2.20pre1 now works
as expected.
Hmm, that uses a VIA
On Wed, May 16, 2001, Shane Wegner [EMAIL PROTECTED] wrote:
On Wed, May 16, 2001 at 12:56:55PM -0700, Johannes Erdfelt wrote:
Could you try this patch? It applies on top of 2.2.20pre1
It also cleans up a couple of comments
That fixes it alright.
Excellent. Alan, could you apply
On Tue, May 15, 2001, James Simmons <[EMAIL PROTECTED]> wrote:
> > Personally, I'd really like to see /dev/ttyS0 be the first detected serial
> > port on a system, /dev/ttyS1 the second, etc. Currently there are plenty of
> > different serial hardware with all their own drivers and /dev entries.
On Tue, May 15, 2001, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Tue, 15 May 2001, Johannes Erdfelt wrote:
> >
> > Even bulk has issues because USB pipe's aren't necessarily streams, they
> > can packetized in the psuedo weird way that USB does things
On Tue, May 15, 2001, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Tue, 15 May 2001, James Simmons wrote:
> > >
> > > And if write() has too much overhead - we'd better fix _that_, because
> > > it's much more likely hotspot than ioctl ever will be.
> >
> > I would use write except we use
On Tue, May 15, 2001, Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 15 May 2001, James Simmons wrote:
And if write() has too much overhead - we'd better fix _that_, because
it's much more likely hotspot than ioctl ever will be.
I would use write except we use write to draw
On Tue, May 15, 2001, Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 15 May 2001, Johannes Erdfelt wrote:
Even bulk has issues because USB pipe's aren't necessarily streams, they
can packetized in the psuedo weird way that USB does things.
This is ok. pipe does not mean
On Tue, May 15, 2001, James Simmons [EMAIL PROTECTED] wrote:
Personally, I'd really like to see /dev/ttyS0 be the first detected serial
port on a system, /dev/ttyS1 the second, etc. Currently there are plenty of
different serial hardware with all their own drivers and /dev entries. For
On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
> > On Mon, May 07, 2001, Shane Wegner <[EMAIL PROTECTED]> wrote:
> > >
> > > That does indeed correct the problem.
:
> > > Stuck on TLB IPI wait (CPU#0)
> > >
> > > Booting vanilla 2.2.19 works fine. The machine is an
> > > Intel Pentium III 850MHZ on an Abit VP6 board. If any
> > > further information is needed, let me know.
> >
> > Can you back o
)
Booting vanilla 2.2.19 works fine. The machine is an
Intel Pentium III 850MHZ on an Abit VP6 board. If any
further information is needed, let me know.
Can you back out the change to io_apic.c and tell me if that fixes it. If so
let Johannes Erdfelt and I know.
That does indeed correct
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote:
On Mon, May 07, 2001 at 11:02:50AM -0700, Johannes Erdfelt wrote:
On Mon, May 07, 2001, Shane Wegner [EMAIL PROTECTED] wrote:
That does indeed correct the problem. 2.2.20pre1 now works
as expected.
Hmm, that uses a VIA
On Tue, Apr 24, 2001, Michael Meissner <[EMAIL PROTECTED]> wrote:
> and it doesn't ask whether I want to build the normal USHI USB driver either as
> a module or builtin to the kernel, only whether I want to build the alternative
> USHI USB dirver (the JE driver). Make xconfig asks whether you
On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote:
> > > Kernel: 2.4.2 - latest (2.4.3-ac12)
> > > Platform: x86 on mangled Slack7.1
> > > Hardware: MSI 694D Pro-AR
> > > ( http://www.msicomputer.com/products/detail.asp?ProductID=150
On Mon, Apr 23, 2001, josh <[EMAIL PROTECTED]> wrote:
> Kernel: 2.4.2 - latest (2.4.3-ac12)
> Platform: x86 on mangled Slack7.1
> Hardware: MSI 694D Pro-AR
> ( http://www.msicomputer.com/products/detail.asp?ProductID=150 )
>
> Problem: USB devices timeout on address assignment. Course thats with
On Mon, Apr 23, 2001, josh [EMAIL PROTECTED] wrote:
Kernel: 2.4.2 - latest (2.4.3-ac12)
Platform: x86 on mangled Slack7.1
Hardware: MSI 694D Pro-AR
( http://www.msicomputer.com/products/detail.asp?ProductID=150 )
Problem: USB devices timeout on address assignment. Course thats with the
On Mon, Apr 23, 2001, josh [EMAIL PROTECTED] wrote:
On Mon, Apr 23, 2001, josh [EMAIL PROTECTED] wrote:
Kernel: 2.4.2 - latest (2.4.3-ac12)
Platform: x86 on mangled Slack7.1
Hardware: MSI 694D Pro-AR
( http://www.msicomputer.com/products/detail.asp?ProductID=150 )
Problem:
On Tue, Apr 17, 2001, FAVRE Gregoire <[EMAIL PROTECTED]> wrote:
> Thus spake Johannes Erdfelt ([EMAIL PROTECTED]):
>
> > You should probably bring up things like this on the Linux USB list.
>
> Well, where is that mailing list?
http://www.linux-usb.org
> > W
You should probably bring up things like this on the Linux USB list.
On Tue, Apr 17, 2001, FAVRE Gregoire <[EMAIL PROTECTED]> wrote:
> Under 2.4.3 I manage uploading photo from my Digital IXUS using USB_UHCI
> with s10h, but under ac series, I don't manage, only other things I have
> changed is
You should probably bring up things like this on the Linux USB list.
On Tue, Apr 17, 2001, FAVRE Gregoire [EMAIL PROTECTED] wrote:
Under 2.4.3 I manage uploading photo from my Digital IXUS using USB_UHCI
with s10h, but under ac series, I don't manage, only other things I have
changed is
On Mon, Apr 02, 2001, Jeff Golds <[EMAIL PROTECTED]> wrote:
> Let me show what I got with the 2.4.2 kernel with USB support enabled.
>
> Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad
> Mar 19 14:10:31 Eng99 last message repeated 108 times
> Mar 19 14:11:37 Eng99 last
On Mon, Apr 02, 2001, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST)
> > From: Ketil Froyn <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
>
> > While running kernel 2.4.2-ac28, I switched on spinlock debugging and
> > verbose BUG() reporting (I
On Mon, Apr 02, 2001, Pete Zaitcev [EMAIL PROTECTED] wrote:
Date: Sun, 1 Apr 2001 03:35:03 +0200 (CEST)
From: Ketil Froyn [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
While running kernel 2.4.2-ac28, I switched on spinlock debugging and
verbose BUG() reporting (I always use sysrq).
On Mon, Apr 02, 2001, Jeff Golds [EMAIL PROTECTED] wrote:
Let me show what I got with the 2.4.2 kernel with USB support enabled.
Mar 19 14:10:00 Eng99 kernel: uhci: host controller halted. very bad
Mar 19 14:10:31 Eng99 last message repeated 108 times
Mar 19 14:11:37 Eng99 last message
On Fri, Mar 16, 2001, Grover, Andrew <[EMAIL PROTECTED]> wrote:
> This is a preliminary patch against 2.4.2 to uhci.c that puts the host
> controller into global suspend when there are no devices attached. This
> conserves power on mobile systems, and because suspending the host
> controller
On Fri, Mar 16, 2001, Grover, Andrew [EMAIL PROTECTED] wrote:
This is a preliminary patch against 2.4.2 to uhci.c that puts the host
controller into global suspend when there are no devices attached. This
conserves power on mobile systems, and because suspending the host
controller ceases
The I/O APIC code for 2.2 contains a little trick which sets the destination
to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC
on AMD-760MP systems causing a lockup during boot.
This patch removes that trick in favor of doing what 2.4 does, masking out
the entries.
This
The I/O APIC code for 2.2 contains a little trick which sets the destination
to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC
on AMD-760MP systems causing a lockup during boot.
This patch removes that trick in favor of doing what 2.4 does, masking out
the entries.
This
On Fri, Mar 09, 2001, David S. Miller <[EMAIL PROTECTED]> wrote:
> Manfred Spraul writes:
> > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > yet.
>
> I am against any API which provides this. It can be extremely
> expensive to do this on some architectures, and
On Fri, Mar 09, 2001, David S. Miller [EMAIL PROTECTED] wrote:
Manfred Spraul writes:
Do lots of drivers need the reverse mapping? It wasn't on my todo list
yet.
I am against any API which provides this. It can be extremely
expensive to do this on some architectures, and since the
On Sat, Feb 24, 2001, Pifko Krisztian <[EMAIL PROTECTED]> wrote:
> I've made a patch which adds usb support for the philips
> rush mp3 player. The driver is mainly the rio500 driver
> only the rush specific parts were modified.
>
> The patch is against 2.4.2.
>
> It uses char 180 65 at
On Sun, Feb 18, 2001, lafanga lafanga <[EMAIL PROTECTED]> wrote:
> The programs 'gpm', 'kudzu' and 'startx' all hang the server immediately
> after they exit (with exit status 0). I cannot pinpoint why the kernel hangs
> and would appreciate any help. The only thing I suspect it may be is that
On Sun, Feb 18, 2001, lafanga lafanga [EMAIL PROTECTED] wrote:
The programs 'gpm', 'kudzu' and 'startx' all hang the server immediately
after they exit (with exit status 0). I cannot pinpoint why the kernel hangs
and would appreciate any help. The only thing I suspect it may be is that it
On Thu, Feb 15, 2001, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'm using the usb-uhci core with the 8200e storage drivers. I don't why
> the kernel logs the next message:
>
> uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4
> uhci.c: root-hub INT complete: port1: 495
On Thu, Feb 15, 2001, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I'm using the usb-uhci core with the 8200e storage drivers. I don't why
the kernel logs the next message:
uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 495 port2: 58a
On Fri, Feb 09, 2001, John Cavan <[EMAIL PROTECTED]> wrote:
> Just got a D-Link USB radio (R100) and I'm seeing lots of timeouts with
> it. I've seen this through the last few 2.4.1+ and -ac+ kernels.
>
> Current config:
>
> Dual P3-500 w/ 512mb of RAM
> Tyan Tiger 133 mobo with VIA chipset,
On Fri, Feb 09, 2001, John Cavan [EMAIL PROTECTED] wrote:
Just got a D-Link USB radio (R100) and I'm seeing lots of timeouts with
it. I've seen this through the last few 2.4.1+ and -ac+ kernels.
Current config:
Dual P3-500 w/ 512mb of RAM
Tyan Tiger 133 mobo with VIA chipset, onboard USB
On Thu, Feb 08, 2001, Michael H. Warfield <[EMAIL PROTECTED]> wrote:
> But, wait a minute. CNAME -> CNAME is a "must not". MX -> CNAME
> is a "should not". The "should not" leaves it to be implimentation
> dependent and not an outright ban. Sooo...
Actually, I had this conversation
On Sun, Feb 04, 2001, Andi Kleen <[EMAIL PROTECTED]> wrote:
> "Hen, Shmulik" <[EMAIL PROTECTED]> writes:
>
> > Actually yes. We were warned that on IA64 architecture the system will halt
> > when accessing any type of variable via a pointer if the pointer does not
> > contain an aligned address
On Sun, Feb 04, 2001, Andi Kleen [EMAIL PROTECTED] wrote:
"Hen, Shmulik" [EMAIL PROTECTED] writes:
Actually yes. We were warned that on IA64 architecture the system will halt
when accessing any type of variable via a pointer if the pointer does not
contain an aligned address matching
On Thu, Jan 25, 2001, David S. Miller <[EMAIL PROTECTED]> wrote:
>
> H. Peter Anvin writes:
> > > RFC793, where is lists the unused flag bits as "reserved".
> > > That is pretty clear to me. It just has to say that
> > > they are reserved, and that is what it does.
> > >
> >
> > Is the
On Thu, Jan 25, 2001, Thunder from the hill <[EMAIL PROTECTED]> wrote:
> I am using an usual VIA MPV3 onboard USB device (on a AMD K6-II 400
> machine), and it has ever worked fine on Linux (until including
> 2.4.0-test10). Now I wanted to use the "retail" 2.4.0-kernel, and USB
> gets stuck while
On Thu, Jan 25, 2001, Thunder from the hill [EMAIL PROTECTED] wrote:
I am using an usual VIA MPV3 onboard USB device (on a AMD K6-II 400
machine), and it has ever worked fine on Linux (until including
2.4.0-test10). Now I wanted to use the "retail" 2.4.0-kernel, and USB
gets stuck while
On Thu, Jan 25, 2001, David S. Miller [EMAIL PROTECTED] wrote:
H. Peter Anvin writes:
RFC793, where is lists the unused flag bits as "reserved".
That is pretty clear to me. It just has to say that
they are reserved, and that is what it does.
Is the definition of
On Sat, Jan 20, 2001, Russell King <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt writes:
> > They need to be visible via DMA. They need to be 16 byte aligned. We
> > also have QH's which have similar requirements, but we don't use as many
> > of them.
>
>
On Sat, Jan 20, 2001, Russell King [EMAIL PROTECTED] wrote:
Johannes Erdfelt writes:
They need to be visible via DMA. They need to be 16 byte aligned. We
also have QH's which have similar requirements, but we don't use as many
of them.
Can we get away from the "16 byte aligned"
On Sat, Jan 20, 2001, Manfred Spraul <[EMAIL PROTECTED]> wrote:
> >
> > TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I
> > haven't checked recently). That's a waste of space for an entire page.
> >
> > However, having every driver implement it's own slab cache seems
On Sat, Jan 20, 2001, Russell King <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt writes:
> > On Fri, Jan 19, 2001, Miles Lane <[EMAIL PROTECTED]> wrote:
> > > Johannes Erdfelt wrote:
> > >
> > > > TODO
> > > >
> > &
On Sat, Jan 20, 2001, Russell King [EMAIL PROTECTED] wrote:
Johannes Erdfelt writes:
On Fri, Jan 19, 2001, Miles Lane [EMAIL PROTECTED] wrote:
Johannes Erdfelt wrote:
TODO
- The PCI DMA architecture is horribly inefficient on x86 and ia64. The
result is a page
On Sat, Jan 20, 2001, Manfred Spraul [EMAIL PROTECTED] wrote:
TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I
haven't checked recently). That's a waste of space for an entire page.
However, having every driver implement it's own slab cache seems a
On Fri, Jan 19, 2001, Miles Lane <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
>
> > TODO
> >
> > - The PCI DMA architecture is horribly inefficient on x86 and ia64. The
> > result is a page is allocated for each TD. This is evil. Perhaps a sl
On Fri, Jan 19, 2001, Miles Lane [EMAIL PROTECTED] wrote:
Johannes Erdfelt wrote:
TODO
- The PCI DMA architecture is horribly inefficient on x86 and ia64. The
result is a page is allocated for each TD. This is evil. Perhaps a slab
cache internally? Or modify the generic slab
On Sat, Jan 06, 2001, antirez <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 05, 2001 at 04:48:00PM -0800, Dunlap, Randy wrote:
> > This rings a small bell with me.
> > There was a change by Dan Streetman IIRC to limit
> > usbdevfs bulk transfers to PAGE_SIZE (4 KB for x86,
> > or 0x1000). Anything
On Sat, Jan 06, 2001, antirez [EMAIL PROTECTED] wrote:
On Fri, Jan 05, 2001 at 04:48:00PM -0800, Dunlap, Randy wrote:
This rings a small bell with me.
There was a change by Dan Streetman IIRC to limit
usbdevfs bulk transfers to PAGE_SIZE (4 KB for x86,
or 0x1000). Anything larger than
On Fri, Jan 05, 2001, Keith Owens <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Jan 2001 02:42:11 -0200,
> Fr d ric L . W . Meunier <[EMAIL PROTECTED]> wrote:
> >Is this just me? Configuring 2.4.0 with make menuconfig with
> >CONFIG_EXPERIMENTAL=y I get no prompt for USB Mass Storage,
> >but the
On Fri, Jan 05, 2001, Keith Owens [EMAIL PROTECTED] wrote:
On Fri, 5 Jan 2001 02:42:11 -0200,
Fr d ric L . W . Meunier [EMAIL PROTECTED] wrote:
Is this just me? Configuring 2.4.0 with make menuconfig with
CONFIG_EXPERIMENTAL=y I get no prompt for USB Mass Storage,
but the .config is saved
On Mon, Jan 01, 2001, Heitzso <[EMAIL PROTECTED]> wrote:
> Johannes, I apologize for not getting back to you earlier.
> Holidays, a changing kernel, and work, kept me away from
> the test.
No problem.
> DATA: s10sh 0.1.9 is a program used to access the USB
> bus to get to digital cameras and
On Mon, Jan 01, 2001, Heitzso [EMAIL PROTECTED] wrote:
Johannes, I apologize for not getting back to you earlier.
Holidays, a changing kernel, and work, kept me away from
the test.
No problem.
DATA: s10sh 0.1.9 is a program used to access the USB
bus to get to digital cameras and download
On Mon, Dec 18, 2000, Heitzso <[EMAIL PROTECTED]> wrote:
> I have a Canon usb camera that I access via a
> recent copy of the s10sh program (with -u option).
>
> Getting to the camera via s10sh -u worked through
> large sections of 2.4.0 test X but broke recently.
> I cannot say for certain
On Mon, Dec 18, 2000, Heitzso [EMAIL PROTECTED] wrote:
I have a Canon usb camera that I access via a
recent copy of the s10sh program (with -u option).
Getting to the camera via s10sh -u worked through
large sections of 2.4.0 test X but broke recently.
I cannot say for certain which
On Tue, Dec 12, 2000, Laramie Leavitt <[EMAIL PROTECTED]> wrote:
> [1.] One line summary of the problem:
> USB (MS Intellimouse specifically) does not work with SMP kernel 2.2.18.
>
> [2.] Full description of the problem/report:
> When trying to install a Microsoft Intellimouse Explorer (USB)
>
On Tue, Dec 12, 2000, Laramie Leavitt [EMAIL PROTECTED] wrote:
[1.] One line summary of the problem:
USB (MS Intellimouse specifically) does not work with SMP kernel 2.2.18.
[2.] Full description of the problem/report:
When trying to install a Microsoft Intellimouse Explorer (USB)
to a SMP
On Fri, Dec 08, 2000, Johannes Erdfelt <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 08, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote:
> > On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
> >
> > > Could you try the alternate UHCI driver? You may need to di
On Fri, Dec 08, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
>
> > Could you try the alternate UHCI driver? You may need to disable the
> > UHCI driver you have configured for the option to become visible.
>
> Di
On Fri, Dec 08, 2000, David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
Could you try the alternate UHCI driver? You may need to disable the
UHCI driver you have configured for the option to become visible.
Differently broken:
uhci: host
On Fri, Dec 08, 2000, Johannes Erdfelt [EMAIL PROTECTED] wrote:
On Fri, Dec 08, 2000, David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 7 Dec 2000, Johannes Erdfelt wrote:
Could you try the alternate UHCI driver? You may need to disable the
UHCI driver you have configured
On Thu, Dec 07, 2000, David Woodhouse <[EMAIL PROTECTED]> wrote:
> Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make
> this magically go away? I doubt it.
Probably not. Enabling bus mastering is the difference between USB
working at all (transfering data to the device) and
On Thu, Dec 07, 2000, David Woodhouse [EMAIL PROTECTED] wrote:
Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make
this magically go away? I doubt it.
Probably not. Enabling bus mastering is the difference between USB
working at all (transfering data to the device) and not
On Wed, Dec 06, 2000, Miles Lane <[EMAIL PROTECTED]> wrote:
> Hmm. Your patch doesn't test whether pci_enable_device(dev)
> was successful, does it?
Umm, it does. If pci_enable_device wasn't successful, it returns -ENODEV.
Your patch below calls pci_set_master if enabling the device fails and
On Wed, Dec 06, 2000, Miles Lane [EMAIL PROTECTED] wrote:
Hmm. Your patch doesn't test whether pci_enable_device(dev)
was successful, does it?
Umm, it does. If pci_enable_device wasn't successful, it returns -ENODEV.
Your patch below calls pci_set_master if enabling the device fails and
then
1 - 100 of 125 matches
Mail list logo
