Re: drm i915 hangs on heavy io load
On Sun, Oct 28, 2012 at 21:32:53 +0900, Norbert Preining wrote: > Hi Chris, > > > > so can you > > please file a bug on bugzilla.freedesktop.org (or bugzilla.kernel.org) > > so that we don't lose track of it. > > Will do when I'm back from the mountains. > > > If your have the option, can you switch the ddx between using SNA and > > UXA. > > ??? Is that a BIOS option? Or kernel? > I can try both. It is an option in the Intel Xorg driver. What is actually used depends on the options provided to the configure script during build time. You can see the current state in nur Xorg.0.log. Here is an example of /etc/X11/xorg.conf which enforces SNA: Section "Device" Option "AccelMethod" "SNA" Identifier "Card0" Driver "intel" EndSection Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No 3.5 version on www.kernel.org
Hi, when looking at http://www.kernel.org/, kernel 3.4.7 is shown as the latest stable kernel, and 3.6-rc1 as the latest mainline kernel. The 3.5 version is not mentioned. Why is the latest stable kernel something older than 3.5? Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc2 hangs after "Suspending console(s)"
Hi folks, with 2.6.25-rc2, my Mac mini Core Duo hangs at suspend. The last message on the console is "Suspending console(s)". I also tried some other versions after 2.6.24, all of them fail with this hang. I attached the lspci output for the case that it matters. Regards, Tino 00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03) Subsystem: Intel Corporation Unknown device [8086:7270] Flags: bus master, fast devsel, latency 0 Capabilities: Kernel driver in use: agpgart-intel 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Unknown device [8086:7270] Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at 9038 (32-bit, non-prefetchable) [size=512K] I/O ports at 20f0 [size=8] Memory at 8000 (32-bit, prefetchable) [size=256M] Memory at 9040 (32-bit, non-prefetchable) [size=256K] Capabilities: 00:07.0 Performance counters [1101]: Intel Corporation Unknown device [8086:27a3] (rev 03) Flags: 66MHz, fast devsel, IRQ 10 Memory at 90444000 (32-bit, non-prefetchable) [size=4K] Capabilities: 00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8] (rev 02) Subsystem: Sigmatel Unknown device [8384:7680] Flags: bus master, fast devsel, latency 0, IRQ 21 Memory at 9044 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel 00:1c.0 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 [8086:27d0] (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 1000-1fff Memory behind bridge: 9020-902f Prefetchable memory behind bridge: 5000-500f Capabilities: Kernel driver in use: pcieport-driver 00:1c.1 PCI bridge [0604]: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 [8086:27d2] (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Memory behind bridge: 9010-901f Capabilities: Kernel driver in use: pcieport-driver 00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8] (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device [8086:7270] Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at 20a0 [size=32] Kernel driver in use: uhci_hcd 00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9] (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device [8086:7270] Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at 2080 [size=32] Kernel driver in use: uhci_hcd 00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca] (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device [8086:7270] Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at 2060 [size=32] Kernel driver in use: uhci_hcd 00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb] (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation Unknown device [8086:7270] Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at 2040 [size=32] Kernel driver in use: uhci_hcd 00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc] (rev 02) (prog-if 20 [EHCI]) Subsystem: Intel Corporation Unknown device [8086:7270] Flags: bus master, medium devsel, latency 0, IRQ 20 Memory at 90445400 (32-bit, non-prefetchable) [size=1K] Capabilities: Kernel driver in use: ehci_hcd 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=32 Memory behind bridge: 9000-900f Capabilities: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9] (rev 02) Subsystem: Intel Corporation Unknown device [8086:7270] Flags: bus master, medium devsel, latency 0 Capabilities: 00:1f.1 IDE interface [0101]: Intel Corporation 82801G (ICH7
Re: 2.6.25-rc2 hangs after "Suspending console(s)"
On Mon, Feb 18, 2008 at 20:49:04 +0100, Pavel Machek wrote: > On Mon 2008-02-18 01:28:15, Tino Keitel wrote: > > Hi folks, > > > > with 2.6.25-rc2, my Mac mini Core Duo hangs at suspend. The last > > message on the console is "Suspending console(s)". I also tried some > > other versions after 2.6.24, all of them fail with this hang. > > Try adding 'no_console_suspend' to kernel command line. Thanks, that gave a bit insight. The last message is now: ACPI: PCI interrupt for device :00:02.0 disabled This is my graphics card: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller So it looks like the recent changes that should repair console sudpend/resume for Intel graphics broke suspend for me. Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 regression - hang on suspend
On Tue, Feb 19, 2008 at 12:59:46 +0100, Soeren Sonnenburg wrote: > Hi, > > since 2.6.25-rc1 (first version I tried) and still in rc2 (and git), I > see a hang on s2ram already when trying to suspend. > > This is on a macbookpro 1,1 - which steps should I do next to help > isolating the problem? Could this be the same as http://lkml.org/lkml/2008/2/17/381? Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 hangs after "Suspending console(s)"
On Tue, Feb 19, 2008 at 09:52:22 +0100, Tino Keitel wrote: > On Mon, Feb 18, 2008 at 20:49:04 +0100, Pavel Machek wrote: > > On Mon 2008-02-18 01:28:15, Tino Keitel wrote: > > > Hi folks, > > > > > > with 2.6.25-rc2, my Mac mini Core Duo hangs at suspend. The last > > > message on the console is "Suspending console(s)". I also tried some > > > other versions after 2.6.24, all of them fail with this hang. > > > > Try adding 'no_console_suspend' to kernel command line. > > Thanks, that gave a bit insight. The last message is now: > > ACPI: PCI interrupt for device :00:02.0 disabled > > This is my graphics card: > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile > 945GM/GMS, 943/940GML Express Integrated Graphics Controller > > So it looks like the recent changes that should repair console > sudpend/resume for Intel graphics broke suspend for me. It looks like I was wrong. It also hangs when the i915 module isn't loaded. Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ath5k failure with 2.6.24-git14
Hi, I tried the current git (9ef9dc69d4167276c04590d67ee55de8380bc1ad) and got the following error message from ath5k: ath5k_pci :02:00.0: registered as 'phy0' ath5k phy0: failed to resume the MAC Chip ath5k_pci: probe of :02:00.0 failed with error -5 Here is the lspci -vnn output: 02:00.0 Ethernet controller [0200]: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c] (rev 01) Subsystem: Apple Computer Inc. Unknown device [106b:0086] Flags: fast devsel, IRQ 17 Memory at 9010 (64-bit, non-prefetchable) [disabled] [size=64K] Capabilities: [40] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [90] MSI-X: Enable- Mask- TabSize=1 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Kernel modules: ath5k The same device works with madwifi: ath_rate_sample: 1.2 (svn r3339) MadWifi: ath_attach: Switching per-packet transmit power control off wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP wifi0: ath_announce: Use hw queue 1 for WME_AC_BE traffic wifi0: ath_announce: Use hw queue 0 for WME_AC_BK traffic wifi0: ath_announce: Use hw queue 2 for WME_AC_VI traffic wifi0: ath_announce: Use hw queue 3 for WME_AC_VO traffic wifi0: ath_announce: Use hw queue 8 for CAB traffic wifi0: ath_announce: Use hw queue 9 for beacons ath_pci: wifi0: Atheros 5424/2424: mem=0x9010, irq=17 I can also set the interface up and use iwlist ath0 scan. Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT 1/1] single_chip test
On Wed, Feb 06, 2008 at 10:46:39 -0500, Bob Copeland wrote: > > > We failed to resume after a hardware reset here for a whole second. Is > > > there any > > > version of ath5k which worked for you (is this a regression)? > > > > I cannot speak for Tino, but my ath5k never worked in MacBook -- it > > failed the same way, and I believe the hardware was the same. My > > understanding was that it was a known bug with PCIE devices, but I got > > that out of reading list archives. > > Nick Kossifidis and I are in the process of debugging this -- we > determined that AR5K_RESET_CTL_PCI hangs the card in hw_nic_wakeup. > It doesn't look like there is any general support for 5424 cards yet. I tried the patch, and the card was detected. I was able to associate with an WPA2 AP and send/receive some traffic. But after a while the interface broke: ath0: No ProbeResp from current AP 00:14:bf:16:25:87 - assume out of range ath5k_hw_get_isr: 0x0020 ... ath0: failed to set channel 165 (5825 MHz) for scan ath0: failed to restore operational channel after scan printk: 19 messages suppressed. ath5k phy0: calibration timeout (2447MHz) printk: 1 messages suppressed. ath5k phy0: calibration timeout (2447MHz) ath5k phy0: unable to reset hardware: -11 Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT 1/1] single_chip test
On Thu, Feb 07, 2008 at 22:51:04 +0100, Jiri Slaby wrote: [...] > What's the srev a phy ver printed few lines above this, please? ath5k_pci :02:00.0: registered as 'phy0' SINGLE: 1, srev: a3, phy: phy0: Selected rate control algorithm 'pid' ath5k phy0: Atheros AR5424 chip found (MAC: 0xa3, PHY: 0x61) Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 hangs after "Suspending console(s)"
On Sat, Feb 23, 2008 at 22:43:50 +0100, Rafael J. Wysocki wrote: > On Wednesday, 20 of February 2008, Tino Keitel wrote: > > On Tue, Feb 19, 2008 at 09:52:22 +0100, Tino Keitel wrote: > > > On Mon, Feb 18, 2008 at 20:49:04 +0100, Pavel Machek wrote: > > > > On Mon 2008-02-18 01:28:15, Tino Keitel wrote: > > > > > Hi folks, > > > > > > > > > > with 2.6.25-rc2, my Mac mini Core Duo hangs at suspend. The last > > > > > message on the console is "Suspending console(s)". I also tried some > > > > > other versions after 2.6.24, all of them fail with this hang. > > > > > > > > Try adding 'no_console_suspend' to kernel command line. > > > > > > Thanks, that gave a bit insight. The last message is now: > > > > > > ACPI: PCI interrupt for device :00:02.0 disabled > > > > > > This is my graphics card: > > > > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile > > > 945GM/GMS, 943/940GML Express Integrated Graphics Controller > > > > > > So it looks like the recent changes that should repair console > > > sudpend/resume for Intel graphics broke suspend for me. > > > > It looks like I was wrong. It also hangs when the i915 module isn't > > loaded. > > Please have a look at: http://bugzilla.kernel.org/show_bug.cgi?id=10065 Thanks. I tested git 1a4c6be4aca5ad6b300932efed1e2729fdc25af9 without any patches and I can suspend and resume fine. Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24.3
On Mon, Feb 25, 2008 at 17:00:24 -0800, Greg Kroah-Hartman wrote: > We (the -stable team) are announcing the release of the 2.6.24.3 > kernel. Hi, I can see the patch in http://www.kernel.org/pub/linux/kernel/v2.6/, but no incremental patch in http://www.kernel.org/pub/linux/kernel/v2.6/incr/. Is this due to some delay, or was is just not uploaded? Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
crashes if accassing FAT MO
Hi folks, I use kernel 2.4.2. If I try to access files on a 640 MB MO (2048 bytes hardware sector size) and the MO is using FAT fs I only got messages like these: Unable to handle kernel NULL pointer dereference at virtual address printing eip: *pde = Oops: CPU:0 EIP:0010:[<>] EFLAGS: 00010286 eax: ebx: c798d740 ecx: 0003 edx: c798d740 esi: ffea edi: ebp: 4000 esp: c576bf88 ds: 0018 es: 0018 ss: 0018 Process cat (pid: 458, stackpage=c576b000) Stack: cc993428 c798d740 0804b220 4000 c798d760 c012d465 c798d740 0804b220 4000 c798d760 c576a000 4000 0804b220 b994 c0108d43 0003 0804b220 4000 4000 0804b220 b994 0003 002b 002b Call Trace: [] [] [] Code: Bad EIP value. Segmentation fault There are no problems if I use ext2fs, exept that I can't use them for data exchange with Windows. It also works with 2.2 kernels but the MO drive will be much slower. Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: crashes if accassing FAT MO
On Thursday, 8. March 2001 17:42, Tino Keitel wrote:
> Hi folks,
>
> I use kernel 2.4.2. If I try to access files on a 640 MB MO (2048 bytes
> hardware sector size) and the MO is using FAT fs I only got messages
> like these:
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
> printing eip:
>
> *pde =
> Oops:
> CPU:0
> EIP:0010:[<>]
> EFLAGS: 00010286
> eax: ebx: c798d740 ecx: 0003 edx: c798d740
> esi: ffea edi: ebp: 4000 esp: c576bf88
> ds: 0018 es: 0018 ss: 0018
> Process cat (pid: 458, stackpage=c576b000)
> Stack: cc993428 c798d740 0804b220 4000 c798d760 c012d465 c798d740
> 0804b220
>4000 c798d760 c576a000 4000 0804b220 b994 c0108d43
> 0003
>0804b220 4000 4000 0804b220 b994 0003 002b
> 002b
> Call Trace: [] [] []
>
> Code: Bad EIP value.
> Segmentation fault
>
> There are no problems if I use ext2fs, exept that I can't use them for
> data exchange with Windows. It also works with 2.2 kernels but the MO
> drive will be much slower.
>
> Tino
Ok, I did some debug work. Here are the results:
Writing to the MO doesn't cause an "Oops", but the file will contain trash.
'cat "test" > file' results in a file that contains 0x1a 0xf7 0xa3 0xdb 0x86
The lines
printk("fat debug: *i_sb: %u\n", inode->i_sb);
printk("fat debug: *cvf_file_read: %u\n",
MSDOS_SB(inode->i_sb)->cvf_format->cvf_file_read);
in fs/fat/file.c:fat_file_read() shows this:
fat debug: *cvf_format: 3365518688
fat debug: *cvf_file_read: 0
In fs/fat/cvf.c I found this:
struct cvf_format bigblock_cvf = {
0, /* version - who cares? */
"big_blocks",
0, /* flags - who cares? */
NULL,
NULL,
NULL,
bigblock_fat_bread,
bigblock_fat_bread,
bigblock_fat_brelse,
bigblock_fat_mark_buffer_dirty,
bigblock_fat_set_uptodate,
bigblock_fat_is_uptodate,
bigblock_fat_ll_rw_block,
default_fat_access,
NULL,
default_fat_bmap,
NULL,
^
default_fat_file_write,
NULL,
NULL
};
cvf_file_read is set to zero and will be never changed, but cvf_file_write is
set to default_fat_file_write.
Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sr device can be written?
On Tue, Aug 30, 2005 at 12:53:51 +0800, jeff shia wrote: > Hello, > Sr is the Scsi-cdrom device?so it can be read only?but look at the source= > =20 > code I notice that > sr can be written also!Is it right? Just imagine a DVD-RAM drive. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sr device can be written?
On Tue, Aug 30, 2005 at 16:11:58 +0800, jeff shia wrote: > YOu mean the device file can be written? Yes, like an ordinary block device. > > > On 8/30/05, Tino Keitel <[EMAIL PROTECTED]> wrote: > > On Tue, Aug 30, 2005 at 12:53:51 +0800, jeff shia wrote: > > > Hello, > > > Sr is the Scsi-cdrom device?so it can be read only?but look at the > > > source= > > > =20 > > > code I notice that > > > sr can be written also!Is it right? > > > > Just imagine a DVD-RAM drive. > > > > Regards, > > Tino > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Could not set non-blocking flag with 2.6.24-rc5
Hi folks,
I often build Debian packages inside a chroot. Today I discovered a
failure during an "aptitude update", which is a command to download new
package lists for the package management. In strace, the lines around
the failure look like this:
99% [Working]) = 14 14
[pid 5986] select(6, [3 4 5], [], NULL, {0, 50}) = 0 (Timeout)
[pid 5986] gettimeofday({1197576353, 670510}, NULL) = 0
[pid 5986] rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
[pid 5986] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
99% [Working]) = 14 14
[pid 5986] select(6, [3 4 5], [], NULL, {0, 50}) = 0 (Timeout)
[pid 5986] gettimeofday({1197576354, 173902}, NULL) = 0
[pid 5986] rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
[pid 5986] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
99% [Working]) = 14 14
[pid 5986] select(6, [3 4 5], [], NULL, {0, 50}
[pid 5988] <... select resumed> ) = 1 (in [3], left {105, 0})
[pid 5988] read(3, "", 56559) = 0
[pid 5988] fcntl64(-1, F_GETFL)= -1 EBADF (Bad file
descriptor)
[pid 5988] fcntl64(-1, F_SETFL,
O_ACCMODE|O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC|O_APPEND|O_SYNC|O_ASYNC|O_DIRECT|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|0xfff8003c)
= -1 EBADF (Bad file descriptor)
[pid 5988] write(2, ""..., 41FATAL -> Could not set non-blocking flag
) = 41
[pid 5988] write(2, ""..., 19Bad file descriptor) = 19
[pid 5988] write(2, ""..., 1
) = 1
[pid 5988] exit_group(100) = ?
Process 5988 detached
This happened with a kernel after 2.6.24-rc5
(4af75653031c6d454b4ace47c1536f0d2e727e3e). I rebooted into 2.6.23.8
and it worked. Now I rebooted into 2.6.24-rc5 again and was able to
reproduce the failure, so it looks like a kernel issue to me.
Regards,
Tino
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RTC wakealarm write-only, still has 644 permissions
On Thu, Nov 29, 2007 at 00:26:47 +0100, Pavel Machek wrote: [...] > > > Also, is there some documentation for wakealarm? > > > > "git show 3925a5ce44330767f7f0de5c58c6a797009f0f75" has some. > > Thanks. Will put it into Doc*/rtc.txt. It would be nice if you mention the differences to the old /proc/acpi/alarm, to help users who want to migrate. Something like in http://lkml.org/lkml/2007/6/19/264. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS related Oops (suspend/resume related)
On Thu, Nov 29, 2007 at 22:05:24 +0100, Rafael J. Wysocki wrote: [...] > Tino, can you check if this patch helps, please? Not really. I suspend one to several times a day, and in most cases resume works. I thing checking the patch is hard when I have no real procedure to reproduce the resume failure. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: XFS related Oops
On Wed, Nov 14, 2007 at 10:04:45 +1100, David Chinner wrote:
> On Tue, Nov 13, 2007 at 11:51:19AM +0100, Tino Keitel wrote:
> > On Tue, Nov 13, 2007 at 09:27:20 +1100, David Chinner wrote:
> >
> > [...]
> >
> > > No. I'd say something got screwed up during suspend/resume. Is it
> > > reproducable?
> >
> > No. I often use suspend to RAM, and usually it works without such
> > failures. I restart squid during the resume prosecure, and the above
> > Oops lead to a squid in D state.
>
> Ok. Sounds like there's not much we can debug at this point. Thanks
> for the report, though.
I got a similar Oops again:
xfs_iget_core: ambiguous vns: vp/0xc00700c0, invp/0xcb5a1680
[ cut here ]
kernel BUG at fs/xfs/support/debug.c:55!
invalid opcode: [#2]
SMP
Modules linked in: dvb_usb_cinergyT2 rfcomm l2cap bluetooth i915 drm
cpufreq_stats firewire_ohci firewire_core dvb_usb crc_itu_t usblp evdev
snd_hda_intel rtc_cmos sky2 dvb_core applesmc led_class coretemp hwmon
CPU:0
EIP:0060:[]Tainted: G D VLI
EFLAGS: 00010246 (2.6.23.1 #4)
EIP is at cmn_err+0x9a/0xa0
eax: c049efb0 ebx: c044ffac ecx: 0001 edx: 0286
esi: edi: 0286 ebp: f75f86f0 esp: eab9fccc
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process gc_approx (pid: 29386, ti=eab9e000 task=e409b030
task.ti=eab9e000)
Stack: c04531ce c043a07d c05544c0 eab9fcf4 c0071500 2094
c022855b
c044ffac c00700c0 cb5a1680 f796ac00 c18828c4 c04fb280
f75f86f4
f748e800 cb5a1680 c0071500 cb5a169c
cb5a1680
Call Trace:
[] xfs_iget_core+0x54b/0x690
[] xfs_iget+0xd4/0x160
[] xfs_dir_lookup_int+0x9b/0x100
[] xfs_lookup+0x75/0xa0
[] xfs_vn_lookup+0x54/0x90
[] do_lookup+0x122/0x1a0
[] __link_path_walk+0x784/0xd80
[] link_path_walk+0x65/0xc0
[] link_path_walk+0x45/0xc0
[] do_path_lookup+0x73/0x1b0
[] getname+0xa5/0xc0
[] __user_walk_fd+0x3b/0x60
[] vfs_stat_fd+0x22/0x60
[] sys_stat64+0xf/0x30
[] dput+0x85/0x100
[] __fput+0x114/0x160
[] mntput_no_expire+0x1b/0x80
[] filp_close+0x47/0x80
[] sys_close+0x63/0xc0
[] sysenter_past_esp+0x5f/0x85
[] __mutex_lock_interruptible_slowpath+0xb0/0x290
===
Code: 45 c0 89 44 24 04 e8 e6 ec ec ff 89 fa b8 b0 ef 49 c0 e8 5a 6e 18
00 85 f6 74 10 83 c4 10 5b 5e 5f c3 c6 81 c0 44 55 c0 00 eb c1 <0f> 0b
eb fe 90 90 83 ec 10 85 d2 89 1c 24 89 cb 89 74 24 04 89
EIP: [] cmn_err+0x9a/0xa0 SS:ESP 0068:eab9fccc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: XFS related Oops
On Wed, Nov 14, 2007 at 10:04:45 +1100, David Chinner wrote:
> On Tue, Nov 13, 2007 at 11:51:19AM +0100, Tino Keitel wrote:
> > On Tue, Nov 13, 2007 at 09:27:20 +1100, David Chinner wrote:
> >
> > [...]
> >
> > > No. I'd say something got screwed up during suspend/resume. Is it
> > > reproducable?
> >
> > No. I often use suspend to RAM, and usually it works without such
> > failures. I restart squid during the resume prosecure, and the above
> > Oops lead to a squid in D state.
>
> Ok. Sounds like there's not much we can debug at this point. Thanks
> for the report, though.
I got a similar Oops again:
xfs_iget_core: ambiguous vns: vp/0xc00700c0, invp/0xcb5a1680
[ cut here ]
kernel BUG at fs/xfs/support/debug.c:55!
invalid opcode: [#2]
SMP
Modules linked in: dvb_usb_cinergyT2 rfcomm l2cap bluetooth i915 drm
cpufreq_stats firewire_ohci firewire_core dvb_usb crc_itu_t usblp evdev
snd_hda_intel rtc_cmos sky2 dvb_core applesmc led_class coretemp hwmon
CPU:0
EIP:0060:[]Tainted: G D VLI
EFLAGS: 00010246 (2.6.23.1 #4)
EIP is at cmn_err+0x9a/0xa0
eax: c049efb0 ebx: c044ffac ecx: 0001 edx: 0286
esi: edi: 0286 ebp: f75f86f0 esp: eab9fccc
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process gc_approx (pid: 29386, ti=eab9e000 task=e409b030
task.ti=eab9e000)
Stack: c04531ce c043a07d c05544c0 eab9fcf4 c0071500 2094
c022855b
c044ffac c00700c0 cb5a1680 f796ac00 c18828c4 c04fb280
f75f86f4
f748e800 cb5a1680 c0071500 cb5a169c
cb5a1680
Call Trace:
[] xfs_iget_core+0x54b/0x690
[] xfs_iget+0xd4/0x160
[] xfs_dir_lookup_int+0x9b/0x100
[] xfs_lookup+0x75/0xa0
[] xfs_vn_lookup+0x54/0x90
[] do_lookup+0x122/0x1a0
[] __link_path_walk+0x784/0xd80
[] link_path_walk+0x65/0xc0
[] link_path_walk+0x45/0xc0
[] do_path_lookup+0x73/0x1b0
[] getname+0xa5/0xc0
[] __user_walk_fd+0x3b/0x60
[] vfs_stat_fd+0x22/0x60
[] sys_stat64+0xf/0x30
[] dput+0x85/0x100
[] __fput+0x114/0x160
[] mntput_no_expire+0x1b/0x80
[] filp_close+0x47/0x80
[] sys_close+0x63/0xc0
[] sysenter_past_esp+0x5f/0x85
[] __mutex_lock_interruptible_slowpath+0xb0/0x290
===
Code: 45 c0 89 44 24 04 e8 e6 ec ec ff 89 fa b8 b0 ef 49 c0 e8 5a 6e 18
00 85 f6 74 10 83 c4 10 5b 5e 5f c3 c6 81 c0 44 55 c0 00 eb c1 <0f> 0b
eb fe 90 90 83 ec 10 85 d2 89 1c 24 89 cb 89 74 24 04 89
EIP: [] cmn_err+0x9a/0xa0 SS:ESP 0068:eab9fccc
Regards,
Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: XFS related Oops (suspend/resume related)
On Mon, Nov 26, 2007 at 23:07:56 +0100, Rafael J. Wysocki wrote: [...] > On 2.6.23.1 you can test the freezer alone by doing > > # echo testproc > /sys/power/disk > # echo disk > /sys/power/state This is suspend to RAM, not to disk. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Could not set non-blocking flag with 2.6.24-rc5
On Sat, Jan 12, 2008 at 21:10:15 +, Christoph Hellwig wrote: > On Thu, Dec 13, 2007 at 09:16:01PM +0100, Tino Keitel wrote: > > Hi folks, > > > > I often build Debian packages inside a chroot. Today I discovered a > > failure during an "aptitude update", which is a command to download new > > package lists for the package management. In strace, the lines around > > the failure look like this: > > Are you using XFS? This looks a lot like the bug I introduced where Yes, I use XFS. > i_rdev gets a wrong value assigned after mknod. In that case please > try -rc7 as it has a fix for that particular problem. OK, I'll try it. Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Could not set non-blocking flag with 2.6.24-rc5
On Sun, Jan 13, 2008 at 09:56:55 +0100, Tino Keitel wrote: > On Sat, Jan 12, 2008 at 21:10:15 +, Christoph Hellwig wrote: > > On Thu, Dec 13, 2007 at 09:16:01PM +0100, Tino Keitel wrote: > > > Hi folks, > > > > > > I often build Debian packages inside a chroot. Today I discovered a > > > failure during an "aptitude update", which is a command to download new > > > package lists for the package management. In strace, the lines around > > > the failure look like this: > > > > Are you using XFS? This looks a lot like the bug I introduced where > > Yes, I use XFS. > > > i_rdev gets a wrong value assigned after mknod. In that case please > > try -rc7 as it has a fix for that particular problem. > > OK, I'll try it. I can not reproduce it anymore with 2.6.24-rc7. Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24 regression: Wake On Lan in sky2 broken on Mac mini
Hi folks, with 2.6.24-rc8, Wake On LAN doesn't work anymore as it used to with 2.6.23 on my Mac mini Core Duo. I saw that this was reported in http://bugzilla.kernel.org/show_bug.cgi?id=9721 and on netdev a patch for the sky2 driver was sent by Stephen Hemminger. This patch fixed WOL for me after applying it to 2.6.24-rc8. However, it seems as the patch never made it into the kernel. Instead, the commit that was suspected to break WOL (84cd2dfb04d23a961c5f537baa243fa54d0987ac) was reverted (be63a21c9573fbf88106ff0f030da5974551257b). Now I tried the 2.6.24 release and noticed that WOL is still broken. I'll be happy to test any patches that can make it into 2.6.24.1. Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Troubles waking up from suspend (S3) - how to debug?
On Sun, Jan 27, 2008 at 18:42:37 +0100, Bruno Prémont wrote: > I'm currently trying out suspend (S3) on a few machines but none of them > wakes > up completely/properly (I have a few more hosts I'm planning to try suspend > on once I can get useful information out of those not waking up properly). [...] > Acer Travelmate 660 laptop (i855GM based): > Laptop suspends as expected but hangs while waking up. You might try this: http://tikei.de/suspend-to-ram-debug Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 regression: Wake On Lan in sky2 broken on Mac mini
On Mon, Jan 28, 2008 at 09:21:30 +0100, Mikael Pettersson wrote: > Tino Keitel writes: > > Hi folks, > > > > with 2.6.24-rc8, Wake On LAN doesn't work anymore as it used to with > > 2.6.23 on my Mac mini Core Duo. I saw that this was reported in > > http://bugzilla.kernel.org/show_bug.cgi?id=9721 and on netdev a patch > > for the sky2 driver was sent by Stephen Hemminger. This patch fixed WOL > > for me after applying it to 2.6.24-rc8. > > > > However, it seems as the patch never made it into the kernel. Instead, > > the commit that was suspected to break WOL > > (84cd2dfb04d23a961c5f537baa243fa54d0987ac) was reverted > > (be63a21c9573fbf88106ff0f030da5974551257b). > > > > Now I tried the 2.6.24 release and noticed that WOL is still broken. > > I'll be happy to test any patches that can make it into 2.6.24.1. > > 1. Wrong mailing list; use netdev (@vger) instead. Done. > 2. The reverted commit had much much more serious consequences than >"wol doesn't work", it actually caused BIOS hangs and failed reboots. Yes, but even with the reverted commit, WOL still doesn't work. I just tried the patch from the netdev mailing list with the 2.6.24 release version and now WOL works for me. Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24 regression: Wake On Lan in sky2 broken on Mac mini
On Mon, Jan 28, 2008 at 14:37:38 +0100, Mikael Pettersson wrote: [...] > However, it _is_ a fact that there is a proliferation of specialized > mailing lists, and it is also a fact that many developers _only_ read > those lists. I'm in no way defending this behaviour, on the contrary > I probably dislike it as much as you do. But we can't ignore it. I planned to post this to netdev first, but then I thought that it's more a task for the stable team and/or those people who track regressions, and I don't know if those people track all the subsystem mailing lists. Especially as there is a patch that fixes the issue for me, and the corresponding bugzilla entry is alrealy marked as resolved and "patch available", so it seems to me as it is just a matter of incorporating an existing patch into further revisions of 2.6.24. Regards, Tino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Problem] slow write to dvd-ram since 2.6.7-bk8
On Sun, Feb 13, 2005 at 09:26:35 -0500, Wakko Warner wrote: > Droebbel wrote: > > On recent kernels, writing to DVD-RAM is much slower than to be > > expected. A 3x Writer should do about 1.9MB/s including automatic > > verify. This is what I get with 2.6.7 up to bk7. However, from 2.6.7-bk8 > > to 2.6.10 write speed is as low as 600 to 1000 kB/s. The drive's head > > jumps a lot more with these kernels. Reading is ok. > > > > I tested UDF and ext2 filesystems, > > DMA is ok according to hdparm, > > I set taskfile-io on and off when building the kernels, > > and I compared the settings for the io-scheduler. > > > > The drive is connected via onboard via82xx ide or usb2 external (both > > works perfectly with hd). > > > > The drive is a LG GSA-4163B; a GSA-4120 had the same problem as far as I > > remember. > > > > Medium: Panasonic 3x > > > > Could not find any kernel error messages. > > I have: > Host: scsi1 Channel: 00 Id: 00 Lun: 00 > Vendor: HL-DT-ST Model: DVDRAM GSA-4160B Rev: A300 > Type: CD-ROM ANSI SCSI revision: 02 > > I also notice this with 2.6.10. I think I also had it with 2.6.8.1 but I > don't remember, it's been a while. The media I use is maxell DRM47 ver 2 I also have low write performance (around 300 kb/s) with several 2.6 kernels (2.6.7 to 2.6.9-mm1) and I can hear the head jump around when I use ext2 or UDF. It will be fast when written directly to the device without a file system using dd. The drive is a LG GSA-4040B. I tried several media types from Panasonic and EMTEC. I'll try to test if the problem disappears with 2.6.6. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Problem] slow write to dvd-ram since 2.6.7-bk8
On Wed, Feb 16, 2005 at 23:29:24 +0100, Droebbel wrote:
> On Mi, 2005-02-16 at 22:55 +0100, Droebbel wrote:
> >Some new information:
> >
> >2.6.7 is ok, 2.6.7-mm2 is not ok, 2.6.7 with just the linus-patch from
> >mm2 is ok, 2.6.7 with linus.patch from mm3 isn't.
> >So I took some of the patches from the broken-out mm2 and tested them
> >seperately.
> >
> >The vmscan-dont-reclaim-too-many-pages.patch led to the said reduction
> >of writing speed. I reverse-applied it to 2.6.8.1, where it seems to
> >solve the problem.
>
> Sorry, have to correct that: it seemed to help at my tests with dd
> (write 1G of zeroes to a file). Copying a file with mc still shows
> around 1.4MB/s. Could be worse, but is definitely not ok. It *is* better
> with 2.6.7.
Here are some numbers with my setup. I always wrote 1 GB of data to the
same DVD-RAM disc (EMTEC), to the device directly and to a fresh ext2
on
the disc.
kernel 2.6.10:
$ time { sudo dd if=/dev/zero of=bigfile bs=64k count=16000 ; sync ; }
real32m5.025s
$ time {sudo dd if=/dev/zero of=/dev/cdrom bs=64k count=16000 ; sync ;}
real29m41.980s
kernel 2.6.7:
$ time { sudo dd if=/dev/zero of=bigfile bs=64k count=16000 ; sync ; }
real13m23.688s
$ time {sudo dd if=/dev/zero of=/dev/cdrom bs=64k count=16000 ; sync ;}
real13m14.609s
Regards,
Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Strage buffer behaviour
Hi folks, I noticed that the kernel (2.6.23.1) seems to buffer only certain partitions on my system: $ for i in 1 2 3 4 ; do for j in 1 2 ; do dd if=/dev/sda$i of=/dev/null bs=1024k count=100 ; done ; done 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 3.01471 seconds, 34.8 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.86945 seconds, 36.5 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 2.92038 seconds, 35.9 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 3.00272 seconds, 34.9 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 4.07722 seconds, 25.7 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.0944248 seconds, 1.1 GB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 5.61527 seconds, 18.7 MB/s 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.331822 seconds, 316 MB/s The dd command reads 100 MB from each partition two times in a row. It looks like sda1 and sda2 are not bufferd (the first 4 dd runs), but sda3 and sda4 are (the last 4 dd runs). The computer is a Mac mini with a 2,5" SATA hard disk. The first 2 partitions contain EFI and MacOS X, and are unused in Linux. The last 2 partitions are an ext3 partition for / and an LVM for the rest of the sytem. Any hints how the dd/buffering behaviour could be explained? The system was mostly idle, and the numbers are reproducible across reboots. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
XFS related Oops
Hi,
after resume from suspend with 2.6.23.1, I got the following Oops:
BUG: unable to handle kernel paging request at virtual address 3e0d204c
printing eip:
c022807f
*pde =
Oops: [#1]
SMP
Modules linked in: dvb_usb_cinergyT2 i915 drm cpufreq_stats usblp
firewire_ohci firewire_core dvb_usb crc_itu_t evdev snd_hda_intel
rtc_cmos sky2 dvb_core applesmc led_class coretemp hwmon
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.23.1 #4)
EIP is at xfs_iget_core+0x6f/0x690
eax: 0033f000 ebx: 3e0d2010 ecx: f7826000 edx: 0033f000
esi: 001346d7 edi: ebp: f7525214 esp: f68b7cb4
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process squid (pid: 2967, ti=f68b6000 task=f6833030 task.ti=f68b6000)
Stack: c024f1b1 0001 f6a3d6c0 001346d7 f789ce00 c18993d8 c04fb280
f7525218
f7826000 e652c240 3e0d2010 e652c25c
e652c240
001346d7 f7826000 c0228774 001346d7
f68b7d80
Call Trace:
[] kmem_zone_alloc+0x51/0xb0
[] xfs_iget+0xd4/0x160
[] xfs_dir_lookup_int+0x9b/0x100
[] xfs_lookup+0x75/0xa0
[] xfs_vn_lookup+0x54/0x90
[] do_lookup+0x122/0x1a0
[] __link_path_walk+0x784/0xd80
[] __next_cpu+0x12/0x30
[] find_busiest_group+0x19d/0x6a0
[] link_path_walk+0x45/0xc0
[] process_timeout+0x0/0x10
[] get_unused_fd_flags+0x52/0xc0
[] do_path_lookup+0x73/0x1b0
[] get_empty_filp+0x58/0x120
[] __path_lookup_intent_open+0x51/0xa0
[] path_lookup_open+0x20/0x30
[] open_namei+0x66/0x640
[] lock_timer_base+0x27/0x60
[] try_to_del_timer_sync+0x45/0x50
[] do_filp_open+0x2e/0x60
[] process_timeout+0x0/0x10
[] get_unused_fd_flags+0x52/0xc0
[] do_sys_open+0x4c/0xe0
[] sys_open+0x1c/0x20
[] sysenter_past_esp+0x5f/0x85
===
Code: 44 24 1c 8b 44 24 1c e8 60 92 1b 00 8b 5d 00 85 db 89 5c 24 34 75
14 e9 90 00 00 00 8b 5b 04 85 db 89 5c 24 34 0f 84 81 00 00 00 <8b> 53
3c 8b 43 38 31 fa 31 f0 09 c2 75 e3 8d 83 dc 00 00 00 e8
EIP: [] xfs_iget_core+0x6f/0x690 SS:ESP 0068:f68b7cb4
Does this ring any bells?
Regards,
Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: XFS related Oops
On Tue, Nov 13, 2007 at 09:27:20 +1100, David Chinner wrote: [...] > No. I'd say something got screwed up during suspend/resume. Is it > reproducable? No. I often use suspend to RAM, and usually it works without such failures. I restart squid during the resume prosecure, and the above Oops lead to a squid in D state. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc1: USB hard disk broken
Hi,
I just tried 2.6.23-rc1 and shortly after the boot my external USB hard
disk went mad.
I all started with these kernel messages:
kern.info: usb 1-6: USB disconnect, address 5
kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00
kern.warn: end_request: I/O error, dev sdb, sector 68479
kern.alert: I/O error in filesystem ("dm-2") meta-data dev dm-2 block 0x6c7fa20
("xfs_trans_read_buf") error 5 buf count 8192
The full kernel log can be found here:
http://tikei.de/kernel.log
And the config:
http://tikei.de/kernel.config
Needless to say that it all worked fine with 2.6.22.
Regards,
Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1: USB hard disk broken
On Wed, Jul 25, 2007 at 10:24:36 +0200, Oliver Neukum wrote: > Am Mittwoch 25 Juli 2007 schrieb Tino Keitel: > > Hi, > > > > I just tried 2.6.23-rc1 and shortly after the boot my external USB hard > > disk went mad. [...] > Please recompile with CONFIG_USB_DEBUG set. > > Regards > Oliver I tried, but it didn't happen again. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1: USB hard disk broken
On Thu, Jul 26, 2007 at 10:06:40 +0200, Oliver Neukum wrote: > Am Mittwoch 25 Juli 2007 schrieb Tino Keitel: > > On Wed, Jul 25, 2007 at 10:24:36 +0200, Oliver Neukum wrote: > > > Am Mittwoch 25 Juli 2007 schrieb Tino Keitel: > > > > Hi, > > > > > > > > I just tried 2.6.23-rc1 and shortly after the boot my external USB hard > > > > disk went mad. > > > > [...] > > > > > Please recompile with CONFIG_USB_DEBUG set. > > > > > > Regards > > > Oliver > > > > I tried, but it didn't happen again. > > Did you try with the old kernel again? This bug may be related to timing. I tried again -rc1 without USB_DEBUG, and was able to reproduce the bug 2 times. At the second time, the kernel log shows this: 2007-08-05_10:30:27.75572 kern.err: ehci_hcd :00:1d.7: dev 6 ep1in scatterli st error 0/-121 2007-08-05_10:30:27.86576 kern.info: usb 1-6: reset high speed USB device using ehci_hcd and address 5 2007-08-05_10:30:55.95293 kern.info: usb 1-6: USB disconnect, address 5 2007-08-05_10:30:55.95300 kern.err: ehci_hcd :00:1d.7: dev 6 ep1in scatterlist error -108/-108 2007-08-05_10:30:55.95310 kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00 2007-08-05_10:30:55.95314 kern.warn: end_request: I/O error, dev sdb, sector 594818327 2007-08-05_10:30:55.95321 kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00 2007-08-05_10:30:55.95325 kern.warn: end_request: I/O error, dev sdb, sector 594818567 2007-08-05_10:30:55.95331 kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00 2007-08-05_10:30:55.95335 kern.warn: end_request: I/O error, dev sdb, sector 594818583 2007-08-05_10:30:55.95342 kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00 2007-08-05_10:30:55.95352 kern.warn: end_request: I/O error, dev sdb, sector 594818823 2007-08-05_10:30:55.95356 kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00 2007-08-05_10:30:55.95360 kern.warn: end_request: I/O error, dev sdb, sector 594818327 2007-08-05_10:30:55.95455 kern.info: sd 4:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x00 2007-08-05_10:30:55.95461 kern.warn: end_request: I/O error, dev sdb, sector 594818327 2007-08-05_10:30:55.96972 kern.err: scsi 4:0:0:0: rejecting I/O to dead device 2007-08-05_10:30:55.96977 kern.err: scsi 4:0:0:0: rejecting I/O to dead device The "scatterlist" line wasn't there in the other cases. I'll try again with the latest git. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1: USB hard disk broken
On Sun, Aug 05, 2007 at 13:09:42 +0200, Tino Keitel wrote: > On Thu, Jul 26, 2007 at 10:06:40 +0200, Oliver Neukum wrote: > > Am Mittwoch 25 Juli 2007 schrieb Tino Keitel: > > > On Wed, Jul 25, 2007 at 10:24:36 +0200, Oliver Neukum wrote: > > > > Am Mittwoch 25 Juli 2007 schrieb Tino Keitel: > > > > > Hi, > > > > > > > > > > I just tried 2.6.23-rc1 and shortly after the boot my external USB > > > > > hard > > > > > disk went mad. > > > > > > [...] > > > > > > > Please recompile with CONFIG_USB_DEBUG set. > > > > > > > > Regards > > > > Oliver > > > > > > I tried, but it didn't happen again. > > > > Did you try with the old kernel again? This bug may be related to timing. > > I tried again -rc1 without USB_DEBUG, and was able to reproduce the > bug 2 times. At the second time, the kernel log shows this: Now I tried current git d4ac2477fad0f2680e84ec12e387ce67682c5c13 and I can still reproduce it. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page Cache Question
On Sun, Aug 05, 2007 at 09:32:59 -0700, Adnan Khaleel wrote: > > I'm looking for a way to disable the page cache for an > experimental NUMA system running the 2.6.17 kernel. I would prefer to > only disable the page cache for my process and still have it be enabled > by the rest of the system. Is there an easy way of doing this? > Alternatively, I would be fine disabling the Page Cache altogether as well. Maybe this helps for you: http://lwn.net/Articles/224653/ Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1: USB hard disk broken
On Thu, Aug 09, 2007 at 16:00:13 -0400, Alan Stern wrote: [...] > What makes you think the problem you see is the same as the one > described by Tino? Do you get the "scatterlist error 0/-121" line in > your log? > > Please provide a dmesg log showing your problem with CONFIG_USB_DEBUG > enabled. I'll try to reproduce the problem with the commit reverted, but not before Sunday evening. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23 - MacMini - snd-hda-intel stopped working
On Sun, Oct 21, 2007 at 23:08:32 -0400, Parag Warudkar wrote: > Ubuntu kernel 2.6.22-10 works fine - I get sound although volume > control doesn't seem to work. > > With 2.6.23 (today's git actually) I get this error on loading snd-hda-intel - > > [ 672.830052] PCI: Setting latency timer of device :00:1b.0 to 64 > [ 673.061586] hda_codec: STAC922x, Apple subsys_id=106b0800 > [ 673.471059] ACPI: PCI interrupt for device :00:1b.0 disabled > [ 673.471367] HDA Intel: probe of :00:1b.0 failed with error -16 Not that this would help you a lot, but it worked with a stock 2.6.23 kernel here: 2007-10-19_05:56:58.01014 kern.info: hda_codec: STAC922x, Apple subsys_id=106b0800 2007-10-19_05:56:58.01015 kern.info: usblp0: USB Bidirectional printer dev 11 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6004 What model do you have? Mine is the first dual core version (1,66 GHz, Superdrive) I attached my kernel config, for the case that this makes any difference. Regards, Tino # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23.1 # Wed Oct 17 21:36:22 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y
Re: How to interpret PM_TRACE output
On Wed, Dec 20, 2006 at 16:19:04 +, Pavel Machek wrote: > Hi! > > > > > I tried PM_TRACE to find the driver that breaks resume from suspend. > > > > I got working resume until I switched to the sk98lin driver > > > > (because sky2 doesn't support wake on LAN). That's why I was quite sure > > > > that > > > > sk98lin is the culprit, but I tried PM_TRACE anymay. > > > > > > See Doc*/power/*. > > > > There is a nice mixture of documentation about swusp, video stuff, > > developer documentation, and one short paragraph about PM_TRACE that > > tells me nothing new. Could you point me to the documentation part that > > you are referring to, and that tells me what to do if PM_TRACE shows > > the usb device but the failure only occurs when I load the sk98lin > > driver? > > Hmmm, so it fails somewhere in usb only if sk98lin is loaded? If you > unload it again, resume works? Are usb interrupts shared? Where Yes, it works with sky2. Yes, the USB device that is reported to fail by PM_TRACE shares the interrupt with eth0, which is sk98lin (see my original posting in this thread). > exactly in the usb does it fail? I don't know, all I have is the PM_TRACE output. Meanwhile, tried to remove uhci_hcd before suspend, and wakeup works then. However, my DVB-T box is dead after resume (reloading the driver doesn't work, only unplug/replug the device helps). It works with suspend to disk, though. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NAK new drivers without proper power management?
On Sun, Feb 11, 2007 at 07:46:36 +0100, Willy Tarreau wrote: [...] > Many people also have Linux on their notebooks, but as a dual-boot. You > read the word ? "dual-boot". It means that they cleanly shutdown their > system every time they don't use it anymore, and they won't know what > OS they'll use next time. I can suspend to disk my Mac mini, reboot into MacOS X, shutdown, and then resume in Linux. I also did this with APM suspend to disk support on my ThinkPad some years ago, using Linux and Windows. So, dualboot and suspend support isn't mutual exclusive. This is only the case if suspend is limited to suspend to RAM. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to interpret PM_TRACE output
Hi folks, I tried PM_TRACE to find the driver that breaks resume from suspend. I got working resume until I switched to the sk98lin driver (because sky2 doesn't support wake on LAN). That's why I was quite sure that sk98lin is the culprit, but I tried PM_TRACE anymay. Here is the PM_TRACE output in dmesg: Magic number: 0:150:255 hash matches drivers/base/power/resume.c:28 hash matches device :00:1d.3 $ lspci | grep 1d.3 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 /proc/interrupts: 17: 52387 0 IO-APIC-level uhci_hcd:usb5, eth0, [EMAIL PROTECTED]::00:02.0 20:12231051222776 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb2 Since UHCI #4 (usb5, as ehci is usb1) and eth0 (sk98lin) use the same interrupt, is it right to assume that the sk98lin driver does bad interrupt handling and therefore breaks the usb5 device on resume? Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to interpret PM_TRACE output
On Sat, Dec 16, 2006 at 08:57:48 +, Pavel Machek wrote: > On Wed 13-12-06 22:22:59, Tino Keitel wrote: > > Hi folks, > > > > I tried PM_TRACE to find the driver that breaks resume from suspend. > > I got working resume until I switched to the sk98lin driver > > (because sky2 doesn't support wake on LAN). That's why I was quite sure that > > sk98lin is the culprit, but I tried PM_TRACE anymay. > > See Doc*/power/*. There is a nice mixture of documentation about swusp, video stuff, developer documentation, and one short paragraph about PM_TRACE that tells me nothing new. Could you point me to the documentation part that you are referring to, and that tells me what to do if PM_TRACE shows the usb device but the failure only occurs when I load the sk98lin driver? Thanks and regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo
Hi folks, I tried 2.6.20-rc3 and suspend to RAM is now broken. The screen stays dark after resume, the same with the network link. It worked with 2.6.18 (I skipped 2.6.19 because of a regression in the sky2 driver). I enabled pm_trace and did a echo mem > /sys/power/state in single user mode. After the reboot, all I got from pm_trace is this: ACPI: (supports S0 S3 S4 S5) Magic number: 0:798:636 hash matches drivers/base/power/resume.c:46 Freeing unused kernel memory: 228k freed This is line 46 in resume.c: TRACE_RESUME(error); No information about the device/driver that refuses to resume. I think that this is a regression, as it worked with 2.6.18 and the kernel config is the same. The hardare is a Mac mini Core Duo. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo
On Sun, Jan 07, 2007 at 13:23:13 -0500, Lee Revell wrote: > On Sun, 2007-01-07 at 16:17 +0100, Tino Keitel wrote: > > No information about the device/driver that refuses to resume. > > You should be able to identify the problematic driver by removing each > driver manually before suspending. I can not reproduce it anymore, resume now works. I really hope that it will stay so. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo
On Sun, Jan 07, 2007 at 21:04:53 +0100, Tino Keitel wrote: > On Sun, Jan 07, 2007 at 13:23:13 -0500, Lee Revell wrote: > > On Sun, 2007-01-07 at 16:17 +0100, Tino Keitel wrote: > > > No information about the device/driver that refuses to resume. > > > > You should be able to identify the problematic driver by removing each > > driver manually before suspending. > > I can not reproduce it anymore, resume now works. I really hope that it > will stay so. It didn't. It looks like it is unusable, becuase it isn't reliable in 2.6.20-rc3. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo
On Mon, Jan 08, 2007 at 00:44:45 +0100, Adrian Bunk wrote: > On Sun, Jan 07, 2007 at 11:27:06PM +0100, Tino Keitel wrote: > > On Sun, Jan 07, 2007 at 21:04:53 +0100, Tino Keitel wrote: > > > On Sun, Jan 07, 2007 at 13:23:13 -0500, Lee Revell wrote: > > > > On Sun, 2007-01-07 at 16:17 +0100, Tino Keitel wrote: > > > > > No information about the device/driver that refuses to resume. > > > > > > > > You should be able to identify the problematic driver by removing each > > > > driver manually before suspending. > > > > > > I can not reproduce it anymore, resume now works. I really hope that it > > > will stay so. > > > > It didn't. It looks like it is unusable, becuase it isn't reliable in > > 2.6.20-rc3. > > Is this issue still present in -rc4? I used 2.6.20-rc4 in single user mode, and applied 2 patches from netdev to get wake on LAN support. This way I was able to set up an automatic suspend/resume loop. It looked good, but after e.g. 20 minutes, the resume hang. So it is reproduceable with 2.6.20-rc4. Unfortunately, I can not test the same with 2.6.18, as the wake on LAN patches need 2.6.20-rc. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo
On Mon, Jan 08, 2007 at 17:17:19 +0100, Pavel Machek wrote: > On Sun 2007-01-07 23:27:06, Tino Keitel wrote: > > On Sun, Jan 07, 2007 at 21:04:53 +0100, Tino Keitel wrote: > > > On Sun, Jan 07, 2007 at 13:23:13 -0500, Lee Revell wrote: > > > > On Sun, 2007-01-07 at 16:17 +0100, Tino Keitel wrote: > > > > > No information about the device/driver that refuses to resume. > > > > > > > > You should be able to identify the problematic driver by removing each > > > > driver manually before suspending. > > > > > > I can not reproduce it anymore, resume now works. I really hope that it > > > will stay so. > > > > It didn't. It looks like it is unusable, becuase it isn't reliable in > > 2.6.20-rc3. > > What was last working version? Can you pinpoint driver breaking it? I just used 2.6.18.2 with a manual driven suspend/resume loop and fully loaded userspace for ca. 40 minutes, without a failure. I tried to pinpoint the driver with pm_trace, without success (see my original posting). Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo
On Tue, Jan 09, 2007 at 22:51:04 +0800, Luming Yu wrote: > >> > It didn't. It looks like it is unusable, becuase it isn't reliable in > >> > 2.6.20-rc3. > >> > >> Is this issue still present in -rc4? > > > >I used 2.6.20-rc4 in single user mode, and applied 2 patches from > >netdev to get wake on LAN support. This way I was able to set up an > >automatic suspend/resume loop. It looked good, but after e.g. 20 > >minutes, the resume hang. So it is reproduceable with 2.6.20-rc4. > >Unfortunately, I can not test the same with 2.6.18, as the wake on LAN > >patches need 2.6.20-rc. > > Hmm, do you mean this is the first time of this kind of testing? > Is this issue related to LAN driver? > I guess you should be able to set up an automatic suspend/resume loop > with /proc/acpi/alarm, and test similar with 2.6.18. Thanks for the hint. I just used /proc/acpi/alarm to set up a suspend/resume loop and did ca. 100 cycles in a row with 2.6.18.2 in single user mode, without a failure. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo
On Fri, Jan 12, 2007 at 14:50:25 +, Pavel Machek wrote: > Hi! > > > > >> > It didn't. It looks like it is unusable, becuase it isn't reliable in > > > >> > 2.6.20-rc3. > > > >> > > > >> Is this issue still present in -rc4? > > > > > > > >I used 2.6.20-rc4 in single user mode, and applied 2 patches from > > > >netdev to get wake on LAN support. This way I was able to set up an > > > >automatic suspend/resume loop. It looked good, but after e.g. 20 > > > >minutes, the resume hang. So it is reproduceable with 2.6.20-rc4. > > > >Unfortunately, I can not test the same with 2.6.18, as the wake on LAN > > > >patches need 2.6.20-rc. > > > > > > Hmm, do you mean this is the first time of this kind of testing? > > > Is this issue related to LAN driver? > > > I guess you should be able to set up an automatic suspend/resume loop > > > with /proc/acpi/alarm, and test similar with 2.6.18. > > > > Thanks for the hint. I just used /proc/acpi/alarm to set up a > > suspend/resume loop and did ca. 100 cycles in a row with 2.6.18.2 in > > single user mode, without a failure. > > Can you do similar test on 2.6.20 -- w/o network driver loaded (and > generaly minimum drivers?) I think I found the problem. In 2.6.18, I had a slightly different config. With 2.6.20-rc4, I had sucessful suspend/resume cycles without the USB DVB-T box attached. I tweaked the USB options a bit and activated some options (CONFIG_USB_SUSPEND, CONFIG_USB_MULTITHREAD_PROBE, CONFIG_USB_EHCI_SPLIT_ISO, CONFIG_USB_EHCI_ROOT_HUB_TT, CONFIG_USB_EHCI_TT_NEWSCHED) and now I can suspend/resume without hangs. At least I haven't seen one until now. Thanks for you patience and regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo
On Sat, Jan 13, 2007 at 04:05:28 +0100, Tino Keitel wrote: [...] > I think I found the problem. In 2.6.18, I had a slightly different > config. With 2.6.20-rc4, I had sucessful suspend/resume cycles without > the USB DVB-T box attached. I tweaked the USB options a bit and > activated some options (CONFIG_USB_SUSPEND, > CONFIG_USB_MULTITHREAD_PROBE, CONFIG_USB_EHCI_SPLIT_ISO, > CONFIG_USB_EHCI_ROOT_HUB_TT, CONFIG_USB_EHCI_TT_NEWSCHED) and now I can > suspend/resume without hangs. At least I haven't seen one until now. Just after I sent the mail, I had 2 failures again. :-( Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo
On Sat, Jan 13, 2007 at 04:45:12 +0100, Tino Keitel wrote: > On Sat, Jan 13, 2007 at 04:05:28 +0100, Tino Keitel wrote: > > [...] > > > I think I found the problem. In 2.6.18, I had a slightly different > > config. With 2.6.20-rc4, I had sucessful suspend/resume cycles without > > the USB DVB-T box attached. I tweaked the USB options a bit and > > activated some options (CONFIG_USB_SUSPEND, > > CONFIG_USB_MULTITHREAD_PROBE, CONFIG_USB_EHCI_SPLIT_ISO, > > CONFIG_USB_EHCI_ROOT_HUB_TT, CONFIG_USB_EHCI_TT_NEWSCHED) and now I can > > suspend/resume without hangs. At least I haven't seen one until now. > > Just after I sent the mail, I had 2 failures again. :-( PM_TRACE revealed that the Ethernet driver (sky2) failed to resume. I removed the patches for wake on LAN and hope that it works now. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: rtc_cmos: error after first write to wakealarm
On Tue, Jun 19, 2007 at 14:24:04 +0200, Alessandro Zummo wrote: > On Fri, 15 Jun 2007 09:03:19 +0200 > Tino Keitel <[EMAIL PROTECTED]> wrote: > > > > > I have the following strange behaviour with rtc_cmos: > > > > > > > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm > > > > bash: echo: write error: Device or resource busy > > > > $ rmmod rtc_cmos > > > > $ modprobe rtc_cmos > > > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm > > > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm > > > > bash: echo: write error: Device or resource busy > > > > $ > > > > > > If the alarm has already been enabled, you cannot set the next > > > alarm. You should disable first. > > > > Ah, ok. > > > > Where is the documentation that describes that I have to disable it > > first, and how to do this? A migration document for > > /proc/acpi/alarm users would be nice, too. > > Well, I guess there is no documentation. Maybe we could add > a dev_warn with an explicit message. Isn't it somewhat ridiculous to plan the removal of a feature for several months, and then replace it with something that behaves differently without any documentation? I don't know if there is any centralized form sysfs documentation. I guess not. So at least a short text like the one below somewhere in Documentation/ would be useful. I still wonder how 'cat /sys/class/rtc/rtcX/wakealarm' is expected to behave. With 2.6.22-rc5, I get this: $ echo 1182351177 > /sys/class/rtc/rtc0/wakealarm $ cat /sys/class/rtc/rtc0/wakealarm 2051644873 There seems to be a constant difference of 869984896 seconds. Is this a bug? --- How to use /sys/class/rtc/rtcX/wakealarm This file takes the seconds since epoch to enable a wake event at the specified time. If a '0' is written, the alarm is disabled. If the alarm was already enabled, a new alarm can only be set after the old alarm is disabled. Migration from /proc/acpi/alarm ^^^ Users of /proc/acpi/alarm have to change their code to supply the seconds since epoch instead of a date string. For shell scripts, this can be done using the date command, e.g. like this: date -d tomorrow "+%s" This returns the seconds since epoch of the current time on the following day. Please note that you have to disable the old alarm first, if you want to set a new alarm. Otherwise, you get an error. Example: echo 12345 > /sys/class/rtc/rtc0/wakealarm echo 0 > /sys/class/rtc/rtc0/wakealarm echo 23456 > /sys/class/rtc/rtc0/wakealarm --- Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] Re: rtc_cmos: error after first write to wakealarm
On Fri, Jun 22, 2007 at 11:45:52 -0700, David Brownell wrote: > On Friday 22 June 2007, Alessandro Zummo wrote: > > On Tue, 19 Jun 2007 19:24:29 +0200 > > Tino Keitel <[EMAIL PROTECTED]> wrote: > > > > > > > Where is the documentation that describes that I have to disable it > > > > > first, and how to do this? A migration document for > > > > > /proc/acpi/alarm users would be nice, too. > > > > > > > > Well, I guess there is no documentation. Maybe we could add > > > > a dev_warn with an explicit message. > > > > > > Isn't it somewhat ridiculous to plan the removal of a feature for > > > several months, and then replace it with something that behaves > > > differently without any documentation? > > It's got as much documentation in the kernel tree as that > old /proc/acpi/alarm thing. More, in fact, since the GIT > comment for the putback creating /sys/rtc/.../wakealarm > files has lots of info about how to use it. What GIT comment are you referring to? > > But sure, having documentation for the rtc sysfs interface > would be a Fine Thing. It should cover the other values > too, not just that one attribute. > > > > > I still wonder how 'cat /sys/class/rtc/rtcX/wakealarm' is expected to > > > behave. With 2.6.22-rc5, I get this: > > > > > > $ echo 1182351177 > /sys/class/rtc/rtc0/wakealarm > > > $ cat /sys/class/rtc/rtc0/wakealarm > > > 2051644873 > > > > > > There seems to be a constant difference of 869984896 seconds. Is this a > > > bug? > > What RTC driver is that using? rtc_cmos > > One theory: it's an RTC that doesn't support all the fields, > so its driver is returning "-1" in fields like "year" or "month". With the old /proc/acpi/alarm, the year 2007 became 0007. Maybe this is the culprit? Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bad behaviour after hdparm -M 128
On Thu, Jun 07, 2007 at 22:50:04 -0300, Henrique de Moraes Holschuh wrote:
[...]
> I just tracked it down to hdparm. Version 6.9 (the one in Debian stable)
> doesn't work right with libata. Version 7.5 (the one in Debian unstable)
> works fine.
>
> So, at least in my side, there are *no* kernel bugs. Maybe this is also the
> case for the poster that reported the problem?
I also use Debian unstable.
Here is the relevant part of the hdparm -I output:
/dev/sda:
ATA device, with non-removable media
Model Number: ST98823AS
Serial Number: 5PK0GTK8
Firmware Revision: 7.01
Standards:
Supported: 7 6 5 4
Likely used: 7
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBAuser addressable sectors: 156301488
LBA48 user addressable sectors: 156301488
device size with M = 1024*1024: 76319 MBytes
device size with M = 1000*1000: 80026 MBytes (80 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific
minimum
R/W multiple sector transfer: Max = 16 Current = ?
Advanced power management level: unknown setting (0x8080)
Recommended acoustic management value: 128, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5
*udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Commands/features:
Enabled Supported:
*SMART feature set
Security Mode feature set
*Power Management feature set
*Write cache
*Look-ahead
*Host Protected Area feature set
*WRITE_BUFFER command
*READ_BUFFER command
*DOWNLOAD_MICROCODE
*Advanced Power Management feature set
SET_MAX security extension
*48-bit Address feature set
*Device Configuration Overlay feature set
*Mandatory FLUSH_CACHE
*FLUSH_CACHE_EXT
*SMART error logging
*SMART self-test
*WRITE_{DMA|MULTIPLE}_FUA_EXT
*IDLE_IMMEDIATE with UNLOAD
*SATA-I signaling speed (1.5Gb/s)
*Native Command Queueing (NCQ)
*Phy event counters
Device-initiated interface power management
*Software settings preservation
*SMART Command Transport (SCT) feature set
Regards,
Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RTC_DRV_CMOS can break userspace interface
On Mon, Jun 04, 2007 at 13:14:58 +0100, Matthew Garrett wrote: > On Mon, Jun 04, 2007 at 11:35:18AM +0200, Tino Keitel wrote: > > (By the way, it helps if you Cc: me - it's easy to lose track of > things > in the LKML noise) > > > Here it is: > > > > state = active > > io 0x70-0x77 > > options > > Yes, there's no IRQ listed. Can you try current git? OK, it works with git 99f9f3d49cbc7d944476f6fde53a77ec789ab2aa (something after -rc4). I can echo something into /sys/class/rtc/rtc0/wakealarm and the machine will wake up from suspend to RAM. However, a minor glitch remains: $ echo 1181672013 > /sys/class/rtc/rtc0/wakealarm - suspend - wait for wakeup After wakeup: $ cat /sys/class/rtc/rtc0/wakealarm 2051656909 Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
rtc_cmos: error after first write to wakealarm
Hi, I have the following strange behaviour with rtc_cmos: $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm bash: echo: write error: Device or resource busy $ rmmod rtc_cmos $ modprobe rtc_cmos $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm bash: echo: write error: Device or resource busy $ The kernel is git eedab661a51966c454e38c17266a531aa58b4a98 (something after 2.6.22-rc4). Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtc_cmos: error after first write to wakealarm
On Fri, Jun 15, 2007 at 15:59:04 +0900, Yoichi Yuasa wrote: > On Fri, 15 Jun 2007 08:33:08 +0200 > Tino Keitel <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I have the following strange behaviour with rtc_cmos: > > > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm > > bash: echo: write error: Device or resource busy > > $ rmmod rtc_cmos > > $ modprobe rtc_cmos > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm > > bash: echo: write error: Device or resource busy > > $ > > If the alarm has already been enabled, you cannot set the next alarm. > You should disable first. Ah, ok. Where is the documentation that describes that I have to disable it first, and how to do this? A migration document for /proc/acpi/alarm users would be nice, too. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC_DRV_CMOS can break userspace interface
On Mon, May 28, 2007 at 14:06:52 -0700, David Brownell wrote:
[...]
> That seems to be true. And those particular users should learn the
> portable /sys/class/rtc/rtc0/wakealarm syntax ... e.g. using numeric
> seconds-since-epoch ("date '+%s'") instead of strings the kernel needs
> to parse. That way, they can start converting usage sooner.
Hi,
I use /proc/acpi/alarm a lot and tried to learn how to use
/sys/class/rtc/rtc0/wakealarm. However, I have no /sys/class/rtc/rtc0
until I load the rtc-test driver. I tried all RTC drivers that are
available in 2.6.21, without success:
$ grep RTC /boot/config-2.6.21
CONFIG_RTC=y
# CONFIG_HPET_RTC_IRQ is not set
# CONFIG_SND_RTCTIMER is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
# RTC interfaces
CONFIG_RTC_INTF_SYSFS=y
# CONFIG_RTC_INTF_PROC is not set
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# RTC drivers
CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_M48T86=m
CONFIG_RTC_DRV_TEST=m
CONFIG_RTC_DRV_V3020=m
In dmesg, I see these messages from RTC_DRV_CMOS:
rtc_cmos 00:09: rtc core: registered rtc_cmos as rtc0
rtc_cmos: probe of 00:09 failed with error -16
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
So all I can do is to continue to use /proc/acpi/alarm.
Regards,
Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RTC_DRV_CMOS can break userspace interface
On Thu, May 31, 2007 at 11:26:04 +0100, Matthew Garrett wrote: > On Thu, May 31, 2007 at 06:32:29AM +0200, Tino Keitel wrote: > > > rtc_cmos 00:09: rtc core: registered rtc_cmos as rtc0 > > rtc_cmos: probe of 00:09 failed with error -16 > > drivers/rtc/hctosys.c: unable to open rtc device (rtc0) > > Try unsetting CONFIG_RTC - you can't use the legacy driver at the same > time as the new one. Yes, you are right. I think this issue should be covered by Kconfig. However: $ cat wakealarm cat: wakealarm: Input/output error It worked with /proc/acpi/alarm before. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RTC_DRV_CMOS can break userspace interface
On Fri, Jun 01, 2007 at 13:54:23 +0100, Matthew Garrett wrote: > On Fri, Jun 01, 2007 at 09:46:06AM +0200, Tino Keitel wrote: > > Yes, you are right. I think this issue should be covered by Kconfig. > > > > However: > > > > $ cat wakealarm > > cat: wakealarm: Input/output error > > > > It worked with /proc/acpi/alarm before. > > Can you do > > for i in /sys/bus/pnp/devices/*; do if [ "$(cat $i/id)" = PNP0b00 ]; > then cat $i/resources; echo options; cat $i/options; fi; done Here it is: state = active io 0x70-0x77 options Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bad behaviour after hdparm -M 128
Hi, I tried to enable acoustic management on my SATA drive, because hdparm -I reported a recommended value of 128, and a current value of 0 (off). I did this: $ sudo hdparm -M 128 /dev/sda /dev/sda: setting acoustic management to 128 HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error acoustic = not supported It apperently failed, no big deal. However, I had these messages in the kernel log, and they don't look really harmless to me: ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.01: cmd ef/42:80:00:00:00/00:00:00:00:00/50 tag 0 cdb 0x0 data 0 res 51/04:80:00:00:00/00:00:00:00:00/50 Emask 0x1 (device error) ata3.01: configured for UDMA/133 ata3: EH complete SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Is this expected behaviour? I used kernel 2.6.21 with the libata PIIX SATA driver and a Seagate ST98823AS drive. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
possible USB regression with 2.6.21-rc4: iPod doesn't work
Hi folks, I plugged my iPod nano 8 GB in and got this message with 2.6.21-rc4: hub 1-0:1.0: over-current change on port 1 along with other USB error messages. I tried a hub with own power supply and a USB port on the computer. A full log is attached. When I boot with 2.6.20, it works: usb 1-5.1: new high speed USB device using ehci_hcd and address 13 usb 1-5.1: configuration #1 chosen from 2 choices scsi5 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 13 usb-storage: waiting for device to settle before scanning scsi 5:0:0:0: Direct-Access AppleiPod 1.62 PQ: 0 ANSI: 0 SCSI device sdc: 3964928 2048-byte hdwr sectors (8120 MB) Is the over-current message an indication that the hardware does bad things, or is this a .21-rc4 bug? Regards, Tino kernlog-ipod.bz2 Description: Binary data
Re: 2.6.21-rc suspend regression
On Wed, Mar 21, 2007 at 23:54:04 +0100, Frédéric RISS wrote: > My MacMini (Intel Core Duo, EFI mode) doesn't come out of suspend to ram I tested suspend to RAM today with my mini. It also failed to resume. I don't use EFI but boot via GRUB. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Thu, Mar 22, 2007 at 09:50:29 +0100, Oliver Neukum wrote: > Am Mittwoch, 21. März 2007 21:47 schrieb Tino Keitel: > > > along with other USB error messages. I tried a hub with own power > > supply and a USB port on the computer. A full log is attached. > > Your log basically shows a hub going berserk. Please post "lsusb -v" > and your .config I didn't tried just the external hub. I also tried a USB port on the computer. I'll collect the requested information this evening. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Thu, Mar 22, 2007 at 09:50:29 +0100, Oliver Neukum wrote: > Am Mittwoch, 21. März 2007 21:47 schrieb Tino Keitel: > > > along with other USB error messages. I tried a hub with own power > > supply and a USB port on the computer. A full log is attached. > > Your log basically shows a hub going berserk. Please post "lsusb -v" > and your .config Both files are attached. Regards, Tino lsusb.txt.bz2 Description: Binary data config-2.6.21-rc4.bz2 Description: Binary data
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Thu, Mar 22, 2007 at 15:40:40 -0400, Alan Stern wrote: > On Thu, 22 Mar 2007, Tino Keitel wrote: > > > On Thu, Mar 22, 2007 at 09:50:29 +0100, Oliver Neukum wrote: > > > Am Mittwoch, 21. März 2007 21:47 schrieb Tino Keitel: > > > > > > > along with other USB error messages. I tried a hub with own power > > > > supply and a USB port on the computer. A full log is attached. > > > > > > Your log basically shows a hub going berserk. > > Or a bad USB transceiver. _Something_ is generating those overcurrent > warnings, and it sure looks like a hardware malfunction. But it works with 2.6.20. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Thu, Mar 22, 2007 at 14:29:11 -0700, David Brownell wrote: > On Thursday 22 March 2007 12:54 pm, Tino Keitel wrote: > > On Thu, Mar 22, 2007 at 15:40:40 -0400, Alan Stern wrote: > > > _Something_ is generating those overcurrent > > > warnings, and it sure looks like a hardware malfunction. > > > > But it works with 2.6.20. > > So can you bisect to find what caused the problem? I never did use git-bisect, but maybe I find the time next week. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clockevents: Fix suspend/resume to disk hangs
On Fri, Mar 23, 2007 at 10:14:11 +0100, Marcus Better wrote: > Marcus Better wrote: > > The XFS workqueue patch [1] fixes my problem [2]. > > > [1] http://permalink.gmane.org/gmane.linux.kernel/507616 > > [2] http://permalink.gmane.org/gmane.linux.kernel/505570 > > Unfortunately it only fixed suspend to RAM. Suspend to disk still hangs > at "snapshotting system". Will try to bisect it... I don't know if this is related, but using 2.6.21-rc4 and suspend2 2.2.9.7, I also get a hang at suspend. I could try if this also happens with 2.6.20 and the same suspend2 version. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Thu, Mar 22, 2007 at 20:42:44 +0100, Oliver Neukum wrote: > Am Donnerstag, 22. März 2007 20:17 schrieb Tino Keitel: > > On Thu, Mar 22, 2007 at 09:50:29 +0100, Oliver Neukum wrote: > > > Am Mittwoch, 21. März 2007 21:47 schrieb Tino Keitel: > > > > > > > along with other USB error messages. I tried a hub with own power > > > > supply and a USB port on the computer. A full log is attached. > > > > > > Your log basically shows a hub going berserk. Please post "lsusb -v" > > > and your .config > > > > Both files are attached. > > Please recompile > with CONFIG_USB_DEBUG > and without CONFIG_USB_SUSPEND With CONFIG_USB_SUSPEND disabled, the iPod works. The dmesg output is attached. Regards, Tino dmesg.bz2 Description: Binary data dmesg_with_USB_SUSPEND.bz2 Description: Binary data
Re: [PATCH 0/6] UDF cleanup and fixes
On Thu, Apr 12, 2007 at 18:01:12 +0200, Jan Kara wrote: > On Wed 04-04-07 08:36:20, Tino Keitel wrote: > > On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: > > > > [...] > > > > > Well, it works for me on 32-bit as well, right up to 100% full. > > > No problems at all... > > > > Maybe it depends on the kernel. I patched 2.6.20 with the patches > > above and got the described behaviour. > I've sent you an email with a few questions but probably it got lost in > the noise... Are you able to reproduce the problem? Have you reproduced the > problem on a freshly created UDF image or was it some older image? Hi, I can't remember of any errors in the kernel or about not available space. It was an image file that I expermimented with, and I did multiple mkudffs runs on the file. Could it be that the behaviour was caused by stale data inside the image? Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Mon, Mar 26, 2007 at 14:12:25 -0400, Alan Stern wrote: > On Sun, 25 Mar 2007, Tino Keitel wrote: > > > > Please recompile > > > with CONFIG_USB_DEBUG > > > and without CONFIG_USB_SUSPEND > > > > With CONFIG_USB_SUSPEND disabled, the iPod works. The dmesg output is > > attached. > > In fact, both logs (with and without CONFIG_USB_SUSPEND) show the iPod > working. Can you post a log with CONFIG_USB_DEBUG turned on that shows > any errors? Attached is a dmesg output with CONFIG_USB_DEBUG and CONFIG_USB_SUSPEND enabled. There are no messages from the iPod because, well, nothing happens when I plug it in. I tried it 3 times. The strange thing is: when I trigger a suspend or shutdown, then the "Do not disconnect" message shows up on the iPod, which means that the computer regognized it as a storage device. Regards, Tino dmesg-with-usb_suspend.bz2 Description: Binary data
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Mon, Mar 26, 2007 at 16:28:34 -0400, Alan Stern wrote: > On Mon, 26 Mar 2007, Tino Keitel wrote: > > > Attached is a dmesg output with CONFIG_USB_DEBUG and CONFIG_USB_SUSPEND > > enabled. > > > > There are no messages from the iPod because, well, nothing happens when > > I plug it in. I tried it 3 times. > > I don't understand. The dmesg log you attached shows the iPod was > detected and recognized as scsi5 (sdc). Then some time later (can't tell > how much later because you don't have CONFIG_PRINTK_TIME set) it was > unplugged and plugged back in. The second time it was detected and > recognized as scsi6 (also sdc). And then the log ends. Not in the attached dmesg output from the above mail. There are not iPod related messages it it, but I plugged it in 2 times. I rebootet with the same kernel version without CONFIG_USB_SUSPEND right after this and the iPod was recognized at the first try. > > Why do you say there are no messages from the iPod? Grepping for "iPod" > in the log shows that the string appears 4 times. If nothing happened > when you plugged it in, how could the computer have known the device was > an iPod? > > > The strange thing is: when I trigger > > a suspend or shutdown, > > You mean you suspend or shutdown the computer? Or the iPod? The computer. > > > then the "Do not disconnect" message shows up on > > the iPod, which means that the computer regognized it as a storage > > device. > > What's so strange about that? Isn't that exactly what's supposed to > happen? Well, it isn't recognized by a normal running system, only during shutdown/suspend. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Mon, Mar 26, 2007 at 17:15:53 -0400, Alan Stern wrote: [...] > The lack of messages from the iPod seems to indicate that the hub isn't > working right. You could try plugging the iPod into a different hub or > directly into the computer. Or maybe into a different port of that hub. I already tried all of the above options, with the same result. Note that all other USB devices (keyboard, mouse, hard disk with /home, DVB-T box etc.) work fine. I'm currently bisecting. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Mon, Mar 26, 2007 at 17:15:53 -0400, Alan Stern wrote: [...] > The lack of messages from the iPod seems to indicate that the hub isn't > working right. You could try plugging the iPod into a different hub or > directly into the computer. Or maybe into a different port of that hub. Uh, I think I found the reason for the strange behaviour at shutdown/suspend. When I unload the usblp module, then the iPod is recognized. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Mon, Mar 26, 2007 at 23:26:14 +0200, Tino Keitel wrote: > On Mon, Mar 26, 2007 at 17:15:53 -0400, Alan Stern wrote: > > [...] > > > The lack of messages from the iPod seems to indicate that the hub isn't > > working right. You could try plugging the iPod into a different hub or > > directly into the computer. Or maybe into a different port of that hub. > > I already tried all of the above options, with the same result. Note > that all other USB devices (keyboard, mouse, hard disk with /home, > DVB-T box etc.) work fine. > > I'm currently bisecting. Hi, this is the bisect result: $ git bisect good 1d619f128ba911cd3e6d6ad3475f146eb92f5c27 is first bad commit commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27 Author: Marcelo Tosatti <[EMAIL PROTECTED]> Date: Sun Jan 21 19:45:59 2007 -0200 USB: switch ehci-hcd to new polling scheme Switch ehci-hcd to use the new polling scheme, which reports root hub status changes via the interrupt handler, in an asynchronous fashion. Doing so disables polling for status changes (whose handler is rh_timer_func). Tested on a Geode GX machine, which is now capable of running at =~ 5 timer interrupts per second (in the -rt tree), resulting in significant power savings. Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]> Cc: David Brownell <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> :04 04 f8b11b3fe3cec62063d8da0f7be807341106f494 78c5a156897b3ad7aef27823d48a546fdda2c0d2 M drivers Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] possible USB regression with 2.6.21-rc4: iPod doesn't work
On Tue, Mar 27, 2007 at 00:21:24 +0200, Tino Keitel wrote: [...] > this is the bisect result: > > $ git bisect good > 1d619f128ba911cd3e6d6ad3475f146eb92f5c27 is first bad commit > commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27 I just tested 2.6.21-rc5 with this commit reverted and the iPod was regognized with CONFIG_USB_SUSPEND enabled. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: > Hello, > > the patches attached to six following emails implement some cleanup and > fixes in the UDF code. The main two fixes are: > 1) UDF now works correctly for files larger than 1GB. Hi, I tried 2.6.20 with your patches and got the following behaviour: $ ls -la dvd.udf -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf $ mount -o loop -t udf dvd.udf /media/udf/ $ df /media/udf/ Filesystem 1K-blocks Used Available Use% Mounted on /home/storage/dvd.udf 4588506 -8584746354 8589334860 - /media/udf ^^ $ ls -la /media/udf/ total 4587521 drwxr-xr-x 3 root root144 Mar 29 15:36 . drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Fri, Mar 30, 2007 at 14:06:34 -0400, Chuck Ebbert wrote: > Tino Keitel wrote: > > On Tue, Mar 06, 2007 at 17:44:47 +0100, Jan Kara wrote: > >> Hello, > >> > >> the patches attached to six following emails implement some cleanup and > >> fixes in the UDF code. The main two fixes are: > >> 1) UDF now works correctly for files larger than 1GB. > > > > Hi, > > > > I tried 2.6.20 with your patches and got the following behaviour: > > > > $ ls -la dvd.udf > > -rw-r--r-- 1 root root 4699717632 Mar 29 15:36 dvd.udf > > $ mount -o loop -t udf dvd.udf /media/udf/ > > $ df /media/udf/ > > Filesystem 1K-blocks Used Available Use% Mounted on > > /home/storage/dvd.udf > >4588506 -8584746354 8589334860 - /media/udf > >^^ > > $ ls -la /media/udf/ > > total 4587521 > > drwxr-xr-x 3 root root144 Mar 29 15:36 . > > drwxr-xr-x 9 root root 1024 Mar 20 12:02 .. > > -rw-r--r-- 1 root root 4697620480 Mar 29 15:57 bk_usr.tar > > drwxr-xr-x 2 root root 40 Mar 29 15:36 lost+found > > > > Is that on a 32-bit machine? Yes, it's an Intel Core Duo. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] UDF cleanup and fixes
On Mon, Apr 02, 2007 at 10:48:27 -0400, Chuck Ebbert wrote: [...] > Well, it works for me on 32-bit as well, right up to 100% full. > No problems at all... Maybe it depends on the kernel. I patched 2.6.20 with the patches above and got the described behaviour. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [4/4] 2.6.23-rc3: known regressions v3
On Fri, Aug 24, 2007 at 10:56:08 -0700, Greg KH wrote: > On Fri, Aug 24, 2007 at 07:38:40PM +0200, Michal Piotrowski wrote: > > Hi all, > > > > Here is a list of some known regressions in 2.6.23-rc3. > > First off, thanks so much for tracking these, it can't be an easy job, > but one that is really needed. Keep up the great work. > > > USB > > > > Subject : 2.6.23-rc1: USB hard disk broken > > References : http://lkml.org/lkml/2007/7/25/62 > > Last known good : ? > > Submitter : Tino Keitel <[EMAIL PROTECTED]> > > Caused-By : ? > > Handled-By : Oliver Neukum <[EMAIL PROTECTED]> > > Status : unknown > > Last I heard was that Tino was going to try to do further testing, but > as he hasn't responded in a few weeks, I'd mark this one down to, > "unknown and unreproducable". Unless someone else knows more? I was at least able to reproduce it with 2.6.23-rc2. And I tried it hard with 2.6.22 but it didn't happen. Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
