Re: Kernel panic with ipfw pipes
On Wed, Nov 22, 2000 at 09:19:41PM -0500, Bosko Milekic wrote: The attached kernel panic occurs when a connection is made that would pass through an ipfw pipe configured as: Please try this patch and report: http://people.freebsd.org/~bmilekic/ip_pipe.diff That seems to have done the trick. The new structure also makes sense when viewed in the kgdb context. Thanks -Russell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Mutex, SMBUS, ACPI (Re: how to mutex'ify a device driver)
On Wed, Nov 22, 2000 at 04:58:32PM -0800, Archie Cobbs wrote: As a relatively simple exercise in -current kernel programming, I'm planning to mutex'ify the ichsmb(4) device driver (this is a relatively simple driver that currently uses splhigh()). I'd appreciate some feedback if what I'm doing is the right thing. What are kernel mutex? A new mechanism for spl replacement? Is it introduced with the new SMP? I found nothing in the mail archives... The plan is to give each instance of the device a mutex. This mutex will be grabbed by both the top level code (when programming the chip to do something or reading the results) and the interrupt code (when servicing an interrupt). Have you comments about smbus/iicbus? What would you add to the todo list of the framework? Did you participate to ACPI discussions? -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: COMPAT_SVR4 broken after uipc_syscalls commit (1.77)
: :Okay, this time I'll even include the entire patch... : :-- Danny J. Zerkel :[EMAIL PROTECTED] Thanks Danny. I've comitted it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console - /var/log/messages idea/patch
On 22 Nov, Ashley Penney wrote: The attached patch is a "proof-of-concept" on which I would like to get some comments: I'm only a moronic user, but this would make my life easier. My machine switches into 132x43 on startup, and I always lose the output. So this Its in the scrollback buffer. BTW: are you using a recent -current on an UP machine? After the first SMPNG commits the switch to 132x60 caused a hang on my machine and I haven't tested if this still happens. is just me saying "Yay for phk." Yes. Regarding the "syslog writes messages back to /dev/console" thing: isn't this just a "I want to be able to shoot in my own foot" bikeshed? Bye, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
slight improvement in locore.s?
locore.s includes: #define ALLOCPAGES(foo) \ movlR(physfree), %esi ; \ movl$((foo)*PAGE_SIZE), %eax ; \ addl%esi, %eax ; \ movl%eax, R(physfree) ; \ movl%esi, %edi ; \ movl$((foo)*PAGE_SIZE),%ecx ; \ xorl%eax,%eax ; \ cld ; \ rep ; \ stosb might it be a very slight optimisation to change this to: #define ALLOCPAGES(foo) \ movlR(physfree), %esi ; \ movl$((foo)*PAGE_SIZE), %eax ; \ movl%eax, %ecx ; \ addl%esi, %eax ; \ movl%eax, R(physfree) ; \ movl%esi, %edi ; \ xorl%eax,%eax ; \ cld ; \ rep ; \ stosb ?? -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
* Mike Meyer [EMAIL PROTECTED] [001122 22:41] wrote: Could I get some feedback on URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=22755 ? It's just a one-line kernel patch with some attendant updates in the kernel and libc, but it makes dealing with broken #! scripts *much* saner, and no one has even seen fit to comment on it yet :-(. This patch may break compliance, ENOEXEC is the proper error code, the shell should try to be a bit smarter about explaining why ENOEXEC was returned. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slight improvement in locore.s?
:might it be a very slight optimisation to change this to: :#define ALLOCPAGES(foo) \ :movlR(physfree), %esi ; \ :... :movl$((foo)*PAGE_SIZE), %eax ; \ ... but why? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slight improvement in locore.s?
locore.s includes: #define ALLOCPAGES(foo) \ movlR(physfree), %esi ; \ movl$((foo)*PAGE_SIZE), %eax ; \ addl%esi, %eax ; \ movl%eax, R(physfree) ; \ movl%esi, %edi ; \ movl$((foo)*PAGE_SIZE),%ecx ; \ xorl%eax,%eax ; \ cld ; \ rep ; \ stosb might it be a very slight optimisation to change this to: #define ALLOCPAGES(foo) \ movlR(physfree), %esi ; \ movl$((foo)*PAGE_SIZE), %eax ; \ movl%eax, %ecx ; \ addl%esi, %eax ; \ movl%eax, R(physfree) ; \ movl%esi, %edi ; \ xorl%eax,%eax ; \ cld ; \ rep ; \ stosb ?? Improvement in what way? Readability? I don't think so. Performance? This macro is only used in the initial bootstrap of the kernel. ...changing it might save a few bytes, however. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.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: slight improvement in locore.s?
It does not impair readability. As long as that is true, I believe its prudent to save every byte possible... Only my 2 cents worth. JAn On Thu, 23 Nov 2000, David Greenman wrote: locore.s includes: #define ALLOCPAGES(foo) \ movlR(physfree), %esi ; \ movl$((foo)*PAGE_SIZE), %eax ; \ addl%esi, %eax ; \ movl%eax, R(physfree) ; \ movl%esi, %edi ; \ movl$((foo)*PAGE_SIZE),%ecx ; \ xorl%eax,%eax ; \ cld ; \ rep ; \ stosb might it be a very slight optimisation to change this to: #define ALLOCPAGES(foo) \ movlR(physfree), %esi ; \ movl$((foo)*PAGE_SIZE), %eax ; \ movl%eax, %ecx ; \ addl%esi, %eax ; \ movl%eax, R(physfree) ; \ movl%esi, %edi ; \ xorl%eax,%eax ; \ cld ; \ rep ; \ stosb ?? Improvement in what way? Readability? I don't think so. Performance? This macro is only used in the initial bootstrap of the kernel. ...changing it might save a few bytes, however. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slight improvement in locore.s?
[EMAIL PROTECTED] wrote: It does not impair readability. As long as that is true, I believe its prudent to save every byte possible... My two cents. It's an improvement in speed (unmeasurable, granted :) and size (a couple of bytes). It doesn't have any disadvantage. So, if someone is willing to commit it, there really shouldn't be any objection to it. As silly as the improvement it, contest it is even more silly. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "All right, Lieutenant, let's see what you do know. Whatever it is, it's not enough, but at least you haven't done anything stupid yet." "I've hardly had time, sir." "There's a naive statement." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page coloring
Hi. Isn't the page coloring algoritm in _vm_page_list_find totally bogus? No, it's not. The comment is, however, misplaced. It describes the behavior of an inline function in vm_page.h, and not the function it precedes. It skips queue pq[index PQ_L2_MASK]. That's correct. The inline function vm_page_list_find() in vm_page.h has already failed to allocate a page of the desired color, index, and so _vm_page_list_find() is called to allocate a page of ANY other color it can find. Rather than choose a random page, the odd-looking loop in _vm_page_list_find() tries to find a page whose color is unlikely to equal the neighboring pages in the vm object if colored allocation for them succeeded. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page coloring
Isn't the page coloring algoritm in _vm_page_list_find totally bogus? No, it's not. The comment is, however, misplaced. It describes the behavior of an inline function in vm_page.h, and not the function it precedes. Hrm. My comment was based on John Dyson's own observations on its behaviour, and other discussions which concluded that the code wasn't flexible enough (hardcoded assumptions on cache organisation, size etc.) If this isn't applicable, my apologies for confusing the matter. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slight improvement in locore.s?
that's all I was thinking.. I actually think it DOES improve readability.. because I spent time wondering why the same line was there twice :-) I was just reading the file and thought, 'hey why not'? then I thought probably it's doing something I don't understand.. but I think I was right the first time.. just an unimportant niggly thing.. Improvement in what way? Readability? I don't think so. Performance? This macro is only used in the initial bootstrap of the kernel. ...changing it might save a few bytes, however. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.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 -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: /dev/console - /var/log/messages idea/patch
Alexander Leidinger [EMAIL PROTECTED] writes: On 22 Nov, Ashley Penney wrote: The attached patch is a "proof-of-concept" on which I would like to get some comments: I'm only a moronic user, but this would make my life easier. My machine switches into 132x43 on startup, and I always lose the output. So this Its in the scrollback buffer. and how do you access the scroll-back buffer if you are not front to the console (read remote) ? Cyrille. -- home: mailto:[EMAIL PROTECTED] work: mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Alfred Perlstein [EMAIL PROTECTED] types: * Mike Meyer [EMAIL PROTECTED] [001122 22:41] wrote: Could I get some feedback on URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=22755 ? It's just a one-line kernel patch with some attendant updates in the kernel and libc, but it makes dealing with broken #! scripts *much* saner, and no one has even seen fit to comment on it yet :-(. Thank you for taking time to look at it. This patch may break compliance, ENOEXEC is the proper error code, Um - compliance with what, exactly? I know it breaks compliance with Unix standards for user friendliness, but that was the point. I also agree that ENOEXEC is the best currently existing error code - but for this it pretty much sucks. Exec returns other codes providing more informative error messages; adding one more shouldn't be a problem. the shell should try to be a bit smarter about explaining why ENOEXEC was returned. Um - not "the" shell; all of them. Given that the authors of some of them are worried about portability, doing so portably is probably important as well. That's why I decided it belonged in the kernel. Doing this means that all shells get the benefit of it without a source change, and the only change other than better error messages was if there is an executable with the same name behind a broken script in the path - and I *couldn't* convince myself that was a problem! mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
