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.
