isolated the reason
for the crash.
Misc. Details on the Ooops is:-
1) Isolation of code causing the crash - As below
2) Hardware : ARM based running linux 2.6.11 with 32 MB of RAM
4) Crash Dump : - As below.
Isolation of code causing the crash:-
___
The target on which
isolated the reason
for the crash.
Misc. Details on the Ooops is:-
1) Isolation of code causing the crash - As below
2) Hardware : ARM based running linux 2.6.11 with 32 MB of RAM
4) Crash Dump : - As below.
Isolation of code causing the crash:-
___
The target on which
On Thu, Apr 21, 2005 at 03:26:37PM -0700, Shaun Jackman wrote:
> I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
> 2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
> the new kernel. This did not work. I then tried compiling the lirc
> 0
I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
the new kernel. This did not work. I then tried compiling the lirc
0.7.1 modules for the new kernel. This didn't work either. The error
message lircd gives
I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
the new kernel. This did not work. I then tried compiling the lirc
0.7.1 modules for the new kernel. This didn't work either. The error
message lircd gives
On Thu, Apr 21, 2005 at 03:26:37PM -0700, Shaun Jackman wrote:
I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
the new kernel. This did not work. I then tried compiling the lirc
0.7.1 modules for the new
It wasn't the kernel.
Many thanks to those who helped me track down this problem.
It seems that the 'C' runtime library was trapping the call
to reboot() which probably should have been _reboot() in
earlier code to prevent this. Anyway, the fix is to call
the kernel directly so it doesn't get
On Fri, 8 Apr 2005, Daniel Jacobowitz wrote:
On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote:
On Thu, 7 Apr 2005, Jan Harkes wrote:
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it
On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote:
> On Thu, 7 Apr 2005, Jan Harkes wrote:
>
> >On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
> >>In the not-too distant past, one could disable Ctl-Alt-DEL.
> >>Can't do it anymore.
> >...
> >>Observe that
On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote:
On Thu, 7 Apr 2005, Jan Harkes wrote:
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
...
Observe that reboot() returns 0
On Fri, 8 Apr 2005, Daniel Jacobowitz wrote:
On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote:
On Thu, 7 Apr 2005, Jan Harkes wrote:
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it
It wasn't the kernel.
Many thanks to those who helped me track down this problem.
It seems that the 'C' runtime library was trapping the call
to reboot() which probably should have been _reboot() in
earlier code to prevent this. Anyway, the fix is to call
the kernel directly so it doesn't get
On Thu, 7 Apr 2005, Jan Harkes wrote:
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
...
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that,
On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote:
| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
|
| > On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
| >
| > |
| > | In the not-too distant past, one could disable Ctl-Alt-DEL.
|
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
> In the not-too distant past, one could disable Ctl-Alt-DEL.
> Can't do it anymore.
...
> Observe that reboot() returns 0 and `strace` understands what
> parameters were passed. The result is that, if I hit Ctl-Alt-Del,
> `init`
On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote:
| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
|
| > On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
| >
| > |
| > | In the not-too distant past, one could disable Ctl-Alt-DEL.
| > | Can't do it anymore.
| >
| > What
On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
|
| In the not-too distant past, one could disable Ctl-Alt-DEL.
| Can't do it anymore.
What should disabling C_A_D do?
| Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| [SNIPPED leading
On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
|
| In the not-too distant past, one could disable Ctl-Alt-DEL.
| Can't do it anymore.
What should disabling C_A_D do?
| Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| [SNIPPED leading stuff...]
|
| mprotect(0xb7fe4000,
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
Script started on Thu 07 Apr 2005 10:58:11 AM EDT
[SNIPPED leading stuff...]
mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
brk(0) = 0x804a000
brk(0x8053000)
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
Script started on Thu 07 Apr 2005 10:58:11 AM EDT
[SNIPPED leading stuff...]
mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
brk(0) = 0x804a000
brk(0x8053000)
On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
|
| In the not-too distant past, one could disable Ctl-Alt-DEL.
| Can't do it anymore.
What should disabling C_A_D do?
| Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| [SNIPPED leading stuff...]
|
| mprotect(0xb7fe4000,
On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
|
| In the not-too distant past, one could disable Ctl-Alt-DEL.
| Can't do it anymore.
What should disabling C_A_D do?
| Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| [SNIPPED leading
On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote:
| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
|
| On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
|
| |
| | In the not-too distant past, one could disable Ctl-Alt-DEL.
| | Can't do it anymore.
|
| What should
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
...
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that, if I hit Ctl-Alt-Del,
`init` will
On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote:
| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
|
| On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
|
| |
| | In the not-too distant past, one could disable Ctl-Alt-DEL.
| |
On Thu, 7 Apr 2005, Jan Harkes wrote:
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
...
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that,
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of linux-os
>Sent: Friday, March 25, 2005 1:19 PM
>To: Linux kernel
>Subject: mmap/munmap on linux-2.6.11
>
>Memory gurus,
>
>We have an application where a driver allocates D
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of linux-os
Sent: Friday, March 25, 2005 1:19 PM
To: Linux kernel
Subject: mmap/munmap on linux-2.6.11
Memory gurus,
We have an application where a driver allocates DMA-able memory.
This DMA-able memory
Memory gurus,
We have an application where a driver allocates DMA-able memory.
This DMA-able memory is mmap()ed to user-space. To conserve
DMA memory only single pages are obtained using
__get_dma_pages(GFP_KERNEL, 1) (one page at a time). These
pages, that may be scattered all about, are
Memory gurus,
We have an application where a driver allocates DMA-able memory.
This DMA-able memory is mmap()ed to user-space. To conserve
DMA memory only single pages are obtained using
__get_dma_pages(GFP_KERNEL, 1) (one page at a time). These
pages, that may be scattered all about, are
On Mon, Mar 21, 2005 at 02:25:55PM -0800, Andrew Morton wrote:
>"George Georgalis" <[EMAIL PROTECTED]> wrote:
>>
>> I'm very defiantly seeing a problem with the 2.6.11
>> kernel and my spamassassin setup. However, it's not
>> clear exactly where the problem is, seems like sa
>> but it might be
"George Georgalis" <[EMAIL PROTECTED]> wrote:
>
> I'm very defiantly seeing a problem with the 2.6.11
> kernel and my spamassassin setup. However, it's not
> clear exactly where the problem is, seems like sa
> but it might be 2.6.11 with daemontools + qmail +
> QMAIL_QUEUE.
>
> A sure sign of it
George Georgalis [EMAIL PROTECTED] wrote:
I'm very defiantly seeing a problem with the 2.6.11
kernel and my spamassassin setup. However, it's not
clear exactly where the problem is, seems like sa
but it might be 2.6.11 with daemontools + qmail +
QMAIL_QUEUE.
A sure sign of it is no logs
On Mon, Mar 21, 2005 at 02:25:55PM -0800, Andrew Morton wrote:
George Georgalis [EMAIL PROTECTED] wrote:
I'm very defiantly seeing a problem with the 2.6.11
kernel and my spamassassin setup. However, it's not
clear exactly where the problem is, seems like sa
but it might be 2.6.11 with
On Wed, Mar 16, 2005 at 05:37:59PM -0500, Paul Jarc wrote:
>"George Georgalis" <[EMAIL PROTECTED]> wrote:
>> On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
>>> To simplify, what about these two:
>>> mplayer foo.mpg
>>> mplayer foo.mpg < mediafiles.txt
>>
>> The particular host does not
"George Georgalis" <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
>> To simplify, what about these two:
>> mplayer foo.mpg
>> mplayer foo.mpg < mediafiles.txt
>
> The particular host does not have X support so mpg is out.
Well, use any one of the files
2.6.11-ac4
o Merge with 2.6.11.4
2.6.11-ac3
o Make SATA AHCI error recovery work (Brett Russ)
o Watchdog link order (Dave Jones)
o Ressurect the epca driver (Alan Cox)
o Merge with 2.6.11.3
2.6.11-ac2
o
Yes... sure"
$ export VAR2=$VAR1
$ export VAR3=$VAR1
$ export VAR4=$VAR1
$ export VAR5=$VAR1
Then check your env size is large enough
$ env|wc -c
4508
$ ./xxx
./xxx 2>/dev/null
Apparently the kernel thinks 4096 is a good length!
So what ? Your program works well now, on a linux-2
>/dev/null
Apparently the kernel thinks 4096 is a good length!
So what ? Your program works well now, on a linux-2.6.11 typical
machine. Ready to buffer overflow again.
Maybe you can pay me $1000 :)
Eric Dumazet
This is code for which there are no sources available
and it is required to be
linux-os wrote:
I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to
On Wed, 16 Mar 2005, Ian Campbell wrote:
On Wed, 2005-03-16 at 07:29 -0500, linux-os wrote:
This means that the read() is no longer perfectly happy
to corrupt all of the user's memory which is the defacto
correct response for a bad buffer as shown. Instead, some
added "check in software" claims to
On Wed, 2005-03-16 at 07:29 -0500, linux-os wrote:
> This means that the read() is no longer perfectly happy
> to corrupt all of the user's memory which is the defacto
> correct response for a bad buffer as shown. Instead, some
> added "check in software" claims to prevent this, but
> is wrong
On Tue, 15 Mar 2005, Tom Felker wrote:
On Tuesday 15 March 2005 11:59 am, linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return "Bad Address" until
the length is 1632 bytes. Apparently
On Tue, 15 Mar 2005, Robert Hancock wrote:
linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return "Bad Address" until
the length is 1632 bytes. Apparently the kernel thinks
1632 is a good
On Tue, 15 Mar 2005, Robert Hancock wrote:
linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return Bad Address until
the length is 1632 bytes. Apparently the kernel thinks
1632 is a good
On Tue, 15 Mar 2005, Tom Felker wrote:
On Tuesday 15 March 2005 11:59 am, linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return Bad Address until
the length is 1632 bytes. Apparently the
On Wed, 2005-03-16 at 07:29 -0500, linux-os wrote:
This means that the read() is no longer perfectly happy
to corrupt all of the user's memory which is the defacto
correct response for a bad buffer as shown. Instead, some
added check in software claims to prevent this, but
is wrong anyway
On Wed, 16 Mar 2005, Ian Campbell wrote:
On Wed, 2005-03-16 at 07:29 -0500, linux-os wrote:
This means that the read() is no longer perfectly happy
to corrupt all of the user's memory which is the defacto
correct response for a bad buffer as shown. Instead, some
added check in software claims to
linux-os wrote:
I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to
Apparently the kernel thinks 4096 is a good length!
So what ? Your program works well now, on a linux-2.6.11 typical
machine. Ready to buffer overflow again.
Maybe you can pay me $1000 :)
Eric Dumazet
This is code for which there are no sources available
and it is required to be used, cannot be replaced
... sure
$ export VAR2=$VAR1
$ export VAR3=$VAR1
$ export VAR4=$VAR1
$ export VAR5=$VAR1
Then check your env size is large enough
$ env|wc -c
4508
$ ./xxx
./xxx 2/dev/null
Apparently the kernel thinks 4096 is a good length!
So what ? Your program works well now, on a linux-2.6.11 typical machine
2.6.11-ac4
o Merge with 2.6.11.4
2.6.11-ac3
o Make SATA AHCI error recovery work (Brett Russ)
o Watchdog link order (Dave Jones)
o Ressurect the epca driver (Alan Cox)
o Merge with 2.6.11.3
2.6.11-ac2
o
George Georgalis [EMAIL PROTECTED] wrote:
On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
To simplify, what about these two:
mplayer foo.mpg
mplayer foo.mpg mediafiles.txt
The particular host does not have X support so mpg is out.
Well, use any one of the files listed in
On Wed, Mar 16, 2005 at 05:37:59PM -0500, Paul Jarc wrote:
George Georgalis [EMAIL PROTECTED] wrote:
On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
To simplify, what about these two:
mplayer foo.mpg
mplayer foo.mpg mediafiles.txt
The particular host does not have X support so
On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
>"George Georgalis" <[EMAIL PROTECTED]> wrote:
>> It (Gerrit Pape's technique) very defiantly stopped working a few revs
>> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
>> mplayer with 2.6.10, now too.
>
>The
On Tuesday 15 March 2005 11:59 am, linux-os wrote:
> The attached file shows that the kernel thinks it's doing
> something helpful by checking the length of the input
> buffer for a read(). It will return "Bad Address" until
> the length is 1632 bytes. Apparently the kernel thinks
> 1632 is a
linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return "Bad Address" until
the length is 1632 bytes. Apparently the kernel thinks
1632 is a good length!
Likely because only 1632 bytes of
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return "Bad Address" until
the length is 1632 bytes. Apparently the kernel thinks
1632 is a good length!
Did anybody consider the overhead necessary to do
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return Bad Address until
the length is 1632 bytes. Apparently the kernel thinks
1632 is a good length!
Did anybody consider the overhead necessary to do
linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return Bad Address until
the length is 1632 bytes. Apparently the kernel thinks
1632 is a good length!
Likely because only 1632 bytes of
On Tuesday 15 March 2005 11:59 am, linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return Bad Address until
the length is 1632 bytes. Apparently the kernel thinks
1632 is a good
On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
George Georgalis [EMAIL PROTECTED] wrote:
It (Gerrit Pape's technique) very defiantly stopped working a few revs
back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
mplayer with 2.6.10, now too.
The /proc/kmsg problem
Almost entirely the 2.6.11.3 update this time. Nice and simple because the
2.6.11.x is working out wonderfully.
Alan
2.6.11-ac3
o Merge in 2.6.11.3
o Make SATA AHCI error recovery work (Brett Russ)
o Watchdog link order (Dave Jones)
o
Almost entirely the 2.6.11.3 update this time. Nice and simple because the
2.6.11.x is working out wonderfully.
Alan
2.6.11-ac3
o Merge in 2.6.11.3
o Make SATA AHCI error recovery work (Brett Russ)
o Watchdog link order (Dave Jones)
o
Hi All,
An update of the uClinux (MMU-less) fixups against 2.6.11.
Most new changes center around the recent nommu changes to keep
the mm list as a vma list. Still a bunch of old changes I need
to push up stream in this patch too.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.11-uc0
Hi All,
An update of the uClinux (MMU-less) fixups against 2.6.11.
Most new changes center around the recent nommu changes to keep
the mm list as a vma list. Still a bunch of old changes I need
to push up stream in this patch too.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.11-uc0
Hi,
FiSC founds a potential error on JFS (Linux 2.6.11) where fsync doesn't
properly flushes out file data. Crash after this fsync causes data loss.
The test case can be found at http://fisc.stanford.edu/bug9/crash.c
To reproduce it, download and compile crash.c, and run it on a fresh jfs
Hi,
FiSC founds a potential error on JFS (Linux 2.6.11) where fsync doesn't
properly flushes out file data. Crash after this fsync causes data loss.
The test case can be found at http://fisc.stanford.edu/bug9/crash.c
To reproduce it, download and compile crash.c, and run it on a fresh jfs
Just booted 2.6.11-mm2 with a new .config and ran into this BUG(). Here
is the snippet from dmesg.
[ 25.088135] ohci_hcd :00:02.0: wakeup
[ 25.113120] BUG: soft lockup detected on CPU#0!
[ 25.113128]
[ 25.113135] Modules linked in: ehci_hcd ohci_hcd usbcore i2c_nforce2
it87 eeprom
On Iau, 2005-03-10 at 09:06, Tupshin Harper wrote:
> Alan...since you disagreed with the earlier characterization of what it
> would take to get into the mainline kernels, could you let us know what
> it would take in your opinion? FWIW, I'm happily using it with a -ac kernel.
It needs some
Alan Cox wrote:
On Mer, 2005-03-09 at 22:22, CaT wrote:
Argh! Ok. I guess I shouldn't've just bought the card based on this
driver then so that I could better debug my problems with my promise
cards. 8(
Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1
On Wednesday 09 March 2005 17:51, Alan Cox wrote:
> On Mer, 2005-03-09 at 07:26, CaT wrote:
> > > Carried over from 2.6.10-ac
> >
> > BTW. What's the probability of the ITE driver making it into the stock
> > kernel?
>
> I have given up caring about the base kernel IDE code. I've tried to get
>
On Wednesday 09 March 2005 17:51, Alan Cox wrote:
On Mer, 2005-03-09 at 07:26, CaT wrote:
Carried over from 2.6.10-ac
BTW. What's the probability of the ITE driver making it into the stock
kernel?
I have given up caring about the base kernel IDE code. I've tried to get
stuff
Alan Cox wrote:
On Mer, 2005-03-09 at 22:22, CaT wrote:
Argh! Ok. I guess I shouldn't've just bought the card based on this
driver then so that I could better debug my problems with my promise
cards. 8(
Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1
On Iau, 2005-03-10 at 09:06, Tupshin Harper wrote:
Alan...since you disagreed with the earlier characterization of what it
would take to get into the mainline kernels, could you let us know what
it would take in your opinion? FWIW, I'm happily using it with a -ac kernel.
It needs some small
Just booted 2.6.11-mm2 with a new .config and ran into this BUG(). Here
is the snippet from dmesg.
[ 25.088135] ohci_hcd :00:02.0: wakeup
[ 25.113120] BUG: soft lockup detected on CPU#0!
[ 25.113128]
[ 25.113135] Modules linked in: ehci_hcd ohci_hcd usbcore i2c_nforce2
it87 eeprom
On Mer, 2005-03-09 at 22:22, CaT wrote:
> Argh! Ok. I guess I shouldn't've just bought the card based on this
> driver then so that I could better debug my problems with my promise
> cards. 8(
Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1 performance is
On Wed, 09 Mar 2005, Paul Jarc uttered the following:
> "George Georgalis" <[EMAIL PROTECTED]> wrote:
>> It (Gerrit Pape's technique) very defiantly stopped working a few revs
>> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
>> mplayer with 2.6.10, now too.
>
> The /proc/kmsg
"George Georgalis" <[EMAIL PROTECTED]> wrote:
> It (Gerrit Pape's technique) very defiantly stopped working a few revs
> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
> mplayer with 2.6.10, now too.
The /proc/kmsg problem happens because the kernel now checks for
permission at
On Wed, Mar 09, 2005 at 05:43:02PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Wed, 09 Mar 2005 16:38:43 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> > On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
> > > It can be merged if somebody fix it to always force controller into
> > >
On Wed, 09 Mar 2005 16:38:43 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
> > It can be merged if somebody fix it to always force controller into
> > non-RAID mode and remove RAID mode support (which currently
> > does nothing more
On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
> It can be merged if somebody fix it to always force controller into
> non-RAID mode and remove RAID mode support (which currently
> does nothing more besides complicating the driver and making special
> commands unusable).
Incorrect
On Wed, 9 Mar 2005 18:26:46 +1100, CaT <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 07, 2005 at 09:34:22PM +, Alan Cox wrote:
> > For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this
> > diff should actually apply to either right now.
> >
> > 2.6.11-ac1
> > o Fix jbd race
On Mer, 2005-03-09 at 07:26, CaT wrote:
> > Carried over from 2.6.10-ac
>
> BTW. What's the probability of the ITE driver making it into the stock
> kernel?
I have given up caring about the base kernel IDE code. I've tried to get
stuff submitted and failed. I've no plan to waste further time on
On Wed, Mar 09, 2005 at 01:06:11PM +, Nix wrote:
>> An interesting technique that allows a program (such as a log writer)
>> to run as an unprivileged user, while receiving privileged data. (taken
>> almost verbatim from Gerrit Pape's socklog)
>>
>> #!/bin/sh
>> exec > exec 2>&1
>> exec
On Tue, 8 Mar 2005, George Georgalis announced authoritatively:
> Here's what I'm doing that is broken. I use tcpserver (functionally
> similar to inetd) to receive an incoming smtp connection. While the
> smtp session is still open, the message is piped to a temp file which
> is then scanned for
On Tue, 8 Mar 2005, George Georgalis announced authoritatively:
Here's what I'm doing that is broken. I use tcpserver (functionally
similar to inetd) to receive an incoming smtp connection. While the
smtp session is still open, the message is piped to a temp file which
is then scanned for
On Wed, Mar 09, 2005 at 01:06:11PM +, Nix wrote:
An interesting technique that allows a program (such as a log writer)
to run as an unprivileged user, while receiving privileged data. (taken
almost verbatim from Gerrit Pape's socklog)
#!/bin/sh
exec /proc/kmsg
exec 21
exec softlimit
On Mer, 2005-03-09 at 07:26, CaT wrote:
Carried over from 2.6.10-ac
BTW. What's the probability of the ITE driver making it into the stock
kernel?
I have given up caring about the base kernel IDE code. I've tried to get
stuff submitted and failed. I've no plan to waste further time on it.
On Wed, 9 Mar 2005 18:26:46 +1100, CaT [EMAIL PROTECTED] wrote:
On Mon, Mar 07, 2005 at 09:34:22PM +, Alan Cox wrote:
For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this
diff should actually apply to either right now.
2.6.11-ac1
o Fix jbd race in ext3
On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
It can be merged if somebody fix it to always force controller into
non-RAID mode and remove RAID mode support (which currently
does nothing more besides complicating the driver and making special
commands unusable).
Incorrect
-
On Wed, 09 Mar 2005 16:38:43 +, Alan Cox [EMAIL PROTECTED] wrote:
On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
It can be merged if somebody fix it to always force controller into
non-RAID mode and remove RAID mode support (which currently
does nothing more besides
On Wed, Mar 09, 2005 at 05:43:02PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Wed, 09 Mar 2005 16:38:43 +, Alan Cox [EMAIL PROTECTED] wrote:
On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
It can be merged if somebody fix it to always force controller into
non-RAID mode
George Georgalis [EMAIL PROTECTED] wrote:
It (Gerrit Pape's technique) very defiantly stopped working a few revs
back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
mplayer with 2.6.10, now too.
The /proc/kmsg problem happens because the kernel now checks for
permission at read()
On Wed, 09 Mar 2005, Paul Jarc uttered the following:
George Georgalis [EMAIL PROTECTED] wrote:
It (Gerrit Pape's technique) very defiantly stopped working a few revs
back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
mplayer with 2.6.10, now too.
The /proc/kmsg problem
On Mer, 2005-03-09 at 22:22, CaT wrote:
Argh! Ok. I guess I shouldn't've just bought the card based on this
driver then so that I could better debug my problems with my promise
cards. 8(
Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1 performance is very
On Mon, Mar 07, 2005 at 09:34:22PM +, Alan Cox wrote:
> For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this
> diff should actually apply to either right now.
>
> 2.6.11-ac1
> o Fix jbd race in ext3(Stephen Tweedie)
>
> Carried over from
George Georgalis wrote:
Here is a problem with 2.6.10:
while read file; do mplayer $file ; done
or
tail -n93 mediafiles.txt | while read file; do mplayer $file ; done
for each file path in that text file I get:
Failed to open /dev/rtc: Permission denied (it should be readable by the user.)
^-
Hi Andrew,
Here's the latest version of relayfs, against linux-2.6.11-mm2. I'm
hoping you'll consider putting this version back into your tree - the
previous rounds of comment seem to have shaken out all the API issues
and the number of comments on the code itself have also steadily
dwindled
On Tue, 8 Mar 2005 12:19:53 -0500, George Georgalis <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 08, 2005 at 11:58:14AM -0500, George Georgalis wrote:
> >On Tue, Mar 08, 2005 at 01:37:03PM +, Nix wrote:
> >>On Thu, 3 Mar 2005, George Georgalis uttered the following:
> >>> I recall a problem a
1 - 100 of 340 matches
Mail list logo
