Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

2023-01-14 Thread Matthew Wilcox 
On Sat, Jan 14, 2023 at 12:28:30PM +0100, Sedat Dilek wrote:
> [ ... ]
> 
> > Best is to ask the Debian release-team or (if there exist) maintainers
> > or responsibles for the IA64 port - which is an ***unofficial*** port.
> >
> 
> Here we go:
> 
> https://lists.debian.org/debian-ia64/
> 
> Posting address: debian-i...@lists.debian.org
> 
> Found via 

More useful perhaps is to look at https://popcon.debian.org/

There are three machines reporting popcon results.  It's dead.

Re: [PATCH v2 1/2] powerpc/ps3: Change updateboltedpp panic to info

2023-01-14 Thread Geoff Levand 
Hi Christophe,

On 1/9/23 09:41, Christophe Leroy wrote:
> 
> 
> Le 03/01/2023 à 18:51, Geoff Levand a écrit :
>> Commit fdacae8a84024474afff234bdd1dbe19ad597a10 (powerpc: Activate
>> CONFIG_STRICT_KERNEL_RWX by default) causes ps3_hpte_updateboltedpp()
>> to be called.  Change the panic statment in ps3_hpte_updateboltedpp()
>> to a pr_info statement so that bootup can continue.
> 
> But if I understand correctly, it means that CONFIG_STRICT_KERNEL_RWX 
> won't work then.
> 
> So, shouldn't we keep the panic and forbid CONFIG_STRICT_KERNEL_RWX on PS3 ?

mmu_hash_ops.updateboltedpp returns void, so I can't return an error code to
indicate the feature is not supported.

I could do something like this in arch/powerpc/Kconfig:

-   select ARCH_HAS_STRICT_KERNEL_RWX   if (PPC_BOOK3S || PPC_8xx || 
40x) && !HIBERNATION
+   select ARCH_HAS_STRICT_KERNEL_RWX   if (PPC_BOOK3S || PPC_8xx || 
40x) && !PPC_PS3 && !HIBERNATION

But then the ppc64_defconfig would be built without STRICT_KERNEL_RWX.

I could do this in ps3_defconfig:

+# CONFIG_STRICT_KERNEL_RWX is not set
+# CONFIG_STRICT_MODULE_RWX is not set

But I don't like that way because it seems too easy for users to not add those
into a custom kernel config, and then they need to figure out what to do after
their kernel panics on startup.

What other 'clean' way is there?

-Geoff

Re: [PATCH mm-unstable v1 01/26] mm/debug_vm_pgtable: more pte_swp_exclusive() sanity checks

2023-01-14 Thread David Hildenbrand 

On 13.01.23 18:10, David Hildenbrand wrote:

We want to implement __HAVE_ARCH_PTE_SWP_EXCLUSIVE on all architectures.
Let's extend our sanity checks, especially testing that our PTE bit
does not affect:
* is_swap_pte() -> pte_present() and pte_none()
* the swap entry + type
* pte_swp_soft_dirty()

Especially, the pfn_pte() is dodgy when the swap PTE layout differs
heavily from ordinary PTEs. Let's properly construct a swap PTE from
swap type+offset.

Signed-off-by: David Hildenbrand 
---


The following fixup for !CONFIG_SWAP on top, which makes it compile for me and
passes when booting on x86_64 with CONFIG_DEBUG_VM_PGTABLE:

...
[0.347112] Loaded X.509 cert 'Build time autogenerated kernel key: 
ee6afc0578f6475656fec8a4f9d02832'
[0.350112] debug_vm_pgtable: [debug_vm_pgtable ]: Validating 
architecture page table helpers
[0.351217] page_owner is disabled
...


From 6a6162e8af62a4b3f7b9d823fdfae86de3f34a9d Mon Sep 17 00:00:00 2001
From: David Hildenbrand 
Date: Sat, 14 Jan 2023 16:47:12 +0100
Subject: [PATCH] fixup: mm/debug_vm_pgtable: more pte_swp_exclusive() sanity
 checks

generic_max_swapfile_size() is only available with CONFIG_SWAP -- which
makes sense, because without SWAP there are no swap files. Let's
simply probe manually which bits we can obtain after storing them in a
PTE, and properly call it "max swap offset", which is more generic for
a swap entry.

Reported-by: kernel test robot 
Signed-off-by: David Hildenbrand 
---
 mm/debug_vm_pgtable.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index 3da0cc380c35..af59cc7bd307 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -810,15 +810,17 @@ static void __init pmd_swap_soft_dirty_tests(struct 
pgtable_debug_args *args) {
 
 static void __init pte_swap_exclusive_tests(struct pgtable_debug_args *args)

 {
-   unsigned long max_swapfile_size = generic_max_swapfile_size();
+   unsigned long max_swap_offset;
swp_entry_t entry, entry2;
pte_t pte;
 
 	pr_debug("Validating PTE swap exclusive\n");
 
+	/* See generic_max_swapfile_size(): probe the maximum offset */

+   max_swap_offset = 
swp_offset(pte_to_swp_entry(swp_entry_to_pte(swp_entry(0, ~0UL;
+
/* Create a swp entry with all possible bits set */
-   entry = swp_entry((1 << MAX_SWAPFILES_SHIFT) - 1,
- max_swapfile_size - 1);
+   entry = swp_entry((1 << MAX_SWAPFILES_SHIFT) - 1, max_swap_offset);
 
 	pte = swp_entry_to_pte(entry);

WARN_ON(pte_swp_exclusive(pte));
--
2.39.0



--
Thanks,

David / dhildenb

[Bug 216095] sysfs: cannot create duplicate filename '/devices/platform/of-display'

2023-01-14 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=216095

--- Comment #14 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 303601
  --> https://bugzilla.kernel.org/attachment.cgi?id=303601=edit
kernel .config (6.2-rc3, PowerMac G4 DP)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216095] sysfs: cannot create duplicate filename '/devices/platform/of-display'

2023-01-14 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=216095

Erhard F. (erhar...@mailbox.org) changed:

   What|Removed |Added

 Attachment #303509|0   |1
is obsolete||

--- Comment #13 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 303600
  --> https://bugzilla.kernel.org/attachment.cgi?id=303600=edit
dmesg (6.2-rc3, PowerMac G4 DP)

(In reply to Michal Suchánek from comment #12)
> Thanks for the DT dumps.
> 
> So you really do have two outputs but the problem is likely different:
Two outputs? I got only a Radeon 9600 in the G4 and it does show up as a single
card in lspci (no secondary output). Xorg.log. only shows a single device.

 # lspci 
:00:0b.0 Host bridge: Apple Inc. UniNorth 2 AGP
:00:10.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV350 [Radeon 9550/9600/X1050 Series]
0001:10:0b.0 Host bridge: Apple Inc. UniNorth 2 PCI
0001:10:12.0 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:10:12.1 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:10:12.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev
04)
0001:10:13.0 Mass storage controller: Silicon Image, Inc. SiI 3112
[SATALink/SATARaid] Serial ATA Controller (rev 02)
0001:10:15.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865
Multi-I/O Controller
0001:10:15.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865
Multi-I/O Controller
0001:10:15.2 Parallel controller: Illegal Vendor ID Device 9865
0001:10:16.0 Network controller: Broadcom Inc. and subsidiaries BCM4306
802.11b/g Wireless LAN Controller (rev 02)
0001:10:17.0 Unassigned class [ff00]: Apple Inc. KeyLargo Mac I/O (rev 03)
0001:10:18.0 USB controller: Apple Inc. KeyLargo USB
0001:10:19.0 USB controller: Apple Inc. KeyLargo USB
0001:10:1b.0 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:10:1b.1 USB controller: NEC Corporation OHCI USB Controller (rev 43)
0001:10:1b.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev
04)
0002:20:0b.0 Host bridge: Apple Inc. UniNorth 2 Internal PCI
0002:20:0d.0 Unassigned class [ff00]: Apple Inc. UniNorth 2 ATA/100
0002:20:0e.0 FireWire (IEEE 1394): Apple Inc. UniNorth 2 FireWire (rev 01)
0002:20:0f.0 Ethernet controller: Apple Inc. UniNorth 2 GMAC (Sun GEM)

 # lspci -v -s :00:10.0
:00:10.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
RV350 [Radeon 9550/9600/X1050 Series] (prog-if 00 [VGA controller])
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] R9600 Pro primary
(Asus OEM for HP)
Device tree node:
/sys/firmware/devicetree/base/pci@f000/ATY,AlteracParent@10
Flags: bus master, 66MHz, medium devsel, latency 255, IRQ 48
Memory at a000 (32-bit, prefetchable) [size=256M]
I/O ports at 0400 [disabled] [size=256]
Memory at 9000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 9002 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2

> The hardware-specific driver gets initialized earlier, and then the
> offb/ofdrm driver cannot get the resources for the framebuffer because the
> native driver is already using them.
> 
> That should be fine but the message it prints is not exactly clear.
Ok. To rule out influence of other drivers I disabled them (# CONFIG_FB is not
set, # CONFIG_DRM_RADEON is not set) and only set CONFIG_DRM=y,
CONFIG_DRM_OFDRM=y but it made no difference. Sill I get this:
sysfs: cannot create duplicate filename '/devices/platform/of-display'
[...]
of-display: probe of of-display failed with error -22

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

2023-01-14 Thread Sedat Dilek 
[ ... ]

> Best is to ask the Debian release-team or (if there exist) maintainers
> or responsibles for the IA64 port - which is an ***unofficial*** port.
>

Here we go:

https://lists.debian.org/debian-ia64/

Posting address: debian-i...@lists.debian.org

Found via 

-Sedat-

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

2023-01-14 Thread Sedat Dilek 
On Sat, Jan 14, 2023 at 12:43 AM Ard Biesheuvel  wrote:
>
> On Fri, 13 Jan 2023 at 22:06, John Paul Adrian Glaubitz
>  wrote:
> >
> > Hello Ard!
> >
> > > Can I take that as an ack on [0]? The EFI subsystem has evolved
> > > substantially over the years, and there is really no way to do any
> > > IA64 testing beyond build testing, so from that perspective, dropping
> > > it entirely would be welcomed.
> >
> > ia64 is regularly tested in Debian and Gentoo [1][2].
> >
> > Debian's ia64 porterbox yttrium runs a recent kernel without issues:
> >
> > root@yttrium:~# uname -a
> > Linux yttrium 5.19.0-2-mckinley #1 SMP Debian 5.19.11-1 (2022-09-24) ia64 
> > GNU/Linux
> > root@yttrium:~#
> >
> > root@yttrium:~# journalctl -b|head -n10
> > Nov 14 14:46:10 yttrium kernel: Linux version 5.19.0-2-mckinley 
> > (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-6) 11.3.0, GNU ld 
> > (GNU Binutils for Debian) 2.39) #1 SMP Debian 5.19.11-1 (2022-09-24)
> > Nov 14 14:46:10 yttrium kernel: efi: EFI v2.10 by HP
> > Nov 14 14:46:10 yttrium kernel: efi: SALsystab=0xdfdd63a18 ESI=0xdfdd63f18 
> > ACPI 2.0=0x3d3c4014 HCDP=0xd8798 SMBIOS=0x3d368000
> > Nov 14 14:46:10 yttrium kernel: PCDP: v3 at 0xd8798
> > Nov 14 14:46:10 yttrium kernel: earlycon: uart8250 at I/O port 0x4000 
> > (options '115200n8')
> > Nov 14 14:46:10 yttrium kernel: printk: bootconsole [uart8250] enabled
> > Nov 14 14:46:10 yttrium kernel: ACPI: Early table checksum verification 
> > disabled
> > Nov 14 14:46:10 yttrium kernel: ACPI: RSDP 0x3D3C4014 24 (v02 
> > HP)
> > Nov 14 14:46:10 yttrium kernel: ACPI: XSDT 0x3D3C4580 000124 (v01 
> > HP RX2800-2 0001  0113)
> > Nov 14 14:46:10 yttrium kernel: ACPI: FACP 0x3D3BE000 F4 (v03 
> > HP RX2800-2 0001 HP   0001)
> > root@yttrium:~#
> >
> > Same applies to the buildds:
> >
> > root@lifshitz:~# uname -a
> > Linux lifshitz 6.0.0-4-mckinley #1 SMP Debian 6.0.8-1 (2022-11-11) ia64 
> > GNU/Linux
> > root@lifshitz:~#
> >
> > root@lenz:~# uname -a
> > Linux lenz 6.0.0-4-mckinley #1 SMP Debian 6.0.8-1 (2022-11-11) ia64 
> > GNU/Linux
> > root@lenz:~#
> >
> > EFI works fine as well using the latest version of GRUB2.
> >
> > Thanks,
> > Adrian
> >
> > > [1] https://cdimage.debian.org/cdimage/ports/snapshots/
> > > [2] https://mirror.yandex.ru/gentoo-distfiles//releases/ia64/autobuilds/
>
> Thanks for reporting back. I (mis)read the debian ports page [3],
> which mentions Debian 7 as the highest Debian version that supports
> IA64, and so I assumed that support had been dropped from Debian.
>
> However, if only a handful of people want to keep this port alive for
> reasons of nostalgia, it is obviously obsolete, and we should ask
> ourselves whether it is reasonable to expect Linux contributors to
> keep spending time on this.
>
> Does the Debian ia64 port have any users? Or is the system that builds
> the packages the only one that consumes them?
>
>
> [3] https://www.debian.org/ports/ia64/

I have no IA64 hardware or be a user of it or have any strong feelings
to keep this arch in the Linux-kernel.

But I am a Debianist (Debian/unstable AMD64 user).

Best is to ask the Debian release-team or (if there exist) maintainers
or responsibles for the IA64 port - which is an ***unofficial*** port.

What I found... on :

https://cdimage.debian.org/cdimage/ > Ports

https://cdimage.debian.org/cdimage/ports/current/

https://cdimage.debian.org/cdimage/ports/current-debian-installer/ia64/debian-installer-images_20211020_ia64.tar.gz
^^ Last modified: 2021-10-20 22:52

https://cdimage.debian.org/cdimage/ports/current/debian-11.0.0-ia64-NETINST-1.iso
^^ Last modofied: 2022-03-28 14:18

With a net-install image you should be able to setup and explore the
IA64 Debian cosmos.

Example #1: binutils packages

Checking available binutils package for Debian/unstable IA64 (version:
2.39.90.20230110-1):

https://packages.debian.org/sid/binutils <--- Clearly states IA64 as
"unofficial port"
https://packages.debian.org/sid/ia64/binutils/filelist

Example #2: linux-image packages

Cannot say what this means...

https://packages.debian.org/search?arch=amd64=linux-image
(AMD64 - matches)

https://packages.debian.org/search?arch=ia64=linux-image
(IA64 - no matches)

https://packages.debian.org/search?arch=ia64=linux (IA64 -
matches - but no linux-image which ships normally a bootable
Linux-kernel)

As stated I have no expertise in Debian whatever release for IA64 arch.

Hope that helps.

-Sedat-