Re: cpu-timer rate

2005-12-05 Thread kama


On Sat, 3 Dec 2005, Peter Jeremy wrote:

 On Fri, 2005-Dec-02 14:32:58 +0100, kama wrote:
 I am just wondering why the cpu-timer is doubled from what I set in
 kern.hz?
 
 # vmstat -i
 interrupt  total   rate
 ...
 cpu0: timer 14314031   1999
 Total   14750922   2060
 
 # sysctl -a | grep hz
 kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 }

 There's only a single timer but FreeBSD needs two independent clocks.
 The 'tick' clock is used to update the TOD counters and decide when to
 reschedule processes.  The 'stathz' is used to collect statistics on
 CPU utilisation ('profhz' is used instead if any process is using
 profiling).  Since processes tend to synchronize to 'tick' the
 statistics clock needs to be independent to ensure that a CPU utilisation
 is correctly allocated.

 In order to simulate two clocks, FreeBSD runs the hardware clock at a
 high rate and uses two different divisors for the soft clocks (/2 for
 tick, /3 for profhz and /15 for stathz).  Larger divisors are better
 for utilisation statistics but increase clock interrupt overheads.

Ehm, Im sorry, but did that even answer my question?

I appreciate that you took time to answer about the different clocks. But
that does not answer why vmstat -i shows a rate of 2000 when I have set
the hz to 1000.

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


error messages from easyraid ex array are there again

2005-12-05 Thread Fritz Heinrichmeyer

Hello,

in march 2005 i reported strange scsi error messages from ahc driver and 
an easyraid ex system, i have not seen this messages for some month now 
(could also result from the fact that cyrus imap server was less used 
..). It raises on a partition where some files containing berkeley-db 
4.x databases are located that are massaged by cyrus imap server. I 
suspect there is no real media error, as nothing is announced at the 
control panel. Now i use freebsd 6 stable (compiled last week, SMP with 
two xeon CPUs).


There where no such messages under the FreeBSD 4.x versions.

es-i2.fernuni-hagen.de kernel log messages:
+++ /tmp/security.ktBMNZqs  Mon Dec  5 03:06:48 2005
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e d 9f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e e 1f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e d 9f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e e 1f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e 10 1f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e d 9f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e 10 1f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e e 1f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e 10 1f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e d 9f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e e 1f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e 10 1f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retrying Command (per Sense Data)
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e d 9f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retries Exhausted
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e 10 1f 0 0 80 0
+(da1:ahc2:0:5:0): CAM Status: SCSI Status Error
+(da1:ahc2:0:5:0): SCSI Status: Check Condition
+(da1:ahc2:0:5:0): MEDIUM ERROR asc:0,0
+(da1:ahc2:0:5:0): No additional sense information
+(da1:ahc2:0:5:0): Retries Exhausted
+g_vfs_done():da1s1e[READ(offset=1767817216, length=131072)]error = 5
+(da1:ahc2:0:5:0): READ(10). CDB: 28 0 0 4e e 1f 0 0 80 0
+(da1:ahc2:0:5:0): 

Re: a file version number going down after upgrade from 6.0-R to 6.0-S

2005-12-05 Thread martinko
On Mon, 5 Dec 2005 10:37:05 +0800, Xin LI wrote
 Hi,
 
 On 12/5/05, martinko [EMAIL PROTECTED] wrote:
  hello,
 
  i noticed, when upgrading from 6.0-R to 6-stable, that
  /etc/rc.d/wpa_supplicant version went down.
  until now i had believed that stable branch contains newer software than
  the release. if so, why this downgrade ??
 
 1.1.4.1 stands for first revision of the 4th branch on 1.1, and
 1.1.2.1 stands for first revision of the 2nd branch.  The former is
 created after the latter.  It's not a downgrade as RELENG_6_0 is
 created after RELENG_6 (hence 4 vs 2), and everything merged to
 RELENG_6_0 must be part of RELENG_6 before it happen.
 
 Cheers,
 --
 Xin LI [EMAIL PROTECTED] http://www.delphij.net


I see now. Many thanks for your explanation, Xin!

Martin
___
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 Stable reboots randomly during high load.

2005-12-05 Thread kama

The system crashed again this weekend, but nothing is created in
/var/crash.

/Bjorn

On Wed, 23 Nov 2005, Mike Tancsa wrote:

 At 09:33 AM 23/11/2005, kama wrote:

 The system crashes without polling enabled. That I added afterwards. With
 it enabled it crashes not so often as without polling.
 
 I'll try a GENERIC kernel with debuging enabled.

 The kernel option doesnt install any debugging into your running
 kernel, it just builds an additional kernel (called kernel.debug)
 with debugging symbols that you can compare the crash dump
 against.  In other words, it wont hurt performance.

  ---Mike

 /Bjorn
 
 On Wed, 23 Nov 2005, Mike Tancsa wrote:
 
   At 08:04 AM 23/11/2005, kama wrote:
  
   I have a HP DL380G3 Dual 2.4 w HT disabled.
  
  
   Polling and SMP is only a recent thing, as is polling support for the
   bge. I would try disabling that.  In terms of seeing why its crashing,
  
  
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
  
   Basically,
   make sure
  
  
   makeoptions DEBUG=-g#Build kernel with gdb(1)
  debug symbols
  
   is in your kernel config
   add
   dumpdev=/dev/da0s1b   # Device name to crashdump to (or NO).
   dumpdir=/var/crash# Directory where crash dumps are to be stored
  
   to /etc/rc.conf assuming da0s1b is your swap.  Install the new kernel
   and reboot.
  
   When and if it crashes again,
   gdb -k kernel.debug /var/crash/vmcore.0
  
   type bt full
  
   from the debugger and post the results.
  
---Mike
  

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

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


panic logging out on serial console

2005-12-05 Thread Bjoern A. Zeeb

Hi,

I had been logged in on serial console and typed 'exit' and the
RELENG_6 machine went *kaboom*. I hadn't seen sth like this befire on
any of my other machines:

i386/RELENG_6 from around 2005-11-17 11:00 UTC.

--- 8 8 8 ---
foo# exit
logout


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x20:0x0
stack pointer   = 0x28:0xef699954
frame pointer   = 0x28:0xef699968
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 70703 (getty)
trap number = 12
panic: page fault
Uptime: 5d21h1m43s
Dumping 1022 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 1023MB (261680 pages) 1007 991 975 959 943 927 911 895 879 863 847 83
1 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 ... ok

Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
--- 8 8 8 ---


I have the core file and can save it for some days but it won't
help a lot unless someone tells me how I can skip the frame with
the null pointer in kgdb.


--
Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic logging out on serial console

2005-12-05 Thread Gavin Atkinson
On Mon, 2005-12-05 at 11:47 +, Bjoern A. Zeeb wrote:
 I had been logged in on serial console and typed 'exit' and the
 RELENG_6 machine went *kaboom*. I hadn't seen sth like this befire on
 any of my other machines:
 
 i386/RELENG_6 from around 2005-11-17 11:00 UTC.
 
 --- 8 8 8 ---
 foo# exit
 logout
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x0
 fault code  = supervisor read, page not present
 instruction pointer = 0x20:0x0
 stack pointer   = 0x28:0xef699954
 frame pointer   = 0x28:0xef699968
 code segment= base 0x0, limit 0xf, type 0x1b
  = DPL 0, pres 1, def32 1, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 70703 (getty)
 trap number = 12
 panic: page fault
 
 I have the core file and can save it for some days but it won't
 help a lot unless someone tells me how I can skip the frame with
 the null pointer in kgdb.

I've never had a problem with backtraces (even when IP=0x0) but don't
forget you can always look at the stack with

(gdb) x/40xw 0xef699954

And then look for addresses that may be within the kernel (probably
start with 0xc)

I'd be interested to know if there is a possibilituy that your panic may
have anything to do with one that I saw
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/043944.html
which seems to be a race in the tty closedown code (which I guess may
also be executed during a logout)

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


Re: cpu-timer rate

2005-12-05 Thread Matthew D. Fuller
On Mon, Dec 05, 2005 at 09:42:08AM +0100 I heard the voice of
kama, and lo! it spake thus:
 
 I appreciate that you took time to answer about the different
 clocks. But that does not answer why vmstat -i shows a rate of 2000
 when I have set the hz to 1000.

Because the rate is always twice hz.


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic logging out on serial console

2005-12-05 Thread Bjoern A. Zeeb

On Mon, 5 Dec 2005, Gavin Atkinson wrote:


On Mon, 2005-12-05 at 11:47 +, Bjoern A. Zeeb wrote:

I had been logged in on serial console and typed 'exit' and the
RELENG_6 machine went *kaboom*. I hadn't seen sth like this befire on
any of my other machines:

i386/RELENG_6 from around 2005-11-17 11:00 UTC.

--- 8 8 8 ---
foo# exit
logout

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code  = supervisor read, page not present
instruction pointer = 0x20:0x0
stack pointer   = 0x28:0xef699954
frame pointer   = 0x28:0xef699968
code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 70703 (getty)
trap number = 12
panic: page fault

I have the core file and can save it for some days but it won't
help a lot unless someone tells me how I can skip the frame with
the null pointer in kgdb.


I've never had a problem with backtraces (even when IP=0x0) but don't
forget you can always look at the stack with

(gdb) x/40xw 0xef699954


oh thanks. I'll paste it in for the arguments:

(kgdb) x/40xw 0xef699954 
0xef699954:   * 0xc05b60db  0x  0xc23b5c00  0xc23b4400

0xef699964: 0xc23b5c00  0xef699980* 0xc0600ec8  0xc23b5cac
0xef699974: 0x  0x  0xc278a900  0xef68
0xef699984:   * 0xc0770a81  0xc23b5c00  0xc23b4400  0x0003
0xef64: 0xcb00  0xef6999bc* 0xc077062f  0xc23b5c00
0xef6999a4: 0x00770c5f  0x000c  0x0003  0xc23b5c00
0xef6999b4: 0xc23b5d1c  0xc23b5cf0  0xef6999d8* 0xc060209c
0xef6999c4: 0xc23b5c00  0xc23b5cc4  0xc2399300  0xef699bcc
0xef6999d4: 0xc0840b00  0xef6999f4* 0xc05a7f87  0xc2399300
0xef6999e4: 0x0003  0x2000  0xc278a900  0x

(kgdb) l *0xc05b60db
0xc05b60db is in knote (/u1/src/RELENG_6/sys/kern/kern_event.c:1534).
1529return;
1530
1531KNL_ASSERT_LOCK(list, islocked);
1532
1533if (!islocked) 
1534list-kl_lock(list-kl_lockarg); 
1535

1536/*
1537 * If we unlock the list lock (and set KN_INFLUX), we can 
eliminate
1538 * the kqueue scheduling, but this will introduce four

(kgdb) l *0xc0600ec8
0xc0600ec8 is in ttwwakeup (/u1/src/RELENG_6/sys/kern/tty.c:2451).
2446tp-t_outq.c_cc = tp-t_olowat) {
2447CLR(tp-t_state, TS_SO_OLOWAT);
2448wakeup(TSA_OLOWAT(tp));
2449}
2450KNOTE_UNLOCKED(tp-t_wsel.si_note, 0);
2451}
2452
2453/*
2454 * Look up a code for a specified speed in a conversion table;
2455 * used by drivers to map software speed values to hardware parameters.

(kgdb) l *0xc0770a81
0xc0770a81 is in comstart (systm.h:290).
285 static __inline intrmask_t  splsoftvm(void) { return 0; }
286 static __inline intrmask_t  splsofttq(void) { return 0; }
287 static __inline intrmask_t  splstatclock(void)  { return 0; }
288 static __inline intrmask_t  spltty(void){ return 0; }
289 static __inline intrmask_t  splvm(void) { return 0; }
290 static __inline voidsplx(intrmask_t ipl __unused)   { 
return; }
291
292 /*
293  * Common `proc' functions are declared here so that proc.h can be 
included
294  * less often.

(kgdb) l *0xc077062f
0xc077062f is in comparam (/u1/src/RELENG_6/sys/dev/sio/sio.c:1902).
1897ttyldoptim(tp);
1898
1899mtx_unlock_spin(sio_lock);
1900splx(s);
1901comstart(tp);
1902if (com-ibufold != NULL) {
1903free(com-ibufold, M_DEVBUF);
1904com-ibufold = NULL;
1905}
1906return (0);

(kgdb) l *0xc060209c
0xc060209c is in ttyopen (/u1/src/RELENG_6/sys/kern/tty.c:3145).
3140tp-t_termios = ISCALLOUT(dev) ? tp-t_init_out : 
tp-t_init_in;
3141tp-t_cflag = tp-t_termios.c_cflag;
3142if (tp-t_modem != NULL)
3143tp-t_modem(tp, SER_DTR | SER_RTS, 0);
3144++tp-t_wopeners;
3145error = tp-t_param(tp, tp-t_termios);
3146--tp-t_wopeners;
3147if (error == 0  tp-t_open != NULL)
3148error = tp-t_open(tp, dev);
3149if (error != 0)

(kgdb) l *0xc05a7f87
0xc05a7f87 is in giant_open (/u1/src/RELENG_6/sys/kern/kern_conf.c:242).
237 giant_open(struct cdev *dev, int oflags, int devtype, struct thread *td)
238 {
239 int retval;
240
241 mtx_lock(Giant);
242 retval = dev-si_devsw-d_gianttrick-
243 

panic: vm_fault: fault on nofault entry, addr: d0a5c000

2005-12-05 Thread David Scheidt
There were messages about rl1 receiving oversized frames just before
the panic.  They didn't get recorded, sorry.  (Working remotely, no
serial console.)

I've still got the dump.  I can do more if required.

Regards,

David


GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.

Unread portion of the kernel message buffer:
panic: vm_fault: fault on nofault entry, addr: d0a5c000
KDB: enter: panic
panic: from debugger
Uptime: 1d18h30m35s
Dumping 255 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 255MB (65280 pages) 240 224 208 192 176 160 144 128 112 96 80 64 48 
32 16

#0  doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc0564748 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2  0xc05649f3 in panic (fmt=0xc076844f from debugger)
at /usr/src/sys/kern/kern_shutdown.c:555
#3  0xc0457be9 in db_panic (addr=-1067991289, have_addr=0, count=-1, 
modif=0xcbfec924 ) at /usr/src/sys/ddb/db_command.c:438
#4  0xc0457b80 in db_command (last_cmdp=0xc0825ee4, cmd_table=0x0, 
aux_cmd_tablep=0xc07b02a4, aux_cmd_tablep_end=0xc07b02a8)
at /usr/src/sys/ddb/db_command.c:350
#5  0xc0457c48 in db_command_loop () at /usr/src/sys/ddb/db_command.c:458
#6  0xc045983d in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221
#7  0xc057c183 in kdb_trap (type=3, code=0, tf=0xcbfeca64)
at /usr/src/sys/kern/subr_kdb.c:473
#8  0xc0734a5c in trap (frame=
  {tf_fs = -872546296, tf_es = -1068040152, tf_ds = -1065877464, tf_edi = 
1, tf_esi = -1065735013, tf_ebp = -872494428, tf_isp = -872494448, tf_ebx = 
-872494384, tf_edx = 0, tf_ecx = -1056878592, tf_eax = 18, tf_trapno = 3, 
tf_err = 0, tf_eip = -1067991289, tf_cs = 32, tf_eflags = 658, tf_esp = 
-872494396, tf_ss = -1068086877}) at /usr/src/sys/i386/i386/trap.c:591
#9  0xc07277ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#10 0xc057bf07 in kdb_enter (msg=0x12 Address 0x12 out of bounds)
at cpufunc.h:60
#11 0xc05649a3 in panic (
fmt=0xc07a2c9b vm_fault: fault on nofault entry, addr: %lx)
at /usr/src/sys/kern/kern_shutdown.c:539
#12 0xc06d61ec in vm_fault (map=0xc1043000, vaddr=3500523520, 
fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277
#13 0xc0734c4f in trap_pfault (frame=0xcbfecc0c, usermode=0, eva=3500523520)
at /usr/src/sys/i386/i386/trap.c:731
#14 0xc07348e9 in trap (frame=
  {tf_fs = -1068171256, tf_es = -1049034712, tf_ds = 40, tf_edi = 
-1048979612, tf_esi = -794443778, tf_ebp = -872493928, tf_isp = -872494024, 
tf_ebx = -1049118720, tf_edx = -1048979456, tf_ecx = 39, tf_eax = -254535834, 
tf_trapno = 12, tf_err = 0, tf_eip = -1066193906, tf_cs = 32, tf_eflags = 
66054, tf_esp = 10896, tf_ss = 2048}) at /usr/src/sys/i386/i386/trap.c:432
#15 0xc07277ea in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#16 0xc0732c0e in generic_bcopy () at /usr/src/sys/i386/i386/support.s:489
(kgdb) quit



#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.422 2005/01/05 05:25:21 kuriyama Exp $

machine i386
cpu I586_CPU
cpu I686_CPU
ident   TOR

# To statically compile in device wiring instead of /boot/device.hints
#hints  GENERIC.hints # Default places to look for devices.

makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols

#optionsSCHED_ULE   # ULE scheduler
options SCHED_4BSD  # 4BSD scheduler
options PREEMPTION  # Enable kernel thread preemption
options INET# InterNETworking
options INET6   # IPv6 communications protocols
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH  

Re: panic logging out on serial console

2005-12-05 Thread Gavin Atkinson
On Mon, 2005-12-05 at 13:29 +, Bjoern A. Zeeb wrote:
 On Mon, 5 Dec 2005, Gavin Atkinson wrote:
 
  On Mon, 2005-12-05 at 11:47 +, Bjoern A. Zeeb wrote:
  I had been logged in on serial console and typed 'exit' and the
  RELENG_6 machine went *kaboom*. I hadn't seen sth like this befire on
  any of my other machines:
 
  i386/RELENG_6 from around 2005-11-17 11:00 UTC.
 
  --- 8 8 8 ---
  foo# exit
  logout
 
  Fatal trap 12: page fault while in kernel mode
  fault virtual address   = 0x0
  fault code  = supervisor read, page not present
  instruction pointer = 0x20:0x0
  stack pointer   = 0x28:0xef699954
  frame pointer   = 0x28:0xef699968
  code segment= base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, def32 1, gran 1
  processor eflags= interrupt enabled, resume, IOPL = 0
  current process = 70703 (getty)
  trap number = 12
  panic: page fault
 
  I have the core file and can save it for some days but it won't
  help a lot unless someone tells me how I can skip the frame with
  the null pointer in kgdb.
 
  I've never had a problem with backtraces (even when IP=0x0) but don't
  forget you can always look at the stack with
 
  (gdb) x/40xw 0xef699954
 
 oh thanks. I'll paste it in for the arguments:

(kgdb) x/40xw 0xef699954 
0xef699954:   * 0xc05b60db  0x  0xc23b5c000xc23b4400
0xef699964: 0xc23b5c00  0xef699980* 0xc0600ec80xc23b5cac
0xef699974: 0x  0x  0xc278a9000xef68
0xef699984:   * 0xc0770a81  0xc23b5c00  0xc23b44000x0003

[snip backtrace]

It looks nothing like mine so I'm pretty sure it's a different issue,
but I suspect there is enough detail there for someone who knows about
the tty/kqueue interaction to have a guess as to what is going on.  It
does look like one entry on the tty writers knote list has become NULL,
so maybe it's a race.

I wonder if
http://lists.freebsd.org/pipermail/freebsd-hackers/2005-April/011300.html is 
related?  Can you get a process listing out of the core file using
ps -M and see if it's similar to rwatson's panic?  Although in his
case, it looks like it panicked in the KNL_ASSERT_LOCK call, which again
would be indicative of a race (e.g. in your case the structure may have
been cleared between calling KNL_ASSERT_LOCK and
list-kl_lock(list-kl_lockarg) )

Gavin

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


Re: FreeBSD-6 amr and ahd trouble

2005-12-05 Thread Scott Long

Joerg Pulz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Fri, 2 Dec 2005, Michael Rogato wrote:

I know I'm a couple weeks late, but I've been having the same problem 
with my 300-8x. It seems that after a seemingly random period of time 
on my dual opteron box, the system just hangs. It did kernel panic 
once when I was taking down the geom array. Originally I thought it 
might have something to do with GEOM, but since it's also happened 
outside of a GEOM array, I'm kind of at a loss.


Have you managed to find anything out about what exactly is causing 
the problem? I don't get any kind of error messages, so I haven't had 
much luck in tracking it down.



With help from Scott Long and John Baldwin, i have my system up and 
running again without problems.

You should build your own kernel which should have
options MUTEX_NOINLINE
in the kernel configuration. With this option my system is working.

regards
Joerg



I think that the root problem is actually memory corruption from the
amr-cam module.  I haven't been able to nail it down further, though.
However, this module is entirely optional and isn't used for anything
in the base system (it's only useful if you hook up a cdrom or tape
drive to your RAID card), so I've disabled it CVS HEAD and RELENG_6
until I can fix it for good.

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


Re: cpu-timer rate

2005-12-05 Thread Kevin Oberman
 Date: Mon, 5 Dec 2005 06:49:10 -0600
 From: Matthew D. Fuller [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]
 
 On Mon, Dec 05, 2005 at 09:42:08AM +0100 I heard the voice of
 kama, and lo! it spake thus:
  
  I appreciate that you took time to answer about the different
  clocks. But that does not answer why vmstat -i shows a rate of 2000
  when I have set the hz to 1000.
 
 Because the rate is always twice hz.

While I will concede that I have no explanation, but on all of my systems
rate = HZ +/-1. I have never seen a case where rate/2 = HZ.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD-6 amr and ahd trouble

2005-12-05 Thread Joerg Pulz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Mon, 5 Dec 2005, Scott Long wrote:


Joerg Pulz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Fri, 2 Dec 2005, Michael Rogato wrote:

I know I'm a couple weeks late, but I've been having the same problem with 
my 300-8x. It seems that after a seemingly random period of time on my 
dual opteron box, the system just hangs. It did kernel panic once when I 
was taking down the geom array. Originally I thought it might have 
something to do with GEOM, but since it's also happened outside of a GEOM 
array, I'm kind of at a loss.


Have you managed to find anything out about what exactly is causing the 
problem? I don't get any kind of error messages, so I haven't had much 
luck in tracking it down.



With help from Scott Long and John Baldwin, i have my system up and running 
again without problems.

You should build your own kernel which should have
options MUTEX_NOINLINE
in the kernel configuration. With this option my system is working.

regards
Joerg



I think that the root problem is actually memory corruption from the
amr-cam module.  I haven't been able to nail it down further, though.
However, this module is entirely optional and isn't used for anything
in the base system (it's only useful if you hook up a cdrom or tape
drive to your RAID card), so I've disabled it CVS HEAD and RELENG_6
until I can fix it for good.


Hi Scott,

i've just backported the amr.c changes from HEAD and removed the
options MUTEX_NOINLINE
line from my kernel configuration. After rebuilding and installing the new 
kernel, the syste came up without any problems, so your assumption about 
the amr-cam interface seems to be right.


thanks
Joerg

- -- 
The beginning is the most important part of the work.

-Plato
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDlIW5SPOsGF+KA+MRArG8AJ9B+QuW28AcC+WgxnZLtqr2GOs/WgCeOhiF
uAjgpBQzOfT31ziF9C7MBVw=
=d98U
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: cpu-timer rate

2005-12-05 Thread Matthew D. Fuller
On Mon, Dec 05, 2005 at 10:15:52AM -0800 I heard the voice of
Kevin Oberman, and lo! it spake thus:
  From: Matthew D. Fuller [EMAIL PROTECTED]
  
  Because the rate is always twice hz.
 
 While I will concede that I have no explanation, but on all of my
 systems rate = HZ +/-1. I have never seen a case where rate/2 = HZ.

Well, OK, it always is when you're using the LAPIC timer, which I
think is on 6.x and up (with the APIC enabled, of course).  When
you're using irq0, it just runs at hz.


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


portmap IP conflict

2005-12-05 Thread Vincent Blondel
Hello all,

My FreeBSD actually knows an IP conflict due a bug in 'rpcbind' code. It
does well exist an option ( -h IP Address ) to bind 'rcpbind' process
to a unique IP address but this actually only works with UDP ( except
for a service running on port 855 but don't know what this service
is ??? ) and not TCP.

[EMAIL PROTECTED] [/home/vincent] # ps -waux |grep rpc
root  15505  0.0  0.1  1452  1144  ??  Is8:05PM   0:00.01
rpcbind -h 10.66.1.1

[EMAIL PROTECTED] [/home/vincent] # sockstat -l4
USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN
ADDRESS
root rpcbind15505 10 udp4   127.0.0.1:111 *:*
root rpcbind15505 11 udp4   10.66.1.1:111 *:*
root rpcbind15505 12 udp4   *:855 *:*
root rpcbind15505 13 tcp4   *:111 *:*

It seems that this problem is known for a long time but didn't find any
patch for it or just an old one for portmap 

  http://memberwebs.com/nielsen/freebsd/jails/patches/portmap-j.html

So is there somebody having such a patch but for rpcbind on FreeBSD
RELENG_5 ?

Regards
Vincent.

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


Re: USB Devices not appearing in /dev

2005-12-05 Thread Ronald Klop

On Mon, 05 Dec 2005 07:04:24 +0100, Igor Robul [EMAIL PROTECTED] wrote:


On Sun, Dec 04, 2005 at 12:59:14AM +1300, Jonathan Chen wrote:

However, if I look in /dev, I only see the generic usb[0-3] devices.
When I used to run 5.4-STABLE, the device entries did appear in /dev.
I have a similar problem with Palm devices and ucom0 not appearing.

In many cases, you need press Sync button on cable to make ucom
appear.


I think he needs /dev/cuaU0 as mentioned in the FILES section of 'man  
ucom'.


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


HP zd8000 laptop reboots on its own with FreeBSD 6.0 release

2005-12-05 Thread Rob

Hi, 

I have had several spontaneous reboots with the 6.0 release installed
off of the iso CD.  I am wondering if I should upgrade to stable?  

I have had problems with this laptop in Linux where it would not get
through the ACPI part of the boot process.  I would have to reboot it
several times before it would go all the way through.

After I first installed FreeBSD, I thought I might be having some
problem with Mozilla as it tends to create zombie processes.  Firefox
starts to eat up 100% cpu on the first WWW page visited.  But then it
could be an Xorg or Enlightenment problem as well.

I wonder if anyone else uses this type laptop, and if they have had
problems? Maybe before upgrading to stable I should try disabling ACPI
and/or hyperthreading and see what happens.  But I don't like waiting
for problems to happen if someone else has found the solution already.

Thanks a lot,

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


Re: cpu-timer rate

2005-12-05 Thread Kevin Oberman
 Date: Mon, 5 Dec 2005 13:47:56 -0600
 From: Matthew D. Fuller [EMAIL PROTECTED]
 
 On Mon, Dec 05, 2005 at 10:15:52AM -0800 I heard the voice of
 Kevin Oberman, and lo! it spake thus:
   From: Matthew D. Fuller [EMAIL PROTECTED]
   
   Because the rate is always twice hz.
  
  While I will concede that I have no explanation, but on all of my
  systems rate = HZ +/-1. I have never seen a case where rate/2 = HZ.
 
 Well, OK, it always is when you're using the LAPIC timer, which I
 think is on 6.x and up (with the APIC enabled, of course).  When
 you're using irq0, it just runs at hz.

That would explain it. While most of the systems in question are V6 or
V7, none is multi-processor and, being conservative, I don't run APIC
on any of them. (An exception is my -current system, but it locks up on
boot with APIC enabled.)

Maybe I should try it some time just to see what happens. ;-)

Thanks.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
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 Stable reboots randomly during high load.

2005-12-05 Thread Brian Fundakowski Feldman
On Mon, Dec 05, 2005 at 12:30:05PM +0100, kama wrote:
 
 The system crashed again this weekend, but nothing is created in
 /var/crash.

Try a serial console...

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
   [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Upgrading 5.3 6.0 buildworld failure in libkrb5

2005-12-05 Thread Vizion
Hi

I have tried repeatedly to get make buildworld for upgrading from freebsd 5.3 
to 6.0 but get repeated failure in libkrb5.

FreeBSD 5.3-RELEASE #0: Fri Nov  5 04:19:18 UTC 2004
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm)  (1593.54-MHz 686-class CPU)
  Origin = AuthenticAMD  Id = 0x6a0  Stepping = 0
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
  AMD Features=0xc048MP,AMIE,DSP,3DNow!
real memory  = 2080309248 (1983 MB)
avail memory = 2030002176 (1935 MB)
ACPI APIC Table: KM400A AWRDACPI

I have tried with very helpful advice from freebsd-questions contributors:

with and without ccache
3x make cleandir prior to build
additional cvsup of source tree

but the problem still remains . 
Hopefully someone on stable may have the answer.

Here is my make.conf

SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf
# added by use.perl 2005-11-18 10:51:36
PERL_VER=5.8.7
PERL_VERSION=5.8.7
.if !defined(NOCCACHE)
.if ${.CURDIR:M/usr/src*}
CC=/usr/local/libexec/ccache/cc
CXX=/usr/local/libexec/ccache/c++
.else
CC=cc
CXX=c++
.endif
.else
CC=/usr/bin/cc
CXX=/usr/bin/c++
.endif

I show the output from pkg_info below the build result

# cd /usr/src  make NOCCACHE=1 buildworld   make NOCCACHE=1 buildkernel

/* NOTE: I get the same failure for the same function in linkrb5 no matter 
what I try: */

/libkrb5/../../../crypto/heimdal/lib/krb5/net_write.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/padata.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/principal.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/prog_setup.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/prompter_posix.c
 /usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_cred.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_error.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_priv.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_rep.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_req.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/rd_safe.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/read_message.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/recvauth.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/replay.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/send_to_kdc.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/sendauth.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/set_default_realm.c
 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/sock_principal.c
 /usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/store.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/store_emem.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/store_fd.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/store_mem.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/ticket.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/time.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/transited.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/verify_init.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/verify_user.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/version.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/warn.c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/write_message.c
/usr/bin/cc -O2 -fno-strict-aliasing -pipe  
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5 
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1 
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I. 
-DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libkrb5/../../include -DINET6  
-c /usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/acl.c
/usr/bin/cc -O2 -fno-strict-aliasing -pipe  
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5 
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1 
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I. 
-DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libkrb5/../../include -DINET6  
-c /usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/add_et_list.c
/usr/bin/cc -O2 -fno-strict-aliasing -pipe  
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5 
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/asn1 
-I/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/roken -I. 
-DHAVE_CONFIG_H -I/usr/src/kerberos5/lib/libkrb5/../../include -DINET6  
-c 
/usr/src/kerberos5/lib/libkrb5/../../../crypto/heimdal/lib/krb5/addr_families.c
/usr/bin/cc -O2 -fno-strict-aliasing -pipe  

ZERO_COPY_SOCKETS

2005-12-05 Thread Joshua Coombs

#optionsZERO_COPY_SOCKETS

What's the status of this in 6.0-R and 6-stable?  The idea of avoiding 
memory copies when possible seems really appealing for my 386, on 
which any little boost is significant. : )


Joshua Coombs 



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


Re: ZERO_COPY_SOCKETS

2005-12-05 Thread Igor Robul
On Mon, Dec 05, 2005 at 09:20:28PM -0500, Joshua Coombs wrote:
 #optionsZERO_COPY_SOCKETS
 
 What's the status of this in 6.0-R and 6-stable?  The idea of avoiding 
 memory copies when possible seems really appealing for my 386, on 
 which any little boost is significant. : )
http://www.freebsd.org/releases/6.0R/relnotes-i386.html#KERNEL

So you can't use FreeBSD-6.0 and greater on 80386 anymore.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]