From: Ralf Baechle DO1GRB <ralf@linux-mips.org>
To: Jarmo <oh1mrr@nic.fi>
Cc: linux-hams@vger.kernel.org
Subject: Re: Timers in 2.6.x kernels
Date: Sat, 13 Mar 2004 15:19:14 +0100 [thread overview]
Message-ID: <20040313141914.GB26738@linux-mips.org> (raw)
In-Reply-To: <200403121310.02980.oh1mrr@nic.fi>
On Fri, Mar 12, 2004 at 01:10:02PM +0200, Jarmo wrote:
> Have found that timerparameters have loud a much differences
> between kernels 2.2-->2.4-->2.6.Now looked up,that there is
> big change happened in kernels param.h file.
The change was long overdue but we didn't have the necessary infrastructure
in the kernel.org tree to increase HZ without affecting binary compatibility
with applications.
All properly written kernel code should now be used USER_HZ for any kind of
kernel interfaces that are user or application visible. Unfortunately quite
a bit of the ham code in the kernel still hasn't done that transitition
so now we've got a wild mix of time units.
I guess for consistence we should bit the bullet and standardize on one
unit, seconds or miliseconds as appropriate. HZ or USER_HZ require the
user to know what kind of system or even what kernel version he's running.
> A little bit more success to keep system up longer,but it crash still...
You're just putting less pressure on the buggy part of the system. Doesn't
mean your change is improving correctness, unfortunately.
> And what we get into syslog
>
> Mar 5 16:46:58 oh1rbf kernel: 6pack: bad checksum f7
> Mar 5 16:46:58 oh1rbf last message repeated 4 times
> Mar 5 16:46:58 oh1rbf kernel: bad: scheduling while atomic!
> Mar 5 16:46:58 oh1rbf kernel: Call Trace:
> Mar 5 16:46:58 oh1rbf kernel: [schedule+1339/1408] schedule+0x53b/0x580
> Mar 5 16:46:58 oh1rbf kernel: [<c011869b>] schedule+0x53b/0x580
> Mar 5 16:46:58 oh1rbf kernel: [_stext+0/32] rest_init+0x0/0x20
> Mar 5 16:46:58 oh1rbf kernel: [<c0105000>] rest_init+0x0/0x20
> Mar 5 16:46:58 oh1rbf kernel: [apm_do_busy+22/48] apm_do_busy+0x16/0x30
> Mar 5 16:46:58 oh1rbf kernel: [<c01148b6>] apm_do_busy+0x16/0x30
Do you happen to be running a CONFIG_SMP / CONFIG_PREEMPT kernel? The
locking stuff in the 6pack driver looks pretty broken and I wouldn't
expect it to survive for long with any of these two kernel options
enabled.
APM implementations tend to tamper with interrupts so disabling APM while
running data over the serial port may help.
Ralf
next prev parent reply other threads:[~2004-03-13 14:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-12 11:10 Timers in 2.6.x kernels Jarmo
2004-03-12 19:09 ` Jeroen Vreeken
2004-03-13 14:19 ` Ralf Baechle DO1GRB [this message]
2004-03-13 14:59 ` Jarmo
2004-03-13 22:06 ` Ralf Baechle DO1GRB
2004-03-14 6:01 ` Jarmo
2004-03-15 0:51 ` Ralf Baechle DO1GRB
[not found] ` <200403150806.46071.oh1mrr@nic.fi>
2004-03-15 13:38 ` Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040313141914.GB26738@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=linux-hams@vger.kernel.org \
--cc=oh1mrr@nic.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox