Andi Kleen <[EMAIL PROTECTED]> writes:
> On Sunday 04 February 2007 18:34, Linus Torvalds wrote:
>>
>> 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?
>
> asmlinkage i
On Sunday 04 February 2007 18:34, Linus Torvalds wrote:
>
> 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?
asmlinkage is standard enough on ia64 as far as I can see.
It d
On Sun, 4 Feb 2007, Frédéric Riss wrote:
>
> I think Andi said that adding asmlinkage on the function pointers
> shouldn't harm ia64. If you prefer wrapper functions, one of the patches
> I sent ( http://lkml.org/lkml/2007/1/30/309 ) did that, but the casting
> it uses looks clumsy.
I'm more co
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 said that adding asmlinkage on the func
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?
My gut feel is that EFI should be handled exactly the same way that we
used to handle APM: never even make it look like it's callabl
>
> 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 is called during the suspend phase).
Thanks looks good.
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
"Adam Kropelin" <[EMAIL PROTECTED]> writes:
> Naive question... Can the pci layer (or e1000) detect that MSI is not enabled
> in
> the hardware and avoid using it in that case? With the number of MSI problems
> showing up it seems risky to assume it's usable on any given platform without
> some s
Eric W. Biederman wrote:
"Adam Kropelin" <[EMAIL PROTECTED]> writes:
Can I get the corresponding lspci -xxx output. I suspect the BIOS
did not program the hypertransport MSI mapping capabilities
correctly. All it has to do is set the enable but still,
occasionally BIOS writers miss the most am
"Adam Kropelin" <[EMAIL PROTECTED]> writes:
>> Can I get the corresponding lspci -xxx output. I suspect the BIOS
>> did not program the hypertransport MSI mapping capabilities correctly.
>> All it has to do is set the enable but still, occasionally BIOS
>> writers miss the most amazing things.
>
Eric W. Biederman wrote:
Auke Kok <[EMAIL PROTECTED]> writes:
maybe I've been unclear, but here's how e1000 detects link changes:
1) by checking every 2 seconds in the watchdog by reading PHY
registers 2) by receiving an interrupt from the NIC with the LSI bit
in the interrupt control register
Auke Kok <[EMAIL PROTECTED]> writes:
> that's explained by a driver change that did that. Since at initialization
> we're
> basically waiting for a link change to tell the stack that we're up, we
> decided
> to change the order to have the hardware fire an LSI interrupt to trigger a
> watchdog r
Adam Kropelin wrote:
Auke Kok wrote:
Adam Kropelin wrote:
I've never had this device work 100% with MSI on any kernel version
I've tested so far. But I'm not the original reporter of the
problem, and I believe for him it was a true regression where a
previous kernel wored correctly.
maybe I've
Auke Kok <[EMAIL PROTECTED]> writes:
> maybe I've been unclear, but here's how e1000 detects link changes:
>
> 1) by checking every 2 seconds in the watchdog by reading PHY registers
> 2) by receiving an interrupt from the NIC with the LSI bit in the interrupt
> control register
>
> if the link is
Auke Kok wrote:
Adam Kropelin wrote:
I've never had this device work 100% with MSI on any kernel version
I've tested so far. But I'm not the original reporter of the
problem, and I believe for him it was a true regression where a
previous kernel wored correctly.
maybe I've been unclear, but he
Adam Kropelin wrote:
> Eric W. Biederman wrote:
>> Auke Kok <[EMAIL PROTECTED]> writes:
>>> None of the MSI code in e1000 has changed significantly either. as
>>> far as I can see, the msi code in e1000 has not changed since
>>> 2.6.18. Nonetheless there's no way I can debug any of this without a
Eric W. Biederman wrote:
Auke Kok <[EMAIL PROTECTED]> writes:
None of the MSI code in e1000 has changed significantly either. as
far as I can see, the msi code in e1000 has not changed since
2.6.18. Nonetheless there's no way I can debug any of this without a
system.
[...]
Perhaps Adam can git-b
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_t *tc);
> >
> > I assume you
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
> +#ifdef CONFIG_X86_32
> +#define efilinkage asmlinkage
> +#else
> +#define efilinkage
> +#endif
No ifdefs, this should be somewhere in the headers for the EFI supporting
architectures
But I suspect you could actually get away with just using asmlinkage
(after reviewing the ia64 asmlinkage I th
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
On Saturday 03 February 2007 10:49, Frédéric Riss wrote:
> Was what I did in the initial patch:
> http://lkml.org/lkml/2007/1/30/258
>
> The issue is that the structure definition is used on multiple
> architectures (for now ia64 and i386) which might used different calling
> conventions.
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
> /*
> + * 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)(args)
> +
> +static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t
On Sat, 03 Feb 2007 10:19:51 +0100 Frédéric Riss <[EMAIL PROTECTED]> wrote:
> 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
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
Auke Kok <[EMAIL PROTECTED]> writes:
> Adrian Bunk wrote:
>> This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
>> that are not yet fixed in Linus' tree.
>>
>> If you find your name in the Cc header, you are either submitter of one
>> of the bugs, maintainer of an affectected
Adrian Bunk wrote:
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breaka
On Fri, 02 Feb 2007 21:03:48 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Fri, 2 Feb 2007 06:49:16 +0100
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> >> This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
> >> that are not yet fixed in Linus'
Andrew Morton wrote:
On Fri, 2 Feb 2007 06:49:16 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
There are still a few things hanging around.
I have these queued:
aio-fix-buggy-put_i
On Fri, 2 Feb 2007 06:49:16 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
> that are not yet fixed in Linus' tree.
There are still a few things hanging around.
I have these queued:
aio-fix-buggy-put_ioctx-call-in-aio_comp
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
On Fri, Feb 02, 2007 at 08:45:42AM +, Fabio Erculiani wrote:
> Adrian,
Hi Fabio,
> and this one?
> http://bugzilla.kernel.org/show_bug.cgi?id=7589
Not a regression in 2.6.20-rc compared to 2.6.19 - it's already in
broken in 2.6.19.
This bug should be fixed, but it's outside the scope o
Adrian,
and this one?
http://bugzilla.kernel.org/show_bug.cgi?id=7589
---
Fabio Erculiani
http://www.sabayonlinux.org
Sabayon Linux Founder
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
36 matches
Mail list logo
