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

[Konrad J Hambrick]

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/e0c19539/attachment.html>