Re: Email being rejected
On Wed, 7 Mar 2001, Gregory Neil Shapiro wrote: root I am using the standard freebsd.mc created during a buildworld. I root have started noticing that I am missing/rejecting a lot of emails root from places like: yahoogroups.com. It would be helpful to show the actual log message so we can determine why it is being rejected. If it is something like: Mar 7 18:45:51 horsey sendmail[69643]: f282jdlg069643: ruleset=check_mail, arg1=[EMAIL PROTECTED], [EMAIL PROTECTED] [10.0.1.1], reject=501 5.1.8 [EMAIL PROTECTED]... Domain of sender address [EMAIL PROTECTED] does not exist Yes, that is it. I actually started noticing the problem in my email for the daily (nightly) run. I went to look in the maillog, however, and that is the essence of the error (I think the PID might have been different ;). Then at the time the mail came in, yahoogroups.com was not resolvable. You can check with: nslookup -q= yahoogroups.com. nslookup -q=A yahoogroups.com. nslookup -q=MX yahoogroups.com. I did this and it does resolve for that one, but it doesn't for an ISP that one of my clients is trying to receive an email from. I emailed the owner of the ISP who promptly informed me that you should never setup an IP for your domain name, just for things like the www.hisname.org ;). However, the MX does (and has all along) resolved for his domain. I thought sendmail would do the DNS lookup/RDNS double-check thing for the MX machine instead of the origination machine, which was why I was so confused. root I have been looking in the sendmail config stuff, and I have not yet root figured out what rule I would need to change, but I need it fixed root soon, customers are complaining. I think what needs to be done is root add a rule that says (if it is a TLD, go ahead and accept it). And, root yes, I realize that means I will get a lot of emails from places root like: akjasdkfhaskhdf.com, but a "whois" lookup would be WAY TOO root SLOW. From /usr/share/sendmail/cf/README: FEATURE(accept_unresolvable_domains) Normally, MAIL FROM: commands in the SMTP session will be refused if the host part of the argument to MAIL FROM: cannot be located in the host name service (e.g., an A or MX record in DNS). If you are inside a firewall that has only a limited view of the Internet host name space, this could cause problems. In this case you probably want to use this feature to accept all domains on input, even if they are unresolvable. Saw this, and didn't like the sound of it one darn bit. I am on a ATT T1, which has been extremely reliable, and have never (that I know of) had problems resolving names unless the other persons bind or connection to the net is shakey. ... An ``access'' database can be created to accept or reject mail from selected domains. For example, you may choose to reject all mail originating from known spammers. To enable such a database, use FEATURE(`access_db') ... OK Accept mail even if other rules in the running ruleset would reject it, for example, if the domain name is unresolvable. Okay, just call me stupid :). I use this feature already to allow relays from/to my various domain names, reject email from spammers, etc. I can even control it directly from webmin instead of looking at all those strange rules in the .cf file. thanks, - brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tape device names and devfs
On Wed, Mar 07, 2001 at 08:50:23PM +1100, Bruce Evans wrote: dump.8 and dump(8) both refer explicitly to nsa0 and nrsa0 whereas sa0 and nsa0 are the actual device names in -current. The dump sources also refer to only the 'r' devices (_PATH_DEFTAPE is still "/dev/rsa0"). Fixed. :-) -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic mounting msdos fs
Yesterday -current: # mount /msdos Acquring duplicate lock of same type: "lockmgr interlock" 1st @ ../../kern/kern_lock.c:239 2nd @ ../../kern/kern_lock.c:239 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc015c3f5 stack pointer = 0x10:0xc7821ce4 frame pointer = 0x10:0xc7821cf0 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 = 489 (mount_msdos) kernel: type 12 trap, code=0 Stopped at witness_exit+0x23d: movl%eax,0(%edx) db I am attaching output of a few "show" commands from debug... -- Weird enough for government work. trace witness_exit(c780634c,0,c024085a,f1,c780634c,1,c024085a,f1) at witness_exit+0x23d lockmgr(c780637c,1010002,c780634c,c77a3980,c7821d70) at lockmgr+0xf5 vop_stdlock(c7821d60) at vop_stdlock+0x1f vn_lock(c78062e0,10002,c77a3980,c780634c,c0e8fb80) at vn_lock+0x186 vget(c78062e0,10002,c77a3980,c0df1400,4) at vget+0x109 msdosfs_hashget(c0da7600,0,1fff,c7806760,4) at msdosfs_hashget+0x11b deget(c0ea7000,0,1fff,c7821e1c,17d) at deget+0x41 msdosfs_root(c0df1400,c7821e4c) at msdosfs_root+0x20 vfs_mount(c77a3980,c0d7db40,c0e8fc00,0,bfbff8e8) at vfs_mount+0xc40 mount(c77a3980,c7821f80,bfbffd94,bfbffcc0,0) at mount+0x6a syscall(2f,2f,2f,0,bfbffcc0) at syscall+0x6b1 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b db show mu registers cs 0x8 ds0x10 es0x10 fs0x18 ss0x10 eax 0xc02ade20 Giant ecx 0xc0e7f040 edx 0 ebx 0xc780634c esp 0xc7821ce4 ebp 0xc7821cf0 esi 0 edi 0xc0294ed8 w_data+0x1518 eip 0xc015c3f5 witness_exit+0x23d efl0x10282 witness_exit+0x23d: movl%eax,0(%edx) db show mutexes "lockmgr interlock" (0xc05a8ef0) locked at ../../kern/kern_lock.c:239 "Giant" (0xc02ade20) locked at ../../i386/i386/trap.c:1169 db who show witness Sleep mutexes: 0 rman head -- last acquired @ ../../kern/subr_rman.c:107 0 sf_bufs list lock -- last acquired @ ../../kern/uipc_syscalls.c:1437 0 vm86pcb lock -- last acquired @ ../../i386/i386/vm86.c:579 0 Giant -- last acquired @ ../../i386/i386/trap.c:1169 1 mbuf free list lock -- last acquired @ ../../kern/uipc_mbuf.c:591 1 vnode pollinfo -- last acquired @ ../../kern/vfs_subr.c:2761 1 vm object_list -- last acquired @ ../../vm/vm_object.c:456 1 ip_inq -- last acquired @ ../../netinet/ip_input.c:817 1 arp_inq -- last acquired @ ../../netinet/if_ether.c:446 1 eventhandler -- last acquired @ ../../kern/subr_eventhandler.c:76 3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:765 7malloc -- last acquired @ ../../kern/kern_malloc.c:317 7uidinfo struct -- last acquired @ ../../kern/kern_resource.c:782 4 lockmgr -- last acquired @ ../../kern/kern_lock.c:505 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:765 7malloc -- last acquired @ ../../kern/kern_malloc.c:317 7uidinfo struct -- last acquired @ ../../kern/kern_resource.c:782 1 zone subsystem -- last acquired @ ../../vm/vm_zone.c:422 3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:765 7malloc -- last acquired @ ../../kern/kern_malloc.c:317 7uidinfo struct -- last acquired @ ../../kern/kern_resource.c:782 3zone -- last acquired @ ../../vm/vm_zone.c:366 4 lockmgr -- last acquired @ ../../kern/kern_lock.c:505 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:765 7malloc -- last acquired @ ../../kern/kern_malloc.c:317 7uidinfo struct -- last acquired @ ../../kern/kern_resource.c:782 1 bpf interface lock -- last acquired @ ../../net/bpf.c:1070 2 bpf1 -- last acquired @ ../../net/bpf.c:1074 2 bpf0 -- last acquired @ ../../net/bpf.c:1074 3lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239 5 process lock -- last acquired @ ../../i386/i386/trap.c:880 6 ucred -- last acquired @ ../../kern/kern_prot.c:1177 6 uidinfo hash -- last acquired @
Perl bootstraping issues (updated)
Hi, As I reported earlier, starting from about a months ago I'm having strange problems with building 5-current world on 4-stable system. As long as nobody confirmed this problem in the similar setups I investigated further and found that problem is due to my non-standard directory layout. Usually I keep my -current and -stable sources on a 4-stable box shared over nfs and my directories layout is as following: /usr/src - 4-stable sources /usr/current/src - 5-current sources When I renamed /usr/src into /usr/src4 and /usr/current/src into /usr/src the 5-current buildworld went without any problems, then I renamed /usr/src back into /usr/current/src and tried again and buildworld failed with the following errors: building static perl library ranlib libperl.a sh /usr/current/src/tools/install.sh -c -o root -g wheel -m 444 libperl.a /sha res/UF/obj/usr/current/src/i386/usr/lib cd /usr/current/src/gnu/usr.bin/perl/miniperl; make obj; make depend; make al l; make install /shares/UF/obj/usr/current/src/gnu/usr.bin/perl/miniperl created for /usr/curren t/src/gnu/usr.bin/perl/miniperl make: don't know how to make miniperlmain.c. Stop *** Error code 2 Of course before doing builds I cleared both OBJDIR and my source tree (the latter using utility that clears all leftovers based on cvsup's checkout file). Thus, it is clear than something goes wrong in the perl bootstrap process. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: well! That root didn't work! Let's try another!
Matthew Jacob [EMAIL PROTECTED] writes:
My FreeBSD-alpha PC164 lost it's IDE disk for 4.2 somehow- which I'd
just loaded the 4.2 kernel from- so it decided to run off of da0
instead, which was -current. Truly a startling turn of
events. Shouldn't one stop and ask if the root one asked for isn't
available?
There are two schools of thought here. One says "you should try very
hard to find a root device", the other says "you should boot only from
the exactly correct root device and complain otherwise". I took the
first approach because its advocates shouted more loudly than those of
the second.
Would a louder warning message be enough of a compromised?
Actually, no. I think very strongly that you shouldn't always look that hard
automatically- you should look hard to find reasonable choices (you could say,
da2, 7 and 9 have what *appear* to be filesystems I can use)- but you
shouldn't just launch onto them- vital customer data corruption can result.
As suggested, if the correct root device can't be found, the boot
_should_ offer you a choice of running off others that appear to be
bootable. Also, I certainly can see instances where someone would want to
have it take an alternate partition to run off of - it could be an
alternate boot behavior programmed into the boot block code at label time.
Note: I don't know exactly what we do now; I'm just taking the above
comments as fact.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: well! That root didn't work! Let's try another!
As suggested, if the correct root device can't be found, the boot _should_ offer you a choice of running off others that appear to be bootable. The "appear to be bootable" criterion is almost impossible (and unsafe to attempt) to determine. Also, I certainly can see instances where someone would want to have it take an alternate partition to run off of - it could be an alternate boot behavior programmed into the boot block code at label time. Note: I don't know exactly what we do now; I'm just taking the above comments as fact. The current arrangement provides almost maximal flexibility; I find it odd that rather than determining the facts for yourself, you base your comments on an inaccurate reading of a not-very-accurate posting. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Panic mounting msdos fs
On 08-Mar-01 Andrea Campi wrote:
Yesterday -current:
# mount /msdos
Acquring duplicate lock of same type: "lockmgr interlock"
1st @ ../../kern/kern_lock.c:239
2nd @ ../../kern/kern_lock.c:239
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc015c3f5
stack pointer = 0x10:0xc7821ce4
frame pointer = 0x10:0xc7821cf0
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 = 489 (mount_msdos)
kernel: type 12 trap, code=0
Stopped at witness_exit+0x23d: movl%eax,0(%edx)
db
(kgdb) l *(witness_exit+0x23d)
0xc0200e41 is in witness_exit (../../kern/kern_mutex.c:1303).
1300if ((flags MTX_NOSWITCH) == 0 !mtx_legal2block() !cold)
1301panic("switchable mtx_unlock() of %s when not legal @
%s:%d",
1302m-mtx_description, file, line);
1303LIST_REMOVE(m, mtx_held);
1304m-mtx_held.le_prev = NULL;
1305}
H. It dereferenced NULL in the LIST_REMOVE(). Did you get a dump by any
chance?
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mount: /dev/ad0s1e: File name too long
Bruce Evans [EMAIL PROTECTED] writes:
I think I prefer the old behaviour. The names preserved by the kernel
can't possibly remain valid until unmount in all cases. Examples:
- pathnames relative to the current directory work. These only remain
valid if the process that does the mount also does the unmount (and
doesn't chdir).
- the pathnames may involve symlinks that go away or change before
unmount.
The fix for this is: don't do that. This is also a reaonable fix for
long pathnames -- don't use them unless you really have to. Long
names even mess up the most common uses of the preserved names --
displaying them in df, mount, etc.
And what if you have to use them (or want to)? If df/mount/etc
have bugs, let's fix those (not that I think they're significant).
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
linux module or linux_devtools problem?
The Portland Group's linux Fortran compiler used to work without a problem, but something has changed that I haven't track down. The script(1) log below suggests two possibilities: (1) the translation of linux syscalls to FreeBSD syscalls isn't working; or (2) the linux ld command (see log) needs some additional options. Any suggestions? -- Steve http://troutmask.apl.washington.edu/~kargl/ Script started on Thu Mar 8 12:57:59 2001 /usr/pgi/linux86/bin/pgftn shell.f -x 124 0x1400 -x 122 0x40 -x 119 0x1\ -x 123 0x1000 -x 119 0x80 -x 127 4 -x 124 1 -astype 0 -stdinc /usr/pgi/\ linux86/include:/compat/linux/usr/include:/compat/linux/usr/lib/gcc-lib/\ i386-redhat-linux/egcs-2.91.66//include -opt 1 -x 80 0x300 -y 80 0x1000\ -asm /var/tmp/pgf7737423aaa PGFTN/x86 Linux/x86 Rel 1.7-6.3: compilation successful pgf77: /usr/pgi/linux86/bin/pgftn completed with exit code 0 /compat/linux/usr/bin/as -o shell.o /var/tmp/pgf7737423aaa pgf77: /compat/linux/usr/bin/as completed with exit code 0 Unlinking /var/tmp/pgf7737423aaa Linking: /compat/linux/usr/bin/ld -m elf_i386 -dynamic-linker /compat/linux/lib/\ ld-linux.so.2 -o shell /usr/pgi/linux86/lib/crt1.o /usr/pgi/linux86/lib/\ crti.o /usr/pgi/linux86/lib/pgfmain.o -L/usr/pgi/linux86/lib -L/compat/\ linux/lib -L/compat/linux/usr/lib -L/compat/linux/usr/lib/gcc-lib/\ i386-redhat-linux/egcs-2.91.66/ shell.o -lpgftnrtl -lm -lpgc -lgcc -lc\ -lgcc /usr/pgi/linux86/lib/crtn.o /usr/pgi/linux86/lib/crt1.o: In function `_start': /usr/pgi/linux86/lib/crt1.o(.text+0x40): undefined reference to `__setfpucw' /usr/pgi/linux86/lib/crt1.o(.text+0x48): undefined reference to `__libc_init' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `__stat': stdinit.o(.text+0x2c): undefined reference to `_xstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `stat': stdinit.o(.text+0x5c): undefined reference to `_xstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `__lstat': stdinit.o(.text+0x8c): undefined reference to `_lxstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `lstat': stdinit.o(.text+0xbc): undefined reference to `_lxstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `__fstat': stdinit.o(.text+0xec): undefined reference to `_fxstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `fstat': stdinit.o(.text+0x11c): undefined reference to `_fxstat' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `__mknod': stdinit.o(.text+0x156): undefined reference to `_xmknod' /usr/pgi/linux86/lib/libpgftnrtl.a(stdinit.o): In function `mknod': stdinit.o(.text+0x196): undefined reference to `_xmknod' pgf77: /compat/linux/usr/bin/ld completed with exit code 1 Unlinking Unlinking Unlinking /var/tmp/pgf7737423aaa Unlinking shell Script done on Thu Mar 8 12:58:01 2001 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Entropy harvesting? Grim reaper is more like it...
I did a buildworld/installworld on an alpha yesterday, and now I'm left with: start_init: trying /sbin/init Entropy harvesting: interrupts ethernet. hangs And this is even with booting from an older kernel. Umm... anyone gotta clue on this one? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New improved panic!
kernel: type 12 trap, code=0
Stopped at 0: kernel: type 12 trap, code=0
db trace
kernel: type 12 trap, code=0
db panic
panic: from debugger
Debugger("panic")
Stopped at 0:kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02660f0
stack pointer = 0x10:0xcaec2dd4
frame pointer = 0x10:0xcaec2dd8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 14 (random)
kernel: type 12 trap, code=0
db
panic: from debugger
Uptime: 17m48s
dumping to dev ad0b, offset 131104
dump ata0: resetting devices .. done
191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171
170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150
149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108
107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82
81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53
52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 succeeded
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: problems with sound in 5.0-20010126-CURRENT
[EMAIL PROTECTED] writes: The sound mostly works. I can play MP3s using mpg123/x11amp/xmms... The problem is that when I start moving the mouse around a lot, the sound distorts and the kernel occasionally spits out a message like: Mar 8 16:07:17 choplifter /boot/kernel/kernel: pcm1: hwptr went backwards 536 - 444 This has been a known problem for several months now. Please do not run -CURRENT unless you follow the freebsd-current mailing list closely. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New improved panic!
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
db trace
kernel: type 12 trap, code=0
Blah. Here's what gdb says:
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc019131b in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2 0xc01916e5 in panic (fmt=0xc02940b4 "from debugger")
at ../../kern/kern_shutdown.c:571
#3 0xc011f1d5 in db_panic (addr=0, have_addr=0, count=1, modif=0xcaec2dd8 "")
at ../../ddb/db_command.c:433
#4 0xc011f175 in db_command (last_cmdp=0xc02cd880, cmd_table=0xc02cd6e0,
aux_cmd_tablep=0xc0310cdc) at ../../ddb/db_command.c:333
#5 0xc011f23a in db_command_loop () at ../../ddb/db_command.c:455
#6 0xc0121403 in db_trap (type=12, code=0) at ../../ddb/db_trap.c:71
#7 0xc0265ffe in kdb_trap (type=12, code=0, regs=0xcaec2f28)
at ../../i386/i386/db_interface.c:164
#8 0xc0275700 in trap_fatal (frame=0xcaec2f28, eva=0)
at ../../i386/i386/trap.c:982
#9 0xc0275475 in trap_pfault (frame=0xcaec2f28, usermode=0, eva=0)
at ../../i386/i386/trap.c:901
#10 0xc0274504 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 0, tf_ebp = -890491044, tf_isp = -890491052, tf_ebx = 32,
tf_edx = -1070513800, tf_ecx = 0, tf_eax = -1071185861, tf_trapno = 12,
tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags = 66194,
tf_esp = -1072401776, tf_ss = -894758432}) at ../../i386/i386/trap.c:448
#11 0x0 in ?? ()
(kgdb) up 10
#10 0xc0274504 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 0, tf_ebp = -890491044, tf_isp = -890491052, tf_ebx = 32,
tf_edx = -1070513800, tf_ecx = 0, tf_eax = -1071185861, tf_trapno = 12,
tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags = 66194,
tf_esp = -1072401776, tf_ss = -894758432}) at ../../i386/i386/trap.c:448
448 (void) trap_pfault(frame, FALSE, eva);
(kgdb) p/x frame.tf_esp
$1 = 0xc0147290
(kgdb) l *0xc0147290
0xc0147290 is in random_kthread (../../dev/random/yarrow.c:97).
92 mtx_lock(Giant);
93 printf("OWNERSHIP Giant == %d sched_lock == %d\n",
94 mtx_owned(Giant), mtx_owned(sched_lock));
95 mtx_unlock(Giant);
96 #endif
97
98 for (pl = 0; pl 2; pl++)
99 yarrow_hash_init(random_state.pool[pl].hash, NULL, 0);
100
101 for (;;) {
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: tape device names and devfs
On Mon, 5 Mar 2001, Steve Kargl wrote: Matthew Jacob wrote: On Mon, 5 Mar 2001, Steve Kargl wrote: What are the names of the tape devices under devfs? Should dump(8) use /dev/sa0 for the rewind device and /dev/nsa0 for no rewind device? Should /etc/rc.devfs create symlinks from rsa0 and nrsa0 for backwards compatibility? Can you give a hint as to which release you're trying this with? FreeBSD 5.0-CURRENT #2: Mon Mar 5 10:40:22 PST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TROUTMASK Does rc.devfs mean anything at all with -current's devfs? I just changed the sa driver to create the correct aliases. Yes, I use it to set permissions on cd0 and cd0c during boot. I could add "ln -sf /dev/nsa0 /dev/nrsa0" for backwards compatibility. dump.8 and dump(8) both refer explicitly to nsa0 and nrsa0 whereas sa0 and nsa0 are the actual device names in -current. Hrmm.. Didn't somebody just fix this? At any rate, by all means add whatever you think appropriate to rc.devfs. If you think the sa driver should create an alias for backward compatibility do so or let know. Frankly- I think given that this is 5.0 that 'compatibility' is not needed. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Panic mounting msdos fs
On 08-Mar-01 Andrea Campi wrote: Yesterday -current: It seems modules are broken with witness right now. Before you were ok as long as you didn't unload the darn things, now they seem to be toast altogether, so you will want to use a static kernel for now until this is fixed. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
