Re: Just a quick thank you...
KJK The next step for Windows would to be able to deal with new hardware KJK without doing an installation from scratch. The next step for FreeBSD KJK would to be able to replace the motherboard without shutting down the KJK machine. :-) Yeah... a hot-pluggable (swappable) motherboard! Kewl. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM Gate.
BTW, QNX had this for a long time, it's called QNet in there. Allows transparently to mount or use anything in /dev. Even a soundcard! PJD Hello hackers... PJD I've done something what will be called GEOM Gate. PJD This software provide disk devices mounting through the network. PJD http://garage.freebsd.pl/geom_gate.tbz ___ [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
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! Z ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Ultra ATA card doesn't seem to provide Ultra speeds.
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... Z ___ [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.
Hello again. Sorry I just forgot to provide at least a version number. Stupid me. It's FreeBSD 5.1 RELEASE and here's a dmesg output. Also, it's not that it 'doesn't work', it works, but I see no difference in speed after changing transfer modes (from WDMA2 to UDMA6) Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #10: Wed Jul 30 12:18:51 MSD 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KIT Preloaded elf kernel /boot/kernel/kernel at 0xc0465000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium Pro (200.46-MHz 686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping = 9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 201326592 (192 MB) avail memory = 190713856 (181 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 12 IOAPIC #0 intpin 17 - irq 11 IOAPIC #0 intpin 18 - irq 10 IOAPIC #0 intpin 19 - irq 15 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fdd00 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371SB (PIIX3) USB controller port 0x9000-0x901f irq 15 at device 7.2 on pci0 usb0: Intel 82371SB (PIIX3) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ukbd0: vendor 0x099a USB Multimedia Keyboard, rev 1.10/1.01, addr 2, iclass 3/1 ums0: Kensington Kensington USB/PS2 Orbit, rev 1.10/4.00, addr 3, iclass 3/1 ums0: 2 buttons drm0: 3dfx Voodoo3 3000 port 0x9400-0x94ff mem 0xe200-0xe3ff,0xe000-0xe1ff irq 11 at device 9.0 on pci0 info: [drm] Initialized tdfx 1.0.0 20010216 on minor 0 pcm0: Creative CT5880-C port 0x9800-0x983f irq 10 at device 10.0 on pci0 pcm0: SigmaTel STAC9721/23 AC97 Codec ed0: NE2000 PCI Ethernet (RealTek 8029) port 0x9c00-0x9c1f irq 15 at device 11.0 on pci0 ed0: address 00:e0:4c:dd:23:1c, type NE2000 (16 bit) atapci1: SiI 0680 UDMA133 controller port 0xb000-0xb00f,0xac00-0xac03,0xa800-0xa807,0xa400-0xa403,0xa000-0xa007 mem 0xe400-0xe4ff irq 12 at device 12.0 on pci0 ata2: at 0xa000 on atapci1 ata3: at 0xa800 on atapci1 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) Timecounters tick every 10.000 msec ad0: 9729MB ST310215A [19767/16/63] at ata0-master WDMA2 ad1: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata2-master UDMA133 acd0: CD-RW PLEXTOR CD-R PX-W4824A at ata3-master PIO4 SMP: AP CPU #1 Launched! cd0 at ata3 bus 0 target 0 lun 0 cd0: PLEXTOR CD-R PX-W4824A 1.04 Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Mounting root from ufs:/dev/ad0s2a 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. Z SS Possibly, but you need to give us info so we can try to diagnose the SS problem it doesn't work it not enough, so please provide at least: SS FreeBSD version (output of uname -a) SS Boot log (output of dmesg) SS -Søren -- Best regards, Buckiemailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Soeren, Heh, QNX in first RTP incarnations only had /dev/zero and I sort of get used to it. But nevermind. I've already tried large bsizes (1m and more) and /dev/null too. But I can't really get past the 16Mb/s barrier... Does machine speed really should affect the hard drive performance so much? I don't think that top showed me the processor usage on dd more than 30%, then again it might be something else... I also had a thought about measuring raw io performance, but the only way I know is dd to zero (null). I'm saying this because in... ugh... Windows I get raw io speeds of up to 60(!) Mb per second (HDTach). And that's fine but Windows doesn't want to mount any volumes off this drive if the speed is set to something more than WDMA2 (even UDMA0). It can only access it sector-by-sector, but without any problems though. Overall, the SI0680 card is a mystery! And SiliconImage is silent as well. Any other ideas as to how to measure the performance or ways to speed it up somehow or test it? Z SS OH, you need to output to /dev/null NOT /dev/zero :) SS besides that, all looks OK, but you need a fairly large bs to se improvments SS on this (relatively slow) machine, try a bs of 1m and see if that SS helps, if not there is something slowing down your system.. SS -Søren SS ___ SS [EMAIL PROTECTED] mailing list SS http://lists.freebsd.org/mailman/listinfo/freebsd-hackers SS To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best regards, Buckiemailto:[EMAIL PROTECTED] ___ [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.
Wow. But still, can it be that something bottlenecks somewhere so that I can't get these loverly speeds? Can I measure pci performance as well? Would be cool to understand what doesn't allow this system to use the 133 to its max... Z 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 KC OK you win :-P I just don't know where to look I guess. KC Ken KC ___ KC [EMAIL PROTECTED] mailing list KC http://lists.freebsd.org/mailman/listinfo/freebsd-hackers KC To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Issues with large drives going back to PIO
Woo. I have just the same thing with a 10Gb Seagate Barracuda ATA III drive here. It appears to occur only when Seagate is attached to the wonderful SI0680 controller (falls back to PIO during boot time and after resetting through atacontrol). There's definitely a 'thing' about these controllers. It never does happen on WDMA modes though, on internal Intel controller. But I have an idea - this Seagate drive has some bad sectors in there, so I had Windows sometimes falling back to PIO for this drive because of these physical errors. Strange anyway. And we seem to have one thing in common: dual PentiumPro systems... Z PK Hello. PK A few months ago (May) to be exact, Søren posted a patch ( PK http://lists.freebsd.org/pipermail/freebsd-current/2003-May/003275.html PK ) to the FreeBSD-current mailing list relating to IDE drives over a certian PK size having issues with falling back to PIO mode and other things. This PK patch was commited, and is currently in 5.1-RELEASE, and my friend told me PK to try applying to the patch to fix the problem (although the patch was PK already commited). There does NOT appear to be anything wrong with the PK drives, as I have run tests on them and stuck them in another FreeBSD PK 5.1-RELEASE box, and the problem seems to disappear. PK The error I'm getting is..: PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn 198898911 PK of 198898911-198899166 retrying PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn 198902239 PK of 198902239-198902494 retrying PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn 198902239 PK of 198902239-198902494 retrying PK Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn 203789023 PK of 203789023-203789038 retrying PK Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn 203789023 PK of 203789023-203789038 falling back to PIO mode PK and PK ad3: UDMA ICRC error cmd=write fsbn 198898911 of 198898911-198899166 PK retrying PK ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 PK retrying PK ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 falling PK back to PIO mode PK The drives are 120GB Maxtor 7200RPM with 2MB cache, I have 3 of them; and I PK have experienced the same error with FreeBSD 5.1-RELEASE, and 4.8-RELEASE PK (4.8, which always made the drives go back to PIO mode no matter what). The PK board is a Asus P4SDX: PK ad0: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata0-master UDMA133 PK ad1: 78167MB Maxtor 4R080J0 [158816/16/63] at ata0-slave UDMA133 PK ad2: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-master UDMA133 PK ad3: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-slave UDMA133 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Issues with large drives going back to PIO
Haha, laugh! I bought it 2 years ago, this was the dream of my childhood, in 1996 I was literally drooling over anything PentiumPro and dual seemed like an impossible dream. Was VERY hard to find, the motherboard especially. Bought from some guy who kept them in a garage. Cost $30 + $10(!) for a PPro radiator. It would still be more than satisfactory if only it wasn't the need to write large amount of CDs at 48x speed and that's why I'd need UDMA controller. The rest is recorded history. But Gigabyte sucks anyway. I've yet to see a BIOS THIS buggy (as in my current PPro motherboard). Z PS. Do you want to buy one? It's packed in a lovely Thermaltake Xaser II case by the way, lighting included! Friday, August 1, 2003, 2:35:19 AM, you wrote: PK Where are you getting Dual PentiumPro system from?? PK --Peter PK - Original Message - PK From: Buckie [EMAIL PROTECTED] PK To: [EMAIL PROTECTED] PK Sent: Thursday, July 31, 2003 3:14 PM PK Subject: Re: Issues with large drives going back to PIO PK Woo. I have just the same thing with a 10Gb Seagate Barracuda ATA III PK drive here. It appears to occur only when Seagate is attached to the PK wonderful SI0680 controller (falls back to PIO during boot time and PK after resetting through atacontrol). There's definitely a 'thing' PK about these controllers. It never does happen on WDMA modes though, on PK internal Intel controller. PK But I have an idea - this Seagate drive has some bad sectors in there, PK so I had Windows sometimes falling back to PIO for this drive because PK of these physical errors. Strange anyway. PK And we seem to have one thing in common: dual PentiumPro systems... PK Z PK Hello. PK A few months ago (May) to be exact, Søren posted a patch ( PK http://lists.freebsd.org/pipermail/freebsd-current/2003-May/003275.html PK ) to the FreeBSD-current mailing list relating to IDE drives over a PK certian PK size having issues with falling back to PIO mode and other things. This PK patch was commited, and is currently in 5.1-RELEASE, and my friend told PK me PK to try applying to the patch to fix the problem (although the patch was PK already commited). There does NOT appear to be anything wrong with the PK drives, as I have run tests on them and stuck them in another FreeBSD PK 5.1-RELEASE box, and the problem seems to disappear. PK The error I'm getting is..: PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn PK 198898911 PK of 198898911-198899166 retrying PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn PK 198902239 PK of 198902239-198902494 retrying PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn PK 198902239 PK of 198902239-198902494 retrying PK Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn PK 203789023 PK of 203789023-203789038 retrying PK Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn PK 203789023 PK of 203789023-203789038 falling back to PIO mode PK and PK ad3: UDMA ICRC error cmd=write fsbn 198898911 of 198898911-198899166 PK retrying PK ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 PK retrying PK ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK falling PK back to PIO mode PK The drives are 120GB Maxtor 7200RPM with 2MB cache, I have 3 of them; PK and I PK have experienced the same error with FreeBSD 5.1-RELEASE, and PK 4.8-RELEASE PK (4.8, which always made the drives go back to PIO mode no matter what). PK The PK board is a Asus P4SDX: PK ad0: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata0-master UDMA133 PK ad1: 78167MB Maxtor 4R080J0 [158816/16/63] at ata0-slave UDMA133 PK ad2: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-master UDMA133 PK ad3: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-slave UDMA133 PK ___ PK [EMAIL PROTECTED] mailing list PK http://lists.freebsd.org/mailman/listinfo/freebsd-hackers PK To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best regards, Buckiemailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
