Re: vinum start needs block device
"Jordan K. Hubbard" <[EMAIL PROTECTED]> writes: > > Since the recent block device vanishment, MAKEDEV all and my vinum > > volumes have failed to start. > > Please read /usr/src/UPDATING if you're going to track -current > these days. The reason for this is clearly documented at the > top of that file and won't be a problem in -release since the > correct device nodes will be created initially. Jordan, I don't understand your answer. Using the new MAKEDEV is what causes vinum to fail. Won't -release be using the new MAKEDEV? Greg, is there a mechanism to transition an existing vinum installation to the new device nodes? -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: egcs unstable
Marcel Moolenaar <[EMAIL PROTECTED]> writes: > After (by accident) compiling world (excluding kernel) with optimization > disabled (ie -O0) and installing the resulting binaries, xemacs (21.1.7) > coredumps with a bus error. I recompiled and reinstalled xemacs and all > was fine. Now, after building and installing world (excluding kernel > again) with optimization (ie -O), xemacs does exactly the same: core > dumps on bus error. I'll recompile xemacs again and expect it to be > solved, but something is definitely broken: xemacs should not core dump > after recompiling world with only a simple change in compiler flags. I don't believe that it's the compiler flag change that is causing this. My xemacs has been core dumping after each build and install of world the last couple of times I did it. I have not had time to investigate the real cause yet. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
"Peter S. Housel" <[EMAIL PROTECTED]> writes: > > Ever since the libtermcap / libncurses consolidation, change emacs has > > problems positioning the cursor and properly updating the screen for > > character-only devices like the console. It also affects the display > > in an xterm in non-X mode, i.e., when DISPLAY is *not* set. > > ... > I filed a bug report for this. I fixed it in Emacs with the following > patch. I think it's a FreeBSD bug, though. Good detective work, Peter. So is the bug in FreeBSD or Emacs? The new man page for tgetstr says: Bugs If you call tgetstr to fetch ca or any other parameterized string, be aware that it will be returned in terminfo notation, not the older and not-quite-compatible termcap notation. This won't cause problems if all you do with it is call tgoto or tparm, which both expand terminfo-style. Emacs tries to expand the string itself rather than by calling tparm and we've surprised it by returning the string in terminfo style rather than termcap style. Here's an alternative patch that forces Emacs to use the library versions of tparm and tgoto to do the decoding rather than rolling its own. Put this in /usr/ports/editors/emacs20/patches/patch-ce (although it really should get merged into patch-ca). It works by using the module intended for Emacs running on terminfo machines (ie. it uses terminfo.c rather than tparam.c). I tried this (briefly) on -current and -stable and it seems to work ok. $ cat /usr/ports/editors/emacs20/patches/patch-ce --- src/Makefile.in.origSat Oct 30 15:52:15 1999 +++ src/Makefile.in Sat Oct 30 15:55:28 1999 @@ -546,7 +546,7 @@ #define LIBS_TERMCAP termcapobj = termcap.o tparam.o #else /* LIBS_TERMCAP */ -termcapobj = tparam.o +termcapobj = terminfo.o #endif /* LIBS_TERMCAP */ #endif /* ! defined (TERMINFO) */ -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
"Russell L. Carter" <[EMAIL PROTECTED]> writes: > Yup! And also for 19.34b... I've searched all over for the > source of this problem, glad to know I'm not alone. However, > it only affects one of my three -current boxes, so apparently there is > bit of cruft lying around, but I haven't been able to find > the sucker causing this. (mergemaster'd repeatedly) Are the ones that work linked with an old version of libtermcap.so that was lying around or are they linked with the new libncurses.so.5 ? -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
Nate Williams <[EMAIL PROTECTED]> writes: > > In any case, you should not be doing lots of writes to root, so the > > lack of softupdates should not be a problem. > > So, are you suggesting make /tmp it's own disk, otherwise anytime you do > development alot of writes are done to /. > > And, if you do lots of development, then you'll have the same problem on > /tmp as you did on / unless you waste a huge disk for /tmp. :( You could just symlink /tmp to someplace big and softupdateable. At least then you can share the free space with another big filesystem. The only problem then is that when you boot standalone you either need to be able to mount wherever you've symlinked it into or rm the symlink and mkdir /tmp while you're standalone (and remember to put it back before going multi user). In some ways symlinking is better than having /tmp as a mount point. If it's a real mount point you're likely to create stuff in /tmp while standalone that can't be seen while you're multi user with a file system mounted on top of it. Which leads to "...my / is full and I can't find the files that are using all the space!" -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
Neil Blakey-Milner writes: >On Wed 1999-09-01 (21:03), Kevin Street wrote: >> I think I should set up a separate cvs repository for the FreeBSD src >> since I may not want the same options for my own cvs repository. In >> particular that tagexpand line turns off all tag expansions except for >> $FreeBSD and $Id. > >Does this include $Date? I think the www tree expects them to be >expanded. (I can't check at the moment, though) $Date is off. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
"Matthew D. Fuller" <[EMAIL PROTECTED]> writes: > On Wed, Sep 01, 1999 at 09:20:44PM +0800, a little birdie told me > that Peter Wemm remarked > > > > 23> cat /home/ncvs/CVSROOT/options > > tag=FreeBSD=CVSHeader > > tagexpand=iFreeBSD,Id > > Speaking of the whole subject, where is this (method of defining tags) > documented? I've searched every bit of CVS documentation I can find > anywhere, and none of it mentions this. /usr/src/contrib/cvs/src/main.c and rcs.c Looks like part of this was pulled in from OpenBSD and then enhanced. I couldn't find any documentation either. I think I should set up a separate cvs repository for the FreeBSD src since I may not want the same options for my own cvs repository. In particular that tagexpand line turns off all tag expansions except for $FreeBSD and $Id. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
Peter Wemm writes: >Make sure you are fetching src-all, and if you are not getting src-anything, >then either get src-base or set up $CVSROOT/CVSROOT/options to this: > >23> cat /home/ncvs/CVSROOT/options >tag=FreeBSD=CVSHeader >tagexpand=iFreeBSD,Id > >Fetching src-base will do this for you, as well as getting the modules files >and the commit logs. Yes, that was my problem. I was fetching src-all but into a subdir. I have my own CVSROOT for the rest of my cvs repository and needed to pick up the options file from FreeBSD's CVSROOT. In William's case he does not need to do anything. He's CVSuping in checkout mode and things are already working correctly. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
"William R. Somsky" <[EMAIL PROTECTED]> writes: > Hmm... but what about if you're cvsup-ing the sources? > I'm cvsup-ing stable, not current, (cvsup file included below) > and $FreeBSD appears all over the place unexpanded. Is this > the way it's supposed to be? Isn't cvsup supposed to be > (effectively) doing a "check-out"? Or am I just confused? > #] grep src/bin/echo bin/echo/echo.[1c] > bin/echo/echo.1:.\" $FreeBSD: src/bin/echo/echo.1,v 1.6.2.2 1999/08/29 14:12:19 >peter Exp $ > bin/echo/echo.c: "$FreeBSD: src/bin/echo/echo.c,v 1.7.2.1 1999/08/29 14:12:20 peter >Exp $"; > So... no expansion of $FreeBSD that I can see here... Those are the expanded tags. When I said I had unexpanded tags, I meant that I was seeing just: "$FreeBSD$" instead of: "$FreeBSD: $" -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xl driver problems on 3c905B-TX
Kevin Street <[EMAIL PROTECTED]> writes: > I'm getting a panic during an ifconfig on boot after building a kernel > with the new xl driver. The patch that Luoqi just posted works for me. I see Bill has just committed a different fix as well. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
xl driver problems on 3c905B-TX
I'm getting a panic during an ifconfig on boot after building a kernel with the new xl driver. This happens early in the boot so I don't have a dump, but can probably arrange to get one if the dmesg output isn't telling us something useful. System is current as of about 7pm EDT 08/31. The last working kernel I have is from 08/28. The relevant dmesg and trap are: xl0: <3Com 3c905B-TX Fast Etherlink XL> irq 10 at device 10.0 on pci0 xl0: Ethernet address: 00:10:5a:c9:a4:5b miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xlphy1: <3Com internal media interface> on miibus0 xlphy1: ignoring this PHY, non-zero instance device_probe_and_attach: xlphy1 attach returned 6 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xc94f2dcc frame pointer = 0x10:0xc94f2de4 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 = 67 (ifconfig) interrupt mask = net trap number = 12 panic: page fault -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! ATA driver (atapi DMA)..
Soren Schmidt writes: >Depends.. There are many factors involved here, using DMA only lowers >the CPU usage, and will enable faster transfers if the problem was >that the CPU was saturated with the PIO transfer. It gave about >double the transfer rate on my old P6 based maschine, because the >CPU drain was the limitting factor. Most modern CDROM are variable >speed, and you will see varying rates depending on the quality of >the media. dd'ing the whole cd and watching with iostat shows speeds from 2M increasing to 5.5M on the outside tracks with cpu staying at 98% to 100% idle on a PII 400. So DMA seems to be doing its stuff. I did try checking for correct data coming off the cd as well, and saw no problems. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! ATA driver (atapi DMA)..
Matthew Dillon <[EMAIL PROTECTED]> writes: > :Two things I've noticed: > :1) my cdrom delivers about 2M/s which is the same as before DMA. Is > :the improvement only in cpu usage or should I be seeing a speed > :improvement too? > : > :speed tested with: > :dd if=/dev/racd0c of=/dev/null bs=64k count=320 > :(I get it to spin up with another dd before this test) > > Well 2MB/sec == 14x CDRom drive. Is it a 14x CDRom drive? CDRom > drives are typically limited to how quickly they can get data off > the platter. A faster bus transfer will not improve that. I should have mentioned that ... it's a 32x cdrom. dmesg says it claims to be able to do 5515 KB/sec. I've played around with using dd ... skip=n to reposition which part of the cd I'm reading and I've seen some much better speeds on the outer tracks (I think I now recall that cd's start numbering from the inside tracks, don't they?). So you're probably right that it's just the rotational speed that I was seeing. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! ATA driver (atapi DMA)..
Two things I've noticed: 1) my cdrom delivers about 2M/s which is the same as before DMA. Is the improvement only in cpu usage or should I be seeing a speed improvement too? speed tested with: dd if=/dev/racd0c of=/dev/null bs=64k count=320 (I get it to spin up with another dd before this test) 2) I can crash my system (sometimes a panic, sometimes a freeze) with: dd if=/dev/racd0c of=/dev/null bs=1m count=1 I could do bs=1m before the DMA code went in. If the system freezes I see: atapi_error: READ_BIG - timeout error = 00 the dd puts out a message about transferring 0 records ata1: master: timeout waiting to give command s = d8 e = 00 I got one panic which was (transcribed by hand, I had dump off): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01f4266 stack pointer = 0x10:0xc9825d7c frame pointer = 0x10:0xc9825d94 code segment= base 0x0, limit 0xf, type 0x1b processor cflags= interrupt enabled, resume, IOPL = 0 current process = 43899 (dd) interrupt mask = bio trap number = 12 panic: page fault I turned dump on and tried again but got a system freeze (reset to reboot) instead with no panic and no dump. The relevant dmesg stuff: ata-pci0: at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 ... ata0: master: setting up UDMA2 mode on PIIX4 chip OK ad0: ATA-4 disk at ata0 as master ad0: 9787MB (20044080 sectors), 19885 cyls, 16 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=2 ad0: 16 secs/int, 0 depth queue, DMA mode ata0: slave: setting up UDMA2 mode on PIIX4 chip OK ad1: ATA-3 disk at ata0 as slave ad1: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S ad1: piomode=4, dmamode=2, udmamode=2 ad1: 16 secs/int, 0 depth queue, DMA mode ata1: master: setting up UDMA2 mode on PIIX4 chip OK ad2: ATA-4 disk at ata1 as master ad2: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad2: piomode=4, dmamode=2, udmamode=2 ad2: 16 secs/int, 0 depth queue, DMA mode atapi: piomode=4, dmamode=2, udmamode=-1 ata1: slave: setting up WDMA2 mode on PIIX3/4 chip OK atapi: DMA transfer mode set acd0: CDROM drive at ata1 as slave acd0: drive speed 5515KB/sec, 256KB cache, DMA acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
John Polstra <[EMAIL PROTECTED]> writes: > Kevin Street wrote: > Expansion of RCS keywords occurs on check_out_, not on checkin. In > other words, your cvs is responsible for expanding them. > > > If my cvs needs to do it, then I presume > > I need to add some options to my CVSROOT to make that happen. If so, > > is there a description somewhere of what I need to steal out of > > FreeBSD's CVSROOT that will make it happen? > > Grab the "options" file from there. There were actually two things I needed to do. Copy the `options' file from FreeBSD's CVSROOT and add a line saying "options" to the `checkoutlist' file so the options file is kept checked out in CVSROOT. I needed to "cvs co" the src tree again since "cvs update" thought everything was already up to date. Thanks John & Rod. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
Rodney W. Grimes writes: >What verion of the cvs binary are you running (cvs -v)? Concurrent Versions System (CVS) 1.10 `Halibut' (client/server) >Are you getting a copy of CVSROOT? yes...as part of src-all, but it's not used as *my* CVSROOT. Let's go back to the beginning here. Is my cvs responsible for expanding the $FreeBSD$ tags, or are they supposed to arrive in my cvs repository already expanded? If my cvs needs to do it, then I presume I need to add some options to my CVSROOT to make that happen. If so, is there a description somewhere of what I need to steal out of FreeBSD's CVSROOT that will make it happen? -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: $FreeBSD tag confusion
John Polstra <[EMAIL PROTECTED]> writes: > The tags are expanding just fine up here in Seattle. :-) > > I wish you would have included the rest of the output from your cvs > status command. It sounds a lot like your source tree was checked > out with "-ko". That would show up in the "Sticky Tag" line of your > cvs status output. === File: umap.hStatus: Up-to-date Working revision:1.11Sun Aug 29 09:54:16 1999 Repository revision: 1.11 /usr/home/cvs/cvsroot/freebsd/src/sys/miscfs/umapfs/umap.h,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) > Do another cvs update, but this time add the "-A" flag: > > cvs update -A umap.h I did check for sticky things before I posted, but just to be safe, I've tried the line above and also tried a full "cvs co" of the entire src tree. Neither helped. I took a look at what I've got in my cvs repository and it's wrong in there, so cvsup isn't getting the right stuff from the server in the first place, or it isn't updating my local cvs repository correctly. CVSup client, GUI version Software version: REL_16_0 Protocol version: 16.0 My first cvsup after the tags went in was from cvsup.ca.FreeBSD.ORG. I've done a few from cvsup.FreeBSD.org to see if it would sort itself out. I think I'll try to get a new copy of part of the tree from scratch and see if it's any different. -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
$FreeBSD tag confusion
I'm confused by what I'm seeing in my source tree after the Id->FreeBSD tag change. I cvsup the repository and then update my source tree locally. Most of the files in the tree now have an unexpanded $FreeBSD$ tag in them (ie. no version info). Files which have been changed since the new tag went in get an expanded $FreeBSD: tag, but the version in the tag is not the same version as the checked out file should be. The contents of the file seem to really be the latest version though, other than the tag. For example in /usr/src/sys/miscfs/umapfs "cvs status umap.h" gives: === File: umap.hStatus: Up-to-date Working revision:1.11Sun Aug 29 19:31:44 1999 Repository revision: 1.11... but in the file I see: * $FreeBSD: src/sys/miscfs/umapfs/umap.h,v 1.10 1999/08/28 00:47:00 peter Exp $ so the $FreeBSD tag in the file is one version behind the version of the currently checked out file. Deleting and doing "cvs up umap.h" leaves me in the same state. Any explanations as to what's going on? -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA - Trouble mounting secondary master
Kevin Street <[EMAIL PROTECTED]> writes: > Soren Schmidt <[EMAIL PROTECTED]> writes: > > 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... > > I tried with the ad dev entries for my problem as well with no > improvement. I've also tried using: > dd if=/dev/ad0s6 of=/dev/null bs=512 count=1 > as the first access to one of the failing drives (ad0). > The first dd fails with device not configured, but any subsequent > access works fine. It seems it's left in an odd state by the driver > start up, but all it takes is a read to get it sorted out again. More on this. I just booted with -v and now when I do the first dd I see: ad0: invalid primary partition table: no magic and the same on ad2 when the swapon fails. So how do I get the magic back into my relationship with my drives? -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA - Trouble mounting secondary master
Soren Schmidt <[EMAIL PROTECTED]> writes: > 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. > > 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... I tried with the ad dev entries for my problem as well with no improvement. I've also tried using: dd if=/dev/ad0s6 of=/dev/null bs=512 count=1 as the first access to one of the failing drives (ad0). The first dd fails with device not configured, but any subsequent access works fine. It seems it's left in an odd state by the driver start up, but all it takes is a read to get it sorted out again. Any thoughts on how we can help debug this? -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA - Trouble mounting secondary master
Brian McGroarty <[EMAIL PROTECTED]> 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. Nice timing, I was about to send a message with a description of a similar (the same?) problem. The first access to any IDE disk (except the one I'm booting from - wd1) fails with 'device not configured'. This affects swapon for wd2s2b during the boot as well as the first mount for wd0 which happens to have only dos partitions on it. So the problem is not restricted to ufs partitions or to the secondary controller. Repeating the swapon or mount command works normally. I've been seeing this problem for about a month, but I've been away on vacation so am just beginning to look into it. I made changes to all my drives and put them in LBA mode at about the same time as I began seeing this, but I'm not sure if that is related. ata-pci0: at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 ata0: master: setting up UDMA2 mode on PIIX4 chip OK ad0: ATA-4 disk at ata0 as master ad0: 9787MB (20044080 sectors), 19885 cyls, 16 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=2 ad0: 16 secs/int, 0 depth queue, DMA mode ata0: slave: setting up UDMA2 mode on PIIX4 chip OK ad1: ATA-3 disk at ata0 as slave ad1: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S ad1: piomode=4, dmamode=2, udmamode=2 ad1: 16 secs/int, 0 depth queue, DMA mode ata1: master: setting up UDMA2 mode on PIIX4 chip OK ad2: ATA-4 disk at ata1 as master ad2: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad2: piomode=4, dmamode=2, udmamode=2 ad2: 16 secs/int, 0 depth queue, DMA mode acd0: CDROM drive at ata1 as slave acd0: drive speed 5515KB/sec, 256KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATA/ATAPI speed test
I tried the ata drivers on the weekend and they work fine, but seem a bit slow. I ran my usual buildworld script with the old and new drivers with these elapsed time results: With the wd drivers 2:05:32 With the ata drivers2:54:21 So that's nearly 40% longer for the ata case - is this all likely due to dma? /usr/obj is on drive 0, /usr/src is on drive 1 and they are mounted with soft-updates and noatime. The tests were not entirely pure as there was some other minor activity running on the machine as well. The ata dmesg output is: ata-pci0: rev 0x01 on pci0.4.1 ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 ... ad0: ATA-3 disk at ata0 as master ad0: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue ad1: ATA-4 disk at ata1 as master ad1: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 0 depth queue Waiting 2 seconds for SCSI devices to settle acd0: CDROM drive at ata0 as slave acd0: drive speed 5515KB/sec, 256KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked -- Kevin Street str...@iname.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
