On Fri, 12 Jan 2001, Nick Hibma wrote:
If you could send me the make and model (basically all the numbers
(including the FCC one) on the label on the device, that would be
appreciated.
Heh, this is some imported piece of junk. There is no FCC id. All the text on
the adapter says is:
PS-PC
First of all, you are not wasting my time (I _asked_ for the info,
right?). More probably it is the other way around with you having to
crash you machine all the time ... :-)
Second the info your supplying is good quality. Thanks for that.
I'll have a look after the weekend (I'll try and not
Oh, and another thing: a kernel panicing is unacceptable, even with bad
hardware (except possibly for hardware faults. There is not a lot you
can do about those).
We've found one non-trivial bug, and I have the feeling that we are
looking at another one (possibly a stack or device list
On Mon, 8 Jan 2001, Nick Hibma wrote:
Just as a note on the side, the fact that the attach of the generic
driver fails (while setting config 0, which is a sort of a soft
reset) could indicate that there is something fishy going on with
respect to fetching the report descriptor. I seems to
On Sun, 7 Jan 2001, Nick Hibma wrote:
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
On Sun, 7 Jan 2001, Nick Hibma wrote:
Jon, could you try the attached patch and tell me whether that works for
you?
Unfortunately, no. The probe messages differ, but it still panics.
This is 4.2-RELEASE, I can try something more recent if it'll get you any
better details.
uhci0: Intel
uhid0: vendor 0x product 0x0667, rev 1.00/2.88, addr 2, iclass 3/0
uhid0: no report descriptor
device_probe_and_attach: uhid0 attach returned 6
ugen0: vendor 0x product 0x0667, rev 1.00/2.88, addr 2
ugen0: setting configuration index 0 failed
device_probe_and_attach: ugen0 attach
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
The panic is definitely bad. It happens straight after failing the
attach?
If you could recompile the kernel with
options DDB
makeoptions DEBUG=-g
plug the device in again, and after it has panicked (it will drop into
the debugger), type trace. That would give me a
On 30-Dec-00 Nick Hibma wrote:
For identifying what this is, there's not a lot of info available. It shows
up in Windows as a "Monster Gamepad" with 4 analog axis and 16 buttons, and
just has a single 20 pin DIPP chip inside with these markings (looks like a
PLA to me):
CY7C63000A-PC
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
I've got a little USB device that allows Playstation controllers to be
used on a PC. If it's plugged in while booting FreeBSD 4.2-RELEASE (the
shipped GENERIC kernel), I get:
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd400-0xd41f irq 3 at
device 4.2 on pci0
usb0: Intel 82371AB/EB
On Fri, Nov 24, 2000 at 04:23:25PM -0800, Jon Simola wrote:
After poking around in the uhid and usb code, I'm beginning to think that
this adapter is just broken by design. Can someone a bit more familiar
with the USB stuff comment on that? Thanks.
For identifying what this is, there's not
13 matches
Mail list logo
