Re: uchcom update
On 28/02/2021 11:03, KOT MATPOCKuH wrote: > Hello! > > I'm using FreeBSD 12.2-STABLE r368656 and got usb-to-rs232 with this > controller. > I see /dev/cuaU0 after plugging in adapter, I can attach to serial line > using cu, but after sending any symbol to device I have device reconnection: > uchcom0 on uhub0 > uchcom0: on usbus0 > uchcom0: CH340 detected > uchcom0: at uhub0, port 9, addr 17 (disconnected) > uchcom0: detached > uchcom0 on uhub0 > uchcom0: on usbus0 > uchcom0: CH340 detected I have this in my loader.conf: # Ignore result of "clear stall" (clearing halt on endpoints) # CH340 USB<->RS232 requires this # and it seems that Linux and Windows do this by default hw.usb.no_cs_fail=1 I recall that without that tuning I had a similar problem. > вт, 5 июн. 2018 г. в 15:05, Ian FREISLICH : > >> On 05/22/2018 09:44 AM, Andriy Gapon wrote: >>> Yesterday I committed some changes to uchcom (so far, only in CURRENT). >>> Commits are r333997 - r334002. >>> >>> If you have a CH340/341 based USB<->RS232 adapter and it works for you, >> could >>> you please test that it still does? >>> If you tried your adapter in the past and it did not work, there is a >> chance it >>> might start working now. Could you please test that as well? >> >> ugen5.4: at usbus5, cfg=0 md=HOST spd=FULL >> (12Mbps) pwr=ON (96mA) >> ugen5.4.0: uchcom0: >> >> It's not made it any worse. I'm not using this adapter by choice - it's >> a USB to Maxim (Dallas) one-wire bus adapter. The manual used to state >> that these are possibly the worst chips ever. Is that still the >> prevailing opinion? -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: driver for cp2112 (USB GPIO and I2C gadget)
On 19/06/2020 17:14, Andriy Gapon wrote: > > If anyone interested in reviewing a new driver please help yourself to: > https://reviews.freebsd.org/D25359 > https://reviews.freebsd.org/D25360 > What might be curious about it is that there are usb, i2c and gpio mixed > together. Any interest at all? I am still torn about which of the approaches to take. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Realtex 0x0129 Card Reader problems
On 05/07/2020 04:32, Peter Jeremy wrote: > I have a laptop with the following card reader: > ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) > pwr=ON (500mA) > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x00ff > bDeviceSubClass = 0x00ff > bDeviceProtocol = 0x00ff > bMaxPacketSize0 = 0x0040 > idVendor = 0x0bda > idProduct = 0x0129 > bcdDevice = 0x3960 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x0003 <2010020139600> > bNumConfigurations = 0x0001 I believe that this hardware needs a driver that FreeBSD does not have. The corresponding Linux driver is rtsx_usb (drivers/misc/cardreader/rtsx_usb.c). > and I'm trying to get it working. I've found several previous threads: > https://lists.freebsd.org/pipermail/freebsd-usb/2013-July/012200.html > https://lists.freebsd.org/pipermail/freebsd-usb/2014-April/012874.html > https://lists.freebsd.org/pipermail/freebsd-usb/2016-February/014128.html > that suggest various quirks but none of those threads mention success and > the suggested quirks don't work for me - in particular, unless I force > both the wire and command protocol, nothing works and even with both > UQ_MSC_FORCE_WIRE_BBB and UQ_MSC_FORCE_PROTO_SCSI, I also need > UQ_MSC_NO_INQUIRY and UQ_MSC_NO_GETMAXLUN - which just moves the error to: > (da0:umass-sim0:0:0:0): got CAM status 0x44 > (da0:umass-sim0:0:0:0): fatal error, failed to attach to device > That all makes me wonder if FreeBSD is actually communicating with the > device at all. > > Can anyone offer a set of quirks that will actually work with this reader? > -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
driver for cp2112
If anyone interested in reviewing a new driver please help yourself to: https://reviews.freebsd.org/D25359 https://reviews.freebsd.org/D25360 What might be curious about it is that there are usb, i2c and gpio mixed together. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
HID++
I wonder if anyone has done any work on HID++ support. Esp., on the kernel side. For curious, this is a Logitech thing built on top of HID that can be used for extra information and configuration of their devices. E.g., query battery info from a wireless mouse. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
uchcom update
Yesterday I committed some changes to uchcom (so far, only in CURRENT). Commits are r333997 - r334002. If you have a CH340/341 based USB<->RS232 adapter and it works for you, could you please test that it still does? If you tried your adapter in the past and it did not work, there is a chance it might start working now. Could you please test that as well? Thanks! -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
phantom device disconnects
Since yesterday I am getting message like the following at random intervals: ugen1.3: at usbus1 (disconnected) ugen1.3: at usbus1 (disconnected) ugen1.3: at usbus1 (disconnected) There are not matching messages about any connected device and usbconfig, obviously, knows nothing about ugen1.3: ugen6.1: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen5.1: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (98mA) ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) Seems like this is caused by flaky hardware? Or something else? Is there a way to stop the spam? Should we be reporting diconnects for unattached ports at all? Thanks! -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb printer vs cups
On 12/09/2014 23:12, Volodymyr Kostyrko wrote: > On 12.09.2014 20:53, Andriy Gapon wrote: >> >> From my experience I think that cupsd executes backend tools with all uids >> and >> gids set to cups and no supplementary groups. In the case of USB printers >> the >> backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a >> printer. That means that the access to those devices must be somehow >> granted to >> cups:cups. >> How do people solve this? What kind of permissions / configuration do you >> use? > > devfs Yes, devfs. So how exactly do you configure permissions, ownerships? >> P.S. >> Maybe I over-generalized the issue to all USB printers. My personal >> experience >> is with an HP printer handled by hplip / hplip-plugin. > > Personally I prefer using stock lpd for those, it can be easily integrated > with > foomatic hpijs. > -- 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 printer vs cups
>From my experience I think that cupsd executes backend tools with all uids and gids set to cups and no supplementary groups. In the case of USB printers the backends need to access /dev/usbctl and /dev/usb/foobar that corresponds to a printer. That means that the access to those devices must be somehow granted to cups:cups. How do people solve this? What kind of permissions / configuration do you use? P.S. Maybe I over-generalized the issue to all USB printers. My personal experience is with an HP printer handled by hplip / hplip-plugin. -- 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 Flash drive problem with 9.0
on 25/03/2012 08:02 Kaho Toshikazu said the following: > Hello Andriy Gapon, > Thank you for your comment. > >> Message-ID: <4f6d9672.4050...@freebsd.org> >> Date: Sat, 24 Mar 2012 11:40:02 +0200 >> >> on 24/03/2012 04:17 Kaho Toshikazu said the following: >>> Hello, >>> >>> I have a similar problem with Transcend 16GB USB flash. When the flash >>> is plugged, FreeBSD attache it, but reports very big capacity and can >>> not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines. >>> 10-current and 8-stable have same problem, and 9-stable is not tested. >> >> Could the problem be related to r229288 (r232943 in stable/9)? >> The dates below match the MFC date 2012-03-13. > > 10-current r26 with reveting only scsi_da.c changed by > r233288 has same problem. Should I revert whole system ? > Sorry, it seems that I copied wrong revisions into my email. They should have been r232941 for stable/9 and r228846 for head. -- 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 Flash drive problem with 9.0
on 24/03/2012 04:17 Kaho Toshikazu said the following: > Hello, > > I have a similar problem with Transcend 16GB USB flash. When the flash > is plugged, FreeBSD attache it, but reports very big capacity and can > not read/write it. UQ_MSC_NO_INQUIRY makes jobs in my machines. > 10-current and 8-stable have same problem, and 9-stable is not tested. Could the problem be related to r229288 (r232943 in stable/9)? The dates below match the MFC date 2012-03-13. > To: freebsd-usb@freebsd.org > Subject: Re: USB Flash drive problem with 9.0 > From: Hans Petter Selasky > Date: Fri, 23 Mar 2012 08:25:32 +0100 > Cc: Alexander Motin , freebsd-curr...@freebsd.org, "J.J. > Day" > > On Friday 23 March 2012 06:14:08 J.J. Day wrote: >> I am upgrading a FreeBSD server and have encountered a problem with >> mounting a USB flash drive. The system was on 6.3 and I upgraded to 9.0 >> using CVS repositories. The flash drive worked properly at all steps >> throughout the upgrade. However, after the OS upgrade was complete, I >> made a mistake and destroyed some of the server application. >> >> So, I set the >> upgraded drive aside, copied the original source drive to a different >> spare, and repeated the upgrade process taking care to verify the >> functioning of the applications during the process. When I finished the >> second time, everything worked properly except for mounting the flash >> drive. >> >> it appears that something changed with the OS code that reads the drive >> firmware between the first time I ran cvsup on (about) the 9th and the >> second time I ran it about the 18th. >> >> >> >> This is the output from the first upgrade (3/11/2012) when the drive is >> inserted: >> >> >> >> ugen4.2: at usbus4 >> umass0: on usbus4 >> umass0: SCSI over Bulk-Only; quirks = 0x0100 >> umass0:2:0:-1: Attached to scbus2 >> da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 >> da0: Removable Direct Access SCSI-4 device >> da0: 40.000MB/s transfers >> da0: 30960MB (63406080 512 byte sectors: 255H 63S/T 3946C) >> And diskinfo output: >> >> >> >> da0 >> 512 # sectorsize >> 32463912960 # mediasize in bytes (30G) >> 63406080# mediasize in sectors >> 0 # stripesize >> 0 # stripeoffset >> 3946# Cylinders according to firmware. >> 255 # Heads according to firmware. >> 63 # Sectors according to firmware. >> AA22064F0035# Disk ident. >> This is the output from the second upgrade (3/18/2012) when the drive is >> inserted: >> >> >> >> ugen4.2: at usbus4 >> umass0: on usbus4 >> umass0: SCSI over Bulk-Only; quirks = 0x0100 >> umass0:2:0:-1: Attached to scbus2 >> da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 >> da0: Removable Direct Access SCSI-4 device >> da0: 40.000MB/s transfers >> da0: 17454747090944MB (71776119061217281 512 byte sectors: 64H 32S/T 0C) >> And diskinfo shows: >> > > Hi, > >> >> da0 >> 512 # sectorsize >> -144115188075855360 # mediasize in bytes () >> -281474976710655# mediasize in sectors >> 0 # stripesize >> 0 # stripeoffset >> -137438953471 # Cylinders according to firmware. >> 64 # Heads according to firmware. >> 32 # Sectors according to firmware. >> AA22064F0035# Disk ident. >> Since the size information is incorrect, the /dev/da0s1 device is not >> created and the drive cannot be mounted. The problem only happens with a >> large drive. When I use a 4GB or 8GB drive, everything works correctly. >> >> If there is any information that I can submit that can assist in solving >> the problem please let me know. >> > > This does not look like a USB problem. It is the SCSI/CAM layer which queries > over SCSI USB how big the disk is. > > BTW: > > dec2hex(17454747090944) > ans = FE0 > > So it looks like some additional bits have sneaked in there? > > dec2hex(32463912960) > ans = 78F00 > > 0xFE0 / 0x78F00 > ans = 537.67 > > So it looks like the mediasize was multiplied by 512 when it shouldn't. > > --HPS -- 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: SuperMicro IPMI keyboard - fails for 'mountroot>' prompt under FreeBSD 9-R...
on 29/02/2012 11:47 Karl Pielorz said the following: > <http://www.tdx.com/x8dtl-if.txt> So the cause is that ukbd driver tries to attach after the mountroot stage. The symptom is obvious, a fix is not. -- 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: a few usb issues related to edge cases
on 21/12/2011 18:38 Hans Petter Selasky said the following: > On Wednesday 21 December 2011 12:29:49 Andriy Gapon wrote: >> on 20/12/2011 14:25 Andriy Gapon said the following: >>> I just wanted to draw your attention to the fact that obtaining any locks >>> in the kdb context (or USB polling code in general, even) is not a good >>> idea. Chances of getting into trouble on those locks are probably quite >>> moderate or even low, but they do exist. I am not sure if you are >>> getting any bug reports about such troubles :-) Regular users probably >>> do not use kdb too often and a panic for them is just a "crash", so they >>> likely do not expect anything usable/debuggable after that :-) >> >> Looking some more at the code I just got myself confused as to how the >> dumping to a umass device could work when the scheduler is stopped. >> It seems that the umass_command_start -> usbd_transfer_start -> >> usbd_callback_ss_done_defer functions would always put a transfer request >> onto a queue and try to wake up a thread to process that queue and the >> request. But that's obviously not going to work when the other thread is >> not going to be run. Have I missed a code path that leads directly to the >> controller in this context? Thank you for your help. > > Hi, > > Those threads should be polled when calling usbd_transfer_poll(). I.E. the > wakeup should be stubbed in the !scheduler_running case. Ah, that's what I missed! -- 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: a few usb issues related to edge cases
on 20/12/2011 14:25 Andriy Gapon said the following: > I just wanted to draw your attention to the fact that obtaining any locks in > the > kdb context (or USB polling code in general, even) is not a good idea. > Chances of getting into trouble on those locks are probably quite moderate or > even low, but they do exist. I am not sure if you are getting any bug reports > about such troubles :-) Regular users probably do not use kdb too often and a > panic for them is just a "crash", so they likely do not expect anything > usable/debuggable after that :-) Looking some more at the code I just got myself confused as to how the dumping to a umass device could work when the scheduler is stopped. It seems that the umass_command_start -> usbd_transfer_start -> usbd_callback_ss_done_defer functions would always put a transfer request onto a queue and try to wake up a thread to process that queue and the request. But that's obviously not going to work when the other thread is not going to be run. Have I missed a code path that leads directly to the controller in this context? Thank you for your 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: ukbd locking update
on 20/12/2011 18:41 Hans Petter Selasky said the following: > On Tuesday 20 December 2011 16:16:36 Andriy Gapon wrote: >> And the new patch: >> http://people.freebsd.org/~avg/usb.new.diff > > Patch looks OK. I will give it a spin later today. Feel free to commit if > you've tested the three use-cases I listed in a previous e-mail. Thank you for the quick review. My tests were all successful, including those 3 scenarios. Please let me know if you have any questions and how your testing goes. I will try to commit this tomorrow morning. -- 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 locking update
And the new patch: http://people.freebsd.org/~avg/usb.new.diff -- 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 locking update
on 20/12/2011 16:00 Attilio Rao said the following: > 2011/12/20 Andriy Gapon : >> >> I completing a patch that changes some locking in ukbd to account for >> SCHEDULER_STOPPED and for other realities of the code. >> >> As a preview I would like to share couple of observations that had their >> effect >> on the patch. >> >> 1. Acquiring Giant in device_attach, _detach in similar newbus method >> implementations should be redundant because those are already executed with >> Giant held. That's done either by the general newbus code or via >> usbd_enum_lock() when the operations are executed in the USB explore thread. > > That's right, however, if you plan to axe those because of the newbus > assumption I'd prefer you add a comment for every function you touch > saying that it needs to be Giant protected (in order to cope with them > once newbus is made MPSAFE). I put mtx_assert there. I think that that should be sufficiently self-documenting and self-protecting 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"
ukbd locking update
I completing a patch that changes some locking in ukbd to account for SCHEDULER_STOPPED and for other realities of the code. As a preview I would like to share couple of observations that had their effect on the patch. 1. Acquiring Giant in device_attach, _detach in similar newbus method implementations should be redundant because those are already executed with Giant held. That's done either by the general newbus code or via usbd_enum_lock() when the operations are executed in the USB explore thread. 2. As discussed before: if (!mutex_owned(&Giant)) mutex_lock(&Giant) this pattern does not make sense, because the Giant is recursive and can be simply acquired without any check. Do you agree? -- 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: a few usb issues related to edge cases
r USB polling code in general, even) is not a good idea.
Chances of getting into trouble on those locks are probably quite moderate or
even low, but they do exist. I am not sure if you are getting any bug reports
about such troubles :-) Regular users probably do not use kdb too often and a
panic for them is just a "crash", so they likely do not expect anything
usable/debuggable after that :-)
P.S. Since most (but not all) locking operations in the USB code are already
wrapped under USB-specific macros, then probably it could make sense to
implement your suggestion locally to the USB code. Just need to take some care
to cover the cases that are not wrapped yet (direct calls to mtx_lock and
similar) and to handle cases where important decisions are made based on
mtx_owned return value (especially in loops).
For example, below are some macros that I want to use in the ukbd code:
#define KBD_LOCK() \
do {\
if (!kdb_active)\
mtx_lock(&Giant); \
} while (0)
#define KBD_UNLOCK()\
do {\
if (!kdb_active)\
mtx_unlock(&Giant); \
} while (0)
#ifdef INVARIANTS
#define KBD_LOCK_ASSERT() \
do {\
if (!cold && !kdb_active && panicstr == NULL) \
mtx_assert(&Giant, MA_OWNED); \
} while (0)
#else
#define KBD_LOCK_ASSERT() (void)0
#endif
P.P.S. Did you have a chance to look at http://wiki.freebsd.org/AvgSyscons yet?
Thank you!
--
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: a few usb issues related to edge cases
on 19/12/2011 17:11 Hans Petter Selasky said the following: > I will fix that. I see a missing wait there. Can I assume that we are allowed > to sleep from device_shutdown() and that system timers still work? I don't see any reason why either of these should be not true. Oh, and I see that you've already committed the change - 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: a few usb issues related to edge cases
First replying just to couple of points where there seems to be a misunderstanding. on 19/12/2011 16:30 Hans Petter Selasky said the following: >> 2. Somewhat related to the above. I think that because the USB subsystem >> implements the shutdown method and detaches all its drivers, then the ukbd >> driver won't be able to properly handle the 'shutdown -h' case where the >> kernel asks to "press any key to reboot" at the end. Depending on which >> thread wins the race (the one that executes the mainline shutdown code or >> the USB explore thread that detaches USB devices) there will either an >> immediate reboot or a later crash when any key is pressed. >> This is not critical, but OTOH perhaps the USB subsystem doesn't have to do >> the shutdown. As far as I can see a lot of the drivers just do nothing >> for the shutdown, for better or for worth. >> >> A side note: perhaps it would be a good idea to pass the 'how' value as an >> additional parameter to device_shutdown. > > The shutdown of USB is done to give USB devices at last chance to turn off or > reduce their current consumption. > > In the old code the Host controller itself would be disabled, so keyboard > wouldn't have worked I believe like you suggest. I am not sure about the old code, I have never checked it. But the atkbd definitely works at this stage. > BTW: Shutdown should be executed after any "Press any key to reboot." and > shutdown should be given time to complete, hence for USB this needs to happen > in sync with the rest of the USB system. Have you actually ever done "shutdown -h"? In other words do you know what the "system halt" is? :) I am not sure if it would be a good idea to declare a system as "halted" before shutdown_final hooks are executed. I would rather sacrifice the whole "press a key" interactivity and simply executed hlt. That's because I think that the system halt has a very limited usage, mostly in combination with UPS, where interactivity via console/keyboard is not very important. BTW, the reason that I suggested to pass 'how' to device_shutdown is to give drivers some choice. E.g. USB could the whole shutdown thing for the cases of poweroff and reboot, but keep the devices going for halt. But probably right now we just need to make a decision whether ukbd is going to support system halt or not. If not, then I think that usb_shutdown() must wait until the explore_proc terminates. If yes, then usb_shutdown() should become a noop. Or it could become quite smart to detach/poweroff other devices in such a way that ukbd still stays usable. But that's probably harder to implement. [snip] >> As a side note: we probably need a flag to mark certain things such as e.g. >> the ukbd driver as "non recoverable", meaning that once those are used in >> the kdb context then there is no safe way to go back to normal system >> operation. > > I think you need to do shutdown _after_ the "Press any key to reboot". A flag > won't help. Umm, this suggestion was about entering and exiting KDB/DDB, not about shutdown/reboot. P.S. I've just looked at the code in stable/7 and it seems that it didn't actually unconfigured USB and detached device drivers. At least ohci_shutdown and ohci_shutdown are not called on FreeBSD. -- 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"
a few usb issues related to edge cases
Hans Petter, I think that I see some issues in the USB code that could cause problems in some edge cases. >From easiest to hardest: 1. I think that currently there is a LOR in usb_bus_shutdown. I think that the following patch should fix it: === --- a/sys/dev/usb/controller/usb_controller.c +++ b/sys/dev/usb/controller/usb_controller.c @@ -479,6 +481,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm) bus_generic_shutdown(bus->bdev); + USB_BUS_UNLOCK(bus); usbd_enum_lock(udev); err = usbd_set_config_index(udev, USB_UNCONFIG_INDEX); @@ -497,6 +500,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm) (bus->methods->set_hw_power_sleep) (bus, USB_HW_POWER_SHUTDOWN); usbd_enum_unlock(udev); + USB_BUS_LOCK(bus); } static void === Otherwise there are a lot of nasty reports like: lock order reversal: (sleepable after non-sleepable) 1st 0xff80006b0688 ohci0 (ohci0) @ /usr/src/sys/dev/usb/controller/usb_controller.c:336 2nd 0xfe00023cf070 USB config SX lock (USB config SX lock) @ /usr/src/sys/dev/usb/usb_device.c:2643 usbd_transfer_unsetup can sleep! with the following non-sleepable locks held: exclusive sleep mutex ohci0 (ohci0) r = 0 (0xff80006b0688) locked @ /usr/src/sys/dev/usb/controller/usb_controller.c:336 2. Somewhat related to the above. I think that because the USB subsystem implements the shutdown method and detaches all its drivers, then the ukbd driver won't be able to properly handle the 'shutdown -h' case where the kernel asks to "press any key to reboot" at the end. Depending on which thread wins the race (the one that executes the mainline shutdown code or the USB explore thread that detaches USB devices) there will either an immediate reboot or a later crash when any key is pressed. This is not critical, but OTOH perhaps the USB subsystem doesn't have to do the shutdown. As far as I can see a lot of the drivers just do nothing for the shutdown, for better or for worth. A side note: perhaps it would be a good idea to pass the 'how' value as an additional parameter to device_shutdown. 3. Looking at usbd_transfer_poll I see that it touches a lot of locks, including taking the bus lock. As we've discussed before, this is not safe in a particular context where the polling is supposed to be used - in the kdb/ddb context. If the lock is already taken by another thread, then instead of being able to use a USB keyboard a user would get even less debug-able crash. Also, it seems that usbd_transfer_poll calls into the usual state machine with various callbacks and dynamically made decisions about whether to execute some actions directly or defer their execution to a different thread. That code also touches locks in various places. I think that it would be more preferable to have a method that does the job in a more straight-forward way, without touching any locks, ignoring the usual code paths and assuming that no other treads are running in parallel. Ditto for the method to submit a request. As a side note: we probably need a flag to mark certain things such as e.g. the ukbd driver as "non recoverable", meaning that once those are used in the kdb context then there is no safe way to go back to normal system operation. What do you think? Thank you. -- 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 18/12/2011 19:39 Hans Petter Selasky said the following: > On Sunday 18 December 2011 11:58:57 Andriy Gapon wrote: >> on 17/12/2011 19:06 Hans Petter Selasky said the following: >>> If the problem is only in UKBD driver, I don't think this is a big >>> problem to solve. The reason for the auto-magic locking, is that I've >>> sometimes seen callers in non-polling mode call into UKBD without Giant >>> locked. And this causes a panic when starting USB transfers, because the >>> code expects Giant to be locked. >> >> Hmm, do you have an example of such a panic? I couldn't find how this could >> be possible in my examination of non-polling entry points into syscons and >> kbd drives. > > mtx_assert(&Giant, MTX_OWNED); will panic if Giant is not locked. Do you need > an example? Yes :-) I want to see a non-polled code path in the keyboard layer where Giant is not locked. >>> Requirement: I would say that to use UKBD polling mode, the scheduler >>> must be stopped. Else you should not use polling mode at all. I think >>> that mountroot is getting characters the wrong way in this regard. >> >> I think that this is a too strong / unnecessary requirement. I think that >> now (after my recent syscons commits) ukbd should work correctly and >> optimally in this context. >> >> I have written a small article about my analysis of locking in syscons, >> underlying kbd drivers and ukbd in particular: >> http://wiki.freebsd.org/AvgSyscons >> I could have misunderstood or missed things, so I will appreciate a review >> and discussion of my observations. Thank you! > > I will have a look at it when I find some time! Hope it won't be long. Thank you! -- 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 17/12/2011 19:06 Hans Petter Selasky said the following: > If the problem is only in UKBD driver, I don't think this is a big problem to > solve. The reason for the auto-magic locking, is that I've sometimes seen > callers in non-polling mode call into UKBD without Giant locked. And this > causes a panic when starting USB transfers, because the code expects Giant to > be locked. Hmm, do you have an example of such a panic? I couldn't find how this could be possible in my examination of non-polling entry points into syscons and kbd drives. > Requirement: I would say that to use UKBD polling mode, the scheduler must be > stopped. Else you should not use polling mode at all. I think that mountroot > is getting characters the wrong way in this regard. I think that this is a too strong / unnecessary requirement. I think that now (after my recent syscons commits) ukbd should work correctly and optimally in this context. I have written a small article about my analysis of locking in syscons, underlying kbd drivers and ukbd in particular: http://wiki.freebsd.org/AvgSyscons I could have misunderstood or missed things, so I will appreciate a review and discussion of my observations. Thank you! -- 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
Replying further... on 16/12/2011 00:56 Hans Petter Selasky said the following: > On Thursday 15 December 2011 15:17:01 Andriy Gapon wrote: >> Hmm... I looked at the history of ukbd.c (which I should have done from the >> very start) and I see two relevant revisions: >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r2=2 >> 03896&pathrev=203896 >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r2= >> 223989&pathrev=223989 >> >> So, first use of pause(9) was introduced to work around current broken >> syscons polling mechanism. Then pause(9) was replaced with the >> hand-rolled yield to fix a problem at shutdown, which supposedly was >> caused by times being stopped. >> >> None of the commits seems to be directly related to thread priorities. > > Not directly, but indirect. You know, if you pause thread 1 (which I thought > was thread 0), then other thread will get a chance to run. pause() could be a sufficient action to let other thread run, but it is not a required action. As we've already discusses earlier all the USB threads have sufficiently high priorities to get runnable while other kernel threads are runnable. Only certain interrupt threads could have prevented them from running, but that's definitely not the case. > It might also be that Giant is locked by syscons, and that unless you pause > or > yield, then Giant will block other parts of USB, like the callback thread, > which is Giant locked for ukbd only to run. > > Maybe that is the explanation? Not sure if you are hypothesizing or if this is something that you experienced during development and testing. Let's consider a few observations. First, syscons doesn't acquire Giant anywhere in the path started from cngetc. Actually, I believe that the only place where Giant is now explicitly acquired in the whole syscons code can be safely replaced with an assert that the Giant is already held. Second, the polling mode is designed to be usable in situations where other threads are not running. So in general it should not depend on other threads being able to make any progress. -- 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 16/12/2011 01:16 Hans Petter Selasky said the following:
> I think I was not aware about the Giant locking maybe having something to do
> about this. I was just thinking about this recently, that syscons and all
> keyboard stuff, currently is Giant locked. Scary?
Nope :-)
I think that no syscons + keyboards code depends on the special properties of
the Giant, most likely with the prominent exception of the ukbd.
Also, the Giant is almost never acquired explicitly (again with the prominent
exception of the ukbd), which actually leads to a consequence that no lock is
acquired in the context where the kernel polls for input. Which is a good thing
if we keep in mind that the kernel may poll for input in the context like panic
or ddb where any lock may be already held by a thread that is not able to run.
> I can always become better writing commit messages! What is your plan forward
> then with regard to the Giant lock problem?
>
> If one thread is like:
>
> while (1)
> {
> lock(Giant);
> c = get nonblocking key from console();
> unlock(Giant);
> }
>
> And the other is like:
>
> if (callback complete) {
> lock(Giant);
> run callback();
> unlock(Giant);
> }
>
> Who gets to run?
First, there is no need to acquire the Giant in the first snippet.
Second, "get nonblocking key from console" should not depend on the callback in
a parallel thread. The polling routine should go all the way to hardware if
needed.
I see where all the complications in ukbd code come from. I think that they
started as attempts to work around the current stupid behavior of syscons during
polling:
do {
kbd_poll_enter();
try_to_get_one_char();
kbd_poll_exit();
} while (!got_a_char);
For ukbd this means ugly races between the polling thread and the usb threads at
the mountroot stage. And so you had to invent "polling autodetection" and add
extra locking. But that lead to troubles in the contexts where no lock was
previously held. And so on. So now ukbd resembles a big collection of hacks
and crotches.
For example consider the following scenario which does not occur very frequently
in reality, but is quite possible. Thread T1 on CPU P1 holds the Giant, at the
same time thread T2 on CPU P2 enters ddb. That means that T1 is "frozen" and
won't be able to release Giant. ddb would try to interact with an operator and
there would be a call-chain like this:
ukbd_check_char
scgetc
sc_cngetc
cncheckc
cngetc
db_readline
...
And now the code in ukbd to which I referred above:
/* check if char is waiting */
static int
ukbd_check_char(keyboard_t *kbd)
{
struct ukbd_softc *sc = kbd->kb_data;
if (!KBD_IS_ACTIVE(kbd))
return (0);
if (sc->sc_flags & UKBD_FLAG_POLLING) {
if (!mtx_owned(&Giant)) {
/* XXX cludge */
int retval;
mtx_lock(&Giant);
retval = ukbd_check_char(kbd);
mtx_unlock(&Giant);
return (retval);
So we are in a polling mode and Giant is not owned by us (T2) because it is
owned by T1 and so mtx_lock would be called and then we would probably get into
a recursion via mi_switch and kdb_reenter.
--
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 16/12/2011 00:56 Hans Petter Selasky said the following: > On Thursday 15 December 2011 15:17:01 Andriy Gapon wrote: >> Hmm... I looked at the history of ukbd.c (which I should have done from the >> very start) and I see two relevant revisions: >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r2=2 >> 03896&pathrev=203896 >> http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r2= >> 223989&pathrev=223989 >> >> So, first use of pause(9) was introduced to work around current broken >> syscons polling mechanism. Then pause(9) was replaced with the >> hand-rolled yield to fix a problem at shutdown, which supposedly was >> caused by times being stopped. >> >> None of the commits seems to be directly related to thread priorities. > > Not directly, but indirect. You know, if you pause thread 1 (which I thought > was thread 0), then other thread will get a chance to run. > > It might also be that Giant is locked by syscons, and that unless you pause > or > yield, then Giant will block other parts of USB, like the callback thread, > which is Giant locked for ukbd only to run. > > Maybe that is the explanation? Maybe. Perhaps even. But let me quote the commit messages just in case. Commit message #1: Detect when we are polling from kernel via cngetc() in the boot process and reserve the keypresses so they do not get passed to syscons. Commit message #2: Fix for dump after shutdown with USB keyboard plugged in. It appears that the system timer is stopped during shutdown and that the pause() statement in ukbd causes infinite hang in this regard. The fix is to use mi_switch() instead of pause() to do the required task switch to ensure that the required USB processes get executed. So the reason I asked the above question was that the issues that we are discussing now were never mentioned before. So if you know that those issue really exist, then maybe it is worthwhile describing and documenting them in detail. As you can see the commit messages mention neither thread priorities nor Giant, instead they talk about other rather specific (and plausible) issues. -- 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 14/12/2011 23:56 Hans Petter Selasky said the following: > On Wednesday 14 December 2011 16:37:50 Andriy Gapon wrote: >> So, Hans Petter, do you recall any details of this problem? >> I am curious about which thread got starved by which. > > From what I know this was 100% reproducible. > > Remove the ukbd_yield() when at the mountroot prompt. Result: cannot type any > keys. No USB devices will enumerate! This hasn't satisfied my curiosity :) >> >> BTW, given your recent improvements to pause(9) what do you think about >> further extending it to also use DELAY(9) when kdb_active is set or when >> SCHEDULER_STOPPED() is true? > > I think this is a good idea. It already checks for "cold". USB usually > doesn't > use this function though when polling. > >> Then, probably, pause(9) could be used for >> both branches in ukbd_do_poll and they could be collapsed together. Hmm... I looked at the history of ukbd.c (which I should have done from the very start) and I see two relevant revisions: http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=199816&r2=203896&pathrev=203896 http://svnweb.freebsd.org/base/head/sys/dev/usb/input/ukbd.c?r1=223755&r2=223989&pathrev=223989 So, first use of pause(9) was introduced to work around current broken syscons polling mechanism. Then pause(9) was replaced with the hand-rolled yield to fix a problem at shutdown, which supposedly was caused by times being stopped. None of the commits seems to be directly related to thread priorities. I suspect that even DELAY(9) could have worked in the place of the pause/yield. Also, I do not see any mentioning of the mountroot context in the commits. Not sure why I even assumed that it was relevant. BTW, maybe we should have a 'cold again' flag for late stages of system shutdown? So, all in all, I believe in the following two things: 1. kern_yield can be used instead of ukbd_yield with any argument 1.1. DELAY() can be used instead of ukbd_yield too 2. all that special code should not be needed once I commit the patches that I have recently posted to arch@ (I do intend to commit them). In that case the keyboard drivers would be properly put into the polling mode instead of the current situation where the polling mode is repeatedly entered and exited when kernel needs some input. Maybe you recall/know more than you wrote above and I have missed something obvious that you can point out? -- 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 10:17 Andriy Gapon said the following:
> on 13/12/2011 00:21 Andriy Gapon said the following:
[snip]
> 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.
So, Hans Petter, do you recall any details of this problem?
I am curious about which thread got starved by which.
BTW, given your recent improvements to pause(9) what do you think about further
extending it to also use DELAY(9) when kdb_active is set or when
SCHEDULER_STOPPED() is true? Then, probably, pause(9) could be used for both
branches in ukbd_do_poll and they could be collapsed together.
>> 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"
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 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"
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: 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"
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"
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"
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"
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"
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: 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: 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 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: > 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 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 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 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 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"
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"
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"
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"
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: 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: 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: 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: 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: 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: 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: 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: 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: [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: [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 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
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 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: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: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
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
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: 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: 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: 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: [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: 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: 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 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 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 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 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
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 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"
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: 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"
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: 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 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"
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: 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"
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: 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 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 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: 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: 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
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
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
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 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 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: 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]"
