At 01:57 AM 4/5/2005 -0600, Zwane Mwaikambo wrote:
On Tue, 5 Apr 2005, Esben Nielsen wrote:
> > I'm sure a lot of the yield() users could be converted to
> > schedule_timeout(), some of the users i saw were for low memory
conditions
> > where we want other tasks to make progress and complete so
On Tue, 5 Apr 2005, Ingo Molnar wrote:
>
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > > Now the question is, who will fix it? Preferably the maintainers, but I
> > > don't know how much of a priority this is to them. I don't have the time
> > > now to look at this and understand enough
On Tue, 5 Apr 2005, Esben Nielsen wrote:
> > I'm sure a lot of the yield() users could be converted to
> > schedule_timeout(), some of the users i saw were for low memory conditions
> > where we want other tasks to make progress and complete so that we a bit
> > more free memory.
> >
>
>
On Tue, 5 Apr 2005, Esben Nielsen wrote:
I'm sure a lot of the yield() users could be converted to
schedule_timeout(), some of the users i saw were for low memory conditions
where we want other tasks to make progress and complete so that we a bit
more free memory.
Easy, but damn
On Tue, 5 Apr 2005, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
Now the question is, who will fix it? Preferably the maintainers, but I
don't know how much of a priority this is to them. I don't have the time
now to look at this and understand enough about the code
At 01:57 AM 4/5/2005 -0600, Zwane Mwaikambo wrote:
On Tue, 5 Apr 2005, Esben Nielsen wrote:
I'm sure a lot of the yield() users could be converted to
schedule_timeout(), some of the users i saw were for low memory
conditions
where we want other tasks to make progress and complete so that we
* Esben Nielsen <[EMAIL PROTECTED]> wrote:
> > Now the question is, who will fix it? Preferably the maintainers, but I
> > don't know how much of a priority this is to them. I don't have the time
> > now to look at this and understand enough about the code to be able to
> > make a proper fix,
On Mon, 4 Apr 2005, Zwane Mwaikambo wrote:
> On Mon, 4 Apr 2005, Steven Rostedt wrote:
>
> > On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
> >
> > > > Currently my fix is in yield to lower the priority of the task calling
> > > > yield and raise it after the schedule. This is NOT a
On Mon, 4 Apr 2005, Steven Rostedt wrote:
> On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
>
> > > Currently my fix is in yield to lower the priority of the task calling
> > > yield and raise it after the schedule. This is NOT a proper fix. It's
> > > just a hack so I can get by it and
On Mon, 2005-04-04 at 16:51 -0600, Zwane Mwaikambo wrote:
> I'm sure a lot of the yield() users could be converted to
> schedule_timeout(), some of the users i saw were for low memory conditions
> where we want other tasks to make progress and complete so that we a bit
> more free memory.
>
On Mon, 4 Apr 2005, Steven Rostedt wrote:
> On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
>
> > > Currently my fix is in yield to lower the priority of the task calling
> > > yield and raise it after the schedule. This is NOT a proper fix. It's
> > > just a hack so I can get by it and
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
> > Currently my fix is in yield to lower the priority of the task calling
> > yield and raise it after the schedule. This is NOT a proper fix. It's
> > just a hack so I can get by it and test other parts.
>
> yeah, yield() is a quite
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > actually, what priorities do the yielding tasks have? sched_yield() does
> > not guarantee that the CPU will be given up, of if a highest-prio
> > SCHED_FIFO task is in a yield() loop it will livelock the system.
>
> What scares me is the code
On Mon, 2005-04-04 at 22:00 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > So it is probably stuck in some spinning "yield" loop, which was the
> > reason I was writing this test to begin with! It's most likely also
> > waiting for kjournald to do some work, and
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> So it is probably stuck in some spinning "yield" loop, which was the
> reason I was writing this test to begin with! It's most likely also
> waiting for kjournald to do some work, and is starving it in a
> schedule or yield loop never actually
* Steven Rostedt [EMAIL PROTECTED] wrote:
So it is probably stuck in some spinning yield loop, which was the
reason I was writing this test to begin with! It's most likely also
waiting for kjournald to do some work, and is starving it in a
schedule or yield loop never actually going to
On Mon, 2005-04-04 at 22:00 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
So it is probably stuck in some spinning yield loop, which was the
reason I was writing this test to begin with! It's most likely also
waiting for kjournald to do some work, and is starving
* Steven Rostedt [EMAIL PROTECTED] wrote:
actually, what priorities do the yielding tasks have? sched_yield() does
not guarantee that the CPU will be given up, of if a highest-prio
SCHED_FIFO task is in a yield() loop it will livelock the system.
What scares me is the code in
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
just a hack so I can get by it and test other parts.
yeah, yield() is a quite
On Mon, 4 Apr 2005, Steven Rostedt wrote:
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
just a hack so I can get by it and test other
On Mon, 2005-04-04 at 16:51 -0600, Zwane Mwaikambo wrote:
I'm sure a lot of the yield() users could be converted to
schedule_timeout(), some of the users i saw were for low memory conditions
where we want other tasks to make progress and complete so that we a bit
more free memory.
I've
On Mon, 4 Apr 2005, Steven Rostedt wrote:
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
just a hack so I can get by it and test other
On Mon, 4 Apr 2005, Zwane Mwaikambo wrote:
On Mon, 4 Apr 2005, Steven Rostedt wrote:
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
* Esben Nielsen [EMAIL PROTECTED] wrote:
Now the question is, who will fix it? Preferably the maintainers, but I
don't know how much of a priority this is to them. I don't have the time
now to look at this and understand enough about the code to be able to
make a proper fix, and I'm sure
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> > Grub option), and the system just locked up hard. I just was curious
> > if this was from a different change. But at least in the latest it
> > shows output, and
On Saturday 02 April 2005 15:34, Ingo Molnar wrote:
>* Lee Revell <[EMAIL PROTECTED]> wrote:
>> It wasn't clear from your last mail whether you were using NFS.
>> If so I would be suspicious given the NFS changes in the new RT
>> patches. I'll try to reproduce the problem on a local fs.
>
>also,
On Sat, 2005-04-02 at 15:44 -0500, Steven Rostedt wrote:
> On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> > >
> > > FYI
> > >
> > > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> > > Grub option), and the system just locked up hard. I just was curious
> > >
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
> >
> > > Here's the bug I get:
> > >
> >
> > FYI
> >
> > For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
>
* Lee Revell <[EMAIL PROTECTED]> wrote:
> It wasn't clear from your last mail whether you were using NFS. If so
> I would be suspicious given the NFS changes in the new RT patches.
> I'll try to reproduce the problem on a local fs.
also, try to undo the fs/nfs/*.c and include/linux/*nfs*.h
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
>
> > Here's the bug I get:
> >
>
> FYI
>
> For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> Grub option), and the system just locked up hard. I just was curious
>
On Sat, 2005-04-02 at 15:06 -0500, Steven Rostedt wrote:
> On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
>
> > Here's the bug I get:
> >
>
> FYI
>
> For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
> Grub option), and the system just locked up hard. I just was
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
> What the test program does, is spawn 5 processes, each with a different
> priority. Starting with 10 and going to 14. All are SCHED_FIFO. Each of
> these processes just do a scan of all directories starting with the root
> directory '/'
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
> Here's the bug I get:
>
FYI
For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
Grub option), and the system just locked up hard. I just was curious if
this was from a different change. But at least in the latest it
Hi Ingo,
I've discovered a problem with basically all "yields" in the kernel. But
that's not why I'm writing you this. To see if your kernel has the same
problems as mine, I wrote a modified test that caused me the problems,
and ran it on your kernel. But too my surprise, this test caused other
Hi Ingo,
I've discovered a problem with basically all yields in the kernel. But
that's not why I'm writing you this. To see if your kernel has the same
problems as mine, I wrote a modified test that caused me the problems,
and ran it on your kernel. But too my surprise, this test caused other
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
Here's the bug I get:
FYI
For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
Grub option), and the system just locked up hard. I just was curious if
this was from a different change. But at least in the latest it
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
What the test program does, is spawn 5 processes, each with a different
priority. Starting with 10 and going to 14. All are SCHED_FIFO. Each of
these processes just do a scan of all directories starting with the root
directory '/' and
On Sat, 2005-04-02 at 15:06 -0500, Steven Rostedt wrote:
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
Here's the bug I get:
FYI
For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
Grub option), and the system just locked up hard. I just was curious if
* Steven Rostedt [EMAIL PROTECTED] wrote:
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
Here's the bug I get:
FYI
For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
Grub option), and the system just locked up hard. I just was curious
if this was
* Lee Revell [EMAIL PROTECTED] wrote:
It wasn't clear from your last mail whether you were using NFS. If so
I would be suspicious given the NFS changes in the new RT patches.
I'll try to reproduce the problem on a local fs.
also, try to undo the fs/nfs/*.c and include/linux/*nfs*.h
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
On Sat, 2005-04-02 at 14:37 -0500, Steven Rostedt wrote:
Here's the bug I get:
FYI
For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
Grub option), and the
On Sat, 2005-04-02 at 15:44 -0500, Steven Rostedt wrote:
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
FYI
For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
Grub option), and the system just locked up hard. I just was curious
if this was from a
On Saturday 02 April 2005 15:34, Ingo Molnar wrote:
* Lee Revell [EMAIL PROTECTED] wrote:
It wasn't clear from your last mail whether you were using NFS.
If so I would be suspicious given the NFS changes in the new RT
patches. I'll try to reproduce the problem on a local fs.
also, try to undo
On Sat, 2005-04-02 at 22:35 +0200, Ingo Molnar wrote:
For kicks I ran this on 2.6.11-rc2-RT-V0.7.36-02 (I still had it as a
Grub option), and the system just locked up hard. I just was curious
if this was from a different change. But at least in the latest it
shows output, and not just
* Gene Heskett <[EMAIL PROTECTED]> wrote:
> Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394
> product 0x/0x/0x
> Apr 1 18:05:24 coyote kernel:
> Apr 1 18:05:24 coyote kernel: ==
> Apr 1 18:05:24 coyote kernel: [ BUG: lock
On Friday 01 April 2005 20:45, Lee Revell wrote:
>On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
>> No one has commented about the loss of video in the
>> tvtime/pcHDTV-3000 card situation, am I on my own, basicly
>> reverting to the
>> pcHDTV-2.0.tar.gz stuff to overwrite the kernel
On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
> No one has commented about the loss of video in the tvtime/pcHDTV-3000
> card situation, am I on my own, basicly reverting to the
> pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
You didn't really give much of a clue as to where
On Friday 01 April 2005 14:22, K.R. Foley wrote:
>Gene Heskett wrote:
>> On Friday 01 April 2005 13:27, K.R. Foley wrote:
>>>Gene Heskett wrote:
>>>
>>>
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts
output:
>
>> >> needs unknown symbol __compat_down_failed_interruptible
>>
>> Nope. Same error output as last report.
>
> does -43-04 work for you?
>
RT-V0.7.43-05 is now working for me. No quirks so far, on the UP laptop.
Building now for the SMP/HT desktop.
Cheers.
--
rncbc aka Rui Nuno Capela
[EMAIL
Gene Heskett wrote:
On Friday 01 April 2005 13:27, K.R. Foley wrote:
Gene Heskett wrote:
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts
output: ---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file
On Friday 01 April 2005 13:29, Ingo Molnar wrote:
>* K.R. Foley <[EMAIL PROTECTED]> wrote:
>> >This one didn't go in cleanly Ingo. From my build-src scripts
>> > output: ---
>> >Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
>>
>> Adding the attached patch on top of the
On Friday 01 April 2005 13:27, K.R. Foley wrote:
>Gene Heskett wrote:
>
>
>> It was up to 43-04 by the time I got there.
>>
>> This one didn't go in cleanly Ingo. From my build-src scripts
>> output: ---
>> Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
>> [...]
>> patching
Gene Heskett wrote:
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts output:
---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at 160.
* K.R. Foley <[EMAIL PROTECTED]> wrote:
> >This one didn't go in cleanly Ingo. From my build-src scripts output:
> >---
> >Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
> Adding the attached patch on top of the above should resolve the
> failures, at least in the
On Friday 01 April 2005 05:47, Ingo Molnar wrote:
>i have released the -V0.7.43-00 Real-Time Preemption patch, which
> can be downloaded from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
>this release too is a step towards more robustness. I found a bug
> that caused an
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> >> needs unknown symbol __compat_down_failed_interruptible
>
> Nope. Same error output as last report.
does -43-04 work for you?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
> * Rui Nuno Capela wrote:
>
>> > thx - i've uploaded -43-01 which should fix this.
>> >
>>
>> Now it's dying-on-the-beach:
>
>> needs unknown symbol __compat_down_failed_interruptible
>
> ok - does -43-02 work any better?
>
Nope. Same error output as last report.
--
rncbc aka Rui Nuno Capela
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> > thx - i've uploaded -43-01 which should fix this.
> >
>
> Now it's dying-on-the-beach:
> needs unknown symbol __compat_down_failed_interruptible
ok - does -43-02 work any better?
Ingo
-
To unsubscribe from this list: send the line
>
> thx - i've uploaded -43-01 which should fix this.
>
Now it's dying-on-the-beach:
.
.
.
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F
System.map 2.6.12-rc1-RT-V0.7.43-01.0; fi
WARNING:
/lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/usb/storage/usb-storage.ko
needs
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> > i have released the -V0.7.43-00 Real-Time Preemption patch, which can be
> > downloaded from the usual place:
> >
>
> RT-V0.7.43-00 is failing to build here:
> kernel/rt.c:1435: error: `up_read' undeclared here (not in a function)
>
>
> i have released the -V0.7.43-00 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
RT-V0.7.43-00 is failing to build here:
.
.
.
CC kernel/rcupdate.o
CC kernel/intermodule.o
kernel/intermodule.c:179: warning: `inter_module_register' is deprecated
i have released the -V0.7.43-00 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
this release too is a step towards more robustness. I found a bug that
caused an infinite recursion and subsequent spontaneous reboot. The bug
i have released the -V0.7.43-00 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
this release too is a step towards more robustness. I found a bug that
caused an infinite recursion and subsequent spontaneous reboot. The bug
i have released the -V0.7.43-00 Real-Time Preemption patch, which can be
downloaded from the usual place:
RT-V0.7.43-00 is failing to build here:
.
.
.
CC kernel/rcupdate.o
CC kernel/intermodule.o
kernel/intermodule.c:179: warning: `inter_module_register' is deprecated
* Rui Nuno Capela [EMAIL PROTECTED] wrote:
i have released the -V0.7.43-00 Real-Time Preemption patch, which can be
downloaded from the usual place:
RT-V0.7.43-00 is failing to build here:
kernel/rt.c:1435: error: `up_read' undeclared here (not in a function)
kernel/rt.c:1435: error:
thx - i've uploaded -43-01 which should fix this.
Now it's dying-on-the-beach:
.
.
.
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F
System.map 2.6.12-rc1-RT-V0.7.43-01.0; fi
WARNING:
/lib/modules/2.6.12-rc1-RT-V0.7.43-01.0/kernel/drivers/usb/storage/usb-storage.ko
needs
* Rui Nuno Capela [EMAIL PROTECTED] wrote:
thx - i've uploaded -43-01 which should fix this.
Now it's dying-on-the-beach:
needs unknown symbol __compat_down_failed_interruptible
ok - does -43-02 work any better?
Ingo
-
To unsubscribe from this list: send the line unsubscribe
* Rui Nuno Capela wrote:
thx - i've uploaded -43-01 which should fix this.
Now it's dying-on-the-beach:
needs unknown symbol __compat_down_failed_interruptible
ok - does -43-02 work any better?
Nope. Same error output as last report.
--
rncbc aka Rui Nuno Capela
[EMAIL PROTECTED]
-
* Rui Nuno Capela [EMAIL PROTECTED] wrote:
needs unknown symbol __compat_down_failed_interruptible
Nope. Same error output as last report.
does -43-04 work for you?
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Friday 01 April 2005 05:47, Ingo Molnar wrote:
i have released the -V0.7.43-00 Real-Time Preemption patch, which
can be downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
this release too is a step towards more robustness. I found a bug
that caused an infinite
* K.R. Foley [EMAIL PROTECTED] wrote:
This one didn't go in cleanly Ingo. From my build-src scripts output:
---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
Adding the attached patch on top of the above should resolve the
failures, at least in the patching. Still
Gene Heskett wrote:
snip
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts output:
---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file lib/rwsem-spinlock.c
Hunk #5 FAILED at 133.
Hunk #6 FAILED at
On Friday 01 April 2005 13:27, K.R. Foley wrote:
Gene Heskett wrote:
snip
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts
output: ---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching file
On Friday 01 April 2005 13:29, Ingo Molnar wrote:
* K.R. Foley [EMAIL PROTECTED] wrote:
This one didn't go in cleanly Ingo. From my build-src scripts
output: ---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
Adding the attached patch on top of the above should
Gene Heskett wrote:
On Friday 01 April 2005 13:27, K.R. Foley wrote:
Gene Heskett wrote:
snip
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts
output: ---
Applying patch realtime-preempt-2.6.12-rc1-V0.7.43-04
[...]
patching
needs unknown symbol __compat_down_failed_interruptible
Nope. Same error output as last report.
does -43-04 work for you?
RT-V0.7.43-05 is now working for me. No quirks so far, on the UP laptop.
Building now for the SMP/HT desktop.
Cheers.
--
rncbc aka Rui Nuno Capela
[EMAIL PROTECTED]
On Friday 01 April 2005 14:22, K.R. Foley wrote:
Gene Heskett wrote:
On Friday 01 April 2005 13:27, K.R. Foley wrote:
Gene Heskett wrote:
snip
It was up to 43-04 by the time I got there.
This one didn't go in cleanly Ingo. From my build-src scripts
output: ---
Applying patch
On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
No one has commented about the loss of video in the tvtime/pcHDTV-3000
card situation, am I on my own, basicly reverting to the
pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
You didn't really give much of a clue as to where to
On Friday 01 April 2005 20:45, Lee Revell wrote:
On Fri, 2005-04-01 at 18:34 -0500, Gene Heskett wrote:
No one has commented about the loss of video in the
tvtime/pcHDTV-3000 card situation, am I on my own, basicly
reverting to the
pcHDTV-2.0.tar.gz stuff to overwrite the kernel stuff?
You
* Gene Heskett [EMAIL PROTECTED] wrote:
Apr 1 18:05:20 coyote ieee1394.agent[6016]: ... no drivers for IEEE1394
product 0x/0x/0x
Apr 1 18:05:24 coyote kernel:
Apr 1 18:05:24 coyote kernel: ==
Apr 1 18:05:24 coyote kernel: [ BUG: lock recursion
80 matches
Mail list logo
