[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <05f0dc06-5a16-fba7-a256-b1d9dea989de@suse.com>
Date: Wed, 26 Jul 2023 13:16:28 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Greg KH <gregkh@...uxfoundation.org>,
liulongfang <liulongfang@...wei.com>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB:bugfix a controller halt error
On 26.07.23 09:18, Greg KH wrote:
> On Wed, Jul 26, 2023 at 02:44:01PM +0800, liulongfang wrote:
>> This is a test conducted under a special test scenario.
>> ECC memory errors are caused by some test tools.
So we are looking at a corner case here.
I think we need to step back, get an overview. And I would
like to apologize for not being entirely helpful.
I see a theoretical possibility here of what is going wrong
and an extremely theoretical bug, but it would be very good
if you could describe your test setup.
So. You are inducing simulated memory errors.
For this scenario to make any sense your failure must be
1. temporary - that is you have detected memory corruption but the RAM cell is not broken
2. unrecoverable - that is we have lost data
3. locateable - that is you know it hit the buffer of this operation and only it
Am I correct so far?
Furthermore your system reports the error to the HC, so that in last
consequence the transfer fails. Right?
> What memory is failing, and why does just this single check matter in
> the whole kernel?
The difference here is that we are deliberately ignoring errors.
> If hardware is broken, and failing, it's not the job of the kernel to
> protect against that, is it? Shouldn't the ECC memory controller have
> properly notified the kernel of the fault
Definitely it should. But this whole discussion makes only sense
if exactly that happens.
> and reset the machine because
> it is now in an undetermined state?
No. It is not in an undetermined state if your detection logic is good enough.
Regards
Oliver
Powered by blists - more mailing lists