Re: Something weird happening w/ SMP -current
It seems Matthew Dillon wrote: > > Here's some more info. If the dd is stuck and systat -vm 1 is showing > no interrupts occuring on, for example, ahc2 (irq17), and I then do > something that causes an interrupt to occur on mux (irq19), which I > guess is ahc1, ahc2 then starts working... until it gets stuck again, > that is. I can also get ahc2 going again by issuing another dd on ahc2. > > For example: > > dd if=/dev/rda1d bs=32k of=/dev/null > ... let this one run ... > ... it gets stuck ... > dd if=/dev/rda1d bs=32k of=/dev/null count=1 > ... this unsticks the first dd ... > ... the first dd runs again ... > ... the first dd gets stuck again ... > repeat... > > All I can think of is that something is causing the system to lose an > occassional interrupt. There's a race condition somewhere. Ahhh, I see this too, on an ATA only box that is, I loose my network from time to time, especially if there is lots of interrups on another source, it endeeed looks like we are loosing interrupts somewhere. Guess we have to study some of the latest changes more carefully and see went wrong, I'll try to experiment a bit with it -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
It seems Dag-Erling Smorgrav wrote: > Richard Tobin <[EMAIL PROTECTED]> writes: > > Is that relevant for 3.2 as well as current? And by "disabling ultra > > DMA" did you mean "disabling UDMA66" or "disabling UDMA completely"? > > (You can permanently disable UDMA66 with a DOS utility available > > from IBM, and it will then act as a plain UDMA33 drive.) > > Depends on your motherboard. Try to just disable UDMA66 first. If that > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > Aladdin), disable UDMA completely in the BIOS setup utility. BZZST! The Aladdin isn't bad, the support in the old wd based driver is :) I use a DJNA drive on an Aladdin board, with the ATA driver, and it works just dandy no matter how I set the BIOS (and I always get UDMA33 btw, the Alladin wont do any higher than that)... -SØren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
It seems Dag-Erling Smorgrav wrote: > "Brian F. Feldman" <[EMAIL PROTECTED]> writes: > > On 4 Jul 1999, Dag-Erling Smorgrav wrote: > > > Depends on your motherboard. Try to just disable UDMA66 first. If that > > > doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs > > > Aladdin), disable UDMA completely in the BIOS setup utility. > > What do you mean, "known bad" ALi? > > I should have said "known bad configuration". I know Søren's ATA > driver supports UDMA on the Aladdin, but I don't have the luxury of > expendable file systems, so I don't use it. I also think it's the > wrong direction to go off in; if we're going to totally rewrite our > IDE driver, we should do it within the CAM framework. Do I hear a volounteer here ?? What the new ATA/ATAPI driver is all about is mostly a rewrite of all the low level code, and that is still needed if you want to go the CAM way. The higher levels of the new ATA driver is simply a port of my allready done ATAPI drivers. There is nothing in the way of screwing a CAM interface ontop of that lowlevel code instead of/in parallel to the current highlvel code Oh and besides that I still have to loose a filesystem to the ATA driver :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
It seems Nick Hibma wrote: > > > I should have said "known bad configuration". I know Søren's ATA > > > driver supports UDMA on the Aladdin, but I don't have the luxury of > > > expendable file systems, so I don't use it. I also think it's the > > > wrong direction to go off in; if we're going to totally rewrite our > > > IDE driver, we should do it within the CAM framework. > > > > Do I hear a volounteer here ?? > > What the new ATA/ATAPI driver is all about is mostly a rewrite of all > > the low level code, and that is still needed if you want to go the CAM way. > > The higher levels of the new ATA driver is simply a port of my allready > > done ATAPI drivers. > > There is nothing in the way of screwing a CAM interface ontop of that > > lowlevel code instead of/in parallel to the current highlvel code > > Yes yes yes! CAM on top of ATAPI. If we keep the command > creation/conversion layer in CAM and make CCB come out at the lower end, > we could instantly screw it on top of the USB Mass Storage driver (that > supports SCSI through CAM at the moment). > Well, CAM & ATAPI is "fairly" easy, the only problem being all the little details that are different enough to make it non-trivial to maintain. I once sat down and tried to get all the details on how the CCB's where different, and decided that I wouldn't want to engage in that. Another story is ATA disks, there you either have to teach CAM about a new lowlevel protocol, or write a SCSI<>ATA translator, which I also decided I didn't want to do... Having CAM & ATAPI without the ATA part is real clumsy if you ask me, so There are also subtle differences in the way errors & timeouts, not to speak about tagged cmds are handlede by the HW, that probably requieres changes to the way CAM works, or non-trivial translation mechanisems, but I havn't looked too deeply into that (yet).. Besides I can live without the CAM overhead (both speed and size wise). That all boils down to that if somebody is willing to do the job, I'm sure we can integrate it into the ATA driver so that both worlds can be made happy, I just dont have the motivation to do it... > On a related edge: > > Would it make sense to create a UFI command layer (USB floppies use it, > don't know what else) on top of CAM? Or am fundamentally wrong in > assuming that one can stack any command layer on top of CAM and abuse > it as a layer that provides common services, command queueing, error > handling? > > It would like this: > > SCSI UFI_da ATAPI > \| / >CAM layer > | > USB Mass Storage Driver >/ | \ > Bulk CB CBI You better ask Justin that... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
It seems Peter Wemm wrote: > > Well, CAM & ATAPI is "fairly" easy, the only problem being all the > > little details that are different enough to make it non-trivial to > > maintain. I once sat down and tried to get all the details on how > > the CCB's where different, and decided that I wouldn't want to engage > > in that. > > Another story is ATA disks, there you either have to teach CAM about > > a new lowlevel protocol, or write a SCSI<>ATA translator, which I > > also decided I didn't want to do... > > Well, that's assuming you use scsi ccb's... you could use atapi ccb's. > We have cam/* which is the generic transport handler. cam/scsi/* which > is the scsi peripheral drivers that use scsi ccbs, and then we could > have cam/ata/* which uses atapi ccb's and ata disk info. Then you have > cam/ata/ata_ad.c, cam/ata/atapi_cd.c etc. Your backend ata controller code > then gets requests sent to it in atapi format and/or something suitable for > ata disks. > > This approach is quite efficient and you get to use the common queueing, error > recovery, etc etc stuff. You don't have to do ccb translation or anything. > You get your own disk, tape, cd etc driver with their own names and major > numbers. They would look *very* similar to the scsi counterparts but would > be seperate as they use different ccbs, different backend-specific hooks, etc. Uhm, yes, agreed, but it defies some of the gains (ie common highlevel drivers) but would probably keep the performance of the current approach. It would make life a wee bit less complicated, but one would still have to do all the lowlevel code to deal with queing etc, but the higherlevel stuff could probably be shared, maybe CAM would have to be modified a bit but it should be possible... > Things like umass, vpo etc have it easy since they basically bulk send the > scsi ccb's to the device as they use the scsi protocol directly. The ATAPI > protocol is similar but would require translation if it used the common top > end drivers. So, it either requires different top end drivers or has to do > translation. So its basically a choice between added complexity or added complexity :) When I get all the lowlevel stuff done (this has to be done no matter what approach is chosen) I'll take a look at it again, but if anybody feels like doing anything about it, let me know, so we can get things coordinated -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IDE_DELAY
It seems Thomas Schuerger wrote: > Hi! > > I've set the option > > IDE_DELAY=1500 > > and compiled and installed my kernel (I even did config -r > before that), but when booting, the IDE driver still waits > for about half a minute before continuing, instead for > about 1.5 seconds. Has anyone succeeded in setting the > IDE delay? SCSI_DELAY works just fine... What driver are you using (ata/wd) ?? This option is only valid for the wd driver, there should be no delays with the ata driver, except if bad behaving HW is present... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Promise/IDE
It seems Mike Hoskins wrote: > and I just installed a Promise Ultra66. Here's my relevant kernel config > stuff (following LINT's example): > > pci0: unknown card DBZ4d38 (vendor=0x105a, dev=0x4d38) at 14.0 irq 9 Thats the promise controller, try the ata driver instead an use the following patch, let me know if it works... Index: ata-all.c === RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v retrieving revision 1.15 diff -u -r1.15 ata-all.c --- ata-all.c 1999/06/25 09:02:56 1.15 +++ ata-all.c 1999/08/05 18:14:11 @@ -184,6 +184,8 @@ return "Intel PIIX4 IDE controller"; case 0x4d33105a: return "Promise Ultra/33 IDE controller"; + case 0x4d38105a: + return "Promise Ultra/66 IDE controller"; case 0x522910b9: return "AcerLabs Aladdin IDE controller"; #if 0 @@ -241,7 +243,7 @@ #endif /* if this is a Promise controller handle it specially */ -if (type == 0x4d33105a) { +if (type == 0x4d33105a || type == 0x4d38105a) { iobase_1 = pci_read_config(dev, 0x10, 4) & 0xfffc; altiobase_1 = pci_read_config(dev, 0x14, 4) & 0xfffc; iobase_2 = pci_read_config(dev, 0x18, 4) & 0xfffc; @@ -318,7 +320,7 @@ if (!irq) printf("ata_pciattach: Unable to alloc interrupt\n"); - if (type == 0x4d33105a) + if (type == 0x4d33105a || type == 0x4d38105a) bus_setup_intr(dev, irq, INTR_TYPE_BIO, promise_intr, scp, &ih); else bus_setup_intr(dev, irq, INTR_TYPE_BIO, ataintr, scp, &ih); @@ -342,7 +344,7 @@ int rid = 0; void *ih; - if (type != 0x4d33105a) { + if (type != 0x4d33105a && type != 0x4d38105a) { irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_SHAREABLE | RF_ACTIVE); if (!irq) Index: ata-dma.c === RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v retrieving revision 1.8 diff -u -r1.8 ata-dma.c --- ata-dma.c 1999/05/26 23:01:57 1.8 +++ ata-dma.c 1999/08/05 18:14:55 @@ -168,6 +168,7 @@ break; case 0x4d33105a: /* Promise Ultra/33 / FastTrack controllers */ +case 0x4d38105a: /* Promise Ultra/66 controllers */ devno = (scp->unit << 1) + (device ? 1 : 0); if (udmamode >=2) { printf("ata%d: %s: setting up UDMA2 mode on Promise chip ", -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA module doesn't work with ATI Mach64 RagePro
It seems Kazutaka YOKOTA wrote: > > >I have switched graphics card from S3Virge to ATI Mach64 RagePro rev 92 > >with 8 MB RAM a I have noticed that VESA module doesn't work with this > >graphics card on my -current box - I can't use VESA_XXX console modes now. > >Command kldstat says there is loaded module vesa.ko. No errors are > >reported when I'm trying to unload/load vesa.ko module. Kernel reports > >during boot: > > > >VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc024f622 (122) > >VESA: ATI MACH64 > > > >Command "vidcontrol -i mode" reports lines below. It looks VESA module > >can't read mode table properly. But simple VESA utilities in DOS are capable > >to determine all VESA modes supported by ATI Mach64 card with VESA 2.0 BIOS. > >Is this known problem? Or should I invetigate this problem further? > > There is a good possibility that the VESA BIOS extension for this card > is provided in a DOS TSR program and the VESA BIOS entry in the ROM > BIOS is just a stub. Such implementation is allowed in the VESA spec. Actually its because the ATI chip reports the modes as non-VGA modes, which is correct (sortof), and our VESA code rejects those modeentries. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA module doesn't work with ATI Mach64 RagePro
It seems Cejka Rudolf wrote: > > Soren Schmidt wrote (1999/08/09): > > > It seems Kazutaka YOKOTA wrote: > > > There is a good possibility that the VESA BIOS extension for this card > > > is provided in a DOS TSR program and the VESA BIOS entry in the ROM > > > BIOS is just a stub. Such implementation is allowed in the VESA spec. > > > Actually its because the ATI chip reports the modes as non-VGA modes, > > which is correct (sortof), and our VESA code rejects those modeentries. > > Yes, thanks. Information reported by 0x4F01 function about any video > mode has set MODE_NON_VGA attribute indeed. And now I have found DOS TSR > program for VESA support... > > I hate VESA 2.0/3.0 specification :-( I hate ATI :-( Well well, no need to be that excited, if you hack out the test, the BIOS will willingly setup the modes that you get. And IIRC we can now support linear framebuffers in graphics modes, so support should be fairly easy to add.. > Is there any good AGP graphics card with full BIOS support in hardware? Dunno, but chances are getting smaller every day, most vendors relies on winblows drivers delivered with the cards nowadays.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error 1)
It seems Doug White wrote: > > > > > > > FWIW - I enabled APM over the weekend, configuring drives to > > > > spin down when not used for a good period of time. I get the > > > > message you list below, alternately with status 50 and 58, any > > > > time a drive needs to spin up. > > > > > > Thanks for the response. FWIW I have no apm enabled and these > > > drives don't have a chance to spin down since they're always busy when > > > under load. > > > > Do those drives happen to be IBM DeskStar drives? > > They spin down automatically when they have not been turned > > off for about a week, in order to clean the heads. > > It's a feature. > > You've got to be kidding. That makes them totally useless for server > operation -- at some random time every week, down goes your server for a > few minutes. :( That can't be true, at least not for the IBM DeskStars I own, I've NEVER EVER seen them do that, one proof should be: 11:22PM up 105 days, 4:18, 1 user, load averages: 1.06, 0.94, 0.91 dmesg snippet: wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S And none of the other machines I have with semilar or newer IBM's have ever done this, in fact I've yet to see one of them fail in any way.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error 1)
It seems Francis Jordan wrote: > /kernel: acd0: CDROM drive at ata1 as master > /kernel: acd0: drive speed 4134KB/sec, 128KB cache > /kernel: acd0: supported read types: CD-R, CD-RW, CD-DA > /kernel: acd0: Audio: play, 256 volume levels > /kernel: acd0: Mechanism: ejectable tray > /kernel: acd0: Medium: CD-ROM unknown medium, unlocked > /kernel: ata_command: timeout waiting for interrupt > > --^ > > It happens everytime I boot. What does the last line mean, and why does > it appear? BTW, there's an audio CD in the CD-ROM drive, so it's not > exactly "unknown" medium. What can I do to help fix this? I assume you only have those two devices on the ide channels right ?? Then the problem is that the CDROM drive doesn't respond proberly to a command, in fact it doesn't respond at all, there is no interrupt. Have you tried another CDROM drive ?? This smells alot like substandard hardware. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error 1)
It seems Thierry Herbelot wrote: > Soren Schmidt wrote: > > > [SNIP] > > > > That can't be true, at least not for the IBM DeskStars I own, I've > > NEVER EVER seen them do that, one proof should be: > > same here > > wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 > wd0: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S > wdc0: unit 1 (wd1): , DMA, 32-bit, multi-block-16 > wd1: 9671MB (19807200 sectors), 19650 cyls, 16 heads, 63 S/T, 512 B/S > wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa > wdc1: unit 0 (wd2): , DMA, 32-bit, multi-block-16 > wd2: 9671MB (19807200 sectors), 19650 cyls, 16 heads, 63 S/T, 512 B/S > > TfH (trying to upgrade one BP6 to 4.0) Have you tried putting disks on the UDMA66 channel ?? I think it should work in upto WDMA mode now with the ata driver... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA - Trouble mounting secondary master
It seems Geoff Rehmet wrote: > Brian McGroarty writes : > > In using the ATA driver, I'm unable to automatically mount a > > partition on a master drive on the secondary controller. fsck > > complains that device rwd2s1e isn't configured and exists. > > Immediately mounting by hand works perfectly. > > > > Compiling the kernel with wd instead of ata eliminates the > > problem. > Hmm, > > I had exactly the same problem, although it manifested itself with a > secondary master or slave. It went away a few weeks ago, and I > was never able to make any sensible progress in tracking the problem > down. Hmm, damn, after the problem went away for Geoff I thought it to be solved since I've never heard of it anywhere else, and I cant reproduce it here no matter what I try. Does it help eany if you only has the root partition use the wd dev and have the rest use the prober ad dev entries ?? It could be some artifact from this... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error 1)
It seems Francis Jordan wrote: > Yes, HDD on the primary, CD-ROM on the secondary controller. This is a > notebook I'm talking about, so I haven't tried any other CD-ROM drives. > If it doesn't respond at all, then how do you get all the other > information, such as supported read types, speed, etc? Perhaps there is > some other way of making this particular CD-ROM drive generate an > interrupt? Of course, it's just a minor annoyance (and otherwise I'm > very pleased with the driver's performance - many thanks to SOS), but if > the new ATA driver were to eventually replace the old one, it's not a > bad idea to try and get rid of as many silly error messages as possible. Hmm try the patch below so we can tell what command it is failing on.. > Is there just one standard that all ATAPI CD-ROM drives must comply > with, or can there be variations? I apologize if this is a silly > question. There is several versions of the ATAPI standard, but they are all pretty vague, there is LOTS of room for vendors to "improve" thier devices :( Index: ata-all.c === RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v retrieving revision 1.16 diff -u -r1.16 ata-all.c --- ata-all.c 1999/08/06 17:39:37 1.16 +++ ata-all.c 1999/08/11 07:00:09 @@ -693,7 +693,8 @@ scp->active = ATA_WAIT_INTR; outb(scp->ioaddr + ATA_CMD, command); if (tsleep((caddr_t)scp, PRIBIO, "atacmd", 500)) { - printf("ata_command: timeout waiting for interrupt\n"); + printf("ata_command: timeout waiting for interrupt (cmd=0x%02x)\n, + command"); scp->active = ATA_IDLE; return -1; } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA - Trouble mounting secondary master
It seems Geoff Rehmet wrote: > Hmm, > > My root device still lands up on "wd0" - even though my fstab has > the root filesystem on ad0s1a. I haven't looked at getting it to > use the ad dev entries for the root file system. (I'm assuming that > is still WIP.) Our boot blocks/loader dont have the needed computrons to use the "ad" device name. However I have some patches to boot2 that allows to boot off an ad root device, provided you dont use the loader, and put the rigth boot string in boot.config. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error 1)
It seems Francis Jordan wrote: > Soren Schmidt wrote: > > > > Hmm try the patch below so we can tell what command it is failing on.. > > After removing the quotation mark after the word command in the above > patch (smile), it prints: Yeah, so much for writing code without compiling it :) > ata_command: timeout waiting for interrupt (cmd=0xa1) > > What is command 0xa1? >From ata-all.h: #define ATA_C_ATAPI_IDENTIFY0xa1/* get ATAPI params*/ That makes it difficult to support that drive :), but I think there must be some other reason it fails, hmmm... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error 1)
It seems Thierry Herbelot wrote: > Soren Schmidt wrote: > > > [SNIP] > > > > Have you tried putting disks on the UDMA66 channel ?? I think it > > should work in upto WDMA mode now with the ata driver... > > I have first to install 4.0 and from my wd2 (I've got a little help from > RNordier, I should make do) > > Then, I'll get a UDMA-66 drive (any recommendation ?) You can put any IDE drive on those channels, but of cause you can only use UDMA66 on capable drives. I'd just be interested in if the newest ata driver finds the controller, UDMA66 is not supported yet anyways only std WDMA... And me, I'm a sucker for IBM or Maxtor drives in that order... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA - Trouble mounting secondary master
It seems Mike Smith wrote: > > Our boot blocks/loader dont have the needed computrons to use the > > "ad" device name. However I have some patches to boot2 that allows > > to boot off an ad root device, provided you dont use the loader, and > > put the rigth boot string in boot.config. > > This should now be totally redundant as long as your /etc/fstab entry > is correct. Define "correct" then please, it doesn't work for my definition... -Current as of aug 21th... If I have this in my fstab: /dev/ad0a / ufs rw 1 1 /dev/ad0f /usrufs rw 2 2 /dev/ad0e /varufs rw 2 2 And have NO wd* entries in /dev, it says on boot: Changing root device to wd0s1a Changing root device to wd0a ... mount: /dev/ad0a on / special device does not match mounted device. Bummer! If however I have a /dev/wd0a it will mount that and show that in a mount/df command, but then it doesn't fit what it is written in /etc/fstab and that is bogus too... So I still stick with my statement that the -current bootblocks/loader doesn't have the computrons needed to use the ad device (or any non wd/da/fd device for that matter) for anything usefull :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with the ata driver
It seems Nicolas Souchu wrote: > acd0: CDROM drive at ata0 as master > acd0: drive speed 0KB/sec > acd0: supported read types: > acd0: Mechanism: caddy > acd0: Medium: CD-ROM unknown medium > > Any clue? > > The drive was running flawlessly with the old wdc driver and with various > primary releases of the new ata driver (some, not all). Hmm, looks like the timeout I've chosen for timing out on the probes *might* be too short for some devices.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata-all.o(.text+0x534): undefined reference to `pci_read_config'
It seems Valentin S. Chopov wrote: > > It seems there is something for > > #if NPCI > 0 ... #endif Yup, forgot that one, fixed. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA atapi-all.c problems/fixes/cleanups
It seems Brian Fundakowski Feldman wrote: > I just noticed a problem with the ATA driver with my (not quite, but to me) > new CD-R drive. The behavior is that underruns and overruns are handled > incorrectly, due to a mixup between variables. The end result is that > too much data is sent to the drive and it chokes, borking my entire 2nd ATA > bus and thereforeo my box. >Enclosed is my fix in the form of a patch to atapi-all.c. The changes > are: > * general cleanups > * the bugfixes > * make the {over,under}run messages easier to understand/more helpful > * more use of ATA_16BIT_ONLY and *l functions to maintain consistency > I'm pretty certain that the bugfixes are correct, since it fixed the problem > for me, but I don't know about the ATA_16BIT_ONLY usage. My uncertainty > there lies in wondering if packets have to be a certain modulus. From the > code, I'd assume that all packets would have a modulus of 4 bytes. Is this > correct? Either the patch is very short, or you forgot to include it :) The ATA_16BIT_ONLY thing is to only do 16bit wide inb/outb instructions as old ISA HW don't allow 32bit wide access. This option is now deprecated as it is switched on automagically for ISA cards. >Anyone else experiencing lockups when an underrun/overrun occurs, try > this patch; it has fixed the problem for me, and now I'm on my way to > writing music CDs :) The current way to hack around that bug must be > to use the "obs" operand to dd(1), since that's what came naturally to > me :) You _should_ _always_ have dd (or whatever you use) pad the output to the given blocksize, or you will run into problems. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA atapi-all.c problems/fixes/cleanups
It seems Brian Fundakowski Feldman wrote: > On Tue, 4 Jan 2000, Soren Schmidt wrote: > > > Either the patch is very short, or you forgot to include it :) > > *LOL* I can't believe I did that :) It'll be on this one!! Yup, this time there is a patch :) > > The ATA_16BIT_ONLY thing is to only do 16bit wide inb/outb instructions > > as old ISA HW don't allow 32bit wide access. This option is now deprecated > > as it is switched on automagically for ISA cards. > > Is all data a multiple of 4 bytes, though? Not really, ie there is nothing that says so. However ALL requests should be of length N*blocksize where N can be from 1 to 254. Blocksize is depending on the format used but normally 2048 or 2352 bytes... > > You _should_ _always_ have dd (or whatever you use) pad the output to the > > given blocksize, or you will run into problems. > > IMHO, it should be better to use a larger multiple of block size (2352) > to not perform so many operations in userland (since the kernel does a > great job of doing writes in the right size in order). Then, it would > be pessimal to use "conv=osync" because you'd lose more room from the > media. But anyway, the padding should work properly, no matter what :) The problem here is that you will then do a lot of unneeded padding as the driver will attempt to pad to the blocksize used which is not wanted. You HAVE to use the right blocksize especially for audio, or you will get "silent" ie zero padded blocks on disk, and thats not what you want is it ? > Thanks for the prompt reply! Now I'll remember that patch... Your'e welcome... What should be done is that we need a new util instead of wormcontrol and dd to do burning. I dont see me having time anytime soon, too much to do (DVD + DVD-RAM support, more chipsets etc etc), so I'm on my way to add an ioctl interface that cdrecord can use -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ouch! Something broke (possibly ATA)
It seems Alex wrote: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xbff21000 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc0214ffe > stack pointer = 0x10:0xc02f6b58 > frame pointer = 0x10:0xc02f6b8c > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > interrupt mask = net tty bio cam > trap number = 12 > panic: page fault > Uptime: 0s > Automatic reboot in 15 seconds - press a key on the console to abort > > > % nm /kernel.test | grep c0214f > c0214f68 T bus_dmamap_load > c0214f28 T bus_dmamem_free Those are not used by the ata driver -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new man pages
It seems Marc Schneiders wrote: > Where do I look for new man pages? I would like to read those for the > new ata driver and for ntpd. They were not created during a build > world some 5 days ago. And I cannot find them in > /usr/src/share/man/man4, where I would expect man ata/ad in any case. There are no man pages for the ata driver (yet), for nptd I dunno... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA atapi-all.c problems/fixes/cleanups
It seems Brian Fundakowski Feldman wrote: > > I used a multiple of the blocksize, and it works fine, except for on > the very last bit of data. The very last bit of data is what causes > an underrun, and the code that's there for overrun/underrun is > wrong right now. For underrun, it ends up writing the underlying > blocksize length from the user buffer of _less_than_that_size_, then > it writes (blocksize - user buffer size) _more_ zeroed data! This > promptly locks up the IDE bus with my CD-R. That's what the patch was > about and you didn't say anything about; yes, I know that blocksizes > should be matched perfectly and padded perfectly to prevent the ATA > driver from having to handle the underrun/overrun cases, but the > current handling is/was still broken. Try this patch instead, it should do the right thing.. Index: atapi-all.c === RCS file: /home/ncvs/src/sys/dev/ata/atapi-all.c,v retrieving revision 1.29 diff -u -r1.29 atapi-all.c --- atapi-all.c 2000/01/03 10:26:56 1.29 +++ atapi-all.c 2000/01/05 08:36:49 @@ -563,12 +563,15 @@ #endif for (resid=request->bytecount; residdevice->controller->ioaddr + ATA_DATA); + *buffer += request->bytecount; + request->bytecount = 0; } -else +else { insw(request->device->controller->ioaddr + ATA_DATA, (void *)((uintptr_t)*buffer), length / sizeof(int16_t)); -request->bytecount -= length; -*buffer += length; + *buffer += length; + request->bytecount -= length; +} } static void @@ -585,19 +588,22 @@ request->device->devname, length, request->bytecount); #ifdef ATA_16BIT_ONLY outsw(request->device->controller->ioaddr + ATA_DATA, - (void *)((uintptr_t)*buffer), length / sizeof(int16_t)); + (void *)((uintptr_t)*buffer), request->bytecount/sizeof(int16_t)); #else outsl(request->device->controller->ioaddr + ATA_DATA, - (void *)((uintptr_t)*buffer), length / sizeof(int32_t)); + (void *)((uintptr_t)*buffer), request->bytecount/sizeof(int32_t)); #endif for (resid=request->bytecount; residdevice->controller->ioaddr + ATA_DATA, 0); +*buffer += request->bytecount; + request->bytecount = 0; } -else +else { outsw(request->device->controller->ioaddr + ATA_DATA, (void *)((uintptr_t)*buffer), length / sizeof(int16_t)); -request->bytecount -= length; -*buffer += length; +*buffer += length; + request->bytecount -= length; +} } static void -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA lost contact
It seems Kris Kennaway wrote: > One of my Western Digital Caviars doesn't work under the new ATA driver: > upon trying to access the disk (via swapon or mount during boot) it gives > the famous "lost contact with disk" message and falls back to PIO mode. > Interestingly, my two older WDCs work fine - although I notice that ad1 > and ad2 are only detected as WDMA2, when it seems (from the udma=2) that > they can handle UDMA - is this a cabling issue or something (I'm not > familiar with IDE cabling requirements)? The disk probably has problems with DMA mode (lots of older WD disks has that). You only get WDMA2 mode since you controller is an older Intel PIIX that can't do UDMA... > ata-pci0: at device 7.1 on pci0 > ata-pci0: Busmastering DMA supported > ad0: piomode=4 dmamode=2 udmamode=-1 cblid=0 > ad0: ATA-0 disk at ata0 as master > ad0: 1549MB (3173184 sectors), 3148 cyls, 16 heads, 63 S/T, 512 B/S > ad0: 16 secs/int, 1 depth queue, WDMA2 > ad1: piomode=4 dmamode=2 udmamode=2 cblid=0 > ad1: ATA-3 disk at ata0 as slave > ad1: 2441MB (4999680 sectors), 4960 cyls, 16 heads, 63 S/T, 512 B/S > ad1: 16 secs/int, 1 depth queue, WDMA2 > ad2: piomode=4 dmamode=2 udmamode=2 cblid=0 > ad2: ATA-4 disk at ata1 as master > ad2: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S > ad2: 16 secs/int, 1 depth queue, WDMA2 -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA lost contact
It seems Kris Kennaway wrote: > On Wed, 5 Jan 2000, Soren Schmidt wrote: > > > The disk probably has problems with DMA mode (lots of older WD disks > > has that). You only get WDMA2 mode since you controller is an older > > Intel PIIX that can't do UDMA... > > Hmm..This disk was bought in about March 99..you're sure that's the > reason? No, but I've had my share of bad experiences with WD disks in that regard, I'll have to look up the modelnumber to be sure... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mounting CD-ROM with ATA driver hangs system
It seems Peter Jeremy wrote: > I just discovered that my ATAPI CD-ROM is no longer usable - when I > try to mount it, my maching hangs (hard). > > I'm running -current from cvs-cur 5961 (Monday about UTC). > > The symptoms are: > > Run "mount -r /dev/acd0c /cdrom" > The CD-ROM activity light flashes briefly and the CD-ROM spins up. > The activity light then goes hard on for something like 20 seconds. > The kernel then prints: > acd0: atapi_timeout: cmd=READ_BIG - resetting > ata0: resetting devices .. _ > The cursor remains at the end of the line ("_" above). The CD-ROM > spins up and down. The HDD light stays hard on. > acd0: CDROM drive at ata0 as slave > acd0: read 1723KB/s (1723KB/s), 256KB buffer, DMA ^^^ You have enabled ATAPI DMA in your kernel config, dont, your drive apparently doesn't support it. DMA on ATAPI devices is disabled as default because _lots_ and I mean _lots_ of ATAPI devices claim to do DMA, but they actually dont :( -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA atapi-all.c problems/fixes/cleanups
It seems Brian Fundakowski Feldman wrote: > How about this? It's mostly the changes in your patch, but it also takes > into account non-int{8,16}_t-sizing/alignment. It also takes care of the > truncation problem when you use outsl and insl, as part of that. Please > review it, as I think it should be the right thing to do. Hmm, sortof. In the real world we should newer ever see partial transfers, they should always be of N * DEV_BSIZE, so this is a bitt overkill. However some of the internal ATAPI handling use odd sizes for modes etc, but they are all at least 16 bit aligned, so 8 bit alignment is not needed, I'll have to check if we need 16 bit alignment, I can't remember ofhand... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA atapi-all.c problems/fixes/cleanups
It seems Brian Fundakowski Feldman wrote: > > It's just as well. It's almost 4 AM and I've just about given up on getting > this all working. Anyway, if everything has to be DEV_BSIZE, then I guess > that would simplify things, except when I try, say, writing 4697 bytes > as an audio blocksize (2 * 2352 - 7), it goes all the way through the > acdstrategy as 4697... I don't know why DEV_BSIZE isn't respected, then, > but I suppose Poul might be able to help here? You should respect the blocksize when talking to a device with a fixed blocklength, dont write ! % blocksize blocks to the device.. Anyhow I've done a replacement for wormcontrol and have cleaned up the interface to the driver, I hope to have it tested for commit soon, this will solve the problem once and for all.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wormcontrol replacement coming!
I've just done a replacement for wormcontrol that allows burning CDR/CDRW with just one command. Its simpleminded but it works. Just a FYI as I know several people have said they where thinking about doing such a thingy. The API to the kernel has changed too, finally I got around to cleaning up the interface.. I'll commit it later when I have tested all combinations and written a man page... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wormcontrol replacement coming!
It seems Luigi Rizzo wrote: > [Charset ISO-8859-1 unsupported, filtering to ASCII...] > > > > I've just done a replacement for wormcontrol that allows burning CDR/CDRW > > with just one command. Its simpleminded but it works. > > > > Just a FYI as I know several people have said they where thinking > > about doing such a thingy. > > this would save me the porting of my wormcontrol changes (similar ideas) Yes. > to -current. Is your command also intended for the 3.x branch ? No. This only works with the new ATA driver. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wormcontrol replacement coming!
It seems Luigi Rizzo wrote: > > > > I've just done a replacement for wormcontrol that allows burning CDR/CDRW > > > > with just one command. Its simpleminded but it works. > > btw for the records -- on 2.2.x i noticed i needed some wait between > the transfer of data to CDR, and the "fixate" command (in other words, > the fixation would often immediately fail if done within the same wormcontrol > instance in charge of the data transfer.) > > I got lazy and instead of investigating the problem i realised that issuing > the "wormcontrol fixate data" manually after the previous one was done did > fix things, so i have no idea if it was related with my port of the worm > support to 2.2.x, with the possible absence of closing and reopening the device, or >with just the delay between the commands. Any idea ? I've not seen the fixate fail, but I've seen the second write to a multitrack disk fail if the device is not closed inbetween. The problem was that the b_offset that is used to calculate the LBA to write to, is not reset between the writes, so the address doesn't corresspond with the address found with the next_writeable function. This is fixed now... I've also investigated using the READCD cmd instead of READ_BIG to read the CD, this allows one to read _any_ data in _any_ format off the CD, thereby eliminating the need for rippers, you just dd the audio CD into a file, handy :). It seems to work pretty well, so I might commit that too... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP! wormcontrol and sys/dvdio.h users
I've just committed burncd the wormcontrol replacement. The ATAPI burner API has changed, so wormcontrol does no longer work, use burncd instead (see burncd.8) The DVD ioctl's has changed numbers, so those using that should recompile thier apps. Wormcontrol and related files will be removed soon. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! wormcontrol and sys/dvdio.h users
It seems Alexander Langer wrote: > Thus spake Soren Schmidt ([EMAIL PROTECTED]): > > > The DVD ioctl's has changed numbers, so those using that > > should recompile thier apps. > > Wormcontrol and related files will be removed soon. > > I saw changes for the ioctl for the ata*, but not for the wd* > stuff. > > Could wormcontrol at least stay as the wd* drivers stay? Sure, I dont se why not, but it adds to the confusion... > ata* doesn't work for me at the moment, thus I'm using the wd drivers. What is your problem ?? > Or am I wrong? Can I use burncd with the wd drivers? No. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Found it --- 'ata' driver screwing up the machine (was Re: New kernel no longer boots on one of my machines... ata, other proble
It seems Matthew Dillon wrote: > > :From what I can tell so far, something during the kernel boot is > :disabling the timer interrupt. The ATA probe does a tsleep() which > :never times out. Output is queued to the console during the boot > :sequence which is never printed (until I CTL-ALT-ESC)... > : > :has someone messed with spl*()'s anywhere recently? > > Another datapoint: When I DDB the machine and 'print *ticks', > it comes up 0, and when I panic it it says "uptime 0s". > > If I remove the 'ata' drivers I get the bootconf screen > since there is no root - but *ticks is incrementing! > > If I add 'ata' back in, buckus (DDB> print *ticks yields 0, machine > is screwed up). > > When I remove 'ata' and enable the 'wd' driver, everything works > normally. The machine boots up fine. Thats to be expected, the wd driver doesn't use config_intrhook_establish() to hook in the probes when interrupts should be running. >From your previous mail it looked like you had both ATA & SCSI in there, then tried without SCSI and it kindof worked. The error 6 problem has been up here before, but I dont remember the solution off hand, but you should use /dev/ad* entries in you fstab, and have MAKEDEV'd them fairly resently, new bootblocks and loader are also a must. My best guess is that config_intrhook_establish() screws up something when more than one consumer uses it to hook into the boot process... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver problems
It seems Peter Jeremy wrote: > On 2000-Jan-06 10:38:51 +1100, I wrote: > ["dd if=/dev/rad0c of=/dev/null bs=64k" dies with an error] > > I did some poking around and found that there are two bugs which > conspire together to cause this: > 1) diskstrategy() does not detect dscheck() returning EOF, instead >passing a zero-length request to the underlying driver. > 2) The ata-disk driver doesn't check for (and ignore) zero-length >requests, instead passing them onto the disk. > > See kern/15956 for details and patches. Thanks! I'll take a look at it! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! wormcontrol and sys/dvdio.h users
It seems Alexander Langer wrote: > > > ata* doesn't work for me at the moment, thus I'm using the wd drivers. > > What is your problem ?? > > I posted this to the -current ml 3 weeks ago, when I wanted to switch. > See the "ata: Mount root failure: 6"-thread. Hmm, that one, I thought (wrongly) that it got solved. Seems to me to be a bootblock/loader/fstab/MAKEDEV inconsistency somehow. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: some problem with atapi-all.c
It seems Fritz Heinrichmeyer wrote: > > I tried the ATA_ENABLE_ATAPI_DMA option, it gave: > > ../../dev/ata/atapi-all.c: In function `atapi_attach': > ../../dev/ata/atapi-all.c:150: syntax error before `)' fixed. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atap cd?
It seems Amancio Hasty wrote: > {root} mount -t cd9660 /dev/acd0a /cdrom > cd9660: Block device required > {root} mount /dev/acd0a /cdrom > mount: Block device required > > ls -ald /dev/acd0c > brw-r- 1 root operator 19, 2 Jan 7 20:27 /dev/acd0c > If this is current it should be: crw-rw-rw- 1 root operator 117, 2 Dec 2 22:52 /dev/acd0c -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atap cd?
It seems Amancio Hasty wrote: > Tnks > > Yes, I am running current as of today . also while trying to read a DVD > I think that your driver is not setting cap.dvdrom flag so when I ask for > report key it returns with failure. Just wondering if you her of such > a problem currently. I am more than happy to hack the driver to read > the key 8) Erhm, if thats the drive you posted the dmesg from, that is a CDROM drive, it cannot read DVD's. I know that cap.dvdrom is set when used on DVD drives and have no reports telling otherwise. The driver works for all thats needed to read/play a DVD given that you use the right tools. Look at freebsd.dk/pub/DVD for the patches needed to css-auth (you have to get the source form somewhere else) and a ported nist player. Remember that I just changed the DVD ioctls, so if you use older compiled tools they wont work... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atap cd?
It seems Amancio Hasty wrote: > I did a fresh re-install and all is working well over here. Now my real hacking > begins that is to modify the DVD mpeg player to use the brand new spanking > functions in XFree86 to do yuv->rgb + scaling with hardware assist 8) You should look at the livid site, they have a new player thats much faster than the nist one, it also has backends for various video HW, including ATI cards which is nice since thats what I've got here :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver timeout
It seems Theo van Klaveren wrote: > > I still can't seem to be able to boot -CURRENT with the ATA driver, > much as I'd like to, due to the `timeout-resetting device' error, which > I've seen more people report. I've sacrificed some dead trees to give > you the exact boot messages: > > ad0: ATA-0 disk at ata0 as master > ad0: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S > ad0: 16 secs/int, 1 depth queue, WDMA2 > ad1: ATA-3 disk at ata0 as slave > ad1: 2441MB (4999680 sectors), 4960 cyls, 16 heads, 63 S/T, 512 B/S > ad1: 16 secs/int, 1 depth queue, UDMA33 > . > . > Mounting root from ufs:/dev/ad0s1a > ad0: ad_timeout: lost disk contact - reseting > ata0: resetting devices .. > > After which the machine hangs _hard_ (i.e. no respone except to the > reset key). > > The information given is mostly correct: The second drive is > UDMA33 and can handle it with the WD driver. Also, when this drive > is removed, the error still occurs. > > I'm in doubt as to the first drive though: The BIOS says it's 'Mode 4', > is that the same as WDMA2? Could the harddisk be reporting the wrong > value, even though the BIOS is giving the correct one? I'm just grasping > at straws here. Mode 4 is PIO4 that is no DMA, it could very well be the problem, WD has made a lot of problematic drives in this area. You could try to comment out the dmainit call in ata-disk.c and see if that helps you. And yes, I'm working on a way to set this from useland... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver timeout
It seems Theo van Klaveren wrote: > > > > Mode 4 is PIO4 that is no DMA, it could very well be the problem, > > WD has made a lot of problematic drives in this area. > > You could try to comment out the dmainit call in ata-disk.c and > > see if that helps you. > > That helps me, but if I'm not mistaken it also disabled UDMA33 on the > second drive. Yup, it was more to determine is DMA really was your problem... > Ah well.. at least I can boot an ATA kernel now. > > > And yes, I'm working on a way to set this from useland... > > That'd be really nice, though if the kernel doesn't even boot to single > user mode, I don't see how this would help users with this problem, as > you'd have to do it before reboot. The idea is to boot in non-DMA mode, and then have a script setup the wanted modes from etc/rc*. That way you can always boot into singleuser mode and change the access modes... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA CDROM problems
It seems Kris Kennaway wrote: > > acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 Sounds like the drive doesn't like this, it probably only supports PLAY_MSF.. > ata1-slave: piomode=3 dmamode=0 udmamode=-1 dmaflag=1 > ata1-slave: timeout waiting for command=ef s=00 e=00 > ata1-slave: failed setting up PIO3 mode on generic chip Now that points to a problem, the drive wont accept being put into PIO mode 3, despite it saying it supports it, hmm... > acd0: CDROM drive at ata1 as slave > acd0: read 171KB/s (689KB/s), 256KB buffer, ??? > acd0: Reads: CD-DA > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray > acd0: Medium: CD-ROM 120mm audio disc loaded, unlocked, lock protected I have some mods to the driver that will be commit in a few days, that _might_ solve this problem... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATAPI broken, but why?
It seems Brian Fundakowski Feldman wrote: > I'm sure everyone's seen my e-mail and others' e-mail about ATAPI in the > ATA driver, at least, being broken (WRT CD-Rs). The question is, does > anyone have any idea at all why? I tried reverting to just before the > CDRIOC* changes, and that didn't help (using wormcontrol to test that). > If any of you have any hints at all, please let me know. Uhm, if reverting the driver to the state BEFORE the change doesn't help, you probably should look somewhere else, as you stated once that that used to work. Have you change other things in the system ? Overclocking ? checked the cables ? can you check the drive otherwise ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATAPI broken, but why?
It seems Brian Fundakowski Feldman wrote: > > I was trying to rule out the CDRIO* changes themselves being at fault. > It seems they're not, but another person also share's my experiences > with no longer being able to write CDs now. How about this: I'll > find out when it broke, and perhaps we can work from there? Deal! :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UDF
It seems Brian Beattie wrote: > I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I > was wondering if anybody was working on it. I'm thinking about trying to > implement it for CD-RW's and would like to avoid duplication of effort and > the anoyance of getting half way through the effort and having somebody > else show up with a completed implementation. I have it on my TODO list, but I'm not started yet, and probably wont for some time to come. The reason I've put it on the backburner for now, is that DVD's can be read using the cd9660 filesystem, and that is sufficient for my needs for the time being. I have however started to implement the needed functionality in the ata driver, so we should probably coordinate that part of the matter.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATAPI CDROM trouble
It seems Vladimir B. Grebeschikov wrote: > > With new ATA driver I have big trouble > - I can't use my CDROM > > while I am do 'mount_cd9660 /dev/acd0c /m/cd' > system compleatly holds, no core, no panic - hold (may be deadloop in > kernel mode ?) > optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices Dont define this until you know the drive is functioning otherwise, LOTS and I mean LOTS of atapi devices dont do DMA even if advertised. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATAPI CDROM trouble
It seems Daniel J. O'Connor wrote: > > On 14-Jan-00 Soren Schmidt wrote: > > Dont define this until you know the drive is functioning otherwise, > > LOTS and I mean LOTS of atapi devices dont do DMA even if advertised. > > Would it be possible to implement this as something like a 'quirk list'? > > ie list known good (or bad) drives and enable (or disable) DMA on them. It would have to be a list of known good drives on known working chipsets, in effect a list that would be next to impossible to maintain. If you have ATAPI hw that are more than 6-12month old, bets are it wont work, newer devices seems more capable, but still alot of them claim to support DMA, but fail utterly always or on some chipset combinations. The only way to know is to try it out and see for yourself, the ATAPI device manufactures should have thier fingers smacked, hard -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA CD-R problems, still...
It seems Bryan Liesner wrote: > On Sun, 16 Jan 2000, Brian Fundakowski Feldman wrote: > > >Can you try this patch to src/usr.sbin/burncd, and see if things work > >after that? Thanks! (BTW, there's also an extra feature in there, hope > >you don't mind :) > > > > Yes, I burned a full 650MB onto a CD-R disk. No problems at all. And > I see just changing the definition of BLOCKS from 32 to 16 did the > trick. I thought there was going to be a lot of digging into the > ATAPI driver to get this fixed. There really wasn't any functional changes to the driver, but there was to the util :) It is sad though that there still are so many crappy drives be made :( However I've committed the fix... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
It seems Russell L. Carter wrote: > > I swapped out my motherboard and am seeing this now: > > ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying > ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying > ad0: UDMA CRC WRITE ERROR blk# 1140495 retrying > ad0: UDMA CRC WRITE ERROR blk# 1140495WARNING: WAIT_READY active=ATA_ACTIVE_ATA > falling back to PIO mode This for the most part means cable and/or power problems, does this appear immediately or under moderate/high load ?? Remember the K7 is a power hog, how big is you PSU, especially how much power (amps) can it deliver on the 3.3V 5V and 12V rails ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata observation (bug?)
It seems Brian Somers wrote: > Hi, > > I don't know if you'd class this as a bug report or more as an > observation. I have a machine with the following: bug :) > ata-pci0: port 0xf000-0xf00f at device 15.0 on >pci0 > ata-pci0: Busmastering DMA supported > ata0 at 0x01f0 irq 14 on ata-pci0 > ata1 at 0x0170 irq 15 on ata-pci0 > [.] > ad0: ATA-0 disk at ata0 as master > ad0: 1623MB (3324384 sectors), 3298 cyls, 16 heads, 63 S/T, 512 B/S > ad0: 16 secs/int, 1 depth queue, WDMA2 > ad1: ATA-4 disk at ata1 as master > ad1: 7339MB (15032115 sectors), 15907 cyls, 15 heads, 63 S/T, 512 B/S > ad1: 16 secs/int, 1 depth queue, UDMA33 > ad2: ATA-4 disk at ata1 as slave > ad2: 26063MB (53377152 sectors), 52953 cyls, 16 heads, 63 S/T, 512 B/S > ad2: 16 secs/int, 1 depth queue, UDMA33 > > Note that ad0 is on a controller of its own, and ad[12] are on the > second controller. If I put the second (7Gb) disk on the first > controller as slave, I can't get the machine to boot. The wd driver > works ok, but ad, although coming up in the ``?'' list in > vfs_mountroot_ask(), won't boot... I get error 6 when I try > ufs:/dev/rad0s1a at the prompt. > > This has stopped me going to the ata driver on this machine for a > long time :-/ > > Moving the two UDMA disks to a controller of their own has solved the > problem Hmm, I'll investigate this, it sure adds more data to the equation.. Thanks for the report! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata-all.c : undefined atapi_attach() in ata_attach()
It seems Valentin S. Chopov wrote: > > It seems that we need #if...#endif here, maybe > something like that: > > ... > #if NATAPICD > 0 || NATAPIFD > 0 || NATAPIST > 0 > /* then the atapi devices */ > for (ctlr=0; ctlr if (!atadevices[ctlr]) continue; > if (atadevices[ctlr]->devices & > ATA_ATAPI_MASTER) > atapi_attach(atadevices[ctlr], > ATA_MASTER); > if (atadevices[ctlr]->devices & > ATA_ATAPI_SLAVE) > atapi_attach(atadevices[ctlr], ATA_SLAVE); > } > #endif fixed! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
It seems Russell L. Carter wrote: > > Hi Soren, > > I am beginning to believe that the FIC mb is the problem. My > IBM-DPTA-372050 is only half as fast (500MB bonnie) > as on the P2B (~10MB/s vs. ~19MB/s). A Jan 11 kernel > doesn't downgrade to PIO on the > IBM-DTTA-371440 as fast as this evenings -current with your > latest bits does, but eventually it gets there. Hmm, that endeed sound strange, the ICRC errors do point at HW trouble, you dont have the cables running near anything that generates a magnetic field or anything (like near the coils to the voltage regs etc), that is known to make trouble... > )(*&$#%$# stupid magazine benchmarkers never actually test > things like IO... gr I wouldn't belive those mags, most of what they write are just rubbish, and often tainted by who bought most advertizing space that month :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
It seems Motomichi Matsuzaki wrote: > > Hi. > > I updated to today's -current from -stable. > My ATAPI CD-ROM drive doesn't probed, > and is seemed to be halted. > (The tray is locked, won't open, and the LED keeps being on.) > > Mother board: ABIT BH6 > CD-ROM drive: ATAPI [CDU77E-NE] on primary-master > other ATAs: none > > It worked fine on -stable. > I tried to use 'obsolete' wdc/wcd driver, it works fine. This is fixed in the next update, due as soon as I get time -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver and DVD's
It seems Kenneth Wayne Culver wrote: > I recently downloaded and tried xmovie (there is a link to it at > www.opensound.com) and when I tried to play a vob file from the DVD my > xconsole filled with this error: > > acd0: READ_BIG - ILLEGAL REQUEST asc=6f ascq=03 error=00 > > Is this an ATA driver problem? No, that is a DVD forum/consortium problem :) The DVD drive tells you this way that it hasn't be authenticated with the right magic to allow you access to the bitstream bits. You need the css-auth program to enable you to read the data off the DVD. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: D?ISK I/O erros
It seems TrouBle wrote: > this is a brand new 10gig UDMA 66 maxtor is this a disk problem via > hardware, or is it a BSD issue with the new code ??? > angelsguardian /kernel: ad0: UDMA CRC WRITE ERROR blk# 7801951 retrying The driver is telling you that the transfers CRC check are not valid and it is retrying the transfer. This can be due to many things: Bad cableing, cable too near field generating devices in the machine, bad disk, bad controller, bad driver... Mostly though this is due to one of the two first items. > ad0: ATA-5 disk at ata0 as master > ad0: 9770MB (20010816 sectors), 19852 cyls, 16 heads, 63 S/T, 512 B/S > ad0: 16 secs/int, 1 depth queue, UDMA33 I need a full verbose bootlog (dmesg) before I can give you any more diagnostic on this.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Missing ATAPI CD
It seems Kris Kennaway wrote: > Since the most recent round of ATA updates, my CDROM is no longer even > probed at boot time. > > deviceata0 > deviceatadisk0 > deviceatapicd0 > options ATA_STATIC_ID > I know of this, it should be fixed in my next update, I hope to have it ready in a day or two.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem of burncd
It seems Yosuke Koshino wrote: > Hi,there > > I install FreeBSD-current-2122. > I tried to write CD-R with burncd, but writing of CD-R is failed > at the 'fixate' sequence. At the same time, I got the next error > message. > The message is "burncd: ioctl(CDRIOCCLOSEDISK) : Device busy". > Then, I add "sleep(10);" in 'fixate' code of burncd.c. You didn't get any other error messages ?? > > I have been able to write CD-R normally with burncd now. > I think the cause of the failure is that My CDR drive have 4MB > cache memory and the synchronize of this cache need about 7 or > 8 seconds. > Is there the matter of the function "acd_close_track()" of > atapi-cd.c in the kernel code ? Hmm, acd_close_track waits uptil 5 mins for the flush to complete that should be more than enough. Maybe you drive return to ready state before it actually did write out the contents, hmmm -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem of burncd
It seems Yosuke Koshino wrote: > "Soren Schmidt <[EMAIL PROTECTED]>" wrote: > > > The message is "burncd: ioctl(CDRIOCCLOSEDISK) : Device busy". > > > Then, I add "sleep(10);" in 'fixate' code of burncd.c. > > > > You didn't get any other error messages ?? > I didn't get no other error message. OK, it could be a sideeffect of something else going wrong. > > > Hmm, acd_close_track waits uptil 5 mins for the flush to complete > > that should be more than enough. Maybe you drive return to ready > > state before it actually did write out the contents, hmmm > If it is true, the firmware of my drive has bug. Do you think so? Could be, I have a drive with 2M of buffer, and I've never seen it do this, and since the driver waits for the device to get ready before returning from the close_track function, it shouldn't happen. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADSUP!! burncd users..
The management of next_writeable has been move from the kernel to userspace. This means that the burncd command must be in sync with the kernel. So make world is your friend. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 CODE FREEZE WILL BEGIN IN FIVE (5) DAYS
It seems Kris Kennaway wrote: > On Mon, 24 Jan 2000, Jordan K. Hubbard wrote: > > > On the 29th of January, I'll be freezing the -current branch (well, > > OK, the trunk). That means NO commits without my review first and I > > Hmm. What does this mean for the ATA driver? I know Soren has some more > updates in the wings, and I'm grateful for his continued work, but the > truth of the matter is that it has never worked properly for my system > (therefore by extension, those of a lot of other people out there who have > working systems at present but who aren't using -current), and 5 days > isn't likely to fix everyone's problems. Huh, you have only told me about the missing CDROM (should be fixed with the commit I just did), what else seems to be a problem ?? > I think we should consider defaulting back to the wd drivers unless soren > can work miracles in the meantime, rather than risking a large subset of > the user base finding 4.0 doesn't work right on their machines :-( I do miracles on a daily basis :), but for the pricetag on the work for FreeBSD, well, cant wonders do ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: at driver problems (was: 4.0 CODE FREEZE WILL BEGIN IN FIVE (5) DAYS)
It seems TrouBle wrote: > does it look like this ??? Could I have a complete dmesg, or at least all the lines that belongs to the ata driver ?? I need to know what chips etc to be able to diagnose further... > ad0: 9770MB (20010816 sectors), 19852 cyls, 16 heads, 63 S/T, 512 B/S > ad0: 16 secs/int, 1 depth queue, UDMA33 > acd0: CDROM drive at ata0 as slave > acd0: read 6890KB/s (6890KB/s), 256KB buffer, PIO4 > acd0: Reads: CD-R, CD-RW, CD-DA stream, packet > acd0: Audio: play, 255 volume levels > acd0: Mechanism: ejectable tray > acd0: Medium: no/blank disc inside, unlocked -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 CODE FREEZE WILL BEGIN IN FIVE (5) DAYS
It seems Greg Childers wrote: > > >Huh, you have only told me about the missing CDROM (should be fixed > >with the commit I just did), what else seems to be a problem ?? > > On some older PCI systems, including my Pentium 66, the driver still detects > irq 0 for ata-pci0. Hardwiring it to irq 14 in the source as suggested recently is >the temporary fix I'm using. Could you send that patch around me please ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
It seems Motomichi Matsuzaki wrote: > > Thank you for fixing, but still not probed. > What can I do for your work? > ata-pci0: port 0xf000-0xf00f at device 7.1 on pci0 > ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xf000 > ata0: mask=03 status0=50 status1=00 > ata0: mask=03 status0=00 status1=00 > ata0: devices = 0x4 > ata0 at 0x01f0 irq 14 on ata-pci0 > : > ata-isa0: already registered as ata0 > : > ata0-master: ata_command: timeout waiting for intr That has me worried, what make/version is the drive ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
It seems Anders Andersson wrote: > I have the same problem: > > [anders@enterprise:anders] $ dmesg | grep ata > ata-pci0: port 0xffa0-0xffaf at device 7.1 > on pci0 > ata0 at 0x01f0 irq 14 on ata-pci0 > ata-isa0: already registered as ata0 > ata0-slave: ata_command: timeout waiting for intr > ata0-slave: identify failed Could I please have a complete dmesg from that ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 CODE FREEZE WILL BEGIN IN FIVE (5) DAYS
It seems Greg Childers wrote: > Hope this helps! It may be helping you, but everyone having more than the ATA chip on the motherboard is going to be bitten severely by this as the interrupt for the primary channel on all controllers are now hardwired to irq 14. What does the Detected irq: say on your machine ?? We might do something intelligent if it is clearly out of range... > --- ata-all.c.orig Sun Jan 16 17:08:59 2000 > +++ ata-all.c Sun Jan 16 17:09:30 2000 > @@ -291,6 +291,11 @@ > iobase_1 = pci_read_config(dev, 0x10, 4) & IOMASK; > altiobase_1 = pci_read_config(dev, 0x14, 4) & IOMASK; > irq1 = pci_read_config(dev, PCI_INTERRUPT_REG, 4) & 0xff; > + if (irq1 != 14) { > + printf("Detected irq: %d ", irq1); > + printf("Changing to 14!!\n"); > + irq1 = 14; > + } > } > > if (pci_get_progif(dev) & PCIP_STORAGE_IDE_MASTERDEV) { -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
It seems Tom Embt wrote: > Don't mean to butt in here, I haven't really been following the thread - > but I may have found a workaround/clue. I have a Sony CDU-55E (ooold 2x) > on secondary master of the PIIX4 on my BP6. By going into the BIOS (the > section of it where you would set CHS numbers, LBA, etc) and changing the > secondary master device from "none" to "auto", I have gone from: > > BTW, this was on a kernel from around 20:00 GMT Jan 25 Interesting... What version is you ata-all.c ?? its damn close to the commit I just made, that should fix that problem... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
It seems Alex wrote: > Speaking of identify failed, I get the following: > > ata-pci0: port 0xfcf0-0xfcff at device > 1.1 on pci0 > ata0 at 0x01f0 irq 14 on ata-pci0 > ata1 at 0x0170 irq 15 on ata-pci0 > > ... > > ata1-slave: ata_command: timeout waiting for intr > ata1-slave: identify failed > ad0: 6194MB disk at ata0 as master mode UDMA33 > acd0: CDROM at ata1 as master mode PIO4 You need to update.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready, (.. and no sound with cmi8330)
It seems F. Heinrichmeyer wrote: > Last weekend i tried patches from Soren Schmidt to reactivate my old > cdrom which went away after the ata-update around the 18. January. This > patches completely broke ata support for me (that means the kernel did > not boot anymore). Of course i reported this one or two days later. I was under the impression that it was something else that caused it not to boot, you didn't tell me back then it was because of the ata driver, oh well... > Now an equivalent variant (while loop instead of goto in ata_getparam , > ata-all.c,v 1.43) is committed and surprise, the new kernel does not > boot anymore. I suggest you try out the 1.44 version that has been committed since and let me know what that brings. At any rate I'd be interested in a full verbose dmesg from the machine... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
It seems Alex wrote: > > You need to update.. > > > OK - I've just updated. Here goes again: > > ata1-slave: ata_command: timeout waiting for intr > ata1-slave: identify failed > ad0: 6194MB [13424/15/63] at ata0-master using > UDMA33 > acd0: CDROM at ata1-master using PIO4 > Mounting root from ufs:/dev/ad0s2a > I wouldn't be surprised if ATAPI_CMD_IDENTIFY failed on ata1-master, but > why does it say ata1-slave? It's a notebook PC, so unfortunately I'm > not sure how it's all connected. Apparently it thinks something is there, could you mail me a complete verbose bootlog (dmesg) please, and I'll try to figure out what is going wrong.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of ATAisms...
It seems Alex Zepeda wrote: > I haven't been able to mount an msdos (FAT16) formattted zip disk (well > any FAT16 formatted zip disk) for quite a while. Currently I'm trying to > mount afd0s4, but no such luck (I think the latest error is something > about reading the partition table). The wd driver used to grok the same > disks. Any thoughts? I still have that on my list, but I've not gotten down to it yet, sorry... > P.S. Soren, thanks for the burncd program. So far I've had more luck > with it than the Adaptec s/w that came with the drive. Glad to hear that _something_ works :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of ATAisms...
It seems Alex Zepeda wrote: > On Wed, 26 Jan 2000, Soren Schmidt wrote: > > > I still have that on my list, but I've not gotten down to it yet, sorry... > > Well as long as I've got the wd driver, I'm fine. > > Anything in perticular where I might be able to help in fixing this? You could try to do a dd of the first say 2 cyls of the ZIP with both drivers and check is they are different, they shouldn't be... > > > P.S. Soren, thanks for the burncd program. So far I've had more luck > > > with it than the Adaptec s/w that came with the drive. > > > > Glad to hear that _something_ works :) > > Well I haven't updated my kernel yet. *grin* Yeah, progress does have its victims :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of ATAisms...
It seems Alex Zepeda wrote: > On Wed, 26 Jan 2000, Soren Schmidt wrote: > > > You could try to do a dd of the first say 2 cyls of the ZIP with > > both drivers and check is they are different, they shouldn't be... > > How many bytes is this again? Erhm, I've forgotten the geometry of the zip, just be sure to have the first two tracks. > > > > Well I haven't updated my kernel yet. *grin* > > > > Yeah, progress does have its victims :) > > Progress is indeed overrated. > > I wanna play mp3s through the pca device! ;) Wow! I havn't used the pca dev in years, but it should work I guess given the right bitrates etc :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of ATAisms...
It seems Alex Zepeda wrote: > On Wed, 26 Jan 2000, Soren Schmidt wrote: > > > Erhm, I've forgotten the geometry of the zip, just be sure to have > > the first two tracks. > > [counting on fingers, then toes, then kunckles ensues] > > afd0: 96MB (196608 sectors), 96 cyls, 64 heads, 32 S/T, 512 B/S > > first 16k? Make that 2M just to be sure.. > zippy:~#dd if=/dev/afd0c bs=1k count=16 of=afd0c.output > dd: /dev/afd0c: Input/output error > zippy:~#Jan 26 00:38:32 zippy /kernel: afd0: error reading primary > partition table reading fsbn 0 > > Hmm. I know this disk works with Windows 98SE. Well, if it has problems with the partitions you should use /dev/afd0 and /dev/wfd0. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIC SD-11 not happy with ata
It seems Russell L. Carter wrote: > > Yah... as before ok I fixed this by swapping in an ASUS K7M (forget the audio, > I can't figure that one out) Working on it :) > For all of the bitching on Soren's ata driver, I'd like to > make this observation on a 500MHz/256MB ASUS K7 systemm, bonnie -s 500: > > ad1: 19574MB [39770/16/63] at ata1-master using UDMA66 > > Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... > ---Sequential Output ---Sequential Input-- --Random- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks-- > MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CU > 500 20650 84.1 20805 30.8 5644 14.8 22111 86.2 21253 21.1 148.9 1.4 > > Um, that ad1 drive cost me $224US, direct from the IBM mothership. Yup, those new IBM drives (the DPTA series) are pretty cool -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
It seems Alex wrote: > > OK - here's the part relevant to ata: > > > ata-pci0: port 0xfcf0-0xfcff at device > 1.1 on pci0 > ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xfcf0 > ata0: mask=03 status0=50 status1=00 > ata0: mask=03 status0=50 status1=00 > ata0: devices = 0x1 > ata0 at 0x01f0 irq 14 on ata-pci0 > ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xfcf8 > ata1: mask=03 status0=00 status1=00 > ata1: mask=03 status0=00 status1=00 > ata1: devices = 0xc Here it sees two devices, apparently you cdrom is reacting both on master AND slave addresses :( > ata1-slave: ata_command: timeout waiting for intr > ata1-slave: identify failed But when we try to talk to it it fails... > ata0-master: success setting up UDMA2 mode on PIIX4 chip But when we try to talk to it it fails... > Any ideas? I'll try to come up with a patch that solves this... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange ATA stuff (was: ep0 incorrectly probed)
It seems Edwin Mons wrote: > On Thu, 27 Jan 2000, Matthew N. Dodd wrote: > > On Thu, 27 Jan 2000, Edwin Mons wrote: > > > and the setup continues as if nothing has happened. The drive is > > > configured as PIO mode 4 in the BIOS (the BIOS does not support UDMA, > > > the chipset apparently does). Any pointers? > > > > Humm... Try mode 'Auto'? > > Did that. Didn't make any difference. Gave the same results either way. > Could be a weird harddisk <-> IDE controller problem. Not a real problem, > though. Everything appears to work just fine. it does, its harmless, its removed from the list when this happens... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Errors compiling kernel...
It seems Will Andrews wrote: > On Thu, Jan 27, 2000 at 07:31:50PM -0500, Donn Miller wrote: > > I recently cvsup'd the sources (around Thu Jan 27 19:30:48 EST 2000), and > > I'm getting these errors compiling the kernel: > > > > cc -c -mpentium -O3 -pipe -Wall -Wredundant-decls -Wnested-externs > > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > > -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL > > -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../dev/ata/atapi-all.c > > ../../dev/ata/atapi-all.c: In function `atapi_attach': > > ../../dev/ata/atapi-all.c:96: syntax error before `}' > > *** Error code 1 > > Soren Schmidt (sos) made some recent commits to the ATA driver. Perhaps > these problems are the result. Yup, braino on my part, fixed now. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of ATAisms...
It seems Alex Zepeda wrote: OK, I got my junkbox back into commission today, I just need to get it update into -current, then I'll take a stab at it... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: panic with new sysctl variable
It seems D. Rock wrote: > Hi, > > just noticed the new sysctl variable for ata. I just wanted to > use the new way for disabling DMA on my disk (has some strange > problems, even under windows). > > Previously I just commented out the ata_dmainit() lines in > ata_disk.c, now I wanted to set it with sysctl: > > sysctl -w hw.atamodes="pio,dma,dma,dma" > > but this paniced my machine. > > I later discovered that there is no sanity check during setting > the new modes: The machine in question didn't have a secondary > IDE controller, but the variables were set without a range check. > > My solution was simple. Just use > sysctl -w hw.atamodes="pio,dma" > > but I think, the ata driver should range check the settings. It does but not for the first two devices as the are kindof magic in some sense. I'll commit the fix asap.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still problems with latest ATA
It seems Kris Kennaway wrote: > My CDROM still refuses to work with cdcontrol, although the 30-seconds of > kernel spinning is now fixed. > > Trying to play a track gives: > > acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 I'll bet this drive doesn't support PLAY_BIG but only PLAY_MSF. The problem here is that PLAY_MSF's parameters are either in binary or in BCD, but you dont know which one to use, as this is screwed in more drives than those missing PLAY_BIG. > One of my WDC's still falls back to PIO mode at boot time (see previous > messages, nothing has changed). Its not able to do DMA then, besides cluttering up the console with the retries, it does work afterwards right ? > If anything has changed in the verbose boot I can provide a copy of it, > otherwise all my relevant details are in the archives from previous > messages.. Send me one, there are a few changed items, I'll see what can be done... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still problems with latest ATA
It seems Kris Kennaway wrote: > On Sun, 30 Jan 2000, Soren Schmidt wrote: > > > > Trying to play a track gives: > > > > > > acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 > > > > I'll bet this drive doesn't support PLAY_BIG but only PLAY_MSF. > > The problem here is that PLAY_MSF's parameters are either in > > binary or in BCD, but you dont know which one to use, as this > > is screwed in more drives than those missing PLAY_BIG. > > This drive worked fine under wcd. It would be kind of disconcerting to be > told that my CD is no longer supported and I have to buy a new one. Hmm, I'll have to check up on the exact model then... > > > One of my WDC's still falls back to PIO mode at boot time (see previous > > > messages, nothing has changed). > > > > Its not able to do DMA then, besides cluttering up the console with > > the retries, it does work afterwards right ? > > It works fine afterwards, but according to > > http://www.westerndigital.com/products/drives/specs/oldspecs/AC26400.html > > it is certainly DMA-capable. It *does* say, interestingly, that older > versions cannot do Ultra ATA 66 (I purchased this as an Ultra ATA 66 > drive, but..). I'll see what the diagnostic utility has to say about > it. I'm sorry to tell you, by my experience with WDC drives are, well, not good, there has been lots of flukes. The latest ones that is relabeled IBM drives works just fine though. Ssdly the same can be said about Maxtor. For a laugh grep for all the blacklisted drives in the Linux drivers :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata: Mount root failure: 6
It seems Alexander Langer wrote: > For the archive of this ml: > > Some of the commits over the time since I got this error solved the > problem silently. > > I'm now using ata this machine w/o any problem. > > On another machine that had problems with DMA with the old wd drivers > UDMA33 now works ok, too. Nice. > > Thanks! You're welcome, glad to hear it finally worked for you too... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Nasty messages from ATA
It seems Peter Jeremy wrote: > Yesterday, I upgraded my system from mid-Jan to the latest > (cvs-cur.6044) to see if it would cure some hard-hangs. > > Last night, I got the following messages: > > Feb 1 18:00:21 gsmx07 /kernel: ad2: ad_timeout: lost disk contact - resetting > Feb 1 18:00:21 gsmx07 /kernel: ata1: resetting devices .. done > Feb 1 18:00:21 gsmx07 /kernel: ad0: ad_timeout: lost disk contact - resetting > Feb 1 18:00:21 gsmx07 /kernel: ata0: resetting devices .. ata0-slave: timeout >waiting for command=ef s=00 e=64 > Feb 1 18:00:21 gsmx07 /kernel: done > Feb 1 18:05:40 gsmx07 /kernel: ad2: ad_timeout: lost disk contact - resetting > Feb 1 18:05:40 gsmx07 /kernel: ata1: resetting devices .. done > Feb 1 18:05:40 gsmx07 /kernel: ad0: ad_timeout: lost disk contact - resetting > Feb 1 18:05:40 gsmx07 /kernel: ata0: resetting devices .. ata0-slave: timeout >waiting for command=ef s=00 e=64 > Feb 1 18:05:40 gsmx07 /kernel: done > > The system should have been virtually quiescent at this time. Any > suggestions? I am running soft-updates. > Feb 1 11:49:38 gsmx07 /kernel: ad0: 6187MB [13410/15/63] at >ata0-master using UDMA33 > Feb 1 11:49:38 gsmx07 /kernel: ad2: 1222MB [2484/16/63] >at ata1-master using WDMA2 Try to switch of DMA on ad2 with the systel like documented ata.4 and see if that helps... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My ATAPI CD not come ready
It seems Alex wrote: > > Mike, I couldn't find your fix in the commit logs - perhaps someone else > committed it? Do you have the revision number? The problem still > persists: > > ata1-slave: ata_command: timeout waiting for intr > ata1-slave: identify failed > ad0: 6194MB [13424/15/63] at ata0-master using > UDMA33 > acd0: CDROM at ata1-master using BIOSPIO I have it on my list, but remember the error is harmless thus not at the top of my list (yet). -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata (CDROM mount) and PCCARD problems (xe driver) with 4.0
It seems Andreas Klemm wrote: > > b) Can't mount cdrom > > mount /cdrom > Device busy Have you upgraded you /dev entries ?? > # Device Mountpoint FStype Options DumpPass# > /dev/wd0s2b noneswapsw 0 0 > /dev/wd0s2a / ufs rw 1 1 > /dev/wd0s1/dosmsdos ro 0 0 > /dev/wd0s2f /usrufs rw 2 2 > /dev/wd0s2e /varufs rw 2 2 > proc /proc procfs rw 0 0 > /dev/acd0a/cdrom cd9660 ro,noauto 0 0 > /dev/fd0a /floppy msdos rw,noauto 0 0 You should be using ad* for the disks... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Something strange with my ATAPI CD
It seems Eric Jacoboni wrote: > Hi, > > Sometimes, i'm unable to mount my ATAPI CDROM : > > The light of the drive is on, i can hear the drive working, but > nothing... After a while (some minutes), the light turns off, the CD > is not mounted and i can't eject it anymore until a reboot :( > > The curious thing is that, sometimes, i can mount it... > > Here are the relevant messages from dmesg : > ata-pci0: port 0xfcd0-0xfcdf at device 7.1 on pci0 > acd0: CDROM at ata1-master using BIOSPIO Hmm I have that exact same HW in my Latitude, it works very well, have you tried more that one CDROM ?? it could be a bad one -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata1
It seems Klaus Herrmann wrote: > > ad0: 6197MB [12592/16/63] at ata0-master using UDMA33 > [ata1-master: piomode=4 dmamode=2 udmamode=-1 dmaflag=1] > [ata1-master: success setting up WDMA2 mode on VIA chip] > ata1-master: CDROM device - NO DRIVER! > > Fatal trap 12: page fault while in kernel mode OK, I've fixed that one locally, commit pending Why it dont find your CDROM is another matter... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA and DMA
It seems Wes Morgan wrote: > Has there been any resolution to the known-broken-dma drives and the ata > driver? I haven't seen any commits or LINT options to this effect, and it > seems to me that since it is the new default driver that something should > be in place before it goes to -release. Look at the ata.4 manpage, there is a sysctl knob that can change the modes, if it gets too bad we can always make it boot in PIO mode, and then the user can change to known safe DMA modes in rc.something... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freeze with todays kernel when trying to look at ata-zip drive
It seems F. Heinrichmeyer wrote: > when trying to do > > mdir z: > > my current kernel immediately freezes! Yeah, I used a bde patch verbatim, shouldn't have done that :) Fixed. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ata-zip drive is useable again!
It seems F. Heinrichmeyer wrote: > todays current kernel made the ata-zip drive useable again. I know, I committed the fix yesterday, I even mailed you so :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atapi cdr problems
It seems Adriel Ickler wrote: > /dev# dmesg | grep cd0 > acd0: CD-RW at ata1-master using PIO4 > /dev# wormcontrol -f racd0a prepdisk quad > wormcontrol: ioctl(WORMIOCPREPDISK): Inappropriate ioctl for device > /dev# Feb 11 10:13:27 misty /kernel: acd0: READ_TOC - ILLEGAL REQUEST > asc=24 ascq=00 error=00 > > Any thoughts? at this point it looks like bad atapi cdr code in the > kernel. Lots of thoughts, but with this little info we hardly can do anything for you... However given that this is -current, you should have read the -current list, and found out that wormcontrol is depricated, use burncd instead... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic during probe of ide tape drive
It seems Shrihari Pandit wrote: > Hi, I just installed 4.0-2208-CURRENT, > > During the device probe, it detected our IDE tape drive "SuperStation-Int/1.06" > then displayed "NO DRIVER!" and paniced. This was working properly under > 3.4-RELEASE/STABLE. That panic was fixed earlier today, but we have no support for the "SuperStation" as far as I know, not even under 3.4... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABIT BP6 + UDMA66: ad_timeout: lost disk contact
It seems Hans Ottevanger wrote: > Hi folks, > > I am currently having problems with my new Dual Celeron testsystem, > when trying to use UDMA66. > ABIT BP6 > 2x Celeron 466 (NOT overclocked) > 128 Mbyte RAM > Matrox G400 16 MByte > 3Com 905B > 2x Maxtor 92041U4 20 GByte > Aopen CDROM 48x > When I use the UDMA33 disk, no problem occurs at all, I can even run > "make buildworld" without any problems. When accessing the disk on the > UDMA66 channel however, the system regularly hangs, followed by a First of, you have to use a very current -current, I've committed some fixes to the HPT/Promise code resently that are vital to making this work. If you are using the newest code, then the problem might be that your disks doesn't work proberly with UDMA66. I've seen several newer disks that has problems here, and frankly Maxtor is not known for their quality in this respect. You could try to disable the UDMA66 code on the HPT chips by ifdef'ing out the code that deals with it like below, if this helps you are most like dealing with disks that has problems with UDMA66. Dont be alarmed though, there is next to no performance difference for you... Trying another disk is also an option, I know that the IBM's work just fine, and that some of the Quantums and WDC's are broken. Index: ata-dma.c === RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v retrieving revision 1.31 diff -u -r1.31 ata-dma.c --- ata-dma.c 2000/02/04 10:20:21 1.31 +++ ata-dma.c 2000/02/12 18:43:47 @@ -435,7 +435,7 @@ if ((device == ATA_MASTER && scp->devices & ATA_ATAPI_MASTER) || (device == ATA_SLAVE && scp->devices & ATA_ATAPI_SLAVE)) break; - +#if 0 if (udmamode >=4 && !(pci_read_config(scp->dev, 0x5a, 1) & 0x2)) { error = ata_command(scp, device, ATA_C_SETFEATURES, 0, 0, 0, ATA_UDMA4, ATA_C_F_SETXFER, ATA_WAIT_READY); @@ -449,6 +449,7 @@ return; } } +#endif if (udmamode >= 2) { error = ata_command(scp, device, ATA_C_SETFEATURES, 0, 0, 0, ATA_UDMA2, ATA_C_F_SETXFER, ATA_WAIT_READY); -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABIT BP6 + UDMA66: ad_timeout: lost disk contact
It seems Ashley Penney wrote: > > [Incidently, since then I've had another timeout or two, but it doesn't > kill the machine anymore. Sos, is there anything I can do to help find > out what's causing this?] Hmm, could you send me a complete verbose boot dmesg ?, just so I can get an idea on your setup. You shouldn't se timeouts, but an occasional ICRC error is to be expected. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABIT BP6 + UDMA66: ad_timeout: lost disk contact
It seems Marius Strom wrote: > Hans and others, > I have the same situation - happy to get a new motherboard and processor, > unhappy to hang FreeBSD. My situation is different, however - I'm running > single processor currently and it still hangs. I've also experienced this > issue with and without softupdates. What make of disk are you using ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lots of ad_timeouts
It seems Don Croyle wrote: > I recently moved one of my machines to -current and I see a lot of > these when I do buildworlds and other large builds. With a kernel > built yesterday after the last set of ATA changes and and boot_verbose > set, the exact message is: > > ad0: ad_timeout: lost disk contact - resetting > ata0: resetting devices .. ata0: mask=03 status0=52 status1=00 > ata0-master: success setting up WDMA2 mode on PIIX4 chip > ata0-slave: timeout waiting for command=ef s=10 e=60 > ata0-slave: failed setting up PIO3 mode on generic chip > ata0-slave: using PIO mode set by BIOS > done Did you run with DMA enabled before the upgrade ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lots of ad_timeouts
It seems Don Croyle wrote: > I really can't tell you for sure. This machine had been running > 2.2.8 before, and I didn't think to save a dmesg before I wiped it and > reinstalled from a snapshot. Aha! 2.2.x didn't do DMA at all > If it would help, I'll try setting it to PIO with sysctl and doing > another buildworld. It probably will... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message