Linux Device Hot Plugging
[Prev Page][Next Page]
- Re: udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
- From: Andrei Borzenkov <arvidjaar@xxxxxxxxx>
- Re: udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
- From: pgnd <pgnd@xxxxxxxxxxxx>
- Re: udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
- From: pgnd <pgnd@xxxxxxxxxxxx>
- Re: udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- udev rule in /etc/udev/rules.d/ FAILS to exec on boot; but OK exec @ shell after boot ?
- From: pgnd <pgnd@xxxxxxxxxxxx>
- Re: PSA: This list is being migrated (no action required)
- From: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
- PSA: This list is being migrated (no action required)
- From: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
- Re: PSA: migrating linux-hotplug to new vger infrastructure
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: PSA: migrating linux-hotplug to new vger infrastructure
- From: Eric Pilmore <epilmore@xxxxxxxxxx>
- Re: PSA: migrating linux-hotplug to new vger infrastructure
- From: Matthew Dharm <mdharm-usb@xxxxxxxxxxxxxxxxxx>
- Re: PSA: migrating linux-hotplug to new vger infrastructure
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: PSA: migrating linux-hotplug to new vger infrastructure
- From: Eric Pilmore <epilmore@xxxxxxxxxx>
- Re: PSA: migrating linux-hotplug to new vger infrastructure
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: PSA: migrating linux-hotplug to new vger infrastructure
- From: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
- Re: PSA: migrating linux-hotplug to new vger infrastructure
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- PSA: migrating linux-hotplug to new vger infrastructure
- From: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
- Get name of newly added interface in udev/rules to pass it as a parameter to a shell script
- From: Dorian Cantzen <cantzen@xxxxxxxxxxxxxx>
- Re: problem on reboot: pcieport 0000:00:1c:0: pciehp: Slot(0): No link
- From: Harald Dunkel <harri@xxxxxxxxx>
- problem on reboot: pcieport 0000:00:1c:0: pciehp: Slot(0): No link
- From: Harald Dunkel <harri@xxxxxxxxx>
- Re: problem on reboot: pcieport 0000:00:1c:0: pciehp: Slot(0): No link
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- problem on reboot: pcieport 0000:00:1c:0: pciehp: Slot(0): No link
- From: Harald Dunkel <harri@xxxxxxxxx>
- Re: Trying to understand udev duplicate ID_PATH issue
- From: Andrei Borzenkov <arvidjaar@xxxxxxxxx>
- Trying to understand udev duplicate ID_PATH issue
- From: Eli V <eliventer@xxxxxxxxx>
- Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
- From: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
- Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
- From: Topi Miettinen <toiwoton@xxxxxxxxx>
- Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
- From: "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
- Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
- From: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
- Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
- From: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
- Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
- From: "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
- Re: [systemd-devel] Creating executable device nodes in /dev?
- From: Christian Brauner <christian.brauner@xxxxxxxxxx>
- Re: [systemd-devel] Creating executable device nodes in /dev?
- From: Christian Brauner <christian.brauner@xxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Topi Miettinen <toiwoton@xxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Greg KH <greg@xxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
- Re: Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
- From: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Andy Lutomirski <luto@xxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Topi Miettinen <toiwoton@xxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Jethro Beekman <jethro@xxxxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Topi Miettinen <toiwoton@xxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Topi Miettinen <toiwoton@xxxxxxxxx>
- Antw: [EXT] Re: [systemd-devel] Creating executable device nodes in /dev?
- From: "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Topi Miettinen <toiwoton@xxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Topi Miettinen <toiwoton@xxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Andy Lutomirski <luto@xxxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Topi Miettinen <toiwoton@xxxxxxxxx>
- Re: Creating executable device nodes in /dev?
- From: Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
- Creating executable device nodes in /dev?
- From: Andy Lutomirski <luto@xxxxxxxxxx>
- Re: udev events for iscsi
- From: Greg KH <greg@xxxxxxxxx>
- udev events for iscsi
- From: Gionatan Danti <g.danti@xxxxxxxxxx>
- HID_QUIRK_INPUT_PER_APP vs /dev/input/by-id
- From: Jim Paris <jim@xxxxxx>
- Re: Consolidating the interface for camera components
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Consolidating the interface for camera components
- From: Philip Molloy <philip@xxxxxxxxxxxxxxxx>
- Re: driver core: Do uevents have a semantic problem ?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: driver core: Do uevents have a semantic problem ?
- From: Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx>
- Re: driver core: Do uevents have a semantic problem ?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- driver core: Do uevents have a semantic problem ?
- From: Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx>
- Re: [PATCH v2] usb: usbfs: Suppress problematic bind and unbind uevents.
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- [PATCH v2] usb: usbfs: Suppress problematic bind and unbind uevents.
- From: Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx>
- Re: [PATCH] usb: usbfs: Suppress problematic bind and unbind uevents.
- From: Greg KH <greg@xxxxxxxxx>
- [PATCH] usb: usbfs: Suppress problematic bind and unbind uevents.
- From: Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx>
- Re: [PATCH] USB: usbfs: Suppress emission of uevents for interfaces handled via usbfs
- From: Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx>
- Re: [PATCH] USB: usbfs: Suppress emission of uevents for interfaces handled via usbfs
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- [PATCH] USB: usbfs: Suppress emission of uevents for interfaces handled via usbfs
- From: Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx>
- [PATCH] USB: usbfs: Suppress emission of uevents for interfaces handled via usbfs.
- From: Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx>
- Re: [PATCH] usbfs: Suppress uevents for claiminterface/releaseinterface
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- [PATCH] usbfs: Suppress uevents for claiminterface/releaseinterface
- From: Ingo Rohloff <ingo.rohloff@xxxxxxxxxxxxxx>
- Re: udev syntax and features
- From: Andrei Borzenkov <arvidjaar@xxxxxxxxx>
- udev syntax and features
- From: Greg <softcode@xxxxxxxxx>
- Re: reserve memory
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: reserve memory
- From: Ran Shalit <ranshalit@xxxxxxxxx>
- Re: reserve memory
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- reserve memory
- From: Ran Shalit <ranshalit@xxxxxxxxx>
- Re: When should we use "hdparm" ?
- From: Ran Shalit <ranshalit@xxxxxxxxx>
- Re: When should we use "hdparm" ?
- From: Ran Shalit <ranshalit@xxxxxxxxx>
- Re: When should we use "hdparm" ?
- From: Greg KH <greg@xxxxxxxxx>
- When should we use "hdparm" ?
- From: Ran Shalit <ranshalit@xxxxxxxxx>
- Re: [uio] panic in name_show()
- From: Francesco Ruggeri <fruggeri@xxxxxxxxxx>
- [uio] panic in name_show()
- From: fruggeri@xxxxxxxxxx (Francesco Ruggeri)
- INFO: task systemd-udevd:326 blocked for more than 120 seconds.
- From: Cristian <caravena@xxxxxxxxx>
- Re: Understanding stop_machine() use for cpu_down()
- From: Hardik H Bagdi <hbagdi1@xxxxxxxxxxxxxx>
- Re: Understanding stop_machine() use for cpu_down()
- From: Greg KH <greg@xxxxxxxxx>
- Understanding stop_machine() use for cpu_down()
- From: Hardik H Bagdi <hbagdi1@xxxxxxxxxxxxxx>
- Re: Dangling UDEV links after removing FC LUNs
- From: Greg KH <greg@xxxxxxxxx>
- Dangling UDEV links after removing FC LUNs
- From: admin <vondra@xxxxxxxxxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: Greg KH <greg@xxxxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: divakar <divakar.chitturi@xxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: Greg KH <greg@xxxxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: divakar <divakar.chitturi@xxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: Greg KH <greg@xxxxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: divakar <divakar.chitturi@xxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: Greg KH <greg@xxxxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: divakar <divakar.chitturi@xxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: Greg KH <greg@xxxxxxxxx>
- RE: Assign BAR address for pci device after hotplug
- From: "Chitturi, Divakar" <divakar.chitturi@xxxxxxx>
- Re: Assign BAR address for pci device after hotplug
- From: Greg KH <greg@xxxxxxxxx>
- Assign BAR address for pci device after hotplug
- From: "Chitturi, Divakar" <divakar.chitturi@xxxxxxx>
- Use the lastest linux version test hotplug funtion, Print a lagre number of call trace on the stage of "physical remove memory"
- From: Peter Yang(杨相坤) <yangxiangkun@xxxxxxxxxx>
- monitoring udevd
- From: SZÉPE Viktor <viktor@xxxxxxxxx>
- Re: rules for interface naming for on-board cards
- From: Gadre Nayan <gadrenayan@xxxxxxxxx>
- Re: rules for interface naming for on-board cards
- From: Mandeep Sandhu <mandeepsandhu.chd@xxxxxxxxx>
- rules for interface naming for on-board cards
- From: Gadre Nayan <gadrenayan@xxxxxxxxx>
- udev: USB Printers not printing [solved]
- From: Max Euer <m.euer@xxxxxxxxx>
- Re: pcmcia oopses
- From: Greg KH <greg@xxxxxxxxx>
- pcmcia oopses
- From: iwillallways forget1 <iwillalwaysforget1@xxxxxxxxx>
- Fwd: /lib/udev/pcmcia-socket-startup makes 32-bit Linux crash hard
- From: iwillallways forget1 <iwillalwaysforget1@xxxxxxxxx>
- /lib/udev/pcmcia-socket-startup makes 32-bit Linux crash hard
- From: iwillallways forget1 <iwillalwaysforget1@xxxxxxxxx>
- Fwd: Fwd: Fwd: How to determine which device crashes udev in boot?
- From: iwillallways forget1 <iwillalwaysforget1@xxxxxxxxx>
- Re: Fwd: Fwd: How to determine which device crashes udev in boot?
- From: Greg KH <greg@xxxxxxxxx>
- Fwd: Fwd: How to determine which device crashes udev in boot?
- From: iwillallways forget1 <iwillalwaysforget1@xxxxxxxxx>
- Re: Fwd: How to determine which device crashes udev in boot?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Fwd: How to determine which device crashes udev in boot?
- From: iwillallways forget1 <iwillalwaysforget1@xxxxxxxxx>
- Re: How to determine which device crashes udev in boot?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- How to determine which device crashes udev in boot?
- From: iwillallways forget1 <iwillalwaysforget1@xxxxxxxxx>
- Re: Fwd: Information request on /dev/bus/usb
- From: Greg KH <greg@xxxxxxxxx>
- Re: Fwd: Information request on /dev/bus/usb
- From: Ahamed <ahamed.en@xxxxxxxxx>
- Re: Fwd: Information request on /dev/bus/usb
- From: Greg KH <greg@xxxxxxxxx>
- Re: Fwd: Information request on /dev/bus/usb
- From: Ahamed <ahamed.en@xxxxxxxxx>
- Re: Fwd: Information request on /dev/bus/usb
- From: Greg KH <greg@xxxxxxxxx>
- Fwd: Information request on /dev/bus/usb
- From: Ahamed <ahamed.en@xxxxxxxxx>
- Re: Improved fxload [Was: Re: fxload devpath]
- From: "Wojciech A. Koszek" <wojciech@xxxxxxxxxx>
- Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: [PATCHv4 1/1] SCSI: hosts: update to use ida_simple for host_no management
- From: Lee Duncan <lduncan@xxxxxxxx>
- Re: Improved fxload [Was: Re: fxload devpath]
- From: Xiaofan Chen <xiaofanc@xxxxxxxxx>
- Re: Improved fxload [Was: Re: fxload devpath]
- From: Carl Karsten <carl@xxxxxxxxxxxxxxxxx>
- Re: Improved fxload [Was: Re: fxload devpath]
- From: Carl Karsten <carl@xxxxxxxxxxxxxxxxx>
- Improved fxload [Was: Re: fxload devpath]
- From: "Wojciech A. Koszek" <wojciech@xxxxxxxxxx>
- Re: fxload devpath
- From: Andrei Borzenkov <arvidjaar@xxxxxxxxx>
- fxload devpath
- From: Carl Karsten <carl@xxxxxxxxxxxxxxxxx>
- Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
- From: Kamezawa Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
- Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch V3 2/9] kernel/profile.c: Replace cpu_to_mem() with cpu_to_node()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
- From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- Re: possible bug regarding pciehp
- From: Tormen <tormen@xxxxxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: possible bug regarding pciehp
- From: Greg KH <greg@xxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
- Re: possible bug regarding pciehp
- From: Tormen <tormen@xxxxxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
- Re: Possible deadlock related to CPU hotplug and kernfs
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: possible bug regarding pciehp
- From: Greg KH <greg@xxxxxxxxx>
- possible bug regarding pciehp
- From: Tormen <tormen@xxxxxxxxxxxx>
- Possible deadlock related to CPU hotplug and kernfs
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- RE: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
- From: David Rientjes <rientjes@xxxxxxxxxx>
- Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: David Rientjes <rientjes@xxxxxxxxxx>
- Re: [Patch V3 2/9] kernel/profile.c: Replace cpu_to_mem() with cpu_to_node()
- From: David Rientjes <rientjes@xxxxxxxxxx>
- RE: [Intel-wired-lan] [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
- From: "Patil, Kiran" <kiran.patil@xxxxxxxxx>
- Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: Robin Holt <robinmholt@xxxxxxxxx>
- Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch V3 0/9] Enable memoryless node support for x86
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch V3 2/9] kernel/profile.c: Replace cpu_to_mem() with cpu_to_node()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch V3 9/9] mm, x86: Enable memoryless node support to better support CPU/memory hotplug
- From: Tang Chen <tangchen@xxxxxxxxxxxxxx>
- Re: [Patch V3 0/9] Enable memoryless node support for x86
- From: Tang Chen <tangchen@xxxxxxxxxxxxxx>
- Re: [Patch V3 9/9] mm, x86: Enable memoryless node support to better support CPU/memory hotplug
- From: Ingo Molnar <mingo@xxxxxxxxxx>
- Re: [Patch V3 9/9] mm, x86: Enable memoryless node support to better support CPU/memory hotplug
- From: Tang Chen <tangchen@xxxxxxxxxxxxxx>
- Re: [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
- From: David Rientjes <rientjes@xxxxxxxxxx>
- Re: [Patch V3 2/9] kernel/profile.c: Replace cpu_to_mem() with cpu_to_node()
- From: David Rientjes <rientjes@xxxxxxxxxx>
- Re: [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: David Rientjes <rientjes@xxxxxxxxxx>
- Re: [Patch V3 4/9] openvswitch: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: Pravin Shelar <pshelar@xxxxxxxxxx>
- Re: [Patch V3 0/9] Enable memoryless node support for x86
- From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
- RE: [Intel-wired-lan] [Patch V3 6/9] i40evf: Use numa_mem_id() to better support memoryless node
- From: "Patil, Kiran" <kiran.patil@xxxxxxxxx>
- [Patch V3 6/9] i40evf: Use numa_mem_id() to better support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch V3 2/9] kernel/profile.c: Replace cpu_to_mem() with cpu_to_node()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch V3 3/9] sgi-xp: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch V3 5/9] i40e: Use numa_mem_id() to better support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch V3 7/9] x86, numa: Kill useless code to improve code readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch V3 9/9] mm, x86: Enable memoryless node support to better support CPU/memory hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch V3 8/9] mm: Update _mem_id_[] for every possible CPU when memory configuration changes
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch V3 4/9] openvswitch: Replace cpu_to_node() with cpu_to_mem() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch V3 1/9] x86, NUMA, ACPI: Online node earlier when doing CPU hot-addition
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch V3 0/9] Enable memoryless node support for x86
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: Tom Gundersen <teg@xxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: Tom Gundersen <teg@xxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: Robert Milasan <rmilasan@xxxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: linuxcbon linuxcbon <linuxcbon@xxxxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: Robert Milasan <rmilasan@xxxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: linuxcbon linuxcbon <linuxcbon@xxxxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: linuxcbon linuxcbon <linuxcbon@xxxxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: Robert Milasan <rmilasan@xxxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: Tom Gundersen <teg@xxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: linuxcbon linuxcbon <linuxcbon@xxxxxxxxx>
- Re: how to do ? minimal udev script for my rc.sysinit ?
- From: Greg KH <greg@xxxxxxxxx>
- how to do ? minimal udev script for my rc.sysinit ?
- From: linuxcbon linuxcbon <linuxcbon@xxxxxxxxx>
- Re: PCI Hotplug Hardware Support
- From: Greg KH <greg@xxxxxxxxx>
- PCI Hotplug Hardware Support
- From: Daniel Norris <norris.daniel@xxxxxxxxx>
- how to install zxdsl 852 v2
- From: "zkubinski@xxxxxxxxx" <zkubinski@xxxxxxxxx>
- Re: create /etc/udev/rules.d/70-persistent-net.rules
- From: Tom Gundersen <teg@xxxxxxx>
- create /etc/udev/rules.d/70-persistent-net.rules
- From: "Christoph Pleger" <Christoph.Pleger@xxxxxxxxxxxxxxxxx>
- Re: udev not renaming interface if driver is built-in
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: udev not renaming interface if driver is built-in
- From: Rajib Karmakar <rajibkit@xxxxxxxxx>
- Re: udev not renaming interface if driver is built-in
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- udev not renaming interface if driver is built-in
- From: Rajib Karmakar <rajibkit@xxxxxxxxx>
- Re: [Patch Part3 V7 0/8] Enable support of Intel DMAR device hotplug
- From: Joerg Roedel <joro@xxxxxxxxxx>
- Re: [Patch Part3 V7 0/8] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch Part3 V7 0/8] Enable support of Intel DMAR device hotplug
- From: Joerg Roedel <joro@xxxxxxxxxx>
- Re: [Patch Part3 V7 0/8] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch Part3 V7 0/8] Enable support of Intel DMAR device hotplug
- From: Joerg Roedel <joro@xxxxxxxxxx>
- [Patch Part3 V7 1/8] iommu/vt-d: Introduce helper function dmar_walk_resources()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V7 2/8] iommu/vt-d: Dynamically allocate and free seq_id for DMAR units
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V7 3/8] iommu/vt-d: Implement DMAR unit hotplug framework
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V7 4/8] iommu/vt-d: Search for ACPI _DSM method for DMAR hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V7 6/8] iommu/vt-d: Enhance error recovery in function intel_enable_irq_remapping()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V7 5/8] iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V7 7/8] iommu/vt-d: Enhance intel-iommu driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V7 8/8] pci, ACPI, iommu: Enhance pci_root to support DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V7 0/8] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: udev error, ENOEXEC
- From: Angelo Dureghello <angelo70@xxxxxxxxx>
- Re: udev error, ENOEXEC
- From: Andrei Borzenkov <arvidjaar@xxxxxxxxx>
- udev error, ENOEXEC
- From: Angelo Dureghello <angelo70@xxxxxxxxx>
- media-player-info 22 released
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: [Patch Part3 V6 8/8] pci, ACPI, iommu: Enhance pci_root to support DMAR device hotplug
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Re: [Patch Part3 V6 5/8] iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V6 1/8] iommu/vt-d: Introduce helper function dmar_walk_resources()
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- [Patch Part3 V6 2/8] iommu/vt-d: Dynamically allocate and free seq_id for DMAR units
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V6 1/8] iommu/vt-d: Introduce helper function dmar_walk_resources()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V6 4/8] iommu/vt-d: Search for ACPI _DSM method for DMAR hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V6 3/8] iommu/vt-d: Implement DMAR unit hotplug framework
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V6 5/8] iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V6 7/8] iommu/vt-d: Enhance intel-iommu driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V6 8/8] pci, ACPI, iommu: Enhance pci_root to support DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V6 6/8] iommu/vt-d: Enhance error recovery in function intel_enable_irq_remapping()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V6 0/8] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch Part3 V5 5/8] iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch Part3 V5 1/8] iommu/vt-d: Introduce helper function dmar_walk_resources()
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V5 5/8] iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V5 1/8] iommu/vt-d: Introduce helper function dmar_walk_resources()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch Part3 V5 0/8] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch Part3 V5 5/8] iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch Part3 V5 0/8] Enable support of Intel DMAR device hotplug
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V5 8/8] pci, ACPI, iommu: Enhance pci_root to support DMAR device hotplug
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V5 7/8] iommu/vt-d: Enhance intel-iommu driver to support DMAR unit hotplug
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V5 6/8] iommu/vt-d: Enhance error recovery in function intel_enable_irq_remapping()
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V5 5/8] iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V5 4/8] iommu/vt-d: Search for ACPI _DSM method for DMAR hotplug
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V5 3/8] iommu/vt-d: Implement DMAR unit hotplug framework
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: Improper Naming in /dev/disk/by-id and Drives Offline
- From: Greg KH <greg@xxxxxxxxx>
- Re: Improper Naming in /dev/disk/by-id and Drives Offline
- From: Brandon R Schwartz <brandon.r.schwartz@xxxxxxxxxxx>
- Re: Improper Naming in /dev/disk/by-id and Drives Offline
- From: Greg KH <greg@xxxxxxxxx>
- Re: Improper Naming in /dev/disk/by-id and Drives Offline
- From: Brandon R Schwartz <brandon.r.schwartz@xxxxxxxxxxx>
- Re: [Patch Part3 V5 2/8] iommu/vt-d: Dynamically allocate and free seq_id for DMAR units
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- Re: [Patch Part3 V5 1/8] iommu/vt-d: Introduce helper function dmar_walk_resources()
- From: Yijing Wang <wangyijing@xxxxxxxxxx>
- [Bugfix] x86, NUMA, ACPI: Online node earlier when doing CPU hot-addition
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V5 1/8] iommu/vt-d: Introduce helper function dmar_walk_resources()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V5 2/8] iommu/vt-d: Dynamically allocate and free seq_id for DMAR units
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V5 3/8] iommu/vt-d: Implement DMAR unit hotplug framework
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V5 5/8] iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V5 4/8] iommu/vt-d: Search for ACPI _DSM method for DMAR hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V5 6/8] iommu/vt-d: Enhance error recovery in function intel_enable_irq_remapping()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V5 8/8] pci, ACPI, iommu: Enhance pci_root to support DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V5 7/8] iommu/vt-d: Enhance intel-iommu driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V5 0/8] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: Improper Naming in /dev/disk/by-id and Drives Offline
- From: Greg KH <greg@xxxxxxxxx>
- Improper Naming in /dev/disk/by-id and Drives Offline
- From: Brandon R Schwartz <brandon.r.schwartz@xxxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: device symlinks being removed
- From: Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
- Re: device symlinks being removed
- From: Patrick Hemmer <linux@xxxxxxxxxxxxxxx>
- device symlinks being removed
- From: Patrick Hemmer <linux@xxxxxxxxxxxxxxx>
- Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Aniroop Mathur <aniroop.mathur@xxxxxxxxx>
- Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Aniroop Mathur <aniroop.mathur@xxxxxxxxx>
- Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Aniroop Mathur <aniroop.mathur@xxxxxxxxx>
- Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Aniroop Mathur <aniroop.mathur@xxxxxxxxx>
- Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Aniroop Mathur <aniroop.mathur@xxxxxxxxx>
- Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?
- From: Aniroop Mathur <aniroop.mathur@xxxxxxxxx>
- Re: [Patch Part3 V4 00/21] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch Part3 V4 00/21] Enable support of Intel DMAR device hotplug
- From: Joerg Roedel <joro@xxxxxxxxxx>
- Re: [RFC Patch V1 22/30] mm, of: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 22/30] mm, of: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Grant Likely <grant.likely@xxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 30/30] x86, NUMA: Online node earlier when doing CPU hot-addition
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 30/30] x86, NUMA: Online node earlier when doing CPU hot-addition
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 29/30] mm, x86: Enable memoryless node support to better support CPU/memory hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 30/30] x86, NUMA: Online node earlier when doing CPU hot-addition
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 29/30] mm, x86: Enable memoryless node support to better support CPU/memory hotplug
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- udev 215 creates inactive MD devices upon stopping them
- From: Sebastian Parschauer <sebastian.riemer@xxxxxxxxxxxxxxxx>
- iommu/vt-d: Fix build error caused by unknown definition of acpi_handle
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch Part3 V4 16/21] iommu/vt-d: Implement DMAR unit hotplug framework
- From: Joerg Roedel <joro@xxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 28/30] mm: Update _mem_id_[] for every possible CPU when memory configuration changes
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 21/30] mm, irqchip: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 15/30] mm, igb: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 09/30] mm, memcg: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 15/30] mm, igb: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 22/30] mm, of: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 28/30] mm: Update _mem_id_[] for every possible CPU when memory configuration changes
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Tony Luck <tony.luck@xxxxxxxxx>
- Re: [RFC Patch V1 15/30] mm, igb: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 17/30] mm, intel_powerclamp: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 01/30] mm, kernel: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 01/30] mm, kernel: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Nishanth Aravamudan <nacc@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 21/30] mm, irqchip: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jason Cooper <jason@xxxxxxxxxxxxxx>
- Re: [RFC Patch V1 09/30] mm, memcg: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Michal Hocko <mhocko@xxxxxxx>
- Re: [Patch Part3 V4 21/21] pci, ACPI, iommu: Enhance pci_root to support DMAR device hotplug
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: David Rientjes <rientjes@xxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: David Rientjes <rientjes@xxxxxxxxxx>
- Re: [RFC Patch V1 01/30] mm, kernel: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jens Axboe <axboe@xxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: "H. Peter Anvin" <hpa@xxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Jiri Kosina <jkosina@xxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Andi Kleen <andi@xxxxxxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Dave Hansen <dave.hansen@xxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Christoph Lameter <cl@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Christoph Lameter <cl@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Christoph Lameter <cl@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Christoph Lameter <cl@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Christoph Lameter <cl@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Christoph Lameter <cl@xxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [RFC Patch V1 01/30] mm, kernel: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Christoph Lameter <cl@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Tejun Heo <tj@xxxxxxxxxx>
- Re: [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Christoph Lameter <cl@xxxxxxxxxx>
- Re: [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- [RFC Patch V1 02/30] mm, sched: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 01/30] mm, kernel: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 03/30] mm, net: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 05/30] mm, perf: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 04/30] mm, netfilter: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 06/30] mm, tracing: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 08/30] mm, thp: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 11/30] mm, char/mspec.c: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 10/30] mm, xfrm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 12/30] mm, IB/qib: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 13/30] mm, i40e: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 14/30] mm, i40evf: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 15/30] mm, igb: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 16/30] mm, ixgbe: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [RFC Patch V1 25/30] mm, x86, kvm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
- [RFC Patch V1 17/30] mm, intel_powerclamp: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 18/30] mm, bnx2fc: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 19/30] mm, bnx2i: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 20/30] mm, fcoe: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 21/30] mm, irqchip: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 22/30] mm, of: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 25/30] mm, x86, kvm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 26/30] mm, x86, perf: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 23/30] mm, x86: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 27/30] x86, numa: Kill useless code to improve code readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 24/30] mm, x86/platform/uv: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 28/30] mm: Update _mem_id_[] for every possible CPU when memory configuration changes
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 30/30] x86, NUMA: Online node earlier when doing CPU hot-addition
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 29/30] mm, x86: Enable memoryless node support to better support CPU/memory hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 09/30] mm, memcg: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 07/30] mm: Use cpu_to_mem()/numa_mem_id() to support memoryless node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [RFC Patch V1 00/30] Enable memoryless node on x86 platforms
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 02/21] iommu/vt-d: Use correct domain id to flush virtual machine domains
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 01/21] iommu/vt-d: Match segment number when searching for dev_iotlb capable devices
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 03/21] iommu/vt-d: Introduce helper functions to improve code readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 05/21] iommu/vt-d: Allocate dynamic domain id for virtual domains only
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 04/21] iommu/vt-d: Introduce helper functions to make code symmetric for readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 06/21] iommu/vt-d: Fix possible invalid memory access caused by free_dmar_iommu()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 07/21] iommu/vt-d: Avoid freeing virtual machine domain in free_dmar_iommu()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 08/21] iommu/vt-d: Simplify include/linux/dmar.h
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 09/21] iommu/vt-d: Change iommu_enable/disable_translation to return void
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 10/21] iommu/vt-d: Simplify intel_unmap_sg() and kill duplicated code
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 15/21] iommu/vt-d: Dynamically allocate and free seq_id for DMAR units
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 14/21] iommu/vt-d: Introduce helper function dmar_walk_resources()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 17/21] iommu/vt-d: Search for ACPI _DSM method for DMAR hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 18/21] iommu/vt-d: Enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 20/21] iommu/vt-d: Enhance intel-iommu driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 19/21] iommu/vt-d: Enhance error recovery in function intel_enable_irq_remapping()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 21/21] pci, ACPI, iommu: Enhance pci_root to support DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 16/21] iommu/vt-d: Implement DMAR unit hotplug framework
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 13/21] iommu/vt-d: Fix issue in computing domain's iommu_snooping flag
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 12/21] iommu/vt-d: Introduce helper function iova_size() to improve code readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 11/21] iommu/vt-d: Introduce helper domain_pfn_within_range() to simplify code
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V4 00/21] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: A question about hotplug and suspend-resume functionallity
- From: Greg KH <greg@xxxxxxxxx>
- A question about hotplug and suspend-resume functionallity
- From: Igor Bezukh <Igor@xxxxxxxxxxxxx>
- Re: multi-port usb-serial hub rules
- From: Andrey Borzenkov <arvidjaar@xxxxxxxxx>
- Re: multi-port usb-serial hub rules
- From: shawn wilson <ag4ve.us@xxxxxxxxx>
- Re: multi-port usb-serial hub rules
- From: Greg KH <greg@xxxxxxxxx>
- multi-port usb-serial hub rules
- From: shawn wilson <ag4ve.us@xxxxxxxxx>
- Re: [Patch Part3 V3 00/21] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Matching on the ata port number, which is an attribute that is not a direct ancestor
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: [Patch Part3 V3 00/21] Enable support of Intel DMAR device hotplug
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- [Patch Part3 V3 01/21] iommu/vt-d: match segment number when searching for dev_iotlb capable devices
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 02/21] iommu/vt-d: use correct domain id to flush virtual machine domains
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 03/21] iommu/vt-d: introduce helper functions to improve code readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 04/21] iommu/vt-d: introduce helper functions to make code symmetric for readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 08/21] iommu/VT-d: simplify include/linux/dmar.h
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 05/21] iommu/vt-d: only dynamically allocate domain id for virtual domains
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 09/21] iommu/vt-d: change iommu_enable/disable_translation to return void
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 07/21] iommu/vt-d: avoid freeing virtual machine domain in free_dmar_iommu()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 12/21] iommu/vt-d: introduce helper function iova_size() to improve code readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 13/21] iommu/vt-d: fix bug in computing domain's iommu_snooping flag
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 11/21] iommu/vt-d: introduce helper domain_pfn_within_range() to simplify code
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 14/21] IOMMU/vt-d: introduce helper function dmar_walk_resources()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 15/21] iommu/vt-d: dynamically allocate and free seq_id for DMAR units
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 16/21] iommu/vt-d: implement DMAR unit hotplug framework
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 10/21] iommu/vt-d: simplify intel_unmap_sg() and kill duplicated code
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 17/21] iommu/vt-d: search _DSM method for DMAR hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 18/21] iommu/vt-d: enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 19/21] iommu/vt-d: enhance error recovery in function intel_enable_irq_remapping()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 21/21] pci, ACPI, iommu: enhance pci_root to support DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 20/21] iommu/vt-d: enhance intel-iommu driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 06/21] iommu/vt-d: fix possible invalid memory access caused by free_dmar_iommu()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V3 00/21] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: [Patch] iommu/vt-d: fix bug in handling multiple RMRRs for the same PCI device
- From: Joerg Roedel <joro@xxxxxxxxxx>
- [Patch] iommu/vt-d: fix bug in handling multiple RMRRs for the same PCI device
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: Kernel BUG() in block/blk-tag.c:89 causing panic.
- From: Greg KH <greg@xxxxxxxxx>
- Kernel BUG() in block/blk-tag.c:89 causing panic.
- From: Saran Neti <sarannmr@xxxxxxxxx>
- Re: Cross building udev cannot creat device node
- From: 李建文 <jwli@xxxxxxxxxxxxxxx>
- Re: Cross building udev cannot creat device node
- From: Greg KH <greg@xxxxxxxxx>
- Re: Cross building udev cannot creat device node
- From: 李建文 <jwli@xxxxxxxxxxxxxxx>
- Re: Cross building udev cannot creat device node
- From: Greg KH <greg@xxxxxxxxx>
- Cross building udev cannot creat device node
- From: 李建文 <jwli@xxxxxxxxxxxxxxx>
- Re: Why do we need usb_modeswitch?
- From: Greg KH <greg@xxxxxxxxx>
- Why do we need usb_modeswitch?
- From: "Suresh Kumar N." <suri.injun@xxxxxxxxx>
- [linux-hotplug] 3g modem is not recognized as an ethernet device without rebooting
- From: Niyazi Sırt <nyzsirt@xxxxxxxxx>
- Re: [Patch Part3 V2 00/21] Enable support of Intel DMAR device hotplug
- From: Joerg Roedel <joro@xxxxxxxxxx>
- Re: [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
- From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
- Re: [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
- From: Pali Rohár <pali.rohar@xxxxxxxxx>
- Re: [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
- From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
- [PATCH 2/2] dell-wmi: Add support for Fn key combinations
- From: Pali Rohár <pali.rohar@xxxxxxxxx>
- [PATCH 1/2] Input: Add keycodes for some missing Fn key combinations
- From: Pali Rohár <pali.rohar@xxxxxxxxx>
- [PATCH 0/2] dell-wmi: Add support for Fn key combinations
- From: Pali Rohár <pali.rohar@xxxxxxxxx>
- Re: Fn keys on Dell Latitude E6440
- From: Pali Rohár <pali.rohar@xxxxxxxxx>
- [Patch Part3 V2 01/21] iommu/vt-d: match segment number when searching for dev_iotlb capable devices
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 02/21] iommu/vt-d: use correct domain id to flush virtual machine domains
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 03/21] iommu/vt-d: introduce helper functions to improve code readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 06/21] iommu/vt-d: fix possible invalid memory access caused by free_dmar_iommu()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 10/21] iommu/vt-d: simplify intel_unmap_sg() and kill duplicated code
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 08/21] iommu/VT-d: simplify include/linux/dmar.h
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 13/21] iommu/vt-d: fix bug in computing domain's iommu_snooping flag
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 12/21] iommu/vt-d: introduce helper function iova_size() to improve code readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 09/21] iommu/vt-d: change iommu_enable/disable_translation to return void
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 11/21] iommu/vt-d: introduce helper domain_pfn_within_range() to simplify code
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 14/21] IOMMU/vt-d: introduce helper function dmar_walk_resources()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 15/21] iommu/vt-d: dynamically allocate and free seq_id for DMAR units
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 17/21] iommu/vt-d: search _DSM method for DMAR hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 16/21] iommu/vt-d: implement DMAR unit hotplug framework
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 19/21] iommu/vt-d: enhance error recovery in function intel_enable_irq_remapping()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 20/21] iommu/vt-d: enhance intel-iommu driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 21/21] pci, ACPI, iommu: enhance pci_root to support DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 18/21] iommu/vt-d: enhance intel_irq_remapping driver to support DMAR unit hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 07/21] iommu/vt-d: avoid freeing virtual machine domain in free_dmar_iommu()
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 04/21] iommu/vt-d: introduce helper functions to make code symmetric for readability
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 05/21] iommu/vt-d: only dynamically allocate domain id for virtual domains
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- [Patch Part3 V2 00/21] Enable support of Intel DMAR device hotplug
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: Clarification regarding USB Data Card (Dongle) enumeration in Linux udev
- From: "Suresh Kumar N." <suri.injun@xxxxxxxxx>
- Re: Clarification regarding USB Data Card (Dongle) enumeration in Linux udev
- From: Greg KH <greg@xxxxxxxxx>
- Re: Clarification regarding USB Data Card (Dongle) enumeration in Linux udev
- From: "Suresh Kumar N." <suri.injun@xxxxxxxxx>
- Re: Clarification regarding USB Data Card (Dongle) enumeration in Linux udev
- From: Greg KH <greg@xxxxxxxxx>
- Clarification regarding USB Data Card (Dongle) enumeration in Linux udev
- From: "Suresh Kumar N." <suri.injun@xxxxxxxxx>
- Re: Fn keys on Dell Latitude E6440
- From: Pali Rohár <pali.rohar@xxxxxxxxx>
- Fn keys on Dell Latitude E6440
- From: Pali Rohár <pali.rohar@xxxxxxxxx>
- Re: system hang
- From: "greg@xxxxxxxxx" <greg@xxxxxxxxx>
- Re: system hang
- From: Willy Tarreau <w@xxxxxx>
- RE: system hang
- From: Narasimharao Bolisetti <narasimharao.b@xxxxxxx>
- system hang
- From: narasimharo bolisetti <nrbolisetti@xxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatxjain@xxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatxjain@xxxxxxxxx>
- Re: /dev entry of USB device not disappearing after detach
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: /dev entry of USB device not disappearing after detach
- From: Valentina Manea <valentina.manea.m@xxxxxxxxx>
- Re: /dev entry of USB device not disappearing after detach
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: /dev entry of USB device not disappearing after detach
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- /dev entry of USB device not disappearing after detach
- From: Valentina Manea <valentina.manea.m@xxxxxxxxx>
- Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
- From: "H. Peter Anvin" <hpa@xxxxxxxxx>
- Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- RE: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
- From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
- Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: question on udev device naming before root is mounted
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- question on udev device naming before root is mounted
- From: David Avery <David.Avery@xxxxxxxxxxxxxxx>
- Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
- From: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
- Re: Reordered network interface names
- From: Arkadiusz Bubała <arkadiusz.bubala@xxxxxxxxxx>
- Reordered network interface names
- From: Arkadiusz Bubała <arkadiusz.bubala@xxxxxxxxxx>
- Re: udev 95-keyboard-force-release.rules patch
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: udev 95-keyboard-force-release.rules patch
- From: Aleksander Kowalski <aleksander.kowalski.1@xxxxxxxxx>
- Re: udev 95-keyboard-force-release.rules patch
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: udev: Please add keymap for HP Chromebook 14 (Falco)
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: udev: Please add keymap for HP Chromebook 14 (Falco)
- From: Stefan Nagy <public@xxxxxxxxxxxxxx>
- Re: udev: Please add keymap for HP Chromebook 14 (Falco)
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- [PATCH] README: typo fixes
- From: "Thomas H.P. Andersen" <phomes@xxxxxxxxx>
- [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
- From: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx>
- Re: udev: attributes rules to identical devices
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: udev: attributes rules to identical devices
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- udev: attributes rules to identical devices
- From: Theo <teo.wolf@xxxxxxx>
- Re: [PATCH] prefer vertical lists rather than horizontal
- From: Kay Sievers <kay@xxxxxxxx>
- [PATCH] prefer vertical lists rather than horizontal
- From: Sami Kerola <kerolasa@xxxxxx>
- Re: Can udev manage /sys/class/leds
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Can udev manage /sys/class/leds
- From: christophe leroy <christophe.leroy@xxxxxx>
- Re: udev 95-keyboard-force-release.rules patch
- From: Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
- udev 95-keyboard-force-release.rules patch
- From: Aleksander Kowalski <aleksander.kowalski.1@xxxxxxxxx>
- Re: synaptics: PS/2 touchpad isn't detected if a keyboard key is held down on boot
- From: Andrey Moiseev <o2g.org.ru@xxxxxxxxx>
- Re: synaptics: PS/2 touchpad isn't detected if a keyboard key is held down on boot
- From: Andrey Moiseev <o2g.org.ru@xxxxxxxxx>
- Re: synaptics: PS/2 touchpad isn't detected if a keyboard key is held down on boot
- From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
- Re: synaptics: PS/2 touchpad isn't detected if a keyboard key is held down on boot
- From: Andrey Moiseev <o2g.org.ru@xxxxxxxxx>
- Re: synaptics: PS/2 touchpad isn't detected if a keyboard key is held down on boot
- From: Andrey Moiseev <o2g.org.ru@xxxxxxxxx>
- RE: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- RE: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Guenter Roeck <linux@xxxxxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Re: [RFC PATCH 0/4] Allow Link state changes for Hot-Plug
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Re: [RFC PATCH 0/4] Allow Link state changes for Hot-Plug
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- [RFC PATCH 4/4] pciehp: Introduce hotplug_lock to serialize HP events
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- [RFC PATCH 3/4] pciehp: Ensure very fast hotplug events are also processed.
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- [RFC PATCH 2/4] pciehp: Use link change notifications for hot-plug and, removal
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- [RFC PATCH 1/4] pciehp: Make check_link_active() non-static
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- [RFC PATCH 0/4] Allow Link state changes for Hot-Plug
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- Re: How important is the MBR partition offset of grub-mkrescue ?
- From: "Thomas Schmitt" <scdbackup@xxxxxxx>
- Re: How important is the MBR partition offset of grub-mkrescue ?
- From: Andrey Borzenkov <arvidjaar@xxxxxxxxx>
- Re: Enhancing pciehp
- From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
- RE: Enhancing pciehp (was: pcielw An alternate pcie hotplug driver)
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: Fn Keys wrong function
- From: Guillermo D <guillermod84@xxxxxxxxx>
- pre-configuring PCIe switch
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: Fn Keys wrong function
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Fn Keys wrong function
- From: Guillermo Dominguez Duarte <guillermod84@xxxxxxxxx>
- RE: Difference between hot-plug on PCIe rootport vs downstream port
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: Difference between hot-plug on PCIe rootport vs downstream port
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Difference between hot-plug on PCIe rootport vs downstream port
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: Enhancing pciehp
- From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
- Re: Enhancing pciehp (was: pcielw An alternate pcie hotplug driver)
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- Enhancing pciehp (was: pcielw An alternate pcie hotplug driver)
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: udev and w1/wire
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- udev and w1/wire
- From: Max Hille <max@xxxxxxx>
- Re: pciehp & other hot-plug drivers (shpc etc..)
- From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
- RE: [PCIe spec question] How to get PCI express link up / link down notifications?
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- RE: [PCIe spec question] How to get PCI express link up / link down notifications?
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: [PCIe spec question] How to get PCI express link up / link down notifications?
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- [PCIe spec question] How to get PCI express link up / link down notifications?
- From: Rajat Jain <rajatjain@xxxxxxxxxxx>
- Re: pciehp & other hot-plug drivers (shpc etc..)
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- Re: Forking pciehp
- From: "gregkh@xxxxxxxxxxxxxxxxxxx" <gregkh@xxxxxxxxxxxxxxxxxxx>
- Forking pciehp
- From: Shiro Itou 伊東 <shiro.itou@xxxxxxxxxxx>
- Re: pciehp & other hot-plug drivers (shpc etc..)
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- pciehp & other hot-plug drivers (shpc etc..)
- From: Rajat Jain <rajatjain.linux@xxxxxxxxx>
- Re: toshiba Satellite P75-A keymap
- From: Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
- toshiba Satellite P75-A keymap
- From: Guillermo Dominguez Duarte <guillermod84@xxxxxxxxx>
- Re: loading 'acpiphp' fails after the system boot?
- From: "gregkh@xxxxxxxxxxxxxxxxxxx" <gregkh@xxxxxxxxxxxxxxxxxxx>
- RE: loading 'acpiphp' fails after the system boot?
- From: Shiro Itou 伊東 <shiro.itou@xxxxxxxxxxx>
- Re: udevadm trigger --type=devices calling ifup on all devices, even devices with ONBOOT=no
- From: Kay Sievers <kay@xxxxxxxx>
- udevadm trigger --type=devices calling ifup on all devices, even devices with ONBOOT=no
- From: Assaf Muller <amuller@xxxxxxxxxx>
- Re: loading 'acpiphp' fails after the system boot?
- From: "gregkh@xxxxxxxxxxxxxxxxxxx" <gregkh@xxxxxxxxxxxxxxxxxxx>
- loading 'acpiphp' fails after the system boot?
- From: Shiro Itou 伊東 <shiro.itou@xxxxxxxxxxx>
- Re: Logitech iTouch keyboard broken scan codes
- From: Götz Christ <goetzchrist@xxxxxxxxx>
- Re: Logitech iTouch USB keyboard scan codes
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: Logitech iTouch keyboard broken scan codes
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: eMachines E725 keymap
- From: Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
- Re: udev: Why non-blocking poll() with blocking recvmsg()?
- From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
- Re: automatic sysfs attribute creation
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- automatic sysfs attribute creation
- From: Alexander Stein <alexander.stein@xxxxxxxxxxxxxxxxxxxxx>
- Re: udev: Why non-blocking poll() with blocking recvmsg()?
- From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
- Re: udev: Why non-blocking poll() with blocking recvmsg()?
- From: Kay Sievers <kay@xxxxxxxx>
- Re: udev: Why non-blocking poll() with blocking recvmsg()?
- From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
- Re: udev: Why non-blocking poll() with blocking recvmsg()?
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- udev: Why non-blocking poll() with blocking recvmsg()?
- From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] udev: fail firmware loading immediately if no search path is defined
- From: Kay Sievers <kay@xxxxxxxx>
- Re: [PATCH] udev: fail firmware loading immediately if no search path is defined
- From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
- [PATCH] udev: fail firmware loading immediately if no search path is defined
- From: Maarten Lankhorst <m.b.lankhorst@xxxxxxxxx>
- Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
- From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
- Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
- From: Bryan Kadzban <bryan@xxxxxxxxxxxxxxxxxxxxx>
- Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
- From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
- Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
- From: Tom Gundersen <teg@xxxxxxx>
- Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
- From: Tom Gundersen <teg@xxxxxxx>
- Re: [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
- From: Maarten Lankhorst <m.b.lankhorst@xxxxxxxxx>
- [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
- From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
- Re: [systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
- From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
- Re: [systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
- From: Kay Sievers <kay@xxxxxxxx>
- Re: Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
- From: Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
- Re: Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
- From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
- Re: Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
- From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
- Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
- From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
- Re: a problem of preparing before cpu hot remove
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- a problem of preparing before cpu hot remove
- From: chenfan <chen.fan.fnst@xxxxxxxxxxxxxx>
- eMachines E725 keymap
- From: Ludvig <enthymeme@xxxxxxxxxxx>
- Ting Stick Udev Support
- From: Tim Sander <tim@xxxxxxxxxxxxxxx>
- media-player-info 21 released
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: media-player-info 19 released
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- media-player-info 19 released
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: media-player-info 18 release
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: media-player-info 18 release
- From: Tom Gundersen <teg@xxxxxxx>
- Re: [systemd-devel] Inhibiting plug and play
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: [systemd-devel] Inhibiting plug and play
- From: Lennart Poettering <lennart@xxxxxxxxxxxxxx>
- Logitech iTouch USB keyboard scan codes
- From: "Albrecht Kolthoff" <kolthoff@xxxxxxx>
- media-player-info 18 release
- From: Martin Pitt <martin.pitt@xxxxxxxxxx>
- Re: Inhibiting plug and play
- From: David Zeuthen <zeuthen@xxxxxxxxx>
- Re: Inhibiting plug and play
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: Inhibiting plug and play
- From: David Zeuthen <zeuthen@xxxxxxxxx>
- Re: Inhibiting plug and play
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Inhibiting plug and play
- From: Phillip Susi <psusi@xxxxxxxxxx>
- Re: Lenovo IdeaPad S206
- From: Steve White <swhite@xxxxxxxxxx>
- RE:
- From: "snowyxx" <snowyxx@xxxxxxx>
- Lenovo IdeaPad S206
- From: Steve White <swhite@xxxxxxxxxx>
- Re:
- From: Tom Gundersen <teg@xxxxxxx>
- [no subject]
- From: "snowyxx" <snowyxx@xxxxxxx>
- Re: [PATCH v3] tools: add static-nodes tool
- From: Tom Gundersen <teg@xxxxxxx>
- Re: [PATCH v3] tools: add static-nodes tool
- From: Kay Sievers <kay@xxxxxxxx>
- Re: [PATCH v3] tools: add static-nodes tool
- From: Lucas De Marchi <lucas.demarchi@xxxxxxxxxxxxxx>
- Re: [PATCH v3] tools: add static-nodes tool
- From: Thomas Bächler <thomas@xxxxxxxxxxxxx>
- Re: [PATCH v2] tools: add static-nodes tool
- From: Tom Gundersen <teg@xxxxxxx>
- [PATCH v3] tools: add static-nodes tool
- From: Tom Gundersen <teg@xxxxxxx>
- Re: [PATCH v2] tools: add static-nodes tool
- From: Lucas De Marchi <lucas.demarchi@xxxxxxxxxxxxxx>
- [PATCH v2] tools: add static-nodes tool
- From: Tom Gundersen <teg@xxxxxxx>
- Re: [PATCH] [WIP]tools: add devname2tmpfile
- From: Dave Reisner <d@xxxxxxxxxxxxxx>
- Re: Disabling device
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Disabling device
- From: Štefan Sakalík <rabbit6440@xxxxxxxxx>
- [PATCH] [RFC] udevd: let tmpfiles create all static nodes
- From: Tom Gundersen <teg@xxxxxxx>
- [PATCH] [WIP]tools: add devname2tmpfile
- From: Tom Gundersen <teg@xxxxxxx>
- [ANNOUNCE] kmod 13
- From: Lucas De Marchi <lucas.demarchi@xxxxxxxxxxxxxx>
- RE: device properties and change events
- From: Keith Pine <kpine@xxxxxxx>
- Re: device properties and change events
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- device properties and change events
- From: Keith Pine <kpine@xxxxxxx>
- Re: Dell Latitude E6530 keymap
- From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
- Dell Latitude E6530 keymap
- From: Stephen Gildea <stepheng+linux@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Myron Stowe <mstowe@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Myron Stowe <mstowe@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Robert Hancock <hancockrwd@xxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Robert Hancock <hancockrwd@xxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Robert Hancock <hancockrwd@xxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Alex Williamson <alex.williamson@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Robert Brown <rj@xxxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Bjørn Mork <bjorn@xxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Alex Williamson <alex.williamson@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Bjørn Mork <bjorn@xxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Alex Williamson <alex.williamson@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Alex Williamson <alex.williamson@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Alex Williamson <alex.williamson@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Don Dutile <ddutile@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Alex Williamson <alex.williamson@xxxxxxxxxx>
- Re: [PATCH] udevadm-info: Don't access sysfs 'resource<N>' files
- From: Kay Sievers <kay@xxxxxxxx>
[Index of Archives]
[Linux Media]
[Samba]
[USB]
[Yosemite]
