Hi,
Sorry ... long delay.
> > The reason I'm asking is that it's starting to sound like we really
> > ought to be implementing devlink, but we've got a bunch of
> > infrastructure that uses the devcoredump, and it'll take time
> > (significantly so) to change all that...
>
> In devlink world pur
On Fri, 22 May 2020 22:46:07 +0200 Johannes Berg wrote:
> > The irony is you have a problem with a networking device and all the
> > devices your initial set touched are networking. Two of the drivers
> > you touched either have or will soon have devlink health reporters
> > implemented.
>
> Li
On 05/25/2020 02:07 AM, Andy Shevchenko wrote:
On Fri, May 22, 2020 at 04:23:55PM -0700, Steve deRosier wrote:
On Fri, May 22, 2020 at 2:51 PM Luis Chamberlain wrote:
I had to go RTFM re: kernel taints because it has been a very long
time since I looked at them. It had always seemed to me
On Fri, May 22, 2020 at 04:23:55PM -0700, Steve deRosier wrote:
> On Fri, May 22, 2020 at 2:51 PM Luis Chamberlain wrote:
> I had to go RTFM re: kernel taints because it has been a very long
> time since I looked at them. It had always seemed to me that most were
> caused by "kernel-unfriendly" u
On Fri, May 22, 2020 at 04:23:55PM -0700, Steve deRosier wrote:
> Specifically, I don't think we should set a taint flag when a driver
> easily handles a routine firmware crash and is confident that things
> have come up just fine again. In other words, triggering the taint in
> every driver module
On Fri, May 22, 2020 at 2:51 PM Luis Chamberlain wrote:
>
> On Fri, May 22, 2020 at 10:46:07PM +0200, Johannes Berg wrote:
> > FWIW, I still completely disagree on that taint. You (Luis) obviously
> > have been running into a bug in that driver, I doubt the firmware
> > actually managed to wedge t
On Fri, May 22, 2020 at 10:46:07PM +0200, Johannes Berg wrote:
> FWIW, I still completely disagree on that taint. You (Luis) obviously
> have been running into a bug in that driver, I doubt the firmware
> actually managed to wedge the hardware.
This hasn't happened just once, its happed many times
On Fri, May 22, 2020 at 10:17:38AM -0700, Jakub Kicinski wrote:
> On Fri, 22 May 2020 05:20:46 + Luis Chamberlain wrote:
> > > diff --git a/net/core/Makefile b/net/core/Makefile
> > > index 3e2c378e5f31..6f1513781c17 100644
> > > --- a/net/core/Makefile
> > > +++ b/net/core/Makefile
> > > @@ -3
On Fri, 2020-05-22 at 10:17 -0700, Jakub Kicinski wrote:
> > > --- a/net/core/Makefile
> > > +++ b/net/core/Makefile
> > > @@ -31,7 +31,7 @@ obj-$(CONFIG_LWTUNNEL_BPF) += lwt_bpf.o
> > > obj-$(CONFIG_BPF_STREAM_PARSER) += sock_map.o
> > > obj-$(CONFIG_DST_CACHE) += dst_cache.o
> > > obj-$(CONFI
On Fri, 22 May 2020 05:20:46 + Luis Chamberlain wrote:
> > diff --git a/net/core/Makefile b/net/core/Makefile
> > index 3e2c378e5f31..6f1513781c17 100644
> > --- a/net/core/Makefile
> > +++ b/net/core/Makefile
> > @@ -31,7 +31,7 @@ obj-$(CONFIG_LWTUNNEL_BPF) += lwt_bpf.o
> > obj-$(CONFIG_BPF_S
On Tue, May 19, 2020 at 02:15:30PM -0700, Jakub Kicinski wrote:
> Add infra for creating devlink instances for a device to report
Thanks for doing this series as a PoC, counter to the module_firmware_crash()
which I proposed to taint the kernel with a firmware crash flag to the kernel
and module.
Add infra for creating devlink instances for a device to report
fw crashes. This patch expects the devlink instance to be registered
at probe time. I belive to be the cleanest. We can also add a devm
version of the helpers, so that we don't have to do the clean up.
Or we can go even further and reg
12 matches
Mail list logo
