Re: more
On Mon, Sep 13, 1999 at 06:03:19AM -0500, Mike Pritchard wrote:
Speaking of which, are there any plans to actually document vi any time
soon? Lots of useful features are missing from the man page!
Sure! Where are your patches for this? I'll review them
and commit them as soon as you supply them!
Why bother? They are already documented in the vi papers, which are
distributed in the system already under
/usr/share/doc/usd/{12.vi,13.viref}. There is a reference to these in
the vi man pages already.
True, but it would be nice if the man page was extended to
include some more documentation. Remember, a lot of our users are
lazy and if "man x" doesn't give them what they want, then
they don't go looking elsewhere. Sad, but true.
Now, the vi(1) man page does refer to the usd document, but
doesn't tell you how to find it. That is a problem. It also
references the "vi quick reference" card", which I have no idea
where to find that (I used to have one sitting one my desk :-).
I think that the originator's request is valid, especially since
some of the original BSD documentation in /usr/share/doc/* has
rotted since it was originally imported. We have been maintaining
those documents more as a "historical" perspective than as
accurate documentation on the current state of affairs.
-Mike
--
Mike Pritchard
[EMAIL PROTECTED] or [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Weird syscons keyboard behaviour
I've noticed some odd syscons keyboard behaviour over the past month or so. Sometimes I get a vty that outputs PC graphics characters for all of my input. This is always at a "login:" prompt. I think I can duplicate this by typing a bunch of garbage at a login prompt, but I don't feel like trying to test it right now and have to reboot my main machine. I just saw this again after a clean boot with a 24 hour old kernel. (built 07:00 a.m. 9/16/99 CST from a few hour old CVSup). The boot went fine, but when I started typing at the login prompt, all I got was garbage. I couldn't switch vty's or anything. I just gave up and hit the big red button. After the reboot, everything was fine. I think this might be some kind of timing problem. I was starting to type in my username right away when I saw the boot was finishing, and if I recall the past incidents correctly, I may have been doing the same thing. I've seen this probably 4 or 5 times in the past month, maybe 6 weeks. Anyone have any ideas what is going on? This is a Compaq AMD K6-2/400 machine. PS/2 style keyboard input to the motherboard. I'll be glad to supply any further details. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current panic w/linux netscape
I finally saw my first -current panic in more than 5 months (not a bad track record). I have a panic that I can duplicate with a 24 hour old "make world" and a 4 hour old -current kernel. If I run the linux netscape (installed from ports less than a week ago), the kernel panics in copystr(). Minimal gdb output follows. I'll have to generate a kernel with debug info for more information. The linux netscape worked fine with my old kernel from 9/16. I'm willing to try and track this down, but I hope someone will pop up and have an idea what is wrong. -Mike Script started on Sun Sep 26 05:47:00 1999 mpp 2# gdb -k /usr/src/sys/compile/MPP/kernel /var/crash/vmcore.0 GNU gdb 4.18 (no debugging symbols found)... IdlePTD 3264512 initial pcb at 29f1c0 panicstr: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x7 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0222d50 stack pointer = 0x10:0xcb0bdc80 frame pointer = 0x10:0xcb0bdce8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 385 (communicator-4.6) interrupt mask = none panic: from debugger panic: from debugger dumping to dev #wd/0x50001, offset 131072 dump 191 ... 1 --- #0 0xc013a644 in boot () (kgdb) bt #0 0xc013a644 in boot () #1 0xc013a9e9 in panic () #2 0xc011f435 in db_panic () #3 0xc011f3d5 in db_command () #4 0xc011f49a in db_command_loop () #5 0xc012151f in db_trap () #6 0xc0215210 in kdb_trap () #7 0xc02240ac in trap_fatal () #8 0xc0223d85 in trap_pfault () #9 0xc02239c7 in trap () #10 0xc0222d50 in copystr () #11 0xc0dc7209 in ?? () #12 0xc0dc5fbd in ?? () #13 0xc0224316 in syscall () #14 0xc0215b06 in Xint0x80_syscall () #15 0x28abf564 in ?? () -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current panic w/linux netscape
:I finally saw my first -current panic in more than 5 months (not a bad
:track record).
:
:I have a panic that I can duplicate with a 24 hour old "make world"
:and a 4 hour old -current kernel. If I run the linux netscape (installed
:from ports less than a week ago), the kernel panics in copystr().
:Minimal gdb output follows. I'll have to generate a kernel with
:debug info for more information.
:
:The linux netscape worked fine with my old kernel from 9/16.
:I'm willing to try and track this down, but I hope someone
:will pop up and have an idea what is wrong.
:
:-Mike
I must have caught two badly timed cvsups in a row. After doing another cvsup
and recompiling/installing a kernel and modules (which I had done before),
everything is working fine. I usually ignore any glitches after
a fresh "cvsup/make world", except in this case it took me 3 cvsup's
to get a fully-functional system.
I'm still not sure exactly what was out of sync here, but after
examing the crash dump with full symbols, it really looked like something
wasn't in sync (i386/trap.c:syscall() had some very odd values it was trying
to use).
I know how to debug kernels, I just haven't had to do so for such a long
time, so I wasn't prepared :-) And doing it this time, just reminds
me how lacking gdb is in some respects compared to other kernel debugging
tools I've used in the past in some areas. In other areas it is much
better.
Thanks for taking the time to respond.
-Mike
Compile your kernel with debugging. In the kernel configuration file
in /usr/src/sys/i386/conf/YOURCONFIGFILE, add:
makeoptions DEBUG="-g"
Then config the kernel and rebuild.
When you make install, the non-debug version will be installed and the
debug version will be sitting in the compile directory as 'kernel.debug'.
Then reboot, then cause the crash again and get another core (be sure
to clear out space from /var/crash if necessary).
Now bring the system up again, and use this for your gdb:
cd /var/crash
gdb -k /usr/src/sys/compile/YOURCONFIGNAME/kernel.debug vmcore.XX
And do the 'back' again to get the stack backtrace. You should see a
whole lot more information.
-Matt
--
Mike Pritchard
[EMAIL PROTECTED] or [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: CVSUP ?
On Sat, Oct 23, 1999 at 01:44:28PM -0700, Mike Smith wrote: It's hosed. There are several emails in -hackers on this. so we're just waiting for a human to go fix it. Someone or something has broken cvsupd on freefall. Until jdp gets back from FreeBSD Con (or someone gives him connectivity there, since we had to pack up the terminal room), there's not going to be any more updates. After we did some more playing on freefall, it looks more like an NFS problem. "ls -l /" hangs on nfsrcv, just like cvsupd is doing right now. -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh to freefall broken
On Thu, Apr 20, 2000 at 05:05:11PM -0700, Archie Cobbs wrote: Kris Kennaway writes: $ ssh [EMAIL PROTECTED] Warning: Server lies about size of server host key: actual size is 1023 bits vs. announced 1024. Warning: This may be due to an old implementation of ssh. Warning: identity keysize mismatch: actual 1023, announced 1024 Agent admitted failure to authenticate using the key. Authentication agent failed to decrypt challenge. Enter passphrase for RSA key '[EMAIL PROTECTED]': Are you still being asked for your passphrase? I noticed a couple of days ago that ssh to freefall wanted my passphrase, but I didn't need it yesterday or today. Sunspots? Full moon? Even before OpenSSH, I've had this problem in the past. Sometimes it seemed to be due to reverse DNS lookups not resolving correctly (my ISP wasn't always responding to reverse DNS lookups correctly). -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed pkg_delete change
On Mon, May 08, 2000 at 02:10:28AM -0400, Kenneth Wayne Culver wrote: I have a suggestion for pkg_delete: Very often when I'm deleting a package (such as kde, after testing the port) I want to delete that package, and all it's dependancies; instead of going around looking for the dependancies, I think it would be a nice idea to add an option to pkg_delete to automatically delete all dependancies that aren't currently used by anything else. If nobody is interested in doing this, I can do it when I have some spare time (finals here at school). And then submit patches. That would have saved me a *lot* of time about a month ago when I went and weeded out all of my packages when my /usr filled up. I basically did what you are proposing by hand and it took forever. e.g. pkg_delete some_package - oops, it depends on pkg_xxx, delete that, oops, it depends on pkg_xxx2, and so on, when in reality that only reason any of those additional packages were installed were for the original package. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
On Wed, May 10, 2000 at 10:16:17AM -0400, Garrett Wollman wrote: On Wed, 10 May 2000 11:57:21 +0800, Trent Nelson [EMAIL PROTECTED] said: Something else I've noticed in the mean time is that PnP devices like my printer - that are also on buses that are probed for PnP devices - end up being probed twice at boot time. Delete the `at isa? port blah' cruft from your config file. For what devices? The only devices I have those on match what is in GENERIC. I did notice that I started getting all of the "unknown: PNPx" messages after the PNPBIOS option became default. On the machine I'm typing on this on, I used to see those messages if I defined PNPBIOS in my config file. PNPBIOS became default some time back, with no way (that I saw) to turn it off. Other than the annoying messages at boot, it never caused a problem that I saw, so I didn't really worry about it. If we aren't supposed to have "at isa? port ..." stuff in our config files, then someone should update GENERIC to reflect that. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
On Tue, Jun 13, 2000 at 04:18:29PM -0700, Peter Wemm wrote: change *ALL* "device foo0 at isa? port blah etc" to "device foo" - see GENERIC for examples. All the 'at ? port ?' stuff is handled by the new /boot/device.hints See GENERIC - if you use a static limited device (eg: fe, aha, le, etc) where GENERIC has 'device le 1' *and* you had more than one device (eg: device le0 at ..., device le1 at ...) then you will need to specify more units. (eg: "device le 2" in the example above.) This is not quite yet complete, but is fully functional. There may still be some syntax changes to the hints stuff in the future, so pay attention. I just noticed that this change has now made a lot of the section 4 man pages out of date. What is the best way to represent these changes in the man pages? A good example is ata(4). Currently it reads like this: SYNOPSIS device isa device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 Should this become: SYNOPSIS device isa device ata hint.ata.0.at="isa" hint.ata.0.port="0x1F0" hint.ata.0.irq="14" hint.ata.1.at="isa" hint.ata.1.port="0x170" Or some much mess? When will the hints file syntax be nailed down, so that someone can go in and fix all the man pages without having to worry about having to go through and do it all again when the syntax changes? Something in the loader man pages should be updated to provide info on the new hints stuff. Having a man page dedicated to describing the hints stuff probably would also be a good idea to make it easy for people to figure out how it works. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
On Mon, Jun 26, 2000 at 09:25:37PM +0200, Guido van Rooij wrote: How about adding a hint to the hint driver itself. E.g. SYNOPSIS device isa device ata hint "hintsfile"# see hint(4) I don't think this is enough. If I botch my hints file enough (and lets say I fat finger some other files in /usr/src/sys/i386/conf. Been there, done that, so lets just assume that it will happen to other people), I should be able to figure out what I need to configure a device from the on-line man-pages. How about something like this: SYNOPSIS device isa device ata hints "hintsfile" # see hints(4) For ata devices on the isa bus, the hint file must contain: the bus that the device resides on (isa), the I/O port and IRQ. For the primary controller, port IO_WD1 and IRQ 14 are used. For the secondary controller, port IO_WD2 and IRQ 15 are used. Maybe the descriptive text could be replaced with something like: See the main text for a description of bus/port/IRQ/flag assignments. And then the main text would include something similar to what I typed above. Then hints(4) could tell the user the syntax they actually have to use and how to use it. If the syntax changes, then we only have to update the generic hints(4). From looking at "NOTES", mostly ISA devices are affected. ppc/scsi/miibus seem to be the other devices (plus another oddball or two). I think as long as we can decide how to provide the needed information in the device specific man pages, this shouldn't be too hard to actually sit down and do. Then someone also has to sit down and write hints(4) to back it all up :-). -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0-current 20000826 snapshot problems
I just had a problem trying to install the latest -current snapshot from the 8/26 snap. Background: Windows trashed my hard disk on one of my machines, so I had to do clean install. Since I run -current on that machine anyways, I decided to try the latest snapshot to restore it. Booting kern.flp (i386) gives me (pardon any typos, I'm looking at one screen and typing on the other): FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000) /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed / Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed can't load 'kernel' can't load 'kernel.old' Type '?' for a list of commands. ok ls - [ the ls was typed by me ] -- / d boot kernel.gz ok boot kernel.gz don't know how to load module '/kernel.gz' This isn't a show stopper for me, since I can restore the machine via other methods, but since I haven't done a clean FreeBSD install in a while, I thought I would try our latest greatest to see how it worked. As you can see, it didn't go very well :-(. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] - End of forwarded message from Mike Pritchard - -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
On Mon, Aug 28, 2000 at 10:23:34AM -0700, Archie Cobbs wrote: John Baldwin writes: FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000) /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed Your floppy is bad. Try a different one. Not necessarily. This also happens if you try to boot boot.flp instead of kern.flp. It turns out it was a bad floppy, which I didn't even think of because I don't think I've had a bad floppy disk in years and years (plus I had been up all night beating my head on the desk over the whole mess). Thanks to everyone who replied. I'm now typing this message from the machine that I had to do the re-install on, so all is good. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re: -CURRENT b0rked?
On Sat, May 12, 2001 at 10:11:25PM -0500, Matthew D. Fuller wrote:
On Sat, May 12, 2001 at 10:07:20PM -0500 I heard the voice of
Ken Wills, and lo! it spake thus:
Deleting keymap.h (autogenerated, in obj/* somewhere, I forget), and restarting
the build got me past this.
I start all my builds with an empty /usr/obj and a freshly co'd /usr/src.
Re-newfs'ing everything here and trying again, just to make doubly sure
now, but I'm pretty sure I cleaned up as always.
Sounds like a problem I had today trying to do a buildworld.
I suspect that the following change messed things up:
src/usr.sbin/sysinstall/Makefile:
revision 1.110
date: 2001/05/12 09:19:36; author: sobomax; state: Exp; lines: +2 -1
Take keyboard map files from ${.CURDIR}/../../share/syscons/keymaps, not from
/usr/share/syscons/keymaps. This should prevent word breakage when new keymaps
have been added.
To get around it, I just commented out the file that was causing problems
in the makefile (ua..alt.kbd or something like that), but before that I
had nuked /usr/obj twice, and did fresh checkouts of /usr/src just to be
sure I hadn't messed up.
-Mike
-
Mike Pritchard
[EMAIL PROTECTED] or [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATA problem
On Wed, Dec 15, 1999 at 10:16:29PM +0100, D. Rock wrote: Hi, The ata driver tries to enable UDMA for my controller, but fails (this is no disk problem. The disks can do UDMA, as tested in another machine). Perhaps UDMA should be disabled for all VIA 82C586 chips: I have two machines with VIA 82C586 chips and they both seem to do UDMA just fine. Several days ago, one machine didn't work right with UDMA (it detected the disk as UDMA/66, but it is only a UDMA/33 disk), but today after a fresh cvsup and kernel build it seems to be working fine. See the dmesg output below. -Mike ata-pci0: VIA 82C586 ATA controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ad0: Maxtor 91366U4/RA530JN0 ATA-5 disk at ata0 as master ad0: 13029MB (26684784 sectors), 26473 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA33 Mounting root from ufs:/dev/ad0s2a -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
