lock order reversal (arp mutex/radix node head)

2003-01-25 Thread Kris Kennaway
lock order reversal
 1st 0xc03bbde0 arp mutex (arp mutex) @ ../../../netinet/if_ether.c:151
 2nd 0xc6149e7c radix node head (radix node head) @ ../../../net/route.c:549
Debugger(witness_lock)
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db trace
Debugger(c031e895,c6149e7c,c033b2a0,c033b2a0,c033b2f6) at Debugger+0x55
witness_lock(c6149e7c,8,c033b2f6,225,0) at witness_lock+0x667
_mtx_lock_flags(c6149e7c,0,c033b2f6,225,c01bc2e4) at _mtx_lock_flags+0xb2
rtrequest1(2,df0d1c44,0,0,c638e680) at rtrequest1+0x5a
rtrequest(2,c638e680,0,0,0) at rtrequest+0x4b
arptfree(c612eb40,0,7530,97,7) at arptfree+0x76
arptimer(0,0,c03344ed,bf,1d9e6) at arptimer+0x80
softclock(0,0,c0331543,230,c21ab720) at softclock+0x19c
ithread_loop(c21a8e00,df0d1d48,c03313b4,361,0) at ithread_loop+0x182
fork_exit(c01a4650,c21a8e00,df0d1d48) at fork_exit+0xc4
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xdf0d1d7c, ebp = 0 ---
db 

Kris



msg50892/pgp0.pgp
Description: PGP signature


INVARIANTS-related fs panic on alpha

2003-01-25 Thread Kris Kennaway
One of the alpha package clients panicked with this.  It was under
very high load at the time (25 simultaneous package builds):

fatal kernel trap:

trap entry = 0x2 (memory management fault)
faulting va= 0xdeadc0dedeadc0e6
type   = access violation
cause  = store instruction
pc = 0xfc53453c
ra = 0xfc53b2a8
sp = 0xfe001da15b30
curthread  = 0xfc003e33b930
pid = 3, comm = g_up

Stopped at  add_to_worklist+0xac:   stq a0,0x8(t0) 0xdeadc0dedeadc0e6 
a0=0xfc0035deb200,t0=0xdeadc0dedeadc0de
db trace
add_to_worklist() at add_to_worklist+0xac
handle_written_inodeblock() at handle_written_inodeblock+0x5e8
softdep_disk_write_complete() at softdep_disk_write_complete+0xac
bufdone() at bufdone+0x19c
bufdonebio() at bufdonebio+0x1c
biodone() at biodone+0x28
g_dev_done() at g_dev_done+0xd8
biodone() at biodone+0x28
g_io_schedule_up() at g_io_schedule_up+0x4c
g_up_procbody() at g_up_procbody+0x9c
fork_exit() at fork_exit+0x100
exception_return() at exception_return
--- root of call graph ---
db



msg50893/pgp0.pgp
Description: PGP signature


Changes to pw/pw_user.c

2003-01-25 Thread Garance A Drosihn
I sent this message off about 12 hours ago, and I have not seen
it appear anywhere.  Since then I have received plenty of other
messages on the mailing lists (including messages I sent after
I sent this one).  So, I'm resending this one...

On Jan 24/2003, Max Khon wrote to freebsd-current:

hi, there!

Can we enable using '$' in usernames in pw?
The patch is attached.

Other variant is to enable using '$' only at end of user name.


Here is a patch which allows a '$' as the last character of a
userid or a group name.  Technically this is based on a patch
that Terry Lambert wrote, but by the time I was done with it I
imagine it's not recognizable.  This has been tested on i386
and sparc64 (beast.freebsd.org seems to be down right now, so I
can't do a test-compile on alpha).

This version of the patch only changes the pw_checkname() routine,
and also includes the previous version of pw_checkname() so you
can see how both the old and new routines behave on any given
value.  This also improves the error messages, and (IMO) makes
the routine a lot easier to follow.

Assuming there are no objections to this, I plan to rip out
everything that's between the #ifdef/endif's of TESTING_PW, and
commit the rest to -current sometime next week.  I have no plans
to MFC this change, but I'll also do that if people want it MFC'ed.

Please look it over, and maybe run it through some tests, and
let me know of any feedback to it.  (Should this print out some
kind of warning message that using '$' is generally not a good
idea?)

Instead of including the patch in my message (which I did the
first time), I've put it up at:

 http://people.freebsd.org/~gad/pw/pw_user-c.diff

--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: GEOM disklabel

2003-01-25 Thread Michael Reifenberger
On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote:
...
 Don't use the '-r' option, it gets confused because geom::BSD does
 not lie to it.
Yes, that seems to work...
Time to say good bye for '-r' ?

Bye!

Michael Reifenberger
^.*Plaut.*$, IT, R/3 Basis, GPS

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: GEOM disklabel

2003-01-25 Thread phk
In message [EMAIL PROTECTED], Michael Reifenberger 
writes:
On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote:
...
 Don't use the '-r' option, it gets confused because geom::BSD does
 not lie to it.
Yes, that seems to work...
Time to say good bye for '-r' ?

Well, we still need it for writing the first disklabel on an otherwise
empty disk, but I think it could be implied in that case.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: GEOM disklabel

2003-01-25 Thread Andrey A. Chernov
On Sat, Jan 25, 2003 at 10:17:39 +0100, [EMAIL PROTECTED] wrote:
 In message [EMAIL PROTECTED], Michael Reifenberger 
 writes:
 On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote:
 ...
  Don't use the '-r' option, it gets confused because geom::BSD does
  not lie to it.
 Yes, that seems to work...
 Time to say good bye for '-r' ?
 
 Well, we still need it for writing the first disklabel on an otherwise
 empty disk, but I think it could be implied in that case.

-B implies -r too. Currenty this check prevents my bootblocks from 
writting.

-- 
Andrey A. Chernov
http://ache.pp.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: [PATCH] Asus A7N8X Deluxe, nForce2 and 3com MAC, Broadcom/Altima PHY

2003-01-25 Thread Mikko S. Hyvarinen
On Sat, Jan 18, 2003 at 02:46:38PM -0800, David O'Brien wrote:
 On Sat, Jan 18, 2003 at 06:46:40PM +0200, Mikko Hyvarinen wrote:
  Hi again,O
  
  I find it outright odd that the partial patch that didn't help much got
  committed quickly but the final fix that makes things work didn't.
  
  Is there something wrong with the patch or did it just slip through the
  cracks somewhere?
 
 I got busy last week.  I just happen to have a few free minutes when the
 1st patch came in, and I have a big interest in AMD platforms.  I've got
 too many things on my plate for today to probably get to the 2nd patch.
 Other committers, please don't think I feel ownership of this patch.

Thank you for the commit. Now the support for this board is on a good basic
level.

I suppose there is not much hope of getting support for the nVidia MAC
integrated to the MCP (southbridge) since even the Linux drivers are
binary-only with a thin glue layer, and no specs seem to be available
on nVidia website, not even in the developer sections.

Regards,
 MSH

-- 
All opinions expressed above are mine alone and do not express the views
of my employer or any other organizations that I am affiliated with.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: firewire hangs on Thinkpad

2003-01-25 Thread Hidetoshi Shimokawa
hmm, I have no problem with my FireWire CardBus card.
If you can get traceback in DDB, please send it to me.

cardbus0: Resource not specified in CIS: id=10, size=800
cardbus0: Resource not specified in CIS: id=14, size=4000
fwohci1: Texas Instruments TSB43AA22 mem 0x88004000-0x88007fff,0x88008000-0x880087ff 
irq 9 at device 0.0 on cardbus0
fwohci1: PCI bus latency was changing to 250.
fwohci1: OHCI version 1.0 (ROM=1)
fwohci1: No. of Isochronous channel is 4.
fwohci1: EUI64 00:c0:d0:00:00:f8:56:6a
fwohci1: Phy 1394a available S400, 2 ports.
fwohci1: Link S400, max_rec 2048 bytes.
firewire1: IEEE1394(FireWire) bus on fwohci1
if_fwe1: Ethernet over FireWire on firewire1
if_fwe1: Fake Ethernet address: 02:c0:d0:f8:56:6a
fwohci1: BUS reset
fwohci1: node_id = 0x8800ffc0, non CYCLEMASTER mode
firewire1: 3 nodes, maxhop = 2, cable IRM = 2
firewire1: new bus manager 2 
firewire1: New S400 device ID:00d03200a412006a
firewire1: New S400 device ID:00a0b00a00060633
firewire1: Device SBP-II

/\ Hidetoshi Shimokawa
\/  [EMAIL PROTECTED]
PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html

At Fri, 24 Jan 2003 15:48:23 +0100,
Andrea Campi wrote:
 
 Hi all,
 
 I'm having a bad time trying to get a firewire cardbus adapter to work.
 First of all, let me say that I'm under no pressure - I just bought
it to
 test our firewire implementation  but I have no pressing need for it.
 
 Anyway, new kernel from last night, when I insert the card I get the following:
 
 cardbus0: Expecting link target, got 0x42
 cardbus0: Resource not specified in CIS: id=10, size=800
 cardbus0: Resource not specified in CIS: id=14, size=4000
 cardbus0: Resource not specified in CIS: id=18, size=800
 fwohci0: Texas Instruments TSB43AB22/A mem 0x880 
08000-0x880087ff,0x88004000-0x88007fff,0x88008800-0x88008fff irq 11 at device 0.0 on 
cardbus0
 fwohci0: PCI bus latency was changing to 250.
 fwohci0: OHCI version 1.10 (ROM=1)
 fwohci0: No. of Isochronous channel is 4.
 fwohci0: EUI64 00:01:fb:00:00:00:00:6e
 fwohci0: Phy 1394a available S400, 2 ports.
 fwohci0: Link S400, max_rec 2048 bytes.
 firewire0: IEEE1394(FireWire) bus on fwohci0
 fwohci0: BUS reset
 fwohci0: BUS reset
 fwohci0: node_id = 0xc000ffc0, CYCLEMASTER mode
 firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me)
 
 
 Sometimes it hangs the machine solid to the point I can't enter DDB, other
 times it takes a few seconds during which the machine is responsive, other
 times DDB is usable. I wasn't able to determine any rule to explain the
 different behaviors, but if anybody has any idea, I can try go get to DDB
 again and get any required info.
 
 Bye,
   Andrea
 
 -- 
 Where do you think you're going today?
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: new wi driver

2003-01-25 Thread Sam Leffler
  : dstumbler breaks; on startup it reports
  : unable to ioctl device socket: Input/output error.
 
  As root or no?

 I have a rebuilt system finally that I could test this against and I'm
 actually getting a different error message on startup of dstumbler:

 error: unable to ioctl device socket: Invalid argument

 From ktrace:

  43042 dstumbler CALL  sigaction(0x12,0x280b5850,0)
  43042 dstumbler RET   sigaction 0
  43042 dstumbler CALL  socket(0x2,0x2,0)
  43042 dstumbler RET   socket 3
  43042 dstumbler CALL  ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0)
  43042 dstumbler RET   ioctl 0
  43042 dstumbler CALL  ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0)
  43042 dstumbler RET   ioctl 0
  43042 dstumbler CALL  ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0)
  43042 dstumbler RET   ioctl 0
  43042 dstumbler CALL  ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0)
  43042 dstumbler RET   ioctl -1 errno 22 Invalid argument
  43042 dstumbler CALL  sigaction(0x12,0x280b5838,0x280b5850)
  43042 dstumbler RET   sigaction 0
  43042 dstumbler CALL  poll(0xbfbff3e8,0x1,0)
  43042 dstumbler RET   poll 0
  43042 dstumbler CALL  poll(0xbfbff3e8,0x1,0)
  43042 dstumbler RET   poll 0
  43042 dstumbler CALL  write(0x1,0x806,0x5e)
  43042 dstumbler GIO   fd 1 wrote 94 bytes
\^[[52;22H\^[[34m\^[[1m[\^[[31m error: unable to ioctl device
socket: \
 Invalid argument \^[[C\^[[39;49m\^[[m\^O


dstumbler uses WI_RID_SCAN_REQ to initiate a scan for AP's.  This required
the application know whether it was talking to a prims/wavelan/symbol card
so was replaced by WI_RID_SCAN_APS which provides a device-independent
interface.  I changed wicontrol to deal with this; it would be good if
dstumbler did likewise.  Otherwise I can look at adding a backwards
compatibility entry for WI_RID_SCAN_REQ.

Sam


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: I've just had a massive file system crash

2003-01-25 Thread Brooks Davis
On Fri, Jan 24, 2003 at 11:03:52PM -0800, David Schultz wrote:
 FreeBSD's ``fix'' for this problem is the same as Windows 98's.
 Specifically, there is a 5-second delay (tuneable:
 kern.shutdown.poweroff_delay) after all buffers are flushed but
 before the power is cut.  Maybe we ought to be sending FLUSH
 CACHE commands to all drives and waiting for them to finish.

I've heard is longer then 5sec on more recent systems like 2000 or XP.
I even heard one claim that some shops were using 30sec internally.

-- Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4



msg50901/pgp0.pgp
Description: PGP signature


Opening /dev/tty in session leader after controlling terminal is revoked causes panic.

2003-01-25 Thread Peter Edwards
Attached is a panic and patch a patch for the problem in the Subject line.

The problem is in kern/tty_tty.c:ctty_clone. It's assuming that if the process
has its P_CONTROLT flag set, then it's session has a valid vnode for it's
controlling terminal. This doesn't hold if the terminal was revoked.

Cheers,
Peter Edwards.
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x88
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc020795a
stack pointer   = 0x10:0xcdd7e7b8
frame pointer   = 0x10:0xcdd7e7c8
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 = 986 (mozilla-bin)
trap number = 12
panic: page fault

syncing disks, buffers remaining... panic: bdwrite: buffer is not busy
Uptime: 20h40m24s
Dumping 256 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112 128 144 160 176 192[CTRL-C to abort]  208 224 240
---
#0  doadump () at /pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) p/a 0xc020795a
$1 = 0xc020795a ctty_clone+74
(kgdb) bt
#0  doadump () at /pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:232
#1  0xc01d1969 in boot (howto=260) at 
/pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:364
#2  0xc01d1bc3 in panic () at /pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:531
#3  0xc0214ea0 in bdwrite (bp=0xc7783bf0) at 
/pub/FreeBSD/current/src/sys/kern/vfs_bio.c:955
#4  0xc028abab in ffs_update (vp=0xc27d3b18, waitfor=0)
at /pub/FreeBSD/current/src/sys/ufs/ffs/ffs_inode.c:125
#5  0xc029f62f in ffs_fsync (ap=0xcdd7e5c0) at
/pub/FreeBSD/current/src/sys/ufs/ffs/ffs_vnops.c:315
#6  0xc029e5f7 in ffs_sync (mp=0xc2691000, waitfor=2, cred=0xc0eb6e80, td=0xc034f000)
at vnode_if.h:612
#7  0xc022a7db in sync (td=0xc034f000, uap=0x0)
at /pub/FreeBSD/current/src/sys/kern/vfs_syscalls.c:138
#8  0xc01d154c in boot (howto=256) at 
/pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:273
#9  0xc01d1bc3 in panic () at /pub/FreeBSD/current/src/sys/kern/kern_shutdown.c:531
#10 0xc02f9c42 in trap_fatal (frame=0xcdd7e778, eva=0)
at /pub/FreeBSD/current/src/sys/i386/i386/trap.c:844
#11 0xc02f9922 in trap_pfault (frame=0xcdd7e778, usermode=0, eva=136)
at /pub/FreeBSD/current/src/sys/i386/i386/trap.c:758
#12 0xc02f93f0 in trap (frame=
  {tf_fs = -841547752, tf_es = -841547760, tf_ds = -1069416432, tf_edi = 
-1033343948, tf_esi
= -
841487372, tf_ebp = -841488440, tf_isp = -841488476, tf_ebx = -841488376, tf_edx = 
-841488260,
tf_ec
x = -1070401078, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071613606, tf_cs = 
8,
tf_eflags 
= 66050, tf_esp = -841488264, tf_ss = -1070401082})
at /pub/FreeBSD/current/src/sys/i386/i386/trap.c:445
#13 0xc02e94a8 in calltrap () at {standard input}:98
#14 0xc0195f38 in devfs_lookupx (ap=0x0) at
/pub/FreeBSD/current/src/sys/fs/devfs/devfs_vnops.c:382
#15 0xc01961db in devfs_lookup (ap=0xcdd7e914)
at /pub/FreeBSD/current/src/sys/fs/devfs/devfs_vnops.c:448
#16 0xc021ed12 in lookup (ndp=0xcdd7ebcc) at vnode_if.h:52
#17 0xc021e71b in namei (ndp=0xcdd7ebcc) at 
/pub/FreeBSD/current/src/sys/kern/vfs_lookup.c:181
#18 0xc0231eb9 in vn_open_cred (ndp=0xcdd7ebcc, flagp=0xcdd7eccc, cmode=420, 
cred=0xc2afb500)
at /pub/FreeBSD/current/src/sys/kern/vfs_vnops.c:122
#19 0xc0231e59 in vn_open (ndp=0x0, flagp=0x0, cmode=0)
at /pub/FreeBSD/current/src/sys/kern/vfs_vnops.c:86
#20 0xc022b683 in kern_open (td=0xc264d8c0, path=0x0, pathseg=UIO_USERSPACE, 
flags=1538,
mode=438)
at /pub/FreeBSD/current/src/sys/kern/vfs_syscalls.c:662
#21 0xc022b490 in open (td=0x0, uap=0x0) at 
/pub/FreeBSD/current/src/sys/kern/vfs_syscalls.c:625
#22 0xc02f9f6a in syscall (frame=
  {tf_fs = -65489, tf_es = -1078001617, tf_ds = -1078001617, tf_edi = 703138768, 
tf_esi =
678015
352, tf_ebp = -1077956120, tf_isp = -841486988, tf_ebx = 677213476, tf_edx = 1537, 
tf_ecx =
67801535
2, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 677550019, tf_cs = 31, tf_eflags = 
518,
tf_esp =
 -1077956148, tf_ss = 47}) at /pub/FreeBSD/current/src/sys/i386/i386/trap.c:1033
#23 0xc02e94fd in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---

(kgdb) disas ctty_clone
Dump of assembler code for function ctty_clone:
0xc0207910 ctty_clone:push   %ebp
0xc0207911 ctty_clone+1:  mov%esp,%ebp
0xc0207913 ctty_clone+3:  sub

Re: I've just had a massive file system crash

2003-01-25 Thread Nate Lawson
On Fri, 24 Jan 2003, David Schultz wrote:
 Thus spake Greg Lehey [EMAIL PROTECTED]:
  I've been thinking about what happened, and I have a possibility: the
  session before shutdown included a lot of writing to that file system,
  and I did a shutdown -p.  It's possible that the shutdown powered off
  the system before the disk had flushed its cache.  For the moment I'm
  avoiding shutdown -p, but when I get home I'll try to provoke it
  again.
 
 FreeBSD's ``fix'' for this problem is the same as Windows 98's.
 Specifically, there is a 5-second delay (tuneable:
 kern.shutdown.poweroff_delay) after all buffers are flushed but
 before the power is cut.  Maybe we ought to be sending FLUSH
 CACHE commands to all drives and waiting for them to finish.

da(4) does a SYNC CACHE (see daclose() and dashutdown()).

-Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: firewire hangs on Thinkpad

2003-01-25 Thread M. Warner Losh
This sounds like it might be an interrupt storm.  I'm not sure if the
fwohci driver is failing to clear an interrupt source, or if the
cardbus bridge is failing.  Have you connected a fw device to the
firewire card?

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Opening /dev/tty in session leader after controlling terminal is revoked causes panic.

2003-01-25 Thread phk
In message [EMAIL PROTECTED], Peter Edwards writes:

The problem is in kern/tty_tty.c:ctty_clone. It's assuming that if the process
has its P_CONTROLT flag set, then it's session has a valid vnode for it's
controlling terminal. This doesn't hold if the terminal was revoked.

Can you try this patch ?

Index: tty_tty.c
===
RCS file: /home/ncvs/src/sys/kern/tty_tty.c,v
retrieving revision 1.46
diff -u -r1.46 tty_tty.c
--- tty_tty.c   19 Jan 2003 11:03:07 -  1.46
+++ tty_tty.c   25 Jan 2003 19:39:15 -
@@ -70,10 +70,12 @@
return;
if (strcmp(name, tty))
return;
-   if (curthread-td_proc-p_flag  P_CONTROLT)
-   *dev = curthread-td_proc-p_session-s_ttyvp-v_rdev;
-   else
+   if (!(curthread-td_proc-p_flag  P_CONTROLT))
+   *dev = ctty;
+   else if (curthread-td_proc-p_session-s_ttyvp == NULL)
*dev = ctty;
+   else
+   *dev = curthread-td_proc-p_session-s_ttyvp-v_rdev;
 }
 
 static void
-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: new wi driver

2003-01-25 Thread Sean Chittenden
 dstumbler uses WI_RID_SCAN_REQ to initiate a scan for AP's.  This
 required the application know whether it was talking to a
 prims/wavelan/symbol card so was replaced by WI_RID_SCAN_APS which
 provides a device-independent interface.  I changed wicontrol to
 deal with this; it would be good if dstumbler did likewise.
 Otherwise I can look at adding a backwards compatibility entry for
 WI_RID_SCAN_REQ.

I've updated the sources with the new wlan request type and I'm not
getting anyfurther than before.  All of the bsd-airtools have all
kinds of nifty hacks to support the various interfaces and quirks of
each of the cards.  I think I'm going to dable with the various
bsd-airtools and update them to use the same interface that wicontrol
does and see if I can't kill off as many card specific quirks as I
can.  -sc

-- 
Sean Chittenden

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: rcconf.sh error

2003-01-25 Thread Mike Makonnen
Fixed. Thanks!


-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg50907/pgp0.pgp
Description: PGP signature


panic in fork() on SMP 5.0-RELEASE

2003-01-25 Thread Morten Rodal
Is this a known panic?  I tried to search the mailinglist archives to
see if somebody had posted something similar, but I couldn't find
anything.

The system is running 5.0-RELEASE with a pretty standard kernel (just
removed all the drivers I don't use and added SMP support).  I think
the load of the system might have been high at the moment as I had
just started


  cd /usr/ports  make -j8 clean

before I went to eat dinner.  When I came back a few hours later it at
rebooted, with this panic.

I have attached the backtrace of this (dual?) panic.  I have never
poked in the kernel source code before, so if there is anything else
you need to know just ask and I'll see what I can do.


-- 
Morten Rodal


Script started on Sat Jan 25 21:17:42 2003
slurp# gdb -k kernel.0 vmcore.0

GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address   = 0x14
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01bdb48
stack pointer   = 0x10:0xe3ac4c04
frame pointer   = 0x10:0xe3ac4cac
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 = 580 (sh)
trap number = 12
panic: page fault
cpuid = 0; lapic.id = 0100
boot() called on cpu#0

syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 5d18h59m34s
Dumping 447 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 
384 400 416 432
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1  0xc01d4bea in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2  0xc01d4ea7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3  0xc021a852 in bwrite (bp=0xcca8c150) at /usr/src/sys/kern/vfs_bio.c:796
#4  0xc021bf46 in vfs_bio_awrite (bp=0xcca8c150) at /usr/src/sys/kern/vfs_bio.c:1643
#5  0xc019e203 in spec_fsync (ap=0xe3ac49f4) at 
/usr/src/sys/fs/specfs/spec_vnops.c:462
#6  0xc019d558 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7  0xc02a9c62 in ffs_sync (mp=0xc3a37000, waitfor=2, cred=0xc1376e80, td=0xc035e900) 
at vnode_if.h:612
#8  0xc022fb9b in sync (td=0xc035e900, uap=0x0) at 
/usr/src/sys/kern/vfs_syscalls.c:138
#9  0xc01d47cb in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#10 0xc01d4ea7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#11 0xc030b662 in trap_fatal (frame=0xe3ac4bc4, eva=0) at 
/usr/src/sys/i386/i386/trap.c:844
#12 0xc030b312 in trap_pfault (frame=0xe3ac4bc4, usermode=0, eva=20) at 
/usr/src/sys/i386/i386/trap.c:758
#13 0xc030ae02 in trap (frame=
  {tf_fs = -475267048, tf_es = -1070792688, tf_ds = -988741616, tf_edi = 
-1070209248, tf_esi = -988528640, tf_ebp = -475247444, tf_isp = -475247632, tf_ebx = 
582, tf_edx = -989019040, tf_ecx = -988528640, tf_eax = 0, tf_trapno = 12, tf_err = 0, 
tf_eip = -1071916216, tf_cs = 8, tf_eflags = 66195, tf_esp = -1053458112, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:445
#14 0xc02f3918 in calltrap () at {standard input}:99
#15 0xc01bd2f0 in fork (td=0xc5144000, uap=0xe3ac4d10) at 
/usr/src/sys/kern/kern_fork.c:124
#16 0xc030b9bc in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi = 135258112, tf_ebp = 
-1077938280, tf_isp = -475247244, tf_ebx = 135236344, tf_edx = 135236332, tf_ecx = 
-1077938240, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 134723859, tf_cs = 31, 
tf_eflags = 514, tf_esp = -1077938324, tf_ss = 47}) at 
/usr/src/sys/i386/i386/trap.c:1033
#17 0xc02f396d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---

(kgdb) slurp# ^Dexit

Script done on Sat Jan 25 21:18:04 2003



msg50908/pgp0.pgp
Description: PGP signature


Re: panic in fork() on SMP 5.0-RELEASE

2003-01-25 Thread Nate Lawson
On Sat, 25 Jan 2003, Morten Rodal wrote:
 The system is running 5.0-RELEASE with a pretty standard kernel (just
 removed all the drivers I don't use and added SMP support).  I think
 the load of the system might have been high at the moment as I had
 just started
 
   cd /usr/ports  make -j8 clean

The problem is uap is invalid in this frame:
#15 0xc01bd2f0 in fork (td=0xc5144000, uap=0xe3ac4d10) at
/usr/src/sys/kern/kern_fork.c:124

The question is, why?  I suspect something to do with memory due to the
second two bytes being a valid kernel address.  How about a dmesg?

-Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: I've just had a massive file system crash

2003-01-25 Thread David Schultz
Thus spake Nate Lawson [EMAIL PROTECTED]:
 On Fri, 24 Jan 2003, David Schultz wrote:
  Thus spake Greg Lehey [EMAIL PROTECTED]:
   I've been thinking about what happened, and I have a possibility: the
   session before shutdown included a lot of writing to that file system,
   and I did a shutdown -p.  It's possible that the shutdown powered off
   the system before the disk had flushed its cache.  For the moment I'm
   avoiding shutdown -p, but when I get home I'll try to provoke it
   again.
  
  FreeBSD's ``fix'' for this problem is the same as Windows 98's.
  Specifically, there is a 5-second delay (tuneable:
  kern.shutdown.poweroff_delay) after all buffers are flushed but
  before the power is cut.  Maybe we ought to be sending FLUSH
  CACHE commands to all drives and waiting for them to finish.
 
 da(4) does a SYNC CACHE (see daclose() and dashutdown()).

Good.  I was referring to IDE in this case, because I assume
that's what Greg's laptop uses.  The ATA driver flushes the cache
when the device is closed, but I don't think that happens during
shutdown.  It probably needs to register a shutdown hook like the
SCSI driver.  Also, the driver is a bit optimistic about how long
the flush will take; it times out after 5 seconds, whereas the ATA
spec says a flush can take up to 30 seconds.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: panic in fork() on SMP 5.0-RELEASE

2003-01-25 Thread Morten Rodal
On Sat, Jan 25, 2003 at 12:38:28PM -0800, Nate Lawson wrote:
 The question is, why?  I suspect something to do with memory due to the
 second two bytes being a valid kernel address.  How about a dmesg?


[forgot to cc: [EMAIL PROTECTED]]

Are you suspecting faulty memory?

See attached dmesg.boot.

-- 
Morten Rodal


Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-RELEASE #0: Sun Jan 19 17:03:57 CET 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp
Preloaded elf kernel /boot/kernel/kernel at 0xc05e2000.
Preloaded elf module /boot/kernel/linux.ko at 0xc05e20b4.
Preloaded elf module /boot/kernel/snd_sb16.ko at 0xc05e2160.
Preloaded elf module /boot/kernel/snd_sbc.ko at 0xc05e2210.
Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc05e22bc.
Preloaded elf module /boot/kernel/nvidia.ko at 0xc05e2368.
Preloaded elf module /boot/kernel/acpi.ko at 0xc05e2414.
Timecounter i8254  frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x634  Stepping = 4
  Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX
real memory  = 469749760 (447 MB)
avail memory = 449974272 (429 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): apic id:  1, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  0, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS   P2L97-DS on motherboard
ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
Using $PIR table, 7 entries at 0xc00f0d20
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-safe  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
IOAPIC #0 intpin 19 - irq 2
IOAPIC #0 intpin 18 - irq 7
agp0: Intel 82443LX (440 LX) host to PCI bridge mem 0xe400-0xe7ff at device 
0.0 on pci0
pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
IOAPIC #0 intpin 16 - irq 11
nvidia0: GeForce2 GTS mem 0xd800-0xdfff,0xd600-0xd6ff irq 11 at 
device 0.0 on pci1
isab0: PCI-ISA bridge at device 4.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0xd800-0xd80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd400-0xd41f irq 2 at device 
4.2 on pci0
usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.03, addr 2, iclass 3/1
ums0: 5 buttons and Z dir.
Timecounter PIIX  frequency 3579545 Hz
pci0: bridge, PCI-unknown at device 4.3 (no driver attached)
ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xd000-0xd0ff mem 
0xd580-0xd5800fff irq 2 at device 6.0 on pci0
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
xl0: 3Com 3c905-TX Fast Etherlink XL port 0xb800-0xb83f irq 7 at device 10.0 on pci0
xl0: Ethernet address: 00:10:4b:3e:23:58
miibus0: MII bus on xl0
nsphy0: DP83840 10/100 media interface on miibus0
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A, console
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
orm0: Option ROMs at iomem 0xcc000-0xd0fff,0xc-0xcb7ff on isa0
pmtimer0 on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sbc0: Creative SB AWE64 Gold at port 0x388-0x38b,0x330-0x331,0x220-0x22f irq 5 drq 
5,1 on isa0
pcm0: SB16 DSP 4.16 on sbc0
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
Timecounters tick every 10.000 msec
ad0: 16479MB Maxtor 91728D8 [33483/16/63] at ata0-master UDMA33
ad2: 43979MB IBM-DTLA-307045 [89355/16/63] at ata1-master UDMA33
acd0: DVD-ROM CREATIVEDVD-ROM DVD2240E 12/24/97 at ata0-slave PIO4
Waiting 15 seconds for SCSI devices to settle
cd0 at ahc0 bus 0 target 4 lun 0
cd0: PLEXTOR CD-R   PX-R820T 1.03 Removable CD-ROM SCSI-2 device 
cd0: 5.000MB/s transfers (5.000MHz, offset 8)
cd0: cd present [327986 x 2048 byte records]
da0 at ahc0 bus 0 target 6 lun 0
da0: QUANTUM FIREBALL SE8.4S PJ09 Fixed Direct Access SCSI-2 

Re: acquiring duplicate lock of same type: system map

2003-01-25 Thread Kris Kennaway
On Sat, Jan 25, 2003 at 12:59:25PM -0600, Alan L. Cox wrote:
 Kris Kennaway wrote:
  
  bento found the following about 5 minutes after I upgraded it to 5.0.
  
  acquiring duplicate lock of same type: system map
   1st system map @ ../../../vm/vm_map.c:2168
   2nd system map @ ../../../vm/vm_kern.c:325
 
 Thanks for the stack trace.  I've finally flagged the system map mutex
 as duplicate ok, which it is.  The commit was a few minutes ago.

Thankyou!

Kris



msg50912/pgp0.pgp
Description: PGP signature


Patch to teach config(8) about platforms.

2003-01-25 Thread Juli Mallett
This patch is needed for the MIPS port's infrastructure, and will be
needed for the PowerPC one, as given ports may support any number of
platforms, on those architectures (and arguably, the same applies to
i386 vs. pc98, but historically...).  What it does is it sets up a
build-time (and install-time, given right MACHINE_ARCH vs. MACHINE)
platform include directory as an analogue to machine, where we
need it.  For kernels with a platform setting, it also sets the
appropriate option for it.  For example platform sgimips implies
options SGIMIPS.  Below are patches to makefile glue and config(8)
itself.

For clarity, this is used in cases where the platform may define its
own values that a header needs, and as such, you might see something
in machine/endian.h like:
#include platform/endian.h

To let the platform determine the endianness, as the port may support
many such configurations with different values.

And note that while it is tempting to have platform be machine on
systems with MACHINE == MACHINE_ARCH, this breaks things like mkioctl.

%%%
diff -dur src/include/Makefile mips/include/Makefile
--- src/include/MakefileFri Jan 24 00:34:40 2003
+++ src/include/MakefileThu Jan 23 22:46:13 2003
@@ -80,7 +80,7 @@
 .endfor
 
 copies:
-.for i in ${LDIRS} ${LSYMSUBDIRS} machine crypto
+.for i in ${LDIRS} ${LSYMSUBDIRS} platform machine crypto
if [ -L ${DESTDIR}/usr/include/$i ]; then \
rm -f ${DESTDIR}/usr/include/$i; \
fi
@@ -95,6 +95,11 @@
cd ${.CURDIR}/../sys; \
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 opencrypto/*.h \
${DESTDIR}/usr/include/crypto
+.if ${MACHINE_ARCH} != ${MACHINE}  
+exists(${.CURDIR}/../sys/${MACHINE_ARCH}/${MACHINE})
+   cd ${.CURDIR}/../sys/${MACHINE_ARCH}/${MACHINE}; \
+   ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
+   ${DESTDIR}/usr/include/platform
+.endif
 .if exists(${.CURDIR}/../sys/${MACHINE_ARCH}/include)
cd ${.CURDIR}/../sys/${MACHINE_ARCH}/include; \
${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 *.h \
@@ -118,6 +123,10 @@
rm -rf ${DESTDIR}/usr/include/$i
ln -s ../../../sys/$i ${DESTDIR}/usr/include/$i
 .endfor
+   rm -rf ${DESTDIR}/usr/include/platform
+.if ${MACHINE_ARCH} != ${MACHINE}  exists(../../sys/${MACHINE_ARCH}/${MACHINE})
+   ln -s ../../sys/${MACHINE_ARCH}/${MACHINE} ${DESTDIR}/usr/include/platform
+.endif
rm -rf ${DESTDIR}/usr/include/machine
ln -s ../../sys/${MACHINE_ARCH}/include ${DESTDIR}/usr/include/machine
 
diff -dur src/sys/conf/kmod.mk mips/sys/conf/kmod.mk
--- src/sys/conf/kmod.mkFri Jan 24 00:35:37 2003
+++ src/sys/conf/kmod.mkThu Jan 23 22:47:11 2003
@@ -145,7 +145,7 @@
 .endif
 .endif
 
-_ILINKS=@ machine
+_ILINKS=@ machine platform
 
 all: objwarn ${PROG}
 
@@ -170,10 +170,18 @@
 .error can't find kernel source tree
 .endif
 
+.if ${MACHINE_ARCH} != ${MACHINE}  exists(${SYSDIR}/${MACHINE_ARCH}/${MACHINE})
+PLATFORMPATH=  ${SYSDIR}/${MACHINE_ARCH}/${MACHINE}
+.else
+PLATFORMPATH=  machine
+.endif
+
 ${_ILINKS}:
@case ${.TARGET} in \
machine) \
path=${SYSDIR}/${MACHINE_ARCH}/include ;; \
+   platform) \
+   path=${PLATFORMPATH} ;; \
@) \
path=${SYSDIR} ;; \
esac ; \
diff -dur src/usr.sbin/config/config.h mips/usr.sbin/config/config.h
--- src/usr.sbin/config/config.hThu Nov  7 21:00:20 2002
+++ src/usr.sbin/config/config.hFri Nov  1 11:16:59 2002
@@ -91,9 +91,11 @@
  * being used.  It uses the name of the machine in choosing
  * files and directories.  Thus if the name of the machine is ``i386'',
  * it will build from ``Makefile.i386'' and use ``../i386/inline''
- * in the makerules, etc.
+ * in the makerules, etc.  It also *may* know about a platform, which
+ * is a superconfiguration of a given machine.
  */
 char   *machinename;
+char   *platformname;
 
 /*
  * For each machine, a set of CPU's may be specified as supported.
Only in mips/usr.sbin/config: config.o
diff -dur src/usr.sbin/config/config.y mips/usr.sbin/config/config.y
--- src/usr.sbin/config/config.yThu Nov  7 21:00:20 2002
+++ src/usr.sbin/config/config.yFri Nov  1 11:16:59 2002
@@ -14,6 +14,7 @@
 %token HINTS
 %token IDENT
 %token MAXUSERS
+%token PLATFORM
 %token PROFILE
 %token OPTIONS
 %token MAKEOPTIONS
@@ -135,6 +136,10 @@
cp-cpu_name = $2;
cp-cpu_next = cputype;
cputype = cp;
+ } |
+   PLATFORM Save_id
+   = {
+   platformname = $2;
  } |
OPTIONS Opt_list
|
Only in mips/usr.sbin/config: lang.c
diff -dur src/usr.sbin/config/lang.l mips/usr.sbin/config/lang.l
--- src/usr.sbin/config/lang.l  Thu Nov  7 21:00:20 2002
+++ src/usr.sbin/config/lang.l  Fri Nov  1 11:16:59 2002
@@ -73,6 +73,7 @@
{ machine,ARCH }, /* MACHINE is defined in 

Losing time on apm -Z (despite pmtimer)

2003-01-25 Thread Rahul Siddharthan
I have acpi disabled and apm enabled in /boot/device.hints
because acpi didn't do standby properly: apm -Z wouldn't turn off the
screen backlight, and on reawakening the screen would be messed up.
(acpiconf -s {2,3} didn't work either.)   With acpi, the following
problem doesn't exist.  It also didn't exist on 4-STABLE.

When I put the laptop into standby (apm -Z) -- suspend doesn't work --
the clock stays where it was before standby, when reawakened.  (eg, if
standby'd at 10:20 and reawakened at 11:00, it still shows 10:20).

I have device pmtimer in my kernel config, and
  hint.pmtimer.0.at=isa
in /device/hints.  dmesg shows
  pmtimer0 on isa0

This is -CURRENT cvsupped and built Jan 21, 2003.

Any ideas?  Any more information I can give?

Thanks,

Rahul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: acquiring duplicate lock of same type: system map

2003-01-25 Thread Alan L. Cox
Kris Kennaway wrote:
 
 bento found the following about 5 minutes after I upgraded it to 5.0.
 
 acquiring duplicate lock of same type: system map
  1st system map @ ../../../vm/vm_map.c:2168
  2nd system map @ ../../../vm/vm_kern.c:325

Thanks for the stack trace.  I've finally flagged the system map mutex
as duplicate ok, which it is.  The commit was a few minutes ago.

Regards,
Alan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: I've just had a massive file system crash

2003-01-25 Thread Daniel O'Connor
On Sun, 2003-01-26 at 08:08, David Schultz wrote:
 Good.  I was referring to IDE in this case, because I assume
 that's what Greg's laptop uses.  The ATA driver flushes the cache
 when the device is closed, but I don't think that happens during
 shutdown.  It probably needs to register a shutdown hook like the
 SCSI driver.  Also, the driver is a bit optimistic about how long
 the flush will take; it times out after 5 seconds, whereas the ATA
 spec says a flush can take up to 30 seconds.

I am wondering if I experienced this problem with my -stable laptop..

I shut it down and then booted it up later to find fsck having a nice
good chew on the drive (deleting REAMS of files).

I stopped it and then ripped it out of the lappy and mounted it read
only to recover most of my files.

Lots of things in /etc got toasted, and it was rather annoying to
recover from :(

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



HEADS UP: Required kernel config file change soon

2003-01-25 Thread Jeff Roberson
I'm about to commit code that will make one of :

options SCHED_4BSD

or

options SCHED_ULE

mandatory.  This will go in a few hours from now.  I will update all of
the standard config files to account for this change.  SCHED_4BSD selects
the old scheduler in case you're wondering.  Failure to specify one of the
two or specifying both will generate compile errors.  I will add code to a
header file at some point to check this at make depend time.

Cheers,
Jeff


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: Required kernel config file change soon

2003-01-25 Thread Jeff Roberson
Ok, this has been commited.  Expect build breakage if you don't add one of
these options or use GENERIC.

Cheers,
Jeff

On Sun, 26 Jan 2003, Jeff Roberson wrote:

 I'm about to commit code that will make one of :

 options SCHED_4BSD

 or

 options SCHED_ULE

 mandatory.  This will go in a few hours from now.  I will update all of
 the standard config files to account for this change.  SCHED_4BSD selects
 the old scheduler in case you're wondering.  Failure to specify one of the
 two or specifying both will generate compile errors.  I will add code to a
 header file at some point to check this at make depend time.

 Cheers,
 Jeff


 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: 5.0-RELEASE failing on Thinkpad T30

2003-01-25 Thread stark
 You are missing the src-sys-crypto collection in your supfile.
 Either use the src-all collection (*strongly* recommended) or else
 read the examples in /usr/share/examples/cvsup carefully and make
 sure you are getting all the collections you need.

I guess submitting a patch to ports/net/cvsupit that would include
this selection would be a better way, eh? :)

(i use cvsupit to make the cvsup file, so that's why i didn't even
know i was missing something :)

Thanks!

Dana Lacoste
Ottawa, Canada

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: if_sis.c failed to attach my SiS630 ethernet controller withthe latest commit

2003-01-25 Thread Toshiomi Moriki
I found the same problem in my FreeBSD box.
Isn't anyone have further informations about this problem?

*** my environment is following: 
 - FIC PA-2013 motherboard (VIA MVP3 chipsets)
 - SiS900 NIC

*** dmesg says: ***
Jan 11 23:15:32 rulue kernel: sis0: SiS 900 10/100BaseTX port 0xe800-0xe8ff mem 
0xea008000-0xea008fff irq 10 at device 9.0 on pci0
Jan 11 23:15:32 rulue kernel: sis0: Ethernet address: 00:40:26:ef:b0:c8
Jan 11 23:15:32 rulue kernel: sis0: MII without any PHY!
Jan 11 23:15:32 rulue kernel: device_probe_and_attach: sis0 attach returned 6

*** pciconf -vl says: ***
agp0@pci0:0:0:  class=0x06 card=0x chip=0x05971106 rev=0x04 hdr=0x00
vendor   = 'VIA Technologies Inc'
device   = 'VT82C597/597AT/598MVP Apollo VP3/MVP3 System Controller'
class= bridge
subclass = HOST-PCI
pcib1@pci0:1:0: class=0x060400 card=0x chip=0x85981106 rev=0x00 hdr=0x01
vendor   = 'VIA Technologies Inc'
device   = 'VT82C598MVP/694x Apollo MVP3/Pro133x PCI to AGP Bridge'
class= bridge
subclass = PCI-PCI
isab0@pci0:7:0: class=0x060100 card=0x chip=0x05861106 rev=0x47 hdr=0x00
vendor   = 'VIA Technologies Inc'
device   = 'VT82C586/A/B PCI to ISA Bridge'
class= bridge
subclass = PCI-ISA
atapci0@pci0:7:1:   class=0x01018a card=0x chip=0x05711106 rev=0x06 
hdr=0x00
vendor   = 'VIA Technologies Inc'
device   = 'VT82 EIDE Controller (All VIA Chipsets)'
class= mass storage
subclass = ATA
uhci0@pci0:7:2: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x02 hdr=0x00
vendor   = 'VIA Technologies Inc'
device   = 'VT82x UHCI USB 1.1 Controller (All VIA Chipsets)'
class= serial bus
subclass = USB
pcib2@pci0:7:3: class=0x060400 card=0x chip=0x30401106 rev=0x10 hdr=0x01
vendor   = 'VIA Technologies Inc'
device   = 'VT83C572, VT86C586/A/B Power Management Controller'
class= bridge
subclass = PCI-PCI
sis0@pci0:9:0:  class=0x02 card=0x030e1154 chip=0x09001039 rev=0x02 hdr=0x00
vendor   = 'Silicon Integrated Systems (SiS)'
device   = 'SiS900 Fast Ethernet/Home Networking Ctrlr'
class= network
subclass = ethernet
pcm0@pci0:11:0: class=0x040100 card=0x00041073 chip=0x00041073 rev=0x05 hdr=0x00
vendor   = 'Yamaha Corporation'
device   = 'YMF724 PCI Audio Controller'
class= multimedia
subclass = audio
none0@pci1:0:0: class=0x03 card=0xff03102b chip=0x0521102b rev=0x01 hdr=0x00
vendor   = 'Matrox Graphics Inc'
device   = 'MGA-G200B Chipset (AGP)'
class= display
subclass = VGA

-- Toshiomi Moriki

From: Shizuka Kudo [EMAIL PROTECTED]
Subject: if_sis.c failed to attach my SiS630 ethernet controller with the latest commit

 Dear all,
 
 I have tracked down the change on sys/pci/if_sis.c ver. 1.61 failed to attach my SiS 
ethernet
 interface. I have an ASUS TUSI-M, a SiS630 motherboard and running the latest 
-current. After
 backed out if_sis.c to ver. 1.60, the ethernet works fine.
 
 Here's the dmesg extract related to the ethernet interface. I has turned on verbose 
boot, but it
 doesn't give me further information.
 
 sis0: SiS 900 10/100BaseTX port 0xd400-0xd4ff mem 0xe780-0xe7800fff irq 14 at 
device 1.1 on
 pci0
 sis0: Ethernet address: 00:e0:18:00:00:03
 sis0: MII without any PHY!
 device_probe_and_attach: sis0 attach returned 6
 
 Regards,
 
 __
 Do you Yahoo!?
 Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
 http://mailplus.yahoo.com

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Pick

2003-01-25 Thread jeff
Hey Bro,

Check out this pick. It's GUARANTEED TO WIN.

FAVORITE   LINE UNDERDOG
Raiders  4  Bucs

Take RAIDERS.  

My source is NEVER wrong.

Get back to me when you win and have fun counting your money!!!

Take it easy.

Jeff


7441NCrV7-535ZsiU0041Pzcv0-388bKki7964GStQ7-99l43

2465lFyu0-136wohf4336xQgz7-245saYd1636Fl37èR{.nÇ+‰·¬zwfj)m¢f£¢·hškyàRŠàÂ+aº{.nÇ+‰·Ÿ­ç›±×.®·§¶)í…æèw*¶¦zˁ