Re: 8.0-RC USB/FS problem

2009-11-25 Thread Hans Petter Selasky
On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote:
 What other debug shall we turn on to analyze this problem.

Are you able to extract the panic message? Try enabling dump on the swap 
partition.

--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


Re: [keyboard] ukbd stops working after filesystems mount at boot time

2009-11-25 Thread Travelling Particle
 Does this let you work around your problem too?

 http://www.freebsd.org/cgi/getmsg.cgi?fetch=0+0+/usr/local/www/db/text/2008/freebsd-mobile/20080309.freebsd-mobile

Haven't tried the patch, but I see what you mean. I had tested with
atkbd and kbdmux both disabled and having geli passphrase visible.
It appears that in 8.0-PRERELEASE (cvsuped Nov 23 2009, I think) the
original problem I had reported is gone: if I can get thru the
passphrase, the late stage continues fine and keyboard works at login
prompt without any problem. However, the keyboard works unreliably(*)
just before the late boot stage, at the moment when the geli
passphrase is expected. 8.0-RC3 behaved the opposite way: no problem
at the passphrase, but unusable console right after that.

(*) By working unreliably I mean that key presses are randomly
skipped. Sometimes you see keys pressed right after the first press,
sometimes it takes 3-4 times to repeat the press before the symbol
gets entered.

I have googled up that skipping key presses at the passphrase prompt
was reported since a long time ago. I see that it was somewhat fixed
in 8.0-RC3 with undesired side-effects. This leaves me wonder if the
keyboard can be fixed without breaking the console. I am willing to
help: if anyone needs debugging output or anything, just tell me what
I should do. USB keyboard is the only input device this computer has
(no PS/2 or serial port), so I' somewhat desperate.

 Chances are that unreliable key inputs at boot stage is not that
 usb specific, but I couldn't dig any deeper then...

I think it's usb-specific. What else would be responsible for dropping
input from the usb device?

Thanks.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


Re: [keyboard] ukbd stops working after filesystems mount at boot time

2009-11-25 Thread Hiroharu Tamaru
Hi

At Wed, 25 Nov 2009 15:14:01 +0300, Travelling Particle wrote:
  Does this let you work around your problem too?
 
  http://www.freebsd.org/cgi/getmsg.cgi?fetch=0+0+/usr/local/www/db/text/2008/freebsd-mobile/20080309.freebsd-mobile
 
 Haven't tried the patch, but I see what you mean. I had tested with
 atkbd and kbdmux both disabled and having geli passphrase visible.
 It appears that in 8.0-PRERELEASE (cvsuped Nov 23 2009, I think) the
 original problem I had reported is gone: if I can get thru the
 passphrase, the late stage continues fine and keyboard works at login
 prompt without any problem. However, the keyboard works unreliably(*)
 just before the late boot stage, at the moment when the geli
 passphrase is expected. 8.0-RC3 behaved the opposite way: no problem
 at the passphrase, but unusable console right after that.
 
 (*) By working unreliably I mean that key presses are randomly
 skipped. Sometimes you see keys pressed right after the first press,
 sometimes it takes 3-4 times to repeat the press before the symbol
 gets entered.
 
 I have googled up that skipping key presses at the passphrase prompt
 was reported since a long time ago. I see that it was somewhat fixed
 in 8.0-RC3 with undesired side-effects. This leaves me wonder if the
 keyboard can be fixed without breaking the console. I am willing to
 help: if anyone needs debugging output or anything, just tell me what
 I should do. USB keyboard is the only input device this computer has
 (no PS/2 or serial port), so I' somewhat desperate.
 
  Chances are that unreliable key inputs at boot stage is not that
  usb specific, but I couldn't dig any deeper then...
 
 I think it's usb-specific. What else would be responsible for dropping
 input from the usb device?

BIOS or something alike, or some non-interrupt driven
method, or some interrupt mechanism itself?

Back then, I wondered if the kernel used BIOS or any of the
above, that probably is different from how the device is
driven after the boot stage is finalized, but I never
reached the actual code to know it myself.  I'd appreciate
if someone can confirm it either way.

Anyway, in my case, I was using atkbd, and not ukbd, and it
was just that I thought if it were really the BIOS, the same
work around may help.

Anyway, reading your description above, more than one thing
is probably involved, so just take what I wrote as my wild
guess at best.  I wish I knew the kernel better not to guess
a lot like this, of course...

So, the ball is back on the side of the experts here ;-p

 Thanks.
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


uhci_interrupt: host controller halted

2009-11-25 Thread Bukin Ruslan
hello,

i have about 1000 UHCI_STS_HCH intrr per second:

Nov 25 19:55:27 br kernel: uhci_interrupt:1506: uhci_interrupt: host controller 
halted
Nov 25 19:55:27 br kernel: uhci_dumpregs:741: usbus2 regs: cmd=0080, sts=0020, 
intr=000f, frnum=01c9, flbase=01a23724, sof=0040, portsc1=0080, portsc2=0080
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073005000) at 
0x01a24002: h_next=0x01a25002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073006000) at 
0x01a25002: h_next=0x01a26002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073007000) at 
0x01a26002: h_next=0x01a27002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073008000) at 
0x01a27002: h_next=0x0001 e_next=0x01a28000
Nov 25 19:55:27 br kernel: uhci_interrupt:1506: uhci_interrupt: host controller 
halted
Nov 25 19:55:27 br kernel: uhci_dumpregs:741: usbus2 regs: cmd=0080, sts=0020, 
intr=000f, frnum=01c9, flbase=01a23724, sof=0040, portsc1=0080, portsc2=0080
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073005000) at 
0x01a24002: h_next=0x01a25002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073006000) at 
0x01a25002: h_next=0x01a26002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073007000) at 
0x01a26002: h_next=0x01a27002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073008000) at 
0x01a27002: h_next=0x0001 e_next=0x01a28000
Nov 25 19:55:27 br kernel: uhci_interrupt:1506: uhci_interrupt: host controller 
halted
Nov 25 19:55:27 br kernel: uhci_dumpregs:741: usbus2 regs: cmd=0080, sts=0020, 
intr=000f, frnum=01c9, flbase=01a23724, sof=0040, portsc1=0080, portsc2=0080
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073005000) at 
0x01a24002: h_next=0x01a25002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073006000) at 
0x01a25002: h_next=0x01a26002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073007000) at 
0x01a26002: h_next=0x01a27002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073008000) at 
0x01a27002: h_next=0x0001 e_next=0x01a28000
Nov 25 19:55:27 br kernel: uhci_interrupt:1506: uhci_interrupt: host controller 
halted
Nov 25 19:55:27 br kernel: uhci_dumpregs:741: usbus2 regs: cmd=0080, sts=0020, 
intr=000f, frnum=01c9, flbase=01a23724, sof=0040, portsc1=0080, portsc2=0080
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073005000) at 
0x01a24002: h_next=0x01a25002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073006000) at 
0x01a25002: h_next=0x01a26002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073007000) at 
0x01a26002: h_next=0x01a27002 e_next=0x0001
Nov 25 19:55:27 br kernel: uhci_dump_qh:814: QH(0xff8073008000) at 
0x01a27002: h_next=0x0001 e_next=0x01a28000
Nov 25 19:55:27 br kernel: uhci_interrupt:1506: uhci_interrupt: host controller 
halted

is this normal?

kern.version: FreeBSD 9.0-CURRENT #6: Wed Nov 25 06:48:28 UTC 2009

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


RE: 8.0-RC USB/FS problem

2009-11-25 Thread Guojun Jin
I will do,

I also borrowed two other machiens -- one AMD two core laptop, and one P4 
desktop -- for further testing.
I will enable kernel coredump for all of them and will make cores available by 
end of today.

-Jin

-Original Message-
From: Hans Petter Selasky [mailto:hsela...@c2i.net]
Sent: Wed 11/25/2009 12:37 AM
To: Guojun Jin
Cc: freebsd-usb@freebsd.org; b...@freebsd.org; freebsd-sta...@freebsd.org
Subject: Re: 8.0-RC USB/FS problem
 
On Wednesday 25 November 2009 00:08:59 Guojun Jin wrote:
 What other debug shall we turn on to analyze this problem.

Are you able to extract the panic message? Try enabling dump on the swap 
partition.

--HPS

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


Re: uhci_interrupt: host controller halted

2009-11-25 Thread Hans Petter Selasky
On Wednesday 25 November 2009 18:08:32 Bukin Ruslan wrote:
 hello,

 i have about 1000 UHCI_STS_HCH intrr per second:



 is this normal?

No, it is not normal. Maybe this happens because the interrupt line is shared. 
What does vmstat -i say?

--HPS

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org



Re: uhci_interrupt: host controller halted

2009-11-25 Thread Bukin Ruslan
On Wed, Nov 25, 2009 at 06:55:57PM +0100, Hans Petter Selasky wrote:
 On Wednesday 25 November 2009 18:08:32 Bukin Ruslan wrote:
  hello,
 
  i have about 1000 UHCI_STS_HCH intrr per second:
 
 
 
  is this normal?
 
 No, it is not normal. Maybe this happens because the interrupt line is 
 shared. 
 What does vmstat -i say?
 
 --HPS

#vmstat -i
interrupt  total   rate
irq1: atkbd03527  6
irq9: acpi0  741  1
irq16: uhci2+  82402150
irq20: uhci0  13  0
irq21: uhci13303  6
irq22: ehci0   3  0
cpu0: timer  1090324   1996
irq256: em0 3514  6
irq257: hdac0  72093132
cpu1: timer  1090197   1996
irq258: vgapci0 4535  8
Total2350652   4305

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org


Re: uhci_interrupt: host controller halted

2009-11-25 Thread Hans Petter Selasky
On Wednesday 25 November 2009 19:21:43 Bukin Ruslan wrote:
 On Wed, Nov 25, 2009 at 06:55:57PM +0100, Hans Petter Selasky wrote:
  On Wednesday 25 November 2009 18:08:32 Bukin Ruslan wrote:
   hello,
  
   i have about 1000 UHCI_STS_HCH intrr per second:
  
  
  
   is this normal?
 
  No, it is not normal. Maybe this happens because the interrupt line is
  shared. What does vmstat -i say?
 
  --HPS

 #vmstat -i
 interrupt  total   rate
 irq1: atkbd03527  6
 irq9: acpi0  741  1
 irq16: uhci2+  82402150
 irq20: uhci0  13  0
 irq21: uhci13303  6
 irq22: ehci0   3  0
 cpu0: timer  1090324   1996
 irq256: em0 3514  6
 irq257: hdac0  72093132
 cpu1: timer  1090197   1996
 irq258: vgapci0 4535  8
 Total2350652   4305

Hi,

There should be some code so that the UHCI only prints this message once. 
Thought it looks like the IRQ is shared so the message is printed multiple 
times.

--HPS

___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org