date:20130723

Processing commands for cont...@bugs.debian.org:

 reassign 717645 nvidia-kernel-dkms
Bug #717645 [src:linux] linux-image-3.10-1-amd64: I cannot compile the NVIDIA 
display driver from its source.
Bug reassigned from package 'src:linux' to 'nvidia-kernel-dkms'.
No longer marked as found in versions linux/3.10.1-1.
Ignoring request to alter fixed versions of bug #717645 to the same values 
previously set
 forcemerge 717361 717645
Bug #717361 {Done: Andreas Beckmann a...@debian.org} [nvidia-kernel-dkms] 
linux-image-3.10-1-amd64: nvidia module doesn't build on 3.10
Bug #717645 [nvidia-kernel-dkms] linux-image-3.10-1-amd64: I cannot compile the 
NVIDIA display driver from its source.
Severity set to 'grave' from 'important'
Marked Bug as done
Marked as fixed in versions nvidia-graphics-drivers/304.88-6.
Marked as found in versions nvidia-graphics-drivers/304.88-5.
Added tag(s) upstream, sid, and jessie.
Merged 717361 717645
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
717361: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717361
717645: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717645
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.137458981422417.transcr...@bugs.debian.org

Bug#516785: Bug #516785: linux-image-2.6.26-1-sparc64-smp: [sparc] SunFire480R cassini network driver kernel panic

2013-07-23 Thread Hermann Lauer

On Tue, Jul 09, 2013 at 05:42:20PM +0200, Moritz Muehlenhoff wrote:
  No, a second machine of the same type is available now for testing - and 
  also crashing after
  loading of the cassini driver. Here lspci and cpuinfo:
...
  0002:00:02.0 Ethernet controller: Oracle Corporation Cassini 10/100/1000 
  (rev 11)
  0003:00:01.0 Ethernet controller: Oracle Corporation Cassini 10/100/1000 
  (rev 11)
...
 Does this work with the wheezy release or later kernels?

Nope, tried 3.10.0 today - network worked for a short time, then a
Hardware FATAL RESET occured. Last suspicion was a chip issue with rev 11 
cassini - there is one working report with rev 20 chips only.

For the records: this was a 4 CPU 480R. As usual console output
is saved and could be provided, any other ideas are welcome.

Thanks,
 Hermann

-- 
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: hermann.la...@iwr.uni-heidelberg.de


-- 
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/20130723151912.ge1...@lemon.iwr.uni-heidelberg.de

Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot

2013-07-23 Thread Borislav Petkov

On Mon, Jul 22, 2013 at 08:19:26PM +0100, Roger Leigh wrote:
 Ben's patch does allow me to boot the system with the memory in this
 configuration on a 3.10 kernel.

Ok, I actually think we can fix it the way below. It should be
equivalent to Ben's patch in current functionality with the difference
that it is a bit simpler and keeps the special handling for K8 which I
want to have there as a future info.

In addition, it still provides for the data structures to be initialized
so some day, when memory hotplug is supported, it should work out of the
box when all of a sudden a second channel appears.

I think it should apply cleanly to 3.8 or 3.9 too as we haven't had a
whole lot of movement in that area :-)

Thanks.

---
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 8b6a0343c220..52f2da1a89a9 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2470,8 +2470,15 @@ static int amd64_init_one_instance(struct pci_dev *F2)
layers[0].size = pvt-csels[0].b_cnt;
layers[0].is_virt_csrow = true;
layers[1].type = EDAC_MC_LAYER_CHANNEL;
-   layers[1].size = pvt-channel_count;
+
+   /*
+* Always allocate two channels since we can have setups with DIMMs on
+* only one channel. Also, this simplifies handling later for the price
+* of a couple of KBs tops.
+*/
+   layers[1].size = 2;
layers[1].is_virt_csrow = false;
+
mci = edac_mc_alloc(nid, ARRAY_SIZE(layers), layers, 0);
if (!mci)
goto err_siblings;
--

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


-- 
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/20130723160557.gg8...@pd.tnic

Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs

2013-07-23 Thread Michael Prokop

[Cc-ing everyone who was involved in discussing #652459]

* Roger Leigh [Sun May 12, 2013 at 06:53:11PM +0100]:

 And one final patch to use panic rather than sulogin on fsck failure.

Thanks for all your patches, I've applied them on top of current
master (and edited debian/changelog on my own, being based on your
patches). The result is currently sitting in branch mika/bug_652459
of initramfs-tools.git.

Does anyone have any objections against the current implementation
of #652459 to support mounting of /usr in the initramfs?
If so, which objections do you have and what needs to be done to
resolve this issue so all involved parties are happy?

If there aren't any objections against the current implementation,
are there any objections against uploading the current state to
experimental?

If someone wants to test Roger's implementation, my CI environment
provides a Debian package of it:

  
http://jenkins.grml.org/job/initramfs-tools-binaries/26/architecture=amd64/artifact/initramfs-tools_0.114~20130723074828.38_all.deb
  [md5sum: 7bbd3f70f6483d8506429fa9ace32a0d]

regards,
-mika-


signature.asc
Description: Digital signature

Bug#717590: [Fwd: Patch drm/nv50-/disp: Use output specific mask in interrupt has been added to the 3.10-stable tree]

2013-07-23 Thread Yves-Alexis Perez

For information

 Forwarded Message 
From: gre...@linuxfoundation.org
To: emil.l.veli...@gmail.com, bske...@redhat.com, cor...@debian.org,
gre...@linuxfoundation.org
Cc: sta...@vger.kernel.org, stable-comm...@vger.kernel.org
Subject: Patch drm/nv50-/disp: Use output specific mask in interrupt
has been added to the 3.10-stable tree
Date: Tue, 23 Jul 2013 10:06:43 -0700
X-spam-status: No, score=-1.9 tagged_above=- required=0.5
tests=[BAYES_00=-1.9] autolearn=ham

This is a note to let you know that I've just added the patch titled

drm/nv50-/disp: Use output specific mask in interrupt

to the 3.10-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 drm-nv50-disp-use-output-specific-mask-in-interrupt.patch
and it can be found in the queue-3.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let sta...@vger.kernel.org know about it.


From 378f2bcdf7c971453d11580936dc0ffe845f5880 Mon Sep 17 00:00:00 2001
From: Emil Velikov emil.l.veli...@gmail.com
Date: Tue, 2 Jul 2013 14:44:12 +0100
Subject: drm/nv50-/disp: Use output specific mask in interrupt

From: Emil Velikov emil.l.veli...@gmail.com

commit 378f2bcdf7c971453d11580936dc0ffe845f5880 upstream.

The commit

   commit 476e84e126171d809f9c0b5d97137f5055f95ca8
   Author: Ben Skeggs bske...@redhat.com
   Date:   Mon Feb 11 09:24:23 2013 +1000

   drm/nv50-/disp: initial supervisor support for off-chip encoders

changed the write mask in one of the interrupt functions for on-chip encoders,
causing a regression in certain VGA dual-head setups. This commit reintroduces
the mask thus resolving the regression

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66129
Reported-and-Tested-by: Yves-Alexis cor...@debian.org
CC: Ben Skeggs bske...@redhat.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
Signed-off-by: Ben Skeggs bske...@redhat.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

---
 drivers/gpu/drm/nouveau/core/engine/disp/nv50.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
@@ -1107,6 +1107,7 @@ nv50_disp_intr_unk20_2(struct nv50_disp_
u32 pclk = nv_rd32(priv, 0x610ad0 + (head * 0x540))  0x3f;
u32 hval, hreg = 0x614200 + (head * 0x800);
u32 oval, oreg;
+   u32 mask;
u32 conf = exec_clkcmp(priv, head, 0xff, pclk, outp);
if (conf != ~0) {
if (outp.location == 0  outp.type == DCB_OUTPUT_DP) {
@@ -1133,6 +1134,7 @@ nv50_disp_intr_unk20_2(struct nv50_disp_
oreg = 0x614280 + (ffs(outp.or) - 1) * 0x800;
oval = 0x;
hval = 0x;
+   mask = 0x;
} else
if (!outp.location) {
if (outp.type == DCB_OUTPUT_DP)
@@ -1140,14 +1142,16 @@ nv50_disp_intr_unk20_2(struct nv50_disp_
oreg = 0x614300 + (ffs(outp.or) - 1) * 0x800;
oval = (conf  0x0100) ? 0x0101 : 0x;
hval = 0x;
+   mask = 0x0707;
} else {
oreg = 0x614380 + (ffs(outp.or) - 1) * 0x800;
oval = 0x0001;
hval = 0x0001;
+   mask = 0x0707;
}
 
nv_mask(priv, hreg, 0x000f, hval);
-   nv_mask(priv, oreg, 0x0707, oval);
+   nv_mask(priv, oreg, mask, oval);
}
 }
 


Patches currently in stable-queue which might be from emil.l.veli...@gmail.com 
are

queue-3.10/drm-nv50-disp-use-output-specific-mask-in-interrupt.patch

-- 
Yves-Alexis


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

Bug#712999: linux-image-3.9-1-amd64: Unable to find LVM volume

2013-07-23 Thread Josef Krieglstein


Dear Maintainer,

Many thanks for the job you all been doing! Great work!

I can confirm same behavior on nvidia MCP61, and linux-image-3.9-0.bpo.1-amd64  
  3.9.6-1~bpo70+1
I must add rootdelay=5 (I don't try less) to boot.

on AMD chipset 970 + SB950 with 3.9.x it is OK, rootdelay not needed.
on MCP61 with stock Wheezy kernel (3.2.0-4-amd64) it is OK, rootdelay not 
needed.

cheers

Josef Krieglstein


--
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/51eec348.7090...@trenet.org

Bug#717681: linux-image-3.10-1-amd64: reproducable Data loss with kernel linux-image-3.10-1-amd64 with md-raid devices

2013-07-23 Thread Thomas Rösch

Package: src:linux
Version: 3.10.1-1
Severity: normal

Dear Maintainer,


I have a system with some md raid devices using raid10. When I want to change
the partitioning of a harddisk, I set all partitions to fail in the raid and
removed then.
After the new partitioning was done, I readd the devices and the raid syncs
again. After successful syncing (nearly one day) everything looks file and the
raid reports no errors.

On the next day, four of raid filesystems are defect and cannot be repaired.
The error was something like illegal entry in ext bitmaps I search for this
error and all says: restore your data ond one says: rewrite alle superblocks
with mkfs.ext4 -S and then use fsck, which seems to work, but nearly all data
are corrupted and contains spots or areas of zero.


But when I restore the data from backup (after creating a new ext4 filesystem
like before) everything looks fine again - until the next start on the next
day. All restored partitions have the same defect as before.
I memory check (memtest) do not found any problem, the other filesystems are
still ok.

On the next try to restore my data, I see that the kernel is still writing data
after reading from my backup medium are finished. Ok, it is flushing the
buffers. After a successful call of sync I see that is still continuing writing
data. Not like the normal rate at 80-400 MB/s, only at 5-10 MB/s. Another sync
returns at once. So for a full memory cache of about 10GBytes, it need around
30min to write down all and then the disk writing stops.

If I don't wait, this data is  *not written*, if I shut down the computer
regulary. It looks like that these data are not covered by a sync.

When I returned to linux-image-3.9-1-amd64 (which I actually use), I don't see
this behavior and all my data I restored are still healthy. Here after a sync
all data are written  and I have no problems after restoring data or powering
down.

Tom



-- Package-specific info:
** Kernel log: boot messages should be attached


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-3.10-1-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.50
ii  initramfs-tools [linux-initramfs-tool]  0.113
ii  kmod9-3
ii  linux-base  3.5
ii  module-init-tools   9-3

Versions of packages linux-image-3.10-1-amd64 recommends:
ii  firmware-linux-free  3.2

Versions of packages linux-image-3.10-1-amd64 suggests:
pn  debian-kernel-handbook  none
ii  extlinux3:4.05+dfsg-6+deb7u3
ii  grub-pc 2.00-15
pn  linux-doc-3.10  none

Versions of packages linux-image-3.10-1-amd64 is related to:
pn  firmware-atherosnone
pn  firmware-bnx2   none
pn  firmware-bnx2x  none
pn  firmware-brcm80211  none
pn  firmware-intelwimax none
pn  firmware-ipw2x00none
pn  firmware-ivtv   none
ii  firmware-iwlwifi0.39
pn  firmware-libertas   none
pn  firmware-linux  none
ii  firmware-linux-nonfree  0.39
pn  firmware-myricomnone
pn  firmware-netxen none
pn  firmware-qlogic none
ii  firmware-ralink 0.39
ii  firmware-realtek0.39
pn  xen-hypervisor  none

-- debconf information:
  linux-image-3.10-1-amd64/postinst/depmod-error-initrd-3.10-1-amd64: false
  linux-image-3.10-1-amd64/postinst/ignoring-ramdisk:
  linux-image-3.10-1-amd64/postinst/missing-firmware-3.10-1-amd64:
  linux-image-3.10-1-amd64/prerm/removing-running-kernel-3.10-1-amd64: true


-- 
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/20130723183339.2404.8186.report...@glatschig.net.z

Processed: kernel

Processing commands for cont...@bugs.debian.org:

 reassign 717678 linux
Bug #717678 [rsync] rsync makes NAS unresponsive
Bug reassigned from package 'rsync' to 'linux'.
No longer marked as found in versions rsync/3.0.9-4.
Ignoring request to alter fixed versions of bug #717678 to the same values 
previously set
 --
Stopping processing here.

Please contact me if you need assistance.
-- 
717678: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717678
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.137460660525968.transcr...@bugs.debian.org

Processed: title

Processing commands for cont...@bugs.debian.org:

 retitle 717678 BUG: soft lockup - CPU#0 stuck for 23s when running rsync
Bug #717678 [linux] rsync makes NAS unresponsive
Changed Bug title to 'BUG: soft lockup - CPU#0 stuck for 23s when running 
rsync' from 'rsync makes NAS unresponsive'
 --
Stopping processing here.

Please contact me if you need assistance.
-- 
717678: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717678
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.137460665326173.transcr...@bugs.debian.org

Processed: severity of 717681 is critical

Processing commands for cont...@bugs.debian.org:

 severity 717681 critical
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
Severity set to 'critical' from 'normal'
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
717681: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717681
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.137460696527984.transcr...@bugs.debian.org

Bug#717678: rsync makes NAS unresponsive

2013-07-23 Thread Volker Bier

Package: rsync
Version: 3.0.9-4
Severity: normal

Dear Maintainer,
when using rsync to make a backup, the complete machine (qnap ts-119pii nas 
box) becomes
unresponsive. The SSS session dies, I can no longer login to the box. The only 
thing left
is to power down the box by long pressing the power button.

Sometimes rsync run for a few minutes before hanging the nas, today (I just 
retried it with
the current kernel), it hang after 2 seconds. But that has been varying the 
whole time.

The serial console repeatedly shows:
[  584.399202] BUG: soft lockup - CPU#0 stuck for 23s! [rsync:3603]
[  584.405233] Modules linked in: sg usb_storage nfsd nfs nfs_acl auth_rpcgss 
fscache lockd sunrpc ipv6 ext2 loop hmac xhci_hcd ehci_hcd evdev sha1_generic 
usbcore mv_cesa usb_common aes_generic mv643xx_eth inet_lro libphy gpio_keys 
ext3 mbcache jbd sd_mod crc_t10dif sata_mv libata scsi_mod
[  584.431087]
[  584.432580] Pid: 3603, comm:rsync
[  584.437298] CPU: 0Not tainted  (3.2.0-4-kirkwood #1 Debian 
3.2.41-2.1qnap)
[  584.444547] PC is at send_to_group.isra.2+0x24/0x154
[  584.449533] LR is at fsnotify+0x15c/0x1e8
[  584.453553] pc : [c00f193c]lr : [c00f1bc8]psr: a013
[  584.453556] sp : cb50dec8  ip : 6093  fp : 0001
[  584.465088] r10: df8b7720  r9 : df8ccbc8  r8 : cb50df34
[  584.470328] r7 : 0002  r6 :   r5 : df8b7720  r4 : 0002
[  584.476878] r3 : 0002  r2 :   r1 : cb5a8720  r0 : df8b7720
[  584.483426] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  584.490586] Control: 0005397f  Table: 0b51  DAC: 0015
[  584.496357] [c001369c] (unwind_backtrace+0x0/0xe0) from [c00645ac] 
(watchdog_timer_fn+0xe0/0x134)
[  584.505615] [c00645ac] (watchdog_timer_fn+0xe0/0x134) from [c004365c] 
(__run_hrtimer+0x118/0x1ec)
[  584.514875] [c004365c] (__run_hrtimer+0x118/0x1ec) from [c0043e80] 
(hrtimer_interrupt+0xe8/0x230)
[  584.524138] [c0043e80] (hrtimer_interrupt+0xe8/0x230) from [c001a1dc] 
(orion_timer_interrupt+0x20/0x30)
[  584.533921] [c001a1dc] (orion_timer_interrupt+0x20/0x30) from [c0064e9c] 
(handle_irq_event_percpu+0x7c/0x23c)
[  584.544226] [c0064e9c] (handle_irq_event_percpu+0x7c/0x23c) from 
[c0065084] (handle_irq_event+0x28/0x38)
[  584.554098] [c0065084] (handle_irq_event+0x28/0x38) from [c0067240] 
(handle_level_irq+0xac/0xc0)
[  584.563271] [c0067240] (handle_level_irq+0xac/0xc0) from [c006486c] 
(generic_handle_irq+0x28/0x44)
[  584.572621] [c006486c] (generic_handle_irq+0x28/0x44) from [c000ed94] 
(handle_IRQ+0x60/0x84)
[  584.581443] [c000ed94] (handle_IRQ+0x60/0x84) from [c000dab4] 
(__irq_svc+0x34/0x78)
[  584.589483] [c000dab4] (__irq_svc+0x34/0x78) from [c00f193c] 
(send_to_group.isra.2+0x24/0x154)
[  584.598482] [c00f193c] (send_to_group.isra.2+0x24/0x154) from [c00f1bc8] 
(fsnotify+0x15c/0x1e8)
[  584.607568] [c00f1bc8] (fsnotify+0x15c/0x1e8) from [c00c0fa0] 
(vfs_write+0x118/0x178)
[  584.615782] [c00c0fa0] (vfs_write+0x118/0x178) from [c00c1218] 
(sys_write+0x3c/0x68)
[  584.623910] [c00c1218] (sys_write+0x3c/0x68) from [c000dea0] 
(ret_fast_syscall+0x0/0x2c)

The command issued was
rsync -av --delete /home/multimedia/bilder /mnt/hdd/backups/daily.0/

I could use rsync with the exact same options on QNAP OS, so this does not seem 
to be a HW problem.
I even found another user with the exact same problem (he has the same NAS box).

-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.2.0-4-kirkwood
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages rsync depends on:
ii  base-files  7.1wheezy1
ii  libacl1 2.2.51-8
ii  libc6   2.13-38
ii  libgcc1 1:4.7.2-5
ii  libpopt01.16-7
ii  lsb-base4.1+Debian8+deb7u1

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:6.0p1-4
ii  openssh-server  1:6.0p1-4

-- no debconf information


-- 
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/20130723175325.11362.69822.report...@netzwerkplatte.fritz.box

Re: Debian should register a namespace at the EFI System Partition Subdirectory Registry

2013-07-23 Thread Lucas Nussbaum

On 20/07/13 at 23:34 +0200, Christoph Anton Mitterer wrote:
 Hi Lucas.
 
 I think it cannot harm (even if we don't need it right now and although
 the whole thing is anyway just voluntary), that debian registers it's
 name at the EFI System Partition Subdirectory Registry:
 http://www.uefi.org/specs/esp_registry
 
 The other major distros seem to have done this already.
 
 I guess that probably needs to be done by some officially authorised
 Debian person...
 
 Cheers,
 Chris.

Hi Christoph,

I'm not very familiar with UEFI, so it would be much better if someone
knowledgeable on the topic would advise me (and/or do the process for
Debian). I'm Ccing the Debian Kernel team and the Grub maintainers,
maybe they can provide their opinion on this (or redirect to someone
else).

Thanks a lot for the heads up,

Lucas


-- 
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/20130723191744.gb7...@xanadu.blop.info

Processed: Re: linux-image-2.6.38-2-686: Horrible Time Skew, Eventual Near-zero Responsiveness

Processing commands for cont...@bugs.debian.org:

 reassign 626432 src:linux
Bug #626432 [linux-2.6] linux-image-2.6.38-2-686: Horrible Time Skew, Eventual 
Near-zero Responsiveness
Bug reassigned from package 'linux-2.6' to 'src:linux'.
No longer marked as found in versions 2.6.38-5.
Ignoring request to alter fixed versions of bug #626432 to the same values 
previously set
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
626432: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626432
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.137461202624434.transcr...@bugs.debian.org

Bug#610467: marked as done (firmware-linux-free: not supported hardware: Gigabyte K8100 Aivia USB Gaming Keyboard)

Your message dated Tue, 23 Jul 2013 22:36:16 +0200
with message-id 20130723203615.ga7...@inutil.org
and subject line Re: not supported hardware: Gigabyte K8100 Aivia USB Gaming 
Keyboard
has caused the Debian Bug report #610467,
regarding firmware-linux-free: not supported hardware: Gigabyte K8100 Aivia USB 
Gaming Keyboard
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.)


-- 
610467: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610467
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: firmware-linux-free
Version: 2.6.32-30
Severity: important

lsusb
Bus 002 Device 006: ID 060b:2270 Solid Year
Bus 002 Device 005: ID 1044:7a02 Chu Yuen Enterprise Co., Ltd
Bus 002 Device 004: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 002 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

hwinfo
77: USB 00.0:  Unclassified device
[Created at usb.122]
UDI: /org/freedesktop/Hal/devices/usb_device_1044_7a02_noserial_if0
Unique ID: RZtk.cCMLqvxI8qC
Parent ID: R8DB.d7FDLX76qXB
SysFS ID: /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.2/2-1.1.2:1.0
SysFS BusID: 2-1.1.2:1.0
Hardware Class: unknown
Model: Chu Yuen Enterprise Unclassified device
Hotplug: USB
Vendor: usb 0x1044 Chu Yuen Enterprise Co., Ltd
Device: usb 0x7a02
Driver: usbhid
Driver Modules: usbhid
Speed: 12 Mbps
Module Alias: usb:v1044p7A02ddc00dsc00dp00ic03isc00ip00
Driver Info #0:
Driver Status: usbhid is active
Driver Activation Cmd: modprobe usbhid
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #75 (Hub)

80: USB 00.0: 10800 Keyboard
[Created at usb.122]
UDI:
/org/freedesktop/Hal/devices/usb_device_60b_2270_noserial_if0_logicaldev_input
Unique ID: Iq74.wG4B9Q+zvp6
Parent ID: R8DB.d7FDLX76qXB
SysFS ID: /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.4/2-1.1.4:1.0
SysFS BusID: 2-1.1.4:1.0
Hardware Class: keyboard
Model: Solid Year USB Keyboard
Hotplug: USB
Vendor: usb 0x060b Solid Year
Device: usb 0x2270 USB Keyboard
Revision: 2.20
Driver: usbhid
Driver Modules: usbhid
Device File: /dev/input/event2
Device Files: /dev/input/event2, /dev/char/13:66, /dev/input/by-id/usb-
KB_USB_Keyboard-event-kbd, /dev/input/by-path/pci-:00:1d.0-usb-0:1.1.4:1.0
-event-kbd
Device Number: char 13:66
Speed: 1.5 Mbps
Module Alias: usb:v060Bp2270d0220dc00dsc00dp00ic03isc01ip01
Driver Info #0:
XkbRules: xfree86
XkbModel: pc104
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #75 (Hub)

81: USB 00.1:  Unclassified device
[Created at usb.122]
UDI: /org/freedesktop/Hal/devices/usb_device_60b_2270_noserial_if1
Unique ID: m+N8.fN9LWyoZqs0
Parent ID: R8DB.d7FDLX76qXB
SysFS ID: /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1.4/2-1.1.4:1.1
SysFS BusID: 2-1.1.4:1.1
Hardware Class: unknown
Model: Solid Year USB Keyboard
Hotplug: USB
Vendor: usb 0x060b Solid Year
Device: usb 0x2270 USB Keyboard
Revision: 2.20
Driver: usbhid
Driver Modules: usbhid
Speed: 1.5 Mbps
Module Alias: usb:v060Bp2270d0220dc00dsc00dp00ic03isc00ip00
Driver Info #0:
Driver Status: usbhid is active
Driver Activation Cmd: modprobe usbhid
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #75 (Hub)

dmesg | grep usb
[ 1.537140] usbcore: registered new interface driver usbfs
[ 1.538227] usbcore: registered new interface driver hub
[ 1.539294] usbcore: registered new device driver usb
[ 2.488575] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 2.488577] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.488579] usb usb1: Product: EHCI Host Controller
[ 2.488580] usb usb1: Manufacturer: Linux 2.6.32-5-686-bigmem ehci_hcd
[ 2.488581] usb usb1: SerialNumber: :00:1a.0
[ 2.488624] usb usb1: configuration #1 chosen from 1 choice
[ 3.370871] usb 1-1: new high speed USB device using ehci_hcd and address 2
[ 3.507074] usb 1-1: New USB device found, idVendor=8087, idProduct=0020
[ 3.507076] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.507111] usb 1-1: configuration #1 chosen from 1 choice
[ 4.009747] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 4.009749] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 4.009751] usb usb2: Product: EHCI Host Controller
[ 4.009752] usb usb2: Manufacturer: Linux 2.6.32-5-686-bigmem ehci_hcd
[

Bug#626432: linux-image-2.6.38-2-686: Horrible Time Skew, Eventual Near-zero Responsiveness

2013-07-23 Thread Moritz Muehlenhoff

reassign 626432 src:linux
thanks

On Wed, May 11, 2011 at 10:55:13PM +0100, Sabahattin Gucukoglu wrote:
 Package: linux-2.6
 Version: 2.6.38-5
 Severity: important
 
 (reportbug script died, hope you've got everything.)
 
 The machine runs with *HORRIBLE* clock drift (see text).  Eventually, the 
 system will slow right down, so that new processes or threads will not 
 start.  It *seems* to be related to the use of BRLTTY.  See this thread: 
 http://www.mail-archive.com/brltty@mielke.cc/msg05352.html
 
 And, yes, it's annoying having to hard-reboot the box every so often.  It 
 would seem that after some period of time, touching my display or the 
 physical console triggers the lockup.  I don't think this is a coincidence, 
 even though on the surface there are two different problems.  The kernel 
 upgrade was sufficient to begin these issues.

Does this work in more recent kernels, e.g. the one from Wheezy?

Cheers,
Moritz


-- 
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/20130723203636.gb7...@inutil.org

Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs

2013-07-23 Thread Roger Leigh

On 23/07/13 18:48, Michael Prokop wrote:

[Cc-ing everyone who was involved in discussing #652459]

(Also copying Adam Conrad and Steve Langasek.)

* Roger Leigh [Sun May 12, 2013 at 06:53:11PM +0100]:

And one final patch to use panic rather than sulogin on fsck failure.

Thanks for all your patches, I've applied them on top of current
master (and edited debian/changelog on my own, being based on your
patches). The result is currently sitting in branch mika/bug_652459
of initramfs-tools.git.

Does anyone have any objections against the current implementation
of #652459 to support mounting of /usr in the initramfs?
If so, which objections do you have and what needs to be done to
resolve this issue so all involved parties are happy?

If there aren't any objections against the current implementation,
are there any objections against uploading the current state to
experimental?

Just a note for testers:

This patchset does require patches for util-linux (fsck -R also
ignores /usr as well as root) and initscripts (remount /usr r/w at the
same time as the rootfs in checkroot.sh, and otherwise handle it the
same as the rootfs). util-linux patch is in #697002. initscripts is
this commit:
http://anonscm.debian.org/gitweb/?p=users/rleigh/sysvinit.git;a=commitdiff;h=d406626ecad8988198542f270b663f3503f0b7ae

For both of these I can put versions in experimental. initramfs-tools
probably needs to have a Breaks: on versions prior to these patched
versions, so it might be worth holding off uploading prior to these
prerequisites being in place. Though if you don't have a separate /usr,
this won't cause any problems. If you do, fsck will fail at boot when
it tries to fsck a mounted /usr, and it will also leave /usr r/o.

Lastly, there is a minor outstanding shortcoming in the ordering of
progress messages with my patchset. I left the ordering as-is, but it
probably wants tweaking so that there's a linear order rather than
nesting messages. e.g. fsck prior to mounting rather than during etc.
This is only cosmetic--it probably just needs the mount message moving
further down; other third-party scripts might also need tweaking.

Note that the patches for all three packages also included the logic for
mounting /etc. If this is not wanted, we should probably drop that at
this point. For initscripts and util-linux, these will be entirely
harmless and will do nothing unless an fstab entry exists; and likewise
for initramfs-tools unless you supply additional options on the kernel
command-line.

Regards,
Roger

--
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/51eef112.6050...@codelibre.net

Bug#717689: linux: please review and merge m68k patch

Dixi quod…

Even if this may have some minor issues still, it’ll be better
than building kernel images that fail to boot at all, that’s why

Ah well. Of course it didn’t boot.

/lib/modules/3.10-0+m68k.2-m68k/kernel/arch/m68k/emu/nfblock.ko
is the “IDE” driver for ARAnyM machines (like virtio-blk).

It’s not present in the initrd (others, like buddha, falconide,
gayle, macide, q40ide in drivers/ide/ and atari_scsi.ko and
friends in drivers/scsi/ are), which makes my boot fail, since
I used root=/dev/nfhd8p1 like before (nfhd8 ~= vda in kvm terms).

Which package is responsible for the inclusion of arch-specific
kernel modules into the initrd (for MODULES=most right now; I
have yet to try MODULES=dep)?

Thanks,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs


--
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/pine.bsm.4.64l.1307232123420.26...@herc.mirbsd.org

Bug#717689: linux: please review and merge m68k patch

2013-07-23 Thread Bastian Blank

On Tue, Jul 23, 2013 at 09:26:28PM +, Thorsten Glaser wrote:
 Which package is responsible for the inclusion of arch-specific
 kernel modules into the initrd (for MODULES=most right now; I
 have yet to try MODULES=dep)?

initramfs-tools

Bastian

-- 
Violence in reality is quite different from theory.
-- Spock, The Cloud Minders, stardate 5818.4


-- 
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/20130723214742.gb8...@mail.waldi.eu.org

resume file

2013-07-23 Thread Rodolfo García Peñas

Hi,

I have a question about the file /etc/initramfs-tools/conf.d/resume file. I 
have this bug ([1]) in the uswsusp package.

Should/must the uswsusp package update that file? What is the better way to do 
it (modify the file directly, call any script,...)?

Thanks a lot,
Rodolfo.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632627
-- 
Rodolfo kix Garcia
k...@debian.org


-- 
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/20130723214806.ga13...@kix.es

Bug#717689: linux: please review and merge m68k patch

2013-07-23 Thread Bastian Blank

On Tue, Jul 23, 2013 at 08:42:04PM +, Thorsten Glaser wrote:
 +CONFIG_IOSCHED_DEADLINE=m
 +CONFIG_IOSCHED_CFQ=m

Should be configured in the top config.

 +# CONFIG_EXT2_FS_SECURITY is not set
 +# CONFIG_EXT3_FS_SECURITY is not set

Why?

 -CONFIG_EXT4_FS=y
 -CONFIG_EXT4_USE_FOR_EXT23=y

You could still stick to this option.

 +CONFIG_NFS_SWAP=y
 +CONFIG_NLS_MAC_ROMAN=m
 +CONFIG_NLS_MAC_CELTIC=m
 +CONFIG_NLS_MAC_CENTEURO=m
 +CONFIG_NLS_MAC_CROATIAN=m
 +CONFIG_NLS_MAC_CYRILLIC=m
 +CONFIG_NLS_MAC_GAELIC=m
 +CONFIG_NLS_MAC_GREEK=m
 +CONFIG_NLS_MAC_ICELAND=m
 +CONFIG_NLS_MAC_INUIT=m
 +CONFIG_NLS_MAC_ROMANIAN=m
 +CONFIG_NLS_MAC_TURKISH=m

Why here?

 +CONFIG_LOG_BUF_SHIFT=16

Why override?

 +## choice: Preemption Model
 +CONFIG_PREEMPT_NONE=y
 +# CONFIG_PREEMPT_VOLUNTARY is not set
 +# CONFIG_PREEMPT is not set
 +## end choice

Isn't this already set?

 +##
 +## file: unknown
 +##

You want to take a look at this options.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, This Side of Paradise, stardate 3417.3


-- 
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/20130723215442.gc8...@mail.waldi.eu.org

Bug#717689: linux: please review and merge m68k patch

Bastian Blank dixit:

On Tue, Jul 23, 2013 at 09:26:28PM +, Thorsten Glaser wrote:
 Which package is responsible for the inclusion of arch-specific
 kernel modules into the initrd (for MODULES=most right now; I
 have yet to try MODULES=dep)?

initramfs-tools

OK, thanks!

Doesn’t help though. I suspect that nfblock was never tested
as module: adding it to the initrd still doesn’t get the
device nodes created.

Please amend the patch:

--- debian/config/m68k/config   2013-07-23 19:43:47.490681446 +
+++ -   2013-07-23 22:04:00.997953396 +
@@ -21,7 +21,7 @@
 CONFIG_HEARTBEAT=y
 CONFIG_PROC_HARDWARE=y
 CONFIG_NATFEAT=y
-CONFIG_NFBLOCK=m
+CONFIG_NFBLOCK=y
 CONFIG_NFCON=y
 CONFIG_NFETH=m
 CONFIG_ATARI_ETHERNAT=y

This is merely what we had before. (I’m giving nfeth a chance here…)

bye,
//mirabilos
-- 
[00:02] Vutral gecko: benutzt du emacs ?
[00:03] gecko nö  [00:03] gecko nur n normalen mac
[00:04] Vutral argl   [00:04] Vutral ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)


--
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/pine.bsm.4.64l.1307232202550.26...@herc.mirbsd.org

Bug#717689: linux: please review and merge m68k patch

Bastian Blank dixit:

On Tue, Jul 23, 2013 at 08:42:04PM +, Thorsten Glaser wrote:
 +CONFIG_IOSCHED_DEADLINE=m
 +CONFIG_IOSCHED_CFQ=m

Should be configured in the top config.

They’re =y there. I put them into modules to save space.

 +# CONFIG_EXT2_FS_SECURITY is not set
 +# CONFIG_EXT3_FS_SECURITY is not set

Why?

Saving space since CONFIG_SECURITY=n.

 -CONFIG_EXT4_USE_FOR_EXT23=y

You could still stick to this option.

The debian/config/config doesn’t use it and builds
separate ext2/ext3/ext4 modules instead, so I did
that too.

 +CONFIG_NFS_SWAP=y
 +CONFIG_NLS_MAC_ROMAN=m
 +CONFIG_NLS_MAC_CELTIC=m
 +CONFIG_NLS_MAC_CENTEURO=m
 +CONFIG_NLS_MAC_CROATIAN=m
 +CONFIG_NLS_MAC_CYRILLIC=m
 +CONFIG_NLS_MAC_GAELIC=m
 +CONFIG_NLS_MAC_GREEK=m
 +CONFIG_NLS_MAC_ICELAND=m
 +CONFIG_NLS_MAC_INUIT=m
 +CONFIG_NLS_MAC_ROMANIAN=m
 +CONFIG_NLS_MAC_TURKISH=m

Why here?

Because debian/config/config didn’t contain them.
But they could be moved there, yes – but I didn’t
want to touch !m68k space.

 +CONFIG_LOG_BUF_SHIFT=16

Why override?

Saving some more space… I will retract this line
if you say so.

 +## choice: Preemption Model
 +CONFIG_PREEMPT_NONE=y
 +# CONFIG_PREEMPT_VOLUNTARY is not set
 +# CONFIG_PREEMPT is not set
 +## end choice

Isn't this already set?

No, it’s set to CONFIG_PREEMPT_VOLUNTARY.

 +##
 +## file: unknown
 +##

You want to take a look at this options.

Right… I did have that planned but forgot.

I looked at them all, and the entire block can go,
they don’t appear in this century’s kernel source ;-)

bye,
//mirabilos
-- 
17:08⎜«Vutral» früher gabs keine packenden smartphones und so
17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig
17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch
17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt


--
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/pine.bsm.4.64l.1307232206360.26...@herc.mirbsd.org

Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot

2013-07-23 Thread Roger Leigh

On Tue, Jul 23, 2013 at 06:05:57PM +0200, Borislav Petkov wrote:
 On Mon, Jul 22, 2013 at 08:19:26PM +0100, Roger Leigh wrote:
  Ben's patch does allow me to boot the system with the memory in this
  configuration on a 3.10 kernel.
 
 Ok, I actually think we can fix it the way below. It should be
 equivalent to Ben's patch in current functionality with the difference
 that it is a bit simpler and keeps the special handling for K8 which I
 want to have there as a future info.
 
 In addition, it still provides for the data structures to be initialized
 so some day, when memory hotplug is supported, it should work out of the
 box when all of a sudden a second channel appears.
 
 I think it should apply cleanly to 3.8 or 3.9 too as we haven't had a
 whole lot of movement in that area :-)

I've tested it against 3.10 and I can confirm that it works.  I've
booted the system with the DRAM on the same channel, and on
separate channels, and it's working without problems in both cases.


Many thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot

2013-07-23 Thread Borislav Petkov

On Tue, Jul 23, 2013 at 11:24:17PM +0100, Roger Leigh wrote:
 I've tested it against 3.10 and I can confirm that it works.  I've
 booted the system with the DRAM on the same channel, and on
 separate channels, and it's working without problems in both cases.

That's good news, thanks for testing and helping with this Roger.

I'll add your Tested-by and queue it for 3.12 (i.e., I don't see it
being urgent enough to rush it to -stable since your dual-channel layout
takes care of the issue indirectly).

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--


-- 
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/20130723223911.gj8...@pd.tnic

Bug#717689: linux: please review and merge m68k patch

Dixi quod…

This is merely what we had before. (I’m giving nfeth a chance here…)

“No such device” is what nfeth.ko says upon insmod.
I’ll report this as bug upstream and revert it to =y too:

--- debian/config/m68k/config   2013-07-23 22:38:05.519153764 +
+++ -   2013-07-23 22:38:28.394235256 +
@@ -21,9 +21,9 @@
 CONFIG_HEARTBEAT=y
 CONFIG_PROC_HARDWARE=y
 CONFIG_NATFEAT=y
-CONFIG_NFBLOCK=m
+CONFIG_NFBLOCK=y
 CONFIG_NFCON=y
-CONFIG_NFETH=m
+CONFIG_NFETH=y
 CONFIG_ATARI_ETHERNAT=y
 CONFIG_ATARI_ETHERNEC=y
 CONFIG_ATARI_DSP56K=m
@@ -984,27 +984,3 @@
 CONFIG_DMASOUND_ATARI=m
 CONFIG_DMASOUND_PAULA=m
 CONFIG_DMASOUND_Q40=m
-
-##
-## file: unknown
-##
-CONFIG_ATARI_MFPSER=m
-CONFIG_ATARI_MIDI=m
-CONFIG_ATARI_SCC=y
-CONFIG_ATARI_SCC_DMA=y
-CONFIG_STRAM_PROC=y
-CONFIG_BLK_DEV_IDEDOUBLER=y
-CONFIG_BLZ1230_SCSI=y
-CONFIG_BLZ2060_SCSI=y
-CONFIG_CYBERSTORMII_SCSI=y
-CONFIG_CYBERSTORM_SCSI=y
-CONFIG_FASTLANE_SCSI=y
-# CONFIG_FB_CYBER is not set
-# CONFIG_FB_RETINAZ3 is not set
-# CONFIG_FB_VIRGE is not set
-CONFIG_MULTIFACE_III_TTY=m
-# CONFIG_OKTAGON_SCSI is not set
-CONFIG_SCSI_AMIGA7XX=y
-# CONFIG_SCSI_NCR53C7xx_FAST is not set
-# CONFIG_WHIPPET_SERIAL is not set
-CONFIG_MVME147_SCC=y


--
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/pine.bsm.4.64l.1307232239090.26...@herc.mirbsd.org

Bug#717473: BUG: Null pointer deref in amd64_edac_mod/amd64_probe_one_instance during boot

On Wed, Jul 24, 2013 at 12:39:11AM +0200, Borislav Petkov wrote:
 On Tue, Jul 23, 2013 at 11:24:17PM +0100, Roger Leigh wrote:
  I've tested it against 3.10 and I can confirm that it works.  I've
  booted the system with the DRAM on the same channel, and on
  separate channels, and it's working without problems in both cases.
 
 That's good news, thanks for testing and helping with this Roger.
 
 I'll add your Tested-by and queue it for 3.12 (i.e., I don't see it
 being urgent enough to rush it to -stable since your dual-channel layout
 takes care of the issue indirectly).

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.)

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/20130723230449.gr7...@decadent.org.uk

Processed: severity of 717654 is important

Processing commands for cont...@bugs.debian.org:

 severity 717654 important
Bug #717654 [src:linux] (no subject)
Severity set to 'important' from 'critical'
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
717654: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717654
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.137462108415235.transcr...@bugs.debian.org

Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs

2013-07-23 Thread maximilian attems

On Tue, Jul 23, 2013 at 10:09:38PM +0100, Roger Leigh wrote:
 On 23/07/13 18:48, Michael Prokop wrote:
 [Cc-ing everyone who was involved in discussing #652459]
 
 (Also copying Adam Conrad and Steve Langasek.)
 
 * Roger Leigh [Sun May 12, 2013 at 06:53:11PM +0100]:
 
 And one final patch to use panic rather than sulogin on fsck failure.
 
 Thanks for all your patches, I've applied them on top of current
 master (and edited debian/changelog on my own, being based on your
 patches). The result is currently sitting in branch mika/bug_652459
 of initramfs-tools.git.
 
 Does anyone have any objections against the current implementation
 of #652459 to support mounting of /usr in the initramfs?
 If so, which objections do you have and what needs to be done to
 resolve this issue so all involved parties are happy?

The shell parsing of /etc/fstab would run on any boot?

nitpicking read_fstab_entry():

- useless loop, please just assign:
+   for file in ${rootmnt}/etc/fstab; do

+   if [ -f $file ]; then
Please reverse logic and immediately return if no fstab

+   if [ $MNT_DIR = $1 ]; then
similary please just unwrap that too.


thanks.

-- 
maks


-- 
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/20130723233045.ga4...@stro.at

Bug#703715: Kernel bug ALPS TouchPad and i915 DRM do not play nicely on Wheezy 3.2.0-4-amd64

On Tue, 2013-07-23 at 20:13 +1000, iiNET wrote:
 Hi Kernel Maintainers
 
 I have been tracking related bugs 704987 and 703715, I have suggested a 
 fix that has been under test for the last week and seems to fix the 
 reported issue, the following is the patch from the stable tree that 
 reverts Debian patch, 
 features/all/Input-add-Synaptics-USB-device-driver.patch.

I don't know how you think these are connected...

 Testing has been editing, creating and reading various Libre Office 
 files without any symptoms reported, all with various touch pad 
 interactions, suspend, resume.
 
 
 commit e24fb4d67f53530038a9711d0c1f65937490bb8c
 Author: Ben Hutchings b...@decadent.org.uk
 Date:   Tue Jun 25 04:15:27 2013 +0100
 
  Revert drm/i915: GFX_MODE Flush TLB Invalidate Mode must be  '1' 
 for scanli
 
  This reverts commit 393143615d9f2f581d87387268dc11b95adc339c, which
  was commit f05bb0c7b624252a5e768287e340e8e45df96e42 upstream.
 
  This has been found to cause GPU hangs when backported to 3.2, though
  not in mainline.
[...]

We are actually using the DRM code from 3.4, not 3.2.  But this patch is
applied and should not be.  Thanks for finding this.

If anyone else would like to test and confirm that this fixes the hangs
they are seeing, please use the attached patch, following the
instructions at
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
reverted:
--- b/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ a/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -407,11 +407,6 @@
 	if (INTEL_INFO(dev)-gen = 6)
 		I915_WRITE(MI_MODE, GFX_MODE_ENABLE(ASYNC_FLIP_PERF_DISABLE));
 
-	/* Required for the hardware to program scanline values for waiting */
-	if (INTEL_INFO(dev)-gen == 6)
-		I915_WRITE(GFX_MODE,
-			   GFX_MODE_ENABLE(GFX_TLB_INVALIDATE_ALWAYS));
-
 	if (IS_GEN7(dev))
 		I915_WRITE(GFX_MODE_GEN7,
 			   GFX_MODE_DISABLE(GFX_TLB_INVALIDATE_ALWAYS) |


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

Bug#703715: Kernel bug ALPS TouchPad and i915 DRM do not play nicely on Wheezy 3.2.0-4-amd64

2013-07-23 Thread Darren Williams




On 07/24/13 11:12, Ben Hutchings wrote:

On Tue, 2013-07-23 at 20:13 +1000, iiNET wrote:

Hi Kernel Maintainers

I have been tracking related bugs 704987 and 703715, I have suggested a
fix that has been under test for the last week and seems to fix the
reported issue, the following is the patch from the stable tree that
reverts Debian patch,
features/all/Input-add-Synaptics-USB-device-driver.patch.


I don't know how you think these are connected...

Aargh there not, should of said:
bugfix/x86/drm-i915-GFX_MODE-Flush-TLB-Invalidate-Mode-must-be-.
patch

Thanks for following up
Darren




Testing has been editing, creating and reading various Libre Office
files without any symptoms reported, all with various touch pad
interactions, suspend, resume.


commit e24fb4d67f53530038a9711d0c1f65937490bb8c
Author: Ben Hutchingsb...@decadent.org.uk
Date:   Tue Jun 25 04:15:27 2013 +0100

  Revert drm/i915: GFX_MODE Flush TLB Invalidate Mode must be  '1'
for scanli

  This reverts commit 393143615d9f2f581d87387268dc11b95adc339c, which
  was commit f05bb0c7b624252a5e768287e340e8e45df96e42 upstream.

  This has been found to cause GPU hangs when backported to 3.2, though
  not in mainline.

[...]

We are actually using the DRM code from 3.4, not 3.2.  But this patch is
applied and should not be.  Thanks for finding this.

If anyone else would like to test and confirm that this fixes the hangs
they are seeing, please use the attached patch, following the
instructions at
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.

Ben.



--

Darren Williams
IT Operations Manager
Australian Technology Park

National ICT Australia Limited
Level 5
13 Garden Street,
Eveleigh NSW 2015
Australia

Tel: (02) 8306 0517
Mob: 0409 835 793
Fax: (02) 8374 5558
Email: Darren.Williams AT nicta.com.au
Web: http://www.nicta.com.au

The imagination driving Australia's ICT future.



The information in this e-mail may be confidential and subject to legal 
professional privilege and/or copyright. National ICT Australia Limited accepts 
no liability for any damage caused by this email or its attachments.


--
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/51ef3433.2050...@nicta.com.au

Re: Bug#717689: linux: please review and merge m68k patch

On Tue, 2013-07-23 at 22:11 +, Thorsten Glaser wrote:
[...]
  -CONFIG_EXT4_USE_FOR_EXT23=y
 
 You could still stick to this option.
 
 The debian/config/config doesn’t use it and builds
 separate ext2/ext3/ext4 modules instead, so I did
 that too.

I think we may want to enable this at the top level later, but there is
no reason to override it now.

  +CONFIG_NFS_SWAP=y

Really?

  +CONFIG_NLS_MAC_ROMAN=m
  +CONFIG_NLS_MAC_CELTIC=m
  +CONFIG_NLS_MAC_CENTEURO=m
  +CONFIG_NLS_MAC_CROATIAN=m
  +CONFIG_NLS_MAC_CYRILLIC=m
  +CONFIG_NLS_MAC_GAELIC=m
  +CONFIG_NLS_MAC_GREEK=m
  +CONFIG_NLS_MAC_ICELAND=m
  +CONFIG_NLS_MAC_INUIT=m
  +CONFIG_NLS_MAC_ROMANIAN=m
  +CONFIG_NLS_MAC_TURKISH=m
 
 Why here?
 
 Because debian/config/config didn’t contain them.
 But they could be moved there, yes – but I didn’t
 want to touch !m68k space.

Apple has gone through a few architectures since m68k. :-)

  +CONFIG_LOG_BUF_SHIFT=16
 
 Why override?
 
 Saving some more space… I will retract this line
 if you say so.

I think this is reasonable since m68k machines may have very little RAM.

  +## choice: Preemption Model
  +CONFIG_PREEMPT_NONE=y
  +# CONFIG_PREEMPT_VOLUNTARY is not set
  +# CONFIG_PREEMPT is not set
  +## end choice
 
 Isn't this already set?
 
 No, it’s set to CONFIG_PREEMPT_VOLUNTARY.
[...]

Now why do you want to change that?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#717681: linux-image-3.10-1-amd64: reproducable Data loss with kernel linux-image-3.10-1-amd64 with md-raid devices

Neil, does the report below sound like the bug you fixed with:

commit 7bb23c4934059c64cbee2e41d5d24ce122285176
Author: NeilBrown ne...@suse.de
Date:   Tue Jul 16 16:50:47 2013 +1000

md/raid10: fix two problems with RAID10 resync.

or any of the others you've recently fixed?

On Tue, 2013-07-23 at 20:33 +0200, Thomas Rösch wrote:
 Package: src:linux
 Version: 3.10.1-1
 Severity: normal
 
 Dear Maintainer,
 
 
 I have a system with some md raid devices using raid10. When I want to change
 the partitioning of a harddisk, I set all partitions to fail in the raid and
 removed then.
 After the new partitioning was done, I readd the devices and the raid syncs
 again. After successful syncing (nearly one day) everything looks file and the
 raid reports no errors.
 
 On the next day, four of raid filesystems are defect and cannot be repaired.
 The error was something like illegal entry in ext bitmaps I search for this
 error and all says: restore your data ond one says: rewrite alle superblocks
 with mkfs.ext4 -S and then use fsck, which seems to work, but nearly all data
 are corrupted and contains spots or areas of zero.
 
 
 But when I restore the data from backup (after creating a new ext4 filesystem
 like before) everything looks fine again - until the next start on the next
 day. All restored partitions have the same defect as before.
 I memory check (memtest) do not found any problem, the other filesystems are
 still ok.
 
 On the next try to restore my data, I see that the kernel is still writing 
 data
 after reading from my backup medium are finished. Ok, it is flushing the
 buffers. After a successful call of sync I see that is still continuing 
 writing
 data. Not like the normal rate at 80-400 MB/s, only at 5-10 MB/s. Another sync
 returns at once. So for a full memory cache of about 10GBytes, it need 
 around
 30min to write down all and then the disk writing stops.
 
 If I don't wait, this data is  *not written*, if I shut down the computer
 regulary. It looks like that these data are not covered by a sync.
 
 When I returned to linux-image-3.9-1-amd64 (which I actually use), I don't see
 this behavior and all my data I restored are still healthy. Here after a sync
 all data are written  and I have no problems after restoring data or powering
 down.
 
 Tom
[...]

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Processed: tagging 717681, bug 717681 is forwarded to ne...@suse.de

Processing commands for cont...@bugs.debian.org:

 tags 717681 + upstream
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) upstream.
 forwarded 717681 ne...@suse.de
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
Set Bug forwarded-to-address to 'ne...@suse.de'.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
717681: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717681
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.137463502824435.transcr...@bugs.debian.org

Processed: tagging 717473

Processing commands for cont...@bugs.debian.org:

 tags 717473 + upstream patch
Bug #717473 [src:linux] BUG: Null pointer deref in 
amd64_edac_mod/amd64_probe_one_instance during boot
Ignoring request to alter tags of bug #717473 to the same tags previously set
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
717473: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717473
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.137463517624833.transcr...@bugs.debian.org

Processed: tagging 717590

Processing commands for cont...@bugs.debian.org:

 tags 717590 + pending
Bug #717590 [src:linux] linux: [nouveau] please backport drm/nv50-/disp: Use 
output specific mask ininterrupt
Added tag(s) pending.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
717590: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717590
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.137463542726292.transcr...@bugs.debian.org

Bug#717590: linux: [nouveau] please backport drm/nv50-/disp: Use output specific mask ininterrupt

On Mon, 2013-07-22 at 21:19 +0200, Yves-Alexis Perez wrote:
 Source: linux
 Severity: normal
 
 [the bug is not reported on the machine actually having the hardware]
 
 Hi,
 
 3.9 introduced a regression in nouveau driver. Basically, dual screen
 using DMS59 connector doesn't work anymore in 3.9 and 3.10.
 
 After a bit of debugging [1] it has been fixed [2] but apparently not
 yet backported to stable (nor 3.9 nor 3.10).
 
 Since it completely breaks dual screen setup on those boxes, it'd be
 nice to include the patch in the Debian package until they get properly
 included in a stable release.

Applied, thanks.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#717547: nfs-common: simple remount returns an error