[Slackbuilds-users] Huge 4.4.x Kernel + SBo hwinfo = Kernel Oops on scsi_tape

[Konrad J Hambrick]

Thank you Arkadiusz Drabczyk


Yes, /sys/class/scsi_tape exists immediately after boot and the huge
kernels I tested do compile-in the "st" module code while the generic
kernels make a module.  These are the Kernel Configs for generic and huge
4.4.17 Kernels.


>
>
> *# grep CONFIG_CHR_DEV_ST=
> /boot/config-*-4.4.17/boot/config-generic-4.4.17:CONFIG_CHR_DEV_ST=m/boot/config-huge-4.4.17:CONFIG_CHR_DEV_ST=y*
>

I believe there is something odd going on in the st.c Kernel code though
because in hwinfo src/hd/block.c starting at line 57 void function
hd_scan_sysfs_block( ) invokes /sbin/modprobe on several other modules that
are compiled into the huge kernels.

This is the code in block.c that causes the Bug Dump:


>
>
>
>
>
>
>
>
>
> *  if(hd_probe_feature(hd_data, pr_block_mods)) {    PROGRESS(1, 0, "block
> modules");    // load_module(hd_data, "ide-cd");    load_module(hd_data,
> "ide-cd_mod");    load_module(hd_data, "ide-disk");    load_module(hd_data,
> "sr_mod");    load_module(hd_data, "sd_mod");#if !defined(__s390__) &&
> !defined(__s390x__)    load_module(hd_data, "st");#endif  }*
>
Only the call to load_module( hd_data, "st" ) module throws the Bug text
into /var/log/syslog

There is another int function called int load_module_with_params( ) which
takes a parameter list for the command ( in this case /sbin/modprobe ).

I was going to try this:

1. blacklist the "st" module in /etc/modprobe.d/
2. change *load_module(hd_data, "st"); *to
*load_module_with_params(hd_data, "st", "-b");   // block.c ; line 65*

According to what I see in the source code, this should pass the -b flag to
/sbin/modprobe which should in turn eliminate the Bug Dump.

Anyhow, not a big deal ( I hope ) it's simply odd that the "st" module
causes the syslog entries where others don't.

And given Pat's recent remark about eliminating the huge Kernels it is
likely to be OBE.

Thanks again.

-- kjh


On Sun, Aug 14, 2016 at 7:01 PM, Arkadiusz Drabczyk <arkadiusz at drabczyk.org>
wrote:

> On Sun, Aug 14, 2016 at 09:23:45AM -0500, Konrad J Hambrick wrote:
> > All --
> >
> > I am running Slackware64 + Multilib with the Huge 4.4.17 Kernel from
> > Slackware64 Current.
> >
> > I installed libx86emu-1.4 and hwinfo-20.1 from the 14.2 SBo Repository
> and
> > tried out hwinfo.
> >
> > When hwinfo tries to load the "st" module, I get the attached Kernel
> Oops.
> >
> > I checked the hwinfo man page and I don't see where I can blacklist or
> exclude
> > modules from hwinfo but it may be I simply don't understand what I am
> reading.
> >
> > But IMO, a userland program shouldn't cause a Kernel Oops :)
> >
> > I also tried Kernels Huge 4.4.15 ( from Current ) and Huge 4.4.14 ( from
> 14.2 )
> > and I still see the same Oops in /var/log/syslog.
> >
> > I am not sure where to report this and I don't know whether it's a
> Kernel Bug
> > or a bug in hwinfo or if it's because I am running the huge kernel, but
> I did
> > find a 'work-around':  Don't invoke load_module(hd_data, "st") in src/hd/
> > block.c
> >
> > Attached is a patch for hwinfo.SlackBuild and an ugly patch for
> src/hd/block.c
> >
> > Maybe Y'All know the REAL cause of the bug ?
> >
> > Thanks for all the good work you're doing for Slackware !
>
> (I also sent this message via gmane.org a couple of hours ago but it
> didn't make it to the list so I'm sending again directly to the list)
>
> I don't think it's a bug.  I think that as you use `huge' kernel the
> module that hwinfo is trying to load is already statically built into
> the kernel, this is why you get this:
>
> sysfs: cannot create duplicate filename '/class/scsi_tape'sysfs: cannot
> create duplicate filename '/class/scsi_tape'
>
> Do you already have /sys/class/scsi_tape right after booting?
>
> See a similar problem here:
> https://www.linuxquestions.org/questions/slackware-14/
> please-explain-kobject_add-failed-578488/
>
> --
> Arkadiusz Drabczyk <arkadiusz at drabczyk.org>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20160815/d5845857/attachment-0001.html>