Re: Immediate general protection errors on Tyan board
Bob Richmond wrote: Immediately upon boot on this system, most userland programs will segfault, including mount. This causes the system to come up in a bizarre state with the root filesystem mounted read-only, and nothing runs without segfault. There have been numerous similar posts about this problem, but they also seem to point to an associated kernel message, "Bad page state" that I don't observe. dmesg (which runs without segfault) returns many similar messages to: start_udev[576] general protection rip:2ae0fc70 rsp:7fb23d90 error:0 echo 0 > /proc/sys/kernel/randomize_va_space - Seems to fix it for most people. See http://bugzilla.kernel.org/show_bug.cgi?id=4851 for more details. Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On 05.09.2005 [12:02:29 +0530], Srivatsa Vaddagiri wrote: > On Sun, Sep 04, 2005 at 10:48:13PM -0700, Nishanth Aravamudan wrote: > > Admittedly, I don't think SMP ARM has been around all that long? > > Maybe the existing code just has not been extended. > > Yeah, maybe ARM never cared for SMP. But we do care :) I just took a look at arm/Kconfig and SMP is marked as EXPERIMENTAL && BROKEN. So I'm guessing that is the only reason for some of the differences you mentioned (the differences are of course, valid and the x86 SMP implementation makes sense to me to extend arch-independently). > > I'm not sure on this. It's going to be NULL for other architectures, > > or end up being called by the reprogram() call for the last CPU to > > go idle, right (presuming there isn't a separate TOD source, like in > > x86). I think it is better to be in the reprogram() interface. > > Non-x86 could have it set to NULL, in which case it doesn't get > called. (I know the current code does not take care of this > situation). But having an explicit 'all_cpus_idle' interface may be > good, since Tony talked of idling some devices when all CPUs are idle. > So it probably has non-x86/PIT uses too. OK, not a problem. I'll try and write up a general intsource.h file (interrupt source header) tonight and tomorrow and send it to this list to see if everybody agrees on what's in the structure and where the arch-independent/dependent line lies. > > > 6. S390 makes use of notifier mechanism to notify when CPUs are > > >coming in and out of idle state. Don't know how it will be used > > >in other arches. But obviously, if we are talking of unifying, > > >we have to provide one. > > > > Couldn't that be part of the s390-specific init() code? That member > > is non-existent in the ARM implementation either, but it should not > > be hard to add? The only issue I see, though, is that the function > > which the init() member points to should not be marked __init, as we > > could have an empty pointer later on? > > If we consider that only s390 needs it and other arch's dont, then it > need not be even part of the init code. Basically the notifier list > can be maintained by s390 in its arch-code entirely and have > 'stop_hz_timer' call into dyn_tick_reprogram_timer (or something like > that)? But I feel there will be other uses for the notifier list (I > know the slab reap timer fires every two seconds and that may be > unnecessary on idle CPUs if it is not reaping anything - perhaps it > could use such a notifier to fire at longer intervals on idle CPUs? > That may be true of other short-timers that kernel/drivers may be > using. This is just a thought and may need more consideration before > we put a notifier mechanism in arch-independent code). Yeah, maybe we would be ok with keeping the notifier setup s390-specific for now, and then extending the faculty to arch-independent code if we find good (clean) reasons to do so. I'm not saying the slab reaping code is insufficient, but I want to keep the structure and code as simple as possible at first (in the design phase, at least). > > I'm not sure on this last one, though, what part of the state can't > > simply be represented by an integer with appropriate &-ing? > > Everything can be represented in bits! I was just comparing > composition of structures in ARM and x86. The state bitfield is part > of 'struct dyn_tick_timer' itself in ARM while it is part of a > separate structure (dyn_tick_state) in x86. Similar minor points need > to be sorted out while unifying. Heh, I agree :) I just wanted to make sure that I hadn't missed something and there was a *specific* reason the x86 code was using a separate structure. I actuall prefer keeping it tied to the interrupt source; it's simpler to me. Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
Willy Tarreau wrote (ao): > So you're both half-right from your point of view. But you're both half-wrong > too : no, people can't always choose, and no, people who don't choose their > laptop are not impacted by development kernels. So let's turn the page and > wait for a stable kernel. If the company provides a laptop that doesn't mean that the user can't choose anymore. He can buy his own laptop. Companies don't allow you to fiddle with the installed OS anyway. Kind regards, Sander -- Humilis IT Services and Solutions http://www.humilis.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Immediate general protection errors on Tyan board
Immediately upon boot on this system, most userland programs will segfault, including mount. This causes the system to come up in a bizarre state with the root filesystem mounted read-only, and nothing runs without segfault. There have been numerous similar posts about this problem, but they also seem to point to an associated kernel message, "Bad page state" that I don't observe. dmesg (which runs without segfault) returns many similar messages to: start_udev[576] general protection rip:2ae0fc70 rsp:7fb23d90 error:0 This occurrs on the latest Fedora Core 4 kernel RPM (kernel-2.6.12-1.1447_FC4) on a Tyan S2892 motherboard with 2 Opteron 246 processors. The BIOS is up to date with what is available on Tyan's website for this board. I'm not sure if the Fedora maintainers have rolled in the latest AMD errata changes from 2.6.13 in the latest package, but that will be my next test. Does anyone still observe this problem in their systems? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
> > +void gfs2_glock_hold(struct gfs2_glock *gl)
> > +{
> > + glock_hold(gl);
> > +}
> >
> > eh why?
On 9/5/05, David Teigland <[EMAIL PROTECTED]> wrote:
> You removed the comment stating exactly why, see below. If that's not a
> accepted technique in the kernel, say so and I'll be happy to change it
> here and elsewhere.
Is there a reason why users of gfs2_glock_hold() cannot use
glock_hold() directly?
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On Sun, Sep 04, 2005 at 10:48:13PM -0700, Nishanth Aravamudan wrote: > Admittedly, I don't think SMP ARM has been around all that long? Maybe > the existing code just has not been extended. Yeah, maybe ARM never cared for SMP. But we do care :) > I'm not sure on this. It's going to be NULL for other architectures, or > end up being called by the reprogram() call for the last CPU to go idle, > right (presuming there isn't a separate TOD source, like in x86). I > think it is better to be in the reprogram() interface. Non-x86 could have it set to NULL, in which case it doesn't get called. (I know the current code does not take care of this situation). But having an explicit 'all_cpus_idle' interface may be good, since Tony talked of idling some devices when all CPUs are idle. So it probably has non-x86/PIT uses too. > > 6. S390 makes use of notifier mechanism to notify when CPUs are coming > >in and out of idle state. Don't know how it will be used in other > >arches. But obviously, if we are talking of unifying, we have to > >provide one. > > Couldn't that be part of the s390-specific init() code? That member is > non-existent in the ARM implementation either, but it should not be hard > to add? The only issue I see, though, is that the function which the > init() member points to should not be marked __init, as we could have an > empty pointer later on? If we consider that only s390 needs it and other arch's dont, then it need not be even part of the init code. Basically the notifier list can be maintained by s390 in its arch-code entirely and have 'stop_hz_timer' call into dyn_tick_reprogram_timer (or something like that)? But I feel there will be other uses for the notifier list (I know the slab reap timer fires every two seconds and that may be unnecessary on idle CPUs if it is not reaping anything - perhaps it could use such a notifier to fire at longer intervals on idle CPUs? That may be true of other short-timers that kernel/drivers may be using. This is just a thought and may need more consideration before we put a notifier mechanism in arch-independent code). > I'm not sure on this last one, though, what part of the state can't > simply be represented by an integer with appropriate &-ing? Everything can be represented in bits! I was just comparing composition of structures in ARM and x86. The state bitfield is part of 'struct dyn_tick_timer' itself in ARM while it is part of a separate structure (dyn_tick_state) in x86. Similar minor points need to be sorted out while unifying. -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On 9/5/05, Willy Tarreau <[EMAIL PROTECTED]> wrote: > Except that someone has to maintain the patch, because with the speed the > kernel is changing, a patch against 2.6.14 will not work on 2.6.15. Indeed. It has to be maintained in tree as well and I don't see any justification for making mainline care about !4KB_STACKS just for the sake of ndiswrapper. While I appreciate that ndiswrapper is useful for some people, it should IMHO be maintained as an out-of-tree patch (stack size included). Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Sun, Sep 04, 2005 at 10:33:44PM +0200, Pavel Machek wrote: > Hi! > > > - read-only mount > > - "specatator" mount (like ro but no journal allocated for the mount, > > no fencing needed for failed node that was mounted as specatator) > > I'd call it "real-read-only", and yes, that's very usefull > mount. Could we get it for ext3, too? This is a bit of a degression, but it's quite a bit different from what ocfs2 is doing, where it is not necessary to replay the journal in order to assure filesystem consistency. In the ext3 case, the only time when read-only isn't quite read-only is when the filesystem was unmounted uncleanly and the journal needs to be replayed in order for the filesystem to be consistent. Mounting the filesystem read-only without replaying the journal could and very likely would result in the filesystem reporting filesystem consistency problems, and if the filesystem is mounted with the reboot-on-errors option, well - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
> +static unsigned int handle_roll(atomic_t *a)
> +{
> + int x = atomic_read(a);
> + if (x < 0) {
> + atomic_set(a, 0);
> + return 0;
> + }
> + return (unsigned int)x;
> +}
>
> this is just plain scary.
Not really, it was just resetting atomic statistics counters when they
became negative. Unecessary, though, so removed.
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Mon, September 5, 2005 2:04 am, Willy Tarreau said: > They don't mind. Those people install Checkpoint on Linux. A product of > which previous releases were even incompatible with security updates ! Heh.. well all the power to them. Still no reason for an open source developer to waste one second worrying about it though. > You don't get it. One of my collegue installed quagga on his binary-only > laptop. Now that he found it very useful and showed how to can be used, > he's planning on setting up servers to run it to bring new services. So > his *crappy* laptop full of binary-only drivers and relying on ndiswrapper > allows him to build a proof of concept and get the possibility to run it > on real hardware. Same comment. Someone should create a distribution dedicated to this market if it's that important. > Except that someone has to maintain the patch, because with the speed the > kernel is changing, a patch against 2.6.14 will not work on 2.6.15. I've > tried UML on 2.4 in the past, and I've learned the hard way not to rely > on patches for old features when developpers consider them obsolete (2.4 > support ended when 2.6 began). If enough people are interested in it, it can't be that hard to organize external maintenance of the patch. Even these long conversations on the mailing list show why the bloody thing should be ejected already. Move it to it's own tree with it's own mailing list etc.. > Keeping it marked as BROKEN is fine. It may even taint the kernel, that's > not a problem. Removing it is wrong. I agree with you that it should taint at a minimum. But should something that taints the kernel even be part of the mainline source? Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
R: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1
> Giampaolo, > > Should read: ...even if the ATMSAR actually lacks of AAL1, AAL2 > and AAL3/4 [where AAL3/4 is obsolete] capabilities... > > Just wanted to make it more precise according to the ATM > standards, this was the only intention of my "patch". You're right. Sorry about that. Thanks, Giampaolo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: R: [Linux-ATM-General] [ATMSAR] Request for review - update #1
Giampaolo Tomassoni wrote: Also, I believe that adsl will carry much more services then just AAL5 for internet connection in the future. Even if the ATMSAR actually lacks of AAL1 and AAL2/3 capabilities, adding them in a single, specialized module is much easier than swimming in a usb+atm middle layer. Giampaolo, Should read: ...even if the ATMSAR actually lacks of AAL1, AAL2 and AAL3/4 [where AAL3/4 is obsolete] capabilities... Just wanted to make it more precise according to the ATM standards, this was the only intention of my "patch". Peace to all! :o) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Mon, Sep 05, 2005 at 01:31:29AM -0400, Sean wrote: > On Mon, September 5, 2005 1:01 am, Willy Tarreau said: > > > But how do you think Linux has penetrated the enterprise market ??? > > We all have put dual boots on every windows machine we had access to, > > eventhough this was clearly forbidden. And after repeatedly showing > > to the staff that you saved their day with your Linux, they finally > > start to get interested to it. One of my best customers has finally > > bought about one hundred RHEL3 licences to replace amateur installs > > on production machines. They would never have looked at it without > > us braving unauthorized dual boots. > > And how impressed would they have been if you had to install a bunch of > binary drivers to get the job done? Do you think all the problems that > are associated with binary drivers would not have bitten you or your > company? They don't mind. Those people install Checkpoint on Linux. A product of which previous releases were even incompatible with security updates ! > What you're talking about did happen, but it didn't happen on laptops, and > it didn't happen with binary drivers. It happened naturally when Linux > grew mature enough to support servers without the need for binary-only > hacks. You don't get it. One of my collegue installed quagga on his binary-only laptop. Now that he found it very useful and showed how to can be used, he's planning on setting up servers to run it to bring new services. So his *crappy* laptop full of binary-only drivers and relying on ndiswrapper allows him to build a proof of concept and get the possibility to run it on real hardware. > Trying to accelerate the acceptance of Linux on the desktop with binary > hacks is simply counterproductive. > > > I think we should not worry about it, but we should not deliberately break > > it in a stable series when that does not bring anything. The fact that > > Adrian proposed to completely remove the option is sad. It's in the > > windows > > world that you can't choose. In Linux, you make menuconfig and choose what > > suits your needs. > > That's the beauty of open source; nobody is being deprived of a choice. > Anyone can simply patch their kernel with 8K support if that's what they > need. But as has been aptly pointed out by others in this thread, 8K > stacks aren't really needed at all, even for NDISwrapper. Except that someone has to maintain the patch, because with the speed the kernel is changing, a patch against 2.6.14 will not work on 2.6.15. I've tried UML on 2.4 in the past, and I've learned the hard way not to rely on patches for old features when developpers consider them obsolete (2.4 support ended when 2.6 began). > 4K stacks were NOT invented to hassle binary-only driver owners, they were > created to solve problems associated with 8K stacks.. Leaving the 8K > stack option in the kernel signals that it is a _good_ option. That just > isn't true, so the option should be removed or at least marked BROKEN. Keeping it marked as BROKEN is fine. It may even taint the kernel, that's not a problem. Removing it is wrong. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On 05.09.2005 [11:02:25 +0530], Srivatsa Vaddagiri wrote: > On Sun, Sep 04, 2005 at 09:26:16PM +0100, Russell King wrote: > > I'd be really surprised if any architecture couldn't use what ARM has > > today - in other words, this is the only kernel-side interface: > > Russel, > I went thr' the ARM implementation and have some remarks (mostly > from a SMP perspective): > > 1. On a SMP platform, we want to let individual CPUs "sleep" independent of >each other. What this mean is there has to be some way of tracking which >CPU's are sleeping currently, so that code like RCU ignores sleeping CPUs. >This was the reason nohz_cpu_mask bitmap was added. I don't see that >bitmap being updated at all in ARM implementation. Admittedly, I don't think SMP ARM has been around all that long? Maybe the existing code just has not been extended. > 2. On architectures like x86 there is a separate jiffy interrupt source >(PIT) which is used to update time-of-day. This is different from the >HZ timer interrupts used on each CPU (local apic timer). When all >CPUs are idle and sleeping, we want to shut off this PIT timer as well. >That's why I added 'arch_all_cpus_idle' interface. One could argue that >this can be done as part of the dyn_tick->reprogram interface as well, >but I felt that having a separate arch_all_cpus_idle is cleaner and >makes it clear what its purpose is. I'm not sure on this. It's going to be NULL for other architectures, or end up being called by the reprogram() call for the last CPU to go idle, right (presuming there isn't a separate TOD source, like in x86). I think it is better to be in the reprogram() interface. > 3. The fact that we want to manipulate the bitmap (set a bit when CPU is going >idle and unset it when it is waking up) _and_ the fact that want to take >some action when all CPUs are idle or when the first CPU is waking up, >requires the use of a spinlock, which is again not present in the ARM >implementation. This might just be tied to the same UP capabilities, I'm not sure. > 4. Again the fact that CPUs could be sleeping independent of each other >requires do_IRQ to check out whether the current CPU was sleeping as >its first step. If the CPU was sleeping, it needs to unset itself >from the bitmap _and_ if we are coming out of "all-cpu-asleep" state, >the PIT timer needs to be restarted as well as time recovered. Note >that these two steps need not be undertaken if we were not in >"all-cpus-asleep" state. I agree; the latter can be in the arch-specific reprogram() code, just like arch_all_cpus_idle() (which might be better named to arch_set_all_cpus_idle()). > I don't see provisions for all these in the current ARM > implementation. In fact the x86 patch that Tony/Con posted didnt take > into account most of these as well, which is the reason I jumped in to > fix the above issues. I definitely appreciate you doing so; dyn-tick for x86 has clearly come a long way in a short time. > 5. Don't see how DYN_TICK_SKIPPING is being used. In SMP scenario, >it doesnt make sense since it will have to be per-cpu. The bitmap >that I talked of exactly tells that (whether a CPU is skipping >ticks or not). I'll take a look at this. > 6. S390 makes use of notifier mechanism to notify when CPUs are coming >in and out of idle state. Don't know how it will be used in other >arches. But obviously, if we are talking of unifying, we have to >provide one. Couldn't that be part of the s390-specific init() code? That member is non-existent in the ARM implementation either, but it should not be hard to add? The only issue I see, though, is that the function which the init() member points to should not be marked __init, as we could have an empty pointer later on? > I hope this makes clear why some of the rework happened, which > in a way is extending the interface that ARM already has. Having > said all these, I do agree that having a consistent interface > is good (for example: x86 has dyn_tick_state structure whereas > ARM uses dyn_tick_timer strucuture itself to store the state etc). I'm not sure on this last one, though, what part of the state can't simply be represented by an integer with appropriate &-ing? Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11.11 and rsync oops (SATA related?)
Parag Warudkar wrote: Jesper Juhl wrote: It seems you forgot to include the data. Nothing inline in the email, nor any attachments. Sorry for that, I really forgot to include the attachments at first, then send the mail, then canceled it (on gmane.org), then send another mail with the attachments. I could see the attachments and inline dmesg - probably your mail server is at it. Jesper was just to quick to notice my mistake :-) But I thought that I don't need to reply to him to increase the S/N ratio... Kalin. -- |[ ~~ ]| +-> http://ThinRope.net/ <-+ |[ __ ]| - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
> +void gfs2_glock_hold(struct gfs2_glock *gl)
> +{
> + glock_hold(gl);
> +}
>
> eh why?
You removed the comment stating exactly why, see below. If that's not a
accepted technique in the kernel, say so and I'll be happy to change it
here and elsewhere.
Thanks,
Dave
static inline void glock_hold(struct gfs2_glock *gl)
{
gfs2_assert(gl->gl_sbd, atomic_read(&gl->gl_count) > 0);
atomic_inc(&gl->gl_count);
}
/**
* gfs2_glock_hold() - As glock_hold(), but suitable for exporting
* @gl: The glock to hold
*
*/
void gfs2_glock_hold(struct gfs2_glock *gl)
{
glock_hold(gl);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On Sun, Sep 04, 2005 at 09:26:16PM +0100, Russell King wrote: > I'd be really surprised if any architecture couldn't use what ARM has > today - in other words, this is the only kernel-side interface: Russel, I went thr' the ARM implementation and have some remarks (mostly from a SMP perspective): 1. On a SMP platform, we want to let individual CPUs "sleep" independent of each other. What this mean is there has to be some way of tracking which CPU's are sleeping currently, so that code like RCU ignores sleeping CPUs. This was the reason nohz_cpu_mask bitmap was added. I don't see that bitmap being updated at all in ARM implementation. 2. On architectures like x86 there is a separate jiffy interrupt source (PIT) which is used to update time-of-day. This is different from the HZ timer interrupts used on each CPU (local apic timer). When all CPUs are idle and sleeping, we want to shut off this PIT timer as well. That's why I added 'arch_all_cpus_idle' interface. One could argue that this can be done as part of the dyn_tick->reprogram interface as well, but I felt that having a separate arch_all_cpus_idle is cleaner and makes it clear what its purpose is. 3. The fact that we want to manipulate the bitmap (set a bit when CPU is going idle and unset it when it is waking up) _and_ the fact that want to take some action when all CPUs are idle or when the first CPU is waking up, requires the use of a spinlock, which is again not present in the ARM implementation. 4. Again the fact that CPUs could be sleeping independent of each other requires do_IRQ to check out whether the current CPU was sleeping as its first step. If the CPU was sleeping, it needs to unset itself from the bitmap _and_ if we are coming out of "all-cpu-asleep" state, the PIT timer needs to be restarted as well as time recovered. Note that these two steps need not be undertaken if we were not in "all-cpus-asleep" state. I don't see provisions for all these in the current ARM implementation. In fact the x86 patch that Tony/Con posted didnt take into account most of these as well, which is the reason I jumped in to fix the above issues. 5. Don't see how DYN_TICK_SKIPPING is being used. In SMP scenario, it doesnt make sense since it will have to be per-cpu. The bitmap that I talked of exactly tells that (whether a CPU is skipping ticks or not). 6. S390 makes use of notifier mechanism to notify when CPUs are coming in and out of idle state. Don't know how it will be used in other arches. But obviously, if we are talking of unifying, we have to provide one. I hope this makes clear why some of the rework happened, which in a way is extending the interface that ARM already has. Having said all these, I do agree that having a consistent interface is good (for example: x86 has dyn_tick_state structure whereas ARM uses dyn_tick_timer strucuture itself to store the state etc). -- Thanks and Regards, Srivatsa Vaddagiri, Linux Technology Center, IBM Software Labs, Bangalore, INDIA - 560017 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Mon, September 5, 2005 1:01 am, Willy Tarreau said: > But how do you think Linux has penetrated the enterprise market ??? > We all have put dual boots on every windows machine we had access to, > eventhough this was clearly forbidden. And after repeatedly showing > to the staff that you saved their day with your Linux, they finally > start to get interested to it. One of my best customers has finally > bought about one hundred RHEL3 licences to replace amateur installs > on production machines. They would never have looked at it without > us braving unauthorized dual boots. And how impressed would they have been if you had to install a bunch of binary drivers to get the job done? Do you think all the problems that are associated with binary drivers would not have bitten you or your company? What you're talking about did happen, but it didn't happen on laptops, and it didn't happen with binary drivers. It happened naturally when Linux grew mature enough to support servers without the need for binary-only hacks. Trying to accelerate the acceptance of Linux on the desktop with binary hacks is simply counterproductive. > I think we should not worry about it, but we should not deliberately break > it in a stable series when that does not bring anything. The fact that > Adrian proposed to completely remove the option is sad. It's in the > windows > world that you can't choose. In Linux, you make menuconfig and choose what > suits your needs. That's the beauty of open source; nobody is being deprived of a choice. Anyone can simply patch their kernel with 8K support if that's what they need. But as has been aptly pointed out by others in this thread, 8K stacks aren't really needed at all, even for NDISwrapper. 4K stacks were NOT invented to hassle binary-only driver owners, they were created to solve problems associated with 8K stacks.. Leaving the 8K stack option in the kernel signals that it is a _good_ option. That just isn't true, so the option should be removed or at least marked BROKEN. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6 patch] remove some unused IDE stuff
Hi Adrian,
Adrian Bunk wrote:
This patch removes some dead IDE-related #define's and
"static inline" functions.
Please double-check it since I've only tested it with grep and didn't
try compilation.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
I think the include/asm-m68knommu/ide.h should just be removed
altogether. None of the underlying code support for it has been
carried into 2.6, so it is pretty much useless.
Regards
Greg
---
arch/ppc/platforms/hdpu.c | 40 ---
include/asm-m68knommu/ide.h | 41
include/asm-parisc/ide.h|5
3 files changed, 86 deletions(-)
--- linux-2.6.13-mm1-full/arch/ppc/platforms/hdpu.c.old 2005-09-02
02:02:33.0 +0200
+++ linux-2.6.13-mm1-full/arch/ppc/platforms/hdpu.c 2005-09-02
02:04:08.0 +0200
@@ -608,46 +608,6 @@
}
}
-#if defined(CONFIG_BLK_DEV_IDE) || defined(CONFIG_BLK_DEV_IDE_MODULE)
-static int hdpu_ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
- return check_region(from, extent);
-}
-
-static void
-hdpu_ide_request_region(ide_ioreg_t from, unsigned int extent, const char
*name)
-{
- request_region(from, extent, name);
- return;
-}
-
-static void hdpu_ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
- release_region(from, extent);
- return;
-}
-
-static void __init
-hdpu_ide_pci_init_hwif_ports(hw_regs_t * hw, ide_ioreg_t data_port,
-ide_ioreg_t ctrl_port, int *irq)
-{
- struct pci_dev *dev;
-
- pci_for_each_dev(dev) {
- if (((dev->class >> 8) == PCI_CLASS_STORAGE_IDE) ||
- ((dev->class >> 8) == PCI_CLASS_STORAGE_RAID)) {
- hw->irq = dev->irq;
-
- if (irq != NULL) {
- *irq = dev->irq;
- }
- }
- }
-
- return;
-}
-#endif
-
void hdpu_heartbeat(void)
{
if (mv64x60_read(&bh, MV64x60_GPP_VALUE) & (1 << 5))
--- linux-2.6.13-mm1-full/include/asm-m68knommu/ide.h.old 2005-09-02
02:04:17.0 +0200
+++ linux-2.6.13-mm1-full/include/asm-m68knommu/ide.h 2005-09-02
02:10:11.0 +0200
@@ -141,47 +141,6 @@
#define ide_init_default_irq(base) ide_default_irq(base)
-static IDE_INLINE int
-ide_request_irq(
- unsigned int irq,
- void (*handler)(int, void *, struct pt_regs *),
- unsigned long flags,
- const char *device,
- void *dev_id)
-{
-#ifdef CONFIG_COLDFIRE
- mcf_autovector(irq);
-#endif
- return(request_irq(irq, handler, flags, device, dev_id));
-}
-
-
-static IDE_INLINE void
-ide_free_irq(unsigned int irq, void *dev_id)
-{
- free_irq(irq, dev_id);
-}
-
-
-static IDE_INLINE int
-ide_check_region(ide_ioreg_t from, unsigned int extent)
-{
- return 0;
-}
-
-
-static IDE_INLINE void
-ide_request_region(ide_ioreg_t from, unsigned int extent, const char *name)
-{
-}
-
-
-static IDE_INLINE void
-ide_release_region(ide_ioreg_t from, unsigned int extent)
-{
-}
-
-
static IDE_INLINE void
ide_fix_driveid(struct hd_driveid *id)
{
--- linux-2.6.13-mm1-full/include/asm-parisc/ide.h.old 2005-09-02
02:05:19.0 +0200
+++ linux-2.6.13-mm1-full/include/asm-parisc/ide.h 2005-09-02
02:08:39.0 +0200
@@ -20,11 +20,6 @@
#define IDE_ARCH_OBSOLETE_INIT
#define ide_default_io_ctl(base) ((base) + 0x206) /* obsolete */
-#define ide_request_irq(irq,hand,flg,dev,id) request_irq((irq),(hand),(flg),(dev),(id))
-#define ide_free_irq(irq,dev_id) free_irq((irq), (dev_id))
-#define ide_check_region(from,extent) check_region((from), (extent))
-#define ide_request_region(from,extent,name) request_region((from),
(extent), (name))
-#define ide_release_region(from,extent)release_region((from),
(extent))
/* Generic I/O and MEMIO string operations. */
#define __ide_insw insw
--
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a CyberGuard CompanyPHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11.11 and rsync oops (SATA related?)
Jesper Juhl wrote: It seems you forgot to include the data. Nothing inline in the email, nor any attachments. I could see the attachments and inline dmesg - probably your mail server is at it. Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Mon, Sep 05, 2005 at 12:47:03AM -0400, Sean wrote: > On Mon, September 5, 2005 12:36 am, Willy Tarreau said: > > > Well, to be fair, most laptop users today are in companies which provide > > them with the model the staff has chosen for all the employees. And > > employees > > try to install Linux on them anyway. That's how you end up with things > > like > > ndiswrapper, because the people who make those notebooks for companies > > don't > > care at all about their customers ; what they want is negociate with the > > staff to sell them 2000 laptops, and that's all. > > Companies that provide laptops to their employees tend to frown on the > users installing a bunch of stuff anyway. But how do you think Linux has penetrated the enterprise market ??? We all have put dual boots on every windows machine we had access to, eventhough this was clearly forbidden. And after repeatedly showing to the staff that you saved their day with your Linux, they finally start to get interested to it. One of my best customers has finally bought about one hundred RHEL3 licences to replace amateur installs on production machines. They would never have looked at it without us braving unauthorized dual boots. > If the company was buying the > laptop to run Linux it would be spec'd appropriately. > > But the real crux of the argument here is not whether or not people should > ever use binary-only drivers, it's whether the open source kernel > developers should spend any time worrying about it or not. I think we should not worry about it, but we should not deliberately break it in a stable series when that does not bring anything. The fact that Adrian proposed to completely remove the option is sad. It's in the windows world that you can't choose. In Linux, you make menuconfig and choose what suits your needs. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
Hi Dave, On Mon, Sep 05, 2005 at 12:26:41AM -0400, Dave Jones wrote: (...) > A lot of users look at it as nirvana. I've seen users report bugs against > ancient kernels, that are extremely likely to be fixed in later kernels, > yet they're unwilling to move to a newer kernel due to them being tied > to a driver that only works on an older kernel, despite the fact that there > are known security and data corruption issues with the older kernels. > > Helping the cause of binary (or part binary) solutions doesn't solve anything. > It brings nothing but unsolvable problems, and upset users when their problems > can't get fixed. The problem is not whether to support or not to support binary only drivers, I personnally am fairly against such drivers and don't have any on any of my systems. But the problem is that something that works in a *stable* series kernel does not work anymore in the next *stable* series which should theorically only fix bugs. And that's what upsets your users. As you said, when you tell them to upgrade, they refuse because the only thing they need to make their laptop work will not work anymore. So when they have spent tens of hours of research on the net to find *a way* to install Linux on their laptop with network support, they get used to it. When you tell them that the upgrade will fix their oopses but will not support their network card anymore, of course they don't want to upgrade ! And don't tell me that they just have to by another card, I know users of laptops with only one pcmcia slot, and this one does not work at all. But even with the oopses, they are happy not to be forced to work in windows. You know, when they proudly show me that Linux finally "works" on their laptop, and that they had to install a ton of binary drivers and ndiswrapper, I whine a lot telling them that it's not "Linux" they have installed, but sort of a thing that will ressemble it and which will probably be even less stable than windows. But they don't care, because they did not have choice. Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Mon, September 5, 2005 12:36 am, Willy Tarreau said: > Well, to be fair, most laptop users today are in companies which provide > them with the model the staff has chosen for all the employees. And > employees > try to install Linux on them anyway. That's how you end up with things > like > ndiswrapper, because the people who make those notebooks for companies > don't > care at all about their customers ; what they want is negociate with the > staff to sell them 2000 laptops, and that's all. Companies that provide laptops to their employees tend to frown on the users installing a bunch of stuff anyway. If the company was buying the laptop to run Linux it would be spec'd appropriately. But the real crux of the argument here is not whether or not people should ever use binary-only drivers, it's whether the open source kernel developers should spend any time worrying about it or not. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
Hi, On Mon, Sep 05, 2005 at 12:12:56AM -0400, Sean wrote: > On Mon, September 5, 2005 12:03 am, Alex Davis said: > > > > What if you don't have a choice? When someone comes to me with their > > laptop > > containing a built-in wireless card not natively supported by Linux, am I > > supposed to tell them "go buy a Linux-supported card" when there's a way > > I can make their existing card work? I don't think so. > > You always have a choice in life. Nobody is stopping you from doing what > _you_ choose to do. That doesn't mean that developers who are concerned > with the creation and promotion of open source should care one whit about > your particular take on the situation. Go do whatever you want just > don't expect the open source developers to pay for it; you maintain the > crufty patches yourself. Well, to be fair, most laptop users today are in companies which provide them with the model the staff has chosen for all the employees. And employees try to install Linux on them anyway. That's how you end up with things like ndiswrapper, because the people who make those notebooks for companies don't care at all about their customers ; what they want is negociate with the staff to sell them 2000 laptops, and that's all. However, those employees generally start with "easy to install" distros, such as fedora or similar. Those don't ship with standard kernels anyway, and they provide what is necessary to stay compatible with the tools which support crappy hardware. So (and it's sad), all those people don't care at all about kernel development, nor do they care about 2.6.13, 2.6.14, etc... It's just *us* who tell them "ah, you can't do that because you use a prehistorical kernel, let me install you the last one", and then and only then, that fails and we whine about the crappy hardware and the "easy to install" distro which seem to be made to work together. So I tend to consider that ndiswrapper users won't care about what will be in 2.6.14, but only about the fact that *their distro* will still support ndiswrapper. Of course, it would have been easier if the kernel would have stabilized and was only in maintenance mode, not breaking anything on every new release, but Linus has decided differently, so be it. Those users did not have a choice in the beginning, otherwise they would have chosen a laptop supported by Linux. And honnestly, I know plenty of them. In fact, it's the other way around. I know very few people who can actually choose their laptop. So you're both half-right from your point of view. But you're both half-wrong too : no, people can't always choose, and no, people who don't choose their laptop are not impacted by development kernels. So let's turn the page and wait for a stable kernel. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Sun, Sep 04, 2005 at 08:41:58PM -0700, Alex Davis wrote: > It will never be 'appropriate' if the system doesn't somehow work on Joe's > hardware. We currently have something that works. "works". As someone who gets to read a lot of bug reports from end-users, this thing is far from perfect judging by the number of tainted oopses I've seen, and not all of them look like stack size issues. The fact is these situations are undebuggable. Where does that leave users ? > Please explain how Linux can be an 'important force' if people can't > use it? Wireless networking is very important to people. There are plenty of cards available, which work just fine with free drivers. > Um, ever hear of 'compromise'?? All I'm saying is let people use what > currently works until we can get an open-source solution. Ndiswrapper's > existence is not stopping you (or anyone else) from pestering manufacturers > for spec's and writing drivers. I look at ndiswrapper as a stop-gap solution. A lot of users look at it as nirvana. I've seen users report bugs against ancient kernels, that are extremely likely to be fixed in later kernels, yet they're unwilling to move to a newer kernel due to them being tied to a driver that only works on an older kernel, despite the fact that there are known security and data corruption issues with the older kernels. Helping the cause of binary (or part binary) solutions doesn't solve anything. It brings nothing but unsolvable problems, and upset users when their problems can't get fixed. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: GFS, what's remaining
On Sat, Sep 03, 2005 at 10:41:40PM -0700, Andrew Morton wrote: > Joel Becker <[EMAIL PROTECTED]> wrote: > > > > > What happens when we want to add some new primitive which has no > > > posix-file analog? > > > > The point of dlmfs is not to express every primitive that the > > DLM has. dlmfs cannot express the CR, CW, and PW levels of the VMS > > locking scheme. Nor should it. The point isn't to use a filesystem > > interface for programs that need all the flexibility and power of the > > VMS DLM. The point is a simple system that programs needing the basic > > operations can use. Even shell scripts. > > Are you saying that the posix-file lookalike interface provides access to > part of the functionality, but there are other APIs which are used to > access the rest of the functionality? If so, what is that interface, and > why cannot that interface offer access to 100% of the functionality, thus > making the posix-file tricks unnecessary? We're using our dlm quite a bit in user space and require the full dlm API. It's difficult to export the full API through a pseudo fs like dlmfs, so we've not found it a very practical approach. That said, it's a nice idea and I'd be happy if someone could map a more complete dlm API onto it. We export our full dlm API through read/write/poll on a misc device. All user space apps use the dlm through a library as you'd expect. The library communicates with the dlm_device kernel module through read/write/poll and the dlm_device module talks with the actual dlm: linux/drivers/dlm/device.c If there's a better way to do this, via a pseudo fs or not, we'd be pleased to try it. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm tree
From: Andrew Morton <[EMAIL PROTECTED]> Date: Sun, 4 Sep 2005 14:42:18 -0700 > It seems a strange thing to check though. Do we really need it? Other platforms already do, it's a very good sanity check. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
On Mon, September 5, 2005 12:03 am, Alex Davis said: > > What if you don't have a choice? When someone comes to me with their > laptop > containing a built-in wireless card not natively supported by Linux, am I > supposed to tell them "go buy a Linux-supported card" when there's a way > I can make their existing card work? I don't think so. You always have a choice in life. Nobody is stopping you from doing what _you_ choose to do. That doesn't mean that developers who are concerned with the creation and promotion of open source should care one whit about your particular take on the situation. Go do whatever you want just don't expect the open source developers to pay for it; you maintain the crufty patches yourself. If you want to see the stupidity of your argument imagine someone going to Microsoft and saying... "look, if you'd simply stop charging for MS Windows more people would embrace it!" Do you think therefore microsoft should stop charging for Windows??? What if I wrote an email to them and said... "A friend of mine brings me his laptop to install Windows on it, but he can't afford a copy of Windows!!!" Do you think they should stop charging for Windows to help you out?? Get real. Please just do whatever you want and stop hoping that open source developers will ever care about your choice to embrace binary-only drivers. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm tree
From: Dave Jones <[EMAIL PROTECTED]>
Subject: Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm
tree
Date: Sun, 4 Sep 2005 16:23:33 -0400
> On Sun, Sep 04, 2005 at 01:16:00PM -0700, Andrew Morton wrote:
> > unsigned long __copy_to_user_ll(void __user *to, const void *from,
> unsigned long n)
> > {
> >BUG_ON((long) n < 0);
>
> Ehh? It's unsigned. This will never be true.
It's to catch the user slipping in enormous lengths to
the user copy routines.
Sparc64 makes this check as well. From U3memcpy.S:
srlx%o2, 31, %g2
cmp %g2, 0
tne %xcc, 5
%o2 is the length, we make sure the upper 33-bits are clear.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
--- Sean <[EMAIL PROTECTED]> wrote: > On Sun, September 4, 2005 11:41 pm, Alex Davis said: > > > It will never be 'appropriate' if the system doesn't somehow work on Joe's > > hardware. We currently have something that works. In my opinion it's > > pointless to take that away. The manufacturers will still stone-wall us > > regardless of ndiswrapper's existence. They were doing it before ndis- > > wrapper existed. > > There are lots and lots of systems where Linux works. Encouraging users > to buy hardware that works with Linux, can only help. Encouraging them > that it doesn't matter and that binary-only drivers are a good > alternative, can only hurt. > > > Please explain how Linux can be an 'important force' if people can't > > use it? Wireless networking is very important to people. > > Lots of people can and do use Linux without ANY binary drivers. There > are Wireless choices that don't require binary only drivers. What if you don't have a choice? When someone comes to me with their laptop containing a built-in wireless card not natively supported by Linux, am I supposed to tell them "go buy a Linux-supported card" when there's a way I can make their existing card work? I don't think so. > > Um, ever hear of 'compromise'?? All I'm saying is let people use what > > currently works until we can get an open-source solution. Ndiswrapper's > > existence is not stopping you (or anyone else) from pestering > > manufacturers > > for spec's and writing drivers. I look at ndiswrapper as a stop-gap > > solution. > > Hey, even Linus himself has said 'better a sub-optimal solution than no > > solution'. > > Nobody is stopping anyone from using what "currently works", there will be > lots of like minded people to provide crap kernels and shitty binary > drivers to people who don't know better. > So don't worry, your well > intentioned vision of the future will survive the removal of 8K stacks > from the kernel. > Regards, > Sean > > > I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET] 2.6.13-git3-bird1
While way overdue, "fixes and sparse annotations" tree is finally
going public. This version is basically a starting point - there will be
much more stuff to merge.
Right now it builds with allmodconfig[1] on the following set:
alpha (UP and SMP), amd64 (UP and SMP), arm (RPC, versatile), i386, ia64,
m32r, m68k (sans sun3), ppc (6xx, 44x, chestnut), ppc64, sparc, sparc64,
s390 (31 and 64bit) and uml (i386 and amd64)[2].
Amount of sparse and gcc4 warnings is moderate on all of the
above - there's no "drowns everything in noise" stuff left. There _are_
nasty areas (drm, some of the sata, several mem* helpers with constant
arguments), but at least that's easy to isolate. Tracking build log
changes for regressions had been fairly easy so far; quite a few chunks
in there (as well as already merged stuff) had been found that way,
so for now I'd say that it's usable.
Current patchset is on ftp.linux.org.uk/pub/people/viro/ -
patch-2.6.13-git3-bird1.bz2 is combined patch, patchset/* is the splitup.
Long description of patches is in patchset/set*, short log is in the end of
this posting. Current build and sparse logs are in logs/*/{log17b,S-log17b}.
Eventually I'll probably have to use rcs for them - they are large and change
slowly...
Patchset will change pretty fast; for one thing, most of the stuff
in there is easily mergable, for another - sparse patches here are just
dealing with the most annoying noise sources. There will be more and folks
are more than welcome to send sane annotation patches for merge.
Have fun - it's just getting started...
[1] configs being tracked are of allmodconfig-with-fixed-subset variety; e.g.
alpha-UP is "set as much as possible to y or m, with CONFIG_SMP not set", etc.
See config/* for currently tracked ones.
[2] toolkit for cross-toolchains will be re-posted on anonftp pretty soon;
ditto for details on cross-build setups, etc.
Short log of the current patchset follows:
linus-delta Changes in Linus' tree since -git3
Infrastructure:
I0-kconfig Teaches allmodconfig to pin a set of options in given
state [NB: rz has another variant; this is just a temporary]
I1-CHECKFLAGS Allows to add stuff to CHECKFLAGS from command line
I2-disable-DI disables CONFIG_DEBUG_INFO for test builds
Kconfig fixes:
B2-rio rio is too broken to mess with; marked as such
B7-floppy sanitized and fixed floppy dependencies
B12-broken-on-big-endiannew kconfig symbol: BROKEN_ON_BIG_ENDIAN.
B17-m32r-smccombination of M32R, SMC91X and ISA is broken
B22-mtd-xip MTD_XIP is there only for two subarchitectures of ARM - PXA
and SA1100 [not for merge; cleaner variant needed]
B23-83908390 fixes - part 1 (generic and arm/etherh)
B33-m68k-8390 8390 fixes - part 2 (m68k ones)
B41-s390-phyPHYLIB is broken on s390
B42-mga drm/mga is broken if AGP is not enabled
Pure compile fixes:
C0-envctrl envctrl fixes
C15-mv643xx_eth mv643xx_eth ifdefs [not for merge; dwmw2 has objections]
C32-segment missed gratitious includes of asm/segment.h
B40-mxser-sparc32 more sparc32 dependencies fallout
C33-mxser another missed asm/segment.h, real fix for problem B40 marks
C34-uli526x missing include in uli526x.c
C35-ipw2200 missing include (ipw2200)
C36-sunsu sunsu compile fixes
Misc bug fixes:
F6-zatm dereference of uninitialized pointer in zatm
Crap spotted by gcc and sparse:
O3-s2io-u64 s2io u64 use for uintptr_t
S0-chelsio chelsio sparse annotations
S1-e1000iomem annotations (e1000)
S2-s2io-iomem iomem annotations (s2io)
S3-ipw2100 iomem annotations, NULL noise removal (ipw2100)
S4-scsi-ch __user annotations (drivers/scsi/ch.c)
S5-ahci iomem annotations (ahci)
S6-sata_nv iomem annotations (sata_nv)
S7-sata_sx4 iomem annotations (sata_sx4)
S8-sata_qstor enum safety (sata_qstor)
S9-aaci iomem annotations (aaci)
S10-ethtool __user annotations (ethtool)
S14-m32r-user basic __user annotations (m32r)
S15-armv-iomem basic iomem annotations (arm-versatile)
S16-m32r-iomem missing basic iomem annotations (m32r)
S17-ia64-user missing basic __user annotations (ia64)
S18-rpc-iomem saner casts in arm-rpc IOMEM()
S19-sparse-m32r pass definition of __BIG_ENDIAN__ to sparse (m32r)
m68k patches:
C16-dmasound-lvalueslvalues abuse in dmasound
C17-dmasound-extern compile fixes for dmsound (static vs. extern)
C18-sun3intsstatic vs. extern in sun3ints.h
C19-sun3_pgtablebogus function argument types (sun3_pgtable.h)
C20-amigaints static vs. extern in amigaints.h
C21-atyfb-typo dumb typo in atyfb
C22-mac8390 lvalues abuse in mac8390
C23-lance lvalues abuse in lance
C24-82596-apricot wrong ifdefs in 82596
C25-scc static vs. extern in scc
C26-m68k-reset memory input should
[patch] i386 seccomp fix for auditing/ptrace
Hello,
This is the same issue as ppc64 before, when returning to userland we
shouldn't re-compute the seccomp check or the task could be killed
during sigreturn when orig_eax is overwritten by the sigreturn syscall.
This was found by Roland.
This was harmless from a security standpoint, but some i686 users
reported failures with auditing enabled system wide (some distro
surprisingly makes it the default) and I reproduced it too by keeping
the whole workload under strace -f.
Patch is tested and works for me under strace -f.
[EMAIL PROTECTED]:~/cpushare> strace -o /tmp/o -f python seccomp_test.py
make: Nothing to be done for `seccomp_test'.
Starting computing some malicious bytecode
init
load
start
stop
receive_data failure
kill
exit_code 0 signal 9
The malicious bytecode has been killed successfully by seccomp
Starting computing some safe bytecode
init
load
start
stop
174 counts
kill
exit_code 0 signal 0
The seccomp_test.py completed successfully, thank you for testing.
Thanks.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff -r 1df7bfbb783f arch/i386/kernel/ptrace.c
--- a/arch/i386/kernel/ptrace.c Fri Sep 2 09:01:35 2005
+++ b/arch/i386/kernel/ptrace.c Mon Sep 5 05:30:49 2005
@@ -680,8 +680,9 @@
__attribute__((regparm(3)))
void do_syscall_trace(struct pt_regs *regs, int entryexit)
{
- /* do the secure computing check first */
- secure_computing(regs->orig_eax);
+ if (!entryexit)
+ /* do the secure computing check first */
+ secure_computing(regs->orig_eax);
if (unlikely(current->audit_context) && entryexit)
audit_syscall_exit(current, AUDITSC_RESULT(regs->eax),
regs->eax);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Sep 4, 2005, at 23:41:58, Alex Davis wrote: --- Sean <[EMAIL PROTECTED]> wrote: It's not a philosophical issue, it's what Linux _is_: an open source operating system! That's what the developers are working on; not your half-baked vision. Um, ever hear of 'compromise'?? All I'm saying is let people use what currently works until we can get an open-source solution. Ndiswrapper's existence is not stopping you (or anyone else) from pestering manufacturers for spec's and writing drivers. I look at ndiswrapper as a stop-gap solution. Hey, even Linus himself has said 'better a sub-optimal solution than no solution'. In any case, this discussion is moot because the kernel API is changing for the better and there is a clearly defined fix for ndiswrapper that will allow it to continue to work even with the new interface: allocate a separate ndiswrapper stack (IE: Not the kernel stacks). The kernel is under no obligation not to break out-of-tree drivers, etc, even semi- non- -binary-only ones such as ndiswrapper. Figure out how to fix it and move on! Cheers, Kyle Moffett -- Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
On Sun, September 4, 2005 11:41 pm, Alex Davis said: > It will never be 'appropriate' if the system doesn't somehow work on Joe's > hardware. We currently have something that works. In my opinion it's > pointless to take that away. The manufacturers will still stone-wall us > regardless of ndiswrapper's existence. They were doing it before ndis- > wrapper existed. There are lots and lots of systems where Linux works. Encouraging users to buy hardware that works with Linux, can only help. Encouraging them that it doesn't matter and that binary-only drivers are a good alternative, can only hurt. > Please explain how Linux can be an 'important force' if people can't > use it? Wireless networking is very important to people. Lots of people can and do use Linux without ANY binary drivers. There are Wireless choices that don't require binary only drivers. > Um, ever hear of 'compromise'?? All I'm saying is let people use what > currently works until we can get an open-source solution. Ndiswrapper's > existence is not stopping you (or anyone else) from pestering > manufacturers > for spec's and writing drivers. I look at ndiswrapper as a stop-gap > solution. > Hey, even Linus himself has said 'better a sub-optimal solution than no > solution'. Nobody is stopping anyone from using what "currently works", there will be lots of like minded people to provide crap kernels and shitty binary drivers to people who don't know better. So don't worry, your well intentioned vision of the future will survive the removal of 8K stacks from the kernel. Regards, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
--- Sean <[EMAIL PROTECTED]> wrote: > On Sun, September 4, 2005 10:29 pm, Alex Davis said: > > > Linux isn't just used by kernel developers. It's that attitude that > > helps insure Linux will always have a small userbase. Lack of numbers > > just gives the manufacturers another reason not to care about us. Joe > > User doesn't care about our philosophical issues, nor should he. When > > I install Linux on someone's machine, he wants it to work NOW, not in > > some 'perfect-world' future. > > Alex, > > > Please stop the hand wringing over not being able to convince Joe User to > install Linux today. It will happen naturally when it's appropriate, It will never be 'appropriate' if the system doesn't somehow work on Joe's hardware. We currently have something that works. In my opinion it's pointless to take that away. The manufacturers will still stone-wall us regardless of ndiswrapper's existence. They were doing it before ndis- wrapper existed. > Linux is steadily growing in power and acceptance without binary drivers. > Trying to artificially speed up the process by destroying the very thing > that makes Linux an important force is actually counterproductive. Please explain how Linux can be an 'important force' if people can't use it? Wireless networking is very important to people. > It's not a philosophical issue, it's what Linux _is_: an open source > operating system! That's what the developers are working on; not your > half-baked vision. Um, ever hear of 'compromise'?? All I'm saying is let people use what currently works until we can get an open-source solution. Ndiswrapper's existence is not stopping you (or anyone else) from pestering manufacturers for spec's and writing drivers. I look at ndiswrapper as a stop-gap solution. Hey, even Linus himself has said 'better a sub-optimal solution than no solution'. > If you want to create some bastardized version and are > willing to commit dollars and effort to maintaining the code needed to do > so, feel free. > > Regards, > Sean > > > I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GFS, what's remaining
On Fri, Sep 02, 2005 at 10:28:21PM -0700, Greg KH wrote:
> On Fri, Sep 02, 2005 at 05:44:03PM +0800, David Teigland wrote:
> > On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
> >
> > > + gfs2_assert(gl->gl_sbd, atomic_read(&gl->gl_count) > 0,);
> >
> > > what is gfs2_assert() about anyway? please just use BUG_ON directly
> > > everywhere
> >
> > When a machine has many gfs file systems mounted at once it can be useful
> > to know which one failed. Does the following look ok?
> >
> > #define gfs2_assert(sdp, assertion) \
> > do { \
> > if (unlikely(!(assertion))) { \
> > printk(KERN_ERR \
> > "GFS2: fsid=%s: fatal: assertion \"%s\" failed\n" \
> > "GFS2: fsid=%s: function = %s\n"\
> > "GFS2: fsid=%s: file = %s, line = %u\n" \
> > "GFS2: fsid=%s: time = %lu\n", \
> > sdp->sd_fsname, # assertion, \
> > sdp->sd_fsname, __FUNCTION__,\
> > sdp->sd_fsname, __FILE__, __LINE__, \
> > sdp->sd_fsname, get_seconds()); \
> > BUG();\
>
> You will already get the __FUNCTION__ (and hence the __FILE__ info)
> directly from the BUG() dump, as well as the time from the syslog
> message (turn on the printk timestamps if you want a more fine grain
> timestamp), so the majority of this macro is redundant with the BUG()
> macro...
Joern already suggested moving this out of line and into a function (as it
was before) to avoid repeating string constants. In that case the
function, file and line from BUG aren't useful. We now have this, does it
look ok?
void gfs2_assert_i(struct gfs2_sbd *sdp, char *assertion, const char *function,
char *file, unsigned int line)
{
panic("GFS2: fsid=%s: fatal: assertion \"%s\" failed\n"
"GFS2: fsid=%s: function = %s, file = %s, line = %u\n",
sdp->sd_fsname, assertion,
sdp->sd_fsname, function, file, line);
}
#define gfs2_assert(sdp, assertion) \
do { \
if (unlikely(!(assertion))) { \
gfs2_assert_i((sdp), #assertion, \
__FUNCTION__, __FILE__, __LINE__); \
} \
} while (0)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm tree
From: Andrew Morton <[EMAIL PROTECTED]>
> Dave Jones <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, Sep 04, 2005 at 01:16:00PM -0700, Andrew Morton wrote:
> > > unsigned long __copy_to_user_ll(void __user *to, const void *from,
> > unsigned long n)
> > > {
> > > BUG_ON((long) n < 0);
> >
> > Ehh? It's unsigned. This will never be true.
>
> It's cast to long, so it'll trap if we try to copy >=2G.
>
> It seems a strange thing to check though. Do we really need it?
I don't know. I've just cut&paste the original __copy_from_user_ll()
Regards,
Hiro
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nfs4 client bug
On Sun, Sep 04, 2005 at 08:08:22PM -0700, Bret Towe wrote: > On 9/4/05, J. Bruce Fields <[EMAIL PROTECTED]> wrote: > > Do you get anything from alt-sysrq-T? > > no i havent used that im usally in x when its freezing > x wont even switch to console would it still give me anything then? Well, you can try something like: alt-sysrq-T wait a couple seconds, then alt-sysrq-S alt-sysrq-U alt-sysrq-B with maybe a second between each to give stuff a chance to get to disk. Then if you're lucky you may find the stack dumps in your log after you reboot. --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nfs4 client bug
On 9/4/05, J. Bruce Fields <[EMAIL PROTECTED]> wrote: > On Sun, Sep 04, 2005 at 01:51:08PM -0700, Bret Towe wrote: > > On 9/4/05, Bret Towe <[EMAIL PROTECTED]> wrote: > > > On 9/4/05, Francois Romieu <[EMAIL PROTECTED]> wrote: > > > > Bret Towe <[EMAIL PROTECTED]> : > > > > [...] > > > > > after moving some files on the server to a new location then trying to > > > > > add the files > > > > > to xmms playlist i found the following in dmesg after xmms froze > > > > > wonder how many more items i can find... > > > > > > > > The system includes some binary only stuff. Please contact your vendor > > > > or provide the traces for a configuration wherein the relevant module > > > > was not loaded after boot. It may make sense to get in touch with > > > > [EMAIL PROTECTED] then. > > > > > > the 'binary only stuff' is ati-drivers kernel module and it crashs > > > with or without it > > > ill provide a 'untainted' trace as soon as i can repeat the bug again > > > > ok without ati-drivers kernel module loaded the computer basicly just > > hard locks when > > some bug hits dunno if its the same item > > Do you get anything from alt-sysrq-T? no i havent used that im usally in x when its freezing x wont even switch to console would it still give me anything then? > > to repeat it tho one needs laptop-mode enabled have xmms playing music > > (flac in my case) > > which resides on nfs then just put the computer under some local load > > for a little bit > > till which im guessing it needs to clear some memory or somethin and > > it hits this hard lock > > or the errors i mailed previously when ati-drivers is loaded > > What kernel version is this? 2.6.13 > --b. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Old ipw2200 code in 2.6.13-git3 and 2.6.13-mm1
On Fri, Sep 02, 2005 at 08:48:28PM -0700, Miles Lane wrote: [snip] > Can we please get the latest IPW2200 code into the development kernels soon? Seconded. I haven't rebuilt the 1.0.6 code against the 2.6.13-git kernels, but my 2.6.13-rc4 build with 1.0.6 ipw2200 in it seems much more stable and dependable at starting up a network than 2.6.13-git-current does. (For example, I had to do a full power-cycle to get things working again after I ran into a "failed to send TX_POWER" issue - I've never seen that before, but I've never run the 1.0.0 driver before today.) -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dynticks - implement no idle hz for x86
On Mon, 5 Sep 2005 06:37 am, Nishanth Aravamudan wrote: > On 04.09.2005 [21:26:16 +0100], Russell King wrote: > > On Sun, Sep 04, 2005 at 01:10:54PM -0700, Nishanth Aravamudan wrote: > > > I've got a few ideas that I think might help push Con's patch > > > coalescing efforts in an arch-independent fashion. Thanks very much Nish! I've updated the patches here http://ck.kolivas.org/patches/dyn-ticks/ with the latest change to timer_pm.c that Srivatsa sent me and have a new rollup there as well as the split out patches. The ball is in Nish's court now so we'll avoid touching the code till you get back to us (this project needs some form of locking ;) ). Cheers, Con - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
On Sun, September 4, 2005 10:29 pm, Alex Davis said: > Linux isn't just used by kernel developers. It's that attitude that > helps insure Linux will always have a small userbase. Lack of numbers > just gives the manufacturers another reason not to care about us. Joe > User doesn't care about our philosophical issues, nor should he. When > I install Linux on someone's machine, he wants it to work NOW, not in > some 'perfect-world' future. Alex, I think you're wrong on just about all counts. The developers get to _dictate_ what goes into Linux because they're footing the bill. Their past performance shows that your worries are unfounded (as the vast acceptance of Linux long _before_ binary-only drivers even existed, shows). Please stop the hand wringing over not being able to convince Joe User to install Linux today. It will happen naturally when it's appropriate, Linux is steadily growing in power and acceptance without binary drivers. Trying to artificially speed up the process by destroying the very thing that makes Linux an important force is actually counterproductive. It's not a philosophical issue, it's what Linux _is_: an open source operating system! That's what the developers are working on; not your half-baked vision. If you want to create some bastardized version and are willing to commit dollars and effort to maintaining the code needed to do so, feel free. Regards, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
--- Sean <[EMAIL PROTECTED]> wrote: > On Sun, September 4, 2005 10:00 pm, Alex Davis said: > > Dave Jones wrote: > >>- NDISwrapper / driverloader. > >> (Shock, horror - no-one cares). > > > > Shock, horror. Someone DOES care: everyone who uses ndiswrapper or > > driverloader, whether they know it or not. Are you proposing that > > we punish the end-users because of the obstinence of the hardware > > manufacturers? If/when native drivers are written, maybe we can > > revisit this. > > > Continuing the promotion of binary-only drivers _hurts_ the demand for > (and thus the development of) open source drivers. Read the comment from > Dave as something like "Nobody who matters, with regard to kernel > development, cares about NDISwrapper". If _you_ care, fork your own tree > and maintain the patch as necessary. > > Regards, > Sean Sean: Linux isn't just used by kernel developers. It's that attitude that helps insure Linux will always have a small userbase. Lack of numbers just gives the manufacturers another reason not to care about us. Joe User doesn't care about our philosophical issues, nor should he. When I install Linux on someone's machine, he wants it to work NOW, not in some 'perfect-world' future. -Alex -Alex > I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ipw2200: Missing kmalloc check
The ipw2200 driver code in current GIT contains a kmalloc() followed by
a memset() without handling a possible memory allocation failure.
Signed-off-by: Panagiotis Issaris <[EMAIL PROTECTED]>
---
drivers/net/wireless/ipw2200.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
8e288419b49346fee512739acac446c951727d04
diff --git a/drivers/net/wireless/ipw2200.c
b/drivers/net/wireless/ipw2200.c
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -3976,6 +3976,10 @@ static struct ipw_rx_queue *ipw_rx_queue
int i;
rxq = (struct ipw_rx_queue *)kmalloc(sizeof(*rxq), GFP_KERNEL);
+ if (unlikely(!rxq)) {
+ IPW_ERROR("memory allocation failed\n");
+ return NULL;
+ }
memset(rxq, 0, sizeof(*rxq));
spin_lock_init(&rxq->lock);
INIT_LIST_HEAD(&rxq->rx_free);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
On Sun, September 4, 2005 10:00 pm, Alex Davis said: > Dave Jones wrote: >>- NDISwrapper / driverloader. >> (Shock, horror - no-one cares). > > Shock, horror. Someone DOES care: everyone who uses ndiswrapper or > driverloader, whether they know it or not. Are you proposing that > we punish the end-users because of the obstinence of the hardware > manufacturers? If/when native drivers are written, maybe we can > revisit this. Continuing the promotion of binary-only drivers _hurts_ the demand for (and thus the development of) open source drivers. Read the comment from Dave as something like "Nobody who matters, with regard to kernel development, cares about NDISwrapper". If _you_ care, fork your own tree and maintain the patch as necessary. Regards, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
Dave Jones wrote: >- NDISwrapper / driverloader. > (Shock, horror - no-one cares). Shock, horror. Someone DOES care: everyone who uses ndiswrapper or driverloader, whether they know it or not. Are you proposing that we punish the end-users because of the obstinence of the hardware manufacturers? If/when native drivers are written, maybe we can revisit this. I code, therefore I am __ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pcihpd-discuss] Re: ACPI problem with PCI Express Native Hot-plug driver
> > Hello, > Would you be willing to test the mainline kernel (2.6.13) to see if you > have the same problem with the most recent version of the driver? And > attach the logs again please. > > Thanks, > Kristen > > Thanks, for the inputs. I will test it with 2.6.13 and get back. Rajat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Mon, 5 Sep 2005, Adrian Bunk wrote: > How do you put pressure on hardware manufacturers for getting them to > release the specs? > > If they are able to write "supported by Linux" on their products anyway > because there's a driver that runs under NdisWrapper? that's specious... they can put "supported by Linux" on their products by supplying a binary-only driver too... ndiswrapper is orthogonal to that problem. on a tangent... has there been any further research/work on page clustering? wli's patches haven't been updated in a while... it's another way to supply larger stacks. (hell with 16KiB "pages" i'd be stoked to "waste" the bottom 4KiB of each stack with an unmapped page to ensure overflow is detected.) -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Brand-new notebook useless with Linux...
On Sat, 2005-09-03 at 18:58 -0400, Chuck Ebbert wrote:
> I just bought a new notebook. Here is the output from lspci using the latest
> pci.ids file from sourceforge:
>
> 00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 01)
> 00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 5a3f
> 00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
> 00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller
> 00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller
> 00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 11)
> 00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE
> Controller ATI
> 00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge
> 00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge
> 00:14.5 Multimedia audio controller: ATI Technologies Inc IXP SB400 AC'97
> Audio Controller (rev 02)
This is an ac97, try the intel sound driver.
> 00:14.6 Modem: ATI Technologies Inc: Unknown device 4378 (rev 02)
No Way.
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
> HyperTransport Technology Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
> Address Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
> Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
> Miscellaneous Control
> 01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS
> 200M 5955 (PCIE)
> 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
Should work.
> 05:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g]
> 802.11g Wireless LAN Controller (rev 02)
linuxant.com or ndiswrapper. I believe they do not have a driver for
Linux.
> 05:09.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
> 05:09.2 FireWire (IEEE 1394): Texas Instruments OHCI Compliant IEEE 1394 Host
> Controller
> 05:09.3 Mass storage controller: Texas Instruments PCIxx21 Integrated
> FlashMedia Controller
> 05:09.4 Class 0805: Texas Instruments PCI6411, PCI6421, PCI6611, PCI6621,
> PCI7411, PCI7421, PCI7611, PCI7621 Secure Digital (SD) Controller
>
> None of these work and I can find no support anywhere for them:
>
> SMBus
> Audio ("unknown codec")
> Modem ("no codec available")
> Wireless
> FlashMedia
Doubt it.
> SD/MMC
Doubt it.
>
> Additionally, the system clock runs at 2x normal speed with PowerNow enabled.
Most likely an ACPI or Windowish ACPI with your laptop.
You are not even saying which laptop you are with. Check google and the
linux on laptops website.
.Alejandro
>
> Am I stuck with running XP on this thing?
>
> __
> Chuck
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: i386: kill !4KSTACKS
On Sun, Sep 04, 2005 at 06:30:29PM -0700, Alex Davis wrote: > >The NdisWrapper FAQ already tells you that you need a patch for some of > >the binary-only Windows drivers that require more than 8kB stacks. > > > >And the fact that NdisWrapper is mostly working hinders the development > >of open source drivers for this hardware. > > If the hardware manufacturer won't give you the spec's then writing a driver > is going to be pretty difficult, if not impossible. Reverse-engineering > may be possible, but still > > I believe it's the lack of spec's, rather than the existence of ndiswrapper > and driverloader, that hinder driver development. How do you put pressure on hardware manufacturers for getting them to release the specs? If they are able to write "supported by Linux" on their products anyway because there's a driver that runs under NdisWrapper? Or if people return/don't buy the hardware because of missing Linux support reducing the revenue of the hardware manufacturer by some $$ ? > -Alex cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
re: RFC: i386: kill !4KSTACKS
>The NdisWrapper FAQ already tells you that you need a patch for some of >the binary-only Windows drivers that require more than 8kB stacks. > >And the fact that NdisWrapper is mostly working hinders the development >of open source drivers for this hardware. If the hardware manufacturer won't give you the spec's then writing a driver is going to be pretty difficult, if not impossible. Reverse-engineering may be possible, but still I believe it's the lack of spec's, rather than the existence of ndiswrapper and driverloader, that hinder driver development. -Alex I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RAID1 ramdisk patch
On Monday September 5, [EMAIL PROTECTED] wrote: > Hi all, > > I have written a small patch for use with a HDD-backed ramdisk in the md > raid1 driver. The raid1 driver usually does read balancing on the disks, > but I feel that if it encounters a single ram disk in the array that > should be the preferred read disk. The application of this would be for > example a 2GB ram disk in raid1 with a 2GB partition, where the ram disk > is used for reading and both 'disks' used for writing. > > Attached is a bit of code which checks for a ram-disk and sets it as > preferred disk. It also checks if the ram disk is in sync before > allowing the read. Hi, equivalent functionality is now available in 2.6-mm and is referred to as 'write mostly'. If you use mdadm-2.0 and mark a device as --write-mostly, then all read requests will go to the other device(s) if possible,. e.g. mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/ramdisk \ --writemostly /dev/realdisk Does this suit your needs? You can also arrange for the write to the writemostly device to be 'write-behind' so that the filesystem doesn't wait for the write to complete. This can reduce write-latency (though not increase write throughput) at a very small cost of reliability (if the RAM dies, the disk may not be 100% up-to-date). NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RAID1 ramdisk patch
Hi all,
I have written a small patch for use with a HDD-backed ramdisk in the md
raid1 driver. The raid1 driver usually does read balancing on the disks,
but I feel that if it encounters a single ram disk in the array that
should be the preferred read disk. The application of this would be for
example a 2GB ram disk in raid1 with a 2GB partition, where the ram disk
is used for reading and both 'disks' used for writing.
Attached is a bit of code which checks for a ram-disk and sets it as
preferred disk. It also checks if the ram disk is in sync before
allowing the read.
PS. I am not this list, please CC me if a reply were to be made.
Regards,
Wilco Baan Hofman
diff -urN linux-2.6.13-rc6.orig/include/linux/raid/raid1.h
linux-2.6.13-rc6/include/linux/raid/raid1.h
--- linux-2.6.13-rc6.orig/include/linux/raid/raid1.h2005-08-07
20:18:56.0 +0200
+++ linux-2.6.13-rc6/include/linux/raid/raid1.h 2005-09-04 11:41:24.0
+0200
@@ -32,6 +32,7 @@
int raid_disks;
int working_disks;
int last_used;
+ int preferred_read_disk;
sector_tnext_seq_sect;
spinlock_t device_lock;
diff -urN linux-2.6.13-rc6.orig/drivers/md/raid1.c
linux-2.6.13-rc6/drivers/md/raid1.c
--- linux-2.6.13-rc6.orig/drivers/md/raid1.c2005-08-07 20:18:56.0
+0200
+++ linux-2.6.13-rc6/drivers/md/raid1.c 2005-09-05 01:54:26.0 +0200
@@ -21,6 +21,8 @@
* Additions to bitmap code, (C) 2003-2004 Paul Clements, SteelEye Technology:
* - persistent bitmap code
*
+ * Special handling of ramdisk (C) 2005 Wilco Baan Hofman <[EMAIL PROTECTED]>
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2, or (at your option)
@@ -399,8 +401,6 @@
goto rb_out;
}
}
- disk = new_disk;
- /* now disk == new_disk == starting point for search */
/*
* Don't change to another disk for sequential reads:
@@ -409,7 +409,18 @@
goto rb_out;
if (this_sector == conf->mirrors[new_disk].head_position)
goto rb_out;
-
+
+ /* [SYN] If the preferred disk exists, return it */
+ if (conf->preferred_read_disk != -1 &&
+
(new_rdev=conf->mirrors[conf->preferred_read_disk].rdev) != NULL &&
+ new_rdev->in_sync) {
+ new_disk = conf->preferred_read_disk;
+ goto rb_out;
+ }
+
+ disk = new_disk;
+ /* now disk == new_disk == starting point for search */
+
current_distance = abs(this_sector - conf->mirrors[disk].head_position);
/* Find the disk whose head is closest */
@@ -1292,10 +1303,11 @@
static int run(mddev_t *mddev)
{
conf_t *conf;
- int i, j, disk_idx;
+ int i, j, disk_idx, ram_count;
mirror_info_t *disk;
mdk_rdev_t *rdev;
struct list_head *tmp;
+ char b[BDEVNAME_SIZE];
if (mddev->level != 1) {
printk("raid1: %s: raid level not set to mirroring (%d)\n",
@@ -1417,6 +1429,30 @@
mddev->queue->unplug_fn = raid1_unplug;
mddev->queue->issue_flush_fn = raid1_issue_flush;
+ /* [SYN] if there is a ram disk, that will be the preferred disk.
+* .. unless there are multiple ram disks. */
+ conf->preferred_read_disk = -1;
+ for (i = 0,
+ram_count = 0;
+i < mddev->raid_disks;
+i++) {
+
+ bdevname(conf->mirrors[i].rdev->bdev, b);
+ if (strncmp(b, "ram", 3) == 0) {
+ if (ram_count) {
+ conf->preferred_read_disk = -1;
+ break;
+ }
+ conf->preferred_read_disk = i;
+ ram_count++;
+ }
+ }
+ if (conf->preferred_read_disk >= 0) {
+ printk(KERN_INFO
+ "raid1: One ram disk (%s) found, setting it preferred
read disk.\n", b);
+ }
+
+
return 0;
out_no_mem:
Re: [DVB patch 51/54] ttpci: av7110: RC5+ remote control support
On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Sun, Sep 04, 2005 Nish Aravamudan wrote: > > On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > > > On Sun, Sep 04, 2005 Nish Aravamudan wrote: > > > > On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > > > > > > > > > > -#define UP_TIMEOUT (HZ/4) > > > > > +#define UP_TIMEOUT (HZ*7/25) > > > > > > > > #define UP_TIMEOUT msecs_to_jiffies(280) > > > > #define UP_TIMEOUT (7*msecs_to_jiffies(40) > > > > > > I agree it's nicer to read, but AFAIK not required for correctness? > > > If so, then we'll fix those up in linuxtv.org CVS and submit > > > cleanup patches later. > > > > Yeah, it's correct with the three current values of HZ (100, 250 and > > 1000), but if you try a not-so-clean value (like Con did with 864, or > > something), you might run into rounding issues. msecs_to_jiffies() > > should take care of them (or will be a single point to do so > > eventually). > > Well, if msecs_to_jiffies() is the new way of specifying timeouts > we'd have a lot more to fix up in our tree. But something like > a remote control key-up timeout doesn't need much precision. > Generally I see nothing wrong with HZ/4, but something like > HZ*20/1000 could be problematic with small or odd HZ values. This discussion comes up every time ;) HZ/4 rounds incorrectly (depends on your perspective, I guess) with HZ=250. > Agreed? Or is it desired that people generally use msecs_to_jiffies()? I agree, generally it's ok, as timeouts aren't meant to be precise. I, personally, am converting code over to msecs_to_jiffies() as I come to it, just so that the conversions are consistent (a number in the tree were not, not that yours are) and basically self-commented. And, like I mentioned, they are automatically rounded correctly with "strange" values of HZ. The changes I mentioned in your patchset are generally not critical, but just comments and my own preferences. Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DVB patch 51/54] ttpci: av7110: RC5+ remote control support
On Sun, Sep 04, 2005 Nish Aravamudan wrote: > On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > > On Sun, Sep 04, 2005 Nish Aravamudan wrote: > > > On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > > > > > > > > -#define UP_TIMEOUT (HZ/4) > > > > +#define UP_TIMEOUT (HZ*7/25) > > > > > > #define UP_TIMEOUT msecs_to_jiffies(280) > > > #define UP_TIMEOUT (7*msecs_to_jiffies(40) > > > > I agree it's nicer to read, but AFAIK not required for correctness? > > If so, then we'll fix those up in linuxtv.org CVS and submit > > cleanup patches later. > > Yeah, it's correct with the three current values of HZ (100, 250 and > 1000), but if you try a not-so-clean value (like Con did with 864, or > something), you might run into rounding issues. msecs_to_jiffies() > should take care of them (or will be a single point to do so > eventually). Well, if msecs_to_jiffies() is the new way of specifying timeouts we'd have a lot more to fix up in our tree. But something like a remote control key-up timeout doesn't need much precision. Generally I see nothing wrong with HZ/4, but something like HZ*20/1000 could be problematic with small or odd HZ values. Agreed? Or is it desired that people generally use msecs_to_jiffies()? Johannes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11.11 and rsync oops (SATA related?)
Hi, there. Long time no posting - didn't have kernel problems for long time :-) That is why I am still running 2.6.11.11 (2.6.12 elsewhere). Will move to 2.6.13 soon. Yesterday just bought a new SATAII drive (Seagate Barracuda 7200.8 ST3300831AS) and while trying to rsync some data from the old drives the rsync process died with segfault. My SiI3112 controller is not SATAII, but it should work in SATA mode, have another drive for year+. Looking at the dmesg I saw 3 oopses (see the shortened .dmesg file). Run the ksymoops and got some output (see .ksymoops.bz2). Although it does not seem very related to the drive, that is the only recent change in hardware, in software: udev . The machine (MB: A7V8X Deluxe) was working stable for 6 months with a few restarts. As far as reproducibility goes, apart from those 3 oopses everything is OK, didn't even have to restart and am now continuing to rsync some 200GB more. Any ideas as to what caused this? Kalin. P.S. Attaching the files :-| -- |[ ~~ ]| +-> http://ThinRope.net/ <-+ |[ __ ]| Linux version 2.6.11.11-dorf ([EMAIL PROTECTED]) (gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #1 Sun May 29 01:39:53 JST 2005 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx NFORCE2: IDE controller at PCI slot :00:09.0 NFORCE2: chipset revision 162 NFORCE2: not 100% native mode: will probe irqs later NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround. NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround. NFORCE2: :00:09.0 (rev a2) UDMA133 controller ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA Probing IDE interface ide0... hda: WDC WD1000BB-00CAA0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: WDC WD2000JB-00DUA0, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 SiI3112 Serial ATA: IDE controller at PCI slot :01:0b.0 SiI3112 Serial ATA: chipset revision 2 SiI3112 Serial ATA: 100% native mode on irq 18 ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio Probing IDE interface ide2... hde: WDC WD360GD-00FLA0, ATA DISK drive ide2 at 0xf8802080-0xf8802087,0xf880208a on irq 18 Probing IDE interface ide3... hdg: ST3300831AS, ATA DISK drive hdg: applying pessimistic Seagate errata fix ide3 at 0xf88020c0-0xf88020c7,0xf88020ca on irq 18 Probing IDE interface ide4... Probing IDE interface ide5... hda: max request size: 128KiB hda: 195371568 sectors (100030 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes not supported hda: hda1 hda2 hda3 hda4 < hda5 hda6 > hdc: max request size: 1024KiB hdc: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(100) hdc: cache flushes supported hdc: hdc1 hdc2 hdc3 < hdc5 hdc6 > hdc4 hde: max request size: 64KiB hde: 72303840 sectors (37019 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(133) hde: cache flushes supported hde: hde1 hde2 hdg: max request size: 7KiB hdg: 586072368 sectors (300069 MB) w/8192KiB Cache, CHS=36481/255/63 hdg: cache flushes supported hdg: hdg1 RPC: error 5 connecting to server 127.0.0.1 RPC: error 5 connecting to server 127.0.0.1 Unable to handle kernel NULL pointer dereference at virtual address 0108 printing eip: c013249b *pde = Oops: [#1] PREEMPT Modules linked in: ipt_TCPMSS ipt_REJECT ipt_state iptable_filter iptable_mangle ppp_synctty ppp_async ppp_generic slhc w83l785ts asb100 i2c_sensor i2c_nforce2 i2c_core ext3 jbd mbcache ip_nat_ftp iptable_nat ip_tables ip_conntrack_ftp ip_conntrack forcedeth via_rhine mii ehci_hcd ohci_hcd usbcore ipv6 CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010213 (2.6.11.11-dorf) EIP is at page_waitqueue+0x1b/0x30 eax: 580da100 ebx: c10da100 ecx: 0020 edx: esi: 0002 edi: 000e ebp: c1b53f40 esp: c1b53d90 ds: 007b es: 007b ss: 0068 Process pdflush (pid: 193, threadinfo=c1b52000 task=c198a570) Stack: c0132573 c10da100 c10da100 c01779bd c1106fa0 c1b53f40 c1b53dd4 000e f7c0e5b0 0001 c019ac60 f7c2068c 20a6 000e c10d6120 Call Trace: [] unlock_page+0x23/0x40 [] mpage_writepages+0x21d/0x3e0 [] reiserfs_writepage+0x0/0x40 [] do_writepages+0x3d/0x50 [] __sync_single_inode+0x71/0x220 [] __writeback_single_inode+0x67/0x150 [] handle_IRQ_event+0x30/0x70 [] __do_IRQ+0xf4/0x160 [] sync_sb_inodes+0x197/0x2a0 [] writeback_inodes+0xd4/0xf0 [] background_writeout+0x73/0xc0 [] __pdflush+0xca/0x1c0 [] pdflush+0x0/0x30 [] pdflush+0x28/0x30 [] background_writeout+0x0/0xc0 [] pdflush+0x0/0x30 [] kthread+0xa5/0xb0 [] kthread+0x0/0xb0 [] kernel_thread_helper+0x5/0x14 Code: c4 18 c3 89 f0 e8 d6 9c 00 00 eb e9 8d
Re: [DVB patch 54/54] ttusb-budget: use time_after_eq()
On Sun, Sep 04, 2005 Nish Aravamudan wrote:
> On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> > On Sun, Sep 04, 2005 Nish Aravamudan wrote:
> > > On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> > > >
> > > > -static int numpkt = 0, lastj, numts, numstuff, numsec, numinvalid;
> > > > +static int numpkt = 0, numts, numstuff, numsec, numinvalid;
> > > > +static unsigned long lastj;
> > > >
> > >
> > > I think you actually want:
> > >
> > > static void ttusb_iso_irq()
> > > {
> > > unsigned long lastj;
> > >
> >
> > The code in question is used to print a one-per-second debug output,
> > and lastj is assigned after every print.
>
> Ah yes, didn't see that in the current code, sorry for that noise.
> Still, lastj is local to ttusb_iso_irq(), right?
Yes, but it needs to be static.
Johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [DVB patch 54/54] ttusb-budget: use time_after_eq()
On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 04, 2005 Nish Aravamudan wrote:
> > On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> > >
> > > -static int numpkt = 0, lastj, numts, numstuff, numsec, numinvalid;
> > > +static int numpkt = 0, numts, numstuff, numsec, numinvalid;
> > > +static unsigned long lastj;
> > >
> > > static void ttusb_process_muxpack(struct ttusb *ttusb, const u8 *
> > > muxpack,
> > >int len)
> > > @@ -779,7 +781,7 @@ static void ttusb_iso_irq(struct urb *ur
> > > u8 *data;
> > > int len;
> > > numpkt++;
> > > - if ((jiffies - lastj) >= HZ) {
> > > + if (time_after_eq(jiffies, lastj + HZ)) {
> >
> > I think you actually want:
> >
> > static void ttusb_iso_irq()
> > {
> > unsigned long lastj;
> >
> > ...
> >
> > lastj = jiffies + HZ;
> > if (time_after_eq(jiffies, lastj)) {
> > ...
> >
> > }
> >
> > The current code doesn't assign jiffies to lastj at any point that I see.
>
> The code in question is used to print a one-per-second debug output,
> and lastj is assigned after every print.
Ah yes, didn't see that in the current code, sorry for that noise.
Still, lastj is local to ttusb_iso_irq(), right?
> I agree that it's ugly, though.
Fair enough :)
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [DVB patch 51/54] ttpci: av7110: RC5+ remote control support
On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > On Sun, Sep 04, 2005 Nish Aravamudan wrote: > > On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > > > --- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/av7110_ir.c > > > 2005-09-04 22:03:40.0 +0200 > > > +++ linux-2.6.13-git4/drivers/media/dvb/ttpci/av7110_ir.c > > > 2005-09-04 22:31:00.0 +0200 > > > @@ -7,16 +7,16 @@ > > > #include > > > > > > #include "av7110.h" > > > +#include "av7110_hw.h" > > > > > > -#define UP_TIMEOUT (HZ/4) > > > +#define UP_TIMEOUT (HZ*7/25) > > > > Should this be > > > > #define UP_TIMEOUT msecs_to_jiffies(280) > > > > or > > > > #define UP_TIMEOUT (7*msecs_to_jiffies(40) > > > > ? > > I agree it's nicer to read, but AFAIK not required for correctness? > If so, then we'll fix those up in linuxtv.org CVS and submit > cleanup patches later. Yeah, it's correct with the three current values of HZ (100, 250 and 1000), but if you try a not-so-clean value (like Con did with 864, or something), you might run into rounding issues. msecs_to_jiffies() should take care of them (or will be a single point to do so eventually). Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.11.11 and rsync oops (SATA related?)
Hi, there. Long time no posting - didn't have kernel problems for long time :-) That is why I am still running 2.6.11.11 (2.6.12 elsewhere). Will move to 2.6.13 soon. Yesterday just bought a new SATAII drive (Seagate Barracuda 7200.8 ST3300831AS) and while trying to rsync some data from the old drives the rsync process died with segfault. My SiI3112 controller is not SATAII, but it should work in SATA mode, have another drive for year+. Looking at the dmesg I saw 3 oopses (see the shortened .dmesg file). Run the ksymoops and got some output (see .ksymoops.bz2). Although it does not seem very related to the drive, that is the only recent change in hardware, in software: udev . The machine (MB: A7V8X Deluxe) was working stable for 6 months with a few restarts. As far as reproducibility goes, apart from those 3 oopses everything is OK, didn't even have to restart and am now continuing to rsync some 200GB more. Any ideas as to what caused this? Kalin. -- |[ ~~ ]| +-> http://ThinRope.net/ <-+ |[ __ ]| - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11.11 and rsync oops (SATA related?)
On 9/5/05, Kalin KOZHUHAROV <[EMAIL PROTECTED]> wrote: > Hi, there. > Long time no posting - didn't have kernel problems for long time :-) > > That is why I am still running 2.6.11.11 (2.6.12 elsewhere). Will move > to 2.6.13 soon. > > Yesterday just bought a new SATAII drive (Seagate Barracuda 7200.8 > ST3300831AS) and while trying to rsync some data from the old drives the > rsync process died with segfault. My SiI3112 controller is not SATAII, > but it should work in SATA mode, have another drive for year+. Looking > at the dmesg I saw 3 oopses (see the shortened .dmesg file). Run the > ksymoops and got some output (see .ksymoops.bz2). > It seems you forgot to include the data. Nothing inline in the email, nor any attachments. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DVB patch 51/54] ttpci: av7110: RC5+ remote control support
On Sun, Sep 04, 2005 Nish Aravamudan wrote: > On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > > --- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/av7110_ir.c 2005-09-04 > > 22:03:40.0 +0200 > > +++ linux-2.6.13-git4/drivers/media/dvb/ttpci/av7110_ir.c 2005-09-04 > > 22:31:00.0 +0200 > > @@ -7,16 +7,16 @@ > > #include > > > > #include "av7110.h" > > +#include "av7110_hw.h" > > > > -#define UP_TIMEOUT (HZ/4) > > +#define UP_TIMEOUT (HZ*7/25) > > Should this be > > #define UP_TIMEOUT msecs_to_jiffies(280) > > or > > #define UP_TIMEOUT (7*msecs_to_jiffies(40) > > ? I agree it's nicer to read, but AFAIK not required for correctness? If so, then we'll fix those up in linuxtv.org CVS and submit cleanup patches later. Thanks for your comments. Johannes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13 locks my machine within 1h, 2.6.12.5 works fine (PREEMPT?)
I get the exact same thing. Here is my config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13 # Mon Aug 29 20:06:23 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_HPET_TIMER is not set # CONFIG_SMP is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_REGPARM is not set CONFIG_SECCOMP=y CONFIG_HZ_100=y # CONFIG_HZ_250 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=100 CONFIG_PHYSICAL_START=0x10 CONFIG_KEXEC=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m CONFIG_ACPI_HOTKEY=m CONFIG_ACPI_FAN=m CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=95 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HO
Re: [DVB patch 23/54] usb: add TwinhanDTV StarBox support
On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> From: Patrick Boettcher <[EMAIL PROTECTED]>
>
> Add driver for the TwinhanDTV StarBox and clones.
>
> Thanks to Ralph Metzler for his initial work on this box and thanks to Twinhan
> for their support.
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-2.6.13-git4/drivers/media/dvb/dvb-usb/vp702x-fe.c 2005-09-04
> 22:28:15.0 +0200
> +static int vp702x_fe_refresh_state(struct vp702x_fe_state *st)
> +{
> + u8 buf[10];
> + if (time_after(jiffies,st->next_status_check)) {
> + vp702x_usb_in_op(st->d,READ_STATUS,0,0,buf,10);
> +
> + st->lock = buf[4];
> + vp702x_usb_in_op(st->d,READ_TUNER_REG_REQ,0x11,0,&st->snr,1);
> + vp702x_usb_in_op(st->d,READ_TUNER_REG_REQ,0x15,0,&st->sig,1);
> +
> + st->next_status_check = jiffies +
> (st->status_check_interval*HZ)/1000;
Should this be
st->next_status_check = jiffies + msecs_to_jiffies(st->status_check_interval);
?
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [DVB patch 54/54] ttusb-budget: use time_after_eq()
On Sun, Sep 04, 2005 Nish Aravamudan wrote:
> On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> >
> > -static int numpkt = 0, lastj, numts, numstuff, numsec, numinvalid;
> > +static int numpkt = 0, numts, numstuff, numsec, numinvalid;
> > +static unsigned long lastj;
> >
> > static void ttusb_process_muxpack(struct ttusb *ttusb, const u8 * muxpack,
> >int len)
> > @@ -779,7 +781,7 @@ static void ttusb_iso_irq(struct urb *ur
> > u8 *data;
> > int len;
> > numpkt++;
> > - if ((jiffies - lastj) >= HZ) {
> > + if (time_after_eq(jiffies, lastj + HZ)) {
>
> I think you actually want:
>
> static void ttusb_iso_irq()
> {
> unsigned long lastj;
>
> ...
>
> lastj = jiffies + HZ;
> if (time_after_eq(jiffies, lastj)) {
> ...
>
> }
>
> The current code doesn't assign jiffies to lastj at any point that I see.
The code in question is used to print a one-per-second debug output,
and lastj is assigned after every print.
I agree that it's ugly, though.
Johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] disable_local_APIC() is only available when CONFIG_X86_LOCAL_APIC is defined
`disable_local_APIC' is only available when CONFIG_X86_LOCAL_APIC is defined : arch/i386/kernel/crash.c: In function `crash_nmi_callback': arch/i386/kernel/crash.c:153: warning: implicit declaration of function `disable_local_APIC' arch/i386/kernel/crash.c: In function `nmi_shootdown_cpus': arch/i386/kernel/crash.c:195: warning: implicit declaration of function `disable_local_APIC' There may be a better fix, but the below seems to do the trick. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- linux-2.6.13-mm1-orig/arch/i386/kernel/crash.c 2005-09-02 23:59:27.0 +0200 +++ linux-2.6.13-mm1/arch/i386/kernel/crash.c 2005-09-05 01:54:21.0 +0200 @@ -150,7 +150,9 @@ static int crash_nmi_callback(struct pt_ regs = &fixed_regs; } crash_save_this_cpu(regs, cpu); +#ifdef CONFIG_X86_LOCAL_APIC disable_local_APIC(); +#endif atomic_dec(&waiting_for_crash_ipi); /* Assume hlt works */ halt(); @@ -190,7 +192,9 @@ static void nmi_shootdown_cpus(void) } /* Leave the nmi callback set */ +#ifdef CONFIG_X86_LOCAL_APIC disable_local_APIC(); +#endif } #else static void nmi_shootdown_cpus(void) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [DVB patch 14/54] frontend: s5h1420: fixes
On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote: > From: Andrew de Quincey <[EMAIL PROTECTED]> > > Misc. fixes. > --- linux-2.6.13-git4.orig/drivers/media/dvb/frontends/s5h1420.c > 2005-09-04 22:24:24.0 +0200 > +++ linux-2.6.13-git4/drivers/media/dvb/frontends/s5h1420.c 2005-09-04 > 22:28:04.0 +0200 @@ -138,16 +146,17 @@ static int s5h1420_send_master_cmd (stru > /* wait for transmission to complete */ > timeout = jiffies + ((100*HZ) / 1000); > @@ -236,7 +246,7 @@ static int s5h1420_send_burst (struct dv > s5h1420_writereg(state, 0x3b, s5h1420_readreg(state, 0x3b) | 0x08); > > /* wait for transmission to complete */ > - timeout = jiffies + ((20*HZ) / 1000); > + timeout = jiffies + ((100*HZ) / 1000); Should these be timeout = jiffies + msecs_to_jiffies(100); ? Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Potential IPSec DoS/Kernel Panic with 2.6.13
I did a direct serial connection and boy was that a lot easier. Anyway,
without further adeu, the crash:
#
Unable to handle kernel paging request at virtual address 50c86502
printing eip:
c01bd216
*pde =
Oops: [#1]
PREEMPT
Modules linked in: aes_i586 esp6 ah6 ipcomp esp4 ah4 af_key xfrm_user
michael_mic deflate twofish khazad wp512 arc4 serpent tea sha512 blowfish
sha256 md5 md4 cast6 cast5 des crypto_null zlib_deflate ipv6 ipt_ULOG
ipt_REJECT ipt_LOG ipt_state ipt_pkttype ipt_CONNMARK ipt_connmark ipt_owner
ipt_recent ipt_iprange ipt_multiport ip_nat_irc ip_nat_tftp ip_conntrack_irc
ip_conntrack_tftp evdev floppy pcspkr intel_agp via_rhine mii tulip agpgart
psmouse ide_cd cdrom
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010216 (2.6.13-Firewall.CyberDog.v12)
EIP is at sha1_update+0x96/0xe0
eax: cd485f0c ebx: 000c ecx: 0003 edx: 0244
esi: 50c86502 edi: cd485f5c ebp: 50c86502 esp: c0333c40
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c0332000 task=c02edb80)
Stack: 0244 cd485f0c
Call Trace:
[] update+0x91/0xd0
[] crypto_hmac_update+0x11/0x20
[] skb_icv_walk+0xe3/0x200
[] esp_hmac_digest+0x63/0xa0 [esp4]
[] crypto_hmac_update+0x0/0x20
[] cbc_encrypt+0x44/0x50
[] esp_output+0x350/0x420 [esp4]
[] xfrm4_output+0x70/0x170
[] ip_forward_finish+0x0/0x40
[] ip_forward+0x16f/0x2c0
[] ip_forward_finish+0x0/0x40
[] ip_rcv+0x365/0x4d0
[] ip_rcv_finish+0x0/0x280
[] packet_rcv_spkt+0x186/0x260
[] tulip_poll+0x0/0x680 [tulip]
[] netif_receive_skb+0x1a9/0x260
[] tulip_poll+0x465/0x680 [tulip]
[] rhine_interrupt+0x42/0x240 [via_rhine]
[] net_rx_action+0xac/0x1b0
[] __do_softirq+0x79/0x90
[] do_softirq+0x27/0x30
[] irq_exit+0x35/0x40
[] do_IRQ+0x1e/0x30
[] common_interrupt+0x1a/0x20
[] default_idle+0x0/0x30
[] default_idle+0x23/0x30
[] cpu_idle+0x50/0x60
[] start_kernel+0x177/0x1c0
[] unknown_bootoption+0x0/0x1c0
Code: 83 e1 03 74 02 f3 a4 81 c4 48 01 00 00 5b 5e 5f 5d c3 8d 76 00 8b 44
24 04 bb 40 00 00 00 29 f3 89 d9 8d 7c 06 1c 89 ee c1 e9 02 a5 89 d9 83
e1 03 74 02 f3 a4 89 c6 8d 7c 24 08 89 c2 83 c6
<0>Kernel panic - not syncing: Fatal exception in interrupt
#
Hope that helps! If you need more info just ask!
-
Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] disable_local_APIC() is only available when CONFIG_X86_LOCAL_APIC is defined
On 9/5/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > > `disable_local_APIC' is only available when CONFIG_X86_LOCAL_APIC is defined : > > arch/i386/kernel/crash.c: In function `crash_nmi_callback': > arch/i386/kernel/crash.c:153: warning: implicit declaration of function > `disable_local_APIC' > arch/i386/kernel/crash.c: In function `nmi_shootdown_cpus': > arch/i386/kernel/crash.c:195: warning: implicit declaration of function > `disable_local_APIC' > > There may be a better fix, but the below seems to do the trick. > [snip] I guess the better fix is to just provide a dummy function in the case of CONFIG_X86_LOCAL_APIC not being defined. If so, just let me know and I'll cook up a patch to do that, instead of the ugly ifdef's. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 30/54] usb: white space cleanup
From: Patrick Boettcher <[EMAIL PROTECTED]>
white space cleanup
Signed-off-by: Patrick Boettcher <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/dvb-usb/vp7045.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-usb/vp7045.c 2005-09-04
22:28:21.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-usb/vp7045.c2005-09-04
22:28:23.0 +0200
@@ -164,7 +164,6 @@ static int vp7045_read_eeprom(struct dvb
return 0;
}
-
static int vp7045_read_mac_addr(struct dvb_usb_device *d,u8 mac[6])
{
return vp7045_read_eeprom(d,mac, 6, MAC_0_ADDR);
@@ -256,9 +255,9 @@ static struct dvb_usb_properties vp7045_
static struct usb_driver vp7045_usb_driver = {
.owner = THIS_MODULE,
.name = "dvb_usb_vp7045",
- .probe = vp7045_usb_probe,
+ .probe = vp7045_usb_probe,
.disconnect = dvb_usb_device_exit,
- .id_table = vp7045_usb_table,
+ .id_table = vp7045_usb_table,
};
/* module stuff */
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 37/54] dst: fix symbol rate setting
From: Manu Abraham <[EMAIL PROTECTED]>
Make the Symbolrate setting card specific.
Signed-off-by: Manu Abraham <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/bt8xx/dst.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/bt8xx/dst.c2005-09-04
22:28:26.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/bt8xx/dst.c 2005-09-04
22:28:32.0 +0200
@@ -324,12 +324,12 @@ static int dst_set_polarization(struct d
{
switch (state->voltage) {
case SEC_VOLTAGE_13:// vertical
- printk("%s: Polarization=[Vertical]\n", __FUNCTION__);
+ dprintk("%s: Polarization=[Vertical]\n", __FUNCTION__);
state->tx_tuna[8] &= ~0x40; //1
break;
case SEC_VOLTAGE_18:// horizontal
- printk("%s: Polarization=[Horizontal]\n", __FUNCTION__);
+ dprintk("%s: Polarization=[Horizontal]\n",
__FUNCTION__);
state->tx_tuna[8] |= 0x40; // 0
break;
@@ -344,7 +344,7 @@ static int dst_set_polarization(struct d
static int dst_set_freq(struct dst_state *state, u32 freq)
{
state->frequency = freq;
- if (debug > 4)
+ if (verbose > 4)
dprintk("%s: set Frequency %u\n", __FUNCTION__, freq);
if (state->dst_type == DST_TYPE_IS_SAT) {
@@ -451,7 +451,6 @@ static fe_code_rate_t dst_get_fec(struct
static int dst_set_symbolrate(struct dst_state* state, u32 srate)
{
- u8 *val;
u32 symcalc;
u64 sval;
@@ -463,7 +462,6 @@ static int dst_set_symbolrate(struct dst
if (debug > 4)
dprintk("%s: set symrate %u\n", __FUNCTION__, srate);
srate /= 1000;
- val = &state->tx_tuna[0];
if (state->type_flags & DST_TYPE_HAS_SYMDIV) {
sval = srate;
@@ -474,17 +472,19 @@ static int dst_set_symbolrate(struct dst
if (debug > 4)
dprintk("%s: set symcalc %u\n", __FUNCTION__, symcalc);
- val[5] = (u8) (symcalc >> 12);
- val[6] = (u8) (symcalc >> 4);
- val[7] = (u8) (symcalc << 4);
+ state->tx_tuna[5] = (u8) (symcalc >> 12);
+ state->tx_tuna[6] = (u8) (symcalc >> 4);
+ state->tx_tuna[7] = (u8) (symcalc << 4);
} else {
- val[5] = (u8) (srate >> 16) & 0x7f;
- val[6] = (u8) (srate >> 8);
- val[7] = (u8) srate;
- }
- val[8] &= ~0x20;
- if (srate > 8000)
- val[8] |= 0x20;
+ state->tx_tuna[5] = (u8) (srate >> 16) & 0x7f;
+ state->tx_tuna[6] = (u8) (srate >> 8);
+ state->tx_tuna[7] = (u8) srate;
+ }
+ state->tx_tuna[8] &= ~0x20;
+ if (state->type_flags & DST_TYPE_HAS_OBS_REGS) {
+ if (srate > 8000)
+ state->tx_tuna[8] |= 0x20;
+ }
return 0;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 16/54] frontend: tda1004x: fix SNR reading
From: Andrew de Quincey <[EMAIL PROTECTED]>
Fix SNR reading
Signed-off-by: Andrew de Quincey <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/frontends/tda1004x.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/frontends/tda1004x.c
2005-09-04 22:24:24.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/frontends/tda1004x.c2005-09-04
22:28:07.0 +0200
@@ -1046,8 +1046,7 @@ static int tda1004x_read_snr(struct dvb_
tmp = tda1004x_read_byte(state, TDA1004X_SNR);
if (tmp < 0)
return -EIO;
- if (tmp)
- tmp = 255 - tmp;
+ tmp = 255 - tmp;
*snr = ((tmp << 8) | tmp);
dprintk("%s: snr=0x%x\n", __FUNCTION__, *snr);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 36/54] Nebula DigiTV nxt6000 fix
From: Stuart Auchterlonie <[EMAIL PROTECTED]>
Fix bug in Nebula DigiTV frontend detection for nxt6000.
Signed-off-by: Stuart Auchterlonie <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/bt8xx/dvb-bt8xx.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/bt8xx/dvb-bt8xx.c 2005-09-04
22:28:29.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/bt8xx/dvb-bt8xx.c 2005-09-04
22:28:30.0 +0200
@@ -574,8 +574,10 @@ static void frontend_init(struct dvb_bt8
/* Old Nebula (marked (c)2003 on high profile pci card) has
nxt6000 demod */
card->fe = nxt6000_attach(&vp3021_alps_tded4_config,
card->i2c_adapter);
- if (card->fe != NULL)
+ if (card->fe != NULL) {
dprintk ("dvb_bt8xx: an nxt6000 was detected on your
digitv card\n");
+ break;
+ }
/* New Nebula (marked (c)2005 on low profile pci card) has
mt352 demod */
digitv_alps_tded4_reset(card);
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 21/54] frontend: stv0297: QAM128 tuning improvement
From: Patrick Boettcher <[EMAIL PROTECTED]> while investigating the QAM_128-issue with the stv0297-driver for the Cablestar (which is not the same as the one in dvb-kernel CVS, yet), I fixed it, not by increasing the timeout, but by disabling the corner-detection for QAM_128 and higher. This patch has been tested on dvb-kernel cvs, and has been reported to work by multiple users. Some cards still need timeout increase on top of this patch. This will be addressed later. Signed-off-by: Patrick Boettcher <[EMAIL PROTECTED]> Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> drivers/media/dvb/frontends/stv0297.c |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) --- linux-2.6.13-git4.orig/drivers/media/dvb/frontends/stv0297.c 2005-09-04 22:24:24.0 +0200 +++ linux-2.6.13-git4/drivers/media/dvb/frontends/stv0297.c 2005-09-04 22:28:12.0 +0200 @@ -606,7 +606,13 @@ static int stv0297_set_frontend(struct d stv0297_set_inversion(state, inversion); /* kick off lock */ - stv0297_writereg_mask(state, 0x88, 0x08, 0x08); + /* Disable corner detection for higher QAMs */ + if (p->u.qam.modulation == QAM_128 || + p->u.qam.modulation == QAM_256) + stv0297_writereg_mask(state, 0x88, 0x08, 0x00); + else + stv0297_writereg_mask(state, 0x88, 0x08, 0x08); + stv0297_writereg_mask(state, 0x5a, 0x20, 0x00); stv0297_writereg_mask(state, 0x6a, 0x01, 0x01); stv0297_writereg_mask(state, 0x43, 0x40, 0x40); -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 50/54] av7110: conditionally disable workaround for broken firmware
From: Oliver Endriss <[EMAIL PROTECTED]> Disable COM_IF_LOCK workaround for firmware > 0x261f. Signed-off-by: Oliver Endriss <[EMAIL PROTECTED]> Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> drivers/media/dvb/ttpci/av7110_hw.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) --- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/av7110_hw.c 2005-09-04 22:30:58.0 +0200 +++ linux-2.6.13-git4/drivers/media/dvb/ttpci/av7110_hw.c 2005-09-04 22:30:59.0 +0200 @@ -366,7 +366,8 @@ static int __av7110_send_fw_cmd(struct a msleep(1); } - wdebi(av7110, DEBINOSWAP, COM_IF_LOCK, 0x, 2); + if (FW_VERSION(av7110->arm_app) <= 0x261f) + wdebi(av7110, DEBINOSWAP, COM_IF_LOCK, 0x, 2); #ifndef _NOHANDSHAKE start = jiffies; @@ -439,7 +440,8 @@ static int __av7110_send_fw_cmd(struct a wdebi(av7110, DEBINOSWAP, COMMAND, (u32) buf[0], 2); - wdebi(av7110, DEBINOSWAP, COM_IF_LOCK, 0x, 2); + if (FW_VERSION(av7110->arm_app) <= 0x261f) + wdebi(av7110, DEBINOSWAP, COM_IF_LOCK, 0x, 2); #ifdef COM_DEBUG start = jiffies; -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 07/54] core: dvb_demux: remove unsused descramble callbacks
From: Andreas Oberritter <[EMAIL PROTECTED]>
Removed unused descramble_mac_address and descramble_section_payload callbacks.
Signed-off-by: Andreas Oberritter <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/dvb-core/demux.h | 11 ---
drivers/media/dvb/dvb-core/dvb_demux.c |3 ---
2 files changed, 14 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-core/demux.h 2005-09-04
22:27:55.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-core/demux.h2005-09-04
22:27:56.0 +0200
@@ -260,17 +260,6 @@ struct dmx_demux {
dmx_section_cb callback);
int (*release_section_feed) (struct dmx_demux* demux,
struct dmx_section_feed* feed);
-int (*descramble_mac_address) (struct dmx_demux* demux,
- u8* buffer1,
- size_t buffer1_length,
- u8* buffer2,
- size_t buffer2_length,
- u16 pid);
-int (*descramble_section_payload) (struct dmx_demux* demux,
- u8* buffer1,
- size_t buffer1_length,
- u8* buffer2, size_t buffer2_length,
- u16 pid);
int (*add_frontend) (struct dmx_demux* demux,
struct dmx_frontend* frontend);
int (*remove_frontend) (struct dmx_demux* demux,
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-core/dvb_demux.c
2005-09-04 22:27:55.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-core/dvb_demux.c2005-09-04
22:27:56.0 +0200
@@ -1232,9 +1232,6 @@ int dvb_dmx_init(struct dvb_demux *dvbde
dmx->allocate_section_feed = dvbdmx_allocate_section_feed;
dmx->release_section_feed = dvbdmx_release_section_feed;
- dmx->descramble_mac_address = NULL;
- dmx->descramble_section_payload = NULL;
-
dmx->add_frontend = dvbdmx_add_frontend;
dmx->remove_frontend = dvbdmx_remove_frontend;
dmx->get_frontends = dvbdmx_get_frontends;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 44/54] cinergyT2: remote control fixes
IR RC fixes:
- EVIOCSKEYCODE is not supported by this driver, fix potential crash
when it is used by not setting rc_input_dev->keycodesize
- fix key repeat handling (hopefully)
- reduce default poll internal to 50msec (necessary for key repeat handling)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/cinergyT2/Kconfig |2
drivers/media/dvb/cinergyT2/cinergyT2.c | 93 +++-
2 files changed, 57 insertions(+), 38 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/cinergyT2/Kconfig 2005-09-04
22:03:40.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/cinergyT2/Kconfig 2005-09-04
22:30:53.0 +0200
@@ -77,7 +77,7 @@ config DVB_CINERGYT2_ENABLE_RC_INPUT_DEV
config DVB_CINERGYT2_RC_QUERY_INTERVAL
int "Infrared Remote Controller update interval [milliseconds]"
depends on DVB_CINERGYT2_TUNING && DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE
-default "100"
+default "50"
help
If you have a very fast-repeating remote control you can try lower
values, for normal consumer receivers the default value should be
--- linux-2.6.13-git4.orig/drivers/media/dvb/cinergyT2/cinergyT2.c
2005-09-04 22:27:49.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/cinergyT2/cinergyT2.c 2005-09-04
22:30:53.0 +0200
@@ -35,7 +35,6 @@
#include "dvb_demux.h"
#include "dvb_net.h"
-
#ifdef CONFIG_DVB_CINERGYT2_TUNING
#define STREAM_URB_COUNT (CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT)
#define STREAM_BUF_SIZE (CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE)
@@ -48,7 +47,7 @@
#define STREAM_URB_COUNT (32)
#define STREAM_BUF_SIZE (512) /* bytes */
#define ENABLE_RC (1)
- #define RC_QUERY_INTERVAL (100) /* milliseconds */
+ #define RC_QUERY_INTERVAL (50) /* milliseconds */
#define QUERY_INTERVAL (333)/* milliseconds */
#endif
@@ -141,6 +140,8 @@ struct cinergyt2 {
struct input_dev rc_input_dev;
struct work_struct rc_query_work;
int rc_input_event;
+ u32 rc_last_code;
+ unsigned long last_event_jiffies;
#endif
};
@@ -155,7 +156,7 @@ struct cinergyt2_rc_event {
uint32_t value;
} __attribute__((packed));
-static const uint32_t rc_keys [] = {
+static const uint32_t rc_keys[] = {
CINERGYT2_RC_EVENT_TYPE_NEC,0xfe01eb04, KEY_POWER,
CINERGYT2_RC_EVENT_TYPE_NEC,0xfd02eb04, KEY_1,
CINERGYT2_RC_EVENT_TYPE_NEC,0xfc03eb04, KEY_2,
@@ -684,52 +685,68 @@ static struct dvb_device cinergyt2_fe_te
#ifdef ENABLE_RC
static void cinergyt2_query_rc (void *data)
{
- struct cinergyt2 *cinergyt2 = (struct cinergyt2 *) data;
- char buf [1] = { CINERGYT2_EP1_GET_RC_EVENTS };
+ struct cinergyt2 *cinergyt2 = data;
+ char buf[1] = { CINERGYT2_EP1_GET_RC_EVENTS };
struct cinergyt2_rc_event rc_events[12];
- int n, len;
+ int n, len, i;
if (down_interruptible(&cinergyt2->sem))
return;
len = cinergyt2_command(cinergyt2, buf, sizeof(buf),
-(char *) rc_events, sizeof(rc_events));
-
- for (n=0; len>0 && n<(len/sizeof(rc_events[0])); n++) {
- int i;
+ (char *) rc_events, sizeof(rc_events));
+ if (len < 0)
+ goto out;
+ if (len == 0) {
+ if (time_after(jiffies, cinergyt2->last_event_jiffies +
+ msecs_to_jiffies(150))) {
+ /* stop key repeat */
+ if (cinergyt2->rc_input_event != KEY_MAX) {
+ dprintk(1, "rc_input_event=%d Up\n",
cinergyt2->rc_input_event);
+ input_report_key(&cinergyt2->rc_input_dev,
+cinergyt2->rc_input_event, 0);
+ cinergyt2->rc_input_event = KEY_MAX;
+ }
+ cinergyt2->rc_last_code = ~0;
+ }
+ goto out;
+ }
+ cinergyt2->last_event_jiffies = jiffies;
-/* dprintk(1,"rc_events[%d].value = %x,
type=%x\n",n,le32_to_cpu(rc_events[n].value),rc_events[n].type);*/
+ for (n = 0; n < (len / sizeof(rc_events[0])); n++) {
+ dprintk(1, "rc_events[%d].value = %x, type=%x\n",
+ n, le32_to_cpu(rc_events[n].value), rc_events[n].type);
if (rc_events[n].type == CINERGYT2_RC_EVENT_TYPE_NEC &&
- rc_events[n].value == ~0)
- {
- /**
-* keyrepeat bit. If we would handle this properly
-* we would need to emit down events as long the
-* keyrepeat goes, a up event if no further
-* repeat bits occur. Would need a timer to implement
-* and no othe
[DVB patch 18/54] frontend: cx24110: DiSEqC fix
Fix DiSEqC switching (one bug fix suggested by Peter Hettkamp, and one experimentally determined msleep(30) suggested by Adam Szalkowski). Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> drivers/media/dvb/frontends/cx24110.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- linux-2.6.13-git4.orig/drivers/media/dvb/frontends/cx24110.c 2005-09-04 22:27:47.0 +0200 +++ linux-2.6.13-git4/drivers/media/dvb/frontends/cx24110.c 2005-09-04 22:28:09.0 +0200 @@ -398,7 +398,7 @@ static int cx24110_diseqc_send_burst(str return -EINVAL; rv = cx24110_readreg(state, 0x77); - cx24110_writereg(state, 0x77, rv|0x04); + cx24110_writereg(state, 0x77, rv | 0x04); rv = cx24110_readreg(state, 0x76); cx24110_writereg(state, 0x76, ((rv & 0x90) | 0x40 | bit)); @@ -418,7 +418,8 @@ static int cx24110_send_diseqc_msg(struc cx24110_writereg(state, 0x79 + i, cmd->msg[i]); rv = cx24110_readreg(state, 0x77); - cx24110_writereg(state, 0x77, rv|0x04); + cx24110_writereg(state, 0x77, rv & ~0x04); + msleep(30); /* reportedly fixes switching problems */ rv = cx24110_readreg(state, 0x76); -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 54/54] ttusb-budget: use time_after_eq()
From: Marcelo Feitoza Parisi <[EMAIL PROTECTED]>
Use of the time_after_eq() macro, defined at linux/jiffies.h, which deal
with wrapping correctly and are nicer to read.
Signed-off-by: Marcelo Feitoza Parisi <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
2005-09-04 22:28:03.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
2005-09-04 22:31:06.0 +0200
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include "dvb_frontend.h"
@@ -570,7 +571,8 @@ static void ttusb_handle_sec_data(struct
const u8 * data, int len);
#endif
-static int numpkt = 0, lastj, numts, numstuff, numsec, numinvalid;
+static int numpkt = 0, numts, numstuff, numsec, numinvalid;
+static unsigned long lastj;
static void ttusb_process_muxpack(struct ttusb *ttusb, const u8 * muxpack,
int len)
@@ -779,7 +781,7 @@ static void ttusb_iso_irq(struct urb *ur
u8 *data;
int len;
numpkt++;
- if ((jiffies - lastj) >= HZ) {
+ if (time_after_eq(jiffies, lastj + HZ)) {
#if DEBUG > 2
printk
("frames/s: %d (ts: %d, stuff %d, sec: %d,
invalid: %d, all: %d)\n",
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 09/54] core: dvb_demux: use INIT_LIST_HEAD
From: Andreas Oberritter <[EMAIL PROTECTED]> Use INIT_LIST_HEAD for frontend_list. Signed-off-by: Andreas Oberritter <[EMAIL PROTECTED]> Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> drivers/media/dvb/dvb-core/dvb_demux.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-core/dvb_demux.c 2005-09-04 22:27:57.0 +0200 +++ linux-2.6.13-git4/drivers/media/dvb/dvb-core/dvb_demux.c2005-09-04 22:27:58.0 +0200 @@ -1188,9 +1188,9 @@ int dvb_dmx_init(struct dvb_demux *dvbde dvbdemux->feed[i].state = DMX_STATE_FREE; dvbdemux->feed[i].index = i; } - dvbdemux->frontend_list.next= - dvbdemux->frontend_list.prev= - &dvbdemux->frontend_list; + + INIT_LIST_HEAD(&dvbdemux->frontend_list); + for (i=0; ipesfilter[i] = NULL; dvbdemux->pids[i] = 0x; -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 33/54] bt8xx: endianness fix
Endianness fix for risc DMA start address setting. (reported by Stefan Haubenthal/Peter Hettkamp) Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> drivers/media/dvb/bt8xx/bt878.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.13-git4.orig/drivers/media/dvb/bt8xx/bt878.c 2005-09-04 22:27:47.0 +0200 +++ linux-2.6.13-git4/drivers/media/dvb/bt8xx/bt878.c 2005-09-04 22:28:27.0 +0200 @@ -219,7 +219,7 @@ void bt878_start(struct bt878 *bt, u32 c controlreg &= ~0x1f; controlreg |= 0x1b; - btwrite(cpu_to_le32(bt->risc_dma), BT878_ARISC_START); + btwrite(bt->risc_dma, BT878_ARISC_START); /* original int mask had : *62840 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 43/54] dst: Updated Documentation
From: Manu Abraham <[EMAIL PROTECTED]> Updated Documentation Signed-off-by: Manu Abraham <[EMAIL PROTECTED]> Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> Documentation/dvb/bt8xx.txt | 95 ++-- 1 file changed, 57 insertions(+), 38 deletions(-) --- linux-2.6.13-git4.orig/Documentation/dvb/bt8xx.txt 2005-09-04 22:30:50.0 +0200 +++ linux-2.6.13-git4/Documentation/dvb/bt8xx.txt 2005-09-04 22:30:51.0 +0200 @@ -1,55 +1,74 @@ -How to get the Nebula Electronics DigiTV, Pinnacle PCTV Sat, Twinhan DST + clones working -= +How to get the Nebula, PCTV and Twinhan DST cards working += -1) General information -== +This class of cards has a bt878a as the PCI interface, and +require the bttv driver. -This class of cards has a bt878a chip as the PCI interface. -The different card drivers require the bttv driver to provide the means -to access the i2c bus and the gpio pins of the bt8xx chipset. +Please pay close attention to the warning about the bttv module +options below for the DST card. -2) Compilation rules for Kernel >= 2.6.12 -= +1) General informations +=== -Enable the following options: +These drivers require the bttv driver to provide the means to access +the i2c bus and the gpio pins of the bt8xx chipset. +Because of this, you need to enable "Device drivers" => "Multimedia devices" - => "Video For Linux" => "BT848 Video For Linux" + => "Video For Linux" => "BT848 Video For Linux" + +Furthermore you need to enable "Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices" - => "DVB for Linux" "DVB Core Support" "BT8xx based PCI cards" + => "DVB for Linux" "DVB Core Support" "BT8xx based PCI cards" -3) Loading Modules, described by two approaches -=== +2) Loading Modules +== In general you need to load the bttv driver, which will handle the gpio and -i2c communication for us, plus the common dvb-bt8xx device driver, -which is called the backend. -The frontends for Nebula DigiTV (nxt6000), Pinnacle PCTV Sat (cx24110), -TwinHan DST + clones (dst and dst-ca) are loaded automatically by the backend. -For further details about TwinHan DST + clones see /Documentation/dvb/ci.txt. - -3a) The manual approach - -Loading modules: -modprobe bttv -modprobe dvb-bt8xx - -Unloading modules: -modprobe -r dvb-bt8xx -modprobe -r bttv +i2c communication for us, plus the common dvb-bt8xx device driver. +The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110) and +TwinHan (dst) are loaded automatically by the dvb-bt8xx device driver. + +3a) Nebula / Pinnacle PCTV +-- -3b) The automatic approach + $ modprobe bttv (normally bttv is being loaded automatically by kmod) + $ modprobe dvb-bt8xx (or just place dvb-bt8xx in /etc/modules for automatic loading) + + +3b) TwinHan and Clones -- -If not already done by installation, place a line either in -/etc/modules.conf or in /etc/modprobe.conf containing this text: -alias char-major-81bttv + $ modprobe bttv i2c_hw=1 card=0x71 + $ modprobe dvb-bt8xx + $ modprobe dst + +The value 0x71 will override the PCI type detection for dvb-bt8xx, +which is necessary for TwinHan cards. + +If you're having an older card (blue color circuit) and card=0x71 locks +your machine, try using 0x68, too. If that does not work, ask on the +mailing list. + +The DST module takes a couple of useful parameters. + +verbose takes values 0 to 4. These values control the verbosity level, +and can be used to debug also. + +verbose=0 means complete disabling of messages + 1 only error messages are displayed + 2 notifications are also displayed + 3 informational messages are also displayed + 4 debug setting + +dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card. +0x20 means it has a Conditional Access slot. + +The autodected values are determined bythe cards 'response +string' which you can see in your logs e.g. -Then place a line in /etc/modules containing this text: -dvb-bt8xx +dst_get_device_id: Recognise [DSTMCI] -Reboot your system and have fun! -- -Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham, Uwe Bugla +Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 13/54] frontend: stv0299: pass i2c bus to pll callback
From: Andreas Oberritter <[EMAIL PROTECTED]>
Pass a pointer to the i2c bus to the pll callbacks (stv0299 only).
It was not possible to tell which i2c bus should be used if an adapter has
multiple frontends on multiple i2c buses.
Signed-off-by: Andreas Oberritter <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/b2c2/flexcop-fe-tuner.c |5 ++---
drivers/media/dvb/frontends/stv0299.c |6 +++---
drivers/media/dvb/frontends/stv0299.h |4 ++--
drivers/media/dvb/ttpci/av7110.c | 10 --
drivers/media/dvb/ttpci/budget-av.c |4 ++--
drivers/media/dvb/ttpci/budget-ci.c |9 -
drivers/media/dvb/ttpci/budget-patch.c|5 ++---
drivers/media/dvb/ttpci/budget.c |5 ++---
drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |4 ++--
9 files changed, 23 insertions(+), 29 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/b2c2/flexcop-fe-tuner.c
2005-09-04 22:54:07.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/b2c2/flexcop-fe-tuner.c 2005-09-04
22:54:23.0 +0200
@@ -164,12 +164,11 @@ static int samsung_tbmu24112_set_symbol_
return 0;
}
-static int samsung_tbmu24112_pll_set(struct dvb_frontend* fe, struct
dvb_frontend_parameters* params)
+static int samsung_tbmu24112_pll_set(struct dvb_frontend* fe, struct
i2c_adapter *i2c, struct dvb_frontend_parameters* params)
{
u8 buf[4];
u32 div;
struct i2c_msg msg = { .addr = 0x61, .flags = 0, .buf = buf, .len =
sizeof(buf) };
- struct flexcop_device *fc = fe->dvb->priv;
div = params->frequency / 125;
@@ -180,7 +179,7 @@ static int samsung_tbmu24112_pll_set(str
if (params->frequency < 150) buf[3] |= 0x10;
- if (i2c_transfer(&fc->i2c_adap, &msg, 1) != 1)
+ if (i2c_transfer(i2c, &msg, 1) != 1)
return -EIO;
return 0;
}
--- linux-2.6.13-git4.orig/drivers/media/dvb/frontends/stv0299.c
2005-09-04 22:54:07.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/frontends/stv0299.c 2005-09-04
22:54:23.0 +0200
@@ -481,7 +481,7 @@ static int stv0299_init (struct dvb_fron
if (state->config->pll_init) {
stv0299_writeregI(state, 0x05, 0xb5); /* enable i2c repeater
on stv0299 */
- state->config->pll_init(fe);
+ state->config->pll_init(fe, state->i2c);
stv0299_writeregI(state, 0x05, 0x35); /* disable i2c
repeater on stv0299 */
}
@@ -603,7 +603,7 @@ static int stv0299_set_frontend(struct d
} else {
/* A "normal" tune is requested */
stv0299_writeregI(state, 0x05, 0xb5); /* enable i2c
repeater on stv0299 */
- state->config->pll_set(fe, p);
+ state->config->pll_set(fe, state->i2c, p);
stv0299_writeregI(state, 0x05, 0x35); /* disable i2c
repeater on stv0299 */
stv0299_writeregI(state, 0x32, 0x80);
@@ -615,7 +615,7 @@ static int stv0299_set_frontend(struct d
}
} else {
stv0299_writeregI(state, 0x05, 0xb5); /* enable i2c repeater
on stv0299 */
- state->config->pll_set(fe, p);
+ state->config->pll_set(fe, state->i2c, p);
stv0299_writeregI(state, 0x05, 0x35); /* disable i2c
repeater on stv0299 */
stv0299_set_FEC (state, p->u.qpsk.fec_inner);
--- linux-2.6.13-git4.orig/drivers/media/dvb/frontends/stv0299.h
2005-09-04 22:54:07.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/frontends/stv0299.h 2005-09-04
22:54:23.0 +0200
@@ -92,8 +92,8 @@ struct stv0299_config
int (*set_symbol_rate)(struct dvb_frontend* fe, u32 srate, u32 ratio);
/* PLL maintenance */
- int (*pll_init)(struct dvb_frontend* fe);
- int (*pll_set)(struct dvb_frontend* fe, struct dvb_frontend_parameters*
params);
+ int (*pll_init)(struct dvb_frontend *fe, struct i2c_adapter *i2c);
+ int (*pll_set)(struct dvb_frontend *fe, struct i2c_adapter *i2c, struct
dvb_frontend_parameters *params);
};
extern int stv0299_writereg (struct dvb_frontend* fe, u8 reg, u8 data);
--- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/av7110.c 2005-09-04
22:54:07.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/ttpci/av7110.c 2005-09-04
22:54:23.0 +0200
@@ -1668,9 +1668,8 @@ static int alps_bsru6_set_symbol_rate(st
return 0;
}
-static int alps_bsru6_pll_set(struct dvb_frontend* fe, struct
dvb_frontend_parameters* params)
+static int alps_bsru6_pll_set(struct dvb_frontend* fe, struct i2c_adapter
*i2c, struct dvb_frontend_parameters* params)
{
- struct av7110* av7110 = (struct av7110*) fe->dvb->priv;
int ret;
u8 data[4];
[DVB patch 04/54] core: glue code for DMX_GET_CAPS and DMX_SET_SOURCE
From: Andreas Oberritter <[EMAIL PROTECTED]>
Glue code for DMX_GET_CAPS and DMX_SET_SOURCE ioctls.
Signed-off-by: Andreas Oberritter <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/dvb-core/demux.h |5 +
drivers/media/dvb/dvb-core/dmxdev.c | 16
2 files changed, 21 insertions(+)
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-core/demux.h 2005-09-04
22:24:24.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-core/demux.h2005-09-04
22:27:52.0 +0200
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/*--*/
/* Common definitions */
@@ -282,6 +283,10 @@ struct dmx_demux {
int (*get_pes_pids) (struct dmx_demux* demux, u16 *pids);
+ int (*get_caps) (struct dmx_demux* demux, struct dmx_caps *caps);
+
+ int (*set_source) (struct dmx_demux* demux, const dmx_source_t *src);
+
int (*get_stc) (struct dmx_demux* demux, unsigned int num,
u64 *stc, unsigned int *base);
};
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-core/dmxdev.c 2005-09-04
22:24:24.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-core/dmxdev.c 2005-09-04
22:27:52.0 +0200
@@ -929,6 +929,22 @@ static int dvb_demux_do_ioctl(struct ino
dmxdev->demux->get_pes_pids(dmxdev->demux, (u16 *)parg);
break;
+ case DMX_GET_CAPS:
+ if (!dmxdev->demux->get_caps) {
+ ret = -EINVAL;
+ break;
+ }
+ ret = dmxdev->demux->get_caps(dmxdev->demux, parg);
+ break;
+
+ case DMX_SET_SOURCE:
+ if (!dmxdev->demux->set_source) {
+ ret = -EINVAL;
+ break;
+ }
+ ret = dmxdev->demux->set_source(dmxdev->demux, parg);
+ break;
+
case DMX_GET_STC:
if (!dmxdev->demux->get_stc) {
ret=-EINVAL;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [DVB patch 54/54] ttusb-budget: use time_after_eq()
On 9/4/05, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> From: Marcelo Feitoza Parisi <[EMAIL PROTECTED]>
>
> Use of the time_after_eq() macro, defined at linux/jiffies.h, which deal
> with wrapping correctly and are nicer to read.
>
> Signed-off-by: Marcelo Feitoza Parisi <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
> Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
>
> drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> --- linux-2.6.13-git4.orig/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
> 2005-09-04 22:28:03.0 +0200
> +++ linux-2.6.13-git4/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
> 2005-09-04 22:31:06.0 +0200
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "dvb_frontend.h"
> @@ -570,7 +571,8 @@ static void ttusb_handle_sec_data(struct
> const u8 * data, int len);
> #endif
>
> -static int numpkt = 0, lastj, numts, numstuff, numsec, numinvalid;
> +static int numpkt = 0, numts, numstuff, numsec, numinvalid;
> +static unsigned long lastj;
>
> static void ttusb_process_muxpack(struct ttusb *ttusb, const u8 * muxpack,
>int len)
> @@ -779,7 +781,7 @@ static void ttusb_iso_irq(struct urb *ur
> u8 *data;
> int len;
> numpkt++;
> - if ((jiffies - lastj) >= HZ) {
> + if (time_after_eq(jiffies, lastj + HZ)) {
I think you actually want:
static void ttusb_iso_irq()
{
unsigned long lastj;
...
lastj = jiffies + HZ;
if (time_after_eq(jiffies, lastj)) {
...
}
The current code doesn't assign jiffies to lastj at any point that I see.
Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 26/54] usb: dtt200u: copy frontend_ops before modifying
From: Ye Jianjun (Joey) <[EMAIL PROTECTED]>
Fix: copy frontend_ops before modifying
Signed-off-by: Ye Jianjun (Joey) <[EMAIL PROTECTED]>
Signed-off-by: Patrick Boettcher <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/dvb-usb/dtt200u-fe.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-usb/dtt200u-fe.c
2005-09-04 22:24:23.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-usb/dtt200u-fe.c2005-09-04
22:28:19.0 +0200
@@ -18,6 +18,7 @@ struct dtt200u_fe_state {
struct dvb_frontend_parameters fep;
struct dvb_frontend frontend;
+ struct dvb_frontend_ops ops;
};
static int dtt200u_fe_read_status(struct dvb_frontend* fe, fe_status_t *stat)
@@ -163,8 +164,9 @@ struct dvb_frontend* dtt200u_fe_attach(s
deb_info("attaching frontend dtt200u\n");
state->d = d;
+ memcpy(&state->ops,&dtt200u_fe_ops,sizeof(struct dvb_frontend_ops));
- state->frontend.ops = &dtt200u_fe_ops;
+ state->frontend.ops = &state->ops;
state->frontend.demodulator_priv = state;
goto success;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 49/54] av7110: disable superflous firmware handshake
Disable superflous firmware handshake. Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> drivers/media/dvb/ttpci/av7110_hw.c |2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/av7110_hw.c 2005-09-04 22:03:40.0 +0200 +++ linux-2.6.13-git4/drivers/media/dvb/ttpci/av7110_hw.c 2005-09-04 22:30:58.0 +0200 @@ -41,6 +41,8 @@ #include "av7110.h" #include "av7110_hw.h" +#define _NOHANDSHAKE + / * DEBI functions / -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 05/54] core: dvb_demux: fix continuity counter error handling
From: Andreas Oberritter <[EMAIL PROTECTED]>
Don't return immediately from dvb_dmx_swfilter_section_packet() if CC is not ok.
Otherwise a new feed drops all packets until the first packet with CC=0 arrives.
Signed-off-by: Andreas Oberritter <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/dvb-core/dvb_demux.c |1 -
1 file changed, 1 deletion(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-core/dvb_demux.c
2005-09-04 22:24:24.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-core/dvb_demux.c2005-09-04
22:27:54.0 +0200
@@ -336,7 +336,6 @@ static int dvb_dmx_swfilter_section_pack
*/
feed->pusi_seen = 0;
dvb_dmx_swfilter_section_new(feed);
- return 0;
}
if (buf[1] & 0x40) {
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 32/54] remove noisy debug print
comment out noisy dprintk in dst_get_signal()
(why are errors only visible with debug on?
this needs to be cleaned up so we can disable debug by default)
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/bt8xx/dst.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/bt8xx/dst.c2005-09-04
22:24:23.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/bt8xx/dst.c 2005-09-04
22:28:26.0 +0200
@@ -928,7 +928,7 @@ static int dst_get_signal(struct dst_sta
{
int retval;
u8 get_signal[] = { 0x00, 0x05, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfb };
- dprintk("%s: Getting Signal strength and other parameters\n",
__FUNCTION__);
+ //dprintk("%s: Getting Signal strength and other parameters\n",
__FUNCTION__);
if ((state->diseq_flags & ATTEMPT_TUNE) == 0) {
state->decode_lock = state->decode_strength = state->decode_snr
= 0;
return 0;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 42/54] dst: ci doc update
From: Manu Abraham <[EMAIL PROTECTED]> Updated documentation Signed-off-by: Manu Abraham <[EMAIL PROTECTED]> Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]> Documentation/dvb/ci.txt |9 + 1 file changed, 1 insertion(+), 8 deletions(-) --- linux-2.6.13-git4.orig/Documentation/dvb/ci.txt 2005-09-04 22:24:23.0 +0200 +++ linux-2.6.13-git4/Documentation/dvb/ci.txt 2005-09-04 22:28:38.0 +0200 @@ -23,7 +23,6 @@ This application requires the following eg: $ szap -c channels.conf -r "TMC" -x (b) a channels.conf containing a valid PMT PID - eg: TMC:11996:h:0:27500:278:512:650:321 here 278 is a valid PMT PID. the rest of the values are the @@ -31,13 +30,7 @@ This application requires the following (c) after running a szap, you have to run ca_zap, for the descrambler to function, - - eg: $ ca_zap patched_channels.conf "TMC" - - The patched means a patch to apply to scan, such that scan can - generate a channels.conf_with pmt, which has this PMT PID info - (NOTE: szap cannot use this channels.conf with the PMT_PID) - + eg: $ ca_zap channels.conf "TMC" (d) Hopeflly Enjoy your favourite subscribed channel as you do with a FTA card. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 52/54] ttpci: add PCI ids for old Siemens/TT DVB-C card
From: Karl Herz <[EMAIL PROTECTED]>
Add PCI-ids of Siemens-DVB-C card with Technotrend manufacturer id.
Signed-off-by: Karl Herz <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/ttpci/av7110.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/av7110.c 2005-09-04
22:31:00.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/ttpci/av7110.c 2005-09-04
22:31:02.0 +0200
@@ -168,7 +168,9 @@ static void init_av7110_av(struct av7110
if (ret < 0)
printk("dvb-ttpci:cannot switch on SCART(AD):%d\n",ret);
if (rgb_on &&
- (av7110->dev->pci->subsystem_vendor == 0x110a) &&
(av7110->dev->pci->subsystem_device == 0x)) {
+ ((av7110->dev->pci->subsystem_vendor == 0x110a) ||
+(av7110->dev->pci->subsystem_vendor == 0x13c2)) &&
+(av7110->dev->pci->subsystem_device == 0x)) {
saa7146_setgpio(dev, 1, SAA7146_GPIO_OUTHI); // RGB on,
SCART pin 16
//saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTLO); //
SCARTpin 8
}
@@ -2868,7 +2870,7 @@ static struct saa7146_pci_extension_data
.ext_priv = x_name, \
.ext = &av7110_extension }
-MAKE_AV7110_INFO(tts_1_X,"Technotrend/Hauppauge WinTV DVB-S rev1.X");
+MAKE_AV7110_INFO(tts_1_X_fsc,"Technotrend/Hauppauge WinTV DVB-S rev1.X or
Fujitsu Siemens DVB-C");
MAKE_AV7110_INFO(ttt_1_X,"Technotrend/Hauppauge WinTV DVB-T rev1.X");
MAKE_AV7110_INFO(ttc_1_X,"Technotrend/Hauppauge WinTV Nexus-CA rev1.X");
MAKE_AV7110_INFO(ttc_2_X,"Technotrend/Hauppauge WinTV DVB-C rev2.X");
@@ -2880,16 +2882,16 @@ MAKE_AV7110_INFO(fsc,"Fujitsu Si
MAKE_AV7110_INFO(fss,"Fujitsu Siemens DVB-S rev1.6");
static struct pci_device_id pci_tbl[] = {
- MAKE_EXTENSION_PCI(fsc, 0x110a, 0x),
- MAKE_EXTENSION_PCI(tts_1_X, 0x13c2, 0x),
- MAKE_EXTENSION_PCI(ttt_1_X, 0x13c2, 0x0001),
- MAKE_EXTENSION_PCI(ttc_2_X, 0x13c2, 0x0002),
- MAKE_EXTENSION_PCI(tts_2_X, 0x13c2, 0x0003),
- MAKE_EXTENSION_PCI(fss, 0x13c2, 0x0006),
- MAKE_EXTENSION_PCI(ttt, 0x13c2, 0x0008),
- MAKE_EXTENSION_PCI(ttc_1_X, 0x13c2, 0x000a),
- MAKE_EXTENSION_PCI(tts_2_3, 0x13c2, 0x000e),
- MAKE_EXTENSION_PCI(tts_1_3se, 0x13c2, 0x1002),
+ MAKE_EXTENSION_PCI(fsc, 0x110a, 0x),
+ MAKE_EXTENSION_PCI(tts_1_X_fsc, 0x13c2, 0x),
+ MAKE_EXTENSION_PCI(ttt_1_X, 0x13c2, 0x0001),
+ MAKE_EXTENSION_PCI(ttc_2_X, 0x13c2, 0x0002),
+ MAKE_EXTENSION_PCI(tts_2_X, 0x13c2, 0x0003),
+ MAKE_EXTENSION_PCI(fss, 0x13c2, 0x0006),
+ MAKE_EXTENSION_PCI(ttt, 0x13c2, 0x0008),
+ MAKE_EXTENSION_PCI(ttc_1_X, 0x13c2, 0x000a),
+ MAKE_EXTENSION_PCI(tts_2_3, 0x13c2, 0x000e),
+ MAKE_EXTENSION_PCI(tts_1_3se, 0x13c2, 0x1002),
/* MAKE_EXTENSION_PCI(???, 0x13c2, 0x0004), UNDEFINED CARD */ // Galaxis
DVB PC-Sat-Carte
/* MAKE_EXTENSION_PCI(???, 0x13c2, 0x0005), UNDEFINED CARD */ // Technisat
SkyStar1
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 12/54] frontend: mt352: fix signal strength reading
From: Barry Scott <[EMAIL PROTECTED]>
Fix two problems with the signal strength value in the mt352.c frontend:
1. the 4 most significant bits are zeroed - shift and mask wrong way round
2. need to align the 12 bits from the registers at the top of the 16 bit
returned value - otherwise the range is not 0 to 0x its 0xf000 to 0x
Signed-off-by: Barry Scott <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/frontends/mt352.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/frontends/mt352.c 2005-09-04
22:24:24.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/frontends/mt352.c 2005-09-04
22:28:02.0 +0200
@@ -462,9 +462,11 @@ static int mt352_read_signal_strength(st
{
struct mt352_state* state = fe->demodulator_priv;
- u16 signal = ((mt352_read_register(state, AGC_GAIN_1) << 8) & 0x0f) |
- (mt352_read_register(state, AGC_GAIN_0));
+ /* align the 12 bit AGC gain with the most significant bits */
+ u16 signal = ((mt352_read_register(state, AGC_GAIN_1) & 0x0f) << 12) |
+ (mt352_read_register(state, AGC_GAIN_0) << 4);
+ /* inverse of gain is signal strength */
*strength = ~signal;
return 0;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 08/54] core: dvb_demux: remove more unused cruft
From: Andreas Oberritter <[EMAIL PROTECTED]>
Removed more unused variables and constants.
Signed-off-by: Andreas Oberritter <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/dvb-core/demux.h |7 ---
drivers/media/dvb/dvb-core/dmxdev.c|4 ++--
drivers/media/dvb/dvb-core/dvb_demux.c | 18 ++
drivers/media/dvb/dvb-core/dvb_demux.h |7 +--
drivers/media/dvb/dvb-core/dvb_net.c |4 +---
5 files changed, 6 insertions(+), 34 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-core/demux.h 2005-09-04
22:27:56.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-core/demux.h2005-09-04
22:27:57.0 +0200
@@ -125,9 +125,7 @@ struct dmx_ts_feed {
u16 pid,
int type,
enum dmx_ts_pes pes_type,
- size_t callback_length,
size_t circular_buffer_size,
- int descramble,
struct timespec timeout);
int (*start_filtering) (struct dmx_ts_feed* feed);
int (*stop_filtering) (struct dmx_ts_feed* feed);
@@ -160,7 +158,6 @@ struct dmx_section_feed {
int (*set) (struct dmx_section_feed* feed,
u16 pid,
size_t circular_buffer_size,
- int descramble,
int check_crc);
int (*allocate_filter) (struct dmx_section_feed* feed,
struct dmx_section_filter** filter);
@@ -208,7 +205,6 @@ struct dmx_frontend {
struct list_head connectivity_list; /* List of front-ends that can
be connected to a particular
demux */
-void* priv; /* Pointer to private data of the API client */
enum dmx_frontend_source source;
};
@@ -226,8 +222,6 @@ struct dmx_frontend {
#define DMX_MEMORY_BASED_FILTERING 8/* write() available */
#define DMX_CRC_CHECKING16
#define DMX_TS_DESCRAMBLING 32
-#define DMX_SECTION_PAYLOAD_DESCRAMBLING64
-#define DMX_MAC_ADDRESS_DESCRAMBLING128
/*
* Demux resource type identifier.
@@ -246,7 +240,6 @@ struct dmx_demux {
u32 capabilities;/* Bitfield of capability flags */
struct dmx_frontend* frontend;/* Front-end connected to the demux
*/
void* priv; /* Pointer to private data of the API
client */
-int users; /* Number of users */
int (*open) (struct dmx_demux* demux);
int (*close) (struct dmx_demux* demux);
int (*write) (struct dmx_demux* demux, const char* buf, size_t count);
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-core/dmxdev.c 2005-09-04
22:27:52.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-core/dmxdev.c 2005-09-04
22:27:57.0 +0200
@@ -571,7 +571,7 @@ static int dvb_dmxdev_filter_start(struc
return ret;
}
- ret=(*secfeed)->set(*secfeed, para->pid, 32768, 0,
+ ret=(*secfeed)->set(*secfeed, para->pid, 32768,
(para->flags & DMX_CHECK_CRC) ? 1 :
0);
if (ret<0) {
@@ -654,7 +654,7 @@ static int dvb_dmxdev_filter_start(struc
(*tsfeed)->priv = (void *) filter;
ret = (*tsfeed)->set(*tsfeed, para->pid, ts_type, ts_pes,
-188, 32768, 0, timeout);
+32768, timeout);
if (ret < 0) {
dmxdev->demux->release_ts_feed(dmxdev->demux, *tsfeed);
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-core/dvb_demux.c
2005-09-04 22:27:56.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-core/dvb_demux.c2005-09-04
22:27:57.0 +0200
@@ -577,8 +577,7 @@ out:
}
static int dmx_ts_feed_set (struct dmx_ts_feed* ts_feed, u16 pid, int ts_type,
-enum dmx_ts_pes pes_type, size_t callback_length,
-size_t circular_buffer_size, int descramble,
+enum dmx_ts_pes pes_type, size_t circular_buffer_size,
struct timespec timeout)
{
struct dvb_demux_feed *feed = (struct dvb_demux_feed *) ts_feed;
@@ -610,17 +609,10 @@ static int dmx_ts_feed_set (struct dmx_t
feed->pid = pid;
feed->buffer_size = circular_buffer_size;
- feed->descramble = descramble;
feed->timeout = timeout;
- feed->cb_length = callback_length;
feed->ts_type = ts_type;
feed->pes_type = pes_type;
- if (feed->descramble) {
- up(&demux->mutex);
- return -ENOSYS;
- }
-
if (feed->buffer_size) {
#ifdef NOBUFS
fee
[DVB patch 53/54] saa7146: i2c vs. sysfs fix
From: Philipp Matthias Hahn <[EMAIL PROTECTED]>
Integrate saa7146_i2c adapter into device model:
Moves entries from /sys/device/platform to /sys/device/pci*.
Signed-off-by: Philipp Hahn <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/common/saa7146_i2c.c |1 +
1 file changed, 1 insertion(+)
--- linux-2.6.13-git4.orig/drivers/media/common/saa7146_i2c.c 2005-09-04
22:27:49.0 +0200
+++ linux-2.6.13-git4/drivers/media/common/saa7146_i2c.c2005-09-04
22:31:04.0 +0200
@@ -405,6 +405,7 @@ int saa7146_i2c_adapter_prepare(struct s
if( NULL != i2c_adapter ) {
BUG_ON(!i2c_adapter->class);
i2c_set_adapdata(i2c_adapter,dev);
+ i2c_adapter->dev.parent= &dev->pci->dev;
i2c_adapter->algo = &saa7146_algo;
i2c_adapter->algo_data = NULL;
i2c_adapter->id= I2C_ALGO_SAA7146;
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 45/54] av7110: Siemens DVB-C analog video input support
From: thomas schorpp <[EMAIL PROTECTED]>
Add support for analog video inputs (CVBS and Y/C) of the
analog module for the Siemens DVB-C card.
Signed-off-by: thomas schorpp <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/ttpci/av7110_v4l.c | 74 +--
1 file changed, 54 insertions(+), 20 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/av7110_v4l.c 2005-09-04
22:03:40.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/ttpci/av7110_v4l.c 2005-09-04
22:30:54.0 +0200
@@ -70,7 +70,7 @@ static int msp_readreg(struct av7110 *av
return 0;
}
-static struct v4l2_input inputs[2] = {
+static struct v4l2_input inputs[4] = {
{
.index = 0,
.name = "DVB",
@@ -87,6 +87,22 @@ static struct v4l2_input inputs[2] = {
.tuner = 0,
.std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
.status = 0,
+ }, {
+ .index = 2,
+ .name = "Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .audioset = 0,
+ .tuner = 0,
+ .std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
+ .status = 0,
+ }, {
+ .index = 3,
+ .name = "Y/C",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .audioset = 0,
+ .tuner = 0,
+ .std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
+ .status = 0,
}
};
@@ -212,24 +228,44 @@ static int av7110_dvb_c_switch(struct sa
}
if (0 != av7110->current_input) {
+ dprintk(1, "switching to analog TV:\n");
adswitch = 1;
source = SAA7146_HPS_SOURCE_PORT_B;
sync = SAA7146_HPS_SYNC_PORT_B;
memcpy(standard, analog_standard, sizeof(struct
saa7146_standard) * 2);
- dprintk(1, "switching to analog TV\n");
- msp_writereg(av7110, MSP_WR_DSP, 0x0008, 0x); //
loudspeaker source
- msp_writereg(av7110, MSP_WR_DSP, 0x0009, 0x); // headphone
source
- msp_writereg(av7110, MSP_WR_DSP, 0x000a, 0x); // SCART 1
source
- msp_writereg(av7110, MSP_WR_DSP, 0x000e, 0x3000); // FM matrix,
mono
- msp_writereg(av7110, MSP_WR_DSP, 0x, 0x4f00); //
loudspeaker + headphone
- msp_writereg(av7110, MSP_WR_DSP, 0x0007, 0x4f00); // SCART 1
volume
- if (av7110->analog_tuner_flags & ANALOG_TUNER_VES1820) {
- if (ves1820_writereg(dev, 0x09, 0x0f, 0x60))
- dprintk(1, "setting band in demodulator
failed.\n");
- } else if (av7110->analog_tuner_flags & ANALOG_TUNER_STV0297) {
- saa7146_setgpio(dev, 1, SAA7146_GPIO_OUTHI); // TDA9198
pin9(STD)
- saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTHI); // TDA9198
pin30(VIF)
+ switch (av7110->current_input) {
+ case 1:
+ dprintk(1, "switching SAA7113 to Analog Tuner
Input.\n");
+ msp_writereg(av7110, MSP_WR_DSP, 0x0008, 0x); //
loudspeaker source
+ msp_writereg(av7110, MSP_WR_DSP, 0x0009, 0x); //
headphone source
+ msp_writereg(av7110, MSP_WR_DSP, 0x000a, 0x); //
SCART 1 source
+ msp_writereg(av7110, MSP_WR_DSP, 0x000e, 0x3000); // FM
matrix, mono
+ msp_writereg(av7110, MSP_WR_DSP, 0x, 0x4f00); //
loudspeaker + headphone
+ msp_writereg(av7110, MSP_WR_DSP, 0x0007, 0x4f00); //
SCART 1 volume
+
+ if (av7110->analog_tuner_flags & ANALOG_TUNER_VES1820) {
+ if (ves1820_writereg(dev, 0x09, 0x0f, 0x60))
+ dprintk(1, "setting band in demodulator
failed.\n");
+ } else if (av7110->analog_tuner_flags &
ANALOG_TUNER_STV0297) {
+ saa7146_setgpio(dev, 1, SAA7146_GPIO_OUTHI); //
TDA9198 pin9(STD)
+ saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTHI); //
TDA9198 pin30(VIF)
+ }
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd0) != 1)
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ break;
+ case 2:
+ dprintk(1, "switching SAA7113 to Video AV CVBS
Input.\n");
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd2) != 1)
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ break;
+
[DVB patch 20/54] frontend: cx24110: clean up timeout handling.
Clean up timeout handling.
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/frontends/cx24110.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/frontends/cx24110.c
2005-09-04 22:28:10.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/frontends/cx24110.c 2005-09-04
22:28:11.0 +0200
@@ -387,8 +387,9 @@ static int cx24110_set_voltage (struct d
static int cx24110_diseqc_send_burst(struct dvb_frontend* fe,
fe_sec_mini_cmd_t burst)
{
- int rv, bit, i;
+ int rv, bit;
struct cx24110_state *state = fe->demodulator_priv;
+ unsigned long timeout;
if (burst == SEC_MINI_A)
bit = 0x00;
@@ -403,8 +404,9 @@ static int cx24110_diseqc_send_burst(str
rv = cx24110_readreg(state, 0x76);
cx24110_writereg(state, 0x76, ((rv & 0x90) | 0x40 | bit));
- for (i = 500; i-- > 0 && !(cx24110_readreg(state,0x76)&0x40) ; )
- ; /* wait for LNB ready */
+ timeout = jiffies + msecs_to_jiffies(100);
+ while (!time_after(jiffies, timeout) && !(cx24110_readreg(state, 0x76)
& 0x40))
+ ; /* wait for LNB ready */
return 0;
}
@@ -414,6 +416,7 @@ static int cx24110_send_diseqc_msg(struc
{
int i, rv;
struct cx24110_state *state = fe->demodulator_priv;
+ unsigned long timeout;
for (i = 0; i < cmd->msg_len; i++)
cx24110_writereg(state, 0x79 + i, cmd->msg[i]);
@@ -427,8 +430,9 @@ static int cx24110_send_diseqc_msg(struc
rv = cx24110_readreg(state, 0x76);
cx24110_writereg(state, 0x76, ((rv & 0x90) | 0x40) | ((cmd->msg_len-3)
& 3));
- for (i=100; i-- > 0 && !(cx24110_readreg(state,0x76)&0x40);)
- msleep(1); /* wait for LNB ready */
+ timeout = jiffies + msecs_to_jiffies(100);
+ while (!time_after(jiffies, timeout) && !(cx24110_readreg(state, 0x76)
& 0x40))
+ ; /* wait for LNB ready */
return 0;
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 51/54] ttpci: av7110: RC5+ remote control support
From: Oliver Endriss <[EMAIL PROTECTED]>
Improved remote control support for av7110-based cards:
o extended rc5 protocol, firmware >= 0x2620 required
o key-up timer slightly adjusted
o completely moved remote control code to av7110_ir.c
o support for multiple ir receivers
o for now, all av7110 cards share the same ir configuration and event device
Signed-off-by: Oliver Endriss <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/ttpci/av7110.c| 70 +-
drivers/media/dvb/ttpci/av7110.h| 11 +-
drivers/media/dvb/ttpci/av7110_ir.c | 140
3 files changed, 110 insertions(+), 111 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/av7110.c 2005-09-04
22:30:55.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/ttpci/av7110.c 2005-09-04
22:31:00.0 +0200
@@ -177,9 +177,6 @@ static void init_av7110_av(struct av7110
ret = av7110_set_volume(av7110, av7110->mixer.volume_left,
av7110->mixer.volume_right);
if (ret < 0)
printk("dvb-ttpci:cannot set volume :%d\n",ret);
- ret = av7110_setup_irc_config(av7110, 0);
- if (ret < 0)
- printk("dvb-ttpci:cannot setup irc config :%d\n",ret);
}
static void recover_arm(struct av7110 *av7110)
@@ -265,60 +262,6 @@ static int arm_thread(void *data)
}
-/**
- * Hack! we save the last av7110 ptr. This should be ok, since
- * you rarely will use more then one IR control.
- *
- * If we want to support multiple controls we would have to do much more...
- */
-int av7110_setup_irc_config(struct av7110 *av7110, u32 ir_config)
-{
- int ret = 0;
- static struct av7110 *last;
-
- dprintk(4, "%p\n", av7110);
-
- if (!av7110)
- av7110 = last;
- else
- last = av7110;
-
- if (av7110) {
- ret = av7110_fw_cmd(av7110, COMTYPE_PIDFILTER, SetIR, 1,
ir_config);
- av7110->ir_config = ir_config;
- }
- return ret;
-}
-
-static void (*irc_handler)(u32);
-
-void av7110_register_irc_handler(void (*func)(u32))
-{
- dprintk(4, "registering %p\n", func);
- irc_handler = func;
-}
-
-void av7110_unregister_irc_handler(void (*func)(u32))
-{
- dprintk(4, "unregistering %p\n", func);
- irc_handler = NULL;
-}
-
-static void run_handlers(unsigned long ircom)
-{
- if (irc_handler != NULL)
- (*irc_handler)((u32) ircom);
-}
-
-static DECLARE_TASKLET(irtask, run_handlers, 0);
-
-static void IR_handle(struct av7110 *av7110, u32 ircom)
-{
- dprintk(4, "ircommand = %08x\n", ircom);
- irtask.data = (unsigned long) ircom;
- tasklet_schedule(&irtask);
-}
-
/
* IRQ handling
/
@@ -711,8 +654,9 @@ static void gpioirq(unsigned long data)
return;
case DATA_IRCOMMAND:
- IR_handle(av7110,
- swahw32(irdebi(av7110, DEBINOSWAP, Reserved, 0, 4)));
+ if (av7110->ir_handler)
+ av7110->ir_handler(av7110,
+ swahw32(irdebi(av7110, DEBINOSWAP, Reserved, 0,
4)));
iwdebi(av7110, DEBINOSWAP, RX_BUFF, 0, 2);
break;
@@ -2783,7 +2727,7 @@ static int av7110_attach(struct saa7146_
goto err_av7110_exit_v4l_12;
#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
- av7110_ir_init();
+ av7110_ir_init(av7110);
#endif
printk(KERN_INFO "dvb-ttpci: found av7110-%d.\n", av7110_num);
av7110_num++;
@@ -2825,6 +2769,9 @@ static int av7110_detach(struct saa7146_
struct av7110 *av7110 = saa->ext_priv;
dprintk(4, "%p\n", av7110);
+#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
+ av7110_ir_exit(av7110);
+#endif
if (budgetpatch) {
/* Disable RPS1 */
saa7146_write(saa, MC1, MASK_29);
@@ -2980,9 +2927,6 @@ static int __init av7110_init(void)
static void __exit av7110_exit(void)
{
-#if defined(CONFIG_INPUT_EVDEV) || defined(CONFIG_INPUT_EVDEV_MODULE)
- av7110_ir_exit();
-#endif
saa7146_unregister_extension(&av7110_extension);
}
--- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/av7110.h 2005-09-04
22:03:40.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/ttpci/av7110.h 2005-09-04
22:31:00.0 +0200
@@ -228,7 +228,10 @@ struct av7110 {
struct dvb_video_events video_events;
video_size_t video_size;
- u32 ir_config;
+ u32 ir_config;
+ u32 ir_command;
+ void(*ir_handler)(struct av7110 *av7110, u32
ircom);
+ struct tasklet_struct ir_tasklet;
/* firmware st
[DVB patch 27/54] usb: dtt200u: add proper device names
From: Patrick Boettcher <[EMAIL PROTECTED]>
Added names for clones of the DVB-T stick.
Whitespace cleanups.
Signed-off-by: Patrick Boettcher <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/dvb-usb/dtt200u.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-usb/dtt200u.c 2005-09-04
22:24:23.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-usb/dtt200u.c 2005-09-04
22:28:20.0 +0200
@@ -106,12 +106,11 @@ static int dtt200u_usb_probe(struct usb_
}
static struct usb_device_id dtt200u_usb_table [] = {
-// { USB_DEVICE(0x04b4,0x8613) },
- { USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_DTT200U_COLD) },
- { USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_DTT200U_WARM) },
- { USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_WT220U_COLD) },
- { USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_WT220U_WARM) },
- { 0 },
+ { USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_DTT200U_COLD) },
+ { USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_DTT200U_WARM) },
+ { USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_WT220U_COLD) },
+ { USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_WT220U_WARM) },
+ { 0 },
};
MODULE_DEVICE_TABLE(usb, dtt200u_usb_table);
@@ -189,7 +188,7 @@ static struct dvb_usb_properties wt220u_
.num_device_descs = 1,
.devices = {
- { .name = "WideView WT-220U PenType Receiver (and clones)",
+ { .name = "WideView WT-220U PenType Receiver (Typhoon/Freecom)",
.cold_ids = { &dtt200u_usb_table[2], NULL },
.warm_ids = { &dtt200u_usb_table[3], NULL },
},
@@ -201,9 +200,9 @@ static struct dvb_usb_properties wt220u_
static struct usb_driver dtt200u_usb_driver = {
.owner = THIS_MODULE,
.name = "dvb_usb_dtt200u",
- .probe = dtt200u_usb_probe,
+ .probe = dtt200u_usb_probe,
.disconnect = dvb_usb_device_exit,
- .id_table = dtt200u_usb_table,
+ .id_table = dtt200u_usb_table,
};
/* module stuff */
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[DVB patch 28/54] usb: core: change dvb_usb_device_init() API
From: Patrick Boettcher <[EMAIL PROTECTED]>
Change the init call to optionally return the new dvb_usb_device directly.
Signed-off-by: Patrick Boettcher <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/dvb-usb/a800.c |2 +-
drivers/media/dvb/dvb-usb/cxusb.c|2 +-
drivers/media/dvb/dvb-usb/dibusb-mb.c|6 +++---
drivers/media/dvb/dvb-usb/dibusb-mc.c|2 +-
drivers/media/dvb/dvb-usb/digitv.c |2 +-
drivers/media/dvb/dvb-usb/dtt200u.c |4 ++--
drivers/media/dvb/dvb-usb/dvb-usb-ids.h |3 +++
drivers/media/dvb/dvb-usb/dvb-usb-init.c |7 ++-
drivers/media/dvb/dvb-usb/dvb-usb.h |4 ++--
drivers/media/dvb/dvb-usb/nova-t-usb2.c |2 +-
drivers/media/dvb/dvb-usb/umt-010.c |2 +-
drivers/media/dvb/dvb-usb/vp702x.c |2 +-
drivers/media/dvb/dvb-usb/vp7045.c |2 +-
13 files changed, 24 insertions(+), 16 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-usb/a800.c 2005-09-04
23:30:21.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-usb/a800.c 2005-09-04
23:32:19.0 +0200
@@ -90,7 +90,7 @@ static struct dvb_usb_properties a800_pr
static int a800_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
- return dvb_usb_device_init(intf,&a800_properties,THIS_MODULE);
+ return dvb_usb_device_init(intf,&a800_properties,THIS_MODULE,NULL);
}
/* do not change the order of the ID table */
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-usb/dibusb-mb.c
2005-09-04 23:32:19.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-usb/dibusb-mb.c 2005-09-04
23:32:19.0 +0200
@@ -86,9 +86,9 @@ static struct dvb_usb_properties dibusb2
static int dibusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
- if (dvb_usb_device_init(intf,&dibusb1_1_properties,THIS_MODULE) == 0 ||
-
dvb_usb_device_init(intf,&dibusb1_1_an2235_properties,THIS_MODULE) == 0 ||
- dvb_usb_device_init(intf,&dibusb2_0b_properties,THIS_MODULE) ==
0)
+ if (dvb_usb_device_init(intf,&dibusb1_1_properties,THIS_MODULE,NULL) ==
0 ||
+
dvb_usb_device_init(intf,&dibusb1_1_an2235_properties,THIS_MODULE,NULL) == 0 ||
+
dvb_usb_device_init(intf,&dibusb2_0b_properties,THIS_MODULE,NULL) == 0)
return 0;
return -EINVAL;
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-usb/dibusb-mc.c
2005-09-04 23:30:21.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-usb/dibusb-mc.c 2005-09-04
23:32:19.0 +0200
@@ -20,7 +20,7 @@ static struct dvb_usb_properties dibusb_
static int dibusb_mc_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
- return dvb_usb_device_init(intf,&dibusb_mc_properties,THIS_MODULE);
+ return dvb_usb_device_init(intf,&dibusb_mc_properties,THIS_MODULE,NULL);
}
/* do not change the order of the ID table */
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-usb/dtt200u.c 2005-09-04
23:32:19.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-usb/dtt200u.c 2005-09-04
23:32:19.0 +0200
@@ -98,8 +98,8 @@ static struct dvb_usb_properties wt220u_
static int dtt200u_usb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
- if (dvb_usb_device_init(intf,&dtt200u_properties,THIS_MODULE) == 0 ||
- dvb_usb_device_init(intf,&wt220u_properties,THIS_MODULE) == 0)
+ if (dvb_usb_device_init(intf,&dtt200u_properties,THIS_MODULE,NULL) == 0
||
+ dvb_usb_device_init(intf,&wt220u_properties,THIS_MODULE,NULL)
== 0)
return 0;
return -ENODEV;
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
2005-09-04 23:32:19.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2005-09-04
23:32:19.0 +0200
@@ -27,6 +27,7 @@
#define USB_VID_KWORLD 0xeb2a
#define USB_VID_KYE0x0458
#define USB_VID_MEDION 0x1660
+#define USB_VID_PINNACLE 0x2304
#define USB_VID_VISIONPLUS 0x13d3
#define USB_VID_TWINHAN0x1822
#define USB_VID_ULTIMA_ELECTRONIC 0x05d8
@@ -88,5 +89,7 @@
#define USB_PID_MEDION_MD95700 0x0932
#define USB_PID_KYE_DVB_T_COLD 0x701e
#define USB_PID_KYE_DVB_T_WARM 0x701f
+#define USB_PID_PCTV_200E 0x020e
+#define USB_PID_PCTV_400E 0x020f
#endif
--- linux-2.6.13-git4.orig/drivers/media/dvb/dvb-usb/dvb-usb-init.c
2005-09-04 23:32:19.
[DVB patch 47/54] budget-av: fixes for CI interface
From: Andrew de Quincey <[EMAIL PROTECTED]>
Fixes for CI interface.
Signed-off-by: Andrew de Quincey <[EMAIL PROTECTED]>
Signed-off-by: Johannes Stezenbach <[EMAIL PROTECTED]>
drivers/media/dvb/ttpci/budget-av.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- linux-2.6.13-git4.orig/drivers/media/dvb/ttpci/budget-av.c 2005-09-04
22:03:40.0 +0200
+++ linux-2.6.13-git4/drivers/media/dvb/ttpci/budget-av.c 2005-09-04
22:30:56.0 +0200
@@ -192,7 +192,7 @@ static int ciintf_slot_reset(struct dvb_
{
struct budget_av *budget_av = (struct budget_av *) ca->data;
struct saa7146_dev *saa = budget_av->budget.dev;
- int timeout = 50; // 5 seconds (4.4.6 Ready)
+ int timeout = 500; // 5 seconds (4.4.6 Ready)
if (slot != 0)
return -EINVAL;
@@ -217,7 +217,6 @@ static int ciintf_slot_reset(struct dvb_
{
printk(KERN_ERR "budget-av: cam reset failed (timeout).\n");
saa7146_setgpio(saa, 2, SAA7146_GPIO_OUTHI); /* disable card */
- saa7146_setgpio(saa, 0, SAA7146_GPIO_OUTHI); /* Vcc off */
return -ETIMEDOUT;
}
@@ -276,7 +275,6 @@ static int ciintf_poll_slot_status(struc
{
printk(KERN_INFO "budget-av: cam ejected\n");
saa7146_setgpio(saa, 2, SAA7146_GPIO_OUTHI); /* disable
card */
- saa7146_setgpio(saa, 0, SAA7146_GPIO_OUTHI); /* Vcc off
*/
budget_av->slot_status = 0;
}
}
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
