subscribe
subscribe me please =) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Tonight make world failed at isdnmonitor...
Debugging uthreads
I've put an initial version of my hack for debugging FreeBSD user threads with gdb up on http://www.freebsd.org/~dfr/uthread.diff. Comments would be appreciated. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
The binary is now available by anonymous ftp at ftp.genericwindows.com in the pub directory. If you have problems, please email me directly. Carlos C. Tapang http://www.genericwindows.com -Original Message- From: Max Khon To: Carlos C. Tapang Cc: Jordan K. Hubbard ; freebsd-current@FreeBSD.ORG Date: Tuesday, May 11, 1999 10:45 PM Subject: Re: FBSDBOOT.EXE >hi, there! > >On Tue, 11 May 1999, Carlos C. Tapang wrote: > >> Because I need it, I have upgraded fbsdboot.exe so now it can recognize ELF. >> If anybody else needs it, please let me know and I'll see what I can do for >> you. >> ps. I had to use my old Microsoft Visual C++ (ver 1.5) to do this >> modification. > >where can I get the diffs or binaries? > >/fjoe > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: de driver problem
As Wilko Bulte wrote ... > As Doug Rabson wrote ... > > On Mon, 10 May 1999, Wilko Bulte wrote: > > > > > > > > > > Yeah. That must be why my 164lx won't netboot. > > > > > > Could well be. My Aspen Alpine refused to with a DE500. A DE435 (10mbit > > > only) worked just dandy. > > > > That reminds me. Does your Alpine still work after the new-bus stuff? I > > wasn't sure I hadn't broken it when I changed the apecs driver. > > My Alpine is on a not so current -current, but it is rebuilding world now. > Stay tuned, I can probably tell you more tomorrow. Bah.. Extracting pod2man (with variable substitutions) cd ext/B; miniperl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib Makefile.PL LINKTYPE=dynamic INSTALLDIRS=perl PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl LIBS="-lperl" INSTALLMAN3DIR=/usr/obj/usr/src/tmp/usr/share/perl/man3 INST_LIB=/usr/obj/usr/src/gnu/usr.bin/perl/perl/build/B INST_ARCHLIB=/usr/obj/usr/src/gnu/usr.bin/perl/perl/build/B ; make -B config PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl Writing Makefile for DynaLoader ==> Your Makefile has been rebuilt. <== ==> Please rerun the make command. <== false false: not found *** Error code 1 This is -current as of last Sunday. I'll resup tonight to see if it got fixed in the meantime Groeten / Cheers, | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > I've put an initial version of my hack for debugging FreeBSD user threads > with gdb up on http://www.freebsd.org/~dfr/uthread.diff. Comments would be > appreciated. Is the uniqueid really necessary when the address of the thread structure is already unique within the process address space? After all, that's what the thread ID is (a pointer to the malloc'd memory). I have the feeling that there needs to be some way to discover if the version of gdb being used is compatible with the version of libc_r that the program is linked against. Otherwise we end up with a similar problem to the all too familiar "struct proc size mismatch". -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
simple (but important) task for junior kernel hacker
I don't have time just now to attend this particular detail, which manifests itself by swapinfo/pstat -p showing "/dev/(null)" for device name. The problem in short is that libkvm:kvm_getswapinfo.c has it's fingers in the kernels memory and pulls out a dev_t without knowing how to (and it shouldn't be taught this!) convert it to a udev_t. The Right Way to solve this problem is to rewrite libkvm:kvm_getswapinfo.c to pick up the information using some (for this purpose constructed) sysctl variables (sysctlbyname(3) please!), and let the kernel convert the dev_t to udev_t before passing it out to userland. So for any aspiring kernel hackers out there: have at it. Patches accepted. In general libkvm should not grovel around in a running kernel but only use sysctlbyname(3). -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
On Wed, 12 May 1999, John Birrell wrote: > Doug Rabson wrote: > > I've put an initial version of my hack for debugging FreeBSD user threads > > with gdb up on http://www.freebsd.org/~dfr/uthread.diff. Comments would be > > appreciated. > > Is the uniqueid really necessary when the address of the thread structure > is already unique within the process address space? After all, that's > what the thread ID is (a pointer to the malloc'd memory). > > I have the feeling that there needs to be some way to discover if the > version of gdb being used is compatible with the version of libc_r that > the program is linked against. Otherwise we end up with a similar > problem to the all too familiar "struct proc size mismatch". I didn't want to use the address since it might cause confusion if a thread was freed and then the memory was re-allocated to create a new thread. I thought about the versioning but I don't think it will be a problem in practice since both uthread and gdb will generally be built by a single 'make world'. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > I didn't want to use the address since it might cause confusion if a > thread was freed and then the memory was re-allocated to create a new > thread. Good reason. > I thought about the versioning but I don't think it will be a problem in > practice since both uthread and gdb will generally be built by a single > 'make world'. But libc_r isn't linked into anything during a 'make world'. It is only linked to 3rd party applications. So, although libc_r and gdb are in sync at the end of a 'make world', any statically linked applications will be out-of-sync (if an internal change has been made to libc_r). I'm not sure there is an easy solution to this. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
Mike Smith writes: >> I switched to the new config(8) today, where the ``config kernel root on..'' >> line is no longer tolerated in the config file. >> >> I now have to ``boot -r'' to avoid a `can't mount root' panic. This wasn't >> necessary before. >> >> I know I can probably put something into /boot/ to automate this. >> Just thought I'd report my (negative) experience. > >Can you tell us what it's trying to mount vs. what it should be >mounting? > >I'm in the process of rewriting parts of this code again to fix the >mess that's been made of it. I'm not sure I'll get all the way, but in >conjunction with some small changes in the loader it *should* make >problems like yours history. > Sorry, all I see is the panic message. As I wrote in another mail, the loader sees the floppy as DISK A and the SCSI disk as DISK B. But then again, it saw that before. Since I'm leaving shortly on a trip and won't be back for 2 weeks I won't be able to pursue this further. --- Gary Jennejohn Home - ga...@muc.de Work - ga...@fkr.dec.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
On Wed, 12 May 1999, John Birrell wrote: > Doug Rabson wrote: > > I didn't want to use the address since it might cause confusion if a > > thread was freed and then the memory was re-allocated to create a new > > thread. > > Good reason. > > > I thought about the versioning but I don't think it will be a problem in > > practice since both uthread and gdb will generally be built by a single > > 'make world'. > > But libc_r isn't linked into anything during a 'make world'. It is only > linked to 3rd party applications. So, although libc_r and gdb are in > sync at the end of a 'make world', any statically linked applications > will be out-of-sync (if an internal change has been made to libc_r). > I'm not sure there is an easy solution to this. Other gdb thread debugging systems tend to export a set of variables from the thread library which describe the important offsets in the thread structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset etc. If you think there will be a real problem, I could do this I guess. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > Other gdb thread debugging systems tend to export a set of variables from > the thread library which describe the important offsets in the thread > structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset > etc. > > If you think there will be a real problem, I could do this I guess. Maybe we should just isolate the things that gdb is allowed to look at and document them as "cast in stone". -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
Poul-Henning Kamp writes: >In message <199905111939.vaa02...@peedub.muc.de>, Gary Jennejohn writes: >>I switched to the new config(8) today, where the ``config kernel root on..'' >>line is no longer tolerated in the config file. >> >>I now have to ``boot -r'' to avoid a `can't mount root' panic. This wasn't >>necessary before. >> >>I know I can probably put something into /boot/ to automate this. >>Just thought I'd report my (negative) experience. > >What's your config ? It sounds like the boot code isn't telling the >kernel the right thing... > >I belive it picks the bootmajor from the type field in the >disklabel. (right Mike ?) > >So do you have a IDE/ATA disk labeled as SCSI by any chance ? > no, it's a "dangerously dedicated" SCSI disk. the loader shows the floppy as DISK A and the SCSI disk as DISK B. I have to admit that I still have old boot blocks on the disk, but as I said, it worked OK before. --- Gary Jennejohn Home - ga...@muc.de Work - ga...@fkr.dec.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: simple (but important) task for junior kernel hacker
On Wed, 12 May 1999 at 10:04:09 +0200, Poul-Henning Kamp wrote: > > I don't have time just now to attend this particular detail, which > manifests itself by swapinfo/pstat -p showing "/dev/(null)" for > device name. > > The problem in short is that libkvm:kvm_getswapinfo.c has it's > fingers in the kernels memory and pulls out a dev_t without knowing > how to (and it shouldn't be taught this!) convert it to a udev_t. > > The Right Way to solve this problem is to rewrite libkvm:kvm_getswapinfo.c > to pick up the information using some (for this purpose constructed) > sysctl variables (sysctlbyname(3) please!), and let the kernel convert > the dev_t to udev_t before passing it out to userland. > > So for any aspiring kernel hackers out there: have at it. Patches > accepted. > > In general libkvm should not grovel around in a running kernel but > only use sysctlbyname(3). > > -- the only place in the entire libkvm where a dev_t is used is kvm_proc.c line 230 this particular section completely looses me Rob To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: simple (but important) task for junior kernel hacker
In message <19990512033344.e21...@phc.igs.net>, Robert Garrett writes: >On Wed, 12 May 1999 at 10:04:09 +0200, Poul-Henning Kamp wrote: >> >> I don't have time just now to attend this particular detail, which >> manifests itself by swapinfo/pstat -p showing "/dev/(null)" for >> device name. >> >> The problem in short is that libkvm:kvm_getswapinfo.c has it's >> fingers in the kernels memory and pulls out a dev_t without knowing >> how to (and it shouldn't be taught this!) convert it to a udev_t. >> >> The Right Way to solve this problem is to rewrite libkvm:kvm_getswapinfo.c >> to pick up the information using some (for this purpose constructed) >> sysctl variables (sysctlbyname(3) please!), and let the kernel convert >> the dev_t to udev_t before passing it out to userland. >> >> So for any aspiring kernel hackers out there: have at it. Patches >> accepted. >> >> In general libkvm should not grovel around in a running kernel but >> only use sysctlbyname(3). >> >> -- >the only place in the entire libkvm where a dev_t is used is >kvm_proc.c line 230 this particular section completely looses me There is a dev_t passed out to pstat -s in a datastructure. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
On Tue, 11 May 1999 21:39:42 +0200, Gary Jennejohn wrote: > I switched to the new config(8) today, where the ``config kernel root on..'' > line is no longer tolerated in the config file. As a workaround, try the following, taken directly from LINT options ROOTDEVNAME=\"da0s2e\" Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: simple (but important) task for junior kernel hacker
On Wed, 12 May 1999 at 10:38:41 +0200, Poul-Henning Kamp wrote: > In message <19990512033344.e21...@phc.igs.net>, Robert Garrett writes: > >On Wed, 12 May 1999 at 10:04:09 +0200, Poul-Henning Kamp wrote: > >> > >> I don't have time just now to attend this particular detail, which > >> manifests itself by swapinfo/pstat -p showing "/dev/(null)" for > >> device name. > >> > >> The problem in short is that libkvm:kvm_getswapinfo.c has it's > >> fingers in the kernels memory and pulls out a dev_t without knowing > >> how to (and it shouldn't be taught this!) convert it to a udev_t. > >> > >> The Right Way to solve this problem is to rewrite libkvm:kvm_getswapinfo.c > >> to pick up the information using some (for this purpose constructed) > >> sysctl variables (sysctlbyname(3) please!), and let the kernel convert > >> the dev_t to udev_t before passing it out to userland. > >> > >> So for any aspiring kernel hackers out there: have at it. Patches > >> accepted. > >> > >> In general libkvm should not grovel around in a running kernel but > >> only use sysctlbyname(3). > >> > >> -- > >the only place in the entire libkvm where a dev_t is used is > >kvm_proc.c line 230 this particular section completely looses me > > There is a dev_t passed out to pstat -s in a datastructure. Right and thats where it comes from kvm_proc.c is responsible for dealing with pstat at least the way I read that file Rob > > -- > Poul-Henning Kamp FreeBSD coreteam member > p...@freebsd.org "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
On Wed, 12 May 1999, John Birrell wrote: > Doug Rabson wrote: > > Other gdb thread debugging systems tend to export a set of variables from > > the thread library which describe the important offsets in the thread > > structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset > > etc. > > > > If you think there will be a real problem, I could do this I guess. > > Maybe we should just isolate the things that gdb is allowed to look at > and document them as "cast in stone". That would work. I think I only need uniqueid, sig_saved, saved_sigcontext, saved_jmpbuf, state and nxt. If those guys were lumped up at the start of struct pthread (possibly in another struct so that gdb doesn't need to know sizeof(struct pthread)) and marked appropriately then the debugger interface would be quite stable. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: simple (but important) task for junior kernel hacker
In message <19990512034529.a5...@phc.igs.net>, Robert Garrett writes: >> There is a dev_t passed out to pstat -s in a datastructure. > >Right and thats where it comes from kvm_proc.c is responsible for >dealing with pstat at least the way I read that file pstat >-s< is what we're talking about right now. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
Hi, On Tue, 11 May 1999, Luigi Rizzo wrote: > Hi, > maybe i am the last one in the world to know, but were you guys aware > of this: > > http://research.microsoft.com/programs/NTSrcLicInfo.htm > > Microsoft makes Windows NT source code available to universities > and other "not-for-profit" research institutions at no charge. > Currently, there are over 55 universities and government agencies > with source licenses. > ... > > I still have to check the exact conditions though. The above web page > says this: > > Features of the license > > * No cost > * Intellectual property created with the use of NT source code is >owned by the researcher. > * Source licensees can share source or other source-based work >with other NT Source licensees. > * Source is licensed to the requesting organization, not individuals >to insure broad internal access. > * No employment restrictions as the result of viewing or using the >source. > Are we going to get this license? I am interested in NTFS source code a lot... P.S. What's happening with MS? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > That would work. I think I only need uniqueid, sig_saved, > saved_sigcontext, saved_jmpbuf, state and nxt. If those guys were lumped > up at the start of struct pthread (possibly in another struct so that gdb > doesn't need to know sizeof(struct pthread)) and marked appropriately then > the debugger interface would be quite stable. I'd be inclined to add the magic number too, because it gives a hint as to whether the structure refers to a valid thread. If the thread is destroyed, the magic number is trashed. I think it is worth adding a new header file defining such a structure. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
[no subject]
running FreeBSD 4.0-CURRENT i have encountered the following problems: 1. something is wrong with psm0 driver. my Genius NewScroll PS/2 mouse works well, but in random moment when i touch the mouse kernel starts to write to the system log the following. Apr 29 11:55:58 camel /kernel: psmintr: out of sync (00c8 != 0008). Apr 29 11:55:58 camel /kernel: psmintr: out of sync (00c0 != 0008). when it happens, mouse cursor moves, but buttons do not work. only reboot solves this problem. this bug doesn't appear with Microsoft and Hewlett-Packard mice. my string in my kernel config related to mouse is device psm0 at atkbdc? irq 12 and kernel detects the mouse as psm0: on atkbdc0 psm0: model NetMouse, device ID 0 psm0: interrupting at irq 12 2. i cannot start X Window + KDE wirh new kernel. the system just reboots when i start X. everything is ok with older (Tue May 11 16:17:50 MSD 1999) kernel. 3. i don't think that it is really a bug, but it's just interesting for me. during bootup process my kernel writes the following message: Bad SMBIOS table checksum! so, what is SMBIOS table and why its checksum is bad? :) -- sincerely, ilya naumov (at work) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
On Wed, 12 May 1999, John Birrell wrote: > Doug Rabson wrote: > > That would work. I think I only need uniqueid, sig_saved, > > saved_sigcontext, saved_jmpbuf, state and nxt. If those guys were lumped > > up at the start of struct pthread (possibly in another struct so that gdb > > doesn't need to know sizeof(struct pthread)) and marked appropriately then > > the debugger interface would be quite stable. > > I'd be inclined to add the magic number too, because it gives a hint > as to whether the structure refers to a valid thread. If the thread > is destroyed, the magic number is trashed. > > I think it is worth adding a new header file defining such a structure. Ok, I'll see about updating my patch along these lines and I'll post up another one in a day or two. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing list, because I am a NetBSD user. :-) > > It depends on old-config, so poor mechanism. newconfig already > > implimented best match probe/attach. > > And a very useful mechanism it is. Which is why I implemented priority > ordered probes in -current. Hmm, I thought this cannot be done correctly on new-bus, because the new-bus kicks match/attach routine from SYSINIT(). It is apparent that this fails in dynamic configuration case, because a potencial candidate of drivers which is dynamically loaded first always matches. This behaviour can not be called as "best match", but "first match". :-) Of course, dynamic configuration of newconfig solves this problem. Was this behaviour of the new-bus changed in -current ? BTW, there are many fundamental design flaws in new-bus, so I don't think new-bus is comparable with newconfig, yet, even if priority probe is implemented. For example: - newconfig can cope with both static configuration and dynamic configuration. new-bus can handle dynamic configuration only. This is because critical information for configuration is represented in C source internally. e.g. The bus/device hierarchy information is embedded in DRIVER_MODULE() on new-bus. On newconfig, such information is represented externally in "files" file. Thus the information can be used in both static and dynamic configuration case. As a result, newconfig can support same configuration syntax in both static and dynamic configuration, the new-bus never can do it. - new-bus cannot support on-demand device driver loading, dynamic configuration for newconfig can do it, though. This is because new-bus doesn't have the way to represent meta information like a mapping from device name to driver filename. If new-bus have this, there is no need to specifiy "kldload if_fxp", but just say "I need fxp0", then configuration framework can automatically load fxp driver, if it is not loaded yet. This is how configuration works in both newconfig and even oldconfig (look at static kernel configuration file for oldconfig, there is the line "device fxp0" which demands fxp driver to be loaded). The way to specify a driver to be linked on new-bus is retrogression to the age before 4.0BSD (4.0BSD introduced oldconfig and it was released on 1980 :-)). Why does a user have to specify file name instead of device name? Mmmm, perhaps do new-bus people believe MS-DOSism or Linuxism? :-) The way on new-bus will cause compatibility problem when OS is upgraded, because the implementation (filename) may be changed between versions and versions. - new-bus heavily depends on oldconfig which is known to be obsolete and machine dependent (look at usr.sbin/config/config.y, there are many definitions which depends on ISA bus, e.g. PORT, IOMEM, IOSIZE, ... newconfig can defines such attributes dynamically on demand.), and lacks many features which newconfig already has. e.g. - configruration hint which can be accessed from static configuration - bus/device hierarchy information which can be accessed from static configuration - inter module dependency information based on module attributes. new-bus completely lacks this feature, and depends on oldconfig about this. - mapping information from device name to object file name. new-bus completely lacks this feature, and depends on old config about this. Therefore, FreeBSD eventually will have to choose one of the following candidates: [a] gives up static configuration. But this doesn't solve the following problems: - at least console driver should be linked statically, unless you statically link this, you cannot get the error about dynamic loading critical drivers. :-) - in some applications, static configuration is good enough and dynamic configuration is merely overkill. FreeBSD will not cope with these applications better. Furthermore, this doesn't solves the problems about inter module dependency and mapping information from device name to object filename. [b] uses ugly kluge like hardcoding to solve the problems which already solved by the newconfig cleanly. [c] reinvents features which already implemented on the newconfig. This is exactly NIH problem, and means FreeBSD loses compatibility with *BSDs (FreeBSD becomes non-BSD). Note that newconfig is genuine feature of 4.4BSD, and 4.4BSD red daemon books already said that after the system is completely booted, 4.4BSD (i.e. newconfig) cannot load device drivers
Re: Debugging uthreads
Doug Rabson wrote: > Ok, I'll see about updating my patch along these lines and I'll post up > another one in a day or two. One more thing... the states are subject to change, probably with new states being added. It is important to check that the state number is within the range that gdb was compiled against (the states probably should be in the common header) and if the state number is out of that range, just display the number. Then we just need to ensure we add new states at the end. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
On Wed, 12 May 1999, John Birrell wrote: > Doug Rabson wrote: > > Ok, I'll see about updating my patch along these lines and I'll post up > > another one in a day or two. > > One more thing... the states are subject to change, probably with new > states being added. It is important to check that the state number is > within the range that gdb was compiled against (the states probably > should be in the common header) and if the state number is out of > that range, just display the number. Then we just need to ensure we > add new states at the end. I think the only state which I need to know about is PS_DEAD. If we marked dead threads in the public struct it might simplify things. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > I think the only state which I need to know about is PS_DEAD. If we marked > dead threads in the public struct it might simplify things. You use PS_RUNNING too. We could just tie down those two as PS_DEAD = 0 and PS_RUNNING = 1. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999, Noriyuki Soda wrote: > NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing > list, because I am a NetBSD user. :-) > > > > It depends on old-config, so poor mechanism. newconfig already > > > implimented best match probe/attach. > > > > And a very useful mechanism it is. Which is why I implemented priority > > ordered probes in -current. > > Hmm, I thought this cannot be done correctly on new-bus, because > the new-bus kicks match/attach routine from SYSINIT(). It is apparent > that this fails in dynamic configuration case, because a potencial > candidate of drivers which is dynamically loaded first always matches. > This behaviour can not be called as "best match", but "first match". :-) > Of course, dynamic configuration of newconfig solves this problem. > > Was this behaviour of the new-bus changed in -current ? Yes. > BTW, there are many fundamental design flaws in new-bus, so I don't > think new-bus is comparable with newconfig, yet, even if priority > probe is implemented. For example: I'm not going to reply to these points as I suspect it will lead to a pointless flame thread. I would prefer to discuss these issues in person at Usenix. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> > BTW, there are many fundamental design flaws in new-bus, so I don't > > think new-bus is comparable with newconfig, yet, even if priority > > probe is implemented. For example: > > I'm not going to reply to these points as I suspect it will lead to a > pointless flame thread. I would prefer to discuss these issues in person > at Usenix. I agree that this is better way to solve the conflicts between new-bus and newconfig. Although I wondered why FreeBSD's core decide to choose new-bus before Usenix. -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
has the 3.2 branch happened?
(he asked :) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Anybody actually using gigabit ethernet?
On Tue, May 11, 1999 at 08:23:15PM +0200, Poul-Henning Kamp wrote: > > Isn't it more appropriate to ask where he didn't learn to read ? :-) > Ok. ok. thanks for the abuse :) > > > >> > tcp_extensions="NO" # Disallow RFC1323 extensions (or YES). > > So we're agreed that this is confusing no? Couldn't it read: tcp_extensions="NO" # Switch RFC1323 extensions on? That way I'd understand it however awake I was :) Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE:
On 12-May-99 Ilya Naumov wrote: > > running FreeBSD 4.0-CURRENT i have encountered the following > problems: > > 1. something is wrong with psm0 driver. my Genius NewScroll PS/2 > mouse works > well, but in random moment when i touch the mouse kernel starts to > write to the > system log the following. > > Apr 29 11:55:58 camel /kernel: psmintr: out of sync (00c8 != 0008). > Apr 29 11:55:58 camel /kernel: psmintr: out of sync (00c0 != 0008). > > when it happens, mouse cursor moves, but buttons do not work. only > reboot solves this problem. this bug doesn't appear with Microsoft > and > Hewlett-Packard mice. If you are using moused then a killall -HUP moused can often solve this sort of problem without a reboot. -- E-Mail: Steve O'Hara-Smith Date: 12-May-99 Time: 10:59:13 This message was sent by XFMail -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: simple (but important) task for junior kernel hacker
Hrmmm have any commits been made on this one yet? The reason Im asking is that as of about 2am my time last night I cvsupped to 4.0-CURRENT and I cant build, it dies on libkvm. It claims the error exists in /usr/src/sys/sys/vnode.h, exact error message as follows: In file included from /usr/src/lib/libkvm/kvm_getswapinfo.c:22: /usr/src/lib/libkvm/../../sys/sys/vnode.h:186: parse error before `udev_t' /usr/src/lib/libkvm/../../sys/sys/vnode.h:186: warning: no semicolon at end of struct or union /usr/src/lib/libkvm/../../sys/sys/vnode.h:191: parse error before `:' cc -nostdinc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm/../../sys -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o cc -fpic -DPIC -nostdinc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm/../../sys -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/lib/libkvm/kvmproc.c -o kvm_proc.So *** Error code 1 *** Error code 1 2 errors (I think this is right, I had to type it out but I think I got it ok). Any ideas? Cheers Andrew On Wed, 12 May 1999, Poul-Henning Kamp wrote: > In message <19990512034529.a5...@phc.igs.net>, Robert Garrett writes: > > >> There is a dev_t passed out to pstat -s in a datastructure. > > > >Right and thats where it comes from kvm_proc.c is responsible for > >dealing with pstat at least the way I read that file > > pstat >-s< is what we're talking about right now. > > -- > Poul-Henning Kamp FreeBSD coreteam member > p...@freebsd.org "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
John Birrell wrote: > Doug Rabson wrote: > > Other gdb thread debugging systems tend to export a set of variables from > > the thread library which describe the important offsets in the thread > > structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset > > etc. > > > If you think there will be a real problem, I could do this I guess. > > Maybe we should just isolate the things that gdb is allowed to look at > and document them as "cast in stone". Why don't we make a libc_r_db and provide the necessary interfaces to gdb from that instead of having gdb know about uthread internals? Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: simple (but important) task for junior kernel hacker
Yes, I fixed that a few hours ago. In message , v ortexia writes: >Hrmmm have any commits been made on this one yet? The reason Im asking is >that as of about 2am my time last night I cvsupped to 4.0-CURRENT and I >cant build, it dies on libkvm. > >It claims the error exists in /usr/src/sys/sys/vnode.h, exact error >message as follows: > >In file included from /usr/src/lib/libkvm/kvm_getswapinfo.c:22: >/usr/src/lib/libkvm/../../sys/sys/vnode.h:186: parse error before `udev_t' >/usr/src/lib/libkvm/../../sys/sys/vnode.h:186: warning: no semicolon at >end of struct or union >/usr/src/lib/libkvm/../../sys/sys/vnode.h:191: parse error before `:' >cc -nostdinc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm/../../sys >-I/usr/obj/usr/src/tmp/usr/include -c /usr/src/lib/libkvm/kvm_proc.c -o >kvm_proc.o >cc -fpic -DPIC -nostdinc -O -pipe -DLIBC_SCCS >-I/usr/src/lib/libkvm/../../sys -I/usr/obj/usr/src/tmp/usr/include -c >/usr/src/lib/libkvm/kvmproc.c -o kvm_proc.So >*** Error code 1 >*** Error code 1 >2 errors > >(I think this is right, I had to type it out but I think I got it ok). > >Any ideas? > >Cheers > >Andrew > > On Wed, 12 May 1999, Poul-Henning Kamp wrote: > >> In message <19990512034529.a5...@phc.igs.net>, Robert Garrett writes: >> >> >> There is a dev_t passed out to pstat -s in a datastructure. >> > >> >Right and thats where it comes from kvm_proc.c is responsible for >> >dealing with pstat at least the way I read that file >> >> pstat >-s< is what we're talking about right now. >> >> -- >> Poul-Henning Kamp FreeBSD coreteam member >> p...@freebsd.org "Real hackers run -current on their laptop." >> FreeBSD -- It will take a long time before progress goes too far! >> >> >> To Unsubscribe: send mail to majord...@freebsd.org >> with "unsubscribe freebsd-current" in the body of the message >> > > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Daniel Eischen wrote: > Why don't we make a libc_r_db and provide the necessary interfaces to > gdb from that instead of having gdb know about uthread internals? It would still mean that gdb would be linked to the uthread internals which may not match the version of libc_r that the 3rd party program was linked against. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: somebody has broken sysctlbyname() in -current
Andrzej Bialecki wrote: > On Sat, 8 May 1999, Peter Wemm wrote: > >> It's interesting that the ANSI emulation in loader(8) is good enough to >> do full-screen displays. It still seems to make sense to move >> userconfig-like functionality into the pre-kernel stages including >> moving config(8)'s hints to a loaded and parsed file. Forth, bah.. :-] > > Heh... To tell you the truth, that was my initial dream which prompted me > to start writing it. It could be done now, really... Right at this moment, I would like to have a simple boot menu: I have both -stable and -current on a single drive (different partitions), and I'd like to select which to boot with a single key stroke. Any pointer on Forth literature/web pages would be appreciated, especially if it's not the ANSI standard (I've looked at it, and it is that: a standard, not a reference manual or a tutorial). My Forth knowledge is rather rusty, I realised... last time I remember I was sitting in front of my Apple II clone about 15 years ago. Stefan -- Mühlendamm 12 | Voice +49-40-256848, +49-177-3504009 D-22089 Hamburg | e-mail: stefan.bet...@hanse.de Germany | s...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
John Birrell wrote: > Daniel Eischen wrote: > > Why don't we make a libc_r_db and provide the necessary interfaces to > > gdb from that instead of having gdb know about uthread internals? > > It would still mean that gdb would be linked to the uthread internals > which may not match the version of libc_r that the 3rd party program > was linked against. OK, but it still seems more appropriate to have uthread debugging internals known somewhere other than in GDB. It seems more obvious to have to modify libc_r_db when libc_r changes than to know to update the gdb sources. If threads had versioning information as well as trying to set certain attributes in stone, then libc_r_db could be made to be backwards compatible with older thread libraries. Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: problem with NewScroll Mouse, etc
We , 12 may 1999, Steve O'Hara-Smith wrote: > > 1. something is wrong with psm0 driver. my Genius NewScroll PS/2 > > mouse works > > well, but in random moment when i touch the mouse kernel starts to > > write to the > > system log the following. > > > > Apr 29 11:55:58 camel /kernel: psmintr: out of sync (00c8 != 0008). > > Apr 29 11:55:58 camel /kernel: psmintr: out of sync (00c0 != 0008). > > > > when it happens, mouse cursor moves, but buttons do not work. only > > reboot solves this problem. even full restart of moused doesn't help. very strange bug. NewScroll seems to be fully compatible with Microsoft PS/2 mouse protocol, and a problem with it appears under FreeBSD only. -- sincerely, ilya naumov (at work) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Today's kernel crashes on starting X
I'm currently running into a problem, that when I start my system, it spontaneously reboots when starting X. Has anyone else run into this? -- Geoff Rehmet, The Internet Solution - Infrastructure tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: geo...@is.co.za URL: http://www.is.co.za To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
On 12-May-99 Ustimenko Semen wrote: > > Are we going to get this license? I am interested in NTFS > source code a lot... > > P.S. What's happening with MS? > They have got a virus. I think they're calling it Open Source... They're fighting really hard to get rid of it, but these things can happen from time to time :) -- +---+ Erik H. Bakke, Habatech AS | To be or not to be... | E-Mail: e...@habatech.no| Is simply a question of binary logic. | Consultancy, Development, Sales | | +---+ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
vinum broken??
Hi, Does anyone else experience problems with the current kernel release and vinum? I've compiled a new kernel along with a make world today. After rebooting vinum did not start: "/dev/vinum/Control: invalid operation..." Any suggestions? regards, Christian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
DMA problems with IBM DeskStar drive
I have a brand new 10 GB IBM UltrStar (DTTA-371010) which is causing me some pains. If I boot with flags 0x80ff, everything works fine: wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): , 32-bit, multi-block-16 wd0: 9641MB (19746720 sectors), 19590 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (wd2): , 32-bit, multi-block-16 wd2: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S but heavy disk access slows the machine to a crawl, as can be expected from any device that does heavy PIO. If I try to boot with flags 0xa0ff to enable DMA, however, this is what I get: wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 9641MB (19746720 sectors), 19590 cyls, 16 heads, 63 S/T, 512 B/S wd0: ATA INQUIRE valid = 0007, dmamword = 0007, apio = 0003, udma = 0407 wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (wd2): , DMA, 32-bit, multi-block-16 wd2: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S wd2: ATA INQUIRE valid = 0007, dmamword = 0007, apio = 0003, udma = 0407 [...] Considering FFS root f/s. changing root device to wd0s4a changing root device to wd0a start_init: trying /sbin/init wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 wd2s1: type 0xa5, start 0, end = 4124735, size 4124736 : OK xl0: selecting BNC port, half duplex wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 and a *lot* more of those. Nothing bad seems to hapen (no fs corruption or anything). In fact, I managed to recompile a kernel while this was going on. The Seagate disk (wd2) causes no trouble at all, DMA or no DMA. The problem occurs in both -STABLE and -CURRENT. I've attached a complete kernel config and verbose boot log. DES -- Dag-Erling Smorgrav - d...@yes.no # Kernel configuration for des.follo.net machine i386 cpu I586_CPU cpu I686_CPU ident DES maxusers32 makeoptions DEBUG=-g options COMPAT_43 options FFS options FFS_ROOT options ICMP_BANDLIM options INCLUDE_CONFIG_FILE options INET options IPFIREWALL options IPFIREWALL_VERBOSE options KTRACE options PROCFS options SOFTUPDATES options SYSVMSG options SYSVSEM options SYSVSHM options UCONSOLE options USERCONFIG options VESA options VISUAL_USERCONFIG options VM86 config kernel root on wd0 controller isa0 controller pci0 controller pnp0 controller fdc0at isa? port IO_FD1 irq 6 drq 2 diskfd0 at fdc0 drive 0 controller wdc0at isa? port IO_WD1 irq 14 controller wdc1at isa? port IO_WD2 irq 15 diskwd0 at wdc0 drive 0 flags 0xa0ff diskwd2 at wdc1 drive 0 flags 0xa0ff controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0at atkbdc? irq 12 device vga0at isa? port ? conflicts pseudo-device splash device sc0 at isa? options MSGBUF_SIZE=32768 options SC_HISTORY_SIZE=1024 device npx0at nexus? port IO_NPX irq 13 device apm0at isa? device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 device ppc0at isa? port? irq 7 controller ppbus0 device lpt0at ppbus? device plip0 at ppbus? device ppi0at ppbus? device xl0 pseudo-device loop pseudo-device ether pseudo-device tun 4 pseudo-device bpfilter 4 pseudo-device pty 64 pseudo-device vn 4 device pcm0at isa? port? irq 5 drq 1 flags 0x0 Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun May 9 19:00:44 CEST 1999 r...@des.follo.net:/usr/src/sys/compile/DES Calibrating clock(s) ... TSC clock: 350799158 Hz, i8254 clock: 1193196 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping=12 Features=0x8021bf Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 128M bytes Write Allocate 15-16M bytes: Enable real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages)
Re: cvs commit: src/sys/pci pcisupport.c
> On Wed, 12 May 1999 09:35:36 -0400, "Rick Whitesel" said: > In general I believe that dynamic configuration of the system is > extremely useful to both the development community and the user > community. The development community has a much easier time if they > can load / unload drivers. As for the users, my rule of thumb is > that a computer should never ask a human the answer to a question > that it can find out for itself. I think this is especially true for > configuration information. In addition, the need for dynamic system > (re)configuration will only increase as features like PCI hot swap > become the standard. Of course, I completely agree with you. The reason I prefer newconfig is it actually can support dynamic configuration better than the new-bus. All features which new-bus has can be implemented on newconfig, too. And, more. (See the description about on-demand dynamic loading in my previous post.) Furthremore, newconfig does static configuration better than the new-bus, and newconfig has a option which removes dynamic configuration entirely from kernel. New-bus apparently doesn't have this option. So, which is flexible ? :-) -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Hi: While I confess to not having the whole picture here, I do, of course, have an opinion. In general I believe that dynamic configuration of the system is extremely useful to both the development community and the user community. The development community has a much easier time if they can load / unload drivers. As for the users, my rule of thumb is that a computer should never ask a human the answer to a question that it can find out for itself. I think this is especially true for configuration information. In addition, the need for dynamic system (re)configuration will only increase as features like PCI hot swap become the standard. Rick Whitesel Scientist NBase-Xyplex Eml: rwhite...@nbase-xyplex.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 - Original Message - From: Noriyuki Soda To: Cc: Sent: Wednesday, May 12, 1999 5:01 AM Subject: Re: cvs commit: src/sys/pci pcisupport.c NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing list, because I am a NetBSD user. :-) > > It depends on old-config, so poor mechanism. newconfig already > > implimented best match probe/attach. > > And a very useful mechanism it is. Which is why I implemented priority > ordered probes in -current. Hmm, I thought this cannot be done correctly on new-bus, because the new-bus kicks match/attach routine from SYSINIT(). It is apparent that this fails in dynamic configuration case, because a potencial candidate of drivers which is dynamically loaded first always matches. This behaviour can not be called as "best match", but "first match". :-) Of course, dynamic configuration of newconfig solves this problem. Was this behaviour of the new-bus changed in -current ? BTW, there are many fundamental design flaws in new-bus, so I don't think new-bus is comparable with newconfig, yet, even if priority probe is implemented. For example: - newconfig can cope with both static configuration and dynamic configuration. new-bus can handle dynamic configuration only. This is because critical information for configuration is represented in C source internally. e.g. The bus/device hierarchy information is embedded in DRIVER_MODULE() on new-bus. On newconfig, such information is represented externally in "files" file. Thus the information can be used in both static and dynamic configuration case. As a result, newconfig can support same configuration syntax in both static and dynamic configuration, the new-bus never can do it. - new-bus cannot support on-demand device driver loading, dynamic configuration for newconfig can do it, though. This is because new-bus doesn't have the way to represent meta information like a mapping from device name to driver filename. If new-bus have this, there is no need to specifiy "kldload if_fxp", but just say "I need fxp0", then configuration framework can automatically load fxp driver, if it is not loaded yet. This is how configuration works in both newconfig and even oldconfig (look at static kernel configuration file for oldconfig, there is the line "device fxp0" which demands fxp driver to be loaded). The way to specify a driver to be linked on new-bus is retrogression to the age before 4.0BSD (4.0BSD introduced oldconfig and it was released on 1980 :-)). Why does a user have to specify file name instead of device name? Mmmm, perhaps do new-bus people believe MS-DOSism or Linuxism? :-) The way on new-bus will cause compatibility problem when OS is upgraded, because the implementation (filename) may be changed between versions and versions. - new-bus heavily depends on oldconfig which is known to be obsolete and machine dependent (look at usr.sbin/config/config.y, there are many definitions which depends on ISA bus, e.g. PORT, IOMEM, IOSIZE, ... newconfig can defines such attributes dynamically on demand.), and lacks many features which newconfig already has. e.g. - configruration hint which can be accessed from static configuration - bus/device hierarchy information which can be accessed from static configuration - inter module dependency information based on module attributes. new-bus completely lacks this feature, and depends on oldconfig about this. - mapping information from device name to object file name. new-bus completely lacks this feature, and depends on old config about this. Therefore, FreeBSD eventually will have to choose one of the following candidates: [a] gives up static configuration. But this doesn't solve the following problems: - at least console driver should be linked statically, unless you statically link this, you cannot get the error about dynamic loading critical drivers. :-) - in some applications, static configuration is good enough and dynamic configuration is merely overkill. FreeBSD will not cope with these applications better. Furthermore, this doesn't solves the problems about inter
Re: DMA problems with IBM DeskStar drive
I just got a 18GB "22GXP" model from IBM and saw the same thing on my -stable box. >start_init: trying /sbin/init >wd0: DMA failure, DMA status 5 >wd0: DMA failure, DMA status 5 >wd0: DMA failure, DMA status 5 >wd0: DMA failure, DMA status 5 -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DMA problems with IBM DeskStar drive
It seems Dag-Erling Smorgrav wrote: > I have a brand new 10 GB IBM UltrStar (DTTA-371010) which is causing > me some pains. If I boot with flags 0x80ff, everything works fine: Hmm, I have one of those, it works wonderfully with my ata driver... So try to use that instead, it should work then... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Today's kernel crashes on starting X
At 02:35 PM 5/12/99 +0200, Geoff Rehmet wrote: I'm currently running into a problem, that when I start my system, it spontaneously reboots when starting X. Has anyone else run into this? I had the same thing happen last night, after building a new kernel and rebooting. I had to go back to a kernel made yesterday morning to get a working machine. No debugger or anything just automatic reboot. INTEL PR440FX motherboard SMP with DPT controller Manfred = ||man...@pacbell.net || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DMA problems with IBM DeskStar drive
In message <199905121351.paa51...@freebsd.dk>, Soren Schmidt writes: >It seems Dag-Erling Smorgrav wrote: >> I have a brand new 10 GB IBM UltrStar (DTTA-371010) which is causing >> me some pains. If I boot with flags 0x80ff, everything works fine: > >Hmm, I have one of those, it works wonderfully with my ata driver... >So try to use that instead, it should work then... Try disabling "ultra DMA" in the BIOS, that seems to have worked for me on my IBM-DJNA-371800 drive. (Jordan: We may want to put something in the README about this in 3.2!) -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DMA problems with IBM DeskStar drive
Soren Schmidt writes: > Hmm, I have one of those, it works wonderfully with my ata driver... > So try to use that instead, it should work then... I'll try that. OBTW, the following comment in LINT is a little weird: # You only need one "controller ata0" for it to find all # PCI devices on modern machines. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DMA problems with IBM DeskStar drive
Poul-Henning Kamp writes: > Try disabling "ultra DMA" in the BIOS, that seems to have worked for > me on my IBM-DJNA-371800 drive. Thanks, I'll try that if the ata driver doesn't work. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
On Wed, 12 May 1999, Daniel Eischen wrote: > John Birrell wrote: > > Daniel Eischen wrote: > > > Why don't we make a libc_r_db and provide the necessary interfaces to > > > gdb from that instead of having gdb know about uthread internals? > > > > It would still mean that gdb would be linked to the uthread internals > > which may not match the version of libc_r that the 3rd party program > > was linked against. > > OK, but it still seems more appropriate to have uthread debugging > internals known somewhere other than in GDB. It seems more obvious > to have to modify libc_r_db when libc_r changes than to know to > update the gdb sources. > > If threads had versioning information as well as trying to set > certain attributes in stone, then libc_r_db could be made to > be backwards compatible with older thread libraries. GDB's needs are rather simple. It needs to know the current thread, be able to enumerate all threads, and access the saved register set of a non-current thread. I don't want to over-engineer the thing given that writing the gdb side of things was actually pretty simple. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
On Wed, 12 May 1999, John Birrell wrote: > Doug Rabson wrote: > > I think the only state which I need to know about is PS_DEAD. If we marked > > dead threads in the public struct it might simplify things. > > You use PS_RUNNING too. We could just tie down those two as PS_DEAD = 0 > and PS_RUNNING = 1. Ah. I thought I had changed that. The use of PS_RUNNING in store_registers is bogus, it should be checking against _thread_run. The whole function get_thread_info is pretty bogus too and it is never called by gdb as far as I can tell. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
panic ! panic ! panic !
After make world this morning I received this panic : Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0155ca4 stack pointer = 0x10:0xc6864d64 frame pointer = 0x10:0xc6864d78 code segment = base 0x0, limit 0xf, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume , IOPL=0 current process = 374 (screen-3.7.6) interrupt mask = tty trap number = 12 panic: page fault I receive this panic with "screen", but before I kept this box resetting itself trying to enter in X... and I was trying Xfree 3.3.3.1 (recompiled and reinstalled) SVGA, Metrolink and Xaccel 5.0 . But I could not seen the panic probably due to X loading. Here are some infos : Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Wed May 12 13:03:16 CEST 1999 r...@gmarco.eclipse.org:/usr/src/sys/compile/GMARCO Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 400911064 Hz CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping=1 Features=0x183f9ff real memory = 134217728 (131072K bytes) avail memory = 127868928 (124872K bytes) Preloaded elf kernel "kernel" at 0xc02ae000. Pentium Pro MTRR support enabled, default memory type is uncacheable Probing for PnP devices: CSN 1 Vendor ID: CTL00c5 [0xc5008c0e] Serial 0x1a3b72f5 Comp ID: PNPb02f [0x2fb0d041] npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 11 at device 0.0 on pci1 isab0: at device 4.0 on pci0 chip1: at device 4.1 on pci0 chip2: at device 4.3 on pci0 ahc0: irq 14 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs de0: irq 10 at device 10.0 on pci0 de0: 21041 [10Mb/s] pass 1.1 de0: address 00:40:05:36:7a:72 isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 atkbdc0: at port 0x60 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: on isa0 sc0: on isa0 sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port de0: enabling 10baseT port Waiting 3 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers changing root device to da0s1a da2 at ahc0 bus 0 target 2 lun 0 da2: Removable Direct Access SCSI-2 device da2: 3.300MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) Kernel file : Identification ### machine "i386" cpu "I686_CPU" ident GMARCO maxusers32 # Misc Options options INET options FFS options NFS options PROCFS options FFS_ROOT options "COMPAT_43" options SCSI_DELAY=3000 options UCONSOLE options USERCONFIG options VISUAL_USERCONFIG options SOFTUPDATES options SYSVSHM options SYSVSEM options SYSVMSG # Controllers ## controller isa0 controller pci0 controller pnp0 # Floppy Disk ### controller fdc0at isa? port IO_FD1 irq 6 drq 2 diskfd0 at fdc0 drive 0 # Scsi subsystem controller ahc0 controller scbus0 device da0 device sa0 device cd0 ## Keyboard and screen ### controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0at atkbdc? irq 12 device vga0at isa? port ? conflicts device sc0 at isa? # Fpu device npx0at nexus? port IO_NPX irq 13 ## Serials Devs # device sio0at isa? port IO_COM1 irq 4 device sio1at isa? port IO_COM2 irq 3 ### Par bus ### device ppc0
Re: Today's kernel crashes on starting X
At 12/05/99, Manfred Antar wrote: >At 02:35 PM 5/12/99 +0200, Geoff Rehmet wrote: >>I'm currently running into a problem, that when I start my system, >>it spontaneously reboots when starting X. Has anyone else run into >>this? >I had the same thing happen last night, after building a new kernel and >rebooting. >I had to go back to a kernel made yesterday morning to get a >working machine. No debugger or anything just automatic reboot. >INTEL PR440FX motherboard SMP with DPT controller I had the same problem here also the program "screen" crashes happily... see my msg subj: panic ! Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Sometimes again SCSI don't finish to boot
In 4.0-current sometimes the box will froze again after the : "Waiting 3 seconds for SCSI devices to settle" then nothing happens. It was a thing happened also in early 1999, before the branch in 4.0-current and 3.1 stable, if I remember well. Any others experience such behaviour ? Here is again (part of) my infos: FreeBSD 4.0-CURRENT #0: Wed May 12 13:03:16 CEST 1999 r...@gmarco.eclipse.org:/usr/src/sys/compile/GMARCO Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 400911064 Hz CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping=1 Features=0x183f9ff real memory = 134217728 (131072K bytes) avail memory = 127868928 (124872K bytes) Preloaded elf kernel "kernel" at 0xc02ae000. Pentium Pro MTRR support enabled, default memory type is uncacheable Probing for PnP devices: pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 11 at device 0.0 on pci1 isab0: at device 4.0 on pci0 chip1: at device 4.1 on pci0 chip2: at device 4.3 on pci0 ahc0: irq 14 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs [...] Waiting 3 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers changing root device to da0s1a da2 at ahc0 bus 0 target 2 lun 0 da2: Removable Direct Access SCSI-2 device da2: 3.300MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) Kernel file : Identification ### machine "i386" cpu "I686_CPU" ident GMARCO maxusers32 # Misc Options options INET options FFS options NFS options PROCFS options FFS_ROOT options "COMPAT_43" options SCSI_DELAY=3000 options UCONSOLE options USERCONFIG options VISUAL_USERCONFIG options SOFTUPDATES options SYSVSHM options SYSVSEM options SYSVMSG # Controllers ## controller isa0 controller pci0 controller pnp0 # Floppy Disk ### controller fdc0at isa? port IO_FD1 irq 6 drq 2 diskfd0 at fdc0 drive 0 # Scsi subsystem controller ahc0 controller scbus0 device da0 device sa0 device cd0 ## Keyboard and screen ### controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0at atkbdc? irq 12 device vga0at isa? port ? conflicts device sc0 at isa? # Fpu device npx0at nexus? port IO_NPX irq 13 ## Serials Devs # device sio0at isa? port IO_COM1 irq 4 device sio1at isa? port IO_COM2 irq 3 ### Par bus ### device ppc0at isa? port? flags 0x40 irq 7 controller ppbus0 device lpt0at ppbus? ### Ether # device de0 ### Luigi's drivers ### devicepcm0 at isa? port 0x220 irq ? drq ? flags 0x15 ## Misc Device ## pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device tun 1 pseudo-device pty 16 pseudo-device gzip Sorry for the double posting of kernel and dmesg file (I also posted in my previous message about crashes). Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Hi: Since newconfig appears technically superior, what are the issues that are hindering its acceptance? Rick Whitesel - Original Message - From: Noriyuki Soda To: Rick Whitesel Cc: Noriyuki Soda ; Sent: Wednesday, May 12, 1999 9:41 AM Subject: Re: cvs commit: src/sys/pci pcisupport.c > On Wed, 12 May 1999 09:35:36 -0400, "Rick Whitesel" said: > In general I believe that dynamic configuration of the system is > extremely useful to both the development community and the user > community. The development community has a much easier time if they > can load / unload drivers. As for the users, my rule of thumb is > that a computer should never ask a human the answer to a question > that it can find out for itself. I think this is especially true for > configuration information. In addition, the need for dynamic system > (re)configuration will only increase as features like PCI hot swap > become the standard. Of course, I completely agree with you. The reason I prefer newconfig is it actually can support dynamic configuration better than the new-bus. All features which new-bus has can be implemented on newconfig, too. And, more. (See the description about on-demand dynamic loading in my previous post.) Furthremore, newconfig does static configuration better than the new-bus, and newconfig has a option which removes dynamic configuration entirely from kernel. New-bus apparently doesn't have this option. So, which is flexible ? :-) -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
> After make world this morning I received this panic : > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x14 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0155ca4 > stack pointer = 0x10:0xc6864d64 > frame pointer = 0x10:0xc6864d78 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume , IOPL=0 > current process = 374 (screen-3.7.6) > interrupt mask = tty > trap number = 12 > panic: page fault > > I receive this panic with "screen", but before I kept this box resetting > itself trying to enter in X... and I was trying Xfree 3.3.3.1 (recompiled > and reinstalled) SVGA, Metrolink and Xaccel 5.0 . But I could not seen the > panic probably due to X loading. > Could you show us the symbols around the faulting instruction at 0xc0155ca4? It would be even better if you have a crash dump and the gdb backtrace. -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Scanners
Tomer Weller wrote: > i got a new UMAX Atrsa 1220P scanner, i have no idea how to configure this in > FreeBSD or Linux (or if i even can), im on 4.0-CURRENT. > == > Tomer Weller > s...@i.am > well...@netvision.net.il > "Drugs are good, and if you do'em > pepole think that you're cool", NoFX > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message Have you tried /usr/ports/graphics/sane? ed To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
At 12/05/99, you wrote: >> >Could you show us the symbols around the faulting instruction at 0xc0155ca4? >It would be even better if you have a crash dump and the gdb backtrace. Pardon, but I am not be able to figure by myself what you asked to me... If you can explain me step by step in a newbie way I can do everything ... The crashes is easily reproducible... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
In message <003001be9c88$2669b620$d3e4b...@xyplex.com>, "Rick Whitesel" writes : >Hi: >Since newconfig appears technically superior, what are the issues that >are hindering its acceptance? That we want to have no "config" at all. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
mbuf starvation
I'm trying to plug some of the holes not checking for mbuf shortage.
In particular, there are the following unchecked calls to MGET and
friends in /sys/kern/uipc_socket.c:sosend() (see patches below).
Would anyone mind if I commit these? I won't be able to commit
these before next Sunday evening, so if anyone deems these to be
useful, he's welcome to commit before then.
Another big problem is that there's a check in m_retry and friends
that panics when falling short of mbufs! I really believe this does
more harm than good, because it prevents correct calling code
(checking for NULL mbuf pointers) from exiting gracefully with
ENOBUFS...
These could most certainly help with 3.2-RELEASE too. Same problem,
I won't be able to do anything more before Sunday.
--- uipc_socket.c.orig Wed May 5 16:48:57 1999
+++ uipc_socket.c Wed May 12 16:55:27 1999
@@ -497,15 +497,27 @@
} else do {
if (top == 0) {
MGETHDR(m, M_WAIT, MT_DATA);
+ if (m == 0) {
+ error = ENOBUFS;
+ goto release;
+ }
mlen = MHLEN;
m->m_pkthdr.len = 0;
m->m_pkthdr.rcvif = (struct ifnet *)0;
} else {
MGET(m, M_WAIT, MT_DATA);
+ if (m == 0) {
+ error = ENOBUFS;
+ goto release;
+ }
mlen = MLEN;
}
if (resid >= MINCLSIZE) {
MCLGET(m, M_WAIT);
+ if (m == 0) {
+ error = ENOBUFS;
+ goto release;
+ }
if ((m->m_flags & M_EXT) == 0)
goto nopages;
mlen = MCLBYTES;
@@ -617,6 +629,8 @@
flags = 0;
if (flags & MSG_OOB) {
m = m_get(M_WAIT, MT_DATA);
+ if (m == 0)
+ return (ENOBUFS);
error = (*pr->pr_usrreqs->pru_rcvoob)(so, m, flags & MSG_PEEK);
if (error)
goto bad;
--- uipc_mbuf.c.origFri Apr 30 12:33:50 1999
+++ uipc_mbuf.c Wed May 12 17:05:02 1999
@@ -263,10 +263,7 @@
if (m != NULL) {
mbstat.m_wait++;
} else {
- if (i == M_DONTWAIT)
- mbstat.m_drops++;
- else
- panic("Out of mbuf clusters");
+ mbstat.m_drops++;
}
return (m);
}
@@ -291,10 +288,7 @@
if (m != NULL) {
mbstat.m_wait++;
} else {
- if (i == M_DONTWAIT)
- mbstat.m_drops++;
- else
- panic("Out of mbuf clusters");
+ mbstat.m_drops++;
}
return (m);
}
--
Pierre Beyssac p...@enst.fr
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Sometimes again SCSI don't finish to boot
> ahc0: irq 14 at device 6.0 on pci0 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > [...] > Waiting 3 seconds for SCSI devices to settle > sa0 at ahc0 bus 0 target 6 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 3.300MB/s transfers > changing root device to da0s1a > da2 at ahc0 bus 0 target 2 lun 0 > da2: Removable Direct Access SCSI-2 device > da2: 3.300MB/s transfers > da2: Attempt to query device size failed: NOT READY, Medium not present > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing > Enabled > da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing > Enabled > da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) you've got two Ultra mode devices (disks) on the same bus as a Async mode device (the tape drive). In theory it's possible to mix Ultra and non-ultra devices and I have certainly done so, but you might want to try your setup without the tape drive attached. -matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
From: Poul-Henning Kamp Subject: Re: cvs commit: src/sys/pci pcisupport.c Date: Wed, 12 May 1999 17:17:49 +0200 Message-ID: <5598.926522...@critter.freebsd.dk> phk> In message <003001be9c88$2669b620$d3e4b...@xyplex.com>, "Rick Whitesel" writes phk> : phk> >Hi: phk> >Since newconfig appears technically superior, what are the issues that phk> >are hindering its acceptance? phk> phk> That we want to have no "config" at all. That is too short an answer. What is the definition of "config"? Why do you want to remove it? Newconfig people is in agreement that old config should be removed. But newconfig is a different thing. Newconfig should be satisfactory for the purpose you remove the old config. Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mbuf starvation
Pierre Beyssac wrote: > Another big problem is that there's a check in m_retry and friends > that panics when falling short of mbufs! I really believe this does > more harm than good, because it prevents correct calling code > (checking for NULL mbuf pointers) from exiting gracefully with > ENOBUFS... I've discussed this with Garett back in September. The reason is quite simple: unless all cases of not checking for a NULL pointer returned are fixed (or instrumented with a panic), it is better to fail with a panic than with some obscure problem later on. Stefan -- Mühlendamm 12 | Voice +49-40-256848, +49-177-3504009 D-22089 Hamburg | e-mail: stefan.bet...@hanse.de Germany | s...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
>phk> >Since newconfig appears technically superior, what are the issues >that >phk> >are hindering its acceptance? >phk> >phk> That we want to have no "config" at all. > >That is too short an answer. No, it is complete and to the point. >What is the definition of "config"? config(8) >Why do you want to remove it? Why should we, as a 3rd millenium OS need a static config tool ? Tell me which future technology we will need to handle which will require static config ? We are working on FreeBSD as a OS for the future, not for the past. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
Luoqi Chen writes : I'm trying to get a crash dump myself, but the kernel I have right now, is screwing up my keyboard, and I cannot even log in! I will try again. Geoff. > > After make world this morning I received this panic : > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x14 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc0155ca4 > > stack pointer = 0x10:0xc6864d64 > > frame pointer = 0x10:0xc6864d78 > > code segment = base 0x0, limit 0xf, type 0x1b > > = DPL0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume , IOPL=0 > > current process = 374 (screen-3.7.6) > > interrupt mask = tty > > trap number = 12 > > panic: page fault > > > > I receive this panic with "screen", but before I kept this box resetting > > itself trying to enter in X... and I was trying Xfree 3.3.3.1 (recompiled > > and reinstalled) SVGA, Metrolink and Xaccel 5.0 . But I could not seen the > > panic probably due to X loading. > > > Could you show us the symbols around the faulting instruction at 0xc0155ca4? > It would be even better if you have a crash dump and the gdb backtrace. > > -lq > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > -- Geoff Rehmet, The Internet Solution geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org tel: +27-83-292-5800 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
At least put DDB in your kernel, type "trace" when it panics and tell us what it says. In message <19990512154854.78032.qm...@rucus.ru.ac.za>, "Geoff Rehmet" writes: >Luoqi Chen writes : > >I'm trying to get a crash dump myself, but the kernel I have >right now, is screwing up my keyboard, and I cannot even log >in! >I will try again. > >Geoff. >> > After make world this morning I received this panic : >> > >> > Fatal trap 12: page fault while in kernel mode >> > fault virtual address = 0x14 >> > fault code = supervisor read, page not present >> > instruction pointer = 0x8:0xc0155ca4 >> > stack pointer = 0x10:0xc6864d64 >> > frame pointer = 0x10:0xc6864d78 >> > code segment = base 0x0, limit 0xf, type 0x1b >> > = DPL0, pres 1, def32 1, gran 1 >> > processor eflags = interrupt enabled, resume , IOPL=0 >> > current process = 374 (screen-3.7.6) >> > interrupt mask = tty >> > trap number = 12 >> > panic: page fault >> > >> > I receive this panic with "screen", but before I kept this box resetting >> > itself trying to enter in X... and I was trying Xfree 3.3.3.1 (recompiled >> > and reinstalled) SVGA, Metrolink and Xaccel 5.0 . But I could not seen the >> > panic probably due to X loading. >> > >> Could you show us the symbols around the faulting instruction at 0xc0155ca4? >> It would be even better if you have a crash dump and the gdb backtrace. >> >> -lq >> >> >> To Unsubscribe: send mail to majord...@freebsd.org >> with "unsubscribe freebsd-current" in the body of the message >> > > >-- >Geoff Rehmet, >The Internet Solution >geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org >tel: +27-83-292-5800 > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: panic ! panic ! panic !
Only one problem with that - screen and keyboard are not responding when it panics. I'm hoping that I will be able to get a dump which I can look at post mortem. I'm going to try again though. The kernel I have at the moment is totally messing up my keyboard, and I cannot even get a single user login! Geoff. > -Original Message- > From: Poul-Henning Kamp [mailto:p...@critter.freebsd.dk] > Sent: 12 May 1999 05:56 > To: Geoff Rehmet > Cc: lu...@watermarkgroup.com; curr...@freebsd.org > Subject: Re: panic ! panic ! panic ! > > > > At least put DDB in your kernel, type "trace" when it > panics and tell us what it says. > > In message <19990512154854.78032.qm...@rucus.ru.ac.za>, > "Geoff Rehmet" writes: > >Luoqi Chen writes : > > > >I'm trying to get a crash dump myself, but the kernel I have > >right now, is screwing up my keyboard, and I cannot even log > >in! > >I will try again. > > > >Geoff. > >> > After make world this morning I received this panic : > >> > > >> > Fatal trap 12: page fault while in kernel mode > >> > fault virtual address = 0x14 > >> > fault code = supervisor read, page not present > >> > instruction pointer = 0x8:0xc0155ca4 > >> > stack pointer = 0x10:0xc6864d64 > >> > frame pointer = 0x10:0xc6864d78 > >> > code segment = base 0x0, limit 0xf, type 0x1b > >> > = DPL0, pres 1, def32 1, gran 1 > >> > processor eflags = interrupt enabled, resume , IOPL=0 > >> > current process = 374 (screen-3.7.6) > >> > interrupt mask = tty > >> > trap number = 12 > >> > panic: page fault > >> > > >> > I receive this panic with "screen", but before I kept > this box resetting > >> > itself trying to enter in X... and I was trying Xfree > 3.3.3.1 (recompiled > >> > and reinstalled) SVGA, Metrolink and Xaccel 5.0 . But I > could not seen the > >> > panic probably due to X loading. > >> > > >> Could you show us the symbols around the faulting > instruction at 0xc0155ca4? > >> It would be even better if you have a crash dump and the > gdb backtrace. > >> > >> -lq > >> > >> > >> To Unsubscribe: send mail to majord...@freebsd.org > >> with "unsubscribe freebsd-current" in the body of the message > >> > > > > > >-- > >Geoff Rehmet, > >The Internet Solution > >geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org > >tel: +27-83-292-5800 > > > > > >To Unsubscribe: send mail to majord...@freebsd.org > >with "unsubscribe freebsd-current" in the body of the message > > > > -- > Poul-Henning Kamp FreeBSD coreteam member > p...@freebsd.org "Real hackers run -current on > their laptop." > FreeBSD -- It will take a long time before progress goes too far! > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mbuf starvation
On Wed, May 12, 1999 at 05:43:27PM +0200, Stefan Bethke wrote: > I've discussed this with Garett back in September. The reason is quite > simple: unless all cases of not checking for a NULL pointer returned are > fixed (or instrumented with a panic), it is better to fail with a panic > than with some obscure problem later on. Yes, I would agree in the general case, but in that particular case the reasonning is flawed: you panic every time, while there are many cases that currently are handled gracefully by the caller. In other words, you don't leave any choice to the caller. That's bad. IHMO it's not even a good thing in general because mbuf starvations can and _will_ happen as a normal condition, not because of bugs but because of high resource use. It can have its uses for debugging purposes, as a compilation option. -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: somebody has broken sysctlbyname() in -current
On Wed, 12 May 1999, Stefan Bethke wrote: > Any pointer on Forth literature/web pages would be appreciated, especially > if it's not the ANSI standard (I've looked at it, and it is that: a > standard, not a reference manual or a tutorial). My Forth knowledge is > rather rusty, I realised... last time I remember I was sitting in front of > my Apple II clone about 15 years ago. "Real-Time Forth" could be good for beginners... It's on the web somewhere. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
From: Poul-Henning Kamp Subject: Re: cvs commit: src/sys/pci pcisupport.c Date: Wed, 12 May 1999 17:45:45 +0200 Message-ID: <5756.926523...@critter.freebsd.dk> phk> phk> >phk> >Since newconfig appears technically superior, what are the issues that phk> >phk> >are hindering its acceptance? phk> >phk> phk> >phk> That we want to have no "config" at all. phk> > phk> >That is too short an answer. phk> phk> No, it is complete and to the point. phk> phk> >What is the definition of "config"? phk> phk>config(8) phk> phk> >Why do you want to remove it? phk> phk> Why should we, as a 3rd millenium OS need a static config tool ? Newconfig is a *dynamic* configuration tool. Replacing the old config with newconfig is sufficient for your reason to remove config. Why do you refuse newconfig if it is a better framework for dynamic configuration? Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> On Wed, 12 May 1999 17:45:45 +0200, Poul-Henning Kamp said: >> What is the definition of "config"? > config(8) >> Why do you want to remove it? > Why should we, as a 3rd millenium OS need a static config tool ? For example, - To specify the drivers which is linked statically to kernel. As I said earlier, you cannot link console driver dynamically, If you do this, you cannot get error message when dynamic linking of the console driver failed. - There should be a way to inform kernel about inter module dependency dynamically. config(8) converts this information to a file which is kernel readable format. - There should be a way to inform kernel about mapping from device name to driver filename dynamically. config(8) converts this information to a file which is kernel readable format. - To achieve better performance in both UP and SMP cases. Proper SMP implementation requires fine grained locking, though this increases performance penalty in UP case. (e.g. Solaris shows this problem.) Thus, the way to specify "options SMP" is needed to use (static) source level and compiler level optimization. This option should automatically select the appropriate sources which is compiled into kernel, according to the source is needed only in UP case, or only in SMP case, or both. This is what oldconfig and newconfig does. The new-bus doesn't have these features. > We are working on FreeBSD as a OS for the future, not for the past. Of course! We never should go back to the age of 1979 (i.e. before 4.0BSD). -- soda To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
At 12/05/99, you wrote: > >At least put DDB in your kernel, type "trace" when it >panics and tell us what it says. Ok... it's a bit long ... (Tell me there isn't a command to write the trace output on a disk :-) After the panic make by "screen" ... >trace Stopped at ttyflush+0x48: movl 0x14(%eax), %eax ttyflush (c025f2a0,3,c02601e0,c025f2a0,80047410) at ttyflush+0x48 ttioctl(c025f2a0,80047410,c6860ee4,3,c6860e20) at ttioctl+0x4a9 ptyioctl(f700,80047410,c6860e04,c01de031,c6860e20,c6860eb0) at spec_ioctl+0x44 spec_vnoperate(c686e20,c6860eb0,c0172821,c6860e20,0) at spec_vnoperate+0x15 ufs_vnoperatespec(c6860e20,0,c0a44cc0,4,c6860f90) at ufs_vnoperatespec+0x15 vn_ioctl(c0a44cc0,80047410,c6860ee4,c5de94a0) at vn_ioctl+0xdd ioctl(c5de94a0,c6860f90,28113874,806df09,8073720) at ioctl+0x1ef syscall(2f,2f,2f,8073720,806df09) at syscall+0x126 Xint0x80_syscall() at Xint 0x80_syscall+0x30 A nightmare ! :-) Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
At 12/05/99, you wrote: >Ok, what I'd like you to do is, run this command, > nm -n /kernel | more >the output is the list of symbols in the kernel sorted by their addresses >(the left-most column), page through the output, find symbols around the >address 0xc0155ca4, and send me those symbol names along with their addresses. c0154d2c T ptrace c0155244 T trace_req c0155250 T stopevent c01552ac t gcc2_compiled. c01552ac T rman_init c015534c T rman_manage_region c0155404 T rman_fini c015549c T rman_reserve_resource c015584c t int_rman_activate_resource c01558a4 T rman_activate_resource c01558bc T rman_await_resource c0155940 t int_rman_deactivate_resource c0155960 T rman_deactivate_resource c0155970 t int_rman_release_resource c0155b18 T rman_release_resource c0155b2c t gcc2_compiled. c0155b2c T soo_read c0155b50 T soo_write c0155b78 T soo_ioctl c0155cd8 T soo_poll c0155cf8 T soo_stat c0155d28 T soo_close c0155d4c t gcc2_compiled. c0155d4c T ipcperm c0155dd8 t gcc2_compiled. c0155dd8 t msginit c0155f3c T msgsys c0155f6c t msg_freehdr c0156010 T msgctl c01561f0 T msgget c015638c T msgsnd c015678c T msgrcv c0156aa0 t gcc2_compiled. c0156aa0 t seminit c0156b38 T semsys c0156b9c T semconfig c0156bfc t semu_alloc c0156cb4 t semundo_adjust c0156da8 t semundo_clear c0156e1c T __semctl c0157398 T semget c01575c4 T semop c0157988 T semexit c0157b00 t gcc2_compiled. c0157b00 t shm_find_segment_by_key but now the kernel is changed because I add options ddb so you are more interested in the old kernel that was up when the crahs happens : This is : c0154084 T shmctl c0154190 t shmget_existing c0154238 t shmget_allocate_segment c015442c T shmget c0154488 T shmsys c01544b8 T shmfork c0154538 T shmexit c0154598 t shminit c01545ec t gcc2_compiled. c01545ec T ttyopen c0154644 T ttyclose c01546c4 T ttyinput c0154df8 t ttyoutput c0154f5c T ttioctl c0155a70 T ttypoll c0155b1c T ttpoll c0155b50 t ttnread c0155b94 T ttywait c0155c34 t ttywflush c0155c5c T ttyflush c0155d68 T termioschars c0155d80 T ttychars c0155d94 T ttyblock c0155dd8 t ttyunblock c0155e1c T ttstart c0155e38 T ttylclose c0155e64 T ttymodem c0155f38 t ttypend c0155fa0 T ttread c0156560 T ttycheckoutq c015660c T ttwrite c01569a0 t ttyrub c0156b3c t ttyrubo c0156b78 t ttyretype c0156c54 t ttyecho c0156ce0 T ttwakeup c0156d30 T ttwwakeup c0156d9c T ttspeedtab c0156dc8 T ttsetwater c0156f40 T ttyinfo c0157100 t proc_compare c01571cc T tputchar c0157224 T ttysleep c0157260 t gcc2_compiled. c0157260 t ttcompatspeedtab c0157290 T ttsetcompat c0157484 T ttcompat c01576e8 t ttcompatgetflags c0157840 t ttcompatsetflags c015797c t ttcompatsetlflags c0157a9c t gcc2_compiled. c0157a9c T ldisc_register and the trace of ddb on panic (new kernel) generated by screen is : >trace Stopped at ttyflush+0x48: movl 0x14(%eax), %eax ttyflush (c025f2a0,3,c02601e0,c025f2a0,80047410) at ttyflush+0x48 ttioctl(c025f2a0,80047410,c6860ee4,3,c6860e20) at ttioctl+0x4a9 ptyioctl(f700,80047410,c6860e04,c01de031,c6860e20,c6860eb0) at spec_ioctl+0x44 spec_vnoperate(c686e20,c6860eb0,c0172821,c6860e20,0) at spec_vnoperate+0x15 ufs_vnoperatespec(c6860e20,0,c0a44cc0,4,c6860f90) at ufs_vnoperatespec+0x15 vn_ioctl(c0a44cc0,80047410,c6860ee4,c5de94a0) at vn_ioctl+0xdd ioctl(c5de94a0,c6860f90,28113874,806df09,8073720) at ioctl+0x1ef syscall(2f,2f,2f,8073720,806df09) at syscall+0x126 Xint0x80_syscall() at Xint 0x80_syscall+0x30 Hope it helps... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
mbuf starvation
< said: > Another big problem is that there's a check in m_retry and friends > that panics when falling short of mbufs! I really believe this does > more harm than good, because it prevents correct calling code > (checking for NULL mbuf pointers) from exiting gracefully with > ENOBUFS... I think we need to think a bit more about the right semantics before making such a change. M_WAIT is supposed to mean `I am in process context and don't mind sleeping in order to get an mbuf, but there is too much locking going on inside the network stack to be able to safely sleep without serious risk of deadlock. This is the sort of application which would be ideal for Matt's `asleep' interface. Then, the code could back its way out of any locks and spls, safely wait for sufficient mbufs to be freed, and then retry. Even then, it's still possible to deadlock if one process hogs the entire mbuf pool. It may be necessary to incrementally penalize processes which do so. FWIW, the 4.3 code sleeps in a loop. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Scanners
> > i got a new UMAX Atrsa 1220P scanner, i have no idea how to configure > > this in FreeBSD or Linux (or if i even can), im on 4.0-CURRENT. ..snip.. > Have you tried /usr/ports/graphics/sane? It doesn't build under 4.0-CURRENT. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Today's kernel crashes on starting X
Hello Geoff, Wednesday, May 12, 1999, 4:35:54 PM, you wrote: GR> I'm currently running into a problem, that when I start my system, GR> it spontaneously reboots when starting X. Has anyone else run into GR> this? yes, i'm experiencing the same problem with today's (May, 12) kernels. Best regards, Ilyamailto:ca...@avias.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: has the 3.2 branch happened?
Joe Abley writes: > (he asked :) As I understand it, 3.2 is simply a release tag on the already existing branch called RELENG_3 (aka 3.1-stable). So there will be no additional branch for 3.2, just a release tag: RELENG_3_2_0 or somesuch. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mbuf starvation
Pierre Beyssac writes:
> if (resid >= MINCLSIZE) {
> MCLGET(m, M_WAIT);
> + if (m == 0) {
> + error = ENOBUFS;
> + goto release;
> + }
> if ((m->m_flags & M_EXT) == 0)
> goto nopages;
> mlen = MCLBYTES;
I think this part of the patch is useless. MCLGET() does not set
m to NULL when it fails, it simply doesn't set the M_EXT flag.
...unless things have changed recently.
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Anybody actually using gigabit ethernet?
I bought two of the cards in order to decide whether or not I wanted to use them in my research group's PII cluster. Right now, they're plugged into a 233MHz Pentium Pro and a 400Mhz K6-2 (using an Aladdin V-based board). I did a bunch of NFS testing over the gigabit link last week and didn't see any glitches. The only "problems" that I've seen are (1) the round-trip latency for small UDP packets is at least 50% higher than FastEthernet on the same hardware and (2) the round-trip latency is highly variable. Alan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: dots in usernames?
Well, I did some reading through rfc821, and an email address is defined
as follows:
::= "@"
::= |
::= | "."
^^^ !
::= |
::= """ """
::= "\" | "\" | |
::= | "\"
::= any one of the 128 ASCII characters, but not any or
::= any one of the 128 ASCII characters (no exceptions)
::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." | "," | ";" |
":" | "@" """ | the control characters (ASCII codes 0 through 31
inclusive and 127)
(the above from ftp://passaic.cs.miami.edu/pub/rfc/rfc821.txt)
So if I've interpreted that right, .'s are indeed a legal part of the
local-part of email addresses (addresses with dots in 'em are also used in
various examples of that rfc); this would say to me that any mailer that
can't handle dots in the username should be considered non-RFC compliant.
I've bcc:'d freebsd-questions and cc:'d freebsd-current (which I'm not on,
btw) as I think the discussion is now headed in that direction.
People on -current: Just to recap, adduser (and rmuser) disallow .'s in
usernames on FreeBSD-stable; passwd(5) cites that some mailers have
problems with dots in usernames. However, they are becoming more common,
and are a legal part of rfc821. So what are people's thoughts on allowing
that in -current, and if there's no complaints, backporting it to -stable?
It seems really really trivial...
On Wed, 12 May 1999, Christopher Michaels wrote:
> That would be the e-mail message that I had in memory when I sent my reply.
> The way I see it, is if you've made the change and nothing's broken then why
> not! I think most of the wariness if from an earlier day when dots actually
> did break things. Now a days the mail software has to take into account
> that there ARE email addresses with dots in them.
>
> Maybe someone else on this list is better qualified to answer your question
> than I am, tho.
>
> I've noticed that most of the places that I've seen dots in user names are
> on Microsoft mail servers and windows NT logins. I personally have never
> seen them on a UNIX server. But again, just test it out and see what
> breaks, if nothing breaks then I don't see a problem with it.
>
> -Chris
>
> Anyone out there want to chime in as to why there shouldn't be dots in user
> names?
>
> > -Original Message-
> > From: Bob K [SMTP:mela...@yip.org]
> > Sent: Tuesday, May 11, 1999 6:36 PM
> > To: Christopher Michaels
> > Cc: freebsd-questi...@freebsd.org
> > Subject:RE: dots in usernames?
> >
> > Hmm. I searched freebsd-questions, and all I could come up with was the
> > following:
> >
> >
> > Date: Sun, 14 Mar 1999 21:39:39 +1000
> > From: Greg Black
> > To:Shawn Ramsey
> > Cc:Kelvin ,
> > freebsd-questi...@freebsd.org
> > Subject: Re: Question about login name
> > Message-ID: <19990314113940.12057.qm...@alpha.comkey.com.au>
> >
> > [snip]
> >
> > It's also worth reading the man page for passwd(5), in
> > particular the following partial paragraph:
> >
> > The login name must never begin with a hyphen (``-'');
> > also, it is strongly suggested that neither upper-case
> > characters nor dots (``.'') be part of the name, as this
> > tends to confuse mailers.
> >
> > And then ask yourself if you really *need* to use this kind of
> > login or if it's just something you'd like. If you don't really
> > need it (and there must be very few reasons why you might), you
> > would probably be better off not to do it.
> >
> > --
> > Greg Black
> >
> >
> > I'm just wondering how much of a problem this poses at this point; I'm
> > seeing more and more email addresses with dots in the username (not to say
> > that just because people do it means it's a good thing ;). Sendmail 8.9.2
> > certainly doesn't mind it, nor does Exim. Is there a list of mailers that
> > don't like this? Is there perhaps a more appropriate forum to ask this
> > sort of question?
> >
> > /me really should read manpages more often...
> >
> > On Tue, 11 May 1999, Christopher Michaels wrote:
> >
> > > My understanding of the situation is that you don't want dots in the
> > > usernames because it tends to confuse mailer programs (mainly).
> > > Unfortunately our web proxy isn't being very cooperative at work here
> > today
> > > and I can't lookup what I'm looking for in the archives.
> > >
> > > This was a top of discussion maybe a moth ago.
> > >
> > > -Chris
> > >
> > > > -Original Message-
> > > > From: Bob K [SMTP:mela...@yip.org]
> > > > Sent: Tuesday, May 11, 1999 11:42 AM
> > > > To: freebsd-questi...@freebsd.org
> > > > Subject:Re: dots in usernames?
> > > >
> > > > On Tue, 11 May 1999, Bob K wrote:
> > > >
> > > > > > will it break anything? I know I can add an alias; I'm just
> > hoping to
> > > > > > simplify things for the user in question. I suppose after doing
> > that,
> > > > a
> > > > > > make world & rebuild of any ports using utmp would be in order?
> > > > >
Re: Scanners
On Wed, May 12, 1999 at 10:28:45AM -0700, David O'Brien wrote:
> > > i got a new UMAX Atrsa 1220P scanner, i have no idea how to configure
> > > this in FreeBSD or Linux (or if i even can), im on 4.0-CURRENT.
> ..snip..
>
> > Have you tried /usr/ports/graphics/sane?
>
> It doesn't build under 4.0-CURRENT.
Had to fix this a few days ago anyway...
-Jeremy
--
| "I could be anything I wanted to, but one things true
--+-- Never gonna be as big as Jesus, never gonna hold the world in my hand
|Never gonna be as big as Jesus, never gonna build a promised land
|But that's, that's all right, OK with me..." -Audio Adrenaline
diff -urN -x CVS /usr/ports.ref/graphics/sane/patches/patch-01
graphics/sane/patches/patch-01
--- /usr/ports.ref/graphics/sane/patches/patch-01 Sun Dec 6 11:37:28 1998
+++ graphics/sane/patches/patch-01 Wed May 12 19:53:21 1999
@@ -5,7 +5,7 @@
# Use test -z because SunOS4 sh mishandles braces in ${var-val}.
# It thinks the first close brace ends the variable substitution.
-test -z "$INSTALL_PROGRAM" && INSTALL_PROGRAM='${INSTALL}'
-+test -z "$INSTALL_SCRIPT" && INSTALL_PROGRAM='${INSTALL}'
++test -z "$INSTALL_SCRIPT" && INSTALL_SCRIPT='${INSTALL}'
test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
diff -urN -x CVS /usr/ports.ref/graphics/sane/patches/patch-02
graphics/sane/patches/patch-02
--- /usr/ports.ref/graphics/sane/patches/patch-02 Tue May 26 10:17:59 1998
+++ graphics/sane/patches/patch-02 Wed May 12 19:56:24 1999
@@ -9,13 +9,12 @@
# Don't delete any intermediate files.
.PRECIOUS: %-s.c %-s.lo %.lo dll-preload.c
-@@ -94,16 +94,16 @@
+@@ -94,16 +94,13 @@
file=libsane-$${be}.so.$(V_MAJOR); \
lib=`grep dlname= libsane-$${be}.la | cut -f2 -d"'"`; \
- if test ! -f $${file} -a -n "$${lib}"; then \
+-if test ! -f $${file} -a -n "$${lib}"; then \
- ln -s $${lib} $${file}; \
-+ ln -sf $${lib} $${file}; \
- fi; \
+-fi; \
done
rm -f $(libdir)/libsane.a $(libdir)/libsane.so \
$(libdir)/libsane.so.$(V_MAJOR)*
diff -urN -x CVS /usr/ports.ref/graphics/sane/patches/patch-03
graphics/sane/patches/patch-03
--- /usr/ports.ref/graphics/sane/patches/patch-03 Wed Sep 16 23:37:56 1998
+++ graphics/sane/patches/patch-03 Wed May 12 19:52:36 1999
@@ -1,12 +0,0 @@
backend/Makefile.in.orig Thu Sep 17 05:03:21 1998
-+++ backend/Makefile.inThu Sep 17 05:16:13 1998
-@@ -93,9 +93,6 @@
- @list="$(ALL_BACKENDS)"; cd $(libsanedir) && for be in $$list; do \
- file=libsane-$${be}.so.$(V_MAJOR); \
- lib=`grep dlname= libsane-$${be}.la | cut -f2 -d"'"`; \
--if test ! -f $${file} -a -n "$${lib}"; then \
-- ln -sf $${lib} $${file}; \
--fi; \
- done
- rm -f $(libdir)/libsane.a $(libdir)/libsane.so \
- $(libdir)/libsane.so.$(V_MAJOR)*
diff -urN -x CVS /usr/ports.ref/graphics/sane/patches/patch-04
graphics/sane/patches/patch-04
--- /usr/ports.ref/graphics/sane/patches/patch-04 Thu Jan 28 23:31:39 1999
+++ graphics/sane/patches/patch-04 Wed May 12 19:58:04 1999
@@ -17,28 +17,28 @@
*)
$echo "$modename: unknown library version type \`$version_type'" 1>&2
echo "Fatal configuration error. See the $PACKAGE docs for more
information." 1>&2
ltconfig.orig Tue Nov 24 17:04:26 1998
-+++ ltconfig Tue Nov 24 17:07:35 1998
-@@ -1123,10 +1123,21 @@
+--- ltconfig.orig Sun Nov 22 05:53:55 1998
ltconfig Wed May 12 19:57:19 1999
+@@ -777,7 +777,7 @@
+ ;;
+
+ # FreeBSD 3, at last, uses gcc -shared to do shared libraries.
+- freebsd3*)
++ freebsd*)
+ archive_cmds='$CC -shared -o $lib$libobjs'
+ hardcode_libdir_flag_spec='-R$libdir'
+ hardcode_direct=yes
+@@ -1123,10 +1123,10 @@
finish_eval='for lib in `ls $libdir/*.ixlibrary 2>/dev/null`; do
libname=`$echo "X$lib" | $Xsed -e '\''s%^.*/\([^/]*\)\.ixlibrary$%\1%'\''`;
test $rm /sys/libs/${libname}_ixlibrary.a; $show "(cd /sys/libs && $LN_S $lib
${libname}_ixlibrary.a)"; (cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a)
|| exit 1; done'
;;
-freebsd2* | freebsd3*)
-+freebsd2*)
- version_type=sunos
- library_names_spec='${libname}${release}.so.$versuffix $libname.so'
- finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'
-+ shlibpath_var=LD_LIBRARY_PATH
-+ ;;
-+
-+freebsd3* | freebsd4*)
+- version_type=sunos
++freebsd*)
+ version_type=freebsd
-+ library_names_spec='${libname}${release}.so.$versuffix $libname.so'
-+ if [ $PORTOBJFORMAT = elf ]; then
-+ finish_cmds='PATH="\$PATH:/sbin" OBJFORMAT="$PORTOBJFORMAT" ldconfig -m
$libdir'
-+ else
-+ finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
-+ fi
+ library_names_spec='${libname}${release}.so.$versuffix $libname.so'
+- finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'
++ finish_cmds='PATH="\$PATH:/sbin" OBJFORMAT="'"$PORTOBJFORMAT"'" ldconfig -m
$li
RE: dots in usernames?
>Date: Wed, 12 May 1999 14:15:12 -0400 (EDT) >From: Bob K >People on -current: Just to recap, adduser (and rmuser) disallow .'s in >usernames on FreeBSD-stable; passwd(5) cites that some mailers have >problems with dots in usernames. However, they are becoming more common, >and are a legal part of rfc821. So what are people's thoughts on allowing >that in -current, and if there's no complaints, backporting it to -stable? >It seems really really trivial... Syntax for valid mailboxes need not correspond to (but should be a superset of, IMO) syntax for usernames. What's the problem you're trying to solve? Cheers, david -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: de driver problem
Wilko Bulte wrote: > PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl > Writing Makefile for DynaLoader > ==> Your Makefile has been rebuilt. <== > ==> Please rerun the make command. <== > false > false: not found > *** Error code 1 I periodically see this one reported, and It is always repaired by the reporter making sure their tree is _really_ clean before doing a make world. "Really clean" means "make cleandir" _twice_, and complete removal of the contents of /usr/obj. _Then_ cvsup. I prefer to usr CVS checkout, as it shows all the differences and other turds in my source tree. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: dots in usernames?
Bob K wrote: > Well, I did some reading through rfc821, and an email address is defined > as follows: Email addresses != Usernames. What this suggests to me is that having an _alias_ (say) Mark.Murray to markmurray in /etc/aliases is OK. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: dots in usernames?
On Wed, 12 May 1999, David Wolfskill wrote: > >Date: Wed, 12 May 1999 14:15:12 -0400 (EDT) > >From: Bob K > > >People on -current: Just to recap, adduser (and rmuser) disallow .'s in > >usernames on FreeBSD-stable; passwd(5) cites that some mailers have > >problems with dots in usernames. However, they are becoming more common, > >and are a legal part of rfc821. So what are people's thoughts on allowing > >that in -current, and if there's no complaints, backporting it to -stable? > >It seems really really trivial... > > Syntax for valid mailboxes need not correspond to (but should be a > superset of, IMO) syntax for usernames. > > What's the problem you're trying to solve? I'm hoping to simplify things for my users so that they don't need to have a different email address from their username if they have a dot in the local-part. mela...@yip.org - Mustard gas: The kids love it! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: dots in usernames?
In the last episode (May 12), Mark Murray said: > Bob K wrote: > > Well, I did some reading through rfc821, and an email address is > > defined as follows: > > Email addresses != Usernames. What this suggests to me is that having > an _alias_ (say) Mark.Murray to markmurray in /etc/aliases is OK. but, from the chown manpage: COMPATIBILITY Previous versions of the chown utility used the dot (`.') character to distinguish the group name. This has been changed to be a colon (`:') character so that user and group names may contain the dot character. So it sounds like the rest of the system is leaning toward allowing dots in usernames as well. -Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: dots in usernames?
On Wed, 12 May 1999, Mark Murray wrote: > Bob K wrote: > > Well, I did some reading through rfc821, and an email address is defined > > as follows: > > Email addresses != Usernames. What this suggests to me is that having > an _alias_ (say) Mark.Murray to markmurray in /etc/aliases is OK. Sigh. Yes, I know. However, here's the reasoning behind not having dots in usernames according to passwd(5): The login name must never begin with a hyphen (``-''); also, it is strongly suggested that neither upper-case characters nor dots (``.'') be part of the name, as this tends to confuse mailers. Since any mailer that can't handle a dot in an email address that consists of lo...@host is not compliant with RFC 821, I'm thinking "Hey! Why not make the change?" I've tested it on my -stable system here, and so far there's been no incompatibilities (but then, I only tested a few things: see the original email I sent - which is the point of putting something in -current before stable :) mela...@yip.org - Mustard gas: The kids love it! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NAKAGAWA Yoshihisa writes: > > mechanism was unacceptable -- else we would have used it years ago. > It is not formal core decision. On whose authority do you say that? Garrett is a core team member. > > Our policy in all areas has been that we'd rather do the Right Thing > > than follow the crowd. > new-bus is wrong way. You are misunderstanding 4.4BSD mechanism. Then explain to us why newbus is wrong and why the 4.4BSD scheme is right. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
X crashing under current
I also am experiencing a kernel panic whenever I start X using today's kernel. Thanks Kenneth Culver Computer Science Major at the University of Maryland, College Park. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
My personal opinion is that static configuration is a subset of dynamic configuration. The eventual aim is to have a kernel which is a very sparse skelaton, with very few services and drivers loaded (in fact possibly none). At boot time, the needed drivers and services are loaded and configured (by the loader possibly). A driver that is already linked in is treated exactly as if it had been loaded, except that the loading is not required.. In this view, a statically linked in module is really just a 'pre-loaded' module. it still needs to be initialised. In this view, config(8) is reduced to being used to specify the preloaded modules (though that may be done after compilation by an external linker/loader) and to specify debugging options. A utility could exist that takes a skelaton kernel, and a specified list of kld modules and creates a composite loadable kernel, in which some modules are already present. I will admit that I have only looked a small amount at the new config that NetBSD uses, but it seemed to me that it produced far too much static information. This infrastucture would be duplicated by a dynamic loading framework. why have two such frameworks? If newconfig has removed all static device framework from the kernel then it is going the way I envision things moving. If it still does what the NetBSD one did when I looked at it, and produces a statically compiled framework of child devices and parent nodes, then that is one of the things we are trying to get away from. julian On Wed, 12 May 1999, Noriyuki Soda wrote: > > On Wed, 12 May 1999 09:35:36 -0400, > "Rick Whitesel" said: > > > In general I believe that dynamic configuration of the system is > > extremely useful to both the development community and the user > > community. The development community has a much easier time if they > > can load / unload drivers. As for the users, my rule of thumb is > > that a computer should never ask a human the answer to a question > > that it can find out for itself. I think this is especially true for > > configuration information. In addition, the need for dynamic system > > (re)configuration will only increase as features like PCI hot swap > > become the standard. > > Of course, I completely agree with you. > > The reason I prefer newconfig is it actually can support dynamic > configuration better than the new-bus. All features which new-bus has > can be implemented on newconfig, too. And, more. (See the description > about on-demand dynamic loading in my previous post.) > > Furthremore, newconfig does static configuration better than the > new-bus, and newconfig has a option which removes dynamic configuration > entirely from kernel. New-bus apparently doesn't have this option. > > So, which is flexible ? :-) > -- > s...@sra.co.jpSoftware Research Associates, Inc., Japan > (Noriyuki Soda) Advanced Technology Group. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Scanners
i tried it, i belive it's only for SCSI scanners, my UMAX 1220P is for the parallel port. On Wed, 12 May 1999, Edwin Culp wrote: > Have you tried /usr/ports/graphics/sane? > > ed -- == Tomer Weller s...@i.am well...@netvision.net.il "Drugs are good, and if you do'em pepole think that you're cool", NoFX To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
Ustimenko Semen wrote: > > Hi, > > On Tue, 11 May 1999, Luigi Rizzo wrote: > > > Hi, > > maybe i am the last one in the world to know, but were you guys aware > > of this: > > > > http://research.microsoft.com/programs/NTSrcLicInfo.htm > > > > Microsoft makes Windows NT source code available to universities > > and other "not-for-profit" research institutions at no charge. > > Currently, there are over 55 universities and government agencies > > with source licenses. > > Are we going to get this license? I am interested in NTFS > source code a lot... > > P.S. What's happening with MS? Thanks for the info - I'll try to persuade my Uni to get a license... Shouldn't be much of a problem. :-) If no-one else wants it, I can always request it myself and get a signature of someone at UKC to back it up (or I can always sign "The Dean" :-) Dean To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Sometimes again SCSI don't finish to boot
As Gianmarco Giovannelli wrote ... > > In 4.0-current sometimes the box will froze again after the : > "Waiting 3 seconds for SCSI devices to settle" > then nothing happens. > It was a thing happened also in early 1999, before the branch in > 4.0-current and 3.1 stable, if I remember well. > > Any others experience such behaviour ? > Here is again (part of) my infos: > > FreeBSD 4.0-CURRENT #0: Wed May 12 13:03:16 CEST 1999 > r...@gmarco.eclipse.org:/usr/src/sys/compile/GMARCO > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 400911064 Hz > CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x651 Stepping=1 > Features=0x183f9ff PAT,PSE36,MMX,FXSR> > real memory = 134217728 (131072K bytes) > avail memory = 127868928 (124872K bytes) > Preloaded elf kernel "kernel" at 0xc02ae000. > Pentium Pro MTRR support enabled, default memory type is uncacheable > Probing for PnP devices: > pcib0: on motherboard > pci0: on pcib0 > chip0: at device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vga-pci0: irq 11 at device 0.0 on pci1 > isab0: at device 4.0 on pci0 > chip1: at device 4.1 on pci0 > chip2: at device 4.3 on pci0 > ahc0: irq 14 at device 6.0 on pci0 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > [...] > Waiting 3 seconds for SCSI devices to settle > sa0 at ahc0 bus 0 target 6 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 3.300MB/s transfers > changing root device to da0s1a > da2 at ahc0 bus 0 target 2 lun 0 > da2: Removable Direct Access SCSI-2 device Have you tried this without the ZIP drive? I've heared from people they sometimes cause grief. Groeten / Cheers, | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
As e...@habatech.no wrote ... > > On 12-May-99 Ustimenko Semen wrote: > > > > Are we going to get this license? I am interested in NTFS > > source code a lot... > > > > P.S. What's happening with MS? > > > They have got a virus. I think they're calling it Open Source... Na... it's called US Dept of Justice I guess ;-) > They're fighting really hard to get rid of it, but these things can happen > from time to time :) Groeten / Cheers, | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mbuf starvation
:I think we need to think a bit more about the right semantics before :making such a change. M_WAIT is supposed to mean `I am in process :context and don't mind sleeping in order to get an mbuf, but there is :too much locking going on inside the network stack to be able to :safely sleep without serious risk of deadlock. : :This is the sort of application which would be ideal for Matt's :`asleep' interface. Then, the code could back its way out of any :locks and spls, safely wait for sufficient mbufs to be freed, and then :retry. Even then, it's still possible to deadlock if one process hogs :the entire mbuf pool. It may be necessary to incrementally penalize :processes which do so. : :FWIW, the 4.3 code sleeps in a loop. : :-GAWollman Doing something like this is exactly what was intented for asleep(). The code is not entirely complete, though. Basically the idea is to use asleep() in situations where the system might block but does not normally block in order to avoid both deadlocks and unnecessary code serialization ( due to holding a lock through a blocking situation ). This becomes critically important in SMP models where most of the locks you hold are spinlocks rather then scheduler locks. asleep() allows a subroutine deep in the call stack to specify an asynchronous blocking condition and then return a temporary failure up through the ranks. At the top level, the scheduler sees and acts upon the asynchronous blocking condition. Higher level routines do not need to understand what condition is being blocked on, only that there is some condition being blocked on. With the current model, higher level routines have to assume that lower level routines may block which complicates matters greatly. -Matt Matthew Dillon :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same :woll...@lcs.mit.edu | O Siem / The fires of freedom :Opinions not those of| Dance in the burning flame :MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick : : :To Unsubscribe: send mail to majord...@freebsd.org :with "unsubscribe freebsd-current" in the body of the message : To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Someone blew up the handbook again.
/usr/local/bin/jade -V html-manifest -ioutput.html -c /usr/doc/share/sgml/catal og -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sg ml/docbook/3.0/catalog -c /usr/local/share/sgml/jade/catalog -d /usr/doc/share/ sgml/freebsd.dsl -t sgml handbook.sgml /usr/local/bin/jade:install/chapter.sgml:279:13:E: character data is not allowed Should I just turn NODOC on for the -current snapshot builds? The problem is that I'm not getting *any* -current (or releng3, for that matter) snapshots out at releng3.freebsd.org and current.freebsd.org because on the days when src isn't broken, the handbook is and that kills the builds just as effectively. :-( - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: de driver problem
> Wilko Bulte wrote:
> > PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl
> > Writing Makefile for DynaLoader
> > ==> Your Makefile has been rebuilt. <==
> > ==> Please rerun the make command. <==
> > false
> > false: not found
> > *** Error code 1
>
> I periodically see this one reported, and It is always repaired
> by the reporter making sure their tree is _really_ clean before
> doing a make world. "Really clean" means "make cleandir" _twice_,
This indicates to me, the original author of ``cleandir'', that
something has broken the functionality that it had. This something
is more than likely the removal of code similiar to:
cd /usr/obj/{.CURDIR}; chflags -R noschg tmp; rm -rf *;
before the equiv of:
cd {.CURDIR}; ${make} clean
> and complete removal of the contents of /usr/obj. _Then_ cvsup.
> I prefer to usr CVS checkout, as it shows all the differences and
> other turds in my source tree.
If ``make cleandir'' is leaving some cruft in any form behind anyplace
in the build tree things are broken.
--
Rod Grimes - KD7CAX - (RWG25) rgri...@gndrsh.aac.dev.com
Accurate Automation, Inc. Reliable computers for FreeBSD
http://www.aai.dnsmgr.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: problem with dev_t changes and pageout..
Maybe whoever committed the supposedly innocuous dev_t changes should back it out. Just a thought. -Matt Matthew Dillon : :It looks like something has come unstuck: : :Fatal trap 12: page fault while in kernel mode :mp_lock = 0002; cpuid = 0; lapic.id = :fault virtual address = 0x28 :fault code = supervisor read, page not present :instruction pointer = 0x8:0xc017bb67 :stack pointer = 0x10:0xc5d97de4 :frame pointer = 0x10:0xc5d97df0 :code segment= base 0x0, limit 0xf, type 0x1b := DPL 0, pres 1, def32 1, gran 1 :processor eflags= interrupt enabled, resume, IOPL = 0 :current process = 2 (pagedaemon) :interrupt mask = net bio cam <- SMP: XXX :kernel: type 12 trap, code=0 :Stopped at spec_strategy+0x93: movl0x28(%edx),%eax : ^^^ %edx = null :db> trace :spec_strategy(c5d97e1c) at spec_strategy+0x93 :swap_pager_putpages(c02904fc,c5d97ecc,2,0,c5d97e60) at swap_pager_putpages+0x3e1 :default_pager_putpages(c02904fc,c5d97ecc,2,0,c5d97e60) at default_pager_putpages+0x17 :vm_pageout_flush(c5d97ecc,2,0,c5d97eb0,c02182cf) at vm_pageout_flush+0x91 :vm_pageout_clean(c04d6b60,8000,c013e290,2000,c5d97f78) at vm_pageout_clean+0x1f1 :vm_pageout_scan(8000,c02789c0,c02789c0,c5d97fac,c013e2c3) at vm_pageout_scan+0x45e :vm_pageout(c5d8fdf7,c0255500,c02789c0,c020c640,c020c748) at vm_pageout+0x221 :kproc_start(c02789c0) at kproc_start+0x33 :fork_trampoline(10b8a0,d88e,18b8c08e,8e00,24448be0) at fork_trampoline+0x30 :db> ps : pid proc addruid ppid pgrp flag stat wmesg wchan cmd : 438 c680da40 c6818000 495 282 277 04 3 biord c332d9c0 p4d : 437 c5d8c340 c6802000 433 417 415 004084 3 piperd c6760660 tee : 436 c680dd00 c681 433 417 415 004004 3 biord c33626f8 p4 : 418 c680dba0 c6815000 433 415 415 004084 3 piperd c6760700 mail : 417 c680de60 c680e000 433 415 415 004084 3wait c680de60 sh :[..] : :The offending line in spec_strategy is: :(*bdevsw(bp->b_dev)->d_strategy)(bp); : :d_strategy was null.. I'm still looking. : :(I think this is the first time the box paged out since booting a few hours :ago, it's got 128M, but p4d has got a lot of stuff to deal with and can hit :a vsize of 70MB or so.) : :Cheers, :-Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
