Re: NULL pointer deref in sioopen() suggests a close/open race on sio device?

[Garance A Drosihn]

At 4:51 PM + 1/23/05, Robert Watson wrote:
The ps list is a bit boring, but the primary interesting thing is
that it looks like the close was going on in one thread just about
when the sio swi was scheduled to run also:
   [...]
  This in turn suggests that something has called ttyrel/tty_close
on the TTY in a race with the open, or otherwise NULL'd that pointer
via knlist_destroy().  Anyone have any pointers on this one?  The
TTY code is not my forte...
FWIW, I just recently setup some of my freebsd boxes with serial
consoles.  It *seems* to me that if I type in 'shutdown -r now'
when I am logged into a serial console, there's often some long
delay before the reboot happens.  It's long enough to be annoying,
but not long enough to motivate me to look into it.  My machines
usually have a monitor/keyboard also setup on them, so my solution
has been to avoid using the serial console...
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NIC card problems....

[Warner Losh]

> The TX threshold messages issued by the dc driver appear more as an
> indication that the PCI bus is under severe load, than as a hint that
> the dc driver is causing the reboots, IMHO.

I've also seen them when the card is a CardBus card, which may
indicate some slightly pessimal performance parameters are set at the
pci cardbus bridge... 

Warner
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NIC card problems....

[Peter Jeremy]

On Mon, 2005-Jan-24 00:27:38 +0100, Stefan Eßer wrote:
>The TX threshold messages issued by the dc driver appear more as an
>indication that the PCI bus is under severe load, than as a hint that
>the dc driver is causing the reboots, IMHO.

Under Tru64, I've seen Tulip cards report backoff to 1024 byte FIFO and
then switching to store-and-forward.  That's about 100µsec latency and
nothing should be holding the PCI bus that long.  I am inclined to
believe that something is stuffed in the PCI interface logic in the NIC.

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NIC card problems....

[Net Virtual Mailing Lists]

Hello Stefan (and everyone else!),

Thank you for your great comments!  I think I have a 3c9xx card around
here somewhere, I will give that a shot when it reboots the next time
(just to see).  It looks like for future systems I'll standardize on the
Intel fxp-based cards, I really appreciate that advice!


As for what might actually be causing this crash: I just checked the PCI
configuration and don't see anything in the BIOS which would suggest that
anything you mentioned is something I can modify - is that correct?  Or
are you saying that I am simply pushing past the limits of what this
hardware (and PCI bus) is capable of?

For whatever it is worth, all I have in terms of PCI cards is this NIC
and VGA card (which doesn't run anything gui-like).  I am using the
onboard IDE controller, not sure if that is considered a "PCI card" for
this purpose.  There are no sound cards or anything like that installed.
 The motherboard has no built-in audio.  I can copy all of the possible
PCI settings I have in my bios setup and what they are set to, if you
think that would be helpful here (I would have done it, but I just am not
sure if you are hinting at the possibility there may be something wrong
with the BIOS configuration here)?

I will say that what you are describing could very well be the case, I've
got two disks (one on each of the two built-in controllers) running
pretty hot-and-heavy during most of this too.

- Greg

>A master latency timer value of 32 (0x20) should keep the bus-master
>switch overhead down to 20% (i.e. 80% left for data transfers) and
>should keep the latency in the range of 1 microsecond per bus-master
>(i.e. 5 microseconds if there are 2 Ethernet cards, 2 disk controllers
>and one host bridge active at the same time). In that case, each PCI
>device could expect to transfer 100 bytes every 5 microseconds. A
>buffer of 128 bytes ought to suffice for a fast Ethernet card, in
>that case.
>
...
>
>The TX threshold messages issued by the dc driver appear more as an
>indication that the PCI bus is under severe load, than as a hint that
>the dc driver is causing the reboots, IMHO.
>
>Regards, STefan
>


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

Re: NIC card problems....

[Stefan Eßer]

On 2005-01-23 05:57 -0800, Net Virtual Mailing Lists <[EMAIL PROTECTED]> wrote:
> My latest problem is with a:
> 
> dc0:  port 0xe800-0xe8ff mem 0xe608-
> 0xe60803ff irq 11 at device 10.0 on pci0
> dc0: Ethernet address: 00:0c:41:ed:ae:85
> 
> ...  after several hours of *HEAVY* (I'm probably understating this)
> utilization I get:
> 
> dc0: TX underrun -- increasing TX threshold
> dc0: TX underrun -- increasing TX threshold
> .. repeats numerous times..
> dc0: TX underrun -- using store and forward mode

Well, that's nothing to worry too much about ...

The device has a data FIFO that is filled with data words fetched
by its bus-master DMA engine via the PCI bus. As an optimization,
sending the Ethernet frame may optionally start, before all data
for the frame has been put into the FIFO. Normally, data is fetched
faster by DMA then sent by Ethernet, but if there are a significant
number of simultanous PCI data transfers by other devices, there is
the risk that the FIFO runs out of data (buffer underflow). In such
a case, the current Ethernet frame can't be finished (dummy data and
a bogus CRC are added to have the receiving party discard the frame).

If such a sittuation exists, the driver will increase the amount of
data required in the FIFO, before transmission of the next Ethernet
frame starts. After multiple underruns, the driver will configure
the Ethernet chip to buffer the full contents of each frame (store
and forward mode) and will avoid the early transmission start, since
the hardware apparently is not capable of providing data fast enough.

> .. at this point the system simply reboots.  I have attempted to apply a

Then there definitely is a bug somewhere, but not neccessarily in the
dc driver. Instead of switching Ethernet cards, you may want to check
the PCI performance of your mainboard. The PCI latency timers (master
latency timer and individual timers in each device) may play a role.

They decide about the maximum "time slice" assigned to each bus-master
in turn. Too small a value causes the PCI bus throughput to suffer
(because of a few PCI bus clocks are lost each time the next bus-master
takes over), while too high a value may cause a device to starve waiting
to get access to the bus granted.

A master latency timer value of 32 (0x20) should keep the bus-master
switch overhead down to 20% (i.e. 80% left for data transfers) and
should keep the latency in the range of 1 microsecond per bus-master
(i.e. 5 microseconds if there are 2 Ethernet cards, 2 disk controllers
and one host bridge active at the same time). In that case, each PCI
device could expect to transfer 100 bytes every 5 microseconds. A
buffer of 128 bytes ought to suffice for a fast Ethernet card, in
that case.

But this is a simplified view and calculation. Devices may keep the
PCI bus longer than the granted time slice, if there are (what used
to be called) "wait cycles" inserted by slow devices. (And some sound
cards have been reported to cause high PCI load, even when idle.)

The TX threshold messages issued by the dc driver appear more as an
indication that the PCI bus is under severe load, than as a hint that
the dc driver is causing the reboots, IMHO.

Regards, STefan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NIC card problems....

[Pete French]

> You know, I don't really care what NIC I use - I really don't.  I'm not
> so much interested in trying to figure out why this NIC is giving me
> grief as much as I am in finding one that will work.  I would just like
> someone somewhere to tell me what is a stable NIC to use for FreeBSD,

As several other people have mentioned, Intel fxp cards work. I have
used a wide variety of these on several system and they all perform
excellently and I have never had a problem. Am currently running
them in a number of production environments.

-pcf.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NIC card problems....

[Chuck Swiger]

Net Virtual Mailing Lists wrote:
[ ... ]
[ ... ]  It would be nice if somewhere there was
some statement of a "fact" that NIC  is known to work well with
FreeBSD.  I'm aware of all of the FUD out there, about people beating
their chests saying how wonderful NIC-A is or NIC-B is, and I've tried
'em all and had problems with each and every one of them so far.  Surely
someone out there must use FreeBSD in an environment where the "network
is the bottleneck"^2 - right?
I have never had a problem with a Intel fxp0 NIC.
My company probably has used over fifty of them.
I have never had a problem with the 3com 9xx xl0 NICs.
About ten of those are in proximity to me over the years.

DEC-branded 21x4x Tulip cards have also been good, but I've had three out of 4 
Asante cards using a PNIC Tulip lookalike have failed, and I'm dubious about 
the last one.  Avoid Tulip clones.


I've not had problems with a sis0 (NatSemi DP83815), but not enough of them to 
generalize.  I've seen mild problems with the vr0 (VIA chipsets) & Broadcom 
chips, and the Realtek and NE2000 clones that ISPs give to their customers for 
free may not be worth even that much.

--
-Chuck
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NIC card problems....

[Peter Jeremy]

On Sun, 2005-Jan-23 05:57:53 -0800, Net Virtual Mailing Lists wrote:
>  It would be nice if somewhere there was
>some statement of a "fact" that NIC  is known to work well with
>FreeBSD.

I recall seeing quite a few such statements about different cards over
the years.  In general, such statements have a limited lifetime because
NIC vendors have an ongoing tendency to "improve" their NICs to the
point of incompatibility.  There are often useful comments about the
NICs at the top of the driver code for that NIC (though there's nothing
about your AN985).

>...  after several hours of *HEAVY* (I'm probably understating this)
>utilization I get:
>
>dc0: TX underrun -- increasing TX threshold
>dc0: TX underrun -- increasing TX threshold
>.. repeats numerous times..
>dc0: TX underrun -- using store and forward mode

Real DEC Tulip cards do this when running Tru64 as well.  My guess is that
it's a bug in the NIC.  (And it looks like AMDtek have copied it).

>.. at this point the system simply reboots.

This is undesirable.  However, you have not provided any information that
would allow anyone to assist you.  Please have a look at
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html

>  I have attempted to apply a
>patch () which I
>found which patches sys/pci/if_dcreg.h and sys/pci/if_dc.c.

This PR is closed which means that the patches (or functional equivalents)
should have already been applied.

>  I would just like
>someone somewhere to tell me what is a stable NIC to use for FreeBSD,

I've been using Intel EtherExpress Pro/100+ cards (fxp driver) in some
systems where the network gets hammered and haven't had any problems.

-- 
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

sendmail failure

[ianjhart]

That post about  lookups reminds me; the one 5.x box I'm running at work, 
refuses to deliver it's log files to our mail hub. I know that there are 
about a million different ways for me to have stuffed this up myself, so 
please be gentle.

That other post reminds me about this because we have broken (i.e. MS) DNS 
servers. The 4.10 boxes we have all deliver okay though. I'm wondering if 
WorkAroundBroken is okay in 5-STABLE.

Anyway I've done side by side comparisons of two servers. They look similar up 
to the point where the 4.x server opens a network connection and gets the 220 
reply. The 5 box apparently does nothing. Using tcpdump, It looks like the A 
request is never sent, so there's no connection opened.

If I run
#echo test | sendmail -Am -v -d16.10 root

on the 4.10 box the output includes

makeconnection: WorkAroundBroken: Trying AF_INET lookup (AF_INET6 failed)
makeconnection (mail.lan.cardinalnewman.coventry.sch.uk. [10.248.192.10].25 
(2))
makeconnection: fd=7

My workstation at home (with 4.10 DNS) shows

makeconnection (alpha.private.lan. [192.168.0.2].25 (2))
makeconnection: fd=7

but the 5.3 box at work shows no makeconnection output at all.

#uname -a
FreeBSD client.lan.cardinalnewman.coventry.sch.uk 5.3-STABLE FreeBSD 
5.3-STABLE #8: Thu Dec 23 00:45:38 GMT 2004 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  
i386

Box was built Aug 2nd and updated from source.

stock sendmail AFAIR; rebuilding everything just in case.

Version 8.13.1
 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF
STARTTLS TCPWRAPPERS USERDB XDEBUG

Cheers

-- 
ian j hart
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: loader.conf examples

[Robert Watson]

On Sun, 23 Jan 2005, Jason C. Wells wrote:

> --On Sunday, January 23, 2005 7:22 AM -0500 Matt Herzog <[EMAIL PROTECTED]> 
> wrote:
> 
> > I'm confused about how and why modules are built and (seemingly
> > loaded without my having specified any to load) when I have not
> > told my kernel conf file to build anything as a module. As a former
> > NetBSD user, I had expected a monolitic kernel . . .
> 
> You can still run a monolithic kernel as I do.  You can also use
> NO_MODULES as a make option to prevent the build and installation of
> modules.  See also MODULES_OVERRIDE is /sys/conf/NOTES. 
> 
> If you never specified a module to load, then no modules should be
> loaded. (Ref kldstat)  Maybe the default behavior has changed.  I
> wouldn't know though since I don't use the default behavior. 

Modules will sometimes be auto-loaded on demand -- typically this occurs
in the following sorts of situations:

- Modules will be auto-loaded of another module that depends on the module
  is loaded.
- acpi.ko will be auto-loaded during the boot process if ACPI is enabled.
- The kernel will auto-load modules necessary to mount a requested file
  system if the necessary modules are not already present.
- If certain features are enabled in rc.conf, the modules will be loaded
  to support them if not already present in the kernel, including modules
  for various ABI compatibility layers (linux, etc), firewalls,
  ATM-related network pieces, NFS, and some MAC modules.
- The ppp(8) command will auto-load modules to support PPPoE if required.

The user process requested loading of modules is blocked if the
securelevel is > 0.  Likewise for the auto-loading of modules relating to
file system mounts.  The loader will still load modules during the early
boot process before the securelevel is available for inspection, however.

Robert N M Watson


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

Re: loader.conf examples

[Jason C. Wells]

--On Sunday, January 23, 2005 7:22 AM -0500 Matt Herzog <[EMAIL PROTECTED]> 
wrote:

I'm confused about how and why modules are built and (seemingly
loaded without my having specified any to load) when I have not
told my kernel conf file to build anything as a module. As a former
NetBSD user, I had expected a monolitic kernel . . .
You can still run a monolithic kernel as I do.  You can also use NO_MODULES 
as a make option to prevent the build and installation of modules.  See 
also MODULES_OVERRIDE is /sys/conf/NOTES.

If you never specified a module to load, then no modules should be loaded. 
(Ref kldstat)  Maybe the default behavior has changed.  I wouldn't know 
though since I don't use the default behavior.

There are two ways to build a kernel.  There is 'make buildkernel' and 
there is 'config KERNEL; make depend; make' Take care which options apply 
to which method.

Later,
Jason C. Wells
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

NULL pointer deref in sioopen() suggests a close/open race on sio device?

[Robert Watson]

Ran into the following panic on a 5-STABLE box this morning, which
occurred after hitting Ctrl-D to close a login session on a serial console
(ttyd0 at 9600 bps):

login: Jan 23 10:43:27 fledge login: 2 LOGIN FAILURES ON ttyd0


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x1c
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc051537b
stack pointer   = 0x10:0xe7345988
frame pointer   = 0x10:0xe7345994
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 = 45092 (getty)
[thread pid 45092 tid 100201 ]
Stopped at  knote+0x27: cmpxchgl%ecx,0x1c(%edx)
db> show pcpu
cpuid= 0
curthread= 0xc290d190: pid 45092 "getty"
curpcb   = 0xe7345da0
fpcurthread  = 0xc290d190: pid 45092 "getty"
idlethread   = 0xc22644b0: pid 11 "idle"
APIC ID  = 0
currentldt   = 0x30
db> trace
Tracing pid 45092 tid 100201 td 0xc290d190
knote(c264e098,0,0,c290d190,e73459c4) at knote+0x27
ttwwakeup(c264e000) at ttwwakeup+0xc8
comstart(c264e000) at comstart+0x385
comparam(c264e000,c264e0a4,c264e000,3,0) at comparam+0x253
sioopen(c079f060,3,2000,c290d190,c078e6a0) at sioopen+0x1df
spec_open(e7345a84,e7345b40,c058d585,e7345a84,180) at spec_open+0x2b6
spec_vnoperate(e7345a84) at spec_vnoperate+0x13
vn_open_cred(e7345be4,e7345ce4,c08,c2261d80,0) at vn_open_cred+0x419
vn_open(e7345be4,e7345ce4,c08,0,c4289b58) at vn_open+0x1e
kern_open(c290d190,804f8e0,0,3,bfbfee18) at kern_open+0xe3
open(c290d190,e7345d14,3,0,292) at open+0x18
syscall(2f,2f,2f,804f8e0,0) at syscall+0x27b
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (5, FreeBSD ELF32, open), eip = 0x280d155b, esp = 0xbfbfedec,
ebp =
0xbfbfee18 ---

The ps list is a bit boring, but the primary interesting thing is that it
looks like the close was going on in one thread just about when the sio
swi was scheduled to run also:

db> ps
  pid   proc uarea   uid  ppid  pgrp  flag   stat  wmesgwchan  cmd
45092 c6762388 e73870000 1 1 0004000 [CPU 0] getty
...
  132 c235954c e4fbf0000 0 0 20c [RUNQ] swi5: clock sio

I didn't have a kernel with debugging symbols on-hand, but the above
address in knote() is a cmpxchg early in the function, which means it's
likely the conditional call to mtx_lock() hitting a NULL mutex pointer for
kl_lock.  This in turn suggests that something has called ttyrel/tty_close
on the TTY in a race with the open, or otherwise NULL'd that pointer via
knlist_destroy().  Anyone have any pointers on this one?  The TTY code is
not my forte...

Robert N M Watson

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

NIC card problems....

[Net Virtual Mailing Lists]

Hello,


I regret that I have never posted to this list before, despite the fact I
have been using FreeBSD in one form or another for many years now (since
2.x era).  I'm a bit cranky, so please do not take any of this wrong.  I
have a system running FreeBSD 4.10-STABLE (bites tongue).

In any event, I just have to ask: what the heck is up with support for
network cards?... I mean, seriously, no offense intended to all of the
folks who work so hard on this stuff, but every single FreeBSD system I
have installed has at one time or another encountered *some* problem
relating to its network card.  It would be nice if somewhere there was
some statement of a "fact" that NIC  is known to work well with
FreeBSD.  I'm aware of all of the FUD out there, about people beating
their chests saying how wonderful NIC-A is or NIC-B is, and I've tried
'em all and had problems with each and every one of them so far.  Surely
someone out there must use FreeBSD in an environment where the "network
is the bottleneck"^2 - right?

By this I mean it is a development system which runs 4 simultaneous
processes which run 24x7 (and use network bandwidth in spades - most
across a 100mb pipe), a web server, postgres, and nfs server -- some of
these processes needed to have MAXDSIZ increased to support up to 1gb (I
set MAXDSIZ="(1024*1024*1024)") (and yes, this excessive memory
consumption is beyond my control)...  The system has 2gb of ram with 8gb
of swap (just to make sure!) and is a 600Mhz AMD K6... I've ensured that
all of these "memory intensive" processes are forked so that they are
able to release their memory when finished.  I don't really care how slow
it runs -- as long as it runs reliably.  I know that this may not be an
ideal configuration given what I'm asking from this limited hardware, but
I did not experience any reliability problems prior to installing FreeBSD
on this exact same hardware (more about this later) with similar tweaks
to just make sure everything is able to run (regardless of actual
performance).

My latest problem is with a:

dc0:  port 0xe800-0xe8ff mem 0xe608-
0xe60803ff irq 11 at device 10.0 on pci0
dc0: Ethernet address: 00:0c:41:ed:ae:85

...  after several hours of *HEAVY* (I'm probably understating this)
utilization I get:

dc0: TX underrun -- increasing TX threshold
dc0: TX underrun -- increasing TX threshold
.. repeats numerous times..
dc0: TX underrun -- using store and forward mode


.. at this point the system simply reboots.  I have attempted to apply a
patch () which I
found which patches sys/pci/if_dcreg.h and sys/pci/if_dc.c.  The patch
file was not correct for my version and it looks to me as if sys/pci/
if_dcreg.h already had the changes applied, but I went ahead and added
the few minor changes it had for pci/sys/if_dc.c, just on a whim (I
should probably note that my version of if_dc.c before the patch was:
"$FreeBSD: src/sys/pci/if_dc.c,v 1.9.2.56 2004/04/22 22:03:27 ru Exp").   

.. In any event, my pager just went off again, the system rebooted, again
with the exact same symptom.

You know, I don't really care what NIC I use - I really don't.  I'm not
so much interested in trying to figure out why this NIC is giving me
grief as much as I am in finding one that will work.  I would just like
someone somewhere to tell me what is a stable NIC to use for FreeBSD,
minus all the speculation as to what might or might not work correctly. 
Just tell me what to buy and I'll go buy it, really I will!  If I need a
specific chipset with a specific revision that's fine too just please
tell me what it is.  Hell at this point I'll even look for NICs from
specific lot numbers.  I'm getting ready to roll out a production version
of what I've been testing the last few months and I simply would like to
know what NIC I can depend on to not give me these sort of fits

Thanks and again sorry if I seem frustrated, but you are getting a 10
second summary of 8 years of frustration.  Maybe I just have bad luck and
always get the "bad NIC", I dunno.

Other than this repeating issue with the support for NIC cards, I've
found FreeBSd to be absolutely rock solid.  It is a real shame that you
guys don't get more support from the hardware manufacturers.  I truly
wish that I were savvy enough to even know where to begin debugging
something like this or to help with the development effort.  Perhaps
someday I will be, who knows.

For whatever its worth this exact system has been running Solaris 2.6
(x86 of course) for the last couple of years and has never crashed for
any reason, ever.  I installed FreeBSD 4.10 because it is what I had
laying around and it is what this client wants to use for their project.
 Over the past week these crashes occur several times throughout the day
and obviously I can't release this project until I am satisfied that it
will run reliably.

..God you have no idea how much I hated writing 90% this, I hope nobody
takes it t

Re: loader.conf examples

[Jorma Dooper]

On Sun, Jan 23, 2005 at 07:22:20AM -0500, Matt Herzog wrote:
> Can anyone point me to a loader.conf file that's full of a wide
> range of options? I just want to see some syntax for stuff like
> video hardware acceleration, audio chipset support etc.
>
Try /boot/defaults/loader.conf and loader.conf(5) manual.   
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

5.3 prob reading 4.11 hdd

[Warren]

I recently took my primary hdd running FreeBSD 4.11-STABLE out of my main 
machine leaving my 2ndry hdd in the machine and installing FreeBSD5.3-STABLE 
on it to use as the new primary.  When everything was done and i plugged in 
the 2nd hdd that originally had 4.11-STABLE on it, i was unable to find the 
individual partitions/slices on there to mount so i could access all the old 
data i had.  I have a basic understanding of FreeBSD but am still not quite 
proficent when it comes to this sort of thing.  Fdisk only shows 1 partition 
so does disklabel. Below is the disklabel output 
of the drive im wanting to get all the data from...

#ad1s1
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  c: 2344364820unused0 0 # "raw" part, don't 
edit
  e: 23443648204.2BSD 2048 1638489

==

# /dev/ad1s1c:
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  c: 234436482   63unused0 0 # "raw" part, don't 
edit
  e: 234436482   634.2BSD 2048 1638489
partition c: partition extends past end of unit
disklabel: partition c doesn't start at 0!
disklabel: An incorrect partition c may cause problems for standard system 
utilities
partition e: partition extends past end of unit
==

# /dev/ad1s1e:
8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  c: 234436482   63unused0 0 # "raw" part, don't 
edit
  e: 234436482   634.2BSD 2048 1638489
partition c: partition extends past end of unit
disklabel: partition c doesn't start at 0!
disklabel: An incorrect partition c may cause problems for standard system 
utilities
partition e: partition extends past end of unit
===

Any help in recovering the copius amounts of data would be greatly 
appreciated.
-- 
Yours Sincerely
Shinjii
http://www.shinji.nq.nu
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

loader.conf examples

[Matt Herzog]

Can anyone point me to a loader.conf file that's full of a wide
range of options? I just want to see some syntax for stuff like
video hardware acceleration, audio chipset support etc.

I'm confused about how and why modules are built and (seemingly
loaded without my having specified any to load) when I have not
told my kernel conf file to build anything as a module. As a former
NetBSD user, I had expected a monolitic kernel . . . 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"