Bug#787814: get-iplayer: unable to download anything
On Fri, 05 Jun 2015 15:24:09 +0100 Peter J Ross peadar.ru...@gmail.com wrote: On Fri, 05 Jun 2015 12:04:52 +0100 =?utf-8?b?SnVoYSBKw6R5a2vDpA==?= ju...@iki.fi wrote: Not a SCALAR reference at /usr/bin/get-iplayer line 7099. This has been fixed upstream in version 2.93. Current upstream version is 2.94. I confirm this. Simply copying get_iplayer version 2.94 from the git repository over the existing binary file makes everything work again. Can we update the version please? Having a non-working package doesn't really help anyone. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672851: netbase 5.0: network connection does not come up upon reboot
On Sat, 2012-05-19 at 22:40 +0100, Adam D. Barratt wrote: On Sat, 2012-05-19 at 19:55 +0100, James Bottomley wrote: On Sat, 2012-05-19 at 16:19 +0200, Marco d'Itri wrote: There is no bug, just don't do stupid things to your system. Yes, there is. The bug is that testing breaks networking on an upgrade and will do so for at least the next six days. No, it won't. ifupdown |0.7~rc3 | testing | source, amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc Great ... that's all I asked for: acceleration of ifupdown or backoff of netbase in testing. This bug can be closed now. James -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672851: netbase 5.0: network connection does not come up upon reboot
Package: netbase Version: 5.0 Followup-For: Bug #672851 This bug is still present in testing It means that anyone who does a dist-upgrade -t testing gets no networking. This just happened to me with a co-lo box resulting in a wasted hour investigating the source of an apparent boot failure. This is a really serious problem. It may be fixed by ifupdown-0.7~rc3 but that's stuck in unstable for another 6 days according to http://bjorn.haxx.se/debian/testing.pl?package=ifupdown Having networking break on dist upgrade to testing for another six days (at least) looks to be irresponsible to say the least. Please revert the netbase update or accelerate ifupdown into testing. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages netbase depends on: ii lsb-base 4.1+Debian3 Versions of packages netbase recommends: ii ifupdown 0.7~alpha5+really0.6.16 netbase suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672851: netbase 5.0: network connection does not come up upon reboot
On Sat, 2012-05-19 at 16:19 +0200, Marco d'Itri wrote: On May 19, James Bottomley james.bottom...@hansenpartnership.com wrote: It means that anyone who does a dist-upgrade -t testing gets no networking. This just happened to me with a co-lo box resulting in a Don't do it then ffs. Interesting idea, but back to the real world where people do actually upgrade their systems, telling them not to isn't so hot for all those new release things people do. There is no bug, just don't do stupid things to your system. Yes, there is. The bug is that testing breaks networking on an upgrade and will do so for at least the next six days. James -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614968: has now impacted testing
On Sat, 2011-03-05 at 10:34 -0600, James Bottomley wrote:
If I remove the transactions and just do a straight delete, everything
works (at least in my test environment; I'll try it on the real program
tonight). There's actually no real reason for the deletes to be done
transactionally. Even if we get a crash, we don't care whether all the
keys or none are deleted ... if we get partial deletion, the next
cleanup will get the rest.
OK, so confirmed last night that the cleanup ran correctly without the
transactional logic and that postgrey didn't die:
Mar 6 02:17:23 bedivere postgrey[32282]: cleaning main database finished.
before: 9349, after: 4484
Mar 6 02:17:24 bedivere postgrey[32282]: cleaning clients database finished.
before: 2844, after: 2336
The patch below is what I'm running.
James
---
--- /usr/sbin/postgrey.orig 2011-01-11 13:15:43.0 -0800
+++ /usr/sbin/postgrey 2011-03-05 08:40:02.0 -0800
@@ -275,11 +275,7 @@
$nr_keys_after++;
}
}
-my $db_obj = $self-{postgrey}{db_obj};
-my $txn = $db_env-txn_begin();
-$db_obj-Txn($txn);
for my $key (@old_keys) { delete $db-{$key}; }
-$txn-txn_commit();
$self-mylog(1, cleaning main database finished. before:
$nr_keys_before, after: $nr_keys_after);
@@ -299,11 +295,7 @@
$nr_keys_after++;
}
}
-my $db_cawl_obj = $self-{postgrey}{db_cawl_obj};
-$txn = $db_env-txn_begin();
-$db_cawl_obj-Txn($txn);
for my $key (@old_keys_cawl) { delete $cawl_db-{$key}; }
-$txn-txn_commit();
$self-mylog(1, cleaning clients database finished. before:
$nr_keys_before, after: $nr_keys_after);
}
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614968: has now impacted testing
On Fri, 2011-03-04 at 15:06 -0400, Joey Hess wrote:
James Bottomley wrote:
I picked this up on a recent testing upgrade (last Saturday). My
postgrey process is now dying every night as well (I've set up a harness
to restart it, but it's not ideal).
Following what happened in #441069 I tried
db5.1_recover -h /var/lib/postgrey/
but that doesn't fix the problem. Whatever it is, it looks to be deeper
than simply an incompatible database update.
My workaround has been to simply disable the broken part on line 249:
if(0 and $hour 1 and $hour 7 and
$now - $self-{postgrey}{last_maint_keys} = 82800)
Well, that means your database never gets cleaned. I was going to say
that simply restarting at least meant the main database got cleaned
(because it's crashing on the AWL transaction). However, I stripped the
cleaning code from postgrey and ran it on a copy of the database. In
spite of the fact that there's no error on the first $txn-commit(), the
transaction hasn't committed. The next transaction you try to create in
the $db_env is empty, which is why the crash.
What's even stranger is that the entire db and db_cawl ties look to be
non functional after $txn-commit() ... it's like setting up the
transaction actually causes the entire perl DB mechanism to fall over.
This all smells like a libdb5.1 problem.
If I remove the transactions and just do a straight delete, everything
works (at least in my test environment; I'll try it on the real program
tonight). There's actually no real reason for the deletes to be done
transactionally. Even if we get a crash, we don't care whether all the
keys or none are deleted ... if we get partial deletion, the next
cleanup will get the rest.
James
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: threads and fork on machine with VIPT-WB cache
On Tue, 2010-04-06 at 08:37 -0500, James Bottomley wrote: (5) Child process B is waken up and sees old value at x in oldpage, through different cache line. B sleeps. This isn't possible. at this point, A and B have the same virtual address and mapping for oldpage this means they are the same cache colour, so they both see the cached value. Perhaps to add more detail to this. In spite of what the arch manual says (it says the congruence stride is 16MB), the congruence stride on all manufactured parisc processors is 4MB. This means that any virtual addresses, regardless of space id, that are equal modulo 4MB have the same cache colour. James -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: threads and fork on machine with VIPT-WB cache
On Tue, 2010-04-06 at 13:57 +0900, NIIBE Yutaka wrote: John David Anglin wrote: It is interesting that in the case of the Debian bug that a thread of the parent process causes the COW break and thereby corrupts its own memory. As far as I can tell, the fork'd child never writes to the memory that causes the fault. Thanks for writing and testing a patch. The case of #561203 is second scenario. I think that this case is relevant to VIVT-WB machine too (provided kernel does copy by kernel address). James Bottomley wrote: So this is going to be a hard sell because of the arch churn. There are, however, three ways to do it with the original signature. Currently, I think that signature change would be inevitable for ptep_set_wrprotect. Well we can't do it by claiming several architectures are wrong in their implementation. We might do it by claiming to need vma knowledge ... however, even if you want the flush, as I said, you don't need to change the signature. 1. implement copy_user_highpage ... this allows us to copy through the child's page cache (which is coherent with the parent's before the cow) and thus pick up any cache changes without a flush Let me think about this way. Well, this would improve both cases of the first scenario of mine and the second scenario. But... I think that even if we would have copy_user_highpage which does copy by user address, we need to flush at ptep_set_wrprotect. I think that we need to keep the condition: no dirty cache for COW page. Think about third scenario of threads and fork: (1) In process A, there are multiple threads, and a thread A-1 invokes fork. We have process B, with a different space identifier color. I don't understand what you mean by space colour ... there's cache colour which refers to the line in the cache to which the the physical memory maps. The way PA is set up, space ID doesn't factor into cache colour. (2) Another thread A-2 in process A runs while A-1 copies memory by dup_mmap. A-2 writes to the address x in a page. Let's call this page oldpage. (3) We have dirty cache for x by A-2 at the time of ptep_set_wrprotect of thread A-1. Suppose that we don't flush here. (4) A-1 finishes copy, and sleeps. (5) Child process B is waken up and sees old value at x in oldpage, through different cache line. B sleeps. This isn't possible. at this point, A and B have the same virtual address and mapping for oldpage this means they are the same cache colour, so they both see the cached value. James (6) A-2 is waken up. A-2 touches the memory again, breaks COW. A-2 copies data on oldpage to newpage. OK, newpage is consistent with copy_user_highpage by user address. Note that during this copy, the cache line of x by A-2 is flushed out to oldpage. It invokes another memory fault and COW break. (I think that this memory fault is unhealthy.) Then, new value goes to x on oldpage (when it's physically tagged cache). A-2 sleeps. (7) Child process B is waken up. When it accesses at x, it sees new value suddenly. If we flush cache to oldpage at ptep_set_wrprotect, this couldn't occur. * * * I know that we should not do threads and fork. It is difficult to define clean semantics. Because another thread may touch memory while a thread which does memory copy for fork, the memory what the child process will see may be inconsistent. For the child, a page might be new, while another page might be old. For VIVT-WB cache machine, I am considering a possibility for the child process to have inconsistent memory even within a single page (when we have no flush at ptep_set_wrprotect). It will be needed for me to talk to linux-arch soon or later. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: threads and fork on machine with VIPT-WB cache
On Sun, 2010-04-04 at 22:51 -0400, John David Anglin wrote:
Thanks a lot for the discussion.
James Bottomley wrote:
So your theory is that the data the kernel sees doing the page copy can
be stale because of dirty cache lines in userspace (which is certainly
possible in the ordinary way)?
Yes.
By design that shouldn't happen: the idea behind COW breaking is
that before it breaks, the page is read only ... this means that
processes can have clean cache copies of it, but never dirty cache
copies (because writes are forbidden).
That must be design, I agree.
To keep this condition (no dirty cache for COW page), we need to flush
cache before ptep_set_wrprotect. That's my point.
Please look at the code path:
(kernel/fork.c)
do_fork - copy_process - copy_mm - dup_mm - dup_mmap -
(mm/memory.c)
copy_page_range - copy_p*d_range - copy_one_pte - ptep_set_wrprotect
The function flush_cache_dup_mm is called from dup_mmap, that's enough
for a case of a process with single thread.
I think that:
We need to flush cache before ptep_set_wrprotect for a process with
multiple threads. Other threads may change memory after a thread
invokes do_fork and before calling ptep_set_wrprotect. Specifically,
a process may sleep at pte_alloc function to get a page.
I agree. It is interesting that in the case of the Debian bug that
a thread of the parent process causes the COW break and thereby corrupts
its own memory. As far as I can tell, the fork'd child never writes
to the memory that causes the fault.
My testing indicates that your suggested change fixes the Debian
bug. I've attached below my latest test version. This seems to fix
the bug on both SMP and UP kernels.
However, it doesn't fix all page/cache related issues on parisc
SMP kernels that I commonly see.
My first inclination after even before reading your analysis was
to assume that copy_user_page was broken (i.e, that even if a
processor cache was dirty when the COW page was write protected,
it should be possible to do the flush before the page is copied).
However, this didn't seem to work... Possibly, there are issues
with aliased addresses.
I note that sparc flushes the entire cache and purges the entire
tlb in kmap_atomic/kunmap_atomic for highmem. Although the breakage
that I see is not limited to PA8800/PA8900, I'm not convinced
that we maintain coherency that is required for these processors
in copy_user_page when we have multiple threads.
As a side note, kmap_atomic/kunmap_atomic seem to lack calls to
pagefault_disable()/pagefault_enable() on PA8800.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX:
952-6602)
diff --git a/arch/parisc/include/asm/pgtable.h
b/arch/parisc/include/asm/pgtable.h
index a27d2e2..b140d5c 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -14,6 +14,7 @@
#include linux/bitops.h
#include asm/processor.h
#include asm/cache.h
+extern void flush_cache_page(struct vm_area_struct *vma, unsigned long
vmaddr, unsigned long pfn);
/*
* kern_addr_valid(ADDR) tests if ADDR is pointing to valid kernel
@@ -456,17 +457,22 @@ static inline pte_t ptep_get_and_clear(struct mm_struct
*mm, unsigned long addr,
return old_pte;
}
-static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long
addr, pte_t *ptep)
+static inline void ptep_set_wrprotect(struct vm_area_struct *vma, struct
mm_struct *mm, unsigned long addr, pte_t *ptep)
{
#ifdef CONFIG_SMP
unsigned long new, old;
+#endif
+ pte_t old_pte = *ptep;
+
+ if (atomic_read(mm-mm_users) 1)
Just to verify there's nothing this is hiding, can you make this
if (pte_dirty(old_pte))
and reverify? The if clause should only trip on the case where the
parent has dirtied the line between flush and now.
+ flush_cache_page(vma, addr, pte_pfn(old_pte));
+#ifdef CONFIG_SMP
do {
old = pte_val(*ptep);
new = pte_val(pte_wrprotect(__pte (old)));
} while (cmpxchg((unsigned long *) ptep, old, new) != old);
#else
- pte_t old_pte = *ptep;
set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
#endif
}
diff --git a/mm/memory.c b/mm/memory.c
index 09e4b1b..21c2916 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -616,7 +616,7 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct
*src_mm,
* in the parent and the child
*/
if (is_cow_mapping(vm_flags)) {
- ptep_set_wrprotect(src_mm, addr, src_pte);
+ ptep_set_wrprotect(vma, src_mm, addr, src_pte);
So this is going to be a hard sell because of the arch churn. There are,
however, three ways to do it with the original signature.
1. implement copy_user_highpage ... this allows us
Bug#561203: threads and fork on machine with VIPT-WB cache
On Fri, 2010-04-02 at 12:48 +0900, NIIBE Yutaka wrote: Thanks for your quick reply. James Bottomley wrote: In COW breaking, the page table entry is copied, so A and B no longer have page table entries at the same physical location. If the COW is intact, A and B have the same physical page, but it's also accessed by the same virtual address, hence no aliasing. Let me explain more. In the scenario, I assume: No aliasing between A and B. We have aliasing between kernel access and user access. Before COW breaking A and B share same data (with no aliasing same space identifier color), and B sees data in cache, while memory has stale data. At COW breaking, kernel copies the memory, it doesn't see new data in cache because of aliasing. Isn't it possible? So your theory is that the data the kernel sees doing the page copy can be stale because of dirty cache lines in userspace (which is certainly possible in the ordinary way)? By design that shouldn't happen: the idea behind COW breaking is that before it breaks, the page is read only ... this means that processes can have clean cache copies of it, but never dirty cache copies (because writes are forbidden). As soon as one or other process tries to write to the page, it gets a memory protection trap long before the data it's trying to write goes into the cache. By the time the write is allowed to complete (and the cache becomes dirty), the process will have the new copy of the page which belongs exclusively to it. James -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: threads and fork on machine with VIPT-WB cache
On Fri, 2010-04-02 at 11:41 +0900, NIIBE Yutaka wrote: (9) Process B does read-access on memory, which gets *NEW* data in cache (if process space identifier color is same). Process B does write-access on memory which causes memory fault, as it's COW memory. Note: Process B sees *NEW* data because it's VIPT-WB cache. It shares same memory in this situation. So I think the bug here is that you're confusing aliasing with SMP cache coherence. In an alias situation, the same physical line is mapped to multiple lines in a processor's cache (at different virtual addresses), which means you can get a different answer depending on which alias you read. In COW breaking, the page table entry is copied, so A and B no longer have page table entries at the same physical location. If the COW is intact, A and B have the same physical page, but it's also accessed by the same virtual address, hence no aliasing. In an SMP incoherent system, A and B could get different results (if on different CPUs) because the write protect is in the cache of A but not B. However, PA is SMP coherent, so the act of B reading a line which is dirty in A's cache causes a flush before the read completes via the cache chequerboard logic and B ends up reading the same value A would have read. James -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558999: FTBFS [hppa] - recompile with -ffunction-sections
I am not very good at GCC optimizations. Can you please explain why this problem is not seen on other architectures? Also can you please advise if I should add this compiler option for all arch or just hppa. It's not really a gcc problem, it's an ELF one. The ELF spec for HPPA says that we need to leave symbol resolution as a relative jump. On parisc 32 bits, this is a 17bit relative jump. We can do longer by indirecting through a stub section. However, this problem usually occurs because the actual text section of the .o file is bigger than 131k (about 17 bits) and so the linker can't insert a reachable stub into the binary. -ffunction-sections splits the text section up into one section per function, so now the linker can insert the stubs in between the functions and thus the problem is solved (until a single function gets longer than 131k). Most other architectures have bigger relative jumps, so they likely won't need -ffunction-sections (unless the file you're compiling gets much bigger). James -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519707: Upgrade to new version of postgrey fails to start with FATAL: ERROR: ...
On Sun, 2009-09-06 at 12:06 +0100, Antonio Radici wrote: thanks for your report, I wrote a preinst script which is running a db4.7_upgrade if we are upgrading from a version less than 1.31-1. That sounds like a good fix, thanks. This is fixed in the git repo in collab-maint and it will be included in the next release. Unfortunately, since I've already done this on my box, I don't really have any way to test. James -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545229: linux-image-2.6.30-1-parisc: panic on boot
Package: linux-image-2.6.30-1-parisc Version: 2.6.30-6 Severity: critical Tags: patch Justification: breaks the whole system -- Package-specific info: -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (500, 'stable') Architecture: hppa (parisc) Kernel: Linux 2.6.26-2-parisc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.30-1-parisc depends on: ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii initramfs-tools [linux-initra 0.93.4 tools for generating an initramfs ii module-init-tools 3.10-3 tools for managing Linux kernel mo linux-image-2.6.30-1-parisc recommends no packages. Versions of packages linux-image-2.6.30-1-parisc suggests: pn linux-doc-2.6.30 none (no description available) ii palo 1.16+nmu1 Linux boot loader for parisc/hppa -- debconf information: linux-image-2.6.30-1-parisc/postinst/kimage-is-a-directory: linux-image-2.6.30-1-parisc/postinst/old-initrd-link-2.6.30-1-parisc: true linux-image-2.6.30-1-parisc/preinst/lilo-has-ramdisk: linux-image-2.6.30-1-parisc/preinst/abort-overwrite-2.6.30-1-parisc: linux-image-2.6.30-1-parisc/postinst/old-system-map-link-2.6.30-1-parisc: true linux-image-2.6.30-1-parisc/preinst/failed-to-move-modules-2.6.30-1-parisc: linux-image-2.6.30-1-parisc/prerm/removing-running-kernel-2.6.30-1-parisc: true linux-image-2.6.30-1-parisc/postinst/bootloader-test-error-2.6.30-1-parisc: linux-image-2.6.30-1-parisc/postinst/create-kimage-link-2.6.30-1-parisc: true linux-image-2.6.30-1-parisc/postinst/depmod-error-initrd-2.6.30-1-parisc: false shared/kernel-image/really-run-bootloader: true linux-image-2.6.30-1-parisc/preinst/lilo-initrd-2.6.30-1-parisc: true linux-image-2.6.30-1-parisc/postinst/old-dir-initrd-link-2.6.30-1-parisc: true linux-image-2.6.30-1-parisc/preinst/elilo-initrd-2.6.30-1-parisc: true linux-image-2.6.30-1-parisc/preinst/overwriting-modules-2.6.30-1-parisc: true linux-image-2.6.30-1-parisc/preinst/abort-install-2.6.30-1-parisc: linux-image-2.6.30-1-parisc/postinst/bootloader-error-2.6.30-1-parisc: linux-image-2.6.30-1-parisc/preinst/bootloader-initrd-2.6.30-1-parisc: true linux-image-2.6.30-1-parisc/postinst/depmod-error-2.6.30-1-parisc: false linux-image-2.6.30-1-parisc/preinst/initrd-2.6.30-1-parisc: linux-image-2.6.30-1-parisc/prerm/would-invalidate-boot-loader-2.6.30-1-parisc: true --- All current debian 2.6.30-1 kernels panic on boot on parisc systems when loading the initial modules. Problem is actually caused by binutils outputting duplicate .text section names. However, this trips a panic on boot because kernel/modules.c has insufficient error checking for this case Patches to fix this are From 1b364bf438cf337a3818aee77d68c0713f3e1fc4 Mon Sep 17 00:00:00 2001 From: James Bottomley james.bottom...@hansenpartnership.com Date: Wed, 26 Aug 2009 22:04:12 +0930 Subject: module: workaround duplicate section names and to fix up that patch From ea6bff368548d79529421a9dc0710fc5330eb504 Mon Sep 17 00:00:00 2001 From: Ingo Molnar mi...@elte.hu Date: Fri, 28 Aug 2009 10:44:56 +0200 Subject: modules: Fix build error in the !CONFIG_KALLSYMS case From 1b364bf438cf337a3818aee77d68c0713f3e1fc4 Mon Sep 17 00:00:00 2001 From: James Bottomley james.bottom...@hansenpartnership.com Date: Wed, 26 Aug 2009 22:04:12 +0930 Subject: module: workaround duplicate section names The root cause is a duplicate section name (.text); is this legal? [ Amerigo Wang: AFAIK, yes. ] However, there's a problem with commit 6d76013381ed28979cd122eb4b249a88b5e384fa in that if you fail to allocate a mod-sect_attrs (in this case it's null because of the duplication), it still gets used without checking in add_notes_attrs() This should fix it [ This patch leaves other problems, particularly the sections directory, but recent parisc toolchains seem to produce these modules and this prevents a crash and is a minimal change -- RR ] Signed-off-by: James Bottomley james.bottom...@suse.de Signed-off-by: Rusty Russell ru...@rustcorp.com.au Tested-by: Helge Deller del...@gmx.de Signed-off-by: Linus Torvalds torva...@linux-foundation.org --- kernel/module.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index 07c80e6..eccb561 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2355,7 +2355,8 @@ static noinline struct module *load_module(void __user *umod, if (err 0) goto unlink; add_sect_attrs(mod, hdr-e_shnum, secstrings, sechdrs); - add_notes_attrs(mod, hdr-e_shnum, secstrings, sechdrs); + if (mod-sect_attrs) + add_notes_attrs(mod, hdr-e_shnum, secstrings, sechdrs); /* Get rid of temporary copy */ vfree(hdr); -- 1.6.0.2
Bug#541702: linux-image-2.6.30-1-686: Kernel fails to start networking because no e100 firmware
On Sat, 2009-08-15 at 19:21 +0100, Ben Hutchings wrote: On Sat, 2009-08-15 at 10:47 -0700, james.bottom...@hansenpartnership.com wrote: Package: linux-image-2.6.30-1-686 Version: 2.6.30-5 Severity: serious Justification: Policy 2.2.1 That very same section explains why we cannot do what you are suggesting! No, it doesn't ... the decision to put firmware-linux in non-free is obviously wrong, since the same firmware was shipped as is in main with 2.6.26-2 On upgrade from 2.6.30-2-686 networking (on a remote machine) failed to start, meaning that a support ticket had to be opened for KVM access. I don't recommend running unstable on production machines. If you bother to read the bug report, you'd see it's actually running testing. Diagnosis revealed that the e100 driver in 2.6.26-2-686 required no firmware, so the firmware-linux package wasn't installed. Apparently 2.6.30-1-686 was built with external firmware for the e100 so it now depends on the firmware-linux package. This is a serious policy violation because required hardware stops working after the upgrade. No, most systems do not require the firmware-linux package. That's not really relevant, is it? linux-image ships with a ton of drivers most systems don't use as well. The point is that what was working before the upgrade didn't work after it. Fix suggested is to make 2.6.30-1-686 depend on linux-firmware so that on upgrade the necessary firmware is present. I intend to ensure that firmware-linux is mentioned in the release notes for squeeze, but it cannot be recommended or made a dependency. So this amounts to ... assuming the user can find the notice (because there's a blizzard of notices that go with each upgrade, particularly if they're going from lenny - squeeze) you'll tell them that you broke their system? The point here is to try and ensure large numbers of systems don't break before this exits testing for stable. James -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541702: linux-image-2.6.30-1-686: Kernel fails to start networking because no e100 firmware
OK, so lets go back to basics here. The point of a bug report is to report a bug. The Bug here is that large numbers of systems will break on upgrade to this kernel once it hits stable. This is the problem that needs fixing. The fact that you find the suggested fix politically incorrect, or that you don't think I should have been able to find the bug in the first place are irrelevant to the fact that the bug exists. Apart from being appallingly bad release practice, breaking a significant fraction of users on an upgrade is also a debian policy violation as I've cited (the package is too buggy to release because of all the breakage). Trying to describe this as fixed because you'll put it in the release notes is wrong in principle because it doesn't prevent the existing users from suffering breakage a priori. A pre upgrade script that detected the problem based on the runtime detection that the user needed modules with firmware now in firmware-linux would be acceptable. Just stop, print the warning and allow them to OK or cancel. The list of modules now requiring firmware surely isn't non-free and it can be derived from the linux build system fairly easily. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519707: Upgrade to new version of postgrey fails to start with FATAL: ERROR: ...
Package: postgrey Version: 1.32-3 Severity: serious Justification: Policy 2.2.1 makes package to buggy to release This looks to be an incidental fault affecting postgrey, but the serious consequence is that postgrey refuses to start. What seems to have happened is that on the recent system upgrade libberkeleydb-perl (a package upon which postgrey relies) was upgraded to version 0.38-1. This version moved from db4.6 to db4.7, which seem to be mutually incompatible formats causing postgrey to fail instantly with postgrey: FATAL: ERROR: can't create DB environment: No such file or directory (dbdir: /var/lib/postgrey uid/gid: 121,121) because it can no longer read the database files in /var/lib/postgrey The only solution to this appears to be to dump the postgrey databases before the upgrade and to reform them after (or simply to remove all the old files losing the accumulated data). I'm open to this being a severe bug in libberkeleydb-perl either since it is the root cause, but I think posgrey will still have to acquire the dump and restore package scripts to fix it. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (500, 'stable') Architecture: hppa (parisc) Kernel: Linux 2.6.26-1-parisc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages postgrey depends on: ii adduser 3.110 add and remove users and groups ii debconf 1.5.25 Debian configuration management sy ii libberkeleydb-perl0.38-1 use Berkeley DB 4 databases from P ii libnet-dns-perl 0.65-1 Perform DNS queries from a Perl sc ii libnet-server-perl0.97-1 An extensible, general perl server ii perl 5.10.0-19 Larry Wall's Practical Extraction ii ucf 3.0016 Update Configuration File: preserv Versions of packages postgrey recommends: ii libdigest-sha1-perl 2.11-2+b1 NIST SHA-1 message digest algorith ii libnet-rblclient-perl 0.5-2 Queries multiple Realtime Blackhol ii libparse-syslog-perl 1.10-1 Perl module for parsing syslog ent ii postfix 2.5.5-1.1 High-performance mail transport ag postgrey suggests no packages. -- debconf information: postgrey/1.32-3_changeport: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#479612: after upgrade to spandsp 0.0.4pre18 asterisk-app-fax crashes asterisk
Package: asterisk-app-fax Version: 0.0.20070624-1 Severity: critical Justification: causes serious data loss Apparently the dependency of asterisk-spandsp-plugins and spandsp-dev is pretty tight. It looks like there was a binary incompatible change introduced by the upgrade from 0.0.4pre16 to 0.0.4pre18 I verified that asterisk crashes every time a fax is received after the upgrade Recompiling asterisk-spandsp-plugins_0.0.20070624-1 and reinstalling makes the crash go away. It looks like theres a compiled version in unstable that will go through to testing in 10 days and fix the problem The net of this bug report is that either these packages need to be tied together, or the so version of spandsp needs increasing for every change (because in the pre stage the ABI is obviously not stable) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages asterisk-app-fax depends on: ii asterisk 1:1.4.18.1~dfsg-1 Open Source Private Branch Exchang ii libc6 2.7-10GNU C Library: Shared libraries ii libspandsp30.0.4pre18-1 Telephony signal processing librar Versions of packages asterisk-app-fax recommends: ii gs-common 0.3.13-0.1 Common files for different Ghostsc ii libconfig-tiny-perl 2.12-1 Read/Write .ini style files with a ii libfile-sync-perl 0.09-4 Perl interface to sync() and fsync ii liblocale-gettext-perl1.05-3 Using libc functions for internati ii libmime-lite-perl 3.021-3Perl5 module for convenient genera ii libpaper-utils1.1.23 library for handling paper charact ii libtiff-tools 3.8.2-8TIFF manipulation and conversion t ii psutils 1.17-24A collection of PostScript documen -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479612: after upgrade to spandsp 0.0.4pre18 asterisk-app-fax crashes asterisk
On Mon, 2008-05-05 at 21:47 +0300, Tzafrir Cohen wrote: On Mon, May 05, 2008 at 01:13:40PM -0500, James Bottomley wrote: Package: asterisk-app-fax Version: 0.0.20070624-1 Severity: critical Justification: causes serious data loss Apparently the dependency of asterisk-spandsp-plugins and spandsp-dev is pretty tight. It looks like there was a binary incompatible change introduced by the upgrade from 0.0.4pre16 to 0.0.4pre18 I verified that asterisk crashes every time a fax is received after the upgrade Recompiling asterisk-spandsp-plugins_0.0.20070624-1 and reinstalling makes the crash go away. The net of this bug report is that either these packages need to be tied together, or the so version of spandsp needs increasing for every change (because in the pre stage the ABI is obviously not stable) A new version was uploaded just today. 0.0.20070624-2 . It was aparantly built against a newer spandsp. Does it fix this issue for you? I think it will, that's why I wrote It looks like theres a compiled version in unstable that will go through to testing in 10 days and fix the problem But I'd have to do an upgrade on the running system to check that, which means not until tomorrow. James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479612: after upgrade to spandsp 0.0.4pre18 asterisk-app-fax crashes asterisk
On Mon, 2008-05-05 at 21:30 +0300, Faidon Liambotis wrote: James Bottomley wrote: Apparently the dependency of asterisk-spandsp-plugins and spandsp-dev is pretty tight. It looks like there was a binary incompatible change introduced by the upgrade from 0.0.4pre16 to 0.0.4pre18 I verified that asterisk crashes every time a fax is received after the upgrade Recompiling asterisk-spandsp-plugins_0.0.20070624-1 and reinstalling makes the crash go away. It looks like theres a compiled version in unstable that will go through to testing in 10 days and fix the problem The net of this bug report is that either these packages need to be tied together, or the so version of spandsp needs increasing for every change (because in the pre stage the ABI is obviously not stable) It's been a while since I used app-fax -- therefore, help maintaining it is welcome. Are you certain that the crash is because of a spandsp ABI change and not because of an asterisk ABI change? We've had one of those as well :( Yes ... because 1. There was no asterisk update in the last apt-get update on Saturday 2. recompiling sterisk-spandsp-plugins_0.0.20070624-1 with the new libspandsp-dev fixes the problem (as I said). James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476285: linux-image-2.6.24-1-parisc: panics on boot in cmpxchg_futex_value_locked
Package: linux-image-2.6.24-1-parisc Version: 2.6.24-5 Severity: critical Tags: patch Justification: breaks the whole system This actually isn't just a bug in debian, it affects every distro which uses the stable tree as a base for instance, the gentoo bug is here: http://bugs.gentoo.org/show_bug.cgi?id=217030 The panic is: backtrace: [10587970] init+0x20/0xc4 [105807e0] kernel_init+0xf4/0x328 [10109c5c] ret_from_kernel_thread+0x1c/0x24 Kernel Fault: Code=26 regs=8fc241c0 (Addr=) YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI PSW: 0100 Not tainted r00-03 0004ff0f 104fc140 10587970 f0412000 r04-07 105b57c0 r08-11 1059b810 105b5810 104c3810 r12-15 10568810 1059b810 8fc24088 3b9aca00 r16-19 f8c4 f17c f174 r20-23 4000 07ff 10587950 0001 r24-27 104c6010 r28-31 8fc24000 c99f4bdd 8fc241c0 105807e0 sr00-03 sr04-07 IASQ: IAOQ: 101433b8 101433bc IIR: 0f401089ISR: IOR: CPU:0 CR30: 8fc24000 CR31: ORIG_R28: IAOQ[0]: cmpxchg_futex_value_locked+0x28/0x9c IAOQ[1]: cmpxchg_futex_value_locked+0x2c/0x9c RP(r2): init+0x20/0xc4 Kernel panic - not syncing: Kernel Fault The root cause is a backport of this commit: commit a0c1e9073ef7428a14309cba010633a6cd6719ea Author: Thomas Gleixner [EMAIL PROTECTED] Date: Sat Feb 23 15:23:57 2008 -0800 futex: runtime enable pi and robust functionality To the stable tree (went in for 2.6.24.4). This breaks parisc because we weren't set up to process NULL as a futex cmpxchg address. We found and fixed the bug upstream as: commit c20a84c91048c76c1379011c96b1a5cee5c7d9a0 Author: Kyle McMartin [EMAIL PROTECTED] Date: Sat Mar 1 10:25:52 2008 -0800 [PARISC] futex: special case cmpxchg NULL in kernel space but, because we didn't know tglx had requested a backport, the fix wasn't backported to stable. I'll send the necessary patch into stable, but to get parisc working again on debian it has to be applied on top of the current kernel. NOTE: This bug was introduced into 2.6.24.4; 2.6.24.3 doesn't have it. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (650, 'testing') Architecture: hppa (parisc) Kernel: Linux 2.6.22-3-parisc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.24-1-parisc depends on: ii debconf [debconf-2.0]1.5.20 Debian configuration management sy ii initramfs-tools [linux-initr 0.91e tools for generating an initramfs ii module-init-tools3.3-pre11-4 tools for managing Linux kernel mo linux-image-2.6.24-1-parisc recommends no packages. -- debconf information excluded *** parisc-cmpxchg-fix.diff From c8d402df60b3aad85b30cfe7df20f829ef6eb895 Mon Sep 17 00:00:00 2001 From: Kyle McMartin [EMAIL PROTECTED] Date: Sat, 1 Mar 2008 10:25:52 -0800 Subject: [PARISC] futex: special case cmpxchg NULL in kernel space Commit a0c1e9073ef7428a14309cba010633a6cd6719ea added code to futex.c to detect whether futex_atomic_cmpxchg_inatomic was implemented at run time: + curval = cmpxchg_futex_value_locked(NULL, 0, 0); + if (curval == -EFAULT) + futex_cmpxchg_enabled = 1; This is bogus on parisc, since page zero in kernel virtual space is the gateway page for syscall entry, and should not be read from the kernel. (That, and we really don't like the kernel faulting on its own address space...) Signed-off-by: Kyle McMartin [EMAIL PROTECTED] --- include/asm-parisc/futex.h | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/asm-parisc/futex.h b/include/asm-parisc/futex.h index dbee6e6..fdc6d05 100644 --- a/include/asm-parisc/futex.h +++ b/include/asm-parisc/futex.h @@ -56,6 +56,12 @@ futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval) int err = 0; int uval; + /* futex.c wants to do a cmpxchg_inatomic on kernel NULL, which is +* our gateway page, and causes no end of trouble... +*/ + if (segment_eq(KERNEL_DS, get_fs()) !uaddr) + return -EFAULT; + if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int))) return -EFAULT; @@ -67,5 +73,5 @@ futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval) return uval; } -#endif -#endif +#endif /*__KERNEL__*/ +#endif /*_ASM_PARISC_FUTEX_H*/ -- 1.5.3.8 -- To
Bug#476292: linux-image-2.6.24-1-parisc64: 64 bit kernel panics on boot in handle_interruption
Package: linux-image-2.6.24-1-parisc64 Version: 2.6.24-5 Severity: critical Tags: patch Justification: breaks the whole system The parisc 64 bit kernel panics on boot with this: CC net/ipv4/netfilter/iptable_raw.mod.o CC net/ipv4/tcp_diag.mod.o CC net/ipv4/tunnel4.mod.o CC net/ipv4/xfrm4_mode_beet.mod.o CC net/ipv4/xfrm4_tunnel.mod.o CC net/key/af_key.mod.o CC net/llc/llc.mod.o CC net/llc/llc2.mod.o CC net/netfilter/nfnetlink_log.mod.o CC net/netfilter/nfnetlink.mod.o CC net/netfilter/nfnetlink_queue.mod.o CC net/netfilter/xt_CLASSIFY.mod.o CC net/netfilter/x_tables.mod.o CC net/netfilter/xt_DSCP.mod.o CC net/netfilter/xt_MARK.mod.o CC net/netfilter/xt_NFQUEUE.mod.o CC net/netfilter/xt_comment.mod.o CC net/netfilter/xt_dccp.mod.o CC net/netfilter/xt_dscp.mod.o CC net/netfilter/xt_esp.mod.o CC net/netfilter/xt_length.mod.o CC net/netfilter/xt_limit.mod.o CC net/netfilter/xt_mac.mod.o CC net/netfilter/xt_mark.mod.o CC net/netfilter/xt_multiport.mod.o CC net/netfilter/xt_pkttype.mod.o CC net/netfilter/xt_policy.mod.o CC net/netfilter/xt_realm.mod.o CC net/netfilter/xt_sctp.mod.o CC net/netfilter/xt_string.mod.o CC net/netfilter/xt_tcpmss.mod.o CC net/netfilter/xt_tcpudp.mod.o CC net/packet/af_packet.mod.o CC net/sctp/sctp.mod.o CC net/sunrpc/auth_gss/auth_rpcgss.mod.o CC net/sunrpc/auth_gss/rpcsec_gss_krb5.mod.o CC net/sunrpc/auth_gss/rpcsec_gss_spkm3.mod.o CC net/sunrpc/sunrpc.mod.o CC net/tipc/tipc.mod.o CC net/xfrm/xfrm_user.mod.o CC sound/ac97_bus.mod.o CC sound/core/oss/snd-mixer-oss.mod.o CC sound/core/oss/snd-pcm-oss.mod.o CC sound/core/seq/oss/snd-seq-oss.mod.o CC sound/core/seq/snd-seq-device.mod.o CC sound/core/seq/snd-seq-dummy.mod.o CC sound/core/seq/snd-seq-midi-event.mod.o CC sound/core/seq/snd-seq-midi.mod.o CC sound/core/seq/snd-seq.mod.o CC sound/core/snd-hwdep.mod.o CC sound/core/snd-page-alloc.mod.o CC sound/core/snd-pcm.mod.o CC sound/core/snd-rawmidi.mod.o CC sound/core/snd-timer.mod.o CC sound/core/snd.mod.o CC sound/parisc/snd-harmony.mod.o CC sound/pci/ac97/snd-ac97-codec.mod.o CC sound/pci/rme9652/snd-hdspm.mod.o CC sound/pci/snd-ad1889.mod.o LD [M] crypto/aes_generic.ko CC sound/soundcore.mod.o LD [M] crypto/anubis.ko LD [M] crypto/arc4.ko LD [M] crypto/blkcipher.ko LD [M] crypto/blowfish.ko LD [M] crypto/cast5.ko LD [M] crypto/cast6.ko LD [M] crypto/cbc.ko LD [M] crypto/crc32c.ko LD [M] crypto/crypto_null.ko LD [M] crypto/deflate.ko LD [M] crypto/des_generic.ko LD [M] crypto/ecb.ko LD [M] crypto/khazad.ko LD [M] crypto/gf128mul.ko LD [M] crypto/md4.ko LD [M] crypto/md5.ko LD [M] crypto/michael_mic.ko LD [M] crypto/serpent.ko LD [M] crypto/sha256_generic.ko LD [M] crypto/sha512.ko LD [M] crypto/tcrypt.ko LD [M] crypto/tea.ko LD [M] crypto/tgr192.ko LD [M] crypto/twofish.ko LD [M] crypto/twofish_common.ko LD [M] crypto/wp512.ko LD [M] drivers/base/firmware_class.ko LD [M] drivers/block/aoe/aoe.ko LD [M] drivers/block/cryptoloop.ko LD [M] drivers/block/loop.ko LD [M] drivers/block/pktcdvd.ko LD [M] drivers/block/sx8.ko LD [M] drivers/block/ub.ko LD [M] drivers/block/umem.ko LD [M] drivers/cdrom/cdrom.ko LD [M] drivers/char/lp.ko LD [M] drivers/char/agp/parisc-agp.ko LD [M] drivers/char/raw.ko LD [M] drivers/hid/usbhid/usbhid.ko LD [M] drivers/input/keyboard/hil_kbd.ko LD [M] drivers/input/keyboard/hilkbd.ko LD [M] drivers/input/misc/hp_sdc_rtc.ko LD [M] drivers/input/misc/uinput.ko LD [M] drivers/input/mouse/hil_ptr.ko LD [M] drivers/input/mouse/psmouse.ko LD [M] drivers/input/mouse/sermouse.ko LD [M] drivers/input/serio/parkbd.ko LD [M] drivers/input/serio/pcips2.ko LD [M] drivers/input/serio/serio_raw.ko LD [M] drivers/md/dm-crypt.ko LD [M] drivers/input/serio/serport.ko LD [M] drivers/md/dm-emc.ko LD [M] drivers/md/dm-mirror.ko LD [M] drivers/md/dm-mod.ko LD [M] drivers/md/dm-multipath.ko LD [M] drivers/md/dm-round-robin.ko LD [M] drivers/md/dm-snapshot.ko LD [M] drivers/md/dm-zero.ko LD [M] drivers/md/faulty.ko LD [M] drivers/md/linear.ko LD [M] drivers/md/md-mod.ko LD [M] drivers/md/multipath.ko LD [M] drivers/md/raid1.ko LD [M] drivers/md/raid0.ko LD [M] drivers/md/raid10.ko LD [M] drivers/message/fusion/mptbase.ko LD [M] drivers/message/fusion/mptctl.ko LD [M] drivers/message/fusion/mptfc.ko LD [M] drivers/message/fusion/mptsas.ko LD [M] drivers/message/fusion/mptscsih.ko LD [M] drivers/message/fusion/mptspi.ko LD [M] drivers/net/3c59x.ko LD [M]
