Re: -current hangs with SMP enabled
+---[ Glenn Gombert ]-- | 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. I can normally boot fine, it's only under load that it hangs. I think it might actually be the AHC driver, not CAM itself. I don't have any other SCSI cards to test that theory though. -- 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 assemblyrevamp, please review!
On Sun, 24 Feb 2002, Matthew Dillon wrote: ... :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). master bit mask seems to be an unusual name for the i386's ICU/or APIC (PIC or APIC in full i386-speak). 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. Some more points related to this: - a mask outside of the CPU is required for SMP. - I believe interrupt masks and not levels are a fundamental requirement for proper scheduling as -current does it. A set of levels like the alpha's IPL doesn't work right because it doesn't permit masking individual interrupts (that have occurred) so that the kernel can keep running a thread whose priority is higher than that of the thread that will handle the interrupt, all according to the kernel's idea of priorities (which might differ significantly from the IPL's idea. There are also implementation problems. The IPL must be treated like an ICU and not restored reentrantly like IPLs usually are. - The worst case for priorities is when there is only a 2-state IPL, which is what an i386 without an ICU/APIC has. Then there can be only 2 really different kernel interrupt priorities (high and low), and the kernel ithread scheduling is just a waste of time. A 2- state IPL would obviously be bad for SMP, but for UP I often feel that it is the case that should be optimized -- this would force all critical regions and interrupt handlers to be short, which would be good for all cases. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LSCOLORS warning is silly
On Mon, Feb 25, 2002 at 02:38:45AM -0500, Mike Barcroft wrote: 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. I'd prefer not to support N different ways of specifying colours, and want to hold onto making the deprecated version include warnings. Sorry, Joe msg35241/pgp0.pgp Description: PGP signature
Deprecated bfd_read warnings in the gdb(1)
David,
I've noticed that after a recent make world gdb started producing
warnings during startup. Please fix.
-Maxim
max@notebook$ uname -a
FreeBSD notebook 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Tue Feb 19
19:46:58 EET 200
2 root@notebook:/usr/src/sys/i386/compile/NOTEBOOK i386
max@notebook$ gdb mkdir
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-unknown-freebsd...Deprecated
bfd_read called a
t
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/dbxread.c
li
ne 2629 in elfstab_build_psymtabs
Deprecated bfd_read called at
/usr/src/gnu/usr.bin/binutils/gdb/../../../../cont
rib/gdb.291/gdb/dbxread.c line 935 in fill_symbuf
Breakpoint 1 at 0x804848d: file mkdir.c, line 137.
Breakpoint 1, build (path=0xbfbff958 //usr/local, omode=49087) at
mkdir.c:137
137 {
(gdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
ACPI timecounter help needed!
Machines with ACPI timecounters will now print 10 lines at boot when the timer is tested. If you are lucky you will see ten times something like: ACPI timer looks GOOD min = 3, max = 3, width = 1 That means that you have well implemented ACPI timer. If you are unlucky, one, several or all 10 lines will be marked as BAD. Please send me an email with these 10 lines and the output of pciconf -l -v for your machine. I'm am interested in reports both from good and bad machines. If your machine starts to mysteriously hang after this commit, try to increase the 15 to 31 in this line: } while (u1 u2 || u2 u3 || (u3 - u1) 15); Hopefully this commit fixes the timecounter backwards problem with broken ACPI timers, if not, let me know. Enjoy, Poul-Henning In message [EMAIL PROTECTED], Poul-Henning Kamp writes: phk 2002/02/25 01:51:18 PST Modified files: sys/dev/acpica acpi_timer.c Log: Add a new test_counter() function which tries to determine the width of the inter-value histogram for 2000 samples. If the width is 3 or less for 10 consequtive samples, we trust the counter to be good, otherwise we use the *_safe() method. This method may be too strict, but the worst which can happen is that we take the performance hit of the *_safe() method when we should not. Make the *_safe() method more discriminating by mandating that the three samples do not span more than 15 ticks on the counter. Disable the PCI-ident based probing as a means to recognize good counters. Inspiration from: dillon and msmith Revision ChangesPath 1.14 +46 -17src/sys/dev/acpica/acpi_timer.c -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LSCOLORS warning is silly
On Mon, 25 Feb 2002, Josef Karthauser wrote: On Mon, Feb 25, 2002 at 02:38:45AM -0500, Mike Barcroft wrote: 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. I'd prefer not to support N different ways of specifying colours, and want to hold onto making the deprecated version include warnings. I could understand your argument if there were A) many different ways, or B) support for the one legacy method was complicated. But neither of these are true. Including a warning for something that is easy to support and costs us nothing is pointlessly pedantic. Do you have a technical reason for your position? -- 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
On Sun, 24 Feb 2002, David O'Brien wrote: 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''. I use startx, and used to use Xwrapper. Now I don't use Xwrapper, and use a setuid root X :-(. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Locale in FreeBSD
On Sun, 24 Feb 2002 22:07:01 +0100, Uros Gruber wrote: I wan't to know when will be suported LC_NUMERIC and LC_MONETARY in FreeBSD, not hardcoded to C lang. What do you mean? There's already nl_langinfo(3) support. All locales in /usr/share/locale seem to have LC_MONETARY and LC_NUMERIC definition files. Ciao, Sheldon. 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, Andrew Gallatin wrote: 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.. I think we can tweak the saved PSL and it should be able to mask interrupts in the same way as for x86. This should be quite easy for ia64 too. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re[2]: Locale in FreeBSD
Hi, Where are this file. On 4.5 release not. Maybe on curent. If you can find this files let me know. 4.5-STABLE FreeBSD 4.5-STABLE #0: Thu Feb 21 13:50:51 CET 2002 -- bye, Urosmailto:[EMAIL PROTECTED] Monday, February 25, 2002, 12:43:30 PM, you wrote: SH On Sun, 24 Feb 2002 22:07:01 +0100, Uros Gruber wrote: I wan't to know when will be suported LC_NUMERIC and LC_MONETARY in FreeBSD, not hardcoded to C lang. SH What do you mean? There's already nl_langinfo(3) support. All locales SH in /usr/share/locale seem to have LC_MONETARY and LC_NUMERIC definition SH files. SH Ciao, SH Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Re[2]: Locale in FreeBSD
On Mon, 25 Feb 2002 13:14:08 +0100, Uros Gruber wrote: Where are this file. On 4.5 release not. Maybe on curent. If you can find this files let me know. Why are you asking about stable on the -current mailing list? Please post your queston to the freebsd-i18n mailing list. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI timecounter help needed!
On Mon, Feb 25, 2002 at 10:59:16AM +0100, Poul-Henning Kamp wrote: Machines with ACPI timecounters will now print 10 lines at boot when the timer is tested. You should mention that this requires bootverbose. If you are lucky you will see ten times something like: ACPI timer looks GOOD min = 3, max = 3, width = 1 That means that you have well implemented ACPI timer. If you are unlucky, one, several or all 10 lines will be marked as BAD. Please send me an email with these 10 lines and the output of pciconf -l -v for your machine. I'm am interested in reports both from good and bad machines. I will send you mine as soon as I can figure out how to extract the information usefully as the machine behaves VERY badly with the ACPI timecounter -- the only way I can see output on the syscons console is if I break into DDB repeatedly. -- wca 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
Matthew Dillon wrote: :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). I'll have to remember this trick of swapping numbers the next time I have a competitive benchmark that's slower than the competition. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: LSCOLORS warning is silly
Josef Karthauser wrote: On Mon, Feb 25, 2002 at 02:38:45AM -0500, Mike Barcroft wrote: 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. I'd prefer not to support N different ways of specifying colours, and want to hold onto making the deprecated version include warnings. Just make the damn thing not work with the deprecated setup, remove the warnings, and handle the complaints. You're going to be handling the complaint either way. Or get rid of the warning, and avoid the complaints, and remove the deprecated support code later, after most of the user base is using new configuration data because of a turnover or use of the documentation. -- 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
Szilveszter Adam heeft op zondag 24 februari 2002 om 19:04 het volgende geschreven: 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. [snip] AOLMe Too!/AOL I use my CURRENT machine to serve up samba, (SSL)IMAP, webserver, development platform, icecast jukebox, LPD/CUPS printserver, NFS fileserver and Appletalk. needless to say, it it pretty loaded. It's got almost a constant load avg around 2 or 3, and it's holding up fine, and it is responsive. Impressive work! offtopic Oh, anyone have CURRENT running on SPARC? I have aquired a few SPARC machines (two SpartStations, a 5 and a 10). How does one go running CURRENT on those? I would like to serve as a test-bed for it. /offtopic Cheers, Emiel Kollof To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CA updated
Magnus B{ckstr|m heeft op zondag 24 februari 2002 om 22:30 het volgende
geschreven:
+ mtx_lock(Giant);
+
Wasn't this _not_ the way to lock GIant, according to Matt Dillon? Look
for previous posts where he explains.
Cheers,
Emiel Kollof
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
ACPI issues and questions (Dell Inspiron 3700)
I have just installed -CURRENT on my Dell Inspiron 3700 laptop, and I immediately found two problems with ACPI: 1. The sio1 port (IrDA) is not detected. I had to add hint.sio.1.at=isa hint.sio.1.port=0x2F8 hint.sio.1.irq=3 to /boot/device.hints in order to get it probed at boot. I think that this is a fault of the ACPI BIOS. 2. S3/STR does not work: if I run acpiconf -s 3, the machine initiates a strange suspend process (stops HD, turns off LCD, then turns it on again, waits, and then seems to enter suspended state). However, when I try to resume the machine, it hangs with the power led on, HD on and LCD off; I have to press the power button for more than 5 seconds in order to turn off the laptop). There also are problems with the ACPI time counter, already reported to phk. I send attached a .tar.gz containing the output of acpidump(8), pciconf(8), and dmesg(8). Just FYI ;-) Also, I have a question: the acpiconf command can enable or disable ACPI power management but... is it enabled or disabled after boot? I cannot find any way to obtain this information. Cheers, JMA -- ** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ** ** Beware of Programmers who carry screwdrivers -- Leonard Brandwein ** acpimsgs.tar.gz Description: application/tar-gz
Re: ACPI issues and questions (Dell Inspiron 3700)
Jose M. Alcaide heeft op maandag 25 februari 2002 om 16:24 het volgende geschreven: [ACPI stuff snip] Please take this to [EMAIL PROTECTED] Yes, it's a japanese list, but english postings are welcome. They would be happy with your acpidump stuff too. They have quite a collection already :) Cheers, Emiel Kollof To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
In message [EMAIL PROTECTED], Jose M. Alcaide wrote:
1. The sio1 port (IrDA) is not detected. I had to add
hint.sio.1.at=isa
hint.sio.1.port=0x2F8
hint.sio.1.irq=3
to /boot/device.hints in order to get it probed at boot. I think that
this is a fault of the ACPI BIOS.
From acpidump.
Device(IRDA) {
Name(_HID, 0x10f0a34d)
So try adding
{0x10f0a34d, NULL}
to sio_ids in /sys/dev/sio/sio_isa.c
Takanori Watanabe
a href=http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html;
Public Key/a
Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
On Tue, Feb 26, 2002 at 12:32:47AM +0900, Takanori Watanabe wrote:
In message [EMAIL PROTECTED], Jose M. Alcaide wrote:
1. The sio1 port (IrDA) is not detected. I had to add
hint.sio.1.at=isa
hint.sio.1.port=0x2F8
hint.sio.1.irq=3
to /boot/device.hints in order to get it probed at boot. I think that
this is a fault of the ACPI BIOS.
From acpidump.
Device(IRDA) {
Name(_HID, 0x10f0a34d)
So try adding
{0x10f0a34d, NULL}
to sio_ids in /sys/dev/sio/sio_isa.c
It works:
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x280-0x287,0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
Thanks!
--
** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] **
** Beware of Programmers who carry screwdrivers -- Leonard Brandwein **
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI issues and questions (Dell Inspiron 3700)
On 25 Feb, Jose M. Alcaide wrote: Also, I have a question: the acpiconf command can enable or disable ACPI power management but... is it enabled or disabled after boot? I cannot find any way to obtain this information. It is enabled by default and the enable/disable part of the command is useless. At least this is what I can remember from the time I send in a patch for /etc/rc.i386 (acpi_enable like apkm_enable) which got rejected. Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Deprecated bfd_read warnings in the gdb(1)
On Mon, Feb 25, 2002 at 11:51:54AM +0200, Maxim Sobolev wrote: David, I've noticed that after a recent make world gdb started producing warnings during startup. Please fix. Please send patch. This will require gdb to be updated to GDB 5.1.1 -- something I am not going to do. This also shows the problems with trying to share libiberty across multiple software packages. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Deprecated bfd_read warnings in the gdb(1)
At 9:34 AM -0800 2/25/02, David O'Brien wrote: On Mon, Feb 25, 2002 at 11:51:54AM +0200, Maxim Sobolev wrote: I've noticed that after a recent make world gdb started producing warnings during startup. Please fix. Please send patch. This will require gdb to be updated to GDB 5.1.1 -- something I am not going to do. This also shows the problems with trying to share libiberty across multiple software packages. Upgrading to gdb 5.1.1 *is* something that I am doing. In fact, I was testing kernel debugging over the weekend. However, the calls to bfd_read are still in gdb 5.1.1 so I could either patch it or wait for gdb 5.2 to be released. Of course, a simple patch to bfd.h could remove the warning as well... If the warning is annoying people, I can make the patch to gdb. If it is tolerable, then let's wait for gdb 5.2. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lomac
Logan weaponx [EMAIL PROTECTED] wrote: Is there a reason lomac_enable isn't in /etc/defaults/rc.conf? I've only had a brief look so excuse this email if i'm in error and the answer is glaringly obvious. It's mostly that it still needs several features of the kernel which aren't currently there to be fully-functionalI don't think there would be any harm in adding it, though, and saying as much in /etc/defaults/rc.conf :) -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ 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!
Unless an unforseen problem arises, I am going to commit this tomorrow and then start working on a cleanup patch. I have decided to keep the sysctl instrumentation intact for the moment so people who experience panics or lockups can turn it off to see whether that was the cause or not. The cleanup patch will deal with moving the critical_*() functions from MI to MD, inlining, and the removal of the (old) CRITICAL_FORK and (new) MACHINE_CRITICAL_ENTER hacks. I'll probably wind up adding machine/critical.h (i.e. /usr/src/sys/arch/include/critical.h) and for i386 sys/i386/i386/critical.c to hold unpend() and other support routines. I've looked at cleaning up cpu_critical_enter() exit but its use pollutes a number of MI source files: kern/kern_ktr.c, kern/subr_trap.c, and kern/subr_witness.c are all misusing the functions. If these functions can safely be changed to use critical_enter() and critical_exit() I will rename the i386's cpu_critical*() functions into intr_disable() and intr_restore() and then use the new names for internal i386 use. Is there any reason why the above uses of cpu_critical*() cannot be changed to use standard critical*()? I believe we *always* have a curthread structure to play with so it should just work. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make builworld pam-ssh error
Hello: When I do make buildworld, I get the next error: ... ... libpam/modules/pam-ssh make: don't know how to make /usr/obj/usr/src/i386/usr/lib/libssh.a Stop Error code 2 1 error Erro code 2 1 error I'm using 4 stable and i'want to upgrade to current. What can I do to fix it. Thanks in advance _ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
power control..(APM/ACPI?)
In the not to distant past (3 months?) My -current laptop kernel (with apm in it I believe,(it's not here)) would repond to a halt -p by switching off the power. Since January, this has stopped working. (I now have to wait around until I see the message and hit the power button manually.) If I'm remote I have to call home and ask someone to turn it off. Is there something I should have noticed? I see nothing in UPDATING. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Latest versions of bsd.lib.mk break picobsd...
Hi Folks,
I've tried contacting [EMAIL PROTECTED] directly but haven't seen anything so I
figure I'll throw this out to the list. On 21 Feb 2002 a change was made to
the
bsd.lib.mk and bsd.prog.mk which is commented, in part, as:
Get rid of the (now unneeded) -I${DESTDIR}/usr/include magic in bsd.prog.mk
and bsd.lib.mk. Finish the removal of LDDESTDIR in bsd.lib.mk,v 1.55 -- we
no longer have users of it.
This change was made by ru. Alas this breaks the picobsd build since the
statically built libraries need some way to know to get their includes from the
directory you're building in. This does not affect a general 5.0 build (I checked
that this morning) but is still very problematic. I'm only just starting with the
picobsd stuff and I would love to fix this bug in the right place if only someone
could tell me what this change meant and how pervasive it was.
Putting in an extra CFLAG for -I${SRC}usr/include works for some libraries but
breaks libbind as alluded to by this comment in the same checkin:
(Attempt to move the -nostdinc -I... part of CFLAGS into the new CINCLUDES
(modeled after a similar CXXINCLUDES) eventually failed because hard-coding
${WORLDTMP}/usr/include to be the first in the include list does not always
work, e.g. lib/libbind.)
So, can someone help me out here?
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
struct {bio,buf} pointer for bioqdisksort()
In arstrategy() at dev/ata/ata-raid.c, memory is allocated with size
of struct ar_buf and passed as struct bio*.
buf1 = malloc(sizeof(struct ar_buf), M_AR, M_NOWAIT | M_ZERO);
...
buf1-bp.bio_dev-AD_STRATEGY((struct bio *)buf1);
This works fine because struct ar_buf contains struct bio as first
member.
struct ar_buf {
struct biobp;
...
This pointer is passed to bioqdisksort() as struct bio*.
In bioqdisksort() at kern/subr_disklabel.c, struct bio *bp is
converted into struct buf* with BIOTOBUF() macro.
void
bioqdisksort(bioq, bp)
struct bio_queue_head *bioq;
struct bio *bp;
{
...
if (td td-td_ksegrp-kg_nice 0) {
TAILQ_FOREACH(bn, bioq-queue, bio_queue)
if (BIOTOBUF(bp)-b_vp != BIOTOBUF(bn)-b_vp)
break;
On my environment, this causes panic because *bp does not have
enough allocated region.
(kgdb) p sizeof(struct bio)
$1 = 80
(kgdb) p sizeof(struct ar_buf)
$2 = 96
(kgdb) p sizeof(struct buf)
$3 = 364
I'm not familiar with this area, but I think
(1) arstrategy() should allocate enough size to cover struct buf for
struct ar_buf,
(2) bioqdisksort() should not suppose struct bio *bp can be
converted into struct buf*, or
(3) Call chain such as arstrategy() - adstrategy() - bioqdisksort()
is wrong.
Can someone explain what I should do next about this?
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
HEADS UP: cvs commit: src/sys/conf kern.pre.mk (fwd)
There are a couple of offending files in the kernel still, and some drivers. The things people are most likely to run into are: usb, inet6, and some drivers (twe, asr etc). Yes, you will almost certainly need 'make -DNO_WERROR' for the short term. But do take a look, there is some low hanging fruit there. --- Forwarded Message Date:Mon, 25 Feb 2002 14:04:33 -0800 From:Peter Wemm [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/conf kern.pre.mk peter 2002/02/25 14:04:33 PST Modified files: sys/conf kern.pre.mk Log: Turn on -Werror by default. This is is easily turned off, by either: - fix the warnings, they are there for a reason! - add -DNO_ERROR to your make(1) command. - add 'makeoptions NO_WERROR=true' to your kernel config. - add 'nowerror' to conf/files* that have warnings that should be fixed due to tracking 3rd party vendor code. - add 'nowerror' to conf/files* where the warning is false due to a compiler bug and fixing it with brute force would be too expensive. There are some very sloppy warnings in our kernel build, come on folks! 'make release' uses -DNO_WERROR intentionally. Revision ChangesPath 1.8 +5 -5 src/sys/conf/kern.pre.mk --- End of Forwarded Message 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 Mon, 25 Feb 2002, Matthew Dillon wrote:
Unless an unforseen problem arises, I am going to commit this tomorrow
and then start working on a cleanup patch. I have decided to
Please wait for jhb's opinion on it. He seems to be offline again.
I think he has plans and maybe even code for more code in critical_enter().
I think we don't agree with these plans, but they are just as valid
as ours, and our versions undo many of his old changes.
I've looked at cleaning up cpu_critical_enter() exit but its use
pollutes a number of MI source files: kern/kern_ktr.c, kern/subr_trap.c,
and kern/subr_witness.c are all misusing the functions. If these
functions can safely be changed to use critical_enter() and critical_exit()
I will rename the i386's cpu_critical*() functions into intr_disable()
and intr_restore() and then use the new names for internal i386 use.
It is already one layer higher than the MD versions for i386's at least.
The MD versions are disable_intr() (should be cli() to inhibit use in MI
code), enable_intr() (should be sti() ...), read_eflags() and write_eflags().
cpu_critical*() is supposed to be the version with an MI interface and
semantics, but one level lower than critical*(). In my version,
critical*() essentially doesn't exist and cpu_critical*() is only used
by fast interrupt handlers and hacks. The MI code in kern mainly depends
on the MD function (with an MI interface and semantics) unpend().
Is there any reason why the above uses of cpu_critical*() cannot be
changed to use standard critical*()? I believe we *always* have a
curthread structure to play with so it should just work.
I think this would mostly work on i386's. It would more obviously work
if td_critness were a per-cpu global and not in the thread struce. It
essentially is a per-cpu global, but we optimize it by putting it in
the thread struct. But ktr, especially, is very low level and should
work in the middle of a thread switch.
According to jake, it would only work on sparc64's if critical*() does
something hardware-related. Lazy masking of interrupts is partly in
hardware, so the hardware must be talked to to turn it on an off. On
i386's, the masking is in software, so it can use td_critnest as a
flag.
The use of cpu_critical*() in subr_trap.c is a bit trickier/kludgier.
We need to return from the interrupt handler atomically with clearing
the lazy-masking flag. The hardware interrupt enable flag must be
used for this on i386's. The code for this is logically:
In ast:
/* Prevent changes to flags while we are deciding if they are set. */
critical_enter();
while ((ke-ke_flags (KEF_ASTPENDING | KEF_NEEDRESCHED)) != 0) {
critical_exit();
...
/* As above. */
critical_enter();
}
In doreti:
/*
* Must use MD code to prevent race window after critical_exit().
* We switch from lazy sofware masking using td_critnest (or
* whatever critical_enter() uses) to hardware masking using cli.
*/
cli();
critical_exit();
...
iretd();
but this is optimized in -current by using cpu_critical*() instead of
critical_enter*() in ast() and not doing the cli() and critical_exit()
in doreti. This depends on cpu_critical_enter() being precisely cli().
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: power control..(APM/ACPI?)
Ditto here. My Dell notebook has ceased powering off. I've been meaning to submit a PR along with the dmesg output (plus some of the whining, I think from ACPI), but just haven't got to it. I'll try to do so tomorrow. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Mon, 25 Feb 2002, Julian Elischer wrote: In the not to distant past (3 months?) My -current laptop kernel (with apm in it I believe,(it's not here)) would repond to a halt -p by switching off the power. Since January, this has stopped working. (I now have to wait around until I see the message and hit the power button manually.) If I'm remote I have to call home and ask someone to turn it off. Is there something I should have noticed? I see nothing in UPDATING. 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: Patch for critical_enter()/critical_exit() interrupt assemblyrevamp, please review!
: :On Mon, 25 Feb 2002, Matthew Dillon wrote: : : Unless an unforseen problem arises, I am going to commit this tomorrow : and then start working on a cleanup patch. I have decided to : :Please wait for jhb's opinion on it. He seems to be offline again. :I think he has plans and maybe even code for more code in critical_enter(). :I think we don't agree with these plans, but they are just as valid :as ours, and our versions undo many of his old changes. I am not going to predicate my every move on permission from JHB nor do I intend to repeat the last debacle which held-up (and is still holding up) potential commits for a week and a half now. JHB hasn't even committed *HIS* patches and I am beginning to wonder what the point is when *NOTHING* goes in. If he had code he damn well should have said something on the lists two days ago. As it is, I have invested a great deal of time and effort on this patch and it is damn well going to go in so I can move on. -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!
It kinda sounds like the interrupt/trap code that calls into
kern/subr_trap.c should be responsible for placing us in a
critical section. kern/subr_trap.c has no business making
assumptions in regards to cpu_critical_enter()/cpu_critical_exit()
(for the same reason that fork_exit() has no business making
those kinds of assumptions).
For the moment I'm not going to worry about it. I'll just keep the
cpu_critical_*() API intact for i386 for now.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:The use of cpu_critical*() in subr_trap.c is a bit trickier/kludgier.
:We need to return from the interrupt handler atomically with clearing
:the lazy-masking flag. The hardware interrupt enable flag must be
:used for this on i386's. The code for this is logically:
:
:In ast:
: /* Prevent changes to flags while we are deciding if they are set. */
: critical_enter();
:
: while ((ke-ke_flags (KEF_ASTPENDING | KEF_NEEDRESCHED)) != 0) {
: critical_exit();
: ...
: /* As above. */
: critical_enter();
: }
:
:In doreti:
: /*
:* Must use MD code to prevent race window after critical_exit().
:* We switch from lazy sofware masking using td_critnest (or
:* whatever critical_enter() uses) to hardware masking using cli.
:*/
: cli();
: critical_exit();
: ...
: iretd();
:
:but this is optimized in -current by using cpu_critical*() instead of
:critical_enter*() in ast() and not doing the cli() and critical_exit()
:in doreti. This depends on cpu_critical_enter() being precisely cli().
:
:Bruce
:
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!
Matthew Dillon wrote: : :On Mon, 25 Feb 2002, Matthew Dillon wrote: : : Unless an unforseen problem arises, I am going to commit this tomorrow : and then start working on a cleanup patch. I have decided to : :Please wait for jhb's opinion on it. He seems to be offline again. :I think he has plans and maybe even code for more code in critical_enter(). :I think we don't agree with these plans, but they are just as valid :as ours, and our versions undo many of his old changes. I am not going to predicate my every move on permission from JHB nor do I intend to repeat the last debacle which held-up (and is still holdin g up) potential commits for a week and a half now. JHB hasn't even committed *HIS* patches and I am beginning to wonder what the point is when *NOTHING* goes in. If he had code he damn well should have said something on the lists two days ago. As it is, I have invested a great deal of time and effort on this patch and it is damn well going to go in so I can move on. So, your great deal of time and effort over the last week is more important than our time and effort over the last few months? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assembly revamp, please review!
:So, your great deal of time and effort over the last week is more important :than our time and effort over the last few months? : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] And how the hell did you come to that conclusion? Nothing I have done has interfered in the least with what you are doing. Not one thing. Even my kern_prot want-to-commit, supposedly duplicating some of JHB's work (but it turns out not since JHB didn't bother instrumenting Giant) would not have cost John more then 5 seconds of merge work. In short, if you are going to make such a state you had damn well start backing it up with hard fact, because I have *HAD* *IT* with all the shit flying around lately that has taken what should be 10 or 20 man hours of work and turned it into 80 or 90. I am not playing this game any more. If you have ephermal, unspecified problems with my work you can address them *AFTER* I commit. If you have hard facts showing probable interference then you can address them *BEFORE* I commit. So far I have not heard a single hard fact in all the shit flying back and forth. -Matt Matthew Dillon [EMAIL PROTECTED] 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
You could use http://people.freebsd.org/~fenner/__FreeBSD_version.html to find an already-existing value of __FreeBSD_version to test based on the date of the original change. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: cvs commit: src/sys/conf kern.pre.mk (fwd)
In message: [EMAIL PROTECTED] Peter Wemm [EMAIL PROTECTED] writes: : There are a couple of offending files in the kernel still, and some : drivers. The things people are most likely to run into are: usb, inet6, : and some drivers (twe, asr etc). I've fixed a few of the low hanging fruit, but I don't know how to get rid of warnings like: const char *foo = blah; char *baz = foo; when I know they are safe. 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 23:15:34 -0800, Matthew Dillon wrote: :... : 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. Your config works! I've attached the dmesg. Now the question is, what is the difference between GENERIC and your config that is causing the problem? (I suppose it makes sense that your config would work, since I think that Dell is a Serverworks-based system too.) I'll see if I can figure it out... 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: Mon Feb 25 22:01:01 MST 2002 [EMAIL PROTECTED]:/usr/home/ken/perforce/FreeBSD-ken/src/sys/i386/compile/dilloncfg Preloaded elf kernel /boot/kernel.dillon/kernel at 0xc03c6000. Preloaded elf module /boot/kernel.dillon/acpi.ko at 0xc03c60b0. Timecounter i8254 frequency 1193182 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 = 2610569216 (2549384K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 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 IOAPIC #1 intpin 10 - irq 2 IOAPIC #1 intpin 11 - irq 5 IOAPIC #1 intpin 15 - irq 9 pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 0.1 on pci0 IOAPIC #1 intpin 14 - irq 11 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 2 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 5 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 pci0: serial bus, USB at device 15.2 (no driver attached) pcib2: ServerWorks host to PCI bridge at pcibus 2 on motherboard IOAPIC #1 intpin 8 - irq 16 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 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 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 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 APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2 APIC_IO: routing 8254 via 8259 and
Re: HEADS UP: cvs commit: src/sys/conf kern.pre.mk (fwd)
On Mon, 2002-02-25 at 20:59, M. Warner Losh wrote: I've fixed a few of the low hanging fruit, but I don't know how to get rid of warnings like: const char *foo = blah; char *baz = foo; when I know they are safe. Correct me if I'm wrong, but isn't the correct declaration: const char foo[] = blah; char baz[] = foo; cheers, mike makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current hangs with SMP enabled
: 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. : :Your config works! : :I've attached the dmesg. Now the question is, what is the difference :between GENERIC and your config that is causing the problem? : :(I suppose it makes sense that your config would work, since I think that :Dell is a Serverworks-based system too.) : :I'll see if I can figure it out... : :Ken :-- :Kenneth Merry Wow, I didn't actually expect my config would make things work differenty on your box. I'm very interested in whatever you turn up. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current hangs with SMP enabled
On Mon, Feb 25, 2002 at 21:29:44 -0800, Matthew Dillon wrote: : 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. : :Your config works! : :I've attached the dmesg. Now the question is, what is the difference :between GENERIC and your config that is causing the problem? : :(I suppose it makes sense that your config would work, since I think that :Dell is a Serverworks-based system too.) : :I'll see if I can figure it out... : :Ken :-- :Kenneth Merry Wow, I didn't actually expect my config would make things work differenty on your box. I'm very interested in whatever you turn up. The answer is...the USB code. [ Nick and Joe CCed ] If I comment out the following lines in my standard config for this machine, SMP works: # USB support device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device usb # USB Bus (required) #device udbp# USB Double Bulk Pipe devices device ugen# Generic device uhid# Human Interface Devices device ukbd# Keyboard device ulpt# Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio# Diamond Rio 500 MP3 player device uscanner# Scanners # USB Ethernet, requires mii device aue # ADMtek USB ethernet device cue # CATC USB ethernet device kue # Kawasaki LSI USB ethernet The USB module is still loaded when usbd cranks up, but it doesn't hang the machine when it is loaded as a module. I've tried two kernels, with the only difference being whether the usb code (as listed above) is enabled or not. The kernel with the USB stuff hangs. I've attached dmesg output from the working boot. 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 #4: Mon Feb 25 22:23:37 MST 2002 [EMAIL PROTECTED]:/usr/home/ken/perforce/FreeBSD-ken/src/sys/i386/compile/gondolin Preloaded elf kernel /boot/kernel.gondolin.smp/kernel at 0xc04c7000. Preloaded elf module /boot/kernel.gondolin.smp/acpi.ko at 0xc04c70b8. Timecounter i8254 frequency 1193182 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 = 2609504256 (2548344K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 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 IOAPIC #1 intpin 10 - irq 2 IOAPIC #1 intpin 11 - irq 5 IOAPIC #1 intpin 15 - irq 9 pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 0.1 on pci0 IOAPIC #1 intpin 14 - irq 11 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 2 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 5 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 pci0: serial bus, USB at device 15.2 (no driver
Re: HEADS UP: cvs commit: src/sys/conf kern.pre.mk (fwd)
In message: [EMAIL PROTECTED] Mike Makonnen [EMAIL PROTECTED] writes: : On Mon, 2002-02-25 at 20:59, M. Warner Losh wrote: : I've fixed a few of the low hanging fruit, but I don't know how to get : rid of warnings like: : : const char *foo = blah; : char *baz = foo; : : when I know they are safe. : : Correct me if I'm wrong, but isn't the correct declaration: : : const char foo[] = blah; : char baz[] = foo; You miss the point. First, there's no around foo. Second, what I quoted was boiled down from a bunch of macros and such. Third, the real example would be volatile int conspeed; int *foo = conspeed; Where foo is only accessed before all other accesses to conspeed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: cvs commit: src/sys/conf kern.pre.mk (fwd)
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Peter Wemm [EMAIL PROTECTED] writes: : There are a couple of offending files in the kernel still, and some : drivers. The things people are most likely to run into are: usb, inet6, : and some drivers (twe, asr etc). I've fixed a few of the low hanging fruit, but I don't know how to get rid of warnings like: const char *foo = blah; char *baz = foo; when I know they are safe. char *baz = (char *)(uintptr_t)foo; ... will work, but isn't exactly pretty. I vaguely recall being told that it should be cast to void * first.. ie: char *baz = (char *)(uintptr_t)(const void *)foo; Warner Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: First (easy) td_ucred patch
On 23-Feb-02 Julian Elischer wrote:
On Fri, 22 Feb 2002, John Baldwin wrote:
http://www.FreeBSD.org/~jhb/patches/ucred.patch
The following diff removes the capacity to cope with the case when td is
NULL. I presume it is there because it CAN be NULL. (Though I have not
checked further.)
No, it can't be NULL anymore. In 4.x, when we were idle, curproc could be
null. In current we have an idle thread context, so we td can't be null except
for very, _very_ early during startup which this code doesn't need to worry
about. :)
--- //depot/vendor/freebsd/sys/fs/smbfs/smbfs_vnops.c 2001/12/20
08:43:46
+++ //depot/projects/smpng/sys/fs/smbfs/smbfs_vnops.c 2002/02/21
15:55:47
@@ -976,7 +976,6 @@
caddr_t id = (caddr_t)1 /* ap-a_id */;
/* int flags = ap-a_flags;*/
struct thread *td = curthread;
- struct proc *p = td ? td-td_proc : NULL;
struct smb_cred scred;
u_quad_t size;
off_t start, end, oadd;
@@ -1027,7 +1026,7 @@
return EOVERFLOW;
end = start + oadd;
}
- smb_makescred(scred, td, p ? p-p_ucred : NULL);
+ smb_makescred(scred, td, td-td_ucred);
switch (ap-a_op) {
case F_SETLK:
switch (fl-l_type) {
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: First (easy) td_ucred patch
On 24-Feb-02 Julian Elischer wrote: 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. I can do separate commits, that's not a problem. 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 -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: How to fix malloc.
On 23-Feb-02 Alfred Perlstein wrote: * Matthew Dillon [EMAIL PROTECTED] [020223 12:51] wrote: :Here is the most up-to-date version of pgrp/session lock (at Change 6700): : :http://people.FreeBSD.org/~tanimura/patches/pgrp10.diff.gz : :I would like to commit this on the next Sunday. Otherwise, my patch :would conflict with other patches, especially tty. : :-- :Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] Do you have any plans to get pgdelete() out from under Giant? That would allow leavepgrp(), doenterpgrp(), enterpgrp(), enterthispgrp(), setsid() (mostly) to be taken out from under Giant, and perhaps a few others. I was thinking of simply having a free list of sessions and process groups, locked by PGRPSESS_XLOCK(). pgdelete() would then not have to call FREE() and setsid() would almost always be able to pull a new structure of the appropriate free list and thus not have to obtain Giant for the MALLOC. All these per-subsystem free-lists are making me nervous in both complexity and wasted code... Ok, instead of keeping all these per-subsystem free-lists here's what we do: In kern_malloc:free() right at the point of if (size MAXALLOCSAVE) we check if we have Giant or not. if we do not then we simply queue the memory however, if we do then we call into kmem_free with all the queued memory. This ought to solve the issue without making us keep all these per-cpu caches. By the way, since MAXALLOCSAVE is some multiple of PAGE_SIZE, we really don't have to worry about it when freeing small structures although that puts evilness into malloc(9) consumers. Can you please consider that instead of continueing down this path of per-subsystem caches? Just as a general heads up, the slab memory allocator Jeff Roberson is working on will not need Giant for the free path, so can we just live with Giant locking around free() for now rather than adding in a bunch of temporary hacks to reinvent the wheel that we have to go back and remove later? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Success! critical_enter()/critical_exit() revamp (was Re: m
On 24-Feb-02 Matthew Dillon wrote: 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(). Err, this is a feature. It isn't safe for us to take an interrupt until we have safeuly cleaned up and released sched_lock. 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). That's cause the state of PSL_I is saved in td_savecrit. Note that the only caller of cpu_switch() is mi_switch(). You need to look at the two functions together. Much of the stuff that used to be in asm is now in C to make the code more portable so that supporting other arch's is easier. While the state for pending interrupts should be per-CPU, you should still be using some per-thread state since we can call switch with interrupts disabled (this happens when we preempt with interrupts disabled.) Speaking of preemption. :) critical_enter/exit are specifically divided into two portions: and MD portion and an MI portion. The preemption patches grow the MI functions a bit to handle deferred preemptions. It would be best if instead of getting rid of the MI functions you would work within the existing framework and architecture and change the implementation of cpu_critical_enter/exit. Note that you have a fully opaque type critical_t to allow you to store whatever per-thread state you wish. Also, you are free to use whatever per-CPU state as well. 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. Eww, how does that work unless the other CPU uses an atomic op to clear the bit, which means that now the local CPU needs to use atomic ops to ensure consistent data. -Matt -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
On 26-Feb-02 Peter Wemm wrote: Matthew Dillon wrote: : :On Mon, 25 Feb 2002, Matthew Dillon wrote: : : Unless an unforseen problem arises, I am going to commit this : tomorrow : and then start working on a cleanup patch. I have decided to : :Please wait for jhb's opinion on it. He seems to be offline again. :I think he has plans and maybe even code for more code in critical_enter(). :I think we don't agree with these plans, but they are just as valid :as ours, and our versions undo many of his old changes. I am not going to predicate my every move on permission from JHB nor do I intend to repeat the last debacle which held-up (and is still holdin g up) potential commits for a week and a half now. JHB hasn't even committed *HIS* patches and I am beginning to wonder what the point is when *NOTHING* goes in. If he had code he damn well should have said something on the lists two days ago. As it is, I have invested a great deal of time and effort on this patch and it is damn well going to go in so I can move on. So, your great deal of time and effort over the last week is more important than our time and effort over the last few months? Kernel preemption was first written at Usenix last June. It's been stable on UP x86 for months but we still have preemption bugs on other systems that prevent it from going in at the time being. Having a fully preemptive kernel simplifies many things and is the same design path used by other major multithreaded Unix-like kernels. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld failed in tcsh
cvsup'ed yesterday and make install (after a successful make buildworld) failed somewhere in building tcsh. I don't know though if the ritual of building the world has changed over time so significantly that intuition always fails. -- Chris Christoph P. U. Kukulies [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 26-Feb-02 Kenneth D. Merry wrote: On Mon, Feb 25, 2002 at 21:29:44 -0800, Matthew Dillon wrote: : 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. : :Your config works! : :I've attached the dmesg. Now the question is, what is the difference :between GENERIC and your config that is causing the problem? : :(I suppose it makes sense that your config would work, since I think that :Dell is a Serverworks-based system too.) : :I'll see if I can figure it out... : :Ken :-- :Kenneth Merry Wow, I didn't actually expect my config would make things work differenty on your box. I'm very interested in whatever you turn up. The answer is...the USB code. [ Nick and Joe CCed ] If I comment out the following lines in my standard config for this machine, SMP works: Ah yes! We had a test machine at TWC that came in that we couldnt' install 4.5 on (even with the UP kernel on the boot disk) due to getting an interrupt storm of USB interrupts. # USB support device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device usb # USB Bus (required) #device udbp# USB Double Bulk Pipe devices device ugen# Generic device uhid# Human Interface Devices device ukbd# Keyboard device ulpt# Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio# Diamond Rio 500 MP3 player device uscanner# Scanners # USB Ethernet, requires mii device aue # ADMtek USB ethernet device cue # CATC USB ethernet device kue # Kawasaki LSI USB ethernet The USB module is still loaded when usbd cranks up, but it doesn't hang the machine when it is loaded as a module. I've tried two kernels, with the only difference being whether the usb code (as listed above) is enabled or not. The kernel with the USB stuff hangs. I've attached dmesg output from the working boot. Ken -- Kenneth Merry [EMAIL PROTECTED] -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current hangs with SMP enabled
+---[ Kenneth D. Merry ]-- | | The answer is...the USB code. I have also solved my problem, and my answer is SMB code.. When booting an SMP kernel with SMB enabled, trying to access /dev/smb0 returns device not configured (works fine in UP mode). Removing the SMB (and related options) from my kernel config and I'm through a buildworld. I'm going to do a few more to make sure it's not a fluke, but, somehow I think that's it. So can I take it the smbbus on my mobo is hosed? -- 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 assem
On 26-Feb-02 Matthew Dillon wrote: : :On Mon, 25 Feb 2002, Matthew Dillon wrote: : : Unless an unforseen problem arises, I am going to commit this tomorrow : and then start working on a cleanup patch. I have decided to : :Please wait for jhb's opinion on it. He seems to be offline again. :I think he has plans and maybe even code for more code in critical_enter(). :I think we don't agree with these plans, but they are just as valid :as ours, and our versions undo many of his old changes. I am not going to predicate my every move on permission from JHB nor do I intend to repeat the last debacle which held-up (and is still holding up) potential commits for a week and a half now. JHB hasn't even committed *HIS* patches and I am beginning to wonder what the point is when *NOTHING* goes in. If he had code he damn well should have said something on the lists two days ago. As it is, I have invested a great deal of time and effort on this patch and it is damn well going to go in so I can move on. I've been taking the weekend off so I could have some think to cool off and think and not get all emotional. The reasons I haven't committed the td_ucred stuff are: 1) I had an ugly panic testing it on the alpha. After a good deal of sleuthing, I've determined that we still have some preemption related bugs in possibly the alpha pmap, but that td_ucred isn't the problem. 2) I've been thinking about the Giant instrumentation a bit. I figured out that most of my problems were with the implementation and have come up with some ideas that might make it a bit more scalable and easier from a long-term perspective though I think it still has some scaling issues. In regards to the critical section stuff: The critical section stuff currently in current is part of the original preemption patches I wrote at Usenix last year. They aren't in the tree because they aren't stable yet. We still have problems on the alpha and problems with IPI deadlocks on SMP machines that need to be worked out. Since this API is still very much in flux I'd prefer to keep it simple for now and not make the code overly complex with optimizations until after we have settled on the design. You've brought up some issues with the critical section stuff as far as its assumptions in fork_exit() and a few other places. For now I would prefer to leave that code alone as it works with our current model. However, I am interested in fixing assumptions that would allow the cpu_critical_enter/exit API to be changed but still maintain an MI interface. This could mean changing the API for cpu_critical_enter/exit and possibly the API (perhaps some MD macros?) for the fork_exit() fixup code. -Matt -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RE: Success! critical_enter()/critical_exit() revamp (was Re: m
: : :On 24-Feb-02 Matthew Dillon wrote: : 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(). : :Err, this is a feature. It isn't safe for us to take an interrupt until we :have safeuly cleaned up and released sched_lock. This and your other comments only apply to systems that have a hard interrupt disablement side effect to critical_enter(). My critical_*() patch set (partially based on BDE's work) removes this requirement and exposes two flaws in the existing MI code (discussed on the lists already). One is a flaw in fork_exit() due to it making improper assumptions as to the nature of the trampoline code to close a td_critnest/sched_lock initialization race, and the other is a flaw in ast() which uses cpu_critical_*() routines as a hack to tightly couple it with MD doreti(). In fact, the assembly that calls ast() should be responsible for placing the machine in the proper critical state. These are not 'bugs' per say, because the flaws remain consistent within their domain. But they are flaws. I am rather disturbed that you keep explaining the flaws and MD/MI cross pollution away as being a 'feature'. It most certainly is not a feature. I am also disturbed that these special interactions assumptions were not documented *anywhere* in the critical_*() or cpu_critical_*() code. And, finally, I am extremely disturbed about the logic you use to justify both the two-level critical_*() API and to justify the hacks in fork_exit() and ast(). In anycase, it's going to become moot very soon now as I clean it up. -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 assem
:1) I had an ugly panic testing it on the alpha. After a good deal of sleuthing, : I've determined that we still have some preemption related bugs in possibly : the alpha pmap, but that td_ucred isn't the problem. :2) I've been thinking about the Giant instrumentation a bit. I figured out that : most of my problems were with the implementation and have come up with some : ideas that might make it a bit more scalable and easier from a long-term : perspective though I think it still has some scaling issues. This is precisely the problem. You are making so many modifications in your local tree that NONE of the work winds up getting committed for months and months. :In regards to the critical section stuff: : :The critical section stuff currently in current is part of the original :preemption patches I wrote at Usenix last year. They aren't in the tree :because they aren't stable yet. We still have problems on the alpha and :problems with IPI deadlocks on SMP machines that need to be worked out. Since :this API is still very much in flux I'd prefer to keep it simple for now and :not make the code overly complex with optimizations until after we have settled :on the design. : :You've brought up some issues with the critical section stuff as far as its :assumptions in fork_exit() and a few other places. For now I would prefer to :leave that code alone as it works with our current model. However, I am :interested in fixing assumptions that would allow the cpu_critical_enter/exit :API to be changed but still maintain an MI interface. This could mean changing :the API for cpu_critical_enter/exit and possibly the API (perhaps some MD :macros?) for the fork_exit() fixup code. : : :John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ I'm sorry John, but I am going to go ahead with my commit. I strongly disagree with your premise and, frankly, my changes clean the code up rather then make it more complex. You have your fingers in just about every single goddamn file in the system and you and others have cried wolf one too many times. I am through with playing that game. The commit goes in. I am open to any suggestions you have for stage-2, which will be a furtherance of the cleanup, but I absolutely refuse to allow you to prevent me from contributing to the SMP work in -current for a forth time because it doesn't exactly match your dream or N-month-old stale patches you might have sitting around in P4. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Future of HARP ATM stack in freebsd...
---BeginMessage--- The two hardware drivers for the HARP ATM stack has been broken in -current for a LNG time now. If nobody are have sufficient interest in the HARP ATM stack to actually fix these two drivers, we should retire the entire thing from -current. So consider this a last call, if the drivers are not fixed by may 1st the HARP ATM stack will be put in the attic. If anybody is interested in actively maintaining this code, I may be able to find a donor for some ATM cards. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ---End Message---
Re: Patch for critical_enter()/critical_exit() interrupt assem
On Tue, 26 Feb 2002, John Baldwin wrote: The critical section stuff currently in current is part of the original preemption patches I wrote at Usenix last year. They aren't in the tree because they aren't stable yet. We still have problems on the alpha and problems with IPI deadlocks on SMP machines that need to be worked out. Since this API is still very much in flux I'd prefer to keep it simple for now and not make the code overly complex with optimizations until after we have settled on the design. The change is mostly part of the design change needed to un-break fast interrupt handlers. critical_enter() mask not mask hardware interrupts for the same reason than splhigh() must not mask them: there is too much MI code that thinks it is critical and short but really isn't (e.g., everything under spinlocks in -current). Changing cpu_critical_enter() to a null version to prevent spinlocks masking interrupts doesn't work very well because it is used for other things that really do need to mask interrupts. Having 2 levels for cpu_critical_enter() (on that masks normal interrupts and one that masks fast interrupts) would work but I think there are already too many levels of critical_enter()s. Bruce 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 assem
: The critical section stuff currently in current is part of the original : preemption patches I wrote at Usenix last year. They aren't in the tree : because they aren't stable yet. We still have problems on the alpha and : problems with IPI deadlocks on SMP machines that need to be worked out. Since : this API is still very much in flux I'd prefer to keep it simple for now and : not make the code overly complex with optimizations until after we have settled : on the design. : :The change is mostly part of the design change needed to un-break fast :interrupt handlers. critical_enter() mask not mask hardware :interrupts for the same reason than splhigh() must not mask them: :there is too much MI code that thinks it is critical and short but :really isn't (e.g., everything under spinlocks in -current). Changing :cpu_critical_enter() to a null version to prevent spinlocks masking :interrupts doesn't work very well because it is used for other things :that really do need to mask interrupts. Having 2 levels for :cpu_critical_enter() (on that masks normal interrupts and one that :masks fast interrupts) would work but I think there are already too :many levels of critical_enter()s. : :Bruce Not to mention the fact that this will lead to an ability to break into the debugger via the serial concsole even if the code is stuck in a spin mutex or in the middle of the scheduler. Not with this commit or the followup cleanup commit, not quite, but maybe the one after. It puts us on the right road. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
