Vojtech Pavlik wrote:
> Oops? I thought the paired controller there is for OSes not being able
> to handle EHCI yet? So that USB works even for those ... I think EHCI
> should handle even 1.x devices ... I may be wrong, though.
Check the Intel EHCI spec. Esp. the chapter about port handover...
On Mon, Nov 20, 2000 at 01:37:23PM +0100, Thomas Sailer wrote:
> > I hope EHCI makes it all moot. Some way or another.
>
> Only for USB2 devices. EHCI is supposed to be paired with an existing
> UHCI or OHCI controller core that is supposed to take over the USB connector
> if an USB 1.x hub or
On Mon, Nov 20, 2000 at 01:37:23PM +0100, Thomas Sailer wrote:
I hope EHCI makes it all moot. Some way or another.
Only for USB2 devices. EHCI is supposed to be paired with an existing
UHCI or OHCI controller core that is supposed to take over the USB connector
if an USB 1.x hub or device
Vojtech Pavlik wrote:
Oops? I thought the paired controller there is for OSes not being able
to handle EHCI yet? So that USB works even for those ... I think EHCI
should handle even 1.x devices ... I may be wrong, though.
Check the Intel EHCI spec. Esp. the chapter about port handover...
Linus Torvalds wrote:
> I'd disagree. UHCI has tons of advantages, not the least of which is
> [Cthat it was there first and is widely available. If OHCI hadn't been
> done we'd have _one_ nice good USB controller implementation instead of
UHCI has a couple of disadvantages, though (and some
Linus Torvalds wrote:
I'd disagree. UHCI has tons of advantages, not the least of which is
[Cthat it was there first and is widely available. If OHCI hadn't been
done we'd have _one_ nice good USB controller implementation instead of
UHCI has a couple of disadvantages, though (and some of
Hi!
> >One note for the archives, if you are presented a choice between a OHCI
> >or a UHCI controller, go for the OHCI. It has a "cleaner" interface,
> >handles more of the logic in the silicon, and due to this provides
> >faster transfers.
>
> I'd disagree. UHCI has tons of advantages, not
Hi!
One note for the archives, if you are presented a choice between a OHCI
or a UHCI controller, go for the OHCI. It has a "cleaner" interface,
handles more of the logic in the silicon, and due to this provides
faster transfers.
I'd disagree. UHCI has tons of advantages, not the least
In article <[EMAIL PROTECTED]>, Greg KH <[EMAIL PROTECTED]> wrote:
>On Fri, Nov 17, 2000 at 11:25:50PM -0800, Ben Ford wrote:
>> Here is lspci output from the laptop in question. Is this not UHCI?
>
>Yes it is. Just a bit funny if you think about it, but with Intel and
>Via putting the UHCI
In article [EMAIL PROTECTED], Greg KH [EMAIL PROTECTED] wrote:
On Fri, Nov 17, 2000 at 11:25:50PM -0800, Ben Ford wrote:
Here is lspci output from the laptop in question. Is this not UHCI?
Yes it is. Just a bit funny if you think about it, but with Intel and
Via putting the UHCI core into
On Fri, Nov 17, 2000 at 11:25:50PM -0800, Ben Ford wrote:
> Here is lspci output from the laptop in question. Is this not UHCI?
Yes it is. Just a bit funny if you think about it, but with Intel and
Via putting the UHCI core into their chipsets I guess it makes sense.
One note for the
Here is lspci output from the laptop in question. Is this not UHCI?
[ben@Juanita ben]$ /sbin/lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel
On Fri, Nov 17, 2000 at 09:27:19PM -0800, David Ford wrote:
>
> The second issue is usb. I now have two machines that lockup on boot in USB.
> One is the above workstation, the second is a Compaq laptop. Unfortunately
> I have no way of unplugging the USB hardware inside the laptop :P
Can't
> > The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
> > difficult because the lockups appear to be kdb-specific (and kdb itself
[...]
> It could be that -test5 and -test6 break some assumption kdb makes.
> It has been eminently stable here.
Whether or not the
On Fri, 17 Nov 2000 20:00:49 + (GMT),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
>difficult because the lockups appear to be kdb-specific (and kdb itself
>goes mad) but when there is no kdb there is very little useful
On Fri, 17 Nov 2000 20:00:49 + (GMT),
Tigran Aivazian <[EMAIL PROTECTED]> wrote:
>The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
>difficult because the lockups appear to be kdb-specific (and kdb itself
>goes mad) but when there is no kdb there is very little useful
Followup to: <[EMAIL PROTECTED]>
By author:Tigran Aivazian <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Hi,
>
> The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
> difficult because the lockups appear to be kdb-specific (and kdb itself
> goes mad) but when
Hi,
The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
difficult because the lockups appear to be kdb-specific (and kdb itself
goes mad) but when there is no kdb there is very little useful information
one can extract from a dead system...
I will start removing kernel
On Fri, 17 Nov 2000 20:00:49 + (GMT),
Tigran Aivazian [EMAIL PROTECTED] wrote:
The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
difficult because the lockups appear to be kdb-specific (and kdb itself
goes mad) but when there is no kdb there is very little useful
Hi,
The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
difficult because the lockups appear to be kdb-specific (and kdb itself
goes mad) but when there is no kdb there is very little useful information
one can extract from a dead system...
I will start removing kernel
Followup to: [EMAIL PROTECTED]
By author:Tigran Aivazian [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Hi,
The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
difficult because the lockups appear to be kdb-specific (and kdb itself
goes mad) but when there is
On Fri, 17 Nov 2000 20:00:49 + (GMT),
Tigran Aivazian [EMAIL PROTECTED] wrote:
The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
difficult because the lockups appear to be kdb-specific (and kdb itself
goes mad) but when there is no kdb there is very little useful
The mysterious lockups in test11-pre5 continue in test11-pre6. It is very
difficult because the lockups appear to be kdb-specific (and kdb itself
[...]
It could be that -test5 and -test6 break some assumption kdb makes.
It has been eminently stable here.
Whether or not the assumptions
On Fri, Nov 17, 2000 at 09:27:19PM -0800, David Ford wrote:
The second issue is usb. I now have two machines that lockup on boot in USB.
One is the above workstation, the second is a Compaq laptop. Unfortunately
I have no way of unplugging the USB hardware inside the laptop :P
Can't you
Here is lspci output from the laptop in question. Is this not UHCI?
[ben@Juanita ben]$ /sbin/lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel
On Fri, Nov 17, 2000 at 11:25:50PM -0800, Ben Ford wrote:
Here is lspci output from the laptop in question. Is this not UHCI?
Yes it is. Just a bit funny if you think about it, but with Intel and
Via putting the UHCI core into their chipsets I guess it makes sense.
One note for the archives,
26 matches
Mail list logo
