Processed: Re: Bug#605003: loss of data
Processing commands for cont...@bugs.debian.org: > reassign 605003 linux-2.6 Bug #605003 [kernel] loss of data Warning: Unknown package 'kernel' Bug reassigned from package 'kernel' to 'linux-2.6'. > -- Stopping processing here. Please contact me if you need assistance. -- 605003: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605003 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.129076286620014.transcr...@bugs.debian.org
Bug#605003: loss of data
Package: kernel Severity: critical It appears that after doing some heavy compiling and filling up the entire filesystem, my xchat settings completely vanished when i decided to reuse it. (decided to clear out all the made up object files and have XX megs space free). I was stunned to see "zero" network lists to select on an irc connection dialog startup box.. I remember reading about a patch for a filesystem routine about applications accessing file read/write operations-- not sure if which library exactly does this.. so i'm posting about this loss of data.. it may just be xchat but I have suspicions that it isn't.. thanks for the good work.. * -- System Information: Debian Release: 5.0.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/3 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20101126043607.4666.79933.report...@acerm1201deb
Bug#604977: marked as done (tech-ctte: bluetooth adapter ar3011 on acer aspire 5553g don't start after shutdown)
Your message dated Fri, 26 Nov 2010 10:57:02 +
with message-id <19695.37502.538943.175...@chiark.greenend.org.uk>
and subject line Re: Bug#604977: tech-ctte: bluetooth adapter ar3011 on acer
aspire 5553g don't start after shutdown
has caused the Debian Bug report #604977,
regarding tech-ctte: bluetooth adapter ar3011 on acer aspire 5553g don't start
after shutdown
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.)
--
604977: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604977
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal
I am using Debian testing with latest updates installed. I have a atheros
ar3011 bluetooth adapter on my laptop. The problem is next, when i shutdown my
laptop and on first boot choose to run debian my adapter don't start. To get my
adapter working i have to boot into my windows 7 second system and then reboot
to debian. This steps allow me to use bluetooth untill next shutdown. When my
adapter is unavailable i get empty output from 'hcitool dev' command.
Nevertheless the output by 'lsusb' is this:
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 0cf3:3002 Atheros Communications, Inc.
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0402:9665 ALi Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub.
Here is my adapter on Bus 004. But system can't start it.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Sergey Chepurko writes ("Bug#604977: tech-ctte: bluetooth adapter ar3011 on
acer aspire 5553g don't start after shutdown"):
> Package: tech-ctte
> Severity: normal
Please do not report bugs directly to the TC.
Ian.
--- End Message ---
Bug#604979: marked as done (tech-ctte: Acer Aspire 5553g fails to resume after hibernate)
Your message dated Fri, 26 Nov 2010 10:57:16 +
with message-id <19695.37516.531017.182...@chiark.greenend.org.uk>
and subject line Re: Bug#604979: tech-ctte: Acer Aspire 5553g fails to resume
after hibernate
has caused the Debian Bug report #604979,
regarding tech-ctte: Acer Aspire 5553g fails to resume after hibernate
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.)
--
604979: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604979
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal
When i use hibernate mode on my laptop Acer Aspire 5553g with closing my
notebook i cant resume the session when open it later. It simply freezes. All i
can do is force shut down using 5 sec press power button. There no other key is
responsing.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Sergey Chepurko writes ("Bug#604979: tech-ctte: Acer Aspire 5553g fails to
resume after hibernate"):
> Package: tech-ctte
> Severity: normal
>
> When i use hibernate mode on my laptop Acer Aspire 5553g with closing my
> notebook i cant resume the session when open it later. It simply freezes. All
> i
> can do is force shut down using 5 sec press power button. There no other key
> is
> responsing.
Please do not report bugs directly to the TC.
Ian.
--- End Message ---
Re: Processed: reassign 604977 to linux-2.6, reassign 604979 to linux-2.6
Debian Bug Tracking System writes ("Processed: reassign 604977 to linux-2.6,
reassign 604979 to linux-2.6"):
> Processing commands for cont...@bugs.debian.org:
Hrm, I see you reassigned them. I closed them, basically on the
thesis that the odds of being able to turn a report from this
submitter into an improvement to the software will be low. But
perhaps I should have left that decision to the kernel maintainers.
Ian.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/19695.37831.487024.871...@chiark.greenend.org.uk
kernel-handbook_1.0.9_i386.changes ACCEPTED into unstable
Accepted: debian-kernel-handbook_1.0.9_all.deb to main/k/kernel-handbook/debian-kernel-handbook_1.0.9_all.deb kernel-handbook_1.0.9.dsc to main/k/kernel-handbook/kernel-handbook_1.0.9.dsc kernel-handbook_1.0.9.tar.gz to main/k/kernel-handbook/kernel-handbook_1.0.9.tar.gz Override entries for your package: debian-kernel-handbook_1.0.9_all.deb - extra doc kernel-handbook_1.0.9.dsc - source doc Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 604713 Thank you for your contribution to Debian. -- 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/e1plx0g-x2...@franck.debian.org
Processed: reassign 605003 to xchat
Processing commands for cont...@bugs.debian.org: > reassign 605003 xchat Bug #605003 [linux-2.6] loss of data Bug reassigned from package 'linux-2.6' to 'xchat'. > thanks Stopping processing here. Please contact me if you need assistance. -- 605003: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605003 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.129077715724946.transcr...@bugs.debian.org
Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888
I've just tested 2.6.32-28 from latest iso and it still doesn't work. The version of this driver included in experimental is reported to work on other distribution (0.17). If you'd point me to some RTFM to help you test something that could give some more chance to add support to these controller in the upcoming stable I'd try to help. thanks -- 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/20101126131806.ga30...@webthatworks.it
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
On Fri, 2010-11-26 at 19:54 +0800, Hayes Wang wrote:
> Correct the binary code (Low pass filter & DLY_CAP fine tune from uC).
> The incorrect ram code would make the nic working abnormally.
[...]
I'm glad you finally acknowledge that this is code rather than simple
register initialisation.
Please can you put the microcontroller firmware under a suitable
licence, if you are not intending to release its source code. The GPL
is not suitable as it requires distributions to provide the source code;
that makes the firmware strictly undistributable at present.
An example licence for binary-only redistribution is:
Copyright
Permission is hereby granted for the distribution of this firmware
data in hexadecimal or equivalent format, provided this copyright
notice is accompanying it.
> Signed-off-by: Hayes Wang
> ---
> drivers/net/r8169.c | 141
> +--
> 1 files changed, 113 insertions(+), 28 deletions(-)
> mode change 100644 => 100755 drivers/net/r8169.c
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> old mode 100644
> new mode 100755
[...]
Also, please don't add execute permission to source files.
Below are the changes Debian currently applies in preparation for proper
licencing of the firmware.
Ben.
---
Subject: [PATCH] r8169: remove firmware for RTL8169D PHY
The recently added support for RTL8169D chips included some machine
code without accompanying source code. Replace this with use of the
firmware loader.
Signed-off-by: Ben Hutchings
---
drivers/net/r8169.c | 717 ---
1 files changed, 44 insertions(+), 673 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 7d33ef4..bfc251a 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1383,6 +1384,23 @@ static void rtl_phy_write(void __iomem *ioaddr, const
struct phy_reg *regs, int
}
}
+struct phy_reg_le {
+ __le16 reg;
+ __le16 val;
+};
+
+static void rtl_phy_write_fw(void __iomem *ioaddr, const struct firmware *fw)
+{
+ const struct phy_reg_le *regs = (const struct phy_reg_le *)fw->data;
+ size_t len = fw->size / sizeof(*regs);
+
+ while (len-- > 0) {
+ mdio_write(ioaddr, le16_to_cpu(regs->reg),
+ le16_to_cpu(regs->val));
+ regs++;
+ }
+}
+
static void rtl8169s_hw_phy_config(void __iomem *ioaddr)
{
static const struct phy_reg phy_reg_init[] = {
@@ -1715,7 +1733,7 @@ static void rtl8168c_4_hw_phy_config(void __iomem *ioaddr)
rtl8168c_3_hw_phy_config(ioaddr);
}
-static void rtl8168d_1_hw_phy_config(void __iomem *ioaddr)
+static void rtl8168d_1_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init_0[] = {
{ 0x1f, 0x0001 },
@@ -1743,361 +1761,8 @@ static void rtl8168d_1_hw_phy_config(void __iomem
*ioaddr)
{ 0x05, 0x8332 },
{ 0x06, 0x5561 }
};
- static const struct phy_reg phy_reg_init_2[] = {
- { 0x1f, 0x0005 },
- { 0x05, 0xffc2 },
- { 0x1f, 0x0005 },
- { 0x05, 0x8000 },
- { 0x06, 0xf8f9 },
- { 0x06, 0xfaef },
- { 0x06, 0x59ee },
- { 0x06, 0xf8ea },
- { 0x06, 0x00ee },
- { 0x06, 0xf8eb },
- { 0x06, 0x00e0 },
- { 0x06, 0xf87c },
- { 0x06, 0xe1f8 },
- { 0x06, 0x7d59 },
- { 0x06, 0x0fef },
- { 0x06, 0x0139 },
- { 0x06, 0x029e },
- { 0x06, 0x06ef },
- { 0x06, 0x1039 },
- { 0x06, 0x089f },
- { 0x06, 0x2aee },
- { 0x06, 0xf8ea },
- { 0x06, 0x00ee },
- { 0x06, 0xf8eb },
- { 0x06, 0x01e0 },
- { 0x06, 0xf87c },
- { 0x06, 0xe1f8 },
- { 0x06, 0x7d58 },
- { 0x06, 0x409e },
- { 0x06, 0x0f39 },
- { 0x06, 0x46aa },
- { 0x06, 0x0bbf },
- { 0x06, 0x8290 },
- { 0x06, 0xd682 },
- { 0x06, 0x9802 },
- { 0x06, 0x014f },
- { 0x06, 0xae09 },
- { 0x06, 0xbf82 },
- { 0x06, 0x98d6 },
- { 0x06, 0x82a0 },
- { 0x06, 0x0201 },
- { 0x06, 0x4fef },
- { 0x06, 0x95fe },
- { 0x06, 0xfdfc },
- { 0x06, 0x05f8 },
- { 0x06, 0xf9fa },
- { 0x06, 0xeef8 },
- { 0x06, 0xea00 },
- { 0x06, 0xeef8 },
- { 0x06, 0xeb00 },
- { 0x06, 0xe2f8 },
- { 0x06, 0x7ce3 },
- { 0x06, 0xf87d },
- { 0x06, 0xa5
Bug#604083: add support for megaraid 9240 9260 9280 8704 8708 8880 8888
Ivan Sergio Borgonovo writes:
> I've just tested 2.6.32-28 from latest iso and it still doesn't work.
> The version of this driver included in experimental is reported to work
> on other distribution (0.17).
>
> If you'd point me to some RTFM to help you test something that could
> give some more chance to add support to these controller in the upcoming
> stable I'd try to help.
A start would be to use the reportbug tool so that the kernel team got
all the relevant data in the bug report, in particular the lspci
listing. Took me a while to finally find a PCI device id to verify
which devices you're after. Finally found it in
http://launchpadlibrarian.net/51569322/Lspci.txt:
01:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS
9240 [1000:0073] (rev 02)
which was added to the driver between v2.6.32..v2.6.33.
commit 879111224d in Linus' tree is the one that actually added the
device to the module alias list. I've included it below. You could try
and see if this is enough, or if the whole driver needs to be updated to
the 2.6.33 version (which is LSI megasas version "00.00.04.12-rc1").
Bjørn
commit 879111224d0784eab623fe8130a1f4481e0e1966
Author: Yang, Bo
Date: Tue Oct 6 14:31:54 2009 -0600
[SCSI] megaraid_sas: Add new megaraid SAS 2 controller support to the driver
Add the new megaraid sas 2 controller to the driver. megaraid sas2 is
LSI next generation SAS products. driver add the interface to support
this product.
Signed-off-by Bo Yang
Signed-off-by: James Bottomley
diff --git a/drivers/scsi/megaraid/megaraid_sas.c b/drivers/scsi/megaraid/megaraid_sas.c
index 0121413..b6e4327 100644
--- a/drivers/scsi/megaraid/megaraid_sas.c
+++ b/drivers/scsi/megaraid/megaraid_sas.c
@@ -76,6 +76,10 @@ static struct pci_device_id megasas_pci_table[] = {
/* gen2*/
{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_SAS0079GEN2)},
/* gen2*/
+ {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_SAS0073SKINNY)},
+ /* skinny*/
+ {PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_SAS0071SKINNY)},
+ /* skinny*/
{PCI_DEVICE(PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_VERDE_ZCR)},
/* xscale IOP, vega */
{PCI_DEVICE(PCI_VENDOR_ID_DELL, PCI_DEVICE_ID_DELL_PERC5)},
@@ -335,6 +339,99 @@ static struct megasas_instance_template megasas_instance_template_ppc = {
};
/**
+ * megasas_enable_intr_skinny - Enables interrupts
+ * @regs: MFI register set
+ */
+static inline void
+megasas_enable_intr_skinny(struct megasas_register_set __iomem *regs)
+{
+ writel(0x, &(regs)->outbound_intr_mask);
+
+ writel(~MFI_SKINNY_ENABLE_INTERRUPT_MASK, &(regs)->outbound_intr_mask);
+
+ /* Dummy readl to force pci flush */
+ readl(®s->outbound_intr_mask);
+}
+
+/**
+ * megasas_disable_intr_skinny - Disables interrupt
+ * @regs: MFI register set
+ */
+static inline void
+megasas_disable_intr_skinny(struct megasas_register_set __iomem *regs)
+{
+ u32 mask = 0x;
+ writel(mask, ®s->outbound_intr_mask);
+ /* Dummy readl to force pci flush */
+ readl(®s->outbound_intr_mask);
+}
+
+/**
+ * megasas_read_fw_status_reg_skinny - returns the current FW status value
+ * @regs: MFI register set
+ */
+static u32
+megasas_read_fw_status_reg_skinny(struct megasas_register_set __iomem *regs)
+{
+ return readl(&(regs)->outbound_scratch_pad);
+}
+
+/**
+ * megasas_clear_interrupt_skinny - Check & clear interrupt
+ * @regs:MFI register set
+ */
+static int
+megasas_clear_intr_skinny(struct megasas_register_set __iomem *regs)
+{
+ u32 status;
+ /*
+ * Check if it is our interrupt
+ */
+ status = readl(®s->outbound_intr_status);
+
+ if (!(status & MFI_SKINNY_ENABLE_INTERRUPT_MASK)) {
+ return 1;
+ }
+
+ /*
+ * Clear the interrupt by writing back the same value
+ */
+ writel(status, ®s->outbound_intr_status);
+
+ /*
+ * dummy read to flush PCI
+ */
+ readl(®s->outbound_intr_status);
+
+ return 0;
+}
+
+/**
+ * megasas_fire_cmd_skinny - Sends command to the FW
+ * @frame_phys_addr : Physical address of cmd
+ * @frame_count : Number of frames for the command
+ * @regs : MFI register set
+ */
+static inline void
+megasas_fire_cmd_skinny(dma_addr_t frame_phys_addr, u32 frame_count,
+ struct megasas_register_set __iomem *regs)
+{
+ writel(0, &(regs)->inbound_high_queue_port);
+ writel((frame_phys_addr | (frame_count<<1))|1,
+ &(regs)->inbound_low_queue_port);
+}
+
+static struct megasas_instance_template megasas_instance_template_skinny = {
+
+ .fire_cmd = megasas_fire_cmd_skinny,
+ .enable_intr = megasas_enable_intr_skinny,
+ .disable_intr = megasas_disable_intr_skinny,
+ .clear_intr = megasas_clear_intr_skinny,
+ .read_fw_status_reg = megasas_read_fw_status_reg_skinny,
+};
+
+
+/**
* The following functions are defined for gen2 (deviceid : 0x78 0x79)
* controllers
*/
@@ -1587,16 +1684,34 @@ megasas_transition_to_ready(struct megasas_instance* instance)
/*
* Set the CLR bit in inbound doorbell
*/
- writel(MFI_INIT_CLEAR_HANDSHAKE|
Re: Bug#605009: serious performance regression with ext4
Hi, adding debian-devel, debian-boot, debian-kernel and Theodore Y. Ts'o in CC because I'm fed up with this problem. Sorry for the massive crosspost, you might want to follow up only on -devel and on the bug report. Some clones/reassign should probably result from this discussion anyway. On Fri, 26 Nov 2010, Michael Biebl wrote: > I'm using ext4 with the default mount option and the fs was created with > the default settings from /etc/mke2fs.conf. > Since the latest upgrade, performance suffered badly. > > E.g. installing vim-runtime took ~8 secs with 1.15.8.5, now it takes > ~44secs. > > It was suggested that I use the nodelalloc mount option for ext4. > But that not only takes away some of the benefits of ext4, it also > requires explicit configuration. > > dpkg should work properly(with good performance) out-of-the-box on ext4. There's currently no way we're going to fix this. It all started with report of corrupted (zero-length) files on ext4/ubifs (see http://bugs.debian.org/430958). We did the right thing to fix this which is to call fsync() on the fly on each file that dpkg unpacks. That was introduced in dpkg 1.15.6. (Ubuntu had more than 80 bug reports related to this and Debian very few because we don't use ext4 by default) That was disastrous in terms of performance, so we then grouped the fsync()+rename() calls at the end of the unpack phase before updating the dpkg database. That can be witnessed in dpkg 1.15.7. That was ok everywhere except on ext4. For some unknown reasons, with the nodelalloc option the performance are again reasonable (but we discovered that only recently). Ubuntu is using ext4 by default and this performance was not acceptable and we tried to work-around the problem by replacing all the fsync() by a single sync() on Linux only (because Linux's sync() is synchronous while it's not necessarily the case on other systems). This was enabled in dpkg 1.15.7.2 in response to http://bugs.debian.org/578635. Now using sync() appears to be a bad choice since it resulted in RC bugs like http://bugs.debian.org/595927 and http://bugs.debian.org/600075 and was an annoyance for people using dpkg on tmpfs to get super-high speed (http://bugs.debian.org/588339). So we reverted that hackish work-around of using sync() and we're back to the situation where dpkg is very slow on ext4. But we have added a new option --force-unsafe-io that can be used when data safety is not important (in a temporary chroot, during initial installation, etc.) as requested in http://bugs.debian.org/584254. Where does that leaves us? Here are various options to consider (they are not necessarily mutually exclusive): 1/ This problem and the known work-arounds should be documented in the release notes. 2/ d-i should be modified to use --force-unsafe-io if it detects a dpkg version >= 1.15.8.6. 3/ d-i might want to setup the nodelalloc option by default when a partition is formatted with ext4 and mounted as / or /usr. 4/ Theodore might want to find out why ext4 is behaving so badly under this usage pattern while ext3 doesn't... i.e. fix https://bugzilla.kernel.org/show_bug.cgi?id=15910 Or at least suggest another usage pattern which result in the same guaranty for dpkg but without the poor performance (and sync() is not the right answer as experience showed us). Note that doing N x fsync() followed by N x rename() is not giving us any better result that doing N x (fsync()+rename()). Note that calling posix_fallocate() before writing the files that are fsynced() did not help either (Mike Hommey thought it could be a way to emulate nodelalloc at the dpkg level only but apparently not). What has not been tried: reordering the fsync() based on FIEMAP information. Or using fdatasync() instead of fsync() and calling fsync() on directories. 5/ maybe the debian-kernel team wants to discuss the issue on LKML. Both for the bad ext4 performances (see above) and the (incorrect?) behaviour of sync() which is never finishing under important I/O loads (cf https://bugzilla.kernel.org/show_bug.cgi?id=18632). But right now from the point of view of dpkg maintainers, this bug is a "wontfix" at our level. Just to sum up what dpkg --unpack does in 1.15.8.6: 1/ set the package status as half-installed/reinst-required 2/ extract all the new files as *.dpkg-new 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by rename(foo.dpkg-new, foo) 4/ set the package status as unpacked Note that the directories are not fsynced() because we mainly don't care if the rename is recorded or not, as long as the installed file always has the content of either the old or the new file. This could be fixed but is unlikely to help in getting better performances I guess. The only thing we want to achieve is that: - when the package is set to unpacked status, all changes have been committed - when the process is abruptly interrupted, we don't leave corrupted files around (like unwanted empty files) Cheers, -- Ra
Bug#604480: marked as done (linux-2.6: CVE-2010-4072 ff.)
Your message dated Fri, 26 Nov 2010 15:32:25 + with message-id and subject line Bug#604480: fixed in syncevolution 1.1+ds1-4 has caused the Debian Bug report #604480, regarding linux-2.6: CVE-2010-4072 ff. 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.) -- 604480: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604480 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: linux-2.6 Severity: normal Hi, there are a number of low urgency security problems (with fixes as far as I can find them). CVE-2010-4072 - http://lkml.org/lkml/2010/10/6/454 CVE-2010-4073 - http://lkml.org/lkml/2010/10/6/492 CVE-2010-4075 - http://lkml.indiana.edu/hypermail//linux/kernel/1009.1/03388.html CVE-2010-4076 - http://lkml.org/lkml/2010/9/15/389 CVE-2010-4077 - http://lkml.indiana.edu/hypermail//linux/kernel/1009.1/03387.html CVE-2010-4079 - http://lkml.org/lkml/2010/9/15/393 CVE-2010-4083 - http://www.spinics.net/lists/mm-commits/msg80234.html I hope this helps. AW -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32 (PREEMPT) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash --- End Message --- --- Begin Message --- Source: syncevolution Source-Version: 1.1+ds1-4 We believe that the bug you reported is fixed in the latest version of syncevolution, which is due to be installed in the Debian FTP archive: sync-ui_1.1+ds1-4_amd64.deb to main/s/syncevolution/sync-ui_1.1+ds1-4_amd64.deb syncevolution-common_1.1+ds1-4_all.deb to main/s/syncevolution/syncevolution-common_1.1+ds1-4_all.deb syncevolution-dbg_1.1+ds1-4_amd64.deb to main/s/syncevolution/syncevolution-dbg_1.1+ds1-4_amd64.deb syncevolution-dbus_1.1+ds1-4_amd64.deb to main/s/syncevolution/syncevolution-dbus_1.1+ds1-4_amd64.deb syncevolution-http_1.1+ds1-4_all.deb to main/s/syncevolution/syncevolution-http_1.1+ds1-4_all.deb syncevolution_1.1+ds1-4.debian.tar.gz to main/s/syncevolution/syncevolution_1.1+ds1-4.debian.tar.gz syncevolution_1.1+ds1-4.dsc to main/s/syncevolution/syncevolution_1.1+ds1-4.dsc syncevolution_1.1+ds1-4_amd64.deb to main/s/syncevolution/syncevolution_1.1+ds1-4_amd64.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 604...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. David Bremner (supplier of updated syncevolution package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 24 Nov 2010 15:10:00 -0800 Source: syncevolution Binary: syncevolution sync-ui syncevolution-common syncevolution-dbus syncevolution-http syncevolution-dbg Architecture: source amd64 all Version: 1.1+ds1-4 Distribution: experimental Urgency: low Maintainer: David Bremner Changed-By: David Bremner Description: sync-ui- Evolution data synchronization program using SyncML (GTK+ GUI) syncevolution - Evolution data synchronization program using SyncML (CLI) syncevolution-common - Evolution data synchronization program using SyncML syncevolution-dbg - Evolution data synchronization program using SyncML (debugging) syncevolution-dbus - Evolution data synchronization program using SyncML (D-Bus suppor syncevolution-http - Evolution data synchronization program using SyncML (http support Closes: 604480 Changes: syncevolution (1.1+ds1-4) experimental; urgency=low . * Remove build dependency on libopenobex1-dev on hurd-i386, because it is not available there. The package is already built without it on kfreebsd. * Explicitly translate between sysync::memSize and size_t. Thanks to Patrick Ohly for the patch. (Closes: #604480). Checksums-Sha1: 6da40b4bbd2a974fd6e521abdf3c224d4bda613a 1857 syncevolution_1.1+ds1-4.dsc 8ec573c0db3dbb3f0f6fdda9ba42f14c68d76c67 9483 syncevolution_1.1+ds1-4.debian.tar.gz 194a2d146781c47694f38a256fb5c3a21eeac96a 742354 syncevolution_1.1+ds1-4_amd64.deb 7c6bc34b26a470576022a266f1d063262e1b83bb 56348 sync-ui_1.1+ds1-4_amd64.deb 43cd8ce4a3945fdfa9bd90c74f5421e3330be285 132614 syncevolution-common_1.1+ds1-4_all.deb ecf8b5df2fb1fc6c44e5b9915a21aadc4e75fead 845392 syncevolution-dbus_1.1+
Re: Bug#605032: general: Acer Aspire 5553g fails to resume after hibernate
reassign 605032 linux-2.6 thanks On Freitag, 26. November 2010, Sergey Chepurko wrote: > Package: general > Severity: normal > > When i use hibernate mode on my laptop Acer Aspire 5553g with closing my > notebook i cant resume the session when open it later. It simply freezes. > All i can do is force shut down using 5 sec press power button. There no > other key is responsing. > > > > -- System Information: > Debian Release: squeeze/sid > APT prefers testing > APT policy: (900, 'testing'), (800, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores) > Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash signature.asc Description: This is a digitally signed message part.
Re: Bug#605030: general: bluetooth adapter ar3011 on acer aspire 5553g don't start after shutdown
reassign 605030 linux-2.6 thanks On Freitag, 26. November 2010, Sergey Chepurko wrote: > Package: general > Severity: normal > > I am using Debian testing with latest updates installed. I have a atheros > ar3011 bluetooth adapter on my laptop. The problem is next, when i shutdown > my laptop and on first boot choose to run debian my adapter don't start. To > get my adapter working i have to boot into my windows 7 second system and > then reboot to debian. This steps allow me to use bluetooth untill next > shutdown. When my adapter is unavailable i get empty output from 'hcitool > dev' command. Nevertheless the output by 'lsusb' is this: > Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 004 Device 002: ID 0cf3:3002 Atheros Communications, Inc. > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 001 Device 002: ID 0402:9665 ALi Corp. > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub. > Here is my adapter on Bus 004. But system can't start it. > > > > -- System Information: > Debian Release: squeeze/sid > APT prefers testing > APT policy: (900, 'testing'), (800, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores) > Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash signature.asc Description: This is a digitally signed message part.
Processed: Re: Bug#605032: general: Acer Aspire 5553g fails to resume after hibernate
Processing commands for cont...@bugs.debian.org: > reassign 605032 linux-2.6 Bug #605032 [general] general: Acer Aspire 5553g fails to resume after hibernate Bug reassigned from package 'general' to 'linux-2.6'. > thanks Stopping processing here. Please contact me if you need assistance. -- 605032: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605032 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.12907865318843.transcr...@bugs.debian.org
Processed: Re: Bug#605030: general: bluetooth adapter ar3011 on acer aspire 5553g don't start after shutdown
Processing commands for cont...@bugs.debian.org: > reassign 605030 linux-2.6 Bug #605030 [general] general: bluetooth adapter ar3011 on acer aspire 5553g don't start after shutdown Bug reassigned from package 'general' to 'linux-2.6'. > thanks Stopping processing here. Please contact me if you need assistance. -- 605030: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605030 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.12907865578922.transcr...@bugs.debian.org
Processed: Re: Bug#604480: marked as done (linux-2.6: CVE-2010-4072 ff.)
Processing commands for cont...@bugs.debian.org:
> reopen 604480
Bug #604480 {Done: David Bremner } [linux-2.6] linux-2.6:
CVE-2010-4072 ff.
'reopen' may be inappropriate when a bug has been closed with a version;
you may need to use 'found' to remove fixed versions.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
604480: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604480
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.12907866029062.transcr...@bugs.debian.org
Re: Bug#605009: serious performance regression with ext4
On Fri, Nov 26, 2010 at 03:53:27PM +0100, Raphael Hertzog wrote: > Just to sum up what dpkg --unpack does in 1.15.8.6: > 1/ set the package status as half-installed/reinst-required > 2/ extract all the new files as *.dpkg-new > 3/ for all the unpacked files: fsync(foo.dpkg-new) followed by >rename(foo.dpkg-new, foo) What are you doing? 1) Suppose package contains files "a", "b", and "c". Which are you doing? a) extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a); extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b); extract c.dpkg-new ; fsync(c.dpkg-new); rename(c.dpkg-new, c); or b) extract a.dpkg-new ; fsync(a.dpkg-new); extract b.dpkg-new ; fsync(b.dpkg-new); extract c.dpkg-new ; fsync(c.dpkg-new); rename(a.dpkg-new, a); rename(b.dpkg-new, b); rename(c.dpkg-new, c); or c) extract(a.dpkg-new); extract(b.dpkg-new); extract(c.dpkg-new); fsync(a.dpkg-new); fsync(b.dpkg-new); fsync(c.dpkg-new); rename(a.dpkg-new, a); rename(b.dpkg-new, b); rename(c.dpkg-new, c); (c) will perform the best for most file systems, including ext4. As a further optimization, if "b" and "c" does not exist, of course it would be better to extract into "b" and "c" directly, and skip the rename, i.e.: d) extract(a.dpkg-new); extract(b); # assuming the file "b" does not yet exist extract(c); # assuming the file "c" does not yet exist fsync(a.dpkg-new); fsync(b); fsync(c); rename(a.dpkg-new, a); ... and then set the package status as unpacked. I am guessing you are doing (a) today --- am I right? (c) or (d) would be best. - Ted -- 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/20101126215254.gj2...@thunk.org
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
Ben Hutchings : > On Fri, 2010-11-26 at 19:54 +0800, Hayes Wang wrote: > > Correct the binary code (Low pass filter & DLY_CAP fine tune from uC). > > The incorrect ram code would make the nic working abnormally. > [...] > > I'm glad you finally acknowledge that this is code rather than simple > register initialisation. I am not sure that Hayes is a native english speaker. I am glad to see him posting here. [...] > Below are the changes Debian currently applies in preparation for proper > licencing of the firmware. Do you have some scripts to convert the data at hand ? I would welcome a clear statement regarding the status of the binary thing (code ? data ?) but even without one *now*, I'd like to see it separated from the main code : the driver sucks and things will go worse with support code for the 8168e. Is there anybody objecting to it ? I will buy anything be it firmware API or plain .h. -- Ueimor -- 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/20101126224914.ga12...@electric-eye.fr.zoreil.com
Bug#564628: [PATCH] net/r8169: Correct the ram code for RTL8111D(L)
On Fri, 2010-11-26 at 23:49 +0100, Francois Romieu wrote: > Ben Hutchings : > > On Fri, 2010-11-26 at 19:54 +0800, Hayes Wang wrote: > > > Correct the binary code (Low pass filter & DLY_CAP fine tune from uC). > > > The incorrect ram code would make the nic working abnormally. > > [...] > > > > I'm glad you finally acknowledge that this is code rather than simple > > register initialisation. > > I am not sure that Hayes is a native english speaker. > > I am glad to see him posting here. Right. Hayes, by 'you' I meant Realtek, not you personally. If my reply seemed aggressive, I apologise. > [...] > > Below are the changes Debian currently applies in preparation for proper > > licencing of the firmware. > > Do you have some scripts to convert the data at hand ? [...] No, it's easy enough to convert a single array by copying it into a C file that dumps it to stdout (assuming the file's byte order is defined to match your own machine). It might be worth adding some sort of header with a version and checksum. Your choice, really. Ben. -- Ben Hutchings, Debian Developer and kernel team member signature.asc Description: This is a digitally signed message part
Processing of linux-2.6_2.6.26-26lenny1_i386.changes
linux-2.6_2.6.26-26lenny1_i386.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.26-26lenny1.dsc linux-2.6_2.6.26-26lenny1.diff.gz linux-doc-2.6.26_2.6.26-26lenny1_all.deb linux-manual-2.6.26_2.6.26-26lenny1_all.deb linux-patch-debian-2.6.26_2.6.26-26lenny1_all.deb linux-source-2.6.26_2.6.26-26lenny1_all.deb linux-support-2.6.26-2_2.6.26-26lenny1_all.deb linux-tree-2.6.26_2.6.26-26lenny1_all.deb linux-image-2.6.26-2-486_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-486_2.6.26-26lenny1_i386.deb linux-image-2.6.26-2-686_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-686_2.6.26-26lenny1_i386.deb linux-image-2.6.26-2-686-bigmem_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-686-bigmem_2.6.26-26lenny1_i386.deb linux-image-2.6.26-2-amd64_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-amd64_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-common_2.6.26-26lenny1_i386.deb linux-image-2.6.26-2-openvz-686_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-openvz-686_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-common-openvz_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-all_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-all-i386_2.6.26-26lenny1_i386.deb linux-libc-dev_2.6.26-26lenny1_i386.deb linux-image-2.6.26-2-vserver-686_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-vserver-686_2.6.26-26lenny1_i386.deb linux-image-2.6.26-2-vserver-686-bigmem_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-vserver-686-bigmem_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-common-vserver_2.6.26-26lenny1_i386.deb linux-image-2.6.26-2-xen-686_2.6.26-26lenny1_i386.deb linux-modules-2.6.26-2-xen-686_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-xen-686_2.6.26-26lenny1_i386.deb xen-linux-system-2.6.26-2-xen-686_2.6.26-26lenny1_i386.deb linux-headers-2.6.26-2-common-xen_2.6.26-26lenny1_i386.deb Greetings, Your Debian queue daemon (running on host franck.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/e1pmcx8-0001mp...@franck.debian.org
Processing of linux-2.6_2.6.26-26lenny1_hppa.changes
linux-2.6_2.6.26-26lenny1_hppa.changes uploaded successfully to localhost along with the files: linux-image-2.6.26-2-parisc_2.6.26-26lenny1_hppa.deb linux-headers-2.6.26-2-parisc_2.6.26-26lenny1_hppa.deb linux-image-2.6.26-2-parisc-smp_2.6.26-26lenny1_hppa.deb linux-headers-2.6.26-2-parisc-smp_2.6.26-26lenny1_hppa.deb linux-image-2.6.26-2-parisc64_2.6.26-26lenny1_hppa.deb linux-headers-2.6.26-2-parisc64_2.6.26-26lenny1_hppa.deb linux-image-2.6.26-2-parisc64-smp_2.6.26-26lenny1_hppa.deb linux-headers-2.6.26-2-parisc64-smp_2.6.26-26lenny1_hppa.deb linux-headers-2.6.26-2-common_2.6.26-26lenny1_hppa.deb linux-headers-2.6.26-2-all_2.6.26-26lenny1_hppa.deb linux-headers-2.6.26-2-all-hppa_2.6.26-26lenny1_hppa.deb linux-libc-dev_2.6.26-26lenny1_hppa.deb Greetings, Your Debian queue daemon (running on host franck.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/e1pmd21-0001wy...@franck.debian.org
Re: Bug#605009: serious performance regression with ext4
Hi Ted, Ted Ts'o wrote: > 1) Suppose package contains files "a", "b", and "c". Which are you > doing? > > a) extract a.dpkg-new ; fsync(a.dpkg-new); rename(a.dpkg-new, a); > extract b.dpkg-new ; fsync(b.dpkg-new); rename(b.dpkg-new, b); > extract c.dpkg-new ; fsync(c.dpkg-new); rename(c.dpkg-new, c); > > or > > b) extract a.dpkg-new ; fsync(a.dpkg-new); > extract b.dpkg-new ; fsync(b.dpkg-new); > extract c.dpkg-new ; fsync(c.dpkg-new); > rename(a.dpkg-new, a); > rename(b.dpkg-new, b); > rename(c.dpkg-new, c); > > or > > c) extract(a.dpkg-new); > extract(b.dpkg-new); > extract(c.dpkg-new); > fsync(a.dpkg-new); > fsync(b.dpkg-new); > fsync(c.dpkg-new); > rename(a.dpkg-new, a); > rename(b.dpkg-new, b); > rename(c.dpkg-new, c); > > > (c) will perform the best for most file systems, including ext4. [...] > I am guessing you are doing (a) today --- am I right? (c) or (d) > would be best. We are doing (c) today. Regards, Jonathan -- 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/20101127075831.gc24...@burratino
