Can't work out which disk we are booting from
Hi, I have installed freebsd 7.1 on a 8GB usb flash drive. Now, it seems that the freebsd loader is unable to identify the usb disk where is booting from(da0s1a). The loader runs fine from the stick but gets confused on the drive it runs from, and the kernel it's not loaded. Here is what the loader prints out: [...] Bios drive A: is disk0 [...] Can't work out which disk we are booting from. Guessed BIOS device 0x80 not found by probes, defaulting to disk0: can't load 'kernel' I installed grub too and grub is loading the freebsd loader just fine, but the freebsd loader still get confused. Unfortunately I wasn't able to load the kernel (/boot/kernel/kernel) directly from grub. ___ 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: The rc.d mess strikes back
Brooks Davis wrote: On Wed, Mar 04, 2009 at 12:04:06AM -0800, Garrett Cooper wrote: On Tue, Mar 3, 2009 at 10:12 PM, Mike Telahun Makonnen wrote: On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis wrote: I don't have much time to debug this, but I've not had problems with services starting too early on the systems I've been running with async dhcp. ?If there is a problem with the wait process we need to actually debug it. ?If the wait for a route/running interface isn't sufficent we should try to figure out what is. ?Synchronous dhcp sucks and yeilds justifed user complaints so it would be nice to kill it off. ?I switched the default because it worked for me and I hoped that people would help find and fix edge cases. Can you elaborate why synchronous DHCP sucks ? The only reason I could see is bringup time. Am I correct in this assumption? If you use synchronous DHCP then every interface that wants to try to get a DHCP address if it has link needs to run through the full link timeout at boot. On a laptop this is annoying and generally pointless. Ok, I just turned synchronous dhclient on locally and I see what you mean. The changes to defaultroute to wait for a default route to be set mean that you consolidate the wait in one location and you don't waste time starting dhclient on interfaces until a link exists (or an association is made for wlan devices). OK, so that means that it's not just waiting for the default route, but it's also waiting for the link on any DHCP interfaces to come up as well. That's what confused me. When it's plugged in my NIC's link is always up by the time rc.d gets to the default route, so I didn't see the point in waiting the extra 30sec when it wasn't plugged in. The comments also seemed to imply that we should be checking whether the link is up. Anyways, given that synchronous dhclient re-introduces the same problem I was trying to fix in the first place I'll just back the whole thing out until we can come up with a better fix. Do you mind if I change the timeout to 15sec. (instead of 30s)? There may well be something better to wait or a need for a longer timeout in some environments. It's also quite possible that we have an ordering problem and need to move some more things after defaultroute or move the checks to a different location. -- Brooks Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org ___ 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"
pendrive recognizing problem
Hello, First of all, please bear with me were this not the appropriate list for my question. I searched high and low for a clue to no avail. One of my pendrives (Kingston Datatraveler 2G) is recognized if no X is run before. If, however, an X session is already started all I see on the console after some time: uhub5: device problem (TIMEOUT), disabling port 5. (After this an old LEXAR pendrive works like charm on the same USB port.) I tried to run X without hald. Does not help. While this is certainly X related, I cant see why should this has an effect on a low level, device detection part of the OS. I appreciate any suggestion where to look for a solution. Thanks! Zsolt ps.: Please CC, as I am not on the list. ___ 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/126848: [usb]: USB Keyboard hangs during Installation
The following reply was made to PR usb/126848; it has been noted by GNATS. From: David Guedj To: bug-follo...@freebsd.org, f...@hotmail.com Cc: Subject: Re: usb/126848: [usb]: USB Keyboard hangs during Installation Date: Sun, 08 Mar 2009 12:44:32 +0100 I'm facing the exact same problem with 7.1 installation CD. USB Keyboard stop working as soon as the kernel loads. The mainboard is a Gigabyte GA-EP35C-DS3R. The problem is known to happen frequently on Gigabyte motherboards. I've tried myriad Linux distribution and none had this kind of problem. I've no other fix than unplug/plug the keyboard to make it working again. ___ 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: The rc.d mess strikes back
On Sun, Mar 08, 2009 at 01:02:12PM +0300, Mike Makonnen wrote: > Brooks Davis wrote: >> On Wed, Mar 04, 2009 at 12:04:06AM -0800, Garrett Cooper wrote: >>> On Tue, Mar 3, 2009 at 10:12 PM, Mike Telahun Makonnen >>> wrote: On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis wrote: > I don't have much time to debug this, but I've not had problems with > services starting too early on the systems I've been running with async > dhcp. ?If there is a problem with the wait process we need to actually > debug it. ?If the wait for a route/running interface isn't sufficent we > should try to figure out what is. ?Synchronous dhcp sucks and yeilds > justifed user complaints so it would be nice to kill it off. ?I switched > the default because it worked for me and I hoped that people would help > find and fix edge cases. Can you elaborate why synchronous DHCP sucks ? >>> The only reason I could see is bringup time. Am I correct in this >>> assumption? >> >> If you use synchronous DHCP then every interface that wants to try to >> get a DHCP address if it has link needs to run through the full link >> timeout at boot. On a laptop this is annoying and generally pointless. > > Ok, I just turned synchronous dhclient on locally and I see what you > mean. > >> The changes to defaultroute to wait for a default route to be set mean >> that you consolidate the wait in one location and you don't waste time >> starting dhclient on interfaces until a link exists (or an association >> is made for wlan devices). > > OK, so that means that it's not just waiting for the default route, but > it's also waiting for the link on any DHCP interfaces to come up as > well. That's what confused me. When it's plugged in my NIC's link is > always up by the time rc.d gets to the default route, so I didn't see > the point in waiting the extra 30sec when it wasn't plugged in. The > comments also seemed to imply that we should be checking whether the > link is up. > > Anyways, given that synchronous dhclient re-introduces the same problem > I was trying to fix in the first place I'll just back the whole thing out > until we can come up with a better fix. Do you mind if I change the timeout > to 15sec. (instead of 30s)? 15 is probably a bit short in practice for wpa networks. Someone a while back suggested that there's some reason (perhaps spanning tree, but I can't remember) why it it should be closer to 50sec for maximum reliability. One thing I've thought of adding is changing the sleeps to "read -t1", checking for a non-timeout result and adding "Press return to skip". Another option would be for each interface to set a minimum timeout based on it's type such as having WPA interfaces set it to 30 and others set it to 15. -- Brooks pgpkYaoGsv7f2.pgp Description: PGP signature
Re: The rc.d mess strikes back
Brooks Davis wrote: On Sun, Mar 08, 2009 at 01:02:12PM +0300, Mike Makonnen wrote: Brooks Davis wrote: On Wed, Mar 04, 2009 at 12:04:06AM -0800, Garrett Cooper wrote: On Tue, Mar 3, 2009 at 10:12 PM, Mike Telahun Makonnen wrote: On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis wrote: I don't have much time to debug this, but I've not had problems with services starting too early on the systems I've been running with async dhcp. ?If there is a problem with the wait process we need to actually debug it. ?If the wait for a route/running interface isn't sufficent we should try to figure out what is. ?Synchronous dhcp sucks and yeilds justifed user complaints so it would be nice to kill it off. ?I switched the default because it worked for me and I hoped that people would help find and fix edge cases. Can you elaborate why synchronous DHCP sucks ? The only reason I could see is bringup time. Am I correct in this assumption? If you use synchronous DHCP then every interface that wants to try to get a DHCP address if it has link needs to run through the full link timeout at boot. On a laptop this is annoying and generally pointless. Ok, I just turned synchronous dhclient on locally and I see what you mean. The changes to defaultroute to wait for a default route to be set mean that you consolidate the wait in one location and you don't waste time starting dhclient on interfaces until a link exists (or an association is made for wlan devices). OK, so that means that it's not just waiting for the default route, but it's also waiting for the link on any DHCP interfaces to come up as well. That's what confused me. When it's plugged in my NIC's link is always up by the time rc.d gets to the default route, so I didn't see the point in waiting the extra 30sec when it wasn't plugged in. The comments also seemed to imply that we should be checking whether the link is up. Anyways, given that synchronous dhclient re-introduces the same problem I was trying to fix in the first place I'll just back the whole thing out until we can come up with a better fix. Do you mind if I change the timeout to 15sec. (instead of 30s)? 15 is probably a bit short in practice for wpa networks. Someone a while back suggested that there's some reason (perhaps spanning tree, but I can't remember) why it it should be closer to 50sec for maximum reliability. One thing I've thought of adding is changing the sleeps to "read -t1", checking for a non-timeout result and adding "Press return to skip". Another option would be for each interface to set a minimum timeout based on it's type such as having WPA interfaces set it to 30 and others set it to 15. wpa is typically not the issue unless wpa-eapol is involved (in which case you need to negotiate with a backend authentication server). wpa typically takes <100ms to handshake and plumb keys once you have an association. The more time consuming aspects of setting up a wireless connection are scanning (if dual-band and not done intelligently) and how fast the dhcp server is (I have observed 15-30 sec lag on some large corporate nets). One thing I don't understand is why we poll at all given that we can listen to the routing socket and figure out exactly what we need. This would require a new app but that's easy (just mod something like wlanwatch or route). We'd still need to decide how to handle the timeout and/or how to deal with interrupting the process. Sam ___ 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"
Latest kernel breaks scanner
Sigh. Had a working system from Mar 4th. Upgraded now it doesn't work. Scanner not found by xsane. Warner ___ 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: Latest kernel breaks scanner
On Sun, Mar 08, 2009 at 01:06:59PM -0600, M. Warner Losh wrote: > Sigh. Had a working system from Mar 4th. Upgraded now it doesn't > work. Scanner not found by xsane. Are you sure its not this? 20090227: The /dev handling for the new USB stack has changed, a buildworld/installworld is required for libusb20. Does usbconfig list your devices? Andrew ___ 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 touchpad not working properly on CURRENT with usb2
Hi Boris, Based on the HID descriptor dump you sent I've found and corrected a couple of bugs in the FreeBSD kernel HID parser. 1) cvsup to latest current. 2) replace the two patched files with the version from USB P4 3) compile new kernel and modules If it doesn't work, then turn on ums debugging before plugging the devices and send me the result! Patch: http://perforce.freebsd.org/chv.cgi?CH=158868 --HPS ___ 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: Latest kernel breaks scanner
In message: <20090308.130659.-1303465250@bsdimp.com> "M. Warner Losh" writes: : Sigh. Had a working system from Mar 4th. Upgraded now it doesn't : work. Scanner not found by xsane. Most likely userland, since the kernel that it worked on last week doesn't work now. Warner : Warner : ___ : 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" : : ___ 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: Latest kernel breaks scanner
In message: <20090308203157.gc30...@citylink.fud.org.nz> Andrew Thompson writes: : On Sun, Mar 08, 2009 at 01:06:59PM -0600, M. Warner Losh wrote: : > Sigh. Had a working system from Mar 4th. Upgraded now it doesn't : > work. Scanner not found by xsane. : : Are you sure its not this? : : 20090227: :The /dev handling for the new USB stack has changed, a :buildworld/installworld is required for libusb20. Yes. Been there, done that. Also have the libmap.conf changes in place for old binaries that had worked for months before that. xsane used to just work in this setup, but now fails. Looks like some kind of mismatch in the ABI: found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 it used to print a real product/vendor there... : Does usbconfig list your devices? Yes. Warner ___ 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: Latest kernel breaks scanner
On Sun, Mar 08, 2009 at 03:43:53PM -0600, M. Warner Losh wrote: > In message: <20090308203157.gc30...@citylink.fud.org.nz> > Andrew Thompson writes: > : On Sun, Mar 08, 2009 at 01:06:59PM -0600, M. Warner Losh wrote: > : > Sigh. Had a working system from Mar 4th. Upgraded now it doesn't > : > work. Scanner not found by xsane. > : > : Are you sure its not this? > : > : 20090227: > :The /dev handling for the new USB stack has changed, a > :buildworld/installworld is required for libusb20. > > Yes. Been there, done that. Also have the libmap.conf changes in > place for old binaries that had worked for months before that. xsane > used to just work in this setup, but now fails. Looks like some kind > of mismatch in the ABI: > > found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 Not sure what would have caused that. Before you spend too much time on this you may want to note that the integration patches for libusb into the ports build will likely be committed tomorrow. This will bump the port numbers so the affected ports rebuild, hopefully sane with DTRT after that. Andrew ___ 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"
1wire sensor with ugen...
Hello,
I've a 1wire USB device with a temperature sensor which I'm trying to set
up. My FreeBSD 7.x (RELENG_7) system detects it on boot and IDs it
correctly:
ugen1: on uhub0
which results in /dev/ugen1 , /dev/ugen1.1 and /dev/ugen1.2 devices all
being created.
The sensor should be accessible as a straight serial device (9600 baud,
etc), but my attempts using pyserial aren't working:
>>> s = serial.Serial('/dev/ugen1', 9600, timeout=1)
>>> s.read(10)
Traceback (most recent call last):
File "", line 1, in
File "build/bdist.freebsd-7.1-STABLE-amd64/egg/serial/serialposix.py",
line 344, in read
serial.serialutil.SerialException: Port not open
>>> s.isOpen()
False
I don't have much experience working directly with ugen devices, so any
advice to get this working would be appreciated.
Thanks!
--
Conall O'Brien
___
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 touchpad not working properly on CURRENT with usb2
> Hi Boris, > > Based on the HID descriptor dump you sent I've found and corrected a couple > of bugs in the FreeBSD kernel HID parser. > > 1) cvsup to latest current. > 2) replace the two patched files with the version from USB P4 > 3) compile new kernel and modules > > If it doesn't work, then turn on ums debugging before plugging the devices > and send me the result! > > Patch: > > http://perforce.freebsd.org/chv.cgi?CH=158868 > > --HPS Hi Hans, I performed steps 1, 2 and 3 (in step 2 downloaded and then replaced the files usb_hid.c and usb_hid.h.) - there is no change in the behavior of the touchpad. It still does not function properly. Resetting the device with "hw.usb2.ums.debug" set to "1" produces the following output in dmesg : usbconfig -u 0 -a 2 reset ukbd0: at uhub0, port 2, addr 2 (disconnected) ums1: at uhub0, port 2, addr 2 (disconnected) ums_detach:608: sc=0xff00017c3400 uhid1: at uhub0, port 2, addr 2 (disconnected) ukbd0: on usbus0 kbd1 at ukbd0 ums1: on usbus0 ums1: 3 buttons and [XY] coordinates ums_attach:546: sc=0xff000d06a400 ums_attach:547: X 8/8 ums_attach:548: Y 16/8 ums_attach:549: Z 0/0 ums_attach:550: T 0/0 ums_attach:551: W 0/0 ums_attach:555: B1 0/1 ums_attach:555: B2 1/1 ums_attach:555: B3 2/1 ums_attach:557: size=64, id=0 uhid1: on usbus0 Best regards, Boris Kotzev ___ 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"
