I created a kernel module which can be passed some command line arguments
(I tried that with insmod and it works).
Now I would like, when I start the kernel with grub, to have this module
loaded at boot time so I can pass, at boot time, a kernel boot option to it.
I mean having something like
kernel vmlinuz root=/dev/ram0 initrd=linuxrc mymodule.param1="myparamvalue"
is it possible?
I've gotten no replies from kde-linux, so I'll ask here:
I upgraded to KDE 4.4 yesterday. I get this error EVERY time I start Kmail:
[ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't
I've tried removing the .local/share/alonadi directory and rebooting with no
Can anyone point me in the right direction per how to fix this?
Thanks in advance
WTF is up with KMail? Ever since I installed a bunch of updates this
morning, KMail started having problems. I got a brilliant idea and
decided to see if restarting KMail would solve the problem. Well, it
didn't. It caused more problems. Now I can't send *anything* and
there's a message on my system (at home -- logged into it from remote)
stating "starting akonadi server." Now WTF is that and why is it not
How come Fedora is still on 2.6.31? Is .32 held back on purpose or are
there issues merging it?
It took less than a week for .31.9 to be pushed through... but I don't
see .32 in updates-testing and it's been almost a whole month...
I have a half dozen machines updated to F11, and one to F12.
Im wondering if I should update the F11s to F12 or leave well enough alone.
I realize that the F11 distribution has reached a 'stable' status, and
the F12 distribution will probably take a couple more months to reach
that status, but would be interested in hearing what other users have
to say about the pair.
I am looking for a SMS server software for RHEL.
The phones we use can receive email but it does not always get to the phone
in a timely manner and sometimes I get "connected refused" when trying to
send messages via email. I've looked at smstools and Googled around but
would like the forums opinion on what they have used and experiences.
Thank you for your time,
I recently ran a <yum update> on my mythdora server, which updated my myth
applications from 0.22-1 to 0.22-5. Now the mythfrontend application
terminates right after being launched and the log ends with
2010-02-28 10:27:10.774 Registering Internal as a media playback plugin.
Floating point exception
I have written to the myth users list, but I thought somebody on this list
might be able to give me some advice, too.
Since the previous version of the myth apps ran pretty well for me, I would
like explore the possibility of going back to that version. However, I
don't have any experience rolling back yum updates If rollbacks require
some before-the-fact configuration, I probably don't have that :-(
On Fri, Jan 29, 2010 at 12:22:05PM +0200, Gilboa Davara wrote:
> > which
> > was throttling the CPUs to 1.6 GHz (from a maximum of 2.4 GHz). I attempted to
> > remedy this by setting InterruptThrottleRate=0,0 in the e1000e driver, after
> > which we had one full day of testing with zero rx_missed_errors, but the
> > application still reported packet loss.
> rx_missed_error usually get triggered when the kernel is slow to handle
> incoming hardware interrupts.
> There's a trade-off here, increase the interrupt rate and you'll
> increase the kernel CPU usage as the expense of lower latency - decrease
> the interrupt rate, and you'll reduce the CPU usage at the expense of a
> higher chance of hitting the RX queue limit.
> I'd suggest you try setting the InterruptThrottleRate to 1000, while
> increasing the RX queues to 4096.
> (sbin/ethtool -G DEVICE rx 4096)
> You could try enabling multi-queue by adding IntterruptType=2,
> RSS=NUM_OF_QUEUE and MQ=1 to your modprobe.conf.d.
I'll try these suggestions later today. Note that I was able to disable
interrupt throttling on the on-board 82574L NICs without seeing any
> Can you post the output of $ mpstat -P 1 ALL during peak load?
We run "mpstat -P 5 ALL" continuously; is this sufficient resolution? I've
attached the mpstat output from the 09:30-10:30 yesterday, which is one of the
busiest hours of the day for multicast traffic.
Also, here is the top of the output from powertop. Are you running with C-STATE
enabled? It is somewhat troubling that more than half of the time is spent in
the most power-saving state (C3), but I think this is averaged across all CPUs.
PowerTOP version 1.11 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies)
C0 (cpu running) (15.2%)
polling 5.5ms ( 4.1%)
C1 halt 0.2ms (23.0%)
C2 mwait 0.2ms ( 4.6%)
C3 mwait 0.4ms (53.1%)
Wakeups-from-idle per second : 2833.7 interval: 10.0s
no ACPI power usage estimate available
Top causes for wakeups:
47.7% (8416.6) <interrupt> : lan1-TxRx-0
25.5% (4498.9) <kernel IPI> : Rescheduling interrupts
13.2% (2324.3) <kernel core> : hrtimer_start_range_ns (tick_sched_timer)
5.7% (1000.9) kipmi0 : __mod_timer (process_timeout)
4.1% (721.9) <interrupt> : lan0-TxRx-0
2.3% (413.0) <interrupt> : extra timer interrupt
0.6% ( 99.8) <kernel module> : __mod_timer (smi_timeout)
0.5% ( 93.1) <interrupt> : ata_piix, ata_piix, uhci_hcd:usb5, uhci_hcd:
0.1% ( 17.2) <kernel core> : __mod_timer (neigh_periodic_timer)
0.1% ( 11.1) <kernel core> : hrtimer_start (tick_sched_timer)
0.1% ( 10.4) vconfig : __mod_timer (garp_join_timer)
0.1% ( 10.0) <kernel module> : __mod_timer (ipmi_timeout)
Appearance Preferences > Background and selecting 'Make Default' used to
set the selected desktop background as the background image for the GDM
login screen and used to work till F11, but is not working as desired
under F12. Is there any other setting that i'm missing under F12 to do
Linux user number: 490644
Open your doors.......It's time to look beyond Windows
Fedora 12 32bit version, after updated by yum for all, when rebooted to
GRUB menu, selected the new kernel 188.8.131.52-174.2.22.fc12.i686.PAE,
won't boot, reboot system back to grub menu and chose previous kernel
184.108.40.206-174.2.3.fc12.i686.PAE to start f12, still works, is there any
fix available or have to wait for f13