Re: Data corruption whilst debugging sonar module of ports/graph
Mike Heffner wrote: > > On 13-Jan-2001 Matthew Thyer wrote: > > | Does anyone recognise where 0xd0d0d0d0 may have come from ? > | > > [snip] > > Read the "Tuning" section of malloc(3). 0xd0 is what allocated and deallocated > memory is set to. xscreensaver is probably not initializing malloc()'d memory, > and therefore it's left at 0xd0. A work around is to turn off this feature: > > ln -s aj /etc/malloc.conf > > however, xscreensaver should be fixed instead. Yes, that's what I'm trying to achieve. I thought it was "0xdeadcode" that got put in the malloc'd memory but if that's changed then thanks for the lead. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 bike shed
Steve Kargl wrote: > I've already filed a PR about this. And, yes > I know people have discussed this the last day or > two, but until the color is chosen can someone > please remove the the installation of sysinstall.8 > from src/share/man/man8/Makefile. ugh, sorry. I forgot to fix that. :-( ... Fixed now, I hope. If this fixes it for you I'll MFC it. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sysinstall.8 bike shed
I've already filed a PR about this. And, yes I know people have discussed this the last day or two, but until the color is chosen can someone please remove the the installation of sysinstall.8 from src/share/man/man8/Makefile. -- Steve ===> share/man/man8 gzip -cn /usr/src/share/man/man8/adding_user.8 > adding_user.8.gz gzip -cn /usr/src/share/man/man8/crash.8 > crash.8.gz gzip -cn /usr/src/share/man/man8/diskless.8 > diskless.8.gz gzip -cn /usr/src/share/man/man8/intro.8 > intro.8.gz gzip -cn /usr/src/share/man/man8/picobsd.8 > picobsd.8.gz gzip -cn /usr/src/share/man/man8/rc.8 > rc.8.gz gzip -cn /usr/src/share/man/man8/sticky.8 > sticky.8.gz make: don't know how to make sysinstall.8. Stop *** Error code 2 Stop in /usr/src/share/man. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Sheldon Hearn wrote: > > On Sat, 13 Jan 2001 01:46:46 +1030, Matthew Thyer wrote: > > > > The way it is now is the way it's always been. Think about what you > > > mean when you say "dynamic swap user". You want mfs to use more swap > > > than you have? :-) > > > > No I want mfs to grow and shrink its filesystem dynamically. > > Then don't limit the size! :-) I dont. So what next ? Since I dont have much time for debugging FreeBSD, I stopped using mfs instead. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Data corruption whilst debugging sonar module of ports/graphics/xscreensaver-gtk-3.26 ?
Both of my main FreeBSD-CURRENT machines cant seem to run the sonar
module from xscreensaver-gtk-3.26 for very long. It crashes with a
SIGBUS on line 1654 of xscreensaver-3.26/hacks/sonar.c when the sonar
sweep gets back around to the first bogie that was ever displayed.
Since my home box is XFree 3.3.6 and work is XFree 4.0.2, I assume
this is a bug with the screensaver itself. Note both machines are
recent -CURRENT (within 1 week of today).
Today I had some spare time (wife and kids out of my hair) so I
installed ports/devel/ddd to have a look at whats going on.
To reproduce what I'm doing:
- Install ports/devel/ddd
- Set "CFLAGS=-g -pipe" in /etc/make.conf
- cd /usr/ports/x11/xscreensaver ; sudo make install
- Set your CFLAGS back to what they were
- cd /usr/ports/x11/xscreensaver/work/xscreensaver-3.26/hacks
- ddd &
- File->Open Program... and choose "sonar"
- Run until it dies with the SIGBUS on line 1654 (subroutine "Sonar")
- Display "si", "*si", "*si->visable", all the "*si->visable{->next}*"
(e.g. "*si->visable->next", "*si->visable->next->next" etc) and
the local variables.
I'm seeing the local variable "bp" with a value of 0xd0d0d0d0.
I cant see how this happens when "bp" is initialised from
si->visable in the for loop at line 1647 and thereafter follows
the list (via ->next) where no members have an address of 0xd0d0d0d0.
It seems that something in sonar.c is overwriting memory it shouldn't.
I haven't done much debugging since Uni, so I was wonderring if
others can reproduce this and does someone have some ideas how I
can easily detect this data corruption with ddd or is it a compiler
bug ? (I suspect not as it always happens when the sweep gets back
around to the first bogie ever displayed).
Does anyone recognise where 0xd0d0d0d0 may have come from ?
1635 static void
1636 Sonar(sonar_info *si, Bogie *bl)
1637 {
1638
1639 /* Local Variables */
1640
1641 Bogie *bp, *prev;
1642 int i;
1643
1644 /* Check for expired tagets and remove them from the visable list */
1645
1646 prev = NULL;
1647 for (bp = si->visable; bp != NULL; bp = bp->next) {
1648
1649 /*
1650 * Remove it from the visable list if it's expired or we have
1651 * a new target with the same name.
1652 */
1653
1654 bp->age ++;
1655
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Building -STABLE on -CURRENT
Sending this to freebsd-stable or freebsd-current was somewhat of a toss-up, but since I expect more committers hang out on -current than -stable, here it is. For the last few days (not sure when it started) I've been unable to build -STABLE on a -CURRENT machine. This has proven a problem for recent RELENG_3 MFC's of security fixes; I've tried upgrading to the most recent -CURRENT on the box, making sure /usr/include is updated, et al. I'm guessing this is /usr/include pollution in the /usr/src build, but won't speculate too much more as I'm travelling tomorrow. Attached below is the breakage from buildworld. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services cd /usr/src/share/syscons/scrnmaps; make build-tools cc -static -O -pipe -I/usr/src/share/syscons/scrnmaps -DFIL=\"koi8-r2cp866\" -o koi8-r2cp866.mk /usr/src/share/syscons/scrnmaps/mkscrfil.c In file included from /usr/src/share/syscons/scrnmaps/mkscrfil.c:28: /usr/include/machine/console.h:3: #error "this file includes which is deprecated, use instead" In file included from /usr/src/share/syscons/scrnmaps/mkscrfil.c:31: /usr/src/share/syscons/scrnmaps/koi8-r2cp866:27: syntax error before `scrmap' /usr/src/share/syscons/scrnmaps/koi8-r2cp866:28: warning: excess elements in scalar initializer /usr/src/share/syscons/scrnmaps/koi8-r2cp866:28: warning: (near initialization for `scrmap') /usr/src/share/syscons/scrnmaps/koi8-r2cp866:28: warning: excess elements in scalar initializer /usr/src/share/syscons/scrnmaps/koi8-r2cp866:28: warning: (near initialization for `scrmap') /usr/src/share/syscons/scrnmaps/koi8-r2cp866:28: warning: excess elements in scalar initializer /usr/src/share/syscons/scrnmaps/koi8-r2cp866:28: warning: (near initialization for `scrmap') /usr/src/share/syscons/scrnmaps/koi8-r2cp866:28: warning: excess elements in scalar initializer ... /usr/src/share/syscons/scrnmaps/mkscrfil.c: In function `main': /usr/src/share/syscons/scrnmaps/mkscrfil.c:42: `scrmap_t' undeclared (first use in this function) /usr/src/share/syscons/scrnmaps/mkscrfil.c:42: (Each undeclared identifier is reported only once /usr/src/share/syscons/scrnmaps/mkscrfil.c:42: for each function it appears in.) *** Error code 1 Stop in /usr/src/share/syscons/scrnmaps. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Running Linux kernel modules.
: : > Why not just track the opens independantly in the overloading code? : :I'm not sure I know what you mean. I don't just need to track :multiple open/closes, I need to be able to hang a pointer off of :something that I can get at durning an mmap() or ioctl() syscall so :that I can tell which instance I'm dealing with. : :Drew f_data? Or if f_data is a vnode, a field in the vnode ? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anybody else seeing a broken /dev/lpt with SMP on -current?
On 13-Jan-01 Alfred Perlstein wrote: > * John Baldwin <[EMAIL PROTECTED]> [010112 18:56] wrote: >> >> On 13-Jan-01 Jordan Hubbard wrote: >> > I've actually been seeing this for about 2 months now but only just >> > now got motivated enough to enable crashdumps and get some information >> > on what happens whenver I try to use the printer attached to my (sadly :) >> > -current SMP box: >> > >> >> All the other traces show the kerenl having returned to an address that is >> beyongd the end of the kernel (which causes the page fault) meaning that the >> stack is fubar'd, so the trace isn't meaningful anyways. :( Knowing how and >> why the lpd interrupt handler trashes the stack is the useful info, and with >> teh stack already trashed, I don't know of an easy way to figure that out. >> Suggestions welcome. > > printf(9) > >:) Maybe if I had a printer lying around. :) I can send jkh some patches to dump out stuff, but I was looking more for suggestions on making sense of the crashdump, not just brute-forcing it. :-P > -Alfred -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Running Linux kernel modules.
Matt Dillon writes: > :To handle the multiple open problem, I'm overloading the open and > :close system calls. Upon open, I call the native open, then I grovel > :around in the process' open file table looking for my special file. > :When I find it, I mark fp->f_nextread with a magic number, then store > :a pointer to the per-open private data in fp->f_offset. On close, I > :go grovelling again. I deallocate the private data, clear the magic > :number, and call the system close function. I've also got an > :at_exit() hook that does much the same thing. > > Wait a sec... f_nextread and f_offset can be messed around with > by the user process, what prevents the user process from screwing > up your kernel data pointer? Pure ignorance. Since the device doesn't support reads/writes, I'm hoping nobody will try to lseek on it ;) I could overload the syscalls that touch these fields if I have to, but I'm hoping this will be just an interum hack and don't want to waste time polishing it. > Why not just track the opens independantly in the overloading code? I'm not sure I know what you mean. I don't just need to track multiple open/closes, I need to be able to hang a pointer off of something that I can get at durning an mmap() or ioctl() syscall so that I can tell which instance I'm dealing with. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anybody else seeing a broken /dev/lpt with SMP on -current?
* John Baldwin <[EMAIL PROTECTED]> [010112 18:56] wrote: > > On 13-Jan-01 Jordan Hubbard wrote: > > I've actually been seeing this for about 2 months now but only just > > now got motivated enough to enable crashdumps and get some information > > on what happens whenver I try to use the printer attached to my (sadly :) > > -current SMP box: > > > > All the other traces show the kerenl having returned to an address that is > beyongd the end of the kernel (which causes the page fault) meaning that the > stack is fubar'd, so the trace isn't meaningful anyways. :( Knowing how and > why the lpd interrupt handler trashes the stack is the useful info, and with > teh stack already trashed, I don't know of an easy way to figure that out. > Suggestions welcome. printf(9) :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Anybody else seeing a broken /dev/lpt with SMP on -current?
On 13-Jan-01 Jordan Hubbard wrote: > I've actually been seeing this for about 2 months now but only just > now got motivated enough to enable crashdumps and get some information > on what happens whenver I try to use the printer attached to my (sadly :) > -current SMP box: > > IdlePTD 3682304 > initial pcb at 2e70e0 > panicstr: page fault > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > cpuid = 0; lapic.id = > fault virtual address = 0x8640 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc8dc8676 > stack pointer = 0x10:0xc8280f88 > frame pointer = 0x10:0xc8280f9c > 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 = 12322 (irq7: lpt0) > trap number = 12 > panic: page fault > cpuid = 0; lapic.id = > boot() called on cpu#0 > > If anybody wants a fuller traceback then I'll compile up a kernel with > debugging symbols, but it's going to be pretty sparse anyway since it > basically only shows the trap() from the page fault and the subsequent > panic. All the other traces show the kerenl having returned to an address that is beyongd the end of the kernel (which causes the page fault) meaning that the stack is fubar'd, so the trace isn't meaningful anyways. :( Knowing how and why the lpd interrupt handler trashes the stack is the useful info, and with teh stack already trashed, I don't know of an easy way to figure that out. Suggestions welcome. > - Jordan -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Anybody else seeing a broken /dev/lpt with SMP on -current?
I've actually been seeing this for about 2 months now but only just now got motivated enough to enable crashdumps and get some information on what happens whenver I try to use the printer attached to my (sadly :) -current SMP box: IdlePTD 3682304 initial pcb at 2e70e0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x8640 fault code = supervisor write, page not present instruction pointer = 0x8:0xc8dc8676 stack pointer = 0x10:0xc8280f88 frame pointer = 0x10:0xc8280f9c 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 = 12322 (irq7: lpt0) trap number = 12 panic: page fault cpuid = 0; lapic.id = boot() called on cpu#0 If anybody wants a fuller traceback then I'll compile up a kernel with debugging symbols, but it's going to be pretty sparse anyway since it basically only shows the trap() from the page fault and the subsequent panic. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: module privlages
I'm not sure what the point of this would really be..nor how you could enforce it. Perhaps you should submit a proof of concept ;-) Kris On Fri, Jan 12, 2001 at 11:15:09AM -0600, Jason Smethers wrote: > Has anyone put any thought into putting restrictions on what a module > can modify when loaded into the kernel? If there is, say, ever binary > third party driver support and this is provided without source some > restrictions on what kernel data this module can link to and modify > when loaded might be a good idea. > > I was thinking something along the lines of a list of symbols that a > kernel module may call, and a list of symbols that a kernel module may > modify. Allowing the update of these lists may be a little tricky to > prevent already load modules from detecting this and adding their own > symbols. > > Doing this with module types might be simple. When a module is loaded > it would contain flags to the module type(s) it is uses and this > selects the list of symbols it may interact with. A module may be then > be used to update these symbols but root is warned and must OK a load > of a kernel module with the type which allows updating the symbol > lists. > > With the module types it would also help prevent a module from messing > around in an area that is not expected from such a module. e.g. a > network driver messing around in the VFS. > > Any thoughts? > > - Jason > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message PGP signature
RE: Broken mmap in current?
Title: RE: Broken mmap in current? I think I spoke too soon.. I saw thousands of calls to mmap and assumed it was the thousands of read/writes that I was doing. It's actually for the thousands (8192) of pages that I'm mapping in. Oddly enough though there are only 3272 calls to my mmap routine each time I run the program. I will investigate further. I did find a bug in mlock() and munlock(). I tried mlock()ing after I mmaped, which I later realized was bogus since the pages are always resident as they exist on the bus. Anyway the kernel faults in vm_page_unwire when I munlock. I will investigate further and post a pr though. Thanks for your help! Jeff -Original Message- From: Bruce Evans [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 11, 2001 8:52 PM To: Jeff Roberson Cc: '[EMAIL PROTECTED]' Subject: Re: Broken mmap in current? On Thu, 11 Jan 2001, Jeff Roberson wrote: > I have written a character device driver for a proprietary PCI device that > has a large sum of mapable memory. The character device supports mmap() > which I use to export the memory into a user process. I have no problems > accessing the memory on this device, but I notice that my mmap routine is > called for every access! Is this a problem with current, or a problem with > my mmap? Maybe both. The device mmap routine is called mainly by the mmap syscall for every page to be mmapped. It is also called by dev_pager_getpages() for some pagefaults, but I think this rarely happens. > I use bus_alloc_resource and then rman_get_start to get the physical address > in my attach, and then the mmap just returns atop(physical address). I > assumed this is correct since I have verified with a logical analyzer that I > am indeed writing to the memory on the device. This is correct. I looked at some examples. Many drivers get this wrong by using i386_btop(), alpha_btop(), etc. (AFAIK, atop() is for addresses which are what we are converting here, btop() is for (byte) offsets, and the machine-dependent prefixes are a vestige of page clustering code that mostly went away 7 years ago. > Also, I noticed that the > device's mmap interface does not provide any way to limit the size of the > block being mapped? Can I specify the length of the region? The length is implicitly PAGE_SIZE. The device mmap function is called for each page to be mapped. It must verify that the memory from offset to (offset + PAGE_SIZE - 1) belongs to the device and can be accessed with the given protection, and do any device-specific things necessary to enable this memory. This scheme can't support bank-switched device memory very well, if at all. pcvvt_mmap() in the pcvt driver is the simplest example of this. agp_mmap() is a more up to date example with the same old bug that the vga drivers used to have (off by 1 (page) error checking the offset). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Running Linux kernel modules.
* Andrew Gallatin <[EMAIL PROTECTED]> [010112 15:29] wrote: > > Julian Elischer writes: > > > > > > Isn't this gross? Is there a better way? > > > > I think that the better way is to actually have each open have a > > different minor number. > > i.e. each process opens a different copy. > > > The way to achieve this best is with cloning devices. > > apply within phk for more info :-) > > Does this mean that the processes can open /dev/foo0 twice and the > driver sees a different minor number for each open? Or does it mean > that the process has to open /dev/foo0 and /dev/foo1? > > If the former, that's awesome!... How do I use it? Well you have to write it, but you basically have the open(2) syscall path optionally return a seperate void * 'cookie' that you must pass into all operations (fileops) on that file. It's not a major rewrite of any code, you just need an extra parameter per fileop and store it in the struct file. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: YES! laptop installing
>: That is fixed with my cardbus patch set... at least for the xircom. >: It should be trivial to fix for the others if they store their >: nic address the same way. > >Interestingly enough, they do. However, of all my cards, the both my >xircom just work w/o this. > >Warner The dc driver would get the mac address wrong for one of my xircom cards but not so wrong as to make it non-functional. The other xircom card (the type-III with modem) seemed to end up with a mac address that was considered invalid by many switches. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
> Can we decide this, please - do we want secure startup (which will > take some effort to achieve), or can we say "screw it" and start > insecure like the old system? Can we have both? Ie; by default we are insecure until some point we call an ioctl() that says 'no more, you must get real randomness now'. So, that way we can do the stuff that doesn't require real randomness (like mounting disks and such), and then once that's over with, the system forces it into 'secure' mode, at which time it's up to the user to supply some randomness for it. If that happens, a user could decide comment out the 'real secure' thing, and /dev/random would never block. You can all laugh at me now. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Running Linux kernel modules.
:To handle the multiple open problem, I'm overloading the open and :close system calls. Upon open, I call the native open, then I grovel :around in the process' open file table looking for my special file. :When I find it, I mark fp->f_nextread with a magic number, then store :a pointer to the per-open private data in fp->f_offset. On close, I :go grovelling again. I deallocate the private data, clear the magic :number, and call the system close function. I've also got an :at_exit() hook that does much the same thing. Wait a sec... f_nextread and f_offset can be messed around with by the user process, what prevents the user process from screwing up your kernel data pointer? Why not just track the opens independantly in the overloading code? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Running Linux kernel modules.
Julian Elischer writes: > > > > Isn't this gross? Is there a better way? > > I think that the better way is to actually have each open have a > different minor number. > i.e. each process opens a different copy. > The way to achieve this best is with cloning devices. > apply within phk for more info :-) Does this mean that the processes can open /dev/foo0 twice and the driver sees a different minor number for each open? Or does it mean that the process has to open /dev/foo0 and /dev/foo1? If the former, that's awesome!... How do I use it? If the latter, then it isn't practical for things like vmware and my Giganet VI driver because both depend on closed-source userland code which cannot be taught to open differently named special files. > I could imagine however that you could assume that each process > opens the device only once, and thus have a hash-table of > private info, keyed on curproc. You should be able to store the curproc > key with the request currently being serviced so that teh interrupt routines > can also use the same key. It would simplifly things, but I don't think that this is going to be a valid assumption in general.. Thanks! Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Julian Elischer <[EMAIL PROTECTED]> writes: > Jun Kuriyama wrote: > > # kldload ng_bridge > > kldload: can't load ng_bridge: Exec format error > > And /var/log/messages says: > > > > Jan 12 16:27:07 waterblue /boot/kernel/kernel: KLD ng_bridge.ko: depends on >ng_ether - not available > > something is terribly broken with the kld loading at the moment. Something is terribly broken with ng_ether at the moment. It lacks a MODULE_VERSION line. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio && serial console in -current?
Interesting theory, but no- that wasn't it. > Matthew Jacob wrote: > > > > Something wierd has been happening lately- the serial console on my i386 > > machine works fine up until init is forked.. THen the output is mangled, and > > one gets replicated and/or mangled stuff. On a reboot I'm getthing things > > like: > > > > Waiting (max 60 > > seconds) for > > system process > > `bufdaemon' to > > stop...stopped > > > > It's like the output is being repeated... > > > > Anyone seen same? > > My guess is you might be using PHK's syslog feature and be sending > console output to the console ? (I haven't tried it tho). > > Check your syslog.conf (or disable syslogd and see what happens). > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! New netgraph code coming
Jun Kuriyama wrote: > > Hi Julian, > > I tried netgraph for the first time to work with latest vmware2 port. > > When I try to load netgraph kernel module, it failed with: > > # kldload ng_bridge > kldload: can't load ng_bridge: Exec format error something is terribly broken with the kld loading at the moment. netgraph actually tries to load modules it needs but it hasn't been able to for some months. Also kldload ca SEE what the dependency is so the module is telling it correctly, just the kernel is failing to load the dependency.. I don't think this is Netgraph's fault. we haven;t changed anything.. it just stopped working one day. > > And /var/log/messages says: > > Jan 12 16:27:07 waterblue /boot/kernel/kernel: KLD ng_bridge.ko: depends on ng_ether >- not available > > But ng_ether.ko is already loaded automatically (checked by kldstat). > > Is this known problem, or my local configuration mistake? > > # My environment is "make world"ed yesterday and kernel is latest. > > -- > Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. > <[EMAIL PROTECTED]> // FreeBSD Project -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Running Linux kernel modules.
Andrew Gallatin wrote: > > > > > To handle the multiple open problem, I'm overloading the open and > close system calls. Upon open, I call the native open, then I grovel > around in the process' open file table looking for my special file. > When I find it, I mark fp->f_nextread with a magic number, then store > a pointer to the per-open private data in fp->f_offset. On close, I > go grovelling again. I deallocate the private data, clear the magic > number, and call the system close function. I've also got an > at_exit() hook that does much the same thing. > > Obtaining the file descripter at ioctl() and mmap() time is much more > interesting. When I'm called from a syscall, I pull the args out of > the process and grab the fd, index the process' file table and bingo. > > The real problem is when mmap is called out of a fault (and not > dev_pager_alloc, which is what gets called when the mmap syscall is > issued). Right now I throw up my hands and return the private data > from the first instance I find when walking the process' open file > table. If this becomes a problem, I'm planning on prefaulting the > pages at dev_pager_alloc() time (when I can get an fd from the > process) and wiring them -- its only 20k per process.. > > Isn't this gross? Is there a better way? I think that the better way is to actually have each open have a different minor number. i.e. each process opens a different copy. The way to achieve this best is with cloning devices. apply within phk for more info :-) I could imagine however that you could assume that each process opens the device only once, and thus have a hash-table of private info, keyed on curproc. You should be able to store the curproc key with the request currently being serviced so that teh interrupt routines can also use the same key. > > Drew > > -- > Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin > Duke University Email: [EMAIL PROTECTED] > Department of Computer Science Phone: (919) 660-6590 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unknown devices
Down near the botton I have some unknown pnp devices, is there any way to figure out what devices they are, they must be motherboard resources because all other devices seem to be accounted for. Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #5: Fri Jan 12 11:14:56 CST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/DWCJR Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1102506314 Hz CPU: AMD Athlon(tm) Processor (1102.51-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc044<,AMIE,DSP,3DNow!> real memory = 402587648 (393152K bytes) config> avail memory = 387854336 (378764K bytes) Preloaded elf kernel "kernel" at 0xc03b3000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03b309c. Preloaded elf module "vesa.ko" at 0xc03b30ec. Preloaded elf module "if_xl.ko" at 0xc03b3188. Preloaded elf module "miibus.ko" at 0xc03b3228. Preloaded elf module "usb.ko" at 0xc03b32c8. Preloaded elf module "bktr.ko" at 0xc03b3364. Preloaded elf module "bktr_mem.ko" at 0xc03b3400. Preloaded elf module "random.ko" at 0xc03b34a0. Preloaded elf module "agp.ko" at 0xc03b3540. Preloaded elf module "snd_es137x.ko" at 0xc03b35dc. Preloaded elf module "snd_pcm.ko" at 0xc03b3680. bktr_mem: memory holder loaded Pentium Pro MTRR support enabled VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc032a2e2 (122) VESA: NVidia ACPI debug layer 0x0 debug level 0x0 Using $PIR table, 8 entries at 0xc00f7960 acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi_tz0: on acpi0 acpi_tz0: current temperature 52.0C acpi_button0: on acpi0 acpi_pcib0: on acpi0 pci0: on acpi_pcib0 agp0: mem 0xe000-0xefff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.4 (no driver attached) ahc0: port 0xd800-0xd8ff mem 0xd000-0xdfff irq 9 at device 12.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs bktr0: mem 0xdddfc000-0xdddfcfff irq 10 at device 13.0 on pci0 bktr0: Warning - card vendor 0x1002 (model 0x0001) unknown. bktr0: Detected a MSP3430G-A4 at 0x80 bktr0: Pinnacle/Miro TV, Temic NTSC tuner, msp3400c stereo. pci0: at 13.1 (no driver attached) pcm0: port 0xd400-0xd43f irq 11 at device 14.0 on pci0 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd000-0xd07f mem 0xdfffef80-0xdfffefff irq 5 at device 15.0 on pci0 xl0: Ethernet address: 00:50:04:b7:13:09 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto acpi_button1: on acpi0 acpi_timer0: <24-bit timer at 3.579545MHz> on acpi0 npx0: on motherboard npx0: INT 16 interface atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fd1: <1200-KB 5.25" drive> on fdc0 drive 1 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources ad0: 6149MB [13328/15/63] at ata0-master UDMA66 ad1: 2317MB [4708/16/63] at ata0-slave UDMA33 acd0: CDROM at ata1-master using PIO4 Waiting 5 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad1s1a cd0 at ahc0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [1 x 2048 byte records] pcm0: hwptr went backwards 2208 -> 2016 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: YES! laptop installing
On Wed, Jan 10, 2001 at 12:04:17AM -0500, Kenneth Wayne Culver wrote: > This is to let everyone know that right now as I type I am setting up > FreeBSD to start downloading over my cardbus ethernet card. It seems to > work great except it doesn't beep when the card enables, but that's fine > with me. :-) Just to add my $0.02, and in case anybody cares... Cardbus is working ok on by Thinkpad with a 3Com pccard, except that the system freezes when I remove the card... Bye, Andrea -- The dark ages were caused by the Y1K problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ext2 root filesystem
Is it possible to have an ext2 filesystem on /? Sorry if this is a FAQ, but I couldn't find any details after a bit of searching. Two issues come to my inexperienced mind. There is the trouble of booting the kernel. GRUB can grok ext2 so I could use that (or at least, I could probably hack GRUB till it can boot FreeBSD again). But before that there is probably going to be a problem building the kernel. Does anybody have any experience doing a cross compile from Linux? -- http://www.penguinpowered.com/~vii To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug in src tree?
[ .. moved to -stable .. ] On Fri, Jan 12, 2001 at 08:17:01AM +0100, electro wrote: > I try to compile a new kernel with the latest source and I always end up > with this (in the end). Any suggestions? > I mean the error message is fun...dont match any know i386 instruction [...] > /tmp/ccmJEqq7.s:758: Error: operands given don't match any known 386 > instruction > /tmp/ccmJEqq7.s:822: Error: operands given don't match any known 386 > instruction [...] You appear to be upgrading from a very old version of FreeBSD. The last time I encountered this was when binutils was upgraded in 4.x-STABLE around July or August 2000. In any case that means (most likely) that you may need to install the newer binutils manually before compiling. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug in src tree?
On Fri 2001-01-12 (21:38), Sheldon Hearn wrote: > > > On Fri, 12 Jan 2001 11:24:38 +0200, Neil Blakey-Milner wrote: > > > > /tmp/ccmJEqq7.s:822: Error: operands given don't match any known 386 > > > instruction > > > *** Error code 1 > > > > > > Stop in /usr/src/sys/compile/PROFESSOR.010110. > > > > You're not using buildkernel, and thus you don't have the necessarily > > updated tools to handle that source. > > Are you sure? I think "electro" _is_ using buildkernel but without a > buildworld. Oops, that's quite possible too. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug in src tree?
On Fri, 12 Jan 2001 11:24:38 +0200, Neil Blakey-Milner wrote: > > /tmp/ccmJEqq7.s:822: Error: operands given don't match any known 386 > > instruction > > *** Error code 1 > > > > Stop in /usr/src/sys/compile/PROFESSOR.010110. > > You're not using buildkernel, and thus you don't have the necessarily > updated tools to handle that source. Are you sure? I think "electro" _is_ using buildkernel but without a buildworld. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh
Warner Losh wrote: > In message <[EMAIL PROTECTED]> Maxim Sobolev writes: > : I like this idea, but perhaps it would be nice to have more > : fine-grained control over when /dev/random is blocking and when > : not. Why not to add sysctl to switch between blocking/non-blocking > : behaviour (defaulting to non-blocking), so our startup scripts would > : be able to switch /dev/random to be secure at the point when it's > : safe to do (all f/s mounted) much like it copes with > : kern.securelevel. Additionaly it would solve the problem that you > : are not able to use almost anything in single-user mode (less, vi, > : ee etc) w/o feeding /dev/random by hand first. > > That's why I had the first write clause in my statement. The act of > seeing it, which writes to /dev/random, would be enough. No need to > make it more complex than it has to be. Seeding it with *something* (ls, vmstat, date etc) is not equial to seeding it properly, i.e using data with high enough amount of entropy in it. Therefore, such sysctl may be potentially used to determine that random generator is in insecure state and should not be used for anything that require high level of randomness (key generation for example - ssh may check such sysctl and refuse to generate a key or at least warn a user about possible problems). Just my UAH0.02 ;). -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Any people with 3c905CX cards out there?
3Com has yet another revision of the Tornado chipset floating around out there on newer 3c905C adapters. Supposedly, these are marked as 3c905CX and have become available within the last couple of months. I've seen some noise on the Linux mailing lists that seems to indicate that some driver mods were necessary due to reset timing differences introduced in the new chipset, however I haven't been able to get my hands on one of these cards yet so I don't know whether or not there are also problems with FreeBSD. Nobody has reported any yet, but it would be nice to confirm the issue one way or the other. If someone has one of these cards and is using it with the xl driver, I'd be interested to know how well (or how badly) it's working. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CFR: Generalized power-management interface
Hi, I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz http://people.freebsd.org/~iwasaki/acpi/wmpm-20010113.tar.gz Note that ioctl number for power device have been changed, so rebuilding your kernel and recompiling lib/libpower/ and usr.sbin/power/ are needed. Added API is; u_intpower_get_pm_type(void); I'll get device major number for /dev/power and commit them within a few days if no objection. Thanks > I've created new common framework on generalized power-management > interface for userland utilities. > > http://people.freebsd.org/~iwasaki/acpi/power-20001229.tar.gz > > This provides some PM APIs to APM applications, such as wmapm, so that > these applications can be ported smoothly to use ACPI (power > management portion). Currently following APIs are implemented; > > intpower_get_syspm_info(struct power_syspm_info *); > intpower_get_batt_info(u_int, struct power_batt_info *); > intpower_standby(void); > intpower_suspend(void); > intpower_hibernate(void); > > And PM event notification mechanism is suggested to be implemented so far. > > Sample application is included in usr.sbin/power/ which is very similar > to apm(8) but supports ACPI as well. > > usr.sbin/acpi/acpibatt/ is for displaying acpi_cmbat (ACPI Control > Method Battery), can be used to verify that generalized > power-management interface is working correctly. > Note that many ACPI BIOS give us unknown battery remaining time when > ac-line is plugged in. MIB 'hw.battery.full_charge_time' can be used to > specify the full charged remaining time of batteries in minutes, like > sysctl -w hw.battery.full_charge_time=60,60 > for multiple number of batteries, or > sysctl -w hw.battery.full_charge_time=120 > for a battery installed. > > To test them, /dev/power is required as a device control file. > > % ls -l /dev/power > crw-r--r-- 1 root wheel 210, 0 12/19 04:51 /dev/power > > I'll commit them at sometime early in coming century. > > Any comments would be appreciated. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
module privlages
Has anyone put any thought into putting restrictions on what a module can modify when loaded into the kernel? If there is, say, ever binary third party driver support and this is provided without source some restrictions on what kernel data this module can link to and modify when loaded might be a good idea. I was thinking something along the lines of a list of symbols that a kernel module may call, and a list of symbols that a kernel module may modify. Allowing the update of these lists may be a little tricky to prevent already load modules from detecting this and adding their own symbols. Doing this with module types might be simple. When a module is loaded it would contain flags to the module type(s) it is uses and this selects the list of symbols it may interact with. A module may be then be used to update these symbols but root is warned and must OK a load of a kernel module with the type which allows updating the symbol lists. With the module types it would also help prevent a module from messing around in an area that is not expected from such a module. e.g. a network driver messing around in the VFS. Any thoughts? - Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: YES! laptop installing
In message <[EMAIL PROTECTED]> "Justin T. Gibbs" writes: : >: MAC=00:00:80:00:00:80, FWIW. : > : >There's about 4 different dc based cards that don't work because they : >don't get the nic address right. Well, that's what I think. : : That is fixed with my cardbus patch set... at least for the xircom. : It should be trivial to fix for the others if they store their : nic address the same way. Interestingly enough, they do. However, of all my cards, the both my xircom just work w/o this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh
In message <[EMAIL PROTECTED]> Maxim Sobolev writes: : I like this idea, but perhaps it would be nice to have more : fine-grained control over when /dev/random is blocking and when : not. Why not to add sysctl to switch between blocking/non-blocking : behaviour (defaulting to non-blocking), so our startup scripts would : be able to switch /dev/random to be secure at the point when it's : safe to do (all f/s mounted) much like it copes with : kern.securelevel. Additionaly it would solve the problem that you : are not able to use almost anything in single-user mode (less, vi, : ee etc) w/o feeding /dev/random by hand first. That's why I had the first write clause in my statement. The act of seeing it, which writes to /dev/random, would be enough. No need to make it more complex than it has to be. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
On Sat, 13 Jan 2001 01:46:46 +1030, Matthew Thyer wrote: > > The way it is now is the way it's always been. Think about what you > > mean when you say "dynamic swap user". You want mfs to use more swap > > than you have? :-) > > No I want mfs to grow and shrink its filesystem dynamically. Then don't limit the size! :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Sheldon Hearn wrote: > > On Fri, 12 Jan 2001 22:01:03 +1030, Matthew Thyer wrote: > > > This seems a bit of a pain. > > > > Is there anyway to go back (if I'm correct) to a dynamic swap user. > > I suppose I'm talking about a real tmpfs ? > > The way it is now is the way it's always been. Think about what you > mean when you say "dynamic swap user". You want mfs to use more swap > than you have? :-) No I want mfs to grow and shrink its filesystem dynamically. I never had these messages until recent changes in mfs but it will take me too much time to narrow it down as the message is hard to reproduce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio && serial console in -current?
Matthew Jacob wrote: > > Something wierd has been happening lately- the serial console on my i386 > machine works fine up until init is forked.. THen the output is mangled, and > one gets replicated and/or mangled stuff. On a reboot I'm getthing things > like: > > Waiting (max 60 > seconds) for > system process > `bufdaemon' to > stop...stopped > > It's like the output is being repeated... > > Anyone seen same? My guess is you might be using PHK's syslog feature and be sending console output to the console ? (I haven't tried it tho). Check your syslog.conf (or disable syslogd and see what happens). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: YES! laptop installing
>: MAC=00:00:80:00:00:80, FWIW. > >There's about 4 different dc based cards that don't work because they >don't get the nic address right. Well, that's what I think. That is fixed with my cardbus patch set... at least for the xircom. It should be trivial to fix for the others if they store their nic address the same way. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
> Start some kind of hardware-managed timer at the earliest possible > opportunity (perhaps start it in the boot loader!), then when you need to > pick up your first seed, read the timer's value and seed your random > generator from that. I have some much more sophisticated code (written by JHB) that does effectively this. It does it by hooking interrupt randomness, and by using the interrupts from your disk controllers (SCSI and IDE/ATA), a nicely fast reseed is gained. I'll happily commit it now, but I'd prefer a code review first, and is suspect that this will be better received once Jake's preemptive ithread code is committed. > The idea is to catch that timer at an unknown condition, and certainly the > computer is not going to boot in the exact same amount of time, every time > it's restarted. This would be especially true if the boot sequence gets > interrupted (to load another kernel perhaps) or the user forces the > machine into single-user mode while it's booting. All entropy harvesting uses some kind of harvesting. On i386, (Pentium and better) it is the TSC register. 80386 and 80486 use nanotime(9) and other CPUs have a TSC-like register. > In my hobby platform, it's common to start the timer, then grab a value > from it after the user hits a key after viewing some introduction screen. > The value grabbed is often used as the actual random number, but it could > be just as useful if used to seed a random generator. SOP :-) > If you're particularly paranoid, you set both timers for 32-bit mode, > start one first thing at startup, and the other when the user hits the > key, then read both of them the first time a random number is needed. > Seed your random generator from that, along with any other sources you can > (such as the video raster counter and the sound device's readable > oscillator, set to generate a noise waveform). Slight overkill, when the TSC register is already used and deliberately underestimated to improve randomness quality. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fan speed control sony vaio lx800 slimtop
> > Would I have to do anything special to see it? If anyone has any > > other ideas of what to do let me know - I'm wondering if throttling > > down the CPU turns down the fan. > > It's possible that the EC is solely responsible for the fan, or that > Sony decided in their infinite wisdom to do it all in a driver somewhere. I have a new theory - do we need to enable some sort of suspend on halt for Intel chips? I see we do this for various cyrix chips, and I saw in a search that pentiums with MMX have "auto halt" and "low power on auto halt" options: http://www-student.informatik.uni-bonn.de:8001/~petera/lpp/ Do we enable these? I don't see any CPU_SUSP_HLT options in initcpu.c for Intel chips. Chip is > CPU: Pentium III/Pentium III Xeon/Celeron (801.82-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x686 Stepping = 6 > >Features=0x383f9ff > Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug in src tree?
Nope.. sorry...
I now use the correct command(namely make buildkernel) only problem now
is that I cant make A succesfully make world before that so my following
question is how important is it to get it(the computer) to succesfully
boot up?
The story is that FreeBSD4.0 boots with out problem but there is a problem
concering my networkcard(vr0 watchdog timeout locks allports for around
10sec)
If I install FreeBSD4.1.1 or FreeBSD4.2 I get kernel page
fault(?) trap 11? during boot and have to reinstall to FreeBSD4.0 again.
I talked to a person in #freebsdhelp (efnet) how said that it probably has
to do with the fact I am using an D-link DFE530-TX networkcard that is
digital(!?) and not compiled into the kernel.
Down below is the error result from my make world in /usr/src (using
today source)
cc -O -pipe -I. -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools
-I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc.295
-I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc.295/config -c
/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc.295/genrecog.c
{standard input}: Assembler messages:
{standard input}:3555: Error: Rest of line ignored. First ignored
character is `p'.
*** Error code 1
Stop in /usr/src/gnu/usr.bin/cc/cc_tools.
TIA
Jerker
On Fri, 12 Jan 2001, Neil Blakey-Milner wrote:
> On Fri 2001-01-12 (08:17), electro wrote:
> > I try to compile a new kernel with the latest source and I always end up
> > with this (in the end). Any suggestions?
> > I mean the error message is fun...dont match any know i386 instruction
> >
> > cc -c -x
> > assembler-with-cpp -DLOCORE -O -Wall -Wredundant-decls -Wnested-externs -Wst
> > rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
> > -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../..
> > /include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include
> > opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/bioscall.s
> > /tmp/ccmJEqq7.s: Assembler messages:
> > /tmp/ccmJEqq7.s:758: Error: operands given don't match any known 386
> > instruction
> > /tmp/ccmJEqq7.s:822: Error: operands given don't match any known 386
> > instruction
> > *** Error code 1
> >
> > Stop in /usr/src/sys/compile/PROFESSOR.010110.
>
> You're not using buildkernel, and thus you don't have the necessarily
> updated tools to handle that source.
>
> Neil
> --
> Neil Blakey-Milner
> [EMAIL PROTECTED]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
-
http://www.ludd.luth.se/~electro
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
On Fri, 12 Jan 2001 22:01:03 +1030, Matthew Thyer wrote: > This seems a bit of a pain. > > Is there anyway to go back (if I'm correct) to a dynamic swap user. > I suppose I'm talking about a real tmpfs ? The way it is now is the way it's always been. Think about what you mean when you say "dynamic swap user". You want mfs to use more swap than you have? :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Sheldon Hearn wrote: > > On Fri, 12 Jan 2001 00:54:40 +1030, Matthew Thyer wrote: > > > > /boot/kernel/kernel: swap_pager_getswapspace: failed > > > > > > This seems to have started in the last week. > > > > > > > I saw the same problem until I stopped using mfs on /tmp. > > > > Stop using mfs for /tmp. > > Are you sure it's not just /tmp "filling up" swap? If it's just that, > all Edwin needs to do is limit the size of his MFS /tmp. I do this in > /etc/fstab: > > /dev/ad0s1b /tmp mfs rw,-s=245760 0 0 > > See the description of the -s option in mount_mfs(8). Well, limits are nice if you can predict your usage in advance. In my case I was using an unlimited mfs (as I have for years): /dev/ad0s2b/tmpmfs rw 0 0 I seem to remember some changes to mfs a while ago and (without checking cvsweb) I assume that's when this: -s size The size of the file system in sectors. This value defaults to the size of the raw partition specified in special (in other words, newfs will use the entire partition for the file system). became the default behaviour. This seems a bit of a pain. Is there anyway to go back (if I'm correct) to dynamic usage of swap ? I suppose I'm talking about a real tmpfs ala Solaris. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Sheldon Hearn wrote: > > On Fri, 12 Jan 2001 00:54:40 +1030, Matthew Thyer wrote: > > > > /boot/kernel/kernel: swap_pager_getswapspace: failed > > > > > > This seems to have started in the last week. > > > > > > > I saw the same problem until I stopped using mfs on /tmp. > > > > Stop using mfs for /tmp. > > Are you sure it's not just /tmp "filling up" swap? If it's just that, > all Edwin needs to do is limit the size of his MFS /tmp. I do this in > /etc/fstab: > > /dev/ad0s1b /tmp mfs rw,-s=245760 0 0 > > See the description of the -s option in mount_mfs(8). Well, limits are nice if you can predict your usage in advance. In my case I was using an unlimited mfs (as I have for years): /dev/ad0s2b/tmpmfs rw 0 0 I seem to remember some changes to mfs a while ago and (without checking cvsweb) I assume that's when this: -s size The size of the file system in sectors. This value defaults to the size of the raw partition specified in special (in other words, newfs will use the entire partition for the file system). became the default behaviour. This seems a bit of a pain. Is there anyway to go back (if I'm correct) to a dynamic swap user. I suppose I'm talking about a real tmpfs ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall.8 Breaking buildworld
Why does sysinstall have to move at all? Whenever I buildworld/installworld, I always go into release/sysinstall and do a make all install, as suggested in handbook/makeworld.html Why can't the man page be included and installed with this? Bap. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Crash dumps during initialisation
How can I get the kernel to make crash dumps if it fails before the 'dumpon' command is issued ? There used to be a line in the kernel configuration file beginning with the keyword 'config' which had options 'dumps on' or 'crash on' but this has gone. Regards, Harry Harry Newton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Head's up: Yarrow-style periodic entropy saving
On Thu, 11 Jan 2001, Doug Barton wrote: > For the sake of those who don't follow commit messages (shame on you!), > here's your fair warning regarding this change. This is the promised update > that periodically (every 3 minutes by default) saves 2k of randomness to a > set of rotating files stored by default in /.entropy. That location was > chosen so that it could be loaded as early as possible in the boot process. On / ? that's quite inconvenient for systems running with read-only root FS... Andrzej Bialecki // <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug in src tree?
On Fri 2001-01-12 (08:17), electro wrote: > I try to compile a new kernel with the latest source and I always end up > with this (in the end). Any suggestions? > I mean the error message is fun...dont match any know i386 instruction > > cc -c -x > assembler-with-cpp -DLOCORE -O -Wall -Wredundant-decls -Wnested-externs -Wst > rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../.. > /include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include > opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/bioscall.s > /tmp/ccmJEqq7.s: Assembler messages: > /tmp/ccmJEqq7.s:758: Error: operands given don't match any known 386 > instruction > /tmp/ccmJEqq7.s:822: Error: operands given don't match any known 386 > instruction > *** Error code 1 > > Stop in /usr/src/sys/compile/PROFESSOR.010110. You're not using buildkernel, and thus you don't have the necessarily updated tools to handle that source. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: YES! laptop installing
On Thu, Jan 11, 2001 at 11:41:17PM -0700, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Mark Murray writes: > : My Netgear FA510 (dc0) probes (sorta) but comes up with a crazy > : MAC address, and then doesn't work. It doesn't even go UP. > : > : MAC=00:00:80:00:00:80, FWIW. > > There's about 4 different dc based cards that don't work because they > don't get the nic address right. Well, that's what I think. Use an /etc/start_if.dc0 script that uses `ifconfig' to set the eithernet address. wpaul show me how to find mine, and I just put in the start_if.dc0 and forget about it. :) -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Running Linux kernel modules.
* Andrew Gallatin <[EMAIL PROTECTED]> [010111 20:13] wrote: > > > On Thursday, January 11, 2001 3:12 PM, Alfred Perlstein > > [SMTP:[EMAIL PROTECTED]] wrote: > > > * Carl Makin <[EMAIL PROTECTED]> [010111 14:52] wrote: > > > > > > > > There are a couple of linux kernel modules that I'd love to run under > > > > FreeBSD. I've always assumed that I'd have to rewrite them substantially > > > > to make that happen. > > > > > > > > Can anyone give me some pointers on how hard it could be to port a linux > > > > kernel module to FreeBSD? > > > > > > Depends on how familiar you are with kernel internals, for instance > > > after taking a quick look at the kernel module needed to run vmware > > > it was pretty clear that someone with the experience and time could > > > have it done in under a week, about 2 weeks later some maniac ( :) ) > > > surfaced who had done just that. > > The biggest problem I've had porting linux drivers is that linux > exports enough internals to allow drivers to distinguish between > multiple opens of the same device. Eg: [snip] > > Isn't this gross? Is there a better way? Beyond gross. :) I've heard of many requests for this special functionality in FreeBSD, things as you've mentioned (vmware, your driver) as well as ptys. If you wanted to fix our interface I'd be glad to help review it and assist if possible. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
