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

Mon Aug 15 09:53:09 UTC 2016

All --

I applied the two attached patch files to hwinfo.

After installing the attached blacklist st file to /etc/modprobe.d, I no
longer get the Kernel Bug Dump in Syslog when I run hwinfo with the huge
Kernel.

Nor do I get the Kernel Bug Dump if I invoke `modprobe -b st` as root from
the commandline ( although the Bug Dump is there without -b ).

Thanks for making me look :)

-- kjh

On Mon, Aug 15, 2016 at 4:20 AM, Konrad J Hambrick <kjhambrick at gmail.com>
wrote:

>
> Thanks for the reply Andrzej Telszewski
>
> See my reply to Arkadiusz Drabczyk, especially the part about blacklisting
> the "st" module in /etc/modprobe.d and changing the call in hwinfo.
>
> What I am considering does work from the command line ( man modprobe and
> look for the -b flag ).
>
> I created a file: /etc/modprobe.d/disable_scsi_tape.conf with a single
> line:
>
> blacklist st
>>
>
> If I simply run:  `/sbin/modprobe st` I get the Bug dump in
> /var/log/syslog ( and dmesg ).
>
> On the other hand, after installing /etc/modprobe.d/disable_scsi_tape.conf
> if I run `/sbin/modprobe -b st` there is no output.
>
> I believe the change to block.c that I suggested in my other reply will
> 'fix' hwinfo
>
> However, since none of the other compiled-in modules in the Huge Kernel
> result in a Bug Dump, I now believe this is a bug in the st.c kernel code.
>
> Thanks again !
>
> -- kjh
>
> On Sun, Aug 14, 2016 at 8:15 PM, Andrzej Telszewski <atelszewski at gmail.com
> > wrote:
>
>> On 15/08/16 02:01, Arkadiusz Drabczyk 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 is correct on that.
>> It's kinda Slackware bug.
>>
>> Try running:
>> $ dmesg --follow
>>
>> and then:
>> $ modprobe st
>>
>> and you'll notice the OOPS appearing when you try to load "st" module.
>>
>> It happens with huge kernel, but not with generic one (I'm too running
>> 4.4.17 from -current on 14.2).
>>
>> Recently there was a conversation about the problem on LQ, starting here:
>> http://www.linuxquestions.org/questions/slackware-14/request
>> s-for-current-20151216-a-4175561577-post5584757/
>>
>> --
>> Best regards,
>> Andrzej Telszewski
>>
>> _______________________________________________
>> 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/ab63e042/attachment-0001.html>
-------------- next part --------------

--- hwinfo.SlackBuild-orig	2016-08-14 09:12:54.748261147 -0500
+++ hwinfo.SlackBuild	2016-08-15 04:32:12.318857525 -0500
@@ -25,7 +25,7 @@
 PRGNAM=hwinfo
 VERSION=20.1
 BUILD=${BUILD:-1}
-TAG=${TAG:-_SBo}
+TAG=${TAG:-_fix_st_SBo}
 
 if [ -z "$ARCH" ]; then
   case "$( uname -m )" in
@@ -71,6 +71,10 @@
 
 # disable regeneration of changelog and VERSION
 chmod -x ./git2log
+#
+# kjh patched-out load_module(hd_data, "st")
+#
+patch -p1 < ${CWD}/src-block.c-patch-for-st-bug.txt
 
 # use our CFLAGS
 sed -i "s/?= -O2/?= $SLKCFLAGS/" Makefile.common
-------------- next part --------------
--- ./src/hd/block.c-orig	2016-08-15 04:28:34.422836861 -0500
+++ ./src/hd/block.c	2016-08-15 04:28:20.349835527 -0500
@@ -62,7 +62,7 @@
     load_module(hd_data, "sr_mod");
     load_module(hd_data, "sd_mod");
 #if !defined(__s390__) && !defined(__s390x__)
-    load_module(hd_data, "st");
+    load_module_with_params(hd_data, "st", "-b");
 #endif
   }
 
-------------- next part --------------
# kjh added the following for hwinfo to eliminate a Kernel Bug Dump 
# in /var/log/syslog / dmesg
#
# The st module is compiled into the huge kernel but if you 
# modprobe st when /sys/class/scsi_tape/ already exists, you'll
# get a Kernel Bug Dump.
#
# This is definitely a kludge
#
# save this file as /etc/modprobe.d/disable_scsi_tape.conf
#
blacklist st
