On Sat, Jan 03, 2026 at 11:33:47AM +0000, Sudip Mukherjee wrote:
> On Sat, Jan 03, 2026 at 12:01:19PM +0600, Paul Menzel wrote:
> > Dear Salvatore,
> > 
> > 
> > Thank you for the follow-up.
> > 
> > Am 03.01.26 um 01:59 schrieb Salvatore Bonaccorso:
> > 
> > > On Mon, Dec 01, 2025 at 05:05:59PM +0100, Paul Menzel wrote:
> > 
> > > > Am 01.12.25 um 14:25 schrieb Sudip Mukherjee:
> > > > > On Thu, 27 Nov 2025 at 22:55, Paul Menzel wrote:
> > > > 
> > > > > > Am 27.11.25 um 19:51 schrieb Paul Menzel:
> > > > > > 
> > > > > > > Unfortunately, not reproducible, but starting with Linux 6.18-rc7, I got
> > > > > > > the oops below *once*:
> 
> <snip>
> 
> > > 
> > > https://bugs.debian.org/1124075
> > 
> > This is
> > 
> > AMD AM5 ASUS ROG STRIX B650-A GAMING WIFI, BIOS 3067 12/10/2024
> > 
> > > https://bugs.debian.org/1124463
> > 
> > This is
> > 
> > Dell Latitude E5470/0VHKV0, BIOS 1.34.3 11/20/2022
> > 
> > > Does it make a difference to cold-boot or reboot into the system?
> > 
> > I only did cold boots, and I am not able to reproduce it anymore, and wrote
> > it off to some hardware issue – despite the system working fine otherwise.
> > 
> > I am adding the x86 folks, and regression lists.
> 
> Thanks Salvatore for the Debian bug links.
> 
> I had been trying to reproduce this but have not seen it on my machine so far.
> 
> But looking at the traces from the Debian bugs and the trace from Paul, my best
> guess is that its happening because the low level driver, parport_pc in these
> cases, has not completed setting up the hardware.
> 
> When 'lp' starts registering, parport driver will check if there is any port,
> if no ports are found then it will try to load the low level module.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/parport/share.c?h=v6.19-rc3#n198
> 
> As mentioned in the comment request_module() is not trying to load a real module
> and it depends on the alias. Also, mentioned in the Documentation.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/parport.rst?h=v6.19-rc3#n45
> 
> I am not sure why the problem is seen now, but is it possible to test the
> below diff please and see if that fixes the issue.
> 
> diff --git a/drivers/parport/share.c b/drivers/parport/share.c
> index 427abdf3c4c4a..8f45daf7b3825 100644
> --- a/drivers/parport/share.c
> +++ b/drivers/parport/share.c
> @@ -287,8 +287,16 @@ int __parport_register_driver(struct parport_driver *drv, struct module *owner,
>          */
>         ret = bus_for_each_dev(&parport_bus_type, NULL, NULL,
>                                port_detect);
> -       if (!ret)
> +
> +       /* Return if no port has been found. The driver has been
> +        * registered, so whenever a new port registers
> +        * attach_driver_chain() will be called which will then check
> +        * all registered drivers.
> +        */
> +       if (!ret) {
>                 get_lowlevel_driver();
> +               return 0;
> +       }
>  
>         mutex_lock(&registration_lock);
>         if (drv->match_port)

There are several backtraces, I looked at two of them and both trap at
an address that corresponds to:

        /*
         * This has to be run as last thing since init_state may need other
         * pardevice fields. -arca
         */
->      port->ops->init_state(par_dev, par_dev->state);
        if (!test_and_set_bit(PARPORT_DEVPROC_REGISTERED, &port->devflags)) {
                port->proc_device = par_dev;
                parport_device_proc_register(par_dev);
        }


in parport_register_dev_model(). However the trapping machine code
doesn't match the kernel modules of the respective kernels, so that's a
bit strange and I'm unable to tell which of the pointer dereferences
there results in the NULL pointer exception.

Maybe this is also an instance of the hardware disappearing? At least
port->ops and pardev are non-NULL earlier in that function and all
static initialisations of a struct parport_operations have an
init_state() callback.

I didn't try to reproduce, but maybe adding a sleep before that call
makes it more reliable to trigger the problem.

Best regards
Uwe