* problem in iptables!!!
From: varun @ 2006-04-10 13:09 UTC (permalink / raw)
To: netfilter-devel
Hi all,
I have a small problem with iptables. Iam trying to use
iptables in an Cyberton Board (ARM). I compiled it with ucLibc. and i
also put the images on the board. Then when board comes up i manually
insmoded the following modules.
ip_conntrack.ko ipt_REJECT.ko ipt_state.ko
ip_tables.ko ipt_conntrack.ko iptable_filter.ko
Then i tried to add a policy
iptables -t filter -A OUTPUT -j REJECT
This works well in my PC with the 2.6 kernel but gives this error on
the same kernel arm compiled.
The error i get is
iptables v1.2.11: Couldn't find target `REJECT'
Try `iptables -h' or 'iptables --help' for more
information.
Can someone tell me what is wrong?
Varun
^ permalink raw reply
* [Bug 6367] New: acpi-cpufreq: fancy CPUfreq values - can't load p4-clockmod anymore
From: bugme-daemon @ 2006-04-10 13:06 UTC (permalink / raw)
To: cpufreq
http://bugzilla.kernel.org/show_bug.cgi?id=6367
Summary: acpi-cpufreq: fancy CPUfreq values - can't load p4-
clockmod anymore
Kernel Version: 2.6.16.1 + suspend2-2.2.4
Status: NEW
Severity: blocking
Owner: cpufreq@www.linux.org.uk
Submitter: oopla@users.sf.net
[P: blockng for me at least, as it prevents me to upgrade the kernel and benefit
from certain fixes]
Most recent kernel where this bug did not occur: 2.6.15.5, Debian's 2.6.15-1.686
Distribution: Debian Sarge, official + custom/vanilla kernel
Hardware Environment:
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Celeron(R) CPU 2.70GHz
stepping : 9
cpu MHz : 336.750
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 5389.63
# lspci
0000:00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
0000:00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control
Registers (rev 02)
0000:00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process
Registers (rev 02)
0000:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
0000:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics
Device (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 03)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #2 (rev 03)
0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI
Controller (rev 03)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 83)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03)
0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage
Controller (rev 03)
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 03)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
0000:00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem
Controller (rev 03)
0000:01:05.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg
NIC (rev 01)
0000:01:08.0 Ethernet controller: Intel Corp. 82801BD PRO/100 VE (MOB) Ethernet
Controller (rev 83)
0000:01:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus
Bridge with ZV Support (rev 33)
Software Environment:
Problem Description:
I've got a P4-celeron Toshiba notebook which used to work ok with the
cpufreq driver p4-clockmod, but that drivers doesn't load anymore in
2.6.16.1, while the acpi-cpufreq does, but offers wrong numbers:
#----OLD----#
# uname -r
2.6.14.7-se-ss2.2-rc15-p4.1
[ss2 stands for suspend2 patch]
with p4-clockmod:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
337500 675000 1012500 1350000 1687500 2025000 2362500 2700000
# lsmod|grep cpu
cpufreq_userspace 5340 0
cpufreq_stats 6020 0
cpufreq_ondemand 6556 0
cpufreq_conservative 7460 0
freq_table 5636 2 cpufreq_stats,p4_clockmod
cpufreq_powersave 2176 0
and works ok.
#----NEW----#
$ uname -r
2.6.16.1-se-ss2.2.2-p4.1
p4-clockmod doesn't load anymore.
with acpi-cpufreq I get fancy CPUfreqs:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2700000 65535000 65535000 65535000 65535000 65535000 65535000 65535000 65535000
+65535000 65535000 65535000 65535000 65535000 65535000
$ lsmod|grep cpu
acpi_cpufreq 7688 1
cpufreq_stats 5508 0
cpufreq_powersave 2304 0
cpufreq_userspace 4884 1
cpufreq_conservative 6820 0
cpufreq_ondemand 6044 0
cpuid 3460 0
processor 38208 2 acpi_cpufreq,thermal
freq_table 5380 2 acpi_cpufreq,cpufreq_stats
also, cpufreq_stats won't unload anymore and suspend2 gets stuck there.
modprobe p4-clockmod results simply in: 'no such device' and nothing appears in
dmesg.
Steps to reproduce:
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
^ permalink raw reply
* mkpatches: against ref-linux or pristine? (Was: Error compiling with CONFIG_PROFILING (xenoprof))
From: Michael Paesold @ 2006-04-10 13:02 UTC (permalink / raw)
To: Keir Fraser; +Cc: Xen Devel
In-Reply-To: <7c24dec9d3c0a25c92442001bd623b45@cl.cam.ac.uk>
Keir Fraser wrote:
> On 10 Apr 2006, at 12:28, Michael Paesold wrote:
>
>> "make mkpatches" creates diffs between vanilla+patches/linux-2.6.16 and
>> xenified+patches/linux-2.6.16).
>
> I would have thought it would make more sense for it to diff against
> vanilla/linux-2.6.16 (i.e., the pristine tree rather than the ref tree).
> Most people are going to want an all-in-one patch to apply to a vanilla
> kernel tree.
You are right, I also see no real value in having one xen patch + several
extra patches to apply. It rather makes the process of patching more
complicated. Although rpm helps me with the patching, I still have to
manually review changes in patches/ everytime I rebase our own RPMs...
resulting in this very thread. :-)
Does anyone see a use-case for not creating an all-in-one patch? On a second
thought, a separate "make mkpatch" (or a more explicit target name) could
provide an all-in-one patch without introducing transitioning problems for
users of mkpatches.
Should I create a patch to implement that? (Seems rather trivial and
suitable for my limited Makefile fu.)
Best Regards,
Michael Paesold
^ permalink raw reply
* [U-Boot-Users] BDI vs. Lauterbach
From: Woodruff, Richard @ 2006-04-10 13:02 UTC (permalink / raw)
To: u-boot
At the U-boot level I don't know that their should be a huge
differentiator. When you get to the OS level depending on the type of
work you are doing having a bit tighter integration with the Linux
kernel probably can be more help (context switch awareness and symbol
context switching being something very useful).
I generally use a Lauterbach when I can as I'm familiar with it and it
has been stable and highly useful faster than alternatives. Also as it
matures many if not all of the internal registers get mapped into the
debugger. I find ETB/ETM to be very useful in debugging low level code.
Being able to step bi-directionally in C or ASM at an exception point
makes things much easier.
LB does have an OS aware layer which I use at times. It can give you ps
in various formats and access the /proc structure. More things then
I'll enumerate here.
Regards,
Richard W.
> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net [mailto:u-boot-users-
> admin at lists.sourceforge.net] On Behalf Of David Snowdon
> Sent: Monday, April 10, 2006 7:38 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] BDI vs. Lauterbach
>
> G'Day,
>
> I've been looking at a few of the posts regarding debugging tools,
> and the standard answer on this list appears to be "Get a BDI2000".
> I'm presently looking at getting a debugger to use to bring up a new
> board, get U-Boot going, and eventually do a lot of OS work (a new OS
> that we're developing - see http://www.ertos.nicta.com.au -- sorry,
> shameless plug).
>
> Some people that we are working with use the Lauterbach Trace32 tools
> extensively, and we've had some good experiences with them. I was
> wondering if anyone on this list had used both (particularly while
> developing U-Boot), and how the BDI-2000 stacks up against the
> Lauterbach equivalent. (Apart from being significantly cheaper).
>
> Any insights much appreciated.
>
> Many thanks,
>
> David Snowdon,
> Research Engineer,
> National ICT Australia,
> http://www.ertos.nicta.com.au
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
^ permalink raw reply
* Re: fs/binfmt_elf.c:maydump()
From: Daniel Jacobowitz @ 2006-04-10 13:01 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel
In-Reply-To: <20060407.132753.50049697.davem@davemloft.net>
On Fri, Apr 07, 2006 at 01:27:53PM -0700, David S. Miller wrote:
> Yes, and it would also dump text segments that get written
> by the dynamic linker such as the .plt, which we definitely
> do want.
>
> It would also dump impure text segment cases as well.
Well, I'm OK with this, upon reflection. Might as well merge it and
see if anyone else is appalled :-)
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* [U-Boot-Users] BDI vs. Lauterbach
From: Andrey Volkov @ 2006-04-10 13:00 UTC (permalink / raw)
To: u-boot
In-Reply-To: <F4FBA095-7452-4306-9573-AA94421484AD@cse.unsw.edu.au>
On Monday, April 10, 2006, David Snowdon wrote:
> G'Day,
> I've been looking at a few of the posts regarding debugging tools,
> and the standard answer on this list appears to be "Get a BDI2000".
> I'm presently looking at getting a debugger to use to bring up a new
> board, get U-Boot going, and eventually do a lot of OS work (a new OS
> that we're developing - see http://www.ertos.nicta.com.au -- sorry,
> shameless plug).
> Some people that we are working with use the Lauterbach Trace32 tools
> extensively, and we've had some good experiences with them. I was
> wondering if anyone on this list had used both (particularly while
> developing U-Boot), and how the BDI-2000 stacks up against the
> Lauterbach equivalent. (Apart from being significantly cheaper).
Pros:
BDI - 10Mbit eth, Lauterbach - 100 Mbit.
Lauterbach scalable and simply extendable, BDI - not.
Cons:
BDI support gnu toolchain natively (in GDB server mode),
Lauterbach - not (sometime it parsing elf/dwarf correctly,
sometime, usually in critical cases :), not).
And you are know, hmm, strange Lauterbach price policy:
price of BDI firmware for a new CPU target is approx. 1000 eur,
for the Lauterbach - price of new device.
> Any insights much appreciated.
> Many thanks,
> David Snowdon,
> Research Engineer,
> National ICT Australia,
> http://www.ertos.nicta.com.au
--
Regards,
Andrey Volkov
^ permalink raw reply
* Re: [Xenomai-core] [BUG?] stalled xeno domain
From: Jan Kiszka @ 2006-04-10 13:00 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
In-Reply-To: <443A5212.7020001@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 10870 bytes --]
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> 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.
>>
>>
>> I should stop blaming others: it was a leaking lock in xeno_16550A. :D
>>
>>
>>> 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.
>>>
>>
>>
>> This was done yesterday and immediately pulled out the offending code a
>> few minutes ago.
>>
>> Philippe, do you see any remaining issues, e.g. that the leak survived
>> the task termination? Does this have any meaning for correct driver and
>> skin code?
>>
>
> The only way I could see this leakage survive a switch transition would
> require it to happen over the root context, not over a primary context.
> Was it the case?
>
The task had to leave from primary mode. If I forced it to secondary
before terminating, the problem did not show up.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] grantable and address conversion patches
From: Keir Fraser @ 2006-04-10 12:47 UTC (permalink / raw)
To: Isaku Yamahata; +Cc: xen-devel, xen-ia64-devel
In-Reply-To: <20060410123737.GM27482%yamahata@valinux.co.jp>
On 10 Apr 2006, at 13:37, Isaku Yamahata wrote:
>> I'd rather define a function to fill in the entire structure in
>> gnttab.h.
>
> I hope that the attached patch is much more preferable
> than the previous one.
> I tested compilation and dom0 boot.
Is the 'phys' parameter to the new functions ever non-zero?
Also, the call sites that pass a ptep pose a problem -- the host
address should not be __pa()'ed as it's already a machine (or
pseudo-phys) address. On mapping you can check for GNTMAP_contains_pte.
Perhaps we will need to pass flags to the unmap function too.
-- Keir
^ permalink raw reply
* Re: [LARTC] Conntrack, nat and multipath - what is wrong here?
From: Erik Slagter @ 2006-04-10 12:47 UTC (permalink / raw)
To: lartc
In-Reply-To: <200604092142.47556.lists@sperling.no>
[-- Attachment #1.1: Type: text/plain, Size: 284 bytes --]
On Mon, 2006-04-10 at 14:16 +0300, Erik S. Johansen wrote:
> And yet another reply-to-self. Please just ignore the question and shoot me,
> i've spent 3 days debugging this with rpf enabled...
I've been bitten by the same more than once :-( Maybe that help a little
bit ;-)
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* RE: Accessing physical memory
From: Fillod Stephane @ 2006-04-10 12:43 UTC (permalink / raw)
To: Antonio Di Bacco, linuxppc-embedded
Antonio Di Bacco wrote:
>How can I access the physical memory? Can I MMAP for example /dev/mem?
Is=20
>there a simpler way?
Your question is a linuxppc-embedded FAQ.
It is documented in Denx's FAQ[1], and accessible through shorter
URL[2].
For more information, please follow this thread[3] (not ppc specific
actually).
[1]
http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Acce
ssingPeripheralsFromUserSpace
[2] http://tinyurl.com/6c7th
[3] http://lists.linuxppc.org/linuxppc-embedded/200403/msg00059.html
CIAO,
--=20
Stephane
^ permalink raw reply
* Re: PREEMPT_RT : 2.6.16-rt12 and boot : BUG ?
From: Serge Noiraud @ 2006-04-10 12:46 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel
In-Reply-To: <200604061705.36303.Serge.Noiraud@bull.net>
jeudi 6 Avril 2006 17:05, Serge Noiraud wrote/a écrit :
> jeudi 6 Avril 2006 16:31, Ingo Molnar wrote/a écrit :
> >
> > * Serge Noiraud <serge.noiraud@bull.net> wrote:
> >
> > > input: ImPS/2 Generic Wheel Mouse as /class/input/input1
> > > VFS: Mounted root (ext2 filesystem).
> > > Fusion MPT base driver 3.03.07
> > > Copyright (c) 1999-2005 LSI Logic Corporation
> > > Could not allocate 8 bytes percpu data
> > > mptscsih: Unknown symbol scsi_remove_host
> >
> > could you increase (double) PERCPU_ENOUGH_ROOM in
> > include/linux/percpu.h, does that solve this problem? (and make sure you
> > use -rt13, -rt12 had a couple of bugs)
> Tested with rt12 and 192K : same problem
> Tested with rt12 and 256K : same problem.
> Tested with rt13 and 256K : same problem.
> I'm currently compiling with CONFIG_KALLSYMS_ALL not set.
Same thing.
The boot succeed if I set CONFIG_CRITICAL_IRQSOFF_TIMING to no.
If I set this parameter to yes, I get the scsi unresolved symbols.
PERCPU_ENOUGH_ROOM is actually set to 256K.
I'll try to set the original value.
I don't see the relation between this parameter and the missing scsi symbols resolution.
Timing problem ?
> >
> > Ingo
--
Serge Noiraud
^ permalink raw reply
* Re: [Xenomai-core] [BUG?] stalled xeno domain
From: Philippe Gerum @ 2006-04-10 12:39 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
In-Reply-To: <443A437B.6010403@domain.hid>
Jan Kiszka wrote:
> Jan Kiszka wrote:
>
>>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.
>
>
> I should stop blaming others: it was a leaking lock in xeno_16550A. :D
>
>
>>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.
>>
>
>
> This was done yesterday and immediately pulled out the offending code a
> few minutes ago.
>
> Philippe, do you see any remaining issues, e.g. that the leak survived
> the task termination? Does this have any meaning for correct driver and
> skin code?
>
The only way I could see this leakage survive a switch transition would
require it to happen over the root context, not over a primary context.
Was it the case?
--
Philippe.
^ permalink raw reply
* Re: [LARTC] Trying to do some very simple ingress limiting, no success
From: Erik Slagter @ 2006-04-10 12:38 UTC (permalink / raw)
To: lartc
In-Reply-To: <1144579998.5694.18.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 660 bytes --]
On Sun, 2006-04-09 at 14:42 +0100, Andy Furniss wrote:
> > The "old" policer is marked as "obsolete", so I guess it will go away.
> > What am I supposed to replace it with, then?
>
> There may be a way in the future to get netfilter state with an
> ematch/meta data (I don't know the detail Thomas Graf has mentioned it).
Is there already a tc man page that reveals all of this :-(
> > For IMQ I need to patch the kernel (feasible) and the netfilter tools
> > (not feasible :-() I just learned.
>
> I didn't know there is a problrm with IMQ + netfilter.
You just told me ;-)
The IMQ handling is done before the netfilter handling...
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [U-Boot-Users] BDI vs. Lauterbach
From: David Snowdon @ 2006-04-10 12:38 UTC (permalink / raw)
To: u-boot
G'Day,
I've been looking at a few of the posts regarding debugging tools,
and the standard answer on this list appears to be "Get a BDI2000".
I'm presently looking at getting a debugger to use to bring up a new
board, get U-Boot going, and eventually do a lot of OS work (a new OS
that we're developing - see http://www.ertos.nicta.com.au -- sorry,
shameless plug).
Some people that we are working with use the Lauterbach Trace32 tools
extensively, and we've had some good experiences with them. I was
wondering if anyone on this list had used both (particularly while
developing U-Boot), and how the BDI-2000 stacks up against the
Lauterbach equivalent. (Apart from being significantly cheaper).
Any insights much appreciated.
Many thanks,
David Snowdon,
Research Engineer,
National ICT Australia,
http://www.ertos.nicta.com.au
^ permalink raw reply
* Re: [PATCH 4/6] grantable and address conversion patches
From: Isaku Yamahata @ 2006-04-10 12:37 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel, xen-ia64-devel
In-Reply-To: <e1735b03fb5938b2ad45d145503fc2ab@cl.cam.ac.uk>
[-- Attachment #1: Type: text/plain, Size: 272 bytes --]
On Mon, Apr 10, 2006 at 11:36:34AM +0100, Keir Fraser wrote:
> I'd rather define a function to fill in the entire structure in
> gnttab.h.
I hope that the attached patch is much more preferable
than the previous one.
I tested compilation and dom0 boot.
--
yamahata
[-- Attachment #2: 9592:3b76ecb1f8b9_gnttab_set.patch --]
[-- Type: text/plain, Size: 17521 bytes --]
# HG changeset patch
# User yamahata@valinux.co.jp
# Node ID 3b76ecb1f8b94db70dbb801ff9c50f9f897aa67f
# Parent 81bc9e9fb40ddd5c4366da8f7b667363005b1f92
make grant table map/unmap argument, host_addr, feature-specific.
introduce gnttab_set_map_grant_ref() and gnttab_set_unmap_grant_ref()
to initialize.
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c
--- a/linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c Mon Apr 10 21:33:45 2006 +0900
@@ -186,9 +186,8 @@ static void fast_flush_area(pending_req_
handle = pending_handle(req, i);
if (handle == BLKBACK_INVALID_HANDLE)
continue;
- unmap[invcount].host_addr = vaddr(req, i);
- unmap[invcount].dev_bus_addr = 0;
- unmap[invcount].handle = handle;
+ gnttab_set_unmap_grant_ref(&unmap[i], vaddr(req, i), 0,
+ handle);
pending_handle(req, i) = BLKBACK_INVALID_HANDLE;
invcount++;
}
@@ -384,6 +383,8 @@ static void dispatch_rw_block_io(blkif_t
pending_req->nr_pages = nseg;
for (i = 0; i < nseg; i++) {
+ uint32_t flags;
+
seg[i].nsec = req->seg[i].last_sect -
req->seg[i].first_sect + 1;
@@ -392,12 +393,12 @@ static void dispatch_rw_block_io(blkif_t
goto fail_response;
preq.nr_sects += seg[i].nsec;
- map[i].host_addr = vaddr(pending_req, i);
- map[i].dom = blkif->domid;
- map[i].ref = req->seg[i].gref;
- map[i].flags = GNTMAP_host_map;
+ flags = GNTMAP_host_map;
if ( operation == WRITE )
- map[i].flags |= GNTMAP_readonly;
+ flags |= GNTMAP_readonly;
+ gnttab_set_map_grant_ref(&map[i], vaddr(pending_req, i), 0,
+ flags, req->seg[i].gref,
+ blkif->domid);
}
ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, nseg);
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/drivers/xen/blkback/interface.c
--- a/linux-2.6-xen-sparse/drivers/xen/blkback/interface.c Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/blkback/interface.c Mon Apr 10 21:33:45 2006 +0900
@@ -58,10 +58,9 @@ static int map_frontend_page(blkif_t *bl
struct gnttab_map_grant_ref op;
int ret;
- op.host_addr = (unsigned long)blkif->blk_ring_area->addr;
- op.flags = GNTMAP_host_map;
- op.ref = shared_page;
- op.dom = blkif->domid;
+ gnttab_set_map_grant_ref(&op,
+ (unsigned long)blkif->blk_ring_area->addr, 0,
+ GNTMAP_host_map, shared_page, blkif->domid);
lock_vm_area(blkif->blk_ring_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
@@ -90,9 +89,9 @@ static void unmap_frontend_page(blkif_t
struct gnttab_unmap_grant_ref op;
int ret;
- op.host_addr = (unsigned long)blkif->blk_ring_area->addr;
- op.handle = blkif->shmem_handle;
- op.dev_bus_addr = 0;
+ gnttab_set_unmap_grant_ref(&op,
+ (unsigned long)blkif->blk_ring_area->addr,
+ 0, blkif->shmem_handle);
lock_vm_area(blkif->blk_ring_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1);
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/drivers/xen/blktap/blktap.c
--- a/linux-2.6-xen-sparse/drivers/xen/blktap/blktap.c Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/blktap/blktap.c Mon Apr 10 21:33:45 2006 +0900
@@ -418,9 +418,9 @@ static void fast_flush_area(int idx, int
if (BLKTAP_INVALID_HANDLE(handle))
continue;
- unmap[op].host_addr = MMAP_VADDR(mmap_vstart, idx, i);
- unmap[op].dev_bus_addr = 0;
- unmap[op].handle = handle->kernel;
+ gnttab_set_unmap_grant_ref(&unmap[op],
+ MMAP_VADDR(mmap_vstart, idx, i), 0,
+ handle->kernel);
op++;
if (create_lookup_pte_addr(
@@ -430,9 +430,7 @@ static void fast_flush_area(int idx, int
DPRINTK("Couldn't get a pte addr!\n");
return;
}
- unmap[op].host_addr = ptep;
- unmap[op].dev_bus_addr = 0;
- unmap[op].handle = handle->user;
+ gnttab_set_unmap_grnat_ref(&unmap[op], ptep, 0, handle->user);
op++;
BLKTAP_INVALIDATE_HANDLE(handle);
@@ -703,15 +701,14 @@ static void dispatch_rw_block_io(blkif_t
unsigned long uvaddr;
unsigned long kvaddr;
uint64_t ptep;
+ uint32_t flags;
uvaddr = MMAP_VADDR(user_vstart, pending_idx, i);
kvaddr = MMAP_VADDR(mmap_vstart, pending_idx, i);
/* Map the remote page to kernel. */
- map[op].host_addr = kvaddr;
- map[op].dom = blkif->domid;
- map[op].ref = req->seg[i].gref;
- map[op].flags = GNTMAP_host_map;
+ gnttab_set_map_grant_ref(&map[op], kvaddr, 0, GNTMAP_host_map,
+ req->seg[i].gref, blkif->domid);
/* This needs a bit more thought in terms of interposition:
* If we want to be able to modify pages during write using
* grant table mappings, the guest will either need to allow
@@ -728,14 +725,13 @@ static void dispatch_rw_block_io(blkif_t
goto bad_descriptor;
}
- map[op].host_addr = ptep;
- map[op].dom = blkif->domid;
- map[op].ref = req->seg[i].gref;
- map[op].flags = GNTMAP_host_map | GNTMAP_application_map
+ flags = GNTMAP_host_map | GNTMAP_application_map
| GNTMAP_contains_pte;
/* Above interposition comment applies here as well. */
if (req->operation == BLKIF_OP_WRITE)
- map[op].flags |= GNTMAP_readonly;
+ flags |= GNTMAP_readonly;
+ gnttab_set_map_grant_ref(&map[op], ptep, 0, flags,
+ req->seg[i].gref, blkif->domid);
op++;
}
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/drivers/xen/blktap/interface.c
--- a/linux-2.6-xen-sparse/drivers/xen/blktap/interface.c Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/blktap/interface.c Mon Apr 10 21:33:45 2006 +0900
@@ -33,10 +33,9 @@ static int map_frontend_page(blkif_t *bl
struct gnttab_map_grant_ref op;
int ret;
- op.host_addr = (unsigned long)blkif->blk_ring_area->addr;
- op.flags = GNTMAP_host_map;
- op.ref = shared_page;
- op.dom = blkif->domid;
+ gnttab_set_map_grant_ref(&op,
+ (unsigned long)blkif->blk_ring_area->addr, 0,
+ GNTMAP_host_map, shared_page, blkif->domid);
lock_vm_area(blkif->blk_ring_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
@@ -59,9 +58,9 @@ static void unmap_frontend_page(blkif_t
struct gnttab_unmap_grant_ref op;
int ret;
- op.host_addr = (unsigned long)blkif->blk_ring_area->addr;
- op.handle = blkif->shmem_handle;
- op.dev_bus_addr = 0;
+ gnttab_set_unmap_grant_ref(&op,
+ (unsigned long)blkif->blk_ring_area->addr,
+ 0, blkif->shmem_handle);
lock_vm_area(blkif->blk_ring_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1);
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/drivers/xen/netback/interface.c
--- a/linux-2.6-xen-sparse/drivers/xen/netback/interface.c Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/netback/interface.c Mon Apr 10 21:33:45 2006 +0900
@@ -150,10 +150,9 @@ static int map_frontend_pages(
struct gnttab_map_grant_ref op;
int ret;
- op.host_addr = (unsigned long)netif->tx_comms_area->addr;
- op.flags = GNTMAP_host_map;
- op.ref = tx_ring_ref;
- op.dom = netif->domid;
+ gnttab_set_map_grant_ref(&op,
+ (unsigned long)netif->tx_comms_area->addr, 0,
+ GNTMAP_host_map, tx_ring_ref, netif->domid);
lock_vm_area(netif->tx_comms_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
@@ -168,10 +167,9 @@ static int map_frontend_pages(
netif->tx_shmem_ref = tx_ring_ref;
netif->tx_shmem_handle = op.handle;
- op.host_addr = (unsigned long)netif->rx_comms_area->addr;
- op.flags = GNTMAP_host_map;
- op.ref = rx_ring_ref;
- op.dom = netif->domid;
+ gnttab_set_map_grant_ref(&op,
+ (unsigned long)netif->rx_comms_area->addr, 0,
+ GNTMAP_host_map, rx_ring_ref, netif->domid);
lock_vm_area(netif->rx_comms_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
@@ -194,18 +192,18 @@ static void unmap_frontend_pages(netif_t
struct gnttab_unmap_grant_ref op;
int ret;
- op.host_addr = (unsigned long)netif->tx_comms_area->addr;
- op.handle = netif->tx_shmem_handle;
- op.dev_bus_addr = 0;
+ gnttab_set_unmap_grant_ref(&op,
+ (unsigned long)netif->tx_comms_area->addr,
+ 0, netif->tx_shmem_handle);
lock_vm_area(netif->tx_comms_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1);
unlock_vm_area(netif->tx_comms_area);
BUG_ON(ret);
- op.host_addr = (unsigned long)netif->rx_comms_area->addr;
- op.handle = netif->rx_shmem_handle;
- op.dev_bus_addr = 0;
+ gnttab_set_unmap_grant_ref(&op,
+ (unsigned long)netif->rx_comms_area->addr,
+ 0, netif->rx_shmem_handle);
lock_vm_area(netif->rx_comms_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1);
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/drivers/xen/netback/netback.c
--- a/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/netback/netback.c Mon Apr 10 21:33:45 2006 +0900
@@ -453,9 +453,8 @@ inline static void net_tx_action_dealloc
gop = tx_unmap_ops;
while (dc != dp) {
pending_idx = dealloc_ring[MASK_PEND_IDX(dc++)];
- gop->host_addr = MMAP_VADDR(pending_idx);
- gop->dev_bus_addr = 0;
- gop->handle = grant_tx_handle[pending_idx];
+ gnttab_set_unmap_grant_ref(gop, MMAP_VADDR(pending_idx), 0,
+ grant_tx_handle[pending_idx]);
gop++;
}
ret = HYPERVISOR_grant_table_op(
@@ -579,10 +578,9 @@ static void net_tx_action(unsigned long
/* Packets passed to netif_rx() must have some headroom. */
skb_reserve(skb, 16);
- mop->host_addr = MMAP_VADDR(pending_idx);
- mop->dom = netif->domid;
- mop->ref = txreq.gref;
- mop->flags = GNTMAP_host_map | GNTMAP_readonly;
+ gnttab_set_map_grant_ref(mop, MMAP_VADDR(pending_idx), 0,
+ GNTMAP_host_map | GNTMAP_readonly,
+ txreq.gref, netif->domid);
mop++;
memcpy(&pending_tx_info[pending_idx].req,
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/drivers/xen/tpmback/interface.c
--- a/linux-2.6-xen-sparse/drivers/xen/tpmback/interface.c Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/tpmback/interface.c Mon Apr 10 21:33:45 2006 +0900
@@ -72,12 +72,10 @@ static int map_frontend_page(tpmif_t *tp
static int map_frontend_page(tpmif_t *tpmif, unsigned long shared_page)
{
int ret;
- struct gnttab_map_grant_ref op = {
- .host_addr = (unsigned long)tpmif->tx_area->addr,
- .flags = GNTMAP_host_map,
- .ref = shared_page,
- .dom = tpmif->domid,
- };
+ struct gnttab_map_grant_ref op;
+
+ gnttab_set_map_grant_ref(&op, (unsigned long)tpmif->tx_area->addr, 0,
+ GNTMAP_host_map, shared_page, tpmif->domid);
lock_vm_area(tpmif->tx_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1);
@@ -100,9 +98,8 @@ static void unmap_frontend_page(tpmif_t
struct gnttab_unmap_grant_ref op;
int ret;
- op.host_addr = (unsigned long)tpmif->tx_area->addr;
- op.handle = tpmif->shmem_handle;
- op.dev_bus_addr = 0;
+ gnttab_set_unmap_grant_ref(&op, (unsigned long)tpmif->tx_area->addr, 0,
+ tpmif->shmem_handle);
lock_vm_area(tpmif->tx_area);
ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1);
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/drivers/xen/tpmback/tpmback.c
--- a/linux-2.6-xen-sparse/drivers/xen/tpmback/tpmback.c Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/tpmback/tpmback.c Mon Apr 10 21:33:45 2006 +0900
@@ -278,10 +278,9 @@ int _packet_write(struct packet *pak,
return 0;
}
- map_op.host_addr = MMAP_VADDR(tpmif, i);
- map_op.flags = GNTMAP_host_map;
- map_op.ref = tx->ref;
- map_op.dom = tpmif->domid;
+ gnttab_set_map_grant_ref(&map_op, MMAP_VADDR(tpmif, i), 0,
+ GNTMAP_host_map, tx->ref,
+ tpmif->domid);
if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
&map_op, 1))) {
@@ -308,9 +307,8 @@ int _packet_write(struct packet *pak,
}
tx->size = tocopy;
- unmap_op.host_addr = MMAP_VADDR(tpmif, i);
- unmap_op.handle = handle;
- unmap_op.dev_bus_addr = 0;
+ gnttab_set_unmap_grant_ref(&unmap_op, MMAP_VADDR(tpmif, i), 0,
+ handle);
if (unlikely
(HYPERVISOR_grant_table_op
@@ -422,10 +420,9 @@ static int packet_read_shmem(struct pack
tx = &tpmif->tx->ring[i].req;
- map_op.host_addr = MMAP_VADDR(tpmif, i);
- map_op.flags = GNTMAP_host_map;
- map_op.ref = tx->ref;
- map_op.dom = tpmif->domid;
+ gnttab_set_map_grant_ref(&map_op, MMAP_VADDR(tpmif, i), 0,
+ GNTMAP_host_map, tx->ref,
+ tpmif->domid);
if (unlikely(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
&map_op, 1))) {
@@ -461,9 +458,8 @@ static int packet_read_shmem(struct pack
tpmif->domid, buffer[offset], buffer[offset + 1],
buffer[offset + 2], buffer[offset + 3]);
- unmap_op.host_addr = MMAP_VADDR(tpmif, i);
- unmap_op.handle = handle;
- unmap_op.dev_bus_addr = 0;
+ gnttab_set_unmap_grant_ref(&unmap_op, MMAP_VADDR(tpmif, i), 0,
+ handle);
if (unlikely
(HYPERVISOR_grant_table_op
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_client.c
--- a/linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_client.c Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_client.c Mon Apr 10 21:33:45 2006 +0900
@@ -264,11 +264,7 @@ int xenbus_free_evtchn(struct xenbus_dev
/* Based on Rusty Russell's skeleton driver's map_page */
int xenbus_map_ring_valloc(struct xenbus_device *dev, int gnt_ref, void **vaddr)
{
- struct gnttab_map_grant_ref op = {
- .flags = GNTMAP_host_map,
- .ref = gnt_ref,
- .dom = dev->otherend_id,
- };
+ struct gnttab_map_grant_ref op;
struct vm_struct *area;
*vaddr = NULL;
@@ -277,8 +273,9 @@ int xenbus_map_ring_valloc(struct xenbus
if (!area)
return -ENOMEM;
- op.host_addr = (unsigned long)area->addr;
-
+ gnttab_set_map_grant_ref(&op, (unsigned long)area->addr, 0,
+ GNTMAP_host_map, gnt_ref, dev->otherend_id);
+
lock_vm_area(area);
BUG_ON(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1));
unlock_vm_area(area);
@@ -303,13 +300,10 @@ int xenbus_map_ring(struct xenbus_device
int xenbus_map_ring(struct xenbus_device *dev, int gnt_ref,
grant_handle_t *handle, void *vaddr)
{
- struct gnttab_map_grant_ref op = {
- .host_addr = (unsigned long)vaddr,
- .flags = GNTMAP_host_map,
- .ref = gnt_ref,
- .dom = dev->otherend_id,
- };
-
+ struct gnttab_map_grant_ref op;
+
+ gnttab_set_map_grant_ref(&op, (unsigned long)vaddr, 0, GNTMAP_host_map,
+ gnt_ref, dev->otherend_id);
BUG_ON(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1));
if (op.status != GNTST_okay) {
@@ -328,9 +322,7 @@ int xenbus_unmap_ring_vfree(struct xenbu
int xenbus_unmap_ring_vfree(struct xenbus_device *dev, void *vaddr)
{
struct vm_struct *area;
- struct gnttab_unmap_grant_ref op = {
- .host_addr = (unsigned long)vaddr,
- };
+ struct gnttab_unmap_grant_ref op;
/* It'd be nice if linux/vmalloc.h provided a find_vm_area(void *addr)
* method so that we don't have to muck with vmalloc internals here.
@@ -351,7 +343,8 @@ int xenbus_unmap_ring_vfree(struct xenbu
return GNTST_bad_virt_addr;
}
- op.handle = (grant_handle_t)area->phys_addr;
+ gnttab_set_unmap_grant_ref(&op, (unsigned long)vaddr, 0,
+ (grant_handle_t)area->phys_addr);
lock_vm_area(area);
BUG_ON(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1));
@@ -372,11 +365,9 @@ int xenbus_unmap_ring(struct xenbus_devi
int xenbus_unmap_ring(struct xenbus_device *dev,
grant_handle_t handle, void *vaddr)
{
- struct gnttab_unmap_grant_ref op = {
- .host_addr = (unsigned long)vaddr,
- .handle = handle,
- };
-
+ struct gnttab_unmap_grant_ref op;
+
+ gnttab_set_unmap_grant_ref(&op, (unsigned long)vaddr, 0, handle);
BUG_ON(HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref, &op, 1));
if (op.status != GNTST_okay)
diff -r 81bc9e9fb40d -r 3b76ecb1f8b9 linux-2.6-xen-sparse/include/xen/gnttab.h
--- a/linux-2.6-xen-sparse/include/xen/gnttab.h Sun Apr 9 18:23:16 2006 +0100
+++ b/linux-2.6-xen-sparse/include/xen/gnttab.h Mon Apr 10 21:33:45 2006 +0900
@@ -40,6 +40,7 @@
#include <linux/config.h>
#include <asm/hypervisor.h>
#include <xen/interface/grant_table.h>
+#include <xen/features.h>
/* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
#ifdef __ia64__
@@ -113,6 +114,41 @@ int gnttab_suspend(void);
int gnttab_suspend(void);
int gnttab_resume(void);
+static inline void
+gnttab_set_map_grant_ref(struct gnttab_map_grant_ref *map,
+ unsigned long virt, unsigned long phys,
+ uint32_t flags, grant_ref_t ref, domid_t domid)
+{
+ if (xen_feature(XENFEAT_auto_translated_physmap)) {
+ if (phys)
+ map->host_addr = phys;
+ else
+ map->host_addr = __pa(virt);
+ } else
+ map->host_addr = virt;
+
+ map->flags = flags;
+ map->ref = ref;
+ map->dom = domid;
+}
+
+static inline void
+gnttab_set_unmap_grant_ref(struct gnttab_unmap_grant_ref *unmap,
+ unsigned long virt, unsigned long phys,
+ grant_handle_t handle)
+{
+ if (xen_feature(XENFEAT_auto_translated_physmap)) {
+ if (phys)
+ unmap->host_addr = phys;
+ else
+ unmap->host_addr = __pa(virt);
+ } else
+ unmap->host_addr = virt;
+
+ unmap->handle = handle;
+ unmap->dev_bus_addr = 0;
+}
+
#endif /* __ASM_GNTTAB_H__ */
/*
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [LARTC] Trying to do some very simple ingress limiting, no success
From: Erik Slagter @ 2006-04-10 12:36 UTC (permalink / raw)
To: lartc
In-Reply-To: <1144579998.5694.18.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 391 bytes --]
On Sun, 2006-04-09 at 14:00 +0100, Andy Furniss wrote:
> There are two policers now the old one will work as you want but you
> need to change your kernel config. Unselect packet action and you should
> be able to choose a different policer.
This indeed did the trick! Thanks!
Stupid that tc & kernel allow all of this, don't give any sort of error
but simply refuse to work.
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: checking write_cached_data return status inside _release and _flush?
From: Jörn Engel @ 2006-04-10 12:24 UTC (permalink / raw)
To: massiblue@libero.it; +Cc: linux-mtd
In-Reply-To: <IXI8OW$25AAA6D68166E4BF09ED12F6E5747466@libero.it>
On Mon, 10 April 2006 13:46:08 +0200, massiblue@libero.it wrote:
>
> i'll fix it properly (finite number of retries, error handling etc...) against 2.6.16.2 and send you the patch, ok?
Great!
Jörn
--
"Error protection by error detection and correction."
-- from a university class
^ permalink raw reply
* Re: SuSE 10.0 and it's RPM 4.1.1??
From: cRaig @ 2006-04-10 12:22 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <efc7f7d00604100516tb878c76wce28fc7e92e9948@mail.gmail.com>
On 4/10/06, Yawar Amin <yawar.amin@gmail.com> wrote:
> That may well be, but according to
> http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-rpm.html,
> RPM stands for RPM Package Manager.
;that's funny, because an earlier version manual [0] on the same sites says:
"Red Hat Package Manager (RPM), is an open packaging system available
for anyone to use, and works on both Red Hat Linux as well as other
Linux and UNIX systems."
[0] http://www.redhat.com/docs/manuals/linux/RHL-5.0-Manual/user-guide/doc059.html
;cRaig
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: [Openvortex-dev] Re: [PATCH] au88x0: clean up __devinit/__devexit
From: Takashi Iwai @ 2006-04-10 12:22 UTC (permalink / raw)
To: Alien; +Cc: openvortex-dev, Dale Sedivec, alsa-devel
In-Reply-To: <200604101338.35172.alien999999999@users.sourceforge.net>
At Mon, 10 Apr 2006 13:38:34 +0200,
Alien wrote:
>
> On Monday 10 April 2006 12:35, Takashi Iwai wrote:
> > At Sat, 8 Apr 2006 20:40:19 -0400,
> >
> > Dale Sedivec wrote:
> > > Removed all use of __devinit/__devexit and init.h from headers. Any
> > > attributes given in the prototype but not in the function definition have
> > > been moved to the definition.
> > >
> > > An exception is vortex_eq_free: I removed the __devexit attribute because
> > > vortex_eq_free is called from vortex_core_shutdown, and
> > > vortex_core_shutdown may be called from __devinit snd_vortex_create.
> > >
> > > Compile tested with allyesconfig and allmodconfig.
> > >
> > > Signed-off-by: Dale Sedivec <dale@codefu.org>
> >
> > Thanks, I applied the patch to ALSA cvs tree.
>
> what about all the other changes, bugfixes and patches that have been posted
> on this list? are they being applies as well? (also, that gigantic bugreport
> and all changes being submitted there...)
I have never received any patches on alsa-devel ML.
Could yout _post_ the patches (not a URL, preferably a series of
separated patches) to alsa-develML and Cc to me for review and merge?
Also don't forget to add a proper changelog and signed-off-by for each
patch.
Thanks,
Takashi
-------------------------------------------------------
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: Error compiling with CONFIG_PROFILING (xenoprof)
From: Keir Fraser @ 2006-04-10 12:21 UTC (permalink / raw)
To: Michael Paesold; +Cc: Xen Devel
In-Reply-To: <00e701c65c91$e69a8f20$d801a8c0@zaphod>
On 10 Apr 2006, at 12:28, Michael Paesold wrote:
> "make mkpatches" creates diffs between vanilla+patches/linux-2.6.16
> and xenified+patches/linux-2.6.16).
I would have thought it would make more sense for it to diff against
vanilla/linux-2.6.16 (i.e., the pristine tree rather than the ref
tree). Most people are going to want an all-in-one patch to apply to a
vanilla kernel tree.
-- Keir
^ permalink raw reply
* [PATCH 2/2] tickless idle cpus: allow boot cpu to skip ticks
From: Srivatsa Vaddagiri @ 2006-04-10 12:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17462.61423.42032.559627@cargo.ozlabs.ibm.com>
This patch (version 2) lets boot cpu to skip ticks. Tested against
2.6.17-rc1-mm1.
Signed-off-by: Srivatsa Vaddagiri <vatsa@in.ibm.com>
---
linux-2.6.17-rc1-root/arch/powerpc/kernel/time.c | 71 ++++++++++++++++++++---
1 file changed, 63 insertions(+), 8 deletions(-)
diff -puN arch/powerpc/kernel/time.c~boot_cpu_fix arch/powerpc/kernel/time.c
--- linux-2.6.17-rc1/arch/powerpc/kernel/time.c~boot_cpu_fix 2006-04-10 17:43:11.000000000 +0530
+++ linux-2.6.17-rc1-root/arch/powerpc/kernel/time.c 2006-04-10 17:44:32.000000000 +0530
@@ -637,6 +637,39 @@ static void iSeries_tb_recal(void)
static void account_ticks(struct pt_regs *regs);
+static spinlock_t do_timer_cpulock = SPIN_LOCK_UNLOCKED;
+static int do_timer_cpu; /* Which CPU should call do_timer? */
+
+static int __devinit do_timer_cpucallback(struct notifier_block *self,
+ unsigned long action, void *hcpu)
+{
+ int cpu = (long)hcpu;
+
+ switch (action) {
+ case CPU_DOWN_PREPARE:
+ spin_lock(&do_timer_cpulock);
+ if (do_timer_cpu == cpu) {
+ cpumask_t tmpmask;
+ int new_cpu;
+
+ cpus_complement(tmpmask, nohz_cpu_mask);
+ cpu_clear(cpu, tmpmask);
+ new_cpu = any_online_cpu(tmpmask);
+ if (new_cpu != NR_CPUS)
+ do_timer_cpu = new_cpu;
+ }
+ spin_unlock(&do_timer_cpulock);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block __devinitdata do_timer_notifier =
+{
+ .notifier_call = do_timer_cpucallback
+};
+
/* Returns 1 if this CPU was set in the mask */
static inline int clear_hzless_mask(void)
{
@@ -645,8 +678,12 @@ static inline int clear_hzless_mask(void
if (unlikely(cpu_isset(cpu, nohz_cpu_mask))) {
cpu_clear(cpu, nohz_cpu_mask);
- rc = 1;
- }
+ spin_lock(&do_timer_cpulock);
+ if (do_timer_cpu == NR_CPUS)
+ do_timer_cpu = cpu;
+ spin_unlock(&do_timer_cpulock);
+ rc = 1;
+ }
return rc;
}
@@ -684,6 +721,15 @@ void stop_hz_timer(void)
return;
}
+ spin_lock(&do_timer_cpulock);
+ if (do_timer_cpu == cpu) {
+ cpumask_t tmpmask;
+
+ cpus_complement(tmpmask, nohz_cpu_mask);
+ do_timer_cpu = any_online_cpu(tmpmask);
+ }
+ spin_unlock(&do_timer_cpulock);
+
do {
seq = read_seqbegin(&xtime_lock);
@@ -716,6 +762,7 @@ void start_hz_timer(struct pt_regs *regs
#else
static inline int clear_hzless_mask(void) { return 0;}
+#define do_timer_cpu boot_cpuid
#endif
static void account_ticks(struct pt_regs *regs)
@@ -742,16 +789,15 @@ static void account_ticks(struct pt_regs
if (!cpu_is_offline(cpu))
account_process_time(regs);
- /*
- * No need to check whether cpu is offline here; boot_cpuid
- * should have been fixed up by now.
- */
- if (cpu != boot_cpuid)
+ if (cpu != do_timer_cpu)
continue;
write_seqlock(&xtime_lock);
tb_last_jiffy += tb_ticks_per_jiffy;
- tb_last_stamp = per_cpu(last_jiffy, cpu);
+ tb_last_stamp += tb_ticks_per_jiffy;
+ /* Handle RTCL overflow on 601 */
+ if (__USE_RTC() && tb_last_stamp >= 1000000000)
+ tb_last_stamp -= 1000000000;
do_timer(regs);
timer_recalc_offset(tb_last_jiffy);
timer_check_rtc();
@@ -836,6 +882,13 @@ void __init smp_space_timers(unsigned in
unsigned long offset = tb_ticks_per_jiffy / max_cpus;
unsigned long previous_tb = per_cpu(last_jiffy, boot_cpuid);
+#ifdef CONFIG_NO_IDLE_HZ
+ /* Don't space timers - we want to let any CPU call do_timer to
+ * increment xtime.
+ */
+ half = offset = 0;
+#endif
+
/* make sure tb > per_cpu(last_jiffy, cpu) for all cpus always */
previous_tb -= tb_ticks_per_jiffy;
/*
@@ -1051,6 +1104,8 @@ void __init time_init(void)
calc_cputime_factors();
#ifdef CONFIG_NO_IDLE_HZ
max_skip = __USE_RTC() ? HZ : MAX_DEC_COUNT / tb_ticks_per_jiffy;
+ do_timer_cpu = boot_cpuid;
+ register_cpu_notifier(&do_timer_notifier);
#endif
/*
_
--
Regards,
vatsa
^ permalink raw reply
* [PATCH 1/2] tickless idle cpus: core patch - v2
From: Srivatsa Vaddagiri @ 2006-04-10 12:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17462.61423.42032.559627@cargo.ozlabs.ibm.com>
This is the v2 of the core patch to skip ticks when a CPU is idle.
Changes since v1:
- fix the buggy call to stop_hz_timer in idle_power4.S (hopefully it
is correct now!).
- Dont allow boot cpu to skip ticks (a follow-on patch will
remove this restriction)
Signed-off-by: Srivatsa Vaddagiri <vatsa@in.ibm.com>
---
linux-2.6.17-rc1-root/arch/powerpc/Kconfig | 6
linux-2.6.17-rc1-root/arch/powerpc/kernel/idle_power4.S | 5
linux-2.6.17-rc1-root/arch/powerpc/kernel/irq.c | 3
linux-2.6.17-rc1-root/arch/powerpc/kernel/time.c | 143 +++++++++--
linux-2.6.17-rc1-root/arch/powerpc/kernel/traps.c | 1
linux-2.6.17-rc1-root/arch/powerpc/platforms/pseries/setup.c | 6
linux-2.6.17-rc1-root/include/asm-powerpc/time.h | 8
7 files changed, 147 insertions(+), 25 deletions(-)
diff -puN arch/powerpc/kernel/time.c~no_idle_hz arch/powerpc/kernel/time.c
--- linux-2.6.17-rc1/arch/powerpc/kernel/time.c~no_idle_hz 2006-04-09 10:40:58.000000000 +0530
+++ linux-2.6.17-rc1-root/arch/powerpc/kernel/time.c 2006-04-10 14:32:04.000000000 +0530
@@ -633,40 +633,97 @@ static void iSeries_tb_recal(void)
}
#endif
-/*
- * For iSeries shared processors, we have to let the hypervisor
- * set the hardware decrementer. We set a virtual decrementer
- * in the lppaca and call the hypervisor if the virtual
- * decrementer is less than the current value in the hardware
- * decrementer. (almost always the new decrementer value will
- * be greater than the current hardware decementer so the hypervisor
- * call will not be needed)
- */
+#ifdef CONFIG_NO_IDLE_HZ
-/*
- * timer_interrupt - gets called when the decrementer overflows,
- * with interrupts disabled.
+static void account_ticks(struct pt_regs *regs);
+
+/* Returns 1 if this CPU was set in the mask */
+static inline int clear_hzless_mask(void)
+{
+ int cpu = smp_processor_id();
+ int rc = 0;
+
+ if (unlikely(cpu_isset(cpu, nohz_cpu_mask))) {
+ cpu_clear(cpu, nohz_cpu_mask);
+ rc = 1;
+ }
+
+ return rc;
+}
+
+#define MAX_DEC_COUNT UINT_MAX /* Decrementer is 32-bit */
+static int min_skip = 2; /* Minimum number of ticks to skip */
+static int max_skip; /* Maximum number of ticks to skip */
+
+
+int sysctl_hz_timer = 1;
+
+/* Defer timer interrupt for as long as possible. This is accomplished by
+ * programming the decrementer to a suitable value such that it raises the
+ * exception after desired interval. This features allows CPUs to
+ * be used more efficiently in virtualized environments and/or allows for
+ * lower power consumption.
+ *
+ * Called with interrupts disabled on an idle CPU. Caller has to ensure that
+ * idle loop is not exited w/o start_hz_timer being called via an interrupt
+ * to restore timer interrupt frequency.
*/
-void timer_interrupt(struct pt_regs * regs)
+
+void stop_hz_timer(void)
{
+ unsigned long cpu = smp_processor_id(), seq, delta;
int next_dec;
- int cpu = smp_processor_id();
- unsigned long ticks;
-#ifdef CONFIG_PPC32
- if (atomic_read(&ppc_n_lost_interrupts) != 0)
- do_IRQ(regs);
-#endif
+ if (sysctl_hz_timer != 0 || cpu == boot_cpuid)
+ return;
- irq_enter();
+ cpu_set(cpu, nohz_cpu_mask);
+ mb();
+ if (rcu_pending(cpu) || local_softirq_pending()) {
+ cpu_clear(cpu, nohz_cpu_mask);
+ return;
+ }
- profile_tick(CPU_PROFILING, regs);
- calculate_steal_time();
+ do {
+ seq = read_seqbegin(&xtime_lock);
-#ifdef CONFIG_PPC_ISERIES
- get_lppaca()->int_dword.fields.decr_int = 0;
+ delta = next_timer_interrupt() - jiffies;
+
+ if (delta < min_skip) {
+ cpu_clear(cpu, nohz_cpu_mask);
+ return;
+ }
+
+ if (delta > max_skip)
+ delta = max_skip;
+
+ next_dec = tb_last_stamp + delta * tb_ticks_per_jiffy;
+
+ } while (read_seqretry(&xtime_lock, seq));
+
+ next_dec -= get_tb();
+ set_dec(next_dec);
+
+ return;
+}
+
+/* Take into account skipped ticks and restore the HZ timer frequency */
+void start_hz_timer(struct pt_regs *regs)
+{
+ if (clear_hzless_mask())
+ account_ticks(regs);
+}
+
+#else
+static inline int clear_hzless_mask(void) { return 0;}
#endif
+static void account_ticks(struct pt_regs *regs)
+{
+ int next_dec;
+ int cpu = smp_processor_id();
+ unsigned long ticks;
+
while ((ticks = tb_ticks_since(per_cpu(last_jiffy, cpu)))
>= tb_ticks_per_jiffy) {
/* Update last_jiffy */
@@ -703,6 +760,41 @@ void timer_interrupt(struct pt_regs * re
next_dec = tb_ticks_per_jiffy - ticks;
set_dec(next_dec);
+}
+
+/*
+ * For iSeries shared processors, we have to let the hypervisor
+ * set the hardware decrementer. We set a virtual decrementer
+ * in the lppaca and call the hypervisor if the virtual
+ * decrementer is less than the current value in the hardware
+ * decrementer. (almost always the new decrementer value will
+ * be greater than the current hardware decementer so the hypervisor
+ * call will not be needed)
+ */
+
+/*
+ * timer_interrupt - gets called when the decrementer overflows,
+ * with interrupts disabled.
+ */
+void timer_interrupt(struct pt_regs * regs)
+{
+#ifdef CONFIG_PPC32
+ if (atomic_read(&ppc_n_lost_interrupts) != 0)
+ do_IRQ(regs);
+#endif
+
+ irq_enter();
+
+ clear_hzless_mask();
+
+ profile_tick(CPU_PROFILING, regs);
+ calculate_steal_time();
+
+#ifdef CONFIG_PPC_ISERIES
+ get_lppaca()->int_dword.fields.decr_int = 0;
+#endif
+
+ account_ticks(regs);
#ifdef CONFIG_PPC_ISERIES
if (hvlpevent_is_pending())
@@ -957,6 +1049,9 @@ void __init time_init(void)
tb_ticks_per_usec = ppc_tb_freq / 1000000;
tb_to_us = mulhwu_scale_factor(ppc_tb_freq, 1000000);
calc_cputime_factors();
+#ifdef CONFIG_NO_IDLE_HZ
+ max_skip = __USE_RTC() ? HZ : MAX_DEC_COUNT / tb_ticks_per_jiffy;
+#endif
/*
* Calculate the length of each tick in ns. It will not be
diff -puN arch/powerpc/kernel/irq.c~no_idle_hz arch/powerpc/kernel/irq.c
--- linux-2.6.17-rc1/arch/powerpc/kernel/irq.c~no_idle_hz 2006-04-09 10:40:58.000000000 +0530
+++ linux-2.6.17-rc1-root/arch/powerpc/kernel/irq.c 2006-04-09 10:40:59.000000000 +0530
@@ -60,6 +60,7 @@
#ifdef CONFIG_PPC_ISERIES
#include <asm/paca.h>
#endif
+#include <asm/time.h>
int __irq_offset_value;
#ifdef CONFIG_PPC32
@@ -189,6 +190,8 @@ void do_IRQ(struct pt_regs *regs)
irq_enter();
+ start_hz_timer(regs);
+
#ifdef CONFIG_DEBUG_STACKOVERFLOW
/* Debugging check for stack overflow: is there less than 2KB free? */
{
diff -puN include/asm-powerpc/time.h~no_idle_hz include/asm-powerpc/time.h
--- linux-2.6.17-rc1/include/asm-powerpc/time.h~no_idle_hz 2006-04-09 10:40:59.000000000 +0530
+++ linux-2.6.17-rc1-root/include/asm-powerpc/time.h 2006-04-09 10:40:59.000000000 +0530
@@ -198,6 +198,14 @@ static inline unsigned long tb_ticks_sin
return get_tbl() - tstamp;
}
+#ifdef CONFIG_NO_IDLE_HZ
+extern void stop_hz_timer(void);
+extern void start_hz_timer(struct pt_regs *);
+#else
+static inline void stop_hz_timer(void) { }
+static inline void start_hz_timer(struct pt_regs *regs) { }
+#endif
+
#define mulhwu(x,y) \
({unsigned z; asm ("mulhwu %0,%1,%2" : "=r" (z) : "r" (x), "r" (y)); z;})
diff -puN arch/powerpc/Kconfig~no_idle_hz arch/powerpc/Kconfig
--- linux-2.6.17-rc1/arch/powerpc/Kconfig~no_idle_hz 2006-04-09 10:40:59.000000000 +0530
+++ linux-2.6.17-rc1-root/arch/powerpc/Kconfig 2006-04-09 10:40:59.000000000 +0530
@@ -593,6 +593,12 @@ config HOTPLUG_CPU
Say N if you are unsure.
+config NO_IDLE_HZ
+ depends on EXPERIMENTAL && (PPC_PSERIES || PPC_PMAC || PPC_MAPLE)
+ bool "Switch off timer ticks on idle CPUs"
+ help
+ Switches the HZ timer interrupts off when a CPU is idle.
+
config KEXEC
bool "kexec system call (EXPERIMENTAL)"
depends on PPC_MULTIPLATFORM && EXPERIMENTAL
diff -puN arch/powerpc/kernel/traps.c~no_idle_hz arch/powerpc/kernel/traps.c
--- linux-2.6.17-rc1/arch/powerpc/kernel/traps.c~no_idle_hz 2006-04-09 10:40:59.000000000 +0530
+++ linux-2.6.17-rc1-root/arch/powerpc/kernel/traps.c 2006-04-09 10:40:59.000000000 +0530
@@ -875,6 +875,7 @@ void altivec_unavailable_exception(struc
void performance_monitor_exception(struct pt_regs *regs)
{
+ start_hz_timer(regs);
perf_irq(regs);
}
diff -puN arch/powerpc/platforms/pseries/setup.c~no_idle_hz arch/powerpc/platforms/pseries/setup.c
--- linux-2.6.17-rc1/arch/powerpc/platforms/pseries/setup.c~no_idle_hz 2006-04-09 10:40:59.000000000 +0530
+++ linux-2.6.17-rc1-root/arch/powerpc/platforms/pseries/setup.c 2006-04-09 10:40:59.000000000 +0530
@@ -463,8 +463,10 @@ static void pseries_dedicated_idle_sleep
* very low priority. The cede enables interrupts, which
* doesn't matter here.
*/
- if (!lppaca[cpu ^ 1].idle || poll_pending() == H_PENDING)
+ if (!lppaca[cpu ^ 1].idle || poll_pending() == H_PENDING) {
+ stop_hz_timer();
cede_processor();
+ }
out:
HMT_medium();
@@ -479,6 +481,8 @@ static void pseries_shared_idle_sleep(vo
*/
get_lppaca()->idle = 1;
+ stop_hz_timer();
+
/*
* Yield the processor to the hypervisor. We return if
* an external interrupt occurs (which are driven prior
diff -puN arch/powerpc/kernel/idle_power4.S~no_idle_hz arch/powerpc/kernel/idle_power4.S
--- linux-2.6.17-rc1/arch/powerpc/kernel/idle_power4.S~no_idle_hz 2006-04-09 10:40:59.000000000 +0530
+++ linux-2.6.17-rc1-root/arch/powerpc/kernel/idle_power4.S 2006-04-10 14:50:36.000000000 +0530
@@ -30,6 +30,11 @@ END_FTR_SECTION_IFCLR(CPU_FTR_CAN_NAP)
cmpwi 0,r4,0
beqlr
+ mflr r0
+ std r0,16(r1)
+ bl .stop_hz_timer
+ ld r0,16(r1)
+ mtlr r0
/* Go to NAP now */
BEGIN_FTR_SECTION
DSSALL
_
--
Regards,
vatsa
^ permalink raw reply
* Re: Black box flight recorder for Linux
From: linux-os (Dick Johnson) @ 2006-04-10 12:18 UTC (permalink / raw)
To: Andi Kleen; +Cc: Robert Hancock, linux-kernel
In-Reply-To: <200604080917.39562.ak@suse.de>
On Sat, 8 Apr 2006, 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
Further, in a boot where the BIOS needs to initialize hardware,
It will write all RAM before enabling NMI. This makes sure that
the parity bit(s) are set properly. Most BIOS will attempt to
preserve RAM on a 'warm' boot as a throw-back to the '286 days
with their above-1MB-memory-manager paged RAM because the
only way to get back from protected mode to 16-bit real mode
was a hardware reset. When using a memory-manager like DOS's
HIMEM.SYS, you might actually be rebooting the machine hundreds
of times per second!
If you want to make a flight-data recorder, you need to use
FAA specs and, as such, you can't rely on second-order effects.
You will need write all the parameters to flash (or equivalent)
at least 10 times per second. I would advise against putting
a file-system on the flash because the file-system might get
corrupt because of a bad write during a crash. Instead, I would
write a large number of identical groups of parameters (a structure
image) at a large number of raw offsets, each with the required
time-stamp. This, done the required 10 times per second.
Note that the NTSB, in investigating some light airplane accidents,
has been successful extracting data from hand-held GPS receivers
and FADEC controllers, so using flash RAM for accident investigation
has some successful history (useful for obtaining certification).
I once proposed a FDR for light aircraft that would cost the end-user
under $2,000. This was to use a small embedded CPU, raw NAV inputs
from the panel, a cheap accelerometer, and some pressure sensors
for altimetry. This would be mounted in the tail, requiring no
user (pilot) input at all. In the event of a crash, the last
hour of flight could be retrieved.
Typical response; "There is no market for this...."
Good luck!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: SuSE 10.0 and it's RPM 4.1.1??
From: Yawar Amin @ 2006-04-10 12:16 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <200604081200.09659.sotl155360@earthlink.net>
On 4/9/06, SOTL <sotl155360@earthlink.net> wrote:
> On Saturday 08 April 2006 03:57 am, you wrote:
[...]
> > Believe it or not, RPM stands for RPM Package Manager.
> >
>
> Keep on Dreaming
>
> Original meaning was RedHat Package Manager.
>
> SOTL
That may well be, but according to
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/custom-guide/ch-rpm.html,
RPM stands for RPM Package Manager.
--
Yawar
Malaysia +60 (12) 918 6642
Bangladesh +880 (174) 614 754 or +880 (2) 882 1848 or +880 (175) 003
706 or +880 (189) 250 170
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Diff between Linus' and linux-mips git: elf.h
From: Thiemo Seufer @ 2006-04-10 12:27 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Kevin D. Kissell, Martin Michlmayr, linux-mips
In-Reply-To: <20060407222142.GA26104@linux-mips.org>
Ralf Baechle wrote:
> On Fri, Apr 07, 2006 at 07:47:40PM +0200, Kevin D. Kissell wrote:
>
> > Arguably, whatever's used by binutils should be the tie-breaker.
> > Googling around, I see that the EM_MIPS_RS3_LE value was
> > added in the October 4, 1999 draft of the ELF spec, but inexplicably
> > the alias with EM_MIPS_RS4_BE was left in place - perhaps they
> > were supposed to be disambiguated by some 32-vs-64-bit flag
> > somewhere. A random sampling of ELF documents on the web
> > shows the vast majority calling out RS3_LE and not RS4_BE.
>
> No way to actually resolve this one; not even binutils oldtimer
> Ian Lance Taylor can remember the reasons for the change anymore.
FWIW, the general rule is to use EM_MIPS == 8 for MIPS with both
endiannesses and ignore EM_MIPS_*. So removing the other defines
from the linux include file seems to be the sensible thing to do.
(Binutils can't do the same due to backward compatibility concerns.)
Thiemo
^ 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.