* 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: [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: 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: 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: 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: [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: 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
* 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: [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
* 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: 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: [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: [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
* 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: [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
* [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: Userland swsusp failure (mm-related)
From: Pavel Machek @ 2006-04-08 16:15 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Fabio Comolli, linux-kernel, Nick Piggin
In-Reply-To: <200604081716.31836.rjw@sisk.pl>
Hi!
> > This is my first (and unique) failure since I began testing uswsusp
> > (2.6.17-rc1 version). It happened (I think) because more than 50% of
> > physical memory was occupied at suspend time (about 550 megs out og
> > 1G) and that was what I was trying to test. After freeing some memory
> > suspend worked (there was no need to reboot).
>
> Well, it looks like we didn't free enough RAM for suspend in this case.
> Unfortunately we were below the min watermark for ZONE_NORMAL and
> we tried to allocate with GFP_ATOMIC (Nick, shouldn't we fall back to
> ZONE_DMA in this case?).
>
> I think we can safely ignore the watermarks in swsusp, so probably
> we can set PF_MEMALLOC for the current task temporarily and reset
> it when we have allocated memory. Pavel, what do you think?
Seems little hacky but okay to me.
Should not fixing "how much to free" computation to free a bit more be
enough to handle this?
Pavel
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply
* Re: iptables and mac filtering
From: Robert Nichols @ 2006-04-08 16:14 UTC (permalink / raw)
To: netfilter
In-Reply-To: <44377281.60706@ratel.ru>
vlad f halilow wrote:
>
> Hi there. Please help with strange issuse. I have debian woody with
> 2.6.12 kernel + iptables.1.3.3. (unstable) under vmware workstation. I
> try to block connection to my PPPoE server (rp-pppoe) by mac-address of
> client. something like
>
> #iptables -I INPUT -m mac --mac-source blablag -j DROP
>
> . Line inserted showed by iptables -L -v -n but not block any IP-less
> requests from address specified. Ping or any IP protocols blocking
> success, but pppoe discovery, exchange and traffic pass the filter
> wthout any problem with no rule countr increment. How i can fix this
> thing? Or what i to do wrong?
You said it yourself. These are IP-less requests. They never make
it up to the protocol levels where iptables operates. Yes, iptables
can match on MAC addresses, but if the packet is handled entirely
at the Data Link layer (MAC sublevel), iptables will never see it.
--
Bob Nichols Yes, "NOSPAM" is really part of my email address.
^ permalink raw reply
* [parisc-linux] bfd tls bug?
From: Carlos O'Donell @ 2006-04-08 16:14 UTC (permalink / raw)
To: Randolph Chung, parisc-linux
Randolph,
bfd/elf32-hppa.c
4168 need_relocs =3D TRUE;
4169 loc =3D htab->srelgot->contents;
4170 /* FIXME (CAO): Should this be reloc_count++ ? =
*/
4171 loc +=3D htab->srelgot->reloc_count * sizeof
(Elf32_External_Rela);
Should there be a reloc_count++ there?
Or is this taken into account earlier?
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
^ permalink raw reply
* Re: Fw: Re: 2.6.17-rc1-mm1 - detects buggy TSC on GEODE
From: Jordan Crouse @ 2006-04-08 16:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: johnstul, jim.cromie, linux-kernel
In-Reply-To: <20060407174129.67e0bc45.akpm@osdl.org>
On 07/04/06 17:41 -0700, Andrew Morton wrote:
>
> Sorry, I should have cc'ed you on this :(
No worries.
> > > 1. the new kernel is now detecting the buggy TSC on the GEODE-sc1100
> > > 2. the bug is apparently correctable by passing 'idle=poll' on kernel
> > > boot-line.
I am assuming that this is the problem where the TSC doesn't roll over
correctly on the SC1100 and SC1200.
> > John, does this mean that enable-tsc-for-amd-geode-gx-lx.patch is only safe
> > to merge after all your time-management patches have gone in?
If that is the case, then the enable-tsc-for-amd-geode-gx-lx.patch is still
safe since the TSC on the GX and LX doesn't have that same problem.
For what its worth, we used to have a fix for the TSC issue back
in the 2.4 days that looked something like this:
#ifdef CONFIG_GEODE_SC1200
#define rdtsc(low,high) \
__asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high)); \
if ((unsigned long) low > 0xFFFFFFFC) high--
#else
#define rdtsc(low,high) \
__asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high))
#endif
That seemed to work, but it is ugly, and I didn't bring it forward
when we moved to 2.6. Perhaps we can revive it if there are SC1100/SC1200
users who need it.
Thanks,
Jordan
--
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>
^ permalink raw reply
* Re: [PATCH rc1-mm] de_thread: fix deadlockable process addition
From: Eric W. Biederman @ 2006-04-08 16:07 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20060408172745.GA89@oleg>
Oleg Nesterov <oleg@tv-sign.ru> writes:
> On 04/08, Eric W. Biederman wrote:
>>
>> Agreed. That is ugly.
>
> Yes, I agree also.
>
>>
>> -#define thread_group_leader(p) (p->pid == p->tgid)
>> +#define thread_group_leader(p) (p == p->group_leader)
>>
>> ...
>>
>> - leader->group_leader = leader;
>> + leader->group_leader = current;
>
> I thought about similar change too, but I am unsure about
> release_task(old_leader)->proc_flush_task() path (because
> I don't understand this code).
proc_flush_task() is purely an optimization to kill the
proc dcache entries when a process exits. So we don't
plug up the dcache with old proc entries.
All it looks at currently and pid an tgid.
So proc_flush_task() should not be a non-issue.
proc_pid_unhash() in -linus is a little more
serious but it only unhashes things.
> This change can confuse next_tid(), but this is minor.
> I don't see other problems.
next_tid?
> However, I think we can do something better instead of
> attach_pid(current)/detach_pid(leader):
>
> void exec_pid(task_t *old, task_t * new, enum pid_type type)
> {
> new->pids[type].pid = old->pids[type].pid;
> hlist_replace_rcu(&old->pids[type].node, &new->pids[type].node);
> old->pids[type].pid = NULL;
> }
>
> So de_thread() can do
>
> exec_pid(leader, current, PIDTYPE_PGID);
> exec_pid(leader, current, PIDTYPE_SID);
>
> This allows us to iterate over pgrp/session lockless without
> seeing the same task twice, btw. But may be it is just unneeded
> complication.
I think it may be worthwhile. Currently we can't do any process
group or session traversal lockless so it isn't worth looking
at until we get the bug fix handled.
Ultimately I think I would like PGID and SID to live in ->signal
in which case we would not need to touch them at all.
>> This requires changing the leaders parents
>>
>> current->parent = current->real_parent = leader->real_parent;
>> - leader->parent = leader->real_parent = child_reaper;
>> + leader->parent = leader->real_parent = current;
>> current->group_leader = current;
>
> I don't understand why do we need this change.
I was just trying to come as close as I could to normal
thread semantics. The fewer special cases in de_thread,
the fewer problems it is.
> Actually, I think leader doesn't need reparenting at all.
> ptrace_unlink(leader) already restored leader->parent = ->real_parent
> and ->sibling. So I think we can do (for review only, should go in a
> separate patch) this:
Duh. All processes in a thread group share the same real_parent.
It looks like the only practical thing we accomplish
with remove_parent/add_parent is to change our place on
our parents list of children.
Since ptrace_link and ptrace_unlink already does this we don't have a
guaranteed order on that list, so skipping the order change
should definitely be safe.
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.
Eric
^ permalink raw reply
* Re: [LARTC] source routing does not work with extra ip addresses
From: Martin A. Brown @ 2006-04-08 16:07 UTC (permalink / raw)
To: lartc
In-Reply-To: <20060408123017.4a108613.mailinglists@lucassen.org>
Hello there,
: Now I put a server behind the Linux box. I want the server to be
: reachable on an /extra/ IP in the routed subnet of ISP2.
Does server have one or two IP addresses? Best solution? Use two
IP addresses on server.
: router ISP2: 1.2.3.1/24
: dev ISP2: eth1
: Linux box eth1: 1.2.3.2/24
: external ip ISP2 for server 10.0.0.2: 1.2.3.3
: arp -s 1.2.3.3 aa:bb:cc:dd:ee:ff pub
: ip route add 1.2.3.3 via 10.0.0.2
: iptables -t nat -A PREROUTING -i eth1 -d 1.2.3.3 -j DNAT --to 10.0.0.2
:
: When pinging 1.2.3.3, the packets get in through eth1 (ok), but the
: replies are following the default route through eth0 (wrong)
The problem is routing. Return packets from your server are handled
in the main routing table. There isn't yet an RPDB entry directing
traffic from 10.0.0.2 to use table_eth1. Your RPDB entry looks like
this:
: ip rule add from 1.2.3.3 lookup table_eth1
Try changing this (or adding another rule):
ip rule add from 10.0.0.2 lookup table_eth1
instead. Now, your server should have Internet access strictly on
the link handled by ISP2.
If you would like to handle inbound traffic on both links, then add
a secondary IP address to your server, and enter another DNAT rule
which specifies another NAT mapping for the secondary IP.
-Martin
--
Martin A. Brown --- Wonderfrog Enterprises --- martin@wonderfrog.net
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [lm-sensors] nForce 430 SMBus
From: Mark Rages @ 2006-04-08 16:06 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <74ee72ca0604071607l1c1063b2iad93659df1bfe3fa@mail.gmail.com>
On 4/8/06, Jean Delvare <khali at linux-fr.org> wrote:
>
> Hey, good work. lease provide the output of (as root):
> lspci -s 00:0a.1 -xxx
>
Here it is:
lspci -s 00:0a.1 -xxx
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a2)
00: de 10 64 02 01 00 b0 00 a2 00 05 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 06 00 00 01 07 00 00 00 00 00 00 de 10 84 cb
30: 00 00 00 00 44 00 00 00 00 00 00 00 05 01 00 00
40: de 10 84 cb 01 00 02 c0 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 05 00 00 01 08 00 00 01 09 00 00 00 00 00 00
70: 01 00 00 00 00 00 b8 fe 00 00 fe fe 01 20 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: d4 30 80 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 10 10 04 00 00 a0 90 00 80 30 00 00 41 44 44 11
f0: 5a ff 5f bf 00 00 00 c0 10 00 00 00 00 00 00 00
--
You think that it is a secret, but it never has been one.
- fortune cookie
^ permalink raw reply
* Re: Adding a new architecture to alsa-driver
From: Lee Revell @ 2006-04-08 16:04 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: alsa-devel
In-Reply-To: <1144510532.10642.1.camel@localhost.localdomain>
On Sat, 2006-04-08 at 16:35 +0100, Adrian McMenamin wrote:
> I've now wasted two days of my life trying to do this and I have had no
> luck, can someone explain the steps needed to added SH (ie
> CONFIG_SUPERH) to the alsa-driver build. I am sure somebody knows the
> steps needed to make this happen
You need to post your driver as a patch against ALSA CVS.
Lee
-------------------------------------------------------
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: Adding a new architecture to alsa-driver
From: Lee Revell @ 2006-04-08 16:03 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: alsa-devel
In-Reply-To: <1144510532.10642.1.camel@localhost.localdomain>
On Sat, 2006-04-08 at 16:35 +0100, Adrian McMenamin wrote:
> I've now wasted two days of my life trying to do this and I have had no
> luck, can someone explain the steps needed to added SH (ie
> CONFIG_SUPERH) to the alsa-driver build. I am sure somebody knows the
> steps needed to make this happen
I already explained it. What *exactly* does not work if you change the
Makefiles as I explained?
Lee
-------------------------------------------------------
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
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.