Re: iwn firmware instability with an up-to-date stable kernel

2010-04-18 Thread Bernhard Schmidt 
On Sun, Apr 18, 2010 at 03:49:14AM +0200, Olivier Cochard-Labbé wrote:
> Hi,
> 
> I meet instability with an up-to-date stable 8 kernel and iwn drivers:
> About twice a day, my wireless connection hang and I've this error
> message in dmesg:
> 
> firmware error log:
>   error type  = "NMI_INTERRUPT_WDG" (0x0004)
>   program counter = 0x046C
>   source line = 0x00D0
>[..]
> 
> Does anyone meet the same problem ?

I've seen this error a few times, even Intel knows about it:
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1965
Issue is that there is no known workaround.

Are you able to reproduce this on demand? As in type a few commands and
the firmware error occurs?

-- 
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: ath0: kernel panic when adhoc mode.

2010-04-18 Thread Paul B Mahol 
On 4/14/10, Lystopad Olexandr  wrote:
> Hi!
>
> I install 8.0 FreeBSD, upgrade it to yesturday stable.
> I need to create wireless link in adhoc mode.
> Help me to do this.
>
>
> I put a wireless card into this box:
>
> a...@pci0:3:3:0:class=0x02 card=0xcc2114b9 chip=0x0013168c
> rev=0x01 hdr=0x00
> vendor = 'Atheros Communications Inc.'
> device = '802.11a/b/g Wireless Adapter (AR5212)'
> class  = network
> subclass   = ethernet
> cap 01[44] = powerspec 2  supports D0 D3  current D0
>
>
>
> when I do:
> # ifconfig wlan0 create wlandev ath0 wlanmode adhoc
>
> server reboot with kernel panic:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address   = 0x
> fault code  = supervisor read, page not present
> instruction pointer = 0x20:0xc0791612
> stack pointer   = 0x28:0xd2f42ba4
> frame pointer   = 0x28:0xd2f42bac
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 0 (ath0 taskq)
> trap number = 12
> panic: page fault
> cpuid = 1
> Uptime: 3m35s
> Physical memory: 439 MB
> Dumping 80 MB: 65 49 33panic: bufwrite: buffer is not busy???
> cpuid = 1
>  17 1
>
> #0  doadump () at pcpu.h:246
> 246 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0  doadump () at pcpu.h:246
> #1  0xc06b3497 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
> #2  0xc06b3789 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:579
> #3  0xc08b63bc in trap_fatal (frame=0xd2f42b64, eva=65535)
> at /usr/src/sys/i386/i386/trap.c:938
> #4  0xc08b6620 in trap_pfault (frame=0xd2f42b64, usermode=0, eva=65535)
> at /usr/src/sys/i386/i386/trap.c:851
> #5  0xc08b6f39 in trap (frame=0xd2f42b64) at
> /usr/src/sys/i386/i386/trap.c:533
> #6  0xc0899b3b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
> #7  0xc0791612 in ieee80211_getcapinfo (vap=0xc2d5f000, chan=0x)
> at /usr/src/sys/net80211/ieee80211_output.c:1836
> #8  0xc0793d17 in ieee80211_beacon_construct (m=0xc2edca00,
> frm=0xc2f0516e "", bo=0xc2d5f884, ni=0xc2ceb000)
> at /usr/src/sys/net80211/ieee80211_output.c:2559
> #9  0xc07946db in ieee80211_beacon_alloc (ni=0xc2ceb000, bo=0xc2d5f884)
> at /usr/src/sys/net80211/ieee80211_output.c:2756
> #10 0xc050eaea in ath_newstate (vap=0xc2d5f000, nstate=IEEE80211_S_RUN,
> arg=-1) at /usr/src/sys/dev/ath/if_ath.c:2641
> #11 0xc0798db1 in ieee80211_newstate_cb (xvap=0xc2d5f000, npending=3)
> at /usr/src/sys/net80211/ieee80211_proto.c:1654
> #12 0xc06ebf92 in taskqueue_run (queue=0xc2a84c80)
> at /usr/src/sys/kern/subr_taskqueue.c:239
> #13 0xc06ec19d in taskqueue_thread_loop (arg=0xc2ada074)
> at /usr/src/sys/kern/subr_taskqueue.c:360
> #14 0xc068a331 in fork_exit (callout=0xc06ec0e0 ,
> arg=0xc2ada074, frame=0xd2f42d38) at /usr/src/sys/kern/kern_fork.c:843
> #15 0xc0899bb0 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:270
> (kgdb)
>

This is bug, please report it ASAP.
>
>
>
> dmesg is:
>
> 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 8.0-STABLE #0: Wed Apr 14 07:45:45 MSD 2010
> r...@serv01:/usr/obj/usr/src/sys/serv01 i386
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.76-MHz 686-class
> CPU)
>   Origin = "AuthenticAMD"  Id = 0x40fb2  Family = f  Model = 4b  Stepping =
> 2
>
> Features=0x178bfbff
>   Features2=0x2001
>   AMD Features=0xea500800
>   AMD Features2=0x1f
> real memory  = 536870912 (512 MB)
> avail memory = 449187840 (428 MB)
> ACPI APIC Table: <050407 APIC1334>
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s)
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
> ioapic0  irqs 0-23 on motherboard
> kbd1 at kbdmux0
> acpi0: <050407 RSDT1334> on motherboard
> acpi0: [ITHREAD]
> acpi0: Power Button (fixed)
> acpi0: reservation of fee0, 1000 (3) failed
> acpi0: reservation of ffb8, 8 (3) failed
> acpi0: reservation of fff8, 8 (3) failed
> acpi0: reservation of 0, a (3) failed
> acpi0: reservation of 10, 1bf0 (3) failed
> ACPI HPET table warning: Sequence is non-zero (2)
> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> cpu0:  on acpi0
> cpu1:  on acpi0
> acpi_hpet0:  iomem 0xfed0-0xfed003ff on
> acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 900
> pcib0:  port 0xcf8-0xcff on acpi0
> pci0:  on pcib0
> pcib1:  at device 1.0 on pci0
> pci1:  on pcib1
> v

Re: panic: vm_fault_copy_wired: page missing

2010-04-18 Thread Daniel Braniss 
> > > 
> > > --QA3RSaXxDkY7tjDy
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Disposition: inline
> > > Content-Transfer-Encoding: quoted-printable
> > > 
> > > On Thu, Apr 15, 2010 at 02:54:19PM +0300, Daniel Braniss wrote:
> > > >=20
> > > > > Take NFS out of the picture if you can...
> > > > >=20
> > > > I've been thinking along those lines, and Kostic is convinced
> > > > that the problem lies there, so I guess I'll give it a try, but
> > > > it's no realy a solution.
> > > 
> > > Better solution is to remove mlock()/mlockall().
> > 
> > without binaries via NFS there is no panic.
> > 
> > I can't remove mlock()/mlockall() since it's not my program, it's apache 
> > et.all.
> > but, while my knowledge of dtrace is almost zero, I did the next best thing
> > and put a printf in mlock/mlockall and they are not being called by 
> > userland.
> > 
> > so, it seems the problem is nfs related, calling in the heavy-weights,
> > hi rick!
> 
> well, Kostic was right after all. It was am-utils that called mlockall(),
> I missed the message first time, commented out the call to mlockall, and the
> system is not panicking.
> 
> so there is a problem with mlock and nfs, can this be fixed? is there a pr?
> 
> anyways, thank you all!
> 
> danny

I placed amd(am-utils) on local disc, and it still panics - slightly 
differently:

KDB: enter: panic
[thread pid 1029 tid 100098 ]
Stopped at  kdb_enter+0x3d: movq$0,0x68f7a0(%rip)
db> tr
Tracing pid 1029 tid 100098 td 0xff0007502000
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x17b
vm_fault_copy_entry() at vm_fault_copy_entry+0x283
vmspace_fork() at vmspace_fork+0x4d0
fork1() at fork1+0x35f
fork() at fork+0x1c
syscall() at syscall+0x1e7
Xfast_syscall() at Xfast_syscall+0xe1
--- syscall (2, FreeBSD ELF64, fork), rip = 0x8009f41ac, rsp = 0x7fffe788, 
rbp = 0 ---

so IMHO, the problem is somewhere in the fact that root is diskless.

danny


___
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: iwn firmware instability with an up-to-date stable kernel

2010-04-18 Thread Olivier Cochard-Labbé 
2010/4/18 Bernhard Schmidt :
> Are you able to reproduce this on demand? As in type a few commands and
> the firmware error occurs?
>

No, I'm not able to reproduce on demand this problem.

Regards,

Olivier
___
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: panic: vm_fault_copy_wired: page missing

2010-04-18 Thread Kostik Belousov 
On Sun, Apr 18, 2010 at 01:21:26PM +0300, Daniel Braniss wrote:
> > > > 
> > > > --QA3RSaXxDkY7tjDy
> > > > Content-Type: text/plain; charset=us-ascii
> > > > Content-Disposition: inline
> > > > Content-Transfer-Encoding: quoted-printable
> > > > 
> > > > On Thu, Apr 15, 2010 at 02:54:19PM +0300, Daniel Braniss wrote:
> > > > >=20
> > > > > > Take NFS out of the picture if you can...
> > > > > >=20
> > > > > I've been thinking along those lines, and Kostic is convinced
> > > > > that the problem lies there, so I guess I'll give it a try, but
> > > > > it's no realy a solution.
> > > > 
> > > > Better solution is to remove mlock()/mlockall().
> > > 
> > > without binaries via NFS there is no panic.
> > > 
> > > I can't remove mlock()/mlockall() since it's not my program, it's apache 
> > > et.all.
> > > but, while my knowledge of dtrace is almost zero, I did the next best 
> > > thing
> > > and put a printf in mlock/mlockall and they are not being called by 
> > > userland.
> > > 
> > > so, it seems the problem is nfs related, calling in the heavy-weights,
> > > hi rick!
> > 
> > well, Kostic was right after all. It was am-utils that called mlockall(),
> > I missed the message first time, commented out the call to mlockall, and the
> > system is not panicking.
> > 
> > so there is a problem with mlock and nfs, can this be fixed? is there a pr?
> > 
> > anyways, thank you all!
> > 
> > danny
> 
> I placed amd(am-utils) on local disc, and it still panics - slightly 
> differently:
> 
> KDB: enter: panic
> [thread pid 1029 tid 100098 ]
> Stopped at  kdb_enter+0x3d: movq$0,0x68f7a0(%rip)
> db> tr
> Tracing pid 1029 tid 100098 td 0xff0007502000
> kdb_enter() at kdb_enter+0x3d
> panic() at panic+0x17b
> vm_fault_copy_entry() at vm_fault_copy_entry+0x283
> vmspace_fork() at vmspace_fork+0x4d0
> fork1() at fork1+0x35f
> fork() at fork+0x1c
> syscall() at syscall+0x1e7
> Xfast_syscall() at Xfast_syscall+0xe1
> --- syscall (2, FreeBSD ELF64, fork), rip = 0x8009f41ac, rsp = 
> 0x7fffe788, 
> rbp = 0 ---
> 
> so IMHO, the problem is somewhere in the fact that root is diskless.

Root on nfs means that e.g. libc is still mapped from nfs mount.


pgpJjizBE5gvU.pgp
Description: PGP signature

Re: panic: vm_fault_copy_wired: page missing

2010-04-18 Thread Daniel Braniss 
> 
> --SpFw69Q4vVW19Q1W
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Sun, Apr 18, 2010 at 01:21:26PM +0300, Daniel Braniss wrote:
> > > > >=20
> > > > > --QA3RSaXxDkY7tjDy
> > > > > Content-Type: text/plain; charset=3Dus-ascii
> > > > > Content-Disposition: inline
> > > > > Content-Transfer-Encoding: quoted-printable
> > > > >=20
> > > > > On Thu, Apr 15, 2010 at 02:54:19PM +0300, Daniel Braniss wrote:
> > > > > >=3D20
> > > > > > > Take NFS out of the picture if you can...
> > > > > > >=3D20
> > > > > > I've been thinking along those lines, and Kostic is convinced
> > > > > > that the problem lies there, so I guess I'll give it a try, but
> > > > > > it's no realy a solution.
> > > > >=20
> > > > > Better solution is to remove mlock()/mlockall().
> > > >=20
> > > > without binaries via NFS there is no panic.
> > > >=20
> > > > I can't remove mlock()/mlockall() since it's not my program, it's apa=
> che=20
> > > > et.all.
> > > > but, while my knowledge of dtrace is almost zero, I did the next best=
>  thing
> > > > and put a printf in mlock/mlockall and they are not being called by u=
> serland.
> > > >=20
> > > > so, it seems the problem is nfs related, calling in the heavy-weights,
> > > > hi rick!
> > >=20
> > > well, Kostic was right after all. It was am-utils that called mlockall(=
> ),
> > > I missed the message first time, commented out the call to mlockall, an=
> d the
> > > system is not panicking.
> > >=20
> > > so there is a problem with mlock and nfs, can this be fixed? is there a=
>  pr?
> > >=20
> > > anyways, thank you all!
> > >=20
> > > danny
> >=20
> > I placed amd(am-utils) on local disc, and it still panics - slightly=20
> > differently:
> >=20
> > KDB: enter: panic
> > [thread pid 1029 tid 100098 ]
> > Stopped at  kdb_enter+0x3d: movq$0,0x68f7a0(%rip)
> > db> tr
> > Tracing pid 1029 tid 100098 td 0xff0007502000
> > kdb_enter() at kdb_enter+0x3d
> > panic() at panic+0x17b
> > vm_fault_copy_entry() at vm_fault_copy_entry+0x283
> > vmspace_fork() at vmspace_fork+0x4d0
> > fork1() at fork1+0x35f
> > fork() at fork+0x1c
> > syscall() at syscall+0x1e7
> > Xfast_syscall() at Xfast_syscall+0xe1
> > --- syscall (2, FreeBSD ELF64, fork), rip =3D 0x8009f41ac, rsp =3D 0x7fff=
> e788,=20
> > rbp =3D 0 ---
> >=20
> > so IMHO, the problem is somewhere in the fact that root is diskless.
> 
> Root on nfs means that e.g. libc is still mapped from nfs mount.

argh, forgot about shared libs, so I linked amd static, and it's not panicking,
yet ... [amd is in the root nfs].


___
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: panic: vm_fault_copy_wired: page missing

2010-04-18 Thread Daniel Braniss 
...
> > > so IMHO, the problem is somewhere in the fact that root is diskless.
> > 
> > Root on nfs means that e.g. libc is still mapped from nfs mount.
> 
> argh, forgot about shared libs, so I linked amd static, and it's not 
> panicking,
> yet ... [amd is in the root nfs].

it just panicked :-(


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

Ynv Records Presents

2010-04-18 Thread YNV Records 
Since 2003, the latino community, along with other races, have been enjoying a 
different type of music thanks to D.R-FLOW. The Group , which is comprised of 2 
very talented youths , Ezequiel Rodriguez and Manuel Vasquez, represent 
Dominicans, in and out of the Dominican Republic in a big way.

Ever since the very beginnings of the group, these bright and talented young 
men have received the love and support of, not only the latino population, but 
also other races all over the world . Their music reaches from the streets of 
New York, to the hearts of many in South America, Europe, and beyond!!! They 
are well-recieved where ever they go because of the diversity of their music, 
from hip-hop to r&b, fans get the opportunity to take away a little bit of 
every genre of music known today.
For More info Regarding Drops, jingle Interviews Or For bookings 
413-363-4388
Moe
View this email on the web here:
http://mim.io/e9d53?fe=1&pact=958917923
Unsubscribe:
http://go.madmimi.com/opt_out?fe=1&pact=958917923&amx=224345343
You can also forward to a friend:
http://go.madmimi.com/forward/958917923?amx=224345343

YNV Records | Boston Ma 02128
___
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"

Ynv Records Presents

2010-04-18 Thread YNV Records 
Since 2003, the latino community, along with other races, have been enjoying a 
different type of music thanks to D.R-FLOW. The Group , which is comprised of 2 
very talented youths , Ezequiel Rodriguez and Manuel Vasquez, represent 
Dominicans, in and out of the Dominican Republic in a big way.

Ever since the very beginnings of the group, these bright and talented young 
men have received the love and support of, not only the latino population, but 
also other races all over the world . Their music reaches from the streets of 
New York, to the hearts of many in South America, Europe, and beyond!!! They 
are well-recieved where ever they go because of the diversity of their music, 
from hip-hop to r&b, fans get the opportunity to take away a little bit of 
every genre of music known today.
For More info Regarding Drops, jingle Interviews Or For bookings 
413-363-4388
Moe
View this email on the web here:
http://mim.io/e9d53?fe=1&pact=958923032
Unsubscribe:
http://go.madmimi.com/opt_out?fe=1&pact=958923032&amx=224345464
You can also forward to a friend:
http://go.madmimi.com/forward/958923032?amx=224345464

YNV Records | Boston Ma 02128
___
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"

rc(8) script -- waiting for the network to become usable

2010-04-18 Thread Jeremy Chadwick 
I'd like to discuss the possibility of introduction of a new script into
/etc/rc.d base system a script, which when enabled, would provide a way
to wait until the IP networking layer (using ping(8)) is up and usable
before continuing with daemon startup.

I've written a script that's in use on all of our RELENG_8 systems (I
have not tested RELENG_7) which works reliably; I'll include that script
at the bottom of my mail, and also a link to it[1].

Let's discuss.  :-)


HISTORY
=
The situation which brought this debacle to my attention:

I found that on reboot of some of our systems, ntpdate (used to sync the
clock initially before ntpd would be started) wouldn't work.  The daemon
would report that it couldn't resolve any of the FQDNs within ntp.conf,
and would therefore act as a no-op before continuing on.

This failure had dire consequences -- Dovecot (at least with older
versions; newer seems to behave better[2]) would refuse to start up,
citing "time moved backwards".  Dovecot not starting had a trick-down
effect on Postfix (which was compiled to use Dovecot for SMTP AUTH),
where Postfix would start but all inbound mail would fail due to
Dovecot's SMTP AUTH mech not listening on a domain socket.  Ouch.

Since DNS failure was the root issue, I dug around rc.d/named and found
that Doug had introduced a feature to rc.d/named called "named_wait"
which calls "host $named_wait_host" repetitively (sleeping 1 second
between calls), waiting until successful resolution before continuing
onwards.  This worked (e.g. set named_wait_host to "www.google.com" or
something Internet-bound).

However, named itself still complains during startup about "host
unreachable resolving XXX messages" with regards to the root servers.
These errors were visible in logs, etc... and could cause confusion or
unnecessary worry (they did in my case).

The root cause should be fairly obvious: the physical networking layer
hadn't fully come up by the time named had started.  In other cases, the
physical network was available but layer 2 (ARP) hadn't finished.

So I wrote this.


USE
=
1) Install script as /usr/local/etc/rc.d/waitnetwork
2) chmod 755 /usr/local/etc/rc.d/waitnetwork
3) Set the following in rc.conf:

waitnetwork_enable="yes"
waitnetwork_ip="some_ip_addr_to_ping"

Note that this does need to be an IP address and *not* an FQDN.  I've
discussed this reasoning with some others and they agree.  Don't pick
something like 127.0.0.1 either (meaning don't be silly).  :-)

Other parameters you can adjust:

waitnetwork_count   -- passed as ping(8) -c flag  (default 5)
waitnetwork_timeout -- passed as ping(8) -t flag  (default 60)


CAVEATS / POINTS OF INTEREST
==
1) This script requires the $waitnetwork_ip box/router/whatever respond
to ICMP ECHO requests.  Please do not bikeshed on this point; we need
something that works, and this requirement shouldn't be that bad to deal
with (firewall/ACL-wise).  For most folks (co-located in particular),
this could be your default gateway, but you can use whatever you want.

2) The needs of some folks may vary depending upon configuration; "we
have two NICs, dual-homed, so what exactly do I put in waitnetwork_ip?"
Yes, I understand the confusion -- hopefully these folks, given their
topologies, can figure out a way to make this work reliably for them.

3) Other stuff I probably haven't thought of.

For those considering arguing that "we should just wait for the NIC to
come up", that won't work -- what's needed is a way to verify layer 3/4
is usable, not layer 1.

I admit there's no universal way to cover every single person's needs,
but providing a simple framework to at least wait until something is
pingable would be a good starting point; it's better than nothing!


NOTES BEFORE COMMITTING
=
The script also contains some XXX comments which should be reviewed by
anyone willing to commit this into the base system.


REFERENCES

[1]: http://jdc.parodius.com/freebsd/waitnetwork
[2]: http://wiki.dovecot.org/TimeMovedBackwards

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


#!/bin/sh
#
# $FreeBSD: $
#

# PROVIDE: waitnetwork
# REQUIRE: NETWORKING
# BEFORE: mountcritremote
# KEYWORD: nojail

# XXX - once/if committed to base, it's better to have mountcritremote
# XXX - REQUIRE waitnetwork, rather than use the above BEFORE line.

. /etc/rc.subr

name="waitnetwork"
rc_var=`set_rcvar`

start_cmd="waitnetwork_start"
stop_cmd=":"

# XXX - once/if committed to base, the following defaults should
# XXX - be placed into src/etc/defaults/rc.conf instead of here

waitnetwork_enable="NO" # Wait for network availability before
# continuing with NETWORKING rc scr

Re: rc(8) script -- waiting for the network to become usable

2010-04-18 Thread Andrew Reilly 
On Sun, Apr 18, 2010 at 02:37:27PM -0700, Jeremy Chadwick wrote:
> I'd like to discuss the possibility of introduction of a new script into
> /etc/rc.d base system a script, which when enabled, would provide a way
> to wait until the IP networking layer (using ping(8)) is up and usable
> before continuing with daemon startup.
> 
> Let's discuss.  :-)
> 
> 
> HISTORY
> =
> The situation which brought this debacle to my attention:
> 
> I found that on reboot of some of our systems, ntpdate (used to sync the
> clock initially before ntpd would be started) wouldn't work.  The daemon
> would report that it couldn't resolve any of the FQDNs within ntp.conf,
> and would therefore act as a no-op before continuing on.

By way of discussion, I'd just like to re-iterate what I
said the first time around: it must be understood that this
sort of thing is a (necessary) hacky-workaround that should
ultimately be unnecessary.  In preference, we should work on
the failing daemons or hassle up-stream daemon authors so
that the daemons in question either (a) retry until they *do*
get the information they're after or (b) fail properly, so
that they can be restarted by an external process monitoring
framework like sysutils/daemontools or launchd.  The reasoning
is simple: network outage is something that can happen even
after startup, and when network connectivity returns, the
routing and addresses that are visible won't necessarily be the
same.  Consider laptops that suspend, as a particular example.
Or mobile devices that switch from wi-fi to cellular networking
to no connectivity on a regular basis.  The "get it right at
boot time" model is important and traditional, but (I think)
a fragile and diminishing fraction of use cases.  Our rc-ng
framework favours solution (a).  I'm more a fan of approach (b),
myself: I use daemontools for many services, and I like the way
that launchd works on my Mac laptops.

Cheers,

-- 
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: rc(8) script -- waiting for the network to become usable

2010-04-18 Thread Garrett Cooper 
On Sun, Apr 18, 2010 at 4:24 PM, Andrew Reilly  wrote:
> On Sun, Apr 18, 2010 at 02:37:27PM -0700, Jeremy Chadwick wrote:
>> I'd like to discuss the possibility of introduction of a new script into
>> /etc/rc.d base system a script, which when enabled, would provide a way
>> to wait until the IP networking layer (using ping(8)) is up and usable
>> before continuing with daemon startup.
>>
>> Let's discuss.  :-)
>>
>>
>> HISTORY
>> =
>> The situation which brought this debacle to my attention:
>>
>> I found that on reboot of some of our systems, ntpdate (used to sync the
>> clock initially before ntpd would be started) wouldn't work.  The daemon
>> would report that it couldn't resolve any of the FQDNs within ntp.conf,
>> and would therefore act as a no-op before continuing on.
>
> By way of discussion, I'd just like to re-iterate what I
> said the first time around: it must be understood that this
> sort of thing is a (necessary) hacky-workaround that should
> ultimately be unnecessary.  In preference, we should work on
> the failing daemons or hassle up-stream daemon authors so
> that the daemons in question either (a) retry until they *do*
> get the information they're after or (b) fail properly, so
> that they can be restarted by an external process monitoring
> framework like sysutils/daemontools or launchd.  The reasoning
> is simple: network outage is something that can happen even
> after startup, and when network connectivity returns, the
> routing and addresses that are visible won't necessarily be the
> same.  Consider laptops that suspend, as a particular example.
> Or mobile devices that switch from wi-fi to cellular networking
> to no connectivity on a regular basis.  The "get it right at
> boot time" model is important and traditional, but (I think)
> a fragile and diminishing fraction of use cases.  Our rc-ng
> framework favours solution (a).  I'm more a fan of approach (b),
> myself: I use daemontools for many services, and I like the way
> that launchd works on my Mac laptops.

I agree with Andrew. This is the model that Mac has been on for a
while now with launchd and this is the way that we should be migrating
towards (IMO) as it does a better job at detecting asynchronous system
events and could improve the overall init / rc model used in FreeBSD.
What ever happened to this work: http://wiki.freebsd.org/launchd ?
I remember that Apple went in a more OSX centric set of APIs in
Leopard+, but it might be worthwhile to start with the older version
of launchd, and migrate from there.
Thanks,
-Garrett
___
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"

cyclades driver in 8.0-STABLE

2010-04-18 Thread Albert Chin 
Just updated to 8.0-RELEASE and recompiling 8.0-STABLE with the
following addition to GENERIC:
  device cy
  options CY_PCI_FASTINTR

Building the kernel with:
  make buildkernel KERNCONF=NEWKERNEL
gives me:
  cc -c -O -pipe -march=pentium4 -std=c99 -g -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/opt/freebsd/src/sys -I/opt/freebsd/src/sys/contrib/altq -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mno-align-long-strings 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-ffreestanding -fstack-protector -Werror /opt/freebsd/src/sys/dev/cy/cy.c
  /opt/freebsd/src/sys/dev/cy/cy.c:251: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'cybreak'
  /opt/freebsd/src/sys/dev/cy/cy.c:252: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'cymodem'
  /opt/freebsd/src/sys/dev/cy/cy.c:253: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'cyopen'
  /opt/freebsd/src/sys/dev/cy/cy.c:254: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'cyclose'
  cc1: warnings being treated as errors

FreeBSD 7 had:
  typedef void t_break_t(struct tty *, int);
in 

This is no longer present in FreeBSD 8. Oversight? Should I be able to
compile the cyclades driver for FreeBSD 8?

-- 
albert chin (ch...@thewrittenword.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: rc(8) script -- waiting for the network to become usable

2010-04-18 Thread Daniel Braniss 
> On Sun, Apr 18, 2010 at 02:37:27PM -0700, Jeremy Chadwick wrote:
> > I'd like to discuss the possibility of introduction of a new script into
> > /etc/rc.d base system a script, which when enabled, would provide a way
> > to wait until the IP networking layer (using ping(8)) is up and usable
> > before continuing with daemon startup.
> > 
> > Let's discuss.  :-)
> > 
> > 
> > HISTORY
> > =
> > The situation which brought this debacle to my attention:
> > 
> > I found that on reboot of some of our systems, ntpdate (used to sync the
> > clock initially before ntpd would be started) wouldn't work.  The daemon
> > would report that it couldn't resolve any of the FQDNs within ntp.conf,
> > and would therefore act as a no-op before continuing on.
> 
> By way of discussion, I'd just like to re-iterate what I
> said the first time around: it must be understood that this
> sort of thing is a (necessary) hacky-workaround that should
> ultimately be unnecessary.  In preference, we should work on
> the failing daemons or hassle up-stream daemon authors so
> that the daemons in question either (a) retry until they *do*
> get the information they're after or (b) fail properly, so
> that they can be restarted by an external process monitoring
> framework like sysutils/daemontools or launchd.  The reasoning
> is simple: network outage is something that can happen even
> after startup, and when network connectivity returns, the
> routing and addresses that are visible won't necessarily be the
> same.  Consider laptops that suspend, as a particular example.
> Or mobile devices that switch from wi-fi to cellular networking
> to no connectivity on a regular basis.  The "get it right at
> boot time" model is important and traditional, but (I think)
> a fragile and diminishing fraction of use cases.  Our rc-ng
> framework favours solution (a).  I'm more a fan of approach (b),
> myself: I use daemontools for many services, and I like the way
> that launchd works on my Mac laptops.

I think that rc is being overloaded yet again(*), and a launchDaemon
kind of solution should be followed, maybe even as a replacement for
inetd?
/blah
(*): in the begining rc would do everything, but life was simple - no internet,
then it got complicated, too many daemons, so inetd was invented, things
were back in control, for a while. Then sysv invented init.d/init levels, then
rc-ng came along, though it solves many problems, 1) the order of things,
2) easy to configure services, it's getting complicated to get 1 'correctly'.
blah/

danny


___
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: net/mpd5, ppp, proxy-arp issues

2010-04-18 Thread Marin Atanasov 
Hi,

I was setting up mpd5 from ports, but this proxy-arp issue still exists in
8.0.

> uname -r
8.0-RELEASE-p2

I've attached the output from the mpd5 daemon, where you can still see that
the issue is relevant.

I've also tried to apply the patch, but it's no longer on that location.
Something else to add - I've a dns server running on the same machine that
mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp
issue, but after a couple of start/stops of mpd5 the name resolving from the
gateway machine is not possible, all other systems from the internal network
are able to use the dns server on the gateway, but the gateway itself
cannot.

Restart of named, doesn't help either, so I had to completely reboot the
machine, so that arp entries are flushed as well.

Could you please have a look at the issue? If you need some additional
information, please let me know.

Regards,
Marin

On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. wrote:

> Thank you !
> The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with
> mpd5).
>
> Please, somebody  fix  the bug kern/141285...
>
>
> Li, Qing wrote:
>
>> Hi,
>>
>> Recently there have been several reports regarding issues with ppp, mpd5
>> and proxy-arp configuration over the ppp links. I read through the
>> various postings and the problems seem to be:
>>
>> 1. Unable to add proxy-arp entries for the remote ppp clients.
>>
>> 2. Log showing "ifa_add_loopback_route: insertion failed" causingsome
>> userland applications to fail.
>>
>> May I ask that you try applying patch
>>
>>  
>> http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff
>>
>> and report back if the patch fixes your problems. And if not, please
>> describe what additional issues you are having.
>>
>> Thanks,
>>
>> -- Qing
>>
>>
>> ___
>> freebsd-...@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-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"
>



-- 
Marin Atanasov Nikolov
dnaeon AT gmail DOT com
daemon AT unix-heaven DOT org
# /usr/local/sbin/mpd5
Multi-link PPP daemon for FreeBSD
 
process 2295 started, version 5.5 (r...@domain 02:21 17-Apr-2010)
Usage: set user {name} {password} [{priv}]
CONSOLE: listening on 127.0.0.1 5005
web: listening on 0.0.0.0 5006
PPTP: waiting for connection on  1723
[L] [L-1] Accepting PPTP connection
[L-1] Link: OPEN event
[L-1] LCP: Open event
[L-1] LCP: state change Initial --> Starting
[L-1] LCP: LayerStart
[L-1] PPTP: attaching to peer's outgoing call
[L-1] Link: UP event
[L-1] LCP: Up event
[L-1] LCP: state change Starting --> Req-Sent
[L-1] LCP: SendConfigReq #1
[L-1]   ACFCOMP
[L-1]   PROTOCOMP
[L-1]   MRU 1500
[L-1]   MAGICNUM 102c4d22
[L-1]   AUTHPROTO CHAP MSOFTv2
[L-1]   MP MRRU 2048
[L-1]   MP SHORTSEQ
[L-1]   ENDPOINTDISC [802.1] 00 10 dc 10 55 3f
[L-1] LCP: rec'd Configure Reject #1 (Req-Sent)
[L-1]   MP MRRU 2048
[L-1]   MP SHORTSEQ
[L-1]   ENDPOINTDISC [802.1] 00 10 dc 10 55 3f
[L-1] LCP: SendConfigReq #2
[L-1]   ACFCOMP
[L-1]   PROTOCOMP
[L-1]   MRU 1500
[L-1]   MAGICNUM 102c4d22
[L-1]   AUTHPROTO CHAP MSOFTv2
[L-1] LCP: rec'd Configure Ack #2 (Req-Sent)
[L-1]   ACFCOMP
[L-1]   PROTOCOMP
[L-1]   MRU 1500
[L-1]   MAGICNUM 102c4d22
[L-1]   AUTHPROTO CHAP MSOFTv2
[L-1] LCP: state change Req-Sent --> Ack-Rcvd
[L-1] LCP: rec'd Configure Request #1 (Ack-Rcvd)
[L-1]   MRU 1400
[L-1]   MAGICNUM 7fe5744d
[L-1]   PROTOCOMP
[L-1]   ACFCOMP
[L-1]   CALLBACK 6
[L-1] LCP: SendConfigRej #1
[L-1]   CALLBACK 6
[L-1] LCP: rec'd Configure Request #2 (Ack-Rcvd)
[L-1]   MRU 1400
[L-1]   MAGICNUM 7fe5744d
[L-1]   PROTOCOMP
[L-1]   ACFCOMP
[L-1] LCP: SendConfigAck #2
[L-1]   MRU 1400
[L-1]   MAGICNUM 7fe5744d
[L-1]   PROTOCOMP
[L-1]   ACFCOMP
[L-1] LCP: state change Ack-Rcvd --> Opened
[L-1] LCP: auth: peer wants nothing, I want CHAP
[L-1] CHAP: sending CHALLENGE #1 len: 21
[L-1] LCP: LayerUp
[L-1] LCP: rec'd Ident #3 (Opened)
[L-1]   MESG: MSRASV5.10
[L-1] LCP: rec'd Ident #4 (Opened)
[L-1]   MESG: MSRAS-0-TSUNAMI
[L-1] CHAP: rec'd RESPONSE #1 len: 61
[L-1]   Name: "mratest"
[L-1] AUTH: Trying INTERNAL
[L-1] AUTH: INTERNAL returned: undefined
[L-1] CHAP: Auth return status: undefined
[L-1] CHAP: Response is valid
[L-1] CHAP: Reply message: S=8BE305F08FBAEB4E801B6201037B4B4AEB76A73B
[L-1] CHAP: sending SUCCESS #1 len: 46
[L-1] LCP: authorization successful
[L-1] Link: Matched action 'bundle "B" ""'
[L-1] Creating new bundle using template "B".
[B-1] Bundle: Interface ng0 created
[L-1] Link: Join bundle "B-1"
[B-1] Bundle: Status update: up 1 link, total bandwidth 64000 bps
[B-1] IPCP: Open event
[B-1] IPCP: state change Init