amusing KSE ktrace.
It occured to me to day to look at several KSE threads running under ktrace.. Talk about confusing.. The key to understanding it is that the lines RET fork 0 are actually the upcalls when a thread blocks, and they will report to the userland scheduler all the RETs that occured since the last RET fork 0 In any case it sure is difficult to follow :-) (6 threads each printing one char and then sleeping) 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x84b7fcc,0x84b7fc4) 17595 ksetest CALL nanosleep(0x84a6fcc,0x84a6fc4) 17595 ksetest CALL write(0x1,0xbfbffc17,0x1) 17595 ksetest GIO fd 1 wrote 1 byte K 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x8275fcc,0x8275fc4) 17595 ksetest RET fork 0 17595 ksetest CALL nanosleep(0x8264fcc,0x8264fc4) 17595 ksetest RET fork 0 17595 ksetest CALL kse_yield 17595 ksetest CALL nanosleep(0xbfbffc10,0xbfbffc08) 17595 ksetest RET fork 0 17595 ksetest CALL kse_yield 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest CALL write(0x1,0x84b7fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte . 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x84a6fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte * 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x8264fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte + 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x8275fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte - 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x84b7fcc,0x84b7fc4) 17595 ksetest CALL nanosleep(0x84a6fcc,0x84a6fc4) 17595 ksetest CALL write(0x1,0xbfbffc17,0x1) 17595 ksetest GIO fd 1 wrote 1 byte L 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x8264fcc,0x8264fc4) 17595 ksetest RET fork 0 17595 ksetest CALL nanosleep(0x8275fcc,0x8275fc4) 17595 ksetest RET fork 0 17595 ksetest CALL kse_yield 17595 ksetest CALL nanosleep(0xbfbffc10,0xbfbffc08) 17595 ksetest RET fork 0 17595 ksetest CALL kse_yield 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest RET nanosleep 0 17595 ksetest CALL write(0x1,0x84b7fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte . 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x84a6fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte * 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x8275fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte - 17595 ksetest RET write 1 17595 ksetest CALL write(0x1,0x8264fd3,0x1) 17595 ksetest GIO fd 1 wrote 1 byte + 17595 ksetest RET write 1 17595 ksetest CALL nanosleep(0x84b7fcc,0x84b7fc4) 17595 ksetest CALL nanosleep(0x84a6fcc,0x84a6fc4) 17595 ksetest CALL write(0x1,0xbfbffc17,0x1) 17595 ksetest GIO fd 1 wrote 1 byte To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PATCH: various memory leaks.
I went through the FlexeLint output of the LINT kernel on i386 and
tried to examine all warnings about memoryleaks in central or
semi-central code.
I this patch I belive addresses the ones I think I could confirm,
in the following files:
cam/scsi/scsi_cd.c
cam/scsi/scsi_da.c
dev/ata/ata-all.c
fs/pseudofs/pseudofs_vncache.c
fs/umapfs/umap_vfsops.c
kern/kern_ktrace.c
kern/kern_linker.c
ufs/ufs/ufs_vnops.c
I would appreciate if the respective owners, authors, maintainers
etc would review and commit their own bits from this patch.
Thanks in advance!
Poul-Henning
Index: cam/scsi/scsi_cd.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v
retrieving revision 1.61
diff -u -r1.61 scsi_cd.c
--- cam/scsi/scsi_cd.c 28 Sep 2002 17:14:05 - 1.61
+++ cam/scsi/scsi_cd.c 30 Sep 2002 06:11:54 -
@@ -1463,6 +1463,7 @@
start_ccb-ccb_h.ccb_bp = NULL;
start_ccb-ccb_h.ccb_state = CD_CCB_PROBE;
xpt_action(start_ccb);
+ /* XXX missing free(rcap, M_TEMP) ??? */
break;
}
}
Index: cam/scsi/scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.108
diff -u -r1.108 scsi_da.c
--- cam/scsi/scsi_da.c 20 Sep 2002 19:35:52 - 1.108
+++ cam/scsi/scsi_da.c 30 Sep 2002 06:13:35 -
@@ -1249,6 +1249,7 @@
start_ccb-ccb_h.ccb_bp = NULL;
start_ccb-ccb_h.ccb_state = DA_CCB_PROBE;
xpt_action(start_ccb);
+ /* XXX missing free(rcap, M_TEMP) ?? */
break;
}
}
Index: dev/ata/ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.154
diff -u -r1.154 ata-all.c
--- dev/ata/ata-all.c 12 Sep 2002 14:32:33 - 1.154
+++ dev/ata/ata-all.c 30 Sep 2002 06:19:11 -
@@ -454,8 +454,10 @@
if (iocmd-u.atapi.flags ATAPI_CMD_WRITE) {
error = copyin(iocmd-u.atapi.data, buf, iocmd-u.atapi.count);
- if (error)
+ if (error) {
+ free(buf, M_ATA);
return error;
+ }
}
error = atapi_queue_cmd(atadev, iocmd-u.atapi.ccb,
buf, iocmd-u.atapi.count,
Index: fs/pseudofs/pseudofs_vncache.c
===
RCS file: /home/ncvs/src/sys/fs/pseudofs/pseudofs_vncache.c,v
retrieving revision 1.17
diff -u -r1.17 pseudofs_vncache.c
--- fs/pseudofs/pseudofs_vncache.c 14 Sep 2002 09:02:24 - 1.17
+++ fs/pseudofs/pseudofs_vncache.c 30 Sep 2002 06:23:59 -
@@ -136,8 +136,10 @@
if (++pfs_vncache_entries pfs_vncache_maxentries)
pfs_vncache_maxentries = pfs_vncache_entries;
error = getnewvnode(pseudofs, mp, pfs_vnodeop_p, vpp);
- if (error)
+ if (error) {
+ FREE(pvd, M_PFSVNCACHE);
return (error);
+ }
pvd-pvd_pn = pn;
pvd-pvd_pid = pid;
(*vpp)-v_data = pvd;
Index: fs/umapfs/umap_vfsops.c
===
RCS file: /home/ncvs/src/sys/fs/umapfs/umap_vfsops.c,v
retrieving revision 1.46
diff -u -r1.46 umap_vfsops.c
--- fs/umapfs/umap_vfsops.c 4 Aug 2002 10:29:31 - 1.46
+++ fs/umapfs/umap_vfsops.c 30 Sep 2002 06:26:18 -
@@ -170,6 +170,8 @@
if (args.nentries MAPFILEENTRIES || args.gnentries
GMAPFILEENTRIES) {
vput(lowerrootvp);
+ free(amp, M_UMAPFSMNT);
+ /* XXX missing error = EINVAL ? */
return (error);
}
@@ -177,8 +179,10 @@
amp-info_gnentries = args.gnentries;
error = copyin(args.mapdata, (caddr_t)amp-info_mapdata,
2*sizeof(u_long)*args.nentries);
- if (error)
+ if (error) {
+ free(amp, M_UMAPFSMNT);
return (error);
+ }
#ifdef DEBUG
printf(umap_mount:nentries %d\n,args.nentries);
@@ -189,8 +193,10 @@
error = copyin(args.gmapdata, (caddr_t)amp-info_gmapdata,
2*sizeof(u_long)*args.gnentries);
- if (error)
+ if (error) {
+ free(amp, M_UMAPFSMNT);
return (error);
+ }
#ifdef DEBUG
printf(umap_mount:gnentries %d\n,args.gnentries);
Index: kern/kern_ktrace.c
===
RCS file: /home/ncvs/src/sys/kern/kern_ktrace.c,v
retrieving revision 1.77
diff -u -r1.77 kern_ktrace.c
--- kern/kern_ktrace.c 11 Sep 2002 21:00:56 - 1.77
+++ kern/kern_ktrace.c 30 Sep 2002 06:35:00 -
@@ -325,8 +325,11 @@
bcopy(args, buf,
Re: XFree86 crash, Bezier thing (was Re: Is phk rewriting the kernel over the weekend?)
On Sun, Sep 29, 2002 at 12:17:54PM -0700, Eric Anholt wrote: On Sun, 2002-09-29 at 10:25, Wesley Morgan wrote: Does this bug effect -stable? It only showed up in -current recently. Isn't it a bigger chance that something on the FreeBSD side made this bug much more visible? On Sun, 29 Sep 2002, Maxim Sobolev wrote: I think it should be fixed in FreeBSD ports before 4.7, because it is really annoying when server crashes without any particular reason. Eric, what do you think about it? -Maxim From what I had heard on the lists it was only a thing that happened when people upgraded kernels, and that it had stopped after some date of kernel. I hadn't experienced it, so I ignored it. I don't know about that link posted, I thought that was a mozilla bug that was supposed to be fixed. I don't think that it is related to kernel (what kernel has to do with Type1 font renderer in X server???). I'm seeing this problem when trying to open MS Word document in AbiWord, perhaps a bug in AbiWord itself, but IMO no application should be able to crash the server, so that we need to fix it ASAP. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: R e: VFS panic is now fixed.
if i can help, please let me know! all im doing is: newfs /dev/ad0s2a mount /dev/ad0s2a /mnt-root rsh dev -n dump 0f - /c/4 | restore rf - and after a short while it panics. with today's cvsup, and with this 'fix': *** vfs_subr.c 2002/09/29 08:16:40 1.1 --- vfs_subr.c 2002/09/29 10:36:04 *** *** 877,883 s = splbio(); mtx_lock(vnode_free_list_mtx); ! /* * Try to reuse vnodes if we hit the max. This situation only * occurs in certain large-memory (2G+) situations. We cannot --- 877,883 s = splbio(); mtx_lock(vnode_free_list_mtx); ! vnmp = 0; /* * Try to reuse vnodes if we hit the max. This situation only * occurs in certain large-memory (2G+) situations. We cannot im now getting a differnet panic :-) lock order reversal 1st 0xc058fd20 vnode_free_list (vnode_free_list) @ /r+d/5.0/src/sys/kern/vfs_subr.c:879 2nd 0xc26653d8 process lock (process lock) @ /r+d/5.0/src/sys/i386/i386/trap.c :731 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x48 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03268d6 stack pointer = 0x10:0xcc8287e0 frame pointer = 0x10:0xcc82882c 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 = 267 (restore) kernel: type 12 trap, code=0 Stopped at getnewvnode+0xc6: cmpl$0,0x48(%ebx) db trace getnewvnode(c04d18c9,c25d3a00,c2301700,cc828884,c757d0ae) at getnewvnode+0xc6 ffs_vget(c25d3a00,8cdd,2,cc8288f4,8180) at ffs_vget+0x93 ffs_valloc(c2a04de0,8180,c2741400,cc8288f4,cc8288f8) at ffs_valloc+0x100 ufs_makeinode(8180,c2a04de0,cc828bec,cc828c00,602) at ufs_makeinode+0x69 ufs_create(cc828a48,cc828a68,c0334919,cc828a48,c04e7780) at ufs_create+0x39 ufs_vnoperate(cc828a48,c04e7780,c2a04de0,cc828bec,cc828c00) at ufs_vnoperate+0x18 VOP_CREATE(c2a04de0,cc828bec,cc828c00,cc828aac,2) at VOP_CREATE+0x39 vn_open_cred(cc828bd8,cc828cd8,180,c2741400,cc828cc4) at vn_open_cred+0x179 vn_open(cc828bd8,cc828cd8,180,28f,c056a5c0) at vn_open+0x29 kern_open(c22a1480,80b32d3,0,602,1b6) at kern_open+0x183 open(c22a1480,cc828d10,c04de480,418,3) at open+0x30 syscall(2f,2f,2f,80b32d3,0) at syscall+0x2be Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x8054953, esp = 0xbfbff41c, ebp = 0xbfbff468 --- db To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Sep 30 03:15:08 PDT 2002 -- Kernel build for GENERIC completed on Mon Sep 30 03:41:41 PDT 2002 -- Kernel build for LINT started on Mon Sep 30 03:41:41 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
scd, mcd, matcd lovers/maintainers please ?
Last call: Unless somebody with access to this hardware and willing to maintain these drivers step forward Real Soon Now, I intend to retire them from -current before 5.0-R. Poul-Henning --- Forwarded Message From: Poul-Henning Kamp [EMAIL PROTECTED] Date: Mon, 30 Sep 2002 06:49:20 -0700 (PDT) To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/i386/isa mcd.c scd.c src/sys/i386/isa/matcd matcd.c phk 2002/09/30 06:49:20 PDT Modified files: sys/i386/isa mcd.c scd.c sys/i386/isa/matcd matcd.c Log: If GEOM is in the kernel, take these three out. I have no way of testing any modifications to them, they shouldn't even bother with disklabels in the first place and they are just plain obsolete old hardware which should be axed entirely before 5.0-R IMO. Sponsored by: DARPA NAI Labs. Revision ChangesPath 1.60 +3 -0 src/sys/i386/isa/matcd/matcd.c 1.126 +3 -0 src/sys/i386/isa/mcd.c 1.67 +3 -0 src/sys/i386/isa/scd.c --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: scd, mcd, matcd lovers/maintainers please ?
On Mon, Sep 30, 2002 at 04:05:40PM +0200, Poul-Henning Kamp wrote: Unless somebody with access to this hardware and willing to maintain these drivers step forward Real Soon Now, I intend to retire them from -current before 5.0-R. For a possible maintainer for the mcd driver i have at least 2 Mitsumi drives + ISA controllers + documentation in good working condition which i am willing to ship for this purpose to anywhere on earth. hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: lockmgr: locking against myself
Hi! While local package initilization I get a panic. World and kernel from today. This I found in messages: Sep 30 15:49:55 leeloo kernel: panic: lockmgr: locking against myself Sep 30 15:49:55 leeloo kernel: Sep 30 15:49:55 leeloo kernel: syncing disks... panic: bremfree: bp 0xd381a080 not locked Sep 30 15:49:55 leeloo kernel: Uptime: 26s Sep 30 15:49:55 leeloo kernel: pfs_vncache_unload(): 4 entries remaining Sep 30 15:49:55 leeloo kernel: Dumping 1535 MB Sep 30 15:49:55 leeloo kernel: ata0: resetting devices .. Sep 30 15:49:55 leeloo kernel: panic: bremfree: bp 0xd3886870 not locked Sep 30 15:49:55 leeloo kernel: Uptime: 26s Sep 30 15:49:55 leeloo kernel: pfs_vncache_unload(): 4 entries remaining Sep 30 15:49:55 leeloo kernel: panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not initialized The hand-written tr: panic: lockmgr: locking against myself lockmgr vm_map_lookup vm_pfault trap_pfault(18,10,10,0,2e) call trap Please let me know if (and how) I could provide more info. Marc msg43608/pgp0.pgp Description: PGP signature
Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation
Hi,
Index: sys/i386/i386/machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.532
diff -u -r1.532 machdep.c
--- sys/i386/i386/machdep.c 7 Sep 2002 19:12:42 - 1.532
+++ sys/i386/i386/machdep.c 29 Sep 2002 21:15:26 -
@@ -1269,8 +1269,12 @@
/*
* Perform base memory related probes setup
*/
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ if (bootinfo.bi_basemem != 0) {
+ basemem = bootinfo.bi_basemem;
+ } else {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
if (basemem 640) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
basemem);
The kernel hasn't used bootinfo.bi_basemem for a long time and shouldn't
start using it again now. It already uses the 0x15/0xe820 call for
everything except basemem (except when the this call fails, it falls
back to 0x15/0xe801). Maybe the bug has something to do with the
kernel using the 0x12 call without checking whether the call succeeded.
When both the 0x15/0xe820 and the 0x15/0xe801 calls fail, the kernel
falls back to an 0x15/0x88 call for determining extmem ... except this
is ifdefed out and replaced by looking at the rtc values. Maybe the
unreliability of the 0x15/0x88 call has something to do with not
checking if the call succeeded.
Yes, I think the best way to determine base mem size in getmemsize()
is to try 0x15/0xe820 call first, then fall back to 0x12 call. But
I'm not sure whether it's OK to call vm86_datacall(0x15) before
determining base mem size...
The patch makes no difference for booting directly from boot2 ... except
memsize() in boot2 also fails to check for errors, so it returns garbage
values.
Yes I know that :-)
But booting kernel directly from boot2 is not working at all for
several years, so my understanding is that /boot/loader is necessary
to boot kernel.
I think the basemem == 0 case should just work, so the systems with a
broken INT 0x12 should at worst lose 640K of memory, no matter whether
basemem is set to 0 because INT 0x12 fails or because it actually
returns 0.
Hmmm, actually no. I know that some machines get panic with fatal trap
12 if we do 0x12 call. The worst case is getting panic, not losing
640K memory.
And it seems that today's Linux don't have 0x12 calling any more,
so I didn't see any problem on the machines.
Now I have some ideas on this issue;
- 0x15/0xe820 call in getmemsize() to determine base mem size. (But how?)
- 0x15/0xe820 call in locore.s before calling init386().
- specify the size by loader tunable (e.g. hw.basememsize).
Comments?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: Fatal trap 12
On 29-Sep-2002 Hanspeter Roth wrote: On Sep 29 at 12:25, Mitsuru IWASAKI spoke: If you think this is caused by acpi.ko, just disable acpi.ko loading. Please read thru loader(8) and device.hints(5). Yes, this is it. I've now disabled acpi and the boot process comes further. vga0: Generic ISA VGA at port 0x3c0-0x3df iomem ... unknown: PNP0401 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) ... Mounting root from ufs:/dev/ad0s3a Fatal trap 12: page fault while in kernal mode fault virtual address = ... ... current process = 1 (init) kernel: type 12 trap, code=0 Stopped atgeneric_bcopy+0x1a: repe movsl (%esi),%es:(%edi) db Context switches not allowd in the debugger. db These messages above that you left out are very important. :( Also, if you can get a trace by typing 't' at the db prompt that can be very helpful as well. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
installing DP1 via ftp
Hello, I've installed DP1 from CD. It doesn't like the Promise ATA100 TX2. `boot -c' just behaves exactly like normal boot and stops in the debugger. Thus I thought I could install via FTP. But what will I get? Will I get a `current' current? Or will I get DP1 from April again? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fatal trap 12
On Sep 30 at 11:59, John Baldwin spoke: These messages above that you left out are very important. :( Also, if you can get a trace by typing 't' at the db prompt that can be very helpful as well. Ok. I hope there aren't to many mistakes. vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa unknown: PNP0401 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) unknown: PNP0303 can't assign resources (port) unknown: PNP0c02 can't assign resources (port) Tiemcounters tick every 10.000 msec ad0: 76351MB SAMSUNG SP8004H [155127/16/63] at ata0-master UDMA100 acd0: CD-RW Memorex SixteenMAXX 1040 at ata1-master PIO4 acd1: CD-RW PLEXTOR CD-R PX-W4012A at ata2-master PIO4 acd2: CD-RW PLEXTOR CD-R PX-W4012A at ata3-master PIO4 acd3: CD-RW PLEXTOR CD-R PX-W4012A at ata4-master PIO4 acd4: CD-RW PLEXTOR CD-R PX-W4012A at ata5-master PIO4 Mounting root from ufs:/dev/ad0s3a Fatal trap 12: page fault while in kernal mode fault virtual address = 0xdeadc0de fault code = supervisor write, page not present instruction pointer = 0x8:0xc044d03e stack pointer = 0x10:0xcd214a94 frame pointer = 0x10:0xcd214c9a code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1 (init) kernel: type 12 trap, code=0 Stopped at generic_bcopy+0x1a: repe movsl (%esi),%es:(%edi) db Context switches not allowd in the debugger. db db trace generic_bcopy(c0f079c0,cd214cf0,0,0,cd214cd8) at generic_bcopy+0x1a start_init(0,cd214d48,c04b26b1,348,0) at start_init+0x45e fork_exit(c02b28b0,0,cd214d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0, eip = 0, esp = 0xcd214d7c, ebp = 0x2f --- db I have also attached a dmesg. I tought it would be one from Release. But it seems to be a concatenation of Current and Release... -Hanspeter Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #: Sat Sep 28 18:14:51 CEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc065f000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1160341146 Hz CPU: AMD Athlon(TM) XP 1800+ (1160.34-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! real memory = 268419072 (262128K bytes) avail memory = 253677568 (247732K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface Using $PIR table, 9 entries at 0xc00f1e30 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 agp0: SIS Generic host to PCI bridge mem 0xf000-0xf3ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 ohci0: SiS 5571 USB controller mem 0xef00-0xef000fff irq 9 at device 2.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SiS 5571 USB controller on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: SiS 5571 USB controller mem 0xee80-0xee800fff irq 9 at device 2.3 on pci0 usb1: OHCI version 1.0, legacy support usb1: SiS 5571 USB controller on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered atapci0: SiS 5591 ATA100 controller port 0xb800-0xb80f at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci1: Promise TX2 ATA100 controller port 0x8800-0x880f,0x9000-0x9003,0x9400-0x9407,0x9800-0x9803,0xa000-0xa007 mem 0xee00-0xee003fff irq 10 at device 9.0 on pci0 ata2: at 0xa000 on atapci1 ata3: at 0x9400 on atapci1 pci0: multimedia, audio at device 10.0 (no driver attached) rl0: RealTek 8139 10/100BaseTX port 0x8000-0x80ff mem 0xed80-0xed8000ff irq 9 at device 11.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode /usr/src/sys/vm/uma_core.c:1307: could sleep with rl0 locked from /usr/src/sys/pci/if_rl.c:872 rl0: Ethernet address: 00:02:44:67:ad:1b miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto /usr/src/sys/vm/uma_core.c:1307: could sleep with rl0 locked from /usr/src/sys/pci/if_rl.c:597 atapci2: Promise TX2 ATA133
Re: PATCH: various memory leaks.
On Mon, 30 Sep 2002, Poul-Henning Kamp wrote: I went through the FlexeLint output of the LINT kernel on i386 and tried to examine all warnings about memoryleaks in central or semi-central code. I this patch I belive addresses the ones I think I could confirm, in the following files: cam/scsi/scsi_cd.c cam/scsi/scsi_da.c dev/ata/ata-all.c fs/pseudofs/pseudofs_vncache.c fs/umapfs/umap_vfsops.c kern/kern_ktrace.c kern/kern_linker.c ufs/ufs/ufs_vnops.c I would appreciate if the respective owners, authors, maintainers etc would review and commit their own bits from this patch. Thanks in advance! Poul-Henning Index: cam/scsi/scsi_cd.c === RCS file: /home/ncvs/src/sys/cam/scsi/scsi_cd.c,v retrieving revision 1.61 diff -u -r1.61 scsi_cd.c --- cam/scsi/scsi_cd.c28 Sep 2002 17:14:05 - 1.61 +++ cam/scsi/scsi_cd.c30 Sep 2002 06:11:54 - @@ -1463,6 +1463,7 @@ start_ccb-ccb_h.ccb_bp = NULL; start_ccb-ccb_h.ccb_state = CD_CCB_PROBE; xpt_action(start_ccb); + /* XXX missing free(rcap, M_TEMP) ??? */ break; } } Index: cam/scsi/scsi_da.c === RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v retrieving revision 1.108 diff -u -r1.108 scsi_da.c --- cam/scsi/scsi_da.c20 Sep 2002 19:35:52 - 1.108 +++ cam/scsi/scsi_da.c30 Sep 2002 06:13:35 - @@ -1249,6 +1249,7 @@ start_ccb-ccb_h.ccb_bp = NULL; start_ccb-ccb_h.ccb_state = DA_CCB_PROBE; xpt_action(start_ccb); + /* XXX missing free(rcap, M_TEMP) ?? */ break; } } Thanks for working on cleaning things up. The SCSI ones are wrong. The rcap is attached to csio-data_ptr and is unconditionally freed in the completion routine, cddone() (see the CD_CCB_PROBE case there). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADSUP! GEOM as default in 5 days...
Provided nothing terminal pops up in the next 5 days, GEOM will become default in -current on Saturday 5th of october. Please test it now on _your_ configuration and tell me if it fails to work. There is one known issue on sparc64 which is being worked: On sparc64 nexus_dmamap_create() calls malloc with M_WAITOK which it shouldn't. Change it to M_NOWAIT if you run into this problem before it gets officially fixed. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fatal trap 12
On 30-Sep-2002 Hanspeter Roth wrote:
On Sep 30 at 11:59, John Baldwin spoke:
These messages above that you left out are very important. :(
Also, if you can get a trace by typing 't' at the db prompt
that can be very helpful as well.
Ok. I hope there aren't to many mistakes.
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa
unknown: PNP0401 can't assign resources (port)
unknown: PNP0501 can't assign resources (port)
unknown: PNP0501 can't assign resources (port)
unknown: PNP0700 can't assign resources (port)
unknown: PNP0f13 can't assign resources (irq)
unknown: PNP0303 can't assign resources (port)
unknown: PNP0c02 can't assign resources (port)
Tiemcounters tick every 10.000 msec
ad0: 76351MB SAMSUNG SP8004H [155127/16/63] at ata0-master UDMA100
acd0: CD-RW Memorex SixteenMAXX 1040 at ata1-master PIO4
acd1: CD-RW PLEXTOR CD-R PX-W4012A at ata2-master PIO4
acd2: CD-RW PLEXTOR CD-R PX-W4012A at ata3-master PIO4
acd3: CD-RW PLEXTOR CD-R PX-W4012A at ata4-master PIO4
acd4: CD-RW PLEXTOR CD-R PX-W4012A at ata5-master PIO4
Mounting root from ufs:/dev/ad0s3a
Fatal trap 12: page fault while in kernal mode
fault virtual address = 0xdeadc0de
This means someone is trying to access memory that has been free'd.
fault code= supervisor write, page not present
instruction pointer = 0x8:0xc044d03e
stack pointer = 0x10:0xcd214a94
frame pointer = 0x10:0xcd214c9a
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 1 (init)
kernel: type 12 trap, code=0
Stopped atgeneric_bcopy+0x1a: repe movsl (%esi),%es:(%edi)
db Context switches not allowd in the debugger.
db
db trace
generic_bcopy(c0f079c0,cd214cf0,0,0,cd214cd8) at generic_bcopy+0x1a
start_init(0,cd214d48,c04b26b1,348,0) at start_init+0x45e
This is:
(kgdb) l *start_init+0x45e
0xc02448de is in start_init (../../../kern/init_main.c:663).
663 if ((error = execve(td, args)) == 0) {
Hmm, unfortunately generic_bcopy() is in asm, and so it doesn't have
a true frame and we end up skipping over the frame in execve()
where it is called from. There are only 3 bcopy's in execve(), but
I'm not sure which is likely to have been the problematic one.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Fatal trap 12
On Sep 30 at 15:16, John Baldwin spoke: Fatal trap 12: page fault while in kernal mode fault virtual address = 0xdeadc0de This means someone is trying to access memory that has been free'd. How do I make someone not to do such bad things? :-) Hmm, unfortunately generic_bcopy() is in asm, and so it doesn't have a true frame and we end up skipping over the frame in execve() where it is called from. There are only 3 bcopy's in execve(), but I'm not sure which is likely to have been the problematic one. Did I smash upgrade? Or doesn't Current just like my hardware? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: installing DP1 via ftp
On Sep 30 at 19:40, Hanspeter Roth spoke: Thus I thought I could install via FTP. But what will I get? Will I get a `current' current? Or will I get DP1 from April again? I've interrupted after /bin has been downloaded. And what do I see? mnt/bin # ll total 7810 -r-xr-xr-x 2 root wheel 70376 Apr 7 01:44 [ -r-xr-xr-x 1 root wheel 70952 Apr 7 01:44 cat -r-xr-xr-x 1 root wheel 69336 Apr 7 01:45 chflags -r-xr-xr-x 1 root wheel 64484 Apr 7 01:44 chio It seems to be DP1 from April. -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
On Mon, Sep 30, 2002 at 09:09:46PM +0200, Poul-Henning Kamp wrote: Provided nothing terminal pops up in the next 5 days, GEOM will become default in -current on Saturday 5th of october. Please test it now on _your_ configuration and tell me if it fails to work. What are the exact steps you will take to make it the default; that we should test now? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
In message [EMAIL PROTECTED], David O'Brien writes: On Mon, Sep 30, 2002 at 09:09:46PM +0200, Poul-Henning Kamp wrote: Provided nothing terminal pops up in the next 5 days, GEOM will become default in -current on Saturday 5th of october. Please test it now on _your_ configuration and tell me if it fails to work. What are the exact steps you will take to make it the default; that we should test now? for i in src/sys/*/conf/GENERIC do echo options GEOM $i done cvs commit src/sys/*/conf/GENERIC -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fatal trap 12
On 30-Sep-2002 Hanspeter Roth wrote: On Sep 30 at 15:16, John Baldwin spoke: Fatal trap 12: page fault while in kernal mode fault virtual address = 0xdeadc0de This means someone is trying to access memory that has been free'd. How do I make someone not to do such bad things? :-) Hmm, unfortunately generic_bcopy() is in asm, and so it doesn't have a true frame and we end up skipping over the frame in execve() where it is called from. There are only 3 bcopy's in execve(), but I'm not sure which is likely to have been the problematic one. Did I smash upgrade? Or doesn't Current just like my hardware? It's not hardware related I don't believe. You can try putting some printf's into the execve() function before each bcopy() to see which one blows up. -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/alpha/osf1 osf1_signal.c src/sys/compat/linprocfs linprocfs.c src/sys/compat/linux linux_misc.c linux_signal.c src/sys/compat/svr4 svr4_filio.c svr4_signal.c src/sys/conf files src/sys/fs/procfs procfs_ctl.c src/sys/kern init_main.c ...
Any problems that one runs into, or things that go boom, or questions should be directed to me. I've been running almost the exact same stuff under OpenBSD and FreeBSD (with the notable exception that some things were unworking in OpenBSD due to relied-upon breakage) both -current and -stable FreeBSD for more or less a month, though admittedly the rewrite to use this subr_sigq.c was based on comments from BDE over this weekend about the macro approach I took, though the logic should be exactly the same. juli. * De: Juli Mallett [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: cvs commit: src/sys/alpha/osf1 osf1_signal.c src/sys/compat/linprocfs linprocfs.c src/sys/compat/linux linux_misc.c linux_signal.c src/sys/compat/svr4 svr4_filio.c svr4_signal.c s jmallett2002/09/30 13:20:22 PDT Modified files: sys/alpha/osf1 osf1_signal.c sys/compat/linprocfs linprocfs.c sys/compat/linux linux_misc.c linux_signal.c sys/compat/svr4 svr4_filio.c svr4_signal.c sys/conf files sys/fs/procfsprocfs_ctl.c sys/kern init_main.c kern_exit.c kern_fork.c kern_kthread.c kern_proc.c kern_sig.c subr_trap.c tty.c sys/sys proc.h Added files: sys/kern subr_sigq.c sys/sys ksiginfo.h Log: First half of implementation of ksiginfo, signal queues, and such. This gets signals operating based on a TailQ, and is good enough to run X11, GNOME, and do job control. There are some intricate parts which could be more refined to match the sigset_t versions, but those require further evaluation of directions in which our signal system can expand and contract to fit our needs. After this has been in the tree for a while, I will make in kernel API changes, most notably to trapsignal(9) and sendsig(9), to use ksiginfo more robustly, such that we can actually pass information with our (queued) signals to the userland. That will also result in using a struct ksiginfo pointer, rather than a signal number, in a lot of kern_sig.c, to refer to an individual pending signal queue member, but right now there is no defined behaviour for such. CODAFS is unfinished in this regard because the logic is unclear in some places. Sponsored by: New Gold Technology Reviewed by:bde, tjr, jake [an older version, logic similar] Revision ChangesPath 1.20 +2 -1 src/sys/alpha/osf1/osf1_signal.c 1.56 +1 -1 src/sys/compat/linprocfs/linprocfs.c 1.131 +2 -1 src/sys/compat/linux/linux_misc.c 1.36 +2 -1 src/sys/compat/linux/linux_signal.c 1.17 +3 -0 src/sys/compat/svr4/svr4_filio.c 1.19 +1 -1 src/sys/compat/svr4/svr4_signal.c 1.707 +1 -0 src/sys/conf/files 1.45 +2 -1 src/sys/fs/procfs/procfs_ctl.c 1.208 +2 -0 src/sys/kern/init_main.c 1.178 +8 -1 src/sys/kern/kern_exit.c 1.165 +1 -0 src/sys/kern/kern_fork.c 1.25 +9 -8 src/sys/kern/kern_kthread.c 1.155 +3 -2 src/sys/kern/kern_proc.c 1.192 +36 -28src/sys/kern/kern_sig.c 1.1 +301 -0src/sys/kern/subr_sigq.c (new) 1.224 +3 -1 src/sys/kern/subr_trap.c 1.186 +9 -5 src/sys/kern/tty.c 1.1 +78 -0 src/sys/sys/ksiginfo.h (new) 1.261 +1 -1 src/sys/sys/proc.h -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fatal trap 12
On Sep 30 at 15:16, John Baldwin spoke: Hmm, unfortunately generic_bcopy() is in asm, and so it doesn't have a true frame and we end up skipping over the frame in execve() where it is called from. There are only 3 bcopy's in execve(), but I'm not sure which is likely to have been the problematic one. Mounting root from ufs:/dev/ad0s3a calling bcopy 416 bcopy 416 returned calling bcopy 556 Fatal trap 12: ... 416 and 556 denote linenumbers in kern_exec.c. -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: installing DP1 via ftp
On Mon, Sep 30, 2002 at 09:45:39PM +0200, Hanspeter Roth wrote: On Sep 30 at 19:40, Hanspeter Roth spoke: Thus I thought I could install via FTP. But what will I get? Will I get a `current' current? Or will I get DP1 from April again? I've interrupted after /bin has been downloaded. And what do I see? sysinstall, by default, will install the version it was built for. You can change this by manually specifying a different URL/path to the release bits, or you can just download new installation media from the desired snapshot (this is the preferred option) and use that to install with. Kris msg43623/pgp0.pgp Description: PGP signature
Longer term fix for sigreturn ABI breaking
At the end is a potentially longer term fix for the ABI
breakage that was introduced when the i386 mcontext_t
was changed/enlarged.
Someone other than I (Bruce?) should vet this. It should
solve the libc_r binary compatibility problem, but it may
not fix everything. Applications that copy ucontext_t's
around (without changing corrupting the mc_fpformat field)
will still break, but there may not be many (if any) of
those.
--
Dan Eischen
Index: i386/i386/machdep.c
===
RCS file: /opt/d/CVS/src/sys/i386/i386/machdep.c,v
retrieving revision 1.539
diff -u -r1.539 machdep.c
--- i386/i386/machdep.c 30 Sep 2002 07:02:22 - 1.539
+++ i386/i386/machdep.c 30 Sep 2002 20:42:30 -
@@ -680,7 +680,7 @@
struct proc *p = td-td_proc;
struct trapframe *regs;
const ucontext_t *ucp;
- int cs, eflags, error, ret;
+ int cs, eflags, error;
error = copyin(uap-sigcntxp, uc, sizeof(uc));
if (error != 0)
@@ -754,9 +754,15 @@
return (EINVAL);
}
- ret = set_fpcontext(td, ucp-uc_mcontext);
- if (ret != 0)
- return (ret);
+ /*
+* Intentionally ignore the error to keep binary
+* compatibility with applications that fiddle with
+* the FPU save area in the context. The kernel
+* now saves the FPU state in the context, but it
+* gets corrupted by those applications that try
+* to work around the kernel NOT saving it.
+*/
+ (void)set_fpcontext(td, ucp-uc_mcontext);
bcopy(ucp-uc_mcontext.mc_fs, regs, sizeof(*regs));
}
@@ -2109,7 +2115,7 @@
* Set machine context.
*
* However, we don't set any but the user modifyable flags, and
- * we we won't touch the cs selector.
+ * we won't touch the cs selector.
*/
int
set_mcontext(struct thread *td, const mcontext_t *mcp)
@@ -2147,10 +2153,6 @@
static void
get_fpcontext(struct thread *td, mcontext_t *mcp)
{
-#if 1 /* XXX: tmp hack to restore ability to run releng4 binaries */
- /* For now, always store the FP state in the PCB. */
- (void)npxgetregs(td, (union savefpu *)td-td_pcb-pcb_save);
-#else
#ifndef DEV_NPX
mcp-mc_fpformat = _MC_FPFMT_NODEV;
mcp-mc_ownedfp = _MC_FPOWNED_NONE;
@@ -2186,16 +2188,11 @@
}
mcp-mc_fpformat = npxformat();
#endif
-#endif /* tmp hack to restore ability to run releng4 binaries */
}
static int
set_fpcontext(struct thread *td, const mcontext_t *mcp)
{
-#if 1 /* XXX: tmp hack to restore ability to run releng4 binaries */
- /* For now, the FP state is always stored in the PCB. */
- npxsetregs(td, (union savefpu *)td-td_pcb-pcb_save);
-#else
union savefpu *addr;
if (mcp-mc_fpformat == _MC_FPFMT_NODEV)
@@ -2234,7 +2231,6 @@
*/
} else
return (EINVAL);
-#endif /* tmp hack to restore ability to run releng4 binaries */
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Fatal trap 12
On 30-Sep-2002 Hanspeter Roth wrote:
On Sep 30 at 15:16, John Baldwin spoke:
Hmm, unfortunately generic_bcopy() is in asm, and so it doesn't have
a true frame and we end up skipping over the frame in execve()
where it is called from. There are only 3 bcopy's in execve(), but
I'm not sure which is likely to have been the problematic one.
Mounting root from ufs:/dev/ad0s3a
calling bcopy 416
bcopy 416 returned
calling bcopy 556
Fatal trap 12: ...
416 and 556 denote linenumbers in kern_exec.c.
Thanks! That's here:
if (ps_arg_cache_limit = i + sizeof(struct pargs)) {
bcopy(imgp-stringbase, newargs-ar_args, i);
p-p_args = newargs;
newargs = NULL;
}
BTW, is this on DP1?
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: installing DP1 via ftp
On Sep 30 at 14:16, Kris Kennaway spoke: release bits, or you can just download new installation media from the desired snapshot (this is the preferred option) and use that to install with. I can only see /pub/FreeBSD/snapshots/i386/5.0-20020302-PREVIEW. Is there a more recent snapshot? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fatal trap 12
On Sep 30 at 17:19, John Baldwin spoke:
On 30-Sep-2002 Hanspeter Roth wrote:
416 and 556 denote linenumbers in kern_exec.c.
Thanks! That's here:
if (ps_arg_cache_limit = i + sizeof(struct pargs)) {
bcopy(imgp-stringbase, newargs-ar_args, i);
p-p_args = newargs;
newargs = NULL;
}
Yes.
BTW, is this on DP1?
No. This one is an attempt to upgrade from 4-Stable.
(I'm trying to find out which approach is less painful. Thus I also
tried the DP1 image on a different slice.)
-Hanspeter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Sep 30 15:19:30 PDT 2002 -- Kernel build for GENERIC completed on Mon Sep 30 15:49:55 PDT 2002 -- Kernel build for LINT started on Mon Sep 30 15:49:55 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Longer term fix for sigreturn ABI breaking
Daniel Eischen wrote: At the end is a potentially longer term fix for the ABI breakage that was introduced when the i386 mcontext_t was changed/enlarged. - ret = set_fpcontext(td, ucp-uc_mcontext); - if (ret != 0) - return (ret); + /* + * Intentionally ignore the error to keep binary + * compatibility with applications that fiddle with + * the FPU save area in the context. The kernel + * now saves the FPU state in the context, but it + * gets corrupted by those applications that try + * to work around the kernel NOT saving it. + */ + (void)set_fpcontext(td, ucp-uc_mcontext); Maybe we could have something like this instead? ret = set_fpcontext(td, ucp-uc_mcontext); #if !defined(COMPAT_FREEBSD4) !defined(COMPAT_43) if (ret != 0) return (ret); #endif ie: ignore the error only if we have to be compatable. Longer term, I was thining that we could/should do what sparc64 does, ie: libc provides the trampoline and it can then call the correct sigreturn syscall. That means we add a new sigreturn syscall each time we significantly break the sigreturn ABI (as in this case) and applications will be able to use the correct one. Paired with a new sigaction syscall which would specify the new context format we can then be future proof. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: signal changes
On Mon, 30 Sep 2002, Juli Mallett wrote: * De: Julian Elischer [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: Re: signal changes ] On Mon, 30 Sep 2002, Juli Mallett wrote: What limits are the on the number of signals that are stored? It's a TailQ. Surely there is a limit or it would be a DOS candidate. What kind of limit would you like? I can't afford the relevant standards or I'd check to see if there was a standard one. I could add a sysctl tunable? I don't know what standard would be relevant.. what standard would specify how many signals you could stack up? -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: signal changes
* De: Julian Elischer [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: Re: signal changes ] On Mon, 30 Sep 2002, Juli Mallett wrote: * De: Julian Elischer [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: Re: signal changes ] On Mon, 30 Sep 2002, Juli Mallett wrote: What limits are the on the number of signals that are stored? It's a TailQ. Surely there is a limit or it would be a DOS candidate. What kind of limit would you like? I can't afford the relevant standards or I'd check to see if there was a standard one. I could add a sysctl tunable? I don't know what standard would be relevant.. what standard would specify how many signals you could stack up? Teh same that provides specification for queued signals - posix rts. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: installing DP1 via ftp
On Mon, Sep 30, 2002 at 11:26:50PM +0200, Hanspeter Roth wrote: On Sep 30 at 14:16, Kris Kennaway spoke: release bits, or you can just download new installation media from the desired snapshot (this is the preferred option) and use that to install with. I can only see /pub/FreeBSD/snapshots/i386/5.0-20020302-PREVIEW. Is there a more recent snapshot? ftp://current.freebsd.org builds daily snapshots. Kris msg43632/pgp0.pgp Description: PGP signature
world breakage?
cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/dell/imp/p4/newcard/src/lib/libkvm -c /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /dell/imp/p4/newcard/src/lib/libkvm/kvm_proc.c:201: structure has no member named `p_siglist' *** Error code 1 Look familiar? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
World broken at libkvm
cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /usr/src/lib/libkvm/kvm_proc.c:201: structure has no member named `p_siglist' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: signal changes
On Mon, 30 Sep 2002, Juli Mallett wrote: Teh same that provides specification for queued signals - posix rts. hey that's MY typo... get your own! :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World broken at libkvm
In message: [EMAIL PROTECTED] walt [EMAIL PROTECTED] writes: : cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c : /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o : /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': : /usr/src/lib/libkvm/kvm_proc.c:201: structure has no member named `p_siglist' This has been fixed. But there's other breakages in the kernel that are being worked on. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World broken at libkvm
* De: M. Warner Losh [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: Re: World broken at libkvm ] In message: [EMAIL PROTECTED] walt [EMAIL PROTECTED] writes: : cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c : /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o : /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': : /usr/src/lib/libkvm/kvm_proc.c:201: structure has no member named `p_siglist' This has been fixed. But there's other breakages in the kernel that are being worked on. And now fixed. All we have to look out for now is someone doing something that exposes some sort of functional difference, but I don't anticipate it. Thanks for the patience. juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World broken at libkvm
Juli Mallett wrote: * De: M. Warner Losh [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: Re: World broken at libkvm ] In message: [EMAIL PROTECTED] walt [EMAIL PROTECTED] writes: : cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c : /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o : /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': : /usr/src/lib/libkvm/kvm_proc.c:201: structure has no member named `p_sigl ist' This has been fixed. But there's other breakages in the kernel that are being worked on. And now fixed. All we have to look out for now is someone doing something that exposes some sort of functional difference, but I don't anticipate it. Have you dealt with the 'could sleep' stuff with witness turned on? These are *guaranteed* panics if the system is low on memory at that given instant. (Witness doesn't cause the problems, it reports fundamental problems that are already there. The system will panic regardless of whether witness is there or not.) I suggest you turn WITNESS on, and stress the system. If you get *new* 'could sleep' stuff or other lock order problems, then there are still significant regressions to be fixed. The last thing we need during the 'please stabilize 5.0' drive is newly added problems. If other folks are seeing new ones, please report them here (not to me, I already get too much email :-]). Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World broken at libkvm
Juli Mallett wrote: * De: M. Warner Losh [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: Re: World broken at libkvm ] This has been fixed. But there's other breakages in the kernel that are being worked on. And now fixed. All we have to look out for now is someone doing something that exposes some sort of functional difference, but I don't anticipate it. World and kernel now compile fine for me. No crashes yet (5 min uptime :-) -- Does this mean you've found full-time employment? ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World broken at libkvm
* De: Peter Wemm [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: Re: World broken at libkvm ] Juli Mallett wrote: * De: M. Warner Losh [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: Re: World broken at libkvm ] In message: [EMAIL PROTECTED] walt [EMAIL PROTECTED] writes: : cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c : /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o : /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': : /usr/src/lib/libkvm/kvm_proc.c:201: structure has no member named `p_sigl ist' This has been fixed. But there's other breakages in the kernel that are being worked on. And now fixed. All we have to look out for now is someone doing something that exposes some sort of functional difference, but I don't anticipate it. Have you dealt with the 'could sleep' stuff with witness turned on? These are *guaranteed* panics if the system is low on memory at that given instant. (Witness doesn't cause the problems, it reports fundamental problems that are already there. The system will panic regardless of whether witness is there or not.) I suggest you turn WITNESS on, and stress the system. If you get *new* 'could sleep' stuff or other lock order problems, then there are still significant regressions to be fixed. The last thing we need during the 'please stabilize 5.0' drive is newly added problems. If other folks are seeing new ones, please report them here (not to me, I already get too much email :-]). It looks like I'll probably be forced to look at backing this out tomorrow, if only for the lock issues. The problem is that sending signals is done with lots of locks held at the time. I'm going to try to clean that up independent of this, once it's sorted, I'll give -arch a holler about this, but for now it should be safe for anyone who wants to to run these patches locally, if they get anything out of it other than a perverse kick. juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
In article [EMAIL PROTECTED] Takahashi Yoshihiro [EMAIL PROTECTED] writes: In article [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: Provided nothing terminal pops up in the next 5 days, GEOM will become default in -current on Saturday 5th of october. Please test it now on _your_ configuration and tell me if it fails to work. It fails to compile a GENERIC kernel for pc98 with GEOM option. And also recent kernel for pc98 without GEOM option cannot mount root filesystem. I got the following error messages. - Mounting root from ufs:/dev/wd0s1a wd0s1: mid 0x94, start 0, end = 4294967295, size 0: OK wd0c: cannot find label (I/O error) wd0s1: cannnot find label (I/O error) Root mount failed: 22 - - Mounting root from ufs:/dev/da0s1a da0c: cannot find label (I/O error) da0s1: cannot find label (I/O error) Root mount failed: 22 - --- TAKAHASHI Yoshihiro [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lightweight interrupt threads
I was talking to someone about lightweight interrupt threads and interactions with KSEs and specifically about KSE borrowing.. Believe it or not, I can't remember who it was.. if it was you, let me know :-) Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lightweight interrupt threads
Dunno who it was, but my understanding is that we already actually use lightweight interrupt threads on sparc64, so you might want to peruse there and look at the approach taken. :-) You might have been talking to Bosko (possibly at USENIX ATC), as he was maintaining an i386 lightweight interrupt thread implementation (although I think it got fairly hosed over time due to a lot of changes in the main tree). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Mon, 30 Sep 2002, Julian Elischer wrote: I was talking to someone about lightweight interrupt threads and interactions with KSEs and specifically about KSE borrowing.. Believe it or not, I can't remember who it was.. if it was you, let me know :-) Julian 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
Re: World broken at libkvm
* De: Don Lewis [EMAIL PROTECTED] [ Data: 2002-09-30 ] [ Subjecte: Re: World broken at libkvm ] On 30 Sep, Peter Wemm wrote: Juli Mallett wrote: And now fixed. All we have to look out for now is someone doing something that exposes some sort of functional difference, but I don't anticipate it. I suggest you turn WITNESS on, and stress the system. If you get *new* 'could sleep' stuff or other lock order problems, then there are still significant regressions to be fixed. The last thing we need during the 'please stabilize 5.0' drive is newly added problems. If other folks are seeing new ones, please report them here (not to me, I already get too much email :-]). I suggest looking especially closely at the sigio stuff. Even the old code has a lock order reversal problem when I/O to a pipe wants to signal the process at the other end of the pipe. I thought a lot about that problem and never found a clean fix. The sigio stuff could be even nastier if you need to allocate memory in the signal code because the sigio can be invoked by the reception of a packet from the network, which is not handled in a process context ... No locks except for the lock of the process being signalled should be held when sending signals, IMHO, though I am mostly ignorant of the SIGIO locking. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lightweight interrupt threads
Apparently, On Tue, Oct 01, 2002 at 01:46:50AM -0400, Robert Watson said words to the effect of; Dunno who it was, but my understanding is that we already actually use lightweight interrupt threads on sparc64, so you might want to peruse there and look at the approach taken. :-) You might have been talking to Not yet :) Its in my perforce tree still; still some issues to resolve. I remember Bosko mentioning this though (kse loaning). Jake Bosko (possibly at USENIX ATC), as he was maintaining an i386 lightweight interrupt thread implementation (although I think it got fairly hosed over time due to a lot of changes in the main tree). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Mon, 30 Sep 2002, Julian Elischer wrote: I was talking to someone about lightweight interrupt threads and interactions with KSEs and specifically about KSE borrowing.. Believe it or not, I can't remember who it was.. if it was you, let me know :-) Julian 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Sep 30 22:23:06 PDT 2002 -- === coda /local0/scratch/des/src/sys/coda/coda_psdev.c: In function `coda_call': /local0/scratch/des/src/sys/coda/coda_psdev.c:566: structure has no member named `p_siglist' /local0/scratch/des/src/sys/coda/coda_psdev.c:575: structure has no member named `p_siglist' *** Error code 1 Stop in /local0/scratch/des/src/sys/modules/coda. *** Error code 1 Stop in /local0/scratch/des/src/sys/modules. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
