Mikhail T. wrote:
That said, I point out, that for me, dump is not failing (although it
did hang this morning). It is the restore, which fails to read dump's
output:
unknown tape header type 213474529
abort? [yn] n
resync restore, skipped 502 blocks
expected next file 54, got 0
Mark Kirkwood wrote:
...specifying /boot/loader.old got me booted ok (not sure why this
*didn't* work with the Asus, maybe I need to try it again with the Feb
sources).
I tried the latest RELENG_7 sources, same result - does *not* boot even
specifying the old loader. I spent a bit
Mark Kirkwood wrote:
I wrote:
I am getting this too - update from RELENG_7 @12 Jan src to 20 Jan
and I have:
panic: free: guard1 fail @ 0x511d
from /usr/src/sys/boot/i386/loader/../../common/module.c:959
Can't work out which disk we are booting from.
Guessed BIOS device 0x
Reuben wrote:
I was wondering if anyone else was seeing loader (v1.02) break after updating
from 7.1-RELEASE to 7.1-STABLE. After performing the prescribed updating
procedure (via the handbook), the system will go through the normal steps and
after the boot menu will present the following
I wrote:
I am getting this too - update from RELENG_7 @12 Jan src to 20 Jan and
I have:
panic: free: guard1 fail @ 0x511d
from /usr/src/sys/boot/i386/loader/../../common/module.c:959
Can't work out which disk we are booting from.
Guessed BIOS device 0x not found by probes,
I am running RELENG_7 from 12 Jan, I noticed that I am only getting
sound on 1 channel. Also opening up Volume Control from Gnome and
altering either of Volume or PCM produces crackles on the non
functioning channel, and kills susbsequent sound output on either channel!
(Just to be sure I
Mark Kirkwood wrote:
I am running RELENG_7 from 12 Jan, I noticed that I am only getting
sound on 1 channel. Also opening up Volume Control from Gnome and
altering either of Volume or PCM produces crackles on the non
functioning channel, and kills susbsequent sound output on either
channel
I trying to update /usr/src via cvs from anoncvs1.FreeBSD.org and getting:
$ cd /usr/src
$ cat CVS/Root
:ext:[EMAIL PROTECTED]:/home/ncvs
$ cvs update -d -P
cannot close CVS/Entries
No space left on device
___
freebsd-stable@freebsd.org mailing list
Ah - too quick with the send button - sorry about the poor English.
I wrote:
I trying to update /usr/src ...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL
Mark Kirkwood wrote:
I wrote:
Mar 27 13:32:30 zmori kernel: da0: CREATIVE NOMAD_MUVO 0001
Removable Direct Access SCSI-4 device
Mar 27 13:32:30 zmori kernel: da0: 1.000MB/s transfers
Mar 27 13:32:30 zmori kernel: da0: 125MB (256001 512 byte sectors:
64H 32S/T 125C)
Mar 27 13:32:39 zmori
Doug Barton wrote:
Robert Blayzor wrote:
On May 28, 2008, at 6:55 PM, Doug Barton wrote:
That's a known problem with FreeBSD 4, which is now well past EOL. I
would suggest moving to FreeBSD 7 ASAP.
Is it? I searched and searched and never found any hits or PR's
regarding this.
Not
John Baldwin wrote:
Try this patch. I'm not 100% certain this will fix it as I can't reproduce
the issue, but I think it might help. Specifically, when the boot code makes
a v86 call, the loader/boot2/whatever swaps in/out a new set of registers via
the v86 structure including the eflags
I wrote:
John Baldwin wrote:
Try this patch. I'm not 100% certain this will fix it as I can't
reproduce
the issue, but I think it might help. Specifically, when the boot
code makes
a v86 call, the loader/boot2/whatever swaps in/out a new set of
registers via
the v86 structure including
Peter Holm wrote:
On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote:
I wrote:
John Baldwin wrote:
Try this patch. I'm not 100% certain this will fix it as I can't
reproduce
the issue, but I think it might help. Specifically, when the boot
code makes
a v86 call
Peter Holm wrote:
On Sun, May 25, 2008 at 08:33:01PM +1200, Mark Kirkwood wrote:
I wrote:
John Baldwin wrote:
Try this patch. I'm not 100% certain this will fix it as I can't
reproduce
the issue, but I think it might help. Specifically, when the boot
code makes
a v86 call
James Seward wrote:
Hello,
Two days ago I csup'd my desktop at home, which was running RELENG_7
from about 7.0-RELEASE time, to bring it up-to-date (still on
RELENG_7). I followed my usual buildkernel/world procedure (the usual
one) which has worked fine all the way since 5.x. After installing
Jeremy Chadwick wrote:
I am too, but PRs that are 2 years old which include patches for severe
bugs that affect reliability of RAID is (in my opinion) not acceptable.
I've been spanked over saying this before (you don't understand how
open source works), but necessity easily supercedes
I wrote:
Mar 27 13:32:30 zmori kernel: da0: CREATIVE NOMAD_MUVO 0001
Removable Direct Access SCSI-4 device
Mar 27 13:32:30 zmori kernel: da0: 1.000MB/s transfers
Mar 27 13:32:30 zmori kernel: da0: 125MB (256001 512 byte sectors:
64H 32S/T 125C)
Mar 27 13:32:39 zmori kernel: umass0: BBB
FWIW - I have just completely *recompiled* my userland after the 6-7
upgrade - i.e:
# portupgrade --batch -fa
on a PIII 1.26Ghz system in just under 2 days (i.e over the weekend) for
836 packages - desktop system with Gnome etc. So it's not actually too
bad. Using the packages option on
Mark Kirkwood wrote:
Hi,
I'm seeing a hang when I insert one of these guys into my 7 stable box
(kernel from 28 Feb), after removing it all seems well:
Mar 27 13:32:29 zmori root: Unknown USB device: vendor 0x041e product
0x4106 bus uhub1
Mar 27 13:32:29 zmori kernel: umass0: Creative Tech
Hi,
I'm seeing a hang when I insert one of these guys into my 7 stable box
(kernel from 28 Feb), after removing it all seems well:
Mar 27 13:32:29 zmori root: Unknown USB device: vendor 0x041e product
0x4106 bus uhub1
Mar 27 13:32:29 zmori kernel: umass0: Creative Tech NOMAD MuVo, class
David E. Thiel wrote:
On Thu, Feb 28, 2008 at 08:30:17PM +0200, Teemu Korhonen wrote:
Did anyone find a solution to the jerky mouse -problem? It still exists
in 7.0-RELEASE.
I experienced some relief from this by switching my single-CPU system
to use hyperthreading, and using an SMP
Ken Smith wrote:
Just in case some interested parties are not subscribed to the
freebsd-announce mailing list... FreeBSD 7.0-RELEASE has been formally
released. If you would like to see the release announcement it's here:
http://www.freebsd.org/releases/7.0R/announce.html
On behalf of the
Stefan Huerter wrote:
Hello
Just testing the new FB 7beta3 - installed from the ISO-images.
System is running on an SCSI 9GB disk, the machine has 750MHz with
512MB Ram and the zfs is using 8 ATA Disks, 4x120GB and 4x160GB
connected to Promise Fasttrak TX2 (with no configs).
Creating the ZFS
Roland Smith wrote:
Remember to remove old files and libraries with `make delete-old' and
`make delete-old-libs' as explained in /usr/src/Makefile.
It is advisable to remove and install your ports from scratch when
upgrading to a new major version, because the automatic port updating
tools
Peter Losher wrote:
One of the other objections I have with this change (other than the fact
that it was made w/o consultation) is the fact that this is would become
the default setting. Yes, busy mail servers may be better served by
slaving frequently used zones, and as Vixie mentioned on the
Kris Kennaway wrote:
Grr, OK. Well, you might have got it wrong, so we still need to see a
portupgrade log from someone who followed the directions.
Kris,
FWIW - I followed the instructions in UPDATING - unfortunately I did 'em
pretty much as I read 'em... so I noticed the CAVEAT *after*
Abdullah Ibn Hamad Al-Marri wrote:
Since AMD/ATI doesn't make a native driver for FreeBSD, I only buy
notebooks with nvidia, and I told my friends about this.
We as FreeBSD users could write about this in our blogs and pages,
which will widespread the word about the driver issues in better way,
Artem Kuchin wrote:
Mark Kirkwood wrote:
I have seen this with a Tyan PIII board + TX2000. In my case re-trying
the boot from cd several times would *eventually* get a working
installer session. (If you search the archives you'll see several
cases of folks encountering this). Unfortunately I
Artem Kuchin wrote:
Hello!
I am having a VERY weird problem.
The pc config is:
1) Celeron 1+ GHZ
2) Intel PCI ethernet nic
3) Fasttrak TX2000 raid + 2 mirrored disks (seagate 80gb)
4) teac dvd driver
5) 512 MB ram
6) Chaintech montherboard (old one)
also tried on gigabyte motherboard
I
JoaoBR wrote:
I am not convinced that this kind of test is of any value for comparing
systems at all because there are too much factors involved - unless the
competitors are installed on identical hardware. On the other side I think it
is usefull to compare tweaked settings on a particular
Pieter de Goeje wrote:
On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote:
In fact if you note that the PIII HW *can* actually do 700MB/s, it
suggests that your HW is capable of considerably more than 900MB/s -
given that opteron's have excellent cpu to memory bandwidth, and the
speed
A few more tests with a slightly improved version of the program
(attached): We (i.e FreeBSD) do noticeably better with bigger block sizes.
Cheers
Mark
Gentoo - 2.6.18-gentoo-r3:
---
$ ./readtest /data0/dump/file 8192 0
random reads: 10 of: 8192 bytes elapsed: 1.2698s
Mark Kirkwood wrote:
Pieter de Goeje wrote:
It would be more interesting to see how random access to a (cached)
file performs in Linux vs FreeBSD, which seems a more logical pattern
for a database.
Agreed, and good point, I'll knock up a simple program to do random
and/or sequential
Pieter de Goeje wrote:
On Wednesday 20 December 2006 11:38, Mark Kirkwood wrote:
In fact if you note that the PIII HW *can* actually do 700MB/s, it
suggests that your HW is capable of considerably more than 900MB/s -
given that opteron's have excellent cpu to memory bandwidth, and the
speed
Oliver Fromme wrote:
Mark Kirkwood wrote:
Exactly, that's why I did the comparison - I think you missed the part
where I mentioned the 2 systems were *identical* with respect to cpus,
memory, mobo - in fact even the power supplies are identical too!
So I assume your benchmark measured
Bill Moran wrote:
In response to Mark Kirkwood [EMAIL PROTECTED]:
JoaoBR wrote:
I am not convinced that this kind of test is of any value for comparing
systems at all because there are too much factors involved - unless the
competitors are installed on identical hardware. On the other side I
JoaoBR wrote:
On Tuesday 19 December 2006 22:05, Mark Kirkwood wrote:
$ dd of=/dev/null if=/tmp/file bs=32k # read it
81920 bytes transferred in 1.801944 secs (454620117 bytes/sec)
hum, look my releng_6:
# dd of=/dev/null if=/c/c1/file bs=32k
81920 bytes
JoaoBR wrote:
On Wednesday 20 December 2006 07:37, Mark Kirkwood wrote:
JoaoBR wrote:
On Tuesday 19 December 2006 22:05, Mark Kirkwood wrote:
$ dd of=/dev/null if=/tmp/file bs=32k # read it
81920 bytes transferred in 1.801944 secs (454620117 bytes/sec)
hum, look my
In the process of investigating performance in another area I happened
to be measuring sequential cached reads (in a fairly basic manner):
$ dd if=/dev/zero of=/tmp/file bs=8k count=10 # create file
81920 bytes transferred in 4.849394 secs (168928321 bytes/sec)
$ dd of=/dev/null
What does the memory-related stats from top show you? Did you have any
other memory intensive applications running at the time? A random
example from one of my systems (1GB RAM):
Thanks, good point - but no - absolutely nothing (machine is freshly
booted, and the only thing running is
Mark Kirkwood wrote:
Charles Sprickman wrote:
I also did a little more digging and noticed that once I start pinging
from one of these hosts using large packet sizes, I get about 50-60%
packet loss (ie: ping -s 1500 other.vr0.host). If I ping something
with a decent card, I get about 30-50
Mark Kirkwood wrote:
I plugged in the card today, and seem to get pretty reasonable
performance (8-10MB/s for scp - see attached).
sorry, forgot to add... this is on:
6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Tue Nov 28 23:55:20 NZDT 2006
with a kernel that differs a small amount from
Charles Sprickman wrote:
I also did a little more digging and noticed that once I start pinging
from one of these hosts using large packet sizes, I get about 50-60%
packet loss (ie: ping -s 1500 other.vr0.host). If I ping something with
a decent card, I get about 30-50% packet loss. There's
Pete French wrote:
You might be able to speed up the read by playing with the vfs.read_max
sysctl (try 16 or 32).
Wow! That makes a huge difference, thanks. Should this not be in 'man tuning' ?
Yeah, I believe I've seen it mentioned *somewhere* with respect to
working with RAID (of course,
Pete French wrote:
I recently overhauled my RAID array - I now have 4 drives arranged
as RAID 0+1, all being 15K 147gig Fujitsu's, and split across two
buses, which are actively terminated to give U160 speeds (and I have
verified this). The card is a 5304 (128M cache) in a PCI-X slot.
This
Mark Linimon wrote:
On Sun, Oct 15, 2006 at 02:01:08PM -0400, Michael Butler wrote:
For everyone's benefit then, please feel free to submit your patches
along with your technical analysis.
I think his best bet is a fork, instead. Then he can tell all the people
that volunteer to work on
Sergey N. Voronkov wrote:
Hello, Stable!
Do anyone have running RELENG_6 branch on old Intel SMP boards? I have two
of them: SCB2 and SDS2. Both are on RELENG_4_11 today. Thinking on proposed
EoL of RELENG_4 branch I'v tryed to move one of them (SCB2) onto 6.1-RELEASE.
That was very problematic
Oops - didn't know about the -acpi mailing list, will post there, sorry.
Mark
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
I've just upgraded 2 machines to 6.2-PRERELEASE #1: Sat Sep 16 18:31:43
NZST 2006:
- Supermicro P3TDER (Serverworks HE-SL Chipset, AMIBOIS)
- Supermicro P3TDDE (VIA Apolla 266 chipset, AWARD)
They both exhibit the same problem:
If ACPI is enabled, shutting down via 'shutdown -h' appears to
Karl Denninger wrote:
No, I would like -STABLE to be treated as what it is claimed to be - BETA
code, not ALPHA code.
There's a huge difference between the two, and MFCing something back to
-STABLE without testing the BASIC functionality of the module you're working
with first does not fit
Mark Kirkwood wrote:
Obviously if your array
is RAID10, the 180MB/s is very good!
Also unlikely - RAID10 with 5 disks?? - brain fade - sorry.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
Steven Hartland wrote:
Mark Kirkwood wrote:
If you are using RAID0|5, then something is slowing you down (possible
clash between disk firmware and the Areca, or unfortunate choice of
strip chunk size).
Dont know which test I was remembering but just did a quicky:
OS: FreeBSD 6.1
RAID: 5 on 5
Steven Hartland wrote:
I believe you are wrong here and my own performance tests here
backs this up, showing it keeps up with the more expensive areca
in a number of areas notably, providing 180MB/s in sequential
read tests from a 5 disk array.
Steve,
Just out of interest what RAID level
Daniel O'Connor wrote:
On Friday 25 August 2006 01:52, Nikolas Britton wrote:
I believe Promise *do* support FreeBSD quite a bit.
Maybe as an after thought. I also don't see any link on their site for
FreeBSD support, lets check google:
shrugs
cvs log ata-chipset.c..
Chris H. wrote:
Hello,
I just recenlly found that I am almost always unable to
build X (Xorg) related applications on a 5.5 box that has
pretty recent source. The applications all die during the
make process with the following error:
error: syntax error before _X_SENTINEL
Any to fix this?
I just upped kern.maxdsize to 1G, but noticed that a test program that
mallocs and frees in a loop (increasing sized chunks 1M - 1024M) takes
about 6 times longer for 1024 iterations than it does only 512 of 'em.
Is this non-linearity expected?
I see from a profile that ifree is taking most
Kirk Strauser wrote:
Bumping shmall did the trick, but semmsl was pretty low so I bumped it up
just in case.
Is any of this stuff well documented other than in NOTES? I can see what
each setting does, but don't really have a feel for *why* I'd need to
increase a given setting, what the
Kirk Strauser wrote:
On Tuesday 23 May 2006 16:19, Jung-uk Kim wrote:
I meant 'kern.ipc.shmall', which used to be 'kern.ipc.shmmaxpgs'. :-(
That did it! Bumping kern.ipc.shmall to 65536 got me back up and running
with enough shared_memory to get my jobs done.
Having not so long ago been
Jonathan Chen wrote:
On Tue, May 23, 2006 at 09:03:06PM -0400, Dave wrote:
Hello,
I'm trying to compile 6.0-stable on a release box, prior to upgrade.
I've tried several times and all end with an internal compiler error:
segmentation fault: 11. And then i'm told to submit a bug report. My
I recently upgraded my FreeBSD machines from 6.0R to 6.1-STABLE
I noticed a pleasant surprise - improved disk IO!
In 6.0R best sequential throughput I ever saw was 170 MB/s (32k block
size reads on an 4G file). In 6.1-STABLE I'm seeing 190 Mb/s (32k block
size reads on an 4G file).
The
Mark Kirkwood wrote:
I recently upgraded my FreeBSD machines from 6.0R to 6.1-STABLE
I noticed a pleasant surprise - improved disk IO!
In 6.0R best sequential throughput I ever saw was 170 MB/s (32k block
size reads on an 4G file). In 6.1-STABLE I'm seeing 190 Mb/s (32k block
size reads
Mike Jakubik wrote:
Mark Kirkwood wrote:
Mark Kirkwood wrote:
I recently upgraded my FreeBSD machines from 6.0R to 6.1-STABLE
I noticed a pleasant surprise - improved disk IO!
In 6.0R best sequential throughput I ever saw was 170 MB/s (32k block
size reads on an 4G file). In 6.1-STABLE I'm
Mike Jakubik wrote:
Patches? For what? It's too late now, 6.1 has been released. I sent
reminders to the RE team and i made it quite clear on the lists that the
quota issue should be described in the relnotes/errata before the
release. If the RE team chooses to ignore major bugs and pretend
Doug White wrote:
On Sat, 6 May 2006, Mark Kirkwood wrote:
I found that installworld stops, because the 'audit' group has not been
created. Now I just pressed 'return' for the default actions during
mergemaster -p, but I didn't notice any mention of the audit group.
The default action
Pieter de Goeje wrote:
Hi Mark,
On Wednesday 10 May 2006 00:51, Mark Kirkwood wrote:
Just updated another box to 6.1-STABLE, and yes I did 'return' though
it. The reason being mergemaster -p wanted to patch my group file to
remove all the additions (i.e, useful groups and group - user
Doug White wrote:
On Sat, 6 May 2006, Mark Kirkwood wrote:
I found that installworld stops, because the 'audit' group has not been
created. Now I just pressed 'return' for the default actions during
mergemaster -p, but I didn't notice any mention of the audit group.
The default action
Last night I updated on of my machines from 6.0-RELEASE to 6.1-RC. As
far as I understand, I followed the instructions correctly - in particular:
boot -s
# fsck -p
# mount -u /
# mount -a
# adjkerntz -i
# cd /usr/src
# mergemaster -p
# make installworld
I found that installworld stops, because
Mark Kirkwood wrote:
I swapped out a TX2000 for a TX4000 today, and naively thought that I'd
just be able to plug in the new card and reboot. Unfortunately, it does
not detect the 4 drives (Maxtor 6E040L0).
Booting off the 6.0R install cd shows the card detected ok, and 6 ATA
channels - 2
I swapped out a TX2000 for a TX4000 today, and naively thought that I'd
just be able to plug in the new card and reboot. Unfortunately, it does
not detect the 4 drives (Maxtor 6E040L0).
Booting off the 6.0R install cd shows the card detected ok, and 6 ATA
channels - 2 on-board + 4 on-card.
JoaoBR wrote:
On Friday 03 March 2006 23:45, Mark Kirkwood wrote:
I would certainly see the installer handling software RAID as a
considerable benefit.
From what I've seen on the net, to install and boot off RAIDed system
disks is quite fiddly (maybe gmirror is the exception here, as I've
JoaoBR wrote:
thank's for your kind advice :)
so listen and learn:
FreeBSD any version from CD is up in 10 minutes, reboot is 30-40 seconds
that what you call complex procedure to set up a raid is done by three
commands, 2 minutes for a slow typer perhaps?
I would certainly see the
I tried a different setup - using a spare drive on the boards ata
controller, booting off that - and attaching a single drive to the
SX4060 after cvsuping to 6.1 Pre-5
Due to the boards buggy ServerWorks ROSB4 ata controller, I've set
hw.ata.ata_dma=0 in loader.conf (This might have helped
Christian Baer wrote:
Good morning, everyone!
There seems to have been some changes made concerning the supported
Promise controllers.
I have a SATA TX2Plus (PDC20775 chip). This is a sort of hybrid for SATA
and PATA - it can run two drives of both.
Until today I got this running with a sort
Peter Hoskin wrote:
Hi,
I've had a number of problems with this card. Please note I'm not using
this as a RAID card.
[EMAIL PROTECTED]:3:0: class=0x010400 card=0x61121095 chip=0x31121095
rev=0x02 hdr=0x00
vendor = 'Silicon Image Inc (Was: CMD Technology Inc)'
device = 'SiI
Peter Hoskin wrote:
Mark Kirkwood wrote:
Unfortunately the sii 3112 is a bit of a horrornumerous people
have experienced issues with it (web search on sii 3112 data
corruption makes quite interesting reading).
I seem to recall a posting suggesting that some success might be had
[EMAIL PROTECTED] wrote:
Hi all!
Once i installed ``old'' FreeBSD 5.0-STABLE with UFS file system.
It had been working fine for a while without any problems but sometime
later; it showed error messages on ttyv0; each error stated
ad1: TIMEOUT - READ_DMA retrying (2 retries left) LBA=17998815
Scott Long wrote:
Jonathan Noack wrote:
Kevin Oberman wrote:
Scott Long wrote:
Also, taking out CPU_I586 is usually a bad idea. It offers no
performance penalties (unlike CPU_I386 and maybe CPU_I486), but
enables things like optimized bcopy.
Ahh, This is the sort of thing I never
vizion wrote:
Thiis was originally
Upgrading 5.3 6.0 buildworld failure now in libmagic
And on Mike Shultz recommendation I have relabeled the topic
(mass snippage)
I have not tried to upgrade directly from 5.3 - 6.0 (however, I did do
5.4 - early 6-current a few months ago, so this is
C. Michailidis wrote:
This is a very straight-forward way of doing things. Do you really think that
sysinstall should use a similar method when it attempts to auto-configure a
slice?
From what I understand there are quite valid reasons why you would want a
seperate /, /var, /tmp, and /usr.
Matthias Buelow wrote:
Mark Kirkwood wrote:
FreeBSD's filesystems are very robust should you lose power.
This sentence is completely bogus (or at best: wishful thinking)
and should be deleted.
It's probably correct if you have hw.ata.wc=0 (and are using IDE drives
obviously
Matthias Buelow wrote:
(snippage...) I was
merely pointing out the inadequacy of talking about robust
filesystems in the context of softupdates and end-consumer harddrives.
Would you be happy if the handbook section added a caution, or referred
to the section that discusses the write cache?
Matthias Buelow wrote:
From what I understand from googling around on that issue, the
write-barrier stuff should make that much more unlikely. Of course
there could be the situation that it was a kernel that did not
(properly) support write-barriers yet, or the Linux implementation
has/had
Frans-Jan v. Steenbeek wrote:
Hi all,
I'm a sysadmin and a web-programmer at a company in the Netherlands. In
the following month we will launch a webshop which will have a estimated
1000 full hits in the first weeks (estimated through calculation of the
marketing-departement). I am writing the
Mark Kane wrote:
However, note that if I turn the drives speed down to UDMA100, the
errors seem to go away. Has anyone else tried this for their problems?
I currently do this, not due to problems, but to improve the write
performance:
4xMaxtor 6E040L0 RAID0
UDMA133 - 40M/s
UDMA100 -
Mark Kane wrote:
I do have a tall Antec case, and have both 200's and the 160 in 5 1/4
inch trays so the cables for those are long (36 inches IIRC).
Hmm - 36 inch cable, makes me wonder if that is what is causing the
problem in UDMA133 mode. IIRC the ATA spec says 18 inches, but most
cables
The Serverworks ROSB4 is known broken - I get instant file corruption on
mine if I try to run it at udma33.
Try
$ atacontrol mode 0 PIO4 PIO4
(I have not tried this - I just use a Promise PDC2071 for all the disks
instead...)
Cheers
Mark
Philip Murray wrote:
Hi,
I have a 4.11 machine
A little update on this:
I have upgraded my motherboard from Tyan S1854 (Award bios) to Tyan
S2510 (Ami. Megatrends bios). Same Promise TX2000, same disks. same
array. 5.4/6.0 install cds boot *fine*. So is bios change the
significant factor here?.
What I do notice is that the 5.4 (and 6.0) cd
Eriq wrote:
I notice that it takes a user about a minute after
'startx' to get into X. Yes I know, but I still like the colors :)
anyway this doesn't happen when I logon as root and start X. Blackbox is
the WM hope this helps.
hmmm *not* slow as root suggests permissions - maybe on font
Hmm - looks like I missed that thread, never mind - repeatability of
findings is sound scientific principle :-)
With respect to changing the default for vfs.read_max - makes sense to
me, but it would be interesting to know if anyone has a system that
performs *worse* with it set to 16.
I happened to have received a 'new' machine, and wanted to see what its
IO system was capable of. So took the opportunity to run 4.10 and 5.4
against each other a few times. (fresh re-installs each time).
Its documented at:
http://homepages.paradise.net.nz/markir/freebsd/
I wanted to play with
Daniel O'Connor wrote:
On Wed, 29 Jun 2005 15:57, Doug White wrote:
Try:
. Zero off the first megabyte or so of the subdisks with dd or similar
tool.
. Force an array initialize from the controller BIOS. Wait for it to
finish.
. Install some other OS that recognizes the array, write the MBR
Mark Kirkwood wrote:
Daniel O'Connor wrote:
On Wed, 29 Jun 2005 15:57, Doug White wrote:
Try:
. Zero off the first megabyte or so of the subdisks with dd or similar
tool.
. Force an array initialize from the controller BIOS. Wait for it to
finish.
. Install some other OS that recognizes
Matt Emmerton wrote:
I gave precise descriptions of what happened on 5.[234]
and can provide more details if requested
Please provide dmesg output from 4.x, as this will help us help you!
Cheers
Mark
___
freebsd-stable@freebsd.org mailing list
Matt Emmerton wrote:
Processor: Intel Pentium II 266 MHz (Slot 1)
Is the above typo, or have you underclocked it ?
(from the dmesg : CPU: Pentium II/Pentium II Xeon/Celeron (*232.67-MHz*
686-class CPU)
___
freebsd-stable@freebsd.org mailing
Steve Roome wrote:
I posted these results and anything else that went with this thread to
the freebsd-performance mailing list.
-current proved a slightly better performer for us, but not enough to
bring it even close to the performance we get with gentoo.
Off the top of my head the select
Daniel O'Connor wrote:
Hmm strange..
I tried it a few times on an ABit AV8, once on an Epox 8KRDA+ and a few times
on an Epox nForce2 board (I can't remember exactly which model) and it has
never worked. They all have AWARD BIOSen (if it matters)
I wonder if it's a problem where a memory
Daniel O'Connor wrote:
I find even disconnecting the drives so no RAID is detected works - ie it's
not the presence of the card per se that is a problem.
Good test - I had not tried that.
In addition, I can confirm your observation that merely deleting the
array makes the loader work
I have experienced this (since about 5.3) on a dual PIII Tyan S1834. In
my case perseverance seems to pay off - one in (approx) 10 boots will
work...
Mark
Daniel O'Connor wrote:
Hi,
I am updating an old 4.x system to 5.4 here and it has a Promise FT100TX2 RAID
controller (in mirror).
The
Glenn Dawson wrote:
At 11:24 PM 6/20/2005, Marc G. Fournier wrote:
I'm looking at adding my first 5.x server onto our network, but am
wondering how 'backward compatible' things are still ...
Mainly, could I run a 4.x jail'd environment on a 5.x server, or would
I have to upgrade the jail
1 - 100 of 125 matches
Mail list logo
