Re: [PATCH,HURD][RFC] hurdselect: Step7, almost complete rewrite finished

2013-02-11 Thread Svante Signell 
On Thu, 2013-01-24 at 13:58 +0100, Svante Signell wrote:

Ok, here is the not yet complete patch for hurdselect.c. An explanation
will follow tomorrow, too late to get everything written down correctly
now. The patch is longer than the new file so maybe not very readable.
therefore I also include a patched hurdselect.c. some minor tweaks will
still be added, but most of it is there now. Additionally, a lot of test
code will follow soon. No (found) regressions so far, only a few test
code examples failing (as for some other OSes).

Svante
 
--- a/hurd/hurdselect.c	2013-01-08 09:42:54.0 +0100
+++ b/hurd/hurdselect.c	2013-02-10 14:51:32.0 +0100
@@ -33,6 +33,279 @@
from SELECT_ALL (which better not have the high bit set).  */
 #define SELECT_RETURNED ((SELECT_ALL << 1) & ~SELECT_ALL)
 
+struct dfd
+{
+  struct hurd_userlink ulink;
+  struct hurd_fd *cell;
+  mach_port_t io_port;
+  int type;
+  mach_port_t reply_port;
+};
+
+/* Helper functions */
+int _io_select_request (int ispoll, int firstfd, int lastfd,
+		   error_t *errvec, mach_port_t *portset, struct dfd *d)
+{
+  int i, got = 0;
+
+  if (firstfd == -1) /* DELAY */
+/* But not if there were no ports to deal with at all.
+   We are just a pure timeout.  */
+  *portset = __mach_reply_port ();
+  else /* POLL || SELECT */
+{
+  *portset = MACH_PORT_NULL;
+
+  for (i = firstfd; i <= lastfd; ++i)
+	{
+	  int err = 0, err1 = 0;
+	  int type = d[i].type;
+	  if (type)
+	{
+	  d[i].reply_port = __mach_reply_port ();
+	  /* FIXME: Needed for poll to account for the round trip delay */
+	  if (ispoll)
+		err = __io_select (d[i].io_port, d[i].reply_port, 1, &type);
+	  else
+		err = __io_select (d[i].io_port, d[i].reply_port, 0, &type);
+	  switch (err)
+		{
+		case MACH_RCV_TIMED_OUT:
+		  /* No immediate response.  This is normal.  */
+		  err = 0;
+		  if (firstfd == lastfd)
+		/* When there's a single descriptor, we don't need a
+		   portset, so just pretend we have one, but really
+		   use the single reply port.  */
+		*portset = d[i].reply_port;
+		  else if (got == 0)
+		/* We've got multiple reply ports, so we need a port set to
+		   multiplex them.  */
+		{
+		  /* We will wait again for a reply later.  */
+		  if (*portset == MACH_PORT_NULL)
+			/* Create the portset to receive all the replies on.  */
+			err1 = __mach_port_allocate (__mach_task_self (),
+		   MACH_PORT_RIGHT_PORT_SET,
+		   portset);
+		  if (! err1)
+			/* Put this reply port in the port set.  */
+			__mach_port_move_member (__mach_task_self (),
+		 d[i].reply_port, *portset);
+		}
+		  break;
+		  
+		  /* FIXME: Only for poll */
+		  if (ispoll)
+		{
+		case EPIPE:
+		case EIO:
+		  errvec[i] = err;
+		  //errno = ENOTCONN;
+		  break;
+		}
+
+		default:
+		  /* No other error should happen.  Callers of select
+		 don't expect to see errors, so we simulate
+		 readiness of the erring object and the next call
+		 hopefully will get the error again.  */
+		  type = SELECT_ALL;
+		  /* FALLTHROUGH */
+
+		case 0:
+		  /* We got an answer.  */
+		  if ((type & SELECT_ALL) == 0)
+		/* Bogus answer; treat like an error, as a fake positive.  */
+		type = SELECT_ALL;
+
+		  /* This port is already ready already.  */
+		  d[i].type &= type;
+		  d[i].type |= SELECT_RETURNED;
+		  ++got;
+		  break;
+		} /* switch (err) */
+	  _hurd_port_free (&d[i].cell->port, &d[i].ulink, d[i].io_port);
+
+	  /* FIXME: Handle only errors EPIPE (pflocal), EIO (pfinet) for POLL*/  
+	  if ((ispoll && (err != 0 && err != EPIPE && err != EIO)) ||
+		  (!ispoll && err != 0))
+	  //if ((ispoll && (err != 0 && err != ENOTCONN)) || (!ispoll && err != 0))
+	  //if ((err != 0) && ((ispoll && err != ENOTCONN) || !ispoll))
+		{
+		  errno = err;
+		  errvec[i] = err;
+		  got = -1;
+		  return got;
+		}
+	} /* if (type) */
+	} /* for */
+} /* else */
+  return got;
+} /* _io_select_request() */
+
+int _wait_for_replies (int nfds, int firstfd, int lastfd, int got,
+		   mach_msg_timeout_t to,
+		   error_t err, mach_port_t portset, struct dfd *d,
+		   const struct timespec *timeout, const sigset_t *sigmask,
+		   sigset_t *oset)
+{
+  int i;
+  union typeword		/* Use this to avoid unkosher casts.  */
+  {
+mach_msg_type_t type;
+uint32_t word;
+  };
+  assert (sizeof (union typeword) == sizeof (mach_msg_type_t));
+  assert (sizeof (uint32_t) == sizeof (mach_msg_type_t));
+
+union
+{
+  mach_msg_header_t head;
+#ifdef MACH_MSG_TRAILER_MINIMUM_SIZE
+  struct
+  {
+	mach_msg_header_t head;
+	NDR_record_t ndr;
+	error_t err;
+  } error;
+  struct
+  {
+	mach_msg_header_t head;
+	NDR_record_t ndr;
+	error_t err;
+	int result;
+	mach_msg_trailer_t trailer;
+  } success;
+#else
+  struct
+  {
+	mach_msg_header_t head;
+	union typeword err_type;
+

[Carol Smith] [GSoC Mentors Announce] Google Summer of Code 2013

2013-02-11 Thread Thomas Schwinge 
Hi!

There will be a Google Summer of Code 2013, see below.  Assuming GNU is
again going to apply and accepted as a mentoring organization -- if we're
interested, we can also already begin thinking about projects to propose.
 has
the current list; to be updated.  Speak up (or directly edit the pages)
if you have any suggestions!

| From: Carol Smith 
| Date: Mon, 11 Feb 2013 11:02:32 -0800
| Message-ID: 

| Subject: [GSoC Mentors Announce] Google Summer of Code 2013
| To: gsoc-mentors-annou...@googlegroups.com
| Reply-To: gsoc-mentors-announce+own...@googlegroups.com
| 
| Hi GSoC mentors and org admins,
| 
| We've announced that we're doing Google Summer of Code 2013 [1]. Yay!
| 
| If you would like to help spread the word about GSoC, we have presentations
| [2], logos [3], and flyers [4] for you to use. Please host meetups, tell
| your friends and colleagues about the program, go to conferences, talk to
| people about the program, and just generally do all the awesome
| word-of-mouth stuff you do every year to promote the program.
| 
| The GSoC calendar, FAQ, and events timeline have all been updated with this
| year's important dates, so please refer to those for the milestones for
| this year's program. NB: the normal timeline for the program has been
| modified for this year. You'll probably want to examine the dates closely
| to make sure you know when important things are happening.
| 
| Please consider translating the presentations and/or flyers into your
| native language and submitting them directly to me to post on the wiki.
| Localization for our material is integral to reaching the widest possible
| audience around the world. If you decide to translate a flyer, please fill
| out our form to request a thank you gift for your effort. [5]
| 
| If you decide to host a meetup, please email me to let me know the date,
| time, and location so I can put it on the GSoC calendar. Also, remember to
| take pictures at your meetup and write up a blog post for our blog using
| our provided template for formatting [6]. If you need promotional items for
| your attendees, please fill out our form [7] to request some; we're happy
| to send some along. We can provide up to about 25 pens, notebooks, or
| stickers and/or a few t-shirts. Please keep in mind, though, that shipping
| restrictions and timeline vary country-to-country; request items early to
| make sure they get there on time! If you have questions about hosting
| meetups, please see the section in our FAQ [8].
| 
| Please also consider applying to participate as an organization again this
| year or maybe joining as a mentor for your favorite organization if they
| are selected this year.
| 
| We rely on you for your help for the success of this program, so thank you
| in advance for all the work you do!
| 
| [1] -
| 
http://google-opensource.blogspot.com/2013/02/flip-bits-not-burgers-google-summer-of.html
| [2] -
| http://code.google.com/p/google-summer-of-code/wiki/ProgramPresentations
| [3] - http://code.google.com/p/google-summer-of-code/wiki/GsocLogos
| [4] - http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers
| [5] - http://goo.gl/gEHDO
| [6] - http://goo.gl/wbZrt
| [7] - http://goo.gl/0BsR8
| [8] - http://goo.gl/2NGfp
| 
| Cheers,
| Carol


Grüße,
 Thomas


pgpNl34dRDwOm.pgp
Description: PGP signature

Re: hd0 dma error

2013-02-11 Thread Samuel Thibault 
Alex Sassmannshausen, le Mon 11 Feb 2013 18:41:59 +, a écrit :
> It might be my untrained eye, but to me this also very much looks like the
> errors I was getting installing and booting the HURD on a brand new IDE.
> 
> --8<---
> > hd0: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }

No, the message is very different: irq timeout means the driver got bored
with waiting for the disk, and Seek is Complete, while here:

> > Riccardo Mottola, le Mon 11 Feb 2013 19:28:32 +0100, a écrit :
> >> hd0: dma_intr: status=0x51 { DriveReady SeekCompleteError }
> >> hd0: dma_intr: error=0x40 { UncorrectableError }, LBAsect=44914186,
> >> sector=27804896
> >> end_request: I/O error, dev 03:07, sector 27804896

It's the disk that said SeekCompleteError, i.e. an explicit error.

Samuel

Re: hd0 dma error

2013-02-11 Thread Alex Sassmannshausen 
It might be my untrained eye, but to me this also very much looks like the
errors I was getting installing and booting the HURD on a brand new IDE.

--8<---
> hd0: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> hd0: irq timeout: status=0x58 { DriveReady SeekComplete }
> hd0: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> ide0: reset: success
> hd0: irq timeout: status=0x58 { DriveReady SeekComplete }
> hd0: irq timeout: status=0x58 { DriveReady SeekComplete }
> hd0: irq timeout: status=0x58 { DriveReady SeekComplete }
> hd0: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> ide0: reset: success
> hd0: irq timeout: status=0x58 { DriveReady SeekComplete }
> end_request: I/O error, dev 03:00, sector 2
--8<---
Thread: Debian Hurd Installer problems.

Best wishes,

Alex

Samuel Thibault writes:

> Riccardo Mottola, le Mon 11 Feb 2013 19:28:32 +0100, a écrit :
>> hd0: dma_intr: status=0x51 { DriveReady SeekCompleteError }
>> hd0: dma_intr: error=0x40 { UncorrectableError }, LBAsect=44914186,
>> sector=27804896
>> end_request: I/O error, dev 03:07, sector 27804896
>> 
>> I hope my drive is not failing and that it is some kind of hardware error?
>
> Well, IIRC this precise kind of error (SeekCompleteError) means the disk
> could not find the sector. So it likely means a hardware issue.
>
> Samuel

Re: hd0 dma error

2013-02-11 Thread Samuel Thibault 
Riccardo Mottola, le Mon 11 Feb 2013 19:28:32 +0100, a écrit :
> hd0: dma_intr: status=0x51 { DriveReady SeekCompleteError }
> hd0: dma_intr: error=0x40 { UncorrectableError }, LBAsect=44914186,
> sector=27804896
> end_request: I/O error, dev 03:07, sector 27804896
> 
> I hope my drive is not failing and that it is some kind of hardware error?

Well, IIRC this precise kind of error (SeekCompleteError) means the disk
could not find the sector. So it likely means a hardware issue.

Samuel

hd0 dma error

2013-02-11 Thread Riccardo Mottola 

Hi,

I was compiling again some sources and got a:

hd0: dma_intr: status=0x51 { DriveReady SeekCompleteError }
hd0: dma_intr: error=0x40 { UncorrectableError }, LBAsect=44914186, 
sector=27804896

end_request: I/O error, dev 03:07, sector 27804896

I hope my drive is not failing and that it is some kind of hardware 
error? I never had problems with it, but I never got this error with 
HURD either.


Afterwards I got a fsck error, as if the volume got unmounted and a 
remount was attempted.


Riccardo

Re: [PATCH,HURD] Fix reading core

2013-02-11 Thread Samuel Thibault 
Samuel Thibault, le Mon 11 Feb 2013 03:01:09 +0100, a écrit :
> The i386 GNU/Hurd ELF core format actually follows the uaccess gregset_t
> array format, not the Mach thread state format.  This fixes gdb reading
> it.

I have uploaded a fixed package on debian-ports.

> * gdb/i386gnu-nat.c (CREG_OFFSET): New macro.
> (creg_offset): New array.
> (CREG_ADDR): Use creg_offset instead of reg_offset.
> 
> --- a/gdb/i386gnu-nat.c.original  2013-02-11 00:46:02.0 +
> +++ b/gdb/i386gnu-nat.c   2013-02-11 00:48:09.0 +
> @@ -56,8 +56,21 @@
>REG_OFFSET (ds), REG_OFFSET (es), REG_OFFSET (fs), REG_OFFSET (gs)
>  };
>  
> +/* Offset to the greg_t location where REG is stored.  */
> +#define CREG_OFFSET(reg) (REG_##reg * 4)
> +
> +/* At CREG_OFFSET[N] is the offset to the greg_t location where
> +   the GDB register N is stored.  */
> +static int creg_offset[] =
> +{
> +  CREG_OFFSET (EAX), CREG_OFFSET (ECX), CREG_OFFSET (EDX), CREG_OFFSET (EBX),
> +  CREG_OFFSET (UESP), CREG_OFFSET (EBP), CREG_OFFSET (ESI), CREG_OFFSET 
> (EDI),
> +  CREG_OFFSET (EIP), CREG_OFFSET (EFL), CREG_OFFSET (CS), CREG_OFFSET (SS),
> +  CREG_OFFSET (DS), CREG_OFFSET (ES), CREG_OFFSET (FS), CREG_OFFSET (GS)
> +};
> +
>  #define REG_ADDR(state, regnum) ((char *)(state) + reg_offset[regnum])
> -#define CREG_ADDR(state, regnum) ((const char *)(state) + reg_offset[regnum])
> +#define CREG_ADDR(state, regnum) ((const char *)(state) + 
> creg_offset[regnum])
>  
>  
>  /* Get the whole floating-point state of THREAD and record the values