Sorry but this is kinda long. > -----Original Message----- > From: centos-bounces at centos.org > [mailto:centos-bounces at centos.org] 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos >