gmane.os.hurd.bugs

Re: »No more PTYs« message

Riccardo Mottola — 2012-05-20T21:10:07

Hi,

On 05/25/12 11:34, Thomas Schwinge wrote:
I often had my pty's exhausted when accessing remotely. Often only after 
a couple of shells/logins. I never tried the "ls" trick on pty's. I will 
test that to see if my box suffers from the same problem.

Riccardo

Re: »No more PTYs« message

Richard Braun — 2012-05-25T09:49:17

On darnassus, this bug was seen faster when syslogd was enabled.

Re: »No more PTYs« message

Samuel Thibault — 2012-05-25T09:40:47

Samuel Thibault, le Fri 25 May 2012 11:39:53 +0200, a écrit :

Also, it only happens on some boxes, on buildds and my hurd box, I don't
have the issue. It's very simple to test actually: log off from the
machine, log on again, and check whether ssh was able to reuse the tty
you had.

Samuel

Re: »No more PTYs« message

Samuel Thibault — 2012-05-25T09:39:53

Thomas Schwinge, le Fri 25 May 2012 11:34:45 +0200, a écrit :

Usually I've seen that *not* because term translators are not started,
but because they are all somehow busy, and openpty doesn't want to use
them for some reason. I would kill them and then it'd be ok again. ls
might have another side effect resulting to curing the issue too. I
haven't had time to investigate further.

Samuel

»No more PTYs« message

Thomas Schwinge — 2012-05-25T09:34:45

Hi!

We've been seeing this on darnassus several times: try to allocate a PTY
(log in via SSH, or start screen, etc.), and get a »No more PTYs«
message.  Now the same happend on flubber: I could log in via SSH, but
starting screen failed.  I did a »ls -l /dev/tty* /dev/pty*« (which will
start all translators due to »stat«ing the nodes) -- and then I was able
to start screen.  Strange?


Grüße,
 Thomas

Re: kernel panic on network activity

Samuel Thibault — 2012-05-24T07:20:04

Riccardo Mottola, le Sun 20 May 2012 09:39:40 +0200, a écrit :

OK, good!

Samuel

Re: kernel panic on network activity

Riccardo Mottola — 2012-05-20T07:39:40

Hi Samuel,

On 05/17/12 01:37, Samuel Thibault wrote:
If I built and installed correctly (well, I did run configure, make, 
gzipped the "gnumach" file put it in /boot and directed grub to it, the 
patch works fine. Network works, I can ping, download and start network 
daemons.

Thank you,

Riccardo

Re: grub-pc makes hurd crash

Riccardo Mottola — 2012-05-22T19:52:19

that file contains only a single line for me:
(hd0)    /dev/hd0

I am running stock 20120505 gnumach.

Riccardo

Re: [PATCH,HURD] sendto: do not crash when addr is NULL

Roland McGrath — 2012-05-21T20:00:03

Put the name of a local variable in all caps when mentioning it in the log
entry or comments.

Initializing ERR at the top is confusingly subtle.
Instead, you make the code that actually cares look like:

if (addr == NULL || addr->sun_family == AF_LOCAL)
  err = 0;
else
  err = __socket_create_address (...);
if (! err)
  ...

It looks like the existing code also has a leak of APORT in the case where
HURD_DPORT_USE fails (i.e. invalid fd).  So you should reorganize in some
way that fixes that too.

It might be simplest just to move the creation of the address port (both
the AF_LOCAL case and the default case) into a subroutine and just call
that inside HURD_DPORT_USE.  It means that the descriptor structure and
port are kept alive around the AF_LOCAL case's calls, but that seems OK.


Thanks,
Roland

[PATCH,HURD] sendto: do not crash when addr is NULL

Pino Toscano — 2012-05-20T20:58:24

Hi,

currently, sendto() crashes when the specified addr is NULL; the 
attached patch fixes it making sendto() with NULL addr behave as it 
would be a plain send().

Thanks,

Re: grub-pc makes hurd crash

Samuel Thibault — 2012-05-19T14:27:34

Riccardo Mottola, le Sat 19 May 2012 16:13:19 +0200, a écrit :

I don't see anything obvious, from the source code the assertion should
never trigger, so it might just be some overflow somewhere. Does it also
happen if you remove hd2 from your /boot/grub/device.map?

Samuel

grub-pc makes hurd crash

Riccardo Mottola — 2012-05-19T14:15:19

Hi,

while configuring/installing grub-pc from debian, the kernel panics in 
the way attached in the screenshot.

Riccardo

Re: grub-pc makes hurd crash

Samuel Thibault — 2012-05-19T14:14:40

Riccardo Mottola, le Sat 19 May 2012 16:13:19 +0200, a écrit :

which version of the kernel are you running exactly?

Samuel

grub-pc makes hurd crash

Riccardo Mottola — 2012-05-19T14:13:19

Hi,

while configuring/installing grub-pc from debian, the kernel panics in 
the way attached in the screenshot.

Riccardo

restartable netdde

Samuel Thibault — 2012-05-19T12:45:58

Hello,

One nifty feature of userland drivers is that you can easily restart
them by just making the translator away. However, that makes pfinet
away, as well as all current network connexions and listening servers.

But pfinet doesn't really need to exit: it could just reopen the network
device after e.g. 1s delay, reconfigure it, and continue as if nothing
happened.

Could somebody have a look?

Samuel

Re: kernel panic on network activity

Samuel Thibault — 2012-05-16T23:37:15

Riccardo Mottola, le Wed 16 May 2012 00:35:02 +0200, a écrit :

The address looked odd to me, but with the backtrace it's much clearer.
It's simply the bios32 entry call which needs to be offset, like Linux
does. Please try the attached patch over the latest git tree.

Samuel
diff --git a/linux/src/arch/i386/kernel/bios32.c b/linux/src/arch/i386/kernel/bios32.c
index 4747972..b069ce4 100644
--- a/linux/src/arch/i386/kernel/bios32.c
+++ b/linux/src/arch/i386/kernel/bios32.c
< at >< at > -206,7 +206,7 < at >< at > static int check_pcibios(void)
 int pack;
 
 if ((pcibios_entry = bios32_service(PCI_SERVICE))) {
-pci_indirect.address = pcibios_entry;
+pci_indirect.address = phystokv(pcibios_entry);
 
 save_flags(flags); cli();
 __asm__("lcall *(%%edi); cld\n\t"
< at >< at > -903,7 +903,7 < at >< at > unsigned long pcibios_init(unsigned long memory_start, unsigned long memory_end)
 } else {
 bios32_entry = check->fields.entry;
 printk ("pcibios_init : BIOS32 Service Directory entry at 0x%lx\n", bios32_entry);
-bios32_indirect.

Re: kernel panic on network activity

Riccardo Mottola — 2012-05-16T22:44:52

This is a screenshot running 20120505-dbg and then "trace".


Riccardo

Re: __thread errno

Roland McGrath — 2012-05-16T22:26:01

TLS_INIT_TP is done early enough in rtld.c that it ought to be before
anything tries to use errno.  Figure out the call chain.

Re: __thread errno

Thomas Schwinge — 2012-05-16T20:27:19

Hi!

On Thu, 10 May 2012 17:25:59 +0800, I wrote:


It appears to me that sysdeps/mach/hurd/dl-sysdep.h bites us:

    /* The private errno doesn't make sense on the Hurd.  errno is always the
       thread-local slot shared with libc, and it matters to share the cell
       with libc because after startup we use libc functions that set errno
       (open, mmap, etc).  */
    
    #define RTLD_PRIVATE_ERRNO 0

And thus in the GNU Hurd configuration, ld.so code uses the __thread
errno -- but TLS has not been set up at this point in ld.so?

In sysdeps/generic/dl-sysdep.h, this is explained/defined as follows:

    /* This macro must be defined to either 0 or 1.
    
       If 1, then an errno global variable hidden in ld.so will work right with
       all the errno-using libc code compiled for ld.so, and there is never a
       need to share the errno location with libc.  This is appropriate only if
       all the libc functions that ld.so uses are called without PLT and always
       get the versions linked i

Re: kernel panic on network activity

Riccardo Mottola — 2012-05-16T10:09:56

Hi,,

On 05/16/2012 12:35 AM, Riccardo Mottola wrote:

let me add that gnumach is 20120505, while version 20120219 works! I 
stil had it in the apt cache and downgraded gnumach, common and image.

Riccardo
(grey_gandalf on IRC)

kernel panic on network activity

Riccardo Mottola — 2012-05-15T22:35:02

Hi,

I attach a screenshot on how my kernel panics when I just "ping" 
localhost. I provide a "screenshot" since I had to uninstall any ssh, 
telnet or login daemon to be able to boot.
This happens after the last debian update I was doing.

dpkg -l | grep hurd
reports: 20120408-3

Any hints?

Riccardo