On 9 Jan 2025, at 15:12, Diego Nieto Cid wrote:
>
> Hi,
>
> On Thu, Jan 09, 2025 at 11:51:27AM +0300, Sergey Bugaev wrote:
>>
>> "Implementer", "architecture", "variant", "part", "revision" come from
>> midr/revidr [0], and "features" are hwcap names. These are privileged
>> registers that only
On 22 Feb 2024, at 17:13, Svante Signell wrote:
> On Thu, 2024-02-22 at 17:43 +0100, Samuel Thibault wrote:
>> Svante Signell, le jeu. 22 févr. 2024 17:36:15 +0100, a ecrit:
>>> Changes:
>>> ...
>>> gcc-13 (13.2.0-14) experimental; urgency=medium
>>> * Pass -D_TIME_BITS=64 together with -D_FILE_O
On 30 Jan 2024, at 09:02, Samuel Thibault wrote:
>
> Jessica Clarke, le mar. 30 janv. 2024 02:32:07 +, a ecrit:
>> On 29 Jan 2024, at 10:20, Samuel Thibault wrote:
>>>
>>> Damien Zammit, le lun. 29 janv. 2024 10:07:30 +, a ecrit:
>>>> - lj
On 29 Jan 2024, at 10:20, Samuel Thibault wrote:
>
> Damien Zammit, le lun. 29 janv. 2024 10:07:30 +, a ecrit:
>> - ljmp $BOOT_CS, $M(0f)
>> + xorl %eax, %eax
>> + mov %cs, %ax
>> + shll $4, %eax
>> + addl $M(0f), %eax
>> + movl %eax, M(ljmp_offset32)
>
> This won't work with pipelined proce
On 25 Oct 2023, at 02:40, Jeffrey Walton wrote:
>
> On Tue, Oct 24, 2023 at 9:33 PM Jessica Clarke wrote:
>>
>> On 25 Oct 2023, at 02:26, Jeffrey Walton wrote:
>>>
>>> On Tue, Oct 24, 2023 at 6:21 PM Samuel Thibault
>>> wrote:
>>>&
On 25 Oct 2023, at 02:26, Jeffrey Walton wrote:
>
> On Tue, Oct 24, 2023 at 6:21 PM Samuel Thibault
> wrote:
>>
>> Some update on the 64bit port:
>>
>> - The debian-ports archive now has enough packages to bootstrap a
>> chroot.
>> - A 64bit debian buildd is getting set up, not much work is l
On 20 May 2023, at 19:52, jbra...@dismail.de wrote:
>
> Hey friends,
>
>
> I just saw this phoronix article that said that Intel is considering newer
> processors to only run in 64-bit mode.
>
> It is likely years away, but I thought I would mention it.
>
> Thanks,
>
> Joshua
>
> https://ww
On 10 May 2023, at 01:26, Samuel Thibault wrote:
>
> Sergey Bugaev, le mar. 09 mai 2023 00:31:07 +0300, a ecrit:
>> GCC was complaining about the mismatch in types between the 'fn' pointer
>> and the function pointers assigned to it. Since fn is meant to be used
>> with different function types,
On 9 Mar 2023, at 19:44, Sergey Bugaev wrote:
>
> On Thu, Mar 9, 2023 at 8:26 PM Andreas Schwab wrote:
>> Similarily, something is pulling in strtoul.os because it references a
>> symbol from there not defined by ../sysdeps/mach/hurd/dl-sysdep.c.
>>
>> elf/librtld.mapT should tell you where the
On 5 Mar 2023, at 20:46, Sergey Bugaev wrote:
>
> Speaking of wrapping the syscall and INTR_MSG_TRAP, I might need a
> little help — is there a proper way to tell GCC that my inline
> assembly needs a specific register as input _and_ clobbers it? In
> Rust, this would be, for instance,
>
> asm!(
On 25 Jan 2023, at 06:27, Flávio Cruz wrote:
>> On Tue, Jan 24, 2023 at 2:54 AM Samuel Thibault
>> wrote:
>> Flávio Cruz, le mar. 24 janv. 2023 01:15:15 -0500, a ecrit:
>> > + int kernel_id;
>> > + unsigned long flags;
>> > +
>> > + cpu_intr_save(&flags);
>> >
On 23 Jan 2022, at 15:02, Etienne Brateau wrote:
>
> The reindent part is mainly to replace tabs characters by spaces. Maybe the
> reindentation is not following the GNU convention (aka 8 spaces) but is
> following the general convention of the files. I can redo it by using 8
> spaces if neede
On 19 Oct 2021, at 13:41, Sergey Bugaev wrote:
>
> On Tue, Oct 19, 2021 at 3:18 PM Samuel Thibault
> wrote:
>> IIRC the kernel does unmount filesystems and flushes caches before
>> actually rebooting.
>
> These two comments provide some more details:
>
> "reboot doesn't sync: do that yourself
On 9 May 2021, at 14:56, hahawang wrote:
>
> Package: gftp
> Severity: important
> Version: 2.7.0b-1
> Tags: ftbfs,patch
> User:hahawang
> Usertags: hurd,hurd-i386
> X-Debbugs-CC:debian-h...@lists.debian.org,bug-hurd@gnu.org
>
> I decide to fix a broken package found at the recommended
> page(h
On 29 Apr 2021, at 12:48, haha wang wrote:
>
> Package: libtorrent
> Severity: important
> Version: 0.13.8-2
> Tags: patch
> User:hahw...@yandex.com
> Usertags: hurd
> X-Debbugs-CC: debian-h...@lists.debian.org
>
>
> I decide to fix a broken package found at the recommended page
> https://pe
On 26 Apr 2021, at 18:08, Sergey Bugaev wrote:
>
> This fixes Wstringop-overflow and Wstringop-truncation GCC warnings.
> See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059
>
> Also, fix a bug where a string was not properly null-terminated.
> ---
> lib.c | 4 ++--
> stow.c | 5 +++--
> 2 fi
On 23 Apr 2021, at 04:13, Andrew Eggenberger
wrote:
>
> I wrote this patch for the website after struggling with dir_readdir.
> Hopefully this will help the next person who needs it (probably me in a few
> months).
This is a part of POSIX, the only Hurd-specific thing is the use of the
underl
On 4 Mar 2021, at 22:02, Riccardo Mottola wrote:
>
> Hi,
>
> I decided to continue working on my ArcticFox efforts on hurd. I found this
> patch by Richard Braun:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1029809
>
> Being ArcticFox codebase around FF 40-45, it was relatively easy to
On 4 Mar 2021, at 22:04, Riccardo Mottola wrote:
>
> Hi all,
>
> continuing the journey of a custom gecko for HURD.
>
> 6:47.93 In file included from
> /home/multix/code/Arctic-Fox/ipc/chromium/src/third_party/libevent/epoll.c:36:
> 6:47.93 ../../dist/system_wrappers/sys/epoll.h:4:15: fatal
On 27 Feb 2021, at 18:00, Jessica Clarke wrote:
> On 27 Feb 2021, at 17:56, Paul Dufresne wrote:
>>
>> Was searching what are the missing package needed for sbcl to be built (sbcl
>> is a Common Lisp compiler).
>>
>> ~/.config/dpkg/buildflags.conf
>>
On 27 Feb 2021, at 17:56, Paul Dufresne wrote:
>
> Was searching what are the missing package needed for sbcl to be built (sbcl
> is a Common Lisp compiler).
>
> ~/.config/dpkg/buildflags.conf
>
> paul@binou:~$ dose-builddebcheck -v --deb-native-arch=i386
> /var/lib/apt/lists/deb.debian.org_d
On 27 Feb 2021, at 02:38, Paul Dufresne wrote:
>
> Here is the relevant part in malloc.c:
I'd advise you to not delve too deeply into malloc. This is likely a
buffer overflow that then corrupts the (inline) state maintained by
malloc, so you really need to be looking at vim.
Jess
> /*
>
On 27 Feb 2021, at 03:57, Paul Dufresne wrote:
>
> This looks like one of these moments I think I am brighter than I am... but
> here my reasoning of the problem so far:
>
> I am using https://github.com/bminor/glibc/blob/master/malloc/malloc.c
>
> In it we see:
>
>> chunk-> +-+-+-+-+-+-+-+-+
On 2 Feb 2021, at 12:57, Samuel Thibault wrote:
>
> Paul Dufresne, le mar. 02 févr. 2021 07:47:53 -0500, a ecrit:
>> sh: 1: dpkg-source: not found
>
> apt-file search dpkg-source
> [...]
> dpkg-dev: /usr/bin/dpkg-source
Also apt even printed out:
> N: Check if the 'dpkg-dev' package is install
On 24 Jan 2021, at 01:52, Jessica Clarke wrote:
> On 24 Jan 2021, at 01:27, Samuel Thibault wrote:
>> Jessica Clarke, le dim. 24 janv. 2021 01:16:13 +, a ecrit:
>>> maybe Hurd should also be nice.
>>
>> Right, we could hack ioctl into doing if (request == TIO
On 24 Jan 2021, at 01:27, Samuel Thibault wrote:
> Jessica Clarke, le dim. 24 janv. 2021 01:16:13 +, a ecrit:
>> maybe Hurd should also be nice.
>
> Right, we could hack ioctl into doing if (request == TIOCFLUSH && !arg)
> arg = &zero.
>
> That still le
On 24 Jan 2021, at 00:59, Jessica Clarke wrote:
> On 24 Jan 2021, at 00:41, Damien Zammit wrote:
>>
>> Hi,
>>
>> On 24/1/21 11:28 am, Samuel Thibault wrote:
>>> Why so? We do support SSE*.
>>>
>>> (glibc 2.33 will even use them aut
On 24 Jan 2021, at 00:41, Damien Zammit wrote:
>
> Hi,
>
> On 24/1/21 11:28 am, Samuel Thibault wrote:
>> Why so? We do support SSE*.
>>
>> (glibc 2.33 will even use them automatically for memcpy etc. thanks to
>> ifunc support recently getting enabled)
>
> OK, I ran the failing test in GDB:
>
On 21 Dec 2020, at 14:09, Samuel Thibault wrote:
> @@ -75,29 +86,52 @@ x86_gnu_fallback_frame_state
> return _URC_END_OF_STACK;
>
> handler_args = context->cfa;
> - scp = handler_args->scp;
> - usp = scp->sc_uesp;
> + sigcode = handler_args->legacy.sigcode;
> + if (sigcode < 4096)
Do y
On 17 Nov 2020, at 21:51, Samuel Thibault wrote:
>
> Svante Signell, le mar. 17 nov. 2020 22:47:04 +0100, a ecrit:
>> On Tue, 2020-11-17 at 21:59 +0100, Samuel Thibault wrote:
>>> Svante Signell, le mar. 17 nov. 2020 21:56:33 +0100, a ecrit:
>>
Got it. Can some of the drivers be tested with
On 13 Oct 2020, at 22:16, Ludovic Courtès wrote:
>
> Previously, 'pthread_kill (pthread_self (), -1)' would wrongfully
> succeed:
>
> https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00152.html
>
> Reported-by: Jan Nieuwenhuizen
> ---
> hurd/hurd-raise.c | 3 +++
> 1 file changed, 3 in
On 11 Aug 2020, at 01:17, Almudena Garcia wrote:
>
> > That being said, instead of hardcoding the maximum number of CPUs to
> > be 256, you can just let the user choose whatever value is preferred.
> > That's what Linux does.
>
> But this could cause coherency problems.
Coherency is a very spe
On 4 Aug 2020, at 22:47, Junling Ma wrote:
>
> The tot_num_intr field is a count of how many deliverable interrupts across
> all lines. When we move
> to the scheme of blocking read for request and write for acking, it is
> possible that an interrupt
> can happen during a small period that the
On 30 Jul 2020, at 22:12, Richard Braun wrote:
> On Thu, Jul 30, 2020 at 10:09:01PM +0100, Jessica Clarke wrote:
>>> It's physically memory mapped to the local APIC address space, but
>>> because of that, it's also not optimal. All systems I know use a scheme
>&g
On 30 Jul 2020, at 22:06, Richard Braun wrote:
> On Thu, Jul 30, 2020 at 10:44:40PM +0200, Samuel Thibault wrote:
I'm wondering: is it really *that* simple to get the current cpu number,
just read a memory location? I'm surprised that this would provide
different results on differe
On 28 Jul 2020, at 00:44, Samuel Thibault wrote:
> Almudena Garcia, le lun. 27 juil. 2020 21:15:10 +0200, a ecrit:
>> [if [ $mach_ncpus -gt 1 ]; then]
>> AC_DEFINE([MULTIPROCESSOR], [1], [set things up for a multiprocessor])
>> + AC_DEFINE_UNQUOTED([NCPUS], [255], [number of CPUs])
>
> Perhaps
mpare with the mine.
>
> How can I solve this?
Look up git rebase.
> El dom., 19 jul. 2020 a las 20:51, Almudena Garcia
> () escribió:
> ok. I had splitted It manually. Now I'll try again this way.
>
> El dom., 19 jul. 2020 a las 20:49, Jessica Clarke ()
&
On 19 Jul 2020, at 19:46, Almudena Garcia wrote:
>
> > for any patch it’s best to not just show a single large diff but to
> > split the changes into logically related commits
> I've just split the patch. I enumerated them following the dependencies
> order.
>
> > The commit
> > message should
On 19 Jul 2020, at 18:06, Almudena Garcia wrote:
>
> I fixed tabulations and comments style. Now better?
Not hugely. Go read files in the same directory and see if they look
like what you've written.
Jess
> El dom., 19 jul. 2020 a las 18:49, Jessica Clarke ()
> escribió:
On 19 Jul 2020, at 17:44, Almudena Garcia wrote:
>
> Hi all:
>
> I attach a patch, with the code to find the cpus and enumerate them, reading
> from ACPI tables and MADT (APIC) tables.
>
> I've tested it over Qemu, but I recommends to test It before committing,
> anyway.
>
> You can find the
40 matches
Mail list logo
