Re: mountroot problem
I found it, will commit in a sec. Sorry.
Poul-Henning
In message 19990508231949.a93...@hal.mpn.cp.philips.com, Jos Backus writes:
Some more information:
In sys/i386/i386/autoconf I'm seeing the following happen:
static void
setroot()
{
int majdev, mindev, unit, slice, part;
dev_t newrootdev;
char partname[2];
char *sname;
if (boothowto RB_DFLTROOT || (bootdev B_MAGICMASK) != B_DEVMAGIC)
return;
majdev = B_TYPE(bootdev);
printf(setroot: majdev=%d,bdevsw(majdev)=%p\n,majdev,bdevsw(majdev));
if (majdev = nblkdev || bdevsw(majdev) == NULL)
return;
unit = B_UNIT(bootdev);
slice = B_SLICE(bootdev);
etc.
which prints
setroot: majdev=4,bdevsw(majdev)=0
Thus the function returns, without setting the name of the root device further
on in the code (it would appear that that is where it happens).
--
Jos Backus _/ _/_/_/ Reliability means never
_/ _/ _/ having to say you're sorry.
_/ _/_/_/ -- D. J. Bernstein
_/ _/ _/_/
jos.bac...@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer;
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: mountroot problem
Ah- that's why root stuff is broke... good To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: bdevsw has changed its character
Greg Lehey wrote: A day or so ago, bdevsw changed from being an array of struct cdevsws to an inline function. That's not a problem in itself: do a make world and all will be well. It does, however, mean that klds which were compiled before the change will no longer load. I had a report today of one person who forgot to do this, and his source tree is on a vinum volume, and he can't load vinum. Beware! That isn't all.. If you are using kld modules, it is a Really Good Idea to keep your kld modules compiled and in sync with your kernel while internal interfaces are changing. kget(8) also will need a recompile. People who are running -current for stability had better be damn careful and be very selective about what they choose to run as a stable snapshot. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: bdevsw has changed its character
On Sunday, 9 May 1999 at 16:15:51 +0800, Peter Wemm wrote: Greg Lehey wrote: A day or so ago, bdevsw changed from being an array of struct cdevsws to an inline function. That's not a problem in itself: do a make world and all will be well. It does, however, mean that klds which were compiled before the change will no longer load. I had a report today of one person who forgot to do this, and his source tree is on a vinum volume, and he can't load vinum. Beware! That isn't all.. If you are using kld modules, it is a Really Good Idea to keep your kld modules compiled and in sync with your kernel while internal interfaces are changing. Right, it was just pretty unfortunate in this case (and I heard of another one) that the person had his source tree mounted on a vinum volume, so he could no longer access it :-) If this happens to anybody else, there's a version of the vinum kld compiled this morning on ftp://ftp.lemis.com/pub/vinum/vinum.ko. kget(8) also will need a recompile. People who are running -current for stability had better be damn careful and be very selective about what they choose to run as a stable snapshot. I think the real problem is that the klds get built with make world and not with a kernel build. How about changing that? I've got the opposite problem on another machine: I did a make world, but not a reboot, and now my Linux emulation is broken. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: bdevsw has changed its character
In message 19990509081553.6ab261...@spinner.netplex.com.au, Peter Wemm write s: Greg Lehey wrote: A day or so ago, bdevsw changed from being an array of struct cdevsws to an inline function. That's not a problem in itself: do a make world and all will be well. It does, however, mean that klds which were compiled before the change will no longer load. I had a report today of one person who forgot to do this, and his source tree is on a vinum volume, and he can't load vinum. Beware! That isn't all.. If you are using kld modules, it is a Really Good Idea to keep your kld modules compiled and in sync with your kernel while internal interfaces are changing. kget(8) also will need a recompile. People who are running -current for stability had better be damn careful and be very selective about what they choose to run as a stable snapshot. Amen brother. In general any commit to sys/kern/* or sys/sys/* should make you pay a LOT of attention. -- 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: HEADS UP: bdevsw has changed its character
In message 19990509174914.a22...@freebie.lemis.com, Greg Lehey writes: People who are running -current for stability had better be damn careful and be very selective about what they choose to run as a stable snapshot. I think the real problem is that the klds get built with make world and not with a kernel build. How about changing that? I've got the opposite problem on another machine: I did a make world, but not a reboot, and now my Linux emulation is broken. Well, it is a problem you cannot solve in general, in particular as we start to see 3rd parth KLDs... -- 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
Building klds with kernel (was: HEADS UP: bdevsw has changed its character)
On Sunday, 9 May 1999 at 10:21:57 +0200, Poul-Henning Kamp wrote: In message 19990509174914.a22...@freebie.lemis.com, Greg Lehey writes: People who are running -current for stability had better be damn careful and be very selective about what they choose to run as a stable snapshot. I think the real problem is that the klds get built with make world and not with a kernel build. How about changing that? I've got the opposite problem on another machine: I did a make world, but not a reboot, and now my Linux emulation is broken. Well, it is a problem you cannot solve in general, in particular as we start to see 3rd parth KLDs... Well, as long as the third party klds are in source, that's fine. They're going to be a real problem otherwise anyway: what will they do with bdevsw? They'll have to be recompiled one way or the other if they're device drivers. Anyway, they're the exception. Most klds are part of the source tree, and they're logically part of the kernel, not of userland, so it makes more sense to build them when building the kernel. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: bdevsw has changed its character
Greg Lehey wrote: On Sunday, 9 May 1999 at 16:15:51 +0800, Peter Wemm wrote: Greg Lehey wrote: A day or so ago, bdevsw changed from being an array of struct cdevsws to an inline function. That's not a problem in itself: do a make world and all will be well. It does, however, mean that klds which were compiled before the change will no longer load. I had a report today of one person who forgot to do this, and his source tree is on a vinum volume, and he can't load vinum. Beware! That isn't all.. If you are using kld modules, it is a Really Good Idea to keep your kld modules compiled and in sync with your kernel while internal interfaces are changing. Right, it was just pretty unfortunate in this case (and I heard of another one) that the person had his source tree mounted on a vinum volume, so he could no longer access it :-) If this happens to anybody else, there's a version of the vinum kld compiled this morning on ftp://ftp.lemis.com/pub/vinum/vinum.ko. Which is why I use pseudo-device vinum :-) But the risk there is that the ioctl's change as /sbin/vinum is compiled seperately. kget(8) also will need a recompile. People who are running -current for stability had better be damn careful and be very selective about what they choose to run as a stable snapshot. I think the real problem is that the klds get built with make world and not with a kernel build. How about changing that? I've got the opposite problem on another machine: I did a make world, but not a reboot, and now my Linux emulation is broken. I have a system in mind to replace config(8) entirely and will allow flexible kernel and module building, but it's barely even on the drawing board. It will make sys/modules obsolete, which is the main reason why I don't want code in there. (The screensavers are misplaced). I also have half thought about moving some particular kernel-specific tools under this system, but I'm not at all sure about that. On one hand, libkvm etc could benefit, along with ps etc which are hightly kernel specific. But it brings in a whole new set of chicken/egg problems. (like, if the kernel build supervisor is maintained by the same tool, then there will be problems.) Greg Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: bdevsw has changed its character
Greg Lehey wrote: I think the real problem is that the klds get built with make world and not with a kernel build. How about changing that? I've got the opposite problem on another machine: I did a make world, but not a reboot, and now my Linux emulation is broken. Same problem with loader, with the added irony that loader is located under sys/... -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
KDE problems with -current.
i had problems with the old kdelibs packages(1.1), all the programs i compiled couldn't link. i think it's an EGCS issue, so i decided to compile the kdelibs (1.1.1) with -current. it compiled, but no KDE software worked (including kwm). tried to go back to the old pkg, but got the same error, i removed all kde components and reinstalled the kde-1.1 packages, got the same errors, can't get KDE to run at all now... what do i do ? P.S : kdebase-1.1.1 port errors with : gmake[3]: Entering directory `/usr/ports/x11/kdebase11/work/kdebase-1.1.1/kfm' /bin/sh ../libtool --silent --mode=link c++ -O -pipe -I/usr/local/include -DHAV E_GETUSERSHELL -DTIME_WITH_SYS_TIME -L/usr/local/lib -L/usr/X11R6/lib -rpath /u sr/local/lib -rpath /usr/X11R6/lib -o kfm kfmgui.o kfmview.o kbind.o main.o kfm dlg.o bookmark.o kfmprops.o kfmserver_ipc.o kfmserver_ipc2.o kfmserver.o kioserv er.o kioserver_ipc.o kioserver_ipc2.o kfmipc.o root.o kfmman.o kiojob.o htmlcach e.o autostart.o kfmtree.o krenamewin.o passworddialog.o kURLcompletion.o debug.o kfmw.o kfmpaths.o kfmjob.o kfmexec.o kmimemagic.o kfinder.o utils.o open-with.o finddlg.o kcookiejar.o kcookiewin.o popup.o kintlist.o -lkhtmlw -lkimgio -ljpeg -ltiff -ljpeg -lz -lpng -lz -lm -lqt -lX11 -lm -ljscript -lkfile -lkfm -lkdeco re -lXext -lqt -lX11 -lkdeui -lkdecore -lXext -lqt -lX11 root.o: file not recognized: File truncated gmake[3]: *** [kfm] Error 1 gmake[3]: Leaving directory `/usr/ports/x11/kdebase11/work/kdebase-1.1.1/kfm' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/x11/kdebase11/work/kdebase-1.1.1/kfm' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/x11/kdebase11/work/kdebase-1.1.1' gmake: *** [all-recursive-am] Error 2 *** Error code 2 == 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
NPX code reports negative i586_bzero() bandwidth
I already submitted this (about a week ago) :( Please take a look at negative bandwith reported by i586_bzero... (kernel cvsup'ed and rebuilded several minutes ago). Looks like data type owerflow (my machine have K6-2 266 running on 250MHz and 1MB of L2 cache). Calibrating clock(s) ... TSC clock: 250535974 Hz, i8254 clock: 1193028 Hz Timecounter i8254 frequency 1193028 Hz CPU: AMD-K6(tm) 3D processor (250.54-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x580 Stepping=0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX 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: 64M bytes Write Allocate 15-16M bytes: Enable Hardware Write Allocate Control: Disable real memory = 67108864 (65536K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x00265000 - 0x03ffdfff, 64589824 bytes (15769 pages) sio0: system console avail memory = 62922752 (61448K bytes) Found BIOS32 Service Directory header at 0xc00faff0 Entry = 0xfb470 (0xc00fb470) Rev = 0 Len = 1 PCI BIOS entry at 0xb4a0 Other BIOS signatures found: ACPI: $PnP: 000fc0b0 Preloaded elf kernel kernel at 0xc025. Initializing PnP override table Probing for PnP devices: Trying Read_Port at 203 PnP: CSN 1 COMP_DEVICE_ID = 0x0006d041 CSN 1 Vendor ID: CTL0028 [0x28008c0e] Serial 0x1013c276 Comp ID: PNP0600 [0x0006d041] Called nullpnp_probe with tag 0x0001, type 0x28008c0e Called nullpnp_probe with tag 0x0001, type 0x0006d041 pci_open(1): mode 1 addr port (0x0cf8) is 0x8060 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=05971106) npx0: math processor on motherboard npx0: INT 16 interface i586_bzero() bandwidth = -2082577916 bytes/sec bzero() bandwidth = 184877056 bytes/sec Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE problems with -current.
Tomer Weller wrote: re -lXext -lqt -lX11 -lkdeui -lkdecore -lXext -lqt -lX11 root.o: file not recognized: File truncated Maybe you are building ports over NFS - some time ago NFS client code on -CURRENT was broken, however now it seems to be fixed. Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mountroot problem
On Sun, May 09, 1999 at 09:52:31AM +0200, Poul-Henning Kamp wrote: I found it, will commit in a sec. Sorry. No problem, and thanks. Kept me off the streets for an evening at least. Cheers, -- Jos Backus _/ _/_/_/ Reliability means never _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE problems with -current.
Nope. Maxim Sobolev wrote: Tomer Weller wrote: re -lXext -lqt -lX11 -lkdeui -lkdecore -lXext -lqt -lX11 root.o: file not recognized: File truncated Maybe you are building ports over NFS - some time ago NFS client code on -CURRENT was broken, however now it seems to be fixed. Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- == 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
de driver problem
Hello folks I cvsupped,made world, built a kernel today and from now on the de interfaces only comes up in 100BaseTX, what causes it not to negotiate ? My Apr_29 kernel doesnt behave like this. The link lamp flickered like hell so it was quite a nice atmosphere for awhile , but i got tired of it :) /Khaled, Telia Network Services Mail: kha...@telia.net Cell: 070-6785492 Work: 08-4567281 :hacker: /n./ [originally, someone who makes furniture with an axe] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: bdevsw has changed its character
I think the real problem is that the klds get built with make world and not with a kernel build. How about changing that? I've shot myself in the foot this way too. I'd really like to see modules built as part of the kernel and not userland. As time goes on, I think we will push more and more of the kernel into modules (rather like Solaris). This distinction of where the live kernel's bits live isn't useful. -- -- 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: KDE problems with -current.
On Sun, May 9, 1999, Tomer Weller wrote: kdebase-1.1.1 port errors with : root.o: file not recognized: File truncated Try doing: make deinstall make clean make all It looks like root.o may have been built with an older version of egcs, or perhaps it was an a.out object file. -- Chris Costelloch...@calldei.com If at first you don't succeed, you must be a programmer. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Disappearing/Reappearing Files... (fwd)
The changes that I added to soft updates two days ago only kick in when the soft dependency memory limit is hit. This certainly should not be happening at system startup, and on any machine with more than 64Mb of memory, almost never. I did make a couple of minor textual changes to other parts of the code which should not have had any effect, but just in case they did, I have put them back to their previous state in today's delta. I would appreciate your trying out the current delta (1.27) and seeing if the problem persists. If it does, please try out the version before I did my recent rework (1.24). If that version has the problem as well, then I believe that some other change is triggering the problem, as 1.24 represents a version that has been in production for half a year without trouble. Kirk McKusick =-=-=-=-=-=-=-= Date: Sun, 9 May 1999 01:39:33 -0700 (PDT) From: Julian Elischer jul...@whistle.com To: mckus...@mckusick.com Subject: Re: Disappearing/Reappearing Files... (fwd) FYI also some other people are commenting on odd behaviour where a created file doesn't show up for a while... almost as if the readdir() is returning the 'backed out' version of the directory data. julian -- Forwarded message -- Date: Sat, 8 May 1999 14:11:10 -0700 (PDT) From: John Polstra j...@polstra.com To: curr...@freebsd.org Subject: Re: Disappearing/Reappearing Files... In article 199905082048.naa34...@vashon.polstra.com, John Polstra j...@polstra.com wrote: I'm seeing something possibly related (possibly not) on an Alpha with this morning's -current. First I was getting unaligned accesses and core dumps from the cp in /etc/rc that updates the /etc/motd file. (I added set -v to /etc/rc to catch it.) But I could do the copy by hand once the system was up. Now on the latest reboot I got this from it: + cp /tmp/_motd /etc/motd + chmod 644 /etc/motd chmod: : No such file or directory chmod in free(): warning: recursive call chmod in free(): warning: recursive call chmod in free(): warning: recursive call chmod in free(): warning: recursive call (Hmm, why didn't the filename come out in chmod's error message?) I'm running with soft-updates but I'll try turning them off. I tried about 10 reboots, half with and half without soft-updates enabled on the various filesystems. With soft-updates disabled, I didn't see the above problem at all. With soft-updates enabled, I saw it most of the time but not always. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong 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: latest ppp with PAP/CHAP coredumps
[.] #0 0x805b519 in FsmRecvConfigRej (fp=0x80ae608, lhp=0xbfbfce98, bp=0x0) ^^ [.] I'm on the case :-) The fsm_Input code now does an mbuf_Read() which will return a NULL mbuf if everything has been read from it. I'm just committing some changes now that make ppp a little more careful about this sort of things. Thanks. -- Chris Costelloch...@calldei.com Avoid temporary variables and strange women. -- Brian br...@awfulhak.orgbr...@freebsd.org http://www.Awfulhak.org br...@openbsd.org Don't _EVER_ lose your sense of humour ! br...@uk.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Disappearing/Reappearing Files... (fwd)
Kirk McKusick wrote: The changes that I added to soft updates two days ago only kick in when the soft dependency memory limit is hit. This certainly should not be happening at system startup, and on any machine with more than 64Mb of memory, almost never. In my case it looks like your changes weren't the problem. I've had a failure without soft updates, and I'm fairly confident that it's a HW problem at this point. (I've only had the machine for a few days.) John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
kernel.old
I was thinking about Peter Wemm's recent change to the kernel Makefile, making a way to install multiple kernels without fragging your last known good kernel, and it got me to thinking, scragging kernel.old, now that we have good kld's, isn't the only way to find yourself well and truly screwed if your new kernel decides it's shy. If your new /modules directory has some incompatibilities with your old kernel, well, you aren't going to be able to save yourself by booting kernel.old. Something on the order of modules.old is going to need to be implemented. Seeing as the modules build isn't in the same part of the (logical) world as the kernel, well, this is somewhat more complicated than it would otherwise be. Is there any chance of the installation of modules being made the responsibility of the kernel Makefile, and not src/modules/Makefile.* ? If that were true, then the kernel installation could be tied to modules installation, and the rotation of the kernel could be extended to rotation of the modules directory. Ideally, I'd want the entire build of modules to be in that Makefile, but I guess that's dreaming. Think about it, it makes some sense, tho, doesn't it? +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kernel.old
In message pine.bsf.4.10.9905091608060.401-100...@picnic.mat.net, Chuck Robe y writes: Something on the order of modules.old is going to need to be implemented. Not to mention /boot/kernel.old.config ... I think you are seeing -current as the norm. You shouldn't. Under -stable the modules should (tm) continue to work since there are not made API changes in -stable. -- 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: de driver problem
On Sun, 9 May 1999, Khaled Daham wrote: Hello folks I cvsupped,made world, built a kernel today and from now on the de interfaces only comes up in 100BaseTX, what causes it not to negotiate ? My Apr_29 kernel doesnt behave like this. The link lamp flickered like hell so it was quite a nice atmosphere for awhile , but i got tired of it :) /Khaled, Telia Network Services Mail: kha...@telia.net Cell: 070-6785492 Work: 08-4567281 :hacker: /n./ [originally, someone who makes furniture with an axe] Some tulip boards in alpha systems don't autonegociate properly so the SRM has a way of forcing them to a particular mode. A change was made recently to respect the SRM setting instead of using autoneg. The variable is typically called ewa0_mode. To find the right setting, type set ewa0_mode from the SRM prompt and it will give you a list of settings. Choose one, then type e.g.: set ewa0_mode Twisted-Pair -- 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: ppp is totally broken
[.] I'm using the 3.1R PPP right now, until the problem is resolved. I'm sending a problem report, as well. It should be resolved now. A NULL mbuf value is valid - it just means that there's nothing in it. I changed fsm_Input() with the last commits, and didn't notice the MBUF_CTOP(bp) calls that you pointed out :-( MBUF_CTOP is now more robust, as are all the fsm functions and mbuf_Prepend() (which would have died when doing protocol rejects). -- Chris Costelloch...@calldei.com RAM DISK is not an installation procedure! -- Brian br...@awfulhak.orgbr...@freebsd.org http://www.Awfulhak.org br...@openbsd.org Don't _EVER_ lose your sense of humour ! br...@uk.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kernel.old
Something on the order of modules.old is going to need to be implemented. Not to mention /boot/kernel.old.config ... I think you are seeing -current as the norm. You shouldn't. Under -stable the modules should (tm) continue to work since there are not made API changes in -stable. BUT we shouldn't make it easy for our developers (who do need to run -CURRENT) to kill themselves. Our development time is limited, and recovering from a bum kernel can be a PITA in some situations, so lets not waste our development time when we don't need to. -- -- 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: HEADS UP: bdevsw has changed its character
In message 19224.926238...@critter.freebsd.dk Poul-Henning Kamp writes: : In general any commit to sys/kern/* or sys/sys/* should make you pay : a LOT of attention. Also, when the number of commits in these areas has been as high as it has been lately, one should think twice before updating... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
config(8) changes and i4b
Anyone very -CURRENT and running i4b ? I just upgraded to the new config syntax and it seems that it doesn't grok pseudo-devices with numbers in the name correctly... With this config(8) works but some dependencies are not generated and make fails. -=-=- # Q.921 / layer 2 - i4b passive cards D channel handling pseudo-device i4bq921 # Q.931 / layer 3 - i4b passive cards D channel handling pseudo-device i4bq931 # layer 4 - i4b common passive and active card handling pseudo-device i4b pseudo-device i4btrc4 pseudo-device i4bctl pseudo-device i4brbch 4 pseudo-device i4btel2 pseudo-device i4bipr4 pseudo-device i4bisppp 4 -=-=- -=-=- loading kernel.debug i4b_l2.o: In function `i4b_dl_data_req': /sys/compile/KELTIA_T/../../i4b/layer2/i4b_l2.c(.text+0x16f): undefined reference to `i4b_Dfreembuf' i4b_l2.o: In function `i4b_l2_unit_init': /sys/compile/KELTIA_T/../../i4b/layer2/i4b_l2.c(.text+0x2aa): undefined reference to `i4b_Dfreembuf' i4b_l2.o: In function `i4b_ph_data_ind': /sys/compile/KELTIA_T/../../i4b/layer2/i4b_l2.c(.text+0x5b2): undefined reference to `i4b_Dfreembuf' i4b_l2fsm.o: In function `F_AE01': /sys/compile/KELTIA_T/../../i4b/layer2/i4b_l2fsm.c(.text+0x609): undefined reference to `i4b_Dcleanifq' i4b_l2fsm.o: In function `F_AE05': /sys/compile/KELTIA_T/../../i4b/layer2/i4b_l2fsm.c(.text+0x64d): undefined reference to `i4b_Dcleanifq' i4b_l2fsm.o: In function `F_AE06': ... -=-=- Without the around the names, config(8) complains with Syntax error. Any idea ? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: config(8) changes and i4b
On Sun, 9 May 1999, Ollivier Robert wrote: Anyone very -CURRENT and running i4b ? I just upgraded to the new config syntax and it seems that it doesn't grok pseudo-devices with numbers in the name correctly... I'm running a kernel from yesterday, patched with i4b 0.80. With this config(8) works but some dependencies are not generated and make fails. It works for me. Try removing your kernel compile directory. Without the around the names, config(8) complains with Syntax error. Yes, this is a known bug in config. But with the quotes it works for me just fine. Blaz Zupan, b...@amis.net, http://www.herbie.amis.net Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kernel.old
I wish :-( It seems that some people think that it is OK to make changes to stable even though those changes break things which used to work. IMHO, branches of the kernel SHOULD be like shared libraries. (It is OK to ADD previously absent features or CORRECT internal errors, but NOT OK to delete features or change API's) On Sun, 9 May 1999, Poul-Henning Kamp wrote: I think you are seeing -current as the norm. You shouldn't. Under -stable the modules should (tm) continue to work since there are not made API changes in -stable. Personally, I think that we should treat kernels just like another library. They export an API (sysctl) that libc, et. al. uses and another API that the kernel modules use. Any change that breaks code which is compliant with those API's belongs in a new release branch. PERIOD. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: config(8) changes and i4b
Ollivier Robert writes: Anyone very -CURRENT and running i4b ? I just upgraded to the new config syntax and it seems that it doesn't grok pseudo-devices with numbers in the name correctly... With this config(8) works but some dependencies are not generated and make fails. -=-=- # Q.921 / layer 2 - i4b passive cards D channel handling pseudo-device i4bq921 # Q.931 / layer 3 - i4b passive cards D channel handling pseudo-device i4bq931 # layer 4 - i4b common passive and active card handling pseudo-device i4b ^ is there really a missing here ? sorry, not yet because config is changing so quickly at the moment. All I can say is that i4b_Dfreembuf is located in layer2/i4b_mbuf.c. You could always add it manually to Makefile until config starts working again ;-) --- 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
4.0-19990509-CURRENT upgrade
I'm running 4.0-19990503-CURRENT. In my case, freebsd swap is on /dev/wd0s3b (3-th partition) I'm trying to upgrade to last 4.0-0509-current. I got error msg: Unable to make device node for /dev/wd0s3b in /dev! The creation of filesystems will be aborted. On DEBUG screen I got: DEBUG: MakeDev: Unknown major/minor for devtype 0s3b Val _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
-current make world failure (compat22)
Hi, The following is error related to compat22 is causing a make release to fail... Has mtree been updated approriately? thanks! John === lib/compat/compat22 cd /usr/src/lib/compat/compat22 ; make install DESTDIR=/R/stage/trees/compat22 SHARED=copies install -c -o root -g wheel -m 444 libalias.so.2.4 libc.so.3.1 libc_r.so.3.0 libcalendar.so.2.0 libcom_err.so.2.0 libcurses.so.2.0 libdialog.so.3.1 libedit.so.2.0 libf2c.so.2.0 libftpio.so.4.0 libg++.so.4.0 libgmp.so.3.0 libgnuregex.so.2.0 libipx.so.2.0 libkvm.so.2.0 libm.so.2.0 libmp.so.3.0 libmytinfo.so.2.0 libncurses.so.3.1 libopie.so.2.0 libpcap.so.2.2 libreadline.so.3.0 librpcsvc.so.2.0 libscrypt.so.2.0 libscsi.so.2.0 libskey.so.2.0 libss.so.2.0 libstdc++.so.2.0 libtelnet.so.2.0 libtermcap.so.2.1 libutil.so.2.2 libvgl.so.1.0 libxpg4.so.2.0 libz.so.2.0 /R/stage/trees/compat22/usr/lib/compat/aout usage: install [-CcDps] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-CcDps] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-g group] [-m mode] [-o owner] directory ... *** Error code 64 And looking at /R /snap/release/R/stage/trees %ls bin compat20des games manpages catpagescompat21dictinfoproflibs compat1xcompat3xdoc krb compat22 doesn't seem to exist... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE problems with -current.
On Sun, 9 May 1999, Tomer Weller wrote: Nope. Well, is root.o truncated or otherwise corrupted? Are you seeing any other filesystem problems on this machine? Did you crash/reboot during the build? Kris Maxim Sobolev wrote: Tomer Weller wrote: re -lXext -lqt -lX11 -lkdeui -lkdecore -lXext -lqt -lX11 root.o: file not recognized: File truncated Maybe you are building ports over NFS - some time ago NFS client code on -CURRENT was broken, however now it seems to be fixed. Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- == 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 - That suit's sharper than a page of Oscar Wilde witticisms that's been rolled up into a point, sprinkled with lemon juice and jabbed into someone's eye Wow, that's sharp! - Ace Rimmer and the Cat, _Red Dwarf_ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -current make world failure (compat22)
The following is error related to compat22 is causing a make release to fail... Has mtree been updated approriately? A grep in /usr/src/etc/mtree/* shows there is no special handling for compat?? dists. -- -- 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
HEADS UP: config(8) changes..
This is late, but a few hours ago, phk chopped out some old stuff from config(8) and removed some backwards compatability warnings. A summary of the changes: If you had old tty, bio, net, cam flags, these are obsolete and will now cause a syntax error rather than a warning. If you had old vector xxxintr, it will now cause a syntax error rather than a warning. Most people would have been getting these warnings for a month or so and will have taken them out already. 'config kernel root on xx0' is gone and will cause a (non-fatal) error. The old config line is mostly no longer required. I say mostly, because there are some circumstances where people used it to change the default kernel name or force a different root device to the boot device. Forcing a different root device can be done with the following (in the config file itself, or in /etc/make.conf): options ROOTDEVICE=\wd0s1e\ If you want to call your kernel something else, try this in the config file: makeoptions KERNEL=vmunix Or use add 'KERNEL=vmunix' to /etc/make.conf, or whatever. This will compile the kernel called vmunix and install it as /vmunix and deal with /vmunix.old etc. The KERNEL option has pretty much been working for some time now, although it wasn't discovered until now. What does this mean for -current users? Not a lot.. The average user can just delete the config line entirely and forget about it. The old defunct keywords need to be deleted (bio, net, tty, vector etc). It should be noted that config(8) is destined to die sooner or later and almost certainly never make it to a release branch. Removal of the port/irq/iomem/drq etc keywords is on the agenda, but it's not clear if they will go completely away since we need a way to run without loader(8) if possible. The Alpha build is (still) broken... (BTW; Don't shoot the messenger, I didn't delete it. But I do happen to think it's basically OK, apart from the loss of 'config vmunix' - that should be fairly easy to remap if a lot of people are going to be affected. Remember, even with remapping, the config lines would need an edit.) Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: config(8) changes..
On Monday, 10 May 1999 at 10:04:40 +0800, Peter Wemm wrote: It should be noted that config(8) is destined to die sooner or later and almost certainly never make it to a release branch. I suppose this makes it almost bearable. What's coming in its place? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: config(8) changes..
Peter Wemm pe...@netplex.com.au wrote: If you had old vector xxxintr, it will now cause a syntax error rather than a warning. What is the new method of specifying a non-standard interrupt function? I have some code (currently on 2.x, but I was hoping to be able to move it) where I have different interrupt functions within the same driver. I could use a single interrupt handler, but it would mean either additional latency or overhead, which I'd like to avoid. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: config(8) changes..
If you had old vector xxxintr, it will now cause a syntax error rather than a warning. What is the new method of specifying a non-standard interrupt function? I have some code (currently on 2.x, but I was hoping to be able to move it) where I have different interrupt functions within the same driver. I could use a single interrupt handler, but it would mean either additional latency or overhead, which I'd like to avoid. The driver has to know which one(s) to attach. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Correction: HEADS UP: config(8) changes..
Peter Wemm wrote: If you had old tty, bio, net, cam flags, these are obsolete and will now cause a syntax error rather than a warning. If you had old vector xxxintr, it will now cause a syntax error rather than a warning. This is wrong, the warnings are just the same as before. 'config kernel root on xx0' is gone and will cause a (non-fatal) error. 'config kernelname' (eg: config vmunix) has been tweaked to translate it into a makeoptions KERNEL=kernelname. The old config line is mostly no longer required. I say mostly, because there are some circumstances where people used it to change the default kernel name or force a different root device to the boot device. Forcing a different root device can be done with the following (in the config file itself, or in /etc/make.conf): options ROOTDEVICE=\wd0s1e\ Corretion.. ROOTDEVNAME.. Also, should be possible to tweak a translation in for this too so that 'root on foo' gets translated into: options ROOTDEVNAME=\foo\ I haven't done it because I could think of a zillion better things to do than fight with lex/yacc. :-] (like fix the Alpha build) Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
SPAM
I was quite surprised the First Time I got SPAM through this mailing list, I thought for sure there would be someone to moderate it so that no garbage gets through, I personally find it quite offensive to get SPAM on a help based mailing list, I have been thinking that maybe this list should have someone moderating it. Maybe I am way out of line, but I thought I would say my peice. -- Seamus Wassman sparh...@sparhawk.bc.ca http://www.sparhawk.bc.ca ICQ#: 7682151 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
subscribe
subscribe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
3DNow! support?
Is anyone planning on upgrading the binutils gas to a later version so that we can get 3DNow! support? I'd like to use it, but I can't seem to get binutils to work right manually. Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: config(8) changes and i4b
According to Gary Jennejohn: pseudo-devicei4b ^ is there really a missing here ? Oops. That was the error, shame on me for not seeing it. The bad thing is that config(8) never complained about that error :-( -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May 9 20:16:32 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
