Hi,
Horst Rauber wrote:
> I'm having the same problem (autofs hangs when accessing an auto mount point)
> with recent kernels, so I wonder if this is really fixed upstream or if there
> is another cause.
>
> Affected kernel: vanilla 3.2.13 and 3.3.1 (both amd64)
> Working kernel: 3.1.10 (amd64)
>
Hi,
I'm having the same problem (autofs hangs when accessing an auto mount point)
with recent kernels, so I wonder if this is really fixed upstream or if there
is another cause.
Affected kernel: vanilla 3.2.13 and 3.3.1 (both amd64)
Working kernel: 3.1.10 (amd64)
Userspace: autofs5 5.0.4-3.2+b1
tags 633423 = patch upstream
quit
Sven Joachim wrote:
> 3.3-rc5 works for me, as does 3.2.7 with the following changes
> cherry-picked:
>
> a32744d4abae (autofs: work around unhappy compat problem on x86-64)
> 3c761ea05a89 (Fix autofs compile without CONFIG_COMPAT)
> 048cd4e51d24 (compat: fix com
tags 633423 + fixed-upstream patch
thanks
On 2012-02-24 20:15 +0100, Sven Joachim wrote:
> Short summary for readers new to the bug: boot hangs with i386 systemd
> and an x86_64 kernel.
>
> On 2011-10-15 21:51 +0200, Sven Joachim wrote:
>
>> It seems that somebody who is both smarter and more p
On 2012-02-24 20:44 +0100, Bastian Blank wrote:
> On Fri, Feb 24, 2012 at 08:15:09PM +0100, Sven Joachim wrote:
>> Short summary for readers new to the bug: boot hangs with i386 systemd
>> and an x86_64 kernel.
>
> Care to explain why it hangs and not dies?
Here is Thomas Meyer's explanation fr
On Fri, Feb 24, 2012 at 01:54:39PM -0600, Jonathan Nieder wrote:
> Ben Hutchings wrote:
>
> > (But why hasn't this been spotted on sparc or powerpc already,
> > where 32-bit userland on 64-bit kernel is the normal case?)
>
> __u64 is 64-bit aligned on those arches in 32-bit mode.
>
> http://thre
On Fri, Feb 24, 2012 at 07:50:05PM +, Ben Hutchings wrote:
> On Fri, Feb 24, 2012 at 08:15:09PM +0100, Sven Joachim wrote:
> [...]
> > Thankfully this problem has now been communicated to Linus himself, and
> > he agreed that it should be fixed in the kernel.
> Of course it should. A shame tha
Ben Hutchings wrote:
> (But why hasn't this been spotted on sparc or powerpc already,
> where 32-bit userland on 64-bit kernel is the normal case?)
__u64 is 64-bit aligned on those arches in 32-bit mode.
http://thread.gmane.org/gmane.linux.kernel/1255890
--
To UNSUBSCRIBE, email to debian-bu
On Fri, Feb 24, 2012 at 08:15:09PM +0100, Sven Joachim wrote:
[...]
> Thankfully this problem has now been communicated to Linus himself, and
> he agreed that it should be fixed in the kernel.
Of course it should. A shame that some kernel maintainers think
they don't have to care about 32-bit com
found 633423 linux-2.6/3.2.6-1
tags 633423 + upstream
# broken interface introduced in v2.6.17-rc1~444
# amd64 kernel image on i386 introduced in 2.6.18.dfsg.1-10
found 633423 linux-2.6/2.6.18.dfsg.1-10
forwarded 633423
http://thread.gmane.org/gmane.linux.kernel/1256405/focus=1256966
quit
Sven Jo
On Fri, Feb 24, 2012 at 08:15:09PM +0100, Sven Joachim wrote:
> Short summary for readers new to the bug: boot hangs with i386 systemd
> and an x86_64 kernel.
Care to explain why it hangs and not dies?
Bastian
--
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", sta
reassign 633423 linux-2.6
retitle 633423 autofs4 interface is broken between x86 and x86_64
affects 633423 systemd
thanks
Short summary for readers new to the bug: boot hangs with i386 systemd
and an x86_64 kernel.
On 2011-10-15 21:51 +0200, Sven Joachim wrote:
> It seems that somebody who is
It seems that somebody who is both smarter and more pertinacious than
myself has tried to use a 32-bit systemd under 64-bit kernel and
experienced the hangs, see the thread starting at [1].
Thomas Meyer proposed a patch in [2], but it was rejected, arguing that
the incompatibility should be fixed
13 matches
Mail list logo
