Re: Low perfomance when read from usb flash drive

[Artyom Mirgorodsky]

7.1 livefs test result:

 dd if=/dev/da0 of=/dev/null bs=65536
 19534+0 records in
 19534+0 records out
 1280180224 bytes transferred in 64.897932 secs (197263329 bytes/sec)
 
 systat -vm
 
 Disksda0
 KB/t64.00
 tps  301
 MB/s   18.84
 %busy 99
 
___
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: Low perfomance when read from usb flash drive

[Hans Petter Selasky]

On Sunday 01 March 2009, Artyom Mirgorodsky wrote:
> 7.1 livefs test result:
>
>  dd if=/dev/da0 of=/dev/null bs=65536
>  19534+0 records in
>  19534+0 records out
>  1280180224 bytes transferred in 64.897932 secs (197263329 bytes/sec)
>

Hi,

It might be a bug with your memory stick. Are your findings consistent accross 
other brands of memory sticks aswell, between 7.1 and 8.x ?

--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: USB2+umass: root mount fails

[Andrew Thompson]

On Mon, Feb 16, 2009 at 01:53:36PM -0800, Marcel Moolenaar wrote:
> It appears that the root mount isn't serialized with USB discovery
> in the same way it was under USB1.

It seems that this is not completly resolved with the root mount hold in
r188907 as geom may not have tasted the partition tables when
vfs_rootmount is woken. USB still needs to finish its bus probe earlier
on the boot process.

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: USB2+umass: root mount fails

[M. Warner Losh]

In message: <20090301190057.gd90...@citylink.fud.org.nz>
Andrew Thompson  writes:
: On Mon, Feb 16, 2009 at 01:53:36PM -0800, Marcel Moolenaar wrote:
: > It appears that the root mount isn't serialized with USB discovery
: > in the same way it was under USB1.
: 
: It seems that this is not completly resolved with the root mount hold in
: r188907 as geom may not have tasted the partition tables when
: vfs_rootmount is woken. USB still needs to finish its bus probe earlier
: on the boot process.

This sounds like a more fundamental ordering problem.  It sounds like
we need two gates here.  (1) All the underlying devices are there and
(2) All tasting is done.

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: USB2+umass: root mount fails

[Andrew Thompson]

On Sun, Mar 01, 2009 at 12:16:20PM -0700, M. Warner Losh wrote:
> In message: <20090301190057.gd90...@citylink.fud.org.nz>
> Andrew Thompson  writes:
> : On Mon, Feb 16, 2009 at 01:53:36PM -0800, Marcel Moolenaar wrote:
> : > It appears that the root mount isn't serialized with USB discovery
> : > in the same way it was under USB1.
> : 
> : It seems that this is not completly resolved with the root mount hold in
> : r188907 as geom may not have tasted the partition tables when
> : vfs_rootmount is woken. USB still needs to finish its bus probe earlier
> : on the boot process.
> 
> This sounds like a more fundamental ordering problem.  It sounds like
> we need two gates here.  (1) All the underlying devices are there and
> (2) All tasting is done.

So should another root hold token be grabbed in disk_create() and
released on taste?

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"

axe usb network adapter problems

[Agnius]

I have http://www.a-link.com/uk/NA1GU.html?id=dr7bZGZG
OS FreeBSD 7.1
When I use axe.88178.patch4 adapter begin work

axe0: 
on uhub3
axe0: AX88178, bufsz 1536, boundary 64
axe0: PHYADDR 0xe0:0x18
miibus0:  on axe0
ciphy0:  PHY 24 on miibus0
ciphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
axe0: WARNING: using obsoleted if_watchdog interface
axe0: WARNING: using obsoleted IFF_NEEDSGIANT flag
axe0: Ethernet address: 00:1a:9f:0b:02:ea

But I found problems:

1. I can not use TX and RX

2. Many errors:
 netstat -i
NameMtu Network   Address IpktsIerrsOpkts  
Oerrs  Coll
axe0   1500   00:1a:9f:0b:02:ea   996093 15890   701185 0  
0

3. Max speed ~4000 kbytes/s

-- 
View this message in context: 
http://www.nabble.com/axe-usb-network-adapter-problems-tp22277434p22277434.html
Sent from the freebsd-usb mailing list archive at Nabble.com.

___
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

[Garrett Cooper]

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

[M. Warner Losh]

In message: 
Garrett Cooper  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?

Warner

: 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
: #options  INET6   # 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
: #options  WITNESS # Enable checks to detect deadlocks and 
cycles
: #options  WITNESS_SKIPSPIN# Don't run witness on spinlocks for 
speed
: options   COMPAT_LINUX
: 
: # Make an SMP-capable kernel by default
: options   SMP # Symmetric MultiProcessor Kernel
: 
: deviceapic
: 
: # CPU frequency control
: devicecpufreq
: 
: # Bus support.
: deviceacpi
: devicepci
: 
: # ATA and ATAPI devices
: deviceata
: deviceatadisk # ATA disk drives
: deviceatapicam# Required for [C|DV]D burning
: #device   ataraid # ATA RAID drives
: deviceatapicd # ATAPI CDROM drives
: #device   atapist

Re: ums no longer loads on CURRENT

[Garrett Cooper]

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
___
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

[Garrett Cooper]

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: . 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)

[Garrett Cooper]

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: . 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: The rc.d mess strikes back

[M. Warner Losh]

In message: 
Garrett Cooper  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: 
 >. 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
___
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

[Garrett Cooper]

On Mar 1, 2009, at 6:44 PM, M. Warner Losh wrote:


In message: 
   Garrett Cooper  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

[Garrett Cooper]

On Mar 1, 2009, at 7:50 PM, M. Warner Losh wrote:


In message: 
   Garrett Cooper  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: 
 >. 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: The rc.d mess strikes back

[Sam Leffler]

M. Warner Losh wrote:

In message: 
Garrett Cooper  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:  >. 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...
  

I saw a similar problem today; if I have a wireless nic setup with

ifconfig_ath0="wlan0"
ifconfig_wlan0="WPA DHCP"

then two instances of wpa_supplicant are launched when I do

/etc/rc.d/netif start ath0

(you get log msgs from wpa_supplicant about not being able to setup the 
/var/run/wpa_supplicant/wlan0 unix domain socket).  Wasn't able to pin 
it down but it's likely the same issue.


   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"

Re: ums no longer loads on CURRENT

[Garrett Cooper]

On Sun, Mar 1, 2009 at 7:58 PM, Garrett Cooper  wrote:
> On Mar 1, 2009, at 6:44 PM, M. Warner Losh wrote:
>
>> In message: 
>>           Garrett Cooper  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

[Andrew Thompson]

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

I have traced this already but not looked into why, the process trying
to (re)load ums is moused.


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: ums no longer loads on CURRENT

[Garrett Cooper]

On Sun, Mar 1, 2009 at 8:30 PM, Andrew Thompson  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: ums no longer loads on CURRENT

[Andrew Thompson]

On Sun, Mar 01, 2009 at 08:41:35PM -0800, Garrett Cooper wrote:
> On Sun, Mar 1, 2009 at 8:30 PM, Andrew Thompson  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,

A quick look found it,

static int
usbmodule(void)
{
return (kld_isloaded("uhub/ums") || kld_load("ums") != -1);
}

its now called ushub/ums. It can probably be renamed back to uhub now.


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: The rc.d mess strikes back

[Garrett Cooper]

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: 
  Garrett Cooper  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: 
 >. 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=view¤t=IMG_0033.jpg
http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=view¤t=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 AT&T  
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: ums no longer loads on CURRENT

[Andrew Thompson]

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

The warning should be gone in r189275 (tested locally).


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: The rc.d mess strikes back

[Boris Kochergin]

Garrett Cooper wrote:

On Mar 1, 2009, at 7:50 PM, M. Warner Losh wrote:


In message: 
   Garrett Cooper  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: 
 >. 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-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"
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
___
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"