Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]]
Harald Schmalzbauer wrote: Some experimental results: When rsyncing with windows, and FreeBSD is receiver, I see the same ACK ever two segemnts, but speed is at 72MB/s. When FreeBSD is sender and Windows is receiver, it looks more I expected. There are about 20 data segments before a ACK is returned. And there are TCP Window Update Segments, reflecting smaller receiver buffers on the windows side. But this happens at a throughput of 82MB/s!!! So the windows machine is behaving like I understand the TCP flow control. Any explanation why the FreeBSD machine seems to ignore window size? IIRC, the delayed ACK RFC requires an ACK at least every second segment. ___ 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: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]]
All those duplicate ACKs look like a problme to me... I would be inclined to capture from the other end or from a monitor port on the switch to make sure those are actually hitting the wire. The only explination I can think of is that the system sending the duplicate ACKs is assuming that it's lost a segment for some reason and is trying to trigger fast recovery early. Stephen Hurd schrieb am 18.02.2010 17:18 (localtime): ... one retransmit per five packets). Is this what you're seeing? If you have a capture you could share covering a few seconds, I could take a look and provide a better opinion. Thanks for your help, here's a small snippet of the iperf session. There are hundreds od duplicate ACKs. I'm not sure how to understand that. Like mentioned, I have to refresh some TCP basics before I can do usefull tests. But perhaps you can confirm that this behaviour is intendend, or where the problem could be... Thanks, -Harry ___ 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
8.0-B4 gstripe / GEOM_PART_* upgrade woes
I've upgraded from 7.2-RELEASE_p2 to 8.0-BETA4 and using GEOM_PART_* with my sliced gstripe array causes the /dev/stripe/raid0a to disappear and the reset of the /dev/stripe/raid0[a-z] file systems to be unmountable. My gvinum array is still working fine and, after chasing the ad* slices, they can be mounted as well. It's just the gstripe slices which are corrupt/missing. When I build without GEOM_PART_* and use GEOM_BSD and GEOM_MBR, it works fine. I've attached an archive with various command outputs which may be helpfull... the 8.0 directory is 8.0 with GEOM_PART_* and 8.0-OLD is using GEOM_BSD and GEOM_MBR. I'll paste the 8.0 ones in here in case attachments are stripped: === dmesg == Copyright (c) 1992-2009 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 8.0-BETA4 #0: Thu Sep 10 17:00:11 PDT 2009 ad...@ace.hurd.local:/tmp/obj/usr/src/sys/ACE Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2394.77-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 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=0x4400CNXT-ID,xTPR real memory = 1342013440 (1279 MB) avail memory = 1299419136 (1239 MB) ACPI APIC Table: IBMSERONYXP FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP/HT): APIC ID: 7 MADT: Forcing active-low polarity and level trigger for SCI ioapic2 Version 1.1 irqs 32-47 on motherboard ioapic1 Version 1.1 irqs 16-31 on motherboard ioapic0 Version 1.1 irqs 0-15 on motherboard kbd1 at kbdmux0 smbios0: System Management BIOS at iomem 0xfdfe0-0xfdffe on motherboard smbios0: Version: 2.3, BCD Revision: 2.3 acpi0: IBM SERONYXP on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 460, 2 (4) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x488-0x48b on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 pcm0: Creative CT5880-C port 0x2200-0x223f irq 16 at device 1.0 on pci0 pcm0: SigmaTel STAC9721/23 AC97 Codec pcm0: [ITHREAD] pcm0: Playback: DAC1,DAC2 / Record: ADC vgapci0: VGA-compatible display port 0x2300-0x23ff mem 0xfd00-0xfdff,0xfebff000-0xfebf irq 26 at device 9.0 on pci0 drm0: Rage XL on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized mach64 2.0.0 20060718 atapci0: ServerWorks CSB5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x700-0x70f at device 15.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] ohci0: OHCI (generic) USB controller mem 0xfebfe000-0xfebfefff irq 11 at device 15.2 on pci0 ohci0: [ITHREAD] usbus0: OHCI (generic) USB controller on ohci0 isab0: PCI-ISA bridge at device 15.3 on pci0 isa0: ISA bus on isab0 pcib1: ACPI Host-PCI bridge on acpi0 pci2: ACPI PCI bus on pcib1 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x1002 mem 0xfbff-0xfbff irq 29 at device 8.0 on pci2 miibus0: MII bus on bge0 brgphy0: BCM5703 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:02:55:07:57:03 bge0: [ITHREAD] pcib2: ACPI Host-PCI bridge on acpi0 pci5: ACPI PCI bus on pcib2 mpt0: LSILogic 1030 Ultra4 Adapter port 0x2400-0x24ff mem 0xf9ff-0xf9ff,0xf9fe-0xf9fe irq 27 at device 7.0 on pci5 mpt0: [ITHREAD] mpt0: MPI Version=1.2.15.0 mpt0: Capabilities: ( RAID-1 SAFTE ) mpt0: 0 Active Volumes (1 Max) mpt0: 0 Hidden Drive Members (6 Max) mpt1: LSILogic 1030 Ultra4 Adapter port 0x2500-0x25ff mem 0xf9fd-0xf9fd,0xf9fc-0xf9fc irq 28 at device 7.1 on pci5 mpt1: [ITHREAD] mpt1: MPI Version=1.2.15.0 mpt1: Capabilities: ( RAID-1 SAFTE ) mpt1: 0 Active Volumes (1 Max) mpt1: 0 Hidden Drive Members (6 Max) pcib3: ACPI Host-PCI bridge on acpi0 pci7: ACPI PCI bus on pcib3 pcib4: ACPI Host-PCI bridge on acpi0 pci9: ACPI PCI bus on pcib4 fdc0: floppy drive controller port 0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: 1440-KB 3.5 drive on fdc0 drive 0 atrtc0: AT realtime clock port 0x70-0x73 irq 8 on acpi0 cpu0: ACPI CPU on acpi0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 p4tcc1: CPU Frequency Thermal Control on cpu1 cpu2: ACPI CPU on acpi0 p4tcc2: CPU Frequency Thermal Control on cpu2 cpu3: ACPI CPU on acpi0 p4tcc3: CPU Frequency Thermal Control on cpu3 pmtimer0 on isa0 orm0: ISA Option ROM at iomem 0xc-0xc7fff pnpid ORM on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA
Re: 8.0-B4 gstripe / GEOM_PART_* upgrade woes
Ivan Voras wrote: An interesting problem. I presume that in either case (gpart or GEOM_BSD/MBR) the output of gstripe status is the same? Only the interpretation of the partition tables is problematic? Yes, but the output of gstripe list is different in the mode lines... for GEOM_PART, the mode is r0w0e0 in all consumers and for GEOM_*, the mode is r3w3e5. What is the expected (good) structure of the partitions/file systems? Do you have a single MBR partition and inside it multiple BSD partitions? What are their partition types? Not sure the correct way to get the info, but the output of fdisk and bsdlabel follow: START of fdisk fdisk /dev/stripe/raid0 *** Working on device /dev/stripe/raid0 *** parameters extracted from in-core disklabel are: cylinders=5219 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=5219 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: UNUSED The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 0, size 5 (24 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 END OF fdisk START OF bsdlabel bsdlabel /dev/stripe/raid0 # /dev/stripe/raid0: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 16777216 164.2BSD 2048 16384 28552 b: 16777216 167772324.2BSD 2048 16384 28552 c: 20964825 8385930unused0 0 # raw part, don't edit d: 50302960 335544484.2BSD 2048 16384 28552 bsdlabel: partition c doesn't start at 0! bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities END OF bsdlabel Now that I look at the bsdlabel output, I vaugely recall that I couldn't get c correct... ___ 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: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Dick Hoogendijk wrote: On Fri, 29 Feb 2008 15:39:11 -0800 Stephen Hurd [EMAIL PROTECTED] wrote: As a workaround, adding the line: hw.ata.ata_dma=0 To /boot/loader.conf will disable DMA and prevent the hangs that are caused by the DMA timeouts. Yeah, but having dma=1 makes the system faster, doesn't it? It would if it worked, yes. But given a choice between fast and broken and slow and working, I find the decision pretty simple. :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade, recommended by 7 release notes, breaks perl
Kris Kennaway wrote: I think something is not quite right in your analysis, because perl does not depend on any external perl modules (it cannot, by definition). I ran into something like this when I was switching from a threaded perl to an unthreaded perl. It wasn't possible to just use a portupgrade to rebuild and reinstall all the packages, I needed to uninstall a large number of them. Basically, every time the port build fell over, I would need to pkg_which the shared object mentioned in the error message, uninstall that package and take note of the name then reinstall them all after everything else worked. I've never encountered this as a result of a version upgrade though. Reproducing the problem is pretty simple... build a threaded perl, then build a bunch of modules that use shared objects, then reconfigure perl to be unthreaded and force upgrade it. The shared objects will fail to load and portupgrade of the modules will fall over. I never reported this as a problem though since it was pretty obvious why it happened and how to fix it. It was my own fault for playing with a threaded perl then wanting to change back. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
last night. It's a MiniITX board, model EN1200. My system can't remain up for more than 10minutes before something locks it up and frequently the screen will output error messages relating to DMA. As a workaround, adding the line: hw.ata.ata_dma=0 To /boot/loader.conf will disable DMA and prevent the hangs that are caused by the DMA timeouts. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
As a workaround, adding the line: hw.ata.ata_dma=0 To /boot/loader.conf will disable DMA and prevent the hangs that are caused by the DMA timeouts. Does that workaround work when the disks are sata? Don't know. I personally would assume so, but I wouldn't be surprised if my assumption was proven wrong either. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
My system has been working reliably with 6.3 for quite some time... when I rebooted into single user mode to do the installworld with the 7.0-RELEASE kernel, the install died about halfway through with READ_DMA TIMEOUT errors. Since I had a mixed system at that point, I set hw.ata.ata_dma=0 in /boot/loader.conf and completed the install. After a good boot to verify everything was working, I flipped hw.ata.ata_dma back and rebooted. The corrupted sync message scared the heck out of me: Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiti Synncgi n(gm adxi sk6s0, svencoodnedss )r efmoari nsiynsgte.m. .pr1o0c ess `syncer' to stop...8 7 8 3 3 3 1 0 0 0 0 done And after the reboot, the READ_DMA timeouts were back. I installed sysutils/smartmontools (output attached in case it's usefull) The only odd think I can think of about my system is an unusually high HZ value (2386) I'm building a kernel now with 1000 to check if that makes a difference. Copyright (c) 1992-2008 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 7.0-RELEASE #1: Tue Feb 26 22:49:13 PST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVER Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (996.85-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x387fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 1207959552 (1152 MB) avail memory = 1172832256 (1118 MB) MPTable: AMI CNB30LE FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 16 ioapic0 Version 1.1 irqs 0-15 on motherboard ioapic1 Version 1.1 irqs 16-31 on motherboard kbd1 at kbdmux0 cpu0 on motherboard cpu1 on motherboard pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 vgapci0: VGA-compatible display port 0xd800-0xd8ff mem 0xfd00-0xfdff,0xfeaff000-0xfeaf irq 22 at device 1.0 on pci0 drm0: Rage XL on vgapci0 info: [drm] Initialized mach64 1.0.0 20020904 fxp0: Intel 82559 Pro/100 Ethernet port 0xd400-0xd43f mem 0xfeafe000-0xfeafefff,0xfe90-0xfe9f irq 20 at device 4.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:e0:81:21:49:7e fxp0: [ITHREAD] fxp1: Intel 82559 Pro/100 Ethernet port 0xd000-0xd03f mem 0xfeafd000-0xfeafdfff,0xfe70-0xfe7f irq 21 at device 5.0 on pci0 miibus1: MII bus on fxp1 inphy1: i82555 10/100 media interface PHY 1 on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:e0:81:21:49:7f fxp1: [ITHREAD] isab0: PCI-ISA bridge port 0x580-0x58f at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: ServerWorks ROSB4 UDMA33 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.1 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] ohci0: OHCI (generic) USB controller mem 0xfeafc000-0xfeafcfff irq 10 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered pcib1: MPTable Host-PCI bridge pcibus 1 on motherboard pci1: PCI bus on pcib1 pcm0: Creative CT5880-C port 0xef00-0xef3f irq 27 at device 2.0 on pci1 pcm0: SigmaTel STAC9721/23 AC97 Codec pcm0: [ITHREAD] pcm0: Playback: DAC1,DAC2 / Record: ADC pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff 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 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model MouseMan+, device ID 0 fdc0: Enhanced floppy controller at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FILTER] fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: Parallel port bus on ppc0 ppbus0: [ITHREAD] lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Jeremy Chadwick wrote: And after the reboot, the READ_DMA timeouts were back. You're not the only one seeing this behaviour. There are too many posts in the past reporting similar. Here's the breakdown: * Some have switched to alternate operating systems (usually Linux) for a short while and seen no sign of DMA timeouts. Booting the 6.3-RELEASE CD seems to make the problem go away... possibly 7.0 stresses the HD more? However: in your case, your disk does look to have problems based on the SMART output you provided. It does not matter how new/old the disk is, by the way. I'll point out the problematic stats. You need to replace the disk ASAP. Yeah, that's pretty much what I figured, the timing (ie: the moment I boot 7.0-RELEASE) is the only bit that seems fishy. This HD has been powered on pretty much continuously for around three years. Given that it's a Maxtor, I'm honestly a bit surprised that it's lasted as well as it has. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 253 253 063Pre-fail Always - 4 This shows you've had 4 reallocated sectors, meaning your disk does in fact have bad blocks. In 90% of the cases out there, bad blocks continue to grow over time, due to whatever reason (I remember reading an article explaining it, but I can't for the life of me find the URL). This is unusual now? I've always known that a small number of bad blocks is normal. Time to readjust my knowledge again? 194 Temperature_Celsius 0x0032 253 253 000Old_age Always - 48 This is excessive, and may be attributing to problems. A hard disk running at 48C is not a good sign. This should really be somewhere between high 20s and mid 30s. Yeah, this is a known problem with this drive... it's been running hot for years. I always figured it was due to the rotational speed increase in commodity drives. Error 2 occurred at disk power-on lifetime: 5171 hours (215 days + 11 hours) When the command that caused the error occurred, the device was in an unknown state. Error 1 occurred at disk power-on lifetime: 5171 hours (215 days + 11 hours) When the command that caused the error occurred, the device was in an unknown state. These are automated SMART log entries confirming the DMA failures. The fact that SMART saw them means that the disk is also aware of said issues. These may have been caused by the reallocated sectors. It's also interesting that the LBAs are different than the ones FreeBSD reported issues with. If that power on lifetime is accurate, that was at least a year ago... but I can't find any documentation as to when the power-on lifetime wraps or what it actually indicates. I'm assuming that it is total power on time since the drive was manufactured. If it's total hours as a 16-bit integer, it shouldn't wrap. Is there a way of getting the current power-on lifetime value that you're aware of? That power on minutes is interesting, but its current value is lower than the value at the error (but higher than the power uptime of the system): 9 Power_On_Minutes0x0032 219 219 000Old_age Always - 1061h+40m Also interesting is that after getting more errors from FreeBSD, I did not get more errors in smartctl. My advice to you is: replace the disk ASAP. This problem will only get worse. Try another hard disk brand too (I don't have anything against Maxtor, but usually its recommended to avoid a brand you have problems with until the next time you have issues, then switch brands, etc. etc...). I'm very fond of Western Digital's SE16, RE, and RE2 series currently. But avoid Fujitsu and Samsung (both have a long track record of having buggy drive firmwares, forcing vendors to make custom workarounds for issues); stick with Seagate, Western Digital, or Maxtor. Yeah, that's my plan... but I wanted to stake out some whining rights in advance so I can do the But you said it was a bad HD or cable! Now I'm out $x00 and my system still doesn't work! Help me or I switch to DragonFly BSD/Desktop BSD/Linux which is perfect and has no problems! thing. Then go on Slashdot and post long rambling messages about how FreeBSD is dead and it doesn't matter than the manpages on any given Linux box are useless. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Scott Long wrote: I'm betting that it's a driver problem and not a hardware problem, though you should probably think about migrating your data off to a new drive sometime soon. Yeah, ordered a replacement drive today. I'd like to attack these driver problems. What I need is to spend a couple of days with an affected system that can reliably reproduce the problem, instrumenting and testing the driver. I have a number of theories about what might be going wrong, but nothing that I'm definitely sure about. If you are willing to set up your system with remote power and remote serial, and if we knew a reliable way to reproduce the problem, I could probably have the problem identified and fixed pretty quickly. Hrm... if my ISP allows multiple PPPoE sessions, the remote serial shouldn't be a problem. Remote power though... would my idling in IRC and you poking me whenever you want the power state changed work? I'm not completely certain it's even possible to turn the system in question off short of the physical power switch and even if it is, I'm positive that it's not possible to turn it back on again since there is no power switch header on the motherboard. If I *can* get multiple PPPoE sessions running, the setup would be SSHing to a FreeBSD-sparc64 system with a serial and network connection to the affected system. I could give you root access on one or both boxes as needed. I would want you to make me feel a bit more comfortable about letting someone play with the ata driver on a system with a known flakey HD. Some kinda of It's super-duper unlikely that I would thrash the FS thing since I won't be able to put the new HD in for a week or two and I have the usual home system backup plan in place (that is, I plan on backing up someday...) I'll try setting up the extra PPPoE session now (since I'm curious about it anyways) and get back to you on that detail. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Scott Long wrote: I'd like to attack these driver problems. What I need is to spend a couple of days with an affected system that can reliably reproduce the problem, instrumenting and testing the driver. I have a number of theories about what might be going wrong, but nothing that I'm definitely sure about. If you are willing to set up your system with remote power and remote serial, and if we knew a reliable way to reproduce the problem, I could probably have the problem identified and fixed pretty quickly. So, it turns out that I can't have multiple PPPoE sessions at the same time. :-( I should be able to hack together something though if the rest of the stuff I mentioned is fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Custom termcap entries and installworld]
1) How do people cope with custom termcap entries? One workaround is to not modify /etc/termcap at all. Instead just store them in a file somewhere and (depending on your shell) do export TERMCAP=/my/custom/termcap Or even export TERMCAP=custom:my custom entry See the ENVIRONMENT section near the bottom of man 3 curses. Hrm... I don't *think* this can be done by frobbing /etc/gettytab, but perhaps it can... I'll give it a shot. Thanks for the reply. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[Fwd: Custom termcap entries and installworld]
---BeginMessage--- I've now shot myself in the foot at least three times in as many years with custom termcap entries... here's the deal: 1) I modify /etc/termcap and customize a termcap entry for some valid reason (I need 132x42 or whatever for my Link MC/5) 2) I update /etc/gettytab and /etc/ttys accordingly and happily use my dumb terminal on occasion (roughly once per week) 3) I upgrade via sources, being sure to run mergemaster and friends. 4) My terminal stops working. I have now shot myself in the foot and need to recreate the termcap entry (which, silly me, I didn't back up) Now, intellectually, I *know* that termcap is really stored in /usr/share/misc, and that mergemaster doesn't/can't touch those files since they're not configuration files... but every single time I run installworld, I need to take a manual step to keep things working the way they were before. This is a POLA breaker but I've just ignored it every time it happened until now. This time I opened a PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/97407) wishing for mergemaster support which, of course, isn't the Right Thing. So, I suppose my questions are these: 1) How do people cope with custom termcap entries? 2) Is there a *correct* way to cope with custom termcap entries? 3) Is there a good reason to not have /usr/share/misc/termcap be a symlink to /etc/termcap rather than the reverse which would allow mergemaster to Just Work? that is... putting it in /etc fixes a problem... does moving it create one or more more serious problems? 4) Am I supposed to submit every custom termcap tweak for inclusion in the next release so I can keep using my terminals? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ---End Message--- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: burncd audio produces white noise
Michael A. Koerber wrote: All, Once upon a time, I think with 5.x or perhaps earlier, the command (ATAPI drive) burncd -ef /dev/acd0 audio *.cdr fixate would produce an audio CD for me. However, under 6.0 and recently 6.1 this same command produces an CD filled with white noise only. The entire procedure I've used is: 1. Start w/ some MP3 files. 2. Use sox (or lame) to convert to CDR format 3. Verify the CDR format with 'xine filename.cdr' (sounds good) 4. Make CD with above command. 5. Play CD on two different players (one on PC, one on entertainment system) (sounds like white noise) 6. Extract a CD track with dd if=/dev/acd0t01 of=tmp.cdr bs=2532 7. Test ripped track with 'xine tmp.cdr' sound just like the original MP3! To ensure that there weren't permissions problems along the way, I've executed these commands as root, though I once did this as a normal user. Any ideas on what I should look at to fix this problem? Yeah, I've noticed that too now that you mention it. When it happened to me, I switched to using atapicam and cdrecord with the -swab parameter. Also, you may want to look at audio/mp3burn (still need to pass -swab though) I would recommend that you file a PR on this one. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: burncd audio produces white noise
Max Laier wrote: Yeah, I've noticed that too now that you mention it. When it happened to me, I switched to using atapicam and cdrecord with the -swab parameter. Also, you may want to look at audio/mp3burn (still need to pass -swab though) I would recommend that you file a PR on this one. Obviously you are giving the wrong options to sox/lame. Most likely you are confusing byte-order. Might also be a problem with the configuration options for the respective ports Something was confusing byte-order, that's for sure (or -swab wouldn't help) however, when I ripped, I would use madplay, not sox... and I *believe* that I had tried the dd method from CD to CD as outlined in the handbook and it failed too. I'm groping for details because I don't burn audio CDs very often, but when something is converted from mp3 to cda, then the resulting cda is burnt to a CD on the same system that did the conversion, it should Just Work. iirc, the CDA format uses the hosts byte order so burncd (or morelikely, the device) would need to use swab() when burning on BE systems. Definitely something for Michael to try is following the steps outlined in the handbook for copying a CD and see if he still has the byte-swapping problem. ___ 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?
Howard Leadmon wrote: Hello All, I have been running FBSD a long while, and actually running since the 5.x releases on the server I am having troubles with. I basically have a small network and just use NIS/NFS to link my various FBSD and Solaris machines together. This has all been running fine up till a few days ago, when all of a sudden NFS came to a crawl, and CPU usage so high the box appears to freeze almost. When I had 6.1-RC running all seemed well, then came the announcement for the official 6.1 release, so I did the cvs updates, made world, kernel, and ran mergemaster to get everything up to the 6.1 stable version. Now after doing this, something is wrong with NFS. It works, it will return information and open files, just it's very very slow, and while performing a request the CPU spike is astounding. A simple du of my home directory can take minutes, and machine all but locks up if the request is done over NFS. Here is top snip: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 497 root 1 40 1252K 780K - 2 50:42 188.48% nfsd This is a nice IBM eServer with dual P4-XEON's and a couple GB or RAM on a disk array, and locally is screams, heck NFS used to scream till I updated. I am not really sure what info would be useful in debugging, so won't post tons of misc junk in this eMail, but if anyone has any ideas as to how best to figure out and resolve this issue it would sure be appreicated... 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) Other than that issue, NFS itself has been working nicely for me. ___ 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?
Howard Leadmon wrote: Would this just be lockd, or should I disable both lockd and statd? I notice in the rc.conf it claims they are both supposed to be enabled, so not sure what issues I run into if I disable them, if any. No need to disable rpc.statd though I don't know if any other programs request monitoring. The issues you'll run into is simply a lack of any locks on the mounted drive. This can easily lead to file corruption if multiple programs or multiple instances of a single program change the same file at the same time. Many programs will use NFS-safe lockfiles if configure to do so, which is often a useable workaround in a lockd-free world. If you're only using the files read-only, or only a single process uses files on the mount at a time (on *all* systems) then there's no issue at all. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Release schedule for 2006
Security updates will be maintained for quite a while. However, it takes manpower to test each proposed security change, so it's very hard to justify doing them 'indefinitely'. The stated policy from the security team is 2 years. So they will probably support 5.5 into 2008, but I wanted to be conservative in my statement in case they have different plans. It seems to me like FBSD may be pushing too much to a new major version. Although NBSD is stepping up the -release versions significantly, I feel that FBSD (and friends, but this is hardly the place for BW about them) are/is moving a bit too quickly. While the SMP changes are nice and all (my main application server at home is a dual coppermine 1GHz), the tty (for example) seems to be getting more and more unstable as it goes on... this seems to a certain degree to be that features in -CURRENT are barely cooking let alone baking, and talk is already that 5.x is obsolete. Pushing off GIANT was a 5.x goal iirc, and making existing changes stable is a per-major goal (again, imho). It seems like the version numbers aren't actually meaningfull anymore. I mean... rant drunk ignore=good idea, I will tomorrow I'm used to a FBSD that would change majors when an API and/or ABI *needed* changing. It feels like it's happening 'cause it'd be cool to have a 7.x now. The FBSD pthread support for example has been better than Linux since libc_r... and it's only improved. But I can't actualy *rely* on anything specific working. A project I work on has had a THREADS_ACTUALLY_WORK flag available for Linux when they acually do (not yet, let's not talk about sigwait()) for the last few years. But I can't depend on a major version for strtold()... can't even depend on a comparison. It's hard to know what to depend on now... Things are Changing and you need to know exactly what you need to discover what is required. A few years ago, I was flabbergasted when I was asked for a way to identify the libc version under FBSD. The need to do something like that never occured to me the possibility of having libc out of sync with the kernel never even crossed my mind, and the reason was that the whole thing was one system. It's starting to feel a lot more like some whatever Linux system now... only without the spiffy up2date thinger to go with it. Upgrading from major to major has been something I never minded when needed, but it's too needed now and there's nothing to make it happy. Either the OBSD no need to rebuild GENERIC model is being accepted, or we're dumping the /etc/,/usr/*/etc/* backup and restore model. I love rcNG for example... but my OPL3 no longer does anything usefull... I had an AWE32 with gobs of RAM plugged in and had to use the Voxware drivers until I couldn't... and now I *need* to use timidity because what other choice do I have? I guess I'm old-fashioned, but I just recently managed to have my LaserWriter 16/600 (using the built-in AUI port) be as easy to set up with CUPS as with printcap I was happy and joyfull. But I had to *manually* do the /usr/bin/* and /usr/sbin/* symlinks *and rebuild KDE samba, and OOo. Why? Probobly 'cause I had lpr working before... does the vaunted handbook even suggest CUPS is there the slighest hint of a migration path? My home NIS and NFS server recently became a Solaris 10 one because it Just Works -- despite the inetd, local service, etc horribleness (still not an AMd fan... mount /home via NFS and don't worry) but I'm worried... even I, a FBSD fanatic am moving my servives off of my various FBSD boxes. Why? They may not work when Things are Better. FBSD currently out sells any *nix you pick... *BSD, */Linux, heck, *X.. but when Apache and PostgreSQL move to Linux as their primary system (and the world yawns... let's not talk about BDB) this is a wake-up call... I still haven't tried DragonFly, I think their development model is surpassed by FBSD. But hey, they fixed their clock and no other BSD did. Small incremental fixes. Have we lost that? One tool for the job. Perl killed it? FBSD is *NOT* a kernel bsdtar is *way* too late to make excuses for... where did the pascal compiler go? /rant Significant performance and stability enhancements that simply cannot be broken up and backported to FreeBSD 5. We are marching towards a 'Giant-less' kernel, which means continuing better SMP performance and better UP responsiveness. With 6.0 we are finally starting to see the benefit of the SMPng work that we've been doing for 5 years. iirc, this was a 5.x goal. We get a Major with no reason. Release notes between Majors are BORING... one needs to look at the userland to get anything they expect to use, and *BASIC* subsystems like the tty suffer. /drunk Will UP ever match what it once was? ___ freebsd-stable@freebsd.org mailing list
Re: /create/symlink failed: no inodes free
MS-KILA wrote: still present trying to install 6.0 on a 600Mhz celery, 384 ram, 8g hdd; ftp install. will attempt the explicit ip idea. does every first attempt at ftp choke like this? wayne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] I've found that starting an emergency shell, running ifconfig yourself, then verifying connectivity *FIRST* is required for some rl cards... or at least, that's what I've been doing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PERFMON with Athlon breaks ata.
Joseph Koshy wrote: A custom kernel compiled with options PERFMON and cputype=athlon when ran on an athlon causes ATA to not probe devices on FreeBSD 6.0-RELEASE. dmesg seems normal except the ata probe is never done, so the only boot devices available is the floppy. AFAIR, PERFMON only supports Pentium and Pentium Pro CPUs. Yeah, wasn't sure... I know the Athlon has a performance counter, but wasn't sure if it was supported etc. Assumed not, but just thought I'd mention it in case it's supposed to work. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PERFMON with Athlon breaks ata.
A custom kernel compiled with options PERFMON and cputype=athlon when ran on an athlon causes ATA to not probe devices on FreeBSD 6.0-RELEASE. dmesg seems normal except the ata probe is never done, so the only boot devices available is the floppy. Just something I noticed in passing, not opening a PR since I'll never follow this up. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mplayer + bktr
Daniel O'Connor wrote: FreeBSD doesn't have rtc.ko.. Mine doesn't anyway :) I'm not sure how mplayer in FreeBSD stamps frames either. It's not stock, but /dev/rtc (via rtc.ko) can be had via emulators/rtc if rtc.ko exists, it's a dependency, to force it to be built you can frob the WITH_RTC knob. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New user confused by need to do huge upgrade
I installed from two CDs, and got a working KDE system. Now, I want to do Firefox from ports with my own make.conf for P4 optimisation. Good! So, I sync with the sources using cvsup (just like emerge --sync) change to the Firefox ports directory, type make and enter dependency hell like has never been known before. Everything that depends upon GTK2 must be updated before Firefox can be compiled! I thought that FreeBSD would be more stable than Gentoo and Linux distros in general. I now find that there is the most major release step (5.4 to 6.0) and within a matter of a few days later, both Gnome and KDE are subject to huge updates that require many hours (or maybe days - it's not done yet) of CPU time. Maybe I am missing something. However, I just cannot see why this is right. What I thought that FreeBSD would give me that Gentoo did not is a coherent system within which deveopment was co-ordinated. Instead, I seem to find the opposite. The core group can offer a major release of the OS, while missing the fact that two hugely important development groups are just days off their own major releases. Maybe there is a level of sanity I am missing as a newcomer to BSD, but I would really like someone to tell me where to find it so that I can stop having to use this bloody Windows laptop to post here ;-) Heh, essentially the problem is this... before a release, the ports tree is stabalized... everything builds and works together, broken dependencies are fixed, all is good with the world. This is the ports tree which is included in the release. After the release, More Stuff (tm) is added/updated/etc. By doing a cvsup, you asked for the newest version of all the ports, one which is not necessarily stable... dependencies may be broken, things may not work etc. Doing a cvsup in ports is like tracking -STABLE for ports. If you had not done the cvsup, FF would have built and installed nicely. IMHO, CVSupping ports is subject to the same caveats as tracking -STABLE (See section 20.2.2 in the handbook) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.x, 6.x and CPUTYPE
I always build my production servers with CPUTYPE=i686 so they can be transplanted to any machine with a PPro or better processor (or even qemu if necessary). Thanks, Craig. I'm glad to hear that I'm not alone in pursuing this method. Do you know of any particular disadvantages of continuing with this less-than-optimised model - I guess I mean, is this something that is likely to break or become uneconomical at some point? For packages, it's a good idea to make a build jail... in case of static linking goodness. I had packages bite me when I was building them all on a system with a CPUTYPE=p3 world. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /create/symlink failed: no inodes free
Matt Smith wrote: Trying to put FBSD 6.0-Stable on a box and the error in the subject line (/create/symlink failed: no inodes free) comes up right after the filesystems are made and the transfer over FTP starts. What causes this error? I've found this tends to happen if the install is aborted then restarted. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /create/symlink failed: no inodes free
Matt Smith wrote: In this case I think the hard disk filled up during the install as I got later: couldn't create /usr/compat - no space left on device. Right... that's essentially the same error. What apears to happen when the install is aborted/restarted is that instead of installing to the HD, it ends up trying to install to the RAM disk... which fills up pretty quickly. :-) Of course, it is possible that the HD did fill. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
