Re: [PATCH v2] New Nokia RX-51 power supply battery driver

On Sat 2013-03-30 11:35:26, Anton Vorontsov wrote: > On Sat, Mar 30, 2013 at 07:07:05PM +0100, Pavel Machek wrote: > > On Wed 2012-10-31 10:48:40, Pali Rohár wrote: > > > Hello, I fixed style issues and added it to Makefile and Kconfig. > > > > > > power_su

Re: New copyfile system call - discuss before LSF?

On Sat 2013-03-30 13:08:39, Andreas Dilger wrote: > On 2013-03-30, at 12:49 PM, Pavel Machek wrote: > > Hmm, really? AFAICT it would be simple to provide an > > open_deleted_file("directory") syscall. You'd open_deleted_file(), > > copy source file into

Re: New copyfile system call - discuss before LSF?

Hi! > >>> Hmm, really? AFAICT it would be simple to provide an > >>> open_deleted_file("directory") syscall. You'd open_deleted_file(), > >>> copy source file into it, then fsync(), then link it into filesystem. > >>> > >>> That should have atomicity properties reflected. > >> > >> Actually, the

Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround

Hi! > >You can do without ret variable... Also more detailed changelog would > >be nice... like what exact problem this works around. > > > > Sure i can, but I don't see a reason to ignore SM's return value. Changelog > of what? > > I guess if you read the thread over the ML you'll have your

Re: New copyfile system call - discuss before LSF?

Hi! On Sat 2013-03-30 22:38:35, AEDilger Gmail wrote: > On 2013-03-30, at 14:45, Pavel Machek wrote: > > On Sat 2013-03-30 13:08:39, Andreas Dilger wrote: > >> On 2013-03-30, at 12:49 PM, Pavel Machek wrote: > >>> Hmm, really? AFAICT it would be simple to prov

openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

> > > > Hmm. open_deleted_file() will still need to get a directory... so it > > > > will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED) would > > > > be acceptable interface? > > > > > > ...and what's the big plan to make this work on anything other than ext4 > > > and btrfs? > > >

Freescale FEC: fall back to random address

If there's no valid ethernet address, fall back to randomly generated one. (Yes, I need to get newer u-boot for the board, but as the only available one is from 2009... this might be good idea). Signed-off-by: Pavel Machek index e3f3937..5a7d1e1 100644 pp--- a/drivers/net/ethernet/free

Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

On Sun 2013-03-31 18:44:53, Myklebust, Trond wrote: > On Sun, 2013-03-31 at 20:32 +0200, Pavel Machek wrote: > > > > > > Hmm. open_deleted_file() will still need to get a directory... so it > > > > > > will still need a path. Perhaps open("

Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

Hi! > Take a look at how many actively used filesystems out there that have > some variant of sillyrename(), and explain what you want to do in those > cases. > >>>Well. Yes, there are non-unix filesystems around. You have to deal > >>>with silly files on them, and this will not be dif

Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF?

Hi! > >>User wants to test for a file with name "foo.txt" > >> > >>* create "foo.txt~" (or whatever) > >>* write contents into "foo.txt~" > >>* rename "foo.txt~" to "foo.txt" > >> > >>Until rename is done, the file does not exists and is not complete. > >>You will potentially have a garbage file t

UIO device tree bindings.

Hi! I'd like to get uio device tree bindings to work -- with recent FPGA parts it will be important. Latest version I see is https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073087.html ... Is there anything newer? I red the discussion, and main problem seems to be the "tell kernel to

Re: UIO device tree bindings.

On Mon 2013-04-01 16:23:36, Pavel Machek wrote: > Hi! > > I'd like to get uio device tree bindings to work -- with recent FPGA > parts it will be important. Latest version I see is > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073087.html > > ... Is

Re: [RFC PATCH 0/5] Add support for S3 non-stop TSC support.

Hi! > >>>On some new Intel Atom processors (Penwell and Cloverview), there is > >>>a feature that the TSC won't stop S3, say the TSC value won't be > >>>reset to 0 after resume. This feature makes TSC a more reliable > >>>clocksource and could benefit the timekeeping code during system > >>>suspen

3.9-rc1 regression in arm dtb build

Hi! Commit commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8 Author: Grant Likely Date: Tue Nov 27 16:29:11 2012 -0700 The current rules have the .dtb files build in a different directory from the .dts files. The only reason for this is that it was what PowerPC has done historic

Re: 3.9-rc1 regression in arm dtb build

On Wed 2013-03-06 20:45:57, Thomas Petazzoni wrote: > Dear Pavel Machek, > > On Wed, 6 Mar 2013 20:33:32 +0100, Pavel Machek wrote: > > > Moves dtb files from arch/arm/boot/ to arch/arm/boot/dtb. That causes > > several problems: > > > > 1) it is inconsisten

Re: 3.9-rc1 regression in arm dtb build

Hi! > > commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8 > > Author: Grant Likely > > Date: Tue Nov 27 16:29:11 2012 -0700 ... > > 1) it is inconsistent with 3.8, making switching between 3.9-rc1 and > > 3.8 tricky > > It's pretty easy to locate the DTB by automatically looking in > arch/*/boot/

Re: 3.9-rc1 regression in arm dtb build

On Sun 2013-03-10 22:05:46, Olof Johansson wrote: > On Thu, Mar 07, 2013 at 01:50:54PM -0700, Stephen Warren wrote: > > On 03/07/2013 07:45 AM, Pavel Machek wrote: > > > Hi! > > >>> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8 > > >>> Author: G

Re: [linux-pm] [PATCH] ACPI: replace strlen("string") with sizeof("string") -1

On Thu 2012-07-26 21:39:38, Len Brown wrote: > ...both give the number of chars in the string > without the '\0', as strncmp() wants, > but sizeof() is compile-time. What about introducing something like streq() to do this automatically? This is ugly #define streq(a, b) ... if (_buildin_const

Re: [PATCH] PM / Freezer: Fix small typo "regrigerator"

On Tue 2012-08-21 22:36:15, Sedat Dilek wrote: > Noticed when digging into a suspend issue in linux-next (next-20120821). > > For more details see . > > Signed-off-by: Sedat Dilek ACK. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pic

Re: [PATCH v2 1/5] x86, fpu: decouple non-lazy/eager fpu restore from xsave

Hi! irely omitted. > and restore using xsave. The kernel will fallback to > enabling legacy floating-point and sse state. > > + eagerfpu= [X86] > + on enable eager fpu restore > + off disable e

Re: Tracking down suspend/resume ext3/mmc issues on imx233

On Mon 2012-09-10 12:33:45, Theodore Ts'o wrote: > On Mon, Sep 10, 2012 at 10:11:48AM -0500, Matt Sealey wrote: > > Wouldn't it be better if the root filesystem was marked as > > non-removable in the device tree - or in the case of a truly removable > > card, just marked in the MMC subsystem - and

Re: 2.6.25-rc2-mm1 (build failure)

Hi! > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/ > > > > When SMP=n, x86_64 build gets: > > > > arch/x86/kernel/built-in.o: In function `acpi_save_state_mem': > > (.text+0xfd7f): undefined reference to `setup_trampoline' > > make[1]: *** [.tmp_vm

Re: [linux-pm] sleepy linux self-test

Hi! > > > > +config PM_WAKEALARM_TEST > > > > + bool "Test suspend/resume and wakealarm during bootup" > > > > + depends on SUSPEND && PM_DEBUG && RTC_LIB > > > > I guess it also should depend on CONFIG_RTC_DRV_CMOS (not being a module) > > and !CONFIG_RTC. > > No -- we need a *generi

Re: [patch] suspend/resume self-test

edlessly, on this hardware), > which now makes Linux unhappy. > > Workaround in both cases was to take the memory card out before booting. > > Also includes some Kconfig tweaks to help reduce configuration bugs on > x86, by avoiding the legacy RTC driver whe

Re: WARN_ON(): proc_dir_entry 'rtc' already registered

Hi! > > I'm getting this during bootup: > > > > PM: Adding info for No Bus:event6 > > PM: Adding info for No Bus:uinput > > PM: Adding info for No Bus:rtc0 > > proc_dir_entry 'rtc' already registered > > Pid: 1, comm: swapper Not tainted 2.6.25-rc1 #125 > > ... deletia > > =

tsc breaks atkbd suspend

nohz=off fixes that. notsc fixes that, too... On my system (thinkpad x60 in UP mode) tsc is normally marked unstable very shortly after boot, so only sleepy test can trigger this. I believe it is very bad idea to use tsc, it does n

Re: tsc breaks atkbd suspend

Hi! > > I'm trying to use the "sleepy test" here, unfortunately it locks for > > 10-or-so seconds. > > > > Problem is in wait_event_timeout: timeouts take about 100x as long as > > they should. Code in drivers/input/serio/libps2.c: > > > > + printk("ps2_command waiting event: %d\n", timeou

Re: 2.6.25-rc2 hangs after "Suspending console(s)"

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

Status of storage autosuspend

Hi! What is the status of USB storage/SCSI autosuspend patches? They work nicely here ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Status of storage autosuspend

Hi! > > What is the status of USB storage/SCSI autosuspend patches? They work > > nicely here ;-). > > I could submit them, but there is one outstanding problem I would like > to solve first. Maybe you can suggest a solution. > > The problem is how to handle SG_IOCTL calls. It seems that the o

Re: WARN_ON(): proc_dir_entry 'rtc' already registered

On Mon 2008-02-18 03:08:16, David Brownell wrote: > On Monday 18 February 2008, Pavel Machek wrote: > > > How to fix ... how about:  instead of just warning folk > > > off such legacy RTC drivers [1] we just wrap them with > > > an "if RTC_LIB != n" so this

notsc is ignored on common configurations

notsc is ignored in 32-bit kernels if CONFIG_X86_TSC is on.. which is bad, fix it. Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c index fafd9dc..3804fbe 100644 --- a/arch/x86/kernel/tsc_32.c +++ b/arch/x86/kernel/ts

Re: tsc breaks atkbd suspend

On Mon 2008-02-18 16:12:40, Thomas Gleixner wrote: > On Mon, 18 Feb 2008, Pavel Machek wrote: > > > I do not understand, what you mean. When exactly is "sleeppy test" > > > running ? > > > > from late_initcall(). > > Has the system already switc

Re: [patch] suspend/resume self-test

On Mon 2008-02-18 12:16:24, David Brownell wrote: > On Monday 18 February 2008, Ingo Molnar wrote: > > > > * David Brownell <[EMAIL PROTECTED]> wrote: > > > > > > >   - Includes a command line parameter, which needs work yet ... it > > > > >     currently turns this test off, but it should also l

Re: notsc is ignored on common configurations

On Tue 2008-02-19 12:26:32, Ingo Molnar wrote: > > * Pavel Machek <[EMAIL PROTECTED]> wrote: > > > notsc is ignored in 32-bit kernels if CONFIG_X86_TSC is on.. which is > > bad, fix it. > > thanks, applied. > > > -static unsigned int ref_freq = 0; >

Re: tsc breaks atkbd suspend

TSC is used even on machines when CONFIG_X86_TSC is not set (X86_TSC means _require_ TSC), but it is not properly disabled when it is unusable, because acpi code understood the config switch as "may use TSC". This actually fixes suspend problems on my x60. Signed-off-by: Pavel Mach

Re: tsc breaks atkbd suspend

Hi! This is wrong: #ifdef CONFIG_X86_TSC static int __init tsc_setup(char *str) { printk(KERN_WARNING "notsc: Kernel compiled with CONFIG_X86_TSC, " "cannot disable TSC.\n"); return 1; } #else /* * disable flag for tsc. Takes effect by clearing the

Re: [PATCH] enclosure: add support for enclosure services

On Wed 2008-02-13 09:45:02, Kristen Carlson Accardi wrote: > On Tue, 12 Feb 2008 13:28:15 -0600 > James Bottomley <[EMAIL PROTECTED]> wrote: > > > On Tue, 2008-02-12 at 11:07 -0800, Kristen Carlson Accardi wrote: > > > I understand what you are trying to do - I guess I just doubt the > > > value y

Re: arch/x86/kernel/acpi/sleep_32.c not compiled ?

On Tue 2008-02-19 22:02:52, Rafael J. Wysocki wrote: > On Tuesday, 19 of February 2008, Thomas Petazzoni wrote: > > Hi, > > Hi, > > > Maybe I'm missing something completely obvious, but I don't see where > > the arch/x86/kernel/acpi/sleep_32.c file gets compiled. The Makefile in > > that director

Re: [PATCH 0/8][for -mm] mem_notify v6

On Tue 2008-02-19 09:00:08, Paul Jackson wrote: > Kosaki-san wrote: > > Thank you for wonderful interestings comment. > > You're most welcome. The pleasure is all mine. > > > you think kill the process just after swap, right? > > but unfortunately, almost user hope receive notification before sw

Re: arch/x86/kernel/acpi/sleep_32.c not compiled ?

On Wed 2008-02-20 00:41:46, Rafael J. Wysocki wrote: > On Tuesday, 19 of February 2008, Pavel Machek wrote: > > On Tue 2008-02-19 22:02:52, Rafael J. Wysocki wrote: > > > On Tuesday, 19 of February 2008, Thomas Petazzoni wrote: > > > > Hi, > > > >

Re: ipw3945: not only it periodically dies, it also BUG()s

Hi! > > unfortunately the link here does not work. > > The instructions on how to report a bug have been updated to address the > above issues. Thank you very much for helping us to make it better. Thanks. One more nit: [EMAIL PROTECTED] seems like normal bugzilla, where you can hit reply but

Re: Disk schedulers

Hi! > whom should I blame about disk schedulers? > > I have the following setup: > 1Gb network > 2GB RAM > disk write speed about 20MB/s > > If I'm scping file (about 500MB) from the network (which is faster than the > local disk), any process is totally unable to read anything from the local >

Re: [PATCH] Document huge memory/cache overhead of memory controller in Kconfig

Hi! > >> I know this is a pedantic comment, but why the heck is it called such > >> a generic term as "Memory Controller" which doesn't give any > >> indication of what it does. > >> > >> Shouldn't it be something like "Memory Quota Controller", or "Memory > >> Limits Controller"? > > > >It's cal

Re: [PATCH] Document huge memory/cache overhead of memory controller in Kconfig

On Wed 2008-02-20 19:28:03, Jan Engelhardt wrote: > > On Feb 20 2008 18:19, Pavel Machek wrote: > >> > >> For ordinary desktop people, memory controller is what developers > >> know as MMU or sometimes even some other mysterious piece of silicon > >>

power_state: remove it from driver core

power_state is scheduled for removal, and it is used only for debug prints by driver core. Remove it. Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index d180795..268855d 100644 --- a/drivers/base/power/main.c +++ b/d

make clean does not remove vmlinux.bin.all

...which is pretty big... arch/x86/boot/compressed$ du -sh * 16K relocs 8.4Mvmlinux.bin.all (note that I'm using separate object/source directories, but it should not matter here). Pavel -- (english) http://www.livejournal.

power_state: get rid of write-only variable in SATA

power_state is scheduled for removal, and libata uses it in write-only mode. Remove it. Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index b4985bc..a31572d 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/

power_state: remove it from usb

power_state is scheduled for removal, and it is used only write-only by USB. Remove it. Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c index 801b6f1..eeb8115 100644 --- a/drivers/usb/core/driver.c +++ b/drivers/us

Re: Feature Removal - power_state

use it were broken. Drivers should instead be exposing domain-specific > interfaces either to kernel or to userspace. > Who: Pavel Machek <[EMAIL PROTECTED]> ...but it is not easy. Most uses are write only (and easy to kill), but at least radeon driver uses it for real. T

separate object directories: trap for user

Hi! I'm using separate object directories, but there's trap there which catches me every now and then: (/data/l/linux are my sources, objects are in /data/l/b-linux) Every now and then, I make a mistake and try to make kernel in source directories... that does not work as expected: [EMAIL PROT

Re: power_state: remove it from usb

On Fri, 22 Feb 2008 00:38:14 +0100 Krzysztof Halasa <[EMAIL PROTECTED]> wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > I'm personally of the opinion that a lot of checkpatch "fixes" are > > anything but. That mainly concerns fixing overlong lines > > Perhaps we should increase line l

Re: [PATCH] Document huge memory/cache overhead of memory controller in Kconfig

Hi! > > > >> For ordinary desktop people, memory controller is what developers > > > >> know as MMU or sometimes even some other mysterious piece of silicon > > > >> inside the heavy box. > > > > > > > >Actually I'd guess 'memory controller' == 'DRAM controller' == part of > > > >northbridge

Re: distributed module configuration

Hi! > > Does this fit what you had in mind? > > Yes it does. > > Now I'll ask if you think embedding this information in one of the C > files for a module would be even nicer? I kind of like to be able to grep over just Kconfig files, to find out what is going on... -- (english) http://www.liv

Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

Hi! > It's "snapshot-and-restore", and my opinion is that: > > - it should *never* call "suspend()"/"resume()" at all (that should be >reserved purely for suspend-to-RAM and has real power management >issues!) Hmm, entering S4 seems like good place to call suspend() for... unless you w

Re: [PATCH v2] power: add knob for printing device resume times

On Sat 2012-06-16 15:57:37, Rafael J. Wysocki wrote: > On Friday, June 15, 2012, Greg KH wrote: > > On Fri, Jun 15, 2012 at 12:00:20PM +0200, Rafael J. Wysocki wrote: > > > On Friday, June 15, 2012, Greg KH wrote: > > > > On Wed, May 23, 2012 at 09:45:32AM -0700, Sameer Nanda wrote: > > > > > Added

ipw3945: not only it periodically dies, it also BUG()s

Hi! Under not-even-high load, it periodically restarts: Feb 5 21:08:50 amd kernel: iwl3945: Microcode SW error detected. Restarting 0x8208. Feb 5 21:08:52 amd kernel: iwl3945: Can't stop Rx DMA. Feb 5 21:12:51 amd kernel: iwl3945: Microcode SW error detected. Restarting 0x8208. Feb 5

Re: brk randomization breaks columns

mize_va_space > to default to 1, and if a user or distro disables it, it will default to > 2. I named it slightly differently, but idea is same. Heap randomization breaks ancient binaries, so disable it by default. Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> diff --git a/fs/

Re: brk randomization breaks columns

On Tue 2008-02-05 17:09:13, Ingo Molnar wrote: > > * Pavel Machek <[EMAIL PROTECTED]> wrote: > > > > From: Jiri Kosina <[EMAIL PROTECTED]> > > > > > > brk: check the lower bound properly > > > > > > There is a check in sys_brk()

Re: ipw3945: not only it periodically dies, it also BUG()s

On Tue 2008-02-05 22:44:41, Pavel Machek wrote: > Hi! > > Under not-even-high load, it periodically restarts: > > Feb 5 21:08:50 amd kernel: iwl3945: Microcode SW error detected. > Restarting 0x8208. > Feb 5 21:08:52 amd kernel: iwl3945: Can't stop Rx DMA. &g

Re: 2.6.26-git0: IDE oops during boot

On Wed 2008-02-06 11:53:34, Pavel Machek wrote: > Hi! > > Trying to boot 2.6.25-git0 (few days old), I get > > BUG: unable to handle kernel paging request at ..ffb0 > IP at init_irq+0x42e > > Call trace: > ide_device_add_all > ide_generic_init > kernel

Re: [rft] s2ram wakeup moves to .c, could fix few machines

On Tue 2008-02-05 17:51:22, H. Peter Anvin wrote: > Rafael J. Wysocki wrote: >>> The asm() for making beeps really need to be moved to a function and >>> cleaned up (redone in C using inb()/outb()) if they are to be retained at >>> all. >> >> Yes, they are. For some people they're the only tool

any cpu hotplug changes in 2.6.24-current-git?

Hi! Are there any recent changes in cpu hotplug? I have suspend (random) problems, nosmp seems to fix it, and last messages in the "it hangs" case are from cpu hotplug... Pavel -- (english) http://www.livejournal.com/~pavelma

Re: PCIE ASPM support hangs my laptop pretty often

On Tue 2008-02-05 16:22:55, Kok, Auke wrote: > ?? ??? wrote: > > I've patched my kernel with the PCIe ASPM and after setting > > echo powersave > /sys/module/pcie_aspm/parameters/policy > > > > I started to experience random hangs of my laptop. > > Hardware info: > >

Re: ipw3945: not only it periodically dies, it also BUG()s

On Tue 2008-02-05 18:20:58, Chatre, Reinette wrote: > On Tuesday, February 05, 2008 1:45 PM, Pavel Machek wrote: > > > > > ...I've reported this before, with full debugging. Not sure if > > anything happened. > > Could you please point me to where you hav

Re: ipw3945: not only it periodically dies, it also BUG()s

Hi! > >>> ...I've reported this before, with full debugging. Not sure if > >>> anything happened. > >> > >> Could you please point me to where you have reported it before? > > > > From [EMAIL PROTECTED] Wed Oct 31 01:52:02 2007 > >

Re: [linux-pm] Re: Small pm documentation cleanups

On Thu 2008-02-07 08:27:03, Nigel Cunningham wrote: > Hi again. > > Pavel Machek wrote: >> Hi! >> >>>> On Tuesday, 5 of February 2008, Pavel Machek wrote: >>>>> Small documentation fixes/additions that accumulated in my tree. >>>>> &

Re: any cpu hotplug changes in 2.6.24-current-git?

Hi! >> Are there any recent changes in cpu hotplug? I have suspend (random) >> problems, nosmp seems to fix it, and last messages in the "it hangs" >> case are from cpu hotplug... > Can you send along your cpuinfo? It happened on more than one machine, one cpuinfo is: processor : 1 vend

Re: any cpu hotplug changes in 2.6.24-current-git?

On Wed 2008-02-06 19:49:19, Gregory Haskins wrote: > Pavel Machek wrote: >> Hi! >> >> >>>> Are there any recent changes in cpu hotplug? I have suspend (random) >>>> problems, nosmp seems to fix it, and last messages in

e1000 1sec latency problem

Hi! I have the famous e1000 latency problems: 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 m

Re: [rft] s2ram wakeup moves to .c, could fix few machines

On Thu 2008-02-07 14:45:35, H. Peter Anvin wrote: > Rafael J. Wysocki wrote: > >> ENTRY(wakeup_long64) >> wakeup_long64: >> -movqsaved_magic, %rax >> -movq$0x123456789abcdef0, %rdx >> -cmpq%rdx, %rax >> -jne bogus_64_magic >> +movqsaved_magic, %rax >> +

Re: [rft] s2ram wakeup moves to .c, could fix few machines

On Thu 2008-02-07 14:46:25, H. Peter Anvin wrote: > Pavel Machek wrote: >> >> This is probably more acceptable version of beep; but there are >> probably even better ways to clean it... >> >> if (wakeup_header.realmode_flags & 4) { >>

Re: [E1000-devel] e1000 1sec latency problem

On Thu 2008-02-07 14:32:16, Kok, Auke wrote: > Pavel Machek wrote: > > Hi! > > > >>> I have the famous e1000 latency problems: > >>> > >>> 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms > >>> 64 bytes from 195.1

Re: ACPI_WMI: worst config description of all times

On Thu 2008-02-07 17:27:38, Len Brown wrote: > On Thursday 07 February 2008 16:47, Pavel Machek wrote: > > > > See? It even has completely useless help text. > > > > Does WMI stand for Windows Management Instrumentation? It is some > > server management feature

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! > > > > This rewrites wakeup code to .c, and it fixes stack (should use movl > > > > ,%esp, not movw). Testers wanted. Makefile infrastructure was done by > > > > hpa, cleanups by rjw. > > > > > > I'll test it tomorrow > > > > Works on my nx6325 (good sign, the box is easy to break ;-)). > >

Re: [E1000-devel] e1000 1sec latency problem

Hi! > > I have the famous e1000 latency problems: > > > > 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms > > 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms > > 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms > > 64 bytes from 195.113.31.123: icmp_se

ACPI_WMI: worst config description of all times

See? It even has completely useless help text. Does WMI stand for Windows Management Instrumentation? It is some server management feature? What is it good for? Pavel WMI (EXPERIMENTAL) (ACPI_WMI) [N/m/y/?] (NEW) ? This driver

iwl3945: not only it periodically dies, it also BUG()s, and oopses

> Could you please create a new bug in our bug tracking system > (www.bughost.org) to enable us to track this problem? Please include the > relevant information from the thread as well as the information you > doscovered recently. I'm connected over that iwl, so filing web form is not exactly easy

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! > > > - memcpy((void *)acpi_wakeup_address, &wakeup_start, > > > -&wakeup_end - &wakeup_start); > > > - acpi_copy_wakeup_routine(acpi_wakeup_address); > > > + memcpy((void *)acpi_realmode, &wakeup_code_start, 4*PAGE_SIZE); > > > > Using a PAGE_SIZE multiplier here isn't a good thing..

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! > > > > > + header = (struct wakeup_header *)(acpi_realmode + 0x3f00); > > > > > > > > ... especially not with magic constants like this. > > > > > > Yeah. Pavel, what's at 0x3f00, btw? > > > > struct wakeup_header. > > > > I really need the entry point to be at offset 0, so that I ca

Re: ACPI_WMI: worst config description of all times

Hi! > On Friday 08 February 2008 00:12:24 Ray Lee wrote: > > While I'm not trying to set you up for a firing squad, if you can show > > that the only use this driver has is as underlying support for Acer/HP > > xyz drivers, > > Certainly at the moment, this is the only real use it has (and the o

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! > >I really need the entry point to be at offset 0, so > >that I can get > >pointers to my data. I could not figure out how to do > >it any other > >way. And if 0 is taken, I thought I'd put header at the > >end. > > > > Why not just put the structure at 0, and put pointers in > the struc

Re: kernel BUG at kernel/power/snapshot.c:464!

Hi! > Our old friend kernel BUG at kernel/power/snapshot.c:464! is back, this > time from mainline. I can't reproduce with 2.6.24-final, but I can with > a git snapshot from a few days ago. I'm doing a git bisect run now, but > it's rather time consuming, so I thought I'd pass this on in the inter

Re: [rft] s2ram wakeup moves to .c, could fix few machines

On Fri 2008-02-08 17:23:15, Rafael J. Wysocki wrote: > On Friday, 8 of February 2008, Pavel Machek wrote: > > Hi! > > Hi, > > > > >I really need the entry point to be at offset 0, so > > > >that I can get > > > >pointers to my data.

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! > > Can you post a delta against my versoin? I do not see any changes from > > a quick glance. > > Appended (plus I removed two hunks, one in arch/x86/Makefile and one in > drivers/acpi/sleep/main.c that were unrelated to the rest of the patch). Thanks, applied. > > This is probably more ac

Re: [rft] s2ram wakeup moves to .c, could fix few machines

On Fri 2008-02-08 13:02:57, H. Peter Anvin wrote: > Pavel Machek wrote: >> On Fri 2008-02-08 17:23:15, Rafael J. Wysocki wrote: >>> On Friday, 8 of February 2008, Pavel Machek wrote: >>>> Hi! >>> Hi, >>> >>>>>> I really need the e

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! > I remember that I did about 1500 reboots to try to fix this. > (According to hard disk's 'smart' statistics) Poor you. > Suggestion: the speaker usually is quite loud, thus it can be annoying to use > for morse code or so. > Why not to use keyboard leds for this purpose? > (USB keyboard pr

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! This cleans up .lds, making use of constants... Pavel diff --git a/arch/x86/kernel/acpi/realmode/wakeup.h b/arch/x86/kernel/acpi/realmode/wakeup.h index 4a26e27..ee7c68b 100644 --- a/arch/x86/kernel/acpi/realmode/wakeup.h +++ b

Re: [rft] s2ram wakeup moves to .c, could fix few machines

On Thu 2008-02-07 23:28:33, Sam Ravnborg wrote: > > === > > --- /dev/null > > +++ linux-2.6/arch/x86/kernel/acpi/realmode/wakeup.ld > > @@ -0,0 +1,51 @@ > > +/* > > + * wakeup.ld > > + * > > + * Linker script for the real-mode wakeup c

Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines

On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote: > Pavel Machek wrote: >> >> See arch/x86/kernel/acpi/realmode/wakeup.S (the version that was sent >> to the list). No problem there, but table stored at nonzero >> offset. Short jump at the beggining of table would fix

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! >> +.section ".header", "a" >> + >> +/* This should match the structure in wakeup.h */ >> +.globl wakeup_header >> +wakeup_header: >> +video_mode: .short 0 /* Video mode number */ >> +pmode_return: .byte 0x66, 0xea /* ljmpl */ >> +.long 0

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! Rafael, this is for you. My cleanups, relative to your cleanup patch. You may need manual patching around rep/stosd. Pavel diff --git a/arch/x86/kernel/acpi/realmode/Makefile b/arch/x86/kernel/acpi/realmode/Makefile index b239f

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! > Okay, this uses the iodelay as the timesource... here is the total > silliness (and totally untested, of course.) Why untested? Testing suspend is easy ;-). s2ram from suspend.sf.net tends to just work... Pavel > static inlin

Re: [rft] s2ram wakeup moves to .c, could fix few machines

> Do we never need data from a .h file? > If we do name it wakeup.lds.S and kbuild > will fix it (assuming we have wakeup.lds > as a prerequisite where it is needed. Ok, I got it to work... but notice the ugly #undef :-(. Pavel diff --git a

Re: [rft] s2ram wakeup moves to .c, could fix few machines

On Fri 2008-02-08 23:01:51, Rafael J. Wysocki wrote: > On Friday, 8 of February 2008, Pavel Machek wrote: > > Hi! > > > > Rafael, this is for you. > > Thanks. > > > My cleanups, relative to your cleanup patch. You may need manual patching > > aroun

Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! > And for good measure name it wakeup.lds. > > Do we never need data from a .h file? > If we do name it wakeup.lds.S and kbuild > will fix it (assuming we have wakeup.lds > as a prerequisite where it is needed. This does not work for me. gas (or someone?) puts # comments on the beggining of

Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines

Hi! > > > > segments:offsets rear its ugly head here. I need %ds to point to my > > > > data, and the way to do it is copy it from %cs; that needs start to be > > > > at 0. > > > > > > Hm, why exactly is that necessay? > > > > It is not _neccessary_. Try to come up with another method that gets

Re: [linux-pm] Re: [rft] s2ram wakeup moves to .c, could fix few machines

On Fri 2008-02-08 22:56:08, Rafael J. Wysocki wrote: > On Friday, 8 of February 2008, Pavel Machek wrote: > > On Fri 2008-02-08 13:27:30, H. Peter Anvin wrote: > > > Pavel Machek wrote: > > >> > > >> See arch/x86/kernel/acpi/realmode/wakeup.S (the ver

Re: [patch] x86: add code to dump the (kernel) page tables for visual inspection

On Mon 2008-02-04 22:26:41, Arjan van de Ven wrote: > Subject: x86: add code to dump the (kernel) page tables for visual inspection > by kernel developers > From: Arjan van de Ven <[EMAIL PROTECTED]> > > This patch adds code to the kernel to have an (optional) > /proc/kernel_page_tables debug fil

Re: [PATCH] input: driver for USB VoIP phones with CM109 chipset

Hi! > + Komunikate KIP1000 Keyboard Matrix > + > + -> -- 1 -- 2 -- 3 --> GPI pin 4 (0x10) > + |||| > + <- -- 4 -- 5 -- 6 --> GPI pin 5 (0x20) > + |||| > + END - 7 -- 8 -- 9 --> GPI pin 6 (0x40) > + |||| > + OK -- * -- 0 -- # --

<    1   2   3   4   5   6   7   8   9   10   >