LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Hans-Peter Jansen <hpj@urpla.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Lars Callenbach" <lars.callenbach@gmx.de>,
linux-kernel@vger.kernel.org, linux-dvb@linuxtv.org
Subject: Re: linux device ordering at boot time
Date: Sun, 20 Jan 2008 11:43:22 +0100 [thread overview]
Message-ID: <200801201143.23612.hpj@urpla.net> (raw)
In-Reply-To: <20080119234804.3c58c77b@lxorguk.ukuu.org.uk>
Dear Alan, dear kernel & dvb hackers,
Am Sonntag, 20. Januar 2008 schrieb Alan Cox:
> > Well, it's a major pain in the a**. I've no idea, what reversed the
> > order of PCI devices, but I had to disable the automatic dvb driver
> > loading in order
>
> It depends on the order you load the modules
Sure, but given, that userspace didn't changed meanwhile, I relied on some
hotplug figure before (in openSUSE 10.2 with 2.6.18) to load the modules in
the correct order which itself surely enumerates the PCI bus in some way.
After switching to 2.6.24-rc this order was reversed. At least, my budget
card was first now, while the ff dvb card second, which resulted in a
working vdr, unfortunately without picture and sound (that dropped the WAF
immensely 8-|).
I solved this issue by blacklisting both cards in /etc/modprobe.d/blacklist,
and manually determined the order and which modules to load, only to
discover, that the system won't wake up on the scheduled times anymore.
Ahh, /proc/acpi/alarm disappeared and needed adaption
to /sys/class/rtc/rtc0/wakealarm. That move seems to have (yet to examine,
but easy to work around) timezone issues. On the bright side, this new
interface doesn't interfere with setting the c-mos clock on power down
anymore. One gross hack down. Cool.
The last regressions awaiting to get tackled are:
- rewind is somewhat broken: after a few seconds rewinding correctly, the
pictures stutter, and vdr uses cpu like mad.
- from time to time, the same happens for a few seconds on simple replay.
Both issues _feel_ like locking artefacts, which 2.6.18 (with
http://linuxtv.org/hg/v4l-dvb drivers) didn't suffer from (my vdr operates
mostly on nfs3 mounted files). I'm trying to explore these problems in more
detail and will come back. For the record, these issues happen with the
factory drivers/media modules and with drivers from v4l-dvb tree.
Please don't get me wrong, I'm not whining about all this, it's just a
report from user side about what happens, if one tries to follow a strong
moving target. Take it as a reminder, that some decisions during (kernel)
development does have an wider impact on us poor users out there, as it
seems.
The only thing, what makes me really sad, is that current dvb development is
distracted by political and emotional (ego-logical) reasons, repressing
the full potential in this area.
Pete
next prev parent reply other threads:[~2008-01-20 10:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-19 18:55 Lars Callenbach
2008-01-19 19:14 ` Oliver Pinter (Pintér Olivér)
2008-01-19 19:41 ` Jan Engelhardt
2008-01-19 23:06 ` Hans-Peter Jansen
2008-01-19 23:48 ` Alan Cox
2008-01-20 10:43 ` Hans-Peter Jansen [this message]
2008-01-20 13:22 ` Lars Callenbach
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=200801201143.23612.hpj@urpla.net \
--to=hpj@urpla.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=lars.callenbach@gmx.de \
--cc=linux-dvb@linuxtv.org \
--cc=linux-kernel@vger.kernel.org \
--subject='Re: linux device ordering at boot time' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).