On Saturday 04 August 2007, Alan Cox wrote:
>
> Linux has never been a "suprise your kernel interfaces all just changed
> today" kernel, nor a "gosh you upgraded and didn't notice your backups
> broke" kernel.
>
Can you give examples of backup solutions that rely on atime being updated?
I can
On Saturday 04 August 2007, Alan Cox wrote:
Linux has never been a suprise your kernel interfaces all just changed
today kernel, nor a gosh you upgraded and didn't notice your backups
broke kernel.
Can you give examples of backup solutions that rely on atime being updated?
I can understand
On Tuesday 12 April 2005 01:46, Andrew Morton wrote:
> Claudio Martins <[EMAIL PROTECTED]> wrote:
> > I think I'm going to give a try to Neil's patch, but I'll have to apply
> > some patches from -mm.
>
> Just this one if you're using 2.6.12-rc2:
>
> ---
On Tuesday 12 April 2005 01:46, Andrew Morton wrote:
Claudio Martins [EMAIL PROTECTED] wrote:
I think I'm going to give a try to Neil's patch, but I'll have to apply
some patches from -mm.
Just this one if you're using 2.6.12-rc2:
--- 25/drivers/md/md.c~avoid-deadlock-in-sync_page_io
On Tuesday 12 April 2005 00:46, Neil Brown wrote:
> On Monday April 11, [EMAIL PROTECTED] wrote:
> > Neil, have you had a look at the traces? Do they mean much to you?
>
> Just looked.
> bio_alloc_bioset seems implicated, as does sync_page_io.
>
> sync_page_io used to use a 'struct bio' on the
On Monday 11 April 2005 23:59, Nick Piggin wrote:
>
> > OK, I'll try them in a few minutes and report back.
>
> I'm not overly hopeful. If they fix the problem, then it's likely
> that the real bug is hidden.
>
Well, the thing is, they do fix the problem. Or at least they hide it very
well
On Monday 11 April 2005 13:45, Nick Piggin wrote:
>
> No luck yet (on SMP i386). How many disks are you using in each
> raid1 array? You are using one array for swap, and one mounted as
> ext3 for the working area of the `stress` program, right?
>
Right. I'm using two Seagate ATA133 disks
On Monday 11 April 2005 13:45, Nick Piggin wrote:
No luck yet (on SMP i386). How many disks are you using in each
raid1 array? You are using one array for swap, and one mounted as
ext3 for the working area of the `stress` program, right?
Right. I'm using two Seagate ATA133 disks (ide
On Monday 11 April 2005 23:59, Nick Piggin wrote:
OK, I'll try them in a few minutes and report back.
I'm not overly hopeful. If they fix the problem, then it's likely
that the real bug is hidden.
Well, the thing is, they do fix the problem. Or at least they hide it very
well ;-)
On Tuesday 12 April 2005 00:46, Neil Brown wrote:
On Monday April 11, [EMAIL PROTECTED] wrote:
Neil, have you had a look at the traces? Do they mean much to you?
Just looked.
bio_alloc_bioset seems implicated, as does sync_page_io.
sync_page_io used to use a 'struct bio' on the stack, but
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
>
> Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
> cutting in during long sysrq traces.
>
> Also, capture the `sysrq-m' output so we can see if the thing is out of
> memory.
Hi Andrew,
Thanks for the tip. I
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.
Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.
Hi Andrew,
Thanks for the tip. I booted with
On Sunday 10 April 2005 03:53, Nick Piggin wrote:
>
> Looks like you may possibly have a memory allocation deadlock
> (although I can't explain the NMI oops).
>
> I would be interested to see if the following patch is of any
> help to you.
>
Hi Nick,
I'll build a kernel with your patch and
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
>
> Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
> cutting in during long sysrq traces.
>
> Also, capture the `sysrq-m' output so we can see if the thing is out of
> memory.
OK, will do it ASAP and report back.
On Tuesday 05 April 2005 03:12, Andrew Morton wrote:
> Claudio Martins <[EMAIL PROTECTED]> wrote:
> >While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck
> > in D state after some time.
> >This machine is a dual Opteron 248 with 2GB (ECC) on o
On Tuesday 05 April 2005 03:12, Andrew Morton wrote:
Claudio Martins [EMAIL PROTECTED] wrote:
While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck
in D state after some time.
This machine is a dual Opteron 248 with 2GB (ECC) on one node (the
other node has no RAM
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.
Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.
OK, will do it ASAP and report back.
Thanks,
On Sunday 10 April 2005 03:53, Nick Piggin wrote:
Looks like you may possibly have a memory allocation deadlock
(although I can't explain the NMI oops).
I would be interested to see if the following patch is of any
help to you.
Hi Nick,
I'll build a kernel with your patch and report
. Please let me
know if you want me to run some other tests or give some more info to help
solve this one.
Kernel config follows (compiled with gcc-3.4.4 on debian)...
Best regards, thanks
Claudio Martins
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc2
. Please let me
know if you want me to run some other tests or give some more info to help
solve this one.
Kernel config follows (compiled with gcc-3.4.4 on debian)...
Best regards, thanks
Claudio Martins
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.12-rc2
On Monday 25 June 2001 11:21, Rodrigo Ventura wrote:
> /proc> cat version meminfo
> Linux version 2.4.6-pre3 (yoda@damasio) (gcc version 2.95.2 19991024
> (release)) #3 Mon Jun 18 19:00:11 WEST 2001 total:used:free:
> shared: buffers: cached:
> Mem: 261779456 256925696 4853760
On Monday 25 June 2001 11:21, Rodrigo Ventura wrote:
/proc cat version meminfo
Linux version 2.4.6-pre3 (yoda@damasio) (gcc version 2.95.2 19991024
(release)) #3 Mon Jun 18 19:00:11 WEST 2001 total:used:free:
shared: buffers: cached:
Mem: 261779456 256925696 48537600
On Thursday 14 June 2001 01:44, Daniel wrote:
> -- If someone really needs support for this junk, they will always have the
> option of using the 2.0.x, 2.2.x or 2.4.x series.
>
You mean you want 2.5+ series to just stop supporting all older hardware?
> So without further ado here're the
On Thursday 14 June 2001 01:44, Daniel wrote:
-- If someone really needs support for this junk, they will always have the
option of using the 2.0.x, 2.2.x or 2.4.x series.
You mean you want 2.5+ series to just stop supporting all older hardware?
So without further ado here're the
Hi
I would like to know if there is any support in the 2.4.x kernels for
Adaptec SCSI RAID ASR-2100S cards. It seems that one can download a driver
or patch from Adaptec website for 2.2.x kernels...
Can someone point me for any patch or driver available for the 2.4
series?
Thanks in
Hi
I would like to know if there is any support in the 2.4.x kernels for
Adaptec SCSI RAID ASR-2100S cards. It seems that one can download a driver
or patch from Adaptec website for 2.2.x kernels...
Can someone point me for any patch or driver available for the 2.4
series?
Thanks in
26 matches
Mail list logo
