I filed a PR at kern/175260
http://http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/175260
Regards,
zeissoctopus
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/dirty-hack-asmc-for-Macbook-3-1-tp5776597p5777918.html
Sent from the freebsd-hackers mailing list archive at
On Tue, Jan 15, 2013 at 09:12:14AM -0500 I heard the voice of
Karim Fodil-Lemelin, and lo! it spake thus:
da0: IBM-ESXS HUC106030CSS60 D3A6 Fixed Direct Access SCSI-6 device
That's a 10k RPM drive.
FreeBSD 9.1:
1+0 records in
1+0 records out
512 bytes transferred in
Dur...
10k ops in 2 seconds is 300k per second.
RPM I mean...
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
On Tue, 15 Jan 2013 08:12:14 -0600, Karim Fodil-Lemelin
fodillemlinka...@gmail.com wrote:
Hi,
I'm struggling getting FreeBSD 9.1 properly work on an IBM blade server
(HS22). Here is a dd output from Linux CentOS vs FreeBSD 9.1.
GNU dd is heavily buffered unless you tell it not to be.
1+0 records out
512 bytes transferred in 60.024997 secs (85298 bytes/sec)
1 ops in 60 seconds is practically the definition of a 10k drive.
nonsense.
___
freebsd-hackers@freebsd.org mailing list
On Jan 15, 2013, at 6:12 AM, Karim Fodil-Lemelin wrote:
Hi,
I'm struggling getting FreeBSD 9.1 properly work on an IBM blade server
(HS22). Here is a dd output from Linux CentOS vs FreeBSD 9.1.
CentOS:
10+0 records in
10+0 records out
5120 bytes (51 MB) copied, 1.97883
1+0 records in
1+0 records out
512 bytes transferred in 60.024997 secs (85298 bytes/sec)
What exactly was the 'dd' command you used?
In particular, what block size did you specify?
512/1=512
default
if it takes one revolution for one write it means that write caching
does anyone know a PXE image (just like /boot/pxeboot) that can be placed
on tftp server and the only thing it will do would be loading first sector
from first local disk at 0x07c00 and booting as with normal hard drive.
what i need is to be able to decide from server side if given computer
On 1/15/13 10:18 AM, Wojciech Puchar wrote:
does anyone know a PXE image (just like /boot/pxeboot) that can be
placed on tftp server and the only thing it will do would be loading
first sector from first local disk at 0x07c00 and booting as with
normal hard drive.
what i need is to be able
On Jan 15, 2013, at 10:18 AM, Wojciech Puchar wrote:
does anyone know a PXE image (just like /boot/pxeboot) that can be placed on
tftp server and the only thing it will do would be loading first sector from
first local disk at 0x07c00 and booting as with normal hard drive.
what i need is
On Jan 15, 2013, at 10:18 AM, Wojciech Puchar wrote:
does anyone know a PXE image (just like /boot/pxeboot) that can be placed on
tftp server and the only thing it will do would be loading first sector from
first local disk at 0x07c00 and booting as with normal hard drive.
what i need is
Currently one can set nice value to the process. But it only affects the
CPU scheduling, so if this process is CPU bound it would yield to others.
What if the process is disk-bound, like some backup operations? The
backup copying large disk seriously affects performance of all other
apps
man gsched
On Tue, Jan 15, 2013 at 12:09 PM, Yuri y...@rawbw.com wrote:
Currently one can set nice value to the process. But it only affects the
CPU scheduling, so if this process is CPU bound it would yield to others.
What if the process is disk-bound, like some backup operations? The
On 15/01/2013 3:03 PM, Dieter BSD wrote:
Disabling the disks's write cache is *required* for data integrity.
One op per rev means write caching is disabled and no queueing.
But dmesg claims Command Queueing enabled, so you should be getting
more than one op per rev, and writes should be fast.
Is
Howdy,
I have an unusual requirement: I need to get the current thread ID
in as few instructions as possible. On Windows, I managed to come
up with this glorious hack:
#ifdef WITH_INTRINSICS
# ifdef MS_WINDOWS
# include intrin.h
# if defined(MS_WIN64)
#
Hi,
You're only doing one IO at the end. That's just plain silly. There's
all kinds of overhead that could show up, that would be amortized over
doing many IOs.
You should also realise that the raw disk IO on Linux is by default
buffered, so you're hitting the buffer cache. The results aren't
On Tue, Jan 15, 2013 at 03:54:03PM -0500, Trent Nelson wrote:
Howdy,
I have an unusual requirement: I need to get the current thread ID
in as few instructions as possible. On Windows, I managed to come
up with this glorious hack:
#ifdef WITH_INTRINSICS
# ifdef MS_WINDOWS
Hello,
I have been sad of-late because kgzip(1) no longer produces a usable kernel.
All versions of 9.x suffer this.
And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently broke in
the 8.x series.
I haven't tried the 7 series lately, but if whatever is making the rounds gets
On Tue, Jan 15, 2013 at 01:16:41PM -0800, Konstantin Belousov wrote:
On Tue, Jan 15, 2013 at 03:54:03PM -0500, Trent Nelson wrote:
Howdy,
I have an unusual requirement: I need to get the current thread ID
in as few instructions as possible. On Windows, I managed to come
up
On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote:
On Tue, Jan 15, 2013 at 01:16:41PM -0800, Konstantin Belousov wrote:
On Tue, Jan 15, 2013 at 03:54:03PM -0500, Trent Nelson wrote:
Howdy,
I have an unusual requirement: I need to get the current thread ID
in as
First part of the recipe:
$ awk '/filename/!/^[[:space:]]*(#|$)/{print}' /etc/dhcpd.conf
filename pxelinux.0;
$ ls -l /tftpboot/pxelinux.0
lrwxrwxrwx 1 root root 15 May 15 2012 /tftpboot/pxelinux.0 - pxelinux.0-3.84
$ file /tftpboot/pxelinux.0-3.84
/tftpboot/pxelinux.0-3.84: data
# dd if=/dev/zero of=foo count=1 bs=1024
1+0 records in
1+0 records out
1024 bytes transferred in 19.579077 secs (523007 bytes/sec)
you write to file not device, so it will be clustered anyway by FreeBSD.
128kB by default, more if you put options MAXPHYS=... in kernel config and
On Tue, Jan 15, 2013 at 12:03:33PM -0800 I heard the voice of
Dieter BSD, and lo! it spake thus:
But dmesg claims Command Queueing enabled, so you should be
getting more than one op per rev, and writes should be fast.
Queueing would only help if your load threw multiple ops at the drive
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/15/13 13:27, dte...@freebsd.org wrote:
Hello,
I have been sad of-late because kgzip(1) no longer produces a
usable kernel.
All versions of 9.x suffer this.
And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this
recently broke
On 1/15/13 1:43 PM, Konstantin Belousov wrote:
On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote:
Luckily it's for an open source project (Python), so recompilation
isn't a big deal. (I also check the intrinsic result versus the
syscall result during startup to
On Tue, 2013-01-15 at 14:29 -0800, Alfred Perlstein wrote:
On 1/15/13 1:43 PM, Konstantin Belousov wrote:
On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote:
Luckily it's for an open source project (Python), so recompilation
isn't a big deal. (I also check the
-Original Message-
From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
hack...@freebsd.org] On Behalf Of Xin Li
Sent: Tuesday, January 15, 2013 2:20 PM
To: freebsd-hackers@freebsd.org
Subject: Re: kgzip(1) is broken
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 15/01/2013 3:55 PM, Adrian Chadd wrote:
You're only doing one IO at the end. That's just plain silly. There's
all kinds of overhead that could show up, that would be amortized over
doing many IOs.
You should also realise that the raw disk IO on Linux is by default
buffered, so you're hitting
On Tue, Jan 15, 2013 at 02:33:41PM -0800, Ian Lepore wrote:
On Tue, 2013-01-15 at 14:29 -0800, Alfred Perlstein wrote:
On 1/15/13 1:43 PM, Konstantin Belousov wrote:
On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote:
Luckily it's for an open source project (Python), so
On Tue, 2013-01-15 at 13:27 -0800, dte...@freebsd.org wrote:
Hello,
I have been sad of-late because kgzip(1) no longer produces a usable kernel.
All versions of 9.x suffer this.
And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently broke in
the 8.x series.
I haven't
On 15/01/2013 4:54 PM, Wojciech Puchar wrote:
# dd if=/dev/zero of=foo count=1 bs=1024
1+0 records in
1+0 records out
1024 bytes transferred in 19.579077 secs (523007 bytes/sec)
you write to file not device, so it will be clustered anyway by FreeBSD.
128kB by default, more if you put
-Original Message-
From: Ian Lepore [mailto:free...@damnhippie.dyndns.org]
Sent: Tuesday, January 15, 2013 3:05 PM
To: dte...@freebsd.org
Cc: freebsd-hackers@freebsd.org
Subject: Re: kgzip(1) is broken
On Tue, 2013-01-15 at 13:27 -0800, dte...@freebsd.org wrote:
Hello,
I
Karim writes:
dd to the
raw drive and no compression/encryption or some other features, just a
naive boot off a live 9.1 CD then dd (see below). The following results
have been gathered on the FreeBSD 9.1 system:
# dd if=/dev/zero of=toto count=100
100+0 records in
100+0 records out
51200
-Original Message-
From: Devin Teske [mailto:devin.te...@fisglobal.com] On Behalf Of
dte...@freebsd.org
Sent: Tuesday, January 15, 2013 3:10 PM
To: 'Ian Lepore'
Cc: freebsd-hackers@freebsd.org; dte...@freebsd.org
Subject: RE: kgzip(1) is broken
-Original Message-
I wrote:
The kernel must be doing write-behind even to a raw disk, otherwise
waiting for write(2) to return before issuing the next write would
slow it down as Matthew suggests.
And a minute after hitting send, I remembered that FreeBSD does not
provide the traditional raw disk devices, e.g.
On Tue, 2013-01-15 at 16:10 -0800, Devin Teske wrote:
-Original Message-
From: Devin Teske [mailto:devin.te...@fisglobal.com] On Behalf Of
dte...@freebsd.org
Sent: Tuesday, January 15, 2013 3:10 PM
To: 'Ian Lepore'
Cc: freebsd-hackers@freebsd.org; dte...@freebsd.org
-Original Message-
From: Ian Lepore [mailto:free...@damnhippie.dyndns.org]
Sent: Tuesday, January 15, 2013 4:43 PM
To: Devin Teske
Cc: dte...@freebsd.org; freebsd-hackers@freebsd.org
Subject: RE: kgzip(1) is broken
On Tue, 2013-01-15 at 16:10 -0800, Devin Teske wrote:
- Original Message -
From: dte...@freebsd.org
To: 'Ian Lepore' free...@damnhippie.dyndns.org
Cc: freebsd-hackers@freebsd.org; dte...@freebsd.org
Sent: Wednesday, January 16, 2013 12:56 AM
Subject: RE: kgzip(1) is broken
-Original Message-
From: Ian Lepore
Hi,
I'd like to propose adding gdb into the cross-build target.
This way MIPS, ARM, PPC etc targets will have gdb-arch built in the
cross-build environment, so it can be (hopefully) used for cross-build
debugging of the kernel, as well as remote debugging out of the box.
Here's my example
25.9 MB/s
Even Linux is pretty slow.
Transfer rates:
outside: 102400 kbytes in 0.685483 sec = 149384 kbytes/sec
middle:102400 kbytes in 0.747424 sec = 137004 kbytes/sec
inside:102400 kbytes in 1.051036 sec = 97428 kbytes/sec
That's more
On 15/01/2013 4:54 PM, Wojciech Puchar wrote:
# dd if=/dev/zero of=foo count=1 bs=1024
1+0 records in
1+0 records out
1024 bytes transferred in 19.579077 secs (523007 bytes/sec)
you write to file not device, so it will be clustered anyway by FreeBSD.
128kB by default, more if you put
On Tue, 2013-01-15 at 15:28 -0500, Karim Fodil-Lemelin wrote:
On 15/01/2013 3:03 PM, Dieter BSD wrote:
Disabling the disks's write cache is *required* for data integrity.
One op per rev means write caching is disabled and no queueing.
But dmesg claims Command Queueing enabled, so you should
On Tue, Jan 15, 2013 at 06:03:30PM -0500, Trent Nelson wrote:
On Tue, Jan 15, 2013 at 02:33:41PM -0800, Ian Lepore wrote:
On Tue, 2013-01-15 at 14:29 -0800, Alfred Perlstein wrote:
On 1/15/13 1:43 PM, Konstantin Belousov wrote:
On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson
Hi,
There doesn't seem to be a blessed way to set the baudrate from inside
gdb/kgdb. It seems to be set from '-b' on the command line.
However kgdb doesn't have this support.
This patch adds -b support so kgdb so I can override the default speed
(9600 it seems) to speak kgdb over serial to a
Also, I found 'set remotebaud' and 'set debug remote 1' to do this.
I'd like to add the code just to support the same -b flag as gdb (so
-r can also be used with a non-standard serial port.)
Thanks,
Adrian
On 15 January 2013 21:15, Adrian Chadd adr...@freebsd.org wrote:
Hi,
There doesn't
The kernel must be doing write-behind even to a raw disk, otherwise
waiting for write(2) to return before issuing the next write would
slow it down as Matthew suggests.
And a minute after hitting send, I remembered that FreeBSD does not
provide the traditional raw disk devices, e.g. /dev/rda0
Transfer rates:
outside: 102400 kbytes in 0.685483 sec = 149384 kbytes/sec
middle:102400 kbytes in 0.747424 sec = 137004 kbytes/sec
inside:102400 kbytes in 1.051036 sec = 97428 kbytes/sec
this is right.
Yet we get only a tiny fraction of those
Karim writes:
It is quite obvious that something is awfully slow on SAS drives,
whatever it is and regardless of OS comparison. We swapped the SAS
drives for SATA and we're seeing much higher speeds. Basically on par
with what we were expecting (roughly 300 to 400 times faster then what
we
48 matches
Mail list logo
