<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">Thank you Arkadiusz Drabczyk<div class=""> <br><br></div><div class="">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.<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><b><span style="font-family:monospace,monospace"># grep CONFIG_CHR_DEV_ST= /boot/config-*-4.4.17<br><br>/boot/config-generic-4.4.17:CONFIG_CHR_DEV_ST=m<br>/boot/config-huge-4.4.17:CONFIG_CHR_DEV_ST=y</span></b><br></blockquote><br></div><div class="">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.<br><br></div><div class="">This is the code in block.c that causes the Bug Dump:<br><br></div><div class=""><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><b>  if(hd_probe_feature(hd_data, pr_block_mods)) {<br>    PROGRESS(1, 0, "block modules");<br>    // load_module(hd_data, "ide-cd");<br>    load_module(hd_data, "ide-cd_mod");<br>    load_module(hd_data, "ide-disk");<br>    load_module(hd_data, "sr_mod");<br>    load_module(hd_data, "sd_mod");<br>#if !defined(__s390__) && !defined(__s390x__)<br>    load_module(hd_data, "st");<br>#endif<br>  }</b><br></blockquote><div>Only the call to load_module( hd_data, "st" ) module throws the Bug text into /var/log/syslog<br> <br></div><div>There is another int function called int load_module_with_params( ) which takes a parameter list for the command ( in this case /sbin/modprobe ).<br><br></div><div>I was going to try this:<br><br>1. blacklist the "st" module in /etc/modprobe.d/ <br></div><div>2. change <b>load_module(hd_data, "st"); </b>to <b>load_module_with_params(hd_data, "st", "-b");   // block.c ; line 65<br></b></div><div><br></div><div>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.<br><br></div><div>Anyhow, not a big deal ( I hope ) it's simply odd that the "st" module causes the syslog entries where others don't.<br><br>And given Pat's recent remark about eliminating the huge Kernels it is likely to be OBE. <br><br></div><div>Thanks again.<br><br></div><div>-- kjh<br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 14, 2016 at 7:01 PM, Arkadiusz Drabczyk <span dir="ltr"><<a href="mailto:arkadiusz@drabczyk.org" target="_blank">arkadiusz@drabczyk.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Aug 14, 2016 at 09:23:45AM -0500, Konrad J Hambrick wrote:<br>
> 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>
<br>
</span>(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.<wbr>org/questions/slackware-14/<wbr>please-explain-kobject_add-<wbr>failed-578488/</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Arkadiusz Drabczyk <<a href="mailto:arkadiusz@drabczyk.org">arkadiusz@drabczyk.org</a>><br>
______________________________<wbr>_________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org">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/<wbr>mailman/listinfo/slackbuilds-<wbr>users</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>
</font></span></blockquote></div><br></div>