Re: devd automatic conversion of umass[0-9] to da[0-9]
on 06/05/2009 18:27 Julian Stacey said the following:
> Hi folks,
> Config below works for a number of memory sticks simultaneously;
> But if one already has a dvd burner plugged in,
> then it fails as devd sees (in case of a first memory stick) a new umass1.
> Although /dev/da0* get created, devd tries to access non existant da1*.
> Any ideas how to improve this ? ( Using 7.1-RELEASE )
You could try to watch for cdev events (i.e. creation of daX device nodes)
instead
of driver events. But I am not sure if cdev events are in 7.1, they are
definitely
in 7.2:
notify 1000 {
match "system""DEVFS";
match "subsystem" "CDEV";
match "type" "CREATE";
match "cdev" "^da[0-9]+$";
action "echo 't120o3l32 b>c+f+16' > /dev/speaker";
};
--
Andriy Gapon
___
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"
usb keyboard detected after mountroot
I think it's time to remind of this issue again. I have no clue why it happens but on my system I consistently see that my USB keyboard is detected after mountroot. This worries me because this is a "legacy free" system, i.e. it has no PS/2 ports. So if something unexpected happens I won't be able to enter different boot device should kernel boot ever stop at mountroot prompt. Some details. With stable/7 I see that my USB mouse is consistently detected way before mountroot. But the USB keyboard most often is detected after mountroot. But sometimes, very infrequently, it is detected at the same time as the mouse. With recent current (and HPS USB, of course) I see that both of the USB devices are consistently detected after mountroot: ... Trying to mount root from zfs:pond/ROOT/original ct_to_ts([2009-05-26 18:17:07]) = 1243361827.0 start_init: trying /sbin/init ugen2.2: at usbus2 ugen6.2: at usbus6 ukbd0: on usbus6 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d ums0: on usbus2 ums0: 8 buttons and [XYZ] coordinates ID=0 uhid0: on usbus6 -- Andriy Gapon ___ 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: usb keyboard detected after mountroot
on 28/05/2009 07:52 Emil Mikulic said the following: > On Wed, May 27, 2009 at 03:29:19PM +0300, Andriy Gapon wrote: >> I think it's time to remind of this issue again. I have no clue why >> it happens but on my system I consistently see that my USB keyboard is >> detected after mountroot. This worries me because this is a "legacy >> free" system, i.e. it has no PS/2 ports. So if something unexpected >> happens I won't be able to enter different boot device should kernel >> boot ever stop at mountroot prompt. > > I have the same problem and filed a PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=133989 > > The PR contains a patch that calls pause() in the prompt code. This > gets the keyboard detected but not actually working. :( Thank you for the info! I updated the PR with my details, hope this issue won't go unnoticed :-) -- Andriy Gapon ___ 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: usb/133989: [newusb] [ukbd] USB keyboard dead at mountroot> prompt
The following reply was made to PR usb/133989; it has been noted by GNATS. From: Andriy Gapon To: bug-follo...@freebsd.org, emiku...@gmail.com Cc: Subject: Re: usb/133989: [newusb] [ukbd] USB keyboard dead at mountroot> prompt Date: Thu, 28 May 2009 18:22:29 +0300 "Me too" here. I have a "legacy-free" system with no PS/2 ports, so I have no choice but use USB keyboard and mouse. And because of this issue I am afraid that I could into a situation where I'd be stuck at mountroot prompt with no input capability. LiveCD would help, but... What's interesting is that with stable/7 my mouse is detected way before mountroot prompt. This happens during "cold explore" phase, I think. But the keyboard is usually found after mountroot phase, but sometimes, very infrequently, it happens before. Typical dmesg: [various stuff] [more usb messages] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xe0425800-0xe0425bff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0425800 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered ... [more stuff] isa_probe_children: probing PnP devices ums0: on uhub2 ums0: 8 buttons and Z dir. ... [more stuff] Trying to mount root from zfs:tank/root ukbd0: on uhub6 kbd1 at ukbd0 kbd1: ukbd0, generic (0), config:0x0, flags:0x3d uhid0: on uhub6 But in head (with new usb stack, of course) I see that USB mouse and keyboard are discovered about the same time and so far it is always after mountroot phase: Typical (verbose) dmesg: [various stuff] [more usb controllers] usbus5: on uhci4 uhci5: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x0f10 usbus6: on uhci5 ehci1: mem 0xe0425800-0xe0425bff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0425800 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 ... [more stuff, interrupts enabled phase] usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ... [more stuff] uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ... SMP: AP CPU #1 Launched! ... Trying to mount root from zfs:pond/ROOT/original start_init: trying /sbin/init ugen2.2: at usbus2 ugen6.2: at usbus6 ukbd0: on usbus6 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d ums0: on usbus2 ums0: 8 buttons and [XYZ] coordinates ID=0 uhid0: on usbus6 I can provide full dmesgs, output of any tools, etc. P.S. please also see this thread about my investigation of this issue in stable/7: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-November/026832.html -- Andriy Gapon ___ 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: USB polling (75% done)
on 23/07/2009 21:23 Maksim Yevmenkin said the following: > On Tue, Jul 21, 2009 at 5:20 AM, Hans Petter Selasky wrote: >> On Monday 20 July 2009 23:51:41 Alfred Perlstein wrote: >>> * Hans Petter Selasky [090715 13:37] wrote: ... >>>> Using USB keyboard in KDB: Does not work because Giant is not locked when >>>> calling into the UKBD's get char routine. UKBD is Giant locked. Someone >>>> familiar with the keyboard system on FreeBSD please step forward and fix >>>> this so that UKBD gets independent of the Giant mutex. >>> the ukbd driver needs giant? >> I think the keyboard mux is under Giant, and does not have any concept about >> mutexes. Most simple solution would be that DDB locks Giant before entering >> into the keyboard code. > > as i understand it, keyboard drivers (and kbdmux(4) is a keyboard > driver), can/should not use any locks. period. so whatever calls into > keyboard driver should take care of locking. Maybe I am missing something but I do not see any explicit locking or lock assertions in kbdmux code. All lock defines are under #if 0. kbdmux does use taskqueue_swi_giant though. Tasks are queued on it in kbdmux_kbd_intr_timo (periodic callout) and in kbdmux_kbd_event (kbd callback). But, these shouldn't get called in polling mode, right? (because there shouldn't be any interrupts) Maybe Giant asserts in ukbd are not needed? Or should be asserted only in "normal" mode? P.S. I am far from knowing this area, just got curious. -- Andriy Gapon ___ 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: Asus M2A-VP, SB600 usb chip and keyboard attached during boot
on 07/09/2009 10:04 Hans Petter Selasky said the following: > On Sunday 06 September 2009 23:14:54 Dorian Büttner wrote: >> ATI > > Hi, > > I will try to port that patch you referred to over to FreeBSD. Maybe I will > have it ready later today. BTW, the patch as present verbatim in the posted link (http://marc.info/?l=openbsd-tech&m=124574838020563&w=2) seems to be incorrect. Either the register should be 0x53 and should be accessed via byte access. Or the bit should be 27. And, BTW, that bit of that register is not documented in AMD SB700/710/750 Register Reference Guide -- bits 24:27 of EHCI Misc Control register are said to be reserved. It's interesting to understand what this bit actually does, maybe someone has contacts at AMD. -- Andriy Gapon ___ 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"
sb600/sb700 ohci experimental patch
If you have a system with SB600, SB700, etc chipset and you have problems with
low
speed USB devices attached during boot (keyboard, mouse), could you please try
the
following experimental patch and report back?
I am primarily interested in the first several lines produced during boot with
printfs that are introduced by the patch. Preferably in the context of
surrounding
USB-related dmesg messages. No need to report subsequent same-looking
ever-repeating messages (if any).
WARNING: this is an experimental patch, it is probably not even close to what a
real fix could be, it might not fix the problem (but perhaps it would), it might
introduce instabilities into OHCI driver and it is noisy (unconditional printf).
The primary purpose of this patch is to gather information necessary for a real
fix.
Thank you!
diff --git a/sys/dev/usb/controller/ohci.c b/sys/dev/usb/controller/ohci.c
index 30592c1..fb6ba34 100644
--- a/sys/dev/usb/controller/ohci.c
+++ b/sys/dev/usb/controller/ohci.c
@@ -247,8 +249,8 @@ reset:
OWRITE4(sc, OHCI_INTERRUPT_ENABLE, sc->sc_eintrs | OHCI_MIE);
/* switch on desired functional features */
ctl = OREAD4(sc, OHCI_CONTROL);
- ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR);
- ctl |= OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE |
+ ctl &= ~(OHCI_CBSR_MASK | OHCI_LES | OHCI_HCFS_MASK | OHCI_IR |
OHCI_CLE |
OHCI_CLF);
+ ctl |= OHCI_PLE | OHCI_IE | /*OHCI_CLE |*/ OHCI_BLE |
OHCI_RATIO_1_4 | OHCI_HCFS_OPERATIONAL;
/* And finally start it! */
OWRITE4(sc, OHCI_CONTROL, ctl);
@@ -2727,8 +2729,17 @@ ohci_set_hw_power(struct usb_bus *bus)
temp = OREAD4(sc, OHCI_CONTROL);
temp &= ~(OHCI_PLE | OHCI_IE | OHCI_CLE | OHCI_BLE);
- if (flags & USB_HW_POWER_CONTROL)
+ if (flags & USB_HW_POWER_CONTROL) {
+ struct usb_page_search buf_res;
+
+ buf_res.physaddr = OREAD4(sc, OHCI_CONTROL_HEAD_ED);
+ printf("(hw power) control head <= %p\n",
(void*)buf_res.physaddr);
+ usbd_get_page(&sc->sc_hw.ctrl_start_pc, 0, &buf_res);
+ printf("(hw power) control head => %p\n",
(void*)buf_res.physaddr);
+ OWRITE4(sc, OHCI_CONTROL_HEAD_ED, buf_res.physaddr);
+
temp |= OHCI_CLE;
+ }
if (flags & USB_HW_POWER_BULK)
temp |= OHCI_BLE;
--
Andriy Gapon
___
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: sb600/sb700 ohci experimental patch
on 25/09/2009 01:31 Andrius Morkūnas said the following: > usbus0: 12Mbps Full Speed USB v1.0 > (hw power) control head <= 0xcfef1e30 > (hw power) control head => 0x2329000 > usbus1: 12Mbps Full Speed USB v1.0 > (hw power) control head <= 0xcfef1e40 > (hw power) control head => 0x4143000 These were the messages that I looked for the most. > If you need anything else, let me know. > > And thanks for the patch. Thank you very much for the testing and the detailed report! Unfortunately I have no clue about the umass issue. >From comparing attach after boot and attach during boot messages it seems that USB part worked almost identical, it's the CAM part that didn't happen in the second case. BTW, how many ports do you have at the back? If more than 2, could you please try connecting the mouse to a port that is not connected to uhub0 (this could be verified with usbconfig)? And then see if you still get a mouse attachment problem during boot? (No other devices during boot please :-) to simplify the testcase.) -- Andriy Gapon ___ 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: sb600/sb700 ohci experimental patch
0 control=0x00af command=0x ohci_dumpregs:544:intrstat=0x0004 intre=0x805a intrd=0x805a ohci_dumpregs:548:hcca=0x030a8000 percur=0x ctrlhd=0x030a9000 ohci_dumpregs:552:ctrlcur=0x bulkhd=0x030b1000 bulkcur=0x ohci_dumpregs:556:done=0x fmival=0xa7782edf fmrem=0x800013d5 ohci_dumpregs:560:fmnum=0x000d perst=0x2a2f lsthrs=0x0628 ohci_dumpregs:564:desca=0x02000b03 descb=0x stat=0x ohci_dumpregs:567:port1=0x0100 port2=0x0100 ohci_dumpregs:573: HCCA: frame_number=0x000e done_head=0x ohci_controller_init:297: dump of ohci0 regs: ohci_dumpregs:540: ohci_dumpregs: rev=0x0110 control=0x00af command=0x ohci_dumpregs:544:intrstat=0x0004 intre=0x805a intrd=0x805a ohci_dumpregs:548:hcca=0x0304b000 percur=0x ctrlhd=0xbfdf1c50 ohci_dumpregs:552:ctrlcur=0x bulkhd=0x03083000 bulkcur=0x ohci_dumpregs:556:done=0xbfdf1ca0 fmival=0xa7782edf fmrem=0x80002e51 ohci_dumpregs:560:fmnum=0x019f perst=0x2a2f lsthrs=0x0628 ohci_dumpregs:564:desca=0x02000b03 descb=0x stat=0x ohci_dumpregs:567:port1=0x0303 port2=0x0100 ohci_dumpregs:573: HCCA: frame_number=0x019f done_head=0x So, as expected, reset does clear the registers, programming does set them correctly. But as soon as we are done programming ohci1, ctrlhd of ohci0 gets re-programmed to 0xbfdf1c50. BTW, to answer your question, other lists seem to be unaffected, head/cur values seem to be preserved intact. hcca register is also OK. Not sure how to interpret this. Either a timing issue, i.e. the register gets over-written some time after we program it. Or perhaps a bug in SMM code, i.e. when we generate an SMI (e.g. while doing ohci1 takeover) SMM code erroneously writes something to ohci0 ctrlhead. Or something else... :) -- Andriy Gapon ___ 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: sb600/sb700 ohci experimental patch
on 25/09/2009 11:02 Svein Skogen (listmail account) said the following:
> Andriy Gapon wrote:
>> on 24/09/2009 17:51 Hans Petter Selasky said the following:
>
> *SNIP!*
>
>> Not sure how to interpret this.
>> Either a timing issue, i.e. the register gets over-written some time after we
>> program it.
>> Or perhaps a bug in SMM code, i.e. when we generate an SMI (e.g. while doing
>> ohci1 takeover) SMM code erroneously writes something to ohci0 ctrlhead.
>> Or something else... :)
>
> Could it be related to "USB Legacy Devices" in bios, and thus be the
> same problem that was discussed recently (regarding HZ larger than 1000)?
>
> An usb-legacy setup might explain both the register-changing _AND_ the
> timing issue...
It very well could, but...
We do perform proper OHCI takeover, so we don't expect firmware to mess with the
controllers after it is finished.
Also, I personally have everything "USB legacy" disabled in my BIOS ("USB Legacy
Support", "USB Keyboard support", "USB Mouse support"). Although, Gigabyte
BIOSes
are known to be sometimes smarter than they appear and to "autodetect" things
when
they are explicitly turned off in settings.
Last point. Explaining is half the job. Fixing / working around is the other
half.
P.S. I am not sure what "timing issue" you referred to.
--
Andriy Gapon
___
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: sb600/sb700 ohci experimental patch
on 25/09/2009 10:28 Hans Petter Selasky said the following:
> On Friday 25 September 2009 08:34:21 Andriy Gapon wrote:
>> Not sure how to interpret this.
>
> In ohci_controller_init() try to disable the
>
> DPRINTF("SMM active, request owner change\n");
>
> part of the code for !(ohci_unit == 0) or (ohci_unit == 2) and see what
> happens.
>
> Your clue might also indicate that we should request owner change for all
> OHCI's before resetting any of them. Possibly a BIOS bug!
Haven't tried the suggested changes yet, but here is some more info.
This is register dump of ohci0 just _before_ we start doing anything with it:
ohci0: mem 0xfe02e000-0xfe02efff irq 16 at
device 18.0 on pci0
ohci0: [ITHREAD]
ohci_dumpregs:567: ohci_dumpregs: rev=0x0110 control=0x0184
command=0x
ohci_dumpregs:571:intrstat=0x0024 intre=0xc042
intrd=0xc042
ohci_dumpregs:575:hcca=0xbfdf1f00 percur=0x
ctrlhd=0xbfdf1c50
ohci_dumpregs:579:ctrlcur=0x bulkhd=0x
bulkcur=0x
ohci_dumpregs:583:done=0xbfdf1ca0 fmival=0x27782edf
fmrem=0x09bd
ohci_dumpregs:587:fmnum=0x8e3a perst=0x2a27
lsthrs=0x0628
ohci_dumpregs:591:desca=0x02000b03 descb=0x
stat=0x
ohci_dumpregs:594:port1=0x0303 port2=0x0100
ohci_dumpregs:600: HCCA: frame_number=0x done_head=0x
This is dump just after we programmed it:
ohci_controller_init:308: rewrite head regs
ohci_dumpregs:567: ohci_dumpregs: rev=0x0110 control=0x00af
command=0x
ohci_dumpregs:571:intrstat=0x0044 intre=0x805a
intrd=0x805a
ohci_dumpregs:575:hcca=0x06647000 percur=0x
ctrlhd=0x06692000
ohci_dumpregs:579:ctrlcur=0x bulkhd=0x06693000
bulkcur=0x
ohci_dumpregs:583:done=0x fmival=0xa7782edf
fmrem=0x80001096
ohci_dumpregs:587:fmnum=0x000d perst=0x2a2f
lsthrs=0x0628
ohci_dumpregs:591:desca=0x02000b03 descb=0x
stat=0x
ohci_dumpregs:594:port1=0x00010301 port2=0x0100
ohci_dumpregs:600: HCCA: frame_number=0x000e done_head=0x
This is dump of ohci0 registers just before we run takeover code of ohci1:
ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at
device 18.1 on pci0
ohci1: [ITHREAD]
ohci_controller_init:185: reread ohci0 regs:
ohci_dumpregs:567: ohci_dumpregs: rev=0x0110 control=0x00af
command=0x
ohci_dumpregs:571:intrstat=0x0044 intre=0x805a
intrd=0x805a
ohci_dumpregs:575:hcca=0x06647000 percur=0x
ctrlhd=0x06692000
ohci_dumpregs:579:ctrlcur=0x bulkhd=0x06693000
bulkcur=0x
ohci_dumpregs:583:done=0x fmival=0xa7782edf
fmrem=0x83b5
ohci_dumpregs:587:fmnum=0x0012 perst=0x2a2f
lsthrs=0x0628
ohci_dumpregs:591:desca=0x02000b03 descb=0x
stat=0x
ohci_dumpregs:594:port1=0x00010301 port2=0x0100
ohci_dumpregs:600: HCCA: frame_number=0x0012 done_head=0x
And this is dump of ohci0 right after we've taken over ohci1:
ohci_controller_init:195: SMM active, request owner change
ohci_controller_init:219: usbus1: resetting
ohci_controller_init:246: reread ohci0 regs:
ohci_dumpregs:567: ohci_dumpregs: rev=0x0110 control=0x00af
command=0x
ohci_dumpregs:571:intrstat=0x0004 intre=0x805a
intrd=0x805a
ohci_dumpregs:575:hcca=0x06647000 percur=0x
ctrlhd=0xbfdf1c50
ohci_dumpregs:579:ctrlcur=0x bulkhd=0x06693000
bulkcur=0x
ohci_dumpregs:583:done=0xbfdf1ca0 fmival=0xa7782edf
fmrem=0x80002122
ohci_dumpregs:587:fmnum=0x0192 perst=0x2a2f
lsthrs=0x0628
ohci_dumpregs:591:desca=0x02000b03 descb=0x
stat=0x
ohci_dumpregs:594:port1=0x0303 port2=0x0100
ohci_dumpregs:600: HCCA: frame_number=0x0192 done_head=0x
As you can see, indeed, the register gets over-written right when we take over
ohci1.
Some additional observations:
1. frame_number seems to grow quite a lot for ohci0
2. before we touch ohci0 it has port1=0x0303, after reset port1=0x00010301,
after ohci1 takeover port1=0x0303 again.
I'd say that this is a pretty strong evidence that BIOS does something to ohci0
after we took over it and while we are taking over ohci1.
Another idea of working around this:
1) in pci fixup code disable USB SMI for these chipsets
2) (optional) in ohci code skip takeover step
Sounds messy.
--
Andriy Gapon
___
freebsd-usb@freebsd.org mailing list
http://lists.free
Re: sb600/sb700 ohci experimental patch
on 27/09/2009 15:17 Andriy Gapon said the following:
> Another idea of working around this:
> 1) in pci fixup code disable USB SMI for these chipsets
> 2) (optional) in ohci code skip takeover step
> Sounds messy.
BTW, just for the sake of experiment I did exactly what I suggested.
I've got the following messages:
kernel: ohci_controller_init:195: SMM active, request owner change
kernel: usbus0: SMM does not respond, resetting
kernel: ohci_controller_init:195: SMM active, request owner change
kernel: usbus1: SMM does not respond, resetting
kernel: ohci_controller_init:195: SMM active, request owner change
kernel: usbus3: SMM does not respond, resetting
kernel: ohci_controller_init:195: SMM active, request owner change
kernel: usbus4: SMM does not respond, resetting
kernel: ohci_controller_init:195: SMM active, request owner change
kernel: usbus6: SMM does not respond, resetting
And the register value stayed intact after initial programming, so no
re-programming was needed.
Here is the (dirty) hack:
diff --git a/sys/dev/pci/fixup_pci.c b/sys/dev/pci/fixup_pci.c
index 566e503..1463c24 100644
--- a/sys/dev/pci/fixup_pci.c
+++ b/sys/dev/pci/fixup_pci.c
@@ -53,6 +53,7 @@ static intfixup_pci_probe(device_t dev);
static voidfixwsc_natoma(device_t dev);
static voidfixc1_nforce2(device_t dev);
static voidfixrtc_piix4(device_t dev);
+static voidfixsmi_usb(device_t dev);
static device_method_t fixup_pci_methods[] = {
/* Device interface */
@@ -84,6 +85,9 @@ fixup_pci_probe(device_t dev)
case 0x01e010de: /* nVidia nForce2 */
fixc1_nforce2(dev);
break;
+case 0x96001022: /* AMD SB700 */
+ fixsmi_usb(dev);
+ break;
}
return(ENXIO);
}
@@ -124,6 +128,21 @@
}
+/* Disable USB SMI */
+static void
+fixsmi_usb(device_t dev)
+{
+uint32_t features;
+
+dev = pci_find_device(0x1002, 0x4385);
+features = pci_read_config(dev, 0x64, 4);
+if (features & (1 << 15)) {
+ printf("Disabling USB SMI on SB7xx\n");
+ features &= ~(1 << 15);
+ pci_write_config(dev, 0x64, features, 4);
+}
+}
+
/*
* Set the SYSTEM_IDLE_TIMEOUT to 80 ns on nForce2 systems to work
* around a hang that is triggered when the CPU generates a very fast
--
Andriy Gapon
___
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: sb600/sb700 ohci experimental patch
on 27/09/2009 16:10 Andriy Gapon said the following: > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus0: SMM does not respond, resetting > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus1: SMM does not respond, resetting > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus3: SMM does not respond, resetting > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus4: SMM does not respond, resetting > kernel: ohci_controller_init:195: SMM active, request owner change > kernel: usbus6: SMM does not respond, resetting > > And the register value stayed intact after initial programming, so no > re-programming was needed. I think that I didn't finished what I was saying. I think that now we can be very sure what is the culprit here. Now we need to find the best strategy to work around the problem. (Of course, it would be just the second best with the best being fixing SMM code, but that's beyond our control). -- Andriy Gapon ___ 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: sb600/sb700 ohci experimental patch
on 28/09/2009 14:48 John Baldwin said the following: > I don't think you can do this because it is a "feature" to not disable SMM if > ohci(4) is not loaded so that a USB keyboard works when the USB driver isn't > loaded via PS/2 emulation, even when the OS is running. Very good point. > I am curious if we > really need to do the handover for each controller or if disabling it for > ohci0 effectively disables it for all controllers? What do other OS's do? > Don't have an answer about other OSes. But OHCI controllers have individual "used by SMM" bits and taking over one controller doesn't affect the bits of the other controllers - they remain set. Not that it means that SMM code actually keeps on controlling them. Actually, just checked - Linux also does it per controller: http://lxr.linux.no/#linux+v2.6.31/drivers/usb/host/ohci-hcd.c#L495 -- Andriy Gapon ___ 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: sb600/sb700 ohci experimental patch
on 28/09/2009 17:10 John Baldwin said the following: > On Monday 28 September 2009 9:55:44 am Andriy Gapon wrote: >> on 28/09/2009 14:48 John Baldwin said the following: >>> I don't think you can do this because it is a "feature" to not disable SMM >>> if >>> ohci(4) is not loaded so that a USB keyboard works when the USB driver >>> isn't >>> loaded via PS/2 emulation, even when the OS is running. >> Very good point. >> >>> I am curious if we >>> really need to do the handover for each controller or if disabling it for >>> ohci0 effectively disables it for all controllers? What do other OS's do? >>> >> Don't have an answer about other OSes. >> But OHCI controllers have individual "used by SMM" bits and taking over one >> controller doesn't affect the bits of the other controllers - they remain >> set. >> Not that it means that SMM code actually keeps on controlling them. >> >> Actually, just checked - Linux also does it per controller: >> http://lxr.linux.no/#linux+v2.6.31/drivers/usb/host/ohci-hcd.c#L495 > > Hmm, it seems Linux now disables SMM for USB controllers (ohci, ehci, and > uhci) > via PCI quirks rather than doing it in the device drivers themselves, which > matches your original suggestion. I'm not sure how best to fix that while > also > allowing USB to work w/o drivers loaded. > I looked at the quirk code (for OHCI only) and they don't disable SMI - they do exactly the same takeover dance, only earlier: http://lxr.linux.no/#linux+v2.6.31/drivers/usb/host/pci-quirks.c#L169 I.e. this actually matches what Hans suggested before - first early takeover of all controllers, then probe/attach pass. Not sure how to implement this best in our architecture - also using quirks or perhaps something along the lines of multi-pass? :-) -- Andriy Gapon ___ 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
on 18/11/2009 14:25 Travelling Particle said the following: > Hello, > > I am not sure if the problem is with USB, because the same hardware works > fine with LiveCD. I will seek help here first, please feel free to redirect > me to a better place for advice. > > The system is 8.0-RC3. > > I am booting off USB stick because I have to attach root partition on HDD > with GELI. It all works fine, I am able to enter passphrase on the keyboard > (there's only ukbd keyboard in the kernel at this moment, but I had tried > with atkbd as well; I have also experimented with or without TEKEN with no > difference). After root partition is mounted, system mounts other geli > partitions on the same hard disk. It is right after the filesystems were > mounted that the problem starts. The output on console at that moment starts > to be interleaved with new lines symbols. After late boot stage completes, I > see login prompt on console, but system acts *as if* I had just pressed > Enter and presents login prompt again and again. The keyboard itself appears > to be dead. If I choose to boot single-mode, behavior is the same -- I see > multiple shell prompts as if I were hitting Enter repeatedly. I had been > trying various configurations in the kernel for over 5 days now, and still > couldn't make the console work on the system (I can login via network > though). > > The hardware is Nvidea ION-based Acer nettop. It does not come with PS/2 > keyboard connector and I cannot test it with any keyboard but USB. The > keyboard itself I am using is Acer's standard one, and it works fine with > LiveCD. I wonder if GELI might mess the things up, but the geli attachment > process goes well, and all filesystems are attached just fine. LiveCD is also 8.0-RC3? -- Andriy Gapon ___ 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: ukbd attachment and root mount
on 28/11/2008 15:12 Andriy Gapon said the following: > on 27/11/2008 15:23 Andriy Gapon said the following: >> I increased debug level in uhub and also switched mouse and keyboard >> ports hoping that order might matter. It didn't. >> >> Here's fresh usbdevs output snippet: >> Controller /dev/usb2: >> addr 1: full speed, self powered, config 1, UHCI root hub(0x), >> Intel(0x), rev 1.00 >> uhub2 >> port 1 addr 3: low speed, power 100 mA, config 1, USB Keyboard(0x0101), >> CHESEN(0x0a81), rev 1.10 >>ukbd0 >>uhid0 >> port 2 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical >> Mouse(0xc040), Logitech(0x046d), rev 24.30 >>ums0 >> >> And here's a new snippet from cold explore dmesg: >> uhub2: uhub_explore: port 1 status 0x0100 0x0001 >> + >> + So, hm, it looks like a change in connection status is reported but >> current status is reported as not connected. >> + I wonder why? Just wanted to followup on this and let you know that the issue seems to be resolved in stable/8, I think that early usb takeover change might have fixed it. The change is not in 8.0. > For now I am blaming this on the keyboard. My wild un-educated guess is > that it takes it too long to come back after controller reset. I don't > have any other explanation at the moment. > > I'll try to get another keyboard (from different vendor) and play with it. -- Andriy Gapon ___ 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: Problems with mouse and keyboard
on 02/12/2009 23:47 Gerd Truschinski said the following: > Hi there, > > I am running FreeBSD 8.0-RELEASE on an Jetway JNC-81-LF Board with the > AMD780G chipset. > My mouse (Logitech) and keyboard (Cherry) are connect via an ATEN > CS-1764 KVM-Switch to the rear USB-ports. > > This work very well as long as I connect the KVM-Switch to one (the > "good" port) of the four rear ports during coldstart. Then I also may > change the port on the fly without any problem. The USB subsystem is > disconnecting and reconnecting like a charm. > > If I use on of the other ports during I get the following errors on all > but the "good" port: I think that this problem is fixed in 8-STABLE but not 8.0-RELEASE. -- Andriy Gapon ___ 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: Problems with mouse and keyboard
on 03/12/2009 18:54 Ondřej Majerech said the following: > On Thu, 03 Dec 2009 14:51:11 +0100, Andriy Gapon wrote: > >> >> I think that this problem is fixed in 8-STABLE but not 8.0-RELEASE. >> > > I've had the same problem, updating to 8-STABLE did fix it, -RELEASE > doesn't work for me. I submitted a PR for it, but I guess it won't be > fixed in -RELEASE until 8.1, right? Yes, correct, unless there is an errata release, but that isn't likely. Another thing to try is to locally apply merge the change if kernel build from sources is practiced. The changes you want are r198151 and r199814 (to be on the safe side). -- Andriy Gapon ___ 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: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing
Hans, is this setup (video4bsd+webcamd+etc) supposed to work with USB Video Class (UVC) devices? Namely, I have a webcam built into Dell SP2208WFP monitor: $ usbconfig ... ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen3.3: at u, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.4: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE BTW, 'at u,' above is not a typo or copy/paste error, it's how it actually appears on the screen. -- Andriy Gapon ___ 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: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing
0x01, 0x01, 0x00, 0x00 Interface 2 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0002 bAlternateSetting = 0x bNumEndpoints = 0x bInterfaceClass = 0x0001 bInterfaceSubClass = 0x0001 bInterfaceProtocol = 0x iInterface = 0x Additional Descriptor bLength = 0x09 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x09, 0x24, 0x01, 0x00, 0x01, 0x2b, 0x00, 0x01, 0x08 | 0x03 Additional Descriptor bLength = 0x0c bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x0c, 0x24, 0x02, 0x01, 0x05, 0x02, 0x00, 0x02, 0x08 | 0x00, 0x00, 0x00, 0x00 Additional Descriptor bLength = 0x09 bDescriptorType = 0x24 bDescriptorSubType = 0x03 RAW dump: 0x00 | 0x09, 0x24, 0x03, 0x02, 0x01, 0x01, 0x00, 0x03, 0x08 | 0x00 Additional Descriptor bLength = 0x0d bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x0d, 0x24, 0x06, 0x03, 0x01, 0x02, 0x43, 0x02, 0x08 | 0x00, 0x00, 0x00, 0x00, 0x00 Interface 3 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0003 bAlternateSetting = 0x bNumEndpoints = 0x bInterfaceClass = 0x0001 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x iInterface = 0x Interface 3 Alt 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0003 bAlternateSetting = 0x0001 bNumEndpoints = 0x0001 bInterfaceClass = 0x0001 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x iInterface = 0x Additional Descriptor bLength = 0x07 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x07, 0x24, 0x01, 0x02, 0x01, 0x01, 0x00 Additional Descriptor bLength = 0x23 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x23, 0x24, 0x02, 0x01, 0x02, 0x02, 0x10, 0x09, 0x08 | 0x80, 0xbb, 0x00, 0x44, 0xac, 0x00, 0x00, 0x7d, 0x10 | 0x00, 0xc0, 0x5d, 0x00, 0x22, 0x56, 0x00, 0x80, 0x18 | 0x3e, 0x00, 0xe0, 0x2e, 0x00, 0x11, 0x2b, 0x00, 0x20 | 0x40, 0x1f, 0x00 Endpoint 0 bLength = 0x0009 bDescriptorType = 0x0005 bEndpointAddress = 0x0084 bmAttributes = 0x000d wMaxPacketSize = 0x00c0 bInterval = 0x0004 bRefresh = 0x bSynchAddress = 0x Additional Descriptor bLength = 0x07 bDescriptorType = 0x25 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x07, 0x25, 0x01, 0x01, 0x00, 0x00, 0x00 -- Andriy Gapon ___ 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: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing
on 26/01/2010 20:36 Andriy Gapon said the following: > on 26/01/2010 19:37 Hans Petter Selasky said the following: >> The string is just too big, so it gets truncated. Send me a dump of the >> config >> descriptor for the webcamera. If it says 0x0e for interface class, it's most >> likely supported. > > Here it is: > ugen3.3: Inc.538-2640-07.08.09.6> at u, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE > > > Configuration index 0 > > bLength = 0x0009 > bDescriptorType = 0x0002 > wTotalLength = 0x041b > bNumInterfaces = 0x0004 > bConfigurationValue = 0x0001 > iConfiguration = 0x > bmAttributes = 0x0080 > bMaxPower = 0x00fa > > Additional Descriptor > > bLength = 0x08 > bDescriptorType = 0x0b > bDescriptorSubType = 0x00 > RAW dump: > 0x00 | 0x08, 0x0b, 0x00, 0x02, 0x0e, 0x03, 0x00, 0x02 > > > Interface 0 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x > bAlternateSetting = 0x > bNumEndpoints = 0x0001 > bInterfaceClass = 0x000e > bInterfaceSubClass = 0x0001 > bInterfaceProtocol = 0x > iInterface = 0x0002 Seems like webcamd indeed recognizes this webcam, but it does that... eventually. That is, I have to start webcamd several times until it seems the webcam. The first few attempts end with 'Cannot find USB device'. I always start it using webcamd -d ugen3.3 -v 0 -- Andriy Gapon ___ 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: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing
on 26/01/2010 20:39 Andriy Gapon said the following: > Seems like webcamd indeed recognizes this webcam, but it does that... > eventually. > That is, I have to start webcamd several times until it seems the webcam. > The first few attempts end with 'Cannot find USB device'. > I always start it using webcamd -d ugen3.3 -v 0 More info (sorry for the forum-like style). I turned all debug calls in uvc driver into regular printfs and I am getting this: Adding mapping Brightness to control ----0101/2. Adding mapping Contrast to control ----0101/3. Adding mapping Hue to control ----0101/6. Adding mapping Saturation to control ----0101/7. Adding mapping Sharpness to control ----0101/8. Adding mapping Gamma to control ----0101/9. Adding mapping Backlight Compensation to control ----0101/1. Adding mapping Gain to control ----0101/4. Adding mapping Power Line Frequency to control ----0101/5. Adding mapping Hue, Auto to control ----0101/16. Adding mapping Exposure, Auto to control ----0001/2. Adding mapping Exposure, Auto Priority to control ----0001/3. Adding mapping Exposure (Absolute) to control ----0001/4. Adding mapping White Balance Temperature, Auto to control ----0101/11. Adding mapping White Balance Temperature to control ----0101/10. Adding mapping White Balance Component, Auto to control ----0101/13. Adding mapping White Balance Blue Component to control ----0101/12. Adding mapping White Balance Red Component to control ----0101/12. Adding mapping Focus (absolute) to control ----0001/6. Adding mapping Focus, Auto to control ----0001/8. Adding mapping Zoom, Absolute to control ----0001/11. Adding mapping Zoom, Continuous to control ----0001/12. Adding mapping Privacy to control ----0001/17. Probing generic UVC device Found format MJPEG. - 640x480 (30.0 fps) - 160x120 (30.0 fps) - 176x144 (30.0 fps) - 320x240 (30.0 fps) - 352x288 (30.0 fps) - 800x600 (30.0 fps) - 1024x768 (10.0 fps) - 1280x1024 (10.0 fps) - 1600x1200 (10.0 fps) Found format YUV 4:2:2 (YUYV). - 640x480 (30.0 fps) - 160x120 (30.0 fps) - 176x144 (30.0 fps) - 320x240 (30.0 fps) - 352x288 (30.0 fps) - 1600x1200 (5.0 fps) Found a Status endpoint (addr 83). Added control ----0101/2 to device entity 5 Added control ----0101/3 to device entity 5 Added control ----0101/6 to device entity 5 Added control ----0101/7 to device entity 5 Added control ----0101/8 to device entity 5 Added control ----0101/9 to device entity 5 Added control ----0101/10 to device entity 5 Added control ----0101/1 to device entity 5 Added control ----0101/5 to device entity 5 Added control ----0101/11 to device entity 5 Added control ----0101/14 to device entity 5 Added control ----0001/11 to device entity 1 Added control ----0001/13 to device entity 1 Scanning UVC chain:Found a valid video chain (1 -> 3). ^^^ this where output stops when webcamd can not attach UVC device initialized. ^^^ this is the successful case -- Andriy Gapon ___ 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: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing
on 26/01/2010 20:43 Andriy Gapon said the following: [snip] > Added control ----0101/2 to device entity 5 > Added control ----0101/3 to device entity 5 > Added control ----0101/6 to device entity 5 > Added control ----0101/7 to device entity 5 > Added control ----0101/8 to device entity 5 > Added control ----0101/9 to device entity 5 > Added control ----0101/10 to device entity 5 > Added control ----0101/1 to device entity 5 > Added control ----0101/5 to device entity 5 > Added control ----0101/11 to device entity 5 > Added control ----0101/14 to device entity 5 > Added control ----0001/11 to device entity 1 > Added control ----0001/13 to device entity 1 > Scanning UVC chain:Found a valid video chain (1 -> 3). > ^^^ this where output stops when webcamd can not attach > UVC device initialized. > ^^^ this is the successful case > > When I start pwcview it show a green frame for a moment and then exits: $ pwcview -s vga -f 30 Webcam set to: 640x480 (vga) at 30 fps libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? Error reading from webcam: Input/output error Here is what gets printed by webcamd: uvc_v4l2_open Trying format 0x47504a4d (MJPG): 48x32. Using default frame interval 3.3 us (30.0 fps). Trying format 0x47504a4d (MJPG): 10x10. Using default frame interval 10.0 us (10.0 fps). Trying format 0x56595559 (YUYV): 48x32. Using default frame interval 3.3 us (30.0 fps). Trying format 0x56595559 (YUYV): 10x10. Using default frame interval 20.0 us (5.0 fps). Unsupported ioctl 0xc0485619 Trying format 0x47504a4d (MJPG): 320x240. Using default frame interval 3.3 us (30.0 fps). Trying format 0x47504a4d (MJPG): 320x240. Using default frame interval 3.3 us (30.0 fps). Trying format 0x47504a4d (MJPG): 640x480. Using default frame interval 3.3 us (30.0 fps). uvc_v4l2_mmap uvc_v4l2_mmap uvc_v4l2_mmap uvc_v4l2_mmap Queuing buffer 0. Queuing buffer 1. Queuing buffer 2. Queuing buffer 3. Device requested 3060 B/frame bandwidth. Selecting alternate setting 6 (3060 B/frame bandwidth). Allocated 2 URB buffers of 160x3060 bytes each. Dropping payload (error bit set). Dropping payload (error bit set). Dropping payload (error bit set). Dropping payload (error bit set). Dropping payload (error bit set). Frame complete (EOF found). Dequeuing buffer 0 (4, 39388 bytes). Queuing buffer 0. uvc_v4l2_release What's also strange is that webcam's "in use" light never turns on. -- Andriy Gapon ___ 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: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing
on 26/01/2010 20:47 Andriy Gapon said the following: > > What's also strange is that webcam's "in use" light never turns on. OK, it actually does turn on. What I've discovered is that the webcam needs some short time to "warm up". I've modified pwcview to ignore a few initial v4l1_read error and everything is fine now. It would be better, of course, if the driver internally handled these couple of initial frames, but my workaround is OK for me too. -- Andriy Gapon ___ 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: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing
on 26/01/2010 23:05 Hans Petter Selasky said the following: > On Tuesday 26 January 2010 19:43:20 Andriy Gapon wrote: >> on 26/01/2010 20:39 Andriy Gapon said the following: >>> Seems like webcamd indeed recognizes this webcam, but it does that... >>> eventually. That is, I have to start webcamd several times until it seems >>> the webcam. The first few attempts end with 'Cannot find USB device'. >>> I always start it using webcamd -d ugen3.3 -v 0 > > Have you updated your libusb to the version in 8-stable? Yes, I did. -- Andriy Gapon ___ 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: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing
BTW, on Skype with video4bsd - when I start Skype and try to configure a video
device I get the following in system log:
kernel: linux: pid 21092 (skype): ioctl fd=10, cmd=0x7601 ('v',1) is not
implemented
kernel: linux: pid 21092 (skype): ioctl fd=39, cmd=0x7601 ('v',1) is not
implemented
And also I get the following on the stdout of webcamd (with Linux debug
converted
to printfs):
uvc_v4l2_open
Unknown ioctl 0x40047601
uvc_v4l2_release
P.S. I am using the latest versions of all required software _from ports_.
I haven't tried svn version of webcamd yet.
--
Andriy Gapon
___
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: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing
on 27/01/2010 19:14 Hans Petter Selasky said the following:
> On Wednesday 27 January 2010 17:11:08 Andriy Gapon wrote:
>> BTW, on Skype with video4bsd - when I start Skype and try to configure a
>> video device I get the following in system log:
>>
>> kernel: linux: pid 21092 (skype): ioctl fd=10, cmd=0x7601 ('v',1) is not
>> implemented kernel: linux: pid 21092 (skype): ioctl fd=39, cmd=0x7601
>> ('v',1) is not implemented
>>
>> And also I get the following on the stdout of webcamd (with Linux debug
>> converted to printfs):
>> uvc_v4l2_open
>> Unknown ioctl 0x40047601
>> uvc_v4l2_release
>>
>>
>> P.S. I am using the latest versions of all required software _from ports_.
>> I haven't tried svn version of webcamd yet.
>>
>
> Those IOCTL's should have been translated by linux.ko. When they are not,
> /dev/videoX does not understand them.
I see. So we need an additional translation.
I believe that this particular ioctl was VIDIOCGCAP (get capabilities).
But it doesn't look like we have V4B analogue for this.
--
Andriy Gapon
___
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: usb/144280: boot0cfg not USB aware
on 07/03/2010 07:08 Fbsd1 said the following: > Hans Petter Selasky wrote: >> On Thursday 25 February 2010 09:29:14 Joe Barbish wrote: >>>> Description: >>> Have boot0cfg installed on PC motherboard cabled hard drive and when >>> I plug >>> in an USB cabled external hard drive or USB flash drive, (both >>> containing >>> a installed full FreeBSD version) and boot the PC, the f5 key for >>> going to >>> the second hard drive is non-functional. Looks like boot0cfg is not USB >>> aware. >>> >> >> This is not an USB issue, but rather BIOS / boot-code related. Please >> change responsible. >> >> --HPS >> >> > You have a very limited view point of what is USB problem. I don't see > it as a bios problem. For sure the problem is in the boot0cfg code and > for sure IT IS A USB PROBLEM. Now if you want to change this to am > different group then you are welcome to do so. But as the original > reporter of the PR I don't have the authority to make that change. Dear "Fbsd1" (Joe Barbish?), Hans meant that this is not an issue with USB kernel driver and he is totally correct. usb@ assignment is for bugs with kernel USB driver only. BTW, bootloader doesn't have any explicit knowledge of USB either, it uses BIOS interface and depends on BIOS USB emulation. I think that Hans can't change the PR assignment. So this message is mostly for Mark :-) -- Andriy Gapon ___ 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: usb/144280: boot0cfg not USB aware
on 10/03/2010 02:25 Fbsd1 said the following: > > Thank you Andriy Gapon for the courteous and informative post. May I > suggest that the submit-pr web page be changed by replacing the USB > assignment with Kernel-usb assignment. That is more in line with the USB > charter and would reduce the number of PR's wrongly being posted to the > USB assignment. So help us help you. http://www.freebsd.org/doc/en/articles/problem-reports/article.html Section 4.4. Filling out the template: - If a problem is with the kernel, the libraries (such as standard C library libc), or a peripheral driver in the base system, in general you will use the kern category. (There are a few exceptions; see below). In general these are things that are described in section 2, 3, or 4 of the manual pages. - If the problem would otherwise be filed in kern but has to do with the USB subsystem, the correct choice is usb. I think that that article should be made more prominent. -- Andriy Gapon ___ 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: 7.3: instant panic upon connecting a umass
on 07/04/2010 14:20 Julian H. Stacey said the following: > I wonder if it's eg a corrupt FS not being fsck'd first ? Have you given a look to the backtrace that Mikhail had posted? I think that it answers your question. -- Andriy Gapon ___ 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 problem with new MacBook Pro.
on 26/04/2010 22:31 Peter Ankerstål said the following: > I managed to get the boot-process past the ACPI-part by adding > similar lines like above (MacBookPro7,1) to the FreeBSD HEAD branch (as of 26 > April 19:00 CEST). Made a release iso like this: > http://romana.now.ie/writing/customfreebsdiso.html > > But now the boot-process panics at a later stage in the process and it looks > like this: > http://www.pean.org/macbook_boot.jpg > > Any pointers? Wow, a 3833x2492 screenshot of a text console! Can you execute 'bt' at the last prompt? -- Andriy Gapon ___ 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 problem with new MacBook Pro.
on 26/04/2010 23:49 Peter Ankerstål said the following: > > On 26 apr 2010, at 22.21, Andriy Gapon wrote: > >> on 26/04/2010 22:31 Peter Ankerstål said the following: >>> I managed to get the boot-process past the ACPI-part by adding >>> similar lines like above (MacBookPro7,1) to the FreeBSD HEAD branch (as of >>> 26 April 19:00 CEST). Made a release iso like this: >>> http://romana.now.ie/writing/customfreebsdiso.html >>> >>> But now the boot-process panics at a later stage in the process and it >>> looks like this: >>> http://www.pean.org/macbook_boot.jpg >>> >>> Any pointers? >> Wow, a 3833x2492 screenshot of a text console! >> Can you execute 'bt' at the last prompt? > > No, sorry. No input seems to work. Do you have KDB_TRACE in your kernel config? If not, please try adding it. Thanks. -- Andriy Gapon ___ 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: usbconfig reset ugen4.2 hanging since an hour
on 02/11/2010 14:00 Hans Petter Selasky said the following: > On Tuesday 02 November 2010 11:01:34 Alexander Leidinger wrote: >> # procstat -kk 29213 >>PIDTID COMM TDNAME KSTACK >> 29213 100291 usbconfig-mi_switch+0x188 >> sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30 >> usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d >> ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21 >> >>> somewhere in umass_detach(), which is preventing the usbconfig reset from >> >> No umass_detach in there... > > Hi, > > The USB threads are joined into a single process and not visible from "ps". > Not sure how you can get a list of all threads. -H option would that for ps. But I am not why mentioned ps, because procstat shows the threads, e.g. procstat -k -a will show stacks of all non-running kernel threads. -- Andriy Gapon ___ 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: usb/138548: [usb67] [usb8] usb devices periodically have unknown activity
The following reply was made to PR usb/138548; it has been noted by GNATS. From: Andriy Gapon To: bug-follo...@freebsd.org, yeren...@gmail.com Cc: Subject: Re: usb/138548: [usb67] [usb8] usb devices periodically have unknown activity Date: Mon, 15 Nov 2010 10:50:19 +0200 BTW, just a guess, the source of activity could be hald. -- Andriy Gapon ___ 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: Two questions: how to specify module-load function for driver module and which name of driver is better (according to "standards")
on 19/11/2010 17:55 Lev Serebryakov said the following: > Hello, Freebsd-usb. > > I've implemented driver (ucom-subdriver) for MosChip 7820 and 7840 > USB2COM multiport bridges. I have two questions: > > (1) How should I specify module-load function? DRIVER_MODULE() > doesn't help much. Are you sure? The last two arguments to DRIVER_MODULE() look like what you want. > I need to run some code only once, at very > beginning, not for each probe/attach. -- Andriy Gapon ___ 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: "Autosense failed" - I/O stops on SD card reader
on 04/12/2010 16:40 Bruce Cran said the following: > Hi, > > I've been having problems with a card reader > (http://www.frontier-electronics.co.za/stor_sdr012.htm) > and an 8GB SD card > (http://www.amazon.co.uk/Transcend-SDHC-Class-Flash-Memory/dp/B000P9ZBFA) > I'm trying to use. FreeBSD 9-CURRENT will regularly display the > following error which causes all IO to stop: > > (da0:umass-sim0:0:0:0): AutoSense failed As I understand, "AutoSense" is an automatic fetching of sense data in case of an error. Strange that that error is not reported here. It would give a much better idea of what was going on. > g_vfs_done():da0s1[READ(offset=6782976, length=36864)]error = 5 > vnode_pager_getpages: I/O read error > vm_fault: pager read error, pid 2986 (cp) > > I tried setting hw.usb.umass.debug=1 but there was no extra debug > output; setting hw.usb.ehci.debug=1 or hw.usb.debug=1 results in > lots of output that I'm not sure is useful. > What would I need to do to help debug what's going wrong? -- Andriy Gapon ___ 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: USB related panic on 8.2-PRERELEASE
on 10/12/2010 20:15 Hans Petter Selasky said the following: > Hi, > > I think this is a known issue which never got fixed. Please try the attached > patch and report back. > > XXX_SAFE != XXX_REAL_SAFE :-) SAFE in sys/queue.h macros means only that it is safe to unlink/free current element in the loop body. Specifically it has nothing to do with concurrent modifications and locking. So, yes :) > On Thursday 09 December 2010 12:02:48 Oleg Nauman wrote: >> On Wed, Dec 8, 2010 at 7:05 PM, Oleg Nauman wrote: >>> Hello Hans, >>> >>> On Wed, Dec 8, 2010 at 3:33 PM, Hans Petter Selasky > wrote: >>>> On Wednesday 08 December 2010 11:41:28 Oleg Nauman wrote: >>>>> Hello, >>>>> >>>>> Unfortunately my notebook experienced the crash during the attempts to >>>>> attach EVDO modem supplied with builtin MicroSD cardreader. >>>>> Related core.txt file is attached as well as 'usbconfig >>>>> dump_all_config_desc' output (all_config.txt) >>>>> USB subsystem reports endless USB_ERR_STALLED events during attempts >>>>> to attach umass device, but attaches it finally ( sometimes it >>>>> attached after two attempts, sometimes it trying to attach during >>>>> 15-20 minutes ).MicroSD is inserted there, without any effect on >>>>> attachment attempts though. >>>> >>>> Hi, >>>> >>>> Can you reproduce the panic using a kernel built with INVARIANTS options >>>> and DEBUG_MEMGUARD . >>> >>> I rebuilt my kernel with options you mentioned ( have added >>> INVARIANT_SUPPORT required by INVARIANTS though ) >>> >>> Waiting on panic.. >> >> Got it finally ( core.txt file is attached ) >> -- Andriy Gapon ___ 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"
usbdump not connected to build?
It seems that usbdump not connected to the build? Is it nor ready yet or something else? Thanks. -- Andriy Gapon ___ 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"
use_generic and usb probing
Mostly out of curiosity (but not only because of that) I wonder why the use_generic flag and two probing passes are needed in USB driver probing code. That is, why the standard approach of using different probing return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't work here. Thanks! -- Andriy Gapon ___ 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: use_generic and usb probing
on 03/04/2011 13:46 Andriy Gapon said the following: > > Mostly out of curiosity (but not only because of that) I wonder why the > use_generic flag and two probing passes are needed in USB driver probing code. > That is, why the standard approach of using different probing return values > (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't work here. I couldn't find any historic reason for this, so I am assuming that this is a kludge to work-around inconsistent return values in various USB "newbus" probe routines. Please see here my attempt at cleaning up the basics: http://people.freebsd.org/~avg/usb-use_generic.diff Reviews and testing are welcome. P.S. A side-effect of this patch is removal of a minor annoyance in a form of the following message: Unknown USB device: vendor <> product <> bus <> The message is produced by devd almost any time anything is connected via USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) use_generic=0 probing pass in USB. -- Andriy Gapon ___ 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: use_generic and usb probing
on 05/04/2011 14:21 Hans Petter Selasky said the following: > On Tuesday 05 April 2011 13:06:22 Andriy Gapon wrote: >> on 03/04/2011 13:46 Andriy Gapon said the following: >>> Mostly out of curiosity (but not only because of that) I wonder why the >>> use_generic flag and two probing passes are needed in USB driver probing >>> code. That is, why the standard approach of using different probing >>> return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't >>> work here. >> >> I couldn't find any historic reason for this, so I am assuming that this is >> a kludge to work-around inconsistent return values in various USB "newbus" >> probe routines. >> >> Please see here my attempt at cleaning up the basics: >> http://people.freebsd.org/~avg/usb-use_generic.diff >> >> Reviews and testing are welcome. >> >> P.S. >> A side-effect of this patch is removal of a minor annoyance in a form of >> the following message: >> Unknown USB device: vendor <> product <> bus <> >> The message is produced by devd almost any time anything is connected via >> USB thanks to (1) a nomatch USB entry in the default devd.conf; (2) >> use_generic=0 probing pass in USB. > > Hi, > > In the initial USB stack design drivers are supposed to either report match > or > non-match. The reason for this is that sometimes parameters are passed on > from > the probe to the attach via the USB attach args. > > See usbd_lookup_id_by_uaa(). > > When multiple drivers are probed and match, the information presented by the > usb_attach_arg's can get messed up with regard to the attaching driver. > > It would be better if the newbus could support a probing priority argument! I believe that newbus already supports ordering of children on a bus. BTW, does USB have to pass anything from probe to attach? Duplicate lookup is of course not very nice, but duplicate probing pass is not nice either. -- Andriy Gapon ___ 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: use_generic and usb probing
on 05/04/2011 15:55 Hans Petter Selasky said the following: > On Tuesday 05 April 2011 14:50:43 Andriy Gapon wrote: >> >> I believe that newbus already supports ordering of children on a bus. >> >> BTW, does USB have to pass anything from probe to attach? > > Mostly only the driver info field. To avoid duplicate lookups. > >> Duplicate lookup is of course not very nice, but duplicate probing pass is >> not nice either. > > This can all be avoided if the bus-drivers are sorted correctly before > probing! Well, I think that that's what probe priorities actually for. I also think that typically ivars should be set by a bus driver. So maybe it's not such a good idea to pass data from probe to attach via ivars in child drivers. But I could be mistaken about that. Practically speaking, you most likely don't have to worry about that for drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And there is only a few "generic" drivers that can be handled on a case by case basis. -- Andriy Gapon ___ 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: use_generic and usb probing
on 06/04/2011 10:33 Hans Petter Selasky said the following: > After looking at subr_usb.c I see your solution is fine as long as the > PROBE() > method that it attaches is the last one called before ATTACH(). If this is > documented in how newbus should function, then please go ahead updating your > patch to cover all USB drivers using use_generic. Which drivers I have missed? Thanks! -- Andriy Gapon ___ 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: use_generic and usb probing
on 06/04/2011 16:28 Hans Petter Selasky said the following: > On Wednesday 06 April 2011 15:21:19 Andriy Gapon wrote: >> on 06/04/2011 10:33 Hans Petter Selasky said the following: > >> >> Which drivers I have missed? >> Thanks! > > Run a kernel test compile including all modules. If that's OK it should be > fine. Yes, that's how I tested it. I also used 'glimpse' to find all occurrences of use_generic :) -- Andriy Gapon ___ 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: use_generic and usb probing
on 13/04/2011 00:48 Nick Hibma said the following: >> Well, I think that that's what probe priorities actually for. I also think >> that typically ivars should be set by a bus driver. So maybe it's not such a >> good idea to pass data from probe to attach via ivars in child drivers. But I >> could be mistaken about that. >> >> Practically speaking, you most likely don't have to worry about that for >> drivers that return BUS_PROBE_SPECIFIC (=0) from their probe methods. And >> there is only a few "generic" drivers that can be handled on a case by case >> basis. > > Newbus priorities where specifically implemented on my request by Doug Rabson > to cater for fallback attachments: usb.h (the old code) contained a list of > priorities. ugen had the lowest priority and attached if no one else did. An > example was a keyboard with a built-in mouse on one interface. It would be > attached by either mouse or keyboard but not both. An additional driver could > probide both devices. We ended up implementing that differently though: > attachment to interfaces instead of devices. OK. Though I don't see how that is related to the question that I raised. > A probe should not pass any information to the attach phase if it can at all > avoid it. Or at least that is the assumption. If a driver needs info in both > phases, it needs to regenerate it again. The fact that usb_probe is called > again is a kludge, specifically for the description. I am not sure that I understood this part. > I guess that documenting this kludge and updating the comment to state this > fact would be sufficient to solve the problem. I don't see how this follows from what you've written above. -- Andriy Gapon ___ 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: use_generic and usb probing
on 06/04/2011 16:28 Hans Petter Selasky said the following: > > Run a kernel test compile including all modules. If that's OK it should be > fine. So I am going to commit this. If it breaks anything for anyone and the problem would not be really trivial, the I'll just revert the change. -- Andriy Gapon ___ 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: use_generic and usb probing
on 17/05/2011 10:19 Andriy Gapon said the following: > So I am going to commit this. > If it breaks anything for anyone and the problem would not be really trivial, > the I'll just revert the change. > r222051. Please take this commit in consideration if you run into any USB-related problems. -- Andriy Gapon ___ 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: System hang in USB umass module while processing panic
on 19/05/2011 22:27 Shah, Vishal said the following: > In FreeBSD 8 USB driver, commands are asynchronously sent from umass layer > onto > the wire, in other words, multiple threads are involved before the command is > sent from the umass layer all the way to the wire. Since the usb_proc is not > scheduled current process keeps waiting for the command to complete, hence the > hang. Is this a known issue? If yes, is there a fix available? Are there any > plans of adding a synchronous path to send the command to the device? Any > information regarding this issue is much appreciated. >From your description this sounds like a problem in USB driver. I am not an expert in USB code, looks like some polling prodding would have to be added there (if it's not there yet). Hans Petter may be a better contact for this issue. I am not sure if I can help you more. -- Andriy Gapon ___ 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: /dev/ugen*.* modes
on 04/07/2011 09:25 Zeus V Panchenko said the following: > Hi, > > how can i set /dev/ugen*.* mode and owner to allow not root to r/w > the device? > > when i plug my photo camera i have to change the mode 666 to access it > ... > > i was trying it in /etc/devfs.conf: > > own ugen0.1 zeus:staff > own ugen0.2 zeus:staff > ... > own ugen2.4 zeus:staff > > permugen0.1 0660 > permugen0.2 0660 > ... > permugen2.4 0660 > > and after device plugged in, the owner changes to toor:operator ... > You have to use devfs.rules(5) for dynamically attaching devices. -- Andriy Gapon ___ 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"
epson perfection v33
Just trying to find out if anyone got Epson Perfection v33 USB scanner working with SANE on FreeBSD. Or any other similar Epson scanner that requires proprietary drivers from Avasys under Linux. Thanks! -- Andriy Gapon ___ 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"
skipping locks, mutex_owned, usb
Yes, the subject sounds quite hairy, so please let me try to explain it.
First, let's consider one concrete function:
static int
ukbd_poll(keyboard_t *kbd, int on)
{
struct ukbd_softc *sc = kbd->kb_data;
if (!mtx_owned(&Giant)) {
/* XXX cludge */
int retval;
mtx_lock(&Giant);
retval = ukbd_poll(kbd, on);
mtx_unlock(&Giant);
return (retval);
}
if (on) {
sc->sc_flags |= UKBD_FLAG_POLLING;
sc->sc_poll_thread = curthread;
} else {
sc->sc_flags &= ~UKBD_FLAG_POLLING;
ukbd_start_timer(sc); /* start timer */
}
return (0);
}
This "XXX cludge" [sic] pattern is scattered around a few functions in the ukbd
code and perhaps other usb code:
func()
{
if (!mtx_owned(&Giant)) {
mtx_lock(&Giant);
func();
mtx_unlock(&Giant);
return;
}
// etc ...
}
I have a few question directly and indirectly related to this pattern.
I. [Why] do we need this pattern?
Can the code be re-written in a smarter (if not to say proper) way?
II. ukbd_poll() in particular can be called from the kdb context (kdb_trap ->
db_trap -> db_command_loop -> etc). What would happen if the Giant is held by a
thread on some other CPU (which would be hard-stopped by kdp_trap)? Won't we
get
a lockup here?
So shouldn't this code actually check for kdb_active?
III. With my stop_scheduler_on_panic patch ukbd_poll() produces infinite chains
of 'infinite' recursion because mtx_owned() always returns false. This is
because
I skip all lock/unlock/etc operations in the post-panic context. I think that
it's a good philosophical question: what operations like mtx_owned(),
mtx_recursed(), mtx_trylock() 'should' return when we actually act as if no
locks
exist at all?
My first knee-jerk reaction was to change mtx_owned() to return true in this
"lock-less" context, but _hypothetically_ there could exist some symmetric code
that does something like:
func()
{
if (mtx_owned(&Giant)) {
mtx_unlock(&Giant);
func();
mtx_lock(&Giant);
return;
}
// etc ...
What do you think about this problem?
Should we re-write ukbd_poll() (and possibly usb code) or should mutex_owned()
be
adjusted?
That question III actually brings another thought: perhaps the whole of idea of
skipping locks in a certain context is not a correct direction?
Perhaps, instead we should identify all the code that could be legitimately
executed in the after-panic and/or kdb contexts and make that could explicitly
aware of its execution context. That is, instead of trying to make _lock,
_unlock, _owned, _trylock, etc do the right thing auto-magically, we should try
to
make the calling code check panicstr and kdb_active and do the right thing on
that
level (which would include not invoking those lock-related operations or other
inappropriate operations).
Thank you very much in advance for your insights and help!
--
Andriy Gapon
___
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: Connecting Nokia C2 cell phone
on 26/08/2011 21:30 Matthias Apitz said the following: > El día Friday, August 26, 2011 a las 07:44:35PM +0200, Jens Jahnke escribió: > >> Hi, >> >> I just plugged my nokia c2 cell phone into my usb port an got the >> following output in messages: >> >> Aug 26 19:42:04 magni kernel: ugen4.2: at usbus4 >> Aug 26 19:42:05 magni root: Unknown USB device: vendor 0x0421 product >> 0x054d bus uhub4 > > Hi, > > The message means, that no other diver attaches to this vendor/product > ID of your device. Actually unless this is a quite recent head or stable/8, then that message doesn't mean anything at all. Just in case. -- Andriy Gapon ___ 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"
usb multimedia keyboard
I have a problem similar to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=102066 My keyboard has a label on it that says the following: Product Name: KB 200 Model NO: GK-060002 Trade Name: KYE SYSTEMS CORP Made in China There is also Genius label on it :-) $ uname -srm FreeBSD 6.2-RELEASE-p2 amd64 $ usbdevs -dv Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x), nVidia(0x), rev 1.00 uhub0 port 1 addr 2: low speed, power 100 mA, config 1, NetScroll + Traveler(0x002e), Genius(0x0458), rev 1.10 ums0 port 2 addr 3: low speed, power 100 mA, config 1, USB Keyboard(0x1603), vendor 0x1241(0x1241), rev 2.80 ukbd0 ... The problem is that under X xev program doesn't show any events for pressing of extra keys (6 multimedia ones and 3 ACPI ones). In Linux xev does show key events for those keys. Is it possible at present at all to get those keys working ? Where to dig ? -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb multimedia keyboard
on 04/04/2007 11:56 Andriy Gapon said the following: > I have a problem similar to this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=102066 [snip] > > The problem is that under X xev program doesn't show any events for > pressing of extra keys (6 multimedia ones and 3 ACPI ones). > > In Linux xev does show key events for those keys. > > Is it possible at present at all to get those keys working ? > Where to dig ? > This provides a lot of additional information but doesn't seem to provide a complete solution: http://www.freebsd.org/cgi/query-pr.cgi?pr=59698 -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
usbd_set_config_no vs. usbd_set_config_index
I am curious about a difference between usbd_set_config_no and usbd_set_config_index. My reason is such: I am trying to use palm/uppc-kmod to talk to my pocket pc device via usb. When I used the port in its original shape it gave me the following error each time I plugged the device: kernel: ucom0: failed to set configuration, err=STALLED kernel: device_attach: ucom0 attach returned 6 Then, to mimic some other driver I simply changed usbd_set_config_index() to usbd_set_config_no() in the code, and voila: kernel: ucom0: ASUS ASUS Windows Mobile Device, rev 2.00/0.00, addr 3 (rt) I am now trying to get synce to actually work. But I am really curious what my change really did, and I am totally ignorant about our usb code. BTW: FreeBSD 6.2-RELEASE-p3 amd64 Thank you in advance for my education. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
scsi_da quirk for a device with "no name"
I have ASUS P535 PPC+phone with Windows Mobile 5 on it.
It has an option to act as a USB mass storage (instead of attempting
acivesync).
When I tried it, it first got recognized by umass and then it
immediately panicked my system.
>From messages:
kernel: umass0: ASUS Generic Mass Storage, rev 2.00/0.00, addr 3
kernel: da0 at umass-sim0 bus 0 target 0 lun 0
kernel: da0: < > Removable Direct Access SCSI-0 device
kernel: da0: 1.000MB/s transfers
kernel: da0: 1952MB (3998720 512 byte sectors: 255H 63S/T 248C)
>From panic (typed from memory):
umass0: Invalid CSW: tag 7 should be 8
(da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x0, scsi
status == 0x4
I googled up several reports of similar and not so similar panics.
Here's a small overview that is not directly related to a question that
I really want to ask:
1. Invalid CSW problems where a signature is wrong, I see that
WRONG_CSWSIG umass quirk is recommended for that;
2. Invalid CSW problems where a tag is wrong and the values are very
different, I see that one person attempted to cure that with a new
hand-rolled quirk to simply ignore the mismatch;
3. Invalid CSW problems where a tag is wrong and the difference is
exactly one. I don't know if there is anything special about that, but
it looks the most interesting of all the cases.
In some cases but not all "Invalid CSW" comes together with "Synchronize
cache failed" and DA_Q_NO_SYNC_CACHE scsi_da quirk is recommended for that.
So I attempted the latter quirk and it helped me! But there is one not
good thing about the way I did that - I used wild cards ("*") for all
three of vendor, product and revision. This is because they all appear
to be empty/unset. This is shown in both kernel messages and by
camcontrol devlist and by camcontrol inquiry.
I am not sure if there are any risks of applying the quirk to all
possible da devices, there will be only umass ones in my case, but I
still would like to do something more specific to the device in question.
Will empty patterns work ? I mean if I put "", "", "" entry into the
quirk array. Actually, I can test this myself soon, but not today.
Thank you.
P.S. some links to the problems that others have reported:
http://www.freebsd.org/cgi/query-pr.cgi?pr=114916&cat=
http://osdir.com/ml/os.freebsd.devel.usb/2005-12/msg00039.html
http://lists.freebsd.org/pipermail/freebsd-bugs/2004-November/010483.html
http://lists.freebsd.org/pipermail/freebsd-bugs/2004-January/005170.html
http://lists.freebsd.org/mailman/htdig/freebsd-usb/2004-December/000318.html
http://lists.freebsd.org/mailman/htdig/freebsd-usb/2005-February/000660.html
--
Andriy Gapon
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usbd_set_config_no vs. usbd_set_config_index
on 15/08/2007 18:41 Hans Petter Selasky said the following: > On Wednesday 15 August 2007, Andriy Gapon wrote: >> I am curious about a difference between usbd_set_config_no and >> usbd_set_config_index. My reason is such: I am trying to use >> palm/uppc-kmod to talk to my pocket pc device via usb. When I used the >> port in its original shape it gave me the following error each time I >> plugged the device: >> kernel: ucom0: failed to set configuration, err=STALLED >> kernel: device_attach: ucom0 attach returned 6 >> >> Then, to mimic some other driver I simply changed >> usbd_set_config_index() to usbd_set_config_no() in the code, and voila: >> kernel: ucom0: ASUS ASUS Windows Mobile Device, rev >> 2.00/0.00, addr 3 (rt) >> >> I am now trying to get synce to actually work. >> But I am really curious what my change really did, and I am totally >> ignorant about our usb code. >> BTW: >> FreeBSD 6.2-RELEASE-p3 amd64 >> >> Thank you in advance for my education. > > Hi, > > usbd_set_config_no will search for a matching bConfiguration value. > > usbd_set_config_index will set the configuration by physical index: 0, 1, > 2 ... > Thank you! Is it safe to assume that *_no is "more robust" than "*_index" and in drivers for general classes of devices it should be preferred ? And _index should only be used in very specific cases where we are sure of what we are doing ? Or am I talking nonsense ? It is curious to compare the following: $ glimpse -l usbd_set_config_no /usr/src/sys/dev/usb/usb_subr.h /usr/src/sys/dev/usb/if_zyd.c /usr/src/sys/dev/usb/uscanner.c /usr/src/sys/dev/usb/if_ural.c /usr/src/sys/dev/usb/if_kue.c /usr/src/sys/dev/usb/if_aue.c /usr/src/sys/dev/usb/ugen.c /usr/src/sys/dev/usb/if_axe.c /usr/src/sys/dev/usb/if_udav.c /usr/src/sys/dev/usb/if_rue.c /usr/src/sys/dev/usb/usb_subr.c /usr/src/sys/dev/usb/if_cue.c /usr/src/sys/dev/usb/usbdi_util.h /usr/src/sys/netgraph/bluetooth/drivers/ubtbcmfw/ubtbcmfw.c $ glimpse -l usbd_set_config_index /usr/src/sys/dev/usb/usb_subr.h /usr/src/sys/dev/usb/ugensa.c /usr/src/sys/dev/usb/umoscom.c /usr/src/sys/dev/usb/ugen.c /usr/src/sys/dev/usb/uplcom.c /usr/src/sys/dev/usb/umct.c /usr/src/sys/dev/usb/uvisor.c /usr/src/sys/dev/usb/uvscom.c /usr/src/sys/dev/usb/usb_subr.c /usr/src/sys/dev/usb/uhub.c /usr/src/sys/dev/usb/uftdi.c /usr/src/sys/dev/usb/usbdi_util.h /usr/src/sys/dev/usb/ubsa.c /usr/src/sys/dev/usb/ucycom.c -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usbd_set_config_no vs. usbd_set_config_index
on 16/08/2007 19:15 Hans Petter Selasky said the following: > Hi, > > I would say that "usbd_set_config_index()" is more reliable and faster > than "usbd_set_config_no()". I tried to get rid of > all "usbd_set_config_no()". Hmm, then I am puzzled how my change from *_index() to *_no() helped in my case. Maybe some parameters were incorrect, or maybe different devices need different parameters and that's where _no() comes useful. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usbd_set_config_no vs. usbd_set_config_index
on 16/08/2007 19:41 Hans Petter Selasky said the following: > On Thursday 16 August 2007, Andriy Gapon wrote: >> on 16/08/2007 19:15 Hans Petter Selasky said the following: >>> Hi, >>> >>> I would say that "usbd_set_config_index()" is more reliable and faster >>> than "usbd_set_config_no()". I tried to get rid of >>> all "usbd_set_config_no()". >> Hmm, then I am puzzled how my change from *_index() to *_no() helped in >> my case. Maybe some parameters were incorrect, or maybe different >> devices need different parameters and that's where _no() comes useful. > > What config number are you setting? > > Have you dumped the configuration of your device using "udesc_dump" > (See /usr/ports/sysutils/udesc_dump) ? Thank you for bearing with me. To reiterate: I was trying palm/uppc-kmod on amd64 6.2 with standard USB stack. attach routine had the following line: err = usbd_set_config_index(dev, UPPC_CONFIG_INDEX, 1); where UPPC_CONFIG_INDEX is defined to 1. It failed with: kernel: ucom0: failed to set configuration, err=STALLED kernel: device_attach: ucom0 attach returned 6 My only change was from _index to _no and then it started to work. Here's udesc_dump full output: Standard Device Descriptor: bLength18 bDescriptorType01 bcdUSB 0200 bDeviceClass 00 bDeviceSubClass00 bDeviceProtocol00 bMaxPacketSize 16 idVendor 0b05 idProduct 420f bcdDevice iManufacturer 1 iProduct 2 iSerialNumber 3 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength32 bNumInterface 1 bConfigurationValue 1 iConfiguration 0 bmAttributes80 bMaxPower 250 (500 mA) Standard Interface Descriptor: bLength9 bDescriptorType04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClassff bInterfaceSubClass ff bInterfaceProtocol ff iInterface 0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 02 (out) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval0 Codes Representing Languages by the Device: bLength 4 bDescriptorType 03 wLANGID[0] 0409 String (index 1): ASUS String (index 2): ASUS PPC String (index 3): f553b4ec-0dee-9dcc-7a63-40a7b4d674b9 -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi_da quirk for a device with "no name"
on 16/08/2007 15:22 Andriy Gapon said the following:
> I have ASUS P535 PPC+phone with Windows Mobile 5 on it.
> It has an option to act as a USB mass storage (instead of attempting
> acivesync).
[snip]
> So I attempted the latter quirk and it helped me! But there is one not
> good thing about the way I did that - I used wild cards ("*") for all
> three of vendor, product and revision. This is because they all appear
> to be empty/unset. This is shown in both kernel messages and by
> camcontrol devlist and by camcontrol inquiry.
> I am not sure if there are any risks of applying the quirk to all
> possible da devices, there will be only umass ones in my case, but I
> still would like to do something more specific to the device in question.
>
> Will empty patterns work ? I mean if I put "", "", "" entry into the
> quirk array. Actually, I can test this myself soon, but not today.
No, empty strings/patterns (all 3 of them) do not work.
Are there any better ways ?
I know, "use the source, Luke" :-)
--
Andriy Gapon
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
usb rndis
What is status of support of USB devices that talk (MS) RNDIS ? Are there any news or clever hacks ? Essentially I am trying to connect to internet my FreeBSD computer using GPRS via Asus P535 device that runs WM5 (AKU 3). I use "Internet Sharing" program on the device side. I tried using cdce but it doesn't attach to my device. I am open to any suggestions both on PC and device sides. Dump from udesc_dump follows. As I understand from http://www.usb.org/developers/defined_class class e0, subclass 1, protocol 3 seems to mean "Remote NDIS". There is a huge linux patch that seems to be designed to add or improve RNDIS support: http://riksun.riken.go.jp/pub/pub/Linux/kernel/people/gregkh/gregkh-2.6/gregkh-03-usb-2.6.20-rc1-git7.patch Standard Device Descriptor: bLength18 bDescriptorType01 bcdUSB 0200 bDeviceClass e0 bDeviceSubClass01 bDeviceProtocol03 bMaxPacketSize 16 idVendor 0b05 idProduct 424f bcdDevice iManufacturer 1 iProduct 2 iSerialNumber 3 bNumConfigurations 1 Configuration 0: Standard Configuration Descriptor: bLength 9 bDescriptorType 02 wTotalLength62 bNumInterface 2 bConfigurationValue 1 iConfiguration 0 bmAttributes80 bMaxPower 250 (500 mA) Standard Interface Descriptor: bLength9 bDescriptorType04 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClasse0 bInterfaceSubClass 01 bInterfaceProtocol 03 iInterface 0 Descriptor: bLength5 bDescriptorType24 bDescriptorSubtype 01 05 24 01 00 01 Descriptor: bLength4 bDescriptorType24 bDescriptorSubtype 02 04 24 02 00 Descriptor: bLength5 bDescriptorType24 bDescriptorSubtype 02 05 24 02 00 01 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 81 (in) bmAttributes 03 (Interrupt) wMaxPacketSize 8 bInterval1 Standard Interface Descriptor: bLength9 bDescriptorType04 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass0a bInterfaceSubClass 00 bInterfaceProtocol 00 iInterface 0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 82 (in) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval0 Standard Endpoint Descriptor: bLength 7 bDescriptorType 05 bEndpointAddress 03 (out) bmAttributes 02 (Bulk) wMaxPacketSize 64 bInterval0 Codes Representing Languages by the Device: bLength 4 bDescriptorType 03 wLANGID[0] 0409 String (index 1): ASUS String (index 2): ASUS Windows Mobile Device String (index 3): f553b4ec-0dee-9dcc-7a63-40a7b4d674b9 -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA3 kernel panic when unplugging USB stick
on 27/11/2007 10:55 Remko Lodder said the following: > [snip] > >> Just in case: >> the reader - Trust CR-1420P >> the card - SanDisk SDSDM-2048 > > The above information is not really informative for me , can you send a > dmesg -v and pciconf -vl so that we might trick it into getting supported > by the current drivers? :) >From usbdevs -vd: Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x), nVidia(0x), rev 1.00 uhub1 ... port 4 addr 2: high speed, power 100 mA, config 1, product 0x6362(0x6362), vendor 0x058f(0x058f), rev 1.26 umass0 >From dmesg: umass0: Generic Mass Storage Device, rev 2.00/1.26, addr 2 umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device >From pciconf- lv: [EMAIL PROTECTED]:11:1:class=0x0c0320 card=0x81c01043 chip=0x026e10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' class= serial bus subclass = USB >From camcontrol devlist -v: scbus6 on umass-sim0 bus 0: at scbus6 target 0 lun 0 (da0,pass2) < > at scbus6 target 0 lun 2 (probe0) < > at scbus6 target -1 lun -1 () -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
unnoticed disconnect
I have a strange problem - when I disconnect a certain USB card reader its umass* and da* devices are not removed, there is complete silence in the system log and usbdevs -vd still shows it as connected. Restarting usbd and/or running usbd -e doesn't change anything. If I reconnect the device there is zero reaction as well and da* devices are unusable (any access produces several BBB ... IOERROR). But if attach another USB device (e.g. USB flash drive) while the reader is disconnected then the system notices that it's actually gone and performs all the necessary disconnect actions. This is quite weird for me. My question if this is something most likely caused by software or something caused by the hardware. And if the latter - what is most likely at fault: the reader, connecting cable, physical port, hub ? -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: unnoticed disconnect
on 25/12/2007 13:03 Andriy Gapon said the following: > I have a strange problem - when I disconnect a certain USB card reader > its umass* and da* devices are not removed, there is complete silence in > the system log and usbdevs -vd still shows it as connected. > Restarting usbd and/or running usbd -e doesn't change anything. > If I reconnect the device there is zero reaction as well and da* devices > are unusable (any access produces several BBB ... IOERROR). > But if attach another USB device (e.g. USB flash drive) while the reader > is disconnected then the system notices that it's actually gone and > performs all the necessary disconnect actions. > > This is quite weird for me. My question if this is something most likely > caused by software or something caused by the hardware. And if the > latter - what is most likely at fault: the reader, connecting cable, > physical port, hub ? > Additional fact: it seems that I can produce the effect with ~80% on port 1 and port 2 of hub 1 and so far I couldn't reproduce it at all on port 8 of the same hub. This is after about the same number of attempts on all three ports. The only difference is that port 1 and port 2 are at the rear panel and port 8 is at the front. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-BETA3 kernel panic when unplugging USB stick
Below was info when the reader was connected already with the troublesome SD card inserted. Here's info when the same reader is connected without any media: demsg: umass0: Generic Mass Storage Device, rev 2.00/1.26, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present Opened disk da0 -> 6 da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present Opened disk da1 -> 6 da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present Opened disk da2 -> 6 da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Opened disk da3 -> 6 camcontrol: scbus6 on umass-sim0 bus 0: at scbus6 target 0 lun 0 (da0,pass2) at scbus6 target 0 lun 1 (da1,pass3) at scbus6 target 0 lun 2 (da2,pass4) at scbus6 target 0 lun 3 (da3,pass5) usbdevs: port 4 addr 2: high speed, power 100 mA, config 1, Mass Storage Device(0x6362), Generic(0x058f), rev 1.26 on 25/12/2007 13:26 Andriy Gapon said the following: > on 27/11/2007 10:55 Remko Lodder said the following: >> [snip] >> >>> Just in case: >>> the reader - Trust CR-1420P >>> the card - SanDisk SDSDM-2048 >> The above information is not really informative for me , can you send a >> dmesg -v and pciconf -vl so that we might trick it into getting supported >> by the current drivers? :) > > From usbdevs -vd: > Controller /dev/usb1: > addr 1: high speed, self powered, config 1, EHCI root hub(0x), > nVidia(0x), rev 1.00 > uhub1 > ... > port 4 addr 2: high speed, power 100 mA, config 1, product > 0x6362(0x6362), vendor 0x058f(0x058f), rev 1.26 >umass0 > > From dmesg: > umass0: Generic Mass Storage Device, rev 2.00/1.26, addr 2 > umass0: BBB reset failed, IOERROR > umass0: BBB bulk-in clear stall failed, IOERROR > umass0: BBB bulk-out clear stall failed, IOERROR > umass0: BBB reset failed, IOERROR > umass0: BBB bulk-in clear stall failed, IOERROR > umass0: BBB bulk-out clear stall failed, IOERROR > umass0: BBB reset failed, IOERROR > umass0: BBB bulk-in clear stall failed, IOERROR > umass0: BBB bulk-out clear stall failed, IOERROR > umass0: BBB reset failed, IOERROR > umass0: BBB bulk-in clear stall failed, IOERROR > umass0: BBB bulk-out clear stall failed, IOERROR > umass0: BBB reset failed, IOERROR > umass0: BBB bulk-in clear stall failed, IOERROR > umass0: BBB bulk-out clear stall failed, IOERROR > umass0: BBB reset failed, IOERROR > umass0: BBB bulk-in clear stall failed, IOERROR > umass0: BBB bulk-out clear stall failed, IOERROR > (da0:umass-sim0:0:0:0): got CAM status 0x4 > (da0:umass-sim0:0:0:0): fatal error, failed to attach to device > (da0:umass-sim0:0:0:0): lost device > > From pciconf- lv: > [EMAIL PROTECTED]:11:1:class=0x0c0320 card=0x81c01043 chip=0x026e10de > rev=0xa3 hdr=0x00 > vendor = 'NVIDIA Corporation' > class= serial bus > subclass = USB > > From camcontrol devlist -v: > scbus6 on umass-sim0 bus 0: >at scbus6 target 0 lun 0 (da0,pass2) > < > at scbus6 target 0 lun 2 (probe0) > < > at scbus6 target -1 lun -1 () > -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi_da quirk for a device with "no name"
This is me again on the issue of a weird umass device that reports empty
strings to SCSI inquiry command. Currently the only way to specify some
SCSI-level quirk for such a device is to create a quirk entry with all
fields set to wildcard "*", but apparently such a quirk would be applied
to many more devices.
A suggestion: what about umass intercepting a response of inquiry
command and generating some names in such a case. E.g. vendor and
product identification could be generated from the USB ids like
Vendor_abcd, Product_1234.
In this case we would get some sufficient identification for such devices.
P.S. it also seems that if NO_INQUIRY umass quirk is specified for a
device, then its identification will be empty as well. I think that this
is not good because, for example, scsi_da quirks are troublesome then.
P.P.S. it is currently impossible to have scsi_da quirk entries with
empty fields (""), they get ignored.
on 16/08/2007 15:22 Andriy Gapon said the following:
> I have ASUS P535 PPC+phone with Windows Mobile 5 on it.
> It has an option to act as a USB mass storage (instead of attempting
> acivesync).
>
> When I tried it, it first got recognized by umass and then it
> immediately panicked my system.
>
> From messages:
> kernel: umass0: ASUS Generic Mass Storage, rev 2.00/0.00, addr 3
> kernel: da0 at umass-sim0 bus 0 target 0 lun 0
> kernel: da0: < > Removable Direct Access SCSI-0 device
> kernel: da0: 1.000MB/s transfers
> kernel: da0: 1952MB (3998720 512 byte sectors: 255H 63S/T 248C)
>
> From panic (typed from memory):
> umass0: Invalid CSW: tag 7 should be 8
> (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x0, scsi
> status == 0x4
>
> I googled up several reports of similar and not so similar panics.
> Here's a small overview that is not directly related to a question that
> I really want to ask:
>
> 1. Invalid CSW problems where a signature is wrong, I see that
> WRONG_CSWSIG umass quirk is recommended for that;
> 2. Invalid CSW problems where a tag is wrong and the values are very
> different, I see that one person attempted to cure that with a new
> hand-rolled quirk to simply ignore the mismatch;
> 3. Invalid CSW problems where a tag is wrong and the difference is
> exactly one. I don't know if there is anything special about that, but
> it looks the most interesting of all the cases.
>
> In some cases but not all "Invalid CSW" comes together with "Synchronize
> cache failed" and DA_Q_NO_SYNC_CACHE scsi_da quirk is recommended for that.
>
> So I attempted the latter quirk and it helped me! But there is one not
> good thing about the way I did that - I used wild cards ("*") for all
> three of vendor, product and revision. This is because they all appear
> to be empty/unset. This is shown in both kernel messages and by
> camcontrol devlist and by camcontrol inquiry.
> I am not sure if there are any risks of applying the quirk to all
> possible da devices, there will be only umass ones in my case, but I
> still would like to do something more specific to the device in question.
>
> Will empty patterns work ? I mean if I put "", "", "" entry into the
> quirk array. Actually, I can test this myself soon, but not today.
>
> Thank you.
>
> P.S. some links to the problems that others have reported:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=114916&cat=
> http://osdir.com/ml/os.freebsd.devel.usb/2005-12/msg00039.html
> http://lists.freebsd.org/pipermail/freebsd-bugs/2004-November/010483.html
> http://lists.freebsd.org/pipermail/freebsd-bugs/2004-January/005170.html
> http://lists.freebsd.org/mailman/htdig/freebsd-usb/2004-December/000318.html
> http://lists.freebsd.org/mailman/htdig/freebsd-usb/2005-February/000660.html
>
--
Andriy Gapon
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: scsi_da quirk for a device with "no name"
[sorry for top-quoting, but I think that this should be more convenient
since I am following up on my own posts]
Warner, list, please consider the attached patch.
umass.c part of it is intended to put some meaningful data into inquiry
response if a device return completely empty identification. This is
useful when cam/scsi layer needs to have a quirk for such a device.
scsi_da.c part of it utilizes this new feature to handle ASUS P535
smartphone (phone+pda) configured to act as a mass storage device for
USB connection.
Another possible alternative to the umass.c patch is to have a new quirk
to force some inquiry data instead of dynamic inquiry response checking,
but I am not sure if that would be any better.
Would it be more convenient for everybody if I file a PR on this ?
Thank you for your attention.
on 24/01/2008 15:58 Andriy Gapon said the following:
> This is me again on the issue of a weird umass device that reports empty
> strings to SCSI inquiry command. Currently the only way to specify some
> SCSI-level quirk for such a device is to create a quirk entry with all
> fields set to wildcard "*", but apparently such a quirk would be applied
> to many more devices.
> A suggestion: what about umass intercepting a response of inquiry
> command and generating some names in such a case. E.g. vendor and
> product identification could be generated from the USB ids like
> Vendor_abcd, Product_1234.
> In this case we would get some sufficient identification for such devices.
>
> P.S. it also seems that if NO_INQUIRY umass quirk is specified for a
> device, then its identification will be empty as well. I think that this
> is not good because, for example, scsi_da quirks are troublesome then.
>
> P.P.S. it is currently impossible to have scsi_da quirk entries with
> empty fields (""), they get ignored.
>
> on 16/08/2007 15:22 Andriy Gapon said the following:
>> I have ASUS P535 PPC+phone with Windows Mobile 5 on it.
>> It has an option to act as a USB mass storage (instead of attempting
>> acivesync).
>>
>> When I tried it, it first got recognized by umass and then it
>> immediately panicked my system.
>>
>> From messages:
>> kernel: umass0: ASUS Generic Mass Storage, rev 2.00/0.00, addr 3
>> kernel: da0 at umass-sim0 bus 0 target 0 lun 0
>> kernel: da0: < > Removable Direct Access SCSI-0 device
>> kernel: da0: 1.000MB/s transfers
>> kernel: da0: 1952MB (3998720 512 byte sectors: 255H 63S/T 248C)
>>
>> From panic (typed from memory):
>> umass0: Invalid CSW: tag 7 should be 8
>> (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x0, scsi
>> status == 0x4
>>
>> I googled up several reports of similar and not so similar panics.
>> Here's a small overview that is not directly related to a question that
>> I really want to ask:
>>
>> 1. Invalid CSW problems where a signature is wrong, I see that
>> WRONG_CSWSIG umass quirk is recommended for that;
>> 2. Invalid CSW problems where a tag is wrong and the values are very
>> different, I see that one person attempted to cure that with a new
>> hand-rolled quirk to simply ignore the mismatch;
>> 3. Invalid CSW problems where a tag is wrong and the difference is
>> exactly one. I don't know if there is anything special about that, but
>> it looks the most interesting of all the cases.
>>
>> In some cases but not all "Invalid CSW" comes together with "Synchronize
>> cache failed" and DA_Q_NO_SYNC_CACHE scsi_da quirk is recommended for that.
>>
>> So I attempted the latter quirk and it helped me! But there is one not
>> good thing about the way I did that - I used wild cards ("*") for all
>> three of vendor, product and revision. This is because they all appear
>> to be empty/unset. This is shown in both kernel messages and by
>> camcontrol devlist and by camcontrol inquiry.
>> I am not sure if there are any risks of applying the quirk to all
>> possible da devices, there will be only umass ones in my case, but I
>> still would like to do something more specific to the device in question.
>>
>> Will empty patterns work ? I mean if I put "", "", "" entry into the
>> quirk array. Actually, I can test this myself soon, but not today.
>>
>> Thank you.
>>
>> P.S. some links to the problems that others have reported:
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=114916&cat=
>> http://osdir.com/ml/os.freebsd.devel.usb/2005-12/msg00039.html
>> http://lists.freebsd.org/pipermail/freebsd-bugs/2004-November/010483.html
>> http://lists.freebsd.org/pipermail/freebsd-bugs/2004-January/
usb/120572: quirk to support ASUS P535 as umass (and inquiry fixup)
>Number: 120572
>Category: usb
>Synopsis: quirk to support ASUS P535 as umass (and inquiry fixup)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-usb
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Feb 12 22:20:00 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Andriy Gapon
>Release:FreeBSD 7.0-RC1 i386
>Organization:
>Environment:
System: FreeBSD 7.0-RC1 i386
>Description:
History and details of the issue can be found in the following post:
http://docs.freebsd.org/cgi/mid.cgi?47AEFFAF.1010403
Short summary:
ASUS P535 smart phone configured to act as a umass storage requires
DA_Q_NO_SYNC_CACHE quirk in da(4). The problem is that da(4) quirks
are set based on inquiry information, but the device in question
provides entirely empty inquiry information (bytes for vendor, product
and revision are all zeroes). The only way in current infrastructure
to provide a quirk for such a device is to have a wildcard quirk
("*", "*", "*"). But that quirk would be applied to all da(4) devices,
which can not be good.
Proposed patch has two parts. umass part detects inquiry responses that
have empty vendor and product info and sets product and vendor info
to the corresponding USB device parameters (as hexadecimal numbers).
scsi_da part provides the quirk for the ASUS device in question.
Note that the umass.c part of teh patch might provide help to supporting
more similarly impaired devices.
>How-To-Repeat:
1. Get ASUS P535 device with miniSD memory card
2. configure the device to act as umass for USB connection
(Setting/Connection/USB)
3. plug into PC
4. observe info and error messages like the following:
kernel: umass0: ASUS Generic Mass Storage, rev 2.00/0.00, addr 3
kernel: da0 at umass-sim0 bus 0 target 0 lun 0
kernel: da0: < > Removable Direct Access SCSI-0 device
kernel: da0: 1.000MB/s transfers
kernel: da0: 1952MB (3998720 512 byte sectors: 255H 63S/T 248C)
umass0: Invalid CSW: tag 7 should be 8
(da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x0, scsi status ==
0x4
>Fix:
--- p535.diff begins here ---
--- sys/dev/usb/umass.c 2008-02-10 15:30:23.0 +0200
+++ sys/dev/usb/umass.c 2008-02-10 15:02:43.0 +0200
@@ -3063,6 +3059,12 @@
maxsector = scsi_4btoul(rcap->addr) - 1;
scsi_ulto4b(maxsector, rcap->addr);
}
+ else if (csio->cdb_io.cdb_bytes[0] == INQUIRY &&
+csio->data_ptr[8] == '\0' && csio->data_ptr[16] ==
'\0') {
+ usb_device_descriptor_t *dd =
usbd_get_device_descriptor(sc->sc_udev);
+ sprintf(&csio->data_ptr[8], "%04x",
UGETW(dd->idVendor));
+ sprintf(&csio->data_ptr[16], "%04x",
UGETW(dd->idProduct));
+ }
xpt_done(ccb);
break;
--- sys/cam/scsi/scsi_da.c 2008-02-10 12:40:43.0 +0200
+++ sys/cam/scsi/scsi_da.c 2008-02-10 15:09:05.0 +0200
@@ -535,6 +535,13 @@
{T_DIRECT, SIP_MEDIA_REMOVABLE, "ChipsBnk", "USB*",
"*"}, /*quirks*/ DA_Q_NO_SYNC_CACHE
},
+ {
+ /*
+* ASUS P535 in umass device mode
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, "0b05*", "422f*",
+"*"}, /*quirks*/ DA_Q_NO_SYNC_CACHE
+ },
};
static disk_strategy_t dastrategy;
--- p535.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
usb/121184: uipaq: add ids from linux ipaq driver (plus a "quirk")
>Number: 121184
>Category: usb
>Synopsis: uipaq: add ids from linux ipaq driver (plus a "quirk")
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-usb
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Feb 28 19:50:00 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Andriy Gapon
>Release:FreeBSD 7.0-RC1 i386
>Organization:
>Environment:
System: FreeBSD 7.0-RC1 i386
>Description:
Linux ipaq driver contains an extensive of supported devices that is much bigger
than a list in uipaq. Unfortunately the IDs are given purely as numbers, so it
would be
a chore to convert that to FreeBSD convention - actual defines in usbdevs and
the drivers
using macro definitions for vendor and device id.
The patch also contains a special initialization sequence that is fed to ppc
device.
This is also borrowed from the Linux driver, comment there say that the command
was
sniffedd in Win98.
>How-To-Repeat:
>Fix:
--- the.patch begins here ---
--- uipaq.c.orig2008-02-26 20:52:57.0 +0200
+++ uipaq.c 2008-02-26 22:05:47.0 +0200
@@ -120,11 +120,459 @@
};
static const struct uipaq_type uipaq_devs[] = {
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_2215 }, 0 },
- {{ USB_VENDOR_HP, USB_PRODUCT_HP_568J }, 0},
- {{ USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQPOCKETPC } , 0},
- {{ USB_VENDOR_CASIO, USB_PRODUCT_CASIO_BE300 } , 0},
- {{ USB_VENDOR_SHARP, USB_PRODUCT_SHARP_WZERO3ES }, 0},
+ {{ 0x0104, 0x00be }, 0}, /* Socket USB Sync */
+ {{ 0x03f0, 0x1016 }, 0}, /* HP USB Sync */
+ {{ 0x03f0, 0x1116 }, 0}, /* HP USB Sync 1611 */
+ {{ 0x03f0, 0x1216 }, 0}, /* HP USB Sync 1612 */
+ {{ 0x03f0, 0x2016 }, 0}, /* HP USB Sync 1620 */
+ {{ 0x03f0, 0x2116 }, 0}, /* HP USB Sync 1621 */
+ {{ 0x03f0, 0x2216 }, 0}, /* HP USB Sync 1622 */
+ {{ 0x03f0, 0x3016 }, 0}, /* HP USB Sync 1630 */
+ {{ 0x03f0, 0x3116 }, 0}, /* HP USB Sync 1631 */
+ {{ 0x03f0, 0x3216 }, 0}, /* HP USB Sync 1632 */
+ {{ 0x03f0, 0x4016 }, 0}, /* HP USB Sync 1640 */
+ {{ 0x03f0, 0x4116 }, 0}, /* HP USB Sync 1641 */
+ {{ 0x03f0, 0x4216 }, 0}, /* HP USB Sync 1642 */
+ {{ 0x03f0, 0x5016 }, 0}, /* HP USB Sync 1650 */
+ {{ 0x03f0, 0x5116 }, 0}, /* HP USB Sync 1651 */
+ {{ 0x03f0, 0x5216 }, 0}, /* HP USB Sync 1652 */
+ {{ 0x0409, 0x00d5 }, 0}, /* NEC USB Sync */
+ {{ 0x0409, 0x00d6 }, 0}, /* NEC USB Sync */
+ {{ 0x0409, 0x00d7 }, 0}, /* NEC USB Sync */
+ {{ 0x0409, 0x8024 }, 0}, /* NEC USB Sync */
+ {{ 0x0409, 0x8025 }, 0}, /* NEC USB Sync */
+ {{ 0x043e, 0x9c01 }, 0}, /* LGE USB Sync */
+ {{ 0x045e, 0x00ce }, 0}, /* Microsoft USB Sync */
+ {{ 0x045e, 0x0400 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0401 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0402 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0403 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0404 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0405 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0406 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0407 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0408 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0409 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x040a }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x040b }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x040c }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x040d }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x040e }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x040f }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0410 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0411 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0412 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0413 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0414 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0415 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0416 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0417 }, 0}, /* Windows Powered Pocket PC 2002 */
+ {{ 0x045e, 0x0432 }, 0}, /* Windows Powered Pocket PC 2003 */
+ {{ 0x045e, 0x0433 }, 0}, /* Windows Powered Pocket PC 2003 */
+ {{ 0x045e, 0x0434 }, 0}, /* Windows Powered Pocket PC 2003 */
+ {{ 0x045e, 0x0435 }, 0}, /* Windows Powered Pocket PC 2003 */
+ {{ 0x045e, 0x0436 }, 0}, /* Windows Powered Pocke
ucom: orphaned ttyUX ?
I recently had a bad experience with ucom. I didn't try to reproduce it in a controlled way, so that I could fully document it. So, here's my recollection and impression/understanding of it with couple of facts on top. The bad experience: system crash with the following info: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc4611c2b stack pointer = 0x28:0xd1d3395c frame pointer = 0x28:0xd1d33974 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 = 8979 (pppd) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c06b76ef,d1d337fc,c04f577a,c06b4e67,c0d9f6e0,...) at 0xc0437e56 = db_trace_self_wrapper+0x26 kdb_backtrace(c06b4e67,c0d9f6e0,c06a7d40,d1d33808,d1d33808,...) at 0xc051ad69 = kdb_backtrace+0x29 panic(c06a7d40,c06cf0ab,c4219cd4,1,1,...) at 0xc04f577a = panic+0xaa trap_fatal(c4219b40,0,c06ceeff,31b,4,...) at 0xc067e5d3 = trap_fatal+0x353 trap_pfault(c06bc33a,d1d338c4,c04e9fc9,8,c,...) at 0xc067e7bb = trap_pfault+0x1db trap(d1d3391c) at 0xc067f182 = trap+0x3c2 calltrap() at 0xc066e2db = calltrap+0x6 --- trap 0xc, eip = 0xc4611c2b, esp = 0xd1d3395c, ebp = 0xd1d33974 --- ucommodem(c28f6400,3,0,c06b41c5,0,...) at 0xc4611c2b = ucommodem+0xab ttyopen(c345ed00,7,2000,c3468a50,c06ee960,...) at 0xc0535b10 = ttyopen+0x180 giant_open(c345ed00,7,2000,c3468a50,7,...) at 0xc04ca70f = giant_open+0x4f devfs_open(d1d33a70,c06d1f98,1e2,c06d267e,c3a1caa0,...) at 0xc04968c8 = devfs_open+0x1d8 VOP_OPEN_APV(c06dfee0,d1d33a70,8eb,c0558155,c3a1caa0,...) at 0xc0696062 = VOP_OPEN_APV+0x42 vn_open_cred(d1d33b64,d1d33c5c,0,c33c8800,c3823900,...) at 0xc0570b2d = vn_open_cred+0x45d vn_open(d1d33b64,d1d33c5c,0,c3823900,8,...) at 0xc0570c33 = vn_open+0x33 kern_open(c3468a50,8063280,0,7,0,...) at 0xc056f873 = kern_open+0xf3 open(c3468a50,d1d33cfc,3fe,c06cef20,c3468a50,...) at 0xc056fd70 = open+0x30 syscall(d1d33d38) at 0xc067eb03 = syscall+0x323 Xint0x80_syscall() at 0xc066e340 = Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x283123fb, esp = 0xbfbfe71c, ebp = 0xbfbfe7f8 --- Apparently, this is a "null pointer dereferencing" crash. (tried to dereference a field of structure pointed to with NULL). What happened before: connected a device recognized by ucom, /dev/ttyU0 appeared disconnected the device, ucom noticed that, but ttyU0 did not disappear re-connected the device (I believe that this time ttyU1 was created for it, but I haven't checked) by mistake used ttyU0 again got the crash I believe that this is another example of a bad use of our device cloning, but I can be very wrong here. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ucom: orphaned ttyUX ?
on 28/02/2008 23:36 Andriy Gapon said the following: > I recently had a bad experience with ucom. I didn't try to reproduce it > in a controlled way, so that I could fully document it. So, here's my > recollection and impression/understanding of it with couple of facts on top. > > The bad experience: system crash with the following info: > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x4 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc4611c2b > stack pointer = 0x28:0xd1d3395c > frame pointer = 0x28:0xd1d33974 > 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 = 8979 (pppd) > trap number = 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c06b76ef,d1d337fc,c04f577a,c06b4e67,c0d9f6e0,...) > at 0xc0437e56 = db_trace_self_wrapper+0x26 > kdb_backtrace(c06b4e67,c0d9f6e0,c06a7d40,d1d33808,d1d33808,...) at > 0xc051ad69 = kdb_backtrace+0x29 > panic(c06a7d40,c06cf0ab,c4219cd4,1,1,...) at 0xc04f577a = panic+0xaa > trap_fatal(c4219b40,0,c06ceeff,31b,4,...) at 0xc067e5d3 = trap_fatal+0x353 > trap_pfault(c06bc33a,d1d338c4,c04e9fc9,8,c,...) at 0xc067e7bb = > trap_pfault+0x1db > trap(d1d3391c) at 0xc067f182 = trap+0x3c2 > calltrap() at 0xc066e2db = calltrap+0x6 > --- trap 0xc, eip = 0xc4611c2b, esp = 0xd1d3395c, ebp = 0xd1d33974 --- > ucommodem(c28f6400,3,0,c06b41c5,0,...) at 0xc4611c2b = ucommodem+0xab > ttyopen(c345ed00,7,2000,c3468a50,c06ee960,...) at 0xc0535b10 = ttyopen+0x180 > giant_open(c345ed00,7,2000,c3468a50,7,...) at 0xc04ca70f = giant_open+0x4f > devfs_open(d1d33a70,c06d1f98,1e2,c06d267e,c3a1caa0,...) at 0xc04968c8 = > devfs_open+0x1d8 > VOP_OPEN_APV(c06dfee0,d1d33a70,8eb,c0558155,c3a1caa0,...) at 0xc0696062 > = VOP_OPEN_APV+0x42 > vn_open_cred(d1d33b64,d1d33c5c,0,c33c8800,c3823900,...) at 0xc0570b2d = > vn_open_cred+0x45d > vn_open(d1d33b64,d1d33c5c,0,c3823900,8,...) at 0xc0570c33 = vn_open+0x33 > kern_open(c3468a50,8063280,0,7,0,...) at 0xc056f873 = kern_open+0xf3 > open(c3468a50,d1d33cfc,3fe,c06cef20,c3468a50,...) at 0xc056fd70 = open+0x30 > syscall(d1d33d38) at 0xc067eb03 = syscall+0x323 > Xint0x80_syscall() at 0xc066e340 = Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip = 0x283123fb, esp = > 0xbfbfe71c, ebp = 0xbfbfe7f8 --- > > Apparently, this is a "null pointer dereferencing" crash. (tried to > dereference a field of structure pointed to with NULL). > What happened before: > connected a device recognized by ucom, /dev/ttyU0 appeared > disconnected the device, ucom noticed that, but ttyU0 did not disappear > re-connected the device > (I believe that this time ttyU1 was created for it, but I haven't checked) > by mistake used ttyU0 again > got the crash Well, it wasn't ttyU1, it was ttyU0: $ ls -l /dev/ttyU0 crw--- 1 root wheel0, 132 28 Feb 22:37 /dev/ttyU0 $ ls -l /dev/ttyU0* crw--- 1 root wheel0, 132 28 Feb 22:37 /dev/ttyU0 crw--- 1 root wheel0, 132 28 Feb 22:37 /dev/ttyU0 crw--- 1 root wheel0, 132 28 Feb 22:37 /dev/ttyU0 crw--- 1 root wheel0, 132 28 Feb 22:37 /dev/ttyU0 crw--- 1 root wheel0, 133 28 Feb 12:33 /dev/ttyU0.init crw--- 1 root wheel0, 133 28 Feb 12:33 /dev/ttyU0.init crw--- 1 root wheel0, 133 28 Feb 12:33 /dev/ttyU0.init crw--- 1 root wheel0, 133 28 Feb 12:33 /dev/ttyU0.init crw--- 1 root wheel0, 134 28 Feb 12:33 /dev/ttyU0.lock crw--- 1 root wheel0, 134 28 Feb 12:33 /dev/ttyU0.lock crw--- 1 root wheel0, 134 28 Feb 12:33 /dev/ttyU0.lock crw--- 1 root wheel0, 134 28 Feb 12:33 /dev/ttyU0.lock So there are multiple ttyU0, and I guess that only one of them is "good". So opening ttyU0 is almost like playing russian roulette. > I believe that this is another example of a bad use of our device > cloning, but I can be very wrong here. > -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suspend/Sleep/Stop USB device
Anish,
I once played with a similar idea - to power off a USB port once a UMASS
device (attached to it) is unmounted, similarly to how windows does it.
I haven't reached any completely satisfactory results, but I got some
results. I have a very faint memory of that now, but I think that either
of the following two should work for a port of a USB hub device:
usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE);
usbd_clear_port_feature(dev, port, UHF_PORT_POWER);
I actually issued the request from user-land, but I think that a proper
solution would be to add a new ioctl for this purpose and a proper
handling of it in usb/uhub.
This is a snippet of the userland code that I still have around:
if ((fd = open(device_name, O_RDWR, 0)) < 0) {
error("%s", device_name);
exit(EXIT_FAILURE);
}
/*==*/
ctlreq.ucr_addr = 1; /* XXX */
ctlreq.ucr_request.bmRequestType = UT_WRITE_CLASS_OTHER;
ctlreq.ucr_request.bRequest = UR_CLEAR_FEATURE;
USETW(ctlreq.ucr_request.wValue, UHF_PORT_POWER);
//USETW(ctlreq.ucr_request.wValue, UHF_PORT_ENABLE);
USETW(ctlreq.ucr_request.wIndex, 8); /* XXX */
USETW(ctlreq.ucr_request.wLength, 0);
ctlreq.ucr_data = 0;
ctlreq.ucr_flags = 0;
ctlreq.ucr_actlen = 0;
/*==*/
if (ioctl(fd, USB_REQUEST, &ctlreq) != 0) {
error("ioctl USB_REQUEST");
close(fd);
exit(EXIT_FAILURE);
}
--
Andriy Gapon
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ucom: orphaned ttyUX ?
Marcin wrote: > Andriy Gapon wrote: >>> I believe that this is another example of a bad use of our device >>> cloning, but I can be very wrong here. > > What driver are you using to have ucom device there (uftdi, ubsa, etc.)? > Is this behavior easy to reproduce? This was palm/uppc-kmod module. I believe that uipaq is a replacement for that in recent versions of FreeBSD. I'll admit that I haven't tried too hard to reproduce this again. > Can you provide some more information about connected USB devices and > what exactly are you doing to reproduce the problem? I think that http://docs.FreeBSD.org/cgi/mid.cgi?47C7294B.6020306 has pretty complete description of it. I connected my WM5 device (in ActiveSync WinCE compatibility mode), then disconnected, the connected, then tried to run ppp over the serial link aka ttyU0. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umass causes panic on 7 amd64
on 17/04/2008 17:56 Paul Schmehl said the following: > > I wish I had a core file to analyze. *Every* time I reboot my machine, I > have > to disconnect my usb drive. Then I have to remount it after I'm back up and > running. If I leave it connected during the reboot, I get the same kind of > errors that were posted by Steve. After the system is up and running, umass > is > detected normally and I can mount and use the drive with no problems. I'm on > i386, so it doesn't look like an AMD-specific problem. > > # uname -a > FreeBSD utd65257.utdallas.edu 7.0-STABLE FreeBSD 7.0-STABLE #6: Wed Apr 16 > 17:14:28 CDT 2008 utd65257.utdallas.edu:/usr/obj/usr/src/sys/GENERIC i386 > > I've rebuilt kernel and world six times in the hopes that recent src updates > would fix the problem. > > Unfortunately, since the error occurs during boot, I know of no way to > capture > the error message. If I log console would that do it? I doubt the console > is > logging at that point. I don't think syslogd is even running yet. > Eh I think I saw something like this myself. Do you by a chance have that new device sg in your kernel? I assume you do (GENERIC) - try to drop it. I am not sure if this is some brokenness of that driver or fighting of several USB drivers over the same hardware. P.S. sorry for the wide broadcast, but I think that users on all 3 lists might be interested. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umass causes panic on 7 amd64
on 17/04/2008 18:31 Paul Schmehl said the following: > --On Thursday, April 17, 2008 18:06:28 +0300 Andriy Gapon <[EMAIL PROTECTED]> > wrote: > >> on 17/04/2008 17:56 Paul Schmehl said the following: >>> I wish I had a core file to analyze. *Every* time I reboot my machine, I >>> have to disconnect my usb drive. Then I have to remount it after I'm back >>> up and running. If I leave it connected during the reboot, I get the same >>> kind of errors that were posted by Steve. After the system is up and >>> running, umass is detected normally and I can mount and use the drive with >>> no problems. I'm on i386, so it doesn't look like an AMD-specific problem. >>> >>> # uname -a >>> FreeBSD utd65257.utdallas.edu 7.0-STABLE FreeBSD 7.0-STABLE #6: Wed Apr 16 >>> 17:14:28 CDT 2008 utd65257.utdallas.edu:/usr/obj/usr/src/sys/GENERIC >>> i386 >>> >>> I've rebuilt kernel and world six times in the hopes that recent src updates >>> would fix the problem. >>> >>> Unfortunately, since the error occurs during boot, I know of no way to >>> capture the error message. If I log console would that do it? I doubt the >>> console is logging at that point. I don't think syslogd is even running >>> yet. >>> >> Eh I think I saw something like this myself. >> Do you by a chance have that new device sg in your kernel? >> I assume you do (GENERIC) - try to drop it. >> I am not sure if this is some brokenness of that driver or fighting of >> several USB drivers over the same hardware. >> >> P.S. sorry for the wide broadcast, but I think that users on all 3 lists >> might be interested. > > This is all I have in my GENERIC conf file: > > # grep -i sg /usr/src/sys/i386/conf/GENERIC > options SYSVMSG # SYSV-style message queues > I see. Then maybe sg was a red herring in my case. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
issue with umass plugged-in during boot up
This is sort of a follow up to the issue of kernel panic when a system is booted with umass device plugged in. Cursory point: I remember having the issue myself when I loaded scsi_low and cam as modules. I blamed it on sg being present in cam.ko, but I have no facts. After I added scsi devices to kernel (sans sg) I stopped having the panics. BTW, I use RELENG_7, i386, UP. Anyway, I see a different issue with booting while a umass device is connected. First issue was that k3b hasn't found my two cd/atapicam devices. Then I executed camcontrol rescan all, it failed with EINVAL. camcontrol reset all - the same error. ktrace showed that the error came from ioctl on xpt device. I rebooted without the umass device and everything went back to normal. I'll try to do more debugging later. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: issue with umass plugged-in during boot up
on 22/04/2008 23:16 Andriy Gapon said the following: > BTW, I use RELENG_7, i386, UP. > > Anyway, I see a different issue with booting while a umass device is > connected. First issue was that k3b hasn't found my two cd/atapicam > devices. Then I executed camcontrol rescan all, it failed with EINVAL. > camcontrol reset all - the same error. ktrace showed that the error came > from ioctl on xpt device. > I rebooted without the umass device and everything went back to normal. > I'll try to do more debugging later. Here is a complete and correct scenario with more details. Original boot: uhci1: port 0xbc00-0xbc1f irq 7 at device 12.0 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xc000-0xc01f irq 10 at device 12.1 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xe7005000-0xe70050ff irq 11 at device 12.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 4 ports with 4 removable, self powered umass0: on uhub3 ... unknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 381554MB (781422768 512 byte sectors: 255H 63S/T 48641C) cam_periph_alloc: attempt to re-allocate valid device pass2 rejected passasync: Unable to attach new device due to status 0x6: CCB request was invalid cam_periph_alloc: attempt to re-allocate valid device cd2 rejected cdasync: Unable to attach new device due to status 0x6 cd2 at ata1 bus 0 target 0 lun 0 cd2: Removable CD-ROM SCSI-0 device cd2: 3.300MB/s transfers cd2: cd present [2236704 x 2048 byte records] unknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cam_periph_alloc: attempt to re-allocate valid device pass1 rejected passasync: Unable to attach new device due to status 0x6: CCB request was invalid cd1 at ata0 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 3.300MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present After boot I cane execute all camcontrol commands without any problems. Here is output of camcontrol devlist -v: scbus0 on umass-sim0 bus 0: at scbus0 target 0 lun 0 (da0,pass0) scbus1 on ata0 bus 0: at scbus1 target 0 lun 0 (cd1,pass1) < > at scbus1 target -1 lun -1 () scbus2 on ata1 bus 0: at scbus2 target 0 lun 0 (pass2,cd2) < > at scbus2 target -1 lun -1 () scbus3 on ata2 bus 0: < > at scbus3 target -1 lun -1 () scbus4 on ata3 bus 0: < > at scbus4 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) Then I detach the umass disk: umass0: at uhub3 port 2 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry GEOM_LABEL: Label ufs/extstuff removed. GEOM_LABEL: Label ufs/extbackup removed. umass0: detached And here is new output of camcontrol devlist -v: scbus1 on ata0 bus 0: at scbus1 target 0 lun 0 (cd1,pass1) < > at scbus1 target -1 lun -1 () scbus2 on ata1 bus 0: at scbus2 target 0 lun 0 (pass2,cd2) < > at scbus2 target -1 lun -1 () scbus3 on ata2 bus 0: < > at scbus3 target -1 lun -1 () scbus4 on ata3 bus 0: < > at scbus4 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) After that camcontrol commands referring to "all" (rescan and reset) fail with EINVAL. ktrace shows that EINVAL comes from ioctl CAMIOCOMMAND on xpt0 device. My clumsy ddb debugging shows that the error is produced somewhere in xptioctl->xpt_find_bus. It seems that xpt might be unhappy about scbus0/pass0 going away. Maybe this is because in /-1 case camcontrol sends ccb with path_id (implicitly) set to zero and xptioctl performs xpt_find_bus for all ioctl commands (including XPT_DEV_MATCH)? I.e. see case of bus=-1 in rescan_or_reset_bus() in camcontrol.c -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tilt/horizontal scroll support
I have the following mouse: http://www.logitech.com/index.cfm/partners/system_builders_integrators/products/mice/devices/3141&cl=gb,en# It has "Tilt Wheel Plus Zoom™ technology", i.e. its scroll wheel can be tilted left and right. Currently it perfectly works as 3 buttons + wheel mouse, but tilting action does not cause any effect (in xev). This is some debug output from ums driver: ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/27.20, addr 2, iclass 3/1 ums0: 8 buttons and Z dir. ums_attach: sc=0xff004d747400 ums_attach: X 8/8 ums_attach: Y 16/8 ums_attach: Z 24/8 ums_attach: B1 0/1 ums_attach: B2 1/1 ums_attach: B3 2/1 ums_attach: B4 3/1 ums_attach: B5 4/1 ums_attach: B6 5/1 ums_attach: B7 6/1 ums_attach: B8 7/1 Here's how "normal"/vertical scrolling of the wheel is reported by ums (one scroll forward and one scroll backward): ums_intr: sc=0xff006b502400 status=0 ums_intr: data = 00 00 00 ff 00 ums_intr: x:0 y:0 z:1 t:0 buttons:0x0 ums_intr: sc=0xff006b502400 status=0 ums_intr: data = 00 00 00 01 00 ums_intr: x:0 y:0 z:-1 t:0 buttons:0x0 As expected value in the 4th byte (data[3]) is interpreted as z-axis movement (and seems to always be +1/-1). Here's how tilting of the wheel is reported (tilted the wheel, held it for some time and then released): ums_intr: sc=0xff004d747400 status=0 ums_intr: data = 00 00 00 00 01 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 ums_intr: sc=0xff004d747400 status=0 ums_intr: data = 00 00 00 00 01 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 ums_intr: sc=0xff004d747400 status=0 ums_intr: data = 00 00 00 00 01 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 ums_intr: sc=0xff004d747400 status=0 ums_intr: data = 00 00 00 00 00 ums_intr: x:0 y:0 z:0 t:0 buttons:0x0 It seems that tilting is reported by value in the 5th byte (data[4]), it has hardware "auto-repeat" and end of tilting is reported by all-zeroes data. Currently, it seems, data[4] is completely ignored. I would like to get tilting to work as horizontal scrolling in X, using SysMouse protocol. As I understand currently our sysmouse(4) protocol doesn't provide for tilting data (there is no field for it in the packet structure), and Xorg sysmouse driver does not have any support for tilting either. So now I have two questions. 1. What would be the best way to each ums about the tilt capability of this mouse? Is there some generic way to detect it or maybe logitech-specific way or some model-specific quirk is required? 2. What would be the best way to pass tilting data to consumers? I see two possibilities: A) map data[4] to some extended button value (do it in ums driver), e.g. to button 6 and button 7; B) it seems that dz value is always 1 or -1, amount of scrolling affects number of mouse events, but abs(dz) is always 1; if this is really always true, then tilting could be piggy-backed onto dz as +2/-2 value (or some such) and then Xorg sysmouse driver could be taught to interpret such values as special button presses (similarly to how vertical scrolling is handled in it). Thank you in advance for advices and opinions. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
usb keyboard dying at loader prompt
I have a quite strange problem. This is with 7-BETA amd64. All of USB is out of kernel and is loaded via modules. BIOS has "Legacy USB" enabled. I have only a USB keyboard, no PS/2 port. The keyboard works file in BIOS and for selecting boot device in boot0 menu. It also works in loader menu. If in the menu I select to go to loader prompt then it works for about 5 seconds and then "dies" - no reaction to key presses, no led change, nothing. I haven't actually verified if the keyboard would still work if I stayed in loader menu for longer than ~10 seconds. This doesn't happen if USB is built into kernel. Weird... -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
on 06/11/2008 14:34 Andriy Gapon said the following: > I have a quite strange problem. > This is with 7-BETA amd64. > All of USB is out of kernel and is loaded via modules. > BIOS has "Legacy USB" enabled. > I have only a USB keyboard, no PS/2 port. > > The keyboard works file in BIOS and for selecting boot device in boot0 > menu. It also works in loader menu. If in the menu I select to go to > loader prompt then it works for about 5 seconds and then "dies" - no > reaction to key presses, no led change, nothing. > I haven't actually verified if the keyboard would still work if I stayed > in loader menu for longer than ~10 seconds. > > This doesn't happen if USB is built into kernel. > > Weird... I did more experimentation and the behavior seems to be quite random - sometimes keyboard works ok for long time in all places, sometimes it stops working after some period of time, sometimes it doesn't work from the start and couple of times I experienced boot process going astray. Not sure what stage that was, there were endless messages spewed on the screen very fast, I couldn't read them. This leads me to the following "crazy" question - is it possible that our boot chain corrupts some vital BIOS memory? I think loader would be a primary suspect. I am not sure of anything, but a wild guess is that RAM where BIOS stores some USB-related stuff gets corrupted. Maybe it's overwritten when kernel and modules are loaded... -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
on 08/11/2008 14:31 Volker said the following: > Andriy, > > On 12/23/-58 20:59, Andriy Gapon wrote: >> I have a quite strange problem. >> This is with 7-BETA amd64. > > Did it work with earlier versions? Can't say, this is a new machine, FreeBSD took its virginity :-) >> All of USB is out of kernel and is loaded via modules. >> BIOS has "Legacy USB" enabled. >> I have only a USB keyboard, no PS/2 port. > > Can you check BIOS settings for EHCI handover? No such settings. > If the BIOS does not have handover enabled, it may disable legacy > support after a timeout, which is often bad. IMO this is the same with > booting off USB drives but every BIOS handles that different. This doesn't seem to be the case. The behavior is quite random, sometimes I can work at loader prompt for may minutes, sometimes keyboard is dead after a few seconds. Also, I think USB keyboard is handled by UHCI, not EHCI in my case, but I am not sure if this matters. My guess is that Legacy support should work until OS explicitly takes over by using special procedure (this should be done for UHCI as well). BTW, it seems that our UHCI take-over code is far more simple than what MS described here: http://www.microsoft.com/whdc/archive/usbhost.mspx#EQHAC Anyway, this happens after loader is done. >> The keyboard works file in BIOS and for selecting boot device in boot0 >> menu. It also works in loader menu. If in the menu I select to go to >> loader prompt then it works for about 5 seconds and then "dies" - no >> reaction to key presses, no led change, nothing. >> I haven't actually verified if the keyboard would still work if I stayed >> in loader menu for longer than ~10 seconds. >> >> This doesn't happen if USB is built into kernel. > > That sound strange. I have no idea why that might work (or I'm totally > wrong with my handover theory). I was incorrect about the above, I have already seen it happening both ways. >> Weird... > > Yes, sounds like or it's probably easily explainable ;) -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
on 11/11/2008 20:55 Peter Wemm said the following: > Some bioses have a list of MBR partition id's and use that to > determine what to do with the USB keyboard. One of my ol older amd64 > motherboards worked but would always disable the usb keyboard right as > loader started. I discovered the following: > * If I put the freebsd bootblocks and loader on a floppy drive (no > MBR), then the bios did not turn off the keyboard. It always > continued to work for loader. > * If i hacked the boot bootblocks and loader and kernel to recognize > different MBR slice id nubmers as "ours", then changing the freebsd > MBR to be "msdos" or "linux" also worked for that BIOS. It would no > longer turn off the USB keyboard. I don't recall which Id number I > used instead of 165 - it was about 4 years ago. > * There were other consequences of using the partition ID hack - I > think I remember it turning off the apic for msdos mode. > > Your problems may be different, but mine were caused by a BIOS > whitelist of MBR partition id's. What a stupid problem. On that > motherboard I ended up taking the path of least resistance and using > the PS/2 adapter plug on the keyboard. Foul play on BIOS part is definitely a big possibility. What puzzles me most is random/inconsistent behavior from boot to boot. Maybe there is some misalignment between how BIOS emulates legacy keyboard and how our boot chain interacts with it, some timing issue or something. Anyway, this is very hard to debug or guess. Most probably I will have to live with it (this system doesn't have PS/2 ports at all). -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
on 05/11/2008 17:24 Andriy Gapon said the following: > System is FreeBSD 7.1-BETA2 amd64. > > Looking through my dmesg I see that relative order of ukbd attachment > and root mounting is not deterministic. Sometime keyboard is attached > first, sometimes root filesystem is mounted first. Quite more often root > is mounted first, though. > Example (with GENERIC kernel): > Nov 3 15:40:54 kernel: Trying to mount root from ufs:/dev/mirror/bootgm > Nov 3 15:40:54 kernel: GEOM_LABEL: Label ufs/bootfs removed. > Nov 3 15:40:54 kernel: GEOM_LABEL: Label for provider mirror/bootgm is > ufs/bootfs. > Nov 3 15:40:54 kernel: GEOM_LABEL: Label ufs/bootfs removed. > Nov 3 15:40:54 kernel: ukbd0: 1.10/1.10, addr 3> on uhub2 > Nov 3 15:40:54 kernel: kbd2 at ukbd0 > Nov 3 15:40:54 kernel: uhid0: 1.10/1.10, addr 3> on uhub2 > > Another (with custom kernel, zfs root): > Nov 4 17:54:03 odyssey kernel: Trying to mount root from zfs:tank/root > Nov 4 17:54:03 odyssey kernel: ukbd0: rev 1.10/1.10, addr 3> on uhub2 > Nov 4 17:54:03 odyssey kernel: kbd2 at ukbd0 > Nov 4 17:54:03 odyssey kernel: kbd2: ukbd0, generic (0), config:0x0, > flags:0x3d > Nov 4 17:54:03 odyssey kernel: uhid0: rev 1.10/1.10, addr 3> on uhub2 > > I have a legacy-free system (no PS/2 ports, only USB) and I wanted to > try a kernel without atkbd and psm (with ums, ukbd, kbdmux), but was > bitten hard when I made a mistake and kernel could not find/mount root > filesystem. > > So I stuck at mountroot prompt without a keyboard to enter anything. > This was repeatable about 10 times after which I resorted to live cd. > > Since then I put back atkbdc into my kernel. I guess BIOS or USB > hardware emulate AT or PS/2 keyboard, so the USB keyboard works before > the driver attaches. I guess I need such emulation e.g. for loader or > boot0 configuration. But I guess I don't have to have atkbd driver in > kernel. This turned out not to be a complete solution as it seems that there are some quirks about legacy USB here, sometimes keyboard stops working even at loader prompt (this is described in a different thread). ukbd attachment still puzzles me a lot. I look at some older dmesg, e.g. this 7.0-RELEASE one: http://www.mavetju.org/mail/view_message.php?list=freebsd-usb&id=2709973 and see that ukbd attaches along with ums before mountroot. I look at newer dmesg and I see that ums attaches at about the same time as before but ukbd consistently attaches after mountroot. I wonder what might cause such behavior and how to fix it. I definitely would like to see ukbd attach before mountroot, I can debug this issue, but need some hints on where to start. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
on 12/11/2008 14:14 Jeremy Chadwick said the following: > On Wed, Nov 12, 2008 at 01:58:58PM +0200, Andriy Gapon wrote: [snip] >> 2. if ukbd driver is not attached then I don't see any way USB keyboard >> would work in non-legacy way > > Regarding #2: at which stage? boot0/boot2/loader require an AT or PS/2 > keyboard to work. None of these stages use ukbd(4) or anything -- there > is no kernel loaded at this point!! Meaning: if you have a USB keyboard, > your BIOS will need to have a "USB Legacy" option to cause it to act as > a PS/2 keyboard, for typing in boot0/boot2/loader to work. > > Device hints are for kernel drivers, once the kernel is loaded. Jeremy, I understand all of this. In subject line and earlier messages I say that I am interested in mountroot prompt - the prompt where kernel can ask about what device to use for root filesystem. Essentially I would like kernel to recognize USB keyboard (and disable all the legacy stuff if needed) before it prompts for the root device. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
on 12/11/2008 13:53 Nate Eldredge said the following: > On Wed, 12 Nov 2008, Andriy Gapon wrote: > >> on 05/11/2008 17:24 Andriy Gapon said the following: > [...] >>> I have a legacy-free system (no PS/2 ports, only USB) and I wanted to >>> try a kernel without atkbd and psm (with ums, ukbd, kbdmux), but was >>> bitten hard when I made a mistake and kernel could not find/mount root >>> filesystem. >>> >>> So I stuck at mountroot prompt without a keyboard to enter anything. >>> This was repeatable about 10 times after which I resorted to live cd. >>> >>> Since then I put back atkbdc into my kernel. I guess BIOS or USB >>> hardware emulate AT or PS/2 keyboard, so the USB keyboard works before >>> the driver attaches. I guess I need such emulation e.g. for loader or >>> boot0 configuration. But I guess I don't have to have atkbd driver in >>> kernel. >> >> This turned out not to be a complete solution as it seems that there are >> some quirks about legacy USB here, sometimes keyboard stops working even >> at loader prompt (this is described in a different thread). >> >> ukbd attachment still puzzles me a lot. >> I look at some older dmesg, e.g. this 7.0-RELEASE one: >> http://www.mavetju.org/mail/view_message.php?list=freebsd-usb&id=2709973 >> and see that ukbd attaches along with ums before mountroot. >> >> I look at newer dmesg and I see that ums attaches at about the same time >> as before but ukbd consistently attaches after mountroot. >> I wonder what might cause such behavior and how to fix it. >> I definitely would like to see ukbd attach before mountroot, I can debug >> this issue, but need some hints on where to start. > > I haven't been following this thread, and I'm pretty sleepy right now, > so sorry if this is irrelevant, but I had a somewhat similar problem > that was fixed by adding > > hint.atkbd.0.flags="0x1" > > to /boot/device.hints . > I can try this, but I think this wouldn't help for two reasons: 1. I already tried kernel without atkb at all 2. if ukbd driver is not attached then I don't see any way USB keyboard would work in non-legacy way Anyway I will try this, thank you. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
on 12/11/2008 14:33 Jeremy Chadwick said the following: > On Wed, Nov 12, 2008 at 02:20:41PM +0200, Andriy Gapon wrote: >> on 12/11/2008 14:14 Jeremy Chadwick said the following: >>> On Wed, Nov 12, 2008 at 01:58:58PM +0200, Andriy Gapon wrote: >> [snip] >>>> 2. if ukbd driver is not attached then I don't see any way USB keyboard >>>> would work in non-legacy way >>> Regarding #2: at which stage? boot0/boot2/loader require an AT or PS/2 >>> keyboard to work. None of these stages use ukbd(4) or anything -- there >>> is no kernel loaded at this point!! Meaning: if you have a USB keyboard, >>> your BIOS will need to have a "USB Legacy" option to cause it to act as >>> a PS/2 keyboard, for typing in boot0/boot2/loader to work. >>> >>> Device hints are for kernel drivers, once the kernel is loaded. >> Jeremy, >> >> I understand all of this. >> In subject line and earlier messages I say that I am interested in >> mountroot prompt - the prompt where kernel can ask about what device to >> use for root filesystem. >> Essentially I would like kernel to recognize USB keyboard (and disable >> all the legacy stuff if needed) before it prompts for the root device. > > I fully understand that fact. However, I don't see the logic in that > statement. You should be able to remove and add a keyboard at any time > and be able to type immediately. Meaning: I don't see why when the > keyboard recognition is performed (e.g. before printing mountroot or > after) matters. It should not. I think this is a red herring. I think that this does matter because keyboard recognition is performed after the 'mounting from' log line *only if* root mount is done automatically. If there is an actual interactive prompt then recognition is not performed, at least I do not see any relevant lines on the screen and I am stuck at the prompt. > I've seen the problem where I have a fully functional USB keyboard in > boot0/boot2/loader For me it even randomly dies at these stages. I reported this in a different thread. But this should not be related to kernel behavior. >and in multi-user, For me this always works. > but when booting into single-user For me this always works. > or when getting a mountroot prompt, the keyboard does not function. > When the mountroot prompt is printed (before or after ukbd attached) > makes no difference for me in this scenario -- I tested it many times. For me ukbd lines are never printed if I get actual interactive mountroot prompt. > It's very possible that "something" (kbdcontrol?) is getting run only > during late stages of multi-user, which makes the keyboard work. But > prior to that "something" being run (but AFTER boot2/loader), the > keyboard is not truly usable. For me this is not true. My keyboard always works after ukbd lines appear on screen. > I hope everyone here is also aware of that fact that not all keyboards > are created equal. Case in point (and this reason is exactly why I > am purchasing a native PS/2 keyboard, as USB4BSD doesn't work with > all USB keyboards right now): For me this is not an option, no PS/2 ports. > http://lists.freebsd.org/pipermail/freebsd-current/2008-November/000219.html > > The bottom line: > > FreeBSD cannot be reliably used with a USB keyboard in all > circumstances.And that is a very sad reality, because 90% of the > keyboards you find on the consumer and enterprise market are USB -- > native PS/2 keyboards are now a scarcity. I agree that this is a sad reality but only for boot stages where we depend on external entity named BIOS to help us. This doesn't have to be a sad reality once kernel takes control. USB support in boot chain - I don't know - this would be great of course but that's a lot of code. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
on 12/11/2008 15:21 Jeremy Chadwick said the following: > I don't know what to say to ***ANY*** of the above, other than this: > > No one is doing anything about this problem because there does not > appear to be a 100% reproducible always-screws-up-when-I-do-this > scenario that happens to *every FreeBSD user*. > > Until we settle down, stop replying to Emails with one-liner injections, > and compile a list of test scenarios/cases that people can perform, and > get these people to provide both 1) full hardware details, 2) full > kernel configuration files, 3) full loader.conf files, and 4) full > device.hints files, we're not going to get anywhere. Well I started two separate threads. This thread is about one very specific issue - ukbd attaching after mountroot code. Again, in this thread I am only interested in getting ukbd to attach before the mount root. I am not interested in BIOS, boot chain, etc. I am not even interested in speculations about whether keyboard would work or not at mountroot prompt if it were attaching before it. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
ooping over 1 configurations usbd_probe_and_attach: trying config idx=0 usbd_set_config_index: (addr 1) cno=3 attr=0xa0, selfpowered=0, power=100 usbd_set_config_index: set config 1 ukbd0: on uhub2 Full dmesg is here: http://www.icyb.net.ua/~avg/ukbd.dmesg.gz -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
I increased debug level in uhub and also switched mouse and keyboard ports hoping that order might matter. It didn't. Here's fresh usbdevs output snippet: Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 uhub2 port 1 addr 3: low speed, power 100 mA, config 1, USB Keyboard(0x0101), CHESEN(0x0a81), rev 1.10 ukbd0 uhid0 port 2 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical Mouse(0xc040), Logitech(0x046d), rev 24.30 ums0 And here's a new snippet from cold explore dmesg: uhub2: uhub_explore: port 1 status 0x0100 0x0001 + + So, hm, it looks like a change in connection status is reported but current status is reported as not connected. + I wonder why? + Could this be related to how we perform UHCI handover from BIOS to kernel? + Our uhci code seems to be much simpler than what MS folks described here: + http://www.microsoft.com/whdc/archive/usbhost.mspx#EQHAC uhub_explore: status change hub=1 port=1 uhub_explore: port=1 !CURRENT_CONNECT_STATUS uhub2: uhub_explore: port 2 status 0x0301 0x0001 uhub_explore: status change hub=1 port=2 usbd_reset_port: port 2 reset done, error=NORMAL_COMPLETION usbd_new_device bus=0x80c7d000 port=2 depth=1 speed=1 usbd_setup_pipe: dev=0xff0004a16d00 iface=0 ep=0xff0004a16d38 pipe=0xff0004a16d08 uhci_open: pipe=0xff0004a16c00, addr=0, endpt=0 (1) usb_allocmem: adding fragments usbd_new_device: adding unit addr=2, rev=200, class=0, subclass=0, protocol=0, maxpacket=8, len=18, speed=1 usbd_ar_pipe: pipe=0xff0004a16c00 usbd_setup_pipe: dev=0xff0004a16d00 iface=0 ep=0xff0004a16d38 pipe=0xff0004a16d08 uhci_open: pipe=0xff0004a16b00, addr=0, endpt=0 (1) usbd_ar_pipe: pipe=0xff0004a16b00 usbd_setup_pipe: dev=0xff0004a16d00 iface=0 ep=0xff0004a16d38 pipe=0xff0004a16d08 uhci_open: pipe=0xff0004a16a00, addr=2, endpt=0 (1) usbd_new_device: new dev (addr 2), dev=0xff0004a16d00, parent=0xff0001338c00 usbd_probe_and_attach: trying device specific drivers usbd_probe_and_attach: no device specific driver found usbd_probe_and_attach: looping over 1 configurations usbd_probe_and_attach: trying config idx=0 usbd_set_config_index: (addr 1) cno=2 attr=0xa0, selfpowered=0, power=98 usbd_set_config_index: set config 1 ums0: on uhub2 ums0: 8 buttons and Z dir. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ukbd attachment and root mount
on 27/11/2008 15:23 Andriy Gapon said the following: > I increased debug level in uhub and also switched mouse and keyboard > ports hoping that order might matter. It didn't. > > Here's fresh usbdevs output snippet: > Controller /dev/usb2: > addr 1: full speed, self powered, config 1, UHCI root hub(0x), > Intel(0x), rev 1.00 > uhub2 > port 1 addr 3: low speed, power 100 mA, config 1, USB Keyboard(0x0101), > CHESEN(0x0a81), rev 1.10 >ukbd0 >uhid0 > port 2 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical > Mouse(0xc040), Logitech(0x046d), rev 24.30 >ums0 > > And here's a new snippet from cold explore dmesg: > uhub2: uhub_explore: port 1 status 0x0100 0x0001 > + > + So, hm, it looks like a change in connection status is reported but > current status is reported as not connected. > + I wonder why? For now I am blaming this on the keyboard. My wild un-educated guess is that it takes it too long to come back after controller reset. I don't have any other explanation at the moment. I'll try to get another keyboard (from different vendor) and play with it. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
I did more testing and it seems that our loader does have something to do with the problem. If I boot to memtest86 the keyboard keeps working. If I pause boot menu, wait for many minutes, the keyboard still works. If I escape to loader prompt, this when the keyboard stops working after a few seconds. Not sure how to explain this. I think I've seen some changes to reduce memory usage of loader, I will try them to see if that would make any difference for my situation. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
[forwarded to the lists] on 28/11/2008 15:48 Luigi Rizzo said the following: > just as a test, can you check if /boot/loader from 6.2 (or sometime > before jan.2008 - e.g. you could take one from a 6.3 CD) which you > can also find at > > http://info.iet.unipi.it/~luigi/doc/20081128-freebsd-6.3-boot-loader > > gives the same behaviour ? > > I was seeing bugs related to the loader with pxeboot and > the behaviour that you mention below sounds related. > > It also sounds related to a problem that i a started having > recently with an usb keyboard after i upgraded to 7.x > in fact i am going to try this old loader myself! > > let me know how the old loader works and if it fixes the > problem i will relate the two issues and bring them up > on the lists for discussion Luigi, thank you very much for this! With your loader the things are much much better. The keyboard doesn't die anymore at the loader prompt! All in all, it seems that this is right direction. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
I would like to report that I am no longer seeing the issue in the subject line. The problem was fixed by the recent commits of jhb ( I tested stable/7). -- Andriy Gapon ___ 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: USB Video Class support
on 01/04/2009 16:33 Engineering said the following: > I have a driver based off ugen. > > Hans Petter helped me get started on it - it should be using his new stack > > It was built for a custom embedded application, so the functionality is > limited to just what I needed to get it going. It works with 7 out of the 10 > different Chinese cameras I have laying around :) > > I'm sure my coding style violates every FreeBSD standard, there is no > documentation, and very few comments, but if someone wants it for a working > framework to create a 'real' driver, they are welcome to it. Great news! Please, where/how I can peruse it? > -Original Message- > From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] > On Behalf Of Nicolas > Sent: Sunday, March 29, 2009 5:09 AM > To: freebsd-usb@freebsd.org; freebsd-multime...@freebsd.org > Subject: USB Video Class support > > Hi, > > Someone knows if a person works on usb video class driver ? > > Thanks in advance, > Nicolas. -- Andriy Gapon ___ 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: serial console on USB ?
on 22/10/2011 00:18 Mike Tancsa said the following: > I came across a thread mentioning potential patches being added a while > back to allow for the console to work with USB, but I am not able to get > it to work with RELENG_8 > > If I just add > > ttyU0 "/usr/libexec/getty std.9600" vt100 on secure > > I can login to the box no problem. But That does not show bootup access > via the serial console. Is there a way to enable that ? I don't believe so. USB subsystem depends on so many kernel services that USB drivers become functional quite late in the boot process. -- Andriy Gapon ___ 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"
kern_yield vs ukbd_yield
Does the following change do what I think that it does?
Thank you!
Author: Andriy Gapon
Date: Thu Sep 1 16:50:13 2011 +0300
ukbd: drop local duplicate of kern_yield and use that instead
diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c
index 086c178..8078cbb 100644
--- a/sys/dev/usb/input/ukbd.c
+++ b/sys/dev/usb/input/ukbd.c
@@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t key)
}
static void
-ukbd_yield(void)
-{
- struct thread *td = curthread;
- uint32_t old_prio;
-
- DROP_GIANT();
-
- thread_lock(td);
-
- /* get current priority */
- old_prio = td->td_base_pri;
-
- /* set new priority */
- sched_prio(td, td->td_user_pri);
-
- /* cause a task switch */
- mi_switch(SW_INVOL | SWT_RELINQUISH, NULL);
-
- /* restore priority */
- sched_prio(td, old_prio);
-
- thread_unlock(td);
-
- PICKUP_GIANT();
-}
-
-static void
ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait)
{
@@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait)
while (sc->sc_inputs == 0) {
/* give USB threads a chance to run */
- ukbd_yield();
+ kern_yield(-1);
/* check if we should wait */
if (!wait)
--
Andriy Gapon
___
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: kern_yield vs ukbd_yield
on 11/12/2011 23:48 m...@freebsd.org said the following:
> On Sun, Dec 11, 2011 at 1:12 PM, Andriy Gapon wrote:
>>
>> Does the following change do what I think that it does?
>> Thank you!
>>
>> Author: Andriy Gapon
>> Date: Thu Sep 1 16:50:13 2011 +0300
>>
>>ukbd: drop local duplicate of kern_yield and use that instead
>>
>> diff --git a/sys/dev/usb/input/ukbd.c b/sys/dev/usb/input/ukbd.c
>> index 086c178..8078cbb 100644
>> --- a/sys/dev/usb/input/ukbd.c
>> +++ b/sys/dev/usb/input/ukbd.c
>> @@ -399,33 +399,6 @@ ukbd_put_key(struct ukbd_softc *sc, uint32_t key)
>> }
>>
>> static void
>> -ukbd_yield(void)
>> -{
>> - struct thread *td = curthread;
>> - uint32_t old_prio;
>> -
>> - DROP_GIANT();
>> -
>> - thread_lock(td);
>> -
>> - /* get current priority */
>> - old_prio = td->td_base_pri;
>> -
>> - /* set new priority */
>> - sched_prio(td, td->td_user_pri);
>> -
>> - /* cause a task switch */
>> - mi_switch(SW_INVOL | SWT_RELINQUISH, NULL);
>> -
>> - /* restore priority */
>> - sched_prio(td, old_prio);
>> -
>> - thread_unlock(td);
>> -
>> - PICKUP_GIANT();
>> -}
>> -
>> -static void
>> ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait)
>> {
>>
>> @@ -439,7 +412,7 @@ ukbd_do_poll(struct ukbd_softc *sc, uint8_t wait)
>>while (sc->sc_inputs == 0) {
>>
>>/* give USB threads a chance to run */
>> - ukbd_yield();
>> + kern_yield(-1);
>
> Not quite.
>
> 1) -1 should be spelled PRI_UNCHANGED, except ukbd_yield() uses
> td_user_pri, but then puts it back again, so I think UNCHANGED is what
> is meant.
> 2) kern_yield() calls it a SW_VOL rather than SW_INVOL, which seems
> the desired behaviour here anyways, since this is an explicit (i.e.
> voluntary) yield.
Thank you for the explanation. So would you say that the patch is OK?
--
Andriy Gapon
___
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: kern_yield vs ukbd_yield
on 12/12/2011 21:09 Hans Petter Selasky said the following:
> On Monday 12 December 2011 20:05:38 John Baldwin wrote:
>>> Hi,
>>>
>>>
>>>
>>>> hselasky@ or someone else familiar with the various usb threads would
>>>> have to answer that.
>>>
>>>
>>>
>>> The problem is only during init() where the init thread has highest
>>> priority and that doesn't allow other threads to run even if the
>>> scheduler is
>>
>> running!
>>
>> Hmm, that should be fixed by lowering the relevant thread's priority.
>> Do you mean thread0 (the one doing all the SYSINIT's or thread we create
>> for init (pid 1) before it executes init?
>
> Yes, thread0. Correct!
Mmm, my short debugging session with qemu shows that it is actually pid 1:
Breakpoint 1, ukbd_do_poll (sc=0xff8000764000, wait=0 '\0') at
/usr/src/sys/dev/usb/input/ukbd.c:403
403 {
(kgdb) bt
#0 ukbd_do_poll (sc=0xff8000764000, wait=0 '\0') at
/usr/src/sys/dev/usb/input/ukbd.c:403
#1 0x803ee57e in ukbd_check (kbd=Variable "kbd" is not available.
) at /usr/src/sys/dev/usb/input/ukbd.c:1418
#2 0x803ee674 in ukbd_check_char (kbd=0xff8000764000) at
/usr/src/sys/dev/usb/input/ukbd.c:1450
#3 0x8035c794 in kbdmux_read_char (kbd=0xfe00021d2c00,
wait=Variable "wait" is not available.
) at /usr/src/sys/dev/kbdmux/kbdmux.c:665
#4 0x803bf4aa in scgetc (sc=0x81835dc0, flags=Variable "flags"
is not available.
) at /usr/src/sys/dev/syscons/syscons.c:3373
#5 0x803c2d03 in sc_cngetc (cd=Variable "cd" is not available.
) at /usr/src/sys/dev/syscons/syscons.c:1753
#6 0x804ae489 in cncheckc () at /usr/src/sys/kern/kern_cons.c:402
#7 0x804ae4c7 in cngetc () at /usr/src/sys/kern/kern_cons.c:383
#8 0x804ae9a7 in cngets (cp=0xff8000326aa0 "", size=80, visible=1)
at /usr/src/sys/kern/kern_cons.c:421
#9 0x80594d4e in vfs_mountroot () at
/usr/src/sys/kern/vfs_mountroot.c:490
#10 0x804a6e65 in start_init (dummy=Variable "dummy" is not available.
) at /usr/src/sys/kern/init_main.c:683
#11 0x804c5a9a in fork_exit (callout=0x804a6e00 ,
arg=0x0, frame=0xff8000326c50) at /usr/src/sys/kern/kern_fork.c:995
#12 0x806bb72e in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:602
#13 0x in ?? ()
(kgdb) p td->td_proc->p_pid
$7 = 1
(kgdb) p td->td_proc->p_comm
$8 = "kernel", '\0'
(kgdb) p td->td_tid
$9 = 12
Also:
(kgdb) p/d td->td_user_pri
$10 = 139
(kgdb) p/d td->td_base_pri
$11 = 84
--
Andriy Gapon
___
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: kern_yield vs ukbd_yield
on 13/12/2011 00:21 Andriy Gapon said the following:
> on 12/12/2011 21:09 Hans Petter Selasky said the following:
>> On Monday 12 December 2011 20:05:38 John Baldwin wrote:
>>>> Hi,
>>>>
>>>>
>>>>
>>>>> hselasky@ or someone else familiar with the various usb threads would
>>>>> have to answer that.
>>>>
>>>>
>>>>
>>>> The problem is only during init() where the init thread has highest
>>>> priority and that doesn't allow other threads to run even if the
>>>> scheduler is
>>>
>>> running!
>>>
>>> Hmm, that should be fixed by lowering the relevant thread's priority.
>>> Do you mean thread0 (the one doing all the SYSINIT's or thread we create
>>> for init (pid 1) before it executes init?
>>
>> Yes, thread0. Correct!
>
> Mmm, my short debugging session with qemu shows that it is actually pid 1:
And in the view of the below data I would like us to revisit this problem.
I looked over usb code and it seems that all usb threads are created with
priorities of either USB_PRI_MED or USB_PRI_HIGH, which translates to
PI_SWI(SWI_CAMBIO) and PI_SWI(SWI_NET). These priorities should be in the
ithread range, so it's kind of surprising that the init thread (with PVM
priority) can cause troubles for them.
> Breakpoint 1, ukbd_do_poll (sc=0xff8000764000, wait=0 '\0') at
> /usr/src/sys/dev/usb/input/ukbd.c:403
> 403 {
> (kgdb) bt
> #0 ukbd_do_poll (sc=0xff8000764000, wait=0 '\0') at
> /usr/src/sys/dev/usb/input/ukbd.c:403
> #1 0x803ee57e in ukbd_check (kbd=Variable "kbd" is not available.
> ) at /usr/src/sys/dev/usb/input/ukbd.c:1418
> #2 0x803ee674 in ukbd_check_char (kbd=0xff8000764000) at
> /usr/src/sys/dev/usb/input/ukbd.c:1450
> #3 0x8035c794 in kbdmux_read_char (kbd=0xfe00021d2c00,
> wait=Variable "wait" is not available.
> ) at /usr/src/sys/dev/kbdmux/kbdmux.c:665
> #4 0x803bf4aa in scgetc (sc=0x81835dc0, flags=Variable
> "flags"
> is not available.
> ) at /usr/src/sys/dev/syscons/syscons.c:3373
> #5 0x803c2d03 in sc_cngetc (cd=Variable "cd" is not available.
> ) at /usr/src/sys/dev/syscons/syscons.c:1753
> #6 0x804ae489 in cncheckc () at /usr/src/sys/kern/kern_cons.c:402
> #7 0x804ae4c7 in cngetc () at /usr/src/sys/kern/kern_cons.c:383
> #8 0x804ae9a7 in cngets (cp=0xff8000326aa0 "", size=80,
> visible=1)
> at /usr/src/sys/kern/kern_cons.c:421
> #9 0x80594d4e in vfs_mountroot () at
> /usr/src/sys/kern/vfs_mountroot.c:490
> #10 0x804a6e65 in start_init (dummy=Variable "dummy" is not available.
> ) at /usr/src/sys/kern/init_main.c:683
> #11 0x804c5a9a in fork_exit (callout=0x804a6e00 ,
> arg=0x0, frame=0xffffff8000326c50) at /usr/src/sys/kern/kern_fork.c:995
> #12 0x806bb72e in fork_trampoline () at
> /usr/src/sys/amd64/amd64/exception.S:602
> #13 0x in ?? ()
> (kgdb) p td->td_proc->p_pid
> $7 = 1
> (kgdb) p td->td_proc->p_comm
> $8 = "kernel", '\0'
> (kgdb) p td->td_tid
> $9 = 12
>
> Also:
> (kgdb) p/d td->td_user_pri
> $10 = 139
> (kgdb) p/d td->td_base_pri
> $11 = 84
>
--
Andriy Gapon
___
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"
