On 8/20/24 16:31, Linus Torvalds wrote:
> On Tue, 20 Aug 2024 at 14:17, Rob Landley wrote:
>>
>> Hexagon also has &&vdso_page which I don't understand (but have a toolchain
>> for
>> somewhere to at least smoketest...)
>
> The '&&&#x
On 8/20/24 10:31, Linus Torvalds wrote:
> On Mon, 19 Aug 2024 at 23:26, Michael Ellerman wrote:
>>
>> Linus Torvalds writes:
>> > +static struct vm_special_mapping vdso_mapping = {
>> > + .name = "[vdso]",
>> > + .pages = syscall_pages;
>> ^
>>
On 1/19/23 16:11, Michael.Karcher wrote:
> Isn't this supposed to be caught by this check:
a, __same_type(a, NULL)
?
>>>
>>> Yeah, but gcc thinks it is smarter than us...
>>> Probably it drops the test, assuming UB cannot happen.
>> Hmm, sounds like a GGC bug to me t
On 4/29/22 16:43, Fabiano Rosas wrote:
> Rob Landley writes:
>> Then paste something longer than 16 characters at the eventual command prompt
>> once the kernel finishes booting.
>
> I suspect this is due to how the tty driver (n_tty.c) interacts with
> the console
On 4/28/22 00:41, Rob Landley wrote:
> On 4/27/22 10:27, Thomas Huth wrote:
>> On 26/04/2022 12.26, Rob Landley wrote:
>>> When I cut and paste 80-ish characters of text into the Linux serial
>>> console, it
>>> reads 16 characters and stops. W
On 4/27/22 10:27, Thomas Huth wrote:
> On 26/04/2022 12.26, Rob Landley wrote:
>> When I cut and paste 80-ish characters of text into the Linux serial
>> console, it
>> reads 16 characters and stops. When I hit space, it reads another 16
>> characters,
>> an
When I cut and paste 80-ish characters of text into the Linux serial console, it
reads 16 characters and stops. When I hit space, it reads another 16 characters,
and if I keep at it will eventually catch up without losing data. If I type,
every character shows up immediately.
(On other qemu target
On 1/14/20 5:06 AM, Hsin-Yi Wang wrote:
> This patch adds a config ARCH_OFFLINE_CPUS_ON_REBOOT, which would offline
> cpus in
> migrate_to_reboot_cpu(). If non reboot cpus are all offlined here, the loop
> for
> checking online cpus would be an empty loop. If architecture don't enable this
> conf
On 03/29/2018 10:27 AM, Russell King - ARM Linux wrote:
> On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
>> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
>>> LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
>>> what I can see, nothing selects it. Therefore,
On 03/28/2018 05:14 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>>
>>
>> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
>>> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>>>&g
On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> On 03/28/2018 10:26 AM, Shea Levy wrote:
>>> Now only those architectures that have custom initrd free requirements
>>> need to define free_initrd
On 03/28/2018 10:26 AM, Shea Levy wrote:
> Now only those architectures that have custom initrd free requirements
> need to define free_initrd_mem.
...
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> {
> free_initmem_default(-1);
>
On 03/23/2018 02:06 PM, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
>> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
Current implementation doesn't randomize address retur
I just added a ppc64 target to https://github.com/landley/mkroot which
means I built 4.14 with the attached miniconfig and ran it with the
attached qemu command line, and it works fine as is but if you remove
the transactional mem line from the config the kernel panics instead
of launching a shell
On 09/17/2017 08:51 AM, Henrique de Moraes Holschuh wrote:
> On Sat, 16 Sep 2017, Rob Landley wrote:
>> So, I added a workaround with a printk in hopes of embarassing them into
>> someday fixing it.
>
> Oh, it will be fixed in Debian alright.
Cool!
But part of the problem
On 09/14/2017 04:17 AM, Christophe LEROY wrote:
> Le 14/09/2017 à 01:51, Rob Landley a écrit :
>> From: Rob Landley
>>
>> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
>> /dev/console open after devtmpfs mount.
>>
>> Add workaround for Debian bug th
From: Rob Landley
Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
/dev/console open after devtmpfs mount.
Add workaround for Debian bug that was copied by Ubuntu.
Signed-off-by: Rob Landley
---
v2 discussion: http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html
drivers/base
On 05/25/2017 04:24 PM, Stephen Rothwell wrote:
> Hi Michael,
>
> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman
> wrote:
>>
>> It'll be:
>>
>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT")
>
> And Andrew has asked me to drop that patch from linux-next which will
>
On 03/04/2017 07:05 AM, Russell King - ARM Linux wrote:
> On Fri, Mar 03, 2017 at 01:27:10PM +0100, Jiri Slaby wrote:
>> diff --git a/kernel/futex.c b/kernel/futex.c
>> index b687cb22301c..c5ff9850952f 100644
>> --- a/kernel/futex.c
>> +++ b/kernel/futex.c
>> @@ -1457,6 +1457,42 @@ futex_wake(u32 _
On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote:
> kernel_read_file_from_path() can try to read a file from
> the system's filesystem. This is typically done for firmware
> for instance, which lives in /lib/firmware. One issue with
> this is that the kernel cannot know for sure when the real
> fina
On 10/07/14 11:59, David Daney wrote:
> On 10/07/2014 09:31 AM, Guenter Roeck wrote:
>> On Tue, Oct 07, 2014 at 11:21:11AM -0500, Rob Landley wrote:
>>> On 10/07/14 00:28, Guenter Roeck wrote:
>>>> Devicetree bindings are supposed to be operating system indepe
On 10/07/14 00:28, Guenter Roeck wrote:
> Devicetree bindings are supposed to be operating system independent
> and should thus not describe how a specific functionality is implemented
> in Linux.
So your argument is that linux/Documentation/devicetree/bindings should
not be specific to Linux. Mer
On Wed, Sep 10, 2014 at 3:18 PM, H. Peter Anvin wrote:
> On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
>>
>> I think the whole "removing Alpha EV5" support is basically bonkers. Just
>> use set_bit in the tty layer. Alpha will continue to work as well as it
>> always has done and you won't de
The powerpc systems I emulate under qemu use the "mac99" board
emulation, which routes the serial console through a PMAC_ZILOG serial
chip.
It got screwed up by Alan Cox's refactoring of the tty layer in 2.6.28:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078700.html
And the
gt; other channel. This may be a qemu bug ... or not, so let's be
> safe and avoid calling into the UART layer when that happens which
> woulc cause a crash.
>
> Signed-off-by: Benjamin Herrenschmidt
Acked-by: Rob Landley
Tested it, and it worked for me.
Thanks,
Rob
--
Latency is
On Sunday 10 January 2010 21:02:16 Benjamin Herrenschmidt wrote:
> On Sat, 2010-01-09 at 02:17 -0600, Rob Landley wrote:
> > On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote:
> > > > Ok, here's the fix. It's not the _right_ fix, but it Works For Me
On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote:
> > Ok, here's the fix. It's not the _right_ fix, but it Works For Me (tm)
> > and I'll leave it to you guys to figure out what this _means_:
>
> I've failed to reproduce so far on both a Wallstreet powerbook (similar
> generation
On Sunday 06 December 2009 19:10:48 Benjamin Herrenschmidt wrote:
> On Sun, 2009-12-06 at 01:01 -0600, Rob Landley wrote:
> > Trying again with a few likely-looking cc's from the MAINTAINERS file:
> >
> > Summary:
> >
> > The PMACZILOG serial driver la
On Sunday 06 December 2009 19:10:48 Benjamin Herrenschmidt wrote:
> On Sun, 2009-12-06 at 01:01 -0600, Rob Landley wrote:
> > Trying again with a few likely-looking cc's from the MAINTAINERS file:
> >
> > Summary:
> >
> > The PMACZILOG serial driver la
Trying again with a few likely-looking cc's from the MAINTAINERS file:
Summary:
The PMACZILOG serial driver last worked in 2.6.28. It was broken by commit
f751928e0ddf54ea4fe5546f35e99efc5b5d9938 by Alan Cox making bits of the tty
layer dynamically allocated. The PMACZILOG driver wasn't prop
My posts are showing up in the archive...
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/076727.html
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/077059.html
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078498.html
But no replies. Is there somebody spe
Last month I reported a serial console problem:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/076727.html
And bisected the problem to find the patch to revert that fixed it for me:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/077059.html
The bug still hasn't been
Last week I reported a bug:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-October/076727.html
I managed to drill past the unrelated breakage and bisect it back to the
relevant commit: It was introduced leading up to 2.6.29, by commit
f751928e0ddf54ea4fe5546f35e99efc5b5d9938 written by Ala
Has anybody gotten a serial console to work under current qemu (ala the 0.11.0
release)?
I've tried the 2.6.30 and 2.6.31.4 kernels, and in both cases both the
bootloader and the kernel's boot messages write to the serial console just
fine, but as soon as userspace tries to write to /dev/consol
On Tuesday 06 October 2009 23:49:04 Grant Likely wrote:
>
> However, I've completely devoted to this work for at least the next
> two months, so there are plenty more patches to follow. Once I've
> got all the common code merged between Microblaze, PowerPC and Sparc
> I'll be fix the endian proble
On Saturday 27 June 2009 21:33:09 Jeremy Kerr wrote:
> Hi Rob,
>
> > I bisected the problem in the linux kernel repository, and wound up
> > here:
> >
> > 60ee031940c1b09c137b617a8829e2f081961fe0 is first bad commit
> > commit 60ee031940c1b09c137b617a8829e2f081961fe0
> > Author: Jeremy Kerr
> > Da
On Thursday 18 October 2007 12:29:08 pm Grant Likely wrote:
> On 10/18/07, Milton Miller <[EMAIL PROTECTED]> wrote:
> > If we say only some boards or ports are special and need to build then
> > I would vote for shipping asm files. If we think we need to build any
> > random embedded platform with
On Wednesday 17 October 2007 3:28:41 pm Grant Likely wrote:
> > Including .dtbs in the kernel tree has a big practical problem:
> > they're binary, so can't be patch(1)ed, which makes updating them a
> > complete PITA.
I note that kconfig includes the lex/yacc output files (blah.c_shipped) so you
On Friday 28 September 2007 11:53:28 am Segher Boessenkool wrote:
> >> I'd be following this more closely if compiling a device tree didn't
> >> currently
> >> require an external utility (dtc or some such) that doesn't come with
> >> the
> >> Linux kernel. No other target platform I've built kern
On Sunday 23 September 2007 9:58:24 pm David Gibson wrote:
> On Fri, Sep 21, 2007 at 06:03:24PM -0500, Milton Miller wrote:
> > Some platforms have a boot agent that can create or modify properties in
> > the device-tree and load images into memory. Provide a helper to set
> > loader_info used by
On Saturday 22 September 2007 11:27:05 pm Paul Mackerras wrote:
> Rob Landley writes:
>
> Just to correct a few misconceptions:
> > 2) PowerPC uses a device tree supplied by the hardware to identify the
> > available hardware, even for stuff living on PCI busses which it co
On Saturday 22 September 2007 4:55:46 am Christoph Hellwig wrote:
> On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote:
> > Here is the second rev of patches to boot a arch powerpc kernel on
> > qemu with the prep architecture.
>
> So if this is supposed to be prep why do you need additi
42 matches
Mail list logo
