Bug#820752: nfs-kernel-server: nfs server fails to start: nfds module can not be loaded: failed to allocate reply cache

2016-04-11 Thread J Mo 


No special VM settings. The system had an uptime of 17 days.

The hardware is slightly odd, being a Zotac ZBox Nano CI320, which uses 
the Intel N2930, but it's stable and I have not had any other problems 
worth noting.


I upgraded and rebooted to linux-image-4.4.0-1-amd64 and now the issue 
is gone. Not sure if it's because of the fresh reboot or the upgrade.


Thanks Ben



On 4/11/16 20:05, Ben Hutchings wrote:

Control: reassign -1 src:linux 4.3.3-7
Control: severity -1 normal
Control: tag -1 unreproducible moreinfo

On Mon, 2016-04-11 at 17:43 -0700, J Mo wrote:

Package: nfs-kernel-server
Version: 1:1.2.8-9
Severity: grave
Justification: renders package unusable

Relatively new system and I'm trying to get nfsd working, but it fails.

It failed for you, but generally it works.


After looking at journalctl, it seems that the nfsd module can not be loaded:

Apr 11 17:37:50.511723 myhost kernel: Installing knfsd (copyright (C) 1996 
o...@monad.swb.de).
Apr 11 17:37:50.511864 myhost kernel: modprobe: page allocation failure: 
order:4, mode:0x2040d0

That's an allocation of 64 KiB with mode GFP_KERNEL | __GFP_COMP |
__GFP_NOTRACK.

[...]

Apr 11 17:37:50.513675 myhost kernel: Node 0 DMA free:15896kB min:20kB low:24kB 
high:28kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB 
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15984kB 
managed:15900kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB 
slab_reclaimable:4kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB 
unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Apr 11 17:37:50.513742 myhost kernel: lowmem_reserve[]: 0 2870 7861 7861
Apr 11 17:37:50.513811 myhost kernel: Node 0 DMA32 free:703004kB min:4112kB 
low:5140kB high:6168kB active_anon:13524kB inactive_anon:17448kB 
active_file:500576kB inactive_file:512192kB unevictable:0kB isolated(anon):0kB 
isolated(file):0kB present:3018236kB managed:2942260kB mlocked:0kB dirty:0kB 
writeback:0kB mapped:16376kB shmem:5232kB slab_reclaimable:1151992kB 
slab_unreclaimable:29404kB kernel_stack:1152kB pagetables:4056kB unstable:0kB 
bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB 
pages_scanned:0 all_unreclaimable? no
Apr 11 17:37:50.514824 myhost kernel: lowmem_reserve[]: 0 0 4990 4990
Apr 11 17:37:50.514899 myhost kernel: Node 0 Normal free:315912kB min:7152kB 
low:8940kB high:10728kB active_anon:33964kB inactive_anon:21560kB 
active_file:1120576kB inactive_file:1447708kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:5242880kB managed:5110500kB 
mlocked:0kB dirty:16kB writeback:0kB mapped:32176kB shmem:15280kB 
slab_reclaimable:2083336kB slab_unreclaimable:48188kB kernel_stack:1440kB 
pagetables:6980kB unstable:0kB bounce:0kB free_pcp:188kB local_pcp:0kB 
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Apr 11 17:37:50.516638 myhost kernel: lowmem_reserve[]: 0 0 0 0
Apr 11 17:37:50.516721 myhost kernel: Node 0 DMA: 2*4kB (UE) 2*8kB (UE) 2*16kB 
(UE) 1*32kB (E) 3*64kB (UE) 2*128kB (UE) 2*256kB (UE) 1*512kB (E) 2*1024kB (UE) 
2*2048kB (EM) 2*4096kB (M) = 15896kB
Apr 11 17:37:50.516789 myhost kernel: Node 0 DMA32: 105486*4kB (UEM) 32237*8kB 
(UEM) 1411*16kB (UEM) 30*32kB (UEM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 
0*2048kB 0*4096kB = 703376kB
Apr 11 17:37:50.516856 myhost kernel: Node 0 Normal: 64405*4kB (UEM) 6948*8kB 
(UEM) 161*16kB (UEM) 5*32kB (EM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 
0*2048kB 0*4096kB = 315940kB
Apr 11 17:37:50.516924 myhost kernel: Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=2048kB
Apr 11 17:37:50.516992 myhost kernel: 901921 total pagecache pages
Apr 11 17:37:50.517064 myhost kernel: 1530 pages in swap cache
Apr 11 17:37:50.517128 myhost kernel: Swap cache stats: add 15480, delete 
13950, find 36006575/36008881
Apr 11 17:37:50.517194 myhost kernel: Free swap  = 3874448kB
Apr 11 17:37:50.517257 myhost kernel: Total swap = 3906556kB

[...]

Strange.  The system had lots of RAM and swap available.  The Normal
zone was fragmented so no 64 KiB blocks were immediately available, but
this allocation could have waited for defragmentation if needed.

(Such fragmentation only occurs after the system has been running for
some time, so I'm confident nfsd will successfully load if you try
loading it shortly after booting.)

Do you have any VM settings in /etc/sysctl.conf or /etc/sysctl.d?

Ben.

Bug#820752: nfs-kernel-server: nfs server fails to start: nfds module can not be loaded: failed to allocate reply cache

2016-04-11 Thread Ben Hutchings 
Control: reassign -1 src:linux 4.3.3-7
Control: severity -1 normal
Control: tag -1 unreproducible moreinfo

On Mon, 2016-04-11 at 17:43 -0700, J Mo wrote:
> Package: nfs-kernel-server
> Version: 1:1.2.8-9
> Severity: grave
> Justification: renders package unusable
> 
> Relatively new system and I'm trying to get nfsd working, but it fails.

It failed for you, but generally it works.

> After looking at journalctl, it seems that the nfsd module can not be loaded:
> 
> Apr 11 17:37:50.511723 myhost kernel: Installing knfsd (copyright (C) 1996 
> o...@monad.swb.de).
> Apr 11 17:37:50.511864 myhost kernel: modprobe: page allocation failure: 
> order:4, mode:0x2040d0

That's an allocation of 64 KiB with mode GFP_KERNEL | __GFP_COMP |
__GFP_NOTRACK.

[...]
> Apr 11 17:37:50.513675 myhost kernel: Node 0 DMA free:15896kB min:20kB 
> low:24kB high:28kB active_anon:0kB inactive_anon:0kB active_file:0kB 
> inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
> present:15984kB managed:15900kB mlocked:0kB dirty:0kB writeback:0kB 
> mapped:0kB shmem:0kB slab_reclaimable:4kB slab_unreclaimable:0kB 
> kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB 
> local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 
> all_unreclaimable? yes
> Apr 11 17:37:50.513742 myhost kernel: lowmem_reserve[]: 0 2870 7861 7861
> Apr 11 17:37:50.513811 myhost kernel: Node 0 DMA32 free:703004kB min:4112kB 
> low:5140kB high:6168kB active_anon:13524kB inactive_anon:17448kB 
> active_file:500576kB inactive_file:512192kB unevictable:0kB 
> isolated(anon):0kB isolated(file):0kB present:3018236kB managed:2942260kB 
> mlocked:0kB dirty:0kB writeback:0kB mapped:16376kB shmem:5232kB 
> slab_reclaimable:1151992kB slab_unreclaimable:29404kB kernel_stack:1152kB 
> pagetables:4056kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB 
> free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> Apr 11 17:37:50.514824 myhost kernel: lowmem_reserve[]: 0 0 4990 4990
> Apr 11 17:37:50.514899 myhost kernel: Node 0 Normal free:315912kB min:7152kB 
> low:8940kB high:10728kB active_anon:33964kB inactive_anon:21560kB 
> active_file:1120576kB inactive_file:1447708kB unevictable:0kB 
> isolated(anon):0kB isolated(file):0kB present:5242880kB managed:5110500kB 
> mlocked:0kB dirty:16kB writeback:0kB mapped:32176kB shmem:15280kB 
> slab_reclaimable:2083336kB slab_unreclaimable:48188kB kernel_stack:1440kB 
> pagetables:6980kB unstable:0kB bounce:0kB free_pcp:188kB local_pcp:0kB 
> free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> Apr 11 17:37:50.516638 myhost kernel: lowmem_reserve[]: 0 0 0 0
> Apr 11 17:37:50.516721 myhost kernel: Node 0 DMA: 2*4kB (UE) 2*8kB (UE) 
> 2*16kB (UE) 1*32kB (E) 3*64kB (UE) 2*128kB (UE) 2*256kB (UE) 1*512kB (E) 
> 2*1024kB (UE) 2*2048kB (EM) 2*4096kB (M) = 15896kB
> Apr 11 17:37:50.516789 myhost kernel: Node 0 DMA32: 105486*4kB (UEM) 
> 32237*8kB (UEM) 1411*16kB (UEM) 30*32kB (UEM) 0*64kB 0*128kB 0*256kB 0*512kB 
> 0*1024kB 0*2048kB 0*4096kB = 703376kB
> Apr 11 17:37:50.516856 myhost kernel: Node 0 Normal: 64405*4kB (UEM) 6948*8kB 
> (UEM) 161*16kB (UEM) 5*32kB (EM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 
> 0*2048kB 0*4096kB = 315940kB
> Apr 11 17:37:50.516924 myhost kernel: Node 0 hugepages_total=0 
> hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
> Apr 11 17:37:50.516992 myhost kernel: 901921 total pagecache pages
> Apr 11 17:37:50.517064 myhost kernel: 1530 pages in swap cache
> Apr 11 17:37:50.517128 myhost kernel: Swap cache stats: add 15480, delete 
> 13950, find 36006575/36008881
> Apr 11 17:37:50.517194 myhost kernel: Free swap  = 3874448kB
> Apr 11 17:37:50.517257 myhost kernel: Total swap = 3906556kB
[...]

Strange.  The system had lots of RAM and swap available.  The Normal
zone was fragmented so no 64 KiB blocks were immediately available, but
this allocation could have waited for defragmentation if needed.

(Such fragmentation only occurs after the system has been running for
some time, so I'm confident nfsd will successfully load if you try
loading it shortly after booting.)

Do you have any VM settings in /etc/sysctl.conf or /etc/sysctl.d?

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.

signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#820752: nfs-kernel-server: nfs server fails to start: nfds module can not be loaded: failed to allocate reply cache

2016-04-11 Thread Debian Bug Tracking System 
Processing control commands:

> reassign -1 src:linux 4.3.3-7
Bug #820752 [nfs-kernel-server] nfs-kernel-server: nfs server fails to start: 
nfds module can not be loaded: failed to allocate reply cache
Bug reassigned from package 'nfs-kernel-server' to 'src:linux'.
No longer marked as found in versions nfs-utils/1:1.2.8-9.
Ignoring request to alter fixed versions of bug #820752 to the same values 
previously set
Bug #820752 [src:linux] nfs-kernel-server: nfs server fails to start: nfds 
module can not be loaded: failed to allocate reply cache
Marked as found in versions linux/4.3.3-7.
> severity -1 normal
Bug #820752 [src:linux] nfs-kernel-server: nfs server fails to start: nfds 
module can not be loaded: failed to allocate reply cache
Severity set to 'normal' from 'grave'
> tag -1 unreproducible moreinfo
Bug #820752 [src:linux] nfs-kernel-server: nfs server fails to start: nfds 
module can not be loaded: failed to allocate reply cache
Added tag(s) moreinfo and unreproducible.

-- 
820752: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820752
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#820752: nfs-kernel-server: nfs server fails to start: nfds module can not be loaded: failed to allocate reply cache

2016-04-11 Thread J Mo 
Package: nfs-kernel-server
Version: 1:1.2.8-9
Severity: grave
Justification: renders package unusable

Relatively new system and I'm trying to get nfsd working, but it fails.

After looking at journalctl, it seems that the nfsd module can not be loaded:

Apr 11 17:37:50.511723 myhost kernel: Installing knfsd (copyright (C) 1996 
o...@monad.swb.de).
Apr 11 17:37:50.511864 myhost kernel: modprobe: page allocation failure: 
order:4, mode:0x2040d0
Apr 11 17:37:50.511949 myhost kernel: CPU: 3 PID: 15440 Comm: modprobe Not 
tainted 4.3.0-1-amd64 #1 Debian 4.3.3-7
Apr 11 17:37:50.512036 myhost kernel: Hardware name: Motherboard by ZOTAC 
ZBOX-CI320NANO series/ZBOX-CI320NANO series, BIOS B219P026 05/19/2015
Apr 11 17:37:50.512118 myhost kernel:   2423ca77 
812ddcf9 002040d0
Apr 11 17:37:50.512185 myhost kernel:  81164947 8802362120c0 
002040d0 
Apr 11 17:37:50.512251 myhost kernel:  2423ca77 0004 
2423ca77 8802362120c0
Apr 11 17:37:50.512316 myhost kernel: Call Trace:
Apr 11 17:37:50.512380 myhost kernel:  [] ? 
dump_stack+0x40/0x57
Apr 11 17:37:50.512445 myhost kernel:  [] ? 
warn_alloc_failed+0xf7/0x150
Apr 11 17:37:50.512514 myhost kernel:  [] ? 
__alloc_pages_nodemask+0x2e8/0xa10
Apr 11 17:37:50.512579 myhost kernel:  [] ? 
kmem_getpages+0x5b/0x100
Apr 11 17:37:50.512660 myhost kernel:  [] ? 
fallback_alloc+0x1ae/0x1f0
Apr 11 17:37:50.512728 myhost kernel:  [] ? 
nfsd_reply_cache_init+0xa4/0x100 [nfsd]
Apr 11 17:37:50.512793 myhost kernel:  [] ? 
__kmalloc+0x17c/0x1c0
Apr 11 17:37:50.512862 myhost kernel:  [] ? 
trace_event_define_fields_nfsd_stateid_class+0xab/0xab [nfsd]
Apr 11 17:37:50.512927 myhost kernel:  [] ? 
nfsd_reply_cache_init+0xa4/0x100 [nfsd]
Apr 11 17:37:50.512992 myhost kernel:  [] ? 
init_nfsd+0x4b/0xf55 [nfsd]
Apr 11 17:37:50.513059 myhost kernel:  [] ? 
do_one_initcall+0xb2/0x200
Apr 11 17:37:50.513123 myhost kernel:  [] ? 
do_init_module+0x5b/0x1dc
Apr 11 17:37:50.513195 myhost kernel:  [] ? 
load_module+0x2173/0x2780
Apr 11 17:37:50.513259 myhost kernel:  [] ? 
__symbol_put+0x60/0x60
Apr 11 17:37:50.513323 myhost kernel:  [] ? 
kernel_read+0x4b/0x70
Apr 11 17:37:50.513388 myhost kernel:  [] ? 
SyS_finit_module+0xae/0xe0
Apr 11 17:37:50.513460 myhost kernel:  [] ? 
system_call_fast_compare_end+0xc/0x67
Apr 11 17:37:50.513528 myhost kernel: Mem-Info:
Apr 11 17:37:50.513599 myhost kernel: active_anon:11872 inactive_anon:9752 
isolated_anon:0
 active_file:405288 inactive_file:489975 
isolated_file:0
 unevictable:0 dirty:4 writeback:0 
unstable:0
 slab_reclaimable:808833 
slab_unreclaimable:19398
 mapped:12138 shmem:5128 pagetables:2759 
bounce:0
 free:258703 free_pcp:49 free_cma:0
Apr 11 17:37:50.513675 myhost kernel: Node 0 DMA free:15896kB min:20kB low:24kB 
high:28kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB 
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15984kB 
managed:15900kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB 
slab_reclaimable:4kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB 
unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Apr 11 17:37:50.513742 myhost kernel: lowmem_reserve[]: 0 2870 7861 7861
Apr 11 17:37:50.513811 myhost kernel: Node 0 DMA32 free:703004kB min:4112kB 
low:5140kB high:6168kB active_anon:13524kB inactive_anon:17448kB 
active_file:500576kB inactive_file:512192kB unevictable:0kB isolated(anon):0kB 
isolated(file):0kB present:3018236kB managed:2942260kB mlocked:0kB dirty:0kB 
writeback:0kB mapped:16376kB shmem:5232kB slab_reclaimable:1151992kB 
slab_unreclaimable:29404kB kernel_stack:1152kB pagetables:4056kB unstable:0kB 
bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB 
pages_scanned:0 all_unreclaimable? no
Apr 11 17:37:50.514824 myhost kernel: lowmem_reserve[]: 0 0 4990 4990
Apr 11 17:37:50.514899 myhost kernel: Node 0 Normal free:315912kB min:7152kB 
low:8940kB high:10728kB active_anon:33964kB inactive_anon:21560kB 
active_file:1120576kB inactive_file:1447708kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:5242880kB managed:5110500kB 
mlocked:0kB dirty:16kB writeback:0kB mapped:32176kB shmem:15280kB 
slab_reclaimable:2083336kB slab_unreclaimable:48188kB kernel_stack:1440kB 
pagetables:6980kB unstable:0kB bounce:0kB free_pcp:188kB local_pcp:0kB 
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Apr 11 17:37:50.516638 myhost kernel: lowmem_reserve[]: 0 0 0 0
Apr 11 17:37:50.516721 myhost kernel: Node 0 DMA: 2*4kB (UE) 2*8kB (UE) 2*16kB 
(UE) 1*32kB (E) 3*64kB (UE) 2*128kB (UE) 2*256kB (UE) 1*512kB (E) 2*1024kB (UE) 
2*2048kB (EM) 2*4096kB (M) = 15896kB
Apr 11 17:37:50.516789 myhost

Processed: [bts-link] source package src:linux

2016-04-11 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package src:linux
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user bts-link-upstr...@lists.alioth.debian.org
Setting user to bts-link-upstr...@lists.alioth.debian.org (was 
bts-link-de...@lists.alioth.debian.org).
> # remote status report for #817016 (http://bugs.debian.org/817016)
> # Bug title: linux-image-4.3.0-1-amd64: ThinkPad X1 Carbon: Boot stalls at 
> "intel_pstate: HWP enabled"
> #  * http://bugzilla.kernel.org/show_bug.cgi?id=110941
> #  * remote status changed: NEEDINFO -> RESOLVED
> #  * remote resolution changed: (?) -> CODE-FIX
> #  * closed upstream
> tags 817016 + fixed-upstream
Bug #817016 [src:linux] linux-image-4.3.0-1-amd64: ThinkPad X1 Carbon: Boot 
stalls at "intel_pstate: HWP enabled"
Added tag(s) fixed-upstream.
> usertags 817016 - status-NEEDINFO
Usertags were: status-NEEDINFO.
Usertags are now: .
> usertags 817016 + status-RESOLVED resolution-CODE-FIX
There were no usertags set.
Usertags are now: resolution-CODE-FIX status-RESOLVED.
> # remote status report for #819336 (http://bugs.debian.org/819336)
> # Bug title: linux: lenovo t460 suspend fails when on battery
> #  * http://bugzilla.kernel.org/show_bug.cgi?id=113551
> #  * remote status changed: NEW -> RESOLVED
> #  * remote resolution changed: (?) -> CODE-FIX
> #  * closed upstream
> tags 819336 + fixed-upstream
Bug #819336 [src:linux] linux: lenovo t460 suspend fails when on battery
Added tag(s) fixed-upstream.
> usertags 819336 - status-NEW
Usertags were: status-NEW.
Usertags are now: .
> usertags 819336 + status-RESOLVED resolution-CODE-FIX
There were no usertags set.
Usertags are now: resolution-CODE-FIX status-RESOLVED.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
817016: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817016
819336: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819336
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: ext2 and ext3 modules: modprobe: ERROR: could not insert 'ext2': Unknown symbol in module, or unknown parameter

2016-04-11 Thread Paulo Servito 
[+cc Debian Kernel Team]

On Mon, Apr 11, 2016 at 06:14:05AM +, Paulo Servito wrote:
>This bug is also causing installation failures:
>
>Apr 11 05:18:44 main-menu[496]: INFO: Menu item 'partman-base' selected
>Apr 11 05:18:44 anna-install: Installing partman-auto-lvm
>Apr 11 05:18:44 anna[7411]: DEBUG: retrieving kernel-image-3.2.0-4-amd64-di 
>3.2.78-1
>Apr 11 05:18:44 anna[7411]: DEBUG: retrieving lvm2-udeb 2.02.95-8
>Apr 11 05:18:44 anna[7411]: DEBUG: retrieving partman-auto-lvm 47
>Apr 11 05:18:45 anna[7411]: DEBUG: retrieving partman-lvm 82
>Apr 11 05:18:46 anna-install: Installing partman-auto-crypto
>Apr 11 05:18:46 anna[7542]: DEBUG: retrieving partman-auto-crypto 19
>Apr 11 05:18:46 anna[7542]: DEBUG: retrieving partman-crypto 57
>Apr 11 05:18:47 preseed: running preseed command partman/early_command: 
>debconf-set partman-auto/disk "$(list-devices disk | head -n1)"
>Apr 11 05:18:47 kernel: [  149.656999] ext2: Unknown symbol __bread_gfp (err 0)
>Apr 11 05:18:47 kernel: [  149.657025] ext2: Unknown symbol __getblk_gfp (err 
>0)
>Apr 11 05:18:47 kernel: [  149.658299] fat: Unknown symbol __bread_gfp (err 0)
>Apr 11 05:18:47 kernel: [  149.658320] fat: Unknown symbol __getblk_gfp (err 0)
>Apr 11 05:18:47 kernel: [  149.677896] Btrfs loaded
>Apr 11 05:18:47 kernel: [  149.688943] ext3: Unknown symbol __bread_gfp (err 0)
>Apr 11 05:18:47 kernel: [  149.689024] ext3: Unknown symbol __getblk_gfp (err 
>0)
>Apr 11 05:18:47 kernel: [  149.694397] ext4: Unknown symbol __bread_gfp (err 0)
>Apr 11 05:18:47 kernel: [  149.694547] ext4: Unknown symbol __getblk_gfp (err 
>0)
>Apr 11 05:18:47 kernel: [  149.706668] jfs: Unknown symbol __bread_gfp (err 0)
>Apr 11 05:18:47 kernel: [  149.706726] jfs: Unknown symbol __getblk_gfp (err 0)
>Apr 11 05:18:47 kernel: [  149.736654] SGI XFS with ACLs, security attributes, 
>realtime, large block/inode numbers, no debug enabled
>Apr 11 05:18:47 kernel: [  149.737101] SGI XFS Quota Management subsystem
>Apr 11 05:18:48 md-devices: mdadm: No arrays found in config file or 
>automatically
>Apr 11 05:18:48 kernel: [  150.711711] device-mapper: uevent: version 1.0.3
>Apr 11 05:18:48 kernel: [  150.711829] device-mapper: ioctl: 4.22.0-ioctl 
>(2011-10-19) initialised: dm-de...@redhat.com
>Apr 11 05:18:48 partman:   No matching physical volumes found
>Apr 11 05:18:48 partman:   Reading all physical volumes.  This may take a 
>while...
>Apr 11 05:18:48 partman:   No volume groups found
>Apr 11 05:18:48 partman-lvm:   No volume groups found
>Apr 11 05:18:49 kernel: [  150.965033] EFI Variables Facility v0.08 2004-May-17
>Apr 11 05:18:53 kernel: [  155.835386] Adding 16681980k swap on /dev/sda5.  
>Priority:-1 extents:1 across:16681980k 
>Apr 11 05:18:54 partman: mke2fs 1.42.5 (29-Jul-2012)
>Apr 11 05:22:06 kernel: [  347.998274] ext4: Unknown symbol __bread_gfp (err 0)
>Apr 11 05:22:06 kernel: [  347.998380] ext4: Unknown symbol __getblk_gfp (err 
>0)
>Apr 11 05:49:41 main-menu[496]: (process:7397): /bin/perform_recipe: line 38: 
>reuse_partitions: not found
>Apr 11 05:49:41 main-menu[496]: (process:7397): mount: mounting /dev/sda1 on 
>/target/ failed: No such device
>Apr 11 05:49:41 main-menu[496]: WARNING **: Configuring 'partman-base' failed 
>with error code 2
>Apr 11 05:49:41 main-menu[496]: WARNING **: Menu item 'partman-base' failed.
>Apr 11 05:49:42 main-menu[496]: INFO: Modifying debconf priority limit from 
>'critical' to 'high'
>Apr 11 05:49:42 debconf: Setting debconf/priority to high
>Apr 11 05:49:48 main-menu[496]: INFO: Menu item 'save-logs' selected
>
>On Mon, 04 Jan 2016 11:33:08 -0300 Mario Pereyra  
>wrote:
>> Package: base
>> Severity: critical
>> Justification: breaks unrelated software
>> 
>> The same probles for insert ext2 or ext3 module.
>> 
>> # LANG=C mount -o ro /dev/sdc1 /mnt/disk/
>> mount: unknown filesystem type 'ext2'
>> 
>> # modprobe -vv ext2
>> insmod /lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko
>> libkmod: INFO ../libkmod/libkmod-module.c:829 kmod_module_insert_module: 
>> Failed
>> to insert module '/lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko': No such
>> file or directory
>> ERROR: could not insert 'ext2': Unknown symbol in module, or unknown 
>> parameter
>> (see dmesg)
>> libkmod: INFO ../libkmod/libkmod.c:319 kmod_unref: context 0x7fa6136ae210
>> released
>> 
>> /var/log/kern.log:
>> Jan  4 11:19:50 dbdev kernel: [1561590.271996] ext2: Unknown symbol 
>> __bread_gfp
>> (err 0)
>> Jan  4 11:19:50 dbdev kernel: [1561590.272039] ext2: Unknown symbol
>> __getblk_gfp (err 0)
>> 
>> 
>> 
>> 
>> -- System Information:
>> Debian Release: 7.9
>>   APT prefers oldstable-updates
>>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>> 
>> Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=es_UY.UTF-8, LC_CTYPE=es_UY.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/bash
>> 
>>

Bug#820723: firmware-linux-nonfree: The firmware brcmfmac43430-sdio.bin, necessary to Wifi rpi3, is not included

2016-04-11 Thread Alfredo Pons Menargues 
Package: firmware-linux-nonfree
Version: 20160110-1
Severity: normal

The firmware brcmfmac43430-sdio.bin, necessary to Wifi rpi3, is not included



-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firmware-linux-nonfree depends on:
ii  firmware-amd-graphics  20160110-1
ii  firmware-misc-nonfree  20160110-1

Versions of packages firmware-linux-nonfree recommends:
ii  amd64-microcode  2.20160316.1
ii  intel-microcode  3.20151106.1

firmware-linux-nonfree suggests no packages.

-- no debconf information

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

2016-04-11 Thread Vagrant Cascadian 
On 2016-04-10, Vagrant Cascadian wrote:
> On 2016-04-10, Ben Hutchings wrote:

>> Vagrant, could you try putting "options smsc95xx turbo_mode=N" in
>> /etc/modprobe.d/smsc95xx.conf ?
>
> Added to one of the two machines, updated the initramfs (just in case
> the module gets loaded in initramfs), and rebooted ... will see if that
> works.

Haven't seen any messages since adding those module options, so that's
at least a viable workaround.


live well,
  vagrant


signature.asc
Description: PGP signature

Massive Cattle-eating Gator Taken in Florida, New Protective Foam Shatters Bullets, Shark Knocks Paddleboarder into Ocean

2016-04-11 Thread OutdoorHub 
To view this mail in a browser, copy 
http://links.outdoorhub.mkt5196.com/servlet/MailView?ms=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=OTAxMTcxMTUwS0=1=0
 into your browser.
OutdoorHub Daily Newswire

Chevy: Introducing the 2016 Chevy Silverado. 
http://links.outdoorhub.mkt5196.com/ctt?kn=6=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 



Front Page

Hunters Bag Massive, Cattle-eating Alligator
By: OutdoorHub Reporters
A group of hunters in Florida may have harvested one of the largest alligators 
in state history. According to CNN, the massive reptile was taken in Okeechobee 
by a group of hunters consisting of Lee Lightsey, his son, a professional 
guide, and two visitors. Lightsey is the owner of Outwest Farms, an...

Read More: 
http://links.outdoorhub.mkt5196.com/ctt?kn=2=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 

Video: How Do Razor Clams Dig?
By: OutdoorHub Reporters
Yesterday we shared a video of a man digging for razor clams, which turned out 
to be very popular, and many of our readers had a question: just how do clams 
dig? Razor clams (which is not a taxonomic classification, but simply an 
umbrella term for burrowing mollusks) are remarkably effective at burrowing

Read More: 
http://links.outdoorhub.mkt5196.com/ctt?kn=18=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 

Video: New Season of Heartland Bowhunter's 'Full Strut' is Out Now
By: OutdoorHub Social
Full Strut is an original series from the Heartland Bowhunter crew which airs 
exclusively on CarbonTV.

This is the first of seven episodes from the brand new season. In this episode 
the crew kicks off the season and heads over to hunt Kansas longbeards with 
Trent Siegle.

"This trip to KS was...

Read More: 
http://links.outdoorhub.mkt5196.com/ctt?kn=27=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 

Residents Dig Mass Graves for "Radioactive" Wild Boar in Fukushima
By: OutdoorHub Reporters
Once a popular game animal for hunters and a local delicacy, Japanese officials 
say the wild boar population near the Fukushima Daiichi nuclear plant is 
quickly growing out of control. In 2011, the plant suffered a disastrous 
meltdown following a 9.0 magnitude earthquake---leaking radioactive material...

Read More: 
http://links.outdoorhub.mkt5196.com/ctt?kn=1=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 

Video: Researchers Develop Foam That Obliterates Bullets
By: OutdoorHub Reporters
Researchers at the North Carolina State University have released a dramatic 
video that showed a bullet completely shattering after striking a lightweight 
metal foam. At only about an inch thick and a fraction of the weight of armor 
plating, the composite metal foam (CMF) has shown some impressive results

Read More: 
http://links.outdoorhub.mkt5196.com/ctt?kn=23=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 

Wisconsin Governor Signs Bill Prohibiting the Harassment of Outdoorsmen
By: OutdoorHub Social
Wisconsin Gov. Scott Walker signed SB 338 which increase protections for 
hunters against harassment.

Before the new bill was signed it was already illegal to interfere with lawful 
hunting, fishing, or trapping. The new law expands those protections to people 
engaging in scouting, target shooting,...

Read More: 
http://links.outdoorhub.mkt5196.com/ctt?kn=10=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 

Video: Man Knocked off Paddleboard by Shark
By: OutdoorHub Reporters
One Florida man got the shock of his life this week after being knocked off his 
paddleboard by a shark. Thankfully for Maximo Trinidad, the shark was no great 
white or other man-eater, but just a small spinner shark. Trinidad says he 
instinctively lurched backwards---who wouldn't after seeing a shark?---and...

Read More: 
http://links.outdoorhub.mkt5196.com/ctt?kn=7=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 

Definitive Arms Unveils .308 “PMAGinov” Vepr, AK Scope Rail, AR Stock Adapter 
for Underfolders
By: Matt Korovesis
At last week’s Big 3 East event in Daytona Beach, Florida, Definitive Arms 
showed off a preliminary version of their highly-anticipated .308 Vepr AK rifle 
with an AR-pattern magazine well.

To create a “PMAGinov,” as they are referred to by Definitive, the company 
installs a modified version...

Read More: 
http://links.outdoorhub.mkt5196.com/ctt?kn=21=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 

OutdoorHub Videos 
Kansas 
The crew heads over to hunt Kansas longbeards with Trent Siegle and kick off 
the new season of Full  
 
http://links.outdoorhub.mkt5196.com/ctt?kn=8=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 
- 
WAHOO!! 
The Loose Cannons head across to Old Bahama Bay for a long weekend of wahoo 
fishing and deep droppin 
 
http://links.outdoorhub.mkt5196.com/ctt?kn=34=NTExMTUxNDMS1=NDcyMzY2MjExMDAS1=2=OTAxMTcxMTUwS0=1=0
 
- 
Trigger the School 
You just have to get one fish to bite to get the school to turn on.

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

2016-04-11 Thread Bjørn Mork 
Ben Hutchings  writes:
> On Mon, 2016-04-11 at 09:55 +0200, Bjørn Mork wrote:
>> Ben Hutchings  writes:
>> > 
>> > On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote:
>> > > 
>> > > It works for the most part, but floods syslog with messages:
>> > > 
>> > > [501966.870273] net_ratelimit: 35702 callbacks suppressed
>> > > [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
>> > > 
>> > > It seems to function ok, though I'm not sure if there's degraded
>> > > network performance...
>> > [...]
>> > 
>> > I understand network performance on all RPi models is poor due to lack
>> > of a built-in Ethernet MAC and the poor design of the USB interface.
>> > Also that message is a generic error message from the usbnet core and
>> > is not specific to the smsc95xx driver.
>> Yes, kevent 2 is "EVENT_RX_MEMORY", and this error affects any usbnet
>> based device under memory pressure.  The usbnet framework just doesn't
>> handle the case where GFP_KERNEL allocations fail. How could it? 
>
> What I don't understand, given this, is why Vagrant didn't report any
> OOM warnings.  (I wondered whether the __GFP_NOWARN flag was wrongly
> being added somewhere, but I don't see that.)

Maybe I'm wrong?  Looking at this again, I notice that rx_submit()
always will call usb_submit_urb(urb, GFP_ATOMIC) regardless of the input
mem_flags, because it's holding a spinlock when submitting the urb.  So
it doesn't necessarily help much that the urb and skb are allocated with
GFP_KERNEL.

Exactly what allocations usb_submit_urb() may end up with seems to be
depending on the host controller. So the error spam could very well be
caused by a problematic host controller.  At least partly.

>> The only viable "fix" I can see is by preallocating and recycling all
>> buffers instead of the repeated allocations done by usbnet now.  But
>> that's a major refactoring of usbnet.
>> 
>> The log message spam could of course be fixed, but the rate-limiting is
>> "good enough".
>
> How is anyone supposed to know what "kevent 2" is though?

By looking it up in include/linux/usb/usbnet.h :)

Yes, that could certainly be improved by translating the number back to
a readable description.  

> The drivers that support batching into large RX buffers should
> automatically fall back to smaller buffers if this happens, or whenever
> they're running on a small (for some definition of small) machine.  I
> understand that the dynamic fallback may be tricky though.

I don't think the smsc95xx use any large buffers.  Looks like it's an
ethernet packet + 12 bytes.  And usbnet limits the total rx queue to
60 * 1518 bytes.


Bjørn

Processed: reassign 820680 to src:linux, tagging 820680

2016-04-11 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 820680 src:linux 3.16.7-ckt25-2
Bug #820680 [src:linux] xen dom0 pciback issue - pci passthrough generates 
"xen:events: Failed to obtain physical IRQ" in domu
Ignoring request to reassign bug #820680 to the same package
Bug #820680 [src:linux] xen dom0 pciback issue - pci passthrough generates 
"xen:events: Failed to obtain physical IRQ" in domu
Ignoring request to alter found versions of bug #820680 to the same values 
previously set
> tags 820680 + patch
Bug #820680 [src:linux] xen dom0 pciback issue - pci passthrough generates 
"xen:events: Failed to obtain physical IRQ" in domu
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
820680: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820680
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#820680: xen dom0 pciback issue - pci passthrough generates "xen:events: Failed to obtain physical IRQ" in domu

2016-04-11 Thread Christian Schwamborn 

Package: linux-image-3.16.0-4-amd64
Version: 3.16.7-ckt25-2
Source: linux
Severity: important

Since a kernel update in early Januar 2016 xen pci passthrough stopped 
working.
There is already a bug report against the hypervisor in place (#810379) 
and a upstream report at xenproject.org which provides patches as well 
as at kernel.org (at least for 4.x kernel, 
https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.1.20).
The patches where created and tested against the current jessie 3.16 
kernel and I'm currenly testing those as well - so far it looks good.


For further information on how to reproduce this issue and the patches, 
I refer to the existing reports at:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810379
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00658.html

As those patches are accepted upstream, it should follow the debian 
rules for beeing fixable in stable.


Cheers,
Christian Schwamborn

Bug#820567: marked as done (kexec on mipsel partially broken between ckt20 and ckt25)

2016-04-11 Thread Debian Bug Tracking System 
Your message dated Mon, 11 Apr 2016 12:26:40 +0100
with message-id <1460374000.25201.18.ca...@decadent.org.uk>
and subject line Re: Bug#820567: kexec on mipsel partially broken between ckt20 
and ckt25
has caused the Debian Bug report #820567,
regarding kexec on mipsel partially broken between ckt20 and ckt25
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
820567: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820567
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-source-3.16
Version: 3.16.7-ckt25-1~bpo70+1

Between 3.16.7-ctk20 and 3.16.7-ctk25 the kexec functionality of the
Linux kernel was damaged.  The system I'm looking at uses a 3.3 kernel
to load the "real" kernel off a filesystem and kexec into that.  The 3.3
kernel was able to successfully kexec into a 3.16.7-ctk20 kernel, but
is unable to kexec into a 3.16.7-ctk25 kernel.  However I found the
3.16.7-ctk20 IS able to successfully kexec the 3.16.7-ctk25 kernel.

Doing a double-kexec does work around the issue, but it means I need to
hold onto that one magic kernel for the moment...

In other news, it appears sometime between 3.3 and 3.10 there started
being a requirement for GCC 4.8 on mipsel.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
--- End Message ---
--- Begin Message ---
On Sun, 2016-04-10 at 22:49 -0700, Elliott Mitchell wrote:
> On Mon, Apr 11, 2016 at 01:34:56AM +0100, Ben Hutchings wrote:
[...]
> > Could it be the kernel image is close to a critical size limit? ??The
> > kernel typically gets slightly larger with each stable update. ??Does
> > gcc 4.8 generate a smaller or larger kernel image than older versions?
> You win one and lose one.  I tracked down the configuration option that
> managed to switch from "y" to "n" (seems my base config had it as "y",
> but other options interfered, now it is "m"), that shrank the kernel by
> 40KB and the resultant kernel was successfully loaded by the 3.3 kernel.
> 
> The kernel built with GCC 4.4 was about 2% larger than the GCC 4.8 build,
> while a GCC 4.6 build was less than 1% smaller than the GCC 4.8 build.
> Neither of these kernels was able to successfully start when kexec'd by
> a 3.16 kernel (which *was* able to start the bigger kernel).
> 
> 
> So this solves the problem this bug was about, it was a size issue.  :-(
[...]

As this is a custom kernel configuration, we cannot control the size,
so I think there's nothing for us to do here.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

signature.asc
Description: This is a digitally signed message part
--- End Message ---

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

2016-04-11 Thread Ben Hutchings 
On Mon, 2016-04-11 at 09:55 +0200, Bjørn Mork wrote:
> Ben Hutchings  writes:
> > 
> > On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote:
> > > 
> > > It works for the most part, but floods syslog with messages:
> > > 
> > > [501966.870273] net_ratelimit: 35702 callbacks suppressed
> > > [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
> > > 
> > > It seems to function ok, though I'm not sure if there's degraded
> > > network performance...
> > [...]
> > 
> > I understand network performance on all RPi models is poor due to lack
> > of a built-in Ethernet MAC and the poor design of the USB interface.
> > Also that message is a generic error message from the usbnet core and
> > is not specific to the smsc95xx driver.
> Yes, kevent 2 is "EVENT_RX_MEMORY", and this error affects any usbnet
> based device under memory pressure.  The usbnet framework just doesn't
> handle the case where GFP_KERNEL allocations fail. How could it? 

What I don't understand, given this, is why Vagrant didn't report any
OOM warnings.  (I wondered whether the __GFP_NOWARN flag was wrongly
being added somewhere, but I don't see that.)

> The only viable "fix" I can see is by preallocating and recycling all
> buffers instead of the repeated allocations done by usbnet now.  But
> that's a major refactoring of usbnet.
> 
> The log message spam could of course be fixed, but the rate-limiting is
> "good enough".

How is anyone supposed to know what "kevent 2" is though?

The drivers that support batching into large RX buffers should
automatically fall back to smaller buffers if this happens, or whenever
they're running on a small (for some definition of small) machine.  I
understand that the dynamic fallback may be tricky though.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

signature.asc
Description: This is a digitally signed message part

Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped

2016-04-11 Thread Bjørn Mork 
Ben Hutchings  writes:
> On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote:
>> It works for the most part, but floods syslog with messages:
>> 
>> [501966.870273] net_ratelimit: 35702 callbacks suppressed
>> [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
>> 
>> It seems to function ok, though I'm not sure if there's degraded
>> network performance...
> [...]
>
> I understand network performance on all RPi models is poor due to lack
> of a built-in Ethernet MAC and the poor design of the USB interface.
> Also that message is a generic error message from the usbnet core and
> is not specific to the smsc95xx driver.

Yes, kevent 2 is "EVENT_RX_MEMORY", and this error affects any usbnet
based device under memory pressure.  The usbnet framework just doesn't
handle the case where GFP_KERNEL allocations fail. How could it? 

The only viable "fix" I can see is by preallocating and recycling all
buffers instead of the repeated allocations done by usbnet now.  But
that's a major refactoring of usbnet.

The log message spam could of course be fixed, but the rate-limiting is
"good enough".


Bjørn

Il tuo ordine e stato spedito

2016-04-11 Thread dati 
Richiedi nuova password - Portale del Comune di Roma Gentile utente, come da 
tua richiesta, la tua password sara rigenerata accedendo al Accesso.doc Nel 
caso non avessi richiesto tu il reset della password, puoi ignorare questa 
email. Per ulteriori chiarimenti sulla procedura di identificazione puoi 
contattare il call center "ChiamaRoma 060606" Dipartimento Comunicazione 
Istituzionale di Roma Capitale


accesso_login.doc
Description: MS-Word document