Processing commands for cont...@bugs.debian.org:
> tags 717681 + patch
Bug #717681 [src:linux] linux-image-3.10-1-amd64: reproducable Data loss with
kernel linux-image-3.10-1-amd64 with md-raid devices
Added tag(s) patch.
> thanks
Stopping processing here.
Please contact me if you need assistanc
On Wed, 2013-07-24 at 13:34 +1000, NeilBrown wrote:
> On Wed, 24 Jul 2013 04:02:15 +0100 Ben Hutchings wrote:
>
> > Neil, does the report below sound like the bug you fixed with:
> >
> > commit 7bb23c4934059c64cbee2e41d5d24ce122285176
> > Author: NeilBrown
> > Date: Tue Jul 16 16:50:47 2013 +
Caro Webmail / E-mail do Usuário,
Esta mensagem é de nosso centro de mensagens a todos os nossos usuários de
webmail.
Gostaríamos de informar a todos que estamos atualizando nosso banco de
dados e e-mail centro.
Assim, a exclusão de todas as contas de email não utilizados inativo para
criar mais
Package: src:linux
Version: 3.2.46-1
Severity: normal
Hello, I have several hosts running wheezy that randomly panic and
reboot anywhere between a day and a few months of uptime.
Kernel package versions:
linux-image-3.2.0-4-amd64 3.2.46-1
linux-image-3.9-0.bpo.1-amd64 3.9.6-1~bpo70+1
The pa
On Wed, Jul 24, 2013 at 05:21:15PM +, Thorsten Glaser wrote:
> Ben Hutchings dixit:
>
> >Yes, but why should this be m68k-specific?
>
> OK. I’ll resend a patch that makes CONFIG_NFS_SWAP global
> and addresses the other things raised.
>
> Will you also want the Macintosh codepages for HFS+ b
Ben Hutchings dixit:
>Yes, but why should this be m68k-specific?
OK. I’ll resend a patch that makes CONFIG_NFS_SWAP global
and addresses the other things raised.
Will you also want the Macintosh codepages for HFS+ be
made global? (I assume so, since HFS+ is globally enabled.)
bye,
//mirabilos
-
On 10.7.2013 16:21, Michal Marek wrote:
> Dne 10.7.2013 15:09, Anisse Astier napsal(a):
>> Michal,
>>
>> Every patch has now been reviewed, do you think it would be possible to
>> take this series for 3.12 ?
>
> Yes, I will merge it as soon as this merge window closes.
This is now in kbuild.git#m
On Wed, Jul 24, 2013 at 9:34 AM, Thorsten Glaser wrote:
>> > >> +## choice: Preemption Model
> […]
>> Now why do you want to change that?
>
> My naïve reasoning is like that: less preemption = less
> interruption / context switches = more work done in total
> at the cost of a bit interactivity (pr
3.2.49-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
commit 2779db8d37d4b542d9ca2575f5f178dbeaca6c86 upstream.
Commit 02725e7471b8 ('genirq: Use irq_get/put functions'),
inadvertently changed can_request_irq() to return 0 for IRQs t
On Wed, 2013-07-24 at 15:57 +0400, Askar Safin wrote:
> > I think this file should be updated every time the package
> > "initramfs-tools" is reconfigured.
>
> Also, ideally, initramfs should be rebuilded every time user changes
> fstab. But, I think this is very hard to reach.
> Also, I think, e
On Wed, 2013-07-24 at 12:06 +0200, Wouter Verhelst wrote:
> On 24-07-13 04:10, Ben Hutchings wrote:
> +CONFIG_NFS_SWAP=y
> >
> > Really?
>
> It _should_ be safe since the PF_MEMALLOC patches were accepted
> (3.6-rc1, commit 7f338fe4540b and friends). Haven't tested it myself
> yet, though.
>
Dixi quod…
>>Another thing that puzzles me:
>>
>>config SMC91X
>>depends on (ARM || M32R || SUPERH || MIPS || BLACKFIN || \
>>MN10300 || COLDFIRE || ARM64)
>
>Maybe just an explicit || ATARI_ETHERNAT here?
>
>Add || ATARI_ETHERNEC to NE2000 as well I’d say, so everyone
> I think this file should be updated every time the package "initramfs-tools"
> is reconfigured.
Also, ideally, initramfs should be rebuilded every time user changes fstab.
But, I think this is very hard to reach.
Also, I think, every tool which updates fstab, should call initramfs rebuilding
>Should/must the uswsusp package update that file? What is the better way to do
>it (modify the file directly, call any script,...)?
I think this file should be updated every time the package "initramfs-tools" is
reconfigured.
I. e. every time initramfs is rebuilded.
As well as I know, when initr
On 24-07-13 04:10, Ben Hutchings wrote:
+CONFIG_NFS_SWAP=y
>
> Really?
It _should_ be safe since the PF_MEMALLOC patches were accepted
(3.6-rc1, commit 7f338fe4540b and friends). Haven't tested it myself
yet, though.
(and yes, I would say that swap over NBD will produce less overhead and
is
> Anyway I will make /etc/mtab as a regular file and disable
> mtab_migrate() shell function in /lib/init/mount-functions.sh on wheezy
> since this problem is a show-stopper for me.
I've met another problem of /bin/umount (mount package).
But this is specific to the system where /etc/mtab is a re
On Wed, 24 Jul 2013, Ben Hutchings wrote:
[ ext2/3/4 ]
> I think we may want to enable this at the top level later, but there is
> no reason to override it now.
OK, will remove that.
> > >> +CONFIG_NFS_SWAP=y
>
> Really?
Not? Is there something better?
Hm, Wouter would probably say swap over n
On Wed, Jul 24, 2013 at 12:04:49AM +0100, Ben Hutchings wrote:
> This is absolutely stable material. Most of the people affected are
> not going to work out that they plugged their memory in wrong. (And
> maybe some of them only have one module.)
Hmm, not from my experience. This is the first repo
Ben Hutchings:
> Well, I don't understand how this is going wrong. All the logic in
> fs/nfs/super.c (nfs_show_mount_options(), nfs_remount(),
> nfs_parse_security_flavors(), nfs_compare_remount_data()) appears to do
> the right thing with the sec option (stored in various structures as
> auth_fl
19 matches
Mail list logo
