Re: malloc_bucket() idea (was Re: How to fix malloc.)
Jake Burkholder wrote: Jeff Roberson (jeff@) has been working on a slab allocator that goes a long way to making malloc(), free() and the zone allocator not require giant. I've reviewed what he's got so far and it looks pretty damn good to me, I'll see about getting him to post it. He's working on adding the per-cpu queues now. A design like this resolves my objection to the pure SLAB allocator; Vahalia suggests this as a potential enhancment in his book, and the authors of the SLAB allocator mention it in their second paper (~1996/1997). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: First (easy) td_ucred patch
Apparently, On Sat, Feb 23, 2002 at 11:21:24AM -0800, Julian Elischer said words to the effect of; On Fri, 22 Feb 2002, John Baldwin wrote: http://www.FreeBSD.org/~jhb/patches/ucred.patch the structural rewriting in kern_proc.c should be done as a separate commit. (though I agree it should be done) the structural rewriting in kern/sysv_*.c could be done as a separate commit as well. (I agree it is worth doing) I'll let you get away with unp_listen() :-) I'd like to point out that in all cases that you mention, the original structure before the giant pushdown is being restored. A lot of structural rewriting occured in those commits. It was not done separately. I don't recall if the patches were posted for review, I certainly never saw them. This strikes me as a double standard. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc_bucket() idea (was Re: How to fix malloc.)
Alfred Perlstein wrote: * Matthew Dillon [EMAIL PROTECTED] [020223 14:43] wrote: This is approximately what I am thinking. Note that this gives us the flexibility to create a larger infrastructure around the bucket cache, such as implement per-cpu caches and so on and so forth. What I have here is the minimal implementation. I strongly object to this implementation right now, please do not commit it. I already explained to you how to make the problem go away but instead you insist on some complex api that pins memory down like the damn zone allocator. It's not needed, so please don't do it. Actually, the zone allocator is not far off, I think. Imagine if the entire possible KVA space (real RAM + swap) was preallocated PTEs. Allocations could treat it as anonymous memory, for which a mapping process was not required, and all allocations would be interrupt safe by default, without having to special case the code one way or the other. This seems, to me, to be the right idea. The only issue left is that the maps take real memory that is wired down. This raises the possibility of adding to the swap where swap + RAM KVA swap + RAM + new_swap = KVA, which would imply mappings bneing required on the adding of swap (via swapon). Not that painful, but it does imply a 1:1000 limit ratio on real vs. virtual RAM to get to the page mapping overhead. 4M pages would cover some of that problem... but making allocations swappable is often desirable, even in the kernel, so you would need to special case those mappings... and 4M and 4K pages play badly together, unless you know what you are doing, and you know the undocumented bugs (c.v. the recent AMD AGP thing). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT in pretty good shape, after all
h julian@jules:uname -a FreeBSD jules.elischer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Thu Feb 21 00:32:02 PST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NMDM i386 julian@jules: I'm using vmware2 to run turbotax to do my taxes and it seems fine On Sat, 23 Feb 2002, Garance A Drosihn wrote: It is working fairly well for me too, on a dual-pentium machine. I can't get vmware2 working, but most of everything else that I do is working, and I'm not running into any mysterious crashes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: First (easy) td_ucred patch
I'm just saying that if this is the simple p-p_ucred = td-td_ucred change that do only that and do the rewrite in a separate commit.. I'm not against doing hte commit as is however.. it's only 3 small nits.. the one that may be real is the other one I mention (I think in another email) where the capability of coping with a NULL td is lost. On Sun, 24 Feb 2002, Jake Burkholder wrote: Apparently, On Sat, Feb 23, 2002 at 11:21:24AM -0800, Julian Elischer said words to the effect of; On Fri, 22 Feb 2002, John Baldwin wrote: http://www.FreeBSD.org/~jhb/patches/ucred.patch the structural rewriting in kern_proc.c should be done as a separate commit. (though I agree it should be done) the structural rewriting in kern/sysv_*.c could be done as a separate commit as well. (I agree it is worth doing) I'll let you get away with unp_listen() :-) I'd like to point out that in all cases that you mention, the original structure before the giant pushdown is being restored. A lot of structural rewriting occured in those commits. It was not done separately. I don't recall if the patches were posted for review, I certainly never saw them. This strikes me as a double standard. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT in pretty good shape, after all
SMP? -- Terry Julian Elischer wrote: h julian@jules:uname -a FreeBSD jules.elischer.org 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Thu Feb 21 00:32:02 PST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/NMDM i386 julian@jules: I'm using vmware2 to run turbotax to do my taxes and it seems fine On Sat, 23 Feb 2002, Garance A Drosihn wrote: It is working fairly well for me too, on a dual-pentium machine. I can't get vmware2 working, but most of everything else that I do is working, and I'm not running into any mysterious crashes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Install World fails in -Current
Doug Barton wrote:
Dag-Erling Smorgrav wrote:
David Wolfskill [EMAIL PROTECTED] writes:
Sounds like a botched (or not run) mergemaster execution:
No - mergemaster will croak because it runs mtree to build its temp
directory, so if you're trying to update a pre-smmsp system you have
to add the smmsp user and group manually.
Ok, I decided to go proactive and add -p mode for pre
{build|install}world which compares master.passwd, group, and the
variables in /etc/make.conf to /usr/src/share/examples/etc/make.conf.
This should give people a fairly painless way to handle the transition
if they choose to accept it. While I was there, I added some other code
I've been using for a while to compare variables in /etc/rc.conf[.local]
with the same variables in /etc/defaults/rc.conf. Use 'mergemaster -C'
to use that feature.
If someone has suggestions on more files to add to -p mode, let me
know. I'll update the man page after people have had a chance to play
with these.
Enjoy,
Doug
--
We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory.
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Success! critical_enter()/critical_exit() revamp (was Re: malloc_bucket() idea (was Re: How to fix malloc.))
I'm going to wait until tomorrow before posting it. I have a bunch of cleanup to do. Bruce, your sys.dif was *invaluable*! It would have taken me a lot longer to figure out the interrupt disablement requirement around the icu_lock, and the statclock and hardclock forwarding issues (which I got working by the way!). It turns out that putting the pending masks in the per-cpu area was the right solution! It made statclock and hardclock forwarding easy (I can see why you didn't even try in your patch set, doing it with a global mask would be nearly impossible). In fact, it made everything unbelievably easy. Apart from all the assembly coding, there were two serious issues. fork_exit() assumes that interrupts are hard-disabled on entry. I readjusted the code such that the trampoline assembly initialized the td_critnest count so it could STI prior to calling fork_exit(). The second issue is that cpu_switch() does not save/restore the PSL_I (interrupt disablement mask). I added a PSL word to the PCB structure to take care of the problem. Without this if you have a thread switch away while holding interrupts hard-disabled, the next thread will inherit the hard disablement. I saw the sti's you added in various places but I figured the best solution was to simply save/restore the state. The original code didn't have this problem because interrupts were always hard-disabled while holding the sched_lock and, of course, cpu_switch() is always called while holding sched_lock. (Similarly, icu_lock needed hard-disablements wrapped around it for the same reason, because a level interrupt still needs to be able to get icu_lock in order to defer itself). In anycase, I have successfully built the world in a -current SMP + apic_vector system. Tomorrow I will cleanup on the UP icu_vector code to match the apic_vector code and post the results. I also have a sysctl that allows developers to toggle the mode for testing purposes (old way or new way). Finally, I took your suggestion in regards to not trying to combine the masks together. I have a 'some sort of interrupt is pending' variable then I have fpending (for fast interrupts), ipending (for normal interrupt threads), and spending (which I use for the stat and hardclock forwarding). They're all per-cpu entities, of course. unpend() prioritizes them. In anycase, I'll post it all tomorrow after I've got icu_vector cleaned up. One of the best things about this patch set is that it is really flexible. We should be able to really make interrupts fly. In fact, it should even be possible for one cpu to steal another cpu's pending interrupt(s) fairly trivially, without having to resort to IPIs. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
snapshots? WAS: Re: -CURRENT in pretty good shape, after all
Am Sa , 2002-02-23 um 18.24 schrieb Dag-Erling Smorgrav: Thumbs up and big cheers to all of you (well, us) guys working on -CURRENT. It's pretty stable and has been for a while now - and even on my poor old 350 MHz K6-2, it performs well enough to make a kickass desktop development platform. Let's hope it'll only get better from here on out :) Hello all, this sounds great. Thanks to all people. But this brings me to one question: What's about snapshot-releases? Some years ago (from 3 on) I had a supscription for current snapshots. The last I got was 2 years ago an April2000 -4 snapshot. Since I changed my employer I made new subscriptions at bsdmall.com but I couldn't find any snapshot subscription. Are you still doing these snapshots and they are just no more offered or don't you do any snapshot releases any more. Thanks all, -Harry DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Wearix Software GmbH Harald Schmalzbauer, IT-Engineer Unterhachinger Strasse 75 81737 München +49 89 548828-702 http://www.wearix.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT in pretty good shape, after all
On 2002-02-23 18:24, Dag-Erling Smorgrav wrote:
Thumbs up and big cheers to all of you (well, us) guys working on
-CURRENT. It's pretty stable and has been for a while now - and even
on my poor old 350 MHz K6-2, it performs well enough to make a kickass
desktop development platform. Let's hope it'll only get better from
here on out :)
It does work perfectly nice for me too, here. I've been building worlds
without a single problem ever since Feb 7, 2002. Oh, and since I like
living in the edge, I erased my 4-STABLE installation on Feb 10, and
formatted that partition. Now I use it as /c, a workspace where temporary
development work is done.
Thank you all, who have put efforts in making this happen!
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
NOTES: I would like to thank Bruce for supplying the sample code that allowed me to do this in a day instead of several days. * debug.critical_mode sysctl. This will not be in the final commit, nor will any of the code that tests the variable. The final commit will use code as if the critical_mode were '1'. The default is 1, which means to use the new streamlined interrupt and cpu_critical_enter/exit() code. Setting it to 0 will revert to the old hard-interrupt-disablement operation. You can change the mode at any time. * Additional cpu_critical_enter/exit() calls around icu_lock. Since critical_enter() no longer disables interrupts, special care must be taken when dealing with the icu_lock spin mutex because it is the one thing the interrupt code needs to be able to defer the interrupt. * MACHINE_CRITICAL_ENTER define. This exists to maintain compatibility with other architectures. i386 defines this to cause fork_exit to use the new API and to allow the i386 MD code to supply the critical_enter() and critical_exit() procedures rather then kern_switch.c I would much prefer it if the other architectures were brought around to use this new mechanism. The old mechanism makes assumptions in regards to hard disablement that is no longer correct for i386. * Trampoline 'sti'. In the final commit, the trampoline will simply 'sti' after setting up td_critnest. The other junk to handle the hard-disablement case will be gone. * PSL save/restore in cpu_switch(). In the original code interrupts were always hard-disabled due to holding the sched_lock. cpu_switch never bothered to save/restore the hard interrupt enable/disable bit (the PSL). In the new code, hard disablement has no relationship to the holding of spin mutexes and so we have to save/restore the PSL. If we don't, one thread's interrupt disablement will propogate to another thread unexpectedly. * Additional STI's. It may be possible to emplace additional STI's in the code. For example, we should be able to enable interrupts in the dounpend() code after we complete processing of FAST interrupts and start processing normal interrupts. * Additional cpu_critical_enter()/exit() calls in CY and TIMER code. Bruce had additional hard interrupt disablements in these modules. I'm not sure why so if I need to do that as well I would like to know. * Additional optimization and work. This is ongoing work but this basic patch set, with some cleanups, is probably what I will commit initially. This code will give us a huge amount of flexibility in regards to handling interrupts. -Matt Index: i386/i386/exception.s === RCS file: /home/ncvs/src/sys/i386/i386/exception.s,v retrieving revision 1.91 diff -u -r1.91 exception.s --- i386/i386/exception.s 11 Feb 2002 03:41:58 - 1.91 +++ i386/i386/exception.s 24 Feb 2002 08:41:40 - @@ -222,6 +222,18 @@ pushl %esp/* trapframe pointer */ pushl %ebx/* arg1 */ pushl %esi/* function */ + movlPCPU(CURTHREAD),%ebx/* setup critnest */ + movl$1,TD_CRITNEST(%ebx) + cmpl$0,critical_mode + jne 1f + pushfl + poplTD_SAVECRIT(%ebx) + orl $PSL_I,TD_SAVECRIT(%ebx) + jmp 2f +1: + movl$-1,TD_SAVECRIT(%ebx) + sti /* enable interrupts */ +2: callfork_exit addl$12,%esp /* cut from syscall */ Index: i386/i386/genassym.c === RCS file: /home/ncvs/src/sys/i386/i386/genassym.c,v retrieving revision 1.121 diff -u -r1.121 genassym.c --- i386/i386/genassym.c17 Feb 2002 17:40:27 - 1.121 +++ i386/i386/genassym.c24 Feb 2002 09:06:56 - @@ -89,6 +89,8 @@ ASSYM(TD_KSE, offsetof(struct thread, td_kse)); ASSYM(TD_PROC, offsetof(struct thread, td_proc)); ASSYM(TD_INTR_NESTING_LEVEL, offsetof(struct thread, td_intr_nesting_level)); +ASSYM(TD_CRITNEST, offsetof(struct thread, td_critnest)); +ASSYM(TD_SAVECRIT, offsetof(struct thread, td_savecrit)); ASSYM(P_MD, offsetof(struct proc, p_md)); ASSYM(MD_LDT, offsetof(struct mdproc, md_ldt)); @@ -134,6 +136,7 @@ ASSYM(PCB_DR3, offsetof(struct pcb, pcb_dr3)); ASSYM(PCB_DR6, offsetof(struct pcb, pcb_dr6)); ASSYM(PCB_DR7, offsetof(struct pcb, pcb_dr7)); +ASSYM(PCB_PSL, offsetof(struct pcb, pcb_psl)); ASSYM(PCB_DBREGS, PCB_DBREGS); ASSYM(PCB_EXT, offsetof(struct pcb, pcb_ext)); @@ -176,6 +179,10 @@ ASSYM(PC_SIZEOF, sizeof(struct pcpu)); ASSYM(PC_PRVSPACE, offsetof(struct
Re: -CURRENT in pretty good shape, after all
- Original Message - From: Szilveszter Adam [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 24, 2002 1:04 PM Subject: Re: -CURRENT in pretty good shape, after all On Sun, Feb 24, 2002 at 06:22:11AM +0200, Giorgos Keramidas wrote: It does work perfectly nice for me too, here. I've been building worlds without a single problem ever since Feb 7, 2002. Oh, and since I like living in the edge, I erased my 4-STABLE installation on Feb 10, and formatted that partition. Now I use it as /c, a workspace where temporary development work is done. Well, just to put my Me too! here. I have been following 5.x for as long as it existed and during all this exercise, I have found it to be fairly useable at all times. There were some bumps along the road, but nothing that a careful study of this and other mailing lists would not have solved. In fact, ever since 5.x branched from 4.0 way back when:-) it was the only installation of FreeBSD that I had on my workstation. I wrote my university thesis on this machine, while religiously keeping up with the latest and greatest -CURRENT source, the box has served as a dialup and later as an ADSL gateway without problems. Of course, debugging code has slowed it down at times but that was expected. Although I do not consider myself a developer/programmer, I always tried to report problems in a useful way when found. It is just that I did not have a lot to do on this front:-) (Maybe I am the kind of user who should start using -CURRENT in greater numbers? OK, I'm here already:-) This machine is a PII-233 UP, with an Intel 440-LX based mobo and only IDE peripherals. It is no longer state of the art or even close, but, thanks to FreeBSD, it runs as snappy as ever. Thank you all, who have put efforts in making this happen! Indeed. It is really refreshing to see that, despite occasional ramblimngs and otbreaks of flame on the lists, the project really makes headway, especially looked at from a historical perspective. Keep up the good work! P.S.: This message is also test to see if the upgrade to the latest sendmail worked well:-) another me too I have had a 5.0 box running continuously for several months, I don't use the box much but I do use it a little at least a few times a day. It just sits there on my cable modem at home and I use it as a samba (pre-3.0beta) server for mp3's at home, or via http/ftp from work. It's been running seti@home since day one, I use it to test ssh and rsync procedures and other miscelaneous things where I need a unix box to try something on and don't want to use a customers machine. I have done a couple buildworlds and buildkernels but only a couple and not in months, but it went without a hitch. I have built a few ports like vnc and samba, again no hitches and again the results have also been running for months. there was a problem with my mouse for a while, I applied a patch from a post on this list, rebuilt and no more mouse problem. all in all, it's been just great for me even though it's a pretty old -CURRENT. oh and the hardware is just a crappy emachine with an amd k6-2 350 (running at 385) that was a desktop win98 machine at a customers that they threw away for being too old and slow. I just put in a new power supply and a little ram and it's been a damned fine freebsd box for me. neven gnome and enlightenment and gimp and netscape et al are fast enough to be useable, although I did disable gnome and E in favor of icewm just on general principle. Brian K. White -- [EMAIL PROTECTED] -- http://www.aljex.com/bkw/ +[+++[-]-]+..+.+++.-.[+---]++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CA updated
Wow! This did away with the once-a-minute error messages from Notify()s on processor objects on my laptop. However, I am now getting frequent panics from from a GIANT_REQUIRED assertion in kmem_malloc(). kmem_malloc() gets called via malloc() from AcpiOsAllocate(), without Giant locked. The call to AcpiOsAllocate() happens deep in a AML object evaluation in from acpi_tz_thread(). I tried naively to modify AcpiOsAllocate to grab Giant before malloc() and release it afterward, but this appears to be a very bad idea: There is a mtx_assert(Giant, MA_NOTOWNED) in ithread_loop() in kern/kern_intr.c which blows up during boot. Regards, Magnus On Fri, 22 Feb 2002, Mike Smith wrote: Subject: HEADS UP: ACPI CA updated I've finally updated the ACPI CA codebase with Intel's 20020214 drop (yes, I tagged it 0217, my bad). This is the first drop that Intel haven't asked me not to commit since the 20011120 version, so there are a large number of changes and bugfixes. See Intel's logs at http://developer.intel.com/technology/iapc/acpi for more details. There aren't many changes in the FreeBSD-specific code, this is just catching up with major improvements in the interpreter. As usual, please report any problems or success to the list. Regards, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT in pretty good shape, after all
On Sat, Feb 23, 2002 at 06:24:39PM +0100, Dag-Erling Smorgrav wrote: Thumbs up and big cheers to all of you (well, us) guys working on -CURRENT. It's pretty stable and has been for a while now - and even on my poor old 350 MHz K6-2, it performs well enough to make a kickass desktop development platform. Let's hope it'll only get better from here on out :) Hear hear (or is that hear here?). I've been running current on my laptop since the first FreeBSDCon, and over all I'm pretty happy with it. I rebooted onto a new kernel a few days ago, but before that I'd amassed over three weeks of uptime on the laptop with no problems at all - terrific. (Three weeks on a laptop? Maybe I should get out more). Joe msg35174/pgp0.pgp Description: PGP signature
Re: malloc_bucket() idea (was Re: How to fix malloc.)
On Sat, 23 Feb 2002, Alfred Perlstein wrote: Usually when I see diff(1) output from you I usually expect a commit within the next half hour or so, I just wanted to make myself clear on the issue. No worries. :) Yes, and hopefully JeffR's allocator will fix our problems, that is if it ever makes it out of p4. :) That assumes that it was actually in P4 in the first place. Jeffr's commit bit was approved in the last two days, and he's begun posting his patches to -arch. I hope to see his memory allocator patch there soon :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CA updated
Wow! This did away with the once-a-minute error messages from Notify()s on processor objects on my laptop. However, I am now getting frequent panics from from a GIANT_REQUIRED assertion in kmem_malloc(). kmem_malloc() gets called via malloc() from AcpiOsAllocate(), without Giant locked. The call to AcpiOsAllocate() happens deep in a AML object evaluation in from acpi_tz_thread(). I tried naively to modify AcpiOsAllocate to grab Giant before malloc() and release it afterward, but this appears to be a very bad idea: There is a mtx_assert(Giant, MA_NOTOWNED) in ithread_loop() in kern/kern_intr.c which blows up during boot. Try grabbing Giant in acpi_tz_thread when it wakes up, then dropping it again before it goes to sleep. This is probably a hack, but I'd guess a required one for now. If that works, send me a diff and I'll commit it with thanks! Regards, Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PNP0303 can't assign resources
hi ! [zaa:/u/zaa]uname -a FreeBSD zaa.ulstu.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Feb 24 22:38:36 MSK 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC i386 - /var/run/dmesg.boot --- sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0c02 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0700 can't assign resources ad0: 4125MB FUJITSU MPB3043ATU E [8940/15/63] at ata0-master UDMA33 acd0: CDROM CREATIVECD3220E at ata0-slave PIO4 Mounting root from ufs:/dev/ad0s2a - end is this normal ? full dmesg.boot attached. -- zhuravlev alexander u l s t u n o c e-mail:[EMAIL PROTECTED] Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sun Feb 24 22:38:36 MSK 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc052a000. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 266616007 Hz CPU: Pentium II/Pentium II Xeon/Celeron (266.62-MHz 686-class CPU) Origin = GenuineIntel Id = 0x634 Stepping = 4 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 134217728 (131072K bytes) avail memory = 125222912 (122288K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xdf80-0xdf9f irq 10 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 7.3 (no driver attached) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0c02 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0700 can't assign resources ad0: 4125MB FUJITSU MPB3043ATU E [8940/15/63] at ata0-master UDMA33 acd0: CDROM CREATIVECD3220E at ata0-slave PIO4 Mounting root from ufs:/dev/ad0s2a
Locale in FreeBSD
Hi! I wan't to know when will be suported LC_NUMERIC and LC_MONETARY in FreeBSD, not hardcoded to C lang. -- bye, Uros To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[Patch: clarity] Re: PNP0303 can't assign resources
zhuravlev alexander wrote:
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknown: PNP0303 can't assign resources
unknown: PNP0c02 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0501 can't assign resources
unknown: PNP0401 can't assign resources
unknown: PNP0700 can't assign resources
ad0: 4125MB FUJITSU MPB3043ATU E [8940/15/63] at ata0-master UDMA33
acd0: CDROM CREATIVECD3220E at ata0-slave PIO4
Mounting root from ufs:/dev/ad0s2a
- end
is this normal ?
It is if you have your BIOS configured incorrectly with
regard to whether you are running a PNP OS.
It's also normal if you have more hardware in a box
than it's possible to handle simultaneously, e.g. if
you had a bunch of slots full of resource hungry
hardware.
Probably you will need to fiddle with your BIOS.
Try the following patch; the failure message will be
somewhat less cryptic, since it will tell you the
proximal reason for failure out of the 5 possibles
for the message you are seeing. 8-).
-- Terry
Index: isa_common.c
===
RCS file: /usr/cvs/src/sys/isa/isa_common.c,v
retrieving revision 1.16.2.1
diff -u -r1.16.2.1 isa_common.c
--- isa_common.c16 Sep 2000 15:49:52 - 1.16.2.1
+++ isa_common.c24 Feb 2002 21:07:23 -
@@ -387,15 +387,20 @@
struct isa_device *idev = DEVTOISA(child);
struct isa_config_entry *ice;
struct isa_config config;
+ char *reason = Empty ISA id_configs;
bzero(config, sizeof config);
TAILQ_FOREACH(ice, idev-id_configs, ice_link) {
+ reason = memory;
if (!isa_find_memory(child, ice-ice_config, config))
continue;
+ reason = port;
if (!isa_find_port(child, ice-ice_config, config))
continue;
+ reason = irq;
if (!isa_find_irq(child, ice-ice_config, config))
continue;
+ reason = drq;
if (!isa_find_drq(child, ice-ice_config, config))
continue;
@@ -403,6 +408,7 @@
* A working configuration was found enable the device
* with this configuration.
*/
+ reason = no callback;
if (idev-id_config_cb) {
idev-id_config_cb(idev-id_config_arg,
config, 1);
@@ -414,7 +420,7 @@
* Disable the device.
*/
bus_print_child_header(device_get_parent(child), child);
- printf( can't assign resources\n);
+ printf( can't assign resources (%s)\n, reason);
if (bootverbose)
isa_print_child(device_get_parent(child), child);
bzero(config, sizeof config);
Re: [Patch: clarity] Re: PNP0303 can't assign resources
This is a multi-part message in MIME format. --741846253D1D9002AE8EAD96 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit zhuravlev alexander wrote: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0c02 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0700 can't assign resources ad0: 4125MB FUJITSU MPB3043ATU E [8940/15/63] at ata0-master UDMA33 acd0: CDROM CREATIVECD3220E at ata0-slave PIO4 Mounting root from ufs:/dev/ad0s2a - end is this normal ? It is if you have your BIOS configured incorrectly with regard to whether you are running a PNP OS. It's also normal if you have hints loaded for things that could have been autoconfigured, which is what the above seems to suggest. -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CA updated
On Sun, 24 Feb 2002, Michael Smith wrote:
Try grabbing Giant in acpi_tz_thread when it wakes up, then dropping it
again before it goes to sleep. This is probably a hack, but I'd guess a
required one for now.
If that works, send me a diff and I'll commit it with thanks!
Yow! Works absolutely fine. Patch below!
Thanks!
Magnus
--- sys/dev/acpica/acpi_thermal.c.ctm Sun Feb 24 13:55:13 2002
+++ sys/dev/acpica/acpi_thermal.c Sun Feb 24 23:20:39 2002
@@ -31,6 +31,8 @@
#include sys/param.h
#include sys/kernel.h
#include sys/kthread.h
+#include sys/lock.h
+#include sys/mutex.h
#include sys/bus.h
#include sys/proc.h
#include sys/reboot.h
@@ -780,6 +782,8 @@
for (;;) {
tsleep(acpi_tz_proc, PZERO, nothing, hz * acpi_tz_polling_rate);
+ mtx_lock(Giant);
+
if (devcount == 0)
devclass_get_devices(acpi_tz_devclass, devs, devcount);
@@ -787,5 +791,7 @@
for (i = 0; i devcount; i++)
acpi_tz_timeout(device_get_softc(devs[i]));
ACPI_UNLOCK;
+
+ mtx_unlock(Giant);
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [Patch: clarity] Re: PNP0303 can't assign resources
Michael Smith wrote: It is if you have your BIOS configured incorrectly with regard to whether you are running a PNP OS. It's also normal if you have hints loaded for things that could have been autoconfigured, which is what the above seems to suggest. OK. 8-). I've always seen it when my PNP OS setting was wrong. The card IDs made me pretty sure it wasn't 8 muti-I/O cards. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [Patch: clarity] Re: PNP0303 can't assign resources
In the last episode (Feb 24), Terry Lambert said: zhuravlev alexander wrote: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0c02 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0700 can't assign resources ad0: 4125MB FUJITSU MPB3043ATU E [8940/15/63] at ata0-master UDMA33 acd0: CDROM CREATIVECD3220E at ata0-slave PIO4 Mounting root from ufs:/dev/ad0s2a - end is this normal ? It is if you have your BIOS configured incorrectly with regard to whether you are running a PNP OS. Not many BIOSes even give you this option anymore.. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [Patch: clarity] Re: PNP0303 can't assign resources
* Terry Lambert [EMAIL PROTECTED] [020224 13:12] wrote: Try the following patch; the failure message will be somewhat less cryptic, since it will tell you the proximal reason for failure out of the 5 possibles for the message you are seeing. 8-). Cool explanation, the attached patch was committed but had to be modified because it wouldn't apply cleanly. Was it meant for -stable? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
libusb build broken due to structure member renaming
hello, I've got a -current-related question to ask. akbeech forwarded me his build log when trying to build the linux user-land libusb from the port which I maintain (it is below). At first I said impossible because I'd tested things thoroughly, but then noticed he was on a -current system. Digging into things I see that sys/dev/usb/usb.h has had some commits lately that renamed the usb structures. Things like interface_index went to uai_interface_index, etc. Question #1: are there plans to MFC these changes in the USB structures to -stable in the near future? Question #2: If not, is __FreeBSD_version = 500030 the appropriate thing to key off of in order to make a patch set for libusb so that it will compile and work cleanly on a fresh -current? (info obtained from http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-versions.html ) If these changes are not going to be MFC'ed in the near future (i.e. for 4.6-RELEASE) then my tendency is to not put #ifdef flags all over the libusb code testing for FreeBSD-current, but rather to locally patch the source if make(1) can determine it's on a system with the 'new' structures. Comments? -Jr (please cc: as I don't subscribe directly to -current) --- start of forwarded message --- From: Beech Rintoul [EMAIL PROTECTED] Subject: libusb build broken To: [EMAIL PROTECTED] Date: Sun, 24 Feb 2002 08:39:09 -0900 I,m getting the following when trying to compile libusb: rm -f .libs/bsd.lo cc -DHAVE_CONFIG_H -I. -I. -I. -O -pipe -Wall -c bsd.c -Wp,-MD,.deps/bsd.TPlo -fPIC -DPIC -o .libs/bsd.lo bsd.c: In function `usb_set_altinterface': bsd.c:154: structure has no member named `interface_index' bsd.c:155: structure has no member named `alt_no' bsd.c: In function `usb_control_msg': bsd.c:287: structure has no member named `request' bsd.c:288: structure has no member named `request' bsd.c:289: structure has no member named `request' bsd.c:289: structure has no member named `request' bsd.c:289: warning: left-hand operand of comma expression has no effect bsd.c:290: structure has no member named `request' bsd.c:290: structure has no member named `request' bsd.c:290: warning: left-hand operand of comma expression has no effect bsd.c:291: structure has no member named `request' bsd.c:291: structure has no member named `request' bsd.c:291: warning: left-hand operand of comma expression has no effect bsd.c:293: structure has no member named `data' bsd.c:294: structure has no member named `flags' bsd.c:306: structure has no member named `request' bsd.c:306: structure has no member named `request' bsd.c:307: warning: control reaches end of non-void function bsd.c: In function `usb_find_devices_on_bus': bsd.c:324: structure has no member named `addr' bsd.c:330: structure has no member named `devnames' bsd.c:335: structure has no member named `devnames' *** Error code 1 Stop in /usr/ports/devel/libusb/work/libusb-0.1.5. *** Error code 1 My machine is a Celeron 500MHz runing -current (yesterday's build). Beech -- --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - --- end of forwarded message --- -- John Jennifer Reynolds [EMAIL PROTECTED] http://www.reynoldsnet.org/ Senior CAD Engineer, WCCG, Intel Corporation [EMAIL PROTECTED] Running FreeBSD since 2.1.5-RELEASE. FreeBSD: The Power to Serve! Unix is user friendly, it's just particular about the friends it chooses. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libusb build broken due to structure member renaming
* John Reynolds [EMAIL PROTECTED] [020224 14:33] wrote: hello, I've got a -current-related question to ask. akbeech forwarded me his build log when trying to build the linux user-land libusb from the port which I maintain (it is below). At first I said impossible because I'd tested things thoroughly, but then noticed he was on a -current system. Digging into things I see that sys/dev/usb/usb.h has had some commits lately that renamed the usb structures. Things like interface_index went to uai_interface_index, etc. Question #1: are there plans to MFC these changes in the USB structures to -stable in the near future? I did that last night. Question #2: If not, is __FreeBSD_version = 500030 the appropriate thing to key off of in order to make a patch set for libusb so that it will compile and work cleanly on a fresh -current? I didn't bump FreeBSD_version specifically for it although I guess I will be now. In both -current and -stable. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [Patch: clarity] Re: PNP0303 can't assign resources
Alfred Perlstein wrote: * Terry Lambert [EMAIL PROTECTED] [020224 13:12] wrote: Try the following patch; the failure message will be somewhat less cryptic, since it will tell you the proximal reason for failure out of the 5 possibles for the message you are seeing. 8-). Cool explanation, the attached patch was committed but had to be modified because it wouldn't apply cleanly. Was it meant for -stable? Ugh. Should have done a context diff. Yeah, it was against 4.5-stable on my machine here. I can't upgrade that particular machine for you-know-why. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libusb build broken due to structure member renaming
John Reynolds wrote: hello, I've got a -current-related question to ask. akbeech forwarded me his build log when trying to build the linux user-land libusb from the port which I maintain (it is below). At first I said impossible because I'd tested things thoroughly, but then noticed he was on a -current system. Digging into things I see that sys/dev/usb/usb.h has had some commits lately that renamed the usb structures. Things like interface_index went to uai_interface_index, etc. Question #1: are there plans to MFC these changes in the USB structures to -stable in the near future? Dunno. Ask Alfred. He made the changes, on my advice, because there was a namespace collision with a C++ reserved word. I don't think there was a requirement to keep things portable between the versions. Usually, this kind of thing makes it back as an MFC, eventually. If you want to back-port the changes as a patch, I think Alfred would commit it for you. Question #2: If not, is __FreeBSD_version = 500030 the appropriate thing to key off of in order to make a patch set for libusb so that it will compile and work cleanly on a fresh -current? Yes, usually. In this case, it should be true. If these changes are not going to be MFC'ed in the near future (i.e. for 4.6-RELEASE) then my tendency is to not put #ifdef flags all over the libusb code testing for FreeBSD-current, but rather to locally patch the source if make(1) can determine it's on a system with the 'new' structures. Comments? Probably a patch would help?... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libusb build broken due to structure member renaming
Terry Lambert wrote: Question #1: are there plans to MFC these changes in the USB structures to -stable in the near future? Too late. Alfred is too fast. Question #2: If not, is __FreeBSD_version = 500030 the appropriate thing to key off of in order to make a patch set for libusb so that it will compile and work cleanly on a fresh -current? See Alfred's posting; he's promised to bump things. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assemblyrevamp, please review!
On Sun, 24 Feb 2002, Matthew Dillon wrote:
NOTES:
I would like to thank Bruce for supplying the sample code that allowed
me to do this in a day instead of several days.
Thanks.
* debug.critical_mode sysctl. This will not be in the final commit,
nor will any of the code that tests the variable. The final commit
will use code as if the critical_mode were '1'.
Won't it be needed for longer for non-i386's arches?
* Additional cpu_critical_enter/exit() calls around icu_lock. Since
critical_enter() no longer disables interrupts, special care must
be taken when dealing with the icu_lock spin mutex because it is
the one thing the interrupt code needs to be able to defer the
interrupt.
clock_lock needs these too, at least in my version where the soft
critical_enter() doesn't mask fast interrupts.
* MACHINE_CRITICAL_ENTER define. This exists to maintain compatibility
with other architectures. i386 defines this to cause fork_exit to
use the new API and to allow the i386 MD code to supply the
critical_enter() and critical_exit() procedures rather then
kern_switch.c
I would much prefer it if the other architectures were brought around
to use this new mechanism. The old mechanism makes assumptions
in regards to hard disablement that is no longer correct for i386.
The old mechanism basically forces mtx_lock_spin() to do the hard disablement.
I never liked this.
* Trampoline 'sti'. In the final commit, the trampoline will simply
'sti' after setting up td_critnest. The other junk to handle the
hard-disablement case will be gone.
Maybe all of the fiddling with sched_lock belongs in MD code.
IIRC, in my version, the hard interrupt enablement in fork_exit() is
only needed at boot time. Something neglects to do it earlier in that
case, at least for some threads. I was surprised by this -- hard
interrupts are enabled early in the boot, and everything later should
disable and enable them reentrantly.
* Additional cpu_critical_enter()/exit() calls in CY and TIMER code.
Bruce had additional hard interrupt disablements in these modules.
I'm not sure why so if I need to do that as well I would like to
know.
There are also some in sio. The ones in sio an cy are needed because
my critical_enter() doesn't mask fast interrupts. Something is needed
to mask them, and cpu_critical_enter() is used. I think you don't need
these yet. The ones in timer code are to make the timer code as hard-
real-time as possible. I think this is important in
i8254_get_timecounter() but not elsewhere in clock.c.
Index: i386/i386/machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.497
diff -u -r1.497 machdep.c
--- i386/i386/machdep.c 17 Feb 2002 17:40:28 - 1.497
+++ i386/i386/machdep.c 24 Feb 2002 19:04:20 -
...
@@ -270,6 +275,121 @@
}
/*
+ * Critical section handling.
+ *
+ * Note that our interrupt code handles any interrupt race that occurs
+ * after we decrement td_critnest.
+ */
+void
+critical_enter(void)
i386/machdep.c is a different wrong place for this and unpend(). I put it
in isa/ithread.c. It is not very MD, and is even less isa-dependent.
+void
+critical_exit(void)
+{
+ struct thread *td = curthread;
+ KASSERT(td-td_critnest 0, (bad td_critnest value!));
+ if (--td-td_critnest == 0) {
+ if (td-td_savecrit != (critical_t)-1) {
+ cpu_critical_exit(td-td_savecrit);
+ td-td_savecrit = (critical_t)-1;
+ } else {
+ /*
+ * We may have to schedule pending interrupts. Create
+ * conditions similar to an interrupt context and call
+ * unpend().
+ */
+ if (PCPU_GET(int_pending) td-td_intr_nesting_level == 0) {
I'm trying to kill td_intr_nesting_level. I think/hope you don't need it.
In ithread_schedule(), we begin with interrupts hard-enabled but don't
have any other locks, so things are delicate -- an mtx_unlock_spin()
immediately after the mtx_lock_spin() would do too much without the above
test. Perhaps add a critical_enter()/critical_exit() wrapper to sync the
software interrupt disablement with the hardware disablement. Xfastintr*
in -current already does this.
Index: i386/isa/apic_vector.s
===
RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v
retrieving revision 1.75
diff -u -r1.75 apic_vector.s
--- i386/isa/apic_vector.s5 Jan 2002 08:47:10 - 1.75
+++ i386/isa/apic_vector.s24 Feb 2002 17:58:34 -
Please do this without so many changes to the assembly code. Especially
not the reordering and style changes. I think I see how to do this
(see
Re: Patch for critical_enter()/critical_exit() interrupt assemblyrevamp, please review!
: :On Sun, 24 Feb 2002, Matthew Dillon wrote: : : * debug.critical_mode sysctl. This will not be in the final commit, : nor will any of the code that tests the variable. The final commit : will use code as if the critical_mode were '1'. : :Won't it be needed for longer for non-i386's arches? No, 99% of it is in 386-specific files, it won't effect other arches. : * Additional cpu_critical_enter/exit() calls around icu_lock. Since : critical_enter() no longer disables interrupts, special care must : be taken when dealing with the icu_lock spin mutex because it is : the one thing the interrupt code needs to be able to defer the : interrupt. : :clock_lock needs these too, at least in my version where the soft :critical_enter() doesn't mask fast interrupts. I wasn't sure whether it was due to that, or whether you just wanted the two I8254 accesses to be right next to each other. Since I am msking fast interrupts I think we are safe. : * MACHINE_CRITICAL_ENTER define. This exists to maintain compatibility :.. : : I would much prefer it if the other architectures were brought around : to use this new mechanism. The old mechanism makes assumptions : in regards to hard disablement that is no longer correct for i386. : :The old mechanism basically forces mtx_lock_spin() to do the hard disablement. :I never liked this. In my case, the term 'dislike' would be an understatement. Every time I looked at what critical_enter() was doing I got angry. Heh. : * Trampoline 'sti'. In the final commit, the trampoline will simply : 'sti' after setting up td_critnest. The other junk to handle the : hard-disablement case will be gone. : :Maybe all of the fiddling with sched_lock belongs in MD code. I think it wound up outside of MD because the only other place to put it is in cpu_switch() (assembly), and people are understandably trying to avoid imposing more assembly on all the architectures. I'm willing to leave it be for now but I agree that it is really ugly. :IIRC, in my version, the hard interrupt enablement in fork_exit() is :only needed at boot time. Something neglects to do it earlier in that :case, at least for some threads. I was surprised by this -- hard :interrupts are enabled early in the boot, and everything later should :disable and enable them reentrantly. I couldn't figure out who was leaving hard interrupts enabled. Did you ever figure out who it was? At the moment I am able to enable interrupts in the trampoline code just before the call to fork_exit(), but it has to be disabled on entry to the trampoline code because the task's td_critnest count is still 0 at that point and we can't afford to execute a real (fast) interrupt's service routine until we clean up the sched_lock. : * Additional cpu_critical_enter()/exit() calls in CY and TIMER code. : Bruce had additional hard interrupt disablements in these modules. : : I'm not sure why so if I need to do that as well I would like to : know. : :There are also some in sio. The ones in sio an cy are needed because :my critical_enter() doesn't mask fast interrupts. Something is needed :to mask them, and cpu_critical_enter() is used. I think you don't need :these yet. The ones in timer code are to make the timer code as hard- :real-time as possible. I think this is important in :i8254_get_timecounter() but not elsewhere in clock.c. Ok, that's what I thought. Since I am masking fast interrupts I believe we are safe there too. In regards to i8254_get_timecounter() the 8254 latches the full count on the first access so we are theoretically safe. I'll change my timecounter to use the 8254 to see if it still works as expected. :... : /* : + * Critical section handling. : + * : + * Note that our interrupt code handles any interrupt race that occurs : + * after we decrement td_critnest. : + */ : +void : +critical_enter(void) : :i386/machdep.c is a different wrong place for this and unpend(). I put it :in isa/ithread.c. It is not very MD, and is even less isa-dependent. Yah. I'm all ears as to where to put it :-) There's no good place to put inline versions of critical_enter() or critical_exit() either. machine/cpufunc.h doesn't have access to the struct thread. p.s. all discussion here and below, except for the bintr/eintr cleanup, would be for a second work/commit round after I commit the current stuff. :I'm trying to kill td_intr_nesting_level. I think/hope you don't need it. :In ithread_schedule(), we begin with interrupts hard-enabled but don't :have any other locks, so things are delicate -- an mtx_unlock_spin() :immediately after the mtx_lock_spin() would do too much without the above :test. Perhaps add a critical_enter()/critical_exit() wrapper to sync the :software interrupt disablement with the
New pam doesn't work with xdm 4.2
I installed XFree86 version 4.2 in binary format from the xfree86.org website. I just upgraded my -current installation to today's latest bits, and now I can't log in with xdm. This is the output to the console (minus date/host info for readability): PAM unable to dlopen(/usr/lib/pam_unix.so) PAM [dlerror: /usr/lib/pam_unix.so: Undefined symbol setnetconfig] PAM adding faulty module: /usr/lib/pam_unix.so PAM unable to dlopen(/usr/lib/pam_opie.so) PAM [dlerror: /usr/lib/libopie.so.2: Undefined symbol __xuname] PAM adding faulty module: /usr/lib/pam_opie.so PAM unable to dlopen(/usr/lib/pam_opieaccess.so) PAM [dlerror: /usr/lib/libopie.so.2: Undefined symbol __xuname] PAM adding faulty module: /usr/lib/pam_opieaccess.so This is my home workstation, so I can just use startx for now, but this should be fixed long term. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current hangs with SMP enabled
I've got a SMP machine with a Supermicro P3TDE6 motherboard. (Serverworks HE-SL chipset, dual 1.26GHz Pentium III's.) It boots just fine with a GENERIC -current kernel (sources cvsupped yesterday at ~1500 MST), but hangs (at the Waiting 15 seconds for SCSI devices to settle message) when SMP and APIC_IO are enabled. Those two options are the only things different between the broken and working GENERIC kernels. I've attached dmesg output from the stock GENERIC kernel. Anyone have any ideas on how to get SMP working? Thanks, Ken -- Kenneth Merry [EMAIL PROTECTED] Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sun Feb 24 17:29:36 MST 2002 [EMAIL PROTECTED]:/usr/home/ken/perforce/FreeBSD-ken/src/sys/i386/compile/GENERIC Preloaded elf kernel /boot/kernel.GENERIC.new/kernel at 0xc0564000. Preloaded elf module /boot/kernel.GENERIC.new/acpi.ko at 0xc05640b4. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1266068202 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1266.07-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 2684289024 (2621376K bytes) avail memory = 2608848896 (2547704K bytes) Pentium Pro MTRR support enabled Using $PIR table, 10 entries at 0xc00f52e0 ACPI-0204: *** Error: AcpiLoadTables: Could not load namespace: AE_NOT_FOUND ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NOT_FOUND ACPI: table load failed: AE_NOT_FOUND npx0: math processor on motherboard npx0: INT 16 interface pcib0: ServerWorks host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 0.1 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) ahc0: Adaptec aic7899 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xfeafc000-0xfeafcfff irq 5 at device 5.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: Adaptec aic7899 Ultra160 SCSI adapter port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 10 at device 5.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255 SCBs fxp0: Intel Pro 10/100B/100+ Ethernet port 0xd400-0xd43f mem 0xfe90-0xfe9f,0xfeafd000-0xfeafdfff irq 9 at device 6.0 on pci0 fxp0: Ethernet address 00:30:48:21:bb:74 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge port 0x580-0x58f at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: ServerWorks ROSB4 ATA33 controller port 0xffa0-0xffaf at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ohci0: OHCI (generic) USB controller mem 0xfeafe000-0xfeafefff irq 10 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (unknown) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib2: ServerWorks host to PCI bridge at pcibus 2 on motherboard pci2: PCI bus on pcib2 pci2: network, ethernet at device 2.0 (no driver attached) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it orm0: Option ROMs at iomem 0xd1800-0xd27ff,0xc-0xcbfff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 pmtimer0 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Waiting 15 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318406LW 0108 Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST318406LW 0108 Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors:
Re: Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
I'm not fluent in x86 asm, so can you confirm for me what you're attempting to do here? I think you're making critical_enter()/critical_exit() cheaper by not actually messing with the interrupt hardware when they're called. Very much like what we do in 4-stable. Instead, you set/clear a per-cpu flag (or incr/decr a counter). If an interrupt comes in when you're inside a critical section, you make note of it mask interrupts on that cpu. In critical_exit(), you run the interrupt handler if there's a pending interrupt, and unmask interrupts. If there's not a pending interrupt, you just clear the flag (or devrement a counter). Is that basically it? If so, I'm wondering if this is even possible on alpha, where we don't have direct access to the hardware. However, according to the psuedo code for rti in the Brown book, munging with the saved PSL in trapframe to set the IPL should work. Hmm.. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current hangs with SMP enabled
* Kenneth D. Merry [EMAIL PROTECTED] [020224 16:56] wrote: I've got a SMP machine with a Supermicro P3TDE6 motherboard. (Serverworks HE-SL chipset, dual 1.26GHz Pentium III's.) It boots just fine with a GENERIC -current kernel (sources cvsupped yesterday at ~1500 MST), but hangs (at the Waiting 15 seconds for SCSI devices to settle message) when SMP and APIC_IO are enabled. Those two options are the only things different between the broken and working GENERIC kernels. I've attached dmesg output from the stock GENERIC kernel. Anyone have any ideas on how to get SMP working? I've had the same problem for a while now. Best of luck. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Success! critical_enter()/critical_exit() revamp (was Re:malloc_bucket() idea (was Re: How to fix malloc.))
On Sun, 24 Feb 2002, Matthew Dillon wrote: Bruce, your sys.dif was *invaluable*! It would have taken me a lot longer to figure out the interrupt disablement requirement around the icu_lock, and the statclock and hardclock forwarding issues (which I got working by the way!). Thanks. It turns out that putting the pending masks in the per-cpu area was the right solution! It made statclock and hardclock forwarding easy (I can see why you didn't even try in your patch set, doing it with a global mask would be nearly impossible). In fact, it made everything unbelievably easy. ... [This paragraph reordered] up. One of the best things about this patch set is that it is really flexible. We should be able to really make interrupts fly. In fact, it should even be possible for one cpu to steal another cpu's pending interrupt(s) fairly trivially, without having to resort to IPIs. Good idea. Stealing would be even easier if the mask were global :-). The second issue is that cpu_switch() does not save/restore the PSL_I (interrupt disablement mask). I added a PSL word to the PCB structure to take care of the problem. Without this if you have a thread switch away while holding interrupts hard-disabled, the next thread will inherit the hard disablement. I saw the sti's you added in various places but I figured the best solution was to simply save/restore the state. The original code didn't have cpu_switch() certainly needs to do this if it can be called with the interrupt enable flag[s] in different states. I need the sti's (actually enable_intr()'s because I don't want fast interrupts to be disabled during context switches. This works because enabling interrupts is sure to be safe, since we might be switching to a thread that will enable them. Some sort of lock is needed to prevent interrupts interfering with the switch. I think soft-masking them in critical_enter() is sufficient in your version too. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current hangs with SMP enabled
+---[ Kenneth D. Merry ]-- | | I've got a SMP machine with a Supermicro P3TDE6 motherboard. (Serverworks | HE-SL chipset, dual 1.26GHz Pentium III's.) | | It boots just fine with a GENERIC -current kernel (sources cvsupped | yesterday at ~1500 MST), but hangs (at the Waiting 15 seconds for SCSI | devices to settle message) when SMP and APIC_IO are enabled. I have a similar problem with -current and SMP. Heavy I/O on the SCSI system (say a buildworld or even an FSCK) causes a hang (no panic). I think interrupts go off and stay off. This happens with both the onboard and UFW PCI card, both Adaptec with ACPI on and off (it's happened since SMPng started, I figured it was one of those things that'd get fixed eventually). Although Matt's latest patches make me think it might be sooner rather than later, so I'll be crash testing again next weekend methinks. ahc0: Adaptec aic7895 Ultra SCSI adapter port 0xd400-0xd4ff mem 0xedfee000-0xedfeefff irq 10 at device 9.0 on pci0 aic7895C: Ultra Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: Adaptec aic7895 Ultra SCSI adapter port 0xd800-0xd8ff mem 0xedfef000-0xedfe irq 10 at device 9.1 on pci0 aic7895C: Ultra Wide Channel B, SCSI Id=7, 32/255 SCBs ahc2: Adaptec 2940 Ultra SCSI adapter port 0xd000-0xd0ff mem 0xedfed000-0xedfedfff irq 9 at device 15.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs I try an SMP kernel about once a month. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
:I think you're making critical_enter()/critical_exit() cheaper by not
:actually messing with the interrupt hardware when they're called.
:Very much like what we do in 4-stable.
:
:Instead, you set/clear a per-cpu flag (or incr/decr a counter). If an
:interrupt comes in when you're inside a critical section, you make
:note of it mask interrupts on that cpu. In critical_exit(),
:you run the interrupt handler if there's a pending interrupt, and
:unmask interrupts. If there's not a pending interrupt, you just clear
:the flag (or devrement a counter).
:
:Is that basically it?
Right. And it turns out to be a whole lot easier to do in -current
because we do not have the _cpl baggage.
Basically critical_enter() devolves down into:
++td-td_critnest
And critical_exit() devolves down into:
if (--td-td_critnest == 0 PCPU_GET(int_pending))
_deal_with_interupts_marked_pending()
As we found with the lazy spl()s in -stable, this is a
huge win-win situation because no interrupts typically
occur while one is in short-lived critical sections. On
-current, critical sections are for spin locks (i.e. mainly
the sched_lock) and in a few other tiny pieces of code and
that is pretty much it. It is a far better situation then
the massive use of spl*()'s we see in -stable and once Giant
is gone it is going to be pretty awesome.
:If so, I'm wondering if this is even possible on alpha, where we don't
:have direct access to the hardware. However, according to the psuedo
:code for rti in the Brown book, munging with the saved PSL in
:trapframe to set the IPL should work. Hmm..
:
:Drew
Well, on IA32 there are effectively two types of interrupts (edge
and level triggered), and three interrupt masks (the processor
interrupt disable, a master bit mask, and then the per-device
masks), and two ways of handling interrupts (as a scheduled
interrupt thread or as a 'fast' interrupt).
Note that the masking requirement is already part and parcel in
-current because most interrupts are now scheduled. The hardware
interrupt routine must schedule the interrupt thread and then
mask the interrupt since it is not dealing with it right then
and there and must be able to return to whatever was running before.
The interrupt thread will unmask the interrupt when it is through
processing it.
But *which* mask one is able to use determines how efficiently
one can write critical_enter() and critical_exit(). On IA32 we
can use the master bit mask instead of the processor interrupt
disable which allows the optimization you see in this patch set.
--
On alpha if you are only able to use the process interrupt disable
you can still optimizatize critical_enter() and critical_exit(). That
is, you can do this:
critical_enter():
++td-td_critnest;
critical_exit()
if (--td-td_critnest == 0 PCPU_GET(int_pending)) {
PCPU_SET(int_pending, 0);
if (PCPU_GET(ipending))
deal_with_pending_edge_triggered_ints();
enable_hardware_interrupts();
(level triggered ints will immediately cause an
interrupt which, since critnest is 0, can now be
taken)
}
hard interrupt vector code:
if (curthread-td_critnest) {
Save any edge triggered interrupts to a bitmap
somewhere (i.e. ipending |= 1 irq_that_was_taken).
adjust return frame such that the restored PSL
has interrupts disabled so it does not immediately
re-enter the hardware interrupt vector code.
}
As you can see, it should be possible to make critical_enter()
and critical_exit() streamlined even on architectures where you
may not have direct access to interrupt masks. In fact, I
considered doing exactly this for the I386 but decided that it
was cleaner to mask level interrupts and throw everything into
the same ipending hopper.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Success! critical_enter()/critical_exit() revamp (was Re:malloc_bucket() idea (was Re: How to fix malloc.))
: up. One of the best things about this patch set is that it is really
: flexible. We should be able to really make interrupts fly. In fact,
: it should even be possible for one cpu to steal another cpu's pending
: interrupt(s) fairly trivially, without having to resort to IPIs.
:
:Good idea. Stealing would be even easier if the mask were global :-).
Well, for the moment I am attempting to avoid having to use lock;'d
bus cycles to keep things efficient. When we get to the stealing part
we might wind up using lock;, but I'll deal with that when the time
comes.
: The second issue is that cpu_switch() does not save/restore the
: PSL_I (interrupt disablement mask). I added a PSL word to the PCB
: structure to take care of the problem. Without this if you have
: a thread switch away while holding interrupts hard-disabled, the
: next thread will inherit the hard disablement. I saw the sti's
: you added in various places but I figured the best solution was
: to simply save/restore the state. The original code didn't have
:
:cpu_switch() certainly needs to do this if it can be called with the
:interrupt enable flag[s] in different states. I need the sti's (actually
:enable_intr()'s because I don't want fast interrupts to be disabled
:during context switches. This works because enabling interrupts is sure
:to be safe, since we might be switching to a thread that will enable
:them. Some sort of lock is needed to prevent interrupts interfering
:with the switch. I think soft-masking them in critical_enter() is
:sufficient in your version too.
:
:Bruce
I don't think we want to make sched_lock any more complex then it
already is, so at least for the foreseeable future we are not
going to be able to actually execute an interrupt handler until
the sched_lock is released in (typically) msleep(). I am rather
annoyed that two levels of procedure have to be called with the
sched_lock held (mi_switch() and cpu_switch()), leaving interrupts
disabled for a fairly long period of time, but I don't see any way
around it right now.
Eventually (presumably) we will have per-cpu run queues. That combined
with interrupt stealing may resolve the problem for us. I am still
not convinced that making the various *pending* flags globals will
be more efficient, because it introduces significant cache mastership
issues. It might be easier to do this:
interrupt_vector
{
if (td-td_critnest) {
... try to forward the interrupt to another cpu that is not
in a critical section ...
... else set bit in local ipending mask.
} else {
... take or schedule interrupt ...
}
}
Or possibly:
interrupt_vector
{
if (td-td_critnest) {
if (!mtx_owned(sched_lock) mtx_trylock(sched_lock)) {
... we can still schedule the interrupt even
though we are in a critical section, we
just can't switch to it yet ...
} else {
... try to forward the interrupt to a cpu that is not
in a critical section ...
... else set bit in local ipending mask.
}
} else {
... take or schedule interrupt ...
}
}
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: -current hangs with SMP enabled
There is a problem in -Current now between SCSI card(s) and the ATA drivers, On my Dell 410 Workstation at work I commetned out the ATA driver stuff (it was not used on that machine) and it booted fine, I think that might just cure the SMP problem you are seeing too. At 11:15 AM 2/25/2002 +1000, Andrew Kenneth Milton wrote: +---[ Kenneth D. Merry ]-- | | I've got a SMP machine with a Supermicro P3TDE6 motherboard. (Serverworks | HE-SL chipset, dual 1.26GHz Pentium III's.) | | It boots just fine with a GENERIC -current kernel (sources cvsupped | yesterday at ~1500 MST), but hangs (at the Waiting 15 seconds for SCSI | devices to settle message) when SMP and APIC_IO are enabled. I have a similar problem with -current and SMP. Heavy I/O on the SCSI system (say a buildworld or even an FSCK) causes a hang (no panic). I think interrupts go off and stay off. This happens with both the onboard and UFW PCI card, both Adaptec with ACPI on and off (it's happened since SMPng started, I figured it was one of those things that'd get fixed eventually). Although Matt's latest patches make me think it might be sooner rather than later, so I'll be crash testing again next weekend methinks. ahc0: Adaptec aic7895 Ultra SCSI adapter port 0xd400-0xd4ff mem 0xedfee000-0xedfeefff irq 10 at device 9.0 on pci0 aic7895C: Ultra Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: Adaptec aic7895 Ultra SCSI adapter port 0xd800-0xd8ff mem 0xedfef000-0xedfe irq 10 at device 9.1 on pci0 aic7895C: Ultra Wide Channel B, SCSI Id=7, 32/255 SCBs ahc2: Adaptec 2940 Ultra SCSI adapter port 0xd000-0xd0ff mem 0xedfed000-0xedfedfff irq 9 at device 15.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs I try an SMP kernel about once a month. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current hangs with SMP enabled
On Sun, Feb 24, 2002 at 21:02:02 -0500, Glenn Gombert wrote: There is a problem in -Current now between SCSI card(s) and the ATA drivers, On my Dell 410 Workstation at work I commetned out the ATA driver stuff (it was not used on that machine) and it booted fine, I think that might just cure the SMP problem you are seeing too. Thanks for the suggestion. Unfortunately it still hangs with SMP enabled and the ATA drivers commented out of the GENERIC config. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
linprocfs or mount appears broken
cvsup sources from 24 FEB 02 at 14:42 PST. No local patches (although I would like to play with Matt's recent work). Standard update sequence (i.e., rm -rf /usr/obj/* buildworld, buildkernel, installkernel, installworld, mergemaster) yields KLD linprocfs.ko: depends on linux - not available linprocfs: vfsload(linprocfs): Exec format error Mounting /etc/fstab filesystems failed, startup aborted Enter full pathname of shell or RETURN for /bin/sh /boot/loader.conf contains linux_load=YES kldstat at the single user prompt shows that the linux.ko module was loaded. The system does not panic or hang. It just drops into single user mode. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: snapshots? WAS: Re: -CURRENT in pretty good shape, after all
On Sun, Feb 24, 2002 at 03:08:27PM +0100, Harald Schmalzbauer wrote: Since I changed my employer I made new subscriptions at bsdmall.com but I couldn't find any snapshot subscription. Daemonnews has never sold snapshots, although that may be something they will do in the future. You can buy a subscription to FreeBSD Snapshot discs from FreeBSD Mall, Inc here : http://www.freebsdmall.com [Click on Software, then click on a single snapshot, or a snapshot subscription.] If I remember correctly, I built that April 2000 snapshot CD, and I'll be making them a lot more regularly from now on. I had to throw away at least one ISO in late 2000 because the -CURRENT snapshot would not install or pass even the most minimum usability tests. We (release engineers) are going to do a lot more polishing in the coming weeks to ensure that FreeBSD 5.0 Developer Preview 1 (DP1) is in good shape so that more people can start running -CURRENT again. Thanks, - Murray To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
Matt, Thanks for the great explanation! Hopefully, I'll get a chance to try this for alpha (though I won't mind if somebody beats me to it). I've also been meaning to get iprobe (kernel profiler) going again too, to find out why -current on alpha sucks so badly right now. (your gettimeofday() syscall test shows that -current has over 2x the overhead for syscalls on alpha, even w/o INVARIANTS). Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New pam doesn't work with xdm 4.2
You need a different version for -current than for -stable. Make sure you have the right version. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
Apparently, On Sun, Feb 24, 2002 at 11:12:22AM -0800,
Matthew Dillon said words to the effect of;
NOTES:
I would like to thank Bruce for supplying the sample code that allowed
me to do this in a day instead of several days.
* debug.critical_mode sysctl. This will not be in the final commit,
nor will any of the code that tests the variable. The final commit
will use code as if the critical_mode were '1'.
The default is 1, which means to use the new streamlined
interrupt and cpu_critical_enter/exit() code. Setting it to 0
will revert to the old hard-interrupt-disablement operation. You
can change the mode at any time.
* Additional cpu_critical_enter/exit() calls around icu_lock. Since
critical_enter() no longer disables interrupts, special care must
be taken when dealing with the icu_lock spin mutex because it is
the one thing the interrupt code needs to be able to defer the
interrupt.
* MACHINE_CRITICAL_ENTER define. This exists to maintain compatibility
with other architectures. i386 defines this to cause fork_exit to
use the new API and to allow the i386 MD code to supply the
critical_enter() and critical_exit() procedures rather then
kern_switch.c
I would much prefer it if the other architectures were brought around
to use this new mechanism. The old mechanism makes assumptions
in regards to hard disablement that is no longer correct for i386.
For sparc64 we basically already have this in hardware. There is both
an interrupt enable (IE) bit and a soft interrupt priority. Hardware
interrupts are masked by the IE bit. In all cases they just queue the
interrupt packet that is sent by the hardware in a per-cpu interrupt
queue and post a soft interrupt. The critical_* stuff only masks soft
interrupts; hard interrupts are rarely masked. The queueing is written
in assmebler and runs outside of the kernel so it is fast. Traps in
general are fast because they don't touch memory until the trapframe
is written out, so I don't see much point in changing this do the masking
in software and avoid the soft interrupt.
In regards to the patch I think that making critical_enter/exit MD in
certain cases is a mistake. cpu_critical_enter/exit are already MD
and it looks you could hide this behind them with some minor changes.
Like in the critical_enter case, make cpu_critical_enter take a thread
as its argument. It could be a null macro in the i386 case, which would
optimize out the test.
if (td-td_critnest == 0)
cpu_critical_enter(td);
td-td_critnest++;
Likewise with cpu_critical_exit, make it take the thread as its argument.
If (td-td_critnest == 1) {
td-td_critnest = 0;
cpu_critical_exit(td);
} else
td-td_critnest--;
(This is equivalent to if (--td-td_critnest == 0), its a matter of taste.)
The fork case is a little different, hmm. I'd have to think about it more.
An md function/macro would probably suffice.
I notice the you are using cpu_critical_exit for the purpose of disabling
interrupts only, like cli, sti. I think that you should use api that tmm
wrote for sparc64 for this so that it can do more. i386 does not really
have cli/sti equivalents otherwise.
s = intr_disable() disables interrupts and returns the old state.
intr_restore(s) restores the state s.
I don't really like this change in general because it complicates things
more than I'd like, but I also don't have a bearing on how expensive cli/sti
are. It would seem to me that it just takes a few more clock cycles, which
isn't that important. I understand that it increases latency for the fast
part of the interrupt handler, but they are not able to run in critical
sections anyway due to the software masking.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
FreeBSD/i386 make release breakage
Current 5-current fails 'make release' when processing release.4 target (making a crunch binary). Here's sample session: === doc rm -f cpio.info cpio.info.gz rm -f .depend /usr/obj/usr/src/gnu/usr.bin/cpio/GPATH /usr/obj/usr/src/gnu/usr.bin/cpio/GRTAGS /usr/obj/usr/src/gnu/usr.bin/cpio/GSYMS /usr/obj/usr/src/gnu/usr.bin/cpio/GTAGS === doc make: don't know how to make dhclient_clean. Stop src/sbin/dhclient/Makefile doesn't know 'dhclient_clean' target. % cd /usr/src/sbin/dhclient % make -n dhclient_clean make: don't know how to make dhclient_clean. Stop It seems that crunchgen misunderstands src/sbin/dhclient/Makefile, and fails to generate a Makefile for crunch binary. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 make release breakage
Ouch. matusita src/sbin/dhclient/Makefile doesn't know 'dhclient_clean' target. Of course that's normal, dhclient_clean target should be created by crunchgen. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New pam doesn't work with xdm 4.2
M. Warner Losh wrote: You need a different version for -current than for -stable. Make sure you have the right version. Version of what? There are no freebsd 5 binaries on xfree86.org's website that I can see. I hope you're not saying that binary compatability is broken by design in 5.0... -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New pam doesn't work with xdm 4.2
In message: [EMAIL PROTECTED] Doug Barton [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : You need a different version for -current than for -stable. Make sure : you have the right version. : : Version of what? There are no freebsd 5 binaries on xfree86.org's : website that I can see. I hope you're not saying that binary : compatability is broken by design in 5.0... I'm saying that PAM doesn't have versioning, so PAM modules are compatible between 4.x and 5.x. You must rebuild X under -current. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current hangs with SMP enabled
On Sun, Feb 24, 2002 at 09:02:02PM -0500, Glenn Gombert wrote: There is a problem in -Current now between SCSI card(s) and the ATA drivers, For how long has this problem existed? This is being typed from a dual Athlon system with 5 SCSI busses (AHC,SYM,ISP) several disks, CD burnger; and with two IDE disks + ATAPI CDROM drive. FreeBSD dragon.nuxi.com 5.0-CURRENT FreeBSD #238: Fri Feb 22 21:56:02 PST 2002 I would really have noticed if my p0rn IDE disk and my SCSI system disk were not usable at the same time. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
:...
:interrupts; hard interrupts are rarely masked. The queueing is written
:in assmebler and runs outside of the kernel so it is fast. Traps in
:general are fast because they don't touch memory until the trapframe
:is written out, so I don't see much point in changing this do the masking
:in software and avoid the soft interrupt.
I have no idea what you are talking about Jake. Could you supply
some context?
:In regards to the patch I think that making critical_enter/exit MD in
:certain cases is a mistake. cpu_critical_enter/exit are already MD
:and it looks you could hide this behind them with some minor changes.
:
:Like in the critical_enter case, make cpu_critical_enter take a thread
:as its argument. It could be a null macro in the i386 case, which would
:optimize out the test.
:
:if (td-td_critnest == 0)
: cpu_critical_enter(td);
:td-td_critnest++;
:
:Likewise with cpu_critical_exit, make it take the thread as its argument.
:
:If (td-td_critnest == 1) {
: td-td_critnest = 0;
: cpu_critical_exit(td);
:} else
: td-td_critnest--;
:(This is equivalent to if (--td-td_critnest == 0), its a matter of taste.)
I'm afraid I have to strongly disagree. I believe that
critical_enter()/exit is *ALREADY* being severely misused in current.
For example, fork_exit() makes assumptions about the underlying hardware
in order to initialize td_critnest and the scheduler mutex safely. This
is just plain broken. fork_exit() should not make any such assumptions.
It is the clear responsibility of either the trampoline code or
cpu_fork() to properly set up td_critnest. One can make an argument
that the sched_lock fixup is in fork_exit()'s domain but you cannot
make the argument that the initialization of critnest (and any associated
hardware state) is MI. It just isn't.
Additionally, critical_enter()/exit themselves are certainly much
more MD then MI. It makes little sense to abstract out an MI interface
that forces unnecessary overhead when all you have to do is define an
MD API that has a few MI requirements, like td_critnest being a critical
nesting count that the MI code can count on. But as MI code the existing
critical_enter()/exit impose additional MD fields and do not give the
MD code the option of not using them (except in a degenerate fashion).
Specifically, the use of the td_savecrit field is under the partial
contorl of the MI code when it shouldn't be, not just in fork_exit()
but also in critical_enter() and critical_exit() themselves.
The existing critical_enter/exit code is far too abstracted for its
low-level purpose and I *WILL* be moving them into MD sections of the
system where they belong. These are really MD routines, not MI routines.
:I notice the you are using cpu_critical_exit for the purpose of disabling
:interrupts only, like cli, sti. I think that you should use api that tmm
:wrote for sparc64 for this so that it can do more. i386 does not really
:have cli/sti equivalents otherwise.
:...
:s = intr_disable() disables interrupts and returns the old state.
:intr_restore(s)restores the state s.
:
:I don't really like this change in general because it complicates things
:more than I'd like, but I also don't have a bearing on how expensive cli/sti
:are. It would seem to me that it just takes a few more clock cycles, which
:isn't that important. I understand that it increases latency for the fast
:part of the interrupt handler, but they are not able to run in critical
:sections anyway due to the software masking.
:
:Jake
Removing cli and sti from the critical functions saves us 300 ns on
every single system call, interrupt, and most traps. And that's with the
sysctl instrumentation and without them being inlined. With the sysctl
instrumentation removed and with critical_enter() and critical_exit()
inlined my guess is that we will save on the order of 500 ns. This
is not insignificant on a P3, and it will probably save even more on
a P4.
With critical_enter() and critical_exit() moved into MD sections, we
can do away with cpu_critical_enter() and cpu_critical_exit() (that is,
make them specific to the MD implementation of critical_enter() and
critical_exit() on those platforms that want to keep the two-layer
abstraction). But for I386 I suppose I could just rename them
to intr_disable() and intr_restore(). I don't understand your
comment about functionality, they work just fine. It's just the name
that needs changing.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: New pam doesn't work with xdm 4.2
On Sun, Feb 24, 2002 at 08:46:45PM -0700, M. Warner Losh wrote: You need a different version for -current than for -stable. Make sure you have the right version. I got the same problem with Xwrapper -- and it was compiled on this 5-CURRENT w/in the past 6 months. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 make release breakage
At 01:27 PM 2/25/2002 +0900, Makoto Matsushita wrote: Current 5-current fails 'make release' when processing release.4 target (making a crunch binary). Here's sample session: === doc rm -f cpio.info cpio.info.gz rm -f .depend /usr/obj/usr/src/gnu/usr.bin/cpio/GPATH /usr/obj/usr/src/gnu/usr.bin/cpio/GRTAGS /usr/obj/usr/src/gnu/usr.bin/cpio/GSYMS /usr/obj/usr/src/gnu/usr.bin/cpio/GTAGS === doc make: don't know how to make dhclient_clean. Stop src/sbin/dhclient/Makefile doesn't know 'dhclient_clean' target. % cd /usr/src/sbin/dhclient % make -n dhclient_clean make: don't know how to make dhclient_clean. Stop It seems that crunchgen misunderstands src/sbin/dhclient/Makefile, and fails to generate a Makefile for crunch binary. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Makoto I can't even get that far. On current as of today: make release BUILDNAME=5.0-20020224-CURRENT \ CHROOTDIR=/usr/tmp/release/5.0-20020224-CURRENT \ CVSROOT=/usr/home/ncvs NOPORTS=YES | tee /usr/src/release/release.log After the cvs checkout completes: cvs checkout: Updating doc/zh_TW.Big5/share cvs checkout: Updating doc/zh_TW.Big5/share/sgml U doc/zh_TW.Big5/share/sgml/catalog U doc/zh_TW.Big5/share/sgml/freebsd.dsl if [ -d /usr/src/release/../../ports/distfiles/ ]; then cp -rp /usr/src/release/../../ports/distfiles /usr/tmp/release/5.0-20020224-CURRENT/usr/ports/distfiles; else mkdir -p /usr/tmp/release/5.0-20020224-CURRENT/usr/ports/distfiles fi Syntax error: end of file unexpected (expecting fi) *** Error code 2 Stop in /usr/src/release. Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: linprocfs or mount appears broken
On Sun, Feb 24, 2002 at 09:02:25PM -0800, Doug Barton wrote: Steve Kargl wrote: cvsup sources from 24 FEB 02 at 14:42 PST. No local patches (although I would like to play with Matt's recent work). I cvsup'ed to this point: obrien 2002/02/24 13:26:07 PST Modified files: contrib/gcc.295/config/i386 freebsd.h Log: Use the default 'ld' emulation rather than hard coding it. For FreeBSD, 'ld' 2.12.0 uses a different emulation than in the past. So this change makes the upgrade easier. Revision ChangesPath 1.41 +1 -2 src/contrib/gcc.295/config/i386/freebsd.h Built/installed world and kernel, and I'm having no problems with linux netscape. Maybe that'll help you narrow things down... If I comment out linprocfs in /etc/fstab, I can boot the system. Linux netscape appears to work, but I don't know if linux netscape needs linprocfs to run. KLD linprocfs.ko: depends on linux - not available linprocfs: vfsload(linprocfs): Exec format error This error message does suggest a problem with ld. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
:Removing cli and sti from the critical functions saves us 300 ns on I'm going to make a correction here... I didn't realize I had WITNESS turned on. 300ns of savings makes a lot of sense when WITNESS is turned on because witness manipulates a number of spin locks. I am going to rerun the test on a 2xCPU box without WITNESS. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LSCOLORS warning is silly
A couple months ago an improvement was added to the color support of ls
to use a wider variety of colors, indicated by alphabet characters
instead of numbers. While I think this is a good change, it included a
warning when users have the old style numeric flags in their LSCOLORS
variable. I think this is a mistake, and needlessly places another
barrier for users coming into -current. Since the support for the old
style color flags is practically free, I'd like to suggest that rather
than warning the user, we simply continue to support the old flags, and
indicate that they are deprecated in the man page.
I'd like to commit the attached patch. Let me know what you think.
--
We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory.
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
? ls.1.gz
Index: ls.1
===
RCS file: /home/ncvs/src/bin/ls/ls.1,v
retrieving revision 1.62
diff -u -r1.62 ls.1
--- ls.19 Jan 2002 13:29:39 - 1.62
+++ ls.125 Feb 2002 05:24:12 -
@@ -496,6 +496,8 @@
is the foreground color and
.Ar b
is the background color.
+The old style of numbers as color designators are still supported,
+although deprecated.
.Pp
The color designators are as follows:
.Pp
Index: print.c
===
RCS file: /home/ncvs/src/bin/ls/print.c,v
retrieving revision 1.53
diff -u -r1.53 print.c
--- print.c 25 Feb 2002 01:36:59 - 1.53
+++ print.c 25 Feb 2002 05:24:13 -
@@ -481,7 +481,6 @@
int j;
int len;
char c[2];
- short legacy_warn = 0;
if (cs == NULL)
cs = ;/* LSCOLORS not set */
@@ -500,13 +499,6 @@
/* Legacy colours used 0-7 */
if (c[j] = '0' c[j] = '7') {
colors[i].num[j] = c[j] - '0';
- if (!legacy_warn) {
- fprintf(stderr,
- warn: LSCOLORS should use
- characters a-h instead of 0-9 (
- see the manual page)\n);
- }
- legacy_warn = 1;
} else if (c[j] = 'a' c[j] = 'h')
colors[i].num[j] = c[j] - 'a';
else if (c[j] = 'A' c[j] = 'H') {
Re: New pam doesn't work with xdm 4.2
On Sun, Feb 24, 2002 at 10:15:44PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Sun, Feb 24, 2002 at 08:46:45PM -0700, M. Warner Losh wrote: : You need a different version for -current than for -stable. Make sure : you have the right version. : : I got the same problem with Xwrapper -- and it was compiled on this : 5-CURRENT w/in the past 6 months. xdm is the problem, not Xwrapper. I don't follow you. In my case it was Xwrapper -- I use ''startx''. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD/i386 make release breakage
null After the cvs checkout completes: Ah, big sorry... I just fixed in src/release/Makefile rev 1.658. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New pam doesn't work with xdm 4.2
In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Sun, Feb 24, 2002 at 10:15:44PM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : David O'Brien [EMAIL PROTECTED] writes: : : On Sun, Feb 24, 2002 at 08:46:45PM -0700, M. Warner Losh wrote: : : You need a different version for -current than for -stable. Make sure : : you have the right version. : : : : I got the same problem with Xwrapper -- and it was compiled on this : : 5-CURRENT w/in the past 6 months. : : xdm is the problem, not Xwrapper. : : I don't follow you. In my case it was Xwrapper -- I use ''startx''. Ah, xdm was my problem Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LSCOLORS warning is silly
Doug Barton [EMAIL PROTECTED] writes: A couple months ago an improvement was added to the color support of ls to use a wider variety of colors, indicated by alphabet characters instead of numbers. While I think this is a good change, it included a warning when users have the old style numeric flags in their LSCOLORS variable. I think this is a mistake, and needlessly places another barrier for users coming into -current. Since the support for the old style color flags is practically free, I'd like to suggest that rather than warning the user, we simply continue to support the old flags, and indicate that they are deprecated in the man page. Deprecated features should generate warnings. See the Committers Guide (8.3) for details. The change to the manual is correct though. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
Apparently, On Sun, Feb 24, 2002 at 09:03:53PM -0800,
Matthew Dillon said words to the effect of;
:...
:interrupts; hard interrupts are rarely masked. The queueing is written
:in assmebler and runs outside of the kernel so it is fast. Traps in
:general are fast because they don't touch memory until the trapframe
:is written out, so I don't see much point in changing this do the masking
:in software and avoid the soft interrupt.
I have no idea what you are talking about Jake. Could you supply
some context?
Sorry, maybe I got ahead of myself. I was responding to your suggestion
that other architectures should pick up this design. This does not make
sense for sparc64.
:In regards to the patch I think that making critical_enter/exit MD in
:certain cases is a mistake. cpu_critical_enter/exit are already MD
:and it looks you could hide this behind them with some minor changes.
:
:Like in the critical_enter case, make cpu_critical_enter take a thread
:as its argument. It could be a null macro in the i386 case, which would
:optimize out the test.
:
:if (td-td_critnest == 0)
: cpu_critical_enter(td);
:td-td_critnest++;
:
:Likewise with cpu_critical_exit, make it take the thread as its argument.
:
:If (td-td_critnest == 1) {
: td-td_critnest = 0;
: cpu_critical_exit(td);
:} else
: td-td_critnest--;
:(This is equivalent to if (--td-td_critnest == 0), its a matter of taste.)
I'm afraid I have to strongly disagree. I believe that
critical_enter()/exit is *ALREADY* being severely misused in current.
For example, fork_exit() makes assumptions about the underlying hardware
in order to initialize td_critnest and the scheduler mutex safely. This
is just plain broken. fork_exit() should not make any such assumptions.
It is the clear responsibility of either the trampoline code or
cpu_fork() to properly set up td_critnest. One can make an argument
that the sched_lock fixup is in fork_exit()'s domain but you cannot
make the argument that the initialization of critnest (and any associated
hardware state) is MI. It just isn't.
Additionally, critical_enter()/exit themselves are certainly much
more MD then MI. It makes little sense to abstract out an MI interface
that forces unnecessary overhead when all you have to do is define an
MD API that has a few MI requirements, like td_critnest being a critical
nesting count that the MI code can count on. But as MI code the existing
critical_enter()/exit impose additional MD fields and do not give the
MD code the option of not using them (except in a degenerate fashion).
Specifically, the use of the td_savecrit field is under the partial
contorl of the MI code when it shouldn't be, not just in fork_exit()
but also in critical_enter() and critical_exit() themselves.
The existing critical_enter/exit code is far too abstracted for its
low-level purpose and I *WILL* be moving them into MD sections of the
system where they belong. These are really MD routines, not MI routines.
Fine. As long as their functionality with respect to MI code does not
change I don't care.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
critical_enter()/critical_exit() overheads in an SMP system
Ok, I've done a more comprehensive test. TU = getuid() syscall test. This is on a 2xCPU SMP box. With one process running the syscall is 34 nS faster with the new critical_*(). With two processes running the syscall is 41 nS faster with the new critical_*(). So, not 300nS, but not too shabby. I expect we'll add another 15-20nS of performance later on when the routines are inlined and the sysctl instrumentation is removed. As I said, cli and sti (and the pushfl/popl combination) are nasty instructions. This test is with a 1.1GHz P3 but I believe it is even worse on a P4. -Matt pid 204 guid/sec 813324 One TU running, old critical_*() pid 204 guid/sec 813336 1.230 uS/call pid 204 guid/sec 813513 pid 204 guid/sec 813394 pid 204 guid/sec 813099 pid 204 guid/sec 836959 new critical_*() pid 204 guid/sec 836779 1.195 us/call -- 34 nS pid 204 guid/sec 836939 pid 214 guid/sec 687816 Two TU's running, old critical_*() pid 214 guid/sec 687632 1.454 uS/call pid 214 guid/sec 687857 pid 214 guid/sec 687887 pid 214 guid/sec 667454 new critical_*() pid 214 guid/sec 667562 1.496 uS/call -- 41 nS pid 214 guid/sec 668551 pid 214 guid/sec 668686 pid 214 guid/sec 668789 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
: :is written out, so I don't see much point in changing this do the masking : :in software and avoid the soft interrupt. : : I have no idea what you are talking about Jake. Could you supply : some context? : :Sorry, maybe I got ahead of myself. I was responding to your suggestion :that other architectures should pick up this design. This does not make :sense for sparc64. All I am advocating is that either cpu_fork() or the trampoline code be responsible for setting up the '1 level of critical_enter()' state that fork_exit() is currently hacking together with twine and bailing wire. That seems pretty straightforward to me. There is a window of opportunity between the trampoline code and the point where fork_exit() installs td_critnest where an interrupt can occur and mess things up. In order to get around this window, fork_exit() is making assumptions about the underlying hardware that it should not be making. For IA32 I will probably fix it in cpu_fork() itself in a later commit and not have to touch the trampoline code at all, but for this current commit I am fixing it in the trampoline code for i386 and have a compatibility shim in fork_exit() for the other architectures. I will also be moving critical_enter()/exit() from MI to MD at some point (not this commit, some later commit), but for the other architectures it will be the same code. I am only optmizing i386. :Fine. As long as their functionality with respect to MI code does not :change I don't care. : The functionality does not change unless you are making an assumption in regards to interrupt disablement vs interrupt deferral in the MI code. Only fork_exit() makes that assumption at the moment but the commit will only correct the assumption for I386. It will not change anything for the other architectures (i.e. the assumption can still be made for the other architectures). -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problems with picobsd...
Hi Folks, I'm now mirroring the CVS repository locally (with cvsup) and then checking out the head of the tree with cvs co src to get at -CURRENT. I'm trying to work with picobsd but I get the following on the latest (24 Feb 2002, 22:25 Pacific Time) stuff when I just try to --init the system: cd /home/gnn/FreeBSD/src/lib/csu/i386-elf; make depend; make all; make install cc -nostdinc -elf -Wall -fkeep-inline-functions -I/home/gnn/FreeBSD/src/lib/c su/i386-elf/../common -c /home/gnn/FreeBSD/src/lib/csu/i386-elf/crt1.c -o crt1.o /home/gnn/FreeBSD/src/lib/csu/i386-elf/crt1.c:32: stddef.h: No such file or directory /home/gnn/FreeBSD/src/lib/csu/i386-elf/crt1.c:33: stdlib.h: No such file or directory In file included from /home/gnn/FreeBSD/src/lib/csu/i386-elf/crt1.c:34: /home/gnn/FreeBSD/src/lib/csu/i386-elf/../common/crtbrand.c:28: sys/param.h: No such file or directory *** Error code 1 Stop in /home/gnn/FreeBSD/src/lib/csu/i386-elf. *** Error code 1 Stop in /home/gnn/FreeBSD/src. *** Error code 1 Stop in /home/gnn/FreeBSD/src. --- fail: Error 1 error code libraries in Error: failed while making libraries --- Aborting ./release/picobsd/build/picobsd This comes from the command: ./release/picobsd/build/picobsd --src /home/gnn/FreeBSD/src --init Clues? Thanks, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: critical_enter()/critical_exit() overheads in an SMP system
:pid 214 guid/sec 687816Two TU's running, old critical_*() :pid 214 guid/sec 6876321.454 uS/call :pid 214 guid/sec 687857 :pid 214 guid/sec 687887 :pid 214 guid/sec 667454new critical_*() :pid 214 guid/sec 6675621.496 uS/call -- 41 nS :pid 214 guid/sec 668551 :pid 214 guid/sec 668686 :pid 214 guid/sec 668789 Boy, I'm batting 0 tonight! Those numbers are reversed :-). new_critical is the top number (the faster 1.454 uS/call) and old_critical is the bottom number (1.496 uS/call). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assemblyrevamp, please review!
On Sun, 24 Feb 2002, Matthew Dillon wrote:
:On Sun, 24 Feb 2002, Matthew Dillon wrote:
: * Additional cpu_critical_enter/exit() calls around icu_lock. Since
: critical_enter() no longer disables interrupts, special care must
: be taken when dealing with the icu_lock spin mutex because it is
: the one thing the interrupt code needs to be able to defer the
: interrupt.
:
:clock_lock needs these too, at least in my version where the soft
:critical_enter() doesn't mask fast interrupts.
I wasn't sure whether it was due to that, or whether you just wanted
the two I8254 accesses to be right next to each other. Since I am
msking fast interrupts I think we are safe.
Hmm, I thought I wrote more about this somewhere. We are fairly safe,
but we may be interrupted for a few microseconds, and i8254_get_timecount()
has depends on the latency being at most 20 usec (the hard-coded 20
was correctly parametrized as TIMER0_LATCH_COUNT in the old assembler
version. This has rotted to TIMER0_LATCH_COUNT being #defined,
documented but not used). Actually, we have more serious latency
problems here. i8254_get_timecount() also depends on clk0 interrupts
not being disabled for 20 usec _before_ it is called (interrupt handlers
can call it, but they must not have interrupts enabled at the time of
the call). -current probably violates this by running with spinlocks
held for more than 20 usec and calling i8254_get_timecount() from at
least the witness code on old machines which have the least to spare.
Your changes help, but clk0 interrupts will probably be delayed by 20
usec in some cases.
:IIRC, in my version, the hard interrupt enablement in fork_exit() is
:only needed at boot time. Something neglects to do it earlier in that
:case, at least for some threads. I was surprised by this -- hard
:interrupts are enabled early in the boot, and everything later should
:disable and enable them reentrantly.
I couldn't figure out who was leaving hard interrupts enabled. Did
you ever figure out who it was? At the moment I am able to enable
No; I don't remember even trying.
interrupts in the trampoline code just before the call to
fork_exit(), but it has to be disabled on entry to the trampoline
code because the task's td_critnest count is still 0 at that
point and we can't afford to execute a real (fast) interrupt's
service routine until we clean up the sched_lock.
I think td_critnest should be set a little earlier. Not sure why it
isn't already.
In regards to i8254_get_timecounter() the 8254 latches the full
count on the first access so we are theoretically safe. I'll
change my timecounter to use the 8254 to see if it still works
as expected.
I use pcaudio for stress testing the i8254 timecounter. It sets the
clock frequency to 16 KHz. Setting HZ to this should work almost as
well in -current. HZ can be set even faster.
: /*
: + * Critical section handling.
:...
:i386/machdep.c is a different wrong place for this and unpend(). I put it
:in isa/ithread.c. It is not very MD, and is even less isa-dependent.
Yah. I'm all ears as to where to put it :-) There's no good place
to put inline versions of critical_enter() or critical_exit() either.
machine/cpufunc.h doesn't have access to the struct thread.
I would keep it in isa/sched_ithd.c until the correct MI parts are found.
p.s. all discussion here and below, except for the bintr/eintr cleanup, would
be for a second work/commit round after I commit the current stuff.
I hope that leaves only 10-20K of changes :-).
: Index: i386/isa/apic_vector.s
: ===
: RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v
: retrieving revision 1.75
: diff -u -r1.75 apic_vector.s
: --- i386/isa/apic_vector.s 5 Jan 2002 08:47:10 - 1.75
: +++ i386/isa/apic_vector.s 24 Feb 2002 17:58:34 -
:
:Please do this without so many changes to the assembly code. Especially
:not the reordering and style changes. I think I see how to do this
:(see call_fast_unpend())
No such luck. In order to be able to mask fast interrupts I
had to move all the macros from between fast and slow ints to
above fast ints.
Erm, macros don't need to be defined before macros that invoke them.
I also decided to tab-out the backslashes in the icu_vector
code, because I couldn't read the code easily with the
backslashes slammed up against the instructions :-(
This uglyness has been maintained since 1992 to keep diffs somewhat
readable. I really don't want to change it now. Even the existence
of the macros is mostly a relic from 1992.
: +void
: +call_fast_unpend(int irq)
: +{
: + fastunpend[irq]();
: +}
: +
:
:I think this can be done using with few changes to the assembler by
:using INTREN(irq) followed by a call to the usual Xfastintr[irq]
Re: LSCOLORS warning is silly
Mike Barcroft wrote: Doug Barton [EMAIL PROTECTED] writes: A couple months ago an improvement was added to the color support of ls to use a wider variety of colors, indicated by alphabet characters instead of numbers. While I think this is a good change, it included a warning when users have the old style numeric flags in their LSCOLORS variable. I think this is a mistake, and needlessly places another barrier for users coming into -current. Since the support for the old style color flags is practically free, I'd like to suggest that rather than warning the user, we simply continue to support the old flags, and indicate that they are deprecated in the man page. Deprecated features should generate warnings. Ok, then let's call it Undocumented legacy support. I agree that features we don't want to support anymore should generate warnings that encourage users to change. However, there is so little cost to support the old flags that there is no reason to ever discontinue that support. it's two lines of code. You can see them in the diff. The code is even properly documented to indicate it's purpose. It can't get any better than that. Let me restate the more important point... there are already 843 things that need to be changed/updated/dealt with in moving from 4.x to 5.0. Most of them are even necessary. If we want to encourage users to adopt 5.0 (at whatever phase of the game) we should not place silly barriers in front of them. It took me over an hour today to track down broken stuff that developed between my last -current update of 12/2/01 till today. And I track development better than most of the people who will use the first 5.0 snapshot. This is one more annoyance I don't need, and I think most of our userbase will feel the same way. If this were an expensive thing to support, I would have stuck with the man page update only. But it's not. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT in pretty good shape, after all
At 1:00 AM -0800 2/24/02, Julian Elischer wrote: On Sat, 23 Feb 2002, Garance A Drosihn wrote: It is working fairly well for me too, on a dual-pentium machine. I can't get vmware2 working, but most of everything else that I do is working, and I'm not running into any mysterious crashes. h I'm using vmware2 to run turbotax to do my taxes and it seems fine Well, between this and comments from two other people that I finally put together (ie, I finally realized the significance of what they were saying), it's working for me too. Thanks! [maybe later this week I'll sit down and figure out how to fix the port so *it* does the right things...] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Success! critical_enter()/critical_exit() revamp (was Re:malloc_bucket() idea (was Re: How to fix malloc.))
On Sun, 24 Feb 2002, Matthew Dillon wrote: :cpu_switch() certainly needs to do this if it can be called with the :interrupt enable flag[s] in different states. I need the sti's (actually :enable_intr()'s because I don't want fast interrupts to be disabled :during context switches. This works because enabling interrupts is sure :to be safe, since we might be switching to a thread that will enable :them. Some sort of lock is needed to prevent interrupts interfering :with the switch. I think soft-masking them in critical_enter() is :sufficient in your version too. I don't think we want to make sched_lock any more complex then it already is, so at least for the foreseeable future we are not going to be able to actually execute an interrupt handler until the sched_lock is released in (typically) msleep(). I am rather Well, my kernel has been executing fast interrupt handlers while sched_lock is held for almost a year. It's actually less complicated with respect to sched_lock but more complicated with respect to fast interrupt handlers. annoyed that two levels of procedure have to be called with the sched_lock held (mi_switch() and cpu_switch()), leaving interrupts disabled for a fairly long period of time, but I don't see any way around it right now. The worst offenders for interrupt latency seemed to be calcru() and/or the sched_locking related to fork and/or exit. Latency was many thousand instructions (reasonable only on 100+ MIPS machines). sched_locking for calcru() is moostly bogus and should be easy to avoid, but not so for context switching. Eventually (presumably) we will have per-cpu run queues. That combined with interrupt stealing may resolve the problem for us. I am still not convinced that making the various *pending* flags globals will be more efficient, because it introduces significant cache mastership issues. It might be easier to do this: OK. I don't care about this yet. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current hangs with SMP enabled
:... : stuff (it was not used on that machine) and it booted fine, I think that : might just cure the SMP problem you are seeing too. : :Thanks for the suggestion. : :Unfortunately it still hangs with SMP enabled and the ATA drivers commented :out of the GENERIC config. : :Ken :-- :Kenneth Merry Just as a data point, I've been running -current on a 2xCPU SMP system (DELL2550) for a few weeks and it's always booted fine. For the last few months I have noticed occassional freezes occuring at odd times long after boot. I have no idea why it happens. -Matt # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.260 2000/06/13 22:28:46 peter Exp $ machine i386 #cpuI386_CPU #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident DELL2550 maxusers0 hints TEST.hints#Default places to look for devices. options SCSI_DELAY=5000 #options MAXMEM=(64*1024) options DDB options INVARIANTS options INVARIANT_SUPPORT options SOFTUPDATES #optionsWITNESS #optionsSHMALL=65537 #optionsSHMMAXPGS=65537 #options GDB_REMOTE_CHAT options ALT_BREAK_TO_DEBUGGER # -Os broken # makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols makeoptions COPTFLAGS=-O -pipe #optionsMATH_EMULATE#Support for x87 emulation options INET#InterNETworking #optionsINET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem options NFSSERVER #Network Filesystem options NFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PSEUDOFS#Pseudofs options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] #optionsSCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores #optionsP1003_1B#Posix P1003_1B real-time extensions #options_KPOSIX_PRIORITY_SCHEDULING #optionsKBD_INSTALL_CDEV# install a CDEV entry in /dev # To make an SMP kernel, the next two are needed # options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #optionsNCPU=2 # number of CPUs #optionsNBUS=8 # number of busses #optionsNAPIC=1 # number of IO APICs #optionsNINTR=24# number of INTs device isa #device eisa device pci #optionsCOMPAT_OLDISA # compatability shims for lnc, fe, le #optionsCOMPAT_OLDPCI # compatability shims for lnc, vx # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices # SCSI Controllers #device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices #device amd # AMD 53C974 (Teckram DC-390(T)) #device dpt # DPT Smartcache - See LINT for options! #device isp
Re: LSCOLORS warning is silly
Doug Barton [EMAIL PROTECTED] writes: Mike Barcroft wrote: Deprecated features should generate warnings. Ok, then let's call it Undocumented legacy support. I agree that features we don't want to support anymore should generate warnings that encourage users to change. However, there is so little cost to support the old flags that there is no reason to ever discontinue that support. it's two lines of code. You can see them in the diff. The code is even properly documented to indicate it's purpose. It can't get any better than that. I don't have any objections to making this a supported legacy mode, but I think deprecated features (things we *want* to go away) should produce warnings. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
