more info: Q: Problems with device hints?
> The PNP ones are normal, not sure about the digi ones; do you have any > digiboards in your system? Yes I do have a digi board (pci) in the system which is probed correctly: digi0 mem 0xb080-0xb0bf irq 10 at device 4.0 on pci0 But I don't have any ISA cards installed and I could not find any device hints concerning an isa digi card, and no hints for adresses 0x378 or 0x061. I checked /boot/kernel.conf, /boot/device.hints, and the CONFIG file I used to compile the kernel. Regards, Robert S. -- Robert Suetterlin ([EMAIL PROTECTED]) phone: (+49)89 / 3-3546 fax: (+49)89 / 3-3950 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: buffer not busy ??? (pagefault)
Hi all,
I got now three times the same panic. Always it is now
T_PAGEFLT. And this is on new fresh ATA disks, a /dev/ar
raid.
So I guess I could say it is repeatable ;) It looks like
in February people had similar problems.
I have to admit that on the SCSI disk I do not run softupdates.
That may be the cause that OpenOffice compiled there ...
A kernel compiled with -o0 doesn't help. Same symptopms, but the
trace is better this time ... :-)
#2 0xc022c5b3 in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc0278350 in bwrite (bp=0xd870bcc4) at /usr/src/sys/kern/vfs_bio.c:761
#4 0xc0279b23 in vfs_bio_awrite (bp=0xd870bcc4)
at /usr/src/sys/kern/vfs_bio.c:1637
#5 0xc01f263e in spec_fsync (ap=0xe98fb720)
at /usr/src/sys/fs/specfs/spec_vnops.c:406
#6 0xc01f2002 in spec_vnoperate (ap=0xe98fb720)
at /usr/src/sys/fs/specfs/spec_vnops.c:124
#7 0xc0344c80 in VOP_FSYNC (vp=0xcbfe8000, cred=0xc204ce80, waitfor=2,
td=0xc0433040) at vnode_if.h:597
#8 0xc03441cf in ffs_sync (mp=0xcbfdee00, waitfor=2, cred=0xc204ce80,
td=0xc0433040) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1160
#9 0xc028df05 in sync (td=0xc0433040, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:130
#10 0xc022be5d in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254
#11 0xc022c5b3 in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#12 0xc03aca7e in trap_fatal (frame=0xe98fb918, eva=33554456)
at /usr/src/sys/i386/i386/trap.c:846
#13 0xc03ac6b5 in trap_pfault (frame=0xe98fb918, usermode=0, eva=33554456)
at /usr/src/sys/i386/i386/trap.c:760
#14 0xc03ac09c in trap (frame=
{tf_fs = -850853864, tf_es = 16, tf_ds = -376504304, tf_edi = 134590208, t
f_esi = 134590288, tf_ebp = -376456856, tf_isp = -376456892, tf_ebx = -872048640
, tf_edx = 33554432, tf_ecx = -826798848, tf_eax = 9138351, tf_trapno = 12, tf_e
rr = 0, tf_eip = -1070368199, tf_cs = 8, tf_eflags = 66054, tf_esp = -1070371830
, tf_ss = 1}) at /usr/src/sys/i386/i386/trap.c:446
#15 0xc039b2f8 in calltrap () at /var/tmp//cciyCklS.s:98
#16 0xc033ecc4 in softdep_load_inodeblock (ip=0xceb80d00)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:4578
#17 0xc0344653 in ffs_vget (mp=0xcbfdfc00, ino=9138351, flags=2,
vpp=0xe98fba84) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1284
#18 0xc034d265 in ufs_lookup (ap=0xe98fbadc)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:601
#19 0xc0354b72 in ufs_vnoperate (ap=0xe98fbadc)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2724
#20 0xc027e65e in VOP_CACHEDLOOKUP (dvp=0xceb78250, vpp=0xe98fbc30,
cnp=0xe98fbc44) at vnode_if.h:83
#21 0xc027da78 in vfs_cache_lookup (ap=0xe98fbb48)
at /usr/src/sys/kern/vfs_cache.c:597
#22 0xc0354b72 in ufs_vnoperate (ap=0xe98fbb48)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2724
#23 0xc028338e in VOP_LOOKUP (dvp=0xceb78250, vpp=0xe98fbc30, cnp=0xe98fbc44)
at vnode_if.h:54
#24 0xc0282c7c in lookup (ndp=0xe98fbc1c) at /usr/src/sys/kern/vfs_lookup.c:482
#25 0xc02825e8 in namei (ndp=0xe98fbc1c) at /usr/src/sys/kern/vfs_lookup.c:181
#26 0xc0290c45 in lstat (td=0xcd49a600, uap=0xe98fbcf8)
---Type to continue, or q to quit---
at /usr/src/sys/kern/vfs_syscalls.c:1643
#27 0xc03ace38 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134590208, tf_esi = 13459028
8, tf_ebp = -1077937400, tf_isp = -376455820, tf_ebx = 672195836, tf_edx = 13455
8656, tf_ecx = 0, tf_eax = 190, tf_trapno = 12, tf_err = 2, tf_eip = 671795807,
tf_cs = 31, tf_eflags = 662, tf_esp = -1077937556, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#28 0xc039b34d in Xint0x80_syscall () at /var/tmp//cciyCklS.s:140
(kgdb) frame 16
#16 0xc033ecc4 in softdep_load_inodeblock (ip=0xceb80d00)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:4578
4578if (inodedep_lookup(ip->i_fs, ip->i_number, 0, &inodedep) == 0)
{
(kgdb) list
4573/*
4574 * Check for alternate nlink count.
4575 */
4576ip->i_effnlink = ip->i_nlink;
4577ACQUIRE_LOCK(&lk);
4578if (inodedep_lookup(ip->i_fs, ip->i_number, 0, &inodedep) == 0)
{
4579FREE_LOCK(&lk);
4580return;
4581}
4582ip->i_effnlink -= inodedep->id_nlinkdelta;
(kgdb) p lk
$7 = {lkt_spl = 0, lkt_held = 0xcd49a600}
(kgdb) p *ip
$11 = {i_hash = {le_next = 0xce50c900, le_prev = 0xcbf622c4}, i_nextsnap = {
tqe_next = 0x0, tqe_prev = 0x0}, i_vnode = 0xceb65940, i_ump = 0xcc134b00,
i_devvp = 0x0, i_flag = 32, i_dev = 0xcbe05e00, i_number = 9138351,
i_effnlink = 1, i_fs = 0xcc059800, i_dquot = {0x0, 0x0}, i_modrev = 0,
i_lockf = 0x0, i_count = 0, i_endoff = 0, i_diroff = 0, i_offset = 0,
i_ino = 0, i_reclen = 0, i_dirhash = 0x0, i_ea_area = 0x0, i_ea_len = 0,
i_ea_error = 0, i_mode = 33261, i_nlink = 1, i_size = 70577, i_flags = 0,
i_gen = 303805966, i_uid = 0, i_gid = 0, dinode_u = {din1 = 0xceb98100,
din2 = 0xceb98100}}
(kgdb) p inodedep
$5 = (struct inodedep *) 0xd87217f4
(kgdb) p *inodedep
$6 = {id_list = {wk_list = {le_ne
Re: nfs_inactive() bug? -> panic: lockmgr: locking against myself
On 13 Sep, Ian Dowse wrote: > For example, if you hold the reference count at 1 while calling the > cleanup function, it allows that function to safely add and drop > references, but if that cleanup function has a bug that drops one > too many references then you end up recursing instead of detecting > it as a negative reference count. I've found in some other code > that it works reasonably well to leave the reference count at zero, > but set a flag to stop further 1->0 transitions from retriggering > the cleanup. Obviously other approaches will work too. The cleanup function shouldn't be mucking with the reference count, which means that the present implementation of nfs_inactive() is broken, but I think there is already general agreement on that point. The only possible exception would be to increase the reference count to pass a reference to another thread, but that would be a silly thing for a cleanup function to do, since it would no longer be cleaning up. We could add a flag that would cause an immediate panic if the cleanup function fiddled with the reference count as an aid to tracking down broken code ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: buffer not busy ??? (pagefault)
On 13 Sep, Martin Blapp wrote: > > I've got some news here ... > > I have three different type of disks > > 1) - ATA100 Raid, 2 Disks a 80GB (striped) > 2) - Vinum ATA Raid, 2 Disks a 16GB (striped) > 3) - SCSI Disk > > I encounter pagefaults and all these nice panics on 1) and 2). > > I don't see them if I build OpenOffice on the SCSI disk ! Does > somewhere a alarm bell ring ? Or may it only be the limited speed > comaring the SCSI disk to the ATA Raids ? Very interesting ... I'm running my openoffice builds on a 10K RPM Seagate Cheetah connected via an Adaptec Ultra 160 SCSI controller and I'm not seeing this problem, so I don't think it is related to the disk speeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Alpha fatal warning in kernel compile
On Thu, Sep 12, 2002 at 05:47:29PM -0700, David O'Brien wrote: > On Thu, Sep 12, 2002 at 01:27:50PM -0700, Kris Kennaway wrote: > > How are you supposed to disable -Werror in kernel builds? Setting > > NO_WERROR in the env or passing it to 'make buildkernel' via -D > > doesn't work; neither does putting -Wno-error in COPTFLAGS. I get the > > following fatal warning when compiling a recent alpha 5.0 kernel under > > 4.x: > > Exactly how were you compiling this? `make buildworld kernel'? Or just > straight compile of the kernel? If the latter I would expect that not to > work too much longer as we will end up adding code dependent on GCC 3, or > we'll hit bugs in gcc 2.95 which wont be noticed. As stated above it was 'make buildkernel' on the 4.x system. Kris msg42956/pgp0.pgp Description: PGP signature
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/var/tmp/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Sep 12 18:19:30 PDT 2002 -- >>> Kernel build for GENERIC completed on Thu Sep 12 19:24:29 PDT 2002 -- >>> Kernel build for LINT started on Thu Sep 12 19:24:30 PDT 2002 -- ===> vinum ./aicasm: 877 instructions used ./aicasm: 658 instructions used In file included from /var/tmp/des/src/sys/dev/dgb/dgb.c:89: /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /var/tmp/des/src/sys/dev/dgb/dgb.c:92:2: #error "The dgb device requires the old isa compatibility shims" /var/tmp/des/src/sys/dev/iicbus/iic.c:42:25: machine/iic.h: No such file or directory /var/tmp/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken and is not compiled with LINT" /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:80:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:81:33: machine/physio_proc.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:86: /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:55:27: machine/dvcfg.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:63: /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp.c:80:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp.c:81:33: machine/physio_proc.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp_pccard.c:52:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/smbus/smb.c:41:25: machine/smb.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30.c:78:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30.c:79:33: machine/physio_proc.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30_pccard.c:57:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30_isa.c:65:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/usb/ukbd.c:419:21: ukbdmap.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/wl/if_wl.c:218: /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /var/tmp/des/src/sys/dev/wl/if_wl.c:224:35: machine/if_wl_wavelan.h: No such file or directory /var/tmp/des/src/sys/dev/wl/if_wl.c:227:2: #error "The wl device requires the old isa compatibility shims" /var/tmp/des/src/sys/kern/subr_prof.c:62:30: machine/asmacros.h: No such file or directory /var/tmp/des/src/sys/kern/subr_prof.c:232:2: #error /var/tmp/des/src/sys/kern/subr_prof.c:243:2: #error /var/tmp/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken and is not compiled with LINT" /var/tmp/des/src/sys/pci/simos.c:57:2: #error "The simos device requires the old pci compatibility shims" /var/tmp/des/src/sys/dev/syscons/syscons.c:117:18: font.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /var/tmp/des/obj/var/tmp/des/src/sys/LINT. *** Error code 1 Stop in /var/tmp/des/obj/var/tmp/des/src/sys/LINT. *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VAIO R505ES TI cardbus
With current as of today, I can finally get the system to
boot without acpi enabled, but not otherwise. However,
with all combinations of hw.pcic.intr_path={0,1,2},
hw.pcic.irq=0, and hw.pcic.init_routing={0,1} the TI
is not happy and I can't use the wireless.
Since this system is acpi-only it would eventually be
nice to get the int routing to work with acpi (actually
for the Sony, it would be nice to get int routing to
work at all (or is loader.conf not the place for hw.pcic.*?)
with acpi enabled it hangs after "trying sbin/init".
I thought jhb had committed some fixes for this; do
they work on any system?
-- Pete
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: nfs_inactive() bug? -> panic: lockmgr: locking against myself
In message <[EMAIL PROTECTED]>, Terry Lambert writes: >Ian Dowse wrote: >> And I've just remembered a fifth :-) I think the old BSD code had >> both an `open' count and a reference count. The open count is a >> count of the real users of the vnode (it is what ufs_inactive really >> wants to compare against 0), and the reference count is just for >> places that you don't want the vnode to be recycled or destroyed. >> This was probably lost when the encumbered BSD sources were rewritten. > >No, this went away with the vnode locking changes; it was in the >4.4 code, for sure. I think references are the correct thing here, >and SunOS seems to agree, since that's how they implement, too. 8-). I seem to have mis-remembered the details anyway :-) It doesn't look as if there ever was ever the `open' count that I mentioned above. Maybe I was just thinking that it would be a good way to solve the issues of matching VOP_CLOSEs with VOP_OPENs, since there are many cases in the kernel that do not guarantee to do a VOP_CLOSE for each VOP_OPEN that was performed. Handling the dropping of a last reference is always tricky to get right when complex operations can be performed from the reference dropping function (especially where that includes adding and then removing references multiple times). It's even harder to do it in a way that continues to catch missing or extra references caused by bugs in the functions called when the reference count hits zero. For example, if you hold the reference count at 1 while calling the cleanup function, it allows that function to safely add and drop references, but if that cleanup function has a bug that drops one too many references then you end up recursing instead of detecting it as a negative reference count. I've found in some other code that it works reasonably well to leave the reference count at zero, but set a flag to stop further 1->0 transitions from retriggering the cleanup. Obviously other approaches will work too. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Alpha fatal warning in kernel compile
On Thu, Sep 12, 2002 at 01:27:50PM -0700, Kris Kennaway wrote: > How are you supposed to disable -Werror in kernel builds? Setting > NO_WERROR in the env or passing it to 'make buildkernel' via -D > doesn't work; neither does putting -Wno-error in COPTFLAGS. I get the > following fatal warning when compiling a recent alpha 5.0 kernel under > 4.x: Exactly how were you compiling this? `make buildworld kernel'? Or just straight compile of the kernel? If the latter I would expect that not to work too much longer as we will end up adding code dependent on GCC 3, or we'll hit bugs in gcc 2.95 which wont be noticed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GENERIC kernel panic on boot with latest -current Septembet 11,2002 due to /usr/src/sys/kern/kern_acct.c v 1.49
On Wed, 11 Sep 2002, Nate Lawson wrote: > This is being worked on. See msg thread in cvs-all, starting with: > <[EMAIL PROTECTED]>. You can back out the > change (1.49) if you need to get running. Sorry, 1.50 fixed the problem. I reverted back to kernel.old anyways which was from a previous -current build before I saw the discussion on the mailing list archives on cvs-all. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: buffer not busy ??? (pagefault)
I've got some news here ... I have three different type of disks 1) - ATA100 Raid, 2 Disks a 80GB (striped) 2) - Vinum ATA Raid, 2 Disks a 16GB (striped) 3) - SCSI Disk I encounter pagefaults and all these nice panics on 1) and 2). I don't see them if I build OpenOffice on the SCSI disk ! Does somewhere a alarm bell ring ? Or may it only be the limited speed comaring the SCSI disk to the ATA Raids ? Would it be possible that gcc32 does make some faulty code in the ata subsystem ? Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Alpha fatal warning in kernel compile
Kris Kennaway <[EMAIL PROTECTED]> writes: > On Thu, Sep 12, 2002 at 01:52:40PM -0700, Nate Lawson wrote: > > (who wants NO_WERROR back or better, warns-clean code more often in > > -current) > > NO_WERROR is standard in userland; it should work in the kernel too. Peter removed support for this a while ago. The easiest way to get around problems now is to edit sys/conf/files* and add a nowerror for each affected file. I think the idea is to force developers to test changes, so that they hit the errors before the tinderboxes and the rest of the developer base. In practice this doesn't stop the determined troublemakers. :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: buffer not busy ??? (pagefault)
Note that I run this system with same hardware for about
2 weeks on STABLE and there it works like a charm. I never
had any panics.
The panics began with gcc3.2 in the base system.
I run also without these ...
optionsDISABLE_PSE
optionsDISABLE_PG_G
Still looks like memory corruption (which one can
only see with FreeBSD CURRENT.)
I also thought that vinum may be part of the problem. I've
replaced all my vinum raid disk with a real hardware raid
with new disks. Problem is still there.
#14 0xc02f3518 in calltrap () at {standard input}:98
#15 0xc01d938e in exit1 (td=0xc1f950c0, rv=0) at vm_map.h:226
#16 0xc01d8efc in exit1 (td=0xc1f950c0, rv=-456012564)
at /usr/src/sys/kern/kern_exit.c:112
#17 0xc0300754 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077937944, tf_esi = 0, tf_
ebp = -1077938072, tf_isp = -456012428, tf_ebx = -1, tf_edx = 10, tf_ecx = 0, tf
_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 134905791, tf_cs = 31, tf_eflags
= 658, tf_esp = -1077938100, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050
#18 0xc02f356d in Xint0x80_syscall () at {standard input}:140
Martin
Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 061 826 93 00: +41 61 826 93 01
PGP:
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ata0-master: timeout waiting for interrupt -> root mount failed
I just installed -DP1, no problem. Then I made a world and kernel (from sept 11 cvsup). Now I get this at boot: FreeBSD 5.0-CURRENT #2: Thu Sep 12 21:20:00 CEST 2002 (...) atapci0: port 0xe000-0xe00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 16 on atapci1 (...) Timecounters tick every 10.000 msec ata0-master: timeout waiting for interrupt ata0-master: ATA identify failed Mounting root from ufs:/dev/ad0s2a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: (...) mountroot> I searched in the archives and found the following patches: http://groups.google.com/groups?selm=200203220914.aa83048%40salmon.maths.tcd.ie http://groups.google.com/groups?selm=200203220933.g2M9XGT90073%40freebsd.dk The first patch I tried - no success. The second one I didn't try since asleep and await have been removed. Furthermore, I changed the 10*hz sleep timeout to 100*hz, no luck. I don't really know what to try next. - Willem van Engen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Alpha fatal warning in kernel compile
On Thu, Sep 12, 2002 at 01:52:40PM -0700, Nate Lawson wrote: > NO_WERROR was removed so the only way is to set in your make.conf: > WERROR= > > This causes the WERROR?=-Werror to not set the flag. Thanks, Bill Fenner also told me this on IRC. The directions in /usr/src/UPDATING need to be fixed to reflect this. > (who wants NO_WERROR back or better, warns-clean code more often in > -current) NO_WERROR is standard in userland; it should work in the kernel too. Kris msg42946/pgp0.pgp Description: PGP signature
Re: Alpha fatal warning in kernel compile
On Thu, 12 Sep 2002, Kris Kennaway wrote: > How are you supposed to disable -Werror in kernel builds? Setting > NO_WERROR in the env or passing it to 'make buildkernel' via -D > doesn't work; neither does putting -Wno-error in COPTFLAGS. I get the > following fatal warning when compiling a recent alpha 5.0 kernel under > 4.x: > > cc -c -O -pipe -Wno-error -mcpu=ev56 -Wall -Wredundant-decls -Wnested-externs >-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >-fformat-extensions -ansi -nostdinc -I- -I. -I/local0/src2/sys >-I/local0/src2/sys/dev -I/local0/src2/sys/contrib/dev/acpica >-I/local0/src2/sys/contrib/ipfilter -I/local0/src2/sys/../include -D_KERNEL -include >opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror >/local0/src2/sys/dev/ccd/ccd.c > cc1: warnings being treated as errors > /local0/src2/sys/dev/ccd/ccd.c: In function `ccdiodone': > /local0/src2/sys/dev/ccd/ccd.c:1181: warning: long long int format, daddr_t arg (arg >6) > *** Error code 1 > > Kris NO_WERROR was removed so the only way is to set in your make.conf: WERROR= This causes the WERROR?=-Werror to not set the flag. -Nate (who wants NO_WERROR back or better, warns-clean code more often in -current) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Alpha fatal warning in kernel compile
How are you supposed to disable -Werror in kernel builds? Setting NO_WERROR in the env or passing it to 'make buildkernel' via -D doesn't work; neither does putting -Wno-error in COPTFLAGS. I get the following fatal warning when compiling a recent alpha 5.0 kernel under 4.x: cc -c -O -pipe -Wno-error -mcpu=ev56 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/local0/src2/sys -I/local0/src2/sys/dev -I/local0/src2/sys/contrib/dev/acpica -I/local0/src2/sys/contrib/ipfilter -I/local0/src2/sys/../include -D_KERNEL -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /local0/src2/sys/dev/ccd/ccd.c cc1: warnings being treated as errors /local0/src2/sys/dev/ccd/ccd.c: In function `ccdiodone': /local0/src2/sys/dev/ccd/ccd.c:1181: warning: long long int format, daddr_t arg (arg 6) *** Error code 1 Kris msg42944/pgp0.pgp Description: PGP signature
Re: PC hangs with power light off [SOLVED]
After disabling ACPI through hints, the box has been up a few days, no problems. Should I pursue this as a FreeBSD acpi problem or does Intel's work on acpica have a long way to go? I don't really have an idea of what we should expect from the current acpi implementation. -Nate On Thu, 5 Sep 2002, Julian Elischer wrote: > One presumes you have disabled loading ACPI? > If in doubt just rename the acpi module to something else :-) > > > On Thu, 5 Sep 2002, Nate Lawson wrote: > > > Oh, I forgot to mention that I have the EXACT same computer sitting next > > to this one and running -STABLE and it has 60 days uptime. > > > > -Nate > > > > On Thu, 5 Sep 2002, Mike Tancsa wrote: > > > We had a couple of Intel boards that did this on Win2k as well. Tried a > > > few BIOS updates and it didnt help. We ended up just replacing them in the > > > end :-( I had more problems with the 810s than any other chipset in the > > > past couple of years. > > > > > > ---Mike > > > > > > On Thu, 5 Sep 2002 15:30:54 -0700 (PDT), in sentex.lists.freebsd.current > > > you wrote: > > > > > > >I have a Celeron 500 box (i810 chipset, 128MB/IDE/SCSI) that hangs every > > > >24 hours or so (usually overnight). I've never had it hang during the day > > > >or while I was using it. It's running a kernel/world from 8/28 although > > > >this has been happening ever since I installed -current on this box in > > > >June. > > > > > > > >The symptoms are I come back to it and the power light is off although the > > > >fan is still running on the power supply. Numlock is frozen (light is > > > >on). Nothing can revive it. Pressing the power button doesn't do > > > >anything either but I can hold it down for 8 secs and the box powers > > > >off. > > > > > > > >All these symptoms indicate to me that it is going into some kind of > > > >suspend mode but I have all of that turned off in the BIOS. APM is > > > >commented out (not just disabled) in my kernel config. ACPI is loaded. > > > > > > > >Thanks for any help, > > > >Nate > > > > > > > > > > > >dmesg > > > >- > > > >Copyright (c) 1992-2002 The FreeBSD Project. > > > >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > > >The Regents of the University of California. All rights reserved. > > > >FreeBSD 5.0-CURRENT #9: Wed Aug 28 18:20:38 PDT 2002 > > > >nate@moe:/usr/obj/usr/src/sys/MOE > > > >Preloaded elf kernel "/boot/kernel/kernel" at 0xc04e7000. > > > >Preloaded elf module "/boot/kernel/agp.ko" at 0xc04e70a8. > > > >Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04e7150. > > > >Timecounter "i8254" frequency 1193182 Hz > > > >Timecounter "TSC" frequency 498487691 Hz > > > >CPU: Pentium II/Pentium II Xeon/Celeron (498.49-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x665 Stepping = 5 > > > > > > > >Features=0x183f9ff > > >T,PSE36,MMX,FXSR> > > > >real memory = 133103616 (129984K bytes) > > > >avail memory = 123813888 (120912K bytes) > > > >Pentium Pro MTRR support enabled > > > >Using $PIR table, 7 entries at 0xc00fdf50 > > > >npx0: on motherboard > > > >npx0: INT 16 interface > > > >acpi0: on motherboard > > > >acpi0: power button is handled as a fixed feature programming model. > > > >Timecounter "ACPI-fast" frequency 3579545 Hz > > > >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > > > >acpi_cpu0: on acpi0 > > > >pcib1: port 0xcf8-0xcff on acpi0 > > > >pci0: on pcib1 > > > >agp0: mem > > > >0xf400-0xf407,0xf800 > > > >-0xfbff irq 3 at device 1.0 on pci0 > > > >pcib2: at device 30.0 on pci0 > > > >pci1: on pcib2 > > > >fxp0: port 0x3400-0x343f mem > > > >0xf410-0xf41f > > > >,0xf430-0xf4300fff irq 5 at device 11.0 on pci1 > > > >fxp0: Ethernet address 00:d0:b7:21:ff:2d > > > >inphy0: on miibus0 > > > >inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > >fxp1: port 0x3440-0x347f mem > > > >0xf420-0xf42f > > > >,0xf4301000-0xf4301fff irq 9 at device 13.0 on pci1 > > > >fxp1: Ethernet address 00:d0:b7:69:21:74 > > > >inphy1: on miibus1 > > > >inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > >ahc_pci0: port 0x3000-0x30ff mem > > > >0xf4302000-0 > > > >xf4302fff irq 3 at device 14.0 on pci1 > > > >aic7890/91: Ultra2 Wide Channel A, SCSI Id=14, 32/253 SCBs > > > >isab0: at device 31.0 on pci0 > > > >isa0: on isab0 > > > >atapci0: port 0x1800-0x180f at device 31.1 > > > >on pci0 > > > >ata0: at 0x1f0 irq 14 on atapci0 > > > >ata1: at 0x170 irq 15 on atapci0 > > > >uhci0: port 0x1820-0x183f irq 11 at > > > >device > > > > 31.2 on pci0 > > > >usb0: on uhci0 > > > >usb0: USB revision 1.0 > > > >uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > > > >uhub0: 2 ports with 2 removable, self powered > > > >pci0: at device 31.3 (no driver attached) > > > >pci0: at device 31.5 (no driver attached) > > > >acpi_button0: on acpi0 > > > >atkbdc0: port 0x64,0x60 irq 1 on acpi0 > > > >atkbd0: flags 0x1 i
Re: Q: Problems with device hints?
On Thu, 12 Sep 2002, Robert Suetterlin wrote: > Hi! > > I get some strange messages during device probing on my Current > machine. I was pointed out that these might be due to device hints in > /boot or compiled / configured into my kernel. Unfortunately I could > not find any device hints that look at all like the messages I get > during bootup (or when loading driver modules): > > digi1: 0x378: Invalid i/o address > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > digi1: 0x061: Invalid i/o address > unknown: can't assign resources (port) > unknown: can't assign resources (irq) The PNP ones are normal, not sure about the digi ones; do you have any digiboards in your system? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel from latest cvsup refuses to boot. - hangs
On 12 Sep 2002, Sid Carter wrote: > > On Wed, 11 Sep 2002 11:30:55 -0700 (PDT), Nate Lawson <[EMAIL PROTECTED]> said: > > Nate> tell without more info. Enable options DDB, boot -vs, wait for the > Nate> hang. Hit CTRL-ALT-ESC to go into DDB and type tr to get a > Nate> backtrace. Copy the trace info (serial console is best for this). Hit c > Nate> for continue, wait, repeat. Chances are you'll still be at the same > Nate> backtrace. If so, then this is the code that's hanging. > > Hi, > I am using the default GENERIC kernel and it already has DDB compiled > in. When I try to do what you suggested above, nothing happens. It is > still in the hung state. No changes. And I don't have a serial console > that I can setup :( Then it's a hard hang somewhere after the bpfinit call. A better approach would be to figure out which source changes introduced the problem by cvsupping to certain days around when it happened, buildkernel, reboot. Once you have it narrowed down to a day, you can identify the culprit commit. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic during reboot in vflush()
Maxim Sobolev wrote: > Maxime Henrion wrote: > > > > Maxim Sobolev wrote: > > > Any ideas? > > > > Looks like some other processes was modifying the mountlist while > > vfs_unmountall() was running. Is this an SMP box ? > > No, it's UP. > > > It would be nice if > > you could check in gdb which other process was holding the mountlist_mtx > > mutex if any. > > Sure, if you will provide me with instruction on how to do in. You could know it by looking at the struct mtx, but after having read the stacktrace more carefully, I think my wild guesses were incorrect. I've seen a NULL mp pointer in the args and thought it was because of a corrupted mountlist but it seems it can't be that. devfs_unmount() gets called with a valid mp pointer and gdb tells us it then calls vflush() with a NULL mp, but devfs_unmount() just call vflush() with the same mp without modifying it. It looks like it's a bug in gdb and the bug is much more likely to be in vflush() like with the stacktraces from the bento cluster kris has been reporting. I expect this bug to be fixed with jeff's patch. I'm still unsure about how things are done in vfs_unmountall() but I doubt it could be the cause of your problems. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't compile XFree86-4-Server
On Thu, Sep 12, 2002 at 10:21:38AM -0400, Wesley Morgan <[EMAIL PROTECTED]> wrote: > I built all of XFree86 yesterday, with no problems. Try applying this > patch to your compiler and rebuiling it: > > http://people.freebsd.org/~kan/gcc-all.diff > > On a side note to -current / gcc maintainers -- this patch seems to fix > some critical bugs, will it be committed? As I wrote, I'm already using this particular patch. Seems like optimisation problem or something, but to be sure, I'm going to build world and kernel tomorrow without CPUTYPE set. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic during reboot in vflush()
Maxime Henrion wrote: > > Maxim Sobolev wrote: > > Any ideas? > > Looks like some other processes was modifying the mountlist while > vfs_unmountall() was running. Is this an SMP box ? No, it's UP. > It would be nice if > you could check in gdb which other process was holding the mountlist_mtx > mutex if any. Sure, if you will provide me with instruction on how to do in. > The vfs_unmountall() function doesn't acquire the > mounstlist_mtx and states this is OK in a comment because this functions > is ran upon reboot, but I suspect this is incorrect and we still need to > do the locking. I'll write a patch tonight to add locking into > vfs_unmountall(), but it may be hard to test unless you know of a way to > reproduce this panic easily. No, I don't. It's the first time I've encountered this particular problem. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Sep 12 09:37:46 PDT 2002 -- ===> xe linking kernel.debug if_ethersubr.o: In function `ether_ipfw_chk': /local0/scratch/des/src/sys/net/if_ethersubr.c:466: undefined reference to `fw_one_pass' *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nfs_inactive() bug? -> panic: lockmgr: locking against myself
Ian Dowse wrote: > And I've just remembered a fifth :-) I think the old BSD code had > both an `open' count and a reference count. The open count is a > count of the real users of the vnode (it is what ufs_inactive really > wants to compare against 0), and the reference count is just for > places that you don't want the vnode to be recycled or destroyed. > This was probably lost when the encumbered BSD sources were rewritten. No, this went away with the vnode locking changes; it was in the 4.4 code, for sure. I think references are the correct thing here, and SunOS seems to agree, since that's how they implement, too. 8-). > At the time I was looking at it last, I remember thinking that the > open count would allow vrele/vput to keep the reference count at 1 > during the VOP_INACTIVE() call, which is what you were proposing. > It would also allow us to fix the problem of many places not matching > each VOP_OPEN() with a VOP_CLOSE(). I suspect we could clean up a > lot of related problems if the open count was brought back. Yes. It was murdered for good reason. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any problems with increaseing the dump(8) block size?
On Wed, Sep 11, 2002 at 10:16:40PM -0500, Dan Nelson wrote: > In the last episode (Sep 11), David O'Brien said: > > I'd like to make this commit to get better performance on today's > > streaming tape drives. It seems my DLT drive doesn't stream well > > with the default block size of '10'. > > Only if we also raise dd's and tar's default blocksizes to 64k as well :) Why do these two need to be linked to dump(8)? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking problems in exec
On 11-Sep-2002 Don Lewis wrote:
> On 11 Sep, John Baldwin wrote:
>>
>> On 11-Sep-2002 Don Lewis wrote:
>>> On 10 Sep, Don Lewis wrote:
On 10 Sep, Nate Lawson wrote:
> I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen
> before grabbing the proc lock. Dropping locks in the middle or
> pre-allocating should always be a last resort.
That is ok as long as there aren't other threads that can mess things up
after fdcheckstd() and setugidsafety() have done their thing.
>>>
>>> It looks like threads aren't a problem because of the call to
>>> thread_single() at the top of execve(). Ptrace() is still a potential
>>> problem, so we can't call fdcheckstd() and setugidsafety() until after
>>> credential_changing has been calculated, setsugid() has been called and
>>> tracing has been disabled, all of which are done after proc lock has
>>> been grabbed.
>>>
>>> It also looks like we should pre-allocate newprocsig instead of
>>> temporarily dropping the lock.
>>
>> We used to do that but backed it out because it wasn't deemed to be
>> that necessary. If you have a demonstrable problematic race condition
>> that this fixes then it might be a good idea. However, allocating
>> stuff we don't need isn't but so great either.
>
> I haven't observed any problems with the procsig stuff, but it sure hit
> me in the eye when I was scanning the code to see if the fdcheckfd()
> could be done before grabbing the proc lock. The mp_fixme() suggests to
> me that the entire if block is going to be protected by its own lock
> sometime in the future:
>
> PROC_LOCK(p);
> mp_fixme("procsig needs a lock");
This is about adding a lock to the procsig structure itself. The proc
lock does not protect the procsig reference count, etc. The proc lock
just protects the actual p_procsig member of struct proc.
> if (p->p_procsig->ps_refcnt > 1) {
> oldprocsig = p->p_procsig;
> PROC_UNLOCK(p);
> MALLOC(newprocsig, struct procsig *, sizeof(struct procsig),
> M_SUBPROC, M_WAITOK);
> bcopy(oldprocsig, newprocsig, sizeof(*newprocsig));
> newprocsig->ps_refcnt = 1;
> oldprocsig->ps_refcnt--;
> PROC_LOCK(p);
> p->p_procsig = newprocsig;
> if (p->p_sigacts == &p->p_uarea->u_sigacts)
> panic("shared procsig but private sigacts?");
>
> p->p_uarea->u_sigacts = *p->p_sigacts;
> p->p_sigacts = &p->p_uarea->u_sigacts;
> }
>
>
> We probably won't want to hold the lock across the call to MALLOC(), and
> dropping the lock and possibly blocking, giving ps_refcnt the
> opportunity to change behind our back, doesn't seem wise. Copying a
> shared object and manipulating its reference count while it is unlocked
> doesn't sound wise either. We may be protected in other ways at the
> moment, but this code suggests to me that this won't always be the case.
procsig doesn't have any locks on it yet. At some point it will, but for
now Giant is what handles that case.
>> I think ptrace(2)
>> is not an issue because ptrace(2) won't attach to a P_INEXEC process
>> IIRC.
>
> I think you're correct, but we still can't call fdcheckstd() before we
> know that we are doing the set-id case, and that decision is made after
> we've grabbed the proc lock. Do you think it is reasonable to
> temporarily drop the proc lock for the fdcheckstd() call?
Yes. Between single-threading the process and P_INEXEC most of the
proc-related races in exec() are handled.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vsnprintf(3) memory leak patch, misc/26044 and bin/36175
On 18:46+0400, Sep 12, 2002, Kris Kennaway wrote:
> On Thu, Sep 12, 2002 at 12:02:45PM +0400, Maxim Konovalov wrote:
>
> > + /* Stdio internals do not deal correctly with zero length buffer */
>
> I thought ache fixed a lot of these; are you sure the situation still
> applies to -current?
Yes, it still leaks. Testcase from misc/26044:
main() {for(;;) vsnprintf(0, 0, "yadda yadda!\n");};
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: nfs_inactive() bug? -> panic: lockmgr: locking against myself
In message <[EMAIL PROTECTED]>, Don Lewis writes: >After looking at ufs_inactive(), I'd like to add a fourth proposal And I've just remembered a fifth :-) I think the old BSD code had both an `open' count and a reference count. The open count is a count of the real users of the vnode (it is what ufs_inactive really wants to compare against 0), and the reference count is just for places that you don't want the vnode to be recycled or destroyed. This was probably lost when the encumbered BSD sources were rewritten. At the time I was looking at it last, I remember thinking that the open count would allow vrele/vput to keep the reference count at 1 during the VOP_INACTIVE() call, which is what you were proposing. It would also allow us to fix the problem of many places not matching each VOP_OPEN() with a VOP_CLOSE(). I suspect we could clean up a lot of related problems if the open count was brought back. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Circumvention for sys/net/if_ethersubr.c
OK; it's probably rather like a sledgehammer, but I got the kernel to compile and run with the following patch: Index: sys/net/if_ethersubr.c === RCS file: /cvs/freebsd/src/sys/net/if_ethersubr.c,v retrieving revision 1.120 diff -u -r1.120 if_ethersubr.c --- sys/net/if_ethersubr.c 12 Sep 2002 01:05:46 - 1.120 +++ sys/net/if_ethersubr.c 12 Sep 2002 14:31:30 - @@ -463,8 +463,10 @@ int i; struct ip_fw_args args; +#ifdef IPFIREWALL if (*rule != NULL && fw_one_pass) return 1; /* dummynet packet, already partially processed */ +#endif /* IPFIREWALL */ /* * I need some amt of data to be contiguous, and in case others need As evidenced by: freebeast(5.0-C)[1] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #30: Thu Sep 12 07:41:46 PDT 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast(5.0-C)[2] Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vsnprintf(3) memory leak patch, misc/26044 and bin/36175
On Thu, Sep 12, 2002 at 12:02:45PM +0400, Maxim Konovalov wrote: > + /* Stdio internals do not deal correctly with zero length buffer */ I thought ache fixed a lot of these; are you sure the situation still applies to -current? Kris msg42930/pgp0.pgp Description: PGP signature
lcms port cms testbed failure
Hi I'm getting lcms port build failure in cms testing phase. The system I'm building the port on (actually building kdegames3) is P4 with Intel i845 chipset. World and kernel are built with system gcc-3.2 with CPUTYPE=p4. The main goal is to build a set of packages for an old P2 system thus CPUTYPE is set to p2 for port building. Is it illegal to optimise system binaries to p4 and then build ports with p2 optimisation? cc -fpic -DPIC -O -pipe -march=pentium2 -march=pentium2 -I/usr/local/src/portbuild/usr/ports/graphics/lcms/work/lcms-1.08/src/../include -c cmscam97.c -o cmscam97.So building static lcms library ranlib liblcms.a building shared library liblcms.so.1 cd /usr/local/src/portbuild/usr/ports/graphics/lcms/work/lcms-1.08/src/../testbed && /usr/bin/env CFLAGS="-O -pipe -march=pentium2 -I../include" make -E CFLAGS test cc -O -pipe -march=pentium2 -I../include -c testcms.c cc -O -pipe -march=pentium2 -I../include testcms.o ../src/liblcms.a -o testcms -lm ./testcms little cms testbed. Ver 1.08 [build Sep 12 2002 16:41:45] Testing fixed point: 2.8848960205 = 2.8848 0.437499269828536 = 0.4374 Testing fixed scaling...pass. Testing linear interpolation ...pass. (66 tics) Testing descending tables (linear interpolation)...pass. Testing reverse linear interpolation on normal monotonic curve...pass. on degenerated curve ...pass. Testing 3D interpolation on LUT...pass. Testing virtual profiles (Emulating sRGB)...pass. Testing sRGB built-in space.Coarse error: In=(0,0,7373) Out1=(1.23009,-126.672,-112.328) Out2=(0,-128,-128) *** Error code 1 Stop in /usr/local/src/portbuild/usr/ports/graphics/lcms/work/lcms-1.08/testbed. *** Error code 1 Stop in /usr/ports/graphics/lcms. *** Error code 1 Stop in /usr/ports/graphics/libmng. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt30. *** Error code 1 Stop in /usr/ports/games/kdegames3. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nfs_inactive() bug? -> panic: lockmgr: locking against myself
On 11 Sep, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Don Lewis writes: >> >>A potentially better solution just occurred to me. It looks like it >>would be better if vrele() waited to decrement v_usecount until *after* >>the call to VOP_INACTIVE() (and after the call to VI_LOCK()). If that >>were done, nfs_inactive() wouldn't need to muck with v_usecount at all. > > I've looked at this before; I think some filesystems (ufs anyway) > depend on v_usecount being 0 when VOP_INACTIVE() is called. Yup, though it would easy to tweak ufs_inactive() to expect the v_usecount to be one greater. A bigger problem is the call to vrecycle() in ufs_inactive(). > The > patch I have had lying around for quite a while is below. It adds > a vnode flag to avoid recursion into the last-reference handling > code in vrele/vput, which is the real problem. > > It also guarantees that a vnode will not be recycled during > VOP_INACTIVE(), so the nfs code no longer needs to hold an extra > reference in the first place. The flag manipulation code got a bit > messy after Jeff's vnode flag splitting work, so the patch could > probably be improved. If the need for nfs_inactive() to manipulate the reference count is eliminated, that should be sufficient to eliminate the vrele/vput recursion problem as well. > Whatever way this is done, we should try to avoid adding more hacks > to the nfs_inactive() code anyway. Tweaking nfs_inactive() has the advantage of being the least intrusive fix for this problem, but it isn't architecturally clean. I'd also argue that decrementing the vnode reference count to zero, but holding on to the reference for an extended period of time while doing I/O on the vnode is also a kludge. It also causes problems that require kludgey fixes, like the reference count manipulation in nfs_inactive(). For the most part the VI_INACTIVE flag is just another way of indicating that we are holding a reference to the vnode, so both the flag and the reference count need to be checked to see if the vnode is in use. The advantage of adding this flag versus just bumping the reference count is that the flag allows us to avoid the bugs in the current implementation while not requiring changes to code that expects the reference count to be zero in code called from VOP_INACTIVE(). Here are the three proposed fixes along with their advantages and disadvantages: Inline the v_usecount decrement code in nfs_inactive() + Least intrusive fix for the recursion bug - Adds a kludge to a kludge Call VOP_INACTIVE() before decrementing the reference count and tweak the foo_inactive() methods to expect the reference count to be one instead of zero + Eliminates the kludge from nfs_inactive() + We aren't lying about holding a reference, so hopefully less potential for bugs - It is not obvious to how to adapt ufs_inactive() Add VI_INACTIVE flag to prevent the vnode from being recycled + Eliminates the kludge from nfs_inactive() + Doesn't require changes to the other filesystems - Code complexity - Programmer needs to know when to look at VI_INACTIVE and when looking at just the reference count is ok After looking at ufs_inactive(), I'd like to add a fourth proposal that would involve splitting VOP_INACTIVE() into two separate methods. The first method would be called before the reference count is decremented and would do any I/O. The second method would be called after the reference count is decremented and could only be used for freeing resources, manipulating flags, putting it on the free list with vrecycle(), etc. + Eliminates the kludge from nfs_inactive() + We don't lie about holding a reference while doing I/O - More extensive code changes - Bikeshed arguments about what to call the two methods To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/var/tmp/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Sep 12 06:07:49 PDT 2002 -- ===> vinum building __divqu.S from /var/tmp/des/src/sys/alpha/alpha/divrem.m4 building __divq.S from /var/tmp/des/src/sys/alpha/alpha/divrem.m4 building __divlu.S from /var/tmp/des/src/sys/alpha/alpha/divrem.m4 building __divl.S from /var/tmp/des/src/sys/alpha/alpha/divrem.m4 building __remqu.S from /var/tmp/des/src/sys/alpha/alpha/divrem.m4 building __remq.S from /var/tmp/des/src/sys/alpha/alpha/divrem.m4 building __remlu.S from /var/tmp/des/src/sys/alpha/alpha/divrem.m4 building __reml.S from /var/tmp/des/src/sys/alpha/alpha/divrem.m4 linking kernel.debug if_ethersubr.o: In function `ether_ipfw_chk': if_ethersubr.o(.text+0xa0c): undefined reference to `fw_one_pass' *** Error code 1 Stop in /var/tmp/des/obj/var/tmp/des/src/sys/GENERIC. *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic during reboot in vflush()
On Thu, 12 Sep 2002, Maxim Sobolev wrote: > Any ideas? See the thread about "Page faults from bento cluster (Re: Problems reading vmcores)]" which seemed to diagnose this. The last mail that I got about this pointed to: http://www.chesapeake.net/~jroberson/VFSsmp.patch As a workaround, try unmounting most of your filesystems from userland using umount -A. Don't use umount -f. (There seems to be a problem with the MNT_FORCECLOSE case in vflush(). MNT_FORCECLOSE is set more than I thought: it is always set for the final unmount done by reboot(2)). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Can't compile XFree86-4-Server
Hi
For a few days the XFree86-4-Server compilation fails with following
error. I'm running -current as of yesterday with kan's patch. The
world and kernel is built with CPUTYPE=p4 and I'm trying to build
complete set of packages for an old P2, thus CPUTYPE=p2 for entire
package build.
rm -f miPck1Prim.o
LD_LIBRARY_PATH=../../../../../../exports/lib cc -O -pipe -march=pentium2
-march=pentium2 -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith
-fno-merge-constants -I. -I../include
-I../../../../../../exports/include/X11 -I../../../include
-I../../../../../../programs/Xserver/include -I../../../../../..
-I../../../../../../exports/include -DCSRG_BASED -DSHAPE -DXINPUT -DXKB -DLBX
-DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX
-DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA
-DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension
-DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15
-DNARROWPROTO -DIN_MODULE -DXFree86Module-c miPck1Prim.c
miPck1Prim.c: In function `CheckFAreaPick1':
miPck1Prim.c:337: unable to find a register to spill in class `FLOAT_REGS'
miPck1Prim.c:337: this is the insn:
(insn 275 273 277 (set (subreg:SF (reg/v:DI 29 rmm0 [64]) 0)
(float:SF (mem/s/j:HI (reg/v/f:SI 2 ecx [61]) [0 .x+0 S2 A16]))) 167
{floathisf2} (insn_list 271 (nil))
(nil))
miPck1Prim.c:337: confused by earlier errors, bailing out
*** Error code 1
Stop in
/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/PEX5/ddpex/mi/level1.
*** Error code 1
Stop in
/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/PEX5.
*** Error code 1
Stop in
/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver.
*** Error code 1
Stop in
/usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs.
*** Error code 1
Stop in /usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc.
*** Error code 1
Stop in /usr/local/src/portbuild/usr/ports/x11-servers/XFree86-4-Server/work/xc.
*** Error code 1
Stop in /usr/ports/x11-servers/XFree86-4-Server.
*** Error code 1
Stop in /usr/ports/x11/XFree86-4.
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Q: Problems with device hints?
Hi! I get some strange messages during device probing on my Current machine. I was pointed out that these might be due to device hints in /boot or compiled / configured into my kernel. Unfortunately I could not find any device hints that look at all like the messages I get during bootup (or when loading driver modules): digi1: 0x378: Invalid i/o address unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) digi1: 0x061: Invalid i/o address unknown: can't assign resources (port) unknown: can't assign resources (irq) Could anyone point me to a place where I can learn how to get rid of these messages, as I guess they are due to some wrong configuration of my system. Regards, Robert S. -- Robert Suetterlin ([EMAIL PROTECTED]) phone: (+49)89 / 3-3546 fax: (+49)89 / 3-3950 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Thu Sep 12 11:46:18 GMT 2002 -- ===> GENERIC Kernel build directory is /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sys/GENERIC Don't forget to do a ``make depend'' ./aicasm: 877 instructions used linking kernel.debug if_ethersubr.o: In function `ether_ipfw_chk': if_ethersubr.o(.text+0x848): undefined reference to `fw_one_pass' if_ethersubr.o(.text+0x84c): undefined reference to `fw_one_pass' *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
digi_Xem: Failed to autoload module: No filesystem
Hello! In my lab I use a digi Xem multiport serial card. Since approx. one week I get the following error message during bootup: digi0 mem 0xb080-0xb0bf irq 10 at device 4.0 on pci0 digi_Xem: Failed to autoload module: No filesystem If I load the digi driver after bootup there is no problem autoloading the digi_Xem module. Regards, Robert S. -- Robert Suetterlin ([EMAIL PROTECTED]) phone: (+49)89 / 3-3546 fax: (+49)89 / 3-3950 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problems with drivers lge and miibus on D-Link DGE 500SX
Hello! I'm using the D-Link DGE 500SX Gigabit Ethernet card in two of my computers. One is running FreeBSD Current, the other runs Stable. The lge driver (and miibus with xmphy) worked well on both systems. Somewhen between Juli this August this Year, the Current driver stopped working with the following problem description: lge0: Ethernet address: 00:50:ba:71:2d:c3 lge0: MII without any PHY! device_probe_and_attach: lge0 attach returned 6 Sorry I did not notice the problem immediately, but all my systems are dual homed and the default gateway is over 100MBit Ethernet. Regards, Robert S. -- Robert Suetterlin ([EMAIL PROTECTED]) phone: (+49)89 / 3-3546 fax: (+49)89 / 3-3950 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any problems with increaseing the dump(8) block size?
On Wed, 11 Sep 2002, Dan Nelson wrote: > In the last episode (Sep 11), David O'Brien said: > > I'd like to make this commit to get better performance on today's > > streaming tape drives. It seems my DLT drive doesn't stream well > > with the default block size of '10'. > > Only if we also raise dd's and tar's default blocksizes to 64k as well :) > > How about raising BUFSIZE (no smiley)? Tru64 and Linux both have an 8k > stdio buffer. Why do the other systems use such a small buffer? :-) BSD stdio normally uses st_blksize, which is 16K for regular files on ffs filesystems created with the current defaults, and 8K for regular files on ffs filesystems ceeated with old defaults. st_blksize used to be quite variable and usually too large (64K) for special files, but it is now not very variable and usually too small (PAGE_SIZE) for special files. BUFSIZ is only used in broken cases where the kernel sets st_blksize to 0 or a naive application uses BUFSIZ or the old setbuf() interface. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel from latest cvsup refuses to boot. - hangs
> On Wed, 11 Sep 2002 11:30:55 -0700 (PDT), Nate Lawson <[EMAIL PROTECTED]> said: Nate> tell without more info. Enable options DDB, boot -vs, wait for the Nate> hang. Hit CTRL-ALT-ESC to go into DDB and type tr to get a Nate> backtrace. Copy the trace info (serial console is best for this). Hit c Nate> for continue, wait, repeat. Chances are you'll still be at the same Nate> backtrace. If so, then this is the code that's hanging. Hi, I am using the default GENERIC kernel and it already has DDB compiled in. When I try to do what you suggested above, nothing happens. It is still in the hung state. No changes. And I don't have a serial console that I can setup :( TIA Regards Sid -- /earth is 98% full ... please delete anyone you can. Sid Carter - http://symonds.net/~sidcarter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
On 12 Sep, Martin Blapp wrote: > Just a thought ... What type of disks are you using? I'm running SCSI >> here. > > ATA ... But I should see disk errors then ... > > I've bought now new disks and will try to build on them. It's not that I think your hardware is defective. I'm wondering if differences in the disk driver code and differences in the I/O completion order might be the reason that you are seeing problems but I am not. There also may be code modifications that were committed at about the same time as the compiler upgrade that are causing the problems that you are seeing. A binary search between a version of the source that was working for you and a version that exhibits these errors would probably be informative, but that would be a fairly major undertaking. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
Hi, > > options DISABLE_PSE > options DISABLE_PG_G I use that too. With them enabled I see memory corruption. > Just a thought ... What type of disks are you using? I'm running SCSI > here. ATA ... But I should see disk errors then ... I've bought now new disks and will try to build on them. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
On 12 Sep, Martin Blapp wrote: > > Hi, > >> If I were you I'd start swapping memory modules, because I'm not having > > Already did that. I even used ECC ram. > >> any trouble with -CURRENT and I havn't seen anyone else having trouble. > > Did you try to build a huge project ? If I don't compile anything big > and load the machine it works perfectly. > >> Did you compile your kernel with any wierd optimizations? > > No. > > And this system works perfectly before after I turned on PG_G. > > The instability began after gcc3.2 import. I've haven't had any trouble building and running openoffice since the 3.2 import. I had to add the following kernel options: options DISABLE_PSE options DISABLE_PG_G because I was seeing memory corruption after the system had been in use for a while. If I ran a number of "make buildworld" runs one after another, I'd start seeing compile errors after about five or six buildworld runs. I never saw any kernel panics either with or without these options, ether doing system rebuilds or building openoffice. I last cvsup'ed and rebuilt the system about three days ago. Since then, the only problems I've had are a few warnings about lock order reversals and kernel malloc calls with locks held, and some problems that the DEBUG_VFS_LOCKS option found in the nfs client code. Just a thought ... What type of disks are you using? I'm running SCSI here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic during reboot in vflush()
Maxim Sobolev wrote: > Any ideas? Looks like some other processes was modifying the mountlist while vfs_unmountall() was running. Is this an SMP box ? It would be nice if you could check in gdb which other process was holding the mountlist_mtx mutex if any. The vfs_unmountall() function doesn't acquire the mounstlist_mtx and states this is OK in a comment because this functions is ran upon reboot, but I suspect this is incorrect and we still need to do the locking. I'll write a patch tonight to add locking into vfs_unmountall(), but it may be hard to test unless you know of a way to reproduce this panic easily. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vsnprintf(3) memory leak patch, misc/26044 and bin/36175
Hello -current,
Our vsnprintf(3) has a memory leak, take a look at
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/36175 and
http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/26044
for details.
Any objections against a patch below (from OpenBSD)?
Index: libc/stdio/vsnprintf.c
===
RCS file: /home/ncvs/src/lib/libc/stdio/vsnprintf.c,v
retrieving revision 1.20
diff -u -r1.20 vsnprintf.c
--- libc/stdio/vsnprintf.c 6 Sep 2002 11:23:56 - 1.20
+++ libc/stdio/vsnprintf.c 12 Sep 2002 07:55:53 -
@@ -50,6 +50,7 @@
{
size_t on;
int ret;
+ char dummy;
FILE f;
struct __sFILEX ext;
@@ -58,6 +59,11 @@
n--;
if (n > INT_MAX)
n = INT_MAX;
+ /* Stdio internals do not deal correctly with zero length buffer */
+ if (n == 0) {
+str = &dummy;
+n = 1;
+ }
f._file = -1;
f._flags = __SWR | __SSTR;
f._bf._base = f._p = (unsigned char *)str;
%%%
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Softupdate panic: softdep_update_inodeblock: update failed
Hi, > > Oh ok, wierd... I've only tried (unsuccessfully, the compiler errors out) > > kde3, and some make worlds and stuff. I guess that's not strenuous enough. > > kde3 compiled okay for me with Alexander Kabaev's gcc patch posted to > this ML. I could compile KDE, XFree86 and make buildworld on this box without a problem with Alexanders patches. They just don't seem to be that big as OpenOffice. And OO uses threaded programs to build. (6,8 billion of code with mozilla not counting). Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic during reboot in vflush()
Any ideas?
max@notebook$ gdb -k /sys/i386/compile/NOTEBOOK/kernel.debug
/var/crash/vmcore.0
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01484c0
stack pointer = 0x10:0xc5847b58
frame pointer = 0x10:0xc5847b70
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 = 1 (init)
trap number = 12
panic: page fault
Uptime: 9h4m54s
Dumping 64 MB
ata0: resetting devices ..
done
16 32 48
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc018195f in boot (howto=256) at
../../../kern/kern_shutdown.c:345
#2 0xc0181b1c in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc027f719 in trap_fatal (frame=0xc5847b18, eva=40) at
../../../i386/i386/trap.c:846
#4 0xc027f470 in trap_pfault (frame=0xc5847b18, usermode=0, eva=40)
at ../../../i386/i386/trap.c:760
#5 0xc027ef31 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi =
-981173284, tf_ebp = -981173392, tf_isp = -981173436, tf_ebx =
-1059837928, tf_edx = -1065459456, tf_ecx = 0, tf_eax = -981173284,
tf_trapno = 12, tf_err = 0, tf_eip = -1072397120, tf_cs = 8, tf_eflags
= 66118, tf_esp = -981173284, tf_ss = -981173284}) at
../../../i386/i386/trap.c:446
#6 0xc02726d8 in calltrap () at {standard input}:98
#7 0xc01c813f in vflush (mp=0x0, rootrefs=1, flags=2) at
vnode_if.h:309
#8 0xc0148107 in devfs_unmount (mp=0xc07be800, mntflags=524288,
td=0xc0625000) at ../../../fs/devfs/devfs_vfsops.c:130
#9 0xc01c47bc in dounmount (mp=0xc07be800, flags=524288,
td=0xc0625000) at ../../../kern/vfs_mount.c:1296
#10 0xc01c9496 in vfs_unmountall () at ../../../kern/vfs_subr.c:2924
#11 0xc01818ca in boot (howto=16392) at
../../../kern/kern_shutdown.c:330
#12 0xc018125f in reboot (td=0xc0625000, uap=0x0) at
../../../kern/kern_shutdown.c:154
#13 0xc027f9cd in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134835213, tf_esi
= -1077936616, tf_ebp = -1077936784, tf_isp = -981172876, tf_ebx =
-1077936704, tf_edx = -1, tf_ecx = 4, tf_eax = 55, tf_trapno = 12,
tf_err = 2, tf_eip = 134543403, tf_cs = 31, tf_eflags = 515, tf_esp =
-1077936968, tf_ss = 47}) at ../../../i386/i386/trap.c:1050
#14 0xc027272d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) up
#1 0xc018195f in boot (howto=256) at
../../../kern/kern_shutdown.c:345
345 doadump();
(kgdb) up
#2 0xc0181b1c in panic () at ../../../kern/kern_shutdown.c:493
493 boot(bootopt);
(kgdb) up
#3 0xc027f719 in trap_fatal (frame=0xc5847b18, eva=40) at
../../../i386/i386/trap.c:846
846 panic("%s", trap_msg[type]);
(kgdb) up
#4 0xc027f470 in trap_pfault (frame=0xc5847b18, usermode=0, eva=40)
at ../../../i386/i386/trap.c:760
760 trap_fatal(frame, eva);
(kgdb) up
#5 0xc027ef31 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi =
-981173284, tf_ebp = -981173392, tf_isp = -981173436, tf_ebx =
-1059837928, tf_edx = -1065459456, tf_ecx = 0, tf_eax = -981173284,
tf_trapno = 12, tf_err = 0, tf_eip = -1072397120, tf_cs = 8, tf_eflags
= 66118, tf_esp = -981173284, tf_ss = -981173284}) at
../../../i386/i386/trap.c:446
446 (void) trap_pfault(&frame, FALSE,
eva);
(kgdb) up
#6 0xc02726d8 in calltrap () at {standard input}:98
98 {standard input}: No such file or directory.
in {standard input}
Current language: auto; currently asm
(kgdb) up
#7 0xc01c813f in vflush (mp=0x0, rootrefs=1, flags=2) at
vnode_if.h:309
309 rc = VCALL(vp, VOFFSET(vop_getattr), &a);
Current language: auto; currently c
(kgdb) print *vp
$2 = {v_interlock = {mtx_object = {lo_class = 0xc02cb4c0, lo_name =
0xc02a785b "vnode interlock",
lo_type = 0xc02a785b "vnode interlock", lo_flags = 196608,
lo_list = {tqe_next = 0x0, tqe_prev = 0x0},
lo_witness = 0x0}, mtx_lock = 4, mtx_recurse = 0, mtx_blocked =
{tqh_first = 0x0, tqh_last = 0xc0d4283c},
mtx_contested = {le_next = 0x0, le_prev = 0x0}, mtx_acqtime = 0,
mtx_filename = 0x0, mtx_lineno = 0}, v_iflag = 256,
v_usecount = 0, v_writecount = 0, v_numoutput = 0, v_vxproc = 0x0,
v_holdcnt = 0, v_vflag = 0, v_id = 788200,
v_mount
