Re: FreeBSD 4.3 crashing with USB hub attached...

2001-05-16 Thread Jon Simola

On Mon, 14 May 2001, Chris Dillon wrote:

> > Did you notice, before the crash, that the kernel had some trouble
> > querying the offending device?  That happens with me, and then a
> > little while later in the boot it crashes.
> 
> Yes, the symptoms were the same as yours.  The initial probing during
> boot took quite a while, and generated a few errors if I remember
> correctly, then a panic shortly afterwards.  I'm going to try my USB
> joypad on my own 4.3-STABLE box tonight and see if I encounter any
> problems, since I just got a new OHCI USB controller for it (I was
> having what I can only explain as EMI/RFI problems with my on-board
> USB controller).

I believe I had a similar problem back on 4.2-RELEASE with a PSX->USB adapter.
http://www.geocrawler.com/mail/thread.php3?subject=Broken-by-design+USB+device%3F&list=159

I sent the offending hardware off to Nick Hibma for him to look at, uh, 4
months ago. Is he back from vacation yet?

---
Jon Simola <[EMAIL PROTECTED]> | "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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: jail network problems

2000-10-30 Thread Jon Simola

On Sun, 29 Oct 2000, Stefan Aeschbacher wrote:

> I am running 4.1-stable updated ca 22.10.00.
> I set up a jail, started it but I have no network at all.
> I made an alias for the used IP address, I ran /etc/rc
> with the following output:



How are you starting the jail? I use this in my boot scripts (single line):

/usr/sbin/jail /u2/xxx.xxx.xxx.195 some.domain.com xxx.xxx.xxx.195 /bin/sh /etc/rc

> ping doesnt work from within the jail (I assume this is normal)

Yep, I was looking into that and the archives revealed that it was a
non-trivial fix for a minor problem.

> jail# telnet localhost - doesnt work
> jail# telnet some address - doesnt work
> some host# telnet jail - doesnt work
> some host# ping jail - doesnt work (should it?)
> 
> any hint?

If you can't ping the jail's IP from another machine, I'd suspect that the IP
isn't aliased properly. Here's what I've got setup in /etc/rc.conf:

ifconfig_fxp0="inet xxx.xxx.xxx.192  netmask 0xff00"
ifconfig_fxp0_alias0="inet xxx.xxx.xxx.193 netmask 0x"
ifconfig_fxp0_alias1="inet xxx.xxx.xxx.194 netmask 0xff00"
ifconfig_fxp0_alias2="inet xxx.xxx.xxx.195 netmask 0xff00"
route_0="xxx.xxx.xxx.193 -iface lo0"
route_1="xxx.xxx.xxx.194 -iface lo0"
route_2="xxx.xxx.xxx.195 -iface lo0"

(And yes, I know that one of the aliases has a /32 netmask and the other two
have a /24 - I was experimenting and there doesn't seem to be a difference)

The routes are something I picked up from reading the archives, they allow
processes in the jail to communicate with the host (mysql, in my case).

Another one that caught me was having /etc/resolv.conf setup properly inside
the jail, otherwise things like telnet will sit and spin trying to do hostname
lookups.

---
Jon Simola <[EMAIL PROTECTED]> | "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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Broken-by-design USB device?

2000-11-24 Thread Jon Simola


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:  port 0xd400-0xd41f irq 3 at
device 4.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
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


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc012663a
stack pointer   = 0x10:0xc044a938
frame pointer   = 0x10:0xc044a938
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
interrupt mask  = net tty bio cam
trap number = 12
panic: page fault
Uptime: 0s
Automatic reboot in 15 seconds - press a key on the console to abort


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 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
9946 G 02 518003

---
Jon Simola <[EMAIL PROTECTED]> | "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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Text mode video operations

2000-12-20 Thread Jon Simola

On Mon, 18 Dec 2000, Mike Smith wrote:

> > Speaking of video operations... does anybody know where I can find
> > some decent VGA programming documentation?  (Or, if possible, someone
> > who knows a few obscure details.)

A lot of old VGA card manuals had the basic programming instructions, using
INT 10h calls. By old, I mean ISA cards with less than 1Meg of RAM. Also check
out Raplh Brown's Interrupt list at:
http://www.cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/WWW/files.html

It's got just about everything you could ever want to know about what Int 10h
functions exist, and how to use them. 

> > I specifically need to know, if possible, how to display hardware-
> > rendered character- and software-rendered pixel-based images on the
> > same display at the same time.
> 
> Standard VGA does not offer this functionality; your current approach is 
> the only way to go.

I've done this before (back when my 386-25 was new). Int 10h func 09h will
draw characters from the VGA ROM in a simple graphics mode (ie 13h, 320x200
8bit colour unbanked). Past that, I just wrote my own font renderer. In 3
years of assembly-level VGA programming I learned quite a few "obscure
details" :)

If you're trying this on recent hardware, I'd pretty much echo what Mike Smith
said. You either BITBLT characters into your framebuffer, or use a font
renderer (ala freetype).

---
Jon Simola <[EMAIL PROTECTED]> | "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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Broken-by-design USB device?

2001-01-02 Thread Jon Simola

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:   cmpl0(%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 <[EMAIL PROTECTED]> | "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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Broken-by-design USB device?

2001-01-08 Thread Jon Simola

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:  port 0xd400-0xd41f irq 9 at
device 4.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
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 returned 6


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc011d58a
stack pointer   = 0x10:0xc030b920
frame pointer   = 0x10:0xc030b920
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
interrupt mask  = net tty bio cam 
kernel: type 12 trap, code=0
Stopped at  DEVICE_PROBE+0xe:   cmpl0(%edx),%eax
db> trace
DEVICE_PROBE(c0d32400,c0d32400,c0d32800,0,0) at DEVICE_PROBE+0xe
device_probe_child(c0d32800,c0d32400,c0d32500,0,c0d32530) at device_probe_child+0xc1
device_probe_and_attach(c0d32400) at device_probe_and_attach+0x3d
usbd_probe_and_attach(c0d32800,c0d32500,2,3,c0d32500) at usbd_probe_and_attach+0xef
usbd_new_device(c0d32800,c0d33000,1,200,2,c0d327c0) at usbd_new_device+0x1dd
uhub_explore(c0d32980,c0d32a00,c0d31580,0,c030be50) at uhub_explore+0x1d4
usb_attach(c0d32a00,c030be6c,c0154967,c0d32a00,c0d33000) at usb_attach+0xf1
DEVICE_ATTACH(c0d32a00,c0d33000,c0d31580,0,1) at DEVICE_ATTACH+0x2e
device_probe_and_attach(c0d32a00) at device_probe_and_attach+0x63
uhci_pci_attach(c0d31580,c030beb8,c0154967,c0d31580,c0d31580) at uhci_pci_attach+0x33f
DEVICE_ATTACH(c0d31580,c0d31580,c0d31b00,0,0) at DEVICE_ATTACH+0x2e
device_probe_and_attach(c0d31580) at device_probe_and_attach+0x63
bus_generic_attach(c0d31a80,c030bef0,c0154967,c0d31a80,c0d31a80) at 
bus_generic_attach+0x16
DEVICE_ATTACH(c0d31a80,c0d31a80,c0d31c80,0,1) at DEVICE_ATTACH+0x2e
device_probe_and_attach(c0d31a80) at device_probe_and_attach+0x63
bus_generic_attach(c0d31b00,c030bf28,c0154967,c0d31b00,c0d31b00) at 
bus_generic_attach+0x16
DEVICE_ATTACH(c0d31b00,c0d31b00,c0a25800,0,1) at DEVICE_ATTACH+0x2e
device_probe_and_attach(c0d31b00) at device_probe_and_attach+0x63
bus_generic_attach(c0d31c80,c0d31c80,c030bf54,c011d60e,c0d31c80) at 
bus_generic_attach+0x16
nexus_attach(c0d31c80,c030bf70,c0154967,c0d31c80,c0d31c80) at nexus_attach+0xd
DEVICE_ATTACH(c0d31c80,c0d31c80,c02791f0,31,1) at DEVICE_ATTACH+0x2e
device_probe_and_attach(c0d31c80) at device_probe_and_attach+0x63
root_bus_configure(c0a25800,c0258f8c,0) at root_bus_configure+0x16
configure(0,309c00,31,0,c011d014) at configure+0x33
mi_startup(c030bfb4,b0206,ffe,31,c0159069) at mi_startup+0x70
begin() at begin+0x4b
db> 


---
Jon Simola <[EMAIL PROTECTED]> | "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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Broken-by-design USB device?

2001-01-11 Thread Jon Simola

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 freeze.

I'd still bet on the hardware being suspect. It's got all the prime labelling
of a quality product: "PS-PC USB Converter" "Full Colors" "Special Design,
Extra Stable & Highly Compatibility"

> And now back to your scheduled 'panic' demolition:
> 
> It still bombs in the middle of DEVOPMETH in:
> 
>device_probe_t *m = (device_probe_t *) DEVOPMETH(dev, device_probe);
> 
> which is
> 
>#define DEVOPMETH(DEV, OP) \
> ((DEVOPDESC(OP)->offset >= DEVOPS(DEV)->maxoffset) \
>  ? DEVOPDESC(OP)->deflt \
>  : DEVOPS(DEV)->methods[DEVOPDESC(OP)->offset])
> 
> while executing
> 
>56:   3b 02   cmp(%edx),%eax
> 
> with edx == dev->ops and eax == device_probe_ops->offset (don't you hate
> i386 assembler syntax?) and edx apparently being 0.
> 
> Which as far as I can see is impossible in the subr_bus.c code. So that
> leaves 'memory spamming' as the only option :-( Apart from that, I have
> no clue which driver tries to attach after the
> ugen driver is finished. Because that is the last driver that makes an
> attempt.
> 
> Could you do the following: Boot the machine and when it panics type the
> following commands:
> 
>   show registers

db> show registers
cs 0x8
ds  0xc0a20010
es  0xc0150010  await+0xe4
fs  0xc0300010
ss0x10
eax0x9
ecx 0xc0d32400
edx  0
ebx0x6
esp 0xc030b920
ebp 0xc030b920
esi 0xc0a227b0
edi 0xc0d32400
eip 0xc011d58a  DEVICE_PROBE+0xe
efl0x90282

>   x/x $ecx,0x20

db> x/x $ecx,0x20
0xc0d32400: 0   0   0   0
0xc0d32410: 0   0   0   c0d2ac40
0xc0d32420: 0   c0a220400   0
0xc0d32430: 0   0   0   0
0xc0d32440: 0   0   0   0
0xc0d32450: 0   0   0   0
0xc0d32460: 0   0   0   0
0xc0d32470: 0   0   0   0

>   x/c *($ecx+0x24),0x10

db> x/c *($ecx+0x24),0x10
0xc0a22040: uhid0\000\000\000\000\000\000\000\000\000\000\000

> which will print three things: the contents of all registers (show
> registers), then the 32 longs at address $ecx (x/x $ecx,20), basically
> the contents of the struct device in DEVICE_PROBE, in which the 6th
> element (at +0x14) should be zero. And then the string that is pointed
> to by the nameunit element in the struct device. This last one should
> give us a hint at which device is failing.
> 
> Never mind if the last one gives you a page fault. nameunit might be
> zero.
> 
> I really am at a loss what this could be :(

If I'm following you, the info above will just prove that something is too
broken to figure out. If I can find another one of these things I'll just mail
it to you. Other than that, I'll stop wasting your time :)

Thank you very much for the help.

---
Jon Simola <[EMAIL PROTECTED]> | "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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message



Re: Broken-by-design USB device?

2001-01-16 Thread Jon Simola

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 USB
CONVERTOR
XK-PC2003

The box says the same except a different part number XK-PC2002. No UPC, no
identifying features, nothing.

> I'll have a look around to see whether I can find another
> one. We have a PlayStation 2 Developer's Kit in the office, so I'm
> interested to see the controllers work. We develop a game for
> PlayStation 2 and Windows (but it runs on FreeBSD as well :-), so being
> able to use the gamepad converter on FreeBSD would be a laugh.
>
> Hm, is it one of these?

Nope, I can't find it anywhere. I've confirmed on a couple other boxes that
this adapter really does cause some problems for some reason. I plugged it
into another test machine running 4.2-RELEASE and:

Jan 15 17:38:44 fileserver /kernel: uhid0: vendor 0x product 0x0667, rev
1.00/2.88, addr 2, iclass 3/0
Jan 15 17:38:44 fileserver /kernel: uhid0: no report descriptor
Jan 15 17:38:44 fileserver /kernel: device_probe_and_attach: uhid0 attach
returned 6
Jan 15 17:43:08 fileserver /kernel: Copyright (c) 1992-2000 The FreeBSD
Project.

For some reason the machine rebooted just after I unplugged the USB thing.

Send me your address and I'll mail this thing off to you, make it a lot easier
to debug.

---
Jon Simola <[EMAIL PROTECTED]> | "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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message