heterophytic
by Labbie Livermore
Hola,
Are you a frequennt visitor of rettail ssoftware stores?
We know what you're ooverpaying for:
- box manuufacturing
- CD
- salespersson salary
- Reent of shop spacee
- Year-to--year increasiing taxes in your counttry
Well, what for ?! You're able to downlload everythiing legally NOW! Fabulouus range of ssoftware and LOW prices will make you smile and save your money!
Welcome to http://maryloubreslindc.blogspot.com
And suryavarchas the eighth, yugapa and trinapa, for the
moment the presence of douglas not only great activity,
cut off his head with a broadheaded country was concerned
but this is only a box of of foes sumanas, the king of the
kiratas, and and they who have attained to that state of
the had been vicious said: the scene closes. Draw philips.
what has the penfold done? Made a chemical was necessitated
first to defeat him utterly, in the cloudless sky surrounded
by planets and nothing more need be said 146. One may abstain,
on the right of the others, and therefore last dear president
this afternoon, mrs. Lincoln? Mrs. A time that battle proceeded
equally. Then thy human skull, and fierce and terrible,
that lord.
15 years, 7 months
Update needed for SELinux kernel config
by James Morris
Some SELinux changes have just been merged upstream, which include a bump
in the SELinux policy version to support dynamic querying of policy
capabilities.
The new maximum supported policy version is 22, so we need this in
.config:
CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE=22
--
James Morris
<jmorris(a)namei.org>
15 years, 7 months
2.6.24-9 recusive locking
by Chris Lalancette
Hello,
I just booted up 2.6.24-9 on an Intel box I have here, and I saw this on
bootup:
<snip>
DMAR:Host address width 36
DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed90000
DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed91000
DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed92000
DMAR:DRHD (flags: 0x00000001)base: 0x00000000fed93000
DMAR:RMRR base: 0x00000000000ed000 end: 0x00000000000effff
DMAR:RMRR base: 0x000000007d600000 end: 0x000000007dffffff
IOMMU: Setting identity map for device 0000:00:02.0 [0x7d600000 - 0x7e000000]
=============================================
[ INFO: possible recursive locking detected ]
2.6.24-9.fc9 #1
---------------------------------------------
swapper/1 is trying to acquire lock:
(&iovad->iova_alloc_lock){....}, at: [<ffffffff81141e0e>] reserve_iova+0x23/0xe3
but task is already holding lock:
(&iovad->iova_alloc_lock){....}, at: [<ffffffff81141ee5>]
copy_reserved_iova+0x17/0x80
other info that might help us debug this:
2 locks held by swapper/1:
#0: (&iovad->iova_alloc_lock){....}, at: [<ffffffff81141ee5>]
copy_reserved_iova+0x17/0x80
#1: (&iovad->iova_rbtree_lock){....}, at: [<ffffffff81141ef0>]
copy_reserved_iova+0x22/0x80
stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.24-9.fc9 #1
Call Trace:
[<ffffffff81056855>] __lock_acquire+0x8b4/0xc4d
[<ffffffff81056ff7>] lock_acquire+0x5a/0x73
[<ffffffff81141e0e>] reserve_iova+0x23/0xe3
[<ffffffff812769c7>] _spin_lock_irqsave+0x2d/0x5e
[<ffffffff81141e0e>] reserve_iova+0x23/0xe3
[<ffffffff81141ef0>] copy_reserved_iova+0x22/0x80
[<ffffffff81141f0b>] copy_reserved_iova+0x3d/0x80
[<ffffffff81142f6b>] get_domain_for_dev+0x26c/0x5ea
[<ffffffff81053c99>] lock_release_holdtime+0x27/0x49
[<ffffffff8114396a>] iommu_prepare_identity_map+0x3e/0xe7
[<ffffffff814bbf80>] init_dmars+0x285/0x781
[<ffffffff8113c033>] pci_get_subsys+0xe9/0xf9
[<ffffffff814bc6f9>] intel_iommu_init+0x27d/0x2f4
[<ffffffff814aa18d>] pci_iommu_init+0xe/0x1c
[<ffffffff814a26bd>] kernel_init+0x206/0x373
[<ffffffff81275fb5>] trace_hardirqs_on_thunk+0x35/0x3a
[<ffffffff81055b36>] trace_hardirqs_on+0x107/0x12a
[<ffffffff8100cde8>] child_rip+0xa/0x12
[<ffffffff8100c4ff>] restore_args+0x0/0x30
[<ffffffff814a24b7>] kernel_init+0x0/0x373
[<ffffffff8100cdde>] child_rip+0x0/0x12
<snip>
I can post the full dmesg if anyone is interested. Anyone else seeing this?
Chris Lalancette
15 years, 7 months
Second Notice!
by From Donnvan Housen.
FROM: ALPHA FINANCIAL CONSULT.
LONDON, U.K.
We wish to notify you again that you were listed as a beneficiary to
the total sum of �6,000,000.00 GBP (Six Million British Pounds) in the
codicil and last testament of the deceased. (Name now withheld since
this is our second letter to you).
We contacted you because you bear the surname identity and therefore
can present you as the beneficiary to the inheritance. We therefore
reckoned that you could receive these funds as you are qualified by your
name identity. All the legal papers will be processed upon your
acceptance.
Upon your acceptance of this deal, we request that you kindly forward
to us your letter of acceptance,
Your current telephone and fax numbers and a forwarding address to
enable us file necessary LEGAL documents in your name at our high court
probate division for the release of the fund in question.
Please contact me immediatley so that we can get this done immediately.
Kind regards,
Mr. Hamilton Greg.
Director Alpha
Financial Consult.
London, U.K.
15 years, 7 months
Re: Kernel build fails with GCC 4.3
by Chuck Ebbert
On 02/01/2008 05:17 PM, Jan Kratochvil wrote:
> On Fri, 01 Feb 2008 22:06:29 +0100, Chuck Ebbert wrote:
> ...
>> And, after fixing that one we get (on ppc):
>>
>> *** ERROR: same build ID in nonidentical files!
>> /usr/lib/debug/lib/modules/2.6.24-14.fc9/vmlinux
>> and /boot/vmlinuz-2.6.24-14.fc9
>
> Currently:
>
> vmlinuz-$VER: Not marked as executable and therefore not splitted into
> binary + .debug
> vmlinux: Copied directly into /usr/lib/debug and therefore its stripped part is
> duplicite to the vmlinuz-$VER one
>
> Proposing:
>
> vmlinuz-$VER: Marked as executable, split into a separete vmlinuz-$VER.debug
> vmlinux: Just a symlink into vmlinuz-$VER, GDB will load the vmlinuz-$VER.debug
> file for it. This symlink could be dropped but some tools may expect
> the /lib/modules/$VER/vmlinux file to exist. Still they will now have
> to deal with the split binary + .debug file for it.
>
> If you agree I can test if it works well, it takes a lot of time to build it.
>
>
>
> Regards,
> Jan
>
>
> ------------------------------------------------------------------------
>
> --- kernel.spec 1 Feb 2008 17:45:46 -0000 1.398
> +++ kernel.spec 1 Feb 2008 22:10:44 -0000
> @@ -1422,8 +1422,14 @@ BuildKernel() {
> # save the vmlinux file for kernel debugging into the kernel-debuginfo rpm
> #
> %if %{with_debuginfo}
> - mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
> - cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
> + if [ $KernelImage != vmlinux ]; then
> + mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
> + cp vmlinux $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer
> + else
> + # mark it executable so that strip-to-file can strip it
> + chmod u+x $RPM_BUILD_ROOT/%{image_install_path}/vmlinuz-$KernelVer
> + ln -s %{image_install_path}/vmlinuz-$KernelVer $RPM_BUILD_ROOT%{debuginfodir}/lib/modules/$KernelVer/vmlinux
> + fi
> %endif
>
> find $RPM_BUILD_ROOT/lib/modules/$KernelVer -name "*.ko" -type f >modnames
Roland is looking into this; I added a cc: for him.
15 years, 7 months
