Re: dirty hack asmc for Macbook 3,1
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 Nabble.com. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 60.024997 secs (85298 bytes/sec) 1 ops in 60 seconds is practically the definition of a 10k drive. CentOS: 10+0 records in 10+0 records out 5120 bytes (51 MB) copied, 1.97883 s, 25.9 MB/s 10k ops in 2 seconds is 300k per second. You could make a flat-out *KILLING* if you could sell a platter drive that can pull that off. Presumably this is an instance of Linux only has block devices for hard drives, not character devices, so you're getting your writes all buffered over there. Which is to say, nothing's wrong, you're just not measuring the same thing. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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. There really is no reason why you should want dd to be buffered by default. How can you trust that your attempt at writing raw data to a device actually completed if it's buffered? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 s, 25.9 MB/s FreeBSD 9.1: 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? Can you strace the 'dd' command on CentOS to verify that it's using the actual block size you specified? Some programs (I've written at least one) cheat by actually doing larger I/O operations than you request. This makes a big difference in performance. So this could reflect optimizations in GNU dd more than any difference in the actual disk I/O. If you want to do a more robust comparison, look for one of the disk benchmarking programs in ports and see if it's available (in the same version) for CentOS. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 is disabled. that's all. linux always uses buffered devices, only relatively recently special OPTION was added to have raw ones. Complete nonsense but it's linux. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
off topic but no idea where to ask
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 boots from NFS or hard disk. thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: off topic but no idea where to ask
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 to decide from server side if given computer boots from NFS or hard disk. This may not be helpful, but maybe you can have the server just deny the PXE client the infomration needed to boot and set the BIOS to boot order to: 1st: PXE 2nd: local disk ? This way if the server doesn't respond to the pxe option then the client will then try local disk? -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: off topic but no idea where to ask
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 to be able to decide from server side if given computer boots from NFS or hard disk. Sounds like a job for PXE-enabled grub, but you probably can hack loader (pxeboot to be exact) to do the same thing. It would be nice to have a feature like this in mainline FreeBSD… Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: off topic but no idea where to ask
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 to be able to decide from server side if given computer boots
from NFS or hard disk.
Yeah, no prob.
NOTE: Our PXE server is Linux (*blech) but I assure you the only thing that
changes is the paths (/etc/dhcpd.conf becomes /usr/local/etc/dhcpd.conf for
example -- the pxelinux.0 image works fine served-up by ISC dhcpd on FreeBSD).
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
Next part of the recipe… The /etc/pxelinux.cfg/default file:
DISPLAY /boot/include/boot.msg
DEFAULT wpuchar_nfs
PROMPT 1
ONTIMEOUT hdd
TIMEOUT 50
TOTALTIMEOUT 6000
LABEL hdd
LOCALBOOT 0x80
LABEL wpuchar_nfs
… your nfs boot config …
Last but not least, …
$ cat /tftpboot/boot/include/boot.msg
Press ENTER to boot from WPuchar's NFS server (defaulting to HDD boot in 5
seconds)...
--
Devin
_
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Is there a way to prioritize disk operations ?
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 accessing the same disk. Is there a way to set the priority value on the process for the disk operations, so that all disk operations originating from the process will be scheduled in similar way how CPU is scheduled based on the nice value of the process? The disk-intense backup process with low disk priority won't affect the other processes at all. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is there a way to prioritize disk operations ?
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 backup copying large disk seriously affects performance of all other apps accessing the same disk. Is there a way to set the priority value on the process for the disk operations, so that all disk operations originating from the process will be scheduled in similar way how CPU is scheduled based on the nice value of the process? The disk-intense backup process with low disk priority won't affect the other processes at all. Yuri __**_ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackershttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscribe@** freebsd.org freebsd-hackers-unsubscr...@freebsd.org -- Freddie Cash fjwc...@gmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 this dd to the raw drive, to a filesystem? (FFS? ZFS? other?) Are you running compression, encryption, or some other feature that might slow things down? Also, try dd with a larger block size, like bs=1m. Hi, Thanks to everyone that answered so far. Here is a follow up. 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 bytes transferred in 1.057507 secs (48416 bytes/sec) # dd if=/dev/zero of=toto count=100 bs=104 100+0 records in 100+0 records out 10400 bytes transferred in 1.209524 secs (8598 bytes/sec) # dd if=/dev/zero of=toto count=100 bs=1024 100+0 records in 100+0 records out 102400 bytes transferred in 0.844302 secs (121284 bytes/sec) # dd if=/dev/zero of=toto count=100 bs=10240 100+0 records in 100+0 records out 1024000 bytes transferred in 2.173532 secs (471123 bytes/sec) # dd if=/dev/zero of=toto count=100 bs=102400 100+0 records in 100+0 records out 1024 bytes transferred in 19.915159 secs (514181 bytes/sec) # dd if=/dev/zero of=toto count=100 100+0 records in 100+0 records out 51200 bytes transferred in 1.070473 secs (47829 bytes/sec) # dd if=/dev/zero of=foo count=100 100+0 records in 100+0 records out 51200 bytes transferred in 0.683736 secs (74883 bytes/sec) # dd if=/dev/zero of=foo count=100 bs=1024 100+0 records in 100+0 records out 102400 bytes transferred in 0.682579 secs (150019 bytes/sec) # dd if=/dev/zero of=foo count=100 bs=10240 100+0 records in 100+0 records out 1024000 bytes transferred in 2.431012 secs (421224 bytes/sec) # dd if=/dev/zero of=foo count=100 bs=102400 100+0 records in 100+0 records out 1024 bytes transferred in 19.963030 secs (512948 bytes/sec) # dd if=/dev/zero of=foo count=10 bs=1024000 10+0 records in 10+0 records out 1024 bytes transferred in 19.615134 secs (522046 bytes/sec) # 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) Best regards, Karim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Getting the current thread ID without a syscall?
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) # pragma intrinsic(__readgsdword) # define _Py_get_current_process_id() (__readgsdword(0x40)) # define _Py_get_current_thread_id() (__readgsdword(0x48)) # elif defined(MS_WIN32) # pragma intrinsic(__readfsdword) # define _Py_get_current_process_id() (__readfsdword(0x20)) # define _Py_get_current_thread_id() (__readfsdword(0x24)) That exploits the fact that Windows uses the FS/GS registers to store thread/process metadata. Could I use a similar approach on FreeBSD to get the thread ID without the need for syscalls? (I technically don't need the thread ID, I just need to get some form of unique identifier for the current thread such that I can compare it to a known global value that's been set to the main thread, in order to determine if I'm currently that thread or not. As long as it's unique for each thread, and static for the lifetime of the thread, that's fine.) The am I the main thread? comparison is made every ~50-100 opcodes, which is why it needs to have the lowest overhead possible. Regards, Trent. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 going to match, not unless you exhaust physical memory and start falling behind on disk IO. At that point you'll see what the fuss is about. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting the current thread ID without a syscall?
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 # include intrin.h # if defined(MS_WIN64) # pragma intrinsic(__readgsdword) # define _Py_get_current_process_id() (__readgsdword(0x40)) # define _Py_get_current_thread_id() (__readgsdword(0x48)) # elif defined(MS_WIN32) # pragma intrinsic(__readfsdword) # define _Py_get_current_process_id() (__readfsdword(0x20)) # define _Py_get_current_thread_id() (__readfsdword(0x24)) That exploits the fact that Windows uses the FS/GS registers to store thread/process metadata. Could I use a similar approach on FreeBSD to get the thread ID without the need for syscalls? The layout of the per-thread structure used by libthr is private and is not guaranteed to be stable even on the stable branches. Yes, you could obtain the tid this way, but note explicitely that using it makes your application not binary compatible with any version of the FreeBSD except the one you compiled on. You could read the _thread_off_tid integer variable and use the value as offset from the %fs base to the long containing the unique thread id. But don't use this in anything except the private code. (I technically don't need the thread ID, I just need to get some form of unique identifier for the current thread such that I can compare it to a known global value that's been set to the main thread, in order to determine if I'm currently that thread or not. As long as it's unique for each thread, and static for the lifetime of the thread, that's fine.) The am I the main thread? comparison is made every ~50-100 opcodes, which is why it needs to have the lowest overhead possible. On newer CPUs in amd64 mode, there is getfsbase instruction which reads the %fs register base. System guarantees that %fs base is unique among live threads. pgpsp_lioKIEy.pgp Description: PGP signature
kgzip(1) is broken
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 MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting the current thread ID without a syscall?
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 with this glorious hack: #ifdef WITH_INTRINSICS # ifdef MS_WINDOWS # include intrin.h # if defined(MS_WIN64) # pragma intrinsic(__readgsdword) # define _Py_get_current_process_id() (__readgsdword(0x40)) # define _Py_get_current_thread_id() (__readgsdword(0x48)) # elif defined(MS_WIN32) # pragma intrinsic(__readfsdword) # define _Py_get_current_process_id() (__readfsdword(0x20)) # define _Py_get_current_thread_id() (__readfsdword(0x24)) That exploits the fact that Windows uses the FS/GS registers to store thread/process metadata. Could I use a similar approach on FreeBSD to get the thread ID without the need for syscalls? The layout of the per-thread structure used by libthr is private and is not guaranteed to be stable even on the stable branches. Yes, you could obtain the tid this way, but note explicitely that using it makes your application not binary compatible with any version of the FreeBSD except the one you compiled on. 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 verify the same ID is returned, falling back to the syscall by default.) You could read the _thread_off_tid integer variable and use the value as offset from the %fs base to the long containing the unique thread id. But don't use this in anything except the private code. Ah, thanks, that's what I was interested in knowing. (I technically don't need the thread ID, I just need to get some form of unique identifier for the current thread such that I can compare it to a known global value that's been set to the main thread, in order to determine if I'm currently that thread or not. As long as it's unique for each thread, and static for the lifetime of the thread, that's fine.) The am I the main thread? comparison is made every ~50-100 opcodes, which is why it needs to have the lowest overhead possible. On newer CPUs in amd64 mode, there is getfsbase instruction which reads the %fs register base. System guarantees that %fs base is unique among live threads. Interesting. I was aware of those instructions, but never assessed them in detail once I'd figured out the readgsdword approach. I definitely didn't realize they return unique values per thread (although it makes sense now that I think about it). Thanks Konstantin, very helpful. Trent. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting the current thread ID without a syscall?
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 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) # pragma intrinsic(__readgsdword) # define _Py_get_current_process_id() (__readgsdword(0x40)) # define _Py_get_current_thread_id() (__readgsdword(0x48)) # elif defined(MS_WIN32) # pragma intrinsic(__readfsdword) # define _Py_get_current_process_id() (__readfsdword(0x20)) # define _Py_get_current_thread_id() (__readfsdword(0x24)) That exploits the fact that Windows uses the FS/GS registers to store thread/process metadata. Could I use a similar approach on FreeBSD to get the thread ID without the need for syscalls? The layout of the per-thread structure used by libthr is private and is not guaranteed to be stable even on the stable branches. Yes, you could obtain the tid this way, but note explicitely that using it makes your application not binary compatible with any version of the FreeBSD except the one you compiled on. 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 verify the same ID is returned, falling back to the syscall by default.) For you, may be. For your users, it definitely will be a problem. And worse, the problem will be blamed on the operating system and not to the broken application. You could read the _thread_off_tid integer variable and use the value as offset from the %fs base to the long containing the unique thread id. But don't use this in anything except the private code. Ah, thanks, that's what I was interested in knowing. (I technically don't need the thread ID, I just need to get some form of unique identifier for the current thread such that I can compare it to a known global value that's been set to the main thread, in order to determine if I'm currently that thread or not. As long as it's unique for each thread, and static for the lifetime of the thread, that's fine.) The am I the main thread? comparison is made every ~50-100 opcodes, which is why it needs to have the lowest overhead possible. On newer CPUs in amd64 mode, there is getfsbase instruction which reads the %fs register base. System guarantees that %fs base is unique among live threads. Interesting. I was aware of those instructions, but never assessed them in detail once I'd figured out the readgsdword approach. I definitely didn't realize they return unique values per thread (although it makes sense now that I think about it). Thanks Konstantin, very helpful. Trent. pgpm7aloC53Ee.pgp Description: PGP signature
Re: off topic but no idea where to ask
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
don't care what it will be from linux or not, but if it works.
actually it would be just:
DEFAULT wpuchar_nfs
PROMPT 1
ONTIMEOUT hdd
TIMEOUT 50
TOTALTIMEOUT 6000
LABEL hdd
LOCALBOOT 0x80
and i would put pxelinux instead of pxeboot in dhcpd.conf for given
workstation when i want disk boot not NFS boot.
Thank you very much
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
# 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 recompile. Even with hard drive write cache disabled, it should about one write per revolution but seems to do 4 writes per second. so probably it is not that but much worse failure. Did you rest read speed? dd if=/dev/disk of=/dev/null bs=512 dd if=/dev/disk of=/dev/null bs=4k dd if=/dev/disk of=/dev/null bs=128k ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 before waiting for any of them to complete. I'd expect a dd to a raw device to throw a single, wait for it to return complete, then throw the next, leading to no more than 1 op per rev. (possibly less, with sufficiently fast revs and a sufficiently slow system, but that's a pretty unlikely combo with platter drives and remotely modern hardware unless it's under serious load otherwise) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kgzip(1) is broken
-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 in the 8.x series. I haven't tried the 7 series lately, but if whatever is making the rounds gets MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. I think this is i386 only? Also, are you trying to avoid loader(8)? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJQ9dYOAAoJEG80Jeu8UPuzPwoH/RRR+SATnzoH/tXz1o+qvg/4 9i5EnGp0lcwhQWHaCvC9vmxFPhDFDQIK6RGjUqzi5IIpRhtgO8sdcLYjYD4sMVVS U/XGNGXeL57EzVwwCmAc1zYXoVHvj8s+ZiEuThF8bXU3L81VxPfosVLp+xdQhyx4 5nOPEjsOtYOx+snBknBR6l1r7Z6bH7Y8pyvXFrz4PV7d5V/i8cIDNFBsjfefuTYL u98ZzXCfQGnMGNRXn+gJ0M+r1r4SxzNWSnfMDBem54EjKrHXReUsmy4ID03VV8R5 RnNK/pupPYEAuK46UcQxjv89fEV/CVUAAshX415QzOdj9qL4Te2TLOUKmBW8c1Y= =uZJa -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting the current thread ID without a syscall?
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 verify the same ID is returned, falling back to the syscall by default.) For you, may be. For your users, it definitely will be a problem. And worse, the problem will be blamed on the operating system and not to the broken application. Anything we can do to avoid this would be best. The reason is that we are still dealing with an optimization that perl did, it reached inside of the opaque struct FILE to do nasty things. Now it is very difficult for us to fix struct FILE. We are still paying for this years later. Any way we can make this a supported interface? -Alfred ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting the current thread ID without a syscall?
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 intrinsic result versus the syscall result during startup to verify the same ID is returned, falling back to the syscall by default.) For you, may be. For your users, it definitely will be a problem. And worse, the problem will be blamed on the operating system and not to the broken application. Anything we can do to avoid this would be best. The reason is that we are still dealing with an optimization that perl did, it reached inside of the opaque struct FILE to do nasty things. Now it is very difficult for us to fix struct FILE. We are still paying for this years later. Any way we can make this a supported interface? -Alfred Re-reading the original question, I've got to ask why pthread_self() isn't the right answer? The requirement wasn't I need to know what the OS calls me it was I need a unique ID per thread within a process. -- Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: kgzip(1) is broken
-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 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 in the 8.x series. I haven't tried the 7 series lately, but if whatever is making the rounds gets MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. I think this is i386 only? Also, are you trying to avoid loader(8)? Yes, this is i386 only. We are using loader(8) and have not had a problem in using kgzip'd kernels from loader(8) for any release from 4.8 to 8.3-RELEASE-p1. It's only the 9.x releases and (now recently) 8.3-RELEASE-p5 that's exhibiting this behavior. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 the buffer cache. The results aren't going to match, not unless you exhaust physical memory and start falling behind on disk IO. At that point you'll see what the fuss is about. To put is simply and maybe give a bit more context, here is what we're doing: 1) Boot OS (Linux or FreeBSD in this case) 2) dd some image over to the SAS drive. 3) rinse and repeat for X times. 4) profit. In this case if step 1) is done with Linux we get 100 times more profit. I was wondering if we could close the gap. Karim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting the current thread ID without a syscall?
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 recompilation isn't a big deal. (I also check the intrinsic result versus the syscall result during startup to verify the same ID is returned, falling back to the syscall by default.) For you, may be. For your users, it definitely will be a problem. And worse, the problem will be blamed on the operating system and not to the broken application. Anything we can do to avoid this would be best. The reason is that we are still dealing with an optimization that perl did, it reached inside of the opaque struct FILE to do nasty things. Now it is very difficult for us to fix struct FILE. We are still paying for this years later. Any way we can make this a supported interface? -Alfred Re-reading the original question, I've got to ask why pthread_self() isn't the right answer? The requirement wasn't I need to know what the OS calls me it was I need a unique ID per thread within a process. The identity check is performed hundreds of times per second. The overhead of (Py_MainThreadId == __readgsdword(0x48) ? A() : B()) is negligible -- I can't say the same for a system/function call. (I'm experimenting with an idea I had to parallelize Python such that it can exploit all cores without impeding the performance of normal single-threaded execution (like previous-GIL-removal attempts and STM). It's very promising so far -- presuming we can get the current thread ID in a couple of instructions. If not, single-threaded performance suffers too much.) Trent. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kgzip(1) is broken
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 tried the 7 series lately, but if whatever is making the rounds gets MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. Here are some possible candidates from the things that were MFC'd to 8 in that timeframe. I haven't looked at what these do, they're just changes that affect files related to booting. r233211 r233377 r233469 r234563 -- Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 options MAXPHYS=... in kernel config and recompile. Even with hard drive write cache disabled, it should about one write per revolution but seems to do 4 writes per second. so probably it is not that but much worse failure. Did you rest read speed? dd if=/dev/disk of=/dev/null bs=512 dd if=/dev/disk of=/dev/null bs=4k dd if=/dev/disk of=/dev/null bs=128k As you mentioned the dd file tests were done UFS and not on raw device. I will get those numbers for you. Thanks, Karim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: kgzip(1) is broken
-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 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 MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. Here are some possible candidates from the things that were MFC'd to 8 in that timeframe. I haven't looked at what these do, they're just changes that affect files related to booting. r233211 r233377 r233469 r234563 Thanks Ian! I'll test each one individually to see if regressing any one (or all) addresses the problem. -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 bytes transferred in 1.057507 secs (48416 bytes/sec) By raw drive I meant something like dd if=/dev/zero of=/dev/da0 bs=1m count=1000 of=toto implies that you are using a filesystem. (FFS? ZFS? other?) Matthew writes: 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 before waiting for any of them to complete. I'd expect a dd to a raw device to throw a single, wait for it to return complete, then throw the next, leading to no more than 1 op per rev. I see a huge speedup from NCQ on both raw disks and with FFS/su. Without NCQ I only get 6% of the expected performance, even with a large blocksize. 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. Writing an entire 3TB disk (raw disk, no fs) gives: 21378.98 real 2.00 user 440.98 sys or 140 MB/s (133 MiB/s) on slow controller in PCIe x1 slot. The same test on the same make model disk on a much faster controller in the chipset takes over 10x as long because FreeBSD does not support NCQ on that controller. :-( Karim's data sure looks like 1 op per rev. Either it isn't really doing NCQ or the filesystem is doing something to keep NCQ from being effective. For example, mounting the fs with the sync option would probably have that effect. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: kgzip(1) is broken
-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- 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 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 MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. Here are some possible candidates from the things that were MFC'd to 8 in that timeframe. I haven't looked at what these do, they're just changes that affect files related to booting. r233211 r233377 r233469 r234563 Thanks Ian! I'll test each one individually to see if regressing any one (or all) addresses the problem. Progress... Looks like I found the culprit. Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where kgzip seems to never work). I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause kgzip to produce non-working kernels. I'm emailing the maintainers (davidch + other Broadcom folk) -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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. /dev/rda0 with an 'r'. (Now if I could just remember *why* it doesn't.) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: kgzip(1) is broken
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 Subject: RE: kgzip(1) is broken -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 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 MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. Here are some possible candidates from the things that were MFC'd to 8 in that timeframe. I haven't looked at what these do, they're just changes that affect files related to booting. r233211 r233377 r233469 r234563 Thanks Ian! I'll test each one individually to see if regressing any one (or all) addresses the problem. Progress... Looks like I found the culprit. Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where kgzip seems to never work). I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause kgzip to produce non-working kernels. Yeah, it'll be interesting to see how a device driver can lead to the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader, which I took to mean before seeing the copyright or anything. I'm emailing the maintainers (davidch + other Broadcom folk) -- Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: kgzip(1) is broken
-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: 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- 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 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 MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. Here are some possible candidates from the things that were MFC'd to 8 in that timeframe. I haven't looked at what these do, they're just changes that affect files related to booting. r233211 r233377 r233469 r234563 Thanks Ian! I'll test each one individually to see if regressing any one (or all) addresses the problem. Progress... Looks like I found the culprit. Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where kgzip seems to never work). I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause kgzip to produce non-working kernels. Yeah, it'll be interesting to see how a device driver can lead to the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader, which I took to mean before seeing the copyright or anything. Indeed... loader throws up the syms and upon execution *KABOOM* (screen goes black and back to POST) The copyright never appears. I'm emailing the maintainers (davidch + other Broadcom folk) The current dossier is even more interesting... the back-ported driver (with zero modifications mind you from stable/9 to stable/8) exhibits memory failures (example below), and causes terminals to become wedged when attempting to (for example) scp a file over an existing configured network (igb-based -- presumably unrelated to bxe but in practice loading bxe causes igb to misbehave). $ ifconfig bxe0 inet 192.168.1.5/24 bxe0: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill fp[00] RX chain. bxe0: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! $ ifconfig bxe1 inet 192.168.1.6/24 bxe1: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill fp[00] RX chain. bxe1: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! (as expected, also sent mail off to maintainers w/respect to above notes/errors) -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kgzip(1) is broken
- 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 [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: 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- 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 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 MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. Here are some possible candidates from the things that were MFC'd to 8 in that timeframe. I haven't looked at what these do, they're just changes that affect files related to booting. r233211 r233377 r233469 r234563 Thanks Ian! I'll test each one individually to see if regressing any one (or all) addresses the problem. Progress... Looks like I found the culprit. Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where kgzip seems to never work). I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause kgzip to produce non-working kernels. Yeah, it'll be interesting to see how a device driver can lead to the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader, which I took to mean before seeing the copyright or anything. Indeed... loader throws up the syms and upon execution *KABOOM* (screen goes black and back to POST) The copyright never appears. I'm emailing the maintainers (davidch + other Broadcom folk) The current dossier is even more interesting... the back-ported driver (with zero modifications mind you from stable/9 to stable/8) exhibits memory failures (example below), and causes terminals to become wedged when attempting to (for example) scp a file over an existing configured network (igb-based -- presumably unrelated to bxe but in practice loading bxe causes igb to misbehave). $ ifconfig bxe0 inet 192.168.1.5/24 bxe0: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill fp[00] RX chain. bxe0: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! $ ifconfig bxe1 inet 192.168.1.6/24 bxe1: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill fp[00] RX chain. bxe1: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! (as expected, also sent mail off to maintainers w/respect to above notes/errors) Sounds like you may be out of mbufs which is easy, on a box with 4 igb's simply booting without tuning with cause this so, if you have igb's and bxe's this could be your cause. Try adding the following to loader.conf and see if it helps:- kern.ipc.nmbclusters=51200 Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[RFC] add gdb into the cross-build target
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 patch. Thanks!
Adrian
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 245281)
+++ Makefile.inc1 (working copy)
@@ -1211,6 +1211,7 @@
${_clang_libs} \
${_clang} \
${_binutils} \
+gnu/usr.bin/gdb \
${_cc} \
usr.bin/xlint/lint1 usr.bin/xlint/lint2 usr.bin/xlint/xlint \
${_btxld} \
@@ -1673,6 +1674,7 @@
.for _tool in \
gnu/usr.bin/binutils \
gnu/usr.bin/cc \
+gnu/usr.bin/gdb \
usr.bin/ar
${_+_}@${ECHODIR} === xdev ${_tool} (obj,depend,all); \
cd ${.CURDIR}/${_tool}; \
@@ -1699,6 +1701,7 @@
.for _tool in \
gnu/usr.bin/binutils \
gnu/usr.bin/cc \
+gnu/usr.bin/gdb \
usr.bin/ar
${_+_}@${ECHODIR} === xdev ${_tool} (install); \
cd ${.CURDIR}/${_tool}; \
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 like it. I assume these numbers are reading. You should get numbers nearly this high when writing. Can you try writing to the bare drive without a filesystem? time dd if=/dev/da0 of=/dev/null bs=124k count=25 time (dd if=/dev/zero if=/dev/da0 bs=124k count=25; sync) Between writing more data than the size of memory and the sync, this should hopefully reduce any buffering effects down into the noise and make the numbers more comparable between FreeBSD and Linux. (and more honest) Also eliminates any effect from the filesystem, which will be different between FreeBSD and Linux. Writing should be almost as fast as reading. Is the disk healthy? Smartctl might give a clue. If the disk is healthy and you still get numbers that indicate one write per rev without a filesystem, then the question is why does the driver claim queueing but not deliver it? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 options MAXPHYS=... in kernel config and recompile. Even with hard drive write cache disabled, it should about one write per revolution but seems to do 4 writes per second. so probably it is not that but much worse failure. Did you rest read speed? dd if=/dev/disk of=/dev/null bs=512 dd if=/dev/disk of=/dev/null bs=4k dd if=/dev/disk of=/dev/null bs=128k ? I'll do the read test as well but if I recall correctly it seemed pretty decent. 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 see with SAS...). I find it strange that diskinfo reports those transfer rates: 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 Yet we get only a tiny fraction of those (it takes 20 seconds to transfer 10MB!) when using dd. I also doubt its dd's behavior since how can we explain the performance going up with SATA when doing the same test? Unfortunately, we'll have to move on soon and we're about to write off SAS and use SATA instead. Thanks, Karim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 be getting more than one op per rev, and writes should be fast. Is this dd to the raw drive, to a filesystem? (FFS? ZFS? other?) Are you running compression, encryption, or some other feature that might slow things down? Also, try dd with a larger block size, like bs=1m. Hi, Thanks to everyone that answered so far. Here is a follow up. 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: You say dd with a raw drive, but as several people have pointed out, linux dd doesn't go directly to the drive by default. It looks like you can make it do so with the direct option, which should make it behave the same as freebsd's dd behaves by default (I think, I'm no linux expert). For example, using a usb thumb drive: th2 # dd if=/dev/sdb4 of=/dev/null count=100 100+0 records in 100+0 records out 51200 bytes (51 kB) copied, 0.0142396 s, 3.6 MB/s th2 # dd if=/dev/sdb4 of=/dev/null count=100 iflag=direct 100+0 records in 100+0 records out 51200 bytes (51 kB) copied, 0.0628582 s, 815 kB/s Hmm, just before hitting send I saw your other response that SAS drives behave badly, SATA are fine. That does seem to point away from dd behavior. It might still be interesting to see if the direct flag on linux drops performance into the same horrible range as freebsd with SAS. -- Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Getting the current thread ID without a syscall?
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 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 verify the same ID is returned, falling back to the syscall by default.) For you, may be. For your users, it definitely will be a problem. And worse, the problem will be blamed on the operating system and not to the broken application. Anything we can do to avoid this would be best. The reason is that we are still dealing with an optimization that perl did, it reached inside of the opaque struct FILE to do nasty things. Now it is very difficult for us to fix struct FILE. We are still paying for this years later. Any way we can make this a supported interface? -Alfred Re-reading the original question, I've got to ask why pthread_self() isn't the right answer? The requirement wasn't I need to know what the OS calls me it was I need a unique ID per thread within a process. The identity check is performed hundreds of times per second. The overhead of (Py_MainThreadId == __readgsdword(0x48) ? A() : B()) is negligible -- I can't say the same for a system/function call. (I'm experimenting with an idea I had to parallelize Python such that it can exploit all cores without impeding the performance of normal single-threaded execution (like previous-GIL-removal attempts and STM). It's very promising so far -- presuming we can get the current thread ID in a couple of instructions. If not, single-threaded performance suffers too much.) If the only thing you ever need is to get a unique handle for the current thread, without the requirement that it corresponds to any other identifier, everything becomes much easier. On amd64, use 'movq %fs:0,%register', on i386 'movl %gs:0,%register'. This instruction is guaranteed to return the thread-unique address of the tcb. See an article about ELF TLS for more details. Even better, this instruction is portable among all ELF Unixes which support TLS. pgpnI6yuTRWOO.pgp Description: PGP signature
[RFC] support -b baudrate when starting gdb
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 115200 console MIPS
device.
The MIPS stuff has other issues; I'll talk about those later.
Thanks,
Adrian
Index: gnu/usr.bin/gdb/kgdb/main.c
===
--- gnu/usr.bin/gdb/kgdb/main.c (revision 245281)
+++ gnu/usr.bin/gdb/kgdb/main.c (working copy)
@@ -333,11 +333,24 @@
args.argv = malloc(sizeof(char *));
args.argv[0] = argv[0];
- while ((ch = getopt(argc, argv, ac:d:fn:qr:vw)) != -1) {
+ while ((ch = getopt(argc, argv, ab:c:d:fn:qr:vw)) != -1) {
switch (ch) {
case 'a':
annotation_level++;
break;
+ case 'b':
+ {
+ int i;
+ char *p;
+
+ i = strtol (optarg, p, 0);
+ if (i == 0 p == optarg)
+ warnx(warning: could not set baud
rate to `%s'.\n,
+ optarg);
+ else
+ baud_rate = i;
+ }
+ break;
case 'c': /* use given core file. */
if (vmcore != NULL) {
warnx(option %c: can only be specified once,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] support -b baudrate when starting gdb
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 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 115200 console MIPS
device.
The MIPS stuff has other issues; I'll talk about those later.
Thanks,
Adrian
Index: gnu/usr.bin/gdb/kgdb/main.c
===
--- gnu/usr.bin/gdb/kgdb/main.c (revision 245281)
+++ gnu/usr.bin/gdb/kgdb/main.c (working copy)
@@ -333,11 +333,24 @@
args.argv = malloc(sizeof(char *));
args.argv[0] = argv[0];
- while ((ch = getopt(argc, argv, ac:d:fn:qr:vw)) != -1) {
+ while ((ch = getopt(argc, argv, ab:c:d:fn:qr:vw)) != -1) {
switch (ch) {
case 'a':
annotation_level++;
break;
+ case 'b':
+ {
+ int i;
+ char *p;
+
+ i = strtol (optarg, p, 0);
+ if (i == 0 p == optarg)
+ warnx(warning: could not set baud
rate to `%s'.\n,
+ optarg);
+ else
+ baud_rate = i;
+ }
+ break;
case 'c': /* use given core file. */
if (vmcore != NULL) {
warnx(option %c: can only be specified once,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 with an 'r'. (Now if I could just remember *why* it doesn't.) because they are only raw devices. caching is in filesystem. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 (it takes 20 seconds to transfer 10MB!) when using dd. I also doubt its dd's behavior since how can we explain dd is fine. hardware configuration isn't ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
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 see with SAS...). Major clue there! According to wikipedia: Most SAS drives provide tagged command queuing, while most newer SATA drives provide native command queuing [1] Note that the driver says Command Queueing enabled without specifying which. If the driver is trying to use SATA's NCQ but the drive only speaks SCSI's TCQ, that could explain it. Or if the TCQ isn't working for some other reason. See if there are any error messages in dmesg or /var/log. If not, perhaps the driver has extra debugging you could turn on. Get TCQ working and make sure your partitions are aligned on 4 KiB boundaries (in case the drive actually has 4 KiB sectors), and you should get the expected performance. [1] http://en.wikipedia.org/wiki/Serial_attached_SCSI ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
