On 01/07/16 11:44, Chris Wilson wrote:
>
> Now I feel silly. Looking at the .s, there is no difference with the
> addition of the barrier to clflush_cache_range(). And sure enough
> letting the test run for longer, we see a failure. I fell for a placebo.
>
> The failing assertion is always on the
tice that; I don't know if this is a compiler failure to do an
obvious hoisting (which should then be merged with the other load) or a
consequence of the volatile. It might be useful to report this to the
gcc bugzilla to let them look at it.
Either way, the diff looks good and you can add m
On 01/07/16 14:29, H. Peter Anvin wrote:
>
> I would be very interested in knowing if replacing the final clflushopt
> with a clflush would resolve your problems (in which case the last mb()
> shouldn't be necessary either.)
>
Nevermind. CLFLUSH is not ordered with regards
On 01/07/16 14:32, H. Peter Anvin wrote:
>
> Nevermind. CLFLUSH is not ordered with regards to CLFLUSHOPT to the
> same cache line.
>
*Except* to the same cache line, dammit.
-hpa
On January 11, 2016 3:28:01 AM PST, Chris Wilson
wrote:
>On Sat, Jan 09, 2016 at 02:36:03PM -0800, Andy Lutomirski wrote:
>> On Sat, Jan 9, 2016 at 12:01 AM, Chris Wilson
> wrote:
>> > On Thu, Jan 07, 2016 at 02:32:23PM -0800, H. Peter Anvin wrote:
>> >> On 01/
On 06/19/2014 01:01 PM, Greg KH wrote:
> On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 19, 2014 at 7:00 PM, Greg KH
>> wrote:
>> + BUG_ON(f1->context != f2->context);
>
> Nice, you just crashed the kernel, making it impossible to debug or
> reco
gt;
>> Cc: David Airlie
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: H Peter Anvin
>> Cc: Ingo Molnar
>> Cc: Thomas Gleixner
>
> Picked to my topic/core-stuff drm branch so it doesn't get lost.
> -Daniel
>
Does this mean you're picking this up, or do you want me to put it into
-tip?
-hpa
On January 22, 2024 8:32:22 AM PST, Dave Hansen wrote:
>On 1/9/24 00:40, Alexey Makhalov wrote:
>> +#ifdef CONFIG_INTEL_TDX_GUEST
>> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
>> + struct tdx_module_args *args)
>> +{
>> +if (!hypervisor_is_type(X86_HYP
On January 22, 2024 4:04:33 PM PST, Alexey Makhalov
wrote:
>
>
>On 1/22/24 10:28 AM, H. Peter Anvin wrote:
>> On January 22, 2024 8:32:22 AM PST, Dave Hansen
>> wrote:
>>> On 1/9/24 00:40, Alexey Makhalov wrote:
>>>> +#ifdef CONFIG_INTEL_TDX_GUES
We should clear this bit presumably on switching either from or to 512-char
mode, since the bit doesn't really make sense either way.
Dave Airlie wrote:
>From: Dave Airlie
>
>When we switch from 256->512 byte font rendering mode, it means the
>current contents of the screen is being reinterpre
Thu, Jan 24, 2013 at 3:20 PM, H. Peter Anvin wrote:
>> We should clear this bit presumably on switching either from or to
>512-char mode, since the bit doesn't really make sense either way.
>
>Yeah the only problem going from 512-char is that chars above 256 will
>morph into gar
It would be nice to support more than 512 characters when using a graphical
console. We should be able to support up to 2048 at least.
Dave Airlie wrote:
>On Thu, Jan 24, 2013 at 10:18 PM, H. Peter Anvin wrote:
>> The characters will morph anyway, it is just a matter off ha
t leave it alone. Maybe add a comment.
> The change is just making things more confusing.
>
Indeed, but...
Daniel: can you guys clean this up or can we just remove the #if 0 clause?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I wo
The problem is that the code will be broken, and so it makes no sense. The #if
0 is really confusing.
Daniel Vetter wrote:
>On Thu, Mar 07, 2013 at 10:09:26PM -0800, H. Peter Anvin wrote:
>> On 03/07/2013 09:28 PM, Tejun Heo wrote:
>> > On Thu, Mar 7, 2013 at 9:27 PM,
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
In addition to the architecture dependency, this is really undesirable
because MTRRs are a limited resource, whereas page table attributes are not.
Furthermore
Why do you care about performance when PAT is disabled?
Brice Goglin wrote:
>Le 21/06/2013 07:00, H. Peter Anvin a écrit :
>> An awful lot of drivers, mostly DRI drivers, are still mucking with
>> MTRRs directly as opposed to using ioremap_wc() or similar
>interfaces.
>
On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
> On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> Why do you care about performance when PAT is disabled?
>
> It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
> nobody ever took the pain to tra
On 06/23/2013 01:30 PM, Dave Airlie wrote:
Why do you care about performance when PAT is disabled?
>
> breaking old boxes just because, is just going to get reverted when I
> get the first regression report that you broke old boxes.
>
Not "just because", but *if* the choice is between break
On 06/23/2013 01:54 PM, Dave Airlie wrote:
>>> breaking old boxes just because, is just going to get reverted when I
>>> get the first regression report that you broke old boxes.
>>>
>>
>> Not "just because", but *if* the choice is between breaking old boxes
>> and breaking new boxes I'll take the
On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>
> And as far as I could find from Intel's not-that-complete public
> "specification updates", we are applying the errata workaround to a few more
> processors than strictly required, but since I have no idea how to write a
> test case, I
The aliasing doesn't matter for Linux because we map the high and low half the
same.
Henrique de Moraes Holschuh wrote:
>On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>> >
>> > And as far as I could fin
On 07/04/2013 05:25 AM, David Herrmann wrote:
- What FB formats are common on x86 that we should add to SIMPLEFB_FORMATS?
(other than ARGB/XRGB32)
The common pixel formats on x86 are:
- Palettized 4-bit planar (bigendian, i.e. MSB to the left)
- Palettized 8-bit packed (one byte per pixe
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
>
> First of all, I bisected between v2.6.37-rc2..f005fe12b90c which where
> only a couple of patches and merged v2.6.38-rc4 in at every step. There
> was no failure found.
> Then I tried this again, but this time I merged v2.6.38-rc5 at every
> step and
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 08:46:09AM +0200, Ingo Molnar wrote:
>> Could you please send the before/after bootlog (in particular all memory
>> init
>> messages included) and your .config?
>>
>> before: f005fe12b90c: x86-64: Move out cleanup higmap [_br
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>> -addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>> +addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
>
> Btw, while looking at this code I wond
On 04/13/2011 02:59 PM, Yinghai Lu wrote:
> On 04/13/2011 02:50 PM, Joerg Roedel wrote:
>> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>>> - addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>>> + addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21)
On 04/13/2011 03:22 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 03:01:10PM -0700, H. Peter Anvin wrote:
>> On 04/13/2011 02:50 PM, Joerg Roedel wrote:
>>> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>>>> - addr = memblock_find_in_range(0, 1
000aff0 (usable)
>
> so looks bios program wrong address to the radon card?
>
Okay, staring at this, it definitely seems toxic to overlay the GART
over memory areas reserved by the BIOS. If I were to guess, I would say
that the problem here seems to be that the kernel thinks it is
y well be a problem that is manifesting itself
in other ways on other systems.
The other thing that this has uncovered is that we already have a bunch
of complete b*llsh*t magic numbers in this path, some of which are
trivially shown to be wrong or at least completely arbitrary, so there
are more issues he
hat already. Not the
> droids.
>
> the num cpu pages is how many CPU pages would be needed to fill the GPU
> GTT, for those crazy cases where CPU pagesize != GPU pagesize.
>
OK, well, something is still weird.
-hpa
--
H. Peter Anvin,
crashes.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 04/15/2011 12:18 PM, Yinghai Lu wrote:
> On 04/15/2011 12:06 PM, Ingo Molnar wrote:
>
>>
>> Joerg, mind submitting it with a changelog that includes everything we
>> learned
>> about this bug and all the Tested-by's in place?
>>
>> Is anyone of the opinion that we should try to revert the all
On 05/23/2011 04:17 PM, Ted Ts'o wrote:
> On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote:
>> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>>>
>>> I really hope there's also a voice that tells you to wait until .42 before
>>> cutting 3.0.0! :-)
>>
>> So I'm toying with 3.0 (
ure-removal-schedule.txt, not
all at once due to some arbitrary milestone.
We have found it works better this way.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
d
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
>
> First of all, I bisected between v2.6.37-rc2..f005fe12b90c which where
> only a couple of patches and merged v2.6.38-rc4 in at every step. There
> was no failure found.
> Then I tried this again, but this time I merged v2.6.38-rc5 at every
> step and
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 08:46:09AM +0200, Ingo Molnar wrote:
>> Could you please send the before/after bootlog (in particular all memory
>> init
>> messages included) and your .config?
>>
>> before: f005fe12b90c: x86-64: Move out cleanup higmap [_br
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>> -addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>> +addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
>
> Btw, while looking at this code I wond
On 04/13/2011 02:59 PM, Yinghai Lu wrote:
> On 04/13/2011 02:50 PM, Joerg Roedel wrote:
>> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>>> - addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>>> + addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21)
On 04/13/2011 03:22 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 03:01:10PM -0700, H. Peter Anvin wrote:
>> On 04/13/2011 02:50 PM, Joerg Roedel wrote:
>>> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>>>> - addr = memblock_find_in_range(0, 1
000aff0 (usable)
>
> so looks bios program wrong address to the radon card?
>
Okay, staring at this, it definitely seems toxic to overlay the GART
over memory areas reserved by the BIOS. If I were to guess, I would say
that the problem here seems to be that the kernel thinks it is
y well be a problem that is manifesting itself
in other ways on other systems.
The other thing that this has uncovered is that we already have a bunch
of complete b*llsh*t magic numbers in this path, some of which are
trivially shown to be wrong or at least completely arbitrary, so there
are more issues he
hat already. Not the
> droids.
>
> the num cpu pages is how many CPU pages would be needed to fill the GPU
> GTT, for those crazy cases where CPU pagesize != GPU pagesize.
>
OK, well, something is still weird.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
crashes.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 04/15/2011 12:18 PM, Yinghai Lu wrote:
> On 04/15/2011 12:06 PM, Ingo Molnar wrote:
>
>>
>> Joerg, mind submitting it with a changelog that includes everything we
>> learned
>> about this bug and all the Tested-by's in place?
>>
>> Is anyone of the opinion that we should try to revert the all
On 05/23/2011 04:17 PM, Ted Ts'o wrote:
> On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote:
>> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>>>
>>> I really hope there's also a voice that tells you to wait until .42 before
>>> cutting 3.0.0! :-)
>>
>> So I'm toying with 3.0 (
eature-removal-schedule.txt, not
all at once due to some arbitrary milestone.
We have found it works better this way.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 02/24/2014 12:19 PM, Borislav Petkov wrote:
> Btw,
>
> I don't know whether the following observation is related or not, but it
> so happens that after resume from suspend-to-disk, I see the booting up
> of the resume kernel on the console but when it is time for the original
> kernel to take o
We should clear this bit presumably on switching either from or to 512-char
mode, since the bit doesn't really make sense either way.
Dave Airlie wrote:
>From: Dave Airlie
>
>When we switch from 256->512 byte font rendering mode, it means the
>current contents of the screen is being reinterpre
Thu, Jan 24, 2013 at 3:20 PM, H. Peter Anvin wrote:
>> We should clear this bit presumably on switching either from or to
>512-char mode, since the bit doesn't really make sense either way.
>
>Yeah the only problem going from 512-char is that chars above 256 will
>morph into gar
It would be nice to support more than 512 characters when using a graphical
console. We should be able to support up to 2048 at least.
Dave Airlie wrote:
>On Thu, Jan 24, 2013 at 10:18 PM, H. Peter Anvin wrote:
>> The characters will morph anyway, it is just a matter off ha
On 07/04/2013 05:25 AM, David Herrmann wrote:
> - What FB formats are common on x86 that we should add to SIMPLEFB_FORMATS?
> (other than ARGB/XRGB32)
The common pixel formats on x86 are:
- Palettized 4-bit planar (bigendian, i.e. MSB to the left)
- Palettized 8-bit packed (one byte per pix
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
In addition to the architecture dependency, this is really undesirable
because MTRRs are a limited resource, whereas page table attributes are not.
Furthermore
Why do you care about performance when PAT is disabled?
Brice Goglin wrote:
>Le 21/06/2013 07:00, H. Peter Anvin a ?crit :
>> An awful lot of drivers, mostly DRI drivers, are still mucking with
>> MTRRs directly as opposed to using ioremap_wc() or similar
>interfaces.
>
On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
> On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> Why do you care about performance when PAT is disabled?
>
> It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
> nobody ever took the pain to tra
On 06/23/2013 01:30 PM, Dave Airlie wrote:
Why do you care about performance when PAT is disabled?
>
> breaking old boxes just because, is just going to get reverted when I
> get the first regression report that you broke old boxes.
>
Not "just because", but *if* the choice is between break
On 06/23/2013 01:54 PM, Dave Airlie wrote:
>>> breaking old boxes just because, is just going to get reverted when I
>>> get the first regression report that you broke old boxes.
>>>
>>
>> Not "just because", but *if* the choice is between breaking old boxes
>> and breaking new boxes I'll take the
On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>
> And as far as I could find from Intel's not-that-complete public
> "specification updates", we are applying the errata workaround to a few more
> processors than strictly required, but since I have no idea how to write a
> test case, I
The aliasing doesn't matter for Linux because we map the high and low half the
same.
Henrique de Moraes Holschuh wrote:
>On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>> >
>> > And as far as I could fin
t leave it alone. Maybe add a comment.
> The change is just making things more confusing.
>
Indeed, but...
Daniel: can you guys clean this up or can we just remove the #if 0 clause?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
The problem is that the code will be broken, and so it makes no sense. The #if
0 is really confusing.
Daniel Vetter wrote:
>On Thu, Mar 07, 2013 at 10:09:26PM -0800, H. Peter Anvin wrote:
>> On 03/07/2013 09:28 PM, Tejun Heo wrote:
>> > On Thu, Mar 7, 2013 at 9:27 PM,
On 2/24/25 14:08, Uros Bizjak wrote:
On Mon, Feb 24, 2025 at 10:56 PM H. Peter Anvin wrote:
On 2/24/25 07:24, Uros Bizjak wrote:
On 23. 02. 25 17:42, Kuan-Wei Chiu wrote:
Refactor parity calculations to use the standard parity8() helper. This
change eliminates redundant implementations
On 2/24/25 07:24, Uros Bizjak wrote:
On 23. 02. 25 17:42, Kuan-Wei Chiu wrote:
Refactor parity calculations to use the standard parity8() helper. This
change eliminates redundant implementations and improves code
efficiency.
The patch improves parity assembly code in bootflag.o from:
58:
On February 24, 2025 2:08:05 PM PST, Uros Bizjak wrote:
>On Mon, Feb 24, 2025 at 10:56 PM H. Peter Anvin wrote:
>>
>> On 2/24/25 07:24, Uros Bizjak wrote:
>> >
>> >
>> > On 23. 02. 25 17:42, Kuan-Wei Chiu wrote:
>> >> Refactor parity c
On February 24, 2025 2:17:29 PM PST, Yury Norov wrote:
>On Mon, Feb 24, 2025 at 01:55:28PM -0800, H. Peter Anvin wrote:
>> On 2/24/25 07:24, Uros Bizjak wrote:
>> >
>> >
>> > On 23. 02. 25 17:42, Kuan-Wei Chiu wrote:
>> > > Refactor parity calcula
On February 25, 2025 1:43:27 PM PST, Andrew Cooper
wrote:
>> Incidentally, in all of this, didn't anyone notice __builtin_parity()?
>
>Yes. It it has done sane for a decade on x86, yet does things such as
>emitting a library call on other architectures.
>
>https://godbolt.org/z/6qG3noebq
>
>~And
On February 25, 2025 2:46:23 PM PST, David Laight
wrote:
>On Mon, 24 Feb 2025 13:55:28 -0800
>"H. Peter Anvin" wrote:
>
>> On 2/24/25 07:24, Uros Bizjak wrote:
>> >
>> >
>> > On 23. 02. 25 17:42, Kuan-Wei Chiu wrote:
>> >> R
On February 24, 2025 5:34:31 AM PST, David Laight
wrote:
>On Mon, 24 Feb 2025 08:09:43 +0100
>Jiri Slaby wrote:
>
>> On 23. 02. 25, 17:42, Kuan-Wei Chiu wrote:
>> > Several parts of the kernel open-code parity calculations using
>> > different methods. Add a generic parity64() helper implemented
On February 24, 2025 5:34:31 AM PST, David Laight
wrote:
>On Mon, 24 Feb 2025 08:09:43 +0100
>Jiri Slaby wrote:
>
>> On 23. 02. 25, 17:42, Kuan-Wei Chiu wrote:
>> > Several parts of the kernel open-code parity calculations using
>> > different methods. Add a generic parity64() helper implemented
On February 27, 2025 1:57:41 PM PST, David Laight
wrote:
>On Thu, 27 Feb 2025 13:05:29 -0500
>Yury Norov wrote:
>
>> On Wed, Feb 26, 2025 at 10:29:11PM +, David Laight wrote:
>> > On Mon, 24 Feb 2025 14:27:03 -0500
>> > Yury Norov wrote:
>> >
>> > > +#define parity(val)
On March 7, 2025 11:30:08 AM PST, Yury Norov wrote:
>On Fri, Mar 07, 2025 at 04:14:34AM -0800, H. Peter Anvin wrote:
>> On March 7, 2025 4:13:26 AM PST, Ingo Molnar wrote:
>> >
>> >* Jiri Slaby wrote:
>> >
>> >> On 07. 03. 25, 12:38, Ingo Mo
On March 7, 2025 4:13:26 AM PST, Ingo Molnar wrote:
>
>* Jiri Slaby wrote:
>
>> On 07. 03. 25, 12:38, Ingo Molnar wrote:
>> >
>> > * Jiri Slaby wrote:
>> >
>> > > On 06. 03. 25, 17:25, Kuan-Wei Chiu wrote:
>> > > > Change return type to bool for better clarity. Update the kernel doc
>> > > > c
On March 6, 2025 8:25:25 AM PST, Kuan-Wei Chiu wrote:
>Several parts of the kernel contain redundant implementations of parity
>calculations for 16/32/64-bit values. Introduces generic
>parity16/32/64() helpers in bitops.h, providing a standardized
>and optimized implementation.
>
>Subsequent pat
On March 6, 2025 8:25:25 AM PST, Kuan-Wei Chiu wrote:
>Several parts of the kernel contain redundant implementations of parity
>calculations for 16/32/64-bit values. Introduces generic
>parity16/32/64() helpers in bitops.h, providing a standardized
>and optimized implementation.
>
>Subsequent pat
On March 7, 2025 11:53:10 AM PST, David Laight
wrote:
>On Fri, 07 Mar 2025 11:30:35 -0800
>"H. Peter Anvin" wrote:
>
>> On March 7, 2025 10:49:56 AM PST, Andrew Cooper
>> wrote:
>> >> (int)true most definitely is guaranteed to be 1.
>&
On March 7, 2025 10:49:56 AM PST, Andrew Cooper
wrote:
>> (int)true most definitely is guaranteed to be 1.
>
>That's not technically correct any more.
>
>GCC has introduced hardened bools that intentionally have bit patterns
>other than 0 and 1.
>
>https://gcc.gnu.org/gcc-14/changes.html
>
>~Andr
On March 7, 2025 11:36:43 AM PST, David Laight
wrote:
>On Fri, 7 Mar 2025 12:42:41 +0100
>Jiri Slaby wrote:
>
>> On 07. 03. 25, 12:38, Ingo Molnar wrote:
>> >
>> > * Jiri Slaby wrote:
>> >
>> >> On 06. 03. 25, 17:25, Kuan-Wei Chiu wrote:
>> >>> Change return type to bool for better clarit
On March 9, 2025 8:48:26 AM PDT, Kuan-Wei Chiu wrote:
>On Fri, Mar 07, 2025 at 12:07:02PM -0800, H. Peter Anvin wrote:
>> On March 7, 2025 11:53:10 AM PST, David Laight
>> wrote:
>> >On Fri, 07 Mar 2025 11:30:35 -0800
>> >"H. Peter Anvin" wrote:
On March 11, 2025 3:01:30 PM PDT, Yury Norov wrote:
>On Sun, Mar 09, 2025 at 11:48:26PM +0800, Kuan-Wei Chiu wrote:
>> On Fri, Mar 07, 2025 at 12:07:02PM -0800, H. Peter Anvin wrote:
>> > On March 7, 2025 11:53:10 AM PST, David Laight
>> > wrote:
>> >
On March 13, 2025 9:24:38 AM PDT, Yury Norov wrote:
>On Wed, Mar 12, 2025 at 05:09:16PM -0700, H. Peter Anvin wrote:
>> On March 12, 2025 4:56:31 PM PDT, Jacob Keller
>> wrote:
>
>[...]
>
>> >This is really a question of whether you expect odd or even parity
On March 12, 2025 4:56:31 PM PDT, Jacob Keller wrote:
>
>
>On 3/7/2025 11:36 AM, David Laight wrote:
>> On Fri, 7 Mar 2025 12:42:41 +0100
>> Jiri Slaby wrote:
>>
>>> On 07. 03. 25, 12:38, Ingo Molnar wrote:
* Jiri Slaby wrote:
> On 06. 03. 25, 17:25, Kuan-Wei Chiu wrote:
On March 14, 2025 12:06:04 PM PDT, David Laight
wrote:
>On Thu, 13 Mar 2025 14:09:24 -0700
>Jacob Keller wrote:
>
>> On 3/13/2025 9:36 AM, H. Peter Anvin wrote:
>> > On March 13, 2025 9:24:38 AM PDT, Yury Norov wrote:
>> >
>> >> On Wed, Mar 12, 2
r 11, 2025 at 03:24:14PM -0700, H. Peter Anvin wrote:
>> > > > On March 11, 2025 3:01:30 PM PDT, Yury Norov
>> > > > wrote:
>> > > > >On Sun, Mar 09, 2025 at 11:48:26PM +0800, Kuan-Wei Chiu wrote:
>> > > > >> On Fri, Mar 07, 20
see BIOS output.
Add support for the 4321: device number in addition to the
1234: one.
Signed-off-by: H. Peter Anvin (Intel)
---
drivers/gpu/drm/tiny/bochs.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index
83 matches
Mail list logo
