<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">Thanks for the reply Andrzej Telszewski<div class=""> <br></div><div class="">See my reply to Arkadiusz Drabczyk, especially the part about blacklisting the "st" module in /etc/modprobe.d and changing the call in hwinfo.<br><br></div><div class="">What I am considering does work from the command line ( man modprobe and look for the -b flag ).<br><br></div><div class="">I created a file: /etc/modprobe.d/disable_scsi_tape.conf with a single line:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">blacklist st<br></blockquote><div><br></div><div>If I simply run:  `/sbin/modprobe st` I get the Bug dump in /var/log/syslog ( and dmesg ).<br><br></div><div>On the other hand, after installing /etc/modprobe.d/disable_scsi_tape.conf if I run `/sbin/modprobe -b st` there is no output.<br><br></div><div>I believe the change to block.c that I suggested in my other reply will 'fix' hwinfo <br><br></div><div>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.<br><br></div><div>Thanks again !<br><br></div><div>-- kjh<br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 14, 2016 at 8:15 PM, Andrzej Telszewski <span dir="ltr"><<a href="mailto:atelszewski@gmail.com" target="_blank">atelszewski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 15/08/16 02:01, Arkadiusz Drabczyk wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Aug 14, 2016 at 09:23:45AM -0500, Konrad J Hambrick wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All --<br>
<br>
I am running Slackware64 + Multilib with the Huge 4.4.17 Kernel from<br>
Slackware64 Current.<br>
<br>
I installed libx86emu-1.4 and hwinfo-20.1 from the 14.2 SBo Repository and<br>
tried out hwinfo.<br>
<br>
When hwinfo tries to load the "st" module, I get the attached Kernel Oops.<br>
<br>
I checked the hwinfo man page and I don't see where I can blacklist or exclude<br>
modules from hwinfo but it may be I simply don't understand what I am reading.<br>
<br>
But IMO, a userland program shouldn't cause a Kernel Oops :)<br>
<br>
I also tried Kernels Huge 4.4.15 ( from Current ) and Huge 4.4.14 ( from 14.2 )<br>
and I still see the same Oops in /var/log/syslog.<br>
<br>
I am not sure where to report this and I don't know whether it's a Kernel Bug<br>
or a bug in hwinfo or if it's because I am running the huge kernel, but I did<br>
find a 'work-around':  Don't invoke load_module(hd_data, "st") in src/hd/<br>
block.c<br>
<br>
Attached is a patch for hwinfo.SlackBuild and an ugly patch for src/hd/block.c<br>
<br>
Maybe Y'All know the REAL cause of the bug ?<br>
<br>
Thanks for all the good work you're doing for Slackware !<br>
</blockquote>
<br>
(I also sent this message via <a href="http://gmane.org" rel="noreferrer" target="_blank">gmane.org</a> a couple of hours ago but it<br>
didn't make it to the list so I'm sending again directly to the list)<br>
<br>
I don't think it's a bug.  I think that as you use `huge' kernel the<br>
module that hwinfo is trying to load is already statically built into<br>
the kernel, this is why you get this:<br>
<br>
sysfs: cannot create duplicate filename '/class/scsi_tape'sysfs: cannot create duplicate filename '/class/scsi_tape'<br>
<br>
Do you already have /sys/class/scsi_tape right after booting?<br>
<br>
See a similar problem here:<br>
<a href="https://www.linuxquestions.org/questions/slackware-14/please-explain-kobject_add-failed-578488/" rel="noreferrer" target="_blank">https://www.linuxquestions.org<wbr>/questions/slackware-14/please<wbr>-explain-kobject_add-failed-<wbr>578488/</a><br>
<br>
</blockquote>
<br></div></div>
Arkadiusz is correct on that.<br>
It's kinda Slackware bug.<br>
<br>
Try running:<br>
$ dmesg --follow<br>
<br>
and then:<br>
$ modprobe st<br>
<br>
and you'll notice the OOPS appearing when you try to load "st" module.<br>
<br>
It happens with huge kernel, but not with generic one (I'm too running 4.4.17 from -current on 14.2).<br>
<br>
Recently there was a conversation about the problem on LQ, starting here:<br>
<a href="http://www.linuxquestions.org/questions/slackware-14/requests-for-current-20151216-a-4175561577-post5584757/" rel="noreferrer" target="_blank">http://www.linuxquestions.org/<wbr>questions/slackware-14/request<wbr>s-for-current-20151216-a-<wbr>4175561577-post5584757/</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Best regards,<br>
Andrzej Telszewski</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.<wbr>org</a><br>
<a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">http://lists.slackbuilds.org/m<wbr>ailman/listinfo/slackbuilds-us<wbr>ers</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/<wbr>pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
</div></div></blockquote></div><br></div>