Re: UDMA problems on ALI chipsets
It seems Dag-Erling Smorgrav wrote: > Is anybody working on getting UltraDMA to work on ALI chipsets? I have > a scratch box with that chipset and an UDMA disks and can test patches > and perform minor debugging if anyone needs me to. > > ide_pci0: irq 0 at > device 15.0 on pci0 Use the ata driver, it has support for the aladdin chipset, and it works... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: hot-swapping ata disks
It seems Iani Brankov wrote: [Charset koi8-r unsupported, filtering to ASCII...] > Hi, > I tried 'camcontrol rescan' and I found it works when I add a SCSI device > while > the system is on. I find it useful for adding/removing devices w/o restarting > the box. (Maybe it's risky, but useful. I supposed that's the idea of the > 'rescan' command in camcontrol) > > Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI > anyway). I have some experimental code that enables one to do this, but it is not without risk as the IDE channels are not designed for this. You also need to put the disk in a drawer that is able to shut off power etc so you dont burn any electronics while changing the drive. Once I get a little time I'll celan this up and make it available... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
It seems Dag-Erling Smorgrav wrote: > Jamie Howard (howar...@wam.umd.edu), with a little help from yours > truly, has written a BSD-licensed version of grep(1) which has all the > functionality of our current (GPLed) implementation, plus a little > more, in one seventh the source code and one fourth the binary code. > What's more, the code is actually possible for mere mortals to read > and understand. > > The source code is available for download from freefall: > > http://www.freebsd.org/~des/software/grep-0.7.tar.gz> > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. Go for it, the more GNU stuff we nuke the better :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Onstream?
It seems Vince Vielhaber wrote: > > Out of curiousity, have there been any successes in the drivers for > the OnStream tape drives (SCSI or IDE)? Working on it (for IDE that is), support is planned for, but I have no release date yet... I know that there is work done on the SCSI end too... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Please support FreeBSD 3.x as host OS]
It seems Assar Westerlund wrote: > Alfred Perlstein writes: > > I heard they have released the source to the kernel modules needed > > to run it. > > > > why not port them over? :) > > I started looking at the kernel modules and porting them, however, I > must confess that I don't fully understand exactly what the linux > kernel module does, which makes it somewhat harder to implement the > same functionality on FreeBSD :-) If you provide an URL to those files, I'd give them a look... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
It seems Biju Susmer wrote: > > OK, i went to net and got this page > > (http://www.mit.edu/afs/sipb.mit.edu/project/linux/docs/faq/AT > > API-FAQ) there > > also they say it should be MASTER. Problem is not with me. > > The vendor didn't > > follow the specs. PC never followd specs i think ;) > > > > Some one please put this in an FAQ (if it is not already > > said) to avoid any > > future problem? > > second thought.. I have not seen a PC with CD at any other configuration... > Cant > this config be supported? Many like me are not good in opening the box and > fixing the problem like other hackers. (But don't say i should not use FBSD > with > CD ;). any thoughts? This config is supported in the new ATA driver, but thats only in current. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare: porting kernel modules to FreeBSD
It seems Gary Jennejohn wrote: > Mark Huizer writes: > >Hi there, > > > >I had a look recently at the code for one of the kernel modules that VMWare > >requires (driver-only.tar), and it looks like something that should be > >portable to FreeBSD, although there is some messy stuff in it (assembly > >that seems to be using Linux specific stuff, brrr..) But anyway: it > >looks feasable. > > > >Is anyone already working on this, or are some people interested in > >helping with this? > > > >As far as I can see, the linux emulation is good enough to run the > >vmware program, "all" you need to do is implement /dev/vmmon and > >/dev/vmnet, given the fact that the code is written really unportable, > >so there is some rewriting to be done. Then with the KLD's > >vmmon,vmnet and linux you should be able to run vmware. > > > > Soren mentioned that he might look into it a few weeks ago, but that's the > last thing I remember seeing. Yup, I have the files here, and have given it a quick look, doesn't look to difficult to do, but I havn't had time yet to get into the matter.. It will probably be awhile before I do have the time though, but if nobody else does it I'll get to it sooner or later... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Seagate STT8000A (ATAPI/IDE) on FreeBSD? (fwd)
It seems David Krinsky wrote: > I posted this to -hardware a few days ago and haven't > gotten much in the way of feedback; since it sounds to me > like a driver bug this seems like an appropriate forum too. > > Is anyone here using -any- ATAPI drive for backup? Yup, I use one: ast0: tape drive at ata1 as slave ast0: Drive empty, readonly, reverse, qfa, ecc, 512b ast0: Max speed=600Kb/s, Transfer limit=52 blocks, Buffer size=728 blocks > When I try to tar up a usefully-sized directory or filesystem, > however, the drive will begin its work apparently correctly, but the > tar will exit with an I/O error at a variable point a few seconds to > minutes into the backup. The following goes to syslog: > > wst_done: wst0: nonrecovered data error I've seen this problem LOTS of times when using the old wd based atapi subsystem. I've never been able to find out why this is happening exactly. This was part of the reason I started out on the new ATA driver (only in -current now). I've never had this problem using the ATA driver, so I'm pretty sure its the old driver thats at fault, probably some delicate timing prob. Using the new driver I do routine backups every night on a couble of servers, not seen a signle problem yet... -Soren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Seagate STT8000A (ATAPI/IDE) on FreeBSD? (fwd)
It seems David Krinsky wrote: > > > Also, make sure that your drive is good. I had one I had to return > > because it was bad. Soren said the driver worked, and I could never > > get it working for me. The replacement worked like a charm. > > Well, it's brand-new, and I didn't get it at a garage sale. :-) > We know it's got a write head; I've succeeded at doing > backups and restores of small directory hierarchies, so I kind of > doubt it's the drive... What kindof chipset is your motherboard using ?? Are you overclocking ?? If not what is you PCI bus clock ?? I'm pretty sure this is the same problem that haunted me with the old driver, and if I'm not mistaken it is timing related.. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Moving bt848 driver to /sys/dev/bktr
It seems Roger Hardiman wrote: > Hi, > > I want to move the Bt848 driver to /sys/dev/bktr > > So, does anyone see any problems with this? Nope, go for it I'd say, and could we then have some of all the version text and stuff put away too, thats why we have CVS :) -Soren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Native Applixware for FreeBSD -- When?
It seems Chuck Robey wrote: > On Mon, 10 May 1999, Bob Willcox wrote: > > > > > Maybe I'll take a look at Word Perfect. Does it do Word documents? > > > > > > Mail me a Word document. I'm not sure, I'll have to try it. I don't do > > > any Windows here, I haven't any experience with Word (and never really > > > liked it last time I tried it, years back). > > > > Nor I, but unfortunately for some folks it seems to be the only editor > > they know. :-( > > > > I do occasionally get word documents and need a way to view/print them > > w/o using Windows. > > OK. *Somebody*, please mail me a Word document, then we'll know. Make > it a reasonably complicated one, but not a dictionary, please. If I > don't get a reply, then I'll figure there's no interest. I sure don't > care. FWIW all the word docs I've thrown at it has worked just dandy, mind that they where pretty simple text only docs though. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: modex support (again)
It seems Mike Smith wrote: > > To summarize, it seems like a lot of trouble just to get 40 additional > > scanlines and square pixels on obsolete hardware - anything that > > doesn't support 'options VESA' was already obsolete five years ago. > > Unfortunately, it's the trend these days to _not_ support anything at > all interesting in your VESA extensions. See eg. the nVidia Riva TNT > firmware. Endeed, they are going new ways allready, VESA support is an endangered animal half dead allready. We have to face it, the only way to use modern video HW is to have a driver that understands it. That is the exact problem, and why I'm very happy for the work the Xfree86 guys are doing. You can do mode-crap-of-the-day on some oldish and som newish HW, but whats the point ?? If you need a wierd resolution for a game or such, have the game set up the VGA regs, and be with it. Using graphics for much else is just retro-computing coming true :) (said the man that did our current video driver, and lots of graphics utils for it, including the minmalistic libvgl, and loved it). -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: modex support (again)
It seems Kelly Yancey wrote: > I think you just nailed the problem here. It requires a prohibitive > amount of effort to support modex video modes given the return. What I am > thinking about is removing the 320x240 mode (since it is impossibly > difficult to deal with)...no one is using it now so no one would be > affected. I would also like to add a comment into one of the source files > indicating why we have chosen not to support unchained VGA modes (ie. > "modex" modes) so that we can prevent this question from arising again in > the future. > On a slightly related note, I am currently in the process of developing > patches to add more useful "tweaked" modes to the video driver: > graphics 720x480, 16 colors (90x30 8x16 character cells) > graphics 256x256, 256 colors (32x32 8x8 character cells) > graphics 296x220, 256 colors (37x27 8x8 character cells) > text 90x25, 90x30, 90x43, 90x50, 90x60 > > The patches will also update vidcontrol to allow selecting any of the > modes. Excuse me, but those modes are even more wierd than modex, either we stick to the std modes, or we'll bloat the driver beyond repair, what I'm stricktly against. All those wacky modes should be set from a module or some such, they have NOTHING to do in the kernel pr default. This isn't Linux guys... (sorry couldn't help that one)... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: modex support (again)
It seems Kelly Yancey wrote: > > I admit that they are less common than say 320x240 mode x...but they are > linear and don't require any hacking to support from applications which > would use graphics modes (unlike the unchained "modex" modes). > I absolutely agree that we should keep the kernel as lean as > possible. And I would *love* to put the modes into a module (that was my > original plan)...but to do that, I need get_mode_param to be extern'ed > from vga_isa.c so that the module can access the BIOS mode table (or else > re-implement the code in vga_isa.c to access the mode table). All I am > looking for is the OK to make that routine extern in my patches and I'll > make a module. My biggest concern is that get_mode_param is obviously > considered an internal API and thus subject to change...change which would > then break my KLD. :( > With a module, I would suggest moving the implemention of the 320x240 > modex mode there also (or else remove it altogether...but with a module, > removing it would be unnessicary). And with a module, there would be no > harm in implementing the other 6 modex modes (320x400, 320x480, 360x200, > 360x240, 360x400, 360x480). > If I can get past the get_mode_param hangup, then there would be no > reason no to implement 2 KLD's: one for the tweaked video modes and one > for the 90-column text modes. Hmm, I see no problem in publicising get_mode_param, the only thing is that it might change over time, but thats another matter... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Problems with ALI chipset
It seems Andrij Korud wrote: >Hi, can you help me with problem with Aladdin V chipset and UDMA. >Here is my dmesg when UDMA in bios is off: >[snip snap] >wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa >wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 >wd0: 4892MB (10018890 sectors), 10602 cyls, 15 heads, 63 S/T, 512 B/S > >and all is working fine. When I turn on UDMA, i got messages >saying something like "irq timeout (DMA active)", sometimes it tell >"probable a portable system" and even "Last time I say: irq timeout" >And system does not working. Hmm, you could try the new "ata" driver instead that does work in UDMA mode on the ALI chipset. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: devstat_end_transaction: HELP!! busy_count for wd0 < 0 (-1)
It seems Dag-Erling Smorgrav wrote: > Dag-Erling Smorgrav writes: > > Dag-Erling Smorgrav writes: > > > Dag-Erling Smorgrav writes: > > > > Dag-Erling Smorgrav writes: > > > > > I'm getting tons of these in an IDE-only box. They started appearing > > > > > after I put in an IBM DTTA371010 to replace the old (and dying) > > > > > Quantum Fireball ST. > > > > Following up on myself, the box just panicked (softdep_write_complete: > > > > lock held). > > > Following up on myself again, a May 4 kernel (with the exact same > > > configuration) works fine and dandy. The problems only show up with a > > > June 3 kernel. > > Argh! I forgot to mention - this is a RELENG_3 box. > > I hang my head in shame; the June 3 kernel was compiled from the wrong > config file. All's well :) OK, just admit that you like talking to yourself :) Thats mostly harmless, but when you start hearing answering voices you should seek professional help, fast :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: wfd.c and ATAPI Zip
It seems Chris D. Faulhaber wrote: > > I have an off-brand (NEC) Zip Drive with: > > which does have buggy firmware; I also have another one with: > > that has no problem when I remove the 64 block limitation. > > In this case, I would use strncmp instead of strcmp to test the first 27 > characters. > > So what you are saying is that we are limiting all Zip drives instead of > being based solely on firmware revision? Any reason for that? Hmm, well in the atapi-fd driver in the new ata/atapi system I only check for !strncmp(atp->atapi_parm->model, "IOMEGA ZIP", 11) which is even more pessimistic. However the overhead added here is small compared to the general speed of the ZIP drive, so its not a problem. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: High syscall overhead?
It seems Christopher R. Bowman wrote: [exelent explanation snipped] > The alternative to the Giant Kernel Lock(tm) is so called fine grained locking > wherein locking is pushed down closer to the data structures. In fine grained > locking two processors might be executing in the kernel at the same time, but > only if they didn't need the same resources. On might be doing a disk read > while the other queues up a character for the serial port. The fine grained > lock has the potential for higher parallelism and thus better throughput since > process may not have to wait as long, but the larger number of locks with > their > many required lock and unlock operations add overhead and further the design > is > more difficult and error prone since the interaction of the numerous locks may > result in deadlock or livelock situations every bit as problematical as the > problem they try to solve. There are also those of us that dont belive in finegrained locking, exactly because of all the small locks you have to check/lock/open, the overhead is not worth it. I think a model where locks placed around resonably sized subsystems is the way to go, and can be made much easier to understand and free from (too many) bugs. I did some experiments some time ago with locks around each devicedriver, the netsubsystem, the vmsubsystem, the filesubsystem and the rest, and it performed admirably. Unfortunately I lost all that work due to "unforeseen physical happenings", but is was not that big a deal to do... I think we should consider it very carefully before going the finegrained lock route, it really doesn't give you that much in real world situations. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: High syscall overhead?
It seems Arun Sharma wrote: > An alternative way, which requires a good understanding of both the > theory and implementation of the kernel is - > > (a) Implement per subsystem locking This was exactly what I experimented with some 7-8 month ago, it showed significant improvements in performance, yet it was relatively easy to do. > (b) Figure out in a "typical" workload, how much time is being spent > in which subsystem and try increasing parallelism (i.e. finer > grained locking) in subsystems where more time is being spent. Well, my simple tests showed no need for this, again its a fine balance between spending the time waiting, and spending the time processing locks. > The result of this approach should be more logical, cleaner and > possibly better performing than the previous one. It sure is easier to understand and to maintain. Maybe I should try it again, and this time keep off-site backups :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ZD labs test update
It seems Tommy Hallgren wrote: > --- Mike Smith wrote: > > We'd previously encountered problems with the Infortrend controller not > > at all liking the other disks we'd tried to talk to; a collection of > > Cheetahs with IBM and Compaq firmware simply wouldn't work. This time > > we had better luck with real Seagate firmware, and the array > > performance wasn't too shabby, giving us ~8MB/sec write performance and > > ~16MB/sec read performance using the dd-stone benchmark. > > Isn't 16MB/s quite bad for this kind of system? It does compare badly to my little ATA system which does the dd-stone at ~13MB write / ~17Mb read, for a fraction of the cost :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Beware of UnixWare 7
It seems Greg Lehey wrote: > FreeBSD, which has the partition number explicitly in the device name. > In my case, FreeBSD was on partition 2, devices /dev/rwd0s2a and > /dev/rwd0s2e. It was moved to partition 3, so the device names > changed to devices /dev/rwd0s3a and /dev/rwd0s3e. Since I didn't have > device nodes for these devices, I was unable to remount the root file > system, and I had to use the fixit floppy to rewrite the partition > table. Nothing got lost, but it was a real pain. Thats the reason why I always use /dev/rwd0a etc, ie without the slicenumbers in it, that way it will always use the FreeBSD slice no matter what number is has gotten. Of cause that only works if you only have one FreeBSD slice, but that is most normal I guess... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CDROM drive doesn't probe if no CD present [Was:cannot mount cd indicates bad ide cd drive - replace?]
It seems Doug White wrote: > I'm lofting this up on -hackers to get the attention of the ATAPI CD > driver programmer -- Soren, you still around? Take a look at this. I'm here alright :) Sounds like the drive has a firmwarebug, If you are running -current try the ata driver instead, and let me know how that turns out... -Søren > On Tue, 22 Jun 1999, Woody Carey wrote: > > > Ok, here is some more information: > > > > Here is the behavior when there is no cd in the drive at bootup [reboot, > > actually] > > ^M^[[Kmyname# mount /cdrom > > cd9660: Input/output error > > myname# dmesg > > [...] > > > wdc0: unit 1 (atapi): , removable, accel, dma, iordy > > acd0: drive speed 0 - 4125KB/sec, 128KB cache > > acd0: supported read types: CD-R, CD-RW, CD-DA > > acd0: Audio: play, 255 volume levels > > acd0: Mechanism: ejectable tray > > acd0: Medium: no/blank disc inside, unlocked > > > and here is the dmesg output and mount output with a cd in the drive at > > boot: > > > > myname# dmesg > [...] > > wdc0: unit 1 (atapi): , removable, accel, dma, iordy > > acd0: drive speed 4125KB/sec, 128KB cache > > acd0: supported read types: CD-R, CD-RW, CD-DA > > acd0: Audio: play, 255 volume levels > > acd0: Mechanism: ejectable tray > > acd0: Medium: CD-ROM 120mm data disc loaded, unlocked > > > myname# mount /cdrom > > > > There was some success message on the console after this mount > > indicating success. > > It did not appear in this script output, obviously. > > Bizarre. That may be a driver bug or your drive is getting into an > inconsistent state if it doesn't boot with a CD present. > > What brand/model of CD drive is it? > > Doug White > Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve > http://gladstone.uoregon.edu/~dwhite| www.freebsd.org > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
It seems Wes Peters wrote: > Tim Vanderhoek wrote: > > > > On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > > > > > read a bit about them. Same for the committers group, but at 165+ > > > members that's going to be a somewhat larger, long-term project. :-) > > > > Did Wes Peters finish his collection of committer ICBMNet lat/long > > co-ordinates? > > Here's what I have so far: > 55.4, 11.3, "phk, sos" # Denmark That should be: 55.4, 11.3, "phk" # Denmark 57.2, 10.2, "sos" # Denmark We dont live THAT close together :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
It seems David Greenman wrote: > >> > A constant 5 o'clock shadow, maybe, but not a beard. > >> > >> And what's wrong with a beard? > > > >Nothing. I just remember someone pointing out in a previous e-mail that > >all the core members had some sort of beard. > >Very few core members have beards, so whoever said that was wrong. Nah, are you sure ?? I havn't shaved in over a decade :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE CDRW
It seems Eugene M. Kim wrote: > One more similar question: Does/will FreeBSD support ATAPI CD-R(W) > drives in disk-at-once mode, perhaps using burncd(1)? I wanted to burn > some audio CDs in that manner but burncd on 4-stable didn't support DAO > writing. I'm working on it, but currently I have little time to spend on it though... -Søren "MrATA" Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: hotplug ata device?
It seems Wilko Bulte wrote: > Hi > > I'm looking for ideas on the following: > > I just added a CF-ata adapter to my system (see http://www.tapr.org). > This works just fine, as long as the card is in the socket during boot. > For obvious reasons this is not always the case. If it was not seen during > boot one gets: > > freebie#mount /flash > msdos: /dev/ad0: Device not configured > > Which I can understand (but don't appreciate in this case ;-) > > Is it possible to have something like the 'camcontrol rescan' that > the SCSI CAM subsystem has? Yes, I've already done that, but it needs alot of polishing before it goes into the public sources, plus an atacontrol util... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ata-disk ioctl and atactl patch
It seems Scott Renfro wrote:
> As I promised on -mobile earlier this week, I've cleaned up my patches
> to port the {Net,Open}BSD atactl utility, including a simplistic
> ata-disk ioctl. They apply cleanly against this afternoon's -stable
> (including Soren's latest commit bringing -stable up to date with
> -current). I've been running them for some time and they ''work great
> here''.
>
> Before announcing this in a broader context, I wanted to get a bit of
> feedback on the ioctl implementation. In particular, is it safe to
> just do an ata_command inside adioctl() without any further checking?
> (e.g., can this cause bad things to happen under heavy i/o load?)
No its not safe at all, you risk trashing an already running command...
Anyhow, I have an atacontrol thingy in the works for attach/detach,
raid control etc, etc, I'll try to merge this functionality into that
(the ioctl's will change etc, but the functionality is nice)...
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ata-disk ioctl and atactl patch
It seems Stephen Rose wrote:
> A couple of us on the questions list have asked for a way to spin down ide
> disks when idle. Is there any chance that this utility could lead to
> something useful there?
Well, of cause it could, but I'm not sure I see the usefullness of
the spindown at all, a spinup costs several units of idleness power,
so you have to keep it spun down for long periods to make it worth
the effort, and you wear significantly more on the mechanics this
way too...
> It seems Scott Renfro wrote:
> > As I promised on -mobile earlier this week, I've cleaned up my patches
> > to port the {Net,Open}BSD atactl utility, including a simplistic
> > ata-disk ioctl. They apply cleanly against this afternoon's -stable
> > (including Soren's latest commit bringing -stable up to date with
> > -current). I've been running them for some time and they ''work great
> > here''.
> >
> > Before announcing this in a broader context, I wanted to get a bit of
> > feedback on the ioctl implementation. In particular, is it safe to
> > just do an ata_command inside adioctl() without any further checking?
> > (e.g., can this cause bad things to happen under heavy i/o load?)
>
> No its not safe at all, you risk trashing an already running command...
>
> Anyhow, I have an atacontrol thingy in the works for attach/detach,
> raid control etc, etc, I'll try to merge this functionality into that
> (the ioctl's will change etc, but the functionality is nice)...
>
> -S?ren
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
> ---
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
It seems Bill Paul wrote: > "But Bill, you work for BSDi now. Can't they get you manuals?" Working for > BSDi is irrelevant: I can't sign any NDAs if I want to release driver > source, and I do want to release the source. And there isn't a designated > person at BSDi that I can turn to to help turn up the heat on recalcitrant > vendors. I'm not willing to go sneaking around and mooching these things > from secret sources since it just perpetuates the officially sanctioned > vendor stupidity. I don't want to have meetings, negotiations or "strategic > partnerships," I just want the stupid programming manuals without NDAs. I hear you! I have the same problems getting ATA controller/device docs out of the vendors, but sometimes it helps trying from another angle. One example is Promise, I mailed and phoned them for about a year, and got exactly nothing back, but it took Jeroen (Asmodai) one mail to get thier attention AND docs (thanks!), the morale being that sometimes it helps getting other people involved. Please understand that I dont mean that everybody and his dog should be mail bombing a vendor to get docs, that we leave for the other guys :)... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix panic when detaching a mounted md device
It seems Warner Losh wrote: > In message <8773.984501263@critter> Poul-Henning Kamp writes: > : >We should then fix the rest of the system to deal with disks that > : >disappear without notice. > : > : That was the point yes :-) > > Cool. When this happens, the forgetful ata flash ejectors of the > world will be happy :-) The next commit to the ATA driver will take care off this, either by the user doing 'atacontrol detach dev' or by the timeout code discovering that a divice went missing and proberly fail all the outstanding bio requests.. This all needed the patch to subr_disk.c that I made earlier today, but now we can actually do it, however some of the cleanup action should be done by the higher levels and not by the device driver... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix panic when detaching a mounted md device
It seems Warner Losh wrote: > In message <[EMAIL PROTECTED]> Soren Schmidt writes: > : This all needed the patch to subr_disk.c that I made earlier today, > : but now we can actually do it, however some of the cleanup action > : should be done by the higher levels and not by the device driver... > > Most of the crashes I've seen are in the higher levels... Where ? I havn't seen any here for quite some time... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI-over-* hacks
It seems Thomas Quinot wrote: > Le 2001-03-21, Mike Smith écrivait : > > > > Has anyone implemented/thought of implementing: > > > - a CAM transport for ATAPI devices; > > Yes. It's not a lot of work. > > Ah, interesting! Do you know if any source code is publicly available? What do you want it for actually ? I've played with it lng ago and tossed it due to performance and loss of features compared to the ATAPI subsystem... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI-over-* hacks
It seems Thomas Quinot wrote: > Le 2001-03-21, Soren Schmidt écrivait : > > > > > > - a CAM transport for ATAPI devices; > > > What do you want it for actually ? > > It is a possible solution for me to be able to use cdparanoia and cdrdao > with my ATAPI CD drive. An alternative solution would be to implement > an atapi-cd ioctl to send a raw command to an ATAPI device, and make > libscg use that. Exactly, I coule dream up an API for that shoving ATAPI commands into the ATA driver, that would make at least some sense... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCSI-over-* hacks
It seems Mike Smith wrote: > > > It is a possible solution for me to be able to use cdparanoia and cdrdao > > > with my ATAPI CD drive. An alternative solution would be to implement > > > an atapi-cd ioctl to send a raw command to an ATAPI device, and make > > > libscg use that. > > > > Exactly, I coule dream up an API for that shoving ATAPI commands into > > the ATA driver, that would make at least some sense... > > As long as you can make it work for ATA commands as well, this would let > us port/whatever the 'hdparm' tool as well, which would make a lot of > people happy. What does hdparm do ? set modes and stuff right ? thats atacontrols job. I'll think up an API for getting ATAPI commands through, thats actually quite easy, we just have to get it right first time... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: crash dump speed up patch.
It seems Gersh wrote: > Ive writen a quick patch for dev/ata/ata-disk.c:addump under > 4.0-stable (03/26/01) which is considerbally faster. > > I did dumps on a SMP system with 512 megs of ram. > > Old: 201 seconds. > New: 59 seconds. > > What I could gather from talking to people over irc/email about the > problem was that there was a DELAY(1000) in between each printf > to deal with problems with serial connections to the debugger. The > soultion I came up with simply to display a smaller ammount of printf's > the output looks like this: > > Any thoughts or comments ? Thats not the only reason that DEALY(1000) is there, its to cope with older disks that has problems when we get too fast here... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wd & ata
It seems BSD Blood wrote: > Hello. >I'm using FreeBSD 4.1. My kernel contains the ata driver for the IDE > controllers. I understand that the ata driver has replaced the wd driver. My > question is:- > > 1. Are there any / Do I need to use certain flags to enable LBA, DMA, etc. > features like for the wd driver? Or is this done automatically by the ata > driver? The ATA driver tries to use the highest performance level your ATA hardware claims to support. ATAPI device DMA has to be explicitly enabled since alot of those fail, man ata.4. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum and superblocks.
It seems Jaye Mathisen wrote: > Not sure what the right thing to do here is, or even if it's a real > problem, but: > > I have 8 75GB IBM drives striped in a big raid 0 for monkeying with. > > newfs -i 131072 -v /dev/vinum/bighonkindisk seems to very nicely put all > the data that newfs write out on to the first disk... It least, only the > first disk gets any io, accoring to systat and iostat. > > Which would seem to me to be problematic in terms of using fsck -b, and > also just for the fact that it would seem that you would have to hit that > disk more often than the others, even though it's striped. > > I realize there's no protection with the raid 0, but the load doesn't seem > evenly distributed on a transaction basis, even though the data is evenly > spread. > > What's the right thing to do here? You need to adjust your stripe size so that the superblocks etc are not all put on the same disk, ie some odd stripe size is often best to distribute those to hopefully all disks... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDF (DVD fs)
It seems Coleman Kane wrote: > Hello, is anyone currently working on code to implement the UDF > filesystem? For those not familiar with it, it is the filesystem that > DVDs use. I'd like to look into getting the support under FreeBSD, since > the players already seem to work. If no one is working on this, then I > could probably use some help in writing the code to support this fs. I think Julian Elischer is working on UDF.. However to play/read/use DVD's you dont need UDF, they are also readable as an ISO9660, but that might change in the future... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDF (DVD fs)
It seems Julian Elischer wrote: > I am working on UDF support. > I have at present a program that reads a udf filesystem > and am working (today) on making it into an "mtools" like > program that allows access to the contents in a useful manner. > > I will eventually turn this into a (readonly) filesystem, and it > is designed with that in mind (it uses a buffer cache etc, like > the kernel. (in other words I'm prototyping). > > I will at some stage also try make a UDF creation module for mkisofs > as well. Uhm, the real value of UDF is that it can be used as a "real" rw filesystem on CDRW/DVDRAM media, if this is not implemented the value of having UDF is very limited IMHO > In the meanwhile you should be able to mount most modern DVDs using > the ISO9660 filesystem as they should be "bridge" format, (in which > there is metadata for both types of filesystems). Endeed, makeing a ro UDF filesystem more or less useless :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATA100-7200rpm vs 10k-rpm SCSI for build box
It seems Thomas Stromberg wrote: > > $--- 128M PC133 RAM > $150 Asus A7V (w/ Promise ATA100 controller) > $297 AMD Athlon 850 (still waiting for than price drop) > $63 Tekram 390F UW-SCSI Controller (Symbios) > $132 4.5G 1RPM Seagate Cheetah > or > $97 IBM Deskstar 75GXP ATA-100 7200RPM 15G (DTLA) > > The question is, whats the real speed difference between a IBM 75GX > (http://www.tweakmax.com/html/ibm75gxp/ibm-1.cfm) and ye old 1RPM > Cheetahs in FreeBSD? Id imagine the Cheetah is faster for compiles, but > is the difference small enough that Id be better off spending the $100 I > save on ATA100 and spend it on another 128M of RAM. I would of course be > using the drive as one drive per channel w/ softupdates, noatime. > > Any advice, bonnie stats, or make world times would be appreciated. Hmm, I have an Abit KA7-100 (thanks to Trent George!) here with IBM 75GXP drives on it (btw the KA7-100 is a VERY nice board) so I will give it a shot on bonnie and world later today to give you some numbers. I would go for the ATA setup and extra RAM but I'm biased :) PS I have ATA100 support for the HPT370 used on the KA7-100 running, but I haven't gotten to the Promise Ultra100 lying here next to me yet, watch -current for updates on it... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: EIDE Problems - fsbn read error
It seems Lew payne wrote: > > One of our new FreeBSD 3.5-REL systems is periodically locking up, > due to an apparent disk error. These are brand-new IBM 7200 RPM > 60 GB ATA/66 EIDE drives, in a ccd configuration as follows: > > Filesystem 1K-blocks UsedAvail Capacity Mounted on > /dev/da0s1a 79359203575265428%/ > /dev/da0s1f 8025325 1023010 636028914%/usr > /dev/da0s1e119055 3401 106130 3%/var > procfs 440 100%/proc > /dev/ccd0c 239854317 127105965 9356000758%/spool > > cat /etc/ccd.conf > # ccd ileave flags component devices > ccd0 128none /dev/wd0s1e /dev/wd2s1e /dev/wd1s1e /dev/wd3s1e > > and the error message (which repeats infinitely) is: > > Jul 31 01:02:06 news /kernel: wd0s1e: soft error reading fsbn 81057521 > of 81057520-81057551 (wd0s1 bn 81057521; cn 64331 tn 7 sn 20) > (status 58 error 1) > Jul 31 01:02:16 news /kernel: wd0s1e: soft error reading fsbn 81057521 > of 81057520-81057551 (wd0s1 bn 81057521; cn 64331 tn 7 sn 20) > (status 58 error 1) > > The system just gets stuck doing this seek over and over again, at > which point it becomes impossible to log in via the console, or do > anything else (I/O bound). > > Is there a trick to getting soft-recovery working with EIDE devices? > Better yet, how can I get rid of this problem without getting rid of > the new drives? It seems that it sits there trying to recover from > this "soft error" but never does, and never maps it in the replacement > block table as "bad". > > Is there a way to "reformat" the drive (low level, perhaps) so that > it maps out the appropriate replacement table for the darn fsbn? Or > how about a way of adding bad blocks to it? > > Any help in solving this would be appreciated !! Upgrade to 4.0 or better yet 4.1, the new ATA drivers there has better error recovery... Oh, and there is no idea in reformatting a modern ATA/IDE drive, if they have bad sectors they have used up all their spares, and should be retired asap... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: In-kernel ioctl calls
It seems Theo van Klaveren wrote: > > I think I've finally figured out why AudioFS isn't working (aside from an > endianess error in v0.1), but I can't think of a solution. The problem I've > found is as follows: The code in atapi-cd.c (from Soren's ATA driver) > assumes the passed buffer (in the ioctl struct) is in user-space. The > following is the offending piece of code from the CDIOCREADAUDIO ioctl call: > > --- snip --- > if ((error = atapi_queue_cmd(cdp->atp, ccb, buffer, size, > ATPR_F_READ, 30, NULL,NULL))) > break; > > if ((error = copyout(buffer, ubuf, size))) > break; > --- snip --- > > The first statement issues the read command to the device, I presume. It > copies the data to an internal (kernel-space) buffer. Next, the internal > buffer is copyout()ed to ubuf (which is my ioctl buffer), which fails > because in the case of AudioFS it's in kernel space. > > Boing, break, abort, no data for you. Bad boy. > > This, of course, caused the buffer's data not to be initialized, causing > noise and crackles. And AudioFS didn't know the ioctl call failed, because > the driver didn't return an error. > > Am I just doing it wrong, or should atapi-cd.c be patched to verify if the > buffer is in user space or in kernel space? If so, what function checks if > an address is in kernel space or in user space? If not, what am I doing > wrong? Here's another idea, the ata driver can read/write 2352 sector size blocks directly, no need to use that ugly ioctl. You just have to set the right blocksize, I could provide you with a function for that, no more ioctl mess ;) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: In-kernel ioctl calls
It seems Theo van Klaveren wrote: > | Here's another idea, the ata driver can read/write 2352 sector size > | blocks directly, no need to use that ugly ioctl. You just have to > | set the right blocksize, I could provide you with a function for > | that, no more ioctl mess ;) > > That would be _greatly_ appreciated! The question is, would this be > 'portable' to other drivers? In other words, how much trouble would it cost > me to get AudioFS to work with SCSI? I dont think the SCSI/CAM system can cope with != % 512 byte blocks, so you are out of luck there, but then again SCSI/CAM doesnt support CDIOCREADAUDIO either, so you are not worse of than now :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: audiofs mixing audio and data tracks
It seems Koster, K.J. wrote: > > > > I can't think of any way of accomplishing this without > > either: > > 1) Combining the code for AudioFS and CD9660, as both > > require access to the mounted device, and hacking them > > to respect each other, or > > 2) Hacking the ATAPI-CD and SCSI-CD drivers to bits and > > teaching them about the various regions on the CD. > > > I'm a little surprised that the functionality of accessing a track on a > digital storage medium and doing stuff like getting a directory listing out > of a track are in the same chunk of code. I lived under the impression that > there were some layers of abstraction between those two. > > I guess not. I learn a little every day. Ahem, maybe its time I chime in here. Luigi and I once had an idea of having each track on a CD represented by a device node, ie track0 = /dev/acd0t1 track1 = /dev/acd0t2 etc etc, that way you could mount each track with whatever fs it supported. This could be used to do what you want, and now where the ata driver supports odd sector sizes, there is nothing hindering doing the mount of an audio track (given the right mount_bla util that is). The only problem is that we have to abuse the minor# etc to get space for the 99 tracks a CD can hold, but that is not too bad... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: audiofs mixing audio and data tracks
It seems Koster, K.J. wrote: > > > > that way you could mount each track with whatever fs it > > supported. > > > Same thing as I proposed, I guess. > > Am I right in thinking that a cdrom can have at most one data track? In that > case, I'd suggest assighing that track a standard device node. That way I > could just mount the data track of a cdrom, without worrying if that's track > 4 or track 1. Mostly yes, but there is nothing hindering multiple data tracks on the same CD. At any rate we only have access to one now anyways so that wouldn't hurt anything :) I'll look into it again, it could be a "very nice thing to have" (tm), imagine ripping audio just by dd if=/dev/acd0ct4 of=title4.raw bs=2352 well that kindof works already ;) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: audiofs mixing audio and data tracks
It seems Tony Finch wrote: > Soren Schmidt <[EMAIL PROTECTED]> wrote: > >It seems Koster, K.J. wrote: > >> > >> Am I right in thinking that a cdrom can have at most one data track? In that > >> case, I'd suggest assighing that track a standard device node. That way I > >> could just mount the data track of a cdrom, without worrying if that's track > >> 4 or track 1. > > > >Mostly yes, but there is nothing hindering multiple data tracks on > >the same CD. At any rate we only have access to one now anyways so > >that wouldn't hurt anything :) > > How does this relate to multi-session CDs? Does that happen at a lower layer? Same thing, we always uses the last session written (which can include parts from earlier written sessions), so the first track on the last session will be the default track you get on /dev/acdN[ac] just as it is now. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: audiofs mixing audio and data tracks
It seems Theo van Klaveren wrote: > | Ahem, maybe its time I chime in here. > | Luigi and I once had an idea of having each track on a CD represented > | by a device node, ie track0 = /dev/acd0t1 track1 = /dev/acd0t2 etc etc, > | that way you could mount each track with whatever fs it supported. > | This could be used to do what you want, and now where the ata driver > | supports odd sector sizes, there is nothing hindering doing the > | mount of an audio track (given the right mount_bla util that is). > > I stand corrected. I hadn't thought the ATA driver was so close to doing > that already. Then again, I haven't extensively studied the ATA code yet. :) > | The only problem is that we have to abuse the minor# etc to > | get space for the 99 tracks a CD can hold, but that is not too bad... > > Tracks, as in audio tracks? You wouldn't want a device for each audio track, > you want one device for _all_ audio tracks and one device per data track. Or > am I misunderstanding you here? Well, the idea is that you get one device pr CD track, that way you can do what you want with them, ie to rip audio track 4 you do: dd if=/dev/acdNt4 of=track4.raw bs=2352 To mount data track5 with an ISO filesys: mount -t cd9660 /dev/acdNt5 /cdrom If you want to collect all audio tracks together you would just use the normal /dev/acd0c device, read the TOC of the CD so you know where they are, set the right blocksize, and there you go (that works now BTW). -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cheap 1000Gbyte machine
It seems Jonathan Laventhol wrote: > Hello Folks -- > > Anybody built a file server with approx 1000 Gbyte or more? Not yet :) > Or even 200 Gbyte? Yup, 300G's standing here right next to me... > I'm looking for a cheap simple way of doing this. Lots of > IDE drives? (How many can you have?) Or SCSI? (Again, > how many can you have?). Take 3 or 4 Promise Ultra66/100's and 14 IBM 75G DTLA 307075 drives and you should be in business, for a very resonable pricetag. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cheap 1000Gbyte machine
It seems Matthew Jacob wrote: > On Fri, 18 Aug 2000, Soren Schmidt wrote: > > > It seems Jonathan Laventhol wrote: > > > Hello Folks -- > > > > > > Anybody built a file server with approx 1000 Gbyte or more? > > > > Not yet :) > > That's not quite true. We had ~900GB on a NetBSD/Alpha machine at NASA/Ames. Oh, I mean I havn't build one yet :) > > > Or even 200 Gbyte? > > > > Yup, 300G's standing here right next to me... > > > > > I'm looking for a cheap simple way of doing this. Lots of > > > IDE drives? (How many can you have?) Or SCSI? (Again, > > > how many can you have?). > > > > Take 3 or 4 Promise Ultra66/100's and 14 IBM 75G DTLA 307075 > > drives and you should be in business, for a very resonable > > pricetag. > > You know, I used to say ixnay on that, but, Soren, I've been looking at a lot > of the features of the newer ATA drives, and now that they have bad block > replacement, I'd have to say that what you're proposing is not unreasonable, > although I'd suggest that Vinum/RAID5 be used. Nice to hear, and yes vinum is the way to go for redundancy, who is going to backup THAT amount of data, and on what :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cheap 1000Gbyte machine
It seems Parag Patel wrote: > On Fri, 18 Aug 2000 15:57:48 EDT, Robert Sexton wrote: > > > >Can IDE drives release the bus during seeks? Historically thats been > >the big advantage of SCSI: Two IDE drives are no faster than one IDE > >drive, while SCSI scales in performance. > > How about a single IDE (master) drive per controller, that is, no slave > drives at all? This would halve the number of available drives per card > (or require twice the number of cards) but essentially would use the PCI > bus as a multiplex bus between drives instead of SCSI. > > You're still pretty much stuck waiting for one command to finish before > another can be sent to a drive though, unlike SCSI drives. Still a lot > cheaper tho'. Not really, if the ATA drives are configured as single masters, they can run simultaniously, but you will still have the PCI bus speed limit :) Which BTW is around 120MB/s as some overhead goes to keep the system running (yes I have measured that :) ) And if you have modern ATA disks, they support tagged queuing as well, have had that running in my lab too... > I suppose another trick would be to arrange your vinum partitions and > drive layout so that master and slave drives are never accessed > simultaneously so one won't block access to the other. Endeed, that would be the easiest solution... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microtime acting up again
It seems Koster, K.J. wrote: You should disable APM and not have it in your kernel either, that fixed it for me on my Abit KA7... > Last night my machine drowned in "microtime going backwards" errors. It was > there when I installed FreeBSD 4.0-release, and it went away when I cvsupped > to -stable immediately after. However, it is back again. > > My box is an AMD Athlon on an Asus k7v motherboard. I had cvsupped to > 4.1-stable this monday night. I was dialed into my ISP, when my machine > became sluggish. The console was spitting "microtime going backward" > messages as fast as my video board would allow. > > Under the flood I was able to shut down most applications and type "reboot" > in a root shell I happened to have open. The machine came back up, but my > mouse (logitech cordless) was crippled and spitting out psmintr out of sync > errors at me. An hour of power off eventually cured the problem. > > Anyone on this list who can explain what this microtime problem is about? > > I used to be able to reproduce it by running bonnie on my disks. I might do > that again this weekend, if I find the time. > > Kees Jan > > = > TV is the worst of both worlds. It's not as > good at words as radio is because the pictures > are a distraction which demand attention, and > it's not as good as cinema because the pictures > are not nearly as good. [Douglas Adams] > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Tagged queuing for ATA drives, patches up for testing
Hi! I've put the latest patches for tagged queueing on ATA disks up for ftp on: ftp://freebsd.dk/pub/ATA/ATA-tagged-queueing-diff-0831.gz This is a snapshot from one of my working tree's and other minor fixes are also included, but thats another story... >From the README: Experimental support for tagged queing on ATA disks that supports it. (IBM drives and some WD drives that are rebadged IBM's). This code only works on drives sitting alone on an ATA channel, and should work on all controllers. Support for master/slave combinations, and ATA/ATAPI ditto is being worked on, but this requires a controller with support for the "auto nop" functionality. Which of the many different controllers supports this is unknown at this time, but HPT controllers has the needed functionality, and should be a safe bet. It seems that the DJNA series of IBM disks has some problems with tagged queueing, but at least the DPTA and DTLA series are known to work. The older DTTA series has not been tested yet. The test runs so far indicates a 3% performance gain on a make -j16 world, with a 30% reduction in system time, not too bad for a first shot. Enjoy and let me know of your findings! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Promise PDC20265
It seems Esko Petteri Matinsola wrote: > Hello, I have Asus A7V motherboard that has integrated UDMA100-controller > PDC20265 made by Promise and Maxtor 54098H8 hard disk. > > When plugged to the UDMA66-controller the Maxtor works properly, boots and > is fast. But when plugged to the PDC20265 BIOS detects it, kernel boots > but don't detect the controller nor the disk so it complains about root > not found. > > I checked the ata driver (I have 4.1-STABLE by yesterday) and it has > support for Promise 100 (I presume it's PDC20265) but it doesn't work ? > > Any suggestions will be appreciated. I have it in my local tree, it should go in soon... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
New ATA tagged queuing patch available
>From the README: ATA-tagged-queueing-diff-0908: Add support for ATA channels with both a master and a slave, even combos where only on of them supports tagged queuing should work now. Also only switch on tagged queuing on IBM DPTA & DTLA series drives, the older DJNA has firmware problems. I am working on a SW solution to that, but for now only enable tagged queuing on drives that is known to work. Get it from http://freebsd.dk, and let me know your results If I dont get any serious problem reports I'll commit this shortly, making FreeBSD the first OS that has tagged Queuing support for ATA drives :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New ATA tagged queuing patch available
It seems Thierry Herbelot wrote: > Soren Schmidt wrote: > > > > >From the README: > > > > ATA-tagged-queueing-diff-0908: > > Add support for ATA channels with both a master and a slave, even > > combos where only on of them supports tagged queuing should work now. > > Also only switch on tagged queuing on IBM DPTA & DTLA series > > drives, the older DJNA has firmware problems. I am working on > > a SW solution to that, but for now only enable tagged queuing > > on drives that is known to work. > > > > Get it from http://freebsd.dk, and let me know your results > > > > If I dont get any serious problem reports I'll commit this > > shortly, making FreeBSD the first OS that has tagged Queuing > > support for ATA drives :) > > > > -Søren > > Nice try ! Yeah :) > Any chance an older IBM drive might be supported ? > Well, the DTTA's say they support tagged queuing, but since the newer DJNA has firmware problems the DTTA probably has that too. To be fair I havn't tried it yet, so if you feel adventurous you can try to add it to the ad_tagsupported function in ata-disk.c and see what happens -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Promise FasTrack66 IDE RAID controller
It seems Spyros Melissovas wrote: > Hello, > > I was wondering if there is any kind of support for the Promise FasTrack66 > IDE RAID controller We support it already as a normail ATA controller... > AFAIK the controller needs a driver which will use the made-up disk geometry > instead of the individual disks attached to it. > > Is anybody in the process of developing something for this controller? I have some submitted patches lying around, and have gotten info from HighPoint how they do their version of the SW RAID stuff. I'm working on getting this done generically and cover both the Promise and the HPT chips, and any other ATA controllers for that matter... Watch this space for further announcements... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting data from the ATAPI-CD driver
It seems Theo van Klaveren wrote: > As detailed in my previous post to this list, the way Linux's AudioFS > does this doesn't work for FreeBSD (using IOCTL's). So, Soren Schmidt's > advice was to directly get data from the atapi_cd driver. Doing some > research, I see two ways to do this: > > 1) Using atapi_queue_cmd(), like the way atapi_cd's ioctl handler does > it but not copyout'ing the retrieved data. To do this _outside_ the > atapi_cd driver, however, I need it's atapi_softc, and I haven't figured > out how to do that yet, except that I have to use driver_get_softc(), > which needs a device_t, which I don't know how to get. I'm not sure this > is the 'right' way. > > 2) Using VOP_STRATEGY on the acd device in audiofs_strategy(), the way > the cd9660 filesystem does it. I'm not sure this will work, but it sure > looks like it. This would also reduce code complexity, but I'm not sure > it's 'right' either. > > What would be the 'right' way? 2. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: burncd utility for atapi burners
It seems Terry Lambert wrote: > > I would like to communicate the proposed changes to the author but I did not > > find his address. Could somebody provide his email to me? > > [ ... ] > > This is going to be a problem in getting your changes accepted: > > > +/*- > > + * t.h. changes copyright (c) 2000 Tomas Hruz > > + * All rights reserved. > > + */ > > Since that includes the right to integrate and distribute. Yups, I'll look at it though, since burncd is my baby :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE Questions
It seems Chris Csanady wrote: > Is there anyone successfully using an IBM 75GXP with an Abit KT7-Raid > motherboard? I am using stable from a couple days ago, and am having > some problems getting it to work. I use 4 on a Abit KA7-100 with RAID0 with no problems... > When I attach the disk to the Highpoint 370 controller, the > machine wedges after a short while. Is the support for this > chipset in stable up to date? Also, are there any plans to > merge the support for tagged queueing? I have just committed all -current functionality to -stable a couble of days ago... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DMA/66 not available for secondary IDE bus?
It seems Brian McGovern wrote: > This may be intentional, but I've noticed that if you have a non-UDMA66 device > on the primary IDE bus, FreeBSD 4.x does not allow you to have UDMA66 on > the secondary bus. Say what ? there is NO such limitation in the ATA driver What chipset are we talking about here ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken PCI-IDE RZ1000 & ata
It seems Volker Stolz wrote: > The RZ1000 PCI-IDE controller found on at least one Intel board is > severely broken and requires a workaround which is available for > Linux (at least it turned up in the config for 2.4.0, though the board > should be a couple of years old, it's for regular Pentium-I). > > Could anyone comment on this to get it working with FreeBSD? > sysinstalls gets write-errors after a couple of kilobytes, and > when running an already installed system, mount/fsck bomb with > sig 11, after that you find yourself in single-user mode with > every command (including 'reboot'!) yielding a SIGILL. Well, that chip is so broken by design, no software workaround can help its misery, a hardware fix exists, but cant (easily) be retrofitted. Forget about it, buy a new Promise or whatever if you really need that board, a software only fix is _not_ possible, no matter what linux might tell you -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken PCI-IDE RZ1000 & ata
It seems Terry Lambert wrote: > > > The RZ1000 PCI-IDE controller found on at least one Intel board is > > > severely broken and requires a workaround which is available for > > > Linux (at least it turned up in the config for 2.4.0, though the board > > > should be a couple of years old, it's for regular Pentium-I). > > > > > > Could anyone comment on this to get it working with FreeBSD? > > > sysinstalls gets write-errors after a couple of kilobytes, and > > > when running an already installed system, mount/fsck bomb with > > > sig 11, after that you find yourself in single-user mode with > > > every command (including 'reboot'!) yielding a SIGILL. > > > > Well, that chip is so broken by design, no software workaround can > > help its misery, a hardware fix exists, but cant (easily) be > > retrofitted. Forget about it, buy a new Promise or whatever if > > you really need that board, a software only fix is _not_ possible, > > no matter what linux might tell you > > The fix was to retry the call if an interrupt occurred > during DMA. This is a very old bug. > > The old ATA driver in FreeBSD had this fix. > > Are you sure that you aren't just not setting the right flags > on the device? This workaround used to be on by default in > GENERIC. > > Alternately, it's possible that the "new, improved" ATA driver > code is mearely "new". Terry, that chip is broken, the fix you mention only fixes part of its trouble, it still corrupts your data without you knowing until you hit a binary that went bad or what have you. Granted the possibility is low, but it _does happen_. So instead of supplying a partial fix and lullabying users into believing its safe to use, the "new and improved" ATA driver states the fact that this chip is broken and can corrupt your data, end of story. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken PCI-IDE RZ1000 & ata
It seems Volker Stolz wrote: > Am 02. Nov 2000 um 17:15 MET schrieb Soren Schmidt: > > ... the "new and improved" ATA driver states the fact > > that this chip is broken and can corrupt your data, end of story. > > Nope, I didn't find any references on this controller. The ATA driver states the buggyness in the probe. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken PCI-IDE RZ1000 & ata
It seems John Summerfield wrote: > > It seems Volker Stolz wrote: > > > The RZ1000 PCI-IDE controller found on at least one Intel board is > > > severely broken and requires a workaround which is available for > > > Linux (at least it turned up in the config for 2.4.0, though the board > > > should be a couple of years old, it's for regular Pentium-I). > > > > > > Could anyone comment on this to get it working with FreeBSD? > > > sysinstalls gets write-errors after a couple of kilobytes, and > > > when running an already installed system, mount/fsck bomb with > > > sig 11, after that you find yourself in single-user mode with > > > every command (including 'reboot'!) yielding a SIGILL. > > > > Well, that chip is so broken by design, no software workaround can > > help its misery, a hardware fix exists, but cant (easily) be > > As Volker notes; Linux can work round it. So can OS/2. I don't know the > details, but there ARE modes where it works. Nope, there are not, even the manufacturer agrees to that -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CD ROM
It seems Katya.Hazelden wrote: > I've got a problem with my CD ROM. The drawer keeps sliding open every time I try to >put a CD into it, it just won't stay shut. Have you got any ideas? Your drive is broken, or something is obstructing the drawer... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: STABLE ATAPI CD-ROM
It seems Dimitar V. Peikov wrote: > > Yesterday, I've CVSuped -STABLE and UPGRADE using information in > /usr/src/UPDATING from 4.1.1-STABLE. Re-cvsup, this has been fixed... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Smart And Friendly Burner?
It seems Daryl Chance wrote: > Hi, > > Anyone else have a smart and friendly cd burner? When I boot I get this: > > /kernel: acd0: CDROM at ata1-master using > UDMA33 > /kernel: ata1-slave: timeout waiting for command=ef s=00 e=00 > /kernel: ata1-slave: timeout waiting for command=ef s=00 e=00 > /kernel: ata1-slave: CDROM device -NO DRIVER! > > I'm running 4.2 RC1 (the iso out on the ftp site). I've since recompiled > the kernel (commenting out a lot of things) and I get this now: > > /kernel: acd1: CD-RW at ata1-slave using WDMA2 > > So it looks fine now. I haven't added to the kernel, just removed stuff. > If needed, I could send the conf file. You dont mention what version on FreeBSD we are talking about here, in any case you should upgrade to the latest version on the branch you are on... What exactly have you removed ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Byte order?
It seems Alex Koshterek wrote: > I know, that x86 is big endian architecture > but simple programm like this: Nope the X86 CPU's are all little endian... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HDD crashes, S.M.A.R.T and relocation tables.
It seems Lev Serebryakov wrote: > I see god solution: monitor HDD health by downloading relocation > table and S.M.A.R.T. information from it daily (in cron job). > When script detect, that relocation table is near to be full or here > is 1000 new relocations in one day, it sends mail to root, and we > have some time to buy new HDD. > > But I could not find any utility for FreeBSD, which could get > S.M.A.R.T. information and relocation table from HDD... > So, we need such utility. > Does anybody know -- is such utility exists? I'm working on it, but its not available to the public yet... I'll announce it when I have it ready for general consumption... BTW not all ATA drives supports this... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
It seems Steve Shoecraft wrote: > > There are a number of reasons why a manufacturer can not/will not release > source code for a driver. A few that come to mind are: > > a) A device driver is a reflection of the hardware. Manufacturers in > highly competitive markets could potentially be giving away trade secrets > for their new wiz-bang technology by publishing the source code. > > b) Manufacturers license technology from other manufacturers for >inclusion > into their product. The license/NDA does not allow them to disseminate the > information (either through source or documentation). c. the driver is so embarrasing they wont show it to the world This is more common than you would belive :) > EXAMPLE: I have been trying to deal with ATI recently regarding my > All-In-Wonder 128 and TV-Out. Although they have been *VERY* helpful in > giving me example source and datasheets for the R128 chipset, they cannot > give me the information on how to enable TV-Out. This is because the > ImpactTV chipset on my AIW contains technology licensed from Macrovision, > and for them (ATI) to release the information to me would breach their > agreement with Macrovision and open them up to a nice fat lawsuit. I *MAY* > have to try and get a license from Macrovision and then present my licensing > info to ATI -- and even if I did, I would not be able to distribute the > source for that component of the driver... (sigh) Well, go read the GATOS project source, they know how to switch the TVout stuff at least it works on my AIW :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Burncd problems
It seems Dave Hayes wrote: > I am on FreeBSD 4.1.1 (according to website, burncd hasn't changed at > 4.2 or -current). No, but the kernel part (the ATA driver) has... > cdmachine# burncd -f /dev/acd0c data cdimage.1 fixate > next writeable LBA 0 > writing from file cdimage.1 size 43568 KB > > only wrote -1 of 32768 bytes > > burncd: ioctl(CDRIOCCLOSETRACK): Input/output error > > Hmm. > > cdmachine# less /usr/src/usr.sbin/burncd/burncd.c > ... > if (ioctl(fd, CDRIOCCLOSETRACK) < 0) >err(EX_IOERR, "ioctl(CDRIOCCLOSETRACK)"); > > What gives here? Any clues? This is a CD-R machine which looks like: Are you sure you had a CDR/CDRW media in there ? that is blank ? > acd0: CD-RW at ata0-slave using WDMA2 > > and the kernel is telling me: > > acd0: READ_TOC - ILLEGAL REQUEST asc=24 ascq=00 error=04 > acd0: WRITE_BIG - ILLEGAL REQUEST asc=2c ascq=00 error=04 > acd0: SYNCHRONIZE_CACHE - ILLEGAL REQUEST asc=2c ascq=00 error=04 Hmm, I'd say upgrade to 4.2 and then report back if it still doesn't work... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reprobing the ATAPI bus.
It seems Josef Karthauser wrote: > Does anyone know how to reprobe the ATAPI bus, e.g. for a cd rom drive > in a laptop that wasn't present during boot? Yes :) Most of the code is already in the ATA driver, but the ioctl's and the atacontrol program is still only here in my lab due to lack of time... I hope to be able to devote enough time to this soon, I'm currently looking into having some of my time for this being sponsored... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reprobing the ATAPI bus.
It seems Josef Karthauser wrote: > > He only gets paid if it conforms to style(9) Heh :b. Just forget about it then, and be patient :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a CDROM in freeBSD 4.2
It seems gerald stoller wrote: > Please send the response directly back to me, in addition to sending > it to hackers , as the volume of mail to hackers is so great that I could > very easily miss the response if it were only sent there. > I just installed freeBSD 4.2 and found that I couldn't mount a > CDROM even though I copied the command-lines from (the top of) page 236 of > Greg Lehey's book (ISBN 1-57176-246-9). When I was running freeBSD 3.3 , I > was able to mount a CDROM , and I believe I did it just as described in > Greg's book. The error message that I get is 'cd9660: Device not > configured'. I was able to mount and read an MSDOS floppy. You dont give us any information to go on at all, what was the exact command you issue'd ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: geom_mirror implementation
It seems Lukas Ertl wrote: > > If there's a good reason ccd(4) is harder to fix than geom_mirror, then > > you might want to talk to phk about rewriting geom_ccd based on > > geom_mirror. I believe scottl and phk have plans to fix raidframe, > > though, which would address a lot of the present limitations. > > I haven't used ccd or raidframe before, and vinum is still a lot of > 'voodoo'. I just wanted to play around and do something useful; > furthermore I learned a real lot about GEOM internals. HMM!! Maybe we could end up doing something usefull here for a change... I would *love* GEOM to grow RAIDX support, so that I just needed to write the read/write RAID config routines to support Promise/HPT/xxx RAID's. That would also mean we could end the miserable lifes of ataraid/vinum/raidframe, which would be a reallygood thing (tm). But I'll bet this sensible a solution to the RAID problems will drown in religion/warfare/bikesheds between those involded in the above RAID solutions and the usual whiners/armchair generals. But count me in for this!! -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sata on -stable
It seems Duncan Barclay wrote: > Hi Soren and all, > > Having just got a nice new motherboard, a PATA drive and a bunch of SATA > disks I discover that my homework wasn't too good. -stable isn't detecting > the VIA-8237 controller, and in particuluar it is not finding the SATA > disks. > > I can hack the device recognition code to pick up the 8237 and set UDMA133 > mode on the PATA drive I have in the machine, but I cannot seem to find my > two SATA drives. Any suggestions on how to at least find the drives - I > don't need the h/w RAID as I was going to use Vinum anyway. The SATA part of the VIA needs a bit more work, you can how its done in current, not too bad just a few lines of code.. -Søren .. but it works under windows!! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sata on -stable
It seems Duncan Barclay wrote:
I had a spare minute earlier today, this should do the trick (and is
part of a larger patch due soon), please test and let me know...
Index: ata-dma.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v
retrieving revision 1.35.2.35
diff -u -r1.35.2.35 ata-dma.c
--- ata-dma.c 26 Oct 2003 18:34:23 - 1.35.2.35
+++ ata-dma.c 3 Dec 2003 10:28:07 -
@@ -506,6 +506,22 @@
}
break;
+case 0x31491106: /* VIA 8237 SATA part */
+ if (udmamode) {
+ error = ata_command(atadev, ATA_C_SETFEATURES, 0,
+ ATA_UDMA + udmamode,
+ ATA_C_F_SETXFER, ATA_WAIT_READY);
+ if (bootverbose)
+ ata_prtdev(atadev, "%s setting UDMA%d on VIA chip\n",
+ (error) ? "failed" : "success", udmamode);
+ if (!error) {
+ ata_dmacreate(atadev, apiomode, ATA_UDMA + udmamode);
+ return;
+ }
+ }
+ /* we could set PIO mode timings, but we assume the BIOS did that */
+ break;
+
case 0x01bc10de: /* nVIDIA nForce */
case 0x74411022: /* AMD 768 */
case 0x74111022: /* AMD 766 */
@@ -522,7 +538,8 @@
char *chip = "VIA";
if (ata_find_dev(parent, 0x31471106, 0) || /* 8233a */
- ata_find_dev(parent, 0x31771106, 0)) { /* 8235 */
+ ata_find_dev(parent, 0x31771106, 0) || /* 8235 */
+ ata_find_dev(parent, 0x31491106, 0)) { /* 8237 */
udmamode = imin(udmamode, 6);
reg_val = via_modes[3];
}
Index: ata-pci.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-pci.c,v
retrieving revision 1.32.2.17
diff -u -r1.32.2.17 ata-pci.c
--- ata-pci.c 22 Oct 2003 14:43:52 - 1.32.2.17
+++ ata-pci.c 3 Dec 2003 10:28:07 -
@@ -189,7 +189,12 @@
return "VIA 8233 ATA133 controller";
if (ata_find_dev(dev, 0x31771106, 0))
return "VIA 8235 ATA133 controller";
+ if (ata_find_dev(dev, 0x31491106, 0))
+ return "VIA 8237 ATA133 controller";
return "VIA Apollo ATA controller";
+
+case 0x31491106:
+ return "VIA 8237 SATA150 controller";
case 0x55131039:
if (ata_find_dev(dev, 0x06301039, 0x30) ||
-Søren
.. but it works under windows!!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sata on -stable
It seems Duncan Barclay wrote: [ Charset windows-1252 unsupported, converting... ] > Thanks Soren, this seems to work. There is a load of chat about incorrect > cable types, but the drives are nice and fast according to a simple dd > if=/dev/zero bs=64k ... Okies, the cable mumble is a "feature" of the -stable ATA driver not having the right infrastructure for this. However I could add a hack that skips the test on pure SATA controllers, but it wont be pretty... -Søren .. but it works under windows!! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1 -> 5.2 upgrade, Promise FastTrak device /dev/ar0 missing?
It seems Kevin A. Pieckiel wrote: > I have a Promise FastTrak SATA150 controller with two 120 GB drives > that are mirrored. Using 5.1-RELEASE-p10 with sources from Nov 3. > > I tried to upgrade from 5.1 to 5.2-RC today and the new kernel couldn't > mount my root partition (/dev/ar0s1a) after doing make installkernel > and rebooting into single user mode. Browsing through the console > messages shows the individual drives (/dev/ad4 and /dev/ad6), but no > /dev/ar0. The /dev/ar0 device shows up on the 5.1 kernel. What did I > do wrong? I'm using the same kernel config file (except for chaning > "options apicio" to "device apic") and followed the usual procedure > of make buildworld, make buildkernel, make installkernel reboot to > single user mode, etc. > > The 5.1 kernel was CVSed on 3 Nov in the RELENG_5_1 tag and the 5.2-RC > was from RELENG_5_2 CVSed 24 Dec. > > Included is my dmesg output from the 5.1 kernel and my kernel config > file SAMSON for the 5.1 kernel. Any help would be appreciated. You need "device ataraid" in your config file.. -Søren Yes I know it works under windows!! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reading raw data from a CD-R with damaged table of contents
It seems Kevin Serwick wrote: > Hi all, > > I added some files to a multisession CD-R with the > burncd command. It appeared to work fine, but when I > read the disk, the new files didn't show up. So I did > the burncd fixate command - bad idea! Now nothing > shows up! (burncd's no Nero Burning Rom! Live and > learn... Is the GUI burning software usable and > reliable?) > > I assume it just destroyed the table of contents. Rather you add a new one that is empty or garbled. > Any suggestions for how I can recover that data? It might be posible to read the original session, I seem to remember that it can be set somehow, but default is to always read the last. However its been quite a few moons since I last looked in the color books. > I couldn't find software to read raw data from > anything. Do you guys know of anything? > I would have to write something myself would I? Possibly, it might be as simple as modifying the atapi-cd.c driver to be able to read a specific session, see above... > Do you know where I can find an ISO 9660 filesystem > specification? Uhm ETSI has some of them for free IIRC.. > This is possible, right? Probably, I always feel very much at risk when saying the opposite :) -Søren Yes I know it works under windows!! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serial ATA 4.8 Installation -help
It seems florian mettetal wrote: > Greetings, > > I have built a brand new system founded on an Asus P4PE motherboard, and > using the FastTrack raid function I have turned my two Maxtor 80GB > Serial ATA (now reffered to as SATA) hard drives into a Mirror raid. > > Proceeding to start the installation of FreeBSD 4.8-stable I selected > Standard Install, Press ok at the pop up, then at the following popup I > am confronted with FreeBSD telling me that "No disks found! Please > verify that your disk controller is being properly probed at boot time". > Has anyone else had this issue? Is this problem fixed in FreeBSD 5.X . > What can I do to get this to work in FreeBSD 4.8? 4.x doesn't support the Promise SATA controllers, you need at least 5.1 for that. The -current ATA driver might be backported later this year, nothing definite yet. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serial ATA 4.8 Installation -help
It seems florian mettetal wrote: > > Now, I am at the Select Drives (Second screen) which menas that 5.1 does > see my promise SATA raid controller. Now... I have 3 selections to use > for drives, ad4, ad6, ar0 > First, I have 2 drives, and one is just a mirror of the other. my > presumption is to singularly use ar0, but... I really do not know. And > as this will someday hopefully be my production server... I wanna set it > up right. You want to use ar0, that's the array.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: prospects for DMA support for SiS962(L) Southbridge?
It seems Rich Morin wrote: > With FreeBSD 4.9 on the horizon, I thought I might bring this up again... > There is no time for this on 4.9 (at least if it should be done properly. 5.1 has support for all SiS chipsets... > At 10:01 AM -0700 6/17/03, Rich Morin wrote: > >I recently upgraded my motherboard and CPU, as: > > > > 478 pin Celeron; 2.1 GHz > > 512 MB DDR DIMM (2 ea.) > > SiS962(L) Southbridge > > > >I then found that I couldn't boot the (FreeBSD 4.7) system, getting: > > > > ad0: READ command timeout tag=0 serv=0 resetting > > ata0: resetting devices > > > >After a bunch of Googling and some discussions on freebsd-questions, > >I decided to change line 90 of /usr/src/sys/dev/ataata-disk.c to: > > > > static int ata_dma = 0; > > > >This works, but I suspect that it is slowing down my disk I/O quite a > >bit. So, I would like to know the prospects for this controller being > >supported in FreeBSD any time soon. > -- > email: [EMAIL PROTECTED]; phone: +1 650-873-7841 > http://www.cfcl.com- Canta Forda Computer Laboratory > http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. > http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A new sort utility
It seems Tim Robbins wrote: > Comments/patches are welcome. As the "History" suggestion of the manual page > suggests, my plan is to get this in to FreeBSD 6, along with replacements for > some other GNU tools. I have a diff(1) replacement (with sdiff support) in > the works, among other things. Go for it!! the more GPL'd stuff we can remove the better!! -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Does anyone work on making ATA moduler?
It seems Takanori Watanabe wrote: > Hi,There is a problem when PCMCIA related stuff > is used as module, ATA CF is not recognized. > > This is because PCMCIA atachment is not compiled > when pccard(4) is not compiled in. > > To fix it, we have to supply PCMCIA attachment > in any form. > One way is to make a kernel module that contains only > ATA/PCMCIA attachment with this Makefile > Then two question. > 1. May I commit this workaround? No, not yet.. > 2. Are there any people working on ATA for making it fully > moduler? Yes there is. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: raid (atacontrol) problems
It seems Igor Tseglevsky wrote: [ Charset KOI8-R unsupported, converting... ] > Strange problems with RAID. If disks are located on different controllers > after rebooting one of disks disappears. Disks on one controller coexist in > RAID normally. Is that Promise controller a fasttrak ie with a RAID BIOS ? In that case you cant span controllers, that only works on generic ATA controllers (ie those without any RAID). > Any ideas? Please, help! > > > cf# atacontrol status 0 > atacontrol: ioctl(ATARAIDSTATUS): Device not configured > cf# atacontrol create mirror ad1 ad4 > ar0 created > cf# atacontrol status 0 > ar0: ATA RAID1 subdisks: ad1 ad4 status: READY > cf# fastboot > > cf# atacontrol status 0 > ar0: ATA RAID1 subdisks: ad1 DOWN status: DEGRADED > > In dmesg: > > ad0: 76319MB [155061/16/63] at ata0-master UDMA66 > ad1: 76319MB [155061/16/63] at ata0-slave UDMA66 > ad2: DMA limited to UDMA33, non-ATA66 cable or device > ad2: 76319MB [155061/16/63] at ata1-master UDMA33 > ad4: 76319MB [155061/16/63] at ata2-master UDMA100 > ad6: 76319MB [155061/16/63] at ata3-master UDMA100 > ar0: WARNING - mirror lost > ar0: 76319MB [9729/255/63] status: DEGRADED subdisks: > disk0 READY on ad1 at ata0-slave > disk1 DOWN no device found for this disk > > Similarly for ad2 and ad6. > > Other situation with same controller: > > cf# atacontrol status 0 > atacontrol: ioctl(ATARAIDSTATUS): Device not configured > cf# atacontrol create mirror ad1 ad2 > ar0 created > cf# atacontrol status 0 > ar0: ATA RAID1 subdisks: ad1 ad2 status: READY > cf# fastboot > > cf# atacontrol status 0 > ar0: ATA RAID1 subdisks: ad1 ad2 status: READY > > Similarly for ad4 and ad6. > > cf# uname -a > FreeBSD cf 5.1-RELEASE-p5 FreeBSD 5.1-RELEASE-p5 #0: Mon Sep 22 07:46:00 GMT 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > cf# > > Some dmesg about controllers: > > atapci0: port > 0xdf90-0xdf9f,0xdfe0-0xdfe3,0xdfa8-0xdfaf,0xdfe4-0xdfe7,0xdff0-0xdff7 mem > 0xfeafc000-0xfeaf irq 11 at device 8.0 on pci2 > ata2: at 0xdff0 on atapci0 > ata3: at 0xdfa8 on atapci0 > > atapci1: port 0xffa0-0xffaf at device 31.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci1 > ata1: at 0x170 irq 15 on atapci1 > > Igor. > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VT8237 serial-ATA support, Promise ATA stalls, GEOM noise
It seems Sean Hamilton wrote: > I'm looking to replace an aging fileserver with an Asus A7V600 board. > Presently it appears FreeBSD does not support the serial ATA interface on > the south bridge. As this appears to be the first Via serial ATA controller, > am I safe in assuming this will not be supported for some time? Probably, VIA has newer been keen on sharing docs, so this can take some time to get done and might just stall until I get such HW here to do the needed magic on. > I have two Asus boards (A7V8X and A7V) which have in common a Promise ATA > controller. Both of these boards hang up for about a minute during the boot > of 5.1-RELEASE, and emit messages about ad* devices being reset -- I cannot > paste them verbatim as they seem to have been omitted from my dmesg. In the > case of the A7V8X, the controller is unused and disabled in the BIOS. Has > this been rectified for 5.2? Should not happen on -current. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Pictures from USENIX
It seems Wes Peters wrote: > Tim Vanderhoek wrote: > > > > On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: > > > > > > read a bit about them. Same for the committers group, but at 165+ > > > members that's going to be a somewhat larger, long-term project. :-) > > > > Did Wes Peters finish his collection of committer ICBMNet lat/long > > co-ordinates? > > Here's what I have so far: > 55.4, 11.3, "phk, sos" # Denmark That should be: 55.4, 11.3, "phk" # Denmark 57.2, 10.2, "sos" # Denmark We dont live THAT close together :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
It seems David Greenman wrote: > >> > A constant 5 o'clock shadow, maybe, but not a beard. > >> > >> And what's wrong with a beard? > > > >Nothing. I just remember someone pointing out in a previous e-mail that > >all the core members had some sort of beard. > >Very few core members have beards, so whoever said that was wrong. Nah, are you sure ?? I havn't shaved in over a decade :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDMA problems on ALI chipsets
It seems Dag-Erling Smorgrav wrote: > Is anybody working on getting UltraDMA to work on ALI chipsets? I have > a scratch box with that chipset and an UDMA disks and can test patches > and perform minor debugging if anyone needs me to. > > ide_pci0: irq 0 at device 15.0 >on pci0 Use the ata driver, it has support for the aladdin chipset, and it works... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: hot-swapping ata disks
It seems Iani Brankov wrote: [Charset koi8-r unsupported, filtering to ASCII...] > Hi, > I tried 'camcontrol rescan' and I found it works when I add a SCSI device while > the system is on. I find it useful for adding/removing devices w/o restarting > the box. (Maybe it's risky, but useful. I supposed that's the idea of the > 'rescan' command in camcontrol) > > Is there a way to do the same with the new 'ata' code. (I know IDE isn't SCSI > anyway). I have some experimental code that enables one to do this, but it is not without risk as the IDE channels are not designed for this. You also need to put the disk in a drawer that is able to shut off power etc so you dont burn any electronics while changing the drive. Once I get a little time I'll celan this up and make it available... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
It seems Dag-Erling Smorgrav wrote: > Jamie Howard ([EMAIL PROTECTED]), with a little help from yours > truly, has written a BSD-licensed version of grep(1) which has all the > functionality of our current (GPLed) implementation, plus a little > more, in one seventh the source code and one fourth the binary code. > What's more, the code is actually possible for mere mortals to read > and understand. > > The source code is available for download from freefall: > > http://www.freebsd.org/~des/software/grep-0.7.tar.gz> > > I move that we replace GNU grep in our source tree with this > implementation, once it's been reviewed by all concerned parties. Go for it, the more GNU stuff we nuke the better :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onstream?
It seems Vince Vielhaber wrote: > > Out of curiousity, have there been any successes in the drivers for > the OnStream tape drives (SCSI or IDE)? Working on it (for IDE that is), support is planned for, but I have no release date yet... I know that there is work done on the SCSI end too... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Fwd: Please support FreeBSD 3.x as host OS]
It seems Assar Westerlund wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > I heard they have released the source to the kernel modules needed > > to run it. > > > > why not port them over? :) > > I started looking at the kernel modules and porting them, however, I > must confess that I don't fully understand exactly what the linux > kernel module does, which makes it somewhat harder to implement the > same functionality on FreeBSD :-) If you provide an URL to those files, I'd give them a look... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
It seems Biju Susmer wrote: > > OK, i went to net and got this page > > (http://www.mit.edu/afs/sipb.mit.edu/project/linux/docs/faq/AT > > API-FAQ) there > > also they say it should be MASTER. Problem is not with me. > > The vendor didn't > > follow the specs. PC never followd specs i think ;) > > > > Some one please put this in an FAQ (if it is not already > > said) to avoid any > > future problem? > > second thought.. I have not seen a PC with CD at any other configuration... Cant > this config be supported? Many like me are not good in opening the box and > fixing the problem like other hackers. (But don't say i should not use FBSD with > CD ;). any thoughts? This config is supported in the new ATA driver, but thats only in current. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare: porting kernel modules to FreeBSD
It seems Gary Jennejohn wrote: > Mark Huizer writes: > >Hi there, > > > >I had a look recently at the code for one of the kernel modules that VMWare > >requires (driver-only.tar), and it looks like something that should be > >portable to FreeBSD, although there is some messy stuff in it (assembly > >that seems to be using Linux specific stuff, brrr..) But anyway: it > >looks feasable. > > > >Is anyone already working on this, or are some people interested in > >helping with this? > > > >As far as I can see, the linux emulation is good enough to run the > >vmware program, "all" you need to do is implement /dev/vmmon and > >/dev/vmnet, given the fact that the code is written really unportable, > >so there is some rewriting to be done. Then with the KLD's > >vmmon,vmnet and linux you should be able to run vmware. > > > > Soren mentioned that he might look into it a few weeks ago, but that's the > last thing I remember seeing. Yup, I have the files here, and have given it a quick look, doesn't look to difficult to do, but I havn't had time yet to get into the matter.. It will probably be awhile before I do have the time though, but if nobody else does it I'll get to it sooner or later... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Seagate STT8000A (ATAPI/IDE) on FreeBSD? (fwd)
It seems David Krinsky wrote: > I posted this to -hardware a few days ago and haven't > gotten much in the way of feedback; since it sounds to me > like a driver bug this seems like an appropriate forum too. > > Is anyone here using -any- ATAPI drive for backup? Yup, I use one: ast0: tape drive at ata1 as slave ast0: Drive empty, readonly, reverse, qfa, ecc, 512b ast0: Max speed=600Kb/s, Transfer limit=52 blocks, Buffer size=728 blocks > When I try to tar up a usefully-sized directory or filesystem, > however, the drive will begin its work apparently correctly, but the > tar will exit with an I/O error at a variable point a few seconds to > minutes into the backup. The following goes to syslog: > > wst_done: wst0: nonrecovered data error I've seen this problem LOTS of times when using the old wd based atapi subsystem. I've never been able to find out why this is happening exactly. This was part of the reason I started out on the new ATA driver (only in -current now). I've never had this problem using the ATA driver, so I'm pretty sure its the old driver thats at fault, probably some delicate timing prob. Using the new driver I do routine backups every night on a couble of servers, not seen a signle problem yet... -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Seagate STT8000A (ATAPI/IDE) on FreeBSD? (fwd)
It seems David Krinsky wrote: > > > Also, make sure that your drive is good. I had one I had to return > > because it was bad. Soren said the driver worked, and I could never > > get it working for me. The replacement worked like a charm. > > Well, it's brand-new, and I didn't get it at a garage sale. :-) > We know it's got a write head; I've succeeded at doing > backups and restores of small directory hierarchies, so I kind of > doubt it's the drive... What kindof chipset is your motherboard using ?? Are you overclocking ?? If not what is you PCI bus clock ?? I'm pretty sure this is the same problem that haunted me with the old driver, and if I'm not mistaken it is timing related.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Moving bt848 driver to /sys/dev/bktr
It seems Roger Hardiman wrote: > Hi, > > I want to move the Bt848 driver to /sys/dev/bktr > > So, does anyone see any problems with this? Nope, go for it I'd say, and could we then have some of all the version text and stuff put away too, thats why we have CVS :) -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help - Fasttrak eide raid host adapter and FreeBSD
It seems Richard Uren wrote: > Ward, > > I purchased one last week - A FastTrak66 > (which is perhaps not the 'FastTrack' you mentioned. > > Its detects as a 'PCI - Mass Storage Controller' > (in the Bios startup) and unless there is some > 'emulate an IDE drive' mode that I missed it > won't work. If you use the 'ata' driver in -current it should be detected and usable uptil UDMA33. I have a patch that might make it work in UDMA66 mode but I havn't gotten my hand on one to test yet.. -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
