Re: 8.0RC2 top statistics seem broken
On Thu, Nov 12, 2009 at 08:42:28AM -0800, Matthew Fleming wrote:
[snip]
Load average and %CPU user are right, as are other global
statistics.
The load is produced by the 7z process (archivers/p7zip) which
compresses some data in two threads but is credited with 0% CPU,
though
its runtime is correct (increments every second as it should in a
CPU-bound process). It doesn't help if I expand / show individual
threads.
I believe this is related to multithreaded processes only. I saw this
for
intr kernel process. Singlethread processes eat CPU slightly less than
on 7.2, however, I can not say is it statistic errors or real speedup.
I saw the issue on SMP/ULE only and can not say anything about UP and
4BSD scheduler.
Check out r197652 on stable/7. I had a similar problem where top was
showing 0% for a CPU hog, but since I was unable to replicate it on
CURRENT (and the ULE accounting code is different between releases) I
only submitted for stable/7. I think the patch will be easy to apply by
hand, though, to test it.
Thank you very much. I have applied your patch and it fixes the bug:
CPU 0: 22.0% user, 0.0% nice, 4.9% system, 0.0% interrupt, 73.2% idle
CPU 1: 1.2% user, 0.0% nice, 1.2% system, 4.9% interrupt, 92.7% idle
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root 2 171 ki31 0K32K CPU00 12:11 165.77% idle
1338 nobody 1 44 -10 439M 433M kqread 0 0:24 14.45% nginx
1339 nobody 1 44 -10 439M 433M kqread 0 0:23 12.89% nginx
12 root 15 -60- 0K 240K WAIT0 0:09 4.39% intr
CPU 0: 16.2% user, 0.0% nice, 8.5% system, 0.8% interrupt, 74.5% idle
CPU 1: 1.2% user, 0.0% nice, 1.9% system, 4.2% interrupt, 92.7% idle
PID USERNAMEPRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root171 ki31 0K32K RUN 1 6:39 88.96% {idle: cpu1}
11 root171 ki31 0K32K RUN 0 6:11 77.59% {idle: cpu0}
1338 nobody 44 -10 439M 433M CPU00 0:27 14.45% nginx
1339 nobody 44 -10 439M 433M RUN 1 0:26 14.26% nginx
12 root-68- 0K 240K WAIT1 0:09 4.69% {irq19: bge0}
The patch against 8.0-PREREALSE is attached.
--
Igor Sysoev
http://sysoev.ru/en/
--- sys/kern/sched_ule.c2009-11-02 09:25:28.0 +0300
+++ sys/kern/sched_ule.c2009-11-12 21:53:45.0 +0300
@@ -103,6 +103,7 @@
u_int ts_slptime; /* Number of ticks we vol. slept */
u_int ts_runtime; /* Number of ticks we were running */
int ts_ltick; /* Last tick that we were running on */
+ int ts_incrtick;/* Last tick that we incremented on */
int ts_ftick; /* First tick that we were running on */
int ts_ticks; /* Tick count */
#ifdef KTR
@@ -1991,6 +1992,7 @@
*/
ts2-ts_ticks = ts-ts_ticks;
ts2-ts_ltick = ts-ts_ltick;
+ ts2-ts_incrtick = ts-ts_incrtick;
ts2-ts_ftick = ts-ts_ftick;
child-td_user_pri = td-td_user_pri;
child-td_base_user_pri = td-td_base_user_pri;
@@ -2182,11 +2184,12 @@
* Ticks is updated asynchronously on a single cpu. Check here to
* avoid incrementing ts_ticks multiple times in a single tick.
*/
- if (ts-ts_ltick == ticks)
+ if (ts-ts_incrtick == ticks)
return;
/* Adjust ticks for pctcpu */
ts-ts_ticks += 1 SCHED_TICK_SHIFT;
ts-ts_ltick = ticks;
+ ts-ts_incrtick = ticks;
/*
* Update if we've exceeded our desired tick threshhold by over one
* second.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.0RC2 top statistics seem broken
On Tue, Nov 10, 2009 at 04:29:37PM +0100, Ivan Voras wrote: Here is what I'm seeing now: last pid: 70893; load averages: 1.70, 1.10, 0.58 up 27+02:59:26 16:23:59 134 processes: 3 running, 131 sleeping CPU: 94.8% user, 0.0% nice, 4.6% system, 0.6% interrupt, 0.0% idle Mem: 309M Active, 48M Inact, 113M Wired, 17M Cache, 60M Buf, 3624K Free Swap: 640M Total, 205M Used, 435M Free, 32% Inuse PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 751 pgsql 1 450 159M 556K select 1 249:38 0.00% postgres 756 pgsql 1 440 25004K 600K select 1 86:31 0.00% postgres 754 pgsql 1 440 159M 1040K select 1 13:02 0.00% postgres 753 pgsql 1 440 159M 7868K select 1 10:55 0.00% postgres 597 root1 440 3184K 464K select 0 4:49 0.00% syslogd 755 pgsql 1 440 159M 1432K select 1 4:46 0.00% postgres 659 root1 440 62156K 1356K select 1 4:30 0.00% vmware-guestd 765 nobody 1 40 3236K 192K kqread 1 3:25 0.00% memcached 775 root1 440 9996K 340K select 1 2:18 0.00% httpd 900 sveb1 50 9452K 0K select 0 1:49 0.00% sshd 790 www 1 440 9768K 224K select 1 1:47 0.00% httpd 70851 ivoras 3 960 199M 195M CPU0 0 1:47 0.00% 7z Load average and %CPU user are right, as are other global statistics. The load is produced by the 7z process (archivers/p7zip) which compresses some data in two threads but is credited with 0% CPU, though its runtime is correct (increments every second as it should in a CPU-bound process). It doesn't help if I expand / show individual threads. I believe this is related to multithreaded processes only. I saw this for intr kernel process. Singlethread processes eat CPU slightly less than on 7.2, however, I can not say is it statistic errors or real speedup. I saw the issue on SMP/ULE only and can not say anything about UP and 4BSD scheduler. -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: interrupt threads CPU usage in FreeBSD 8.0
On Tue, Nov 03, 2009 at 05:36:55PM +0100, Attilio Rao wrote:
2009/10/21 Igor Sysoev i...@rambler-co.ru:
Hi,
for some reason in 8.0 top always shows 0% CPU usage for intr kernel
process and active interrupt thread, irq19 bge0 in my case.
8-0 RC1 top -PS:
CPU 0: 27.8% user, 0.0% nice, 7.1% system, 0.0% interrupt, 65.0% idle
CPU 1: 3.0% user, 0.0% nice, 2.3% system, 7.1% interrupt, 87.6% idle
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root 2 171 ki31 0K32K RUN 0 140.7H 152.54% idle
61371 nobody 1 69 -10 384M 289M kqread 0 105:56 17.77% nginx
61372 nobody 1 67 -10 384M 293M CPU00 106:15 16.99% nginx
12 root 15 -60- 0K 240K WAIT0 54:50 0.00% intr
8.0 RC1 top -PSH:
PID USERNAMEPRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root171 ki31 0K32K RUN 1 71.5H 81.05% {idle: cpu1}
11 root171 ki31 0K32K CPU00 69.3H 69.19% {idle: cpu0}
61372 nobody 68 -10 384M 294M kqread 0 107:06 18.99% nginx
61371 nobody 68 -10 384M 291M kqread 0 106:45 16.99% nginx
12 root-68- 0K 240K WAIT1 50:48 0.00% {irq19:
bge0}
17 root 44- 0K16K syncer 1 5:23 0.00% syncer
12 root-32- 0K 240K WAIT1 3:06 0.00% {swi4:
clock}
7.2-STABLE top -PS:
CPU 0: 9.0% user, 0.0% nice, 7.9% system, 9.0% interrupt, 74.1% idle
CPU 1: 23.3% user, 0.0% nice, 8.3% system, 0.0% interrupt, 68.4% idle
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
12 root1 171 ki31 0K16K RUN 0 275.0H 83.59% idle: cpu0
11 root1 171 ki31 0K16K RUN 1 264.2H 76.27% idle: cpu1
16109 nobody 1 68 -10 376M 307M CPU01 28:05 21.97% nginx
16110 nobody 1 4 -10 376M 316M RUN 0 28:05 20.17% nginx
26 root1 -68- 0K16K WAIT0 902:39 6.69% irq19:
bge0
How old is your 7.2-STABLE?
I saw this on 7.0-7.2. One of 7.2-S is, for example, from 2009.10.04.23.59.59.
I believe I saw the same CPU usage on FreeBSD-6 too.
--
Igor Sysoev
http://sysoev.ru/en/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
interrupt threads CPU usage in FreeBSD 8.0
Hi,
for some reason in 8.0 top always shows 0% CPU usage for intr kernel
process and active interrupt thread, irq19 bge0 in my case.
8-0 RC1 top -PS:
CPU 0: 27.8% user, 0.0% nice, 7.1% system, 0.0% interrupt, 65.0% idle
CPU 1: 3.0% user, 0.0% nice, 2.3% system, 7.1% interrupt, 87.6% idle
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root 2 171 ki31 0K32K RUN 0 140.7H 152.54% idle
61371 nobody 1 69 -10 384M 289M kqread 0 105:56 17.77% nginx
61372 nobody 1 67 -10 384M 293M CPU00 106:15 16.99% nginx
12 root 15 -60- 0K 240K WAIT0 54:50 0.00% intr
8.0 RC1 top -PSH:
PID USERNAMEPRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root171 ki31 0K32K RUN 1 71.5H 81.05% {idle: cpu1}
11 root171 ki31 0K32K CPU00 69.3H 69.19% {idle: cpu0}
61372 nobody 68 -10 384M 294M kqread 0 107:06 18.99% nginx
61371 nobody 68 -10 384M 291M kqread 0 106:45 16.99% nginx
12 root-68- 0K 240K WAIT1 50:48 0.00% {irq19: bge0}
17 root 44- 0K16K syncer 1 5:23 0.00% syncer
12 root-32- 0K 240K WAIT1 3:06 0.00% {swi4: clock}
7.2-STABLE top -PS:
CPU 0: 9.0% user, 0.0% nice, 7.9% system, 9.0% interrupt, 74.1% idle
CPU 1: 23.3% user, 0.0% nice, 8.3% system, 0.0% interrupt, 68.4% idle
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
12 root1 171 ki31 0K16K RUN 0 275.0H 83.59% idle: cpu0
11 root1 171 ki31 0K16K RUN 1 264.2H 76.27% idle: cpu1
16109 nobody 1 68 -10 376M 307M CPU01 28:05 21.97% nginx
16110 nobody 1 4 -10 376M 316M RUN 0 28:05 20.17% nginx
26 root1 -68- 0K16K WAIT0 902:39 6.69% irq19: bge0
--
Igor Sysoev
http://sysoev.ru/en/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
7.1-STABLE does not boot after recent superpage support MFC
Is anyone able to boot kernel with recently merged superpage support ? I have csup'd world to *default date=2009.02.26.23.59.59 then rebuild world and kernel does not boot: FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009 X kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0x803b1d80 stack pointer = 0x10:0x80686ce0 frame pointer = 0x10:0x80686d00 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 0 () trap number = 12 panic: page fault cpuid = 0 And the message is cycled. The kernel does not boot despite vm.pmap.pg_ps_enabled value. -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
vfs.ffs.rawreadahead
Hi, could anyone tell what does vfs.ffs.rawreadahead enable ? As I understand it's used in DIRECTIO code that allows read data directly to an userland buffer bypassing the buffer cache. What I can not understand where the read ahead data can be placed in ? -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.ffs.rawreadahead
On Wed, Sep 03, 2008 at 04:03:59PM +0530, Sujit Karataparambil wrote: The VFS was designed to be Object abtraction of the Berkeley Fast File System. This has been since an terminology with journalling filesystem to have functionality to added on request. In src/sys/ufs/ffs/ffs_rawread.c I see that rawreadahead is used. However, I do not understand whether rawreadahead starts a second parallel ahead disk transaction with supplied userland buffer or not. -- Igor Sysoev http://sysoev.ru/en/ On 9/3/08, Igor Sysoev [EMAIL PROTECTED] wrote: Hi, could anyone tell what does vfs.ffs.rawreadahead enable ? As I understand it's used in DIRECTIO code that allows read data directly to an userland buffer bypassing the buffer cache. What I can not understand where the read ahead data can be placed in ? -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.ffs.rawreadahead
On Wed, Sep 03, 2008 at 05:03:21PM +0530, Sujit Karataparambil wrote: These are Journalling File System. Some thing like WAPBL which stands for Write-Ahead Physical Block Logging. These are built on Generic kernel components. vfs.ffs.rawreadahead as it may be seen from its name is read-ahead capability, but not write-ahead. And there is no any write-ahead related sysctl: #sysctl -a|grep ahead vfs.ffs.rawreadahead: 1 # On 9/3/08, Igor Sysoev [EMAIL PROTECTED] wrote: On Wed, Sep 03, 2008 at 04:03:59PM +0530, Sujit Karataparambil wrote: The VFS was designed to be Object abtraction of the Berkeley Fast File System. This has been since an terminology with journalling filesystem to have functionality to added on request. In src/sys/ufs/ffs/ffs_rawread.c I see that rawreadahead is used. However, I do not understand whether rawreadahead starts a second parallel ahead disk transaction with supplied userland buffer or not. -- Igor Sysoev http://sysoev.ru/en/ On 9/3/08, Igor Sysoev [EMAIL PROTECTED] wrote: Hi, could anyone tell what does vfs.ffs.rawreadahead enable ? As I understand it's used in DIRECTIO code that allows read data directly to an userland buffer bypassing the buffer cache. What I can not understand where the read ahead data can be placed in ? -- Igor Sysoev http://sysoev.ru/en/ -- --linux(2.4/2.6),bsd(4.5.x+),solaris(2.5+) -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.ffs.rawreadahead
On Wed, Sep 03, 2008 at 03:39:55PM +0300, Kostik Belousov wrote: On Wed, Sep 03, 2008 at 01:53:52PM +0400, Igor Sysoev wrote: Hi, could anyone tell what does vfs.ffs.rawreadahead enable ? As I understand it's used in DIRECTIO code that allows read data directly to an userland buffer bypassing the buffer cache. What I can not understand where the read ahead data can be placed in ? The operation of the ffs_rawread is more accurately described as bypassing the page cache. It creates the physical buffer that maps the user pages. The readahead is performed only when the supplied user memory region is bigger then blocksize. In this case, two reads are performed simultaneously, with both buffers mapping consequent blocks from user-supplied buffers. The read operation looks like footsteps. Nice! As I understand the size limit of one read operation is MAXPHYS, which is equal to 128K due to LBA28 ATA limit. On SCSI, SATA, and LBA48 ATA this limit can be increased. Is it safe ? -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vfs.ffs.rawreadahead
On Wed, Sep 03, 2008 at 10:44:46AM -0600, Scott Long wrote: On Wed, 3 Sep 2008, Igor Sysoev wrote: On Wed, Sep 03, 2008 at 03:39:55PM +0300, Kostik Belousov wrote: On Wed, Sep 03, 2008 at 01:53:52PM +0400, Igor Sysoev wrote: Hi, could anyone tell what does vfs.ffs.rawreadahead enable ? As I understand it's used in DIRECTIO code that allows read data directly to an userland buffer bypassing the buffer cache. What I can not understand where the read ahead data can be placed in ? The operation of the ffs_rawread is more accurately described as bypassing the page cache. It creates the physical buffer that maps the user pages. The readahead is performed only when the supplied user memory region is bigger then blocksize. In this case, two reads are performed simultaneously, with both buffers mapping consequent blocks from user-supplied buffers. The read operation looks like footsteps. Nice! As I understand the size limit of one read operation is MAXPHYS, which is equal to 128K due to LBA28 ATA limit. On SCSI, SATA, and LBA48 ATA this limit can be increased. Is it safe ? The value of MAXPHYS is unrelated to capabilities or limitations of ATA. It was chosen based on the needs to prevent an excessive amount of parallel I/O from exhausting the kernel address space and system memory. In fact, the concern was with SCSI, not with ATA. MAXPHYS can be raised, especially on 64bit platforms, but doing so also bloats the sizes of a few key data structures. I've been looking at a solution for this, and I'd rather that people keep their MAXPHYS changes confined to their local trees rather than changing FreeBSD unless they also solve the associated side effects. As I understand MAXPHYS affects at least on pager_map size: on modern machines it's usually 256 * MAXPHYS = 32M, therefore increasing MAXPHYS will increase the map too. The 128K is probably good value and I do not suggest to increase it by default, I just want to increase MAXPHYS to improve disk throughput on some hosts where nginx serves large files (1G+) using DIRECTIO. BTW, is it possible to change MAXPHYS to a loader tunnable ? -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver 6.6.6 regression
On Wed, Nov 07, 2007 at 12:55:24PM +0300, Igor Sysoev wrote: On Wed, Nov 07, 2007 at 12:18:06PM +0300, Igor Sysoev wrote: On Fri, Oct 12, 2007 at 04:15:46PM +0400, Igor Sysoev wrote: Yesterday I have cvsup'ed FreeBSD on ThinkPad T42 to RELENG_6 2007.10.10.23.59.59 and have noticed lags while playing mp3 and browsing. I have suspected new em driver, because there was no lags if wifi iwi0 was used instead of em0 for network. So I had downgraded the em driver separately to 6.2.9 version, have build a kernel loadable module, and have loaded it instead of the 6.6.6 module, and the lags have disappeared. The lags appeares only if browser (Firefox, Opera) does several requests: main page, js, images. There are no lags if browser reload simple page. Also, I could not reproduce lags by other network traffic: pings, ssh, scp, downloading files. There are no lags if I compile and so on. Some additional info: The shared irq11 is used by pcm0, em0, iwi0, CardBus, USB, and acpi_video0. [EMAIL PROTECTED]:1:0: class=0x02 card=0x05491014 chip=0x101e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82540EP Gigabit Ethernet Controller (Mobile)' I just cvsup'ed to the new em 6.7.2 version without FAST interrupt and lags in sound and USB mouse has gone. Thank you. However, if I define EM_FAST_IRQ, then lags appear again. I've just rebuild RELENG_6 with EM_FAST_IRQ enabled and with Scott Long's fix 1.14.2.5 of src/sys/i386/i386/intr_machdep.c and all run without lags. Thank you. em0: Intel(R) PRO/1000 Network Connection Version - 6.7.2 port 0x8000-0x803f mem 0xc022-0xc023,0xc020-0xc020 irq 11 at device 1.0 on pci2 em0: [FAST] -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver 6.6.6 regression
On Fri, Oct 12, 2007 at 04:15:46PM +0400, Igor Sysoev wrote: Yesterday I have cvsup'ed FreeBSD on ThinkPad T42 to RELENG_6 2007.10.10.23.59.59 and have noticed lags while playing mp3 and browsing. I have suspected new em driver, because there was no lags if wifi iwi0 was used instead of em0 for network. So I had downgraded the em driver separately to 6.2.9 version, have build a kernel loadable module, and have loaded it instead of the 6.6.6 module, and the lags have disappeared. The lags appeares only if browser (Firefox, Opera) does several requests: main page, js, images. There are no lags if browser reload simple page. Also, I could not reproduce lags by other network traffic: pings, ssh, scp, downloading files. There are no lags if I compile and so on. Some additional info: The shared irq11 is used by pcm0, em0, iwi0, CardBus, USB, and acpi_video0. [EMAIL PROTECTED]:1:0: class=0x02 card=0x05491014 chip=0x101e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82540EP Gigabit Ethernet Controller (Mobile)' I just cvsup'ed to the new em 6.7.2 version without FAST interrupt and lags in sound and USB mouse has gone. Thank you. -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver 6.6.6 regression
On Wed, Nov 07, 2007 at 12:18:06PM +0300, Igor Sysoev wrote: On Fri, Oct 12, 2007 at 04:15:46PM +0400, Igor Sysoev wrote: Yesterday I have cvsup'ed FreeBSD on ThinkPad T42 to RELENG_6 2007.10.10.23.59.59 and have noticed lags while playing mp3 and browsing. I have suspected new em driver, because there was no lags if wifi iwi0 was used instead of em0 for network. So I had downgraded the em driver separately to 6.2.9 version, have build a kernel loadable module, and have loaded it instead of the 6.6.6 module, and the lags have disappeared. The lags appeares only if browser (Firefox, Opera) does several requests: main page, js, images. There are no lags if browser reload simple page. Also, I could not reproduce lags by other network traffic: pings, ssh, scp, downloading files. There are no lags if I compile and so on. Some additional info: The shared irq11 is used by pcm0, em0, iwi0, CardBus, USB, and acpi_video0. [EMAIL PROTECTED]:1:0: class=0x02 card=0x05491014 chip=0x101e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82540EP Gigabit Ethernet Controller (Mobile)' I just cvsup'ed to the new em 6.7.2 version without FAST interrupt and lags in sound and USB mouse has gone. Thank you. However, if I define EM_FAST_IRQ, then lags appear again. -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2G+ sysv shm segments
On Wed, Oct 17, 2007 at 05:38:43AM +1000, Peter Jeremy wrote:
On 2007-Oct-15 18:17:14 +0400, Igor Sysoev [EMAIL PROTECTED] wrote:
more than 2G. The attached patches against 6.x and 7.x allow to create 2G+
segments.
Useful, thanks.
--- src/sys/sys/shm.h2007-09-12 23:33:39.0 +0400
+++ src/sys/sys/shm.h2007-10-15 17:42:38.0 +0400
@@ -77,7 +77,7 @@
struct shmid_ds {
struct ipc_perm shm_perm; /* operation permission structure */
-int shm_segsz; /* size of segment in bytes */
+size_t shm_segsz; /* size of segment in bytes */
...
--- src/usr.bin/ipcs/ipcs.c 2007-09-12 23:32:25.0 +0400
+++ src/usr.bin/ipcs/ipcs.c 2007-10-15 17:29:06.0 +0400
@@ -439,7 +439,7 @@
kshmptr-u.shm_nattch);
if (option BIGGEST)
-printf( %12d,
+printf( %12ld,
kshmptr-u.shm_segsz);
Note that size_t is always 'unsigned' and translates to 'int' rather
than 'long' on i386 so this printf will report a warning. I suggest
printf( %12lu, (unsigned long)kshmptr-u.shm_segsz); or similar.
Here should be %zu.
However, this patch can not be commited even to 7/8, because it does not
preserve binary compatibility for shmctl(IPC_STAT).
It seems that should be new shmctl syscall.
--
Igor Sysoev
http://sysoev.ru/en/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
2G+ sysv shm segments
Two years ago Christian S.J. Peron had increased total number of SysV shm
pages on 64-bit platform, that allows to create many shm segments more than 2G
in sum. However, the patch does not allow to create a single large segment
more than 2G. The attached patches against 6.x and 7.x allow to create 2G+
segments. I know that stock 6.x will not have this feature because of
compatibility, but I send 6.x patch too because someone may want to use
2G+ shm on 6.x.
To install:
patch -d /usr big_sysvshmX.txt
[ rebuild kernel ]
cd /usr/src/include/
make obj
make
make install
cd /usr/src/usr.bin/ipcs/
make obj
make
make install
--
Igor Sysoev
http://sysoev.ru/en/
--- src/sys/sys/shm.h 2007-09-12 23:33:39.0 +0400
+++ src/sys/sys/shm.h 2007-10-15 17:42:38.0 +0400
@@ -77,7 +77,7 @@
struct shmid_ds {
struct ipc_perm shm_perm; /* operation permission structure */
- int shm_segsz; /* size of segment in bytes */
+ size_t shm_segsz; /* size of segment in bytes */
pid_t shm_lpid; /* process ID of last shared memory op */
pid_t shm_cpid; /* process ID of creator */
short shm_nattch; /* number of current attaches */
@@ -94,11 +94,11 @@
* might be of interest to user programs. Do we really want/need this?
*/
struct shminfo {
- int shmmax, /* max shared memory segment size (bytes) */
- shmmin, /* min shared memory segment size (bytes) */
- shmmni, /* max number of shared memory identifiers */
- shmseg, /* max shared memory segments per process */
- shmall; /* max amount of shared memory (pages) */
+ u_long shmmax; /* max shared memory segment size (bytes) */
+ u_long shmmin; /* max shared memory segment size (bytes) */
+ u_long shmmni; /* max number of shared memory identifiers */
+ u_long shmseg; /* max shared memory segments per process */
+ u_long shmall; /* max amount of shared memory (pages) */
};
/*
--- src/sys/kern/sysv_shm.c 2007-09-12 23:33:19.0 +0400
+++ src/sys/kern/sysv_shm.c 2007-10-15 17:16:54.0 +0400
@@ -181,15 +181,15 @@
static int shm_allow_removed;
SYSCTL_DECL(_kern_ipc);
-SYSCTL_INT(_kern_ipc, OID_AUTO, shmmax, CTLFLAG_RW, shminfo.shmmax, 0,
+SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmmax, CTLFLAG_RW, shminfo.shmmax, 0,
Maximum shared memory segment size);
-SYSCTL_INT(_kern_ipc, OID_AUTO, shmmin, CTLFLAG_RW, shminfo.shmmin, 0,
+SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmmin, CTLFLAG_RW, shminfo.shmmin, 0,
Minimum shared memory segment size);
-SYSCTL_INT(_kern_ipc, OID_AUTO, shmmni, CTLFLAG_RDTUN, shminfo.shmmni, 0,
+SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmmni, CTLFLAG_RDTUN, shminfo.shmmni, 0,
Number of shared memory identifiers);
-SYSCTL_INT(_kern_ipc, OID_AUTO, shmseg, CTLFLAG_RDTUN, shminfo.shmseg, 0,
+SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmseg, CTLFLAG_RDTUN, shminfo.shmseg, 0,
Number of segments per process);
-SYSCTL_INT(_kern_ipc, OID_AUTO, shmall, CTLFLAG_RW, shminfo.shmall, 0,
+SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmall, CTLFLAG_RW, shminfo.shmall, 0,
Maximum number of pages available for shared memory);
SYSCTL_INT(_kern_ipc, OID_AUTO, shm_use_phys, CTLFLAG_RW,
shm_use_phys, 0, Enable/Disable locking of shared memory pages in core);
@@ -754,7 +754,8 @@
struct shmget_args *uap;
int mode;
{
- int i, segnum, shmid, size;
+ int i, segnum, shmid;
+ size_t size;
struct ucred *cred = td-td_ucred;
struct shmid_kernel *shmseg;
vm_object_t shm_object;
@@ -967,15 +968,15 @@
{
int i;
- TUNABLE_INT_FETCH(kern.ipc.shmmaxpgs, shminfo.shmall);
+ TUNABLE_ULONG_FETCH(kern.ipc.shmmaxpgs, shminfo.shmall);
for (i = PAGE_SIZE; i 0; i--) {
shminfo.shmmax = shminfo.shmall * i;
if (shminfo.shmmax = shminfo.shmall)
break;
}
- TUNABLE_INT_FETCH(kern.ipc.shmmin, shminfo.shmmin);
- TUNABLE_INT_FETCH(kern.ipc.shmmni, shminfo.shmmni);
- TUNABLE_INT_FETCH(kern.ipc.shmseg, shminfo.shmseg);
+ TUNABLE_ULONG_FETCH(kern.ipc.shmmin, shminfo.shmmin);
+ TUNABLE_ULONG_FETCH(kern.ipc.shmmni, shminfo.shmmni);
+ TUNABLE_ULONG_FETCH(kern.ipc.shmseg, shminfo.shmseg);
TUNABLE_INT_FETCH(kern.ipc.shm_use_phys, shm_use_phys);
shmalloced = shminfo.shmmni;
--- src/usr.bin/ipcs/ipcs.c 2007-09-12 23:32:25.0 +0400
+++ src/usr.bin/ipcs/ipcs.c 2007-10-15 17:29:06.0 +0400
@@ -93,11 +93,11 @@
};
#defineSHMINFO_XVEC\
-X(shmmax, sizeof(int)) \
-X(shmmin, sizeof(int)) \
-X(shmmni, sizeof(int)) \
-X(shmseg, sizeof(int
em driver 6.6.6 regression
Yesterday I have cvsup'ed FreeBSD on ThinkPad T42 to RELENG_6 2007.10.10.23.59.59 and have noticed lags while playing mp3 and browsing. I have suspected new em driver, because there was no lags if wifi iwi0 was used instead of em0 for network. So I had downgraded the em driver separately to 6.2.9 version, have build a kernel loadable module, and have loaded it instead of the 6.6.6 module, and the lags have disappeared. The lags appeares only if browser (Firefox, Opera) does several requests: main page, js, images. There are no lags if browser reload simple page. Also, I could not reproduce lags by other network traffic: pings, ssh, scp, downloading files. There are no lags if I compile and so on. Some additional info: The shared irq11 is used by pcm0, em0, iwi0, CardBus, USB, and acpi_video0. [EMAIL PROTECTED]:1:0: class=0x02 card=0x05491014 chip=0x101e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82540EP Gigabit Ethernet Controller (Mobile)' -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver 6.6.6 regression
On Fri, Oct 12, 2007 at 04:15:46PM +0400, Igor Sysoev wrote: Yesterday I have cvsup'ed FreeBSD on ThinkPad T42 to RELENG_6 2007.10.10.23.59.59 and have noticed lags while playing mp3 and browsing. I have suspected new em driver, because there was no lags if wifi iwi0 was used instead of em0 for network. So I had downgraded the em driver separately to 6.2.9 version, have build a kernel loadable module, and have loaded it instead of the 6.6.6 module, and the lags have disappeared. The lags appeares only if browser (Firefox, Opera) does several requests: main page, js, images. There are no lags if browser reload simple page. Sorry, now I have noticed that audio lags are possible even for single HTTP request/tiny 304 response if site is far from me. Also, I could not reproduce lags by other network traffic: pings, ssh, scp, downloading files. There are no lags if I compile and so on. Some additional info: The shared irq11 is used by pcm0, em0, iwi0, CardBus, USB, and acpi_video0. [EMAIL PROTECTED]:1:0: class=0x02 card=0x05491014 chip=0x101e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82540EP Gigabit Ethernet Controller (Mobile)' -- Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
2G+ KVA on mad64
Can FreeBSD/amd64 support more than 2G+ KVA ? Is it safe to set KPDPI to (NPDPEPG-4) in /sys/amd64/include/pmap.h to get 4G KVA ? Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Strange interaction between kqueue and UNIX domain sockets
I've saw strange interaction between UNIX domain sockets and kqueue in FreeBSD 5.4 (at least). One process connects to another process via UNIX domain socket. Second process writes some data and abnormally exits. The kqueue reports to the first process about some data in fflags and set EV_EOF flag. However, the next recv() returns 0 zero bytes. It seems that kernel ignores these data. I never saw such interaction between kqueue and TCP sockets. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Easy way to kill a 5.x/6.x box as a basic user.
On Fri, 28 Oct 2005, Carl Makin wrote: I've been playing with some GIS software and 32Mb TIFF images. Running ImageMagick's convert utility under my normal user login to convert the image to gif or jpeg blows away the system every time. No panic seen on the console and no core dump found, the system just quietly reboots. Upon reboot /var is full and corrupt and takes ages for the background fsck to fix it so I normally boot into single user mode and do it myself. Is anyone else seeing this? I can happily supply an image that causes the problem if someone wants to try it. It's known problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/67919 And there is bandaid patch by Uwe Doering that at least allows to keep system alive: http://freebsd.rambler.ru/bsdmail/freebsd-stable_2004/msg03698.html I'd applied this patch year ago on one of our production servers, and the bug was gone. However, no one wants to commit this patch. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: thanks for commiting (MFC ffs_softdep.c 1.182, softdep.h 1.18) to RELENG_5 and 6. When in 4?
On Wed, 31 Aug 2005, Stephan Uphoff wrote: On Sat, 2005-08-27 at 03:51, Igor Sysoev wrote: On Tue, 23 Aug 2005, Tomaz Borstnar wrote: Would some kind soul MFC ffs_softdep.c 1.182, softdep.h 1.18 into RELENG_4 as well? This bug is also present in FreeBSD 4.x. Found it ever since 4.7. I saw this annoying bug at least since 4.5. I think the fix should be merged not only to RELENG_4, but also at least to RELENG_4_11. I use very similar fix on two 4.10 machines and one 4.11 machine for 6 weeks. Before the fix I had to reboot one of these machines at least once per month and so. Now the bug has gone. Thank you, Stephan! Glad to hear your success. I finally managed to merge it into RELENG_4. (Sorry for the long delay) However I don't think we normally merge non-security related fixes to RELENG_4_11. (But I will ask around to make sure) The bug is not directly security-related, however, I saw three various consequences of the bug: 1) The free space very quickly ends up. It usually happens when the big log files are used. I saw it very often. The only way to reclaim the space is to reboot. And then fsck would run on these partitions (and probably on other partitions if you forgot to umount them before reboot). 2) The free inodes ends up. I saw it once. Yes, the only way is the reboot. 2) The vnodes ends up. I saw it once: the most processes stuck in inode wchan. And yes, probably the only way is the hard reboot: you simply could not start the shutdown procedure. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: icc8 failed on 4.10: Illegal instruction
On Wed, 29 Dec 2004, Igor Sysoev wrote: On Tue, 28 Dec 2004, Kris Kennaway wrote: On Wed, Dec 29, 2004 at 10:21:05AM +0300, Igor Sysoev wrote: Then I installed the port and I ran /usr/local/intel_cc_80/bin/icc, but it always failed with message Illegal instruction. You forgot to mention what type of CPU you have. Sorry, it was so obvious for me that is not CPU problem in this case, so I forgot to mention it. From dmesg: CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz (2679.56-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 0x80b13d7 __intel_proc_init_ftzdaz+79:stmxcsr (%esp,1) Strange, the code in __intel_proc_init_ftzdaz looks like the right code. Right now I can not say from what extention stmxcsr come from. Here is the features from dmesg: Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE It's an SSE instruction, and you need to enable support for SSE in your kernel. Thank you. The options CPU_ENABLE_SSE resolves the problem. I think it should be mention in the port for 4.x. However, it seems that 4.10's headers are not good for icc8: cat q.c #include stdio.h /usr/local/intel_cc_80/bin/icc q.c /usr/include/wchar.h(79): error: __mbstate_t has already been declared in the current scope } __mbstate_t; ^ /usr/include/libio.h(463): error: identifier __gnuc_va_list is undefined _IO_va_list, int *__restrict) __THROW; ^ /usr/include/libio.h(465): error: identifier __gnuc_va_list is undefined _IO_va_list) __THROW; ^ /usr/include/stdio.h(307): error: identifier __gnuc_va_list is undefined _G_va_list __arg) __THROW; ^ /usr/include/stdio.h(309): error: identifier __gnuc_va_list is undefined extern int vprintf (__const char *__restrict __format, _G_va_list __arg) ^ /usr/include/stdio.h(313): error: identifier __gnuc_va_list is undefined _G_va_list __arg) __THROW; ^ /usr/include/stdio.h(324): error: identifier __gnuc_va_list is undefined __const char *__restrict __format, _G_va_list __arg) ^ compilation aborted for q.c (code 2) The port maintainer Alexander Leidinger said that it is because the linux_devtools port was installed, and he is right - just after I deleted the linux_devtools, icc ran without problems. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: icc8 failed on 4.10: Illegal instruction
On Tue, 28 Dec 2004, Kris Kennaway wrote: On Wed, Dec 29, 2004 at 10:21:05AM +0300, Igor Sysoev wrote: Then I installed the port and I ran /usr/local/intel_cc_80/bin/icc, but it always failed with message Illegal instruction. You forgot to mention what type of CPU you have. Sorry, it was so obvious for me that is not CPU problem in this case, so I forgot to mention it. From dmesg: CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz (2679.56-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 0x80b13d7 __intel_proc_init_ftzdaz+79:stmxcsr (%esp,1) Strange, the code in __intel_proc_init_ftzdaz looks like the right code. Right now I can not say from what extention stmxcsr come from. Here is the features from dmesg: Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE It's an SSE instruction, and you need to enable support for SSE in your kernel. Thank you. The options CPU_ENABLE_SSE resolves the problem. I think it should be mention in the port for 4.x. However, it seems that 4.10's headers are not good for icc8: cat q.c #include stdio.h /usr/local/intel_cc_80/bin/icc q.c /usr/include/wchar.h(79): error: __mbstate_t has already been declared in the current scope } __mbstate_t; ^ /usr/include/libio.h(463): error: identifier __gnuc_va_list is undefined _IO_va_list, int *__restrict) __THROW; ^ /usr/include/libio.h(465): error: identifier __gnuc_va_list is undefined _IO_va_list) __THROW; ^ /usr/include/stdio.h(307): error: identifier __gnuc_va_list is undefined _G_va_list __arg) __THROW; ^ /usr/include/stdio.h(309): error: identifier __gnuc_va_list is undefined extern int vprintf (__const char *__restrict __format, _G_va_list __arg) ^ /usr/include/stdio.h(313): error: identifier __gnuc_va_list is undefined _G_va_list __arg) __THROW; ^ /usr/include/stdio.h(324): error: identifier __gnuc_va_list is undefined __const char *__restrict __format, _G_va_list __arg) ^ compilation aborted for q.c (code 2) Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: icc8 failed on 4.10: Illegal instruction
On Wed, 29 Dec 2004, Igor Sysoev wrote: On Tue, 28 Dec 2004, Kris Kennaway wrote: It's an SSE instruction, and you need to enable support for SSE in your kernel. Thank you. The options CPU_ENABLE_SSE resolves the problem. I think it should be mention in the port for 4.x. The message about CPU_ENABLE_SSE exists, however it does not say about a signal: If you use icc on a Pentium 4 you may have to use 'options CPU_ENABLE_SSE' (depending on the OS version, if in doubt try if it works) in your kernel config (have a look at http://www.FreeBSD.org/handbook/ if you do not know how to do this), else icc will hang forever. However, it seems that 4.10's headers are not good for icc8: cat q.c #include stdio.h /usr/local/intel_cc_80/bin/icc q.c /usr/include/wchar.h(79): error: __mbstate_t has already been declared in the current scope } __mbstate_t; ^ /usr/include/libio.h(463): error: identifier __gnuc_va_list is undefined _IO_va_list, int *__restrict) __THROW; ^ [ ... ] /usr/include/stdio.h(324): error: identifier __gnuc_va_list is undefined __const char *__restrict __format, _G_va_list __arg) ^ compilation aborted for q.c (code 2) The __gnuc_va_list errors could be fixed by adding -D__gnuc_va_list=va_list to /usr/local/intel_cc_80/bin/icc.cfg and /usr/local/intel_cc_80/bin/icpc.cfg, but how to fix __mbstate_t error I do not know. Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
icc8 failed on 4.10: Illegal instruction
I have cvsup'ed ports to use icc-8.1.024 on FreeBSD 4.10-RELEASE. Then I installed the port and I ran /usr/local/intel_cc_80/bin/icc, but it always failed with message Illegal instruction. Does icc-8.1.024 work on FreeBSD 4.x ? Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: icc8 failed on 4.10: Illegal instruction
On Tue, 28 Dec 2004, Kris Kennaway wrote: On Tue, Dec 28, 2004 at 04:34:35PM +0300, Igor Sysoev wrote: I have cvsup'ed ports to use icc-8.1.024 on FreeBSD 4.10-RELEASE. Then I installed the port and I ran /usr/local/intel_cc_80/bin/icc, but it always failed with message Illegal instruction. You forgot to mention what type of CPU you have. Does icc-8.1.024 work on FreeBSD 4.x ? Sorry, it was so obvious for me that is not CPU problem in this case, so I forgot to mention it. From dmesg: CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz (2679.56-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 I should also say that Linux binaries from linux_base-8-8.0_4 runs without problems. Is there way to get the core of Linux binary and look it in gdb ? Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: icc8 failed on 4.10: Illegal instruction
On Tue, 28 Dec 2004, Kris Kennaway wrote: On Wed, Dec 29, 2004 at 09:41:32AM +0300, Igor Sysoev wrote: On Tue, 28 Dec 2004, Kris Kennaway wrote: On Tue, Dec 28, 2004 at 04:34:35PM +0300, Igor Sysoev wrote: I have cvsup'ed ports to use icc-8.1.024 on FreeBSD 4.10-RELEASE. Then I installed the port and I ran /usr/local/intel_cc_80/bin/icc, but it always failed with message Illegal instruction. You forgot to mention what type of CPU you have. Does icc-8.1.024 work on FreeBSD 4.x ? Sorry, it was so obvious for me that is not CPU problem in this case, so I forgot to mention it. From dmesg: CPU: Intel(R) Pentium(R) 4 CPU 2.66GHz (2679.56-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 I should also say that Linux binaries from linux_base-8-8.0_4 runs without problems. Is there way to get the core of Linux binary and look it in gdb ? The linux_devtools port includes a linux version of gdb. /usr/compat/linux/usr/bin/gdb /usr/local/intel_cc_80/bin/iccbin GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-redhat-linux... (gdb) run Starting program: /usr/local/intel_cc_80/bin/iccbin Program received signal SIGILL, Illegal instruction. 0x080b13d7 in __intel_proc_init_ftzdaz () (gdb) bt #0 0x080b13d7 in __intel_proc_init_ftzdaz () #1 0x080b133d in __intel_proc_init.H () #2 0x2830e54d in __libc_start_main () from /lib/libc.so.6 (gdb) info registers ... eip0x80b13d70x80b13d7 ... (gdb) disassemble $eip ... 0x80b13d3 __intel_proc_init_ftzdaz+75:mov0x2c(%esp,1),%esi 0x80b13d7 __intel_proc_init_ftzdaz+79:stmxcsr (%esp,1) 0x80b13db __intel_proc_init_ftzdaz+83:mov(%esp,1),%eax ... (gdb) Strange, the code in __intel_proc_init_ftzdaz looks like the right code. Right now I can not say from what extention stmxcsr come from. Here is the features from dmesg: Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Igor Sysoev http://sysoev.ru/en/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vnode_pager_putpages errors and DOS?
On Fri, 5 Nov 2004, Uwe Doering wrote: Igor Sysoev wrote: [...] I've tried your patch from second email (it requires to include sys/conf.h for devsw and D_DISK): the system also became unresponsible. The main problem is that I could not kill the offending process - it stuck in biowr state. In the meantime I've investigated this further. The two patches I provided so far certainly have their merits, since they deal with some unwanted side effects. However, I found that the root cause for the eventual system lock-up lies elsewhere. In an earlier email I already pointed out that function vnode_pager_generic_putpages() actually doesn't care whether the write operation failed or not. It always returns VM_PAGER_OK. Now, in case the write operation succeeds the file system code takes care that the formerly dirty pages associated with the i/o buffer get marked clean. On the other hand, if the write attempt fails, for instance in an out-of-disk-space situation, the pages are left dirty. At this point the syncer enters an infinite loop, trying to flush the same dirty pages to disk over and over again. The fix is actually quite simple. In case of a write error we have to make sure ourselves that the associated pages get marked clean. We do this by returning VM_PAGER_BAD instead of VM_PAGER_OK. These two result codes are functionally identical, with the exception that VM_PAGER_BAD additionally marks the respective page clean. For the details, please have a look at the caller function vm_pageout_flush() in 'vm_pageout.c'. What this modification means is that in case of a write error the affected pages remain intact in memory until they get recycled, but we lose their contents as far as the copy on disk is concerned. I believe this is acceptable (and possibly even originally intended) because giving up on syncing is about the best thing we can do in this situation, anyway. And it is certainly a much better choice than halting the whole system due to an infinite loop. I've attached an updated version of the patch for 'vnode_pager.c'. On my test system it resolved the issue. Please let us know whether it works for you as well. Sorry for the late response: I was ill and have no access to the test machine. I applied the patch to the clean 4.10. The result is the same: the process could not be killed, the file system access is very limited and the system became unresponsible. Igor Sysoev http://sysoev.ru/en/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vnode_pager_putpages errors and DOS?
On Thu, 11 Nov 2004, Igor Sysoev wrote: On Fri, 5 Nov 2004, Uwe Doering wrote: Igor Sysoev wrote: [...] I've tried your patch from second email (it requires to include sys/conf.h for devsw and D_DISK): the system also became unresponsible. The main problem is that I could not kill the offending process - it stuck in biowr state. In the meantime I've investigated this further. The two patches I provided so far certainly have their merits, since they deal with some unwanted side effects. However, I found that the root cause for the eventual system lock-up lies elsewhere. In an earlier email I already pointed out that function vnode_pager_generic_putpages() actually doesn't care whether the write operation failed or not. It always returns VM_PAGER_OK. Now, in case the write operation succeeds the file system code takes care that the formerly dirty pages associated with the i/o buffer get marked clean. On the other hand, if the write attempt fails, for instance in an out-of-disk-space situation, the pages are left dirty. At this point the syncer enters an infinite loop, trying to flush the same dirty pages to disk over and over again. The fix is actually quite simple. In case of a write error we have to make sure ourselves that the associated pages get marked clean. We do this by returning VM_PAGER_BAD instead of VM_PAGER_OK. These two result codes are functionally identical, with the exception that VM_PAGER_BAD additionally marks the respective page clean. For the details, please have a look at the caller function vm_pageout_flush() in 'vm_pageout.c'. What this modification means is that in case of a write error the affected pages remain intact in memory until they get recycled, but we lose their contents as far as the copy on disk is concerned. I believe this is acceptable (and possibly even originally intended) because giving up on syncing is about the best thing we can do in this situation, anyway. And it is certainly a much better choice than halting the whole system due to an infinite loop. I've attached an updated version of the patch for 'vnode_pager.c'. On my test system it resolved the issue. Please let us know whether it works for you as well. Sorry for the late response: I was ill and have no access to the test machine. I applied the patch to the clean 4.10. The result is the same: the process could not be killed, the file system access is very limited and the system became unresponsible. Sorry, I applied the patch, but forget to rebuild kernel :). It seems that patch resolves the problem - the program exits and the system is working. I run it several times. I would also run buildworld on this system to ensure that the program did not affect VM. Igor Sysoev http://sysoev.ru/en/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vnode_pager_putpages errors and DOS?
On Thu, 11 Nov 2004, Igor Sysoev wrote: I've attached an updated version of the patch for 'vnode_pager.c'. On my test system it resolved the issue. Please let us know whether it works for you as well. Sorry for the late response: I was ill and have no access to the test machine. I applied the patch to the clean 4.10. The result is the same: the process could not be killed, the file system access is very limited and the system became unresponsible. Sorry, I applied the patch, but forget to rebuild kernel :). It seems that patch resolves the problem - the program exits and the system is working. I run it several times. I would also run buildworld on this system to ensure that the program did not affect VM. make -j 32 buildworld ran without problems. Igor Sysoev http://sysoev.ru/en/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vnode_pager_putpages errors and DOS?
On Thu, 4 Nov 2004, Uwe Doering wrote:
Igor Sysoev wrote:
On Sat, 9 Oct 2004, Uwe Doering wrote:
[...]
I wonder whether the unresponsiveness is actually just the result of the
kernel spending most of the time in printf(), generating warning
messages. vnode_pager_generic_putpages() doesn't return any error in
case of a write failure, so the caller (syncer in this case) isn't aware
that the paging out failed, that is, it is supposed to carry on as if
nothing happened.
So how about limiting the number of warnings to one per second? UFS has
similar code in order to curb file system full and the like. Please
consider trying the attached patch, which applies cleanly to 4-STABLE.
It won't make the actual application causing these errors any happier,
but it may eliminate the DoS aspect of the issue.
I have just tried your patch. To test I ran the program from
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/67919
The patch allows me to login on machine while the system reports about
vnode_pager_putpages: I/O error 28. However, the file system access is
very limited and after some time the system became unresponsible.
Limited file system access is to be expected, since
vnode_pager_putpages() keeps the number of dirty buffers
('numdirtybuffers') near its upper limit ('hidirtybuffers'). However,
the unresponsiveness may be caused by another shortcoming I found in the
meantime.
When 'numdirtybuffers' is greater or equal 'hidirtybuffers', function
bwillwrite() will block until 'numdirtybuffers' drops below some
threshold value. bwillwrite() gets called in a number of places that
deal with writing data to disk.
Two of these places are dofilewrite() (which is in turn called by
write() and pwrite()) and writev(). There, bwillwrite() gets called if
the file descriptor is of type DTYPE_VNODE. Now, this unfortunately
doesn't take into account that ttys, including pseudo ttys, and even
/dev/null and friends, are character device nodes and therefore vnodes
as well, but have nothing to do with writing data to disk. That is, in
case of heavy disk write activity, write attempts to these device nodes
get blocked, too! With the consequence that the system appears to
become unresponsive at the shell prompt, or reacts very sporadic. Even
daemonized processes that happen to log data to /dev/null (on stdout
stderr, for example) will block.
What we need here is an additional test that makes sure that in case of
a character device bwillwrite() gets called only if the device is in
fact a disk. Please consider trying out the attached patch. It will
not reduce the heavy disk activity (which is, after all, legitimate),
but it is supposed to enable you to operate the system at shell level
and kill the offending process, or do whatever is necessary to resolve
the problem.
I've tried your patch from second email (it requires to include
sys/conf.h for devsw and D_DISK): the system also became unresponsible.
The main problem is that I could not kill the offending process - it
stuck in biowr state.
Igor Sysoev
http://sysoev.ru/en/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vnode_pager_putpages errors and DOS?
On Sat, 9 Oct 2004, Uwe Doering wrote: Robert Watson wrote: On Fri, 8 Oct 2004, Steve Shorter wrote: I have some machines that run customers cgi stuff. These machines have started to hang and become unresponsive. At first I thought it was a hardware issue, but I discovered in a cyclades log the following stuff that got logged to the console which explains the cause of the system hangs/failures. vnode_pager_putpages: residual I/O 65536 at 347 vnode_pager_putpages: I/O error 28] vnode_pager_putpages: residual I/O 65536 at 285] Aha! also at the same time I get in syslog /kernel: pid 6 (syncer), uid 0 on /chroot/tmp: file system full Whats happening? Can a full filesystem bring the thing down? Ideas? Fixes? Ideally not, but many UNIX programs respond poorly to being out of memory and disk space (No space, wot?). Are you using a swap file, and if so, how did you create the swapfile? Are you using sparse files much? I wonder whether the unresponsiveness is actually just the result of the kernel spending most of the time in printf(), generating warning messages. vnode_pager_generic_putpages() doesn't return any error in case of a write failure, so the caller (syncer in this case) isn't aware that the paging out failed, that is, it is supposed to carry on as if nothing happened. So how about limiting the number of warnings to one per second? UFS has similar code in order to curb file system full and the like. Please consider trying the attached patch, which applies cleanly to 4-STABLE. It won't make the actual application causing these errors any happier, but it may eliminate the DoS aspect of the issue. I have just tried your patch. To test I ran the program from http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/67919 The patch allows me to login on machine while the system reports about vnode_pager_putpages: I/O error 28. However, the file system access is very limited and after some time the system became unresponsible. Igor Sysoev http://sysoev.ru/en/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic caused by EVFILT_SIGNAL detaching in rfork()ed thread
On Sat, 23 Oct 2004, Uwe Doering wrote:
Igor Sysoev wrote:
Here is more correct patch to fix the panic in 4.x reported in
http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2004/msg02732.html
-
--- src/sys/kern/kern_event.c Sun Oct 10 12:17:55 2004
+++ src/sys/kern/kern_event.c Sun Oct 10 12:19:29 2004
@@ -794,7 +794,8 @@
while (kn != NULL) {
kn0 = SLIST_NEXT(kn, kn_link);
if (kq == kn-kn_kq) {
- kn-kn_fop-f_detach(kn);
+ if (!(kn-kn_status KN_DETACHED))
+ kn-kn_fop-f_detach(kn);
/* XXX non-fd release of kn-kn_ptr */
knote_free(kn);
*knp = kn0;
-
Your patch appears to be an excerpt from the fix to RELENG_5. May I
suggest a different approach for RELENG_4? My reasoning is that the
implementation of kevents differs between RELENG_4 and RELENG_5.
I agree with your patch. It is similar to my early patch, however,
I think that is more correctly to check (kn-kn_status KN_DETACHED)
instead of !SLIST_EMPTY(p-p_klist).
Also, it would probably be a good idea to fix RELENG_4 swiftly (and
possibly release a security advisory) because this flaw is certainly a
great DoS opportunity for maliciously minded shell users ...
Yes.
Igor Sysoev
http://sysoev.ru/en/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
panic caused by EVFILT_SIGNAL detaching in rfork()ed thread
Here is more correct patch to fix the panic in 4.x reported in
http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2004/msg02732.html
-
--- src/sys/kern/kern_event.c Sun Oct 10 12:17:55 2004
+++ src/sys/kern/kern_event.c Sun Oct 10 12:19:29 2004
@@ -794,7 +794,8 @@
while (kn != NULL) {
kn0 = SLIST_NEXT(kn, kn_link);
if (kq == kn-kn_kq) {
- kn-kn_fop-f_detach(kn);
+ if (!(kn-kn_status KN_DETACHED))
+ kn-kn_fop-f_detach(kn);
/* XXX non-fd release of kn-kn_ptr */
knote_free(kn);
*knp = kn0;
-
The patch based on the fix for FreeBSD 5.x:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_event.c.diff?r1=1.79r2=1.80
For more information see the thread started in
http://freebsd.rambler.ru/bsdmail/freebsd-current_2004/msg18389.html
To reproduce the panic in 4.x you could download
http://sysoev.ru/nginx/nginx-0.1.2.tar.gz
and build it without the installation:
tar zxf nginx-0.1.2.tar.gz
cd nginx-0.1.2
./configure --with-threads=rfork \
--without-http_rewrite_module \
--prefix=$PWD \
--pid-path=nginx.pid \
--http-log-path=access.log \
--error-log-path=stderr
make
Now you have to edit ./conf/nginx.conf.
Add the line daemon off; in the start of the file.
Change the lines worker_processes 3; to worker_threads 3;
and listen 80; to listen 8000;.
Now you could run ./nginx as non-privileged user.
If you run in another console
ps ax -o pid,ppid,%cpu,vsz,wchan,command|egrep '(nginx:|PID)'
you will see something like this:
PID PPID %CPU VSZ WCHAN COMMAND
3737 238 0.0 1340 pause nginx: master process ./nginx
3738 3737 0.0 1844 kqread nginx: worker process (nginx)
3739 3738 0.0 1844 kqread nginx: worker thread (nginx)
3740 3738 0.0 1844 kqread nginx: worker thread (nginx)
3741 3738 0.0 1844 kqread nginx: worker thread (nginx)
Now stop nginx by pressing ^C. Your system may panic.
Igor Sysoev
http://sysoev.ru/en/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vnode_pager_putpages errors and DOS?
On Sat, 9 Oct 2004, Robert Watson wrote: On Fri, 8 Oct 2004, Steve Shorter wrote: I have some machines that run customers cgi stuff. These machines have started to hang and become unresponsive. At first I thought it was a hardware issue, but I discovered in a cyclades log the following stuff that got logged to the console which explains the cause of the system hangs/failures. vnode_pager_putpages: residual I/O 65536 at 347 vnode_pager_putpages: I/O error 28] vnode_pager_putpages: residual I/O 65536 at 285] Aha! also at the same time I get in syslog /kernel: pid 6 (syncer), uid 0 on /chroot/tmp: file system full Whats happening? Can a full filesystem bring the thing down? Ideas? Fixes? Ideally not, but many UNIX programs respond poorly to being out of memory and disk space (No space, wot?). Are you using a swap file, and if so, how did you create the swapfile? Are you using sparse files much? If the machines run CGIs, then it is probably ImageMagick's mmap()s: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/67919 Igor Sysoev http://sysoev.ru/en/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [GENERAL] was there a change in FreeBSD SHM implementation from4.4 to 4.6? (postgres trouble)
On Fri, 12 Jul 2002, Vivek Khera wrote: IS == Igor Sysoev [EMAIL PROTECTED] writes: The kernel config has SHMMAX and SHMMAXPGS. IS Sorry, I'd meant SHMMAXPGS is sysctl kern.ipc.shmall. Actually, SHMMAXPGS * 4096 == kern.ipc.shmmax so if you set SHMMAXPGS to some value, you need to multiply that by 4096 to set shmmax. I think the kernel should warn you if you set SHMMAX SHMALL. Although kernel build can warn about it I do not believe that sysctl mechanics allows warnings. Igor Sysoev http://sysoev.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Upcoming 4.6.1
I think 4.6.1 should contain following kernel fixes: 1. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=100548+0+archive/2002/freebsd-stable/20020630.freebsd-stable 2. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1982827+0+archive/2002/cvs-all/20020630.cvs-all 3. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1209006+0+archive/2002/cvs-all/20020707.cvs-all 4. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=351587+0+archive/2002/cvs-all/20020630.cvs-all Igor Sysoev http://sysoev.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
VMware2 and CDROM image
Hi, I have a patch that allow to use CD-ROM images in VMware2 via vn device: http://sysoev.ru/freebsd/patch.vn_cd.txt Patch was made and tested on FreeBSD 4.2 and 4.3. I had used it to install Windows NT 4.0 from CD-ROM image in VMware2. It can be used on FreeBSD 4.x only (because it's using vn device). Russian description is available here: http://sysoev.ru/freebsd/vmware_cd_image.html In English, short: After appling of patch you need rebuild vnconfig and kernel. vnconfig will get new options - '-s cdrom': vnconfig -s cdrom -c vn0c image.iso After configuring vn device you can use it in VMware2 as /dev/vn0c instead of physical CD-ROM device. Igor Sysoev http://sysoev.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
