* [Qemu-devel] VNC terminal server?
From: Samuel Hunt @ 2006-04-08 16:20 UTC (permalink / raw)
To: qemu-devel
It occurs to me that this program would make an excellent basis for a VNC
terminal server.
What I'm basically after is something that I can have several clients
connect into one server, and the server does all the work and just outputs
the screen and stuff over the network and recieves the input over the
network.
VNC does all the I/O that's needed, would it be possible to set Qemu up
though so it works with VNC as the I/O and simply sits on something like
Linux as a server, starting a new instance every time another client
connects?
Thanks all!
Sam
^ permalink raw reply
* Re: [PATCH] fix udevtrigger first/default/last ordering
From: Kay Sievers @ 2006-04-08 16:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20060408175157.6dfb3d29@eusebe>
On Sat, Apr 08, 2006 at 05:51:57PM +0200, Thomas de Grenier de Latour wrote:
> There is some logic in udevtrigger (udev-0.89 or current git) to make
> some events being triggered first or last. But it doesn't work because,
> in device_list_insert(), some "sysfs_path"-prefixed devices paths are
> compared to some unprefixed paths
Fixed. Thanks a lot,
Kay
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Watch Performance
From: Steve Grubb @ 2006-04-08 16:21 UTC (permalink / raw)
To: linux-audit, redhat-lspp
Hello,
Over the last day or two, I re-worked the user space audit code to be able to
control the new file system audit subsystem. As I was doing the work, I
became concerned about the performance impact since it appears to be using
the syscall exit filter.
The syscall exit filter (and entry filter) is expensive to use except in cases
where you need to use it. This is because each rule in it must be examined
during each syscall to see if the current syscall is of interest. The current
lspp configuration has 10 syscall audit rules.
I became curious what the measured impact would be with the current file
system audit implementation. I decide to run the same performance test that I
tested the audit system with a couple weeks ago when inode and IPC problems
were noticed. I used the lspp.16 kernel with profile=2 boot param. The
following table shows the results:
rules seconds
0 49
10 56
25 75
50 115
75 143
90 185
0 rules had this for function usage:
1284 __d_lookup 4.7380
1170 __link_path_walk 0.3098
1065 avc_has_perm_noaudit 1.2144
706 _atomic_dec_and_lock 8.4048
612 do_path_lookup 0.8204
561 dput 1.2986
509 _raw_spin_lock 2.1477
10 rules had this:
1295 __d_lookup 4.7786
1089 audit_filter_syscall 6.3684
1081 __link_path_walk 0.2862
889 avc_has_perm_noaudit 1.0137
676 audit_getname 2.6000
658 do_path_lookup 0.8820
596 _atomic_dec_and_lock 7.0952
25 rules had this:
3193 audit_filter_rules 3.0009
2178 audit_filter_syscall 12.7368
1280 __d_lookup 4.7232
1131 __link_path_walk 0.2994
956 avc_has_perm_noaudit 1.0901
652 _atomic_dec_and_lock 7.7619
530 dput 1.2269
50 rules had this:
11213 audit_filter_rules 10.5385
4654 audit_filter_syscall 27.2164
4100 selinux_task_ctxid 141.3793
1212 __d_lookup 4.4723
1103 __link_path_walk 0.2920
1012 avc_has_perm_noaudit 1.1539
788 _atomic_dec_and_lock 9.3810
75 had this:
15351 audit_filter_rules 14.4276
6032 audit_filter_syscall 35.2749
2066 selinux_task_ctxid 71.2414
1237 __d_lookup 4.5646
1184 __link_path_walk 0.3135
1014 avc_has_perm_noaudit 1.1562
592 _atomic_dec_and_lock 7.0476
and 90 rules had this:
18287 audit_filter_rules 17.1870
9173 audit_filter_syscall 53.6433
4346 selinux_task_ctxid 149.8621
1314 __link_path_walk 0.3479
1218 __d_lookup 4.4945
1070 avc_has_perm_noaudit 1.2201
682 _atomic_dec_and_lock 8.1190
As you can see, the audit_filter_rules and audit_filter_syscall overwhelmed
the profile quickly. It would not be unreasonable for a system to have 40
watches. The lspp rules have 56 of them. With 10 syscall rules added, the
performance of a correctly configured lspp machine will be similar to the 75
rules test. This represents a 186% performance hit compared to no audit
rules.
I do not believe optimizing the audit_filter_rules function will solve the
problem. I think the file system audit algorithm needs to be re-thought. It
simply cannot penalize every syscall.
There are several ways to solve the problem. Maybe what we need to do is use
the watch list to store watches on and add a new field to the context. If a
watch is triggered it sets the flag in the context. When syscall exit is
done, it checks the flag and if set, does both the watch list and the exit
list. Otherwise, it skips the watch list. I don't know if this is feasible,
or a preferred solution, but we need to start looking at how to decouple the
exit list and watches.
-Steve
^ permalink raw reply
* Re: [BUG] 2.6.16.2 (like olders) fails to suspend audio device
From: Lee Revell @ 2006-04-08 16:27 UTC (permalink / raw)
To: patrizio.bassi; +Cc: Kernel,, alsa-devel
In-Reply-To: <4437BB29.8050502@gmail.com>
It would help if you cc'ed the right list (added)
On Sat, 2006-04-08 at 15:31 +0200, Patrizio Bassi wrote:
> I've already posted same bug some weeks ago.
>
> this is just a reminder and to confirm bug is still there.
>
> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>
> Alsa driver: 1370
>
> 1) if builtin in kernel, on resume it doesn't work any more.
> 2) if built as module on resume it works with no need to remove/readd
> module.
>
> in both situations dmesg shows:
>
> pnp: Failed to activate device 00:0b.
>
>
> Stopping tasks: ===========================================|
> Shrinking memory... done (39214 pages freed)
> pnp: Device 00:0c disabled.
> pnp: Device 00:08 disabled.
> swsusp: Need to copy 13752 pages
> ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 9 (level, low)
> -> IRQ 9
> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
> -> IRQ 9
> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
> -> IRQ 9
> ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 5 (level, low)
> -> IRQ 5
> ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKD] -> GSI 9 (level, low)
> -> IRQ 9
> ACPI: PCI Interrupt 0000:00:0a.2[C] -> Link [LNKA] -> GSI 11 (level,
> low) -> IRQ 11
> usb usb1: root hub lost power or was reset
> ehci_hcd 0000:00:0a.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
> ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level,
> low) -> IRQ 10
> pnp: Device 00:08 activated.
> pnp: Failed to activate device 00:0b.
> pnp: Device 00:0c activated.
> Restarting tasks... done
> agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
> agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode
> agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode
>
> lspci
> 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
> bridge (rev 03)
> 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP
> bridge (rev 03)
> 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
> 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
> 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
> 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
> 00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
> (rev 74)
> 00:0a.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 50)
> 00:0a.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 50)
> 00:0a.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP
>
>
> dmesg says 00:08 and 00:0c are activated..but i've no idea which devices
> they are, lspci -vv shows nothing about that.
>
> Ready to give more infos and test patches.
>
> Patrizio Bassi
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [BUG] 2.6.16.2 (like olders) fails to suspend audio device
From: Lee Revell @ 2006-04-08 16:27 UTC (permalink / raw)
To: patrizio.bassi; +Cc: Kernel,, alsa-devel
In-Reply-To: <4437BB29.8050502@gmail.com>
It would help if you cc'ed the right list (added)
On Sat, 2006-04-08 at 15:31 +0200, Patrizio Bassi wrote:
> I've already posted same bug some weeks ago.
>
> this is just a reminder and to confirm bug is still there.
>
> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>
> Alsa driver: 1370
>
> 1) if builtin in kernel, on resume it doesn't work any more.
> 2) if built as module on resume it works with no need to remove/readd
> module.
>
> in both situations dmesg shows:
>
> pnp: Failed to activate device 00:0b.
>
>
> Stopping tasks: ===========================================|
> Shrinking memory... done (39214 pages freed)
> pnp: Device 00:0c disabled.
> pnp: Device 00:08 disabled.
> swsusp: Need to copy 13752 pages
> ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 9 (level, low)
> -> IRQ 9
> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
> -> IRQ 9
> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
> -> IRQ 9
> ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 5 (level, low)
> -> IRQ 5
> ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKD] -> GSI 9 (level, low)
> -> IRQ 9
> ACPI: PCI Interrupt 0000:00:0a.2[C] -> Link [LNKA] -> GSI 11 (level,
> low) -> IRQ 11
> usb usb1: root hub lost power or was reset
> ehci_hcd 0000:00:0a.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
> ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level,
> low) -> IRQ 10
> pnp: Device 00:08 activated.
> pnp: Failed to activate device 00:0b.
> pnp: Device 00:0c activated.
> Restarting tasks... done
> agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
> agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode
> agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode
>
> lspci
> 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
> bridge (rev 03)
> 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP
> bridge (rev 03)
> 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
> 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
> 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
> 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
> 00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
> (rev 74)
> 00:0a.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 50)
> 00:0a.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 50)
> 00:0a.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP
>
>
> dmesg says 00:08 and 00:0c are activated..but i've no idea which devices
> they are, lspci -vv shows nothing about that.
>
> Ready to give more infos and test patches.
>
> Patrizio Bassi
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: 40% IDE performance regression going from FC3 to FC5 with same kernel
From: Alessandro Suardi @ 2006-04-08 16:27 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Linux Kernel
In-Reply-To: <1144511112.2989.8.camel@laptopd505.fenrus.org>
On 4/8/06, Arjan van de Ven <arjan@infradead.org> wrote:
>
> > Just for the record - no, even rebuilding same kernel with same GCC
> > (3.4.4) under FC5, disk performance is much slower than FC3 -
> > according to hdparm _and_ dd tests.
>
> what happens if you kill hald and other inotify using animals?
Thanks Arjan for looking into this.
Stopping hald brings hdparm from 18.5MB/s to 20MB/s, which is
indeed a noticeable improvement, though still far from the FC3
performance. I'm unsure what else can be stopped however
from this process list:
[root@donkey init.d]# ps ax
PID TTY STAT TIME COMMAND
1 ? S 0:00 init [3]
2 ? SN 0:00 [ksoftirqd/0]
3 ? S 0:00 [watchdog/0]
4 ? S< 0:00 [events/0]
5 ? S< 0:00 [khelper]
6 ? S< 0:00 [kthread]
8 ? S< 0:00 [kblockd/0]
11 ? S< 0:00 [khubd]
40 ? S 0:00 [kapmd]
72 ? S 0:00 [pdflush]
73 ? S 0:00 [pdflush]
74 ? S 0:00 [kswapd0]
75 ? S< 0:00 [aio/0]
76 ? S 0:00 [cifsoplockd]
77 ? S 0:00 [cifsdnotifyd]
153 ? S< 0:00 [kseriod]
186 ? S 0:00 [kedac]
199 ? S 0:00 [kjournald]
274 ? S<s 0:00 /sbin/udevd -d
346 ? S< 0:00 [kpsmoused]
781 ? S< 0:00 [scsi_eh_0]
782 ? S< 0:00 [usb-storage]
836 ? S 0:00 [kjournald]
838 ? S 0:00 [kjournald]
840 ? S 0:00 [kjournald]
842 ? S 0:00 [kjournald]
844 ? S 0:00 [kjournald]
1170 ? Ss 0:00 syslogd -m 0
1173 ? Ss 0:00 klogd -x
1197 ? Ss 0:00 portmap
1216 ? Ss 0:00 rpc.statd
1295 ? Ss 0:00 /usr/sbin/apmd -p 10 -w 5 -W -P
/etc/sysconfig/apm-sc 1440 ? Ss 0:00 cupsd
1480 ? Ss 0:00 /usr/sbin/sshd
1504 ? Ss 0:00 sendmail: accepting connections
1514 ? Ss 0:00 sendmail: Queue runner@01:00:00 for
/var/spool/client 1524 ? Ss 0:00 gpm -m /dev/input/mice -t
exps2
1533 ? Ss 0:00 crond
1582 ? Ss 0:00 /usr/sbin/atd
1662 tty1 Ss+ 0:00 /sbin/mingetty tty1
1663 tty2 Ss+ 0:00 /sbin/mingetty tty2
1666 tty3 Ss+ 0:00 /sbin/mingetty tty3
1669 tty4 Ss+ 0:00 /sbin/mingetty tty4
1672 tty5 Ss+ 0:00 /sbin/mingetty tty5
1703 tty6 Ss+ 0:00 /sbin/mingetty tty6
1718 ? Ss 0:00 sshd: root@pts/0
1742 pts/0 Ss 0:00 -bash
1859 pts/0 R+ 0:00 ps ax
strace shows read() system time practically identical around 1.3s,
hence I ran a ltrace comparison, which shows this:
FC3:
[root@donkey ~]# ltrace -c dd if=/dev/hdb of=/dev/null skip=400
bs=1024k count=200
200+0 records in
200+0 records out
% time seconds usecs/call calls function
------ ----------- ----------- --------- --------------------
99.86 14.597554 72987 200 read
0.10 0.015150 75 200 write
0.01 0.000947 473 2 dcgettext
0.01 0.000871 435 2 fprintf
0.00 0.000634 634 1 setlocale
FC5:
[root@donkey ~]# ltrace -c dd if=/dev/hdb of=/dev/null skip=400
bs=1024k count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 9.49944 seconds, 22.1 MB/s
% time seconds usecs/call calls function
------ ----------- ----------- --------- --------------------
99.81 27.460675 137303 200 read
0.12 0.032411 32411 1 dcgettext
0.05 0.014069 70 200 write
0.00 0.000908 302 3 __fprintf_chk
FC5 rebooted, with hald stopped:
[root@donkey init.d]# ltrace -c dd if=/dev/hdb of=/dev/null skip=400
bs=1024k count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 8.83107 seconds, 23.7 MB/s
% time seconds usecs/call calls function
------ ----------- ----------- --------- --------------------
99.93 26.791861 133959 200 read
0.05 0.014154 70 200 write
0.00 0.000925 925 1 dcgettext
0.00 0.000856 285 3 __fprintf_chk
Note the usecs/call comparison for read()...
[Also note how the ltrace output is wrong in terms of absolute
timing - approximately 3x the actual elapsed time]
Thanks,
--alessandro
"Dreamer ? Each one of us is a dreamer. We just push it down deep because
we are repeatedly told that we are not allowed to dream in real life"
(Reinhold Ziegler)
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: James Courtier-Dutton @ 2006-04-08 16:28 UTC (permalink / raw)
To: Andi Kleen; +Cc: Robert Hancock, linux-kernel
In-Reply-To: <200604080917.39562.ak@suse.de>
Andi Kleen wrote:
> On Saturday 08 April 2006 16:05, Robert Hancock wrote:
>> Andi Kleen wrote:
>>> James Courtier-Dutton <James@superbug.co.uk> writes:
>>>> Now, the question I have is, if I write values to RAM, do any of those
>>>> values survive a reset?
>>> They don't generally.
>>>
>>> Some people used to write the oopses into video memory, but that
>>> is not portable.
>> I wouldn't think most BIOSes these days would bother to clear system RAM
>> on a reboot. Certainly Microsoft was encouraging vendors not to do this
>> because it slowed down system boot time.to
>
> Reset button is like a cold boot and it generally ends up with cleared
> RAM.
>
> -Andi
Thank you. That saved me 30mins hacking. :-)
^ permalink raw reply
* Re: [PATCH 2.6.16] Shared interrupts sometimes lost
From: Lee Revell @ 2006-04-08 16:31 UTC (permalink / raw)
To: Neil Brown; +Cc: linux-kernel
In-Reply-To: <17463.14285.31029.943738@cse.unsw.edu.au>
On Sat, 2006-04-08 at 14:10 +1000, Neil Brown wrote:
>
> To explain what I think is happening, let me start with a very simple
> case. A number of PCI devices (this one included) have a number of
> events which can trigger an interrupt. The events which are current
> are presented as bits in a register, and are ORed together (and
> possibly masked by another register) to make the IRQ line.
> When 1's are written to any bits in this register, it acknowledges
> the event and clears the bit.
> A typical code fragment is
> events = read_register(INTERRUPTS);
> write_register(INTERRUPTS, events);
> ... handle each 1 bits in events ....
>
Isn't a more typical IRQ handler:
while (events = read_register(INTERRUPTS) != 0) {
...handle each bit in events and ACK it...
}
Lee
^ permalink raw reply
* Watch problems
From: Steve Grubb @ 2006-04-08 16:32 UTC (permalink / raw)
To: linux-audit
Hi,
I was testing the new watch system and ran across some problems. When I loaded
85 watches + 10 syscall rules, I got this when trying to list them back out:
[root@localhost watch-perf]# auditctl -l
Error receiving audit netlink packet (No buffer space available)
Error sending rule list request (No buffer space available)
And when I try to add a watch against a file in my home directory, I get this:
[root@localhost watch-perf]# auditctl -w /root/test/watch-perf/error.txt
Error sending add rule request (Permission denied)
If I move the same file to /etc, it works fine. I ran strace to see where this
is coming from:
sendto(3, "@\4\0\0\363\3\5\0\1\0\0\0\0\0\0\0\4\0\0\0\2\0\0\0\1\0\0"..., 1088,
0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 1088
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 100) = 1
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\261\10\0\0\363\377\377\377@\4\0"...,
8476,
MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) =
36
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\261\10\0\0\363\377\377\377@\4\0"...,
8476,
MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36
write(2, "Error sending add rule request ("..., 50Error sending add rule
request (Permission denied)) = 50
Looks like the kernel to me. This is using the lspp.16 kernel.
-Steve
^ permalink raw reply
* Re: 40% IDE performance regression going from FC3 to FC5 with same kernel
From: Arjan van de Ven @ 2006-04-08 16:36 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: Linux Kernel
In-Reply-To: <5a4c581d0604080927g532b6d10y7992d9adb4e63d08@mail.gmail.com>
On Sat, 2006-04-08 at 18:27 +0200, Alessandro Suardi wrote:
> On 4/8/06, Arjan van de Ven <arjan@infradead.org> wrote:
> >
> > > Just for the record - no, even rebuilding same kernel with same GCC
> > > (3.4.4) under FC5, disk performance is much slower than FC3 -
> > > according to hdparm _and_ dd tests.
> >
> > what happens if you kill hald and other inotify using animals?
>
> Thanks Arjan for looking into this.
>
> Stopping hald brings hdparm from 18.5MB/s to 20MB/s, which is
> indeed a noticeable improvement, though still far from the FC3
> performance. I'm unsure what else can be stopped however
> from this process list:
>
> 274 ? S<s 0:00 /sbin/udevd -d
try killing that one next; it may or may not help but it's sure worth a
try (esp given the success of the first kill :)
^ permalink raw reply
* Re: [Xenomai-core] [BUG?] stalled xeno domain
From: Jan Kiszka @ 2006-04-08 16:38 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
In-Reply-To: <4437D2EE.4040902@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 9171 bytes --]
Jan Kiszka wrote:
> Hi Philippe,
>
> debugging is nice, tracing is still nicer. As you suggested, I extended
> the tracer with per-domain stall flags (needs some output clean-up,
> preliminary patch attached nevertheless).
>
> And here is the result (full trace attached):
>
>> :| (0x51) 0x000000c8 -1113+ 1.112 __ipipe_sync_stage+0x142 (ipipe_suspend_domain+0x56)
>> :| fn -1112+ 1.789 __ipipe_sync_stage+0xe (ipipe_suspend_domain+0x56)
>> :| *(0x50) 0x00000064 -1110+ 1.293 __ipipe_sync_stage+0x97 (ipipe_suspend_domain+0x56)
>> : *fn -1109+ 1.398 do_IRQ+0x8 (__ipipe_sync_stage+0xcf)
>> : *fn -1107+ 2.105 __do_IRQ+0xc (do_IRQ+0x21)
>> : *fn -1105+ 1.631 handle_IRQ_event+0xd (__do_IRQ+0x9e)
>> : *fn -1104+ 2.413 timer_interrupt+0x9 (handle_IRQ_event+0x40)
>> : *fn -1101+ 3.022 mark_offset_tsc+0xe (timer_interrupt+0x31)
>> : *fn -1098+ 2.721 do_timer+0x9 (timer_interrupt+0x37)
>> :| *fn -1096+ 2.112 __ipipe_handle_irq+0xe (common_interrupt+0x18)
>> :| *fn -1093+ 1.210 __ipipe_ack_common_irq+0xc (__ipipe_handle_irq+0xc0)
>> :| *(0x50) 0x00000064 -1092+ 1.218 __ipipe_ack_common_irq+0x31 (__ipipe_handle_irq+0xc0)
>> :| *fn -1091+ 1.834 mask_and_ack_8259A+0xb (__ipipe_ack_common_irq+0x5d)
>> :| *(0x50) 0x00000064 -1089+ 1.345 __ipipe_ack_common_irq+0x9d (__ipipe_handle_irq+0xc0)
>> :| *fn -1088 0.924 ipipe_suspend_domain+0xb (__ipipe_handle_irq+0x174)
>> :| *(0x51) 0x000000c8 -1087+ 1.172 ipipe_suspend_domain+0x26 (__ipipe_handle_irq+0x174)
>> :| *fn -1086+ 2.030 __ipipe_sync_stage+0xe (ipipe_suspend_domain+0x56)
>> :| **(0x50) 0x000000c8 -1084+ 1.330 __ipipe_sync_stage+0x97 (ipipe_suspend_domain+0x56)
>> :| **fn -1082 0.879 xnintr_clock_handler+0x8 (__ipipe_sync_stage+0x12b)
>> :| **fn -1082+ 1.218 xnintr_irq_handler+0xb (xnintr_clock_handler+0x18)
>> :| **fn -1080+ 1.233 xnpod_announce_tick+0x9 (xnintr_irq_handler+0x2a)
>> :| **(0x50) 0x000000c8 -1079+ 1.736 xnpod_announce_tick+0x20 (xnintr_irq_handler+0x2a)
>> :| **fn -1077+ 2.984 xntimer_do_tick_aperiodic+0xe (xnpod_announce_tick+0x36)
>> :| **fn -1074+ 2.751 xnthread_timeout_handler+0x8 (xntimer_do_tick_aperiodic+0x18d)
>> :| **fn -1072+ 1.864 xnpod_resume_thread+0xe (xnthread_timeout_handler+0x1d)
>> :| **(0x50) 0x000000c8 -1070+ 4.699 xnpod_resume_thread+0x2b (xnthread_timeout_handler+0x1d)
>> :| **(0x50) 0x000000c8 -1065+ 1.586 xnpod_resume_thread+0x2bf (xnthread_timeout_handler+0x1d)
>> :| **(0x01) 0x00001237 -1063+ 2.661 xntimer_do_tick_aperiodic+0x309 (xnpod_announce_tick+0x36)
>> :| **(0x50) 0x000000c8 -1061+ 1.263 xnpod_announce_tick+0x4f (xnintr_irq_handler+0x2a)
>> :| **fn -1060+ 1.255 rthal_irq_end+0x8 (xnintr_irq_handler+0x46)
>> :| **fn -1058+ 2.007 enable_8259A_irq+0x9 (rthal_irq_end+0x2e)
>> :| **fn -1056+ 1.924 xnpod_schedule+0xe (xnintr_irq_handler+0x6e)
>> :| **(0x50) 0x000000c8 -1054! 15.368 xnpod_schedule+0x53 (xnintr_irq_handler+0x6e)
>> :| **fn -1039! 13.300 __switch_to+0xc (xnpod_schedule+0x689)
>> :| **(0x50) 0x000000c8 -1026+ 1.766 xnpod_schedule+0x951 (xnpod_suspend_thread+0x27c)
>> :| **(0x50) 0x000000c8 -1024! 18.195 xnpod_suspend_thread+0x2bb (rt_task_sleep+0x54)
>> : **fn -1006+ 1.624 __ipipe_syscall_root+0x9 (system_call+0x20)
>> : **fn -1004+ 1.406 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x58)
>> : **fn -1003+ 4.323 hisyscall_event+0xe (__ipipe_dispatch_event+0x5e)
>> : **fn -998+ 1.398 __rt_task_sleep+0xa (hisyscall_event+0x23c)
>> : **fn -997+ 1.789 __copy_from_user_ll+0xa (__rt_task_sleep+0x1a)
>> : **fn -995! 15.345 rt_task_sleep+0xa (__rt_task_sleep+0x25)
>> : **fn -980 0.879 __ipipe_syscall_root+0x9 (system_call+0x20)
>> : **fn -979+ 1.308 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x58)
>> : **fn -978+ 2.451 hisyscall_event+0xe (__ipipe_dispatch_event+0x5e)
>> : **fn -975+ 1.631 sys_rtdm_ioctl+0x8 (hisyscall_event+0x23c)
>> : **fn -974+ 1.255 _rtdm_ioctl+0xc (sys_rtdm_ioctl+0x1b)
>> : **fn -972+ 4.180 rtdm_context_get+0xa (_rtdm_ioctl+0x20)
>> : **fn -968+ 1.203 __ipipe_syscall_root+0x9 (system_call+0x20)
>> : **fn -967+ 1.345 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x58)
>
> The '*' mark a stalled domain, root domain on the right. It seems to me
> that xnpod_suspend_thread() leaves the xeno domain stalled on wake up.
> This gets recovered somehow later.
>
> But here we see a different effect which finally causes the tick to get
> frozen:
>
>> : fn -504+ 2.075 sched_clock+0xd (schedule+0x112)
>> : fn -502 0.992 __ipipe_stall_root+0x8 (schedule+0x18e)
>> : *(0x50) 0x00000064 -501+ 4.022 __ipipe_stall_root+0x32 (schedule+0x18e)
>> : *fn -497+ 1.977 __ipipe_dispatch_event+0xe (schedule+0x412)
>> : *fn -495+ 4.210 schedule_event+0xd (__ipipe_dispatch_event+0x5e)
>> : **(0x50) 0x000000c8 -491+ 1.428 schedule_event+0x261 (__ipipe_dispatch_event+0x5e)
>> :| **fn -490+ 2.067 xnpod_schedule_runnable+0xe (schedule_event+0x28b)
>> :| **fn -488 0.954 ipipe_unstall_pipeline_from+0xc (schedule_event+0x2c1)
>> :| *(0x51) 0x000000c8 -487+ 4.646 ipipe_unstall_pipeline_from+0x25 (schedule_event+0x2c1)
>> :| *fn -482+ 7.248 __switch_to+0xc (xnpod_schedule+0x689)
>> :| **(0x50) 0x000000c8 -475+ 1.421 xnpod_schedule+0x77f (xnpod_suspend_thread+0x27c)
>> :| **(0x50) 0x000000c8 -473+ 1.481 xnpod_schedule+0x951 (xnpod_suspend_thread+0x27c)
>> :| **(0x50) 0x000000c8 -472+ 1.654 xnpod_suspend_thread+0x2bb (xnshadow_relax+0x136)
>> :| **(0x50) 0x000000c8 -470+ 2.917 xnshadow_relax+0x154 (hisyscall_event+0x2ec)
>> :| **fn -467+ 1.375 ipipe_reenter_root+0xb (xnshadow_relax+0x204)
>> :| **fn -466 0.954 __ipipe_unstall_root+0x8 (ipipe_reenter_root+0x26)
>> :| * (0x51) 0x00000064 -465+ 3.789 __ipipe_unstall_root+0x25 (ipipe_reenter_root+0x26)
>> : * fn -461+ 1.578 send_sig+0x8 (xnshadow_relax+0x228)
>> : * fn -460+ 1.496 send_sig_info+0xb (send_sig+0x1d)
>> : * fn -458 0.909 __ipipe_test_and_stall_root+0x9 (send_sig_info+0x38)
>> : **(0x50) 0x00000064 -457+ 1.699 __ipipe_test_and_stall_root+0x27 (send_sig_info+0x38)
>> : **fn -455+ 1.203 specific_send_sig_info+0xb (send_sig_info+0x69)
>> : **fn -454+ 1.706 __ipipe_test_root+0x8 (specific_send_sig_info+0x16)
>> : **fn -453+ 3.360 sig_ignored+0x9 (specific_send_sig_info+0x29)
>> : **fn -449+ 1.714 send_signal+0xb (specific_send_sig_info+0x55)
>> : **fn -447+ 3.142 __sigqueue_alloc+0x9 (send_signal+0x3f)
>> : **fn -444+ 1.210 kmem_cache_alloc+0xa (__sigqueue_alloc+0x42)
>> : **fn -443 0.909 __ipipe_test_and_stall_root+0x9 (kmem_cache_alloc+0x12)
>> : **(0x50) 0x00000064 -442+ 2.180 __ipipe_test_and_stall_root+0x27 (kmem_cache_alloc+0x12)
>> : **fn -440+ 1.218 __ipipe_restore_root+0x8 (kmem_cache_alloc+0x52)
>> : **fn -439+ 1.315 __ipipe_stall_root+0x8 (__ipipe_restore_root+0x11)
>
> No more recovery from the xeno stall, no more timer ticks.
>
> The special traces were generated via
>
> #define ipipe_mark_domain_stall(ipd,cpuid) \
> ipipe_trace_special(0x50, ipd->priority)
> #define ipipe_mark_domain_unstall(ipd,cpuid) \
> ipipe_trace_special(0x51, ipd->priority)
>
> Any ideas? I do not find anything fishy yet that we may have introduced
> to cause this problem.
>
Hmm, what about this theory: the RT-thread which got woken up in the
first trace snippet suffered from a leaking IRQ lock. Its broken flags
got restored on wakeup, and also when the thread went for termination
(second trace). Therefore, we see this leaking domain stall. Possible
explanation?
This would move I-pipe and Xenomai out of the focus, leaving only the
16550A driver and our middleware messaging service (also a RTDM driver,
currently my top favourite). My trace unfortunately does not last back
far enough to answer this, I will have a look at this on Monday.
If it turned out to be the reason, we should consider putting some
XENO_ASSERT guards in the return-to-user paths of RTDM services.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: Lee Revell @ 2006-04-08 16:40 UTC (permalink / raw)
To: James Courtier-Dutton; +Cc: linux list
In-Reply-To: <44379AB8.6050808@superbug.co.uk>
On Sat, 2006-04-08 at 12:12 +0100, James Courtier-Dutton wrote:
> The main advantage of something like this would be for newer
> motherboards that are around now that don't have a serial port.
Did you try netconsole and/or the 1394 based remote debug solution that
was recently posted to LKML (that I now can't find in my mail)?
Lee
^ permalink raw reply
* Re: ipt_unclean query
From: Phil Oester @ 2006-04-08 16:44 UTC (permalink / raw)
To: Sumit; +Cc: netfilter-devel
In-Reply-To: <44376F11.4000804@elitecore.com>
On Sat, Apr 08, 2006 at 01:36:41PM +0530, Sumit wrote:
> Hi Devs,
> After making an unclean DROP ruleset I got "not-working" complains
> form some of my clients who using specific stock-trading application.
Unclean is unsafe, and is scheduled to be removed from pom within the
next 30 days. Don't use it.
Phil
^ permalink raw reply
* Re: patch : hdaps on Thinkpad R52
From: Frank Gevaerts @ 2006-04-08 16:53 UTC (permalink / raw)
To: Jean Delvare; +Cc: Robert Love, linux-kernel
In-Reply-To: <20060408170238.4e241eac.khali@linux-fr.org>
On Sat, Apr 08, 2006 at 05:02:38PM +0200, Jean Delvare wrote:
> Hi Franck,
>
> Sorry for the late answer...
>
> > > OK, so as strange as it sounds, that's really the string as stored in
> > > the DMI table. How odd... You have to understand that I'm a bit
> > > reluctant to adding it officially to the hdaps driver, given that it
> > > clearly looks like a bogus table in your laptop. I guess that you only
> > > have one laptop with this string?
> >
> > I just had a mail from another R52 user, reporting that his system
> > (also 1846AQG) also reports ThinkPad H.
>
> I gathered data on my side too, the three R52 I had reports for used
> "ThinkPad R52" but these had different machine type/model. I guess that
> the 1846AQG is somehow different, but probably you don't know why?
No.
> So I suppose we could add that "ThinkPad H" identifier string to the
> hdaps driver after all, as you proposed in the first place. I'm only
> worried that the "H" suffix is really short, and I hope that no other
> model not supported by the driver (or needing the invert option) will
> ever have the same identifier. Time will tell.
If it turns out to be a problem, the best solution might be to also
(optionally) check the 'Product Name' field. I don't know how hard this
would be.
Frank
> Thanks,
> --
> Jean Delvare
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
^ permalink raw reply
* Re: [BUG] 2.6.16.2 (like olders) fails to suspend audio device
From: Patrizio Bassi @ 2006-04-08 16:53 UTC (permalink / raw)
To: Lee Revell; +Cc: Kernel,, alsa-devel
In-Reply-To: <1144513623.22490.150.camel@mindpipe>
Lee Revell ha scritto:
> It would help if you cc'ed the right list (added)
>
> On Sat, 2006-04-08 at 15:31 +0200, Patrizio Bassi wrote:
>
>> I've already posted same bug some weeks ago.
>>
>> this is just a reminder and to confirm bug is still there.
>>
>> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>>
>> Alsa driver: 1370
>>
>> 1) if builtin in kernel, on resume it doesn't work any more.
>> 2) if built as module on resume it works with no need to remove/readd
>> module.
>>
>> in both situations dmesg shows:
>>
>> pnp: Failed to activate device 00:0b.
>>
>>
>> Stopping tasks: ===========================================|
>> Shrinking memory... done (39214 pages freed)
>> pnp: Device 00:0c disabled.
>> pnp: Device 00:08 disabled.
>> swsusp: Need to copy 13752 pages
>> ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 5 (level, low)
>> -> IRQ 5
>> ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:0a.2[C] -> Link [LNKA] -> GSI 11 (level,
>> low) -> IRQ 11
>> usb usb1: root hub lost power or was reset
>> ehci_hcd 0000:00:0a.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
>> ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level,
>> low) -> IRQ 10
>> pnp: Device 00:08 activated.
>> pnp: Failed to activate device 00:0b.
>> pnp: Device 00:0c activated.
>> Restarting tasks... done
>> agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
>> agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode
>> agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode
>>
>> lspci
>> 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
>> bridge (rev 03)
>> 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP
>> bridge (rev 03)
>> 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
>> 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
>> 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
>> 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
>> 00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
>> (rev 74)
>> 00:0a.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>> Controller (rev 50)
>> 00:0a.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>> Controller (rev 50)
>> 00:0a.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
>> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP
>>
>>
>> dmesg says 00:08 and 00:0c are activated..but i've no idea which devices
>> they are, lspci -vv shows nothing about that.
>>
>> Ready to give more infos and test patches.
>>
>> Patrizio Bassi
>>
>>
>
you're right, sorry, but, having the strange devices in dmesg let me
think that's a problem
in suspend too.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [BUG] 2.6.16.2 (like olders) fails to suspend audio device
From: Patrizio Bassi @ 2006-04-08 16:53 UTC (permalink / raw)
To: Lee Revell; +Cc: Kernel,, alsa-devel
In-Reply-To: <1144513623.22490.150.camel@mindpipe>
Lee Revell ha scritto:
> It would help if you cc'ed the right list (added)
>
> On Sat, 2006-04-08 at 15:31 +0200, Patrizio Bassi wrote:
>
>> I've already posted same bug some weeks ago.
>>
>> this is just a reminder and to confirm bug is still there.
>>
>> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>>
>> Alsa driver: 1370
>>
>> 1) if builtin in kernel, on resume it doesn't work any more.
>> 2) if built as module on resume it works with no need to remove/readd
>> module.
>>
>> in both situations dmesg shows:
>>
>> pnp: Failed to activate device 00:0b.
>>
>>
>> Stopping tasks: ===========================================|
>> Shrinking memory... done (39214 pages freed)
>> pnp: Device 00:0c disabled.
>> pnp: Device 00:08 disabled.
>> swsusp: Need to copy 13752 pages
>> ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 5 (level, low)
>> -> IRQ 5
>> ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKD] -> GSI 9 (level, low)
>> -> IRQ 9
>> ACPI: PCI Interrupt 0000:00:0a.2[C] -> Link [LNKA] -> GSI 11 (level,
>> low) -> IRQ 11
>> usb usb1: root hub lost power or was reset
>> ehci_hcd 0000:00:0a.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
>> ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level,
>> low) -> IRQ 10
>> pnp: Device 00:08 activated.
>> pnp: Failed to activate device 00:0b.
>> pnp: Device 00:0c activated.
>> Restarting tasks... done
>> agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
>> agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode
>> agpgart: Putting AGP V2 device at 0000:01:00.0 into 2x mode
>>
>> lspci
>> 00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host
>> bridge (rev 03)
>> 00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP
>> bridge (rev 03)
>> 00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
>> 00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
>> 00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
>> 00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
>> 00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
>> (rev 74)
>> 00:0a.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>> Controller (rev 50)
>> 00:0a.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
>> Controller (rev 50)
>> 00:0a.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
>> 00:0b.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>> 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP
>>
>>
>> dmesg says 00:08 and 00:0c are activated..but i've no idea which devices
>> they are, lspci -vv shows nothing about that.
>>
>> Ready to give more infos and test patches.
>>
>> Patrizio Bassi
>>
>>
>
you're right, sorry, but, having the strange devices in dmesg let me
think that's a problem
in suspend too.
^ permalink raw reply
* Re: [PATCH] Fix mm regression bug: nommu use compound page in slab allocator
From: Pekka Enberg @ 2006-04-08 16:55 UTC (permalink / raw)
To: Luke Yang; +Cc: Nick Piggin, Andrew Morton, linux-kernel
In-Reply-To: <489ecd0c0603301811u3c8b6ac3lbe03a93a92bebf44@mail.gmail.com>
Hi Luke,
On 3/31/06, Luke Yang <luke.adi@gmail.com> wrote:
> The earlier patch to consolidate mmu and nommu page allocation
> and refcounting by using compound pages for nommu allocations
> had a bug: kmalloc slabs who's pages were initially allocated
> by a non-__GFP_COMP allocator could be passed into mm/nommu.c
> kmalloc allocations which really wanted __GFP_COMP underlying
> pages. Fix that by having nommu pass __GFP_COMP to all higher order
> slab allocations.
Any reason we are not doing this for CONFIG_MMU as well? We could then
fix the slab callers to not pass __GFP_COMP at all which seems broken
anyway.
Pekka
> Signed-off-by: Luke Yang <luke.adi@gmail.com>
> Acked-by: Nick Piggin <npiggin@suse.de>
>
> slab.c | 4 ++++
> 1 files changed, 4 insertions(+)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 4cbf8bb..388a6a9 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1454,7 +1454,11 @@ static void *kmem_getpages(struct kmem_c
> int i;
>
> flags |= cachep->gfpflags;
> +#ifdef CONFIG_MMU
> page = alloc_pages_node(nodeid, flags, cachep->gfporder);
> +#else
> + page = alloc_pages_node(nodeid, (flags | __GFP_COMP), cachep->gfporder);
> +#endif
> if (!page)
> return NULL;
> addr = page_address(page);
^ permalink raw reply
* Annuncio
From: EsseGi @ 2006-04-08 17:03 UTC (permalink / raw)
Gentile utente,
ho letto il suo annuncio e con la presente le chiedo l'autorizzazione per presentarvi questa mia eccezionale attivitа di guadagno.
Si tratta di un metodo poco impegnativo e che nel tempo dа degli interessanti profitti.
Guadagni senza investire nulla
Questa volta non dovrete spendere neanche 1centesimo!!! Basta solo
usare questo link
http://www.monthlypayday.com//index.php?id=4336
e registrarsi con un nome utente e pass personale (con cui accederete al sito),
mettere il vostro indirizzo di account PayPal (l'e-mail con> cui siete
registrati su www.paypal.it (se non lo siete ancora registratevi,
и gratuito) attraverso cui ricevete i pagamenti!
Ora seguite questi passaggi molto semplici qui sotto:
1. Registratevi cliccando su queso link:
http://www.monthlypayday.com//index.php?id=4336
e cliccate su join free che si trova in alto a sinistra..
2. Inserite username e pass personali con cui accederete al vostro
account.
3. Copiate il vostro link personale nella sezione "Refferral info"
e cercatein qualsiasi modo (dipende dalle vostre abilitа) di far registrare
+ utenti possibili con il vostro link!
Descrizione dei pagamenti:
ogni membro che riuscite a far registrare vi farа guadagnare 20$!!!
IL BELLO DI QUESTO SISTEMA E? CHE NON PAGHERETE NULLA SIA PER L'ISCRIZIONE
E SIA SE NON RIUSCIRETE A FAR REGISTRARE NESSUNO! UN UNICA COSA AVVIENE
SOLO QUANDO AVRETE FATTO REGISTRARE I PRIMI 3 MEMBRI: DA QUI IN POI OGNI MESE
PUNTUALMENTE ANCHE SE NON FATE REGISTRARE + NESSUNO GUADAGNERETE SEMPRE 60$!
PERO' 1 VOLTA AL MESE IL SITO TRATTIENE SOLAMENTE 20$ DAL GUADAGNO
(non vitoglie nulla!!!), ANCHE SE I VOSTRI MEMBRI REGISTRATI SIANO 500!
Questa mail non и spam in quanto il suo indirizzo e-mail и presente in siti pubblicamente consultabili (legge 675/96)
Il Vs. indirizzo di posta elettronica non й stato in alcun modo conservato ne trattato.
Il presente messaggio non sarа ripetuto con ulteriori invii.
^ permalink raw reply
* Re: 40% IDE performance regression going from FC3 to FC5 with same kernel
From: Alessandro Suardi @ 2006-04-08 17:07 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Linux Kernel
In-Reply-To: <1144514167.2989.10.camel@laptopd505.fenrus.org>
On 4/8/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2006-04-08 at 18:27 +0200, Alessandro Suardi wrote:
> > On 4/8/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > >
> > > > Just for the record - no, even rebuilding same kernel with same GCC
> > > > (3.4.4) under FC5, disk performance is much slower than FC3 -
> > > > according to hdparm _and_ dd tests.
> > >
> > > what happens if you kill hald and other inotify using animals?
> >
> > Thanks Arjan for looking into this.
> >
> > Stopping hald brings hdparm from 18.5MB/s to 20MB/s, which is
> > indeed a noticeable improvement, though still far from the FC3
> > performance. I'm unsure what else can be stopped however
> > from this process list:
> >
> > 274 ? S<s 0:00 /sbin/udevd -d
>
>
> try killing that one next; it may or may not help but it's sure worth a
> try (esp given the success of the first kill :)
killing udevd doesn't bring any improvement - still at 20MB/s.
Do you want me to file a FC5 bugzilla entry with the current info
or do you think there is something else that can be discussed
on lkml ?
Thanks,
--alessandro
"Dreamer ? Each one of us is a dreamer. We just push it down deep because
we are repeatedly told that we are not allowed to dream in real life"
(Reinhold Ziegler)
^ permalink raw reply
* [Qemu-devel] qemu exec.c
From: Paul Brook @ 2006-04-08 17:14 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Paul Brook <pbrook@savannah.gnu.org> 06/04/08 17:14:56
Modified files:
. : exec.c
Log message:
Fix breakpoint TLB invalidation.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/exec.c.diff?tr1=1.74&tr2=1.75&r1=text&r2=text
^ permalink raw reply
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Oleg Nesterov @ 2006-04-08 21:13 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <m1r748jbju.fsf@ebiederm.dsl.xmission.com>
On 04/08, Eric W. Biederman wrote:
> Oleg Nesterov <oleg@tv-sign.ru> writes:
>
> > This change can confuse next_tid(), but this is minor.
> > I don't see other problems.
>
> next_tid?
proc_task_readdir:
first_tid() returns old_leader
next_tid() returns new_leader
de_thread:
old_leader->group_leader = new_leader;
next_rid() returns old_leader again,
because it is not thread_group_leader()
anymore
> This means your patch doesn't go far enough. We should be
> able to kill all of the parent list manipulation in
> de_thread. Doing reduces the places that assign
> real_parent to just fork and exit.
Yes!
I think I understand why we had the reason to reparent 'leader'
in the past. We used to set leader->exit_state = EXIT_ZOMBIE,
so without reparenting current's parent could have a bogus do_wait()
result if this do_wait() happens before release_task(leader).
Now we set leader->exit_state = EXIT_DEAD, which means this task
is not visible to do_wait().
Oleg.
^ permalink raw reply
* Re: [patch] represent-dirty__centisecs-as-jiffies-internally.patch comment fix
From: Bart Samwel @ 2006-04-08 17:16 UTC (permalink / raw)
To: Coywolf Qi Hunt; +Cc: linux-kernel, Andrew Morton
In-Reply-To: <2cd57c900604080310l454eec24m7298e01001f132af@mail.gmail.com>
Coywolf Qi Hunt wrote:
> 2006/3/25, akpm@osdl.org <akpm@osdl.org>:
>
>> From: Bart Samwel <bart@samwel.tk>
>>
>> Make that the internal values for:
>>
>> /proc/sys/vm/dirty_writeback_centisecs
>> /proc/sys/vm/dirty_expire_centisecs
>>
>> are stored as jiffies instead of centiseconds. Let the sysctl interface do
>> the conversions with full precision using clock_t_to_jiffies, instead of
>> doing overflow-sensitive on-the-fly conversions every time the values are
>> used.
>
>> diff -puN mm/page-writeback.c~represent-dirty__centisecs-as-jiffies-internally mm/page-writeback.c
>> --- devel/mm/page-writeback.c~represent-dirty__centisecs-as-jiffies-internally 2006-03-24 03:00:41.000000000 -0800
>> +++ devel-akpm/mm/page-writeback.c 2006-03-24 03:00:41.000000000 -0800
>> @@ -75,12 +75,12 @@ int vm_dirty_ratio = 40;
>> * The interval between `kupdate'-style writebacks, in centiseconds
>> * (hundredths of a second)
>
> Bart,
>
> You forgot to fix the comments. The attached patch fixes them.
Thanks, well spotted. I think the other patch already went into Linus'
tree, I guess this should go in there as well?
Cheers,
Bart
^ permalink raw reply
* Re: kernel vs user power management
From: Holger Macht @ 2006-04-08 17:18 UTC (permalink / raw)
To: Brown, Len; +Cc: thoenig, linux-acpi, linux-laptop, Andi Kleen
In-Reply-To: <CFF307C98FEABE47A452B27C06B85BB622B194@hdsmsx411.amr.corp.intel.com>
On Sat 08. Apr - 02:42:12, Brown, Len wrote:
> Timo, Holger,
> Andi pointed me to your FOSDEM Linux Power Management presentation:
>
> http://en.opensuse.org/FOSDEM2006
>
> http://files.opensuse.org/opensuse/en/b/b5/One_step_opendesign.pdf
>
> And I'm glad to see you working on Linux Power Management.
>
> But I'm a little concerned that user-space and the kernel are
> a little out of sync on a few things.
>
> I'm happy to see that the userspace p-state governor
> is no longer enabled by default on SuSE systems.
> While it was passable on servers with steady-state
> workloads, it was very bad for laptops where the
> machine spends a lot of time idle, but has short
> bursts of processing need which userspace could
> not detect. These laptops would spend virtually
> all their time in Pn when using the userspace governor.
To be honest, this observation suprises me a little bit. We did some
measurements with userspace agains ondemand governor some time ago and did
not notice any big differences in the results between them. Well, these
tests are about 1 1/2 years ago, though, and there went some changes into
the kernel until now ;-)
Nevertheless, we adjust the sampling rate in any case and currently set it
to 333 milliseconds (that's configurable). We noticed if we use the
default ondemand setting, the ondemand governor increases the frequency
too often although there is not much to do which is also not helpful. But
333 milliseconds is maybe a bit too high, it's taken because of historical
reasons. This value _was_ the default interval of our main event loop. I
think I will lower it a bit.
Furthermore, we had some problems on multiprocessor systems in the past
(about 1/2 year ago) with the ondemand governor. After some time the
system was running (even some hours or even days) the machine locked up
hard. Thus, we set the userspace governor by default on those systems
where we never experienced such problems. At the moment I did only get one
similar report where the root cause is not clear. So I stick to the
ondemand governor in any case in newer releases. And such lockups are
really hard to reproduce and to debug.
Another argument was that speedstep_ich was not yet ready for ondemand
which it is now IIRC.
>
> The next step is to delete the userspace governor
> as a valid governor selection entirely. If somebody
> really wants manual control, they can still set the
> limits within which "ondemand" will stay.
In current code, I always try to use the ondemand governor at first and if
that fails we automatically switch to the userspace implementation at
runtime. This way has the advantage that we always get a working cpu
frequency scaling support.. But it also has one big disadvantage, we do
not get reports about not working ondemand governor so maybe we simply did
not notice the improvements in this area. For our stable releases, I will
keep the current inplementation. For the unstable one, I will disable the
autoswitching code and if it still works good then for a few month, I will
remove the userspace implementation completely. It should not hurt to let
the code in for some time and remove the visible configuration option,
just to have fallback under strange circumstances. Would this be ok with
you?
> I'm happy to see that clock throttling is not enabled by
> default in recent SuSE release, at least on my laptop
> which supports P-states.
>
> I'd like to see no option to enable clock-throttling on
> systems that support real p-states.
Yes, this is reasonable, indeen. Will do that. With p-states in this
context, you mean cpufreq here?
>
> It is useful only for workloads which have an infinite
> amount of non-idle computing which you don't care how
> slow it computes. For the vast majority of workloads
> it just slows down the machine and delays the processor
> from getting into idle where it can save a non-linear
> amount of power. Further, there exist today systems which
> will consume MORE power in deep C-states when throttled
> vs. when not throttled.
>
> The other major topic is the user/kernel interface
> for power management policy. there needs to be in-kernel
> state for this, else the device drivers will have no low-latency
> way to get the answer to the simple policy question of how they should
> optimize for performance vs power at any given instant when they
> recognize their device is idle.. this state should be controlled
> by user space, but I think it is most practical for it to
> be kernel resident.
I'm not sure if I completely understand what you mean here. Do you mean
the so called "runtime device power management"?
If so, I fully agree with you. But I do not set a specific policy in the
powersave code explicitely for that feature. If the policy information
will go into the kernel, I will use and set this one, of course.
>
> thanks,
> -Len
Regards,
Holger
^ permalink raw reply
* Re: [PATCH] xdiff/xdiffi.c: fix warnings about possibly uninitialized variables
From: Davide Libenzi @ 2006-04-08 17:18 UTC (permalink / raw)
To: Marco Roeland; +Cc: git
In-Reply-To: <20060408152720.GA11125@fiberbit.xs4all.nl>
On Sat, 8 Apr 2006, Marco Roeland wrote:
> Compiling this module gave the following warnings (some double dutch!):
>
> xdiff/xdiffi.c: In functie 'xdl_recs_cmp':
> xdiff/xdiffi.c:298: let op: 'spl.i1' may be used uninitialized in this function
> xdiff/xdiffi.c:298: let op: 'spl.i2' may be used uninitialized in this function
> xdiff/xdiffi.c:219: let op: 'fbest1' may be used uninitialized in this function
> xdiff/xdiffi.c:219: let op: 'bbest1' may be used uninitialized in this function
>
> A superficial tracking of their usage, without deeper knowledge about the
> algorithm, indeed confirms that there are code paths on which these
> variables will be used uninitialized. In practice these code paths might never
> be reached, but then these fixes will not change the algorithm. If these
> code paths are ever reached we now at least have a predictable outcome. And
> should the very small performance impact of these initializations be
> noticeable, then they should at least be replaced by comments why certain
> code paths will never be reached.
These paths are never reached because of the way data is prepared before
and passed to the function. Unfortunately the compiler cannot know this.
Using them as -1 or XDL_LINE_MAX won't help either, since those are out of
domain values. You can leave it there and the algo won't suffer, or you
can relax a little the warning level when building the file.
- Davide
^ permalink raw reply
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Oleg Nesterov @ 2006-04-08 21:23 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20060408211308.GA1845@oleg>
On 04/09, Oleg Nesterov wrote:
>
> proc_task_readdir:
>
> first_tid() returns old_leader
>
> next_tid() returns new_leader
>
> de_thread:
> old_leader->group_leader = new_leader;
>
>
> next_rid() returns old_leader again,
> because it is not thread_group_leader()
> anymore
I think something like this for next_tid() is sufficient:
- if (thread_group_leader(pos))
+ if (pos->pid == pos->tgid)
We can also do the same change in first_tgid().
Oleg.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.