Re: Raspberry PI gets USB support [FreeBSD 10 current]
On Tue, Sep 11, 2012 at 3:23 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Tuesday 11 September 2012 17:16:35 Ivan Voras wrote: On 10/09/2012 16:54, Hans Petter Selasky wrote: Hi, For those that want to try the Raspberry PI and its USB ports: Add this to sys/conf/files: dev/usb/controller/dwc_otg.coptional dwcotg arm/broadcom/bcm2835/dwc_otg_brcm.c optional dwcotg And add this to RPI-B: device dwcotg device usb device umass Open ISSUE: External USB ports do not enumerate. Set address times out. Reason unknown. Maybe someone out there has any clues? Thanks! :) I am waiting for my Raspberry Pi to arrive and I'd like very much to try FreeBSD on it! Hi, I've managed to resolve the problems appearing so far, though there might be more issues which we need to look at like CPU usage of the current driver implemented. 1) Get latest 10-current sources 2) Simply add to sys/arm/conf/RPI-B: device dwcotg device usb device smsc device mii device miibus And ue0 should show up! Good luck! I'll give this a shot on one of my RPIs. Thanks HPS! -Garrett ___ 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 Thu, Mar 1, 2012 at 3:07 AM, Karl Pielorz kpielorz_...@tdx.co.uk wrote: --On 29 February 2012 07:50 -0800 Garrett Cooper yaneg...@gmail.com wrote: The BIOS has an option for port 60/64 emulation - I've tried enabling it (didn't seem to make any difference with nothing changed on the FreeBSD side) - is there any way to coax the system to prefer / use what would appear to be a PS/2 keyboard at that stage? Have you tried kbdmux(4) yet? Do you mean (looking at the man page) just setting: hint.kbdmux.0.disabled=1 In device.hints? That didn't make any difference - nor, (just in case) did setting it to '0'. Are you sure it's compiled into the kernel? It's in GENERIC, but I'm not sure what you're running... -Garrett ___ 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 Wed, Feb 29, 2012 at 3:40 AM, Karl Pielorz kpielorz_...@tdx.co.uk wrote: --On 29 February 2012 12:44 +0200 Andriy Gapon a...@freebsd.org wrote: 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. The BIOS has an option for port 60/64 emulation - I've tried enabling it (didn't seem to make any difference with nothing changed on the FreeBSD side) - is there any way to coax the system to prefer / use what would appear to be a PS/2 keyboard at that stage? Have you tried kbdmux(4) yet? Thanks, -Garrett ___ 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/160301: [patch] missing device usb and device ucom entries in manpages
Number: 160301 Category: usb Synopsis: [patch] missing device usb and device ucom entries in manpages Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: doc-bug Submitter-Id: current-users Arrival-Date: Mon Aug 29 23:20:04 UTC 2011 Closed-Date: Last-Modified: Originator: Garrett Cooper Release:9.0-BETA1 Organization: iXsystems, Inc. Environment: FreeBSD burnout.ixsystems.com 9.0-BETA1 FreeBSD 9.0-BETA1 #0 r224989: Sun Aug 21 14:12:11 PDT 2011 gcoo...@burnout.ixsystems.com:/usr/obj/usr/src/sys/BURNOUT amd64 Description: The USB serial modules manpages are missing dependencies on usb and ucom: $ svngrep -r DEPEND /sys/dev/usb/serial/ | sed -E -e 's/.*MODULE_DEPEND\(//g' -e 's/(usb|ucom),.*/\1/g' -e 's/,/-/' | grep -v ^ucom | sort u3g- ucom u3g- usb uark- ucom uark- usb ubsa- ucom ubsa- usb ubser- ucom ubser- usb uchcom- ucom uchcom- usb ucycom- ucom ucycom- usb ufoma- ucom ufoma- usb uftdi- ucom uftdi- usb ugensa- ucom ugensa- usb uipaq- ucom uipaq- usb ulpt- usb umcs7840- ucom umcs7840- usb umct- ucom umct- usb umodem- ucom umodem- usb umoscom- ucom umoscom- usb uplcom- ucom uplcom- usb uslcom- ucom uslcom- usb uvisor- ucom uvisor- usb uvscom- ucom uvscom- usb The attached patch fixes the manpage bugs. How-To-Repeat: Fix: Patch attached with submission follows: Index: share/man/man4/ufoma.4 === --- share/man/man4/ufoma.4 (revision 224989) +++ share/man/man4/ufoma.4 (working copy) @@ -38,6 +38,8 @@ place the following lines in your kernel configuration file: .Bd -ragged -offset indent +.Cd device usb +.Cd device ucom .Cd device ufoma .Ed .Pp Index: share/man/man4/uchcom.4 === --- share/man/man4/uchcom.4 (revision 224989) +++ share/man/man4/uchcom.4 (working copy) @@ -40,6 +40,8 @@ place the following lines in your kernel configuration file: .Bd -ragged -offset indent +.Cd device usb +.Cd device ucom .Cd device uchcom .Ed .Pp Index: share/man/man4/uvisor.4 === --- share/man/man4/uvisor.4 (revision 224989) +++ share/man/man4/uvisor.4 (working copy) @@ -40,6 +40,8 @@ place the following lines in your kernel configuration file: .Bd -ragged -offset indent +.Cd device usb +.Cd device ucom .Cd device uvisor .Ed .Pp Index: share/man/man4/uplcom.4 === --- share/man/man4/uplcom.4 (revision 224989) +++ share/man/man4/uplcom.4 (working copy) @@ -40,6 +40,8 @@ place the following lines in your kernel configuration file: .Bd -ragged -offset indent +.Cd device usb +.Cd device ucom .Cd device uplcom .Ed .Pp Index: share/man/man4/ubser.4 === --- share/man/man4/ubser.4 (revision 224989) +++ share/man/man4/ubser.4 (working copy) @@ -39,6 +39,8 @@ place the following line in your kernel configuration file: .Bd -ragged -offset indent +.Cd device usb +.Cd device ucom .Cd device ubser .Ed .Pp Index: share/man/man4/umodem.4 === --- share/man/man4/umodem.4 (revision 224989) +++ share/man/man4/umodem.4 (working copy) @@ -40,6 +40,8 @@ place the following lines in your kernel configuration file: .Bd -ragged -offset indent +.Cd device usb +.Cd device ucom .Cd device umodem .Ed .Pp Index: share/man/man4/ubsa.4 === --- share/man/man4/ubsa.4 (revision 224989) +++ share/man/man4/ubsa.4 (working copy) @@ -39,6 +39,8 @@ place the following lines in your kernel configuration file: .Bd -ragged -offset indent +.Cd device usb +.Cd device ucom .Cd device ubsa .Ed .Pp Index: share/man/man4/umcs.4 === --- share/man/man4/umcs.4 (revision 224989) +++ share/man/man4/umcs.4 (working copy) @@ -39,6 +39,8 @@ place the following lines in your kernel configuration file: .Bd -ragged -offset indent +.Cd device usb +.Cd device ucom .Cd device umcs .Ed .Pp Index: share/man/man4/uftdi.4 === --- share/man/man4/uftdi.4 (revision 224989) +++ share/man/man4/uftdi.4 (working copy) @@ -40,6 +40,8 @@ place the following lines in your kernel configuration file: .Bd -ragged -offset indent +.Cd device usb +.Cd device ucom .Cd device uftdi .Ed .Pp Index: share/man/man4/umct.4 === --- share/man/man4/umct.4 (revision 224989) +++ share/man/man4/umct.4 (working copy) @@ -36,6 +36,8 @@ place the following lines
Re: 8.x grudges
On Wed, Jul 7, 2010 at 1:52 PM, Mikhail T. mi+t...@aldan.algebra.com wrote: 07.07.2010 16:34, Randi Harper ???(??): Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... Don't use a kernel config from 7. We've already told you this. Your telling me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to just work. Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7-8 is not revolutionary, but simply the next step. I read the UPDATING file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... Your way clearly isn't fine, as it doesn't work. That's an obviously flawed argument -- this line of thinking can be used against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of doing things clearly isn't fine. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If *I* have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... To put it in simple terms, there were changes made to geom, and the way that sysinstall writes out dedicated disks wasn't compatible. Search the mailing list archives. If this is a known problem, it is even more of an outrage, that some shim was not introduced to keep the users from hitting this particular bump. The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? There's a lot of secret sauce done for detecting whether or not you're booting from CD vs pxebooting in a release image, as well as within the sysinstall application as to what environment its dealing with, as well as what you get after things are done with a vanilla build and a sysinstall install (as I've discovered on my own). Unfortunately assuming both methods to produce the same result is flawed :(... Thanks, -Garrett ___ 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: 8.x grudges
On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
07.07.2010 14:59, Jeremy Chadwick ???(??):
FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and
thus not an option) -- the kernel-config files, that worked with
7.x, break without this option in them (in addition to all the
nuisance, that's documented in UPDATING -- which, somehow, makes
the breakage acceptable). config(8) would not warn about this, but
kernel build fails.
We don't use this option (meaning it's removed from our kernels). It's
definitely not required. All it does is ensure your kernel can
comprehend executables/binaries built on 7.x.
Attached is the kernel config-file (i386), that worked fine under 7.x. The
kernel-compile will break (some *freebsd7* structs undefined), without the
COMPAT_FREEBSD7 option. Try it for yourself...
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
Those require COMPAT_FREEBSD7. This does seem like a bug:
static struct syscall_helper_data shm_syscalls[] = {
SYSCALL_INIT_HELPER(shmat),
SYSCALL_INIT_HELPER(shmctl),
SYSCALL_INIT_HELPER(shmdt),
SYSCALL_INIT_HELPER(shmget),
#if defined(COMPAT_FREEBSD4) || defined(COMPAT_FREEBSD5) || \
defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD7)
SYSCALL_INIT_HELPER(freebsd7_shmctl),
#endif
The check should be for COMPAT_FREEBSD7 only I would think.
Apart from that, everything else should work without it I would think.
Thanks,
-Garrett
___
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 Mon, Mar 2, 2009 at 3:32 PM, Andrew Reilly andrew-free...@areilly.bpc-users.org wrote: On Mon, Mar 02, 2009 at 01:25:22PM -0700, M. Warner Losh wrote: In message: 2fd864e0903020512i22b2c31fg487aaf37fed63...@mail.gmail.com Astrodog astro...@gmail.com writes: : As unfortunate (and annoying) as that delay was, your system was in a : defined state, at the end of rc.d. As things stand now, that doesn't : appear to be the case anymore, and I think that may be a more : significant issue than the delay. I'd be happy with synchronous dhcp. The more general problem is the (large) number of network applications that assume that network addresses and routes never change (because that's how things were when they were written.) My personal pet peeve is ntpd, but there are many others. Any daemon that caches host IP address information at startup is (IMO) broken, and needs to be fixed. There are many reasons why network addresses may change *after* startup, and it is not reasonable to go around and manually HUP everything when that happens. Needing synchronous DHCP as a work-around here is just the signifier of the problem: it isn't the over-all solution. I completely and wholeheartedly agree with you. This could be more difficult with contributed software, but it can be done! Thanks =], -Garrett ___ 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
ums no longer loads on CURRENT
Recently built kernel as of today around 4pm. The mouse is available on the console and moused isn't running; this issue prevents me from using X11. I'm looking for all libraries linked against libusb-0.1.so. 8 right now... More details: [r...@orangebox /usr/home/gcooper]# kldload ums module_register: module ushub/ums already exists! Module ushub/ums failed to register: 17 kldload: can't load ums: File exists [r...@orangebox /usr/home/gcooper]# cat /root/ORANGEBOX-common /root/ ORANGEBOX # START COMMON INCLUDE FILE cpu I686_CPU ident ORANGEBOX # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking #optionsINET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options NTFS# NT File System options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_BSD options GEOM_MBR options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options STOP_NMI# Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) # Debugging for use in -current options KDB # Enable kernel debugger support. options KDB_UNATTENDED # I don't want to be here when shit crashes.. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #optionsWITNESS # Enable checks to detect deadlocks and cycles #optionsWITNESS_SKIPSPIN# Don't run witness on spinlocks for speed options COMPAT_LINUX # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel device apic # CPU frequency control device cpufreq # Bus support. device acpi device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicam# Required for [C|DV]D burning #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks)
Re: ums no longer loads on CURRENT
On Mar 1, 2009, at 7:20 PM, Garrett Cooper wrote: On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: Garrett Cooper wrote: deviceums# Mouse This is why you cannot kldload. Not sure about any functional regression. Sam Yeah, well that message was printed out by another process altogether while loading up the kernel after the ata subsystem was brought up, so something's getting confused and trying to kldload by accident... I was just reproducing the message. I'll provide more data to prove this claim when I can. Thanks, -Garrett Here's the picture from my iPhone: http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=viewcurrent=IMG_0032.png . I OBVIOUSLY didn't do the kldload... and because my /boot/ loader.conf doesn't contain ums_load=YES, I'm really curious who the actual culprit is in rc.d land... I used to do WITHOUT_MODULES=* to not build modules, but I'm trying to move away from that mentality for some things like snd_emu10kx, but obviously there's a conflict somewhere for ums; hopefully it's merely cosmetic... Thanks, -Garrett ___ 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
The rc.d mess strikes back (was Re: ums no longer loads on CURRENT)
On Mar 1, 2009, at 7:36 PM, Garrett Cooper wrote: On Mar 1, 2009, at 7:20 PM, Garrett Cooper wrote: On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: Garrett Cooper wrote: deviceums# Mouse This is why you cannot kldload. Not sure about any functional regression. Sam Yeah, well that message was printed out by another process altogether while loading up the kernel after the ata subsystem was brought up, so something's getting confused and trying to kldload by accident... I was just reproducing the message. I'll provide more data to prove this claim when I can. Thanks, -Garrett Here's the picture from my iPhone: http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=viewcurrent=IMG_0032.png . I OBVIOUSLY didn't do the kldload... and because my /boot/ loader.conf doesn't contain ums_load=YES, I'm really curious who the actual culprit is in rc.d land... I used to do WITHOUT_MODULES=* to not build modules, but I'm trying to move away from that mentality for some things like snd_emu10kx, but obviously there's a conflict somewhere for ums; hopefully it's merely cosmetic... Thanks, -Garrett Ok, found the culprit. It turns out moused is being called from devd... this is all probably related to the startup mess I reported 2 weeks ago with my NIC. I'm seeing a lot of additional problems in terms of keeping track of daemons; for instance syslogd is getting started up twice, but the first instance isn't recording a PID and the second one is dying because the first one is bound to the address. Agh... Could we just unwind this rc.d mess? It seems to be causing issues and wasn't very thoroughly tested before commit. Thanks, -Garrett ___ 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: ums no longer loads on CURRENT
On Mar 1, 2009, at 6:44 PM, M. Warner Losh wrote: In message: cb26d07a-6d29-4b53-b3f1-cd1cab8af...@gmail.com Garrett Cooper yanef...@gmail.com writes: : Recently built kernel as of today around 4pm. The mouse is available : on the console and moused isn't running; this issue prevents me from : using X11. I'm looking for all libraries linked against libusb-0.1.so. : 8 right now... Did you read updating? Yes, I did. The only problem is that I can't find anything linked against that library; then again my one-liner was probably screwed up so I'll check again later. I'll applied the libmap.conf suggestion and that solved that issue. Yet I've unhappily uncovered something else that needs to be solved with rc.d :(... Since I started up this thread, I'll be more than happy to note what apps I encounter that need to be rebuilt so it can be further documented in UPDATING. Thanks, -Garrett ___ 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 Mar 1, 2009, at 7:50 PM, M. Warner Losh wrote: In message: e39d3873-3f36-467a-b225-347a088b6...@gmail.com Garrett Cooper yanef...@gmail.com writes: : On Mar 1, 2009, at 7:36 PM, Garrett Cooper wrote: : : On Mar 1, 2009, at 7:20 PM, Garrett Cooper wrote: : : On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: : : Garrett Cooper wrote: : deviceums# Mouse : : This is why you cannot kldload. Not sure about any functional : regression. : : Sam : : Yeah, well that message was printed out by another process : altogether while loading up the kernel after the ata subsystem was : brought up, so something's getting confused and trying to kldload : by accident... I was just reproducing the message. : I'll provide more data to prove this claim when I can. : Thanks, : -Garrett : : Here's the picture from my iPhone: http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=viewcurrent=IMG_0032.png : . I OBVIOUSLY didn't do the kldload... and because my /boot/ : loader.conf doesn't contain ums_load=YES, I'm really curious who : the actual culprit is in rc.d land... : I used to do WITHOUT_MODULES=* to not build modules, but I'm trying : to move away from that mentality for some things like snd_emu10kx, : but obviously there's a conflict somewhere for ums; hopefully it's : merely cosmetic... : Thanks, : -Garrett : : Ok, found the culprit. It turns out moused is being called from : devd... this is all probably related to the startup mess I reported 2 : weeks ago with my NIC. I'm seeing a lot of additional problems in : terms of keeping track of daemons; for instance syslogd is getting : started up twice, but the first instance isn't recording a PID and the : second one is dying because the first one is bound to the address. : Agh... I didn't think that moused loaded anything. And what do extra nics have to do with this? I think you are confusing multiple problems... : Could we just unwind this rc.d mess? It seems to be causing issues : and wasn't very thoroughly tested before commit. This is a little to vague to be actionable. Do you have specific instances? Do you have rcorder output? Etc... Warner For whatever reason the NFS filemounts not coming up forces rc.d to restart from a square one (because it enters maintenance mode), which nukes PID files in /var/run (I'm assuming) via the cleanvar service, and causes devd and syslogd to be started twice, which in turn causes that message to be printed out on the console. devd's rc script is just smart enough to recognize that there's a PID already running on the system, and thus it doesn't try to start more than once, but syslogd's is braindead (is there really a point to running multiple instances of syslogd?) and thus it tries to start up the service twice. I'm understand why devd attempts to probe and install ums in the kernel's namespace if it already exists... but I'm unhappy with the fact that even though I set moused_enable=NO in rc.conf, moused still doesn't honor that option ;(... -Garrett ___ 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: ums no longer loads on CURRENT
On Sun, Mar 1, 2009 at 7:58 PM, Garrett Cooper yanef...@gmail.com wrote: On Mar 1, 2009, at 6:44 PM, M. Warner Losh wrote: In message: cb26d07a-6d29-4b53-b3f1-cd1cab8af...@gmail.com Garrett Cooper yanef...@gmail.com writes: : Recently built kernel as of today around 4pm. The mouse is available : on the console and moused isn't running; this issue prevents me from : using X11. I'm looking for all libraries linked against libusb-0.1.so. : 8 right now... Did you read updating? Yes, I did. The only problem is that I can't find anything linked against that library; then again my one-liner was probably screwed up so I'll check again later. I'll applied the libmap.conf suggestion and that solved that issue. Yet I've unhappily uncovered something else that needs to be solved with rc.d :(... Since I started up this thread, I'll be more than happy to note what apps I encounter that need to be rebuilt so it can be further documented in UPDATING. Thanks, -Garrett I think I've tied down the issue in part with hal, etc. I have perforce installed on the system, along with nvidia-kernel, which means that I need misc/compat-5x. Unfortunately compat-5x installs libusbhid.so.1, which no doubt conflicts with the installed copy we have in /usr/lib, but through the glorious thing known as autoconf with ports, I believe it's picking up the copy in /usr/local/lib/compat/... I could be wrong though. Thoughts? Thanks, -Garrett ___ 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: ums no longer loads on CURRENT
On Sun, Mar 1, 2009 at 8:30 PM, Andrew Thompson thom...@freebsd.org wrote: On Sun, Mar 01, 2009 at 07:20:03PM -0800, Garrett Cooper wrote: On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: Garrett Cooper wrote: device ums # Mouse This is why you cannot kldload. Not sure about any functional regression. Sam Yeah, well that message was printed out by another process altogether while loading up the kernel after the ata subsystem was brought up, so something's getting confused and trying to kldload by accident... I was just reproducing the message. I'll provide more data to prove this claim when I can. I have traced this already but not looked into why, the process trying to (re)load ums is moused. Andrew It's being done from devd's end, but I'd really like it if the terse messaging would go away because it confused the heck out of me... the issue was ABI/libmap.conf related like Warner put down in UPDATING, but I instead opened up another can of worms ;(... Thanks, -Garrett ___ 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 Mar 1, 2009, at 9:18 PM, Boris Kochergin wrote: Garrett Cooper wrote: On Mar 1, 2009, at 7:50 PM, M. Warner Losh wrote: In message: e39d3873-3f36-467a-b225-347a088b6...@gmail.com Garrett Cooper yanef...@gmail.com writes: : On Mar 1, 2009, at 7:36 PM, Garrett Cooper wrote: : : On Mar 1, 2009, at 7:20 PM, Garrett Cooper wrote: : : On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: : : Garrett Cooper wrote: : deviceums# Mouse : : This is why you cannot kldload. Not sure about any functional : regression. : : Sam : : Yeah, well that message was printed out by another process : altogether while loading up the kernel after the ata subsystem was : brought up, so something's getting confused and trying to kldload : by accident... I was just reproducing the message. : I'll provide more data to prove this claim when I can. : Thanks, : -Garrett : : Here's the picture from my iPhone: http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=viewcurrent=IMG_0032.png : . I OBVIOUSLY didn't do the kldload... and because my /boot/ : loader.conf doesn't contain ums_load=YES, I'm really curious who : the actual culprit is in rc.d land... : I used to do WITHOUT_MODULES=* to not build modules, but I'm trying : to move away from that mentality for some things like snd_emu10kx, : but obviously there's a conflict somewhere for ums; hopefully it's : merely cosmetic... : Thanks, : -Garrett : : Ok, found the culprit. It turns out moused is being called from : devd... this is all probably related to the startup mess I reported 2 : weeks ago with my NIC. I'm seeing a lot of additional problems in : terms of keeping track of daemons; for instance syslogd is getting : started up twice, but the first instance isn't recording a PID and the : second one is dying because the first one is bound to the address. : Agh... I didn't think that moused loaded anything. And what do extra nics have to do with this? I think you are confusing multiple problems... : Could we just unwind this rc.d mess? It seems to be causing issues : and wasn't very thoroughly tested before commit. This is a little to vague to be actionable. Do you have specific instances? Do you have rcorder output? Etc... Warner For whatever reason the NFS filemounts not coming up forces rc.d to restart from a square one (because it enters maintenance mode), which nukes PID files in /var/run (I'm assuming) via the cleanvar service, and causes devd and syslogd to be started twice, which in turn causes that message to be printed out on the console. devd's rc script is just smart enough to recognize that there's a PID already running on the system, and thus it doesn't try to start more than once, but syslogd's is braindead (is there really a point to running multiple instances of syslogd?) and thus it tries to start up the service twice. I'm understand why devd attempts to probe and install ums in the kernel's namespace if it already exists... but I'm unhappy with the fact that even though I set moused_enable=NO in rc.conf, moused still doesn't honor that option ;(... -Garrett With regard to NFS breaking your boot process, I have run into the same thing recently, but it was my fault. Your screenshot omits the potentially-interesting information, if the problem is the same. In my case, /etc/rc.d/* was out of sync with /etc/network.subr. /etc/ rc.d/netif, which handles the ifconfig_* lines in rc.conf, has references to an ifn_start() function in /etc/network.subr, so interfaces configured in rc.conf never came up. -Boris Thanks for the reminder to upload the other images here they are in their verbose glory: http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=viewcurrent=IMG_0033.jpg http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=viewcurrent=IMG_0034.jpg And the interesting sections of my rc.conf: ifconfig_msk0=DHCP defaultrouter=192.168.10.1 hostname=orangebox.gateway.2wire.net nfs_client_enable=YES ntpdate_enable=YES ntpdate_flags=ntp.ucsd.edu rpcbind_enable=YES synchronous_dhclient=YES So the issue is again not with my interface, but the fact that registering dhcp sucks with my router (it's a lame 2wire hunk of ATT junk), and it takes a while to register properly (5~10 seconds), and by the time the NFS mount line is reached, it's only been 2~3 seconds... I realize the motivation for not having runlevels like Linux, but there should something such that mounting NFS filesystems doesn't cause rc to start from scratch because it's entirely unnecessary and it breaks a lot of assumptions with rc... HTH, -Garrett ___ 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: Future of udbp in USB2?
On Mon, Feb 9, 2009 at 12:16 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Monday 09 February 2009, Garrett Cooper wrote: Hi Hans, I was just preparing to test out the usb2 changes and I noted that one option in my old kernel configfile didn't have an analog in the USB2 config file: udbp. I don't use the option, but I was just checking to see whether or not an analog does exist, or the support will be completely phased out when USB2 becomes the default for FreeBSD. Thanks, -Garrett Hi, The udbp module is now called misc_dbp and it still connects via netgraph. Other similar devices just emulate USB ethernet devices. --HPS Ok... is that going to be documented in the release notes for the new functionality? -Garrett ___ 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
Future of udbp in USB2?
Hi Hans, I was just preparing to test out the usb2 changes and I noted that one option in my old kernel configfile didn't have an analog in the USB2 config file: udbp. I don't use the option, but I was just checking to see whether or not an analog does exist, or the support will be completely phased out when USB2 becomes the default for FreeBSD. Thanks, -Garrett ___ 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: HEADSUP usb2/usb4bsd to become default in GENERIC
On Sun, Feb 8, 2009 at 7:17 PM, Maksim Yevmenkin maksim.yevmen...@gmail.com wrote: On Sun, Feb 8, 2009 at 11:12 AM, Sam Leffler s...@freebsd.org wrote: [...] - Update GENERIC to use usb2 device names. Wasn't there a plan to rename usb2 devices to match oldusb names (where applicable) once oldusb had been killed? I don't see it in the list. Probably, although coming from the other side as a user I find it pretty annoying when there's somewhat gratuitous changes to the kernel config files that I don't really care about that cause my kernels to break. The vast majority of our users do not run -CURRENT, and so haven't had to change config files yet. One day, those users will be migrating from 7.x to 8.x, and shouldn't need to change their kernel config for a somewhat gratuitous change. Your argument only works if people had already had to change their config files once (usb - usb2), and that by renaming these back they will have to change their kernel config back. Only people running -CURRENT will end up having to do this twice (or indeed at all) if the rename takes place, end users will not need to do it at all. Basically, calling it usb2 isn't as bad as renaming it back to usb as it's less disruptive in my book. Again, I disagree. I agree with your comments. And, as I've said previously, any name changes from usb1 will require _all_ documentation (manual pages, handbook, etc) to change; not a good idea. i second that. i would really like to see old module names to be preserved as much as possible. thanks, max In some cases I find the new module names to be more intuitive (uplcom - usb2_serial_plcom), but I find having to add the additional modules required for USB4BSD (usb2_core, etc) to be a bit more annoying. Also, there's an issue with the example USB2 kernel config -- you need to have double-quotes around the include file otherwise config says `syntax error' and pukes. Thanks, -Garrett ___ 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: bin/129963: [newusb] usbconfig(8) fails with misleading error when run as a normal user
On Tue, Jan 6, 2009 at 10:32 AM, Hans Petter Selasky hsela...@c2i.net wrote:
On Saturday 03 January 2009, Volker wrote:
On 01/03/09 01:35, Hans Petter Selasky wrote:
On Wednesday 31 December 2008, v...@freebsd.org wrote:
Synopsis: [newusb] usbconfig(8) fails with misleading error when run as
a normal user
Responsible-Changed-From-To: freebsd-bugs-freebsd-usb
Responsible-Changed-By: vwe
Responsible-Changed-When: Wed Dec 31 12:55:52 UTC 2008
Responsible-Changed-Why:
reassign
http://www.freebsd.org/cgi/query-pr.cgi?pr=129963
Hi,
usbconfig will only show USB devices which the user has access to.
What should be the correct display message when no devices are accessible
due to innsufficient permissions?
--HPS
Hans,
what about access denied or insufficient privileges?
Someone might have a better idea but everything should be better than
silently refusing to do anything.
Volker
Is this Ok:
http://perforce.freebsd.org/chv.cgi?CH=155731
--HPS
Eh? I still think that strerror or something along those lines would
be more helpful.
You could also do
if (getuid() != 0) {
errx(1, Cluebat -- you might not be able to read the usb devices
if you're not root);
}
or...
struct stat usb_s;
int fd = open(..., O_RDONLY /* blah, blah... */);
if (fd == -1) {
errx(1, Does the file -- %s -- exist?, file);
}
if (fstat(fd, usb_s) == -1) {
errx(1, Couldn't stat the file: %s, file);
}
if (!S_IRUSR(usb_s.st_mode) !S_IRGRP(usb_s.st_mode)
!S_IROTH(usb_s.st_mode)) {
errx(1, File not readable (do you have read permissions?));
}
/* Continue on merry way reading devices; maybe use strerror(3) for
more intuitive error messages? */
Thoughts?
-Garrett
___
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: bin/129963: [newusb] usbconfig(8) fails with misleading error when run as a normal user
On Tue, Jan 6, 2009 at 11:15 AM, M. Warner Losh i...@bsdimp.com wrote:
In message: 7d6fde3d0901061110r79333a07jf4eb134224a94...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Tue, Jan 6, 2009 at 10:32 AM, Hans Petter Selasky hsela...@c2i.net
wrote:
: On Saturday 03 January 2009, Volker wrote:
: On 01/03/09 01:35, Hans Petter Selasky wrote:
: On Wednesday 31 December 2008, v...@freebsd.org wrote:
: Synopsis: [newusb] usbconfig(8) fails with misleading error when run
as
: a normal user
:
: Responsible-Changed-From-To: freebsd-bugs-freebsd-usb
: Responsible-Changed-By: vwe
: Responsible-Changed-When: Wed Dec 31 12:55:52 UTC 2008
: Responsible-Changed-Why:
: reassign
:
: http://www.freebsd.org/cgi/query-pr.cgi?pr=129963
:
: Hi,
:
: usbconfig will only show USB devices which the user has access to.
:
: What should be the correct display message when no devices are
accessible
: due to innsufficient permissions?
:
: --HPS
:
: Hans,
:
: what about access denied or insufficient privileges?
:
: Someone might have a better idea but everything should be better than
: silently refusing to do anything.
:
: Volker
:
: Is this Ok:
:
: http://perforce.freebsd.org/chv.cgi?CH=155731
:
: --HPS
:
: Eh? I still think that strerror or something along those lines would
: be more helpful.
:
: You could also do
:
: if (getuid() != 0) {
: errx(1, Cluebat -- you might not be able to read the usb devices
: if you're not root);
: }
:
: or...
:
: struct stat usb_s;
:
: int fd = open(..., O_RDONLY /* blah, blah... */);
:
: if (fd == -1) {
: errx(1, Does the file -- %s -- exist?, file);
: }
:
: if (fstat(fd, usb_s) == -1) {
: errx(1, Couldn't stat the file: %s, file);
: }
:
: if (!S_IRUSR(usb_s.st_mode) !S_IRGRP(usb_s.st_mode)
: !S_IROTH(usb_s.st_mode)) {
: errx(1, File not readable (do you have read permissions?));
: }
:
: /* Continue on merry way reading devices; maybe use strerror(3) for
: more intuitive error messages? */
:
: Thoughts?
Do you really have to be root to find the devices, if so, that's bad.
Very bad. xsane refuses to run as root. I have:
[localrules=10]
add path 'uscanner*' mode 0660
to make it work. /dev/usb* in old usb allow listing w/o privs...
Warner
Hence that's why I provided another hacked solution. I hate `can't
run this app unless root' because it doesn't accurately solve the
problem, but it makes the issue more straightforward than `no devices'
:).
Personally I think using errno and strerror when trying to open /
read devices would be a lot cleaner. Let me see what I can quickly
grok from libusb(3) either tonight or tomorrow that might be an
improvement..
-Garrett
___
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: bin/129963: [newusb] usbconfig(8) fails with misleading error when run as a normal user
On Sat, Jan 3, 2009 at 10:35 AM, Volker vol...@vwsoft.com wrote: On 01/03/09 01:35, Hans Petter Selasky wrote: On Wednesday 31 December 2008, v...@freebsd.org wrote: Synopsis: [newusb] usbconfig(8) fails with misleading error when run as a normal user Responsible-Changed-From-To: freebsd-bugs-freebsd-usb Responsible-Changed-By: vwe Responsible-Changed-When: Wed Dec 31 12:55:52 UTC 2008 Responsible-Changed-Why: reassign http://www.freebsd.org/cgi/query-pr.cgi?pr=129963 Hi, usbconfig will only show USB devices which the user has access to. What should be the correct display message when no devices are accessible due to innsufficient permissions? --HPS Hans, what about access denied or insufficient privileges? Someone might have a better idea but everything should be better than silently refusing to do anything. Volker Why not just simplify the problem by printing out the strerror(3) message for the actual issue -- or was that the misleading error message? Cheers, -Garrett ___ 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
