Arnd,
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
> indications that 486 have no users either on recent kernels.
> There is still the Vortex86 family of SoCs, and the oldest of those were
> 486SX-class, but all the modern ones are 586-class.
I actively use the i486DX syst
Christoph,
in the 4.17 cycle you submitted the patch "x86/dma: Use DMA-direct".
This causes the VGA video on my laptop to stop working, but the system
continues to be up and functioning. Video works until about 3/4 the
way through boot, when I think it is loading a video driver, and then
video ha
I bisected a bug than manifests itself on 32-bit i386 architectures to
commit 4f9007359bcd28bc83c63cb9af38d8b2c8c1670d for long term kernel
3.16.61. It appears as one of two cases, varying by cpu architecture.
All of them fail with an error message variation of "systemd[1]:
Assertion 'clock_gettim
Ben, please backport Thomas Gleixner's patch to the 3.16 series.
commit ef1d4deab953ecb1dfcf9f167043bda8b3f14a11
Author: Thomas Gleixner
Date: Thu Aug 31 20:08:16 2017 +0200
x86/eisa: Add missing include
The seperation of the EISA init missed to include linux/io.h which breaks
the
I will also complain. I use the 32 bit x86 environment regularly for
testing. I have found several bugs and worked with upstream developers
to create fixes.
The developers never said anything like "this is a waste of time
because it was found on 32 bit". Instead, they were universally
supportive.
>
> This shouldn't be necessary; for systems that don't have virtualization
> extensions, the comment explains why setting X86_FEATURE_VMMCALL is safe.
>
> But it is also wrong, because you can run a 32-bit kernel as a guest on
> a 64-bit processor, and then it should set X86_FEATURE_VMMCALL becaus
Andi,
I have a K6 regression testing system. I think my K6 is a revision
C, but I probably can get an earlier cpu (with the bug) to test on.
Do you have any specific tests you would want me to do on the affected cpu?
- Matthew Whitehead
Christoph,
that patch fixed the panic. Thank you for the fix. Please submit
them to the netdev mailing list.
- Matthew
Christoph,
I bisected the following kernel panic to the patch "PCI: Remove NULL
device handling from PCI DMA API". It seems we
still need NULL checking for some older drivers, in my case the 3c59x
driver for PCI/EISA cards.
I am pretty sure the panic arises in the driver here
(drivers/net/ethern
Thomas and Steven,
I am running the 4.16 kernel and I found some odd behavior in sar.
It shows zero usage time in ALL categories.
12:12:36CPU %user %nice %system %iowait%steal %idle
12:34:10all 0.00 0.00 0.00 0.00 0.00 0.00
12:58:
On Sat, Feb 17, 2018 at 4:16 PM, Pavel Machek wrote:
> Hi!
>
>> > BTW... I'd really like to have a database of machine, kernel version,
>> > cpuinfo, config... So that questions like "what is the latest kernel
>> > that is known to be running on this hardware" and "what config should
>> > I start
Andy
On Fri, Feb 16, 2018 at 9:17 AM, Andy Shevchenko
wrote:
> On Thu, Feb 15, 2018 at 6:54 PM, Matthew Whitehead
> wrote:
>> Several i586-class cpus supporting this instruction are missing from
>> the X86_CMPXCHG64 config group.
>
> What about Intel Quark? MinuteIA core which is currently set a
>
> BTW... I'd really like to have a database of machine, kernel version,
> cpuinfo, config... So that questions like "what is the latest kernel
> that is known to be running on this hardware" and "what config should
> I start from".
>
> For example, I have nokia N810 here. It was supported by Linu
On Tue, Feb 13, 2018 at 4:37 PM, Kees Cook wrote:
> On Tue, Feb 13, 2018 at 8:57 AM, tedheadster wrote:
>> Changing X86_32_LAZY_GS to 'y' does not cause the kernel to hang.
>>
>>> On Tue, Feb 13, 2018 at 11:40:17AM -0500, tedheadster wrote:
>>>>
> On Tue, Feb 13, 2018 at 11:40:17AM -0500, tedheadster wrote:
>> in your patch "x86: make lazy %gs optional on x86_32" were you able
>> to test it on really old processors? In 4.16.0-rc1, X86_32_LAZY_GS got
>> toggled from 'y' to 'n' in m
Kees,
I have a question about this patch. When I configure a kernel for
ARCH=i386 it sets these Kconfig variables this way:
HAVE_CC_STACKPROTECTOR=y
CC_STACKPROTECTOR_AUTO=y
CC_STACKPROTECTOR_NONE=n
CC_STACKPROTECTOR_REGULAR=n
CC_STACKPROTECTOR_STRONG=n
It seems to me that at least _one_ of th
On Thu, Feb 8, 2018 at 12:02 PM, David Laight wrote:
> From: Arnd Bergmann
>> Sent: 08 February 2018 15:23
> ...
>> The Winchip is what eventually turned into the VIA Nano, which does
>> have speculative execution, but I don't think the earlier C3 and C7 did,
>> they are much closer to the origina
On Thu, Feb 8, 2018 at 12:02 PM, David Laight wrote:
> From: Arnd Bergmann
>> Sent: 08 February 2018 15:23
> ...
>> The Winchip is what eventually turned into the VIA Nano, which does
>> have speculative execution, but I don't think the earlier C3 and C7 did,
>> they are much closer to the origina
On Tue, Feb 6, 2018 at 3:54 PM, David Woodhouse wrote:
> On Tue, 2018-02-06 at 15:45 -0500, tedheadster wrote:
>>
>> If that is correct (and I might be wrong), then I am up to date and I
>> am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
>&
On Tue, Feb 6, 2018 at 2:24 PM, tedheadster wrote:
> On Tue, Feb 6, 2018 at 2:17 PM, David Woodhouse wrote:
>> On Tue, 2018-02-06 at 11:13 -0800, Guenter Roeck wrote:
>>> On Tue, Feb 06, 2018 at 07:10:27PM +, David Woodhouse wrote:
>>> >
>>> >
>
On Tue, Feb 6, 2018 at 2:17 PM, David Woodhouse wrote:
> On Tue, 2018-02-06 at 11:13 -0800, Guenter Roeck wrote:
>> On Tue, Feb 06, 2018 at 07:10:27PM +, David Woodhouse wrote:
>> >
>> >
>> >
>> > On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote:
>> > >
>> > > .
>> > > >
>> > > >
>>
On Sat, Feb 3, 2018 at 2:37 AM, David Woodhouse wrote:
> On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote:
>> I just tested the 4.15 kernel and it is reporting that my old i486
>> (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
>> Spectre V1, and Spe
I just tested the 4.15 kernel and it is reporting that my old i486
(non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
Spectre V1, and Spectre V2.
I find this to be _unlikely_.
/sys/devices/system/cpu/vulnerabilities/* reports the following:
meltdown: "Vulnerable"
spectre_v1: "V
On Fri, Nov 17, 2017 at 11:14 PM, Randy Dunlap wrote:
> On 10/24/2017 08:14 AM, tedheadster wrote:
>> There has been some change between the 4.13 and 4.14-rc5 kernel. I am
>> using the same userspace with those two kernels. 4.13 successfully
>> reports the UUID using &#x
There has been some change between the 4.13 and 4.14-rc5 kernel. I am
using the same userspace with those two kernels. 4.13 successfully
reports the UUID using 'blkid /dev/sdX' for all cases.
However, when I switch to the 4.14-rc5 kernel, I can successfully
query /dev/sda1 for the UUID. However, /
Thomas
On Mon, Oct 16, 2017 at 6:25 AM, Thomas Gleixner wrote:
> Matthew,
>
> On Sat, 14 Oct 2017, tedheadster wrote:
>
>> I bisected a bug to commit 87e81786b13b267c4355e0d23e33c7e4c08fa63f.
>> On first generation i486 processors it immediately resets the system
&
Thomas,
I bisected a bug to commit 87e81786b13b267c4355e0d23e33c7e4c08fa63f.
On first generation i486 processors it immediately resets the system
after the "Booting the kernel" message.
- Matthew Whitehead
On Sat, Apr 8, 2017 at 6:23 AM, Francois Romieu wrote:
> David Miller :
> [...]
>> One theory is that the interrupt masking isn't working properly
>> and interrupts are still arriving and hitting the NAPI state even
>> when we are actively polling NAPI.
>>
>> And this problem was masked by the lo
I too have old EISA systems that I am using with current kernels.
They're good for testing, having uncovered a kernel bug previously
with Thomas Gleixner:
https://lkml.org/lkml/2013/11/13/424
- Matthew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
29 matches
Mail list logo
