[RFC] Change OpenSSL derived digest functions to return boolean values
Hi,
I put a patch to Phabricator and Github.
https://reviews.freebsd.org/D1542
https://github.com/kuriyama/freebsd/compare/openssl-digest-return-value
Any comments are welcome!
DESCRIPTION
OpenSSL changed return value type of *_{Init,Update,Final}() functions
at 2001 [1]. Our implementations at libmd do not follow these changes.
[1]
https://github.com/openssl/openssl/commit/2dc769a1c17e1e0c7aef6e11496c8ba2c1db2e28
BACKGROUND
I noticed this problem during using install(1) with net/nss_ldap,
net/openldap24-client and ldaps:// protocol. While install(1) is
linked with libmd, but ports libldap is compiled with libcrypto to
expect OpenSSL's SHA1_Update() function. When using install(1) in this
situation, install(1) uses libmd's SHA1_Update(), but wrapping
functions in OpenSSL expects SHA1_Update() to return boolean. This
causes sometimes fails SHA1_Update() (which depends on value of EAX
register?) call.
Problem is, we have SHA1_Update() functions in libmd and libcrypto,
and both has different return value types. This should be same if they
provides identical functionality.
TBD
Should adjust {SHA{256,512}_,MDX}{Init,Update,Final}() functions, too?
--
Jun Kuriyama // FreeBSD Project
// S2 Factory, Inc.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -current lockup (how to diagnose?)
At Tue, 2 Dec 2003 01:45:43 -0500 (EST),
Robert Watson wrote:
> Could you try compiling in DEBUG_LOCKS into your kernel and doing "show
> lockedvnods" with that?
Okay. I'll use new kernel with DEBUG_LOCKS.
> Unfortunately, someone removed the pid from the
> output of that command, but didn't add the thread pointer to the DDB ps
> output, so you'll probably need to modify the lockmgr_printinfo() function
> in vfs_subr.c to print out lkp->lk_lockholder->td_proc->p_pid as well for
> exclusive locks.
I don't understand what it means, but I'll try with this modification.
Index: kern_lock.c
===
RCS file: /home/ncvs/src/sys/kern/kern_lock.c,v
retrieving revision 1.70
diff -u -r1.70 kern_lock.c
--- kern_lock.c 16 Jul 2003 01:00:38 - 1.70
+++ kern_lock.c 2 Dec 2003 07:04:49 -
@@ -611,8 +611,8 @@
printf(" lock type %s: SHARED (count %d)", lkp->lk_wmesg,
lkp->lk_sharecount);
else if (lkp->lk_flags & LK_HAVE_EXCL)
- printf(" lock type %s: EXCL (count %d) by thread %p",
- lkp->lk_wmesg, lkp->lk_exclusivecount, lkp->lk_lockholder);
+ printf(" lock type %s: EXCL (count %d) by thread %p (pid:%d)",
+ lkp->lk_wmesg, lkp->lk_exclusivecount, lkp->lk_lockholder,
lkp->lk_lockholder->td_proc->p_pid);
if (lkp->lk_waitcount > 0)
printf(" with %d pending", lkp->lk_waitcount);
}
> It looks like maybe something isn't releasing a vnode
> lock before returning to userspace. I have some patches to assert that no
> lockmgr locks are held on the return to userspace, but I'll have to dig
> them up tomorrow and send them to you. Basically, it adds a per-thread
> lockmgr lock count in a thread-local variable, incrementing for each lock,
> and decrementing for each release, and then KASSERT()'s in userret that
> the variable is 0.
Thanks! I'm waiting for your patch.
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: -current lockup (how to diagnose?)
At Mon, 1 Dec 2003 09:23:21 -0500 (EST), Robert Watson wrote: > This could be a sign of a VM or VFS lock leak or deadlock. I'd advise > hooking up a serial console, dropping to DDB over serial line, and posting > the results of "ps" and "show lockedvnods". We might then ask you to use > the "show locks" command on various processes. You'll need to have DDB > and WITNESS compiled in. I got it. http://www.imgsrc.co.jp/~kuriyama/BSD/lock-20031202.log -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: -current lockup (how to diagnose?)
At Mon, 1 Dec 2003 09:23:21 -0500 (EST), Robert Watson wrote: > This could be a sign of a VM or VFS lock leak or deadlock. I'd advise > hooking up a serial console, dropping to DDB over serial line, and posting > the results of "ps" and "show lockedvnods". We might then ask you to use > the "show locks" command on various processes. You'll need to have DDB > and WITNESS compiled in. He he, I of course have serial console, DDB and WITNESS. They are good safety belf fot -current users, isn't it? :-) I'll post information above next time. Thanks! -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: -current lockup (how to diagnose?)
At Mon, 1 Dec 2003 14:39:56 +0100, Melvyn Sopacua wrote: > > > o KDE's clock is working. > > > o KDE's virtual screen switching is working. > > > o Apache does not reply on 80/tcp from remote. > > > o ssh from this box is still working. > > But ssh *to* the box doesn't right? Yes. > I've had this on -STABLE as well and indeed KDE seems to be related. Also, I > recall this to happen during the security check or rebuilding the locate > database. I haven't seen this once I installed more memory. > > A good tell-tale is: > * Switch to the console. > * Select another VT, via ALT-F2 > * Type in the login name and press enter > > You won't get a passwd prompt. Yes, I can see the same situation. > Most of the time I got outof it, by CTRL-ALT-F1 and CTRL-C. Hmm, I'll try next time. > I think I have a weekly run report somewhere, reporting 'vm exhaustion' > errors. I can dig it up if it's helpful. > At the time, the box had 128Megs of RAM and 256MB swap, P-III 450. My box has 2GB memory, so it would be enough. My box makes world and release nightly and it locks usually at that time. Anyway, I'm waiting for next lock ups. :-) -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-current lockup (how to diagnose?)
I got lockups in recent -current box. This box is my main workstation and usually be up to date kernel. In recent days, I usually locked up. This is not a panic, only locks up. My situation is: o KDE's clock is working. o KDE's virtual screen switching is working. o Apache does not reply on 80/tcp from remote. o ssh from this box is still working. o zsh on this box does not go next prompt when I press enter key at promprt. It looks kernel is working, but fork/exec is not working when I enter to this situation. So, what can I diagnose with this situation? Of course this box has serial console. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: anoncvs
At Sat, 29 Nov 2003 01:02:59 + (UTC), Matt Bell wrote: > is there still an ongoing problem with anoncvs? > > anoncvs.freebsd.org(209.181.243.20):2401 failed: Connection refused Sorry, this box is waiting for console operation after upgrading failure. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: boot process is too slow during installation
At Thu, 27 Nov 2003 09:49:04 + (UTC), Zhang Shu wrote: > I am trying to install the current-FreeBSD to my Vaio PCG-Z1/P but found > the installation boot process is extremely slow. It takes more than 10 > minutes to finish loading the disk created from kern.flp and another 10 > minutes for mfsroot.flp. Does anyone know what the problem is? > > The USB floppy drive I am using is sony's PCGA-UF05. The same thing > happens with another USB floppy drive which I don't remember the model. > > I also tried to boot the installation disks of 4.8R, 4.9R and 5.1R but > the result were the same. I haven't seen fast USB floppy drive. So I think all of USB floppy drive may be too slow... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: vm_fault: fault on nofault entry
, tf_eip = 671916175, tf_cs = 31, tf_eflags =
518, tf_esp = -1077942388, tf_ss = 47})
at ../../../i386/i386/trap.c:1010
#25 0xc06faa2d in Xint0x80_syscall () at {standard input}:136
---Can't read userspace from dump, or kernel process---
(kgdb) up 11
#11 0xc06b0fae in vm_fault (map=0xc1031000, vaddr=3673116672,
fault_type=1 '\001', fault_flags=0) at ../../../vm/vm_fault.c:891
891 KASSERT(fs.m->flags & PG_BUSY,
(kgdb) list
886 }
887
888 /*
889 * Page had better still be busy
890 */
891 KASSERT(fs.m->flags & PG_BUSY,
892 ("vm_fault: page %p not busy!", fs.m));
893 /*
894 * Sanity check: page must be completely valid or it is not fit to
895 * map into user space. vm_pager_get_pages() ensures this.
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: vm_fault: fault on nofault entry
(kgdb) down
#14 0xc06fa578 in calltrap () at {standard input}:94
94 {standard input}: No such file or directory.
in {standard input}
Current language: auto; currently asm
(kgdb) list
89 in {standard input}
(kgdb) up
#15 0xc069bea2 in ffs_vget (mp=0xd121dc00, ino=3469149696, flags=2,
vpp=0xed1768e0) at ../../../ufs/ffs/ffs_vfsops.c:1333
1333ffs_load_inode(bp, ip, fs, ino);
Current language: auto; currently c
(kgdb) p bp
$1 = (struct buf *) 0xd4ba34b0
(kgdb) p ip
$2 = (struct inode *) 0xcbb33c08
(kgdb) p fs
$3 = (struct fs *) 0xc99f7800
(kgdb) p ino
$4 = 3469149696
(kgdb) p *bp
$5 = {b_io = {bio_cmd = 2, bio_dev = 0xd23d1d00, bio_disk = 0x0,
bio_offset = 28672, bio_bcount = 4096, bio_data = 0xd84a4000 "",
bio_flags = 4, bio_error = 0, bio_resid = 0,
bio_done = 0xc05aca10 , bio_driver1 = 0x0, bio_driver2 = 0x0,
bio_caller1 = 0x0, bio_caller2 = 0xd4ba34b0, bio_queue = {tqe_next = 0x0,
tqe_prev = 0x0}, bio_attribute = 0x0, bio_from = 0x0, bio_to = 0x0,
bio_length = 0, bio_completed = 0, bio_children = 294, bio_inbed = 0,
bio_parent = 0x0, bio_t0 = {sec = 0, frac = 0}, bio_task = 0,
bio_task_arg = 0x0, bio_pblkno = 0}, b_op = 0xc07b6848,
b_magic = 280038160, b_iodone = 0, b_blkno = 56, b_offset = 28672,
b_vnbufs = {tqe_next = 0xd4a5c4d0, tqe_prev = 0xd4c63674},
b_left = 0xd4c635d0, b_right = 0xd4a5c4d0, b_vflags = 0, b_freelist = {
tqe_next = 0xd4c635d0, tqe_prev = 0xd4b6da08}, b_qindex = 0,
b_flags = 537002144, b_xflags = 1 '\001', b_lock = {
lk_interlock = 0xc07e5d30, lk_flags = 1024, lk_sharecount = 0,
lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80,
lk_wmesg = 0xc07646ac "getblk", lk_timo = 0, lk_lockholder = 0xd2606780,
lk_newlock = 0x0}, b_bufsize = 4096, b_runningbufspace = 0,
b_kvabase = 0xd84a4000 "", b_kvasize = 16384, b_lblkno = 56,
b_vp = 0xcb680514, b_object = 0xcc5cf528, b_dirtyoff = 0, b_dirtyend = 0,
b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xd84a4000, b_pager = {
pg_reqpage = 0}, b_cluster = {cluster_head = {tqh_first = 0xd4a5c4d0,
tqh_last = 0xd4c64d50}, cluster_entry = {tqe_next = 0xd4a5c4d0,
tqe_prev = 0xd4c64d50}}, b_pages = {0xc21086f8, 0x0 },
b_npages = 1, b_dep = {lh_first = 0x0}}
(kgdb) p *ip
$6 = {i_hash = {le_next = 0x0, le_prev = 0xc844b0e4}, i_nextsnap = {
tqe_next = 0x0, tqe_prev = 0x0}, i_vnode = 0xcd465a28, i_ump = 0xd23e8600,
i_flag = 32, i_dev = 0xd23d1d00, i_number = 16, i_effnlink = 0,
i_fs = 0xc99f7800, 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_un = {dirhash = 0x0, snapblklist = 0x0}, i_ea_area = 0x0,
i_ea_len = 0, i_ea_error = 0, i_mode = 0, i_nlink = 0, i_size = 0,
i_flags = 0, i_gen = 0, i_uid = 0, i_gid = 0, dinode_u = {din1 = 0xcec70600,
din2 = 0xcec70600}}
(kgdb) p *fs
$7 = {fs_firstfield = 0, fs_unused_1 = 0, fs_sblkno = 32, fs_cblkno = 48,
fs_iblkno = 56, fs_dblkno = 96, fs_old_cgoffset = 0, fs_old_cgmask = -1,
fs_old_time = 1069112008, fs_old_size = 8640, fs_old_dsize = 8351,
fs_ncg = 4, fs_bsize = 4096, fs_fsize = 512, fs_frag = 8, fs_minfree = 0,
fs_old_rotdelay = 0, fs_old_rps = 60, fs_bmask = -4096, fs_fmask = -512,
fs_bshift = 12, fs_fshift = 9, fs_maxcontig = 32, fs_maxbpg = 512,
fs_fragshift = 3, fs_fsbtodb = 0, fs_sbsize = 1536, fs_spare1 = {0, 0},
fs_nindir = 1024, fs_inopb = 32, fs_old_nspf = 1, fs_optim = 1,
fs_old_npsect = 2168, fs_old_interleave = 1, fs_old_trackskew = 0, fs_id = {
1069112008, -1022875143}, fs_old_csaddr = 96, fs_cssize = 512,
fs_cgsize = 1024, fs_spare2 = 0, fs_old_nsect = 2168, fs_old_spc = 2168,
fs_old_ncyl = 4, fs_old_cpg = 1, fs_ipg = 160, fs_fpg = 2168,
fs_old_cstotal = {cs_ndir = 2, cs_nbfree = 1041, cs_nifree = 636,
cs_nffree = 21}, fs_fmod = 1 '\001', fs_clean = 0 '\0', fs_ronly = 0 '\0',
fs_old_flags = -128 '\200', fs_fsmnt = "/mnt", '\0' ,
fs_volname = '\0' , fs_swuid = 0, fs_pad = 0,
fs_cgrotor = 0, fs_ocsp = {0x0 },
fs_contigdirs = 0xc8e3ae10 "", fs_csp = 0xc8e3ac00,
fs_maxcluster = 0xc8e3ae00, fs_active = 0x0, fs_old_cpc = 0,
fs_maxbsize = 4096, fs_sparecon64 = {0 },
fs_sblockloc = 65536, fs_cstotal = {cs_ndir = 10, cs_nbfree = 1031,
cs_nifree = 612, cs_nffree = 23, cs_numclusters = 0, cs_spare = {0, 0,
0}}, fs_time = 1069112008, fs_size = 8640, fs_dsize = 8351,
fs_csaddr = 96, fs_pendingblocks = 0, fs_pendinginodes = 0, fs_snapinum = {
0 }, fs_avgfilesize = 16384, fs_avgfpdir = 64,
fs_save_cgsize = 0, fs_sparecon32 = {0 }, fs_flags = 0,
fs_contigsumsize = 16, fs_maxsymlinklen = 60, fs_old_inodefmt = 2,
fs_maxfilesize = 4402345721855, fs_qbmask = 4095, fs_qfmask = 511,
fs_state = 0, fs_old_postblformat = 1, fs_old_nrpos = 1, fs_spare5 = {0, 0},
Re: floppy install troubles
At Wed, 12 Nov 2003 03:48:01 + (UTC), Peter Schultz wrote: > I'm having trouble installing with the 5.1-CURRENT-20031110-JPSNAP > floppies I got off snapshots.jp.freebsd.org. First off, I tried to > create a new slice and it wants to use /dev/ad0p1. I don't believe the > p is correct. I tried again without changing the slices at all, and > when newfs ran the install stopped with this error: "newfs: Cannot > retrieve operator gid". I saw "p" slice too. Is your disk is fresh one (no write after buying), or already used one? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R
At Mon, 3 Nov 2003 17:47:59 + (UTC), Stephane Raimbault wrote: > >autoboot 10 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/kernel]... I meant to use "-v" at above. Hit any key at this 10 seconds waiting, and type "boot -v" and enter at prompt. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R
At Fri, 31 Oct 2003 16:56:43 + (UTC), Stephane Raimbault wrote: > Does anyone have any thoughts regarding this? I would like to get 5.1 on > this server. How about trying with -v at boot? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 'cd /usr/src/etc; make distribute' broken.
At Fri, 12 Sep 2003 20:01:36 + (UTC), Kris Kennaway wrote: > This used to work fine, but now it is dying with the following: > > install -o root -g wheel -m 644 > /a/asami/portbuild/amd64/5/src/etc/sendmail/freebsd.mc > /a/asami/portbuild/amd64/5/src/etc/sendmail/freebsd.cf //var/chroot/etc/mail > install: /a/asami/portbuild/amd64/5/src/etc/sendmail/freebsd.cf: No such file or > directory > *** Error code 71 > > Stop in /a/asami/portbuild/amd64/5/src/etc/sendmail. > *** Error code 1 > > Indeed, freebsd.cf does not appear to be built anywhere. Does anyone > know what is going on? Hmm, on my environment, freebsd.cf is built correctly. Is there freebsd.submit.cf in the same directory? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall spec_getpages panic
At Wed, 20 Aug 2003 17:01:30 + (UTC), Gavin Atkinson wrote: > On the 8th August [EMAIL PROTECTED] mentioned he was getting a panic > with FreeBSD inside VMware where _mtx_lock is being called with a NULL > mutex from spec_getpages. I'm also seeing this, 100% reproducible, on real > hardware. (see message ID [EMAIL PROTECTED] for the > original posters email and jhb's reply) For me, Sysinstall panics during > the extraction of the base package: This seems to be fixed by [EMAIL PROTECTED] I can install it on my VMware after this commit. > alc 2003/08/22 10:50:32 PDT > > FreeBSD src repository > > Modified files: > sys/fs/specfsspec_vnops.c > Log: > Use the requested page's object field instead of the vnode's. In some > cases, the vnode's object field is not initialized leading to a NULL > pointer dereference when the object is locked. > > Tested by: rwatson > > Revision ChangesPath > 1.208 +5 -2 src/sys/fs/specfs/spec_vnops.c -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: access to snapshot?
At Sat, 23 Aug 2003 23:41:26 + (UTC), Daniel Flickinger wrote: > p1:attila 556-> ftp current.freebsd.org > Trying 3ffe:501:185b:1:210:f3ff:fe03:50cb... > ftp: connect to address 3ffe:501:185b:1:210:f3ff:fe03:50cb: No route to host > Trying 211.14.6.234... > ftp: connect: Operation timed out > ftp> quit > > this has been going on all day although snapshot itself is > up and available. > > snapshot.jp.freebsd.org and jp.freebsd.org do not permit > anonymous logins. Sorry, network which hosts snapshots machines is down from Saturday. I hope we can fix this today, but I'm not sure we can do that... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall spec_getpages panic (with VM overtones)
At Wed, 20 Aug 2003 17:31:39 -0400 (EDT),
Robert Watson wrote:
> > *c0529513 = "/usr/src/sys/fs/specfs/spec_vnops.c", line 0x300 is line 768:
> >
> > 766 gotreqpage = 0;
> > 767 VM_OBJECT_LOCK(vp->v_object);
> > 768 vm_page_lock_queues();
> > 769 for (i = 0, toff = 0; i < pcount; i++, toff = nextoff) {
> >
> > so ap->a_vp is null. I'#m afraid that's the limit of my ddb ability.
> >
> > Any suggestions as to where I should go from here? I don't really have
> > the facility at the moment to make release to test patches but will try
> > to if necessary.
>
> Is it ap->a_vp that's NULL, or vp->v_object that's NULL? vp is
> dereferenced several times before that in the code, so if vp is really
> NULL at line 767, we're probably talking about memory corruption. But if
> vp->v_object is NULL, then it could be we're not creating a VM object
> along some code path.
FWIW, ffs_getpages() at ffs_vnops.c:938, dp->v_object is NULL. Where
this should be allocated?
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall spec_getpages panic (with VM overtones)
At Wed, 20 Aug 2003 17:31:39 -0400 (EDT),
Robert Watson wrote:
> > *c0529513 = "/usr/src/sys/fs/specfs/spec_vnops.c", line 0x300 is line 768:
> >
> > 766 gotreqpage = 0;
> > 767 VM_OBJECT_LOCK(vp->v_object);
> > 768 vm_page_lock_queues();
> > 769 for (i = 0, toff = 0; i < pcount; i++, toff = nextoff) {
> >
> > so ap->a_vp is null. I'#m afraid that's the limit of my ddb ability.
> >
> > Any suggestions as to where I should go from here? I don't really have
> > the facility at the moment to make release to test patches but will try
> > to if necessary.
>
> Is it ap->a_vp that's NULL, or vp->v_object that's NULL? vp is
> dereferenced several times before that in the code, so if vp is really
> NULL at line 767, we're probably talking about memory corruption. But if
> vp->v_object is NULL, then it could be we're not creating a VM object
> along some code path.
At least I checked with printf() debugging, it seems vp->v_object is
NULL.
Should I check in ffs_getpages(), too?
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic at _mtx_lock_flags+0x43 on VMware 3.x
At Fri, 08 Aug 2003 15:47:31 -0400 (EDT), John Baldwin wrote: > The passed in mutex to mtx_lock is NULL, so likely a bio or > some such in spec_getpages() is zero'd and not initialized > yet or something. Yes, vp->v_object in spec_getpages() is NULL and then, VTOI(ap->a_vp)->i_devvp->v_object in ffs_getpages() (the caller of spec_getpages() via VOP_GETPAGES()) is also NULL. I don't know where this should be initialized... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic at _mtx_lock_flags+0x43 on VMware 3.x
I got a reproducable panic when installing current snapshot on VMware 3.x on Windows XP. Sorry, panic message and trace is PNG image captured on Windows: http://www.imgsrc.co.jp/~kuriyama/tmp/20030808.png If more information is needed, please let me know. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dereferencing type-punned pointer will break strict-aliasingrules
Hmm, it seems this macro is John's baby. John?
At Mon, 28 Jul 2003 02:00:50 + (UTC),
Thomas Moestl wrote:
>
> [1 ]
> On Mon, 2003/07/28 at 09:30:08 +0900, Jun Kuriyama wrote:
> >
> > Is this caused by -oS option?
> >
> > - in making BOOTMFS in make release
> > cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions
> > -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev
> > -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter
> > -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL
> > -include opt_global.h -fno-common -finline-limit=15000 -mno-align-long-strings
> > -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/geom/geom_dev.c
> > /usr/src/sys/geom/geom_dev.c: In function `g_dev_open':
> > /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will
> > break strict-aliasing rules
> > [...]
>
> Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
> workaround. The problem is caused by the i386 PCPU_GET/PCPU_SET
> implementation:
>
> #define __PCPU_GET(name) ({ \
> __pcpu_type(name) __result; \
> \
> [...]
> } else if (sizeof(__result) == 4) { \
> u_int __i; \
> __asm __volatile("movl %%fs:%1,%0" \
> : "=r" (__i)\
> : "m" (*(u_int *)(__pcpu_offset(name; \
> __result = *(__pcpu_type(name) *)&__i; \
> [...]
>
> In this case, the PCPU_GET is used to retrieve curthread, causing
> sizeof(__result) to be 4, so the cast at the end of the code snippet
> is from a u_int * to struct thread *, and __i is accessed through the
> casted pointer, which violates the C99 aliasing rules.
> An alternative is to type-pun via a union, which is also a bit ugly,
> but explicitly allowed by C99. Patch attached (but only superficially
> tested).
>
> - Thomas
>
> --
> Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
> <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
> PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
> [2 pcpu.diff ]
> Index: pcpu.h
> ===
> RCS file: /vol/ncvs/src/sys/i386/include/pcpu.h,v
> retrieving revision 1.36
> diff -u -r1.36 pcpu.h
> --- pcpu.h27 Jun 2003 21:50:52 - 1.36
> +++ pcpu.h28 Jul 2003 01:37:57 -
> @@ -96,23 +96,32 @@
> __pcpu_type(name) __result; \
> \
> if (sizeof(__result) == 1) {\
> - u_char __b; \
> + union { \
> + u_char __b; \
> + __pcpu_type(name) __r; \
> + } __u; \
> __asm __volatile("movb %%fs:%1,%0" \
> - : "=r" (__b)\
> + : "=r" (__u.__b)\
> : "m" (*(u_char *)(__pcpu_offset(name; \
> - __result = *(__pcpu_type(name) *)&__b; \
> + __result = __u.__r; \
> } else if (sizeof(__result) == 2) { \
> - u_short __w;\
> + union { \
> + u_short __w;\
> + __pcpu_type(name) __r; \
> + } __u; \
> __asm __volatile("movw %%fs:%1,%0" \
> - : "=r" (__w)
Re: dereferencing type-punned pointer will break strict-aliasingrules
At Mon, 28 Jul 2003 00:30:35 + (UTC),
kuriyama wrote:
> Is this caused by -oS option?
Grrr, of course this should be s/-oS/-Os/.
These warnings are caused from DROP_GIANT() macro. By tracking this
down, actual source is __PCPU_GET() macro (line: 115) in
sys/i386/include/pcpu.h.
__result = *(__pcpu_type(name) *)&__i;
To test this with simplified code:
-
% cat test.c
struct T {
int a;
};
void
test()
{
struct T* c;
int __i = 0;
c = *(struct T* *)&__i;
}
% cc -c -Os -Wall test.c
test.c: In function `test':
test.c:11: warning: dereferencing type-punned pointer will break strict-aliasing rules
-
__PCPU_GET() macro seems to be harmless if -Os is not used or
__pcpu_type() returns actual type rather than pointer.
What should we do?
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dereferencing type-punned pointer will break strict-aliasing rules
Is this caused by -oS option? - in making BOOTMFS in make release cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/geom/geom_dev.c /usr/src/sys/geom/geom_dev.c: In function `g_dev_open': /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:205: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:205: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c: In function `g_dev_close': /usr/src/sys/geom/geom_dev.c:232: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:232: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:232: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:232: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:253: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:253: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c: In function `g_dev_ioctl': /usr/src/sys/geom/geom_dev.c:281: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:281: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:281: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:281: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:340: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:340: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 1 error -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
At Tue, 15 Jul 2003 11:54:06 -0700,
David O'Brien wrote:
> Much, much better if you can point to the specific GCC source code file
> where this is handled.
May this help you?
waterblue% cat exp.c
int
main(int argc, char** argv)
{
int exp = 5;
return 0;
}
waterblue% cc -Wshadow -c exp.c
exp.c: In function `main':
exp.c:4: warning: declaration of `exp' shadows a global declaration
:0: warning: shadowed declaration is here
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
src/bin/ed/re.c: warning: declaration of `exp' shadows a globaldeclaration
With new gcc and -Wshadow, src/bin/ed/re.c shows this warning:
cc -Wshadow -c re.c
re.c: In function `get_compiled_pattern':
re.c:44: warning: declaration of `exp' shadows a global declaration
:0: warning: shadowed declaration is here
It seems local variable exp is conflicted with exp(3) declaration. I
don't know what name should be used...
Index: re.c
===
RCS file: /home/ncvs/src/bin/ed/re.c,v
retrieving revision 1.19
diff -u -r1.19 re.c
--- re.c30 Jun 2002 05:13:53 - 1.19
+++ re.c14 Jul 2003 23:42:41 -
@@ -41,7 +41,7 @@
pattern_t *
get_compiled_pattern(void)
{
- static pattern_t *exp = NULL;
+ static pattern_t *expr = NULL;
static char error[1024];
char *exps;
@@ -52,27 +52,27 @@
errmsg = "invalid pattern delimiter";
return NULL;
} else if (delimiter == '\n' || *++ibufp == '\n' || *ibufp == delimiter) {
- if (!exp)
+ if (!expr)
errmsg = "no previous pattern";
- return exp;
+ return expr;
} else if ((exps = extract_pattern(delimiter)) == NULL)
return NULL;
/* buffer alloc'd && not reserved */
- if (exp && !patlock)
- regfree(exp);
- else if ((exp = (pattern_t *) malloc(sizeof(pattern_t))) == NULL) {
+ if (expr && !patlock)
+ regfree(expr);
+ else if ((expr = (pattern_t *) malloc(sizeof(pattern_t))) == NULL) {
fprintf(stderr, "%s\n", strerror(errno));
errmsg = "out of memory";
return NULL;
}
patlock = 0;
- if ((n = regcomp(exp, exps, 0))) {
- regerror(n, exp, error, sizeof error);
+ if ((n = regcomp(expr, exps, 0))) {
+ regerror(n, expr, error, sizeof error);
errmsg = error;
- free(exp);
- return exp = NULL;
+ free(expr);
+ return expr = NULL;
}
- return exp;
+ return expr;
}
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic linux ldconfig with MUTEX_PROFILING
At Thu, 10 Jul 2003 08:32:28 +0200, Dag-Erling Smørgrav wrote: > > I'm trying to use MUTEX_PROFILING, but paniced in linux ldconfig. > > Any clues? > > is COMPAT_LINUX compiled into the kernel? You can't use modules with > MUTEX_PROFILING; it changes the size and layout of struct mtx, and > since modules aren't built with the same options as the kernel, they > use the wrong struct mtx. Ah, bingo! I'm using linux.ko for Linux ABI. I'll try with COMPAT_LINUX. But I used linux.ko which sync'ed with kernel itself (both were built with same config). Is MUTEX_PROFILING not passed to kernel module building? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic linux ldconfig with MUTEX_PROFILING
At Fri, 27 Jun 2003 09:37:40 + (UTC),
kuriyama wrote:
> (kgdb) l *linux_brk+0x1a
> 0xc19d24ca is in linux_brk
> (/.a/black/host/disk/arena/home/kuriyama/ncvs/src/sys/compat/linux/linux_misc.c:217).
> 212
> 213 #ifdef DEBUG
> 214 if (ldebug(brk))
> 215 printf(ARGS(brk, "%p"), (void *)args->dsend);
> 216 #endif
> 217 old = (vm_offset_t)vm->vm_daddr + ctob(vm->vm_dsize);
> 218 new = (vm_offset_t)args->dsend;
> 219 tmp.nsize = (char *) new;
> 220 if (((caddr_t)new > vm->vm_daddr) && !obreak(td, &tmp))
> 221 td->td_retval[0] = (long)new;
I've checked via printf debugging. It seems "vm" is NULL at line
217. So NULL is from td->td_proc->p_vmspace.
205 linux_brk(struct thread *td, struct linux_brk_args *args)
206 {
207 struct vmspace *vm = td->td_proc->p_vmspace;
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic linux ldconfig with MUTEX_PROFILING
I'm trying to use MUTEX_PROFILING, but paniced in linux ldconfig.
Any clues?
Initial i386 initialization:.
Additional ABI support: linux
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0xe8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc19d24ca
stack pointer = 0x10:0xcbd51cbc
frame pointer = 0x10:0xcbd51ce0
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 = 495 (ldconfig)
kernel: type 12 trap, code=0
Stopped at linux_brk+0x1a: movl0xe8(%edx),%eax
db> trace
linux_brk(c18f6720,cbd51d10,c0411b33,3fd,1) at linux_brk+0x1a
syscall(2f,2f,2f,80b3b60,20) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (45, Linux ELF, linux_brk), eip = 0x807fb51, esp = 0xbfbff9b0, ebp =
0xbfbff9b8 ---
db> panic
panic: from debugger
cpuid = 0; lapic.id =
Debugger("panic")
Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 0; lapic.id =
instruction pointer = 0x8:0xc0397195
stack pointer = 0x10:0xcbd51a28
frame pointer = 0x10:0xcbd51a34
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 495 (ldconfig)
Stopped at linux_brk+0x1a: movl0xe8(%edx),%eax
db> panic
panic: from debugger
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 35s
Dumping 95 MB
ata0: resetting devices ..
done
16 32 48 64 80
Dump complete
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc0231a63 in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc0231e46 in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc0148e52 in db_panic () at ../../../ddb/db_command.c:449
#4 0xc0148dd2 in db_command (last_cmdp=0xc041e4d0, cmd_table=0x0,
aux_cmd_tablep=0xc0416d24, aux_cmd_tablep_end=0xc0416d28)
at ../../../ddb/db_command.c:346
#5 0xc0148ee6 in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc014bc7a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:73
#7 0xc0396ea3 in kdb_trap (type=12, code=0, regs=0xcbd51c7c)
at ../../../i386/i386/db_interface.c:172
#8 0xc03aff62 in trap_fatal (frame=0xcbd51c7c, eva=0)
at ../../../i386/i386/trap.c:831
#9 0xc03afc42 in trap_pfault (frame=0xcbd51c7c, usermode=0, eva=232)
at ../../../i386/i386/trap.c:750
#10 0xc03af80d in trap (frame=
{tf_fs = -1069613032, tf_es = 16, tf_ds = 16, tf_edi = -1047568980, tf_esi =
-1047566560, tf_ebp = -875225888, tf_isp = -875225944, tf_ebx = -1047568872, tf_edx =
0, tf_ecx = -1047568872, tf_eax = -1047568980, tf_trapno = 12, tf_err = 0, tf_eip =
-104038, tf_cs = 8, tf_eflags = 66194, tf_esp = -1071480430, tf_ss = -1047568872})
at ../../../i386/i386/trap.c:435
#11 0xc0398848 in calltrap () at {standard input}:97
#12 0xc03b02ae in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134953824, tf_esi = 32, tf_ebp =
-1077937736, tf_isp = -875225740, tf_ebx = 0, tf_edx = 45, tf_ecx = 0, tf_eax = 45,
tf_trapno = 12, tf_err = 2, tf_eip = 134740817, tf_cs = 31, tf_eflags = 658, tf_esp =
-1077937744, tf_ss = 47}) at ../../../i386/i386/trap.c:1023
#13 0xc039889d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---
(kgdb) l *linux_brk+0x1a
0xc19d24ca is in linux_brk
(/.a/black/host/disk/arena/home/kuriyama/ncvs/src/sys/compat/linux/linux_misc.c:217).
212
213 #ifdef DEBUG
214 if (ldebug(brk))
215 printf(ARGS(brk, "%p"), (void *)args->dsend);
216 #endif
217 old = (vm_offset_t)vm->vm_daddr + ctob(vm->vm_dsize);
218 new = (vm_offset_t)args->dsend;
219 tmp.nsize = (char *) new;
220 if (((caddr_t)new > vm->vm_daddr) && !obreak(td, &tmp))
221 td->td_retval[0] = (long)new;
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LOR: vm object (vm object) @ vm/vm_object.c:432
I got this with today's kernel: lock order reversal 1st 0xc851e2e4 vm object (vm object) @ vm/vm_object.c:432 2nd 0xc082f110 system map (system map) @ vm/vm_kern.c:328 Stack backtrace: backtrace(c03f57e2,c082f110,c040afd9,c040afd9,c040ae81) at backtrace+0x17 witness_lock(c082f110,8,c040ae81,148,0) at witness_lock+0x697 _mtx_lock_flags(c082f110,0,c040ae78,148,3) at _mtx_lock_flags+0xb2 _vm_map_lock(c082f0b0,c040ae78,148,e8ff4ab0,c0236e34) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,e8ff4b1c,c03715ca) at kmem_malloc+0x66 page_alloc(c083a200,1000,e8ff4b0f,101,c044516c) at page_alloc+0x27 slab_zalloc(c083a200,101,c040c816,664,c083a814) at slab_zalloc+0x14a uma_zone_slab(c083a200,101,c040c80d,664,0) at uma_zone_slab+0xd8 uma_zalloc_internal(c083a200,0,101,6e8,0) at uma_zalloc_internal+0x55 uma_zfree_arg(c083a800,c85b4090,0,e8ff4bc8,c03589d8) at uma_zfree_arg+0x2e7 dev_pager_putfake(c85b4090,0,c040a60a,be,c851e2e4) at dev_pager_putfake+0x3a dev_pager_dealloc(c851e2e4,1,c040c71c,10c,0) at dev_pager_dealloc+0xc8 vm_pager_deallocate(c851e2e4,0,c040b90a,25f,282df000) at vm_pager_deallocate+0x3d vm_object_terminate(c851e2e4,0,c040b90a,1b0,c857d960) at vm_object_terminate+0x1f4 vm_object_deallocate(c851e2e4,c851b708,c851e2e4,c851b708,e8ff4c9c) at vm_object_deallocate+0x377 vm_map_entry_delete(c3b09b00,c851b708,c040b047,86b,c03f0e5a) at vm_map_entry_delete+0x3b vm_map_delete(c3b09b00,282df000,282e,1000,282df000) at vm_map_delete+0x3e3 vm_map_remove(c3b09b00,282df000,282e,0,c829eda8) at vm_map_remove+0x58 munmap(c829f980,e8ff4d10,c0410a80,3fd,2) at munmap+0x9e syscall(2f,2f,2f,c7000,1000) at syscall+0x26e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (73), eip = 0x28251f33, esp = 0xbfbef80c, ebp = 0xbfbef838 --- -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Remove absolute symlink in $MAKEOBJDIR
At Mon, 2 Jun 2003 10:10:26 + (UTC),
Bruce Evans wrote:
> As marcel pointed out, there are technical reasons for not using cp.
> Use cat.
OK, thanks!
> > (2) Use correct dependency in sys/boot/i386/kgzldr.
>
> This is too hackish for me. Try using the same method as for lib/csu.
> I think you nmainly care about "make install" building things. This is
> from longstanding brokenness of installation of man pages which was
> cloned to brokenness of installation of FILES.
Hmm, like this? I don't know which owner and mode should be used at
realinstall stage.
Index: Makefile
===
RCS file: /home/ncvs/src/sys/boot/i386/kgzldr/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- Makefile30 Sep 2002 20:37:57 - 1.12
+++ Makefile3 Jun 2003 03:41:02 -
@@ -1,6 +1,5 @@
# $FreeBSD: src/sys/boot/i386/kgzldr/Makefile,v 1.12 2002/09/30 20:37:57 peter Exp $
-FILES= kgzldr.o
SRCS= start.s boot.c inflate.c lib.c crt.s sio.s
OBJS= ${SRCS:N*.h:R:S/$/.o/g}
CFLAGS=-ffreestanding
@@ -15,7 +14,13 @@
BOOT_COMCONSOLE_PORT?= 0x3f8
AFLAGS+=--defsym SIO_PRT=${BOOT_COMCONSOLE_PORT}
+all: ${OBJS} kgzldr.o
+
kgzldr.o: ${OBJS}
${CC} ${LDFLAGS} -o ${.TARGET} ${OBJS}
+
+realinstall:
+ ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${LIBMODE} \
+ kgzldr.o ${DESTDIR}${BINDIR}
.include
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Remove absolute symlink in $MAKEOBJDIR
At Sun, 1 Jun 2003 23:33:04 -0700,
David O'Brien wrote:
> I prefer the ln's over cp. Are you sure this is the only reason for the
> same $MAKEOBJDIR requirement? Also, typically one sets MAKEOBJDIRPREFIX,
> not MAKEOBJDIR. Are you sure you're using the right one for what you're
> wanting to do?
Actually, I'm using MAKEOBJDIRPREFIX. The only thing I want to do is,
o Nightly buildworld in /work/HEAD/src, /work/RELENG_5_0/src and
/work/RELENG_5_1/src with MAKEOBJDIRPREFIX=/work/${BRANCH}/obj.
o Use /work/${BRANCH}/{src,obj} for installing the world on the other
box.
But without this patch, I have symlinks like this:
% ls -l /work/RELENG_5_1/obj/work/RELENG_5_1/src/bin/csh/csh.1
lrwxr-xr-x 1 god god 56 Jun 2 05:40
/work/RELENG_5_1/obj/work/RELENG_5_1/src/bin/csh/csh.1 ->
/work/RELENG_5_1/src/bin/csh/../../contrib/tcsh/tcsh.man
This causes problem when installing on the other box as mounting
/usr/src and /usr/obj.
I'll appreciate if you can teach me how to build absolute-path-free
objdir in another way...
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Remove absolute symlink in $MAKEOBJDIR
k/Makefile
===
RCS file: /home/ncvs/src/usr.bin/awk/Makefile,v
retrieving revision 1.10
diff -u -r1.10 Makefile
--- usr.bin/awk/Makefile17 Mar 2003 08:07:54 - 1.10
+++ usr.bin/awk/Makefile17 Mar 2003 15:24:24 -
@@ -27,6 +27,6 @@
CLEANFILES+= nawk.1
nawk.1: awk.1
- ln -sf ${.ALLSRC} ${.TARGET}
+ cp ${.ALLSRC} ${.TARGET}
.include
Index: usr.bin/less/Makefile.common
===
RCS file: /home/ncvs/src/usr.bin/less/Makefile.common,v
retrieving revision 1.3
diff -u -r1.3 Makefile.common
--- usr.bin/less/Makefile.common3 Jun 2000 11:39:36 - 1.3
+++ usr.bin/less/Makefile.common23 Jan 2003 23:22:06 -
@@ -8,4 +8,4 @@
.SUFFIXES: .nro .1
.nro.1:
- ln -s ${.IMPSRC} ${.TARGET}
+ cp ${.IMPSRC} ${.TARGET}
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Okay. who broke ata.
At Sun, 6 Apr 2003 04:18:42 + (UTC), Kevin S. Brackett wrote: > make world from yesterday broke support for my promise udma66 controller, > getting READ/WRITE errors on the drive attached to, reverting to previous > kernel fixes problem. I got same result. After updating to latest source, I got: ad0: 76319MB [155061/16/63] at ata0-master UDMA100 ad1: 39266MB [79780/16/63] at ata0-slave UDMA100 ad4: READ command timeout tag=0 serv=0 - resetting ata2: resetting devices .. Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc015eed2 stack pointer = 0x10:0xe11f0c48 frame pointer = 0x10:0xe11f0c5c 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 = 14 (swi7: tty:sio clock) kernel: type 12 trap, code=0 Stopped at reinit_bus+0x12:movl0(%esi),%eax db> trace reinit_bus(0,2,e11f0c90,c0147998,c7a61e00) at reinit_bus+0x12 atapi_cam_reinit_bus(c7a61e00,ec,c03adf22,3,c7a87f00) at atapi_cam_reinit_bus+0x21 ata_reinit(c7a61e00,c7a87f00,c03a9f87,0,0) at ata_reinit+0x3c8 ad_timeout(c7a87f00,0,c03c0542,bf,438) at ad_timeout+0x136 softclock(0,0,c03bd526,232,c3afd5a0) at softclock+0x19c ithread_loop(c3afc180,e11f0d48,c03bd3a2,314,0) at ithread_loop+0x182 fork_exit(c01fac70,c3afc180,e11f0d48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a Previous (Mar 26) kernel said like this: ad0: 76319MB [155061/16/63] at ata0-master UDMA100 ad1: 39266MB [79780/16/63] at ata0-slave UDMA100 ad4: 58644MB [119150/16/63] at ata2-master UDMA100 ad5: 43979MB [89355/16/63] at ata2-slave UDMA100 acd0: CD-RW at ata1-master PIO4 acd1: DVD-R at ata1-slave PIO4 pass0 at ata1 bus 0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 16.000MB/s transfers pass1 at ata1 bus 0 target 1 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 16.000MB/s transfers -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: headlocked should be 1
Today's current. I cannot dump core at this time...
panic: headlocked should be 1
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c03bad7e,0,c03c3c6f,e1190b28,1) at Debugger+0x55
panic(c03c3c6f,c47a2034,e1190b74,c3b27200,3fc0) at panic+0x11f
tcp_input(c3b27200,14,c04094c0,1,c03bb2b9) at tcp_input+0x2a91
ip_input(c3b27200,0,c03c184d,e9,c3af1e80) at ip_input+0x9aa
swi_net(0,0,c03b8c87,217,c3afd3f8) at swi_net+0x112
ithread_loop(c3afc100,e1190d48,c03b8af8,35f,0) at ithread_loop+0x182
fork_exit(c01f8b90,c3afc100,e1190d48) at fork_exit+0xc4
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xe1190d7c, ebp = 0 ---
db> panic
panic: from debugger
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 1h41m22s
Dumping 2047 MB
ata2: resetting devices ..
done
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: devstat_end_transaction: HELP!! busy_count for ad1 is < 0 (-1)!
At Thu, 13 Mar 2003 23:24:03 +0100, Stefan Farfeleder wrote: > There's a patch from phk at http://phk.freebsd.dk/patch/ken.patch which > works for me (though it breaks gkrellm :) Thaks! I missed previous thread of this subject. I'll try that patch. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
devstat_end_transaction: HELP!! busy_count for ad1 is < 0 (-1)!
I got this message after upgrading my world to as of Thu Mar 13 10:38:11 JST 2003. devstat_end_transaction: HELP!! busy_count for ad1 is < 0 (-1)! devstat_end_transaction: HELP!! busy_count for ad1 is < 0 (-1)! devstat_end_transaction: HELP!! busy_count for ad1 is < 0 (-1)! ... What does this mean? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.7-amd cannot mount exports from 5.0-RELEASE
At Mon, 27 Jan 2003 11:58:34 +0100 (CET), Martin Blapp wrote: > Can you try to cvsup on both boxes and then manually rebuild > libc, mountd, rpcbind, nfsd. Hmm, 5.0-RELEASE box is difficult to upgrade to HEAD. I'll try to update my box to the latest of HEAD tomorrow. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.7-amd cannot mount exports from 5.0-RELEASE
At Mon, 27 Jan 2003 11:21:54 +0100 (CET), Martin Blapp wrote: > There seem to be definitly a problem around. Can you exactly tell > me how you can reproduce it ? Hmm, sorry for my little description. > I tried it too and amd still works. I use on both servers a recent > CURRENT and one has amd running, the other the nfsd and mountd. > > tcp and udp mounts still work fine. So the trigger of this > bug must be elsewhere ... In my environment, server is 5.0-RELEASE and client is HEAD as of Jan 20th. Both have nfsd, rpc.lockd, rpc.statd and nfs client. I'll verify to find the case which is easy to reproduce. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.7-amd cannot mount exports from 5.0-RELEASE
At Tue, 21 Jan 2003 23:29:16 + (UTC), Masafumi NAKANE wrote: > Well, not so quick. I took another -CURRENT box and the problem was > not reproduceable on this box. I can't quite figure out what the > differences between these two boxes are, though. I think I found the solution. On HEAD and RELENG_5_0 as of now On RELENG_4 and old (e.g. last year's) HEAD, refering remote filesystem via AMD retrieves export list from server and trying to mount like this: c->s MOUNT V1 EXPORT Call s->c MOUNT V1 EXPORT Reply c->s MOUNT V1 MNT Call s->c MOUNT V1 MNT Reply But on latest HEAD and RELENG_5_0, packets show like this: c->s MOUNT V1 EXPORT Call s->c MOUNT V1 EXPORT Reply c->s MOUNT V1 MNT Call s->c MOUNT V1 EXPORT Reply (duplicate) So, problem may be in mountd. I tested with reverting the commit at 2003/01/15, and it works fine. mbr 2003/01/15 23:27:31 PST Modified files: usr.sbin/mountd mountd.c Log: Implement nonblocking tpc-connections. rpcgen -m does still produce backcompatible code. I don't know the problem is in amd or mountd. I fear other programs are broken with this commit... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dump -L and privilege
I'm trying to use dump -L option to dump with snapshot on -current/RELENG_5_0 family. I found dump -L needs writable permission to the device (that's reasonable because it *writes* snapshot file). But when I try to dump by operator group, it's impossible to dump with -L option (target device has root:operator and crw-r-). This behavior is understandable. But in actual backup operations, what should we do? I'd like to hear what you thought in design. (1) Do dump as root with -L option. (2) Do chmod g+w for device. (3) Other ideas? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-RC2/if_awi.ko doesn't load
At Fri, 10 Jan 2003 00:33:47 + (UTC),
Nicolas Christin wrote:
> I just tried to give a shot to 5.0-RC2 on an old box of mine that can
> only perform network installs (no CD drive). During the boot process, a
> module failed to load.
>
> DEBUG: Loading module if_awi.ko (BayStack 660 and others)
> link_elf: symbol rc4_init undefined
I got same result on today's snapshot of HEAD (20030113-JPSNAP). I'm
using {kern,mfsroot}.flp and FTP installation.
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Mounting MS-DOS fs image via /dev/md*
I'm not sure this is correct way to create MS-DOS fs image and mounting it. % dd if=/dev/zero of=test.flp bs=1024 count=1440 1440+0 records in 1440+0 records out 1474560 bytes transferred in 0.044105 secs (33432904 bytes/sec) % sudo mdconfig -a -t vnode -f test.flp md1 % sudo newfs_msdos -f 1440 -L test /dev/md1 /dev/md1: 2847 sectors in 2847 FAT12 clusters (512 bytes/cluster) bps=512 spc=1 res=1 nft=2 rde=224 sec=2880 mid=0xf0 spf=9 spt=18 hds=2 hid=0 % sudo mount -t msdos /dev/md1 /mnt msdosfs: /dev/md1: No such file or directory How should I do? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Lock GEOM topology not exclusively locked
I've updated today's -current (HEAD). I got this messages after rebooting. Is it OK? Lock GEOM topology not exclusively locked @ ../../../geom/geom_mbr.c:118 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_subr.c:176 Lock GEOM topology not exclusively locked @ ../../../geom/geom_event.c:279 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A couple of 5.0 RC#0 sysinstall issues
At Tue, 10 Dec 2002 21:00:02 + (UTC), Brian J. McGovern <[EMAIL PROTECTED]> wrote: > 2.) Doing a Custom install with a custom distribution set, I receive, on the > first console: > > S:21494970 = (ff/ff/ff) > E:2988-899 = (ff/ef/ff) > > S:29880900 = (ff/ff/ff) > E:78172289 = (ff/ef/ff) > > 1S:63 = (0/1/1) E:128519 = (7/fe/3f) > S:128520 = (8/0/1) > E:120101939 = (ff/fe/ff) This is known issue. Removing there debug stuff will be removed before release. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fdisk editor in DP2
I'm trying to install DP2 to old machine (P2 dual). This box has 2GB IDE disk and ran NT4 before. When entering fdisk editor after booting from CD-ROM, I cannot delete NTFS partition by "D" key. "D" key only shows cursor up (NTFS is at offset 63, offset 0 seems boot selector for NT). Can I do something for debugging? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
makewhatis.local
I've installed fresh -current box and it seems it does not have
/usr/libexec/makewhatis.local script.
How about connecting makewhatis.local to the build? That is shell
script and doesn't require perl.
Index: Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/man/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile18 May 2002 19:47:57 - 1.5
+++ Makefile16 Nov 2002 08:46:26 -
@@ -7,6 +7,6 @@
# $FreeBSD: src/gnu/usr.bin/man/Makefile,v 1.5 2002/05/18 19:47:57 markm Exp $
#
-SUBDIR = lib man manpath apropos
+SUBDIR = lib man manpath apropos makewhatis
.include
Index: makewhatis/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/man/makewhatis/Makefile,v
retrieving revision 1.18
diff -u -r1.18 Makefile
--- makewhatis/Makefile 7 Apr 2001 11:21:18 - 1.18
+++ makewhatis/Makefile 16 Nov 2002 08:46:41 -
@@ -1,8 +1,8 @@
# $FreeBSD: src/gnu/usr.bin/man/makewhatis/Makefile,v 1.18 2001/04/07 11:21:18 ru Exp
$
MAINTAINER= wosch
-SCRIPTS=makewhatis.perl makewhatis.local.sh
-MAN= makewhatis.1 makewhatis.local.8
+SCRIPTS=makewhatis.local.sh
+MAN= makewhatis.local.8
libexecdir=/usr/libexec
LINKS=${libexecdir}/makewhatis.local ${libexecdir}/catman.local
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: dnet causes Hard Lock on SMP kernel? ( was 'Why is my -current system Hard Locking?' )
At Fri, 8 Nov 2002 00:58:10 + (UTC), Joel M. Baldwin <[EMAIL PROTECTED]> wrote: > > I got same result on my box. Only solution I have is deinstall > > dnetc. :-) ... > What motherboard/CPU is this on? > Have you tried a nonSMP kernel? It's SuperMicro's P3TDDE with dual P-III (1.13GHz). Yes, it works fine when I removed "options SMP" and "options apic" from kernel configuration. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dnet causes Hard Lock on SMP kernel? ( was 'Why is my -current system Hard Locking?' )
At Thu, 7 Nov 2002 22:55:56 + (UTC), Joel M. Baldwin <[EMAIL PROTECTED]> wrote: > I'm still pursuing the cause of the Hard Locks on my system. > > 1.) I have a serial console hooked up. Nothing appears on > the console when a Hard Lock happens. No panic. > 2.) Shorting IOCHK to ground on the ISA connector doesn't work > on a ABIT BP6, so I can't force myself into ddb. > > The BIG thing is that I now have a sure fire way of forcing > a Hard Lock. Every time I run the distributed.net client > 'dnet' the system hard locks. BUT ONLY ON A SMP KERNEL! > I have a non SMP kernel running and things so far > seem stable. Running the system with only 1 CPU is slow, > so it'll take a while for me to be sure. I got same result on my box. Only solution I have is deinstall dnetc. :-) -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Minimal install
At Sat, 2 Nov 2002 19:07:33 + (UTC), M. Warner Losh <[EMAIL PROTECTED]> wrote: > I'm downloading current snapshots. I was wondering what the minimum > set of files I needed to download to do a minimal install. I'm > guessing just floppies, base, or maybe floppies, base and crypto. (I'm > installing on pc98 machine, so need floppies). I think latter. You can check by selecting "Custom" after selecting "Minimal". -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-20021101-CURRENT snap & iso
At Sat, 2 Nov 2002 01:03:43 + (UTC), John De Boskey wrote: > The only (non-critical) > problem I've seen so far is refresh problems within > sysinstall. I think this is caused by printf()s in libdisk. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: boot0 problem?
At Sat, 2 Nov 2002 02:03:48 + (UTC), kuriyama wrote: > I used "BootMgr" in sysinstall. When I booted after install, it > stopped at: > > - > F1 FreeBSD > > Default: F1 > - Oops, I set "LBA" in BIOS explicitly, it booted fine. Hmm, it's my bad to believe BISO "Auto" setting... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
boot0 problem?
OK, I've installed 20021102-JPSNAP to fresh 80GB disk on my P-III x 2 box from floppy and ftp and finishes fine. But I cannot boot it. I used "BootMgr" in sysinstall. When I booted after install, it stopped at: - F1 FreeBSD Default: F1 - At this, pushing [F1] or [Enter] causes beeping but not go to next stage. Is there someone who has successfully installed recent -current with BootMgr? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
disklabel with fresh drive
I'm trying to install fresh 5.0-current from self-baked ISO. But when I select fresh drive at "Configure" -> "Label" in sysinstall, sysinstall stalls (title, table, synopsis is printed, but no Part rows). I can do Alt-F2 even if main screen cannot accept any command keys. When I select already formatted drive, it works fine. Is there a possibility fresh drive is not supported in libdisk? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The next "make release" breaker...
At Wed, 30 Oct 2002 13:01:32 +0100, Dag-Erling Smorgrav wrote: > Jun Kuriyama <[EMAIL PROTECTED]> writes: > > I got same result as Poul-Henning. It seems installed libssh.a in > > chroot does not have mm_auth_krb5(). > > The *installed* libssh shouldn't matter. What matters is the libssh > which is built during 'make world' inside the chroot. That's what > sshd should be linked against. Sorry for my misunderstanding. You mention $chrootdir/usr/obj/usr/src/secure/lib/libssh/libssh.a, right? % cd $chrootdir/usr/obj/usr/src/secure/lib/libssh % nm libssh.a | grep mm_auth 05e0 T mm_auth2_read_banner 06f0 T mm_auth_password 0820 T mm_auth_rhosts_rsa_key_allowed 1df0 T mm_auth_rsa_generate_challenge 1d00 T mm_auth_rsa_key_allowed 1ef0 T mm_auth_rsa_verify_response -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The next "make release" breaker...
At Tue, 29 Oct 2002 16:03:49 + (UTC), Poul-Henning Kamp wrote: > http://phk.freebsd.dk/misc/_.release > > I think it is related to all the crypto magic in make release... I got same result as Poul-Henning. It seems installed libssh.a in chroot does not have mm_auth_krb5(). I don't know why "-DKRB5" is not defined in libssh building but is defined in sshd building... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP and getty?
With latest current, I cannot reach to login prompt with SMP. Without "options SMP" and "options APIC_IO", it works fine. But with them, system is stalled at this point: - Starting inetd. Starting cron. Starting background file system checks. Mon Oct 28 09:58:32 JST 2002 - I don't know where the system stalled. System does not go to DDB by signalling from serial console. Does anyone have any idea for debugging more? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libfetch/http.c with -Werror
It seems _http_growbuf() should return int at the end of function? Index: http.c === RCS file: /home/ncvs/src/lib/libfetch/http.c,v retrieving revision 1.61 diff -u -r1.61 http.c --- http.c 3 Oct 2002 10:42:19 - 1.61 +++ http.c 27 Oct 2002 06:07:54 - @@ -179,6 +179,7 @@ return (-1); io->buf = tmp; io->bufsize = len; + return (0); } /* -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installing from CD and MAKEDEV
At Thu, 24 Oct 2002 12:10:53 + (UTC), kuriyama wrote: > I've created install CD with "make iso.1" (with sources few hours > before). > > I'm trying to install fresh current box with this CD. But I got > "MAKEDEV returned non-zero status" dialog after extracting dists. > > It seems "cd /dev; sh MAKEDEV all" is failed at devfs environment. I found it. Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by default. Options may be: (1) Back out 1.297. (2) Set MAKEDEV_INSTALL for install-media environment. (3) Drop non-devfs code from sysinstall (really???). -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Installing from CD and MAKEDEV
I've created install CD with "make iso.1" (with sources few hours before). I'm trying to install fresh current box with this CD. But I got "MAKEDEV returned non-zero status" dialog after extracting dists. It seems "cd /dev; sh MAKEDEV all" is failed at devfs environment. Is this my local problem? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: mutex inp not owned at ../../../netinet/tcp_output.c:131
I don't know why but I cannot get core for this panic. But "Dumping
2047 MB" message didn't count down and printed next line "ata0:
resetting devices .." soon.
-
panic: mutex inp not owned at ../../../netinet/tcp_output.c:131
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> tr
Debugger(c034e33a,0,c034d528,e13c49a8,e13c49c8) at Debugger+0x55
panic(c034d528,c0357483,c0358817,83,e13c49c8) at panic+0xfd
_mtx_assert(c85660b0,1,c0358817,83,c3d1b600) at _mtx_assert+0xbc
tcp_output(c8566100,c92ad8b8,c8566000,c9319970,1600) at tcp_output+0x5a
tcp_mtudisc(c8566000,28,10,28,95330600) at tcp_mtudisc+0x103
in6_pcbnotify(c03a71f0,e13c4be0,950f,e13c4c00,1600) at in6_pcbnotify+0x1fb
tcp6_ctlinput(5,e13c4be0,e13c4bb0,0,2) at tcp6_ctlinput+0x13e
icmp6_notify_error(c3d20900,28,4d8,5,c3d20900) at icmp6_notify_error+0x587
icmp6_input(e13c4cb4,e13c4c8c,3a,c3cfecc0,28) at icmp6_input+0xe89
ip6_input(c3d20900,0,c035af11,ee,1c) at ip6_input+0xc78
ip6intr(c034d337,1a5,c3cf06c0,c3ced800,e13c4d0c) at ip6intr+0x91
swi_net(0,0,c034b774,217,c3cfc2b0) at swi_net+0x23
ithread_loop(c3ced800,e13c4d48,c034b471,369,0) at ithread_loop+0x182
fork_exit(c01d3a60,c3ced800,e13c4d48) at fork_exit+0xaf
fork_trampoline() at fork_trampoline+0x1a
db> panic
panic: from debugger
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 10h56m14s
Dumping 2047 MB
ata0: resetting devices ..
panic: KSE not on run queue
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 10h56m15s
Terminate ACPI
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic: mutex pcm0:play:0 not owned at ../../../kern/kern_mutex.c:339
At Sun, 18 Aug 2002 07:17:07 -0700 (PDT),
Orion Hodson wrote:
> Modified files:
> sys/dev/sound/pcmdsp.c
> Log:
> Apply reference counting patch. Fixes problem of two applications
> opening the device, eg one read only and one write only, and the
> reference count being non-zero when both exit rendering device
> permanently busy.
After this, I got a panic around sound. With r1.54 of dsp.c, it looks
fine.
panic: mutex pcm0:play:0 not owned at ../../../kern/kern_mutex.c:339
panic: from debugger
panic messages:
---
dmesg: kernel message buffer has different magic number
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01ffcc9 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc01ffef8 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc0142152 in db_panic () at ../../../ddb/db_command.c:449
#4 0xc01420d2 in db_command (last_cmdp=0xc03d5f20, cmd_table=0xc0380688,
aux_cmd_tablep=0x104, aux_cmd_tablep_end=0xc1fbf6c0)
at ../../../ddb/db_command.c:345
#5 0xc01421e6 in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc014473e in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc0352d0f in kdb_trap (type=3, code=0, regs=0xcb5a0a64)
at ../../../i386/i386/db_interface.c:161
#8 0xc0362487 in trap (frame=
{tf_fs = -883294184, tf_es = -883294192, tf_ds = -1071841264, tf_edi = 256,
tf_esi = -1040451904, tf_ebp = -883291472, tf_isp = -883291504, tf_ebx = 0, tf_edx =
0, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070256204, tf_cs =
8, tf_eflags = 662, tf_esp = -1069786017, tf_ss = -1069952868})
at ../../../i386/i386/trap.c:605
#9 0xc03543d8 in calltrap () at {standard input}:98
#10 0xc01ffee0 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:479
#11 0xc01f696c in _mtx_assert (m=0x0, what=0, file=0xc1fbf6c0 "", line=256)
at ../../../kern/kern_mutex.c:800
#12 0xc01f6200 in _mtx_unlock_flags (m=0x0, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:339
#13 0xc01a63aa in pcm_chnrelease (c=0x0) at ../../../dev/sound/pcm/sound.c:229
#14 0xc01a144b in dsp_close (i_dev=0x100, flags=6, mode=8192, td=0xc1fbf6c0)
at ../../../dev/sound/pcm/dsp.c:382
#15 0xc01d5af7 in spec_close (ap=0xcb5a0ba4)
at ../../../fs/specfs/spec_vnops.c:631
#16 0xc01d4fd8 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:124
#17 0xc0255a56 in vn_close (vp=0xc210cde0, flags=0, file_cred=0x0, td=0x0)
at vnode_if.h:224
#18 0xc02568c0 in vn_closefile (fp=0x0, td=0x0)
at ../../../kern/vfs_vnops.c:877
#19 0xc01e4253 in fdrop_locked (fp=0xc210cde0, td=0x0) at file.h:256
#20 0xc01e3cfe in fdrop (fp=0xc200eb40, td=0x0)
at ../../../kern/kern_descrip.c:1625
#21 0xc01e3cac in closef (fp=0xc210cde0, td=0xc200eb40)
at ../../../kern/kern_descrip.c:1611
#22 0xc01e2328 in close (td=0xc1fbf6c0, uap=0x0)
at ../../../kern/kern_descrip.c:803
#23 0xc0362da1 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 1, tf_esi = -1077936672, tf_ebp =
-1077936884, tf_isp = -883290764, tf_ebx = 672599680, tf_edx = 0, tf_ecx = 191, tf_eax
= 6, tf_trapno = 22, tf_err = 2, tf_eip = 672156459, tf_cs = 31, tf_eflags = 643,
tf_esp = -1077936912, tf_ss = 47})
at ../../../i386/i386/trap.c:1050
#24 0xc035442d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) up 14
#14 0xc01a144b in dsp_close (i_dev=0x100, flags=6, mode=8192, td=0xc1fbf6c0)
at ../../../dev/sound/pcm/dsp.c:382
382 pcm_chnrelease(wrch);
(kgdb) list
377 }
378 if (wrch) {
379 chn_flush(wrch); /* may sleep */
380 wrch->flags &= ~(CHN_F_RUNNING | CHN_F_MAPPED | CHN_F_DEAD);
381 chn_reset(wrch, 0);
382 pcm_chnrelease(wrch);
383 }
384 i_dev->si_drv1 = NULL;
385 i_dev->si_drv2 = NULL;
386
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: CFLAGS=-O and WARN=5
At Wed, 14 Aug 2002 12:19:52 + (UTC), Philip Reynolds wrote: > The problem here, as is fairly self-evident is that you cannot > compile with -Wuninitialized without a -O flag because it produces > warnings that can only be seen through optomisation (it's got to do > with automatic variables, see gcc(1) for details). Yeah, I know why gcc complains about this. :-) What I want to know is, our buildworld does not been supported without -O or not. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CFLAGS=-O and WARN=5
When I tried make world with CFLAGS="-g -pipe" in make.conf, I got a result below. Is buildworld without CFLAGS=-O not supported? ===> bin/df cc -pipe -g -I/usr/src/bin/df/../../sbin/mount -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wuninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/bin/df/df.c cc1: warnings being treated as errors cc1: warning: -Wuninitialized is not supported without -O *** Error code 1 Stop in /usr/src/bin/df. *** Error code 1 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATAPI_SET_SPEED on Panasonic LF-D321
I got this drive ("LF-D321" is printed in front of drive), but burncd
cannot set speed.
> acd1: DVD-R at ata1-slave PIO4
% sudo burncd -f /dev/acd1c data release.iso
burncd: ioctl(CDRIOCWRITESPEED): Input/output error
Dmesg shows:
> acd1: SET_SPEED - ILLEGAL REQUEST asc=0x20 ascq=0x00 error=0x00
Cannot this drive accept ATAPI_SET_SPEED atapi command?
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
How to use gdb52 port
I've installed gdb-5.2_1, but I cannot debug usual code. I've tried
with "-g", "-gstabs+" and "-g -gstabs+" but got same result.
% cat test1.c
int main() { int *p; *p = 1; }
% cc -g test1.c -o test1
% ./test1
Bus error (core dumped)
% gdb52 test1 test1.core
GNU gdb 5.2 (FreeBSD)
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-portbld-freebsd5.0"...
Core was generated by `test1'.
Program terminated with signal 10, Bus error.
regcache.c:96: gdb-internal-error: register_buffer: Assertion `regnum >= 0 && re
gnum < (NUM_REGS + NUM_PSEUDO_REGS)' failed.
An internal GDB error was detected. This may make further
debugging unreliable. Quit this debugging session? (y or n)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Mozilla 1.0 error
At Fri, 7 Jun 2002 12:43:27 + (UTC), John Angelmo wrote: > (cd /usr/ports/www/mozilla/work/mozilla/dist/bin; /usr/bin/env > LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regxpcom; echo > skin,install,select,classic/1.0 >> chrome/installed-chrome.txt; echo > locale,install,select,en-US >> chrome/installed-chrome.txt; > /usr/bin/env LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regchrome) > [1] Segmentation fault (core dumped) > *** Error code 139 > > Stop in /usr/ports/www/mozilla. I got same result, too. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
could sleep with "process lock" from kern_prot.c:867
Just FYI. I got this with debug.witness_ddb=1 kernel.
../../../vm/uma_core.c:1327: could sleep with "process lock" locked from
../../../kern/kern_prot.c:867
Debugger("witness_sleep")
Stopped at breakpoint+0x4: popl%ebp
db> trace
breakpoint(e86f0bfc,c01f84ac,c036b060,c036b06e,e86f0bdc) at breakpoint+0x4
Debugger(c036b060) at Debugger+0x49
witness_sleep(1,0,c037e2b1,52f) at witness_sleep+0x178
uma_zalloc_arg(c081d600,0,4) at uma_zalloc_arg+0x46
uma_zalloc(c081d600,4) at uma_zalloc+0x10
malloc(20,c03bfee0,4) at malloc+0xa5
uifind(1) at uifind+0x5f
change_euid(e86bd800,1) at change_euid+0x26
setreuid(e86e1d60,e86f0cf8) at setreuid+0x13b
syscall(2f,2f,2f,bfbff550,1) at syscall+0x299
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (126, FreeBSD ELF, setreuid), eip = 0x280e8cbf, esp = 0xbfbff3f0, ebp =
0xbfbff40c ---
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in libfetch
This seems not yet fixed even after libfetch commit. U lib/libfetch/Makefile U lib/libfetch/common.c U lib/libfetch/common.h U lib/libfetch/http.c U usr.bin/fetch/Makefile ===> usr.sbin/pkg_install/add cc -O -pipe -march=pentium -I/usr/src/usr.sbin/pkg_install/add/../lib -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.sbin/pkg_install/add/main.c cc -O -pipe -march=pentium -I/usr/src/usr.sbin/pkg_install/add/../lib -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.sbin/pkg_install/add/perform.c cc -O -pipe -march=pentium -I/usr/src/usr.sbin/pkg_install/add/../lib -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.sbin/pkg_install/add/futil.c cc -O -pipe -march=pentium -I/usr/src/usr.sbin/pkg_install/add/../lib -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.sbin/pkg_install/add/extract.c cc -O -pipe -march=pentium -I/usr/src/usr.sbin/pkg_install/add/../lib -Wall -Wno-format-y2k -Wno-uninitialized -o pkg_add main.o perform.o futil.o extract.o /usr/obj/usr/src/usr.sbin/pkg_install/add/../lib/libinstall.a -lfetch -lmd /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_set_fd' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `X509_NAME_oneline' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_read' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_new' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_CTX_new' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_library_init' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `ERR_print_errors_fp' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_load_error_strings' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_CIPHER_get_name' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSLv23_client_method' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `X509_get_subject_name' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_get_current_cipher' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_connect' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `X509_get_issuer_name' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_get_peer_certificate' /usr/obj/usr/src/i386/usr/lib/libfetch.so: undefined reference to `SSL_write' *** Error code 1 Stop in /usr/src/usr.sbin/pkg_install/add. *** Error code 1 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
witness "process lock"
How about this?
../../../vm/uma_core.c:1324: could sleep with "process lock" locked from
../../../kern/kern_prot.c:867
../../../vm/uma_core.c:1324: could sleep with "process lock" locked from
../../../kern/kern_prot.c:511
Debugger("witness_sleep")
Stopped at breakpoint+0x4: leave
db> trace
breakpoint(e8760c00,c01f5bb6,c03669a0,c03669ae,e8760be0) at breakpoint+0x4
Debugger(c03669a0) at Debugger+0x49
witness_sleep(1,0,c0379e91,52c) at witness_sleep+0x178
uma_zalloc_arg(c081d3c0,0,4) at uma_zalloc_arg+0x46
uma_zalloc(c081d3c0,4) at uma_zalloc+0x10
malloc(20,c03bb760,4) at malloc+0xa1
uifind(2) at uifind+0x5f
change_ruid(e8733b80,2) at change_ruid+0x38
setuid(e86f6d50,e8760cf8) at setuid+0xf9
syscall(2f,2f,2f,8058380,12) at syscall+0x299
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (23, FreeBSD ELF, setuid), eip = 0x280b3a0b, esp = 0xbfbff71c, ebp =
0xbfbff748 ---
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gdb breaks world
At Mon, 27 May 2002 02:46:01 + (UTC), David O'Brien wrote: > Add it to COPTFLAGS. Why are you adding it to DEBUG? > ``grep DEBUG /sys/conf/*.mk /sys/conf/Makefile.*'' shows DEBUG is not > used this way. I added it to DEBUG because I think "-gstabs+" will be used as replacement of "-g". I added it to COPTFLAGS and tried again, but no luck. makeoptions COPTFLAGS=-gstabs+ #Build kernel with gdb(1) debug symbols (gdb) core-file /var/crash/vmcore.6 "/var/crash/vmcore.6" is not a core dump: File format not recognized Sorry for my silly questions... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gdb breaks world
At Sun, 26 May 2002 21:35:28 -0500, David W. Chapman Jr. <[EMAIL PROTECTED]> wrote: > > % sudo gdb52 > Last time I checked, gdb was broken in -current and people were > encouraged to use gdb in the ports system, but this may be oudated. Yes, I'm using gdb52 from ports/devel/gdb52. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gdb breaks world
At Wed, 22 May 2002 18:54:02 + (UTC), David O'Brien wrote: > -ggdb means to use the most "expressive" debugging format the compiler > knows about. You want -gstabs+ or -gstabs I cannot debug a kernel with -gstabs+ option. Any hints about this? % cd sys/i386/compile/WATERBLUE % grep gdb ../../conf/WATERBLUE makeoptions DEBUG=-gstabs+ #Build kernel with gdb(1) debug symbols % sudo gdb52 (gdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (gdb) exec-file kernel (gdb) core-file /var/crash/vmcore.4 "/var/crash/vmcore.4" is not a core dump: File format not recognized -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Messages from WITNESS [Sun May 26 kernel]
At Sun, 26 May 2002 22:19:58 + (UTC),
Alfred Perlstein wrote:
> Uh, why don't you guys enable 'debug.witness_ddb' and get us some
> tracebacks? :)
Could this help you?
../../../vm/uma_core.c:1324: could sleep with "process lock" locked from
../../../kern/kern_prot.c:867
../../../vm/uma_core.c:1324: could sleep with "pcm0:play:0" locked from
../../../dev/sound/pcm/sound.c:191
Debugger("witness_sleep")
Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c02d6fa0) at Debugger+0x46
witness_sleep(1,0,c02ea491,52c) at witness_sleep+0xf8
uma_zalloc_arg(c081d5a0,0,4) at uma_zalloc_arg+0x3e
malloc(30,c031b020,4,e2fc3180,0) at malloc+0x78
kobj_create(c031b0c0,c031b020,4,e2fc3180,e2f8cc00) at kobj_create+0x1a
feeder_create(c031b0c0,0,e2fc3180,e7f96974,c017ebb5) at feeder_create+0x18
chn_addfeeder(e2fc3180,c031b0c0,0) at chn_addfeeder+0x12
chn_buildfeeder(e2fc3180) at chn_buildfeeder+0x5b
chn_tryformat(e2fc3180,8,0,1f40,e2fc3180) at chn_tryformat+0x28
chn_setformat(e2fc3180,8,e2fc3338,3,c035cad0) at chn_setformat+0x15
chn_reset(e2fc3180,8) at chn_reset+0xc5
dsp_open(c035cad0,6,2000,e33a2414,e837f980) at dsp_open+0x21c
spec_open(e7f96a7c,e7f96b28,c01f5e69,e7f96a7c,6) at spec_open+0x12f
spec_vnoperate(e7f96a7c) at spec_vnoperate+0x13
vn_open_cred(e7f96c10,e7f96b64,0,e837f980,e7f96cec) at vn_open_cred+0x353
vn_open(e7f96c10,e7f96b64,0,c01c7c54,e7f690f0) at vn_open+0x18
open(e33a2414,e7f96d14,3,1,297) at open+0x155
syscall(2f,2f,2f,804e6a4,2807343a) at syscall+0x205
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (5, FreeBSD ELF, open), eip = 0x280f4bcb, esp = 0xbfbffa08, ebp =
0xbfbffa44 ---
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
could sleep with "pcm0:play:0" locked
I got this message (after fifo fix kernel): May 21 13:54:35 waterblue kernel: ../../../vm/uma_core.c:1324: could sleep with "pcm0:play:0" locked from ../../../dev/sound/pcm/dsp.c:734 May 21 13:54:35 waterblue kernel: ../../../vm/uma_core.c:1324: could sleep with "pcm0:play:0" locked from ../../../dev/sound/pcm/dsp.c:690 May 21 13:54:35 waterblue kernel: ../../../vm/uma_core.c:1324: could sleep with "pcm0:play:0" locked from ../../../dev/sound/pcm/dsp.c:765 May 21 13:54:35 waterblue kernel: ../../../vm/uma_core.c:1324: could sleep with "pcm0:play:0" locked from ../../../dev/sound/pcm/dsp.c:353 May 21 13:55:00 waterblue kernel: ../../../vm/uma_core.c:1324: could sleep with "process lock" locked from ../../../kern/kern_prot.c:511 May 21 13:55:00 waterblue kernel: ../../../vm/uma_core.c:1324: could sleep with "process lock" locked from ../../../kern/kern_prot.c:613 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lock order reversal (process lock @ kern_exec.c)
Here is a message of lock order reversal (just fresh current): lock order reversal 1st 0xe853eb18 process lock (process lock) @ ../../../kern/kern_exec.c:316 2nd 0xc0324400 filelist lock (filelist lock) @ ../../../kern/kern_descrip.c:1112 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Replace makeLINT.pl with makeLINT.sh
How about using this script instead of makeLINT.pl?
# MIME multipart post is rejected by hub...
-
#! /bin/sh
# $FreeBSD$
/usr/bin/sed -e 's/#.*//' -e 's/\ //' | /usr/bin/awk '
/^[ \t]*$/ { next }
/^hint\./ { next }
/^(\
machine|\
ident|\
device|\
makeoptions|\
options|\
profile|\
cpu|\
option|\
maxusers\
)[ \t]/ { print; next }
{ printf("unrecognized line: line %d: %s\n", NR, $0) > "/dev/stderr" }
'
-
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal and panic in kern_descrip.c
> No setuid executables ... it's a mystery to me how one encounters this > code path when running netscape :-( Hmmm, after patch about FILEDESC_LOCK (1.139), my netscape can run correctly. (@_@) -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal and panic in kern_descrip.c
> I have no idea about this. I'm portupgrade'ing linux_base, > linux-netscape-* port and I'll try this again. Hmm, I can reproduce this even after upgrading related ports... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal and panic in kern_descrip.c
At Mon, 22 Apr 2002 11:09:26 -0500, Jacques A. Vidrine <[EMAIL PROTECTED]> wrote: > I'm curious ... could you send the output of > > pkg_info -L linux-netscape-navigator-4.79 | xargs ls -l Attached. > Also, does `/compat/linux/bin/sh' blow up for you? No, I can invoke this without problem... -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project -r-xr-xr-x 1 root wheel 293 Apr 22 22:37 /usr/local/bin/navigator-linux-4.79 -r--r--r-- 1 root wheel16934 Oct 17 2001 /usr/local/lib/netscape-linux/LICENSE -r--r--r-- 1 root wheel 323710 Oct 17 2001 /usr/local/lib/netscape-linux/Netscape.ad -r--r--r-- 1 root wheel16731 Oct 17 2001 /usr/local/lib/netscape-linux/README -r--r--r-- 1 root wheel 4674 Oct 18 1994 /usr/local/lib/netscape-linux/XKeysymDB -r--r--r-- 1 root wheel 4568 Oct 17 2001 /usr/local/lib/netscape-linux/bookmark.htm -r--r--r-- 1 root wheel 5861 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/aix/font.properties -r--r--r-- 1 root wheel 6069 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/aix/font.properties.cs -r--r--r-- 1 root wheel 6073 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/aix/font.properties.hu -r--r--r-- 1 root wheel 9941 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/aix/font.properties.ja -r--r--r-- 1 root wheel 7744 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/aix/font.properties.ko -r--r--r-- 1 root wheel 6070 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/aix/font.properties.pl -r--r--r-- 1 root wheel 6071 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/aix/font.properties.ru -r--r--r-- 1 root wheel 7708 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/aix/font.properties.zh -r--r--r-- 1 root wheel 8893 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/aix/font.properties.zh_TW -r--r--r-- 1 root wheel 981 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/awt.properties -r--r--r-- 1 root wheel 7304 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties -r--r--r-- 1 root wheel 7757 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.cs -r--r--r-- 1 root wheel 7713 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.el -r--r--r-- 1 root wheel 7758 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.hu -r--r--r-- 1 root wheel13029 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.ja -r--r--r-- 1 root wheel 9033 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.ko -r--r--r-- 1 root wheel 7771 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.lt -r--r--r-- 1 root wheel 7771 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.lv -r--r--r-- 1 root wheel 7758 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.pl -r--r--r-- 1 root wheel 7711 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.ru -r--r--r-- 1 root wheel 7721 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.tr -r--r--r-- 1 root wheel 8976 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.zh -r--r--r-- 1 root wheel 8984 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.zh_GB2312 -r--r--r-- 1 root wheel23909 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.zh_TW -r--r--r-- 1 root wheel 8737 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.zh_TW_Big5 -r--r--r-- 1 root wheel23946 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/font.properties.zh_TW_CNS11643 -r-xr-xr-x 1 root wheel11179 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/hpux/font.properties -r-xr-xr-x 1 root wheel 8364 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/hpux/font.properties.bg -r-xr-xr-x 1 root wheel 8672 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/hpux/font.properties.cs -r-xr-xr-x 1 root wheel 8360 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/hpux/font.properties.el -r-xr-xr-x 1 root wheel 8670 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/hpux/font.properties.hr -r-xr-xr-x 1 root wheel 8676 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/hpux/font.properties.hu -r-xr-xr-x 1 root wheel17681 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/hpux/font.properties.ja -r-xr-xr-x 1 root wheel14797 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/hpux/font.properties.ko -r-xr-xr-x 1 root wheel 8673 Oct 5 1998 /usr/local/lib/netscape-linux/java/classes/hpux/font.properties.pl -r-xr-xr-x 1 root wheel 86
Re: lock order reversal and panic in kern_descrip.c
At Mon, 22 Apr 2002 07:32:39 -0500, Jacques A. Vidrine <[EMAIL PROTECTED]> wrote: > Does it happen every time? I cannot reproduce it. Yes. > What is odd is that fdcheckstd() is only called when exec'ing a > set[ug]id executable -- any idea what set[ug]id program is being > exec'd here? I have no idea about this. I'm portupgrade'ing linux_base, linux-netscape-* port and I'll try this again. > > #14 0xc019d01b in fdcheckstd (td=0xe7f8ed50) > > at ../../../kern/kern_descrip.c:1532 > > #15 0xc01a04e2 in execve (td=0xe7f8ed50, uap=0xe805bcdc) > > at ../../../kern/kern_exec.c:372 > > My -CURRENT is a few days old. I'll see if updating allows me to > reproduce the problem. A kern_descrip.c is updated by tanimura after your r1.137. Could you try with r1.138? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lock order reversal and panic in kern_descrip.c
Today's -current kernel. This happend when I invoke linux-netscape.
lock order reversal
1st 0xe7fdf134 filedesc structure (filedesc structure) @
../../../kern/kern_descrip.c:1531
2nd 0xc0321ca0 filelist lock (filelist lock) @ ../../../kern/kern_descrip.c:1092
recursed on non-recursive lock (sleep mutex) filedesc structure @
../../../kern/kern_descrip.c:1114
first acquired @ ../../../kern/kern_descrip.c:1531
panic: recurse
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x41: xorl%eax,%eax
db> trace
Debugger(c02d523a) at Debugger+0x41
panic(c02d8808,e7fdf134,0,c02d1af3,0) at panic+0xd8
witness_lock(e7fdf134,8,c02d1af3,45a) at witness_lock+0x198
_mtx_lock_flags(e7fdf134,0,c02d1af3,45a,e7a5be10) at _mtx_lock_flags+0x74
falloc(e7f8ed50,e805baa0,e805baa8,e7fdf134,0) at falloc+0xaf
fdcheckstd(e7f8ed50,e805bd20,e7f8ed50,bfbfc2d0,e7f8ec50) at fdcheckstd+0x1d7
execve(e7f8ed50,e805bcdc,e7f8ee2c,e7f8ec50,bfbffeb8) at execve+0x6ae
linux_execve(e7f8ed50,e805bd20,bfbfc2d0,84a9d2a,bfbfc2d0) at linux_execve+0x5b
syscall(85b002f,bfbf002f,bfbf002f,bfbfc2d0,84a9d2a) at syscall+0x223
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (11, FreeBSD ELF, nosys), eip = 0x2881990b, esp = 0xbfbfc298, ebp =
0xbfbfc2a8 ---
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01b26b8 in boot (howto=260) at ../../../kern/kern_shutdown.c:346
#2 0xc01b28c9 in panic (fmt=0xc02be36a "from debugger")
at ../../../kern/kern_shutdown.c:490
#3 0xc0131891 in db_panic (addr=-1071031351, have_addr=0, count=-1,
modif=0xe805b88c "") at ../../../ddb/db_command.c:449
#4 0xc013182f in db_command (last_cmdp=0xc03020e4, cmd_table=0xc0301f04,
aux_cmd_tablep=0xc02fc238, aux_cmd_tablep_end=0xc02fc23c)
at ../../../ddb/db_command.c:345
#5 0xc01318fb in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc0133c8f in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc029590a in kdb_trap (type=3, code=0, regs=0xe805b988)
at ../../../i386/i386/db_interface.c:161
#8 0xc02a98ec in trap (frame={tf_fs = -403177448, tf_es = 16,
tf_ds = -403177456, tf_edi = -1070024964, tf_esi = 256,
tf_ebp = -402277936, tf_isp = -402277964, tf_ebx = -1070757880,
tf_edx = 0, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1071031351, tf_cs = 8, tf_eflags = 582, tf_esp = -1070645245,
tf_ss = -1070771654}) at ../../../i386/i386/trap.c:585
#9 0xc0295bc9 in Debugger (msg=0xc02d523a "panic") at machine/cpufunc.h:68
#10 0xc01b28b4 in panic (fmt=0xc02d8808 "recurse")
at ../../../kern/kern_shutdown.c:477
#11 0xc01ca3d8 in witness_lock (lock=0xe7fdf134, flags=8,
file=0xc02d1af3 "../../../kern/kern_descrip.c", line=1114)
at ../../../kern/subr_witness.c:533
#12 0xc01aad4c in _mtx_lock_flags (m=0xe7fdf134, opts=0,
file=0xc02d1af3 "../../../kern/kern_descrip.c", line=1114)
at ../../../kern/kern_mutex.c:314
#13 0xc019c3df in falloc (td=0xe7f8ed50, resultfp=0xe805baa0,
resultfd=0xe805baa8) at ../../../kern/kern_descrip.c:1114
#14 0xc019d01b in fdcheckstd (td=0xe7f8ed50)
at ../../../kern/kern_descrip.c:1532
#15 0xc01a04e2 in execve (td=0xe7f8ed50, uap=0xe805bcdc)
at ../../../kern/kern_exec.c:372
#16 0xe7cc3aff in ?? ()
#17 0xc02aa08f in syscall (frame={tf_fs = 140181551, tf_es = -1078001617,
tf_ds = -1078001617, tf_edi = -1077951792, tf_esi = 139107626,
tf_ebp = -1077951832, tf_isp = -402277004, tf_ebx = -1077951792,
tf_edx = 143628032, tf_ecx = -1077951676, tf_eax = 11, tf_trapno = 12,
tf_err = 2, tf_eip = 679581963, tf_cs = 31, tf_eflags = 582,
tf_esp = -1077951848, tf_ss = 47}) at ../../../i386/i386/trap.c:1022
#18 0xc02968dd in syscall_with_err_pushed ()
Cannot access memory at address 0xbfbfc2a8.
(kgdb) up 11
#11 0xc01ca3d8 in witness_lock (lock=0xe7fdf134, flags=8,
file=0xc02d1af3 "../../../kern/kern_descrip.c", line=1114)
at ../../../kern/subr_witness.c:533
533 panic("recurse");
(kgdb) list
528 printf(
529 "recursed on non-recursive lock (%s) %s @ %s:%d\n",
530 class->lc_name, lock->lo_name, file, line);
531 printf("first acquired @ %s:%d\n", lock1->li_file,
532 lock1->li_line);
533 panic("recurse");
534 }
535 CTR4(KTR_WITNESS, "%s: pid %d recursed on %s r=%d", __func__,
536 td->td_proc->p_pid, lock->lo_name,
537 lock1->li_flags & LI_RECURSEMASK);
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic: lockmgr: draining against myself
This is today's kernel. Should I test with -DDEBUG_LOCKS?
-
panic: lockmgr: draining against myself
cpuid = 1; lapic.id = 0100
Debugger("panic")
Stopped at Debugger+0x41: xorl%eax,%eax
db> trace
Debugger(c029d1ba) at Debugger+0x41
panic(c029ae60,e908e780,e325cd50,0,0) at panic+0xd8
lockmgr(e908e828,10007,e908e7e8,e325cd50,e326099c) at lockmgr+0x3ef
vop_stdlock(e32609d0,e32609e0,c01c51f6,e32609d0,e908e780) at vop_stdlock+0x1f
ufs_vnoperate(e32609d0) at ufs_vnoperate+0x15
vclean(e908e780,8,e325cd50,e908e780,e3260a10) at vclean+0x62
vgonel(e908e780,e325cd50,e908e780,e909b300,e3260a48) at vgonel+0x37
vrecycle(e908e780,0,e325cd50,e908e780,e325cd50) at vrecycle+0x4b
ufs_inactive(e3260a68,e3260a78,c01c4da4,e3260a68,e8482580) at ufs_inactive+0x160
ufs_vnoperate(e3260a68) at ufs_vnoperate+0x15
vput(e908e780) at vput+0xe4
handle_workitem_freeblocks(e8482580,0,e909b300,e909b300,e325cd50) at
handle_workitem_freeblocks+0x193
softdep_setup_freeblocks(e909b300,0,0,e908e780,e909b300) at
softdep_setup_freeblocks+0x31f
ffs_truncate(e908e780,0,0,0,0) at ffs_truncate+0x240
ufs_inactive(e3260c60,e3260c70,c01c4da4,e3260c60,0) at ufs_inactive+0x91
ufs_vnoperate(e3260c60) at ufs_vnoperate+0x15
vput(e908e780,c02e3bdc,e7f65f40,e79d8000,0) at vput+0xe4
handle_workitem_remove(e7f65f40,0,e325cd50,0,0) at handle_workitem_remove+0x15f
process_worklist_item(0,0) at process_worklist_item+0x113
softdep_process_worklist(0) at softdep_process_worklist+0x106
sched_sync(0,e3260d48,e325cd50,c01c414c,0) at sched_sync+0x190
fork_exit(c01c414c,0,e3260d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x37
-
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc0188e4c in boot (howto=260) at ../../../kern/kern_shutdown.c:346
#2 0xc018905d in panic (fmt=0xc028c74a "from debugger")
at ../../../kern/kern_shutdown.c:490
#3 0xc012f591 in db_panic (addr=-1071235275, have_addr=0, count=-1,
modif=0xe3260804 "") at ../../../ddb/db_command.c:449
#4 0xc012f52f in db_command (last_cmdp=0xc02c8fc4, cmd_table=0xc02c8de4,
aux_cmd_tablep=0xc02c31c8, aux_cmd_tablep_end=0xc02c31cc)
at ../../../ddb/db_command.c:345
#5 0xc012f5fb in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc013198f in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc0263c76 in kdb_trap (type=3, code=0, regs=0xe3260900)
at ../../../i386/i386/db_interface.c:161
#8 0xc0277c5c in trap (frame={tf_fs = -385351656, tf_es = -484048880,
tf_ds = -1072168944, tf_edi = 7, tf_esi = 256, tf_ebp = -484046520,
tf_isp = -484046548, tf_ebx = -1071010208, tf_edx = -484061872,
tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1071235275, tf_cs = 8, tf_eflags = 582, tf_esp = -1070878077,
tf_ss = -1071001158}) at ../../../i386/i386/trap.c:585
#9 0xc0263f35 in Debugger (msg=0xc029d1ba "panic") at machine/cpufunc.h:68
#10 0xc0189048 in panic (fmt=0xc029ae60 "lockmgr: draining against myself")
at ../../../kern/kern_shutdown.c:477
#11 0xc017ef37 in lockmgr (lkp=0xe908e828, flags=65543, interlkp=0xe908e7e8,
td=0xe325cd50) at ../../../kern/kern_lock.c:427
#12 0xc01c0bef in vop_stdlock (ap=0xe32609d0)
at ../../../kern/vfs_default.c:282
#13 0xc02396bd in ufs_vnoperate (ap=0xe32609d0)
at ../../../ufs/ufs/ufs_vnops.c:2660
...
(kgdb) up 11
#11 0xc017ef37 in lockmgr (lkp=0xe908e828, flags=65543, interlkp=0xe908e7e8,
td=0xe325cd50) at ../../../kern/kern_lock.c:427
427 panic("lockmgr: draining against myself");
(kgdb) list
422 * never drain if we do. Unfortunately, we have no way to
423 * check for holding a shared lock, but at least we can
424 * check for an exclusive one.
425 */
426 if (lkp->lk_lockholder == pid)
427 panic("lockmgr: draining against myself");
428
429 error = acquiredrain(lkp, extflags);
430 if (error)
431 break;
(kgdb) up
#12 0xc01c0bef in vop_stdlock (ap=0xe32609d0)
at ../../../kern/vfs_default.c:282
282 return (lockmgr(&vp->v_lock, ap->a_flags, &vp->v_interlock, ap->a_td));
(kgdb) list
277 } */ *ap;
278 {
279 struct vnode *vp = ap->a_vp;
280
281 #ifndef DEBUG_LOCKS
282 return (lockmgr(&vp->v_lock, ap->a_flags, &vp->v_interlock, ap->a_td));
283 #else
284 return (debuglockmgr(&vp->v_lock, ap->a_flags, &vp->v_interlock,
285 ap->a_td, "vop_stdlock", vp->filename, vp->line));
286 #endif
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
lock order reversal (vm/uma_core.c:269)
Today's -current kernel. lock order reversal 1st 0xe322f024 DIRHASH (UMA zone) @ ../../../vm/uma_core.c:269 2nd 0xc081da94 PCPU 256 (UMA cpu) @ ../../../vm/uma_core.c:1265 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Assertion faild at kern_mutex.c
At Fri, 1 Mar 2002 01:34:17 + (UTC), John Baldwin wrote: > That's bad juju panic. :) Are you using witness? If so, did you get a printf > about sleeping with a lock held? I forgot to mention, I'm using WITNESS and WITNESS_SKIPSPIN options. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Assertion faild at kern_mutex.c
At Fri, 1 Mar 2002 01:34:17 + (UTC), John Baldwin wrote: > That's bad juju panic. :) Are you using witness? If so, did you get a printf > about sleeping with a lock held? I think I did not get lock warning just before this assertion failure. But on my environment, I got this lock order reversal everytime I booted. lock order reversal 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Assertion faild at kern_mutex.c
At Thu, 28 Feb 2002 17:10:25 + (UTC), David Wolfskill wrote: > >Sorry, I forgot to get kernel core for this (today's -current)... > > >panic: Assertion td->td_proc->p_stat == SRUN || td->td_proc->p_stat == SZOMB || >td->td_proc->p_stat == SSTOP failed at ../../../kern/kern_mutex.c:126 > > I have yet to see this, running either: I cannot reproduce this assertion failure. I'll try to get core if I got this failure next time. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Assertion faild at kern_mutex.c
Sorry, I forgot to get kernel core for this (today's -current)... panic: Assertion td->td_proc->p_stat == SRUN || td->td_proc->p_stat == SZOMB || td->td_proc->p_stat == SSTOP failed at ../../../kern/kern_mutex.c:126 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
lock order reversal (vfs_syscalls.c)
I got this message on today's -current: lock order reversal 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
struct {bio,buf} pointer for bioqdisksort()
In arstrategy() at dev/ata/ata-raid.c, memory is allocated with size
of "struct ar_buf" and passed as "struct bio*".
> buf1 = malloc(sizeof(struct ar_buf), M_AR, M_NOWAIT | M_ZERO);
...
> buf1->bp.bio_dev->AD_STRATEGY((struct bio *)buf1);
This works fine because "struct ar_buf" contains "struct bio" as first
member.
> struct ar_buf {
> struct biobp;
...
This pointer is passed to bioqdisksort() as "struct bio*".
In bioqdisksort() at kern/subr_disklabel.c, "struct bio *bp" is
converted into "struct buf*" with BIOTOBUF() macro.
> void
> bioqdisksort(bioq, bp)
> struct bio_queue_head *bioq;
> struct bio *bp;
> {
...
> if (td && td->td_ksegrp->kg_nice > 0) {
> TAILQ_FOREACH(bn, &bioq->queue, bio_queue)
> if (BIOTOBUF(bp)->b_vp != BIOTOBUF(bn)->b_vp)
> break;
On my environment, this causes panic because "*bp" does not have
enough allocated region.
(kgdb) p sizeof(struct bio)
$1 = 80
(kgdb) p sizeof(struct ar_buf)
$2 = 96
(kgdb) p sizeof(struct buf)
$3 = 364
I'm not familiar with this area, but I think
(1) arstrategy() should allocate enough size to cover "struct buf" for
"struct ar_buf",
(2) bioqdisksort() should not suppose "struct bio *bp" can be
converted into "struct buf*", or
(3) Call chain such as arstrategy() -> adstrategy() -> bioqdisksort()
is wrong.
Can someone explain what I should do next about this?
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
World breakage (lib/libroken)
Is this the problem on my local environment only? ===> libroken awk -f /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.h.in > make-roken.c awk: /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk:18: warning: escape sequence `\#' treated as plain `#' cc -O -mpentiumpro -pipe -march=pentiumpro -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I/usr/obj/usr/src/kerberos5/lib/libroken -Wall -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../include -DHAVE_CONFIG_H -DINET6 -I/usr/obj/usr/src/i386/usr/include make-roken.c -o make-roken /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot find -lc *** Error code 1 Stop in /usr/src/kerberos5/lib/libroken. *** Error code 1 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
World breakage (lib/libroken)
Is this the problem on my local environment only? ===> libroken awk -f /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.h.in > make-roken.c awk: /usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken.awk:18: warning: escape sequence `\#' treated as plain `#' cc -O -mpentiumpro -pipe -march=pentiumpro -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/include -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I/usr/obj/usr/src/kerberos5/lib/libroken -Wall -I/usr/src/kerberos5/lib/libroken/../../include -I/usr/src/kerberos5/lib/libroken/../../include -DHAVE_CONFIG_H -DINET6 -I/usr/obj/usr/src/i386/usr/include make-roken.c -o make-roken /usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot find -lc *** Error code 1 Stop in /usr/src/kerberos5/lib/libroken. *** Error code 1 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic in bioqdisksort()
I got another panic with yesterday's kernel.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0xc9256040
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01ccf1b
stack pointer = 0x10:0xf12bb828
frame pointer = 0x10:0xf12bb834
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 = 458 (fsck_ufs)
kernel: type 12 trap, code=0
Stopped at bioqdisksort+0x2b: movl0xc0(%ebx),%eax
db> trace
bioqdisksort(c8eab4a8,c9255f80,c8eaa000,f12bb880,c014e3ce) at bioqdisksort+0x2b
adstrategy(c9255f80) at adstrategy+0x39
arstrategy(d5472908,d5472908,ec3638c0,f12bb8ac,c01a0093) at arstrategy+0x2de
diskstrategy(d5472908,c8eb3000,d5472908,c901f000,f12bb8b8) at diskstrategy+0xa1
spec_strategy(f12bb8d0,f12bb8dc,c02911cd,f12bb8d0,d5472908) at spec_strategy+0x19b
spec_vnoperate(f12bb8d0,d5472908,c901f000,200a4,c0334ce0) at spec_vnoperate+0x15
ufs_strategy(f12bb900,f12bb90c,c01ed1d7,f12bb900,800) at ufs_strategy+0xa9
ufs_vnoperate(f12bb900) at ufs_vnoperate+0x15
bwrite(d5472908,f12bb950,c027f195,d5472908,c901f000) at bwrite+0x25f
bawrite(d5472908,c901f000,c9020f00,f13eed00,2) at bawrite+0x16
cgaccount(12,f13eed00,d55b2d78,1,c901f000) at cgaccount+0x26d
ffs_snapshot(c9014400,80b20e0,0,c9014400,0) at ffs_snapshot+0x939
ffs_mount(c9014400,c9138380,bfbffcb4,f12bbc18,f11a8104) at ffs_mount+0x458
vfs_mount(f11a8104,c902bd40,c9138380,1211100,bfbffcb4) at vfs_mount+0x622
mount(f11a8104,f12bbd20,80b66a6,80b6600,bfbffdc8) at mount+0x6a
syscall(2f,2f,2f,bfbffdc8,80b6600) at syscall+0x25f
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
(kgdb) up 11
#11 0xc01ccf1b in bioqdisksort (bioq=0xc8eab4a8, bp=0xc9255f80)
at ../../../kern/subr_disklabel.c:91
91 TAILQ_FOREACH(bn, &bioq->queue, bio_queue)
(kgdb) list
86 struct bio *bn;
87 struct bio *be;
88 struct thread *td = curthread;
89
90 if (td && td->td_ksegrp->kg_nice > 0) {
91 TAILQ_FOREACH(bn, &bioq->queue, bio_queue)
92 if (BIOTOBUF(bp)->b_vp !=
BIOTOBUF(bn)->b_vp)
93 break;
94 if (bn != NULL) {
95 mtx_lock(&dksort_mtx);
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic: bioqdisksort()
TAILQ_FOREACH(bn, &bioq->queue, bio_queue)
(kgdb) list
86 struct bio *bn;
87 struct bio *be;
88 struct thread *td = curthread;
89
90 if (td && td->td_ksegrp->kg_nice > 0) {
91 TAILQ_FOREACH(bn, &bioq->queue, bio_queue)
92 if (BIOTOBUF(bp)->b_vp != BIOTOBUF(bn)->b_vp)
93 break;
94 if (bn != NULL) {
95 mtx_lock(&dksort_mtx);
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fsck panic; ffs_vfree: freeing free inode
I got panic of background fsck (installworld'ed at 2001/12/28).
-
Additional TCP options:.
Starting background filesystem checks
Thu Jan 3 13:07:17 JST 2002
panic: handle_disk_io_initiation: Unexpected type ???
cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x45: pushl %ebx
db> trace
Debugger(c02f6359) at Debugger+0x45
panic(c0311ae0,c0311045,d54ea724,ebff2d40,c9087800) at panic+0xd8
softdep_disk_io_initiation(d54ea724) at
softdep_disk_io_initiation+0x144
spec_strategy(f0f558dc,f0f558e8,c028c7b5,f0f558dc,d54ea724) at
spec_strategy+0x69
spec_vnoperate(f0f558dc,d54ea724,f0f17a20,210b4,c03282c0) at
spec_vnoperate+0x15
ufs_strategy(f0f5590c,f0f55918,c01e996f,f0f5590c,d54ea724) at
ufs_strategy+0xa9
ufs_vnoperate(f0f5590c) at ufs_vnoperate+0x15
bwrite(d54ea724,f0f55960,c0285334,d54ea724,3) at bwrite+0x25f
bawrite(d54ea724,3,f0f17a20,246,32) at bawrite+0x16
ffs_fsync(f0f559f8,c900e800,ebff2d40,0,20) at ffs_fsync+0x21c
ffs_snapshot(c900cc00,80b2060,0,c900cc00,0) at ffs_snapshot+0x983
ffs_mount(c900cc00,c901fc00,bfbffcb4,f0f55c1c,f0f4ec04) at
ffs_mount+0x43c
vfs_mount(f0f4ec04,c8bc0470,c901fc00,1211000,bfbffcb4) at
vfs_mount+0x622
mount(f0f4ec04,f0f55d20,80b62a6,80b6200,bfbffdc8) at mount+0x6a
syscall(2f,2f,2f,bfbffdc8,80b6200) at syscall+0x257
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (21, FreeBSD ELF, mount), eip = 0x805363b, esp =
0xbfbffc08, ebp = 0xbfbffd24 ---
-
-
(kgdb) up 11
#11 0xc027f6e8 in softdep_disk_io_initiation (bp=0xd54ea724)
at ../../../ufs/ffs/ffs_softdep.c:3207
3207panic("handle_disk_io_initiation:
Unexpected type %s",
(kgdb) list
3202case D_ALLOCDIRECT:
3203case D_ALLOCINDIR:
3204continue;
3205
3206default:
3207panic("handle_disk_io_initiation:
Unexpected type %s",
3208TYPENAME(wk->wk_type));
3209/* NOTREACHED */
3210 }
3211}
-
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Yet another panic at pgfind()
This is yesterday's -current. Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x114 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b6c40 stack pointer = 0x10:0xf1947cd8 frame pointer = 0x10:0xf1947cd8 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 = 76144 (cron) kernel: type 12 trap, code=0 Stopped at pgfind+0x1c:cmpl%ecx,0x14(%eax) db> Context switches not allowed in the debugger. db> trace pgfind(12970) at pgfind+0x1c setsid(f10ab604,f1947d20,8058000,8051060,805514a) at setsid+0x3f syscall(2f,2f,2f,805514a,8051060) at syscall+0x257 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (147, FreeBSD ELF, setsid), eip = 0x280b5a43, esp =0xbfbff700, ebp = 0xbfbffcac --- -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Forward: if_fxp.c typo?
Hmm, -current has same problem. It should fix in -current... --- Begin Message --- Hi all, fxp_stop() of the latest fxp driver do SOFTWARE_RESET when called. Shouldn't this be SELECTIVE_RESET? As I'm not familiar with fxp, would someone check and commit it to the repositry? The current code clears all the hardware mc filters already set, as a result, the box can't receive any multicast packets (this is a serious problem especially when using ipv6). --- Keiichi SHIMA IIJ Research Laboratory <[EMAIL PROTECTED]> KAME Project <[EMAIL PROTECTED]> --- orig/if_fxp.c Thu Nov 8 18:30:10 2001 +++ if_fxp.cThu Nov 22 17:22:38 2001 @@ -1429,7 +1429,7 @@ * Issue software reset, which also unloads the microcode. */ sc->flags &= ~FXP_FLAG_UCODE; - CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SOFTWARE_RESET); + CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SELECTIVE_RESET); DELAY(50); /* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message --- End Message --- --- Begin Message --- I noticed this fixes my problem, but I don't know this patch is logically correct or not. I think we should commit this before 4.5-RELEASE if this is correct way. Can someone comment this? At Thu, 22 Nov 2001 08:47:09 + (UTC), Keiichi SHIMA / $BEg7D0l(B wrote: > fxp_stop() of the latest fxp driver do SOFTWARE_RESET when called. > Shouldn't this be SELECTIVE_RESET? > > As I'm not familiar with fxp, would someone check and commit it to the > repositry? The current code clears all the hardware mc filters > already set, as a result, the box can't receive any multicast packets > (this is a serious problem especially when using ipv6). ... > --- orig/if_fxp.c Thu Nov 8 18:30:10 2001 > +++ if_fxp.c Thu Nov 22 17:22:38 2001 > @@ -1429,7 +1429,7 @@ >* Issue software reset, which also unloads the microcode. >*/ > sc->flags &= ~FXP_FLAG_UCODE; > - CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SOFTWARE_RESET); > + CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SELECTIVE_RESET); > DELAY(50); > > /* -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message --- End Message ---
Re: FYI: Panic at in_pcbremlists()
At Fri, 21 Dec 2001 10:06:38 -0600 (CST),
Jonathan Lemon wrote:
> >I got a panic with today's current. I don't know I can reproduce this
> >panic or not...
>
> This probably is in:
>
> 1015if (LIST_FIRST(&phd->phd_pcblist) == NULL) {
> 1016LIST_REMOVE(phd, phd_hash);
> 1017free(phd, M_PCB);
>
> but without the structure pointers, there isn't much to debug.
> Is there a crash dump available?
Yes, I have. But this machine have 2GB memory and dump is 2GB, too.
So it is difficult to send dump. If you can instruct how I should do,
I'll follow you.
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
FYI: Panic at in_pcbremlists()
I got a panic with today's current. I don't know I can reproduce this panic or not... Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0214186 stack pointer = 0x10:0xe519cc88 frame pointer = 0x10:0xe519cc8c 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 = 13 (swi6: tty:sio clock) kernel: type 12 trap, code=0 Stopped at in_pcbremlists+0x82:movl%eax,0x4(%edx) db> Context switches not allowed in the debugger. db> trace in_pcbremlists(e9fb11e0,e9fb11e0,0,e9fb12a0,e9fb11e0) at in_pcbremlists+0x82 in_pcbdetach(e9fb11e0,6,e9fb12a0,c0225f0c,e9fb12a0) at in_pcbdetach+0x35 tcp_close(e9fb12a0,e519ccf8,c01c4246,e9fb12a0,c386c2c0) at tcp_close+0x236 tcp_timer_2msl(e9fb12a0) at tcp_timer_2msl+0x52 softclock(0) at softclock+0x136 ithread_loop(c386d180,e519cd48,c386d180,c01aeef0,0) at ithread_loop+0x12e fork_exit(c01aeef0,c386d180,e519cd48) at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Broken at share/colldef
===> share ===> share/colldef colldef -I /usr/src/share/colldef -o bg_BG.CP1251.out /usr/src/share/colldef/bg_BG.CP1251.src ... /sv_SE.ISO8859-1.src colldef -I /usr/src/share/colldef -o uk_UA.ISO8859-5.out /usr/src/share/colldef/uk_UA.ISO8859-5.src colldef: Char 0xcd duplicated near line 36 *** Error code 69 Stop in /usr/src/share/colldef. *** Error code 1 Stop in /usr/src/share. *** Error code 1 -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XF86 with agp.ko and mga.ko
I'm using XFree86-Server-4.1.0_2 and drm-kmod-0.9.4 with - module_path="/;/boot;/modules;/usr/local/lib/drm" agp_load="YES" mga_load="YES" linux_load="YES" - lines in /boot/loader.conf. World at 2001/12/10 is fine for me, but after installworld'ing of today's world (2001/12/12) my X server is slowed down. My kernel shows too many lines to console like this: - Dec 12 17:06:03 waterblue kernel: error: [drm:mga_dma_flush] *ERROR* mga_dma_flush called without lock held Dec 12 17:06:03 waterblue kernel: error: [drm:mga_dma_reset] *ERROR* mga_dma_reset called without lock held - I re-installed XFree86-Server and drm-kmod but X is still really slow. I'm using X without mga.ko (this shows reasonable speed). Does anyone know any hints about this? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
