Bug 143927 - CONFIG_SERIAL_8250_NR_UARTS=4 and should be 32
Summary: CONFIG_SERIAL_8250_NR_UARTS=4 and should be 32
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-01 16:04 UTC by Jerry Geis
Modified: 2015-01-04 22:14 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-09-28 08:32:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg showing crazy serial port numbering (23.57 KB, text/plain)
2005-04-18 13:03 UTC, Joergen Thomsen
no flags Details

Description Jerry Geis 2005-01-01 16:04:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Description of problem:
CONFIG_SERIAL_8250_NR_UARTS=4 bby default for the kernel.
I use upto 4 8 port multiport serial cards and they do not function
since UARTS are only 4. The auto detection of the these multiport 
cards working fine with redhat 9. If this number is increased
the cards are detected and work. I would hope that others would fine
increasing this value to 32 valuable as well.

THanks,

Jerry


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


How reproducible:
Always

Steps to Reproduce:
1.kernel just does not correctly find the serial ports if set to 4.
2.
3.
    

Additional info:

Comment 1 Jørgen Thomsen 2005-01-06 22:34:57 UTC
I can only second that after spending several hours finding out how 
to compile and install a kernel only for changing 4 to 32. It was 
working fine in Redhat 8 as well. 

Comment 2 Dave Jones 2005-01-06 23:02:33 UTC
I fixed this in CVS on the 1st, which was the same day I did the 2.6.9
update build. Can you test if its fixed there ? If not, it should
definitly be fixed in the 2.6.10 kernel in updates-testing.


Comment 3 Jerry Geis 2005-01-07 13:26:06 UTC
I grabbed the 2.6.10 from updates testing.
It "sort" of wored...

Instead of getting serial ports ttyS4-ttyS11 for an 8 port card
I got:

ttyS14
ttyS15
ttyS44 - ttyS49

All 8 ports were given just not in the order expected. The ports did work.

Why such an unexpected order?

Jerry

Comment 4 Dave Jones 2005-01-08 01:20:49 UTC
strange. some udev problem maybe? Harald ?

Comment 5 Harald Hoyer 2005-01-10 10:48:05 UTC
Dave: udev uses for ttyS* the kernel numbering scheme... no udev
involved directly ... sorry.

$ ls /sys/class/tty/ttyS*/dev


Comment 6 Jørgen Thomsen 2005-02-11 11:15:49 UTC
Doesn't this odd numbering scheme get fixed ? It is now in the 
current kernel release.

Comment 7 Jerry Geis 2005-02-11 13:41:07 UTC
I am using 2.6.10-741FC3 and it still is a crazy numbering scheme.

Comment 8 Dave Jones 2005-04-16 23:12:43 UTC
can you attach the dmesg output please ?


Comment 9 Joergen Thomsen 2005-04-18 13:03:11 UTC
Created attachment 113324 [details]
dmesg showing crazy serial port numbering

Comment 10 Dave Jones 2005-07-15 19:13:11 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 11 Dave Jones 2005-09-28 08:32:11 UTC
I brought this up with the upstream maintainer a while ago. He replied..

"I feel that this is a case where there's nothing that can be done
to satisfy everyone - any assignment scheme is always going to have
issues with someone's setup."

Given that changing this behaviour is quite a deviation from the upstream serial
code, this would have to happen upstream rather than exclusively in Fedora.



Note You need to log in before you can comment on or make changes to this bug.