Re: switching schedulers (Re: SCHED_ULE should not be the default)
Adrian Chadd said: Hi all, Can someone load a kernel module dynamically at boot-time? Ie, instead of compiling it in, can 4bsd/ule be loaded as a KLD at boot-time, so the user can just change by rebooting? That may be an acceptable solution for now. As Luigi explained, the problem is not to have code for both schedulers residing in the kernel, the problem is to migrate processes from one scheduler to the other. -- Michel Talon ta...@lpthe.jussieu.fr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1
O Hartmann says: For the underlying OS, as far as I know, the compiler hasn't as much impact as on userland software since autovectorization and other neat things are not used during system build. From my experience using gcc 4.2 or 4.4/4.5 does not have an impact beyond 3% when SSE isn't explicetly enforced. More interesting is the performance gain due to the architecture. I think it would be very easy for M. Larabel to repeat this benchmark with a bleeding edge Ubuntu or Suse as well. And since FreeBSD 9.0 can be compiled with CLANG, it should be possible to compare both also with bleeding edge compilers, say FreeBSD 9/CLANG, Ubuntu 12/gcc 4.6.2. My experience is that using gcc 4.6 gives *much* better performance than using the obsolete gcc that is in FreeBSD and much better performance than clang. After all you have to pay the price for stupidities such as being GPL free. Or you can see it otherwise, you can compete on the most GPL free system, or the best working system. As for the ZFS versus ext3 performance, here also if you try to sell FreeBSD on features which are supposed to have extraordinary benefits don't be surprised when testers use these features and find horrendous performance issues. -- Michel Talon ta...@lpthe.jussieu.fr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: switching schedulers (Re: SCHED_ULE should not be the default)
Le 16 déc. 2011 à 22:51, Doug Barton a écrit : On 12/16/2011 13:40, Michel Talon wrote: Adrian Chadd said: Hi all, Can someone load a kernel module dynamically at boot-time? Ie, instead of compiling it in, can 4bsd/ule be loaded as a KLD at boot-time, so the user can just change by rebooting? That may be an acceptable solution for now. As Luigi explained, the problem is not to have code for both schedulers residing in the kernel, the problem is to migrate processes from one scheduler to the other. I think dynamically switching schedulers on a running system and loading one or the other at boot time are different problems, are they not? Of course, you are perfectly right., and i had misunderstood Adrian's post. But if the problem is only to change scheduler by rebooting, i think it is no more expensive to compile a kernel with the other scheduler. Or is it that people never compile kernels nowadays? The ability to switch scheduler on a running machine would certainly be a more desirable way to test the best adaptation of the system to the load. To come back to the problems in question about ULE i must say i don't see obvious malfunctions for my own use (i had some problems of this sort long ago, but they disappeared with more recent FreeBSD). Doug -- Michel Talon ta...@lpthe.jussieu.fr ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RFC vgrind in base (and buildworld)
Damien Fleuriot wrote: I think I'm speaking for a reasonable amount of people when I say: I have no idea what vgrind is used for to begin with. Anyways, there is also a reasonable number of people who know what vgrind is about: pretty printing various source codes through troff particularly C code. Another tool doing the same through TeX is tgrind. The less clutter, the better :) Except perhaps not two people have the same idea of clutter. For example many people think that half of the content of the so-called base system is clutter. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD-7.2 works excellent
Hello, just a word to say that the upgrade from FreeBSD-7.1 to 7.2 has solved all problems i had on my desktop (very slow windowing, etc.) without changing anything to the installed ports. Now everything works excellent in accordance with the FreeBSD tradition. Thanks for the good work of the developers -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Invalid path for portupgrade ftp.FreeBSD.orgpub
I think you can access that in the ruby program pkg_fetch (/usr/local/sbin/pkg_fetch) in function real_fetch_pkg, i have the following: $pkg_site_uris.each do |uri_base| PKG_SUFFIXES.each do |suffix| uri = uri_base + (subdir + '/' + pkgname + suffix) path = path_base + suffix fetch(uri, path) and return path end end Here probably you lack the '/' -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: A nasty ataraid experience.
Bruce M Simpson wrote: Following the rebuild procedure in the Handbook, if you try to run atacontrol rebuild from the FreeBSD 7.1 LiveFS, it'll break. I ran it thinking that it had some kind of magic in it which I couldn't achieve using dd alone, which is partly true, but also partly not true. It has a hardcoded path to /usr/bin/nice, which it runs using the system() libc call, and unfortunately, the LiveFS is rooted at /mnt2. It does this after it issues an ioctl() to tell the ATA driver to copy and rewrite the meta-data to the new spare drive. I always use the LiveFS cdromin the following way: chroot /mnt2 set -o emacs mount -t devfs devfs /dev export PAGER=more so that i am exactly in the same situation as on a real machine. HOMEWORK: Why does fdisk still assume 16 heads... ? Perhaps we should have a switch to tell it to use the LBA-style C/H/S converted geometry? FreeBSD fdisk is a calamity. I also now understand that I can't rely on RAID alone to keep the integrity of my own data -- there is no substitute for backups, I just wish there were realistic backup solutions for individuals trying to do things with technology right now, without paying over the odds, or being ripped off. A solution to keep backups without paying over the odds is to backup your data to another hard disk. This doesn't mean using RAID mirror, it means using rsync or similar to copy data regularly. It is preferable that this occurs on another machine, and even better in another geographic location. But even if the backup disk is on the same machine, this protects againts inadvertent deletions of a file or RAID misbehaviors. The risk being that some hardware problem simultaneously corrupts the main storage and the backup. Modern features such as UFS snapshots or better ZFS snapshots allow to produce better backups. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Big problems with 7.1 locking up :-(
UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801DB (ICH4) USB controller USB-C port 0xb000-0xb01f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: Intel 82801DB/L/M (ICH4) USB 2.0 controller mem 0xde80-0xde8003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: Intel 82801DB/L/M (ICH4) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb3 uhub3: 6 ports with 6 removable, self powered pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 bfe0: Broadcom BCM4401 Fast Ethernet mem 0xde00-0xde001fff irq 20 at device 5.0 on pci2 miibus0: MII bus on bfe0 bmtphy0: BCM4401 10/100baseTX PHY PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:0c:6e:04:5d:39 bfe0: [ITHREAD] fxp0: Intel 82559 Pro/100 Ethernet port 0xa800-0xa83f mem 0xdd80-0xdd800fff,0xdd00-0xdd0f irq 23 at device 11.0 on pci2 miibus1: MII bus on fxp0 inphy0: i82555 10/100 media interface PHY 1 on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:1d:df:8e fxp0: [ITHREAD] sym0: 875 port 0xa400-0xa4ff mem 0xdc80-0xdc8000ff,0xdc00-0xdc000fff irq 20 at device 12.0 on pci2 sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking sym0: [ITHREAD] isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f irq 18 at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] pcm0: Intel ICH4 (82801DB) port 0x9800-0x98ff,0x9400-0x943f mem 0xdb80-0xdb8001ff,0xdb00-0xdbff irq 17 at device 31.5 on pci0 pcm0: [ITHREAD] pcm0: Analog Devices AD1980 AC97 Codec fdc0: floppy drive controller port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: ACPI CPU on acpi0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 p4tcc1: CPU Frequency Thermal Control on cpu1 pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xccfff,0xd-0xd0fff pnpid ORM on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 ppbus0: [ITHREAD] lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] ums0: vendor 0x04d9 product 0x048e, class 0/0, rev 1.10/8.00, addr 2 on uhub1 ums0: 5 buttons and Z dir. WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle ZFS filesystem version 6 ZFS storage pool version 6 ad0: 58644MB Maxtor 6Y060L0 YAR41VW0 at ata0-master UDMA100 acd0: DVDR TSSTcorpCD/DVDW SH-S182D/SB02 at ata1-master UDMA33 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe5:sym0:0:5:0): phase change 6-7 6...@01a0c7a8 resid=4. (da0:sym0:0:5:0): phase change 6-7 6...@01a0c7a8 resid=4. da0 at sym0 bus 0 target 5 lun 0 da0: IOMEGA ZIP 100 J.03 Removable Direct Access SCSI-2 device da0: 3.300MB/s transfers da0: 96MB (196608 512 byte sectors: 64H 32S/T 96C) cd0 at ata1 bus 0 target 0 lun 0 cd0: TSSTcorp CD/DVDW SH-S182D SB02 Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /home was not properly dismounted /home: mount pending error: blocks 128 files 10 WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 -- Michel
Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY
Jeremy Chadwick wrote: I believe we're in overall agreement with regards to background_fsck (should be disabled by default). In fact background fsck has been introduced for a good reason: waiting for a full fsck on modern big disks is far too long. Similarly write cache is enabled on ata disks for the reason that without it performance sucks too much. My humble opinion is that you attach far far too much importance to reliability in this game. There are many reasons why corruption may happen in the files, most of them being hardware related (bad ram, overheating chipset, etc.) Hence you can never be assured that your data is perfectly reliable (except perhaps ZFS permanent checksumming), all you have is some probability of reliability. I think that for most people what is important is a good balance between the risk of catastrophic failure (which is always here, and is increased little by background fsck) and the performance and ease of use. The FreeBSD developers have chosen this middle ground, with good reason, in my opinion. People who are more concerned with the reliability of their data, and want to pay the price can always disable background fsck, maintain backups, etc. Personnally i would run away from a system requiring hours of fsck before being able to run multiuser. Neither Windows, with NTFS, nor Linux, with ext3, reiserfs, xfs, jfs, etc. require any form of scandisk or fsck. Demanding that full fsck is the default in FreeBSD is akin to alienating a large fraction of users who have greener pasture easily available. Idem for asking to disable write caching on the disks. So for most people there is a probability to get some day the UNEXPECTED SOFT UPDATE INCONSISTENCY message. They will run a full fsck in that occasion, not a terrible thing. In many years of FreeBSD use, it happened me a small number of times, and i have still to loose a file, at least that i remarked. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with dtrace
Still testing FreeBSD-7.1-beta encountered the following (perhaps to be expected) result with dtrace: dtrace -m kernel - some output - deadlock after a few seconds. Less demanding tracing worked OK. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy disk controller broken
On Wed, Sep 17, 2008 at 05:13:39PM -0400, John Baldwin wrote: On Wednesday 17 September 2008 11:04:33 am Michel Talon wrote: Hello, when testing FreeBSD-7.1-BETA i discovered that the floppy disk controller doesn't work correctly. Trying to format a floppy (perhaps with bad blocks) i get: Processing fdformat: ioctl(FD_FORM): Device not configured instead of the normal E letter. I then checked the same problem is present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in 2006! Of course the floppy disk driver is particularly messy, but this is not pretty. (*) i386/103862: Error with fdformat It looks like the ioctl to format a track used to never report failures from the controller. The newer driver does. What I've done with fdformat is to make it just ignore the errors in userland instead. Try this: Index: fdformat.c === --- fdformat.c(revision 183112) +++ fdformat.c(working copy) @@ -75,8 +75,7 @@ f.fd_formb_secno(i) = il[i+1]; f.fd_formb_secsize(i) = secsize; } - if(ioctl(fd, FD_FORM, (caddr_t)f) 0) - err(EX_OSERR, ioctl(FD_FORM)); + (void)ioctl(fd, FD_FORM, (caddr_t)f); } static int -- John Baldwin This doesn't work any more. This time i get niobe# fdformat fd0 Format 1440K floppy `/dev/fd0'? (y/n): y Processing done. where only the first E takes some time to be printed, and all subsequent ones are printed instantaneously, that is all other formatting is not tried. In principle the formatting process must try each of the sectors in turn, and can come up with a series of V and F. Moreover, trying to write to the floppy: niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror dd: /dev/fd0: Input/output error 5+0 records in 4+0 records out 2048 bytes transferred in 4.054404 secs (505 bytes/sec) I don't expect such result. Traditionnally writing works, while reading may fail. Here reading fails with incoherent messages: dd: /dev/fd0: Device not configured 3+0 records in 3+0 records out 1536 bytes transferred in 2.595216 secs (592 bytes/sec) repeated a large number of times. But nothing in dmesg, contrary to the tradition which showed the defective sectors. In conclusion i am under the impression that the in kernel driver is severely botched. Of course nobody uses floppies any more, but this is quite ugly. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: floppy disk controller broken
On Thu, Sep 18, 2008 at 06:18:45PM +0200, Oliver Fromme wrote: Michel Talon wrote: John Baldwin wrote: It looks like the ioctl to format a track used to never report failures from the controller. The newer driver does. What I've done with fdformat is to make it just ignore the errors in userland instead. Try this: Index: fdformat.c === --- fdformat.c(revision 183112) +++ fdformat.c(working copy) @@ -75,8 +75,7 @@ f.fd_formb_secno(i) = il[i+1]; f.fd_formb_secsize(i) = secsize; } - if(ioctl(fd, FD_FORM, (caddr_t)f) 0) - err(EX_OSERR, ioctl(FD_FORM)); + (void)ioctl(fd, FD_FORM, (caddr_t)f); } static int This doesn't work any more. This time i get niobe# fdformat fd0 Format 1440K floppy `/dev/fd0'? (y/n): y Processing done. where only the first E takes some time to be printed, and all subsequent ones are printed instantaneously, that is all other formatting is not tried. In principle the formatting process must try each of the sectors in turn, and can come up with a series of V and F. Moreover, trying to write to the floppy: niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror dd: /dev/fd0: Input/output error 5+0 records in 4+0 records out 2048 bytes transferred in 4.054404 secs (505 bytes/sec) I don't expect such result. Traditionnally writing works, while reading may fail. Maybe I misunderstand what you're saying, but ... When I try to write to a floppy that has *not* been successfully formatted, I very much expect to get Input/output error. Anything else would be a bug. Best regards Oliver The floppy has certainly be formatted, in the past. Perhaps i remember badly, i have not used floppies since years, but in this case the behavior with Windows, Linux and ancient FreeBSD was that you could write to the floppy, but could encounter errors while reading. Using dd conv=noerror allowed to recover the valid part. Under Windows you could very well use floppies partly damaged with bad blocks or tracks. Here the driver seems to bail out at the first error, so that the above commands run much faster than they should, a few seconds, while something of the order of a minute should be more realistic. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
floppy disk controller broken
Hello, when testing FreeBSD-7.1-BETA i discovered that the floppy disk controller doesn't work correctly. Trying to format a floppy (perhaps with bad blocks) i get: Processing fdformat: ioctl(FD_FORM): Device not configured instead of the normal E letter. I then checked the same problem is present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in 2006! Of course the floppy disk driver is particularly messy, but this is not pretty. (*) i386/103862: Error with fdformat -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: radeon and FreeBSD freeze
Boris Samorodov wrote: The most convenient way to freeze the OS is to finish gnome session. When gdm is reloading the whole mashine freezes at gnome greeter. The mouse cursor freezes while being a clock-buzzer. Ctrl-alt-del doesn't help, only reset does. Does disabling DRI in xorg.conf fixes the problem ? Didn't try, but may do if it may help. This is a well known problem, with radeon cards on machines with Via chipsets. The freeze occurs under FreeBSD, Linux and even Windows, most easily with DRI but sometimes without DRI. The only solution i have found is to exchange the video card on the machine with a Via chipset to an nVidia card, and put the Radeon on a machine with an Intel chipset. Now i have zero problem, including with DRI. The radeon card now drives a beautiful 1920x1200 screen without any problem, and gives a very good display quality. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Andy Kosela wrote: ... a really beutiful and elaborate post on the subject ... However, being an ordinary user with few machines running FreeBSD, i have seen on my limited sample that 2 machines worked better with 6.3 than 6.2 (two old Athlon machines, which work perfectly OK in fact) and one worked much worse (a P4 which used to be perfectly stable and suddenly panicked 3 times in a week). So i upgraded this last one to 7.0 and it is now working perfectly well without any trouble. The only gotcha is the slowness of X problem when compiling, but i live with that. Moral of the story: the developer base of FreeBSD is not large enough to maintain a large number of releases. In my humble opinion, having 8.0 7.0 and 6.* is even too much. The developers are working on 8.0, they still have a very good grasp of 7.0 but 6.* becomes old stuff, more or less forgotten. It then occurs that things are merged to the 6.* branch which are perhaps susceptible of destabilising it. Personnally i have seen the same occurring with 6.0, 5.0 and 4.*, for me the last releases of the 4.* were very poor on my laptop while the early 4.* releases were perfectly OK. I think it is very unreasonable for end users to ask maintaining, e.g. 6.2 ad vitam eternam. The real stable branch is now 7.* and diverting effort to polish the 6.* is a waste of time. People wanting a very stable system should simply use something else, like Debian stable, official RedHat, etc. whose aim is precisely to offer the maximum stability, with only security and bug fixes, and for extended periods of time. The price you pay is obsoleted and unsexy systems, which is probably OK for the intended use. On the other hand i have no business running such a system. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Mon, Jun 09, 2008 at 06:55:06AM +1000, Peter Jeremy wrote: On 2008-Jun-08 17:49:20 +0200, Michel Talon [EMAIL PROTECTED] wrote: and it is now working perfectly well without any trouble. The only gotcha is the slowness of X problem when compiling, but i live with that. Have you tried SCHED_ULE? In my experience, it does a better job of scdeduling than SCHED_4BSD, even on UP machines (YMMV). Yes, i run with SCHED_ULE, the machine is less interactive than with 6.2 when compiling, but, as i said, i don't care much about that. What i really don't like is panicking, and with 7.0 my machine is perfectly stable. On the other hand, many tasks run very fast under 7.0, so, overall i am very happy with this version. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System hangs when /var partition full (vnode_pager_putpages errors)
Maks Verver wrote: I recently encountered an error, where executing the ImageMagick convert tool as an unpriviliged user caused the system to hang. The error is similar to one reported in 2004: I had exactly the same problem recently under FreeBSD-6.3. I don't know if the problem was related to /var full since i was under X and the machine was completely frozen. It responded to ping and nothing else. The only solution was to press the reset button, and i had to do manual fsck after that because the machine panicked doing the background fsck. Very nasty bug (hence i did not investigate it further ...). -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: recovery FreeBSD
mahdieh Saeed wrote: I removed one directory with rm -r .Is there any way to restore information Se port sysutils/magicrescue -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsdlabel blues again
Volker said: As I've done this procedure twice yesterday and once more today, I've double and triple checked everything but I'm running into one single problem: partition c extends past end of unit and doesn't start at 0. I think you should run bsdlabel on the mirror, not on the raw partitions or disks. Then you will have no more problem of the above type, only the innocuous following one: gms1 is a mirror of ad0s1 and ad4s1: asmodee% bsdlabel mirror/gms1 # /dev/mirror/gms1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524272 164.2BSD 2048 16384 32768 b: 2097152 524288 swap c: 327669920unused0 0 # raw part, d: 524288 26214404.2BSD 2048 16384 32776 e: 524288 31457284.2BSD 2048 16384 32776 f: 29096970 36700164.2BSD 2048 16384 28552 asmodee% bsdlabel ad0s1 # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524272 164.2BSD 2048 16384 32768 b: 2097152 524288 swap c: 327669920unused0 0 # raw part, d: 524288 26214404.2BSD 2048 16384 32776 e: 524288 31457284.2BSD 2048 16384 32776 f: 29096970 36700164.2BSD 2048 16384 28552 bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities asmodee% bsdlabel ad4s1 # /dev/ad4s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 524272 164.2BSD 2048 16384 32768 b: 2097152 524288 swap c: 327669920unused0 0 # raw part, d: 524288 26214404.2BSD 2048 16384 32776 e: 524288 31457284.2BSD 2048 16384 32776 f: 29096970 36700164.2BSD 2048 16384 28552 bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities I think the difference is the last sector of the partition on which geom writes its configuration. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with the installer sysinstall.
Hello, today i have installed FreeBSD-6.2 BETA2 amd-64 on a Core 2 Duo machine with an ASUS P5LD2-VM mobo. I have encountered the following bug from the installer: it wrote an fstab file with all the disk entries on ad4, while the disk is on ad8. Hence when i rebooted, after install, root filesystem could not be found. I had to fiddle at the prompt to get the machine to boot, and then hand edit /etc/fstab. Obviously this would have been a showstopper for a newbie. By the way another minor problem is that the audio does not work. According to the mobo manual, it is a Realtek ALC882 audio chip. None of the sound modules have recognized the chip. Sound works under Linux. All in one this has been a wonderful experience, except for sound FreeBSD amd-64 works perfectly on the machine, i had no problem with the em chip, and the machine is incredibly fast. I have also booted the last FREESBIE cdrom, the integrated Intel video works no problem with the i810 driver. Even glxgears is not totally ridiculous, it's around 1000. The 2D performance is perfectly crisp and fine. I am joining the dmesg for reference. -- Michel TALON Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-BETA2 #0: Mon Oct 2 03:47:17 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP ACPI APIC Table: A M I OEMAPIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz (2659.96-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6f6 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,b9,CX16,b14,b15 AMD Features=0x2800SYSCALL,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 2138701824 (2039 MB) avail memory = 2053550080 (1958 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: A M I OEMRSDT on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 acpi_throttle1: ACPI CPU Throttling on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: display, VGA at device 2.0 (no driver attached) pci0: multimedia at device 27.0 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci3: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 17 at device 28.1 on pci0 pci2: ACPI PCI bus on pcib2 em0: Intel(R) PRO/1000 Network Connection Version - 6.1.4 port 0xd800-0xd81f mem 0xcffe-0xcfff irq 17 at device 0.0 on pci2 em0: Ethernet address: 00:17:31:55:9d:99 em0: [FAST] uhci0: UHCI (generic) USB controller port 0x8000-0x801f irq 20 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0x8400-0x841f irq 17 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: UHCI (generic) USB controller port 0x8800-0x881f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: UHCI (generic) USB controller on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: UHCI (generic) USB controller port 0x9000-0x901f irq 19 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: UHCI (generic) USB controller on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801GB/R (ICH7) USB 2.0 controller mem 0xcfdffc00-0xcfdf irq 20 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801GB/R (ICH7) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr
Re: Gmirror performanc
Oliver Fromme [EMAIL PROTECTED] wrote: I tried with -b split -s various sizes, -b round-robin, -b load. (dd-ing as done with a bs of 1m; I see the transaction size is 128Kb, unless the split method is used, in which case the transaction size gies down. When round-robin is used, the transaction size is 128Kb/s, but the number of transaction per second goes down.). I cannot explain why I should not get a higher read speed. Anyone? dd is a sequential, single-threaded operation, so it will only use one disk at a time. It's not really suitable as a benchmark for real-world things. I see the same problem as Guido, that is gmirror on two disks is not faster that each disk separately and is even markedly slower. I disagree with your explanation, which moreover contradicts the definition of split, round-robin, etc. in the man page of gmirror. Experimentally, observing the disk throughput via iostat shows that both disks are involved in the IO. asmodee# dd if=/dev/mirror/gms1a of=/dev/null bs=256k 556+0 records in 556+0 records out 145752064 bytes transferred in 8.785839 secs (16589431 bytes/sec) (note the low throughput, the disks are individually able to do more than 20 MB/s, this is on an old machine), while iostat shows: asmodee% iostat -w 1 tty ad0 ad4 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 60 61.38 116 6.95 61.40 117 7.01 0 0 1 0 99 0 60 64.00 129 8.06 64.00 128 7.99 0 0 2 1 97 0 60 64.00 128 7.99 64.00 129 8.06 0 0 2 1 97 0 60 64.00 129 8.06 64.00 129 8.06 0 0 1 1 98 0 60 63.50 128 7.93 63.50 127 7.87 0 0 5 2 94 that is the transaction is evenly distributed on both disks ad0 and ad4 (which are on 2 separate channels). The problem is that each disk works at only 8MB/s while it is able of 3 times more. Looking at the kernel driver /usr/src/sys/geom/mirror/g_mirror.c, it seems that the load is split on the various disks in the function g_mirror_request_split() in a way which is simulatneous for all providers. How is it that after that the request proceeds so slowly, i don't know. But i doubt very much it will be any different wether you have a real world load or a simple dd. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
So it may be relevant to say that i have kernels without IPV6 support. Recall that i have absolutely no problem with the client in FreeBSD-6.1. Tomorrow i will test one of the 6.1 machines as a NFS server and the other as a client, and will make you know if i see something. Well, i have checked between 2 FreeBSD-6.1-RELEASE machines on the network, both have fxp ethernet driver running at 100 Mb/s, one is NFS server other NFS client. Both run lockd and statd. I have absolutely no problem exchanging files, for example if i begin to copy /usr/src through NFS from one machine to the other, which makes a lot of transactions of all sorts, i get: niobe# mount asmodee:/usr/src /mnt cp -R /mnt/src . ... after some time i interrupt the transfer niobe% du -sh . 131M. and during this time i observe the following type of statistics asmodee% netstat -w 1 -I fxp0 input (fxp0) output packets errs bytespackets errs bytes colls 542 0 84116 1330 01219388 0 515 0 72806 1290 01196330 0 501 0 95722 1081 0 741048 0 539 0 90704 1090 01228052 0 645 0 67888902 01451098 0 405 0 81264 1609 0 604278 0 503 0 74218709 0 924422 0 500 0 98904973 0 619350 0 550 0 100122855 0 836328 0 615 0 79336 1081 0 862772 0 577 0 82862901 01005024 0 which looks decent to me. Doing the same with just one big file no problem either, and i get a transfer speed of 6.60 MB/s which is perhaps a little less than with linux, but nothing catastrophic. I get 8.20 MB/s for FreeBSD client interacting with the Linux server. Now netstat gives packets errs bytespackets errs bytes colls 785 0 123266 4716 06825600 0 759 0 139898 4530 07747276 0 852 0 124652 5106 06902566 0 863 0 128040 5170 07081738 0 811 0 123760 4862 06851498 0 789 0 123540 4720 06834310 0 840 0 115378 5024 06382114 0 So up to what i can see NFS works OK for me on FreeBSD-6.1. So the main difference with other people cases may be that i have removed IPV6 support from kernel. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
with the bge driver ... could we be possibly talking internet vs nfs issues? Pursuing invetigations, i have discovered that for people having workstations whose home directories are on a NFS server, and who run Gnome or KDE, there is a program which has horrible NFS behavior, it is gam_server from gamin, which detects alterations on your .kde for example. On my machine running nfsstat -c -w 1 i see 4000 requests/s due to that. If i displace it (*) and kill it, this drops to 80 requests/s and KDE works exactly as well, including discovering new files. I think it is not necessary to comment on the performance penalty if a number of stations send 4000r/s to a server, it will soon be killed. (*) it restarts itself automatically so it is necessary to displace or rename it before killing. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
Using Ubuntu as the server I connected a FreeBSD 5.4 and 6-stable box as clients on a 100Mb/s network. The time trial used a dummy 100Meg file transfered from the server to the client. I have similar experiences here. With FreeBSD-6.1 as client (using an Intel etherexpress card at 100 Mb/s) and FC5 server i see full wire speed for file transfers via NFS. After the 4th of July I intend to test Ubuntu as a client to a FreeBSD 6-STABLE server on a gigabit lan to run similar time trials. I'm looking to confirm what I can only suspect at this point, which is that the NFS server on FreeBSD is mucked up, but the client is okay. I have the same impression. The 6.1-RELEASE client seems to work well. Yesterday i have upgraded my 6.0 (*) box to 6.1 and i have not seen a single NFS problem after that. Moreover i am using rpc.statd, and rpc.lockd and they work OK and are really functional. I have the following sysctl which may have an effect on the problem: vfs.nfs.access_cache_timeout=5 So it may well be that it is the FreeBSD NFS server code which has problems. (*) 6.0-RELEASE client definitively does not work OK for me. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
BTW, I noticed yesterday that that IPv6 support committ to rpc.lockd was never backed out. An immediate question for people experiencing new rpc.lockd problems with 6.x should be whether or not backing out that change helps. So it may be relevant to say that i have kernels without IPV6 support. Recall that i have absolutely no problem with the client in FreeBSD-6.1. Tomorrow i will test one of the 6.1 machines as a NFS server and the other as a client, and will make you know if i see something. As to the problems you mention about NFS Linux, yes i have seen a lot since years. But to my surprise FC5 seems to work well. By the way it is kernel 2.6.16 so sufficiently recent for the problems to have been ironed out, presumably. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
So it would appear that you cured the NFS problems inherent with FBSD-6 by replacing FBSD with Fedora Linux. Nice to know that NFSd works in Linux. But won't help those on the FBSD list fix their FBSD-6 boxen. :/ First NFS is designed to make machines of different OSs interact properly. If a FreeBSD server interacts properly with a FreeBSD client, but not other clients, you cannot say that the situation is fine. Second i am not the one to chose the NFS server, there are people working in social groups, in the real world. And third, the most important, the OP message seemed to imply that the FreeBSD-6 NFS client was at fault, i pointed out that in my experience my FreeBSD-6.1 client works OK, while the 6.0 doesn't, when interacting with a FC5 server. This is in itself a relevant piece of information for the problem at hand. It may be that the server side is at fault, or some complex interaction between client and server. Anyways some people claimed here that they had no problem with FreeBSD-5 clients and servers. My experience is that i had constant problems between FreeBSD-5 clients and Fedora Core 3 servers. I cannot provide any other data point. I am not particularly sure of the quality of the FC3 or FC5 NFS server implementation, except that the ~ 100 workstations running the similar Fedora distribution work like a charm with their homes NFS mounted on the server. On the other hand a Debian client machine also has severe NFS problems. My only conclusion is that these NFS stories are very tricky. The only moment everything worked fine was when we were running Solaris on the server. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
the one thing that sticks out to me about this report is that they upgraded teh NFS server to FC5 ... what was the server running before? if FreeBSD, could the problem be an interaction problem between the NFS server and client, vs just the client side? Previously the server used Fedora Core 3. I think like you that it is an interaction between client and server. For example we have a client machine running Debian Unstable which had NFS problems interacting FC3 server and still has with FC5 server. But i don't have any more with Fbsd-6.1. As to the problem of the machine freezing when the server freezes i have always seen that, both under Linux and FreeBSD, nothing new. The freeze seems to me less severe now, that is i have been able to log in root with the server down. The load on the server is rather big, we are talking around 100 machines having their home directories on the server. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
I only started to see the lockd problems when upgrading the server side to FreeBSD 6.x and later. I had various FreeBSD clients, between 4.x and 7-current and the lockd problem only showed up when upgrading the server from 5.x to 6.x. As far as i remember FreeBSD-4 did not have a true lockd, only a fake one, so it was always working no problem. I have used all versions of FreeBSD-5 up to 6.0 and 6.1 on my client with a Linux server, and i can say that 6.1 is the first one which works OK for me. I don't have any experience with FreeBSD server, except the occasional nfs mounting after a make world. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS Locking Issue
Based on prior reading about this problem, I'd venture to guess that the file locking between FC5 and FreeBSD simply isn't. See, between just 2 machines sharing files without rpc.lockd running you won't see a problem. Both the client and the server must not only be running rpc.lockd, but they must be able to actually talk to each other. I definitely disagree with that. I have written a little program just to check locking on files on the NFS share, and i can assure you it works. Before FC5 the same program did not work, in fact hanged. You could not kill the program, without unmounting the NFS share. After the upgrade FC3 - FC5 the lockd works and if i try setting a second lock on the same file it will fail. I am using this daily with mutt, no problem. But it is not only lockd which now works, it is more generally NFS. On a 6.0 machine i regularly get things like: Jun 22 17:30:10 asmodee kernel: for server ada:/ada1 Jun 22 17:30:10 asmodee kernel: nfs send error 1 for server ada:/ada1 Jun 22 17:30:10 asmodee last message repeated 797 times Jun 22 17:30:15 asmodee kernel: for server ada:/ada Jun 22 17:30:15 asmodee kernel: nfs send error 1 for server ada:/ada Jun 22 17:30:15 asmodee last message repeated 817 times Jun 22 17:30:20 asmodee kernel: nfs send error 35 for server ada:/ada and the home directories are inaccessible for a couple of minutes. I have never seen that once on the 6.1 machine. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
NFS Locking Issue
I guess I'm still just a bit stunned that a bug this obvious not only found it's way into the STABLE branch, but is still there. Maybe it's not as obvious as I think, or not many folks are using it? All I know for sure here is that if I had upgraded to 6.1 my network would have been crippled. Strange, since i upgraded to FreeBSD-6.1 and the NFS server to Fedora Core 5, my machine, NFS client is happy, and lockd works. It is first time since years i have no problem. It certainly did not work with FreeBSD-5 and i still have a machine with FreeBSD-6.0 which does not work properly (frequently loses the NFS mount, but it gets remounted some times later by amd). Anyways i have exactly 0 problem with the 6.1 machine. I could extend that to say that everything works very well on that machine, nothing is slow, including disk access. This has not always been the case. Stability wise, i have not seen any panic, hang or whatever since i have compiled a kernel adapted to my hardware. I got a panic with the generic kernel soon after installation, but now machine is totally stable. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Security Survey
ports tree in the process, the end result is a bit more undefined. One thing that I wish for is that the ports tree would branch for releases, and that those branches would get security updates. I know that this would involve an exponentially larger amount of effort from the ports team, and I don't fault them for not doing it. Still, it would be nice to have. Yes, totally agree. That's the way OpenBSD ports tree works and it worked very well for me. Thus not to say FreeBSD's one didn't, but it takes a lot more attention, which isn't always a bad thing ;) OpenBSD doesn't have next to 15000 ports. In my opinion, this richness is one of the main assets of FreeBSD, and by necessity implies a great difficulty to maintain everything in a coherent and secure state. You have only to contemplate the years it took to release Debian Sarge to convince yourself. Personnally i am quite pleased with the present state of the FreeBSD ports, i think it is in a much better state than a couple of years before, and for my own use, security is a very secondary issue. People who have machines exposed on the internet usually have a small number of ports installed, and can maintain them in the latest secure version. I have around 600 ports installed on my 6.1 machine, which will certainly grow in time, and no intention whatsoever to run portupgrade on that. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble with NFSd under 6.1-Stable, any ideas?
Are you running rpc.lockd? I've had very bad luck with it since sometime in the 5.x series... especially with it interoperating with Solaris. I submitted a PR on it, but it's apparently broken in about X ways. If possible, I would suggest living without rpc.lockd for now (if you're currently living with it that is) On the contrary NFS problems interoperating with Linux have been cleared for me since upgrading Linux to Fedora Core 5 and FreeBSD to 6.1. In particular rpc.lockd works, everything is OK, performance is fine. I had very bad problems in the past, when we were running Fedora Core 3. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Crash with 6.1
I have installed FreeBSD-6.1 from cdrom yesterday on my machine a P4 with hyperthreading. It crashed some hours later when i was accessing the packages cdrom, specifically doing cd /cdrom/paTab This is with the installed kernel, no modification whatsoever. I don't have the corresponding debugging kernel, so all i have is: niobe# kgdb /boot/kernel/kernel /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. (no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer. (kgdb) bt #0 0xc0650272 in doadump () #1 0xc06507c9 in boot () #2 0xc0650af1 in panic () #3 0xc084a2cc in trap_fatal () #4 0xc084a00b in trap_pfault () #5 0xc0849c45 in trap () #6 0xc0836c4a in calltrap () #7 0xc061681e in g_io_request () #8 0xc0618de9 in g_vfs_strategy () #9 0xc0620dc9 in cd9660_strategy () #10 0xc085c229 in VOP_STRATEGY_APV () #11 0xc069c5b0 in bufstrategy () #12 0xc0696e19 in breadn () #13 0xc0696d5c in bread () #14 0xc061d6d5 in cd9660_blkatoff () #15 0xc06208a2 in cd9660_readdir () #16 0xc085bf34 in VOP_READDIR_APV () #17 0xc06b26a3 in getdirentries () #18 0xc084a613 in syscall () #19 0xc0836c9f in Xint0x80_syscall () #20 0x0033 in ?? () I don't suspect a hardware problem since this machine has run FreeBSD-5.3 and 5.4 previously without trouble, there is no overheating, etc. As for the cdrom, after reboot i have installed the whole KDE plus a lot of other things from it without problem. Previous frame inner to this frame (corrupt stack?) (kgdb) quit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
moused coredumps after suspend-resume
Hello, i have found a little annoyance with FreeBSD-6.0. I have tested suspend-resume on a Thinkpad T40, it works OK which is nice, but kills moused which coredumps. Strange, i have an old laptop using apm instead of acpi where moused survives suspend-resume. PS. It is an usb mouse, so i have kldload ums, moused -p /dev/ums0 before doing acpicontrol -s 3 -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.0-RC1 and qemu
Hello, i observe a regression running 6.0-RC1 under qemu, compared to 6.0-BETA5. Now the ethernet card driver doesn't attach, i get ed0: RealTek 8029 port 0xc100-0xc1FF irq 11 at device 3.0 on pci0 ed0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc100 device_attach: ed0 attach returned 6 Under BETA5 the network was fully functional. -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Upgrade to FreeBSD 4.3-RC
Hello, I have upgraded today from some 4.2-STABLE to 4.3-RC. I have encountered the following problems: - First, trying reboot single user with the new kernel and modules (i had some modules loaded by /boot/loader.conf, namely vesa ipf splash and a splash bitmap) but old /boot/loader had problems. I could not type -s at the OK prompt. Only garbage appeared on the screen. I had to boot directly from the bootblocks to complete the installation. So the keyboard seems to have been completely messed up. After make installworld there is no more problem using the keyboard at the loader prompt. - Second i had disabled sound in the kernel config file since it is now a module. However trying to cat something to /dev/audio or dsp or using mixer said device not configured. I have a Vibra16 and have tried kldloads of snd_pcm and snd_sbc in each order without any effect. I have recompiled a kernel with device sbc and device pcm, now everything is OK. From the dmesg it appears that module sbc yielded proper recognition of the sound card, but module pcm never attached to sbc. In other words the line pcm0: SB16 DSP 4.16 (ViBRA16X) on sbc0 never appeared, but the line sbc0: Creative ViBRA16X at port 0x220-0x22f,0...irq 5 drq 1,3 on isa0 was here. At least the first problem may be very embarassing for people. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ssh problem upgrading to 4.2-stable
On Wed, Jan 31, 2001 at 11:41:14AM +, Pete French wrote: So, yesterday we upgraded the last machine running 3.5 here to 4.2 stable (CVSuped on saturday I believe). All went very smoothly and everything runs fine except for ssh. We are using openssh, and it rejects peoples passwords with "Permission denied, please try again." I seem to recall reading that password encryptionc hanged from MD5 to DES between 3.x and 4.x - and I suspect this could be the problem. The /usr/lib/libcrypt.so file is a link to libdescrypt.so, so I assume we are now using DES passwords. Old users have MD5 passwords, but new users are created with DES passwords. Using 'passwd' however converts them to MD5. I have checked auth.conf, mailing list archives and done a web search and am running out of ideas. There is an issue with /etc/pam.conf. You can overwrite it with the one under /usr/src. This worked for me. Also there is another pithole (i fell into): sshd dies because there is an obsolete option in /etc/ssh/sshd_config, that you need to remove. ConnectionsPerPeriod 5/10 Am I barking up the wrong tree entirely here ? -pete. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: odd mouse button behavior
On Thu, Jan 18, 2001 at 02:23:30PM +0100, Jimmy Olgeni wrote: Latest discovery: the mouse will work fine if you choose "/dev/pms0" and "auto" as mouse device and protocol type. But you have to kill "moused". Looks like XFree-4 does not like moused for some reason... -- Sure not true. I have several FreeBSD installs (including laptop with touchpad) using XFree 4.02 and moused. You need to declare /dev/sysmouse for the device, and auto for the protocol. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: My xterm has broken :(
On Mon, Jan 15, 2001 at 07:11:24PM +, Catch-all m-box wrote: Hi, Can anyone help with this one? I have STABLE from this afternoon, but have also upgraded to XFree86 4 It seems to be okay, except when I try to get an xterm, I get nothing! This is the log message generated: /usr/libexec/ld-elf.so.1: Undefined symbol "_XA_UTF8_STRING" referenced from COP Y relocation in xterm I have also seen that on my machine. What i have done: fetched XFree 4.02 from www.xfree86.org make World, make install and all was solved. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Athlon and 4.2 Release
On Mon, Jan 15, 2001 at 08:40:23PM -0600, David Kelly wrote: Derek Tattersall writes: I have a 1 GHz Thunderbird (Athlon) on an ASUS A7V Via KT133 chipset with an IBM ultra 100 30 Gig Hard drive. If I let the HDD be auto detected, 4.2 Release terminates at the point it is going to partition the drive. If I set the HDD for LBA with all the options disabled, it reboots in the middle of the boot sequence, after the "press enter to boot now prompt". I boot my 800 MHz A7V from SCSI. And replaced the MB out from under an installed system. 9G on SCSI, 45G Maxtor on the on-board ATA-100. For this MB to run reliably under load I had to select "BIOS Defaults", and maybe also "System Performance Setting" from "Optimal" to "Normal". Also disabled "PCI Master Read Caching" and "Delayed Transaction". Something in there was causing problems under load. The situation might also surface during installation. Strange because i have here installed FreeBSD 4.2-Stable on an Abit KT7 Raid which has the same chipset, and runs an Athlon 1.1 Ghz. I have loaded all optimal settings in the Bios to enhance speed, and all works beautifully, including UDMA speed for the disk (here a Western Digital). -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Broken kern.flp?
On Tue, Jan 16, 2001 at 06:06:09PM +0900, Makoto MATSUSHITA wrote: I've just got a report that current 4-stable's floppy image, kern.flp is broken and it can't boot. Here is a sample session: *** BTX loader 1.00 BTX version is 1.01 Console: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 637/kB/48128kB available memory FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Mon Jan 15 11:41:27 GMT 2001) /kernel text=0x24113b data=0x2fdac+0x201ec elf_loadexec: cannot seek can't load module '/kernel': input/output error | Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... /kernel text=0x24113b data=0x2fdac+0x201ec elf_loadexec: cannot seek can't load 'kernel' can't load 'kernel.old' I have seen that also trying to install 4.2-Release on my new machine. Fortunately the cdrom booted OK. I thought it was bad floppy, but apparently not. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HDD Problem
On Wed, Dec 27, 2000 at 03:21:33PM -0800, Kent Stewart wrote: "David W. Chapman Jr." wrote: I have a KT7 with an athlon 1.1, no problems with ATA66, don't have a 100 drive though. Works fine, does make worlds in a little over an hour with 384mb of pc133, but I do have to downclock the pc133 to 100 because these via chips have some problem with agp and pc133 at the moment. I'm also running the slow end on the bios memory setting. The wz beta bios is supposed to deal with some memory timing questions. I have downloaded wz but haven't flashed the bios yet. I am running uz, which became w? (their www server is overloaded and can't see what they called the uz when it was released). Abit is also up to KT7a and 686B. I have both Maxtor's (30 GB and 40 GB - ATA100's) set to do only UDMA 33 using Maxtor's udmaupdt.exe program. That didn't help FreeBSD. Windows 2000 didn't have any problems at the UDMA66 setting and just slowed down a little bit at the UDMA33 setting. I have three other systems based on the bx chipset that don't have problems doing UDMA33. I also have an AbitKT7 with a Duron 650 and a Western Digital UDMA66 7200 rpm drive. I have never seen any ata problem on this machine. Yes it runs pc133 memory with the least conservative settings: "turbo" memory, 2 cycles wait etc. This machine also runs Win98 and Linux and has no problem with any of these systems. Make buildworld takes an hour. We have received similar machines at work but with 1.1 Ghz Athlons. Does not make big difference on speed except on very compute intensive things. Apparently most of the time is spent accessing memory or the disks. The only problem this machine had, and only under FreeBSD, is that floppy formatting did not work. Fortunately, since upgrade to 4.2, this is solved. Also the loader dies doing lsdev, but this is apparently due to the presence of a dvdrom. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: MFC? src/sys/i386/conf/GENERIC and sound support
On Thu, Dec 28, 2000 at 03:17:10PM -0800, [EMAIL PROTECTED] wrote: On 28 Dec, Gerald Pfeifer wrote: Having been hit by this today, how about MFCing the following change? revision 1.289 date: 2000/11/14 01:11:13; author: jkh; state: Exp; lines: +4 -1 In the year 2000, I think it's perfectly reasonable to include audio support by default in GENERIC. I can't answer for JKH or others but audio has had a history of problems, especially durning the boot-up probe stage. Problems such that it might lock up the machine under certain conditions. Perhaps this is the reason sound may never make it into GENERIC. And sound has still problems. Example, on my laptop sound has always worked since 3.* But having upgraded to 4.2-RELEASE i get the following: pcm0: Neomagic 256AV (non-ac97) at port 0x220-0x22f,0x530-0x537,0x388-0x38f,0x320-0x321 irq 5 drq 0,1 on isa0 pcm0: play interrupt timeout, channel dead Apparently sound died after suspend and resume, which was not the case previously. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Parallel ZIP patch for better mode detection
On Mon, Dec 18, 2000 at 08:51:32AM +0100, Nicolas Souchu wrote: On Fri, Dec 15, 2000 at 07:45:23PM +0100, flag wrote: On Thu, 14 Dec 2000, Nicolas Souchu wrote: Hi, Here is a patch against -stable /sys/dev/ppbus for better ZIP/ZIP+ mode detection. I've tested ZIP, but don't have any ZIP+ :( Could some of you approve vpo and imm drivers for me? Can I gain any speed-boost installing this patch? The big problem with the parallel zip is that, while you are transferring data from/to the zip, the copy process get the 100% of the cpu and the system stay unusable until the end of the zip operation...very sad...=( That's normal. The ZIP is designed so that it can run only in polling mode :( You should get better speed and reactivness of your machine if you use EPP mode (which is polled also but faster). Nicholas Yes, but i have two machines on which running the parallel port in EPP mode and using vpo works but is incredibly slow. Moreover the machine is essentially unusable during the transfers with the zip. One of these machines duals boot Linux, and here the zip works very well, almost at the same speed that a scsi zip that i have on a third machine. During the transfers the machine keeps its responsiveness. So i conclude that the driver has its responsibility in this affair :) To be precise the port is probed as EPP1.9 in both cases. I have looked at the vpio.c file and it seems that EPP1.9 is not used in the best possible way. On the other hand i have also looked at the Linux driver, and have not seen big difference in the way the transfer is done. So i have not been able to improve anything. I take advantage of the presence of the developer in the mailing list to attract its attention to this question. To me, the behaviour of the Zip on FreeBSD is by far the worst bad point of FreeBSD with respect to Linux. I have seen many messages from people with laptops in which only ECP mode is available, and for them the // port Zip does not work at all. But in many cases // port Zip is the only practical way to transfer files from home machines to office machines and so on. It should not be neglected. Best regards -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /dev and //port
On Mon, Dec 11, 2000 at 04:24:20AM -0500, [EMAIL PROTECTED] wrote: Hi, All: After completely installing 4.2-stable-20001208, I re-built a custom kernel in order to use parallel port zip drive; however, it just hang when I try to use /dev as instructed in There is no need to rebuild anything to use // port Zip drive. Just kldload vpo (assuming you have plugged the zip and powered it--check with dmesg that it has been probed) After that you mount it. For example if it is dos formatted in slice 4 (the standard way) mount -t msdos /dev/da0s4 /mnt -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: wierd printout from dmesg
If y understand, there is a window where you have new userland and old kernel. I have experienced big problems (even panics) with these mixings in the transition 4.1 - 4.2 It seeems that things have changed so much that userland utilities can even panic mismatched kernels. Reboot single user, with the new kernel, mount -a, and make installworld and reboot. Then all problems where fixed in the two upgrades i have done, moreover some bugs i had with 4.1 are fixed now. -- Michel TALON To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
4.2 panicing
Mike Thanks for your answer. It was indeed mountd which paniced the machine. I have taken the risk of doing make installworld and all seems to go fine, including sound (SB16). The machine even seems to go faster (an illusion?) -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Linux emulation
On Sat, Nov 04, 2000 at 01:22:59AM -0800, David O'Brien wrote: On Fri, Nov 03, 2000 at 03:39:57PM +0100, Michel Talon wrote: I have encountered today some fairly critical bugs in the Linux emulation. This is on a 4.1-RELEASE box, i mention these problems in case they have not been seen or corrected before 4.2-RELEASE If at all possible, it would be great if you could test 4.2-BETA from this point forward (but before release time). We done a lot of reorganization of the linux compatibility bits. On my test box StarOffice 5.2 runs fine. I will try to check that, but i am leaving to Japan next Friday, and it's a home machine, so i have to burn a cdrom, and do that before leaving! Thanks for your attention -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Busted -STABLE
There is a recent fix to the brooktree driver. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Busted -STABLE
On Fri, Oct 27, 2000 at 01:18:37PM +0100, Bap wrote: Where? There is a recent fix to the brooktree driver. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message I have seen that on the freebsd-stable list this morning, i think. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinux hardware
On Fri, Oct 27, 2000 at 09:44:28AM -0500, Thomas T. Veldhouse wrote: I am also seeing BTX failures, but only from manual commands. The lsdev command will cause BTX to fail (and halt) when it scans my CDROM/DVD. I am using 4.1.1-RELEASE. I have a ABIT KA7-100 board (which uses the VIA686A chipset for IDE access). I recognize my exact problem. I have a Abit KT7 with a dvdrom, and lsdev crashes the loader. I had not related this to the DVD however. In any case FreeBSD is loded perfectly fine from the DVD as well as the hard disk. Only lsdev crashes the loader. By the way, i always have this annoying problem that the same machine is unable to format floppies under freebsd, while it formats them fine under Linux and Windows. I have been told that other have the same problem on various machines, while one guy with the same mobo said me he does not have it. Also i have seen comments in the CVS tree at ata.c about the ata driver stealing an ioport of the floppy drive. Does somebody know the present status of the question, and if it is valuable to upgrade (i run 4.1, it is at home so upgrades are painful)? -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Via KT133 chipset and DMA diskaccess
On Tue, Oct 17, 2000 at 01:25:03PM +, Marc Albers wrote: I'm have not been able to get DMA disk access to work ( DMA33 or DMA66 ) on my new Abit KT7. I have heard of several people having it working perfectly on their KA133 based motherboards. Therefore I am curious: Is there anyone who has this working on an VIA KT133 based motherboard? If so, can this person assist me in taming my beast? It worked for me since the installation without me doing any thing (except enable UDMA in the BIOS). Of course on the same board Abit KT7, disk is a Wester Digital 20 Gigs 7200 rpm. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Space
On Thu, Sep 28, 2000 at 03:11:19PM -0700, Tom wrote: On Thu, 28 Sep 2000, Jared Chenkin wrote: I'm having some space problems on my FreeBSD 3.3-STABLE box. The problem is that the previous administrator did not give me alot of space on the root partition, and now its at 95% and pwd_mkdb(8) and its frontends complain about lack of space (duh!) I've looked through the stuff on the fliesystem, and I was wondering if there is anything that I can safely move to another filesystem for the time being. I was considering moving /kernel.GENERIC being that I have a customized kernel which works quite well :) Live Large, Jared Chenkin [EMAIL PROTECTED] (AIM: DevNull24) Networked Systems Administrator Bronx Science Computing /tmp and /var are good canadates for their own filesystems, if they aren't that way already. I recently had a space problem even with /var (while i have a 100 Megs /var). This was trying to install klyx with pkg_add. The dependency stuff tried to install TeTex as a dependency (note that i already have TeTex, but an older version) and this immediately filled up /var/tmp. This points once more that partionning / is a bad decision for a lot of people. I have never encountered any problem with a big flat /. On the machine with its own /tmp /var etc. i am continuously bothered with file system fulls. Moreover i am beginning sick with the ports dependencies which are changing each weak so that you need to have 10 copies of tcl tk and so on, or reinstall everything. The TeTex example is particularly ridiculous. Tom Uniserve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: pb with 4.1-STABLE and Compaq Deskpro 4000 floppy
On Fri, Sep 22, 2000 at 02:50:32PM +0200, Claude Buisson wrote: Hi all, I just installed 4.1-STABLE (cvsupped September 15) on a Compaq Deskpro 4000 (5200MMX), and I cannot use the floppy. 1) loading of kernel/mfsroot floppies is OK for install 2) after installation, the floppy cannot be accessed: no io succeed. 3) a fixit floppy cannot be mounted after loading kernel/mfsroot floppies and selecting "fixit". But, 3) may be done using 3.5-STABLE kernel/mfsroot floppies. Compag diag/setup says the fdc uses ports 3f0-3f5 4.1-STABLE says the fdc uses ports 3f0-3f5,3f7 3.5-STABLE says the fdc uses ports 3f0-3f7 Hoping for help, Claude Buisson FRAMATOME I also have a floppy problem with 4.1 Release on my box. Here i can read write on formatted floppies, but fdformat does not work. The floppy drive is good since it works OK under Win and Linux. I have looked at the code for the floppy controller but it's spaghetti code. In particular some delays are implemented through for loops, perhaps the machine is too fast for the drive. Don't know. I have already posted that but have received no feedback. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Which release of 4.1 supports i810 with XFree86 4.0.1?
On Wed, Sep 06, 2000 at 11:33:05PM -0700, Doug White wrote: On Wed, 6 Sep 2000, Alan Bindemann wrote: From: Doug White [EMAIL PROTECTED] Don't expect to get lots of help for this; XFree86 4 is very, very beta and has lots of nasty bugs. [snip] I suggest using 3.3.6 for production use. I was under the impression that the i810 chipset was not supported under 3.3.6. Am I mistaken? If so, do I need to rebuild 3.3.6 with some patches for i810 support? I stay away from such broken hardware. As X 4 is beta, don't expect any help from this list for it. Perhaps X 4 is beta, but X 3 does not work or work poorly on some video cards which are amongst the best on the market (GeForce). So a shift to 4.01 will soon to be considered. Do you think people will only buy Matrox G 400 because it is very well supported by X 3? To speak for my case, i have received mail that GeForce works with X 3 but my own works very poorly, if at all. I am obliged to go to 4.01 and install nVidia drivers under Linux. Corresponding drivers for freebsd are said to be in preparation. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
floppy drive
Hello, I have just discovered a strange problem on my new PC. The mother board is an Abit KT7 hosting a Duron with Via chipset. I can triple boot FreeBSD 4.1-RELEASE (stock GENERIC kernel) Linux and Win98. Problem: under freebsd i cannot run fdformat fd0. Immediately bad crc errors appear, only some sectors come out with V. Of course i have tried with several floppies and two floppy drives, one of them working very well in another machine. Much stranger: with the same floppy and floppy drive and machine, formatting works perfectly OK with Linux and Win98. To add to the bizarre, once i have a good fdformatted floppy (under linux) i can perfectly read and write to it under freebsd. dd if=/dev/fd0 of= /tmp/flopworks and is quite fast. dd if=/tmp/flop of=/dev/fd0 also works. Floppy drives are Sony, and it is the first time i see that on a freebsd machine. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: My System Hangs/Deadlock?
On Sun, Aug 20, 2000 at 11:03:32PM -0700, Billy wrote: I am currently experiencing problems with my FreeBSD system. I just recently go in my dual celeron/abit box in and have just started to use it. I am experiencing a strange problem I've never seen before. Whenever I do some intensive work, my computer will lock up. I still These cards support easy overclocking, no? Perhaps you could check cooling, notably the fans on the processors or even general cooling of the box. I have seen several times machines locking up just like yours, without any message. Each time it was a broken fan. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: shorter boot time?
On Tue, May 16, 2000 at 04:29:00PM -0400, Vivek Khera wrote: "MM" == Mike Muir [EMAIL PROTECTED] writes: MM The small pause for me was for ATA devices. I no longer need them (no MM ide/atapi devices in system) and the boot just flies right past that point. MM The boot time on 4.0 is _significantly_ faster for me. I run 3.4-STABLE and had a long pause detecting the second drive on my second IDE controller. Since that device doesn't exist, I removed it from my kernel and now it doesn't pause looking for it. I have a machine with SCSI disk, but IDE Cdrom, so i cannot remove the ata driver. Well, it pauses for a very long time probing IDE disks. I have not found any way to reduce this delay. Under 3.4, there was no such problem. -- Michel Talon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ARP Problem? Need confirmation...
In reply to the message from Jasper O'Malley On Sat, 3 Jul 1999, Adrian Wontroba wrote: # arp -s 192.168.1.13 auto pub using interface ep0 for proxy with address 0:10:5a:ae:33:86 arp: writing to routing socket: File exists This is on a RELENG_3 box with a make world run on June 30th. This is the second independent confirmation I've gotten for this bug. I've tried to locate the offending code in the source tree, but it's beyond my limited programming abilities, I'm afraid. Anyone have any ideas? Here on my machine running 3.2-STABLE i get the following result: su-2.02# arp -s 134.157.10.68 auto pub using interface xl0 for proxy with address 0:10:5a:3b:ae:3 note however that the ethernet adress here obtained is incorrect since this is my own mac adress and not that of the printer 134.157.10.68 But after all i used auto! After a couple of arp -d the situation is restored to normal. arp -a ariane.lpthe.jussieu.fr (134.157.10.68) at 0:60:b0:bf:49:96 It seems that there is no bug here. -- Michel TALON To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
