Re: nvi strangeness
On Fri, 2008-02-08 at 11:38 +, Alex Zbyslaw wrote: > Dag-Erling Smørgrav wrote: > > >That doesn't work, however, and neither does "1,"; only "X,Y" works, so > >if you want to substitute in the entire file, you first have to find out > >how long it is, then manually type in that number. > > > > > > > Does 1,$ not work? That's what I always used in ed. Yes, it works. I use it all the time in nvi, in various forms. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Laptop suggestions?
My old Dell Inspiron 5160 has developed problems that I can't fix, sigh, so it's time to replace it. I'm hoping for some good suggestions from this list (cc'd to hackers for the exposure, I know everyone doesn't read -mobile). My criteria: * 3D acceleration. * MiniPCI wireless (don't care which card, I'll replace it anyway). * At least 15" screen. * Decent power consumption. * Plays well with FreeBSD 7-stable. Nice to have: * Dual core. * >4GB memory. * Working suspend/hibernate mode (and no, I'm not holding my breath). So, suggestions? BTW, if I get a decent response I'll summarize it for the list, along with the one I chose and my experience after ordering/installing it. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Laptop suggestions?
On Fri, 2008-07-25 at 18:02 -0400, John Nielsen wrote: > On Thursday 24 July 2008, Frank Mayhar wrote: > > My old Dell Inspiron 5160 has developed problems that I can't fix, sigh, > > so it's time to replace it. I'm hoping for some good suggestions from > > this list (cc'd to hackers for the exposure, I know everyone doesn't > > read -mobile). Turns out the issue is a known problem, although one that Dell is apparently refusing to own up to, with overheating causing problems with the power connector on the 5150 and 5160 motherboards and often with other nearby components as well. Annoying, and makes me want to stay away from Dell. > I haven't played with one hands-on, but the laptop I was going to buy until > $work supplied a different one was a Fujitsu Lifebook E8410. It has a few > customization options if you get it from Fujitsu directly. Among these are > Intel graphics and Atheros wireless, 2 of the main things I was looking for > for good FreeBSD hw support. After reading all the replies I'm actually taking your suggestion and going with Fujitsu, specifically the E8420. I'm getting the NVidia option and I'll be running in i386 mode until FreeBSD can handle the nvidia requirements for amd64 mode. Atheros wireless, WSXGA+ option and 2GB upgradable to 4. I'll keep my fingers crossed with regard to working suspend/resume but again I'm not holding my breath. They claim that with the 8-cell main and 6-cell modular battery it has a 5:30 runtime; we'll see. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Laptop suggestions?
On Thu, 2008-07-31 at 12:48 +0200, Achim Patzner wrote: > Wrong on both counts. I'm just using the appropriate tools for the jobs > that need to be done. And on the desktop FreeBSD just plain sucks in > comparison to Mac OS. The problem is that you are expressing your opinion as if it is a Basic Fact of the Universe. It ain't. Get over it. (For the record, I've been running FreeBSD on laptops for, well, lots of years now. Not to mention on my main desktop system for a lot longer than that. I'm _very_ happy with it. On the other hand, the Mac interface annoys me endlessly. But of course that's _my_ opinion.) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fdescfs updates--coming to a devfs near you!
Poul-Henning Kamp wrote:
> I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
> is bogus. It looks like something which happened "because we can" more
> than something which has a legitimate need.
I strongly disagree. I actually have a script that I use daily which requires
a filename as an argument. By handing it /dev/stdin, I can make it take
output as a part of a pipe. A _very_ useful little feature, IMNSHO.
As far as fdescfs, well, Unixware has something very like it, and I believe
that other commercial Unices do as well. I suspect that it's useful to
some, if not to all.
One thing about end users as opposed to engineers, they put this stuff to
uses that we can't even imagine. Never underestimate the sheer ingenuity
of a relatively naive user. :-)
--
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://store.exit.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Yeah, but what does it mean? [Was: Re: File trees: the deeper, the weirder]
On Sun, 2006-10-29 at 10:51 -0800, [EMAIL PROTECTED] wrote: > What does vnlru stand for? VNode List Recycling Unit? Someone please > tell me. I lost Deep Thought's email address, so I'm a bit stuck. I wasn't in on the naming, but I'll bet it stands for something along the lines of VNode Least Recently Used. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
UFS2 version of ffsrecov.
No, I'm not looking for one, I'm releasing one. This is a heavily modified version of John-Mark Gurney's ffsrecov, adapted to use libufs and to work (only) with UFS2 file systems. I call it ffs2recov and it is available at http://www.exit.com/Archives/FreeBSD/ffs2recov.tar.bz2 I wrote this a couple of years ago so that I could recover a file system that had been stomped by a misconfigured RAID controller. It worked well enough for me to recover a couple of hundred gigabytes worth of data, which was a great relief (although some stuff was gone forever, sigh). I had intended to polish it up and release it long before now, but I've never managed to get around to doing the polishing. In particular, while it has a nice little summary of implemented options, the manpage needs a lot of work. On the positive side, however, I extended it to be a lot more robust in the face of corrupt pointers and file system offsets, so it doesn't just fall over when it sees garbage in a block address or whatnot. I'm releasing it under the BSD two-clause license, with due credit to John-Mark. It's my hope that someone else will take it, clean it up a bit, rewrite the manpage and maybe make a port out of it. If you do and you need a place to host the distfile, let me know. In any event, it's a tool that people often need. Enjoy. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UFS2 version of ffsrecov.
On Mon, 2007-02-05 at 12:27 +0100, Ivan Voras wrote: > Frank Mayhar wrote: > > No, I'm not looking for one, I'm releasing one. This is a heavily > > modified version of John-Mark Gurney's ffsrecov, adapted to use libufs > > and to work (only) with UFS2 file systems. I call it ffs2recov and it > > is available at > > http://www.exit.com/Archives/FreeBSD/ffs2recov.tar.bz2 > Can it undelete files on a working file system? Heh, I figured someone would ask that question. The answer is, for the most part, no, it can't. When you delete a file the directory entry is freed; ffs2recov doesn't know how to recover it and in fact it may not _be_ recoverable. If it is at all, fsdb might be your best bet. On the other hand, you might also shoot your own foot off. :-) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kerberized NFS work?
Is there, by any chance, anyone out there working on kerberized NFS for FreeBSD. That is, the rpcsec_gss support in particular as well as the support in NFS4? I really really want to run FreeBSD on my desktop at work but it needs to talk to kerberized NFS servers... -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Getrusage(2) weirdness.
I recently had occasion to need the ru_maxrss field returned from getrusage(2) in Linux 2.6, which as it happens was not implemented. So I implemented it. In the process I wrote a test program to validate my implementation. I also tried running the test under various other operating systems, including FreeBSD 6-stable. Most systems don't implement the field (including Solaris and MacOSX), FreeBSD is one of the few that does. Only, it does so weirdly. You can find the test program at http://www.exit.com/Archives/Linux/getrusage-test.c The output should be pretty self-explanatory. If you run it under FreeBSD 6.2 (at least), you will find that it give inconsistent results. Something like the following: jill ~>./getrusage-test before 0 after: 0 1: rusage_self: FAIL flag 6 granddad 0, kid1 0, kid2 0, kid3 0 kid4 0 kid5 2372 sz 1365 2: rusage_grandchildren: PASS flag 3 dad 0, kid1 2372, kid2 2372, kid3 2372 kid4 2372 sz 2048 3: rusage_children: FAIL flag 3 dad 0, kid1 2372, kid2 2372, kid3 2372 kid4 2372 sz 4096 4: rusage_ignorechildren: PASS jill ~>./getrusage-test before 0 after: 968 1: rusage_self: FAIL flag 6 granddad 968, kid1 0, kid2 0, kid3 0 kid4 0 kid5 0 sz 1365 2: rusage_grandchildren: FAIL flag 3 dad 968, kid1 0, kid2 0, kid3 0 kid4 3572 sz 2048 3: rusage_children: PASS flag 3 dad 1820, kid1 3572, kid2 3572, kid3 3572 kid4 3572 sz 4096 4: rusage_ignorechildren: PASS jill ~>./getrusage-test before 0 after: 0 1: rusage_self: FAIL flag 6 granddad 0, kid1 0, kid2 0, kid3 0 kid4 0 kid5 2336 sz 1365 2: rusage_grandchildren: PASS flag 3 dad 1760, kid1 2336, kid2 2336, kid3 2336 kid4 2336 sz 2048 3: rusage_children: FAIL flag 3 dad 1760, kid1 2336, kid2 2336, kid3 2336 kid4 2336 sz 4096 4: rusage_ignorechildren: PASS jill ~>./getrusage-test before 0 after: 1144 1: rusage_self: PASS flag 6 granddad 1144, kid1 0, kid2 0, kid3 0 kid4 0 kid5 0 sz 1365 2: rusage_grandchildren: FAIL flag 3 dad 1144, kid1 0, kid2 0, kid3 0 kid4 0 sz 2048 3: rusage_children: FAIL flag 3 dad 1144, kid1 0, kid2 0, kid3 0 kid4 0 sz 4096 4: rusage_ignorechildren: PASS jill ~>./getrusage-test before 0 after: 0 1: rusage_self: FAIL flag 6 granddad 0, kid1 0, kid2 0, kid3 0 kid4 0 kid5 1936 sz 1365 2: rusage_grandchildren: PASS flag 3 dad 1760, kid1 1936, kid2 1936, kid3 1936 kid4 1936 sz 2048 3: rusage_children: FAIL flag 3 dad 1760, kid1 1936, kid2 1936, kid3 1936 kid4 1936 sz 4096 4: rusage_ignorechildren: PASS jill ~>./getrusage-test before 0 after: 0 1: rusage_self: FAIL flag 6 granddad 0, kid1 0, kid2 0, kid3 0 kid4 0 kid5 0 sz 1365 2: rusage_grandchildren: FAIL flag 3 dad 0, kid1 0, kid2 0, kid3 0 kid4 3052 sz 2048 3: rusage_children: PASS flag 3 dad 0, kid1 3052, kid2 3052, kid3 3052 kid4 3052 sz 4096 4: rusage_ignorechildren: PASS jill ~>./getrusage-test before 0 after: 0 1: rusage_self: FAIL flag 6 granddad 0, kid1 0, kid2 0, kid3 0 kid4 0 kid5 0 sz 1365 2: rusage_grandchildren: FAIL flag 3 dad 0, kid1 0, kid2 0, kid3 0 kid4 3208 sz 2048 3: rusage_children: PASS flag 3 dad 0, kid1 3208, kid2 3208, kid3 3208 kid4 3208 sz 4096 4: rusage_ignorechildren: PASS jill ~>./getrusage-test before 492 after: 492 1: rusage_self: FAIL flag 6 granddad 492, kid1 0, kid2 0, kid3 0 kid4 0 kid5 0 sz 1365 2: rusage_grandchildren: FAIL flag 3 dad 492, kid1 0, kid2 0, kid3 0 kid4 0 sz 2048 3: rusage_children: FAIL flag 3 dad 492, kid1 0, kid2 0, kid3 0 kid4 0 sz 4096 4: rusage_ignorechildren: PASS jill ~>./getrusage-test before 444 after: 444 1: rusage_self: FAIL flag 6 granddad 444, kid1 0, kid2 0, kid3 0 kid4 0 kid5 0 sz 1365 2: rusage_grandchildren: FAIL flag 3 dad 444, kid1 0, kid2 0, kid3 0 kid4 0 sz 2048 3: rusage_children: FAIL flag 3 dad 444, kid1 0, kid2 0, kid3 0 kid4 0 sz 4096 4: rusage_ignorechildren: PASS -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck of large volume with small memory
On Mon, 2007-09-24 at 16:30 -0700, Don Lewis wrote: > On 24 Sep, sam wrote: > > hi, all > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-June/151686.html > > > > my problem > > # fsck /dev/aacd0s1f > > ** /dev/aacd0s1f (NO WRITE) > > ** Last Mounted on /usr > > ** Phase 1 - Check Blocks and Sizes > > fsck_ufs: cannot alloc 2378019004 bytes for inoinfo > > I'd be willing to bet that one of the cylinder group blocks in your file > system got corrupted. > > > any solutions ? > > The patch below should allow a manual fsck to run to completion. I'd > recommend running "fsck -N" and capturing its output. Then use the clri > command (either standalone or in fsdb) to zero out the uninitialized > inodes that are unmasked by setting cg_initediblk to its maximum > possible value based on the file system parameters. > > Expect major file system lossage ... You might also want to try ports/sysutils/ffsrecov2 before you run this fsck. It might allow you to recover data that would otherwise be lost. (Like, say, if there are directories hidden beneath the corrupt inode.) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SB Live! versus -stable.
I sent this to stable, to a deafening silence. I'm therefore forwarding
it to hackers as well.
Well, I had three panics from this today (the first was accidental when I
went to a webpage with music attached; the other two were me trying to get
a good dump). I got some info from the dump. The most relevant bits are
that the NMI was at IP 0x280f819a, which isn't in the kernel. I don't know
where this might be, a shared library maybe? (I was running the Linux
Netscape 4.73, if that might help.)
I've attached a disassembly around the faulting instruction, as well as
some other info gleaned from the dump. Cameron, et al, if you want any
other info, please let me know; I'll hang on to the dump as long as
necessary (when you have 36 gig, space isn't a real problem :-).
--
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://store.exit.com/
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:302
#1 0xc01612f5 in panic (
fmt=0xc02a1660 "RAM parity error, likely hardware failure.")
at ../../kern/kern_shutdown.c:552
#2 0xc0267e8d in isa_nmi (cd=0) at ../../i386/isa/intr_machdep.c:187
#3 0xc025f42f in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 147577152, tf_esi = 135760192, tf_ebp = -1077937456,
tf_isp = -656769068, tf_ebx = 262144, tf_edx = 135729216,
tf_ecx = 254400, tf_eax = 11816960, tf_trapno = 19, tf_err = 0,
tf_eip = 672104858, tf_cs = 31, tf_eflags = 66054, tf_esp = -1077937560,
tf_ss = 47}) at ../../i386/i386/trap.c:379
#4 0x280f819a in ?? ()
#5 0x8051b67 in ?? ()
#6 0x8054d3a in ?? ()
#7 0x8054e09 in ?? ()
#8 0x804a2cf in ?? ()
#9 0x80495c5 in ?? ()
(kgdb) print /x frame
$1 = {tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 0x8cbd940,
tf_esi = 0x8178940, tf_ebp = 0xbfbffad0, tf_isp = 0xd8da7fd4,
tf_ebx = 0x4, tf_edx = 0x8171040, tf_ecx = 0x3e1c0, tf_eax = 0xb45000,
tf_trapno = 0x13, tf_err = 0x0, tf_eip = 0x280f819a, tf_cs = 0x1f,
tf_eflags = 0x10206, tf_esp = 0xbfbffa68, tf_ss = 0x2f}
0x280f8148: andb $0x4e,%al
0x280f814a: je 0x280f818f
0x280f814d: pushl %ebx
0x280f814e: incl %esp
0x280f814f: cmpb (%eax),%ah
0x280f8151: boundl 0x6f(%ebx),%esp
0x280f8154: jo 0x280f81cf
0x280f8156: pushl %ebx
0x280f8158: subb $0x76,%al
0x280f815a: andb %dh,(%ecx)
0x280f815c: andb %dh,%cs:%ss:(%ecx)
0x280f8160: cmpl %edi,(%ecx)
0x280f8162: das
0x280f8164: xorl %esi,(%ecx)
0x280f8166: das
0x280f8167: xorl %esi,(%edx)
0x280f8169: andb %dh,(%eax)
0x280f816b: xorb %bh,(%edx)
0x280f816d: xorl $0x36303a30,%eax
0x280f8172: andb %ch,0x74(%edx)
0x280f8175: arpl %sp,(%eax)
0x280f8177: incl %ebp
0x280f8178: js 0x280f81ea
0x280f817a: andb %ah,(%eax,%eax,1)
0x280f817d: leal 0x0(%esi),%esi
0x280f8180: pushl %esi
0x280f8181: pushl %edi
0x280f8182: movl 0xc(%esp,1),%edi
0x280f8186: movl 0x10(%esp,1),%esi
0x280f818a: movl 0x14(%esp,1),%ecx
0x280f818e: movl %edi,%eax
0x280f8190: subl %esi,%eax
0x280f8192: cmpl %ecx,%eax
0x280f8194: jb 0x280f81ac
0x280f8196: cld
0x280f8197: shrl $0x2,%ecx
0x280f819a: repz movsl %ds:(%esi),%es:(%edi) <-- Faulting instruction.
0x280f819c: movl 0x14(%esp,1),%ecx
0x280f81a0: andl $0x3,%ecx
0x280f81a3: repz movsb %ds:(%esi),%es:(%edi)
0x280f81a5: movl 0xc(%esp,1),%eax
0x280f81a9: popl %edi
0x280f81aa: popl %esi
0x280f81ab: ret
(kgdb) proc 373
(kgdb) bt
#0 mi_switch () at machine/globals.h:119
#1 0xc0163f91 in tsleep (ident=0xc030206c, priority=280,
wmesg=0xc02819e8 "select", timo=8640001) at ../../kern/kern_synch.c:467
#2 0xc016ed28 in select (p=0xd8dd5740, uap=0xd8e18edc)
at ../../kern/sys_generic.c:702
#3 0xc22393dc in ?? ()
#4 0xc22392bb in ?? ()
#5 0xc0260055 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 146812732, tf_esi = -1077944272, tf_ebp = 1342250056,
tf_isp = -656306220, tf_ebx = 1342250064, tf_edx = 1342250600,
tf_ecx = 148557768, tf_eax = 82, tf_trapno = 12, tf_err = 2,
tf_eip = 143784734, tf_cs = 31, tf_eflags = 582, tf_esp = 1342250052,
tf_ss = 47}) at ../../i386/i386/trap.c:1126
#6 0xc024d7fc in Xint0x80_syscall ()
#7 0x891e5a4 in ?? ()
#8 0x891e7a8 in ?? ()
#9 0x891cd68 in ?? ()
#10 0x891cda7 in ?? ()
#11 0x891ce14 in ?? ()
(kgdb) frame 2
#2 0xc016ed28 in select (p=0xd8dd5740, uap=0xd8e18edc)
at ../../kern/sys_generic.c:702
702 error = tsleep((caddr_t)&selwait, PSOCK | PCATCH, "select", timo);
(kgdb) print /x *p
$2 = {p_procq = {tqe_next = 0xd65e9780, tqe_prev = 0xd65e8dc0}, p_list = {
le_next = 0xd8dd55a0, le_prev = 0xd8dd5268}, p_cred = 0xc2020ee0,
p_fd = 0xc2294400, p_stats = 0xd8e17b78, p_limit = 0xc2297f00,
I know this isn't the right place to ask this, but...
...there are so many excessively bright and experienced minds on this list I can't imagine a _better_ place to ask it. My ISP (for whom I consult from time to time) is looking into Layer 4 Gigabit Ethernet; he needs some idea of the quality of various switches out there. If anyone here has recommendations or experiences with such switches, please email me directly (off-list). I would be, well, not _eternally_ in your debt, but I'll stand you a drink at BSDCon. Oh, he's looking into this because, quite unexpectedly, he has become something of a miniature MAE down here in Marina Del Rey. He needs gigabit just to keep up with the traffic. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://store.exit.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATAPI DVDwriters (not) to buy?
Wilko Bulte wrote: > Any experiences with a NEC ND-2510 ? Good/bad? I just bought one of these wrapped in an IDE<->USB/Firewire interface. I haven't tried the dual-layer disks yet (none lying around), but it appears to work just fine with regular DVD+R. The only gotcha is that USB is really too slow; I'll be connecting it via firewire shortly. Otherwise, no problems so far. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS
David Schultz wrote: > On Thu, Sep 16, 2004, Frank Knobbe wrote: > > On Thu, 2004-09-16 at 11:20, Bruce M Simpson wrote: > > > On Thu, Sep 16, 2004 at 11:12:16AM -0400, Kevin A. Pieckiel wrote: > > > > Where on earth would you find a disk system that can store 2^64 bytes of > > > > data or larger, anyway? > > > You can bet that somebody, somewhere, needs this right now. And someone > > > will definitely need it in the next 5-10 years. > > Naahh... there is No Such Application for it. ;) > Actually, there are a number of parties---banks, governments, > geneticists, and Internet search engines, for instance---who > never seem to have enough storage. Not to mention the folks to whom Frank was (very obliquely) referring. This whole argument just seems silly to me. So what if 128 bits seems large? Thirty years ago it would have seemed utterly ludicrous that an individual could possibly ever use even a few gigabytes of storage, but in this room I have .75 terabyte online. A zetabyte may seem like a lot now, but in thirty years? Who knows? I think that the one thing we can say is that there's pretty much zero chance that we can predict what the future will bring, "number of particles in the observable universe" notwithstanding. Personally, I think that an apparently infinite address space is a _good_ thing. At least we won't run out soon, right? :-) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Amazing.
I just want to drop a line to you folks (and to Bill Paul in particular) to express my appreciation for your work. I received my new laptop today after my old one finally succumbed to a combination of old age and ancient coffee spills. I installed 5.3-BETA6 on it immediately, no trouble, it knew about the Broadcom NIC out of the box and I did a quick check to learn how to set up ndis so I could use the Dell (actually Broadcom) wireless NIC as well. Built ndis, converted the Windows driver, built if_ndis, installed it, loaded it, configured the interface, ran dhclient and I'm using it as I type this. Took maybe an hour, including burning the driver and /usr/src on a DVD to carry into the living room. I was so impressed that I just had to write and say so. Kudos to you guys. You do good work. After having had to deal with the insides of Linux for the last year, it's a pleasure to use a system that is built with such professionalism. Thanks! -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: process checkpoint restore facility now in DragonFly BSD
Peter Kieser wrote: [ Charset ISO-8859-1 unsupported, converting... ] > I have no problem with bringing up the discussion of process > checkpointing on FreeBSD, what I _DO_ have a problem with is all this > cruft about DF on the list all the time. We keep getting the, "DragonFly > does it this way" or "DragonFly has this and we don't" on the > freebsd-hackers mailing list, and I'm pretty sure I'm not the only one > annoyed about it. > > Again, I have no problem with bringing up the process checkpointing, I > have a problem with people saying "DragonFly has this" _all_ the time; > if I wanted to hear about DF's development path I would be subscribed to > their mailing lists. I, on the other hand, think the shed should be painted pink. (And that discussion of DF on -hackers is at least as welcome as discussion of discussion of DF on -hackers.) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel documentation and specification
klowd9 - wrote: > >Kirk's book, ``The Design and Implementation of the FreeBSD > >Operating System'' probably contains the answers to basic > >questions about scheduling and IPC. > I considered purchasing that book, which is very very good imo, but a bit > overpriced at $60.. Um, well, actually for a reference work, that's a reasonable price. You might be able to pick up a copy of the 4.4BSD demon book used, I guess. > Any other resources about kernel development, and to whom may i speak with > to help me get started.. If you're really serious, buy the book. Buy an intro Operating Systems book as well, Andrew Tannenbaum's is good but there are others. Grab the FreeBSD source and start reading. I started out in mainframes but when I decided I wanted to do Unix kernel programming, I took a UCLA Extension course, I bought the books that were available at the time (some fifteen years ago, now, ghods how time flies) and when it was finally available I got the 386bsd source, bought a 486 system, installed it, and started mucking about. I was fortunate enough to have access to some SVR4 experts around then, as well. But all this was _after_ six years of college and five or six years of a Real Job doing operating systems work. These days the resources are ridiculously plentiful. There are online resources galore, from OS class syllabi to a number of varieties of open-source Unix. As well as many more people who know something about it and are willing to answer reasonable, intelligent questions. But don't expect anyone to hold your hand and _don't_ expect anyone to do the work for you. If you really want to learn this stuff, you will have to invest a _lot_ of time and at least _some_ money. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Console ASCII interpretation
alexander wrote: > You're right. The code I'm using is wrong when it is being executed > under the console. However the fact that Eterm and xterm do what I > want to do with my app show that I'm not the only one who needs a > NOP ascii value. Both render the NUL ascii code as NOP. Since both > terms are much newer than the console this indicates that they > reflect the recent changes in software development much better. I wouldn't bet that the xterm code is newer than the console code. Warner's point, that you apparently keep missing, is that, the ancient docs notwithstanding, there _is_ no hard-and-fast standard regarding how ASCII control codes are rendered. The closest thing to a "standard" there concerns BEL, HT, ESC and _possibly_ BS and NL. Everything else is pretty much up for grabs, and this quite definitely _includes_ NUL. Relying on a particular rendering of any ASCII control character across all output devices is the Wrong Thing To Do. > Keeping code simply because of historic reasons doesn't seem too obvious > to me. There are a lot if ways to let the user decide whether he > prefers historic code over new code. Hence all the COMPAT options > in the kernel. Perhaps, but this doesn't _involve_ code. This has to do with the ASCII character set and the standards, or lack thereof, that govern rendering those characters. > But it's obvious, that it would be much easier if I change my code to > only display that many bytes as I really want to be displayed. Not "much easier." "Correct." The fact that your code wrote three NULs to the console in the first place meant that your code, not the console, was broken. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
UFS2 recovery tool?
Due to a series of circumstances involving a RAID controller and an unclear user interface and an unfortunate use of "fsck -y", I managed to hammer a couple of very large file systems. (Fortunately I had a very recent copy of /home backed up elsewhere, or I wouldn't be sending this email.) While I could live without the data on those file systems if I absolutely had to, I know much of the data is recoverable with the right tools. In fact I found a whole intact subtree using fsdb. Unfortunately the root directory was wiped. While I can recover the inode with fsdb, it doesn't allow me to allocate a new (free) block for the directory contents. What I need is either a way to set up the root directory so I can link the subtrees that I find to it, or, alternatively, something like ffsrecov that will just pull the subtree off the dead filesystem directly, writing it to a _live_ filesystem. Unfortunately, ffsrecov hasn't yet been updated to support UFS2. If I have to, I'll write the code myself, but I'm hoping here that someone else has done so already. (At the moment it's hard for me to find the time for such relatively complex development that isn't directly work-related.) So, has anyone done this? If someone even has code lying around that understands UFS2 and can create directories and allocate blocks, even if it's not suitable for inclusion in ports, that would be wonderful. Drop me email with a pointer to said code. Alternatively, if you have (detailed, low-level) advice as to how to write the code, feel free to chime in. (Please, though, don't tell me to look at fsck_ffs, fsdb and sys/ffs/*; that I know already and it will be where I start if I end up writing this all myself.) So here's hoping... -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d cleanup
On Mon, 1 Aug 2005 13:29:00 -0500 (CDT)
[EMAIL PROTECTED] wrote:
> Well I certainly respect the opinions, but respectfully when has the use
> of && and || become obfuscation? Secondly, the use of shell style blocks
> of code is similar to the way they are done in C where curly-braces are
> used to enclose blocks of code. I honestly don't believe that it is
> because of people who look at C and shell code, it is probably more due to
> the foundation of all that existing shell code we read that does use IF
> statements instead of logical AND/OR.
That may be true for you, but I suspect that you don't write much (if any) C,
do you? When one is accustomed to seeing standard if/else with proper
indentation, the kind of thing you propose is indeed obfuscatory. This is one
of the reasons that Perl is nearly unmaintainable, and that is the name of the
game in one word: Maintainability.
Most of us aren't experts in /bin/{ba}sh syntax, nor will we be.
> What is the point of using a bulky
> IF statement for the evaluating simple true/false situation that the shell
> supports with && or ||?
The point is that it is more clear. It expresses exactly what it is: A
conditional statement in a programming language. The "&&" and "||" syntax
is just a shortcut to do the same thing. Like most shortcuts, it has its
place, but should be avoided when writing for a general audience.
Ghods know I'm as guilty as anyone of violating this rule, but I try...
--
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
On Mon, 1 Aug 2005 23:37:05 -0500 (CDT) [EMAIL PROTECTED] wrote: > I grep'ed the entire rc.d dir, and found that the same technique is used > elsewhere in accounting, and cleanvar. So I feel justified this time, > although please review, and thanks for the look. While I understand the > need to want a fork program to touch, or otherwise create an inode, I feel > forking for such an effort is weird and a bit over-engineered. Well, while one prefers a system to boot as quickly as reasonably possible, it's not like startup is particularly performance-critical. This is another place where I feel that clarity more than compensates for (very minor) slowness, particularly when coupled with the fact that the cost of a fork()/exec() is overwhelmed by the cost of cranking up some of the heavy-weight daemons. It seems to me that you're looking at things from a very "hacky" perspective. That is, it seems that you know a lot of shortcuts that add a bit of speed here and there and that's what you're trying to apply. (Please correct me if I'm wrong.) I would suggest that you look at the startup scripts somewhat differently, by asking yourself what is _broken_ there. I've seen at least a couple of suggestions along this line in reply to you. The mkdir usage isn't really broken, it seems to me. While I'm by no stretch of the imagination an expert regarding the rc scripts (they work and I ignore them), there are others around here that are, and they can, I am certain, give you some relevant, useful and very challenging suggestions. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] rc.d/tmp (silly mkdir usage)
On Tue, 2 Aug 2005 11:47:19 -0500 (CDT) [EMAIL PROTECTED] wrote: > "When all you've got is a hammer, everything looks like a nail." Sorry, maybe it didn't have to be said. I tried, though, I did. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bluetooth GPS for timekeeping?
On Tue, 2005-08-09 at 14:51 -0400, David Gilbert wrote: > But ... since there are long patches of time where I'm not mobile, I > was wondering if anyone had looked at using a Bluetooth GPS for > timekeeping. Has anyone also ever had an ntp server sometimes use a > GPS and othertimes use other servers ... depending on the availability > of the GPS? The former would depend strongly on the characteristics of the Bluetooth protocols, at least when it comes to accuracy. Keeping time to the half-second or so would be pretty easy, I would guess. The latter is the way it already works. Just configure other peers in your ntp.conf along with your GPS, viz: pps /dev/pps0 assert hardpps server 127.127.41.0 prefer # GPSClock fudge 127.127.41.0 stratum 0 fudge 127.127.41.0 time1 -1.0 peer 127.127.22.0 # PPS refclock fudge 127.127.22.0 stratum 0 flag3 1 # name it as a good clock peer 128.9.176.30 # timekeeper.isi.edu peer 164.67.62.194 # tick.ucla.edu peer 63.149.208.50 # nist1.datum.com peer 192.43.244.18 # time.nist.gov peer 206.223.0.15 # tick.exit.com That's the configuration for tock.exit.com. It uses the GPSClock if it's available, otherwise it falls back to the best of the other tickers. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bluetooth GPS for timekeeping?
On Tue, 2005-08-09 at 15:19 -0400, David Gilbert wrote: > >>>>> "Frank" == Frank Mayhar <[EMAIL PROTECTED]> writes: > > Frank> On Tue, 2005-08-09 at 14:51 -0400, David Gilbert wrote: > >> But ... since there are long patches of time where I'm not mobile, > >> I was wondering if anyone had looked at using a Bluetooth GPS for > >> timekeeping. Has anyone also ever had an ntp server sometimes use > >> a GPS and othertimes use other servers ... depending on the > >> availability of the GPS? > > Frank> The former would depend strongly on the characteristics of the > Frank> Bluetooth protocols, at least when it comes to accuracy. > Frank> Keeping time to the half-second or so would be pretty easy, I > Frank> would guess. > > Frank> The latter is the way it already works. Just configure other > Frank> peers in your ntp.conf along with your GPS, viz: > > How might you determine the accuracy of the GPS ... or the > "characteristics of the Bluetooth protocols" ? First learn about the way Bluetooth works. Pay attention to the various delays that are built into the protocol and that might be forced by transmission and reception conditions. > The GPS docs "say" that the GPS chipset keep time to within 100ns. > However (and I assume this is to save power) they also say that the > position indication is only sent once per second. The way this accuracy is typically transmitting outside the GPS unit itself is via a (usually logic-level) pulse-per-second signal. As it happens, a lot of the older GPS units that do this have a 5V PPS, which is enough to get it over the 3V RS232 threshold so it can be seen as CD. (For those with a PPS of 3.3V or lower, you have to use another method; PHK has a good mechanism on his website, using a Soekris box.) While the RS232 hardware is pretty sloppy, it is good enough to get within a few microseconds of the real time; right now tock thinks he's within about nine us of UTC and tick agrees to within +/- 2us. Tick uses a Motorola Oncore (instead of the GPSClock) but also gets the PPS via the RS232 CD signal and he thinks he's within about a microsecond of UTC. Since it's wired, the PPS signal is just degraded by propagation and by the accuracy of the receiving system. I'm no RF expert but I'll bet that getting high accuracy via Bluetooth would be problematic. On the other hand, accuracy to within milliseconds should be doable and to within hundreds of ms easy, since that's what the position indication string gives you. > In my case, the Bluetooth GPS would be talking to a Bluetooth dongle > hanging directly out a port of the server in question. Well, you wouldn't want to run a stratum 0 NTP server on this, but it's probably plenty good enough for a human being. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Oddity in libufs.
I've been using libufs as the I/O mechanism for my (heavy) modification
of sysutils/ffsrecov. It's working to my needs and now I'm poking at
other bits and pieces to maybe get it suitable for release into the
wild. I just looked at cgread() to see what it does and noticed that
there seems to be a redundant line:
.
.
if (c >= fs->fs_ncg) {
return (0);
}
ccg = fsbtodb(fs, cgtod(fs, c)) * disk->d_bsize;
if (bread(disk, fsbtodb(fs, cgtod(fs, c)),
disk->d_cgunion.d_buf,
.
.
That assignment up there looks redundant, as ccg is never used. I
suspect that it's a relic of an old lseek()/read() pair that's long
gone.
--
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Oddity in libufs.
On Sun, 2005-09-25 at 14:00 +0300, Giorgos Keramidas wrote: > On 2005-09-24 20:26, Frank Mayhar <[EMAIL PROTECTED]> wrote: > > That assignment up there looks redundant, as ccg is never used. I > > suspect that it's a relic of an old lseek()/read() pair that's long > > gone. > It's probably easy to verify that without this assignment 'ccg' is an > unused var: Um, yeah. I was pointing it out mostly so that a committer could check it out and perhaps remove the line in question... -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Oddity in libufs.
On Sun, 2005-09-25 at 21:23 -0700, John-Mark Gurney wrote: > Frank Mayhar wrote this message on Sat, Sep 24, 2005 at 20:26 -0700: > > I've been using libufs as the I/O mechanism for my (heavy) modification > > of sysutils/ffsrecov. It's working to my needs and now I'm poking at > > Well, I've recently rewrote ffsrecov in python, and have put up a > preliminary copy up at: > http://people.freebsd.org/~jmg/ffsrecov/ Sigh. Of _course_ you have. Where were you in June when I was begging for this? (Er, and, why python, of all things?) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Very weird NFS-related hang in 6-beta5.
I mount my /usr/ports, /usr/src, et al from an NFS server. Everything seems to work fine except on one system where I've been seeing repeated hangs. Of course the system in question is my main desktop one, sigh. At first I was using gigabit Ethernet (Intel Pro/1000, 82545GM chipset) but the interface kept wedging hard, also on this system (and _not_ on the server, just on this one). I upgrading the system to 6.0-beta5 to see if the interface hangs went away. (I upgraded by NFS-mounting /usr/src over my parallel 100BaseTX network rather than the Gigabit network.) The upgrade worked fine but the hangs didn't disappear. I planned to swap out the gigabit card to see if it was the hardware that was the problem, but in the interim (not having a spare card lying around) I decided to do a complete portupgrade using the 100BaseTX network. This is where it gets weird. Because of all the hangs I've run into, at some point I made all the NFS mounts soft mounts. I've been watching these port builds, and from time to time, with no obvious pattern that can discern, NFS hangs. The server seems perfectly healthy and in fact the _interface_ seems healthy, but the particular I/O in question just hangs until it eventually times out due to the soft-mount. After it finally times out, things pick up and keep going again. NFS works fine for a while, then it hangs again. I captured one of the hangs; this is from the client machine: 16:17:53.642822 IP realtime.exit.com.560259720 > jill.exit.com.nfs: 132 read fh 1070,983185/1114384 8192 bytes @ 1925120 16:17:53.643541 IP jill.exit.com.nfs > realtime.exit.com.560259720: reply ok 1472 read 16:18:11.679433 IP realtime.exit.com.560259720 > jill.exit.com.nfs: 132 read fh 1070,983185/1114384 8192 bytes @ 1925120 16:18:11.680142 IP jill.exit.com.nfs > realtime.exit.com.560259720: reply ok 1472 read So the server gets the read and replies, but the client apparently never sees the reply (despite the fact that it is coming in on the interface and gets picked up by tcpdump). I've attached the dmesg from the client, if it helps, but I doubt it will. I can't imagine that this is hardware, although I guess it _might_ be. It's just very weird. Any hints as to cause or further steps I can take to diagnose it would be appreciated. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
"panic: initiate_write_inodeblock_ufs2: already started" on 6.0-RC1 with Intel SRCU42L RAID.
I ran into this panic this evening; PR entered as kern/87861. The filesystem that gets this is on an Intel SRCU42L RAID5 array and that seems to be the important characteristic. This also happens in 5.4-stable, so it's not something special about 6.0. I can reproduce this at will so it will be easy for me to help diagnose it. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [FreeBSD-Announce] New Logo
On Mon, 2005-10-31 at 22:47 +0900, Jun Kuriyama wrote: > With our new logo, we'll be able to show our own identity on the 'net, > and this will make our marketing efforts much easier. We'll write a > guideline page which gives usage rules and usable (vector format) logo > data under the same BSD license as the rest of FreeBSD. Man, I _so_ hope this is a joke... -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic in nfs_putpages() on 6-stable.
I've run into this panic a couple of times over the last few days, while trying to rebuild ports using an NFS-mounted /usr/ports filesystem. It happened again today and this time I had time to look at the dump. The problem is a null pointer dereference in nfs_putpages(), when it tries to look at np->n_size. It turns out that v_data is NULL on entry to this routine. Looking at the stack I see why: #6 0xc0674e4a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05eb030 in nfs_putpages (ap=0xe81c6a14) at /usr/src/sys/nfsclient/nfs_bio.c:301 #8 0xc0691148 in VOP_PUTPAGES_APV (vop=0x1000, a=0xe81c6a14) at vnode_if.c:2164 #9 0xc064fd8e in vnode_pager_putpages (object=0xcafaa840, m=0x1000, count=0x1000, sync=0x5, rtvals=0x1000) at vnode_if.h:1119 During symbol reading, Attribute value is not a constant (DW_FORM_ref4). #10 0xc064b99e in vm_pageout_flush (mc=0xe81c6ab0, count=0x1, flags=0x5) at vm_pager.h:147 #11 0xc0647d0c in vm_object_page_collect_flush (object=0xcafaa840, p=0xc19e5218, curgeneration=0x0, pagerflags=0x5) at /usr/src/sys/vm/vm_object.c:950 #12 0xc0647800 in vm_object_page_clean (object=0xcafaa840, start=0x0, end=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_object.c:753 #13 0xc0647525 in vm_object_terminate (object=0xcafaa840) at /usr/src/sys/vm/vm_object.c:608 #14 0xc064e5ad in vnode_destroy_vobject (vp=0xcb58c110) at /usr/src/sys/vm/vnode_pager.c:166 #15 0xc05ee075 in nfs_reclaim (ap=0x1000) at /usr/src/sys/nfsclient/nfs_node.c:247 #16 0xc069095e in VOP_RECLAIM_APV (vop=0x1000, a=0xe81c6c90) at vnode_if.c:1589 #17 0xc0587aa5 in vgonel (vp=0xcb58c110) at vnode_if.h:818 #18 0xc0584ac2 in vlrureclaim (mp=0xc9b2e400) at /usr/src/sys/kern/vfs_subr.c:612 #19 0xc0584e8b in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:725 #20 0xc052034c in fork_exit (callout=0xc0584d00 , arg=0x0, frame=0xe81c6d38) at /usr/src/sys/kern/kern_fork.c:789 #21 0xc0674eac in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 In nfs_reclaim(), just before he calls vnode_destroy_vobject(), he zfrees and clears vp->v_data. When, down in the guts of vm_object.c, he tries to flush the associated pages, v_data is already NULL so he goes boom. Now, why does he do the zfree/clear before vnode_destroy_vobject()? Is he assuming that there are no pages associated with this vnode that need to be flushed? Should there be? I looked at some other file systems and they do the same thing. The obvious fix is to move the zfree/clear to after the vnode_destroy_vobject() but if there should be no pages that need to be flushed on the vnode at this point, that would just hide the problem. I can keep looking at the code to answer my question but I thought I would ask here first, in case there's someone who knows the answer right away. Thanks. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in nfs_putpages() on 6-stable, more info.
A bit more data and another question. On Sun, 2006-01-15 at 12:40 -0800, Frank Mayhar wrote: > In nfs_reclaim(), just before he calls vnode_destroy_vobject(), he > zfrees and clears vp->v_data. When, down in the guts of vm_object.c, he > tries to flush the associated pages, v_data is already NULL so he goes > boom. > > Now, why does he do the zfree/clear before vnode_destroy_vobject()? Is > he assuming that there are no pages associated with this vnode that need > to be flushed? Should there be? I looked at some other file systems and > they do the same thing. The obvious fix is to move the zfree/clear to > after the vnode_destroy_vobject() but if there should be no pages that > need to be flushed on the vnode at this point, that would just hide the > problem. Looking further down, at vlrureclaim(), I see that the commentary for vlrureclaim() specifically says that a a flushed vnode may still have backing store, so it appears that yes, there may be pages associated with the vnode when he calls vgonel(). Between vgonel() and nfs_reclaim() there's just VOP stuff, so the flushing has to be done lower down. The nfs_reclaim() routine itself just does some bookkeeping and then calls vnode_destroy_vobject(). That routine can push pages out, which means that if the backing store is on NFS, nfs_putpages() can be called. But that routine will fault because he'll try to use v_data as an nfsnode. The reason for my confusion is that of the filesystems in the tree, the only one that doesn't zfree and clear v_data before calling vnode_destroy_vobject() is UFS. The commentary in ufs_reclaim() is clear, though: /* * Destroy the vm object and flush associated pages. */ vnode_destroy_vobject(vp); Then later he VI_LOCKS() and clears v_data. (And [indirectly] does the zfree only _after_ that, which is interesting but probably not important.) I'm going to go slightly out on a limb here and guess that the "flush associated pages" thing came in relatively recently and the other filesystems haven't caught up with it. This implies that the proper fix is to go through those other xxx_reclaim() routines and reorder the operations. That's easy enough to do, but I would like to make sure that my understanding of this (and my guess) is correct and that I'm not wasting my time. Thanks! -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in nfs_putpages() on 6-stable, more info.
On Sun, 2006-01-15 at 14:45 -0800, Frank Mayhar wrote: > That's easy enough to do, but I would like to make sure that my > understanding of this (and my guess) is correct and that I'm not wasting > my time. Sigh. Well, given the deafening silence I got in response to this, I went ahead and fixed it, or at least I hope it's the right fix. I've been running with it for over 24 hours now with no problems (and heavy NFS access), so it looks good. See http://www.freebsd.org/cgi/query-pr.cgi?pr=91879 for the patch. I went ahead and fixed all the filesystems I could find, since they all had nearly identical code. I trust that this will be committed, and subsequently MFC'd, relatively quickly. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: urgent, need to recover superblock!
On Wed, 2006-02-22 at 22:23 -0500, Dave wrote: > Some urgency on this issue!I've got a 10 gb ide drive that has > critical data on one of it's > partitions /dev/ad1e. This drive was originally gmirrored in > another box it worked fine, it was the master drive. Now i've > installed this drive as a slave in another 6.0 box, and now it > shows up as ad1 with the partition i want being ad1e. I did a mount it > worked fine. So i knew the drive was working, i then unmounted the > partition, and tried to dump it to another drive. This didn't work, dump got > an error about incorrect superblock. I then did a mount > -o ro /dev/ad1e /mnt and i'm getting an error "Incorrect > superblock" from mount. I then tried fsck /dev/ad1e and got the > same error msg. These partitions were formatted with ufs2 as their > filesystem. I then ran bsdlabel ad1 and got a printout of my label, > this showed up which gives me hope that this data can be retrieved. > An error i'm getting from bsdlabel says that the c: partition does not cover > the > entire disk and that may result in utilities not working correctly. Any > help appreciated. > Some urgency! My heavily-hacked version of ffsrecov (hacked to support UFS2 but not quite ready for general release) might help with this. Source is available at http://www.exit.com/Archives/FreeBSD/ffsrecov.tar.gz. If you make changes, please send them back to me and I'll try to incorporate them. One of these days I'll get around to making this thing suitable for ports. But not today. Hope it helps. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Zero Copy, FreeBSD and Linus Torvalds opinion
On Mon, 2006-05-01 at 00:09 +0300, Iantcho Vassilev wrote: > "incompetent idiots." quote > > What do you think about it? "It is better to remain silent and be thought a fool, than to speak, and remove all doubt." -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BSD in a rocket.
Andy Sporner wrote: > On 14-Feb-02 Josef Karthauser wrote: > > I need to put together a computer to install in a small J-class > > rocket for collecting telemetry and other data. I'd really love > > to run some kind of BSD on it and ideally land the data on a > > flash-card or such device. I'd really appreciate any recommendations > > for an inexpensive device or development board to use for the job. > As for hardware perhaps the Mini-biscuit PC from advantech. I > just looked at found one that uses a 486 DX-66 with up to 32 MB > EDD RAM one compactflash socket and ethernet (CPC-2245-3200). It > goes for about 280 Euro and the development board for another 190. You might also look at Soren Kristenson's net4501; it is a 486 DX100 equivalent (really an embedded 133 MHz AMD processor) with 64 MB ram, compact flash, compact PCI, three (!) ethernet, partial regular PCI, serial port (second serial is optional). All together US$192, quantity one. Check out his website, http://www.soekris.com/, for more information. I'm not associated with him, I'm just a happy customer. :-) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ServerWorks AGP support?
I recently acquired a Tyan S1867 motherboard, which uses the ServerWorks HE chipset. I have a Radeon 7500 video card and I want to be able to do direct rendering with XFree86 4.2. Unfortunately, the ServerWorks chipset doesn't appear to be supported in modules/agp.ko. So, is anyone working on adding such support? I see that the ServerWorks chipset is (or at least appears to be) supported in the Linux AGP code; if necessary I can extract the necessary information from that code to write a driver for FreeBSD, but it would be nice if someone had already done the work, since my time is more than full enough already. :-) Here's hoping . . . -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Minor weirdness in pci/agp_amd.c.
I'm working on writing a driver for the ServerWorks AGP support from the Linux driver (sans documentation, SIGH :-(). I've been using the various other drivers as models, particularly the AMD driver, since it seems to be closest in many ways to the ServerWorks architecture. Anyway, I've run into a minor oddity in agp_amd_alloc_gatt(), in pci/agp_amd.c. At lines 120-121: gatt->ag_pdir = vtophys((vm_offset_t) gatt->ag_vdir); gatt->ag_pdir = vtophys(gatt->ag_virtual); Looks like one or the other is redundant? Probably the first, I would guess, if the code actually works as it is. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Minor weirdness in pci/agp_amd.c.
Coleman Kane wrote: > -STABLE has been (as of late last week) brought up to speed as far as this > fix goes. The earlier driver (shipped with 4.5) had this little oddity in > it, but it was removed when the driver got re-written. It has been fixed, > so there really is no problem. Ah, yes, it's agp_amd.c in 4.5-stable. Late last week? That explains why I haven't seen the fix yet; I cvsup daily, but I haven't 'cvs update'd my source tree for a few days. Thanks. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Minor weirdness in pci/agp_amd.c.
Well, I updated my tree (4.5-stable again) and was going through agp_amd.c
to check out the changes, when another gotcha jumped out at me. At line
113 you allocate the ag_vdir, then bzero it:
/*
* Allocate the page directory.
*/
gatt->ag_vdir = malloc(AGP_PAGE_SIZE, M_AGP, M_NOWAIT);
bzero(gatt->ag_vdir, AGP_PAGE_SIZE);
if (!gatt->ag_vdir) {
Looks to me like if the malloc fails the bzero will trap, eh? The bzero()
should be after the "if (!gatt->ag_vdir)" test.
An extra set of eyes can always be useful, I guess. :-)
--
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: first parameter to select
Enache Adrian wrote: > IIRC, in Solaris select() isn't a system call, but a library call > emulated in userland on top of poll(2). > (I could be wrong, I never really used Solaris ). Dunno about Solaris but that's certainly true in Unixware. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Device driver advice needed.
I have become the owner of a Specialix I/O8+ PCI multiport serial card. I originally thought that FreeBSD had a driver for that card, but it turns out that the si(4) driver only supports the older SI/XIO and SX cards. Fortunately, Linux has an I/O8+ driver and I'm in contact with the author, Roger Wolff. While there isn't any documentation available for the I/O8+ itself, there is documentation for the CD1865 chipset it uses. Between that, the Linux source and Roger's apparent willingness to answer questions, I should be able to come up with a working driver without too terribly much effort. I'm targeting 4-stable, since that's the platform for which I need support. I had originally thought I would add the I/O8+ support to the existing si(4) driver, but I just learned that the I/O8+ is sufficiently different from the SX series that Roger wrote two different drivers for Linux. Now I'm strongly leaning toward writing a new driver, call it "sx(4)." For 4-stable, I'll need a new major to be allocated, although I understand that in 5.x devfs eliminates that requirement. Still, for the moment, I'm stuck with 4-stable. I also need some advice as to how to name the devices in /dev. The si(4) driver uses /dev/ttyA* and /dev/cuaA*; perusing MAKEDEV it appears that I might use /dev/ttyG* and /dev/cuaG*. Is there a convention I should use? Finally, I've also come across an SDK for the SX series, with documentation, that includes support for the newer SX+ card. I don't have one of those and therefore can't test the code, but it appears relatively easy to add the support for the newer card to the existing driver. If someone wants to pick it up I would be happy to hand it to them. Peter Wemm, who ported the si(4) driver from BSD/OS would be the logical choice, if he's interested. If I have time and am ambitious, I might add the support myself, but that's a pretty big "if." Suggestions and advice solicited. Theses cheerfully roundfiled. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB versus SMP and Epson printers.
Don Lewis wrote: > Unless someone snuck it in while I wasn't looking, our ulpt > implementation doesn't support reading data from the printer, so it's > not possible to check the ink levels. I've had to boot Linux in order > to do this. Hmm. Okay... Unfortunately, the straight printing didn't work, either. I tried the "check the ink levels" trick only after my test page never printed. I'm using CUPS, could this be a limitation of the ulpt driver? Should I be using another device? -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB versus SMP and Epson printers.
On Monday I received my brand-new Epson C82, a replacement for a 900N with a dead print head. I had already configured CUPS so I imagined that I would just hook it up with USB and everything would be happy. Well, that's not how it turned out. I tried two different machines, both with Tyan dual-CPU motherboards. One is a Thunder 2500 (S1867) with dual PIII 866, my gateway/fax/server box and the one I preferred. The other is my main desktop box, a Tiger MPX (2466N-4M) with dual Athlon MP 1900+. Both displayed essentially the same problem, although the Tiger MPX seemed to come a little bit closer to working than the Thunder 2500. Basically, although usbdevs would show the device, when I tried to do, say, an 'escputil -s -r /dev/ulpt0' (to show the ink levels), the process would seem to send something to the printer (I say "seem to" because I saw no evidence of it on the printer side), then sit in the USB code forever, timing out and looping. On the Tiger MPX I did see the "port disabled" message when I connected the printer (although nothing when I disconnected it). The Thunder 2500 didn't do that much. I've attached the dmesg from the Thunder 2500; I don't have one handy for the MPX. If anyone can give me any hints about this, I would be very grateful. Thanks. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ 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 4.8-STABLE #1: Mon Aug 4 14:54:45 PDT 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/TINKER Timecounter "i8254" frequency 1193182 Hz CPU: Intel Pentium III (868.64-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff real memory = 2147483648 (2097152K bytes) avail memory = 2087452672 (2038528K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor motherboard: 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: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000 Preloaded elf kernel "kernel" at 0xc0406000. Pentium Pro MTRR support enabled Using $PIR table, 12 entries at 0xc00fdf00 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard IOAPIC #1 intpin 13 -> irq 2 IOAPIC #1 intpin 12 -> irq 16 IOAPIC #1 intpin 0 -> irq 17 IOAPIC #1 intpin 2 -> irq 18 IOAPIC #1 intpin 4 -> irq 19 IOAPIC #1 intpin 7 -> irq 20 pci0: on pcib0 pci0: (vendor=0x1166, dev=0x0005) at 0.1 sym0: <896> port 0xf800-0xf8ff mem 0xfeafe000-0xfeaf,0xfeaf8c00-0xfeaf8fff irq 2 at device 1.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-40, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym1: <896> port 0xf400-0xf4ff mem 0xfeafc000-0xfeafdfff,0xfeaf8800-0xfeaf8bff irq 16 at device 1.1 on pci0 sym1: Symbios NVRAM, ID 7, Fast-40, SE, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. pci0: (vendor=0x11cb, dev=0x2000) at 3.0 irq 17 tl0: port 0xfc90-0xfc9f mem 0xfeafbc00-0xfeafbc0f irq 18 at device 4.0 on pci0 tl0: Ethernet address: 00:08:c7:b1:93:c3 miibus0: on tl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto tlphy0: on miibus0 tlphy0: 10base2/BNC, 10base5/AUI fxp0: port 0xfca0-0xfcbf mem 0xfe80-0xfe8f,0xfceff000-0xfcef irq 19 at device 5.0 on pci0 fxp0: Ethernet address 00:90:27:1c:5e:6a inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: port 0xfcc0-0xfcff mem 0xfe90-0xfe9f,0xfeaf7000-0xfeaf7fff irq 20 at device 7.0 on pci0 fxp1: Ethernet address 00:e0:81:01:ff:6c inphy1: on miibus2 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 15.0 on pci0 isa0: on isab0 pci0: at 15.1 ohci0: mem 0xfeaf6000-0xfeaf6fff irq 17 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib1: on motherboard IOAPIC #1 intpin 1 -> irq 21 pci1: on pcib1 pci1: at 0.0 irq 21 pcib2: on motherboard IOAPIC #1 intpin 8 -> irq 22 IOAPIC #1 intpin 10 -> irq 23 pci2: on pcib2 tl1: port 0xf0b0-0xf0bf mem 0xefeffc00-0xefeffc0f irq 22 at device 1.0 on pci2 tl1: Ethernet address: 00:08:c7:28:52:93 miibus3: on tl1 nsphy1: on miibus3 nsphy1: 10b
Re: Dynamic reads without locking.
I read the thread hoping to see a succint response to this and so far I don't see it. Here goes... Pawel Jakub Dawidek wrote: > I'm wondering... > Jeffrey Hsu was talking about this at BSDCon03. > There is no need to lock data when we just made simple read, for example: > > mtx_lock(&foo_mtx); > foo = 5; > mtx_unlock(&foo_mtx); > but only: > bar = foo; > > IMHO this is quite dangerous. > Let's see: > > thread1 thread2 > mtx_lock(&foo_mtx); > foo = data_from_user; > bar = foo; > foo &= MASK; > mtx_unlock(&foo_mtx); > > In this case we have really dangerous race if data from user are > safe only when we made 'and' operation on them. > OR of course we can just store wrong value in 'bar' and this could > be case of different problems. There are at least two different things going on here. First off, in general an unlocked read is generally only "safe" if the writes themselves are atomic. And I mean atomic _without_ using locks. So the locked update of "foo" up there should really be: thread1 thread2 foo = (data_from_user & MASK) bar = foo So you see there is a simple race here. As long as the write to foo in thread1 is atomic by nature (which really depends on the architecture, but that's a different thread), either thread2 will end up with a stale value or it will end up with the new value. Either way, it will be a _valid_ value. > So I'm not sure now if I understand everything well. We can't just say > 'We never split such writes. We always do: foo = (data_from_user & MASK)', > because author of some 3rd party kernel module will be sure that when > he locks writes to some variable this operation is safe and he could > split such writes and in kernel could be dynamic read without lock. The other thing is that the unlocked reads about which I assume Jeffrey Hsu was speaking can only be used in very specific cases, where one has control over both the write and the read. If you have to handle unmodified third-party modules, you have no choice but to do locking, for the reason you indicate. On the other hand, you can indeed make such a rule as you describe: For this global datum, we always either write or read it in a single operation, we never do a write/read/modify/write. Hey, if it's your kernel, you can make the rules you want to make! But it's better to not allow third-party modules to use those global data. In fact, it could be that the compiler may optimize your example into a single operation. The way it is written, it's just bad coding practice, at least in this case. I don't really see that there's much about which to disagree, here. Jeffrey is right in at least certain well-defined cases. In the general case, though, you have to use some kind of explicit serialization. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Specialix I/O8+ driver available for abuse.
I've finally finished that driver I've been working on, for the Specialix I/O8+ multiport serial card. I've dropped a source tarball into http://www.exit.com/Archives/FreeBSD/ It has a manpage as well as a file "sx-kern-patches" which patches conf/files and conf/options to allow you to build the thing. It has not yet been really heavily tested (although it works just fine in my limited use of it). Check the manpage for configuration info. If you run into any bugs, let me know. Note that this driver is for -stable _only_. When I start running 5.x I'll port it, but not until then. Enjoy. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Security through obscurity? (and /etc/defaults/rc.conf changes)
Jochem Kossen wrote:
> Because things evolve? :)
You say "evolve." I say "get broken."
> > How do I know which man page to read?
> You start X with startx, seems obvious to me. The disabling of tcp
> connections only applies to startx
It's not obvious when one has been starting X with the same command for
years and it has never before changed. Gee, seems to seriously violate
POLA, eh?
> OK, then i suggest we mention it in the handbook, the security policy
> document, the manpage AND the release notes :)
Just don't do it in the first place. If you must have this, make a _new_
command ("secure-startx," perhaps) and point to it in the release notes.
> For the simple reason I don't like useless open ports on my system. I
> don't use it, _most_ other people don't use it, so i sent in a patch.
Yeah, but unless one is installing a fresh system, one shouldn't care so
much. And, by the way, how do you define "useless?" To me, having X
listening for TCP connections is far from useless.
> Of course, it was only discussed on the ports@ mailinglist, but it
> didn't seem like such a big deal to me or apparently the others...
This is another case of changing the default in such a way as to violate
POLA.
I've given this some thought, particularly with respect to the rc.conf
changes. My opinion is that, while this kind of thing is a good idea
for from-scratch installs (the kind a person new to FreeBSD might be
doing), making these changes to a running system is a Really Bad Idea.
That means that if you _must_ change the defaults, add overrides at
the same time to maintain the old default behavior. Then document the
hell out of the new defaults. One shouldn't have to read ancient
mail archives or pore over cvs logs to figure out what happened and
why.
Hey, I'm a kernel programmer (I work on BSD/OS as it happens). I know
what it's like to be stuck with obsolete defaults. The fact of the
matter is, though, that if I change a default and that upsets our
customers, we potentially lose revenue and I potentially lose my job.
This gives me real incentive to get it right, and that means not pulling
the rug out from under the end user.
IMHO, this was botched. Sorry, David, I calls 'em as I see 'em.
--
Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY supportconsidered harmful?)
Jochem Kossen wrote: > It does work. But i think you mean the tcp connections. > Does that mean you vote for enabling _all_ services? They don't work out > of the box as well... This is ridiculous. You know as well as I do that that's _not_ what Greg means. Just don't change stuff out from under the users. > > And don't tell me that X11 is an add-on and luxury. > I agree, but the tcp connections IS an add-on luxury imho Wrong. It's the way it works. > > We are living in the 21st century. > That's right, the century of virii, DoS attacks, worms, and > scriptkiddiots. Then fix the security holes at your end and leave the rest of to fix them the way _we_ want to. Don't impose your "fix" on the rest of us by fiat. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY supportconsidered harmful?)
Robert, it's really, really simple. For new installs, install the new, more secure behavior. Be sure to loudly document this behavior so that those of us who expect the _old_ behavior don't get bitten by the change. And don't change the old behavior in upgrades of existing systems. As I said in my other email, if you _must_ change the defaults, add overrides so the behavior doesn't change. And by "add overrides" I mean something like an /etc/rc.conf.override file that gets pulled in after /etc/defaults/rc.conf but before /etc/rc.conf. (This says nothing about the necessity or desirability of the change itself, by the way. That's an entirely _different_ argument.) When you change defaults on a running system, you piss off a lot of users. Including me. :-) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Changing defaults versus increased security.
M. Warner Losh wrote: > : When you change defaults on a running system, you piss off a lot of users. > : Including me. :-) > When we fail to take reasonable steps to preclude intruders from > gaining access to your system, we'd likely piss you off more if you > knew about it :-(. Hey, I intentionally said nothing about the desirability of such a change. I just don't believe that changing the defaults of a running system is a good idea. Perhaps changing the defaults for newly-installed systems _is_ a good idea, about that I have no opinion, but when I do a mergemaster and something very basic stops working, it's not more secure, it's just broken. I don't object to more secure systems (far from it), I just object to sudden changes in systems I run. These systems have _already_ been secured against intrusion; like any administrator worth his salt, I've taken steps to secure the borders of my network(s). Inside my network, though, things are less secure because I know I can trust myself. It seems easy enough to create an /etc/rc.overrides script with a large "Danger Will Robinson" message to annoy a sysadmin into looking at it and containing the old defaults. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
More about security, X, rc.conf and changing defaults.
Terry Lambert wrote: > FWIW: I wouldn't object to a firewall rule that disallowed remote > TCP connections to the X server by default, if the firewall is > enabled. I think we already have this... Yep, I agree, and whether or not it's in the distributed rc.firewall, I have the ports blocked in my hand-tuned version. As to Stijn's remarks, he is putting up a strawman at best. If a person runs X, it should be their responsibility to make sure that it's secure. Just like if they ran Windows or any other software with potential security holes. X is plastered with warnings as it is, why do we need to cripple a function it supports? Stijn, if it "opens up a hole in your network," that's _your_ problem, not mine. There are many other ways to secure your network than by turning off tcp connections by default in the X server. Hey, I'm not objecting to adding the capability, I'm just objecting to the fact that it was imposed upon everyone else by fiat and (worse) without warning. And before people start saying again that this only affects a port and is irrelevant to the operating system itself, this is one symptom of what I see as a worsening problem. I agree with Warner that the former default should only be supported until the next major release, but that former default _should be supported_. Yeah, it's up to me as a sysadmin to notice this stuff and fix it, but how many people pay that much attention to the stuff in /etc/defaults when they are in the middle of upgrading a bread-and- butter system (to get it closer to the current -stable, so later improvements won't be so difficult to bring in) and are going as fast as they can? Much better, IMNSHO, to create the new /etc/rc.override (or whatever) script and let it bug the admin about the fact that the defaults have changed. And _not_ spring this sort of thing on the FreeBSD world unawares. Not all of us have time to pay attention to the mailing lists (or even _one_ of the mailing lists) to catch this sort of thing before it gets committed. Hey, I'm a software engineer for Wind River (with a fulltime job there), plus sole engineer and sysadmin for my own side business. I barely have time for _sleep_. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does FreeBSD have a problem with some AMD processors?
Morsal Rodbay wrote: > I recenetly bought an Athlon XP 1800+... and it turned out that it wouldnt > run XFree. Everything worked well besides X. Since a workstation without X > is useless I was forced to switch to WinXP and it's very stable so there is > nothing wrong with the hardware which means it's a FreeBSD issue. It's probably _not_ a FreeBSD issue. I'm running -stable on a dual AMD MP 1800+ system (Tyan 2466 motherboard), running XFree86 on a Radeon 8500 128MB card. No problems at all. And it screams. :-) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Numerous hard hangs on TWO different ASUS P4T-E w/P4 1.6G
I'm experiencing hangs as well. At first I thought it was the fxp0/sym driver thing, but I've since changed hardware almost completely and the hangs persis. I'm now strongly suspecting some kind of interrupt problem. For the record, I've attached my dmesg output. This is a dual AMD MP 1900+ (1.6 GHz) Tyan 2466N-4M system. 3Com xl0 ethernet, Adaptec 39160 and 3940 SCSI, Creative Soundblaster Live! audio, Radeon 8500 128MB video (XFree86 4.2). 2GB DDR memory. I see very common short-term hangs, a few seconds to less than a minute. The mouse and keyboard stop responding, X stops updating and everything just pauses, the whole system (including the network). It then starts back up, often dropping keyboard or mouse data. Once in a while (not sure how often, but at least every couple of days) it hangs solid and never comes back. Totally unresponsive. This invariably requires a hard reset. This is a busy system. Near-constant load on the network (some 40-100KB/s), lots of disk accesses. Seems worse when network and/or SCSI load is high. Dmesg output follows. If there's anything I can do to help diagnose this problem, please let me know... -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ Copyright (c) 1992-2002 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 4.6-RC #21: Thu May 23 15:24:24 PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/REALTIME Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(tm) MP 1900+ (1600.07-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc048<,AMIE,DSP,3DNow!> real memory = 2146959360 (2096640K bytes) config> q avail memory = 2086846464 (2037936K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc042a000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc042a09c. Preloaded elf module "umap.ko" at 0xc042a0ec. link_elf: symbol null_bypass undefined Pentium Pro MTRR support enabled Using $PIR table, 12 entries at 0xc00fdf00 apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 5.0 irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 chip1: at device 7.3 on pci0 ahc0: port 0x1000-0x10ff mem 0xc000-0xcfff irq 5 at device 9.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0x1400-0x14ff mem 0xc0001000-0xc0001fff irq 11 at device 9.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs pcib2: at device 16.0 on pci0 pci2: on pcib2 ohci0: mem 0xc020-0xc0200fff irq 10 at device 0.0 on pci2 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (unknown) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib3: at device 6.0 on pci2 pci3: on pcib3 ahc2: port 0x4000-0x40ff mem 0xc030-0xc0300fff irq 11 at device 4.0 on pci3 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs ahc3: port 0x4400-0x44ff mem 0xc0301000-0xc0301fff irq 10 at device 5.0 on pci3 aic7880: Ultra Wide Channel B, SCSI Id=7, 16/253 SCBs pcm0: port 0x3080-0x309f irq 10 at device 7.0 on pci2 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x3000-0x307f mem 0xc0201000-0xc020107f irq 10 at device 8.0 on pci2 xl0: Ethernet address: 00:e0:81:20:cc:de miibus0: on xl0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto orm0: at iomem 0xc-0xccfff,0xcd000-0xcd7ff,0xdc000-0xd on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <4 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: c
Re: Numerous hard hangs on TWO different ASUS P4T-E w/P4 1.6G
Lars Eggert wrote: > I've seen these, too, on a dual-P3 Dell Precision 420. Under high loads > (buildworld), I get the exact same short-time freezes that sometimes > recover, and sometimes lockup the machine solid. > > We have the same sound card (and network card), and in my case, not > playing audio during high loads solves the problem - are you using your > audio device at all when this happens? Nope. Well, sometimes, but not often. When I am, I get the "repeating the last sample" effect during the freeze, the same as if the sound card wasn't generating interrupts (or the system wasn't servicing those interrupts). This is one of the things that makes me suspect interrupt problems. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Numerous hard hangs on TWO different ASUS P4T-E w/P4 1.6G
Terry Lambert wrote: > If you have NTP enabled, you might try disabling that, as well. It > could be something unexpected in the timer code. Nope. Killed ntpd, still happenning... > Another alternative could be to force: > > kern.timecounter.method: 0 > kern.timecounter.hardware: i8254 This is actually the default for my system. I'm not seeing any stray interrupts, either: [73]~ >uptime 11:58AM up 15:41, 5 users, load averages: 2.89, 2.56, 2.36 [74]~ >vmstat -i interrupt total rate stray irq7 1 0 ahc0 irq5 295768 5 mux irq11 1499613 26 mux irq10 7155313126 fdc0 irq6 1 0 atkbd0 irq1 19380 0 psm0 irq12 630291 11 ppc0 irq7 1 0 clk irq0 5645002 99 Total15245370270 I am a tad suspicious of sharing interrupts with the SB Live card, though. I'm going to next disable the onboard IDE (thought I had already done that, sigh) and the parallel port to get a few irqs back and try to arrange for the sound card to use one of them. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
Kris Kennaway wrote: > Surely it's easier to just upgrade the apache port, instead of > recompiling your kernel and the entire OS. Not always. (I'm running an old version of Covalent Raven SSL and I'm loathe to upgrade. "If it works, don't fix it" and there are only so many hours in a day.) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
Kris Kennaway wrote: > On Thu, Jun 20, 2002 at 07:33:54PM -0700, Frank Mayhar wrote: > > Kris Kennaway wrote: > > > Surely it's easier to just upgrade the apache port, instead of > > > recompiling your kernel and the entire OS. > > Not always. (I'm running an old version of Covalent Raven SSL and I'm > > loathe to upgrade. "If it works, don't fix it" and there are only so > > many hours in a day.) > The exact same argument can be made for not upgrading the OS, which is > a much larger endeavour and can potentially screw things up much > worse. Yep. Which is why the only times I've upgraded the kernel on my production boxes have been when there is a critical fix that I _had_ to install, usually a security fix. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inuring FreeBSD to the apache bug without upgrading apache ?
Brandon D. Valentine wrote: > However, I would ask Frank if there's a particular reason he needs to > use Covalent Raven SSL. OpenSSL is free, works like gangbusters, and > comes with FreeBSD. I have a feeling he'd be much happier with it if > there's not some other reason he cannot move to it. As I mentioned, the two reasons are (1) it hasn't been broken (at least up to now) and (2) I haven't had time. These are colocated production boxes; I don't have easy physical access to them to fix things if they go seriously wrong, and having them be down for any length of time is a Bad Thing. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Good 802.11a card?
I'm looking into finally going wireless, and it seems that 802.11a is the way to go, faster and better than 802.11b. So is there a decent card that FreeBSD supports? All of the cards I've seen so far are Cardbus cards, which -stable doesn't yet support, AFAIK. Alternatively, what's the status of Cardbus support for -stable? -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Good 802.11a card?
M. Warner Losh wrote: > That's ok, since there's no 802.11a support in FreeBSD at the moment. > There might be a binary only driver in the future, but don't even > think about asking me about it because I'm not working on it and can't > say more in public or private. Hmm. No docs for the cards, I suppose. > : Alternatively, what's the status of Cardbus support for -stable? > None. There was some patches done for it a while ago, but that dried > up :-(. So I suppose that the only cardbus support is in -current? And that it's much too different to be ported to -stable? Sigh. I was afraid of this. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Upgrading from 2.2.8 to 3.2-stable...
Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a "make upgrade." My question is: What the hell am I doing wrong? I'm just doing a "make upgrade" on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar fr...@exit.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Upgrading from 2.2.8 to 3.2-stable...
Apologies if this appears twice. The first attempt didn't appear to work. Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a "make upgrade." My question is: What the hell am I doing wrong? I'm just doing a "make upgrade" on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar fr...@exit.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Another odd problem.
I have an old NE2000 ethernet card that's been running fine for years. I just upgraded to 3.2-stable, and now it regularly spits out the errors "ed0: remote transmit DMA failed to complete" and "ed: packets buffered, but transmitter idle". Did something change in the driver? Is my card dying? What gives? -- Frank Mayhar fr...@exit.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Keyboard problems w/3.2-stable.
I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems to be working okay, except the keyboard. It works fine under the BIOS, and during the bootstrap, but by the time it gets to the login prompt, it stops responding entirely. I've tried several different fixes (changing console drivers, cycling power on the system, and things like that), but nothing is working. It's bound to be something simple I'm missing; it worked fine under 2.2.8. I've enclosed the dmesg and config file as attachments. Any pointers would be greatly appreciated. -- Frank Mayhar fr...@exit.com Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Sun Aug 15 15:06:08 PDT 1999 fr...@realtime.exit.com:/usr/src/sys/compile/TINKER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 132632402 Hz CPU: Pentium/P54C (132.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf real memory = 67108864 (65536K bytes) avail memory = 62164992 (60708K bytes) Preloaded elf kernel "kernel" at 0xc02cd000. Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.7.0 vga0: rev 0x00 on pci0.9.0 tl0: rev 0x10 int a irq 12 on pci0.10.0 tl0: Ethernet address: 00:08:c7:28:52:93 tl0: autoneg complete, link status good (full-duplex, 100Mbps) ahc0: rev 0x00 int a irq 11 on pci0.12.0 ahc0: aic7870 Wide Channel A, SCSI Id=7, 16/255 SCBs Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <4 virtual consoles, flags=0x0> ed0 at 0x320-0x33f irq 10 on isa ed0: address 00:40:05:11:b2:70, type NE2000 (16 bit) atkbdc0 at 0x60-0x6f on motherboard fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 flags 0x10 on isa sio1: type 16550A ppc0 at 0x278 irq 7 on isa ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port Intel Pentium detected, installing workaround for F00F bug IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging limited to 100 packets/entry ccd0-15: Concatenated disk drivers Waiting 8 seconds for SCSI devices to settle changing root device to da0s1a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 6.756MB/s transfers (6.756MHz, offset 15) da1: 1170MB (2396970 512 byte sectors: 255H 63S/T 149C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 8.064MB/s transfers (8.064MHz, offset 8) da2: 1042MB (2134305 512 byte sectors: 255H 63S/T 132C) da3 at ahc0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 8.064MB/s transfers (8.064MHz, offset 15), Tagged Queueing Enabled da3: 1001MB (2051000 512 byte sectors: 64H 32S/T 1001C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 8.064MB/s transfers (8.064MHz, offset 15), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # http://www.FreeBSD.ORG/> # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.140 1998/12/27 13:55:47 sos Exp $ machine "i386" cpu "I586_CPU" ident TINKER maxusers128 #optionsMATH_EMULATE#Support for x87 emulation options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device options NFS #Network Filesystem options MFS #Memory File System options MSDOSFS #MSDOS Filesystem options "CD9660"#ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 options UCONSOLE#Allow users to grab the console options "NSWAPDEV=8" options COMPAT_LINUX options SYSVSHM options SYSVSEM options SYSVMSG op
Re: Keyboard problems w/3.2-stable.
frank wrote: > I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems > to be working okay, except the keyboard. It works fine under the BIOS, and > during the bootstrap, but by the time it gets to the login prompt, it stops > responding entirely. Well, duh. I found the problem, partly thanks to a response from -hackers. I had the line device atkbd0 at atkbdc? ... instead of device atkbd0 at isa? ... Hand the dunce cap over here. And my apologies for the various bounces. Going to the latest bind and sendmail is giving me fits. -- Frank Mayhar fr...@exit.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Keyboard problems w/3.2-stable.
frank wrote: > I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems > to be working okay, except the keyboard. It works fine under the BIOS, and > during the bootstrap, but by the time it gets to the login prompt, it stops > responding entirely. Well, duh. I found the problem, partly thanks to a response from -hackers. I had the line device atkbd0 at atkbdc? ... instead of device atkbd0 at isa? ... Hand the dunce cap over here. And my apologies for the various bounces. Going to the latest bind and sendmail is giving me fits. -- Frank Mayhar fr...@exit.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Deprecating ps(1)s -w switch
On Tue, 2009-08-25 at 08:48 -0700, Tim Kientzle wrote: > Jonathan McKeown wrote: > > On Tuesday 25 August 2009 15:44:47 Ed Schouten wrote: > >> * Brian Somers wrote: > >>> I recently closed bin/137647 and had second thoughts after Ivan (the > >>> originator) challenged my reason for closing it. > >>> > >>> The suggestion is that ps's -w switch is a strange artifact that can > >>> be safely deprecated. ps goes to great lengths to implement width > >>> limitations, and any time I've seen people not using -ww has either > >>> been a mistake or doesn't matter. > > The difference between "ps", "ps -w", and "ps -ww" is pretty > significant for Java, in particular. Java command lines > are typically enormous (thank you, CLASSPATH) which makes > "ps -ww" often more annoying than it's worth. > > I concur with another poster that the GNU ps approach for > supporting multiple argument styles deserves consideration. I realized that nobody asked me, but IMHO it ain't broke so don't fix it. I use -w and -ww a lot, and yes, I do distinguish them. Sometimes -w is enough; if it isn't, then I'll use -ww but otherwise I avoid it because it gives just too much output in many cases. -- Frank Mayhar fr...@exit.com http://www.exit.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Atheros AR9281 still not supported?
So I take it that the newer Atheros chipsets are still not supported in FreeBSD 8? I thought I saw a rumor a while ago that they would be but now I can't track it down and of course the BugBusting page shows this series as still unsupported. Unfortunately I'm having a problem with my formerly trusty ar5212 interface since I upgraded (hangs, can't reset, error "ath_chan_set: unable to reset channel 36 (5180 Mhz, flags 0x140), hal status 3") so I was hoping to use the builtin interface, but it appears that's out. Please correct me if I'm wrong. Thanks. -- Frank Mayhar fr...@exit.com http://www.exit.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
psm0: unable to allocate IRQ
Hi, guys. I'm trying to set up a new laptop and have run into a couple of problems. This one is the message in the subject line. I've managed to get X working but it can't talk to the mouse; after investigation and a verbose boot, this is why. I'm kind of stumped as to what steps to take; I've tried booting without acpi, same problem. Why would this happen? And better yet, how do I go about fixing it? Any help or suggestions would be greatly appreciated. Thanks. (And please CC replies to the list, email to this address is not quite 100% reliable at the moment.) Oh, the dmesg in question is available at https://docs.google.com/open?id=0B1d6rhpx_wBIeFJmNVJqVVQ1Xzg -- Frank Mayhar fr...@exit.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: psm0: unable to allocate IRQ
On Mon, 2012-12-31 at 23:11 -0800, Frank Mayhar wrote: > Hi, guys. I'm trying to set up a new laptop and have run into a couple > of problems. This one is the message in the subject line. I've managed > to get X working but it can't talk to the mouse; after investigation and > a verbose boot, this is why. I'm kind of stumped as to what steps to > take; I've tried booting without acpi, same problem. Why would this > happen? And better yet, how do I go about fixing it? > > Any help or suggestions would be greatly appreciated. Thanks. (And > please CC replies to the list, email to this address is not quite 100% > reliable at the moment.) > > Oh, the dmesg in question is available at >https://docs.google.com/open?id=0B1d6rhpx_wBIeFJmNVJqVVQ1Xzg Adding freebsd-mobile in case anyone there has encountered (and, hopefully, solved) this. -- Frank Mayhar fr...@exit.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: psm0: unable to allocate IRQ
On Wed, 2013-01-02 at 18:26 -0800, Frank Mayhar wrote: > On Mon, 2012-12-31 at 23:11 -0800, Frank Mayhar wrote: > > Hi, guys. I'm trying to set up a new laptop and have run into a couple > > of problems. This one is the message in the subject line. I've managed > > to get X working but it can't talk to the mouse; after investigation and > > a verbose boot, this is why. I'm kind of stumped as to what steps to > > take; I've tried booting without acpi, same problem. Why would this > > happen? And better yet, how do I go about fixing it? > > > > Any help or suggestions would be greatly appreciated. Thanks. (And > > please CC replies to the list, email to this address is not quite 100% > > reliable at the moment.) > > > > Oh, the dmesg in question is available at > >https://docs.google.com/open?id=0B1d6rhpx_wBIeFJmNVJqVVQ1Xzg > > Adding freebsd-mobile in case anyone there has encountered (and, > hopefully, solved) this. Sigh. I'm an idiot (again). I managed to lose the "device acpi" line from my config. Added it back, problem solved. Sorry for the noise. -- Frank Mayhar fr...@exit.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Upgrading from 2.2.8 to 3.2-stable...
Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a "make upgrade." My question is: What the hell am I doing wrong? I'm just doing a "make upgrade" on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Upgrading from 2.2.8 to 3.2-stable...
Apologies if this appears twice. The first attempt didn't appear to work. Well, I'm having problems upgrading a system from 2.2.8 to 3.2-stable. I checked the archives, and apparently others have run into this one as well. Unfortunately, I couldn't find a fix for it. The problem is when the upgrade procedure tries to build the elf version of libmytinfo. It generates an executable, mkcaplist, which it uses to generate the caplist.c file. This is an elf executable, which promptly coredumps when the makefile tries to run it. Now, I _know_ this library has been around for a while, and others have successfully done a "make upgrade." My question is: What the hell am I doing wrong? I'm just doing a "make upgrade" on a clean /usr/obj. It crashes when it gets to libmytinfo. That's it. Any help or pointers would be greatly appreciated. Thanks. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Another odd problem.
I have an old NE2000 ethernet card that's been running fine for years. I just upgraded to 3.2-stable, and now it regularly spits out the errors "ed0: remote transmit DMA failed to complete" and "ed: packets buffered, but transmitter idle". Did something change in the driver? Is my card dying? What gives? -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Keyboard problems w/3.2-stable.
I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems to be working okay, except the keyboard. It works fine under the BIOS, and during the bootstrap, but by the time it gets to the login prompt, it stops responding entirely. I've tried several different fixes (changing console drivers, cycling power on the system, and things like that), but nothing is working. It's bound to be something simple I'm missing; it worked fine under 2.2.8. I've enclosed the dmesg and config file as attachments. Any pointers would be greatly appreciated. -- Frank Mayhar [EMAIL PROTECTED] Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #0: Sun Aug 15 15:06:08 PDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/TINKER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 132632402 Hz CPU: Pentium/P54C (132.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf real memory = 67108864 (65536K bytes) avail memory = 62164992 (60708K bytes) Preloaded elf kernel "kernel" at 0xc02cd000. Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.7.0 vga0: rev 0x00 on pci0.9.0 tl0: rev 0x10 int a irq 12 on pci0.10.0 tl0: Ethernet address: 00:08:c7:28:52:93 tl0: autoneg complete, link status good (full-duplex, 100Mbps) ahc0: rev 0x00 int a irq 11 on pci0.12.0 ahc0: aic7870 Wide Channel A, SCSI Id=7, 16/255 SCBs Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <4 virtual consoles, flags=0x0> ed0 at 0x320-0x33f irq 10 on isa ed0: address 00:40:05:11:b2:70, type NE2000 (16 bit) atkbdc0 at 0x60-0x6f on motherboard fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 flags 0x10 on isa sio1: type 16550A ppc0 at 0x278 irq 7 on isa ppc0: SMC FDC37C665GT chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port Intel Pentium detected, installing workaround for F00F bug IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging limited to 100 packets/entry ccd0-15: Concatenated disk drivers Waiting 8 seconds for SCSI devices to settle changing root device to da0s1a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 6.756MB/s transfers (6.756MHz, offset 15) da1: 1170MB (2396970 512 byte sectors: 255H 63S/T 149C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 8.064MB/s transfers (8.064MHz, offset 8) da2: 1042MB (2134305 512 byte sectors: 255H 63S/T 132C) da3 at ahc0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 8.064MB/s transfers (8.064MHz, offset 15), Tagged Queueing Enabled da3: 1001MB (2051000 512 byte sectors: 64H 32S/T 1001C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 8.064MB/s transfers (8.064MHz, offset 15), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # http://www.FreeBSD.ORG/> # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.140 1998/12/27 13:55:47 sos Exp $ machine "i386" cpu "I586_CPU" ident TINKER maxusers128 #optionsMATH_EMULATE#Support for x87 emulation options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device options NFS #Network Filesystem options MFS #Memory File System options MSDOSFS #MSDOS Filesystem options "CD9660"#ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 options UCONSOLE#Allow users to grab the console options "NSWAPDEV=8" options COMPAT_LINUX options SYSVSHM options SYSVSEM options SYSVMSG op
Re: Keyboard problems w/3.2-stable.
frank wrote: > I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems > to be working okay, except the keyboard. It works fine under the BIOS, and > during the bootstrap, but by the time it gets to the login prompt, it stops > responding entirely. Well, duh. I found the problem, partly thanks to a response from -hackers. I had the line device atkbd0 at atkbdc? ... instead of device atkbd0 at isa? ... Hand the dunce cap over here. And my apologies for the various bounces. Going to the latest bind and sendmail is giving me fits. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Keyboard problems w/3.2-stable.
frank wrote: > I just upgraded an old Pentium 133 system to 3.2-stable. Everything seems > to be working okay, except the keyboard. It works fine under the BIOS, and > during the bootstrap, but by the time it gets to the login prompt, it stops > responding entirely. Well, duh. I found the problem, partly thanks to a response from -hackers. I had the line device atkbd0 at atkbdc? ... instead of device atkbd0 at isa? ... Hand the dunce cap over here. And my apologies for the various bounces. Going to the latest bind and sendmail is giving me fits. -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
