[releng_8 tinderbox] failure on amd64/amd64

2010-09-07 Thread FreeBSD Tinderbox 
TB --- 2010-09-08 05:46:32 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-08 05:46:32 - starting RELENG_8 tinderbox run for amd64/amd64
TB --- 2010-09-08 05:46:32 - cleaning the object tree
TB --- 2010-09-08 05:47:43 - cvsupping the source tree
TB --- 2010-09-08 05:47:43 - /usr/bin/csup -z -r 3 -g -L 1 -h 
cvsup18.freebsd.org /tinderbox/RELENG_8/amd64/amd64/supfile
TB --- 2010-09-08 05:53:05 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-08 05:53:05 - ERROR: unable to cvsup the source tree
TB --- 2010-09-08 05:53:05 - 2.20 user 45.20 system 393.43 real


http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full
___
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: FreeBSD 6.4 and 8.0 EoLs coming soon

2010-09-07 Thread vwe 

[removed security@ which is not nearly related to topic]

On 09/07/10 23:31, Vadim Goncharov wrote:

07.09.10 @ 18:53 Andriy Gapon wrote:

The reason is performance for overall network stack, not ideology.


For a practical reasons, "it works but slow" is better than
"doesn't work at all (due to absence of code in the src tree)".

"Make it work. Make it right. Make it fast. In that order", know this?
Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what
is it?..


BTW, there were advanced notices for users, request for volunteers, etc.

So, if you didn't speak up at that time please keep silence now :-)


You do not understand the problem. It is not in notices & volunteers,
but rather in the Project's policy - delete something which could still
work. Personally, I don't use ISDN, so didn't said anything that time,
but now, there are more precedents of removing components from FreeBSD -
so, for now, I must say that this policy is harmful. Though I doubt that
one man's opinion could change Project's policy until it's too late...



Vadim,

it (i4b) worked, nobody was maintaining it, nobody opted to maintain it, 
everybody was asked to maintain it, nobody wanted, everybody has been 
asked to speak up if the code will be axed out, nobody spoke up, it has 
been axed out ... 13 months ago and even then nobody complained about.


Are _you_ willing to maintain it?
___
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: Network memory allocation failures

2010-09-07 Thread Jeremy Chadwick 
On Tue, Sep 07, 2010 at 05:29:17PM -0700, Pyun YongHyeon wrote:
> On Tue, Sep 07, 2010 at 04:32:57PM -0700, Mahlon E. Smith wrote:
> > On Tue, Sep 07, 2010, Jeremy Chadwick wrote:
> > > 
> > > This could be a bce(4) bug, meaning the "failed to allocate memory"
> > > message could be indicating DMA failure or something else from the card,
> > > and not necessarily related to mbufs.
> > > 
> > > There are also changes/fixes to bce(4) that are in RELENG_8 (8.1-STABLE)
> > > that aren't in 8.1-RELEASE, but I don't know if those are responsible
> > > for your problem.
> > 
> > Hmm, well -- I'm definitely not opposed to jumping to -STABLE if it
> > might fix it.
> > 
> > 
> > > Please provide output from the following:
> > > 
> > > * uname -a(if desired, XXX out hostname)
> > 
> > FreeBSD jessage 8.1-RELEASE FreeBSD 8.1-RELEASE #2: Fri Aug 20 14:30:31 PDT 
> > 2010 r...@jessage:/usr/src/sys/amd64/compile/R810  amd64
> > 
> > Custom kernel, with additions to GENERIC (nothing removed):
> > 
> > device carp
> > device snp
> > options HZ=1000
> > options DEVICE_POLLING
> 
> bce(4) does not support polling(4) so you can completely remove
> configuration of HZ and DEVICE_POLLING. In fact, there is no reason
> to use polling(4) at all on intelligent controllers like bce(4).
> polling(4) is mainly for dumb controllers that lack efficient
> interrupt moderation.
> 
> > options ALTQ
> > options ALTQ_CBQ
> > options ALTQ_PRIQ
> > options SC_DISABLE_REBOOT
> > options PANIC_REBOOT_WAIT_TIME=5
> > 
> > ALTQ and friends not actually active on the machine.  I was fighting a
> > different battle when running GENERIC, so I can't honestly recall if this
> > problem existed then -- I'll make sure it is still happening under
> > GENERIC for a baseline, to eliminate any potential weirdness with
> > DEVICE_POLLING or the HZ timing.
> > 
> > 
> > > * vmstat -i
> > 
> > interrupt  total   rate
> > irq19: ehci0 1547103  0
> > irq21: uhci1 uhci3+   29  0
> > irq23: atapci035  0
> > irq32: mfi0 68104468 43
> > cpu0: timer   3093305346   1986
> > irq256: bce046587008 29
> > cpu19: timer  3103614834   1992
> > cpu1: timer   3093298527   1986
> > cpu4: timer   3093297557   1986
> > cpu10: timer  3089824707   1983
> > cpu12: timer  3097896788   1989
> > cpu16: timer  3097897232   1989
> > cpu22: timer  3103615267   1992
> > cpu2: timer   3093297601   1986
> > cpu5: timer   3093298349   1986
> > cpu3: timer   3093298637   1986
> > cpu6: timer   3089823402   1983
> > cpu18: timer  3103614571   1992
> > cpu13: timer  3097897961   1989
> > cpu20: timer  3103615299   1992
> > cpu23: timer  3103614783   1992
> > cpu9: timer   3089821582   1983
> > cpu17: timer  3097898138   1989
> > cpu11: timer  3089821712   1983
> > cpu14: timer  3097897190   1989
> > cpu7: timer   3089821360   1983
> > cpu21: timer  3103615012   1992
> > cpu15: timer  3097898081   1989
> > cpu8: timer   3089824487   1983
> > Total74424047066  47788
> > 
> > 
> > > * ifconfig -a (if desired, XXX out IPs and MACs)
> > 
> > bce0: flags=8943 metric 
> > 0 mtu 1500
> > 
> > options=c01bb
> > ether 00:25:64:fd:0b:24
> > inet 10.5.2.69 netmask 0xfc00 broadcast 10.5.3.255
> > media: Ethernet autoselect (1000baseT )
> > status: active
> > bce1: flags=8802 metric 0 mtu 1500
> > 
> > options=c01bb
> > ether 00:25:64:fd:0b:26
> > media: Ethernet autoselect (none)
> > status: no carrier
> > bce2: flags=8802 metric 0 mtu 1500
> > 
> > options=c01bb
> > ether 00:25:64:fd:0b:28
> > media: Ethernet autoselect (none)
> > status: no carrier
> > bce3: flags=8802 metric 0 mtu 1500
> > 
> > options=c01bb
> > ether 00:25:64:fd:0b:2a
> > media: Ethernet autoselect (none)
> > status: no carrier
> > lo0: flags=8049 metric 0 mtu 16384
> > options=3
> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
> > inet6 ::1 prefixlen 128 
> > inet 127.0.0.1 netmask 0xff00 
> > nd6 options=3
> > vbo

Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon

2010-09-07 Thread Doug Barton 

On 09/07/2010 02:31 PM, Vadim Goncharov wrote:

07.09.10 @ 18:53 Andriy Gapon wrote:


on 07/09/2010 13:38 Vadim Goncharov said the following:

Just to clarify things a little for those following it:
the original I4B code was removed

^ (1)

for entirely practical reasons: it couldn't run without the Giant
lock, and support for the Giant lock over the network stack was
removed.


But if it was used, removing a component just because of Giant lock
is not
practical and is purely ideologic, isn't it?


Which part of "support for the Giant lock *over the network stack* was
removed"
[emphasis mine] do you not understand?


No, component removed was (1), I've underlined.


The reason is performance for overall network stack, not ideology.


For a practical reasons, "it works but slow" is better than
"doesn't work at all (due to absence of code in the src tree)".


I think you are misunderstanding the situation. It wasn't a case of, "It 
works but it's slow." The situation was that in order to take 
performance of the network stack as a whole up to the next level it was 
necessary to remove the Giant lock. Because the original I4B code didn't 
work without the Giant lock, and because no one stepped forward to fix 
that, the code had to be removed.



BTW, there were advanced notices for users, request for volunteers, etc.

So, if you didn't speak up at that time please keep silence now :-)


You do not understand the problem. It is not in notices & volunteers,


In this case it was 100% about the latter. In addition to the fact that 
without volunteers there is no project, period; the fact that no one 
steps forward to maintain/improve a given piece of code is generally a 
pretty good indicator that it's not widely used.



but rather in the Project's policy - delete something which could still
work.


This was not the case here.


Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

___
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: FreeBSD 6.4 and 8.0 EoLs coming soon

2010-09-07 Thread Vadim Goncharov 

07.09.10 @ 18:53 Andriy Gapon wrote:


on 07/09/2010 13:38 Vadim Goncharov said the following:

Just to clarify things a little for those following it:
the original I4B code was removed

^ (1)

for entirely practical reasons: it couldn't run without the Giant
lock, and support for the Giant lock over the network stack was  
removed.


But if it was used, removing a component just because of Giant lock is  
not

practical and is purely ideologic, isn't it?


Which part of "support for the Giant lock *over the network stack* was  
removed"

[emphasis mine] do you not understand?


No, component removed was (1), I've underlined.


The reason is performance for overall network stack, not ideology.


For a practical reasons, "it works but slow" is better than
"doesn't work at all (due to absence of code in the src tree)".

"Make it work. Make it right. Make it fast. In that order", know this?
Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is  
it?..



BTW, there were advanced notices for users, request for volunteers, etc.

So, if you didn't speak up at that time please keep silence now :-)


You do not understand the problem. It is not in notices & volunteers, but  
rather in the Project's policy - delete something which could still work.  
Personally, I don't use ISDN, so didn't said anything that time, but now,  
there are more precedents of removing components from FreeBSD - so, for  
now, I must say that this policy is harmful. Though I doubt that one man's  
opinion could change Project's policy until it's too late...


--
WBR, Vadim Goncharov
___
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: Network memory allocation failures

2010-09-07 Thread Pyun YongHyeon 
On Tue, Sep 07, 2010 at 04:32:57PM -0700, Mahlon E. Smith wrote:
> On Tue, Sep 07, 2010, Jeremy Chadwick wrote:
> > 
> > This could be a bce(4) bug, meaning the "failed to allocate memory"
> > message could be indicating DMA failure or something else from the card,
> > and not necessarily related to mbufs.
> > 
> > There are also changes/fixes to bce(4) that are in RELENG_8 (8.1-STABLE)
> > that aren't in 8.1-RELEASE, but I don't know if those are responsible
> > for your problem.
> 
> Hmm, well -- I'm definitely not opposed to jumping to -STABLE if it
> might fix it.
> 
> 
> > Please provide output from the following:
> > 
> > * uname -a(if desired, XXX out hostname)
> 
> FreeBSD jessage 8.1-RELEASE FreeBSD 8.1-RELEASE #2: Fri Aug 20 14:30:31 PDT 
> 2010 r...@jessage:/usr/src/sys/amd64/compile/R810  amd64
> 
> Custom kernel, with additions to GENERIC (nothing removed):
> 
> device carp
> device snp
> options HZ=1000
> options DEVICE_POLLING

bce(4) does not support polling(4) so you can completely remove
configuration of HZ and DEVICE_POLLING. In fact, there is no reason
to use polling(4) at all on intelligent controllers like bce(4).
polling(4) is mainly for dumb controllers that lack efficient
interrupt moderation.

> options ALTQ
> options ALTQ_CBQ
> options ALTQ_PRIQ
> options SC_DISABLE_REBOOT
> options PANIC_REBOOT_WAIT_TIME=5
> 
> ALTQ and friends not actually active on the machine.  I was fighting a
> different battle when running GENERIC, so I can't honestly recall if this
> problem existed then -- I'll make sure it is still happening under
> GENERIC for a baseline, to eliminate any potential weirdness with
> DEVICE_POLLING or the HZ timing.
> 
> 
> > * vmstat -i
> 
> interrupt  total   rate
> irq19: ehci0 1547103  0
> irq21: uhci1 uhci3+   29  0
> irq23: atapci035  0
> irq32: mfi0 68104468 43
> cpu0: timer   3093305346   1986
> irq256: bce046587008 29
> cpu19: timer  3103614834   1992
> cpu1: timer   3093298527   1986
> cpu4: timer   3093297557   1986
> cpu10: timer  3089824707   1983
> cpu12: timer  3097896788   1989
> cpu16: timer  3097897232   1989
> cpu22: timer  3103615267   1992
> cpu2: timer   3093297601   1986
> cpu5: timer   3093298349   1986
> cpu3: timer   3093298637   1986
> cpu6: timer   3089823402   1983
> cpu18: timer  3103614571   1992
> cpu13: timer  3097897961   1989
> cpu20: timer  3103615299   1992
> cpu23: timer  3103614783   1992
> cpu9: timer   3089821582   1983
> cpu17: timer  3097898138   1989
> cpu11: timer  3089821712   1983
> cpu14: timer  3097897190   1989
> cpu7: timer   3089821360   1983
> cpu21: timer  3103615012   1992
> cpu15: timer  3097898081   1989
> cpu8: timer   3089824487   1983
> Total74424047066  47788
> 
> 
> > * ifconfig -a (if desired, XXX out IPs and MACs)
> 
> bce0: flags=8943 metric 0 
> mtu 1500
> 
> options=c01bb
> ether 00:25:64:fd:0b:24
> inet 10.5.2.69 netmask 0xfc00 broadcast 10.5.3.255
> media: Ethernet autoselect (1000baseT )
> status: active
> bce1: flags=8802 metric 0 mtu 1500
> 
> options=c01bb
> ether 00:25:64:fd:0b:26
> media: Ethernet autoselect (none)
> status: no carrier
> bce2: flags=8802 metric 0 mtu 1500
> 
> options=c01bb
> ether 00:25:64:fd:0b:28
> media: Ethernet autoselect (none)
> status: no carrier
> bce3: flags=8802 metric 0 mtu 1500
> 
> options=c01bb
> ether 00:25:64:fd:0b:2a
> media: Ethernet autoselect (none)
> status: no carrier
> lo0: flags=8049 metric 0 mtu 16384
> options=3
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
> inet6 ::1 prefixlen 128 
> inet 127.0.0.1 netmask 0xff00 
> nd6 options=3
> vboxnet0: flags=8802 metric 0 mtu 1500
> ether 0a:00:27:00:00:00
> 
> 
> > * netstat -inbd   (if desired, XXX out MACs)
> 
> NameMtu Network   Address  Ipkts Ierrs Idrop 
> IbytesOpkts Oerrs Obytes  Coll Drop
> bce0   1500   00:25:64:fd:0b:24 1446

Re: Network memory allocation failures

2010-09-07 Thread Mahlon E. Smith 
On Tue, Sep 07, 2010, Jeremy Chadwick wrote:
> 
> This could be a bce(4) bug, meaning the "failed to allocate memory"
> message could be indicating DMA failure or something else from the card,
> and not necessarily related to mbufs.
> 
> There are also changes/fixes to bce(4) that are in RELENG_8 (8.1-STABLE)
> that aren't in 8.1-RELEASE, but I don't know if those are responsible
> for your problem.

Hmm, well -- I'm definitely not opposed to jumping to -STABLE if it
might fix it.


> Please provide output from the following:
> 
> * uname -a(if desired, XXX out hostname)

FreeBSD jessage 8.1-RELEASE FreeBSD 8.1-RELEASE #2: Fri Aug 20 14:30:31 PDT 
2010 r...@jessage:/usr/src/sys/amd64/compile/R810  amd64

Custom kernel, with additions to GENERIC (nothing removed):

device carp
device snp
options HZ=1000
options DEVICE_POLLING
options ALTQ
options ALTQ_CBQ
options ALTQ_PRIQ
options SC_DISABLE_REBOOT
options PANIC_REBOOT_WAIT_TIME=5

ALTQ and friends not actually active on the machine.  I was fighting a
different battle when running GENERIC, so I can't honestly recall if this
problem existed then -- I'll make sure it is still happening under
GENERIC for a baseline, to eliminate any potential weirdness with
DEVICE_POLLING or the HZ timing.


> * vmstat -i

interrupt  total   rate
irq19: ehci0 1547103  0
irq21: uhci1 uhci3+   29  0
irq23: atapci035  0
irq32: mfi0 68104468 43
cpu0: timer   3093305346   1986
irq256: bce046587008 29
cpu19: timer  3103614834   1992
cpu1: timer   3093298527   1986
cpu4: timer   3093297557   1986
cpu10: timer  3089824707   1983
cpu12: timer  3097896788   1989
cpu16: timer  3097897232   1989
cpu22: timer  3103615267   1992
cpu2: timer   3093297601   1986
cpu5: timer   3093298349   1986
cpu3: timer   3093298637   1986
cpu6: timer   3089823402   1983
cpu18: timer  3103614571   1992
cpu13: timer  3097897961   1989
cpu20: timer  3103615299   1992
cpu23: timer  3103614783   1992
cpu9: timer   3089821582   1983
cpu17: timer  3097898138   1989
cpu11: timer  3089821712   1983
cpu14: timer  3097897190   1989
cpu7: timer   3089821360   1983
cpu21: timer  3103615012   1992
cpu15: timer  3097898081   1989
cpu8: timer   3089824487   1983
Total74424047066  47788


> * ifconfig -a (if desired, XXX out IPs and MACs)

bce0: flags=8943 metric 0 
mtu 1500

options=c01bb
ether 00:25:64:fd:0b:24
inet 10.5.2.69 netmask 0xfc00 broadcast 10.5.3.255
media: Ethernet autoselect (1000baseT )
status: active
bce1: flags=8802 metric 0 mtu 1500

options=c01bb
ether 00:25:64:fd:0b:26
media: Ethernet autoselect (none)
status: no carrier
bce2: flags=8802 metric 0 mtu 1500

options=c01bb
ether 00:25:64:fd:0b:28
media: Ethernet autoselect (none)
status: no carrier
bce3: flags=8802 metric 0 mtu 1500

options=c01bb
ether 00:25:64:fd:0b:2a
media: Ethernet autoselect (none)
status: no carrier
lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
inet6 ::1 prefixlen 128 
inet 127.0.0.1 netmask 0xff00 
nd6 options=3
vboxnet0: flags=8802 metric 0 mtu 1500
ether 0a:00:27:00:00:00


> * netstat -inbd   (if desired, XXX out MACs)

NameMtu Network   Address  Ipkts Ierrs Idrop Ibytes 
   Opkts Oerrs Obytes  Coll Drop
bce0   1500   00:25:64:fd:0b:24 14467627 0 0 6346549588 
11846499 0 4646920777 00 
bce0   1500 10.5.0.0/22   10.5.2.69  1987644 - -  371635478 
  415087 -   74168123 -- 
bce1*  1500   00:25:64:fd:0b:260 0 0  0 
   0 0  0 00 
bce2*  1500   00:25:64:fd:0b:280 0 0  0 
   0 0  0 00 
bce3*  1500   00:25:64:fd:0b:2a0 0 0  0 
   0 0  0 00 
lo0   1638425561 0 0   47

Re: Network memory allocation failures

2010-09-07 Thread Jeremy Chadwick 
On Tue, Sep 07, 2010 at 02:08:13PM -0700, Mahlon E. Smith wrote:
> I picked up a couple of Dell R810 monsters a couple of months ago.  96G
> of RAM, 24 core.  With the aid of this list, got 8.1-RELEASE on there,
> and they are trucking along merrily as VirtualBox hosts.
> 
> I'm seeing memory allocation errors when sending data over the network.
> It is random at best, however I can reproduce it pretty reliably.
> 
> Sending 100M to a remote machine.  Note the 2nd scp attempt worked.
> Most small files can make it through unmolested.
> 
> obb# dd if=/dev/random of=100M-test bs=1M count=100
> 100+0 records in
> 100+0 records out
> 104857600 bytes transferred in 2.881689 secs (36387551 bytes/sec)
> obb# rsync -av 100M-test skin:/tmp/
> sending incremental file list
> 100M-test
> Write failed: Cannot allocate memory
> rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: 
> Broken pipe (32)
> rsync: connection unexpectedly closed (28 bytes received so far) [sender]
> rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
> obb# scp 100M-test skin:/tmp/
> 100M-test52%   52MB  52.1MB/s   00:00 ETAWrite failed: Cannot 
> allocate memory
> lost connection
> obb# scp 100M-test skin:/tmp/
> 100M-test   100%  100MB  50.0MB/s   00:02
> obb# scp 100M-test skin:/tmp/
> 100M-test 0%0 0.0KB/s   --:-- ETAWrite failed: Cannot 
> allocate memory
> lost connection
> 
> Fetching a file, however, works.
> 
> obb# scp skin:/usr/local/tmp/100M-test .
> 100M-test100%  100MB  20.0MB/s   00:05
> obb# scp skin:/usr/local/tmp/100M-test .
> 100M-test100%  100MB  20.0MB/s   00:05
> obb# scp skin:/usr/local/tmp/100M-test .
> 100M-test100%  100MB  20.0MB/s   00:05
> obb# scp skin:/usr/local/tmp/100M-test .
> 100M-test100%  100MB  20.0MB/s   00:05
> ...
> 
> 
> I've ruled out bad hardware (mainly due to the behavior being
> *identical* on the sister machine, in a completely different data
> center.) It's a broadcom (bce) NIC.

This could be a bce(4) bug, meaning the "failed to allocate memory"
message could be indicating DMA failure or something else from the card,
and not necessarily related to mbufs.

There are also changes/fixes to bce(4) that are in RELENG_8 (8.1-STABLE)
that aren't in 8.1-RELEASE, but I don't know if those are responsible
for your problem.

Please provide output from the following:

* uname -a(if desired, XXX out hostname)
* vmstat -i
* ifconfig -a (if desired, XXX out IPs and MACs)
* netstat -inbd   (if desired, XXX out MACs)
* pciconf -lvc(only the bceX entry please)

Also check dmesg to see if there's any error messages that correlate
when the problem occurs.

I'm also CC'ing Yong-Hyeon PYUN who might have some ideas.

-- 
| 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: Network memory allocation failures

2010-09-07 Thread Adam Vande More 
On Tue, Sep 7, 2010 at 4:08 PM, Mahlon E. Smith  wrote:

> I've kind of reached a limit here in what to dig for / try next.  What
> else can I do to try and determine the root problem that would be
> helpful?  Anyone ever have to deal with or seen something like this
> recently?  (Or hell, not recently?)
>
> Ideas appreciated! 
>

Wild guess here, not sure all the dynamics of changing this, but you could
try increasing:

kern.maxdsiz

It's a kern tunable, so change it in /boot/loader.conf

-- 
Adam Vande More
___
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"

Network memory allocation failures

2010-09-07 Thread Mahlon E. Smith 

Hi, all.

I picked up a couple of Dell R810 monsters a couple of months ago.  96G
of RAM, 24 core.  With the aid of this list, got 8.1-RELEASE on there,
and they are trucking along merrily as VirtualBox hosts.

I'm seeing memory allocation errors when sending data over the network.
It is random at best, however I can reproduce it pretty reliably.

Sending 100M to a remote machine.  Note the 2nd scp attempt worked.
Most small files can make it through unmolested.

obb# dd if=/dev/random of=100M-test bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes transferred in 2.881689 secs (36387551 bytes/sec)
obb# rsync -av 100M-test skin:/tmp/
sending incremental file list
100M-test
Write failed: Cannot allocate memory
rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: 
Broken pipe (32)
rsync: connection unexpectedly closed (28 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
obb# scp 100M-test skin:/tmp/
100M-test52%   52MB  52.1MB/s   00:00 ETAWrite failed: Cannot 
allocate memory
lost connection
obb# scp 100M-test skin:/tmp/
100M-test   100%  100MB  50.0MB/s   00:02
obb# scp 100M-test skin:/tmp/
100M-test 0%0 0.0KB/s   --:-- ETAWrite failed: Cannot 
allocate memory
lost connection

Fetching a file, however, works.

obb# scp skin:/usr/local/tmp/100M-test .
100M-test100%  100MB  20.0MB/s   00:05
obb# scp skin:/usr/local/tmp/100M-test .
100M-test100%  100MB  20.0MB/s   00:05
obb# scp skin:/usr/local/tmp/100M-test .
100M-test100%  100MB  20.0MB/s   00:05
obb# scp skin:/usr/local/tmp/100M-test .
100M-test100%  100MB  20.0MB/s   00:05
...


I've ruled out bad hardware (mainly due to the behavior being
*identical* on the sister machine, in a completely different data
center.) It's a broadcom (bce) NIC.

mbufs look fine to me.

obb# netstat -m
511/6659/7170 mbufs in use (current/cache/total)
510/3678/4188/25600 mbuf clusters in use (current/cache/total/max)
510/3202 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/984/984/12800 4k (page size) jumbo clusters in use
(current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
1147K/12956K/14104K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

Plenty of available mem (not surprising):

obb# vmstat -hc 5 -w 5 
 procs  memory  pagedisks faults cpu
 r b w avmfre   flt  re  pi  pofr  sr mf0 mf1   in   sy   cs us 
sy id
 0 0 0722M92G   115   0   1   0  1067   0   0   0  429 32637 6520  
0  1 99
 0 0 0722M92G 1   0   0   0 0   0   0   09 31830 3279  
0  0 100
 0 0 0722M92G 0   0   0   0 3   0   0   08 33171 3223  
0  0 100
 0 0 0761M92G  2593   0   0   0  1712   0   5   4  121 35384 3907  
0  0 99
 1 0 0761M92G 0   0   0   0 0   0   0   0   10 30237 3156  
0  0 100


Last bit of info, and here's where it gets really weird.  Remember how I
said this was a VirtualBox host?  Guest machines running on it (mostly
centos) don't exhibit the problem, which is also why it took me so long
to notice it in the host.  They can merrily copy data around at will,
even though they are going out through the same host interface.

I'm not sure what to check for or toggle at this point.  There are all
sorts of tunables I've been mucking around with to no avail, and so I've
reverted them to defaults.  Mostly concentrating on these:

hw.intr_storm_threshold
net.inet.tcp.rfc1323
kern.ipc.nmbclusters
kern.ipc.nmbjumbop
net.inet.tcp.sendspace
net.inet.tcp.recvspace
kern.ipc.somaxconn
kern.ipc.maxsockbuf

It was suggested to me to try limiting the RAM in loader.conf to under
32G and see what happens.  When doing this, it does appear to be "okay".
Not sure if that's coincidence, or directly related -- something with
the large amount of RAM that is confusing a data structure somewhere?
Or potentially a problem with the bce driver, specifically?

I've kind of reached a limit here in what to dig for / try next.  What
else can I do to try and determine the root problem that would be
helpful?  Anyone ever have to deal with or seen something like this
recently?  (Or hell, not recently?)

Ideas appreciated!

--
Mahlon E. Smith  
http://www.martini.nu/contact.html


pgp8MJk2qvp9Q.pgp
Description: PGP signature

Cannot build 7-stable (nsn-attrab)

2010-09-07 Thread Thomas Donnelly 

Hello All,

I am trying to do make buildworld after a fresh cvsup on a freebsd 7 box  
and running into some issues. I appologize if I am flooding the list with  
output but I want to make sure I send as much information as possible.


Initially I had this error:

cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/
usr/obj/usr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/
cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/
usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/
usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/
usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/
usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/
src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber  -I/
usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/
cc_int/../../../../contrib/gcc/tree-ssa-ccp.c


{standard input}: Assembler messages:
{standard input}:0: Warning: end of file not at end of a line; newline  
inserted

cc: Internal error: Killed: 9 (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1
{standard input}: Assembler messages:
{standard input}:1939: Warning: end of file not at end of a line; newline  
inserted

{standard input}:2129: Error: expecting operand after ','; got nothing
cc: Internal error: Killed: 9 (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1
2 errors
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error


with this make.conf:

# added by use.perl 2009-07-01 16:17:52
PERL_VERSION=5.8.9
PYTHON_DEFAULT_VERSION=python2.4
BATCH=YES
WITHOUT_X11=YES
SKIP_DNS_CHECK=YES
CRYPT_DES=0
WITH_PORT_REPLACES_BASE_BIND8=YES
WITH_PORT_REPLACES_BASE_BIND9=YES
WITHOUT_ALT_CONFIG_PREFIX=YES
WITH_OPENSSL_PORT=YES
X11BASE=${LOCALBASE}


Then I replaced that make.conf with a completely clean make.conf and got  
this error:


cc -O2 -fno-strict-aliasing -pipe  -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=
\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/
src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/
cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/
cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/
cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/
cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/
usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber  -c ../
cc_tools/insn-attrtab.c
{standard input}: Assembler messages:
{standard input}:24478: Warning: end of file not at end of a line; newline  
inserted

{standard input}:25877: Error: unknown pseudo-op: `.'
cc: Internal error: Killed: 9 (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1

Stop in /usr/src/gnu/usr.bin/cc/cc_int.
*** Error code 1

Stop in /usr/src/gnu/usr.bin/cc.
*** Error code 1

Stop in /usr/src/gnu/usr.bin.
*** Error code 1

Stop in /usr/src/gnu.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


These errors happened consistently multiple times. Usually with hardware  
failure my experience is it is inconsistent when it breaks. I have no  
reason to suspect hardware failure with this machine. While I am not  
ruling it out, it seems unlikely.


$ uname -a
FreeBSD xxx.xxx.xxx 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Thu Jul  2  
16:07:38 UTC 2009 r...@xxx/xxx/:/usr/obj/usr/src/sys/XXX  amd64



Thoughts?

I am not on this list so please cc me in your replies.

Thanks!
-=Tom


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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: MSIX failure

2010-09-07 Thread Jack Vogel 
I've looked at the code, this message was misleading, what really happens
is that the driver fails to be able to setup either MSIX OR MSI, when this
happens it will fall back and use a Legacy interrupt, so its non-fatal and
the device should work anyway.

The only real reason you should see this is a) you used sysctl and turned
msi and msix off, or b) a real hardware problem in the chipset has caused
the failure. All devices em drives (as opposed to lem) are PCI Express and
so by definition they have MSI and MSIX available.

I have just checked in a new delta to em in HEAD that corrects some other
issues, and I have added a changed message that will be less confusing.

Regards,

Jack


On Tue, Sep 7, 2010 at 10:00 AM, Jack Vogel  wrote:

> Email to Gareth de Vaux is bouncing :(
>
> First off, this device was not supported in 8.0 REL, what were you running
> that last
> worked?
>
> Do you have MSI disabled on this system of yours, the reason for this
> message
> is that both MSIX and MSI setup failed, your device should succeed with
> MSI.
>
> Tell me more about the system please?
>
> Jack
>
>
>
> On Mon, Sep 6, 2010 at 11:36 AM, Jack Vogel  wrote:
>
>> In the future make sure that you put E1000 or EM in the title otherwise I
>> might miss it,
>> fortunately I looked at this :)
>>
>> I'm on a holiday weekend, I will investigate this tomorrow.
>>
>> Jack
>>
>>
>>
>> On Mon, Sep 6, 2010 at 8:53 AM, Gareth de Vaux  wrote:
>>
>>> Hi all, I moved from 8.0-RELEASE to last week's -STABLE:
>>>
>>> $ uname -v
>>> FreeBSD 8.1-STABLE #0: Thu Sep  2 16:38:02 SAST 2010 r...@x
>>> :/usr/obj/usr/src/sys/GENERIC
>>>
>>> and all seems well except my network card is unusable. On boot up:
>>>
>>> em0:  port 0x3040-0x305f mem
>>> 0xe320-0xe321,0xe322-0xe3220fff irq 10 at device 25.0 on pci0
>>> em0: Setup MSIX failure
>>> em0: [FILTER]
>>> em0: Ethernet address: 00:27:0e:1e:5e:e3
>>>
>>> em1:  port
>>> 0x1000-0x103f mem 0xe312-0xe313,0xe310-0xe311 irq 9 at
>>> device 1.0 on pci5
>>> em1: [FILTER]
>>> em1: Ethernet address: 00:1b:21:5b:f2:18
>>>
>>>
>>> em0 is a PCI 'Intel(R) PRO/1000 GT Desktop Adapter' which worked up until
>>> now.
>>> em1 is onboard which didn't work with 8.0-RELEASE either.
>>>
>>>
>>> $ ifconfig em0
>>> em0: flags=8843 metric 0 mtu 1500
>>>
>>>  
>>> options=219b
>>>ether 00:27:0e:1e:5e:e3
>>>inet 
>>>media: Ethernet autoselect
>>>status: no carrier
>>>
>>>
>>> pciconf -lv:
>>>
>>> e...@pci0:0:25:0:class=0x02 card=0x8086 chip=0x10f08086
>>> rev=0x05 hdr=0x00
>>>vendor = 'Intel Corporation'
>>>class  = network
>>>subclass   = ethernet
>>>
>>> e...@pci0:5:1:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05
>>> hdr=0x00
>>>vendor = 'Intel Corporation'
>>>device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)'
>>>class  = network
>>>subclass   = ethernet
>>>
>>> (no device listing for em0)
>>>
>>> Swapping the PCI card with a PCI-X version gives the same behaviour.
>>> Setting
>>> hw.pci.enable_msix and hw.pci.enable_msi to 0 doesn't help in either
>>> case.
>>> ___
>>> 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
>>> "
>>>
>>
>>
>
___
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: Broadcom 4315 not working

2010-09-07 Thread Baby Boy 

 On 07.09.2010 02:39, Weongyo Jeong wrote:

Today I MFCed a patch for LP PHY devices to STABLE_8.  Could you please
test with latest?

One thing you can test is that using PIO mode.  Thank you.

regards,
Weongyo Jeong



Hello everybody!

All operations are executed on a completely new/clean OS.
Access Point ASUS WL-330gE, Authentication Method selected Open System.
###

=== PREPARATION ===

# svn checkout svn://svn.freebsd.org/base/stable/8 /usr/src
...
...
# uname -a
FreeBSD  8.1-STABLE FreeBSD 8.1-STABLE #0 r212293: Tue Sep  7 19:21:04 
MSD 2010 dm@:/usr/obj/usr/src/sys/GENERIC  i386


Update ports and:
# cd /usr/ports/net/bwn-firmware-kmod && make install clean
...
===>   Registering installation for bwn-firmware-kmod-0.1.0
===>  Cleaning for b43-fwcutter-012
===>  Cleaning for bwn-firmware-kmod-0.1.0
# rehash

# pciconf -lvbc
no...@pci0:3:0:0:   class=0x028000 card=0x1508103c chip=0x431514e4 
rev=0x01 hdr=0x00

vendor = 'Broadcom Corporation'
device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)'
class  = network
bar   [10] = type Memory, range 64, base 0xd420, size 16384, 
enabled

cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
cap 09[58] = vendor (length 120)
cap 05[e8] = MSI supports 1 message, 64 bit
cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)

# echo if_bwn_load=\"YES\" >> /boot/loader.conf
# shutdown -r now

# kldstat
Id Refs AddressSize Name
 18 0xc040 bc242c   kernel
 21 0xc0fc3000 37248if_bwn.ko
 32 0xc0ffb000 a26c siba_bwn.ko

# ifconfig
bwn0: flags=8802 metric 0 mtu 2290
ether 0c:ee:e6:a1:50:cc
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
###

=== DMA ===

# kldload bwn_v4_lp_ucode.ko
# ifconfig wlan0 create wlandev bwn0
# ifconfig wlan0 up
# ifconfig
bwn0: flags=8843 metric 0 mtu 2290
ether 0c:ee:e6:a1:50:cc
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
status: associated

wlan0: flags=8843 metric 0 mtu 1500
ether 0c:ee:e6:a1:50:cc
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrier
ssid "" channel 5 (2432 MHz 11g)
country US authmode OPEN privacy OFF txpower 30 bmiss 7 
scanvalid 60

bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5
protmode CTS wme bintval 0

# ifconfig wlan0 up list ap
SSID/MESH IDBSSID  CHAN RATE   S:N INT CAPS
dlink home 11   00:1c:f0:e2:96:c56   54M -132:-95  100 EPS  WME ATH WPS
ASUS00:1d:60:16:d5:161   11M -107:-95  100 EWME <<-- 
Is my

my_home_net...  00:1c:f0:3d:5f:d91   54M -140:-95  100 EPS  RSN WPA ATH
DIR300.Augur00:1e:58:81:50:611   54M -141:-95  100 EPS  ATH WPS
dlink DIR-400   00:01:23:45:67:892   54M -140:-95  100 EPS  WPA WPS

# cat /var/log/messages
...
Sep  7 20:41:51  kernel: wlan0: Ethernet address: 0c:ee:e6:a1:50:cc
Sep  7 20:42:01  kernel: bwn0: firmware version (rev 478 patch 104 date 
0x8701 time 0x657)
Sep  7 20:42:01  kernel: wlan0: ieee80211_new_state_locked: pending INIT 
-> SCAN transition lost

Sep  7 20:42:01  kernel:
Sep  7 20:42:04  kernel: bwn0: status of RF switch is changed to OFF
Sep  7 20:42:04  kernel: bwn0: please turns on the RF switch
Sep  7 20:42:05  kernel: bwn0: status of RF switch is changed to ON
Sep  7 20:42:29  kernel: bwn0: status of RF switch is changed to OFF
Sep  7 20:42:29  kernel: bwn0: please turns on the RF switch
Sep  7 20:42:30  kernel: bwn0: status of RF switch is changed to ON
Sep  7 20:42:33  kernel: bwn0: status of RF switch is changed to OFF
Sep  7 20:42:33  kernel: bwn0: please turns on the RF switch
Sep  7 20:42:34  kernel: bwn0: status of RF switch is changed to ON
Sep  7 20:43:32  kernel: bwn0: status of RF switch is changed to OFF
Sep  7 20:43:32  kernel: bwn0: please turns on the RF switch
Sep  7 20:43:40  kernel: bwn0: status of RF switch is changed to ON
Sep  7 20:43:53  kernel: bwn0: status of RF switch is changed to OFF
Sep  7 20:43:53  kernel: bwn0: please turns on the RF switch
.

If manually press on switch WiFi On/Off, then OS response by pressing in 
the form of output status (ON or OFF) on monitor.

###

=== PIO ===
(Warren Block, thanks for the help)

# echo hw.bwn.usedma=0 >> /boot/loader.conf
# shutdown -r now

# kldload bwn_v4_lp_ucode.ko
# ifconfig wlan0 create wlandev bwn0
# ifconfig wlan0 up
# ifconfig
bwn0: flags=8843 metric 0 mtu 2290
ether 0c:ee:e6:a1:50:cc
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
status: associated
...
wlan0: flags=8843 metric 0 mtu 1500
ether 0c:ee:e6:a1:50:cc
media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
status: no carrie

Re: MSIX failure

2010-09-07 Thread Jack Vogel 
Email to Gareth de Vaux is bouncing :(

First off, this device was not supported in 8.0 REL, what were you running
that last
worked?

Do you have MSI disabled on this system of yours, the reason for this
message
is that both MSIX and MSI setup failed, your device should succeed with MSI.

Tell me more about the system please?

Jack


On Mon, Sep 6, 2010 at 11:36 AM, Jack Vogel  wrote:

> In the future make sure that you put E1000 or EM in the title otherwise I
> might miss it,
> fortunately I looked at this :)
>
> I'm on a holiday weekend, I will investigate this tomorrow.
>
> Jack
>
>
>
> On Mon, Sep 6, 2010 at 8:53 AM, Gareth de Vaux  wrote:
>
>> Hi all, I moved from 8.0-RELEASE to last week's -STABLE:
>>
>> $ uname -v
>> FreeBSD 8.1-STABLE #0: Thu Sep  2 16:38:02 SAST 2010 r...@x
>> :/usr/obj/usr/src/sys/GENERIC
>>
>> and all seems well except my network card is unusable. On boot up:
>>
>> em0:  port 0x3040-0x305f mem
>> 0xe320-0xe321,0xe322-0xe3220fff irq 10 at device 25.0 on pci0
>> em0: Setup MSIX failure
>> em0: [FILTER]
>> em0: Ethernet address: 00:27:0e:1e:5e:e3
>>
>> em1:  port
>> 0x1000-0x103f mem 0xe312-0xe313,0xe310-0xe311 irq 9 at
>> device 1.0 on pci5
>> em1: [FILTER]
>> em1: Ethernet address: 00:1b:21:5b:f2:18
>>
>>
>> em0 is a PCI 'Intel(R) PRO/1000 GT Desktop Adapter' which worked up until
>> now.
>> em1 is onboard which didn't work with 8.0-RELEASE either.
>>
>>
>> $ ifconfig em0
>> em0: flags=8843 metric 0 mtu 1500
>>
>>  
>> options=219b
>>ether 00:27:0e:1e:5e:e3
>>inet 
>>media: Ethernet autoselect
>>status: no carrier
>>
>>
>> pciconf -lv:
>>
>> e...@pci0:0:25:0:class=0x02 card=0x8086 chip=0x10f08086
>> rev=0x05 hdr=0x00
>>vendor = 'Intel Corporation'
>>class  = network
>>subclass   = ethernet
>>
>> e...@pci0:5:1:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05
>> hdr=0x00
>>vendor = 'Intel Corporation'
>>device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)'
>>class  = network
>>subclass   = ethernet
>>
>> (no device listing for em0)
>>
>> Swapping the PCI card with a PCI-X version gives the same behaviour.
>> Setting
>> hw.pci.enable_msix and hw.pci.enable_msi to 0 doesn't help in either case.
>> ___
>> 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"
>>
>
>
___
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"

Cannot install using serial console

2010-09-07 Thread Jeremie Le Hen 
Hi list,

=> Please Cc: me when replying, as I am not subscribed. <=

I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think
it's important here) in a KVM-backed virtual machine on a headless Linux
host, following section 2.12.1 of the handbook.
http://www.freebsd.org/doc/handbook/install-advanced.html

I've rebuilt the ISO image with the following lines in boot/loader.conf:
console="comconsole"
beastie_disable="YES"

The kernel boots correctly (see output below) but the output invariably
stalls after the following lines:
Trying to mount root from ufs:/dev/md0
/stand/sysinstal

(Yes, only one `l'.)

Any idea?

/boot/kernel/kernel text=0x919885 data=0xe7a54+0x203be0 
syms=[0x4+0xa25d0+0x4+0xde647]
|
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT-201008 #0: Tue Aug  3 20:41:56 UTC 2010
r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
WARNING: WITNESS option enabled, expect reduced performance.
CPU: QEMU Virtual CPU version 0.9.1 (2667.06-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x663  Family = 6  Model = 6  Stepping = 3
  
Features=0x783fbfd
  Features2=0x1
  AMD Features=0xe0100800
  AMD Features2=0x4
real memory  = 268435456 (256 MB)
avail memory = 239321088 (228 MB)
Event timer "LAPIC" frequency 0 Hz quality 500
ACPI APIC Table: 
ioapic0: Changing APIC ID to 1
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0:  on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0
cpu0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci_link0: BIOS IRQ 9 does not match initial IRQ 10
pci0:  on pcib0
isab0:  at device 1.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0
ata0:  on atapci0
ata0: [ITHREAD]
ata1:  on atapci0
ata1: [ITHREAD]
uhci0:  port 0xc020-0xc03f irq 11 at 
device 1.2 on pci0
uhci0: [ITHREAD]
usbus0: controller did not stop
usbus0:  on uhci0
pci0:  at device 1.3 (no driver attached)
vgapci0:  mem 
0xc200-0xc3ff,0xc400-0xc4000fff at device 2.0 on pci0
re0:  port 0xc100-0xc1ff mem 0xc4001000-0xc40010ff 
irq 11 at device 3.0 on pci0
re0: Chip rev. 0x7480
re0: MAC rev. 0x
miibus0:  on re0
rlphy0:  PHY 0 on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
re0: Ethernet address: 54:52:00:78:4a:3e
re0: [FILTER]
pci0:  at device 4.0 (no driver attached)
atrtc0:  port 0x70-0x71,0x72-0x77 irq 8 on acpi0
atrtc0: [FILTER]
Event timer "RTC" frequency 32768 Hz quality 0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse Explorer, device ID 4
fdc0:  port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: does not respond
device_attach: fdc0 attach returned 6
uart0:  port 0x3f8-0x3ff irq 4 flags 
0x10 on acpi0
uart0: [FILTER]
uart0: console (9600,n,8,1)
pmtimer0 on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x100>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
attimer0:  at port 0x40 on isa0
Timecounter "i8254" frequency 1193182 Hz quality 0
attimer0: Can't map interrupt.
ppc0: parallel port not found.
Timecounter "TSC" frequency 2667064832 Hz quality 800
Starting kernel event timers: LAPIC @ 100Hz, RTC @ 128Hz
Timecounters tick every 10.000 msec
md0: Preloaded image  4423680 bytes at 0xc1186af4
usbus0: 12Mbps Full Speed USB v1.0
ad0: 10240MB  at ata0-master WDMA2
ugen0.1:  at usbus0
uhub0:  on usbus0
acd0: CDROM  at ata1-master WDMA2
WARNING: WITNESS option enabled, expect reduced performance.
Root mount waiting for: usbus0
uhub0: 2 ports with 2 removable, self powered
Trying to mount root from ufs:/dev/md0


-- 
Jeremie Le Hen

Humans are born free and equal.  But some are more equal than others.
Coluche
___
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: Broadcom 4315 not working

2010-09-07 Thread Warren Block 

On Tue, 7 Sep 2010, Baby Boy wrote:


Today I MFCed a patch for LP PHY devices to STABLE_8.
Could you please test with latest?


??.


!!


One thing you can test is that using PIO mode. Thank you.


Please tell my how I do it?


Add to /boot/loader.conf:
  hw.bwn.usedma=0
___
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: FreeBSD 6.4 and 8.0 EoLs coming soon

2010-09-07 Thread Julian H. Stacey 
> P.S. why is security@ in cc: ?


Original announcement:
> Message-id: <4c7e71dc.1040...@freebsd.org>
> From: FreeBSD Security Officer 
> Date: Wed, 01 Sep 2010 08:31:40 -0700 (17:31 CEST)
> To: FreeBSD Stable ,
>   freebsd security 

All respondents (I happened to be first, Wed, 01 Sep 2010 18:09:33
+0200) retained stable@ & security@

Wed, 01 Sep 2010 21:36:02 +0200 I added:
> i...@freebsd.org : I just re-subscribed (used to be on long ago)

Now it's know Hans Petter Selasky  has a code
stack to try, &  Robert Watson has posted it'd be welcome ... etc,
I guess its up to us ISDN users to install, try, & discuss on a new
thread on isdn@

Cheers,
Julian
-- 
Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
 Mail plain text,  Not HTML, quoted-printable & base 64 dumped with spam.
Avoid top posting, It cripples itemised cumulative responses.
___
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: FreeBSD 6.4 and 8.0 EoLs coming soon

2010-09-07 Thread Andriy Gapon 
on 07/09/2010 13:38 Vadim Goncharov said the following:
>> Just to clarify things a little for those following it: the original I4B 
>> code 
>> was removed for entirely practical reasons: it couldn't run without the 
>> Giant 
>> lock, and support for the Giant lock over the network stack was removed.
> 
> But if it was used, removing a component just because of Giant lock is not
> practical and is purely ideologic, isn't it?

Which part of "support for the Giant lock *over the network stack* was removed"
[emphasis mine] do you not understand?
The reason is performance for overall network stack, not ideology.

BTW, there were advanced notices for users, request for volunteers, etc.

So, if you didn't speak up at that time please keep silence now :-)

P.S. why is security@ in cc: ?

-- 
Andriy Gapon
___
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: Broadcom 4315 not working

2010-09-07 Thread Baby Boy 



Today I MFCed a patch for LP PHY devices to STABLE_8.
Could you please test with latest?


ОК.


!!


One thing you can test is that using PIO mode. Thank you.


Please tell my how I do it?
___
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: FreeBSD 6.4 and 8.0 EoLs coming soon

2010-09-07 Thread Vadim Goncharov 
Hi Robert Watson! 

On Sun, 5 Sep 2010 11:47:29 +0100 (BST); Robert Watson wrote about 'Re: HEADS 
UP: FreeBSD 6.4 and 8.0 EoLs coming soon':

>>> It seems code exists :-)
>>>
>>> http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html
>>> ISDN4BSD package has been updated to compile on FreeBSD
>>> 8-current
>>>
>>> http://www.selasky.org/hans_petter/isdn4bsd/
>>>
>>> Apparently needs massaging into main FreeBSD tree.
>>
>> I agree that my I4B code should be re-written somewhat before committed. 
>> Possibly we should update the API's present too, to support IP-telephony 
>> aswell.
> Just to clarify things a little for those following it: the original I4B code 
> was removed for entirely practical reasons: it couldn't run without the Giant 
> lock, and support for the Giant lock over the network stack was removed.

But if it was used, removing a component just because of Giant lock is not
practical and is purely ideologic, isn't it?

-- 
WBR, Vadim Goncharov. ICQ#166852181   mailto:vadim_nucli...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]

___
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: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.

2010-09-07 Thread Andriy Gapon 
on 06/09/2010 22:05 jhell said the following:
> On 09/03/2010 20:14, David Xu wrote:
>> I think sysctl kern.sched.preempt_thresh is too low, default is only
>> 64. I always tune it up to 200 on  my desktop machine which is
>> running gnome and other GUI applications, for a heavy GUI deskkop, I
>> would tune it up to 224 to get better result.
>>
> 
> For reference how did you arrive at 224 for a result ?

As Jeremy has already discovered, take a look at sys/sys/priority.h, especially
PRI_MIN_IDLE.


-- 
Andriy Gapon
___
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 for topology detection of Intel CPUs

2010-09-07 Thread Andriy Gapon 
on 06/09/2010 21:53 Chip Camden said the following:
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs

Thanks

-- 
Andriy Gapon
___
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: wpa_supplicant does not create pidfile

2010-09-07 Thread Mark Andrews 

In message <4c85e638.4070...@bsdforen.de>, Dominic Fandrey writes:
> On 07/09/2010 09:09, Bernhard Schmidt wrote:
> > On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote:
> >> On 07/09/2010 08:50, Bernhard Schmidt wrote:
> >>> On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote:
>  On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey  
> > wrote:
> > On 27/08/2010 09:28, Bernhard Schmidt wrote:
> >> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey 
> >>>
> >>> wrote:
> >>> wpa_supplicant doesn't create the pidfile if the target directory
> >>> does not exist. Because /var/run is wiped with every boot I added
> >>> the following line to my rc.local to workaround this issue:
> >>>
> >>> /bin/mkdir -p /var/run/wpa_supplicant
> >>>
> >>> I'm running RELENG_8.
> >>
> >> How about this?
> >>
> >> Index: etc/mtree/BSD.var.dist
> >> ===
> >> --- etc/mtree/BSD.var.dist>.(revision 211568)
> >> +++ etc/mtree/BSD.var.dist>.(working copy)
> >> @@ -64,6 +64,8 @@
> >>
> >>  ..
> >>  ppp gname=network mode=0770
> >>  ..
> >>
> >> +wpa_supplicant
> >> +..
> >>
> >>  ..
> >>  rwhogname=daemon mode=0775
> >>  ..
> >
> > Is the mtree built every time the system boots? Because my /var/run
> > is a tmpfs. And even if it wasn't, I think it's wiped every boot
> > any way.
> 
>  Not build but, according to /etc/rc.d/var mtree is run on every boot.
>  I actually tried that and it works just fine.
> >>>
> >>> Did you have a chance to try this? Given positive feedback I'd like to
> >>> commit it.
> >>
> >> No, doesn't work. The named and ppp directories also don't exist.
> >>
> >> Sorry about the delay.
> > 
> > Ok, thanks.
> > 
> > Is it only /var/run/* that is wiped for you, or /var/* itself? I just check
> ed 
> > rc.d/var and it looks like this:
> > if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then
> > true
> > elif [ -x /usr/sbin/mtree ] ; then
> > populate_var
> > 
> > So.. if var/run does exist, populate_var isn't run.
> > 
> 
> Only /var/run and /var/log are tmpfs (notebook, reduce HD access
> to allow HD spindown). I wouldn't wipe my /var/db every boot.

Then /var/run must exist as it is a mount point.

> Regards
> 
> -- 
> A: Because it fouls the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail? 
> ___
> 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"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.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: wpa_supplicant does not create pidfile

2010-09-07 Thread Bernhard Schmidt 
On Tuesday, September 07, 2010 09:14:00 Dominic Fandrey wrote:
> On 07/09/2010 09:09, Bernhard Schmidt wrote:
> > On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote:
> >> On 07/09/2010 08:50, Bernhard Schmidt wrote:
> >>> On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote:
>  On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey 
> > 
> > wrote:
> > On 27/08/2010 09:28, Bernhard Schmidt wrote:
> >> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey
> >> 
> >>> 
> >>> wrote:
> >>> wpa_supplicant doesn't create the pidfile if the target directory
> >>> does not exist. Because /var/run is wiped with every boot I added
> >>> the following line to my rc.local to workaround this issue:
> >>> 
> >>> /bin/mkdir -p /var/run/wpa_supplicant
> >>> 
> >>> I'm running RELENG_8.
> >> 
> >> How about this?
> >> 
> >> Index: etc/mtree/BSD.var.dist
> >> ===
> >> --- etc/mtree/BSD.var.dist>.(revision 211568)
> >> +++ etc/mtree/BSD.var.dist>.(working copy)
> >> @@ -64,6 +64,8 @@
> >> 
> >>  ..
> >>  ppp gname=network mode=0770
> >>  ..
> >> 
> >> +wpa_supplicant
> >> +..
> >> 
> >>  ..
> >>  rwhogname=daemon mode=0775
> >>  ..
> > 
> > Is the mtree built every time the system boots? Because my /var/run
> > is a tmpfs. And even if it wasn't, I think it's wiped every boot
> > any way.
>  
>  Not build but, according to /etc/rc.d/var mtree is run on every boot.
>  I actually tried that and it works just fine.
> >>> 
> >>> Did you have a chance to try this? Given positive feedback I'd like to
> >>> commit it.
> >> 
> >> No, doesn't work. The named and ppp directories also don't exist.
> >> 
> >> Sorry about the delay.
> > 
> > Ok, thanks.
> > 
> > Is it only /var/run/* that is wiped for you, or /var/* itself? I just
> > checked
> > 
> > rc.d/var and it looks like this:
> > if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then
> > 
> > true
> > 
> > elif [ -x /usr/sbin/mtree ] ; then
> > 
> > populate_var
> > 
> > So.. if var/run does exist, populate_var isn't run.
> 
> Only /var/run and /var/log are tmpfs (notebook, reduce HD access
> to allow HD spindown). I wouldn't wipe my /var/db every boot.

Ah, ok, that explains it. Try with populate_var=YES in rc.conf and it should 
create all directories under var/run.

-- 
Bernhard
___
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: wpa_supplicant does not create pidfile

2010-09-07 Thread Dominic Fandrey 
On 07/09/2010 09:09, Bernhard Schmidt wrote:
> On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote:
>> On 07/09/2010 08:50, Bernhard Schmidt wrote:
>>> On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote:
 On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey  
> wrote:
> On 27/08/2010 09:28, Bernhard Schmidt wrote:
>> On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey 
>>>
>>> wrote:
>>> wpa_supplicant doesn't create the pidfile if the target directory
>>> does not exist. Because /var/run is wiped with every boot I added
>>> the following line to my rc.local to workaround this issue:
>>>
>>> /bin/mkdir -p /var/run/wpa_supplicant
>>>
>>> I'm running RELENG_8.
>>
>> How about this?
>>
>> Index: etc/mtree/BSD.var.dist
>> ===
>> --- etc/mtree/BSD.var.dist>.(revision 211568)
>> +++ etc/mtree/BSD.var.dist>.(working copy)
>> @@ -64,6 +64,8 @@
>>
>>  ..
>>  ppp gname=network mode=0770
>>  ..
>>
>> +wpa_supplicant
>> +..
>>
>>  ..
>>  rwhogname=daemon mode=0775
>>  ..
>
> Is the mtree built every time the system boots? Because my /var/run
> is a tmpfs. And even if it wasn't, I think it's wiped every boot
> any way.

 Not build but, according to /etc/rc.d/var mtree is run on every boot.
 I actually tried that and it works just fine.
>>>
>>> Did you have a chance to try this? Given positive feedback I'd like to
>>> commit it.
>>
>> No, doesn't work. The named and ppp directories also don't exist.
>>
>> Sorry about the delay.
> 
> Ok, thanks.
> 
> Is it only /var/run/* that is wiped for you, or /var/* itself? I just checked 
> rc.d/var and it looks like this:
> if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then
> true
> elif [ -x /usr/sbin/mtree ] ; then
> populate_var
> 
> So.. if var/run does exist, populate_var isn't run.
> 

Only /var/run and /var/log are tmpfs (notebook, reduce HD access
to allow HD spindown). I wouldn't wipe my /var/db every boot.

Regards

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 
___
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: wpa_supplicant does not create pidfile

2010-09-07 Thread Bernhard Schmidt 
On Tuesday, September 07, 2010 09:01:18 Dominic Fandrey wrote:
> On 07/09/2010 08:50, Bernhard Schmidt wrote:
> > On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote:
> >> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey  
wrote:
> >>> On 27/08/2010 09:28, Bernhard Schmidt wrote:
>  On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey 
> > 
> > wrote:
> > wpa_supplicant doesn't create the pidfile if the target directory
> > does not exist. Because /var/run is wiped with every boot I added
> > the following line to my rc.local to workaround this issue:
> > 
> > /bin/mkdir -p /var/run/wpa_supplicant
> > 
> > I'm running RELENG_8.
>  
>  How about this?
>  
>  Index: etc/mtree/BSD.var.dist
>  ===
>  --- etc/mtree/BSD.var.dist>.(revision 211568)
>  +++ etc/mtree/BSD.var.dist>.(working copy)
>  @@ -64,6 +64,8 @@
>  
>   ..
>   ppp gname=network mode=0770
>   ..
>  
>  +wpa_supplicant
>  +..
>  
>   ..
>   rwhogname=daemon mode=0775
>   ..
> >>> 
> >>> Is the mtree built every time the system boots? Because my /var/run
> >>> is a tmpfs. And even if it wasn't, I think it's wiped every boot
> >>> any way.
> >> 
> >> Not build but, according to /etc/rc.d/var mtree is run on every boot.
> >> I actually tried that and it works just fine.
> > 
> > Did you have a chance to try this? Given positive feedback I'd like to
> > commit it.
> 
> No, doesn't work. The named and ppp directories also don't exist.
> 
> Sorry about the delay.

Ok, thanks.

Is it only /var/run/* that is wiped for you, or /var/* itself? I just checked 
rc.d/var and it looks like this:
if [ -d /var/run -a -d /var/db -a -d /var/empty ] ; then
true
elif [ -x /usr/sbin/mtree ] ; then
populate_var

So.. if var/run does exist, populate_var isn't run.

-- 
Bernhard
___
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: wpa_supplicant does not create pidfile

2010-09-07 Thread Dominic Fandrey 
On 07/09/2010 08:50, Bernhard Schmidt wrote:
> On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote:
>> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey  wrote:
>>> On 27/08/2010 09:28, Bernhard Schmidt wrote:
 On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey  
> wrote:
> wpa_supplicant doesn't create the pidfile if the target directory
> does not exist. Because /var/run is wiped with every boot I added
> the following line to my rc.local to workaround this issue:
>
> /bin/mkdir -p /var/run/wpa_supplicant
>
> I'm running RELENG_8.

 How about this?

 Index: etc/mtree/BSD.var.dist
 ===
 --- etc/mtree/BSD.var.dist>.(revision 211568)
 +++ etc/mtree/BSD.var.dist>.(working copy)
 @@ -64,6 +64,8 @@
  ..
  ppp gname=network mode=0770
  ..
 +wpa_supplicant
 +..
  ..
  rwhogname=daemon mode=0775
  ..
>>>
>>> Is the mtree built every time the system boots? Because my /var/run
>>> is a tmpfs. And even if it wasn't, I think it's wiped every boot
>>> any way.
>>
>> Not build but, according to /etc/rc.d/var mtree is run on every boot.
>> I actually tried that and it works just fine.
> 
> Did you have a chance to try this? Given positive feedback I'd like to commit 
> it.
> 

Just had this idea, that it might be run, before the tmpfs is
mounted. Seems unlikely, though.

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 
___
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: wpa_supplicant does not create pidfile

2010-09-07 Thread Dominic Fandrey 
On 07/09/2010 08:50, Bernhard Schmidt wrote:
> On Friday, August 27, 2010 09:42:30 Bernhard Schmidt wrote:
>> On Fri, Aug 27, 2010 at 09:36, Dominic Fandrey  wrote:
>>> On 27/08/2010 09:28, Bernhard Schmidt wrote:
 On Sun, Aug 22, 2010 at 19:50, Dominic Fandrey  
> wrote:
> wpa_supplicant doesn't create the pidfile if the target directory
> does not exist. Because /var/run is wiped with every boot I added
> the following line to my rc.local to workaround this issue:
>
> /bin/mkdir -p /var/run/wpa_supplicant
>
> I'm running RELENG_8.

 How about this?

 Index: etc/mtree/BSD.var.dist
 ===
 --- etc/mtree/BSD.var.dist>.(revision 211568)
 +++ etc/mtree/BSD.var.dist>.(working copy)
 @@ -64,6 +64,8 @@
  ..
  ppp gname=network mode=0770
  ..
 +wpa_supplicant
 +..
  ..
  rwhogname=daemon mode=0775
  ..
>>>
>>> Is the mtree built every time the system boots? Because my /var/run
>>> is a tmpfs. And even if it wasn't, I think it's wiped every boot
>>> any way.
>>
>> Not build but, according to /etc/rc.d/var mtree is run on every boot.
>> I actually tried that and it works just fine.
> 
> Did you have a chance to try this? Given positive feedback I'd like to commit 
> it.
> 

No, doesn't work. The named and ppp directories also don't exist.

Sorry about the delay.

Regards

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 
___
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"