* Re: Make ReBAR Great Again
From: Greg KH @ 2026-03-26 15:16 UTC (permalink / raw)
To: Cristian Cocos; +Cc: linux-hotplug
In-Reply-To: <ec7dbc9aeab3f7e497ba6e10712da047cf5bc14e.camel@ieee.org>
On Thu, Mar 26, 2026 at 11:01:02AM -0400, Cristian Cocos wrote:
> Is this the right forum to post this? The hotplug list looked to me to
> be the most appropriate venue, though please advise if you guys can
> think of a more appropriate recipient.
linux-pci?
^ permalink raw reply
* Re: Make ReBAR Great Again
From: Cristian Cocos @ 2026-03-26 15:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <b60b2f7c039f5f325fc54a75230f595a2278776b.camel@ieee.org>
Is this the right forum to post this? The hotplug list looked to me to
be the most appropriate venue, though please advise if you guys can
think of a more appropriate recipient.
The short story is that ReBAR does not work in hotplug scenarios:
hotplugged eGPUs are forced onto a 256MB BAR regardless of the system's
ReBAR capabilities, and this because during hotplug the Linux kernel
does not consult the ReBAR capability. It's that simple. Seeing as
eGPUs are becoming more popular, accommodating eGPU hotplug scenarios
becomes stringent.
On Sun, 2026-03-08 at 15:35 -0400, Cristian Cocos wrote:
> The following is a suggestion for the Linux kernel devs.
>
> Now that Thunderbolt eGPUs have become more common, it might be a
> good
> idea to make the Linux kernel ReBAR-over-Thunderbolt friendly. This,
> I
> contend, can be done by simply mimicking the system behavior at boot
> time.
>
> The current Thunderbolt eGPU *hotplug* sequence of events is this:
> BAR
> 2's hardware register powers up at 256 MB — the default size
> programmed
> into the BAR's address decoder by Intel at the factory. The PCIe
> Resizable BAR capability advertises support for up to 16 GB, but it's
> passive — software must explicitly exercise it. When a Thunderbolt
> eGPU
> is hotplugged at runtime, the kernel's PCI subsystem enumerates the
> new
> device, reads the BAR at its 256 MB default, sizes the bridge windows
> to match, and assigns addresses — all before any driver loads. The
> ReBAR capability is never consulted(!) during this process.
>
> A workaround is available for cold-plug scenarios only, and is
> achieved by means of the **thunderbolt.host_reset=0** kernel
> parameter:
> this preserves the BIOS's PCIe tunnel and BAR assignments from POST
> (where the BIOS *does* exercise ReBAR). This delivers the full 16 GB
> BAR but, as just mentioned, only works for cold-plug(!) scenarios —
> if
> the eGPU is power-cycled at runtime, the new tunnel gets the 256 MB
> default.
>
> The proper fix would be for the kernel's PCI hotplug resource
> assignment to *first* check for ReBAR capability during enumeration,
> resize the BAR to the largest supported size that fits within
> available
> bridge headroom, and *then* commit bridge windows and assign
> addresses.
> This is essentially what the BIOS does during POST. It hasn't been
> implemented yet because eGPU-over-Thunderbolt-with-ReBAR is (was?) a
> niche use case.
>
> Well, no more niche use case. eGPU-over-Thunderbolt is becoming
> mainstream.
>
>
^ permalink raw reply
* Re Re: potential bug or quirk in the linux kernel usb subsystem, usb microphone sampling rate resolution rate
From: Hans Jörg Paliege @ 2026-03-09 9:04 UTC (permalink / raw)
To: linux-hotplug
Hello Mr. Hartman,
i am just a daily linux user and not familiar with the internal
proceedings of bugreports, mailing lists and development teams.
Please dont take any of this personal. I just sent the report to the
main developer according to the linux kernel documentation,
which is you. As with yesterdays and this email, i only clicked reply
and i hope that the email finds its way to the right developer
and with some good luck maybe this quirk will be fixed.
Small addendum to the usb microphone quirk:
As a workaround i use a professional ZOOM H2 usb audio recording device
from 2009. Specs can be found on a wikipedia page.
The main difference why this works fine is because during boot it is
only powered up and on the device itself i have to
choose either to be a smd card storage device or a usb stereo
microphone. At this point i have to manually set the
audio sample rate to either 44100 or 48000 and then initialize the usb
connection with the pc. Once this is done,
it works and the usb subsystem does not override the sampling rate
because it is set on the device itself.
As with todays dmesg messages, they are the same as yesterday. All other
dmesg messages are fine with no errors, and all other usb devices work
fine.
Thank you very much.
Best regards
Hans Paliege
^ permalink raw reply
* Make ReBAR Great Again
From: Cristian Cocos @ 2026-03-08 19:35 UTC (permalink / raw)
To: linux-hotplug
The following is a suggestion for the Linux kernel devs.
Now that Thunderbolt eGPUs have become more common, it might be a good
idea to make the Linux kernel ReBAR-over-Thunderbolt friendly. This, I
contend, can be done by simply mimicking the system behavior at boot
time.
The current Thunderbolt eGPU *hotplug* sequence of events is this: BAR
2's hardware register powers up at 256 MB — the default size programmed
into the BAR's address decoder by Intel at the factory. The PCIe
Resizable BAR capability advertises support for up to 16 GB, but it's
passive — software must explicitly exercise it. When a Thunderbolt eGPU
is hotplugged at runtime, the kernel's PCI subsystem enumerates the new
device, reads the BAR at its 256 MB default, sizes the bridge windows
to match, and assigns addresses — all before any driver loads. The
ReBAR capability is never consulted(!) during this process.
A workaround is available for cold-plug scenarios only, and is
achieved by means of the **thunderbolt.host_reset=0** kernel parameter:
this preserves the BIOS's PCIe tunnel and BAR assignments from POST
(where the BIOS *does* exercise ReBAR). This delivers the full 16 GB
BAR but, as just mentioned, only works for cold-plug(!) scenarios — if
the eGPU is power-cycled at runtime, the new tunnel gets the 256 MB
default.
The proper fix would be for the kernel's PCI hotplug resource
assignment to *first* check for ReBAR capability during enumeration,
resize the BAR to the largest supported size that fits within available
bridge headroom, and *then* commit bridge windows and assign addresses.
This is essentially what the BIOS does during POST. It hasn't been
implemented yet because eGPU-over-Thunderbolt-with-ReBAR is (was?) a
niche use case.
Well, no more niche use case. eGPU-over-Thunderbolt is becoming
mainstream.
^ permalink raw reply
* Re: potential bug or quirk in the linux kernel usb subsystem, usb microphone sampling rate resolution rate
From: Greg KH @ 2026-03-08 17:36 UTC (permalink / raw)
To: Hans Jörg Paliege; +Cc: linux-usb, linux-hotplug
In-Reply-To: <159da401-4f3a-4069-bd2a-d8dd934995e1@web.de>
On Wed, Mar 04, 2026 at 07:55:13PM +0100, Hans Jörg Paliege wrote:
> Hello Mr. Kroah-Hartman,
>
>
>
> my name is Hans Paliege and i am a longtime Linux user, but i came across a
> potential peculiar quirk or bug in the usb subsystem
>
> that may need your attention. According to the kernel documentation i should
> contact You as the main developer directly.
The documentation should say to contact the linux-usb list, which I've
cc:ed here :)
> I am using a debian unstable amd64 build that is updated daily, and during
> boot for about two weeks now
>
> the audio frequency sample rate of my logitech C270 usb webcam is no longer
> initialized correctly.
When did it last work properly? When did it stop working? Any specific
kernel version ranges?
> As a result the webcam only delivers video but no audio. The webcam
> microphone is as a audio device recognized
> by the webbrowser but the input is null.
Those are 2 different USB devices in one, so something is off for the
audio stream somehow.
>
> During boot the dmesg error messages are:
>
>
> [ +0,007125] usb 3-1: current rate 24000 is different from the runtime rate
> 16000
> [ +0,002572] usb 3-1: 3:3: cannot set freq 24000 to ep 0x82
>
>
>
> After manual usbreset of the logitech C270 webcam the dmesg error messages
> are:
>
>
> [Mär 2 22:13] usb 3-6.2: reset full-speed USB device number 7 using xhci_hcd
> [ +12,959814] usb 3-1: reset high-speed USB device number 2 using xhci_hcd
> [ +0,288046] uvcvideo 3-1:1.0: Found UVC 1.00 device C270 HD WEBCAM
> (046d:0825)
> [ +0,036940] usb 3-1: current rate 16000 is different from the runtime rate
> 32000
> [ +0,063995] usb 3-1: current rate 24000 is different from the runtime rate
> 16000
> [ +0,061679] usb 3-1: 3:3: cannot set freq 24000 to ep 0x82
> [ +0,213449] usb 3-1: set resolution quirk: cval->res = 384
Is that the audio device, or the video device?
> After some internet search i could not find any specific command,
> application or grub boot parameter to manually set the rate to the runtime
> rate of 16000 or 32000.
>
> The quirk seems to be, that the sampling rate is automatically set to the
> value of 24000, while the actual working runtime rates are ignored.
>
> Any subsequent pipewire-alsa related audio volume and input/output works
> fine, and i have to use a really old ZOOM H2 usb microphone at 44100 that
> works for now.
>
> Maybe a recent change in the linux kernel or the usb subsytem caused this.
> It would be great if you could take a closer look at it and fix it.
A range of kernel versions here would be helpful, as would any other
kernel log messages.
thanks,
greg k-h
^ permalink raw reply
* potential bug or quirk in the linux kernel usb subsystem, usb microphone sampling rate resolution rate
From: Hans Jörg Paliege @ 2026-03-04 18:55 UTC (permalink / raw)
To: linux-hotplug
Hello Mr. Kroah-Hartman,
my name is Hans Paliege and i am a longtime Linux user, but i came
across a potential peculiar quirk or bug in the usb subsystem
that may need your attention. According to the kernel documentation i
should contact You as the main developer directly.
I am using a debian unstable amd64 build that is updated daily, and
during boot for about two weeks now
the audio frequency sample rate of my logitech C270 usb webcam is no
longer initialized correctly.
As a result the webcam only delivers video but no audio. The webcam
microphone is as a audio device recognized
by the webbrowser but the input is null.
During boot the dmesg error messages are:
[ +0,007125] usb 3-1: current rate 24000 is different from the runtime
rate 16000
[ +0,002572] usb 3-1: 3:3: cannot set freq 24000 to ep 0x82
After manual usbreset of the logitech C270 webcam the dmesg error
messages are:
[Mär 2 22:13] usb 3-6.2: reset full-speed USB device number 7 using xhci_hcd
[ +12,959814] usb 3-1: reset high-speed USB device number 2 using xhci_hcd
[ +0,288046] uvcvideo 3-1:1.0: Found UVC 1.00 device C270 HD WEBCAM
(046d:0825)
[ +0,036940] usb 3-1: current rate 16000 is different from the runtime
rate 32000
[ +0,063995] usb 3-1: current rate 24000 is different from the runtime
rate 16000
[ +0,061679] usb 3-1: 3:3: cannot set freq 24000 to ep 0x82
[ +0,213449] usb 3-1: set resolution quirk: cval->res = 384
After some internet search i could not find any specific command,
application or grub boot parameter to manually set the rate to the
runtime rate of 16000 or 32000.
The quirk seems to be, that the sampling rate is automatically set to
the value of 24000, while the actual working runtime rates are ignored.
Any subsequent pipewire-alsa related audio volume and input/output works
fine, and i have to use a really old ZOOM H2 usb microphone at 44100
that works for now.
Maybe a recent change in the linux kernel or the usb subsytem caused
this. It would be great if you could take a closer look at it and fix it.
Thank you very much.
Best regards
Hans Paliege
^ permalink raw reply
* Hiring Linux Gurus for Next Microsoft/Apple Now!
From: info @ 2025-09-16 5:15 UTC (permalink / raw)
To: linux-kernel, linux-arch, linux-input, linux-hotplug
In-Reply-To: <ec28ecc24919963b2e5f9edd77e55262@unitedcomputing.tech>
Dear Linux experts/developers,
We are AGGRESSIVELY HIRING a team of Linux gurus for our business United
Computing Inc., most promising like next Microsoft/Apple, to own and
build our Linux platforms like ZorinOS & Ubuntu and dominate
mobile/desktop/embedded/workstation/server/cloud or all computing
domains with Linux existing domination over all domains except for
shrinking Windows desktop computing, and our LinuxAll innovations for
work & play in any pose/time/place and replacing today's
phones/tablets/PCs/gaming/AR/VR devices. LinuxAll includes XR glasses
for multiple virtual screens/windows, physical or virtual
keyboards/multi-touch/3D inputs, Linux gaming computer tablet phones,
and optional power banks, etc. These addictive products will hit the
market like iPhone 1+ for sure. We own this top tech innovation since
mid 2008 out of our AR/VR research and the disrupted PC industry by the
release of iPhone with small screen and limited OS/inputs. Tech giants
built their XR products but all failed, and can't steal them from us due
to cross competitions, let alone others. LinuxAll Gen 1/2 products,
especially many Birdbath and Waveguide AR glasses, are on sale at
https://www.unitedcomputing.org/shop.
Below is a list of our LinuxAll components and products:
1) Birdbath XR Glasses: Legion Glasses 2, Rayneo Air 3s Pro, Viture Luma
XR, Xreal One Pro/Air 2 Ultra/Pro, Rokid AR Lite, StarV View, InAir 2
Pro
2) Waveguide XR Glasses: Inmo Air 3, Rayneo X3 Pro, Oppo Air Glass 3,
Rokid Glasses, Orion AR, Myvu Discovery, Lumus Optical, Cellid, PVG,
JioGlass, Mirza AR, StarV Air2
3) Mini Gaming PCs: Legion Go, Ling Long Foldable Keyboard PC, Khadas
Mind 2, Rog Ally, Steam Deck, OneXPlayer 2 Pro, GPD WIN4, Ayaneo, Mini
PCs, etc.
4) Computer Phones: 5.5'/6'/6.5'/7'/8' rugged gaming phone tablet PCs
from Sincoole, rugged-pda, njynwei, and MactronGroup
5) Physical/virtual Inputs: Foldable/mini/projection keyboards, TapXR
wearable keyboard, and Leap Motion or XR cameras based virtual inputs
6) Laptop Power Banks: Psooo 65w 5/80k power bank, Zkpilse 65w 50k power
bank, offgrid power products, etc.
It's critical and necessary for our business to own and build our OS
platforms, otherwise there will be endless US/world crisis and huge
fights over this matter that must be settled ASAP. As the WinAll deal
with Microsoft and $1 billion for ZorinOS & Ubuntu acquisition aren't
there, we are contacting Linux developer communities to own and build
our Linux platforms together instead. Our Linux developers will match
employees building Ubuntu & ZorinOS with various job functions. They
will add the HCI and system components/features for
phone/tablet/PC/gaming/AR/VR convergence, new XR/AI features matching
new hardware/devices, and our Linux platforms to dominate all computing
domains. They will build core apps, tools, frameworks, etc. for our
Linux platforms too. OS businesses are quite mature and crowded so we
shall be able to absorb abundant Linux resources soon. By leveraging
abundant PC/mobile hardware/chip vendor resources, we don't need to
invest a lot in our Linux & LinuxAll ownership and development as well.
Interested candidates please email us their resumes and roles at
info@unitedcomputing.tech ASAP or contact us for any question. This is
really a great opportunity for Linux to defeat Windows/MacOS/Android/iOS
and dominate/shine for ever. The sooner you join us, the sooner we go
big together!
More information:
https://www.facebook.com/marketplace/profile/100095444238325/
https://www.unitedcomputing.org/linuxall > UCPitchDeck.pdf
https://b23.tv/9h73RDV
Thanks & Regards,
Shirley Zhou
Founder & CEO
United Computing Inc.
https://www.unitedcomputing.org
Phone/WhatsApp: +1 9096309408
Email: info@unitedcomputing.tech
Address: 6203 San Ignacio Ave Ste 110, San Jose, CA, USA, 95119
^ permalink raw reply
* Re: udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
From: Andrei Borzenkov @ 2023-12-21 13:22 UTC (permalink / raw)
To: pgnd; +Cc: linux-hotplug, gregkh, jeisom
In-Reply-To: <7a270d09-9c53-47d4-b3e7-603062faf647@dev-mail.net>
On Thu, Dec 21, 2023 at 3:26 PM pgnd <pgnd@dev-mail.net> wrote:
>
>
> > Anyway, try asking on the systemd mailing list, which is where udev help
> > can be found, this list really isn't alive anymore at all, sorry.
>
> np, thx. i've posted in systemd:matrix.org; we'll see what pops up there.
>
> > Try running 'udevadm monitor' to watch the events to ensure they are
> > what you think they are.
>
> just to close/comment here before moving on, @ shell after boot
>
> udevadm monitor | grep enp5s0
> KERNEL[40344.410195] change /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:05.0/0000:05:00.0/net/enp5s0 (net)
> UDEV [40344.529849] change /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:05.0/0000:05:00.0/net/enp5s0 (net)
>
> and, checking boot logs,
>
> journalctl -b | grep systemd-udevd | grep /etc
> Dec 20 19:24:16 dev systemd-udevd[522]: Trying to open "/etc/systemd/hwdb/hwdb.bin"...
> Dec 20 19:24:16 dev systemd-udevd[522]: Trying to open "/etc/udev/hwdb.bin"...
> Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/11-dm.rules
> Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/59-persistent-storage-dm.rules
> Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/59-persistent-storage-md.rules
> Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/59-persistent-storage.rules
> Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/61-persistent-storage.rules
> Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/64-lvm.rules
> Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/65-md-incremental-imsm.rules
>
> seemingly missing/ignoring,
>
> ls -al /etc/udev/rules.d/
> -rw-r--r-- 1 root root 2.2K Dec 20 18:47 99-enp5s0-sysctl.rules
>
Your udevd runs in initrd and this rule is not included there.
>
> where
>
> find /usr/lib/dracut/modules.d -type f \
> -iname 11-dm.rules \
> -o -iname 59-persistent-storage-dm.rules \
> -o -iname 59-persistent-storage-md.rules \
> -o -iname 59-persistent-storage.rules \
> -o -iname 61-persistent-storage.rules \
> -o -iname 64-lvm.rules \
> -o -iname 65-md-incremental-imsm.rules
>
> /usr/lib/dracut/modules.d/90dm/11-dm.rules
> /usr/lib/dracut/modules.d/90dm/59-persistent-storage-dm.rules
> /usr/lib/dracut/modules.d/90mdraid/59-persistent-storage-md.rules
> /usr/lib/dracut/modules.d/90mdraid/65-md-incremental-imsm.rules
> /usr/lib/dracut/modules.d/95udev-rules/59-persistent-storage.rules
> /usr/lib/dracut/modules.d/95udev-rules/61-persistent-storage.rules
> /usr/lib/dracut/modules.d/90lvm/64-lvm.rules
>
>
^ permalink raw reply
* Re: udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
From: pgnd @ 2023-12-21 13:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <7a270d09-9c53-47d4-b3e7-603062faf647@dev-mail.net>
> i've posted in systemd:matrix.org; we'll see what pops up there.
for those interested, mv'd to systemd mailing list
https://lists.freedesktop.org/archives/systemd-devel/2023-December/049866.html
^ permalink raw reply
* Re: udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
From: pgnd @ 2023-12-21 12:25 UTC (permalink / raw)
To: linux-hotplug; +Cc: gregkh, jeisom
In-Reply-To: <2023122117-outlet-generic-f184@gregkh>
> Anyway, try asking on the systemd mailing list, which is where udev help
> can be found, this list really isn't alive anymore at all, sorry.
np, thx. i've posted in systemd:matrix.org; we'll see what pops up there.
> Try running 'udevadm monitor' to watch the events to ensure they are
> what you think they are.
just to close/comment here before moving on, @ shell after boot
udevadm monitor | grep enp5s0
KERNEL[40344.410195] change /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:05.0/0000:05:00.0/net/enp5s0 (net)
UDEV [40344.529849] change /devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:05.0/0000:05:00.0/net/enp5s0 (net)
and, checking boot logs,
journalctl -b | grep systemd-udevd | grep /etc
Dec 20 19:24:16 dev systemd-udevd[522]: Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Dec 20 19:24:16 dev systemd-udevd[522]: Trying to open "/etc/udev/hwdb.bin"...
Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/11-dm.rules
Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/59-persistent-storage-dm.rules
Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/59-persistent-storage-md.rules
Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/59-persistent-storage.rules
Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/61-persistent-storage.rules
Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/64-lvm.rules
Dec 20 19:24:16 dev systemd-udevd[522]: Reading rules file: /etc/udev/rules.d/65-md-incremental-imsm.rules
seemingly missing/ignoring,
ls -al /etc/udev/rules.d/
-rw-r--r-- 1 root root 2.2K Dec 20 18:47 99-enp5s0-sysctl.rules
where
find /usr/lib/dracut/modules.d -type f \
-iname 11-dm.rules \
-o -iname 59-persistent-storage-dm.rules \
-o -iname 59-persistent-storage-md.rules \
-o -iname 59-persistent-storage.rules \
-o -iname 61-persistent-storage.rules \
-o -iname 64-lvm.rules \
-o -iname 65-md-incremental-imsm.rules
/usr/lib/dracut/modules.d/90dm/11-dm.rules
/usr/lib/dracut/modules.d/90dm/59-persistent-storage-dm.rules
/usr/lib/dracut/modules.d/90mdraid/59-persistent-storage-md.rules
/usr/lib/dracut/modules.d/90mdraid/65-md-incremental-imsm.rules
/usr/lib/dracut/modules.d/95udev-rules/59-persistent-storage.rules
/usr/lib/dracut/modules.d/95udev-rules/61-persistent-storage.rules
/usr/lib/dracut/modules.d/90lvm/64-lvm.rules
^ permalink raw reply
* Re: udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
From: Greg KH @ 2023-12-21 8:17 UTC (permalink / raw)
To: pgnd; +Cc: linux-hotplug
In-Reply-To: <fb9f85b9-cb79-427c-862f-bd33afe2fcbf@dev-mail.net>
On Wed, Dec 20, 2023 at 07:33:06PM -0500, pgnd wrote:
> i've created a udev rule to set IPv6 params
>
> cat /etc/udev/rules.d/01-enp5s0-sysctl.rules
> ACTION=="add|bind|change", SUBSYSTEM=="net", KERNEL=="enp5s0", \
> RUN+="/sbin/sysctl -qw \
> net.ipv6.conf.enp5s0.forwarding=0 \
> net.ipv6.conf.enp5s0.accept_ra=1 \
> net.ipv6.conf.enp5s0.use_tempaddr=1 \
> "
>
> but, immediately after boot, exec
>
> sysctl \
> net.ipv6.conf.enp5s0.forwarding \
> net.ipv6.conf.enp5s0.accept_ra \
> net.ipv6.conf.enp5s0.use_tempaddr
>
> returns the values, unchanged,
>
> net.ipv6.conf.enp5s0.forwarding = 0
> net.ipv6.conf.enp5s0.accept_ra = 0
> net.ipv6.conf.enp5s0.use_tempaddr = 0
>
> otoh, if i exec at shell,
>
> udevadm trigger
> sysctl \
> net.ipv6.conf.enp5s0.forwarding \
> net.ipv6.conf.enp5s0.accept_ra \
> net.ipv6.conf.enp5s0.use_tempaddr
>
> the values are changed
>
> net.ipv6.conf.enp5s0.forwarding = 0
> net.ipv6.conf.enp5s0.accept_ra = 1
> net.ipv6.conf.enp5s0.use_tempaddr = 1
>
> what's keeping my udev rule from setting up the interface sysctls on boot?
Are you sure that your rule is running after the interface is renamed?
Try running 'udevadm monitor' to watch the events to ensure they are
what you think they are.
Anyway, try asking on the systemd mailing list, which is where udev help
can be found, this list really isn't alive anymore at all, sorry.
good luck!
greg k-h
^ permalink raw reply
* udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
From: pgnd @ 2023-12-21 0:33 UTC (permalink / raw)
To: linux-hotplug
hi,
on
lsb_release -rd
Description: Fedora release 39 (Thirty Nine)
Release: 39
uname -rm
6.6.6-200.fc39.x86_64 x86_64
i have this net device
lspci | grep Ethernet | grep 05:00
05:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
i enable persistent naming; in kernel cmdline,
"... net.ifnames=1 ..."
the interface is renamed/created during boot
dmesg | grep "renamed from eth"
[ 6.945108] igb 0000:05:00.0 enp5s0: renamed from eth0
i've created a udev rule to set IPv6 params
cat /etc/udev/rules.d/01-enp5s0-sysctl.rules
ACTION=="add|bind|change", SUBSYSTEM=="net", KERNEL=="enp5s0", \
RUN+="/sbin/sysctl -qw \
net.ipv6.conf.enp5s0.forwarding=0 \
net.ipv6.conf.enp5s0.accept_ra=1 \
net.ipv6.conf.enp5s0.use_tempaddr=1 \
"
but, immediately after boot, exec
sysctl \
net.ipv6.conf.enp5s0.forwarding \
net.ipv6.conf.enp5s0.accept_ra \
net.ipv6.conf.enp5s0.use_tempaddr
returns the values, unchanged,
net.ipv6.conf.enp5s0.forwarding = 0
net.ipv6.conf.enp5s0.accept_ra = 0
net.ipv6.conf.enp5s0.use_tempaddr = 0
otoh, if i exec at shell,
udevadm trigger
sysctl \
net.ipv6.conf.enp5s0.forwarding \
net.ipv6.conf.enp5s0.accept_ra \
net.ipv6.conf.enp5s0.use_tempaddr
the values are changed
net.ipv6.conf.enp5s0.forwarding = 0
net.ipv6.conf.enp5s0.accept_ra = 1
net.ipv6.conf.enp5s0.use_tempaddr = 1
what's keeping my udev rule from setting up the interface sysctls on boot?
-pgnd
^ permalink raw reply
* Re: PSA: This list is being migrated (no action required)
From: Konstantin Ryabitsev @ 2023-11-10 19:35 UTC (permalink / raw)
To: linux-embedded, linux-ext4, linux-fbdev, linux-fpga,
linux-fscrypt, linux-gcc, linux-gpio, linux-hams, linux-hexagon,
linux-hotplug, linux-hwmon, linux-i2c, linux-ia64, linux-ide,
linux-iio, linux-input, linux-integrity, linux-kbuild,
linux-kselftest, linux-leds, linux-m68k, linux-man, linux-media,
linux-mips, linux-mmc, linux-msdos
In-Reply-To: <cfriwrxovqzcrptf74ccq52lcqj2nsergucufsz6wlh45fdnz3@z5e5y2lowbq2>
On Fri, Nov 10, 2023 at 01:51:44PM -0500, Konstantin Ryabitsev wrote:
> This list is being migrated to new vger infrastructure. No action is required
> on your part and there will be no change in how you interact with this list
> after the migration is completed.
>
> There will be a short 30-minute delay to the list archives on lore.kernel.org.
> Once the backend work is done, I will follow up with another message.
This work is completed now. This message acts as a test to make sure archives
are working at their new place.
If anything is not working or looking right, please reach out to
helpdesk@kernel.org.
-K
^ permalink raw reply
* PSA: This list is being migrated (no action required)
From: Konstantin Ryabitsev @ 2023-11-10 18:51 UTC (permalink / raw)
To: linux-embedded, linux-ext4, linux-fbdev, linux-fpga,
linux-fscrypt, linux-gcc, linux-gpio, linux-hams, linux-hexagon,
linux-hotplug, linux-hwmon, linux-i2c, linux-ia64, linux-ide,
linux-iio, linux-input, linux-integrity, linux-kbuild,
linux-kselftest, linux-leds, linux-m68k, linux-man, linux-media,
linux-mips, linux-mmc, linux-msdos
Hello, all:
This list is being migrated to new vger infrastructure. No action is required
on your part and there will be no change in how you interact with this list
after the migration is completed.
There will be a short 30-minute delay to the list archives on lore.kernel.org.
Once the backend work is done, I will follow up with another message.
-K
^ permalink raw reply
* Re: PSA: migrating linux-hotplug to new vger infrastructure
From: Greg KH @ 2023-11-07 6:00 UTC (permalink / raw)
To: Eric Pilmore; +Cc: Matthew Dharm, Konstantin Ryabitsev, linux-hotplug, D Meyer
In-Reply-To: <CAOQPn8uhcVP4PR353GdJoEqUbF1CBHgKsvmtLMpgS5V=+G+kOw@mail.gmail.com>
On Mon, Nov 06, 2023 at 09:12:56PM -0800, Eric Pilmore wrote:
> On Mon, Nov 6, 2023 at 12:46 PM Matthew Dharm
> <mdharm-usb@one-eyed-alien.net> wrote:
> >
> >
> > Special MMIO reservation in BIOS is not required if a device in your
> > PCIe tree, such as a Broadcom Gen4 or Gen5 switch device, can reserve
> > address space via "synthetic mode" for missing devices.
> >
> > Matt
>
> Yes, I'm familiar with Synthetic Mode (or Synthetic Endpoints), but
> that's simply creating a dummy device to fool the BIOS into
> effectively putting aside some amount of MMIO space. And that works
> great so long as what you want to dynamically add fits within that
> reserved space. I guess I was looking for something more flexible
> where I didn't need to know a priori the "size" of what I wanted to
> add in. Presumably this would require some kind of rebalancing of the
> address assignments within the PCIe tree/sub-tree, which in turn
> likely means temporarily "suspending" I/O activity, at least across
> some portion of the I/O tree, while addresses move around.
No, that is not something that Linux supports at this time. I also
don't think that any other operating system supports it either, right?
We always said, if someone wants to support this, great, we will be glad
to review the patches for adding this type of functionality. But until
then, we just rely on the BIOS or other types of hardware to handle this
properly for us.
thanks,
greg k-h
^ permalink raw reply
* Re: PSA: migrating linux-hotplug to new vger infrastructure
From: Eric Pilmore @ 2023-11-07 5:12 UTC (permalink / raw)
To: Matthew Dharm; +Cc: Greg KH, Konstantin Ryabitsev, linux-hotplug, D Meyer
In-Reply-To: <CAA6KcBBCn_rktLyTKanUSef1+KDj+ONKbHL+U3yXstn9-T6k6g@mail.gmail.com>
On Mon, Nov 6, 2023 at 12:46 PM Matthew Dharm
<mdharm-usb@one-eyed-alien.net> wrote:
>
>
> Special MMIO reservation in BIOS is not required if a device in your
> PCIe tree, such as a Broadcom Gen4 or Gen5 switch device, can reserve
> address space via "synthetic mode" for missing devices.
>
> Matt
Yes, I'm familiar with Synthetic Mode (or Synthetic Endpoints), but
that's simply creating a dummy device to fool the BIOS into
effectively putting aside some amount of MMIO space. And that works
great so long as what you want to dynamically add fits within that
reserved space. I guess I was looking for something more flexible
where I didn't need to know a priori the "size" of what I wanted to
add in. Presumably this would require some kind of rebalancing of the
address assignments within the PCIe tree/sub-tree, which in turn
likely means temporarily "suspending" I/O activity, at least across
some portion of the I/O tree, while addresses move around.
Eric
^ permalink raw reply
* Re: PSA: migrating linux-hotplug to new vger infrastructure
From: Matthew Dharm @ 2023-11-06 20:46 UTC (permalink / raw)
To: Greg KH; +Cc: Eric Pilmore, Konstantin Ryabitsev, linux-hotplug, D Meyer
In-Reply-To: <2023110617-startling-crying-e805@gregkh>
On Mon, Nov 6, 2023 at 11:25 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Nov 06, 2023 at 11:05:47AM -0800, Eric Pilmore wrote:
> > On Mon, Nov 6, 2023 at 5:44 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > >
> > > I think the list can just be deleted, there's no traffic anymore, and
> > > "hotplug" doesn't make any sense anymore as "everything" can be
> > > added/removed from a Linux system these days.
> > >
> > > So can we just remove it?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Hi Greg,
> >
> > I was curious about your comment regarding "everything". Is it
> > possible to dynamically add/remove entire I/O sub-trees on the PCIe
> > side?
>
> It has for decades. Well, PCIe isn't decades old, but this has worked
> for PCI systems for decades.
>
> > In other words, can a PCIe bridge, and all associated
> > sub-branches be dynamically added/removed?
>
> Again, yes, for a very long time. If your hardware supports it.
>
> > If so, is there special BIOS support required for possibly reserving
> > adequate MMIO address space?
>
> Yes. That's what those types of systems do, this is nothing new at all,
> we had this working in Linux in 2002 or so. You need special hardware
> to support this, and USB4/Thunderbolt is bringing this for more common
> hardware as well.
Special MMIO reservation in BIOS is not required if a device in your
PCIe tree, such as a Broadcom Gen4 or Gen5 switch device, can reserve
address space via "synthetic mode" for missing devices.
Matt
--
Matthew Dharm
Former Maintainer, USB Mass Storage driver for Linux
^ permalink raw reply
* Re: PSA: migrating linux-hotplug to new vger infrastructure
From: Greg KH @ 2023-11-06 19:25 UTC (permalink / raw)
To: Eric Pilmore; +Cc: Konstantin Ryabitsev, linux-hotplug, D Meyer
In-Reply-To: <CAOQPn8vh36KVYNiH=u_rR_PDd1xMoNKuDJ=u1nnGMqFR9un+yg@mail.gmail.com>
On Mon, Nov 06, 2023 at 11:05:47AM -0800, Eric Pilmore wrote:
> On Mon, Nov 6, 2023 at 5:44 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> >
> > I think the list can just be deleted, there's no traffic anymore, and
> > "hotplug" doesn't make any sense anymore as "everything" can be
> > added/removed from a Linux system these days.
> >
> > So can we just remove it?
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> I was curious about your comment regarding "everything". Is it
> possible to dynamically add/remove entire I/O sub-trees on the PCIe
> side?
It has for decades. Well, PCIe isn't decades old, but this has worked
for PCI systems for decades.
> In other words, can a PCIe bridge, and all associated
> sub-branches be dynamically added/removed?
Again, yes, for a very long time. If your hardware supports it.
> If so, is there special BIOS support required for possibly reserving
> adequate MMIO address space?
Yes. That's what those types of systems do, this is nothing new at all,
we had this working in Linux in 2002 or so. You need special hardware
to support this, and USB4/Thunderbolt is bringing this for more common
hardware as well.
thanks,
greg k-h
^ permalink raw reply
* Re: PSA: migrating linux-hotplug to new vger infrastructure
From: Eric Pilmore @ 2023-11-06 19:05 UTC (permalink / raw)
To: Greg KH; +Cc: Konstantin Ryabitsev, linux-hotplug, D Meyer
In-Reply-To: <2023110646-unimpeded-palm-e067@gregkh>
On Mon, Nov 6, 2023 at 5:44 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
>
> I think the list can just be deleted, there's no traffic anymore, and
> "hotplug" doesn't make any sense anymore as "everything" can be
> added/removed from a Linux system these days.
>
> So can we just remove it?
>
> thanks,
>
> greg k-h
Hi Greg,
I was curious about your comment regarding "everything". Is it
possible to dynamically add/remove entire I/O sub-trees on the PCIe
side? In other words, can a PCIe bridge, and all associated
sub-branches be dynamically added/removed? If so, is there special
BIOS support required for possibly reserving adequate MMIO address
space?
Thanks,
Eric
^ permalink raw reply
* Re: PSA: migrating linux-hotplug to new vger infrastructure
From: Greg KH @ 2023-11-06 16:35 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: linux-hotplug
In-Reply-To: <20231106-tough-zebra-of-potency-a8b32b@nitro>
On Mon, Nov 06, 2023 at 09:29:47AM -0500, Konstantin Ryabitsev wrote:
> On Mon, Nov 06, 2023 at 02:33:22PM +0100, Greg KH wrote:
> > > I plan to migrate the linux-hotplug@vger.kernel.org list to the new
> > > infrastructure this week. We're still doing it list-by-list to make sure that
> > > we don't run into scaling issues with the new infra.
> > >
> > > The migration will be performed live and should not require any downtime.
> > > There will be no changes to how anyone interacts with the list after
> > > migration is completed, so no action is required on anyone's part.
> > >
> > > Please let me know if you have any concerns.
> >
> > I think the list can just be deleted, there's no traffic anymore, and
> > "hotplug" doesn't make any sense anymore as "everything" can be
> > added/removed from a Linux system these days.
> >
> > So can we just remove it?
>
> There seems to be legitimate traffic from last year, so I would lean towards
> migrating it for now and revisiting the question of sunsetting it next year,
> after the dust settles a bit.
Ok, fair enough, trying to make it easier :)
^ permalink raw reply
* Re: PSA: migrating linux-hotplug to new vger infrastructure
From: Konstantin Ryabitsev @ 2023-11-06 14:29 UTC (permalink / raw)
To: Greg KH; +Cc: linux-hotplug
In-Reply-To: <2023110646-unimpeded-palm-e067@gregkh>
On Mon, Nov 06, 2023 at 02:33:22PM +0100, Greg KH wrote:
> > I plan to migrate the linux-hotplug@vger.kernel.org list to the new
> > infrastructure this week. We're still doing it list-by-list to make sure that
> > we don't run into scaling issues with the new infra.
> >
> > The migration will be performed live and should not require any downtime.
> > There will be no changes to how anyone interacts with the list after
> > migration is completed, so no action is required on anyone's part.
> >
> > Please let me know if you have any concerns.
>
> I think the list can just be deleted, there's no traffic anymore, and
> "hotplug" doesn't make any sense anymore as "everything" can be
> added/removed from a Linux system these days.
>
> So can we just remove it?
There seems to be legitimate traffic from last year, so I would lean towards
migrating it for now and revisiting the question of sunsetting it next year,
after the dust settles a bit.
-K
^ permalink raw reply
* Re: PSA: migrating linux-hotplug to new vger infrastructure
From: Greg KH @ 2023-11-06 13:33 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: linux-hotplug
In-Reply-To: <20231106-sparkling-axolotl-of-peace-a3eeb0@nitro>
On Mon, Nov 06, 2023 at 08:21:50AM -0500, Konstantin Ryabitsev wrote:
> Good day!
>
> I plan to migrate the linux-hotplug@vger.kernel.org list to the new
> infrastructure this week. We're still doing it list-by-list to make sure that
> we don't run into scaling issues with the new infra.
>
> The migration will be performed live and should not require any downtime.
> There will be no changes to how anyone interacts with the list after
> migration is completed, so no action is required on anyone's part.
>
> Please let me know if you have any concerns.
I think the list can just be deleted, there's no traffic anymore, and
"hotplug" doesn't make any sense anymore as "everything" can be
added/removed from a Linux system these days.
So can we just remove it?
thanks,
greg k-h
^ permalink raw reply
* PSA: migrating linux-hotplug to new vger infrastructure
From: Konstantin Ryabitsev @ 2023-11-06 13:21 UTC (permalink / raw)
To: linux-hotplug
Good day!
I plan to migrate the linux-hotplug@vger.kernel.org list to the new
infrastructure this week. We're still doing it list-by-list to make sure that
we don't run into scaling issues with the new infra.
The migration will be performed live and should not require any downtime.
There will be no changes to how anyone interacts with the list after
migration is completed, so no action is required on anyone's part.
Please let me know if you have any concerns.
Best wishes,
-K
^ permalink raw reply
* Get name of newly added interface in udev/rules to pass it as a parameter to a shell script
From: Dorian Cantzen @ 2023-04-24 16:56 UTC (permalink / raw)
To: linux-hotplug
Hey I'm a bit desperate. I'm trying to get some help writing a
udev/rule. My problem I also posted on UNIX.stackexchange.com
https://unix.stackexchange.com/questions/743890/get-name-of-newly-added-interface-in-udev-rules-to-pass-it-as-a-parameter-to-a-s
Basically I'm trying to get the name of the interface of a newly added
usb lte stick which I tried with:
SUBSYSTEM="net" ACTION="add" ATTRS{idVendor}="12d1"
RUN+="/home/some/interface_test/dosomething.sh '$attr{bInterfaceClass}'"
But there is nothing being passed over. I also tried it with the %m %b
listed in the man pages but not the right information is being passed.
Cheers
Dorian
^ permalink raw reply
* Re: problem on reboot: pcieport 0000:00:1c:0: pciehp: Slot(0): No link
From: Harald Dunkel @ 2022-07-31 17:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <94dbdb74-1de7-22e6-62d2-1fe460eb89d9@afaics.de>
Hi folks,
sorry for the double post. Please ignore.
Regards
Harri
On 2022-07-31 19:11:52, Harald Dunkel wrote:
> Hi folks,
>
> setup:
> kernel 5.18.14 (built from git)
> Qnap TS-559 Pro II, 4*3.5 HDD + 1 SSD, /boot is on USB stick
> Intel(R) Atom(TM) CPU D525
> Debian Sid
>
> On a reboot after some runtime my Qnap TS-559 Pro II shuts down cleanly, but
> after the kernel and initrd are loaded again it writes an endless stream of
> messages to the console
>
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
> pcieport 0000:00:1c:0: pciehp: Slot(0): Card present
> pcieport 0000:00:1c:0: pciehp: Slot(0): No link
>
> Appr. 2 lines per second. I get an emergency console to login, but it
> is garbled.
>
> If I wait a few minutes to let the qnap cool down it boots again.
>
> # lspci
> 00:00.0 Host bridge: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx DMI Bridge (rev 02)
> 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
> 00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller (rev 02)
> 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
> 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
> 00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)
> 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
> 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)
> 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 02)
> 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 02)
> 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 02)
> 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02)
> 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 02)
> 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
> 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
> 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
> 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
> 00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
> 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)
> 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
> 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
> 02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
> 03:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9125 PCIe SATA 6.0 Gb/s controller (rev 11)
> 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
> 05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
> 06:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
>
> # lscpu
> Architecture: x86_64
> CPU op-mode(s): 32-bit, 64-bit
> Address sizes: 36 bits physical, 48 bits virtual
> Byte Order: Little Endian
> CPU(s): 4
> On-line CPU(s) list: 0-3
> Vendor ID: GenuineIntel
> BIOS Vendor ID: Intel
> Model name: Intel(R) Atom(TM) CPU D525 @ 1.80GHz
> BIOS Model name: Intel(R) Atom(TM) CPU D525 @ 1.80GHz To Be Filled By O.E.M. CPU @ 1.8GHz
> BIOS CPU family: 43
> CPU family: 6
> Model: 28
> Thread(s) per core: 2
> Core(s) per socket: 2
> Socket(s): 1
> Stepping: 10
> BogoMIPS: 3591.07
> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm const
> ant_tsc arch_perfmon pebs bts nopl cpuid aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dtherm
> Caches (sum of all):
> L1d: 48 KiB (2 instances)
> L1i: 64 KiB (2 instances)
> L2: 1 MiB (2 instances)
> NUMA:
> NUMA node(s): 1
> NUMA node0 CPU(s): 0-3
> Vulnerabilities:
> Itlb multihit: Not affected
> L1tf: Not affected
> Mds: Not affected
> Meltdown: Not affected
> Mmio stale data: Not affected
> Retbleed: Not affected
> Spec store bypass: Not affected
> Spectre v1: Not affected
> Spectre v2: Not affected
> Srbds: Not affected
> Tsx async abort: Not affected
>
>
> Every helpful hint is highly appreciated.
>
> Harri
--
Dipl.-Ing. Harald Dunkel |
Muehlenbachstr. 3 | keep it simple
52134 Herzogenrath, Germany |
+49 2407 565 105 |
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox