* [Buildroot] ARM OABI/EABI problem
From: Michael S. Zick @ 2009-12-09 15:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87ws0wl0v8.fsf@macbook.be.48ers.dk>
On Wed December 9 2009, Peter Korsgaard wrote:
> >>>>> "peter" == peter stosz <peter.stosz@mentat.hu> writes:
>
> Hi,
>
> peter> Please explain me, how to build complete OABI 'style' sytem to
> peter> ARM (RM9200) target.
>
> peter> I try to compile a minimal Linux 2.6.27 with Busybox 1.15
> peter> system. I must OABI, because I need Floating Point Emulator,
> peter> but it depends on !AEABI || OABI_COMPAT
>
> Really? Softfloat is a lot faster than kernel emulation.
>
> peter> As you see (on Build option section) I leave
> peter> BR2_GNU_TARGET_SUFFIX on the default "linux-uclibcgnueabi" When
> peter> I change it to "linux-uclibc", I get the following error:
>
> You should use linux-uclibc for OABI.
>
> peter> warning: working around missing syslimits.h
> peter> cp: stat ?/srv/buildroot/output/staging/lib/gcc-lib/arm-linux-uclibc/4.4.2/
> peter> include/syslimits.h? sikertelen: Nincs ilyen f?jl vagy k?nyvt?r <-- No such
> peter> file or directory
> peter> make: *** [/srv/buildroot/output/target/usr/bin/gcc] Error 1
>
> Hmm, could you try with gcc 4.3.4? I've compiled OABI with 4.3.4 without
> problems, but I've never tried 4.4.x.
>
> Remember to run make clean after any toolchain changes.
>
> peter> Build environment:
> peter> Ubuntu 9.10 x64 (Hungarian)
> peter> bash, not dash
> peter> make as root
>
Ah, that may be part of your problem, I did that (by mistake)
several times.
Make sure to change the entire tree back to owned as your own
user name, then *only* work under your own username!
chown -R usrname:usrname *
from the top of the build tree.
If using a GIT clone, you can also get things screwed up if
you do your updates (pull) as root - always do those as
your own user name.
*never* run any build system as "root" - -
All it takes is one typo in the wrong place and your entire
machines software installation might as well be in /dev/null
Mike
> Don't do that! Buildroot is designed to work without root permissions,
> and I give absolutely NO guarantee that we won't make a mistake and
> accidently overwrite/delete something, especially if you use a git
> snapshot.
>
> peter> Buildroot 2009.11
> peter> 2nd error message on BR daily snapshot (091205)
>
^ permalink raw reply
* Re: [REROLL PATCH 2/8] Support mandatory capabilities
From: Ilari Liusvaara @ 2009-12-09 15:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl5t59bp.fsf@alter.siamese.dyndns.org>
On Tue, Dec 08, 2009 at 03:34:34PM -0800, Junio C Hamano wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> > + fflush(stderr);
> > + die("Unknown madatory capability %s. This remote "
> > + "helper probably needs newer version of Git.\n",
> > + capname);
>
> Why fflush() here? Is the reason for needing to flush stderr before
> letting die() to write into it very specific to this codepath, or shared
> among other callers of die()? I am wondering if we should add this
> fflush() to report() in usage.c instead.
No idea why its there (anymore). Die will flush stderr anyway via exit.
Removed.
-Ilari
^ permalink raw reply
* Re: [ANNOUNCE] Feature freeze for Xen 4.0
From: Keir Fraser @ 2009-12-09 15:12 UTC (permalink / raw)
To: Thiago Camargo Martins Cordeiro; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <6b7f6eb0912090615g26edc65fx2ef68978e5945be9@mail.gmail.com>
The two are on separate release schedules. We will build the pv_ops kernel
by default when building Xen 4.0 from source, but there's no greater
significance than that. However, Jeremy's pv_ops tree (which of course
tracks mainline) should work well for most dom0 and domU applications.
-- Keir
On 09/12/2009 14:15, "Thiago Camargo Martins Cordeiro"
<thiagocmartinsc@gmail.com> wrote:
> The Xen 4.0 will be release with a stable pv_ops dom0 included in mainline
> Linux?
>
> Thanks,
> Thiago
>
> 2009/12/9 Keir Fraser <keir.fraser@eu.citrix.com>
>> Lots of new features have recently made it into the xen-unstable tree, and I
>> think now is the time to declare a freeze so that we can get 4.0 out the
>> door early in the New Year. If you're sitting on any feature patches,
>> declare them or send them on now - I want to freeze the tree except for any
>> agreed special cases at the end of the week.
>>
>> -- Keir
>>
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
^ permalink raw reply
* Re: pass upstream rev to scripts/get_maintainer.pl
From: Mark Brown @ 2009-12-09 15:11 UTC (permalink / raw)
To: Joe Perches; +Cc: Uwe Kleine-K?nig, Andrew Morton, linux-kernel
In-Reply-To: <1260368582.27319.32.camel@Joe-Laptop.home>
On Wed, Dec 09, 2009 at 06:23:02AM -0800, Joe Perches wrote:
> On Wed, 2009-12-09 at 14:13 +0000, Mark Brown wrote:
> > With the limit on the number of people returned it's possible that
> > authors of the patch series being posted (there may be more than one)
> > will push out folks that it'd be good to include.
> You could use --git-max-maintainers=<value more than default>
Of course, for that use case the patch is just a potentially clearer
idiom for doing it.
^ permalink raw reply
* Re: Networking-related crash?
From: Avi Kivity @ 2009-12-09 15:11 UTC (permalink / raw)
To: Adam Huffman; +Cc: kvm, netdev
In-Reply-To: <608c44bf0912090546s446bf973ne408e99661fdc56f@mail.gmail.com>
On 12/09/2009 03:46 PM, Adam Huffman wrote:
> I've been seeing lots of crashes on a new Dell Precision T7500,
> running the KVM in Fedora 12. Finally managed to capture an Oops,
> which is shown below (hand-transcribed):
>
> BUG: unable to handle kernel paging request at 0000000000200200
> IP: [<ffffffff8139aab7>] destroy_conntrack+0x82/0x11f
> PGD 332d0e067 PUD 33453c067 PMD 0
> Oops: 0002 [#1] SMP
> last sysfs file: /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map
> CPU 4
> Modules linked in: tun bridge stp llc sunrpc ipt_MASQUERADE
> iptable_nat nf_nat ipt_LOG xt_physdev ip6t_REJECT nf_conntrack_ipv6
> ip6table_filter ip6
> _tables ipv6 dm_multipath kvm_intel kvm uinput snd_hda_codec_analog
> nouveau snd_hda_intel snd_hda_codec ttm drm_kms_helper snd_hwdep
> snd_seq drm sn
> d_seq_device snd_pcm firewire_ohci i2c_i801 snd_timer ppdev
> firewire_core snd i2c_algo_bit iTCO_wdt crc_itu_t parport_pc i2c_core
> soundcore parport
> iTCO_vendor_support tg3 snd_page_alloc shpchp dcdbas wmi mptsas
> mptscsih mptbase scsi_transport_sas megaraid_sas [last_unloaded:
> speedstep_lib]
> Pid: 1759, comm: qemu-kvm Not tainted 2.6.31.6-162.fc12.x86_64 #1
> Precision WorkStation T7500
> RIP: 0010:[<ffffffff8139aab7>] [<ffffffff8139aab7>]
> destroy_conntrack+0x82/0x11f
> RSP: 0018:ffffc90000803bf0 EFLAGS: 00010202
> RAX: 0000000080000001 RBX: ffffffff816fb1a0 RCX: 000000000000752f
> RDX: 0000000000200200 RSI: 0000000000000011 RDI: ffffffff816fb1a0
> RBP: ffffc90000803c00 R08: ffff880336699438 R09: 0000000000aaa5e0
> R10: 00000002f54189d5 R11: 0000000000000001 R12: ffffffff819a92e0
> R13: ffffffffa029adcc R14: 0000000000000000 R15: ffff880632866c38
> FS: 00007fdd34b17710(0000) GS:ffffc90000800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 002B ES: 002B CR0: 0000000080050033
> CR2: 0000000000200200 CR3: 00000003349c0000 CR4: 00000000000026e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process qemu-kvm (pid: 1759, threadinfo ffff88062e9e8000, task ffff880634945e00)
> Stack:
> ffff880632866c00 ffff880634640c30 ffffc90000803c10 ffffffff813989c2
> <0> ffffc90000803c30 ffffffff81374092 ffffc90000803c30 ffff880632866c00
> <0> ffffc90000803c50 ffffffff81373dd3 0000000200000000 ffff880632866c00
> Call Trace:
> <IRQ>
> [<ffffffff813989c2>] nf_conntrack_destroy+0x1b/0x1d
> [<ffffffff81374092>] skb_release_head_state+0x95/0xd7
> [<ffffffff81373dd3>] __kfree_skb+0x16/0x81
> [<ffffffff81373ed7>] kfree_skb+0x6a/0x72
> [<ffffffffa029adcc>] ip6_mc_input+0x220/0x230 [ipv6]
> [<ffffffffa029a3d1>] ip6_rcv_finish+0x27/0x2b [ipv6]
> [<ffffffffa029a763>] ipv6_rcv+0x38e/0x3e5 [ipv6]
> [<ffffffff8137bd91>] netif_receive_skb+0x402/0x427
> [<ffffffff8137bf1b>] napi_skb_finish+0x29/0x3d
> [<ffffffff8137c37a>] napi_gro_receive+0x2f/0x34
> [<ffffffffa0084fad>] tg3_poll+0x6c6/0x8c3 [tg3]
> [<ffffffff8137c4b0>] net_rx_action+0xaf/0x1c9
> [<ffffffff81379cfe>] ? list-add_tail+0x15/0x17
> [<ffffffff81057614>] __do_softirq+0xdd/0x1ad
> [<ffffffff81026936>] ? apic_write+0x16/0x18
> [<ffffffff81012eac>] call_softirq+0x1c/0x30
> [<ffffffff810143fb>] do_softirq+0x47/0x8d
> [<ffffffff81057326>] irq_exit+0x44/0x86
> [<ffffffff8141ecd5>] do_IRQ+0xa5/0xbc
> [<ffffffff810126d3>] ret_from_intr+0x0/0x11
> <EOI>
> [<ffffffffa02437bb>] ? kvm_arch_vcpu_ioctl_run+0x84b/0xb34 [kvm]
> [<ffffffffa02437aa>] ? kvm_arch_vcpu_ioctl_run+0x83a/0xb34 [kvm]
> [<ffffffffa02395e3>] ? kvm_vcpu_ioctl+0xfd/0x556 [kvm]
> [<ffffffff81108adc>] ? vfs_ioctl+0x22/0x87
> [<ffffffff81109038>] ? do_vfs_ioctl+0x47b/0x4c1
> [<ffffffff811090d4>] ? sys_ioctl+0x56/0x79
> [<ffffffff81012093>] ? stub_clone+0x13/0x20
> [<ffffffff81011cf2>] ? system_call_fastpath+0x16/0x1b
> Code: c7 00 a6 9a 81 e8 23 04 08 00 48 89 df e8 68 29 00 00 f6 43 78
> 08 75 24 48 8b 53 10 48 85 d2 75 04 0f 0b eb fe 48 8b 43 08 a8 01<48>
> 89 02 7
> 5 04 48 89 50 08 48 c7 43 10 00 02 20 00 65 8b 14 25
> RIP [<ffffffff8139aab7>] destroy_conntrack+0x82/0x11f
> RSP<ffffc90000803bf0>
> CR2: 0000000000200200
>
Looks unrelated to kvm - softirq happened to trigger during a kvm
ioctl. Fault looks like list poison. Copying netdev.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply
* Re: linux-next: manual merge of the tty tree with the trivial tree
From: Stephen Rothwell @ 2009-12-09 15:11 UTC (permalink / raw)
To: Jiri Kosina
Cc: Greg KH, linux-next, linux-kernel, Thadeu Lima de Souza Cascardo
In-Reply-To: <alpine.LNX.2.00.0912091536230.3755@pobox.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
Hi Jiri,
On Wed, 9 Dec 2009 15:38:19 +0100 (CET) Jiri Kosina <jkosina@suse.cz> wrote:
>
> On Wed, 9 Dec 2009, Stephen Rothwell wrote:
>
> > I just used the tty tree version where they clashed. Jiri, you might
> > consider sending that patch to Greg for the tty tree.
>
> the trivial tree pull request has already been sent to Linus a day ago. I
> am now waiting whether it will be merged or missed.
>
> In the latter case, I will split the tty hunk out and send to Greg. In the
> former case the conflict would have to be solved either by Greg or Linus.
OK, that's fine, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Octopus merge
From: Claudia.Ignat @ 2009-12-09 15:10 UTC (permalink / raw)
To: Michael J Gruber, Thomas Rast; +Cc: git
In-Reply-To: <4B0EB257.8080002@drmicha.warpmail.net>
Michael and Thomas, thank you for your explanations. The fact that in
some cases octopus merge fails, but changes of the first merges subparts
of octopus merge are included in the worktree rests a dilemma.
Further, I have noticed that for the same conflicting changes the
conflict messages (referring to conflict types) received in the case of
an octopus merge are not the same as the conflict messages received for
the corresponding sequential merges.
I slightly changed the scenario I described in my previous message.
Workspaces ws2, ws3 and ws4 are clones of the workspace ws1. Suppose the
current workspace is ws3 and some changes are done in parallel in all
these 3 workspaces. Changes of ws2 and ws3 are conflicting: both modify
the same line of file file1.txt to different values and they rename the
same file file2.txt to fileWS2.txt and fileWS3.txt respectively. Changes
in ws4 are not conflicting with changes in ws2 and ws3.
While I am in the current workspace ws3 I perform the merge
git merge ws2
and content conflict in file1.txt as well as rename/rename conflict are
signaled.
If instead I perform the merge
git merge ws4 ws2
only the content conflict in file1.txt is raised, while the conflict
rename/rename of file2.txt is not mentioned.
The script for the second mentioned scenario is given below.
Do you think this should be the normal behavior of octopus merge?
Thanks.
Cheers,
Claudia
# !/bin/bash
TEST_NAME="TP1" # name of the working directory
rm -rf ${TEST_NAME} # cleaning working directory
mkdir -p ${TEST_NAME}
cd ${TEST_NAME}
# initialising initial git workspace
mkdir ws1
cd ws1
git init
# adding 2 files to ws1
# commit changes
echo -e -n "1\n2\n3\n4\n5\n" > file1.txt
echo -e -n "a\nb\nc\nd\ne\n" > file2.txt
git add file1.txt file2.txt
git commit -m "ws1 | add 12345 in file1.txt; add abcde in file2.txt"
cd ..
# cloning three times ws1 (as ws2, ws3 and ws4)
git clone ws1 ws2
git clone ws1 ws3
git clone ws1 ws4
# updating file1.txt in ws2 (insert X at line 3, then write and quit 'ed')
# rename file2.txt to fileWS2.txt
# commit changes
cd ws2
echo -e "3i\nX\n.\nw\nq\n" | ed file1.txt
git add file1.txt
git mv file2.txt fileWS2.txt
git commit -m "ws2 | insert 12X345 in file1.txt; rename file2.txt to
fileWS2.txt"
cd ..
# updating file1.txt in ws3 (insert Y at line 3, then write and quit 'ed')
# rename file2.txt to fileWS3.txt
# commit changes
cd ws3
echo -e "3i\nY\n.\nw\nq\n" | ed file1.txt
git add file1.txt
git mv file2.txt fileWS3.txt
git commit -m "ws3 | insert 12Y345 in file1.txt; rename file2.txt to
fileWS3.txt"
cd ..
# add file u.txt in ws4
cd ws4
echo -e -n "U1\n2\n3\n4\n5\n" > u.txt
git add u.txt
git commit -m "ws4 | add u.txt"
cd ..
# ws3 pull from ws2 ws4
cd ws3
git remote add bws2 ../ws2
git remote add bws4 ../ws4
git fetch bws2
git fetch bws4
git merge bws4/master bws2/master
cd ..
Michael J Gruber wrote:
> Claudia.Ignat@loria.fr venit, vidit, dixit 26.11.2009 16:56:
>> # !/bin/bash
>> TEST_NAME="TP1" # name of the working directory
>> rm -rf ${TEST_NAME} # cleaning working directory
>> mkdir -p ${TEST_NAME}
>> cd ${TEST_NAME}
>>
>> # initialising initial git workspace
>> mkdir ws1
>> cd ws1
>> git init
>>
>> # adding a file to ws1
>> # commit changes
>> echo -e -n "1\n2\n3\n4\n5\n" > file.txt
>> git add file.txt
>> git commit -m "ws1 | add 12345"
>> cd ..
>>
>> # cloning three times ws1 (as ws2, ws3 and ws4)
>> git clone ws1 ws2
>> git clone ws1 ws3
>> git clone ws1 ws4
>> git clone ws1 ws5
>>
>> # updating file.txt in ws2 (insert X at line 3, then write and quit 'ed')
>> # commit changes
>> cd ws2
>> echo -e "3i\nX\n.\nw\nq\n" | ed file.txt
>> git add file.txt
>> git commit -m "ws2 | insert 12X345"
>> cd ..
>>
>>
>> # updating file.txt in ws3 (insert Y at line 3, then write and quit 'ed')
>> # commit changes
>> cd ws3
>> echo -e "3i\nY\n.\nw\nq\n" | ed file.txt
>> git add file.txt
>> git commit -m "ws3 | insert 12Y345"
>> cd ..
>>
>> cd ws4
>> echo -e -n "U1\n2\n3\n4\n5\n" > u.txt
>> git add u.txt
>> git commit -m "ws4 | add u.txt"
>> cd ..
>>
>> cd ws5
>> echo -e -n "W1\n2\n3\n4\n5\n" > w.txt
>> git add w.txt
>> git commit -m "ws5 | add w.txt"
>> cd ..
>>
>> # ws3 pull from ws2 ws4 ws5
>> cd ws3
>> git remote add bws2 ../ws2
>> git remote add bws4 ../ws4
>> git remote add bws5 ../ws5
>> git fetch bws2
>> git fetch bws4
>> git fetch bws5
>> git merge bws4/master bws2/master bws5/master
>> cd ..
>>
>> # resolve conflict in ws3
>> cd ws3
>
> First of all, thanks for the clear description and test case!
>
> The octopus strategy cannot do merges which need manual resolution. Or
> so the doc says. After trying the merge with 4 2 5, Git tells you:
>
> Trying simple merge with 7ff9b5bd514cb600bac935ebd40eae366bba7d19
> Trying simple merge with 6872cd350154743d59cb4d313cbdb122ac43e537
> Simple merge did not work, trying automatic merge.
> Auto-merging file.txt
> ERROR: content conflict in file.txt
> fatal: merge program failed
> Automated merge did not work.
> Should not be doing an Octopus.
> Merge with strategy octopus failed.
>
> That is, it aborts the merge completely. If you "resolve" it and commit
> it's simply a commit that you make.
>
> If, instead, you merge 4 5 2, Git tells you:
>
> Trying simple merge with e4f78f6905bed39bcd96790a4f63e138a455a445
> Trying simple merge with 14c1f2a70767334df5d6d3120631752564094699
> Trying simple merge with 8540a039d3fc964d097d4f037357668441d1d4f5
> Simple merge did not work, trying automatic merge.
> Auto-merging file.txt
> ERROR: content conflict in file.txt
> fatal: merge program failed
> Automatic merge failed; fix conflicts and then commit the result.
>
> Admittedly this looks fatal also, but the last line tells you that the
> actual merge process is not aborted yet. If you resolve the conflict and
> commit without -m you even see the prepared commit message.
>
> So, octopus can deal with manual conflict resolution if the conflicts
> appear in the last step only. That is the difference between the two cases.
>
> Now, in the first case the aborted merge leaves some traces in the index
> as well as in the worktree. I'm not sure that is how it's supposed to be.
>
> Cheers,
> Michael
^ permalink raw reply
* Re: [PATCH] NTFS: Change string pointers to string constants.
From: walter harms @ 2009-12-09 15:07 UTC (permalink / raw)
To: Marcin Slusarz
Cc: Joe Perches, Anton Altaparmakov, John Daiker, kernel-janitors,
aia21, linux-ntfs-dev, LKML
In-Reply-To: <20091209145846.GA3562@joi.lan>
Marcin Slusarz schrieb:
> On Mon, Dec 07, 2009 at 05:47:13PM -0800, Joe Perches wrote:
>> On Tue, 2009-12-08 at 00:57 +0000, Anton Altaparmakov wrote:
>>> Can you please explain the rational for making this change?
>> Perhaps it's not worth much, but it saves a pointer reference.
>>
>> $ cat pointer.c
>> #include <string.h>
>> #include <stdio.h>
>>
>> int main (int argc, char** argv)
>> {
>> static const char *foo = "abcdefg";
>> printf("%s\n", foo);
>> return 0;
>> }
>>
>> $ gcc -c pointer.c
>> $ size pointer.o
>> text data bss dec hex filename
>> 37 4 0 41 29 pointer.o
>>
>> $ cat reference.c
>> #include <string.h>
>> #include <stdio.h>
>>
>> int main (int argc, char** argv)
>> {
>> static const char foo[] = "abcdefg";
>> printf("%s\n", foo);
>> return 0;
>> }
>>
>> $ gcc -c reference.c
>> $ size reference.o
>> text data bss dec hex filename
>> 36 0 0 36 24 reference.o
>
> Yeah, for static variables it's better. But for automatic variables
> it's worse, because it now has to do a copy at runtime.
> And the patch changes both types.
>
> $ size pointer.o reference.o
> text data bss dec hex filename
> 101 8 0 109 6d pointer.o
> 96 0 0 96 60 reference.o
>
> $ size pointer-nonstatic.o reference-nonstatic.o
> text data bss dec hex filename
> 106 0 0 106 6a pointer-nonstatic.o
> 109 0 0 109 6d reference-nonstatic.o
> --
nobody should spend to much time on this. gcc <what ever next version>
will have different results. It is better to spend time improving
the compiler and make it generate shorter/faster code.
just my 2 cents,
wh
^ permalink raw reply
* Re: [Xenomai-help] xenomai 2.4.10 - invalid opcode: 0000
From: Petr Cervenka @ 2009-12-09 15:08 UTC (permalink / raw)
To: Petr Cervenka; +Cc: xenomai-help
In-Reply-To: <4B1E6B1B.5080306@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
I want to apologize myself, I forgot to attach the file with the error logs.
Petr Cervenka
Petr Cervenka wrote:
>
>Jan Kiszka wrote:
>>
>>Petr Cervenka wrote:
>>> Hello,
>>> I tried to upgrade linux kernel and xenomai and now I have problems with
>>> freezing computer because of "invalid opcode: 0000".
>>> It happens without any real-time app. running. Most often when I run X
>>> with KDE and netbeans (almost 100% probability), but it can freeze also
>>> during the boot.
>>> It perhaps depends on system load (CPU, disk, IO, ...?).
>>>
>>> My configuration:
>>> SW:
>>> linux kernel 2.6.30.9, arch: x86_64
>>> xenomai-2.4.10, smp
>>>
>>> also:
>>> rtnet-0.9.11 - no driver loaded
>>> peak-linux-driver-6.11 - no device connected
>>>
>>> HW:
>>> CPU: Intel Core2Duo E7400
>>> chipset: Intel 3210
>>> system partition is on CF (compact flash) mounted in CF-SATA converter.
>>>
>>> Do you have any advices or tips? Thanks in advice.
>>> I can provide you by any needed information (.config of linux kernel,
>>> full systemlog, ...), just ask me.
>>
>>Yes, please. I assume your system is otherwise stable (without
>>Xenomai/I-pipe enabled).
>>
>>It would also be nice if you could retry over 2.6.31.x with latest ipipe
>>patch. And try to switch on CONFIG_IPIPE_DEBUG_TRACE_MCOUNT. That may
>>give a function back-trace on oops, maybe providing more pointers where
>>we come from (but it may also make the issue disappear).
>>
>>Jan
>>
>
>1) When I disable Xenomai and I-pipe, the system is more or less stable. At least I was not able to produce the error (any error).
>I also ran memtest during the night without any error.
>
>2) It is repeatable also in 2.6.31.7. with adeos-ipipe-2.6.31.1-x86-2.4-08.patch
>
>3) Switching CONFIG_IPIPE_DEBUG_TRACE_MCOUNT on doesn't make the error to dissapear. So maybe the catched logs could provide you more info.
>
>I realized that the error could be different, but there is almost every time "__ipipe_handle_irq" call in the call stack
>
>Also a very strange thing happened: When I tried to build "stable" kernel with disabled Xenomai and I-pipe, I was booted in the "unstable" kernel. It corrupted the .config file in some time between "make xconfig" and freeze during building. When I checked the .config file next time (because it failed to continue the compile) big part from the beginning was missing and some other binary data were appended to the end.
>
>Petr Cervenka
[-- Attachment #2: _syslogs2.txt --]
[-- Type: text/plain, Size: 33546 bytes --]
[ 8.164025] BUG: unable to handle kernel paging request at 00000000ffffffd3
[ 8.170067] IP: [<ffff88000172a145>] 0xffff88000172a145
[ 8.171434] PGD 7d68a067 PUD 0
[ 8.177172] Oops: 0002 [#1] PREEMPT SMP
[ 8.183527] last sysfs file: /sys/devices/pnp0/00:02/id
[ 8.186600] CPU 1
[ 8.186600] Modules linked in: psmouse serio_raw iTCO_wdt iTCO_vendor_support container e1000e button evdev ext3 jbd mbcache sg sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore fan thermal_sys fuse
[ 8.186600] Pid: 2806, comm: udevd Not tainted 2.6.31.7-adeos #1 X7SBA
[ 8.186600] RIP: 0010:[<ffff88000172a145>] [<ffff88000172a145>] 0xffff88000172a145
[ 8.186600] RSP: 0018:ffff880001716cd0 EFLAGS: 00014693
[ 8.186600] RAX: 00000000ffffffd3 RBX: 0000000000000282 RCX: ffffffff81660b00
[ 8.186600] RDX: ffff880001713000 RSI: ffff880037a02080 RDI: 0000000080000001
[ 8.186600] RBP: ffff88007d4e54e0 R08: 0000000000000000 R09: 0000000000000000
[ 8.186600] R10: 0000000000000002 R11: 00000000ffffffff R12: 000000000000d120
[ 8.186600] R13: ffff88007d4e75b0 R14: ffff88007d4e7330 R15: ffff88007d4e54e0
[ 8.186600] FS: 00007f166a4656e0(0000) GS:ffff880001713000(0000) knlGS:0000000000000000
[ 8.186600] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 8.186600] CR2: 00000000ffffffd3 CR3: 0000000037a12000 CR4: 00000000000406e0
[ 8.186600] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8.296212] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 8.297011] Process udevd (pid: 2806, threadinfo ffff88007d606000, task ffff88007d75d4e0)
[ 8.297011] Stack:
[ 8.297011] 0000000000000001 000000000000020e ffff880001716d10 ffffffff8103c7f4
[ 8.297011] <0> ffff880001716d10 ffff88000172a140 0000000000000001 0000000000000000
[ 8.297011] <0> ffff880001716dd0 0000000000000086 000000000000d120 0000000000000282
[ 8.297011] Call Trace:
[ 8.297011] <IRQ>
[ 8.297011] [<ffffffff8103c7f4>] ? pick_next_task_fair+0x84/0xb0
[ 8.297011] [<ffffffff81021490>] ? smp_reschedule_interrupt+0x0/0x20
[ 8.354004] [<ffffffff81029435>] ? __ipipe_preempt_schedule_irq+0x95/0x1a0
[ 8.354004] [<ffffffff81021490>] ? smp_reschedule_interrupt+0x0/0x20
[ 8.354004] [<ffffffff8100cb46>] ? retint_kernel+0x26/0x30
[ 8.354004] [<ffffffff81094109>] ? __ipipe_sync_stage+0x1c9/0x2ec
[ 8.354004] [<ffffffff81094836>] ? __ipipe_walk_pipeline+0x146/0x290
[ 8.354004] [<ffffffff81028f04>] ? __ipipe_handle_irq+0x384/0x4b0
[ 8.354004] [<ffffffff8100d009>] ? reschedule_interrupt+0x39/0x60
[ 8.354004] <EOI>
[ 8.354004] Code: Bad RIP value.
[ 8.354004] RIP [<(null)>] (null)
[ 8.354004] RSP <000000000000d120>
[ 8.354004] CR2: 00000000ffffffd3
[ 8.416972] ---[ end trace 7d6706abc126d1eb ]---
[ 8.433702] ------------[ cut here ]------------
[ 8.434250] kernel BUG at kernel/exit.c:1015!
[ 8.434250] invalid opcode: 0000 [#2] PREEMPT SMP
[ 8.434250] last sysfs file: /sys/devices/pnp0/00:02/id
[ 8.434250] CPU 1
[ 8.434250] Modules linked in: psmouse serio_raw iTCO_wdt iTCO_vendor_support container e1000e button evdev ext3 jbd mbcache sg sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore fan thermal_sys fuse
[ 8.434250] Pid: 2806, comm: udevd Tainted: G D 2.6.31.7-adeos #1 X7SBA
[ 8.434250] RIP: 0010:[<ffffffff81051618>] [<ffffffff81051618>] do_exit+0x528/0x840
[ 8.434250] RSP: 0018:ffff8800017169f8 EFLAGS: 00010296
[ 8.434250] RAX: 0000000000000000 RBX: 0000000000000012 RCX: ffffffff81660b00
[ 8.434250] RDX: ffff880001713000 RSI: ffff88007fb90000 RDI: 0000000080000001
[ 8.434250] RBP: ffff880001716a58 R08: ffff88007d606000 R09: 0000000000000000
[ 8.434250] R10: ffff88007d75d518 R11: 00000000ffffffff R12: ffff88007d75d4e0
[ 8.434250] R13: ffff88007d75dc88 R14: ffff88007fb90000 R15: ffff88007d75d4d0
[ 8.434250] FS: 00007f166a4656e0(0000) GS:ffff880001713000(0000) knlGS:0000000000000000
[ 8.434250] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 8.434250] CR2: ffffffffffffffd5 CR3: 00000000378d0000 CR4: 00000000000406e0
[ 8.434250] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8.434250] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 8.434250] Process udevd (pid: 2806, threadinfo ffff88007d606000, task ffff88007d75d4e0)
[ 8.434250] Stack:
[ 8.434250] 0000000000000000 ffff880001716a18 ffff88007d75d668 0000000100000000
[ 8.434250] <0> ffff880001716a18 ffff880001716a18 0000000000000002 0000000000000000
[ 8.434250] <0> ffff880001716c28 0000000000000009 0000000000000002 0000000000000200
[ 8.434250] Call Trace:
[ 8.434250] <IRQ>
[ 8.434250] [<ffffffff81011329>] oops_end+0xe9/0xf0
[ 8.434250] [<ffffffff810316fc>] no_context+0x15c/0x250
[ 8.434250] [<ffffffff8103199c>] __bad_area_nosemaphore+0xec/0x1d0
[ 8.434250] [<ffffffff8120c656>] ? __up_read+0x46/0xb0
[ 8.434250] [<ffffffff81031ad4>] __bad_area+0x54/0x70
[ 8.434250] [<ffffffff81031b23>] bad_area+0x13/0x20
[ 8.434250] [<ffffffff81032014>] do_page_fault+0x254/0x2a0
[ 8.434250] [<ffffffff81029abf>] __ipipe_handle_exception+0x1af/0x660
[ 8.434250] [<ffffffff81360106>] page_fault+0x26/0x70
[ 8.434250] [<ffffffff8135cbac>] ? thread_return+0xe6/0x8ca
[ 8.434250] [<ffffffff81021490>] ? smp_reschedule_interrupt+0x0/0x20
[ 8.434250] [<ffffffff81029435>] ? __ipipe_preempt_schedule_irq+0x95/0x1a0
[ 8.434250] [<ffffffff81021490>] ? smp_reschedule_interrupt+0x0/0x20
[ 8.434250] [<ffffffff8100cb46>] ? retint_kernel+0x26/0x30
[ 8.434250] [<ffffffff81094109>] ? __ipipe_sync_stage+0x1c9/0x2ec
[ 8.434250] [<ffffffff81094836>] ? __ipipe_walk_pipeline+0x146/0x290
[ 8.434250] [<ffffffff81028f04>] ? __ipipe_handle_irq+0x384/0x4b0
[ 8.434250] [<ffffffff8100d009>] ? reschedule_interrupt+0x39/0x60
[ 8.434250] <EOI>
[ 8.434250] Code: 10 00 48 c7 c7 00 0b 66 81 e8 a5 22 04 00 65 48 8b 04 25 c8 b4 00 00 83 80 44 e0 ff ff 01 49 c7 04 24 40 00 00 00 e8 a8 b1 30 00 <0f> 0b eb fe 41 39 94 24 b8 04 00 00 0f 85 de fe ff ff 83 fe ff
[ 8.434250] RIP [<ffffffff81051618>] do_exit+0x528/0x840
[ 8.434250] RSP <ffff8800017169f8>
[ 8.745898] ---[ end trace 7d6706abc126d1ec ]---
[ 8.750641] Fixing recursive fault but reboot is needed!
[ 8.756230] note: udevd[2806] exited with preempt_count 268435457
[ 8.762489] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
[ 8.763477] IP: [<ffffffff810511c9>] do_exit+0xd9/0x840
[ 8.763477] PGD 7d11e067 PUD 7e409067 PMD 0
[ 8.763477] Oops: 0002 [#3] PREEMPT SMP
[ 8.763477] last sysfs file: /sys/devices/pnp0/00:02/id
[ 8.763477] CPU 0
[ 8.763477] Modules linked in: psmouse serio_raw iTCO_wdt iTCO_vendor_support container e1000e button evdev ext3 jbd mbcache sg sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore fan thermal_sys fuse
[ 8.763477] Pid: 2806, comm: udevd Tainted: G D 2.6.31.7-adeos #1 X7SBA
[ 8.763477] RIP: 0010:[<ffffffff810511c9>] [<ffffffff810511c9>] do_exit+0xd9/0x840
[ 8.763477] RSP: 0000:ffff880001716728 EFLAGS: 00010282
[ 8.763477] RAX: 0000000000000000 RBX: 000000000000000b RCX: ffffffff81660b00
[ 8.763477] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000080000001
[ 8.763477] RBP: ffff880001716788 R08: 00000000ffffffff R09: 0000000000000000
[ 8.763477] R10: 000000000000000a R11: 0000000000000006 R12: ffff88007d75d4e0
[ 8.763477] R13: 000000000000000b R14: 0000000000000200 R15: 0000000000000004
[ 8.763477] FS: 00007f166a4656e0(0000) GS:ffff8800016f4000(0000) knlGS:0000000000000000
[ 8.763477] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 8.763477] CR2: 0000000000000004 CR3: 0000000037b91000 CR4: 00000000000406f0
[ 8.763477] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8.763477] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 8.763477] Process udevd (pid: 2806, threadinfo ffff88007d606000, task ffff88007d75d4e0)
[ 8.763477] Stack:
[ 8.763477] 0000000000000000 0000000000000004 ffff880001716758 0000000000000000
[ 8.763477] <0> ffff880001716948 000000000000000b 0000000000000200 0000000000000000
[ 8.763477] <0> ffff880001716948 000000000000000b 0000000000000200 0000000000000004
[ 8.763477] Call Trace:
[ 8.763477] Code: 25 00 b0 00 00 8b 88 44 e0 ff ff 8b 46 1c 89 ca f7 d0 81 e2 ff ff ff ef c1 e8 1f 39 c2 0f 85 4d 07 00 00 49 8b 84 24 40 04 00 00 <f0> ff 48 04 0f 94 c2 31 c0 84 d2 0f 95 c0 85 c0 89 45 bc 0f 84
[ 8.763477] RIP [<ffffffff810511c9>] do_exit+0xd9/0x840
[ 8.763477] RSP <ffff880001716728>
[ 8.763477] CR2: 0000000000000004
[ 8.974983] ---[ end trace 7d6706abc126d1ed ]---
[ 8.979727] Fixing recursive fault but reboot is needed!
...
=====================================================================================================
[ 127.021789] BUG: unable to handle kernel NULL pointer dereference at 000000000000021a
[ 127.022005] IP: [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 127.022005] PGD 7114a067 PUD 71111067 PMD 0
[ 127.022005] Oops: 0002 [#1] PREEMPT SMP
[ 127.022005] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:11:04.0/resource
[ 127.022005] CPU 0
[ 127.022005] Modules linked in: ppdev ac video output sbs sbshc battery af_packet parport_pc lp parport ipv6 psmouse serio_raw iTCO_wdt iTCO_vendor_support e1000e container button evdev ext3 jbd mbcache sg sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore fan thermal_sys fuse
[ 127.022005] Pid: 5410, comm: konqueror Not tainted 2.6.31.7-adeos #1 X7SBA
[ 127.022005] RIP: 0010:[<ffffffff8135cae9>] [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 127.022005] RSP: 0018:ffff8800016f7cb0 EFLAGS: 00250b02
[ 127.022005] RAX: ffff8800379a8c20 RBX: ffff88000170b140 RCX: 00000000c0000100
[ 127.022005] RDX: 0000000000007fc7 RSI: ffff88007eda54e0 RDI: ffff8800379a8c20
[ 127.022005] RBP: 0000000000000282 R08: ffff88007110c000 R09: 0000000000989680
[ 127.022005] R10: ffff88007eda5518 R11: 00000000ffffffff R12: ffff88007e3eaa40
[ 127.022005] R13: 0000000000000000 R14: ffff88007e3eb740 R15: 0000000000000082
[ 127.022005] FS: 00007fc70a0c36f0(0000) GS:ffff8800016f4000(0000) knlGS:0000000000000000
[ 127.022005] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 127.022005] CR2: 000000000000021a CR3: 0000000071110000 CR4: 00000000000406f0
[ 127.022005] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 127.022005] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 127.022005] Process konqueror (pid: 5410, threadinfo ffff88007110c000, task ffff88007eda54e0)
[ 127.022005] Stack:
[ 127.022005] 0000000000000000 0000000000000048 ffffffff814e80c8 0000000000000008
[ 127.022005] <0> 0000000000000101 ffff8800016f7ce8 ffffffff810536f9 ffff8800016f7d38
[ 127.022005] <0> ffffffff81054616 0000000000000086 000000000000000a 0000000000000082
[ 127.022005] Call Trace:
[ 127.022005] <IRQ>
[ 127.022005] [<ffffffff810536f9>] ? _local_bh_enable+0x49/0xb0
[ 127.022005] [<ffffffff81054616>] ? __do_softirq+0x166/0x290
[ 127.022005] [<ffffffff8105427f>] ? irq_exit+0x7f/0xc0
[ 127.022005] [<ffffffff813604e7>] ? smp_apic_timer_interrupt+0x67/0x9d
[ 127.022005] [<ffffffff81360480>] ? smp_apic_timer_interrupt+0x0/0x9d
[ 127.022005] [<ffffffff81094226>] ? __ipipe_sync_stage+0x2e6/0x2ec
[ 127.022005] [<ffffffff810933a0>] ? __ipipe_set_irq_pending+0x40/0xe0
[ 127.022005] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 127.022005] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 127.022005] [<ffffffff81028f04>] ? __ipipe_handle_irq+0x384/0x4b0
[ 127.022005] [<ffffffff8100c9f9>] ? common_interrupt+0x39/0x54
[ 127.022005] <EOI>
[ 127.022005] Code: 03 00 00 e9 5a df ca ff 65 48 8b 34 25 00 b0 00 00 4c 8b 46 08 48 89 c7 41 f7 40 10 00 00 04 00 0f 85 ec f3 ca ff 48 89 ee 5d 9d <48> 89 45 98 65 48 8b 04 25 00 b0 00 00 48 8b 10 48 c7 c3 00 24
[ 127.022005] RIP [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 127.022005] RSP <ffff8800016f7cb0>
[ 127.022005] CR2: 000000000000021a
=====================================================================================================
[ 323.109557] BUG: unable to handle kernel NULL pointer dereference at 000000000000021a
[ 323.110003] IP: [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 323.110003] PGD 71550067 PUD 0
[ 323.110003] Oops: 0002 [#1] PREEMPT SMP
[ 323.110003] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.6/modalias
[ 323.110003] CPU 0
[ 323.110003] Modules linked in: ppdev ac video output sbs sbshc battery af_packet parport_pc lp parport ipv6 serio_raw psmouse iTCO_wdt iTCO_vendor_support e1000e container button evdev ext3 jbd mbcache sg sd_mod usb_storage usb_libusual ahci libata scsi_mod ehci_hcd uhci_hcd usbcore fan thermal_sys fuse
[ 323.110003] Pid: 6377, comm: java Not tainted 2.6.31.7-adeos #1 X7SBA
[ 323.110003] RIP: 0010:[<ffffffff8135cae9>] [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 323.110003] RSP: 0018:ffff8800016f7cb0 EFLAGS: 00250b02
[ 323.110003] RAX: ffff880037adb690 RBX: ffff88000170b140 RCX: 0000000000000000
[ 323.110003] RDX: 00000000ffffffff RSI: ffff880037adced0 RDI: ffff880037adb690
[ 323.110003] RBP: 0000000000000282 R08: ffff8800717ae000 R09: 0000000000001000
[ 323.110003] R10: 0000000000000001 R11: 00000000ffffffff R12: ffff88007df59a00
[ 323.110003] R13: 0000000000000000 R14: ffff88007df59a00 R15: 0000000000000086
[ 323.110003] FS: 0000000041a61950(0063) GS:ffff8800016f4000(0000) knlGS:0000000000000000
[ 323.110003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 323.110003] CR2: 000000000000021a CR3: 000000007e2e4000 CR4: 00000000000406f0
[ 323.110003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 323.110003] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 323.110003] Process java (pid: 6377, threadinfo ffff8800717ae000, task ffff880037adced0)
[ 323.110003] Stack:
[ 323.110003] 0000000000000000 0000000000000048 ffffffff814e80c8 0000000000000008
[ 323.110003] <0> 0000000000000101 ffff8800016f7ce8 ffffffff810536f9 ffff8800016f7d38
[ 323.110003] <0> ffffffff81054616 0000000000000086 000000000000000a 0000000000000082
[ 323.110003] Call Trace:
[ 323.110003] <IRQ>
[ 323.110003] [<ffffffff810536f9>] ? _local_bh_enable+0x49/0xb0
[ 323.110003] [<ffffffff81054616>] ? __do_softirq+0x166/0x290
[ 323.110003] [<ffffffff8105427f>] ? irq_exit+0x7f/0xc0
[ 323.110003] [<ffffffff813604e7>] ? smp_apic_timer_interrupt+0x67/0x9d
[ 323.110003] [<ffffffff81360480>] ? smp_apic_timer_interrupt+0x0/0x9d
[ 323.110003] [<ffffffff81094226>] ? __ipipe_sync_stage+0x2e6/0x2ec
[ 323.110003] [<ffffffff810933a0>] ? __ipipe_set_irq_pending+0x40/0xe0
[ 323.110003] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 323.110003] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 323.110003] [<ffffffff81028f04>] ? __ipipe_handle_irq+0x384/0x4b0
[ 323.110003] [<ffffffff8100cd69>] ? invalidate_interrupt1+0x39/0x60
[ 323.110003] <EOI>
[ 323.110003] Code: 03 00 00 e9 5a df ca ff 65 48 8b 34 25 00 b0 00 00 4c 8b 46 08 48 89 c7 41 f7 40 10 00 00 04 00 0f 85 ec f3 ca ff 48 89 ee 5d 9d <48> 89 45 98 65 48 8b 04 25 00 b0 00 00 48 8b 10 48 c7 c3 00 24
[ 323.110003] RIP [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 323.110003] RSP <ffff8800016f7cb0>
[ 323.110003] CR2: 000000000000021a
=====================================================================================================
[ 836.500401] BUG: unable to handle kernel paging request at 000000000000d120
[ 836.504559] IP: [<000000000000d120>] 0xd120
[ 836.504559] PGD 71532067 PUD 7156b067 PMD 0
[ 836.504559] Oops: 0010 [#1] PREEMPT SMP
[ 836.504559] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:11:04.0/resource
[ 836.504559] CPU 0
[ 836.504559] Modules linked in: ppdev ac video output sbs sbshc battery af_packet parport_pc lp parport ipv6 psmouse serio_raw iTCO_wdt iTCO_vendor_support e1000e container button evdev ext3 jbd mbcache sg sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore fan thermal_sys fuse
[ 836.504559] Pid: 5408, comm: konqueror Not tainted 2.6.31.7-adeos #1 X7SBA
[ 836.504559] RIP: 0010:[<000000000000d120>] [<000000000000d120>] 0xd120
[ 836.504559] RSP: 0018:ffff8800016f7de0 EFLAGS: 00254282
[ 836.504559] RAX: 0000000000000000 RBX: ffffffff81021490 RCX: ffffffff81660b00
[ 836.504559] RDX: ffff8800016f4000 RSI: ffff88007d0a7330 RDI: 0000000080000001
[ 836.504559] RBP: 000000000000d120 R08: ffff880071540000 R09: ffff8800715a8c68
[ 836.504559] R10: ffff88000170b1b0 R11: 0000000000000000 R12: ffff8800016ff900
[ 836.504559] R13: 0000000000000000 R14: 0000000000000008 R15: 0000000000000082
[ 836.504559] FS: 00007f404d4c46f0(0000) GS:ffff8800016f4000(0000) knlGS:0000000000000000
[ 836.504559] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 836.504559] CR2: 000000000000d120 CR3: 000000007156a000 CR4: 00000000000406f0
[ 836.504559] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 836.504559] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
[ 836.504559] Process konqueror (pid: 5408, threadinfo ffff880071540000, task ffff8800715a8c20)
[ 836.504559] Stack:
[ 836.504559] ffff8800016f7e10 ffffffff81029435 ffff8800016ff900 ffffffff81021490
[ 836.504559] <0> ffff8800016ff900 0000000000000008 0000000000240086 0000000000000200
[ 836.504559] <0> 000000000000d120 ffff8800016f7e68 ffffffff810933a0 ffff880071540000
[ 836.504559] Call Trace:
[ 836.504559] <IRQ>
[ 836.504559] [<ffffffff81029435>] ? __ipipe_preempt_schedule_irq+0x95/0x1a0
[ 836.504559] [<ffffffff81021490>] ? smp_reschedule_interrupt+0x0/0x20
[ 836.504559] [<ffffffff810933a0>] ? __ipipe_set_irq_pending+0x40/0xe0
[ 836.504559] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 836.504559] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 836.504559] [<ffffffff81028f04>] ? __ipipe_handle_irq+0x384/0x4b0
[ 836.504559] [<ffffffff8100c9f9>] ? common_interrupt+0x39/0x54
[ 836.504559] <EOI>
[ 836.504559] Code: Bad RIP value.
[ 836.504559] RIP [<000000000000d120>] 0xd120
[ 836.504559] RSP <ffff8800016f7de0>
[ 836.504559] CR2: 000000000000d120
[ 836.751540] kernel tried to execute NX-protected page - exploit attempt? (uid: 1000)
[ 836.752467] BUG: unable to handle kernel paging request at ffff88007dab9840
[ 836.752467] IP: [<ffff88007dab9840>] 0xffff88007dab9840
[ 836.752467] PGD 1002063 PUD 10067 PMD 800000007da001e3
[ 836.752467] Oops: 0011 [#2] PREEMPT SMP
[ 836.752467] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:11:04.0/resource
[ 836.752467] CPU 0
[ 836.752467] Modules linked in: ppdev ac video output sbs sbshc battery af_packet parport_pc lp parport ipv6 psmouse serio_raw iTCO_wdt iTCO_vendor_support e1000e container button evdev ext3 jbd mbcache sg sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore fan thermal_sys fuse
[ 836.752467] Pid: 5408, comm: konqueror Tainted: G D 2.6.31.7-adeos #1 X7SBA
[ 836.752467] RIP: 0010:[<ffff88007dab9840>] [<ffff88007dab9840>] 0xffff88007dab9840
[ 836.752467] RSP: 0000:ffff8800016f7b28 EFLAGS: 00250096
[ 836.752467] RAX: 0000000000000000 RBX: 000000000000d120 RCX: ffff880001701120
[ 836.752467] RDX: ffff880001701120 RSI: 0000000000000000 RDI: 0000000000012400
[ 836.752467] RBP: ffff88000172a1b0 R08: 00000000ffffffff R09: 0000000000000000
[ 836.752467] R10: 000000000000000a R11: 0000000000000006 R12: ffffffff81660b00
[ 836.752467] R13: 0000000000000200 R14: ffff88000172a1d8 R15: ffff88000172a140
[ 836.752467] FS: 00007f404d4c46f0(0000) GS:ffff8800016f4000(0000) knlGS:0000000000000000
[ 836.752467] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 836.752467] CR2: ffff88007dab9840 CR3: 000000007156a000 CR4: 00000000000406f0
[ 836.752467] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 836.752467] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
[ 836.752467] Process konqueror (pid: 5408, threadinfo ffff880071540000, task ffff8800715a8c20)
[ 836.752467] Stack:
[ 836.752467] ffff8800016f7b68 0000000000240282 ffff8800016f7b48 ffff88007dabc8c0
[ 836.752467] <0> ffff88007dab9840 0000000000017140 ffff88000172a140 0000000000240082
[ 836.752467] <0> 000000000000d120 0000000000240286 ffff8800016f7bb8 0000000000240086
[ 836.752467] Call Trace:
[ 836.752467] <IRQ>
[ 836.752467] [<ffffffff81093f91>] ? __ipipe_sync_stage+0x51/0x2ec
[ 836.752467] [<ffffffff81093f91>] ? __ipipe_sync_stage+0x51/0x2ec
[ 836.752467] [<ffffffff81113b97>] ? mempool_free_slab+0x17/0x20
[ 836.752467] [<ffffffff81093f91>] ? __ipipe_sync_stage+0x51/0x2ec
[ 836.752467] [<ffffffff81093f91>] ? __ipipe_sync_stage+0x51/0x2ec
[ 836.752467] [<ffffffff8135fbce>] ? _spin_unlock_irqrestore+0x5e/0x70
[ 836.752467] [<ffffffff811f123f>] ? blk_run_queue+0x3f/0x50
[ 836.752467] [<ffffffffa007c752>] ? scsi_run_queue+0x152/0x3a0 [scsi_mod]
[ 836.752467] [<ffffffff81208a07>] ? kobject_put+0x27/0x60
[ 836.752467] [<ffffffff810933a0>] ? __ipipe_set_irq_pending+0x40/0xe0
[ 836.752467] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 836.752467] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 836.752467] [<ffffffff81028f04>] ? __ipipe_handle_irq+0x384/0x4b0
[ 836.752467] [<ffffffff8100c9f9>] ? common_interrupt+0x39/0x54
[ 836.752467] <EOI>
[ 836.752467] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <02> 00 00 00 00 00 00 00 00 e0 80 7d 00 88 ff ff 02 00 00 00 00
[ 836.752467] RIP [<ffff88007dab9840>] 0xffff88007dab9840
[ 836.752467] RSP <ffff8800016f7b28>
[ 836.752467] CR2: ffff88007dab9840
[ 836.752467] ---[ end trace 5a24f9b362aa2c56 ]---
[ 837.112700] BUG: unable to handle kernel NULL pointer dereference at 000000000000001a
[ 837.113002] IP: [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 837.113002] PGD 7e6f2067 PUD 37be8067 PMD 0
[ 837.113002] Oops: 0002 [#3] PREEMPT SMP
[ 837.113002] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:11:04.0/resource
[ 837.113002] CPU 0
[ 837.113002] Modules linked in: ppdev ac video output sbs sbshc battery af_packet parport_pc lp parport ipv6 psmouse serio_raw iTCO_wdt iTCO_vendor_support e1000e container button evdev ext3 jbd mbcache sg sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore fan thermal_sys fuse
[ 837.113002] Pid: 5408, comm: konqueror Tainted: G D 2.6.31.7-adeos #1 X7SBA
[ 837.113002] RIP: 0010:[<ffffffff8135cae9>] [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 837.113002] RSP: 0018:ffff8800016f77b8 EFLAGS: 00015102
[ 837.113002] RAX: ffff88007d9cc2b0 RBX: ffff88000170b140 RCX: 00000000c0000100
[ 837.113002] RDX: 0000000000007f40 RSI: ffff8800715a8c20 RDI: ffff88007d9cc2b0
[ 837.113002] RBP: 0000000000000082 R08: ffff880071540000 R09: 0000000000000000
[ 837.113002] R10: 0000000000000001 R11: 00000000ffffffff R12: 0000000000000000
[ 837.113002] R13: 0000000000000000 R14: ffff88007dcfe3c0 R15: 0000000000000000
[ 837.113002] FS: 00007f404d4c46f0(0000) GS:ffff8800016f4000(0000) knlGS:0000000000000000
[ 837.113002] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 837.113002] CR2: 000000000000001a CR3: 000000007d021000 CR4: 00000000000406f0
[ 837.113002] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 837.113002] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
[ 837.113002] Process konqueror (pid: 5408, threadinfo ffff880071540000, task ffff8800715a8c20)
[ 837.113002] Stack:
[ 837.113002] 0000000000000282 ffff8800016f7800 0000000000000282 ffffffff81660b00
[ 837.113002] <0> ffff88000172a140 0000000000017140 0000000000000086 000000000000d120
[ 837.113002] <0> 0000000000000282 ffff8800016f7840 0000000000000282 ffffffff81660b00
[ 837.113002] Call Trace:
[ 837.113002] <IRQ>
[ 837.113002] [<ffffffff81046747>] ? kick_process+0x67/0xb0
[ 837.113002] [<ffffffff8105c132>] ? signal_wake_up+0x72/0x110
[ 837.113002] [<ffffffff8105c304>] ? complete_signal+0x134/0x210
[ 837.113002] [<ffffffff8135fa98>] ? _read_unlock+0x18/0x50
[ 837.113002] [<ffffffff8115bd93>] ? send_sigio+0x223/0x250
[ 837.113002] [<ffffffff81094f36>] ? __ipipe_restore_root+0x86/0xd0
[ 837.113002] [<ffffffff81113b97>] ? mempool_free_slab+0x17/0x20
[ 837.113002] [<ffffffff81144c43>] ? kmem_cache_free+0xd3/0x180
[ 837.113002] [<ffffffff8135fb99>] ? _spin_unlock_irqrestore+0x29/0x70
[ 837.113002] [<ffffffff81094e25>] ? __ipipe_unstall_root+0x75/0x100
[ 837.113002] [<ffffffff81094f36>] ? __ipipe_restore_root+0x86/0xd0
[ 837.113002] [<ffffffff81094e25>] ? __ipipe_unstall_root+0x75/0x100
[ 837.113002] [<ffffffff81094f36>] ? __ipipe_restore_root+0x86/0xd0
[ 837.113002] [<ffffffff8114e9c9>] ? file_free_rcu+0x39/0x50
[ 837.113002] [<ffffffff81094e25>] ? __ipipe_unstall_root+0x75/0x100
[ 837.113002] [<ffffffff810536f9>] ? _local_bh_enable+0x49/0xb0
[ 837.113002] [<ffffffff81054616>] ? __do_softirq+0x166/0x290
[ 837.113002] [<ffffffff8105427f>] ? irq_exit+0x7f/0xc0
[ 837.113002] [<ffffffff813604e7>] ? smp_apic_timer_interrupt+0x67/0x9d
[ 837.113002] [<ffffffff81360480>] ? smp_apic_timer_interrupt+0x0/0x9d
[ 837.113002] [<ffffffff81094226>] ? __ipipe_sync_stage+0x2e6/0x2ec
[ 837.113002] [<ffffffff810933a0>] ? __ipipe_set_irq_pending+0x40/0xe0
[ 837.113002] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 837.113002] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 837.113002] [<ffffffff81028f04>] ? __ipipe_handle_irq+0x384/0x4b0
[ 837.113002] [<ffffffff8100c9f9>] ? common_interrupt+0x39/0x54
[ 837.113002] <EOI>
[ 837.113002] Code: 03 00 00 e9 5a df ca ff 65 48 8b 34 25 00 b0 00 00 4c 8b 46 08 48 89 c7 41 f7 40 10 00 00 04 00 0f 85 ec f3 ca ff 48 89 ee 5d 9d <48> 89 45 98 65 48 8b 04 25 00 b0 00 00 48 8b 10 48 c7 c3 00 24
[ 837.113002] RIP [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 837.113002] RSP <ffff8800016f77b8>
[ 837.113002] CR2: 000000000000001a
[ 837.113002] ---[ end trace 5a24f9b362aa2c57 ]---
[ 837.113002] Fixing recursive fault but reboot is needed!
=====================================================================================================
[ 86.857061] BUG: unable to handle kernel NULL pointer dereference at 000000000000021a
[ 86.857252] IP: [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 86.857252] PGD 7dac6067 PUD 7dac7067 PMD 0
[ 86.857252] Oops: 0002 [#1] PREEMPT SMP
[ 86.857252] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:11:04.0/resource
[ 86.857252] CPU 1
[ 86.857252] Modules linked in: ppdev ac video output sbs sbshc battery af_packet parport_pc lp parport ipv6 serio_raw psmouse iTCO_wdt iTCO_vendor_support container button e1000e evdev ext3 jbd mbcache sg sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore fan thermal_sys fuse
[ 86.857252] Pid: 5375, comm: konqueror Not tainted 2.6.31.7-adeos #1 X7SBA
[ 86.857252] RIP: 0010:[<ffffffff8135cae9>] [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 86.857252] RSP: 0018:ffff880001716cb0 EFLAGS: 00250b02
[ 86.857252] RAX: ffff88007db7b690 RBX: ffff88000172a140 RCX: ffff88007123a000
[ 86.857252] RDX: ffff88007dffbb00 RSI: ffff88007d1c3690 RDI: ffff88007db7b690
[ 86.857252] RBP: 0000000000000282 R08: ffff88007dafc000 R09: 0000000000000020
[ 86.857252] R10: ffff88007d1c36c8 R11: 00000000ffffffff R12: ffff88007e21f0c0
[ 86.857252] R13: 0000000000000001 R14: ffff88007e21cd00 R15: 0000000000000086
[ 86.857252] FS: 00007fe00dc896f0(0000) GS:ffff880001713000(0000) knlGS:0000000000000000
[ 86.857252] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 86.857252] CR2: 000000000000021a CR3: 000000007dac5000 CR4: 00000000000406e0
[ 86.857252] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 86.857252] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 86.857252] Process konqueror (pid: 5375, threadinfo ffff88007dafc000, task ffff88007d1c3690)
[ 86.857252] Stack:
[ 86.857252] 0000000000000000 0000000000000010 ffffffff814e8090 0000000000000001
[ 86.857252] <0> 0000000000000101 ffff880001716ce8 ffffffff810536f9 ffff880001716d38
[ 86.857252] <0> ffffffff81054616 0000000000000086 000000010000000a 0000000000000082
[ 86.857252] Call Trace:
[ 86.857252] <IRQ>
[ 86.857252] [<ffffffff810536f9>] ? _local_bh_enable+0x49/0xb0
[ 86.857252] [<ffffffff81054616>] ? __do_softirq+0x166/0x290
[ 86.857252] [<ffffffff8105427f>] ? irq_exit+0x7f/0xc0
[ 86.857252] [<ffffffff813604e7>] ? smp_apic_timer_interrupt+0x67/0x9d
[ 86.857252] [<ffffffff81360480>] ? smp_apic_timer_interrupt+0x0/0x9d
[ 86.857252] [<ffffffff81094226>] ? __ipipe_sync_stage+0x2e6/0x2ec
[ 86.857252] [<ffffffff810933a0>] ? __ipipe_set_irq_pending+0x40/0xe0
[ 86.857252] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 86.857252] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 86.857252] [<ffffffff81028f04>] ? __ipipe_handle_irq+0x384/0x4b0
[ 86.857252] [<ffffffff8100c9f9>] ? common_interrupt+0x39/0x54
[ 86.857252] <EOI>
[ 86.857252] Code: 03 00 00 e9 5a df ca ff 65 48 8b 34 25 00 b0 00 00 4c 8b 46 08 48 89 c7 41 f7 40 10 00 00 04 00 0f 85 ec f3 ca ff 48 89 ee 5d 9d <48> 89 45 98 65 48 8b 04 25 00 b0 00 00 48 8b 10 48 c7 c3 00 24
[ 86.857252] RIP [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 86.857252] RSP <ffff880001716cb0>
[ 86.857252] CR2: 000000000000021a
=====================================================================================================
[ 222.421941] BUG: unable to handle kernel NULL pointer dereference at 000000000000021a
[ 222.422001] IP: [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 222.422001] PGD 7179f067 PUD 0
[ 222.422001] Oops: 0002 [#1] PREEMPT SMP
[ 222.422001] last sysfs file: /sys/block/sda/removable
[ 222.422001] CPU 0
[ 222.422001] Modules linked in: ppdev ac video output sbs sbshc battery af_packet parport_pc lp parport ipv6 psmouse serio_raw iTCO_wdt iTCO_vendor_support e1000e container button evdev ext3 jbd mbcache sg sd_mod ahci libata ehci_hcd uhci_hcd scsi_mod usbcore fan thermal_sys fuse
[ 222.422001] Pid: 5691, comm: java Not tainted 2.6.31.7-adeos #1 X7SBA
[ 222.422001] RIP: 0010:[<ffffffff8135cae9>] [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 222.422001] RSP: 0018:ffff8800016f7cb0 EFLAGS: 00250b02
[ 222.422001] RAX: ffff88007de0f940 RBX: ffff88000170b140 RCX: 0000000000000000
[ 222.422001] RDX: 00000000ffffffff RSI: ffff88007165b690 RDI: ffff88007de0f940
[ 222.422001] RBP: 0000000000000282 R08: ffff88007167a000 R09: ffff880001708dc0
[ 222.422001] R10: 0000000000000000 R11: 00000000ffffffff R12: ffff88007e2d6d80
[ 222.422001] R13: 0000000000000000 R14: ffff880037b7d040 R15: 0000000000000082
[ 222.422001] FS: 0000000041476950(0063) GS:ffff8800016f4000(0000) knlGS:0000000000000000
[ 222.422001] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 222.422001] CR2: 000000000000021a CR3: 00000000714d4000 CR4: 00000000000406f0
[ 222.422001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 222.422001] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 222.422001] Process java (pid: 5691, threadinfo ffff88007167a000, task ffff88007165b690)
[ 222.422001] Stack:
[ 222.422001] 0000000000000000 0000000000000010 ffffffff814e8090 0000000000000001
[ 222.422001] <0> 0000000000000101 ffff8800016f7ce8 ffffffff810536f9 ffff8800016f7d38
[ 222.422001] <0> ffffffff81054616 0000000000000086 000000000000000a 0000000000000082
[ 222.422001] Call Trace:
[ 222.422001] <IRQ>
[ 222.422001] [<ffffffff810536f9>] ? _local_bh_enable+0x49/0xb0
[ 222.422001] [<ffffffff81054616>] ? __do_softirq+0x166/0x290
[ 222.422001] [<ffffffff8105427f>] ? irq_exit+0x7f/0xc0
[ 222.422001] [<ffffffff813604e7>] ? smp_apic_timer_interrupt+0x67/0x9d
[ 222.422001] [<ffffffff81360480>] ? smp_apic_timer_interrupt+0x0/0x9d
[ 222.422001] [<ffffffff81094226>] ? __ipipe_sync_stage+0x2e6/0x2ec
[ 222.422001] [<ffffffff810933a0>] ? __ipipe_set_irq_pending+0x40/0xe0
[ 222.422001] [<ffffffff81094797>] ? __ipipe_walk_pipeline+0xa7/0x290
[ 222.422001] [<ffffffff81094a6f>] ? __ipipe_dispatch_wired_nocheck+0xef/0x230
[ 222.422001] [<ffffffff8109602c>] ? __ipipe_dispatch_wired+0x8c/0xe0
[ 222.422001] [<ffffffff81028f04>] ? __ipipe_handle_irq+0x384/0x4b0
[ 222.422001] [<ffffffff8100c9f9>] ? common_interrupt+0x39/0x54
[ 222.422001] <EOI>
[ 222.422001] Code: 03 00 00 e9 5a df ca ff 65 48 8b 34 25 00 b0 00 00 4c 8b 46 08 48 89 c7 41 f7 40 10 00 00 04 00 0f 85 ec f3 ca ff 48 89 ee 5d 9d <48> 89 45 98 65 48 8b 04 25 00 b0 00 00 48 8b 10 48 c7 c3 00 24
[ 222.422001] RIP [<ffffffff8135cae9>] thread_return+0x23/0x8ca
[ 222.422001] RSP <ffff8800016f7cb0>
[ 222.422001] CR2: 000000000000021a
^ permalink raw reply
* Re: + spi-imx-correct-check-for-platform_get_irq-failing.patch added to -mm tree
From: Grant Likely @ 2009-12-09 15:08 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f,
mm-commits-u79uwXL29TY76Z2rM5mHXA, daniel-rDUAYElUppE,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20091209074533.GB8136-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
(resend because I forgot to cc the mailing list)
2009/12/9 Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>:
> Hello Grant,
>
> On Tue, Dec 08, 2009 at 05:38:57PM -0700, Grant Likely wrote:
>> > diff -puN drivers/spi/spi_imx.c~spi-imx-correct-check-for-platform_get_irq-failing drivers/spi/spi_imx.c
>> > --- a/drivers/spi/spi_imx.c~spi-imx-correct-check-for-platform_get_irq-failing
>> > +++ a/drivers/spi/spi_imx.c
>> > @@ -554,7 +554,7 @@ static int __init spi_imx_probe(struct p
>> > }
>> >
>> > spi_imx->irq = platform_get_irq(pdev, 0);
>> > - if (!spi_imx->irq) {
>> > + if (spi_imx->irq < 0) {
>>
>> This changes the old behaviour. Is that what you intended? '<= 0' perhaps?
> Yes, the old check was wrong. What if the irq to use is 0? I thought
> the commit log to be understandable. platform_get_irq returns -ENXIO on
> error and an irq number on success. So 0 has to be interpreted as valid
> irq, not an error.
0 is not a valid IRQ
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
^ permalink raw reply
* Re: [PATCH] NTFS: Change string pointers to string constants.
From: walter harms @ 2009-12-09 15:07 UTC (permalink / raw)
To: Marcin Slusarz
Cc: Joe Perches, Anton Altaparmakov, John Daiker, kernel-janitors,
aia21, linux-ntfs-dev, LKML
In-Reply-To: <20091209145846.GA3562@joi.lan>
Marcin Slusarz schrieb:
> On Mon, Dec 07, 2009 at 05:47:13PM -0800, Joe Perches wrote:
>> On Tue, 2009-12-08 at 00:57 +0000, Anton Altaparmakov wrote:
>>> Can you please explain the rational for making this change?
>> Perhaps it's not worth much, but it saves a pointer reference.
>>
>> $ cat pointer.c
>> #include <string.h>
>> #include <stdio.h>
>>
>> int main (int argc, char** argv)
>> {
>> static const char *foo = "abcdefg";
>> printf("%s\n", foo);
>> return 0;
>> }
>>
>> $ gcc -c pointer.c
>> $ size pointer.o
>> text data bss dec hex filename
>> 37 4 0 41 29 pointer.o
>>
>> $ cat reference.c
>> #include <string.h>
>> #include <stdio.h>
>>
>> int main (int argc, char** argv)
>> {
>> static const char foo[] = "abcdefg";
>> printf("%s\n", foo);
>> return 0;
>> }
>>
>> $ gcc -c reference.c
>> $ size reference.o
>> text data bss dec hex filename
>> 36 0 0 36 24 reference.o
>
> Yeah, for static variables it's better. But for automatic variables
> it's worse, because it now has to do a copy at runtime.
> And the patch changes both types.
>
> $ size pointer.o reference.o
> text data bss dec hex filename
> 101 8 0 109 6d pointer.o
> 96 0 0 96 60 reference.o
>
> $ size pointer-nonstatic.o reference-nonstatic.o
> text data bss dec hex filename
> 106 0 0 106 6a pointer-nonstatic.o
> 109 0 0 109 6d reference-nonstatic.o
> --
nobody should spend to much time on this. gcc <what ever next version>
will have different results. It is better to spend time improving
the compiler and make it generate shorter/faster code.
just my 2 cents,
wh
^ permalink raw reply
* Re: [PATCH] connman: don't give user 'system' permissions by default. We might not have one. (connman 0.46)
From: Sebastian Spaeth @ 2009-12-09 15:03 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1260365221-11155-1-git-send-email-Sebastian@SSpaeth.de>
[-- Attachment #1: Type: text/plain, Size: 204 bytes --]
Can I get an ACK for this? default connman configuration assumes that we
have a user called "system". This simply gets rid of that assumption.
I would push this in addition to a PR bump.
spaetz
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 268 bytes --]
^ permalink raw reply
* Re: [PATCH] of/flattree: merge of_find_node_by_phandle
From: Stephen Rothwell @ 2009-12-09 15:05 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <200912091748.00122.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 465 bytes --]
On Wed, 9 Dec 2009 17:48:00 +0800 Jeremy Kerr <jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote:
>
> > [PATCH] of/flattree: merge of_find_node_by_phandle
>
> On second thoughts, this should probably be "of" rather than "of/flattree".
And should probably be cc'd to PowerPC, Sparc and Microblaze kernel
people ...
--
Cheers,
Stephen Rothwell sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org
http://www.canb.auug.org.au/~sfr/
[-- Attachment #1.2: Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 192 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: wireless device and udev
From: John W. Linville @ 2009-12-09 15:05 UTC (permalink / raw)
To: Andrey Borzenkov
Cc: linux-hotplug, Johannes Berg, Stephen Hemminger,
Luis R. Rodriguez, linux-wireless
In-Reply-To: <200912090654.28630.arvidjaar@mail.ru>
On Wed, Dec 09, 2009 at 06:54:27AM +0300, Andrey Borzenkov wrote:
> On Tuesday 08 of December 2009 23:05:04 John W. Linville wrote:
> > On Tue, Dec 08, 2009 at 08:29:11PM +0100, Johannes Berg wrote:
> > > On Tue, 2009-12-08 at 13:52 -0500, John W. Linville wrote:
> > > > So, probably we need to map from the wlanX name to the phyY name,
> > > > then determine whether or not this is the first wlanX for phyY.
> > > > If not, then the name should be left alone.
> > > >
> > > > Now, how do we figure out how many wlanX's belong to phyY?
> > >
> > > And what's the "first" one? :)
> >
> > I suppose I was figuring that if there was only one, it was the
> > first. :-) But you're right, I suppose that could be racy...
> >
> > > ls /sys/class/net/wlan0/device/net/
> > >
> > > will give you the list of interface associated with this device.
> >
> > Cool...
> >
>
> Is it possible to distinguish between automatic system enumeration when
> new device is created and explicit name that user gives? Because in
> example above (iw phy add interface) user already supplied specific
> name; there is no reason for udev to (try to) mangle it.
That's why I wanted the "first" one...it is auto-generated. :-)
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [Lustre-devel] client side reply handling
From: Peter Braam @ 2009-12-09 15:05 UTC (permalink / raw)
To: lustre-devel
Hi,
I wonder if LNET doesn't have an atomic operation that unlinks the packet
from the delivery process upon receiving a packet. Iirc it does. Why
wouldn't one use that?
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20091209/27c0c4d8/attachment.htm>
^ permalink raw reply
* Re: [PATCH 01/10] trace_kprobe: shows signs of fields in format files
From: Masami Hiramatsu @ 2009-12-09 15:05 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Ingo Molnar, Steven Rostedt, Frederic Weisbecker, Jason Baron,
LKML
In-Reply-To: <4B1F4E80.4050507@cn.fujitsu.com>
Lai Jiangshan wrote:
>
> format files of trace_kprobe don't shows signs, it is
> different from all other format files, incorrect API to user.
>
> Signed-off-by: Lai Jiangshan<laijs@cn.fujitsu.com>
Thanks Lai!
Acked-by: Masami Hiramatsu <mhiramat@redhat.com>
> ---
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index e3c80e9..3ef66d4 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -1163,10 +1163,11 @@ static int __probe_event_show_format(struct trace_seq *s,
> #undef SHOW_FIELD
> #define SHOW_FIELD(type, item, name) \
> do { \
> - ret = trace_seq_printf(s, "\tfield: " #type " %s;\t" \
> - "offset:%u;\tsize:%u;\n", name, \
> + ret = trace_seq_printf(s, "\tfield:" #type " %s;\t" \
> + "offset:%u;\tsize:%u;\tsigned:%d;\n", name,\
> (unsigned int)offsetof(typeof(field), item),\
> - (unsigned int)sizeof(type)); \
> + (unsigned int)sizeof(type), \
> + is_signed_type(type)); \
> if (!ret) \
> return 0; \
> } while (0)
>
>
>
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
^ permalink raw reply
* Re: [linux-lvm] kernel panic on lvcreate
From: Christopher Hawkins @ 2009-12-09 15:00 UTC (permalink / raw)
To: LVM general discussion and development
In-Reply-To: <33462681.271260370580061.JavaMail.javamailuser@localhost>
Hello,
After some time I revisited this issue on a freshly installed Centos 5.4 box, latest kernel (2.6.18-164.6.1.el5 ) and the panic is still reproducible. Any time I create a snapshot of the root filesystem, kernel panics. The LVM HOWTO says to post bug reports to this list. Is this the proper place?
Thanks,
Chris
From earlier post:
OOPS message:
BUG: scheduling while atomic: java/0x00000001/2959 [<c061637f>] <3>BUG: scheduling while atomic: java/0x00000001/2867 [<c061637f>] schedule+0x43/0xa55 [<c042c40d>] lock_timer_base+0x15/0x2f
[<c042c46b>] try_to_del_timer_sync+0x44/0x4a
[<c0437dd2>] futex_wake+0x3c/0xa5
[<c0434d5f>] prepare_to_wait+0x24/0x46
[<c0461ea7>] do_wp_page+0x1b3/0x5bb
[<c0438b01>] do_futex+0x239/0xb5e
[<c0434c13>] autoremove_wake_function+0x0/0x2d
[<c0463876>] __handle_mm_fault+0x9a9/0xa15
[<c041e727>] default_wake_function+0x0/0xc
[<c046548d>] unmap_region+0xe1/0xf0
[<c061954f>] do_page_fault+0x233/0x4e1
[<c061931c>] do_page_fault+0x0/0x4e1
[<c0405a89>] error_code+0x39/0x40
=======================
schedule+0x43/0xa55
[<c042c40d>] <0>------------[ cut here ]------------
kernel BUG at arch/i386/mm/highmem.c:43!
invalid opcode: 0000 [#1]
SMP
last sysfs file: /devices/pci0000:00/0000:00:00.0/irq
Modules linked in: autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc ip6t_REJECTdCPU: 3 ip6table_filter ip6_tables x_tables ipv6 xfrm_nalgo cry
EIP: 0060:[<c041cb08>] Not tainted VLI
EFLAGS: 00010206 (2.6.18-164.2.1.el5 #1)
EIP is at kmap_atomic+0x5c/0x7f
eax: c0012d6c ebx: fff5b000 ecx: c1fb8760 edx: 00000180
esi: f7be8580 edi: f7fa7000 ebp: 00000004 esp: f5c54f0c
ds: 007b es: 007b ss: 0068 Process mpath_wait (pid: 3273, ti=f5c54000 task=f5c50000 task.ti=f5c54000)ne Stack: c073a4e0 c0462f7f f7b0eb30 f7b40780 f5c54f3c 0029c3f0 f63b5ef0 f7be8580
f7b40780 f7fa7000 00008802 c0472d75 f7b0eb30 f7c299c0 00001000 00001000
00001000 00000101 00000001 00000000 00000000 f5c5007b 0000007b ffffffff
Call Trace:
[<c0462f7f>] __handle_mm_fault+0xb2/0xa15
[<c0472d75>] do_filp_open+0x2b/0x31
[<c061954f>] do_page_fault+0x233/0x4e1
[<c061931c>] do_page_fault+0x0/0x4e1
[<c0405a89>] error_code+0x39/0x40
=======================
Code: 00 89 e0 25 00 f0 ff ff 6b 50 10 1b 8d 14 13 bb 00 f0 ff ff 8d 42 44 c1 e EIP: [<c041cb08>] kmap_atomic+0x5c/0x7f SS:ESP 0068:f5c54f0c
<0>Kernel panic - not syncing: Fatal exception
0c 29 c3 a1 54 12 79 c0 c1 e2 02 29 d0 83 38 00 74 08 <0f> 0b 2b
----- "Milan Broz" <mbroz@redhat.com> wrote:
> On 11/03/2009 04:07 PM, Christopher Hawkins wrote:
> > When I create a root snapshot on a fairly typical Centos 5.3
> server:
> ...
> > I get a kernel panic.
>
> Please try to first update kernel to version from 5.4.
> (There were some fixes for snapshot like
> https://bugzilla.redhat.com/show_bug.cgi?id=496100)
>
> If it still fails, please post the OOps trace from kernel (syslog).
>
> Milan
> --
> mbroz@redhat.com
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
^ permalink raw reply
* Re: How to force a fix pin
From: Ed Tsang @ 2009-12-09 15:04 UTC (permalink / raw)
To: Ralph Hempel, Nel D; +Cc: Bluettooth Linux
In-Reply-To: <4B1FA40F.2020003@hempeldesigngroup.com>
Ralph,Nel,
Thanks for the hints.
Since I will need to use the same pin code for every devices and I will not know their address before hand. In the pincodes file could we use
* 0000
I will try it out first.
Net Des
----- Original Message ----
From: Ralph Hempel <rhempel@hempeldesigngroup.com>
To: Nel D <newatlinux@gmail.com>
Cc: Ed Tsang <netdesign_98@yahoo.com>; Bluettooth Linux <linux-bluetooth@vger.kernel.org>
Sent: Wed, December 9, 2009 8:20:15 AM
Subject: Re: How to force a fix pin
Nel D wrote:
> Hi ,
>
>
> On Wed, Dec 9, 2009 at 3:45 AM, Ed Tsang <netdesign_98@yahoo.com> wrote:
>> Hi, My application scan for devices, send file to it. But some device (blackberry) will request a pin. With the bluetoothd 4.51. bluetooth-applet will pop up and enter a pin. If de-install it, the bluetoothd will complain "No agent available for 0 request (pin_code_request?).". And the remote device failed to pair with a "default pin 0000".
>> Is there a way to force a default pin "0000". look like /etc/bluetooth/pin is history. Is there a simply work around.
>>
>> Net Des
In the directory /var/lib/xx:yy:xx:yy:xx:yy/
where xx:yy:xx:yy:xx:yy is your Bluetooth interface MAC
you will either find or have to create two files:
pincodes
trusts
Assuming that your other device is aa:bb:aa:bb:aa:bb you
modify the files as follows:
In the pincodes file, add a line like this, replace 0000
with your desired pincode
aa:bb:aa:bb:aa:bb 0000
In the trusts file, put this:
aa:bb:aa:bb:aa:bb [all]
Which says the device can access all services (I think)
If the pairing is sucessful you will get a new
entry in the linkkeys file, and that key will then be
used in the future, so no more pairing is required.
I am currently investigating why (in 4.57) the linkkeys
and trusts entry of a successfully paired device are
sometimes deleted.
Ralph
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
^ permalink raw reply
* Growing Linear RAID
From: senthilkumar.muthukalai @ 2009-12-09 15:01 UTC (permalink / raw)
To: linux-raid
Hi,
I am trying to add a disk to a Linear Raid which was created with 2
disks.
We use linux-2.6.18 and mdadm-2.6.4.
I guess these support the above mentioned disk addition.
But I get the error quoted below.
Could you pls guide me?
Observations
------------
[root@NAS00226b1755a0 ~]# mdadm /dev/md0 --grow -n 3 /dev/sata3
mdadm: --size, --raiddisks, and --add are exclusing in --grow mode
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]# mdadm /dev/md0 --grow -n 3
mdadm: linear array /dev/md0 cannot be reshaped.
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]# mdadm /dev/md0 --grow --add /dev/sata3
mdadm: Cannot add new disk to this array
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]# mdadm /dev/md0 --add /dev/sata3
mdadm: add new device failed for /dev/sata3 as 2: No space left on
device
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]# mdadm /dev/md0 --grow -n 3 --add /dev/sata3
mdadm: --size, --raiddisks, and --add are exclusing in --grow mode
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]#
[root@NAS00226b1755a0 ~]# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5]
[raid4]
md0 : active linear sdb[1] sda[0]
444265856 blocks super 1.2 32k rounding
unused devices: <none>
[root@NAS00226b1755a0 ~]# mdadm -D /dev/md0
/dev/md0:
Version : 01.02.03
Creation Time : Wed Dec 9 03:02:50 2009
Raid Level : linear
Array Size : 444265856 (423.68 GiB 454.93 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Wed Dec 9 03:02:50 2009
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Rounding : 32K
Name : 0
UUID : 041dce1e:adafc8da:525455fe:5a9d950f
Events : 0
Number Major Minor RaidDevice State
0 8 0 0 active sync /dev/sata1
1 8 16 1 active sync /dev/sata2
Thanks,
Senthil M
^ permalink raw reply
* Re: [PATCH] NTFS: Change string pointers to string constants.
From: Marcin Slusarz @ 2009-12-09 14:59 UTC (permalink / raw)
To: Joe Perches
Cc: Anton Altaparmakov, John Daiker, kernel-janitors, aia21,
linux-ntfs-dev, LKML
In-Reply-To: <1260236833.3215.237.camel@Joe-Laptop.home>
On Mon, Dec 07, 2009 at 05:47:13PM -0800, Joe Perches wrote:
> On Tue, 2009-12-08 at 00:57 +0000, Anton Altaparmakov wrote:
> > Can you please explain the rational for making this change?
>
> Perhaps it's not worth much, but it saves a pointer reference.
>
> $ cat pointer.c
> #include <string.h>
> #include <stdio.h>
>
> int main (int argc, char** argv)
> {
> static const char *foo = "abcdefg";
> printf("%s\n", foo);
> return 0;
> }
>
> $ gcc -c pointer.c
> $ size pointer.o
> text data bss dec hex filename
> 37 4 0 41 29 pointer.o
>
> $ cat reference.c
> #include <string.h>
> #include <stdio.h>
>
> int main (int argc, char** argv)
> {
> static const char foo[] = "abcdefg";
> printf("%s\n", foo);
> return 0;
> }
>
> $ gcc -c reference.c
> $ size reference.o
> text data bss dec hex filename
> 36 0 0 36 24 reference.o
Yeah, for static variables it's better. But for automatic variables
it's worse, because it now has to do a copy at runtime.
And the patch changes both types.
$ size pointer.o reference.o
text data bss dec hex filename
101 8 0 109 6d pointer.o
96 0 0 96 60 reference.o
$ size pointer-nonstatic.o reference-nonstatic.o
text data bss dec hex filename
106 0 0 106 6a pointer-nonstatic.o
109 0 0 109 6d reference-nonstatic.o
^ permalink raw reply
* Re: [PATCH] multiboot-like module support
From: Samuel Thibault @ 2009-12-09 14:59 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <1260368975.23698.40977.camel@zakaz.uk.xensource.com>
Ian Campbell, le Wed 09 Dec 2009 14:29:35 +0000, a écrit :
> On Wed, 2009-12-09 at 14:01 +0000, Samuel Thibault wrote:
> > + * A multiboot module is a package containing modules very similar to
> > a
> > + * multiboot module array. The only differences are:
>
> I don't really know the multiboot layout but is there a reason not to
> use it as is rather than defining a new version?
It'd make the builder more tricky, as multiboot uses absolute
physical addresses. That'd mean extending libxc in order to take
the list of modules itself and build the table very late, during
xc_dom_build_image(), when the target virtual address is known, while
by using relative offsets, there is no need to, it's self-contained.
Relative offsets also permit to build a package even before submitting
it to xm create (that's how I'm using it atm actually).
I'm not against it, it's just that it is much less simple. One good
thing however is that then the code building the table would be in
libxc, shared by pv-grub and xend.
The other difference is how to know the number of modules. In the
multiboot standard, it's simply set in the boot_info structure. That
could be added to the start_info structure for instance.
> I would imagine that using the standard layout could potentially lead to
> less Xen specific code on the guest side.
Well, yes, I'd just answer that there aren't so many multiboot
implementations anyway :)
Samuel
^ permalink raw reply
* Re: Questions about Watch Dog Timer under Linux.
From: Mark Brown @ 2009-12-09 14:59 UTC (permalink / raw)
To: Cypher Wu; +Cc: linux-kernel
In-Reply-To: <f9f38a550912090647q5af6cb14w84ea8d9223d82bd9@mail.gmail.com>
On Wed, Dec 09, 2009 at 10:47:28PM +0800, Cypher Wu wrote:
> I'm used to work on embedded systems, the Watch Dog Timer in our
> products is usually a seperate chip on the board wich will start to
> work after power reset and will time out in 2 seconds. The system has
> to start dog clearing from the very beginning and there have no way to
> disable WDT.
> Now I want to use WDT under Linux, while I read
> Documentation/watchdog/watchdog-api.txt and then look though some
> drivers of WDT under Linux, it seems WDT under Linux has to be able to
> be disabled, and it will be disabled from the beginning, and starting
> to work after the application open the special driver file? The
> sample code under Linux use a very bigger time span than our embedded
> system:
You don't *have* to be able to disable the watchdog - the API supports
it but you can always fail to do so (and even where you can Linux
watchdogs support a non-disabling mode, look for WATCHDOG_NOWAYOUT in
existing drivers). Similarly, there's no problem with having the
watchdog be live at system startup - if the watchdog is already enabled
when the driver is opened then the driver just needs to handle that
gracefully.
> while (1) {
> ret = write(fd, "\0", 1);
...
> sleep(10);
> }
>
> Is this the pattern we have to follow to use WDT under Linux? We have
You're free to update the watchdog as often as you like, the 10s is
just a number that was picked which is suitable for that application.
> to choose a chip as WDT, and it seems the chip we've familiar under
> embedded systems can't be used under Linux?
Nothing about your watchdog sounds particularly unusual for Linux.
^ permalink raw reply
* Re: [PATCH] NTFS: Change string pointers to string constants.
From: Marcin Slusarz @ 2009-12-09 14:59 UTC (permalink / raw)
To: Joe Perches
Cc: Anton Altaparmakov, John Daiker, kernel-janitors, aia21,
linux-ntfs-dev, LKML
In-Reply-To: <1260236833.3215.237.camel@Joe-Laptop.home>
On Mon, Dec 07, 2009 at 05:47:13PM -0800, Joe Perches wrote:
> On Tue, 2009-12-08 at 00:57 +0000, Anton Altaparmakov wrote:
> > Can you please explain the rational for making this change?
>
> Perhaps it's not worth much, but it saves a pointer reference.
>
> $ cat pointer.c
> #include <string.h>
> #include <stdio.h>
>
> int main (int argc, char** argv)
> {
> static const char *foo = "abcdefg";
> printf("%s\n", foo);
> return 0;
> }
>
> $ gcc -c pointer.c
> $ size pointer.o
> text data bss dec hex filename
> 37 4 0 41 29 pointer.o
>
> $ cat reference.c
> #include <string.h>
> #include <stdio.h>
>
> int main (int argc, char** argv)
> {
> static const char foo[] = "abcdefg";
> printf("%s\n", foo);
> return 0;
> }
>
> $ gcc -c reference.c
> $ size reference.o
> text data bss dec hex filename
> 36 0 0 36 24 reference.o
Yeah, for static variables it's better. But for automatic variables
it's worse, because it now has to do a copy at runtime.
And the patch changes both types.
$ size pointer.o reference.o
text data bss dec hex filename
101 8 0 109 6d pointer.o
96 0 0 96 60 reference.o
$ size pointer-nonstatic.o reference-nonstatic.o
text data bss dec hex filename
106 0 0 106 6a pointer-nonstatic.o
109 0 0 109 6d reference-nonstatic.o
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Wolfram Sang @ 2009-12-09 14:57 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <200912091529.13913.roman.fietze@telemotive.de>
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hello Roman,
> I would be interested in your opinion, maybe Wolfgang could make some
> comments, because he is involved in the U-Boot a lot as well.
Do you have a way to measure performance penalties? I know that stability comes
before performance, still I am wondering as it looks to me that the most
interesting features are simply switched off.
Regrads,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [Resend PATCH] ACPI: Add the IPMI opregion driver to enable ACPI to access BMC controller
From: Bjorn Helgaas @ 2009-12-09 14:57 UTC (permalink / raw)
To: yakui.zhao; +Cc: lenb, linux-acpi
In-Reply-To: <1260323925-25701-1-git-send-email-yakui.zhao@intel.com>
On Tuesday 08 December 2009 06:58:45 pm yakui.zhao@intel.com wrote:
> From: Zhao Yakui <yakui.zhao@intel.com>
>
> Add the IPMI opregion driver so that the AML code can communicate with BMC
> throught IPMI message.
> It will create IPMI user interface for every IPMI device detected
> in ACPI namespace and install the corresponding IPMI opregion space handler.
>
> The following describes how to process the IPMI request in IPMI space handler:
> 1. format the IPMI message based on the request in AML code.
> IPMI system address. Now the address type is SYSTEM_INTERFACE_ADDR_TYPE
> IPMI net function & command
> IPMI message payload
> 2. send the IPMI message by using the function of ipmi_request_settime
> 3. wait for the completion of IPMI message. It can be done in different
> routes: One is in handled in IPMI user recv callback function. Another is
> handled in timeout function.
> 4. format the IPMI response and return it to ACPI AML code.
I think this should be part of the ipmi_si_intf module, not a separate
module. This opregion code is of no use without ipmi_si_intf. The
opregion code can still be under its own config option, but I don't
see the value in having it be a separate module.
The opregion code should definitely not use acpi_bus_register_driver()
to claim IPI0001 devices. The ipmi_si_intf driver already uses
pnp_register_driver() to claim IPI0001 devices. The fact that Linux
allows two drivers to claim the same device (one via pnp_register_driver()
and the other via acpi_bus_register_driver()) is a defect in Linux, and
we shouldn't take advantage of that.
Bjorn
> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
> ---
> drivers/acpi/Kconfig | 12 +
> drivers/acpi/Makefile | 1 +
> drivers/acpi/ipmi.c | 583 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 596 insertions(+), 0 deletions(-)
> create mode 100644 drivers/acpi/ipmi.c
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 93d2c79..23cd08a 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -204,6 +204,18 @@ config ACPI_PROCESSOR
>
> To compile this driver as a module, choose M here:
> the module will be called processor.
> +config ACPI_IPMI
> + tristate "IPMI"
> + depends on EXPERIMENTAL
> + default n
> + select IPMI_HANDLER
> + select IPMI_SI
> + help
> + This driver enables the ACPI to access the BMC controller. And it
> + uses the IPMI request/response message to communicate with BMC
> + controller, which can be found on on the server.
> +
> + To compile this driver as a module, choose M here:
>
> config ACPI_HOTPLUG_CPU
> bool
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 7702118..61077b7 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_ACPI_BATTERY) += battery.o
> obj-$(CONFIG_ACPI_SBS) += sbshc.o
> obj-$(CONFIG_ACPI_SBS) += sbs.o
> obj-$(CONFIG_ACPI_POWER_METER) += power_meter.o
> +obj-$(CONFIG_ACPI_IPMI) += ipmi.o
>
> # processor has its own "processor." module_param namespace
> processor-y := processor_core.o processor_throttling.o
> diff --git a/drivers/acpi/ipmi.c b/drivers/acpi/ipmi.c
> new file mode 100644
> index 0000000..5c74936
> --- /dev/null
> +++ b/drivers/acpi/ipmi.c
> @@ -0,0 +1,583 @@
> +/*
> + * ipmi.c - ACPI IPMI opregion
> + *
> + * Copyright (C) 2009 Intel Corporation
> + * Copyright (C) 2009 Zhao Yakui <yakui.zhao@intel.com>
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or (at
> + * your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> + *
> + * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/types.h>
> +#include <linux/delay.h>
> +#include <linux/proc_fs.h>
> +#include <linux/seq_file.h>
> +#include <linux/interrupt.h>
> +#include <linux/list.h>
> +#include <linux/spinlock.h>
> +#include <linux/io.h>
> +#include <acpi/acpi_bus.h>
> +#include <acpi/acpi_drivers.h>
> +#include <linux/ipmi.h>
> +
> +MODULE_AUTHOR("Zhao Yakui");
> +MODULE_DESCRIPTION("ACPI IPMI Opregion driver");
> +MODULE_LICENSE("GPL");
> +
> +#define ACPI_IPMI_CLASS "IPMI"
> +#define ACPI_IPMI_DEVICE_NAME "IPMI_dev"
> +#define IPMI_FLAGS_HANDLER_INSTALL 0
> +
> +#define ACPI_IPMI_OK 0
> +#define ACPI_IPMI_TIMEOUT 0x10
> +#define ACPI_IPMI_UNKNOWN 0x07
> +/* the IPMI timeout is 30s */
> +#define IPMI_TIMEOUT (30 * HZ)
> +
> +
> +struct acpi_ipmi_device {
> + acpi_handle handle;
> + struct acpi_device *device;
> + int if_type;
> + /* the device list attached to driver_data.ipmi_devices */
> + struct list_head head;
> + ipmi_user_t user_interface;
> + struct mutex mutex_lock;
> + /* the IPMI request message list */
> + struct list_head tx_msg_list;
> + long curr_msgid;
> + /* IPMI flags */
> + unsigned long flags;
> +};
> +
> +struct ipmi_driver_data {
> + int device_count;
> + struct list_head ipmi_devices;
> + struct ipmi_smi_watcher bmc_events;
> + struct ipmi_user_hndl ipmi_hndlrs;
> +};
> +
> +struct acpi_ipmi_msg {
> + /* message list */
> + struct list_head head;
> + /*
> + * General speaking the addr type should be SI_ADDR_TYPE. And
> + * the addr channel should be BMC.
> + * In fact it can also be IPMB type. But we will have to
> + * parse it from the Netfn command buffer. It is so complex
> + * that it is skipped.
> + */
> + struct ipmi_addr addr;
> + /* tx message id */
> + long tx_msgid;
> + /* it is used to track whether the IPMI message is finished */
> + struct completion tx_complete;
> + struct kernel_ipmi_msg tx_message;
> + int msg_done;
> + /* tx data . And copy it from ACPI object buffer */
> + u8 tx_data[64];
> + int tx_len;
> + /* get the response data */
> + u8 rx_data[64];
> + /* the response length. The netfn & cmd is excluded. */
> + int rx_len;
> + struct acpi_ipmi_device *device;
> +};
> +
> +/*
> + * IPMI request/response buffer.
> + * The length is 66 bytes.
> + */
> +struct acpi_ipmi_buffer {
> + /* status code of a given IPMI command */
> + u8 status_code;
> + /* the length of the payload */
> + u8 length;
> + /*
> + * the payload. Before the operation is carried out, it represents the
> + * request message payload. After the opration is carried out, it
> + * stores the response message returned by IPMI command.
> + */
> + u8 data[64];
> +};
> +
> +static void ipmi_register_bmc(int iface, struct device *dev);
> +static void ipmi_bmc_gone(int iface);
> +static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data);
> +
> +static struct ipmi_driver_data driver_data = {
> + .ipmi_devices = LIST_HEAD_INIT(driver_data.ipmi_devices),
> + .bmc_events = {
> + .owner = THIS_MODULE,
> + .new_smi = ipmi_register_bmc,
> + .smi_gone = ipmi_bmc_gone,
> + },
> + .ipmi_hndlrs = {
> + .ipmi_recv_hndl = ipmi_msg_handler,
> + },
> +};
> +
> +static
> +struct acpi_ipmi_msg *acpi_alloc_ipmi_msg(struct acpi_ipmi_device *ipmi)
> +{
> + struct acpi_ipmi_msg *ipmi_msg;
> +
> + ipmi_msg = kzalloc(sizeof(struct acpi_ipmi_msg), GFP_KERNEL);
> + if (!ipmi_msg) {
> + printk(KERN_DEBUG "Can't allocate memory for ipmi_msg\n");
> + return NULL;
> + }
> + init_completion(&ipmi_msg->tx_complete);
> + INIT_LIST_HEAD(&ipmi_msg->head);
> + ipmi_msg->device = ipmi;
> + return ipmi_msg;
> +}
> +
> +static void acpi_format_ipmi_msg(struct acpi_ipmi_msg *tx_msg,
> + acpi_physical_address address,
> + acpi_integer *value)
> +{
> + struct kernel_ipmi_msg *msg;
> + u8 temp_value;
> + struct acpi_ipmi_buffer *buffer;
> + struct acpi_ipmi_device *device;
> +
> + msg = &tx_msg->tx_message;
> + /* get the netfn */
> + temp_value = (address >> 8) & 0xff;
> + msg->netfn = temp_value;
> + /* get the command */
> + temp_value = address & 0xff;
> + msg->cmd = temp_value;
> + msg->data = tx_msg->tx_data;
> + /*
> + * value is the parameter passed by the IPMI opregion space handler.
> + * It points to the IPMI request message buffer
> + */
> + buffer = (struct acpi_ipmi_buffer *)value;
> + /* copy the tx message data */
> + msg->data_len = buffer->length;
> + memcpy(tx_msg->tx_data, buffer->data, msg->data_len);
> + /*
> + * now the default type is SYSTEM_INTERFACE and channel type is BMC.
> + * If the netfn is APP_REQUEST and the cmd is SEND_MESSAGE,
> + * the addr type should be changed to IPMB.
> + */
> + tx_msg->addr.addr_type = IPMI_SYSTEM_INTERFACE_ADDR_TYPE;
> + tx_msg->addr.channel = IPMI_BMC_CHANNEL;
> + tx_msg->addr.data[0] = 0;
> +
> + /*
> + * If the netfn is APP_REQUEST and the cmd is SEND_MESSAGE, we should
> + * parse the IPMI request message buffer to get the IPMB address.
> + * If so, please fix me.
> + */
> +
> + /* Get the msgid */
> + device = tx_msg->device;
> + mutex_lock(&device->mutex_lock);
> + device->curr_msgid++;
> + tx_msg->tx_msgid = device->curr_msgid;
> + mutex_unlock(&device->mutex_lock);
> +}
> +
> +static void acpi_format_ipmi_response(struct acpi_ipmi_msg *msg,
> + acpi_integer *value, int timeout)
> +{
> + struct acpi_ipmi_buffer *buffer;
> +
> + /*
> + * value is also used as output parameter. It represents the response
> + * IPMI message returned by IPMI command.
> + */
> + buffer = (struct acpi_ipmi_buffer *)value;
> + /* when timeout is zero, it means that the timeout happens */
> + if (!timeout) {
> + /* the status code is ACPI_IPMI_TIMEOUT */
> + buffer->status_code = ACPI_IPMI_TIMEOUT;
> + return;
> + }
> + /*
> + * If the flag of msg_done is not set, it means that the IPMI command
> + * is not executed correctly.
> + * The status code will be ACPI_IPMI_UNKNOWN.
> + */
> + if (!msg->msg_done) {
> + buffer->status_code = ACPI_IPMI_UNKNOWN;
> + return;
> + }
> + /*
> + * If the IPMI response message is obtained correctly, the status code
> + * will be ACPI_IPMI_OK
> + */
> + buffer->status_code = ACPI_IPMI_OK;
> + buffer->length = msg->rx_len;
> + memcpy(buffer->data, msg->rx_data, msg->rx_len);
> + return;
> +}
> +static void ipmi_destroy_tx_msg(struct acpi_ipmi_device *ipmi)
> +{
> + struct acpi_ipmi_msg *tx_msg = NULL;
> + int count = 20;
> +
> + list_for_each_entry(tx_msg, &ipmi->tx_msg_list, head) {
> + /* wake up the sleep thread on the Tx msg */
> + complete(&tx_msg->tx_complete);
> + }
> + /* wait for about 20 ticks to flush the tx message list */
> + while (count--) {
> + if (list_empty(&ipmi->tx_msg_list))
> + break;
> + schedule_timeout(1);
> + }
> + if (!list_empty(&ipmi->tx_msg_list))
> + printk(KERN_DEBUG "tx msg list is not NULL\n");
> +
> +}
> +
> +static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data)
> +{
> + struct acpi_ipmi_device *ipmi_device =
> + (struct acpi_ipmi_device *)user_msg_data;
> + int msg_found = 0;
> + struct acpi_ipmi_msg *tx_msg = NULL;
> +
> + if (msg->user != ipmi_device->user_interface) {
> + printk(KERN_DEBUG "Incorrect IPMI user\n");
> + ipmi_free_recv_msg(msg);
> + return;
> + }
> + mutex_lock(&ipmi_device->mutex_lock);
> + list_for_each_entry(tx_msg, &ipmi_device->tx_msg_list, head) {
> + if (msg->msgid == tx_msg->tx_msgid) {
> + /* find the message id */
> + msg_found = 1;
> + break;
> + }
> + }
> +
> + mutex_unlock(&ipmi_device->mutex_lock);
> + if (!msg_found) {
> + /* no matched msg is found . But we should free it */
> + ipmi_free_recv_msg(msg);
> + printk(KERN_DEBUG "Incorrect MSG is found \n");
> + return;
> + }
> +
> + if (msg->msg.data_len > 1) {
> + /* copy the response data to Rx_data buffer */
> + memcpy(tx_msg->rx_data, msg->msg_data, msg->msg.data_len);
> + tx_msg->rx_len = msg->msg.data_len;
> + tx_msg->msg_done = 1;
> + }
> + complete(&tx_msg->tx_complete);
> + ipmi_free_recv_msg(msg);
> +};
> +
> +static void ipmi_register_bmc(int iface, struct device *dev)
> +{
> + struct acpi_ipmi_device *ipmi_device;
> + struct acpi_device *device;
> + ipmi_user_t user;
> + int err;
> +
> + if (list_empty(&driver_data.ipmi_devices))
> + return;
> +
> + list_for_each_entry(ipmi_device, &driver_data.ipmi_devices, head) {
> + device = ipmi_device->device;
> + if (ipmi_device->user_interface) {
> + /*
> + * Only one user interface is allowed to be registered
> + * for one IPMI device.
> + * If we already create the user interface for
> + * one IPMI device, skip it
> + */
> + continue;
> + }
> + if (dev == &device->dev) {
> + /*
> + * If the dev is identical to the ACPI device,
> + * create the user interface.
> + */
> + err = ipmi_create_user(iface, &driver_data.ipmi_hndlrs,
> + ipmi_device, &user);
> + if (err == 0)
> + ipmi_device->user_interface = user;
> +
> + continue;
> + }
> + /*
> + * In fact maybe the IPMI interface can be registered by
> + * other methods. For example: SPMI, DMI, PCI
> + * So we should also create the user interface.
> + */
> + err = ipmi_create_user(iface, &driver_data.ipmi_hndlrs,
> + ipmi_device, &user);
> + if (err == 0)
> + ipmi_device->user_interface = user;
> + }
> + return;
> +}
> +
> +static void ipmi_bmc_gone(int iface)
> +{
> + struct acpi_ipmi_device *ipmi_device;
> +
> + if (list_empty(&driver_data.ipmi_devices))
> + return;
> +
> + list_for_each_entry(ipmi_device, &driver_data.ipmi_devices, head) {
> + if (ipmi_device->user_interface) {
> + ipmi_destroy_user(ipmi_device->user_interface);
> + ipmi_device->user_interface = NULL;
> + /* we should also destory tx msg list */
> + ipmi_destroy_tx_msg(ipmi_device);
> + }
> + }
> +}
> +/* --------------------------------------------------------------------------
> + * Address Space Management
> + -------------------------------------------------------------------------- */
> +/*
> + * This is the IPMI opregion space handler.
> + * @function: indicates the read/write. In fact as the IPMI message is driven
> + * by command, only write is meaningful.
> + * @address: This contains the netfn/command of IPMI request message.
> + * @bits : not used.
> + * @value : it is an in/out parameter. It points to the IPMI message buffer.
> + * Before the IPMI message is sent, it represents the actual request
> + * IPMI message. After the IPMI message is finished, it represents
> + * the response IPMI message returned by IPMI command.
> + * @handler_context: IPMI device context.
> + */
> +
> +static acpi_status
> +acpi_ipmi_space_handler(u32 function, acpi_physical_address address,
> + u32 bits, acpi_integer *value,
> + void *handler_context, void *region_context)
> +{
> + struct acpi_ipmi_msg *tx_msg = NULL;
> + struct acpi_ipmi_device *ipmi_device =
> + (struct acpi_ipmi_device *) handler_context;
> + int err;
> + acpi_status status;
> + /*
> + * IPMI opregion message.
> + * IPMI message is firstly written to the BMC and system software
> + * can get the respsonse. So it is unmeaningful for the IPMI read
> + * access.
> + */
> + if ((function & ACPI_IO_MASK) == ACPI_READ) {
> + /* Read function is not supported. AE_TYPE is returned. */
> + return AE_TYPE;
> + }
> + if (!ipmi_device->user_interface) {
> + /* there doesn't exist user interface*/
> + return AE_NOT_EXIST;
> + }
> + tx_msg = acpi_alloc_ipmi_msg(ipmi_device);
> + if (!tx_msg) {
> + /* no memory is allocated */
> + return AE_NO_MEMORY;
> + }
> + acpi_format_ipmi_msg(tx_msg, address, value);
> + mutex_lock(&ipmi_device->mutex_lock);
> + list_add_tail(&tx_msg->head, &ipmi_device->tx_msg_list);
> + mutex_unlock(&ipmi_device->mutex_lock);
> + err = ipmi_request_settime(ipmi_device->user_interface,
> + &tx_msg->addr,
> + tx_msg->tx_msgid,
> + &tx_msg->tx_message,
> + NULL, 0, 0, 0);
> + if (err) {
> + status = AE_ERROR;
> + goto end_label;
> + }
> + err = wait_for_completion_timeout(&tx_msg->tx_complete, IPMI_TIMEOUT);
> +
> +end_label:
> + acpi_format_ipmi_response(tx_msg, value, err);
> + status = AE_OK;
> + mutex_lock(&ipmi_device->mutex_lock);
> + list_del(&tx_msg->head);
> + mutex_unlock(&ipmi_device->mutex_lock);
> + kfree(tx_msg);
> + return status;
> +}
> +
> +static void ipmi_remove_handlers(struct acpi_ipmi_device *ipmi)
> +{
> + if (!test_bit(IPMI_FLAGS_HANDLER_INSTALL, &ipmi->flags))
> + return;
> + acpi_remove_address_space_handler(ipmi->handle,
> + ACPI_ADR_SPACE_IPMI, &acpi_ipmi_space_handler);
> +
> + clear_bit(IPMI_FLAGS_HANDLER_INSTALL, &ipmi->flags);
> +}
> +
> +static int ipmi_install_handlers(struct acpi_ipmi_device *ipmi)
> +{
> + acpi_status status;
> +
> + if (test_bit(IPMI_FLAGS_HANDLER_INSTALL, &ipmi->flags))
> + return 0;
> +
> + status = acpi_install_address_space_handler(ipmi->handle,
> + ACPI_ADR_SPACE_IPMI,
> + &acpi_ipmi_space_handler,
> + NULL, ipmi);
> + if (ACPI_FAILURE(status)) {
> + printk(KERN_DEBUG "Can't register IPMI opregion %s\n",
> + acpi_device_bid(ipmi->device));
> + return -EINVAL;
> + }
> + set_bit(IPMI_FLAGS_HANDLER_INSTALL, &ipmi->flags);
> + return 0;
> +}
> +
> +static int acpi_ipmi_add(struct acpi_device *device)
> +{
> + struct acpi_ipmi_device *ipmi_device;
> + acpi_handle handle;
> + unsigned long long temp;
> + acpi_status status;
> + if (!device)
> + return -EINVAL;
> +
> + handle = device->handle;
> + temp = 0;
> + status = acpi_evaluate_integer(handle, "_IFT", NULL, &temp);
> + if (ACPI_FAILURE(status)) {
> + printk(KERN_DEBUG "Incorrect _IFT object for %s\n",
> + acpi_device_bid(device));
> + return -ENODEV;
> + }
> + ipmi_device = kzalloc(sizeof(struct acpi_ipmi_device), GFP_KERNEL);
> + if (!ipmi_device) {
> + printk(KERN_DEBUG "Can't allocate memory space\n");
> + return -ENOMEM;
> + }
> + ipmi_device->if_type = temp;
> + switch (ipmi_device->if_type) {
> + case 1:
> + case 2:
> + case 3:
> + break;
> + default:
> + printk(KERN_DEBUG "Unknow IPMI:SI interface type %d\n",
> + ipmi_device->if_type);
> + kfree(ipmi_device);
> + return -EINVAL;
> + }
> + ipmi_device->handle = device->handle;
> + ipmi_device->device = device;
> + mutex_init(&ipmi_device->mutex_lock);
> + INIT_LIST_HEAD(&ipmi_device->head);
> + INIT_LIST_HEAD(&ipmi_device->tx_msg_list);
> +
> + if (ipmi_install_handlers(ipmi_device)) {
> + /* can't register the IPMI opregion */
> + kfree(ipmi_device);
> + return -EINVAL;
> + }
> +
> + /* add it to the IPMI device list */
> + list_add_tail(&ipmi_device->head, &driver_data.ipmi_devices);
> + device->driver_data = ipmi_device;
> + return 0;
> +}
> +
> +static int acpi_ipmi_remove(struct acpi_device *device, int type)
> +{
> + struct acpi_ipmi_device *ipmi_device;
> +
> + ipmi_device = acpi_driver_data(device);
> + if (!ipmi_device)
> + return 0;
> +
> + if (ipmi_device->user_interface) {
> + /*
> + * If the IPMI user interface is created, it should be
> + * destroyed.
> + */
> + ipmi_destroy_user(ipmi_device->user_interface);
> + ipmi_device->user_interface = NULL;
> + }
> + list_del(&ipmi_device->head);
> + if (!list_empty(&ipmi_device->tx_msg_list)) {
> + /* destroy the Tx_msg list */
> + ipmi_destroy_tx_msg(ipmi_device);
> + }
> + ipmi_remove_handlers(ipmi_device);
> + kfree(ipmi_device);
> + device->driver_data = NULL;
> + return 0;
> +}
> +
> +static const struct acpi_device_id ipmi_device_ids[] = {
> + {"IPI0001", 0},
> + {"", 0},
> +};
> +
> +static struct acpi_driver acpi_ipmi_driver = {
> + .name = "ipmi",
> + .class = ACPI_IPMI_CLASS,
> + .ids = ipmi_device_ids,
> + .ops = {
> + .add = acpi_ipmi_add,
> + .remove = acpi_ipmi_remove,
> + },
> +};
> +
> +static int __init acpi_ipmi_init(void)
> +{
> + int result = 0;
> +
> + if (acpi_disabled)
> + return result;
> +
> + result = acpi_bus_register_driver(&acpi_ipmi_driver);
> +
> + if (result)
> + return result;
> +
> + result = ipmi_smi_watcher_register(&driver_data.bmc_events);
> +
> + if (result)
> + acpi_bus_unregister_driver(&acpi_ipmi_driver);
> +
> + return result;
> +}
> +
> +static void __exit acpi_ipmi_exit(void)
> +{
> + if (acpi_disabled)
> + return;
> +
> + ipmi_smi_watcher_unregister(&driver_data.bmc_events);
> + acpi_bus_unregister_driver(&acpi_ipmi_driver);
> +
> + return;
> +}
> +
> +module_init(acpi_ipmi_init);
> +module_exit(acpi_ipmi_exit);
^ 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.