Date: Sat, 10 Apr 1999 00:19:07 +0200 (CEST) From: Wilko Bulte <wilko@yedi.iaf.nl> To: ken@plutotech.com (Kenneth D. Merry) Cc: freebsd-scsi@freebsd.org Subject: Re: Getting Pioneer CD changer to work Message-ID: <199904092219.AAA16594@yedi.iaf.nl> In-Reply-To: <199904092154.PAA18063@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 9, 1999 3:54:46 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > > Wilko Bulte wrote... > > > > As Kenneth D. Merry wrote ... > > > > > Wilko Bulte wrote... > > > > > > As Kenneth D. Merry wrote ... > > > > > > > Wilko Bulte wrote... > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > > > Wilko Bulte wrote... .... > > The boot messages are OK, so is the probe. I've diagnosed it as > > follows: > > > > - probes ok > > - works ok for some time (running my test script) > > - locks up it's own firmware > > - kernel throws away the devices associated with the changer, > > thus cddone 0x6 and 'no such device' errors for 'dd' > > Right, sounds familiar. > > > > Try increasing the minimum to 8 seconds and the maximum to 20: > > > > > > options "CHANGER_MIN_BUSY_SECONDS=8" > > > options "CHANGER_MAX_BUSY_SECONDS=20" > > > > > > I had similar problems with Lars Fredriksen's Nakamichi changer that I > > > borrowed to do the changer functionality in the CD driver. The default > > > timeouts may be a little too low, but I think they work okay for that sort > > > of changer at least. > > > > In this case it is not the changer. The lockup that happened with me > > present was during reads by two parallel operating 'dd's like: > > > > while : > > > > dd <bla> > > sleep 5 > > dd <bla> > > done > > > > So, the drive is seeking quite a bit (you can hear that, and observe it > > as the case is still off). My guess: the firmware looses track of the > > parallel I/Os going on. I'm retesting with a single 'dd' in the loop. > > I'm confused here. When you say "dd <bla>" above, do you mean that each dd > is going to a *separate* CD on the changer, or are you just reading with > two different processes from the same CD? (so the changer isn't switching > CDs) The two processes are reading from the same CD, so the changer is not doing anything. The drive's head is seeking a bit and in the end it (sometimes, not always takes the same time) locks up. > With the Nakamichi changer I had, I found that if it got pounded too often > to switch back and forth (i.e. with I/O going to a number of different LUNs > at the same time) it would eventually get confused and stop responding on > various LUNs. Another crappy firmware design apparantly. > If you increase the minimum timeout, it'll prevent that from happening. I can try that later/this weekend. Overnight I plan to have it do single stream reads using tar, then changing to the next cd, than single stream read etc. All in an endless loop. > > Right. It proved to be in my -current source tree alright. Apparantly it > > did not get installed by the 'installworld' for some reason ?? My testbox > > started off as a 2.2.6 CD install. Ah well, it is there now. camcontrol > > is happy. > > > > If we ever meet, I definitely owe you a couple of beers ;-) > > Coke (the kind that comes in red cans) would be preferrable. :) The true coke (in my book). Fine with me. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904092219.AAA16594>