Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Jan 2001 14:31:02 +0000 (GMT)
From:      Nick Hibma <n_hibma@calcaphon.com>
To:        Jon Simola <jon@abccom.bc.ca>, Doug Rabson <dfr@qubesoft.com>
Cc:        FreeBSD Hackers Mailing List <hackers@FreeBSD.ORG>
Subject:   Re: Broken-by-design USB device?
Message-ID:  <Pine.BSF.4.20.0101071347190.17540-200000@henny.webweaving.org>
In-Reply-To: <Pine.BSF.3.96.1010102110053.462F-100000@newmail.netbistro.com>

next in thread | previous in thread | raw e-mail | index | archive | help
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--0-1089154843-978875662=:17540
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.BSF.4.20.0101071354271.17540@henny.webweaving.org>


There is, I think, at least a bug in subr_bus.c that might cause this,
although, this is just a hunch. I've not been able to explain what's
happening yet.

What is happening is that device_probe_child sets the device class, and
in case of an error unsets it. But in this case attach (instead of
probe) returns an error and hence the devclass _should_ be unset for
that device (it didn't have a devclass to start with) to force it back
to its virgin state, but isn't.

If you could review his patch dfr, that would be appreciated.

This is an issue in current as well.


Jon, could you try the attached patch and tell me whether that works for
you?

Cheers,

Nick


On Tue, 2 Jan 2001, Jon Simola wrote:

> On Sat, 30 Dec 2000, Nick Hibma wrote:
> 
> > The panic is definitely bad. It happens straight after failing the
> > attach?
> 
> Yep, but only during the kernel boot. Hot plugging the device after the system
> is booted spews the same errors to the console but does not cause a panic:
> 
> uhid0: no report descriptor
> device_probe_and_attach: uhid0 attach returned 6
> 
> > plug the device in again, and after it has panicked (it will drop into
> > the debugger), type trace. That would give me a hint at where it
> > crashes.
> 
> Here you go. If you need anything else, please ask.
> 
> kernel: type 12 trap, code=0
> Stopped at      DEVICE_PROBE+0xe:       cmpl    0(%edx),%eax
> db> trace
> DEVICE_PROBE(c1142d00,c1142d00,c1139100,0,0) at DEVICE_PROBE+0xe
> device_probe_child(c1139100,c1142d00,c1142e00,0,c1142e30) at
> device_probe_child+0xc1
> device_probe_and_attach(c1142d00) at device_probe_and_attach+0x29
> usbd_probe_and_attach(c1139100,c1142e00,2,3,c1142e00) at
> usbd_probe_and_attach+0xef
> usbd_new_device(c1139100,c113a000,1,200,2,c11390c0) at usbd_new_device+0x1dd
> uhub_explore(c1139280,c1139300,c1139e80,0,c0456e64) at uhub_explore+0x1d4
> usb_attach(c1139300,c0456e7c,c01afc0b,c1139300,c113a000) at usb_attach+0xf1
> DEVICE_ATTACH(c1139300,c113a000,c1139e80,0,c0456ea0) at DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1139300) at device_probe_and_attach+0x4f
> uhci_pci_attach(c1139e80,c0456ec4,c01afc0b,c1139e80,c1139e80) at
> uhci_pci_attach+0x33f
> DEVICE_ATTACH(c1139e80,c1139e80,c1136400,0,c0456ed4) at DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1139e80) at device_probe_and_attach+0x4f
> bus_generic_attach(c1136380,c0456ef8,c01afc0b,c1136380,c1136380) at
> bus_generic_attach+0x16
> DEVICE_ATTACH(c1136380,c1136380,c1136580,0,c0456f08) at DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1136380) at device_probe_and_attach+0x4f
> bus_generic_attach(c1136400,c0456f2c,c01afc0b,c1136400,c1136400) at
> bus_generic_attach+0x16
> DEVICE_ATTACH(c1136400,c1136400,c0e25800,0,c0456f3c) at DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1136400) at device_probe_and_attach+0x4f
> bus_generic_attach(c1136580,c1136580,c0456f58,c012740e,c1136580) at
> bus_generic_attach+0x16
> nexus_attach(c1136580,c0456f70,c01afc0b,c1136580,c1136580) at nexus_attach+0xd
> DEVICE_ATTACH(c1136580,c1136580,c039a710,45b000,c0456f80) at
> DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1136580) at device_probe_and_attach+0x4f
> root_bus_configure(c0e25800,c036d38c,0) at root_bus_configure+0x16
> configure(0,454c00,45b000,0,c0126df4) at configure+0x33
> mi_startup(c0456fb4,b0206,ffe,45b000,c01b42f9) at mi_startup+0x70
> begin() at begin+0x4b
> 
> > The controller probably requires some work because a fake report
> > descriptor is needed to make it possible for the uhid driver to talk to
> > it. It does not provide any information on where the information for the
> > buttons and axes is stored in the descriptor returned on the interrupt
> > pipe.
> 
> ---
> Jon Simola <jon@abccom.bc.ca> | "In the near future - corporate networks
>     Systems Administrator     |  reach out to the stars, electrons and light 
>      ABC  Communications      |  flow throughout the universe." -- GITS
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

--
Qube Software, Ltd.                                             Private:
n_hibma@qubesoft.com                              n_hibma@webweaving.org
                                                     n_hibma@freebsd.org
http://www.qubesoft.com/                   http://www.etla.net/~n_hibma/

--0-1089154843-978875662=:17540
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="subr_bus.c.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.4.20.0101071354220.17540@henny.webweaving.org>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME="subr_bus.c.patch"

SW5kZXg6IHN1YnJfYnVzLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD
UyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMva2Vybi9zdWJyX2J1cy5jLHYN
CnJldHJpZXZpbmcgcmV2aXNpb24gMS41NC4yLjcNCmRpZmYgLXUgLXIxLjU0
LjIuNyBzdWJyX2J1cy5jDQotLS0gc3Vicl9idXMuYwkyMDAwLzA4LzAzIDA2
OjM2OjM4CTEuNTQuMi43DQorKysgc3Vicl9idXMuYwkyMDAxLzAxLzA3IDEz
OjUxOjE1DQpAQCAtMTE0MCw2ICsxMTQwLDcgQEANCiB7DQogICAgIGRldmlj
ZV90IGJ1cyA9IGRldi0+cGFyZW50Ow0KICAgICBpbnQgZXJyb3IgPSAwOw0K
KyAgICBpbnQgaGFzY2xhc3MgPSAoZGV2LT5kZXZjbGFzcyAhPSAwKTsNCiAN
CiAgICAgaWYgKGRldi0+c3RhdGUgPj0gRFNfQUxJVkUpDQogCXJldHVybiAw
Ow0KQEAgLTExNTUsNiArMTE1Niw5IEBADQogCSAgICBlbHNlIHsNCiAJCXBy
aW50ZigiZGV2aWNlX3Byb2JlX2FuZF9hdHRhY2g6ICVzJWQgYXR0YWNoIHJl
dHVybmVkICVkXG4iLA0KIAkJICAgICAgIGRldi0+ZHJpdmVyLT5uYW1lLCBk
ZXYtPnVuaXQsIGVycm9yKTsNCisJCS8qIFVuc2V0IHRoZSBjbGFzcyB0aGF0
IHdhcyBzZXQgaW4gZGV2aWNlX3Byb2JlX2NoaWxkICovDQorCQlpZiAoIWhh
c2NsYXNzKQ0KKwkJICAgIGRldmljZV9zZXRfZGV2Y2xhc3MoZGV2LCAwKTsN
CiAJCWRldmljZV9zZXRfZHJpdmVyKGRldiwgTlVMTCk7DQogCQlkZXYtPnN0
YXRlID0gRFNfTk9UUFJFU0VOVDsNCiAJICAgIH0NCg==
--0-1089154843-978875662=:17540--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.0101071347190.17540-200000>