Re: ATAng regression: cdcontrol close not working
It seems Lars Eggert wrote: Lars Eggert wrote: Soren Schmidt wrote: Is there any other patch I can try? I've just confirmed that this bug still exists with today's kernel. I cant reproduce the no matter what I try, sorry... Would remote access to the machine in question help you? FYI, this is still an issue: s = ioctl(fd, CDIOCCLOSE, 0) IOError: [Errno 16] Device busy Hmm, if the call to do the close fails there isn't much I can do... I can't reproduce the problem on any of the dozens of ATAPI CDROM's I have in the closet, so if you want to get further with this, you'll have to instrument the code and find out exactly why this fails. Maybe then I can find a solution that can work, and not break anything. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
vnode lock violation in today's -CURRENT
I just ran into this while running portupgrade. VOP_GETATTR: 0xc741e000 is not locked but should be Debugger(Lock violation. ) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db tr Debugger(c08bf9aa,c9749c78,c741e000,c08bf9eb,e820c984) at Debugger+0x55 vfs_badlock(c08bf9eb,c9749c78,c741e000,c09590e0,c741e000) at vfs_badlock+0x45 assert_vop_locked(c741e000,c9749c78,e820c9dc,0,e820c9c0) at assert_vop_locked+0x62 getdents_common(c6ede500,e820cd10,1,e820cd40,c0848b70) at getdents_common+0xfa linux_getdents64(c6ede500,e820cd10,c08d6778,3ee,3) at linux_getdents64+0x20 syscall(2f,2f,2f,5,0) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (220, Linux ELF, linux_getdents64), eip = 0x805a028, esp = 0xbfbfdc5c, ebp = 0xbfbfdcb8 --- It looks to me like the call to vn_lock() in getdents_common() needs to be moved to before the call to VOP_GETATTR(). The malloc() call should probably be moved as well, which means that the intervening error handling needs to be tweaked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hit g_provider %p disappeared while tasting
On Mon, 17 Nov 2003, Robert Watson wrote: Hi, Where the dead pointer comes from is what has yet to be discovered. Do you have an atapi-cd drive in this machine ? No. while pxebooting there is no floppy and no hd and no cf rader attached. fxp0, dual intel card fxp1,2 an ed0 (preloaded module) and an older S3 graphic card. that's about everything in that P133 with F00F bug. I have older a todays boot logs including boot_verbose=1; if it helps I can mail them off-list. What, if any, storage devices or pseudo-devices are present. Often, diskless environments use md for temporary storage...? Or, maybe we're looking at a failure mode that occurs when zero storage devices are available :-). or if some special classes like md and atapi-cd are used that have no taster function. I send some more information to phk this very early morning. The problem seens to be that none of the classes has a goem entry when going through g_valid_obj(). Another thing that crossed my mind while going to work this morning is that the only related reports I had seen are when mounting rootfs. [ also see [EMAIL PROTECTED] , this month in current ] What about the atapi-cd case ? From the debugging this night I remember that there are some XXX comments in geom_dev about this. Just another thing one might keep in mind while further debugging. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upgraded to CURRENT = system is dead
Garance A Drosihn [EMAIL PROTECTED] writes: Uh. /usr/src/UPDATING explicitly says: 20031112: [...] You should build and boot a new kernel BEFORE doing a `make world' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. We generally recommend doing a buildworld first, but it has to be done in a different order for this upgrade. These instructions should be changed. Doing 'buildworld' before 'buildkernel' works just fine this time as always, and instructing users to do the opposite will only confuse them. There's nothing in the kernel build that calls statfs64. However, if I am correctly reading the section quoted from Antione's message, the problem might be that he did: 'make install kernel ...' instead of: 'make installkernel ...' I assumed that this was a typo in the email, but even if it wasn't, it shouldn't make any difference; since he didn't build a new world, 'make install' will just reinstall the world he already had, and 'make kernel' will build and install a new kernel. It'll just take a while longer than it should. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machine freeze when X starts
Chris Knight wrote: -Original Message- From: Jens Rehsack [mailto:[EMAIL PROTECTED] Sent: Monday, 17 November 2003 00:00 To: [EMAIL PROTECTED] Subject: Machine freeze when X starts Hi, after I updated my machine yesterday to the -CURRENT src/ and ports/ of yesterday (2003-11-15 10:30 GMT), build kernel and world as described in Kirks HEADSUP mail and rebuild all ports, my machine always crashes when I start X. My problem is, that I cannot determine the reason for the crashes, so I cannot think about a workaround. Any hints are very welcome :-) I had a similar problem. I resolved my problem by killing the gnome session processes and the X lockup was fixed. I had replaced metacity with enlightenment, so there might be some weird interaction between the two. Hope this helps. Hi Chris, sorry, that wont help me out, 'cause the machine is not reacting to anything I'm doing (except the power and reset button). Best regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- [EMAIL PROTECTED] I've got a freezing compaq presario when using the trident driver. The power button is then the only option. When using the vesa driver, there's no freezing. Must add though that I had this problem with every 5.x, and not 4.8. It seems to be a xfree server thing for this machine. Have you tried the vesa driver? Dylan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build world question
Jason [EMAIL PROTECTED] writes: I cvsuped an hour or so ago, now when I finish make buildworld I get: === usr.sbin/boot0cfg cc -O -pipe -march=athlon-xp -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.sbin/boot0cfg/boot0cfg.c cc -O -pipe -march=athlon-xp -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -o boot0cfg boot0cfg.o gzip -cn /usr/src/usr.sbin/boot0cfg/boot0cfg.8 boot0cfg.8.gz === etc This is normal behaviour and has been for ages. No errors, thats it. I thought I should get this message too: make world completed on You didn't ask it to do 'make world', so it didn't tell you that 'make world' was completed. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS-UP new statfs structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 14 Nov 2003 08:33, Matt Smith wrote: And gnomevfs was something I saw in another headsup. There are bound to be others, I'm just keeping an eye on my /var/log/messages to see if anything else sig 11 or 12's! So far so good though. I have a feeling OpenOffice (1.0) is also broken by this. #0 0x285eb243 in osl_psz_getVolumeInformation () from /usr/local/OpenOffice.org1.0/program/libsal.so.3 Looks like something to do with disks to me. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/uhQ4LqgJ90OcaiARAsYuAKDgHgVsJYlXTmT8MOvvI+AQsJPbLwCbBo8C RmBzxNU60/6WfQjLcyjAC64= =yO/7 -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machine freeze when X starts
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote: Chris Knight wrote: -Original Message- From: Jens Rehsack [mailto:[EMAIL PROTECTED] Sent: Monday, 17 November 2003 00:00 To: [EMAIL PROTECTED] Subject: Machine freeze when X starts Hi, after I updated my machine yesterday to the -CURRENT src/ and ports/ of yesterday (2003-11-15 10:30 GMT), build kernel and world as described in Kirks HEADSUP mail and rebuild all ports, my machine always crashes when I start X. My problem is, that I cannot determine the reason for the crashes, so I cannot think about a workaround. Any hints are very welcome :-) I had a similar problem. I resolved my problem by killing the gnome session processes and the X lockup was fixed. I had replaced metacity with enlightenment, so there might be some weird interaction between the two. Hope this helps. Hi Chris, sorry, that wont help me out, 'cause the machine is not reacting to anything I'm doing (except the power and reset button). At least we can be sure that something went completely wrong with this weekend's sources. I had similar symptoms (X crashing, basic commands not working), but was lucky enough, not to be completely locked out. With some help from this list I could rebuild the OS. X and Metacity work again, but Nautilus still crashes. Jens, did you try to reload your old kernel? boot /boot/kernel.old Perhaps this gives you a little more than the power button. Uli. Best regards, Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- [EMAIL PROTECTED] I've got a freezing compaq presario when using the trident driver. The power button is then the only option. When using the vesa driver, there's no freezing. Must add though that I had this problem with every 5.x, and not 4.8. It seems to be a xfree server thing for this machine. Have you tried the vesa driver? Dylan +---+ |Peter Ulrich Kruppa| | Wuppertal | | Germany | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS-UP new statfs structure
On Tue, Nov 18, 2003 at 12:44:35PM +, Mark Dixon wrote: On Friday 14 Nov 2003 08:33, Matt Smith wrote: And gnomevfs was something I saw in another headsup. There are bound to be others, I'm just keeping an eye on my /var/log/messages to see if anything else sig 11 or 12's! So far so good though. I have a feeling OpenOffice (1.0) is also broken by this. I'm sure we could go on like this for ages, but the lesson to be learned is that you should rebuild all your installed applications (e.g. portupgrade -fa) to be sure there are no hidden surprises waiting to bite you weeks or months down the line. Kris pgp0.pgp Description: PGP signature
Unfortunate dynamic linking for everything
Guys, Please revisit the dynamic linking for everything. The cost for using shared libs in cases like shells actually is higher than statically linking (both in memory and in time.) It appears that there is a loss of VM understanding over time. Don't confuse the advantages of using shared libs on X windows (and environments like that) with the same advantages being non-existant when using shared libs on normal layout programs (shells are perhaps the worst general case, but not necessarily the worst in all ways.) Another issue: if you continue to support the dynamic linking mechanisms for special shared libs, but otherwise link statically, much of the high overhead of shared libs for-everything will still be mitigated. Just because there might be a need for a special shared lib, that doesn't justify using shared libs for everything (and add the cost of sparse memory allocation and significantly higher fork/exec times than necessary.) For a 'fun time', take a look at the process map in the deprecated /proc filesystem. Compare the size (complexity) of a shared program with a static program... It doesn't show all of the internal differences, but is an externally accessable (and benchmark free) exemplar. The only real reason for building various programs dynamic in order to gain the advantage of specific shared object would be an all or nothing type argument (a typical fallacy in most religious discussions.) It really doesn't make sense to arbitrarily cut-off a discussion especially when a decision might be incorrect. Perhaps the all-dynamic scheme had been decided upon so as to give a competitive performance advantage to those who rebuild everything (appropriate) static? :-). If there hadn't been a noticed increase in cost by using all-shared-libs, then the measurements were done incorrectly. If the decision is made based upon allowing for 1.5X (at least) times increase in fork/exec times, and larger memory usage (due to sparse allocations), then it would be best to have decided that performance isn't as important as it used to be (which it just might not be anymore.) Last time that I heard, disk space is still much much less expensive than main memory :-). Remember: the cost for disk space is nil nowadays, space only made obvious by an insanely small default root filesystem size allocation. (An 'insanely' small root filesystem is okay when that root is a mini-root recovery system, but the cost of an extra 500MB is rather small on a non-specialty system is nil compared to other resources.) I do use an all-dynamic configuration for certain embedded applications (but also a case where there are no seperated filesystems, and the memory usage isn't quite as important because of the fact that AVAILABLE features is more important than lots of concurrently running programs.) For the best sharing and quickest system response (both due to memory and raw program/image invocation times), at least make the shells static. (Sorry for any misspellings or grammar errors -- it is early in the morning... I'll probably not participate in any further discussion on this matter either, but it would be good to generally avoid loosing 'ancient', but still 'accurate' technical history.) John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machine freeze when X starts
Peter Ulrich Kruppa wrote:
At least we can be sure that something went completely wrong with
this weekend's sources.
Not just this weekend. The commit of the new interrupt code prevents
my system from running with HTT and I've seen nothing in the commits
which gives a workaround for me. John knows about the issue and I'm
hoping he thinks about a fix.
I had similar symptoms (X crashing, basic
commands not working), but was lucky enough, not to be completely
locked out. With some help from this list I could rebuild the OS.
X and Metacity work again, but Nautilus still crashes.
Jens, did you try to reload your old kernel?
No, because the (already build and installed) world requires
the new stat strcutures :-(
boot /boot/kernel.old
:-)
Great idea, but without dri it works fine.
Perhaps this gives you a little more than the power button.
Don't loading dri does even, but at the moment I'm rebuilding
the ports for another machine ('cause the crashed machine was
also the build workstation) to give Robert the backtrace (if
I can get it).
Bast regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR (vm_kern.c:328, vm_map.c:2176) (current-nov-17)
hi, lock order reversal 1st 0xc0c31100 system map (system map) @ /usr/src/sys/vm/vm_kern.c:328 2nd 0xc07052e0 Giant (Giant) @ /usr/src/sys/vm/vm_map.c:2176 Stack backtrace: backtrace witness_lock _mtx_lock_flags rm_map_delete kmem_alloc page_alloc uma_large_malloc malloc g_bde_new_sector g_bde_start2 g_bde_start1 g_bde start g_io_schedule_down g_down_priority fork_exit fork_trampoline uname -a FreeBSD security-ag.ath.cx 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Nov 17 15:20:03 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ SECURITY-AG i386 hth, Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help getting Realtek 8129-based NIC recognized?
Date: Mon, 17 Nov 2003 23:11:00 -0700 (MST) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Help getting Realtek 8129-based NIC recognized? From: M. Warner Losh [EMAIL PROTECTED] Have you tried re? It's in the kernel config, yes: device rl # RealTek 8129/8139 device re # new RealTek driver It does not, however, appear to be recognized. Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] If you want true virus-protection for your PC, install a non-Microsoft OS on it. Plausible candidates include FreeBSD, Linux, NetBSD, OpenBSD, and Solaris (in alphabetical order). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sbin/umount umount.c
Ian Dowse wrote (2003/11/16):
Modified files:
sbin/umount umount.c
Log:
If the unmount by file system ID fails, don't warn before retrying
a non-fsid unmount if the file system ID is all zeros. This is a
temporary workaround for warnings that occur in the vfs.usermount=1
case because non-root users get a zeroed filesystem ID. I have a
more complete fix in the works, but I won't get it done for 5.2.
Revision ChangesPath
1.41 +4 -1 src/sbin/umount/umount.c
Hello and thanks for fixing this! I had a plan to report this, but you
were faster :o) I'm interested in this area - please, can you tell, what
do you plan to do in your more complete fix?
When I looked at this issue, I thought about some things:
* Why is f_fsid zeroed for non-root users at all? Is there any reason?
Maybe it would be good idea to document it in
/usr/src/lib/libc/sys/getfsstat.2 and /usr/src/lib/libc/sys/statfs.2 -
so one small point for Tim:
Tim J. Robbins wrote (2003/11/15):
Modified files:
lib/libc/sys statfs.2
Log:
Resync. struct statfs and flag definitions with sys/mount.h.
Revision ChangesPath
1.22 +57 -22src/lib/libc/sys/statfs.2
* Tim, can you please update /usr/src/lib/libc/sys/getfsstat.2 to reflect
current sys/mount.h too, as you did for /usr/src/lib/libc/sys/statfs.2?
Manual page getfsstat.2 lists struct statfs too and there are still old
fields and values like MNAMELEN is 90 and so on. And if there are no
objections, is it possible to add sentence Non-root users get always
f_fsid zeroed. (with better english...) to both manual pages?
* There are small typos in umount.c:
--- umount.c.orig Tue Nov 18 16:24:43 2003
+++ umount.cTue Nov 18 16:24:54 2003
@@ -365,7 +365,7 @@
warn(unmount of %s failed, sfs-f_mntonname);
if (errno != ENOENT)
return (1);
- /* Compatability for old kernels. */
+ /* Compatibility for old kernels. */
warnx(retrying using path instead of file system ID);
if (unmount(sfs-f_mntonname, fflag) != 0) {
warn(unmount of %s failed, sfs-f_mntonname);
@@ -557,7 +557,7 @@
}
/*
- * Convert a hexidecimal filesystem ID to an fsid_t.
+ * Convert a hexadecimal filesystem ID to an fsid_t.
* Returns 0 on success.
*/
int
---
* Do you understand, why there is line in umount.c:376
getmntentry(NULL, NULL, sfs-f_fsid, REMOVE)
? I'm not sure, but if it is needed for some reason,
I think that there should be used different getmntentry() according
to the used unmount() method, like in this patch:
--- umount.c.orig Tue Nov 18 14:59:00 2003
+++ umount.cTue Nov 18 15:26:59 2003
@@ -370,10 +370,14 @@
if (unmount(sfs-f_mntonname, fflag) != 0) {
warn(unmount of %s failed, sfs-f_mntonname);
return (1);
+ } else {
+ /* Mark this this file system as unmounted. */
+ getmntentry(NULL, sfs-f_mntonname, NULL, REMOVE);
}
+ } else {
+ /* Mark this this file system as unmounted. */
+ getmntentry(NULL, NULL, sfs-f_fsid, REMOVE);
}
- /* Mark this this file system as unmounted. */
- getmntentry(NULL, NULL, sfs-f_fsid, REMOVE);
if (vflag)
(void)printf(%s: unmount from %s\n, sfs-f_mntfromname,
sfs-f_mntonname);
---
* /usr/src/sbin/mount/mount.c: If user uses mount -v, it prints false
zeroed fsids - isn't it better to print just non-zero fsids, so that
nobody is mystified? I have created two patches - I do not know
which do you consider as a better:
--- mount.c.origTue Nov 18 14:46:24 2003
+++ mount.c Tue Nov 18 14:50:46 2003
@@ -535,9 +535,11 @@
if (sfp-f_syncreads != 0 || sfp-f_asyncreads != 0)
(void)printf(, reads: sync %ld async %ld,
sfp-f_syncreads, sfp-f_asyncreads);
- printf(, fsid );
- for (i = 0; i sizeof(sfp-f_fsid); i++)
- printf(%02x, ((u_char *)sfp-f_fsid)[i]);
+ if (sfp-f_fsid.val[0] != 0 || sfp-f_fsid.val[1] != 0) {
+ printf(, fsid );
+ for (i = 0; i sizeof(sfp-f_fsid); i++)
+ printf(%02x, ((u_char *)sfp-f_fsid)[i]);
+ }
}
(void)printf()\n);
}
---
or
--- mount.c.origTue Nov 18 14:46:24 2003
+++ mount.c Tue Nov 18 14:57:30 2003
@@ -508,7 +508,7 @@
prmount(sfp)
struct statfs *sfp;
{
- int flags, i;
+ int flags, i, fsid;
struct opt *o;
struct passwd *pw;
@@ -535,9 +535,18 @@
if (sfp-f_syncreads != 0 || sfp-f_asyncreads != 0)
(void)printf(, reads: sync %ld
Problem booting JPSNAP kernel
I have been trying to get the latest current iso to install, but so far I cannot get it to boot. I am installing it on a IBM Netfinity 5500 which has only one processor installed (two possible) and the only thing really special that it has is a ServerRAID card (looks to be built-in or at least very hard to get to). I had no problem last month installing a JPSNAP from 2003-10-21. The iso from 2003-11-16 gives me this error when booting right after the Beastie menu. There is no other info given other then the menu, not even the copyright. Thinking that it might be the CD, I booted off of the 2003-10-21 disc and had it install the 2003-11-16 data via ftp, and I still get the same error when booting the 16th's kernel off the hard disk. Here is the error: cpuid = 0; apic id = 00 instruction pointer= 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment = base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, def32 0, gran 0 processor eflags = interrupt enabled, vm86, IOPL = 0 current process= 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 Any Ideas? I was able to boot off the 16th's disc in a laptop and a desktop just a few minutes ago. I also have an old makeshift current server with build from last night running fine. FreeBSD seems to just not like something on this server now. Thanks, Matt Haught ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : It really doesn't make sense to arbitrarily cut-off a : discussion especially when a decision might be incorrect. I'd say that good technical discussion about why this is wrong would be good. However, emotional ones should be left behind. Except for John's message, most of the earlier messages have been more emotional than technical. John, do you have any good set of benchmarks that people can run to illustrate your point? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS-UP new statfs structure
Kirk McKusick wrote (2003/11/14):
This is why we make this change now so that it will be in place
for the masses when 5.2 is released :-)
Hello, and is it possible to review some my (one's from masses :o)
questions/suggestions?
* cvtstatfs() for freebsd4_* compat syscalls does not copy text fields
correctly, so old binaries with new kernel know just about first
16 characters from mount points - what do you think about the
following patch? (Or maybe with even safer sizeof() - but I did not
test it.)
--- sys/kern/vfs_syscalls.c.origSun Nov 16 11:12:09 2003
+++ sys/kern/vfs_syscalls.c Sun Nov 16 11:56:07 2003
@@ -645,11 +645,11 @@
osp-f_syncreads = MIN(nsp-f_syncreads, LONG_MAX);
osp-f_asyncreads = MIN(nsp-f_asyncreads, LONG_MAX);
bcopy(nsp-f_fstypename, osp-f_fstypename,
- MIN(MFSNAMELEN, OMNAMELEN));
+ MIN(MFSNAMELEN, OMFSNAMELEN - 1));
bcopy(nsp-f_mntonname, osp-f_mntonname,
- MIN(MFSNAMELEN, OMNAMELEN));
+ MIN(MNAMELEN, OMNAMELEN - 1));
bcopy(nsp-f_mntfromname, osp-f_mntfromname,
- MIN(MFSNAMELEN, OMNAMELEN));
+ MIN(MNAMELEN, OMNAMELEN - 1));
if (suser(td)) {
osp-f_fsid.val[0] = osp-f_fsid.val[1] = 0;
} else {
---
* sys/compat/freebsd32/freebsd32_misc.c: If you look into copy_statfs(),
you copy 88-byte strings into just 80-byte strings. Fortunately it seems
that there are just overwritten spare fields and f_syncreads/f_asyncreads
before they are set to the correct value. What about these patches, which
furthermore are resistant to possible MFSNAMELEN change in the future?
[I'm sorry, these patches are untested]
--- sys/compat/freebsd32/freebsd32.h.orig Tue Nov 18 16:58:28 2003
+++ sys/compat/freebsd32/freebsd32.hTue Nov 18 16:59:36 2003
@@ -75,6 +75,7 @@
int32_t ru_nivcsw;
};
+#define FREEBSD32_MFSNAMELEN 16 /* length of type name including null */
#define FREEBSD32_MNAMELEN(88 - 2 * sizeof(int32_t)) /* size of on/from name
bufs */
struct statfs32 {
@@ -92,7 +93,7 @@
int32_t f_flags;
int32_t f_syncwrites;
int32_t f_asyncwrites;
- charf_fstypename[MFSNAMELEN];
+ charf_fstypename[FREEBSD32_MFSNAMELEN];
charf_mntonname[FREEBSD32_MNAMELEN];
int32_t f_syncreads;
int32_t f_asyncreads;
--- sys/compat/freebsd32/freebsd32_misc.c.orig Tue Nov 18 16:59:49 2003
+++ sys/compat/freebsd32/freebsd32_misc.c Tue Nov 18 17:03:31 2003
@@ -276,6 +276,7 @@
static void
copy_statfs(struct statfs *in, struct statfs32 *out)
{
+ bzero(out, sizeof *out);
CP(*in, *out, f_bsize);
CP(*in, *out, f_iosize);
CP(*in, *out, f_blocks);
@@ -290,14 +291,14 @@
CP(*in, *out, f_flags);
CP(*in, *out, f_syncwrites);
CP(*in, *out, f_asyncwrites);
- bcopy(in-f_fstypename,
- out-f_fstypename, MFSNAMELEN);
- bcopy(in-f_mntonname,
- out-f_mntonname, MNAMELEN);
+ bcopy(in-f_fstypename, out-f_fstypename,
+ MIN(MFSNAMELEN, FREEBSD32_MFSNAMELEN - 1));
+ bcopy(in-f_mntonname, out-f_mntonname,
+ MIN(MNAMELEN, FREEBSD32_MNAMELEN - 1));
CP(*in, *out, f_syncreads);
CP(*in, *out, f_asyncreads);
- bcopy(in-f_mntfromname,
- out-f_mntfromname, MNAMELEN);
+ bcopy(in-f_mntfromname, out-f_mntfromname,
+ MIN(MNAMELEN, FREEBSD32_MNAMELEN - 1));
}
int
---
* sys/ia64/ia32/ia32.h: It seems to me that statfs32 has similar problems
as freebsd32.h - however in this case real and bigger, because statfs32
is now a combination of old and new statfs: old 32bit fields with new
string lengths, so sizeof(statfs32) is changed from 256 to 272. Is this
really correct? If I understand it correctly, it breaks binary
compatibility for old ia32 binaries. I think that MFSNAMELEN/MNAMELEN
should be renamed to OMFSNAMELEN/OMNAMELEN, or ia32.h should define own
IA32_MFSNAMELEN/IA32_MNAMELEN, similarly to freebsd32.h - which is more
secure with respect to further updates in the future.
* sys/ia64/ia32/ia32_misc.c: If ia32.h is changed/fixed, copy_statfs()
has the same problems, as is in freebsd32_misc.c.
* sys/alpha/osf1/osf1_mount.c: And just small trash at the end, because
it is in #ifdef notanymore ... #endif ;o) (however it means, that osf1
statfs calls are completely broken?), but why bsd2osf_statfs() has
3 x max()? What about following patch?
--- sys/alpha/osf1/osf1_mount.c.origTue Nov 18 17:40:08 2003
+++ sys/alpha/osf1/osf1_mount.c Tue Nov 18 17:40:52 2003
@@ -88,7 +88,7 @@
{
#ifdef notanymore
-bzero(osfs, sizeof (struct osf1_statfs));
+ bzero(osfs, sizeof (struct osf1_statfs));
if (!strncmp(fsnames[MOUNT_UFS], bsfs-f_fstypename, MFSNAMELEN))
osfs-f_type = OSF1_MOUNT_UFS;
else if (!strncmp(fsnames[MOUNT_NFS], bsfs-f_fstypename, MFSNAMELEN))
@@
Recovery? recent make world rendered system unusable (64 bit change)
I've been running 5.1-CURRENT for a while and a couple nights ago did a make world. After a couple hours building, my system was unusable. Critical binaries like rm, ls, mtree, sh failed, reporting Exec format error. I can't login, not even single user. I can no longer even boot single user. I've hosed my system and am looking for a way to recover without having to reinstall everything and overwrite critical data and system config files. Naturally, I only discovered the note in UPDATING after I trashed my system -- in fact, I read it from the OK boot prompt with its more. Doh! 20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a `installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. [...] Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. [...] DO NOT make installworld after the buildworld w/o building and installing a new kernel FIRST. You will be unable to build a new kernel otherwise on a system with new binaries and an old kernel. I'm looking for recommendations on how to recover, hopefully without trashing my critical system files like /etc/passwd. Ideally, I guess I'd like a way to replace all the broken binaries and any related libraries without overwriting other files. If I do a floppy-based install and then select Custom/Expert than request a minimal install, I presume it will install a small set of binaries but also overwrite /etc/passwd, /etc/ssh/* and so on. Is there a way to have it just update binaries and libraries? If I have to, I could add another disk to this box. Then I could do a floppy install of 5.x on to that new disk. Then I could boot it, and mount the old disk's partitions. Then install the new install's binaries on the old partitions. Or perhaps I could do a make buildworld, kernel, installworld the proper way, using the old disk's partitions as the target. Or could I -- somehow -- push a 64-bit-aware kernel onto this box so that the newly broken binaries will work again? How? Again, I've got no shell access any more so everything's gonna have to be done from floppy or maybe CD if I can borrow a burner. Naturally, this is my net boot server for my diskless clients so I can't go that route either. :-( Any other suggestions? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM Blade
Has anyone been successful installing FreeBSD 5.x (or 4.x) on an IBM HS20 Blade? I would surely be interested in pointers if possible. I tried but failed miserably. There were two problems: 1. It is impossible to boot from CD. Neither 4.8 nor 5.1 boot from CD. Booting from floppy works but is of course cumbersome. 2. After boot, keyboard did not work. The problem is that although the keyboard is actually a USB keyboard, the AT port is still connected so FreeBSD detects the normal keyboard as well, so the nonexisting AT keyboard becomes /dev/kbd0 while the real (USB) keyboard becomes /dev/kbd1. This was a bug in both 4.8 and 5.1 and it is supposedly fixed in 4.9. I'll have the possibility to test 4.9 on the blade soon now and I'll be able to test it. Both the fiberchannel and ethernet seem to be detected during bootup, but I don't know if they actually work... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem booting JPSNAP kernel
Matt Haught wrote: I have been trying to get the latest current iso to install I have also had negative results with the floppies from the 16th, but the error for me is that no kernel modules want to get loaded, ergo no networking. Good news: It looks like the problems I had creating filesystems using sysinstall have been corrected. Pete... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recovery? recent make world rendered system unusable (64 bit change)
In message: [EMAIL PROTECTED] Chris Shenton [EMAIL PROTECTED] writes: : I'm looking for recommendations on how to recover, hopefully without : trashing my critical system files like /etc/passwd. Ideally, I guess : I'd like a way to replace all the broken binaries and any related : libraries without overwriting other files. Grab a recent snapshot. Boot off of that with the fixit functionality. Fix things. Chances are good that you'll be able to build a new kernel with the kernel that you booted... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recovery? recent make world rendered system unusable (64 bit change)
Hiya, Chris Shenton wrote: ... [snip] ... Any other suggestions? Thanks. Yes, You need to exploit the notion of booting from another root filesystem, mounting the broken root, and then taking corrective action on the corrupted files. The easy way is to grab a recent livecd from the jp snapshot service. With the jpsnap livecd I was able to boot, copy all the working binaries from the cdrom over the corrupt binaries on the local HDD. I suggest you try the same idea. Certainly there are other ways to do the same exact thing, but without the time and expense of downloading the iso9660 image, and burning a rom. Certainly you could make due with a set of floppies, and/or nfs from another -current machine. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM Blade
On Tuesday 18 November 2003 17:56, Blaz Zupan wrote: FreeBSD 5.x (or 4.x) on an IBM HS20 Blade? I would surely be interested in pointers if possible. I tried but failed miserably. There were two problems: 1. It is impossible to boot from CD. Neither 4.8 nor 5.1 boot from CD. Booting from floppy works but is of course cumbersome. I've made the installation using the pxe network installation http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/index.html and it worked without problem. 2. After boot, keyboard did not work. The problem is that although the keyboard is actually a USB keyboard, the AT port is still connected so FreeBSD detects the normal keyboard as well, so the nonexisting AT keyboard becomes /dev/kbd0 while the real (USB) keyboard becomes /dev/kbd1. This was a bug in both 4.8 and 5.1 and it is supposedly fixed in 4.9. I'll have the possibility to test 4.9 on the blade soon now and I'll be able to test it. I've solved DISABLING every kind of usb from the kernel. but making so I lost the floppy and the cdrom. :-( I've not tried with 4.9 but only with 4.8 R Both the fiberchannel and ethernet seem to be detected during bootup, but I don't know if they actually work... the ethernet worked fine. Ciao Marco ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM Blade
I've solved DISABLING every kind of usb from the kernel. but making so I lost the floppy and the cdrom. :-( I've not tried with 4.9 but only with 4.8 R Well, if you managed to install it, then there is no problem. Reenable usb and put this in /etc/rc.local or some other startup file: kbdcontrol -k /dev/kbd1 This will switch keyboard during startup. This way you should have floppy, cdrom and keyboard working. But the real solution should be to upgrade to 4.9, which is supposed to work without the above hack. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote: FYI, this is still an issue: s = ioctl(fd, CDIOCCLOSE, 0) IOError: [Errno 16] Device busy Hmm, if the call to do the close fails there isn't much I can do... I can't reproduce the problem on any of the dozens of ATAPI CDROM's I have in the closet, so if you want to get further with this, you'll have to instrument the code and find out exactly why this fails. Maybe then I can find a solution that can work, and not break anything. I'll see what I can find out. It probably doesn't help you to know that the same hardware worked fine with the old ATA code... Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Recovery? recent make world rendered system unusable (64 bit change)
On Tue, Nov 18, 2003 at 11:50:22AM -0500, Chris Shenton wrote: I've been running 5.1-CURRENT for a while and a couple nights ago did a make world. After a couple hours building, my system was unusable. Critical binaries like rm, ls, mtree, sh failed, reporting Exec format error. I can't login, not even single user. I can no longer even boot single user. Re-install/upgrade from a cd. Upgrade should leave your files alone. I've argued before that world should be removed as a target, as I don't believe it's ever correct to do it. Why leave this gun pointed at people's feet? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
anoncvs connection refused?
Hi, I've seen this for the last few days: [EMAIL PROTECTED]: /usr/src] make -DCVS_UPDATE update -- Updating /usr/src from cvs repository -- cd /usr/src; cvs -R -q update -A -P -d cvs [update aborted]: connect to anoncvs.freebsd.org(209.181.243.20):2401 failed: Connection refused *** Error code 1 Is anoncvs filtering me? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Update ncurses in base system?
Apparently, the ncurses version in the base system is 5.2, while there is a newer 5.3 port available. Would it make sense to import the 5.3 ncurses into the base system? There are some ports (mail/cone) that need 5.3 and that won't work with FreeBSD 4 either way (missing i18n/l10n features in libc.so.4 that are in libc.so.5). Thanks in advance, -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Updated acpi_cpu patch
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
Thanks,
Nate
Notes:
* Add a detach method that disables entry to acpi_cpu_idle and in the SMP
case, IPIs all processors to exit sleeping. This fixes a panic on
shutdown for MP boxes.
* Rework the initialization functions so that cpu_idle_hook is written
late in the boot process. This fixes a panic on boot where acpi_cpu_idle
was called before the cpu_cx_states entry was filled out.
* Make the P_BLK, P_BLK_LEN, and cpu_cx_count all softc-local variables.
This will help SMP boxes that have _CST or multiple P_BLKs. No such boxes
are known at this time.
* Always allocate the C1 state, even if the P_BLK is invalid. This means
we will always take over idling if enabled. Remove the value -1 as valid
for cx_lowest since this is redundant with machdep.cpu_idle_hlt.
* Reduce locking for the throttle initialization case to around the write
to the smi_cmd port.
Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.19
diff -u -r1.19 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 - 1.19
+++ sys/dev/acpica/acpi_cpu.c 18 Nov 2003 17:46:23 -
@@ -1,5 +1,5 @@
/*-
- * Copyright (c) 2003 Nate Lawson
+ * Copyright (c) 2003 Nate Lawson (SDG)
* Copyright (c) 2001 Michael Smith
* All rights reserved.
*
@@ -77,9 +77,11 @@
device_tcpu_dev;
ACPI_HANDLE cpu_handle;
uint32_tcpu_id;/* ACPI processor id */
+uint32_tcpu_p_blk; /* ACPI P_BLK location */
+uint32_tcpu_p_blk_len; /* P_BLK length (must be 6). */
struct resource*cpu_p_cnt; /* Throttling control register */
struct acpi_cx cpu_cx_states[MAX_CX_STATES];
-int cpu_bm_ok; /* Bus mastering control available. */
+int cpu_cx_count; /* Number of valid Cx states. */
};
#define CPU_GET_REG(reg, width)\
@@ -116,10 +118,9 @@
#define PCI_REVISION_4M3
/* Platform hardware resource information. */
-static uint32_t cpu_p_blk; /* ACPI P_BLK location */
-static uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */
static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */
static uint8_t cpu_pstate_cnt;/* Register to take over throttling. */
+static uint8_t cpu_cst_cnt; /* Indicate we are _CST aware. */
static uint32_t cpu_rid; /* Driver-wide resource id. */
static uint32_t cpu_quirks;/* Indicate any hardware bugs. */
@@ -146,11 +147,13 @@
static int acpi_cpu_probe(device_t dev);
static int acpi_cpu_attach(device_t dev);
+static int acpi_cpu_detach(device_t dev);
static int acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
static voidacpi_cpu_startup(void *arg);
static voidacpi_cpu_startup_throttling(void);
+static voidacpi_cpu_startup_cx(void);
static voidacpi_cpu_throttle_set(uint32_t speed);
static voidacpi_cpu_idle(void);
static voidacpi_cpu_c1(void);
@@ -166,6 +169,7 @@
/* Device interface */
DEVMETHOD(device_probe,acpi_cpu_probe),
DEVMETHOD(device_attach, acpi_cpu_attach),
+DEVMETHOD(device_detach, acpi_cpu_detach),
{0, 0}
};
@@ -178,6 +182,7 @@
static devclass_t acpi_cpu_devclass;
DRIVER_MODULE(acpi_cpu, acpi, acpi_cpu_driver, acpi_cpu_devclass, 0, 0);
+
static int
acpi_cpu_probe(device_t dev)
{
@@ -272,11 +277,10 @@
AcpiEvaluateObject(sc-cpu_handle, _INI, NULL, NULL);
/* Get various global values from the Processor object. */
-cpu_p_blk = pobj.Processor.PblkAddress;
-cpu_p_blk_len = pobj.Processor.PblkLength;
+sc-cpu_p_blk = pobj.Processor.PblkAddress;
+sc-cpu_p_blk_len = pobj.Processor.PblkLength;
ACPI_DEBUG_PRINT((ACPI_DB_IO, acpi_cpu%d: P_BLK at %#x/%d%s\n,
-device_get_unit(dev), cpu_p_blk, cpu_p_blk_len,
-sc-cpu_p_cnt ? : (shadowed)));
+device_get_unit(dev), sc-cpu_p_blk, sc-cpu_p_blk_len));
acpi_sc = acpi_device_get_parent_softc(dev);
sysctl_ctx_init(acpi_cpu_sysctl_ctx);
@@ -297,7 +301,8 @@
if (thr_ret == 0 || cx_ret == 0) {
status = AcpiInstallNotifyHandler(sc-cpu_handle, ACPI_DEVICE_NOTIFY,
acpi_cpu_notify, sc);
- AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, sc);
+ if (device_get_unit(dev) == 0)
+ AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, NULL);
} else {
Re: anoncvs connection refused?
On Tue, Nov 18, 2003 at 09:48:33AM -0800, Lars Eggert wrote: I've seen this for the last few days: [EMAIL PROTECTED]: /usr/src] make -DCVS_UPDATE update -- Updating /usr/src from cvs repository -- cd /usr/src; cvs -R -q update -A -P -d cvs [update aborted]: connect to anoncvs.freebsd.org(209.181.243.20):2401 failed: Connection refused *** Error code 1 Is anoncvs filtering me? No, not filtering. There was a little problem with an upgrade followed by a little trouble finding who has the keys to that particular machine room. It's being worked on. Sorry for the hassles. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recovery? recent make world rendered system unusable (64 bit change)
masta [EMAIL PROTECTED] writes: The easy way is to grab a recent livecd from the jp snapshot service. [ http://livecd.sourceforge.net/ ] With the jpsnap livecd I was able to boot, copy all the working binaries from the cdrom over the corrupt binaries on the local HDD. I suggest you try the same idea. That seems a like a nice suite, but the site says it's acts like a 4.6 repair, so I don't think the binaries would be suitable for replacing my damaged 5.1 commands. :-( ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recovery? recent 'make world' rendered system unusable (64 bit change)
Allegedly Chris Shenton said masta [EMAIL PROTECTED] writes: The easy way is to grab a recent livecd from the jp snapshot service. With the jpsnap livecd I was able to boot, copy all the working binaries from the cdrom over the corrupt binaries on the local HDD. I suggest you try the same idea. [ http://livecd.sourceforge.net/ ] That seems a like a nice suite, but the site says it's acts like a 4.6 repair, so I don't think the binaries would be suitable for replacing my damaged 5.1 commands. :-( I wasn't talking about that, I was talking about the jp snapshot service, which is accessible at: http://snapshots.jp.freebsd.org/ The site speaks for itself, but basicly it is a dailly snapshot service for FreeBSD, which by now should have all the fixes you need on their livecd version of -cuurent. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EISA Adaptec 274X SCSI panic (ISRng related)
On Tue, 18 Nov 2003, Andy Farkas wrote: My EISA AHA2740's don't work no more :( # grep ahc /var/run/dmesg.boot ahc0: Adaptec 274X SCSI adapter at 0x2c00-0x2cff, irq 10 (level) ahc0: on eisa0 slot 2 ahc1: Adaptec 274X SCSI adapter at 0x4c00-0x4cff, irq 11 (level) ahc1: on eisa0 slot 4 ahc2: Adaptec aic7880 Ultra SCSI adapter port 0xf800-0xf8ff mem 0xf68fb000-0xf68fbfff irq 17 at device 11.0 on pci1 ahc2: Using left over BIOS settings ahc3: Adaptec aic7880 Ultra SCSI adapter port 0xf400-0xf4ff mem 0xf68fa000-0xf68fafff irq 18 at device 12.0 on pci1 ahc3: Using left over BIOS settings Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code= supervisor write, page not present instruction pointer = 0x8:0xc0649083 stack pointer = 0x10:0xd763ac5c frame pointer = 0x10:0xd763ac84 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 14 (idle: cpu0) kernel: type 12 trap, code=0 Stopped at intr_execute_handlers+0x23: lock addl %eax,0(%edx) db tr intr_execute_handlers(c06d5084,d763ac9c,d763ace0,c065bbae,7) at intr_execute_handlers+0x23 atpic_handle_intr(7) at atpic_handle_intr+0x42 Xatpic_intr7() at Xatpic_intr7+0x1e --- interrupt, eip = 0xc064d655, esp = 0xd763ace0, ebp = 0xd763ace0 --- This is almost certainly addressed by jhb's atpic patch. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-CURRENT totally broken on AMD64 in 32-bit mode
On Mon, Nov 17, 2003 at 10:12:03AM -0800, David O'Brien wrote: The kernel changes of the past week has totally turned my AMD64 machine that I use in 32-bit mode running FreeBSD/i386 (GENERIC): OK boot -v cpuid = 0; apic id = 00 instruction pointer = 0x0:0xa00 stack pointer = 0x0:0xffe frame pointer = 0x0:0x0 code segment= base 0x0, limit 0x0, type 0x0 = DPL 0 , pres 0, def32 0, gran 0 processor eflags= interrupt enabled, vm86, IOPL = 0 cuyrrent process= 0 () kernel: type 30 trap, code=0 Stopped at 0xa00: cli db tr (null)(0,0,0,0,0) at 0xa00 You get a panic (trap 30) that you can hit 'center' and continue from. It's actually only a trap, not a panic. I am trying to figure out the exact problem now. It seems that the vm86 code is very buggy and enables interrupts during the early boot. You can try http://www.FreeBSD.org/~jhb/patches/vm86.patch -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD current, apache and php4 woes
Hi. panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated cpuid = 0; lapic.id = You'll either want to raise the size of the kmem_map pool or decrease the maximum number of vnodes allowed (vnodes get allocated out of the kmem_map and are likely depleating it Add one of the two lines to /boot/loader.conf: kern.vn.kmem.size=35000 or kern.maxvnodes=15 The first one is probably the better choice for you since the very nature of what you are doing demands that you touch a lot of vnodes. Scott It seems that your advice helpted cure the patient. I did two things: 1. added kern.vm.kmem.size=45000 2. clean up tmp-files older than 4 hours every hour (previous was files older than 12 h.). Now the servers has been quite stable, no reboot in almost two days! My problem appears to be too many files in /tmp and /var/tmp (50.000 or more) which made the kernel puke. I guess this is a scenario which we will see more often. Would it be possible to output this situation to the message-log before the server simply reboots? I did install 4.9 but in my particular case the server would stop responding to web-request after a few hours, but would respond to ping. Console login was imposible. So 5.1 is more mature in my case. The last two weeks have been _very_ frustrating. ;-) Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR (swap_pager.c:1323, swap_pager.c:1838, uma_core.c:876) (current:Nov17)
Here is the stack backtrace: lock order reversal 1st 0xc1da318c vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc0724900 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1838 3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Stack backtrace: backtrace(c0692be9,c0c358c4,c06a376c,c06a376c,c06a464d) at backtrace+0x17 witness_lock(c0c358c4,8,c06a464d,36c,1) at witness_lock+0x672 _mtx_lock_flags(c0c358c4,0,c06a464d,36c,1) at _mtx_lock_flags+0xba obj_alloc(c0c22480,1000,c976f9db,101,c06f3f50) at obj_alloc+0x3f slab_zalloc(c0c22480,1,c06a464d,68c,c0c22494) at slab_zalloc+0xb3 uma_zone_slab(c0c22480,1,c06a464d,68c,c0c22520) at uma_zone_slab+0xd6 uma_zalloc_internal(c0c22480,0,1,5c1,72e,c06f55a8) at uma_zalloc_internal+0x3e uma_zalloc_arg(c0c22480,0,1,72e,2) at uma_zalloc_arg+0x3ab swp_pager_meta_build(c1da318c,7,0,2,0) at swp_pager_meta_build+0x174 swap_pager_putpages(c1da318c,c976fbb8,8,0,c976fb20) at swap_pager_putpages+0x32d default_pager_putpages(c1da318c,c976fbb8,8,0,c976fb20) at default_pager_putpages+0x2e vm_pageout_flush(c976fbb8,8,0,0,c06f36a0) at vm_pageout_flush+0x17a vm_pageout_clean(c0dae2d8,0,c06a4468,32a,0) at vm_pageout_clean+0x305 vm_pageout_scan(0,0,c06a4468,5a9,1f4) at vm_pageout_scan+0x65f vm_pageout(0,c976fd48,c068d4ed,311,0) at vm_pageout+0x31b fork_exit(c0625250,0,c976fd48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc976fd7c, ebp = 0 --- Debugger(witness_lock) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db I'm running the sources from yesterday, nov 17: FreeBSD 5.1-CURRENT #0: Mon Nov 17 06:40:05 CST 2003 root@:/usr/obj/usr/src/sys/GALAXY ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR (swap_pager.c:1323, swap_pager.c:1838, uma_core.c:876) (current:Nov17)
On Tue, 18 Nov 2003, Cosmin Stroe wrote: Here is the stack backtrace: Thanks, this is known and is actually safe. We're pursuing ways to quiet these warnings. lock order reversal 1st 0xc1da318c vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc0724900 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1838 3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Stack backtrace: backtrace(c0692be9,c0c358c4,c06a376c,c06a376c,c06a464d) at backtrace+0x17 witness_lock(c0c358c4,8,c06a464d,36c,1) at witness_lock+0x672 _mtx_lock_flags(c0c358c4,0,c06a464d,36c,1) at _mtx_lock_flags+0xba obj_alloc(c0c22480,1000,c976f9db,101,c06f3f50) at obj_alloc+0x3f slab_zalloc(c0c22480,1,c06a464d,68c,c0c22494) at slab_zalloc+0xb3 uma_zone_slab(c0c22480,1,c06a464d,68c,c0c22520) at uma_zone_slab+0xd6 uma_zalloc_internal(c0c22480,0,1,5c1,72e,c06f55a8) at uma_zalloc_internal+0x3e uma_zalloc_arg(c0c22480,0,1,72e,2) at uma_zalloc_arg+0x3ab swp_pager_meta_build(c1da318c,7,0,2,0) at swp_pager_meta_build+0x174 swap_pager_putpages(c1da318c,c976fbb8,8,0,c976fb20) at swap_pager_putpages+0x32d default_pager_putpages(c1da318c,c976fbb8,8,0,c976fb20) at default_pager_putpages+0x2e vm_pageout_flush(c976fbb8,8,0,0,c06f36a0) at vm_pageout_flush+0x17a vm_pageout_clean(c0dae2d8,0,c06a4468,32a,0) at vm_pageout_clean+0x305 vm_pageout_scan(0,0,c06a4468,5a9,1f4) at vm_pageout_scan+0x65f vm_pageout(0,c976fd48,c068d4ed,311,0) at vm_pageout+0x31b fork_exit(c0625250,0,c976fd48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc976fd7c, ebp = 0 --- Debugger(witness_lock) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db I'm running the sources from yesterday, nov 17: FreeBSD 5.1-CURRENT #0: Mon Nov 17 06:40:05 CST 2003 root@:/usr/obj/usr/src/sys/GALAXY ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Update ncurses in base system?
On Tue, Nov 18, 2003 at 06:57:08PM +0100, Matthias Andree wrote: Apparently, the ncurses version in the base system is 5.2, while there is a newer 5.3 port available. Would it make sense to import the 5.3 ncurses into the base system? Perhaps, once FreeBSD 5.2 is released. A committer needs to take interest in the issue and perform the import. Kris pgp0.pgp Description: PGP signature
Re: LOR (swap_pager.c:1323, swap_pager.c:1838, uma_core.c:876) (current:Nov17)
On Tue, Nov 18, 2003 at 01:53:28PM -0600, Cosmin Stroe wrote: Here is the stack backtrace: lock order reversal 1st 0xc1da318c vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc0724900 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1838 3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Known issue, harmless. Kris pgp0.pgp Description: PGP signature
Current SMP with ACPI dies in a second
My old MSI-6120 SMP system has been unusable quite a while with ACPI. I've got these so far: - Couldn't get vector from ISR - vmstat -i shows high interrupt rates and system is very slow - kernel trap 12 panic Latest problem is something like this: pfs_vncache_unload(): 2 entries remaining current process = 27 (irq17: fxp0) kernel trap 12 stray irq20 Kernel config, dmesg, acpidump, etc. files available at http://tomppa.iki.fi/~tomppa/FreeBSD/ Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
In the last episode (Nov 18), M. Warner Losh said:
In message: [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
: It really doesn't make sense to arbitrarily cut-off a discussion
: especially when a decision might be incorrect.
I'd say that good technical discussion about why this is wrong would
be good. However, emotional ones should be left behind. Except for
John's message, most of the earlier messages have been more emotional
than technical.
John, do you have any good set of benchmarks that people can run to
illustrate your point?
Pretty much any benchmark that you can build statically and dynamically
should suffice. I've attached a simple one that fills an array with
random numbers then qsorts them. make compare will generate three
graphs at the end: time spent loading the executable, time spent within
the loops, and total time. Note that both load and loop timings are
higher for the dynamic binary. I ran it on a busy system, which is why
there are so many outliers. Make sure you have
src/tools/tools/ministat installed someplace in your path.
Also see
http://lists.freebsd.org/pipermail/freebsd-current/2003-April/001106.html ,
where I had posted proc/pid/maps for a static and dynamic ls.
--
Dan Nelson
[EMAIL PROTECTED]
all: compare
REPS=50
STATICLOGS=static.total.log static.loop.log static.load.log
DYNAMICLOGS=dynamic.total.log dynamic.loop.log dynamic.load.log
LOGS=${STATICLOGS} ${DYNAMICLOGS}
CFLAGS+=-Wall
static: svd.o
${CC} -static ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.ALLSRC} ${LDADD}
dynamic: svd.o
${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.ALLSRC} ${LDADD}
clean:
rm -f static dynamic ${LOGS} *.o
.PHONY: run
run ${LOGS}: static dynamic
@rm -f ${LOGS}
@reps=0; while [ $$reps -lt ${REPS} ] ; do \
time -p ./static 21 static.loop.log | sed -ne '/real/s/real //p'
static.total.log ; \
time -p ./dynamic 21 dynamic.loop.log | sed -ne '/real/s/real //p'
dynamic.total.log ; \
echo -n . ; \
reps=$$(($$reps+1)) ; \
done
@echo
@paste static.total.log static.loop.log | awk '{print $$1 - $$2}'
static.load.log
@paste dynamic.total.log dynamic.loop.log | awk '{print $$1 - $$2}'
dynamic.load.log
compare: ${LOGS}
ministat -s static.load.log dynamic.load.log
ministat -s static.loop.log dynamic.loop.log
ministat -s static.total.log dynamic.total.log
#include stdio.h
#include stdlib.h
#include string.h
#include sys/time.h
#define SIZE 1024000
int comp(const void *a, const void *b)
{
return memcmp(a, b, sizeof(int));
}
int main(int argc, char *argv[])
{
int numbers[SIZE];
int i;
struct timeval tv1, tv2;
gettimeofday(tv1, NULL);
srand(5);
for (i = 0; i SIZE; i++)
{
numbers[i] = rand();
}
qsort(numbers, SIZE, sizeof(*numbers), comp);
gettimeofday(tv2, NULL);
timersub(tv2, tv1, tv1);
printf(%ld.%06ld\n, tv1.tv_sec, tv1.tv_usec);
return 0;
}
ministat -s static.load.log dynamic.load.log
x static.load.log
+ dynamic.load.log
+--+
| xx + |
| xx ++ |
| xx ++ |
| ++ |
| ++ |
| ++ |
| ++ |
| +++|
| x+++|
| x* |
| x*+ + |
| x**+ + ++ |
| x**+ ++ ++ +|
| *+++**+ ++ |
| xxx**+****+*++ ++* x +++ +|
||___M_A| |
| |__M__A_| |
+--+
N Min MaxMedian AvgStddev
x 96 0.001561 0.027646 0.003969 0.0049661042 0.0040137086
+ 96 0.003765 0.05356 0.00824 0.010588323 0.0072195082
Difference at 95.0% confidence
0.0056 +/- 0.00165239
113.212% +/- 33.2733%
Re: FreeBSD current, apache and php4 woes
On Tue, 18 Nov 2003, [iso-8859-1] Claus Guttesen wrote: Hi. panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated cpuid = 0; lapic.id = You'll either want to raise the size of the kmem_map pool or decrease the maximum number of vnodes allowed (vnodes get allocated out of the kmem_map and are likely depleating it Add one of the two lines to /boot/loader.conf: kern.vn.kmem.size=35000 or kern.maxvnodes=15 The first one is probably the better choice for you since the very nature of what you are doing demands that you touch a lot of vnodes. Scott It seems that your advice helpted cure the patient. I did two things: 1. added kern.vm.kmem.size=45000 2. clean up tmp-files older than 4 hours every hour (previous was files older than 12 h.). Now the servers has been quite stable, no reboot in almost two days! My problem appears to be too many files in /tmp and /var/tmp (50.000 or more) which made the kernel puke. I forgot to mention in the last email that kern.maxvnodes will still scale upwards as you increase kern.vm.kmem.size. So you might want to set a hard limit on it so you don't continue to run into problems. A value of 200,000 is probably good in your case. I guess this is a scenario which we will see more often. Would it be possible to output this situation to the message-log before the server simply reboots? It might be useful for this particular panic message to print out the value of maxvnodes, numvnodes, and/or other metrics to help with debugging. We need to also review the scaling algorithm and tweak it back into line. A more complex solution would be to create a way for the vfs system to get feedback on KVA and kmem_map pressure and auto-tune itself. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: cardbus no longer working with -CURRENT and ACPI
On 15-Nov-2003 Dylan Wylie wrote:
List,
Running -CURRENT now gives the following problem on a Compaq Pressario 1600-
XL144 laptop:
[...]
cbb0: TI1211 PCI-CardBus Bridge at device 10.0 on pci0
cardbus0: CardBus bus on cbb0
pccard0: 16-bit PCCard bus on cbb0
pcib0: _PRS resource entry has unsupported type 0
cbb: Unable to map IRQ...
device_probe_and_attach: cbb0 attache returned 12
[...]
Umm. ARGH!
Can you try this:
Index: acpi_pcib.c
===
RCS file: /usr/cvs/src/sys/dev/acpica/acpi_pcib.c,v
retrieving revision 1.33
diff -u -r1.33 acpi_pcib.c
--- acpi_pcib.c 14 Nov 2003 21:36:09 - 1.33
+++ acpi_pcib.c 18 Nov 2003 19:40:31 -
@@ -287,7 +287,7 @@
}
/* type-check the resource we've got */
-if (prsres-Id != ACPI_RSTYPE_IRQ || prsres-Id != ACPI_RSTYPE_EXT_IRQ) {
+if (prsres-Id != ACPI_RSTYPE_IRQ prsres-Id != ACPI_RSTYPE_EXT_IRQ) {
device_printf(pcib, _PRS resource entry has unsupported type %d\n,
prsres-Id);
goto out;
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote: Below you'll find the update patch for acpi_cpu. Please test this, especially for SMP and laptops with _CST objects in their ASL. Looks good here on a Centrino based laptop, which has a _CST method in its ASL: acpi_cpu0: CPU on acpi0 acpi_cpu0: C2 state 1 lat acpi_cpu0: C3 state 85 lat hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 86231/0 0/0 0/0 Although it seems I have lost a C3 state (before, I had an additional C3/185). regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Lukas Ertl wrote: hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 86231/0 0/0 0/0 Although it seems I have lost a C3 state (before, I had an additional C3/185). Correction: every other boot I get the additional C3/185 - strange, indeed. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote:
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
...
Notes:
* Add a detach method that disables entry to acpi_cpu_idle and in the SMP
case, IPIs all processors to exit sleeping. This fixes a panic on
shutdown for MP boxes.
Sigh, I appear to have been mistaken about the SMP reboot problem being
fixed, sorry about that. Mark's random_harvest panic appears to have
caused me to miss the other failure mode in my last test. Stack trace
attached, and I believe I'm running with your latest patch.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
crash2# reboot
boot() called on cpu#0
Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped
syncing disks, buffers remaining...
done
Uptime: 1m4s
Shutting down ACPI
terneRle btoroatpi n1g2. .w.i
h interrupts disabled
panic: Assertion td-td_turnstile != NULL failed at
../../../kern/subr_turnstile
.c:437
cpuid = 1;
Debugger(panic)
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db trace
Debugger(c08975c7,1,c0896aca,c8f389f4,100) at Debugger+0x55
panic(c0896aca,c089a415,c089a1f2,1b5,c0959398) at panic+0x156
turnstile_wait(c20e1280,c0955320,c2007640,1cc,c101bfe4) at
turnstile_wait+0x2ac
_mtx_lock_sleep(c0955320,0,c08ad7ae,df,0) at _mtx_lock_sleep+0x125
_mtx_lock_flags(c0955320,0,c08ad7ae,df,a) at _mtx_lock_flags+0x98
vm_fault(c0951d00,0,1,0,c1380640) at vm_fault+0x5a
trap_pfault(c8f38c04,0,9c,fc,9c) at trap_pfault+0x109
trap(c1380018,c8f30010,c0660010,0,10) at trap+0x333
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc047c619, esp = 0xc8f38c44, ebp = 0xc8f38c64 ---
AcpiHwLowLevelRead(10,c8f38c80,94,10,0) at AcpiHwLowLevelRead+0x19
AcpiHwRegisterRead(0,1,c8f38ca0,0,c137fc5c) at AcpiHwRegisterRead+0x71
AcpiGetRegister(1,c8f38ccc,0,3e8,0) at AcpiGetRegister+0x61
acpi_cpu_idle(c8f38d0c,c0658f4c,c0955320,2,c089533f) at acpi_cpu_idle+0x5e
cpu_idle(c0955320,2,c089533f,53,14b) at cpu_idle+0x28
idle_proc(0,c8f38d48,c08951f4,311,e8241c89) at idle_proc+0x3c
fork_exit(c0658f10,0,c8f38d48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xc8f38d7c, ebp = 0 ---
db
(kgdb) bt
#0 0xc081317b in Debugger (msg=0x12 Address 0x12 out of bounds)
at machine/atomic.h:263
#1 0xc066db36 in panic (fmt=0xc0896aca Assertion %s failed at %s:%d)
at ../../../kern/kern_shutdown.c:534
#2 0xc0693c8c in turnstile_wait (ts=0xc20e1280, lock=0xc0955320,
owner=0xc2007640) at ../../../kern/subr_turnstile.c:469
#3 0xc0664125 in _mtx_lock_sleep (m=0xc0955320, opts=0,
file=0xc08ad7ae ../../../vm/vm_fault.c, line=223)
at ../../../kern/kern_mutex.c:476
#4 0xc0663c88 in _mtx_lock_flags (m=0xc0955320, opts=0,
file=0xc08ad7ae ../../../vm/vm_fault.c, line=223)
at ../../../kern/kern_mutex.c:218
#5 0xc07d39fa in vm_fault (map=0xc0951d00, vaddr=0, fault_type=1 '\001',
fault_flags=0) at ../../../vm/vm_fault.c:223
#6 0xc0829159 in trap_pfault (frame=0xc8f38c04, usermode=0, eva=156)
at ../../../i386/i386/trap.c:711
#7 0xc0828dd3 in trap (frame=
{tf_fs = -1053294568, tf_es = -923598832, tf_ds = -1067057136,
tf_edi = 0, tf_esi = 16, tf_ebp = -923562908, tf_isp = -923562960, tf_ebx
= -923562880, tf_edx = -1, tf_ecx = 148, tf_eax = -923562880, tf_trapno =
12, tf_err = 0, tf_eip = -1069038055, tf_cs = 8, tf_eflags = 65538, tf_esp
= 1024, tf_ss = -923562880}) at ../../../i386/i386/trap.c:420
#8 0xc08148b8 in calltrap () at {standard input}:94
#9 0xc047c321 in AcpiHwRegisterRead (UseLock=0 '\0', RegisterId=16,
ReturnValue=0x12) at ../../../contrib/dev/acpica/hwregs.c:601
#10 0xc047c071 in AcpiGetRegister (RegisterId=18, ReturnValue=0x12,
Flags=0)
at ../../../contrib/dev/acpica/hwregs.c:375
#11 0xc0499ebe in acpi_cpu_idle () at ../../../dev/acpica/acpi_cpu.c:798
#12 0xc081d2d8 in cpu_idle () at ../../../i386/i386/machdep.c:1071
#13 0xc0658f4c in idle_proc (dummy=0x0) at ../../../kern/kern_idle.c:86
#14 0xc0658c44 in fork_exit (callout=0xc0658f10 idle_proc, arg=0x12,
frame=0x12) at ../../../kern/kern_fork.c:793
(kgdb) l *AcpiHwLowLevelRead+0x19
0xc047c619 is in AcpiHwLowLevelRead (../../../contrib/dev/acpica/hwregs.c:836).
831 /*
832 * Must have a valid pointer to a GAS structure, and
833 * a non-zero address within. However, don't return an error
834 * because the PM1A/B code must not fail if B isn't present.
835 */
836 if ((!Reg) ||
837 (!ACPI_VALID_ADDRESS (Reg-Address)))
838 {
839 return (AE_OK);
840 }
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Lukas Ertl wrote:
On Tue, 18 Nov 2003, Nate Lawson wrote:
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
Looks good here on a Centrino based laptop, which has a _CST method in
its ASL:
acpi_cpu0: CPU on acpi0
acpi_cpu0: C2 state 1 lat
acpi_cpu0: C3 state 85 lat
I'll be moving some printfs under bootverbose before release.
hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85
hw.acpi.cpu.cx_lowest: 0
hw.acpi.cpu.cx_history: 86231/0 0/0 0/0
Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is
available). I'm interested in any benchmark results, especially IO. I'm
hoping the scheduling of sleeps is good enough that you don't experience
much performance loss even with lower sleeps.
Although it seems I have lost a C3 state (before, I had an additional
C3/185).
_CST can change dynamically at runtime. If you booted with the AC adapter
attached, your laptop may not offer all the sleep states. When you unplug
the AC adapter, we get a notify on _CST to re-evaluate it and look for new
states. However, that code is currently disabled due to complex locking
issues (i.e. what to do when a Cx state is being accessed but _CST is
being re-evaluated). _CST re-evaluation won't be enabled until after
5.2R. However, you can reboot your laptop with the AC adapter detached
(or attached) to see what states are available.
This excerpt from truckman@'s asl shows that 4 Cx states are only
available when the AC adapter is not attached. (The C*NA memory addresses
appear to be managed by the BIOS and not the AML but the PSR access is
clear).
Method (_CST, 0, NotSerialized)
{
If (\C2NA)
{
Return (CST1)
}
If (\C3NA)
{
Return (CST2)
}
If (\_SB.PCI0.LPC.EC.AC._PSR ())
{
Return (CST3)
}
If (\C4NA)
{
Return (CST3)
}
Return (CST4)
}
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD current, apache and php4 woes
Hi. Add one of the two lines to /boot/loader.conf: kern.vn.kmem.size=35000 or kern.maxvnodes=15 The first one is probably the better choice for you since the very nature of what you are doing demands that you touch a lot of vnodes. 1. added kern.vm.kmem.size=45000 2. clean up tmp-files older than 4 hours every hour I forgot to mention in the last email that kern.maxvnodes will still scale upwards as you increase kern.vm.kmem.size. So you might want to set a hard limit on it so you don't continue to run into problems. A value of 200,000 is probably good in your case. A sysctl kern.maxvnodes gives me 134675, but it's been added as a safetyprecaution to /boot/loader.conf. regards Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Robert Watson wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: Below you'll find the update patch for acpi_cpu. Please test this, especially for SMP and laptops with _CST objects in their ASL. ... Notes: * Add a detach method that disables entry to acpi_cpu_idle and in the SMP case, IPIs all processors to exit sleeping. This fixes a panic on shutdown for MP boxes. Sigh, I appear to have been mistaken about the SMP reboot problem being fixed, sorry about that. Mark's random_harvest panic appears to have caused me to miss the other failure mode in my last test. Stack trace attached, and I believe I'm running with your latest patch. Could you add a printf to the start of acpi_cpu_detach()? I want to see if we're being called before or after ACPI is stopped (Shutting down ACPI). Also, please do: l *AcpiGetRegister+0x61 I think it's the call to get the bus master status, which is interesting since this means that cpu_cx_count != 0 which means that acpi_cpu_detach hasn't run yet. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote: On Tue, 18 Nov 2003, Lukas Ertl wrote: hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 86231/0 0/0 0/0 Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is available). I'm interested in any benchmark results, especially IO. I'm hoping the scheduling of sleeps is good enough that you don't experience much performance loss even with lower sleeps. I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. Although it seems I have lost a C3 state (before, I had an additional C3/185). _CST can change dynamically at runtime. If you booted with the AC adapter attached, your laptop may not offer all the sleep states. When you unplug the AC adapter, we get a notify on _CST to re-evaluate it and look for new states. However, that code is currently disabled due to complex locking issues (i.e. what to do when a Cx state is being accessed but _CST is being re-evaluated). _CST re-evaluation won't be enabled until after 5.2R. However, you can reboot your laptop with the AC adapter detached (or attached) to see what states are available. Ah, yes, that would explain it - I just booted on battery. This excerpt from truckman@'s asl shows that 4 Cx states are only available when the AC adapter is not attached. (The C*NA memory addresses appear to be managed by the BIOS and not the AML but the PSR access is clear). This part of the ASL looks the one here - let me guess, is it a ThinkPad? :-) regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Lukas Ertl wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is available). I'm interested in any benchmark results, especially IO. I'm hoping the scheduling of sleeps is good enough that you don't experience much performance loss even with lower sleeps. I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. That's probably ok. It has a lot of IO. This excerpt from truckman@'s asl shows that 4 Cx states are only available when the AC adapter is not attached. (The C*NA memory addresses appear to be managed by the BIOS and not the AML but the PSR access is clear). This part of the ASL looks the one here - let me guess, is it a ThinkPad? :-) Yes, R40. I'm scared because I'm beginning to recognize chipsets by their ASL organization. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote:
On Tue, 18 Nov 2003, Robert Watson wrote:
On Tue, 18 Nov 2003, Nate Lawson wrote:
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
...
Notes:
* Add a detach method that disables entry to acpi_cpu_idle and in the SMP
case, IPIs all processors to exit sleeping. This fixes a panic on
shutdown for MP boxes.
Sigh, I appear to have been mistaken about the SMP reboot problem being
fixed, sorry about that. Mark's random_harvest panic appears to have
caused me to miss the other failure mode in my last test. Stack trace
attached, and I believe I'm running with your latest patch.
Could you add a printf to the start of acpi_cpu_detach()? I want to see
if we're being called before or after ACPI is stopped (Shutting down
I modified acpi_cpu_detach:
+acpi_cpu_detach(device_t dev)
+{
+
+printf(\nacpi_cpu_detach\n\n);
+
But sure enough:
syncing disks, buffers remaining...
done
Uptime: 56s
Shutting down ACPI
kernel trap 12 with interrupts disabled
tanicR:e bAososteirntgi.o.n.
d-td_turnstile != NULL failed at ../../../kern/subr_turnstile.c:437
cpuid = 0;
Debugger(panic)
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db
So indeed, it doesn't look like the ACPI detach call has gone out yet.
ACPI). Also, please do:
l *AcpiGetRegister+0x61
I think it's the call to get the bus master status, which is interesting
since this means that cpu_cx_count != 0 which means that acpi_cpu_detach
hasn't run yet.
This is using the existing crash from the trace I sent you previously.
(kgdb) l *AcpiGetRegister+0x61
0xc047c071 is in AcpiGetRegister
(../../../contrib/dev/acpica/hwregs.c:375).
370 {
371 return_ACPI_STATUS (Status);
372 }
373 }
374
375 Status = AcpiHwRegisterRead (ACPI_MTX_DO_NOT_LOCK,
376 BitRegInfo-ParentRegister, RegisterValue);
377
378 if (Flags ACPI_MTX_LOCK)
379 {
Also potentially useful information:
(kgdb) inspect cpu_cx_count
$1 = 1
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Robert Watson wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: Could you add a printf to the start of acpi_cpu_detach()? I want to see if we're being called before or after ACPI is stopped (Shutting down So indeed, it doesn't look like the ACPI detach call has gone out yet. Yes, I'm certain acpi_cpu_detach is not being called before AcpiTerminate(). Can someone with some newbus knowledge explain this? devinfo shows acpi_cpu0 as a child of acpi0 so its detach should be called before acpi0's. Perhaps the fact that there is no DEVMETHOD for acpi_detach means that its children never have their detach methods called? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On 18 Nov, Lukas Ertl wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: This excerpt from truckman@'s asl shows that 4 Cx states are only available when the AC adapter is not attached. (The C*NA memory addresses appear to be managed by the BIOS and not the AML but the PSR access is clear). This part of the ASL looks the one here - let me guess, is it a ThinkPad? :-) Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode when I run shutdown -p. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Don Lewis wrote: On 18 Nov, Lukas Ertl wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: This excerpt from truckman@'s asl shows that 4 Cx states are only available when the AC adapter is not attached. (The C*NA memory addresses appear to be managed by the BIOS and not the AML but the PSR access is clear). This part of the ASL looks the one here - let me guess, is it a ThinkPad? :-) Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode when I run shutdown -p. That's an old problem that Linux is also trying to work around. It appears to be buggy hw. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
natd-Related Panic (?)
Sources cvsupped on the 16th or so. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc04fe96f stack pointer = 0x10:0xc9414ab0 frame pointer = 0x10:0xc9414ad4 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 = 252 (natd) kernel: type 12 trap, code=0 Stopped at m_free+0x4f: cmpl$0,0(%eax) db trace m_free(c9414b98,c063ee1e,0,c1befb08,c9414b14) at m_free+0x4f ip_input(c9414b98,c3,c06a5860,c9414cbc,246) at ip_input+0xc4 div_ouput(c1d04a50,c0fb1f00,c1befb00,0,c9414c20) at div_ouput+0x1ef div_send(c1d04a50,0,c0fb1f00,c1befb00,0) at div_send+0x5b sosend(c1d04a50,c1befb00,c9414c4c,c0fb1f00,0) at sosend+0x41d kern_sendit(c1c8c640,3,c9414cc4,0,0) kern_sendit+0xf2 sendit(c1c8c640,3,c9414cc4,0,bfbeeddc) at sendit+0x16e sendto(c1c8c640,c9414d14,c064ce16,3ee,6) at sendto+0x5b syscall(2f,2f,2f,bfbeed80,1) at syscall+0x266 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (133, FreeBSD ELF32, sendto), eip = 0x180d092f, esp = 0xbfbeecec, ebp = 0xbfbfed98 --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Corrected HEADS UP: the midi driver will be removed after 5.2-R
On Sat, 15 Nov 2003 22:42:44 +0900, Seigo Tanimura [EMAIL PROTECTED] said: tanimura Mathew Kanner has developed the new version of the midi framework, tanimura based on kobj(9) and buildable as a module. As the first step to tanimura replace the midi driver, the conventional one is removed from the tanimura kernel in a minute. tanimura Mathew will soon be starting a work to merge his driver. As we need some more time to define Mathew's driver, we have decided to postpone axing the old one until 5.2-R is released. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
floppy install [was: cvs commit: src/release/i386 drivers.conf]
Jun Kuriyama wrote: kuriyama2003/11/12 00:08:16 PST FreeBSD src repository Modified files: release/i386 drivers.conf Log: Move cd9660 module from 3rd floppy to 2nd to unbreak release. Revision ChangesPath 1.31 +1 -1 src/release/i386/drivers.conf It looks like the build has broken again in the same place: ftp://snapshots.jp.freebsd.org/pub/FreeBSD/snapshots/i386/5.1-CURRENT-20031118-JPSNAP.log If the beta is coming out tomorrow, it would be cool to have this fixed. The floppies from the 16th cannot load any of the kernel modules, I think the relevant error message is: link_elf: symbol _mtx_assert undefined Pete... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Tuesday 18 November 2003 18:58, you wrote: On Tue, 18 Nov 2003, Harald Schmalzbauer wrote: On Tuesday 18 November 2003 03:37, you wrote: Sorry I wasn't more clear. I need you to print the contents like this: print *cpu_cx_count cpu_cx_count 1 cpu_cx_lowest 0 cpu_idle_hook c0468300 cpu_cx_next 0 I hope these are the correct values. Thanks, those are the correct values for your box. I just posted a patch that should address the boot-time panic. Please revert old patches and try it. Yep, this looks good. Perhaps you're interested in the following line which arose for the first time during boot: C0? cx_next 0 cx_count 1 And here is what you requested in your first patch: cale:~ sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 0/0 How do I know when this will be comitted to . Thanks a lot, -Harry -Nate pgp0.pgp Description: signature
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote: On Tue, 18 Nov 2003, Don Lewis wrote: Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode when I run shutdown -p. That's an old problem that Linux is also trying to work around. It appears to be buggy hw. Just for the record: shutdown -p works fine on the T40. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Tue, 18 Nov 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : It really doesn't make sense to arbitrarily cut-off a : discussion especially when a decision might be incorrect. I'd say that good technical discussion about why this is wrong would be good. However, emotional ones should be left behind. Except for John's message, most of the earlier messages have been more emotional than technical. I used to use all dynamic linkage, but switched to all static linkage (except for ports) when I understood John's points many year ago. It shouldn't be necessary to repeat the argmuments. John, do you have any good set of benchmarks that people can run to illustrate your point? Almost any benchmark that does lots of forks or execs, or uses libraries a lot will do. IIRC, 5-10% of my speedups for makeworld was from building tools static. Makeworld is not such a good benchmark for this as it used to be since it always builds tools static so the non-staticness of standard binaries doesn't matter so much. Perhaps it still matters for /bin/sh. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sbin/umount umount.c
In message [EMAIL PROTECTED], Rudolf Cejka writes:
If the unmount by file system ID fails, don't warn before retrying
a non-fsid unmount if the file system ID is all zeros. This is a
...
Hello and thanks for fixing this! I had a plan to report this, but you
were faster :o) I'm interested in this area - please, can you tell, what
do you plan to do in your more complete fix?
When I looked at this issue, I thought about some things:
* Why is f_fsid zeroed for non-root users at all? Is there any reason?
As I understand it, the main reason for hiding file system IDs from
non-root users is beacuse file system IDs are used as part of NFS
file handles on an NFS server, so hiding them makes it harder to
guess a valid file handle. If you know the file system ID and an
inode number, then you would only need to guess the 32-bit inode
generation number.
OpenBSD started zeroing out file system IDs for non-root users a
long time ago, and while FreeBSD mostly followed suit, I think it
was only with Kirk's 64-bit statfs changes a few days ago that we
have started doing this consistently (we had missed getfsstat()
before).
I was planning to return a filesystem ID of {st_dev, 0} to non-root
users, where st_dev is the device number that is already returned
by the stat(2) system call. This requires a few changes, because
currently st_dev comes from va_fsid in struct vattr, which is not
directly accessible at the time a file system is mounted. Since
many userland applications depend on st_dev being persistent and
unique, I think it makes more sense to have it as part of struct
mount instead of struct vattr.
Some additional changes are required to guarantee the uniqueness
of st_dev's and file system IDs (including {st_dev, 0} ones), and
then unmount(2) needs to accept these user-visible IDs. In fact,
maybe {st_dev, 0} could be returned to root too, but that might
possibly break some NFS-related utilities.
* There are small typos in umount.c:
Thanks - fixed locally, but there's no urgency to commit before
5.2.
* Do you understand, why there is line in umount.c:376
getmntentry(NULL, NULL, sfs-f_fsid, REMOVE)
? I'm not sure, but if it is needed for some reason,
I think that there should be used different getmntentry() according
to the used unmount() method, like in this patch:
I think umount(8) first gets a list of all mounted file systems and
then uses that list to resolve a mountpoint or device node into a
a struct statfs. When unmounting all file systems, it needs to
ignore any file systems that it has already unmounted, or it might
attempt to unmount the same file system twice. If the unmount call
fails, it should still do the REMOVE operation so that it will at
least attempt an unmount on each file system.
You're right that this will not work correctly with zeroed file
system IDs (it worked before Kirk's commit last week, but wasn't
supposed to). In practice can it ever make things worse than the
uniqueness problems caused by non-root users not having no file
system ID? I can't think of any examples offhand.
* /usr/src/sbin/mount/mount.c: If user uses mount -v, it prints false
zeroed fsids - isn't it better to print just non-zero fsids, so that
nobody is mystified? I have created two patches - I do not know
which do you consider as a better:
Yes, I guess now that getfsstat(2) also zeros the IDs for non-root,
there isn't much point in printing them.
Ian
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: natd-Related Panic (?)
On Tue, 2003-11-18 at 23:38, Rogelio Rodriguez wrote: Sources cvsupped on the 16th or so. Try re-cvsup-ing. I was struck by the same problem and it was fixed with rev 1.256 of ip_input.c HTH, -- Andreas Kohn [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Unfortunate dynamic linking for everything
M. Warner Losh said: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : It really doesn't make sense to arbitrarily cut-off a : discussion especially when a decision might be incorrect. I'd say that good technical discussion about why this is wrong would be good. However, emotional ones should be left behind. Except for John's message, most of the earlier messages have been more emotional than technical. John, do you have any good set of benchmarks that people can run to illustrate your point? I'll see if I can find some of my old benchmarks (from memory, not disk -- lots of stuff has rotted away.). I had hoped to avoid doing much in the way of proof. Pointing to the much more complex process map along with the implication for significantly higher overhead :-). (The VM code generally gets slower with more complex process maps and more memory used. For smallish programs -- including those with a few shared libs, changing the VM code won't help much, because the cost is built in to the complexity of the process image.) If set-up correctly (trying to find facts, rather than proving a foregone conclusion), even the fork/exec tests on LMBENCH can be informative. The LMBENCH fork/exec benchmarks don't really measure EVERYTHING, and there appears to be a additional overhead beyond the old-time a.out, but they will likely still show some of the additional overhead. (Actually, simple fork/exec tests of simple programs don't show all of the additional overhead, and also bias the overhead results, but are one data point.) There might be a certain 'coolness' WRT dynamically linking everything, but the overhead is certainly measurable. If the object is to maximally 'share', then for shells the FreeBSD VM shares maximally without using shared libs (perhaps there is a lost know-how about how aggressively the FreeBSD VM implements parent/child and exec based sharing?) I'll try to put together a few simple benchmarks -- mostly from my defective memory. I had recently refreshed myself on this issue (but lost again due to disk hardware disasters and being clobbered by vinum problems -- which I have given up on.) Gimme a day or so -- I have several other things in my queue. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
named problem (introduced in 5.1)
-- Resending this. Since it might got lost. Hi ! I have been running named for few years now, and I never had any problem with it. Few days ago I upgraded system to 5.1 (Release) and named has gone beserk. It shows errors in named.root file. Error go something like this: check_hints: no A record for address 'Something' class 1 in hints I updated all /etc files with files from source tree (which is cvsuped to 5.1-RELEASE) but it doesn't work? Does anybody have any idea where the problem lies? Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/* ** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recovery? recent make world rendered system unusable (64 bit change)
On Tue, 2003-11-18 at 08:50, Chris Shenton wrote: I've been running 5.1-CURRENT for a while and a couple nights ago did a make world. After a couple hours building, my system was unusable. Critical binaries like rm, ls, mtree, sh failed, reporting Exec format error. I can't login, not even single user. I can no longer even boot single user. I've hosed my system and am looking for a way to recover without having to reinstall everything and overwrite critical data and system config files. Naturally, I only discovered the note in UPDATING after I trashed my system -- in fact, I read it from the OK boot prompt with its more. Doh! 20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a `installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. [...] Running an old kernel after a `make world' will cause programs such as `df' that do a statfs system call to fail with a bad system call. [...] DO NOT make installworld after the buildworld w/o building and installing a new kernel FIRST. You will be unable to build a new kernel otherwise on a system with new binaries and an old kernel. I'm looking for recommendations on how to recover, hopefully without trashing my critical system files like /etc/passwd. Ideally, I guess I'd like a way to replace all the broken binaries and any related libraries without overwriting other files. If I do a floppy-based install and then select Custom/Expert than request a minimal install, I presume it will install a small set of binaries but also overwrite /etc/passwd, /etc/ssh/* and so on. Is there a way to have it just update binaries and libraries? If I have to, I could add another disk to this box. Then I could do a floppy install of 5.x on to that new disk. Then I could boot it, and mount the old disk's partitions. Then install the new install's binaries on the old partitions. Or perhaps I could do a make buildworld, kernel, installworld the proper way, using the old disk's partitions as the target. Or could I -- somehow -- push a 64-bit-aware kernel onto this box so that the newly broken binaries will work again? How? Again, I've got no shell access any more so everything's gonna have to be done from floppy or maybe CD if I can borrow a burner. Naturally, this is my net boot server for my diskless clients so I can't go that route either. :-( Any other suggestions? Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Best suggestion would be to get a 5.0-CURRENT live CD off of current.snapshot.org with the kernel with the new statfs changes if it exists (I forget if we make live CD's daily or not) That or you can loadup a emergency holoshell of 5.1 RELEASE, reinstall /bin /sbin /usr/sbin etc and then rebuild the kernel to the new statfs kernel, then install the new world once again. The basic problem is you need a kernel with the new statfs changes, maybe you can find someone nice enough here to email you their kernel with the new changes that'll boot on your computer, and then you can get it corrected. Even I had that problem, luckily the machine was just a test machine so reinstallation wasn't going to kill me. Scott -- I think we ought to be out there doing what we do best - making large holes in other people's countries. - George Carlin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in cache_lookup()
Bleeding edge current updated around 15:00 GMT today. This was triggered whilst building GENERIC to test someone's patches... db trace cache_lookup(c2c50514,d65d9c28,d65d9c3c,c2c50514,c29fd280) at cache_lookup+0x166 vfs_cache_lookup(d65d9b70,d65d9b8c,c051ab52,d65d9b70,20002) at vfs_cache_lookup+0xc9 ufs_vnoperate(d65d9b70,20002,c29fd280,c303430c,c29fd280) at ufs_vnoperate+0x18 lookup(d65d9c14,c2a18800,400,d65d9c30,c29fd280) at lookup+0x302 namei(d65d9c14,1,c29fd280,d65d9c18,0) at namei+0x20b lstat(c29fdtat+0x52 syscall(2f,2f,2f,bfbfbc78,0) at syscall+0x309 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (190, FreeBSD ELF32, lstat), eip = 0x280be3cf, esp = 0xbfbfb26c, ebp = 0xbfbfb2f8 --- If you need any more information, contact me via email or on irc in 'all the usual places'. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote: M. Warner Losh said: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : It really doesn't make sense to arbitrarily cut-off a : discussion especially when a decision might be incorrect. I'd say that good technical discussion about why this is wrong would be good. However, emotional ones should be left behind. Except for John's message, most of the earlier messages have been more emotional than technical. John, do you have any good set of benchmarks that people can run to illustrate your point? I'll see if I can find some of my old benchmarks (from memory, not disk -- lots of stuff has rotted away.). I had hoped to avoid doing much in the way of proof. Pointing to the much more complex process map along with the implication for significantly higher overhead :-). (The VM code generally gets slower with more complex process maps and more memory used. For smallish programs -- including those with a few shared libs, changing the VM code won't help much, because the cost is built in to the complexity of the process image.) I'm glad that real arguments are finally starting to surface =-) Our rationale for encouraging Gordon is as follows: 1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want to upgrade from 4-STABLE. Historically in 4.x, the / partition has been very modest in size. One just simply cannot cram the bloat that has grown in 5.x into a 4.x partition scheme. Of course there is the venerable 'dump - clean install - restore' scheme, but we were looking for something a little more user-friendly. 2. NSS support out-of-the-box: Again, this is a user-experience issue in that forcing NSS users to recompile world was seen as a potential roadblock to them. 3. Binary security updates: there is a lot of interest in providing a binary update mechanism for doing security updates. Having a dynamic root means that vulnerable libraries can be updated without having to update all of the static binaries that might use them. 4. I've probably forgotten the other factors... As for performance, we felt that the typical use of FreeBSD did not fall into the category of doing forkbomb performance tests. While there might certainly be users that do continuously create lots of short-lived processes, we felt that the above benefits outweighed this, but left the door open for tailoring to this need (recompiling world with NO_DYNAMICROOT). If people really are concerned with the VM microbenchmarks associated with complex process maps, then hopefully this is a challenge to look for optimizations there. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in random_harvest()
I think a fix was already committed for this, but it's biting me hard
right now.
Script started on Wed Nov 19 00:09:06 2003
kimchi# gdb -k /home/bms/cvs/src/sys/i386/compile/KIMCHI vm[K[K/kernel.debig
[K[Kug vmcore.7
GNU gdb 5.2.1 (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-undermydesk-freebsd...
panic: kmem_malloc: entry not found or misaligned
panic messages:
---
panic: kmem_malloc: entry not found or misaligned
Stack backtrace:
panic: from debugger
Uptime: 4m28s
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from
/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI/modules/usr/home/bms/cvs/src/sys/modules/vesa/vesa.ko.debug...done.
Loaded symbols for
/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI/modules/usr/home/bms/cvs/src/sys/modules/vesa/vesa.ko.debug
Reading symbols from /boot/kernel/if_vr.ko...done.
Loaded symbols for /boot/kernel/if_vr.ko
Reading symbols from
/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI/modules/usr/home/bms/cvs/src/sys/modules/usb/usb.ko.debug...done.
Loaded symbols for
/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI/modules/usr/home/bms/cvs/src/sys/modules/usb/usb.ko.debug
Reading symbols from /boot/kernel/netgraph.ko...done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/blank_saver.ko...done.
Loaded symbols for /boot/kernel/blank_saver.ko
#0 doadump () at ../../../kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc04c3edd in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc04c4299 in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc0431bf2 in db_panic () at ../../../ddb/db_command.c:450
#4 0xc0431b52 in db_command (last_cmdp=0xc0689af0, cmd_table=0x0,
aux_cmd_tablep=0xc0684a5c, aux_cmd_tablep_end=0xc0684a60)
at ../../../ddb/db_command.c:346
#5 0xc0431c86 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc0434b4a in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73
#7 0xc0620a65 in kdb_trap (type=3, code=0, regs=0xd65f1498)
at ../../../i386/i386/db_interface.c:171
#8 0xc063159c in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1066937799, tf_ebp =
-698411804, tf_isp = -698411836, tf_ebx = 0, tf_edx = 0, tf_ecx = 1021, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1067315964, tf_cs = 8, tf_eflags = 130, tf_esp =
-1066925180, tf_ss = -1067016530})
at ../../../i386/i386/trap.c:580
#9 0xc06223c8 in calltrap () at {standard input}:88
#10 0xc04c41ec in panic (
fmt=0xc067d239 kmem_malloc: entry not found or misaligned)
at ../../../kern/kern_shutdown.c:534
#11 0xc05e60bd in kmem_malloc (map=0xc0c310a0, size=4096, flags=1)
at ../../../vm/vm_kern.c:426
---Type return to continue, or q return to quit---
#12 0xc05f7e87 in page_alloc (zone=0xc0c3ba80, bytes=0, pflag=0x0, wait=0)
at ../../../vm/uma_core.c:845
#13 0xc05f7af9 in slab_zalloc (zone=0xc0c3ba80, wait=1)
at ../../../vm/uma_core.c:753
#14 0xc05f8e36 in uma_zone_slab (zone=0xc0c3ba80, flags=1)
at ../../../vm/uma_core.c:1539
#15 0xc05f908f in uma_zalloc_bucket (zone=0xc0c3ba80, flags=1)
at ../../../vm/uma_core.c:1635
#16 0xc05f8ca5 in uma_zalloc_arg (zone=0xc0c3ba80, udata=0x0, flags=1)
at ../../../vm/uma_core.c:1469
#17 0xc04b803c in malloc (size=2, type=0xc068e160, flags=1) at uma.h:234
#18 0xc046f598 in random_harvest_internal (somecounter=442778455129,
entropy=0x0, count=8, bits=0, frac=0, origin=RANDOM_INTERRUPT)
at ../../../dev/random/randomdev.c:370
#19 0xc046ed69 in random_harvest (entropy=0x0, count=0, bits=0, frac=0,
origin=RANDOM_START) at cpu.h:104
#20 0xc04ae642 in ithread_schedule (ithread=0x17a70c59, do_switch=1)
at ../../../kern/kern_intr.c:378
#21 0xc06264f9 in intr_execute_handlers (isrc=0xc06aec28, iframe=0x16)
at ../../../i386/i386/intr_machdep.c:206
#22 0xc06342d8 in atpic_handle_intr (iframe=
{if_vec = 14, if_fs = 24, if_es = 16, if_ds = 16, if_edi = -1060958048, if_esi =
-1060961344, if_ebp = -698411084, if_ebx = -1060960204, if_edx = 7, if_ec---Type
return to continue, or q return to quit---
x = 7, if_eax = -1060958048, if_eip = -1067552603, if_cs = 8, if_eflags = 582, if_esp
= -698411084, if_ss = -1067552851}) at ../../../i386/isa/atpic.c:335
#23 0xc06346ce in Xatpic_intr14 () at {standard input}:40
#24 0xc05e7499 in vm_map_insert (map=0xc0c303c0, object=0xc0c310a0,
offset=47181824, start=3267354624, end=3267358720, prot=7 '\a',
max=7 '\a', cow=0) at ../../../vm/vm_map.c:860
#25 0xc05e5c96 in kmem_malloc (map=0xc0c310a0, size=3234009248, flags=1027)
at ../../../vm/vm_kern.c:348
#26
Re: hard lock-up writing to tape
On Monday 17 November 2003 04:41 pm, Mike Durian wrote: I was finally able to get some partial success by setting flag 0x30 for sio1. When I'd boot, I'd get console messages on my remote tip session. However, I'd only receive those messages printed from user-level applications. I would not see any of the bold-face messages from the kernel. I'm still stumbling with the remote serial console. Can someone who does this often test and verify they can use COM2 as the serial console - and then tell me what you did. The best I can manage is described above and then I get neither the bold kernel messages nor the debugger prompt. mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Scott Long said: On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote: M. Warner Losh said: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : It really doesn't make sense to arbitrarily cut-off a : discussion especially when a decision might be incorrect. I'd say that good technical discussion about why this is wrong would be good. However, emotional ones should be left behind. Except for John's message, most of the earlier messages have been more emotional than technical. John, do you have any good set of benchmarks that people can run to illustrate your point? I'll see if I can find some of my old benchmarks (from memory, not disk -- lots of stuff has rotted away.). I had hoped to avoid doing much in the way of proof. Pointing to the much more complex process map along with the implication for significantly higher overhead :-). (The VM code generally gets slower with more complex process maps and more memory used. For smallish programs -- including those with a few shared libs, changing the VM code won't help much, because the cost is built in to the complexity of the process image.) I'm glad that real arguments are finally starting to surface =-) Our rationale for encouraging Gordon is as follows: 1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want to upgrade from 4-STABLE. Historically in 4.x, the / partition has been very modest in size. One just simply cannot cram the bloat that has grown in 5.x into a 4.x partition scheme. Of course there is the venerable 'dump - clean install - restore' scheme, but we were looking for something a little more user-friendly. /bin and /sbin don't need to contain everything :-). Adding a full featured /rescue should also help to counterbalance this (but maybe the upgrade would be selective?) There are reasons for /usr/bin and /usr/sbin (along with /usr/local, /usr/share.) Disk space is CHEAP and grandfathering 20MB hard drives (or the yr2000 equivalent of 4GB hard drives) is nice -- but repartitioning them with more reasonable root allocations seems like a good idea anyway :-). 50MB root was silly when 2-4GB disks were common. Continuing to pay for a poorly made partitioning decision in the past seems to be unworthy (in my opinion.) 2. NSS support out-of-the-box: Again, this is a user-experience issue in that forcing NSS users to recompile world was seen as a potential roadblock to them. The cool thing about properly implemented shared libs is that not everything has to be shared. Even the kernel supports runtime loading/addition of modules, and the NSS sounds like a good candidate for a library feature. Burdening everything with the sparse .data associated with libc seems to be a waste (but, perhaps the performance that was carefully crafted into the codebase is no longer important?) Really -- it is possible that performance isnt' important anymore, and fully accepting the ongoing loss of performance for features (without careful tradeoffs) might be an appropriate strategy. (In the case of the NSS stuff, it shouldn't require everything to be built dynamic.) 3. Binary security updates: there is a lot of interest in providing a binary update mechanism for doing security updates. Having a dynamic root means that vulnerable libraries can be updated without having to update all of the static binaries that might use them. The additional hole of exploiting the system through the shared libs is a negative tradeoff. 4. I've probably forgotten the other factors... As for performance, we felt that the typical use of FreeBSD did not fall into the category of doing forkbomb performance tests. Nope - even shell execution times (e.g. long shell scripts) will see a difference. Prejudicial comments like 'fork-bombs' and 'microbenchmarks' aren't really fair. Proper benchmarking is time consuming and analysis is tricky. System loading conditions are difficult to control (for experiments.) Note that alot of the lost performance is hidden by the VM code (e.g. one of the purposes for prezeroing on SMP box -- before SMP was fine grained.) The cost of sparse data and needless inheritance of modified pages has performance hits that are incredibly difficult to accurately (and honestly) measure. Anyone can create 'preordained' benchmark results. This is one reason why I am loathe to get into the FreeBSD performance game again -- it is much more difficult than a few micro-benchmarks :-) that simply measure a fork exec time. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
At 17:06 18/11/2003 -0700, Scott Long wrote: Our rationale for encouraging Gordon is as follows: 1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want to upgrade from 4-STABLE. Historically in 4.x, the / partition has been very modest in size. One just simply cannot cram the bloat that has grown in 5.x into a 4.x partition scheme. Of course there is the venerable 'dump - clean install - restore' scheme, but we were looking for something a little more user-friendly. Of course, making / dynamic results in added complication of removing old libraries from /usr/lib, now that some of them have moved to /lib... 3. Binary security updates: there is a lot of interest in providing a binary update mechanism for doing security updates. Having a dynamic root means that vulnerable libraries can be updated without having to update all of the static binaries that might use them. As far as I'm concerned, this is a non-issue. Identifying which static binaries need to be replaced is now a solved problem, replacing them is easy, and if binary patches are used, there is effectively no impact on bandwidth usage either. On the issue of performance, however: I know people have benchmarked fork-bombs, but has anyone done benchmarks with moderate numbers of long-lived, library-intensive, processes? It seems to me that dynamic linking could have caching advantages. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
[EMAIL PROTECTED] wrote: Scott Long said: On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote: M. Warner Losh said: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : It really doesn't make sense to arbitrarily cut-off a : discussion especially when a decision might be incorrect. I'd say that good technical discussion about why this is wrong would be good. However, emotional ones should be left behind. Except for John's message, most of the earlier messages have been more emotional than technical. John, do you have any good set of benchmarks that people can run to illustrate your point? I'll see if I can find some of my old benchmarks (from memory, not disk -- lots of stuff has rotted away.). I had hoped to avoid doing much in the way of proof. Pointing to the much more complex process map along with the implication for significantly higher overhead :-). (The VM code generally gets slower with more complex process maps and more memory used. For smallish programs -- including those with a few shared libs, changing the VM code won't help much, because the cost is built in to the complexity of the process image.) I'm glad that real arguments are finally starting to surface =-) Our rationale for encouraging Gordon is as follows: 1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want to upgrade from 4-STABLE. Historically in 4.x, the / partition has been very modest in size. One just simply cannot cram the bloat that has grown in 5.x into a 4.x partition scheme. Of course there is the venerable 'dump - clean install - restore' scheme, but we were looking for something a little more user-friendly. [snip] 2. NSS support out-of-the-box: Again, this is a user-experience issue in that forcing NSS users to recompile world was seen as a potential roadblock to them. [snip] 3. Binary security updates: there is a lot of interest in providing a binary update mechanism for doing security updates. Having a dynamic root means that vulnerable libraries can be updated without having to update all of the static binaries that might use them. [snip] 4. I've probably forgotten the other factors... As for performance, we felt that the typical use of FreeBSD did not fall into the category of doing forkbomb performance tests. One of ther things he might have forgot to mention is dynamic tricks releated to PAM, which sorta falls in the same league as NSS working out of the box. It was worth mentioning IMHO. Besides, I see nothing preventing anybody from building their system with static worlds, and there is nothing stopping anybody from putting /rescue in the PATH before /bin or /sbin. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build world question
Steve Kargl wrote: On Mon, Nov 17, 2003 at 11:12:20PM -0500, Jason wrote: I cvsuped an hour or so ago, now when I finish make buildworld I get: === usr.sbin/boot0cfg cc -O -pipe -march=athlon-xp -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.sbin/boot0cfg/boot0cfg.c cc -O -pipe -march=athlon-xp -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -o boot0cfg boot0cfg.o gzip -cn /usr/src/usr.sbin/boot0cfg/boot0cfg.8 boot0cfg.8.gz === etc No errors, thats it. I thought I should get this message too: make world completed on Is this a problem or normal? I just don't want to be half way into an update and have problems. Did you use a -j option to make? No, just the basic command. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
masta said: One of ther things he might have forgot to mention is dynamic tricks releated to PAM, which sorta falls in the same league as NSS working out of the box. It was worth mentioning IMHO. I guess that I have to remember that my own goals of 'performance' and handling 'highest workload' for efficient use of hardware isn't everyone's goal. However, PAM and NSS 'tricks' really seem to be exactly that, and certainly worthy of special builds. However, that isn't necessary, yet still not building everything with a shared libc. Note that none of this requires that libc be shared (libc and its ilk are the worst offenders.) Dynamic loading can certainly be used (if you want to load a wierd, special purpose, tricky module.) John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS-UP new statfs structure
On Tue, 18 Nov 2003, Rudolf Cejka wrote:
Hello, and is it possible to review some my (one's from masses :o)
questions/suggestions?
* cvtstatfs() for freebsd4_* compat syscalls does not copy text fields
correctly, so old binaries with new kernel know just about first
16 characters from mount points - what do you think about the
following patch? (Or maybe with even safer sizeof() - but I did not
test it.)
Hmm, there were 2 bugs here:
- MFSNAMELEN was confused with MNAMELEN in some places. This gives
unterminated strings as well as excessively truncated strings.
- there were off-by-1 errors which would have given unterminated
strings even without the previous bug.
--- sys/kern/vfs_syscalls.c.orig Sun Nov 16 11:12:09 2003
+++ sys/kern/vfs_syscalls.c Sun Nov 16 11:56:07 2003
@@ -645,11 +645,11 @@
osp-f_syncreads = MIN(nsp-f_syncreads, LONG_MAX);
osp-f_asyncreads = MIN(nsp-f_asyncreads, LONG_MAX);
bcopy(nsp-f_fstypename, osp-f_fstypename,
- MIN(MFSNAMELEN, OMNAMELEN));
+ MIN(MFSNAMELEN, OMFSNAMELEN - 1));
MFSNAMELEN didn't change, so there is currently only a logical problem
here. The -1 term could be moved outside of the MIN(). It works in
either place and would save duplicating the terminating NUL in the
unlikely event that the new name length becomes smaller than the old
one. I'm not sure which is clearest.
bcopy(nsp-f_mntonname, osp-f_mntonname,
- MIN(MFSNAMELEN, OMNAMELEN));
+ MIN(MNAMELEN, OMNAMELEN - 1));
Similarly, plus the larger bug. MNAMELEN increased from
(88 - 2 * sizeof(long)) to 88, so if it were used without the -1 in
the above, then mount point name lengths longer than the old value
would have been unterminated instead of truncated.
bcopy(nsp-f_mntfromname, osp-f_mntfromname,
- MIN(MFSNAMELEN, OMNAMELEN));
+ MIN(MNAMELEN, OMNAMELEN - 1));
Similarly.
if (suser(td)) {
osp-f_fsid.val[0] = osp-f_fsid.val[1] = 0;
} else {
---
* sys/compat/freebsd32/freebsd32_misc.c: If you look into copy_statfs(),
you copy 88-byte strings into just 80-byte strings. Fortunately it seems
that there are just overwritten spare fields and f_syncreads/f_asyncreads
before they are set to the correct value. What about these patches, which
furthermore are resistant to possible MFSNAMELEN change in the future?
[I'm sorry, these patches are untested]
--- sys/compat/freebsd32/freebsd32.h.orig Tue Nov 18 16:58:28 2003
+++ sys/compat/freebsd32/freebsd32.h Tue Nov 18 16:59:36 2003
@@ -75,6 +75,7 @@
int32_t ru_nivcsw;
};
+#define FREEBSD32_MFSNAMELEN 16 /* length of type name including null */
#define FREEBSD32_MNAMELEN(88 - 2 * sizeof(int32_t)) /* size of on/from
name bufs */
MFSNAMELEN hasn't changed, so this part is cosmetic. But don't we now need
to clone all of this compatibility cruft for the new statfs()? Native
32-bit systems have both. Then MFSNAMELEN for this version should probably
be spelled OMFSNAMELEN.
struct statfs32 {
@@ -92,7 +93,7 @@
int32_t f_flags;
int32_t f_syncwrites;
int32_t f_asyncwrites;
- charf_fstypename[MFSNAMELEN];
+ charf_fstypename[FREEBSD32_MFSNAMELEN];
charf_mntonname[FREEBSD32_MNAMELEN];
int32_t f_syncreads;
int32_t f_asyncreads;
--- sys/compat/freebsd32/freebsd32_misc.c.origTue Nov 18 16:59:49 2003
+++ sys/compat/freebsd32/freebsd32_misc.c Tue Nov 18 17:03:31 2003
@@ -276,6 +276,7 @@
static void
copy_statfs(struct statfs *in, struct statfs32 *out)
{
+ bzero(out, sizeof *out);
Yikes. All copied out structs that might have holes (i.e., all structs
unless you want to examine them in binary for every combination of
arch/compiler/etc) need to be bzero()ed like this, but there are no
bzero()'s in files in this directory.
CP(*in, *out, f_bsize);
CP(*in, *out, f_iosize);
CP(*in, *out, f_blocks);
@@ -290,14 +291,14 @@
CP(*in, *out, f_flags);
CP(*in, *out, f_syncwrites);
CP(*in, *out, f_asyncwrites);
- bcopy(in-f_fstypename,
- out-f_fstypename, MFSNAMELEN);
- bcopy(in-f_mntonname,
- out-f_mntonname, MNAMELEN);
+ bcopy(in-f_fstypename, out-f_fstypename,
+ MIN(MFSNAMELEN, FREEBSD32_MFSNAMELEN - 1));
+ bcopy(in-f_mntonname, out-f_mntonname,
+ MIN(MNAMELEN, FREEBSD32_MNAMELEN - 1));
CP(*in, *out, f_syncreads);
CP(*in, *out, f_asyncreads);
- bcopy(in-f_mntfromname,
- out-f_mntfromname, MNAMELEN);
+ bcopy(in-f_mntfromname, out-f_mntfromname,
+ MIN(MNAMELEN, FREEBSD32_MNAMELEN - 1));
}
int
This seems to be correct except possibly for the style (placement of -1
and fixing the indentation of the continuation lines so that it is not
bug-for-bug compatible with the rest of the file).
---
* sys/ia64/ia32/ia32.h: It seems to me that statfs32 has similar
Re: Unfortunate dynamic linking for everything
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote: Scott Long said: On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote: M. Warner Losh said: In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : It really doesn't make sense to arbitrarily cut-off a : discussion especially when a decision might be incorrect. I'd say that good technical discussion about why this is wrong would be good. However, emotional ones should be left behind. Except for John's message, most of the earlier messages have been more emotional than technical. John, do you have any good set of benchmarks that people can run to illustrate your point? I'll see if I can find some of my old benchmarks (from memory, not disk -- lots of stuff has rotted away.). I had hoped to avoid doing much in the way of proof. Pointing to the much more complex process map along with the implication for significantly higher overhead :-). (The VM code generally gets slower with more complex process maps and more memory used. For smallish programs -- including those with a few shared libs, changing the VM code won't help much, because the cost is built in to the complexity of the process image.) I'm glad that real arguments are finally starting to surface =-) Our rationale for encouraging Gordon is as follows: 1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want to upgrade from 4-STABLE. Historically in 4.x, the / partition has been very modest in size. One just simply cannot cram the bloat that has grown in 5.x into a 4.x partition scheme. Of course there is the venerable 'dump - clean install - restore' scheme, but we were looking for something a little more user-friendly. /bin and /sbin don't need to contain everything :-). Adding a full featured /rescue should also help to counterbalance this (but maybe the upgrade would be selective?) There are reasons for /usr/bin and /usr/sbin (along with /usr/local, /usr/share.) Disk space is CHEAP and grandfathering 20MB hard drives (or the yr2000 equivalent of 4GB hard drives) is nice -- but repartitioning them with more reasonable root allocations seems like a good idea anyway :-). 50MB root was silly when 2-4GB disks were common. Continuing to pay for a poorly made partitioning decision in the past seems to be unworthy (in my opinion.) /boot has grown quite large too and threatens to be unbounded in size as times go on. Shaving off the 30-40MB of size in /bin and /sbin can help alleviate this, even on system formatted in 5.x partition sized. This argument wasn't the most compelling one by itself, but it played a part in the decision so I included it here. 2. NSS support out-of-the-box: Again, this is a user-experience issue in that forcing NSS users to recompile world was seen as a potential roadblock to them. The cool thing about properly implemented shared libs is that not everything has to be shared. Even the kernel supports runtime loading/addition of modules, and the NSS sounds like a good candidate for a library feature. Burdening everything with the sparse .data associated with libc seems to be a waste (but, perhaps the performance that was carefully crafted into the codebase is no longer important?) Really -- it is possible that performance isnt' important anymore, and fully accepting the ongoing loss of performance for features (without careful tradeoffs) might be an appropriate strategy. (In the case of the NSS stuff, it shouldn't require everything to be built dynamic.) Unfortunately, our dynamic linker prevents dlopen() and friends from working in a static binary. There was some talk about having NSS lookups happen through a proxy process, but our implementation just plain wasn't done that way, and no one has stepped forward with alternate code. NSS modules can affect a surprisingly large number of utilities, including the shells. Selectively choosing which utilities to link static vs. shared would have resulted in quite a patchy result that probably would not have had a significant benefit. 3. Binary security updates: there is a lot of interest in providing a binary update mechanism for doing security updates. Having a dynamic root means that vulnerable libraries can be updated without having to update all of the static binaries that might use them. The additional hole of exploiting the system through the shared libs is a negative tradeoff. Exploits in libraries happen though. The LD_LIBRARY_PATH attack is an old one that most Unixes are hopefully hardened against. 4. I've probably forgotten the other factors... As for performance, we felt that the typical use of FreeBSD did not fall into the category of doing forkbomb performance tests. Nope - even shell execution times (e.g. long shell scripts) will see a difference.
Re: HEADS-UP new statfs structure
On Fri, Nov 14, 2003 at 08:33:06AM +, Matt Smith wrote: Marco Wertejuk wrote: Just for a short note: cfsd (ports/security/cfs) should be recompiled as well after those statfs changes. And mail/postfix and devel/gnomevfs2 (ones's i've found so far) I think this was reported earlier, but I couldn't find the e-mail. I just confirmed that OpenOffice ( editors/openoffice port ) also needs to be recompiled due to the statfs changes. I just ran it now and it crashed: (gdb) where #0 0x2860742b in osl_psz_getVolumeInformation () from /usr/local/OpenOffice.org1.0/program/libsal.so.3 -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build world question
Dag-Erling Smørgrav wrote: Jason [EMAIL PROTECTED] writes: I cvsuped an hour or so ago, now when I finish make buildworld I get: === usr.sbin/boot0cfg cc -O -pipe -march=athlon-xp -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/usr.sbin/boot0cfg/boot0cfg.c cc -O -pipe -march=athlon-xp -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -o boot0cfg boot0cfg.o gzip -cn /usr/src/usr.sbin/boot0cfg/boot0cfg.8 boot0cfg.8.gz === etc This is normal behaviour and has been for ages. No errors, thats it. I thought I should get this message too: make world completed on You didn't ask it to do 'make world', so it didn't tell you that 'make world' was completed. DES I told it to make buildworld, do I also need to tell it make world? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
Harald Schmalzbauer wrote: On Tuesday 18 November 2003 18:58, you wrote: On Tue, 18 Nov 2003, Harald Schmalzbauer wrote: On Tuesday 18 November 2003 03:37, you wrote: Sorry I wasn't more clear. I need you to print the contents like this: print *cpu_cx_count cpu_cx_count 1 cpu_cx_lowest 0 cpu_idle_hook c0468300 cpu_cx_next 0 I hope these are the correct values. Thanks, those are the correct values for your box. I just posted a patch that should address the boot-time panic. Please revert old patches and try it. Yep, this looks good. Perhaps you're interested in the following line which arose for the first time during boot: C0? cx_next 0 cx_count 1 And here is what you requested in your first patch: cale:~ sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 0/0 Ok - what do I need to do to try this new acpi stuff out? I'm running -current as of Nov 14th, and I'd like to help debug/test this on my notebook.. Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
At 8:07 AM -0500 11/18/03, [EMAIL PROTECTED] wrote: It really doesn't make sense to arbitrarily cut-off a discussion especially when a decision might be incorrect. All I wanted to cut off was the claim that this decision had not been discussed publicly before. It was also annoying that most the recent complaints (before your message) were issues that had been explicitly discussed and addressed before the decision had been reached. Many people seem to be complaining on what they think we did, as opposed to what we actually did. If there hadn't been a noticed increase in cost by using all-shared-libs, then the measurements were done incorrectly. If the decision is made based upon allowing for 1.5X (at least) times increase in fork/exec times, and larger memory usage (due to sparse allocations), ... I do remember some comments about benchmarks, and it was true that the all-dynamic bin/sbin does come out slower. I don't remember if the benchmarks were ours or from NetBSD's investigation. However, I think we measured increase in overall time for some set of commands, instead of increase in the fork() routine. Thus, the penalty observed was much less than 50%. I think it was under 2%, but I don't remember the exact number. When we're dealing with a 100% increase in the cost of compiling something with the newer gcc, the increase due to this change seemed pretty insignificant... It is probably true that there are several commands where we would see a worthwhile performance benefit by static linking, and which have no need for things like dynamic PAM modules. But commands which care about userids or group information would need to stay dynamic (IMO), and I think that means all shells. Also, when it comes to security fixes, it would be nice for binary upgrades if all we had to do was replace one library, instead of replacing every command which is statically-linked with the problem routine. The announcement of this change may have played up disk-savings more than it should have, because we weren't doing this to save disk space. It was just that the disk savings were a very nice side-effect. It's pretty rare that we can talk about the system getting smaller!:-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Multifunction USB devices
I have an Epson printer/scanner combo device (CX5200) which works just fine either as a printer or as a scanner (when I add the vendor and product codes to usbdevs and uscanner.c) but not both simultaneously. Currently I compile ulpt and my customized uscanner as modules, and to switch functions I power the device off, unload/load the appropriate kernel module, and power the device back on. I'm assuming a patch to add the CX5200 vendor/device codes to usbdevs and uscanner.c in the way I'm doing wouldn't be accepted into CURRENT since the resulting usage of it is a bit of a hack. Is that right? I wouldn't mind doing work over the next few months to create proper simultaneous support for both devices if it can be done with a reasonable level of effort and I can find some sources of information, and I can get some guidance from an experienced committer or architect to help do it right the first time. Where should I go for discussion? I'd like to learn ie. should I work to combine ulpt and uscanner into some kind of single umulti type of device driver, or should a virtual hub device of some kind be created to support both ulpt and uscanner simultaneously as-is (one USB endpoint, multiple interfaces), or should the system simply continue searching after matching a USB device, or will this be OBE with some other USB work going on, etc. Thanks, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
At 6:42 PM -0600 11/18/03, masta wrote: Besides, I see nothing preventing anybody from building their system with static worlds, true... and there is nothing stopping anybody from putting /rescue in the PATH before /bin or /sbin. Note that this will not have the same performance as the older all-static setup, because each binary in /rescue is a crunchgen'ed combination of *all* the commands there. They're all hardlinked together. Eg: (332) # ls -l /bin/cp /rescue/cp -r-xr-xr-x1 root wheel 113372 Nov 16 02:29 /bin/cp* -r-xr-xr-x 131 root wheel 3807836 Nov 16 02:30 /rescue/cp* I have no idea what kind of a difference that would make, I'm just saying that it is different... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Wednesday 19 November 2003 02:09, Eric Anderson wrote:
Harald Schmalzbauer wrote:
On Tuesday 18 November 2003 18:58, you wrote:
On Tue, 18 Nov 2003, Harald Schmalzbauer wrote:
On Tuesday 18 November 2003 03:37, you wrote:
Sorry I wasn't more clear. I need you to print the contents like this:
print *cpu_cx_count
cpu_cx_count 1
cpu_cx_lowest 0
cpu_idle_hook c0468300
cpu_cx_next 0
I hope these are the correct values.
Thanks, those are the correct values for your box. I just posted a patch
that should address the boot-time panic. Please revert old patches and
try it.
Yep, this looks good. Perhaps you're interested in the following line
which arose for the first time during boot:
C0? cx_next 0 cx_count 1
And here is what you requested in your first patch:
cale:~ sysctl hw.acpi.cpu
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: 0
hw.acpi.cpu.cx_history: 0/0
Ok - what do I need to do to try this new acpi stuff out? I'm running
-current as of Nov 14th, and I'd like to help debug/test this on my
notebook..
Try the patch Nate posted in Updated acpi_cpu patch. For convinience I
attached it. That's all I can tell you.
-Harry
Eric
Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.19
diff -u -r1.19 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 - 1.19
+++ sys/dev/acpica/acpi_cpu.c 18 Nov 2003 17:46:23 -
@@ -1,5 +1,5 @@
/*-
- * Copyright (c) 2003 Nate Lawson
+ * Copyright (c) 2003 Nate Lawson (SDG)
* Copyright (c) 2001 Michael Smith
* All rights reserved.
*
@@ -77,9 +77,11 @@
device_t cpu_dev;
ACPI_HANDLE cpu_handle;
uint32_t cpu_id; /* ACPI processor id */
+uint32_t cpu_p_blk; /* ACPI P_BLK location */
+uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */
struct resource *cpu_p_cnt; /* Throttling control register */
struct acpi_cx cpu_cx_states[MAX_CX_STATES];
-int cpu_bm_ok; /* Bus mastering control available. */
+int cpu_cx_count; /* Number of valid Cx states. */
};
#define CPU_GET_REG(reg, width) \
@@ -116,10 +118,9 @@
#define PCI_REVISION_4M 3
/* Platform hardware resource information. */
-static uint32_t cpu_p_blk; /* ACPI P_BLK location */
-static uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */
static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */
static uint8_t cpu_pstate_cnt;/* Register to take over throttling. */
+static uint8_t cpu_cst_cnt; /* Indicate we are _CST aware. */
static uint32_t cpu_rid; /* Driver-wide resource id. */
static uint32_t cpu_quirks; /* Indicate any hardware bugs. */
@@ -146,11 +147,13 @@
static int acpi_cpu_probe(device_t dev);
static int acpi_cpu_attach(device_t dev);
+static int acpi_cpu_detach(device_t dev);
static int acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
static void acpi_cpu_startup(void *arg);
static void acpi_cpu_startup_throttling(void);
+static void acpi_cpu_startup_cx(void);
static void acpi_cpu_throttle_set(uint32_t speed);
static void acpi_cpu_idle(void);
static void acpi_cpu_c1(void);
@@ -166,6 +169,7 @@
/* Device interface */
DEVMETHOD(device_probe, acpi_cpu_probe),
DEVMETHOD(device_attach, acpi_cpu_attach),
+DEVMETHOD(device_detach, acpi_cpu_detach),
{0, 0}
};
@@ -178,6 +182,7 @@
static devclass_t acpi_cpu_devclass;
DRIVER_MODULE(acpi_cpu, acpi, acpi_cpu_driver, acpi_cpu_devclass, 0, 0);
+
static int
acpi_cpu_probe(device_t dev)
{
@@ -272,11 +277,10 @@
AcpiEvaluateObject(sc-cpu_handle, _INI, NULL, NULL);
/* Get various global values from the Processor object. */
-cpu_p_blk = pobj.Processor.PblkAddress;
-cpu_p_blk_len = pobj.Processor.PblkLength;
+sc-cpu_p_blk = pobj.Processor.PblkAddress;
+sc-cpu_p_blk_len = pobj.Processor.PblkLength;
ACPI_DEBUG_PRINT((ACPI_DB_IO, acpi_cpu%d: P_BLK at %#x/%d%s\n,
- device_get_unit(dev), cpu_p_blk, cpu_p_blk_len,
- sc-cpu_p_cnt ? : (shadowed)));
+ device_get_unit(dev), sc-cpu_p_blk, sc-cpu_p_blk_len));
acpi_sc = acpi_device_get_parent_softc(dev);
sysctl_ctx_init(acpi_cpu_sysctl_ctx);
@@ -297,7 +301,8 @@
if (thr_ret == 0 || cx_ret == 0) {
status = AcpiInstallNotifyHandler(sc-cpu_handle, ACPI_DEVICE_NOTIFY,
acpi_cpu_notify, sc);
- AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, sc);
+ if (device_get_unit(dev) == 0)
+ AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, NULL);
} else {
sysctl_ctx_free(acpi_cpu_sysctl_ctx);
}
@@ -306,6 +311,21 @@
}
static int
+acpi_cpu_detach(device_t dev)
+{
+
+/* Disable any entry to the idle function. */
+cpu_cx_count = 0;
+
+#ifdef SMP
+/* Wait for all processors to exit acpi_cpu_idle(). */
+
Re: Unfortunate dynamic linking for everything
On Wed, 19 Nov 2003, Colin Percival wrote: At 17:06 18/11/2003 -0700, Scott Long wrote: Our rationale for encouraging Gordon is as follows: 1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want to upgrade from 4-STABLE. Historically in 4.x, the / partition has been very modest in size. One just simply cannot cram the bloat that has grown in 5.x into a 4.x partition scheme. Of course there is the venerable 'dump - clean install - restore' scheme, but we were looking for something a little more user-friendly. Of course, making / dynamic results in added complication of removing old libraries from /usr/lib, now that some of them have moved to /lib... The magic for solving this exact problem already exists in the source upgrade path. Fixing this for the binary upgrade path (via sysinstall) is still under investigation. It is mitigated by the fact the systems that are binary-upgraded have their library search path set to look at /lib first. Leaving around stale libraries is of course bad, and we will hopefully come up with a solution soon. 3. Binary security updates: there is a lot of interest in providing a binary update mechanism for doing security updates. Having a dynamic root means that vulnerable libraries can be updated without having to update all of the static binaries that might use them. As far as I'm concerned, this is a non-issue. Identifying which static binaries need to be replaced is now a solved problem, replacing them is easy, and if binary patches are used, there is effectively no impact on bandwidth usage either. Bandwidth is still a concern for a lot of people, and this has the potential to save significant bandwidth in many situations. On the issue of performance, however: I know people have benchmarked fork-bombs, but has anyone done benchmarks with moderate numbers of long-lived, library-intensive, processes? It seems to me that dynamic linking could have caching advantages. Colin Percival I can't comment well here. To my untrained mind, I would think that more sharing of libc would help with memory pressure, but I'm just making simple assumptions. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Scott Long said: On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote: The cool thing about properly implemented shared libs is that not everything has to be shared. Even the kernel supports runtime loading/addition of modules, and the NSS sounds like a good candidate for a library feature. Burdening everything with the sparse .data associated with libc seems to be a waste (but, perhaps the performance that was carefully crafted into the codebase is no longer important?) Really -- it is possible that performance isnt' important anymore, and fully accepting the ongoing loss of performance for features (without careful tradeoffs) might be an appropriate strategy. (In the case of the NSS stuff, it shouldn't require everything to be built dynamic.) Unfortunately, our dynamic linker prevents dlopen() and friends from working in a static binary. There was some talk about having NSS lookups happen through a proxy process, but our implementation just plain wasn't done that way, and no one has stepped forward with alternate code. It seems like the defect is with the old limitation on the dlopen things then. (That limitation has been operative for years.) Making that decision 6months ago (or whenever the decision was made) seems to result in sidestepping the best solution (esp when 6months is alot of time to fix such limitations.) Again, I cannot take the responsibility, and mostly trying to keep 'improvements' from undoing previous work. I am worried (really) that there'll be a progressive loss of performance in order to gain features that could have been implemented with less impact. There was ALOT of work in trying to make FreeBSD very performant, and throwing that away with incrementalism seems to be wasteful. I am NOT meaning to negatively criticize, because that is quite seductive, and I am NOT suggesting that FreeBSD should have the Plan9 mimalist ethic. :-). Favorite 'tricky' features will come and go -- but basic system performance gets harder and hard to recover as time goes on!!! I guess that all OSes have a size/performance curve where they get bigger and fatter, SOMETIMES (not always) losing previous attributes for new features. Just don't let the performance loss go too far. IMO, I wouldn't have supported everything be built shared if there was a POTENTIAL mitigating solution of a proper dlopen implementation. DG would likely have had a 'fit.' Perhaps there should be a FreeBSD performance (and footprint) responsibility officer before it becomes too bloated to recover? :-). John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Tue, 18 Nov 2003, Eric Anderson wrote: And here is what you requested in your first patch: cale:~ sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 0/0 Ok - what do I need to do to try this new acpi stuff out? I'm running -current as of Nov 14th, and I'd like to help debug/test this on my notebook.. cvsup to -current as of today would be a good first start. The code was committed Nov 15. Then boot with acpi enabled and post the output of sysctl hw.acpi.cpu. You can try different levels by doing sysctl hw.acpi.cpu.cx_lowest=x where x is 0...(number_supported_states - 1) -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Tue, Nov 18, 2003 at 08:03:23PM -0500, [EMAIL PROTECTED] wrote: However, PAM and NSS 'tricks' really seem to be exactly that, and certainly worthy of special builds. However, that isn't necessary, yet still not building everything with a shared libc. Things like nss_ldap (which is used *heavily* at my place of employment) are some reasons that FreeBSD doesn't make it into more places. It was the reason why FreeBSD isn't being used here. Calling them 'tricks' (and succumbing to the name calling you wanted to avoid) doesn't change the fact that every major contender (IRIX, Solaris, Linux to name a few) all support this feature set. -gordon pgp0.pgp Description: PGP signature
Re: Unfortunate dynamic linking for everything
Gordon Tetlow said: On Tue, Nov 18, 2003 at 08:03:23PM -0500, [EMAIL PROTECTED] wrote: However, PAM and NSS 'tricks' really seem to be exactly that, and certainly worthy of special builds. However, that isn't necessary, yet still not building everything with a shared libc. Things like nss_ldap (which is used *heavily* at my place of employment) are some reasons that FreeBSD doesn't make it into more places. It was the reason why FreeBSD isn't being used here. Calling them 'tricks' Firstly -- I was answering back the 'tricks' comment made that you had elided :-). Please quote the message that set-up the context for the usage. (and succumbing to the name calling you wanted to avoid) doesn't change the fact that every major contender (IRIX, Solaris, Linux to name a few) all support this feature set. As discussed before, it DEFINITELY isn't necessary to dynamically link EVERYTHING to implement your favorite feature. Not everyone needs PAM/NSS, even though everyone needs memory management and scarce resource allocation. Why build in the overhead for everyone, and make it UNNCESSARILY worse (e.g. dynamically link libc when you want NSS or PAM?) Of course, there was a development resource limitation, but the decision (discussion) was made approx 6months ago? (Enough time to solve the problem without a GLOBAL performance hit.) John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
:Our rationale for encouraging Gordon is as follows: : :1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want :to upgrade from 4-STABLE. Historically in 4.x, the / partition has :been very modest in size. One just simply cannot cram the bloat that :has grown in 5.x into a 4.x partition scheme. Of course there is the :venerable 'dump - clean install - restore' scheme, but we were looking :for something a little more user-friendly. This argument would apply to very old 4.x users but not to anyone who installed it as of March 2001. I bumped the nominal size of the root partition to 128MB in 1.98.2.7 of sysinstall/label.c. Prior to that Jordan had bumped the root partition size to 100MB in 1.98.2.3 in March 2001. It was 50MB before then, which is too small even for 4.x. :2. NSS support out-of-the-box: Again, this is a user-experience issue :in that forcing NSS users to recompile world was seen as a potential :roadblock to them. Users have to recompile the world anyway, I don't think NSS is an issue. Or to put it another way: Nobody in their right mind should be contemplating upgrading a 4.x system to 5.x for production purposes. There will simply be too much 4.x cruft left over. Upgrading really requires a wipe and reinstall in this instance. I seem to recall that the main reason 5.x went to a dynamic /bin was to work around a terribly broken PAM design. The other issues were just eye candy compared to the PAM problems. Personally speaking, I think the solution is to fix PAM instead :-) :3. Binary security updates: there is a lot of interest in providing a :binary update mechanism for doing security updates. Having a dynamic :root means that vulnerable libraries can be updated without having to :update all of the static binaries that might use them. Non-issue if you have an automatic security update mechanism or script to do the work for the user, which we don't. Even so, /bin and /sbin are sufficiently self-contained in the source hierarchy that recompiling and reinstalling them is not a big deal. I think the security argument is a red-herring because, frankly, security problems are far more prevalient with ports and larger services (Apache, sendmail, sshd, etc... mostly in /usr/bin and /usr/local), and not as big an issue for /bin and /sbin. :As for performance, we felt that the typical use of FreeBSD did not fall :into the category of doing forkbomb performance tests. While there might :certainly be users that do continuously create lots of short-lived :processes, we felt that the above benefits outweighed this, but left the :door open for tailoring to this need (recompiling world with :NO_DYNAMICROOT). fork() is a non-issue (forking overhead for a dynamic executable imposes a slight time penalty but does not really impose any resource penalty). However, I personally believe that anything run by a shell script is an issue in regards to performance, and anything you exec multiple separate copies of is an issue in regards to memory overhead. A system running a large number of JAIL'd environments will wind up with a larger number of swap-managed dirty pages. But, all this aside, the reason I am decidedly against a dynamic /bin is simply one of system recovery and safety. I've blown up /usr so many times over the years that had /bin and /sbin been dynamic I would have been in real trouble on many occassions. If I recall correctly, some people have proposed and/or implemented some sort of emergency fall back or safety bin in 5.x to make up for this issue. I would humbly submit that this simply acknowledges that a dynamic /bin and /sbin is a bad idea in the first place. I do not intend to make /bin or /sbin dynamic in DragonFly by default. I don't mind adding support for those people who want it, but I am not going to make it the default. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
: :As far as I'm concerned, this is a non-issue. Identifying which static : binaries need to be replaced is now a solved problem, replacing them is : easy, and if binary patches are used, there is effectively no impact on : bandwidth usage either. : :Bandwidth is still a concern for a lot of people, and this has the :potential to save significant bandwidth in many situations. :.. :Scott I would not consider this a viable argument since binary downloads are usually compressed. A compressed /bin stacks up as follows (from 4.x): -rw-r--r-- 1 root wheel 4034560 Nov 18 18:34 /tmp/x1.tar static -rw-r--r-- 1 root wheel 849920 Nov 18 18:34 /tmp/x2.tar dynamic -rw-r--r-- 1 root wheel 1860215 Nov 18 18:34 /tmp/x1.tgz static -rw-r--r-- 1 root wheel 354576 Nov 18 18:34 /tmp/x2.tgz dynamic So you are talking about 1.5 MBytes less bandwidth, which is nothing compared to the cost of doing a full install over the net. Yah, yah, /sbin too... but you get the idea. It certainly isn't enough of a difference to justify going to a dynamic /bin and /sbin. I'm not saying there aren't other arguments, just that this isn't one of them. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
:/boot has grown quite large too and threatens to be unbounded in size as :times go on. Shaving off the 30-40MB of size in /bin and /sbin can :help alleviate this, even on system formatted in 5.x partition sized. :... :This argument wasn't the most compelling one by itself, but it played a :part in the decision so I included it here. You aren't saving that much. I don't have a 5.x box handy but on a 4.x box a static /bin is only 4MB and /sbin is only 12MB. The dynamic versions will save you around 12MB is my guess. -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
Gang, I suspect that my position has been expressed adequately. Further discussion might become divisive, but a decision that incurs the overhead of performance or a rebuild on the default user base seems wrong (JUST MY OPINION.) It took ALOT of WORK (person years) to make FreeBSD perform as well as it does. BOTH the add-on crew and the general user base can have the performance and feature set without rebuilding, but the decision was apparently made to impose the cost of performance or rebuild and binary maintenance on the default user base. It makes more sense to have appropriately upgraded the system (by the NSS project) to avoid the performance hit by others and also provide the feature set. Apparently (I haven't fully analysed this) implementing the dlopen stuff for non-dynamic programs would have helped to mitigate this issue. (It might have put more burden on the NSS/PAM/whatever addon projects, but those are indeed addons that shouldn't take ANYTHING away from the rest of the project.) I am suggesting that the NSS crew and those who are concerned about performance can BOTH have the results that they wish for. 'All or nothing' creates divisiveness, and in these discussions it is TOO EASY to fall into that trap. I am not suggesting the loss of the new NSS stuff, but also suggest that ANY loss of performance when it can be avoided, is unwise. My opinion is known, and hopefully the loss of hard earned performance with person-years of work won't happen as time goes on. A little loss isn't that bad, but how much loss is too much loss (esp when not necessary?) EOT John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
At 6:38 PM -0800 11/18/03, Matthew Dillon wrote: So you are talking about 1.5 MBytes less bandwidth, which is nothing compared to the cost of doing a full install over the net. Yah, yah, /sbin too... but you get the idea. Many freebsd users (me for one) are still living on a modem, where even one bump of 1.5 meg is a significant issue... Remember that the issue we're talking about is security updates, not full system upgrades. Everyone would want the security updates, even if they're on a slow link. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote: There might be a certain 'coolness' WRT dynamically linking everything, but the overhead is certainly measurable. If the object is to maximally 'share', then for shells the FreeBSD VM shares maximally without using shared libs (perhaps there is a lost know-how about how aggressively the FreeBSD VM implements parent/child and exec based sharing?) I'll try to put together a few simple benchmarks -- mostly from my defective memory. I had recently refreshed myself on this issue (but lost again due to disk hardware disasters and being clobbered by vinum problems -- which I have given up on.) Gimme a day or so -- I have several other things in my queue. I guess one of the key observations to make here is that the vast majority of applications in FreeBSD have been dynamically linked for years. The only thing that has changed recently is a few binaries in /bin and /sbin. Of these binaries, the vast majority are never run for most systems, are run once during boot, or extremely infrequently in response to an administrative action where minor differences in latency will be unnoticeable. This would include applications like ping, mount_*, fsirand, newfs, swapon, kldload, chflags, rcorder, quotacheck, etc. The once during boot case is interesting in the aggregate, but most of the binaries in question should probably have been linked dynamically long ago simply because there's no real benefit to making them statically linked. So I think this leaves three interesting cases: (1) Shells, which are run for extended periods of time, and which are often run in a large number (propotional to #users logged in, or #windows open). I'm not to interested in this argument simply because the applications most people are interested in using FreeBSD for are already dynamically linked: Apache, databases, perl, XWindows, KDE, ... The vast majority of long-lived processes are already dynamically linked. (2) Shells again, because they will be fork()d and exec()d frequently during heavily scripted activities, such as system boot, periodic events, large make jobs, etc. And presumably the only shell of interest is sh, although some of the supporting non-builtin binaries may also be of interest. (3) Other binaries, such as mount_*, etc, which aren't run very often, but when they are run, will be run in aggregate with many other similar binaries, such as during system boot. The cost of one binary going dynamic is presumably extremely small, but if you suddenly make many binaries dynamic, it's presumably much more noticeable. Some macrobenchmark results that would probably be interesting to see (some of which I know have already been looked at as part of this discussion): - With a move to rcNG (/etc/rc.d), our boot process is now probably quite a bit more sensitive to the net performance change from dynamic linking. This would be at least one benchmark that would be interesting to look at (and I understand has been looked at by those exploring dynamic linking). - The impact on large multi-part build tasks, such as buildworld, is also interesting. Turning on process accounting shows that 'sh' is run by make(1) once for each task it spawns off during the build. A macrobenchmark would be helpful to look at whether there's a positive or negative impact. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
At 21:54 18/11/2003 -0500, Garance A Drosihn wrote: Many freebsd users (me for one) are still living on a modem, where even one bump of 1.5 meg is a significant issue... Remember that the issue we're talking about is security updates, not full system upgrades. Everyone would want the security updates, even if they're on a slow link. If people rebuild from source, the binary sizes don't affect the update time. If people use FreeBSD Update -- which is the only binary security update tool around -- then they're using binary patches, and that 1.5MB is actually closer to 10 kb. The bandwidth usage associated with updating a system is only a concern for people who roll their own binary update mechanism -- and those people aren't likely to be doing everything over a modem. Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
:Many freebsd users (me for one) are still living on a modem, :where even one bump of 1.5 meg is a significant issue... : :Remember that the issue we're talking about is security :updates, not full system upgrades. Everyone would want :the security updates, even if they're on a slow link. : :-- :Garance Alistair Drosehn= [EMAIL PROTECTED] I really have to disagree with this comment. By your reasoning saving a few bytes could be argued as being 'significant'. I've done net installs over slow modems before.. hell, I ran cvsup over a slow modem for over a year! My problem was never / or /bin. Not once. Not ever. I really don't care about a measily few megabytes relative to the size of the whole dist, and I doubt modem users of today care much either when you put it in that perspective. Sure, if you could save 50% of the bandwidth over the whole dist it would be significant. But 12 MBytes? No. The reason your argument make little sense is that there are plenty of OTHER ways you can make modem user's lives easier that have not been implemented. We aren't talking about a few measily megabytes here, we are talking about not making modem users have to wait sitting in front of their terminal staring at a slow download for hours before they even know whether their system will boot the dist! A two-stage install... basic kernel and /, reboot, then install the rest, would have a major impact on modem users. A thousand times greater impact then the few measily megabytes. Modem users don't mind waiting as long as they don't have to sit in front of the terminal while doing so. Once a basic dist is up and running on a modem user's machine believe me, they will happily go off and do something else while waiting for the rest of the bits to download and install because they know if something blows up they won't have to start all over again. -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
I just thought I would chime in on this heated debate and maybe add a little gasoline or at least a few oily rags. :-) For what it's worth, I've been running FreeBSD literally since before its inception, when it was merely a collection of patches to 386BSD 0.1. I'm also a longtime kernel guy so I do have a bit of a professional opinion. I tend to think that making the binaries in / dynamic is a bad idea. It is one of those that is floated from time to time, and ends up being voted down, often after someone has to recover a hosed system without having the appropriate shared libraries available. It seems like a good idea on the surface, but I really think it's an if it ain't broke, don't fix it situation. The amount of space it will save is trivial relative to the size of modern disks and the size of the rest of the distribution. I really don't care that much about how fast the system boots; even if you slowed it to half its current speed it would still be much faster than anything Microsoft has produced. If you're upgrading security libraries (or whatever), it's really as easy to upgrade the binaries in /bin and /sbin as it is to replace the libraries. There's just not that much there. Both Matt and John are right. You guys are trying to solve a non-problem. Please don't. There are much better things on which to spend your time. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hard lock-up writing to tape
On Tue, 18 Nov 2003, Mike Durian wrote: On Monday 17 November 2003 04:41 pm, Mike Durian wrote: I was finally able to get some partial success by setting flag 0x30 for sio1. When I'd boot, I'd get console messages on my remote tip session. However, I'd only receive those messages printed from user-level applications. I would not see any of the bold-face messages from the kernel. I'm still stumbling with the remote serial console. Can someone who does this often test and verify they can use COM2 as the serial console - and then tell me what you did. Moving the 0x10 flag from sio0 to sio1 should be sufficient for the kernel part. Setting the 0x20 flag for sio1 together with the 0x10 flag should mainly save having to edit the flag for sio0. If the kernel's serial console is the same as the boot blocks', then it should use the same speed as the boot blocks set it too. Otherwise there may be a speed mismatch. The best I can manage is described above and then I get neither the bold kernel messages nor the debugger prompt. This could be from a speed mismatch or from kern.consmute somehwo getting set. Some of this stuff can be configured after booting: - RELENG4 has non-broken boot-time configuration which allows changing during the boot. - -current has the kern.console sysctl for enabling multiple consoles (buut only 1 sio one). You can boot with a syscons console and then enable the serial, and the latter should work if it is on a working port to begin with. Anyway, this sysctl shows which sio port can be a console, if any. - RELENG_4 and -current have the machdep.conspeed sysctl for setting the console speed. Bruce ___ [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
After CVSup'ing to latest source, it can be reproduced. It happens at
make release. /mnt below may indicates this happened at making
floppies with mfs filesystem.
- serial console
/mnt: correcting fs_sblockloc from 8192 to 65536
panic: vm_fault: fault on nofault entry, addr: daef5000
cpuid = 0;
Debugger(panic)
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db trace
Debugger(c075e5bd,0,c0777dc0,ece63608,100) at Debugger+0x55
panic(c0777dc0,daef5000,1,ece636b8,ece636a8) at panic+0x156
vm_fault(c1031000,daef5000,1,0,c8f21500) at vm_fault+0x122e
trap_pfault(ece6379c,0,daef5000,c07617f2,daef5000) at trap_pfault+0x152
trap(ece60018,c0550010,c0810010,cacfa000,daef5000) at trap+0x313
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc0699384, esp = 0xece637dc, ebp = 0xece637f0 ---
ffs_load_inode(d4cc6310,caaff1a4,c87cb000,150,0) at ffs_load_inode+0xa4
ffs_vget(c8f53c00,150,2,ece638e0,8180) at ffs_vget+0x3a2
ffs_valloc(cacf4410,8180,c9082780,ece638e0,ece638f8) at ffs_valloc+0x100
ufs_makeinode(8180,cacf4410,ece63bec,ece63c00,202) at ufs_makeinode+0x69
ufs_create(ece63a68,ece63b24,c05c690e,ece63a68,ece63a64) at ufs_create+0x39
ufs_vnoperate(ece63a68,ece63a64,2,c07e0940,c8f21500) at ufs_vnoperate+0x18
vn_open_cred(ece63bd8,ece63cd8,180,c9082780,4) at vn_open_cred+0x19e
vn_open(ece63bd8,ece63cd8,180,4,c07e2690) at vn_open+0x33
kern_open(c8f21500,8059040,0,202,180) at kern_open+0xce
open(c8f21500,ece63d10,c077efce,3ee,3) at open+0x30
syscall(2f,2f,2f,3,bfbfe7b0) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (5, FreeBSD ELF32, open), eip = 0x280ca08f, esp = 0xbfbfe78c, ebp =
0xbfbfe898 ---
- gdb -k
#0 doadump () at ../../../kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc055fa7b in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc055fe7d in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc046f632 in db_panic () at ../../../ddb/db_command.c:450
#4 0xc046f592 in db_command (last_cmdp=0xc07d2760, cmd_table=0x0,
aux_cmd_tablep=0xc0784658, aux_cmd_tablep_end=0xc078465c)
at ../../../ddb/db_command.c:346
#5 0xc046f6d5 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc04726d5 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73
#7 0xc06f8f8c in kdb_trap (type=3, code=0, regs=0xece6357c)
at ../../../i386/i386/db_interface.c:171
#8 0xc070e678 in trap (frame=
{tf_fs = -1065484264, tf_es = -923664368, tf_ds = 16, tf_edi = -1065910848,
tf_esi = 1, tf_ebp = -320457272, tf_isp = -320457304, tf_ebx = 0, tf_edx = 0, tf_ecx =
1, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1066429803, tf_cs = 8, tf_eflags
= 642, tf_esp = -1065892694, tf_ss = -1066015299})
at ../../../i386/i386/trap.c:580
#9 0xc06fa9d8 in calltrap () at {standard input}:94
#10 0xc055fe16 in panic (
fmt=0xc0777dc0 vm_fault: fault on nofault entry, addr: %lx)
at ../../../kern/kern_shutdown.c:534
#11 0xc06b0fae in vm_fault (map=0xc1031000, vaddr=3673116672,
fault_type=1 '\001', fault_flags=0) at ../../../vm/vm_fault.c:891
#12 0xc070e8c2 in trap_pfault (frame=0xece6379c, usermode=0, eva=3673116672)
at ../../../i386/i386/trap.c:723
#13 0xc070e4f3 in trap (frame=
{tf_fs = -320471016, tf_es = -1068171248, tf_ds = -1065287664, tf_edi =
-892362752, tf_esi = -621850624, tf_ebp = -320456720, tf_isp = -320456760, tf_ebx =
-894439004, tf_edx = -621850624, tf_ecx = 64, tf_eax = 10, tf_trapno = 12, tf_err = 0,
tf_eip = -1066822780, tf_cs = 8, tf_eflags = 66182, tf_esp = -892362752, tf_ss = 16})
at ../../../i386/i386/trap.c:420
#14 0xc06fa9d8 in calltrap () at {standard input}:94
#15 0xc069c362 in ffs_vget (mp=0xc8f53c00, ino=3402604544, flags=2,
vpp=0xece638e0) at ../../../ufs/ffs/ffs_vfsops.c:1333
#16 0xc0681400 in ffs_valloc (pvp=0xcacf4410, mode=33152, cred=0xc9082780,
vpp=0xece638e0) at ../../../ufs/ffs/ffs_alloc.c:861
#17 0xc06aac19 in ufs_makeinode (mode=33152, dvp=0xcacf4410, vpp=0xece63bec,
cnp=0xece63c00) at ../../../ufs/ufs/ufs_vnops.c:2358
#18 0xc06a71b9 in ufs_create (ap=0xece63a68)
at ../../../ufs/ufs/ufs_vnops.c:199
#19 0xc06ab328 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2793
#20 0xc05c690e in vn_open_cred (ndp=0xece63bd8, flagp=0xece63cd8, cmode=384,
cred=0xc9082780, fdidx=0) at vnode_if.h:118
#21 0xc05c6763 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0)
at ../../../kern/vfs_vnops.c:93
#22 0xc05bfc3e in kern_open (td=0xc8f21500, path=0x0, pathseg=UIO_USERSPACE,
flags=514, mode=384) at ../../../kern/vfs_syscalls.c:963
#23 0xc05bfb60 in open (td=0x0, uap=0x0) at ../../../kern/vfs_syscalls.c:933
#24 0xc070f020 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 3, tf_esi = -1077942352, tf_ebp =
-1077942120, tf_isp = -320455308, tf_ebx = -1077942344, tf_edx = -1, tf_ecx = 2,
tf_eax = 5, tf_trapno = 0, tf_err = 2, tf_eip = 671916175, tf_cs = 31, tf_eflags =
518, tf_esp =
