It's not known, no, and yeah, that's scary (and 60 seconds is long enough

that most people would have grown bored and pushed the power button for 
Do you mean that doing "date" twice does not increase the seconds? If so,

that's almost certainly related to the gaping delay. Which timer do you

end up using (what does "dmesg | grep clocksource" say)? Does adding

"clocksource=acpi_pm" to the kernel command line change things?
Also, what does your lspci look like?
		Linus

-

I discovered that SysRq-t works during the pause. So I pressed it more

or less halfway the pause; the full result is here:

http://www.dea.icai.upcomillas.es/romano/linux/info/dmesg-resume.txt
It seems that most of the tasks are in
[<c0138931>] refrigerator+0x41/0x60
So, I tried to suspend without any card in the pcmcia slot. Guess what?

I extracted the card and the system did not suspend. Just stopped dead.
Sigh.
	Romano
--

Romano Giannetti --- romano.giannetti@gmail.com

Sorry for the following disclaimer, it's attached by our otugoing server

and I cannot shut it up.
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.
-

Yeah, but the interesting one is this pair:
  events/0      R running     0     4      1 (L-TLB)
  sleep.sh      D 0000014F     0  5798   5789 (NOTLB)

  Call Trace:

   [<c01d3c01>] kobject_uevent_env+0x3a1/0x4a0

   [<c02d8509>] wait_for_completion+0x79/0xb0

   [<c0116640>] default_wake_function+0x0/0x10

   [<c0238a08>] _request_firmware+0x1c8/0x310

   [<c0238bef>] request_firmware+0xf/0x20

   [<e0a35d5d>] pcmcia_bus_match+0x28d/0x3c0 [pcmcia]

   [<c02864a7>] netlink_broadcast+0x1f7/0x310

   [<c0233d74>] driver_probe_device+0x34/0xc0

   [<c02d79ee>] klist_next+0x4e/0xa0

   [<c0233014>] bus_for_each_drv+0x44/0x70

   [<c0233eba>] device_attach+0x7a/0x80

   [<c0233e00>] __device_attach+0x0/0x10

   [<c0232f56>] bus_attach_device+0x26/0x60

   [<c0231d06>] device_add+0x5e6/0x6e0

   [<c01d350f>] kobject_init+0x2f/0x50

   [<e0a360f5>] pcmcia_device_add+0x185/0x220 [pcmcia]

   [<e0a36261>] pcmcia_card_add+0xa1/0xc0 [pcmcia]

   [<e0913900>] ti12xx_power_hook+0x180/0x1d0 [yenta_socket]

   [<e0a36300>] ds_event+0x80/0xb0 [pcmcia]

   [<e0967359>] send_event+0x39/0x70 [pcmcia_core]

   [<e09677b6>] socket_insert+0x86/0xe0 [pcmcia_core]

   [<e0967c2b>] pcmcia_socket_dev_resume+0x7b/0x90 [pcmcia_core]

   [<c01e135f>] pci_device_resume+0x1f/0x60

   [<c023815f>] resume_device+0x5f/0xf0
ie we have a deadlock because resume wants to do that firmware request,

but the event daemon is apparently spinning like mad. 
And yes, request_firmware() has a "loading_timeout" in seconds.  And

it's 60. So that explains your pause right there!
It might be some unfortunate interaction with process freezing (my

favorite whipping boy), but it could also be something else.  I suspect

we should treat suspend/resume as a bootup event, and not allow execve()

for that case at all. Right now we have:
        retval = -EPERM;

        if (current->fs->root)

  ...
[ message continues ]

If someone does request_firmware from resume function... that's
Well. we'd like to present hardware in working state as soon as we

resume (if eth0 was there before resume, it should be there after

resume. not 3 seconds after resume); so if someone needs to load the

firmware, they should just store it in the kernel memory, and load it

during boot or during (very early) suspend.
									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Equally arguably, we should just have a "resume_late()" call that can be

used to do this after everything is up and running.
And quite frankly, I don't actually see any reason why firmware loading

shouldn't work in the resume path. I really do think that this is ANOTHER

bug that has no other reason than the fact that that f*cking freezer

killed the system for no really good reason.
		Linus

-

Well, if I understand request_firmware() correctly, it does something in sysfs

and waits for the user land to react, but at this point the user land can't do

anything.
Greetings,

Rafael

-

Yes, we can do that. But userland will see devices "not there" for a

few seconds after boot.
...that is ugly, but we can survive it for ethernet cards etc... but

it will be really fatal for any block device. Pcmcia block devices

exist, so I do not think we can do that.
									Pavel
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

No they won't.
Why the HELL cannot you realize that kernel threads are different?
The right thing to do is AND HAS ALWAYS BEEN, to stop and start user

threads only around the whole thing.
Don't touch those kernel threads. Stop freezing them.
Then, what you do is:

 - stop user space

 - suspend

 - resume

 - start user space
and at no point do you touch any kernel threads.
And yes, that "resume" part is multi-phase. We already have

"resume_early()" to do bus-level setup, and then "resume()" to do the

"make devices work". I was suggesting adding a "resume_late()" phase to

let the devices do things that require other devices to work, like doing

firmware loading.
But stopping kernel threads is STUPID. As long as we continue to do that,

it will never _ever_ work.
Yeah, we could re-start the kernel thread before "resume_late()", but the

fact is, they shouldn't have been stopped in the first place.
			Linus

-

Btw, this is where things like "udevd" can be really problematic. That

whole "uevent over netlink" stuff is really nasty for things like this.
It's quite possible that even for user-level threads, we simply MUST NOT

freeze them the way we do. Exactly because of deadlocks.
I'm personally really really convinced that the whole freezer thing is a

total disaster. I don't know how anybody can even imagine anything else.

It's simply deadlock city.
We should freeze IO, not processes.
		Linus

-

Killing freezer will not help you in any way. udevd may need access to

arbitrary devices. You will still have the deadlocks, only this time

userland will be involved, too.
Just load the firmware before starting suspend.
									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

~~~~~~~~~~~

notice how resume of pcmcia card that poor user has needs
My proposed solution is "fix pcmcia to load firmware before suspend

even starts"
Maybe freezer causes cancer in small children, but lets not blame it

for this.

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

s/pcmcia/all drivers that load firmware/ if you are going to go that way.
--

  "One disk to rule them all, One disk to find them. One disk to bring

  them all and in the darkness grind them. In the Land of Redmond

  where the shadows lie." -- The Silicon Valley Tarot

  Henrique Holschuh

-

I'm not "going that way". It always was that way. If driver tries to

load firmware during suspend, it will deadlock.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Exactly.
And the freezing of user land has _nothing_ to do with that.  The fact is

the user land is not reliable while device drivers are being suspended,

regardless of whether it's frozen at that point or not.
BTW, we are going (or at least I'm going) to untangle the hibernation and

suspend code paths, but I have limited time for that and I just _can't_ do this

any faster.  In the meantime, we have bugs like this one that need to be fixed

_within_ the current limitations, because we just _can't_ remove these

limitations overnight..
Greetings,

Rafael

-

Ugh? We are talking about request_firmware() here, right? That's

calling userland helper to load the firmware...? Looks like USER

thread to me.

								Pavel
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Right. And if we had had the nice old /sbin/hotplug thing, it would all

have worked fine - because it would just have done an execve(), and things

would be happy.
But people screwed that up too, and now udevd is an undebuggable user

thread. Shit happens. See my other email about why even user threads can

probably not be frozen, and the whole freezer thing is misdesigned.
And I repeat: PowerPC had working and stable suspend five _years_ ago,

without any of that freezing crud. We should rip it out.
		Linus

-

As far as I can tell the PPC code simply shuts down the devices without

worrying about userspace at all. If this was reliable, what prevents us

from simply disabling the freezer for STR?
--

Matthew Garrett | mjg59@srcf.ucam.org

-

Personally, I think that's the right thing to do. 
And by "disabling the freezer", I think we should just not call it at all.

However, sadly, right now it's called from common code. I'll happily take

a tested patch to split that code sequence up, and try to do it in 2.6.23,

if somebody has the energy (I'm getting to the point where I may just do

it myself, but my lazy nature still hopes for a STR person to step

forward).
		Linus

-

I guess we should warn the driver authors, then; and decide what

driver authors should do.
If I'm video4linux driver for grabbing screen, have been suspended,

and someone asks me to read a frame, should I
a) return -ESORRYIMSUSPENDED
b) just block the caller
?
a) seems ugly to my eyes (userspace should not know about suspend).

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

The "subsystem" thing should have stopped the queues, and the device

should never even _see_ this.
Before we suspend a device, we call the subsystem that that device has

been registered with. Ie, we have code like this:
	if (dev->class && dev->class->suspend)

		error = dev->class->suspend(dev, state);
which was very much designed so that individual devices wouldn't have to

always know - if the upper layer devices for that class can handle these

things, they should.
Do people actually _do_ this, right now? No. But we do actually have the

infrastructure, and I think we have one or two classes that actually do

use it (at least the "rfkill_class" has a suspend member, dunno how well

this model actually works).
I think Greg had some patches to make network drivers use this, for

example. Network drivers right now all end up doing stuff that really

doesn't belong in the driver at all when they suspend, and the

infrastructure _should_ just do it for them (ie do all the _network_

related stuff, as opposed to the actual hardware-related stuff).
(Examples of things that we probably _should_ do for network devices on a

class level:
	suspend:

		netif_poll_disable()

		if (netif_running(dev))

			dev->stop(dev);
	resume:

		if (netif_running(dev))

			dev->start(dev);

		netif_poll_enable(dev);
or something similar).
			Linus

-

Okay, _if_ there's a subsystem, subsystem should have stopped the

queues. End result should be that userspace is blocked when trying to

access suspended device/suspended subsystem.
I guess we are in violent agreement.

								Pavel
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Yes, I started to work on it, as it is the correct thing to do, but got
I'll try to hack something together later this week along this line and

see how it works...
thanks,
greg k-h

-

I'll take a look at this. It probably makes sense to build on Rafael's

work on splitting the codepaths up.
--

Matthew Garrett | mjg59@srcf.ucam.org

-

Actaully, removing the freezer from the suspend code path is simple.  You only

need to remove calls to freeze_processes() and thaw_processes() from

kernel/power/main.c .
That said, I don't think that PPC does what you say only.  We've discussed this

a bit on linux-pm, in this thread:
https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012242.html
In particular, please see this message:
https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012301.html
Greetings,

Rafael

-

Yes, there's also the notifier chain for the hardware. However, very few

drivers seem to use that - adb seems to be the only one still in the

tree. For everything else, the device tree is used in exactly the same

way as on x86. If it's safe on Macs but not on x86, then (as far as I

can tell) it looks like it's only by luck.
Anyway. I've tested the following patch on a dual-core x86. No obvious

issues yet, but I'll try to put it through a few hundred cycles.
diff --git a/include/linux/pm.h b/include/linux/pm.h

diff --git a/kernel/power/main.c b/kernel/power/main.c

index 8812985..1db3012 100644

--- a/kernel/power/main.c

+++ b/kernel/power/main.c

@@ -19,7 +19,6 @@

 #include <linux/console.h>

 #include <linux/cpu.h>

 #include <linux/resume-trace.h>

-#include <linux/freezer.h>

 #include <linux/vmstat.h>
 #include "power.h"

@@ -66,9 +65,10 @@ static inline void pm_finish(suspend_state_t state)

  *	suspend_prepare - Do prep work before entering low-power state.

  *	@state:		State we're entering.

  *

- *	This is common code that is called for each state that we're

- *	entering. Allocate a console, stop all processes, then make sure

- *	the platform can enter the requested state.

+ *	This is common code that is called for each state that we're

+ *	entering. Allocate a console, then make sure the platform can

+ *	enter the requested state. This is not called for

+ *	suspend-to-disk.

  */
 static int suspend_prepare(suspend_state_t state)

@@ -81,11 +81,6 @@ static int suspend_prepare(suspend_state_t state)
 	pm_prepare_console();
-	if (freeze_processes()) {

-		error = -EAGAIN;

-		goto Thaw;

-	}

-

 	if ((free_pages = global_page_state(NR_FREE_PAGES))

 			< FREE_PAGE_NUMBER) {

 		pr_debug("PM: free some memory\n");

@@ -93,7 +88,7 @@ static int suspend_prepare(suspend_state_t state)

 		if (nr_free_pages() < FREE_PAGE_NUMBER) {

 			error = -ENOMEM;

 			printk(KERN_ERR "PM: No enough memory\n");

-			goto Thaw;

+			goto Exit...
[ message continues ]

This /mostly/ works - I've had my test machine cycling through a suspend

cycle every 10 seconds for the past hour without any difficulties

providing I unload USB first. If USB is loaded, the suspend occasionally

fails with one of the devices returning -EBUSY and causing it to be

aborted. I haven't looked into this in any detail yet, but it's

presumably sufficiently generic code that it's potentially biting people

on PPC anyway.
--

Matthew Garrett | mjg59@srcf.ucam.org

-

Most probably.
Still, please take what I said in the other thread into consideration: We've

been using the freezer for so long that at least some drivers started to rely

on it being used.
Even if there are no such drivers on your system, they can be used by other

systems.
Greetings,

Rafael

-

Sure, but if any of these drivers run on PPC then they're broken anyway.

The assumption that processes will be frozen during suspend is true in

the specific case of ACPI and some of the ARM platforms, but not true on

PPC or APM systems. We either need to fix the drivers to stop assuming

this or add the process freezer to the other PM systems. Right now,

they're buggy.
--

Matthew Garrett | mjg59@srcf.ucam.org

-

Well, PPC people are aware of this, and they think they can fix the

drivers. We probably want to drop the freezer for suspend long-term,

so. PPC machines use small subset of all the drivers, so it apparently

is not big problem for them.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

I'm fairly certain that PPC uses USB. In any case, it's not limited to

PPC - APM has the same issue. Any driver that assumes processes will be

frozen during suspend to RAM is broken now, not the future.
--

Matthew Garrett | mjg59@srcf.ucam.org

-

Yup, that's a possible view. Fixes welcome.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Hi.
The converse is also true, though. Any process that assumes processes

aren't frozen during suspend to RAM is also broken now, and will be

while we allow the possibility of suspending to ram after writing a

hibernation image.
In short, drivers should be designed to work whether processes are

frozen or not.
Regards,
Nigel

OK
I'm working on a patch that introduces hibernation/suspend notifiers.  It will

conflict with this one a bit, but OTOH it might be useful here too.
I'll post it in a while in a separate thread.
Greetings,

Rafael

-

[patch to disable freezer deleted]
First of all, excuse me for being a quite lousy tester. Could not come

around to try bisecting, no time at all. Yesterday in the autobus I gave

a shot to this "wild test" and I report the results here.
- The good (?) news. I have made 7 suspend/resume cycle (to ram, I

haven't tested hibernation) with a 2.6.21.2 with that patch, applied

manually. The system did suspend and resume nicely even compiling a

kernel and opening openoffice. Normally (le me stress _normally_) no

delay was apparent on resume. I do not know how dangerous is this... :-)
- The bad (?) news. One time out of 7 I had the 60 seconds delay. I

attach here the dmesg(s) of the resumes,  a good one, a delayed one, and

another good one after a reboot (where you can, by the way, see the

dancing serial effect... the card is sometime /dev/ttyS1,

sometime /dev/ttyS2). 
[ 1112.984000] Back to C!

[ 1112.985000] Applying VIA southbridge workaround.

[ 1112.985000] PCI: Disabling Via external APIC routing

[ 1113.418000] PM: Writing back config space on device 0000:00:00.0 at offset 1 (was 2100006, writing 12100006)

[ 1113.418000] PM: Writing back config space on device 0000:00:01.0 at offset 9 (was fff0, writing 38003800)

[ 1113.418000] PCI: Setting latency timer of device 0000:00:01.0 to 64

[ 1114.408000] ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9

[ 1114.408000] PCI: Setting latency timer of device 0000:00:07.2 to 64

[ 1114.408000] usb usb1: root hub lost power or was reset

[ 1114.481000] ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9

[ 1114.481000] PCI: Setting latency timer of device 0000:00:07.3 to 64

[ 1114.481000] usb usb2: root hub lost power or was reset

[ 1114.657000] ACPI: PCI Interrupt 0000:00:07.5[C] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5

[ 1114.657000] PCI: Setting latency timer of device 0000:00:07.5 to 64

[ 1115.347000] pccard: PCMCIA card inserted into slot 1

[ 1115....
[ message continues ]

Interesting. If you can re-create it, please do the sysrq-T thing again,

to see what's up. (Also, you might do "sysrq-p", which gives the current

process data, which sysrq-T does not).
			Linus

-

I've got it, but I had a problem: I filled the dmesg buffer. I will try

to find where to enlarge it. I have posted the partial result to: 
http://www.dea.icai.upcomillas.es/romano/linux/info/dmesg-resume-nofreez...
in the hope that something can be used. I am running 2.6.21.2, with the

"no freeze kthreads at all" patch from Matthew Garrett, with this

add-on:
--- drivers/base/firmware_class.c.orig	2007-05-30 12:19:59.000000000 +0200

+++ drivers/base/firmware_class.c	2007-05-29 19:39:56.000000000 +0200

@@ -471,7 +471,11 @@

                  struct device *device)

 {

         int uevent = 1;

-        return _request_firmware(firmware_p, name, device, uevent);

+        int rval;

+        printk(KERN_ERR "FW: requesting firmware (sync) for %s\n", name);

+        rval = _request_firmware(firmware_p, name, device, uevent);

+        printk(KERN_ERR "FW: return %d\n", rval);

+        return rval;

 }
 /**

@@ -545,7 +549,9 @@

 	struct task_struct *task;

 	struct firmware_work *fw_work = kmalloc(sizeof (struct firmware_work),

 						GFP_ATOMIC);

-

+

+        printk(KERN_ERR "FW: requesting firmware (async) for %s\n", name);

+

 	if (!fw_work)

 		return -ENOMEM;

 	if (!try_module_get(module)) {

@@ -569,8 +575,12 @@

 		fw_work->cont(NULL, fw_work->context);

 		module_put(fw_work->module);

 		kfree(fw_work);

+                printk(KERN_ERR "FW: failing return %d\n", PTR_ERR(task));

 		return PTR_ERR(task);

 	}

+

+        printk(KERN_ERR "FW: normal return\n");

+

 	return 0;

 }
--

Romano Giannetti --- romano.giannetti@gmail.com

Sorry for the following disclaimer, it's attached by our otugoing server

and I cannot shut it up.
--

La presente comunicacisn tiene caracter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribucisn, reproduccisn o uso de esta comunicacisn y/o de la informacisn contenida en la misma...
[ message continues ]

use 'dmesg -s 100000' if it's just dmesg(8) that needs help.

If it's the kernel buffer filling up, you can rebuild the kernel

after changing CONFIG_LOG_BUF_SHIFT, but it's easier just to boot

using this:

	log_buf_len=n	Sets the size of the printk ring buffer, in bytes.

			Format: { n | nk | nM }

			n must be a power of two.  The default size

			is set in the kernel config file.
---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

I'm not ready to redesign udevd :-(.
Your other mail proves that either
1) we can stop freezing udevd, and pray udevd does not become confused

by "half hardware not available" while system is being suspended
_or_
2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
Imageine we killed freezer. Also imagine Romano has IDE card his

PCMCIA slot. Kaboom, we solved nothing. We'll either deadlock or do

something very nasty to the filesystem on the IDE card ... because

we'll have udevd running, but fs on IDE card not available.
That does not work. "Not freezing udevd" only makes problems hard to

trigger, see?
Now... "should we rip freezer out of suspend" is a different story. It

does not help _here_. We still need to load the firmware during

_suspend_.
[Can you ack this point and we can have nice flamewar about ripping

out freezer?]
But I'd actually like to get rid of freezer for suspend (I believe

it is needed for hibernation) -- we'll need to do similar that for

runtime suspending of devices, anyway. But "just rip it out" will

cause some hard to debug breakage, we need to somehow audit the

drivers, or ask driver writers to audit them or something. ... and

yes, ripping freezer out _will_ make drivers more complex. Your video

capture card will now have to deal with
"ouch, I was already told to suspend, and now someone is calling my

ioctls() ?!".
									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

And people aren't listening. Have you thought about _why_?
Don't be silly. We solved it. The firmware has to be loadable from

somewhere else, since otherwise his IDE card wouldn't have been accessible

in the first place! 
So all your arguments are just bogus crap.
			Linus

-

The shiny userspace firmware loading causes problems since it exists,

every second box has problems with it, in all sorts of situations. If

people are still sold to the idea of userspace firmware loading, why

don't we keep the data in the driver, instead of immediately

discarding it after the first upload? Not to waste a few hundred

kilobytes? That doesn't sound like a convincing deal, after all the

years people try to work around the issues it causes.
Kay

-

Agreed.
Rafael

-

Rather than most drivers being told to make this step, can this be added

to the firmware_class such that firmware objects are cached in RAM and

subsequent calls to request_firmware() don't have to query userspace.
This seems the least intrusive solution to this problem.
Thanks,
Michael-Luke

-

Who is going to keep track of the data hiding in the firmware_class? On

driver unbind, module unload, you want to release the data.
Kay
-

Agreed again. :-)
Greetings,

Rafael

-

But it does not work, and as you demonstrated, getting it to work w/o

preloading is awful lot of work. Feel free to send a patch. Unless you
Firmware loader is complex userspace process. That's not silly. It is

userland, and I'd hate to explain to its authors detailed rules. 
It could do 'find / -name "pcmcia-card-firmware"' for example. It

could do dbus message to tell gnome-graphical-crap to display window

to say that it is loading firmware. Maybe it also writes to syslog

when syslogd is available.
It is userland process, so it is allowed to do stupid stuff.
[If you do not agree, please try to write up

"Doc*/what-firmware-loader-must-do.txt" -- at that point you should

realize how ugly the solution you are suggesting is.]

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Hi Linus.
Let me see if I can help. I'll probably fail miserably, but I can only

try :)
First, let me agree with you that for the atomic copy itself, the

freezer is unnecessary. Disabling irqs and so on is enough to ensure the

atomic copy is atomic. I don't think any of us are arguing with you

there.
Where we see the problem is with what happens after the atomic copy is

made. The problem is that the atomic copy includes struct inodes, dnodes

and such like - an in memory representation of the state of mounted

filesystems. Imagine that, post atomic copy, we don't have the freezer.

Processes can then make on-disk changes to these mounted filesystems in

the time before we complete saving the image and powering down. If, at

resume time, we then restore the atomic copy, we have a mismatch between

what the in-memory data structures say and what the on-disk data says.

This leads to corruption.
How to avoid?
Well, there are only two options as far as I can see. We either stop

those changes occurring in the first place, or we make them undoable.
Freezing processes, and/or filesystems would be the first path,

checkpointing the second.
So, as far as I can see, we're stuck with freezing processes at least

until checkpointing is implemented.
I have to admit though, that even if checkpointing was implemented, I'd

like to see freezing processes remain. The image gets written faster if

we don't have to compete for cpu and i/o. It also allows us to do a

fuller image of memory than is otherwise possible (Yes, I know some

people don't care for full images, but others of us have usage patterns

that make the system far more useable if a full image is kept, or simply

prefer to have our machines as if the power had never gone away).

Without processes freezing, I'd have to work a lot harder to find a way

to do that full image. The simplest way would probably be to carry the

freezer code myself. (Yeah, I'm reconciled to the idea of never getting

Suspend2 merged. I'd like it to happen, but...
[ message continues ]

First off, realize that the problem actually happens during

suspend-to-ram.
Think about that for a second.
In fact, think about it for a _loong_ time. Because dammit, people seem to

have a really hard time even realizing this.
	There is no "atomic copy".
	There is no "checkpointing".
Hope _the_above_ helps. Why is it so hard for people to accept that

suspend-to-ram shouldn't break because of some IDIOTIC issues with disk

snapshots?
And why do you people _always_ keep mixing the two up?
			Linus

-

Hi Linus.
It does. Sorry. I didn't read enough of the context.
To answer the question, I guess the answer is that although they're

different creatures, they have similarities. This is one of them, which

is why I could make the mistake I did. Nothing in the issue being

discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus

too much on the similarities, but that doesn't mean they're not there.
Regards,
Nigel

I agree that the current bug is not unique to STR. In fact, I think Romano

tested both STD and STR, and both had the same bug with the 60s timeout.
But what irritates me is that STR really shouldn't have _had_ that bug at

all. The only reason STR had the same bug as STD was exactly the fact that

the two features are too closely inter-twined in the kernel. 
That irritates me hugely. We had a bug we should never had had! We had a

bug because people are sharing code that shouldn't be shared! We had a bug

because of code that makes no sense in the first place!
I agree that disk snapshotting is much harder. If we had a bug just in

that part, I wouldn't mind it so much. Getting hard problems wrong isn't

something you should be ashamed of. What I mind is that the _easier_

problem got infected by all the bugs from the _harder_ issue. That just

makes me really really angry and frustrated.
Look at it this way: if you designed a CPU, and you made the integer

code-path share everything with the floating point side, because "addition

is addition", and as a result the latency for the simple arithmetic and

logical ops in integer ALU was four cycles, what would you be?
You'd be a moron, that's what. 
And that is _exactly_ what the current STD/STR code does. It says "suspend

is suspend" and tries to share the same pipeline, even though the two

operations are totally different, and share nothing but the name people

use for it (and even the name is really pretty weak, and I've tried to

get people to use some other name for STD).
So yes,the two things _do_ share the problem, but they really really

shouldn't. There's no reason to think that they should. And it drives me

absolutely bonkers that people seem to have such a hard time seeing that.
That said, I think freezing is crap even for snapshotting/suspend-to-disk,

but the point of the above rant is to show how insane it is to think that

problems and complexity in one area should translate into problems and

comp...
[ message continues ]

And what do you expect? We have three people working on

hibernation, and suspend-to-ram was created as "oh, if we do this,
You'd be seriously overstaffed in FPU side, and seriously understaffed

on ALU side.
This is basically what happened here. I tell people to get hibernation

to work _first_ because it is usually easier.
And what does that mean? We need three people to work on

suspend-to-RAM. Heck, we need at least _one_ person to work on

suspend-to-RAM, but he needs to be listed in MAINTAINERS.
With hibernation people trying to maintain suspend in their spare

cycles, how do you expect suspend to work? Similar to hibernation,

that's how it looks today.

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Hi.
I think I get what you're trying to say, but I also think you're either

overstating your case ("...totally different and share nothing but the

name...") or underestimating the similiarity - they both need (albeit

for different reasons) to do the cpu hotplugging, driver suspending

(yeah, there are similarities and differences there) and irq disabling.

That's _some_ similarity. Apart from that, yeah - they are totally

different.
Re the name, we discussed changing the name of Suspend2 on IRC a night

or two ago. We came to the conclusion that, for better or for worse,

it's too well known now. I can see your logic in wanting to

differentiate them, but I seem to be a bit stuck :\. Push some more.

Maybe we'll get there anyway :) Maybe you can get rid of that horrible,
Does that imply that you'd prefer to see filesystem checkpointing code,

that you think freezing can be done better, or do you have some other
Fair enough :).
Nigel

I actually don't think that processes should be frozen really at all.
I agree that filesystems have to be frozen (and I think that checkpointing

of the filesystem or block device is "too clever"), but I just don't think

that has anything to do with freezing processes.
So I'd actually much prefer to freeze at the VFS (and socket layers, etc),

and make sure that anybody who tries to write or do something else that we

cannot do until resuming, will just be blocked (or perhaps just buffered)!
See? I actually think that this process-based thing is barking up the

wrong tree. After all, it's really not the case that we need to stop

processes, and stopping processes really does have some problems. It's

simpler in some ways, but I think a more directed solution would actually 
But I really don't care that deeply per se, exactly because I don't use it

myself. I think people are going down the wrong rabbit-hole, but it

wouldn't _irritate_ me that much except for the fact that it now also

impacts suspend-to-RAM.
			Linus

-

Howdy.
That does sound doable.
I'm sorry to say it, but dropping process freezing still seems to me

like the better way though. I prefer it because of the reliability

aspect. With the current code, having frozen processes, I can look at

the state of memory, calculate how much I'll need for this or that and

know that I'll have sufficient memory for the atomic copy and for doing

the I/O  (making assumptions about how much memory drivers will

allocate) before I start to do either. If we stop freezing processes,

that predictability will go away. There'll always be a possibility that

some process will get memory hungry and stop me from being able to get

the image on disk, and I'll have to either abort or give up and try

again and again until I can complete writing the image, the battery runs
Not sure who you're quoting here, but it's not me. Pavel maybe? I was
Does that mean you never ever power off your laptop (assuming you have

one), and the battery never runs out? Surely you must power it off

completely sometimes? If you do, doesn't that ever happen at a time when

you're part way through something and you'd like to be able to pick up

your merge or whatever later without having to say "Now, where was I up

to?" *shrug* Maybe you're just exceptional :) (Yeah, we know you are in

other ways, but this way?...)
Regards,
Nigel

How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to

the filesystem VFS callers?   Or is that starting to get messy again?
Cheers
-

Hi.
Yeah. Getting messy again :)
Nigel

Indeed. And also misses the point - the point being that we don't actually

need to freeze anything at all most of the time. There's nothing wrong

with making memory allocations etc.
And yes, suspend is different from hibernate. I can see how hibernate

people are worried about people writing to things after doing the

snapshot, but those concerns don't exist with suspend. With suspend, the

biggest concern is accessing a device after it has been suspended, but on

the other hand, also the fact that we end up having driver writers used

to the system being "runnable", so they do things that really do require a

full-fledged system (and sometimes that means just some delayed action

using a kernel thread, other times it seems to rely on more complex

behaviour like firmware loading :^p )
			Linus

-

Notice that we want to be able to suspend while hibernating -- for

suspend to both behaviour. So drivers may _not_ rely on system being

runnable.
(Suspend to both is: write image to disk, then suspend to RAM. If you

do not run out of battery, resume is from RAM and fast, if you do, you

still can do resume from disk, not loosing your data).

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
(Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond 
So keep the driver layers read-only and unfreeze the processes after

doing the atomic copy.
--

Matthew Garrett | mjg59@srcf.ucam.org

-

To read firmware you probably need to _write_ atimes.
Anyway, make-disks-read-only patch would be welcome. I just think it

is going to be more complex than freezer.
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

I know you probably won't care, but that's not an option for Suspend2 -

I get the possibility of a full image by overwriting LRU pages that were

saved prior to the atomic copy.
That aside, keeping the driver layers read-only sounds more complicated

than just freezing processes.
Regards,
Nigel

This generally is a problem, not only for suspend2. :-)
Once you've unfrozen the user land, we can't rely on the hibernation image any

more, because some tasks may cause the on-disk filesystems' state to change.
Greetings,

Rafael

-

Hi.
ge.
True. I understood, perhaps wrongly, that when Matthew spoke of keeping

the drivers layers read-only, he was meaning stopping filesystem changes

by some other means.
Regards,
Nigel

Hence "keep the driver layers read-only" :) 
--

Matthew Garrett | mjg59@srcf.ucam.org

-

It's a problem that effectively has to be solved for STR anyway if

we're going to suspend without freezing. The midlayers need to be able

to block requests when the low-level devices are suspended, so we can

just re-use that code.
--

Matthew Garrett | mjg59@srcf.ucam.org

-

Very true.  And I think the right order should be to make the midlayers do

this and then remove the freezer from the STR code path, not the other way
Yes, that should be possible.
Greetings,

Rafael

-

Yes. After all, STR simply shouldn't _care_.
The rule should be that in a well-written setup, STR "just works" whether

user processes are suspended or not. In other words, the whole freezing

part isn't about STR. It should be totally immaterial.
(Of course, that assumes that the freezing is _sane_, of course: ie the

core kernel threads shouldn't all be frozen. I think Rafael's patch to

turn the defaults around are a big step in the right direction).
			Linus

-

Hi.
Yeah, but they can't. Even after the freezing of processes has been

removed from the normal suspend to ram path, we're still going to have

this issue with the suspend to ram after writing a hibernation image

path.
Regards,
Nigel

So? The bootup isn't that much worse than a disk suspend/resume, and it's

reliable.
And actually, I don't use laptops much. I use mostly desktops, and STR

works fine on at least some of them. In contrast, doing some

suspend-to-disk thing would just be insane and idiotic. If I have to wait

for half a minute and have a slow system even after that because my git

trees aren't in the cache, I really might as well just shut them off.
In contrast, STR means they are quiet and don't waste energy when I don't

use them, but they're instantly available when I care. HUGE difference.
I really think suspend-to-disk is just a total waste of my time.
		Linus

-

I very much prefer suspend (to RAM) over hibernate (to DISK).

But once in a while, primarily when travelling, I'll use hibernate.
And the "swsusp" in the kernel is just plain crappy and slow,

which leads many people (including our beloved chief penguin, it seems)

into thinking that hibernate *has* to be too slow to be useful.
But with Suspend2, it is very quick and usable by comparism.

Try it, you'll like it (at least a little).
Cheers

-

Hi.
Ah. That's because you're using [u]swsusp. If you used Suspend2, your

git trees would be in the cache, your system wouldn't be slow and you'd

still be back up in that half a minute or so - probably less time. Give

it a try for a week, and then go back to rebooting. After that, tell me

rebooting is better and I've wasted the last 5 or 6 years improving the

code.
Regards,
Nigel

(Changing subject to something more informative. You are lost,

original thread is at http://lkml.org/lkml/2007/5/23/38 )
More data. I compiled 2.6.21.2 + the patch "Fix ACPI suspend / device

suspend ordering problem  (52ade9b3b97fd3bea42842a056fe0786c28d0555)
and I discovered that if I do not put the 3Com 3CXEM556B card into the

pcmcia slot, the suspend/resume (and the snapshot/restore) works ok,

without delay at all. It continues to work even with a cardbus wifi in

the slot, so my conclusions are that the probable culprit is restricted

to:
      *  a race when loading the .cis file from userspace

      * the serial_cs or 3c589_cs driver (only when the device is in;

        they are loaded still now and all is working ok)
...what now?

	Romano
--

Romano Giannetti --- romano.giannetti@gmail.com

Sorry for the following disclaimer, it's attached by our otugoing server

and I cannot shut it up.
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.
-

Ok. That was probably true even before you added the suspend ordering 
Can you compile those two modules with PCMCIA_DEBUG=4?
Something like
	make EXTRA_CFLAGS=-DPCMCIA_DEBUG=4
should do it. You might also enable CONFIG_PCMCIA_DEBUG while you're at

it. And then the extra debugging output hopefully will narrow down where

things go south.
		Linus

-

Oh, no it apparently wasn't. I missed your other email that said
   "So, I tried to suspend without any card in the pcmcia slot. Guess what?

    I extracted the card and the system did not suspend. Just stopped dead."
so apparently the patch actually did matter for you. Can you double-check

and confirm?
		Linus

-

Well, I've made a bit of a mess. The setup that has not the delay when

the card is out is a plain 2.6.21.2 (without suspend ordering). 
The lockup ocurred on a 2.6.21.1 WITH the suspend ordering patch, but

was just one time, after I plugged and unplugged the card several time.

Could not reproduce it, however. Puzzled.
Romano 
-

Ok, I'm pretty sure that the suspend ordering doesn't matter at all for

you.
Occasional lockups on resume is probably a separate issue, and it might

well be a race, or even just firmware timing bugs.
		Linus

-

Btw, to solve the 60-second timeout problem, do you actually _need_ to

have CONFIG_PCMCIA_LOAD_CIS enabled for those cards to work for you? Quite

likely that's the "firmware" that screws up for you, and it's also not

totally unlikely that you don't even need it.
			Linus

-

I could try to undefine it. As a fast try, I simply removed the .cis

file, and the card do not work (complains it can't find cis file). I do

not remember where, but I read that I need this file --- I think I found

it mentioned in the cardmgr->pccardctl conversion HOWTO. 
Romano 
-

Well, I have to give up for tonight... that make do not works (see the

problem explained in other messages, some part of the kernel fails to

compile for the redefined EXTRA_CFLAGS); I naively tried to do:
     make EXTRA_CFLAGS=-DPCMCIA_DEBUG=4 drivers/pcmcia/
(which worked)
and then
     make
(alone) but the second one recompiled the  drivers/pcmcia/ subdir, too.

Too tired to think right now (good excuse), so I will try to find a bit

of time tomorrow.
Another naive doubt I have is: in 2.6.17.13, with additional patches

http://zeus2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a...

http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.g...

http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.g...
(now in the mainline), it works. And it used the cis file too.
Romano
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.
-

It really would be nice of you to just "git bisect" this, to see where it

started having that 60-second delay..
		Linus

-

...and while at it, I decided to start by learning a bit more of git,

and installed the last version...
% git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

Initialized empty Git repository in /usr/src/git/linux-2.6/.git/

Cannot get remote repository information.

Perhaps git-update-server-info needs to be run there?
I cannot use git protocol from here (overfirewalling, you know...)
Romano
--

Romano Giannetti --- romano.giannetti@gmail.com

Sorry for the following disclaimer, it's attached by our otugoing server

and I cannot shut it up.
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.
-

Heh. If you are using http://, you should _not_ ask for "git.kernel.org".
So use
	git clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
instead. That should work (modulo mirroring issues - but mirroring has 
http:// will suck, but should work. It will be a bit frustrating, because

when it downloads the big packs, it will just say something like
	Getting pack 4f22c0234340c4f3470c04f912969fc59ae8babc

	 which contains ...
and then it will be quiet for a _loong_ time while it downloads that 164MB

pack..
And the real problem with http:// will come later, if you use git to keep

up-to-date with the kernel, and I end up repacking the archive (which I

usually do around major releases). Then it will end up fetching the newly

repacked data - even though most of it you already have.
Anyway, there's a reason why the "native" protocols are much preferred,

but the http:// one does work. It just requires www.kernel.org, not

git.kernel.org.
			Linus

-

Yep, it would be nice. I will try; but this has to wait a week or more,

end term is approaching and this is a busy period not only for student.

Meanwhile, I tried to compile with PCMCIA debug with nil result (it

seems that a good part of the kernel do not compile if you override

EXTRA_CFLAGS on the make command line). So I tried to define

PCMCIA_DEBUG=4 in the source(s) file affected, but no joy... then I

checked in a clean tree:
cd /linux-2.6.21.3/drivers/pcmcia

% grep PCMCIA_DEBUG *

Kconfig:config PCMCIA_DEBUG

m8xx_pcmcia.c:#ifdef PCMCIA_DEBUG

m8xx_pcmcia.c:static int pc_debug = PCMCIA_DEBUG;

Makefile:ifeq ($(CONFIG_PCMCIA_DEBUG),y)
...so it's seems that only the m8xx modules uses it, and the modules

that load the drivers for my card is yenta_socket... no idea on how to

enable debug.
Romano
--

Romano Giannetti --- romano.giannetti@gmail.com

Sorry for the following disclaimer, it's attached by our otugoing server

and I cannot shut it up.
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.
-

Compiling now. I had lost a lot of time because at first try it stopped

in ntfs:
  CC [M]  fs/ntfs/super.o

fs/ntfs/super.c: In function ‘init_ntfs_fs’:

fs/ntfs/super.c:3152: error: expected ‘)’ before ‘NTFS_VERSION’

fs/ntfs/super.c: At top level:

fs/ntfs/super.c:3262: error: expected ‘,’ or ‘;’ before ‘NTFS_VERSION’

make[2]: *** [fs/ntfs/super.o] Error 1

make[1]: *** [fs/ntfs] Error 2

make: *** [fs] Error 2
I suppose because NTFS_VERSION were defined as EXTRA_CFLAGS too in the Makefile,

and I corrected it adding a fake #define NTFS_VERSION in super.c. Then I

got to a meeting, and coming back:
  CC [M]  fs/xfs/quota/xfs_dquot.o

fs/xfs/quota/xfs_dquot.c:18:17: error: xfs.h: No such file or directory

fs/xfs/quota/xfs_dquot.c:19:20: error: xfs_fs.h: No such file or directory

fs/xfs/quota/xfs_dquot.c:20:21: error: xfs_bit.h: No such file or directory

fs/xfs/quota/xfs_dquot.c:21:21: error: xfs_log.h: No such file or directory
So I gave up and lost^Wused a couple of hours trimming  down .config, and

now it's compiling.
Romano
-

On Thu, 24 May 2007 22:14:08 +0200
ntfs is being naughty.
--- a/fs/ntfs/Makefile~a

+++ a/fs/ntfs/Makefile

@@ -6,7 +6,7 @@ ntfs-objs := aops.o attrib.o collate.o c

 	     index.o inode.o mft.o mst.o namei.o runlist.o super.o sysctl.o \

 	     unistr.o upcase.o
-EXTRA_CFLAGS = -DNTFS_VERSION=\"2.1.28\"

+EXTRA_CFLAGS += -DNTFS_VERSION=\"2.1.28\"
 ifeq ($(CONFIG_NTFS_DEBUG),y)

 EXTRA_CFLAGS += -DDEBUG

_
akpm:/usr/src/linux-2.6.22-rc2> grep -r EXTRA_CFLAGS . | fgrep '+=' | wc -l

131

akpm:/usr/src/linux-2.6.22-rc2> grep -r EXTRA_CFLAGS . | fgrep -v '+=' | wc -l

55
hm, lots of Makefiles commit the same sin.  Sam, is this as busted as

I think it is?

-

I really cannot see why it makes a difference.

If you use += (and :=) make will resolve EXTRA_CFLAGS when it see it.

Whereas with = make will resolve it only when actually referenced.
But the way we use EXTRA_CFLAGS it should not matter.

If the fix above really helps nfs I need to take a closer look tomorrow.
	Sam

-

On Thu, 24 May 2007 23:12:37 +0200
It's not a matter of when it's evaluated.  The user is supposed to be

able to set EXTRA_CFLAGS on the command-line, yes?  If they do that then

the "=" in there will rub out their efforts.  The makefiles should be

appending new things to EXTRA_CFLAGS, rather than doing a replacement?
-

There is no way to specify additional CFLAGS on the commandline today.

For sparse we took the shorthand CF so you can do:
make C=2 CF=-warn-bitwise
But we have no such thing for CFLAGS.

If there is a real need I can cook up something.

But frankly I have alway edited top-level Makefile and be doen with it.
I will fix it so Kbuild do not barf out if you set EXTRA_* on the commandline

but silently ignore it instead.
	Sam

-

No, you're right, it doesn't help. What could help is a form of saying

to make "add this EXTRA_CFLAGS  to whatever is specified in the command

line". No idea if it exists.
Romano
-

The GNU make manual says:
"To append more text to a variable defined on the command line, use:
     override VARIABLE += MORE TEXT

"
HTH,

Johannes

-

Hmmm... 
CC [M]  drivers/ide/pci/amd74xx.o

drivers/ide/pci/amd74xx.c:28:24: error: ide-timing.h: No such file or

directory

(etc etc)
... and in Makefile:
EXTRA_CFLAGS    := -Idrivers/ide
I changed it to 
EXTRA_CFLAGS    += -Idrivers/ide
but I have the same error. Puzzled (yes, again).
-

(changing email. My employer server adds a stupid and malformed

disclaimer, so that vger refuses the post. Oh well. I will no trim the

quot to my original message so that it's here for anyone).
I forgot to mention that I have Ingo cfs patch in. But I had the same

behaviour without, so I do not think it's related.
root@rukbat:/sys/power# dmesg | grep clock

[   19.600060] Time: tsc clocksource has been installed.

[   23.028323] Time: acpi_pm clocksource has been installed.
The "time do not advance was an error of my side... I was basing myself

on the timestamp on the syslog, but then realized that this has nothig

to do with the time at which te message is sent. 
Will try to reboot with clocksource=acpi_pm, althoughI think that this
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)

00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)

00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)

00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)

00:07.4 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)

00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)

00:07.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 30)

00:0a.0 CardBus bridge: Texas Instruments PCI1420

00:0a.1 CardBus bridge: Texas Instruments PCI1420

00:0e.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link)

00:10.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64)

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8180L 802.11b MAC (rev 20)
By the way, s...
[ message continues ]

On Wed, 23 May 2007 09:09:00 +0200
you can see that with:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
--

	Paolo Ornati

	Linux 2.6.22-rc2-gd2579053 on x86_64

-

Hmmm:
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource

acpi_pm 
So I am using it. 
Thanks
-