Re: Any action on PR 10570 ? getting closer to 65K :-(
John Polstra writes: In article 19990429212555.12573.qm...@ewok.creative.net.au, adr...@freebsd.org wrote: Mike Tancsa writes: I am currently using a couple of FreeBSD boxes for my border routers, and it seems that the global routing table is getting closer and closer to 65K+ routes (i.e. sooner than later I am going to bump into PR 10570). I am not a systems programmer by any stretch of the imagination, so I would not know how to go about debugging anything and everything that would be effected by changing the size from a short to a long. I guess this PR only effects very few people, so I can understand it not being a priority. But are there any plans to look at it soon ? wat-border# netstat -nr | wc 59118 355941 4200959 Hey, that is an interesting pr. I'd like to tackle this one if noone minds, I have a similar environment to debug this one in, but it might take a little time. Of course nobody minds! :-) I posted a follow-up, but it went into the black hole of cvs-all. Briefly, I grepped the source tree and I believe that if you change the field to an int and then do a full make world and kernel build, it should work just fine. I recommend using an int rather than a long because on the Alpha, a long is 64 bits. (int32_t would be OK, too.) Yup. I checked the source tree for ifa_refcnt and IFAFREE, and including a couple of man page references, all the code plays with ifa_refcnt directly without assigning it to variables and vice versa. I'll submit a followup to the pr, and a patch after I've verified it doesn't panic the system, but that will be sometime early next week (I can't setup a BGP connection to flood routes in and out before then..) (I've CC:ed the original pr poster, although I'm not entirely sure if the same holds for OpenBSDs source tree..) Adrian Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
Interesting, I was considering trying this with a new UUNET connection with gated, but they're sending me 69,000+ routes. Glad I didn't try it yet. :) On Thu, 29 Apr 1999, Mike Tancsa wrote: I am currently using a couple of FreeBSD boxes for my border routers, and it seems that the global routing table is getting closer and closer to 65K+ routes (i.e. sooner than later I am going to bump into PR 10570). I am not a systems programmer by any stretch of the imagination, so I would not know how to go about debugging anything and everything that would be effected by changing the size from a short to a long. I guess this PR only effects very few people, so I can understand it not being a priority. But are there any plans to look at it soon ? wat-border# netstat -nr | wc 59118 355941 4200959 ---Mike Mike Tancsa,tel 01.519.651.3400 Network Administrator, m...@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada 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
Porting Greg Lehey's rawio.c from FreeBSD to Linux...
Folks, I don't want to get into any OS wars here, but I'd like to do some low-level disk benchmarking of a Linux system using the same tool I used for that under FreeBSD, namely Greg Lehey's rawio (see ftp://ftp.lemis.com/pub/rawio.tar.gz). This program was originally written to test his vinum software mirroring/striping/RAID device driver for FreeBSD (see http://www.lemis.com/vinum.html), but I believe that it would be generally useful to do low-level disk testing under most any *nix OS. Anyway, if there's anyone out there with any experience in porting programs that do low-level disk I/O, I'd appreciate it if you could take a look at this program and give me some pointers on what it would take to get it to compile and run under Linux (specifically, Debian Linux with kernel 2.2.6). Also, since I'm not subscribed to either of these mailing lists and I can't keep up with the newsgroup gateway for them, I would appreciate it if you would also e-mail me any responses you might have on this subject. TIA! -- Brad Knowles b...@shub-internet.org http://www.shub-internet.org/brad/ http://wwwkeys.pgp.net:11371/pks/lookup?op=getsearch=0xE38CCEF1 Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [ OK ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
On Fri, Apr 30, 1999 at 04:28:55PM +0800, adr...@freebsd.org wrote: I'll submit a followup to the pr, and a patch after I've verified it doesn't panic the system, but that will be sometime early next week (I can't setup a BGP connection to flood routes in and out before then..) Uh, from reading the PR it looks like it can be triggered by creating a little more than 2^16 routes to the same destination, and then deleting some of them to fall back under 2^16. I'm going to give it a try now and I'll send you the script if that works. I'm also making a world with short changed to int to see if it works. Wouldn't it be sensible to issue a warning (or panic) when increasing the reference count reaches 0, rather than causing a later kernel segfault? It would involve some overhead though, and I'm not sure having 2^32 routes is currently realistic since most machines don't even have that many bytes of RAM, but it might be true one day... -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New ATA drivers problem? (Was: New kernels won't boot)
On Thu, 29 Apr 1999, Soren Schmidt wrote: It seems Brian Feldman wrote: Ever going to help with my atapi-fd problems? I found examples of the corruptions, including lots of NULLs... Well, so long as I cannot get my hands on the problem, its real hard to solve it. I'm trying to get ahold of the same LS120 drive here but so far I havn't found any, in fact LS120 drives are extremely rare over here... As I said before, I can make some tests, but unfortunately my machine doesn't want to mount disks at all with the new ATA code... Please take a look at the message I sent about a week ago. Andrzej Bialecki // ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New ATA drivers problem? (Was: New kernels won't boot)
It seems Andrzej Bialecki wrote: Ever going to help with my atapi-fd problems? I found examples of the corruptions, including lots of NULLs... Well, so long as I cannot get my hands on the problem, its real hard to solve it. I'm trying to get ahold of the same LS120 drive here but so far I havn't found any, in fact LS120 drives are extremely rare over here... As I said before, I can make some tests, but unfortunately my machine doesn't want to mount disks at all with the new ATA code... Please take a look at the message I sent about a week ago. Unfortunately they dont tell me much :( I'll have to rearrange some disks here and try to make some new installs see if I can get the problem to appear then.. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
Pierre Beyssac writes: On Fri, Apr 30, 1999 at 04:28:55PM +0800, adr...@freebsd.org wrote: I'll submit a followup to the pr, and a patch after I've verified it doesn't panic the system, but that will be sometime early next week (I can't setup a BGP connection to flood routes in and out before then..) Uh, from reading the PR it looks like it can be triggered by creating a little more than 2^16 routes to the same destination, and then deleting some of them to fall back under 2^16. I'm going to give it a try now and I'll send you the script if that works. I'm also making a world with short changed to int to see if it works. Wouldn't it be sensible to issue a warning (or panic) when increasing the reference count reaches 0, rather than causing a later kernel segfault? It would involve some overhead though, and I'm not sure having 2^32 routes is currently realistic since most machines don't even have that many bytes of RAM, but it might be true one day... -- There isn't a reference to either IFAFREE or ifa_refcnt outside of /usr/src/sys on my tree. Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
On Fri, Apr 30, 1999 at 07:08:18PM +0800, adr...@freebsd.org wrote: There isn't a reference to either IFAFREE or ifa_refcnt outside of /usr/src/sys on my tree. But changing its size changes the offsets of ifa_metric and ifa_rt which are after it in the structure. Also, netstat, route and ifconfig, at least, more or less depend on offsets in that structures, though I don't know exactly how (some of it has been rewritten to use ioctl() or the routing socket, I believe). -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New ATA drivers problem? (Was: New kernels won't boot)
It seems Soren Schmidt wrote: As I said before, I can make some tests, but unfortunately my machine doesn't want to mount disks at all with the new ATA code... Please take a look at the message I sent about a week ago. Unfortunately they dont tell me much :( I'll have to rearrange some disks here and try to make some new installs see if I can get the problem to appear then.. Meanwhile, could you try this patch to boot2.c and ata-disk.c and install the new bootblocks created by this and see if it works with a genuine ad device set. You should then use ad?? in fstab of cause. Boot directly ie like 0:ad(0,a)/kernel from the boot promt, as the /boot/loader doesn't know about ad devices... Another thing to try is to dump down ata-disk.c so it doesn't use either multi-sector mode or DMA, as that might confuse some disks, notably WD but also Quantum has had some marginal disks... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
Pierre Beyssac writes: On Fri, Apr 30, 1999 at 07:08:18PM +0800, adr...@freebsd.org wrote: There isn't a reference to either IFAFREE or ifa_refcnt outside of /usr/src/sys on my tree. But changing its size changes the offsets of ifa_metric and ifa_rt which are after it in the structure. Also, netstat, route and ifconfig, at least, more or less depend on offsets in that structures, though I don't know exactly how (some of it has been rewritten to use ioctl() or the routing socket, I didn't say you shouldn't make world again, I was just pointing out that there shouldn't be a need to modify anything else in userland. Adrian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: New ATA drivers problem? (Was: New kernels won't boot)
(trimmed spaghetti CC: list...) On Fri, 30 Apr 1999, Soren Schmidt wrote: Unfortunately they dont tell me much :( I'll have to rearrange some disks here and try to make some new installs see if I can get the problem to appear then.. Is there any info I can dig out for you? Some useful printfs here and there? Andrzej Bialecki // ab...@webgiro.com WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: libstdc++
On Thu, Apr 29, 1999 at 08:16:35PM -0700, Thomas Dean tomd...@ix.netcom.com wrote: c++ worked on Apr 12 and Apr 20. I did cvsup/make world/make kernel on: Apr 12 Apr 21 Apr 28 Apr 29 I believe the Apr 29 make world broke it. I used xpdf last night, after the make world. today, it complains of 'undefined symbol __vt_7filebuf' Also the sound broke between Apr.21 and 22. My onboard Vibra16X doesn't work with later than Apr.21 sources. It gets probed and seems to work but emits silence. Voxware doesn't work also, complains about incorrect DMA channel, BTW I know that hardware and configuration is ok. -- Vallo Kallaste va...@matti.ee To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
int_64t support in kernel printf(), anyone ?
Ok, since my last request went so well, lets try again: Adrians patch for the rlimit file in procfs revealed that the kernel printf doesn't support 64 bit integers on i386. Anyone care to try their hands on that little detail ? -- 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: Any action on PR 10570 ? getting closer to 65K :-(
I'm running a (-CURRENT) system with the short-int patch applied and it seems to run ok so far. Here's a script to exercise the panic, you just need to define default as the IP for your default gateway. On Fri, Apr 30, 1999 at 07:28:26PM +0800, adr...@freebsd.org wrote: I didn't say you shouldn't make world again, I was just pointing out that there shouldn't be a need to modify anything else in userland. Uh, not directly anyway, but it seems that at least netstat displays the reference count as a signed short. Hence it displays a negative integer if you happen to have more than 2^15 references to the route. I suppose this will have to be given a closer look, as whatever interface it uses to get the count from the kernel might have to be changed. OTOH, the good news is that the old netstat executable still works as before. #!/bin/sh default=xxx.xxx.xxx.xxx count=65537 start=167772161 # 10.0.0.1 end=`expr $start + $count` echo Adding $count routes i=$start while [ $i -lt $end ]; do #route add $i $default #i=`expr $i + 1` done i=$start while [ $i -lt $end ]; do # echo -n 'Press RETURN to delete one route: ' # read a route delete $i $default i=`expr $i + 1` done -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
On Fri, Apr 30, 1999 at 04:08:35PM +0200, Pierre Beyssac wrote: and it seems to run ok so far. Here's a script to exercise the panic, you just need to define default as the IP for your default while [ $i -lt $end ]; do #route add $i $default #i=`expr $i + 1` Ooops, sorry, you need to uncomment the above 2 lines, too :-) -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
Pierre Beyssac wrote: Wouldn't it be sensible to issue a warning (or panic) when increasing the reference count reaches 0, rather than causing a later kernel segfault? It would involve some overhead though, and I'm not sure having 2^32 routes is currently realistic since most machines don't even have that many bytes of RAM, but it might be true one day... It would be pretty hard to create 2^32 routes, given that IPv4 only has 32-bit addresses. :-) Also, if you time it I suspect you'll find that it would take a geological lifetime on a fast machine to add that many routes. I think it makes more sense to increase the size of the reference count as discussed, rather than adding checks that add more complexity and overhead. 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
Re: Any action on PR 10570 ? getting closer to 65K :-(
On Fri, Apr 30, 1999 at 07:29:14AM -0700, John Polstra wrote: It would be pretty hard to create 2^32 routes, given that IPv4 only has 32-bit addresses. :-) And here comes... IPv6 :-) Also, if you time it I suspect you'll find that it would take a geological lifetime on a fast machine to add that many routes. Some people crack 40-bit DES in no time nowadays, so who knows what to expect... I think it makes more sense to increase the size of the reference count as discussed, rather than adding checks that add more complexity and overhead. I agree. Let's count on an int being extended to 64 bits within the next few decades :-) -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE DMA timeouts (was: Kernel won't boot from IDE disk)
On Fri, Apr 30, 1999 at 02:05:00PM +0930, Greg Lehey wrote: On Thursday, 29 April 1999 at 10:10:43 -0500, Glenn Johnson wrote: I am doing a fresh installation. I installed the April 23, 1999 snapshot of STABLE and then cvsupped the CURRENT source (4.0 CURRENT). I did a 'make world' and that went fine. I copied the GENERIC kernel config to a new file and edited the copied file. I deleted whatever drivers I did not need. I also deleted, perhaps mistakenly, but out of habit, the line: optionsFAILSAFE I don't think this is your problem. I set the flags to wdc0 and wdc1 to 'a0ffa0ff' This might be. I then added the following: options SOFTUPDATES options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options CPU_WT_ALLOC controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 device opl0 at isa? port 0x388 Upon reboot, the system would hang after doing all of the probes. Below is some of the output that I got from a boot -v. I wrote this down on paper, so the formatting may be a little off. isa_compat: didn't get drq for wdc1 ... changing root device to wd0s1a At this point it hangs. But if I press a key on the keyboard I then get: wd0s1: type 0xa5, start 0, end = 3173183, size 3173184 wd0s1: C/H/S end 197/132/63 (1659041) != end 3173183: invalid start_init: trying /sbin/init wd0: interrupt timeout (status 50rdy, seekdone error 0) wd0: wdtimeout() DMA status 4 This last two lines above are repeated 5x, then I get: wd0: Last time I say: interrupt timeout. Probably a portable PC. It is a desktop PC. I am not at the system now, so the following is from memory. It is an AMI BIOS, a Western Digital 1.6 GB IDE drive on the primary IDE and a Mitsumi 4x CD-ROM drive on the secondary IDE. What's your chipset? If it's an SiS 5591, I'd be interested in seeing your complete dmesg output (preferably with a -v output). You'll also be able to get it to work by changing the wdc0 flags to eliminate DMA. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key The IDE controller chip is an Intel PIIX3 Bus Master IDE controller. I did turn off all flags, via boot -c, then deleting the flags. That did not help. I have reinstalled 3.1 so the dmesg output below is from that. Not all of the messages from boot -v are there but I hope the relevant information is. Isn't there a way to expand the message buffer size via a kernel config option? Thanks. dmesg output from 3.1 which works: disabled, B: IRQ12, C: IRQ9, D: disabled MB0: IRQ15, MB1: found- vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base ffa0, size 4 ide_pci0: Intel PIIX3 Bus-master IDE controller rev 0x00 on pci0.7.1 intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: ffa2 intel_piix_status: secondary master/slave sample = 3, master/slave recovery = 3 intel_piix_status: secondary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: secondary master/slave sample = 3, master/slave recovery = 3 intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 1 status: 04 from port: ffaa found- vendor=0x1013, dev=0x00d0, revid=0x01 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 1, range 32, base ffafc000, size 14 map[1]: type 1, range 32, base fc00, size 25 vga0: Cirrus Logic GD5462 SVGA controller rev 0x01 on pci0.8.0 found- vendor=0x1011, dev=0x0014, revid=0x21 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=12 map[0]: type 4, range 32, base 7880, size 7 map[1]: type 1, range 32, base ffafbe80, size 7 de0: Digital 21041 Ethernet rev 0x21 int a irq 12 on pci0.9.0 de0: 21041 [10Mb/s] pass 2.1 de0: address 00:c0:f0:37:d0:2d found- vendor=0x10cd, dev=0x1300, revid=0x03 class=01-00-00,
Re: Our routed - Vern says it's old and buggy.
On Wed, 28 Apr 1999, Chuck Robey wrote: On Wed, 28 Apr 1999, Matthew Dillon wrote: :Matthew Dillon dil...@apollo.backplane.com writes: I can't quite figure why they stuck the word open in there, because it couldn't possibly be more open than RIP. Probably beqause they stuck OPEN on _everything_ for a while. It drowe me nuts:) /Johan OSPF has been around for a long time. But RIP is older, and was the first routing scheme. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message +--- 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 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
Pierre Beyssac beys...@enst.fr wrote: On Fri, Apr 30, 1999 at 07:28:26PM +0800, adr...@freebsd.org wrote: I didn't say you shouldn't make world again, I was just pointing out that there shouldn't be a need to modify anything else in userland. Uh, not directly anyway, but it seems that at least netstat displays the reference count as a signed short. It actually does printf(%6d %8ld , rt-rt_refcnt, rt-rt_use); so changing rt_refcnt to an int doesn't cause problems here, at least. Only two other things do need to be changed: src/share/doc/smm/18.net/a.t src/share/man/man9/rtentry.9 (they contain copies of the declaration) Tony. -- f.a.n.finch d...@dotat.at f...@demon.net Arthur: Oh, that sounds better, have you worked out the controls? Ford: No, we just stopped playing with them. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
buildworld breaks in doscmd if no X installed?
cvsupped last night, and I don't have X installed. Is this a matter of If you want to buildworld, install X? I'm certain i've done this before though. :) Kevin cc -nostdinc -O -pipe -I. -I/usr/X11R6/include -DDISASSEMBLER -I/usr/obj/usr/src/tmp/usr/include -o doscmd AsyncIO.o ParseBuffer.o bios.o callback.o cpu.o dos.o cmos.o config.o cwd.o debug.o disktab.o doscmd.o ems.o emuint.o exe.o i386-pinsn.o int.o int10.o int13.o int14.o int16.o int17.o int1a.o int2f.o intff.o mem.o mouse.o net.o port.o setver.o signal.o timer.o trace.o trap.o tty.o xms.o -L/usr/X11R6/lib -lX11 tty.o: In function `video_setborder': tty.o(.text+0x22b): undefined reference to `XSetWindowBackground' tty.o: In function `setgc': tty.o(.text+0x2c1): undefined reference to `XChangeGC' tty.o: In function `video_update': tty.o(.text+0x4ca): undefined reference to `XDrawImageString' tty.o(.text+0x550): undefined reference to `XDrawImageString' tty.o(.text+0x64a): undefined reference to `XChangeGC' tty.o(.text+0x6d2): undefined reference to `XFillRectangle' tty.o(.text+0x77e): undefined reference to `XChangeGC' tty.o(.text+0x7bb): undefined reference to `XFillRectangle' tty.o(.text+0x7c9): undefined reference to `XFlush' tty.o: In function `debug_event': tty.o(.text+0xbf8): undefined reference to `XBell' tty.o(.text+0xc03): undefined reference to `XFlush' tty.o: In function `video_async_event': tty.o(.text+0x11c3): undefined reference to `XFlush' tty.o(.text+0x11e3): undefined reference to `XNextEvent' tty.o(.text+0x1257): undefined reference to `XFlush' tty.o(.text+0x1298): undefined reference to `XNextEvent' tty.o: In function `video_event': tty.o(.text+0x1774): undefined reference to `XLookupString' tty.o(.text+0x18f8): undefined reference to `XLookupString' tty.o: In function `tty_write': tty.o(.text+0x1f82): undefined reference to `XBell' tty.o: In function `KbdWrite': tty.o(.text+0x27da): undefined reference to `XBell' tty.o: In function `video_init': tty.o(.text+0x2b35): undefined reference to `XOpenDisplay' tty.o(.text+0x2b5c): undefined reference to `XDisplayName' tty.o(.text+0x2c39): undefined reference to `XAllocNamedColor' tty.o(.text+0x2c92): undefined reference to `XLoadQueryFont' tty.o(.text+0x2cae): undefined reference to `XLoadQueryFont' tty.o(.text+0x2d81): undefined reference to `XCreateSimpleWindow' tty.o(.text+0x2de4): undefined reference to `XCreateGC' tty.o(.text+0x2e1b): undefined reference to `XCreateGC' tty.o(.text+0x2e38): undefined reference to `XSetNormalHints' tty.o(.text+0x2e62): undefined reference to `XSelectInput' tty.o(.text+0x2e76): undefined reference to `XMapWindow' tty.o(.text+0x2e81): undefined reference to `XFlush' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: DUMMYNET broken in -current ?
On Fri, 30 Apr 1999, Poul-Henning Kamp wrote: I have two machines, the target being a -current SMP box. On the source machine I do ping target On the target machine, SMP kernel with IPFW+DUMMYNET: ipfw pipe config 1 delay 200ms ipfw add pipe 1 icmp from any to any and get a panic in ether_output because dst is 0x14. Anybody who can try this ? perchance related: My gateway configured with BRIDGE panics when doing a sysctl -A/-a it's -current from 2 days ago with Matt Dillon's patches for NFS. ? -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
In article pine.bsf.4.03.9904291137380.1166-100...@resnet.uoregon.edu,
Doug White dwh...@resnet.uoregon.edu wrote:
Yes, we know that audio is broken; it's been broken since April 20th.
Well, it's worse than broken. Merely including pcm0 in the kernel
config file causes instant panic on boot-up with my machine (new
kernel built last night from fresh sources):
BIOS basemem (639K) != RTC basemem (640K), setting to BIOS value
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc015983c
stack pointer = 0x10:0xc0303f68
frame pointer = 0x10:0xc0303f70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 0 ()
interrupt mask = net tty bio cam
kernel: type 12 trap, code=0
Stopped at 0xc015983c: movl0(%ecx),%ebx
KGDB says there's a NULL item in sysctl_set:
(kgdb) where
#0 sysctl_register_oid (oidp=0x0) at ../../kern/kern_sysctl.c:79
#1 0xc01598f1 in sysctl_register_set (lsp=0xc02885b8)
at ../../kern/kern_sysctl.c:127
#2 0xc0159941 in sysctl_register_all (arg=0x0) at
../../kern/kern_sysctl.c:145
#3 0xc014954a in main (framep=0xc0303fb4) at ../../kern/init_main.c:231
(kgdb) up
#1 0xc01598f1 in sysctl_register_set (lsp=0xc02885b8)
at ../../kern/kern_sysctl.c:127
127 sysctl_register_oid((struct sysctl_oid *)
lsp-ls_items[i]);
(kgdb) p *lsp
$1 = {ls_length = 414, ls_items = {0xc026e3e0}}
(kgdb) p i
$2 = 412
(kgdb) p lsp-ls_items[411]
$4 = (void *) 0xc0285bc0
(kgdb) p lsp-ls_items[412]
$5 = (void *) 0x0
(kgdb) p lsp-ls_items[413]
$6 = (void *) 0x4
(kgdb) up
#2 0xc0159941 in sysctl_register_all (arg=0x0) at
../../kern/kern_sysctl.c:145
145 sysctl_register_set(sysctl_set);
(kgdb) up
#3 0xc014954a in main (framep=0xc0303fb4) at ../../kern/init_main.c:231
231 (*((*sipp)-func))((*sipp)-udata);
I can gather more information if anybody wants it. The kernel works
fine if I take pcm0 out of the config file.
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
dummynet: weird icmp behavior
I have a -current install from just before egcs and am using DummyNet to experiment with network protocols. I've been applying the rules to the loopback device so as to prevent other interference. It seems to work well, except that ICMP seems not to be working for me. At one point in the past, I am certain that it did work. Here is the ruleset: sleipnir:/homea/robert# ipfw list 1 pipe 5 ip from 127.0.0.1 to 127.0.0.1 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 65000 allow ip from any to any 65535 deny ip from any to any The pipe is configured: sleipnir:/homea/robert# ipfw pipe 5 config bw 10Mbit/s delay 150ms And ping localhost simply doesn't get any response, except once in a blue moon when a 600ms packet turns up. Tcpdump indicates that packets are going out but not being responded to: tcpdump: listening on lo0 13:02:09.201061 127.0.0.1 127.0.0.1: icmp: echo request 13:02:10.211104 127.0.0.1 127.0.0.1: icmp: echo request 13:02:11.221089 127.0.0.1 127.0.0.1: icmp: echo request 13:02:12.231110 127.0.0.1 127.0.0.1: icmp: echo request 13:02:13.241125 127.0.0.1 127.0.0.1: icmp: echo request When I load up tcpdump, I see: Apr 30 13:02:28 sleipnir last message repeated 19 times Apr 30 13:02:29 sleipnir /kernel: lo0: promiscuous mode enabled Apr 30 13:02:29 sleipnir /kernel: looutput: af=0 unexpected Normal UDP/TCP/etc all seem to get there fine, just not any ICMP (or at least not pings). For example, the ICMP port unreachable packet for telneting to an invalid port also disappears. Any advice here would be quite welcome :) Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Sound doesn't work after recent upgrade
Alexander Leidinger netch...@wurzelausix.cs.uni-sb.de writes: On 27 Apr, Vallo Kallaste wrote: Something changed between Apr.21 and Apr.27 so that my onboard Vibra16X get probed but I doesn't get sound. No error messages, nothing, different players show that all is okay and play silently. Catting something to /dev/audio or /dev/dsp(W) causes noise for about 1 second then silence. My soundcard worked well Me too for my Vibra16?-Card. But only for pcm. The in-kernel Voxware driver works. Me three, with a Soundblaster 32. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
John Polstra wrote: In article pine.bsf.4.03.9904291137380.1166-100...@resnet.uoregon.edu, Doug White dwh...@resnet.uoregon.edu wrote: Yes, we know that audio is broken; it's been broken since April 20th. Well, it's worse than broken. Merely including pcm0 in the kernel config file causes instant panic on boot-up with my machine (new kernel built last night from fresh sources): It must be something that entered the tree late yesterday afternoon or an interaction between devices. FreeBSD 4.0-CURRENT #1: Thu Apr 29 15:41:29 PDT 1999 r...@troutmask.apl.washington.edu:/usr/src/sys/compile/TROUTMASK Timecounter i8254 frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping=9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 268435456 (262144K bytes) avail memory = 258375680 (252320K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc02f9000. Pentium Pro MTRR support enabled, default memory type is uncacheable Probing for PnP devices: CSN 1 Vendor ID: CTL00a5 [0xa5008c0e] Serial 0x9df7 Comp ID: @@@ \ [0x] SoundBlaster: DSP Command(0xe1) timeout. IRQ conflict ? pcm1 (SB16pnp SB16 PnP sn 0x9df7) at 0x640-0x64f irq 0 drq 4 flags 0x10 \ on isa CSN 2 Vendor ID: CTL0080 [0x80008c0e] Serial 0x Comp ID: @@@ \ [0x] pcm2 (SB16pnp SB16 PnP sn 0x) at 0x220-0x22f irq 5 drq 1 flags 0x15\ on isa -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ep0 *UTP*
Alex Zepeda garba...@hooked.net writes: On Wed, 28 Apr 1999, Jim Bryant wrote: Well, I'd chalk it up to buggy 3com h/w myself. Alas I'm still getting: ep0 XXX: driver didn't set ifq_maxlen I still get that one too. Driver problem? I'm guessing so. I wonder if this is the cause of some odd network behavior I'm getting.. Anybody using a 3c509 and expecting it to work reliably should be taken out and shot in the back of the head. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ep0 *UTP*
Leif Neland r...@neland.dk writes: Btw, why does boot write [*UTP*] ? The card is working nicely with bnc. Your card is configured to use the UTP tranceiver. You probably have -link1 in your ifconfig_ep0, which forces the card to switch to the BNC tranceiver but does not actually reconfigure the card. 3Com are not particularly forthcoming with details on how do this, so if you want it to say [*BNC*] at boot time, boot with a DOS disk and run 3c5x9cfg. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ep0 *UTP*
Dag-Erling Smorgrav once wrote: Well, I'd chalk it up to buggy 3com h/w myself. Alas I'm still getting: ep0 XXX: driver didn't set ifq_maxlen I still get that one too. Driver problem? I'm guessing so. I wonder if this is the cause of some odd network behavior I'm getting.. Anybody using a 3c509 and expecting it to work reliably should be taken out and shot in the back of the head. Is this because the cards are bad, or because the driver is bad? I had my share of problems with them, until I set them to use MTU of 900 -- no problems since, with NFS and X-session traffic flowing through the pair of this cards. -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ep0 *UTP*
Dag-Erling Smorgrav wrote: Alex Zepeda garba...@hooked.net writes: On Wed, 28 Apr 1999, Jim Bryant wrote: Well, I'd chalk it up to buggy 3com h/w myself. Alas I'm still getting: ep0 XXX: driver didn't set ifq_maxlen I still get that one too. Driver problem? I'm guessing so. I wonder if this is the cause of some odd network behavior I'm getting.. Anybody using a 3c509 and expecting it to work reliably should be taken out and shot in the back of the head. DES Hi, would you please be more specific about that last sentence ? i've always heard from the FreeBSD community (newsgroups, /sys/i386/conf/GENERIC, ...) that the ep0 driver was buggy. I've got one 3C509 combo NIC in my home box, and it has been running now for 5 (which could turn into much more if was able to remember exactly when i installed it :)) under various releases of FreeBSD without experiencing any problem whatsoever. The board does not get a real load, as it is mostly used to connect some other computers to the internet on my home network. I'd like you to tell me why i should expect to get a bullet in the head if we ever meet :-) Which will make you the most unfriendly guy (and for me, the last) around :-) Thanks ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: PCM
In article 199904301717.kaa03...@troutmask.apl.washington.edu, Steve Kargl s...@troutmask.apl.washington.edu wrote: John Polstra wrote: Well, it's worse than broken. Merely including pcm0 in the kernel config file causes instant panic on boot-up with my machine (new kernel built last night from fresh sources): It must be something that entered the tree late yesterday afternoon or an interaction between devices. [successful boot transcript omitted] On a hunch, I built the kernel again from the same sources but starting with a clean compile directory. This time it worked. So it appears that the panic I got wasn't something inherent in the kernel, but rather was a build problem. I'm certain that I typed make depend before building the bad kernel. So I think there must be a missing dependency somewhere. 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
Re: Any action on PR 10570 ? getting closer to 65K :-(
Pierre Beyssac wrote: Wouldn't it be sensible to issue a warning (or panic) when increasing the reference count reaches 0, rather than causing a later kernel segfault? It would involve some overhead though, and I'm not sure having 2^32 routes is currently realistic since most machines don't even have that many bytes of RAM, but it might be true one day... It would be pretty hard to create 2^32 routes, given that IPv4 only has 32-bit addresses. :-) Also, if you time it I suspect you'll find that it would take a geological lifetime on a fast machine to add that many routes. But some of us are playing with IPv6 and it is easy to create 2^32 routes in that environment. I think it makes more sense to increase the size of the reference count as discussed, rather than adding checks that add more complexity and overhead. The checks could be added _today_ with very little testing needed, simple return an error if attempting to wrap the route ref count from 65536-0. At least then we don't blow chunks latter and end up segfaulting. This is a real bug fix. Even when the variable is increased in size to an int32_t it _should_ have an overflow test, not doing so is poor programming no matter how you cut it. -- Rod Grimes - KD7CAX - (RWG25) rgri...@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
Rodney W. Grimes wrote: Pierre Beyssac wrote: Wouldn't it be sensible to issue a warning (or panic) when increasing the reference count reaches 0, rather than causing a later kernel segfault? It would involve some overhead though, and I'm not sure having 2^32 routes is currently realistic since most machines don't even have that many bytes of RAM, but it might be true one day... It would be pretty hard to create 2^32 routes, given that IPv4 only has 32-bit addresses. :-) Also, if you time it I suspect you'll find that it would take a geological lifetime on a fast machine to add that many routes. But some of us are playing with IPv6 and it is easy to create 2^32 routes in that environment. You're being totally unrealistic. You can't create 2^32 of _anything_ on an i386 without running out of memory. Even if you could address that much memory, you or your machine would be dead from old age long before it managed to add that many routes. Let's say, _totally_ unrealistically, that you added 100 routes per second continuously. It would still take you 500 days to wrap the 32-bit counter. Regarding IPv6, it would be a surprise if that structure remained the same at all for IPv6. The checks could be added _today_ with very little testing needed, simple return an error if attempting to wrap the route ref count from 65536-0. At least then we don't blow chunks latter and end up segfaulting. This is a real bug fix. No it's not. It doesn't fix anything, because your 16-bit counter has wrapped around and now it's not valid any more. It doesn't matter whether you detect it and warn about it or not. The damage is already done. On the other hand, increasing the size of the variable eliminates the problem entirely. And once you do that, the overflow test is unnecessary. 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
Re: Any action on PR 10570 ? getting closer to 65K :-(
In message xfmail.990430112019@polstra.com, John Polstra writes: Rodney W. Grimes wrote: Pierre Beyssac wrote: Wouldn't it be sensible to issue a warning (or panic) when increasing the reference count reaches 0, rather than causing a later kernel segfault? It would involve some overhead though, and I'm not sure having 2^32 routes is currently realistic since most machines don't even have that many bytes of RAM, but it might be true one day... It would be pretty hard to create 2^32 routes, given that IPv4 only has 32-bit addresses. :-) Also, if you time it I suspect you'll find that it would take a geological lifetime on a fast machine to add that many routes. But some of us are playing with IPv6 and it is easy to create 2^32 routes in that environment. You're being totally unrealistic. You can't create 2^32 of _anything_ on an i386 without running out of memory. Well, John, you can, the newer ones will address 2^36 bytes of memory and even a i386 can address 2^32 bytes or 2^35 bits... But hair splitting aside, you certainly cannot create 2^32 routes without having other significant problems, and while I agree with Rod that the overflow should be checked, I think it should be done with a KASSERT() if not just with a comment. -- 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: ep0 *UTP*
Erwan Arzur er...@netvalue.fr writes: Dag-Erling Smorgrav wrote: Anybody using a 3c509 and expecting it to work reliably should be taken out and shot in the back of the head. would you please be more specific about that last sentence? 3Com 3c509 NICs are unreliable. Some work, others don't. They are also known to be temperamental, in that the same card may perform well in one computer but poorly in another. Add to that the fact that the driver is buggy (search the mailing list archives!), and what you get is a hardware/software combination I cannot in good faith recommend to anyone. If you need something cheap, go for an SMC or Kingston based NE2000 compatible ISA card. You'll probably get it cheaper than the 3c509, and it will work better (and be pnp-configurable to boot). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ep0 *UTP*
Dag-Erling Smorgrav wrote:
Alex Zepeda garba...@hooked.net writes:
On Wed, 28 Apr 1999, Jim Bryant wrote:
Well, I'd chalk it up to buggy 3com h/w myself. Alas I'm still getting:
ep0 XXX: driver didn't set ifq_maxlen
I still get that one too. Driver problem?
I'm guessing so. I wonder if this is the cause of some odd network
behavior I'm getting..
Anybody using a 3c509 and expecting it to work reliably should be
taken out and shot in the back of the head.
I thought I sent this before, but I can't find in the GNAT
database.
--- if_ep.c.origFri Apr 30 11:22:36 1999
+++ if_ep.c Fri Apr 30 11:24:15 1999
@@ -621,6 +621,7 @@
ifp-if_start = epstart;
ifp-if_ioctl = epioctl;
ifp-if_watchdog = epwatchdog;
+ ifp-if_snd.ifq_maxlen = IFQ_MAXLEN;
if (!attached) {
if_attach(ifp);
--
Steve
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: ep0 *UTP*
3Com 3c509 NICs are unreliable. Some work, others don't. They are also known to be temperamental, in that the same card may perform well in one computer but poorly in another. Add to that the fact that the driver is buggy (search the mailing list archives!), and what you get is a hardware/software combination I cannot in good faith recommend to anyone. If you need something cheap, go for an SMC or Kingston based NE2000 compatible ISA card. You'll probably get it cheaper than the 3c509, and it will work better (and be pnp-configurable to boot). H I've deployed well over 3 dozen of the 3c509 in its various versions, with about a third on FreeBSD systems and I haven't seem the problems you are describing. They must work at some level because I know several universities that have used them exclusively, which means probably 100's of units per site. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
Poul-Henning Kamp wrote: In message xfmail.990430112019@polstra.com, John Polstra writes: You're being totally unrealistic. You can't create 2^32 of _anything_ on an i386 without running out of memory. Well, John, you can, the newer ones will address 2^36 bytes of memory and even a i386 can address 2^32 bytes or 2^35 bits... But hair splitting aside, If we're going to split hairs, how about this: To make a reference count exceed 2^32, you need to have 2^32 different pointers pointing to it. A pointer takes 2^2 bytes on the i386. So that's 2^34 bytes of memory you'd need just to store the pointers. You'd better hope you don't get a panic on that mother! It might take quite awhile to write a 16 GByte crash dump. :-) you certainly cannot create 2^32 routes without having other significant problems, and while I agree with Rod that the overflow should be checked, I think it should be done with a KASSERT() if not just with a comment. A check would be worthwhile to detect bugs in the code (increments without matching decrements). If you want to check for bona-fide overflows, you'd best be prepared to check every counter in the system. 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
Re: make world fails when updating from older -current
perl5: not found *** Error code 1 Do you have NOPERL uncommented in /etc/make.conf? If so, don't do that. -- -- 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: Any action on PR 10570 ? getting closer to 65K :-(
On Fri, 30 Apr 1999, Poul-Henning Kamp wrote: In message xfmail.990430112019@polstra.com, John Polstra writes: Rodney W. Grimes wrote: You're being totally unrealistic. You can't create 2^32 of _anything_ on an i386 without running out of memory. Well, John, you can, the newer ones will address 2^36 bytes of memory and even a i386 can address 2^32 bytes or 2^35 bits... Since when does FreeBSD only run on i386? Ben You have your mind on computers, it seems. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
In message xfmail.990430113648@polstra.com, John Polstra writes: Poul-Henning Kamp wrote: In message xfmail.990430112019@polstra.com, John Polstra writes: You're being totally unrealistic. You can't create 2^32 of _anything_ on an i386 without running out of memory. Well, John, you can, the newer ones will address 2^36 bytes of memory and even a i386 can address 2^32 bytes or 2^35 bits... But hair splitting aside, If we're going to split hairs, how about this: To make a reference count exceed 2^32, you need to have 2^32 different pointers pointing to it. A pointer takes 2^2 bytes on the i386. So that's 2^34 bytes of memory you'd need just to store the pointers. You'd better hope you don't get a panic on that mother! It might take quite awhile to write a 16 GByte crash dump. :-) Still only 1/4 the addressable store of P5 and upwards... :-) -- 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: (FWD) Re: Progs linked against libstdc++ dead...
These are good questions, and I don't know enough yet about the issues surrounding vtable thunks to answer them. I haven't had time to really dig into this yet. Hopefully Saturday. I'm about to revert the change until I can see what the problem is and what the upgrade issues will be. EGCS 1.2 *should* be out in the July/Aug time frame. Of course I will try to upgrade us to it (well 1.2.1 which I figure will quickly follow). The EGCS maintainers are pushing to get vtable thunks working properly for 1.2. Since the Linux config files specify DEFALUT_VTABLE_THUNKS=1, no one has posted a bug report related to them, there is an option to turn them off, and this *is* -CURRENT. I may just leave them turned on by default. Opinions? -- -- 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: Any action on PR 10570 ? getting closer to 65K :-(
Snob Art Genre wrote: On Fri, 30 Apr 1999, Poul-Henning Kamp wrote: In message xfmail.990430112019@polstra.com, John Polstra writes: Rodney W. Grimes wrote: You're being totally unrealistic. You can't create 2^32 of _anything_ on an i386 without running out of memory. Well, John, you can, the newer ones will address 2^36 bytes of memory and even a i386 can address 2^32 bytes or 2^35 bits... Since when does FreeBSD only run on i386? Sheesh. Make it a bloody long then so you'll get 64 bits on the Alpha. And then go fix all the printf format mismatches. Or, pull you head out of that dark fantasyland and realize that (a) a 32-bit counter is not a problem in any realistic sense, and (b) if it were, we'd have thousands of other equally serious problems throughout the system. I'm done with this absurd thread. 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
Re: (FWD) Re: Progs linked against libstdc++ dead...
David O'Brien wrote: I haven't had time to really dig into this yet. Hopefully Saturday. I'm about to revert the change until I can see what the problem is and what the upgrade issues will be. EGCS 1.2 *should* be out in the July/Aug time frame. Of course I will try to upgrade us to it (well 1.2.1 which I figure will quickly follow). The EGCS maintainers are pushing to get vtable thunks working properly for 1.2. Good. I didn't know whether it was something they were actively working on. Since the Linux config files specify DEFALUT_VTABLE_THUNKS=1, no one has posted a bug report related to them, there is an option to turn them off, and this *is* -CURRENT. I may just leave them turned on by default. Opinions? I think that's the best solution for now. 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
Panic
Ulp!! I just had my first panic in a year, and remembered why I didn't want to use modules too much, because when I tried to revert, the old kernel didn't like the new modules (procfs, it seems). Anyhow, I handcopied the panic message, here it is, I'd extremely appreiciate any help in getting a new kernel to boot. I finally got my old kernel up by not loading procfs.ko ... Oh, yeah, I booted this 3 times with the same message, it's not a random occurrence. Since I handcopied this, and my printing is in block letters, I don't differentiate between upper and lower case, so don't read anything into that. fatal trap 12: page fault while in kernel mode mp_lock = 001a; cpuid = 0; lapic.id = 0100 fault virtual address = 0x14 fault code = supervisor read, page not present instruction pointer = 0x8; 0xc01c6663 stack pointer = 0x10; 0xc034ade4 frame pointer = 0x10; 0xc034ae14 code segment = base 0x0, limit 0xf, type 0x1b dpl 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, iopl=0 interrupt mask = net tty bio cam - smp:xxx kernel: type 12 trap, code = 0 stopped at nexus_setup_intr+0x13:pushl 0x14(%edx) This is my first kernel since the nexus stuff was brought in, and I had to edit my config file to get it to stop issuing me errors ... here's my config, I hope this helps: machine i386 cpu I586_CPU cpu I686_CPU ident CHUCKRSP maxusers64 # Create a SMP capable kernel (mandatory options): options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional, these are the defaults: options NCPU=2 # number of CPUs options NBUS=4 # number of busses options NAPIC=1 # number of IO APICs options NINTR=24# number of INTs options SYSVSHM options SYSVSEM options SYSVMSG #optionsSCSI_NCR_SYMBIOS_COMPAT options MSGBUF_SIZE=40960 # Lets always enable the kernel debugger for SMP. options DDB # SMP shouldn't need x87 emulation, disable by default. #optionsMATH_EMULATE#Support for x87 emulation options GPL_MATH_EMULATE#Support for x87 emulation via options INET#InterNETworking options FFS_ROOT options FFS #Berkeley Fast Filesystem #optionsNFS #Network Filesystem #optionsMSDOSFS #MSDOS Filesystem #optionsCD9660#ISO 9660 Filesystem #optionsPROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=8000 #Be pessimistic about Joe SCSI device options UCONSOLE#Allow users to grab the console options FAILSAFE#Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options VM86 options MD5 #optionsSCSI_NCR_SYMBIOS_COMPAT # for LEDs options SOFTUPDATES #optionsPERFMON #optionsVESA# needs VM86 defined too!! # Coda stuff: #optionsCODA#CODA filesystem. #pseudo-device vcoda 4 #coda minicache - venus comm. config kernel root on da0s1a dumps on da0s1b controller isa0 controller eisa0 controller pnp0 controller pci0 controller fdc0at isa? port IO_FD1 irq 6 drq 2 diskfd0 at fdc0 drive 0 diskfd1 at fdc0 drive 1 # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. controller ncr0 controller scbus0 #device npx0at isa? port IO_NPX irq 13 vector npxintr #device npx0at isa? port IO_NPX iosiz 0x0 flags 0x0 irq 13 vector npxintr # # The Numeric Processing eXtension driver. This should be configured if # your machine has a math co-processor, unless the coprocessor is very # buggy. If it is not configured then you *must* configure math emulation # (see above). If both npx0 and emulation are configured, then only npx0 # is used (provided it works). device npx0at nexus? port IO_NPX iosiz 0x0 flags 0x0 irq 13 device da0 device da1 device xpt0 device cd0 #Only need one of these, the code dynamically grows # The keyboard controller; it controlls the keyboard and the PS/2 mouse. controller atkbdc0 at isa? port IO_KBD # The AT keyboard device atkbd0 at isa? port IO_KBD # new syscons stuff #controller atkbdc0 at isa? port IO_KBD tty #device atkbd0 at isa? tty irq 1 device
Re: (FWD) Re: Progs linked against libstdc++ dead...
On Fri, 30 Apr 1999, David O'Brien wrote: # These are good questions, and I don't know enough yet about the issues # surrounding vtable thunks to answer them. # # I haven't had time to really dig into this yet. Hopefully Saturday. I'm # about to revert the change until I can see what the problem is and what # the upgrade issues will be. EGCS 1.2 *should* be out in the July/Aug # time frame. Of course I will try to upgrade us to it (well 1.2.1 which I # figure will quickly follow). The EGCS maintainers are pushing to get # vtable thunks working properly for 1.2. They seem to work now, but I'll reserve the final judgement for the experts. :-) # Since the Linux config files specify DEFALUT_VTABLE_THUNKS=1, no one has # posted a bug report related to them, there is an option to turn them off, # and this *is* -CURRENT. I may just leave them turned on by default. # # Opinions? I'd like to see them left on. # -- # -- 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: (FWD) Re: Progs linked against libstdc++ dead...
On Fri, 30 Apr 1999, David O'Brien wrote: These are good questions, and I don't know enough yet about the issues surrounding vtable thunks to answer them. I haven't had time to really dig into this yet. Hopefully Saturday. I'm about to revert the change until I can see what the problem is and what the upgrade issues will be. EGCS 1.2 *should* be out in the July/Aug time frame. Of course I will try to upgrade us to it (well 1.2.1 which I figure will quickly follow). The EGCS maintainers are pushing to get vtable thunks working properly for 1.2. Since the Linux config files specify DEFALUT_VTABLE_THUNKS=1, no one has posted a bug report related to them, there is an option to turn them off, and this *is* -CURRENT. I may just leave them turned on by default. Opinions? I would prefer to keep vtable thunks turned on. The alternative produces wretched code for multiple inheritance. Personally, I want -fnew-abi too; gcc does some disgusting things with multiple zero-sized base classes without it... -- 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: Any action on PR 10570 ? getting closer to 65K :-(
Rodney W. Grimes wrote: Pierre Beyssac wrote: Wouldn't it be sensible to issue a warning (or panic) when increasing the reference count reaches 0, rather than causing a later kernel segfault? It would involve some overhead though, and I'm not sure having 2^32 routes is currently realistic since most machines don't even have that many bytes of RAM, but it might be true one day... It would be pretty hard to create 2^32 routes, given that IPv4 only has 32-bit addresses. :-) Also, if you time it I suspect you'll find that it would take a geological lifetime on a fast machine to add that many routes. But some of us are playing with IPv6 and it is easy to create 2^32 routes in that environment. You're being totally unrealistic. You can't create 2^32 of _anything_ on an i386 without running out of memory. You can easily create 2^32 of lots of things on an i386, they just have to take an average of 8 bits each. And this code is _NOT_ restricted to the i386. Even if you could address that much memory, you or your machine would be dead from old age long before it managed to add that many routes. Let's say, _totally_ unrealistically, that you added 100 routes per second continuously. It would still take you 500 days to wrap the 32-bit counter. 100/routes a second is trivial to add, this is a straw man argument, you have no idea what this code might be running on, how fast it can add routes, etc, etc. Your using the same mentality that has created the Y2K issue. Regarding IPv6, it would be a surprise if that structure remained the same at all for IPv6. Routes are still going to reference an interface, reference counts are still there. The checks could be added _today_ with very little testing needed, simple return an error if attempting to wrap the route ref count from 65536-0. At least then we don't blow chunks latter and end up segfaulting. This is a real bug fix. No it's not. It doesn't fix anything, because your 16-bit counter has wrapped around and now it's not valid any more. It doesn't matter whether you detect it and warn about it or not. The damage is already done. And a strange segfalut is a lot easier to track down and figure out what blew up... NOT!! On the other hand, increasing the size of the variable eliminates the problem entirely. And once you do that, the overflow test is unnecessary. No, it does not ``eliminate'' the problem, it only hides it. Plain and simple not doing bounds checking on reference counts is bad. -- Rod Grimes - KD7CAX - (RWG25) rgri...@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: solid NFS patch #6 avail for -current - need testers files)
-Original Message- From: Doug Rabson [mailto:d...@nlsystems.com] Sent: 21 April 1999 20:14 To: Matthew Dillon Cc: Peter Wemm; Matthew Reimer; freebsd-current@freebsd.org Subject: Re: solid NFS patch #6 avail for -current - need testers files) I wonder if it would be too radical to suggest that the release cycle for 4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets worse and worse as time goes on and it just becomes a waste of programmer time. If we are reasonably careful with the 4.0 tree, I think a 4.0 release could be branched off it after 3.2 or maybe 3.3. It seems to me that merging a complex set of changes (such as the VM fixes or the new-bus work) from 4.0 to the 3.x branch would tend to produce a system which was less stable than the 'natural' environment for the software which is being merged across. I wonder if it would be too radical to suggest a third branch :-) I know of an increasing number of people who are not tracking -stable anymore because it's losing its reputation of stability. The main reason being that changes are pushed across from -current with little or no testing in -stable. I think -stable should have very conservative commit rules, only bug fixes, no feature creap. For the commercial users this is what they want, they're not interested in the newer features, they want what they already to have to work more reliably. There is however a more vocal group of people who chase features and they adhere to the rules and don't run -current to get them but increasingly their pressure has meant that -current features are hitting -stable very quickly. I think there should be three branches: 1) -current, usual rules apply, may toast your box at any moment, don't use unless you're prepared for such eventualities. 2) -beta, the place where new features migrate from -current when they seem to be working ok. Still potentially flakey but isn't expected to toast your machine. Users need to put up with problems but it should be an useable platform for a lot of people. It gets new features quickly. 3) -stable, only changes made to this branch are bug fixes, no new features added ever. I think -current has largely become -beta with the problem that when it does hit bad spots the beta users complain far too loudly than they really have the right to. The user base should be shifted as follows 1) -current has very few (relatively) users, only those developers who work on the OS (i.e. not ports) code. 2) The vast majority of people who run -current at the moment should really be running -beta. 3) -stable is for those who don't track FreeBSD. They upgrade only when a release takes place and not even at every release. These are mostly commercial users or home users who really aren't into the OS and just want a working box. In terms of workload I don't think it would have the major impact that people fear. Merges back to -stable should be *very* rare and so should not amount to any significant workload. Most of the merges we do to -stable at the moment should really be done to -beta so the workload there would be the same. Possibly even more radical than a third branch Change the -current list into -beta and form a new -current list that requires signing (figuratively not literally) an agreement that you accept -current may seriously hose you. Only allow people who have agreed these terms to post to the list, it would still be open for everyone to follow. This should reduce the number of whining messages on the development list from people who shouldn't really be running the development branch. Paul Richards Originative Solutions Ltd. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
:If we're going to split hairs, how about this: To make a reference :count exceed 2^32, you need to have 2^32 different pointers pointing :to it. A pointer takes 2^2 bytes on the i386. So that's 2^34 bytes :of memory you'd need just to store the pointers. : :You'd better hope you don't get a panic on that mother! It might :take quite awhile to write a 16 GByte crash dump. :-) : : you certainly cannot create 2^32 routes without having other : significant problems, and while I agree with Rod that the overflow : should be checked, I think it should be done with a KASSERT() if not : just with a comment. : :A check would be worthwhile to detect bugs in the code (increments :without matching decrements). If you want to check for bona-fide :overflows, you'd best be prepared to check every counter in the :system. : :John :--- : John Polstra j...@polstra.com We do check some critical reference-count fields for overflow. But it doesn't make sense to check all of them. This particular reference count has no related bugs that we know of apart from legally bumping past 65536, so it would be kinda silly to check it for an overflow. If one insisted, I suppose we could add a check if INVARIANTS is enabled but I don't see any advantage to doing so in this case. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make world fails when updating from older -current
On 30-Apr-99 David O'Brien wrote: perl5: not found *** Error code 1 Do you have NOPERL uncommented in /etc/make.conf? If so, don't do that. Then why don't we take it out of make.conf for now? If we may still need the functionality, then we can leave the logic in the build mechanism, just don't tell the user about it. Then we can resurrect it in the future as necessary. At least we could add a comment to /etc/make.conf warning a user that buildworlds will fail with that option turned on. -- David(obr...@nuxi.com -or- obr...@freebsd.org) --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use 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
default route not set up??
Hi, I must be missing something If you set defaultrouter in /etc/rc.conf to an ip address, I expected that rc.network would do a route add default ..., but instead I find that rc.network doesn't do anything with the defaultrouter variable except to pass it on to the route_default variable, which doesn't seem to be used at all. What am I missing here??? Lars To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Any action on PR 10570 ? getting closer to 65K :-(
John Polstra wrote: Rodney W. Grimes wrote: Pierre Beyssac wrote: Wouldn't it be sensible to issue a warning (or panic) when increasing the reference count reaches 0, rather than causing a later kernel segfault? It would involve some overhead though, and I'm not sure having 2^32 routes is currently realistic since most machines don't even have that many bytes of RAM, but it might be true one day... It would be pretty hard to create 2^32 routes, given that IPv4 only has 32-bit addresses. :-) Also, if you time it I suspect you'll find that it would take a geological lifetime on a fast machine to add that many routes. But some of us are playing with IPv6 and it is easy to create 2^32 routes in that environment. You're being totally unrealistic. You can't create 2^32 of _anything_ on an i386 without running out of memory. Even if you could address that much memory, you or your machine would be dead from old age long before it managed to add that many routes. Let's say, _totally_ unrealistically, that you added 100 routes per second continuously. It would still take you 500 days to wrap the 32-bit counter. Regarding IPv6, it would be a surprise if that structure remained the same at all for IPv6. The checks could be added _today_ with very little testing needed, simple return an error if attempting to wrap the route ref count from 65536-0. At least then we don't blow chunks latter and end up segfaulting. This is a real bug fix. No it's not. It doesn't fix anything, because your 16-bit counter has wrapped around and now it's not valid any more. It doesn't matter whether you detect it and warn about it or not. The damage is already done. On the other hand, increasing the size of the variable eliminates the problem entirely. And once you do that, the overflow test is unnecessary. John So what about those i586/pentium machines? Do they have the 32bit counters so you can implement the higher bit counts? Chas To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: (FWD) Re: Progs linked against libstdc++ dead...
On Fri, 30 Apr 1999, David O'Brien wrote: These are good questions, and I don't know enough yet about the issues surrounding vtable thunks to answer them. I haven't had time to really dig into this yet. Hopefully Saturday. I'm about to revert the change until I can see what the problem is and what the upgrade issues will be. EGCS 1.2 *should* be out in the July/Aug time frame. Of course I will try to upgrade us to it (well 1.2.1 which I figure will quickly follow). The EGCS maintainers are pushing to get vtable thunks working properly for 1.2. Since the Linux config files specify DEFALUT_VTABLE_THUNKS=1, no one has posted a bug report related to them, there is an option to turn them off, and this *is* -CURRENT. I may just leave them turned on by default. Opinions? *gritting teeth* bring it on! :) -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: solid NFS patch #6 avail for -current - need testers files)
Hello, My name is David DeTinne and I have been suscribing to FreeBSD Stable for some time now, before 2.2.2 was released. Here is my view regarding your posting: 3.1 is probably the most unstable stable version ever to be sent out by Walnut Creek. I have a machine that has 2.2.6 on it, which has been abused, cold booted, etc. When I received 3.1 in the mail I installed it on three seperate machines before giving up. to many system failures. I am waiting for 3.2 to replace my 2.2.6 installation due to the machine's importance. Right now I am using 4.0 current 19990421 on my test box which works fine, go figure? Although I am not a programmer, I do care about the open source movement, and look forward to the day where I can replace all of the desktop OS's in my office with a free version of unix, linux, etc. To sum it all up is there any difference between the branches? Thank You, David DeTinne To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
To sum it all up is there any difference between the branches? Yes. We hope that people like you will help us by participating in the testing of potential releases _before_ they go out as releases, not _afterwards_. Sitting around doing nothing and then complaining after the fact doesn't help anyone, least of all yourself. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: solid NFS patch #6 avail for -current - need testers files)
On Fri, 30 Apr 1999 da...@aps-services.com wrote: 3.1 is probably the most unstable stable version ever to be sent out by Walnut Creek. I have a machine that has 2.2.6 on it, which has been abused, cold booted, etc. When I received 3.1 in the mail I installed it on three seperate machines before giving up. to many system failures. I am waiting for 3.2 to replace my 2.2.6 installation due to the machine's importance. use 3.1-stable from current.freebsd.org last -stable is TODAY-stable :-)) Right now I am using 4.0 current 19990421 on my test box which works fine, go figure? time-to-time -current in some features is MORE stable then last -STABLE, but -current is CURRENT: its a development version. Although I am not a programmer, I do care about the open source movement, and look forward to the day where I can replace all of the desktop OS's in my office with a free version of unix, linux, etc. To sum it all up is there any difference between the branches? plz c handbook at http://www.freebsd.org/handbook Rgdz, Sergey A. Osokin, o...@etrust.ru To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
To sum it all up is there any difference between the branches? Yes. We hope that people like you will help us by participating in the testing of potential releases _before_ they go out as releases, not _afterwards_. Sitting around doing nothing and then complaining after the fact doesn't help anyone, least of all yourself. This isn't meant in a bad way, but let me share with you my experiences. Before 3.0 was released, I said several times Hey, NFS got a lot worse on -CURRENT. Is anyone looking at this? and got several replies of Duh, this is -CURRENT. Don't whine about it. If you're trying to use this in a production environment, you're crazy. After 3.0 was released, I said Hey, 3.0 got released, and NFS was still broken, to which I got Why didn't you bug us about this before the release? and/or Why didn't you test this before release? I understand NFS is a 'special' problem, but for those of us not in the trenches coding, I think the '3-level' system would be better. -CURRENT for those who are coding, -BETA for people like me to test things and bring up what broke, and -RELEASE for everyone else. I honestly don't know when to bring up things like that, now. :) Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
I honestly don't know when to bring up things like that, now. :) For 3.2, _right_now_. What you're doing with Matt is the first stage; the next involves bringing it back to the 3.2-beta tree and testing it there. Please understand that if you (the community) aren't working on this, nobody else is. We don't have enough people manning the trenches because they're all sitting back in the chateau waiting for the afternoon dispatches. This doesn't work. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Fri, 30 Apr 1999, Mike Smith wrote: To sum it all up is there any difference between the branches? Yes. We hope that people like you will help us by participating in the testing of potential releases _before_ they go out as releases, not _afterwards_. Sitting around doing nothing and then complaining after the fact doesn't help anyone, least of all yourself. I seem to recall that there was a lot of noise about the instability of 3 before it was released, but that it went out the door because it had been taking too long. Wasn't it Greg Lehey who said that the beta period seemed more like integration testing? Ben You have your mind on computers, it seems. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
-stable vs -current (was Re: solid NFS patch #6... )
Well, what it comes down to is the number of developers actively developing the codebase. We had some truely unfortunate timing with people leaving and new people coming on, and pieces of the system ( such as NFS ) that simply were left dangling for a long period of time with nobody actively locating or fixing bugs. There have been too many critics and not enough people getting into the guts of the code and fixing things. ( Of course, I'm *very* biased here in my opinion :-) ). What it comes down to is that a whole lot of changes were made between 2.2.x and 3.0 without enough debugging by the authors. This kinda resulted in a partially rotting code base even through the 3.1 release, until a number of us got sick and tired of it and started actively tracking down and fixing the bugs. I expect the 3.2 release to be a really good release. It is true that -current has been, more often then not, more stable then -stable in the last two months. This is because fixes were being made to -current more quickly then they could be backported to -stable. Most of these fixes *have* been backported at this point. There are still a few that have not that are on my hot list ( and still not addressed, even with prodding ). There are also a few bug fixes that simply cannot be backported to stable without some pain ( i.e. require the complete replacement of a number of subsystems ), and pain is not in the cards with the 3.2 release so close. It is hard enough dealing with two branches of the source tree. I will personally take my Super Soaker 5000 to anyone suggesting that we have *three* . Sqirt sqirt sqirt! I am hoping that we will be able to accomplish a major synchronization after the 3.2 release. I personally believe that -current is stable enough that we should do one big-assed commit to sync -stable up to the current -current and then continue as per normal. I only wish EGCS hadn't been incorporated quite yet. At the very least, I want to sync *my* stuff up ( NFS/VM/VFS/BIO/VN/SWAPPER ). -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
On Friday, 30 April 1999 at 11:38:32 +0200, Brad Knowles wrote: Folks, I don't want to get into any OS wars here, but I'd like to do some low-level disk benchmarking of a Linux system using the same tool I used for that under FreeBSD, namely Greg Lehey's rawio (see ftp://ftp.lemis.com/pub/rawio.tar.gz). This program was originally written to test his vinum software mirroring/striping/RAID device driver for FreeBSD (see http://www.lemis.com/vinum.html), but I believe that it would be generally useful to do low-level disk testing under most any *nix OS. Anyway, if there's anyone out there with any experience in porting programs that do low-level disk I/O, I'd appreciate it if you could take a look at this program and give me some pointers on what it would take to get it to compile and run under Linux (specifically, Debian Linux with kernel 2.2.6). Also, since I'm not subscribed to either of these mailing lists and I can't keep up with the newsgroup gateway for them, I would appreciate it if you would also e-mail me any responses you might have on this subject. I don't really understand why you ask a FreeBSD group about it; it's a Linux issue. FWIW, about the only area where you're liable to run into difficulties is in the disk label handling round line 300, which is pretty peripheral to the function: it's just there as one way of finding out the size of the partition. You'll need in-depth Linux information to even find out if Linux has an equivalent function. If you have any other problems, send me the compiler output and I'll guess at what it might be. 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: -stable vs -current (was Re: solid NFS patch #6... )
On Fri, Apr 30, 1999 at 04:52:58PM -0700, Matthew Dillon wrote: I expect the 3.2 release to be a really good release. I seem to recall that 2.2.x wasn't even called -stable until 2.2.2. That .2 release is exactly where 3.x is right now... -- This .sig is not innovative, witty, or profund. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: ppbus causes hangs?
Yes, It's fixed my problem too. Many thanks. I don't know that skipping the probes and defaulting to high functionality wants to be the default, though, Matt. Best would be to figure out how to probe without mucking the chipset...is there something I can do to help, Mike? Eric Matthew Dillon wrote: : :Try setting the flags on the 'ppc' device to 0x40 and _please_ report :the results. Yes, this fixes the problem for me. But, it has to be the *DEFAULT*. The flag should be used to enable the more sophisticated operation that might freeze the machine up, not disable it. :-( -Matt 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: PCM
It must be something that entered the tree late yesterday afternoon or an interaction between devices. Same here... FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999 j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY ... pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0 pcm0: interrupting at irq 5 And I'm using this right now to listen to an mp3 of a Loggins and Messina album, so it must work. :-) One thing I did notice which *is* kinda new, as of this last kernel, is this: smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: interrupting at irq 17 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. devclass_alloc_unit: npx0 already exists, using next available unit number I'm pretty sure that npx0 does not already exist in this context, leading me to believe that the message is actually being intermingled with another probe's test or something is very odd here. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -stable vs -current (was Re: solid NFS patch #6... )
On Fri, 30 Apr 1999, Matthew Dillon wrote: Well, what it comes down to is the number of developers actively developing the codebase. We had some truely unfortunate timing with people leaving and new people coming on, and pieces of the system ( such as NFS ) that simply were left dangling for a long period of time with nobody actively locating or fixing bugs. There have been too many critics and not enough people getting into the guts of the code and fixing things. ( Of course, I'm *very* biased here in my opinion :-) ). What it comes down to is that a whole lot of changes were made between 2.2.x and 3.0 without enough debugging by the authors. This kinda resulted in a partially rotting code base even through the 3.1 release, until a number of us got sick and tired of it and started actively tracking down and fixing the bugs. I expect the 3.2 release to be a really good release. It is true that -current has been, more often then not, more stable then -stable in the last two months. This is because fixes were being made to -current more quickly then they could be backported to -stable. Most of these fixes *have* been backported at this point. There are still a few that have not that are on my hot list ( and still not addressed, even with prodding ). There are also a few bug fixes that simply cannot be backported to stable without some pain ( i.e. require the complete replacement of a number of subsystems ), and pain is not in the cards with the 3.2 release so close. It is hard enough dealing with two branches of the source tree. I will personally take my Super Soaker 5000 to anyone suggesting that we have *three* . Sqirt sqirt sqirt! 5000 is out? YES!!! I am hoping that we will be able to accomplish a major synchronization after the 3.2 release. I personally believe that -current is stable enough that we should do one big-assed commit to sync -stable up to the current -current and then continue as per normal. I only wish EGCS hadn't been incorporated quite yet. At the very least, I want to sync *my* stuff up ( NFS/VM/VFS/BIO/VN/SWAPPER ). I wholeheartedly agree with this idea! -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message 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: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
I don't really understand why you ask a FreeBSD group about it; it's a
Linux issue. FWIW, about the only area where you're liable to run
into difficulties is in the disk label handling round line 300, which
is pretty peripheral to the function: it's just there as one way of
finding out the size of the partition. You'll need in-depth Linux
information to even find out if Linux has an equivalent function.
Open the device, and
if (ioctl(fd, BLKGETSIZE, (caddr_t) seeklim) 0) {
see linux/fs.h
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
On Friday, 30 April 1999 at 20:51:06 -0700, Matt Jacob wrote:
I don't really understand why you ask a FreeBSD group about it; it's a
Linux issue. FWIW, about the only area where you're liable to run
into difficulties is in the disk label handling round line 300, which
is pretty peripheral to the function: it's just there as one way of
finding out the size of the partition. You'll need in-depth Linux
information to even find out if Linux has an equivalent function.
Open the device, and
if (ioctl(fd, BLKGETSIZE, (caddr_t) seeklim) 0) {
see linux/fs.h
Thanks for the info. Looking at this, it looks as if this ioctl is
for a block device. rawio uses character devices. Does that make a
difference?
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: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
On Friday, 30 April 1999 at 20:51:06 -0700, Matt Jacob wrote:
I don't really understand why you ask a FreeBSD group about it; it's a
Linux issue. FWIW, about the only area where you're liable to run
into difficulties is in the disk label handling round line 300, which
is pretty peripheral to the function: it's just there as one way of
finding out the size of the partition. You'll need in-depth Linux
information to even find out if Linux has an equivalent function.
Open the device, and
if (ioctl(fd, BLKGETSIZE, (caddr_t) seeklim) 0) {
see linux/fs.h
Thanks for the info. Looking at this, it looks as if this ioctl is
for a block device. rawio uses character devices. Does that make a
difference?
(
everyone... wait for it wait for it wait for it... NOW!
AAARHHH!!!
)
There are no raw devices in Linux. Linus is totally against them as
stupid. Linus has some good points about this, but it's still an, um,
interesting stance.
Let me qualify that slightly- Steve Tweedie has some patches to provide
this finally in the post 2.2 time frame. I helped folks hack an mmap of
kernel memory to provide 'raw, direct I/O' functionality years ago (they
needed to get video images off of disk, into memory, topped and tailed
with UDP info and sent out to the appropriate clients- when they went from
one Wide/Fast controller (it was that long ago) to two they only saw a 5%
increase in speed (can you spell 'copyin/copyout' boyz gurlz? Oh,
okay,. it's get_fs_long and put_fs_long in linux...)...
I just sent this to Brad, but here's a little pattern checker I use for *BSD,
solaris linux, oh yeah, and ConvexOS- much like rawio (which looks a
little more clean- I also have a disk exerciser-Yes, it's GPLd, but
basically it's for whomever... I really ought to add the DVH header for
IRIX/MIPS
For raw pattern testing Linux has a special challenge since you right
directly into the buffer cache. There *is* a BLKFLSBUF ioctl that can try
and force a flush but this probably ought to be written to use O_FSYNC- I
think that the ll_rw code might use it or an fsync could be done...
-matt
#ident $Id: $
/*
*
* Copyright (c) 1998, Matthew Jacob
*
* This software is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; version 2.
*
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public
* License along with this software; if not, write to the Free
* Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* The author may be reached via electronic communications at
*
* mja...@feral.com
*
* or, via United States Postal Address
*
* Matthew Jacob
* 1831 Castro Street
* San Francisco, CA, 94131
*
***
*
* $Log: patchk.c,v $
* Revision 1.2 1999/02/02 17:23:07 mjacob
* checkpoint
*
*/
#ifdef convex
#include sys/types.h
extern int optind;
extern int getopt(int, char **, const char *);
#define SEEK_T off64_t
#define SEEKlseek64
#define FSTAT fstat64
#define STAT_T stat64_t
#else
#define SEEK_T off_t
#define SEEKlseek
#define FSTAT fstat
#define STAT_T struct stat
#endif
#include unistd.h
#include stdlib.h
#include stdio.h
#include errno.h
#include fcntl.h
#include string.h
#include sys/stat.h
#include sys/time.h
#include sys/param.h
#include sys/ioctl.h
#ifdef sun
#define randlrand48
#define srand srand48
#ifdef __SVR4
#include sys/dkio.h
#else
#include sun/dkio.h
extern int gettimeofday(struct timeval *, struct timezone *);
extern void bzero(char *, int);
extern int strtol(const char *, char **, int);
#endif
extern int optind;
#endif
#ifdef __linux__
#include sys/ioctl.h
#include linux/fs.h
#endif
#ifdef convex
#include sys/ioctl.h
#include interfaces/io_if/scsi/scsi.h
#endif
#if defined(__NetBSD__) || defined(__OpenBSD__)
#include sys/disklabel.h
#include sys/dkio.h
#endif
#ifdef __FreeBSD__
#include sys/disklabel.h
#endif
#ifdef __ultrix
extern int optind;
#endif
#ifndef O_LARGEFILE
#define O_LARGEFILE 0
#endif
static int szarg(char *);
int
main(int a, char **v)
{
SEEK_T seekbase, seeklim, *buffer, wloc;
int blksize;
long long sb, sl;
STAT_T st;
int fd, i, error, create, nowrite;
seekbase = (SEEK_T) 0;
nowrite = 0;
srand((int)(time((time_t *) 0)/getpid()));
if (a != 4) {
usage:
fprintf(stderr,
Usage: %s raw-disk
Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
Linux had no char device last I looked.. everything is always buffered
this may have changed, but
On Sat, 1 May 1999, Greg Lehey wrote:
On Friday, 30 April 1999 at 20:51:06 -0700, Matt Jacob wrote:
I don't really understand why you ask a FreeBSD group about it; it's a
Linux issue. FWIW, about the only area where you're liable to run
into difficulties is in the disk label handling round line 300, which
is pretty peripheral to the function: it's just there as one way of
finding out the size of the partition. You'll need in-depth Linux
information to even find out if Linux has an equivalent function.
Open the device, and
if (ioctl(fd, BLKGETSIZE, (caddr_t) seeklim) 0) {
see linux/fs.h
Thanks for the info. Looking at this, it looks as if this ioctl is
for a block device. rawio uses character devices. Does that make a
difference?
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
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Error while make world (cvsuped 990501)
My system was suped at 990501. -- elf make world started on Sat May 1 09:36:25 MSD 1999 -- -- Cleaning up the temporary elf build tree -- mkdir -p /usr/obj/usr/src/tmp chflags -R noschg /usr/obj/usr/src/tmp/ rm -rf /usr/obj/usr/src/tmp -- Making make -- mkdir -p /usr/obj/usr/src/tmp/usr/bin /usr/obj/usr/src/tmp/make ( cd /usr/src/usr.bin/make; MAKEOBJDIRPREFIX=; unset MAKEOBJDIRPREFIX; PATH=/usr/obj/usr/src/tmp/sbin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/bin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin GCC_EXEC_PREFIX=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib/ LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib NOEXTRADEPEND=t OBJFORMAT_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/libexec MAKEOBJDIR=/usr/obj/usr/src/tmp/make make DESTDIR=/usr/obj/usr/src/tmp -I/usr/src/share/mk -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED all; PATH=/usr/obj/usr/src/tmp/sbin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/bin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin BISON_SIMPLE=/usr/obj/usr/src/t! mp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin GCC_EXEC_PREFIX=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib/ LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib NOEXTRADEPEND=t OBJFORMAT_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/libexec MAKEOBJDIR=/usr/obj/usr/src/tmp/make make DESTDIR=/usr/obj/usr/src/tmp -I/usr/src/share/mk -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED install; PATH=/usr/obj/usr/src/tmp/sbin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/bin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin BISON_SIMPLE=/usr/obj/usr/src/tmp/usr/share/misc/bison.simple COMPILER_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/obj/usr/src/tmp/usr/bin GCC_EXEC_PREFIX=/usr/obj/usr/src/tmp/usr/lib:/usr/obj/usr/src/tmp/usr/lib/ LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/usr/lib LIBRARY_PATH=/usr/obj/usr/src/tm! p/usr/lib:/usr/obj/usr/src/tmp/usr/lib NOEXTRADEPEND=t OBJFORMAT_PATH=/usr/obj/usr/src/tmp/usr/libexec:/usr/libexec MAKEOBJDIR=/usr/obj/usr/src/tmp/make make DESTDIR=/usr/obj/usr/src/tmp -I/usr/src/share/mk -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED clean ) cc -O -pipe -I/usr/src/usr.bin/make -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/make/arch.c cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. REM To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Linux char devices (was: Porting Greg Lehey's rawio.c from FreeBSD to Linux...)
On Friday, 30 April 1999 at 21:25:12 -0700, Matt Jacob wrote:
On Friday, 30 April 1999 at 20:51:06 -0700, Matt Jacob wrote:
I don't really understand why you ask a FreeBSD group about it; it's a
Linux issue. FWIW, about the only area where you're liable to run
into difficulties is in the disk label handling round line 300, which
is pretty peripheral to the function: it's just there as one way of
finding out the size of the partition. You'll need in-depth Linux
information to even find out if Linux has an equivalent function.
Open the device, and
if (ioctl(fd, BLKGETSIZE, (caddr_t) seeklim) 0) {
see linux/fs.h
Thanks for the info. Looking at this, it looks as if this ioctl is
for a block device. rawio uses character devices. Does that make a
difference?
snip
There are no raw devices in Linux. Linus is totally against them as
stupid. Linus has some good points about this, but it's still an, um,
interesting stance.
It also makes it impossible for rawio to run accurately. rawio
measures device throughput, not system throughput. Cache the data and
you completely lose this ability (hey! Under Vinum, an array of four
floppies has a random read throughput of 50 MB/s!).
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
