bus_alloc_resouce() failure for OPTi 82C861
Hi there,
I installed -CURRENT on my old PC(ThinkPad235 aka Chandra2),
but its USB device doesn't work.
(it works on Windows environment)
[boot message]
ohci0: OPTi 82C861 (FireLink) USB controller irq 10 at device 5.0 on pci0
ohci0: Could not map memory
device_probe_and_attach: ohci0 attach returned 6
in source code, sys/pci/ohci_pci.c
rid = PCI_CBMEM;
sc-io_res = bus_alloc_resource(self, SYS_RES_MEMORY, rid,
0, ~0, 1, RF_ACTIVE);
if (!sc-io_res) {
device_printf(self, Could not map memory\n);
return ENXIO;
}
It seems the function bus_alloc_resource() returns NULL.
How can I avoid this failure?
TIA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bus_alloc_resouce() failure for OPTi 82C861
In message: [EMAIL PROTECTED]
FUJITA Kazutoshi [EMAIL PROTECTED] writes:
: Hi there,
:
: I installed -CURRENT on my old PC(ThinkPad235 aka Chandra2),
: but its USB device doesn't work.
: (it works on Windows environment)
:
: [boot message]
: ohci0: OPTi 82C861 (FireLink) USB controller irq 10 at device 5.0 on pci0
: ohci0: Could not map memory
: device_probe_and_attach: ohci0 attach returned 6
:
:
: in source code, sys/pci/ohci_pci.c
:
: rid = PCI_CBMEM;
: sc-io_res = bus_alloc_resource(self, SYS_RES_MEMORY, rid,
: 0, ~0, 1, RF_ACTIVE);
: if (!sc-io_res) {
: device_printf(self, Could not map memory\n);
: return ENXIO;
: }
:
: It seems the function bus_alloc_resource() returns NULL.
:
: How can I avoid this failure?
You can't. However, you can work around it like the pccbb driver
does. It would be better if these things were handled in the pci bus
layer, but someone would need to implement that.
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 assem
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : We have very different development models, and different priorities. : I'm not sure why you are attempting to impose your development model : and priorities on me. This is the work I want to do. It's my time : here, not yours, and if you believe that the work will make your job : harder in some future unspecified commit then you have only to bring : up the issue down the road when you are actually ready to work on : that future unspecified commit and we can work it out. But I don't : think it's appropriate for you to impose such a strict set of requirements : based on work that does not exist in -current anywhere as far as I can : tell. While your time is your time, it isn't your tree. It isn't my tree. The tree is a shared resource that we all must respect. There are times that it is reasonable to have restrictions on what can go into the tree. Since smpng is being coordinated amoung several developers in the tree, there are some restrictions that may come with that. I think that such restrictions are reasonable and the price of doing business in a shared resource. I think that's a fundamental decision about the tree that has been made that your development model is at odds with and the source of much of the current dispute over commit or not to commit the changes. In the past there have been a number of restrictions on what can and can't go into the tree. I needn't enumerate them here, but I will add that there have been times where special restrictions were in place that weren't in place at other times. We're entering the glide path to 5.0, so I would expect there to be more such restrictions coming from the release engineer and maybe others as we move towards that release. I'm not saying that your patches necessarily fall under these restrictions, but I am saying that to assert that your time is yours and therefore anything that you do can go into the tree is a false premise. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libcrypt crypt-md5.c crypt.c crypt.h misc.c src/secure/lib/libcrypt blowfish.c blowfish.h crypt-blowfish.c crypt-des.c
In article [EMAIL PROTECTED] Mark Murray [EMAIL PROTECTED] wrote: markm 2002/03/06 09:18:09 PST Modified files: lib/libcrypt crypt-md5.c crypt.c crypt.h misc.c secure/lib/libcrypt blowfish.c blowfish.h crypt-blowfish.c crypt-des.c Log: No functional change, but big code cleanup. WARNS, lint(1) and style(9). This comment is false. On my -CURRENT system with this commit in place 'passwd' and 'login'/'su' commands loops forever computing MD5 password. After reverting crypt-md5.c to rev. 1.8 all thouse commands work as always. Was this cleanup tested ? N.Dudorov Revision ChangesPath 1.9 +47 -47src/lib/libcrypt/crypt-md5.c 1.22 +9 -7 src/lib/libcrypt/crypt.c 1.7 +2 -2 src/lib/libcrypt/crypt.h 1.3 +6 -5 src/lib/libcrypt/misc.c 1.3 +13 -110 src/secure/lib/libcrypt/blowfish.c 1.2 +13 -13src/secure/lib/libcrypt/blowfish.h 1.3 +26 -59src/secure/lib/libcrypt/crypt-blowfish.c 1.16 +40 -34src/secure/lib/libcrypt/crypt-des.c To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cardbus problem
Hi! I have xl0: watchdog timeout on my 3Com cardbus card after updating kernel recently. Everything seems to be OK during boot, but xl0: watchdog timeout starts directly after ifconfig, and makes network incredibly slow. boot -v will not boot at all, it stops somewhere around cardbus_attach_card. It seems the problem is in recent changes to sys/dev/cardbus, because taking the August version of sys/dev/cardbus/* files resolved the problem. Further investigation is needed. I attach dmesg output below. -- Yuri Khotyaintsev Swedish Institute of Space Physics, Uppsala Division, Box 537, S-75121 Uppsala 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 Mar 4 23:11:04 CET 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/JAZZ Preloaded elf kernel /boot//kernel/kernel at 0xc0454000. Preloaded elf module /boot//kernel/acpi.ko at 0xc04540ac. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x66a Stepping = 10 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 100597760 (98240K bytes) avail memory = 93360128 (91172K bytes) Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00fdf30 ACPI-0567: *** Warning: Reference BAT0 at AML 1276 not found ACPI-0567: *** Warning: Reference BAT1 at AML 127a not found apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface acpi0: Other PM system enabled. 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) pcm0: ESS Technology Maestro-2E port 0xf800-0xf8ff irq 5 at device 6.0 on pci0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfcd0-0xfcdf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 7.2 (no driver attached) pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pccbb0: TI1220 PCI-CardBus Bridge irq 11 at device 10.0 on pci0 cardbus0: CardBus bus on pccbb0 pccbb1: TI1220 PCI-CardBus Bridge irq 11 at device 10.1 on pci0 cardbus1: CardBus bus on pccbb1 orm0: Option ROM at iomem 0xc-0xcefff 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 GlidePoint, 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 (NIBBLE-only) in COMPATIBLE mode 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: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 TUPLE: LINKTARGET [3]: 43 49 53 Product version: 5.0 Product name: 3Com Corporation | 3CCFEM656B-LAN | LAN | 1 | Manufacturer ID: 02016265 Functions: Network Adaptor, Multi-Functioned TUPLE: DEVICE_OC [2]: 02 ff cardbus1: Opening BAR: type=IO, bar=10, len=0080 cardbus1: Opening BAR: type=MEM, bar=14, len=0100 TUPLE: CONFIG_CB [6]: 03 01 00 00 00 00 TUPLE: CFTABLE_ENTRY_CB [15]: 41 ba 01 b5 1e 01 b5 1e 02 30 f8 ff 04 01 02 CIS reading done cardbus1: Resource not specified in CIS: id=18, size=80 cardbus1: Non-prefetchable memory at 84002000-8400217f cardbus1: Non-prefetchable memory rid=14 at 84002000-840020ff (100) cardbus1: Non-prefetchable memory rid=18 at 84002000-8400207f (80) cardbus1: IO port at 1000-107f cardbus1: IO port rid=10 at 1000-107f xl0: 3Com 3c656B Fast Etherlink XL port 0x1000-0x107f mem 0x84002000-0x8400207f,0x84002000-0x840020ff irq 11 at device 0.0 on cardbus1 xl0: Ethernet address: 00:50:04:92:29:17 miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto TUPLE: LINKTARGET [3]: 43 49 53 Product version: 5.0 Product name: 3Com Corporation | 3CCFEM656B-MDM | MDM | 1 | Manufacturer ID: 02016365 Functions: Serial Port, Multi-Functioned TUPLE: DEVICE_OC [2]: 02 ff cardbus1: Opening BAR: type=MEM, bar=18, len=1000 TUPLE: CONFIG_CB [6]: 03 01 00 00 00 00 TUPLE: CFTABLE_ENTRY_CB [14]: 41 b2
3ware (twe) driver updated (HEADS UP)
Just a quick note to let people know that the 3ware driver twe(4) driver has been updated to deal with 3ware's latest firmware releases. These changes have been tested for a couple of weeks now. One other important note for owners of 7xxx series controllers; the 7.4 firmware update is due out this week. Recent shipping controllers have reportedly had problems with large I/Os (128kB) and this update addresses this issue, so you are advised to upgrade. 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
Re: cvs commit: src/lib/libcrypt crypt-md5.c crypt.c crypt.h misc.c src/secure/lib/libcrypt blowfish.c blowfish.h crypt-blowfish.c crypt-des.c
This comment is false. On my -CURRENT system with this commit in place 'passwd' and 'login'/'su' commands loops forever computing MD5 password. After reverting crypt-md5.c to rev. 1.8 all thouse commands work as always. It was a signed/unsiged issue. Fixed! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Contemplating THIS change to signals.
I mentioned something similar for a different reason. Go look at the last
part of the following message in the recent -hackers archives:
Subject: ptrace bug?
MessageId: [EMAIL PROTECTED]
(this was for -stable, BTW)
Having the suspend for the ptrace()ing parent done in issignal is a pain
when issignal is called multiple times by the debuggee before getting back
to userland. The debugger sees wait() return more than once reporting the
same signal depending on where the victim process was when it stopped, and
the code path back to userland. It's particularly noticable when the
ptrace(PT_CONTINUE) tries to continue the process with a signal, and the
signal arrives back at the debugger. The debugger has no idea wheather it
sees the signal because it tried to send it, or the same signal raised for
some other reason. The results of this can be seen in GDB frequently when
you use the signal command.
I suggested moving the ptrace handling to postsig(), but anything along the
lines of what you are mentioning seems like an improvement to me, and I'm
sure you're much more likely to know what you're doing :-) I only delved in
here briefly to try and work out some of the non-obvious behaviour of
ptrace().
Oh, and while your mucking with issignal(), any chance of looking at the bug
raised (and the patch) in the start of that message, and in PR kern/35175?
:-)
--
Peter
Julian Elischer wrote:
Maybe this should be in -arch.. I couldn;t make my mind up,
but..
There is some behaviour in signals which seems
1/ un-neccesary
2/ potentially dangerous.
in addition it is
3/ Definitly incompatible with KSEs.
I am hoping that someone can give me a good reason why it is done, and
failing that, I'm hoping people can give comments on my thoughts.
The behavious in question was inherrited from BSD4.4-LITE2
When the sleep code (tsleep,msleep, cv{stuff})
checks to see if there is a pending signal that might cause the sleep
to abort, it calls CURSIG() which calls issignal,
which in turn might decide to actually suspend the process.
(if the user hit ^Z for example)
This is fine when CURSIG is called from userret(), because we are on the
user boundary, however calling it from the sleep()
call seems a rather UN-NICE thing to do.
One could argue that it is safe because you are not allowed to sleep
while holding resources (um is it not possible to sleep
while holding a vnode?) but it seems that it is possible to hit ^Z
at teh right moment while something is holding some resource
(during what it expects to be a very short term sleep,) and end up
blocking the whole system.
I would argue that a process can be considered to be suspended even while
it is running in kernel space. My definition of a suspended process
would be one that id not running any user code. it is not making any
headway on the userland program. This I put it to the group that
it is sufficient to only suspend a process when it is crossing the user
boundary. (returning to user space)
My suggestion is to remove teh code in issignal() that perfoms the
blocking actions and create a separate function that does that action.
I would then call that function from userret() immediatly after the call
to issignal(). The result would be that
suspended processes would still not reach userland, but processes would
not have to option of suspending indefinitly at sleep().
The signal would still cut short the sleep, but the process would be
allowed to proceed to the user boundary, at which point it would
be suspended as before.
If anyone has any reasons they think this is a bad idea, then please speak
up. Neithe Matt (Dillon) nor I can see that stopping in msleep
is required, and both of us are in fact un-easy with it.
In a THREADED world it gets even more complicated, because
the SUSPENDED state is a PER_PROCESS state, which means that
you are not suspented until ALL THERADS have left userland
and been counted as 'suspended'.
Having some threads stopped 'near' msleep and others stopped at the
userland boundary is asking for trouble in my opinion.
I can not think of any downside to making the suspension
(whether from ptrace, or a signal) only occur at the user boundary.
If I hear NO arguments I'll take it that no-one can think of any reasons
to not change the code. If yuo have a reason PLEASE speak up so that we
can discuss it and try figure out whether it is real or can be
gotten around in some manner.
Julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
5-CURRENT source upgrade path is broken in PAM
Hi, Looks like source upgrade path is broken due to PAM. My system is -CURRENT compiled on 19 February. Please fix. -Maxim === libpam/modules/pam_ftp cc -pipe -O -mpreferred-stack-boundary=2 -march=pentium -I/usr/src/lib/libpam/mo dules/pam_ftp/../../../../contrib/openpam/libpam/include -I/usr/src/lib/libpam/m odules/pam_ftp/../../libpam -c /usr/src/lib/libpam/modules/pam_ftp/pam_ftp.c -o pam_ftp.o cc -fpic -DPIC -pipe -O -mpreferred-stack-boundary=2 -march=pentium -I/usr/src/l ib/libpam/modules/pam_ftp/../../../../contrib/openpam/libpam/include -I/usr/src/ lib/libpam/modules/pam_ftp/../../libpam -c /usr/src/lib/libpam/modules/pam_ftp/ pam_ftp.c -o pam_ftp.So /usr/src/lib/libpam/modules/pam_ftp/pam_ftp.c: In function `pam_sm_authenticate' : /usr/src/lib/libpam/modules/pam_ftp/pam_ftp.c:155: warning: passing arg 3 of `pa m_prompt' from incompatible pointer type /usr/src/lib/libpam/modules/pam_ftp/pam_ftp.c:155: warning: passing arg 4 of `pa m_prompt' from incompatible pointer type /usr/src/lib/libpam/modules/pam_ftp/pam_ftp.c:155: too many arguments to functio n `pam_prompt' /usr/src/lib/libpam/modules/pam_ftp/pam_ftp.c: In function `pam_sm_authenticate' : /usr/src/lib/libpam/modules/pam_ftp/pam_ftp.c:155: warning: passing arg 3 of `pa m_prompt' from incompatible pointer type /usr/src/lib/libpam/modules/pam_ftp/pam_ftp.c:155: warning: passing arg 4 of `pa m_prompt' from incompatible pointer type /usr/src/lib/libpam/modules/pam_ftp/pam_ftp.c:155: too many arguments to functio n `pam_prompt' *** Error code 1 *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Maxim Sobolev [EMAIL PROTECTED] writes: Looks like source upgrade path is broken due to PAM. My system is -CURRENT compiled on 19 February. Please fix. Please use 'make world' to upgrade your system. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Dag-Erling Smorgrav wrote: Maxim Sobolev [EMAIL PROTECTED] writes: Looks like source upgrade path is broken due to PAM. My system is -CURRENT compiled on 19 February. Please fix. Please use 'make world' to upgrade your system. I'm using `make world' (well buildworld, but it shouln't matter). -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Maxim Sobolev wrote: Dag-Erling Smorgrav wrote: Maxim Sobolev [EMAIL PROTECTED] writes: Looks like source upgrade path is broken due to PAM. My system is -CURRENT compiled on 19 February. Please fix. Please use 'make world' to upgrade your system. I'm using `make world' (well buildworld, but it shouln't matter). To be more crear: those errors are result of doing `make world'. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
On Thu, 7 Mar 2002 13:30:44 +0200 (EET), Maxim Sobolev [EMAIL PROTECTED] said: Maxim Hi, Looks like source upgrade path is broken due to PAM. My Maxim system is -CURRENT compiled on 19 February. Please fix. Could this have anything to do with the fact that, since I built world yesterday, I can't log in as root? -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota A witty saying proves nothing. -- Voltaire 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 API is intended for the stage-2 commit. The stage-1 commit is intended to do all the 'hard stuff' in as straightforward a manner as possible. The sysctl / option you talk about here existed in my patch set 2 and a half weeks ago. The API and getting it right is more important than the hard stuff. Its not as fun, but the API will outlive the code (consider the next arch, and the next). It may take more of your time due to discussion and feedback to get the API in place, but that's part of the cost of collaboration. I really wish you people would at least read the patch and commit message before you comment on it. I didn't have to read the patch to know that there were concerns and on-going discussion about the API. In this instance, the issues are not large and can be remedied quickly - all the more reason for the discussion to take place before the commit. I didn't have to read the patch to know that you didn't seem to care about getting the API right before commiting the code. The API was something to be cleaned up later. If you have problems with my API, I'll even help merge your changes into mine, but I need to commit now. Lets discuss this after the commit. This project is not about a race to commit. [Perhaps my viewpoint here is a bit different then some seeing as the CAM stuff was 1.5 years old by the time it was committed to the tree. I know all about painful merge conflicts.] I didn't have to read the patch to know that you would only remove your commit if someone could point to specific defects in the hard part of your submission. The hard part, how it works, and whether it contained any bugs or not was not the real issue. This is why you and John were talking right past each other. Don't get me wrong, Matt. I don't think you should be unduley held off from committing either. From my perspective of the discussion so far, other than the delay for John to get back home from BSDcon, we could have finished the discussion about the API and committed this stuff a week ago if the focus wasn't on how you were personally wronged, or John is holding up the whole tree, or my changes are correct, my changes are correct. All of the above may be true, but focusing on the particular events instead of the *process to avoid them recurring in the future* will only lead to more frustration and you wanting to work on -stable instead of -current, etc. You're a good engineer Matt. You've shown before that you can colloborate and coordinate with others in this project. The only issue is how that colloboration takes place, and the *process* for getting things done. If the process makes it twice as hard for us to get things done, then it's broken. In that case, *attack the process*, not the person. The process can and will change but only if we set aside personal indignity (why should I have to put up with this crap!?!?) and attack our problems and goals as engineers. Sometimes the flare-ups in FreeBSD remind me of the middle-east. Each side accuses the other side of starting it, or having the blame. In reality, both sides were jerks, own portions of the blame, and have concentrated on continuing the conflagration rather than mitigating it. I hope we have a better perspective on reality. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Michael D. Harnois wrote: On Thu, 7 Mar 2002 13:30:44 +0200 (EET), Maxim Sobolev [EMAIL PROTECTED] said: Maxim Hi, Looks like source upgrade path is broken due to PAM. My Maxim system is -CURRENT compiled on 19 February. Please fix. Could this have anything to do with the fact that, since I built world yesterday, I can't log in as root? Bah, just completed `make world' after doing `make includes' and found that I can't login as *any* user, not only root!!! Login just hangs after entering password and nothing goes on. DES! PLEASE FIX THAT FSKING PAM - within a very short timeframe it's the second time I'm having problems due to it and this just isn't acceptable even for -current. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
On 7 Mar 2002, Michael D. Harnois wrote: On Thu, 7 Mar 2002 13:30:44 +0200 (EET), Maxim Sobolev [EMAIL PROTECTED] said: Maxim Hi, Looks like source upgrade path is broken due to PAM. My Maxim system is -CURRENT compiled on 19 February. Please fix. Could this have anything to do with the fact that, since I built world yesterday, I can't log in as root? I can't login as root either, I can only gain root access if I boot into single-user. The login process just eats up all cpu-ressources and the login times out after 300 seconds. A su doesn't work either, of course. Sincerely, Rasmus Skaarup To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Bah, just completed `make world' after doing `make includes' and found that I can't login as *any* user, not only root!!! Login just hangs after entering password and nothing goes on. DES! PLEASE FIX THAT FSKING PAM - within a very short timeframe it's the second time I'm having problems due to it and this just isn't acceptable even for -current. That is _my_ fault, not DES'. It was a crypt() problem which I have fixed. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
I can't login as root either, I can only gain root access if I boot into single-user. The login process just eats up all cpu-ressources and the login times out after 300 seconds. A su doesn't work either, of course. Not a PAM problem, a crypt(3) problem. My fault, and fixed. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cardbus problem
In message: [EMAIL PROTECTED] Yuri Khotyaintsev [EMAIL PROTECTED] writes: : Hi! : : I have xl0: watchdog timeout on my 3Com cardbus card after updating kernel : recently. Everything seems to be OK during boot, : but xl0: watchdog timeout starts directly after ifconfig, and makes network : incredibly slow. : boot -v will not boot at all, it stops somewhere around cardbus_attach_card. : : It seems the problem is in recent changes to sys/dev/cardbus, because : taking the August version of sys/dev/cardbus/* files resolved the problem. So using a completely -current kernel, except for the august version of sys/dev/cardbus/*? I wouldn't have expected that to compile, but that's a good data point if true. : xl0: 3Com 3c656B Fast Etherlink XL port 0x1000-0x107f mem : 0x84002000-0x8400207f,0x84002000-0x840020ff irq 11 at device 0.0 on cardbus1 : xl0: Ethernet address: 00:50:04:92:29:17 What does vmstat -i say about irq 11? Warner /me gets out his 656 cardbus card and gives it a whirl. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Date: Thu, 07 Mar 2002 17:43:26 +0200 From: Maxim Sobolev [EMAIL PROTECTED] Michael D. Harnois wrote: On Thu, 7 Mar 2002 13:30:44 +0200 (EET), Maxim Sobolev [EMAIL PROTECTED] said: Maxim Hi, Looks like source upgrade path is broken due to PAM. My Maxim system is -CURRENT compiled on 19 February. Please fix. Could this have anything to do with the fact that, since I built world yesterday, I can't log in as root? Bah, just completed `make world' after doing `make includes' and found that I can't login as *any* user, not only root!!! Login just hangs after entering password and nothing goes on OK; markm said it was a crypt() problem (that he caused fixed); I'm not going to belabor that. (I will, however, express appreciation for Mark taking the heat: thanks, Mark!) But on the point of folks being unable to login, I'm not seeing the failure here. First, an ssh session: bunrab(4.5-S)[3] _ssh freebeast Enter passphrase for RSA key '[EMAIL PROTECTED]': Last login: Thu Mar 7 08:06:22 2002 from bunrab.catwhiske Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT (FREEBEAST) #8: Thu Mar 7 06:49:17 PST 2002 Welcome to FreeBSD! ... You may also use sysinstall(8) to re-enter the installation and configuration utility. Edit /etc/motd to change this login announcement. freebeast(5.0-C)[1] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #8: Thu Mar 7 06:49:17 PST 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast(5.0-C)[2] Now, direct login from the (serial) console: Additional TCP options:. Starting background filesystem checks Thu Mar 7 08:08:23 PST 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: david Password: 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 (FREEBEAST) #8: Thu Mar 7 06:49:17 PST 2002 Welcome to FreeBSD! ... You may also use sysinstall(8) to re-enter the installation and configuration utility. Edit /etc/motd to change this login announcement. freebeast(5.0-C)[1] logout FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: root Password: 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 (FREEBEAST) #8: Thu Mar 7 06:49:17 PST 2002 Welcome to FreeBSD! ... You may also use sysinstall(8) to re-enter the installation and configuration utility. Edit /etc/motd to change this login announcement. freebeast# uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #8: Thu Mar 7 06:49:17 PST 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast# logout FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: As I mentioned, it works for me. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
OK; markm said it was a crypt() problem (that he caused fixed); I'm not going to belabor that. (I will, however, express appreciation for Mark taking the heat: thanks, Mark!) *blush* But on the point of folks being unable to login, I'm not seeing the failure here. You'll only see it if you have the bad version of crypt-md5.c(1.9) and you actually use md5 passwords (the salt begins with $1$ when you look in /etc/master.passwd). The breakage time was less than 24 hours. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Mark Murray wrote: Bah, just completed `make world' after doing `make includes' and found that I can't login as *any* user, not only root!!! Login just hangs after entering password and nothing goes on. DES! PLEASE FIX THAT FSKING PAM - within a very short timeframe it's the second time I'm having problems due to it and this just isn't acceptable even for -current. That is _my_ fault, not DES'. It was a crypt() problem which I have fixed. Ok, I see now. Could we please make a rule to send a heads-up in such cases (i.e. in the cases when some serious misbehaviour was introduced and then fixed shortly). This would save me (and probably others) roughly a hour that I spent debugging what's going wrong. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
That is _my_ fault, not DES'. It was a crypt() problem which I have fixed. Ok, I see now. Could we please make a rule to send a heads-up in such cases (i.e. in the cases when some serious misbehaviour was introduced and then fixed shortly). This would save me (and probably others) roughly a hour that I spent debugging what's going wrong. My apologies. I should have thought to do that. I'll remember if there is a next time ;-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Maxim Sobolev [EMAIL PROTECTED] writes: Looks like source upgrade path is broken due to PAM. My system is -CURRENT compiled on 19 February. Please fix. Please use 'make world' to upgrade your system. Its more broken than that. I have a fix. The problem is in the headers; you changed #include pam_mod_misc.h to #include secure/pam_mod_misc.h without ensuring that a (correct) pam_mod_misc.h was in an appropriate secure/ dir. I've just finished fixing this (includes a repo-copy) and it will go in shortly. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Maxim Sobolev [EMAIL PROTECTED] writes: Dag-Erling Smorgrav wrote: Maxim Sobolev [EMAIL PROTECTED] writes: Looks like source upgrade path is broken due to PAM. My system is -CURRENT compiled on 19 February. Please fix. Please use 'make world' to upgrade your system. I'm using `make world' (well buildworld, but it shouln't matter). The error message you're reporting indicates that libpam is being built with the wrong headers. This shouldn't happen during 'make world'. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Mark Murray [EMAIL PROTECTED] writes: The problem is in the headers; you changed #include pam_mod_misc.h to #include secure/pam_mod_misc.h without ensuring that a (correct) pam_mod_misc.h was in an appropriate secure/ dir. Umm, IIRC 'make world' starts by doing a 'make includes' into /usr/obj, which should take care of this. I've just finished fixing this (includes a repo-copy) and it will go in shortly. No repo-copy should be necessary. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Maxim Sobolev [EMAIL PROTECTED] writes: Bah, just completed `make world' after doing `make includes' and found that I can't login as *any* user, not only root!!! Login just hangs after entering password and nothing goes on. DES! PLEASE FIX THAT FSKING PAM - within a very short timeframe it's the second time I'm having problems due to it and this just isn't acceptable even for -current. Please moderate your language and your attitude. DES -- Dag-Erling Smorgrav - [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
Can someone please end this nightmare? If you've reviewed the patch and found substantive reason to contest it then speak now else the patch should be commited today so that forward progress can continue. I mean, cut the crap and state the facts you see about the code or sit in silence while those who do know the facts work them out. To bitch and moan because you assume it might interrupt someone elses work is as antiproductive as anything can be. From what I've seen I think Matt should be allowed to commit. Pete... 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
Trim your cc's. I'm sorry, but simply not liking the idea of someone else doing a particular optimization now verses later is not a good enough reason to require that 40+ hours worth of work be thrown away when that other person has stated, repeatedly, that he will support said code. Given that not optimising the code is consistent with the current SMPng approach, and given that you went and did this work unsolicited, the situation is unfortunate but inevitable. So far not one person, not even you, has been able to explain why the patch should not go in. It should not be committed because the current SMPng direction is establishment and implementation, not optimisation. Is that plain enough for you? You're doing the wrong work, as far as the general consensus goes. I am angry because you and a number of others are not willing to take the work at face value and instead insist on making ridiculous extremist assumption into it and then using that opinion to justify not allowing the patch to go in. You are angry because you've decided that you want to do something, and you don't want to be told you can't by someone else. Had you been reasonable about the situation, your code would probably have been committed and you could have spent the last week or more doing something else more interesting. Instead, you've tried to hold the Project to ransom for your ego. We don't tolerate this from anyone, no matter how skillful or useful they might otherwise be. This is a collaborative effort, and you need to collaborate on the group's terms, not your own. I don't see how you can possibly tell me that I am not being a team player when I am being told to throw the code away completely. If you were a team player, you would throw the code away. (Actually, I doubt that throwing the code away is the correct solution; my point here is simply that you've completely failed to understand what being part of a team is actually about.) I can't fight your opinion of me, but you can't expect me to listen to you if you can't justify it. You have already shown very clearly that you aren't even interested in looking at the code, that you don't care what it does, but you are against it anyway. That's because this is not about the code; it's about your behaviour. This is not about being part of a team. You don't have to be forced into using someone else's methodology to be part of a team. Being part of a team means respecting other people's metholodogies and it means compromising. I find this quite funny. You abuse John for not compromising, yet you're not willing to compromise on the issue that's really at hand here (and which has been highlighted repeatedly since the first day of dispute). You're asking for respect, but not returning it. This is about being part of a team, not having a fan club. This IS about team work, but you are barking up the wrong tree if you think I'm the one who's not being a team player here. Do we see you subordinating your personal goals to those of the team? Say what? Who said anything about me not wanting to discuss API changes? That's all I've been TRYING to do for the last three fucking weeks! No, you have been arguing to get your code committed, as-is, philosophically unchanged. Are you discussing API changes? No, you are basically just bashing me. That's all that you people have been doing for three fucking weeks. This is a consequence of your behaviour. Had you been more reasonable, you'd have had less bashing. Now who is being unreasonable? Why do you believe that it is absolutely necessary that I be prevented from committing the work? Because allowing you to commit it at this stage would represent giving in to your attempt to hold the Project to ransom. Had you moderated your tone and worked within the dictates of the situation, you'd probably have found a path that would have allowed your code to be committed with little effort. Unfortunately, you appear not to have learned from your previous mistakes, and (again) took an approach which deliberately antagonises your co-developers. You've successfully manufactured a situation from which it is almost impossible to proceed forward; any benefit to the Project that might be derived from your code has already been more than offset by time wasted in response to your behaviour, and actually giving your your head without seeing due process served is simply not consistent with our intention that development be managed by consensus. Despite your repeated attempts to transfer blame elsewhere, you are ultimately the root cause of your current dilemma, and likewise you are the only person that can resolve it. Such a resolution is going to require a change in approach from you; what you want is eminently achievable, you just have to work out that tricky
Re: Patch for critical_enter()/critical_exit() interrupt assem
On Thu, 7 Mar 2002, Michael Smith wrote: Trim your cc's. I'm sorry, but simply not liking the idea of someone else doing a particular optimization now verses later is not a good enough reason to require that 40+ hours worth of work be thrown away when that other person has stated, repeatedly, that he will support said code. Given that not optimising the code is consistent with the current SMPng approach, and given that you went and did this work unsolicited, the situation is unfortunate but inevitable. Geeze Mike I expect bettrer from you.. So far not one person, not even you, has been able to explain why the patch should not go in. It should not be committed because the current SMPng direction is establishment and implementation, not optimisation. The code actually fixes bugs too. Improvement in performance is a bonus. Is that plain enough for you? You're doing the wrong work, as far as the general consensus goes. No, If he had asked you first (and john didn't exist) whould you have honestly said I think that you should be forbidden from looking at fixing that code. I am angry because you and a number of others are not willing to take the work at face value and instead insist on making ridiculous extremist assumption into it and then using that opinion to justify not allowing the patch to go in. You are angry because you've decided that you want to do something, and you don't want to be told you can't by someone else. This is a volunteer process.. Who is to say that anyone is forbidden from fixing certain problems, especially when the problems are not in any particular person's Baliwick. These changes are no more in JHB's area than they are in BDE's. If BDE had committed them there would not have been a peep out of anyone. (And that's a certainty). Had you been reasonable about the situation, your code would probably have been committed and you could have spent the last week or more doing something else more interesting. Instead, you've tried to hold the Project to ransom for your ego. We don't tolerate this from anyone, no matter how skillful or useful they might otherwise be. Don't be melodramatic. There was whole week of silence on this topic when NOT ONE SINGLE PERSON bothered to review the patch. It's interesting that the loudest people against this patch have not read it. This is a collaborative effort, and you need to collaborate on the group's terms, not your own. In a collaborative effort someone would have reviewed the code by now. I can't fight your opinion of me, but you can't expect me to listen to you if you can't justify it. You have already shown very clearly that you aren't even interested in looking at the code, that you don't care what it does, but you are against it anyway. That's because this is not about the code; it's about your behaviour. The behaviour was ok until he got picked on. The patch was backed out within hours of the request and he's been waiting for a technical review ever since. I find this quite funny. You abuse John for not compromising, yet you're not willing to compromise on the issue that's really at hand here (and which has been highlighted repeatedly since the first day of dispute). Matt has put his code up for view and stated that he's willing to discuss it with anyone. John has hidden his code in 1MB of patches and refused to comment on Matt's patch other than to say that he wouldn't have done it. This is a consequence of your behaviour. Had you been more reasonable, you'd have had less bashing. May you be on the receiving end sometime. The initial objections were because some one SUSPECTED that jhb had code in that area. After the patch was backed out, not a single person has bothered to review it. Core simply washed it's hands of the deal. After that I'll tell you that I just about recommended to my company that we switch to Linux. It was so sickenning. Because allowing you to commit it at this stage would represent giving in to your attempt to hold the Project to ransom. No core's refusal to allow a commit shows a childish attempt to show who's boss, and to ensure that an uppity developer gets what's comming to him. Ther was a whole week of silence on the topic when Matt waited for comment, review and critisism. The only critisism he got was in the form of abuse. Had you moderated your tone and worked within the dictates of the situation, you'd probably have found a path that would have allowed your code to be committed with little effort. that obviously doesn't work.. see above. Unfortunately, you appear not to have learned from your previous mistakes, and (again) took an approach which deliberately antagonises your co-developers. You've successfully manufactured a situation from which it is almost impossible to proceed forward; any benefit to
Re: Patch for critical_enter()/critical_exit() interrupt assem
If memory serves me right, Bruce A. Mah wrote: [snip] Disregard. I hit the wrong button in my MUA. Sorry for the spammage. Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Dag-Erling Smorgrav wrote:
Maxim Sobolev [EMAIL PROTECTED] writes:
Dag-Erling Smorgrav wrote:
Maxim Sobolev [EMAIL PROTECTED] writes:
Looks like source upgrade path is broken due to PAM. My system is -CURRENT
compiled on 19 February. Please fix.
Please use 'make world' to upgrade your system.
I'm using `make world' (well buildworld, but it shouln't matter).
The error message you're reporting indicates that libpam is being
built with the wrong headers. This shouldn't happen during 'make
world'.
Shit Happens[tm]. BTW, why you are ignoring system CFLAGS settings
(optimisations and such) for pam_unix? Please consider attached patch.
-Maxim
--- lib/libpam/modules/pam_unix/Makefile2002/03/07 16:40:34 1.1
+++ lib/libpam/modules/pam_unix/Makefile2002/03/07 16:40:45
@@ -27,7 +27,7 @@
LIB= pam_unix
SHLIB_NAME=${LIB}.so.${SHLIB_MAJOR}
SRCS= pam_unix.c pw_copy.c pw_yp.c pw_util.c ypxfr_misc.c ${GENSRCS}
-CFLAGS=-DYP -Dyp_error=warnx \
+CFLAGS+= -DYP -Dyp_error=warnx \
-I${.OBJDIR} \
-I${.CURDIR}/../../../../libexec/ypxfr \
-I${.CURDIR}/../../../../usr.sbin/vipw \
Re: 5-CURRENT source upgrade path is broken in PAM
Maxim Sobolev [EMAIL PROTECTED] writes: Shit Happens[tm]. BTW, why you are ignoring system CFLAGS settings (optimisations and such) for pam_unix? Please consider attached patch. *I* am not. Learn how to use 'cvs annotate' DES -- Dag-Erling Smorgrav - [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
: those reviews object on a purely subjective manner. : : : I think this is premature : : I don't consider that to be a technical review? do you? If that's what he said, no. However, that's not all that he said. Also, Jake had several objections from a sparc64 perspective that weren't answered by dillon. My memory is different than yours. But all this he said she said stuff isn't getting us anywhere. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
At 5:43 PM +0200 3/7/02, Maxim Sobolev wrote: Michael D. Harnois wrote: Could this have anything to do with the fact that, since I built world yesterday, I can't log in as root? Bah, just completed `make world' after doing `make includes' and found that I can't login as *any* user, not only root!!! Login just hangs after entering password and nothing goes on. For anyone who is stuck with this problem, note that the problem happens when doing a normal password check. So, you *may* be able to work around this if you have something like authorized keys set up in openssh. Or maybe you can log in as one userid, but not some userid like root (that was my problem -- every userid worked fine except for root). If you're lucky enough to set up 'sudo' for a userid you *can* log into, you may be able to use that to become root. -- 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: 5-CURRENT source upgrade path is broken in PAM
Mark Murray [EMAIL PROTECTED] writes: The problem is in the headers; you changed #include pam_mod_misc.h to #include secure/pam_mod_misc.h without ensuring that a (correct) pam_mod_misc.h was in an appropriate secure/ dir. Umm, IIRC 'make world' starts by doing a 'make includes' into /usr/obj, which should take care of this. That is 'make world'. It was broken for make obj make depend make, and pam_krb5 was just plain broken (../Makefile.inc had a broken path). I've just finished fixing this (includes a repo-copy) and it will go in shortly. No repo-copy should be necessary. IMO, the repo-copy is the cleanest, because it solves te above problems in the most canonical way. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Dag-Erling Smorgrav wrote: Maxim Sobolev [EMAIL PROTECTED] writes: Bah, just completed `make world' after doing `make includes' and found that I can't login as *any* user, not only root!!! Login just hangs after entering password and nothing goes on. DES! PLEASE FIX THAT FSKING PAM - within a very short timeframe it's the second time I'm having problems due to it and this just isn't acceptable even for -current. Please moderate your language and your attitude. Sorry, I've overreacted - unlikely combination of unfortunate events, ya know. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Mark Murray [EMAIL PROTECTED] writes: Umm, IIRC 'make world' starts by doing a 'make includes' into /usr/obj, which should take care of this. That is 'make world'. It was broken for make obj make depend make, [...] IMO, the repo-copy is the cleanest, because it solves te above problems in the most canonical way. Please talk to Ruslan about this. I suggested doing just what you're thinking of about a month or two ago, and he rejected it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Call for UMA (allocator) testers.
I have an updated copy of my kernel memory allocator available for general testing. If you aren't familiar with this allocator you may want to look at the arch@ archives under Slab allocator. This patch has been tested on SMP alpha and single proc x86. It depends on recent current changes, so fresh sources are expected. This patch is missing the necessary vmstat changes, so you will want to use 'sysctl vm.zone' to view your memory usage. I'd like people to test with WITNESS and INVARIANTS, although with these options on it is somewhat slower than the original kernel. With these disabled it is on par. If you have a SMP machine you will get witness warnings if you run low on memory. There is no real problem except that witness doesn't understand that the condition is safe. If you do test this patch, please send me an email so I know how many people are using this. If you get a lock order violation other than acquring duplicate lock of same type please let me know. If you get a panic, please give me a stack trace (tr in ddb) and the output of call uma_print_stats in the debugger if that is possible. This has been debugged and tested over several months so it is quite stable for me. Hopefully it will be stable for you too. :-) The patch and new files are available at: http://www.chesapeake.net/~jroberson/uma.tar Untar into src/sys and apply the patch. After you rerun config you should be ready to compile. Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-CURRENT source upgrade path is broken in PAM
Mark Murray [EMAIL PROTECTED] writes: Umm, IIRC 'make world' starts by doing a 'make includes' into /usr/obj, which should take care of this. That is 'make world'. It was broken for make obj make depend make, [...] IMO, the repo-copy is the cleanest, because it solves te above problems in the most canonical way. Please talk to Ruslan about this. I suggested doing just what you're thinking of about a month or two ago, and he rejected it. Ruslan is not writing this code; we are. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn 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 API is intended for the stage-2 commit. The stage-1 commit :is intended to do all the 'hard stuff' in as straightforward :a manner as possible. The sysctl / option you talk about here :existed in my patch set 2 and a half weeks ago. : :The API and getting it right is more important than the hard stuff. :Its not as fun, but the API will outlive the code (consider the next :arch, and the next). It may take more of your time due to discussion :and feedback to get the API in place, but that's part of the cost of :collaboration. :... :I really wish you people would at least read the patch and commit :message before you comment on it. : :I didn't have to read the patch to know that there were concerns and :on-going discussion about the API. In this instance, the issues are :not large and can be remedied quickly - all the more reason for the :discussion to take place before the commit. Again, bullshit. You should have read the patch. How can you possibly justify a lecture on what I should and should not be doing when you don't even read to bother the material under discussion? :I didn't have to read the patch to know that you didn't seem to care :about getting the API right before commiting the code. The API Again, complete and utter bullshit. You actually believe that because I want to commit this stuff in multiple stages and decided that the API change would be in stage 2, that this somehow magically means that I don't seem to care? How the hell did you come to that conclusion? Did you even bother to read the commit message? I'll tell you why I want to commit the stuff in multple stages... BECAUSE THAT ALLOWS THE CORE OF THE CODE TO BE TESTED WHILE THE REMAINING STUFF CAN BE DISCUSSED AND/OR WORKED ON. That's why. I am not going to spend months integrating change after change into a patchset, having to retest the whole mess every time, and then only after months commit the final result. That is not how I work and I strongly oppose that kind of methodology. I prefer to work in smaller chunks and yet here you are trying to justify your nonsense by making further attacks on my methodologies and code that are completely absurd and completely unsupported by any evidence whatsoever. This is complete and utter nonsense. You seem to believe you know a lot about my motives without reading one goddamn line of code. Because you know what? The commit message laid this all out in very clear terms. :I didn't have to read the patch to know that you would only remove your :commit if someone could point to specific defects in the hard part of :your submission. The hard part, how it works, and whether it contained :any bugs or not was not the real issue. This is why you and John were :talking right past each other. Excuse me, but I think whether something contains bugs or not is a more serious issue then which source file the code winds up being in. And, again, you seem to be making ridiculous assumptions that are simply not true. Change the API? I am doing no such thing. I am expanding one portion of the existing API. The procedural interface has not changed. The procedure names have not changed. The location of the procedures change, and the capabilities of the procedures have changed, and certain restrictive assumptions regarding hard interrupt disablement have been changed. But you, and others, do not appear to be willing to face up to the code or its straightforward intent. Intead you are reading all sorts of garbage into its meaning, WITHOUT EVEN BOTHERING TO READ IT. It is unbelievable to me that a professional such as yourself would stoop to such tactics without backing it up with one shred of evidence and not even having bothered to read the code in question. And instead of standing up and apologizing for that, you instead feel that you have to start making wild accusations without one single hard reference to ANYTHING I have done. :.. :you can colloborate and coordinate with others in this project. The only :issue is how that colloboration takes place, and the *process* for getting :things done. If the process makes it twice as hard for us to get things :done, then it's broken. In that case, *attack the process*, not the person. :The process can and will change but only if we set aside personal :indignity (why should I have to put up with this crap!?!?) and attack :our problems and goals as engineers. Hey, I'm the one being attacked here. This whole mess started with people attacking me. If people had let well enough alone.. if people had simply read the goddamn patch rather then attack its intent (if you even know what it's intent is since so far you are batting 0 on that front), then we would not be in this situation. Instead it's attacked because
grp.h fix is incomplete
grp.h fix is incomplete because 'u_int32_t' is not defined (but must be)
for standalone grp.h. Please add some includes for u_int32_t definition
too, probably sys/types.h
To see it, try to compile following program:
#include grp.h
main ()
{}
and get:
/usr/include/grp.h:53: syntax error before `gid_t'
/usr/include/grp.h:53: warning: data definition has no type or storage
class
/usr/include/grp.h:59: syntax error before `gid_t'
/usr/include/grp.h:64: warning: parameter names (without types) in
function declaration
/usr/include/grp.h:72: syntax error before `int'
--
Andrey A. Chernov
http://ache.pp.ru/
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
Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500, Robert Watson said words to the effect of; On Thu, 7 Mar 2002, Warner Losh wrote: In message [EMAIL PROTECTED] Julian Elischer writes: : : : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: : : Then do the right things so it will. : : Unfortunatly that has been proven to not work. : : after reverting the change and silently waiting for a week : 1/ no person bothered to review it. : 2/ people assumed the patch had gone away. Ummm, There are reviews in the archives that object to the API as it relates to optimization and those objections haven't been sanely answered with anything more constructive than BS. The primary objections I've seen from Jake, and he posted them as part of the earlier thread prior to the commit, was that the API changes proposed by Matt don't make sense for the sparc64 implementation, uni-processor or multi-processor, and that while these changes might be appropriate for i386, he wanted to see the APIs set up in such a way that the differences in architectures were hidden in the MD code. This suggests working some more on the API before moving on, and my reading of earlier posts in the thread from John was that that was what he had in mind also. Yes. What I would like and what I mentioned before is for this to be hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter would be a null macro for i386, which would turn critical_enter into just an increment, as Matt wanted. cpu_critical_exit would do all the magic of unpending interrupts. The reason for this is that I would like to see critical_exit handled any pending preemptions for a thread. We do not yet know exactly how this will work so I would like this to be done in MI code to start with. The code must not make assumptions that are not valid on all platforms. This is easiest if they use the same code. This is not about duplication of code in several MD files. Bruce also had some comments which were shrugged off, I thought they were important. Specifically, please do not make unnecessary changes to the assembler code. Macros do not need to be defined before they are used, I believe this was the justification for some of the reordering in apic_vector.s which makes the patch confusing. Please do not tab out the ; \ at the end of the lines in the INTR and FAST_INTR macros in icu_vector.s. This just makes unnecessary diffs. The PUSH_DUMMY macro must push a reasonable eip value, in addition to the code segment, so that profiling and stack traces work right. If you have not already, please make sure that a trace from inside an interrupt handler that was unpended looks somewhat normal. Please also make sure that kgdb is able to decode the frame properly. It assumes that the eip of the frame will be near certain kernel symbols in order to determine what kind of frame it is. Jake 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
:I didn't have to read the patch to know that there were concerns and :on-going discussion about the API. In this instance, the issues are :not large and can be remedied quickly - all the more reason for the :discussion to take place before the commit. Again, bullshit. You should have read the patch. How can you possibly justify a lecture on what I should and should not be doing when you don't even read to bother the material under discussion? Because it isn't relavent. Until you see that, you will continue to be frustrated. You will continue to get angry. You will continue to butt heads. You will continue to act unprofessionally on our lists. You will continue to piss people off. And most importantly, you will continue to lose the battles that you care about. Is your code in the tree right now? No. That above all else shows that your tactics are the wrong ones. :I didn't have to read the patch to know that you didn't seem to care :about getting the API right before commiting the code. The API Again, complete and utter bullshit. You actually believe that because I want to commit this stuff in multiple stages and decided that the API change would be in stage 2, that this somehow magically means that I don't seem to care? How the hell did you come to that conclusion? Did you even bother to read the commit message? You came to the conclusion that only *your decision* on what was an appropriate proceedure was the one that mattered. That's not the way this project works. You can't act unilaterally. When people ask you to hold off (and they even asked politely!) so discussion can take place, that is not the time to commit. I'll tell you why I want to commit the stuff in multple stages... BECAUSE THAT ALLOWS THE CORE OF THE CODE TO BE TESTED WHILE THE REMAINING STUFF CAN BE DISCUSSED AND/OR WORKED ON. That's why. One week of discussion will not prevent the code from being tested. I am not going to spend months integrating change after change into a patchset, having to retest the whole mess every time, and then only after months commit the final result. I've counted weeks so far and those weeks weren't even necessary. Now your expecting months and years of delay? Please. The only way it will get delayed that long is if you spend all of your time stomping up and down, writing in all caps, and tell the rest of us that we have to follow the proceedures you think are appropriate. That's not how colaboration works. You need to compromise and not get all pissed off if the process requires you to delay your commit for a bit. That is not how I work and I strongly oppose that kind of methodology. I think you've made that clear already. The question is whether you are willing to compromise so you can be part of a team or not. That means, for all of us, that we will not necessarily be able to work in the way we would personally want, all of the time. That's what happens in a group environment. That's life. I prefer to work in smaller chunks and yet here you are trying to justify your nonsense by making further attacks on my methodologies and code that are completely absurd and completely unsupported by any evidence whatsoever. This is not an attack on any such thing. This is about *process*. You want to commit in small chucks? Great! You want to get this stuff into the tree quickly? Great! You want to make the code so it can be dynamically configured for testability? Great! You don't want to discuss API changes that have affects on other ports, and other subsystems prior to committing them? That's unacceptable when people are asking you to explain them first, regardless of how well thought out or implemented they are. This is not a race to commit. This is about developing a well designed system without killing each other in the process. This is complete and utter nonsense. You seem to believe you know a lot about my motives without reading one goddamn line of code. Because you know what? The commit message laid this all out in very clear terms. For this kind of change, the commit message should have been the last, not the first public forum to have expressed these ideas. :I didn't have to read the patch to know that you would only remove your :commit if someone could point to specific defects in the hard part of :your submission. The hard part, how it works, and whether it contained :any bugs or not was not the real issue. This is why you and John were :talking right past each other. Excuse me, but I think whether something contains bugs or not is a more serious issue then which source file the code winds up being in. Did I say anything about source files? This is about discussion prior to commit. Nothing more. And, again, you seem to be making ridiculous assumptions that are simply not true. Change the API? I am doing no such thing. I am
Re: Patch for critical_enter()/critical_exit() interrupt assem
: :You came to the conclusion that only *your decision* on what was :an appropriate proceedure was the one that mattered. That's not :the way this project works. You can't act unilaterally. When people :ask you to hold off (and they even asked politely!) so discussion :can take place, that is not the time to commit. I did no such thing. I came to the conclusion because not a single goddamn person bothered to read the patch and instead the only argument I got was wait for John and John's only argument is I don't like the idea of optimizing this routine right now as if he would be the only one responsible for dealing with the consequences. I'm sorry, but simply not liking the idea of someone else doing a particular optimization now verses later is not a good enough reason to require that 40+ hours worth of work be thrown away when that other person has stated, repeatedly, that he will support said code. So far not one person, not even you, has been able to explain why the patch should not go in. John's only excuse is that he doesn't like the idea of optimizing it now. John has stated on several occassions that he believes I am breaking future work (like preemption). I have responded every time by asking him to clarify exactly what he thought would be broken. He has consistently refused to clarify his statement. I have read his tiny little 10-page SMP document and there is absolutely nothing in that document which is at odds with my patch. Not one thing. I am angry because you and a number of others are not willing to take the work at face value and instead insist on making ridiculous extremist assumption into it and then using that opinion to justify not allowing the patch to go in. I have said, REPEATEDLY, but you can't seem to understand, that I am totally open to making adjustments to the code. I am not willing to throw it away, but I am willing to make adjustments to the code. I don't see why the patch should be held up. But you know something? You and others don't seem to be interested in having a conversation about possible improvements. You seem to be out for blood, to prevent the patch from going in at all costs no matter how good it is, without even having bothered to read or understand it, and that makes me unbelievably angry, I don't see how you can possibly tell me that I am not being a team player when I am being told to throw the code away completely. I think it's John who is not being the team player here, and others, who seem to believe that me throwing the code away is the correct solution to their ills. :I'll tell you why I want to commit the stuff in multple stages... :BECAUSE THAT ALLOWS THE CORE OF THE CODE TO BE TESTED WHILE THE :REMAINING STUFF CAN BE DISCUSSED AND/OR WORKED ON. That's why. : :One week of discussion will not prevent the code from being tested. Coming on THREE weeks now. Three weeks of my time wasted arguing with people who don't even bother to take the time to understand what I am trying to accomplish, who seem to regard a relatively straightforward patch as somehow being an attack on John's leadership when that could not be farther from the truth, who seem inclined to do nothing but bash me personally and supply opinions without one shred of evidence to back them up. I can't fight your opinion of me, but you can't expect me to listen to you if you can't justify it. You have already shown very clearly that you aren't even interested in looking at the code, that you don't care what it does, but you are against it anyway. You response is to ignore the points I have brought up and then start bashing me personally. :I am not going to spend months integrating change after change into :a patchset, having to retest the whole mess every time, and then only :after months commit the final result. : :I've counted weeks so far and those weeks weren't even necessary. Now :your expecting months and years of delay? Please. Gee, lets see... why don't YOU ask JOHN how long he intends to wait before he allows this sort of optimization to be made? Eh? Please. : :That is not how I work and I strongly oppose that kind of methodology. : :I think you've made that clear already. The question is whether you :are willing to compromise so you can be part of a team or not. That :means, for all of us, that we will not necessarily be able to work in :the way we would personally want, all of the time. That's what happens :in a group environment. That's life. This is not about being part of a team. You don't have to be forced into using someone else's methodology to be part of a team. Being part of a team means respecting other people's metholodogies and it means compromising. There has been no
Re: Patch for critical_enter()/critical_exit() interrupt assem
On Thu, 7 Mar 2002, Justin T. Gibbs wrote: The only way it will get delayed that long is if you spend all of your time stomping up and down, writing in all caps, and tell the rest of us that we have to follow the proceedures you think are appropriate. That's not how colaboration works. You need to compromise and not get all pissed off if the process requires you to delay your commit for a bit. Justin, the stuff was backed out when requested, and has been so for quite a while now. NOT ONE SINGLE of the dog-in-the-manger people has bothered to review it in that week. How long is he expected to wait? John has only said that somehow it aesthetically offends his sensibilities in some way. He has certainly not given any techincal reason to not do it, (that I have seen). How long is a person supposed to wait when no-one can give a reason that it should not be committed and there are reasons that it should? I prefer to work in smaller chunks and yet here you are trying to justify your nonsense by making further attacks on my methodologies and code that are completely absurd and completely unsupported by any evidence whatsoever. This is not an attack on any such thing. This is about *process*. You want to commit in small chucks? Great! You want to get this stuff into the tree quickly? Great! You want to make the code so it can be dynamically configured for testability? Great! You don't want to discuss API changes that have affects on other ports, and other subsystems prior to committing them? That's unacceptable when people are asking you to explain them first, regardless of how well thought out or implemented they are. This is not a race to commit. This is about developing a well designed system without killing each other in the process. Talk about puting words into another person's mouth! NOT ONE SINGLE PERSON has asked to discuss this work! Matt has already said that he would GLADLY discuss it with anyone who's interested to do so. So far tehre ahve been no takers. For this kind of change, the commit message should have been the last, not the first public forum to have expressed these ideas. It was being discusse on mailing lists as well as privatly before teh commit. Did I say anything about source files? This is about discussion prior to commit. Nothing more. How is expanding an API not a change to that API? Why is it that when other developers express a need to discuss these changes prior to them being committed, their concerns don't matter to you? Are you the only person in the project that can't keep changes in your local tree for a few days while you present your ideas? I have done no such thing. The facts are very simple: Looks very much like it from this direction. Matt: I'm going to commit this code to the tree Others: We should discuss the rammifications first. Matt: We can discuss it after its in. Others: No, we need to discuss it first. Matt: Commit Others: Back it out until we discuss it. Matt: !@#$%^$@#. Every time I try to do something its blocked Matt: Backs out: Ok so what do you want to discuss? Others: .. Oh, nothing really, we just felt like stuffing you around again. That's not how I perceived this at all. John needs to be active in the discussion on changes so they are resolved quickly and don't hold you back. I have not said one thing about your changes not going in other than to say that they should be discussed first. If John doesn't want to have to merge with you, he'll have to get his patches into the tree just like anyone else. No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. Regardless, you have to be willing to discuss and perhaps refine your changes prior to committing them. This is true for anyone on the project, not just you. He's been sitting around for a week waiting for a single person to want to discuss it. I challenge you to find a single person who has asked to discuss the design. (and actually done it). It is only a huge deal because it was made into a huge deal. If the change had been discussed prior to being pushed into the tree, this would never have happened. I don't think that John, or anyone else, is opposed to the change going in once some small issues are discussed first. Just get over this I've been abused bit already and discuss the changes! We all want to move on and I'd rather see us moving on with your changes than without. No it's only a huge deal because OTHERS made it a huge deal. -- Justin 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
No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead appointment. We specifically indicate that the tech lead is obligated to provide justification for any decisions that he may make. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. 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 Thu, 7 Mar 2002, David Greenman wrote: No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead appointment. We specifically indicate that the tech lead is obligated to provide justification for any decisions that he may make. So, where is it? -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. 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
: :You came to the conclusion that only *your decision* on what was :an appropriate proceedure was the one that mattered. That's not :the way this project works. You can't act unilaterally. When people :ask you to hold off (and they even asked politely!) so discussion :can take place, that is not the time to commit. I did no such thing. Let me quote you from below: So, you see, I didn't just commit it out of nowhere. I waited what I believed to be a reasonable period of time. So your oppinion on what was a reasonable period of time was the only one that mattered. Q.E.D. I came to the conclusion because not a single goddamn person bothered to read the patch and instead the only argument I got was wait for John and John's only argument is I don't like the idea of optimizing this routine right now as if he would be the only one responsible for dealing with the consequences. Actually, John's reaction to the patch is a secondary issue. He wasn't even able to read the lists when this thing blew up. He could have fallen over backward with love for your changes and you still would have strewn cuss words all over our lists. [More talk about the irrelevant contents of the patch and 40 hours of work being thrown away paranoia.] I am angry because you and a number of others are not willing to take the work at face value and instead insist on making ridiculous extremist assumption into it and then using that opinion to justify not allowing the patch to go in. How many times do I have to say this? The patch is not the issue. Most likely it will be incorperated into the tree shortly. Yawn I'm sorry Matt, but even if these changes are gold lined, it doesn't change the fact that you acted unilaterally in a manner that is not conducive to team work. That it. That's really it. Now do you want me to go chew out John too. Okay. John isn't being super professional either. The fact that you started this doesn't change that. You both have done things that you shouldn't have. Now instead of trying to convince us that you are completely without reproach, why not move forward in some constructive manner? Aren't you out of breath yet? Aren't your fingers tired of typing the same old worn out argument, My code excuses my behavior! again and again? :One week of discussion will not prevent the code from being tested. Coming on THREE weeks now. Three weeks of my time wasted arguing with people who don't even bother to take the time to understand what I am trying to accomplish... This is your choice Matt. You may not realize it, but you are in control of how long this wears on. Gee, lets see... why don't YOU ask JOHN how long he intends to wait before he allows this sort of optimization to be made? Eh? Please. Hey John. Can you comment on whatever issues you have with the content of these changes? If the API is not compatible with what you are doing, please explain why and how those conflicts might be resolved. Assuming that these issues can be addressed and the optimization can be disabled via a configuration option, what further reasons are there to not allow this change to go into the tree? :That is not how I work and I strongly oppose that kind of methodology. : :I think you've made that clear already. The question is whether you :are willing to compromise so you can be part of a team or not. That :means, for all of us, that we will not necessarily be able to work in :the way we would personally want, all of the time. That's what happens :in a group environment. That's life. This is not about being part of a team. I've played hide and seek with people that feel this way. 1, 2, 3 Seems like a reasonable amount of time to me... Ha Ha found you! You don't have to be forced into using someone else's methodology to be part of a team. No, you have to accept the team's methodology in areas that affect the team. As we say in the States, your personal liberties end where they infrindge on mine. This is no different. The CVS repository is not yours to commit to any way you like. The team has a methodology for that and as soon as that methodology is broken, we fall into situations just like this one. This IS about team work, but you are barking up the wrong tree if you think I'm the one who's not being a team player here. I know you believe this. Just as you believed you were reasonable in committing that code when you were asked not to. Just as you continue to insist that the content of your patch is the issue here. I can't convince you otherwise, but perhaps I can convince you to drop your self righteousness for a bit so we can move on? I HAVE NEVER SAID THAT THE CODE COULD NOT BE CHANGED. Hello? Are you even listening to what I am saying? Actually? No. This isn't about the code, so your comments about it have absolutely no sway with me. You should save your breath for
Re: Patch for critical_enter()/critical_exit() interrupt assem
On Thu, 7 Mar 2002, Justin T. Gibbs wrote: The only way it will get delayed that long is if you spend all of your time stomping up and down, writing in all caps, and tell the rest of us that we have to follow the proceedures you think are appropriate. That's not how colaboration works. You need to compromise and not get all pissed off if the process requires you to delay your commit for a bit. Justin, the stuff was backed out when requested, and has been so for quite a while now. Sure. That doesn't excuse the fact that it was committed in the first place. NOT ONE SINGLE of the dog-in-the-manger people has bothered to review it in that week. How long is he expected to wait? So, after screaming obsenities at John and creating a big stink on our lists, you want to know why those in the know haven't felt like engaging Matt? I'm not saying that is an excuse, just a possible reason. I've already asked John to move this stuff along in my other mail, so don't try to pin me up as an obstructionist. He's been sitting around for a week waiting for a single person to want to discuss it. Hey, if Matt wants to believe that he can only be productive once his changes are committed, that is his problem. It is only a huge deal because it was made into a huge deal. If the change had been discussed prior to being pushed into the tree, this would never have happened. I don't think that John, or anyone else, is opposed to the change going in once some small issues are discussed first. Just get over this I've been abused bit already and discuss the changes! We all want to move on and I'd rather see us moving on with your changes than without. No it's only a huge deal because OTHERS made it a huge deal. So we're supposed to ignore it when Matt breaks the rules just because he is such a good hacker? Been there. Tried that. Now where here again. -- Justin 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
If memory serves me right, Justin T. Gibbs wrote: : :You came to the conclusion that only *your decision* on what was :an appropriate proceedure was the one that mattered. That's not :the way this project works. You can't act unilaterally. When people :ask you to hold off (and they even asked politely!) so discussion :can take place, that is not the time to commit. I did no such thing. Let me quote you from below: So, you see, I didn't just commit it out of nowhere. I waited what I believed to be a reasonable period of time. So your oppinion on what was a reasonable period of time was the only one that mattered. Q.E.D. I came to the conclusion because not a single goddamn person bothered to read the patch and instead the only argument I got was wait for John and John's only argument is I don't like the idea of optimizing this routine right now as if he would be the only one responsible for dealing with the consequences. Actually, John's reaction to the patch is a secondary issue. He wasn't even able to read the lists when this thing blew up. He could have fallen over backward with love for your changes and you still would have strewn cuss words all over our lists. [More talk about the irrelevant contents of the patch and 40 hours of work being thrown away paranoia.] I am angry because you and a number of others are not willing to take the work at face value and instead insist on making ridiculous extremist assumption into it and then using that opinion to justify not allowing the patch to go in. How many times do I have to say this? The patch is not the issue. Most likely it will be incorperated into the tree shortly. Yawn I'm sorry Matt, but even if these changes are gold lined, it doesn't change the fact that you acted unilaterally in a manner that is not conducive to team work. That it. That's really it. Now do you want me to go chew out John too. Okay. John isn't being super professional either. The fact that you started this doesn't change that. You both have done things that you shouldn't have. Now instead of trying to convince us that you are completely without reproach, why not move forward in some constructive manner? Aren't you out of breath yet? Aren't your fingers tired of typing the same old worn out argument, My code excuses my behavior! again and again? :One week of discussion will not prevent the code from being tested. Coming on THREE weeks now. Three weeks of my time wasted arguing with people who don't even bother to take the time to understand what I am trying to accomplish... This is your choice Matt. You may not realize it, but you are in control of how long this wears on. Gee, lets see... why don't YOU ask JOHN how long he intends to wait before he allows this sort of optimization to be made? Eh? Please. Hey John. Can you comment on whatever issues you have with the content of these changes? If the API is not compatible with what you are doing, please explain why and how those conflicts might be resolved. Assuming that these issues can be addressed and the optimization can be disabled via a configuration option, what further reasons are there to not allow this change to go into the tree? :That is not how I work and I strongly oppose that kind of methodology. : :I think you've made that clear already. The question is whether you :are willing to compromise so you can be part of a team or not. That :means, for all of us, that we will not necessarily be able to work in :the way we would personally want, all of the time. That's what happens :in a group environment. That's life. This is not about being part of a team. I've played hide and seek with people that feel this way. 1, 2, 3 Seems like a reasonable amount of time to me... Ha Ha found you! You don't have to be forced into using someone else's methodology to be part of a team. No, you have to accept the team's methodology in areas that affect the team. As we say in the States, your personal liberties end where they infrindge on mine. This is no different. The CVS repository is not yours to commit to any way you like. The team has a methodology for that and as soon as that methodology is broken, we fall into situations just like this one. This IS about team work, but you are barking up the wrong tree if you think I'm the one who's not being a team player here. I know you believe this. Just as you believed you were reasonable in committing that code when you were asked not to. Just as you continue to insist that the content of your patch is the issue here. I can't convince you otherwise, but perhaps I can convince you to drop your self righteousness for a bit so we can move on? I HAVE NEVER SAID THAT THE CODE COULD NOT BE CHANGED. Hello? Are you even listening
Re: Patch for critical_enter()/critical_exit() interrupt assem
:Yes. What I would like and what I mentioned before is for this to be :hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter :would be a null macro for i386, which would turn critical_enter into :just an increment, as Matt wanted. cpu_critical_exit would do all the :magic of unpending interrupts. The reason for this is that I would :like to see critical_exit handled any pending preemptions for a thread. :We do not yet know exactly how this will work so I would like this to be :done in MI code to start with. The code must not make assumptions that are :not valid on all platforms. This is easiest if they use the same code. :This is not about duplication of code in several MD files. We can't, because the MI code makes some rather blatent assumptions in regards to cpu_critical_enter and exit. Take the witness code, for example. So we cannot safely null-out those macros. In fact, the MI code also makes some rather blatent assumptions in regards to critical_enter() and exit which I have also had to clean up (and which will need considerably more cleanup). These assumptions include, just as an example: The witness code calling cpu_critical_enter()/exit without holding td_critnest count, and Peter's now withdrawn code which explicitly released the cpu critical section while holding a non-zero td_critnest count. In otherwords, really aweful hacks. So we can't just NULL out those inlines. Trying to keep critical_enter()/critical_exit() MI and cpu_critical_enter()/cpu_critical_exit() MD and separated doesn't make much sense to me, because frankly critical_enter() and critical_exit() are tiny little routines (and will remain tiny even after SWI and preemption is added) and I can't think of any reason to force higher complexity in the routines due to the separation. In short, critical_enter()/critical_exit() are TIGHTLY INTEGRATED with cpu_critical_enter/exit despite your attempt to make critical_enter/exit MI. What my patch does is accept as true the fact that the two sets of routines are, in fact, tightly integrated, and then implements them in a more sensible way (or, more to the point, allows each architecture to implement them in the proper manner as befits the architecture). The API's are still MI, but the implementation is MD. :Bruce also had some comments which were shrugged off, I thought they :were important. Specifically, please do not make unnecessary changes :to the assembler code. Macros do not need to be defined before they :are used, I believe this was the justification for some of the reordering :in apic_vector.s which makes the patch confusing. Please do not tab :out the ; \ at the end of the lines in the INTR and FAST_INTR macros :in icu_vector.s. This just makes unnecessary diffs. The PUSH_DUMMY :macro must push a reasonable eip value, in addition to the code segment, :so that profiling and stack traces work right. If you have not already, :please make sure that a trace from inside an interrupt handler that was :unpended looks somewhat normal. Please also make sure that kgdb is able :to decode the frame properly. It assumes that the eip of the frame will :be near certain kernel symbols in order to determine what kind of frame :it is. : :Jake Actually all I did there was square up icu_vector.s so it looked almost the same as apic_vector.s. I would consider that an improvement. Besides, I find it very difficult to work on those macros without tabbing out the backslashes. I moved some of the #defines around due to it otherwise being a forward reference. This turned out not to be an issue since the macros aren't actually used until later in the code, but I don't like forward referenced macros anyway so I left it in. Insofar as diffs go, I'm afraid even the most conservative changes to the assembly to support interrupt deferral would make for a pretty big diff set. I'm not going to change them now, no, but I don't see this as being a show stopper in the least. -Matt Matthew Dillon [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
At 7:04 PM -0800 3/7/02, Matthew Dillon wrote: :Bruce also had some comments which were shrugged off, I thought they :were important. Specifically, please do not make unnecessary changes :to the assembler code. Macros do not need to be defined before they :are used, I believe this was the justification for some of the :reordering in apic_vector.s which makes the patch confusing. Please :do not tab out the ; \ at the end of the lines in the INTR and :FAST_INTR macros in icu_vector.s. This just makes unnecessary diffs. : :Jake Actually all I did there was square up icu_vector.s so it looked almost the same as apic_vector.s. I would consider that an improvement. Perhaps that part of the update could be considered cosmetic, and thus be done as a separate update -- just so people can tell which lines are cosmetic changes and which ones are substantive. That is more work for you, but it makes it easier on reviewers, and it is certainly consistent with what developers are asked to do on other updates they make. You'll still probably have a debate on the wonderfulness of that cosmetic change, but at least it makes it easier for the major changes to looked at and commented on separately. -- 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: Patch for critical_enter()/critical_exit() interrupt assem
On Thu, 7 Mar 2002, Justin T. Gibbs wrote: Then do the right things so it will. Unfortunatly that has been proven to not work. after reverting the change and silently waiting for a week 1/ no person bothered to review it. 2/ people assumed the patch had gone away. 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
In message [EMAIL PROTECTED] Julian Elischer writes: : : : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: : : Then do the right things so it will. : : Unfortunatly that has been proven to not work. : : after reverting the change and silently waiting for a week : 1/ no person bothered to review it. : 2/ people assumed the patch had gone away. Ummm, There are reviews in the archives that object to the API as it relates to optimization and those objections haven't been sanely answered with anything more constructive than BS. 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 assem
those reviews object on a purely subjective manner. I think this is premature I don't consider that to be a technical review? do you? they do not even comment on the bug-fixing aspect of the patch. On Thu, 7 Mar 2002, Warner Losh wrote: In message [EMAIL PROTECTED] Julian Elischer writes: : : : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: : : Then do the right things so it will. : : Unfortunatly that has been proven to not work. : : after reverting the change and silently waiting for a week : 1/ no person bothered to review it. : 2/ people assumed the patch had gone away. Ummm, There are reviews in the archives that object to the API as it relates to optimization and those objections haven't been sanely answered with anything more constructive than BS. Warner 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 assem
On 07-Mar-02 Matthew Dillon wrote:
:Search for paper John Baldwin and find link 6:
:
:http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=199282+204026+/usr/local/www/db/
:text/2002/freebsd-arch/20020303.freebsd-arch
:
:The actual paper is at:
: http://www.FreeBSD.org/~jhb/smpng/design/article.{ps,pdf}
:
:-J
:--
:Jeroen C. van Gelderen - [EMAIL PROTECTED]
Ok... I've read it. The sections on interrupts and critical sections
are fully compatible with my patch. The one section... basically
the last sentence of the last paragraph, is exactly the piece that
my patch cleans up and makes more flexible. Instead of requiring that
cpu_critical_*() always be used for the initial critical_enter() my
patch makes it optional, and for I386 I use that flexibility to allow
critical_*() to NOT have to call cpu_critical_*().
You seemed to have missed the entire part where we handle deferred preemptions
in MI code in critical_exit(). The critical_enter/exit stuff really exists to
support the preemption code and to get rid of the various FOO_NOSWITCH flags.
I think it is ok to remove the linkage between critical_enter/exit and
cpu_critical_* (possibly even renaming cpu_critical_* to a better name) and to
allow arch's to optimize cpu_critical_* but leave critical_* as MI code.
That's what I've asked for from the start and Jake even suggested it from the
start.
I'm still not comfortable with the optimiation, but changing the MI critical_*
code is by far my biggest objection to the code.
-Matt
Matthew Dillon
[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: Patch for critical_enter()/critical_exit() interrupt assem
On Thu, 7 Mar 2002, Warner Losh wrote: In message [EMAIL PROTECTED] Julian Elischer writes: : : : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: : : Then do the right things so it will. : : Unfortunatly that has been proven to not work. : : after reverting the change and silently waiting for a week : 1/ no person bothered to review it. : 2/ people assumed the patch had gone away. Ummm, There are reviews in the archives that object to the API as it relates to optimization and those objections haven't been sanely answered with anything more constructive than BS. The primary objections I've seen from Jake, and he posted them as part of the earlier thread prior to the commit, was that the API changes proposed by Matt don't make sense for the sparc64 implementation, uni-processor or multi-processor, and that while these changes might be appropriate for i386, he wanted to see the APIs set up in such a way that the differences in architectures were hidden in the MD code. This suggests working some more on the API before moving on, and my reading of earlier posts in the thread from John was that that was what he had in mind also. I don't pretend to understand all the issues here, but I think it's important to recognize that there have been several coherrent responses to the current patch that do need to be addressed. I think the preference I've seen from a number of developers is that the be addressed before the commit, rather than after. 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: Patch for critical_enter()/critical_exit() interrupt assem
: :In otherwords. You acted unilaterally. You seem to be making my :arguments for me. Again. Thanks! No, I am not acting unilaterally, but neither do I feel it is appropriate to be told to wait indefinitely (and I am STILL waiting by the way!). When I commit something it isn't set in stone. If there's a problem with the commit, or it doesn't integrate just right with something else, etc etc etc... I have no problem discussing and modifying the source. To me, the commit is a way to stage the work out, not the final chapter. This may not have been discussed with John prior to my wanting to commit it, but it was discussed. It was discussed on the lists, in public, and the discussion was quite reasonable in my view until I tried to commit it. Now contrast that with, say, Peter's PMAP commit. No discussion on the public lists AT ALL, no warning, no heads up, nothing. Did anyone complain? No. Contrast that commit with my critical_*() work. (Now, in fact, I am not faulting Peter nor saying that he should not have done the commit. I am simply contrasting it with my own work). My making a commit is not only not acting unilaterally, it is not setting the work in stone and it is not terminating debate or review either. It is just a stepping stone and I believe it is wholely inappropriate for you or anyone else to ask that a single stone not even be set down on the table when I have an armful of them without giving a reasonable reason for the request. You are at fault for not researching the situation before opening your mouth, and that you get burned for it is nobody's fault but your own. You are at fault for misunderstanding the purpose of the commit and ignoring my repeated statements regarding further discussion. You are at fault for assuming that my making this commit somehow means that I am not willing to continue a reasoned debate on the issues involved. Justin, you need to take a step back and really think about what you are tring to prove here. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: grp.h fix is incomplete
At 9:25 PM +0300 3/7/02, Andrey A. Chernov wrote: grp.h fix is incomplete because 'u_int32_t' is not defined (but must be) for standalone grp.h. Please add some includes for u_int32_t definition too, probably sys/types.h As a minor side question, should we also have that defined as uint32_t instead of u_int32_t ? -- 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: Patch for critical_enter()/critical_exit() interrupt assem
:: after reverting the change and silently waiting for a week :: 1/ no person bothered to review it. :: 2/ people assumed the patch had gone away. : :Ummm, There are reviews in the archives that object to the API as it :relates to optimization and those objections haven't been sanely :answered with anything more constructive than BS. : :Warner I think John has a right to object to the work based on it being an optimization, but that should not sufficient reason in anyone's book to veto a commit, especially something that is as straightforward and obvious as I believe my work to be in this case. Unlike John, I am not the type of person who leaves hundreds of kilobytes of patches laying around my tree. For me completed work is either committable, or it should be thrown away. John's other objections - in regards to interference with future work, are completely unsubstantiated. He has not explained any reasoning for his objections AT ALL other then to make vague, undirected comments about how it doesn't fit with his idea of the world. He pointed me to a 10-page mini paper and I even after reading it I do not see how any of my work inteferes with anything he is doing. Not a single person beyond John has voiced ANY objection to work beyond the wait for John to get back objection and the talk to John objection. Not one person. -Matt Matthew Dillon [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
:You seemed to have missed the entire part where we handle deferred preemptions :in MI code in critical_exit(). The critical_enter/exit stuff really exists to :support the preemption code and to get rid of the various FOO_NOSWITCH flags. :I think it is ok to remove the linkage between critical_enter/exit and :cpu_critical_* (possibly even renaming cpu_critical_* to a better name) and to :allow arch's to optimize cpu_critical_* but leave critical_* as MI code. :That's what I've asked for from the start and Jake even suggested it from the :start. : :I'm still not comfortable with the optimiation, but changing the MI critical_* :code is by far my biggest objection to the code. : :John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Who said anything about not handling deferred preemptions in MI code in critical_exit()? You mean just because I am moving less then 30 lines of code from MI to MD you object to the concept? What is so difficult about having the code, in the MD source files, do this: if (td-whatever_preemption_request) mi_function_to_deal_with_preemption(); We do this sort of thing all the time in MD code. It's useful because it allows us to focus a critical piece of code in a single source file rather then forcing us to split the critical piece of code into three or four source files as your current code does... all in the name of placing a bare 30 lines of code (less!) in kern/ instead of in arch/.../? Because in my view that is ALL you are talking about here... I don't see why the above code has to be in an MI procedure. It can just as easily be in an MD implementation of critical_*() and I believe the implementation of the API is far easier to work with and far more flexible with these two procedures sitting in MD rather then MI. I don't see how my code can possibly interfere with deferred preemption. Two lines of code in arch does not constitute interference, and I am certainly willing to deal with that myself... you don't have to lift one bloody finger. All you need to do is write your MI preemption handling code and you would have to do that in any case. Look at all the hacks you ALREADY have to deal with the split you impose between critical_*() and cpu_critical_*(). Look at the hack peter did and look at the incorrect assumptions you already have made in MI code due to the way you constructed the original API (hard interrupt disablement). And, most of all, I don't see how something so trivial should result in you vetoing my commit. I mean, it's no skin off your nose if down the line it turns out that critical_*() gets complex enough to warrent an MI split, because I would be the one doing it. But, right now, even with the preemption stuff you are talking about, there is NO REASON to keep a forced split and plenty of reasons to move it to MD. -Matt Matthew Dillon [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
:The primary objections I've seen from Jake, and he posted them as part of :the earlier thread prior to the commit, was that the API changes proposed :by Matt don't make sense for the sparc64 implementation, uni-processor or :multi-processor, and that while these changes might be appropriate for :i386, he wanted to see the APIs set up in such a way that the differences Huh? I have made no API changes that have any effect whatsoever on these architectures. Jake is free to implement whatever he wants for them, all I intend to do is make it easier and more flexible to do so. Sure, I intend to move critical_enter() and critical_exit() from MI to MD, but all that means for non-i386 architectures is that the EXACT procedures for critical_enter() and critical_exit() now sitting in kern/kern_switch.c will be copied into arch/arch/critical.c. That's the only effect for these other architectures. How our architectures handle things like deferred interrupts and SWI is architecture specific. It always has been and always will be. That doesn't mean we have to duplicate a large piece of code in arch/arch/critical.c (for example, SWI handling or deferred context switch support), it simply means that these functions will be written in an MI section and the MD critical_*() functions will simply call the MI functions. This work will come to a grand total of 2 or 4 lines of code per architecture. Big fucking deal! -Matt Matthew Dillon [EMAIL PROTECTED] :I don't pretend to understand all the issues here, but I think it's :important to recognize that there have been several coherrent responses to :the current patch that do need to be addressed. I think the preference :I've seen from a number of developers is that the be addressed before the :commit, rather than after. : :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: Patch for critical_enter()/critical_exit() interrupt assem
On Thu, Mar 07, 2002 at 02:43:36PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Julian Elischer writes: : : : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: : : Then do the right things so it will. : : Unfortunatly that has been proven to not work. : : after reverting the change and silently waiting for a week : 1/ no person bothered to review it. : 2/ people assumed the patch had gone away. Ummm, There are reviews in the archives that object to the API as it relates to optimization and those objections haven't been sanely answered with anything more constructive than BS. They are BS. Saying it's not good because it's an optimization is not a technical argument. I've already mentionned this before but I'm going to do it one more time, for the record: optimizations can be anything in SMPng. Heck, you could say that locking down a subsystem is an optimization. Even doing lockdowns (what John wants everyone to be doing) is something that is likely to change in the future. You can't prevent API changes from happening, they are part of regular evolutionary steps. Just look at what happened to the mbuf subsystem. I initially locked it down and it has changed an incredible amount. The API changed, other things changed. It's normal because it's part of regular code evolution. Therefore, you can't just say that the work some of us are doing is an optimization and that because it is that we shouldn't be doing it right now. These are things that have been in the TODO for a while now and are part of the general direction of this project and delaying them by claiming that it's too early and that the API might change is just preventing them from getting tested. Sure, the API may change. That's normal. You can't possibly get the API right at step 1. But you _can_ get the backend stuff at least working in the right direction. The same thing happened to our mutex code. The API totally changed (I cleaned it up myself). But does that mean that all the initial work done on mutex locks was wrong? I hope not. Without it, we never could have evolved to where we have. I've looked at both JHB's paper and Matt's patch. To me, it doesn't look like the direction we're supposed to be headed in is wrong. I don't see a technical argument (yet) saying otherwise besides for this it's an optimization and shouldn't go in thing. Please, if there is one, state it. The same applies to the ithread lightweight stuff I've been working on. Warner -- Bosko Milekic [EMAIL PROTECTED] [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 Tuesday, 5 March 2002 at 9:43:29 -0800, Matthew Dillon wrote: phk wrote: you have a right to bully the only person who have consistently chugged away at the SMPng project when practically everybody else (you included) defected. This is an extreme misrepresentation of the facts. I stated very clearly at the original Yahoo SMP summit that I would soon not be available. I did what work I could before I became unavailable, and then I was, SURPRISE! Unavailable for 2 years! I did not abandon anyone. I wrote that code that is the basis for allowing us to remove Giant from syscalls, I wrote the original idle process code including all the hard assembly stuff. I cleaned up the pre-SMPng SPL masks (cpl and cml). I did what I could in the time I had. I've got to defend Matt here. This happened exactly the way he says. This in no way detracts from the work John has done, of course. Greg -- See complete headers for address and phone numbers 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 Thursday, 7 March 2002 at 14:30:47 -0800, Matthew Dillon wrote: after reverting the change and silently waiting for a week 1/ no person bothered to review it. 2/ people assumed the patch had gone away. Ummm, There are reviews in the archives that object to the API as it relates to optimization and those objections haven't been sanely answered with anything more constructive than BS. Warner I think John has a right to object to the work based on it being an optimization, but that should not sufficient reason in anyone's book to veto a commit, especially something that is as straightforward and obvious as I believe my work to be in this case. I think this is a good point. We're in a development phase now, and we shouldn't step on each others' feet. But Matt has gone to some trouble to ensure it can be turned off at will. Come a release, it's possible that the project manager might decide to chop it out again, but I'm betting on it staying. Another issue: sure, it's partially an optimization. Sure, it contains MD code. But it also fixes bugs. Should a policy of structure now, optimize later mean we should reject bug fixes which also perform better? And will we, in the long term, be able to eliminate MD code and still have good performance? I think the issue of i386 only is a non-issue. It has to start somewhere, and it doesn't break the other platforms. Unlike John, I am not the type of person who leaves hundreds of kilobytes of patches laying around my tree. For me completed work is either committable, or it should be thrown away. Without prejudice to John (I don't know how much uncommitted stuff he has), I think that Matt's right here too. Where practicable, smaller increments are easier to handle. John's other objections - in regards to interference with future work, are completely unsubstantiated. He has not explained any reasoning for his objections AT ALL other then to make vague, undirected comments about how it doesn't fit with his idea of the world. He pointed me to a 10-page mini paper and I even after reading it I do not see how any of my work inteferes with anything he is doing. Core has asked John to describe his objections. Based on the current flam^H^H^H^Hdiscussion, I'm sure people will agree that it's probably better to discuss things in a smaller group first. The results will, of course, be made known. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SMPng manager's responsibilities (was: Patch for critical_enter()/critical_exit() interrupt assem)
On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote: On Thu, 7 Mar 2002, David Greenman wrote: No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead appointment. We specifically indicate that the tech lead is obligated to provide justification for any decisions that he may make. So, where is it? *sigh* It's not explicitly in the statement. I mentioned this point in core, and got the reply: Core recognizes John Baldwin's continued hard work on the SMPng project over the last 18 months. John has been informally directing the SMPng project for some time and we would like to formalize the arrangement. We are officially recognizing him as technical lead and he will be the final arbiter of technical issues relating to SMPng. I think we should say that he is responsible to core for his decisions. That would deflate some of dillon's objections. That goes without saying. Sigh. I'm getting tired of putting that in every last damn thing we do. This is not a differences of direction within core. We had a long discussion, and in the end it's a question of formulation. As I feared, this particular issue has been dragged up again. The text quoted above was version 5 of the draft. The final statement contained the additional text He has the authority to take those actions necessary to keep the SMPng effort on track, similar to the Security Officer's authority in the area of security. If you look back to *that* charter, you'll see that the SO is also responsible to core. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SMPng manager's responsibilities (was: Patch for critical_enter()/critical_exit() interrupt assem)
On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote: On Thu, 7 Mar 2002, David Greenman wrote: No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead appointment. We specifically indicate that the tech lead is obligated to provide justification for any decisions that he may make. So, where is it? *sigh* It's not explicitly in the statement. I mentioned this point in core, and got the reply: I think Julian is asking for John's justification, not our appointment message. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SMPng manager's responsibilities (was: Patch for critical_enter()/critical_exit() interrupt assem)
On Thursday, 7 March 2002 at 16:43:40 -0800, David Greenman wrote: On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote: On Thu, 7 Mar 2002, David Greenman wrote: No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead appointment. We specifically indicate that the tech lead is obligated to provide justification for any decisions that he may make. So, where is it? *sigh* It's not explicitly in the statement. I mentioned this point in core, and got the reply: I think Julian is asking for John's justification, not our appointment message. Ah, sorry. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: grp.h fix is incomplete
Garance A Drosihn [EMAIL PROTECTED] writes: At 9:25 PM +0300 3/7/02, Andrey A. Chernov wrote: grp.h fix is incomplete because 'u_int32_t' is not defined (but must be) for standalone grp.h. Please add some includes for u_int32_t definition too, probably sys/types.h Perhaps subconsciously I was trying to keep making software include sys/types.h before grp.h. :) I just committed a fix. As a minor side question, should we also have that defined as uint32_t instead of u_int32_t ? Yes, usually. I just grabbed the copy from sys/types.h, which wasn't correct. uint32_t is more correct, but requires pollution from another header, so I used the __uint32_t variant. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: smbfs in -current?
On Wed, 6 Mar 2002, Seth Hettich wrote: I have both: options SMBFS options NETSMB in my config. Perhaps someone could give a little explanation, and add it to NOTES? Thanks for pointing to it. For some reason LINT from -stable have this explanation and NOTES doesn't. For now quote from LINT: cut # SMB/CIFS requester # NETSMB enables support for SMB protocol, it requires LIBMCHAIN and LIBICONV # options. # NETSMBCRYPTO enables support for encrypted passwords. options NETSMB #SMB/CIFS requester options NETSMBCRYPTO#encrypted password support for SMB cut -- Boris Popov http://rbp.euro.ru 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
:Perhaps that part of the update could be considered cosmetic, and :thus be done as a separate update -- just so people can tell which :lines are cosmetic changes and which ones are substantive. That is :more work for you, but it makes it easier on reviewers, and it is :certainly consistent with what developers are asked to do on other :updates they make. : :You'll still probably have a debate on the wonderfulness of that :cosmetic change, but at least it makes it easier for the major :changes to looked at and commented on separately. : :-- :Garance Alistair Drosehn= [EMAIL PROTECTED] Ugh. I'd rather not. It would take a while to unwind the tabbing from the deferred interrupts. i.e. I didn't just cleanup the syntax in icu_vector.s, I also had to implement the same stuff I put in apic_vector.s to support deferred interrupts. -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
Apparently, On Thu, Mar 07, 2002 at 07:04:49PM -0800, Matthew Dillon said words to the effect of; :Yes. What I would like and what I mentioned before is for this to be :hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter :would be a null macro for i386, which would turn critical_enter into :just an increment, as Matt wanted. cpu_critical_exit would do all the :magic of unpending interrupts. The reason for this is that I would :like to see critical_exit handled any pending preemptions for a thread. :We do not yet know exactly how this will work so I would like this to be :done in MI code to start with. The code must not make assumptions that are :not valid on all platforms. This is easiest if they use the same code. :This is not about duplication of code in several MD files. We can't, because the MI code makes some rather blatent assumptions in regards to cpu_critical_enter and exit. Take the witness code, for example. So we cannot safely null-out those macros. In fact, the MI code also makes some rather blatent assumptions in regards to critical_enter() and exit which I have also had to clean up (and which will need considerably more cleanup). I agree that the use of cpu_critical_enter/exit could use cleaning up. Can you give an example of where critical_enter is used improperly? You mean in fork_exit? Your changes to cpu_switch solve that problem with critical_exit almost unchanged. The savecrit stuff should really just be made MD. If cpu_critical_exit was changed to take the thread as its argument as I suggested before this would be easy. Specifically I think that all of the current uses of cpu_critical_enter exit outside of critical_enter exit are bugs. The use in ktr is bogus because the increment of ktr_idx is done atomically. I don't know why this was there in the first place. I think that witness is an example of where we need a different specifically defined to be hard interrupt disable api. This is why I suggested the intr_disable/intr_restore api, which should only be used in MD code and in dire circumstances otherwise, of which this case qualifies. The code in ast is just structured wrong. I think that before the loop was in assembler outside of the routine itself, so that it didn't make so many assumptions about interrupt disablement. doreti which calls it should look like this: loop: cli; if (there is an ast we can handle) goto ast; iret; ast: sti; call ast; goto loop; In which case ast doesn't need to loop or use critical sections at all. All of the MD code I could find I think should use a different api for hard interrupt disablement. They are all very MD and need this specifically, which cpu_critical_enter need not necessarily do. With these changes I don't see why the critical_enter/exit functions can't or shouldn't remain MI. These assumptions include, just as an example: The witness code calling cpu_critical_enter()/exit without holding td_critnest count, and Peter's now withdrawn code which explicitly released the cpu critical section while holding a non-zero td_critnest count. In otherwords, really aweful hacks. So we can't just NULL out those inlines. Trying to keep critical_enter()/critical_exit() MI and cpu_critical_enter()/cpu_critical_exit() MD and separated doesn't make much sense to me, because frankly critical_enter() and critical_exit() are tiny little routines (and will remain tiny even after SWI and preemption is added) and I can't think of any reason to force higher complexity in the routines due to the separation. In short, critical_enter()/critical_exit() are TIGHTLY INTEGRATED with cpu_critical_enter/exit despite your attempt to make critical_enter/exit MI. What my patch does is accept as true the fact that the two sets of routines are, in fact, tightly integrated, and then implements them in a more sensible way (or, more to the point, allows each architecture to implement them in the proper manner as befits the architecture). I do not agree that having cpu_critical_enter separate in any way hinders an architecture's ability to implement critical_enter properly. The MI code that calls it expects it to do certain things, one of them is to call cpu_critical_enter and cpu_critical_exit exactly once for each non-nested critical_enter exit pair. Wether or not this actually disables interrupts is up to the MD code. The API's are still MI, but the implementation is MD. :Bruce also had some comments which were shrugged off, I thought they :were important. Specifically, please do not make unnecessary changes :to the assembler code. Macros do not need to be defined before they :are used, I believe this was the justification for some of the reordering :in apic_vector.s which makes the patch
