Re: [PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args
On 18/05/2020 19:18, Al Viro wrote:
>> I hadn't looked into details (the branch itself is only two commits long,
>> but it
>> incorporates an openbios update - 35 commits there, some obviously pci- and
>> sun4u-related), but it's really easy to reproduce - -m 1024 and -hda
>> are probably the only relevant arguments. Even dd if=/dev/sda of=/dev/null
>> bs=64m
>> is often enough to hang it, so I rather doubt that networking (e1000 on pciB,
>> FWIW, with tap for backend) has anything to do with that.
>
> FWIW, virtio-blk-pci does appear to be much more resilent; I hadn't been
> able to reproduce hangs on that, while mounting identical fs from pata_cmd64x
> and doing the same aptitude dist-upgrade --download-only ended up with
>
> ...
> Note: Using 'Download Only' mode, no other actions will be performed.
> Do you want to continue? [Y/n/?] y
> Get: 1 http://ftp.ports.debian.org/debian-ports sid/main sparc64
> perl-modules-5.30 all 5.30.2-1 [2,806 kB]
> Get: 2 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libperl5.30
> sparc64 5.30.2-1 [3,388 kB]
> Get: 3 http://ftp.ports.debian.org/debian-ports sid/main sparc64 perl sparc64
> 5.30.2-1 [290 kB]
> Get: 4 http://ftp.ports.debian.org/debian-ports sid/main sparc64 perl-base
> sparc64 5.30.2-1 [1,427 kB]
> Get: 5 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libsystemd0
> sparc64 245.5-3 [309 kB]
> Get: 6 http://ftp.ports.debian.org/debian-ports sid/main sparc64 udev sparc64
> 245.5-3 [1,356 kB]
> Get: 7 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libudev1
> sparc64 245.5-3 [153 kB]
> [ 1472.613660] ata2: lost interrupt (Status 0x58)
> [ 1472.615124] ata1: lost interrupt (Status 0x50)
> [ 1472.615812] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 1472.616515] ata1.00: failed command: WRITE DMA
> [ 1472.617145] ata1.00: cmd ca/00:60:0c:9b:23/00:00:00:00:00/e0 tag 0 dma
> 49152 out
> [ 1472.617145] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4
> (timeout)
> [ 1472.618229] ata1.00: status: { DRDY }
> [ 1472.618743] ata1: soft resetting link
> [ 1472.779489] ata1.00: configured for UDMA/33
> [ 1472.781211] ata1: EH complete
> [ 1477.977424] ata2.00: qc timeout (cmd 0xa0)
> [ 1477.977897] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 1483.353324] ata2.00: qc timeout (cmd 0xa0)
> [ 1483.353697] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 1483.354453] ata2.00: limiting speed to UDMA/33:PIO3
> [ 1488.729323] ata2.00: qc timeout (cmd 0xa0)
> [ 1488.730255] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 1488.731320] ata2.00: disabled
> [ 1503.88] ata1: lost interrupt (Status 0x50)
(lots cut)
Well it certainly looks like there's an IRQ going missing somewhere, but glad
to hear
the virtio-blk-pci is working much better for you. Presumably the
virtio-net-pci NIC
also works?
> ... at which point I killed the damn thing. Unpingable, doesn't react to
> serial
> console (the output is obviously there, the input doesn't reach shell, at the
> very least). That was on current debian kernel (5.6.0-based), but the
> mainline
> 5.7-rc1 behaves the same way. qemu is (yesterday) mainline:
>
> commit debe78ce14bf8f8940c2bdf3ef387505e9e035a9 (HEAD -> master,
> origin/master, origin/HEAD)
> Merge: 66706192de 9ecaf5ccec
> Author: Peter Maydell
> Date: Fri May 15 19:51:16 2020 +0100
>
> Merge remote-tracking branch 'remotes/rth/tags/pull-fpu-20200515' into
> staging
>
> and anything since bcf9e2c2f2 exhibits that behaviour. qemu arguments:
> ../qemu1/build/sparc64-softmmu/qemu-system-sparc64 \
> -hda sid.img \
> -drive id=hd,if=none,file=foo.raw,format=raw \
> -device virtio-blk-pci,bus=pciB,drive=hd \
> -netdev tap,ifname=tap4,script=no,downscript=no,id=net \
> -device e1000,bus=pciB,netdev=net \
> -nographic -m 1024
> foo.raw and sid.img have the same contents (sid.img is qcow2 - might or might
> not
> cause enough timing differences to trigger whatever's happening).
>
> Looks like something got screwed in PCI interrupt routing in that sun4u
> branch back in
> 2017. If you have any suggestions on debugging that, I'd be glad to help;
> I'm not
> familiar with openbios guts, though ;-/
I've had one other report of a cmd646 hang on Linux several years ago and that
was on
some pretty high end hardware; however when tracing was enabled everything
worked as
it should. Despite my best attempts I can't seem to reproduce it here on my
normal i7
laptop which is quite frustrating.
Before bcf9e2c2f2 the on-board NIC (sunhme) and cmd646 were wired to sabre's
PCI IRQ
lines directly onto a single PCI bus, and after that commit they were rewired
via
simba PCI bridges to legacy OBIO IRQs since some OSs like NetBSD hard-coded the
legacy IRQ numbers for on-board devices. I'm not sure whether this is relevant
to the
kernel or not, or perhaps there is some magic register somewhere missing from
emulation that
Re: [PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args
On Mon, May 18, 2020 at 07:18:25PM +0100, Al Viro wrote:
> On Sun, May 17, 2020 at 11:13:47PM +0100, Al Viro wrote:
>
> > Is virtio-blk-pci more resilent to lost interrupt bug introduced in
> > "sun4u: update PCI topology to include simba PCI bridges"? I hadn't tried
> > it yet (reverted to the last working mainline qemu commit for now); IDE
> > definitely is screwed by that - both the Linux and NetBSD drivers, actually.
> >
> > A 50Mb worth of wget(1) is more than enough to trigger that crap;
> >
> > commit 063833a6ec
> > Merge: d634fc0499 bcf9e2c2f2
> > Author: Peter Maydell
> > Date: Thu Oct 19 18:42:51 2017 +0100
> >
> > Merge remote-tracking branch 'remotes/mcayland/tags/qemu-sparc-signed'
> > into staging
> >
> > hangs, d634fc0499 works, bcf9e2c2f2 hangs.
> >
> > I hadn't looked into details (the branch itself is only two commits long,
> > but it
> > incorporates an openbios update - 35 commits there, some obviously pci- and
> > sun4u-related), but it's really easy to reproduce - -m 1024 and -hda
> > are probably the only relevant arguments. Even dd if=/dev/sda of=/dev/null
> > bs=64m
> > is often enough to hang it, so I rather doubt that networking (e1000 on
> > pciB,
> > FWIW, with tap for backend) has anything to do with that.
>
> FWIW, virtio-blk-pci does appear to be much more resilent; I hadn't been
> able to reproduce hangs on that, while mounting identical fs from pata_cmd64x
> and doing the same aptitude dist-upgrade --download-only ended up with
>
> ...
> Note: Using 'Download Only' mode, no other actions will be performed.
> Do you want to continue? [Y/n/?] y
> Get: 1 http://ftp.ports.debian.org/debian-ports sid/main sparc64
> perl-modules-5.30 all 5.30.2-1 [2,806 kB]
> Get: 2 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libperl5.30
> sparc64 5.30.2-1 [3,388 kB]
> Get: 3 http://ftp.ports.debian.org/debian-ports sid/main sparc64 perl sparc64
> 5.30.2-1 [290 kB]
> Get: 4 http://ftp.ports.debian.org/debian-ports sid/main sparc64 perl-base
> sparc64 5.30.2-1 [1,427 kB]
> Get: 5 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libsystemd0
> sparc64 245.5-3 [309 kB]
> Get: 6 http://ftp.ports.debian.org/debian-ports sid/main sparc64 udev sparc64
> 245.5-3 [1,356 kB]
> Get: 7 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libudev1
> sparc64 245.5-3 [153 kB]
> [ 1472.613660] ata2: lost interrupt (Status 0x58)
> [ 1472.615124] ata1: lost interrupt (Status 0x50)
> [ 1472.615812] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 1472.616515] ata1.00: failed command: WRITE DMA
> [ 1472.617145] ata1.00: cmd ca/00:60:0c:9b:23/00:00:00:00:00/e0 tag 0 dma
> 49152 out
> [ 1472.617145] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4
> (timeout)
> [ 1472.618229] ata1.00: status: { DRDY }
> [ 1472.618743] ata1: soft resetting link
> [ 1472.779489] ata1.00: configured for UDMA/33
> [ 1472.781211] ata1: EH complete
> [ 1477.977424] ata2.00: qc timeout (cmd 0xa0)
> [ 1477.977897] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 1483.353324] ata2.00: qc timeout (cmd 0xa0)
> [ 1483.353697] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 1483.354453] ata2.00: limiting speed to UDMA/33:PIO3
> [ 1488.729323] ata2.00: qc timeout (cmd 0xa0)
> [ 1488.730255] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [ 1488.731320] ata2.00: disabled
> [ 1503.88] ata1: lost interrupt (Status 0x50)
> [ 1503.333838] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 1503.334309] ata1.00: failed command: WRITE DMA EXT
> [ 1503.334647] ata1.00: cmd 35/00:30:0c:7b:23/00:01:00:00:00/e0 tag 0 dma
> 155648 out
> [ 1503.334647] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4
> (timeout)
> [ 1503.335494] ata1.00: status: { DRDY }
> [ 1503.335858] ata1: soft resetting link
> [ 1503.494764] ata1.00: configured for UDMA/33
> [ 1503.495313] ata1: EH complete
> [ 1534.041532] ata1: lost interrupt (Status 0x50)
> [ 1534.042043] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 1534.042627] ata1.00: failed command: WRITE DMA
> [ 1534.042969] ata1.00: cmd ca/00:60:0c:9b:23/00:00:00:00:00/e0 tag 0 dma
> 49152 out
> [ 1534.042969] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4
> (timeout)
> [ 1534.043902] ata1.00: status: { DRDY }
> [ 1534.044306] ata1: soft resetting link
> [ 1534.202625] ata1.00: configured for UDMA/33
> [ 1534.203119] ata1: EH complete
> [ 1564.761561] ata1: lost interrupt (Status 0x50)
> [ 1564.762351] ata1.00: limiting speed to UDMA/25:PIO4
> [ 1564.762831] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
> frozen
> [ 1564.763388] ata1.00: failed command: WRITE DMA EXT
> [ 1564.763790] ata1.00: cmd 35/00:30:0c:7b:23/00:01:00:00:00/e0 tag 0 dma
> 155648 out
> [ 1564.763790] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4
> (timeout)
> [ 1564.764784] ata1.00: status: { DRDY }
> [ 1564.765470] ata1: soft resetting link
> [
Re: [PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args
On Sun, May 17, 2020 at 11:13:47PM +0100, Al Viro wrote:
> Is virtio-blk-pci more resilent to lost interrupt bug introduced in
> "sun4u: update PCI topology to include simba PCI bridges"? I hadn't tried
> it yet (reverted to the last working mainline qemu commit for now); IDE
> definitely is screwed by that - both the Linux and NetBSD drivers, actually.
>
> A 50Mb worth of wget(1) is more than enough to trigger that crap;
>
> commit 063833a6ec
> Merge: d634fc0499 bcf9e2c2f2
> Author: Peter Maydell
> Date: Thu Oct 19 18:42:51 2017 +0100
>
> Merge remote-tracking branch 'remotes/mcayland/tags/qemu-sparc-signed'
> into staging
>
> hangs, d634fc0499 works, bcf9e2c2f2 hangs.
>
> I hadn't looked into details (the branch itself is only two commits long, but
> it
> incorporates an openbios update - 35 commits there, some obviously pci- and
> sun4u-related), but it's really easy to reproduce - -m 1024 and -hda
> are probably the only relevant arguments. Even dd if=/dev/sda of=/dev/null
> bs=64m
> is often enough to hang it, so I rather doubt that networking (e1000 on pciB,
> FWIW, with tap for backend) has anything to do with that.
FWIW, virtio-blk-pci does appear to be much more resilent; I hadn't been
able to reproduce hangs on that, while mounting identical fs from pata_cmd64x
and doing the same aptitude dist-upgrade --download-only ended up with
...
Note: Using 'Download Only' mode, no other actions will be performed.
Do you want to continue? [Y/n/?] y
Get: 1 http://ftp.ports.debian.org/debian-ports sid/main sparc64
perl-modules-5.30 all 5.30.2-1 [2,806 kB]
Get: 2 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libperl5.30
sparc64 5.30.2-1 [3,388 kB]
Get: 3 http://ftp.ports.debian.org/debian-ports sid/main sparc64 perl sparc64
5.30.2-1 [290 kB]
Get: 4 http://ftp.ports.debian.org/debian-ports sid/main sparc64 perl-base
sparc64 5.30.2-1 [1,427 kB]
Get: 5 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libsystemd0
sparc64 245.5-3 [309 kB]
Get: 6 http://ftp.ports.debian.org/debian-ports sid/main sparc64 udev sparc64
245.5-3 [1,356 kB]
Get: 7 http://ftp.ports.debian.org/debian-ports sid/main sparc64 libudev1
sparc64 245.5-3 [153 kB]
[ 1472.613660] ata2: lost interrupt (Status 0x58)
[ 1472.615124] ata1: lost interrupt (Status 0x50)
[ 1472.615812] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 1472.616515] ata1.00: failed command: WRITE DMA
[ 1472.617145] ata1.00: cmd ca/00:60:0c:9b:23/00:00:00:00:00/e0 tag 0 dma 49152
out
[ 1472.617145] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4
(timeout)
[ 1472.618229] ata1.00: status: { DRDY }
[ 1472.618743] ata1: soft resetting link
[ 1472.779489] ata1.00: configured for UDMA/33
[ 1472.781211] ata1: EH complete
[ 1477.977424] ata2.00: qc timeout (cmd 0xa0)
[ 1477.977897] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 1483.353324] ata2.00: qc timeout (cmd 0xa0)
[ 1483.353697] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 1483.354453] ata2.00: limiting speed to UDMA/33:PIO3
[ 1488.729323] ata2.00: qc timeout (cmd 0xa0)
[ 1488.730255] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 1488.731320] ata2.00: disabled
[ 1503.88] ata1: lost interrupt (Status 0x50)
[ 1503.333838] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 1503.334309] ata1.00: failed command: WRITE DMA EXT
[ 1503.334647] ata1.00: cmd 35/00:30:0c:7b:23/00:01:00:00:00/e0 tag 0 dma
155648 out
[ 1503.334647] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4
(timeout)
[ 1503.335494] ata1.00: status: { DRDY }
[ 1503.335858] ata1: soft resetting link
[ 1503.494764] ata1.00: configured for UDMA/33
[ 1503.495313] ata1: EH complete
[ 1534.041532] ata1: lost interrupt (Status 0x50)
[ 1534.042043] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 1534.042627] ata1.00: failed command: WRITE DMA
[ 1534.042969] ata1.00: cmd ca/00:60:0c:9b:23/00:00:00:00:00/e0 tag 0 dma 49152
out
[ 1534.042969] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4
(timeout)
[ 1534.043902] ata1.00: status: { DRDY }
[ 1534.044306] ata1: soft resetting link
[ 1534.202625] ata1.00: configured for UDMA/33
[ 1534.203119] ata1: EH complete
[ 1564.761561] ata1: lost interrupt (Status 0x50)
[ 1564.762351] ata1.00: limiting speed to UDMA/25:PIO4
[ 1564.762831] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 1564.763388] ata1.00: failed command: WRITE DMA EXT
[ 1564.763790] ata1.00: cmd 35/00:30:0c:7b:23/00:01:00:00:00/e0 tag 0 dma
155648 out
[ 1564.763790] res 40/00:01:00:00:00/00:00:00:00:00/a0 Emask 0x4
(timeout)
[ 1564.764784] ata1.00: status: { DRDY }
[ 1564.765470] ata1: soft resetting link
[ 1564.926509] ata1.00: configured for UDMA/25
[ 1564.927516] ata1: EH complete
[ 1575.001438] INFO: task jbd2/sda2-8:143 blocked for more than 120 seconds.
[ 1575.002273] Tainted: GE 5.6.0-1-sparc64 #1 Debian
5.6.7-1
[ 1575.002755] "echo 0 >
Re: [PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args
On Sun, May 17, 2020 at 05:34:34PM +0100, Mark Cave-Ayland wrote: > FWIW if you're running a more recent version of QEMU (>=3.1) then you can > also boot > from the virtio-blk-pci device directly instead of having to switch back to > the IDE > device after installation as you have done above. Should be something like: > > qemu-system-sparc64 \ > -m 4096 \ > -device virtio-blk-pci,bus=pciB,drive=hd \ > -drive > file=/home/brauner/.local/share/qemu/sparc64.img,format=raw,if=none,id=hd,bootindex=0 > \ > -net nic \ > -net user \ > -nographic > > Note the removal of the legacy -boot argument and the addition of > "bootindex=0" to > the -drive argument. Is virtio-blk-pci more resilent to lost interrupt bug introduced in "sun4u: update PCI topology to include simba PCI bridges"? I hadn't tried it yet (reverted to the last working mainline qemu commit for now); IDE definitely is screwed by that - both the Linux and NetBSD drivers, actually. A 50Mb worth of wget(1) is more than enough to trigger that crap; commit 063833a6ec Merge: d634fc0499 bcf9e2c2f2 Author: Peter Maydell Date: Thu Oct 19 18:42:51 2017 +0100 Merge remote-tracking branch 'remotes/mcayland/tags/qemu-sparc-signed' into staging hangs, d634fc0499 works, bcf9e2c2f2 hangs. I hadn't looked into details (the branch itself is only two commits long, but it incorporates an openbios update - 35 commits there, some obviously pci- and sun4u-related), but it's really easy to reproduce - -m 1024 and -hda are probably the only relevant arguments. Even dd if=/dev/sda of=/dev/null bs=64m is often enough to hang it, so I rather doubt that networking (e1000 on pciB, FWIW, with tap for backend) has anything to do with that.
Re: [PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args
On 17/05/2020 16:01, Christian Brauner wrote: > On Tue, May 12, 2020 at 01:06:33PM -0700, David Miller wrote: >> From: Christian Brauner >> Date: Tue, 12 May 2020 19:15:24 +0200 >> >>> I've tested this series with qemu-system-sparc64 and a Debian Sid image >>> and it comes up no problem (Here's a little recording >>> https://asciinema.org/a/329510 ). >> >> Can you show how you put this environment together and also what >> compilation tools you used? Looks great. > > Sorry for the delay. That mail somehow got lost in my inbox. > > So in general, I used qemu-system-sparc64 which is available in Universe > with either Debian or Ubuntu and that's what I've been using as host > distro. So you need a > > deb http://us.archive.ubuntu.com/ubuntu/ universe > deb-src http://us.archive.ubuntu.com/ubuntu/ universe > deb http://us.archive.ubuntu.com/ubuntu/ -updates universe > deb-src http://us.archive.ubuntu.com/ubuntu/ -updates universe > > int /etc/apt/sources.list > > So after this, you should be able to install > > apt install qemu-system-sparc > > Now we need an image and believe it or not there's a guy who lives in > Berlin too who builds Debian images for all crazy architectures. You can > download them from: > > https://cdimage.debian.org/cdimage/ports/ > > They're built quite frequently. Sometimes you get unlucky because a new > kernel won't boot anymore then going a couple of months back usually > helps. So for this experiment I downloaded: > > https://cdimage.debian.org/cdimage/ports/9.0/sparc64/iso-cd/debian-9.0-sparc64-NETINST-1.iso > > then I did: > > cd .local/share/qemu > truncate -s 15GB sparc64.img > > And then to _install_: > > qemu-system-sparc64 \ > -m 4096 \ > -device virtio-blk-pci,bus=pciB,drive=hd \ > -drive > file=/home/brauner/Downloads/debian-9.0-sparc64-NETINST-1.iso,format=raw,if=ide,bus=1,unit=0,media=cdrom,readonly=on > \ > -drive > file=/home/brauner/.local/share/qemu/sparc64.img,format=raw,if=none,id=hd \ > -boot order=d \ > -net nic \ > -net user \ > -nographic \ > > Then the Debian install will run after it finishes you can boot with: > > qemu-system-sparc64 \ > -name debian-unstable-sparc64 -machine sun4u,accel=tcg,usb=off -m 4096 \ > -smp 1,sockets=1,cores=1,threads=1 \ > -uuid ccd8b5c2-b8e4-4d5e-af19-9322cd8e55bf -rtc base=utc -no-reboot > -no-shutdown \ > -boot strict=on \ > -drive > file=/home/brauner/.local/share/qemu/sparc64.img,if=none,id=drive-ide0-0-1,format=raw,cache=none,aio=native > \ > -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-1,id=ide0-0-1 \ > -msg timestamp=on -nographic > > If the install isn't setting up the repos right and you can't install > stuff the correct url is: > http://ftp.ports.debian.org/debian-ports/ > to put into sources.list FWIW if you're running a more recent version of QEMU (>=3.1) then you can also boot from the virtio-blk-pci device directly instead of having to switch back to the IDE device after installation as you have done above. Should be something like: qemu-system-sparc64 \ -m 4096 \ -device virtio-blk-pci,bus=pciB,drive=hd \ -drive file=/home/brauner/.local/share/qemu/sparc64.img,format=raw,if=none,id=hd,bootindex=0 \ -net nic \ -net user \ -nographic Note the removal of the legacy -boot argument and the addition of "bootindex=0" to the -drive argument. ATB, Mark.
Re: [PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args
On Tue, May 12, 2020 at 01:06:33PM -0700, David Miller wrote: > From: Christian Brauner > Date: Tue, 12 May 2020 19:15:24 +0200 > > > I've tested this series with qemu-system-sparc64 and a Debian Sid image > > and it comes up no problem (Here's a little recording > > https://asciinema.org/a/329510 ). > > Can you show how you put this environment together and also what > compilation tools you used? Looks great. Sorry for the delay. That mail somehow got lost in my inbox. So in general, I used qemu-system-sparc64 which is available in Universe with either Debian or Ubuntu and that's what I've been using as host distro. So you need a deb http://us.archive.ubuntu.com/ubuntu/ universe deb-src http://us.archive.ubuntu.com/ubuntu/ universe deb http://us.archive.ubuntu.com/ubuntu/ -updates universe deb-src http://us.archive.ubuntu.com/ubuntu/ -updates universe int /etc/apt/sources.list So after this, you should be able to install apt install qemu-system-sparc Now we need an image and believe it or not there's a guy who lives in Berlin too who builds Debian images for all crazy architectures. You can download them from: https://cdimage.debian.org/cdimage/ports/ They're built quite frequently. Sometimes you get unlucky because a new kernel won't boot anymore then going a couple of months back usually helps. So for this experiment I downloaded: https://cdimage.debian.org/cdimage/ports/9.0/sparc64/iso-cd/debian-9.0-sparc64-NETINST-1.iso then I did: cd .local/share/qemu truncate -s 15GB sparc64.img And then to _install_: qemu-system-sparc64 \ -m 4096 \ -device virtio-blk-pci,bus=pciB,drive=hd \ -drive file=/home/brauner/Downloads/debian-9.0-sparc64-NETINST-1.iso,format=raw,if=ide,bus=1,unit=0,media=cdrom,readonly=on \ -drive file=/home/brauner/.local/share/qemu/sparc64.img,format=raw,if=none,id=hd \ -boot order=d \ -net nic \ -net user \ -nographic \ Then the Debian install will run after it finishes you can boot with: qemu-system-sparc64 \ -name debian-unstable-sparc64 -machine sun4u,accel=tcg,usb=off -m 4096 \ -smp 1,sockets=1,cores=1,threads=1 \ -uuid ccd8b5c2-b8e4-4d5e-af19-9322cd8e55bf -rtc base=utc -no-reboot -no-shutdown \ -boot strict=on \ -drive file=/home/brauner/.local/share/qemu/sparc64.img,if=none,id=drive-ide0-0-1,format=raw,cache=none,aio=native \ -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-1,id=ide0-0-1 \ -msg timestamp=on -nographic If the install isn't setting up the repos right and you can't install stuff the correct url is: http://ftp.ports.debian.org/debian-ports/ to put into sources.list > > > This is the sparc specific bit and _if_ you agree with the changes here > > it'd be nice if I could get your review, and if technically correct, > > your ack so I can fold this into a larger series and move on to the next > > arch. > > With the delay slot instruction indentation fixed: > > Acked-by: David S. Miller Thank you, Dave! Christian
Re: [PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args
From: Christian Brauner Date: Tue, 12 May 2020 19:15:24 +0200 > I've tested this series with qemu-system-sparc64 and a Debian Sid image > and it comes up no problem (Here's a little recording > https://asciinema.org/a/329510 ). Can you show how you put this environment together and also what compilation tools you used? Looks great. > This is the sparc specific bit and _if_ you agree with the changes here > it'd be nice if I could get your review, and if technically correct, > your ack so I can fold this into a larger series and move on to the next > arch. With the delay slot instruction indentation fixed: Acked-by: David S. Miller Thank you.
[PATCH 0/3] sparc: port to copy_thread_tls() and struct kernel_clone_args
Hey Dave,
I've tested this series with qemu-system-sparc64 and a Debian Sid image
and it comes up no problem (Here's a little recording
https://asciinema.org/a/329510 ). Process creation works fine for
fork(), vfork(), and clone() afaict. For sparc 32bit I tried my best,
but couldn't get my hands on either a compiler or a useable distro image
for pure sparc32. The changes should be straightforward though but
anyone who can test I'd appreciate it.
This is more or less the explanation also present in the first patch:
This is part of ongoing work that aims at getting rid of the
copy_thread()/copy_thread_tls() split that makes the process creation
codepaths in the kernel more convoluted and error-prone than they need
to be.
This is the sparc specific bit and _if_ you agree with the changes here
it'd be nice if I could get your review, and if technically correct,
your ack so I can fold this into a larger series and move on to the next
arch.
It also unblocks implementing clone3() on architectures not support
copy_thread_tls(). Any architecture that wants to implement clone3()
will need to select HAVE_COPY_THREAD_TLS and thus need to implement
copy_thread_tls(). So both goals are connected but independently
beneficial.
HAVE_COPY_THREAD_TLS means that a given architecture supports
CLONE_SETTLS and not setting it should usually mean that the
architectures doesn't implement it but that's not how things are. In
fact all architectures support CLONE_TLS it's just that they don't
follow the calling convention that HAVE_COPY_THREAD_TLS implies. That
means all architectures can be switched over to select
HAVE_COPY_THREAD_TLS. Once that is done we can remove that macro (yay,
less code), the unnecessary do_fork() export in kernel/fork.c, and also
rename copy_thread_tls() back to copy_thread(). At this point
copy_thread() becomes the main architecture specific part of process
creation but it will be the same layout and calling convention for all
architectures. (Once that is done we can probably cleanup each
copy_thread() function even more but that's for the future.)
Since sparc does support CLONE_SETTLS there's no reason to not select
HAVE_COPY_THREAD_TLS. This brings us one step closer to getting rid of
the copy_thread()/copy_thread_tls() split we still have and ultimately
the HAVE_COPY_THREAD_TLS define in general. A lot of architectures have
already converted and sparc is one of the few hat haven't yet. This also
unblocks implementing the clone3() syscall on sparc which I will follow
up later (if no one gets there before me). Once that is done we can get
of another ARCH_WANTS_* macro.
This patch just switches sparc64 over to HAVE_COPY_THREAD_TLS but not
sparc32 which will be done in the next patch. Once Any architecture that
supports HAVE_COPY_THREAD_TLS cannot call the do_fork() helper anymore.
This is fine and intended since it should be removed in favor of the
new, cleaner _do_fork() calling convention based on struct
kernel_clone_args. In fact, most architectures have already switched.
With this patch, sparc joins the other arches which can't use the
fork(), vfork(), clone(), clone3() syscalls directly and who follow the
new process creation calling convention that is based on struct
kernel_clone_args which we introduced a while back. This means less
custom assembly in the architectures entry path to set up the registers
before calling into the process creation helper and it is easier to to
support new features without having to adapt calling conventions. It
also unifies all process creation paths between fork(), vfork(),
clone(), and clone3(). (We can't fix the ABI nightmare that legacy
clone() is but we can prevent stuff like this happening in the future.)
Note that sparc can't easily call into the syscalls directly because of
its return value conventions when a new process is created which
needs to clobber the UREG_I1 register in copy_thread{_tls()} and it
needs to restore it if process creation fails. That's not a big deal
since the new process creation calling convention makes things simpler.
This removes sparc_do_fork() and replaces it with 3 clean helpers,
sparc_fork(), sparc_vfork(), and sparc_clone(). That means a little more
C code until the next patch unifies sparc 32bit and sparc64. It has the
advantage that we can remove quite a bit of assembler and it makes the
whole syscall.S process creation bits easier to read.
The follow-up patch will remove the custom sparc_do_fork() helper for
32bi sparc and move sparc_fork(), sparc_vfork(), and sparc_clone() into
a common process.c file. This allows us to remove quite a bit of
custom assembly form 32bit sparc's entry.S file too and allows to remove
even more code because now all helpers are shared between 32bit sparc
and sparc64 instead of having to maintain two separate sparc_do_fork()
implementations.
For some more context, please see:
commit 606e9ad20094f6d500166881d301f31a51bc8aa7
Merge: ac61145a725a 457677c70c76
Author: Linus Torvalds
Date:
