Bug 52862

Summary: Serial module not loading correct devices
Product: [Retired] Red Hat Linux Reporter: Lawrence M. Shaw <lmshaw>
Component: setserialAssignee: Tim Waugh <twaugh>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: kiosso
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-09-28 23:42:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Can you try this initscript, to see what is left to fix after those two things are cleared up? none

Description Lawrence M. Shaw 2001-08-30 04:06:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

Description of problem:
It worked great with 6.2 but now with 7.1 I've got device problems 
with /etc/rc.d/init.d/serial.
I need all four comm ports S0-S3.  With 6.2, I could easily 
edit /etc/serial.conf by removing the ###AUTOSAVE### line and resaving it 
with "/etc/rc.d/init.d/serial stop".  Now no matter what I do, at boot I 
get "/etc/rc.3/S50serial: test: too many arguments" and then ttyS0-S3 
loads but then I get "/dev/ttySA0: No such device" for 27 lines with 
device names of SA0-2, SC0-3, SI0-9 & SR0-9.
I've edited /etc/serial.conf to just the four lines for S0-S3 and 
issued "setserial" commands for these devices (which worked fine in 6.2) 
but when I reboot the system tries to reload all the above devices.  If I 
generate /etc/serial.conf using the ###AUTOSAVE### feature, 32 device 
lines are generated as such: /dev/ttyS0-S31 (starting with S4 they 
say "uart unknown") but these devices do not match the devices that are 
listed at boot as noted above.
Note /dev/ttyS0-S3 work just fine: its just all these bogus messages at 
boot and shutdown plus "/proc/tty/driver/serial" lists 59 lines 
of "uart:unknown" which I don't think were there in 6.2.  Is this related 
to the previously reported Bug# 49426 which notes that the serial module 
cannot be unloaded.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Copy rc.serial to /etc/rc.d/init.d/serial
2. Load the serial module: chkconfig --add serial
3. Run setserial to configure the ports as desired
4. Create the /etc/serial.conf file by shutting down or running:
  /etc/rc.d/init.d/serial stop
	

Actual Results:  At reboot bogus devices are listed as noted above.
And the /etc/serial.conf file is not created correctly based on the new 
setserial commands issued.

Expected Results:  Per Red Hat documentation, issueing the setserial 
commands and then stopping the serial service should result in the new 
values being saved in /etc/serial.conf and the correct devices loaded at 
reboot.  Also if the first line in /etc/serial.conf (###AUTSAVE###) is 
removed serial should allow manual changes to /etc/serial.conf.  These 
manual changes are not being read at reboot and the same bogus messages 
always occur at boot no matter what /etc/serial.conf is changed to.

Additional info:

Comment 1 Lawrence M. Shaw 2001-09-11 04:35:49 UTC
Anyone able to look at this?

Comment 2 Tim Waugh 2001-09-11 16:48:50 UTC
The 'test: too many arguments' problem: I'm pretty sure this is due to the 
serial driver being compiled statically into the kernel and not built as a 
module, and the initscript not coping with that very gracefully.  I have fixed 
that here.

The 'no such device' issue is due to standard error not being redirected as it 
should be.  Fixing that up now.


Comment 3 Tim Waugh 2001-09-11 17:17:11 UTC
Created attachment 31617 [details]
Can you try this initscript, to see what is left to fix after those two things are cleared up?

Comment 4 Lawrence M. Shaw 2001-09-13 05:52:09 UTC
I'll test the initscript tomorrow and let you know.
Thanks very much for the fix.
Question: Is the serial driver supposed to be compiled statically into the 
kernel?  Is this related to Bug# 49426.  Will it take a new kernel to solve 
being unable to unload the driver.  Probably be fixed in 7.2?

Comment 5 Tim Waugh 2001-09-13 07:38:25 UTC
This is unrelated to that bug report.  There is no need for serial port 
support to be modular.  In fact there is a strong reason for not doing that: 
serial console.


Comment 6 Lawrence M. Shaw 2001-09-14 21:27:17 UTC
OK I've done some of the testing.
Shutdown still has problems as follows:
/etc/rc6.d/K75serial: test: too many arguments
Startup looks much better.  I only get the four ttyS0-S3 listed.  Great!
Might be a good idea to also show the serial startup the same as the other 
processes:  "Starting serial" just before listing the ttys.
I still need to test the ###AUTOSAVE### feature (per the serial HOWTO). Give 
me a couple days.


Comment 7 Tim Waugh 2001-09-17 10:23:21 UTC
Okay, I think I found the last cause of the 'too many arguments' problem:

  `head -1 /etc/serial.conf 2>/dev/null`X = "###AUTOSAVE###X" ; then

should instead be:

  "$(head -1 /etc/serial.conf 2>/dev/null)" = "###AUTOSAVE###" ; then

If you make that change, does that problem go away?

Comment 8 Lawrence M. Shaw 2001-09-23 17:09:17 UTC
Yes, that solves the shutdown errors.  I still need to check the 
###AUTOSAVE###.  Will do this later this week.

Comment 9 Keith Iosso 2001-09-28 23:41:56 UTC
Thanks guys, this was perfect timing for me. A minor documentation point that
could be fixed at the same time would be to make the instructions to run
chkconfig in the last line of /usr/share/doc/setserial-2.17/README say
"chkconfig --add serial" instead of "chkconfig -add serial".

Comment 10 Tim Waugh 2001-09-29 09:19:53 UTC
Fixed in setserial-2.17-5.


Comment 11 Lawrence M. Shaw 2001-10-04 04:47:59 UTC
Tested ###AUTOSAVE### feature and it now seems to work per documentation.
I did get a couple "bad serial port count" errors as the serial.conf file was 
created but possibly this is normal.  File looked OK.