From: Frank Scheiner <frank.scheiner@web.de>
To: Christoph Hellwig <hch@lst.de>, Jan Engelhardt <jengelh@inai.de>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Sparc kernel list <sparclinux@vger.kernel.org>,
debian-sparc <debian-sparc@lists.debian.org>
Subject: Re: Regression in 028abd92 for Sun UltraSPARC T1
Date: Tue, 23 Mar 2021 18:39:36 +0100 [thread overview]
Message-ID: <4938f0fa-e63f-2a4b-e607-512e06987885@web.de> (raw)
In-Reply-To: <20210323165721.GA14577@lst.de>
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 uses an extra data blob (5th argument to the
>> mount syscall). Such blobs have historically not always been designed to bear
>> the same layout between ILP32 and LP64 modes, and nfs's structs fell prey to
>> this as well.
>>
>> My hypothesis now is that fs/nfs/fs_context.c line 1160:
>>
>> if (in_compat_syscall())
>> nfs4_compat_mount_data_conv(data);
>>
>> and ones similar to it (I didn't look too close where nfs3 gets to do its
>> conversion), no longer trigger as a result of compat_sys_mount being
>> wiped from the syscall table:
>
> No, if in_compat_syscall() syscall doesn't trigger properly the kernel
> would not get this far.
>
> That being said, the NFS compat code was moved out of the compat mount
> handler and into nfs and refactored in the commit just before this one.
>
> Frank, can you double check that commit
> 67e306c6906137020267eb9bbdbc127034da3627 really still works, and
> only 028abd9222df0cf5855dab5014a5ebaf06f90565 broke your setup?
Indeed, I also expected 67e306c6906137020267eb9bbdbc127034da3627 to fail
because of its commit message, but from my log it did work correctly.
As the T1000 is at home and I don't have another T1 based system in my
storage location where I am now, I'll double check that in the evening
and report back.
Strangely for a V245 (with UltraSPARC IIIi) both commits seem to work
according to my testing, but 5.10.x (from Debian) doesn't work and
5.9.15 (also from Debian) does work - tested now both for boot from
network and boot from disk.
Possibly unrelated to the problem with the T1000, the V245 emits the
following for boot from disk with 5.10.x:
```
[...]
Loading Linux 5.10.0-5-sparc64-smp ...
Loading initial ramdisk ...
[ 2.602821] rtc_cmos rtc_cmos: IRQ index 0 not found
/dev/sda2: clean, 33516/8454144 files, 1105784/33798750 blocks
[ 13.542728] autofs4:pid:1:autofs_fill_super: called with bogus options
[ 13.628931] systemd[1]: proc-sys-fs-binfmt_misc.automount: Failed to
initialize automounter: Invalid argument
[ 13.759917] systemd[1]: Failed to set up automount Arbitrary
Executable File Formats File System Automount Point.
[FAILED] Failed to set up automount File System Automount Point.
[ 14.456396] Unable to handle kernel paging request in mna handler
[ 14.456400] at virtual address da65f2fed110e482
[ 14.597474] current->{active_,}mm->context = 00000000000000ce
[ 14.597478] current->{active_,}mm->pgd = fff0000006d5c000
[ 14.752380] Unable to handle kernel paging request in mna handler
[ 14.752383] at virtual address da65f2fed110e482
[ 14.893509] current->{active_,}mm->context = 0000000000000094
[ 14.969141] current->{active_,}mm->pgd = fff00011010e0000
[ 15.040554] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
[ 15.141430] Press Stop-A (L1-A) from sun keyboard or send break
[ 15.141430] twice on console to return to the boot prom
[ 15.141459] kernel BUG at kernel/cpu.c:960
```
Cheers,
Frank
next prev parent reply other threads:[~2021-03-23 17:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 21:30 Regression in 028abd92 for Sun UltraSPARC T1 Frank Scheiner
2021-03-22 21:48 ` John Paul Adrian Glaubitz
2021-03-22 21:55 ` Frank Scheiner
2021-03-23 16:50 ` Jan Engelhardt
2021-03-23 16:57 ` Christoph Hellwig
2021-03-23 17:39 ` Frank Scheiner [this message]
2021-03-23 22:17 ` Frank Scheiner
2021-03-24 8:28 ` Christoph Hellwig
2021-03-24 12:30 ` Frank Scheiner
2021-03-24 12:42 ` Anatoly Pugachev
2021-03-24 12:48 ` Frank Scheiner
2021-03-24 12:49 ` John Paul Adrian Glaubitz
2021-03-24 13:09 ` Frank Scheiner
2021-03-24 13:16 ` John Paul Adrian Glaubitz
2021-03-24 13:19 ` Frank Scheiner
2021-03-24 13:24 ` Anatoly Pugachev
2021-03-24 13:29 ` Frank Scheiner
2021-03-24 13:57 ` Frank Scheiner
2021-03-24 15:22 ` Jan Engelhardt
2021-03-24 15:58 ` Frank Scheiner
2021-03-24 16:10 ` Christoph Hellwig
2021-03-24 16:33 ` Frank Scheiner
2021-03-24 16:37 ` Frank Scheiner
2021-03-25 7:50 ` Christoph Hellwig
2025-09-02 20:18 ` John Paul Adrian Glaubitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4938f0fa-e63f-2a4b-e607-512e06987885@web.de \
--to=frank.scheiner@web.de \
--cc=debian-sparc@lists.debian.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=hch@lst.de \
--cc=jengelh@inai.de \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).