Re: Multiple USB drives stability question
Jeff,
On 15 aug 2009, at 05:04, Jeff Richards wrote:
(da6:umass-sim6:6:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0
0 0
...
I've had lots of stability issues with USB drives until I added some
quirks to prevent the SYNCHRONIZE CACHE from happening. For example:
Index: cam/scsi/scsi_da.c
===
RCS file: /usr/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.224.2.6
diff -r1.224.2.6 scsi_da.c
539a540,547
> * LaCie external 250GB Hard drive designed by Porsche
> * PR: usb/121474
> */
>{T_DIRECT, SIP_MEDIA_FIXED, "SAMSUNG", "HM250JI", "*"},
>/*quirks*/ DA_Q_NO_SYNC_CACHE
>},
>{
>/*
You might try that, and see if it improves your situation.
Ben
___
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: Going to BSD 8 from RELENG_7
Dan Allen wrote: > I cvsup and build RELENG_7 many times a week. This has served me well > (except for the ZFS boot problem I had that went in and was backed out) > for quite a while. > > I like to track a STABLE release. When BSD 7 went to 7.1 and to 7.2, it > all just happened automatically with the way I do things. > > Now I am interested on one of my BSD machines to try 8.0. I need to > change my cvsup target from RELENG_7 to CURRENT I believe. Is that > true? When will STABLE become 8.0? Minor terminology issue, "STABLE" is not the name of one version of FreeBSD, it is the label appended to the version number during the ongoing development of the branch after a release. So there are currently 6.4-STABLE and 7.2-STABLE branches, and after 8.0-RELEASE there will be an 8.0-STABLE. BTW, the -STABLE name refers to the API in that branch, as well as (hopefully) the fact that running it should be safe/stable. If you're interested in testing the new 8.0 version before it is released we would all be very glad to have you do that. :) The more testers we get before release the more certain we can be that there are no problems with it. I would like to make one suggestion though, if you could hold off until the 8.0-BETA3 is ready and test a clean install using the cd iso image that would be great! We never get enough people testing clean installations so this is something that is very valuable. Obviously however you test this you'd want to back up your data and any relevant configuration stuff first. Oh, and any feedback on your experiences can go to the freebsd-current mailing list until after the release. Good luck, 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 "freebsd-stable-unsubscr...@freebsd.org"
Re: Multiple USB drives stability question
I was checking sysctl and noticed skipped_byes, alloc_failures,low_mem all increasing on geom.journal. $sysctl -a | grep geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.mirror.sync_requests: 2 kern.geom.mirror.disconnect_on_failure: 1 kern.geom.mirror.idletime: 5 kern.geom.mirror.timeout: 4 kern.geom.mirror.debug: 0 kern.geom.journal.stats.low_mem: 380 kern.geom.journal.stats.journal_full: 0 kern.geom.journal.stats.wait_for_copy: 25 kern.geom.journal.stats.switches: 834 kern.geom.journal.stats.combined_ios: 5612 kern.geom.journal.stats.skipped_bytes: 34684928 kern.geom.journal.cache.alloc_failures: 14726 kern.geom.journal.cache.misses: 13894 kern.geom.journal.cache.switch: 90 kern.geom.journal.cache.divisor: 2 kern.geom.journal.cache.limit: 167772160 kern.geom.journal.cache.used: 79546368 kern.geom.journal.optimize: 1 kern.geom.journal.record_entries: 20 kern.geom.journal.parallel_copies: 16 kern.geom.journal.accept_immediately: 64 kern.geom.journal.parallel_flushes: 16 kern.geom.journal.force_switch: 70 kern.geom.journal.switch_time: 10 kern.geom.journal.debug: 0 kern.geom.virstor.component_watermark: 1 kern.geom.virstor.chunk_watermark: 100 kern.geom.virstor.debug: 2 debug.sizeof.g_geom: 68 $sysctl -a | grep geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.mirror.sync_requests: 2 kern.geom.mirror.disconnect_on_failure: 1 kern.geom.mirror.idletime: 5 kern.geom.mirror.timeout: 4 kern.geom.mirror.debug: 0 kern.geom.journal.stats.low_mem: 389 kern.geom.journal.stats.journal_full: 0 kern.geom.journal.stats.wait_for_copy: 28 kern.geom.journal.stats.switches: 838 kern.geom.journal.stats.combined_ios: 5622 kern.geom.journal.stats.skipped_bytes: 35667968 kern.geom.journal.cache.alloc_failures: 15016 kern.geom.journal.cache.misses: 15079 kern.geom.journal.cache.switch: 90 kern.geom.journal.cache.divisor: 2 kern.geom.journal.cache.limit: 167772160 kern.geom.journal.cache.used: 73140224 kern.geom.journal.optimize: 1 kern.geom.journal.record_entries: 20 kern.geom.journal.parallel_copies: 16 kern.geom.journal.accept_immediately: 64 kern.geom.journal.parallel_flushes: 16 kern.geom.journal.force_switch: 70 kern.geom.journal.switch_time: 10 kern.geom.journal.debug: 0 kern.geom.virstor.component_watermark: 1 kern.geom.virstor.chunk_watermark: 100 kern.geom.virstor.debug: 2 debug.sizeof.g_geom: 68 --- On Sat, 8/15/09, Jeff Richards wrote: From: Jeff Richards Subject: Re: Multiple USB drives stability question To: freebsd-stable@freebsd.org Date: Saturday, August 15, 2009, 10:50 AM I am now trying to rsync large files from the 320GB gmirror+gjournal device to the 2nd 1TB gmirror+gjournal device. Using gstat I see the 320GB device active all the time while the 1TB device loads in spurts. There will be periods of multiple seconds where the target providers are completely idle while the source providers are still reporting 100% active. Is there any tuning I should be investigating for these GEOM classes? --- On Fri, 8/14/09, Jeff Richards wrote: From: Jeff Richards Subject: Re: Multiple USB drives stability question To: freebsd-stable@freebsd.org Date: Friday, August 14, 2009, 11:04 PM I just tested my 2nd 1TB gmirror device on another system with FBSD 7.2. I was getting full throughput on the drive and no lockup using bonnie++ and also monitoring with gstat. I then moved those drives back on my main server. When I booted the system I hung on the 320GB gmirror devices. Previously the 1st 1TB gmirror and 320GB gmirror were attached to the integrated USB ports on the motherboard. I moved the 320GB gmirror to a PCI USB adapter. The 2 320GB drives in the gmirror were da5 and da6. Here's what I saw on the console: (da6:umass-sim6:6:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da6:umass-sim6:6:0:0): CAM Status: SCSI Status Error (da6:umass-sim6:6:0:0): SCSI Status: Check Condition (da6:umass-sim6:6:0:0): ILLEGAL REQUEST asc:20,0 (da6:umass-sim6:6:0:0): Invalid command operation mode (da6:umass-sim6:6:0:0): Unretryable error GEOM_MIRROR: Request failed (error=5), da6[READ(offset=512, length=512)] GEOM_MIRROR: Device gm-san: provider da6 disconnected. (da5:umass-sim5:5:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da5:umass-sim5:5:0:0): CAM Status: SCSI Status Error (da5:umass-sim5:5:0:0): SCSI Status: Check Condition (da5:umass-sim5:5:0:0): ILLEGAL REQUEST asc:20,0 (da5:umass-sim5:5:0:0): Invalid command operation mode (da5:umass-sim5:5:0:0): Unretryable error GEOM_JOURNAL: BIO_FLUSH not supported by mirror/gm-san. I waited for a few minutes with no change in the console. I then detached one of the USB drives (which happened to be da6) and saw this: umass6: at uhub7 port 4 (addr 4) disconnected (da6:umass-sim6:6:0:0): lost device Nothing else changed for a few minutes so I powered off the system. When I brought it back up the 320GB gmirror device was out of sync, but apart from that all de
Re: Multiple USB drives stability question
I am now trying to rsync large files from the 320GB gmirror+gjournal device to the 2nd 1TB gmirror+gjournal device. Using gstat I see the 320GB device active all the time while the 1TB device loads in spurts. There will be periods of multiple seconds where the target providers are completely idle while the source providers are still reporting 100% active. Is there any tuning I should be investigating for these GEOM classes? --- On Fri, 8/14/09, Jeff Richards wrote: From: Jeff Richards Subject: Re: Multiple USB drives stability question To: freebsd-stable@freebsd.org Date: Friday, August 14, 2009, 11:04 PM I just tested my 2nd 1TB gmirror device on another system with FBSD 7.2. I was getting full throughput on the drive and no lockup using bonnie++ and also monitoring with gstat. I then moved those drives back on my main server. When I booted the system I hung on the 320GB gmirror devices. Previously the 1st 1TB gmirror and 320GB gmirror were attached to the integrated USB ports on the motherboard. I moved the 320GB gmirror to a PCI USB adapter. The 2 320GB drives in the gmirror were da5 and da6. Here's what I saw on the console: (da6:umass-sim6:6:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da6:umass-sim6:6:0:0): CAM Status: SCSI Status Error (da6:umass-sim6:6:0:0): SCSI Status: Check Condition (da6:umass-sim6:6:0:0): ILLEGAL REQUEST asc:20,0 (da6:umass-sim6:6:0:0): Invalid command operation mode (da6:umass-sim6:6:0:0): Unretryable error GEOM_MIRROR: Request failed (error=5), da6[READ(offset=512, length=512)] GEOM_MIRROR: Device gm-san: provider da6 disconnected. (da5:umass-sim5:5:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da5:umass-sim5:5:0:0): CAM Status: SCSI Status Error (da5:umass-sim5:5:0:0): SCSI Status: Check Condition (da5:umass-sim5:5:0:0): ILLEGAL REQUEST asc:20,0 (da5:umass-sim5:5:0:0): Invalid command operation mode (da5:umass-sim5:5:0:0): Unretryable error GEOM_JOURNAL: BIO_FLUSH not supported by mirror/gm-san. I waited for a few minutes with no change in the console. I then detached one of the USB drives (which happened to be da6) and saw this: umass6: at uhub7 port 4 (addr 4) disconnected (da6:umass-sim6:6:0:0): lost device Nothing else changed for a few minutes so I powered off the system. When I brought it back up the 320GB gmirror device was out of sync, but apart from that all devices were online. Below are the kernel messages from the second boot: 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 7.2-RELEASE #0: Fri May 1 08:49:13 UTC 2009 r...@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.26GHz (2266.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf49 Stepping = 9 Features=0xbfebfbff Features2=0x441d AMD Features2=0x1 real memory = 1877868544 (1790 MB) avail memory = 1826934784 (1742 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 6fde (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfe80-0xfe8003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xc000-0xcfff,0xfb00-0xfbff irq 16 at device 0.0 on pci1 pcib2: irq 27 at device 2.0 on pci0 pci2: on pcib2 pcib3: irq 31 at device 3.0 on pci0 pci3: on pcib3 atapci0: port 0xfc00-0xfc07,0xf800-0xf803,0xf400-0xf407,0xf000-0xf003,0xec00-0xec0f,0xe800-0xe8ff irq 21 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe400-0xe40f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xe000-0xe01f irq 20 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xdc00-0xdc1f irq 22 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd800-0xd81f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xd400-0xd41f irq 23 at device 16.3 on pci0 uhci3: [G
Re: Version nomenclature [was RELENG_7 to 8]
Hi, > STABLE and CURRENT could only point to two things and there were about > 10 potential tags involved. Tags... You say tags. Now, freebsd is an constantly evolving project. It's never finished. And when a branch is, it's EOL. It took me two minutes, back in 97 to get the grasp and at that time the security branch had yet to be introduced, before that I tracked 'stable'. Go figure. You know, that's the beauty of this project: it's 'nix, but different. I agree with you we should find a solution about all this name-bitching: let's encourage them to actualy READ the F. manual. Let's include it in the FAQ ! Or include some pointer in UPDATING for those that like to mess with source code. Or would you like to rename STABLE into UNSTABLE ? Or FIXED ? Or into the $next_upcoming_release_number-ALPHA ? Now that sounds appealing to newcomers not. I occaisionally run a STABLE box in production without any trouble, so it's name is what you get: great software, it's stable enough. We also inject new software releases into our ports collection. I never read anything about it's name scheme. Funny, but very relieving IMO. Cheers. Robert ___ 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: Version nomenclature [was RELENG_7 to 8]
In message , grarpamp (grarp...@gmail.com) wrote: [...] > > uname: '7.2-STABLE #0 ' isn't quite the same solid > reference as RELENG_7 as of yesterdays code. Which is what it is, > not the zero-eth 7.2 errata/security/stability commit. If you use SVN the revision number is included in the output of uname -a and uname -v. Cheers, Nick. -- ___ 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: Version nomenclature [was RELENG_7 to 8]
On Sat, 15 Aug 2009 01:48:27 -0400 grarpamp wrote: > Wanted to put in a suggestion. Users are constantly confused and > asking questions about the FreeBSD version naming scheme, somehow > not quite picking it up right, which is which, where to use it, > etc. > > And though I know what it is, it still seems silly to me. Because > we've got logical pointers _loosely_ correlating to formal repo tag > and branch names. Worst case I've seen was when FreeBSD had 4, 5, > 6 all in flux at once. STABLE and CURRENT could only point to two > things and there were about 10 potential tags involved. > > Basically, I'm proposing FreeBSD should relegate the terms STABLE > and CURRENT out to the marketing portion of the web team. You > can't check them out of any repo as tags, 4 and 5 were 'stable' when > 6 was 'current' and so on. > > CURRENT means nothing more than cvs HEAD or svn trunk or git . > So use those terms instead of leading people think they can check > out 'CURRENT' or that it has some magical command line, config file > or source properties. website: 'The latest snapshots from our > FreeBSD-STABLE and FreeBSD-CURRENT branches are also available'... > checking out those branch names gets you HEAD. There are references > to 7-STABLE, 8-CURRENT and parhaps other bastardizations on a theme > :-) in the handbook that are not valid tags. > > STABLE is pretty much the same way, only more confusing if more > than one thing is 'stable'. Back in the 4/5/6 days it could have > referred to any number of branches. And on the main page, we now > have more buzzwords... 'production' and 'legacy'. In fact, I'd > venture that the proper place for such words, > CURRENT/STABLE/production/legacy, is only on the release/download/support > related pages of the website, with little '->'s to the actual tag > they imply. More importanly, with descriptions that say something > like which trains are developed/supported when, for how long. ie: > why the deserve such words to be applied to them. > > Anyone who has a need to refer to CURRENT/STABLE is obviously getting > beyond the release iso's and into the cvs/svn/git level of things. > So just use the right terms then. Encourage people to use proper > tags and for reporting bugs and things. They could probably make it > into uname somehow. > > RELENG_x_y_RELEASE > RELENG_x_y [date/serial] > RELENG_x [date/serial] > HEAD/trunk [date/serial] > > uname: '7.2-STABLE #0 ' isn't quite the same solid > reference as RELENG_7 as of yesterdays code. Which is what it is, > not the zero-eth 7.2 errata/security/stability commit. > > And maybe figure out a way that each commit bumps a serial counter > in UPDATING or some stampfile or uname so people can report the > serial. Or maybe use the git crypto hash thing. FreeBSD needs a > crypto hash reference inside the primary source tree anyways, not > just on the n steps removed iso's. > > I dunno, just seen year after year of these questions on the lists :) > Thought I'd put at least something out there. Not meant to be a > bikeshed or anything. More like something to be addressed by doc > project or whatever. > Nice document. I believe a lot of people get confused by these situations due to a matter of not using CVS, SVN, etc... etc... and have never heard of tags and such before. While more people have heard of and used these in their own environment at one point and are not used to the scheme that FreeBSD uses. While at some point everyone should come across http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html not everyone has been pointed to it for reference. I feel this document states these very clearly and besides what else are you going to call the development trunk/tree for FreeBSD-STABLE & FreeBSD-CURRENT ? call them both trunk ?. This is really based upon a well defined method of development that is fairly easy to understand if pointed in the right direction. A key factor in the "what is RELENG_X" type of situation is a "Am I missing something ?, What branch am I running again ?, What branch should I pick ?" and a good answer to that is right in the handbook telling yo u what these are all about. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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"
