Re: [RFC PATCH 0/13] sparc32: sunset sun4m and sun4d
On 18/12/2020, Sam Ravnborg wrote: > The sun4m and sun4d based SPARC machines was very popular in the > 90'ties and was then replaced by the more powerful sparc64 > class of machines. > Today there is only Gentoo that to my best knowledge supports > sparc32 and people have moved on to more capable HW. > > Cobham Gaisler have variants of the LEON processer that > runs sparc32 - and they are in production today. > > With this patchset I propose to sunset sun4m and sun4d and move > focus to a more streamlined support for LEON. > > One downside is that qemu supports sun4m - and we may loose > some testing possibilities when sun4m is dropped. qemu supports > LEON to some degree - I have not yet tried it out. > > Andreas from Gaisler have indicated that they may be more active > upstream on sparc32 - and this will only be easier with a kernel > where the legacy stuff is dropped. > This makes me a bit sad. But I guess I haven't had any time to put into the sparc32 port for many years, so I guess it is time to let go. But I do believe that by doing this we should make sure we are not putting ourselves in a position where the sparc kernel-developers don't have access to any real sparc32 hardware. SUN machines were at least plentiful. The LEON-family of processors being targeted towards the rad-hardened market are not so much available. Maybe Gaisler can contribute some systems, or make some available remotely? Best regards, Kjetil Oftedal
Re: Debian drops support for sparc
On 30/07/2015, David Miller da...@davemloft.net wrote: From: Josip Rodin j...@entuzijast.net Date: Thu, 30 Jul 2015 21:22:30 +0200 On Thu, Jul 30, 2015 at 06:48:24PM +0200, Sam Ravnborg wrote: But I think the focus should probably be on the sheer redness of the sparc columns at: https://release.debian.org/jessie/arch_qualify.html (current release) From the link above: sparc Upstream Support According to the gcc maintainer 32bit code generation as we use it is no longer supported upstream and we should aim for a switch to 64bit userland anytime soon. Is it correct that 32bit gcc is no longer maintained? I have seen nothing on gcc mailaing list about this. That's from jessie, which was already released. The said note has been removed from the list for stretch. The thing is, it makes no sense to go to a 64-bit only userland distribition. What does make sense is maybe only supporting sparc64 kernels, but with a userland that is built 32-bit targetting v8plus. The problem is that numerous other issues - haven't. It would be nice to narrow things down to the real issues. The only major blocker I know of is the kernel FPU issue, which is what I'm spending all of my sparc cycles on. -- To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, As far as I remember Debian dropped Sparc32 support quite a few years ago. So I guess what is being dropped this time around is the official support for 64-bit kernel + 32-bit/v8plus userland. Then only the unofficial port of 64-bit kernel + 64-bit userland remains. Regards, Kjetil Oftedal -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CALMQjD-REfcWX=ie11uwjarkpme3qbn5l+etea0ibql2w0s...@mail.gmail.com
Re: Warning when mounting btrfs partition, kernel unaligned access
On Wed, 13 Apr 2011, Sébastien Bernard wrote:
I played a little with btrfs on debian sparc64 (V240).
I created a LV from my volumegroup and mounted it.
At this moment I got a warning from the kernel as follow:
[ 624.857466] device fsid 5defc44f31f449af-b797a325301d119a devid 1 transid
502 /dev/mapper/vgsys-debian64
[ 624.983823] [ cut here ]
[ 625.044657] WARNING: at
/build/buildd-linux-2.6_2.6.38-3-sparc-675DHN/linux-2.6-2.6.38/debian/build/source_sparc_none/fs/btrfs/extent_io.c:3787
write_extent_buffer+0xc8/0x128 [btrfs]()
[ 625.260939] Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl
auth_rpcgss sunrpc ext2 loop flash ext4 mbcache jbd2 crc16 dm_mod raid1 md_mod
btrfs lzo_compress zlib_deflate crc32c libcrc32c ide_cd_mod cdrom ata_generic
libata ide_pci_generic sd_mod crc_t10dif qla1280 ohci_hcd ehci_hcd tg3
sym53c8xx scsi_transport_spi scsi_mod usbcore libphy alim15x3 nls_base [last
unloaded: scsi_wait_scan]
[ 625.725351] Call Trace:
[ 625.757411] [103f5cbc] write_extent_buffer+0xc8/0x128 [btrfs]
[ 625.843302] [103fd7b4] btrfs_read_sys_array+0x3c/0x314 [btrfs]
[ 625.930333] [103c65e0] open_ctree+0xf28/0x1884 [btrfs]
[ 626.008199] [1039d01c] btrfs_mount+0x238/0x43c [btrfs]
[ 626.086068] [00514db8] vfs_kern_mount+0x98/0x1fc
[ 626.157071] [00514f5c] do_kern_mount+0x24/0xbc
[ 626.225696] [0052d718] do_mount+0x830/0x898
[ 626.290889] [0054ed68] compat_sys_mount+0x1c8/0x204
[ 626.365229] [00406114] linux_sparc_syscall32+0x34/0x40
[ 626.442999] ---[ end trace 1a1c133a476942b9 ]---
Then, after writing on the disk, I got a lot of warning:
[ 822.515875] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 825.897439] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 826.030575] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 826.565416] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 826.692390] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 841.631005] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 841.736359] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 846.774635] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 846.880038] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 847.018567] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 847.157098] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 847.262536] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 851.884641] log_unaligned: 127 callbacks suppressed
[ 851.948889] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 852.054307] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 852.227997] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
[ 852.333491] Kernel unaligned access at TPC[103c2204]
btrfs_csum_final+0x38/0x3c [btrfs]
I peeked a look at the btrf_csum_final and here's the function :
void btrfs_csum_final(u32 crc, char *result)
{
*(__le32 *)result = ~cpu_to_le32(crc);
}
I know that this problem is certainly an alignment problem and that the sparc
is prone to that kind of problem.
If someone could explain what's wrong with it?
S. Bernard
--
On SPARC memory alignment is required. I.e. bytes can be written to any
address. 32 bit words on the other hand must be written to an address on
a 4 byte boundary, 64 bit words on 8 byte boundaries and so on.
The problem with the csum function is that it casts the result byte pointer
to a 32 bits pointer. This pointer might not point to an aligned memory
position for 32 bits operations.
Either the function must handle unaligned result pointers internally, or
you must guarantee that the result pointer is always aligned. Which would
increase performance slightly on most architectures, as those architectures
that allow unaligned memory accesses often do it at a cost in memory access
time.
Kjetil Oftedal
