It seems Greg Lehey wrote:
for n in 1 2 3 4 5
do
dd if=/dev/adX of=/dev/null bs=512K count=1
Don't you mean
dd if=/dev/ad$n of=/dev/null bs=512K count=1
?
No, I mean it exactly as written (X is the number of the disk to test).
-Søren
To Unsubscribe: send mail to
Hi,
On Mon, Dec 03, 2001 at 09:28:26AM +0100, Sren Schmidt wrote:
No, I mean it exactly as written (X is the number of the disk to test).
Ah, you mean just do it 5 times?
Yeps, the idea here is that I want the drive to cache the data, so that
I can get the raw interface speed, that
It seems Miklos Niedermayer wrote:
On Mon, Dec 03, 2001 at 09:28:26AM +0100, S_ren Schmidt wrote:
No, I mean it exactly as written (X is the number of the disk to test).
Ah, you mean just do it 5 times?
Yeps, the idea here is that I want the drive to cache the data, so that
I
Hi,
On Mon, Dec 03, 2001 at 10:50:02AM +0100, Sren Schmidt wrote:
1+0 records in
1+0 records out
524288 bytes transferred in 0.006204 secs (84507936 bytes/sec)
But the disk needs to be idle or you risk getting another
request inbetween ruining the cached data, or if you disk has
less
It seems Miklos Niedermayer wrote:
I think they are idle (looking at vmstat -i), but i can't be sure.
However i have 2 machines here with VIA 82C596 chipset...
atapci0: VIA 82C596 ATA66 controller port 0xd800-0xd80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ad0: 28629MB
Søren Schmidt wrote:
It seems Miklos Niedermayer wrote:
I think they are idle (looking at vmstat -i), but i can't be sure.
However i have 2 machines here with VIA 82C596 chipset...
atapci0: VIA 82C596 ATA66 controller port 0xd800-0xd80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
It seems nuzrin yaapar wrote:
Hmm, yes that looks somewhat on the low side...
Well, two things, the older VIA chips are not the best performers, but
I still think it should be better than that, I'll run some tests here,
I might have messed up something...
Are we talking -current or
I keep getting the following error below when I try to make a complete
copy of the 'src' directory:
cvs server: Updating src/contrib/cpio
cvs checkout: in directory src/contrib/cvs:
cvs checkout: cannot open CVS/Entries for reading: No such file or
directory
cvs [checkout aborted]:
Glenn Gombert [EMAIL PROTECTED] wrote:
Are there any FreeBSD 'Anonymous' FreeBSD Servers avaiable besides:
:pserver:[EMAIL PROTECTED]:/home/ncvs ,
anoncvs.de.openbsd.org
--
Christian naddy Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL
On 4 Dez, nuzrin yaapar wrote:
I'm also getting around 20MB/sec.
dmesg:
atapci0: VIA 82C686 ATA100 controller port 0xd000-0xd00f at device 7.1
on pci0
ad0: 12416MB QUANTUM FIREBALL CX13.0A [25228/16/63] at ata0-master UDMA66
atapci0: VIA 82C686 ATA100 controller port 0xd000-0xd00f at
I was surprised by a compile time error with one of my programms on
FreeBSD-alpha.
HP-UX, Solaris and NetBSD expect the data argument as beeing
u_longlong_t which sounds logical given the function name.
On FreeBSD (verified on -current) it is defined to be u_quad_t which
resolves to unsigned
On Mon, Dec 03, 2001 at 03:35:13AM -0800, Glenn Gombert wrote:
I keep getting the following error below when I try to make a complete
copy of the 'src' directory:
cvs server: Updating src/contrib/cpio
cvs checkout: in directory src/contrib/cvs:
cvs checkout: cannot open CVS/Entries
On Mon, Dec 03, 2001 at 02:55:37AM +0100, Emiel Kollof wrote:
On Monday 03 December 2001 02:28, David Xu wrote:
This is strange, the problem would happen in heavy forked system which
have lots of pages
are shared between lots of process and most are commited to these
processes, this is
I can't really see how it would be, everything updates alright until
it starts working on the 'src/contrib/cpio' directory and then it stops
with the error shown below, I can try something else if you had an suggestion
on exactly what, any help would be greatly appreciated...
Glenn G.
On Mon, Dec 03, 2001 at 09:12:29AM -0800, Glenn Gombert wrote:
I can't really see how it would be, everything updates alright until
it starts working on the 'src/contrib/cpio' directory and then it stops
with the error shown below, I can try something else if you had an suggestion
on
Hello all,
Today I cannot boot into my machine with either kernel or kernel.old. Both
panic after trying to mount the filesystems. kernel.old is a generic kernel,
but kernel is a generic kernel from 11/12 source. Neither kernel is a debug
kernel. This panic does not seem to relate to the one
I think it is necessary to add the notice to UPDATING because it's been
half an year since the incident day. If it were like within last few
days, I definitely would've gotten some hints about the fix by scanning
-current (which I did). But I had to scratch my heads helplessly until
I asked the
On Wed, 28 Nov 2001, Sheldon Hearn wrote:
| I have some untested patches in my tree and I will contact bp this
| week about them (I wanted to import smbfs userland to the tree and
| already got ok from bp but could not test it because kernel-side smbfs
| is not compilable yet).
Galen Sampson [EMAIL PROTECTED] wrote:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc02b5baf
stack pointer = 0x10:0xcadc3d48
frame pointer = 0x10:0xbfbfadb4
:Hmm, I've just played around a bit, it seems we are hit by interrupt
:latency or something, if you limit the transfer to 128k, which allows
:the ATA controller to fetch it in one go, you will see the expected
:transfer rates. Now I dont see this on PCI based controllers, and that
:hints that the
This patch was done on -CURRENT.
It is both pasted and attached to this message.
Thanks
David
--- write.c.origMon Dec 3 17:42:45 2001
+++ write.c Mon Dec 3 17:45:22 2001
@@ -190,8 +190,7 @@
while (read(ufd, (char *) u, sizeof(u)) == sizeof(u))
if
* David Hill [EMAIL PROTECTED] [011203 16:50] wrote:
This patch was done on -CURRENT.
It is both pasted and attached to this message.
Which write.c is this to be applied to?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Mon, 3 Dec 2001 17:29:32 -0600
Alfred Perlstein [EMAIL PROTECTED] wrote:
* David Hill [EMAIL PROTECTED] [011203 16:50] wrote:
This patch was done on -CURRENT.
It is both pasted and attached to this message.
Which write.c is this to be applied to?
To Unsubscribe: send mail to
It seems Matthew Dillon wrote:
:Hmm, I've just played around a bit, it seems we are hit by interrupt
:latency or something, if you limit the transfer to 128k, which allows
:the ATA controller to fetch it in one go, you will see the expected
:transfer rates. Now I dont see this on PCI based
On Mon, 3 Dec 2001, Julian Elischer wrote:
do these patches include the proc-thread changes needed?
According to cvs logs - yes.
--
Boris Popov
http://rbp.euro.ru
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
: :sits on irq 14 15 making them the lowest priority devices in the system,
: :and that could cause the interrupt latency I'm seeing which then again
: :causes the bad transfer rates on transfers that need to transfer more
: :that one transaction full of data (ie max 128k).
: :
: :-Søren
:
:
At Mon, 3 Dec 2001 17:33:13 -0800 (PST),
Dag-Erling Smorgrav wrote:
Modified files:
sys/fs/procfsprocfs.h procfs_ctl.c procfs_dbregs.c
procfs_fpregs.c procfs_map.c procfs_mem.c
procfs_note.c procfs_regs.c
I'm about to commit patches to procfs(5) that will (unfortunately)
temporarily disable truss(1), until I finish extending ptrace(2) and
rewriting truss(1) to use that instead of procfs(5) (or find a quiet
moment to figure out why my legacy support code doesn't work). Until
then, use ktrace(1)
Hi,
We're seeing strange behavior of mpd (netgraph-ified ppp daemon)
under -current that doesn't occur under -stable.
The problem is that when mpd tries to do a connect(2) on a
(PF_INET, SOCK_RAW, IPPROTO_GRE), the kernel returns EINPROGRESS
instead of succeeding immediately (note: this is a
Below is the result of your feedback form. It was submitted by
([EMAIL PROTECTED]) on Monday, December 3, 2001 at 04:36:36
---
Dear Sir or Madam: Its finally here, the product we've all been waiting for... PORN
NAPSTER.
On 4 Dec 2001, Dag-Erling Smorgrav wrote:
I'm about to commit patches to procfs(5) that will (unfortunately)
temporarily disable truss(1), until I finish extending ptrace(2) and
rewriting truss(1) to use that instead of procfs(5) (or find a quiet
moment to figure out why my legacy support
31 matches
Mail list logo
