I have to admit I'm completely lost at this point. This new trace looks
totally strange to me, and I'm pretty sure whatever symptoms you see are
due to different alignments / code sections etc just triggered by the
removal, we need help from the real sparc experts.
On 24.03.21 17:33, Frank Scheiner wrote:
On 24.03.21 17:10, Christoph Hellwig wrote:
On Wed, Mar 24, 2021 at 04:58:39PM +0100, Frank Scheiner wrote:
[ 20.090279] [<006c6494>] sys_mount+0x114/0x1e0
[ 20.090338] [<006c6454>] sys_mount+0xd4/0x1e0
[ 20.090499]
On 24.03.21 17:10, Christoph Hellwig wrote:
On Wed, Mar 24, 2021 at 04:58:39PM +0100, Frank Scheiner wrote:
[ 20.090279] [<006c6494>] sys_mount+0x114/0x1e0
[ 20.090338] [<006c6454>] sys_mount+0xd4/0x1e0
[ 20.090499] [<00406274>] linux_sparc_syscall+0x34/0x44
[
On Wed, Mar 24, 2021 at 04:58:39PM +0100, Frank Scheiner wrote:
> [ 20.090279] [<006c6494>] sys_mount+0x114/0x1e0
> [ 20.090338] [<006c6454>] sys_mount+0xd4/0x1e0
> [ 20.090499] [<00406274>] linux_sparc_syscall+0x34/0x44
> [ 20.090697] Disabling lock debugging due
On 24.03.21 16:22, Jan Engelhardt wrote:
On Wednesday 2021-03-24 14:57, Frank Scheiner wrote:
(gdb) l *(sys_mount+0x114/0x1e0)
0x6c6380 is in __se_sys_mount (fs/namespace.c:3390).
/0x1e0 does not normally belong there. Just
l *(sys_mount+0x114)
I guess this comes from my log
On Wednesday 2021-03-24 14:57, Frank Scheiner wrote:
> (gdb) l *(sys_mount+0x114/0x1e0)
> 0x6c6380 is in __se_sys_mount (fs/namespace.c:3390).
/0x1e0 does not normally belong there. Just
l *(sys_mount+0x114)
On 24.03.21 09:28, Christoph Hellwig wrote:
On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote:
028abd9222df0cf5855dab5014a5ebaf06f90565
...is broken on my T1000.
As I don't know how big attachments can be on this list, I put the logs
on pastebin.
A log for 028abd9222df is here:
On 24.03.21 14:24, Anatoly Pugachev wrote:
On Wed, Mar 24, 2021 at 4:19 PM Frank Scheiner wrote:
On 24.03.21 14:16, John Paul Adrian Glaubitz wrote:
On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available on
the T1000.
If need be, where do they need to exist and how
On Wed, Mar 24, 2021 at 4:19 PM Frank Scheiner wrote:
> On 24.03.21 14:16, John Paul Adrian Glaubitz wrote:
> > On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available
> > on the T1000.
> >>
> >> If need be, where do they need to exist and how should the directory be
> >>
On 24.03.21 14:16, John Paul Adrian Glaubitz wrote:
On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available on
the T1000.
If need be, where do they need to exist and how should the directory be
named - `/usr/src/[...]`?
Try installing "linux-source" and the "-dbg"
On 3/24/21 2:09 PM, Frank Scheiner wrote:> Kernel sources are not available on
the T1000.
>
> If need be, where do they need to exist and how should the directory be
> named - `/usr/src/[...]`?
Try installing "linux-source" and the "-dbg" package for your Debian kernel.
Adrian
--
.''`.
On 24.03.21 09:28, Christoph Hellwig wrote:
On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote:
028abd9222df0cf5855dab5014a5ebaf06f90565
...is broken on my T1000.
As I don't know how big attachments can be on this list, I put the logs
on pastebin.
A log for 028abd9222df is
Hello Frank!
On 3/24/21 1:30 PM, Frank Scheiner wrote:
> Sorry, but I can't install `gdb` on my T1000 ATM, because it depends on
> "libpython3.8" for sparc64 (see [1]) and "libpython3.9" for the other
> architectures, but "libpython3.8" is actually not available for sparc64,
> "libpython3.9" is
On 24.03.21 13:42, Anatoly Pugachev wrote:
On Wed, Mar 24, 2021 at 3:31 PM Frank Scheiner wrote:
Sorry, but I can't install `gdb` on my T1000 ATM, because it depends on
"libpython3.8" for sparc64 (see [1]) and "libpython3.9" for the other
architectures, but "libpython3.8" is actually not
On Wed, Mar 24, 2021 at 3:31 PM Frank Scheiner wrote:
> Sorry, but I can't install `gdb` on my T1000 ATM, because it depends on
> "libpython3.8" for sparc64 (see [1]) and "libpython3.9" for the other
> architectures, but "libpython3.8" is actually not available for sparc64,
> "libpython3.9" is
On 24.03.21 09:28, Christoph Hellwig wrote:
On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote:
028abd9222df0cf5855dab5014a5ebaf06f90565
...is broken on my T1000.
As I don't know how big attachments can be on this list, I put the logs
on pastebin.
A log for 028abd9222df is here:
On Tue, Mar 23, 2021 at 11:17:41PM +0100, Frank Scheiner wrote:
> 028abd9222df0cf5855dab5014a5ebaf06f90565
>
> ...is broken on my T1000.
>
> As I don't know how big attachments can be on this list, I put the logs
> on pastebin.
>
> A log for 028abd9222df is here:
>
> https://pastebin.com/ApPYsMcu
On 23.03.21 17:57, Christoph Hellwig wrote:> Frank, can you double check
that commit
67e306c6906137020267eb9bbdbc127034da3627 really still works, and
only 028abd9222df0cf5855dab5014a5ebaf06f90565 broke your setup?
So I manually checked out both 67e306c6906137020267eb9bbdbc127034da3627
and
On 23.03.21 17:57, Christoph Hellwig wrote:
On Tue, Mar 23, 2021 at 05:50:59PM +0100, Jan Engelhardt wrote:
Some participants in the discussion over at the debian-sparc list mentioned
"NFS" and "Invalid argument", which is something I know just too well from
iptables. NFS is a filesystem that
On Tue, Mar 23, 2021 at 05:50:59PM +0100, Jan Engelhardt wrote:
> Some participants in the discussion over at the debian-sparc list mentioned
> "NFS" and "Invalid argument", which is something I know just too well from
> iptables. NFS is a filesystem that uses an extra data blob (5th argument to
On Monday 2021-03-22 22:55, Frank Scheiner wrote:
>>> Riccardo Mottola first recognized a problem with 5.10.x kernels on his
>>> Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify
>>> the problem also on my Sun T1000 and it looks like this specific issue
>>> breaks the
Hi,
On 22.03.21 22:48, John Paul Adrian Glaubitz wrote:
On 3/22/21 10:30 PM, Frank Scheiner wrote:
Riccardo Mottola first recognized a problem with 5.10.x kernels on his
Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify
the problem also on my Sun T1000 and it looks like
Hello!
On 3/22/21 10:30 PM, Frank Scheiner wrote:
> Riccardo Mottola first recognized a problem with 5.10.x kernels on his
> Sun T2000 with UltraSPARC T1 (details in [this thread]). I could verify
> the problem also on my Sun T1000 and it looks like this specific issue
> breaks the mounting of
23 matches
Mail list logo
