It is with great reluctance when I attempt moving my main "desktop"

over to a new kernel version -- because the USB subsystem seems to

break every single time.
So today I tried 2.6.25-rc7 on it for the first time.

Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it.

It comes back on resume, with an X desktop again,

but with no USB functionality -- no mouse.
The keyboard still works, so I dropped to a console and tried:
   rmmod usbhid

   insmod usbhid
And the console hung at 100% CPU on the insmod.

Back to 2.6.24.3 again, for now -- I've got work to do.
The specs of this machine have been posted with great regularity

in the past, every new kernel revision it seems.   So here we go again:
Dell Inspiron 9400 notebook, Intel Core2Duo T7400, 2GB SDRAM.
Suspend/Resume have worked perfectly (after kernel fixes, mostly USB)

for all kernels in the past since 2.6.20 or so.
Here's the /var/log/messages from the suspend/resume.

That's it for now.  I've got work to do, and I'm tired of

seeing this break with each new revision.
logger: /usr/local/bin/suspend.sh

kernel: [  107.491762] PM: Syncing filesystems ... done.

kernel: [  107.492274] Freezing user space processes ... (elapsed 0.00 seconds) done.

kernel: [  107.493016] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.

kernel: [  107.499129] ACPI: Preparing to enter system sleep state S3

kernel: [  107.499656] Suspending console(s)

kernel: [  107.524879] b44: eth0: powering down PHY

kernel: [  108.011326] sd 0:0:0:0: [sda] Synchronizing SCSI cache

kernel: [  108.011473] sd 0:0:0:0: [sda] Stopping disk

kernel: [  110.058446] pciehp_suspend ENTRY

last message repeated 2 times

kernel: [  110.058446] ricoh-mmc: Suspending.

kernel: [  110.058446] ricoh-mmc: Controller is now re-enabled.

kernel: [  110.058446] ACPI handle has no context!

kernel: [  110.058446] ACPI: PCI interrupt for device 0000:03:01.1 disabled

kernel: [  110.058446] ACPI handle has no context!

kernel: [ ...
[ message continues ]

..
Correction there:  3GB of RAM, not 2.
--

3GB of RAM can be a problem. Try iommu=soft. .. but in such case

rmmod/insmod of usbhid would not help...
If rmmod/insmod usbhid helps, and system is fully working after that,

then it is probably usb problem....
Is your problem fixed after latest RTC findings? If not, try to debug

insmod/rmmod of usb, first. If that does not work, it is unlikely

suspend/resume will.

									Pavel

--

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

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

pomozte zachranit klanovicky les:  http://www.ujezdskystrom.info/

--

..
Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.
-ml

--

Are you running with CONFIG_USB_SUSPEND? If so, please try without it.
	Regards

		Oliver

--

..
Funny.  One of the first posts in this thread told me to make sure

that I do use CONFIG_USB_SUSPEND (which I have been for many kernels now).
One thing I just tried, was to unload all USB stuff before suspend,

and reload on resume -- just stuck the commands into my suspend/resume script.
The machine has been 100% rock solid since then.

So I think that definitely implicates USB.
Still want USB_SUSPEND=n ?  Please explain.
Thanks

--

It looks like you are hanging in the kthread for autosuspending. Compiling

that out should confirm it.
	Regards

		Oliver
--

..
Mmm.. interesting choice, there.  I'll try that.
There is another quirk on this machine that might confuse

software that's not robust:  the internal Bluetooth adapter

is USB connected, and I normally have it disabled (BIOS hotkey).

So it normally is "not present".
But on any power-on / resume, it briefly powers up and becomes "present",

and, after a second or two, the BIOS powers it down again, "not present".
Just long enough for software to notice it and try talking to it.

If that software is not carefully coded, it might get confused.
..
Okay, and once we see that it works fine:  then what?

--

We'll combine that information with the result of only removing usbhid

and arrive at a pretty good idea where in the kernel the hang occurs.

There are only two functions that touch autosuspend in the usbhid code.

So if it works with usbhid unloaded, either of them should be to blame.
	Regards

		Oliver
--

..
Thanks!
It does still hang with *usbhid* unloaded,

but not if all USB stuff is unloaded.

I'm still working my way through the rest of the suggestions here,

and USB_DEBUG=n is next.
I have figured out a way to make this much more reproducible now:

When suspended, the notebook does not supply +5V over USB.

But with a voltmeter, I discovered that there is sufficient capacitance

on the USB +5V, that it takes many minutes for the voltage to decay

from 5.1V down to near 0V.
Resuming while the voltage is still relatively high, generally works.

Resuming after the voltage drops to near zero, always fails (with USB modules loaded).
So I've put a 2Kohm resistor across the USB +5V lines,

forcing it to decay to zero within about 5 seconds.

This helps a lot for debugging here.
It probably also provides a vital clue as to what is wrong.

Resume seems to generally work when the USB devices maintain

some amount of standby power, and always fails when they don't.
--

..
--

..
Note that it makes no difference whether I unplug all external USB devices

prior to suspend or not.  The failure patterns remain the same.

--

..
I've now removed the internal USB-Bluetooth adaptor, so we can now test

without any USB devices connected.
Suspend without any USB devices plugged-in, and it *always* resumes fine

with working USB, even when the USB stuff is plugged in before hitting

the resume button.
But suspend *with* any USB device plugged-in, and it *always* fails resume,

even when the USB device is unplugged before hitting the resume button.
Conclusion:   the bug is in the usb SUSPEND code, not the RESUME code.

--

To the USB subsystem these devices are plugged in as soon as power is
I would arrive at the opposite conclusion. Independent from that, loss of

power is not really supported by USB during STR. Obviously it should not

hang, but all devices will be disconnected and reconnected.
But if power is cut with newer kernels and older kernels retain it, something

must have changed. Can you undo the ACPI changes since the last working

kernel?
	Regards

		Oliver
--

All devices disconnected / reconnected is expected, but it has to

work. Machines like thinkpad x60 kill USB power during s2ram.
									Pavel

--

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

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

--

..
No, that's no different.

This notebook always cuts +5V from USB on suspend or poweroff.

Regardless of kernel version.  I don't know how common this is,

but all of my notebooks here have always behaved this way,

as have most (but not all) of the larger systems.
The two most recent PCIe motherboards I have here

do provide +5V standby power to USB, even when "OFF",

much to my annoyance and to the detriment of this planet.
Cheers

--

Very well.
Mark, can you get a sysrq-t trace of your whole system when USB goes

dead? And please enable CONFIG_USB_DEBUG. We need to do whether

khubd and ksuspend_usbd are in state D.
	Regards

		Oliver

--

(CCing Alan Stern on this sub-thread)
..
Both of those things were already done, and results from the last time

are attached to the bugzilla report: http://bugzilla.kernel.org/show_bug.cgi?id=10345
I'll be installing -rc8 today, and see what happens there.
Cheers

--

(CCing linux-usb again)

(CCing Alan Stern on this sub-thread)
..
Both of those things were already done, and results from the last time

are attached to the bugzilla report: http://bugzilla.kernel.org/show_bug.cgi?id=10345
I'll be installing -rc8 today, and see what happens there.
Cheers
--

Have you tried testing with all the USB drivers present except

ehci-hcd?  So far all the indicators are that it is the source of the

problem.
Also, check out the thread on LKML started by Tino Keitel.  He had

similar problems and found that reverting commit

e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.
Alan Stern
--

And try the change I suggested there:  taking the

HC_IS_RUNNING test out of ehci_iaa_watchdog().
--

..
Yup, that does indeed cure it.

Here's a patch, in case you didn't already generate one:
Signed-off-by: Mark Lord <mlord@pobox.com>
--- rc8/drivers/usb/host/ehci-hcd.c	2008-03-11 11:18:40.000000000 -0400

+++ linux/drivers/usb/host/ehci-hcd.c	2008-04-02 12:16:40.000000000 -0400

@@ -289,9 +289,7 @@

 	 * (a) SMP races against real IAA firing and retriggering, and

 	 * (b) clean HC shutdown, when IAA watchdog was pending.

 	 */

-	if (ehci->reclaim

-			&& !timer_pending(&ehci->iaa_watchdog)

-			&& HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {

+	if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {

 		u32 cmd, status;
 		/* If we get here, IAA is *REALLY* late.  It's barely

--

Given your immediately-preceding experience, I'll wait for a

bit more confirmation ... but this seems like a candidate to
--

Okay, I'm puzzled.  How could this make any difference?

ehci_bus_suspend() calls end_unlink_async() anyway, whenever reclaim is

set.
Is the real problem that it does so before calling ehci_work() instead

of after calling ehci_halt()?
Mark, if you want to experiment some more, try reverting your patch

above and moving:
	if (ehci->reclaim)

		end_unlink_async(ehci);
in ehci-hub.c:ehci_bus_suspend() to just after the line saying:
	hcd->state = HC_STATE_SUSPENDED;
Alan Stern
--

It's more like:  what else in that patch could have had

any such effect?  That HC_IS_RUNNING test was the only

candidate.
Those hcd->state tests have been getting more and more

dodgey as time goes by.  At this point I hardly trust

any of them.  There *IS* no clear state machine which

governs the usbcore/HCD interaction.
- Dave
--

ISTR trying to make that same point a few times over the past two or

three years...  :-)
It would make more sense for each HCD to keep its own private "state"

variable.  The interaction with usbcore can be broken down into a few

simple tests, such as:
	Is the HC dead?

	Is the HC (i.e., the PCI or platform device) suspended?

	Is the HC running?

	Is it okay to submit an URB?
There's plenty of redundancy in this list, and some of the information

may already be available in hcd->self.root_hub->state.  In many or most

cases, these questions can't be answered in a race-free manner anyhow,

which limits their usefulness.
Alan Stern
--

Was there any argument about that fact?  The question was

more "shouldn't there actually *be* such a state machine"
At any given instant, all of them have valid answers.

The only one that's not resolvable by mutual exclusion

on the HCD's spinlock is "is it dead", since the HC

could crap out at any time.  (Nowadays that's fortunately

rare ... we've been whomping on such bugs for long enough

by now!)
- Dave
--

..
Here's what I did, and yes, this also works.  Pick one.
This patch, suggested by Alan Stern, fixes the hung USB issues

on my notebook from suspend/resume cycles.
Signed-off-by: Mark Lord <mlord@pobox.com>
--- rc8/drivers/usb/host/ehci-hub.c	2008-03-11 11:18:40.000000000 -0400

+++ linux/drivers/usb/host/ehci-hub.c	2008-04-02 13:28:50.000000000 -0400

@@ -135,8 +135,6 @@

 		hcd->state = HC_STATE_QUIESCING;

 	}

 	ehci->command = ehci_readl(ehci, &ehci->regs->command);

-	if (ehci->reclaim)

-		end_unlink_async(ehci);

 	ehci_work(ehci);
 	/* Unlike other USB host controller types, EHCI doesn't have

@@ -180,6 +178,9 @@

 	ehci_halt (ehci);

 	hcd->state = HC_STATE_SUSPENDED;
+	if (ehci->reclaim)

+		end_unlink_async(ehci);

+

 	/* allow remote wakeup */

 	mask = INTR_MASK;

 	if (!device_may_wakeup(&hcd->self.root_hub->dev))

--

..
Either patch is stable here, and have survived reboots and suspend/resumes,

with and without the 2.2Kohm resistor to drain residual USB voltage.
Which one should Andrew/Linus take?
-ml

--

It's up to David, of course.  My preference is for the patch I

proposed, naturally enough.  It fixes the cause rather than the

symptom.
Alan Stern
--

I'm not sure I'd agree with that.
--

Really?  The logic seemed clear enough to me.
     1. Evidently the ehci_iaa_watchdog routine was getting called at a

	time when the host controller wasn't running -- which had to

	have been after it was suspended.
     2. But ehci_bus_suspend() calls end_unlink_async(), which turns

	off the IAA watchdog timer.
     3. Hence the timer must have been restarted later on while

	ehci_bus_suspend() was still running.  The call to ehci_work()

	appeared to be the only place that could have happened.
     4. Thus moving the end_unlink_async() call to after ehci_work()

	(or just to be doubly safe, after ehci_halt() and the change

	to HC_STATE_SUSPENDED) should take care of all pending QH

	unlinks and leave none of them unfinished.
Strictly speaking, it would be best to move the del_timer_sync() calls

to after ehci_lock is released.  But it doesn't really matter if the

timer routines get invoked after the controller is suspended.
Alan Stern
--

The change to remove the HC_IS_RUNNING test meant that routine

would then work when hcd->state is HC_STATE_SUSPENDED or possibly

HC_STATE_RESUMING.  (Since those are the two states for which

HC_IS_RUNNING fails, other than HC_STATE_HALTED which shouldn't

be happening here...)
Now, prior to the now-merged patch that was skipping some work,

and that seemed to cause resume problems.  Making it not skip
Not exactly.  First, ehci_bus_suspend() force the timer off all

by itself ... way too early, while things can still retrigger it.

That's a buggy idiom that should be fixed.  (As you've agreed,

elsewhere.)
Second, it doesn't always call end_unlink_async() ... only when

one or more async unlink is still pending.
Third, if it *does* call end_unlink_async(), it can retriger

the timer when it needs to do another unlink.  Only when the

HC is halted (HC_STATE_HALT) is that logic bypassed, scrubbing

several endpoints at once.  (And a minor fourth point, direct

calls to end_unlink_async leaves the IAA IRQ machinery active.)
I think your fix handles the "one pending unlink" case, but
Removing the state check in the watchdog changed behavior, so the

HC must have been in one of the two states I listed above when

that watchdog fired (SUSPENDED or RESUMING).  And it had work to
It takes care of *ONE* pending QH unlink.  If there's more than
When the timer would be retriggered, to finish additional unlinks,

it does matter.  A complete fix for this would (a) disable the IAA

watchdog timer later, once it can never be retriggered again, and

(b) make end_unlink_async handle the multiple-unlinks case when the

HC is suspended, including not retriggering the watchdog.
--

Sounds right.  That test at the end of start_unlink_async() should be

changed to !RUNNING instead of HALT.
To help prevent unwanted recursion, I wrote a patch some time ago that

would batch up multiple unlinks.  (The idea was to keep track of which

entries were added to the reclaim queue before the current IAA cycle

got started, and handle them all at one stroke when the current cycle

ends.)  That patch is a bit out-of-date now, but it shouldn't be too
Agreed.  If the code does (a) after (b) then end_unlink_async doesn't

need to avoid retriggering the watchdog.
Alan Stern
--

..
Will do, thanks.  And there's a similar one in ehci_work().  ??

--

Don't see why that should matter.  In any case, that

test hasn't changed recently.
--

This patch seems to fix it.

Could you guys look this over some more,

as I really am not familiar with the USB code.
* * * *
When comparing 2.6.24 against 2.6.25, this line of code

stood out as not looking entirely correct, given the new

uses of QH_STATE_UNLINK_WAIT in 2.6.25.
Applying this patch seems to fix the USB suspend/resume deaths

on my machine here.  More testing is needed to be sure.
Signed-off-by: Mark Lord <mlord@pobox.com>
--- linux-2.6.25-rc8/drivers/usb/host/ehci-hcd.c	2008-03-11 11:18:40.000000000 -0400

+++ linux/drivers/usb/host/ehci-hcd.c	2008-04-02 11:36:13.000000000 -0400

@@ -815,7 +815,7 @@

 		end_unlink_async(ehci);
 	/* if it's not linked then there's nothing to do */

-	if (qh->qh_state != QH_STATE_LINKED)

+	if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT)

 		;
 	/* defer till later if busy */

--

To answer your implied question...
QH_STATE_UNLINK_WAIT doesn't have a new meaning in 2.6.25.  Just as

before, it means that qh is on a queue waiting to be unlinked.
qh->qh_state can never be equal to QH_STATE_UNLINK_WAIT at this point.

If it were, it would mean that some part of the driver had tried to

unlink qh twice.  But even then, the correct move would be to follow

the "nothing to do" path -- since qh is already waiting to be unlinked,

there's no point trying to do any more.
Alan Stern
--

Here it is again, with more lines of context, for easier review:
* * *
When comparing 2.6.24 against 2.6.25, this line of code

stood out as not looking entirely correct, given the new

uses of QH_STATE_UNLINK_WAIT in 2.6.25.
Applying this patch seems to fix the USB suspend/resume deaths

on my machine here.  More testing is needed to be sure.
Signed-off-by: Mark Lord <mlord@pobox.com>

---
Regenerated with more context in diff, for easier review.
--- linux/drivers/usb/host/ehci-hcd.c.orig	2008-03-11 11:18:40.000000000 -0400

+++ linux/drivers/usb/host/ehci-hcd.c	2008-04-02 11:36:13.000000000 -0400

@@ -801,35 +801,35 @@

 		return intr_submit(ehci, urb, &qtd_list, mem_flags);
 	case PIPE_ISOCHRONOUS:

 		if (urb->dev->speed == USB_SPEED_HIGH)

 			return itd_submit (ehci, urb, mem_flags);

 		else

 			return sitd_submit (ehci, urb, mem_flags);

 	}

 }
 static void unlink_async (struct ehci_hcd *ehci, struct ehci_qh *qh)

 {

 	/* failfast */

 	if (!HC_IS_RUNNING(ehci_to_hcd(ehci)->state) && ehci->reclaim)

 		end_unlink_async(ehci);
 	/* if it's not linked then there's nothing to do */

-	if (qh->qh_state != QH_STATE_LINKED)

+	if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT)

 		;
 	/* defer till later if busy */

 	else if (ehci->reclaim) {

 		struct ehci_qh		*last;
 		for (last = ehci->reclaim;

 				last->reclaim;

 				last = last->reclaim)

 			continue;

 		qh->qh_state = QH_STATE_UNLINK_WAIT;

 		last->reclaim = qh;
 	/* start IAA cycle */

 	} else

 		start_unlink_async (ehci, qh);

 }

--

..
Nope.  Nevermind.
Just got lucky once, without the resistor installed on USB power.
The patch doesn't fix it.  But that code still looks strange to me.
Cheers

--

..
No change in -rc8.  I've uploaded new syslog (with alt-sysrq-T) and .config

as attachements to the bugzilla entry:
    http://bugzilla.kernel.org/show_bug.cgi?id=10345
--

Same analysis. ehci_endpoint_disable() is spinning and ksuspend_usb

is waiting for it.
	Regards

		Oliver
PS: Sorry for not looking at the full bugzilla entry
--

..
--

..
Speaking of which.. what's with this "broken" message?

I wonder if it could be at all related ?
kobject: 'hci_usb' (f89d2948): kobject_cleanup

kobject: 'hci_usb' (f89d2948): does not have a release() function, it is broken and must be fixed.

kobject: 'hci_usb' (f89d2948): auto cleanup 'remove' event

kobject: 'hci_usb' (f89d2948): kobject_uevent_env

kobject: 'hci_usb' (f89d2948): fill_kobj_path: path = '/module/hci_usb'

kobject: 'hci_usb' (f89d2948): auto cleanup kobject_del

kobject: 'hci_usb': free name
--

..
And booting with iommu=soft is worse:  video comes back with bizarre timings

after suspend/resume -- totally unsynced display afterwards.
Cheers

--

Mark, could you try to boot with "acpi_new_pts_ordering" and retest?
Perhaps the problem is caused by the suspend ordering being wrong.
Thanks,

Rafael

--

..
Thanks for the suggestion.  It made no difference.
I do have this in the syslog from either boot method:
proc_dir_entry 'rtc' already registered

Pid: 1, comm: swapper Not tainted 2.6.25-rc7 #2

 [proc_register+185/295] proc_register+0xb9/0x127

 [create_proc_entry+109/128] create_proc_entry+0x6d/0x80

 [rtc_proc_add_device+26/53] rtc_proc_add_device+0x1a/0x35

 [rtc_device_register+328/443] rtc_device_register+0x148/0x1bb

 [cmos_do_probe+197/661] cmos_do_probe+0xc5/0x295

 [pnp_device_probe+99/129] pnp_device_probe+0x63/0x81

 [driver_probe_device+182/296] driver_probe_device+0xb6/0x128

 [__driver_attach+0/121] __driver_attach+0x0/0x79

 [__driver_attach+70/121] __driver_attach+0x46/0x79

 [bus_for_each_dev+55/89] bus_for_each_dev+0x37/0x59

 [driver_attach+17/19] driver_attach+0x11/0x13

 [__driver_attach+0/121] __driver_attach+0x0/0x79

 [bus_add_driver+138/424] bus_add_driver+0x8a/0x1a8

 [driver_register+69/153] driver_register+0x45/0x99

 [kernel_init+307/621] kernel_init+0x133/0x26d

 [schedule_tail+23/68] schedule_tail+0x17/0x44

 [ret_from_fork+6/28] ret_from_fork+0x6/0x1c

 [kernel_init+0/621] kernel_init+0x0/0x26d

 [kernel_init+0/621] kernel_init+0x0/0x26d

 [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10

 =======================

rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0

rtc0: alarms up to one month, y3k
Some kind of .config conflict, I suppose -- though how it has survived

this far into 2.6.25-rc* makes one wonder.
Meanwhile, I've been trying to rebuild a kernel with debug options

enabled, but so far none of them will come back from suspend,

just a black screen, no alt-sysrq, 5-seconds on the power button

required to escape.
The last attempt had only these differences from the original problem

kernel.  The original at least resumes, this one doesn't.

I'm rebuilding now without the PM debug flags set.
--- dot_config.nousb	2008-03-27 22:43:50.000000000 -0400

+++ dot_config.nothing	2008-03-27 22:47:32.000000000 -0400

@@ -1,7 +1,7 @@

 #

 # Auto...
[ message continues ]

That's not good, why not tell the linux-usb developers this?  (added to
This looks like your usb device should be up and working.
--

..
Okay, correction there:  it just hangs the console, but not 100% CPU.

Other tasks still continue running.
Same thing happens when I rmmod usbhid, and then rmmod ehci_hcd.

The rmmod ehci_hcd hangs.
But since the rest of the system is still alive, including the non-USB touchpad(!),

here is the alt-sysrq-t from syslog:
rmmod         D f74c2ddc     0  4538   4492

       f6d3b200 00000086 f74c2c90 f74c2ddc c281e840 00000001 c01131be 00000000

       00000001 c0324a00 c0324a00 00000000 00000001 7fffffff 7fffffff f653cea8

       00000002 c02906f8 00000000 00000012 c038f6aa 00000086 c011aa05 00000000

Call Trace:

 [__wake_up_common+46/88] __wake_up_common+0x2e/0x58

 [schedule_timeout+19/134] schedule_timeout+0x13/0x86

 [wake_up_klogd+43/45] wake_up_klogd+0x2b/0x2d

 [wait_for_common+205/308] wait_for_common+0xcd/0x134

 [default_wake_function+0/8] default_wake_function+0x0/0x8

 [__cancel_work_timer+237/312] __cancel_work_timer+0xed/0x138

 [wq_barrier_func+0/8] wq_barrier_func+0x0/0x8

 [<f889f684>] usb_remove_hcd+0x63/0xd7 [usbcore]

 [<f88a858e>] usb_hcd_pci_remove+0x15/0x68 [usbcore]

 [pci_device_remove+22/53] pci_device_remove+0x16/0x35

 [__device_release_driver+88/118] __device_release_driver+0x58/0x76

 [driver_detach+122/182] driver_detach+0x7a/0xb6

 [bus_remove_driver+96/126] bus_remove_driver+0x60/0x7e

 [pci_unregister_driver+30/95] pci_unregister_driver+0x1e/0x5f

 [sys_delete_module+388/445] sys_delete_module+0x184/0x1bd

 [remove_vma+49/54] remove_vma+0x31/0x36

 [do_page_fault+506/1232] do_page_fault+0x1fa/0x4d0

 [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85

 =======================
If nothing else, this should point to where USB is getting deadlocked.
??

--

rmmod is hanging up in a call to cancel_work_sync(), which means the

real problem is in the workqueue.  It's quite understandable that you

wouldn't want to go any further into debugging this, but in case you

don't mind, the workqueue task is ksuspend_usbd.
On the other hand, I don't understand how problems with the RTC

configuration could cause this sort of result.
Alan Stern
--

..
Yeah, me neither.   It's not clear whether simply changing the kernel

config made a race condition "go away" for now, or whether it really

fixed things for real.
My system is working with the current config, that's all I know right now.

Gotta fix VMware modules again, but that's de-rigour with new kernels.
Cheers
--

..
Oh, I also had a hung "lsusb" in another window at the same time:
lsusb         D f74c187c     0  4491   4397

       f6d3bc80 00000082 f74c1730 f74c187c c2816840 00000000 c26cb440 f666bab8

       00000003 c014b132 00000000 00000000 00000000 f75c1114 00000246 f75c111c

       f74c1730 c0291678 00000001 f74c1730 c01156bc f75c1120 f77e5f78 f75c1000

Call Trace:

 [handle_mm_fault+1205/1222] handle_mm_fault+0x4b5/0x4c6

 [__down+194/212] __down+0xc2/0xd4

 [default_wake_function+0/8] default_wake_function+0x0/0x8

 [__down_failed+7/12] __down_failed+0x7/0xc

 [<f88a70a0>] usbdev_ioctl+0x42/0x1132 [usbcore]

 [dput+22/197] dput+0x16/0xc5

 [__link_path_walk+2664/2969] __link_path_walk+0xa68/0xb99

 [mntput_no_expire+17/92] mntput_no_expire+0x11/0x5c

 [path_walk+144/152] path_walk+0x90/0x98

 [klist_del+24/59] klist_del+0x18/0x3b

 [klist_iter_exit+15/24] klist_iter_exit+0xf/0x18

 [bus_find_device+87/97] bus_find_device+0x57/0x61

 [kobject_get+15/19] kobject_get+0xf/0x13

 [get_device+14/20] get_device+0xe/0x14

 [<f889c29e>] usb_get_dev+0xf/0x13 [usbcore]

 [<f88a6d9c>] usbdev_open+0x13c/0x144 [usbcore]

 [chrdev_open+312/373] chrdev_open+0x138/0x175

 [open_namei+582/1357] open_namei+0x246/0x54d

 [chrdev_open+0/373] chrdev_open+0x0/0x175

 [__dentry_open+263/404] __dentry_open+0x107/0x194

 [nameidata_to_filp+28/44] nameidata_to_filp+0x1c/0x2c

 [do_filp_open+43/49] do_filp_open+0x2b/0x31

 [vfs_ioctl+71/93] vfs_ioctl+0x47/0x5d

 [do_vfs_ioctl+555/574] do_vfs_ioctl+0x22b/0x23e

 [sys_ioctl+44/69] sys_ioctl+0x2c/0x45

 [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85

 [schedule+53/1498] schedule+0x35/0x5da

 =======================

--

>Do you have CONFIG_USB_SUSPEND enabled in your .config?
Yes.

I'm puzzled by this one, but really too busy to fix it myself this time around.

I will fix it myself if necessary, eventually, just not for a few weeks

while I catch up on some deadlines.
Cheers
#

# Automatically generated make config: don't edit

# Linux kernel version: 2.6.25-rc7

# Thu Mar 27 10:54:45 2008

#

# CONFIG_64BIT is not set

CONFIG_X86_32=y

# CONFIG_X86_64 is not set

CONFIG_X86=y

# CONFIG_GENERIC_LOCKBREAK is not set

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_HAVE_LATENCYTOP_SUPPORT=y

CONFIG_SEMAPHORE_SLEEPERS=y

CONFIG_FAST_CMPXCHG_LOCAL=y

CONFIG_MMU=y

CONFIG_ZONE_DMA=y

CONFIG_GENERIC_ISA_DMA=y

CONFIG_GENERIC_IOMAP=y

CONFIG_GENERIC_BUG=y

CONFIG_GENERIC_HWEIGHT=y

# CONFIG_GENERIC_GPIO is not set

CONFIG_ARCH_MAY_HAVE_PC_FDC=y

CONFIG_DMI=y

# CONFIG_RWSEM_GENERIC_SPINLOCK is not set

CONFIG_RWSEM_XCHGADD_ALGORITHM=y

# CONFIG_ARCH_HAS_ILOG2_U32 is not set

# CONFIG_ARCH_HAS_ILOG2_U64 is not set

CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y

CONFIG_GENERIC_CALIBRATE_DELAY=y

# CONFIG_GENERIC_TIME_VSYSCALL is not set

CONFIG_ARCH_HAS_CPU_RELAX=y

# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set

CONFIG_ARCH_HIBERNATION_POSSIBLE=y

CONFIG_ARCH_SUSPEND_POSSIBLE=y

# CONFIG_ZONE_DMA32 is not set

CONFIG_ARCH_POPULATES_NODE_MAP=y

# CONFIG_AUDIT_ARCH is not set

CONFIG_ARCH_SUPPORTS_AOUT=y

CONFIG_GENERIC_HARDIRQS=y

CONFIG_GENERIC_IRQ_PROBE=y

CONFIG_GENERIC_PENDING_IRQ=y

CONFIG_X86_SMP=y

CONFIG_X86_32_SMP=y

CONFIG_X86_HT=y

CONFIG_X86_BIOS_REBOOT=y

CONFIG_X86_TRAMPOLINE=y

CONFIG_KTIME_SCALAR=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_...
[ message continues ]

No, haven't heard anything similar either. Mark, are you able to collect

the stacktraces via alt-sysrq-t at the time the system goes crazy?
Also, as you seem to be able to easily reproduce the bug, git-bisect might

reveal the culprit easily. For start, you can try to bisect only let's say 
Hmm, what device is this?
--

Jiri Kosina

SUSE Labs

--

..
No where practical to capture them to.

I don't know if the machine was entirely dead,

..
I don't have the XX days necessary for git-bisect right now.

But if there were some likely candidates, I could probably try a couple.

Mostly I just wanted to give a heads-up that all is not well with 2.6.25

for now, and I'll get round to debugging it when I have time to do so.
I haven't yet tried -rc7 on my *other* dissimilar notebook,

but back at -rc2 it also had serious issues with suspend/resume not working.

This is my first look at 2.6.25 (on notebooks) since then.
..
Wireless PCIe card on internal slot -- Intel 3945ABG.
--

From: Mark Lord <lkml@rtr.ca>
I wish people would say stuff like this.
It takes 20 to 40 minutes, tops, to do this.
The bulk of it can run in the background while you perform other

tasks.

--

..
I just did, thanks.
In this case, a bisect would be a complete waste of time,

because whatever is wrong seems to be a timing-related race

condition of some kind.
Merely rebuilding the kernel with slightly different debug flags

affects things, so trying to bisect it would be a super waste of

time in all probability.
When I rebuilt with all debug stuff on, the kernel was worse than

before, and just gave the "black screen of nothing" on resume,

with a hung system.
At least before the system didn't hang.
Now I've just booted with a differently configured kernel,

with only about half of the debug flags turned on.

This one resumes from suspend, and *with* working USB too.
Ugh. Gotta love it when the bug is so subtle that turning on

the debug flags makes it (1) get worse, and/or (2) get cured.
Here's the abbreviated diff between broken (no USB on resume, no hang),

and working (good USB, no hang) .config files.
--- dot_config.nousb	2008-03-27 22:43:50.000000000 -0400

+++ dot_config.works	2008-03-28 01:29:22.000000000 -0400

-CONFIG_LOG_BUF_SHIFT=16

+CONFIG_LOG_BUF_SHIFT=17

-# CONFIG_KALLSYMS_ALL is not set

+CONFIG_KALLSYMS_ALL=y

-# CONFIG_MAC80211_DEBUGFS is not set

-# CONFIG_RTC is not set

-CONFIG_GEN_RTC=y

-CONFIG_GEN_RTC_X=y

+CONFIG_RTC=y

+CONFIG_SND_RTCTIMER=m

+CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y

-CONFIG_RTC_LIB=y

-CONFIG_RTC_CLASS=y

-

-#

-# Conflicting RTC option has been selected, check GEN_RTC and RTC

-#

-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=y

-CONFIG_RTC_INTF_DEV=y

-# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set

-CONFIG_RTC_DRV_TEST=m

-

-#

-# I2C RTC drivers

-#

-CONFIG_RTC_DRV_DS1307=m

-CONFIG_RTC_DRV_DS1374=m

-CONFIG_RTC_DRV_DS1672=m

-CONFIG_RTC_DRV_MAX6900=m

-CONFIG_RTC_DRV_RS5C372=m

-CONFIG_RTC_DRV_ISL1208=m

-CONFIG_RTC_DRV_X1205=m

-CONFIG_RTC_DRV_PCF8563=m

-CONFIG_RTC_DRV_PCF8583=m

-# CONFIG_RTC_DRV_M41T80 is not s...
[ message continues ]

Mmm.. also had the RTC conflict resolved in that one.

Time to try another kernel with just the RTC change now.

--

..
Okay, that might be it.  I've booted and am running without debug flags again.

The difference between "bad" .config and "good" .config was this (below).
Could somebody please fix the RTC mess in kconfig now ?
--- dot_config.nousb	2008-03-27 22:43:50.000000000 -0400

+++ dot_config.best	2008-03-28 01:50:40.000000000 -0400

-# CONFIG_RTC is not set

-CONFIG_GEN_RTC=y

-CONFIG_GEN_RTC_X=y

+CONFIG_RTC=y

+CONFIG_SND_RTCTIMER=m

+CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y

-CONFIG_RTC_LIB=y

-CONFIG_RTC_CLASS=y

-

-#

-# Conflicting RTC option has been selected, check GEN_RTC and RTC

-#

-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=y

-CONFIG_RTC_INTF_DEV=y

-# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set

-CONFIG_RTC_DRV_TEST=m

-

-#

-# I2C RTC drivers

-#

-CONFIG_RTC_DRV_DS1307=m

-CONFIG_RTC_DRV_DS1374=m

-CONFIG_RTC_DRV_DS1672=m

-CONFIG_RTC_DRV_MAX6900=m

-CONFIG_RTC_DRV_RS5C372=m

-CONFIG_RTC_DRV_ISL1208=m

-CONFIG_RTC_DRV_X1205=m

-CONFIG_RTC_DRV_PCF8563=m

-CONFIG_RTC_DRV_PCF8583=m

-# CONFIG_RTC_DRV_M41T80 is not set

-# CONFIG_RTC_DRV_S35390A is not set

-

-#

-# SPI RTC drivers

-#

-

-#

-# Platform RTC drivers

-#

-CONFIG_RTC_DRV_CMOS=y

-CONFIG_RTC_DRV_DS1511=m

-CONFIG_RTC_DRV_DS1553=m

-CONFIG_RTC_DRV_DS1742=m

-# CONFIG_RTC_DRV_STK17TA8 is not set

-CONFIG_RTC_DRV_M48T86=m

-# CONFIG_RTC_DRV_M48T59 is not set

-CONFIG_RTC_DRV_V3020=m

-

-#

-# on-CPU RTC drivers

-#

+# CONFIG_RTC_CLASS is not set

--

..
An update:  still mostly stable now.

But I have seen one resume failure on this machine since then,

and that's not "normal" -- suspend/resume are normally rock solid.
My other pure Intel Dell X1 notebook has also hung a couple

of time during startup -- usually with "switched to high resolution"

messages near-last on the the screen.  There's a long standing bug

to do with that stuff, which I first reported back in 2.6.20 (or .21).

Back then, it was kernel .config dependent, and has never been tracked down.
Maybe the same thing here, maybe not.
Cheers

--

My version has been sitting in MM for a while now.

I'll forward it to you off-list, in case you want

to verify that it resolves that specific issue.
It would have prevented your broken initial config,

which statically linked both the new framework plus

some incompatible legacy stuff.
- Dave

--

could you please provide an URL or the patch itself so that others who

hit this issue and read this thread can apply the fix?
	Ingo

--

I merged the two patches (gentle, then harsh) so the result is

smaller.  Here you go.
- dave
========== CUT HERE

Prevent the most significant RTC configuration problems:
 - If the new RTC framework is enabled, don't allow any of the

   legacy drivers to be configured.
 - When using generic RTC on x86, enable rtc-cmos by default.
It seems too many people are used to enabling a legacy RTC despite

the Kconfig help/comments; the gentle approach hasn't worked.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

---

 drivers/char/Kconfig |    8 ++++++++

 drivers/rtc/Kconfig  |    5 +----

 2 files changed, 9 insertions(+), 4 deletions(-)
--- linux-2.6.orig/drivers/char/Kconfig	2008-03-28 02:35:58.000000000 -0700

+++ linux-2.6/drivers/char/Kconfig	2008-03-28 02:39:17.000000000 -0700

@@ -704,6 +704,12 @@ config NVRAM

 	  To compile this driver as a module, choose M here: the

 	  module will be called nvram.
+#

+# These legacy RTC drivers just cause too many conflicts with the generic

+# RTC framework ... let's not even try to coexist any more.

+#

+if RTC_LIB=n

+

 config RTC

 	tristate "Enhanced Real Time Clock Support"

 	depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV && !ARM && !SUPERH && !S390

@@ -812,6 +818,8 @@ config DS1302

 	  will get access to the real time clock (or hardware clock) built

 	  into your computer.
+endif # RTC_LIB

+

 config COBALT_LCD

 	bool "Support for Cobalt LCD"

 	depends on MIPS_COBALT

--- linux-2.6.orig/drivers/rtc/Kconfig	2008-03-28 02:35:58.000000000 -0700

+++ linux-2.6/drivers/rtc/Kconfig	2008-03-28 02:39:12.000000000 -0700

@@ -20,10 +20,6 @@ menuconfig RTC_CLASS
 if RTC_CLASS
-if GEN_RTC || RTC

-comment "Conflicting RTC option has been selected, check GEN_RTC and RTC"

-endif

-

 config RTC_HCTOSYS

 	bool "Set system time from RTC on startup and resume"

 	depends on RTC_CLASS = y

@@ -303,6 +299,7 @@ comment "Platform R...
[ message continues ]

I do not see why it should default to y, given that udev loads my m

perfectly fine.

--

Then there's no problem with having it default to "y".
The usual case is to have a driver disabled by default, and when it's

that common that we do not want it disabled by default we can as well

immediately let it default to "y".
The user still has all three choices.
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

...
Thanks, David.  Could you perhaps also update the option descriptions

to clearly indicate which set of RTCs are the new ones, and which are

the old ones that are going away someday?
I didn't find it at all obvious, and I still don't know which set my

configured kernel is actually using.
Thanks

--

[ CC's trimmed a bit ]
Hmm, I thought that would be clear from context.

"These" (drivers/char) legacy RTC drivers (old),

vs generic RTC framework (toplevel driver Kconfig).
Admittedly the *previous* Kconfig was troublesome,

at the UI level (vs. those comments outside the GUI).
A more general issue seems to be what to do with

those legacy RTC drivers.  Few of them seem to

have maintainers.  I don't want to own them, and

I doubt Alessandro does either.  If their Kconfig

is going to change, I'd rather just see them all

flagged as deprecated ... with plans to delete them.
The RTCs in question being:
  "RTC" ... replaced by new "rtc-cmos"

	--> ready to deprecate now ?
  "JS_RTC" ... a SPARC32 thing

	--> bug?? no "js-rtc.c" in the tree!  patch sent
  "SGI_DS1286" ...

	--> needs conversion to new framework
  "SGI_IP27_RTC" ...

	--> needs conversion to new framework
  "GEN_RTC", "GEN_RTC_X" ... I never really saw the point

	--> who uses this?
  "EFI_RTC" ... IA64 only

	--> needs conversion to new framework
  "DS1302" ... M32R-specific, "rtc-ds1302" should replace it

	--> ready to deprecate now?
Plus there are various chunks of RTC code elsewhere in the tree,

mostly in arch subdirectories, which should be phased out but
If you enable the new framework, that's what it's

using; there should be no other options visible.

(At least, none that are even as loosely organized

as the drivers/char stuff.)
Else ... it's clearly not enabled!  So it's some

other (legacy) RTC driver.  I don't see the issue.
- Dave
--

Where's the bug?
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

In which case, just enable rtc.c ... a "egrep -r 'JS_RTC|js-rtc'"
Right, I looked at that a bit more.  The rtc-ds1302 code was

not written portably.   If it were updated to get addresses

from platform resources -- like *normal* platform drivers do,

since the addresses are platform specific -- and if those two

M32R platforms got updated ... *then* this could be deprecated.
- Dave
--

cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

Right:  it doesn't mention JS_RTC at all.  Whatever is up

with that stuff, it's broken.
--

You miss the point, the point is:

  drivers/sbus/char/Makefile:obj-$(CONFIG_SUN_MOSTEK_RTC) += rtc.o
Two modules with the same name in one build are not allowed.
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

It gets uglier and uglier.  So if that abortion is really

needed, it'd make more sense to rename the MOSTEK code.

If that's not fixed, its Kconfig should mention needing

the JS_RTC thing instead of the "real" legacy rtc.c ...
Glad I got rid of my JavaStation ages ago, but I liked

the idea of having a real builtin coffee cup holder.  :)
You see why nobody wants to touch the legacy RTC stuff?

Some of it is broken *BY DESIGN* instead of just by

pure happenstance of evolution.
- Dave

--

On Fri, 28 Mar 2008 15:18:35 -0700
 And we did not even touched the 11 minutes ntp update mode :)
-- 
 Best regards,
 Alessandro Zummo,

  Tower Technologies - Torino, Italy
  http://www.towertech.it
--

The Mostek code does not need drivers/char/rtc.c
I'm not sure, but the JavaStation might actually be one of these unusual 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

Gentleness is not the point. The Kconfig help/comments where just

not clear at all.
FWIW, it's still confusing to have an option "Enhanced Real Time

Clock Support" under "Character Devices", then later an option

"Real Time Clock" one level higher, none of the two in any way

acknowledging the existence of the other one, and only after

naively selecting both, you are told that there is some sort of

conflict. Couldn't this be made more explicit, such as:

- mentioning in both options' help text that the other one

   shouldn't be selected at the same time (if that's true)

- noting explicitly which of the two RTC options is the "legacy"

   one (is it RTC_CLASS?)

- enhancing the conflict message, which reads, in git-current:

        *** Conflicting RTC option has been selected, check GEN_RTC

        *** RTC interfaces ***

   Perhaps it's only me, but I do not know what to make of this.
HTH

T.
--=20

Tilman Schmidt                    E-Mail: tilman@imap.cc

Bonn, Germany

Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.

Unge=F6ffnet mindestens haltbar bis: (siehe R=FCckseite)

You mean "still, after applying that patch I sent"?  I don't
I think that'd be more confusing, since it's not possible.

Telling people not to do something will usually make them
That term isn't visible through the Kconfig user interfaces,

so I'm not sure why it should be introduced except as part

of a strategy to get rid of all those old drivers.  Which is
Me either, since the patch I sent removed that message.

I'm now quite sure you did *NOT* apply and try that patch

before responding to it.
- Dave

--

No, I was referring to the situation still existing in current mainline.

My comment was intended to be in support of your patches. Sorry for not

having made myself clear.
Regards,

Tilman

..
Exactly the issue.  Mod++++++++++++++++++++++
--

Very-Much-Acked-by: Ingo Molnar <mingo@elte.hu>
it's not just about being gentle: it's that there are thousands of

.config options that are confusing to most users, so our defaults and

rules must make sense. If we think that an approach is superior (which

your new RTC code certainly is), we have to take up the responsibility

of pushing that as a prominent, default choice and excluding the old

code. That ends up benefiting everyone, reduces complexity of the

kernel. You wont see anyone shed tears for the old code.
	Ingo

--

Users with audio-related usage patterns do, as SND_RTCTIMER

still depends on old rtc :-/

--

-ENOPATCH :)
Last time this specific issue came up, a related point was

that the relevant ALSA documentation in this area needed

updating too.  ISTR it assumed there was only one kind of

RTC, and had a few other issues.
- Dave
--

...as I got bitten by this, too.
--

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

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

pomozte zachranit klanovicky les:  http://www.ujezdskystrom.info/

--

Heh, my 3GHz P4 takes 20 minutes to build one kernel.
	-Mike
--

I don't understand this claim.  On what incredibly fast piece of iron

can you possibly do between 8 and 16 kernel builds (the range I've

encountered when I do the "git bisect" dance), boot each one, and

evaluate the results in so small a period of time?  An Alpha kernel

build takes me between 5 and 10 minutes for minor changes, closer to

four *hours* for a "from scratch" (make clean) build.  Even worse: for

those of us who don't have access to the console of the test machine

continuously (e.g., the machine is at home and you normally work outside

the home), the whole bisection process can take several days to complete.
Yes, Mark's problem is with a laptop, and maybe he's allowed to take

it with him into his workplace, but still...
If your claim is 20 to 40 minutes "per iteration", I could believe that.
--

------------------------------------------------------------------------

Bob Tracy          |  "I was a beta tester for dirt.  They never did

rct@frus.com       |   get all the bugs out." - Steve McGrew on /.

------------------------------------------------------------------------

--

From: rct@frus.com (Bob Tracy)
Builds are just over a minute on my box.  I can do a full

kernel build plus reboot cycle in under 2 minutes.

--

Most of us got over "mine is bigger than yours" bragging at about age

13. He said "laptop," that means slow builds, slow installs, slow boots,

and unless he's on a fat net pipe to a faster machine, build elsewhere

isn't much of a saving.
--

Bill Davidsen <davidsen@tmr.com>

   "We have more to fear from the bungling of the incompetent than from

the machinations of the wicked."  - from Slashdot
--

I've gotta get me some of that :-).
--

------------------------------------------------------------------------

Bob Tracy          |  "I was a beta tester for dirt.  They never did

rct@frus.com       |   get all the bugs out." - Steve McGrew on /.

------------------------------------------------------------------------

--

...
Well, lucky you.
I have a box almost that quick here, too.

Except it's not the one with the problem.
My main email/work machine is the one with the problem,

and the downtime is not affordable -- ie. it costs *me* personally money.
Cheers

--

not that it's relavent to the problem that you are troubleshooting (based

on later messages), but I will point out that there is nothing wrong with

useing a fast box to compile kernels for slower boxes.
David Lang

--