Re: process in STOP state

[Tijl Coosemans]

On Wednesday 13 January 2010 15:36:49 Kostik Belousov wrote:
> On Wed, Jan 13, 2010 at 08:03:12AM -0500, Gardner Bell wrote:
>> Kostik Belousov wrote:
>>> On Tue, Jan 12, 2010 at 06:15:31PM -0500, Gardner Bell wrote:
 Just updated my 8.0-STABLE desktop to r202128 the other day and
 can no longer run certain windows executables through wine without
 them almost immediately entering the STOP state and using 100% CPU
 for a short period of time.  Has anyone else ran into a similar
 issue lately?
 
 I'm able to get the program to continue as normal by attaching the
 pid trough gdb, but would for obvious reasons prefer not to do
 that.  Any help trying to find the underlying cause would be
 appreciated as this has not been a problem with revisions previous
 to r202128.
>>> 
>>> You can check whether the process is multithreaded (most likely, it
>>> is), and, if so, what is the state of different threads. procstat
>>> -t  and then procstat -k  would probably give some
>>> information for the start.
>> 
>> Here's the output from procstat -k and -t.  I've compiled my kernel
>> with KDB and DDB support if there is anything needed from that.
>> 
>>   PIDTID COMM TDNAME   CPU  PRI STATE   WCHAN
>> 44900 100162 wine initial thread 1  160 stop-
>> 44900 100178 wine -  1  131 stop-
>> 44900 100179 wine -  1  140 stop-
>> 44900 100180 wine -  0  160 stoppiperd
>> 44900 100182 wine -  1  160 stopselect
>> 44900 100183 wine -  0  160 stop-
>> 44900 100184 wine -  0  160 stop-
>> 44900 100185 wine -  1  160 stop-
>> 44900 100186 wine -  0  160 stop-
>> 44900 100190 wine -  0  160 stop-
>> 44900 100191 wine -  0  160 stoppiperd
>> 44900 100192 wine -  1  160 stop-
>> 44900 100194 wine -  0  160 stop-
>> 44900 100195 wine -  0  141 stoppiperd
>> 44900 100200 wine -  1  160 stop-
>> 44900 100201 wine -  1  160 stop-
>> 44900 100202 wine -  0  160 stoppiperd
>> 44900 100203 wine -  1  160 stoppiperd
>> 44900 100204 wine -  1  160 stoppiperd
>> 44900 100205 wine -  0  160 stop-
>> 44900 100206 wine -  0  160 stop-
>> 
>> %procstat -k 44900
>>   PIDTID COMM TDNAME   KSTACK 
>> 
>> 44900 100162 wine initial thread   mi_switch 
>> thread_suspend_check as 
>>  t doreti_ast
>> 44900 100178 wine -mi_switch sleepq_switch 
>> sleepq_ca 
>>tch_signals sleepq_timedwait_sig 
>> _cv_timedwait_sig seltdwait kern_select select 
>> 
>>   syscall Xint0x80_syscall
>> 44900 100179 wine -mi_switch sleepq_switch 
>> sleepq_ca 
>>tch_signals sleepq_timedwait_sig 
>> _cv_timedwait_sig seltdwait kern_select select 
>> 
>>   syscall Xint0x80_syscall
>> 44900 100180 wine -mi_switch sleepq_switch 
>> sleepq_ca 
>>tch_signals sleepq_wait_sig 
>> _sleep pipe_read dofileread kern_readv read syscall 
>> 
>>Xint0x80_syscall
>> 44900 100182 wine -mi_switch sleepq_switch 
>> sleepq_ca 
>>tch_signals sleepq_wait_sig 
>> _cv_wait_sig seltdwait poll syscall Xint0x80_syscall 
>> 
>> 
>> 44900 100183 wine -mi_switch sleepq_switch 
>> sleepq_ca 
>>tch_signals sleepq_timedwait_sig 
>> _cv_timedwait_sig seltdwait poll syscall Xint0x 
>> 
>>   80_syscall
>> 44900 100184 wine -mi_switch sleepq_switch 
>> sleepq_ca 
>>tch_signals sleepq_timedwait_sig 
>> _cv_timedwait_sig seltdwait kern_select select 
>> 
>>   syscall Xint0x80_syscall
>> 44900 100185 wine -mi_switch sleepq_switch 
>> sleepq_ca 
>>tch_signals sleepq_timedwait_sig 
>> _cv_timedwait_sig seltdwait kern_select select 
>> 
>>   syscall Xint0x80_syscall
>> 44900 100186 wine -mi_switch sleepq_switch 
>> sleepq_ca 
>>tch_signals sleepq_timedwait_sig 
>> _cv_timedwait_sig seltdwait kern_select select 
>> 
>>   syscall Xint0x80_syscall
>> 44900 10

Re: [PATCH] Lockmgr deadlock on STABLE_8

[Pete French]

> http://www.freebsd.org/~attilio/lockmgr_fix8.diff
>
> I'm seeking for testers here.
> Any report would be very much appreciated.

I tested the patch on my machine which locks up, and I am afraid that it
still locks, even with the patch applied. The last things on the console
before the lock are.

1) A whole load of sshd errors for one of those flood attacks which try
multiple usersnames. This is not unusual, all my systems with an external
ssh port see this.

2) Four 'Watchdog timeout occurreed, resetting!" messages from if_bce.c.
These are new - without your patch I did not get these.

I have tried rnning this machine with WITNESS in the kernel, but it
will not deadlock then. Without WiTNESS it will lock up in about
twelve hours. I am going to try with just KDB and DDB to see if I can get
it into a state where we can get some useful information out of it.

I realsie, of course, that this might be utterly unrelated to the problem
your patch is trying to address!

cheers,

-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [PATCH] Lockmgr deadlock on STABLE_8

[Attilio Rao]

2010/1/14 Pete French :
>> http://www.freebsd.org/~attilio/lockmgr_fix8.diff
>>
>> I'm seeking for testers here.
>> Any report would be very much appreciated.
>
> I tested the patch on my machine which locks up, and I am afraid that it
> still locks, even with the patch applied. The last things on the console
> before the lock are.
>
> 1) A whole load of sshd errors for one of those flood attacks which try
> multiple usersnames. This is not unusual, all my systems with an external
> ssh port see this.
>
> 2) Four 'Watchdog timeout occurreed, resetting!" messages from if_bce.c.
> These are new - without your patch I did not get these.
>
> I have tried rnning this machine with WITNESS in the kernel, but it
> will not deadlock then. Without WiTNESS it will lock up in about
> twelve hours. I am going to try with just KDB and DDB to see if I can get
> it into a state where we can get some useful information out of it.

Also enable INVARIANTS.
While there (with my patch applied) please setup textdump in order to
report the following DDB commands (and once it deadlocks break in
DDB):
bt, show allpcpu, ps, alltrace, show alllocks

Try also to get a coredump (and if you can't report immediately to us
and try to not turn off the machine in order to apply following
instructions).

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [PATCH] Lockmgr deadlock on STABLE_8

[Pete French]

> Also enable INVARIANTS.

Including INVARIANTS stops my kernel from building. It
has been this way since 8.0 (this is why I only
had WITNESS compiled in). It fails with many many
errors like this:

/usr/src/sys/vm/vm_map.c:575: undefined reference to `_mtx_assert'

My kernel config file looks like this:

include GENERIC
ident   WITNESS

options KDB
options DDB
options WITNESS
options INVARIANTS


> While there (with my patch applied) please setup textdump in order to
> report the following DDB commands (and once it deadlocks break in
> DDB):
> bt, show allpcpu, ps, alltrace, show alllocks

Having read the manual page for textdump, I am not sure I
will be able to get a dump out of this machine, as it has no
swap configured (and no spare partition that I can
allocate for such a thing). I have tried using dumpon
to dump to a ZVOL, but it gives me an error saying
that it is not supported. Is there anything I can do
to remedy this ?

> Try also to get a coredump (and if you can't report immediately to us
> and try to not turn off the machine in order to apply following
> instructions).

That's fine - this machine is more or less dedicated as a
test ,machine for 8.0 right now. I can possibly dive you console
access to it fi required in fact, as I did this for Robert
once to sort out a problem with 7.0

I'll try running with the current KDB and DDB kernel until
I can figure out how to get a WITNESS/INVARIANTS one built,
and will let you know when that deadlocks.

cheers,

-pete.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [PATCH] Lockmgr deadlock on STABLE_8

[Thomas Backman]

On Jan 14, 2010, at 2:11 PM, Pete French wrote:

>> Also enable INVARIANTS.
> 
> Including INVARIANTS stops my kernel from building. It
> has been this way since 8.0 (this is why I only
> had WITNESS compiled in). It fails with many many
> errors like this:
> 
> /usr/src/sys/vm/vm_map.c:575: undefined reference to `_mtx_assert'
> 
> My kernel config file looks like this:
> 
>   include GENERIC
>   ident   WITNESS
> 
>   options KDB
>   options DDB
>   options WITNESS
>   options INVARIANTS
INVARIANTS requires INVARIANT_SUPPORT [sic] in the kernel config (see comments 
in GENERIC).

Regards,
Thomas___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [PATCH] Lockmgr deadlock on STABLE_8

[Pete French]

> INVARIANTS requires INVARIANT_SUPPORT [sic] in the kernel config (see 
> comments in GENERIC).

Ah, right, that would explain it. Thanks!

-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [PATCH] Lockmgr deadlock on STABLE_8

[Attilio Rao]

2010/1/14 Pete French :
>> INVARIANTS requires INVARIANT_SUPPORT [sic] in the kernel config (see 
>> comments in GENERIC).
>
> Ah, right, that would explain it. Thanks!

INVARIANT_SUPPORT is made mandatory in order to allow non-INVARIANT
kernel to be able to handle INVARIANT compiled modules.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: USB problems on 8.0-STABLE

[John Baldwin]

On Wednesday 13 January 2010 6:21:08 pm Frank wrote:
> On Wed, 13 Jan 2010, John Baldwin wrote:
> 
> > Same here.  I suspect the problem is in apcupsd.conf.  This is what I am
> > using:
> >
> > UPSCABLE usb
> > UPSTYPE usb
> > DEVICE
> 
> This is what I have in mine also.  Here's the whole thing:
> 
> UPSCABLE usb
> UPSTYPE usb
> LOCKFILE /var/spool/lock
> DEVICE
> UPSCLASS standalone
> UPSMODE disable
> NETSERVER on
> NISPORT 3551
> NETTIME 10

What does apctest say when you run it?

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: USB problems on 8.0-STABLE

[Steve Randall]

On Fri, 8 Jan 2010 17:47:55 -0500 (EST)
Frank  wrote:

> I am having problems with mouse, keyboard and APC UPS.  When attempting to 
> start apcupsd I get the following error:
> 
> Jan  8 17:42:06 Ace apcupsd[1606]: apcupsd FATAL ERROR in generic-usb.c at 
> line 636 Cannot find UPS device -- For a link to detailed USB trouble 
> shooting information, please see .
> Jan  8 17:42:06 Ace apcupsd[1606]: apcupsd error shutdown completed
> 
> In X, I must move the mouse to get anything to update.  For example, if I 
> type in an xterm nothing will display or happen until the mouse is moved. 
> This also happens using a browser or any other app.
> 
> # dmesg | grep usb 
> usbus0:  on ohci0 usbus1: EHCI version 1.0
> usbus1:  on ehci0
> usbus0: 12Mbps Full Speed USB v1.0
> usbus1: 480Mbps High Speed USB v2.0
> ugen0.1:  at usbus0
> uhub0:  on 
> usbus0
> ugen1.1:  at usbus1
> uhub1:  on 
> usbus1
> Root mount waiting for: usbus1
> Root mount waiting for: usbus1
> Root mount waiting for: usbus1
> Root mount waiting for: usbus1
> ugen0.2:  at usbus0
> ugen0.3:  at usbus0
> ums0:  addr 3> on usbus0
> ugen0.4:  at usbus0
> ukbd0:  on 
> usbus0
> 
> Ace /usr/ports # usbdevs -d -v
> usbdevs: no USB controllers found

A possibility occurs to me that I think nobody has yet mentioned. If
you still have the obsolete usbdevs command on your system, is it
possible you also still have the obsolete devel/libusb port installed?
It conflicts with the libusb in the base system, causing just the sorts
of problems you are experiencing.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: process in STOP state

[Gardner Bell]

Tijl Coosemans wrote:

On Wednesday 13 January 2010 15:36:49 Kostik Belousov wrote:

On Wed, Jan 13, 2010 at 08:03:12AM -0500, Gardner Bell wrote:

Kostik Belousov wrote:

On Tue, Jan 12, 2010 at 06:15:31PM -0500, Gardner Bell wrote:

Just updated my 8.0-STABLE desktop to r202128 the other day and
can no longer run certain windows executables through wine without
them almost immediately entering the STOP state and using 100% CPU
for a short period of time.  Has anyone else ran into a similar
issue lately?

I'm able to get the program to continue as normal by attaching the
pid trough gdb, but would for obvious reasons prefer not to do
that.  Any help trying to find the underlying cause would be
appreciated as this has not been a problem with revisions previous
to r202128.

You can check whether the process is multithreaded (most likely, it
is), and, if so, what is the state of different threads. procstat
-t  and then procstat -k  would probably give some
information for the start.

Here's the output from procstat -k and -t.  I've compiled my kernel
with KDB and DDB support if there is anything needed from that.

  PIDTID COMM TDNAME   CPU  PRI STATE   WCHAN
44900 100162 wine initial thread 1  160 stop-
44900 100178 wine -  1  131 stop-
44900 100179 wine -  1  140 stop-
44900 100180 wine -  0  160 stoppiperd
44900 100182 wine -  1  160 stopselect
44900 100183 wine -  0  160 stop-
44900 100184 wine -  0  160 stop-
44900 100185 wine -  1  160 stop-
44900 100186 wine -  0  160 stop-
44900 100190 wine -  0  160 stop-
44900 100191 wine -  0  160 stoppiperd
44900 100192 wine -  1  160 stop-
44900 100194 wine -  0  160 stop-
44900 100195 wine -  0  141 stoppiperd
44900 100200 wine -  1  160 stop-
44900 100201 wine -  1  160 stop-
44900 100202 wine -  0  160 stoppiperd
44900 100203 wine -  1  160 stoppiperd
44900 100204 wine -  1  160 stoppiperd
44900 100205 wine -  0  160 stop-
44900 100206 wine -  0  160 stop-

%procstat -k 44900
  PIDTID COMM TDNAME   KSTACK 

44900 100162 wine initial thread   mi_switch 
thread_suspend_check as 
 t doreti_ast
44900 100178 wine -mi_switch sleepq_switch 
sleepq_ca 
   tch_signals sleepq_timedwait_sig 
_cv_timedwait_sig seltdwait kern_select select 


  syscall Xint0x80_syscall
44900 100179 wine -mi_switch sleepq_switch 
sleepq_ca 
   tch_signals sleepq_timedwait_sig 
_cv_timedwait_sig seltdwait kern_select select 


  syscall Xint0x80_syscall
44900 100180 wine -mi_switch sleepq_switch 
sleepq_ca 
   tch_signals sleepq_wait_sig 
_sleep pipe_read dofileread kern_readv read syscall 


   Xint0x80_syscall
44900 100182 wine -mi_switch sleepq_switch 
sleepq_ca 
   tch_signals sleepq_wait_sig 
_cv_wait_sig seltdwait poll syscall Xint0x80_syscall 



44900 100183 wine -mi_switch sleepq_switch 
sleepq_ca 
   tch_signals sleepq_timedwait_sig 
_cv_timedwait_sig seltdwait poll syscall Xint0x 


  80_syscall
44900 100184 wine -mi_switch sleepq_switch 
sleepq_ca 
   tch_signals sleepq_timedwait_sig 
_cv_timedwait_sig seltdwait kern_select select 


  syscall Xint0x80_syscall
44900 100185 wine -mi_switch sleepq_switch 
sleepq_ca 
   tch_signals sleepq_timedwait_sig 
_cv_timedwait_sig seltdwait kern_select select 


  syscall Xint0x80_syscall
44900 100186 wine -mi_switch sleepq_switch 
sleepq_ca 
   tch_signals sleepq_timedwait_sig 
_cv_timedwait_sig seltdwait kern_select select 


  syscall Xint0x80_syscall
44900 100190 wine -mi_switch sleepq_switch 
sleepq_ca 
   tch_signals sleepq_timedwait_sig 
_cv_timedwait_sig seltdwait kern_select select 


  syscall Xint0x80_syscall
44900 100191 wine -mi_switch sleepq_s

problem install linux base f10

[Martin Smith]

8.0 stable freshly installed and updated, am trying to install linux 
base f10 and getting the following error

sysctrl: unknown oid 'compat.linux.osrelease'
linuxulator is not (kld)loaded, exiting
pkg_add: install script returned error status

is there some work around for this? cheers
--
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: problem install linux base f10

[Scot Hetzel]

On Thu, Jan 14, 2010 at 10:52 AM, Martin Smith  wrote:
> 8.0 stable freshly installed and updated, am trying to install linux base
> f10 and getting the following error
> sysctrl: unknown oid 'compat.linux.osrelease'
> linuxulator is not (kld)loaded, exiting
> pkg_add: install script returned error status
>
> is there some work around for this? cheers

You need to load the linux kernel module, before installing the
linux_base-f10 port.

Just do a 'kldload linux' before installing the port.  Then to have
the linux module always load at boot, add linux_enable="YES" to
/etc/rc.conf.

Scot
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: problem install linux base f10

[Martin Smith]

Scot Hetzel wrote:

On Thu, Jan 14, 2010 at 10:52 AM, Martin Smith  wrote:

8.0 stable freshly installed and updated, am trying to install linux base
f10 and getting the following error
sysctrl: unknown oid 'compat.linux.osrelease'
linuxulator is not (kld)loaded, exiting
pkg_add: install script returned error status

is there some work around for this? cheers


You need to load the linux kernel module, before installing the
linux_base-f10 port.

Just do a 'kldload linux' before installing the port.  Then to have
the linux module always load at boot, add linux_enable="YES" to
/etc/rc.conf.


Thanks a lot for that Scot.
--
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

An old gripe: Reading via mmap stinks

[Mikhail T.]

03/25/06 14:03, John-Mark Gurney wrote:

The other useful/interesting number would be to compare system time
between the mmap case and the read case to see how much work the
kernel is doing in each case...


After adding begin- and end-offset options to md5(1) -- implemented 
using mmap (see bin/142814) -- I, once again, am upset over the slowness 
of pagefaulting-in compared to the reading-in.


(To reproduce my results, patch your /usr/src/sbin/md5/ with

http://aldan.algebra.com/~mi/tmp/md5-offsets.patch

Then use plain ``md5 LARGE_FILE'' to use read and ``md5 -b 0 
LARGE_FILE'' to use the mmap-method.)


The times for processing an 8Gb file residing on a reasonable IDE drive 
(on a recent FreeBSD-7.2-StABLE/i386) are thus:


  mmap: 43.400u 9.439s 2:35.19 34.0%16+184k 0+0io 106994pf+0w
  read: 41.358u 23.799s 2:12.04 49.3%   16+177k 67677+0io 0pf+0w

Observe, that even though read-ing is quite taxing on the kernel (high 
sys-time), the mmap-ing loses overall -- at least, on an otherwise idle 
system -- because read gets the full throughput of the drive (systat -vm 
shows 100% disk utilization), while pagefaulting gets only about 69%.


When I last brought this up in 2006, it was "revealed", that read(2) 
uses heuristics to perform a read-ahead. Why can't the pagefaulting-in 
implementation use the same or similar "trickery" was never explained...


Now, without a clue on how these things are implemented, I'll concede, 
that, probably, it may /sometimes/ be difficult for VM to predict, where 
the next pagefault will strike, but in the cases, when the process:


a) mmaps up to 1Gb at a time;
b) issues an madvise MADV_SEQUENTIAL over the entire mmap-ed
   region

mmaping ought to offer the same -- or better -- performance, than read. 
For example, a hit on a page inside a region marked as SEQUENTIAL ought 
to bring in the next page or two. VM has all the information and the 
hints, just does not use them... Shame, is not it?


-mi

P.S. If it is any consolation, on Linux things seem to be even worse. 
Processing a 9Gb file on kernel 2.6.18/i386:


   mmap: 26.222u 6.336s 6:01.75 8.9% 0+0k 0+0io 61032pf+0w
   read: 25.991u 7.686s 3:43.70 15.0%0+0k 0+0io 23pf+0w

although the absolute times can't be compared with us due to hardware 
differences, the mmap being nearly twice slower is a shame...

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: An old gripe: Reading via mmap stinks

[Andrew Snow]

Hi Mikhail, I assume these tests were done on UFS.  Have you tried ZFS? 
I'm curious to see the results.



- Andrew
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: USB problems on 8.0-STABLE

[Frank]

On Thu, 14 Jan 2010, John Baldwin wrote:


What does apctest say when you run it?

--
John Baldwin


 apctest


2010-01-14 18:15:04 apctest 3.14.5 (10 January 2009) freebsd
Checking configuration ...
Attached to driver: usb
sharenet.type = DEFAULT
I cannot handle sharenet.type = DEFAULT
2010-01-14 18:15:04 apctest exiting, signal 1

--
Frank
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge panic in 8.0

[Erik Klavon]

On Wed, Jan 13, 2010 at 06:06:40PM -0800, Pyun YongHyeon wrote:
> On Wed, Jan 13, 2010 at 05:47:19PM -0800, Erik Klavon wrote:
> > One of my amd64 machines running 8.0p1 acting as a NAT system for many
> > network clients dropped into kdb today. tr indicates a problem in
> > bge.
> > 
> > Tracing pid 12 tid 100033 td 0xff0001687000
> > pmap_kextract() at pmap_kextract+0x4e
> > bus_dmamap_load() at bus_dmamap_load+0xab
> > bge_newbuf_std() at bge_newbuf_std+0xcc
> > bge_rxeof() at bge_rxeof+0x36a
> > bge_intr() at bge_intr+0x1c0
> > intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
> > ithread_loop() at ithread_loop+0x8e
> > fork_exit() at fork_exit+0x118
> > fork_trampoline() at fork_trampoline+0xe
> > --- trap 0, rip = 0, rsp = 0xff8074c01d30, rbp = 0 ---
> > 
> > I haven't been able to find a PR that matches this particular trace.
> > 
> > Pyun recently MFCd to stable (hence my post to this list) some changes
> > to bge that involve functions in the above trace and according to the
> > commit log (r201685) may address a kernel panic. Is there any
> > indication in the above trace that this is the type of panic the
> > commit attempts to address? I don't have a core dump for this
> > panic. This machine has been unstable on 8, so I may be able to get a
> > core dump in the future. If there is other information you'd like me
> > to gather, please let me know.
> 
> Yes, that part of code in trace above were rewritten to address
> bus_dma(9) issues. So it would be great if you can try latest
> bge(4) in stable/8 and let me know how it goes on your box. I guess
> you can just download if_bge.c and if_bgereg.h from stable/8 and
> rebuild bge(4) would be enough to run it on 8.0-RELEASE.

Great, I will try this out on a test machine today. If it holds up
under testing, I will put it into production. These crashes can happen
weeks after a machine boots, so I won't know if the problem is solved
for some time. Thanks for your help,

Erik
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: An old gripe: Reading via mmap stinks

[Mikhail T.]

01/14/10 17:15, Andrew Snow wrote:

Hi Mikhail, I assume these tests were done on UFS. Have you tried ZFS?
I'm curious to see the results.


I suspect, it would be harder for me to setup ZFS, than for you to apply 
my patch for to md5.c :-)


-mi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: USB problems on 8.0-STABLE

[Frank]

On Thu, 14 Jan 2010, Frank wrote:


On Thu, 14 Jan 2010, John Baldwin wrote:


What does apctest say when you run it?

--
John Baldwin


apctest


2010-01-14 18:15:04 apctest 3.14.5 (10 January 2009) freebsd
Checking configuration ...
Attached to driver: usb
sharenet.type = DEFAULT
I cannot handle sharenet.type = DEFAULT
2010-01-14 18:15:04 apctest exiting, signal 1


My apologies, I had disabled several things in apcupsd.conf during 
testing.


apctest


2010-01-14 18:37:58 apctest 3.14.5 (10 January 2009) freebsd
Checking configuration ...
Attached to driver: usb
sharenet.type = DISABLE
cable.type = USB_CABLE

You are using a USB cable type, so I'm entering USB test mode
mode.type = USB_UPS
Setting up the port ...
apctest FATAL ERROR in generic-usb.c at line 636
Cannot find UPS device --
For a link to detailed USB trouble shooting information,
please see .
apctest error termination completed

--
Frank
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: process in STOP state

[David Xu]

Tijl Coosemans wrote:
 ursig ast doreti_ast

Besides weird formatting of procstat -k output, I do not see anything
wrong in the state of the process. It got SIGSTOP, I am sure.
Attaching gdb helps because debugger gets signal reports instead of
target process getting the signal actions on signal delivery.

The only question is why the process gets SIGSTOP at all.


Wine uses ptrace(2) sometimes. The SIGSTOP could have come from that.
I recently submitted http://www.freebsd.org/cgi/query-pr.cgi?pr=142757
describing a problem with ptrace and signals, so you might want to give
the kernel patch a try.


The problem in your patch is that ksi pointer can not be hold across
thread sleeping, because once the process is resumed, there is no
guarantee that the thread will run first, once the signal came from
process's signal queue, other threads can remove the signal, and here 
your sigqueue_take(ksi) is dangerous code.


David Xu

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: An old gripe: Reading via mmap stinks

[Matthew Dillon]

:   mmap:   43.400u 9.439s 2:35.19 34.0%16+184k 0+0io 106994pf+0w
:   read: 41.358u 23.799s 2:12.04 49.3%   16+177k 67677+0io 0pf+0w
:
:Observe, that even though read-ing is quite taxing on the kernel (high 
:sys-time), the mmap-ing loses overall -- at least, on an otherwise idle 
:system -- because read gets the full throughput of the drive (systat -vm 
:shows 100% disk utilization), while pagefaulting gets only about 69%.
:
:When I last brought this up in 2006, it was "revealed", that read(2) 
:uses heuristics to perform a read-ahead. Why can't the pagefaulting-in 
:implementation use the same or similar "trickery" was never explained...

Well, the VM system does do read-ahead, but clearly the pipelining
is not working properly because if it were then either the cpu or
the disk would be pegged, and neither is.

It's broken in DFly too.  Both FreeBSD and DragonFly use
vnode_pager_generic_getpages() (UFS's ffs_getpages() just calls
the generic) which means (typically) the whole thing devolves into
a UIO_NOCOPY VOP_READ().  The VOP_READ should be doing read-ahead
based on the sequential access heuristic but I already see issues
in both implementations of vnode_pager_generic_getpages() where it
finds a valid page from an earlier read-ahead and stops (failing to
issue any new read-aheads because it fails to issue a new UIO_NOCOPY
VOP_READ... doh!).

This would explain why the performance is not as bad as linux but
is not as good as a properly pipelined case.  I'll play with it
some in DFly and I'm sure the FreeBSD folks can fix it in FreeBSD.

-Matt

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: USB problems on 8.0-STABLE

[Frank]

On Thu, 14 Jan 2010, Steve Randall wrote:


Ace /usr/ports # usbdevs -d -v
usbdevs: no USB controllers found


A possibility occurs to me that I think nobody has yet mentioned. If
you still have the obsolete usbdevs command on your system, is it
possible you also still have the obsolete devel/libusb port installed?
It conflicts with the libusb in the base system, causing just the sorts
of problems you are experiencing.


You hit the nail right on the head!  I deinstalled libusb and now it 
works.


Thanks!

--
Frank
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

HEADS UP: Mass mergemaster MFC to [78]-stable

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Howdy,

I've merged the following changes to bring mergemaster up to date with
what's in HEAD to RELENG_[78]. Of particular interest for most people,
especially those with long-lived installs will be r200425, and r200708;
however a few of the other changes might also bring surprises. As usual
I have tried to be very cautious with the defaults so as not to disrupt
people's existing installations, but please heed the "usual" advice to
back up /etc before running mergemaster. I also suggest the regular use
of the -P option.

If you have any questions or problems please speak up sooner rather than
later, since I'd like to get any "issues" ironed out as far in advance
of the 7.3-RELEASE as possible.

FYI, I do not plan to merge these changes, or any other changes besides
serious bug fixes to RELENG_6.


Enjoy,

Doug

-  Original Message 
Subject: svn commit: r202337 - stable/8/usr.sbin/mergemaster
Date: Fri, 15 Jan 2010 03:28:47 + (UTC)

Author: dougb
Date: Fri Jan 15 03:28:46 2010
New Revision: 202337
URL: http://svn.freebsd.org/changeset/base/202337

Log:
  MFC r200416:
  Simplify handling of MTREEFILE relative to DESTDIR

  Make the message about a missing MTREEFILE combined with -U
  more informative

  MFC r200425:
  Over time things that used to be files/directories/links can change
  to something else. So add code to detect when things don't match and
  give the user choices about how to fix it.

  If we're using -P and something in the above check needs to be moved
  we need to have the directory there for it, so create it at the
  beginning and delete empty versions of it at the end.

  The case where something used to be a file or link and now is supposed
  to be a directory (e.g., /etc/security) is especially dangerous, so
  make failure to install a necessary directory in $DESTDIR a fatal
  error.

  MFC r200700:
  In the places where find is used that the user may see the results,
  first pipe it to sort so that order of processing will be
  deterministic and like things will be grouped together.

  MFC r200701:
  Fix an indentation issue, no functional changes

  MFC r200708:
  Fix a problem with how mergemaster handles the hard links for /.cshrc
  and /.profile. The problem is that install(1) will unlink the old file
  before it installs the new one, which means that in the best case we
  have to compare the changes for the old file twice.

  So, change the logic to first test to see if the link exists, then
  install the file. Then if the link was there and we're using -i, just
  create the link in /root and be done with it. Otherwise display the
  message to the user and give them the option.

  Because we are now sorting things before doing the comparison we can
  know conclusively that the files in / should be the sources, and the
  files in /root will be the targets, so adjust the paths accordingly.

  While I'm here, split a too-long error message into two lines and
  just return at the end of handling these files instead of setting
  the variable that says "do nothing" and then returning at the end
  of the function anyway.

  MFC r201291:
  Add some patches contributed by jhb:
  1. Don't prompt the user for "-U but no db" error if we're using -a
  2. Add an option to delete stale rc.d files automatically if the user
  has DELETE_STALE_RC_FILES in their rc file. Lack of command line
  option for this is not an oversight.
  3. Add []'s around the terminal $ for the $FreeBSD$ test for -F

  For one bug raised by jhb I did a more thorough solution:
  There were a lot of things that "snuck in" between the end of the test
  for -r and the start of the comparison. One of them is the creation of
  the mtree db, as pointed out by jhb. Fix this problem more thoroughly
  by moving the end of the test down to where it should/used to be,
  right before the comparison. As a result, indent the interloping code
  to match.

  MFC r201292:
  Document the DELETE_STALE_RC_FILES option introduced in r201291. This
  is an "rc file only" option by design.

  While I'm here, update the comments in the example rc file to indicate
  which command line options they relate to, and correct the defaults
  for a couple of options.

  MFC r201293:
  It's not necessary to include both Op and Fl for command line options
  included in the text, so use only the latter.

  Clarify that using -U doesn't make sense in combination with -a

  MFC r201323:
  If we are using -p it does not make any sense to even create the
  MTREENEW file since it will never be used.

  MFC r201765:
  Update copyright date

  Update delete_temproot() to include the error message if it fails,
  and clean up the places where it's called.

  If there are no files left in temproot when the comparison is done
  delete it without prompting. This should make "automated" runs of
  mergemaster without -a a little easier.

  Document the new behavior in the man page.


-BEGIN PGP S

Re: Multiple serial consoles via null modem cable

[Marin Atanasov]

Thank you a lot for your feedback!

Now to the real question again, because I'm a little confused now - can I
still get a usb-to-serial port converter having let's say 8 serial ports and
then connect each machine to the usb-to-serial hub and manage them remotely
from a single location (the host having the usb-to-serial hub)? That way I
just specify a serial port number and I get to a specific machine?

The model provided by Boris looks nice, and that was my initial idea, but
I'm not sure if I could get it working under FreeBSD. Is conserver or
conserver-com able to handle this? I know that cu uses COM1 only, but will
conserver able to handle serial consoles on different ports, since the
usb-to-serial port would appear as multiple serial ports.

Thank you and regards,
Marin


On Tue, Jan 12, 2010 at 7:04 PM, Boris Samorodov  wrote:

> On Tue, 12 Jan 2010 17:14:44 +0200 Marin Atanasov wrote:
>
> > I'm thinking about the following situation - 1 system acting like a host
> > with a serial port hub, each port of the hub is connected to a different
> > machine on sio0, using null modem cables.
>
> Along with milti-io serial cards we use multi-usb serial
> converters, such as SUNIX UTS7009P (7 USB to serial adapter):
> http://www.sunix.com.tw/it/en/LinkCraft/UTS4009P_UTS7009P.htm
>
> --
> WBR, Boris Samorodov (bsam)
> Research Engineer, http://www.ipt.ru Telephone & Internet SP
> FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
>



-- 
Marin Atanasov Nikolov
dnaeon AT gmail DOT com
daemon AT unix-heaven DOT org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Multiple serial consoles via null modem cable

[Jeremy Chadwick]

On Fri, Jan 15, 2010 at 08:34:17AM +0200, Marin Atanasov wrote:
> Thank you a lot for your feedback!
> 
> Now to the real question again, because I'm a little confused now - can I
> still get a usb-to-serial port converter having let's say 8 serial ports and
> then connect each machine to the usb-to-serial hub and manage them remotely
> from a single location (the host having the usb-to-serial hub)? That way I
> just specify a serial port number and I get to a specific machine?
>
> The model provided by Boris looks nice, and that was my initial idea, but
> I'm not sure if I could get it working under FreeBSD. Is conserver or
> conserver-com able to handle this? I know that cu uses COM1 only, but will
> conserver able to handle serial consoles on different ports, since the
> usb-to-serial port would appear as multiple serial ports.

I'm referencing the product Charles showed, but the topology would look
like this:

++
|   USB to serial hub|
|   U1 FreeBSD box running conserver
||
||
+-P1---P2---P3---P4---..-+
  ||||
  ||||
  |||`-- box #4
  ||`--- box #3
  |` box #2
  `- box #1

"U1" is the uplink port, which has to connect to something -- in this
case the FreeBSD box where conserver would run.  The uplink port would
connect to a single USB port on the FreeBSD box.

The cabling between a port (Px) and a box would be serial (probably
DB9).

What you end up with on the FreeBSD box is a series of /dev entries
which are associated with all of the ports on the USB to serial hub,
using ucom(4).  For example:

/dev/ttyU0 = P1 = box #1
/dev/ttyU1 = P2 = box #2
...

You'd then tell conserver using its configuration file that "box name
foo is attached to /dev/ttyU0, box name bar is attached to /dev/ttyU1"
and so on.

Then to get access to the serial console of either foo or bar, you'd SSH
to the FreeBSD machine and type "console foo" or "console bar".  Voila.

Make sense?

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Multiple serial consoles via null modem cable

[Marin Atanasov]

Yeap, that makes sense :)

Thank you, I'm gonna try it as soon as I get that device :)

Thanks again,
Marin

On Fri, Jan 15, 2010 at 8:45 AM, Jeremy Chadwick
wrote:

> On Fri, Jan 15, 2010 at 08:34:17AM +0200, Marin Atanasov wrote:
> > Thank you a lot for your feedback!
> >
> > Now to the real question again, because I'm a little confused now - can I
> > still get a usb-to-serial port converter having let's say 8 serial ports
> and
> > then connect each machine to the usb-to-serial hub and manage them
> remotely
> > from a single location (the host having the usb-to-serial hub)? That way
> I
> > just specify a serial port number and I get to a specific machine?
> >
> > The model provided by Boris looks nice, and that was my initial idea, but
> > I'm not sure if I could get it working under FreeBSD. Is conserver or
> > conserver-com able to handle this? I know that cu uses COM1 only, but
> will
> > conserver able to handle serial consoles on different ports, since the
> > usb-to-serial port would appear as multiple serial ports.
>
> I'm referencing the product Charles showed, but the topology would look
> like this:
>
> ++
> |   USB to serial hub|
> |   U1 FreeBSD box running conserver
> ||
> ||
> +-P1---P2---P3---P4---..-+
>  ||||
>  ||||
>  |||`-- box #4
>  ||`--- box #3
>  |` box #2
>  `- box #1
>
> "U1" is the uplink port, which has to connect to something -- in this
> case the FreeBSD box where conserver would run.  The uplink port would
> connect to a single USB port on the FreeBSD box.
>
> The cabling between a port (Px) and a box would be serial (probably
> DB9).
>
> What you end up with on the FreeBSD box is a series of /dev entries
> which are associated with all of the ports on the USB to serial hub,
> using ucom(4).  For example:
>
> /dev/ttyU0 = P1 = box #1
> /dev/ttyU1 = P2 = box #2
> ...
>
> You'd then tell conserver using its configuration file that "box name
> foo is attached to /dev/ttyU0, box name bar is attached to /dev/ttyU1"
> and so on.
>
> Then to get access to the serial console of either foo or bar, you'd SSH
> to the FreeBSD machine and type "console foo" or "console bar".  Voila.
>
> Make sense?
>
> --
> | Jeremy Chadwick   j...@parodius.com |
> | Parodius Networking   http://www.parodius.com/ |
> | UNIX Systems Administrator  Mountain View, CA, USA |
> | Making life hard for others since 1977.  PGP: 4BD6C0CB |
>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>



-- 
Marin Atanasov Nikolov
dnaeon AT gmail DOT com
daemon AT unix-heaven DOT org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: HEADS UP: Mass mergemaster MFC to [78]-stable

[Christer Solskogen]

On Fri, Jan 15, 2010 at 4:38 AM, Doug Barton  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> Howdy,
>

Great work, Doug! Thanks.

-- 
chs
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"