SCHED_ULE trouble after ugrade 6.2-RELEASE - 6.3-RELEASE
hi all my trouble description: --part of dmesg--- CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2392.26-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x400CNTX-ID Logical CPUs per core: 2 --- 1. using FreeBSD 6.2-RELEASE i386 SMP with SCHED_ULE description of boot process: system is booting normal 2. using FreeBSD 6.3-RELEASE i386 SMP with SCHED_ULE description of boot process: system is full stop on boot process message: - Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle - 3. using FreeBSD 6.3-STABLE i386 SMP with SCHED_ULE description of boot process: system is full stop on boot process message: - Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle - 4. using FreeBSD 6.3-RELEASE i386 SMP with SCHED_4BSD description of boot process: system is booting normal please any solution /Vladimir Ermakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: double start of scripts in /usr/local/etc/rc.d
Eygene Ryabinkin wrote: And is your /usr/X11R6 symlinked to /usr/local? have this symlink Then remove /usr/X11R6/etc from the local_startup variable (in /etc/rc.conf and/or in /etc/defaults/rc.conf) and enjoy single startup of scripts ;)) Seems like you had updated your system to Xorg 7.2, but forgot to run /usr/ports/Tools/scripts/mergebase.sh or mergebase.sh failed to remove /usr/X11R6/etc from local_startup. thx iam deleted this symlink /Vladimir Ermakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE trouble after ugrade 6.2-RELEASE - 6.3-RELEASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sam wrote: hi all my trouble description: Do NOT use ULE on 6.x. ULE has been revamped heavily on 7.0 and the version on 6.x is old, and is known to contain some bugs. Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHptQgi+vbBBjt66ARAvJvAJ4stGN+IC4kAyJLyJGDa7mfkNA58gCggj1V ErCk1Yiw8lU6UM1BACTbA2M= =pkR+ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: double start of scripts in /usr/local/etc/rc.d
Mon, Feb 04, 2008 at 11:56:21AM +0300, sam wrote: Then remove /usr/X11R6/etc from the local_startup variable (in /etc/rc.conf and/or in /etc/defaults/rc.conf) and enjoy single startup of scripts ;)) thx iam deleted this symlink No, no, no: you should not remove the symlink itself. By the immortal words of Kris Kennaway in /usr/ports/UPDATING: - When the merge operation completes successfully, the /usr/X11R6 directory hierarchy will be removed and replaced by a symlink to /usr/local. This symlink is necessary because some binary ports (and some remaining source ports) have hard-coded references to /usr/X11R6. - So you can hit the problem of hard-coded references. Just remove the string /usr/X11R6/etc from startup configuration as was described above. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: Greetings, Kris Kennaway wrote: Kris Kennaway wrote: Fixing all of the above I can send at about 13MB/sec (timecounter is not relevant any more). The CPU is spending about 75% of the time in the kernel, so that is the next place to look. [hit send too soon] Actually 15MB/sec once I disable all kernel debugging. This is identical to Linux 2.6.24 on the same hardware. The patch I use to fix hping brain-damage is attached. Kris Indeed this patch highly improve results (x2) under FreeBSD. On my hardware the max speeds under FreeBSD i still little slower compared to Linux (something like 19 vs 19.5 MB/s) but the speed is quite more stable under FreeBSD (under linux the average speed seems slower) I didn't tested the patch under linux but will do soon. Thanks for the help :) BTW 262144 is little high as this match the default value in FreeBSD, I tested with twice smaller buffer and do not see performance lost. Kris if you do not mind I'll write to hping developers to adopt this patch, and if no response from them I can try to reach the port maintainer, so we have this patched in ports? My patch is a bit crude, because I didnt have the courage to digest the entire structure of the code, so it may be slightly wrong with respect to other operating modes (the #if 0 part is wrong, but that code needs to be rewritten). Some version of it should be included in the software, but perhaps after renaming the patch file ;-) Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory allocation performance
Julian Elischer [EMAIL PROTECTED] writes: Dag-Erling Smørgrav [EMAIL PROTECTED] writes: Julian Elischer [EMAIL PROTECTED] writes: you mean FILO or LIFO right? Uh, no. You want to reuse the last-freed object, as it is most likely to still be in cache. exactly.. FILO or LIFO (last in First out.) Clearly, I must have written the above in an acute state of caffeine deprivation. You are perfectly correct. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Greetings, Kris Kennaway wrote: Kris Kennaway wrote: Fixing all of the above I can send at about 13MB/sec (timecounter is not relevant any more). The CPU is spending about 75% of the time in the kernel, so that is the next place to look. [hit send too soon] Actually 15MB/sec once I disable all kernel debugging. This is identical to Linux 2.6.24 on the same hardware. The patch I use to fix hping brain-damage is attached. Kris Indeed this patch highly improve results (x2) under FreeBSD. On my hardware the max speeds under FreeBSD i still little slower compared to Linux (something like 19 vs 19.5 MB/s) but the speed is quite more stable under FreeBSD (under linux the average speed seems slower) I didn't tested the patch under linux but will do soon. Thanks for the help :) BTW 262144 is little high as this match the default value in FreeBSD, I tested with twice smaller buffer and do not see performance lost. Kris if you do not mind I'll write to hping developers to adopt this patch, and if no response from them I can try to reach the port maintainer, so we have this patched in ports? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
On 04/02/2008, Stefan Lambrev [EMAIL PROTECTED] wrote: Kris if you do not mind I'll write to hping developers to adopt this patch, and if no response from them I can try to reach the port maintainer, so we have this patched in ports? As we're in a the whole world is a Linux situation, would it be helpful to open a page on our wiki to enumerate differences like this, that would help people write and port applications to FreeBSD? I know the sort of advice given by Kris should be obvious to professional developers, but history shows that it is not and that people rather read blogs than manuals. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sort(1) memory usage
Jeremy Chadwick [EMAIL PROTECTED] writes:
As you said: the code shows that when no files are specified (e.g. read
off a pipe), sort will make some assumptions regarding the initial
buffer size to read data into. The buffer size allocated in that case
is fairly large, rather than basing it off of the first line off stdin;
it looks like this is done to save CPU time in the long run (otherwise
you'd have to rellocate more later and take a hit; initbuf() is
responsible for that).
Oh give me a break, the self-starting exponential algorithm for growth
of dynamically allocated buffers has been known for decades. In case
any GNU sort developers are reading this, here it comes, free of charge:
static char *buf = NULL;
static size_t bufsz = 0;
static size_t buflen = 0;
int
buf_append(const char *str)
{
size_t len;
len = strlen(str);
if (buflen + len + 1 bufsz) {
size_t nbufsz = bufsz;
char *nbuf;
while (buflen + len + 1 nbufsz)
nbufsz = nbufsz * 2 + 1;
nbuf = realloc(buf, nbufsz);
if (nbuf == NULL)
return (-1);
buf = nbuf;
bufsz = nbufsz;
}
memcpy(buf + buflen, str, len);
buf[buflen + len] = '\0';
buflen += len;
return (0);
}
With a good allocator - and depending to some extent on the memory usage
pattern of the rest of your program - if you jump-start it by initally
allocating 16 kB or so (and setting bufsz accordingly), realloc() will
never need to copy anything - but even in the worst case, the amortized
cost will be O(2n), IIRC. This is practically unnoticeable next to the
cost of the sorting algorithm itself, which will be O(n log n) at best
and O(n*n) at worst.
Looking at the code, it seems to go to extreme lengths to get it
absolutely wrong. For instance, if hw.physmem / 8 hw.usermem, it will
pick the former, which means it's pretty much guaranteed to either fail
or hose your system (or both).
Can you expand on this? Looking at the code, it doesn't appear that's
possible. The code in question is default_sort_size(), which is used
when no -S or --buffer-size argument is specified.
I looked at how it computes the cap, which is MAX(total / 8, avail) - in
other words, never mind what's actually feasible, I want more! More!
More, I say!
Count this as a vote for ditching GNU sort in favor of a BSD-licensed
implementation (from {Net,Open}BSD for instance).
In this specific case, I think you're bashing GNU just because you feel
like it. Come on man... =/
No, I'm bashing GNU because it's bloated crap, as this example clearly
shows. It wouldn't be the first time a BSD rewrite of a GNU tool ended
up performing better; see for instance bsdtar. Besides, the FreeBSD
project has a tradition of replacing GNU tools with BSD-licensed
equivalents as long as no functionality is lost.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sort(1) memory usage
On Sun, Feb 03, 2008 at 04:31:34PM +0100, Dag-Erling Smørgrav wrote:
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
Erik Trulsson [EMAIL PROTECTED] writes:
Yep, it seems that GNU sort allocates a quite large buffer by default when
the size of the input is unknown (such as when it reads input from stdin.)
A quick check in the source code indicates that it tries to size this
buffer
according to how much memory the system has (and according to any limits
set
on how much memory the process is allowed to use.)
Uh, OK. This scaling doesn't seem to work correctly. It seems to
allocate 27 MB on 32-bit machines and 54 MB on 64-bit machines,
regardless of memory size.
I've looked at the code, as has a peer of mine.
As you said: the code shows that when no files are specified (e.g. read
off a pipe), sort will make some assumptions regarding the initial
buffer size to read data into. The buffer size allocated in that case
is fairly large, rather than basing it off of the first line off stdin;
it looks like this is done to save CPU time in the long run (otherwise
you'd have to rellocate more later and take a hit; initbuf() is
responsible for that).
I think being able to select which implementation you want (less memory
with more potential CPU overhead, vs. more memory with less potential
CPU overhead) would be best.
Regarding Erik's concern over how much is allocated on 32-bit vs.
64-bit: two things come to mind:
1) There was a recent discussion about this on freebsd-am64,
specifically in regards to increased VSZ of processes on amd64 vs. i386
with shared libraries:
http://lists.freebsd.org/pipermail/freebsd-amd64/2007-September/010254.html
2) int/long on amd64 are obviously 64-bit in size, while on i386 they're
32-bit (e.g. half the size). 27*2=54, so possibly that's where the
excess comes from?
Looking at the code, it seems to go to extreme lengths to get it
absolutely wrong. For instance, if hw.physmem / 8 hw.usermem, it will
pick the former, which means it's pretty much guaranteed to either fail
or hose your system (or both).
Can you expand on this? Looking at the code, it doesn't appear that's
possible. The code in question is default_sort_size(), which is used
when no -S or --buffer-size argument is specified.
Count this as a vote for ditching GNU sort in favor of a BSD-licensed
implementation (from {Net,Open}BSD for instance).
In this specific case, I think you're bashing GNU just because you feel
like it. Come on man... =/
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sort(1) memory usage
On Mon, Feb 04, 2008 at 04:04:35PM +0100, Dag-Erling Sm?rgrav wrote: Last I checked, it also (rather surprisingly) lacked -u (unique), which is required by POSIX. That must have been before the import into src/usr.bin/sort in 2000. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Synaptics
Me again. Mon, Feb 04, 2008 at 05:41:18PM +0300, Eygene Ryabinkin wrote: This is a sort of 'ping' mail, sorry. To the point: I had reproduced the problem and will start looking into it once this message will fly from my mailserver. Stay tuned ;)) OK, things should be better with the attached patch. I was not able to fully test the resulting Synaptics driver, since I have no Synaptics beast at my amd64 machine ;)) But with the provided patch, my Synaptics driver tries to search for the psm device, as I told him, so, please, give it a try. Must be patched with 'patch -p1' and one should be in the port directory. -- Eygene From 083c1be4c91da739436f2b1e509a96512ac05867 Mon Sep 17 00:00:00 2001 From: Eygene Ryabinkin [EMAIL PROTECTED] Date: Mon, 4 Feb 2008 19:17:43 +0300 Subject: [PATCH] Fix compilation at amd64 by overriding the ARCH variable properly. FreeBSD make sets ARCH variable to 'amd64' [1] and invokes GNU make. It inherits the ARCH variable and refuses to set it via ordinary '=' operator. So we must force ARCH assignments. [1] Try 'make -V ARCH' in the port directory. Signed-off-by: Eygene Ryabinkin [EMAIL PROTECTED] --- files/patch-Makefile |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/files/patch-Makefile b/files/patch-Makefile index 1ae3cbe..90870c5 100644 --- a/files/patch-Makefile +++ b/files/patch-Makefile @@ -1,5 +1,5 @@ Makefile.orig Sun Jul 16 00:58:26 2006 -+++ Makefile Sun Aug 13 10:47:35 2006 +--- Makefile.orig 2006-07-15 19:58:26.0 +0400 Makefile 2008-02-04 19:11:33.0 +0300 @@ -12,14 +12,14 @@ MANDIR = $(DESTDIR)$(PREFIX)/man @@ -8,7 +8,8 @@ + ARCH = $(shell uname -m) endif ifeq ($(ARCH),amd64) - ARCH = x86_64 +- ARCH = x86_64 ++ override ARCH = x86_64 endif ifeq ($(ARCH),x86_64) ARCH_DEFINES = -D__x86_64__ -D_XSERVER64 -- 1.5.3.8 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sort(1) memory usage
Joerg Sonnenberger [EMAIL PROTECTED] writes: On Mon, Feb 04, 2008 at 04:04:35PM +0100, Dag-Erling Sm?rgrav wrote: Last I checked, it also (rather surprisingly) lacked -u (unique), which is required by POSIX. That must have been before the import into src/usr.bin/sort in 2000. Oops - I looked at the man page, not the code, and misread the SYNOPSIS. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
fs/udf: vm pages overlap while reading large dir
More on the problem with reading big directories on UDF. First, some sleuthing. I came to believe that the problem is caused by some larger change in vfs/vm/buf area. It seems that now VMIO is applied to more vnode types than before. In particular it seems that now vnodes for devices have non-NULL v_object (or maybe this is about directory vnodes, I am not sure). Also it seems that the problem should happen for any directory with size larger than four 2048-bytes sectors (I think that any directory with 300 files would definitely qualify). After some code reading and run-time debugging, here are some facts about udf directory reading: 1. bread-ing is done via device vnode (as opposed to directory vnodes), as a consequence udf_strategy is not involved in directory reading 2. the device vnode has a non-NULL v_object, this means that VMIO is used 3. it seems that the code assumed that non-VM buffers are used 4. bread is done on as much data as possible, up to MAXBSIZE [and even slightly more in some cases] (i.e. code determines directory data size and attempts to read in everything in one go) 5. physical sector number adjusted to DEV_BSIZE (512 bytes) sectors is passed to bread - this is because of #1 above and peculiarities of buf system 6. directory reading and file reading are quite different, because the latter does reading via file vnode Let's a consider a simple case of directory reading 5 * PAGE_SIZE (4K) bytes starting from a physical sector N with N%2 = 0 from media with sector size of 2K (most common CD/DVD case): 1. we want to read 12 KB = 3 pages = 6 sectors starting from sector N, N%2 = 0 2. 4*N is passed as a sector number to bread 3. bo_bsize of the corresponding bufobj is a media sector size, i.e. 2K 4. actual read in bread will happen from b_iooffset of 4*N*DEV_BSIZE = N*2K, i.e. correct offset within the device 5. for a fresh read getblk will be called 6. getblk will set b_offset to blkno*bo_bsize=4*N*2K, i.e. 4 times the correct byte offset within the device 7. allocbuf will allocate pages using B_VMIO case 8. allocbuf calculates base page index as follows: pi = b_offset/PAGE_SIZE this means the following: sectors N and N+1 will be bound to a page with index 4*N*2K/4K = 2*N sectors N+2 and N+3 will be bound to the next page 2*N +1 sectors N+4 and N+5 is tied to the next page 2*N + 2 Now let's consider a directory read of 2 sectors (1 page) starting at physical sector N+1. Using the same calculations as above, we see that the sector will be tied to a page 2*(N+1) = 2*N + 2. And this page already contains valid cached data from the previous read, *but* it contains data from sectors N+4 and N+5 instead of N+1 and N+2. So, we see, that because of b_offset being 4 times the actual byte offset, we get incorrect page indexing. Namely, sector X gets associated with different pages depending on what sector is used as a starting sector for bread. If bread starts at sector N, then data of sector N+1 is associated with (second half of) page with index 2*N; but if bread starts at sector N+1 then it gets associated with (the first half of) page with index 2*(N+1). Previously, before VMIO change, data for all reads was put into separate buffers that did not share anything between them. So the problem was limited only to wasting memory with duplicate data, but no actual over-runs did happen. Now we have the over-runs because the VM pages are shared between the buffers of the same vnode. One obvious solution is to limit bread size to 2*PAGE_SIZE = 4 * sector_size. In this case, as before, we would waste some memory on duplicate data but we would avoid page overruns. If we limit bread size even more, to 1 sector, then we would not have any duplicate data at all. But there would still be some resource waste - each page would correspond to one sector, so 4K page would have only 2K of valid data and the other half in each page is unused. Another solution, which to me seems to be better, is to do usual reading - pass a directory vnode and 2048-byte sector offset to bread. In this case udf_strategy will get called for bklno translation, all offsets and indexes will be correct and everything will work perfectly as it is the case for all other filesystems. The only overhead in this case comes from the need to handle UDF_INVALID_BMAP case (where data is embedded into file entry). So it means that we have to call bmap_internal to see if we have that special case and hanlde it, and if the case is not special we would call bread on a directory vnode which means that bmap_internal would be called again in udf_strategy. One optimization that can be done in this case is to create a ligher version of bmap_internal that would merely check for the special case and wouldn't do anything else. I am attaching a patch based on the ideas above. It fixes the problem for me and doesn't seem to create any new ones :-) About the patch: hunk #1 fixes a copy/paste hunk #2 should fixes strategy to not set junk b_blkno in case
Re: gettimeofday() in hping
Greetings, Stefan Lambrev wrote: Greetings, Kris Kennaway wrote: Kris Kennaway wrote: Fixing all of the above I can send at about 13MB/sec (timecounter is not relevant any more). The CPU is spending about 75% of the time in the kernel, so that is the next place to look. [hit send too soon] Actually 15MB/sec once I disable all kernel debugging. This is identical to Linux 2.6.24 on the same hardware. The patch I use to fix hping brain-damage is attached. Kris Indeed this patch highly improve results (x2) under FreeBSD. On my hardware the max speeds under FreeBSD i still little slower compared to Linux (something like 19 vs 19.5 MB/s) but the speed is quite more stable under FreeBSD (under linux the average speed seems slower) I didn't tested the patch under linux but will do soon. Thanks for the help :) BTW 262144 is little high as this match the default value in FreeBSD, I tested with twice smaller buffer and do not see performance lost. Kris if you do not mind I'll write to hping developers to adopt this patch, and if no response from them I can try to reach the port maintainer, so we have this patched in ports? I have results from hping + patches with different counters in freebsd and linux: Linux - ACPI em1 in 22.257 MB/s 22.479 MB/s 15.384 GB out13.735 MB/s 14.247 MB/s 12.432 GB Linux -- TSC em1 in 22.334 MB/s 22.445 MB/s 18.599 GB out13.567 MB/s 14.176 MB/s 14.379 GB Linux - jiffies em1 in 22.119 MB/s 22.268 MB/s 20.078 GB out13.962 MB/s 14.058 MB/s 15.270 GB FreeBSD - ACPI em1 in 13.157 MB/s 13.162 MB/s 23.697 GB out13.150 MB/s 13.153 MB/s 17.976 GB FreeBSD - TSC em1 in 18.624 MB/s 18.832 MB/s 25.507 GB out17.008 MB/s 17.041 MB/s 19.681 GB FreeBSD - i8254 em1 in 6.763 MB/s 6.763 MB/s 26.005 GB out 6.756 MB/s 6.758 MB/s 20.151 GB FreeBSD - dummy em1 in 18.705 MB/s 18.796 MB/s 27.014 GB out17.217 MB/s 17.225 MB/s 21.082 GB It is weird that changing time counter in linux does not affect performance which may mean, that time counter is not changed at all (always TSC used?) ... But here are few others interesting findings 1) patch increase performance in linux too. 2) when flooding from linux the numbers of returned packets are less. 3) on both linux and freebsd the max combined speed is 35MB/s which is something like 630,000 packets/s Does anyone ever succeed to transfer without error more then 630kpps (300kpps incoming) with em driver and intel gigabit card? -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fs/udf: vm pages overlap while reading large dir
Andriy Gapon wrote: More on the problem with reading big directories on UDF. First, some sleuthing. I came to believe that the problem is caused by some larger change in vfs/vm/buf area. It seems that now VMIO is applied to more vnode types than before. In particular it seems that now vnodes for devices have non-NULL v_object (or maybe this is about directory vnodes, I am not sure). Also it seems that the problem should happen for any directory with size larger than four 2048-bytes sectors (I think that any directory with 300 files would definitely qualify). After some code reading and run-time debugging, here are some facts about udf directory reading: 1. bread-ing is done via device vnode (as opposed to directory vnodes), as a consequence udf_strategy is not involved in directory reading 2. the device vnode has a non-NULL v_object, this means that VMIO is used 3. it seems that the code assumed that non-VM buffers are used 4. bread is done on as much data as possible, up to MAXBSIZE [and even slightly more in some cases] (i.e. code determines directory data size and attempts to read in everything in one go) 5. physical sector number adjusted to DEV_BSIZE (512 bytes) sectors is passed to bread - this is because of #1 above and peculiarities of buf system 6. directory reading and file reading are quite different, because the latter does reading via file vnode Let's a consider a simple case of directory reading 5 * PAGE_SIZE (4K) bytes starting from a physical sector N with N%2 = 0 from media with sector size of 2K (most common CD/DVD case): 1. we want to read 12 KB = 3 pages = 6 sectors starting from sector N, N%2 = 0 2. 4*N is passed as a sector number to bread 3. bo_bsize of the corresponding bufobj is a media sector size, i.e. 2K 4. actual read in bread will happen from b_iooffset of 4*N*DEV_BSIZE = N*2K, i.e. correct offset within the device 5. for a fresh read getblk will be called 6. getblk will set b_offset to blkno*bo_bsize=4*N*2K, i.e. 4 times the correct byte offset within the device 7. allocbuf will allocate pages using B_VMIO case 8. allocbuf calculates base page index as follows: pi = b_offset/PAGE_SIZE this means the following: sectors N and N+1 will be bound to a page with index 4*N*2K/4K = 2*N sectors N+2 and N+3 will be bound to the next page 2*N +1 sectors N+4 and N+5 is tied to the next page 2*N + 2 Now let's consider a directory read of 2 sectors (1 page) starting at physical sector N+1. Using the same calculations as above, we see that the sector will be tied to a page 2*(N+1) = 2*N + 2. And this page already contains valid cached data from the previous read, *but* it contains data from sectors N+4 and N+5 instead of N+1 and N+2. So, we see, that because of b_offset being 4 times the actual byte offset, we get incorrect page indexing. Namely, sector X gets associated with different pages depending on what sector is used as a starting sector for bread. If bread starts at sector N, then data of sector N+1 is associated with (second half of) page with index 2*N; but if bread starts at sector N+1 then it gets associated with (the first half of) page with index 2*(N+1). Previously, before VMIO change, data for all reads was put into separate buffers that did not share anything between them. So the problem was limited only to wasting memory with duplicate data, but no actual over-runs did happen. Now we have the over-runs because the VM pages are shared between the buffers of the same vnode. One obvious solution is to limit bread size to 2*PAGE_SIZE = 4 * sector_size. In this case, as before, we would waste some memory on duplicate data but we would avoid page overruns. If we limit bread size even more, to 1 sector, then we would not have any duplicate data at all. But there would still be some resource waste - each page would correspond to one sector, so 4K page would have only 2K of valid data and the other half in each page is unused. Another solution, which to me seems to be better, is to do usual reading - pass a directory vnode and 2048-byte sector offset to bread. In this case udf_strategy will get called for bklno translation, all offsets and indexes will be correct and everything will work perfectly as it is the case for all other filesystems. The only overhead in this case comes from the need to handle UDF_INVALID_BMAP case (where data is embedded into file entry). So it means that we have to call bmap_internal to see if we have that special case and hanlde it, and if the case is not special we would call bread on a directory vnode which means that bmap_internal would be called again in udf_strategy. One optimization that can be done in this case is to create a ligher version of bmap_internal that would merely check for the special case and wouldn't do anything else. I am attaching a patch based on the ideas above. It fixes the problem for me and doesn't seem to create any new ones :-) About the patch: hunk #1 fixes a copy/paste hunk #2 should fixes strategy to not set
fs/udf: vm pages overlap while reading large dir [patch]
More on the problem with reading big directories on UDF. First, some sleuthing. I came to believe that the problem is caused by some larger change in vfs/vm/buf area. It seems that now VMIO is applied to more vnode types than before. In particular it seems that now vnodes for devices have non-NULL v_object (or maybe this is about directory vnodes, I am not sure). Also it seems that the problem should happen for any directory with size larger than four 2048-bytes sectors (I think that any directory with 300 files would definitely qualify). After some code reading and run-time debugging, here are some facts about udf directory reading: 1. bread-ing is done via device vnode (as opposed to directory vnodes), as a consequence udf_strategy is not involved in directory reading 2. the device vnode has a non-NULL v_object, this means that VMIO is used 3. it seems that the code assumed that non-VM buffers are used 4. bread is done on as much data as possible, up to MAXBSIZE [and even slightly more in some cases] (i.e. code determines directory data size and attempts to read in everything in one go) 5. physical sector number adjusted to DEV_BSIZE (512 bytes) sectors is passed to bread - this is because of #1 above and peculiarities of buf system 6. directory reading and file reading are quite different, because the latter does reading via file vnode Let's a consider a simple case of directory reading 5 * PAGE_SIZE (4K) bytes starting from a physical sector N with N%2 = 0 from media with sector size of 2K (most common CD/DVD case): 1. we want to read 12 KB = 3 pages = 6 sectors starting from sector N, N%2 = 0 2. 4*N is passed as a sector number to bread 3. bo_bsize of the corresponding bufobj is a media sector size, i.e. 2K 4. actual read in bread will happen from b_iooffset of 4*N*DEV_BSIZE = N*2K, i.e. correct offset within the device 5. for a fresh read getblk will be called 6. getblk will set b_offset to blkno*bo_bsize=4*N*2K, i.e. 4 times the correct byte offset within the device 7. allocbuf will allocate pages using B_VMIO case 8. allocbuf calculates base page index as follows: pi = b_offset/PAGE_SIZE this means the following: sectors N and N+1 will be bound to a page with index 4*N*2K/4K = 2*N sectors N+2 and N+3 will be bound to the next page 2*N +1 sectors N+4 and N+5 is tied to the next page 2*N + 2 Now let's consider a directory read of 2 sectors (1 page) starting at physical sector N+1. Using the same calculations as above, we see that the sector will be tied to a page 2*(N+1) = 2*N + 2. And this page already contains valid cached data from the previous read, *but* it contains data from sectors N+4 and N+5 instead of N+1 and N+2. So, we see, that because of b_offset being 4 times the actual byte offset, we get incorrect page indexing. Namely, sector X gets associated with different pages depending on what sector is used as a starting sector for bread. If bread starts at sector N, then data of sector N+1 is associated with (second half of) page with index 2*N; but if bread starts at sector N+1 then it gets associated with (the first half of) page with index 2*(N+1). Previously, before VMIO change, data for all reads was put into separate buffers that did not share anything between them. So the problem was limited only to wasting memory with duplicate data, but no actual over-runs did happen. Now we have the over-runs because the VM pages are shared between the buffers of the same vnode. One obvious solution is to limit bread size to 2*PAGE_SIZE = 4 * sector_size. In this case, as before, we would waste some memory on duplicate data but we would avoid page overruns. If we limit bread size even more, to 1 sector, then we would not have any duplicate data at all. But there would still be some resource waste - each page would correspond to one sector, so 4K page would have only 2K of valid data and the other half in each page is unused. Another solution, which to me seems to be better, is to do usual reading - pass a directory vnode and 2048-byte sector offset to bread. In this case udf_strategy will get called for bklno translation, all offsets and indexes will be correct and everything will work perfectly as it is the case for all other filesystems. The only overhead in this case comes from the need to handle UDF_INVALID_BMAP case (where data is embedded into file entry). So it means that we have to call bmap_internal to see if we have that special case and hanlde it, and if the case is not special we would call bread on a directory vnode which means that bmap_internal would be called again in udf_strategy. One optimization that can be done in this case is to create a ligher version of bmap_internal that would merely check for the special case and wouldn't do anything else. I am attaching a patch based on the ideas above. It fixes the problem for me and doesn't seem to create any new ones :-) About the patch: hunk #1 fixes a copy/paste hunk #2 should fixes strategy to not set junk b_blkno in case
Re: gettimeofday() in hping
On 04/02/2008, Alexander Leidinger [EMAIL PROTECTED] wrote: Ivan just change the page today. Feel free to suggest more specific things. Yes, I've added notes on syscall caching on Linux and socket buffer semantics. I've also linked to the page from Wikipedia article on FreeBSD - maybe it will help it to be noticed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fs/udf: vm pages overlap while reading large dir [patch]
Andriy Gapon wrote: More on the problem with reading big directories on UDF. You do realise that you have now made yourself the official maintainer of the UDF file system by submitting a competent and insightful analysis of the problem? First, some sleuthing. I came to believe that the problem is caused by some larger change in vfs/vm/buf area. It seems that now VMIO is applied to more vnode types than before. In particular it seems that now vnodes for devices have non-NULL v_object (or maybe this is about directory vnodes, I am not sure). Also it seems that the problem should happen for any directory with size larger than four 2048-bytes sectors (I think that any directory with 300 files would definitely qualify). After some code reading and run-time debugging, here are some facts about udf directory reading: 1. bread-ing is done via device vnode (as opposed to directory vnodes), as a consequence udf_strategy is not involved in directory reading 2. the device vnode has a non-NULL v_object, this means that VMIO is used 3. it seems that the code assumed that non-VM buffers are used 4. bread is done on as much data as possible, up to MAXBSIZE [and even slightly more in some cases] (i.e. code determines directory data size and attempts to read in everything in one go) 5. physical sector number adjusted to DEV_BSIZE (512 bytes) sectors is passed to bread - this is because of #1 above and peculiarities of buf system 6. directory reading and file reading are quite different, because the latter does reading via file vnode Let's a consider a simple case of directory reading 5 * PAGE_SIZE (4K) bytes starting from a physical sector N with N%2 = 0 from media with sector size of 2K (most common CD/DVD case): 1. we want to read 12 KB = 3 pages = 6 sectors starting from sector N, N%2 = 0 2. 4*N is passed as a sector number to bread 3. bo_bsize of the corresponding bufobj is a media sector size, i.e. 2K 4. actual read in bread will happen from b_iooffset of 4*N*DEV_BSIZE = N*2K, i.e. correct offset within the device 5. for a fresh read getblk will be called 6. getblk will set b_offset to blkno*bo_bsize=4*N*2K, i.e. 4 times the correct byte offset within the device 7. allocbuf will allocate pages using B_VMIO case 8. allocbuf calculates base page index as follows: pi = b_offset/PAGE_SIZE this means the following: sectors N and N+1 will be bound to a page with index 4*N*2K/4K = 2*N sectors N+2 and N+3 will be bound to the next page 2*N +1 sectors N+4 and N+5 is tied to the next page 2*N + 2 Now let's consider a directory read of 2 sectors (1 page) starting at physical sector N+1. Using the same calculations as above, we see that the sector will be tied to a page 2*(N+1) = 2*N + 2. And this page already contains valid cached data from the previous read, *but* it contains data from sectors N+4 and N+5 instead of N+1 and N+2. So, we see, that because of b_offset being 4 times the actual byte offset, we get incorrect page indexing. Namely, sector X gets associated with different pages depending on what sector is used as a starting sector for bread. If bread starts at sector N, then data of sector N+1 is associated with (second half of) page with index 2*N; but if bread starts at sector N+1 then it gets associated with (the first half of) page with index 2*(N+1). Previously, before VMIO change, data for all reads was put into separate buffers that did not share anything between them. So the problem was limited only to wasting memory with duplicate data, but no actual over-runs did happen. Now we have the over-runs because the VM pages are shared between the buffers of the same vnode. One obvious solution is to limit bread size to 2*PAGE_SIZE = 4 * sector_size. In this case, as before, we would waste some memory on duplicate data but we would avoid page overruns. If we limit bread size even more, to 1 sector, then we would not have any duplicate data at all. But there would still be some resource waste - each page would correspond to one sector, so 4K page would have only 2K of valid data and the other half in each page is unused. Another solution, which to me seems to be better, is to do usual reading - pass a directory vnode and 2048-byte sector offset to bread. In this case udf_strategy will get called for bklno translation, all offsets and indexes will be correct and everything will work perfectly as it is the case for all other filesystems. The only overhead in this case comes from the need to handle UDF_INVALID_BMAP case (where data is embedded into file entry). So it means that we have to call bmap_internal to see if we have that special case and hanlde it, and if the case is not special we would call bread on a directory vnode which means that bmap_internal would be called again in udf_strategy. One optimization that can be done in this case is to create a ligher version of bmap_internal that would merely check for the special case and wouldn't do anything else. I am attaching a patch based on the ideas
Re: Synaptics
Cristian, good day. Wed, Jan 23, 2008 at 01:26:41PM +0200, [EMAIL PROTECTED] wrote: I just ran into the same problem. In xorg.conf I explicitly told the synaptics driver to use psm and /dev/psm0, but the error message would suggest that it uses event. Also, I tried to change the source code of the synaptics driver (synaptics.c) and hard-coded psm as the only driver, no matter what xorg.conf says. Synaptics still would not start, but this time complaining that no device was specified. Please note that I had Device in my xorg.conf, but the error suggests that the driver ignored it. Suppose I use the attached xorg.conf file, at some point, /var/log/Xorg.0.log shows the following error: (II) Synaptics touchpad driver version 0.14.6 (1406) Synaptics_Touchpad no synaptics event device found (checked 10 nodes) Synaptics_Touchpad The /dev/input/event* device nodes seem to be missing (EE) xf86OpenSerial: No Device specified. Synaptics driver unable to open device (EE) PreInit failed for input device Synaptics_Touchpad (II) UnloadModule: synaptics As you said, it looks like synaptics is trying to use the auto protocol, although the configuration file tells it to use psm. Now, if I put the attached patch in x11-drivers/synaptics/files, using the same xorg.conf, synaptics will fail like this: (II) Synaptics touchpad driver version 0.14.6 (1406) (EE) xf86OpenSerial: No Device specified. Synaptics driver unable to open device (EE) PreInit failed for input device Synaptics_Touchpad (II) UnloadModule: synaptics It almost looks as if I have to hardcode the device too, because synaptics certainly ignores my options. This is a sort of 'ping' mail, sorry. To the point: I had reproduced the problem and will start looking into it once this message will fly from my mailserver. Stay tuned ;)) -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/dsp disappeared after power outage
On Saturday 02 February 2008 06:40:15 pm Aryeh M. Friedman wrote: I just had a power outage and when it came back /dev/dsp0.0 was missing from the devices. the kern module loaded fine and detected the card correctly (according to dmesg, sysctl and /dev/sndstat) but neither the above or /dev/pcm exists. After rebooting the problem remains. Any ideas how to fix it? Nothing to fix. This is how devfs device cloning works. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Greetings, Ivan Voras wrote: On 04/02/2008, Stefan Lambrev [EMAIL PROTECTED] wrote: Kris if you do not mind I'll write to hping developers to adopt this patch, and if no response from them I can try to reach the port maintainer, so we have this patched in ports? As we're in a the whole world is a Linux situation, would it be helpful to open a page on our wiki to enumerate differences like this, that would help people write and port applications to FreeBSD? I know the sort of advice given by Kris should be obvious to professional developers, but history shows that it is not and that people rather read blogs than manuals. That's the reason I started to dislike Linux last few years - because it's defacto standart in open source/unix like OS world, and their dev team act very much like MS dev team :( In the wiki there is a page about how to avoid linuxism. I think we have to mention this there. It was the first place where I looked how to speed up hping. I think the info about gettimeofday (and replacements) and the ENOBUFS situation have to be explained little more there. I do not expect developers, that write programs for linux to read the FreeBSD wiki, but it will help people like me - not very experienced in coding, to produce patches/ports without bothering too much advanced developers :) It will be good if there are some examples too. -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/dsp disappeared after power outage
On Feb 4, 2008, at 08:03 , John Baldwin wrote: On Saturday 02 February 2008 06:40:15 pm Aryeh M. Friedman wrote: I just had a power outage and when it came back /dev/dsp0.0 was missing from the devices. the kern module loaded fine and detected the card correctly (according to dmesg, sysctl and /dev/sndstat) but neither the above or /dev/pcm exists. After rebooting the problem remains. Any ideas how to fix it? Nothing to fix. This is how devfs device cloning works. -- John Baldwin Nothing to fix? The sound card that is correctly detected by the kernel module is not being created in /dev, ONLY after he had a power outage. It is not even coming back when he reboots the machine. I don't have any suggestions, I just don't believe Nothing to fix is the right answer. Bert JW Regeer
Re: sort(1) memory usage
David Schultz [EMAIL PROTECTED] writes: We had been using a BSD-licensed sort(1), but ache@ changed it back to GNU sort several years ago. Anyone know why? If I had to guess I'd say i18n [...] That is my recollection as well. We would do well to take a look at the code (and CVS logs) from NetBSD; they may have solved the i18n issues by now. There may also be a few missing features: someone mentioned -g, which is apparently similar to yet somehow different from -n, in weird and wonderful ways which the authors did not bother documenting. Last I checked, it also (rather surprisingly) lacked -u (unique), which is required by POSIX. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sort(1) memory usage
On Sun, Feb 03, 2008, Dag-Erling Smørgrav wrote:
Dag-Erling Smørgrav [EMAIL PROTECTED] writes:
Erik Trulsson [EMAIL PROTECTED] writes:
Yep, it seems that GNU sort allocates a quite large buffer by default when
the size of the input is unknown (such as when it reads input from stdin.)
A quick check in the source code indicates that it tries to size this
buffer
according to how much memory the system has (and according to any limits
set
on how much memory the process is allowed to use.)
Uh, OK. This scaling doesn't seem to work correctly. It seems to
allocate 27 MB on 32-bit machines and 54 MB on 64-bit machines,
regardless of memory size.
Looking at the code, it seems to go to extreme lengths to get it
absolutely wrong. For instance, if hw.physmem / 8 hw.usermem, it will
pick the former, which means it's pretty much guaranteed to either fail
or hose your system (or both).
In the immortal words of Blazing Star: YOU FAIL IT
Count this as a vote for ditching GNU sort in favor of a BSD-licensed
implementation (from {Net,Open}BSD for instance).
We had been using a BSD-licensed sort(1), but ache@ changed it
back to GNU sort several years ago. Anyone know why? If I had to
guess I'd say i18n, but that's not very hard to deal with these
days given strcoll(3).
That said, I'm unaware of any technical differences between the two.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fs/udf: vm pages overlap while reading large dir [patch]
Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800: Andriy Gapon wrote: More on the problem with reading big directories on UDF. You do realise that you have now made yourself the official maintainer of the UDF file system by submitting a competent and insightful analysis of the problem? Yay, and can you fix the sequential read performance while you're at it? Kthx! -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Squish. Larger than the normal icky things, and twice as icky. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE trouble after ugrade 6.2-RELEASE - 6.3-RELEASE
Xin LI wrote: I can not speak for that, but my understanding is, no, it won't be MFC'ed. The performance enhancements on 7.x included a lot of factors, ULE is one of them, and there are also some other enhancements in the system, which could be not suitable for MFC due to ABI/KBI change. Yes, there is no possibility of ULE 2.0 being merged to 6.x. Use it in 6.x if you dare, just don't complain to us if it breaks your system :-) i.e. if at any point you start experiencing problems, do not report them until you have verified that they persist with 4BSD also. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
Stefan Lambrev wrote: FreeBSD - ACPI em1 in 13.157 MB/s 13.162 MB/s 23.697 GB out13.150 MB/s 13.153 MB/s 17.976 GB FreeBSD - TSC em1 in 18.624 MB/s 18.832 MB/s 25.507 GB out17.008 MB/s 17.041 MB/s 19.681 GB FreeBSD - i8254 em1 in 6.763 MB/s 6.763 MB/s 26.005 GB out 6.756 MB/s 6.758 MB/s 20.151 GB FreeBSD - dummy em1 in 18.705 MB/s 18.796 MB/s 27.014 GB out17.217 MB/s 17.225 MB/s 21.082 GB I forgot to mention I was using -a to spoof the return address so time is not wasted receiving packets (since your goal was to syn flood the server). Probably there are other (possibly also bogus) gettimeofday calls that are still present in hping when receiving packets. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE trouble after ugrade 6.2-RELEASE - 6.3-RELEASE
Quoting Kris Kennaway [EMAIL PROTECTED]: Yes, there is no possibility of ULE 2.0 being merged to 6.x. Use it in 6.x if you dare, just don't complain to us if it breaks your system :-) All right, I won't :-) i.e. if at any point you start experiencing problems, do not report them until you have verified that they persist with 4BSD also. I can hear you. Then again, I'm in the slow process of converting people in my office to use FreeBSD instead of GNU/Linux: it's not going to be easy if 6.3 4BSD exhibits slownesses when compiling a kernel, and 6.3 ULE might prove not that stable :-\ (I've not encountered any problem until now, though, and I'm touching wood as my granny says) By the way, why still include ULE in 6.x if it is to be avoided ? gregory ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE trouble after ugrade 6.2-RELEASE - 6.3-RELEASE
Quoting Xin LI [EMAIL PROTECTED]: Do NOT use ULE on 6.x. ULE has been revamped heavily on 7.0 and the version on 6.x is old, and is known to contain some bugs. Is it particular to 6.x *SMP* systems ? I've been using 6.3-R with ULE for about a fortnight without any trouble (on a pentium4-m UP). I was drivent to switch to ULE because I suffered awful slow-downs, mouse jerkiness and all: when compiling kernel or a port, for instance, mouse would not respond with fluidity in firefox, switching tabs would take many seconds, and watching TV with vlc showed many cut-offs and fixed pictures (not related to network traffic or bandwidth limitations). The transition to ULE made them disappear (still occasional mouse jerkiness though). I suppose the enhancements/corrections of 7.x ULE won't be MFC'd ? gregory delfly ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/dsp disappeared after power outage
On Mon, 04.02.2008 at 13:00:40 -0700, Bert JW Regeer wrote: On Feb 4, 2008, at 08:03 , John Baldwin wrote: On Saturday 02 February 2008 06:40:15 pm Aryeh M. Friedman wrote: I just had a power outage and when it came back /dev/dsp0.0 was missing from the devices. the kern module loaded fine and detected the card correctly (according to dmesg, sysctl and /dev/sndstat) but neither the above or /dev/pcm exists. After rebooting the problem remains. Any ideas how to fix it? Nothing to fix. This is how devfs device cloning works. Nothing to fix? The sound card that is correctly detected by the kernel module is not being created in /dev, ONLY after he had a power outage. It is not even coming back when he reboots the machine. I don't have any suggestions, I just don't believe Nothing to fix is the right answer. Sigh, AFAIK dev cloning works by creating the device nodes when open()ed. Using 'ls /dev/dsp*' will not open() any devices, so nothing is created. He should use 'ls /dev/dsp0 /dev/dsp0.0' and then the devices should appear. Try it for yourself, do 'ls /dev/dsp*' then 'ls /dev/dsp.8' Not that anything usefull can be done with ls(1) to get sound :) Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_ULE trouble after ugrade 6.2-RELEASE - 6.3-RELEASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Quoting Xin LI [EMAIL PROTECTED]: Do NOT use ULE on 6.x. ULE has been revamped heavily on 7.0 and the version on 6.x is old, and is known to contain some bugs. Is it particular to 6.x *SMP* systems ? Particular to *all* 6.x systems at the moment, possibly. I've been using 6.3-R with ULE for about a fortnight without any trouble (on a pentium4-m UP). I was drivent to switch to ULE because I suffered awful slow-downs, mouse jerkiness and all: when compiling kernel or a port, for instance, mouse would not respond with fluidity in firefox, switching tabs would take many seconds, and watching TV with vlc showed many cut-offs and fixed pictures (not related to network traffic or bandwidth limitations). The transition to ULE made them disappear (still occasional mouse jerkiness though). I suppose the enhancements/corrections of 7.x ULE won't be MFC'd ? I can not speak for that, but my understanding is, no, it won't be MFC'ed. The performance enhancements on 7.x included a lot of factors, ULE is one of them, and there are also some other enhancements in the system, which could be not suitable for MFC due to ABI/KBI change. Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHp3Osi+vbBBjt66ARAud3AKCyFlIGeLTD5US/wbzWP6dwJclPZwCfRLF2 TyTZ5a+OHVX6zHEXKm+Oj0A= =F1PJ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/dsp disappeared after power outage
On Feb 4, 2008, at 14:52 , Ulrich Spoerlein wrote: On Mon, 04.02.2008 at 13:00:40 -0700, Bert JW Regeer wrote: On Feb 4, 2008, at 08:03 , John Baldwin wrote: On Saturday 02 February 2008 06:40:15 pm Aryeh M. Friedman wrote: I just had a power outage and when it came back /dev/dsp0.0 was missing from the devices. the kern module loaded fine and detected the card correctly (according to dmesg, sysctl and /dev/sndstat) but neither the above or /dev/pcm exists. After rebooting the problem remains. Any ideas how to fix it? Nothing to fix. This is how devfs device cloning works. Nothing to fix? The sound card that is correctly detected by the kernel module is not being created in /dev, ONLY after he had a power outage. It is not even coming back when he reboots the machine. I don't have any suggestions, I just don't believe Nothing to fix is the right answer. Sigh, AFAIK dev cloning works by creating the device nodes when open()ed. Using 'ls /dev/dsp*' will not open() any devices, so nothing is created. He should use 'ls /dev/dsp0 /dev/dsp0.0' and then the devices should appear. Try it for yourself, do 'ls /dev/dsp*' then 'ls /dev/dsp.8' Not that anything usefull can be done with ls(1) to get sound :) Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. I just booted up my desktop machine at home, I don't have sound enabled by default, so I loaded the module that is required. Before the module was loaded: ls -lah /dev/dsp* ls: No match. After the module was loaded (I just load snd_driver). Nothing else was executed after the module was loaded. ls -lah /dev/dsp* crw-rw-rw- 1 root wheel0, 106 Jan 26 05:24 /dev/dsp0.0 crw-rw-rw- 1 root wheel0, 109 Jan 26 05:24 /dev/dsp0.1 crw-rw-rw- 1 root wheel0, 112 Jan 26 05:24 /dev/dsp0.2 crw-rw-rw- 1 root wheel0, 115 Jan 26 05:24 /dev/dsp0.3 crw-rw-rw- 1 root wheel0, 118 Jan 26 05:24 /dev/dsp0.4 crw-rw-rw- 1 root wheel0, 122 Jan 26 05:24 /dev/dsp0.5 crw-rw-rw- 1 root wheel0, 107 Jan 26 05:24 /dev/dspW0.0 crw-rw-rw- 1 root wheel0, 110 Jan 26 05:24 /dev/dspW0.1 crw-rw-rw- 1 root wheel0, 113 Jan 26 05:24 /dev/dspW0.2 crw-rw-rw- 1 root wheel0, 116 Jan 26 05:24 /dev/dspW0.3 crw-rw-rw- 1 root wheel0, 119 Jan 26 05:24 /dev/dspW0.4 crw-rw-rw- 1 root wheel0, 123 Jan 26 05:24 /dev/dspW0.5 crw-rw-rw- 1 root wheel0, 121 Jan 26 05:24 /dev/dspr0.4 So what gives? Bert JW Regeer
Re: SCHED_ULE trouble after ugrade 6.2-RELEASE - 6.3-RELEASE
[EMAIL PROTECTED] wrote: Quoting Kris Kennaway [EMAIL PROTECTED]: Yes, there is no possibility of ULE 2.0 being merged to 6.x. Use it in 6.x if you dare, just don't complain to us if it breaks your system :-) All right, I won't :-) i.e. if at any point you start experiencing problems, do not report them until you have verified that they persist with 4BSD also. I can hear you. Then again, I'm in the slow process of converting people in my office to use FreeBSD instead of GNU/Linux: it's not going to be easy if 6.3 4BSD exhibits slownesses when compiling a kernel, and 6.3 ULE might prove not that stable :-\ (I've not encountered any problem until now, though, and I'm touching wood as my granny says) By the way, why still include ULE in 6.x if it is to be avoided ? Typically we don't remove even experimental (even broken) code in stable branches in case it is still useful to someone despite the problems. Try 7.0 instead. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
