Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Tue, 18 Nov 2003, Eric Anderson wrote: > Nate Lawson wrote: > >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) > > > Thanks! I've rebuilt and am happy to say that nothing is hosed and I > booted successfully :) > > Here's my sysctl output: > $ sysctl hw.acpi.cpu > hw.acpi.cpu.max_speed: 8 > hw.acpi.cpu.current_speed: 4 > hw.acpi.cpu.performance_speed: 8 > hw.acpi.cpu.economy_speed: 4 You should run a benchmark with different values for hw.acpi.cpu.current_speed to be sure the throttling control still works ok. I left it mostly intact so you shouldn't see any problems but it's still good to test. As you change it, you should see dmesg output of "acpi_cpu0: set speed to xx%" > hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 23589/0 0/0 0/0 0/0 > > I played with the different levels a bit, and can't tell much difference > in them. Let me know what else I can try to break with this. Just for > the info, I booted with a/c plugged in, but did the sysctl running on > battery. You should set hw.acpi.cpu.cx_lowest to 1 regularly and 2 or 3 if you're using battery. This will save on heat. I'd also be interested in if you'd set it to 3 while on battery and run a typical workload for an hour and then send me the result of sysctl hw.acpi.cpu. The cx_history value helps me know if my scheduler is accurate. > Eric AndersonSystems Administrator Centaur Technology Say hi to Tom Crispin for me. :) -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 18 Nov, Robert Watson wrote: > (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. You left out my favorite fork()/exec() intensive exmple, our ports system. During portupgrade, visible activity can grind stop for quite a while at the "Registering installation" stage, while top's "last pid" field increases rapidly and system CPU time is an embarrassingly large number, and this is with a static /bin and /sbin. Rather than trying to re-"optimize" this by converting /bin/sh back to being static, I think a got more could be gained by re-writing this part of the ports infrastructure to be more efficient. I'm not volunteering ... ___ [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 18 Nov, Garance A Drosihn wrote: > At 8:07 AM -0500 11/18/03, [EMAIL PROTECTED] wrote: > >> 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... I thought there were some NetBSD benchmark numbers posted, but after digging through my mail archives, I now think the results that I'm remembering were posted by Gordon and were run with rcNG, which is somewhat more shell intensive than our previous rc system: On 2 Jun, Gordon Tetlow wrote: > I'm planning on making a dynamically-linked root partition by 5.2. To > that end, I'm planning on doing to the following: > > Integrate Tim Kientzle's /rescue patches into the tree > Create /lib and populate with all the libs needed to support dynamically > linked binaries in /bin and /sbin > Have a big (probably NO_DYNAMIC_ROOT) knob to switch from static to > dynamic. > > There will be a performance hit associated with this. I did a quick > measurement at boot and my boot time (from invocation of /etc/rc to > the login prompt) went from 12 seconds with a static root to 15 > seconds with a dynamic root. I have yet to perform a worldstone on > it. I was thinking the difference was smaller than that. ___ [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)
Barney Wolff <[EMAIL PROTECTED]> writes: > Re-install/upgrade from a cd. Upgrade should leave your files alone. Thanks, Barney -- that's what I did and it saved my butt. A few folks suggested either LiveCD images or "fixit" functionality. I was kinda dead in the water and didn't think I could download a LiveCD and burn it from another system. I played with the floppy "fixit" functionality a bit but didn't see a way to preserve /etc and such. So I used a 5.1-RELEASE CD I had and used the UPGRADE option which promised to save my /etc stuff. I specified my old mount points (fortunately, I was able to read /etc/fstab from the boot "OK" prompt and make paper notes!). I then tried -- twice -- to install the "minimal" system from the CD and both times it kernel panic'd with a page fault (in process bufdaemon, last time). For grins, I again specified my mounts (only /, /var, /tmp, /usr; I didn't bother with /home and /usr/local), and told it to install via FTP. Surprisingly, this worked -- no panic. It appears to have installed a working kernel, /bin, /usr/bin, and friends and now I'm running again. I'm now doing a "make build world" and then will do a "make kernel KERNCONF=MyKernelDefinitionFileName", then finally a "make installworld" per the UPGRADING guide. I've never used the Upgrade option to FreeBSD and I've been using it heavily since 2.2.x. It's a good thing. Many thanks to everyone who replied. I promise I'll scan UPGRADING before doing a "make *world" next time! ___ [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 11:45 PM -0500 11/18/03, Robert Watson wrote: My feeling is we should all go away for a day or two, and run our favorite macro-benchmark on our favorite sensitive dynamic linking-sensitive application. I wish I had the time and background to implement one solution that I'd like to benchmark. have a: chflags ldcache /bin/sh When the loader goes to execute some binary, it checks for this ldcache flag. If set, it checks to see if it already has a cached copy of this program (probably checking based on a key of inode+lastchg for a match). If not, it links and loads the file into memory. It saves away a read-only copy of the result of that load. Then it does the appropriate magic to create a copy-on-write image of the loaded file, and executes that. If it already has a cached copy of that file, well, it just makes another copy-on-write image of the loaded file, and executes that. No I/O, no loading, no linking. Just RAM. Yes, disks have been getting bigger, but so has available memory. I think we would see a MUCH bigger win by taking advantage of that memory, than we will ever see by statically-linking system binaries. On the other hand, I have no idea if the above idea would be easy to implement in FreeBSD. It also needs to be a bit smarter than what I described, to cover the dynamic-library case (eg: the very PAM/NSS issue that we're interested in). If that isn't workable, I'm sure there are other strategies which could be imagined. Strategies which will give us more of a performance boost than static-linking these few programs will give us. -- 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]"
another trap 12 while in kernel mode
Hi, I am regularly getting those but unfortunately I neither have DDB in that kernel nor can get a crash dump nor do I have built wie DEBUG=-g. Is there anything more I can do apart from rebuilding kernel with support of all the missing debugging flags (which is in progress) ? I am logged in via serial console on this machine btw but I am not sure if this is the killing criteria for this panic. According to the log I write there had been no output for a long time before. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x6c2f6e81 fault code = supervisor write, page not present instruction pointer = 0x8:0xc055a00a stack pointer = 0x10:0xc9b4acac frame pointer = 0x10:0xc9b4acac 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 = 26 (swi8: tty:sio clock) trap number = 12 panic: page fault syncing disks, buffers remaining... 426 426 426 426 426 426 426 426 426 426 426 426 426 426 426 426 426 426 426 426 giving up on 349 buffers Uptime: 6h46m27s pfs_vncache_unload(): 1 entries remaining Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... -- 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: Unfortunate dynamic linking for everything
On Tue, Nov 18, 2003, Robert Watson wrote: > On systems like Mac OS X, use of a "shared > region" permits not only use of prebinding, but assumptions of common load > addresses for common libraries. In addition, the "shared region" approach > allows the reuse of page table and VM meta-data across many processes. > Leaving aside special-purpose optimizations like that, using some simple > heuristics, we could probably easily reduce the number of load addressed > dramatically, making prebinding a far more feasible approach, and > something we should explore thoroughly. IIRC, Dyson proposed something like that a while ago. It's a neat idea, particularly if it gets us away from PIC on register-starved architectures such as the i386. > John Dyson's suggestion of "mixed mode" linking, in which we statically > link known required parts of binaries, but permit dynamic linking of > "plug-in" functionality is another quite reasonable solution, as long as > we take care of the potential issue of "plug-ins" relying on symbols from > a library that is statically linked to the application, but not in the set > of symbols depended on by the application. Wouldn't the first shared object you loaded instantly pull in libc.so as a dependency, giving you pieces of both a static and a dynamic libc? It seems that that would break something... > For big applications like KDE, Open Office, et al, prebinding probably is > the right approach, and hopefully we have plenty of time before 5.3 to > refine Matthew's work and see if we can't get things up to speed. For these applications, the fork/exec overhead is so far into the noise and there are so many shared libraries that dynamic linking wins outright, prebinding or not. Maybe for servers that fork a lot this would be more contentious. ___ [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 2003-11-19T04:43:23Z, "M. Warner Losh" <[EMAIL PROTECTED]> writes: > The main reason we went with dynamic / was to be able to get dynamic > libary/loading support for newer authentication and user technologies. Just a quick interjection: As one who recently migrated a FreeBSD server from NIS to OpenLDAP authentication, and who can now see user and group names instead of UIDs and GIDs in directory listings, I sincerely thank everyone who worked on the dynamic linking project. -- Kirk Strauser "94 outdated ports on the box, 94 outdated ports. Portupgrade one, an hour 'til done, 82 outdated ports on the box." pgp0.pgp Description: PGP signature
Re: Unfortunate dynamic linking for everything
On Tue, 18 Nov 2003, David Schultz wrote: > On Tue, Nov 18, 2003, Robert Watson wrote: > > (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. > > This is the only performance argument that truly seems compelling, > particularly since fork()/exec() performance for dynamic binaries in > FreeBSD really sucks as compared to Solaris and AIX (and presumably > other systems that have gone dynamic long ago). I think this is mostly > an aspect of the dynamic linker and the lack of prebinding rather than > performance problems in the VM system. Some of Matthew Dodd's exploration of prebinding seems to indicate it's a big win for large applications with many libraries (XWindows, KDE, OpenOffice, whathaveyou), but that the base cost of loading relocation caches overwhelms the benefits of prebinding. More refinement could correct this, perhaps. Part of the cost of excessive cost of prebinding right now is that we almost always map libraries to different addresses for different programs, which results in a very large relocation cache. A quick sample on my notebook reveals libc mapped at no less than 28 different base addresses. On systems like Mac OS X, use of a "shared region" permits not only use of prebinding, but assumptions of common load addresses for common libraries. In addition, the "shared region" approach allows the reuse of page table and VM meta-data across many processes. Leaving aside special-purpose optimizations like that, using some simple heuristics, we could probably easily reduce the number of load addressed dramatically, making prebinding a far more feasible approach, and something we should explore thoroughly. My feeling is we should all go away for a day or two, and run our favorite macro-benchmark on our favorite sensitive dynamic linking-sensitive application. I.e., buildworld, system boot, periodic, or whatever. Attempt to focus on the actual performance loss, both the cause, and potential solutions. Returning to a static /bin/sh would be one potential solution. John Dyson's suggestion of "mixed mode" linking, in which we statically link known required parts of binaries, but permit dynamic linking of "plug-in" functionality is another quite reasonable solution, as long as we take care of the potential issue of "plug-ins" relying on symbols from a library that is statically linked to the application, but not in the set of symbols depended on by the application. Remaining with dynamic linking is another possible "solution" if macrobenchmarks don't reveal an interesting hit. If I had to guess, I think it probably comes down to comparing the costs of repeated fork/exec of /bin/sh, and that the "mixed mode" solution may be the easiest way to address a possible performance problem while retaining the dynamic linking benefits. But I want to be sure we address a real-world performance problem, not an anticipated one. For big applications like KDE, Open Office, et al, prebinding probably is the right approach, and hopefully we have plenty of time before 5.3 to refine Matthew's work and see if we can't get things up to speed. 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
In message: <[EMAIL PROTECTED]> Garance A Drosihn <[EMAIL PROTECTED]> writes: : At 9:02 PM -0500 11/18/03, [EMAIL PROTECTED] wrote: : > 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.) : : Well, yes, perhaps. But there is that issue of "development : resource limitation". Back when we did debate this publicly, : no one stepped forward and said "I have the time to implement : a better solution". Thus, we went with this solution. And it still isn't too late for someone to step forward with a better solution. Or to develop one. The main reason we went with dynamic / was to be able to get dynamic libary/loading support for newer authentication and user technologies. The size advantage is one minor added benefit. : Speaking as to what we can do right now, I would not want to : delay the 5.x-stable branch by adding some project right now : to start writing an alternate PAM/NSS solution. If someone : wants to write one for 6.0, that would be good. There is : nothing in this solution which would cause problems for : some later solution. Disk space will only get cheaper. I tend to agree. If there's a performance regression with the dynamic change, then the right solution isn't to yell 'back it out', but rather to build a better mouse trap. FreeBSD gets better through these tentions and people scratching an itch. FreeBSD doesn't get better by stagnating and never changing anything. With all things it is a balance. Sometimes it tips a little this way or that. As our user base changes, the balance point changes. If FreeBSD isn't willing to adapt to the new balance point, it runs the risk of losing relevance. Finally, I'll just observe that most of our users care most about apache, which has been dynamically linked for a long time. Warner ___ [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)
Nate Lawson wrote: 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) Thanks! I've rebuilt and am happy to say that nothing is hosed and I booted successfully :) Here's my sysctl output: $ sysctl hw.acpi.cpu hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 4 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 4 hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 23589/0 0/0 0/0 0/0 I played with the different levels a bit, and can't tell much difference in them. Let me know what else I can try to break with this. Just for the info, I booted with a/c plugged in, but did the sysctl running on battery. Thanks Nate for the hints.. 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 9:02 PM -0500 11/18/03, [EMAIL PROTECTED] wrote: 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.) Well, yes, perhaps. But there is that issue of "development resource limitation". Back when we did debate this publicly, no one stepped forward and said "I have the time to implement a better solution". Thus, we went with this solution. Speaking as to what we can do right now, I would not want to delay the 5.x-stable branch by adding some project right now to start writing an alternate PAM/NSS solution. If someone wants to write one for 6.0, that would be good. There is nothing in this solution which would cause problems for some later solution. Disk space will only get cheaper. I can see that it might be worthwhile to statically-link *some* of the programs in /bin and /usr/bin. Particularly small ones, where the added overhead would be a significant percentage of the total execution time of the command. But I do think we should stick with the present setup for 5.2-release, and consider any fine-tuning of it after that release is done. 5.2 is still "-current", and it is fine to leave this as it is for a "-current" release. And by doing that, more developers will get real-world experience with this setup, and find out if we have overlooked anything. [disclaimer: This is just my opinion, as one developer. I suspect that everyone in the FreeBSD project will agree that I do *not* speak "for the project"... :-) ] -- 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, Nov 18, 2003, Scott Long wrote: > > 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. FreeBSD had a lingering LD_LIBRARY_PATH-related vulnerability until Sunday, actually[1]. ;-) But I don't mean to dispute your point. Like most of the other arguments in this bikeshed, there is nothing fundamental about the LD_LIBRARY_PATH problem---nothing that can't be fixed easily. [1] The bug is either that nologin(8) respected LD_LIBRARY_PATH or that sshd(8) and login(1) allow environment poisoning, depending on your point of view. ___ [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, Robert Watson wrote: > (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. This is the only performance argument that truly seems compelling, particularly since fork()/exec() performance for dynamic binaries in FreeBSD really sucks as compared to Solaris and AIX (and presumably other systems that have gone dynamic long ago). I think this is mostly an aspect of the dynamic linker and the lack of prebinding rather than performance problems in the VM system. Most of the other arguments both for and against seem less important. The disk space argument that people have been giving is particularly bogus given that disk capacity is increasing 60% per year and the size of /bin isn't. The NSS argument is only valid because NSS was implemented specifically to require dlopen() rather than a daemon, so that disadvantage is in no way fundamental. The best reason in my mind for going dynamic hasn't even been mentioned much. In a fully dynamic system, it is possible to change kernel ABIs without breaking anything as long as the kernel and libc are in sync. Thus, we wouldn't have three versions of statfs() and two versions of accept(), along with other cruft in the kernel to support binaries going back to 4.2BSD. The compatX.Y libraries would suffice. Also, developers would have greater flexibility to extend or otherwise improve system interfaces between minor releases. Unfortunately, this would mean giving up on ABI compatibility for static binaries entirely, so I doubt it would fly anytime soon. Moreover, the performance issues we have with dynamic binaries now really are significant, at least as of a few months ago. (Maybe mdodd's prebinding work addresses some of that.) Dragonfly has addressed the same issue in a different, perhaps more elegant way, wherein even static binaries have forward and reverse ABI compatibility. But it does still require the kernel to mock up legacy fields in shared structures forever, and it doesn't permit me to, for instance, take advantage of the fact that mmap(), msync(), mprotect(), minherit(), madvise(), and mincore() have essentially the same access checks and rewrite them to use a common monitor. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ppp RADIUS accounting bug
Hello! I found a serious bug in RADIUS accounting code. The problem is that OctetsIn and OctetsOut are defined as unsingned long long, but the RADIUS supports only INT32 values, so, when we're doing rad_put_int(r->cx.rad, RAD_ACCT_OUTPUT_OCTETS, stats->OctetsOut) in radius.c for OctetsOut (and OctetsIn also) we loosing information if OctetsOut is greater then INT32_MAX. This should be fixed. Regards, Boris ___ [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 = -
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: 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: 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
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
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 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
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?) 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
:/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
:> :>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
: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
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
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
Garance A Drosihn said: > 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. > Okay... I do understand. > > > 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. > Please remember: that several people worked VERY VERY hard to make FreeBSD performant. It would be very difficult to recover the performance after many cascaded performance losses. Throwing away performance is almost an irrevocable decision, and features (once added) are difficult to remove or substantially rearchitect (for performance.) (Once a slow, but workable functionality is added, the cost to recover lost performance after the fact is very very high.) 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
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: 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: 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 funct
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]"
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 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]"
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: 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: 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: 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 d
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 com
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: 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
[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: 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
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: 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]"
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 to continue, or q 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
to continue, or q 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 0xc05f7e87 in page_al
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]"
Re: Unfortunate dynamic linking for everything
Garrett Wollman said: > < > > If the object is to maximally 'share', > > The object, AIUI, is for ~username expansion to work in the shells > when the user stored somewhere defined by an external NSS module. I > don't believe that there is anything else in a (sane) shell that > cares. > It is a fallacy that EVERYTHING (e.g. libc) needs to be dynamically linked to support that feature. A single, self contained library that might even be sparse WRT memory isn't going to hurt much. A compromise that supports both a 'feature' and performance seems to be appropriate. Making everything shared (with the sparse allocation of .data, and .text somewhat) to implement a specific feature is certainly wasteful. All or nothing isn't the optimal answer here. John ___ [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: 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]"
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: 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]"
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: 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: 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: 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: 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
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: 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]"
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: 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]"
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, 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 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, 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, 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, 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: 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, 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: 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: 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 )
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 , 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, send any mail to
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. Looks good here on a Centrino based laptop, which has a _CST method in its ASL: acpi_cpu0: 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: 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: at device 10.0 on pci0
> cardbus0: 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: 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: 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 2>&1 >> static.loop.log | sed -ne '/real/s/real //p' >>
static.total.log ; \
time -p ./dynamic 2>&1 >> 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
#include
#include
#include
#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%
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: 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
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, 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]"
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: 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]"
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 'c' 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: 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: at 0x2c00-0x2cff, irq 10 (level) > ahc0: on eisa0 slot 2 > ahc1: at 0x4c00-0x4cff, irq 11 (level) > ahc1: on eisa0 slot 4 > ahc2: port 0xf800-0xf8ff mem > 0xf68fb000-0xf68fbfff irq 17 at device 11.0 on pci1 > ahc2: Using left over BIOS settings > ahc3: 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: 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: 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: 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]"
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 {
sysctl_ctx_free(&ac
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]"
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
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]"
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: 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: 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: 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: 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: 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: 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]"
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]"
