Re: VIA C3 CPU not recognized
On Thu, 2005-Jan-06 23:36:43 +0100, Lukas Ertl wrote: >5.3-STABLE refuses to recognize my VIA C3 CPU, it panics immediately >after the loader with > >CPU class not configured > >Last known working kernel is from Sun Nov 7 16:27:23 CET 2004, it >recognizes the CPU as > >CPU: VIA C3 Samuel 2 (601.37-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x673 Stepping = 3 > Features=0x803035 > >The new kernel says it's an "unknown class" CPU. The exact message may help diagnose what has gone wrong. > I haven't changed my >kernel config since I built the old kernel, so maybe I have overlooked >some new option for VIA CPUs, but I couldn't find a change at first >glance. FWIW, I can't see anything that has changed. Assuming you've double-checked the obvious things (like both kernels really were built using the same config file and you're updating along the correct branch), I'd suggest you either need to do a binary search between 7th November and now to work out what broke, or (if "boot -d" enters the debugger early enough) spend some time with DDB working out why the CPU ident code no longer works for you. The relevant files are: /sys/i386/i386/identcpu.c /sys/i386/i386/initcpu.c /sys/i386/i386/locore.s -- 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: VIA C3 CPU not recognized
On Fri, 2005-Jan-07 00:20:12 +0100, Lukas Ertl wrote: >Nevermind. It seems I now explicitely need > >cpu I686_CPU > >in my kernel. You should have always needed that. -- 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: 5.3-STABLE failing to read 4.x-Stable hdd
On Sat, 2005-Jan-08 16:58:10 +1000, Warren wrote: >> I didn't suggest you trash it I just want to know if it was setup as >> dangerously dedicated, and what the output of the fdisk command on both >> drives is.. > >Soz mis understood.. Try running disklabel on ad0s1 and ad1s1. Slice numbers should now be treated as mandatory on sliced disks. -- 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: GMIRROR can be destroyed by ordinary users
On Sat, 2005-Jan-08 19:54:56 +0100, Simon L. Nielsen wrote: >On 2005.01.08 19:39:42 +0100, Pawel Jakub Dawidek wrote: >> On Sat, Jan 08, 2005 at 04:33:14PM +0100, Simon L. Nielsen wrote: >> +> I'm not really sure it is expected that you can do that when being in >> +> the operator group. >> >> Yes. If you want to change it you should do: >> >> # chmod 600 /dev/geom.ctl > >Being in the operator group only gives read access to /dev/geom.ctl >(it's root:operator crw-r-) so I think it's somewhat counter >intuitive that one can stop the mirror without write permission there. >Wouldn't it be better to only allow stopping the mirror (and similar) >if the user has write access to geom.ctl? In some ways, it's not. The "operator" group is intended for users who perform backups (they can read the disks and therefore perform dumps of them). One approach to backing up mirrored systems is to detach one mirror and back it up. Once the backup is finished, you re-attach the mirror. Given this, it is reasonable for "operator"s to be able to fiddle with mirrors. This approach is mostly obsoleted by soft-updates snapshots but is still relevant if: - you aren't running soft-updates for any reason - the filesystem is too dynamic and full for a snapshot to survive for the time needed for a backup. However, overall, I would agree with Simon that being able to make changes to a device that is opened read-only is counter-intuitive. -- 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: 4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
On Wed, Dec 15, 2004 at 12:42:25PM -0800, Scott Sewall wrote:
> I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic
> occurs seems to happen when I'm running rsync of large directories
> possibly in combination with reading or writing to a compact flash
> attached to USB.
Having just looked into an identical panic, the problem is an
interface bug between bus_dmamem_alloc() and contigmalloc(). It's
nothing to do with USB and (AFAIK) exists in 4.x, 5.x and 6.x.
The relevant part of my backtrace looks like:
#15 0xc028aaef in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = -980715140, tf_ebp = -1070676940, tf_isp = -1070676996,
tf_ebx = 0, tf_edx = 6867008, tf_ecx = -1056660992, tf_eax = 7261248,
tf_trapno = 12, tf_err = 0, tf_eip = -1072225192, tf_cs = 8,
tf_eflags = 66118, tf_esp = -1065633592, tf_ss = 0})
at /home/src/sys/i386/i386/trap.c:466
#16 0xc0172458 in tsleep (ident=0xc58b797c, priority=4,
wmesg=0xc02bfd27 "swwrt", timo=0) at /home/src/sys/kern/kern_synch.c:436
#17 0xc021e60f in swap_pager_putpages (object=0xd03c6e04, m=0xc02ec50c,
count=1, sync=1, rtvals=0xc02ec4b0) at /home/src/sys/vm/swap_pager.c:1431
#18 0xc021ceaf in default_pager_putpages (object=0xd03c6e04, m=0xc02ec50c,
c=1, sync=0, rtvals=0xc02ec4b0) at /home/src/sys/vm/default_pager.c:133
#19 0xc0228ca4 in vm_pageout_flush (mc=0xc02ec50c, count=1, flags=0)
at /home/src/sys/vm/vm_pager.h:147
#20 0xc02285c9 in contigmalloc1 (size=36864, type=0xc02f4340, flags=1, low=0,
high=4294967295, alignment=1, boundary=0, map=0xc03372ac)
at /home/src/sys/vm/vm_page.c:1855
#21 0xc022887f in contigmalloc (size=36864, type=0xc02f4340, flags=1, low=0,
high=4294967295, alignment=1, boundary=0)
at /home/src/sys/vm/vm_page.c:1980
#22 0xc027bd3b in bus_dmamem_alloc (dmat=0xc176b4c0, vaddr=0xc1231a48,
flags=1, mapp=0xc1231a44) at /home/src/sys/i386/i386/busdma_machdep.c:351
#23 0xc0231be2 in usb_block_allocmem (tag=0x0, size=36864, align=1,
dmap=0xc17d8d3c) at /home/src/sys/dev/usb/usb_mem.c:186
...
#35 0xc022d4ea in uhci_intr (arg=0xc104f000)
at /home/src/sys/dev/usb/uhci.c:1175
#36 0xc02841f2 in cpu_idle () at /home/src/sys/i386/i386/machdep.c:1000
Basically, the USB code is trying to allocate ~36KB RAM within an
interrupt handler. usb_block_allocmem() invokes bus_dmamem_alloc()
with BUS_DMA_NOWAIT (advising that sleep()ing is not allowed).
Since more than one page of memory is requested, bus_dmamem_alloc()
uses contigmalloc() to allocate the requested memory. The BUS_DMA_NOWAIT
flag is mapped to M_NOWAIT but contigmalloc() does not support M_NOWAIT.
Unfortunately, I don't know enough about the VM code to be able to
suggest a fix.
--
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: 5.3-RELEASE crashes during make buildworld (and other problems)
On Wed, 2005-Jan-12 13:36:04 -0800, Rick Updegrove wrote:
>Fatal trap 12: page fault while in kernel mode
>fault virtual address = 0x4d
>fault code = supervisor read, page not present
>instruction pointer= 0x8:0xc061c642
That's a NULL pointer dereference. It's not necessarily hardware.
>[EMAIL PROTECTED] nm -n /boot/kernel | grep c061c642
>nm: Warning: '/boot/kernel' is not an ordinary file
Two problems:
1) The kernel is /boot/kernel/kernel (sysctl kern.bootfile)
2) You're extremely unlikely to find a symbol at that address.
What you need to do is
$ nm -n `sysctl kern.bootfile` | less
and search for the symbol closest to but no greater than 0xc061c642
This still isn't enough information to reveal anything useful. As a
minimum, you need to enable DDB ("options DDB" and "options KDB") and
get a backtrace after the panic. If you don't already have one, a
serial console will make things much easier. A crashdump or gdb
session would be much better.
>> Hardware problems would be my first suspicion here.
>
>Me too... if it were not for the fact 5.3-RELEASE is the only OS that
>has problems on this hardware.
That doesn't totally rule out hardware. Pattern-sensitive memory
problems may not show up on different operating systems (or even
different kernels). That said, based on the trap information, I'd
look at a software cause first.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unkillable OpenOffice.org process in 5.3p2
9 264336 52309 /usr/local/OpenOffice.org1.1.3/program/libpackage2.so soffice.b 67812 peter txt VREG 4,39 1071540 54075 /usr/local/OpenOffice.org1.1.3/program/libfwk645fi.so soffice.b 67812 peter txt VREG 4,39 331340 52310 /usr/local/OpenOffice.org1.1.3/program/libsts645fi.so soffice.b 67812 peter txt VREG 4,3965932 54047 /usr/local/OpenOffice.org1.1.3/share/fonts/truetype/Vera.ttf soffice.b 67812 peter txt VREG 4,39 148240 54017 /usr/local/OpenOffice.org1.1.3/program/libuui645fi.so soffice.b 67812 peter txt VREG 4,39 184556 54063 /usr/local/OpenOffice.org1.1.3/program/libdtransX11645fi.so soffice.b 67812 peter txt VREG 4,39 7545576 54132 /usr/local/OpenOffice.org1.1.3/program/libsc645fi.so soffice.b 67812 peter txt VREG 4,39 1288144 52290 /usr/local/OpenOffice.org1.1.3/program/libdbtools2.so soffice.b 67812 peter txt VREG 4,3993008 53415 /usr/local/OpenOffice.org1.1.3/program/liblocaledata_en.so soffice.b 67812 peter txt VREG 4,3949224 53402 /usr/local/OpenOffice.org1.1.3/share/fonts/truetype/VeraMono.ttf soffice.b 67812 peter txt VREG 4,39 132156 53912 /usr/local/OpenOffice.org1.1.3/program/liblocaledata_es.so soffice.b 67812 peter txt VREG 4,39 558408 53751 /usr/local/OpenOffice.org1.1.3/program/liblocaledata_euro.so soffice.b 67812 peter txt VREG 4,39 291784 54103 /usr/local/OpenOffice.org1.1.3/program/liblocaledata_others.so soffice.b 67812 peter0u VBAD (revoked) soffice.b 67812 peter1u VBAD (revoked) soffice.b 67812 peter2u VBAD (revoked) soffice.b 67812 peter3u IPv4 0xc1fbf000 0t0 TCP *:* (CLOSED) soffice.b 67812 peter4u PIPE 0xc26cfd8016384 ->0xc26cfe2c, cnt=1, in=1 soffice.b 67812 peter5u PIPE 0xc26cfe2c0 ->0xc26cfd80 soffice.b 67812 peter6u unix 0xc1f018dc 0t0 ->(none) soffice.b 67812 peter7u VCHR 240,0 0t0 31 /dev/dri/card0 soffice.b 67812 peter8rR VREG 4,39 3571712 53511 /usr/local/OpenOffice.org1.1.3/program/types.rdb soffice.b 67812 peter9rR VREG 4,39 3145728 54253 /usr/local/OpenOffice.org1.1.3/program/services.rdb soffice.b 67812 peter 10u unix 0xc293c144 0t0 /tmp/OSL_PIPE_204_SingleOfficeIPC_d5f5c59e4f9863b9649fb08a1fc2a3eb soffice.b 67812 peter 11r VREG 4,39 455664 53566 /usr/local/OpenOffice.org1.1.3/program/resource/ofa64501.res soffice.b 67812 peter 120xc3dfb044 file struct, ty=0, op=0xc06e29c0 soffice.b 67812 peter 13r VREG 4,39 217794 54263 /usr/local/OpenOffice.org1.1.3/program/resource/iso64501.res soffice.b 67812 peter 14r VREG 4,39 312626 53972 /usr/local/OpenOffice.org1.1.3/program/resource/svx64501.res soffice.b 67812 peter 15r VREG 4,39 335110 54078 /usr/local/OpenOffice.org1.1.3/program/resource/sfx64501.res soffice.b 67812 peter 16r VREG 4,3943664 53433 /usr/local/OpenOffice.org1.1.3/program/resource/basctl64501.res soffice.b 67812 peter 17u VREG 4,3411497 7511489 /home/peter/seps.20050113.csv soffice.b 67812 peter 18u unix 0xc293c654 0t0 ->(none) soffice.b 67812 peter 19r VREG 4,39 553150 54133 /usr/local/OpenOffice.org1.1.3/program/resource/sc64501.res soffice.b 67812 peter 20r VREG 4,3920452 53568 /usr/local/OpenOffice.org1.1.3/program/resource/vcl64501.res soffice.b 67812 peter 21u PIPE 0xc290c18016384 ->0xc290c22c soffice.b 67812 peter 22u PIPE 0xc290c22c0 ->0xc290c180 ddb shows: 0xc3dfb044: c2243c38c2900 0 0xc3dfb054: 0 c1968d24c06e29c0c2534580 0xc3dfb064: 3 0 0 0 0xc3dfb074: 0 0 0 0 0xc3dfb084: 0 c3dfb6e8c1bf06601 67812 c2439388 d9323000 204 1 67808 028c083 stop(threaded) soffice.bin thread 0xc1e92c80 ksegrp 0xc2220690 [SUSP] thread 0xc21aa7d0 ksegrp 0xc2220690 [SLPQ spltwt 0xc1130238][SLP] thread 0xc4334960 ksegrp 0xc2220690 [SUSP] thread 0xc21b6c80 ksegrp 0xc2220690 [SUSP] thread 0xc1e8e190 ksegrp 0xc2220690 [SLPQ accept 0xc293c17e][SLP][SUSP] thread 0xc21b67d0 ksegrp 0xc2000b60 [SUSP] -- 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: SSH Protocol mismatch
On Sun, 2005-Jan-16 04:05:11 +0800, CryBaby wrote: >OS: FreeBSD 4.11-STABLE #3: Fri Jan 14 23:53:07 CST 2005 > >I ssh my host by using putty or any ssh client in WindowsXP, and I can't login >lately. (But telnet and other services are ok.) What has changed (both on FreeBSD and WinXP) since it last worked? Have you tried running sshd in a debug mode and looking at what it reports? eg "sshd -d -p 8022" and then ssh to port 8022. Use up to 3 d's for more detail. I'm not sure if PuTTY has anything equivalent to 'ssh -v' but if so, have you tried looking at what it reports? -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Purpose of CD9660_ROOT
RELENG_4 documents a config option: options CD9660_ROOT #ISO 9660 Filesystem usable as root but I am unable to find any other reference to this option. I can confirm that CD9660_ROOT is _not_ necessary for 4.10 (at least) boot off a CD-ROM and use it as root. The last reference I can find is in ARCH/ARCH/autoconf.c from whence it was deleted well before RELENG_4_BP. Have I missed something or is this option a total no-op? -- 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: User's cron job creates zombie process on 5.3
On Wed, 2005-Jan-19 09:16:59 +0900, Rob Lahaye wrote:
> tunnel="-L 55110:localhost:110 pop3.univ.net"
> tunnel_up=`pgrep -f -- "${tunnel}"`
> [ "${tunnel_up}" = "" ] && /usr/bin/ssh -N -f ${tunnel}
>It works beautifully, but why does this also generate one zombie process:
> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
> rob 655 0.0 0.0 00 ?? ZSat02PM 0:00.01
You get a zombie when a process has exited and the parent hasn't issued
a wait(2) (or SIG_IGN'd SIGCHLD). Have a look at what the parent process
is and that might give you an idea as to what is going wrong.
--
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: User's cron job creates zombie process on 5.3
On Wed, 2005-Jan-19 21:14:26 -0800, spam maps wrote:
>> ( /usr/bin/ssh -n -f ${tunnel} & )
>
>Alas, no success. Still get the zombie
>process.
>
>I actually wonder if this is an odd or buggy behaviour
>of ssh, or is cron making a mistake here?
The cron daemon (which will have a PPID of 1) forks a copy of itself
to actually handle the cron job (I suspect this is the parent of the
zombie that you are seeing). This child process runs "/bin/sh -c CRONJOB"
(where CRONJOB is the line in your crontab) and I suspect this is the
zombie you are seeing.
My guess is that your ssh process is holding open file descriptors and
the cron child process is waiting for these descriptors to close before
wait()ing for the child. If this is true, then you should avoid it
with something like:
( /usr/bin/ssh -n -f ${tunnel} >/dev/null 2>&1 & )
(or redirect to a suitable file).
>Leaving a zombie process around, means there's a kind
>of bug/mistake somewhere, right?
Yes. But it's not necessarily a bug in FreeBSD :-).
--
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: Very large directory
On Wed, 2005-Jan-19 21:30:53 -0600, Phillip Salzman wrote:
>They've been running for a little while now - and recently we've noticed a
>lot of disk space disappearing. Shortly after that, a simple du into our
>/var/spool returned a not so nice error:
>
> du: fts_read: Cannot allocate memory
>
>No matter what command I run on that directory, I just don't seem to have
>enough available resources to show the files let alone delete them (echo *,
>ls, find, rm -rf, etc.)
I suspect you will need to write something that uses dirent(3) to scan
the offending directory and delete (or whatever) the files one by one.
Skeleton code (in perl) would look like:
chdir $some_dir or die "Can't cd $some_dir: $!";
opendir(DIR, ".") or die "Can't opendir: $!";
while (my $file = readdir(DIR)) {
next if ($file eq '.' || $file eq '..');
next if (&this_file_is_still_needed($file));
unlink $file or warn "Unable to delete $file: $!";
}
closedir DIR;
If you've reached the point where you can't actually read the entire
directory into user memory, expect the cleanup to take quite a while.
Once you've finished the cleanup, you should confirm that the directory
has shrunk to a sensible size. If not, you need to re-create the
directory and move the remaining files into the new directory.
--
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: Very large directory
On Thu, 2005-Jan-20 13:36:30 -0800, Darryl Okahata wrote: > Since the original poster was willing to use -rf, wouldn't it be >better to do: > >cd /var/spool/directory ; find . -type f -print0 | xargs -0 rm -f The original poster mentioned that "find" wouldn't work: find(1) uses fts(3) which reads the entire directory into memory. -- 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: Disabling write-behind on IDE drives, and SMART
On Fri, 2005-Jan-21 09:28:37 -0800, Kevin Oberman wrote: >10 minutes (or even 1 minute) would be fine IF you have the system >shutdown when the main power fails, but if the system is unattended and >active and power goes out, it will simply keep going until the UPS dies >and will still leave your disk in a bad state. > >The right answer is to run nut or other UPS monitor to shutdown the >system when power fails. Agreed. ACPI helps enormously here. When implementing this, remember to ensure that things recover when mains power is restored in the interval between when the UPS says "I'm about to die, shutdown now" and when it actually dies. > Or, better still, have generator backed power >with about an hour of UPS to give the generator time to get up to speed >and on-line. Huh? Most generators take a lot less than an hour to get going. 15-30 seconds would be a typical value. If your backup generator takes an hour to start, it is probably overdue for servicing :-). > But that is still less than perfect. Generators fail, are >often not tested regularly, and will eventually run out of fuel. If this is important to you then it needs to be covered as part of your business continuity or disaster recovery plan. -- 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....
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 (<http://www.freebsd.org/cgi/query-pr.cgi?pr=34236&f=raw>) 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]"
Re: NIC card problems....
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: [HEADS UP] perl symlinks in /usr/bin will be gone
On Sat, 2005-Jan-29 21:24:25 +0100, Anton Berezin wrote: >In practical terms this will mean a one-time sweep of your scripts in >order to convert them, in a typical case, from #! /usr/bin/perl to >#! /usr/local/bin/perl. I'd also like to object. The perl documentation has consistently stated that a symlink to /usr/bin/perl should be created so that scripts can use #!/usr/bin/perl. Removing this symlink will impact users as well as administrators and (IMHO) will adversely impact on the image of FreeBSD. -- 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: 50% of packets lost only on local interfaces
On Mon, 2005-Feb-07 17:05:39 -0600, Jon Noack wrote: >José M. Fandiño wrote: >>Jon Noack wrote: >>>>>> Finally, I found the culprit: >>>>>> >>>>>>CFLAGS="" \ 100% of the transmited traffic is received >>>>>>COPTFLAGS="" / >>>>>> >>>>>>CFLAGS= -pipe \ 50% of the transmited traffic is received >>>>>>COPTFLAGS= -pipe / It would be quite interesting to compare the actual commands that are generated: Capture the buildworld/kernel output and compare the same command in both cases. If the only difference is really just "-pipe", then we need to do some more investigating. >The explanation I've heard (I have no actual knowledge here, I'm just >good at repeating others) is that gcc doesn't compile any ASM with -O0 >(which is what you get with CFLAGS="-pipe"). This Breaks Things(tm): There used to be inconsistencies in the way gcc handle asm() statements so that it could be difficult to write asm() statement constraints that worked correctly with both -O0, -O1 and -O2 but it never ignored asm() statements. (I haven't looked since about 2.95 so I'm not sure if the 3.x series fixed this problem) >http://docs.freebsd.org/cgi/mid.cgi?20020623214947.J84322 The error message quoted in this article refers to the constraint problem above. The problem was not asm() was being ignored (or that incorrect code was generated) but that the compiler incorrectly reported errors (and failed to compile the code). (I recognize that function name - I spent weeks trying to come up with a constraint set that worked with both -O0 and -O1 and eventually gave up). Since you have managed to compile a kernel, I very much doubt you are running into the same problem. >kern/52764 is another example: >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/52764 Again, this is a "fails to compile" report, not a "generates incorrect code" report. The code in question was written on the assumption that the compiler would do dead code removal and "gcc -O0" doesn't. >More generically it makes sense that gcc treat code differently with -O0 >than with -O. By definition, it has to - otherwise the generated code would be the same. -- 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: Save the Demon!
On 2005-Feb-10 04:39:13 +0100, Bj?rn K?nig <[EMAIL PROTECTED]> wrote: >David Magda wrote: > >>It's "daemon", not "demon". Or even "dæmon" >It's a question whether you are British or American or understand it as >a proper name. ;-) My dictionary has both as headwords with a reference from demon to daemon (but not vice versa) and lists "a service program that is called into action by the operating system" under daemon. The etymology is from greek "daimon" via latin "daemon". -- 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: mktime() bug? result strtotime() fail in PHP
On Fri, 2005-Feb-11 21:16:00 -0200, Marcus Grando wrote: >I have problems with mktime() on FreeBSD 4.11-STABLE and daylight timezone. > >My timezone is "America/Sao_Paulo", daylight begin on 2004-11-02 00:00 >and terminate on 2005-02-20 00:00. > >The problem is: >If run this code[1] on FreeBSD 4.11-STABLE, then return -1, if run on >FreeBSD 5.3-STABLE, then return 1099364400 (correct) and if run on >Linux, then return 1099364400 (correct). To be pedantic, FreeBSD 4.11 is correct and the others are wrong. If DST started at 2004-11-02 00:00 local time then you can't convert a local time of 2004-11-02 00:00:00 because that time doesn't exist - your local time goes 2004-11-01 23:59:59, 2004-11-02 01:00:00, 2004-11-02 01:00:01. server% TZ=':/usr/share/zoneinfo/America/Sao_Paulo' perl -e 'print scalar localtime 1099364400,"\n";' Tue Nov 2 01:00:00 2004 server% TZ=':/usr/share/zoneinfo/America/Sao_Paulo' perl -e 'print scalar localtime 1099364399,"\n";' Mon Nov 1 23:59:59 2004 server% -- 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: mktime() bug? result strtotime() fail in PHP
On Mon, 2005-Feb-14 10:05:50 -0200, Marcus Grando wrote: >Peter Jeremy wrote: >>To be pedantic, FreeBSD 4.11 is correct and the others are wrong. If > ^^ >Also FreeBSD 5.3-STABLE? I don't have a 5.3-STABLE system to confirm but if it doesn't return -1 it is wrong. >>DST started at 2004-11-02 00:00 local time then you can't convert a local >>time of 2004-11-02 00:00:00 because that time doesn't exist - your local >>time goes 2004-11-01 23:59:59, 2004-11-02 01:00:00, 2004-11-02 01:00:01. > >I know, but timestamp return is better of that -1. What timestamp should it return? 2004-11-02 00:00:00 doesn't exist for you, therefore there is no possible value for seconds since epoch that will convert to this time. The manpage states: until tm_mon and tm_year are determined. The mktime() function returns the specified calendar time; if the calendar time cannot be represented, it returns -1; Since 2004-11-02 00:00:00 cannot be represented, then it should return -1. Maybe you should explain why having mktime() correctly report an error is a problem for you. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Excessive delays due to syncer kthread
I am trying to do some video capture and have been losing occasional fields. After adding some debugging code to the kernel, I've found that the problem is excessive latency between the hardware interrupt and the driver interrupt - the hardware can handle about 1.5msec of latency. Most of the time, the latency is less than 20µsec but but I'm seeing up to 8 msec occasionally. In virtually all cases where there is a problem, curproc at the time of the hardware interrupt is syncer. (I had one case where there was another process, but it had died by the time I went looking for it). The interrupt is marked INTR_TYPE_AV so it shouldn't be being delayed by other threads. (I can't easily make it INTR_FAST because it needs to call psignal(9)). The system is an Athlon XP-1800 with 512MB RAM and 2 ATA-100 disks running 5.3-RELEASE-p5. It has a couple of NFS exports but doesn't import anything. There's nothing much running apart from ffmpeg capturing the video and a process capturing my kernel debugging output. Apart from 4 files being sequentially written as part of my capture and cron regularly waking up to go back to sleep, there shouldn't be any filesystem activity. I tried copying a couple of large files and touching lots of files but that didn't cause any problems. Can anyone suggest why syncer would be occasionally running for up to 8 msec at a time? Overall, it's not clocking up a great deal of CPU time, it just seems to grab it in large chunks. Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Excessive delays due to syncer kthread
On Sat, 2005-Feb-26 11:24:26 +, Robert Watson wrote: >I don't have too much insight into the syncer (I've CC'd phk to victimize >him with more e-mail as this is an area he takes great interested in). A >couple of questions: > >(1) Have you tried turning on options PREEMPTION? I haven't yet. I will look at this but some of the mailing list comments made me think it wasn't totally reliable yet. >(2) Does the driver code run with Giant at all? Yes. It's marked INTR_MPSAFE and never grabs Giant. The only locking it needs is PROC_LOCK (and that's only for psignal(9)). >(3) Are you relying on callouts or taskqueues at all for processing? No. >running though. So using preemption and Giant-free code, we should be >able to get your driver code in kernel to run on short deadline, but >getting the syncer to behave better will be necessary to get the user code >running on short deadline. The userland code is less of a problem. The hardware can fit 3-6 frames (depending on depth) into a shared ring buffer - which gives me 60-120msec for the user code to wake up (100msec at the depth I will normally use). The problem is that the hardware can't autonomously move between entries in the ring buffer so the interrupt handler needs to re-write some device registers during the vertical blanking period (~1.6msec). Thanks for your input. -- 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: Excessive delays due to syncer kthread
On Sat, 2005-Feb-26 19:28:29 -0800, Kris Kennaway wrote: >I don't think there are known problems with use of PREEMPTION on >RELENG_5. Thanks for that. How about RELENG_5_3? Do I need to move to -STABLE (and traditionally, this point of the release cycle is not a good time to be running -STABLE). -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Crash when PREEMPTION enabled
I have tried enabling PREEMPTION on 5.3-RELEASE-p5 whilst it ran OK
for a few hours, it crashed overnight whilst doing a "make index" in
/usr/ports. I've tried repeating "make index" and it worked. I have
a coredump of the crash and have been doing some poking around.
A backtrace (with the nonsense "frames" deleted) is:
#8 0xc06775e2 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 4, tf_esi = -1011675136,
tf_ebp = -663303504, tf_isp = -663303576, tf_ebx = 65538, tf_edx = -1040411904,
tf_ecx = -1011675136, tf_eax = 25, tf_trapno = 12, tf_err = 0, tf_eip = 8,
tf_cs = 8, tf_eflags = 66050, tf_esp = -1068017362, tf_ss = -663303532})
at /usr/src/sys/i386/i386/trap.c:417
#9 0xc0664ada in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#26 0xc057592e in vn_lock (vp=0xc3b31000, flags=65538, td=0xc1cc0640)
at vnode_if.h:1013
#27 0xc0567636 in vget (vp=0xc3b31000, flags=2, td=0x0)
at /usr/src/sys/kern/vfs_subr.c:2028
#28 0xc055a4aa in vfs_cache_lookup (ap=0x0)
at /usr/src/sys/kern/vfs_cache.c:723
#29 0xc061a2a8 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2816
#30 0xc055fdce in lookup (ndp=0xd876cc24) at vnode_if.h:52
#31 0xc055f7bb in namei (ndp=0xd876cc24) at /usr/src/sys/kern/vfs_lookup.c:181
#32 0xc056f042 in stat (td=0xc1cc0640, uap=0xd876cd14)
at /usr/src/sys/kern/vfs_syscalls.c:2034
#33 0xc06780d0 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 134964334,
tf_ebp = -1077946296, tf_isp = -663302796, tf_ebx = 134964320, tf_edx =
134964320, tf_ecx = 134964320, tf_eax = 188, tf_trapno = 12, tf_err = 2, tf_eip
= 134643347, tf_cs = 31, tf_eflags = 582, tf_esp = -1077946452, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1001
#34 0xc0664b2f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201
It appears that vn_lock() has called VOP_LOCK() but v_op is pointing to
an array of garbage. Apart from the memory at v_op, the vnode looks
reasonably sane:
(kgdb) p *(struct vnode *)0xc3b31000
$1 = {v_interlock = {mtx_object = {lo_class = 0xc06e583c,
lo_name = 0xc06b89b9 "vnode interlock",
lo_type = 0xc06b89b9 "vnode interlock", lo_flags = 196608, lo_list = {
tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0},
mtx_lock = 3251373632, mtx_recurse = 0}, v_iflag = 0, v_usecount = 1,
v_numoutput = 0, v_vxthread = 0x0, v_holdcnt = 1, v_cleanblkhd = {
tqh_first = 0xcbf84bc4, tqh_last = 0xcbf84c64},
v_cleanblkroot = 0xcbf84bc4, v_cleanbufcnt = 1, v_dirtyblkhd = {
tqh_first = 0x0, tqh_last = 0xc3b31048}, v_dirtyblkroot = 0x0,
v_dirtybufcnt = 0, v_vflag = 8, v_writecount = 0, v_object = 0xc36d4ad4,
v_lastw = 0, v_cstart = 0, v_lasta = 0, v_clen = 0, v_un = {
vu_mountedhere = 0x0, vu_socket = 0x0, vu_spec = {vu_cdev = 0x0,
vu_specnext = {sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_freelist = {
tqe_next = 0xc2719210, tqe_prev = 0xc39e5ef8}, v_nmntvnodes = {
tqe_next = 0xc39cfd68, tqe_prev = 0xc24d9df8}, v_synclist = {
le_next = 0xc3ae1840, le_prev = 0xc3b151a0}, v_type = VREG,
v_tag = 0xc06b7244 "ufs", v_data = 0xc270c690, v_lock = {
lk_interlock = 0xc070cc94, lk_flags = 16777280, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 80,
lk_wmesg = 0xc06b7244 "ufs", lk_timo = 6, lk_lockholder = 0x,
lk_newlock = 0x0}, v_vnlock = 0xc3b310ac, v_op = 0xc1fc9300,
v_mount = 0xc1bb4000, v_cache_src = {lh_first = 0x310}, v_cache_dst = {
tqh_first = 0xc358e3b8, tqh_last = 0xc358e3c8}, v_id = 362047,
v_dd = 0xc3b31000, v_ddid = 0, v_pollinfo = 0x0, v_label = 0x0,
v_cachedfs = 1057, v_cachedid = 6630696, v_bsize = 16384}
Anyone have any ideas?
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Duplicated hardware interrupts
Whilst tracking down some interrupt latency problems, I've found that I'm getting duplicate interrupts from some, but not all, devices. The double interrupts appear to always occur for some IRQs and never occur on others. Based on those symptoms, I wonder if there's a hardware issue. The system is a GigaByte GA-7VRX-P motherboard (VIA KT333) with an Athlon XP-1800 running 5.3-RELEASE-p5 with APIC and ACPI: CPU: AMD Athlon(tm) XP 1800+ (1533.40-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc048 real memory = 536805376 (511 MB) avail memory = 515629056 (491 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard ... acpi0: on motherboard I'm not seeing duplicate interrupts on atkbd0, rtc, fdc0, psm0 and ata0. I am seeing duplicate interrupts on drm0, rl0 and my video capture card. FWIW, the kernel code I'm using to check the interrupts is attached. Userland just mmap's the buffer, converts it to ASCII and dumps it to disk for later processing. Has anyone else seen anything like this? -- 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: kernel config: sound device with or without quotes
On Wed, 2005-Mar-02 02:46:41 -0800, Rob wrote:
>In /usr/src/sys/conf/NOTES is the list of supported
>sound devices. I get confused by the pressence and
>absence of quotes here. Are these quotes only
>decoration, or really needed. For example:
>
>device "snd_ad1816"
>device snd_cmi
>
>If they are needed, it confuses me why one sound
>device needs quotes, and another doesn't?
For hysterical raisins, config(8) parses bareword arguments to "device" as
($device_name, $device_instance) = /([a-zA-Z_]+)([0-9]*)/;
The double quotes force the first entry to be treated as a device
"snd_ad1816", rather than the 1817th instance of "snd_ad".
>How does that affect the use of loading them in
>/boot/loader.conf? How about following two:
>
>snd_ad1816_load="YES"
>snd_cmi_load="YES"
>
>Is that OK?
Yes. The loader has a different parsing algorithm:
${device_name}_load="{YES,NO}"
and
hint.$device_name.$device_instance.flag="VALUE"
--
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: 1000baseTX?
On Fri, 2005-Mar-04 23:39:36 -0800, Doug White wrote:
>On Thu, 3 Mar 2005, Yoshiaki Kasahara wrote:
>
>> In man pages, dmesg and ifconfig of FreeBSD5, GbE operation over
>> twisted pair is mostly referred as '1000baseTX'. I guess most of them
>> should be replaced by '1000baseT'. 1000base"TX" and 1000base"T" are
>> different standard and they are not compatible ("TX" needs CAT6 cable
>> and uses pairs in different way). Also 1000baseTX support is very
>> rare yet. I'm sorry I'm not sure if some devices really support "TX".
>
>Do you have any documentation to back up this claim?
I'm not sure about the pairing but there are two distinct standards
for gigabit ethernet over UTP. Try typing "1000base-t 1000base-tx
differences" (without the quotes) into Google.
--
Peter Jeremy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
alpm0: Could not allocate Bus space
I'm trying to resurrect an Asus P5A-B system and the power management is failing. The relevant parts of the dmesg are: FreeBSD 5.3-RELEASE-p5 #2: Sat Mar 5 21:54:19 EST 2005 ... bios32: Found BIOS32 Service Directory header at 0xc00f9b80 bios32: Entry = 0xf0530 (c00f0530) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x560 pnpbios: Found PnP BIOS data at 0xc00fcfb0 pnpbios: Entry = f:cfe0 Rev = 1.0 pnpbios: OEM ID cd041 acpi0: on motherboard acpi0: [MPSAFE] ... found-> vendor=0x10b9, dev=0x7101, revid=0x00 bus=0, slot=3, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) ... alpm0: at device 3.0 on pci0 alpm0: host/noslave 74K alpm0: 0x20 bytes of rid 0x14 res 4 failed. alpm0: Could not allocate Bus space device_attach: alpm0 attach returned 6 I've had a look through the archives but not been able to find this problem. Has anyone else seen it and how would I go about fixing it? -- 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: alpm0: Could not allocate Bus space
No bites from anyone else... On Tue, 2005-Mar-08 20:34:05 +1100, Peter Jeremy wrote: >alpm0: at device 3.0 on pci0 >alpm0: host/noslave 74K >alpm0: 0x20 bytes of rid 0x14 res 4 failed. The request winds up with acpi_alloc_resource() and it returns NULL because its resource list ( device_get_ivars(alpm0)->ad_rl ) is NULL. If I disable ACPI then alpm0 attaches correctly. Does this make sense? Is the SMB interface incompatible with ACPI? -- 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: Slow Tomcat startup...
On Tue, 2005-Mar-15 15:35:03 +0100, Jiri Novak wrote: >I'm having troubles with FreeBSD 5.3-RELEASE-p5 on amd64, with Apache2 >and Tomcat 5.0.30 (jdk1.5.0) installed. The problem I'm experiencing is >very strange - Tomcat startup times are very very long, about 3-4 >minutes, with three virtual hosts. I can't offer you a solution but I can make some suggestions on where to look: 1) What is the system doing during this 3-4 minutes? Do "top" and "vmstat -v" show anything interesting? 2) Have you tried starting one instance of apache/tomcat outside a jail? -- 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: undefined reference to `memset'
On Wed, 2005-Mar-23 13:48:04 -0800, Vinod Kashyap wrote:
>If any kernel module has the following, or a similar line in it:
>-
>char x[100] = {0};
>-
>building of the GENERIC kernel on FreeBSD 5 -STABLE for amd64
>as of 03/19/05, fails with the following message at the time of linking:
>"undefined reference to `memset'".
>
>The same problem is not seen on i386.
>
>The problem goes away if the above line is changed to:
>-
>char x[100];
>memset(x, 0, 100);
>-
Can you post a complete (compilable) example please. Based on your
second example, I suspect that you are putting the variable
declaration inside a function definition - the second example doesn't
make sense outside a function.
If I add "char x[100] = {0};" into a function on i386 and compile it
as a kernel module on 5.3, a static memset symbol is generated - it's
possible that the amd64 compiler gets confused about the implicit
reference to memset that this code needs.
--
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: undefined reference to `memset'
On Thu, 2005-Mar-24 12:03:19 -0800, Vinod Kashyap wrote:
[ char x[100] = { 0 }; ]
>A statement like this (auto and not static)
I'd point out that this is the first time that you've mentioned that
the variable is auto. Leaving out critical information will not
encourage people to help you.
> is necessary if you
>are dealing with re-entrancy.
This isn't completely true. The preferred approach is:
char*x;
x = malloc(100, MEM_POOL_xxx, M_ZERO | M_WAITOK);
(with a matching free() later).
> Whatever the issues with wastage or
>bad performance, a programmer should definitely be able to do it,
>if he so desires.
Again, untrue. The FreeBSD kernel is not a standard C environment.
Kernel stack is a relatively small, fixed size and using excessive
kernel stack will lead to panics. Increasing the kernel stack size is
undesirable because it's expensive in RAM consumption.
>How is it then, that an explicit call to memset (like in my example) works?
The code
auto char x[100] = {0};
is equivalent to
auto char x[100];
memset(x, 0, sizeof(x));
but memset only exists as a static inline function (defined in libkern.h).
If an explicit call to memset works then the problem would appear to be
that the compiler's implicit expansion is failing to detect the static
inline definition, and generating an external reference which can't be
satisfied. This would seem to be a gcc bug.
>2. I should have mentioned that I don't see the problem if I am
> building only the kernel module. It happens only when I am building
> the kernel integrating the module containing the example code.
This is the opposite of what you implied previously. There are some
differences in how kernel modules are built so this
How about posting a (short) compilable piece of C code that shows the
problem. I would expect that an "nm" of the resultant object would
show "U memset" when the code was compiled for linking into the kernel
and " t memset" or not reference memset at all when
compiled as a module.
--
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: syscons options and memory use
On Thu, 2005-Mar-31 09:53:59 +0200, Ronald Klop wrote: >>In the last episode (Mar 31), Ronald Klop said: >>>The syscons manual page says: >>>"The following options will remove some features from the syscons >>> driver and save kernel memory. >>> [...] >>> SC_NO_SYSMOUSE >>>This option removes mouse support in the syscons driver. >>>The mouse daemon moused(8) will fail if this option is >>>defined. This option implies the SC_NO_CUTPASTE option >>>too. >>>" >>> >>>How much memory does this save (or how can I discover that)? Is it worth >>>it on a 96MB PentiumII laptop? It basically removes scmouse.c, sysmouse.c and a largish chunk of code in scvgarndr.c - my estimate is about 9KB. You can probably do better looking elsewhere. For loadable devices, looking at the module size is a good guideline. >How can I see the size of my kernel? server% size /boot/kernel/kernel textdata bss dec hex filename 3045945 229911 978784 4254640 40ebb0 /boot/kernel/kernel server% Remember that this doesn't include dynamic memory allocated by the kernel which can be quite significant. Look at the "real memory" and "avail memory" lines in your boot dmesg to get a better idea of the basic kernel memory requirements. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kernel NTP flipping between FLL and PLL modes
My 5.x machines are regularly reporting that the kernel is flipping between FLL and PLL mode (as shown by STA_MODE in syslog messages). This isn't occuring on my 4.x machines (they typically report 2040 then 2041 and stay indefinitely in that mode). Any suggestions as to why this is happening? (And how I can stop it regularly flipping) A fairly typical set of syslog entries looks like: Apr 1 00:15:16 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 00:32:22 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 01:23:36 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 01:40:42 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 10:09:10 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 10:26:14 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 12:59:58 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 13:51:14 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 16:07:48 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 16:59:06 fwall2 ntpd[407]: kernel time sync enabled 2001 Apr 1 19:15:42 fwall2 ntpd[407]: kernel time sync enabled 6001 Apr 1 19:49:48 fwall2 ntpd[407]: kernel time sync enabled 2001 -- 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: Kernel NTP flipping between FLL and PLL modes
On Fri, 2005-Apr-01 19:38:41 +0300, Andriy Gapon wrote: >I can second that. I have never seen anything like this with 5.2.1 as >soon as I upgraded to 5.3 I started seeing messages like these: ... >Mar 29 22:15:40 oddity ntpd[400]: time reset -0.288522 s >Mar 29 22:15:40 oddity ntpd[400]: kernel time sync enabled 6001 >Mar 29 23:09:19 oddity ntpd[400]: time reset +0.530732 s >Mar 29 23:09:19 oddity ntpd[400]: kernel time sync enabled 2001 >Mar 29 23:35:18 oddity ntpd[400]: time reset -0.165853 s >Mar 30 00:41:14 oddity ntpd[400]: time reset -0.199104 s >Mar 30 11:21:21 oddity ntpd[400]: kernel time sync enabled 6001 >Mar 30 11:38:27 oddity ntpd[400]: kernel time sync enabled 2001 >Mar 30 17:22:37 oddity ntpd[400]: time reset -0.392425 s >Mar 30 17:22:37 oddity ntpd[400]: kernel time sync enabled 6001 >Mar 30 17:26:06 oddity ntpd[400]: kernel time sync enabled 2001 >Mar 30 17:28:15 oddity ntpd[400]: time reset +0.309711 s >Mar 30 18:07:02 oddity ntpd[400]: time reset +0.164515 s >Mar 30 18:41:43 oddity ntpd[400]: time reset -0.391355 s >Mar 30 19:00:17 oddity ntpd[400]: time reset +0.598313 s >Mar 30 19:47:45 oddity ntpd[400]: time reset -0.276978 s >Mar 30 21:26:24 oddity ntpd[400]: time reset +0.158781 s >Mar 30 23:18:01 oddity ntpd[400]: time reset +0.160708 s ... >2001<->6001 flips do not trouble me a bit (but annoying), time resets >are not a good thing definitely. I've seen similar reset behaviour in the past. The investigating I did suggested that the PLL could become unstable under some conditions (though I never managed to work out exactly what triggered the mis-behaviour). It would either lock up around +/- 500ppm and regularly jump in one direction to compensate or it would start swinging wildly and regularly jump back and forth with the net time jumped close to zero (in the latter case, looking at the loopstats showed that the frequency offset would start oscillating with the swings getting larger over time). Manually setting ntp.drift to a realistic value and restarting ntpd seemed to cure the problem (at least temporarily). I haven't seen that problem recently - I think it was in the early 4.x period. >I suppose that it might be possible that the root cause is in my local >network conditions, If it is network conditions, enabling huff-puff might help. If possible, work out what the real drift on that system is and re-initialise ntp.drift as well. -- 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: Kernel NTP flipping between FLL and PLL modes
On Tue, 2005-Apr-05 15:01:07 +0300, Andriy Gapon wrote:
>on 01.04.2005 20:40 Bob Bishop said the following:
>>
>> Unlikely I think. As I said, I've got several machines on the same LAN:
>> the 5.3's misbehave; the others don't.
>
>#define CLOCK_ALLAN 1500.
>...
>doubleallan_xpt = CLOCK_ALLAN;
>...
>if (ULOGTOD(sys_poll) > allan_xpt / 2) {
>...
>
>if I understand the above "random" lines of code in
>contrib/ntp/ntpd/ntp_loopfilter.c correctly, then PLL<->FLL switch
>occurs when polling interval goes 512<->1024, which is perfectly
>possible under certain conditions with default ntp settings: minpoll=64,
>maxpoll=1024 if ntp.conf(5) can be trusted.
Note that this code doesn't exist in 5.3. It was introduced sometime
between 5.3 and 5.4. In any case, looking at the associated comments,
this only affects the FLL/PLL loop gain.
The FLL/PLL switch is set is in sys/kern/kern_ntptime.c:hardupdate()
using:
time_status &= ~STA_MODE;
if (mtemp >= MINSEC && (time_status & STA_FLL || mtemp > MAXSEC)) {
L_LINT(ftemp, (time_monitor << 4) / mtemp);
L_RSHIFT(ftemp, SHIFT_FLL + 4);
L_ADD(time_freq, ftemp);
time_status |= STA_MODE;
}
and this code hasn't changed. MINSEC is 256 (which matches the comments)
MAXSEC is either 1200 or 2048 (depending on which header file is active),
though the comments imply it is 1024. mtime is the time since the last
adjustment (call to hardupdate()).
STA_FLL is set in ntpd/ntp_loopfilter.c:
if (sys_poll > NTP_MAXDPOLL)
ntv.status |= STA_FLL;
though the associated comment states "for legacy only". (And I'm
never seeing STA_FLL transitions in syslog). This sets STA_FLL if the
polling interval is > 2^10 (1024). By default, sys_poll is limited to
NTP_MAXDPOLL so this should never occur. (You can over-ride it with
"maxpoll N" on peer/server config lines).
--
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: 5.4-RC1 Freezing, but pingable (may be related to gvinum)
On Sat, 2005-Apr-09 14:51:41 -0500, Ash wrote: >By "hang" I mean that the machine stops responding to console keystrokes >(serial or otherwise) while existing ssh and nfs connections stop >responding, but do not immediately close. The machine continues to >respond to ICMP pings. I can not make new SSH connections and my >attempts eventually timeout rather than giving me a connection refused >error. This is consistent with the kernel continuing to run normally but being unable to schedule userland processes - usually due to a deadlock. Do the caps-lock, num-lock, scroll-lock buttons on a local keyboard still toggle the relevant LEDs? Assuming the LEDs toggle: Do you have "options DDB" and "options KDB" in your kernel? If so, can you break into DDB? (If not, I think you'll need to build a kernel with DDB). Once the system has hung, you need to enter DDB and run 'ps'. The output from that will give (hopefully) give an indication as to what is going wrong (and where to look next). If you've build the kernel with debugging symbols and got a dump device enabled, "call doadump()" should also generate a crashdump which will be much easier to examine. Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Deadlock in 5.3p5
My son's computer deadlocked last night. "show lockedvnods" in DDB showed: Locked vnodes 0xc1669840: tag ufs, type VDIR, usecount 8, writecount 0, refcount 2, flags (VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc18ed000 (pid 9666) with 7 pending ino 2, on dev ad0s1g (4, 25) 0xc1682000: tag ufs, type VDIR, usecount 5, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fd000 (pid 15686) with 1 pending ino 23552, on dev ad0s1g (4, 25) 0xc1b30d68: tag ufs, type VDIR, usecount 2, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc268f000 (pid 9075) with 1 pending ino 122986, on dev ad0s1g (4, 25) 0xc1c3c210: tag ufs, type VDIR, usecount 3, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc16fe4b0 (pid 9067) with 1 pending ino 142022, on dev ad0s1g (4, 25) 0xc1e2ce70: tag ufs, type VREG, usecount 6, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: SHARED (count 1) with 1 pending ino 142169, on dev ad0s1g (4, 25) After poking around in the crashdump for a while, I've worked out that the process holding each of the above exclusive locks is waiting on the next lock in the list. Unfortunately, there doesn't appear to be any way to work out which process is holding the shared lock unless DEBUG_LOCKS is set (and even this doesn't work if the lock was implicitly downgraded by a process calling lockmgr(LK_SHARED) when it holds an exclusive lock). FWIW, the affected inodes are: 2 /usr 23552 /usr/local 122986 /usr/local/OpenOffice.org1.1.4 142022 /usr/local/OpenOffice.org1.1.4/program 142169 /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so Does anyone have any ideas on how to track this further (or so I just write it off as a glitch). -- 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: [bugs] Misleading security message output
On Thu, 2005-Apr-14 13:04:36 +1000, Andrew Reilly wrote: [Unexpected failed login reports in security messages] > >After much hunting around, and checking perimeter logs, it >turned out that nothing of the sort had happened. The security >log script had been fooled by the age of the messages.0.gz file, >which contained messages from more than a year ago. I was bitten at home and worked out what happened. So when the same problem showed up at work, I knew what had happened. > It can be worked-around by forcing faster log-file rotations, That's the solution I used. -- 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: Enabling HTT On A Uniproc w/4.11-Stable
On Sun, 2005-Apr-17 01:50:51 -0500, Tim Daneliuk wrote: >How do I enable hyperthreading on a Uniprocessor p4 system. >I tried my usual SMP kernel options (SMP and APIC) but, of course, >the kernel cannot find an APIC. I have set the appropriate option >in loader.conf to enable hyperthreading but, No Joy. Should I >use the SMP option alone here? You definitely need APIC for SMP and the APIC is part of the iA32 spec so I'm sure you have one somewhere. At a quick guess, I suspect you haven't enabled the APIC in your BIOS - check for an option that allows you to select between PIC and APIC interrupt types. If that's not the problem, we need more information: Motherboard/BIOS type and at least the beginning of a verbose boot (down to about the pci0 probe). -- 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: Deadlock in 5.3p5
On Wed, 2005-Apr-20 19:33:43 -0700, Doug White wrote: >On Sat, 16 Apr 2005, Peter Jeremy wrote: >> 0xc1e2ce70: tag ufs, type VREG, usecount 6, writecount 0, refcount 0, flags >> (VV_OBJBUF), lock type ufs: SHARED (count 1) with 1 pending >> ino 142169, on dev ad0s1g (4, 25) ... >> 142169 /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so >> >> Does anyone have any ideas on how to track this further (or so I just >> write it off as a glitch). > >This is the old "race to root" that happens at the end of the death >spiral. You need to know why the guy holding tte library lock isn't >letting go of it. How can I find out which process is holding the library lock? It's a shared lock and there doesn't appear to be any record kept of processes seizing shared locks. -- 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: dump woes
On Thu, 2005-Apr-21 23:07:48 -0400, Dan Ponte wrote: >I'm having a rather strange predicament with dump(8). First, I tried >dumping a snapshot to a file within the filesystem being dumped like so: > > styx# dump -0u -a -L -C 8 -f /usr/backup/usr.dump /usr > >I then let it sit for a while. The filesystem was only 4.1GB, but the >dump file was growing to almost 12GB! Try running fsck on the filesystem. It's possible that there's some corruption that's confusing dump. -- 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: Preposterous errno values from kernel
On Thu, 2005-Apr-21 22:04:01 -0700, Kris Kennaway wrote: >I'm getting this on a RELENG_5_4 sparc64 system (e4500): > ># rm -rf * >/bin/rm: Unknown error: 7283. Cute. Does it affect anything other than /bin/rm? Is /bin/rm sane (not some random junk that's confusing the ELF loader)? Is this an SMP system (which might point to locking problems)? If this seems consistent (other than the actual errno reported), the quickest solution would seem to be to use DDB (or kernel GDB) to follow the execution path from execve() until it goes off the rails. -- 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: background_fsck=no does not work?
On Mon, 2005-Apr-25 14:19:00 -0400, Bill Moran wrote: >Actually, I have seen a similar problem on 5.x WRT OpenOffice ... >0. OpenOffice hangs and cant' be killed >1. Reboot system >2. System claims all buffers flushed, then just hangs >3. After hardbooting, filesystems need fscked This sounds like the fault might be related to the deadlock I reported in http://lists.FreeBSD.org/pipermail/freebsd-stable/2005-April/013839.html In my case, OO.org was definitely involved, and it appears to have become unkillable before /usr locked up. Two of the locks were: - A shared lock on /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so - /usr/local/OpenOffice.org1.1.4/program/pagein holding an exclusive lock on /usr/local/OpenOffice.org1.1.4/program and wanting an exclusive lock on /usr/local/OpenOffice.org1.1.4/program/libpsp645fi.so I have no idea what "pagein" is supposed to do but I can't see any good reason for it wanting to lock an OO.org shared library. I have the crashdump lying around in case anyone can suggest somewhere to look for the cause. -- 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: Performance issue
On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote: >I have what I think is a serious performance issue with fbsd 5.3 >release. I've read about threading issues, and it seems to me that >that is what I'm looking at, but I'm not confident enough to rule out >that it might be a hardware issue, a kernel configuration issue, or >something to do with the python port. There does appear to be a problem in FreeBSD. Python is built with threading enabled by default, the threading libraries play with the signal mask and there have been extensive changes there. My suggestions on things you could check are: 1) Rebuild python with threading disabled (add '-DWITHOUT_THREADS' to the 'make' command line and see if that makes any difference 2) Re-write the sample program in a non-threaded language - eg C or perl and see if the high system time goes away. Unfortunately, I can't think of a solution at present. -- 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: 5.4-RC2 freezing - ATA related?
On Mon, May 16, 2005 at 06:40:01AM -0600, Elliot Finley wrote: >The system freezes, but isn't totally dead. It'll still respond to pings, >the screensaver still functions, but it won't respond to a CAD at the >console. But if I press 'Enter' at the console, it'll give me a 'login:' >prompt, but after entering the username, it never comes back with the >'password:' prompt. ... >On my lightly loaded systems, it happens rarely. On my mailserver (fairly >heavy disk load), it happens quite frequently. This could equally be a filesystem deadlock (race-to-root) rather than something in the ATA controller. Do you know if it happens gradually (starts with one or two non-responsive, unkillable processes and gets worse until nothing happens)? >How can I troubleshoot this? Re-compile the kernel with: options KDB options DDB makeoptions DEBUG=-g and ensure you have a "dumpdev" in /etc/rc.conf. When you get a lockup, drop to DDB (Ctrl-Alt-ESC) and run "show lockedvnods", "ps" and "call doadump()". If you post the output (a serial console will help here) someone might be able to provide more pointers. (The crashdump will help with later debugging). Note: If you don't have another FreeBSD system handy, a hard copy of ddb(4) will be very handy if you want to play around in DDB. -- Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alright you primitive screwheads, LISTEN UP!!
On Mon, May 16, 2005 at 05:58:04PM -0400, Chuck Swiger wrote: >This smells like a "joe job", a forged posting intended as flamebait. That was my first impression but if it's a forgery, it's much better than the run-of-the-mill forgeries around: All the headers tally and suggest it was posted from hub - which means that it's either genuine or an inside job. [I also get called by my surname but haven't quite reached the level of aggravation suggested by the initial posting]. Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pkg question...
On Tue, 2005-May-17 22:19:05 +1000, Graham Menhennitt wrote: >Yann Golanski wrote: > >>Is there a way to remove a package and the dependencies that only said >>package uses? >> >> >ports -> sysutils/pkg_rmleaves That is an interactive script that lets you delete all packages that aren't required by other packages. You still need some way to work out what dependencies were installed by the first package. You could try looking at "pkg_deinstall -R" (part of portupgrade). BTW, if you compiled the package, it could have installed build-time dependencies that aren't recorded as requirements and I don't know any easy way to find/delete them. -- 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: 5.4-RC2 freezing - ATA related?
On Tue, 2005-May-17 09:58:33 -0500, Brent Casavant wrote: >The only solution I found at that time was reverting to 4.10, though >that is obviously suboptimal. I could be persuaded to reinstall 5.x >on the machine if I'd be sure to get someone to look into this. It doesn't work that way. You are going to need to provide much more information and do some of the work yourself. I'd suggest that you: 1) Install 5.4-RELEASE (or -STABLE), including a kernel built with debugging and DDB enabled (see my previous post and/or the handbook). 2) Confirm that the problem still exists for you. 3) Since you think it's the daily tasks, run "periodic daily" manually and try to provoke the problem. 4) Once you can provoke it, run the scripts in /etc/periodic/daily individually to identify which script is the problem. Try to narrow it down to a single command within the script. 5) Once you can identify a command (or command sequence) that provokes' the problem, save a crashdump and send your dmesg, the sequence of commands you ran as well as the DDB output from "show lockedvnods" and "ps" to this list. That's enough information for someone to make a start on investigating the problem. If that's all too hard and you want a fix, see http://www.freebsd.org/commercial/consult_bycat.html -- 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: 5.4-RC2 freezing - ATA related?
On Wed, 2005-May-18 06:43:37 -0600, Elliot Finley wrote: >Had the system lock up again. This is with the new ATA mkIII patches on >http://people.freebsd.org/~sos/ATA. > >I didn't get the crashdump (forgot to set dumpdev), but I did get 'ps' and >'show lockedvnods' output from DDB. The output is in the form of >screenshots combined into a single .pdf which can be accessed here >http://www.efinley.com/Binder1.pdf That shows a deadlock-to-root in your /dev/ar0s1a (presumably root) filesystem. The perl process (pid 487) has an exclusive lock on the FS mountpoint - this is blocking 130 other processes. Pid 487 is itself waiting on another filesystem lock (you can't determine the actual lock tree without more poking around kernel memory). The vnode locks are held by processes: PID namewaiting on 487 perl [ufs c3c1c1b4] 57 syncer [snaplk c535f500] (holds 2 locks) 476 perl [ufs c87e4f1c] 489 perl [snaplk c535f500] (holds 2 locks) 3337 mksnap_ffs [getblk d77656f4] Looking through the process list, cron has started a "dump -L" which is trying to create a filesystem snapshot. That has wedged on "getblk" (trying to perform physical disk I/O) and is probably the root of your problem. Nothing else is waiting on physical I/O. I'd say that your first guess was right: This is a bug in the ATA code and is probably a job for sos. -- 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: 5.4-RC2 freezing - ATA related?
On Wed, 2005-May-18 16:03:16 +0100, Jamie Heckford wrote: >Managed to get a dump on our system for a similar prob we are getting: That traceback looks like a panic, not a deadlock. What was the panic message? >#2 0xc0513474 in panic (fmt=0xc06c3da5 "%s") at >/usr/src/sys/kern/kern_shutdown.c:566 ... >#7 0xc0510018 in crcopy () at /usr/src/sys/kern/kern_prot.c:1810 >#8 0xc0598c77 in in_pcbdetach (inp=0xc0743a40) at >/usr/src/sys/netinet/in_pcb.c:720 >#9 0xc05b21a6 in tcp_close (tp=0x0) at /usr/src/sys/netinet/tcp_subr.c:783 There's something wrong here: If tcp_close() is passed NULL it will panic at this point when it tries to dereference tp. >#10 0xc05ae560 in tcp_input (m=0xc3a6a300, off0=20) at >/usr/src/sys/netinet/tcp_input.c:2308 >#11 0xc05a5aed in ip_input (m=0xc3a6a300) at >/usr/src/sys/netinet/ip_input.c:776 >#12 0xc0582f13 in netisr_processqueue (ni=0xc0742498) at >/usr/src/sys/net/netisr.c:233 >#13 0xc058310a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:346 -- 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: 5.4-RC2 freezing - ATA related?
Previously posted trap frame:
#5 0xc0691771 in trap (frame=
{tf_fs = -1068433384, tf_es = -989790192, tf_ds = 16, tf_edi = -106612473
6, tf_esi = -1066124736, tf_ebp = -323699844, tf_isp = -323699872, tf_ebx = -10
07063716, tf_edx = 528, tf_ecx = -1013235680, tf_eax = 307472464, tf_trapno = 1
2, tf_err = 2, tf_eip = -1067870386, tf_cs = 8, tf_eflags = 66050, tf_esp = -98
9760240, tf_ss = -1007063716}) at /usr/src/sys/i386/i386/trap.c:425
On Thu, 2005-May-19 00:15:44 +0100, Jamie Heckford wrote:
>Fatal trap 12: page fault while in kernel mode
>fault virtual address = 0x214
That's a NULL pointer somewhere. The trap frame shows %edx is 528 so
the code has presumably tried to dereference %edx but it's not clear
how %edx would up with that value.
>fault code = supervisor write, page not present
>instruction pointer = 0x8:0xc059974e
>stack pointer = 0x10:0xecb4bb74
>frame pointer = 0x10:0xecb4bb7c
This instruction pointer matches the trap frame but not the traceback
you posted. The trap frame gives the stack pointer as 0xC5017510
(which is nonsense) with a nonsense stack segment but the frame
pointer matches. Having the frame pointer above the stack pointer
is also unusual.
It looks like gdb is a bit confused. You could try:
disasm 0xc059974e
x/x 0xecb4bb74
Does the instruction either at or immediately before 0xc059974e
include [%edx]? What function is it in and can you work out the
line number? Does the address reported by the x/x match anything
in the backtrace?
--
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: Boot loader cant identify ntfs?
On Thu, 2005-May-19 09:29:25 +0100, Bob Bishop wrote: >At 01:56 19/05/2005, Ian Dowse wrote: >>[...] >>BTW, one potential improvement to the current boot0 situation would >>be to have boot0cfg dynamically generate the OS table based on what >>partition types actually exist on the disk. [etc] > >That would be just plain unhelpful in the case where a partition gets >retyped subsequently. As I read Ian's proposal, it still dynamically detects the partition types at boot time. It's just that the table of known partition types is built by boot0cfg based on the partition types when boot0cfg is run. If you change a partition partition type then the new partition type may not be recognized but that is no worse than the current situation. It would probably be possible to pad the available space with other "common" partition types. -- 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: 5.4-RC2 freezing - ATA related?
On Fri, 2005-May-20 08:25:58 -0600, Elliot Finley wrote: >I took the -L option off of my dump command in my daily dump script. I've >gone two days without locking up which is unusual. I think that may be what >was tickling the bug that was locking me up. Sometime you might like to do a 'dd if=/dev/ar0 of=/dev/null bs=32k' just to confirm that you don't have any unreadable blocks (though this seems unlikely). -- 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: 5.4-RC2 freezing - ATA related?
On Fri, 2005-May-20 14:53:09 -0600, Elliot Finley wrote: >From: "Peter Jeremy" <[EMAIL PROTECTED]> >> On Fri, 2005-May-20 08:25:58 -0600, Elliot Finley wrote: >> >I took the -L option off of my dump command in my daily dump script. I've >> >gone two days without locking up which is unusual. I think that may be what >> >was tickling the bug that was locking me up. >> >> Sometime you might like to do a 'dd if=/dev/ar0 of=/dev/null bs=32k' just >> to confirm that you don't have any unreadable blocks (though this seems >> unlikely). > >came up clean. transfer went 40MB/s. That seem to leave the finger pointing at the ATA driver. Paging Søren: Are you have to help Elliot? -- 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: Context sensitivity in beastie.4th?
On Thu, 2005-May-26 23:41:26 -0600, Scott Long wrote: >Seems to work for me with the commented lines fixed. Btw, you by no >doubt have noticed that it's somewhat inconvenient to do 4th programming >by modifying the boot scripts and then praying that the reboot works. >It's possible to do 90% of the testing in userland, like I did when I >wrote beastie.4th. [Instructions deleted] I believe your instructions are worth preserving. Any chance of you adding that to (eg) /usr/src/sys/boot/README or into the ficl or forth directories? -- 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: FreeBSD 5.4: Is it generally unstable?
On Wed, 2005-Jun-08 10:13:16 +1000, David Hogan wrote: >Recently though, I've been playing around with FreeBSD 5.4 on a vmware box, >and I'm beginning to think it may be the way forward in the long run. Having >observed freebsd-stable@freebsd.org for the last couple of weeks, I've >noticed a worrying (to me) amount of traffic regarding kernel panics, >general instability etc, and I'm now posting this in the hope that I might >obtain perspective on this from some experienced FreeBSD users. IMHO, just reading this mailing list will give you an overly negative view of FreeBSD's stability. My experiences are that FreeBSD 5.4 using a GENERIC kernel (or something close to it) is quite stable. I'm only aware of one issue - relating to an interaction between mysnc(2) and UFS2 snapshots - and that hasn't affected me so far.. Most of the problems I've seen on this list relate to one or more of: - Experimenting with the ULE scheduler (which is not used by default) - Experimenting with PREEMPTION (which is off by default) - Having machines with 4GB or more of RAM - Running 5-STABLE (the development version) rather than 5.4 - Having filesystems with lots (>>1e6) of inodes - Unusual hardware (eg laptops) My suggestion is that you install your application suite on FreeBSD 5.4 (either native or within VMware) and experiment for a while. Your own applications are by far the best test. If you're happy with FreeBSD, switch over. If you run into problems, let us know. At this stage, I would recommend 5.4 over 4.11. -- 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: 5.4-RC2 freezing - ATA related?
On Tue, 2005-May-31 16:47:19 -0700, Steve Watt wrote: >>> The vnode locks are held by processes: >>> PID namewaiting on >>> 487 perl [ufs c3c1c1b4] >>> 57 syncer [snaplk c535f500] (holds 2 locks) >>> 476 perl [ufs c87e4f1c] >>> 489 perl [snaplk c535f500] (holds 2 locks) >>> 3337 mksnap_ffs [getblk d77656f4] ... >This is a filesystem lock problem, not an ATA driver problem. I analyzed >it, and posted the results to -hackers last week, with the subject "snapshots >and innds". I saw your previous post but the symptoms don't look the same to me. Your deadlock has mksnap_ffs blocked on ufs whilst Elliot's problem has mksnap_ffs blocked on getblk. getblk is a lower level call (physical I/O) and I don't see how a FS problem could cause problems for getblk calls. -- 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: Strange error
On Fri, 2005-Jun-10 22:41:36 +0200, Jack Raats wrote: >This day I've a very strange error when trying to connect to my FreeBSD >machine (4.11-STABLE) >I got the following error: >ssh_exchange_identification: Connection closed by remote host > >Can anyone give me any clue what's wrong? Try turning on debugging on the client (ssh -vvv ...). You can also turn on debugging on the server with '-d' (though you probably also want to use '-p'). If the problem isn't obvious, compare the output with a debugging session that works. -- 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: FreeBSD MySQL still WAY slower than Linux
On Fri, 2005-Jun-17 10:38:34 -0400, David Sze wrote: >It turns out that the problem was the same thing everyone usually points >the finger at, but no one actually mentioned this time: Linux mounts its >partitions async by default. This shouldn't be an issue here. The FreeBSD default has always been that data is written asynchronously (see below) and there should be virtually no metadata updates in a database application. If an application needs control over when the data is physically written to the disk (eg a database server), it needs to use fsync(2) and/or msync(2) calls. If Linux (or FreeBSD) isn't complying with fsync(2) or msync(2) semantics then it has a serious problem. >super-smack select-key >5.4-RELEASE ~20,000 queries/second >6.0-CURRENT ~24,000 queries/second >CentOS w/async ~36,000 queries/second >CentOS w/sync ~26,000 queries/second I can't see where this benchmark is doing any writes so I'd like to see an explanation of the difference in CentOS performance figures before making any decision on CentOS vs FreeBSD. >super-smack update-select >5.4-RELEASE ~4,000 queries/second >6.0-CURRENT ~4,500 queries/second >CentOS w/async ~7,500 queries/second >CentOS w/sync ~750 queries/second > >That last CentOS number is not a typo, it was an order of magnitude >slower. That's a surprising difference - I wouldn't have expected it to be so large. A couple of people have mentioned the impact of journalling. Journalling improves performance by converting time-critical random I/Os into time-critical sequential I/Os and background random I/Os - and sequential I/O is many orders of magnitude faster than random I/O. All transactional databases do their own journalling (REDO logs). As long as the database correctly issues filesystem synchronisation commands and the filesystem correctly implements them, database application, a journalling filesystem provides no benefits. A more interesting test would be a client that issues a series of updates to a server and, immediately after receiving the acknowledge for the last update turns, off the server's power. After the server is rebooted, confirm that all the updates have been applied correctly. Filesystem I/O behaviour: DataMetadata Mount type asyncasync async async sync 'traditional' UFS asyncasync[*] UFS + softupdates sync sync sync 'Metadata' covers directory updates and some inode updates [*] softupdates controls write ordering to ensure on-disk consistency. -- 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: FreeBSD MySQL still WAY slower than Linux
On Fri, 2005-Jun-17 23:42:08 +0200, Wilko Bulte wrote: >On Fri, Jun 17, 2005 at 02:26:48PM -0700, Javier Henderson wrote.. >> Wilko Bulte wrote: >> >Yes. Go and visit the London City and check their computer rooms. >> >You will be surprised about the number of UNIX boxes. You don't >> >think IBM, HP, Sun etc sell their UNIX machines just to ISPs or..? >> >> But are those Unix servers actually processing bank transactions and >> holding customer accounts? Unix and mainframes are not mutually exclusive - the major mainframe vendors will be happy to supply Unix on their mainframes. The big benefit of mainframes is data integrity - your typical mainframe will have error detection and/or correction on _all_ data paths, including through the ALU, all levels of cache and all I/O paths. The other benefit of mainframes is massive I/O bandwidth and the ability to usefully use the available bandwidth. >Why not? As an aside: what do you think telecom operators run their >main billing systems on? UNIX... Any idea what downtime costs per hour >on those systems? Not just billing systems. My employer sells Unix systems used for call processing (intelligent networks) as well as PABX's built on Unix kernels. And downtime at the call processing end is more expensive than the billing end - customers won't notice if the bill is ½hr late (or a call is undercharged) but they do notice if they can't ring the home-delivery pizza shop when they're hungry. I think this is getting somewhat off-topic: I don't think any banks or telcos have business critical systems running on FreeBSD or Linux with MySQL databases. And the FreeBSD-S/390 port is nowhere near Tier-1 status yet. -- 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: rebooting problem
On Fri, 2005-Jun-17 11:58:35 +0200, GMane wrote: >When I try to reboot my machine it hangs on and I have to do it manually >pressing the reset button. > >Did anyone have the same problem? I've seen something similar on a HP DL380. Do you have any modules loaded? If so, does the problem go away if you avoid loading any modules? See http://www.FreeBSD.org/cgi/query-pr.cgi?pr=i386/72441 -- 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: howto update freebsd 4.7 release to 4.7 stable
On Tue, 2005-Jun-21 09:16:30 +0700, Khanh Cao Van wrote: >My custom use freeBSD 4.7 release and ask me to install JDK1.4 on it . >But when I use ports to compile JDK , the system show me a message : > >You must have a version of FreeBSD later than 4.7-STABLE February 2003 >or 5-CURRENT February 2003 to compile and use JDK 1.4.2. JDK 1.4 requires some threading changes that were (presumably) introduced in February 2003. Looking back at the CVS commit logs, there were a large number of changes to the threading library during January and February 2003 and it's not clear exactly what fixes JDK is relying on. If the only problem with JDK is the threading library, you may be able to get JDK1.4 running by just upgrading libpthread to 4-STABLE: # cd /usr/src/lib/libpthread upgrade just this tree to 4-STABLE using whatever method you prefer # make clean # make all # make install I can't guarantee that this will work but it is probably your only option to get JDK 1.4 working without doing a full upgrade. >So I have to update my 4.7 release to 4.7 stable . But I do not know >how to do make it . I've looking everywhere but could not find any >clear document about it . Please help me ! 4.7-STABLE is not a fixed package. It refers to the RELENG_4 CVS branch between the time that RELENG_4_7 was branched and RELENG_4_8 was branched (ie betweem 4.7-RELEASE and 4.8-RELEASE). It is not really practical to update to 4.7-STABLE once 4.8 has been released. >PS : I'm not going to upgrade my kernel 4.7 to 4.8 or anything else , >just 4.7 only . Thank for reading ! Note that 4.7 is no longer supported by the FreeBSD project and I would strongly recommend that you consider upgrading. In particular, security fixes are unlikely to be applied to 4.7. Upgrading userland without upgrading the kernel is not supported in general. -- 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: howto update freebsd 4.7 release to 4.7 stable
On Tue, 2005-Jun-21 17:24:46 -0400, Brian Fundakowski Feldman wrote: >On Tue, Jun 21, 2005 at 07:37:42PM +0700, Khanh Cao Van wrote: >> hi , I could not findout the "# cd /usr/src/lib/libpthread" as your >> answer bellow ,please help me to fix this problem > >Yeah, 4.x actually uses libc_r. Sorry about that. I was looking in the wrong source tree. -- 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: Data corruption in cd9660 on FreeBSD 4.11?
On Fri, 2005-Jun-24 22:31:06 +1000, Stephen McKay wrote: >I'm experiencing data corruption when reading CDs and DVDs on FreeBSD 4.11. ... >So, can anyone suggest any more tests I could try? Or is there a kind of >hardware fault that could cause this substitution of whole blocks read from >CDs without causing any other problems? You might like to post the relevant sections of a verbose boot - the ATA and CD probes. Are you running the CD/DVD drives in PIO or UDMA modes? In the former, the CPU is reading the data from the CD and writing it to memory. In the latter, the CPU tells the disk controller where to write. It could be instructive to change modes and see what happens. Have you tried anything other than ISO9660 filesystems on a physical CD? What happens if you just dd the CD-ROM? What happens if you use a vnode mount (see vnconfig(8)) of an ISO filesystem sitting in a UFS filesystem? Anything unusual in your kernel config file? Have you tried building a kernel with WITNESS and/or DIAGNOSTIC? Any chance of you repeating the tests with a 5.x system? Maybe on a spare small partition or using a 5.4-RELEASE disk1 as a live filesystem. -- 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: Problems with 5.x
Hi Matt, On Thu, 2005-Jun-30 11:57:38 -0400, Matt Emmerton wrote: >First, I tried to install 5.2. Booting from CD, BTX would halt with a >register dump. There are some people around who can read BTX dumps. Any chance of you posting it? The CD boot mode was changed from "floppy emulation" mode in 4.x to "no emulation" mode in 5.x (for slightly more details, see the '-b' and '-no-emul-boot' options to mkisofs). At a guess, it looks like your BIOS doesn't handle the latter very well. My two suggestions are: 1) A BIOS upgrade. If your BIOS is flashable, check out the vendor's website. 2) Boot from physical floppies. The images are in the 'floppies' directory on the CD-ROM. I presume you've satisfied yourself that the CD-ROMs aren't corrupt. (Unlikely but possible). You might have to experiment with dis/enabling ACPI to get things working. >Next, I installed 4.10 (which installs fine) and tried to cvsup to -stable, >but had problems with buildworld. Generally, upgrading to version N from version N-1 is only supported from the latest version of N-1, so you might need to upgrade your 4.10 system to 4-STABLE first. Alternatively, you will need to post more details (cut-and-paste) of the errors you are getting. -- 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: init: can't exec getty 'none' for port /dev/console: No such file or directory
On Fri, 2005-Jul-01 08:23:52 +0300, Bashar wrote: >i noticed one of my boxes had the message "init: can't exec getty 'none' >for port /dev/console: No such file or directory" into messages and >repeating forever. You should have the following line in /etc/ttys: console noneunknown off secure The only change you can validly make to this line is to change 'secure' to 'insecure' but I suspect you've changed 'off' to 'on'. Try turning the console back off and sending a SIGHUP to init. -- 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: init: can't exec getty 'none' for port /dev/console: No such file or directory
Please don't top-post. On Fri, 2005-Jul-01 20:17:47 +0300, Bashar wrote: >Peter Jeremy wrote: >>You should have the following line in /etc/ttys: >>console noneunknown off secure >True its set to on, but i believe this change was requested from the DC >to enable the remote console for the box. > >would turning it off effect the remote console from working? No. The 'console' entry is just a marker. By "remote console" I presume you mean "serial console". The easiest way to get a serial console is to put "-P" into /boot.config and unplug the keyboard. (For other ways, see boot(8) and sio(4)). In order to enable logins on a serial console, you will need to turn on the getty for ttyd0. -- 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: Quality of FreeBSD
On Thu, 2005-Jul-21 17:46:13 +0200, Martin wrote: >One more thing about "cheap hardware": if you know that a piece of >hardware is potentially buggy (I mean real BUGS and not missing >support), please publish your opinion, because I will buy hardware >FOR FREEBSD, so I avoid major problems. How about test suites for >ACPI quality, e.g.? Would it be possible? In general, I'd say what you want isn't achievable. Firstly, there's the risk of legal action from a vendor who believes they have been maligned and the reliability (or lack thereof) of the supplied opinions. More critically, vendors often make (significant to FreeBSD) changes to products without any obvious external differences. For example, wireless cards that are externally identical but have different chipsets when you open the packaging. And there's no way to ensure that the BIOS and ACPI in the motherboard you bought last week bears any resemblance to the BIOS and ACPI in the supposedly identical motherboard that I buy this week. As far as the vendor is concerned, as long as it (sort of) works on Windoze when you use the vendor-supplied driver then the vendor has fulfilled their "fit-for-use" responsibility. -- 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: 4->5 libmilter.a install failure
On Mon, 2005-Aug-08 14:25:35 -1000, Randy Bush wrote:
>my error. i hacked /etc/make.conf between build and install.
>so i can use ed to unhack it, but when i try to install again
>
>--
>>>> Making hierarchy
>--
>cd /usr/src; /usr/obj/usr/src/make.i386/make -f Makefile.inc1 hierarchy
>cd /usr/src/etc;/usr/obj/usr/src/make.i386/make distrib-dirs
>mtree -eU -f /usr/src/etc/mtree/BSD.root.dist -p /
>/usr/libexec/ld-elf.so.1: Shared object "libmd.so.2" not found, required by
>"mtree"
Apart from the other suggested solutions: At the beginning of the
installworld, make stashes a selection of utilities (including
mtree) into a temporary directory (${INSTALLTMP} in Makefile.inc1).
The exact name varies but is something like /tmp/install.
If you haven't lost the directory from the first installworld, you can
always copy mtree (any any other over-written utilities) back where
they started.
--
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: Memory requirements between releases
On Fri, 2005-Aug-12 21:38:43 +0100, Chris wrote: >The installation notes for 4.11 say, referring to i386 platform >" ...after installation, FreeBSD itself can be run in 4-8MB of RAM with >a pared-down kernel" > >The installation notes for 5.4 and 6 (the floppies README.TXT) say >"FreeBSD for the i386 requires ...at least 24 MB of RAM". > >Did the memory requirement really jump that much or is something >different being measured? As Kris said, you are measuring two different things. Note the phrase "after installation" in your first quote. Installation takes substantially more memory because FreeBSD needs to load a full-sized GENERIC kernel, allocate space for a RAM disk to hold the installation filesystem process and have enough RAM left over to actually run the installaton processes. Once you've installed FreeBSD, you can prune down the kernel and you don't need the RAM disk. That said, 5.x is larger than 4.x (which is larger than 3.x, etc). >I have on old tosh 110CT laptop with 24mb memory I want to set up as a >wireless router/NAT box but would prefer to use 6 or 5.4. Can I reduce >the amount of memory required? I have compiled a reduced kernel but it >swaps like mad when compiling. Kismet and deps took over 12 hours. Just >after boot and not doing anything it has about 2mb free and 17 processes >running. 24MB should be adequate as a SOHO wireless router/NAT box but doing compilations will stress it significantly (as you've noticed). It would be too small if you were going to run lots of applications (named, squid etc) 2MB free sounds about right. The Unix kernel sees free space as wasted space and tries to avoid having too much of it. You can add "inactive" to the free memory to get a better idea of how much RAM isn't being used, and the cache will shrink if processes need for RAM. As long as your system isn't paging during normal operation (normal operation for a firewall excludes compiling ports or the kernel), then you have enough RAM. 17 processes sounds a bit high. You can probably find some that aren't necessary - in particular, you probably only want one or two gettys. -- 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: 6.0-BETA2 as reliable webserver?
On Fri, 2005-Aug-19 23:42:18 +0200, Frans-Jan v. Steenbeek wrote: >building. Since we are moving in a few months, we decided to use a HP >laptop instead (reasonably fast CPU, 512 Megs) since we had a few to >spare. > >The toy is currently set up with FreeBSD 6.0-BETA2, Apache 2.0, MySQL 5.0 >and PHP-5.0 with all the reasonable modules. Everything is compiled from >ports. No changes to the kernel yet, no world-rebuilding done. I'd also be extremely loath to bet my company on a laptop running beta software. As others have pointed out, laptops aren't designed for this. (Though my old Compaq laptop ran FreeBSD 24x7 for several years and I only stopped using it because the lid was cracking too badly). If you're really concerned about noise: - use an older desktop and maybe even underclock it to keep it cooler - build your own system. Either go the low power route (mini-ITX) so you don't need noisy fans or use an over-rated PSU and CPU heatsink to keep fan speed (and noise) down. In either case, you'll need to look around to find a quiet HDD. - [as a completely left-field suggestion] look at something like an Apple G5 system - large fans running slowly generate very little noise. At the very least, you need to build a test harness to test the system under load (and maybe get some friends and/or friendly customers to hammer it as well). Whilst all the software is derived from a mature code-base, I'd be surprised if you can't crash it. >I will post all problems not yet reported to the list, but if anyone of >you would like to share his or her opinion on this matter, please let me >know. Will 4.11-RELEASE perhaps be a better choice? 4.x is definitely more mature than 6.x. That said, I'd recommend against deploying 4.x in a new system because it is a dead end - you'll need to migrate off it at some point and that's far easier to do before a system goes live. You made the point that you support for newer hardware is better in newer releases. Why not use 5.4? As you point out, you are more familiar with it. And, once 6.x does become more stable, moving from 5.x to 6.x will be far easier than moving from 4.x to 6.x. -- 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: CTM updates
CTM has been down since 2nd November. The last e-mail delta I received was cvs-cur 5804. Chuck Robey is in the process of correcting the problem and has suggested (on cvs-announce) that it should be back later today. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kernel not patching?
On 1999-Dec-03 06:20:25 +1100, David Gilbert wrote: >I have 'options vinum' in the kernel ... and typing 'make' give: I presume you read the warning in LINT: # Configuring Vinum into the kernel is not necessary, since the kld # module gets started automatically when vinum(8) starts. This # device is also untested. Use at your own risk. Maybe you should switch to using vinum as a KLD and see if your problem goes away. (BTW, auto char *foo = "foo"; means that the stack contains a pointer to a string foo. The string will be in static storage - ie to find the stack, you need to work out the KVA for "foo" and then search for this address). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /bin/test broken ?
On 1999-Dec-23 12:09:49 +1100, Vlad Skvortsov <[EMAIL PROTECTED]> wrote: > Seems like /bin/test is broken after cvsup on Dec 16: > > $ /bin/test 1 -ne 0 ] > [: ]: unexpected operator What behaviour were you expecting? That command should have been expressed as either: $ /bin/test 1 -ne 0 or $ [ 1 -ne 0 ] Mixing `test' and `]' is not allowed, so producing an error message is the correct response. That said, the error message should have been: test: ]: unexpected operator and it is not clear why you are getting `[' reported as the program name. As far as I can tell, nothing related to test or errx(3) has been updated recently. (I'm not actually running -stable, so I can't confirm the behaviour). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /bin/test broken ?
On 1999-Dec-28 20:08:21 +1100, "Rodney W. Grimes" <[EMAIL PROTECTED]> wrote: >The syntax is reasonable, as /bin/[ or /bin/test is about the only way >one would overide a builtin [, should some shell implement test as >a builtin. Of course, that assumes that the shell doesn't have other problems with its parsing: $ zsh -c '[ 1 -ne 0 ] && echo correct' correct $ zsh -c '/bin/[ 1 -ne 0 ] && echo correct' zsh: bad pattern: /bin/[ $ (Found by accident whilst looking into the original problem - I haven't, but probably should, report it as a bug in zsh 3.0.5). Peter -- Peter Jeremy (VK2PJ)[EMAIL PROTECTED] Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kern/13644
On 2000-Jan-24 03:37:19 +1100, Mikhail Teterin <[EMAIL PROTECTED]> wrote: >=> =FreeBSD: >=> ==> => If timeout is a non-nil pointer, it specifies a maximum >=> ==> => interval to wait for the selection to complete. ... >It appears, that you, as well as other developers, speak from the >implementation point of view. I only look at the man-page. The man page >says, the time out is the UPPER limit. Note that the man page talks about waiting for the _selection_ to complete. It does not refer to returning from the select(2) call. And the behaviour is exactly as documented: when the specified interval is complete, the process will return to the run queue for normal scheduling (if it hasn't previously found a ready FD). Unix is not a real-time OS, so once a process is in the run queue, an arbitrary period can expire before the process is actually run. The only cases where a select(2) (or poll(2)) system call will return before a specified period are: 1) A signal was received 2) One of the specified file descriptors became ready. >sorts of other man-pages from all sorts of other vendors, who all say >(almost) the same thing: > > that the timeout is indeed the UPPER limit, and not the LOWER. Please provide a test program and results from these other vendors demonstrating that their select() will return before the specified time limit in the absence of any other event. It's probably worthwhile adding a comment to select(2) similar to that in sleep(3), noting that "system activity may lengthen the sleep by an indeterminate amount." Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: "No /boot/loader" or "Invalid format"
On 2000-Mar-17 08:19:36 +1100, "Jeffrey J. Mountin" <[EMAIL PROTECTED]> wrote: >Not sure if the behaviour changed, but the other gotcha is that / and swap >must be sequential on the disk (or was it same partition/drive). I don't recall ever seeing this mentioned anywhere. There shouldn't be anything in the system that requires it. Do you have a pointer to something that documents this? Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Netscape pegs CPU on XServer kill
On 2000-Mar-21 15:32:00 +1100, David Kelly <[EMAIL PROTECTED]> wrote: >the above note. And it *says* it "core dumped" but I haven't found any >netscape.core's laying around lately. The ports installation process makes /usr/local/bin/netscape a small shellscript which sets a couple of environment variables, turns off core dumps (ulimit -c 0) and then exec's the netscape binary. This means you won't find any droppings lying around. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Netscape pegs CPU on XServer kill
On 2000-Apr-06 22:21:01 +1000, Mikhail Teterin <[EMAIL PROTECTED]> wrote: >Peter Jeremy once stated: >=The ports installation process makes /usr/local/bin/netscape a small >=shellscript which sets a couple of environment variables, turns off >=core dumps (ulimit -c 0) and then exec's the netscape binary. This >=means you won't find any droppings lying around. > >Yeah, but it used to be, it would not even say '(core dumped)' if there >was not one. Now it will say that even if no dump was made. Kind of >misleading, although, I'm sure there is some reason for it. This was done as part of PR kern/14540, committed in /sys/kern/kern_sig.c 1.68 (30th October 1999) and 1.53.2.6 (22nd November 1999). This PR changed the behaviour where the core image would be larger than the processes RLIMIT_CORE. Previously a corefile would not be created at all, now the corefile is truncated to RLIMIT_CORE. If RLIMIT_CORE is zero, then no core file is created, but coredump() returns success - leading to the `core dumped' message. Presumably, the lower-level function (p->p_sysent->sv_coredump()) used to return an error when the core file was truncated (I haven't chased that function down). I agree, this behaviour is somewhat counter-intuitive. Maybe it deserves a PR to change it. Feel free to submit one. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
3-STABLE hangs
I have a Dell OptiPlex GXi (Pentium-133 with 96MB RAM) running 3-STABLE (from last night) which is used to simulate a WAN (using dummynet). Under normal operation, it hangs about every 2 weeks, but I can make it happen in about 15 minutes by loading up the box. When it hangs, it does a good job - no response to the network, keyboard or even NMI. These crashes are becoming quite embarrassing. Does anyone have any suggestions on how to locate and fix the problem? Following are dmesg output, as well as the ipfw and natd files (addresses have been changed). Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.4-STABLE #8: Mon Apr 17 17:31:12 EST 2000 root@:/usr/src/sys/compile/wansim Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (132.95-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf real memory = 100663296 (98304K bytes) avail memory = 94908416 (92684K bytes) Preloaded elf kernel "kernel" at 0xc02b7000. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x01 on pci0.7.0 ide_pci0: rev 0x00 on pci0.7.1 fxp0: rev 0x08 int a irq 11 on pci0.13.0 fxp0: Ethernet address 00:d0:b7:20:c4:9f fxp1: rev 0x08 int a irq 10 on pci0.14.0 fxp1: Ethernet address 00:d0:b7:20:8f:ee fxp2: rev 0x08 int a irq 9 on pci0.15.0 fxp2: Ethernet address 00:d0:b7:20:bd:ab vga0: rev 0x54 int a irq 11 on pci0.16.0 xl0: <3Com 3c905-TX Fast Etherlink XL> rev 0x00 int a irq 11 on pci0.17.0 xl0: Ethernet address: 00:c0:4f:ba:32:2b xl0: autoneg complete, link status good (half-duplex, 100Mbps) Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <12 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A wdc0 at 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa wdc0: unit 0 (wd0): , LBA, DMA, 32-bit, multi-block-16 wd0: 2014MB (4124736 sectors), 1023 cyls, 64 heads, 63 S/T, 512 B/S fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 npx0 on motherboard npx0: INT 16 interface atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa Intel Pentium detected, installing workaround for F00F bug IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to accept, logging limited to 100 packets/entry by default DUMMYNET initialized (000212) /etc/rc.firewall.local: #!/bin/sh # # dummynet configuration. This file is sourced from rc.network # Single pass thru firewall code /sbin/sysctl -w net.inet.ip.fw.one_pass=1 # Create pipes to simulate WAN /sbin/ipfw pipe 1 config bw 2Mbit/sec delay 7ms queue 256KB /sbin/ipfw pipe 2 config bw 2Mbit/sec delay 7ms queue 256KB # Explicitly allow traffic we've already delayed /sbin/ipfw add 10 allow ip from 10.123.126.144/28 to 192.168.0.0/16 out /sbin/ipfw add 20 allow ip from 10.123.126.160/28 to 192.168.0.0/16 out /sbin/ipfw add 30 allow ip from 192.168.0.0/16 to 10.123.126.144/28 in /sbin/ipfw add 40 allow ip from 192.168.0.0/16 to 10.123.126.160/28 in /sbin/ipfw add 50 allow ip from 192.168.0.0/16 to 192.168.0.0/16 # Bypass pipes for ssh traffic /sbin/ipfw add 80 skipto 3000 tcp from any ssh to any /sbin/ipfw add 81 skipto 3000 tcp from any to any ssh # Use pipe1 for traffic from local to remote /sbin/ipfw add 110 pipe 1 ip from 10.123.126.144/28 to 192.168.0.0/16 in /sbin/ipfw add 120 pipe 1 ip from 10.123.126.160/28 to 192.168.0.0/16 in # Use pipe 2 for packets going out xl0 /sbin/ipfw add 210 pipe 2 ip from 192.168.0.0/16 to 10.123.126.144/28 out /sbin/ipfw add 220 pipe 2 ip from 192.168.0.0/16 to 10.123.126.160/28 out # Grab packets for myself /sbin/ipfw add 1001 allow ip from 10.123.126.146 to any out /sbin/ipfw add 1002 allow ip from 10.123.126.162 to any out /sbin/ipfw add 1003 allow ip from 192.168.126.146 to any out /sbin/ipfw add 1004 allow ip from 192.168.126.162 to any out /sbin/ipfw add 1101 allow ip from any to 10.123.126.146 in /sbin/ipfw add 1102 allow ip from any to 10.123.126.162 in /sbin/ipfw add 1103 allow ip from any to 192.168.126.146 in /sbin/ipfw add 1104 allow ip from any to 192.168.126.162 in # Start NAT for any other traffic /sbin/ipfw add 5000 divert 32000 all from any to any via xl0 /sbin/ipfw add 5100 divert 32000 all from any to any via fxp0 # Create proxy ARP entries for vlan158/174 aliases to the remote hosts echo "Creating proxy arp entries" /usr/sbin/arp -d -a /usr/sbin/arp -s aald04-aal0 $ether_fxp0 pub /usr/sbin/arp -s aald06-aal0 $ether_fxp0 pub /usr/sbin/arp -s aald07-aal0 $ether_fxp0 pub /usr/sbin/arp -s aald09-aal0 $ether_
Re: Install 4.0-STABLE on an old Laptop
On 2000-Apr-16 13:01:48 +1000, Warner Losh <[EMAIL PROTECTED]> wrote: >In message <[EMAIL PROTECTED]> Gunnar Flygt writes: >: Has anyone tried the minimum requirements for 4.0? Sure, but will it run >: on an old Toshiba 486 with 24 MB of RAM? > >24MB of RAM shoud be plenty to run a fairly thin, but still usable >system. I've got a 486 with 20MB RAM running 4-CURRENT from a couple of months ago (it takes about 30 hours for a buildworld and my wife complains about the noise in our bedroom). I haven't noticed any real problems with the lack of RAM. My biggest gotcha is forgetting to add swap before linking a kernel (with debugging) in single user. (It compiles, but the linker runs out of RAM). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.0 release to 4.0 stable update
On 2000-Apr-17 04:47:14 +1000, Philipp Huber <[EMAIL PROTECTED]> wrote: >i updated my 3.2-release to 4.0-release, and today i cvsup'ed my >source tree to 4.0 stable. i read src/UPDATING, checked the things i >had to do and started compiling the whole thing with make >buildworld. after a few minutes there's an error somewhere in the gnu >subdirectory: cc1 gets signal 11. it's definetely not a memory >problem, i changed it and was the same again [Can you please wrap your lines]. I presume your system was fully converted to 4.0-RELEASE (kernel and userland) before you started a build to 4-STABLE. When you repeat the buildworld, does the error occur in exactly the same place? If so, can you provide the last 20-30 lines of the buildworld output. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD 2.2.8 gone for good?
On Sat, May 06, 2000 at 01:48:31PM +1000, Chad R. Larson wrote: >I'd also point out that you can use anonymous CVS, or CVSup to fetch >the 2.2.8-STABLE source tree and build it yourself... You'll need a 2.x machine to do this. You definitely can't build 2.x on a 4.x machine, and I suspect you can't on 3.x either. [If anyone would like to prove me wrong, I'd like to know because otherwise I'm going to have to downgrade a 4.x machine to 2.x so I can do a 2.x buildworld for another machine too under-endowed to manage a buildworld itself]. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD 2.2.8 gone for good?
On Sun, May 07, 2000 at 02:35:16AM +1000, Matt Heckaman wrote: >Don't bet on that, here's an interesting story of mine: > >I sent two letters on the same day, from the same post office here in >Montreal, Canada. I sent one letter express, one letter normal mail. ... [The further you post a letter, the quicker it arrives] Check out "Mail Supremacy" by Hayford Pierce. (I found it in "100 Great Science Fiction Short Short Stories"). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Cached versus non cached disk I/O
On 2000-Aug-03 15:20:02 -0700, Tom <[EMAIL PROTECTED]> wrote: >On Fri, 4 Aug 2000, Peter Jeremy wrote: >> Not quite. softupdates is actually more robust than a normal FS >> mount (and far more robust than async). > Not likely. I personally pushed softupdates over the edge before (see >archives). In my case, the amount of unwritten metadata filled up all >kernel space. The filesystem was recoverable, but fsck filled up >lost+found several times (that should be considered a fsck bug that wasn't >possible to expose without softupdates). It was rather messy. That definitely is (or was) a bug in softupdates - it's not supposed to behave that way. I presume you're referring to the postmark test you were running last December on 3.4-STABLE. Looking at the CVS logs, the core softupdates code would have been 1.34.2.3, which is now nearly a year old. Have you tried repeating your tests on a more version of softupdates (5-CURRENT or 4-STABLE)? It looks like Kirk doesn't MFC many of the changes he makes in -CURRENT, but there were are a lot of softupdates fixes in 4-STABLE compared to 3-STABLE. (From what I can see, there has only been one real bugfix in -CURRENT since 4-STABLE branched - that related to a panic if user quotas were exceeded). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: vlanning causing kernel panics?
[Catching up on old mail] On 2000-Nov-06 16:33:38 +0100, Maikel Verheijen <[EMAIL PROTECTED]> wrote: >While trying to use vlan's under FreeBSD, my machine keeps on kernel panicing >when I try to ifconfig the vlan interface. > >What I did in short: > >- Made a kernel with: >pseudo-device vlan20 # Get 20 vlan interfaces 1) There was a bug which limited the total number of network interfaces to 16 (an array dimensioned to 16 elements). I'm not sure if/when the fix was MFC'd. (I can't find the relevant commit off-hand). >- Rebooted (of course :) > >- did a: >/sbin/ifconfig vlan0 vlan 120 vlandev xl1 >/sbin/ifconfig vlan0 inet 10.10.10.10 netmask 255.255.255.0 These two lines can be combined. 2) You need to do an "ifconfig xl1 up" first. You don't need to specify an IP address/netmask/etc, but can/should specify physical characteristics (10/100, half/full duplex etc). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problems booting 486/66 after 3.1
On 13 Dec, [EMAIL PROTECTED] wrote: > I have a Micronics 486 VLB motherboard (unknown exact model) that doesn't > like FreeBSD beyond 3.x. 3.1-RELEASE works fine on this motherboard but > 4.x versions reboot immediately following the display of the Copyright > notices and FreeBSD version line. My 486 isn't having any problems with -current, and I know I did run 4.x on it - but I can't remember exactly when. I presume you have correctly upgraded the bootblocks and /boot/loader. Does "boot -v" give any additional details? Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Intel PRO/100+ driver or hardware?
On 2001-Jan-08 10:18:40 +, Edvard Fagerholm <[EMAIL PROTECTED]> wrote: >> The other cards connected to the hub are a mixture of 10 and 100 cards >> (3Com 905B, LinkSys LNE100TX, 3Com 509). All of these work fine. > >Funny, as I've got a quite similar problem. During high network >throughput (about 50mbit/s) one of my boxes just dies. This is why it >always crashes when doing backups and I had to put the backup computer >to 10mbit half-duplex mode to get it work... Just to add a further data-point: I have a Dell OptiPlex GXi (Pentium-133 with 96MB RAM) that had 3 genuine PRO/100+ cards. It used to regularly lock up (to the point where NMI had no effect) under load (disk+network+CPU). Replacing the PRO/100+ associated with the multiplexed interrupt with a DEC DE500 (21143) solved the problem. I initially ran into the problem with 3.4-STABLE last February. I can't recall if I re-checked after I installed 4.x on the machine. I wound up switching to feeding all the relevant networks via a VLAN trunk into a single PRO/100+ and haven't had any problems since. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: installworld anomoly
On 2001-Feb-04 13:08:02 -0800, Matt Dillon <[EMAIL PROTECTED]> wrote: > It's not a bug with OpenSSH, it's a bug with 'makewhatis'. The > 'makewhatis' perl script is closing the input descriptor without > draining all the input. If the gzcat writing the descriptor does > not use a large enough buffer, the gzcat's write() will then fail. > > This is not a bug with gzcat or a bug due to the pipe being too small > (there is no 'right' size for the pipe), it's a bug with 'makewhatis', > and a very easy bug to fix too. I disagree with this fix. By default, a write to a pipe with no reader will cause a SIGPIPE. The default action for SIGPIPE is to terminate the process quietly. OpenSSH has set SIGPIPE to SIG_IGN, resulting in a write to a pipe with no reader returning EPIPE. gzcat is correctly detecting that the write failed, reporting an error and exiting. Firstly, OpenSSH should not be changing the default signal behaviour passed onto it's children. This _is_ a bug and should be fixed. Secondly, making makewhatis(1) read all available input before closing the pipe is just unnecessarily slowing down makewhatis. There's no reason for makewhatis to process an entire man page - it just needs the name and synopsis. Once it has read that, it should dispose of that man page and move onto the next ASAP. There's no point in making gzcat uncompress the entire man page. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 802.1q vlans and STABLE
On 2001-Feb-22 22:13:20 -0500, Mike Tancsa <[EMAIL PROTECTED]> wrote: >are vlans and the fxp driver ready for prime time ? I've been running a system with 6 VLANs on an fxp for about 6 months now without problems. The system has currently been up nearly 3 weeks (following a blackout) and had been up for 2 1/2 months before that. netstat -I gives: aalp02# netstat -i Name Mtu Network AddressIpkts IerrsOpkts Oerrs Coll dc0* 1500 08:00:2b:c3:6b:b90 00 0 0 fxp0 1500 00:d0:b7:20:8f:ee 252636245 0 252026018 0 0 fxp0 1500 none none252636245 0 252026018 0 0 fxp1* 1500 00:d0:b7:20:bd:ab0 00 0 0 xl0* 1500 00:c0:4f:ba:32:2b0 00 0 0 vlan0 1500 00:d0:b7:20:8f:ee 51854151 0 24998001 0 0 vlan0 1500 net91/24 aalp02-a0 51854151 0 24998001 0 0 vlan1 1500 00:d0:b7:20:8f:ee0 02 0 0 vlan1 1500 net155aalp02-a1 0 02 0 0 vlan2 1500 00:d0:b7:20:8f:ee 90580612 0 128663939 0 0 vlan2 1500 net156aalp02-l0 90580612 0 128663939 0 0 vlan3 1500 00:d0:b7:20:8f:ee 9104283 0 9104999 0 0 vlan3 1500 net157aalp02-l19104283 0 9104999 0 0 vlan4 1500 00:d0:b7:20:8f:ee 93593008 0 81969794 0 0 vlan4 1500 net158aalp02-r0 93593008 0 81969794 0 0 vlan5 1500 00:d0:b7:20:8f:ee 7504326 0 7289701 0 0 vlan5 1500 net159aalp02-r17504326 0 7289701 0 0 lo0 16384 8 08 0 0 lo0 16384 127 localhost 8 08 0 0 ds0* 65532 0 00 0 0 aalp02# >http://www.euitt.upm.es/~pjlobo/fbsdvlan.html That's where I got my code last August. I haven't looked to see what has changed since then. I know I have patches for: - set the "Long Receive OK" bit in the i82559 (fxp) [rather than rummage through "error packets"] - support VLANs on the TI ThunderLan (tl driver) - support VLANs on the SMC 9432TX (tx driver) - VLAN support in driver modules for the above drivers - fix VLAN handling in arp(8) - support VLANs in tcpdump(8) [this may be in the generic tree by now] >configuring fxp0, do I just assign it IPs via the vlan interface, or should >I also give fxp0 a normal IP. The fxp0 interface doesn't need an IP address, but you will need to explicitly `up' it with a line in /etc/rc.conf like: ifconfig_fxp0="up media 100baseTX mediaopt full-duplex" > Will it break things if fxp0 has an IP associated with it ? No, but at least the Alcatel (Xylan) switch I'm using won't send `normal' ethernet packets once the port has been designated as a VLAN trunk. >Also, does aliasing of vlan interfaces work as expected ? I don't know any reason why it wouldn't, but haven't tried. I _am_ using proxy ARP on one of the VLAN interfaces. >Is there a limit as to the # of vlan interfaces ? There used to be some hard limits on total interfaces (16 or 32, I can't remember which) - I'm not sure when the fix was MFC'd. I don't believe there is any hard limit on the number of VLANs, but I've never tried more than 6. > Also, do I have any >performance hits if I have too many vlans ? On incoming 802.1Q packets, there's a linear search through a list of known VLAN numbers to determine the destination vlan device. Unless you're planning on lots of VLAN's, this probably isn't an issue. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: CTM not updated since Mar 13
On 2001-Apr-11 11:21:00 +0200, "B. Christer Moller" <[EMAIL PROTECTED]> wrote: >I know you are all very busy with the upcoming FreeBSD-4.3 RELEASE, but for >us who uses CTM to update our sources there hasn't been any updates since 13 >Mar. Is this meant to be like this or just a problem? If you're relying on CTM, you should really be reading ctm-announce. The machine hosting the CTM generation lost net connectivity without notice. A new host has been found and CTM generation was re-enabled a couple of days ago. I don't see the stable sources, but a cvs-cur delta was posted on 9th April and I thought it was the last to be generated. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On 2008-Jun-08 17:49:20 +0200, Michel Talon <[EMAIL PROTECTED]> wrote: >and it is now working perfectly well without any trouble. The only >"gotcha" is the slowness of X problem when compiling, but i live with that. Have you tried SCHED_ULE? In my experience, it does a better job of scdeduling than SCHED_4BSD, even on UP machines (YMMV). >which are perhaps susceptible of destabilising it. Personnally i have >seen the same occurring with 6.0, 5.0 and 4.*, for me the last releases >of the 4.* were very poor on my laptop while the early 4.* releases were >perfectly OK. The difficulty with the later 4.x releases was that there were major differences between the 4.x and later kernels and this made it increasingly difficult to backport bugfixes. This is less of an issue with now 4.x is out of the way. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpmjvNkZtFUJ.pgp Description: PGP signature
Re: Unusually large directory - 2.0 peta bytes
On 2008-Jun-14 07:17:56 +0200, Goran Lowkrantz <[EMAIL PROTECTED]> wrote: >drwxr-xr-x 2 root wheel 2251799813685760 Jun 14 04:06 . This is 0x80200 ># od -c /usr/local/lib/perl5/site_perl/5.8.8/mach/auto/APR/PerlIO | more >000s 313 O \0 \f \0 004 001 . \0 \0 \0 1 313 O \0 >020 364 001 004 002 . . \0 \0 t 313 O \0 024 \0 \b \t >040P e r l I O . s o \0 217 300 u 313 O \0 >060 324 001 \b \t P e r l I O . b s \0 217 300 >100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 >* >0001000 \0 \0 \0 \0 \0 002 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 ... >This does not look like a directory, it looks like a shared library, >PerlIO.so, that somehow got the directory bit set. Actually, no. It looks like a valid directory that somehow managed to get the high bit in its length set (random bit flip). The od output makes it look like it contains (or used to contain) PerlIO.so and PerlIO.bs. >Second, how do I remove the directory bit so I can delete the file? I'd try a fsck - that may detect the inconsistency and fix it to the point where rm works. If not, then you'll need to use fsdb(8) - just be careful with the latter - you can do major damage with it. Your second issue is how you got a random bit-flip - you might like to check your hardware. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpjik1ITJllG.pgp Description: PGP signature
Re: jdk16 web plugin on FreeBSD 7 AMD64 Issues
On 2008-Jun-26 16:23:23 -0400, Sabeeh Baig <[EMAIL PROTECTED]> wrote: >that the plugins from jdk16 and jdk15 on AMD64 worked. I can't comment on jdk16 but the jdk15 plugin does not work on amd64. There is a patch for jdk15 at ports/122904 that works for me. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp0xTleZQcRR.pgp Description: PGP signature
GEOM gotcha upgrading from 6.x to 7.x
Yesterday, I planned to try an upgrade from 6.x to 7.x on one of the servers at work, on the assumption that I could reasonably easily revert to 6.x if things went bad. My confidence in being able to do that was severely shaken when I saw "Upgrading metadata" messages for both geom_mirror disks when the 7.x kernel booted. Whilst I did not need to revert, some examination of the geom_mirror source shows that (as I feared), a 6.x kernel will choke on a 7.x geom_mirror. I've looked through the various geom man pages, UPDATING, the relevant commit message and various mailing lists and am unable to find any mention of this. Having the kernel automatically alter persistent state on the host in a way that is incompatible with earlier kernels is bad enough. Doing so without any mechanism to revert the change and with no "heads-up" warning of the change is, IMO, unacceptable. I accept that it's sometimes necessary to make changes that are not backward compatible or that are difficult to revert, such changes are normally discussed in advance and come with heads-up warnings. I can't think of any previous case where simply test booting a kernel is enough to render your system unusable with an older kernel. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpo7UvOGlDVy.pgp Description: PGP signature
Re: DigiBoard Xem with 2 extenal modules
On 2008-Jul-03 13:08:09 -0300, Alexandre Biancalana <[EMAIL PROTECTED]> wrote: >Is anybody running FreeBSD 7 DigiBoard Xem with 2 external 16-port modules ? I was unable to get it to work in 6.x and haven't tried with 7.x. My work-around was to use PCI cards (since I had a second one available). I have worked through the driver and compared it to the most recent Linux driver available from Digi, as well as upgrading the firmware to the most recent available to no avail. I know the second 16 ports works in Solaris but haven't tried Linux and verified that it doesn't work in FreeBSD. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpAgv2nrKbnm.pgp Description: PGP signature
Re: DigiBoard Xem with 2 extenal modules
On 2008-Jul-03 17:13:50 -0300, Alexandre Biancalana <[EMAIL PROTECTED]> wrote: >I tried in Linux and that works. But the customer solution was ever >FreeBSD and I don't want to change :-( Which implies that problem is inside our code. Maybe someone else needs to work through the Linux driver and see what it does that our driver isn't doing. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgplQdQP8SkKx.pgp Description: PGP signature
Re: msync() differences between Linux and FreeBSD
On 2008-Jul-02 05:00:02 -0700, Marcus Reid <[EMAIL PROTECTED]> wrote: > It seems that in FreeBSD, msync() waits for bits to be >committed to disk even when MS_ASYNC is specified. Your previous ktrace output suggests that, at least for the way rrdtool is using mmap(2), physical I/O is being performed by msync(2). It's not clear whether FreeBSD is ignoring the MS_ASYNC flag (the code suggests it isn't), is blocking on previously queued I/O or is blocking for some other reason. >First off, I don't know how frequently msync() is used, and whether changing >its behavior would impact the performance of many things. The behaviour of msync(2) is defined in the Single Unix Specification and FreeBSD adheres to SUS unless there is a very good reason. >media... i.e. issue real I/O. So msync() can't be a NOP if you go by >the OpenGroup specification. > >Is there a spec that FreeBSD is adhering to that prevents msync() with >MS_ASYNC from being a NOP, seeing as munmap() does the job? As per Matt's response that you quoted, yes. > And does this >really matter for the real-world performance of some apps? IMO, rrdtool is using mmap()/madvise()/msync()/munmap() in an unusual fashion and it should be fixed, rather than changing FreeBSD to match rrdtool. I believe a more usual approach would be to mmap() a file (or part thereof), optionally call madvise(), perform a series of accesses and maybe msync()s of any updated regions then a single munmap() before exiting. Performing mmap()/msync()/munmap() (where the msync() specifies the entire file) for each update maximises system overheads for no obvious benefit. Also, you mentioned hitting a "brick wall" between 940MB and 1161MB. That straddles 1GB. You may also be running into system or process boundary conditions (how much RAM do you have and what tuning have you done). You might like to write a tool to simulate the rrdtool behaviour with varying DB sizes and identify exactly what you are hitting. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpy7HVw3YMNp.pgp Description: PGP signature
