nfe0 startup

2010-04-29 Thread Robert Jenssen 
Hi,

I am using a mother board with a NVIDIA MCP9 network chip on an AMD64 
motherboard. Here is the output of dmesg:

 
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 #1: Fri Apr  9 15:20:00 EST 2010
r...@x:/usr/obj/usr/src/sys/ECLIPSE i386
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Opteron(tm) Processor 148 (2211.35-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x20f71  Family = f  Model = 27  Stepping = 1
  
Features=0x78bfbff
  Features2=0x1
  AMD Features=0xe2500800
  AMD Features2=0x1
real memory  = 1073741824 (1024 MB)
avail memory = 1041534976 (993 MB)
ACPI APIC Table: 
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0:  on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 3fef (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
cpu0:  on acpi0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pci0:  at device 0.0 (no driver attached)
isab0:  at device 1.0 on pci0
isa0:  on isab0
pci0:  at device 1.1 (no driver attached)
ohci0:  mem 0xfe02f000-0xfe02 irq 21 at 
device 2.0 on pci0
ohci0: [ITHREAD]
usbus0:  on ohci0
ehci0:  mem 0xfeb0-0xfeb000ff irq 22 at 
device 2.1 on pci0
ehci0: [ITHREAD]
usbus1: EHCI version 1.0
usbus1:  on ehci0
pci0:  at device 4.0 (no driver attached)
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe800-0xe80f at device 6.0 on pci0
ata0:  on atapci0
ata0: [ITHREAD]
ata1:  on atapci0
ata1: [ITHREAD]
atapci1:  port 
0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd400-0xd40f mem 
0xfe02c000-0xfe02cfff irq 21 at device 7.0 on pci0
atapci1: [ITHREAD]
ata2:  on atapci1
ata2: [ITHREAD]
ata3:  on atapci1
ata3: [ITHREAD]
atapci2:  port 
0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc000-0xc00f mem 
0xfe02b000-0xfe02bfff irq 22 at device 8.0 on pci0
atapci2: [ITHREAD]
ata4:  on atapci2
ata4: [ITHREAD]
ata5:  on atapci2
ata5: [ITHREAD]
pcib1:  at device 9.0 on pci0
pci1:  on pcib1
vgapci0:  port 0xac00-0xacff mem 
0xfb00-0xfbff,0xfcfff000-0xfcff irq 19 at device 5.0 on pci1
fwohci0:  port 0xa800-0xa87f mem 0xfcffe000-0xfcffe7ff 
irq 18 at device 6.0 on pci1
fwohci0: [ITHREAD]
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channels is 4.
fwohci0: EUI64 .
fwohci0: Phy 1394a available S400, 2 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0:  on fwohci0
dcons_crom0:  on firewire0
dcons_crom0: bus_addr 0x3ed64000
fwe0:  on firewire0
if_fwe0: Fake Ethernet address: ...
fwe0: Ethernet address: 
fwip0:  on firewire0
fwip0: Firewire address: .. @ 0xfffe, S400, maxrec 2048
fwohci0: Initiate bus reset
fwohci0: fwohci_intr_core: BUS reset
fwohci0: fwohci_intr_core: node_id=0x, SelfID Count=1, CYCLEMASTER mode
nfe0:  port 0xbc00-0xbc07 mem 
0xfe02a000-0xfe02afff irq 23 at device 10.0 on pci0
miibus0:  on nfe0
e1000phy0:  PHY 1 on miibus0
e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto
nfe0: Ethernet address: 
nfe0: [FILTER]
pcib2:  at device 11.0 on pci0
pci2:  on pcib2
pcib3:  at device 12.0 on pci0
pci3:  on pcib3
pcib4:  at device 13.0 on pci0
pci4:  on pcib4
pcib5:  at device 14.0 on pci0
pci5:  on pcib5
acpi_tz0:  on acpi0
atrtc0:  port 0x70-0x73 irq 8 on acpi0
pmtimer0 on isa0
orm0:  at iomem 
0xc-0xc7fff,0xc8000-0xcbfff,0xcc000-0xcd7ff pnpid ORM on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
ppc0: parallel port not found.
powernow0:  on cpu0
Timecounter "TSC" frequency 2211345268 Hz quality 800
Timecounters tick every 1.000 msec
firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0)  (me) 
firewire0: bus manager 0 
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 480Mbps High Speed USB v2.0
ad4: 76319MB  at ata2-master UDMA100 SATA 3Gb/s
ugen0.1:  at usbus0
uhub0:  on usbus0
ugen1.1:  at usbus1
uhub1:  on usbus1
uhub0: 8 ports with 8 removable, self powered
uhub1: 8 ports with 8 removable, self powered
unknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 
(probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
(probe0:ata0:0:0:0): CAM status: SCSI Status Error
(probe0:ata0:0:0:0): SCSI status: Check Condition
(probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray 
closed)
cd0 at ata0 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SCSI-0 device 
cd0: 3.300MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not presen

Re: nfe0 startup

2010-04-29 Thread Adam Vande More 
On Thu, Apr 29, 2010 at 8:23 AM, Robert Jenssen <
robertjens...@ozemail.com.au> wrote:

> Hi,
>
> I am using a mother board with a NVIDIA MCP9 network chip on an AMD64
> motherboard. Here is the output of dmesg:
>
> 
>
> Also the nfs mounts are now OK.
>
> It seems that nfe0 takes a while to get started. I am lucky that ntpdate is
> called and delays things for long enough to allow nfe0 to startup. Without a
> failing call to ntpdate the subsequent nfs mount fails and I get the
> single-user prompt.
>
> Is there a better way than relying on ntpdate failing?
>

What does rc.conf have to say about nfe0?

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

Re: nfe0 startup

2010-04-30 Thread Robert Jenssen 
Hi,

Many thanks to those who responded to my question. It seems that waiting for 
the network to start up is a common problem. Recently Jeremy Chadwick proprosed 
adding a /usr/local/etc/rc.d/waitnetwork script. In response others have 
suggested the more radical step of replacing /etc/rc.d with launchd. See 
Message-ID  <20100418213727.ga98...@icarus.home.lan> etc. I will await 
developments.

Cheers,

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

Re: nfe0 startup

2010-05-01 Thread Matthew Seaman 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/05/2010 01:15:13, Robert Jenssen wrote:

> Many thanks to those who responded to my question. It seems that
> waiting for the network to start up is a common problem. Recently
> Jeremy Chadwick proprosed adding a /usr/local/etc/rc.d/waitnetwork
> script. In response others have suggested the more radical step of
> replacing /etc/rc.d with launchd. See Message-ID
> <20100418213727.ga98...@icarus.home.lan> etc. I will await
> developments.

launchd(8) is a very interesting proposition, but it replaces a lot more
than just the RC framework.  It also covers cron(8), devd(8), inetd(8),
init(8)/getty(8).  Unlike RC scripts, launchd does /not/ expect the
programs it manages to daemonise.  In that respect, it's a lot more like
daemontools or the sysV-ish inittab.  While this has advantages (eg. in
being able to restart crashed daemons promptly), it's a very different
way of doing things, and there would have to be concomitant changes all
over /usr/src.  Not forgetting all of the available ported software.

By my estimation, if FreeBSD were to commit to using launchd(8), the
work required would absorb the majority of the available developer time
running up to a major release.  ie. if the decision was taken to go
ahead, as soon as 9.0-RELEASE was branched, work on launchd in
10-CURRENT would have to start immediately, and take priority over many
other development efforts in order to have the following 10.0-RELEASE
up to the quality expected from the FreeBSD project.

I don't think that's going to happen.  I can see a launchd-esque system
being introduced, but it would have to be radically rewritten compared
to what MacOS X uses, offer compatibility shims for all of the systems
it was intended to supplant, and it would take many years of gradual
developent and change to get it to the desired state.

In other words, keep up your RC script-writing skills for the
foreseeable future.

Cheers,

Matthew

- -- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
  Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvb6IYACgkQ8Mjk52CukIy8KwCglf3zwHd0G28UOUgHcUi0lSz4
eGgAni89VMuk6zknVBJRDcqzfPzHbkfB
=7+ik
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"