Am 14.04.2014 09:15, schrieb Ingo Molnar:
>>> Right, it is really that it is not possible to boot a mixed-mode kernel
>>> on its non-native firmware using the stub, since the stub itself can
>>> only be one way or the other.
>>
>> Yeah, my help text was a bit... unhelpful.
>>
>> CONFIG_EFI_MIXED
Am 14.04.2014 09:15, schrieb Ingo Molnar:
Right, it is really that it is not possible to boot a mixed-mode kernel
on its non-native firmware using the stub, since the stub itself can
only be one way or the other.
Yeah, my help text was a bit... unhelpful.
CONFIG_EFI_MIXED does not introduce
EFI stub support is only missing for a 64 bit kernel on 32-bit firmware,
on 64-bit kernels, EFI stub works as usual.
---
Matt, I don't know if this help was intentionally discouraging,
however, out of curiosity, I tested this with ovmf, and the
kernel boots fine on 64-bit firmware bit with EFI
EFI stub support is only missing for a 64 bit kernel on 32-bit firmware,
on 64-bit kernels, EFI stub works as usual.
---
Matt, I don't know if this help was intentionally discouraging,
however, out of curiosity, I tested this with ovmf, and the
kernel boots fine on 64-bit firmware bit with EFI
Am 09.04.2014 10:30, schrieb Thomas Bächler:
> Am 09.04.2014 10:25, schrieb Matt Fleming:
>> On Tue, 08 Apr, at 10:04:48PM, Thomas Bächler wrote:
>>>
>>> Hello again Matt,
>>>
>>> with linux.git master, I cannot reproduce the problem at all (with or
Am 09.04.2014 10:25, schrieb Matt Fleming:
> On Tue, 08 Apr, at 10:04:48PM, Thomas Bächler wrote:
>>
>> Hello again Matt,
>>
>> with linux.git master, I cannot reproduce the problem at all (with or
>> without your patch). In fact, all the 0x0 CRCs on symbols are go
Am 09.04.2014 10:25, schrieb Matt Fleming:
On Tue, 08 Apr, at 10:04:48PM, Thomas Bächler wrote:
Hello again Matt,
with linux.git master, I cannot reproduce the problem at all (with or
without your patch). In fact, all the 0x0 CRCs on symbols are gone, and
those were the symbols that were
Am 09.04.2014 10:30, schrieb Thomas Bächler:
Am 09.04.2014 10:25, schrieb Matt Fleming:
On Tue, 08 Apr, at 10:04:48PM, Thomas Bächler wrote:
Hello again Matt,
with linux.git master, I cannot reproduce the problem at all (with or
without your patch). In fact, all the 0x0 CRCs on symbols
Am 08.04.2014 20:57, schrieb Thomas Bächler:
>>>> Thomas, you mention you're running in a 32-bit vm earlier in this
>>>> thread. Any chance you're using ovmf because that would make it much
>>>> easier to track this down?
>>>>
>>>
>>
Am 08.04.2014 14:14, schrieb Matt Fleming:
> On Tue, 08 Apr, at 06:46:49AM, Tetsuo Handa wrote:
>> Fleming, Matt wrote:
>>> On 7 April 2014 21:42, Andi Kleen wrote:
This sounds like the UEFI boot corrupts some memory?
>>>
>>> Hmpf, yeah. I'll take a look in the morning.
>>>
>>> Thomas,
Am 08.04.2014 14:14, schrieb Matt Fleming:
On Tue, 08 Apr, at 06:46:49AM, Tetsuo Handa wrote:
Fleming, Matt wrote:
On 7 April 2014 21:42, Andi Kleen a...@linux.intel.com wrote:
This sounds like the UEFI boot corrupts some memory?
Hmpf, yeah. I'll take a look in the morning.
Thomas, you
Am 08.04.2014 20:57, schrieb Thomas Bächler:
Thomas, you mention you're running in a 32-bit vm earlier in this
thread. Any chance you're using ovmf because that would make it much
easier to track this down?
I'm not familiar with UEFI boot, but it could happen because what
I experienced
Am 07.04.2014 23:25, schrieb Fleming, Matt:
> On 7 April 2014 21:42, Andi Kleen wrote:
>>
>> This sounds like the UEFI boot corrupts some memory?
>
> Hmpf, yeah. I'll take a look in the morning.
>
> Thomas, you mention you're running in a 32-bit vm earlier in this
> thread. Any chance you're
Am 07.04.2014 19:46, schrieb Thomas Bächler:
> Am 07.04.2014 19:30, schrieb Andi Kleen:
>>>> Do you have a specific config?
>>>> Specific compiler version?
>>>
>>> Using gcc 4.8 from Arch Linux with the configuration at [1] and Linux 3.14.
>>
>
Am 07.04.2014 19:30, schrieb Andi Kleen:
>>> Do you have a specific config?
>>> Specific compiler version?
>>
>> Using gcc 4.8 from Arch Linux with the configuration at [1] and Linux 3.14.
>
> I tested this configuration (with gcc 4.8 on FC20/19) and it loads
> ext4 and all the other modules
Am 07.04.2014 19:30, schrieb Andi Kleen:
Do you have a specific config?
Specific compiler version?
Using gcc 4.8 from Arch Linux with the configuration at [1] and Linux 3.14.
I tested this configuration (with gcc 4.8 on FC20/19) and it loads
ext4 and all the other modules without any
Am 07.04.2014 19:46, schrieb Thomas Bächler:
Am 07.04.2014 19:30, schrieb Andi Kleen:
Do you have a specific config?
Specific compiler version?
Using gcc 4.8 from Arch Linux with the configuration at [1] and Linux 3.14.
I tested this configuration (with gcc 4.8 on FC20/19) and it loads
Am 07.04.2014 23:25, schrieb Fleming, Matt:
On 7 April 2014 21:42, Andi Kleen a...@linux.intel.com wrote:
This sounds like the UEFI boot corrupts some memory?
Hmpf, yeah. I'll take a look in the morning.
Thomas, you mention you're running in a 32-bit vm earlier in this
thread. Any chance
Am 05.04.2014 19:23, schrieb Tetsuo Handa:
> Thomas B臘hler wrote:
For convenience, here is a copy-and-paste of the full text:
>>>
>>> I did some experiments know and I can't find any 32bit modules
>>> that do not load with 32bit MODVERSIONS on or off with
>>> a current tree.
>>>
>>> Do you
Am 05.04.2014 03:13, schrieb Andi Kleen:
> On Tue, Apr 01, 2014 at 01:38:10AM +0200, Thomas Bächler wrote:
>> Am 01.04.2014 01:34, schrieb Andi Kleen:
>>>> This problem persists in v3.14, i.e. I still have to revert
>>>> 83460ec8dcac14142e7860a01fa59c267
Am 05.04.2014 03:13, schrieb Andi Kleen:
On Tue, Apr 01, 2014 at 01:38:10AM +0200, Thomas Bächler wrote:
Am 01.04.2014 01:34, schrieb Andi Kleen:
This problem persists in v3.14, i.e. I still have to revert
83460ec8dcac14142e7860a01fa59c267ac4657c in order to get a working
kernel on i686. I
Am 05.04.2014 19:23, schrieb Tetsuo Handa:
Thomas B臘hler wrote:
For convenience, here is a copy-and-paste of the full text:
I did some experiments know and I can't find any 32bit modules
that do not load with 32bit MODVERSIONS on or off with
a current tree.
Do you have a specific config?
are affected,
make sure that FSID is at least 1.
References: http://article.gmane.org/gmane.linux.kernel/1666905
References: http://permalink.gmane.org/gmane.linux.utilities.util-linux-ng/8557
Cc: 3.14
Signed-off-by: Thomas Bächler
---
fs/super.c | 5 -
1 file changed, 4 insertions(+), 1 deletion
are affected,
make sure that FSID is at least 1.
References: http://article.gmane.org/gmane.linux.kernel/1666905
References: http://permalink.gmane.org/gmane.linux.utilities.util-linux-ng/8557
Cc: 3.14
Signed-off-by: Thomas Bächler
---
fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Am 03.04.2014 19:57, schrieb Dave Reisner:
> Hi,
>
> [This is a repost of a G+ post at Tejun's request]
>
> With Linux 3.14, you might notice in /proc/self/mountinfo that your
> root's parent FSID is now 0, instead of the 1 that it's been for the
> last N years. Tejun wrote the change
Am 03.04.2014 19:57, schrieb Dave Reisner:
Hi,
[This is a repost of a G+ post at Tejun's request]
With Linux 3.14, you might notice in /proc/self/mountinfo that your
root's parent FSID is now 0, instead of the 1 that it's been for the
last N years. Tejun wrote the change
are affected,
make sure that FSID is at least 1.
References: http://article.gmane.org/gmane.linux.kernel/1666905
References: http://permalink.gmane.org/gmane.linux.utilities.util-linux-ng/8557
Cc: 3.14 sta...@vger.kernel.org
Signed-off-by: Thomas Bächler tho...@archlinux.org
---
fs/super.c | 2 +-
1 file
are affected,
make sure that FSID is at least 1.
References: http://article.gmane.org/gmane.linux.kernel/1666905
References: http://permalink.gmane.org/gmane.linux.utilities.util-linux-ng/8557
Cc: 3.14 sta...@vger.kernel.org
Signed-off-by: Thomas Bächler tho...@archlinux.org
---
fs/super.c | 5 -
1 file
Am 03.04.2014 00:39, schrieb Marcel Holtmann:
> Hi Thomas,
>
>> The culprit is USB autosuspend. When I explicitly disable it (echo 'on'
>>> power/control), the mouse works fine again. However, due to the
>> aforementioned commit, I need to do this manually after every boot and
>> every resume,
in. However, due to the
aforementioned commit, I need to do this manually after every boot and
every resume, because btusb keeps setting it back to 'auto'. I have
found no way of overriding this behaviour.
Any advice or help is appreciated.
Regards
Thomas Bächler
signature.asc
Description: Open
again. However, due to the
aforementioned commit, I need to do this manually after every boot and
every resume, because btusb keeps setting it back to 'auto'. I have
found no way of overriding this behaviour.
Any advice or help is appreciated.
Regards
Thomas Bächler
signature.asc
Description
Am 03.04.2014 00:39, schrieb Marcel Holtmann:
Hi Thomas,
The culprit is USB autosuspend. When I explicitly disable it (echo 'on'
power/control), the mouse works fine again. However, due to the
aforementioned commit, I need to do this manually after every boot and
every resume, because btusb
Am 01.04.2014 01:34, schrieb Andi Kleen:
>> This problem persists in v3.14, i.e. I still have to revert
>> 83460ec8dcac14142e7860a01fa59c267ac4657c in order to get a working
>> kernel on i686. I would really appreciate if someone would actually read
>> my original mail from about 3 months ago and
Am 26.01.2014 10:01, schrieb Thomas Bächler:
> Good morning,
>
> I am trying to build Linux 3.13 on i686 with CONFIG_MODVERSIONS enabled
> (for configuration, see [2]). Upon booting it in a VM, I discovered that
> I was unable to load several kernel modules, like ext4:
>
>
Am 26.01.2014 10:01, schrieb Thomas Bächler:
Good morning,
I am trying to build Linux 3.13 on i686 with CONFIG_MODVERSIONS enabled
(for configuration, see [2]). Upon booting it in a VM, I discovered that
I was unable to load several kernel modules, like ext4:
ext4: disagrees about version
Am 01.04.2014 01:34, schrieb Andi Kleen:
This problem persists in v3.14, i.e. I still have to revert
83460ec8dcac14142e7860a01fa59c267ac4657c in order to get a working
kernel on i686. I would really appreciate if someone would actually read
my original mail from about 3 months ago and write an
Am 05.03.2014 19:36, schrieb Marcel Holtmann:
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
>>>
>>> NAK. We allocated a static minor for this.
>>
>> Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
>> correct?
I am sorry Marcel, I only looked at the Linus tree,
Adding the devname:vhci alias and thus adding a static /dev/vhci device node
only works when assigning a fixed major/minor number. However, the code
currently uses a dynamically assigned minor number. It is therefore impossible
to create a static device and to autoload the module when accessing
Adding the devname:vhci alias and thus adding a static /dev/vhci device node
only works when assigning a fixed major/minor number. However, the code
currently uses a dynamically assigned minor number. It is therefore impossible
to create a static device and to autoload the module when accessing
Am 05.03.2014 19:36, schrieb Marcel Holtmann:
This reverts commit bfacbb9aec029b3200053d84c8cd5d7575f2d4a5.
NAK. We allocated a static minor for this.
Johan mentioned that. Commit b075dd40c95d11c2c8690f6c4d6232fc,
correct?
I am sorry Marcel, I only looked at the Linus tree, not at
Am 26.01.2014 15:22, schrieb Tetsuo Handa:
> Thomas B臘hler wrote:
>> This looks exactly like the problem experienced by Tetsuo Handa in [1].
>> However, for me, his solution, i.e. setting
>> CONFIG_PHYSICAL_ALIGN=0x100
>> instead of
>> CONFIG_PHYSICAL_ALIGN=0x10
>> doesn't help and the
Am 26.01.2014 15:22, schrieb Tetsuo Handa:
Thomas B臘hler wrote:
This looks exactly like the problem experienced by Tetsuo Handa in [1].
However, for me, his solution, i.e. setting
CONFIG_PHYSICAL_ALIGN=0x100
instead of
CONFIG_PHYSICAL_ALIGN=0x10
doesn't help and the symptoms stay
Good morning,
I am trying to build Linux 3.13 on i686 with CONFIG_MODVERSIONS enabled
(for configuration, see [2]). Upon booting it in a VM, I discovered that
I was unable to load several kernel modules, like ext4:
ext4: disagrees about version of symbol d_tmpfile
ext4: Unknown symbol d_tmpfile
Good morning,
I am trying to build Linux 3.13 on i686 with CONFIG_MODVERSIONS enabled
(for configuration, see [2]). Upon booting it in a VM, I discovered that
I was unable to load several kernel modules, like ext4:
ext4: disagrees about version of symbol d_tmpfile
ext4: Unknown symbol d_tmpfile
Am 23.08.2012 16:35, schrieb Feng Tang:
> 2012/8/23 Thomas Bächler :
>> This regards the following commit in the Linus tree:
>>
>> commit 887c8ec7219fc8eba78bb8f44a74c660934e9b98
>> Author: Aaron Sierra
>> Date: Fri Apr 20 14:14:11 2012 -0500
>>
>>
.
At this point, I believe that none of you are actually aware of the
problem and I write you to change that unfortunate situation.
Regards
Thomas Bächler
signature.asc
Description: OpenPGP digital signature
report.
At this point, I believe that none of you are actually aware of the
problem and I write you to change that unfortunate situation.
Regards
Thomas Bächler
signature.asc
Description: OpenPGP digital signature
Am 23.08.2012 16:35, schrieb Feng Tang:
2012/8/23 Thomas Bächler tho...@archlinux.org:
This regards the following commit in the Linus tree:
commit 887c8ec7219fc8eba78bb8f44a74c660934e9b98
Author: Aaron Sierra asie...@xes-inc.com
Date: Fri Apr 20 14:14:11 2012 -0500
watchdog: Convert
Rafael J. Wysocki schrieb:
>> Replying to myself again. Apparently, a fix for this bug was applied to
>> the linux-acpi tree independently of my bug report, see here:
>> http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4c41d3ad6544f1c9aec37c441af04f5d0ad3a731
>
> I'm
>>> http://bugzilla.kernel.org/show_bug.cgi?id=9299
>
> I just tested again (with 2.6.24-rc2-gecd744ee). If I only load the 'ac'
> kernel module and not the 'battery' kernel module, then the system boots
> fine. However, if I load the 'battery' module during boot or later, I
> still get the oops.
Thomas Bächler schrieb:
> Rafael J. Wysocki schrieb:
>> On Saturday, 3 November 2007 12:31, Thomas Bächler wrote:
>>> I am trying to boot 2.6.24-rc1-g74521c28 from the linux-2.6 git tree.
>>> During boot, I get a kernel oops when udevtrigger is running, thus most
Thomas Bächler schrieb:
Rafael J. Wysocki schrieb:
On Saturday, 3 November 2007 12:31, Thomas Bächler wrote:
I am trying to boot 2.6.24-rc1-g74521c28 from the linux-2.6 git tree.
During boot, I get a kernel oops when udevtrigger is running, thus most
devices are not created and the boot
http://bugzilla.kernel.org/show_bug.cgi?id=9299
I just tested again (with 2.6.24-rc2-gecd744ee). If I only load the 'ac'
kernel module and not the 'battery' kernel module, then the system boots
fine. However, if I load the 'battery' module during boot or later, I
still get the oops.
I am
Rafael J. Wysocki schrieb:
Replying to myself again. Apparently, a fix for this bug was applied to
the linux-acpi tree independently of my bug report, see here:
http://git.kernel.org/?p=linux/kernel/git/lenb/linux-acpi-2.6.git;a=commit;h=4c41d3ad6544f1c9aec37c441af04f5d0ad3a731
I'm having
Sam Ravnborg schrieb:
> I'm afraid some people do not realize a whit about what they do.
> So at least we could let kbuild warn about it.
> Something like this:
>
> $ export CFLAGS=-O3
> $ make AFLAGS=-fisk
> Makefile:540: "Appending $AFLAGS (-fisk) from command line to kernel defined
> $AFLAGS"
Sam Ravnborg schrieb:
I'm afraid some people do not realize a whit about what they do.
So at least we could let kbuild warn about it.
Something like this:
$ export CFLAGS=-O3
$ make AFLAGS=-fisk
Makefile:540: Appending $AFLAGS (-fisk) from command line to kernel defined
$AFLAGS
Rafael J. Wysocki schrieb:
> On Saturday, 3 November 2007 12:31, Thomas Bächler wrote:
>> I am trying to boot 2.6.24-rc1-g74521c28 from the linux-2.6 git tree.
>> During boot, I get a kernel oops when udevtrigger is running, thus most
>> devices are not create
Thomas Bächler schrieb:
>
> I just remembered, a friend of mine got it to compile with the exact
> same toolchain, but with a different configuration (which I don't have).
> He used a snapshot tarball from yesterday though, not the git tree.
>
I found the problem and elimi
Thomas Bächler schrieb:
I just remembered, a friend of mine got it to compile with the exact
same toolchain, but with a different configuration (which I don't have).
He used a snapshot tarball from yesterday though, not the git tree.
I found the problem and eliminated it. While this is my
Rafael J. Wysocki schrieb:
On Saturday, 3 November 2007 12:31, Thomas Bächler wrote:
I am trying to boot 2.6.24-rc1-g74521c28 from the linux-2.6 git tree.
During boot, I get a kernel oops when udevtrigger is running, thus most
devices are not created and the boot stalls.
Fortunately
Thomas Gleixner schrieb:
> On Tue, 30 Oct 2007, Thomas Bächler wrote:
>
>> Thomas Gleixner schrieb:
>>> Thomas,
>>>
>>> On Mon, 29 Oct 2007, Thomas Bächler wrote:
>>>> x86_64 fails to compile for me with this error:
>>>>
&g
Thomas Gleixner schrieb:
On Tue, 30 Oct 2007, Thomas Bächler wrote:
Thomas Gleixner schrieb:
Thomas,
On Mon, 29 Oct 2007, Thomas Bächler wrote:
x86_64 fails to compile for me with this error:
CC arch/x86/kernel/vsyscall_64.o
{standard input}: Assembler messages:
{standard input
Dave Airlie schrieb:
>> I'm sorry, I forgot to mention that: As I _thought_ it had worked with
>> rc6, I already found that commit. I reverted it and got a panic again
>> (no trace, as I was in X), so this one doesn't seem to cause the problem.
>>
>
> Okay I've spotted a potential bug that might
Dave Airlie schrieb:
> lets start with:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4a7b1d1d90d202a030688ab5b177c3c0f15ee3e
>
> and work from there..
I'm sorry, I forgot to mention that: As I _thought_ it had worked with
rc6, I already found that commit. I
I first discovered this problem when updating to 2.6.23 final on x86_64.
When I launched google earth, the kernel paniced. When I tried to
reproduce, it oopsed instead of panicing.
dri/drm seems to work generally, as I am running beryl without trouble,
so far I could only reproduce the problem
I first discovered this problem when updating to 2.6.23 final on x86_64.
When I launched google earth, the kernel paniced. When I tried to
reproduce, it oopsed instead of panicing.
dri/drm seems to work generally, as I am running beryl without trouble,
so far I could only reproduce the problem
Dave Airlie schrieb:
lets start with:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4a7b1d1d90d202a030688ab5b177c3c0f15ee3e
and work from there..
I'm sorry, I forgot to mention that: As I _thought_ it had worked with
rc6, I already found that commit. I
Dave Airlie schrieb:
I'm sorry, I forgot to mention that: As I _thought_ it had worked with
rc6, I already found that commit. I reverted it and got a panic again
(no trace, as I was in X), so this one doesn't seem to cause the problem.
Okay I've spotted a potential bug that might lay
Thierry Vignaud schrieb:
> disable link detection in your network config then (eg:
> MII_NOT_SUPPORTED=yes in ifcfg-XXX depending on the distro).
I don't have such an option in "my distro". What does it do and how
would it change the fact that TX is being disabled in the driver?
-
To unsubscribe
Thierry Vignaud schrieb:
disable link detection in your network config then (eg:
MII_NOT_SUPPORTED=yes in ifcfg-XXX depending on the distro).
I don't have such an option in my distro. What does it do and how
would it change the fact that TX is being disabled in the driver?
-
To unsubscribe
Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe:
support basic carrier detection) breaks networking on my Davicom DM9009.
ethtool always reports there is no link. tcpdump shows incoming packets,
but TX is disabled. Reverting the above patch fixes the problem.
-
To
Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe:
support basic carrier detection) breaks networking on my Davicom DM9009.
ethtool always reports there is no link. tcpdump shows incoming packets,
but TX is disabled. Reverting the above patch fixes the problem.
-
To
72 matches
Mail list logo
