Re: panic: vm_fault: fault on nofault entry
Subject: Re: panic: vm_fault: fault on nofault entry, On Wed, 19 Nov 2003 12:38:14 +0900, Jun Kuriyama wrote: > After CVSup'ing to latest source, it can be reproduced. It happens at > "make release". "/mnt" below may indicates this happened at making > floppies with mfs filesystem. Yaeh, latest kernel also caused the same panic at "make release" :-( -- Shin-ichi YOSHIMOTO <[EMAIL PROTECTED]> http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rtld + static linking
After watching the recent shared/dynamic threads, and reading the archives from five or six years ago, I have a question... Dynamic linking works by the kernel running the dynamic linker, which loads shared objects and fixes the symbol tables, yes? Is there some reason that a statically-linked program couldn't include some "ld-elf.a" type of intelligence? Would that be necessary and sufficient to allow statically-linked programs to load shared objects? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: localhost adress
Hi, Maybe the latest commit by 'tmm' fixes it: tmm 2003/11/22 19:02:00 PST FreeBSD src repository Modified files: sys/netinet in_pcb.c Log: bzero() the the sockaddr used for the destination address for rtalloc_ign() in in_pcbconnect_setup() before it is filled out. Otherwise, stack junk would be left in sin_zero, which could cause host routes to be ignored because they failed the comparison in rn_match(). This should fix the wrong source address selection for connect() to 127.0.0.1, among other things. Reviewed by:sam Approved by:re (rwatson) Revision ChangesPath 1.133 +1 -0 src/sys/netinet/in_pcb.c -- Ady (@freebsd.ady.ro) On Sat, 22 Nov 2003, Anthony Ginepro wrote: > Since my last current (FreeBSD renaissance.homeip.net 5.1-CURRENT > FreeBSD 5.1-CURRENT #0: Fri Nov 21 17:49:36 CET 2003), I couldn't > use anymore local network program like mlnet (telnet localhost 4000) > or squid as my adress is 81.65.xx.xx (from my modem-cable) instead > of 127.0.0.1. > > I didn't have this trouble with -CURRENT on the 17th of November. > > Is it related to tcp hostcache or is something weird in my config ? > > Anthony. > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vfs_domount() ->...-> vfs_freeopts() NULL pointer dereferencing
Hi,
System in question is FreeBSD 5.1-CURRENT,
sources for -current cvsupped a few days ago.
Problem occurs while mounting ext2fs partition. If VFS_MOUNT()
returns error there is null pointer dereference happening
in vfs_freeopts() which is called by vfs_mount_destroy()
Trace:
vfs_freeopts(0, ...)
vfs_mount_destroy()
vfs_domount()
vfs_nmount
nmount()
offending code:
/* Release all resources related to the mount options. */
static void
vfs_freeopts(struct vfsoptlist *opts)
{
struct vfsopt *opt;
/* jr */
if (!opts) printf("tailq list opts is NULL pointer\n");
while (!TAILQ_EMPTY(opts)) {
opt = TAILQ_FIRST(opts);
vfs_freeopt(opts, opt);
}
free(opts, M_MOUNT);
}
Trivial patch would be adding:
if (!opts) return;
but is it correct?
best regards, bm.
ps. ext2fs was dirty..
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic when trying to mount cd9660 as udf
Christian Laursen wrote:
> By accident, I tried to mount a CD as UDF, and got the follwoing panic:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc06c2f6c
> stack pointer = 0x10:0xcda4bac0
> frame pointer = 0x10:0xcda4bacc
> 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 = 530 (mount_udf)
>
> This seems to be easily reproducable. First I got it on my workstation
> running 5.2-BETA, and I then reproduced it on my test machine which runs
> -CURRENT from 4 days ago:
[...]
Can you try the attached patch and tell me if it fixes your problem?
Thanks,
Maxime
Index: vfs_mount.c
===
RCS file: /space2/ncvs/src/sys/kern/vfs_mount.c,v
retrieving revision 1.115
diff -u -p -r1.115 vfs_mount.c
--- vfs_mount.c 14 Nov 2003 05:27:41 - 1.115
+++ vfs_mount.c 23 Nov 2003 12:35:29 -
@@ -841,7 +841,8 @@ update:
* Check if the fs implements the type VFS_[N]MOUNT()
* function we are looking for.
*/
- if ((compat == 0) == (mp->mnt_op->vfs_mount != NULL)) {
+ if ((compat && mp->mnt_op->vfs_mount == NULL) ||
+ (!compat && mp->mnt_op->vfs_nmount == NULL)) {
printf("%s doesn't support the %s mount syscall\n",
mp->mnt_vfc->vfc_name, compat? "old" : "new");
VI_LOCK(vp);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic when trying to mount cd9660 as udf
It seems that vfs_mount.c rev 1.113 breakes something.
It also breakes mount_udf -C. Using rev 1.112 works fine with me.
A mail to current@ with subject "vfs_domount() ->...-> vfs_freeopts()
NULL pointer dereferencing" may also related to the same problem.
- R. Imura
On Sun, Nov 23, 2003 at 03:02:34AM +0100, Christian Laursen wrote:
> By accident, I tried to mount a CD as UDF, and got the follwoing panic:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc06c2f6c
> stack pointer = 0x10:0xcda4bac0
> frame pointer = 0x10:0xcda4bacc
> 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 = 530 (mount_udf)
>
> This seems to be easily reproducable. First I got it on my workstation
> running 5.2-BETA, and I then reproduced it on my test machine which runs
> -CURRENT from 4 days ago:
>
> FreeBSD cardassian.borderworlds.dk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Nov 19
> 04:22:32 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
>
> The output in this mail is from the test machine.
>
> This is the backtrace I got from the resulting crashdump:
>
> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> #1 0xc066d6fb in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
> #2 0xc066dafd in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #3 0xc048ac32 in db_panic () at /usr/src/sys/ddb/db_command.c:450
> #4 0xc048ab92 in db_command (last_cmdp=0xc0938360, cmd_table=0xc08c3c00,
> aux_cmd_tablep=0xc08baa04, aux_cmd_tablep_end=0xc08baa1c)
> at /usr/src/sys/ddb/db_command.c:346
> #5 0xc048acd5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
> #6 0xc048dcd5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
> #7 0xc0812dcc in kdb_trap (type=12, code=0, regs=0xcda4ba80)
> at /usr/src/sys/i386/i386/db_interface.c:171
> #8 0xc08294d6 in trap_fatal (frame=0xcda4ba80, eva=0)
> at /usr/src/sys/i386/i386/trap.c:816
> #9 0xc0829182 in trap_pfault (frame=0xcda4ba80, usermode=0, eva=0)
> at /usr/src/sys/i386/i386/trap.c:735
> #10 0xc0828d23 in trap (frame=
> {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1040053552, tf_esi = 1, tf_ebp
> = -844842292, tf_isp = -844842324, tf_ebx = 0, tf_edx = 4, tf_ecx = 1, tf_eax = 0,
> tf_trapno = 12, tf_err = 0, tf_eip = -1066651796, tf_cs = 8, tf_eflags = 66182,
> tf_esp = 6, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:420
> #11 0xc0814818 in calltrap () at {standard input}:94
> #12 0xc06c3913 in vfs_mount_destroy (mp=0x0, td=0x0)
> at /usr/src/sys/kern/vfs_mount.c:537
> #13 0xc06c472f in vfs_domount (td=0xc20c7dc0, fstype=0xc2020ad0 "udf",
> fspath=0xc2020ab0 "/mnt", fsflags=1, fsdata=0xc2020c00, compat=0)
> at /usr/src/sys/kern/vfs_mount.c:938
> #14 0xc06c3a39 in vfs_nmount (td=0x0, fsflags=0, fsoptions=0x0)
> at /usr/src/sys/kern/vfs_mount.c:581
> #15 0xc06c353d in nmount (td=0x0, uap=0xcda4bd10)
> at /usr/src/sys/kern/vfs_mount.c:407
> #16 0xc0829870 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077940702, tf_esi = 8, tf_ebp
> = -1077940972, tf_isp = -844841612, tf_ebx = 5, tf_edx = -1077940736, tf_ecx = 10,
> tf_eax = 378, tf_trapno = 12, tf_err = 2, tf_eip = 671876783, tf_cs = 31, tf_eflags
> = 582, tf_esp = -1077942196, tf_ss = 47})
> at /usr/src/sys/i386/i386/trap.c:1010
> #17 0xc081486d in Xint0x80_syscall () at {standard input}:136
>
> --
> Best regards
> Christian Laursen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic when trying to mount cd9660 as udf
Maxime Henrion <[EMAIL PROTECTED]> writes:
> Christian Laursen wrote:
> > By accident, I tried to mount a CD as UDF, and got the follwoing panic:
[snip]
> Can you try the attached patch and tell me if it fixes your problem?
Unfortunately it doesn't seem to make any difference.
The trace seems to be identical except for a line number that changed
because of the patch.
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc066d6fb in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc066dafd in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc048ac32 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc048ab92 in db_command (last_cmdp=0xc0938360, cmd_table=0xc08c3c00,
aux_cmd_tablep=0xc08baa04, aux_cmd_tablep_end=0xc08baa1c)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc048acd5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc048dcd5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7 0xc0812ddc in kdb_trap (type=12, code=0, regs=0xcda39a80)
at /usr/src/sys/i386/i386/db_interface.c:171
#8 0xc08294e6 in trap_fatal (frame=0xcda39a80, eva=0)
at /usr/src/sys/i386/i386/trap.c:816
#9 0xc0829192 in trap_pfault (frame=0xcda39a80, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:735
#10 0xc0828d33 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1040052640, tf_esi = 1, tf_ebp =
-844916020, tf_isp = -844916052, tf_ebx = 0, tf_edx = 4, tf_ecx = 1, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1066651796, tf_cs = 8, tf_eflags = 66182, tf_esp
= 6, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:420
#11 0xc0814828 in calltrap () at {standard input}:94
#12 0xc06c3913 in vfs_mount_destroy (mp=0x0, td=0x0)
at /usr/src/sys/kern/vfs_mount.c:537
#13 0xc06c4740 in vfs_domount (td=0xc20c7640, fstype=0xc2020e60 "udf",
fspath=0xc2020ea0 "/mnt", fsflags=1, fsdata=0xc2020e40, compat=0)
at /usr/src/sys/kern/vfs_mount.c:939
#14 0xc06c3a39 in vfs_nmount (td=0x0, fsflags=0, fsoptions=0x0)
at /usr/src/sys/kern/vfs_mount.c:581
#15 0xc06c353d in nmount (td=0x0, uap=0xcda39d10)
at /usr/src/sys/kern/vfs_mount.c:407
#16 0xc0829880 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077940702, tf_esi = 8, tf_ebp =
-1077940972, tf_isp = -844915340, tf_ebx = 5, tf_edx = -1077940736, tf_ecx = 10,
tf_eax = 378, tf_trapno = 12, tf_err = 2, tf_eip = 671876783, tf_cs = 31, tf_eflags =
582, tf_esp = -1077942196, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1010
#17 0xc081487d in Xint0x80_syscall () at {standard input}:136
--
Best regards
Christian Laursen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
printing problems lpr/lpd misbehavior ?
On a fresh current 23/11 1600CET : normal user cannot print anymore: >lpr lpr: error - scheduler not responding! but as root things works as expected. Ideas ? or another item for the "bugs to fix" list ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing problems lpr/lpd misbehavior ?
It seems Soren Schmidt wrote: > > On a fresh current 23/11 1600CET : > > normal user cannot print anymore: > > >lpr > lpr: error - scheduler not responding! > > but as root things works as expected. > > Ideas ? or another item for the "bugs to fix" list ? Disregard above, some crappy port has installed "cups" which apparently has its own "lpr" command, nice... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing problems lpr/lpd misbehavior ?
Soren Schmidt <[EMAIL PROTECTED]> writes: > Disregard above, some crappy port has installed "cups" which apparently > has its own "lpr" command, nice... Sorry, but *you* are the "crappy port". CUPS is intentionally split into several ports so that the parts that other ports depend on (cups-base) can be installed separately from the front-end (cups-lpr) and the only port that depends on the front-end is the meta-port, which itself has no dependents. You should consider this a golden opportunity to try out CUPS, which is much easier to set up than the base system's lpd, and has far better support for modern printers (including the ability to configure printer options such as resolution, quality, duplex etc.). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing problems lpr/lpd misbehavior ?
It seems Dag-Erling Smørgrav wrote: > Soren Schmidt <[EMAIL PROTECTED]> writes: > > Disregard above, some crappy port has installed "cups" which apparently > > has its own "lpr" command, nice... > > Sorry, but *you* are the "crappy port". CUPS is intentionally split > into several ports so that the parts that other ports depend on > (cups-base) can be installed separately from the front-end (cups-lpr) > and the only port that depends on the front-end is the meta-port, > which itself has no dependents. "parse error" it sneaked in as a dependency of something else, I *newer* installed cups here (and its also now *gone*)... > You should consider this a golden opportunity to try out CUPS, which > is much easier to set up than the base system's lpd, and has far > better support for modern printers (including the ability to configure > printer options such as resolution, quality, duplex etc.). No thanks, lpd does the job quite nicely, with close to *no setup* so it cant be much easier :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
XFree86 ports / Font problem
Hi... after updating my 5.1-current machine: a) new kernel b) new world c) all packages (including XFree86) d) newest gnome-packages (using marcusmerge) i got these msgs in XFree86.0.log Warning: font renderer for ".pcf" already registered at priority 0 Warning: font renderer for ".pcf.Z" already registered at priority 0 Warning: font renderer for ".pcf.gz" already registered at priority 0 Warning: font renderer for ".snf" already registered at priority 0 Warning: font renderer for ".snf.Z" already registered at priority 0 Warning: font renderer for ".snf.gz" already registered at priority 0 Warning: font renderer for ".bdf" already registered at priority 0 Warning: font renderer for ".bdf.Z" already registered at priority 0 Warning: font renderer for ".bdf.gz" already registered at priority 0 Warning: font renderer for ".pmf" already registered at priority 0 The result is a fontless X... (okay enlightenment has it fonts... but mostly prgs do not... including gdm and all that things) Does anyone know something about this? Jan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing problems lpr/lpd misbehavior ?
In a message written on Sun, Nov 23, 2003 at 05:42:44PM +0100, Dag-Erling Smørgrav wrote: > Sorry, but *you* are the "crappy port". CUPS is intentionally split > into several ports so that the parts that other ports depend on > (cups-base) can be installed separately from the front-end (cups-lpr) > and the only port that depends on the front-end is the meta-port, > which itself has no dependents. One thing I notice is if you select "KDE" during the install you get enough cups to print, but none of the command line front ends. I've helped about 20 people with this "problem". I'm not sure if a better solution is to make the "KDE" master target include the command line utilities or to just make cups into one bit port. However, as it works now it doesn't make a lot of sense. You're installing a huge windowing system but you skimp on a few hundred k of command line utilities that people expect to exist. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Panic when trying to mount cd9660 as udf
On Sun, Nov 23, 2003 at 03:02:34AM +0100, Christian Laursen wrote:
> By accident, I tried to mount a CD as UDF, and got the follwoing panic:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc06c2f6c
> stack pointer = 0x10:0xcda4bac0
> frame pointer = 0x10:0xcda4bacc
> 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 = 530 (mount_udf)
>
> This seems to be easily reproducable. First I got it on my workstation
> running 5.2-BETA, and I then reproduced it on my test machine which runs
> -CURRENT from 4 days ago:
>
> FreeBSD cardassian.borderworlds.dk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Nov 19
> 04:22:32 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
>
> The output in this mail is from the test machine.
>
> This is the backtrace I got from the resulting crashdump:
>
> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> #1 0xc066d6fb in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
> #2 0xc066dafd in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #3 0xc048ac32 in db_panic () at /usr/src/sys/ddb/db_command.c:450
> #4 0xc048ab92 in db_command (last_cmdp=0xc0938360, cmd_table=0xc08c3c00,
> aux_cmd_tablep=0xc08baa04, aux_cmd_tablep_end=0xc08baa1c)
> at /usr/src/sys/ddb/db_command.c:346
> #5 0xc048acd5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
> #6 0xc048dcd5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
> #7 0xc0812dcc in kdb_trap (type=12, code=0, regs=0xcda4ba80)
> at /usr/src/sys/i386/i386/db_interface.c:171
> #8 0xc08294d6 in trap_fatal (frame=0xcda4ba80, eva=0)
> at /usr/src/sys/i386/i386/trap.c:816
> #9 0xc0829182 in trap_pfault (frame=0xcda4ba80, usermode=0, eva=0)
> at /usr/src/sys/i386/i386/trap.c:735
> #10 0xc0828d23 in trap (frame=
> {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1040053552, tf_esi = 1, tf_ebp
> = -844842292, tf_isp = -844842324, tf_ebx = 0, tf_edx = 4, tf_ecx = 1, tf_eax = 0,
> tf_trapno = 12, tf_err = 0, tf_eip = -1066651796, tf_cs = 8, tf_eflags = 66182,
> tf_esp = 6, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:420
> #11 0xc0814818 in calltrap () at {standard input}:94
> #12 0xc06c3913 in vfs_mount_destroy (mp=0x0, td=0x0)
> at /usr/src/sys/kern/vfs_mount.c:537
> #13 0xc06c472f in vfs_domount (td=0xc20c7dc0, fstype=0xc2020ad0 "udf",
> fspath=0xc2020ab0 "/mnt", fsflags=1, fsdata=0xc2020c00, compat=0)
> at /usr/src/sys/kern/vfs_mount.c:938
> #14 0xc06c3a39 in vfs_nmount (td=0x0, fsflags=0, fsoptions=0x0)
> at /usr/src/sys/kern/vfs_mount.c:581
> #15 0xc06c353d in nmount (td=0x0, uap=0xcda4bd10)
> at /usr/src/sys/kern/vfs_mount.c:407
> #16 0xc0829870 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077940702, tf_esi = 8, tf_ebp
> = -1077940972, tf_isp = -844841612, tf_ebx = 5, tf_edx = -1077940736, tf_ecx = 10,
> tf_eax = 378, tf_trapno = 12, tf_err = 2, tf_eip = 671876783, tf_cs = 31, tf_eflags
> = 582, tf_esp = -1077942196, tf_ss = 47})
> at /usr/src/sys/i386/i386/trap.c:1010
> #17 0xc081486d in Xint0x80_syscall () at {standard input}:136
Hi,
I get a similar backtrace when trying to mount a genuine UDF filesystem (DVD-ROM)
as UDF - and it happens every time with all the DVD-ROMs I have. Seems to be the
same offender as in your case
This is -current from sources dated november 15th.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc05ab4bc
stack pointer = 0x10:0xe8153a8c
frame pointer = 0x10:0xe8153a98
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 = 843 (mount_udf)
trap number = 12
panic: page fault
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc05524f9 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc05528d8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc071c3d6 in trap_fatal (frame=0xe8153a4c, eva=0) at
/usr/src/sys/i386/i386/trap.c:821
#4 0xc071c072 in trap_pfault (frame=0xe8153a4c, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:735
#5 0xc071bbcd in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -963579664, tf_esi = 1, tf_ebp =
-401261928, tf_isp = -401261960, tf_ebx = 0, tf_edx = -963570612, tf_ecx = -960873344,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1067797316, tf_cs = 8, tf_eflags =
66194, tf_esp = 6, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:420
#6 0xc070ce58 in calltrap
Re: printing problems lpr/lpd misbehavior ?
Soren Schmidt <[EMAIL PROTECTED]> writes: > "parse error" it sneaked in as a dependency of something else, I *newer* > installed cups here (and its also now *gone*)... check /usr/ports/INDEX, it *can't* have snuck in as a dependency. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic when trying to mount cd9660 as udf
Christian Laursen wrote: > Maxime Henrion <[EMAIL PROTECTED]> writes: > > > Christian Laursen wrote: > > > By accident, I tried to mount a CD as UDF, and got the follwoing panic: > > [snip] > > > Can you try the attached patch and tell me if it fixes your problem? > > Unfortunately it doesn't seem to make any difference. > > The trace seems to be identical except for a line number that changed > because of the patch. Oops, sorry, that patch had 0 chances to work. I now see what is the problem and I'll send you another fix as soon as possible, but can't right now. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Patch to Elan520/Soekris 45xx support in FreeBSD-current
http://phk.freebsd.dk/patch/cpu_elan.patch http://phk.freebsd.dk/patch/CPU_ELAN.4 The major new things are: ELAN_XTAL option now called CPU_ELAN_XTAL ELAN_PPS option now called CPU_ELAN_PPS /dev/led/error for the error LED. More LEDs can be configured on the GPIO pins, for instance: sysctl machdep.elan_gpio_config="-LLLE--lpLL-" Configures active high LEDS on GPIO5,6,7,21 & 22, an active low LED on GPIO11. These will appear as devices "/dev/led/gpio5" etc. The 'p' on GPIO12 and 'E' on GPIO8 are PPS input and PPS-echo configurations (enabled by CPU_ELAN_PPS option). The led(4) interface is of course not only useful with lamps, you can use it with any sort of gadget connected to a GPIO pin. I can not guarantee that these patches will make it into FreeBSD 5.2. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.2-BETA lockup
Hi, Since updating two of my machines to the latest HEAD I am experiencing a total lockup on one of them. After being booted for approx 3 minutes the machine stops responding completely. It doesn't panic or drop into DDB. The numlock key doesn't toggle the keyboard light, and I can't drop it into DDB manually. I have full debugging options compiled in to this kernel as per the usual -CURRENT GENERIC file. It's currently booted with the older kernel from the 16th and this is stable as a rock. Anything else I can do to find the problem out or workaround it considering it just hangs? The machine is a router running two 3com network cards (xl) and IPFW/natd. It also has IPV6 with IP6FW, and a gif tunnel. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
$ cc close.c -o close && ./close
0
0
$ cc close.c -lc_r -o close && ./close
0
25
$ cat close.c
#include
main()
{
int fd = open("/dev/null", 1);
printf("%d\n", errno);
close(fd);
printf("%d\n", errno);
}
This confuses rather badly applications which assume errno is meaningful.
It could be fixed easily by repeating the trick from uthread/uthread_fd.c:
--- /arc/freebsd/src/lib/libc_r/uthread/uthread_close.c Tue Jun 10 23:42:27 2003
+++ lib/libc_r/uthread/uthread_close.c Sun Nov 23 00:50:30 2003
@@ -87,10 +87,12 @@ _close(int fd)
*/
if ((S_ISREG(sb.st_mode) || S_ISCHR(sb.st_mode))
&& (_thread_fd_getflags(fd) & O_NONBLOCK) == 0) {
+ int saved_errno = errno;
/* Get the current flags: */
flags = __sys_fcntl(fd, F_GETFL, NULL);
/* Clear the nonblocking file descriptor flag: */
__sys_fcntl(fd, F_SETFL, flags & ~O_NONBLOCK);
+ errno = saved_errno;
}
/* XXX: Assumes well behaved threads. */
Regards,
Adi
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sat, Nov 22, 2003 a.d., M. Warner Losh wrote: > Grepping seems unsatisfying to find out which keys are used. Do you > have a list? Believe it or not, vi only needs 'cm' :-) Regards, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing problems lpr/lpd misbehavior ?
On Sun, Nov 23, 2003 at 05:42:44PM +0100, Dag-Erling Smørgrav wrote: > Soren Schmidt <[EMAIL PROTECTED]> writes: > > Disregard above, some crappy port has installed "cups" which apparently > > has its own "lpr" command, nice... > > Sorry, but *you* are the "crappy port". CUPS is intentionally split > into several ports so that the parts that other ports depend on > (cups-base) can be installed separately from the front-end (cups-lpr) > and the only port that depends on the front-end is the meta-port, > which itself has no dependents. > > You should consider this a golden opportunity to try out CUPS, which ^. > is much easier to set up than the base system's lpd, and has far > better support for modern printers (including the ability to configure > printer options such as resolution, quality, duplex etc.). q: What makes cups so special that one should try it out ? What can it do better than apsfilter which IMHO isn't as bloated as cups and has better features... reply-to set ... Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? -> http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Bruce M Simpson <[EMAIL PROTECTED]> writes: : On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote: : > * /rescue/vi is currently unusable if /usr is missing because : >the termcap database is in /usr. One possibility : >would be to build a couple of default termcap entries : >into ncurses or into vi. : : My suggested candidates are vt100 and cons25. The comconsole port installs : an /etc/ttys entry using vt100. This is also the default terminal type for : most dialup entries. Timing Solutions uses the following minimal termcap for its embedded applications. It has a number of terminals that it supports, while still being tiny. it is 3.5k in size, which was the goal ( < 4k block size we were using). One could SED this down by another 140 bytes or so. Removing the comments and the verbose names would net another 300 odd bytes. The terminals supported are vt220, vt102, vt100, xterm, xterms, cons25w, cons25 and ansi. This seems a reasonable number: neither too few, nor too many. It lets people connect 'normal' terminals to the serial port (most PCs have vt100/vt220 emulation), as well as PC to PC connection on the console or xterm. I'd be happy to commit this as /etc/termcap.tiny. vi could then look for both termcap and termcap.tiny and things would just work. Comments? Sounds like a good idea to me. I only wonder if it makes sense to commit it as /rescue/termcap.tiny to make the purpose clear? I see no point in trying to prune any smaller. As you point out, it's already smaller than a typical block size. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Machine freeze when X starts
Robert Watson wrote: On Mon, 17 Nov 2003, Jens Rehsack wrote: Hmm. This failure mode is fairly common when a resource deadlock or lock deadlock occurs in some kernel subsystems. Any chance you can get a serial console on the box so you can drop to DDB and generate some ps and stacktrace output? It seems to me a little bit more complicated to setup the serial console, so: yes, I can do it, but not today. Or - if you have a small "quick get DDB to serial console without many trouble", I can give it a quick start. I'll try to do this week. Hook up a null modem cable to the first serial port on your machine, and to a serial port on another machine. On the other machine, use tip to attach to the com port, or some other com program of your choice. Speed should be 9600. ... Hi Robert, I had to build the kernels and world for the remote machine before, because I hadn't enabled the serial devices in the kernel, but I didn't get ready before today. I didn't get tip running, but my old serial terminal (Robotron P8000) worked fine. But the bug was gone in the meantime, so - sorry for now. But for the next time, I'm prepared. Best regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing problems lpr/lpd misbehavior ?
Andreas Klemm <[EMAIL PROTECTED]> writes: > q: What makes cups so special that one should try it out ? > What can it do better than apsfilter which IMHO isn't as bloated > as cups and has better features... apsfilter is in my experience a lot more difficult and confusing to configure, and I don't think I ever figured out how to do things like switch duplex on / off etc. CUPS has a web-based configuration interface which is very simple to use. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
More info [was Re: Sony PCG-GRX570 laptop, panic on boot w/ 5.1R...]
George Hartzell writes: > > I've been trying to install something 5-ish on a Sony PCG-GRX570 > laptop. > > I started off trying to boot off of the 5.1 release CD, normally, > w/out acpi, and safe. Every option panic-ed, with essentially the > same message (see below), although it followed a different driver > depending on how it was booted. > > Then I installed 4.7 (since I had the CD), cvsup-ed my repository, and > cvs up'ed /usr/src to the 5-current. I followed the section on moving > from 4 to 5-current in UPDATING to build the world, etc I had to > work around a bit of previously reported 4.7/5 weirdness in > /usr/include, but it went w/out any trouble. > > When I reached the point where I was supposed to boot the new kernel > in single user mode, the 5-current kernel paniced: > > miibus0: in fxp0 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x63696d20 > fault code = supervisor write, page not present > instruction pointer= 0x8:0xc0659df3 > stack pointer = 0x10:0xc0c217ac > frame pointer = 0x10:0xc0c217cc > 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= 0 (swapper) > kernel: type 12 trap, code=0 > Stopped at ithread_add_handler+0x163: movl%ebx,0(%eax) > db> > > I've seen several similar reports in the archives for late last > summer. The general answer seemed to be that people were having > hardware trouble. I don't think that is the case in my case, unless > -current is doing something very strange, since the same machine runs > well enough under 4.7 to buildworld and buildkernel, and the same > hardware has been running Suse and Win2000. > > How can I help get this solved? It turns out that the 5.0 release CD also boots successfully, so it seems to be something that's happened in -current since then. Help? g. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 23, 2003 at 02:42:58AM +0100, Brad Knowles wrote: > At 5:22 PM -0800 2003/11/22, David O'Brien wrote: > > > Please, NO. There wasn't an FTP client available for this type of > > recovery pre-/rescue, there shouldn't be one now. > > Why? Why cut your nose off to spite your face? Even though this > capability may not have existed before, why shouldn't we have it now? Lets build all of /bin, /sbin, /usr/bin, /usr/sbin static then. You would have all kinds of capability you didn't before. /rescue is the consession made between those that want a dynamic / and those that want a static /. Its purpose is only to allow one to do the things they could before with a static /. It is not to become a can or worms that ends up being a duplicate of 50% of the system. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vinum still not working
Hello, I just built a new world+kernel after the commit of grogs corrections but I still get: [EMAIL PROTECTED] - ~ 503 # vinum start ** no drives found: No such file or directory -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PII SMP system hangs during boot with ACPI enabled
I have an old dual PII/400 system that I'm trying to set up as a -current scratchbox. The motherboard is a Tyan S1836DLUAN with the Intel 440BX chipset. I upgraded the BIOS to the latest from Tyan's web site. It is supposed to support ACPI. I'm using -current from around noon Pacific time, November 23 (today). The system boots and runs fine if I disable ACPI either in loader.conf or in the BIOS, but if ACPI is enabled it hangs fairly late in the boot, right after these messages: lo0: bpf attached acpi_cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% It's not a totally solid hang. For instance, the scroll lock key works and allows me to scroll forward and backward through the syscons output. I've attached the verbose boot messages. Is this system Just Too Old? John SMAP type=02 base=0009fc00 len=0400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=0fee SMAP type=03 base=0ffe len=00018000 SMAP type=04 base=0fff8000 len=8000 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fffc len=0004 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-BETA #1: Sun Nov 23 13:32:22 PST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/VASHON Preloaded elf kernel "/boot/kernel/kernel" at 0xc07bc000. ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193045 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 400910473 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 268304384 (255 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00829000 - 0x0fb39fff, 254873600 bytes (62225 pages) avail memory = 255266816 (243 MB) APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00fdb40 bios32: Entry = 0xfdb50 (c00fdb50) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb71 pnpbios: Found PnP BIOS data at 0xc00f72c0 pnpbios: Entry = f:6964 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 MADT: Found IO APIC ID 2, Vector 0 at 0xfec0 ioapic0: intpin 0 -> ExtINT (edge, activehi) ioapic0: intpin 1 -> irq 1 (edge, activehi) ioapic0: intpin 2 -> irq 2 (edge, activehi) ioapic0: intpin 3 -> irq 3 (edge, activehi) ioapic0: intpin 4 -> irq 4 (edge, activehi) ioapic0: intpin 5 -> irq 5 (edge, activehi) ioapic0: intpin 6 -> irq 6 (edge, activehi) ioapic0: intpin 7 -> irq 7 (edge, activehi) ioapic0: intpin 8 -> irq 8 (edge, activehi) ioapic0: intpin 9 -> irq 9 (edge, activehi) ioapic0: intpin 10 -> irq 10 (edge, activehi) ioapic0: intpin 11 -> irq 11 (edge, activehi) ioapic0: intpin 12 -> irq 12 (edge, activehi) ioapic0: intpin 13 -> irq 13 (edge, activehi) ioapic0: intpin 14 -> irq 14 (edge, activehi) ioapic0: intpin 15 -> irq 15 (edge, activehi) ioapic0: intpin 16 -> irq 16 (level, activelo) ioapic0: intpin 17 -> irq 17 (level, activelo) ioapic0: intpin 18 -> irq 18 (level, activelo) ioapic0: intpin 19 -> irq 19 (level, activelo) ioapic0: intpin 20 -> irq 20 (level, activelo) ioapic0: intpin 21 -> irq 21 (level, activelo) ioapic0: intpin 22 -> irq 22 (level, activelo) ioapic0: intpin 23 -> irq 23 (level, activelo) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: active-hi MADT: intr override: source 9, irq 20 ioapic0: intpin 9 disabled ioapic0: intpin 20 trigger: level ioapic0: intpin 20 polarity: active-hi ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00040011 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff null: random: mem: Pentium Pro MTRR support enabled acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width =
libutil.so version bumped, but no compat lib yet
After rebuilding a -CURRENT box today and removing some old cruft, as I usually do, I noticed that libutil.so had been bumped to version 4, although there wasn't any version 3 in /usr/lib/compat yet. This bump was done quite recently, Wed Nov 12 21:56:07 2003 UTC. I'm not sure if it was an oversight to leave out installing a compat lib, or is the policy in this case "just rebuild almost all your ports, this is -CURRENT, after all" ? :) (It turns out that quite a lot of them depend on libutil.so.3 ...) If it's needed, I'll shoot in a nice PR. There's probably a good copy of a libutil.so.3 binary to be found on the 5.1-RELEASE CD, or else I'll just keep using my old one. :) pgp0.pgp Description: PGP signature
Re: vinum still not working
On Sunday, 23 November 2003 at 22:46:30 +0100, Matthias Schuendehuette wrote: > Hello, > > I just built a new world+kernel after the commit of grogs corrections > but I still get: > > [EMAIL PROTECTED] - ~ > 503 # vinum start > ** no drives found: No such file or directory Yes. The fix wasn't enough. I was holding off committing until I could test it. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Unfortunate dynamic linking for everything
> As I pointed out earlier, some of the heat here comes > from the fact that /bin/sh is currently overloaded: > > * It is the default system script interpreter, used >by the rc scripts and many other things. As such, >it must start quickly. > > * It is the default user shell for many users. As such, >it must support NSS. > > So far, I haven't seen anyone in this thread seriously > argue against either of these points. I'll seriously argue against the 2nd point above. I don't know of a SINGLE person that uses /bin/sh as their interactive shell when multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses Bash, AT&T ksh, pdksh, zsh. > Richard Coleman wrote: > >It seems /bin/sh is the real sticking point. > > There is a problem here: Unix systems have historically used > /bin/sh for two somewhat contradictory purposes: > * the system script interpreter > * as a user shell > > The user shell must be dynamically linked in order > to support centralized administration. I personally > see no way around that. Given that many users do > rely on /bin/sh, it seems that /bin/sh must be > dynamically linked. > > There are good reasons to want the system script > interpreter statically linked. > > Maybe it's time to separate these two functions? I argue the two functions are already separated as /bin/sh as interactive shell doesn't really exist outside of single user. We should build /bin/sh static and be done with the argument. Or rather, lets find a /bin/sh interactive user and have him argue that /bin/sh needs NSS support. I dare say that will be a thread two orders of magnitude shorter than this one. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
repeatable panic with truss
Hello, While running the next commands on the attached program I get a panic everytime. gcc rfk-smtpd.c truss ./a.out cat --panic-- Running 5.1-CURRENT from today. I did a 'make world' in a clean /usr/obj dir. System P-II 400Mhz UP, 256 MB, IDE, no acpi enabled. I hope somebody can repeat this and maybe it helps getting FreeBSD more and more stable. (Or maybe it's a known issue.) Ronald. PS: I don't have a debugger enabled kernel, so can't give any more output for now. But I'm willing to make one if it's needed. -- Ronald Klop Amsterdam, The Netherlands rfk-smtpd.c Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATAng lockups (Re: geom<->ata forever cycle)
Sat, Nov 22, 2003 at 13:08:10, netch (Valentin Nechayev) wrote about "geom<->ata
forever cycle":
VN> 5.1-current of 2003-11-20 hangs during kernel initialization with forever
VN> cycle around geom partitioning detection and ATA read failure.
VN> Message rate is too fast to record, no stopping is available, no serial
VN> console.
VN> Previous 5-current on this machine was of 2003-05-23.
VN> How to diagnose?
Well, I restricted time interval to between 2003-08-18 and 2003-08-25, so it is
ATAng. Also tested 2003-11-20 and 2003-10-06 with the same result.
Different poses were seen:
- forever cycle around GEOM detecting
- simple lockup
- panic("initiate_write_inodeblock_ufs1: already started")
- another kinds of panic
and all have common sign - impossibility of driver to dig itself out of
lockup (switch to PIO, reset bus, etc.)
Dirty fix works to set hw.ata.ata_dma=0 in loader; moreover, `atacontrol
mode 1 udma100 -' doesn't cause problems, but `atacontrol mode 0 udma33 -'
drops system to broken state in a few minutes.
Please say how to dig this problem.
Full verbose dmesg.boot (from 2003-08-18 kernel) and config (unchanged)
was put in previous letters and can be resent personally.
Entries, bound with ATA, in first problematic (2003-08-25) dmesg.boot:
pcib0: at pcibus 0 on motherboard
atapci0: port 0xf000-0xf00f at device 31.1 on pci0
ata0: pre reset mask=03 ostat0=50 ostat2=00
ata0-master: ATAPI 00 00
ata0-slave: ATAPI 14 eb
ata0: after reset mask=03 stat0=50 stat1=00
ata0-master: ATA 01 a5
ata0: devices=09
ata0: at 0x1f0 irq 14 on atapci0
ata0-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin
ata0-master: pio=0x0c wdma=0x22 udma=0x44 cable=40pin
ad0: setting PIO4 on Intel ICH2 chip
ad0: ATA-4 disk at ata0-master
ad0: 14664MB (30033360 sectors), 29795 C, 16 H, 63 S, 512 B
ad0: 16 secs/int, 1 depth queue, PIO4
acd0: setting PIO4 on Intel ICH2 chip
acd0: CDROM drive at ata0 as slave
acd0: read 6890KB/s (6890KB/s), 128KB buffer, PIO4
(remind that it is with hw.ata.ata_dma=0)
-netch-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
David O'Brien wrote: We should build /bin/sh static and be done with the argument. Or rather, lets find a /bin/sh interactive user and have him argue that /bin/sh needs NSS support. I dare say that will be a thread two orders of magnitude shorter than this one. Statically linking /bin/sh wouldn't be that big a deal. It would be trivial to add a port to compile a dynamic version of sh for customers that *really* want sh. Personally, I can't remember a customer specifically requesting that. You would need to make sure that startup scripts never use tilde expansion. I'm not sure how common that is with RCNG. But it would be sorta odd to have statically linked versions of sh in both /bin and /rescue. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
null_lookup() vnode locking wierdness
I was trying to figure out why the VOP_UNLOCK() call in null_lookup()
was violating a vnode locking assertion, so I tossed a bunch of
ASSERT_VOP_LOCKED() calls into null_lookup(). I found something I don't
understand ...
ASSERT_VOP_LOCKED(dvp, "null_lookup 1");
if ((flags & ISLASTCN) && (dvp->v_mount->mnt_flag & MNT_RDONLY) &&
(cnp->cn_nameiop == DELETE || cnp->cn_nameiop == RENAME))
return (EROFS);
/*
* Although it is possible to call null_bypass(), we'll do
* a direct call to reduce overhead
*/
ASSERT_VOP_LOCKED(dvp, "null_lookup 2");
ldvp = NULLVPTOLOWERVP(dvp);
ASSERT_VOP_LOCKED(dvp, "null_lookup 3");
vp = lvp = NULL;
error = VOP_LOOKUP(ldvp, &lvp, cnp);
ASSERT_VOP_LOCKED(dvp, "null_lookup 4");
if (error == EJUSTRETURN && (flags & ISLASTCN) &&
(dvp->v_mount->mnt_flag & MNT_RDONLY) &&
(cnp->cn_nameiop == CREATE || cnp->cn_nameiop == RENAME))
error = EROFS;
/*
* Rely only on the PDIRUNLOCK flag which should be carefully
* tracked by underlying filesystem.
*/
if (cnp->cn_flags & PDIRUNLOCK)
VOP_UNLOCK(dvp, LK_THISLAYER, td);
The null_lookup {1,2,3} assertions pass, but null_lookup 4 fails. It
appears that the VOP_LOOKUP() call to the underlying file system is
unlocking the directory vnode in the nullfs file system. How can that
happen?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
From: "David O'Brien" <[EMAIL PROTECTED]> > I'll seriously argue against the 2nd point above. I don't know of a > SINGLE person that uses /bin/sh as their interactive shell when > multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses > Bash, AT&T ksh, pdksh, zsh. I don't know anyone that farms lama's, so there cannot be any lama farmers. computer$ grep dmlb /etc/passwd dmlb:*:1166:1166:Duncan Barclay:/home/dmlb:/bin/sh Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: null_lookup() vnode locking wierdness
On 23 Nov, I wrote:
> I was trying to figure out why the VOP_UNLOCK() call in null_lookup()
> was violating a vnode locking assertion, so I tossed a bunch of
> ASSERT_VOP_LOCKED() calls into null_lookup(). I found something I don't
> understand ...
>
> ASSERT_VOP_LOCKED(dvp, "null_lookup 1");
> if ((flags & ISLASTCN) && (dvp->v_mount->mnt_flag & MNT_RDONLY) &&
> (cnp->cn_nameiop == DELETE || cnp->cn_nameiop == RENAME))
> return (EROFS);
> /*
> * Although it is possible to call null_bypass(), we'll do
> * a direct call to reduce overhead
> */
> ASSERT_VOP_LOCKED(dvp, "null_lookup 2");
> ldvp = NULLVPTOLOWERVP(dvp);
> ASSERT_VOP_LOCKED(dvp, "null_lookup 3");
> vp = lvp = NULL;
> error = VOP_LOOKUP(ldvp, &lvp, cnp);
> ASSERT_VOP_LOCKED(dvp, "null_lookup 4");
> if (error == EJUSTRETURN && (flags & ISLASTCN) &&
> (dvp->v_mount->mnt_flag & MNT_RDONLY) &&
> (cnp->cn_nameiop == CREATE || cnp->cn_nameiop == RENAME))
> error = EROFS;
>
> /*
> * Rely only on the PDIRUNLOCK flag which should be carefully
> * tracked by underlying filesystem.
> */
> if (cnp->cn_flags & PDIRUNLOCK)
> VOP_UNLOCK(dvp, LK_THISLAYER, td);
>
> The null_lookup {1,2,3} assertions pass, but null_lookup 4 fails. It
> appears that the VOP_LOOKUP() call to the underlying file system is
> unlocking the directory vnode in the nullfs file system. How can that
> happen?
I think I just answered my own question. It appears that both vnodes
can share the same lock according to the following code fragment in
null_nodeget():
/*
* From NetBSD:
* Now lock the new node. We rely on the fact that we were passed
* a locked vnode. If the lower node is exporting a struct lock
* (v_vnlock != NULL) then we just set the upper v_vnlock to the
* lower one, and both are now locked. If the lower node is exporting
* NULL, then we copy that up and manually lock the new vnode.
*/
vp->v_vnlock = lowervp->v_vnlock;
error = VOP_LOCK(vp, LK_EXCLUSIVE | LK_THISLAYER, td);
It looks like the easiest fix is to skip the VOP_UNLOCK() call in
null_lookup() if dvp->v_vnlock == ldvp->v_vnlock.
Index: sys/fs/nullfs/null_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/nullfs/null_vnops.c,v
retrieving revision 1.63
diff -u -r1.63 null_vnops.c
--- sys/fs/nullfs/null_vnops.c 17 Jun 2003 08:52:45 - 1.63
+++ sys/fs/nullfs/null_vnops.c 24 Nov 2003 00:10:41 -
@@ -392,7 +392,7 @@
* Rely only on the PDIRUNLOCK flag which should be carefully
* tracked by underlying filesystem.
*/
- if (cnp->cn_flags & PDIRUNLOCK)
+ if ((cnp->cn_flags & PDIRUNLOCK) && dvp->v_vnlock != ldvp->v_vnlock)
VOP_UNLOCK(dvp, LK_THISLAYER, td);
if ((error == 0 || error == EJUSTRETURN) && lvp != NULL) {
if (ldvp == lvp) {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em0 on install
trying to install using the 5.1-release mini cd and em0. it seems not to dhcp (looked with tcpdump) despite my saying Yes (and no to ipv6). am i missing a clue? randy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-BETA lockup
On Sun, 23 Nov 2003, Matt Smith wrote: > Since updating two of my machines to the latest HEAD I am experiencing a > total lockup on one of them. > > After being booted for approx 3 minutes the machine stops responding > completely. It doesn't panic or drop into DDB. The numlock key doesn't > toggle the keyboard light, and I can't drop it into DDB manually. > > I have full debugging options compiled in to this kernel as per the > usual -CURRENT GENERIC file. > > It's currently booted with the older kernel from the 16th and this is > stable as a rock. > > Anything else I can do to find the problem out or workaround it > considering it just hangs? > > The machine is a router running two 3com network cards (xl) and > IPFW/natd. It also has IPV6 with IP6FW, and a gif tunnel. Any chance you could hook up a serial console, set BREAK_TO_DEBUGGER in kernel options, and see if a serial break drops you to DDB over serial? Under some circumstances a serial break can be more effective getting into the debugger than a console break. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 on install
Randy Bush wrote: trying to install using the 5.1-release mini cd and em0. it seems not to dhcp (looked with tcpdump) despite my saying Yes (and no to ipv6). am i missing a clue? Not plugged in to a Cisco switch, are you? -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
> > So far, I haven't seen anyone in this thread seriously > > argue against either of these points. > > I'll seriously argue against the 2nd point above. I don't know of a > SINGLE person that uses /bin/sh as their interactive shell when > multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses > Bash, AT&T ksh, pdksh, zsh. > I'm one... I have to operate on many disparate systems with the same home directory some of the bourne-shell variants (e.g. HP/UX's ksh) will lock-up on my simple bourne-shell .profile. So - I stick with the "plain/old/boring" sh. - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libutil.so version bumped, but no compat lib yet
Dimitry Andric wrote: After rebuilding a -CURRENT box today and removing some old cruft, as I usually do, I noticed that libutil.so had been bumped to version 4, although there wasn't any version 3 in /usr/lib/compat yet. This bump was done quite recently, Wed Nov 12 21:56:07 2003 UTC. I'm not sure if it was an oversight to leave out installing a compat lib, or is the policy in this case "just rebuild almost all your ports, this is -CURRENT, after all" ? :) (It turns out that quite a lot of them depend on libutil.so.3 ...) If it's needed, I'll shoot in a nice PR. There's probably a good copy of a libutil.so.3 binary to be found on the 5.1-RELEASE CD, or else I'll just keep using my old one. :) Yes, this was an oversight. I'll look into fixing it tonight. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mbrlen() vs. compatibility with -STABLE-compiled ports
Perhaps it's unrealistic to expect this to work, but on each of the machines where I run -CURRENT, I also run -STABLE (on other slices), but I generally only build ports under -STABLE, and /usr/local is common to both the -CURRENT and -STABLE environments. (I build -CURRENT with "COMPAT4X= yes" specified in /etc/make.conf.) And in practice, this has generally worked rather well (with only a couple of exceptions over the couple of years I've been doing this), while I've been tracking each of -STABLE and -CURRENT (and doing a "portupgrade -a" under -STABLE) on a daily basis. Thus, I had some reason to believe that the setup was testing how well the compatibility code was working. After recovering from a series of misadventures (-CURRENT challenges from recent statfs changes; hardware issues on the machines [warranty repair for the laptop; reset BIOS to get proper CPU timing on the SMP "build" machine]), I think my environment is back to what passes for "normal" around here: I was able to build today's -CURRENT OK while running yesterday's -CURRENT in multi-user mode (in the case of the laptop, while running X; the build machine generally runs headless). And I apologize: this turned out to be rather longer than I intended. Since -CURRENT is now 5.2-BETA, I thought it might be worth reporting what appears to be a problem with the compatibility code. I am, however, no expert on the mechanisms by which this works, so I'll try to confine my comments to what I actually observe (and immediately-derivable conclusions). First, a little more background: I recently had occasion to augment my collection of installed ports to include mod_php4-4.3.4_2,1. (I run the apache-1.3.29_1 Web server on each of the machines in question.) As mentioned above, this was built under -STABLE. And it appears to work. When I boot -CURRENT: g1-15(5.2)[5] uname -a FreeBSD g1-15.catwhisker.org 5.2-BETA FreeBSD 5.2-BETA #1: Sun Nov 23 11:49:39 PST 2003 [EMAIL PROTECTED]:/common/S2/obj/usr/src/sys/LAPTOP_30W i386 g1-15(5.2)[6] I see in the console log: Nov 23 15:11:53 localhost kernel: Starting cron. Nov 23 15:11:53 localhost kernel: Local package initialization: Nov 23 15:11:53 localhost kernel: Setting the mixer vol from 75:75 to 25:25. Nov 23 15:11:54 localhost kernel: Syntax error on line 237 of /usr/local/etc/apache/httpd.conf: Nov 23 15:11:54 localhost kernel: Cannot load /usr/local/libexec/apache/libphp4.so into server: /usr/lib/libhistory.so.4: Undefined symbol "mbrlen" Nov 23 15:11:54 localhost kernel: Starting snmpd. Nov 23 15:12:16 localhost kernel: . The message in question is the whine about mbrlen(). I'll point out now (in case it isn't obvious) that when this set of messages is issued, apache does not start. As to the cause of the whine: g1-15(5.2)[4] ls -l libhistory* compat/libhist* -r--r--r-- 1 root wheel 20351 Nov 23 12:25 compat/libhistory.so.3 -r--r--r-- 1 root wheel 31362 Nov 23 12:27 libhistory.a lrwxrwxr-x 1 root wheel 15 Nov 23 12:27 libhistory.so -> libhistory.so.4 -r--r--r-- 1 root wheel 25156 Nov 23 12:27 libhistory.so.4 -r--r--r-- 1 root wheel 32234 Nov 23 12:27 libhistory_p.a g1-15(5.2)[5] nm -D libhistory.so.4 | grep -iC mbrlen U malloc 6d7c B max_input_history U mbrlen U mbrtowc 5190 T next_history g1-15(5.2)[6] nm -D libc.so | grep -iC mbrlen 0003a3b0 T mblen 0003a2b0 T mbmb 00053230 T mbrlen 0003a230 T mbrrune 0009b6f0 T mbrtowc g1-15(5.2)[7] The above is from the usual -CURRENT environment. Now, comparing that with -STABLE: g1-15(5.2)[1] sudo mount -o ro /S1 Password: g1-15(5.2)[2] sudo mount -o ro /S1/usr g1-15(5.2)[3] cd !$/lib cd /S1/usr/lib g1-15(5.2)[4] ls -l libhistory* compat/libhist* -r--r--r-- 1 root wheel 20351 Nov 23 07:29 compat/libhistory.so.3 -r--r--r-- 1 root wheel 24518 Nov 23 07:30 libhistory.a lrwxrwxr-x 1 root wheel 15 Nov 23 07:30 libhistory.so -> libhistory.so.4 -r--r--r-- 1 root wheel 19452 Nov 23 07:30 libhistory.so.4 -r--r--r-- 1 root wheel 26520 Nov 23 07:30 libhistory_p.a g1-15(5.2)[5] nm -D libhistory.so.4 | grep -iC mbrlen g1-15(5.2)[6] nm -D libc.so.4 | grep -iC mbrlen g1-15(5.2)[7] We see that libc.so.4 does not have mbrlen(), but libc.so.5 does. So far, so good. Also, libhistory.so.4 built under -CURRENT contains a reference to mbrlen(), while libhistory.so.4 built under -STABLE does not. Since -STABLE's libc doesn't have a mbrlen(), but -CURRENT's does, that makes a certain amount of sense; on the other hand, in some cases (such as the present instance) this causes a problem. As I built apache under -STABLE, it references libc.so.4: g1-15(5.2)[8] ldd `which httpd` /usr/local/sbin/httpd: libcrypt.so.2 => /lib/libcrypt.so.2 (0x280a1000) libexpat.so.4 => /usr/local/lib/libexpat.so.4 (0x280ba000) libc.so.4 => /usr/lib/compat/libc.so.4 (0x280d6000) g1-15(5.2)[9] so when run under -CURRENT, it is the "compatibility" version of libc.so.4 that is
Re: PII SMP system hangs during boot with ACPI enabled
No way! Good (non-386) equipment is never to old. :) Please add debug.acpi.disable="cpu" to loader.conf or type that in at the loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup path. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 on install
>> trying to install using the 5.1-release mini cd and em0. it seems not >> to dhcp (looked with tcpdump) despite my saying Yes (and no to ipv6). >> am i missing a clue? > Not plugged in to a Cisco switch, are you? gawd no! you would even suggest such a thing in public? sheesh! :-) this is a thinkpad t40p. 4.9-release cdrom boots through to em0 media just fine, and i just retested that assertion without moving any wires etc. i tried booting wigh acpi off. no change. it stalls scanning for dhcp servers, which do exist, and then puts up the NetworkConfiguration menu. if i say no to dhcp and hand configure, no packets leave the interface. randy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Mon, Nov 24, 2003 at 12:14:39AM -, Duncan Barclay wrote: > > From: "David O'Brien" <[EMAIL PROTECTED]> > > > I'll seriously argue against the 2nd point above. I don't know of a > > SINGLE person that uses /bin/sh as their interactive shell when > > multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses > > Bash, AT&T ksh, pdksh, zsh. > > I don't know anyone that farms lama's, so there cannot be any lama farmers. One has to make a strong statement to get the people to come out of the woodwork. > computer$ grep dmlb /etc/passwd > dmlb:*:1166:1166:Duncan Barclay:/home/dmlb:/bin/sh Good. Now do you need NSS support? Do the benefits of supporting NSS in /bin/sh for you out-weigh the performance issue of building it dynamically? Couldn't you just as easily use the pdksh port? -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Sun, Nov 23, 2003 at 06:27:01PM -0500, Richard Coleman wrote: > But it would be sorta odd to have statically linked versions of sh in > both /bin and /rescue. We'd remove it from /rescue if the /bin/sh one was static. :-) -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
At 5:22 PM -0800 2003/11/22, David O'Brien wrote:
Please, NO. There wasn't an FTP client available for this type of
recovery pre-/rescue, there shouldn't be one now.
"This type of recovery" (repairing a system with a trashed /bin)
wasn't possible at all pre-/rescue. Had it been possible, /rescue
wouldn't be needed.
Bruce M Simpson wrote:
I think David has valid concerns here about feeping creaturism. fetch
has a whole load of library dependencies which go with it, making it
unsuitable for inclusion in /rescue in the base system.
Fetch requires libfetch (45k). I've not tested, but I expect
it adds less than 64k to /rescue.
Scenarios that require /rescue are ones in which /bin and /sbin
are unusable, which is almost always going to imply a trashed file
in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to
involve locating a good copy of a trashed file to replace a damaged
local copy.
I can only think of a few places where that "good copy"
can come from:
* CDROM: requires a CD-ROM drive, and a suitable CD.
* floppy: requires a floppy drive
* NFS: requires a local network and an NFS server
* An HTTP or FTP server: requires a network connection and 'fetch.'
I don't think we can safely assume that everyone has access to
one of the first three options here.
Given the choice between 'vi' and 'fetch,' I'd definitely
choose the latter. ('vi' is useful for repairing config files;
errors in config files are not generally going to break /bin.)
I don't see fetch as a requirement for diskless clients.
This is a red herring: diskless clients don't need /rescue since
any "recovery" necessary can be done on the server. Whether or
not diskless clients require fetch has therefore no bearing at
all on the question of whether fetch should be in /rescue.
Tim Kientzle
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 on install
> >> trying to install using the 5.1-release mini cd and em0. it seems not > >> to dhcp (looked with tcpdump) despite my saying Yes (and no to ipv6). > >> am i missing a clue? [snip] > this is a thinkpad t40p. 4.9-release cdrom boots through to em0 > media just fine, and i just retested that assertion without moving > any wires etc. I have seen this on the T40p. The "solution" is to disable the cardbus support. I have detailed my experience with this laptop at http://www.scode.org/freebsdt40p.html The relevant part is this: "The gigabit ethernet interface - em0 - worked perfectly during installation. When I booted the resulting system however, it no longer worked. The driver failed to load properly during boot with an error regarding the EEPROM checksum being invalid. I found this post which indicated the em0 driver "broke" support on the X31 somewhere between 5.0-RELEASE and 5.1-RELEASE. I tried using the old 5.0 driver in 5.1, aswell as removing the checksum check in the 5.1 driver. No luck. I eventually figured out that the pcmcia support seemed to break just about everything, including the em driver. When the cardbus bridge (cdb) was commented out in the kernel configuration, em0 suddenly worked perfectly. So basically, a good idea in general is to strip down unused stuff in the kernel configuration, but specifically the cardbus bridge. " This is the post referenced in the above paragraph: http://lists.freebsd.org/pipermail/freebsd-i386/2003-June/47.html (note: i'm not on -current, so please CC any responses that are meant for me to respond to, thanks!) -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Results: Dell Inspiron 8600
Hi, got a new Dell Inspiron 8600 today and here is the run-down for people looking to buy one: * 5.1-RELEASE does not have the bfe ethernet driver. -CURRENT does, which leaves you with 3 options: * have a wireless connection available, cause the firewire nic is recognized * use a bootcd from a more recent version * install 5.1-RELEASE and use the cd drive to copy over /usr/src from another machine * CURRENT also fixes a bug in acpi which you may see in 5.1-RELEASE, recognizable by the "Attempt to allocate zero bytes" message in ut_allocate * If you're going to run X, you're looking for this, in the 'Monitor' section: HorizSync 30-120 Option "IgnoreEDID" "true" # not sure this affects anything VertRefresh 40 # wxga format display (one line) Modeline "1280x800"108.00 1280 1376 1488 1800800 801 804 1500 +hsync +vsync Open issues: * no /dev/apmctl: Nov 24 01:25:37 sarevok root: /etc/rc: WARNING: /dev/apmctl not found; kernel is missing apm(4) $ ls -al /dev/apm* crw-rw-r-- 1 root operator 39, 0 Nov 24 01:25 /dev/apm $ grep apmctl /sys/conf/NOTES /sys/i386/conf/LINT | wc -l 0 As a result apmd does not start * APM Capabilities reports 'unknown' * nv driver from XFree86-4-Server makes screen unusable after exit. Messages on the XFree86-4 list suggest that driver does a better job, so I'm gonna try it. Small issue: Running mplayer to play a DVD still has a lot of 'black' stripes on top and bottom. In theory, it should not be more than 40 pixels each (1280x720 == 16:9 vs. 1280x800 screen res), but it's way more than that. All in all: a good result. -- Melvyn === FreeBSD sarevok.idg.nl 5.2-BETA FreeBSD 5.2-BETA #2: Sun Nov 23 15:02:26 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAREVOK i386 === ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 on install
Randy Bush wrote: trying to install using the 5.1-release mini cd and em0. it seems not to dhcp (looked with tcpdump) despite my saying Yes (and no to ipv6). am i missing a clue? Not plugged in to a Cisco switch, are you? gawd no! you would even suggest such a thing in public? sheesh! :-) I forgot to add the :) at the end.. it was meant as a joke.. :) -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Mon, 24 Nov 2003, Duncan Barclay wrote: > >From: "David O'Brien" <[EMAIL PROTECTED]> > >> I'll seriously argue against the 2nd point above. I don't know of a >> SINGLE person that uses /bin/sh as their interactive shell when >> multi-user. Not ONE. Every Bourne shell'ish user I've ever met uses >> Bash, AT&T ksh, pdksh, zsh. > >I don't know anyone that farms lama's, so there cannot be any lama farmers. > >computer$ grep dmlb /etc/passwd >dmlb:*:1166:1166:Duncan Barclay:/home/dmlb:/bin/sh > >Duncan So, imagine, i'm accidentally deleted /bin with your most wanted static sh... And, of course, due to static nature of /bin/sh it was removed from /rescue? Nothing will protect you from shooting in the leg, neither static linking, nor assumption that /lib is OK. MOST people uses /bin/sh only for rc scripts (to be correct, their system uses it). David O'Brien just tried to told, that NOBODY he knows will be REALLY impacted by performance loss, caused due dynamic /bin/sh linking. You will... So, because Duncan Barclay is impacted by performance loss due dynamic /bin/sh linking, ENTIRE FreeBSD community will have troubles (at least with NSS) due to static linking... Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
>Date: Mon, 24 Nov 2003 09:34:08 +0600 (NOVT) >From: "Maxim M. Kazachek" <[EMAIL PROTECTED]> > So, imagine, i'm accidentally deleted /bin with your most wanted >static sh... And, of course, due to static nature of /bin/sh it was >removed from /rescue? Nothing will protect you from shooting in the leg, >neither static linking, nor assumption that /lib is OK. So go ahead and make /bin/sh also have a (hard) link to /rescue/sh. Then the referenced action merely decrements the link count, and the executable itself doesn't go away. Sure, you could be more imaginative with foot-shooting, but the stated problem is really easy to avoid. Peace, david (reluctant to contribute to this thread) -- David H. Wolfskill [EMAIL PROTECTED] If you want true virus-protection for your PC, install a non-Microsoft OS on it. Plausible candidates include FreeBSD, Linux, NetBSD, OpenBSD, and Solaris (in alphabetical order). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Sun, 23 Nov 2003, David Wolfskill wrote: >>Date: Mon, 24 Nov 2003 09:34:08 +0600 (NOVT) >>From: "Maxim M. Kazachek" <[EMAIL PROTECTED]> > >> So, imagine, i'm accidentally deleted /bin with your most wanted >>static sh... And, of course, due to static nature of /bin/sh it was >>removed from /rescue? Nothing will protect you from shooting in the leg, >>neither static linking, nor assumption that /lib is OK. > >So go ahead and make /bin/sh also have a (hard) link to /rescue/sh. >Then the referenced action merely decrements the link count, and the >executable itself doesn't go away. > >Sure, you could be more imaginative with foot-shooting, but the stated >problem is really easy to avoid. > >Peace, >david (reluctant to contribute to this thread) >-- >David H. Wolfskill [EMAIL PROTECTED] >If you want true virus-protection for your PC, install a non-Microsoft OS >on it. Plausible candidates include FreeBSD, Linux, NetBSD, OpenBSD, and >Solaris (in alphabetical order). I'm a real masochist, and removed /rescue/sh /sbin/sh whatsoever. And after that will begin complain, that FreeBSD is ugly, non bullet-proof operating system... :-) But, in fact, as I can remember, all /rescue stuff is one hadlinked executable. I don't think that hardlinking /bin/sh into /rescue would be nice idea... IMHO it's not clear. Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: localhost adress
On Sun, Nov 23, 2003 at 01:33:33PM +0200, Adrian Penisoara wrote: > Maybe the latest commit by 'tmm' fixes it: This appears to fix the reported issue. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sun, Nov 23, 2003 at 02:42:58AM +0100, Brad Knowles wrote: > At 5:22 PM -0800 2003/11/22, David O'Brien wrote: > > > Please, NO. There wasn't an FTP client available for this type of > > recovery pre-/rescue, there shouldn't be one now. > > Why? Why cut your nose off to spite your face? Even though this > capability may not have existed before, why shouldn't we have it now? I think David has valid concerns here about feeping creaturism. fetch has a whole load of library dependencies which go with it, making it unsuitable for inclusion in /rescue in the base system. If you want access to fetch early on in this way, you could make a local branch and maintain the change for your own site, or you could boot from a FreeBSD live CD, or use sysinstall from the installation CD to install a package. I don't see fetch as a requirement for diskless clients. Regards, BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0 on install
[ for the archive ] >>> trying to install using the 5.1-release mini cd and em0. it seems not >>> to dhcp (looked with tcpdump) despite my saying Yes (and no to ipv6). >>> am i missing a clue? >> Not plugged in to a Cisco switch, are you? > gawd no! you would even suggest such a thing in public? sheesh! :-) > > this is a thinkpad t40p. 4.9-release cdrom boots through to em0 > media just fine, and i just retested that assertion without moving > any wires etc. > > i tried booting wigh acpi off. no change. > > it stalls scanning for dhcp servers, which do exist, and then puts > up the NetworkConfiguration menu. if i say no to dhcp and hand > configure, no packets leave the interface. when cdrom boot gives you chuckie's boot menu, choose the loader prompt (7). then tell it OK hw.pci.allow_unsupported_io_range="1" OK boot to let the boot continue. randy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
atacontrol(8) not yielding any output
Hi all, kimchi# uname -a FreeBSD kimchi.dek.spc.org 5.2-BETA FreeBSD 5.2-BETA #4: Sun Nov 23 01:52:10 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KIMCHI i386 atacontrol doesn't report any devices. Using commands such as cap/info/list don't yield anything at all. Perhaps more worrying:- kimchi# atacontrol mode 0 atacontrol: ioctl(ATAGMODE): Device not configured The disk and cd themselves are present in dmesg during boot. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: null_lookup() vnode locking wierdness
On Sun, Nov 23, 2003 at 04:16:10PM -0800, Don Lewis wrote: > On 23 Nov, I wrote: > > I was trying to figure out why the VOP_UNLOCK() call in null_lookup() > > was violating a vnode locking assertion, so I tossed a bunch of > > ASSERT_VOP_LOCKED() calls into null_lookup(). I found something I don't > > understand ... > > > It looks like the easiest fix is to skip the VOP_UNLOCK() call in > null_lookup() if dvp->v_vnlock == ldvp->v_vnlock. Yes, this seems to be correct and necessary addition. At first sight, the later code shouldn't blow because of that. BTW, buildworld -jN on top of the null mount together with another buildword -jN on the underlying file system helps a lot to discover vnode locking problems. -- Boris Popov http://rbp.euro.ru ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
