Andriy Gapon пишет:
If you have a system with SB600, SB700, etc chipset and you have problems with
low
speed USB devices attached during boot (keyboard, mouse), could you please try
the
following experimental patch and report back?
I am primarily interested in the first several lines produced d
on 28/09/2009 17:10 John Baldwin said the following:
> On Monday 28 September 2009 9:55:44 am Andriy Gapon wrote:
>> on 28/09/2009 14:48 John Baldwin said the following:
>>> I don't think you can do this because it is a "feature" to not disable SMM
>>> if
>>> ohci(4) is not loaded so that a USB k
On Monday 28 September 2009 9:55:44 am Andriy Gapon wrote:
> on 28/09/2009 14:48 John Baldwin said the following:
> > I don't think you can do this because it is a "feature" to not disable SMM
> > if
> > ohci(4) is not loaded so that a USB keyboard works when the USB driver
> > isn't
> > loaded
on 28/09/2009 14:48 John Baldwin said the following:
> I don't think you can do this because it is a "feature" to not disable SMM if
> ohci(4) is not loaded so that a USB keyboard works when the USB driver isn't
> loaded via PS/2 emulation, even when the OS is running.
Very good point.
> I am c
On Sunday 27 September 2009 9:10:21 am Andriy Gapon wrote:
> on 27/09/2009 15:17 Andriy Gapon said the following:
> > Another idea of working around this:
> > 1) in pci fixup code disable USB SMI for these chipsets
> > 2) (optional) in ohci code skip takeover step
> > Sounds messy.
>
> BTW, just f
on 27/09/2009 16:10 Andriy Gapon said the following:
> kernel: ohci_controller_init:195: SMM active, request owner change
> kernel: usbus0: SMM does not respond, resetting
> kernel: ohci_controller_init:195: SMM active, request owner change
> kernel: usbus1: SMM does not respond, resetting
> kerne
on 27/09/2009 15:17 Andriy Gapon said the following:
> Another idea of working around this:
> 1) in pci fixup code disable USB SMI for these chipsets
> 2) (optional) in ohci code skip takeover step
> Sounds messy.
BTW, just for the sake of experiment I did exactly what I suggested.
I've got the fo
on 25/09/2009 10:28 Hans Petter Selasky said the following:
> On Friday 25 September 2009 08:34:21 Andriy Gapon wrote:
>> Not sure how to interpret this.
>
> In ohci_controller_init() try to disable the
>
> DPRINTF("SMM active, request owner change\n");
>
> part of the code for !(ohci_unit == 0
This patch works for me, I get..
usbus0: 12Mbps Full Speed USB v1.0
(hw power) control head <= 0xcfdf1c50
(hw power) control head => 0x3f7a000
usbus1: 12Mbps Full Speed USB v1.0
(hw power) control head <= 0x3dd6000
(hw power) control head => 0x3dd6000
usbus2: 480Mbps High Speed USB v2.0
usbus3: 12
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andriy Gapon wrote:
> on 25/09/2009 11:02 Svein Skogen (listmail account) said the following:
>> Andriy Gapon wrote:
>>> on 24/09/2009 17:51 Hans Petter Selasky said the following:
>> *SNIP!*
>>
>>> Not sure how to interpret this.
>>> Either a timing i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andriy Gapon wrote:
> on 24/09/2009 17:51 Hans Petter Selasky said the following:
*SNIP!*
>
> Not sure how to interpret this.
> Either a timing issue, i.e. the register gets over-written some time after we
> program it.
> Or perhaps a bug in SMM cod
on 25/09/2009 11:02 Svein Skogen (listmail account) said the following:
> Andriy Gapon wrote:
>> on 24/09/2009 17:51 Hans Petter Selasky said the following:
>
> *SNIP!*
>
>> Not sure how to interpret this.
>> Either a timing issue, i.e. the register gets over-written some time after we
>> program
On Friday 25 September 2009 08:34:21 Andriy Gapon wrote:
> Not sure how to interpret this.
In ohci_controller_init() try to disable the
DPRINTF("SMM active, request owner change\n");
part of the code for !(ohci_unit == 0) or (ohci_unit == 2) and see what
happens.
Your clue might also indicate
on 24/09/2009 17:51 Hans Petter Selasky said the following:
>
> Your patch looks good. Send me the final version when it is ready and testers
> report OK. I will then review and commit it.
>
> I think that if you need to reload the control head, you will also need to
> reload the other head lis
On Wednesday 23 September 2009 16:54:41 Andriy Gapon wrote:
> If you have a system with SB600, SB700, etc chipset and you have problems
> with low speed USB devices attached during boot (keyboard, mouse), could
> you please try the following experimental patch and report back?
> I am primarily inte
On Thu, 24 Sep 2009 09:38:36 +0300, Andriy Gapon wrote:
BTW, how many ports do you have at the back?
If more than 2, could you please try connecting the mouse to a port that is not
connected to uhub0 (this could be verified with usbconfig)?
And then see if you still get a mouse attachment proble
on 25/09/2009 01:31 Andrius Morkūnas said the following:
> usbus0: 12Mbps Full Speed USB v1.0
> (hw power) control head <= 0xcfef1e30
> (hw power) control head => 0x2329000
> usbus1: 12Mbps Full Speed USB v1.0
> (hw power) control head <= 0xcfef1e40
> (hw power) control head => 0x4143000
These we
On Friday 25 September 2009 00:31:17 Andrius Morkūnas wrote:
> On Wed, 23 Sep 2009 17:54:41 +0300, Andriy Gapon wrote:
> > If you have a system with SB600, SB700, etc chipset and you have problems
> > with low speed USB devices attached during boot (keyboard, mouse), could
> > you please try the f
On Wed, 23 Sep 2009 17:54:41 +0300, Andriy Gapon wrote:
If you have a system with SB600, SB700, etc chipset and you have problems with
low
speed USB devices attached during boot (keyboard, mouse), could you please try
the
following experimental patch and report back?
I am primarily interested
If you have a system with SB600, SB700, etc chipset and you have problems with
low
speed USB devices attached during boot (keyboard, mouse), could you please try
the
following experimental patch and report back?
I am primarily interested in the first several lines produced during boot with
print
20 matches
Mail list logo
