Bug#995467: Salvaging status

[Wesley W. Terpstra]

Can I pass the baton of mlton package ownership off to someone?

I've been intending to some day come back to working on this, but the
reality is, I probably never will.
I'd be happy to answer questions about how to get things to work, if that
is helpful.

You need someone who either is currently or wants to become a debian
developer (and go through that whole process).

On Mon, Dec 20, 2021 at 11:39 AM Henry Cejtin 
wrote:

> I built the pdf guide a while ago, and I noticed a few problems that I
> managed to work around.
>
> One point is that you need to have lots of other packages installed, and
> if you don't, it doesn't say anything clear.
>
> I installed all of the following to make it work:
>
> asciidoc
> texlive-full
> docbook
> source-highlight
> context-nonfree
> context-doc-nonfree
> docbook-dsssl-doc
> docbook-defguide
> python-apt-doc
> vim-doc
> w3m
> lynx
> links
> vim-scripts
> epubcheck
> sgmls-doc
>
> (This was a while ago, under Debian Stretch.)
>
> A second point is that under Buster and Bullseye, the convert program
> (from ImageMagick) won't accept pdf's.  The reason has to do with an old
> Ghostscript but and security concerns.
>
> This problem of convert losing this capability also causes the Debian
> package pdfsandwich to no longer work.  It is all a real problem.  Note,
> that there are many other ways to do what needs to be done.  To put
> images into a pdf you can use the Debian package img2pdf.  To go the
> other way, you can use pdfimages or pdftocairo (in poppler-utils).
>
> Somehow it seems that this should be fixed in the imagemagick package
> since there must be other programs that depend on it.
>
> I agree with the comments from people about it probably not being a good
> idea to just edit /etc/ImageMagick-6/policy.xml to let Ghostscript do
> stuff.  That definitely makes me too nervous to do.
>
> On Sun, Dec 19, 2021 at 9:33 PM Ryan Kavanagh  wrote:
> >
> > Another status update for those following at home:
> >
> > The mlton package (upstream release 20210117) now bootstraps and builds!
> >
> > For some reason I can't get the guide to compile (pdflatex spits out a
> > bunch of errors and then dies, and the tool that calls pdflatex suggests
> > the docbook input is invalid), so I might just temporarily disable
> > building/installing it. I figure having an installable mlton package
> > sans PDF guide is better than having no mlton package whatsoever in the
> > meantime.
> >
> > I have considerably more time to work on this now that the semester is
> > over, so I'm hoping to get it uploaded in the next week or so.
> >
> > Best,
> > Ryan
> >
> > --
> > |)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
> > |\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A
>

[tip: irq/core] irqchip/sifive-plic: Remove incorrect requirement about number of irq contexts

[tip-bot2 for Wesley W. Terpstra]

The following commit has been merged into the irq/core branch of tip:

Commit-ID: 82f2202ddc97490994fad0dbfec04a014fa5163d
Gitweb:
https://git.kernel.org/tip/82f2202ddc97490994fad0dbfec04a014fa5163d
Author:Wesley W. Terpstra 
AuthorDate:Tue, 12 May 2020 10:26:36 -07:00
Committer: Marc Zyngier 
CommitterDate: Mon, 18 May 2020 10:28:30 +01:00

irqchip/sifive-plic: Remove incorrect requirement about number of irq contexts

A PLIC may not be connected to all the cores. In that case, nr_contexts
may be less than num_possible_cpus. This requirement is only valid a single
PLIC is the only interrupt controller for the whole system.

Signed-off-by: Atish Patra 
Signed-off-by: "Wesley W. Terpstra" 
Signed-off-by: Marc Zyngier 
Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 
Link: https://lore.kernel.org/r/20200512172636.96299-1-atish.pa...@wdc.com

[Atish: Modified the commit text]
---
 drivers/irqchip/irq-sifive-plic.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/irqchip/irq-sifive-plic.c 
b/drivers/irqchip/irq-sifive-plic.c
index d0a71fe..822e074 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -301,8 +301,6 @@ static int __init plic_init(struct device_node *node,
nr_contexts = of_irq_count(node);
if (WARN_ON(!nr_contexts))
goto out_iounmap;
-   if (WARN_ON(nr_contexts < num_possible_cpus()))
-   goto out_iounmap;
 
error = -ENOMEM;
priv->irqdomain = irq_domain_add_linear(node, nr_irqs + 1,

Bug#904475: mlton: build-depends on the version of itself that is going to be built

[Wesley W. Terpstra]

On Tue, Jul 24, 2018 at 9:01 AM, Andreas Beckmann  wrote:

> Source: mlton
> Version: 20180207-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the
> past)
>
> now you got the package deadlocked w.r.t. their build-depends
>

Nah. This is a normal situation that resolves after a week or so. It
happens pretty much every time when I upload a new version.

I am just need to find some time to sort out the 'world' regression
segfault issue, which is caused by address space randomization, before I
upload the next version.

Bug#904475: mlton: build-depends on the version of itself that is going to be built

[Wesley W. Terpstra]

On Tue, Jul 24, 2018 at 9:01 AM, Andreas Beckmann  wrote:

> Source: mlton
> Version: 20180207-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the
> past)
>
> now you got the package deadlocked w.r.t. their build-depends
>

Nah. This is a normal situation that resolves after a week or so. It
happens pretty much every time when I upload a new version.

I am just need to find some time to sort out the 'world' regression
segfault issue, which is caused by address space randomization, before I
upload the next version.

Accepted mlton 20180207-1 (source amd64) into unstable

[Wesley W. Terpstra]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 10 Apr 2018 13:38:06 -0700
Source: mlton
Binary: mlton mlton-basis mlton-doc mlton-compiler mlton-tools 
mlton-runtime-native mlton-runtime-alpha-linux-gnu 
mlton-runtime-x86-64-linux-gnu mlton-runtime-aarch64-linux-gnu 
mlton-runtime-arm-linux-gnueabi mlton-runtime-arm-linux-gnueabihf 
mlton-runtime-hppa-linux-gnu mlton-runtime-i486-linux-gnu 
mlton-runtime-i486-kfreebsd-gnu mlton-runtime-x86-64-kfreebsd-gnu 
mlton-runtime-mips64el-linux-gnuabi64 mlton-runtime-mips-linux-gnu 
mlton-runtime-mipsel-linux-gnu mlton-runtime-powerpc-linux-gnu 
mlton-runtime-powerpc64le-linux-gnu mlton-runtime-riscv64-linux-gnu 
mlton-runtime-s390x-linux-gnu mlton-runtime-sparc-linux-gnu
Architecture: source amd64
Version: 20180207-1
Distribution: sid
Urgency: low
Maintainer: Wesley W. Terpstra 
Changed-By: Wesley W. Terpstra 
Description:
 mlton  - Optimizing compiler for Standard ML
 mlton-basis - Optimizing compiler for Standard ML - basis library
 mlton-compiler - Optimizing compiler for Standard ML - compiler
 mlton-doc  - Optimizing compiler for Standard ML - documentation
 mlton-runtime-aarch64-linux-gnu - Optimizing compiler for Standard ML - arm64 
runtime libraries
 mlton-runtime-alpha-linux-gnu - Optimizing compiler for Standard ML - alpha 
runtime libraries
 mlton-runtime-arm-linux-gnueabi - Optimizing compiler for Standard ML - armel 
runtime libraries
 mlton-runtime-arm-linux-gnueabihf - Optimizing compiler for Standard ML - 
armhf runtime libraries
 mlton-runtime-hppa-linux-gnu - Optimizing compiler for Standard ML - hppa 
runtime libraries
 mlton-runtime-i486-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-i386 runtime libra
 mlton-runtime-i486-linux-gnu - Optimizing compiler for Standard ML - i386 
runtime libraries
 mlton-runtime-mips-linux-gnu - Optimizing compiler for Standard ML - mips 
runtime libraries
 mlton-runtime-mips64el-linux-gnuabi64 - Optimizing compiler for Standard ML - 
mips64el runtime libraries
 mlton-runtime-mipsel-linux-gnu - Optimizing compiler for Standard ML - mipsel 
runtime libraries
 mlton-runtime-native - Optimizing compiler for Standard ML - native runtime 
libraries
 mlton-runtime-powerpc-linux-gnu - Optimizing compiler for Standard ML - 
powerpc runtime libraries
 mlton-runtime-powerpc64le-linux-gnu - Optimizing compiler for Standard ML - 
ppc64el runtime libraries
 mlton-runtime-riscv64-linux-gnu - Optimizing compiler for Standard ML - 
riscv64 runtime libraries
 mlton-runtime-s390x-linux-gnu - Optimizing compiler for Standard ML - s390x 
runtime libraries
 mlton-runtime-sparc-linux-gnu - Optimizing compiler for Standard ML - sparc 
runtime libraries
 mlton-runtime-x86-64-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-amd64 runtime libr
 mlton-runtime-x86-64-linux-gnu - Optimizing compiler for Standard ML - amd64 
runtime libraries
 mlton-tools - Optimizing compiler for Standard ML - tools
Changes:
 mlton (20180207-1) unstable; urgency=low
 .
   * New upstream release; new build-depends:
* changed from htmldoc to python-pygments
* changed from imagemagick to graphicsmagick
* removed dblatex, ruby-albino, librsvg2-bin
   * Bump debhelper compat to 10 (cdbs broken with 11/12)
   * Bump standards version to 4.1.4
* mlton now only recommends mlton-doc
   * Added riscv64 port
Checksums-Sha1:
 0652029c31067690bb9607b70df0a44122ac0298 4351 mlton_20180207-1.dsc
 e859c645baf9b53669139e708af4f7badb1caa3b 25003695 mlton_20180207.orig.tar.gz
 fe8d20eb155837bcdf303ab367868647016419c1 13344 mlton_20180207-1.debian.tar.xz
 56e833ac8129db6330bb746fc578d5496e485600 3070708 
mlton-compiler_20180207-1_amd64.deb
 e20426797bd27ac6d73adbeca3db207ded5cb50d 8480 
mlton-runtime-native_20180207-1_amd64.deb
 fc187e78f1a5350a4d9cb227b6504d973a604e27 198252 
mlton-runtime-x86-64-linux-gnu_20180207-1_amd64.deb
 46a7fe254a50e41fb9198f4d5fcbae27ffecd57e 1092612 
mlton-tools_20180207-1_amd64.deb
 f498803a9a2b090c1cd226982aba9663d072a009 10145 mlton_20180207-1_amd64.buildinfo
Checksums-Sha256:
 7a849b6908b9bd299b8caed38228cc0589cbc749dd9e427bd87bf9ba52879a80 4351 
mlton_20180207-1.dsc
 872cd98da3db720cbe05f673eaa1776d020d828713753f18fa5dd6a268195fef 25003695 
mlton_20180207.orig.tar.gz
 2bb686ab9dceebc6f61c4c03e5e446627d338f7badc569152a74e48638d12609 13344 
mlton_20180207-1.debian.tar.xz
 8c9bc43cb7f8304edee95857c1ec914e0605604b2b1864f8096776b70dfe3b40 3070708 
mlton-compiler_20180207-1_amd64.deb
 d44cb153c91634b80c56b85f25fdeb3e5201053466d645ce6d093de55d2b95dc 8480 
mlton-runtime-native_20180207-1_amd64.deb
 d62506bde943cbe34e3d69751ffc2e0da677cfbe57353775fe7a918eb7ca12ee 198252 
mlton-runtime-x86-64-linux-gnu_20180207-1_amd64.deb
 cacbfa08b545875912d85752fd07849461db57c6443e56e6b3749265a5d5ddd1 1092612 
mlton-tools_20180207-1_amd64.deb
 9ebe5553cfb73c2b47cca56adb3ee4e5849d2a9dc8d7e1fabbeb0b3722650323 10145 
mlton_20180207-1_amd64.buildinfo
Files:
 d5fb429db065fa493e7a8256f25ddeb2 4351

Bug#890791: Proposed updates?

[Wesley W. Terpstra]

Good evening,

I was wondering where I can find the proposed-updates version of dpkg with
the riscv64 architecture line added to /usr/share/dpkg/cputable. I thought
I'd be able to find it on <
https://release.debian.org/proposed-updates/stable.html>, but it's not
listed, so I must be looking in the wrong place.

So far I've just being hand-editting this file on all my stable machines,
but I'd prefer to just update dpkg from proposed-updates. What am I doing
wrong?

Bug#890791: Proposed updates?

[Wesley W. Terpstra]

Good evening,

I was wondering where I can find the proposed-updates version of dpkg with
the riscv64 architecture line added to /usr/share/dpkg/cputable. I thought
I'd be able to find it on <
https://release.debian.org/proposed-updates/stable.html>, but it's not
listed, so I must be looking in the wrong place.

So far I've just being hand-editting this file on all my stable machines,
but I'd prefer to just update dpkg from proposed-updates. What am I doing
wrong?

[PATCH 3/3] pwm-sifive: add a driver for SiFive SoC PWM

[Wesley W. Terpstra]

SiFive SoCs can contain one or more PWM IP blocks.
This adds a driver for them. Tested on the HiFive Unleashed.

Signed-off-by: Wesley W. Terpstra <wes...@terpstra.ca>
---
 drivers/pwm/Kconfig  |  11 ++
 drivers/pwm/Makefile |   1 +
 drivers/pwm/pwm-sifive.c | 259 +++
 3 files changed, 271 insertions(+)
 create mode 100644 drivers/pwm/pwm-sifive.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 763ee50..49e9824 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -387,6 +387,17 @@ config PWM_SAMSUNG
  To compile this driver as a module, choose M here: the module
  will be called pwm-samsung.
 
+config PWM_SIFIVE
+   tristate "SiFive PWM support"
+   depends on OF
+   depends on COMMON_CLK
+   help
+ Generic PWM framework driver for SiFive SoCs, such as those
+  found on the HiFive Unleashed series boards.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-sifive.
+
 config PWM_SPEAR
tristate "STMicroelectronics SPEAr PWM support"
depends on PLAT_SPEAR
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0258a74..17c5eb9 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_RCAR)+= pwm-rcar.o
 obj-$(CONFIG_PWM_RENESAS_TPU)  += pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
 obj-$(CONFIG_PWM_SAMSUNG)  += pwm-samsung.o
+obj-$(CONFIG_PWM_SIFIVE)   += pwm-sifive.o
 obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
 obj-$(CONFIG_PWM_STI)  += pwm-sti.o
 obj-$(CONFIG_PWM_STM32)+= pwm-stm32.o
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
new file mode 100644
index 000..587d4d4
--- /dev/null
+++ b/drivers/pwm/pwm-sifive.c
@@ -0,0 +1,259 @@
+/*
+ * SiFive PWM driver
+ *
+ * Copyright (C) 2018 SiFive, Inc
+ *
+ * Author: Wesley W. Terpstra <wes...@sifive.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2, as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_PWM4
+
+/* Register offsets */
+#define REG_PWMCFG 0x0
+#define REG_PWMCOUNT   0x8
+#define REG_PWMS   0x10
+#defineREG_PWMCMP0 0x20
+
+/* PWMCFG fields */
+#define BIT_PWM_SCALE  0
+#define BIT_PWM_STICKY 8
+#define BIT_PWM_ZERO_ZMP   9
+#define BIT_PWM_DEGLITCH   10
+#define BIT_PWM_EN_ALWAYS  12
+#define BIT_PWM_EN_ONCE13
+#define BIT_PWM0_CENTER16
+#define BIT_PWM0_GANG  24
+#define BIT_PWM0_IP28
+
+#define SIZE_PWMCMP4
+#define MASK_PWM_SCALE 0xf
+
+struct sifive_pwm_device {
+   struct pwm_chip chip;
+   struct notifier_block   notifier;
+   struct clk  *clk;
+   void __iomem*regs;
+   int irq;
+   unsigned intapprox_period;
+   unsigned intreal_period;
+};
+
+static inline struct sifive_pwm_device *chip_to_sifive(struct pwm_chip *c)
+{
+   return container_of(c, struct sifive_pwm_device, chip);
+}
+
+static inline struct sifive_pwm_device *notifier_to_sifive(struct 
notifier_block *nb)
+{
+   return container_of(nb, struct sifive_pwm_device, notifier);
+}
+
+static int sifive_pwm_apply(struct pwm_chip *chip,
+   struct pwm_device *dev,
+   struct pwm_state *state)
+{
+   struct sifive_pwm_device *pwm = chip_to_sifive(chip);
+   unsigned int duty_cycle;
+   u32 frac;
+
+   duty_cycle = state->duty_cycle;
+   if (!state->enabled)
+   duty_cycle = 0;
+   if (state->polarity == PWM_POLARITY_NORMAL)
+   duty_cycle = state->period - duty_cycle;
+
+   frac = ((u64)duty_cycle << 16) / state->period;
+   frac = min(frac, 0xU);
+
+   iowrite32(frac, pwm->regs + REG_PWMCMP0 + (dev->hwpwm * SIZE_PWMCMP));
+
+   if (state->enabled) {
+   state->period = pwm->real_period;
+   state->duty_cycle = ((u64)frac * pwm->real_period) >> 16;
+   if (state->polarity == PWM_POLARITY_NORMAL)
+   state->duty_cycle = state->period - state->duty_cycle;
+   }
+
+   return 0;
+}
+
+static void sifive_pwm_get_state(struct pwm_chip *chip,
+struct pwm_device *dev,
+struct pwm_state *state)
+{
+   struct sifive_pwm_device *pwm = chip_to_sifive(chip);
+   unsigned long duty;
+
+   duty = ioread32(pwm->regs + REG_PWMCMP0 + (dev->hwpwm * SIZ

[PATCH 3/3] pwm-sifive: add a driver for SiFive SoC PWM

[Wesley W. Terpstra]

SiFive SoCs can contain one or more PWM IP blocks.
This adds a driver for them. Tested on the HiFive Unleashed.

Signed-off-by: Wesley W. Terpstra 
---
 drivers/pwm/Kconfig  |  11 ++
 drivers/pwm/Makefile |   1 +
 drivers/pwm/pwm-sifive.c | 259 +++
 3 files changed, 271 insertions(+)
 create mode 100644 drivers/pwm/pwm-sifive.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 763ee50..49e9824 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -387,6 +387,17 @@ config PWM_SAMSUNG
  To compile this driver as a module, choose M here: the module
  will be called pwm-samsung.
 
+config PWM_SIFIVE
+   tristate "SiFive PWM support"
+   depends on OF
+   depends on COMMON_CLK
+   help
+ Generic PWM framework driver for SiFive SoCs, such as those
+  found on the HiFive Unleashed series boards.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-sifive.
+
 config PWM_SPEAR
tristate "STMicroelectronics SPEAr PWM support"
depends on PLAT_SPEAR
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0258a74..17c5eb9 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_RCAR)+= pwm-rcar.o
 obj-$(CONFIG_PWM_RENESAS_TPU)  += pwm-renesas-tpu.o
 obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
 obj-$(CONFIG_PWM_SAMSUNG)  += pwm-samsung.o
+obj-$(CONFIG_PWM_SIFIVE)   += pwm-sifive.o
 obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
 obj-$(CONFIG_PWM_STI)  += pwm-sti.o
 obj-$(CONFIG_PWM_STM32)+= pwm-stm32.o
diff --git a/drivers/pwm/pwm-sifive.c b/drivers/pwm/pwm-sifive.c
new file mode 100644
index 000..587d4d4
--- /dev/null
+++ b/drivers/pwm/pwm-sifive.c
@@ -0,0 +1,259 @@
+/*
+ * SiFive PWM driver
+ *
+ * Copyright (C) 2018 SiFive, Inc
+ *
+ * Author: Wesley W. Terpstra 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2, as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_PWM4
+
+/* Register offsets */
+#define REG_PWMCFG 0x0
+#define REG_PWMCOUNT   0x8
+#define REG_PWMS   0x10
+#defineREG_PWMCMP0 0x20
+
+/* PWMCFG fields */
+#define BIT_PWM_SCALE  0
+#define BIT_PWM_STICKY 8
+#define BIT_PWM_ZERO_ZMP   9
+#define BIT_PWM_DEGLITCH   10
+#define BIT_PWM_EN_ALWAYS  12
+#define BIT_PWM_EN_ONCE13
+#define BIT_PWM0_CENTER16
+#define BIT_PWM0_GANG  24
+#define BIT_PWM0_IP28
+
+#define SIZE_PWMCMP4
+#define MASK_PWM_SCALE 0xf
+
+struct sifive_pwm_device {
+   struct pwm_chip chip;
+   struct notifier_block   notifier;
+   struct clk  *clk;
+   void __iomem*regs;
+   int irq;
+   unsigned intapprox_period;
+   unsigned intreal_period;
+};
+
+static inline struct sifive_pwm_device *chip_to_sifive(struct pwm_chip *c)
+{
+   return container_of(c, struct sifive_pwm_device, chip);
+}
+
+static inline struct sifive_pwm_device *notifier_to_sifive(struct 
notifier_block *nb)
+{
+   return container_of(nb, struct sifive_pwm_device, notifier);
+}
+
+static int sifive_pwm_apply(struct pwm_chip *chip,
+   struct pwm_device *dev,
+   struct pwm_state *state)
+{
+   struct sifive_pwm_device *pwm = chip_to_sifive(chip);
+   unsigned int duty_cycle;
+   u32 frac;
+
+   duty_cycle = state->duty_cycle;
+   if (!state->enabled)
+   duty_cycle = 0;
+   if (state->polarity == PWM_POLARITY_NORMAL)
+   duty_cycle = state->period - duty_cycle;
+
+   frac = ((u64)duty_cycle << 16) / state->period;
+   frac = min(frac, 0xU);
+
+   iowrite32(frac, pwm->regs + REG_PWMCMP0 + (dev->hwpwm * SIZE_PWMCMP));
+
+   if (state->enabled) {
+   state->period = pwm->real_period;
+   state->duty_cycle = ((u64)frac * pwm->real_period) >> 16;
+   if (state->polarity == PWM_POLARITY_NORMAL)
+   state->duty_cycle = state->period - state->duty_cycle;
+   }
+
+   return 0;
+}
+
+static void sifive_pwm_get_state(struct pwm_chip *chip,
+struct pwm_device *dev,
+struct pwm_state *state)
+{
+   struct sifive_pwm_device *pwm = chip_to_sifive(chip);
+   unsigned long duty;
+
+   duty = ioread32(pwm->regs + REG_PWMCMP0 + (dev->hwpwm * SIZE_PWMCMP));
+
+   state->period

[PATCH 0/3] SiFive SoC PWM driver

[Wesley W. Terpstra]

SiFive SoCs can contain one or more PWM IP blocks.
This adds a driver for them. Tested on the HiFive Unleashed.

This patch series is broken into three parts:
  The driver itself, in drivers/pwm
  The device tree binding description, in Documentation/devicetree/bindings
  The SiFive vendor prefix, in Documentation/devicetree/bindings

Wesley W. Terpstra (3):
  dt-bindings: added new pwm-sifive driver documentation
  dt-bindings: Add "sifive" vendor prefix
  pwm-sifive: add a driver for SiFive SoC PWM

 .../devicetree/bindings/pwm/pwm-sifive.txt |  28 +++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/pwm/Kconfig|  11 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-sifive.c   | 259 +
 5 files changed, 300 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
 create mode 100644 drivers/pwm/pwm-sifive.c

-- 
2.7.4

[PATCH 0/3] SiFive SoC PWM driver

[Wesley W. Terpstra]

SiFive SoCs can contain one or more PWM IP blocks.
This adds a driver for them. Tested on the HiFive Unleashed.

This patch series is broken into three parts:
  The driver itself, in drivers/pwm
  The device tree binding description, in Documentation/devicetree/bindings
  The SiFive vendor prefix, in Documentation/devicetree/bindings

Wesley W. Terpstra (3):
  dt-bindings: added new pwm-sifive driver documentation
  dt-bindings: Add "sifive" vendor prefix
  pwm-sifive: add a driver for SiFive SoC PWM

 .../devicetree/bindings/pwm/pwm-sifive.txt |  28 +++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/pwm/Kconfig|  11 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-sifive.c   | 259 +
 5 files changed, 300 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
 create mode 100644 drivers/pwm/pwm-sifive.c

-- 
2.7.4

[PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation

[Wesley W. Terpstra]

Document new PWM device tree bindings for SiFive SoCs.

Signed-off-by: Wesley W. Terpstra <wes...@sifive.com>
---
 .../devicetree/bindings/pwm/pwm-sifive.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt 
b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
new file mode 100644
index 000..7cea20d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
@@ -0,0 +1,28 @@
+SiFive PWM controller
+
+Unlike most other PWM controllers, the SiFive PWM controller currently only
+supports one period for all channels in the PWM. This is set globally in DTS.
+The period also has significant restrictions on the values it can achieve,
+which the driver rounds to the nearest achievable frequency.
+
+Required properties:
+- compatible: should be "sifive,pwm0"
+- reg: physical base address and length of the controller's registers
+- clocks: The frequency the controller runs at
+- #pwm-cells: Should be 2.
+  The first cell is the PWM channel number
+  The second cell is the PWM polarity
+- sifive,approx-period: the driver will get as close to this period as it can
+- interrupts: one interrupt per PWM channel (currently unused in the driver)
+
+Examples:
+
+pwm:  pwm@1002 {
+   compatible = "sifive,pwm0";
+   reg = <0x0 0x1002 0x0 0x1000>;
+   clocks = <>;
+   interrupt-parent = <>;
+   interrupts = <42 43 44 45>;
+   #pwm-cells = <2>;
+   sifive,approx-period = <100>;
+};
-- 
2.7.4

[PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation

[Wesley W. Terpstra]

Document new PWM device tree bindings for SiFive SoCs.

Signed-off-by: Wesley W. Terpstra 
---
 .../devicetree/bindings/pwm/pwm-sifive.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.txt 
b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
new file mode 100644
index 000..7cea20d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.txt
@@ -0,0 +1,28 @@
+SiFive PWM controller
+
+Unlike most other PWM controllers, the SiFive PWM controller currently only
+supports one period for all channels in the PWM. This is set globally in DTS.
+The period also has significant restrictions on the values it can achieve,
+which the driver rounds to the nearest achievable frequency.
+
+Required properties:
+- compatible: should be "sifive,pwm0"
+- reg: physical base address and length of the controller's registers
+- clocks: The frequency the controller runs at
+- #pwm-cells: Should be 2.
+  The first cell is the PWM channel number
+  The second cell is the PWM polarity
+- sifive,approx-period: the driver will get as close to this period as it can
+- interrupts: one interrupt per PWM channel (currently unused in the driver)
+
+Examples:
+
+pwm:  pwm@1002 {
+   compatible = "sifive,pwm0";
+   reg = <0x0 0x1002 0x0 0x1000>;
+   clocks = <>;
+   interrupt-parent = <>;
+   interrupts = <42 43 44 45>;
+   #pwm-cells = <2>;
+   sifive,approx-period = <100>;
+};
-- 
2.7.4

[PATCH 2/3] dt-bindings: Add "sifive" vendor prefix

[Wesley W. Terpstra]

This adds a vendor prefix "sifive" for SiFive, Inc.
We make chips.

Signed-off-by: Wesley W. Terpstra <wes...@sifive.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ae850d6..c98faf7 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -315,6 +315,7 @@ sgx SGX Sensortech
 sharp  Sharp Corporation
 shimafuji  Shimafuji Electric, Inc.
 si-en  Si-En Technology Ltd.
+sifive SiFive, Inc.
 sigma  Sigma Designs, Inc.
 siiSeiko Instruments, Inc.
 silSilicon Image
-- 
2.7.4

[PATCH 2/3] dt-bindings: Add "sifive" vendor prefix

[Wesley W. Terpstra]

This adds a vendor prefix "sifive" for SiFive, Inc.
We make chips.

Signed-off-by: Wesley W. Terpstra 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ae850d6..c98faf7 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -315,6 +315,7 @@ sgx SGX Sensortech
 sharp  Sharp Corporation
 shimafuji  Shimafuji Electric, Inc.
 si-en  Si-En Technology Ltd.
+sifive SiFive, Inc.
 sigma  Sigma Designs, Inc.
 siiSeiko Instruments, Inc.
 silSilicon Image
-- 
2.7.4

Bug#890791: Progress?

[Wesley W. Terpstra]

Has there been any progress on this issue?

I maintain a package with an explicit Architecture list and I wanted
to port it to my new riscv64 system, but I can't upload the new source
package to unstable because it mentions riscv64 in the control file.
It's quite frustrating that backporting this to dak is blocking
packages from adding support to source which could otherwise be
compiled by the debian-ports infrastructure...

Thanks for looking into this

Bug#890791: Progress?

[Wesley W. Terpstra]

Has there been any progress on this issue?

I maintain a package with an explicit Architecture list and I wanted
to port it to my new riscv64 system, but I can't upload the new source
package to unstable because it mentions riscv64 in the control file.
It's quite frustrating that backporting this to dak is blocking
packages from adding support to source which could otherwise be
compiled by the debian-ports infrastructure...

Thanks for looking into this

Bug#857220: mlton-tools: broken symlink: /usr/share/doc/mlton-tools/README -> doc/README

[Wesley W. Terpstra]

Thanks for the report.

I probably won't make a new upload to fix this issue alone, but will
be sure to fix it with the next upload.

Accepted mlton 20130715-3 (source) into unstable

[Wesley W. Terpstra]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 18 Dec 2016 22:48:17 +0100
Source: mlton
Binary: mlton mlton-basis mlton-doc mlton-compiler mlton-tools 
mlton-runtime-native mlton-runtime-alpha-linux-gnu 
mlton-runtime-x86-64-linux-gnu mlton-runtime-aarch64-linux-gnu 
mlton-runtime-arm-linux-gnueabi mlton-runtime-arm-linux-gnueabihf 
mlton-runtime-hppa-linux-gnu mlton-runtime-i486-linux-gnu 
mlton-runtime-i486-kfreebsd-gnu mlton-runtime-x86-64-kfreebsd-gnu 
mlton-runtime-mips64el-linux-gnuabi64 mlton-runtime-mips-linux-gnu 
mlton-runtime-mipsel-linux-gnu mlton-runtime-powerpc-linux-gnu 
mlton-runtime-powerpc64le-linux-gnu mlton-runtime-s390x-linux-gnu 
mlton-runtime-sparc-linux-gnu
Architecture: source
Version: 20130715-3
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra <terps...@debian.org>
Changed-By: Wesley W. Terpstra <terps...@debian.org>
Description:
 mlton  - Optimizing compiler for Standard ML
 mlton-basis - Optimizing compiler for Standard ML - basis library
 mlton-compiler - Optimizing compiler for Standard ML - compiler
 mlton-doc  - Optimizing compiler for Standard ML - documentation
 mlton-runtime-aarch64-linux-gnu - Optimizing compiler for Standard ML - arm64 
runtime libraries
 mlton-runtime-alpha-linux-gnu - Optimizing compiler for Standard ML - alpha 
runtime libraries
 mlton-runtime-arm-linux-gnueabi - Optimizing compiler for Standard ML - armel 
runtime libraries
 mlton-runtime-arm-linux-gnueabihf - Optimizing compiler for Standard ML - 
armhf runtime libraries
 mlton-runtime-hppa-linux-gnu - Optimizing compiler for Standard ML - hppa 
runtime libraries
 mlton-runtime-i486-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-i386 runtime libra
 mlton-runtime-i486-linux-gnu - Optimizing compiler for Standard ML - i386 
runtime libraries
 mlton-runtime-mips-linux-gnu - Optimizing compiler for Standard ML - mips 
runtime libraries
 mlton-runtime-mips64el-linux-gnuabi64 - Optimizing compiler for Standard ML - 
mips64el runtime libraries
 mlton-runtime-mipsel-linux-gnu - Optimizing compiler for Standard ML - mipsel 
runtime libraries
 mlton-runtime-native - Optimizing compiler for Standard ML - native runtime 
libraries
 mlton-runtime-powerpc-linux-gnu - Optimizing compiler for Standard ML - 
powerpc runtime libraries
 mlton-runtime-powerpc64le-linux-gnu - Optimizing compiler for Standard ML - 
ppc64el runtime libraries
 mlton-runtime-s390x-linux-gnu - Optimizing compiler for Standard ML - s390x 
runtime libraries
 mlton-runtime-sparc-linux-gnu - Optimizing compiler for Standard ML - sparc 
runtime libraries
 mlton-runtime-x86-64-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-amd64 runtime libr
 mlton-runtime-x86-64-linux-gnu - Optimizing compiler for Standard ML - amd64 
runtime libraries
 mlton-tools - Optimizing compiler for Standard ML - tools
Changes:
 mlton (20130715-3) unstable; urgency=low
 .
   * Build-depend only on mlton-compiler and mlton-tools
* Buildds got stuck by looking at the mlton all package
   * Remove heap-size hacks; debian buildds have >2GB RAM now
   * Source-only upload to ensure full rebuild
Checksums-Sha1:
 bb117ef6789ca47280b7d53bc3211f9b09113cc7 4202 mlton_20130715-3.dsc
 778b731cdcb1552b60adbe4b4aec191300b26f25 12292 mlton_20130715-3.debian.tar.xz
Checksums-Sha256:
 96ec200339f0d3240b8ecdbe48bf44c66308588def2d655985781a520c70e4b4 4202 
mlton_20130715-3.dsc
 edecc508ab0f3d6383d11c9cccb7e4494b9bfae5d31a2ca056cb898776be3676 12292 
mlton_20130715-3.debian.tar.xz
Files:
 dcad0c1188516a69c82d1f67f69ab187 4202 devel optional mlton_20130715-3.dsc
 3029a25f4377990757872851cc17e1b5 12292 devel optional 
mlton_20130715-3.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJYVxKOAAoJEOZHXQMKm/Fk2BEP+wY9Lj+Rfwg92uprtyA3+uJs
AWYHf2W9Rzk5BY+7iKvcNJWd3F11l6BlKTJYwW9jzZvjQ4edJLZWewz790Rgn722
oyzVKbHNMndQqgYhLMB2Df2rxjDsTrqxBxHm3ZBWjYK+ThUI2ByP8zDpOVzquvv2
Ar6jsx0YT/X+BZDgDnQPY6E9vc4kR8To0zD/FiAhgePyJ/VituqodOO5/iSk5Gh+
8sPP2FrFphxIS4eKT9U+0ogN2Ep4nGwpsoOED3o4gBKEQagczF6RlnyT5T7xFkv6
4+MF6QijsEcybXHpm9/fnigp9dJVjuwF0zUa4d2CNE3kj47HWApCbD4GvI2X4Q0n
BjZq7pq3Ze76fCXHY4iaSdrG1tFqFDhMNxZfsnLtgsdGkJXt0+FVAyoPSsbxgC2K
9eVlPGB3Q7v/qjLYTwFptretrcEOllSF6tvLjekBdzmcclITSUux5PQLppJPVbPe
e4uWeUDtDShFoNSPsJ5Tx9fgI+IEWzh4J/oWahqSN9ig8SQTe7Ws+zE/Dk/t8LET
BVxT/h3RNDXVB7/YpOYREQQf1qLRVHc+CYfdARmOB7yVB1U4yZn96301PfP6h/xd
CmHpWsMMvDnN5hjNGDdppHADVLB0a2mHoLxVaEJhGBLsLOPJX4QXi4OCkj0WOPx9
fySchhtDJWk/5Q3Ox9Hd
=lbYO
-END PGP SIGNATURE-

Accepted mlton 20130715-2 (source all kfreebsd-amd64) into unstable, unstable

[Wesley W. Terpstra]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 17 Dec 2016 03:39:49 +0100
Source: mlton
Binary: mlton mlton-basis mlton-doc mlton-compiler mlton-tools 
mlton-runtime-native mlton-runtime-alpha-linux-gnu 
mlton-runtime-x86-64-linux-gnu mlton-runtime-aarch64-linux-gnu 
mlton-runtime-arm-linux-gnueabi mlton-runtime-arm-linux-gnueabihf 
mlton-runtime-hppa-linux-gnu mlton-runtime-i486-linux-gnu 
mlton-runtime-i486-kfreebsd-gnu mlton-runtime-x86-64-kfreebsd-gnu 
mlton-runtime-mips64el-linux-gnuabi64 mlton-runtime-mips-linux-gnu 
mlton-runtime-mipsel-linux-gnu mlton-runtime-powerpc-linux-gnu 
mlton-runtime-powerpc64le-linux-gnu mlton-runtime-s390x-linux-gnu 
mlton-runtime-sparc-linux-gnu
Architecture: source all kfreebsd-amd64
Version: 20130715-2
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra <terps...@debian.org>
Changed-By: Wesley W. Terpstra <terps...@debian.org>
Description:
 mlton  - Optimizing compiler for Standard ML
 mlton-basis - Optimizing compiler for Standard ML - basis library
 mlton-compiler - Optimizing compiler for Standard ML - compiler
 mlton-doc  - Optimizing compiler for Standard ML - documentation
 mlton-runtime-aarch64-linux-gnu - Optimizing compiler for Standard ML - arm64 
runtime libraries
 mlton-runtime-alpha-linux-gnu - Optimizing compiler for Standard ML - alpha 
runtime libraries
 mlton-runtime-arm-linux-gnueabi - Optimizing compiler for Standard ML - armel 
runtime libraries
 mlton-runtime-arm-linux-gnueabihf - Optimizing compiler for Standard ML - 
armhf runtime libraries
 mlton-runtime-hppa-linux-gnu - Optimizing compiler for Standard ML - hppa 
runtime libraries
 mlton-runtime-i486-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-i386 runtime libra
 mlton-runtime-i486-linux-gnu - Optimizing compiler for Standard ML - i386 
runtime libraries
 mlton-runtime-mips-linux-gnu - Optimizing compiler for Standard ML - mips 
runtime libraries
 mlton-runtime-mips64el-linux-gnuabi64 - Optimizing compiler for Standard ML - 
mips64el runtime libraries
 mlton-runtime-mipsel-linux-gnu - Optimizing compiler for Standard ML - mipsel 
runtime libraries
 mlton-runtime-native - Optimizing compiler for Standard ML - native runtime 
libraries
 mlton-runtime-powerpc-linux-gnu - Optimizing compiler for Standard ML - 
powerpc runtime libraries
 mlton-runtime-powerpc64le-linux-gnu - Optimizing compiler for Standard ML - 
ppc64el runtime libraries
 mlton-runtime-s390x-linux-gnu - Optimizing compiler for Standard ML - s390x 
runtime libraries
 mlton-runtime-sparc-linux-gnu - Optimizing compiler for Standard ML - sparc 
runtime libraries
 mlton-runtime-x86-64-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-amd64 runtime libr
 mlton-runtime-x86-64-linux-gnu - Optimizing compiler for Standard ML - amd64 
runtime libraries
 mlton-tools - Optimizing compiler for Standard ML - tools
Closes: 791936
Changes:
 mlton (20130715-2) unstable; urgency=low
 .
   * Remove policy-problematic smlnj HTML4 from the package
   * Remove ports for hurd-i386 (unreliable) and ia64 (dead)
   * Add arm64 port (use supplied patch; closes: #791936)
   * Add mips64el port (needed a complete arch patch)
   * Add ppc64el port (needs bin/platform patch)
   * Track s390 port name change to s390x
   * Fix kfreebsd ports (removed getpgrp work-around)
   * Added build dependency on librsvg2-bin
Checksums-Sha1:
 f1787a0a25a2e37ab075413cbf03f99bbd3382c6 4194 mlton_20130715-2.dsc
 5359dcc5cb344117bb6d08c7e6bb0b47d7fe6e3f 12984 mlton_20130715-2.debian.tar.xz
 b26b19dbe472fda1a006730641ba2c8b4c2d2cd9 1535542 mlton-basis_20130715-2_all.deb
 65d9e652539857458f92f63ae0e585f3c5debce5 2745980 
mlton-compiler_20130715-2_kfreebsd-amd64.deb
 1f53d63d8f0115ea31884f9b5cb0358513928af1 10358618 mlton-doc_20130715-2_all.deb
 33d6ca50ecdafe1a37f930ebca5db495fd5357e4 41002 
mlton-runtime-native_20130715-2_kfreebsd-amd64.deb
 a397a0319ba75fa3055183341b5d6cdc34d50e88 242458 
mlton-runtime-x86-64-kfreebsd-gnu_20130715-2_kfreebsd-amd64.deb
 fa61168285674b06fe721481f896e2cc7547b835 1140198 
mlton-tools_20130715-2_kfreebsd-amd64.deb
 4a8683547dba11c186cc06faae05daa582b63ac9 41782 mlton_20130715-2_all.deb
 1de70a10484d48de58a5a2d32c4a1fab314f05de 13113 
mlton_20130715-2_kfreebsd-amd64.buildinfo
Checksums-Sha256:
 843831dcbe1534f4f6242614bb6c514f30d9b37796567943dd1b7d840d612899 4194 
mlton_20130715-2.dsc
 00db216526a12a9d2611362780cfb910c14c47303ce42dbcc9467425068bf482 12984 
mlton_20130715-2.debian.tar.xz
 8af93b966c979f3ef5553f9c1c7eba1fa3e3ddfd19641ba82e947cf42fd540e2 1535542 
mlton-basis_20130715-2_all.deb
 b0014253a04732c0fb1dd447735a090efda355c4827ee9efe415835300083d4f 2745980 
mlton-compiler_20130715-2_kfreebsd-amd64.deb
 d108d0f86bb20e06f4175665614bcd230decc49777a446738676e9c8e1ac100b 10358618 
mlton-doc_20130715-2_all.deb
 25ccacc073eab0be1268390f129d7341d15c37a3468491cdab8efb621885efa5 41002 
mlton-runtime-native_20130715-2_kfreeb

Accepted mlton 20130715-1 (source all amd64) into unstable

[Wesley W. Terpstra]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 9 Dec 2016 12:11:32 +0200
Source: mlton
Binary: mlton mlton-basis mlton-doc mlton-compiler mlton-tools 
mlton-runtime-native mlton-runtime-alpha-linux-gnu 
mlton-runtime-x86-64-linux-gnu mlton-runtime-arm-linux-gnueabi 
mlton-runtime-arm-linux-gnueabihf mlton-runtime-hppa-linux-gnu 
mlton-runtime-i486-gnu mlton-runtime-i486-linux-gnu 
mlton-runtime-ia64-linux-gnu mlton-runtime-i486-kfreebsd-gnu 
mlton-runtime-x86-64-kfreebsd-gnu mlton-runtime-mips-linux-gnu 
mlton-runtime-mipsel-linux-gnu mlton-runtime-powerpc-linux-gnu 
mlton-runtime-s390-linux-gnu mlton-runtime-sparc-linux-gnu
Architecture: source all amd64
Version: 20130715-1
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra <terps...@debian.org>
Changed-By: Wesley W. Terpstra <terps...@debian.org>
Description:
 mlton  - Optimizing compiler for Standard ML
 mlton-basis - Optimizing compiler for Standard ML - basis library
 mlton-compiler - Optimizing compiler for Standard ML - compiler
 mlton-doc  - Optimizing compiler for Standard ML - documentation
 mlton-runtime-alpha-linux-gnu - Optimizing compiler for Standard ML - alpha 
runtime libraries
 mlton-runtime-arm-linux-gnueabi - Optimizing compiler for Standard ML - armel 
runtime libraries
 mlton-runtime-arm-linux-gnueabihf - Optimizing compiler for Standard ML - 
armhf runtime libraries
 mlton-runtime-hppa-linux-gnu - Optimizing compiler for Standard ML - hppa 
runtime libraries
 mlton-runtime-i486-gnu - Optimizing compiler for Standard ML - hurd-i386 
runtime libraries
 mlton-runtime-i486-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-i386 runtime libra
 mlton-runtime-i486-linux-gnu - Optimizing compiler for Standard ML - i386 
runtime libraries
 mlton-runtime-ia64-linux-gnu - Optimizing compiler for Standard ML - ia64 
runtime libraries
 mlton-runtime-mips-linux-gnu - Optimizing compiler for Standard ML - mips 
runtime libraries
 mlton-runtime-mipsel-linux-gnu - Optimizing compiler for Standard ML - mipsel 
runtime libraries
 mlton-runtime-native - Optimizing compiler for Standard ML - native runtime 
libraries
 mlton-runtime-powerpc-linux-gnu - Optimizing compiler for Standard ML - 
powerpc runtime libraries
 mlton-runtime-s390-linux-gnu - Optimizing compiler for Standard ML - s390 
runtime libraries
 mlton-runtime-sparc-linux-gnu - Optimizing compiler for Standard ML - sparc 
runtime libraries
 mlton-runtime-x86-64-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-amd64 runtime libr
 mlton-runtime-x86-64-linux-gnu - Optimizing compiler for Standard ML - amd64 
runtime libraries
 mlton-tools - Optimizing compiler for Standard ML - tools
Closes: 762143 837567
Changes:
 mlton (20130715-1) unstable; urgency=low
 .
   * New upstream release (closes: #762143)
   * Always build PIC on Linux (closes: #837567)
   * Bump debhelper compat to 9 (disable empty dbgsym packages)
   * Bump standards version to 3.9.8 (use DEB_HOST_MULTIARCH)
   * Replace README link with contents to help dh_installdocs
Checksums-Sha1:
 0aa8b2d3b9e8e73d8acda6e5cb36b94efdb86fc3 3999 mlton_20130715-1.dsc
 7aaf3614a290776d354a18992f766e0e316bbb84 25606142 mlton_20130715.orig.tar.gz
 5d49ea6a48d850a29591613bb326cad0c358a5a0 11568 mlton_20130715-1.debian.tar.xz
 d0edbc34d3f9f238f58cc58aaec0036375249e73 1535900 mlton-basis_20130715-1_all.deb
 03c5eefc9ecf3d69eef0c076d5cc15357811f772 2864750 
mlton-compiler_20130715-1_amd64.deb
 9238595f45067d40971a93a51bc5b078353fbed0 10391240 mlton-doc_20130715-1_all.deb
 67e21e8a152daf9320493e0717adff00ccb422cb 40814 
mlton-runtime-native_20130715-1_amd64.deb
 57c18772857535c6a86ef2b77fed8c837a1f4e95 228682 
mlton-runtime-x86-64-linux-gnu_20130715-1_amd64.deb
 e6d5382d9c8e082fa61306a04856c5c9b3a09806 1158432 
mlton-tools_20130715-1_amd64.deb
 e639057f57130dd710a02f4a6120eb4ae506dfac 41588 mlton_20130715-1_all.deb
 3f75ec2e87e4f0f3878845e9fd5086c6755413ef 12098 mlton_20130715-1_amd64.buildinfo
Checksums-Sha256:
 39edcda64f6bd66991a19285b1150e4c1b29e6eb6332e54eaeb2a7a227baed6b 3999 
mlton_20130715-1.dsc
 215857ad11d44f8d94c27f75e74017aa44b2c9703304bcec9e38c20433143d6c 25606142 
mlton_20130715.orig.tar.gz
 858bebc73e79b33f700b84a7e35cb107e03b272adddfb95cba5515ba829e196c 11568 
mlton_20130715-1.debian.tar.xz
 86a4e63cf0c222af5be2f16d82fe1a98fc6ad3735fe77861ad9bd0a54b75edc3 1535900 
mlton-basis_20130715-1_all.deb
 e47022dc529bcca2218ed1c31bd08349ce926709834527a95cf81b340f908ca5 2864750 
mlton-compiler_20130715-1_amd64.deb
 04ac4c0eddccbb1c3e3affe2eb7ed791d237acfef90a15ea2b06a7856d16d14a 10391240 
mlton-doc_20130715-1_all.deb
 2938c1a9329d1d5a6d469aac30df5e93a5ff61936be6dbf95898170843d678b3 40814 
mlton-runtime-native_20130715-1_amd64.deb
 101c4f94c9213d1f6f44ee3af77c26c68d2a6c01adaa2365177e35b808788c65 228682 
mlton-runtime-x86-64-linux-gnu_20130715-1_amd64.deb
 053e1c5038ec3b070a34ffee9d764941089c9a928932ef4306d89997ab9705e0 1158432 
mlton-tools_20130715

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

[Wesley W. Terpstra]

On Mon, Apr 4, 2016 at 8:42 PM, Alexander Duyck
 wrote:
> It is always possible that the SFP+ cages on the device may not dissipate
> enough heat for a given SFP+ module

If an SFP is capable of melting itself or other devices, that is the
fault of the SFP, not Intel's card, and not my unlocking of said card.
FYI, I have never seen such an SFP, and we use lots of different
models at my day job.

> when the device is under heavy use.

There is no "heavy use" for 10GBase.
You constantly transmit comma codes for clock recovery or the link goes dead.

> Odds are the card does have a fuse on it so it probably would just
> brick the card.  Still, intentionally circumventing the white list in
> the EEPROM puts you at a greater risk than just "bricking the card"
> there is always the potential for more catastrophic issues such as the
> risk of actually starting a fire.

While I agree there is a non-zero risk, it's EXTREMELY unlikely.

> I've seen things such as someone
> overclocking a graphics card and literally burning the network card in
> the slot next to it.

Overclocking a graphics card can increase power consumption a lot! You
are talking about parts that draw 200W during normal operation, and
god knows how much when they overclocked it. An SFP+ that draws 5W
would already be on the high end. There is no fire risk from 5W in a
housing that size, with thermal contact to the copper layers of the
card. The surface area is plenty.

> It is those kind of liability issues that lead to things like
> this white-list that Intel implemented in their EEPROM in the first
> place.

I don't believe that for a second.

If that were the case, then the low-margin bargain 10GBase cards would
be the ones implementing the SFP+ white lists.  However, the cheap
cards allow all SFP+s. Why? Because the legal jeopardy is so low that
even with their low margin, they don't care. It's no coincidence that
the two major bad actors (Intel and Cisco) also sell SFP+s.

> My concern wouldn't be so much about bricking the card as voiding the
> warranty for the entire system.  You should probably stress that this
> is "at your own risk" ... You might also want to throw a license on the code 
> in the
> git repo so that you make it expressly clear you are not liable for
> any possible damages caused by the use of your code.  Probably
> something like a BSD license would suffice.

Yes, I should put a licence on it. So I suppose there will be an "at
your own risk" from that. However, I live in Germany. If you help
someone and do not charge anything for it, you can not be held liable
here. It's the "good samaritan law".

> ... the risks could extend beyond just the card
> itself as there is always potential for damage to other components in
> the system.

I suppose it doesn't hurt to say this, but I don't agree that there is
any real risk.

PS. Alex, sorry for sending this to you twice.

--
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

[Wesley W. Terpstra]

On Mon, Apr 4, 2016 at 7:28 PM, Alexander Duyck
 wrote:
>> DO NOT FOLLOW THIS GUIDE UNLESS YOU DON'T FEAR BRICKING YOUR CARD!
>
> Actually possible repercussions are far worse than bricking your card.
> You could potentially burn up the entire system if you mess with an
> EEPROM and you don't know what you are doing.

I disagree.

To even read the I2C EEPROM from the SFP+, which is how the card
rejects the SFP+, it must power it. If the SFP+ is electrically
broken, it will be a hazard regardless of whether or not it passes the
qualification check.

Furthermore, any responsibly developed board includes a fuse to
prevent overcurrent with plug-in modules. I do not have the card in
front of me, but I expect such an expensive card would include this
sort of basic safety precaution.

--
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

[Wesley W. Terpstra]

On Mon, Apr 4, 2016 at 7:09 AM, Oleg A. Arkhangelsky  wrote:
> Sourceforge eat mail attachments. Put your program somewhere else.

Ok. Thanks for pointing this out!

I've put a slightly improved version up at:


--
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

[Wesley W. Terpstra]

Sorry for the earlier message! My hand hit the send button before I'd
finished writing the email.

I had a bit more time this weekend, and I managed to unlock my
X710-DA4. It now accepts any SFP+. I tried four different models of
10GBASE-LR transceivers in the card, and they all seemed to work just
fine. Admittedly, I only tested that they could hit 1.1GiB/s TCP flows
for a few minutes before picking one transceiver type and sticking
with it. In particular, I had some A7EL-LND3-ADMA transceivers lying
around that I found for 10EUR a piece and I am now using these
reliably the whole day. In summary, FUD aside, the X710-DA4 works
great with most SFP+s and the decision to lock this card down seems
more like it has something to do with monopolistic practices than
anything else. If I run into any problems with the cheaper SFP+s I
will follow-up with a reply to the list.

The XL710 has four records in NVM that describe whether or not the
card should reject an unknown SFP+. When you flip these four bits, it
will accept any SFP+. I have tested Linux only, but the driver works
unmodified with an unlocked card. Todd Fujinaka mentioned that Intel
sells an unlocked optics card, so I imagine the drivers were tested
against those cards which is why it works under linux. Therefore, I'd
wager the windows driver likewise works with an unlocked card, though
I have not tested it.

Be warned: running nvmupdate64e -rd will restore the lock bits! Normal
update appears to preserve their value.

To unlock your card, you will need linux 4.5, nvmupdate64e v1.26.17.09
, skill with Cl, and some time. I have not prepared a general-purpose
unlocking tool, because the NVM format might differ between cards and
thus this procedure should only be undertaken by someone who knows
what they are doing.

DO NOT FOLLOW THIS GUIDE UNLESS YOU DON'T FEAR BRICKING YOUR CARD!

Step one is to find the "PHY Capability LAN 0" structure in the NVM.
The NVM image that nvmupdate64e v1.26.17.09 writes seems to have a
corrupt "PHY Capability LAN 0 Pointer", so you will need to find the
record by hand. Use the attached my-tool.c to read the NVM. You will
need to set devid to the PCI express device ID for your card. lspci -n on
my machine showed:

01:00.0 0200: 8086:1572 (rev 01)
01:00.1 0200: 8086:1572 (rev 01)
01:00.2 0200: 8086:1572 (rev 01)
01:00.3 0200: 8086:1572 (rev 01)
... and thus I set devid to 0x1572.

You also need to set ifr.ifr_name to one of the corresponding ethernet
names. In my machine the card was eth2, eth3, eth4, eth5. I imagine
other models might have less devices and the numbers assigned depend
on what other cards udev has seen in your system. It does not matter
which card you pick, as long as it matches the devid you picked
earlier.

Once mytool works, run ./mytool 0x6870 0xc as root and see if it has a
similar record to mine.
My "PHY Capability LAN 0" record looked like this:
6870 + 00 => 000b
6870 + 01 => 0022 = external SFP+
6870 + 02 => 0083 = int: SFI, 1000BASE-KX, SGMII (???)
6870 + 03 => 1871 = ext: 0x70 = 10GBASE-{SFP+,LR,SR} 0x1801=crap?
6870 + 04 => 
6870 + 05 => 
6870 + 06 => 3303 = SFP+ copper (passive, active), 10GBase-{SR,LR}, SFP
6870 + 07 => 000b
 6870 + 08 => 2b0c
*** This is the important register ***
(0xb=bits 3+1+0 = enable qualification (3), pause TX+RX capable (1+0),
 0xc = 3+2 = 10GbE + 1GbE)
6870 + 09 => 0a00
6870 + 0a => 0a1e = default LESM values
6870 + 0b => 0003

I had 3 more records just like this at offsets 0x687c, 0x6888, and
0x6894. The key field is at offset 0x08 (PHY Capabilities Misc0). You
need to clear bit 11. In my case that meant writing 0x230c.

If your record is not at this location, run mytool 0 0x8000 >
somefile, and start looking for 4 occurrences of "000b" that are
separated by 0xc addresses and repeat four times. This is how I found
my records, since the NVM image from Intel does not have pointers to
the correct location.

Once you've found the first record's offset, update mypoke.c with the
correct offset. Then calculate the correct value for the Misc0
register by subtracting bit 11 and modify the line
"*(uint16_t*)(eeprom+1) = 0x230c;". Then, compile and run mypoke.
Finally, confirm with mytool that your new Misc0 register was
correctly written. If anything goes wrong, run nvmupdate64e -rd BEFORE
you reboot! This will blow away any changes you made by mistake.

If everything looks good, run nvmupdate64e -u just to make sure the
device is in a valid state. Then, power cycle your machine, insert the
SFP+ of your choice, and enjoy your unlocked card.

If this works for you, please let me know. If this proves useful to
enough people, perhaps we can put together a more user-friendly
unlocking procedure. As I said, without seeing a few more cards, I
would not want to automate this.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications 

[E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

[Wesley W. Terpstra]

I had a bit more time this weekend, and I managed to unlock my
X710-DA4. It now accepts any SFP+. I tried four different models of
10GBASE-LR transceivers in the card, and they all seemed to work just
fine. Admittedly, I only tested that they could hit 1.1GiB/s TCP flows
for a few minutes before picking one transceiver type and sticking
with it. In particular, I had some A7EL-LND3-ADMA transceivers lying
around that I found for 10EUR a piece and I am now using these
reliably the whole day. In summary, FUD aside, the X710-DA4 works
great with most SFP+s and the decision to lock this card down seems
more like it has something to do with monopolistic practices than
anything else. If I run into any problems with the cheaper SFP+s I
will follow-up with a reply to the list.

The XL710 has four records in NVM that describe whether or not the
card should reject an unknown SFP+. When you flip these four bits, it
will accept any SFP+. I have tested Linux only, but the driver works
unmodified with an unlocked card. Todd Fujinaka mentioned that Intel
sells an unlocked optics card, so I imagine the drivers were tested
against those cards which is why it works under linux. Therefore, I'd
wager the windows driver likewise works with an unlocked card, though
I have not tested it.

Be warned: running nvmupdate64e -rd will restore the lock bits! Normal
update appears to preserve their value.

To unlock your card, you will need linux 4.5, skill with Cl, and some
time. I have not prepared a general-purpose unlocking tool, because
the NVM format might differ between cards and thus this procedure
should only be undertaken by someone who knows what they are doing.

Step one is to find the "PHY Capability LAN 0" structure in the NVM.
The NVM image that nvmupdate64e v1.26.17.09 writes seems to have a
corrupt "PHY Capability LAN 0 Pointer", so you will need to find the
record by hand. Use the attached my-tool.c to read the NVM. You will
need to set devid to the PCI express device ID for your card. lspci on
my machine showed:

My "PHY Capability LAN 0" record looked like this:

6870 + 00 => 000b
6870 + 01 => 0022 = external SFP+
6870 + 02 => 0083 = int: SFI, 1000BASE-KX, SGMII (???)
6870 + 03 => 1871 = ext: 0x70 = 10GBASE-{SFP+,LR,SR} 0x1801=crap?
6870 + 04 => 
6870 + 05 => 
6870 + 06 => 3303 = SFP+ copper (passive, active), 10GBase-{SR,LR}, SFP
6870 + 07 => 000b
6870 + 08 => 2b0c
*** The important register ***
(0xb=bits 3+1+0 = enable qualification (3), pause TX+RX capable (1+0),
0xc = 3+2 = 10GbE + 1GbE)
6870 + 09 => 0a00
6870 + 0a => 0a1e = default LESM values
6870 + 0b => 0003

I had 3 more records just like this at offsets 0x687c, 0x6888, and
0x6894. The key field is at offset 0x08 (PHY Capabilities Misc0). You
need to clear bit 11. In my case that meant writing 0x230c.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] i40e: source for nvmupdate64e? (to clear module qualification)

[Wesley W. Terpstra]

Thank you for your feedback,

> Also be aware that a large chunk of the NVM image is signed and won't
> work  if the signature and/or checksum is found invalid.  I don't remember
> if the Qualified Module bits are in the signed portion, but I suspect they 
> are.

The data sheet (Section 6) says that they are not.
Table 6-2 lists "EMP SR Settings" as Auth=No.

Furthermore, there is good reason to believe they *cannot* be signed.
The fields listed in Section 6.3.23 all say "Note: This field is
preserved by the Intel NVM update tool." Therefore, either the update
tool would need the private key to sign whatever it finds (rendering
the exercise in security futile), or it would need to have a signed
version for all combinations of these fields, or those fields are
unsigned (by far the most likely).

So, I just need to find the fields, update them, and not break the
CRC. The data sheet lists the CRC8 polynomial used, so that's not a
problem.

I am still interested in finding a more up-to-date data sheet, the
source code to nvmupdate64e, and/or more documentation regarding how
the module pointers interact with the module index used in the i40e
driver.

> Keep in mind that the qualified module table is to help us know that the
> device will actually work with the optics being used.  We've had to debug
> some strange things that came down to mis-behaving connectors.

Drifting off topic now, but here we go:

As a developer, I feel your pain.
Users are the worst.
Anything to head off lengthy support.

As a network admin, I wonder why you aren't validating the fibre optic
cables, as I have had more problems with bad fibre, especially when
installed by people who are more familiar with copper. At my day job,
we tested several SFPs from four reputable manufacturers at various
temperatures and with different rad-hard cables. In the end, all of
the SFPs, from the most expensive to the quite inexpensive, worked
equally well. The quality of the fibre mattered far more.

As a consumer, I am frustrated that a card I bought to support the
SFP+ standard instead only supports 10GBASE-LR or 10GBASE-T or
whatever else Intel is willing to sell me. The whole point of a
standard is that I can use any component that conforms to the
standard. There are plenty of very qualified manufacturers of optical
transceivers. Most of them are not Intel.

Furthermore, while motherboard vendors list qualified RAM modules,
they don't fail to boot if you install an unqualified module. They
don't even give a warning! If the combination of RAM/SFP and
motherboard/card do not work, that's my fault for not sticking to the
qualified module list. Fine. The only thing a module white-list
achieves is to guarantee that most combinations of SFP/card will fail
to work. Meanwhile, my lab experience has shown that in reality, most
combinations DO work.

At my day job, we also build (FPGA-based) optical network cards used
as timing receivers. These boards store an SFP database in an EEPROM.
We need that database to quantify the delay in picoseconds through the
PHY. If someone inserts a PHY we didn't list, we don't reject the
module. We issue a warning and take a default delay value, resulting
in a slightly desynchronized (but still syntonized) clock. IMNSHO,
this is the only correct way to deal with the situation.

> I suggest you get in contact with your dealer or Intel Networking
> support and see if they can help you out with your specific optics.

I bought the Intel X710-DA4 in question second-hand, for private use.
I already own a collection of SFPs. I *will* get the X710 to accept
them by poking its NVM. It just might take me a few more weekends than
I'd expected. Any help/documentation is appreciated.

Thanks!

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] i40e: source for nvmupdate64e? (to clear module qualification)

[Wesley W. Terpstra]

 + 0b => 

So, my quest to locate the all-important PHY Capabilities Misc0 register
(Section 6.3.23.9 of the data sheet) has thus far failed.

I have a suspicion that part of my problem is that I'm looking in the wrong
"module". The data sheet describes that there are different modules, and
mytool also supports reading from them, but it's unclear to me how the
module pointers relate to the different modules. The data sheet I have does
not discuss this.

Does someone have a more up-to-date data sheet and/or knowledge of how the
module pointers and NVM address and module relate? And/or the source code
to nvmupdate64e which certainly is doing this correctly?

Thanks for any and all feedback.

PS. It seems mind boggling that Intel has intentionally locked their cards
to specific SFPs. The whole point of using SFPs is so that you can mix and
match different PHY types as you need them!

On Sat, Mar 19, 2016 at 12:25 AM, Wesley W. Terpstra <wes...@terpstra.ca>
wrote:

> Hi! I have an Intel X710-DA4 and want to use it with a few different SFPs.
> Unfortunately, out-of-the-box this seems to be disabled.
>
> From poking around, it seems that the x710 firmware rejects SFPs not
> listed in the NVM qualified database whenever the "Enable Module
> Qualification" bit is set (see Section 6.3.23.9 in the Intel Ethernet
> Controller XL710 Datasheet). From what I've read in the data sheet and i40e
> linux driver, it seems I just need to set this bit to 0 and I should be
> good to go.
>
> I am looking for the source code for nvmupdate64e, as this userspace tool
> seems to use the ethtools_ops.set_eeprom syscall to write the NVM, which is
> what I'd like to do. Where can I find the source-code for this? The
> i40e_type.h header in the linux driver is pretty undocumented in the
> correct use of i40e_nvmupd_cmd. I don't want to screw up the CRC, so would
> prefer to simply modify the existing NVM update tool.
>
> Anyone know where the source code is?
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

[E1000-devel] i40e: source for nvmupdate64e? (to clear module qualification)

[Wesley W. Terpstra]

Hi! I have an Intel X710-DA4 and want to use it with a few different SFPs.
Unfortunately, out-of-the-box this seems to be disabled.

>From poking around, it seems that the x710 firmware rejects SFPs not listed
in the NVM qualified database whenever the "Enable Module Qualification"
bit is set (see Section 6.3.23.9 in the Intel Ethernet Controller XL710
Datasheet). From what I've read in the data sheet and i40e linux driver, it
seems I just need to set this bit to 0 and I should be good to go.

I am looking for the source code for nvmupdate64e, as this userspace tool
seems to use the ethtools_ops.set_eeprom syscall to write the NVM, which is
what I'd like to do. Where can I find the source-code for this? The
i40e_type.h header in the linux driver is pretty undocumented in the
correct use of i40e_nvmupd_cmd. I don't want to screw up the CRC, so would
prefer to simply modify the existing NVM update tool.

Anyone know where the source code is?
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Bug#791928: Please support ARM64 (#error Unknown CPU architecture)

[Wesley W. Terpstra]

Porting mlton is easy. I ported it to most of the debian archs already. All
i need is a debian porterbox and buildd when i prepare a new upload.
On Jul 9, 2015 6:00 PM, Martin Michlmayr t...@hp.com wrote:

 Package: st
 Version: 1.9-3.1
 Severity: wishlist
 User: debian-...@lists.debian.org
 Usertags: arm64 port

 This package fails to build on arm64, but a quick looks suggests
 this package might be useful on arm64.  Do you know if upstream or
 someone else is working on arm64 support (aarch64) already?  (Looks
 like upstream is pretty dead; last release in 2009?)

  sbuild (Debian sbuild) 0.64.1 (13 Oct 2013) on
 m400-c5n1.hlinux.usa.hp.com
 ...
  if [ ! -d LINUX_3.13.0-55-generic_OPT ]; then mkdir
 LINUX_3.13.0-55-generic_OPT; fi
  gcc  -DLINUX -Wall -O -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall -D_FORTIFY_SOURCE=2 -c sched.c -o
 LINUX_3.13.0-55-generic_OPT/sched.o
  In file included from common.h:68:0,
   from sched.c:48:
  md.h:453:2: error: #error Unknown CPU architecture
   #error Unknown CPU architecture
^
  sched.c: In function '_st_vp_check_clock':
  sched.c:470:14: warning: variable 'elapsed' set but not used
 [-Wunused-but-set-variable]
 st_utime_t elapsed, now;
^
  sched.c: In function 'st_thread_create':
  sched.c:578:2: error: #error Unknown OS
   #error Unknown OS
^

 --
 Martin Michlmayr
 Linux for HP Helion, Hewlett-Packard

Re: [rust-dev] Newcomer to Rust: my experience

[Wesley W. Terpstra]

Yes, I discovered this, thanks.
I signed up for http://internals.rust-lang.org/c/documentation and
posted it there.

On Mon, Apr 6, 2015 at 3:34 PM, Oleg Eterevsky o...@eterevsky.com wrote:
 Hi Wesley!

 That's a very cool analysis. This sounds very much like my thoughts about
 the tutorial.

 I think you'd better post it on http://users.rust-lang.org/, since it is the
 main place for Rust discussions now. The mailing list is almost dead.

 --
 Oleg

 On Mon, Apr 6, 2015 at 4:23 PM Wesley W. Terpstra wes...@terpstra.ca
 wrote:

 Good afternoon and happy easter,

 I am a newcomer to Rust and recently finished working through your
 tutorial. Before I get too much further into reading the standard
 library, I wanted to share my experience as a complete Rust newbie
 starting out only with your documentation, before I forget it. I
 regret that I did not start taking notes immediately, but it was not
 yet clear to me how much I was going to like Rust, so a lot of this
 will be me recalling my experience, without notes.

 First, my background. I've been programming in C++ for 20 years and
 used MLton (Standard ML) heavily for about 5 years, 4 years ago. I
 have dabbled with Haskell, but not seriously. So, as far as beginners
 to Rust go, I suspect I would be the sort of person who should
 definitely have been able to go through your tutorial and come out at
 the other end with a clear mental model of the language, as I've been
 exposed to almost all of the concepts before.

 1- I had heard about Rust through the odd talk at ML workshops via
 youtube, although the last ML workshop I attended in person was ~6
 years ago. The main thing that raised Rust to my attention was your
 v1.0 release which was mentioned on Slashdot. A few days ago, I saw a
 comment posted somewhere that reminded me about it and contained these
 two keywords: functional + no-GC. That got me interested enough to
 head over to your main page.

 2- I really liked how on the front page there was a feature list that
 summarised what I could expect from the language. I was surprised not
 to see a bullet point reaffirming that there was no garbage collector
 necessary. I then started reading the Rust tutorial book in order.

 3- Installing Rust on Mavericks worked perfectly and I was happy to
 see it supported all three major platforms. I almost made the mistake
 of installing the old rust package in macports instead of running the
 macports version (0.12.0). From what I've read since, this would have
 been a critical mistake since Rust has evolved so quickly in the near
 past. Perhaps this package should be either removed or updated.

 4- I was a bit annoyed that I had to wade through Cargo stuff before
 getting to the details of the language, since I was still in the
 evaluating if Rust is interesting phase and had very little interest
 in packaging minutia in the introduction.

 5- Coming from an ML background, I only needed to skim most of the
 basics, taking note of which features were slightly different.

 6- The moment I saw for x in 0..10, I immediately wanted to know if
 I would be able to use the .. notation on my own types.

 7- I was again annoyed by the crates/modules/testing sections at the
 start of Section 3. I had completed reading the Basics section and
 had yet to see why I should care about Rust. The key Rust feature,
 resource management was still nowhere to be seen.

 8- Finally I reached the Pointers section I had been basically
 waiting to get to this whole time. Then I had to wade through pointer
 problems that any C programmer already knows intimately, before
 getting to how Rust does things. These two sections, 3.3 and 3.4, are
 probably the MOST important sections in the entire tutorial, but they
 come very late and are not well described. I would have expected to
 see a top-down approach to explanation. A here is how Rust deals with
 memory and THEN here is how this solves these problems. Instead, I
 got a here are problems you already know and then a here's how Rust
 does stuff. Due to this presentation approach, section 3.3 is very
 disjointed and I didn't come away from it with a clear idea of how
 this all works. It is also very jarring, because the rest of the
 tutorial is pretty Micky-Mouse and then suddenly the main new concept
 of Rust is explained with only surface detail in two tiny
 sections---completely inadequately.

 9- I entered the Ownership section quite annoyed from the terrible
 preceding section. I *still* don't really understand lifetimes, even
 after having sorted out the way Rust ownership works. These two
 sections are the worst in the tutorial, while also being the most
 important!

 At this point, I played around with Rust to try and understand the
 calling convention, move, copy, and borrow. I am pretty sure I
 understand it now, but I did *NOT* come away from the tutorial with
 this understanding. I would have presented the concepts in this order:

 1. Rust moves objects by default. Include

[rust-dev] Newcomer to Rust: my experience

[Wesley W. Terpstra]

Good afternoon and happy easter,

I am a newcomer to Rust and recently finished working through your
tutorial. Before I get too much further into reading the standard
library, I wanted to share my experience as a complete Rust newbie
starting out only with your documentation, before I forget it. I
regret that I did not start taking notes immediately, but it was not
yet clear to me how much I was going to like Rust, so a lot of this
will be me recalling my experience, without notes.

First, my background. I've been programming in C++ for 20 years and
used MLton (Standard ML) heavily for about 5 years, 4 years ago. I
have dabbled with Haskell, but not seriously. So, as far as beginners
to Rust go, I suspect I would be the sort of person who should
definitely have been able to go through your tutorial and come out at
the other end with a clear mental model of the language, as I've been
exposed to almost all of the concepts before.

1- I had heard about Rust through the odd talk at ML workshops via
youtube, although the last ML workshop I attended in person was ~6
years ago. The main thing that raised Rust to my attention was your
v1.0 release which was mentioned on Slashdot. A few days ago, I saw a
comment posted somewhere that reminded me about it and contained these
two keywords: functional + no-GC. That got me interested enough to
head over to your main page.

2- I really liked how on the front page there was a feature list that
summarised what I could expect from the language. I was surprised not
to see a bullet point reaffirming that there was no garbage collector
necessary. I then started reading the Rust tutorial book in order.

3- Installing Rust on Mavericks worked perfectly and I was happy to
see it supported all three major platforms. I almost made the mistake
of installing the old rust package in macports instead of running the
macports version (0.12.0). From what I've read since, this would have
been a critical mistake since Rust has evolved so quickly in the near
past. Perhaps this package should be either removed or updated.

4- I was a bit annoyed that I had to wade through Cargo stuff before
getting to the details of the language, since I was still in the
evaluating if Rust is interesting phase and had very little interest
in packaging minutia in the introduction.

5- Coming from an ML background, I only needed to skim most of the
basics, taking note of which features were slightly different.

6- The moment I saw for x in 0..10, I immediately wanted to know if
I would be able to use the .. notation on my own types.

7- I was again annoyed by the crates/modules/testing sections at the
start of Section 3. I had completed reading the Basics section and
had yet to see why I should care about Rust. The key Rust feature,
resource management was still nowhere to be seen.

8- Finally I reached the Pointers section I had been basically
waiting to get to this whole time. Then I had to wade through pointer
problems that any C programmer already knows intimately, before
getting to how Rust does things. These two sections, 3.3 and 3.4, are
probably the MOST important sections in the entire tutorial, but they
come very late and are not well described. I would have expected to
see a top-down approach to explanation. A here is how Rust deals with
memory and THEN here is how this solves these problems. Instead, I
got a here are problems you already know and then a here's how Rust
does stuff. Due to this presentation approach, section 3.3 is very
disjointed and I didn't come away from it with a clear idea of how
this all works. It is also very jarring, because the rest of the
tutorial is pretty Micky-Mouse and then suddenly the main new concept
of Rust is explained with only surface detail in two tiny
sections---completely inadequately.

9- I entered the Ownership section quite annoyed from the terrible
preceding section. I *still* don't really understand lifetimes, even
after having sorted out the way Rust ownership works. These two
sections are the worst in the tutorial, while also being the most
important!

At this point, I played around with Rust to try and understand the
calling convention, move, copy, and borrow. I am pretty sure I
understand it now, but I did *NOT* come away from the tutorial with
this understanding. I would have presented the concepts in this order:

1. Rust moves objects by default. Include example showing that let y
= x makes x invalid afterwards. Explain that this ensures that
there is exactly one release to each allocate---something that can
easily be understood even without explaining C pointers. Show that
this applies to function calls as well; let x = Foo; f(x);
println!({:?}, x); // -- Bad

2. Explain that some types can be copied instead. Mention that this is
indicated by the Copy+Clone trait and show that let y = x and
f(x) leave x valid afterwards. Mention that all basic types work
this way, but that it is an opt-in feature.

3. Show the #[derive(Copy,Clone)] syntax which 

Bug#780981: avahi-daemon: Avahi-daemon loses name when used with dynamic IPv6

[Wesley W. Terpstra]

Package: avahi-daemon
Version: 0.6.31-4+b2
Severity: important

Dear Maintainer,

FYI, This is clearly an upstream bug, but I could not figure out the upstream
BTS. Since this affects jessie, I figure it also important to mention here.
Please forward this bug upstream.

So, here's the problem. Every night at 4am or so my home internet router (a
fritzbox) resets its internet connection.  This causes my external IPv6 and
IPv4 addresses to change.  When this happens avahi-daemon loses its name.

Normally, a ps listing shows:
24747 ?S  0:00 avahi-daemon: running [pumpkin.local]
When the bug kicks in, it looks like:
24145 ?S  0:00 avahi-daemon: running [pumpkin-2.local]

In daemon.log, the tell-tale symptom is the following line:
Mar 22 17:43:00 pumpkin avahi-daemon[20334]: Host name conflict, retrying with 
pumpkin-2

At this point, the system no longer responds to its own name and all sorts
of higher-level network applications start to fail. The severity depends on
how many services depend avahi. In my case, it breaks time machine backups
from all macs in the house, cacti error logging, nfs clients, and xbmc.
So, for me, this is a severe bug that happens about once a week. However,
as I'll explain, the problem only affects people with a perfect storm of
configuarion options.

You can find reports of this bug going back a year all over the internet.
However, I went a bit further than those reports and modified avahi-daemon
to print out WHAT the conflict is that leads to this problem.

The issue is this: when your router resets its internet connection, its
assigned *IPv6* address changes. Local IPv6 addresses are assigned in the
low 64-bits of the assigned address. Thus, hosts in the internal network
will see their IPv6 address change, but not their NAT'd IPv4 address.

These things are necessary to trigger the bug:
  You must be using IPv6 (IPv4 NAT'd IPs do not change)
  Your system must receive its IPv6 address dynamically (no static address)
  Your IPv6 subnet must change for some reason (modern router reconnecting)

The bug also has some sort of race condition involved.

When I added debug statements to the daemon, the problem became much more
severe and it could easily end up with pumpkin-87 before finally succeeding. 
Before the additional print statements were added, the failure would happen
with about a 1/10 change every time the network address changed.  Thus, I
imagine on a slower system the bug appears more often.

Here is an extract from the logs of my modified avahi-daemon:

These messages appear harmless and happen fairly often:
Mar 22 17:41:47 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:41:47 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
Mar 22 17:42:23 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:23 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
Mar 22 17:42:48 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:48 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
At this point I just reset my internet connection:
Mar 22 17:42:58 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:58 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
fe80::ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:dc21:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:bbeb:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:1b96:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:e532:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:cc8d:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:5036:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin 

[Pkg-utopia-maintainers] Bug#780981: avahi-daemon: Avahi-daemon loses name when used with dynamic IPv6

[Wesley W. Terpstra]

Package: avahi-daemon
Version: 0.6.31-4+b2
Severity: important

Dear Maintainer,

FYI, This is clearly an upstream bug, but I could not figure out the upstream
BTS. Since this affects jessie, I figure it also important to mention here.
Please forward this bug upstream.

So, here's the problem. Every night at 4am or so my home internet router (a
fritzbox) resets its internet connection.  This causes my external IPv6 and
IPv4 addresses to change.  When this happens avahi-daemon loses its name.

Normally, a ps listing shows:
24747 ?S  0:00 avahi-daemon: running [pumpkin.local]
When the bug kicks in, it looks like:
24145 ?S  0:00 avahi-daemon: running [pumpkin-2.local]

In daemon.log, the tell-tale symptom is the following line:
Mar 22 17:43:00 pumpkin avahi-daemon[20334]: Host name conflict, retrying with 
pumpkin-2

At this point, the system no longer responds to its own name and all sorts
of higher-level network applications start to fail. The severity depends on
how many services depend avahi. In my case, it breaks time machine backups
from all macs in the house, cacti error logging, nfs clients, and xbmc.
So, for me, this is a severe bug that happens about once a week. However,
as I'll explain, the problem only affects people with a perfect storm of
configuarion options.

You can find reports of this bug going back a year all over the internet.
However, I went a bit further than those reports and modified avahi-daemon
to print out WHAT the conflict is that leads to this problem.

The issue is this: when your router resets its internet connection, its
assigned *IPv6* address changes. Local IPv6 addresses are assigned in the
low 64-bits of the assigned address. Thus, hosts in the internal network
will see their IPv6 address change, but not their NAT'd IPv4 address.

These things are necessary to trigger the bug:
  You must be using IPv6 (IPv4 NAT'd IPs do not change)
  Your system must receive its IPv6 address dynamically (no static address)
  Your IPv6 subnet must change for some reason (modern router reconnecting)

The bug also has some sort of race condition involved.

When I added debug statements to the daemon, the problem became much more
severe and it could easily end up with pumpkin-87 before finally succeeding. 
Before the additional print statements were added, the failure would happen
with about a 1/10 change every time the network address changed.  Thus, I
imagine on a slower system the bug appears more often.

Here is an extract from the logs of my modified avahi-daemon:

These messages appear harmless and happen fairly often:
Mar 22 17:41:47 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:41:47 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
Mar 22 17:42:23 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:23 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
Mar 22 17:42:48 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:48 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
At this point I just reset my internet connection:
Mar 22 17:42:58 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:58 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Withdrawing address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
fe80::ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:3c58:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:dc21:c0a8:b22a:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:bbeb:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:1b96:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:e532:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:cc8d:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin avahi-daemon[20334]: Registering new address record for 
4006:5036:c0a8:b23f:ae22:bff:fe50:73ea on br0.*.
Mar 22 17:42:59 pumpkin 

Bug#685878: Netatalk 3?

[Wesley W. Terpstra]

Hi,

I've been using a self-built netatalk3 in debian for quite some time. I
assume there is a good reason that debian/sid still has 2.2.2?

If it's just manpower, I'd be happy to help with packaging. It would be a
real pity if jessie ships with a 3-year-old netatalk.

Bug#685878: [Pkg-netatalk-devel] Netatalk 3?

[Wesley W. Terpstra]

On Mon, Nov 3, 2014 at 8:29 PM, Jonas Smedegaard d...@jones.dk wrote:

 Hi Wesley,


Hey Jonas.
Long time no see!


 If you are only intrested in helping with Netatalk 3, then that's fine
 too.


Well, I personally need netatalk = 3.
Netatalk 2 doesn't do time machine properly.

But I highly doubt that any work now on that front will be
 accepted for Jessie: Freeze is in 2 days, which means a bug-free
 Netatalk 3 should have been uploaded at least 8 days ago. :-(


Yeah, I hadn't realized freeze was this close.
Shit. I've really dropped the ball on my own packages.
Maybe there will be a surprise extension like almost-every-other release.

What is crucially needed now to even get Netatalk 2 in Jessie is for
 someone to fix bug#751121.


That is indeed unfortunate!
Even an urgent upload won't make it in now if the freeze date holds.

Re: Best way to carry on 2-input architecture?

[Wesley W. Terpstra]

On Fri, Aug 22, 2014 at 11:46 AM, Wesley W. Terpstra wes...@terpstra.ca wrote:
   H = (x - L) mod (B-1)

 So let me get this straight. Your plan is to compute x=a*b mod (B-1).
 In other words, you sum 64 columns of 64-rows in a square shape
 instead of the usual parallelogram. Then you throw the twos complement
 of the old result (L) in there for 65 rows. Finally, apply Wallace and
 a KS adder.

I made a mistake. Modulo (B-1), -L is not(L). So you throw ~L into the
65th row, not the twos complement. That works out better anyways.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Best way to carry on 2-input architecture?

[Wesley W. Terpstra]

On Fri, Aug 22, 2014 at 2:06 PM, Niels Möller ni...@lysator.liu.se wrote:
 But a 64-bit mul is usually not single cycle?

Of course not. I'm not sure what you're driving at here.

If mullo and mulhi both have the same clock and are both 3 cycles
deep, it does not matter if one has slightly lower latency between two
registers. A chip is timed so that the slowest path between any two
registers for a single clock domain is guaranteed to complete within
the clock period.

 On typical x86 processors,
 mullo (or low half of a wide mul) is available a cycle earlier than the
 high half, so maybe there are other reasons for that

All I can say for sure is that they didn't HAVE to make it one cycle
later. There are all kinds of reasons they might have done so that
have nothing to do with the latency of a multiplier circuit.

 You could get by with a single port, if you send out the results in
 different cycles. Returning to x86 processors, it's also common that one
 can issue a widening mul only once every second cycle. Maybe that's how
 they do it?

It's possible. We don't have the HDL for an Intel processor, so who knows.
Real chips have lots of complicating factors that need to be balanced.

I am not sure this scheme is a big win, though. Outputting the high
half a cycle later means you cannot issue a new multiply through the
EU during that cycle. So, back to my mux(high,low) multiplier example,
I can output both halves on alternating cycles too, with the same
throughput. That's because my mulhi goes in where they have a pipeline
stall to push out the high half.

If they are doing that, maybe it's to save power or something.

 I think it's fairly unusual (at least for bignum applications) that you
 want the high half but not the low half. Even for division (see
 https://gmplib.org/~tege/division-paper.pdf), the low half is needed
 (and interpreted as quotient fraction for the adjustment step). There
 may be a few cases where a mulhadd could eliminate the need for the low
 half.

When I said integer division, I did not mean bignum integer division.
If there is no hardware divide instruction, you can implement it using
fmahi. In that case you don't need fmalo at all.

My CPU does a 64x64=128 and uses a mux to pick hi/lo halves. For my
design, I am sure this is the right choice. It keeps the issue stage
very simple and I want to use the circuit for division (software or
microcode). If I was building an ASIC and had different goals, maybe
I'd do something else. I'll wager there are more users of integer
division than there are users of gmp, so the trade-off in my case is
clear. =D

 It's fine for plain mulhi, but for mulhadd, H can equal B-1. Largest
 possible value is x = (B-1)*(B-1) + B-1 = B (B-1).

Fair enough. You could easily detect that earlier in the pipeline by
seeing if your c in a*b+c is all ones.

 mentioned NTT as a possibility. That should be more efficient for
 wraparound mul than for regular mul. But I would also be a bit surprised
 if that can bring any significant savings for sizes as small as 64 bits.

I was not proposing it for 64x64!!!
I have no idea when NTT would be more efficient.
Maybe like 2048x2048 or something.

The gate depth of NTT will be 2*log(N)*C where C is the cost of doing
GF(N) arithmetic in the butterfly stages. Let's guess C is like 8. Oh,
you also need a small Wallace tree and a KS adder to recombine the
final carries too.

So, NTT gate depth always be much worse than a standard multiplier,
except for the wire delays due to the huge size of a really big
standard multiplier as the quadratic AND area explodes.

To be fair, both KS and a butterfly network will also have serious
problems with wire lengths in the far mixing rows. Maybe there's a
better, as yet undiscovered circuit. At the scales we're talking
about, wire delay will be the dominant cost.

FYI, as you didn't know about the KS-adder: It's just a specific
example of the more general prefix-sum design pattern. That's a
standard building block for parallel algorithms (including hardware).
There are lots of variations. KS has nlogn area and logn depth. You
can also do prefix-sum (and thus adders) in n area and 2logn depth.
Lots of trade-off options.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Best way to carry on 2-input architecture?

[Wesley W. Terpstra]

On Wed, Aug 20, 2014 at 10:59 AM, Niels Möller ni...@lysator.liu.se wrote:
 I've been thinking that if you want the full two-word result of a
 multiply, and compute each part separately using mulhi and mullo, the
 mulhi operation will have to compute the full product anyway, discarding
 the low half, and then the mullo will redo the same computation. This
 seems redundant

Yes, it is.

This is why some architectures output the low+high at the same time.
However, that means instructions can potentially have two outputs,
which increases the already-quadratic execution-unit-bypass cost. IMO,
trying to output both halves at once is a bad idea. Bypass ports are
more expensive than multiplier units.

 But maybe you can do a circuit for mulhi which is significantly simpler
 than for a widening multiplication, because you only need to collect the
 carry out from the low partial products? Something like a Wallace tree
 where you drop the low output bit from all the half and full adders of
 the low product half.

If you figure out a way to do this, please let me know.

Personally, I don't see how this could be done. The Wallace tree can
never reduce you to less than two rows. So, you still have to do the
full adder to find the carry for the lower half.

 And maybe you would want to implement some sort of carry-lookahead
 anyway, to reduce latency, so a even a widening multiplication would use
 mostly independent circuits for the low and high half?

Don't forget that ASICs do not use ripple adders. They use Kogge-Stone
adders, or a variation with similar circuit depth, but less area. So
carry-lookahead is crap compared to what they use for the final sum.

 Second question is on how large multipliers are implemented. How large
 multipliers is it practical to build using a single cycle combinatorial
 Wallace tree? How does one organize a 64x64 multiplier, which seems too
 large to do in one cycle?

These are all questions for an ASIC designer. I work with FPGAs.

However, I think your question exposes some confusion. It's not how
large the multiplier is that matters. You must pay the full area cost
for the multiplier no matter how many cycles it takes. In fact,
increasing the latency/cycles ADDS area cost. [There are ways to
reduce the area, but if you want to be able to issue one multiply
every cycle (like a CPU), those techniques are unavailable.]

So, for a 64x64 multiplier, the circuit starts with 1 level of 64x64
AND gates, followed by 8 levels of 3:2 Wallace reduction, followed 6
levels of a KS adder.

That circuit has some technology-dependant latency from start to
finish. Lets say it takes 1 nanosecond. That would mean they can run
it at 1GHz with a 1 cycle latency. However, if they put a row of
registers in the middle, the latency for each cycle is cut in half +
the register's delay. So maybe they get 1.8GHz with 2 cycle latency.
The latency of the multiplier is a trade-off you make to increase the
maximum frequency of the device. In all cases, the multiplier hardware
is identical, only the position and number of registers in the circuit
change.

 One could build it out of smaller blocks, say we have combinatorial 8x8
 multipliers. We then need 64 of those, in sequence or parallel, and a
 bunch of adders. Or we could use Karatsuba, to do a 64x64 using 27 8x8
 multiplies and a bunch of additions.

Those are software techniques. You would not do that in an ASIC.

You *might* do this in an FPGA, because we have so-called hard IP
blocks that are basically fixed-function multipliers of a specific
size. So, the Arria V series has hardware to do 27x27 multiplies that
I can use as building blocks.

For reference, here is the implementation I wrote for multipliers on
an FPGA: https://github.com/terpstra/opa/blob/master/opa_prim_mul.vhd
This multiplier has latency of 2-4 cycles depending on whether or not
I enable some registers to improve the circuit performance.

I don't do Karatsuba or anything like that, because, ... well, it's a
bad idea. :-) I use a Wallace tree to get the result of the (27x27 or
whatever) DSP blocks down to two-three parts and then I use the FPGA's
dedicated adder logic.

 Does that make any sense?

No. You would build it as I outlined above. 64x64 AND gates, Wallace
reduction, and a log-deep adder. The only variation is where you put
the registers.

If you were building a truly huge multiplier, like 256x256 or bigger,
then you would use a state-machine which drives and reuses primitive
multiplier units built like above. Such a state-machine would never be
used in a CPU, but might be used in a custom crypto chip or something.
A CPU would just run a program that did the same thing.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Best way to carry on 2-input architecture?

[Wesley W. Terpstra]

On Wed, Aug 20, 2014 at 10:59 AM, Niels Möller ni...@lysator.liu.se wrote:
 One could build it out of smaller blocks, say we have combinatorial 8x8
 multipliers. We then need 64 of those, in sequence or parallel, and a
 bunch of adders. Or we could use Karatsuba, to do a 64x64 using 27 8x8
 multiplies and a bunch of additions.

I'm going to retract my out-of-hand rejection of this idea.

 So one possibility might be a three-stage pipe-line, where the first
 stage exands the two 64-bit inputs into 27 8-bit values each (well, they
 grow a little; we either have to manage additional sign bits, or to work
 with unsigned only, the largest pieces will grow to 11 bits). Second
 stage would do 27 smaller multiplies in parallel. And the third and
 final stage would combine those 27 products to the complete 128 bit
 product.

I can't visualize how the summands get recombined. It's not as simple
as adding the results using a Wallace tree, though, because you have
common sub-expressions that you can't destroy or you lost the benefit.

What I can visualize, and think fits well to hardware, is an NTT-based
algorithm. Widen all the bits by log(N), do an NTT to both inputs,
multiply, and another NTT. This would be a good fit for hardware
beyond some threshold.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Best way to carry on 2-input architecture?

[Wesley W. Terpstra]

On Sun, Aug 17, 2014 at 10:00 PM, Niels Möller ni...@lysator.liu.se wrote:
 t...@gmplib.org (Torbjörn Granlund) writes:
 My work is available here: https://gmplib.org/~tege/fisa.pdf

Thank you for the link.

 And mine at http://www.lysator.liu.se/~nisse/misc/instr16.pdf (a toy
 project, trying to squeeze a decent instruction set with 16 general
 purpose registers into 16-bit opcodes).

As I mentioned, my current ISA is also 16 bit. I won't go to the
trouble of writing it up, as I intend to ditch it for something better
as soon as I've finalised the core CPU design. However, I went with
the format OoAB (each 4 bit) where the main op code is O, and
operations are always gp(B) = gp(A) op gp(B). The format only
supports 8-bit constants via an instruction that sets gp(B) =
sext(oA). The restriction of having B as both input and output is
not particularly onerous, IMO. If you have a CPU with register
renaming, executing a copy instruction is free (except for the space
in memory). So if the compiler can't avoid a copy before the
instruction, at least it doesn't add any latency. I'm undecided as to
if 16 registers are sufficient.

The main reasons this is only a temporary ISA is that there is no easy
way to get large enough branch displacements. I considered adding a
special prefix register as you describe, but that has some serious
problems when built as actual hardware:

The first option is just using the prefix register by name. So you
shift in your constant, 12bits at a time, then execute an instruction
that uses it by name. That works well for arithmetic. The downside to
this scheme is that all your branches are now indirect branches. That
makes the job of the fetch stage very hard. Probably too hard.

The alternative is to use prefix instructions. Here you load some
constant in pseduo-instructions that become no-ops and the next real
instruction receives the constant as an immediate in place of gp(B).
The downside to this is that it makes the ISA context sensitive. When
you receive an interrupt, you need to make sure that the return PC
points to the start of the prefix sequence. On the plus side, the
prefix instructions can be readily identified during the fetch stage
and thus branch prediction is nearly as easy as in a classic RISC. I
think this is the better of the two options.

Your approach is closest to the first option. Because you need to look
at the prefix flag and combine the prefix register with the
immediate value when you do a jump, you have the indirection branch
problem... on steroids.

 I'm not familiar with implementing cpu's (I'd like to learn some day),
 but I imagine that additional read/write ports to a couple of flag bits
 are cheaper than additional read/write ports to the much wider register
 file.

That's definitely true for an in-order CPU. If you really want flags,
you can have them on an out-of-order CPU too. It does imply a 3rd
port, though. Just because the flag register-file is narrow doesn't
mean that all the attendant circuitry to rename the flags and delay
instructions until needed flags become ready goes away, though.

 Or extending that a bit, one needs an efficient way to compute a*b + c +
 d, where the inputs are single-word values, and the result always fits
 in two words, with no overflow.

Hmm. How often does one need this double FMA ability? I assume we're
talking about the high part of the result, because the low part could
be obtained with normal arithmetic.

 E.g., on ARM there's the umaal
 instruction; to be really useful, it has to be implemented so that it
 can start the multiply as soon as a and b are available, with the data
 dependency on c and d happening later on in the pipeline.

That's not how you do it. The reason FMA is so great in hardware is
that when you implement say a 32x32 multiplier you first do some
really cheap addition (no carry needed) using a Wallace tree or
something similar. Then after the Wallace tree you have two 64-bit
numbers that you combine with a proper adder to get the final result.
An FMA puts the extra term to sum into the calculation before the
Wallace tree, so you essentially get free carries. That means you must
have a*b+c all ready to go before the FMA.

FMA is really great. I really want it. I want it so bad it tempts me
to implement 3 ports just to have it. However, 3 ports cause me so
much pain. :-( I've even contemplated crazy ideas like a special FMA
two-part instruction sequence:

fma-pt1 t, a, b
fma-pt2 y, t, c

The idea being that 't' is used to force sequencing of the
instructions and then you make the bypass between multiply units
double-width so they can stash both a and b into t to pass to the unit
who gets fma-pt2. But this is crazy talk. I am sure this sort of hack
would turn out to be a bad idea longer term. For one thing, it's
another context-sensitive instruction...

 A bit more specialized, if you don't have a divide instruction, you want
 to be able to do division via multiplication.

Yeah, I'd go with 

Re: Best way to carry on 2-input architecture?

[Wesley W. Terpstra]

On Mon, Aug 18, 2014 at 9:01 AM, Niels Möller ni...@lysator.liu.se wrote:
 I don't think it has to be that bad. First, the prefix flag and register
 should be saved and restored on irq, so there should be no problem with
 irq:s or page faults and the like in the middle of an instruction.

Yes, that's the advantage. Keep in mind, though, that dealing with
variable-length instructions is a well understood and not-so-difficult
problem. I just need to report the PC as being at the start of the
prefix-chain. This change is local to the decoder.

 one has to do something a bit similar with the program counter

I agree with everything you said about the PC.
Dealing with the PC is a real pain.
Not something to copy unless you must.

 And then I intend the prefix register and prefix flag to live with the
 decoder block (so it should never be subject to register renaming). The
 prefix instruction is executed as part of the decoding, and the full
 immediate value/offset is passed with the rest of the decoded
 instruction to the main instruction execution block.

The value in the decoder is ahead of the values seen in the execution
units. If an exception occurs, you need to be able to rewind/reset the
value in the decoder to the state it would have had if execution had
gone to the correct destination at that point. Upon reflection, I
think you are correct that I could track the state of the shift
register all the way through the pipeline, just like the PC. Then,
when I retire an exception-producing instruction, I feed the
fetcher/decoder the old shift register state at the same time I give
it the new PC.

So, I agree it could be done. But, I still think it's more expensive
than supporting variable-length instructions. Going down the
variable-length instruction path also opens the doors to other
features, like your 4-operand umaal instruction.

 But if it is done that way, it's almost useless for gmp. One of the add
 operands is the input carry word, and if it has to be available before
 the multiply, then you get the full multiplication latency on the
 critical path. If I remember previous discussions on this list
 correctly, experiments showed that at least on cortex-a15, umaal is
 *not* implemented that way: The latency between the availability of the
 add operands and availability of the output is only a single cycle.

That's very strange. So, let me preface my response by noting that I
know very little about ARM and that all of my practical HDL experience
is with FPGAs, not ASICs. Furthermore, while I've had to debug a few
soft CPUs, I build different circuits professionally. This CPU project
is something I'm doing for fun. So I am definitely not an expert on
how ARM implemented this.

That said, from what you describe, it sounds to me like they've
actually decomposed the FMA into two micro-ops. The first does the
32x32 a*b and the second runs when the 64-bit multiply result and the
32-bit c term are available. Otherwise, their instruction scheduler
would somehow have to be able to look into the future to see that it
has ab ready now and will have c later. That is probably possible,
but I'll wager it's prohibitively expensive, likely doubling the
length of the scheduling critical path. If the FMA is decomposed into
two micro-ops, a bog standard instruction scheduler would have the
behaviour you describe. This approach would also mean that they could
use a 2-port processor core to implement FMA at the cost of a
double-wide bus for one of the operands.

This has given me something to think about, as it might be a way for
my implementation to also get FMA with 2 ports. Frankly, though, I am
more tempted to go with a fully 3-port design like Torbjörn's than
building in some hack.

 On ARM, it is used by addmul_1, addmul_2, addmul_3 and friends, which
 means that it is the main work horse of bignum multiply. Search for it
 in the mpn/arm subdirectories for examples.

I agree the instruction look interesting. From the fma behaviour you
described above, I strongly suspect that ARM has one of their register
file ports 64-bit wide. That would let you implement all of these
sorts of operations with micro-ops. Again, though, I know almost
nothing about ARM.

PS. Sorry you got this twice, Niels. I missed the reply all button.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: Best way to carry on 2-input architecture?

[Wesley W. Terpstra]

So, yeah, we're drifting pretty far off-topic now. If you have
follow-up questions that you think aren't interesting for gmp-devel,
just send them to me privately.

On Mon, Aug 18, 2014 at 2:35 PM, Niels Möller ni...@lysator.liu.se wrote:
 I think the decoder could implement the prefix instruction, as I've
 defined it, in that way, treating a sequence of prefix instructions +
 non-prefix instruction as an indivisible longer instruction. Supervisor
 mode/kernel mode code might need to know if there really is a prefix
 register or not, but otherwise, it's an implementation detail not
 visible to user code.

I don't agree. The point of your approach is that the shift
instruction is NOT a prefix, but a proper instruction. Thus, other
instructions can come between it and the instruction which finally
consumes the shift flag. So you can't treat the shift op + consumer
op as an indivisible whole, the way you can with variable-length
instructions. This is the key difference.

Either you say it's a prefix op (and thus indivisible from the
consuming op, essentially a variable-length op) or you let
shift-in-a-constant be a proper instruction. You choose the later.
Thus, you need to track it all the way through the pipeline so that
you can abort it.

 If you get a page fault from a reordered load or store, or some
 other exception associated with the execution of a particular
 instruction, how do you stop the instruction flow at the correct point
 before the control transfer to the handler?

So your outline is more-or-less right. There are different approaches
to this problem, depending on your goals. My goals are: exceptions can
be slow, cancelled reads are allowed to be visible outside of the CPU,
cancelled writes are not. Thus, I forbid a write from even being
reordered before an unconfirmed read or branch. This is not
particularly difficult since I only have a single loadstore unit due
to resource constraints and I have to watch for RaW conflicts through
memory anyway.

To cancel the other operations, I have two register renaming maps
(from architectural registers to backing registers). One is at the
front of the pipeline, near the decode stage. The other is at the end
of the pipeline at the retire stage. When an instruction enters the
OoO window, I update the front map. When an instruction is retired
(leaves the OoO window), I update the back map. Instructions only
leave the OoO window, in order, when they've completed. Obviously, I
can retire and load multiple instructions / cycle.

If an exception occurs, I just tag the instruction as killed. When it
reaches the retire stage, I destroy everything in the OoO window and
force the rename stage to load the retire stage's rename map. This
stops processing of any remaining instructions and reverts the writes
of any that were already done. I use this scheme for branch
misprediction too. In all cases, I then supply the PC that was
associated with the killed instruction to the fetch unit. This is
where I would need to resupply the shift register state in your ISA
as well.

It sounds expensive, but after the CPU has been running a bit without
exceptions, you generally have stuff waiting at the bottom of the OoO
window from whatever the critical path through the code is anyway.
There are other approaches that are faster. If it turns out to be too
slow for misprediction, I may revise my plan. Mine is very simple,
though, which makes it good for a first version on an FPGA.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Best way to carry on 2-input architecture?

[Wesley W. Terpstra]

Good evening,

As a hobby project I've been building an out-of-order superscalar CPU
for use in FPGAs. Everything has been going pretty smoothly, but I'd
like to be able to support gmplib efficiently on it. To keep the issue
stage small+fast, instructions on this machine can only accept two
register arguments at once. No carry flags. I was wondering if there
is a clever way to implement bigint addition with less
instructions/word, by adding a custom instruction or two.

So I can already do the generic gmp version:
  do
{
  ul = *up++;
  vl = *vp++;
  sl = ul + vl;
  cy1 = sl  ul;
  rl = sl + cy;
  cy2 = rl  sl;
  cy = cy1 | cy2;
  *rp++ = rl;
}
  while (--n != 0);

In my assembly language this would best be written as:
loop:
  iload ul, up, i
  iload vl, vp, i
  add sl, ul, vl
  addhi cy1, ul, vl ; cuts dependency on sl = gives carry immediately
  add rl, sl, cy
  addhi cy2, sl, cy
  or cy, cy1, cy2
  istore rl, rp, i
  add i, i, 1
  bne i, n, loop
... while that looks awful, it's actually not so bad. Between the
loads and store are only two instructions (2* add), the minimum
possible. Between loop iterations, the critical path path is cy, which
goes through an addhi and an or. I can't yet reorder loads before
stores, but in the future once I can, this means each loop iteration
has latency of 2 cycles (assuming the reorder buffer is large enough).
Since the loop has 10 instructions and I can only issue 4 at once, I
am actually bottlenecked by the poor code density and L1-cache
interface. Hmm. Now I wonder why I am writing this email and perhaps
there is nothing that needs to be done!

For comparison, if I had addc:
loop:
  iload ul, up, i
  iload vl, vp, i
  addc sl, ul, vl ; can not implement this! (3-inputs: CF, ul, vl)
  istore sl, rp, i
  add i, i, 1
  bne i, n, loop
... that is only 6 instructions and the latency is just 1 cycle.
However, I'm still going to be bottlenecked by the L1 and issue-width.

So, now that I've more carefully analyzed the loop, I am actually not
as concerned as I was initially! However, I think the question still
stands: aside from an addhi instruction, are there any other custom
instructions I should be adding for bigint arithmetic? I also already
have umulhi which should help with multiplication. I am guessing
that when optimizing gmp, there were times when you guys were
irritated by the lack of some specific instruction that would have
made things a lot quicker. This is the sort of information I'd love to
have.

Thanks for your time!
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Bug#725884: Me too!

[Wesley W. Terpstra]

Just wanted to mention this bug affects me as well. I have the same
disks (WD30EZRX). As I found this bug report via google, it's not
surprising we have the same hard disk, however.

I can spin the disk down with 'hdparm -y /dev/sdd' and it stays spun
down for hours. However, the disk will never spin down on its own,
despite hdparm -S 2 /dev/sdd.

Here's hoping someone finds a fix!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Using bcache to save power -- safe?

[Wesley W. Terpstra]

Good afternoon!

My question: Can I leave writeback_running=0, or will it hurt my data?

Background:

I've started using bcache on my NAS array and must say it is working
out quite well. My goals were energy/noise savings and performance.
These appear to be met with my current configuration.

backing device: RAID5 array on 4x WD green drives
cache device: RAID1 array on 2x SanDisk SSDs
LVM on top of bcache0
WD drives set to spin down after 10 minutes idle
linux 3.12

writeback_percent = 25
sequential_cutoff = 0
congested_*_threshold_us = 0
writeback_running = 0

... with these settings my server can happily continue running its
periodic tasks (smartd, cacti, syslog, dvb, samba, ntp, etc) without
spinning up the disks. All periodic data gets stored to the energy
saving (and silent) SSDs. Great!

My concern is what will happen if some huge burst of IO comes and
overwhelms my cache drive. Can bcache still push data to the RAID5
when writeback_running=0? I have a daily cronjob set to re-enable
writeback_running and set cache_mode to writethrough, wait for clean,
then re-enable writeback. So, the dirty_data does not tend to get too
high. However, there could be some day where a ton of data gets
written.

Is near-permanent writeback_running=0 safe?

Thanks!

PS. Obviously I am interested in the progress of RAID5-aware bcache
and multiple SSDs per cache set, since both would directly benefit my
setup. So I am pretty happy with the direction bcache is heading!
--
To unsubscribe from this list: send the line unsubscribe linux-bcache in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug#707410: mlton: FTBFS: gc/int-inf.c:180:43: error: unknown type name '__gmp_const'

[Wesley W. Terpstra]

Yes, I also have a patch, but the next MLton is due out shortly and it
includes the patch. I am just waiting for the release.


On Tue, Jun 25, 2013 at 6:53 PM, Sebastian Ramacher sramac...@debian.orgwrote:

 Control: tags -1 + patch upstream fixed-upstream
 Control: forwarded -1 https://github.com/MLton/mlton/issues/3

 On 2013-05-09 10:09:15, Lucas Nussbaum wrote:
  Relevant part:
   gcc -std=gnu99  -I. -Iplatform  -fno-common -fvisibility=hidden -m64
 -O2 -fomit-frame-pointer   -pedantic -Wall -Wextra -Wformat=2
 -Wswitch-default -Wswitch-enum -Wuninitialized -Winit-self
 -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wshadow -Wpointer-arith
 -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return
 -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes
 -Wmissing-declarations -Wmissing-field-initializers -Wmissing-noreturn
 -Wmissing-format-attribute -Wredundant-decls -Wnested-externs
  -Wdisabled-optimization  -c -o gc.o gc.c
   In file included from gc.c:44:0:
   gc/int-inf.c:180:43: error: unknown type name '__gmp_const'
   gc/int-inf.c:181:43: error: unknown type name '__gmp_const'
   gc/int-inf.c: In function 'IntInf_add':
   gc/int-inf.c:196:3: warning: implicit declaration of function 'binary'
 [-Wimplicit-function-declaration]
   gc/int-inf.c:196:3: warning: nested extern declaration of 'binary'
 [-Wnested-externs]
   gc/int-inf.c: At top level:
   gc/int-inf.c:257:34: error: unknown type name '__gmp_const'
   gc/int-inf.c: In function 'IntInf_neg':
   gc/int-inf.c:271:3: warning: implicit declaration of function 'unary'
 [-Wimplicit-function-declaration]
   gc/int-inf.c:271:3: warning: nested extern declaration of 'unary'
 [-Wnested-externs]
   gc/int-inf.c: At top level:
   gc/int-inf.c:283:34: error: unknown type name '__gmp_const'
   gc/int-inf.c: In function 'IntInf_arshift':
   gc/int-inf.c:299:3: warning: implicit declaration of function 'shary'
 [-Wimplicit-function-declaration]
   gc/int-inf.c:299:3: warning: nested extern declaration of 'shary'
 [-Wnested-externs]
   make[4]: *** [gc.o] Error 1

 A fix is available from upstream:

 https://github.com/caltry/mlton/commit/a658a1f4a76a01f568116598800f49b80cf8ee1a

 Attached is a patch to the package that incorporates this fix. I don't
 intend to upload it.

 Regards
 --
 Sebastian Ramacher

Bug#707410: mlton: FTBFS: gc/int-inf.c:180:43: error: unknown type name '__gmp_const'

[Wesley W. Terpstra]

Yes, I also have a patch, but the next MLton is due out shortly and it
includes the patch. I am just waiting for the release.


On Tue, Jun 25, 2013 at 6:53 PM, Sebastian Ramacher sramac...@debian.orgwrote:

 Control: tags -1 + patch upstream fixed-upstream
 Control: forwarded -1 https://github.com/MLton/mlton/issues/3

 On 2013-05-09 10:09:15, Lucas Nussbaum wrote:
  Relevant part:
   gcc -std=gnu99  -I. -Iplatform  -fno-common -fvisibility=hidden -m64
 -O2 -fomit-frame-pointer   -pedantic -Wall -Wextra -Wformat=2
 -Wswitch-default -Wswitch-enum -Wuninitialized -Winit-self
 -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wshadow -Wpointer-arith
 -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return
 -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes
 -Wmissing-declarations -Wmissing-field-initializers -Wmissing-noreturn
 -Wmissing-format-attribute -Wredundant-decls -Wnested-externs
  -Wdisabled-optimization  -c -o gc.o gc.c
   In file included from gc.c:44:0:
   gc/int-inf.c:180:43: error: unknown type name '__gmp_const'
   gc/int-inf.c:181:43: error: unknown type name '__gmp_const'
   gc/int-inf.c: In function 'IntInf_add':
   gc/int-inf.c:196:3: warning: implicit declaration of function 'binary'
 [-Wimplicit-function-declaration]
   gc/int-inf.c:196:3: warning: nested extern declaration of 'binary'
 [-Wnested-externs]
   gc/int-inf.c: At top level:
   gc/int-inf.c:257:34: error: unknown type name '__gmp_const'
   gc/int-inf.c: In function 'IntInf_neg':
   gc/int-inf.c:271:3: warning: implicit declaration of function 'unary'
 [-Wimplicit-function-declaration]
   gc/int-inf.c:271:3: warning: nested extern declaration of 'unary'
 [-Wnested-externs]
   gc/int-inf.c: At top level:
   gc/int-inf.c:283:34: error: unknown type name '__gmp_const'
   gc/int-inf.c: In function 'IntInf_arshift':
   gc/int-inf.c:299:3: warning: implicit declaration of function 'shary'
 [-Wimplicit-function-declaration]
   gc/int-inf.c:299:3: warning: nested extern declaration of 'shary'
 [-Wnested-externs]
   make[4]: *** [gc.o] Error 1

 A fix is available from upstream:

 https://github.com/caltry/mlton/commit/a658a1f4a76a01f568116598800f49b80cf8ee1a

 Attached is a patch to the package that incorporates this fix. I don't
 intend to upload it.

 Regards
 --
 Sebastian Ramacher

[PATCH] usb-serial: add support for USB Wishbone-serial adapters

[Wesley W. Terpstra]

Wishbone is an open hardware SoC bus commonly used in FPGA
designs. Bus access can be serialized using the Etherbone
protocol http://www.ohwr.org/projects/etherbone-core.

This driver is intended to be used with devices which attach
their internal Wishbone bus to a USB serial interface using
the Etherbone protocol. A userspace library is required to
speak the protocol made available by this driver as ttyUSBx.

Signed-off-by: Wesley W. Terpstra w.terps...@gsi.de
---
 drivers/usb/serial/Kconfig   |   17 ++
 drivers/usb/serial/Makefile  |1 +
 drivers/usb/serial/wishbone-serial.c |   95 ++
 3 files changed, 113 insertions(+)
 create mode 100644 drivers/usb/serial/wishbone-serial.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 17b7f9a..504f26e 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -667,6 +667,23 @@ config USB_SERIAL_ZIO
  To compile this driver as a module, choose M here: the
  module will be called zio.
 
+config USB_SERIAL_WISHBONE
+   tristate USB-Wishbone adapter interface driver
+   help
+ Say Y here if you want to use a USB attached Wishbone bus.
+
+ Wishbone is an open hardware SoC bus commonly used in FPGA
+ designs. Bus access can be serialized using the Etherbone
+ protocol http://www.ohwr.org/projects/etherbone-core.
+
+ This driver is intended to be used with devices which attach
+ their internal Wishbone bus to a USB serial interface using
+ the Etherbone protocol. A userspace library is required to
+ speak the protocol made available by this driver as ttyUSBx.
+
+ To compile this driver as a module, choose M here: the
+ module will be called wishbone-serial.
+
 config USB_SERIAL_ZTE
tristate ZTE USB serial driver
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index eaf5ca1..cec63fa 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_USB_SERIAL_SYMBOL)   += 
symbolserial.o
 obj-$(CONFIG_USB_SERIAL_WWAN)  += usb_wwan.o
 obj-$(CONFIG_USB_SERIAL_TI)+= ti_usb_3410_5052.o
 obj-$(CONFIG_USB_SERIAL_VISOR) += visor.o
+obj-$(CONFIG_USB_SERIAL_WISHBONE)  += wishbone-serial.o
 obj-$(CONFIG_USB_SERIAL_WHITEHEAT) += whiteheat.o
 obj-$(CONFIG_USB_SERIAL_XIRCOM)+= keyspan_pda.o
 obj-$(CONFIG_USB_SERIAL_VIVOPAY_SERIAL)+= vivopay-serial.o
diff --git a/drivers/usb/serial/wishbone-serial.c 
b/drivers/usb/serial/wishbone-serial.c
new file mode 100644
index 000..481ec66
--- /dev/null
+++ b/drivers/usb/serial/wishbone-serial.c
@@ -0,0 +1,95 @@
+/*
+ * USB Wishbone-Serial adapter driver
+ *
+ * Copyright (C) 2013 Wesley W. Terpstra w.terps...@gsi.de
+ * Copyright (C) 2013 GSI Helmholtz Centre for Heavy Ion Research GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/tty.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/usb/serial.h
+#include linux/uaccess.h
+
+#define GSI_VENDOR_OPENCLOSE 0xB0
+
+static const struct usb_device_id id_table[] = {
+   { USB_DEVICE_AND_INTERFACE_INFO(0x1D50, 0x6062, 0xFF, 0xFF, 0xFF) },
+   { },
+};
+MODULE_DEVICE_TABLE(usb, id_table);
+
+/*
+ * Etherbone must be told that a new stream has begun before data arrives.
+ * This is necessary to restart the negotiation of Wishbone bus parameters.
+ * Similarly, when the stream ends, Etherbone must be told so that the cycle
+ * line can be driven low in the case that userspace failed to do so.
+ */
+static int usb_gsi_openclose(struct usb_serial_port *port, int value)
+{
+   struct usb_device *dev = port-serial-dev;
+
+   return usb_control_msg(
+   dev,
+   usb_sndctrlpipe(dev, 0), /* Send to EP0OUT */
+   GSI_VENDOR_OPENCLOSE,
+   USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_INTERFACE,
+   value, /* wValue = device is open(1) or closed(0) */
+   port-serial-interface-cur_altsetting-desc.bInterfaceNumber,
+   0, 0,  /* There is no data stage */
+   5000); /* Timeout till operation fails */
+}
+
+static int wishbone_serial_open(struct tty_struct *tty,
+   struct usb_serial_port *port)
+{
+   int retval;
+
+   retval = usb_gsi_openclose(port, 1);
+   if (retval) {
+   dev_err(port-serial-dev-dev,
+  Could not mark device as open (%d)\n,
+  retval);
+   return retval

Re: [PATCH] usb-serial: add support for USB Wishbone-serial adapters

[Wesley W. Terpstra]

On Thu, 2013-04-11 at 06:45 -0700, Greg KH wrote:
 I only have one very minor question about the code:
 
  +++ b/drivers/usb/serial/wishbone-serial.c
  @@ -0,0 +1,95 @@
  +/*
  + * USB Wishbone-Serial adapter driver
  + *
  + * Copyright (C) 2013 Wesley W. Terpstra w.terps...@gsi.de
  + * Copyright (C) 2013 GSI Helmholtz Centre for Heavy Ion Research GmbH
  + *
  + * This program is free software; you can redistribute it and/or
  + * modify it under the terms of the GNU General Public License
  + * as published by the Free Software Foundation; either version 2
  + * of the License, or (at your option) any later version.
  + */
 
 Do you really mean or any later version for the license of this
 driver?  I ask as the kernel itself is GPLv2-only.  It's fine if you
 want this to be GPLv2+, I just have to ask.

Yes, I know the kernel is v2. Which is a shame because the FSF made the
v3 licence which some people would prefer. If in the distant future, the
kernel were to slowly be relicenced as v2+ or v3, I don't want to
contribute to the migration problem.

A question for you in turn: why were usb_serial_[de]register removed?
The new usb_serial_deregister_drivers isn't available in older kernels.
So drivers cannot support (without ifdefs) both old and new kernels


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb-serial: add support for USB Wishbone-serial adapters

[Wesley W. Terpstra]

On Thu, 2013-04-11 at 08:15 -0700, Greg KH wrote:
 Fair enough, although this driver would probably be the least of our
 worries if that were to happen :)
Of course.

 Documenation/stable_api_nonsense.txt
Tactfully named. :)

Is there a document that describes how to track the progress a patch
makes on its way to a released kernel version? I understand that
subsystem maintainers aggregate changes which then are aggregated in
turn by Linus, but beyond that I have no understanding of the flow.

Also: Thank you very much for all your help. I've made several kernel
modules over the years, but never submitted any of them for inclusion
because I had the (it seems false) impression that the linux kernel
development process was full of angry people who would make it
unpleasant.

Glad to learn that this is just a myth!
I will probably contribute more patches in the future.


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

USB-Wishbone bridge adapter

[Wesley W. Terpstra]

  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  5 USB-Wishbone Bridge
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86  EP 6 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass2 Communications
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)

/*
 * USB-WB adapter driver
 *
 *	This program is free software; you can redistribute it and/or
 *	modify it under the terms of the GNU General Public License version
 *	2 as published by the Free Software Foundation.
 */

#include linux/kernel.h
#include linux/init.h
#include linux/tty.h
#include linux/module.h
#include linux/usb.h
#include linux/usb/serial.h
#include linux/uaccess.h

#define GSI_VENDOR_OPENCLOSE 0xB0

static const struct usb_device_id id_table[] = {
	{ USB_DEVICE_AND_INTERFACE_INFO(0x1D50, 0x6062, 0xFF, 0xFF, 0xFF) },
	{ },
};
MODULE_DEVICE_TABLE(usb, id_table);

static struct usb_driver usb_wb_driver = {
	.name =		usb_wb,
	.probe =	usb_serial_probe,
	.disconnect =	usb_serial_disconnect,
	.id_table =	id_table,
	.no_dynamic_id =	1,
};

static int usb_wb_open(struct tty_struct *tty, struct usb_serial_port *port)
{
	struct usb_device *dev = port-serial-dev;
	int result;
	
	result = usb_control_msg(
		dev, 
		usb_sndctrlpipe(dev, 0), /* Send to EP0OUT */
		GSI_VENDOR_OPENCLOSE,
		USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_INTERFACE,
		1, /* wValue (2..3) = device is open */
		port-serial-interface-cur_altsetting-desc.bInterfaceNumber,
		0, 0,  /* no data stage */
		5000); /* timeout */
	
	if (result  0)
		dev_err(dev-dev, Could not mark device as open (result = %d)\n, result);
	
	return usb_serial_generic_open(tty, port);
}

static void usb_wb_close(struct usb_serial_port *port)
{
	struct usb_device *dev = port-serial-dev;
	int result;
	
	result = usb_control_msg(
		dev, 
		usb_sndctrlpipe(dev, 0), /* Send to EP0OUT */
		GSI_VENDOR_OPENCLOSE,
		USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_INTERFACE,
		0, /* wValue (2..3) = device is closed */
		port-serial-interface-cur_altsetting-desc.bInterfaceNumber,
		0, 0,  /* no data stage */
		5000); /* timeout */
	
	if (result  0)
		dev_err(dev-dev, Could not mark device as closed (result = %d)\n, result);
	
	return usb_serial_generic_close(port);
}

static struct usb_serial_driver usb_wb_device = {
	.driver = {
		.owner =	THIS_MODULE,
		.name =		usb_wb,
	},
	.id_table =		id_table,
	.usb_driver =		usb_wb_driver,
	.num_ports =		1,
	.open =			usb_wb_open,
	.close =		usb_wb_close,
};

static int __init usb_wb_init(void)
{
	int retval;

	retval = usb_serial_register(usb_wb_device);
	if (retval)
		return retval;
	retval = usb_register(usb_wb_driver);
	if (retval)
		usb_serial_deregister(usb_wb_device);
	return retval;
}

static void __exit usb_wb_exit(void)
{
	usb_deregister(usb_wb_driver);
	usb_serial_deregister(usb_wb_device);
}

MODULE_AUTHOR(Wesley W. Terpstra w.terps...@gsi.de);
MODULE_DESCRIPTION(Wishbone-USB adapter);
MODULE_LICENSE(GPL);

module_init(usb_wb_init);
module_exit(usb_wb_exit);

Re: USB-Wishbone bridge adapter

[Wesley W. Terpstra]

On Wed, 2013-04-10 at 19:01 +0200, Wesley W. Terpstra wrote:
 I've attached the output of lsusb -v
... and of course attached the output of an older version of the device.

The capabilities should read:
  CDC ACM:
bmCapabilities   0x02
  line coding and serial state
... otherwise it is the same.

I am not 100% certain if the CDC Call Management record should be
present in a non-modem device. This record may disappear once I've
clarified this detail of standard.


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB-Wishbone bridge adapter

[Wesley W. Terpstra]

On Wed, 2013-04-10 at 10:08 -0700, Greg KH wrote:
 On Wed, Apr 10, 2013 at 07:01:40PM +0200, Wesley W. Terpstra wrote:
  Greg, I've attached a small Linux driver which recognizes and the
  USB-Wishbone functionality of the device. It just adds two vendor
  messages to signal to the FPGA that the device has been opened. Please
  let me know what needs to be improved before it could be considered for
  inclusion in the kernel proper.
 
 You need to send it in a format that I can use to apply it (hint, read
 the file, Documentation/SubmittingPatches.)  If you do that, I will be
 glad to review it, and if all is good, apply it to the kernel tree.

Alrighty. I will prepare a patch version of it tomorrow.

Thanks.


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Piggy-backing new hardware using old usb-serial

[Wesley W. Terpstra]

On Thu, 2013-03-28 at 09:39 -0500, Dan Williams wrote:
 Greg's right, there's no reason not to use cdc-acm if you want to do
 that, since not all cdc-acm devices are modems.  If you get a USBIF
 vendor ID, then I'll happily add your device to the ModemManager probing
 blacklist too.

Yes, the cdc-acm approach has the distinct advantage of not having to
write one driver for each OS.

What does ModemManager probing consist of? Sending a few ATx commands to
see what the device is? On the interactive console that wouldn't hurt,
but on the proprietary data channel it could break things.

I assume that it poses no problem to the linux cdc enumeration if my
device reports two data interfaces (with two endpoints each).

Once I have added an interrupt endpoint and ignore the class specific
requests to meet the CDC-ACM interface and have a valid VID+PID pair,
I'll get back to you.

In case anyone else cares, I found some nice Dutch folks who resell PIDs
under their VID for cheap:
http://www.mcselec.com/index.php?page=shop.product_detailsflypage=shop.flypageproduct_id=92option=com_phpshopItemid=1

I will probably go this route for now.


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Piggy-backing new hardware using old usb-serial

[Wesley W. Terpstra]

Good evening,

We are developing a custom piece of hardware that provides the
equivalent of two serial console interfaces. They do not speak the AT
command set. One port provides an interactive console to the user for
configuration purposes (via minicom/etc). The other speaks a proprietary
protocol used by purpose-built userspace tools. Neither port has an
inherent baud rate limit; both can fully utilize USB2 bandwidth.

The closest standard USB-IF class I could find is the cdc-acm device
class. However, this seems to be very much targeted at modems with ATx
commands. The linux cdc-acm drivers would put the hardware
at /dev/ttyACM and software seems to treat these like modems. The closer
matching usb-serial dongles all appear to have unstandardized drivers.

We would like our hardware to work out of the box on released Linux
versions (and to a lesser extent on windows). Our current prototypes
borrow the Sierra VID to trick the kernel into loading the sierra
driver. This works well for the interactive console. However, I assume
that distributing the device like this will have legal consequences.

I could write a custom driver, but then end users need to compile
+install it. Our device will never be widely available and thus our
driver will never be included in linux, ie: even future users will have
to compile+install for themselves. Because the USB logic is inside an
FPGA, I can readily change the hardware to suite any existing driver.

What driver should I target?
Is there a way to AUTOload an older driver despite the new VID:PID?
Should I give up and require a custom driver?

Thank you for any and all feedback/advice.


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Piggy-backing new hardware using old usb-serial

[Wesley W. Terpstra]

On Wed, 2013-03-27 at 13:06 -0700, Greg KH wrote:
  Our current prototypes borrow the Sierra VID
 And the USB-IF might revoke your vendor id, if they find you shipping a
 device with a different vendor id than the one you have been assigned.

One of the reasons we borrowed that VID is that we do not currently have
a VID assigned. We are still deciding whether it is worth joining the
USB-IF just to get a vendor ID for a few thousands of devices.

I am of the opinion that it is, but I cannot sign the membership forms
on behalf of GSI. We probably will end up buying a VID soon.

 Why not just add your device id to an existing driver, sending in a
 patch to do so.  All distros will pick that up and then your device will
 just work on all Linux distros.

I was under the impression that drivers in the linux mainline had to be
for hardware that was widely available. I take it then, that just adding
support to an existing driver is acceptable?

That wouldn't address people with older linux distributions, but would
definitely be a good long term solution. It's really a shame there is no
USB-IF standard for usb-serial... then things would even potentially
work out of the box on windows.

  What driver should I target?
 What chip do you use for your device?

The device I am concerned about right now has an Altera arria2 connected
to a cy7c68013a-56baxc (fx2lp). We have several form factor variations.
A few have FTDI chips where I don't need to care, but can also do less.

 If you just want raw data, then do something like the
 drivers/usb/serial/zio.c driver, tiny, simple, and trivial.

Yes, if I make source-level changes to the kernel I have many options.

PS. Thank you for the very prompt reply!


--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

buildd.debian.org: Mipsel blacklist for package MLton

[Wesley W. Terpstra]

Package: buildd.debian.org
Severity: normal

Good evening!

The package 'MLton' needs a minimum of 1GB physical memory to compile.
Otherwise it will thrash in swap until killed. The mips buildd
recently tried to build this package on phrixos which only has 512MB.
Naturally, this failed [1]. Please add the package MLton to the
blacklist of any buildd with less than 512MB of main memory. All the
mips buildds seem to meet the 1GB threshold, so only mipsel is
affected.

These mipsel buildds are NOT OK:
  rem: 470MB (db.debian.org)
  phrixos: 512MB (as reported in build log [1])
  monteverdi: ??? unknown, no db.debian.org entry ???
These mipsel buildds are OK:
  mayer 1G (db.debian.org)
These machines are missing from db.debian.org:
  phrixos
  monteverdi

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mltonarch=mipselver=20100608-5stamp=1311251242


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caa-o0xjt2utvds4tcpkof-evmb7oupgt6g7vxz3l11zhxok...@mail.gmail.com

Bug#635004: buildd.debian.org: Mipsel blacklist for package MLton

[Wesley W. Terpstra]

Package: buildd.debian.org
Severity: normal

Good evening!

The package 'MLton' needs a minimum of 1GB physical memory to compile.
Otherwise it will thrash in swap until killed. The mips buildd
recently tried to build this package on phrixos which only has 512MB.
Naturally, this failed [1]. Please add the package MLton to the
blacklist of any buildd with less than 512MB of main memory. All the
mips buildds seem to meet the 1GB threshold, so only mipsel is
affected.

These mipsel buildds are NOT OK:
  rem: 470MB (db.debian.org)
  phrixos: 512MB (as reported in build log [1])
  monteverdi: ??? unknown, no db.debian.org entry ???
These mipsel buildds are OK:
  mayer 1G (db.debian.org)
These machines are missing from db.debian.org:
  phrixos
  monteverdi

[1] 
https://buildd.debian.org/status/fetch.php?pkg=mltonarch=mipselver=20100608-5stamp=1311251242



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Accepted mlton 20100608-5 (source all amd64)

[Wesley W. Terpstra (Debian)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 19 Jul 2011 12:29:52 +0200
Source: mlton
Binary: mlton mlton-basis mlton-doc mlton-compiler mlton-tools 
mlton-runtime-native mlton-runtime-alpha-linux-gnu 
mlton-runtime-x86-64-linux-gnu mlton-runtime-arm-linux-gnueabi 
mlton-runtime-arm-linux-gnueabihf mlton-runtime-hppa-linux-gnu 
mlton-runtime-i486-gnu mlton-runtime-i486-linux-gnu 
mlton-runtime-ia64-linux-gnu mlton-runtime-i486-kfreebsd-gnu 
mlton-runtime-x86-64-kfreebsd-gnu mlton-runtime-mips-linux-gnu 
mlton-runtime-mipsel-linux-gnu mlton-runtime-powerpc-linux-gnu 
mlton-runtime-s390-linux-gnu mlton-runtime-sparc-linux-gnu
Architecture: source all amd64
Version: 20100608-5
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org
Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org
Description: 
 mlton  - Optimizing compiler for Standard ML
 mlton-basis - Optimizing compiler for Standard ML - basis library
 mlton-compiler - Optimizing compiler for Standard ML - compiler
 mlton-doc  - Optimizing compiler for Standard ML - documentation
 mlton-runtime-alpha-linux-gnu - Optimizing compiler for Standard ML - alpha 
runtime libraries
 mlton-runtime-arm-linux-gnueabi - Optimizing compiler for Standard ML - armel 
runtime libraries
 mlton-runtime-arm-linux-gnueabihf - Optimizing compiler for Standard ML - 
armhf runtime libraries
 mlton-runtime-hppa-linux-gnu - Optimizing compiler for Standard ML - hppa 
runtime libraries
 mlton-runtime-i486-gnu - Optimizing compiler for Standard ML - hurd-i386 
runtime libraries
 mlton-runtime-i486-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-i386 runtime libra
 mlton-runtime-i486-linux-gnu - Optimizing compiler for Standard ML - i386 
runtime libraries
 mlton-runtime-ia64-linux-gnu - Optimizing compiler for Standard ML - ia64 
runtime libraries
 mlton-runtime-mips-linux-gnu - Optimizing compiler for Standard ML - mips 
runtime libraries
 mlton-runtime-mipsel-linux-gnu - Optimizing compiler for Standard ML - mipsel 
runtime libraries
 mlton-runtime-native - Optimizing compiler for Standard ML - native runtime 
libraries
 mlton-runtime-powerpc-linux-gnu - Optimizing compiler for Standard ML - 
powerpc runtime libraries
 mlton-runtime-s390-linux-gnu - Optimizing compiler for Standard ML - s390 
runtime libraries
 mlton-runtime-sparc-linux-gnu - Optimizing compiler for Standard ML - sparc 
runtime libraries
 mlton-runtime-x86-64-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-amd64 runtime libr
 mlton-runtime-x86-64-linux-gnu - Optimizing compiler for Standard ML - amd64 
runtime libraries
 mlton-tools - Optimizing compiler for Standard ML - tools
Changes: 
 mlton (20100608-5) unstable; urgency=low
 .
   * Newest gcc and binutils fix mips[el] jump problem
* Uploaded mips[el] bootstrap packages as 20100608-4
* Build-Depend on newest gcc and binutils
* Removed explicit-relocs patch
   * Include a diffs to current release head
* Necessary for 8-bit aligned MIPS read/writes
* Increase heap-size for mips post-alignment
   * Building armel on debian buildd instead of qemu
* Heap-size 1.2g on 1.5g machines
   * Added armhf port
Checksums-Sha1: 
 1bb029fdde1e2a3d5f756aa5ec1ce96c6c566a72 1825 mlton_20100608-5.dsc
 bfc3b15bfd5d02fa691dba3b4e17009ea85a5e33 26927 mlton_20100608-5.debian.tar.gz
 d60c8324acf9f26f06bed29038b28719949dc4be 39610 mlton_20100608-5_all.deb
 868685a90f891005a38c47bba90ccbd734e8cf0f 2099252 mlton-basis_20100608-5_all.deb
 0fd6a73ed031e194b93437b0ec70069e28d68eb0 3534262 mlton-doc_20100608-5_all.deb
 649473310228343e5c8d26b3db6719576b97c9aa 4556928 
mlton-compiler_20100608-5_amd64.deb
 d334c82958d847ecaf9a794a220dad980f5bdaab 1597894 
mlton-tools_20100608-5_amd64.deb
 51c171b7b0e2051001573893363d15686cb86d72 38670 
mlton-runtime-native_20100608-5_amd64.deb
 98f2edae948952f4255b9cf97365e3dfa74bb51f 502332 
mlton-runtime-x86-64-linux-gnu_20100608-5_amd64.deb
Checksums-Sha256: 
 178fe1b64a8929ca171f688cfd3903180572776397a6d95a4f64677dd5d08bd2 1825 
mlton_20100608-5.dsc
 1594177e42385820fa3ce3d2e8749f11cd87ee7d07e84cae1ea785821ef93198 26927 
mlton_20100608-5.debian.tar.gz
 bc83fcfa96701c4e6f65c545ea988781f35932d534983d88bc795d2aee0a2032 39610 
mlton_20100608-5_all.deb
 ca0069da9f1706747b00fb0e4e777e010cd9d6686698348a9f7e0a4ade82be2c 2099252 
mlton-basis_20100608-5_all.deb
 1ff0dcd8139582b43078e271a8aa478391f6f7b80980f8734b2d15ed430b3268 3534262 
mlton-doc_20100608-5_all.deb
 ceac6442ad85acd897fd8361101f5a2321b615d3ba6eb82e05b470d01ec3e4c8 4556928 
mlton-compiler_20100608-5_amd64.deb
 03db0f6949b2f7d035ec62869e3b2749fd15d19d9d55c3785283900ccde775cf 1597894 
mlton-tools_20100608-5_amd64.deb
 bf0c78cda2e64137b90a3ced9f91d152bdbd85ccc064e999eb857fabdde6f5c6 38670 
mlton-runtime-native_20100608-5_amd64.deb
 1c1c6f1394a25d30ef1e5795c370db0a691c91e1066e86a43f1bd0e76654dc00 502332 
mlton-runtime-x86-64-linux-gnu_20100608-5_amd64.deb
Files

Re: [Qemu-devel] qemu-user[armel/mips] and debian-rootfs

[Wesley W. Terpstra]

2011/7/11 Riku Voipio riku.voi...@iki.fi:
 On Mon, Jul 11, 2011 at 11:10:50AM -0300, Lisandro Damián Nicanor Pérez Meyer 
 wrote:
 Thanks Riku! This bug has already been solved by Wesley Terpstra:

 http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg00313.html

 Ok, I missed these patches. Will adjust the linux-user patchset to include
 these patches if no bugs found in them.

Just a heads up---if you only use my original patch, mipseb still
won't be able to run 'make'.
My final patchset (sent as a series of 6 patches) resolves this in
addition to the other problems.

[Qemu-devel] Best qemu ARM board supporting 1G+ ?

[Wesley W. Terpstra]

Greetings.

I have a arm/versatileab running debian/sid, but this only has access
to 256MB of main memory. For my current project I need a minimum of
1GB. I know that the realview-pbx-a9 can do this, but am unsure how
well its supported.

1. Which qemu ARM boards support = 1GB of memory?

2. Which of those can run a linux kernel reliably enough to host debian?

Thanks!

[Qemu-devel] [PATCH 1/6] mips: sigaltstack args

[Wesley W. Terpstra]

The syscall sigaltstack takes two parameters, not zero. This patch
should have no impact as only values above 4 influence the runtime
behaviour. Nevertheless, it is wrong.

Signed-off-by: Wesley W. Terpstra terps...@debian.org
---

diff --git a/linux-user/main.c b/linux-user/main.c
index 289054b..26ebc73 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -1875,7 +1875,7 @@ static const uint8_t mips_syscall_args[] = {
 MIPS_SYS(sys_getcwd    , 2)
 MIPS_SYS(sys_capget    , 2)
 MIPS_SYS(sys_capset    , 2)    /* 4205 */
-    MIPS_SYS(sys_sigaltstack    , 0)
+    MIPS_SYS(sys_sigaltstack    , 2)
 MIPS_SYS(sys_sendfile    , 4)
 MIPS_SYS(sys_ni_syscall    , 0)
 MIPS_SYS(sys_ni_syscall    , 0)
diff --git a/linux-user/main.c b/linux-user/main.c
index 289054b..26ebc73 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -1875,7 +1875,7 @@ static const uint8_t mips_syscall_args[] = {
 	MIPS_SYS(sys_getcwd	, 2)
 	MIPS_SYS(sys_capget	, 2)
 	MIPS_SYS(sys_capset	, 2)	/* 4205 */
-	MIPS_SYS(sys_sigaltstack	, 0)
+	MIPS_SYS(sys_sigaltstack	, 2)
 	MIPS_SYS(sys_sendfile	, 4)
 	MIPS_SYS(sys_ni_syscall	, 0)
 	MIPS_SYS(sys_ni_syscall	, 0)

[Qemu-devel] [PATCH 3/6] mips: null pointer deref should segfault

[Wesley W. Terpstra]

Dereferencing a null pointer causes an exception 0xC (EXCP_AdEL)
instead of EXCP_TLBL. This should also trigger a segfault.

Signed-off-by: Wesley W. Terpstra terps...@debian.org
---

diff --git a/linux-user/main.c b/linux-user/main.c
index 289054b..26ebc73 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2093,6 +2107,8 @@ void cpu_loop(CPUMIPSState *env)
 break;
 case EXCP_TLBL:
 case EXCP_TLBS:
+case EXCP_AdEL:
+case EXCP_AdES:
 info.si_signo = TARGET_SIGSEGV;
 info.si_errno = 0;
 /* XXX: check env-error_code */
diff --git a/linux-user/main.c b/linux-user/main.c
index 289054b..26ebc73 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2093,6 +2107,8 @@ void cpu_loop(CPUMIPSState *env)
 break;
 case EXCP_TLBL:
 case EXCP_TLBS:
+case EXCP_AdEL:
+case EXCP_AdES:
 info.si_signo = TARGET_SIGSEGV;
 info.si_errno = 0;
 /* XXX: check env-error_code */

[Qemu-devel] [PATCH 2/6] mips: missing syscall returns wrong errno

[Wesley W. Terpstra]

Return -TARGET_ENOSYS instead of -ENOSYS from linux-user/main.c
   * Caused strange 'Level 2 synchronization messages' instead of
correctly reporting the syscall was missing.
   * Made glibc simply fail instead of using older syscalls

Signed-off-by: Wesley W. Terpstra terps...@debian.org
---

diff --git a/linux-user/main.c b/linux-user/main.c
index 289054b..26ebc73 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2053,7 +2067,7 @@ void cpu_loop(CPUMIPSState *env)
 syscall_num = env-active_tc.gpr[2] - 4000;
 env-active_tc.PC += 4;
 if (syscall_num = sizeof(mips_syscall_args)) {
-ret = -ENOSYS;
+ret = -TARGET_ENOSYS;
 } else {
 int nb_args;
 abi_ulong sp_reg;
diff --git a/linux-user/main.c b/linux-user/main.c
index 289054b..26ebc73 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -2053,7 +2067,7 @@ void cpu_loop(CPUMIPSState *env)
 syscall_num = env-active_tc.gpr[2] - 4000;
 env-active_tc.PC += 4;
 if (syscall_num = sizeof(mips_syscall_args)) {
-ret = -ENOSYS;
+ret = -TARGET_ENOSYS;
 } else {
 int nb_args;
 abi_ulong sp_reg;

[Qemu-devel] [PATCH 6/6] mips: eabi syscall support for 64-bit args

[Wesley W. Terpstra]

mips uses the eabi calling convention. For 64-bit values this means
some registers are skipped. This patch replicates the behaviour of
arm/eabi for mips targets.
This affects ftruncate64, creating insane sized fails (or just failing).

Signed-off-by: Wesley W. Terpstra terps...@debian.org
---

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fed7a8f..0b0a3d0 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4367,6 +4367,10 @@
 arg3 = arg4;
   }
 #endif
+#ifdef TARGET_MIPS
+arg2 = arg3;
+arg3 = arg4;
+#endif
 return get_errno(truncate64(arg1, target_offset64(arg2, arg3)));
 }
 #endif
@@ -4384,6 +4388,10 @@
 arg3 = arg4;
   }
 #endif
+#ifdef TARGET_MIPS
+arg2 = arg3;
+arg3 = arg4;
+#endif
 return get_errno(ftruncate64(arg1, target_offset64(arg2, arg3)));
 }
 #endif
@@ -6841,6 +6849,9 @@
 if (((CPUARMState *)cpu_env)-eabi)
 arg4 = arg5;
 #endif
+#ifdef TARGET_MIPS
+arg4 = arg5;
+#endif
 if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
 goto efault;
 ret = get_errno(pread(arg1, p, arg3, arg4));
@@ -6851,6 +6862,9 @@
 if (((CPUARMState *)cpu_env)-eabi)
 arg4 = arg5;
 #endif
+#ifdef TARGET_MIPS
+arg4 = arg5;
+#endif
 if (!(p = lock_user(VERIFY_READ, arg2, arg3, 1)))
 goto efault;
 ret = get_errno(pwrite(arg1, p, arg3, arg4));
@@ -7609,6 +7623,11 @@
 arg4 = arg5;
 }
 #endif
+#ifdef TARGET_MIPS
+arg2 = arg3;
+arg3 = arg4;
+arg4 = arg5;
+#endif
 ret = get_errno(readahead(arg1, ((off64_t)arg3  32) | arg2, arg4));
 #else
 ret = get_errno(readahead(arg1, arg2, arg3));
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fed7a8f..0b0a3d0 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4367,6 +4367,10 @@
 arg3 = arg4;
   }
 #endif
+#ifdef TARGET_MIPS
+arg2 = arg3;
+arg3 = arg4;
+#endif
 return get_errno(truncate64(arg1, target_offset64(arg2, arg3)));
 }
 #endif
@@ -4384,6 +4388,10 @@
 arg3 = arg4;
   }
 #endif
+#ifdef TARGET_MIPS
+arg2 = arg3;
+arg3 = arg4;
+#endif
 return get_errno(ftruncate64(arg1, target_offset64(arg2, arg3)));
 }
 #endif
@@ -6841,6 +6849,9 @@
 if (((CPUARMState *)cpu_env)-eabi)
 arg4 = arg5;
 #endif
+#ifdef TARGET_MIPS
+arg4 = arg5;
+#endif
 if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0)))
 goto efault;
 ret = get_errno(pread(arg1, p, arg3, arg4));
@@ -6851,6 +6862,9 @@
 if (((CPUARMState *)cpu_env)-eabi)
 arg4 = arg5;
 #endif
+#ifdef TARGET_MIPS
+arg4 = arg5;
+#endif
 if (!(p = lock_user(VERIFY_READ, arg2, arg3, 1)))
 goto efault;
 ret = get_errno(pwrite(arg1, p, arg3, arg4));
@@ -7609,6 +7623,11 @@
 arg4 = arg5;
 }
 #endif
+#ifdef TARGET_MIPS
+arg2 = arg3;
+arg3 = arg4;
+arg4 = arg5;
+#endif
 ret = get_errno(readahead(arg1, ((off64_t)arg3  32) | arg2, arg4));
 #else
 ret = get_errno(readahead(arg1, arg2, arg3));

[Qemu-devel] [PATCH 4/6] mips: rlimit incorrectly converts values

[Wesley W. Terpstra]

Byte swap was applied in the wrong order with testing for
RLIM_INFINITY. On mips bigendian from an amd64 system this results in
infinity being misinterpretted as 2^31-1.

This is a serious bug because it causes setrlimit stack size to kill
all child processes. This means (for example) that 'make' can run no
children. The mechanism of failure:
1. parent sets stack size rlimit to 'infinity'
2. qemu screws this value up
3. child process fetches stack size as a large (but non-infinite) value
4. qemu tries to allocate stack before execution
5. stack allocation fails (too big) and child process dies

Signed-off-by: Wesley W. Terpstra terps...@debian.org
---

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fed7a8f..0b0a3d0 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -919,18 +919,30 @@ static inline abi_long
host_to_target_rusage(abi_ulong target_addr,

 static inline rlim_t target_to_host_rlim(target_ulong target_rlim)
 {
-if (target_rlim == TARGET_RLIM_INFINITY)
-return RLIM_INFINITY;
+target_ulong target_rlim_swap;
+rlim_t result;
+
+target_rlim_swap = tswapl(target_rlim);
+if (target_rlim_swap == TARGET_RLIM_INFINITY || target_rlim_swap
!= (rlim_t)target_rlim_swap)
+result = RLIM_INFINITY;
 else
-return tswapl(target_rlim);
+result = target_rlim_swap;
+
+return result;
 }

 static inline target_ulong host_to_target_rlim(rlim_t rlim)
 {
+target_ulong target_rlim_swap;
+target_ulong result;
+
 if (rlim == RLIM_INFINITY || rlim != (target_long)rlim)
-return TARGET_RLIM_INFINITY;
+target_rlim_swap = TARGET_RLIM_INFINITY;
 else
-return tswapl(rlim);
+target_rlim_swap = rlim;
+result = tswapl(target_rlim_swap);
+
+return result;
 }

 static inline abi_long copy_from_user_timeval(struct timeval *tv,
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fed7a8f..0b0a3d0 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -919,18 +919,30 @@ static inline abi_long host_to_target_rusage(abi_ulong target_addr,
 
 static inline rlim_t target_to_host_rlim(target_ulong target_rlim)
 {
-if (target_rlim == TARGET_RLIM_INFINITY)
-return RLIM_INFINITY;
+target_ulong target_rlim_swap;
+rlim_t result;
+
+target_rlim_swap = tswapl(target_rlim);
+if (target_rlim_swap == TARGET_RLIM_INFINITY || target_rlim_swap != (rlim_t)target_rlim_swap)
+result = RLIM_INFINITY;
 else
-return tswapl(target_rlim);
+result = target_rlim_swap;
+
+return result;
 }
 
 static inline target_ulong host_to_target_rlim(rlim_t rlim)
 {
+target_ulong target_rlim_swap;
+target_ulong result;
+
 if (rlim == RLIM_INFINITY || rlim != (target_long)rlim)
-return TARGET_RLIM_INFINITY;
+target_rlim_swap = TARGET_RLIM_INFINITY;
 else
-return tswapl(rlim);
+target_rlim_swap = rlim;
+result = tswapl(target_rlim_swap);
+
+return result;
 }
 
 static inline abi_long copy_from_user_timeval(struct timeval *tv,

[Qemu-devel] [PATCH 5/6] mips: rlimit codes are not the same

[Wesley W. Terpstra]

The codes for get/setrlimit differ between linux target platforms.
This patch adds conversion.
This is important else programs (rsyslog, python, ...) can go into a
near infinite loop trying to close all the file descriptors from 0 to
-1.

Signed-off-by: Wesley W. Terpstra terps...@debian.org
---

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fed7a8f..2011e66 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -945,6 +945,44 @@
 return result;
 }

+static inline int target_to_host_resource(int code)
+{
+switch (code) {
+case TARGET_RLIMIT_AS:
+return RLIMIT_AS;
+case TARGET_RLIMIT_CORE:
+return RLIMIT_CORE;
+case TARGET_RLIMIT_CPU:
+return RLIMIT_CPU;
+case TARGET_RLIMIT_DATA:
+return RLIMIT_DATA;
+case TARGET_RLIMIT_FSIZE:
+return RLIMIT_FSIZE;
+case TARGET_RLIMIT_LOCKS:
+return RLIMIT_LOCKS;
+case TARGET_RLIMIT_MEMLOCK:
+return RLIMIT_MEMLOCK;
+case TARGET_RLIMIT_MSGQUEUE:
+return RLIMIT_MSGQUEUE;
+case TARGET_RLIMIT_NICE:
+return RLIMIT_NICE;
+case TARGET_RLIMIT_NOFILE:
+return RLIMIT_NOFILE;
+case TARGET_RLIMIT_NPROC:
+return RLIMIT_NPROC;
+case TARGET_RLIMIT_RSS:
+return RLIMIT_RSS;
+case TARGET_RLIMIT_RTPRIO:
+return RLIMIT_RTPRIO;
+case TARGET_RLIMIT_SIGPENDING:
+return RLIMIT_SIGPENDING;
+case TARGET_RLIMIT_STACK:
+return RLIMIT_STACK;
+default:
+return code;
+}
+}
+
 static inline abi_long copy_from_user_timeval(struct timeval *tv,
   abi_ulong target_tv_addr)
 {
@@ -,7 +5593,7 @@
 break;
 case TARGET_NR_setrlimit:
 {
-int resource = arg1;
+int resource = target_to_host_resource(arg1);
 struct target_rlimit *target_rlim;
 struct rlimit rlim;
 if (!lock_user_struct(VERIFY_READ, target_rlim, arg2, 1))
@@ -5568,7 +5606,7 @@
 break;
 case TARGET_NR_getrlimit:
 {
-int resource = arg1;
+int resource = target_to_host_resource(arg1);
 struct target_rlimit *target_rlim;
 struct rlimit rlim;

@@ -6872,7 +6910,8 @@
 case TARGET_NR_ugetrlimit:
 {
struct rlimit rlim;
-   ret = get_errno(getrlimit(arg1, rlim));
+   int resource = target_to_host_resource(arg1);
+   ret = get_errno(getrlimit(resource, rlim));
if (!is_error(ret)) {
struct target_rlimit *target_rlim;
 if (!lock_user_struct(VERIFY_WRITE, target_rlim, arg2, 0))
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 04c268d..6ec9c31 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -693,6 +693,40 @@ struct target_rlimit {
 #define TARGET_RLIM_INFINITY   ((target_ulong)~0UL)
 #endif

+#if defined(TARGET_MIPS)
+#define TARGET_RLIMIT_CPU  0
+#define TARGET_RLIMIT_FSIZE1
+#define TARGET_RLIMIT_DATA 2
+#define TARGET_RLIMIT_STACK3
+#define TARGET_RLIMIT_CORE 4
+#define TARGET_RLIMIT_RSS  7
+#define TARGET_RLIMIT_NPROC8
+#define TARGET_RLIMIT_NOFILE   5
+#define TARGET_RLIMIT_MEMLOCK  9
+#define TARGET_RLIMIT_AS   6
+#define TARGET_RLIMIT_LOCKS10
+#define TARGET_RLIMIT_SIGPENDING   11
+#define TARGET_RLIMIT_MSGQUEUE 12
+#define TARGET_RLIMIT_NICE 13
+#define TARGET_RLIMIT_RTPRIO   14
+#else
+#define TARGET_RLIMIT_CPU  0
+#define TARGET_RLIMIT_FSIZE1
+#define TARGET_RLIMIT_DATA 2
+#define TARGET_RLIMIT_STACK3
+#define TARGET_RLIMIT_CORE 4
+#define TARGET_RLIMIT_RSS  5
+#define TARGET_RLIMIT_NPROC6
+#define TARGET_RLIMIT_NOFILE   7
+#define TARGET_RLIMIT_MEMLOCK  8
+#define TARGET_RLIMIT_AS   9
+#define TARGET_RLIMIT_LOCKS10
+#define TARGET_RLIMIT_SIGPENDING   11
+#define TARGET_RLIMIT_MSGQUEUE 12
+#define TARGET_RLIMIT_NICE 13
+#define TARGET_RLIMIT_RTPRIO   14
+#endif
+
 struct target_pollfd {
 int fd;   /* file descriptor */
 short events; /* requested events */
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fed7a8f..2011e66 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -945,6 +945,44 @@
 return result;
 }
 
+static inline int target_to_host_resource(int code)
+{
+switch (code) {
+case TARGET_RLIMIT_AS:
+return RLIMIT_AS;
+case TARGET_RLIMIT_CORE:
+return RLIMIT_CORE;
+case TARGET_RLIMIT_CPU:
+return RLIMIT_CPU;
+case TARGET_RLIMIT_DATA:
+return RLIMIT_DATA;
+case TARGET_RLIMIT_FSIZE:
+return RLIMIT_FSIZE;
+case TARGET_RLIMIT_LOCKS:
+return RLIMIT_LOCKS;
+case TARGET_RLIMIT_MEMLOCK

[Qemu-devel] PATCH: fix qemu-mips[el]-static to work with debian squeeze/sid chroot

[Wesley W. Terpstra]

I also recently tried to get a mipsel debian/sid chroot running under my
amd64/squeeze system. As posted by Lisandro earlier this month, it didn't
work. ;-) There are several problems, the most glaring of which the attached
patch fixes. I'll break down the changes:

1. Return -TARGET_ENOSYS instead of -ENOSYS from linux-user/main.c
   * Caused the strange 'Level 2 synchronization messages' instead of
correctly reporting the syscall was missing.
   * Made glibc simply fail instead of using older syscalls (one important
example is the new setrlimit syscall which qemu lacks and gnupg/apt needs)

2. The mips syscall table wasn't kept in-sync with syscall.c
   * utimensat was missing (and the cause of the ENOSYS error Lisandro was
seeing)
   * Although I didn't run into problems with any other syscalls, I updated
the table to match syscall.c as well I could anyway

3. Dereferencing a null pointer causes an exception 0xC (EXCP_AdEL) instead
of EXCP_TLBL. This should also trigger a segfault.

4. The codes for get/setrlimit do not stay constant between linux target
platforms. I added a conversion method. This is important else programs
(rsyslog, python, ...) can go into a near infinite loop trying to close all
the file descriptors from 0 to -1.

5. 64-bit file system calls were failing on mipsel (ftruncate 888 created
files 888*4GB large). arm had already work-around code for EABI which also
worked for mipsel, so I just added the same code path for mips everywhere
arm eabi has it. Works for both little and big endian.

These changes were enough to get a mostly working debian chroot for me. I
did have to install squeeze first and then dist-upgrade to sid, however, as
debootstrap seems to have problems with the new multilib glibc (dist-upgrade
will install it fine, though).

To setup a mipsel chroot in /media with the patch applied:
apt-get install qemu-user-static binfmt-support debootstrap
debootstrap --foreign --arch=mipsel squeeze /media/mipsel-sid
compile qemu with patch
cp qemu-srcdir/mipsel-user-static /media/mipsel-sid/usr/bin
chroot /media/mipsel-sid
/debootstrap/debootstrap --second-stage
echo deb http://ftp.de.debian.org/debian sid main  /etc/apt/sources.list
apt-get update
apt-get install locales
mount devpts /dev/pts -t devpts
mount proc /proc -t proc
mount sys /sys -t sysfs
dpkg-reconfigure locales
apt-get dist-upgrade
... install whatever else you need ...

There is still some problem where gcc 4.6.1 in the chroot can ICE when
handling floating point code. I'm looking into it.

I would appreciate it if these fixes could be merged upstream. Thanks.
*
*


qemu-mipsel-debian-rootfs.patch.gz
Description: GNU Zip compressed data

Re: [Milkymist-devel] MMU

[Wesley W. Terpstra]

On 23/04/11 12:55 PM, Sebastien Bourdeauducq wrote:

b) Use a simple cache with cache associativity * page size = cache size.
Advantages: simple hardware, and solves above problems.
Half the point of the LM32 is the sweet-spot in speed/size that it hits. 
This approach to an MMU lives at a similar design sweet-spot. I am for it.



Problems: a bit
less flexible, and if we do not want to flush caches at context switches
we must ensure that shared memory areas are mapped at the same virtual
addresses in all processes that use it.


I don't believe you are correct. As long as:
   [associativity]*[page size] = [cache size]
there should be no problem.

There are only two possible issues that can happen in the cache:

1) Multiple physical addresses map to one virtual address

This is solved by using physical tagging.

2) Multiple virtual addresses map to one physical address

This is solved by the above restriction on cache size.

To be concrete, imagine a shared page. The operating system will only 
ever map a page aligned (ie: a 4k page won't live offset at position 
2k). Any access to the shared page will use the same low bits index into 
that page (12 bits in our example). Supposing a 16k cache, that means 
that the page can only have four aliasing locations (the highest 2 bits 
of the 16k cache's index). With an associativity of 4, that means the 
cache sees all aliasing when it issues an update/fetch. Thus, there is 
no problem.


Conclusion: you don't need to ever flush cache and there are no issues.

The approach you are proposing (using the OS to ensure the address 
match) is useful when you want to BREAK the assumption of 
[associativity]*[page size] = [cache size]; ie: you want a bigger 
cache. Then you can use the OS to limit the number of potential aliases 
below the limit.


For example, 4-way associative 64k cache with a 4k page size. Now your 
address indexes into the cache use log(64k/4) = 14 bits compared to the 
page size of 12 bits. The OS can ensure there are no problems if it 
makes sure that all mappings of a shared page agree on bits 13 and 14. 
If the cache had only been 16k there would be no bits for the OS to 
enforce agreement on.


___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
Twitter: www.twitter.com/milkymistvj
Ideas? http://milkymist.uservoice.com

Re: [Milkymist-devel] MMU

[Wesley W. Terpstra]

Although I've already mentioned there are absolutely no problems with a 
VIPT mmu/cache design under the cache-size assumption Sebastien worked 
with, there is *also* no problem with exceeding this cache-size 
restriction for an operating system like linux. I'll explain why below.


On 25/04/11 07:18 PM, Norman Feske wrote:

In general, this is a rather unwelcome restriction. E.g., look at the
mmap syscall on Linux, which enables each process to map (potentially
different parts of) the same file at (potentially multiple) virtual
address regions. Of course, multiple processes may do so for the same
file.
Linux does *not* allow you map pages wherever you like. The mmap syscall 
is free to reject every proposed location you suggest. Just try any 
unaligned address; they will all fail. To ensure that file-backed mmap 
doesn't lead to inconsistent caching, linux just has to increase the 
required alignment.


For example, suppose a 64k cache 4-way associative cache with a 4k page 
size. Now, linux just has to make sure that every mapping of that 
file-backed page match on bits 13 and 14. This can be achieved by mmap 
requiring 16k alignment to the file offset, a perfectly permissible 
restriction according to POSIX.

I acknowledge your reservations against a physically indexed cache.
A physically indexed cache would require us to add a new pipeline stage 
in the LM32. That would require a complete redesign of the CPU.


___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
Twitter: www.twitter.com/milkymistvj
Ideas? http://milkymist.uservoice.com

Either as or ld produce a bad jump on mips eabi

[Wesley W. Terpstra]

Good evening, on and off for years, I've been bitten by a miscompilation of
'goto' on the mips target. I finally isolated it into a single test-case
that I can report. I believe this bug to be at least 6 years old and it is
still present in version 2.18.1~cvs20080103-7 (as used in debian/sid).

The problem boils down to these assembler constructs which SHOULD behave the
same as I understand it:
  sw $3,%lo(nextFun)($2)
- lw $1,%got($L894)($28)
+ lui $1,%hi($L894)
  nop
  addiu $1,$1,%lo($L894)
  jr $1
The '%got' variant which is used by default on EABI will lead to a
segmentation fault. I suspect the problem is related to (at least) two
facts: the entire method is over 64kB large and the jumps that get
miscompiled are 'near' a 64kB boundary.

I have put up a tarball with the miscompiled assembler, the original C file,
and a library sufficient to link the final program at: 
http://www.terpstra.ca/debian/bad-goto.tar.gz.

If you want to blame gcc (though i think the assembler it generated is
valid) here is how to rebuild the assembler:
gcc -std=gnu99 -O0 -g -w -fno-strict-aliasing mlyacc.6.preprocessed.c -S -o
mlyacc.6.preprocessed.s

To link the two alternatives:
gcc -o ok mlyacc.6.preprocessed.ok.s link.a -lgmp -lm
gcc -o bad mlyacc.6.preprocessed.bad.s link.a -lgmp -lm
... the gmp version used here is 5.0.1+dfsg-7 from debian sid.
... the glibc version is 2.11.2-11 (again from debian sid)

To observe the bad jump:
gdb ./bad
break mlyacc.6.preprocessed.c:2915
run
Breakpoint 1, Chunk6 () at mlyacc.6.preprocessed.c:2915
2915 *(Word8*)(stackTop + (60)) = (Word8)(Word8)0x0;
(gdb) s
2916 *(CPointer*)(stackTop + (56)) = 25;
(gdb)
2917 do { if (0) fprintf (stderr, %s:%d: Push (%d)\n, mlyacc.6.c,
912, 60); stackTop += (60); } while (0);
(gdb)
2919 cont.nextChunk = (void*)Chunk0;
(gdb)
2920 nextFun = 2736; }
(gdb)
2922 goto leaveChunk;  /* !!! This jump goes the wrong way !!! */
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x2aabead0 in _dl_check_caller (caller=0x0, mask=0) at dl-caller.c:39
39 dl-caller.c: No such file or directory.
in dl-caller.c

If you run the same sequence on 'gdb ./ok' the program will proceed past the
bad jump and die at the next bad jump. (Yes, in this file there are multiple
jumps which get miscompiled. mlyacc.6.preprocessed.ok.s only has the first
jump corrected.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Accepted mlton 20100608-4 (source all i386)

[Wesley W. Terpstra (Debian)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 01 Apr 2011 22:57:25 +0200
Source: mlton
Binary: mlton mlton-basis mlton-doc mlton-compiler mlton-tools 
mlton-runtime-native mlton-runtime-alpha-linux-gnu 
mlton-runtime-x86-64-linux-gnu mlton-runtime-arm-linux-gnueabi 
mlton-runtime-hppa-linux-gnu mlton-runtime-i486-gnu 
mlton-runtime-i486-linux-gnu mlton-runtime-ia64-linux-gnu 
mlton-runtime-i486-kfreebsd-gnu mlton-runtime-x86-64-kfreebsd-gnu 
mlton-runtime-mips-linux-gnu mlton-runtime-mipsel-linux-gnu 
mlton-runtime-powerpc-linux-gnu mlton-runtime-s390-linux-gnu 
mlton-runtime-sparc-linux-gnu
Architecture: source all i386
Version: 20100608-4
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org
Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org
Description: 
 mlton  - Optimizing compiler for Standard ML
 mlton-basis - Optimizing compiler for Standard ML - basis library
 mlton-compiler - Optimizing compiler for Standard ML - compiler
 mlton-doc  - Optimizing compiler for Standard ML - documentation
 mlton-runtime-alpha-linux-gnu - Optimizing compiler for Standard ML - alpha 
runtime libraries
 mlton-runtime-arm-linux-gnueabi - Optimizing compiler for Standard ML - armel 
runtime libraries
 mlton-runtime-hppa-linux-gnu - Optimizing compiler for Standard ML - hppa 
runtime libraries
 mlton-runtime-i486-gnu - Optimizing compiler for Standard ML - hurd-i386 
runtime libraries
 mlton-runtime-i486-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-i386 runtime libra
 mlton-runtime-i486-linux-gnu - Optimizing compiler for Standard ML - i386 
runtime libraries
 mlton-runtime-ia64-linux-gnu - Optimizing compiler for Standard ML - ia64 
runtime libraries
 mlton-runtime-mips-linux-gnu - Optimizing compiler for Standard ML - mips 
runtime libraries
 mlton-runtime-mipsel-linux-gnu - Optimizing compiler for Standard ML - mipsel 
runtime libraries
 mlton-runtime-native - Optimizing compiler for Standard ML - native runtime 
libraries
 mlton-runtime-powerpc-linux-gnu - Optimizing compiler for Standard ML - 
powerpc runtime libraries
 mlton-runtime-s390-linux-gnu - Optimizing compiler for Standard ML - s390 
runtime libraries
 mlton-runtime-sparc-linux-gnu - Optimizing compiler for Standard ML - sparc 
runtime libraries
 mlton-runtime-x86-64-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-amd64 runtime libr
 mlton-runtime-x86-64-linux-gnu - Optimizing compiler for Standard ML - amd64 
runtime libraries
 mlton-tools - Optimizing compiler for Standard ML - tools
Changes: 
 mlton (20100608-4) unstable; urgency=low
 .
   * Add missing install file for sparc runtime
   * Make the self target symlink relative
   * Added Replaces and Breaks the old version for smooth upgrades
   * Previous build needed manual uploads, so buildd rebuild needed
   * Still needing bootstrap:
* mips(el) gcc bug still unresolved and no-explicit-relocs fails too
Checksums-Sha1: 
 3e50070d8659ae94c8bfb1297fa14c41eea30daf 1706 mlton_20100608-4.dsc
 acc097284b7326833f5f21007d4c0ced60184d24 19444 mlton_20100608-4.debian.tar.gz
 6610714060b59b004a3bb628b456157d8d6cdd9d 38988 mlton_20100608-4_all.deb
 885ab049e93f5df98afe8577c6c6d16edef9de33 2098526 mlton-basis_20100608-4_all.deb
 b9bf4e5cf69d508b1381ba95098126aebd9a975c 3530830 mlton-doc_20100608-4_all.deb
 bd113f577ae0c4dcf2d91ad3c0f28f29dd614cbb 3329468 
mlton-compiler_20100608-4_i386.deb
 9cab00e65bc27f20b0fac91f9cbfe2f6d6c4b01c 1366712 
mlton-tools_20100608-4_i386.deb
 2899a0af4ddadd07918c6f1449f3ab57d8fed3f1 38128 
mlton-runtime-native_20100608-4_i386.deb
 05f1b8da8cc427086c27f33df46c4ac806d5c682 454520 
mlton-runtime-i486-linux-gnu_20100608-4_i386.deb
Checksums-Sha256: 
 708e98bb71fed05a6638b35adaed35ab68a76f735f56c5288c9d6c8857273da9 1706 
mlton_20100608-4.dsc
 236ef40df466a2bc7089e7fbab03ddc5424cb972ea388136f07b43d97c45d6b4 19444 
mlton_20100608-4.debian.tar.gz
 31fe313a9765cac9ecb0f6d42a57756497ce41cf66f94c8eed5bda85e7bd9d33 38988 
mlton_20100608-4_all.deb
 b16a9dd33aeac4effd8df28015c62940bb72992fccaea53fcc893338cb34292c 2098526 
mlton-basis_20100608-4_all.deb
 b2b4ae49263556c53b5c16364a49a49bdff36163da2cddd3f145d6aa8ee76ff3 3530830 
mlton-doc_20100608-4_all.deb
 57928066cb52d04e5b79502e4bfb400c4e77adfca9101ba1714e4aba9e4ed2b1 3329468 
mlton-compiler_20100608-4_i386.deb
 31a92fdc7e20747a716902bcac0958e600ffbd3b37827eedaccaf23925d7ee96 1366712 
mlton-tools_20100608-4_i386.deb
 d32c5fb5d6977350e4ad815aca6a15f8a028eb53a53bbdeb0cb244e98d01590c 38128 
mlton-runtime-native_20100608-4_i386.deb
 7860a1a75d53af596943f23b3ac56a4f6c315a3948b826d12bab573a23f647d4 454520 
mlton-runtime-i486-linux-gnu_20100608-4_i386.deb
Files: 
 ed3462108bd61031cdd2ada01a8a4805 1706 devel optional mlton_20100608-4.dsc
 323b0c2c03877cfad8f39c59bc8627f1 19444 devel optional 
mlton_20100608-4.debian.tar.gz
 4f6c34f5ef4cd2d38197d0ec5b856fdb 38988 devel optional mlton_20100608-4_all.deb
 f4489127722846e2ca48504904b1eeca

Re: mlton any-all package transition breakage

[Wesley W. Terpstra]

On Fri, Apr 1, 2011 at 9:58 PM, Peter Palfrader wea...@debian.org wrote:

 all the other chroots are now fucked because we did as you asked, and
 for some reason it wants to bring in mlton-doc


The problem there is you're trying to install and/or upgrade the sid one,
not the squeeze one.


 I think we won't be doing anything like that again any time soon.


Feel free to purge whatever mlton package you have installed.

I've been fairly successful building the package from installing the .debs
in my home directory.

Re: mlton any-all package transition breakage

[Wesley W. Terpstra]

On Fri, Apr 1, 2011 at 10:47 PM, Peter Palfrader wea...@debian.org wrote:

  The problem there is you're trying to install and/or upgrade the sid one,
  not the squeeze one.

 No, the squeeze package installed cleanly.  now apt-get update 
 upgrade breaks.  That means the package is buggy.


Yes, I know it's buggy. That's why I'm trying to fix it.

It is missing a replaces/breaks, which leads to upgrade problems.
However, before I can upload a new version that fixes that, I need to get a
working bootstrap version that the buildd will actually install.

mlton any-all package transition breakage

[Wesley W. Terpstra]

Good afternoon.

I am the maintainer for the Standard ML 97 (SML) compiler mlton. This
compiler is itself written in SML and is self-hosting. Thus, it needs an
older version of the compiler in order to bootstrap itself. Further
complicating things, the build needs in the ballpark of 1-2GB of physical
memory for 32-64-bit architectures, otherwise the build will cause the host
machine to swap-till-death. Over the years I have slowly increased the
number of supported architectures in debian via a combination of
cross-compilation and binary uploads. At the moment, every major debian
architecture is supported.

Recently I had to prepare a new upload due to the gmp transition and took
the opportunity now that squeeze is released to split out the
arch-independent components of this monolithic package. Unfortunately, this
had unforeseen consequences on the buildd system. The problem is that the
old 'any' package (20100608-2) got removed from unstable before the new
package's (20100608-3) buildd runs completed; only the amd64 buildd was fast
enough. I am not entirely clear on the cause, but the consequence is clear
enough: the buildds can no longer install the old version of mlton needed to
bootstrap the new version.

It has been proposed to me to manually rebuild the package on every debian
architecture and then binary upload the result. To that end, I request
installation in a sid chroot these packages from unstable: libgmp-dev
htmldoc texlive-latex-base procps debhelper cdbs quilt joe. Additionally,
please install from squeeze (should still install cleanly in sid chroot) the
package: mlton.

I request the above packages to be installed on these machines:
albeniz.debian.org  alpha   8g  y
abel.debian.org armel   1.5gy
merulo.debian.org   ia648g  y
asdfasdf.debian.net kfreebsd-amd64  2g  y
ad...@asdfasdf.debian.net
io.debian.net   kfreebsd-i386   1.5gy   ad...@io.debian.net
gabrielli.debian.orgmips1.6gy
zelenka.debian.org  s3901g  y
smetana.debian.org  sparc   2g  y

Unfortunately, a look over the currently available porterboxes shows that
not every architecture can be fixed this way: paer does not have a sid
chroot, strauss has insufficient memory, mipsel has no porterbox at all, and
pescetti has insufficient memory. This means that I cannot rebuild the
package for: hppa, hurd-i386, mipsel, powerpc. The available buildd machines
*can* rebuild the package on these architectures, but will not do so as long
as the old version is missing from unstable.

I believe strauss has configurable main memory. If it could be temporarily
given 1.5G, then that would solve hurd-i386.
Would it be possible to get a sid dchroot setup on paer? If yes, that's
another architecture fixed.

I am looking for a solution to this build problem for mipsel and powerpc. If
the old mlton 'any' package (still in squeeze) were re-added to unstable,
that would work (and also render the above package installation requests
unnecessary). I'm open to any other suggestions.

One option I have considered: by-hand, rip the contents out of the old mlton
'any' package and rebundle the old contents as the new version and do a
binary upload. This way I could get packages for powerpc and mipsel that
would work to properly bootstrap a new upload on the buildds. This is a
pretty nasty hack and would mean that the sources do not match the binaries
for this one uploaded version, but this might be acceptable as a
transitionary step...?

Any help appreciated!

PS. I could not determine which mailing list is haunted by the ftp-masters.
If debian-admin is wrong, please forward it.

Re: new buildd dependency resolution breaks self depends?

[Wesley W. Terpstra]

On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx k...@roeckx.be wrote:

 On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote:
  If I may ask, for what purpose do the buildds have a special list of
  packages above and beyond those in unstable?

 So that in case various packages have to be build in an order,
 where the seconds depends on the first being available and so on,
 that it doesn't take weeks to get them all build.  We would have
 to wait at least a dinstall before the next one could be build,
 assuming sometimes has the time to sign the package between
 dinstalls.

 It basicly just avoids a whole lot of delays.


Unfortunately, it seems also to add quite some delays in the self-compiling
case. :-/ Each time a buildd finishes, that buildd's Packages file gets
updated due to the completed binary upload and all other buildds go back
into the BD-Uninstallable state. (I assume this also means the package loses
its place in line on the busy buildd queues)

I wonder if the same rules applied to the unstable package list (don't
include the all for a package whose any is not done) could be applied also
to the buildd's Packages?

new buildd dependency resolution breaks self depends?

[Wesley W. Terpstra]

I've read that there was a recent change made to the buildd resolution with
regards to ensuring that consistent package versions are used on the builds
[0]. Is it possible that this changed also messed up self-dependency
resolution?

My package, mlton, has a versioned dependency on itself for version =
20070826. As it is a compiler for SML written in SML, it needs a previous
version of itself installed in order to compile the new version. Previously,
this has presented no problems; the buildd installed the old version and
compiled the new version. Now, the buildd demands that the same version be
installed as is to be built [1]:

*mlton/alpha dependency installability problem:*

  mlton (= 20100608-3) build-depends on one of:
  - mlton (= 20100608-3)

... this is, of course, impossible. The buildd must install the old version
in order to build the new. I have a suspicion that an overzealous 'use the
same version' rule in the dependency resolver might be the cause of this
bug.

Thanks for any help understanding why the buildd system will no longer
attempt to build my package!

[0] http://lists.debian.org/debian-policy/2011/03/msg00103.html
[1] https://buildd.debian.org/status/package.php?p=mlton

Re: new buildd dependency resolution breaks self depends?

[Wesley W. Terpstra]

On Tue, Mar 29, 2011 at 5:52 PM, Julien Cristau jcris...@debian.org wrote:

 As far as I can tell the problem is that you switched the mlton binary
 package to 'Architecture: all'.  Which means it's available on all
 architectures already in the new version, even though it's not
 installable.


Ahh! That makes a lot of sense, thanks.

I'll need to figure out a way to work-around this.

Re: new buildd dependency resolution breaks self depends?

[Wesley W. Terpstra]

On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx k...@roeckx.be wrote:

 As long as the Packages file for the buildds mentions this arch
 all package, no buildd can build it, because it only considers
 installing the latest version.  But it should get removed
 from that file after 24 or 32 hours or something.  In which case
 we'll only see the old version, can install those, and things should
 work from there.


I hope what you're telling me is true, because it will save  me a lot of
work! :)

What I don't understand about your explanation: once the new all+i386 .debs
hit unstable, won't the buildds see the new 'all' package in unstable and
thus want to install it in preference to the old 'any' package even after it
is removed from the Packages file? The 'all' package will still be
uninstallable since it depends on the missing 'any' packages.

While I can fix the problem at hand by removing the mlton 'all' package for
an upload,  I see a more troublesome problem on the horizon:

The basis, runtime, and compiler packages should all be at the same version
to compile correctly. The basis package is an 'all' package which includes
the cross-platform bits of the runtime library. The runtime and compiler are
'any' packages with compiled object code.

If the Build-Depends lists 'mlton-compiler' (ie: after I resolve the current
problem), any future uploads will see that it has these versions available:
mlton-compiler (= old-version) depends on runtime
mlton-runtime (= old-version) depends on basis
mlton-basis (= new version)
... which I believe means that the old-version mlton-compiler package will
be uninstallable since the old-version of the basis in unstable is hidden by
the new-version.

Have I understood this problem correctly?

Re: new buildd dependency resolution breaks self depends?

[Wesley W. Terpstra]

On Tue, Mar 29, 2011 at 7:27 PM, Kurt Roeckx k...@roeckx.be wrote:

 Note that in unstable you don't see the arch arch all version
 until the arch any version is also available.  Or you would see
 the old arch all version until the new arch any version is
 available.


That's great! My thanks to whomever had the foresight to prevent this
temporary dependency breakage for all-any dependencies. I guess this would
otherwise have annoyed unstable users for packages that had yet to be built
for their architecture..?

This means that the version from unstable should always be
 installable, unless there is some other reason it's not like
 a transition of some other library.


Yes, the libgmp3-dev - libgmp-dev transition already bit me this way. I
assumed I was in for more of the same with the self dependency.

The problem is that the buildds currently also see the newer
 arch all version.  But this version will go away after some
 time and it will only see the version from unstable.


If I may ask, for what purpose do the buildds have a special list of
packages above and beyond those in unstable?

The new version of mlton-basis will only be visible to the buildds
 for about a day, after which they should have no problem building
 it.


Thank god. :)

Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?

[Wesley W. Terpstra]

On Tue, Mar 29, 2011 at 7:10 PM, Lennart Sorensen 
lsore...@csclub.uwaterloo.ca wrote:

 Does mlton-basis depend on mlton-runtime or mlton-compiler to build?

If the answer is yes, then most likely these should not be three seperate

source packages.


It's all one source package. I split it up the binaries because:
1) about 60% of the package could be in an 'all' package.
2) the runtime components for different architectures can be installed
side-by-side... thus enabling cross-compilation.

If no, then why doesn't it just work or is the problem a previous version
 causing a mess?


According to Kurt, there is no problem. It's all in my head. :)

Accepted mlton 20100608-3 (source all i386)

[Wesley W. Terpstra (Debian)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sun, 20 Mar 2011 14:05:32 +0100
Source: mlton
Binary: mlton mlton-basis mlton-doc mlton-compiler mlton-tools 
mlton-runtime-native mlton-runtime-alpha-linux-gnu 
mlton-runtime-x86-64-linux-gnu mlton-runtime-arm-linux-gnueabi 
mlton-runtime-hppa-linux-gnu mlton-runtime-i486-gnu 
mlton-runtime-i486-linux-gnu mlton-runtime-ia64-linux-gnu 
mlton-runtime-i486-kfreebsd-gnu mlton-runtime-x86-64-kfreebsd-gnu 
mlton-runtime-mips-linux-gnu mlton-runtime-mipsel-linux-gnu 
mlton-runtime-powerpc-linux-gnu mlton-runtime-s390-linux-gnu 
mlton-runtime-sparc-linux-gnu
Architecture: source all i386
Version: 20100608-3
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org
Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org
Description: 
 mlton  - Optimizing compiler for Standard ML
 mlton-basis - Optimizing compiler for Standard ML - basis library
 mlton-compiler - Optimizing compiler for Standard ML - compiler
 mlton-doc  - Optimizing compiler for Standard ML - documentation
 mlton-runtime-alpha-linux-gnu - Optimizing compiler for Standard ML - alpha 
runtime libraries
 mlton-runtime-arm-linux-gnueabi - Optimizing compiler for Standard ML - armel 
runtime libraries
 mlton-runtime-hppa-linux-gnu - Optimizing compiler for Standard ML - hppa 
runtime libraries
 mlton-runtime-i486-gnu - Optimizing compiler for Standard ML - hurd-i386 
runtime libraries
 mlton-runtime-i486-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-i386 runtime libra
 mlton-runtime-i486-linux-gnu - Optimizing compiler for Standard ML - i386 
runtime libraries
 mlton-runtime-ia64-linux-gnu - Optimizing compiler for Standard ML - ia64 
runtime libraries
 mlton-runtime-mips-linux-gnu - Optimizing compiler for Standard ML - mips 
runtime libraries
 mlton-runtime-mipsel-linux-gnu - Optimizing compiler for Standard ML - mipsel 
runtime libraries
 mlton-runtime-native - Optimizing compiler for Standard ML - native runtime 
libraries
 mlton-runtime-powerpc-linux-gnu - Optimizing compiler for Standard ML - 
powerpc runtime libraries
 mlton-runtime-s390-linux-gnu - Optimizing compiler for Standard ML - s390 
runtime libraries
 mlton-runtime-sparc-linux-gnu - Optimizing compiler for Standard ML - sparc 
runtime libraries
 mlton-runtime-x86-64-kfreebsd-gnu - Optimizing compiler for Standard ML - 
kfreebsd-amd64 runtime libr
 mlton-runtime-x86-64-linux-gnu - Optimizing compiler for Standard ML - amd64 
runtime libraries
 mlton-tools - Optimizing compiler for Standard ML - tools
Closes: 618268
Changes: 
 mlton (20100608-3) unstable; urgency=low
 .
   * Include all bugfixes since 20100608 release
   * Depend on libgmp-dev (closes: #618268)
   * Split package into compiler, runtime, basis, tools, and doc
* Use multiarch to support cross-compiling
* Eliminates the need for a mlton-cross package
   * Updated standards version (no changes needed)
Checksums-Sha1: 
 ab2a13932ea7f59e7156068928703b88cc4c7753 1706 mlton_20100608-3.dsc
 7dbf3825a00c490ae546ea82146edb179c4dd946 19442 mlton_20100608-3.debian.tar.gz
 9a7da6d36fd760f751ab875eade0fdc5e7a20d8c 38848 mlton_20100608-3_all.deb
 8f1c4b52993de1cd31e1ae7e7b3d91b706890fa8 2098430 mlton-basis_20100608-3_all.deb
 90853c4de9caedf4eb3e25901e8fea76fb051ec1 3530704 mlton-doc_20100608-3_all.deb
 11c90bf37ac4a4296d163462da5544f8fe3647f1 3329284 
mlton-compiler_20100608-3_i386.deb
 4349dbca8ac6e68db119153aa33839086d395497 1366532 
mlton-tools_20100608-3_i386.deb
 3c6821814c21665e1fbec31cfcaec99839d0c020 37980 
mlton-runtime-native_20100608-3_i386.deb
 c807d643267ebe57360086b24ff9f4d2b168ef4c 454448 
mlton-runtime-i486-linux-gnu_20100608-3_i386.deb
Checksums-Sha256: 
 56992f105a42f3d45d8d77216bb748dcd4e728e445d3bb51cd88ba47e3262120 1706 
mlton_20100608-3.dsc
 b4bfc29ad718e91ee89d3a0757928378aa0d9e04d5c50e94ab113fbab5fc6d26 19442 
mlton_20100608-3.debian.tar.gz
 a83cc439ffee859be95c3c0c9329279861ed05cddb01fa0efa27f11c54940921 38848 
mlton_20100608-3_all.deb
 9b2a7ddb4ab74a1d7e6eb67f7f4909fb1ade9a150e98530662cc8e499014e36b 2098430 
mlton-basis_20100608-3_all.deb
 9d21935dc991e738e3845569726b0ba38b4b07acf650c124e26a3210b57001df 3530704 
mlton-doc_20100608-3_all.deb
 aecfa50ea502507c71c7d8c214773c4fe2a954d81ef9599ed7453e1b963bc20e 3329284 
mlton-compiler_20100608-3_i386.deb
 184e48453b4c0282ece1c7683c59a2cc471e493695cabdf29d8b0e97d89a5284 1366532 
mlton-tools_20100608-3_i386.deb
 8969063bac41792557476b16e3e8ee1d26c29719b4a8c16660df6976005ef981 37980 
mlton-runtime-native_20100608-3_i386.deb
 df7dcc470f2077368b2fda72c71063eff4a0ad01c02621b0da1246d728a3dbd4 454448 
mlton-runtime-i486-linux-gnu_20100608-3_i386.deb
Files: 
 9e99f31f5640a946c7d6f05b5d830de1 1706 devel optional mlton_20100608-3.dsc
 79fff4cbe000864fbf22b6e64195040e 19442 devel optional 
mlton_20100608-3.debian.tar.gz
 4c06c6678f885a6258ad5a4f801c102e 38848 devel optional mlton_20100608-3_all.deb
 b89292acb99d336e91e588b7f09f7c26 2098430

Bug#619162: RM: mlton-cross -- ROM; Bad idea

[Wesley W. Terpstra (Debian)]

Package: ftp.debian.org
Severity: normal

I had tried to support cross-compiling Standard ML with this package,
but it needed to extract files from the main mlton package to achieve
this effect, much like the evil ia32libs package.

Since then, I've built a better solution that should work with 
Multi-Arch support in dpkg (whenever this lands). As the Multi-Arch
approach works with the normal 'mlton' package, 'mlton-cross' is
completely unnecessary.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [Milkymist-devel] LM32 patch licensing

[Wesley W. Terpstra]

I've CC'd this to the list so my advocacy gets archived. ;)

On 09/03/11 12:34 AM, Michael Walle wrote:

Mh, xilinx has the bscan cell, which basically has a TDI and TDO and that gets
connected to the real JTAG pins if you select the proper instruction (USER1,
USER2, etc). The 'internal' JTAG TAP isn't really visible externally.

Doesn't the Altera's vJTAG megafunction work in a similar way? For the Xilinx
case, i have to know that i have to use a special instruction anyway. Hence i
don't see why there should be an IDCODE for automatic discovery.
   


Sounds quite similar. Altera boards have a JTAG bitbang interface over 
USB. You can boundary scan, load FPGA configuration, etc over that JTAG 
interface. Sometimes this interface has more than one chip on it (our 
Arria2 boards have 2 components in the chain, for example).


The Cyclone3 chip has a 'sld hub' inside it which is accessed via two of 
the Cyclone3's JTAG registers. You can instruct the hub via USER1 to 
connect one of the JTAG instance ids' IR or DR to the USER0 register.


What is inside that chain you can now probe like any other JTAG chain; 
only the way you access the chain is different, two registers instead of 
USB. Since the FPGA is reconfigurable, until you probe the internal 
chain, you have no idea what is inside it. Having a tool which is able 
to detect the contents of the FPGA and say Aha! You have an LM32 in 
there, let's provide gdb hooks and wishbone bus access! is a lot better 
than a tool which has to work off the assumption that the FPGA was 
configured with an LM32.


I have designed my debug tool to be quite modular and extensible. I hope 
that it will be useful for many other cores than just the LM32. In that 
case, it might need to support other devices built into a 
Cyclone3/whatever. Other designs may already have a JTAG chain with 
multiple devices that were originally connected directly to output pins 
and you have now connected to the sld hub. In that case the tool should 
still scan the JTAG chain to determine what is inside and address the 
attached devices.


Conversely, you might design an LM32 to have its JTAG pins connected to 
actual output pins once deployed. In that scenario you would need IDCODE 
support for the LM32 to be detected on the external interface. I intend 
to make my LM32 debuggable over Etherbone in addition to USB. That means 
I will wire the JTAG pins also to a small Wishbone-JTAG slave. Since we 
will likely have many devices on that 
Linux/UDP-Etherbone-Wishbone-JTAG path, the LM32 should behave 
correctly so that we can use it and the other devices.


Finally, the cost to implement IDCODE and BYPASS is very small. I 
imagine it will be some 2-4 hours of work and under 20 LUTs. So I'd turn 
the question around and ask: What is the advantage to not conforming to 
the JTAG standard?



Will an Altera FPGA split the JTAG chain if you use you instantiate a vJTAG
megafunction? I can hardly believe this, because
  (1) a broken FPGA bitstream could result in a broken JTAG chain
  (2) the JTAG chain would be different if the FPGA was configured
   

You cannot attach a device to the top-level JTAG, but as I've argued above, 
there are many situations where that doesn't excuse the LM32 from conforming to 
the standard.

___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
Twitter: www.twitter.com/milkymistvj
Ideas? http://milkymist.uservoice.com

Re: [Milkymist-devel] Some tweaks to the LM32 used at GSI

[Wesley W. Terpstra]

On 07/03/11 04:21 PM, Sebastien Bourdeauducq wrote:

Yes, but in some cases, a synthesizer that supports retiming
Ok, I was under the impression the FPGA synthesis tools didn't do this 
and it was more the domain of ASIC tools. Quartus clearly doesn't 
support it (since I see an improvement by manually doing it).



For
example, this is a valid way to infer a 2-stage pipelined multiplier
with Xst, even if the operands are too large for a single hard
multiplier:

always @(posedge clk) begin
foo= a*b;
bar= foo; /* foo is not used anywhere else */
end
   

That's pretty cool if your tool can do it for you.

At any rate, if there are such smart FPGA synthesizers, then I can see 
why you'd like to leave it as it is. For our stuff using Altera, I'll 
just keep the change locally.


___
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
Twitter: www.twitter.com/milkymistvj
Ideas? http://milkymist.uservoice.com

Re: [Milkymist-devel] Some tweaks to the LM32 used at GSI

[Wesley W. Terpstra]

On 28/02/11 01:54 PM, Sebastien Bourdeauducq wrote:

Michael, what do you think of the JTAG modifications below (I have not
touched this part and I quite don't know how it works) ?
   


Ok, I've improved on that last patch for the JTAG interface.

I found (while getting openocd working) that my JTAG could sometimes 
hang. I didn't see this bug with my own firmware loading tool because it 
always runs a JTAG drscan after each operation to determine the 
resulting status. This masked the following problem:


Altera JTAG sometimes stops driving the JTAG clock once it asserts 
update (confirmed with signal tap). Thus, when the old code waited for 
the negative edge of update, it could stop indefinitely---or at least 
until the next JTAG operation.


Like the previous patch, this patch also fixes a race condition. The old 
code latched the shift register (jtag_cores) concurrently with flipping 
the rx_toggle on update (lm32_jtag). This caused JTAG instability on 
Altera chips, where commands could got lost or repeated, depending on 
the synthesizers mood.


For me, now, the JTAG runs rock solid on my Cyclone3: it never screws up 
or loses synchronization and it always executes commands immediately.


I can't test the spartan6 changes, but I believe/hope I've updated the 
verilog file appropriately.


diff -ru /home/terpstra/lm32/milkymist/cores/lm32/rtl/jtag_cores.v rtl/jtag_cores.v
--- /home/terpstra/lm32/milkymist/cores/lm32/rtl/jtag_cores.v	2011-02-28 14:00:53.0 +0100
+++ rtl/jtag_cores.v	2011-03-01 14:50:03.0 +0100
@@ -1,3 +1,5 @@
+// Modified by GSI to use simple positive edge clocking and the JTAG capture state
+
 module jtag_cores (
 input [7:0] reg_d,
 input [2:0] reg_addr_d,
@@ -11,15 +13,19 @@
 wire tck;
 wire tdi;
 wire tdo;
+wire capture;
 wire shift;
 wire update;
+wire e1dr;
 wire reset;
 
 jtag_tap jtag_tap (
 	.tck(tck),
 	.tdi(tdi),
 	.tdo(tdo),
+	.capture(capture),
 	.shift(shift),
+	.e1dr(e1dr),
 	.update(update),
 	.reset(reset)
 );
@@ -27,26 +33,28 @@
 reg [10:0] jtag_shift;
 reg [10:0] jtag_latched;
 
-always @(posedge tck or posedge reset)
+always @(posedge tck)
 begin
 	if(reset)
 		jtag_shift = 11'b0;
 	else begin
-		if(shift)
+		if (shift)
 			jtag_shift = {tdi, jtag_shift[10:1]};
-		else
+		else if (capture)
 			jtag_shift = {reg_d, reg_addr_d};
 	end
 end
 
 assign tdo = jtag_shift[0];
 
-always @(posedge reg_update or posedge reset)
+always @(posedge tck)
 begin
 	if(reset)
 		jtag_latched = 11'b0;
-	else
-		jtag_latched = jtag_shift;
+	else begin
+	   if (e1dr)
+		   jtag_latched = jtag_shift;
+	end
 end
 
 assign reg_update = update;
diff -ru /home/terpstra/lm32/milkymist/cores/lm32/rtl/lm32_jtag.v rtl/lm32_jtag.v
--- /home/terpstra/lm32/milkymist/cores/lm32/rtl/lm32_jtag.v	2011-02-28 14:00:53.0 +0100
+++ rtl/lm32_jtag.v	2011-03-01 14:50:03.0 +0100
@@ -170,13 +170,15 @@
 // Internal nets and registers 
 /
 
-reg rx_toggle;  // Clock-domain crossing registers
-reg rx_toggle_r;// Registered version of rx_toggle
-reg rx_toggle_r_r;  // Registered version of rx_toggle_r
-reg rx_toggle_r_r_r;// Registered version of rx_toggle_r_r
-
-reg [`LM32_BYTE_RNG] rx_byte;   
-reg [2:0] rx_addr;
+reg rx_update;  // Clock-domain crossing registers
+reg rx_update_r;// Registered version of rx_update
+reg rx_update_r_r;  // Registered version of rx_update_r
+reg rx_update_r_r_r;// Registered version of rx_update_r_r
+
+// These wires come from the JTAG clock domain.
+// They have been held unchanged for an entire JTAG clock cycle before the jtag_update toggle flips
+wire [`LM32_BYTE_RNG] rx_byte;   
+wire [2:0] rx_addr;
 
 `ifdef CFG_JTAG_UART_ENABLED 
 reg [`LM32_BYTE_RNG] uart_tx_byte;  // UART TX data
@@ -229,36 +231,26 @@
 // Sequential Logic
 /
 
-// Toggle a flag when a JTAG write occurs
- 
-always @(negedge jtag_update `CFG_RESET_SENSITIVITY)
-begin
-if (rst_i == `TRUE)
-  rx_toggle = 1'b0;
-else 
-  rx_toggle = ~rx_toggle;
-end
-
-always @(*)
-begin
-rx_byte = jtag_reg_q;
-rx_addr = jtag_reg_addr_q;
-end
+assign rx_byte = jtag_reg_q;
+assign rx_addr = jtag_reg_addr_q;
 
-// Clock domain crossing from JTAG clock domain to CPU clock domain
+// The JTAG latched jtag_reg[_addr]_q at least one JTCK before jtag_update is raised
+// Thus, they are stable (and safe to sample) when jtag_update is high
 always @(posedge clk_i `CFG_RESET_SENSITIVITY)
 begin
 if (rst_i == `TRUE)
 begin
-rx_toggle_r = 1'b0;
-rx_toggle_r_r = 1'b0;
-rx_toggle_r_r_r = 1'b0;
+rx_update = 1'b0;
+rx_update_r = 1'b0;
+rx_update_r_r = 1'b0;
+rx_update_r_r_r = 1'b0;
 end
 else
 begin
-rx_toggle_r = 

[Milkymist-devel] Some tweaks to the LM32 used at GSI

[Wesley W. Terpstra]

The changes in this patch:
1.  add a JTAG capture pin
  = allows removing sensitivity to reg_update which caused clocking 
problems making JTAG unstable

2. support register file backed by ram blocks
  = saves quite some area and speed on altera
  ... be sure to enable it using `define CFG_EBR_POSEDGE_REGISTER_FILE
3. Fix a minor problem where compilation fails when interrupts are not 
supported

4. Add support to flush icache and dcache per JTAG
5. Fix wrong width assignments for PC
6. Marginally pipeline the multiplier
  = not a lot, but enough to move it off the critical path

I've also attached my firmware loading tool. It needs quartus to work 
with Altera FPGAs, though.




gsi-lm32-tweaks.tar.gz
Description: GNU Zip compressed data
#! /bin/bash
# \
export RLWRAP_ #\
exec rlwrap -C lm32-ctl -I /opt/quartus/quartus/bin/quartus_stp --64bit -t $0 
$@

### LOW LEVEL ACCESS #
proc jtag_put {val} {
  device_virtual_dr_shift -instance_index 0 -length 11 -dr_value [format %03X 
$val] -value_in_hex -no_captured_dr_value
}

proc jtag_get {} {
  return 0x[device_virtual_dr_shift -instance_index 0 -length 11 -dr_value 000 
-value_in_hex]
}

 SAFE-ISHL ACCESS #

proc jtag_val {idx val} {
  set v [expr {($val  3) | $idx}]
  jtag_put $v
}

proc jtag_cmd {idx cmd} {
  set val [expr {$cmd  4}]
  jtag_val $idx $val
}

proc jtag_low {i} {
  set high 1
  while {$high = 1} {
set val [jtag_get]
set high [expr {($val  $i)  1}]
  }
  return [expr {$val  3}]
}

proc jtag_high {i} {
  set high 0
  while {$high  1} {
set val [jtag_get]
set high [expr {($val  $i)  1}]
  }
  return [expr {$val  3}]
}

## COMMANDS ###

proc jtag_read_addr {addr} {
  jtag_cmd 0 1
  jtag_val 0 [expr {($addr  24)  0xff}]
  jtag_val 0 [expr {($addr  16)  0xff}]
  jtag_val 0 [expr {($addr   8)  0xff}]
  jtag_val 0 [expr {($addr   0)  0xff}]
  
  return [jtag_low 2]
}

proc jtag_read_next {} {
  jtag_cmd 0 3
  return [jtag_low 2]
}

proc jtag_read_memory {addr len} {
  set out [list]
  
  if {$len  0} {
lappend out [format %02X [jtag_read_addr $addr]]
  }
  
  for {set i 1} {$i  $len} {incr i} {
#set x [expr {$addr+$i}]
#lappend out [format %02X [jtag_read_addr $x]]
lappend out [format %02X [jtag_read_next]]
  }
  return $out
}

proc jtag_write_addr {addr val} {
  jtag_cmd 0 2
  jtag_val 0 [expr {($addr  24)  0xff}]
  jtag_val 0 [expr {($addr  16)  0xff}]
  jtag_val 0 [expr {($addr   8)  0xff}]
  jtag_val 0 [expr {($addr   0)  0xff}]
  jtag_val 0 $val
  
  return [jtag_low 2]
}

proc jtag_write_next {val} {
  jtag_cmd 0 4
  jtag_val 0 $val
  return [jtag_low 2]
}

proc jtag_write_memory {addr data} {
  set first 1
  foreach j $data {
if {$first == 1} {
  set first 0
  jtag_write_addr $addr $j
} else {
  jtag_write_next $j
}
  }
}

proc jtag_uart_write {val} {
  jtag_low 1
  jtag_val 1 $val
}

proc jtag_uart_read {} {
  set val [jtag_get]
  while {($val  1) == 1} {
jtag_val 2 0
set val [jtag_get]
set inb [expr {$val  3}]
puts -nonewline [format %02X $inb] 
  }
  puts .
}

proc jtag_write_csr {csr val} {
  jtag_cmd 0 5
  jtag_val 0 [expr {($val  24)  0xff}]
  jtag_val 0 [expr {($val  16)  0xff}]
  jtag_val 0 [expr {($val   8)  0xff}]
  jtag_val 0 [expr {($val   0)  0xff}]
  jtag_val 0 $csr
  
  return [jtag_low 2]
}

proc jtag_break {} {
  jtag_cmd 0 6
}

proc jtag_reset {} {
  jtag_cmd 0 7
}

# Move back to idle state
proc jtag_sync {} {
  for {set i 0} {$i  10} {incr i} {
jtag_cmd 0 0
after 20
  }
}

# ASM #

proc opcode {val} {
  switch $val {
 0 { return srui}
 1 { return nori}
 2 { return muli}
 3 { return sh  }
 4 { return lb  }
 5 { return sri }
 6 { return xori}
 7 { return lh  }
 8 { return andi}
 9 { return xnori   }
10 { return lw  }
11 { return lhu }
12 { return sb  }
13 { return addi}
14 { return ori }
15 { return sli }
16 { return lbu }
17 { return be  }
18 { return bg  }
19 { return bge }
20 { return bgeu}
21 { return bgu }
22 { return sw  }
23 { return bne }
24 { return andhi   }
25 { return cmpei   }
26 { return cmpgi   }
27 { return cmpgei  }
28 { return cmpgeui }
29 { return cmpgui  }
30 { return orhi}
31 { return cmpnei  }
32 { return sru }
33 { return nor }
34 { return mul }
35 { return divu}
36 { return rcsr}
37 { return sr  }
38 { return xor }
39 { return div }
40 { return and }
41 { return xnor}
42 { return ??  }
43 { return raise   }
44 { return sextb   }
45 { return add }
46 { return or  }
47 { 

Re: Arm blacklist for package MLton

[Wesley W. Terpstra]

On Wed, Nov 10, 2010 at 1:02 AM, Hector Oron hector.o...@gmail.com wrote:
 AFAIK blacklisting per buildd is not available[1].

I've had the same problem on other architectures and had it solved
there this way, so I assume/hope arm is no different.

 In any case, this email might be best placed as a bug report to 
 buildd.debian.org

Thanks for the suggestion.


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimemk6b-v1pdryvesthfcl7pg+eb8vlyncj5...@mail.gmail.com

Bug#603002: buildd.debian.org: Arm blacklist for package MLton

[Wesley W. Terpstra]

Package: buildd.debian.org
Severity: normal

Good afternoon.

To compile my package, MLton, a buildd needs 1GB of physical memory
(or else it will thrash swap so badly the build fails). Until
recently, none of the arm buildd's met this requirement and thus I had
to use qemu to build the binary package for this platform.

Now that there are new arm buildds with = 1 GB of RAM, I was hoping
to let the buildd system build this package in the future. As I
understand it, however, buildds are selected to spread out the load
and so my package might end up being built on a machine with
insufficient memory. Therefore, I would ask that the MLton package be
black-listed on these hosts:

black list:
   arcadelt
   argento
   ancina
ok:
   alain
   alwyn
   antheil
   arne
   arnold

Thank you!

-- System Information:
Debian Release: 5.0.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Arm blacklist for package MLton

[Wesley W. Terpstra]

Good afternoon.

To compile my package, MLton, a buildd needs 1GB of physical memory
(or else it will thrash swap so badly the build fails). Until
recently, none of the arm buildd's met this requirement and thus I had
to use qemu to build the binary package for this platform.

Now that there are new arm buildds with = 1 GB of RAM, I was hoping
to let the buildd system build this package in the future. As I
understand it, however, buildds are selected to spread out the load
and so my package might end up being built on a machine with
insufficient memory. Therefore, I would ask that the MLton package be
black-listed on these hosts:

black list:
arcadelt
argento
ancina
ok:
alain
alwyn
antheil
arne
arnold

Thank you!


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinh+0gxvdn2ovgd1szvndj3kfj7_hjvuepab...@mail.gmail.com

Bug#591174:

[Wesley W. Terpstra]

Where in the policy is it forbidden to download from the Internet? I
actually looked for this before I packaged it:

terps...@orange:/usr/share/doc/debian-policy$ zgrep -i internet policy.txt.gz
 MIME (Multipurpose Internet Mail Extensions, RFCs 2045-2049) is a
terps...@orange:/usr/share/doc/debian-policy$ zgrep -i download policy.txt.gz
 compiling from source don't have to download multiple packages.
 a Debian package: anyone can download the `.deb' file and read the

The purpose of this package is to take the arch-specific files created
by the buildds and put them into an 'all' package suitable for use in
cross-compilation. When combined with emdebian, you can then easily
target any debian architecture from any other.

While I can understand that downloading files from the Internet at
large might be bad for other reasons, this package only downloads from
the debian archive itself. I could have packed all the
cross-compilation files into a 'source tarball' by manually extracting
them from the cross-built deb files, but I thought that it would be
rather dishonest to call these binary files the 'source'. The scripts
used to extract the files are the actual source.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#591174:

[Wesley W. Terpstra]

Where in the policy is it forbidden to download from the Internet? I
actually looked for this before I packaged it:

terps...@orange:/usr/share/doc/debian-policy$ zgrep -i internet policy.txt.gz
 MIME (Multipurpose Internet Mail Extensions, RFCs 2045-2049) is a
terps...@orange:/usr/share/doc/debian-policy$ zgrep -i download policy.txt.gz
 compiling from source don't have to download multiple packages.
 a Debian package: anyone can download the `.deb' file and read the

The purpose of this package is to take the arch-specific files created
by the buildds and put them into an 'all' package suitable for use in
cross-compilation. When combined with emdebian, you can then easily
target any debian architecture from any other.

While I can understand that downloading files from the Internet at
large might be bad for other reasons, this package only downloads from
the debian archive itself. I could have packed all the
cross-compilation files into a 'source tarball' by manually extracting
them from the cross-built deb files, but I thought that it would be
rather dishonest to call these binary files the 'source'. The scripts
used to extract the files are the actual source.



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Accepted mlton-cross 20100608-2 (source all)

[Wesley W. Terpstra (Debian)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 15 Jun 2010 16:07:23 +0200
Source: mlton-cross
Binary: mlton-target-i586-mingw32msvc mlton-target-amd64-mingw32msvc 
mlton-target-alpha-linux-gnu mlton-target-x86-64-linux-gnu 
mlton-target-arm-linux-gnueabi mlton-target-hppa-linux-gnu 
mlton-target-i486-linux-gnu mlton-target-ia64-linux-gnu 
mlton-target-mips-linux-gnu mlton-target-mipsel-linux-gnu 
mlton-target-powerpc-linux-gnu mlton-target-s390-linux-gnu 
mlton-target-sparc-linux-gnu
Architecture: source all
Version: 20100608-2
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org
Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org
Description: 
 mlton-target-alpha-linux-gnu - Cross-compiler support files for MLton on 
alpha-linux-gnu
 mlton-target-amd64-mingw32msvc - Cross-compiler support files for MLton on 
amd64-mingw32msvc
 mlton-target-arm-linux-gnueabi - Cross-compiler support files for MLton on 
arm-linux-gnueabi
 mlton-target-hppa-linux-gnu - Cross-compiler support files for MLton on 
hppa-linux-gnu
 mlton-target-i486-linux-gnu - Cross-compiler support files for MLton on 
i486-linux-gnu
 mlton-target-i586-mingw32msvc - Cross-compiler support files for MLton on 
i586-mingw32msvc
 mlton-target-ia64-linux-gnu - Cross-compiler support files for MLton on 
ia64-linux-gnu
 mlton-target-mips-linux-gnu - Cross-compiler support files for MLton on 
mips-linux-gnu
 mlton-target-mipsel-linux-gnu - Cross-compiler support files for MLton on 
mipsel-linux-gnu
 mlton-target-powerpc-linux-gnu - Cross-compiler support files for MLton on 
powerpc-linux-gnu
 mlton-target-s390-linux-gnu - Cross-compiler support files for MLton on 
s390-linux-gnu
 mlton-target-sparc-linux-gnu - Cross-compiler support files for MLton on 
sparc-linux-gnu
 mlton-target-x86-64-linux-gnu - Cross-compiler support files for MLton on 
x86_64-linux-gnu
Closes: 573655
Changes: 
 mlton-cross (20100608-2) unstable; urgency=low
 .
   * New upstream release
* Skipping version 20100608-1 which didn't build on mips
   * Build-depend on wget (closes: #573655)
   * Switch to quilt source format
   * Include a debian watch file
Checksums-Sha1: 
 5a4422b834f1f206da1041dbb0017fbfa5da91fa 1539 mlton-cross_20100608-2.dsc
 90f1f61805106b5e19e47a9f828479ad3aaedff7 13519 mlton-cross_20100608.orig.tar.gz
 a88722180e746cf1d71ce50324647683cc5fc467 4385 
mlton-cross_20100608-2.debian.tar.gz
 2ce03dee3a6e03a411c108440721318e61898d4c 1402524 
mlton-target-i586-mingw32msvc_20100608-2_all.deb
 aafe8baa3811bed32fb2324147d40446d104b936 1497712 
mlton-target-amd64-mingw32msvc_20100608-2_all.deb
 99eb80e3399052c710b7da2507e896ddd324d0c0 654292 
mlton-target-alpha-linux-gnu_20100608-2_all.deb
 bb34d7c3c8c18d86712cfc2fa2afae9086eeb361 502840 
mlton-target-x86-64-linux-gnu_20100608-2_all.deb
 af83b2c241289bc79ff246f38a76992301bfc929 459076 
mlton-target-arm-linux-gnueabi_20100608-2_all.deb
 5534f5ad944c4706eb0e60c7ceb9f5f405bcd2d1 577890 
mlton-target-hppa-linux-gnu_20100608-2_all.deb
 fe990a8a553801fa42fd818f2f764b21b0c3e34b 441570 
mlton-target-i486-linux-gnu_20100608-2_all.deb
 2125d619f0aab0401b89b6faca7b412a953d81a3 706948 
mlton-target-ia64-linux-gnu_20100608-2_all.deb
 c4e1adcdda8a67d1fb5bf1ed7cd0c29fa939f756 583844 
mlton-target-mips-linux-gnu_20100608-2_all.deb
 073228edefb13df041d142c5ee0ae29357105acd 581782 
mlton-target-mipsel-linux-gnu_20100608-2_all.deb
 2e7e398467e6d869711d958f338e2437f8d8fada 498010 
mlton-target-powerpc-linux-gnu_20100608-2_all.deb
 e1ada788ec086235730afd93dd6b670ba328396e 513084 
mlton-target-s390-linux-gnu_20100608-2_all.deb
 792760e236f37c0201806eb8889a90beb4297439 489612 
mlton-target-sparc-linux-gnu_20100608-2_all.deb
Checksums-Sha256: 
 b3fb5d253b41fdd1fbf1d16f8d2ce366002fa2ae5af96b03da2308fcfa5e1c98 1539 
mlton-cross_20100608-2.dsc
 95d52d837a4370be8ff4363d0f43c9b2e8ab50bfaf6eaf47f6a604c7f2b7bc6f 13519 
mlton-cross_20100608.orig.tar.gz
 601f6d58860392ccb0a15637656e1393a2085f4e1957b4a0a10d46461cdb3f06 4385 
mlton-cross_20100608-2.debian.tar.gz
 5daf20d878fb273f7ca00cbffc20a4df170e3b4f5750a9c4e7874576da507a12 1402524 
mlton-target-i586-mingw32msvc_20100608-2_all.deb
 73c92c81bd0c18337562993f70d45cf2c8ee63f68a5ab503015a341bf1c56834 1497712 
mlton-target-amd64-mingw32msvc_20100608-2_all.deb
 aecc81226c89c4b09efc4f953a7025d73526fc176b8f3cb6bd38c34dee2a9e32 654292 
mlton-target-alpha-linux-gnu_20100608-2_all.deb
 d03024a03a50da029a4daa7d4cee552a11699195a84ad83583b81635aac5cd7c 502840 
mlton-target-x86-64-linux-gnu_20100608-2_all.deb
 b05234e61182dcefe22ed2c5407dcf32c31851b9dcbf39b99d649876dd4cfe9b 459076 
mlton-target-arm-linux-gnueabi_20100608-2_all.deb
 08efe9e98e471ba8b7e06dd8f59988c82032765f3ffb37dab8328d0863f156a3 577890 
mlton-target-hppa-linux-gnu_20100608-2_all.deb
 dd896a1de6fc5e63f6355e273968cd5728ea7924ac9a7703c29a1bdaa1f3f391 441570 
mlton-target-i486-linux-gnu_20100608-2_all.deb
 32d4e61aec996e338cd7dfd620d0fb774dcf96f353b6fe17145556d7aaae14d8 706948

Accepted mlton 20100608-2 (source armel)

[Wesley W. Terpstra (Debian)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 14 Jun 2010 18:28:58 +0200
Source: mlton
Binary: mlton
Architecture: source armel
Version: 20100608-2
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org
Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org
Description: 
 mlton  - Optimizing compiler for Standard ML
Changes: 
 mlton (20100608-2) unstable; urgency=low
 .
   * Added a new '-mno-explicit-relocs' mips work-around.
* Bug filed with gcc upstream (#44537)
Checksums-Sha1: 
 c984947524711cbb50bdda76864d720969c88a3e 1202 mlton_20100608-2.dsc
 d6bdd5a2854bc94adf2124556d6316f383cf006f 9611 mlton_20100608-2.debian.tar.gz
 8f144ce329bca0109a683fa64c1e86ff650b30cf 13507086 mlton_20100608-2_armel.deb
Checksums-Sha256: 
 e4f5dc5a18ed9874f6bf501958b03e51ab278b0ad568527522524fa0cbe015f4 1202 
mlton_20100608-2.dsc
 e4949f6b7ae91fe8a9329f880341043dadc47ba3b65a0551f7cce1a55c4791c0 9611 
mlton_20100608-2.debian.tar.gz
 e76f2586eb37231145faf59fafb7442b51fe5fbbad205451efd1fa03ddef1ca1 13507086 
mlton_20100608-2_armel.deb
Files: 
 c1415f56b39a94eaac1dc791b6da9fe0 1202 devel optional mlton_20100608-2.dsc
 9cdef523efd99755b9613d3229f7ca8c 9611 devel optional 
mlton_20100608-2.debian.tar.gz
 efc51bb5c82498a508f29a76c617f9ae 13507086 devel optional 
mlton_20100608-2_armel.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwWxV8ACgkQvLvElXGKklaDKgCgkqd9rCaPwEDhNM/I/uQtsKP4
Z00AnjDZIAwMNmclAeyW9uE/NfumxGvZ
=utb1
-END PGP SIGNATURE-


Accepted:
mlton_20100608-2.debian.tar.gz
  to main/m/mlton/mlton_20100608-2.debian.tar.gz
mlton_20100608-2.dsc
  to main/m/mlton/mlton_20100608-2.dsc
mlton_20100608-2_armel.deb
  to main/m/mlton/mlton_20100608-2_armel.deb


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ookjj-00062t...@ries.debian.org

Accepted mlton 20100608-1 (source amd64)

[Wesley W. Terpstra (Debian)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 11 Jun 2010 16:11:59 +0200
Source: mlton
Binary: mlton
Architecture: source amd64
Version: 20100608-1
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org
Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org
Description: 
 mlton  - Optimizing compiler for Standard ML
Changes: 
 mlton (20100608-1) unstable; urgency=low
 .
   * New upstream release
   * Removed the mips -fPIC work-around
* Filing a new gcc bug report upstream
Checksums-Sha1: 
 136f9cde8c4042a65eee9bd0df638e0f841685bd 1202 mlton_20100608-1.dsc
 919b3d0aac8bf8ef09265491e3b22665bd94c5c1 5785771 mlton_20100608.orig.tar.gz
 06367a62af21524d420e0caa6504f3aece0cc981 9056 mlton_20100608-1.debian.tar.gz
 1d474a5f5d47f7d0599e50e9282aa8fb154e13f1 12142254 mlton_20100608-1_amd64.deb
Checksums-Sha256: 
 91b6886e360e3852dc29600614e1bd28115e18fb3473a38ceaeb13608bef5bc4 1202 
mlton_20100608-1.dsc
 f2cb2cf0d6ca8e00331b15e3d23ede05080742895e79e73d2c26a546cd1c0b33 5785771 
mlton_20100608.orig.tar.gz
 7a95b602eca484851b1d9529b624950958fd294a10faab3aeb4b3a413c528f9e 9056 
mlton_20100608-1.debian.tar.gz
 91bd6577cfd0bc2d84631da7f1d7586ab54f487050bb8c1bdefeac9df438e970 12142254 
mlton_20100608-1_amd64.deb
Files: 
 ef4351cc8e2ca91c4afbec4588ea77c8 1202 devel optional mlton_20100608-1.dsc
 8c53b68492a8aa41de06d35dc0e9d8fa 5785771 devel optional 
mlton_20100608.orig.tar.gz
 453cdc6567c3752997cc4e68fb0fd970 9056 devel optional 
mlton_20100608-1.debian.tar.gz
 2e7994a9f43038666ac1027374e33590 12142254 devel optional 
mlton_20100608-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwSqB4ACgkQvLvElXGKklaNzACeJ8Numd/NAVonlDumPUv4Lsax
x+0AoImkr5aXAl4UMqsRydCdqXHLrkJM
=yK76
-END PGP SIGNATURE-


Accepted:
mlton_20100608-1.debian.tar.gz
  to main/m/mlton/mlton_20100608-1.debian.tar.gz
mlton_20100608-1.dsc
  to main/m/mlton/mlton_20100608-1.dsc
mlton_20100608-1_amd64.deb
  to main/m/mlton/mlton_20100608-1_amd64.deb
mlton_20100608.orig.tar.gz
  to main/m/mlton/mlton_20100608.orig.tar.gz


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1onbza-0004gc...@ries.debian.org

Bug#552314: gcc 4.3.4 even worse

[Wesley W. Terpstra]

The 'use -fPIC' hack I've been using to avoid this problem doesn't help with
the newest gcc in sid.


https://buildd.debian.org/fetch.cgi?pkg=mltonarch=mipsver=20100504~svn-r7459stamp=1273006902file=logas=raw


  gcc -std=gnu99 -c -I/usr/lib/mlton/targets/self/include \
  -I/usr/lib/mlton/include -O1 -fno-common -fno-strict-aliasing \
  -fomit-frame-pointer -w -fPIC -o /tmp/fileTmKIAk.o \
  /tmp/file6ErB3L.257.c
/tmp/cc0HroCk.s: Assembler messages:
/tmp/cc0HroCk.s:58809: Error: Branch out of range


I suppose I should be grateful that the bug no longer causes invalid code to
be generated. Can someone please look into this problem? From reports I've
found with google, mips has had this problem on and off for over five years.
Wouldn't it be sensible to just add a bit of wiggle room to the test which
determines whether a near or far branch instruction is appropriate? Maybe a
simple heuristic like 'within 10 instructions of being outside of short
reach means use a far instruction'?

Bug#552314: gcc 4.3.4 even worse

[Wesley W. Terpstra]

The 'use -fPIC' hack I've been using to avoid this problem doesn't help with
the newest gcc in sid.


https://buildd.debian.org/fetch.cgi?pkg=mltonarch=mipsver=20100504~svn-r7459stamp=1273006902file=logas=raw


  gcc -std=gnu99 -c -I/usr/lib/mlton/targets/self/include \
  -I/usr/lib/mlton/include -O1 -fno-common -fno-strict-aliasing \
  -fomit-frame-pointer -w -fPIC -o /tmp/fileTmKIAk.o \
  /tmp/file6ErB3L.257.c
/tmp/cc0HroCk.s: Assembler messages:
/tmp/cc0HroCk.s:58809: Error: Branch out of range


I suppose I should be grateful that the bug no longer causes invalid code to
be generated. Can someone please look into this problem? From reports I've
found with google, mips has had this problem on and off for over five years.
Wouldn't it be sensible to just add a bit of wiggle room to the test which
determines whether a near or far branch instruction is appropriate? Maybe a
simple heuristic like 'within 10 instructions of being outside of short
reach means use a far instruction'?

Accepted mlton 20100504~svn-r7459 (source i386)

[Wesley W. Terpstra (Debian)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 04 May 2010 19:26:59 +0200
Source: mlton
Binary: mlton
Architecture: source i386
Version: 20100504~svn-r7459
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org
Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org
Description: 
 mlton  - Optimizing compiler for Standard ML
Changes: 
 mlton (20100504~svn-r7459) unstable; urgency=low
 .
   * New snapshot from svn/HEAD
* Includes fixes for PIC codegen on x86
* Better handling of memory exhaustion
* Fix aliasing problem with newest gcc
   * Switch to using quilt source format
Checksums-Sha1: 
 fb47ccc573100781a96a87e9b5038cba16a1780a 1246 mlton_20100504~svn-r7459.dsc
 52bce105d3c0b294e3acef1bc24db8f6ae6b7e28 5867986 mlton_20100504~svn.orig.tar.gz
 a8520f654c25746000edf738b898fb86b0a32dd3 9624 
mlton_20100504~svn-r7459.debian.tar.gz
 f49aa7a8fa9aa6c68f400ee34f3899e996e49149 10586144 
mlton_20100504~svn-r7459_i386.deb
Checksums-Sha256: 
 ed687241c422ea382b847b096bd53f13d8b24c9249f7fa8a43fc5e49f82fcbbf 1246 
mlton_20100504~svn-r7459.dsc
 2cdc5c9da187b4fd4cd78af44a3a9b783ec3a00090a7e1dd4ae30b130d16693a 5867986 
mlton_20100504~svn.orig.tar.gz
 5e6c1986f12bb3b74301ab22de77f983f7c7ff17445080800def7c09fcecb75b 9624 
mlton_20100504~svn-r7459.debian.tar.gz
 64f771982923be22bdffc3bb9b7773568216d13e7a2362bb8a6c9b03f9efbb2d 10586144 
mlton_20100504~svn-r7459_i386.deb
Files: 
 96cca0ea9181779102c506660b7cc0e2 1246 devel optional 
mlton_20100504~svn-r7459.dsc
 9e48025b2ebaf4dad1864094e78aa51d 5867986 devel optional 
mlton_20100504~svn.orig.tar.gz
 47267654097a72ea9cc660d1090b3cb9 9624 devel optional 
mlton_20100504~svn-r7459.debian.tar.gz
 8cdbbc3d350a0d47e9a2625a29b379bf 10586144 devel optional 
mlton_20100504~svn-r7459_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvgbv4ACgkQvLvElXGKklbLqACgpuHNJGtv8FQnPXgfpwJaGmx8
9jQAoJ3OzvB/uq+EnQ+IbeEKmcy2PClr
=UoNP
-END PGP SIGNATURE-


Accepted:
mlton_20100504~svn-r7459.debian.tar.gz
  to main/m/mlton/mlton_20100504~svn-r7459.debian.tar.gz
mlton_20100504~svn-r7459.dsc
  to main/m/mlton/mlton_20100504~svn-r7459.dsc
mlton_20100504~svn-r7459_i386.deb
  to main/m/mlton/mlton_20100504~svn-r7459_i386.deb
mlton_20100504~svn.orig.tar.gz
  to main/m/mlton/mlton_20100504~svn.orig.tar.gz


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1o9ncm-jp...@ries.debian.org

Accepted bidentd 1.1.4-1 (source i386)

[Wesley W. Terpstra (Debian)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 29 Apr 2010 16:50:54 +0200
Source: bidentd
Binary: bidentd
Architecture: source i386
Version: 1.1.4-1
Distribution: unstable
Urgency: low
Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org
Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org
Description: 
 bidentd- Bisqwit's identd for NAT proxying
Closes: 286917 558277
Changes: 
 bidentd (1.1.4-1) unstable; urgency=low
 .
   * New upstream release (closes: #286917)
   * Updated standards-version (no changes)
   * Include Russian translation (closes: #558277)
   * Switch to quilt package format
Checksums-Sha1: 
 b90b2944ba63fb6fef7d8ab83499a9efe5b3fe6c 1013 bidentd_1.1.4-1.dsc
 32353284e1bea0660866389094b0c5bdfd89fc43 22273 bidentd_1.1.4.orig.tar.gz
 734e534a982163b01f883e41834eec2784ccd968 15246 bidentd_1.1.4-1.debian.tar.gz
 529261f0eedc1eb89ed614a509041ba7d4c40c25 21512 bidentd_1.1.4-1_i386.deb
Checksums-Sha256: 
 99c71cd2b06088151a0f0fac42b1943495361d9551db86a82b0dbc5f47f3a358 1013 
bidentd_1.1.4-1.dsc
 1a15853df51967ec705546547bceb21211be8f07e1a0641206cd9fca2c9bf330 22273 
bidentd_1.1.4.orig.tar.gz
 f9f1a8ccace01c3a5e6510b70b303f2411d25e00a81dfa4d5d2f2442497d500a 15246 
bidentd_1.1.4-1.debian.tar.gz
 95710f4562b8fa609703c1e7e891d14aa34970ad1fa535a92cd12f3fdcb8a9c2 21512 
bidentd_1.1.4-1_i386.deb
Files: 
 1e2190b8626d5438d3f3e2c78505894c 1013 net extra bidentd_1.1.4-1.dsc
 a053e5e7943a9ff5ef271a25163f4a36 22273 net extra bidentd_1.1.4.orig.tar.gz
 7bf546e88f73181bba02956331bb3df1 15246 net extra bidentd_1.1.4-1.debian.tar.gz
 e5453ef1ec33852a5dcebda2da7e6266 21512 net extra bidentd_1.1.4-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvZqLoACgkQvLvElXGKklbocQCgjYXtjNNxrUbJ0hiX/iSLe6H8
3mUAoJHv8fS7IYpSNzyv+vYq8YOQLAEG
=8Q/K
-END PGP SIGNATURE-


Accepted:
bidentd_1.1.4-1.debian.tar.gz
  to main/b/bidentd/bidentd_1.1.4-1.debian.tar.gz
bidentd_1.1.4-1.dsc
  to main/b/bidentd/bidentd_1.1.4-1.dsc
bidentd_1.1.4-1_i386.deb
  to main/b/bidentd/bidentd_1.1.4-1_i386.deb
bidentd_1.1.4.orig.tar.gz
  to main/b/bidentd/bidentd_1.1.4.orig.tar.gz


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1o7wbj-0002um...@ries.debian.org