Re: Why is ATAPI DMA disabled by default ?
It seems Maxim Konovalov wrote: > > > I use 5.1-current and have found that by default FreeBSD disables ATAPI's > > support for DMA transfers and thus uses CPU hungry PIO modes. > > It even makes sysctl used to change this read-only. > > I had changed the default value of atapi_dma to 1 in dev/ata/atapi-all.c to 1 > > and it worked fine for me. > > Hint: put hw.ata.atapi_dma="1" in /boot/loader.conf. Or just use atacontrol to change the mode once the system is running... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ultra ATA card doesn't seem to provide Ultra speeds. - SOLVED
It seems Buckie wrote: > Hello folks. > Some of you may remember my trouble with SI0680-based ULTRADMA ATA > controller card. Well, the problem was obvivously the faulty card. > After replacing it works fine. > > I don't know what magic Soeren has put in the SI driver, but unlike > Windows it never crashed, never hang, it even tried to use UDMA modes. > So kudos to Soeren for writing quality drivers like that one. > > I also remember Peter Kiesser has had some issues with drives falling > back to PIO with SIS controller. I had this too on the drive that FreeBSD5.1_RELEASE > used to start > from. So now we know this can be an issue with a broken controller. > (It doesn't fall back to PIO here after replacement is made). Again, > thanks to Soeren it just magically worked (as best as it could > obvivously) in spite of all the fish. > > That's all! OK! then I dont need to spend more time looking for trouble on that one :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
It seems Kenneth Culver wrote: > > > Guess I just didn't look hard enough or in the right place. I only spent a > minute or 2 on it, but yeah ATA drives don't tell you that sort of thing, > they say stuff like "ATA133 for a max transfer rate of 133 MB/sec *" then > at the bottom the * says something like "133 MB/sec burst rate from drive > to controller" or something similar. But I did try fairly hard to find > specs on our Seagate drives and couldn't find a hard number that told what > the maximum read and write speeds were. Thats maybe true for some drives, but generally they state this info in their docs, for the Diamond 9+ it took me < 10 secs to find the below transfer speeds, I did have the PDF handy though :) Disk to Read Once a 236Mb/sec 236Mb/sec236Mb/sec 236Mb/sec Revolutionmminimumminimum minimum minimum 433Mb/sec 433Mb/sec433Mb/sec 433Mb/sec maximummaximum maximum maximum Disk to Read 257Mb/sec 257Mb/sec257Mb/sec 257Mb/sec Instantaneously minimumminimum minimum minimum 472Mb/sec 472Mb/sec472Mb/sec 472Mb/sec maximummaximum maximum maximum -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
It seems Kenneth Culver wrote: > > What I find fascinating is that Maxtor's site never actually tells you > > the true throughput of that disk anywhere. > > http://www.maxtor.com/en/products/ata/desktop/diamondmax_plus_9/ > > Almost none of the hard disk manufacturers do. In fact I've never seen > "true throughput" numbers from ANY manufacturer. Maybe not, but they do give a transferspeed from medium range and that is what can be expected. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
It seems Buckie wrote: > I ran a dd: > dd if=/dev/ad1 of=/dev/zero ibs=8192 > ...and cancelled it after some amount of time: > 2321+0 records in > 37136+0 records out > 19013632 bytes transferred in 27.876118 secs (682076 bytes/sec) > > I don't use static2 ata device numbering hence Maxtor is assigned ad1, > but it would be ad4 if things were static. > > Experiemnting with ibs value I can get speeds of up to 16MB per > second. But no more. OH, you need to output to /dev/null NOT /dev/zero :) besides that, all looks OK, but you need a fairly large bs to se improvments on this (relatively slow) machine, try a bs of 1m and see if that helps, if not there is something slowing down your system.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
It seems Buckie wrote: > Hello hackers! > > I hope someone can help me with this since you know the internals of > FreeBSD much more than me. Hope it doesn't take much time. > > The sort of problem I'm having is this: after installing a new Ultra > ATA card (it's based on Silicon Image 0680 chip by the way) although > the disks start to run at UATA6 (133) mode (as seen in dmesg output or > atacontrol), I see absolutely no > improvement compared to WDMA2 mode they used to run previously. I > still can get around 14Mb/s on dd transfers, but there has to be > more? My motherboard only supports WDMA2 mode and nothing more and > that's why I bought the card. Is there any trick I forgot to apply? > The drive is Maxtor 120Gb Diamond Plus 9. > Also, file transfers from mounted NTFS seem to be very very slow, much > slower than UFS transfers, what gives (when using mkisofs for example > for burning CDs)? > > Hope someone can shed some light on this... Possibly, but you need to give us info so we can try to diagnose the problem "it doesn't work" it not enough, so please provide at least: FreeBSD version (output of uname -a) Boot log (output of dmesg) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: prospects for DMA support for SiS962(L) Southbridge?
It seems Rich Morin wrote: > I recently upgraded my motherboard and CPU, as: > >478 pin Celeron; 2.1 GHz >512 MB DDR DIMM (2 ea.) >SiS962(L) Southbridge > > I then found that I couldn't boot the (FreeBSD 4.7) system, getting: > >ad0: READ command timeout tag=0 serv=0 resetting >ata0: resetting devices > > After a bunch of Googling and some discussions on freebsd-questions, > I decided to change line 90 of /usr/src/sys/dev/ataata-disk.c to: > > static int ata_dma = 0; > > This works, but I suspect that it is slowing down my disk I/O quite a > bit. So, I would like to know the prospects for this controller being > supported in FreeBSD any time soon. It is supported in 5.1. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Backporting burncd w/VCD support to 4.5-REL-p24
It seems D J Hawkey Jr wrote: > > Doing a backport to 4.5 will include changes to the ATA driver in the > > kernel as well as to burncd, and is not a trivial matter... > > I feared as much. Would this be the ATAPICAM (?) stuff done for 4.6? > OTOH, I backported the ICH sound support to 4.3; I'm not afraid of > tinkering with the kernel. But p'raps this comparison is apples and > oranges in terms of complexity. I have no idea about the ATAPICAM stuff, what I'm talking about is the hooks for burncd etc... > > It would be far easier to upgrade the system to something newer like > > at least 4.7 where the support is already in... > > I realize this, of course. I'm hesitant to do this because some of my > hardware is pretty old now, and I fear that the newer ATA/ATAPI sub- > system may not like some of my hardware. I do recall quite a few posts > about problems with the newer subsystem, but then again, quite some > time has passed now. Well, you need the new ATA/ATAPI system for this to work I'm afraid... > Lemme ask you this, then: Given a FBSD 4.5 system, is the CAM xpt > module patch (T. Quinot) and cdrecord a [more] viable option? Or am > I basically SOOL? I have no idea, others might have the answer to that.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Backporting burncd w/VCD support to 4.5-REL-p24
It seems D J Hawkey Jr wrote: > Hi all. > > Per the subject, how much work will it be? > > For giggles, I grabbed the earliest burncd from CVS that supports VCD, > saved off my /usr/src/usr.sbin/burncd, then: > # cd /usr/src/usr.sbin/burncd > # make all > The build puked on a few CDR* definitions, and a bunch of other stuff. > Later versions than the version I grabbed want stdint.h (which I don't > have), so I shied away from that. > > Can anyone (Soren?) tell me what all I need to pull this off, and not > break the rest of the system? If it's easier to build up a Makefile to > build it outside of /usr/src, I'd be game to try that, too. Doing a backport to 4.5 will include changes to the ATA driver in the kernel as well as to burncd, and is not a trivial matter (and IMHO not worth the effort as an update will do nicely)... It would be far easier to upgrade the system to something newer like at least 4.7 where the support is already in... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone useing ATI All-in-wonder cards with xawtv ?
It seems Dan Nelson wrote: > In the last episode (Apr 09), Soeren Schmidt said: > > And have it working ? > > > > I've got it so far (using the GATOS ATI.2 X driver) that I get sound > > but only a black picture. Anyhow tuner setup and channel programming > > etc works, just no video.. > > Move the display window slightly or resize it. That works for me (ATI > AIW Pro 128). No change, still blank window, what version of X are you using ? However this is a RADEON AIW (R100 based) so that might make the diff... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 3 IDE devices on Promise card + FreeBSD == not possible?
It seems Pete wrote: > On Mon, 10 Mar 2003, Søren Schmidt wrote: > > > No, thats not the case, the ATA driver has a built in RAID engine > > to use with Promise and HighPoint controllers. The reason it is > > like this is that it is nessesary to read the RAID config off the > > disks in a vendor specific way, and neither of cdd/vinum could do > > this when its was done. > > So, if I were to create the RAID-1 volume with atacontrol, I'm tied to > using the Promise controller? Could I move the drives to a > Highpoint-based controller or just a plain on-board ATA interface and > still have the RAID volume accessible? If I want this kind of > flexibility, should I move to Vinum? If you want to boot from the array you need to have the array config in a way that fits the controller, if thats not needed you can move around as you see fit, you can even make ATA RAID's on any ATA controller not just Promise or Highpoint as loong as you wont boot from it. I guess I should make an option to atacontrol that can convert between HPT/Promise format or maybe just silently write both to the disks ;) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3 IDE devices on Promise card + FreeBSD == not possible?
It seems Dag-Erling Smorgrav wrote: > Pete <[EMAIL PROTECTED]> writes: > >> atacontrol create mirror ad6 ad7 > > This is starting to _really_ confuse me. Does FreeBSD have two software > > RAID systems? > > Yes (vinum and raidframe) And ccd :) > >Is there something built into the ATA controller drivers > > that can do software RAID too? It looks that way from that atacontrol > > and ata man pages. > > No, but atacontrol knows how to configure hardware RAID controllers > such as your Promise FastTrack. No, thats not the case, the ATA driver has a built in RAID engine to use with Promise and HighPoint controllers. The reason it is like this is that it is nessesary to read the RAID config off the disks in a vendor specific way, and neither of cdd/vinum could do this when its was done. ATA RAID's like the Promise Fasttrak are *not* HW RAID's its a SW RAID engine in the BIOS on those cards. However that is only used for booting from the RAID, and then the ATA driver picks up the array config and uses that with its internal SW RAID engine. Atacontrol just sees a generic ATA RAID interface, and the ATA driver then knows how to r/w the config for a specific controller. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 3 IDE devices on Promise card + FreeBSD == not possible?
It seems Pete wrote: > Hello, > > I've been posting about this since the beginning on the year. A few > times on freebsd-questions, once on freebsd-hackers, and submitted a PR > (http://www.freebsd.org/cgi/query-pr.cgi?pr=48165). I have never found > a solution beyond replacing FreeBSD with Linux. (Which is not something > I'd like to do, but know I can, if need be. I'm trying to learn about > FreeBSD, not Linux.) To make it short, the disklabel problem is probably due to the disk containing what disklabel see as a bogus label, try to zero out the label by using dd if=/dev/zero of=/dev/adN count=100. Now if you have a promise fasttrak its beyond me why you want to use vinum to make a mirror... In the post you refer to you have: ar0: 29314MB [3737/255/63] status: READY subdisks: 0 READY ad4: 29314MB [59560/16/63] at ata2-master UDMA100 ar1: 29314MB [3737/255/63] status: READY subdisks: 0 READY ad6: 29314MB [59560/16/63] at ata3-master UDMA100 ar2: 29314MB [3737/255/63] status: READY subdisks: 0 READY ad7: 29314MB [59560/16/63] at ata3-slave UDMA100 You use ar0 as a single disk and thats fine. Then you need a mirror of ad6 and ad7 to get that you first need to delete ar1 and ar2 (which you have defined in the Promise BIOS to get it past probing right ?). So doing: atacontrol delete ar1 atacontrol delete ar2 Get you rid of those two 1 disk arrays, then do: atacontrol create mirror ad6 ad7 and you get a new ar1 array thats the mirror of ad6 & ad7.. Disklabel & newfs ar1 and you are done (remember the dd trick above if disklabel thinks the label is bogus) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: booting from Promise tx2000: FIXED
It seems Dag-Erling Smorgrav wrote: > Len Conrad <[EMAIL PROTECTED]> writes: > > while waiting for Soeren Schmidt to get the Promise SX4000 driver done! > > I was under the impression that the SX4000 and SX6000 were already > supported? I know that phk has an SX6000 which he says works fine. > OTOH, it's possible that this hasn't percolated down to -STABLE yet. The SX6000 is supported, the SX4000 is quite a different animal and is not supported yet. However I'm working with Promise to write support for it... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SiS pciconf's request ending :)
Thanks to all those that replied with pciconf output from various SiS chipsets (and thanks to those that sent from other systems as well :) ). I now have a significant amount of data to use for the SiS chipset support, and am working on it over the next days.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Request for info from SiS chipset owners
I'm currently in the midst of an ATA chipset support mega rewrite/update, and the last item on the list is SiS support. That where _you_ come into the picture, I need a pciconf -l from your SiS based system! Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Promise ATA133 controller
It seems Travis L. Leuthauser wrote: > none3@pci2:14:0:class=0x018085 card=0x1275105a chip=0x1275105a > rev=0x01 hdr=0x00 > vendor = 'Promise Technology Inc' > device = 'PDC20275 FastTrack TX EIDE Controller' > class= mass storage > > Running 4.7 Stable as of today around 2PM CST. OK, thats Yet Another Promise chipid, I'll commit the needed bits asap... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Promise ATA133 controller
It seems Travis L. Leuthauser wrote: > Is anyone currently working on support for the Promise PDC20275 FastTrack TX > EIDE Controller, which comes on the AOpen AX4B Pro-533 for ATA133? If so, > is there an ETA for support? Should be supported already... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pst: timeout mfa=0x00328210 cmd=WRITE
It seems Abel Alejandro wrote: > Hello, I am getting this error like 5 or 10 times > then my box crashes. I have tried both 4.7-RC and > 5.0-RC2 and both crash after having displayed this > message a few times. It shouldn't crash since the requests are retried and then usually succeeds, however I'm currently working on this driver for something else, and I might have found the cause of this problem, more when I have gotten a better handle on it... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATA RAID performance
It seems Sean Hamilton wrote: > Greetings, > > I have tried using both atacontrol and ccdconfig to create stripes and > mirrors of various sizes, and have found that in all cases, read performance > *decreased*. Uhm, what kind of disks, stripesize etc are you using, without that info noone can tell you why... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: burncd raw mode
It seems Stijn Hoop wrote: > > Not as is, but it could be done, however there is absolutly no point > > in doing it, *unless* its to make an exact copy of a CD that is > > copyprotected in one of the usual ways. > > OK, but what if it is? Tools, not policy? I didn't put any policy in there you just did :) I have some local hacks that I've used for testing cuesheets, but nothing thats really usefull.. > > Thats a long explanation, its checksumming etc etc. > > Actually, is it the driver that constructs this metadata, or mkisofs, or ... ? The burner construct the metadata in case of a mode1 data disc, so that checksumming etc is done the right way, and thats the reason why doing it yourself is a vaste of time unless you want to but "special" data in there. > For making a backup of my PSX CDs to play with an emulator? (perfectly legal > for me to do). Windows apps can do this. Rip the cd as 2352 bytes, rip out the 2048 you need and use the XAmode1 datatype to burncd IIRC, and you need a bootchip :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: burncd raw mode
It seems Sean Hamilton wrote: > Greetings, > > I have a 2352-byte block mode1 CD image, and wish to burn this with burncd. > I know I can use bin2iso or bchunk to decode it, but I'd rather keep the > block metadata intact from the file itself instead of having the > burner/driver(?) reconstruct it. > > I assembled a small stack of coasters by trying a few combinations of -d, > 'raw', etc, to no avail. The best I got was from raw, a track which needed > to be read with 2352 byte blocks, so it wasn't being interpreted as > metadata. I presume if I were to dd this entire disc into a file, I would > have a verbatim copy of my original, albeit less fault tolerant. > > Can this be done with burncd? Not as is, but it could be done, however there is absolutly no point in doing it, *unless* its to make an exact copy of a CD that is copyprotected in one of the usual ways. So, assuming you have a legit image, you simply rip out the 2048 bytes of real data from each 2352 byte block in that file, and burn it as a normal data CD, bingo.. > How does the drive/driver know to interpret the remaining 304 bytes as > metadata? Thats a long explanation, its checksumming etc etc. > Is it possible to extract the full 2352 byte blocks from a track which is > advertised as only 2048, ie a typical data track? There are a few Windows > apps for doing exactly this. Sure it is, but why would you need to ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATAPI vs ATA disk
It seems Eduard Martinescu wrote: > > I am trying to port the 'smartmontools' package from sourceforge.net to > FreeBSD. However, I am running into some issues. I need to be able to > send SMART commands (and read responses) to ATA disk drives. At first > glance, it looked like the generic ATAPI layer would work great, but I > have found that the ATA disk drives do NOT support generic ATAPI > commands (through that ATAPICMD ioctl). > > So now I am at a loss as to how best to proceed. Should I just patch > the code in ata-all.c that looks for an ATAPI_MASTER or SLAVE device? > (and allow a ATA_MASTER and SLAVE) to receive ATAPI commands? Should I > try to work up a new IOCTL to support ATAPI commands to ATA disks? > Should I add IOCTL support to the AD device driver? I have a patch coming up that supports the SMART commands, interpreting the data will be left to userland (where smartmontools might be able to do the job)... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Show me the light
It seems Ronald G Minnich wrote: > On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: > > > As far as I remember, there is open collector output > > on parallel port, so your wish impossible %-) > > oops, I forgot that little deal. Yup, you need a pullup. Only the control signals are OC, the databits are tri state. Actually, depending on how many databits one needs, the rest can be used to provide a usable powersupply when they are set to '1'. I use that for an 8chan AD converter that then fit into the parport plug housing and no need for an external power supply. But beware the current you can get this way is very limitted... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
It seems Juli Mallett wrote: > > Find another box where it has already been successfully installed, > > and an ISO image has been built from sources. > > I don't have a CD burner. I have no ability to burn a CD at all. Where do you live ? I'm sure we can find someone with a CD burner near you willing to make a copy and snailmail it to you... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sil vs. SiI
It seems Hanspeter Roth wrote: > On Oct 11 at 09:01, Soeren Schmidt spoke: > > > The Sil 680 does support ATAPI DMA, I'll need to dig out the older > > I have an Enmic installed which reports > atapci1: port [...] > > Is this reported literally by the controller or is it derived from a > table lookup? >From a table, seems I could use better glasses :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sil 0648/0649/0680 supporting DMA for ATAPI?
It seems Hanspeter Roth wrote: > On Oct 11 at 09:01, Soeren Schmidt spoke: > > > The Sil 680 does support ATAPI DMA, I'll need to dig out the older > > Would this also cover Dawicontrol Ultra DMA 133 RAID which is > claimed to be built upon SiI 0680? Yes, if its a Sil 0680 chip then it'll work, the one I've got is a Sunix SNX 3700, its a feature of the chip not the card (unless the maker really screwed up something) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sil 0648/0649/0680 supporting DMA for ATAPI?
It seems Hanspeter Roth wrote: > On Oct 05 at 15:05, Soeren Schmidt spoke: > > > Too late, I've already added support for the Sil 0680 chip in both > > -current and -stable. BTW it was not supported before that (not even > > Does any of the Sil 0648/0649/0680 support DMA for ATAPI devices, > particularly for Plextor CD-R PX-W4012A? The Sil 680 does support ATAPI DMA, I'll need to dig out the older CMD64[89] to be able to give a definite answer on those.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CMD Tech. PCI-0680 Driver
It seems William M. Grim wrote: > Anyway, I'm looking to update the ATA driver so that my new ATA/133 card > with a Silicon Images' PCI-0680 chipset works. I bought the card from > CMD Technologies. Apparently, ata/33 on up to ata/100 is supported for > their line of cards according to the 4.6.2 release notes. Too late, I've already added support for the Sil 0680 chip in both -current and -stable. BTW it was not supported before that (not even the slower ata33-100 modes). -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IBM ATA Deskstars *without* tagged queueing?
It seems Hellmuth Michaelis wrote: > support. I asked for a cross update program to get IBM firmware; they > had none. They wrote one :-), i got it and now my drive does tagged > command queueing. Well, I've always liked IBM's as well, anyhow do you still have the update program ? I'd like to add that to my collection. (One of these days I really should find out how they do the firmware download)... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: READ_BIG - ILLEGAL REQUEST at very end of CD
It seems Robert Watson wrote: > Yeah, it's odd actually. I burnt myself a CD this morning using my Mac OS > X box, and it appeared to be fine on an older -CURRENT box and on the Mac. > Stuck it in my far-more-recent -CURRENT box and it died horribly. Or at > least, it gave the same error you're reporting. I'm going to try to track > it down -- the three suspects are (1) the marker I used to write on the CD > was more caustic than I thought, (2) my CD-ROM drive is broken in my > notebook and it went undiscovered until now, and (3) something changed in > the ATA code to cause me suffering. Hmm, it could be that the size calculation fails for some setups (again, we have suffered pain here before due to various incarnations of drive firmware), causing the driver to try issueing a read that goes beyond EOM. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB->ATA devices
It seems Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Soeren Schmidt writes: > >It should be possible to hide the USB stuff under the ATA_* macroes > >or even just under bus_space_*. > >I need a bit more concrete details on how to call into the USB > >code, then it should be pretty easy to add... > > This would be hard to do right, as the preferred way to talk to USB > devices is with a request-callback model. The ATA command would > need to be put into a request structure and handed to the USB device > driver, and the USB driver would then call back when the request > completes. There are hacks that can be used to perform the USB > operations synchronously, but they generally do not handle unexpected > removal of the device well at all. > > There are many possible ATA/ATAPI over USB protocols, so turning > the ATA request into one or more USB transfers is a bridge-specific > operation. Basically these odd protocols exist because the manufacturers > of the various bridges have decided to cut corners and not implement > the standard USB mass storage interface. Sounds like a can of worms better left unopened... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB->ATA devices
It seems Bruce M Simpson wrote: > > If you're interested, I wrote a functional but incomplete driver > > for a similar device, the Prolific Technology PL2307 bridge. I just > > This is good stuff. > > The Onspec expects a command packet containing the ATA register contents > in the order they appear in i/o space. Plus an additional byte whose > meaning I have yet to decipher. > > > implemented the conversion for a minimal set of ATA commands in the > > driver itself; it would obviously be better to have the ATA layer > > in a separate driver though. The code for that driver is at: > > How about doing ata(4) over usb? > > Support was added for PCMCIA to ata in the form of ata-card.c. This > required macro-izing the bus_space_write*() calls amongst other things. Ahem, all the bus_* stuff was done to support other platforms (alpha/sparc) not for the PCMCIA stuff which is very much straight forward... > Normally this takes place over an underlying isa/pci bus abstraction, > maybe we could re-use this abstraction in ata-usb.c to avoid changing > anything here? That way we avoid duplicating the ATA bit-banging code. It should be possible to hide the USB stuff under the ATA_* macroes or even just under bus_space_*. I need a bit more concrete details on how to call into the USB code, then it should be pretty easy to add... > http://www.cuivre.fr.eu.org/~thomas/atapicam/> > > Remember atapicam? I like the fact that it allows one to run cdrecord > with an ATAPI CDRW drive; perhaps it could be re-used and extended to > allow CAM to be used to interact with these pure ATA devices? Of course > in this case, if we make the devices on the USB->ATA bridge look like > ata-disk devices and what have you, who needs CAM? atapicam only does ATAPI, not ATA... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory corruption in CURRENT
It seems Mark Santcroos wrote: > Hi, > > Can you revert back to the system compiler and also compile your kernel > with this options and do some buildworlds again? I already use the system compiler... > On Thu, Aug 22, 2002 at 01:41:13PM +0200, Soeren Schmidt wrote: > > > > Sure, but I dont have the problem :) I can buildworld for days on my > > (heavily overclocked btw) Athlon with no problems at all... > > > > -S?ren -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory corruption in CURRENT
It seems Terry Lambert wrote: > Martin Blapp wrote: > > > options DISABLE_PSE > > > options DISABLE_PG_G > > > > Just added them. I'll now build 20 buildworlds with those enabled. > > Let the list know if it does anything. If Soren could also test, > that would give a sample size. Sure, but I dont have the problem :) I can buildworld for days on my (heavily overclocked btw) Athlon with no problems at all... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory corruption in CURRENT
It seems Martin Blapp wrote: > Hi Soeren, > > > However, this kind of problem in most cases spells bad HW to me, > > ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc... > > That's what I thought too. I have now three different systems which show > all this: > > 1) PIV 1,6Ghz, Intel B845DG Board, 1GB Kingston Ram, > 2) PIV 2Ghz Intel B845DG Board, 1GB Kingston ECC Ram > 3) PIV 2,26 Ghz Asus P4B533 Board with I845 chipset, 1GB noname Ram > > All running CURRENT. I also replaced in 1) and 2) the CPU, RAM. > It happens both on SCSI and ATA disks. Powersupply has been changed > for all 3 systems. Problem is still the same. > > The problem sometimes appears just after startup. CPU is still cold then. > Other times it builds 6 buildworlds sucessfully, and then suddenly I see > a SIG4. Hmm, thats probably a P4 problem then, I dont see it on any of my systems (P3 + K7) I dont have a P4 here (and newer will unless left at my doorstep), and I have no immediate ideas other than trying a MB that doesn't have a i845 chipset (the less Intel parts the better :) ) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory corruption in CURRENT
It seems Martin Blapp wrote: > > Hi all, > > I suspect all the SIG4 and SIG11 problems we see are due > memory corruption in CURRENT. > > The file is correct after a reboot, so the corruption was limited to the > > copy cached in RAM. > > Thats memory corruption. I'm also not able anymore > to make 10 buildworlds (without -j, that triggers > panics in pmap code). > > Bye the way, I'm experiencing this since about 4-5 months. > > All hackers, please help to track this down. Hmm, I haven't seen this at all, but I've just started buildworld loops on two machines here, but I normally do at least a couble buildworlds a day and I havn't notice problems like the above (but plenty of bad commits etc). However, this kind of problem in most cases spells bad HW to me, ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: offtopic: low level format of IDE drive.
It seems Julian Elischer wrote: > One of my FreeBSD development boxes had a hernia last week when it lost > power while writing to disk. The drive wrote out garbage to a track. > > I want to reformat the drive, (low level) but the bios doesn't have any > support to do this (In the past That is how I did this). > The machiine has 1 CD drive and no floppy.. > > anyone with any ideas as to how one can reformat a hard drive feel free to > lend me a clue.. On modern disks you generally cannot do a lowlevel format (like in the old MFM & RLL days) although many disks will accept the command but will do absolutly nothing, well some will do a rescan for bad blocks.. Now if you want to get rid of "bad sectors" you should simply do a dd if=/dev/zero of=/dev/adX bs=1m and the disks *should* rewrite the sectors and remap them if they are really bad... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: process hang in atprq state
It seems Soeren Schmidt wrote: > It seems Richard Nyberg wrote: > > Hi there. > > I seem to have some problems with my cd read program. > > > > I've attached a small prototype program that for some reason hangs > > in atprq, even though I use a timeout of 5 seconds. The program reads > > a cd in raw format using the MMC READ_CD command. It works fine :) > > except that it never manages to finish because of the hang. The hang > > doesn't seem to be linked to any specific place on the cd, but it might > > be linked to my ignorance ;) > > Uhm, you just need to set the blocksize on the CD device with the > CDRIOCGETBLOCKSIZE and then just read the CD with > dd if=/dev/acdX of=fil bs=2352 > That will read the CD in RAW mode... Oh, I forgot to tell you that it hangs because you have to stop reading at the last block, the drive will try to read anything you ask it to, but some drives newer return data for nonexistin blocks.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: process hang in atprq state
It seems Richard Nyberg wrote: > Hi there. > I seem to have some problems with my cd read program. > > I've attached a small prototype program that for some reason hangs > in atprq, even though I use a timeout of 5 seconds. The program reads > a cd in raw format using the MMC READ_CD command. It works fine :) > except that it never manages to finish because of the hang. The hang > doesn't seem to be linked to any specific place on the cd, but it might > be linked to my ignorance ;) Uhm, you just need to set the blocksize on the CD device with the CDRIOCGETBLOCKSIZE and then just read the CD with dd if=/dev/acdX of=fil bs=2352 That will read the CD in RAW mode... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
