* [PATCH 06/10] RTC subsystem, RS5C372 sysfs fix
From: Alessandro Zummo @ 2006-03-31 10:04 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, akpm
In-Reply-To: <20060331100423.175139000@towertech.it>
[-- Attachment #1: rtc-subsys-rs5c372-fix-sysfs.patch --]
[-- Type: text/plain, Size: 1372 bytes --]
fixed sysfs show() return code
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
---
drivers/rtc/rtc-rs5c372.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
--- linux-rtc.orig/drivers/rtc/rtc-rs5c372.c 2006-03-29 02:41:04.000000000 +0200
+++ linux-rtc/drivers/rtc/rtc-rs5c372.c 2006-03-29 02:46:40.000000000 +0200
@@ -169,24 +169,26 @@ static struct rtc_class_ops rs5c372_rtc_
static ssize_t rs5c372_sysfs_show_trim(struct device *dev,
struct device_attribute *attr, char *buf)
{
- int trim;
+ int err, trim;
- if (rs5c372_get_trim(to_i2c_client(dev), NULL, &trim) == 0)
- return sprintf(buf, "0x%2x\n", trim);
+ err = rs5c372_get_trim(to_i2c_client(dev), NULL, &trim);
+ if (err)
+ return err;
- return 0;
+ return sprintf(buf, "0x%2x\n", trim);
}
static DEVICE_ATTR(trim, S_IRUGO, rs5c372_sysfs_show_trim, NULL);
static ssize_t rs5c372_sysfs_show_osc(struct device *dev,
struct device_attribute *attr, char *buf)
{
- int osc;
+ int err, osc;
- if (rs5c372_get_trim(to_i2c_client(dev), &osc, NULL) == 0)
- return sprintf(buf, "%d.%03d KHz\n", osc / 1000, osc % 1000);
+ err = rs5c372_get_trim(to_i2c_client(dev), &osc, NULL);
+ if (err)
+ return err;
- return 0;
+ return sprintf(buf, "%d.%03d KHz\n", osc / 1000, osc % 1000);
}
static DEVICE_ATTR(osc, S_IRUGO, rs5c372_sysfs_show_osc, NULL);
--
^ permalink raw reply
* [PATCH 05/10] RTC subsystem, fix proc output
From: Alessandro Zummo @ 2006-03-31 10:04 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, akpm, Lennert Buytenhek
In-Reply-To: <20060331100423.175139000@towertech.it>
[-- Attachment #1: rtc-subsys-fix-proc-24hr.patch --]
[-- Type: text/plain, Size: 3690 bytes --]
Moved the "24hr: yes" proc output from drivers to rtc
proc code. This is required because the time value
in the proc output is always in 24hr mode regardless
of the driver.
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: Lennert Buytenhek <buytenh@wantstofly.org>
---
drivers/rtc/rtc-ep93xx.c | 1 -
drivers/rtc/rtc-m48t86.c | 3 ---
drivers/rtc/rtc-pcf8563.c | 7 -------
drivers/rtc/rtc-proc.c | 2 ++
drivers/rtc/rtc-rs5c372.c | 5 ++---
drivers/rtc/rtc-test.c | 1 -
drivers/rtc/rtc-x1205.c | 2 --
7 files changed, 4 insertions(+), 17 deletions(-)
--- linux-rtc.orig/drivers/rtc/rtc-ep93xx.c 2006-03-29 02:14:50.000000000 +0200
+++ linux-rtc/drivers/rtc/rtc-ep93xx.c 2006-03-29 02:40:12.000000000 +0200
@@ -67,7 +67,6 @@ static int ep93xx_rtc_proc(struct device
ep93xx_get_swcomp(dev, &preload, &delete);
- seq_printf(seq, "24hr\t\t: yes\n");
seq_printf(seq, "preload\t\t: %d\n", preload);
seq_printf(seq, "delete\t\t: %d\n", delete);
--- linux-rtc.orig/drivers/rtc/rtc-pcf8563.c 2006-03-29 02:14:50.000000000 +0200
+++ linux-rtc/drivers/rtc/rtc-pcf8563.c 2006-03-29 02:40:27.000000000 +0200
@@ -227,14 +227,7 @@ static int pcf8563_rtc_set_time(struct d
return pcf8563_set_datetime(to_i2c_client(dev), tm);
}
-static int pcf8563_rtc_proc(struct device *dev, struct seq_file *seq)
-{
- seq_printf(seq, "24hr\t\t: yes\n");
- return 0;
-}
-
static struct rtc_class_ops pcf8563_rtc_ops = {
- .proc = pcf8563_rtc_proc,
.read_time = pcf8563_rtc_read_time,
.set_time = pcf8563_rtc_set_time,
};
--- linux-rtc.orig/drivers/rtc/rtc-proc.c 2006-03-29 02:14:50.000000000 +0200
+++ linux-rtc/drivers/rtc/rtc-proc.c 2006-03-29 02:39:56.000000000 +0200
@@ -71,6 +71,8 @@ static int rtc_proc_show(struct seq_file
alrm.pending ? "yes" : "no");
}
+ seq_printf(seq, "24hr\t\t: yes\n");
+
if (ops->proc)
ops->proc(class_dev->dev, seq);
--- linux-rtc.orig/drivers/rtc/rtc-rs5c372.c 2006-03-29 02:14:50.000000000 +0200
+++ linux-rtc/drivers/rtc/rtc-rs5c372.c 2006-03-29 02:46:57.000000000 +0200
@@ -151,9 +151,8 @@ static int rs5c372_rtc_proc(struct devic
{
int err, osc, trim;
- seq_printf(seq, "24hr\t\t: yes\n");
-
- if ((err = rs5c372_get_trim(to_i2c_client(dev), &osc, &trim)) == 0) {
+ err = rs5c372_get_trim(to_i2c_client(dev), &osc, &trim);
+ if (err == 0) {
seq_printf(seq, "%d.%03d KHz\n", osc / 1000, osc % 1000);
seq_printf(seq, "trim\t: %d\n", trim);
}
--- linux-rtc.orig/drivers/rtc/rtc-x1205.c 2006-03-29 02:38:39.000000000 +0200
+++ linux-rtc/drivers/rtc/rtc-x1205.c 2006-03-29 02:39:46.000000000 +0200
@@ -451,8 +451,6 @@ static int x1205_rtc_proc(struct device
{
int err, dtrim, atrim;
- seq_printf(seq, "24hr\t\t: yes\n");
-
if ((err = x1205_get_dtrim(to_i2c_client(dev), &dtrim)) == 0)
seq_printf(seq, "digital_trim\t: %d ppm\n", dtrim);
--- linux-rtc.orig/drivers/rtc/rtc-m48t86.c 2006-03-29 02:14:50.000000000 +0200
+++ linux-rtc/drivers/rtc/rtc-m48t86.c 2006-03-29 02:42:37.000000000 +0200
@@ -127,9 +127,6 @@ static int m48t86_rtc_proc(struct device
reg = ops->readb(M48T86_REG_B);
- seq_printf(seq, "24hr\t\t: %s\n",
- (reg & M48T86_REG_B_H24) ? "yes" : "no");
-
seq_printf(seq, "mode\t\t: %s\n",
(reg & M48T86_REG_B_DM) ? "binary" : "bcd");
--- linux-rtc.orig/drivers/rtc/rtc-test.c 2006-03-29 02:14:50.000000000 +0200
+++ linux-rtc/drivers/rtc/rtc-test.c 2006-03-29 02:42:54.000000000 +0200
@@ -49,7 +49,6 @@ static int test_rtc_proc(struct device *
{
struct platform_device *plat_dev = to_platform_device(dev);
- seq_printf(seq, "24hr\t\t: yes\n");
seq_printf(seq, "test\t\t: yes\n");
seq_printf(seq, "id\t\t: %d\n", plat_dev->id);
--
^ permalink raw reply
* [PATCH 03/10] RTC subsystem, X1205 sysfs cleanup
From: Alessandro Zummo @ 2006-03-31 10:04 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, akpm
In-Reply-To: <20060331100423.175139000@towertech.it>
[-- Attachment #1: rtc-subsys-x1205-fix-sysfs.patch --]
[-- Type: text/plain, Size: 1604 bytes --]
fixed sysfs show() return code
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
---
drivers/rtc/rtc-x1205.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
--- linux-rtc.orig/drivers/rtc/rtc-x1205.c 2006-03-29 02:14:50.000000000 +0200
+++ linux-rtc/drivers/rtc/rtc-x1205.c 2006-03-29 02:33:57.000000000 +0200
@@ -19,7 +19,7 @@
#include <linux/rtc.h>
#include <linux/delay.h>
-#define DRV_VERSION "1.0.6"
+#define DRV_VERSION "1.0.7"
/* Addresses to scan: none. This chip is located at
* 0x6f and uses a two bytes register addressing.
@@ -473,24 +473,26 @@ static struct rtc_class_ops x1205_rtc_op
static ssize_t x1205_sysfs_show_atrim(struct device *dev,
struct device_attribute *attr, char *buf)
{
- int atrim;
+ int err, atrim;
- if (x1205_get_atrim(to_i2c_client(dev), &atrim) == 0)
- return sprintf(buf, "%d.%02d pF\n",
- atrim / 1000, atrim % 1000);
- return 0;
+ err = x1205_get_atrim(to_i2c_client(dev), &atrim);
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d.%02d pF\n", atrim / 1000, atrim % 1000);
}
static DEVICE_ATTR(atrim, S_IRUGO, x1205_sysfs_show_atrim, NULL);
static ssize_t x1205_sysfs_show_dtrim(struct device *dev,
struct device_attribute *attr, char *buf)
{
- int dtrim;
+ int err, dtrim;
- if (x1205_get_dtrim(to_i2c_client(dev), &dtrim) == 0)
- return sprintf(buf, "%d ppm\n", dtrim);
+ err = x1205_get_dtrim(to_i2c_client(dev), &dtrim);
+ if (err)
+ return err;
- return 0;
+ return sprintf(buf, "%d ppm\n", dtrim);
}
static DEVICE_ATTR(dtrim, S_IRUGO, x1205_sysfs_show_dtrim, NULL);
--
^ permalink raw reply
* [PATCH 00/10] RTC subsystem
From: Alessandro Zummo @ 2006-03-31 10:04 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, akpm
RTC subsystem.
- general cleanup of white spaces and error messages
- new NEC VR41XX driver
- fixed some sysfs error codes
- oscillator handling in ds1672
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
--
^ permalink raw reply
* [PATCH/RFC] libata: disable interrupts before soft reset
From: Albert Lee @ 2006-03-31 10:04 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Tejun Heo, Doug Maxey, IDE Linux
Changes:
- add ata_irq_off() to libata.h
- call ata_irq_off() to disable the interrupt before soft reset
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
---
When testing an old 1996 Acer 8x CD-ROM drive (CD-787E), an
interrupt is generated in ata_devchk(), right after the device is selected.
(The unhandled irq cause the IRQ 10 to be disabled.)
Disabling interrupts before doing soft reset fixes the problem.
However, this problem is only seen on the specific CD-ROM drive.
So, don't know whether the fix is necessary.
Patch against upstream (8b316a3973f05e572b4edeeda9072987f6bbaa44).
For your review, thanks.
Albert
===================================================
(Attached detailed dmesg for your reference)
pata_pdc2027x 0000:02:05.0: version 0.74
ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10
ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
pata_pdc2027x 0000:02:05.0: PLL input clock 16718 kHz
ata3: PATA max UDMA/133 cmd 0x989517C0 ctl 0x98951FDA bmdma 0x98951000 irq 10
ata4: PATA max UDMA/133 cmd 0x989515C0 ctl 0x98951DDA bmdma 0x98951008 irq 10
checking device 0
selecting checking device 0
irq 10: nobody cared (try booting with the "irqpoll" option)
<78139444> __report_bad_irq+0x24/0x7f <78139516> note_interrupt+0x77/0x21d
<78138f0d> handle_IRQ_event+0x2e/0x5a <78139003> __do_IRQ+0xca/0xd7
<78104708> do_IRQ+0x53/0x8b
=======================
<78102f4e> common_interrupt+0x1a/0x20 <7811e589> __do_softirq+0x37/0x95
<7810478f> do_softirq+0x4f/0x60
=======================
<7811e475> irq_exit+0x37/0x39 <7810470f> do_IRQ+0x5a/0x8b
<78102f4e> common_interrupt+0x1a/0x20 <98884ce0> ata_altstatus+0x29/0x2d [libata]
<9887e9d6> ata_std_dev_select+0x23/0x47 [libata] <9887ea2c> ata_devchk+0x32/0x135 [libata]
<9887fde7> ata_std_softreset+0x52/0x11a [libata] <9887fd95> ata_std_softreset+0x0/0x11a [libata]
<9887fac5> ata_std_postreset+0x0/0x12a [libata] <9887d45d> do_probe_reset+0x2b/0x82 [libata]
<9887fd95> ata_std_softreset+0x0/0x11a [libata] <9887fac5> ata_std_postreset+0x0/0x12a [libata]
<9887d4ee> ata_drive_probe_reset+0x3a/0x7d [libata] <989425ae> pdc2027x_probe_reset+0x60/0x65 [pata_pdc2027x]
<9887fac5> ata_std_postreset+0x0/0x12a [libata] <98881b84> ata_device_add+0x428/0x648 [libata]
<98942449> pdc2027x_init_one+0x29f/0x348 [pata_pdc2027x] <781de777> pci_device_probe+0x40/0x5b
<7823fe24> driver_probe_device+0x3b/0xb0 <7823ff88> __driver_attach+0x82/0x84
<7823f457> bus_for_each_dev+0x39/0x57 <7823fd16> driver_attach+0x16/0x1a
<7823ff06> __driver_attach+0x0/0x84 <7823f71c> bus_add_driver+0x63/0x110
<782402da> driver_register+0x41/0xb4 <781de3c8> __pci_register_driver+0x65/0x86
<781317af> sys_init_module+0x114/0x1731 <9887d79a> ata_port_start+0x0/0x7e [libata]
<78102d1b> sysenter_past_esp+0x54/0x75
handlers:
[<98881f1e>] (ata_interrupt+0x0/0x282 [libata])
Disabling IRQ #10
writing pattern 1 device 0
writing pattern 2 device 0
writing pattern 3 device 0
reading pattern 4 device 0
device found 1
checking device 1
selecting checking device 1
writing pattern 1 device 1
writing pattern 2 device 1
writing pattern 3 device 1
reading pattern 4 device 1
device found 1
select dev 0
======================================
diff -Nrup upstream0/drivers/scsi/libata-core.c reset_irq_off/drivers/scsi/libata-core.c
--- upstream0/drivers/scsi/libata-core.c 2006-03-31 13:33:15.000000000 +0800
+++ reset_irq_off/drivers/scsi/libata-core.c 2006-03-31 17:12:28.000000000 +0800
@@ -2069,6 +2069,10 @@ void ata_bus_reset(struct ata_port *ap)
DPRINTK("ENTER, host %u, port %u\n", ap->id, ap->port_no);
+ /* disable interrupts */
+ if (ap->ioaddr.ctl_addr) /* FIXME: hack. create a hook instead */
+ ata_irq_off(ap);
+
/* determine if device 0/1 are present */
if (ap->flags & ATA_FLAG_SATA_RESET)
dev0 = 1;
@@ -2199,6 +2203,10 @@ int ata_std_softreset(struct ata_port *a
goto out;
}
+ /* disable interrupts */
+ if (ap->ioaddr.ctl_addr) /* FIXME: hack. create a hook instead */
+ ata_irq_off(ap);
+
/* determine if device 0/1 are present */
if (ata_devchk(ap, 0))
devmask |= (1 << 0);
diff -Nrup upstream0/include/linux/libata.h reset_irq_off/include/linux/libata.h
--- upstream0/include/linux/libata.h 2006-03-31 13:33:24.000000000 +0800
+++ reset_irq_off/include/linux/libata.h 2006-03-31 17:07:04.000000000 +0800
@@ -840,6 +840,35 @@ static inline u8 ata_irq_on(struct ata_p
return tmp;
}
+/**
+ * ata_irq_off - Disable interrupts on a port.
+ * @ap: Port on which interrupts are disabled.
+ *
+ * Disable interrupts on a legacy IDE device using MMIO or PIO,
+ * wait for idle, clear any pending interrupts.
+ *
+ * LOCKING:
+ * Inherited from caller.
+ */
+
+static inline u8 ata_irq_off(struct ata_port *ap)
+{
+ struct ata_ioports *ioaddr = &ap->ioaddr;
+ u8 tmp;
+
+ ap->ctl |= ATA_NIEN;
+ ap->last_ctl = ap->ctl;
+
+ if (ap->flags & ATA_FLAG_MMIO)
+ writeb(ap->ctl, (void __iomem *) ioaddr->ctl_addr);
+ else
+ outb(ap->ctl, ioaddr->ctl_addr);
+ tmp = ata_wait_idle(ap);
+
+ ap->ops->irq_clear(ap);
+
+ return tmp;
+}
/**
* ata_irq_ack - Acknowledge a device interrupt.
^ permalink raw reply
* Re: 230GB partition mount problem
From: Genco YILMAZ @ 2006-03-31 10:02 UTC (permalink / raw)
To: Vincent Roqueta; +Cc: nfs
In-Reply-To: <200603311057.21433.vincent.roqueta@bull.net>
[-- Attachment #1: Type: text/html, Size: 3440 bytes --]
^ permalink raw reply
* Re: Midi name string in mpu401_uart not unique
From: Alan Horstmann @ 2006-03-31 10:02 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hpsk3n7jw.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]
On Thursday 30 March 2006 18:53, you wrote:
> At Thu, 30 Mar 2006 18:45:23 +0100,
> Alan Horstmann wrote:
> > On Thursday 30 March 2006 12:04, you wrote:
> > >
> > > Instead of adding a new argument to snd_mpu401_uart_new, the caller
> > > can overwrite the string after creating the instace.
> > >
> > > snd_mpu401_uart_new(card, device, type, ..., &rmidi);
> > > snprintf(rmidi->name, sizeof(rmidi->name),
> > > "MIDI Name As I Like %d", card->number);
> > >
> > > Then the change would be less intrusive.
> > >
> > > Or am I missing something else?
> >
> > Sounds a lot simpler -just involving the driver only; I will try this
> > later. In the mpu-names.diff midi names were added to
> > snd_ice1712_card_info to be used in the name string. Is that still a
> > reasonable thing to do, or is there a better place, given that the
> > different sub-vendors might have different requirements?
>
> That addition looks OK to me. What I don't want is to change the
> existing API if there is a simple solution.
>
> > Bearing in mind Clemens' comments, is there any value in improving the
> > name given by mpu401_uart_new when using ->shortname, as in the diff, by
> > adding card and device numbers?
>
> Maybe the order of "CARD DEVICE" like "DMX6fire WaveTable" is better?
> Just a matter of taste, though...
Would it be acceptable to add card, device to ->shortname in mpu401_uart as
attached:
mpu401_uart.c-add-to-shortname.patch
Add card and device numbers to portnames generated from ->shortnames by
snd_mpu401_uart_new.
Signed-off-by: Alan Horstmann <gineera@aspect135.co.uk>
[-- Attachment #2: mpu401_uart.c-add-to-shortname.patch --]
[-- Type: text/x-diff, Size: 545 bytes --]
--- mpu401_uart-orig.c 2005-11-18 18:52:14.000000000 +0000
+++ mpu401_uart.c 2006-03-31 10:33:33.000000000 +0100
@@ -506,7 +506,7 @@
mpu->irq = irq;
mpu->irq_flags = irq_flags;
if (card->shortname[0])
- snprintf(rmidi->name, sizeof(rmidi->name), "%s MIDI", card->shortname);
+ snprintf(rmidi->name, sizeof(rmidi->name), "%s MIDI %d-%d", card->shortname, card->number, device);
else
sprintf(rmidi->name, "MPU-401 MIDI %d-%d", card->number, device);
snd_rawmidi_set_ops(rmidi, SNDRV_RAWMIDI_STREAM_OUTPUT, &snd_mpu401_uart_output);
^ permalink raw reply
* Re: [PATCH/RFC] MTD: Striping layer core
From: Artem B. Bityutskiy @ 2006-03-31 10:00 UTC (permalink / raw)
To: Jörn Engel
Cc: Alexander Belyakov, Korolev, Alexey, Vitaly Wool,
Kutergin, Timofey, linux-mtd
In-Reply-To: <20060331094050.GB14713@wohnheim.fh-wedel.de>
On Fri, 2006-03-31 at 11:40 +0200, Jörn Engel wrote:
> On Fri, 31 March 2006 13:36:43 +0400, Artem B. Bityutskiy wrote:
> >
> > No, mtd->type has to tell you the type of the MTD device. Ideally, this
> > has to me the only flash-specific field in the mtd_info structure. And
> > if users want to do some flash specific things, they have to look at
> > mtd->type, realize what is the subsystem which handles this flash, and
> > start working with this subsystem. For striping, this is the striping
> > subsystem. I don't know what for mtd->flags, probably this hast to go at
> > all.
>
> Is this exported to userspace via mtdchar?
>
I don't quite understand what is "this".
Ideally yes, there should be a /ubi/devices/mtd/mtdX/type file, there
you can look and realize the type of this MTD device. The contents of
this file will be generated using the mtd-type field. Userspace will be
able to realize the type of this device and look to the corresponding
place in sysfs. For example, if this is a striped device, it'll look
at /sys/devices/mtd_stripe/stripe0/ or whatever.
This is just my imagination how things should look like. So, treat this
correspondingly. May be it is better to use symlinks in sysfs to point
to the striping layer, no sure.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
^ permalink raw reply
* Re: [PATCH] splice support #2
From: Jens Axboe @ 2006-03-31 9:57 UTC (permalink / raw)
To: tridge; +Cc: linux-kernel, Linus Torvalds
In-Reply-To: <17452.50912.404106.256236@samba.org>
On Fri, Mar 31 2006, tridge@samba.org wrote:
> Linus and Jens,
>
> Stephen Rothwell just pointed me at the new splice() interface. Looks
> really nice!
>
> One comment though. Could we add a off_t to splice to make it more
> like pwrite() ? Otherwise threads could get painful with race
> conditions between the seek and the splice() call.
>
> Either that or add psplice() like this:
>
> ssize_t psplice(int fdin, int fdout, size_t len, off_t ofs, unsigned flags);
>
> where ofs sets the offset to read from fdin.
I definitely see some valid reasons for adding a file offset instead of
using ->f_pos, I'll leave that decision up to Linus though. Linus?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] splice support #2
From: Jens Axboe @ 2006-03-31 9:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Molnar, linux-kernel, akpm
In-Reply-To: <Pine.LNX.4.64.0603300853190.27203@g5.osdl.org>
On Thu, Mar 30 2006, Linus Torvalds wrote:
>
>
> On Thu, 30 Mar 2006, Jens Axboe wrote:
> > On Thu, Mar 30 2006, Ingo Molnar wrote:
> > >
> > > neat stuff. One question: why do we require fdin or fdout to be a pipe?
> > > Is there any fundamental problem with implementing what Larry's original
> > > paper described too: straight pagecache -> socket transfers? Without a
> > > pipe intermediary forced inbetween. It only adds unnecessary overhead.
> >
> > No, not a fundamental problem. I think I even hid that in some comment
> > in there, at least if it's decipharable by someone else than myself...
>
> Actually, there _is_ a fundamental problem. Two of them, in fact.
>
> The reason it goes through a pipe is two-fold:
>
> - the pipe _is_ the buffer. The reason sendfile() sucks is that sendfile
> cannot work with <n> different buffer representations. sendfile() only
> works with _one_ buffer representation, namely the "page cache of the
> file".
>
> By using the page cache directly, sendfile() doesn't need any extra
> buffering, but that's also why sendfile() fundamentally _cannot_ work
> with anything else. You cannot do "sendfile" between two sockets to
> forward data from one place to another, for example. You cannot do
> sendfile from a streaming device.
>
> The pipe is just the standard in-kernel buffer between two arbitrary
> points. Think of it as a scatter-gather list with a wait-queue. That's
> what a pipe _is_. Trying to get rid of the pipe totally misses the
> whole point of splice().
>
> Now, we could have a splice call that has an _implicit_ pipe, ie if
> neither side is a pipe, we could create a temporary pipe and thus
> allow what looks like a direct splice. But the pipe should still be
> there.
>
> - The pipe is the buffer #2: it's what allows you to do _other_ things
> with splice that are simply impossible to do with sendfile. Notably,
> splice allows very naturally the "readv/writev" scatter-gather
> behaviour of _mixing_ streams. If you're a web-server, with splice you
> can do
>
> write(pipefd, header, header_len);
> splice(file, pipefd, file_len);
> splice(pipefd, socket, total_len);
>
> (this is all conceptual pseudo-code, of course), and this very
> naturally has none of the issues that sendfile() has with plugging etc.
> There's never any "send header separately and do extra work to make
> sure it is in the same packet as the start of the data".
>
> So having a separate buffer even when you _do_ have a buffer like the
> page cache is still something you want to do.
>
> So there.
My point was mainly that the buffer itself need not necessarily be a
pipe, it could be implemented with a pipe just using the same buffer
type. But I guess it doesn't make much sense, the pipe has nice
advantages in itself.
--
Jens Axboe
^ permalink raw reply
* Re: [Xenomai-help] Non-deterministic behaviour in primary mode
From: Philippe Gerum @ 2006-03-31 9:55 UTC (permalink / raw)
To: Saul; +Cc: xenomai
In-Reply-To: <1143790982.14016.257982746@domain.hid>
Saul wrote:
> Philippe Gerum wrote:
>
>>Mm, this really looks like some firmware/BIOS cyclic activity, that
>>would hit the busy loop more or less frequently, depending on the
>>internal timing of the outer loop. This reminds me that some recent
>>Intel chipset are known to prevent global SMI disabling actually, maybe
>>this is the case here, so our work-around would be basically useless.
>>Another usual suspect is NMI handling (which the Adeos layer does not
>>pipeline but rather delivers immediately), but I guess that you did not
>>activate the NMI watchdog anyway, so back to square #1, I guess.
>
>
> No, I never enabled the NMI watchdog.
>
> Yeah, that doesn't sound good for me. I just tried, for the first time,
> allowing SMI to remain enabled. Behaves exactly the same :( A failure
> to disable SMI would also explain why none of my peripherals were ever
> affected.
>
> I thought SMI was supposed to increase latencies, but I only see
> latencies < 60us at any load, unless I start video capture. Does the
> latency test absolutely rule out SMI as the cause?
Not really, e.g. if the video capture device is USB-attached, then SMI
could possibly remain in the picture.
Is there any way to
> check whether SMI is actually disabled?
>
Gilles will likely have more clue here, but I guess that reading back
the state of the GBL_SMI_EN_BIT from the SMI's MMIO space would
probably tell us if a previous request to disable SMI globally did
succeed or not. The code in question is in ksrc/arch/i386/smi.c.
Another option to cross-check that we might have an SMI issue would be
to find a box with an ICH4 chipset which is known to be reasonably
controllable by our SMI work-around, and try to do video capture using
it after Xenomai has globally disabled SMI sources.
> Thanks,
> Saul.
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
^ permalink raw reply
* Re: Save 320K on production machines?
From: Jörn Engel @ 2006-03-31 9:48 UTC (permalink / raw)
To: Linda Walsh; +Cc: Paulo Marques, Adrian Bunk, Jan Engelhardt, Linux-Kernel
In-Reply-To: <442C4ECF.3080505@tlinx.org>
On Thu, 30 March 2006 13:34:07 -0800, Linda Walsh wrote:
>
> 1) It would be nice if a "stack usage" option could be turned on
> that would do some sort of run-time bounds checking that could
> display the max-stack used "so far" in "/proc".
Would CONFIG_DEBUG_STACK_USAGE=y do what you want?
> 2) How difficult would it be to place kernel stack in a "pageable" pool
> where the limit of valid data in a 4K page is only 3.5K - then
> when a kernel routine tries to exceed the stack boundary, it takes a
> page fault where a "note" could be logged that more stack was "needed",
> then automatically map another 4K page into the stack and return to
> interrupted routine.
S390 has something a bit like that. They can specify the stack limit
and get an exception when a function is trying to grow the stack
beyond the limit. Martin Schwidefsky might know the details a bit
better.
Jörn
--
You ain't got no problem, Jules. I'm on the motherfucker. Go back in
there, chill them niggers out and wait for the Wolf, who should be
coming directly.
-- Marsellus Wallace
^ permalink raw reply
* Re: 2.6.16-mm1 leaks in dvb playback (found)
From: Adrian Bridgett @ 2006-03-31 9:54 UTC (permalink / raw)
To: David S. Miller; +Cc: ak, akpm, linux-kernel
In-Reply-To: <20060330.234823.109651253.davem@davemloft.net>
On Thu, Mar 30, 2006 at 23:48:23 -0800 (-0800), David S. Miller wrote:
> As I stated, there was a bug in the initial patch, which subsequent
> patches fix.
>
> Can you try Linus's current tree to see if the problem is there?
2-6-16-git18 still has the problem (30th March).
Adrian
^ permalink raw reply
* Re: Gateway cluster using iptables and CLUSTERIP
From: KOVACS Krisztian @ 2006-03-31 9:54 UTC (permalink / raw)
To: netfilter
In-Reply-To: <A78C6C481BFAE949BC5990E1EEB2FE125715@q.LeBlancNet.us>
Hi,
On Thursday 30 March 2006 18.31, Robert LeBlanc wrote:
> iptables -A INPUT -I eth1 -d 10.0.0.1 -j CLUSTERIP -new -hashmode
> sourceip -clustermac 01:83:91:A7:0D:33 -total-nodes 1 -local-nodes 1
>
> I have entered only one node in the cluster so that I would not have to
> bring up both nodes during the testing or remember to add the other node
> to /proc/net/ipt_CLUSTERIP/10.0.0.1.
Strange. Please note that apparently there are very few CLUSTERIP users
out there, so this might also be a bug. Does setting total-nodes to 2 help?
--
Regards,
Krisztian Kovacs
^ permalink raw reply
* Re: software raid1
From: Marco Gerards @ 2006-03-31 9:54 UTC (permalink / raw)
To: The development of GRUB 2
In-Reply-To: <1120.213.192.3.1.1143611287.squirrel@drak.ucw.cz>
Tomáš Ebenlendr <ebik@drak.ucw.cz> writes:
>> ... but grub loads the kernel and the ramdisk, and then the kernel
>> executes the ramdisk. The RAID has to work (for reads, anyway) before
>> then.
>>
>> --
>> Peter
>
> What do you mean work? Grub will read from one disk ignoring it is in RAID1,
> in this case. And I don't know current implementation of raid now, but there
> was implementation where one must say to kernel by script (in ramdisk)
> which partition is joint whith wich... But now there might be some
> autodetection...
RAID is more than just RAID1. Actually RAID1 is not that used that
much in practise I think. Most setups I have seen are either RAID0 or
RAID5.
--
Marco
^ permalink raw reply
* Re: What is /dev/snd/hwC0D0 used for ?
From: Takashi Iwai @ 2006-03-31 9:53 UTC (permalink / raw)
To: Lee Revell; +Cc: paul, Carlos Munoz, alsa-devel
In-Reply-To: <1143773231.22771.15.camel@mindpipe>
At Thu, 30 Mar 2006 21:47:10 -0500,
Lee Revell wrote:
>
> On Thu, 2006-03-30 at 20:45 -0500, Paul Davis wrote:
> > On Thu, 2006-03-30 at 16:37 -0500, Lee Revell wrote:
> > > > Is there a document explaining what all the devices are used for ? I
> > > > searched but didn't find anything.
> > > >
> > >
> > > No because these interfaces are intended to be private to alsa-lib. The
> > > source code is authoritative.
> >
> > is this confirmed policy?
> >
>
> Nope, just my understanding of the situation. Corrections are welcome.
It's right about the access to the "device file". They can be all
accessed gracefully via alsa-lib, and that's preferred.
But it's not intentional that there are no documents about that. Just
no time and interest for such a thing :)
> > what happens about support for devices that have classes of control
> > that do not fit into the existing ALSA schema and have traditionally
> > been handled via device-specific ioctl's on /dev/snd/hwFOO ?
> >
>
> Good question. I know the upstream kernel policy is "no new ioctls,
> period"...
The hwdep can have its own reads, writes, ioctls, whatever. Iit's the
very reason of this device.
The hwdep-specific methods can be issued from alsa-lib such as
snd_hwdep_read(), snd_hwdep_write(), snd_hwdep_ioctl(). The mmap is
not implmented as alsa-lib's method, so you'd need to do it manually
using snd_hwdep_poll_descriptor(). Maybe this should be properly
implemented, too.
Takashi
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: grub 1.92
From: Marco Gerards @ 2006-03-31 9:52 UTC (permalink / raw)
To: The development of GRUB 2
In-Reply-To: <642564037.20060331055951@opanki.ru>
"Sergey Ya. Korshunoff" <seyko@opanki.ru> writes:
Hi Sergey,
> grub 1.92 is already quite usefull.
> I use it as a boot loader in my GENTOO partition.
>
> But current version of GRUB2 (1.93 from CVS) reports about pointer misaligment and hangs
> (no any text menu posiible). Any plans to fix this? (I use x86 hardware).
Right, this is what happens when a parse error occurs. This is a big
problem and my highest priority.
> Suggestions about grub2 1.92
>
> 1) Make it possible to coexist with grub 0.97:
> -- /boot/grub2 intstead of /boot/grub as target for install scripts
> -- rename scripts to grub2-install etc...
> -- /usr/lib/grub2 and etc....
>
> Then user can select wich version of grub to install on some
> partition
It's a replacement. But I think there is a configure feature that
allows you to rename binaries and scripts before installing. The
/boot/grub directory being shared should not course any problems.
> 2) It is nice to keep clean /boot/grub2 from modules (put them in
> subdir like /boot/grub2/modules)
There were some discussions about subdirectories for the kinds of
modules. Like fs/, commands/, etc. But I do not remember the outcome
of that discussion. :-)
> 3) some grub-cfg.txt with sample menu for grub2-install to put into
> /boot/grub2 (as it do with fs.lst and modules.lst)
When I fixed things, I will put an example on the wiki.
> Currenly user need to search sources to find default name for menu and
> how is can look.
What do you mean?
> 4) Minor error: when pager=1 then it works and in menu mode (when we
> ask to edit some menu line or return back). And maybe pager=1 by
> defaults?
Do you mean it should be disabled in the menu editor?
I do not think it is wise to enable it by default. But you could put
it in your grub.cfg.
--
Marco
^ permalink raw reply
* NFS client (10x) performance regression 2.6.14.7 -> 2.6.15
From: Jakob Oestergaard @ 2006-03-31 9:48 UTC (permalink / raw)
To: linux-kernel
Hi guys,
I just found out... Installed 2.6.16.1 (32-bit) on a spanking new dual
opteron 275 (dual-core) machine, and saw that my link jobs were taking
ages.
I narrowed it down a bit - these are the kernels I have tested:
2.6.13.5: Good
2.6.14.7: Good
2.6.15: Poor
2.6.15.7: Poor
2.6.16.1: Poor
Sequential NFS I/O is good on all kernels. Only "ld" shows the problem.
On 2.6.14.7, I can run a large link job creating a 60 MB executable in
15.6 seconds wall-clock time.
On 2.6.15, the same link job takes 2 minutes 28 seconds.
This is almost 10 *times* longer.
Testing with tiobench, I can see no notable difference between the
kernels (!) It seems that this is very specific to ld. I am using GNU
ld version 2.15.
The NFS client mounts the working directory using NFS v3 over UDP with
default (32k) rsize/wsize.
Since this machine is not in production yet, I can experiment with
kernel patches on it - I would like to try and narrow this down even
further - any suggestions as to which patches to exclude/include will be
greatly appreciated.
Note; I did double-check all the common problems (ethernet problems,
mount options, ...).
--
/ jakob
^ permalink raw reply
* Re: [PATCH] This patch fixes several issues related to vmxassist
From: Keir Fraser @ 2006-03-31 9:48 UTC (permalink / raw)
To: Li, Xin B; +Cc: Xen Devel
In-Reply-To: <59D45D057E9702469E5775CBB56411F10222A7D9@pdsmsx406>
On 30 Mar 2006, at 18:02, Li, Xin B wrote:
>> Shouldn't we get the Xen portion of vmxassist help us with that, for
>> example by making the hidden descriptor info (base, limit, etc)
>> available to us? There's already a method for loading that
>> stuff out of
>> Xen, right?
>>
>> Looks to me as though the kludge won't work if you unluckily load a
>> real-mode segment value that happens to also reference a 'big segment'
>> in the currently registered GDT.
>
> Yes, we may have potential bug here, maybe we should hold this patch
> and try to find a cleaner way.
> -Xin
In fact, the existing implementation of address() is kludgy. It already
does tests on the selector value to decide whether it is likely to
refer to a protected-mode or real-mode segment. Unfortunately the test
may sometimes yield false positives (selectors that look like they
could be a valid protected-mode value, but actually it's some arbitrary
real-mode selector).
I don't know the heritage of that code. I expect someone decided it was
good enough to be getting on with but maybe now it is time to revisit
and see if we can implement a watertight version which correctly uses
hidden segment descriptor state which is readily available when running
on VMX.
It might be worth pinging Leendert about this and see what he thinks.
-- Keir
^ permalink raw reply
* Re: packets skipping DNAT rules
From: Martijn Lievaart @ 2006-03-31 9:47 UTC (permalink / raw)
To: netfilter; +Cc: netfilter
In-Reply-To: <442ACC85.1060807@candlefire.org>
Mr Ritter zei:
> I have some rules in the PREROUTING of the nat table that perform a DNAT
> however, on a very consistent basis the rules doesn't get applied and
> the packet ends up in the filter table without the destination modified.
> 95% of the time it works, 5% it doesn't. I can't put a finger on whats
> causing it, or see anything in particular about the packets that fail to
> DNAT. Any suggestions on how to resolve this?
You can start by posting your ruleset, please show us the output from
iptables-save. Also, you failed to mention if those packets that don't get
DNATted are really random or creating a new connection.
HTH,
M4
^ permalink raw reply
* Re: Save 320K on production machines?
From: Adrian Bunk @ 2006-03-31 9:43 UTC (permalink / raw)
To: Linda Walsh; +Cc: Paulo Marques, Jan Engelhardt, Linux-Kernel
In-Reply-To: <442C4ECF.3080505@tlinx.org>
On Thu, Mar 30, 2006 at 01:34:07PM -0800, Linda Walsh wrote:
>...
> If I "doubled" my stack back to 8K, that would lower the "random
> probability" of hitting a stack limit, but right now, it seems like
> amount of stack "needed" is nearly guesswork. Sigh. Having my
> kernel fairly static and minimalistic (no unused modules; no loadable
> modules, etc) I might only "need" 3K.
Things like unused modules or loadable module support should have more
or less zero impact on stack usage.
> 1) It would be nice if a "stack usage" option could be turned on
> that would do some sort of run-time bounds checking that could
> display the max-stack used "so far" in "/proc".
The -rt kernel contains something like this.
> 2) How difficult would it be to place kernel stack in a "pageable" pool
> where the limit of valid data in a 4K page is only 3.5K - then
> when a kernel routine tries to exceed the stack boundary, it takes a
> page fault where a "note" could be logged that more stack was "needed",
> then automatically map another 4K page into the stack and return to
> interrupted routine.
>
> It sounds a bit strange -- the kernel having to call another part of
> the kernel to handle a pagefault within the kernel, but perhaps there
> could be another level of "partitioning" w/in kernel space that would
> allow the non-paging part of the kernel to be paged in/out in a similar
> way to user code.
>...
This has been discussed to death, and the consensus was that code
resulting in a too high stack usage should be fixed.
If you find any stack problems with 4k stacks and the automatically
enabled unit-at-a-time when using gcc 4.x in kernel 2.6.16-mm2, please
send a bug report.
Regarding unit-at-a-time with gcc 3.x, it works most time for most
people, but it's completely unsupported. If you want to use
unit-at-a-time on i386, please use gcc 4.x.
> -l
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] PowerMac11,2 i2c-bus@0 duplicate dev-tree workaround
From: Johannes Berg @ 2006-03-31 9:42 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1143783444.28005.10.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Fri, 2006-03-31 at 16:37 +1100, Michael Ellerman wrote:
> OK, that sounds a little complicated. I'm just worried about having lots
> workarounds in the unflattening code, the code's hard enough to read as
> it is.
Yeah that's a good argument.
> I think it's preferable to do the workarounds in the code that
> needs the workaround, that way they're isolated in certain parts of the
> code rather than all in the unflattening.
I'd really prefer to have these nodes vanish from the complete node
chain so we don't have the workarounds cluttering up the rather high
levels with machine dependent code. I'll find a better place to put it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...
From: Herbert Xu @ 2006-03-31 9:42 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, jesse.brandeburg, nipsy, jrlundgren, cat, djani22,
yoseph.basri, bb, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, E1000-devel
In-Reply-To: <20060331.013540.95485284.davem@davemloft.net>
On Fri, Mar 31, 2006 at 01:35:40AM -0800, David S. Miller wrote:
>
> He does not have TSO enabled, e1000 disables TSO when on a link speed
> slower than gigabit.
Indeed. But I think that only happens on PCI Express and I don't think
Ingo is using PCI Express.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [PATCH/RFC] MTD: Striping layer core
From: Jörn Engel @ 2006-03-31 9:40 UTC (permalink / raw)
To: Artem B. Bityutskiy
Cc: Alexander Belyakov, Korolev, Alexey, Vitaly Wool,
Kutergin, Timofey, linux-mtd
In-Reply-To: <442CF82B.5060904@yandex.ru>
On Fri, 31 March 2006 13:36:43 +0400, Artem B. Bityutskiy wrote:
>
> No, mtd->type has to tell you the type of the MTD device. Ideally, this
> has to me the only flash-specific field in the mtd_info structure. And
> if users want to do some flash specific things, they have to look at
> mtd->type, realize what is the subsystem which handles this flash, and
> start working with this subsystem. For striping, this is the striping
> subsystem. I don't know what for mtd->flags, probably this hast to go at
> all.
Is this exported to userspace via mtdchar?
Jörn
--
Das Aufregende am Schreiben ist es, eine Ordnung zu schaffen, wo
vorher keine existiert hat.
-- Doris Lessing
^ permalink raw reply
* [uml-devel] RE: UML-hcd driver for 2.6.x
From: James McMechan @ 2006-03-31 9:39 UTC (permalink / raw)
To: wilhelm.golz; +Cc: user-mode-linux-devel
Hello Mr. Golz,
There has only been minor interest in using USB from within UML and the host
controller
architecture changed ~2.4.19/2.5.59 breaking the usb-hcd.
Enthusiasm for fixing it has been lacking I only seem to get one or two
emails each year about USB on UML.
Encouragement is welcome, it has been a lack of interest that has allowed it
to fall to bit rot.
It was working fairly well before the architecture change and could be made
to work again without very much more work.
I have a thought that USB/IP http://usbip.naist.jp/ may provide a more
active approach with its virtual host controller over IP as a example of a
current virtual host controller, or even direct use over UMLs networking.
Sorry for the extra long delay in replying, your message arrived while I was
out of town for two weeks and now my cat is sick...
James McMechan
>From: Wilhelm Golz <wilhelm.golz@secunet.com>
>Reply-To: wilhelm.golz@secunet.com
>To: James_McMechan@hotmail.com
>Subject: UML-hcd driver for 2.6.x
>Date: Wed, 15 Mar 2006 13:38:59 +0100
>
>Hello James,
>
>we (secunet) are currently strongly interested in using USB-devices
>from within a 2.6.12-UML. As far as I have seen You are the
>only one, who had significant success with this under Linux 2.4.
>I tried to get Your uml-hcd-driver (2.5.59) work with a 2.6.12.1 UML
>running on a 2.6.8-host, but up to now without progress.
>
>My questions: Do You plan to develop on this topic in the next time,
>is there maybe a new driver on Your plan?
>Or should it basically work already and am I just not on the right path?
>Maybe there is a way to encourage You in further development of this
>driver?
>
>With kind regards Wilhelm Golz
>
>
>
>--
>Wilhelm Golz
>
>secunet Security Networks AG Telefon: +49.30.399782-11
>Niederlassung Berlin Telefax: +49.30.399782-20
>Alt-Moabit 91c mailto:golz@secunet.com
>D-10559 Berlin http://www.secunet.com
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.