Sorry but this is kinda long.
> -----Original Message-----
> From: centos-bounces@xxxxxxxxxx
> [mailto:centos-bounces@xxxxxxxxxx] On Behalf Of Jim Perrin
> Sent: Tuesday, July 25, 2006 4:24 AM
> To: CentOS mailing list
> Subject: Re: [CentOS] Building a new 2.6 kernel
>
>
> > I suspect Kudzu is seeing the additional ports now that the
> kernel is build to
> > use them but I don't understand why it causes a problem
> with booting.
>
> Not to be mean, but this is one of the reasons the irc support channel
> chooses to not support kernel builds. It's likely that you're missing
> either an unspecified build dependency, or you've marked something in
> the kernel incorrectly in the config it's using to build. You may need
> to consult the build logs (assuming you kept them) and look for errors
> and the like. What you're running into is part of the "fun" of the
> rebuild process. Now you get to test it and figure out what broke.
Never would have taken it as being mean, it's just a statement of fact your
passing on. I can understand the reason they would take this position and it's
not unreasonable but I think this makes a VERY good case why changing the
number of ttyS ports should NOT require a kernel rebuild. I never wanted to
rebuild the kernel but the additional ports requirement forced me too.
IMHO, the number of ttyS ports should either be controlled by the number of
ports that are found during boot, defaulted to something like 40+ ports on the
standard build or a boot time configuration parameter. The simple way would be
to make the standard kernel set to 40+ ports. With the exception of a system
with very small memory the amount of additional memory required for the
additional ports is a "drop in the bucket". The better way would be either
automatic or boot parameter.
Coming back to my configuration, the only parameter I knowingly changed was
the number of non-legacy tryS ports from 4 to 37 for a total of 41 ports. (Why
37 you might ask? It's 4 Mainpine OCT+ cards [24], plus their control ports
plus the Dell RAC). When Kudzu popped up it was trying to remove a "Generic
Serial Modem". I've been looking into this a little more this morning and I
now suspect the problem is as follows:
The standard kernel has support for 4 legacy and 4 additional ports. The RAC
was assigned to ttyS4. The Mainpine OCT+ first 3 ports were mapped to ttyS5, 6
and 7, it's 4th and 5th ports were being mapped to legacy ports ttyS2 and 3
and the last three were unused. The hardware configuration file, hwconf, shows
"Generic Serial Modems" on ttyS0 through ttyS3 and nothing for the RAC or the
Mainpine.
I think that Kudzu wants to remove ttyS2 and 3 but it's having a problem doing
so. I suspect it may be crashing in such a way that it does not return control
back to the boot process so the boots continues to wait for Kudzu to complete.
I guess I could remove the Mainpine and boot the standard kernel and see what
happens (weekend or late night project). Kudzu should try to remove the
additional "Generic Serial Modems". If that also fail then there may be a
Kudzu problem and not a kernel problem.
Question: would it be reasonable/safe to manually remove the entries for ttyS2
and 3 from the hwconf file and would that cause Kudzu not to think there was a
"Generic Serial Modem" modem on those ports that needed to be removed?
I suspect that if one boots back into a standard kernel Kudzu will want to add
those ports back into the hwconf file and I don't know if there is any way to
keep it from doing so.
So far the kernel seems to be solid except for the problem with Kudzu.
Here is part of dmesg for both the standard kernel and the new build. FYI, in
both cases ttyS4 is the Dell built-in RAC card.
Standard Kernel:
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS4 at I/O 0xec80 (irq = 185) is a 16550A
ttyS5 at I/O 0xdc80 (irq = 225) is a 16550A
ttyS6 at I/O 0xdc88 (irq = 225) is a 16550A
ttyS7 at I/O 0xdc90 (irq = 225) is a 16550A
ttyS2 at I/O 0xdc98 (irq = 225) is a 16550A
ttyS3 at I/O 0xdca0 (irq = 225) is a 16550A
Note: the control port was not seen.
New Kernel Build:
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 41 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ACPI: PCI interrupt 0000:00:04.1[B] -> GSI 23 (level, low) -> IRQ 185
ttyS4 at I/O 0xec80 (irq = 185) is a 16550A
ACPI: PCI interrupt 0000:01:06.0[A] -> GSI 16 (level, low) -> IRQ 225
ttyS5 at I/O 0xdc80 (irq = 225) is a 16550A
ttyS6 at I/O 0xdc88 (irq = 225) is a 16550A
ttyS7 at I/O 0xdc90 (irq = 225) is a 16550A
ttyS8 at I/O 0xdc98 (irq = 225) is a 16550A
ttyS9 at I/O 0xdca0 (irq = 225) is a 16550A
ttyS10 at I/O 0xdca8 (irq = 225) is a 16550A
ttyS11 at I/O 0xdcb0 (irq = 225) is a 16550A
ttyS12 at I/O 0xdcb8 (irq = 225) is a 16550A
ttyS20 at I/O 0xdcf8 (irq = 225) is a 16450
It's going to be interesting to see what happens if I added another Mainpine
OCT+ card. Will it's ports start at 13 or 21? Time will tell.
>
> > Anyone ever seen this?
> >
> > Thanks to all that have help me get this far. You guys have
> been great.
>
>
> --
> During times of universal deceit, telling the truth becomes a
> revolutionary act.
> George Orwell
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
