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

[Andrzej Telszewski]

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/requests-for-current-20151216-a-4175561577-post5584757/

-- 
Best regards,
Andrzej Telszewski