Weird story with dump | restore
Hello ! Something is weird with standard dump/restore procedure which I've always used to relocate my filesystems. I'm using 4.0-19991208-CURRENT on two machines, one is my home machine with SiS 5591 ATA controller and the other one has Intel PIIX. Home machine has disk pair Seagate 6.4GB and IBM 37.5GB, the other one Quantum Fireball 1GB and Fujitsu 3.2GB. First pair is in standard WDMA2 mode, the other one in PIO as per ata driver boot messages. Both setups have disks on separate channels, disks are masters. Problem: I'm trying to use dump/restore pair piped together to relocate / and /usr filesystems to the secondary master disk. In the first case from Seagate to IBM and second case from Quantum to Fujitsu. Target disks have innocent filesystems just created. On the home machine with SiS controller the overall dump/restore process runs smoothly until phase IV when it will do regular file dumping. Now the process stops regularly for about 10 seconds, then runs for 4 seconds or so. The process just runs, stops, runs, stops and so forth. Intervals aren't always same, but the stopped period is always longer. I dropped to in-kernel debugger and used ps to view process states. The dump wmesg column showed pipdwt and sbwait, for restore it's nbufkv. There's five lines for dump overall, the not mentioned were in wait or pause state. After viewing ps in debugger I continued the usual run and launced top. Everything stops while the restore process enters into nbuf?? state, top can't refresh screen etc, but everything continues after stopped period so I can see the restore process state changing. For the record, at last I used pax to relocate the data on the /usr filesystem and pax showed exactly same behavior. Difference was in reversed stop/run sequence, runs lasted lot longer than stopped states, pax even run for ten minutes, then stopped for about 13 seconds. The wd driver has same behavior, kernel with wd driver has same configuration as ata one. This claim is only true for SiS 5591 case as I've not tried yet with other machine. For other machine everything is same except machine stops completely. I've tried to disable softupdates on both source and target filesystems but no difference. All procedures were done in single user mode. It's very annoying, I have only fair experiences with dump/restore back to the 2.2.2 days until now. machine i386 ident Vokk maxusers32 makeoptions CONF_CFLAGS=-fno-builtin #Don't allow use of memcmp, etc. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options PQ_NORMALCACHE # color for 256k/16k cache cpu I586_CPU# aka Pentium Pro(tm) options COMPAT_43 options SYSVSHM options SYSVSEM options SYSVMSG options MD5 options DDB options DDB_UNATTENDED options INET#Internet communications protocols pseudo-device ether #Generic Ethernet pseudo-device loop#Network loopback device pseudo-device bpf #Berkeley packet filter options ICMP_BANDLIM options FFS #Fast filesystem options NFS #Network File System options CD9660 #ISO 9660 filesystem options PROCFS #Process filesystem options FFS_ROOT#FFS usable as root device options SOFTUPDATES options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L pseudo-device pty #Pseudo ttys pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. options MSGBUF_SIZE=40960 controller isa0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device vga0at isa? port ? conflicts pseudo-device splash device sc0 at isa? options MAXCONS=8 # number of virtual consoles options SC_HISTORY_SIZE=800 # number of history buffer lines device npx0at nexus? port IO_NPX flags 0x0 irq 13 controller ata0 device atadisk0# ATA disk drives device atapicd0# ATAPI CDROM drives options ATA_ENABLE_ATAPI_DMA controller fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 controller miibus0 controller pci0 device vr0 controller ppbus0 device lpt0at ppbus? device plip0 at ppbus? device ppi0at ppbus? device ppc0at isa? port? irq 7 options CLK_CALIBRATION_LOOP options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION --
Re: Serious server-side NFS problem
We've solved most of the performance issues, but NFS is still eating a little too much cpu for my tastes. Unfortunately it is getting to the point where a significant portion of the performance loss is occuring in the network driver itself. Some of my cards eat 25% of the cpu just in 'interrupt' (at 10 MBytes/sec half duplex), not even counting the TCP or UDP stacks. This is mainly due to the MTU being too small (i.e. packet fragmentation takes it toll on the interrupt subsystem). SCSI cards are way ahead of NIC cards in regards to reducing interrupt overhead (though gigabit NICs have caught up some). Actually, I'm not sure I buy this at all. Both the EtherExpress and 3C905 families give less than one interrupt per datagram, and the other overheads on them are comparably small. I think you'll want to do some profiling before getting too concerned about the network drivers themselves; gigabit hardware isn't really any lighter on the CPU than good 100Mbps hardware, and we can handle better than 400MBps UDP inbound on a reasonable (400MHz) system right now. (Lots better with jumbo frames.) My guesses (based on some of the profiling that Bill Paul did) would be the IP and UDP checksum guessing, but more that I think you'll find that a considerable amount of the inbound NFS traffic handling is actually performed in the interrupt context (ie. I don't think that stuff is being handed off to a softnet handler), blowing out the numbers a bit. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux /proc and vmware.
In message [EMAIL PROTECTED], Chuck Rob ey writes: I'd also like to see us have enough information in /proc to be able to divorce ps friends from libkvm. It would be nice to be able to have most tools continue to work if you have mismatched kernels userlands. Such transparancy can be made with with either /proc or sysctl. I thought the work was going in precisely the opposite way, so that jail could work without any visibility to /proc. Well, if you want to run linux binaries which insist on peeking into /proc you will need to mount a procfs there. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
In message [EMAIL PROTECTED], Soren Schmidt writes: It seems Richard Seaman, Jr. wrote: Yup, sounds like the problem some are seing, now I wonder why I havn't seen it on any of the IBM disks I've access to, hmm... It apparantly can't be disabled, but I'll try to figure out if I can detect when the drive is in this mode, or put it in standby mode and back again when there is nothing else to do, that should reset the timer... Probably the best thing to do would be to write a "atamaint" program and schedule a cronjob to run it at 05:00 every morning or something. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious server-side NFS problem
On Wed, 15 Dec 1999, Matthew Dillon wrote: Here's a general update on this bug report to -current. It took all day but I was finally able to reproduce Andrew's bug. You guys are going to *love* this. NFS uses the kernel 'boottime' structure to generate its version id. Now normally you might believe that this structure, once set, will never change. The authors of NFS certainly make that assumption! No such luck. If you happen to be running, oh, xntpd for example, the kernel adjusts the boottime structure to take into account time changes, including PLL changes so, in fact, the boottime structure can change quite often - once each tick, in fact. Nice catch, Matt. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird story with dump | restore
On Fri, Dec 17, 1999 at 10:47:59AM +0200, Vallo Kallaste [EMAIL PROTECTED] wrote: [snip] It's very annoying, I have only fair experiences with dump/restore back to the 2.2.2 days until now. Sorry for the long post and partially? false alert. Something in my mind waked up and I checked what type of bsize and fsize the other machines have. Now I remember a little discussion in the cvs-all list, at that time phk committed something about default flags for newfs or so and there was rgrimes involved into discussion. He was suggesting following flags for filesystem creation for newer, bigger disks: newfs -b16384 -f2048 -u2048 -c128 -i4096 I've used them since with no problems whatsoever. Now I got the dump done on the machine with default filesystem, the bugger is unusual filesystem I guess. Is it expected behavior? Does anybody know why it can't be done? -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world broken
On Fri, Dec 17, 1999 at 04:30:16PM -0700, Darren Wiebe wrote: I just built the world from sources about 3-4 hours ago. It was all great. Fwiw, I just got the same error on another system, cvsupped this morning. -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sh(1) broken caching [was: Re: Broken sh(1)?]
In [EMAIL PROTECTED], David O'Brien wrote: On Thu, Dec 16, 1999 at 03:40:20PM +0100, Martin Cracauer wrote: You can also fool sh into running the *wrong* binary if if you have two in showdowed paths: pdksh does not suffer from either this problem or the problem that started this thread (and does not coredump). We've shown in the past that pdksh is actually smaller (when linked statically) than ash. I still think we should *seriously* consider switching to pdksh. As I said before, pdksh has other bugs. Try this in pdksh: #! /bin/sh emacs -nw /tmp/bla mv /tmp/bla /tmp/bla2 Two times: - first run, do not hit C-g in emacs - second run, use C-g in emacs In the second run, the `mv` will not be executed, while in the first it will. This is not a bug, but a design decision in pdksh (see also my homepage - sigint.html). It's poor man's workaround about programs that don't exit with a proper signal status when they exit on a signal. Also we would loose all the PRs we received in the past. This testing effort by our user base is a valuable resource. From the tests I ran on all available shells, only bash2 is considerably better than the other shells, pdksh has other bugs than our ash, not less. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: is it really at the end of its lifecycle?
Thus spake Peter Jeremy ([EMAIL PROTECTED]): -rwxr-xr-x 1 jeremyp inplat 96509 Dec 17 08:08 minigzip % cc -O -o minigzip minigzip.c /usr/lib/libz.a What about stripping? root:/usr/src/usr.bin/minigzip $ ls -l minigzip -rwxr-xr-x 1 root bin 96921 17 Dez 12:35 minigzip root:/usr/src/usr.bin/minigzip $ strip minigzip root:/usr/src/usr.bin/minigzip $ ls -l minigzip -rwxr-xr-x 1 root bin 90044 17 Dez 12:35 minigzip root:/usr/src/usr.bin/minigzip $ cc -O -o minigzip minigzip.o /usr/lib/libz.a root:/usr/src/usr.bin/minigzip $ ls -l minigzip -rwxr-xr-x 1 root bin 48699 17 Dez 12:36 minigzip root:/usr/src/usr.bin/minigzip $ strip minigzip root:/usr/src/usr.bin/minigzip $ ls -l minigzip -rwxr-xr-x 1 root bin 45240 17 Dez 12:36 minigzip Alex -- I doubt, therefore I might be. PGP signature
ATA Problem? Fallback to PIO
I seem to be having a problem with the my Western Digital Caviar 6.4GB UDMA33 (5400RPM?) Hard Drive. I get the following error: ad0: WDC WD200BA/P76CA30A ATA-4 disk at ata0 as master ad0: 19092MB (39102336 sectors), 38792 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA33 ad1: WDC AC36400L/09.09M08 ATA-4 disk at ata0 as slave ad1: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 1 depth queue, UDMA33 . . . Mounting root from ufs:/dev/ad1s2a ad1: UDMA CRC WRITE ERROR blk# 1999 retrying ad1: UDMA CRC WRITE ERROR blk# 1999 retrying ad1: UDMA CRC WRITE ERROR blk# 1999 retrying ad1: UDMA CRC WRITE ERROR blk# 1999 falling back to PIO mode I do not have any problems with this drive under Windows98, WindowsNT, FreeBSD3.x or Linux. Never an error reported before. What does this mean? I am using the GENERIC kernel from the FreeBSD 4.0-19991215-CURRENT #0: Wed Dec 15 16:26:48 GMT 1999 snapshot. I have not had time to recompile as of yet. I do know that this drive is partitioned funny with ad1s1 as a 2000MB FAT16 partition and the rest as UFS. I saw a warning once that x number of sectors are not being used because of the off-size of the partitions. Perhaps I should repartition? As a side question - why are the CD-ROM (see DMESG below) drives using PIO? Thanks in advance, Tom Veldhouse [EMAIL PROTECTED] DMESG output follows: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-19991215-CURRENT #0: Wed Dec 15 16:26:48 GMT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x612 Stepping = 2 Features=0x81f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,P AT,MMX AMD Features=0xc040AMIE,DSP,3DNow! real memory = 134152192 (131008K bytes) config di lnc0 config di le0 config di ie0 config di fe0 config di ex0 config di ed0 config di cs0 config di wt0 config di scd0 config di mcd0 config di matcd0 config di bt0 config di aic0 config di aha0 config di adv0 config q avail memory = 126492672 (123528K bytes) Preloaded elf kernel "kernel" at 0xc0378000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc037809c. Pentium Pro MTRR support enabled md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: AMD-751 host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: AMD-751 PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 vga-pci0: NVidia model 002d graphics accelerator irq 10 at device 5.0 on pci1 pci0: unknown card (vendor=0x1274, dev=0x1371) at 3.0 irq 11 dc0: LC82C115 PNIC II 10/100BaseTX irq 5 at device 6.0 on pci0 dc0: Ethernet address: 00:a0:cc:37:ad:85 miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: VIA 82C686 PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: VIA 82C686 ATA controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 pci0: VIA 83C572 USB controller (vendor=0x1106, dev=0x3038) at 7.2 irq 11 pci0: VIA 83C572 USB controller (vendor=0x1106, dev=0x3038) at 7.3 irq 11 isab1: PCI to ISA bridge (vendor=1106 device=3057) at device 7.4 on pci0 pci0: unknown card (vendor=0x127a, dev=0x1003) at 9.0 irq 10 pci0: unknown card (vendor=0x104c, dev=0x8019) at 12.0 irq 3 fe0: not probed (disabled) fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ata-isa0: already registered as ata0 ata-isa1: already registered as ata1 adv0: not probed (disabled) bt0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) wt0: not probed (disabled) mcd0: not probed (disabled) matcd0: not probed (disabled) scd0: not probed (disabled) atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio2: not probed (disabled) sio3: not probed (disabled) ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppb0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: Lexmark Lexmark 5700 LEXWPS plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 ed0: not probed (disabled) ex0: not probed (disabled) ie0: not probed (disabled)
Re: ATA driver problem?? (lost disk contact)
On Fri, Dec 17, 1999 at 08:22:03AM +0100, Soren Schmidt wrote: Yup, sounds like the problem some are seing, now I wonder why I havn't seen it on any of the IBM disks I've access to, hmm... It apparantly can't be disabled, but I'll try to figure out if I can detect when the drive is in this mode, or put it in standby mode and back again when there is nothing else to do, that should reset the timer... Note that the wd driver doesn't "report" any problems. Don't know if that is because the wd driver handles this differently, or because the reporting is different. The machine that reports these problems runs 7/24, and has for over a year and a half. The IBM disk has been in for quite a while (maybe 6 months or more). Only ata "reports" the problem. Note that the IBM specs say that spinup from standby to idle is 13 secs "typical" and 31 secs max for this drive. I'm assuming that what we're seeing is that the ata driver "lost contact" because the timeout is less that the time it takes to spinup from standby to idle (or to spinup from an interrupted switch from idle to standby)? -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA Problem? Fallback to PIO
It seems Thomas T. Veldhouse wrote: I seem to be having a problem with the my Western Digital Caviar 6.4GB UDMA33 ad0: WDC WD200BA/P76CA30A ATA-4 disk at ata0 as master ad0: 19092MB (39102336 sectors), 38792 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, UDMA33 ad1: WDC AC36400L/09.09M08 ATA-4 disk at ata0 as slave ad1: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 1 depth queue, UDMA33 . . . Mounting root from ufs:/dev/ad1s2a ad1: UDMA CRC WRITE ERROR blk# 1999 retrying ad1: UDMA CRC WRITE ERROR blk# 1999 retrying ad1: UDMA CRC WRITE ERROR blk# 1999 retrying ad1: UDMA CRC WRITE ERROR blk# 1999 falling back to PIO mode I do not have any problems with this drive under Windows98, WindowsNT, FreeBSD3.x or Linux. Never an error reported before. Hmm, the WDC WD200BA disk does UDMA66 doesn't it ?? The VIA 82C686 has support for this, but its very "generous" in setting it. Form the above I'd guess you dont have a 80lead cable on those disks ?? What does the BIOS say about the disk modes on boot ?? A dmesg from a verbose boot would be nice... Also what mobo is this ? I guess the VIA has decided to run UDMA66 which wont work without the right cable... As a side question - why are the CD-ROM (see DMESG below) drives using PIO? Because ATAPI DMA is disabled as default (the old driver didn't even have DMA support for ATAPI devices), see lint how to enable it. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
It seems Richard Seaman, Jr. wrote: Yup, sounds like the problem some are seing, now I wonder why I havn't seen it on any of the IBM disks I've access to, hmm... It apparantly can't be disabled, but I'll try to figure out if I can detect when the drive is in this mode, or put it in standby mode and back again when there is nothing else to do, that should reset the timer... Note that the wd driver doesn't "report" any problems. Don't know if that is because the wd driver handles this differently, or because the reporting is different. Because the wd driver has a 10 secs timeout, and ata has 5 secs. I think the easiest way to "solve" this is to increase the timeout to 10-15 secs, as little as I want to do that... The machine that reports these problems runs 7/24, and has for over a year and a half. The IBM disk has been in for quite a while (maybe 6 months or more). Only ata "reports" the problem. Se above.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATA driver, ZIP-Disk and mtools now OK
today i tried again a windows formatted ZIP disk with mtools. First with a line in /usr/local/etc/mtools.conf drive z: file="/dev/afd0s4" --- this does not work!! i had a message like init Z: sector size too big Cannot initialize 'Z:' this message i have never seen before, so i gave poking around with mtools.conf another try. Looking at solaris examples, i edited drive z: file="/dev/afd0s4" partition=4 # this works and now it works! -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver, ZIP-Disk and mtools now OK
It seems Fritz Heinrichmeyer wrote: today i tried again a windows formatted ZIP disk with mtools. First with a line in /usr/local/etc/mtools.conf drive z: file="/dev/afd0s4" --- this does not work!! i had a message like init Z: sector size too big Cannot initialize 'Z:' this message i have never seen before, so i gave poking around with mtools.conf another try. Looking at solaris examples, i edited drive z: file="/dev/afd0s4" partition=4 # this works and now it works! Hmm, so my gut feeling that the atapi-fd driver did what it should was not that far off :) Thanks for reporting, I was about to spend time on this problem in the weekend, now I can tick that on off -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver, ZIP-Disk and mtools now OK, but mount_msdos ...
Of course i wish you a nice weekend ... but only mtools work. Mount_msdos still fails: mount_msdos /dev/afd0s4 /mnt mount_msdos: /dev/afd0s4: Invalid argument -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver, ZIP-Disk and mtools now OK, but mount_msdos ...
It seems Fritz Heinrichmeyer wrote: Of course i wish you a nice weekend ... but only mtools work. Mount_msdos still fails: mount_msdos /dev/afd0s4 /mnt mount_msdos: /dev/afd0s4: Invalid argument Hmm, strange, are you sure the dospartition is on slice 4 ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA Problem? Fallback to PIO
On Fri, 17 Dec 1999, Soren Schmidt wrote: Hmm, the WDC WD200BA disk does UDMA66 doesn't it ?? The VIA 82C686 has support for this, but its very "generous" in setting it. Form the above I'd guess you dont have a 80lead cable on those disks ?? What does the BIOS say about the disk modes on boot ?? A dmesg from a verbose boot would be nice... Also what mobo is this ? I guess the VIA has decided to run UDMA66 which wont work without the right cable... This is a compaq special motherboard (5868 series). If I would have known what I as getting, I wouldn't have bought the computer. The BIOS offers nearly nothing in the way of options. I do know it uses a VIA chipset and the AMD 751 chipset. I don't really have more specifics other than what you see in the dmesg. I will get you a verbose dmesg tonight. I will also see what BIOS settings are available. I do believe all of them are set to auto for the IDE interfaces. I do believe the drive is UDMA66 capable - but I never looked into it. Perhaps I should get a different cable. Ironically, Linux drops that drive to PIO. Because ATAPI DMA is disabled as default (the old driver didn't even have DMA support for ATAPI devices), see lint how to enable it. -Søren Cool. Real CD performance. Thanks, Tom Veldhouse [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID datapoint.
"Mike" == Mike Smith [EMAIL PROTECTED] writes: The AMI MegaRAID 1400 delivers between 16.5 and 19 M/s (the 19M/s value is somewhat contrived --- using 8 bonnies in parrallel and then summing their results --- which is not 100% valid)... but the MegaRAID appears to be stable. Mike Hmm. Those numbers aren't so great though. I'd be interested Mike to know how busy the controller is during your test (use systat Mike -vmstat 1 and look at the amrd0 device), as well as how you've Mike configured it. AMI's default configurations for those Mike controllers is wildly inconsistent between one BIOS version and Mike the next. Well... it's RAID-5 across the same 8 drives with all 8 drives on one LVD chain (same configuration as the other test). I have tried the 128k stripe, but it was slower than the default 64k stripe. I would like to know, however, if there are any planned or in-the-works utility programs for the amr device. In particular, a program to print the state of the array would be useful. Mike I'm currently waiting on AMI for more documentation, at which Mike point there will indeed be more monitoring and control Mike facilities added. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor gcc-issue ?
On Fri, 17 Dec 1999, Pascal Hofstee wrote: freebsd-aout.h: #define TARGET_DEFAULT \ (MASK_80387 | MASK_IEEE_FP | MASK_FLOAT_RETURNS | MASK_NO_FANCY_MATH_387) freebsd.h: #define TARGET_DEFAULT (MASK_NO_FANCY_MATH_387 | 0301) apparently the defines for MASK_80387 | MASK_IEEE_FP | MASK_FLOAT_RETURNS got combined into one single octal value. If have doubts that this is actually intended. 0301 is an old (bad) way of spelling MASK_80387 | MASK_IEEE_FP | MASK_FLOAT_RETURNS. Cygnus finally fixed it in in gcc/config/i386/freebsd.h on 1999/03/23 (see the ChangeLog), but FreeBSD hasn't merged the change. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver, ZIP-Disk and mtools now OK, but mount_msdos ...
On 17 Dec, Soren Schmidt wrote: Of course i wish you a nice weekend ... but only mtools work. Mount_msdos still fails: mount_msdos /dev/afd0s4 /mnt mount_msdos: /dev/afd0s4: Invalid argument Hmm, strange, are you sure the dospartition is on slice 4 ?? Yes (mounting /dev/wfd0s4 works). Bye, Alexander. -- Dead men tell no tales, unless you're in forensics. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor gcc-issue ?
On Sat, 18 Dec 1999, Bruce Evans wrote: 0301 is an old (bad) way of spelling MASK_80387 | MASK_IEEE_FP | MASK_FLOAT_RETURNS. Cygnus finally fixed it in in gcc/config/i386/freebsd.h on 1999/03/23 (see the ChangeLog), but FreeBSD hasn't merged the change. Thanks ... I do have on eother question though ... does this mean that FreeBSD by default compiles with the -mieee-fp compile switch. As that is the solution (for SIGFPE issues) suggested by some Mozilla people on Bugzilla. If FreeBSD indeed already compiles with the -mieee-flag on default the fix obviously should be looked for elsewhere. If you could clarify this issue for me it would be hightly appreciated. Pascal Hofstee - [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS d- s+: a-- C++ UB P+ L- E--- W- N+ o? K- w--- O? M V? PS+ PE Y-- PGP-- t+ 5 X-- R tv+ b+ DI D- G e* h+ r- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver, ZIP-Disk and mtools now OK
On 17 Dec, Fritz Heinrichmeyer wrote: drive z: file="/dev/afd0s4" partition=4 # this works and now it works! Confirmed, mtools works (mount remains). I think this gives Søren a start to look at. If I remember correctly one of the first versions of ata didn´t had this problem (it stopped perhaps at the 3. or 4. "Heads-Up"). Bye, Alexander. -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. http://netchild.home.pages.de Alexander+Home @ Leidinger.net Key fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious server-side NFS problem
On Fri, 17 Dec 1999 00:55:26 -0800, Mike Smith [EMAIL PROTECTED] said: the IP and UDP checksum guessing, but more that I think you'll find that a considerable amount of the inbound NFS traffic handling is actually performed in the interrupt context If it is, then there is a serious bug. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious server-side NFS problem
... (200-300 MHz) clients. That's *with* packet loss (for some reason when my fxp ethernets pump data out that quickly they tend to cause packet loss in other parts of my HUBed network, which I find quite annoying). Interesting you should say that I've been playing with some broadcom based ASIC 100BaseTX full duplex switches and I actually loose more packets due to overrunning the buffers in the switch than I do if I used a half duplex standard hub. :-( Performance for most things overall on the network is better with the switch, but direct high bandwidth traffic between 2 machines has suffered due to the conversion to a fully switched network. Seems FreeBSD (using dc21143 based cards) can pump data around so damn fast that the switch can't keep up :-(. I need to do some more testing to find out if this occurs between ports on the same ASIC or only when packets have to go out to the ASIC to ASIC bridge bus. Also how do the fxp and dc based cards respond to flow control? Do we obey it? Do the cards even understand it? -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID datapoint.
At 10:02 AM -0500 1999/12/17, David Gilbert wrote: Well... it's RAID-5 across the same 8 drives with all 8 drives on one LVD chain (same configuration as the other test). I have tried the 128k stripe, but it was slower than the default 64k stripe. One of the lessons I learned from Greg was that, when dealing with RAID implementations in hardware, you should usually take their "native" stripe size, since that's the one that will usually perform best. It's only when you do software RAID (e.g., vinum) that you can choose larger or smaller stripe sizes with a reasonable expectation that you will get the particular performance enhancement that you're hoping for. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird story with dump | restore
On Fri, Dec 17, 1999 at 10:47:59AM +0200, Vallo Kallaste [EMAIL PROTECTED] wrote: [snip] It's very annoying, I have only fair experiences with dump/restore back to the 2.2.2 days until now. Sorry for the long post and partially? false alert. Something in my mind waked up and I checked what type of bsize and fsize the other machines have. Now I remember a little discussion in the cvs-all list, at that time phk committed something about default flags for newfs or so and there was rgrimes involved into discussion. He was suggesting following flags for filesystem creation for newer, bigger disks: newfs -b16384 -f2048 -u2048 -c128 -i4096 I've used them since with no problems whatsoever. Now I got the dump done on the machine with default filesystem, the bugger is unusual filesystem I guess. Is it expected behavior? Does anybody know why it can't be done? A few more details please. Are you having problems when you are dumping from a file system formatted as above, or is it a restore going to this type of file system, or are both the source and destination file system formatted as above? EXACTLY what dump/restore pipeline command did you run? I'll try to duplicate this here... I suspect a blocking/unblocking operation is highly un optimized to deal with these large block size file systems and/or your exasting a kernel resource during this operation. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID datapoint.
"Brad" == Brad Knowles [EMAIL PROTECTED] writes: Brad At 10:02 AM -0500 1999/12/17, David Gilbert wrote: Well... it's RAID-5 across the same 8 drives with all 8 drives on one LVD chain (same configuration as the other test). I have tried the 128k stripe, but it was slower than the default 64k stripe. Brad One of the lessons I learned from Greg was that, when dealing Brad with RAID implementations in hardware, you should usually take Brad their "native" stripe size, since that's the one that will Brad usually perform best. Brad It's only when you do software RAID (e.g., vinum) that you can Brad choose larger or smaller stripe sizes with a reasonable Brad expectation that you will get the particular performance Brad enhancement that you're hoping for. Another thing that I find very different betweent he vinum software RAID-5 and the hardware I've tried (I've used both the DPT and the MegaRAID controllers) that the latency of a command can be incredible on the hardware raid. If you type (for instance) 'du -ks foo' where foo is a big directory on the hardware raid, and then press CTRL-C, it can take 10 to 15 seconds to come back (I'm assuming that this is queued I/O requests). Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious server-side NFS problem
:On Fri, 17 Dec 1999 00:55:26 -0800, Mike Smith [EMAIL PROTECTED] said: : : the IP and UDP checksum guessing, but more that I think you'll find that : a considerable amount of the inbound NFS traffic handling is actually : performed in the interrupt context : :If it is, then there is a serious bug. : :-GAWollman : :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same No serious NFS traffic handling is done in the interrupt context. The packets are essentially just queued up for nfsd to deal with. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
In message [EMAIL PROTECTED] Alexander Langer writes: : When I boot my new kernel, I get : root mount failure: 6 This is ENXIO, Device Not Configured. What is the name of the device that it is trying to mount? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious server-side NFS problem
Kenneth D. Merry writes: Another advantage with gigabit ethernet is that if you can do jumbo frames, you can fit an entire 8K NFS packet in one frame. I'd like to see NFS numbers from two 21264 Alphas with GigE cards, zero copy, checksum offloading and a big striped array on one end at least. I Well.. maybe this will work for you ;-) 2 21264 alphas (500MHz XP1000S), 640MB RAM, Myrinet/Trapeze using 64-bit Myrinet cards, 8K cluster mbufs, UDP checksums disabled (we can do checksum offloading at the receiver only). We have a 56K MTU. Using this setup, *without* zero copy, we get roughly 140MB/sec out of TCP: % netperf -Hbroil-my TCP STREAM TEST to broil-my : histogram Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 524288 524288 52428810.011135.20 And about 900Mb/sec (112MB/sec) out of UDP using an 8k message size: % netperf -Hbroil-my -tUDP_STREAM -- -m 8192 UDP UNIDIRECTIONAL SEND TEST to broil-my : histogram Socket Message Elapsed Messages SizeSize Time Okay Errors Throughput bytes bytessecs# # 10^6bits/sec 573448192 10.00 165619 01084.94 65535 10.00 137338899.68 I have exported a local disk on broil-my and created a 512MB file (zot). Both machines have 640MB of ram and the test file is fully cached on the server. When reading the file from the client, I have found the best I can do is roughly 57MB/sec: # mount_nfs -a 3 -r 16384 boil-my:/var/tmp /mnt # dd if=/mnt/zot of=/dev/null bs=64k 8192+0 records in 8192+0 records out 536870912 bytes transferred in 9.658521 secs (55585209 bytes/sec) # umount /mnt # mount_nfs -a 3 -r 32768 boil-my:/var/tmp /mnt # if=/mnt/zot of=/dev/null bs=64k 8192+0 records in 8192+0 records out 536870912 bytes transferred in 9.513517 secs (56432433 bytes/sec) Emperically, it seems that -a 3 performs better than -a 2 or -a 4. Also, the bandwidth seems to max out with a 16k read size. Increasing much beyond that doesn't seem to help. Varying the number if nfsiods across between 2,4 20 doesn't seem to matter much. Running iprobe on the client (http://www.cs.duke.edu/ari/iprobe.html) shows us that we are spending: - 29.4% in bcopy -- this doesn't change a lot if I enable/disable vfs_ioopt. I suspect that this is from bcopy'ing data out of mbufs, not crossing the user/kernel boundary. In either case, there's not much that can be done to reduce this in a generic manner. - 5.5% tsleep (contention between nfsiods?) The "top" functions/components are: Name Count Pct Pct -- - --- --- kernel412890.0 bcopy_samealign_lp1347 32.6 29.4 procrunnable 279 6.8 6.1 tsleep 256 6.2 5.6 Lidle2 195 4.7 4.3 m_freem 89 2.2 1.9 soreceive 73 1.8 1.6 lockmgr 63 1.5 1.4 brelse 60 1.5 1.3 vm_page_free_toq55 1.3 1.2 ovbcopy 51 1.2 1.1 wakeup 43 1.0 0.9 acquire 42 1.0 0.9 bcopy_da_lp 42 1.0 0.9 nfs_request 41 1.0 0.9 ip_input40 1.0 0.9 biodone 39 0.9 0.9 nfs_readrpc 38 0.9 0.8 vm_page_alloc 36 0.9 0.8 ... -- /modules/tpz.ko435 9.5 tpz.ko is the myrinet device driver. This is saying that the system spent 90% of its time in the static kernel, 9.5% in the device driver, and 0.5% in userland. The server is also close to maxed-out. I can provide an iprobe breakdown for it as well, and/or complete breakdowns for the client and server. Cheers, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
On Fri, Dec 17, 1999 at 10:17:33AM -0700, Warner Losh wrote: : When I boot my new kernel, I get : root mount failure: 6 This is ENXIO, Device Not Configured. What is the name of the device that it is trying to mount? ad0s1a an IDE drive with the new ata-drivers. Also, the same for wd0s1a and rwd0s1a Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
In message [EMAIL PROTECTED] Alexander Langer writes: : ad0s1a : an IDE drive with the new ata-drivers. : Also, the same for wd0s1a and rwd0s1a That looks good. Can you send the config file and the boot messages, at least those related to ata/ad? And a ls -l /dev/ad0* might not hurt either. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird story with dump | restore
: suggesting following flags for filesystem creation for newer, bigger : disks: : : newfs -b16384 -f2048 -u2048 -c128 -i4096 : : I've used them since with no problems whatsoever. Now I got the dump : done on the machine with default filesystem, the bugger is unusual : filesystem I guess. Is it expected behavior? Does anybody know why it : can't be done? : :A few more details please. Are you having problems when you are :dumping from a file system formatted as above, or is it a restore :going to this type of file system, or are both the source and destination :file system formatted as above? : :EXACTLY what dump/restore pipeline command did you run? : :I'll try to duplicate this here... I suspect a blocking/unblocking :operation is highly un optimized to deal with these large block size :file systems and/or your exasting a kernel resource during this :operation. : :-- :Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] Hmm. With a block size of 16384 and restore getting stuck in 'nbufkv', it sounds like a problem with the buffer cache. The buffer cache can get into this state if there are too many dirty buffers eating up available KVM. Try changing the vfs.lodirtybuffers and vfs.hidirtybuffers sysctl variables. Try halving the values for both and tell me if that solves the problem. sysctl -a | fgrep dirty sysctl -w vfs.lodirtybuffers=X sysctl -w vfs.hidirtybuffers=Y Where X and Y are appropriate numbers. The delay you are seeing is due to the fact that getnewbuf() no longer synchronously flushes buffers out. I'll look into fixing the code to better handle this situation. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
On Fri, Dec 17, 1999 at 10:24:19AM -0700, Warner Losh wrote: That looks good. Can you send the config file and the boot messages, at least those related to ata/ad? And a ls -l /dev/ad0* might not hurt either. Unfortunately, I cant send the boot-messages, because they aren`t logged and I have no serial console. But there seems to be no error. The disk is detected correctly with UDMA33 and no errors appear. But I can send the other stuff. crw-r- 1 root operator 116, 0x00010002 Dec 17 18:56 /dev/ad0 crw-r- 1 root operator 116, 0 Dec 17 18:56 /dev/ad0a crw-r- 1 root operator 116, 1 Dec 17 18:56 /dev/ad0b crw-r- 1 root operator 116, 2 Dec 17 18:56 /dev/ad0c crw-r- 1 root operator 116, 3 Dec 17 18:56 /dev/ad0d crw-r- 1 root operator 116, 4 Dec 17 18:56 /dev/ad0e crw-r- 1 root operator 116, 5 Dec 17 18:56 /dev/ad0f crw-r- 1 root operator 116, 6 Dec 17 18:56 /dev/ad0g crw-r- 1 root operator 116, 7 Dec 17 18:56 /dev/ad0h crw-r- 1 root operator 116, 0x00020002 Dec 17 18:56 /dev/ad0s1 crw-r- 1 root operator 116, 0x0002 Dec 17 18:56 /dev/ad0s1a crw-r- 1 root operator 116, 0x00020001 Dec 17 18:56 /dev/ad0s1b crw-r- 1 root operator 116, 0x00020002 Dec 17 18:56 /dev/ad0s1c crw-r- 1 root operator 116, 0x00020003 Dec 17 18:56 /dev/ad0s1d crw-r- 1 root operator 116, 0x00020004 Dec 17 18:56 /dev/ad0s1e crw-r- 1 root operator 116, 0x00020005 Dec 17 18:56 /dev/ad0s1f crw-r- 1 root operator 116, 0x00020006 Dec 17 18:56 /dev/ad0s1g crw-r- 1 root operator 116, 0x00020007 Dec 17 18:56 /dev/ad0s1h crw-r- 1 root operator 116, 0x00030002 Dec 17 18:56 /dev/ad0s2 crw-r- 1 root operator 116, 0x00040002 Dec 17 18:56 /dev/ad0s3 crw-r- 1 root operator 116, 0x00050002 Dec 17 18:56 /dev/ad0s4 crw-r- 1 root operator 116, 0x0001000a Dec 17 18:56 /dev/ad1 crw-r- 1 root operator 116, 8 Dec 17 18:56 /dev/ad1a crw-r- 1 root operator 116, 9 Dec 17 18:56 /dev/ad1b crw-r- 1 root operator 116, 10 Dec 17 18:56 /dev/ad1c crw-r- 1 root operator 116, 11 Dec 17 18:56 /dev/ad1d crw-r- 1 root operator 116, 12 Dec 17 18:56 /dev/ad1e crw-r- 1 root operator 116, 13 Dec 17 18:56 /dev/ad1f crw-r- 1 root operator 116, 14 Dec 17 18:56 /dev/ad1g crw-r- 1 root operator 116, 15 Dec 17 18:56 /dev/ad1h crw-r- 1 root operator 116, 0x0002000a Dec 17 18:56 /dev/ad1s1 crw-r- 1 root operator 116, 0x0003000a Dec 17 18:56 /dev/ad1s2 crw-r- 1 root operator 116, 0x00030008 Dec 17 17:24 /dev/ad1s2a crw-r- 1 root operator 116, 0x00030009 Dec 17 17:24 /dev/ad1s2b crw-r- 1 root operator 116, 0x0003000a Dec 17 17:24 /dev/ad1s2c crw-r- 1 root operator 116, 0x0003000b Dec 17 17:24 /dev/ad1s2d crw-r- 1 root operator 116, 0x0003000c Dec 17 17:24 /dev/ad1s2e crw-r- 1 root operator 116, 0x0003000d Dec 17 17:24 /dev/ad1s2f crw-r- 1 root operator 116, 0x0003000e Dec 17 17:24 /dev/ad1s2g crw-r- 1 root operator 116, 0x0003000f Dec 17 17:24 /dev/ad1s2h crw-r- 1 root operator 116, 0x0004000a Dec 17 18:56 /dev/ad1s3 crw-r- 1 root operator 116, 0x0005000a Dec 17 18:56 /dev/ad1s4 crw-r- 1 root operator 116, 0x00010012 Dec 17 18:56 /dev/ad2 crw-r- 1 root operator 116, 16 Dec 17 18:56 /dev/ad2a crw-r- 1 root operator 116, 17 Dec 17 18:56 /dev/ad2b crw-r- 1 root operator 116, 18 Dec 17 18:56 /dev/ad2c crw-r- 1 root operator 116, 19 Dec 17 18:56 /dev/ad2d crw-r- 1 root operator 116, 20 Dec 17 18:56 /dev/ad2e crw-r- 1 root operator 116, 21 Dec 17 18:56 /dev/ad2f crw-r- 1 root operator 116, 22 Dec 17 18:56 /dev/ad2g crw-r- 1 root operator 116, 23 Dec 17 18:56 /dev/ad2h crw-r- 1 root operator 116, 0x00020012 Dec 17 18:56 /dev/ad2s1 crw-r- 1 root operator 116, 0x00030012 Dec 17 18:56 /dev/ad2s2 crw-r- 1 root operator 116, 0x00040012 Dec 17 18:56 /dev/ad2s3 crw-r- 1 root operator 116, 0x00050012 Dec 17 18:56 /dev/ad2s4 crw-r- 1 root operator 116, 0x0001001a Dec 17 18:56 /dev/ad3 crw-r- 1 root operator 116, 24 Dec 17 18:56 /dev/ad3a crw-r- 1 root operator 116, 25 Dec 17 18:56 /dev/ad3b crw-r- 1 root operator 116, 26 Dec 17 18:56 /dev/ad3c crw-r- 1 root operator 116, 27 Dec 17 18:56 /dev/ad3d crw-r- 1 root operator 116, 28 Dec 17 18:56 /dev/ad3e crw-r- 1 root operator 116, 29 Dec 17 18:56 /dev/ad3f crw-r- 1 root operator 116, 30 Dec 17 18:56 /dev/ad3g crw-r- 1 root operator 116, 31 Dec 17 18:56 /dev/ad3h crw-r- 1 root operator 116, 0x0002001a Dec 17 18:56 /dev/ad3s1 crw-r- 1 root operator 116, 0x0003001a Dec 17 18:56 /dev/ad3s2 crw-r- 1 root operator 116, 0x0004001a Dec 17 18:56 /dev/ad3s3 crw-r- 1 root operator 116, 0x0005001a Dec 17 18:56 /dev/ad3s4 Attached is the config-file.
Re: ata: Mount root failure: 6
In message [EMAIL PROTECTED] Alexander Langer writes: : crw-r- 1 root operator 116, 0x00010002 Dec 17 18:56 /dev/ad0 You didn't copy MAKEDEV from a current source tree before making these devices. The major number of ad is 30, not 116. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
In message [EMAIL PROTECTED] Warner Losh writes: : You didn't copy MAKEDEV from a current source tree before making these : devices. The major number of ad is 30, not 116. Actually, this is wrong. I didn't update MY MAKEDEV before looking. 30 is the old major bdev number... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fcnt, ecvt, gcvt and XFree86 2.9.16f build errors
Hi, The latest XFree86 snapshot, 3.9.16f (which is about to become the public 3.9.17 snapshot) does not build on FreeBSD -current. It compains about fcvt, ecvt and gcvt. The exact error log from building XFree86 3.9.16f follows. It compiles ok on my 3.4 box (just CVSuped) The next public snapshot of XFree86 3.9.x is due very soon, so a quick fix would be great. Cheers Roger -- Roger Hardiman [EMAIL PROTECTED] [EMAIL PROTECTED] fcvt, ecvt and gcvt are used in ./xc/lib/misc/snprintf.c The important part of my make log follows making all in ./programs... making all in programs/appres... ..snip.. cc -o bitmap -O -L../../exports/lib BitEdit.o CutPaste.o Graphics.o ReqMach.o Bitmap.o Dialog.o Handlers.o -lXaw -lXmu -lXt -lSM -lICE -lXpm -lXext -lX11 -L/usr/X11R6/lib-lm ../../exports/lib/libXaw.a(MultiSrc.o): In function `InitStringOrFile': MultiSrc.o(.text+0xf7c): warning: tmpnam() possibly used unsafely; consider using mkstemp() ../../exports/lib/libXmu.a(Lower.o): In function `conv_fp': Lower.o(.text+0x4b): undefined reference to `fcvt' Lower.o(.text+0x6a): undefined reference to `ecvt' ../../exports/lib/libXmu.a(Lower.o): In function `vsnprintf': Lower.o(.text+0x85b): undefined reference to `gcvt' *** Error code 1 (continuing) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
On Fri, Dec 17, 1999 at 10:53:01AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Alexander Langer writes: : crw-r- 1 root operator 116, 0x00010002 Dec 17 18:56 /dev/ad0 You didn't copy MAKEDEV from a current source tree before making these devices. The major number of ad is 30, not 116. My latest -current tree has the following MAKEDEV and MAKEDEV.local: /usr/src/etc/MAKEDEV:# $FreeBSD: src/etc/MAKEDEV,v 1.226 1999/12/14 22:36:03 joerg Exp $ /usr/src/etc/MAKEDEV.local:# $FreeBSD: src/etc/MAKEDEV.local,v 1.3 1999/08/27 23:23:40 peter Exp $ That are the ones I used. Are these the right ones? If so, why does it fail for me (incorrect major number) but not for you? Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
On Fri, Dec 17, 1999 at 11:18:05AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Alexander Langer writes: : That are the ones I used. Are these the right ones? Turns out those are the right ones. : If so, why does it fail for me (incorrect major number) but not for you? Don't know. Still doesn't work, btw, also with major num of 30. BTW: The MAKEDEV _really_ does include 116 as major num. If this an error - could one _please_ correct this? Thank you. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA Problem? Fallback to PIO
It seems Thomas Veldhouse wrote: Hmm, the WDC WD200BA disk does UDMA66 doesn't it ?? The VIA 82C686 has support for this, but its very "generous" in setting it. Form the above I'd guess you dont have a 80lead cable on those disks ?? What does the BIOS say about the disk modes on boot ?? A dmesg from a verbose boot would be nice... Also what mobo is this ? I guess the VIA has decided to run UDMA66 which wont work without the right cable... This is a compaq special motherboard (5868 series). If I would have known what I as getting, I wouldn't have bought the computer. The BIOS offers nearly nothing in the way of options. I do know it uses a VIA chipset and the AMD 751 chipset. I don't really have more specifics other than what you see in the dmesg. I will get you a verbose dmesg tonight. I will also see what BIOS settings are available. I do believe all of them are set to auto for the IDE interfaces. Hmm, never buy "brand name" PC's, better get two clones for the same price :), however the chipset combo are the same as on m K7M, the secret ASUS board... I do believe the drive is UDMA66 capable - but I never looked into it. Perhaps I should get a different cable. Ironically, Linux drops that drive to PIO. Well, last I looked Linux didn't have any real support for the VIA 82c686, maybe its because VIA doesn't have a spec sheet for it online. I've done some experimentation, and have some sparse docs, but its not perfect (neither are the VIA chips I might add) Because ATAPI DMA is disabled as default (the old driver didn't even have DMA support for ATAPI devices), see lint how to enable it. Cool. Real CD performance. Yup, I get around 4M/sec of my drive with no CPU load, real nice... But be carefull, alot of ATAPI devices dont take DMA that well, and some chipsets are real crappy in that respect too -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird story with dump | restore
:The source filesystems were both standard with bsize 8192 and fsize
:1024. Target filesystems were nonstandard.
:
:I umounted the source filesystem, in the exact case /usr (/dev/ad0s1e),
:then mounted target filesystem to /mnt, cd to /mnt and
:
:dump -0a -f - /dev/ad0s1e | restore rf -
:--
:
:Vallo Kallaste
:[EMAIL PROTECTED]
Try this patch to -current, it should solve the problem. I've been
meaning to fixup the buf_daemon for a while. This solves the
buf_daemon problem. We still will not be entirely optimal due to kvm
reshuffling but that's a different problem.
-Matt
Index: vfs_bio.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.237
diff -u -r1.237 vfs_bio.c
--- vfs_bio.c 1999/12/01 02:09:29 1.237
+++ vfs_bio.c 1999/12/17 18:44:40
@@ -88,7 +88,7 @@
bufmallocspace, maxbufmallocspace, hibufspace;
static int maxbdrun;
static int needsbuffer;
-static int numdirtybuffers, lodirtybuffers, hidirtybuffers;
+static int numdirtybuffers, hidirtybuffers;
static int numfreebuffers, lofreebuffers, hifreebuffers;
static int getnewbufcalls;
static int getnewbufrestarts;
@@ -96,8 +96,6 @@
SYSCTL_INT(_vfs, OID_AUTO, numdirtybuffers, CTLFLAG_RD,
numdirtybuffers, 0, "");
-SYSCTL_INT(_vfs, OID_AUTO, lodirtybuffers, CTLFLAG_RW,
- lodirtybuffers, 0, "");
SYSCTL_INT(_vfs, OID_AUTO, hidirtybuffers, CTLFLAG_RW,
hidirtybuffers, 0, "");
SYSCTL_INT(_vfs, OID_AUTO, numfreebuffers, CTLFLAG_RD,
@@ -275,6 +273,16 @@
}
}
+/*
+ * bd_speedup - speedup the buffer cache flushing code
+ */
+
+static __inline__
+void
+bd_speedup(void)
+{
+ bd_wakeup(1);
+}
/*
* Initialize buffer headers and related structures.
@@ -353,7 +361,6 @@
* Reduce the chance of a deadlock occuring by limiting the number
* of delayed-write dirty buffers we allow to stack up.
*/
- lodirtybuffers = nbuf / 7 + 10;
hidirtybuffers = nbuf / 4 + 20;
numdirtybuffers = 0;
/*
@@ -365,14 +372,9 @@
* the buffer cache.
*/
while (hidirtybuffers * BKVASIZE 3 * hibufspace / 4) {
- lodirtybuffers = 1;
hidirtybuffers = 1;
buf_maxio = 1;
}
- if (lodirtybuffers 2) {
- lodirtybuffers = 2;
- hidirtybuffers = 4;
- }
/*
* Temporary, BKVASIZE may be manipulated soon, make sure we don't
@@ -799,9 +801,9 @@
void
bwillwrite(void)
{
- int twenty = (hidirtybuffers - lodirtybuffers) / 5;
+ int slop = hidirtybuffers / 10;
- if (numdirtybuffers hidirtybuffers + twenty) {
+ if (numdirtybuffers hidirtybuffers + slop) {
int s;
s = splbio();
@@ -1571,9 +1573,8 @@
flags = VFS_BIO_NEED_ANY;
}
- /* XXX */
+ bd_speedup(); /* hlp */
- (void) speedup_syncer();
needsbuffer |= flags;
while (needsbuffer flags) {
if (tsleep(needsbuffer, (PRIBIO + 4) | slpflag,
@@ -1652,6 +1653,7 @@
static struct proc *bufdaemonproc;
static int bd_interval;
static int bd_flushto;
+static int bd_flushinc;
static struct kproc_desc buf_kp = {
"bufdaemon",
@@ -1672,6 +1674,7 @@
bd_interval = 5 * hz; /* dynamically adjusted */
bd_flushto = hidirtybuffers;/* dynamically adjusted */
+ bd_flushinc = 1;
while (TRUE) {
bd_request = 0;
@@ -1694,44 +1697,38 @@
}
}
- /*
-* If nobody is requesting anything we sleep
-*/
- if (bd_request == 0)
- tsleep(bd_request, PVM, "psleep", bd_interval);
+ if (bd_request ||
+ tsleep(bd_request, PVM, "psleep", bd_interval) == 0) {
+ /*
+* Another request is pending or we were woken up
+* without timing out. Flush more.
+*/
+ --bd_flushto;
+ if (bd_flushto = numdirtybuffers - 5) {
+ bd_flushto = numdirtybuffers - 10;
+ bd_flushinc = 1;
+ }
+ if (bd_flushto 2)
+ bd_flushto = 2;
+ } else {
+ /*
+* We slept and timed out, we can slow down.
+*/
+ bd_flushto += bd_flushinc;
+ if (bd_flushto hidirtybuffers)
+ bd_flushto = hidirtybuffers;
+ ++bd_flushinc;
+ if (bd_flushinc hidirtybuffers / 20 + 1)
+
Re: AMI MegaRAID datapoint.
"Mike" == Mike Smith [EMAIL PROTECTED] writes: The AMI MegaRAID 1400 delivers between 16.5 and 19 M/s (the 19M/s value is somewhat contrived --- using 8 bonnies in parrallel and then summing their results --- which is not 100% valid)... but the MegaRAID appears to be stable. Mike Hmm. Those numbers aren't so great though. I'd be interested Mike to know how busy the controller is during your test (use systat Mike -vmstat 1 and look at the amrd0 device), as well as how you've Mike configured it. AMI's default configurations for those Mike controllers is wildly inconsistent between one BIOS version and Mike the next. Well... it's RAID-5 across the same 8 drives with all 8 drives on one LVD chain (same configuration as the other test). I have tried the 128k stripe, but it was slower than the default 64k stripe. Try enabling DirectIO and WriteBack if you haven't already. AMI's RAID5 implementation seems to suffer from rewriting the entire stripe when you do sub-stripe-sized writes, but I'm not sure about that yet. The Mylex controllers seem to have a small edge in performance, which may be due to them doing cache-line-sized I/Os (usually only 8k) in that case. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Serious server-side NFS problem
:On Fri, 17 Dec 1999 00:55:26 -0800, Mike Smith [EMAIL PROTECTED] said: : : the IP and UDP checksum guessing, but more that I think you'll find that : a considerable amount of the inbound NFS traffic handling is actually : performed in the interrupt context : :If it is, then there is a serious bug. No serious NFS traffic handling is done in the interrupt context. The packets are essentially just queued up for nfsd to deal with. That's interesting then, since your results are somewhat at odds with what I've seen so far regarding interrupt load for network traffic. Do you have any profiling results that point the finger more directly at anything? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID datapoint.
"Mike" == Mike Smith [EMAIL PROTECTED] writes: Mike Try enabling DirectIO and WriteBack if you haven't already. Mike AMI's RAID5 implementation seems to suffer from rewriting the Mike entire stripe when you do sub-stripe-sized writes, but I'm not Mike sure about that yet. Already done. This would explain why 128K stripes are bad. Mike The Mylex controllers seem to have a small edge in performance, Mike which may be due to them doing cache-line-sized I/Os (usually Mike only 8k) in that case. Maybe so, but they also don't seem to support the LVD-enabled versions of the Mylex cards. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
Try this: running an old/working kernel, run disklabel on all your disks/slices and make sure the "badsect" flag is NOT set. I ran into this a couple of nights ago, updating a machine (my laptop) to a current "-current". -- T.T.F.N., Dave Truesdell / [EMAIL PROTECTED][EMAIL PROTECTED] / UNIX system administrator To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID datapoint... or is it NFS
Another thing I've found with the MegaRAID (or maybe this is an nfs thing?) is that large scale (100Mb, full duplex) hits on the NFS server tend to lock up the nfs server (which has the megaraid in it). Typically, this includes not being able to access the non-raid root var and usr partitions. Any ideas? I can reproduce the problem, but it doesn't cause a panic. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMI MegaRAID datapoint... or is it NFS
:Another thing I've found with the MegaRAID (or maybe this is an nfs :thing?) is that large scale (100Mb, full duplex) hits on the NFS :server tend to lock up the nfs server (which has the megaraid in it). :Typically, this includes not being able to access the non-raid root :var and usr partitions. : :Any ideas? I can reproduce the problem, but it doesn't cause a panic. : :Dave. :|David Gilbert, Velocet Communications. | Two things can only be | You need to figure out what the processes are locked up in. If 'ps axl' doesn't work then you need to ctl-alt-esc into DDB (assuming the kernel is configured for DDB) and do a 'ps' there. It should be possible to narrow the problem down from that output. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problem?? (lost disk contact)
On Fri, Dec 17, 1999 at 02:28:29PM +0100, Soren Schmidt wrote: Because the wd driver has a 10 secs timeout, and ata has 5 secs. I think the easiest way to "solve" this is to increase the timeout to 10-15 secs, as little as I want to do that... I don't really understand disk drivers, so if I'm off base, I apologize. I'm under the impression that you can query the disk to see if its in idle mode, or if not, if its in standby mode. If you leave the timeout at 5 secs, and you actually timeout, perhaps you can check the disk to see if its in standby mode, or in the process of spinning up. If so, for just this case, perhaps you can adjust the timeout to a greater value before retrying the command? Also, perhaps you want to skip printing the diagnostic if the timeout was due to standby/spinup, unless it also fails on retry? -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fcnt, ecvt, gcvt and XFree86 2.9.16f build errors
Hi, The latest XFree86 snapshot, 3.9.16f (which is about to become the public 3.9.17 snapshot) does not build on FreeBSD -current. It compains about fcvt, ecvt and gcvt. The exact error log from building XFree86 3.9.16f follows. It compiles ok on my 3.4 box (just CVSuped) The problem is that gcc 2.95.2 in -current does not include #define __FreeBSD__ any more. XF can't tell the OS, so it assumes you lack snprintf(), and tries a different way of putting strings into numbers (fcvt, ecvt, gcvt). Check the top of a log from make World to see the OS detection. If you drop a #define __FreeBSD__ in config/cf/Imake.cf, it'll detect and get at least farther along. (still having troubles compiling from their cvs, going to submit a report rsn). Hopefully we can find a bit nicer way of doing things soon. -- Eric Anholt [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3COM 574BT 10/100 PCMCIA
[EMAIL PROTECTED] wrote: I see a few days ago that some one mentioned the 3COM 574BT 10/100 PCMICA card was still not supported. Is this true ??? Yes, it's still broken in -current. (I have one, I know.) Matt Dodd has the specs and the NIC (complements of Terry Murphy at 3Com), so it should be fixed Real Soon Now (meaning, when Matt gets to it). -- Frank Mayhar [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Proposed end-all fix for (Re: Make world broken in libc_r)
On Sat, Nov 27, 1999 at 11:40:08AM -0800, Alfred Perlstein wrote:
On Sat, 27 Nov 1999, Mark Murray wrote:
Hi
"make world" is broken in libc_r. Simple fix is to replace all
"socklen_t" with "int".
libc_r likes to pull data from /usr/include instead of the
source tree, "make includes" fixes this. I'm not sure if
that's the correct way to fix it though.
I've got a change in the pipeline that will cause world breakage again,
unless we do something about this. Is there anything wrong with simply
adding:
CFLAGS+=-I${.CURDIR}/../../include
to lib/libc_r/Makefile? It fixes such build problems.
Jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Weird story with dump | restore
On Fri, Dec 17, 1999 at 11:18:18AM -0800, Matthew Dillon [EMAIL PROTECTED] wrote: Try this patch to -current, it should solve the problem. I've been meaning to fixup the buf_daemon for a while. This solves the buf_daemon problem. We still will not be entirely optimal due to kvm reshuffling but that's a different problem. Thank you for your clear explanation and patch, I will try it out. Your previous suggestion to lower the dirtybuffers marks was successful. The initial values were 222 for hi and 125 for lowmark. Lowering them by half let the restore run as usual. Now I'm running off from an IBM 35GB disk :-) that's because my response was abit delayed. Thanks -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Success with ATA drivers and UDMA66
Hi all, I just wanted to let you know that I enabled UDMA66 (by plugging in an 80 conductor cable) on my WDC AC418000D today. The mainboard is an ABit BP6 with builtin Highpoint HPT366 ATA controller. The system works very nicely. I did some heavy testing in single user mode by moving several 300 Mb files around between the IDE disk and my other SCSI disk (which got me a sustained transfer rate of over 10 Mb/sec). Then I made world. Everything works great (softupdates enabled on all filesystems except "/"). If someone wants me to do some specific testing, let me know. Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Success with ATA drivers and UDMA66
On 18-Dec-99 Dave J. Boers wrote: The system works very nicely. I did some heavy testing in single user mode by moving several 300 Mb files around between the IDE disk and my other SCSI disk (which got me a sustained transfer rate of over 10 Mb/sec). Then I made world. Everything works great (softupdates enabled on all filesystems except "/"). /proc too? (although technically, /proc isn't a filesystem. ;-) -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fcnt, ecvt, gcvt and XFree86 2.9.16f build errors
On Fri, Dec 17, 1999 at 02:08:50PM -0800, Eric Anholt wrote: The problem is that gcc 2.95.2 in -current does not include #define The problem is that /usr/libexec/cpp ... __FreeBSD__ any more. XF can't tell the OS, so it assumes you lack A fix is on the way RSN. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: framemaker for linux
On Thu, 16 Dec 1999, Andrew Atrens wrote: All, This might be a linux ABI question, or it might be an `ld.so' question, so arguably I could have sent this to emulation, questions or since I run -current, current, or perhaps hackers, at any rate here goes - I've got `framemaker for linux' and am getting - # maker5X.exe maker5X.exe: error in loading shared libraries : undefined symbol: __register_frame_info I believe this is a libc issue. I remember running into this before, although on the FreeBSD ABI (I _think_). Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: minor gcc-issue ?
On Fri, 17 Dec 1999, Pascal Hofstee wrote: On Sat, 18 Dec 1999, Bruce Evans wrote: 0301 is an old (bad) way of spelling MASK_80387 | MASK_IEEE_FP | MASK_FLOAT_RETURNS. Cygnus finally fixed it in in gcc/config/i386/freebsd.h on 1999/03/23 (see the ChangeLog), but FreeBSD hasn't merged the change. Thanks ... I do have on eother question though ... does this mean that FreeBSD by default compiles with the -mieee-fp compile switch. As that is Yes. the solution (for SIGFPE issues) suggested by some Mozilla people on Bugzilla. Very unlikely. -mieee-fp just fixes comparisons of Quiet NaNs with 0, at a small cost in efficiency. As a side effect, this prevents SIGFPEs for comparisons of Quiet NaNs with 0 when the invalid-operand exception is not masked, but if you have a Quiet NaN, then you are probably running with invalid-operand exceptions masked and wouldn't be worried about SIGFPEs. Quiet NaNs are normally generated by invalid operations, e.g., 0.0/0.0 when the invalid-operand exception is masked. If this exception is unmasked, then 0.0/0.0 generates a SIGFPE and leaves the operands on the FPU stack. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: framemaker for linux
On Fri, 17 Dec 1999, Doug White wrote:
Date: Fri, 17 Dec 1999 20:45:40 -0800 (PST)
From: Doug White [EMAIL PROTECTED]
To: "Atrens, Andrew (A.B.) [EXCHANGE:SKY:1U33]"
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: framemaker for linux
On Thu, 16 Dec 1999, Andrew Atrens wrote:
All,
This might be a linux ABI question, or it might be an `ld.so' question,
so arguably I could have sent this to emulation, questions or since I run
-current, current, or perhaps hackers, at any rate here goes -
I've got `framemaker for linux' and am getting -
# maker5X.exe
maker5X.exe: error in loading shared libraries
: undefined symbol: __register_frame_info
I believe this is a libc issue. I remember running into this before,
although on the FreeBSD ABI (I _think_).
Quite possibly since at the root of it, it's a gcc/egcs incompatibility.
The problem is described quite nicely in the glibc FAQ -
| 2.8.When I run an executable on one system which I compiled on
| another, I get dynamic linker errors. Both systems have the same
| version of glibc installed. What's wrong?
|
| {ZW} Glibc on one of these systems was compiled with gcc 2.7 or 2.8, the
| other with egcs (any version). Egcs has functions in its internal
| `libgcc.a' to support exception handling with C++. They are linked into
| any program or dynamic library compiled with egcs, whether it needs them
| or
| not. Dynamic libraries then turn around and export those functions again
| unless special steps are taken to prevent them.
|
| When you link your program, it resolves its references to the exception
| functions to the ones exported accidentally by libc.so. That works fine
| as
| long as libc has those functions. On the other system, libc doesn't have
| those functions because it was compiled by gcc 2.8, and you get undefined
| symbol errors. The symbols in question are named things like
| `__register_frame_info'.
The best thing to do is get the glibc-2.1.2-11.i386.rpm from redhat and
install it with -
rpm --ignoreos --root=/usr/compat/linux --nodeps -i glibc-2.1.2-11.i386.rpm
This version apparently has stubs for __register_frame_info and friends
and so will work irregardless of which gcc it was built with.
Andrew.
--
+--
| Andrew Atrens Nortel Networks, Ottawa, Canada. |
| All opinions expressed are my own, not those of any employer. |
--+
Heller's Law: The first myth of management is that it exists.
Johnson's Corollary: Nobody really knows what is going on
anywhere within the organization.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Success with ATA drivers and UDMA66
"Dave J. Boers" wrote: Hi all, I just wanted to let you know that I enabled UDMA66 (by plugging in an 80 conductor cable) on my WDC AC418000D today. The mainboard is an ABit BP6 with builtin Highpoint HPT366 ATA controller. The system works very nicely. I did some heavy testing in single user mode by moving several 300 Mb files around between the IDE disk and my other SCSI disk (which got me a sustained transfer rate of over 10 Mb/sec). Then I made world. Everything works great (softupdates enabled on all filesystems except "/"). If someone wants me to do some specific testing, let me know. Do you boot from the UDMA66 drive ? What is your BIOS revision ? How many SDARM DIMMs do you use ? What is the rating of your Power supply ? Do you use an AGP graphics board ? (I also have a BP6 and I'm mildly satisfied by its stability up to now, I'm looking for ways to upgrade it and hints to increase the reliability) TfH Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
