Re: Interpreting /sys/block//{,}/discard_alignment

On Thu, Jan 10, 2019 at 7:04 PM Martin K. Petersen wrote: > James, > > > Q1 - I'm hoping you can clarify how this should be interpreted. > > > > I originally took this to mean the number of bytes into the first > > discard_granularity block that the partition resides at. i.e. If > >

Interpreting /sys/block//{,}/discard_alignment

https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-block Describes discard_alignment as: "Devices that support discard functionality may internally allocate space in units that are bigger than the exported logical block size. The discard_alignment parameter indicates how many bytes the

Re: Avoid speculative indirect calls in kernel

On Fri, Jan 5, 2018 at 5:40 AM, Woodhouse, David <d...@amazon.co.uk> wrote: > On Thu, 2018-01-04 at 21:01 -0500, james harvey wrote: >> >> >> I understand the GCC patches being discussed will fix the >> vulnerability because newly compiled kernels will be compiled

Re: Avoid speculative indirect calls in kernel

On Fri, Jan 5, 2018 at 5:40 AM, Woodhouse, David wrote: > On Thu, 2018-01-04 at 21:01 -0500, james harvey wrote: >> >> >> I understand the GCC patches being discussed will fix the >> vulnerability because newly compiled kernels will be compiled with a >> GC

Re: Avoid speculative indirect calls in kernel

On Wed, Jan 3, 2018 at 7:19 PM, Jiri Kosina wrote: > On Wed, 3 Jan 2018, Andi Kleen wrote: > >> > It should be a CPU_BUG bit as we have for the other mess. And that can be >> > used for patching. >> >> It has to be done at compile time because it requires a compiler option. > >

Re: Avoid speculative indirect calls in kernel

On Wed, Jan 3, 2018 at 7:19 PM, Jiri Kosina wrote: > On Wed, 3 Jan 2018, Andi Kleen wrote: > >> > It should be a CPU_BUG bit as we have for the other mess. And that can be >> > used for patching. >> >> It has to be done at compile time because it requires a compiler option. > > If gcc anotates

Re: Bricked x86 CPU with software?

On Thu, Jan 4, 2018 at 4:00 PM, Tim Mouraveiko wrote: > Pavel, > > As I mentioned before, I repeatedly and fully power-cycled the motherboard > and reset BIOS > and etc. It made no difference. I can see that the processor was not drawing > any power. The > software code

Re: Bricked x86 CPU with software?

On Thu, Jan 4, 2018 at 4:00 PM, Tim Mouraveiko wrote: > Pavel, > > As I mentioned before, I repeatedly and fully power-cycled the motherboard > and reset BIOS > and etc. It made no difference. I can see that the processor was not drawing > any power. The > software code behaved in a similar

Re: Who reordered my disks (probably v4.8-rc1 problem)

On Sun, Aug 14, 2016 at 5:09 AM, Pavel Machek wrote: >> Use static (persistent) naming instead, /dev/disk/by-label, >> /dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel >> and /dev/disk/by-partuuid > > Explain that to my bootloader. Kernel needs root= on a

Re: Who reordered my disks (probably v4.8-rc1 problem)

On Sun, Aug 14, 2016 at 5:09 AM, Pavel Machek wrote: >> Use static (persistent) naming instead, /dev/disk/by-label, >> /dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel >> and /dev/disk/by-partuuid > > Explain that to my bootloader. Kernel needs root= on a command line. It

Re: Who reordered my disks (probably v4.8-rc1 problem)

Use static (persistent) naming instead, /dev/disk/by-label, /dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel and /dev/disk/by-partuuid As you found, /dev/sdX bus names are assigned in the order they are added, which for some time has not been guaranteed to remain consistent

Re: Who reordered my disks (probably v4.8-rc1 problem)

Use static (persistent) naming instead, /dev/disk/by-label, /dev/disk/by-id, /dev/disk/by-uuid, and if gpt /dev/disk/by-partlabel and /dev/disk/by-partuuid As you found, /dev/sdX bus names are assigned in the order they are added, which for some time has not been guaranteed to remain consistent

Re: Kernel panic - Fails to load BIOS-E820 memory map booted through iPXE, uses BIOS-88

On Mon, Aug 8, 2016 at 8:33 PM, james harvey <jamespharve...@gmail.com> wrote: > <<< How does booting through iPXE disrupt the BIOS E820 map? >>> > > Booting 4.6.4 from the Arch 2016.08.01 ISO on a DVD properly sees > 64GB. (See quote 1.) > > Booting the

Re: Kernel panic - Fails to load BIOS-E820 memory map booted through iPXE, uses BIOS-88

On Mon, Aug 8, 2016 at 8:33 PM, james harvey wrote: > <<< How does booting through iPXE disrupt the BIOS E820 map? >>> > > Booting 4.6.4 from the Arch 2016.08.01 ISO on a DVD properly sees > 64GB. (See quote 1.) > > Booting the same ISO throug

Kernel panic - Fails to load BIOS-E820 memory map booted through iPXE, uses BIOS-88

<<< How does booting through iPXE disrupt the BIOS E820 map? >>> Booting 4.6.4 from the Arch 2016.08.01 ISO on a DVD properly sees 64GB. (See quote 1.) Booting the same ISO through iPXE only sees about 50*M*B usable, and the detected memory map sections are reported as "BIOS-88" rather than

Kernel panic - Fails to load BIOS-E820 memory map booted through iPXE, uses BIOS-88

<<< How does booting through iPXE disrupt the BIOS E820 map? >>> Booting 4.6.4 from the Arch 2016.08.01 ISO on a DVD properly sees 64GB. (See quote 1.) Booting the same ISO through iPXE only sees about 50*M*B usable, and the detected memory map sections are reported as "BIOS-88" rather than

Drawback to intel-rng no_fwh_detect option, if firmware space is locked read-only

I know the error message says I can try using the "no_fwh_detect" option. So, I am not asking how to fix this error. I am asking what it means, and what the difference is if the module would load with the firmware space not locked read only, versus it loading locked but with the no_fwh_detect

Drawback to intel-rng no_fwh_detect option, if firmware space is locked read-only

I know the error message says I can try using the "no_fwh_detect" option. So, I am not asking how to fix this error. I am asking what it means, and what the difference is if the module would load with the firmware space not locked read only, versus it loading locked but with the no_fwh_detect