Re: SiS 7002 lockup using USB2.0 'legacy' mode
Hi J.C.,
wow, thanks for all the work and explanation!
On Sun, 7 Mar 2010 16:56:26 -0800 J.C. Roberts wrote:
On Sun, 7 Mar 2010 22:31:18 +0100 Christopher Zimmermann
madro...@zakweb.de wrote:
ok, you misunderstood me. My BIOS needs 'legacy' to be turned on to
use the USB-keyboard.
Yep, you weren't clear on legacy as meaning Legacy USB Support but
I was able to dig up a possibly similar/correct manual. According to
Asus, K8S-MV as seen in your dmesg, doesn't exist. The closest I
found was K8S-MX
Yes, it says K8S-MV on the board, but it looks like the K8S-MX.
The bios menu is not the same, but similar.
http://dlsvr.asus.com/pub/ASUS/mb/sock754/k8s-mx/e1884_k8s-mx.pdf
Page 56 (2-20) of the above looks kind of like what you've described.
Does your BIOS have the very strange option of:
Stop EHCI HC in OHCI handover [Disabled] [Enabled]
as shown in the (possibly wrong) manual I found?
Yes, I have this option, but it makes no difference to what value I
set it.
Additionally, one of the possible reasons why your keyboard and
mouse
will not work without Legacy USB Support and/or OnBoard SiS USB 1.1
DEVICE enabled is because they are plugged into the wrong port. In
other words you've shut off the Host Controller (SiS 5597/5598) for
the port (s) where your mouse and keyboard are plugged in.
As I understand it, the 'legacy' option just means the bios should
talk to USB devices (like my keyboard). Turning it off means the BIOS
won't touch my host controler nor my keyboard.
When I turn off the 'legacy' option everything works fine. The code in
OpenBSD which is waiting for BIOS to give up control will then not
even be executed (see dev/pci/ehci_pci.c). The relevant register bits
are even called EHCI_LEGSUP_BIOSOWNED and EHCI_LEGSUP_OSOWNED.
You see, LEG like in LEGacy.
Is the kernel locked up? --Possibly No. The kernel may be
ignoring
the USB mouse/keyboard that you specifically told the bios to
ignore by turning on Legacy Mode. When the BIOS tells the kernel
that it has no mouse or keyboard installed, then the kernel
thinks, Ah, we're running headless, and adjusts accordingly.
the kernel stops while booting. Read my orignal post again. I found
the very line of code causing this problem, but still don't know
exactly how to fix it.
The (possibly wrong) manual I found has that very weird BIOS option
for OHCI to EHCI handover. If your system has something similar, then
this *might* be the root of your problem. If OHCI refuses to
handover to EHCI, then it could explain why EHCI is waiting around
for the BIOS to give up control.
As said above, this option does not change the behavior. Now I tried
to port the way, linux protects this section where the driver tries to
take port ownership. Still it did not fix the lockup. The patch is
attached, if you are interested.
christopher
Index: dev/usb/ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.106
diff -u -p -r1.106 ehci.c
--- dev/usb/ehci.c 26 Nov 2009 12:27:48 - 1.106
+++ dev/usb/ehci.c 8 Mar 2010 08:44:51 -
@@ -81,7 +81,7 @@ struct cfdriver ehci_cd = {
#ifdef EHCI_DEBUG
#define DPRINTF(x) do { if (ehcidebug) printf x; } while(0)
#define DPRINTFN(n,x) do { if (ehcidebug(n)) printf x; } while (0)
-int ehcidebug = 0;
+int ehcidebug = 0x19;
#define bitmask_snprintf(q,f,b,l) snprintf((b), (l), %b, (q), (f))
#else
#define DPRINTF(x)
@@ -502,22 +502,49 @@ ehci_init(ehci_softc_t *sc)
EHCI_CMD_PSE |
EHCI_CMD_RS);
- /* Take over port ownership */
+ /* Take over port ownership
+ *
+ * Start, enabling full USB 2.0 functionality ... usb 1.1 devices
+ * are explicitly handed to companion controller(s), so no TT is
+ * involved with the root hub. (Except where one is integrated,
+ * and there's no companion controller unless maybe for USB OTG.)
+ *
+ * Turning on the CF flag will transfer ownership of all ports
+ * from the companions to the EHCI controller. If any of the
+ * companions are in the middle of a port reset at the time, it
+ * could cause trouble. Write-locking ehci_cf_port_reset_rwsem
+ * guarantees that no resets are in progress. After we set CF,
+ * a short delay lets the hardware catch up; new resets shouldn't
+ * be started before the port switching actions could complete.
+*
+* This explanation is taken from the Linux kernel 2.6.33
+* drivers/usb/host/ehci-hcd.c by David Brownell
+ */
+ rw_enter_write(ehci_cf_port_reset_rwlock);
+ DPRINTFN(2, (ehci: after lock\n));
+ delay(50);
+ DPRINTFN(2, (ehci: after delay1\n));
EOWRITE4(sc, EHCI_CONFIGFLAG, EHCI_CONF_CF);
+ delay(50);
+ DPRINTFN(2, (ehci: after
Re: faq14.html
J.C. Roberts wrote: Initially, I just wanted to fix the use create typo, but decided to make it shorter, more accurate, and more clear in the process. committed. btw: this is a good type of diff. Too often, people will spot the typo, correct the typo, and leave the rest of the section poorly worded and overly verbose. Nick. Index: faq14.html === RCS file: /cvs/www/faq/faq14.html,v retrieving revision 1.198 diff -N -u -p faq14.html --- faq14.html4 Mar 2010 01:14:13 - 1.198 +++ faq14.html7 Mar 2010 22:17:07 - @@ -2274,10 +2274,9 @@ You will, of course, be unable to test your work until USB bootable system. libGoing from IDE to USB interfaces:/b -As the media will be readable and writable from both USB and IDE -adapters, you can use create the media for booting in an IDE adapter but -maintain it in a USB adapter on a different machine (or the other way -around). +Since flash media can be readable and writable through USB, IDE and +other adapters, you can create bootable media with one type of adapter +but maintain or use it with another type of adapter. libMixing OpenBSD and other partitions on one device:/b OpenBSD treats the flash disk as any other disk so one can use
Re: SiS 7002 lockup using USB2.0 'legacy' mode
ok, I got it fixed.
Heres my theory of what went wrong:
My (broken) BIOS does not know how to hand over the ehci host
controller. Therefore the timeout.
Additionally when 'HiSpeed' is selected it turns on several System
Management Interupts in the ehci host controller and won't turn them
off when the kernel requests the handover.
Later, when the kernel sets the CF bit the host controller issues a
SMI to notify the BIOS of the ownership change of mouse and keyboard
from ohci to the ehci host controller. The BIOS does not seem to like
this and the kernel/BIOS freezes.
My fix simply clears all SMI_ENABLE bits in the USBLEGCTLSTS register
when the BIOS does not acknowledge the handover. This violates the
spec, because the USBLEGCTLSTS register is supposed to be used by the
BIOS, not the OS.
Still I'm wondering why the controller worked with Linux since I could
not find a similar piece of code in the Linux kernel.
The diff is attached. Further down you find my first attempt to fix
this by porting the writelock part from linux. I don't know whether
OpenBSD needs this.
cheers,
Christopher
Index: dev/pci/ehci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ehci_pci.c,v
retrieving revision 1.18
diff -u -p -r1.18 ehci_pci.c
--- dev/pci/ehci_pci.c 24 Jul 2009 03:18:58 - 1.18
+++ dev/pci/ehci_pci.c 8 Mar 2010 14:17:48 -
@@ -294,9 +294,26 @@ ehci_pci_takecontroller(struct ehci_pci_
break;
DELAY(1000);
}
- if (legsup EHCI_LEGSUP_BIOSOWNED)
- printf(%s: timed out waiting for BIOS\n,
+ if (legsup EHCI_LEGSUP_BIOSOWNED) {
+ /*
+* The BIOS on the Asus K8S-MV/P does not
+* release the semaphore in time and won't
+* turn of System management interrupts.
+* It will get confused by the SMIs caused
+* by port changes when the CF bit goes up.
+* Therefore we do the job of the BIOS and
+* turn off SMIs. The SMI control bits
+* are bits 0-15 at register eecp+0x04.
+* See the intel EHCI spec.
+*/
+ printf(%s: timed out waiting for BIOS
+- at least disable all SMIs.\n,
sc-sc.sc_bus.bdev.dv_xname);
+ legsup = pci_conf_read(sc-sc_pc, sc-sc_tag,
+ eecp + 0x04);
+ pci_conf_write(sc-sc_pc, sc-sc_tag,
+ eecp + 0x04, legsup 0x);
+ }
}
}
}
The folling diff is ported from the linux kernel.
It did not help my chipset, but didn't break anything either.
Index: dev/usb/usb.h
===
RCS file: /cvs/src/sys/dev/usb/usb.h,v
retrieving revision 1.35
diff -u -p -r1.35 usb.h
--- dev/usb/usb.h 1 Mar 2010 23:35:56 - 1.35
+++ dev/usb/usb.h 8 Mar 2010 14:11:01 -
@@ -688,3 +688,6 @@ struct usb_event {
#define USB_SET_CM_OVER_DATA _IOW ('U', 131, int)
#endif /* _USB_H_ */
+
+/* see ehci.c, usb_subr.h and usbdi.c */
+extern struct rwlock ehci_cf_port_reset_rwlock;
Index: dev/usb/usbdi.c
===
RCS file: /cvs/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.38
diff -u -p -r1.38 usbdi.c
--- dev/usb/usbdi.c 5 Mar 2010 17:28:54 - 1.38
+++ dev/usb/usbdi.c 8 Mar 2010 14:11:03 -
@@ -67,12 +67,16 @@ usbd_status usbd_open_pipe_ival(usbd_int
int usbd_nbuses = 0;
struct rwlock usbpalock;
+struct rwlock ehci_cf_port_reset_rwlock;
void
usbd_init(void)
{
- if (usbd_nbuses == 0)
+ if (usbd_nbuses == 0) {
rw_init(usbpalock, usbpalock);
+ rw_init(ehci_cf_port_reset_rwlock,
+ ehci_cf_port_reset_rwlock);
+ }
usbd_nbuses++;
}
Index: dev/usb/ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.106
diff -u -p -r1.106 ehci.c
--- dev/usb/ehci.c 26 Nov 2009 12:27:48 - 1.106
+++ dev/usb/ehci.c 8 Mar 2010 14:10:58 -
@@ -502,7 +502,25 @@ ehci_init(ehci_softc_t *sc)
EHCI_CMD_PSE |
EHCI_CMD_RS);
- /* Take over port ownership */
+ /* Take over port ownership
+ *
+ * Start, enabling full USB 2.0
su.1
That the option '-' is depreciated in favor of '-l' could be emphasized more. Index: su.1 === RCS file: /cvs/src/usr.bin/su/su.1,v retrieving revision 1.24 diff -u -p -r1.24 su.1 --- su.131 May 2007 19:20:17 - 1.24 +++ su.18 Mar 2010 20:02:22 - @@ -100,9 +100,9 @@ file (see The options are as follows: .Bl -tag -width Ds .It Fl -Same as the +(depreciated) Use the .Fl l -option (deprecated). +option instead. .It Fl a Ar auth-type Specify an authentication type such as .Dq skey ,
Re: su.1
On Mon, Mar 08, 2010 at 10:05:08PM +0200, Lars Nooden wrote: That the option '-' is depreciated in favor of '-l' could be emphasized more. it could be emphasised more. but we have a lot of pages using a fairly standard format (describe what option does, but note it is deprecated). we could talk about moving all pages to that format, but that's really another discussion. to be honest, i don;t see any immediate value to warrant such a change - i think it's enough to say we discourage its use. as to deprecate-depreciate. well, depreciate is not really correct. it's an oft-abused term, but it really just means that something has lost value. i guess we could argue that's a better description than deprecate, but that again is another argument. in summary, i don;t see this going in. jmc Index: su.1 === RCS file: /cvs/src/usr.bin/su/su.1,v retrieving revision 1.24 diff -u -p -r1.24 su.1 --- su.1 31 May 2007 19:20:17 - 1.24 +++ su.1 8 Mar 2010 20:02:22 - @@ -100,9 +100,9 @@ file (see The options are as follows: .Bl -tag -width Ds .It Fl -Same as the +(depreciated) Use the .Fl l -option (deprecated). +option instead. .It Fl a Ar auth-type Specify an authentication type such as .Dq skey ,
