Le vendredi 30 mars 2007 à 23:49 +0200, Adrian Bunk a écrit :
> Subject: MacMini doesn't come out of suspend to ram (i386 clockevents)
> (CONFIG_HPET_TIMER)
> References : http://lkml.org/lkml/2007/3/21/374
> Submitter : Frédéric Riss <[EMAIL PROTECTED]&
Le lundi 26 mars 2007 à 11:14 +0200, Thomas Gleixner a écrit :
> On Mon, 2007-03-26 at 08:45 +0200, Frédéric RISS wrote:
> > Additional data point: I just tried with -rc5 and the issue is still
> > present. The config I used for this test defines neither NO_HZ nor
> > HIGH_RE
Le dimanche 25 mars 2007 à 23:34 +0200, Frédéric Riss a écrit :
> However, as I pointed out in the initial report, the MacMini doesn't
> come out of suspend to ram because a commit in another merged patchset
> broke it. I tracked it down to:
>
> commit e9e2cdb412412326c482
Le vendredi 23 mars 2007 à 19:50 +0100, Adrian Bunk a écrit :
> Subject: MacMini: doesn't come out of suspend to ram
> References : http://lkml.org/lkml/2007/3/21/374
> Submitter : Frédéric RISS <[EMAIL PROTECTED]>
> Tino Keitel <[EMAIL PROTECTED]
My MacMini (Intel Core Duo, EFI mode) doesn't come out of suspend to ram
with current git. This was working great with 2.6.20. A long bisection
phase[1] brought me to that old commit:
Commit c5a7156959e89b32260ad6072bbf5077bcdfbeee
Author: Bob Moore <[EMAIL PROTECTED]> 2007-02-02 17:48:19
Commit
On dim, 2007-03-04 at 17:28 +0100, Frédéric RISS wrote:
> When the system is hung, and I press on the power button, I get this
> backtrace (copied from the screen, netconsole won't allow to capture
> it):
>
> BUG: soft lockup detected on CPU#0!
> [] sof
Hi,
With recent git versions, my system won't resume from suspend to ram. At
resume time, the kernel hangs just after printing "Enabling non-boot
CPUs ...". This is on a Core Duo system (Mac Mini). Looking at the BUG,
it looks related to hrtimers.
When the system is hung, and I press on the power
Le lundi 12 février 2007 à 08:38 +0100, Andi Kleen a écrit :
> When calling into the EFI firmware, the parameters need to be passed on
> the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
> This patch is needed to allow the new Intel-based Macs to suspend to ram
> (efi.get_time
Le dimanche 04 février 2007 à 09:34 -0800, Linus Torvalds a écrit :
>
> On Sun, 4 Feb 2007, Frédéric Riss wrote:
> >
> > New patch:
>
> I didn't get how this would fix the ia64 issues? I thought ia64 needed
> the standard calling convention?
I think Andi sa
Le samedi 03 février 2007 à 11:51 +0100, Andi Kleen a écrit :
> > +
> > +typedef efilinkage efi_status_t efi_get_time_t (efi_time_t *tm,
> > + efi_time_cap_t *tc);
>
> I assume you have double checked it actually works? (i vaguely recall some
> issues with
Le samedi 03 février 2007 à 11:57 +0100, Frédéric Riss a écrit :
> Le samedi 03 février 2007 à 11:51 +0100, Andi Kleen a écrit :
> > > +
> > > +typedef efilinkage efi_status_t efi_get_time_t (efi_time_t *tm,
> > > + efi_time_cap
Le samedi 03 février 2007 à 11:51 +0100, Andi Kleen a écrit :
> > +
> > +typedef efilinkage efi_status_t efi_get_time_t (efi_time_t *tm,
> > + efi_time_cap_t *tc);
>
> I assume you have double checked it actually works? (i vaguely recall some
> issues with
Le samedi 03 février 2007 à 10:58 +0100, Andi Kleen a écrit :
> Define a efilinkage macro then that expands to nothing on ia64
>
> Probably asmlinkage would work already, syscall_linkage as used on ia64
> doesn't
> seem to affect function pointers.
And here it goes:
When calling into the EFI fi
Le samedi 03 février 2007 à 10:33 +0100, Andi Kleen a écrit :
> > /*
> > + * Wrap all the virtual calls in a way that forces the parameters on the
> > stack.
> > + */
> > +
> > +#define efi_call_virt(f, args...) \
> > + ((efi_##f##_t
> > __attribute__((regparm(0)))*)efi.systab->runtime->f)(a
Le vendredi 02 février 2007 à 17:55 -0800, Andrew Morton a écrit :
> - I have efi-x86-pass-firmware-call-parameters-on-the-stack.patch, but
> I'm not sure it's right and unless something really rapid happens, we'll
> ship with that bug unfixed.
Things I can say:
- Works for me :-)
- When you
Le mardi 30 janvier 2007 à 12:17 -0700, Bjorn Helgaas a écrit :
> On Tuesday 30 January 2007 12:01, Frédéric Riss wrote:
> > When calling into an EFI firmware, the parameters need to be passed on
> > the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
> >
Le mardi 30 janvier 2007 à 11:10 -0800, Andrew Morton a écrit :
> > This patch fixes the issue for x86, but the file is also used by IA64. I
> > would have used asmlinkage to force arguments on the stack, but it has a
> > special meaning on IA64, thus I used a raw regparm(0) GCC attribute.
> > This
When calling into an EFI firmware, the parameters need to be passed on
the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
This patch is needed to allow the new Intel-based Macs to suspend to ram
when run in EFI mode (efi.get_time is called during the suspend phase).
Signed-of
Le lundi 29 janvier 2007 à 23:57 +0100, Thomas Gleixner a écrit :
> On Mon, 2007-01-29 at 23:50 +0100, Frédéric Riss wrote:
> > > That's probably a userspace problem. Are you using DHCP ?
> >
> > Yep DHCP. Is that a known issue? I never had to reconfigure with older
Le lundi 29 janvier 2007 à 23:45 +0100, Thomas Gleixner a écrit :
> On Mon, 2007-01-29 at 23:38 +0100, Frédéric Riss wrote:
> > I see the same symptoms on my Intel Mac Mini, and reverting the commit
> > also allows the driver to seemingly resume correctly.
> >
> >
Le lundi 29 janvier 2007 à 23:23 +0100, Thomas Gleixner a écrit :
> On Mon, 2007-01-29 at 13:38 -0800, Stephen Hemminger wrote:
> > Sorry it was against the last patch I sent to Jeff for netdev.
> > Here is against 2.6.20-rc6
>
> Still the same problem. The only difference of this patch to the
> p
Le lundi 29 janvier 2007 à 23:10 +0100, Pavel Machek a écrit :
> > > Ok, I guess we'd like some testing here... so that in can be fixed in
> > > mainline...
> >
> > I can confirm that this patch is needed for my Intel Mac Mini to resume
> > correctly when used without BIOS emulation (EFI mode). He
Le mardi 23 janvier 2007 à 09:44 +, Pavel Machek a écrit :
> Hi!
>
> > > > Whitelist? Let me blacklist it all the way to Timbuktu instead!
> > >
> > > > I've been doing more testing, and X never managed to come back to
> > > > working
> > > > state without some of my couple intel-agp changes
23 matches
Mail list logo
