Re: DigiBoard Xem with 2 extenal modules
On 2008-Aug-04 13:49:58 -0300, Alexandre Biancalana [EMAIL PROTECTED] wrote: Modems connected but they only work on ports of the first module, any decice connected on ports of second module does not work. ISTR the problem I ran into was that the octet read out of the driver bore little resemblance to the serial data written into the port. The bit-rate would match and framing was reported as correct but I would get nonsense in the top or bottom 4 bits. My notes are at work and I'll try and dig them up tomorrow. Any other idea ? All I can suggest is comparing the Linux driver with the FreeBSD one (and maybe someone needs to confirm if it works in Linux). I couldn't find a difference but maybe someone will see something I missed. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpUvI9NuauSF.pgp Description: PGP signature
Re: em(4) on FreeBSD is sometimes annoying
Am Mon, 4 Aug 2008 12:12:24 -0700 schrieb Jack Vogel [EMAIL PROTECTED]: OK, so your EEPROM is does not have the bug. As I was saying before, I would like to see what back to back behavior is. And, BTW, back to back does NOT mean hook to the switch, that's the very thing that is suspicious. It means NIC to NIC, no DHCP, assigned addresses. And then see that you pass traffic, and then unhook cable, see if link goes down, reconnect and it should go up. With no /etc/rc.d/netif script involved during startup everything always works as expected. If I comment the line ifconfig_re0=DHCP and start my laptop. I can assign the address. I can ping the other NIC. If can unhook the cable the LED goes off, link goes down, I can plug it in again, I can ping again. I have also no problems if I start without ifconfig_re0=DHCP and run dhclient em0 while ethernet cable is unplugged. If I plug it in again, everything works like above. But: If I startup with ifconfig_em0=DHCP AND (binary and!) no cable nothing of this works correctly. There must be something ifconfig_em=DHCP causes on startup that running dhclient does not cause and that provokes the dead state. Oh, and exactly what kernel, and driver revision are you using. Kernel is FreeBSD-STABLE compile date Mon Aug 4 13:41:43 CEST 2008. It's GENERIC. The em(4) driver is the one used in this STABLE version of yesterday. I should perhaps mention that I have some other problems with this laptop. I cannot boot with a PCMCIA wireless card (atheros) already in the slot, or I get 100% load on cbb(4) and the system is not usable. If I boot without the Atheros card and I plug it in later, it mostly is detected. AND I get sometimes an NMI when Atheros card is in use AND (binary and again!) the laptop is on battery. This happens also on Linux. AND the laptop will almost never recognize the Atheros card, if I am using a text terminal with high resolution (set by vidcontrol MODE_280 with VESA support compiled in; cannot reproduce now, because I'm using GENERIC). I don't know if these things are related. I will get some other laptop in one or two months. I hope these things won't bother me anymore. -- Martin signature.asc Description: PGP signature
Stable SATA pci card for FreeBSD 6.x/7.0
Hi, I'm running FreeBSD 6.3 (I know, I should upgrade), and I just bought an add-on pci SATA controller for 2 extra SATA disks. However, a lot of disk activity on the drives will often cause the machine to crash and spontaneously reboot. I checked out which chipset was on the card with pciconf -lv and I found it was the Sil 3512. Googling showed me that I'm not the only one with problems using this card. Does anybody have experience with a (preferably not too expensive) 2-port SATA expansion card which does not have any issues running under FreeBSD 6.3/7.0? [pciconf -lv output] [EMAIL PROTECTED]:10:0: class=0x018000 card=0x35121095 chip=0x35121095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'Sil 3512 SATALink/SATARaid Controller' class = mass storage [/var/log/messages before the crash] Aug 5 11:16:14 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)]error = 6 Aug 5 11:16:17 piglet last message repeated 9 times Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: Query timeouts on FreeBSD 7 over network
I've tried with the ULE scheduler and 4BSD and tried with and with out PREEMPTION turned on. Nothing makes a difference. First of all you could try to connect only two machines via cross-over cable, no any switches between the machines, no any VLANs and so on. FreeBSD-7.0 works better with ULE-scheduler and kernel should be preemtive (options PREEMPTION in kernel config). - what is your kernel config? I'm pretty sure this is related to the OS or the em driver in some way, because if I disable all ICMP rate limiting and run an extended ping from the local firewall, I experience a very low amount of random packet loss in no pattern, unlike if you have the ICMP rate limiting enabled. Once again it would be better if you do analyze the traffic going throuth the em-interface excluding your DNS testing data. Try to get the network with no any walking packets but dnsperf traffic and no any upinks and/or downlinks. Also, are there any documented recommendations for sysctl values for FreeBSD when running BIND for optimal performance? - What options did you provide to configure script during BIND building? One of necessary options should be --enable-threads if you build BIND under FreeBSD 7.0. +---+ ! CANMOS ISP Network! +---+ ! Best regards ! ! Igor V. Ruzanov, network operational staff! ! e-Mail: [EMAIL PROTECTED] ! +---+ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable SATA pci card for FreeBSD 6.x/7.0
On Tue, Aug 05, 2008 at 12:28:40PM +0200, Sebastiaan van Erk wrote: However, a lot of disk activity on the drives will often cause the machine to crash and spontaneously reboot. I checked out which chipset was on the card with pciconf -lv and I found it was the Sil 3512. Googling showed me that I'm not the only one with problems using this card. Yes, most of the Silicon Image ICs I've read about have odd driver problems or general issues (even under Windows). The system rebooting is an odd one; you sure your PSU can handle two disks? Does anybody have experience with a (preferably not too expensive) 2-port SATA expansion card which does not have any issues running under FreeBSD 6.3/7.0? Promise makes some consumer-priced cards which work very well under FreeBSD (sos@ has full documentation on their cards). Their RAID controllers (the consumer-level ones) **do not** require that you use RAID; they support JBOD, and the disks will show up under FreeBSD as ad(4) devices. (If you choose to use the RAID, you'll still see the ad(4) disks, but you'll also see an ar(4) device too. This has the added advantage of you being able to monitor SMART stats on the disks themselves directly, etc... [pciconf -lv output] [EMAIL PROTECTED]:10:0: class=0x018000 card=0x35121095 chip=0x35121095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'Sil 3512 SATALink/SATARaid Controller' class = mass storage [/var/log/messages before the crash] Aug 5 11:16:14 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)] error = 6 Aug 5 11:16:17 piglet last message repeated 9 times Are you sure this is being caused by the controller? Have you checked SMART statistics on both disks? Assuming error == errno, errno 6 is Device not configured. There's been recent discussion of such messages being caused by the use of gmirror or gjournal, when the mirror/journal is improperly set up. (In one users' case, he was receiving similar errors, as well as the filesystem failing during fsck. Turns out he incorrectly configured journalling, which nuked the last ~1MB of his UFS filesystem.) I'm not saying this is the reason for the messages you see, but it's something to keep in mind. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Query timeouts on FreeBSD 7 over network
On Tue, Aug 05, 2008 at 03:04:50PM +0400, Igor V. Ruzanov wrote: I've tried with the ULE scheduler and 4BSD and tried with and with out PREEMPTION turned on. Nothing makes a difference. First of all you could try to connect only two machines via cross-over cable, no any switches between the machines, no any VLANs and so on. FreeBSD-7.0 works better with ULE-scheduler and kernel should be preemtive (options PREEMPTION in kernel config). - what is your kernel config? I'm pretty sure this is related to the OS or the em driver in some way, because if I disable all ICMP rate limiting and run an extended ping from the local firewall, I experience a very low amount of random packet loss in no pattern, unlike if you have the ICMP rate limiting enabled. I believe -stable just got added to this thread, so I'm not sure if these details were provided prior. My apologies if this stuff has already been dealt with. 1) Are there any messages from the kernel about watchdog timeouts or other anomalies pertaining to the network? Look in dmesg. 2) pciconf -lv (only include the Ethernet entries please), vmstat -i and netstat -in output. 3) Try disabling MSI/MSI-X via /boot/loader.conf variables (you'll need to reboot after this): hw.pci.enable_msi=0 hw.pci.enable_msix=0 4) Disabling TSO on the interface, and in the OS: ifconfig emXX -tso sysctl net.inet.tcp.tso=0 -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable SATA pci card for FreeBSD 6.x/7.0
Hi, Thanks for the reply. Jeremy Chadwick wrote: Yes, most of the Silicon Image ICs I've read about have odd driver problems or general issues (even under Windows). The system rebooting is an odd one; you sure your PSU can handle two disks? Well, I've got a 450W Asus PSU in there, but I've also got 6 hard disks and 1 dvd-rom drive (mostly inactive) in there. The hard disks are mostly 250/300GB but the two new ones are 1TB SATA drives. But the 450W should easily be enough, shouldn't it? Does anybody have experience with a (preferably not too expensive) 2-port SATA expansion card which does not have any issues running under FreeBSD 6.3/7.0? Promise makes some consumer-priced cards which work very well under FreeBSD (sos@ has full documentation on their cards). Their RAID controllers (the consumer-level ones) **do not** require that you use RAID; they support JBOD, and the disks will show up under FreeBSD as ad(4) devices. (If you choose to use the RAID, you'll still see the ad(4) disks, but you'll also see an ar(4) device too. This has the added advantage of you being able to monitor SMART stats on the disks themselves directly, etc... I'll have a look at that if I can't get this one stable. They're reasonably priced, so if they're good with FreeBSD then that looks like a good option to me. [pciconf -lv output] [EMAIL PROTECTED]:10:0: class=0x018000 card=0x35121095 chip=0x35121095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'Sil 3512 SATALink/SATARaid Controller' class = mass storage [/var/log/messages before the crash] Aug 5 11:16:14 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)] error = 6 Aug 5 11:16:17 piglet last message repeated 9 times Are you sure this is being caused by the controller? Have you checked SMART statistics on both disks? Assuming error == errno, errno 6 is Device not configured. I did look at the smart stats [pasted them below]. What I will try next is just to switch the two 250GB SATA drives on my main board with the two 1TB drives on the controller and see if I still get the problems if I really increase the load on the two 1TB drives. There's been recent discussion of such messages being caused by the use of gmirror or gjournal, when the mirror/journal is improperly set up. (In one users' case, he was receiving similar errors, as well as the filesystem failing during fsck. Turns out he incorrectly configured journalling, which nuked the last ~1MB of his UFS filesystem.) I'm not saying this is the reason for the messages you see, but it's something to keep in mind. I'll try reconfigure the geom. I used an online tutorial, but I'm not quite sure that I did everything correctly, though fsck worked alright. I did do this one differently than usual though, usually I use full disk mirror after I already initialized one of the disks, and then I convert it to a mirror by using: sysctl kern.geom.debugflags=16 gmirror label -v -b round-robin gm0 /dev/ad0 gmirror insert gm0 /dev/ad2 (Especially useful when you want the entire FreeBSD install to be mirrored). I guess I can try this on the extra disks as well. Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: Stable SATA pci card for FreeBSD 6.x/7.0
Hi, Sorry for forgetting to paste the smart details. Pressed send too quickly. However, when I did check the smart stats again, I noticed I'd been smartctling the wrong disk (duh), and smart was not enabled on the new disks. I enabled it now, and it comes with a bunch of warnings and other stuff Considering it wasn't enabled, maybe the errors wouldn't show up anyway, but here's the output of the smartctl command just in somebody sees something to worry about in it... (The ECC recovery count looks rather high, I tried -F samsung and -F samsung2 but that didn't help). Regards, Sebastiaan [EMAIL PROTECTED](ttyp3:59:0):~# smartctl -a /dev/ad4 smartctl version 5.37 [i386-portbld-freebsd6.3] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: SAMSUNG HD103UJ Serial Number:S13PJ1BQ606865 Firmware Version: 1AA01112 User Capacity:1,000,204,886,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Not recognized. Minor revision code: 0x52 Local Time is:Tue Aug 5 15:15:20 2008 CEST == WARNING: May need -F samsung or -F samsung2 enabled; see manual for details. SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (11811) seconds. Offline data collection capabilities:(0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 2) minutes. Extended self-test routine recommended polling time:( 198) minutes. Conveyance self-test routine recommended polling time:( 21) minutes. 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 1 Raw_Read_Error_Rate 0x000f 253 253 051Pre-fail Always - 0 3 Spin_Up_Time0x0007 090 090 011Pre-fail Always - 4050 4 Start_Stop_Count0x0032 100 100 000Old_age Always - 4 5 Reallocated_Sector_Ct 0x0033 100 100 010Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 253 253 051Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015Pre-fail Offline - 0 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 230 10 Spin_Retry_Count0x0033 100 100 051Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always - 4 13 Read_Soft_Error_Rate0x000e 253 253 000Old_age Always - 0 183 Unknown_Attribute 0x0032 100 100 000Old_age Always - 0 184 Unknown_Attribute 0x0033 100 100 099Pre-fail Always - 0 187 Unknown_Attribute 0x0032 100 100 000Old_age Always - 0 188 Unknown_Attribute 0x0032 100 100 000Old_age Always - 0 190 Temperature_Celsius 0x0022 056 056 000Old_age Always - 740818988 194 Temperature_Celsius 0x0022 052 052 000Old_age Always - 48 (Lifetime Min/Max 0/12324) 195 Hardware_ECC_Recovered 0x001a 100 100 000Old_age Always - 153751007 196 Reallocated_Event_Count
Re: Stable SATA pci card for FreeBSD 6.x/7.0
On Tue, Aug 05, 2008 at 03:16:41PM +0200, Sebastiaan van Erk wrote: Sorry for forgetting to paste the smart details. Pressed send too quickly. A note for the list: Sebastiaan and I are discussing the details off-list. I don't know if he forgot to CC the list on his replies, or if he intentionally sent them to me directly. :-) Just thought I'd make note of that here, in case readers wonder what becomes of this issue. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable SATA pci card for FreeBSD 6.x/7.0
Hi, I'm interested and following the thread, can you pls send the communication that's of importance to all at the end? cheers, valqk. Jeremy Chadwick wrote: On Tue, Aug 05, 2008 at 03:16:41PM +0200, Sebastiaan van Erk wrote: Sorry for forgetting to paste the smart details. Pressed send too quickly. A note for the list: Sebastiaan and I are discussing the details off-list. I don't know if he forgot to CC the list on his replies, or if he intentionally sent them to me directly. :-) Just thought I'd make note of that here, in case readers wonder what becomes of this issue. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Max size of one swap slice
Hi All, Recently we found that we can only allocate 32GB for one swap slice. Does there is any sysctl oid or any kernel option to increase it? Why we have this restriction? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable SATA pci card for FreeBSD 6.x/7.0
Hi, Sorry about that, I believe I only messed up on my first reply, and I thought I mailed that to the list as well after I noticed I messed up. Thing is, I'm used to replying to mailing lists using the Reply button and unfortunately the reply doesn't go to the mailing list when I do that... Some people don't like it when you send it to the mailing list and CC it to them personally, but since you apparently do, I'll just use reply-all from now on. Sorry again about the mistake, Regards, Sebastiaan Jeremy Chadwick wrote: On Tue, Aug 05, 2008 at 03:16:41PM +0200, Sebastiaan van Erk wrote: Sorry for forgetting to paste the smart details. Pressed send too quickly. A note for the list: Sebastiaan and I are discussing the details off-list. I don't know if he forgot to CC the list on his replies, or if he intentionally sent them to me directly. :-) Just thought I'd make note of that here, in case readers wonder what becomes of this issue. smime.p7s Description: S/MIME Cryptographic Signature
Stuck in geli
Rarely, a geli partition I have freezes a process in bufwait state. It occurs after an ATA timeout message: Aug 5 03:47:13 thor kernel: ad10: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=219028637 The geli partition resides on an Intel MatrixRAID RAID1 mirror using the ICH9R chipset (Asus P5K-E/WIFI). Killing (even -9) the process does not work. Rebooting is the only solution, yet the system is unable to flush the buffers and complete a clean unmounting. Both drives in the mirror have both survived a smartctl -t offline scan. Also, a previous time it was with ad12, so I strongly doubt it is the drive. It seems like a geli partition is unable to handle a timeout from a drive. ad10: Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family Device Model: ST3160827AS ad12: Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family Device Model: ST3160827AS Sean P.S. I could not help myself with the subject line. :) -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Max size of one swap slice
On Tue, Aug 05, 2008 at 11:39:11PM +0800, Lin Jui-Nan Eric wrote: ... Recently we found that we can only allocate 32GB for one swap slice. Yes. Does there is any sysctl oid or any kernel option to increase it? Why we have this restriction? I don't know why, though I suspect it may have something to do with the way storage in the swap space is allocated addressed. You may, however, have more than 1 swap space. (Per man pages for swapon(8) and swapoff(8), the default maximum is 4.) Peace, david -- David H. Wolfskill [EMAIL PROTECTED] I submit that conspiracy would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp9jUikPpVDV.pgp Description: PGP signature
Re: Max size of one swap slice
On Aug 5, 2008, at 8:39 AM, Lin Jui-Nan Eric wrote: Recently we found that we can only allocate 32GB for one swap slice. Does there is any sysctl oid or any kernel option to increase it? Why we have this restriction? This size limitation likely predates the availability of disks larger than 32GB. It's hard to conceive of why you'd want to add so much swap space, anyway-- if you've got programs which actually need to deal with 10s of gigabytes worth of data, then they ought to maintain a smaller/ reasonable-sized working set in RAM and do disk I/O as needed themselves rather than depend upon the VM pager, anyways. (Well, when using a BSD-derived kernel, anyways. Some of the Mach kernels support userland VM pager implementations, so that things like a database or Photoshop can provide their own pager which understands their workload and chooses which pages to evict or replace better than the default system pager algorithm can.) Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable SATA pci card for FreeBSD 6.x/7.0
Jeremy Chadwick wrote: First and foremost, you've forgotten to CC the mailing list on all but one of your replies. I'll assume this is intentional, but it's probably not for the best, as readers may find your post and wonder what the outcome was. It was not intentional, it hit reply instead of reply-all. Sorry. I will reply this to the list, so other interested parties can follow the thread and your informative replies. On Tue, Aug 05, 2008 at 02:47:45PM +0200, Sebastiaan van Erk wrote: Hi, Thanks for the reply. Jeremy Chadwick wrote: Yes, most of the Silicon Image ICs I've read about have odd driver problems or general issues (even under Windows). The system rebooting is an odd one; you sure your PSU can handle two disks? Well, I've got a 450W Asus PSU in there, but I've also got 6 hard disks and 1 dvd-rom drive (mostly inactive) in there. The hard disks are mostly 250/300GB but the two new ones are 1TB SATA drives. But the 450W should easily be enough, shouldn't it? Without getting into semantics, a 450W PSU may be on the light side for 6 disks. I'm fairly amazed you're able to power up that machine without disk errors or other problems during POST. You'll be having 6 disks spin up all simultaneously -- and spin-up is when disks draw the most power, and possibly during normal operation. If you have a different (or larger) PSU, I would recommend trying that to see if it addresses your problem. A PSU which isn't providing enough power will cause the disks to occasionally disconnect from the bus, or the machine sporadtically lock up, reboot (power-cycle), or other odd things. Unfortunately I don't have a larger PSU lying around, but I could buy one; though I'd like to try some other stuff first because I've had 6 disks in my PC before without any problems. [/var/log/messages before the crash] Aug 5 11:16:14 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)] error = 6 Aug 5 11:16:17 piglet last message repeated 9 times Are you sure this is being caused by the controller? Have you checked SMART statistics on both disks? Assuming error == errno, errno 6 is Device not configured. I did look at the smart stats [pasted them below]. What I will try next is just to switch the two 250GB SATA drives on my main board with the two 1TB drives on the controller and see if I still get the problems if I really increase the load on the two 1TB drives. More and more information about your system configuration is coming to light. Your original post didn't disclose any of that; now I know you have 6 disks in the system, 2 of which are using on-board SATA (no idea what controller), and 2 which are using a Silicon Image controller. What are the remaining 2 disks connected to? Sorry that I didn't give you that information immediately. The problem when you do that though is that the post is sometimes ignored because it is deemed too long or complicated (at least I've seen that happen). I'll glady post any relevant data. My other (on-board) SATA controller is a VIA controller; and I've never had any problems with it (although the hardware raid messed up once a year or 2 ago, and since then I've been using software raid without any issues). [EMAIL PROTECTED]:15:0: class=0x010400 card=0x71421462 chip=0x31491106 rev=0x80 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8237 VT6410 SATA RAID Controller' class = mass storage subclass = RAID The remaining disks are PATA disks which are in the on-board IDE controller. It's a legacy computer that's been upgraded a lot, though it's not too obsolete, the CPU's a AMD Sempron(tm) Processor 2600+ (1599.83-MHz 686-class CPU). Your recommended method of troubleshooting (swapping the 250G for the 1TB) is a good idea. But hear me loud and clear: just because you switch the disks and the problem disappears for a few hours doesn't mean it's gone. There have been **many** people who have shown up on the mailing lists stating I did X thing and now it works!, only to find that a week later it *didn't* fix the problem. Yes, I don't really expect it to solve the problem, but was thinking that at least I could try and stress test the known working disks on the controller and try to see if it's the controller that's the problem or the disks (or something else). I've been able to reproduce the crashes pretty well by just doing a lot of disk IO on the 1TB disks only (so the other disks were pretty idle during the tests). There's been recent discussion of such messages being caused by the use of gmirror or gjournal, when the mirror/journal is improperly set up. (In one users' case, he was receiving similar errors, as well as the filesystem failing during fsck. Turns out he incorrectly configured journalling, which nuked the last ~1MB of his UFS filesystem.) I'm not saying this is the reason for the messages you see, but it's something to keep in
Re: Max size of one swap slice
On Tuesday 05 August 2008 17:39:11 Lin Jui-Nan Eric wrote: Recently we found that we can only allocate 32GB for one swap slice. Does there is any sysctl oid or any kernel option to increase it? Why we have this restriction? this is a consequence of the data structure used to manage swap space. See sys/blist.h for details. It *seems* that you *might* be able to increase the coverage by decreasing BLIST_META_RADIX, but that's from a quick glance and most certainly not a good idea. However, the blist is a abstract enough API so that you can likely replace it with something that supports 64bit addresses (and thus 512*2^64 bytes of swap space per device) ... but I don't see why you'd want to do something like this. Remember that you need memory to manage your swap space as well! -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Max size of one swap slice
: Recently we found that we can only allocate 32GB for one swap slice. : Does there is any sysctl oid or any kernel option to increase it? Why : we have this restriction? : :this is a consequence of the data structure used to manage swap space. See :sys/blist.h for details. It *seems* that you *might* be able to increase the :coverage by decreasing BLIST_META_RADIX, but that's from a quick glance and :most certainly not a good idea. : :However, the blist is a abstract enough API so that you can likely replace it :with something that supports 64bit addresses (and thus 512*2^64 bytes of swap :space per device) ... but I don't see why you'd want to do something like :this. Remember that you need memory to manage your swap space as well! : :-- :/\ Best regards, | [EMAIL PROTECTED] :\ / Max Laier | ICQ #67774661 The core structures can handle 2 billion swap pages == 2TB of swap, but the blist code hits arithmatic overflows if a single blist has more then (0x4000 / BLIST_META_RADIX) = 1G/16 = 64M swap blocks, or 256GB. I think the VM/BIO system had additional overflow issues due to conversions back and forth between PAGE_SIZE and DEV_BSIZE which further restricted the limit to 32GB. Those restrictions may be gone now that FreeBSD is using 64 bit block numbers, so you may be able to pop it up to 256GB with virtually no effort (but you need to test it significantly!). With some work on the blist code only (not its structures) the arithmatic overflow issues could also be resolved, increasing the swap capability to 2TB. I do not recommend changing any of the core blist structure, particularly not BLIST_META_RADIX. Just don't try :-). You do NOT want to bump the swap block number fields to 64 bits. Also note that significant memory is used to manage that much swap. It's a factor of 1:16384 or so for the blist structures and probably about the same amount for the vm_object tracking structures. 32G of swap needs around 2-4MB of wired ram. -Matt Matthew Dillon [EMAIL PROTECTED] ___ 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: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
The thrust of this change is to replace the mutexes protecting the inpcb and inpcbinfo data structures with read-write locks (rwlocks). These That's really cool and directly affects my current work project. I'm developing (have developed, actually) a multi-threaded, 5000+ member VoIP/SIP conferencing server called Nconnect. It a primarily UDP application running on FreeBSD 7. This generates and receives about 250,000 UDP packets a second, with 200 byte packets, resulting in about 400Mbps of traffic in each direction. The current bottleneck is the kernel UDP processing. It should be possible to scale to 1+ members if kernel UDP processing had optimal concurrency. Anyway, thumbs up (and not for the middle-eastern meaning :-)) - I'm looking forward to the MFC. -DG Dr. David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 Pave the road of life with opportunities. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming ABI Breakage in RELENG_7
On Tue, Jul 29, 2008 at 10:45 AM, Ken Smith [EMAIL PROTECTED] wrote: Normally the FreeBSD Project tries very hard to avoid ABI breakage in Stable Branches. However occasionally the fix for a bug can not be implemented without ABI breakage, and it is decided that the fix warrants the impact of the ABI breakage. We have one of those situations coming along for RELENG_7 (what will become FreeBSD 7.1). The ABI breakage should only impact kernel modules that are not part of the baseline system (those will be patched by the MFC) which deal with advisory locks. As such the impact should not cause many people problems. The work that will be MFCed fixes issues with filesystem advisory locks, and moves the advisory locks list from filesystem-private data structures into the vnode structure. The MFC will be done by Kostantin Belousov some time this coming Friday (August 1st, 2008) if you have concerns and want to watch for it. Just updated to 7-STABLE last night and found that Truecrypt (which uses a combination of fuse and mdconfig to mount its encrypted volumes) is now completely unable to mount its encrypted volumes. I've rebuilt fusefs-kmod and fusefs-libs as well as Truecrypt to no avail. As Truecrypt is implementing an encrypted file system, I am assuming at this point that the kernel ABI breakage may be what is causing this new problem. Are the any calls in particular that I should be looking for in the Truecrypt code to see where it might be choking on the new kernel ABI? I've briefly reviewed some of the changes in r181119 but lack the experience to discern anything useful from them. I'd like to file an issue with the Truecrypt devs if I can get an idea of where the breakage might be. Thanks, Matt Thanks. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming ABI Breakage in RELENG_7
Matt wrote: Just updated to 7-STABLE last night and found that Truecrypt (which uses a combination of fuse and mdconfig to mount its encrypted volumes) is now completely unable to mount its encrypted volumes. I've rebuilt fusefs-kmod and fusefs-libs as well as Truecrypt to no avail. Silly question, but did you build AND install both a new world AND a new kernel before you rebuilt your ports? Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Upcoming ABI Breakage in RELENG_7
On Tue, Aug 5, 2008 at 5:09 PM, Doug Barton [EMAIL PROTECTED] wrote: Matt wrote: Just updated to 7-STABLE last night and found that Truecrypt (which uses a combination of fuse and mdconfig to mount its encrypted volumes) is now completely unable to mount its encrypted volumes. I've rebuilt fusefs-kmod and fusefs-libs as well as Truecrypt to no avail. Silly question, but did you build AND install both a new world AND a new kernel before you rebuilt your ports? Yes - full, clean (deleted /usr/obj/* before build) build on world + kernel. I've run it through a couple ktrace runs looking for obvious problems, but haven't found anything that I can interpret yet. It appears the failures are triggering around some file-descriptor errors, but nothing that makes any sense yet. I'll look at things a little closer when I get some more time - need to boot into a backup copy of the 7-RELEASE system to get some baselines. Matt Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable SATA pci card for FreeBSD 6.x/7.0
On Tue, Aug 05, 2008 at 07:08:20PM +0200, Sebastiaan van Erk wrote: Jeremy Chadwick wrote: On Tue, Aug 05, 2008 at 02:47:45PM +0200, Sebastiaan van Erk wrote: Hi, Thanks for the reply. Jeremy Chadwick wrote: Yes, most of the Silicon Image ICs I've read about have odd driver problems or general issues (even under Windows). The system rebooting is an odd one; you sure your PSU can handle two disks? Well, I've got a 450W Asus PSU in there, but I've also got 6 hard disks and 1 dvd-rom drive (mostly inactive) in there. The hard disks are mostly 250/300GB but the two new ones are 1TB SATA drives. But the 450W should easily be enough, shouldn't it? Without getting into semantics, a 450W PSU may be on the light side for 6 disks. I'm fairly amazed you're able to power up that machine without disk errors or other problems during POST. You'll be having 6 disks spin up all simultaneously -- and spin-up is when disks draw the most power, and possibly during normal operation. If you have a different (or larger) PSU, I would recommend trying that to see if it addresses your problem. A PSU which isn't providing enough power will cause the disks to occasionally disconnect from the bus, or the machine sporadtically lock up, reboot (power-cycle), or other odd things. Unfortunately I don't have a larger PSU lying around, but I could buy one; though I'd like to try some other stuff first because I've had 6 disks in my PC before without any problems. See the very bottom of my mail. I don't believe the PSU is the problem, after reviewing your SMART statistics. ...parts of thread cut... My other (on-board) SATA controller is a VIA controller; and I've never had any problems with it (although the hardware raid messed up once a year or 2 ago, and since then I've been using software raid without any issues). Okay, so you've got an onboard VIA (VT6410) SATA controller, an onboard VIA IDE controller, and a PCI SATA controller. I'd still like to know which disks are attached to what controller, and if any of the devices are sharing IRQs. Can you provide the output from the following two commands? dmesg | egrep 'atapci|(ad|ata)[0-9]+' vmstat -i I'm just trying to narrow stuff down. Your recommended method of troubleshooting (swapping the 250G for the 1TB) is a good idea. But hear me loud and clear: just because you switch the disks and the problem disappears for a few hours doesn't mean it's gone. There have been **many** people who have shown up on the mailing lists stating I did X thing and now it works!, only to find that a week later it *didn't* fix the problem. Yes, I don't really expect it to solve the problem, but was thinking that at least I could try and stress test the known working disks on the controller and try to see if it's the controller that's the problem or the disks (or something else). I've been able to reproduce the crashes pretty well by just doing a lot of disk IO on the 1TB disks only (so the other disks were pretty idle during the tests). It's interesting that the disks which are giving you trouble are Samsung disks. There's some history here which you should be made aware of: In July, Daniel Eriksson reported data corruption occurring with his nVidia MCP55 chipset when 1TB Samsung disks were attached to it. The same disks on another controller performed fine. The corruption was being detected by ZFS as checksum errors. (UFS/UFS2 won't detect this sort of thing, unless the corruption is occurring somewhere within the filesystem tables.) http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043427.html Soren Schmidt (ata(4) author) replied that there are some nVidia chipset-related fixes for ATA in -CURRENT, and provided a patch. Daniel reported that the patch made absolutely no difference: http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043434.html Daniel also tried using a firmware patch for his Samsung disks, which limit the SATA speed to SATA150, but the speed was still negotiated as SATA300 (indicating the vendors' own f/w patch is broken, or FreeBSD does not play well with it). The f/w patch didn't fix his problem either: http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043432.html [EMAIL PROTECTED] reported using his MCP55 controller without any problem -- as long as he didn't use Samsung disks. He stated that he believes Samsung disks are PATA disks that use a PATA-to-SATA adapter inside of the drive, leading to problems (and yes, those adapters are known to cause all sorts of mayhem): http://lists.freebsd.org/pipermail/freebsd-stable/2008-July/043485.html I'm not sure what became of the thread; Daniel never provided a post-mortem. I'm left to believe he probably took [EMAIL PROTECTED]'s advice and switched to another disk vendor. ...parts of thread cut... ...smartctl output for both Samsung disks... Thanks for upgrading to 5.38. All the SMART statistics for these
Re: Stuck in geli
On Tue, Aug 05, 2008 at 10:45:16AM -0500, Sean C. Farley wrote: Rarely, a geli partition I have freezes a process in bufwait state. It occurs after an ATA timeout message: Aug 5 03:47:13 thor kernel: ad10: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=219028637 This looks like the issue I've been tracking for months now. I'm sorry the document isn't complete; it's an issue of time... http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting The geli partition resides on an Intel MatrixRAID RAID1 mirror using the ICH9R chipset (Asus P5K-E/WIFI). Killing (even -9) the process does not work. Rebooting is the only solution, yet the system is unable to flush the buffers and complete a clean unmounting. After reading my above Wiki page, I hope you consider disabling MatrixRAID and avoiding it entirely on FreeBSD. There are patches to address major issues which have been sitting untouched, despite patches included, for 2+ years. Draw your own conclusions. Also, you won't be able to kill -9 a process in that state. The kernel (or some piece of it) is hung, not the process. The fact that a reboot is required also does not surprise me. You *might* have been able to detach the ATA/SATA channel using atacontrol to get access to the system, but then again it might result in a system panic (see Wiki). Both drives in the mirror have both survived a smartctl -t offline scan. This doesn't really mean anything; the SMART statistics, self-test log, and error log are what's more important. Chances are it's not a disk issue though... Also, a previous time it was with ad12, so I strongly doubt it is the drive. It seems like a geli partition is unable to handle a timeout from a drive. The problem is not with geli(4), as I see it. ad10: Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family Device Model: ST3160827AS ad12: Model Family: Seagate Barracuda 7200.7 and 7200.7 Plus family Device Model: ST3160827AS My experiences with disk timeouts on FreeBSD is that the OS does not handle it well at all, regardless of geli(4) being used or not. The entire system can deadlock, and in some cases panic (which for me is the more common result). I can't help myself here -- Linux's libata handles this much more elegantly. In the case of a failure similar to the above, there is a brief system deadlock and then full system recovery with EIO (I/O error) being returned to any process stuck in that state. There *is* data loss, but I don't think there's anything one can do about that (on Linux or FreeBSD); journalling filesystems should solve that aspect. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable SATA pci card for FreeBSD 6.x/7.0
Sebastiaan van Erk wrote: [/var/log/messages before the crash] Aug 5 11:16:14 piglet kernel: g_vfs_done():mirror/gm1s1e[WRITE(offset=111376236544, length=16384)]error = 6 Aug 5 11:16:17 piglet last message repeated 9 times Can you show which messages where before these? -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stable SATA pci card for FreeBSD 6.x/7.0
I heartily recommend 3ware controllers for FreeBSD 6/7, even if you only need 2 ports. - Andrew ___ 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 to 6.x or 7.x with 64MB /
On Tue, Aug 5, 2008 at 2:48 AM, Nick Barnes [EMAIL PROTECTED] wrote: It occurs to me that if ad0s1a is insufficient then I could use ad0s1g as swap, and repurpose ad0s1b as a new /. Is it straightforward to installworld/mergemaster to somewhere other than / ? The DESTDIR directive will allow you to redirect your installworld to a different location, as for mergemaster IIRC this can be done (been a while since I was working on my embedded stuff that needed all this FreeBSD 6.something in about 8MB) but I can't remember what switches. It might be worth considering building /bin and /sbin dynamically (20oddMB to about 500kB), mind I can't remember where the required libs would be, if they're in /lib it'd be all good, if they're in /usr/lib you're stuck. All things considered I think your best option is to move / to a different partition. Should be relatively painless to do from a LiveCD, mount everything, duplicate / to somewhere else, modify fstab and the bootloader config, reboot. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
