Roger,
GRUB_CMDLINE_LINUX_DEAFAULT attaches its options to default GRUB menu item only.
GRUB_CMDLINE_LINUX does it for each item (recovery modes too).
Since you can edit GRUB item line at while boot time, it is up to you which one to choose.
But there is no reason to change any of those lines if you did not succeed by editing grub start lines.
Re: GRUB_SERIAL_COMMAND
the GNU Grub Manual says it is to conf serial line, while booting box via it.
"Please confirm or not that "pci=nocrs" is just temporary in the active (by pressing shift, then escape) grub screen, and will disappear on the next boot."
Everything you enter to GRUB command WHILE BOOTING your box (i.e. upon pressing "e" while Grub menu is seen) is TEMPORARY and active for that particular boot only. Therefore you can test new options being added to kernel in a safe way.
What you add to GRUB_CMDLINE_LINUX... and issue update-grub afterwards is active for all next system launches.
==========
I experienced my problems upon upgrading to Ubu 12.04 LTS from 8.04 and changing my mobo to AMD990FX-based (Asus Sabertooth). My modem is ZOOM PCI 2920 (not sure about the number).
First success came upon adding "pci=routeirq" option. Then I upgraded BIOS to version 1604 and modem got not accessible again (frankly speaking it was accessible all that time, but its replies went to nowhere due to wrong IRQ assignment).
Look at your /var/log/dmesg and grep "ttyS" there. Focus on IRQ number assigned by kernel. Check in /proc/interrupts if that number is used by bus you have put your modem into, and what device driver cares about that IRQ. You should find "8250" or "serial" as driver names for your modem if it operates right ( not your case alas!).
So if there is IRQ number assigned at boot time ( as checked in dmesg log), and there is not right driver assigned to that IRQ at run time ( as seen in /proc/interrupts) you should focus on investigating events happened in between.
If nothing helps you may try kernel option "irqpoll". The option will make CPU to care about the interrupts. In general the option will slow machine, but this may not be your case if you are not running several GigaEthernets links.
As a valuable experience you may connect the modem to phone line and call the modem through another phone. I wonder if you would see kernel complains about "nobody cares" on your terminal.
Roger, LINUX_DEAFAULT attaches its options to default GRUB menu item only.
GRUB_CMDLINE_
GRUB_CMDLINE_LINUX does it for each item (recovery modes too).
Since you can edit GRUB item line at while boot time, it is up to you which one to choose.
But there is no reason to change any of those lines if you did not succeed by editing grub start lines.
Re: GRUB_SERIAL_COMMAND
the GNU Grub Manual says it is to conf serial line, while booting box via it.
"Please confirm or not that "pci=nocrs" is just temporary in the active (by pressing shift, then escape) grub screen, and will disappear on the next boot."
Everything you enter to GRUB command WHILE BOOTING your box (i.e. upon pressing "e" while Grub menu is seen) is TEMPORARY and active for that particular boot only. Therefore you can test new options being added to kernel in a safe way.
What you add to GRUB_CMDLINE_ LINUX.. . and issue update-grub afterwards is active for all next system launches.
==========
I experienced my problems upon upgrading to Ubu 12.04 LTS from 8.04 and changing my mobo to AMD990FX-based (Asus Sabertooth). My modem is ZOOM PCI 2920 (not sure about the number).
First success came upon adding "pci=routeirq" option. Then I upgraded BIOS to version 1604 and modem got not accessible again (frankly speaking it was accessible all that time, but its replies went to nowhere due to wrong IRQ assignment).
Look at your /var/log/dmesg and grep "ttyS" there. Focus on IRQ number assigned by kernel. Check in /proc/interrupts if that number is used by bus you have put your modem into, and what device driver cares about that IRQ. You should find "8250" or "serial" as driver names for your modem if it operates right ( not your case alas!).
So if there is IRQ number assigned at boot time ( as checked in dmesg log), and there is not right driver assigned to that IRQ at run time ( as seen in /proc/interrupts) you should focus on investigating events happened in between.
If nothing helps you may try kernel option "irqpoll". The option will make CPU to care about the interrupts. In general the option will slow machine, but this may not be your case if you are not running several GigaEthernets links.
As a valuable experience you may connect the modem to phone line and call the modem through another phone. I wonder if you would see kernel complains about "nobody cares" on your terminal.