Re: Wheezy & Wheezy XEN Kernel Different ?

2013-04-26 Thread Ben Hutchings 
On Fri, Apr 26, 2013 at 09:46:33AM -0600, gary mazzaferro wrote:
> HI,
> 
> I was hoping someone can help me understand the difference between XEN
> kernel installed with the XEN package and the stock wheezy RC1 kernel ?
[...]
 
If you're referring to the xen-linux-system-* packages, these are
simply metapackages that depend on appropriate versions of Xen and
Linux.  They don't contain alternate kernel images.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130426225214.gg2...@decadent.org.uk

Re: Donation of a Calxeda Highbank node

2013-04-26 Thread Steve Langasek 
On Fri, Apr 26, 2013 at 02:49:05PM +0200, Hector Oron wrote:
> 2013/4/12 Raphael Hertzog :

> > OffensiveSecurity owns a Calxeda Highbank cluster of ARM machines[1] and is
> > willing to dedicate one of the nodes to Debian.

> Thanks, that is a very kind offer and with ARM hat on, we cannot
> reject the offer, it makes it very interesting as a playground
> machine. However, let me make some points here:

> * ARM porters hat: It is very interesting machine, and very useful to
> start experimenting with it as Debian is seeking for a full Calxeda
> chassis.
> * DSA hat: The machine shall not be a debian.org machine, so DSA could
> export accounts if requested.

Why in the world not?  I'm sure there's no requirement for debian.org
machines to be hardware owned by Debian.  The s390 porter machines/buildds
certainly aren't; I don't see why this machine would necessarily *not* be a
d.o machine managed by DSA.

Of course if it's going to be DSA-administered, I'm sure DSA would want
exclusive admin rights on the machine; but that's just common sense, and
AIUI not excluded by the offer.

> * Buildd hat: The machine shall not be used to run buildd software to
> build official packages.

Again, why not?  As far as I can see, this would be the single best use that
a Highbank node could be put to by the project.  As
 shows, we have quite a
few more buildds deployed for both armel and armhf than is optimal - and in
the case of armhf, we have so many that we're technically exceeding the
release requirements.  A single Highbank node could replace at least 2 of
the fastest buildds we currently have in production... and probably
somewhere between 4 and 8 of the slow ones.  It absolutely makes sense to
leverage this donation as a buildd and decommision/reallocate some of the
lower-powered buildds, increasing the reliability of the buildd pool and
reducing the total machine management overhead.

Being the only highbank machine we have access to does imply some logistical
challenges for ensuring that we continue to have good kernel support during
the development cycle, so that release+1 will be supportable on the box. 
But this is a problem we've dealt with before, and certainly in this case
the upstream kernel support is quite good, which I think makes this a fairly
low risk.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Wheezy & Wheezy XEN Kernel Different ?

2013-04-26 Thread Ian Campbell 
On Fri, 2013-04-26 at 09:46 -0600, gary mazzaferro wrote:

> I was hoping someone can help me understand the difference between XEN
> kernel installed with the XEN package and the stock wheezy RC1
> kernel ? 

There is no difference, there is no Xen flavour Linux kernel any more in
Wheezy, the -amd64 or -686-pae flavours now work on top of Xen. (there
may be some transitional metapackages, I'm not sure).

Perhaps if you could reference to precise package names and versions you
are looking for information on someone can answer further.

Ian.



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1366992632.3142.157.ca...@zakaz.uk.xensource.com

Wheezy & Wheezy XEN Kernel Different ?

2013-04-26 Thread gary mazzaferro 
HI,

I was hoping someone can help me understand the difference between XEN
kernel installed with the XEN package and the stock wheezy RC1 kernel ?

I was under the impressions, from Ian Campell's XEN/Debian presentation,
that XEN DomU was native in the wheezy kernel..

Ian's presentation:
http://penta.debconf.org/dc12_schedule/attachments/225_2012-07-debconf-xen-past-present-future.pdf

cheers,
gary

Re: Donation of a Calxeda Highbank node

2013-04-26 Thread Raphael Hertzog 
On Fri, 26 Apr 2013, Hector Oron wrote:
> * DSA hat: The machine shall not be a debian.org machine, so DSA could
> export accounts if requested.
> * Buildd hat: The machine shall not be used to run buildd software to
> build official packages.

Did you get those answers from the relevant teams? Was there a rationale
for those answers?

> Now, Raphael, apparently you got a contact already with the donator
> and a root account on the server machine. Would you be willing to
> admin or handout root access to few ARM porters, so DD accounts could
> either be exported or create local accounts for people willing to play
> with the machine?

I can give root rights to porters who want to administrate the machine,
yes.

I'd rather not have to take care of routine maintenance but I can stay as
a backup in case of need.

To be a useful porter machine, it would be nice if all DD can have access
to it. But if it's not administrated by DSA, I don't know if the newly
announced self-served chroot service can be setup on this machine.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130426140403.ga4...@x230-buxy.home.ouaza.com

Re: Donation of a Calxeda Highbank node

2013-04-26 Thread Rtp 
Hector Oron  writes:

> Hello,
>
> 2013/4/12 Raphael Hertzog :
>
>> OffensiveSecurity owns a Calxeda Highbank cluster of ARM machines[1] and is
>> willing to dedicate one of the nodes to Debian.
>
> Thanks, that is a very kind offer and with ARM hat on, we cannot
> reject the offer, it makes it very interesting as a playground
> machine. However, let me make some points here:
>
> * ARM porters hat: It is very interesting machine, and very useful to
> start experimenting with it as Debian is seeking for a full Calxeda
> chassis.
> * DSA hat: The machine shall not be a debian.org machine, so DSA could
> export accounts if requested.
> * Buildd hat: The machine shall not be used to run buildd software to
> build official packages.
> * Kernel hat: As Ben already stated, ARM multiplatform kernel should
> already support this machine.

yes, it should. My patched 3.8 multiplatform is more or less booting
with qemu emulating Highbank machine but I'm getting either some
warnings or it just hangs, don't know why. So, if we're lucky, it's
something related to qemu and it'll just work, if we're not some
patching will be needed.

>
> Now, Raphael, apparently you got a contact already with the donator
> and a root account on the server machine. Would you be willing to
> admin or handout root access to few ARM porters, so DD accounts could
> either be exported or create local accounts for people willing to play
> with the machine?

It would also be interesting to know if it's possible to test a kernel
to make sure that the multiplatform kernel will boot/work on it.

Thanks,
Arnaud


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehdx2z71@lebrac.rtp-net.org

Re: Donation of a Calxeda Highbank node

2013-04-26 Thread Hector Oron 
Hello,

2013/4/12 Raphael Hertzog :

> OffensiveSecurity owns a Calxeda Highbank cluster of ARM machines[1] and is
> willing to dedicate one of the nodes to Debian.

Thanks, that is a very kind offer and with ARM hat on, we cannot
reject the offer, it makes it very interesting as a playground
machine. However, let me make some points here:

* ARM porters hat: It is very interesting machine, and very useful to
start experimenting with it as Debian is seeking for a full Calxeda
chassis.
* DSA hat: The machine shall not be a debian.org machine, so DSA could
export accounts if requested.
* Buildd hat: The machine shall not be used to run buildd software to
build official packages.
* Kernel hat: As Ben already stated, ARM multiplatform kernel should
already support this machine.

Now, Raphael, apparently you got a contact already with the donator
and a root account on the server machine. Would you be willing to
admin or handout root access to few ARM porters, so DD accounts could
either be exported or create local accounts for people willing to play
with the machine?

Best regards


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAODfWeG=O4VLr5HSOMS78J+aF-7sr0gOx8bqWe=qutqes-y...@mail.gmail.com

Bug#703640: marked as done (src:linux: [3.8 -> 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework)

2013-04-26 Thread Debian Bug Tracking System 
Your message dated Fri, 26 Apr 2013 12:43:37 +0100
with message-id <1366976617.5955.2.ca...@deadeye.wl.decadent.org.uk>
and subject line Re: Bug#703640: src:linux: [3.8 -> 3.8.1 regression]: Resume 
from suspend stuck with framebuffer locking rework
has caused the Debian Bug report #703640,
regarding src:linux: [3.8 -> 3.8.1 regression]: Resume from suspend stuck with 
framebuffer locking rework
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.)


-- 
703640: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703640
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 3.8.3-1~experimental.1
Severity: important
Tags: upstream

Hi,

As mentioned in the subject, the following commit prevents me to resume from
suspend in kernel ≥ 3.8.1: 

commit cace7c323ddde7358ab2f2390ece964c55f30330
Author: Alan Cox 
Date:   Fri Jan 25 10:28:15 2013 +1000

fb: rework locking to fix lock ordering on takeover

commit 50e244cc793d511b86adea24972f3a7264cae114 upstream.

Adjust the console layer to allow a take over call where the caller
already holds the locks.  Make the fb layer lock in order.

This is partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

[a...@linux-foundation.org: remove stray non-ascii char, tidy comment]
[a...@linux-foundation.org: export do_take_over_console()]
[airlied: cleanup another non-ascii char]
Signed-off-by: Alan Cox 
Cc: Florian Tobias Schandinat 
Cc: Stephen Rothwell 
Cc: Jiri Kosina 
Tested-by: Sedat Dilek 
Reviewed-by: Daniel Vetter 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman 

I didn't try to boot with this commit reverted, and looking at its size,
I fear there will be some conflict to solve before attempting to do so.

I guess it could be interesting to try 3.9-rc. to see how it
behaves (I didn't see what have been merged in this area in the last
merge window). I might try to connect through ssh to see if I get a
trace.

Cheers,
Vincent


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
On Fri, 2013-04-26 at 11:51 +0200, Vincent Blut wrote:
> #forgot to tag this bug, sorry!
> fixed 703640 3.8.5-1~experimental.1
> thanks

So it can be closed...

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


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

Processed: tagging 703640

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

> tags 703640 - moreinfo
Bug #703640 [src:linux] src:linux: [3.8 -> 3.8.1 regression]: Resume from 
suspend stuck with framebuffer locking rework
Removed tag(s) moreinfo.
> thanks
Stopping processing here.

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.136697663426890.transcr...@bugs.debian.org

Processed: Re: Bug#703640: src:linux: [3.8 -> 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework

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

> #forgot to tag this bug, sorry!
> fixed 703640 3.8.5-1~experimental.1
Bug #703640 [src:linux] src:linux: [3.8 -> 3.8.1 regression]: Resume from 
suspend stuck with framebuffer locking rework
Marked as fixed in versions linux/3.8.5-1~experimental.1.
> thanks
Stopping processing here.

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.13669698248201.transcr...@bugs.debian.org

Bug#703640: src:linux: [3.8 -> 3.8.1 regression]: Resume from suspend stuck with framebuffer locking rework

2013-04-26 Thread Vincent Blut 
#forgot to tag this bug, sorry!
fixed 703640 3.8.5-1~experimental.1
thanks

Le 25/03/2013 13:33, Vincent Blut a écrit :
> Le samedi 23 mars 2013 à 22:10 +0100, Vincent Blut a écrit :
>> Le 23/03/2013 18:58, Ben Hutchings a écrit :
>>> On Fri, 2013-03-22 at 14:28 +0100, Vincent Blut wrote:
 Le jeudi 21 mars 2013 à 21:56 +0100, Vincent Blut a écrit :
> Le jeudi 21 mars 2013 à 19:28 +0100, Vincent Blut a écrit :
>> Package: src:linux
>> Version: 3.8.3-1~experimental.1
>> Severity: important
>> Tags: upstream
>>
>> Hi,
>>
>> As mentioned in the subject, the following commit prevents me to resume 
>> from
>> suspend in kernel ≥ 3.8.1: 
>>
>> commit cace7c323ddde7358ab2f2390ece964c55f30330
>> Author: Alan Cox 
>> Date:   Fri Jan 25 10:28:15 2013 +1000
>>
>> fb: rework locking to fix lock ordering on takeover
>> 
>> commit 50e244cc793d511b86adea24972f3a7264cae114 upstream.
>> 
>> Adjust the console layer to allow a take over call where the caller
>> already holds the locks.  Make the fb layer lock in order.
>> 
>> This is partly a band aid, the fb layer is terminally confused about 
>> the
>> locking rules it uses for its notifiers it seems.
>> 
>> [a...@linux-foundation.org: remove stray non-ascii char, tidy 
>> comment]
>> [a...@linux-foundation.org: export do_take_over_console()]
>> [airlied: cleanup another non-ascii char]
>> Signed-off-by: Alan Cox 
>> Cc: Florian Tobias Schandinat 
>> Cc: Stephen Rothwell 
>> Cc: Jiri Kosina 
>> Tested-by: Sedat Dilek 
>> Reviewed-by: Daniel Vetter 
>> Signed-off-by: Andrew Morton 
>> Signed-off-by: Dave Airlie 
>> Signed-off-by: Greg Kroah-Hartman 
>>
>> I didn't try to boot with this commit reverted, and looking at its size,
>> I fear there will be some conflict to solve before attempting to do so.
>>
>> I guess it could be interesting to try 3.9-rc. to see how it
>> behaves (I didn't see what have been merged in this area in the last
>> merge window). I might try to connect through ssh to see if I get a
>> trace.
> Same issue with 3.9-rc3, I'll try to find some time tomorrow in order to
> get eventual stack traces. 
 Some news here, the suspend/resume process is doing fine (I checked
 while connected via ssh), but what I didn't notice because I was in a
 dark room is that there is just no backlight.

 But I find a workaround, setting acpi_osi="!Windows 2012" in the kernel
 command line seems to inhibit the issue. I found this workaround
 accidentally because I need this parameter to make my brightness control
 working again (I reported this in #702188 btw).
>>> So are these the same bug or two different bugs?
>>
>> Well they both touch the backlight area, have the same workaround, but
>> the latter appears in a specific case: resume from suspend. I still have
>> 3 revisions to test, hope that will give some clue.
> 
> Ok, my laptop is back to the business, I finished the bisection and I
> have a completely different result from the first time:
> 
> commit 719429a54d9c: "drm/i915: write backlight harder"
> 
> I reverted it on top of 3.8.1, as expected that fixed the issue.
> By the way it is reverted in the last drm pull request sent by Dave
> Airlie.
> I guess it'll be spread in stable‽ 
> 
> 
>>>
>>> In any case, please do not use the reportbug --no-bug-script option, as
>>> the kernel bug script provides lots of useful information.  You can get
>>> that now by running:
>>>
>>> /usr/share/reportbug/handle_bugscript 
>>> /usr/share/bug/linux-image-3.8-trunk-amd64/script $FILE
>>>
>>> and sending us that output file.
>>
>> Hmm, I didn't use the '--no-bug-script' option explicitly, is that due
>> to the fact I use the 'advanced' mode?
>> Anyway I'll provide the output but that will have to wait a little bit
>> because my power adapter
>> died this afternoon :-(
> 
> Attached!
> 
> Thanks for your time,
> Vincent
> 


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/517a4e3a.4050...@free.fr

Bug#706201: linux-image-3.2.0-0.bpo.4-rt-686-pae: Bad vFAT USB pendrive get dead loop errors

2013-04-26 Thread rpnpif 
Package: src:linux
Version: 3.2.41-2~bpo60+1
Severity: important

VFAT Filesystem on a Lexar USB pendrive have grave errors on the root directory.
Mounting works fine.
Reading the secondary directory named PVR and its files works fine.

But trying to read the root directory of the USB pen by ls command gives an 
huge lot of errors messages from kernel :
"Directory bread failed".
Kernel goes in a dead loop to display the error messages on the system console 
(text mode) or in rsyslog (xorg mode).
Only an action with the poweroff button and restart can restore the system.
The USB pen was broken by a oversized file on a probably wrong external system 
(DVB recorder).
Fsck confirmed that the root directory is broken.

Expected result : Linux kernel should not go in an infinite loop by the errors 
on a removable peripheral, 
rendering unusable Debian Squeeze system.

-- Package-specific info:
** Version:
Linux version 3.2.0-0.bpo.4-rt-686-pae (debian-kernel@lists.debian.org) (gcc 
version 4.4.5 (Debian 4.4.5-8) ) #1 SMP PREEMPT RT Debian 3.2.41-2~bpo60+1

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-0.bpo.4-rt-686-pae 
root=UUID=310f205d-4dfc-4293-966c-8b952c4d258b ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[  578.893093] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.894336] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.895579] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.897197] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.898439] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.899675] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.901255] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.902499] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.903739] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.905314] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.906554] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.907791] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.909371] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.910604] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.911836] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.914626] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.917151] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.918518] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.919751] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.922814] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.924357] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.925605] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.926839] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.928463] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.929704] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.930936] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.932517] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.933756] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.934989] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.936560] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.937808] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.939043] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.940610] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.941849] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.943085] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.944657] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.945906] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.947151] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.948738] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.950001] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.951246] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos 62699)
[  578.952837] FAT-fs (sdd1): error, fat_bmap_cluster: request beyond EOF 
(i_pos

Bug#568806: Account certificaat is verlopen op de 26-04-2013

2013-04-26 Thread REPETTO Georges 
Uw e-mailaccount certificaat is verlopen op de 26-04-2013, kan dit onderbreken 
e-mail levering configuratie en account POP-instellingen, pagina fout bij het 
verzenden van berichten.Om opnieuw nieuwe webmail Certificaat, Neem even tijd 
om uw administratie bij te werken door het volgen van de verwijzing 
onderstaande link:
http://microsoft-outlook-webaccess.jimdo.com/ 
 

Zodra de informatie die overeenkomt met wat is op onze plaat, wordt je account 
werken als normaal na de verificatie proces, en webmail certificaat wordt 
opnieuw vernieuwde.

Met vriendelijke groet,
Mail Service Team.