Re: [v11,1/4] drivers: jtag: Add JTAG core driver
Oleksandr Shamray writes:
> diff --git a/include/uapi/linux/jtag.h b/include/uapi/linux/jtag.h
> new file mode 100644
> index 000..0b25a83
> --- /dev/null
> +++ b/include/uapi/linux/jtag.h
> [...]
> +/**
> + * enum jtag_xfer_mode:
> + *
> + * @JTAG_XFER_HW_MODE: hardware mode transfer
> + * @JTAG_XFER_SW_MODE: software mode transfer
> + */
> +enum jtag_xfer_mode {
> + JTAG_XFER_HW_MODE,
> + JTAG_XFER_SW_MODE,
> +};
Is this essentially selecting between bit-bang mode or not? Is there a
generally applicable reason to select SW mode over HW (or vice versa)?
This sounds like it's tied to device-specific capability which shouldn't
be exposed in a generic user API.
> +/**
> + * struct jtag_xfer - jtag xfer:
> + *
> + * @mode: access mode
> + * @type: transfer type
> + * @direction: xfer direction
> + * @length: xfer bits len
> + * @tdio : xfer data array
> + * @endir: xfer end state
> + *
> + * Structure represents interface to Aspeed JTAG device for jtag sdr xfer
> + * execution.
Probably should remove the reference to Aspeed here.
> +/* ioctl interface */
> +#define __JTAG_IOCTL_MAGIC 0xb2
> +
> +#define JTAG_IOCRUNTEST _IOW(__JTAG_IOCTL_MAGIC, 0,\
> + struct jtag_run_test_idle)
> +#define JTAG_SIOCFREQ_IOW(__JTAG_IOCTL_MAGIC, 1, unsigned int)
> +#define JTAG_GIOCFREQ_IOR(__JTAG_IOCTL_MAGIC, 2, unsigned int)
> +#define JTAG_IOCXFER _IOWR(__JTAG_IOCTL_MAGIC, 3, struct jtag_xfer)
> +#define JTAG_GIOCSTATUS _IOWR(__JTAG_IOCTL_MAGIC, 4, enum jtag_endstate)
I notice the single-open()-per-device lock was dropped by request in an
earlier revision of your patches, but multiple processes trying to drive
a single JTAG master could wreak serious havoc if transactions get
interleaved. Would something like an added JTAG_LOCKCHAIN/UNLOCKCHAIN
ioctl() for exclusive client access be reasonable to prevent this?
-Chip
Re: [v11,1/4] drivers: jtag: Add JTAG core driver
Oleksandr Shamray writes:
> diff --git a/include/uapi/linux/jtag.h b/include/uapi/linux/jtag.h
> new file mode 100644
> index 000..0b25a83
> --- /dev/null
> +++ b/include/uapi/linux/jtag.h
> [...]
> +/**
> + * enum jtag_xfer_mode:
> + *
> + * @JTAG_XFER_HW_MODE: hardware mode transfer
> + * @JTAG_XFER_SW_MODE: software mode transfer
> + */
> +enum jtag_xfer_mode {
> + JTAG_XFER_HW_MODE,
> + JTAG_XFER_SW_MODE,
> +};
Is this essentially selecting between bit-bang mode or not? Is there a
generally applicable reason to select SW mode over HW (or vice versa)?
This sounds like it's tied to device-specific capability which shouldn't
be exposed in a generic user API.
> +/**
> + * struct jtag_xfer - jtag xfer:
> + *
> + * @mode: access mode
> + * @type: transfer type
> + * @direction: xfer direction
> + * @length: xfer bits len
> + * @tdio : xfer data array
> + * @endir: xfer end state
> + *
> + * Structure represents interface to Aspeed JTAG device for jtag sdr xfer
> + * execution.
Probably should remove the reference to Aspeed here.
> +/* ioctl interface */
> +#define __JTAG_IOCTL_MAGIC 0xb2
> +
> +#define JTAG_IOCRUNTEST _IOW(__JTAG_IOCTL_MAGIC, 0,\
> + struct jtag_run_test_idle)
> +#define JTAG_SIOCFREQ_IOW(__JTAG_IOCTL_MAGIC, 1, unsigned int)
> +#define JTAG_GIOCFREQ_IOR(__JTAG_IOCTL_MAGIC, 2, unsigned int)
> +#define JTAG_IOCXFER _IOWR(__JTAG_IOCTL_MAGIC, 3, struct jtag_xfer)
> +#define JTAG_GIOCSTATUS _IOWR(__JTAG_IOCTL_MAGIC, 4, enum jtag_endstate)
I notice the single-open()-per-device lock was dropped by request in an
earlier revision of your patches, but multiple processes trying to drive
a single JTAG master could wreak serious havoc if transactions get
interleaved. Would something like an added JTAG_LOCKCHAIN/UNLOCKCHAIN
ioctl() for exclusive client access be reasonable to prevent this?
-Chip
Re: amd_mce.c redundant if check?
On Wed, Aug 20, 2014 at 11:18:21AM -0600, Adam Duskett wrote:
I have recently come upon this section of code in
arch/x86/kernel/cpu/mcheck/mce_amd.c that seems to be a redundant
unnecessary if check.
From line 170 - 176:
if (tr->set_lvt_off) {
if (lvt_off_valid(tr->b, tr->lvt_off, lo, hi)) {
/* set new lvt offset */
hi &= ~MASK_LVTOFF_HI;
hi |= tr->lvt_off << 20;
}
}
This seems like it's not actually doing anything because it's setting
the same value that the bit-field already has to itself.
I brought this up to Adam the other day, so he posted the question to this
list today to elicit a response from the original developer(s). I realize
the quickest response is to ask the original poster (Adam) to investigate
further, such as with pen and paper, but that is not a proper response to a
legitimate question. Here is the #define that is referenced, and the two
routines in question. This is current in kernel version 3.16 in
arch/x86/kernel/cpu/mcheck/mce_amd.c.
#define MASK_LVTOFF_HI0x00F0
static int lvt_off_valid(struct threshold_block *b, int apic, u32 lo, u32
hi)
{
int msr = (hi & MASK_LVTOFF_HI) >> 20;
if (apic < 0) {
pr_err(FW_BUG "cpu %d, failed to setup threshold interrupt "
"for bank %d, block %d (MSR%08X=0x%x%08x)\n", b->cpu,
b->bank, b->block, b->address, hi, lo);
return 0;
}
if (apic != msr) {
pr_err(FW_BUG "cpu %d, invalid threshold interrupt offset %d
"
"for bank %d, block %d (MSR%08X=0x%x%08x)\n",
b->cpu, apic, b->bank, b->block, b->address, hi, lo);
return 0;
}
return 1;
};
/*
* Called via smp_call_function_single(), must be called with correct
* cpu affinity.
*/
static void threshold_restart_bank(void *_tr)
{
struct thresh_restart *tr = _tr;
u32 hi, lo;
rdmsr(tr->b->address, lo, hi);
if (tr->b->threshold_limit < (hi & THRESHOLD_MAX))
tr->reset = 1; /* limit cannot be lower than err count */
if (tr->reset) {/* reset err count and overflow bit
*/
hi =
(hi & ~(MASK_ERR_COUNT_HI | MASK_OVERFLOW_HI)) |
(THRESHOLD_MAX - tr->b->threshold_limit);
} else if (tr->old_limit) { /* change limit w/o reset */
int new_count = (hi & THRESHOLD_MAX) +
(tr->old_limit - tr->b->threshold_limit);
hi = (hi & ~MASK_ERR_COUNT_HI) |
(new_count & THRESHOLD_MAX);
}
/* clear IntType */
hi &= ~MASK_INT_TYPE_HI;
if (!tr->b->interrupt_capable)
goto done;
if (tr->set_lvt_off) {
if (lvt_off_valid(tr->b, tr->lvt_off, lo, hi)) {
/* set new lvt offset */
hi &= ~MASK_LVTOFF_HI;
hi |= tr->lvt_off << 20;
}
}
if (tr->b->interrupt_enable)
hi |= INT_TYPE_APIC;
done:
hi |= MASK_COUNT_EN_HI;
wrmsr(tr->b->address, lo, hi);
}
If one were to actually analyze the source file from which this snippet
comes (lines 117 - 185), one would realize the call to lvt_off_valid() is
given tr->lvt_off as the input "apic" value that is compared to the content
in "hi" at bit positions 23:20 (MSR bits 55:52); this field is called LVT
Offset (LVTOFF). The value for tr->lvt_off is usually from 0 to 4,
inclusive. If this value is equal to the LVTOFF value in "hi", then
lvt_off_valid() returns 1 for true. If the value for tr->lvt_off differs
from the LVTOFF value in "hi", then lvt_off_valid() returns 0 for false.
Now, if the return from lvt_off_valid() is false, then nothing is changed in
"hi". However, if the return is true, which means the value in tr->lvt_off
is equal to the LVTOFF value in "hi", then the LVTOFF value in "hi" is
replaced with the value in tr->lvt_off. One has to wonder, then, why bother
actually calling lvt_off_valid() in the first place when the end result is
that "hi" does not change. What is the rationale for having the code
snippet at lines 170 - 176 when that condition check does nothing to change
"hi"?
--
Chip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: amd_mce.c redundant if check?
On Wed, Aug 20, 2014 at 11:18:21AM -0600, Adam Duskett wrote:
I have recently come upon this section of code in
arch/x86/kernel/cpu/mcheck/mce_amd.c that seems to be a redundant
unnecessary if check.
From line 170 - 176:
if (tr-set_lvt_off) {
if (lvt_off_valid(tr-b, tr-lvt_off, lo, hi)) {
/* set new lvt offset */
hi = ~MASK_LVTOFF_HI;
hi |= tr-lvt_off 20;
}
}
This seems like it's not actually doing anything because it's setting
the same value that the bit-field already has to itself.
I brought this up to Adam the other day, so he posted the question to this
list today to elicit a response from the original developer(s). I realize
the quickest response is to ask the original poster (Adam) to investigate
further, such as with pen and paper, but that is not a proper response to a
legitimate question. Here is the #define that is referenced, and the two
routines in question. This is current in kernel version 3.16 in
arch/x86/kernel/cpu/mcheck/mce_amd.c.
#define MASK_LVTOFF_HI0x00F0
static int lvt_off_valid(struct threshold_block *b, int apic, u32 lo, u32
hi)
{
int msr = (hi MASK_LVTOFF_HI) 20;
if (apic 0) {
pr_err(FW_BUG cpu %d, failed to setup threshold interrupt
for bank %d, block %d (MSR%08X=0x%x%08x)\n, b-cpu,
b-bank, b-block, b-address, hi, lo);
return 0;
}
if (apic != msr) {
pr_err(FW_BUG cpu %d, invalid threshold interrupt offset %d
for bank %d, block %d (MSR%08X=0x%x%08x)\n,
b-cpu, apic, b-bank, b-block, b-address, hi, lo);
return 0;
}
return 1;
};
/*
* Called via smp_call_function_single(), must be called with correct
* cpu affinity.
*/
static void threshold_restart_bank(void *_tr)
{
struct thresh_restart *tr = _tr;
u32 hi, lo;
rdmsr(tr-b-address, lo, hi);
if (tr-b-threshold_limit (hi THRESHOLD_MAX))
tr-reset = 1; /* limit cannot be lower than err count */
if (tr-reset) {/* reset err count and overflow bit
*/
hi =
(hi ~(MASK_ERR_COUNT_HI | MASK_OVERFLOW_HI)) |
(THRESHOLD_MAX - tr-b-threshold_limit);
} else if (tr-old_limit) { /* change limit w/o reset */
int new_count = (hi THRESHOLD_MAX) +
(tr-old_limit - tr-b-threshold_limit);
hi = (hi ~MASK_ERR_COUNT_HI) |
(new_count THRESHOLD_MAX);
}
/* clear IntType */
hi = ~MASK_INT_TYPE_HI;
if (!tr-b-interrupt_capable)
goto done;
if (tr-set_lvt_off) {
if (lvt_off_valid(tr-b, tr-lvt_off, lo, hi)) {
/* set new lvt offset */
hi = ~MASK_LVTOFF_HI;
hi |= tr-lvt_off 20;
}
}
if (tr-b-interrupt_enable)
hi |= INT_TYPE_APIC;
done:
hi |= MASK_COUNT_EN_HI;
wrmsr(tr-b-address, lo, hi);
}
If one were to actually analyze the source file from which this snippet
comes (lines 117 - 185), one would realize the call to lvt_off_valid() is
given tr-lvt_off as the input apic value that is compared to the content
in hi at bit positions 23:20 (MSR bits 55:52); this field is called LVT
Offset (LVTOFF). The value for tr-lvt_off is usually from 0 to 4,
inclusive. If this value is equal to the LVTOFF value in hi, then
lvt_off_valid() returns 1 for true. If the value for tr-lvt_off differs
from the LVTOFF value in hi, then lvt_off_valid() returns 0 for false.
Now, if the return from lvt_off_valid() is false, then nothing is changed in
hi. However, if the return is true, which means the value in tr-lvt_off
is equal to the LVTOFF value in hi, then the LVTOFF value in hi is
replaced with the value in tr-lvt_off. One has to wonder, then, why bother
actually calling lvt_off_valid() in the first place when the end result is
that hi does not change. What is the rationale for having the code
snippet at lines 170 - 176 when that condition check does nothing to change
hi?
--
Chip
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] atmel_serial: Split the interrupt handler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 18 Dec 2007, Haavard Skinnemoen wrote: > On Tue, 18 Dec 2007 18:06:14 +0100 > Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > > > From: Remy Bohmer <[EMAIL PROTECTED]> > > Heh. That's obviously wrong. Wonder what happened there? > > Looks like Chip's address got mangled too. You can find me at <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> these days, although <[EMAIL PROTECTED]> still works for the time being. Chip - -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 GPG ID: 852E052F GPG FPR: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHaA87r6maj4UuBS8RApaiAKCDFvC/WtA/s0pysvMIZIsTlAcN7wCffRoa JwA3E6Kt16pU9yi1dx1lCWk= =M528 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] atmel_serial: Add DMA support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 18 Dec 2007, Haavard Skinnemoen wrote: > From: Chip Coldwell <[EMAIL PROTECTED]> > > This patch is based on the DMA-patch by Chip Coldwell for the > AT91/AT32 serial USARTS, with some tweaks to make it apply neatly on > top of the other patches in this series. > > The RX code has been moved to a tasklet and reworked a bit. Instead of > depending on the ENDRX and TIMEOUT bits in CSR, we simply grab as much > data as we can from the DMA buffers. I think this closes a race where > the ENDRX bit is set after we read CSR but before we read RPR, > although I haven't confirmed this. > > This also fixes a DMA sync bug in the original patch. > > [EMAIL PROTECTED]: rebased onto irq-splitup patch] > [EMAIL PROTECTED]: moved to tasklet, fixed dma bug, misc cleanups] > Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]> > Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> > --- > drivers/serial/atmel_serial.c | 386 ++-- > 1 files changed, 366 insertions(+), 20 deletions(-) > > diff --git a/drivers/serial/atmel_serial.c b/drivers/serial/atmel_serial.c > index 990d3ab..07c2734 100644 > --- a/drivers/serial/atmel_serial.c > +++ b/drivers/serial/atmel_serial.c > @@ -7,6 +7,8 @@ > * Based on drivers/char/serial_sa1100.c, by Deep Blue Solutions Ltd. > * Based on drivers/char/serial.c, by Linus Torvalds, Theodore Ts'o. > * > + * DMA support added by Chip Coldwell. I will ACK/Sign-off on this soon; I just want to do some tests on real hardware first. Chip - -- Charles M. Coldwell "Turn on, log in, tune out" Somerville, Massachusetts, New England -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHaA7cr6maj4UuBS8RAjMSAJsGcKoFKCP/R3aAPhW5hj+v3Qt6ZACgshsF 5NP6/9+NbhDAxBC/7jo8J0Y= =hx4t -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] atmel_serial: Add DMA support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 18 Dec 2007, Haavard Skinnemoen wrote: From: Chip Coldwell [EMAIL PROTECTED] This patch is based on the DMA-patch by Chip Coldwell for the AT91/AT32 serial USARTS, with some tweaks to make it apply neatly on top of the other patches in this series. The RX code has been moved to a tasklet and reworked a bit. Instead of depending on the ENDRX and TIMEOUT bits in CSR, we simply grab as much data as we can from the DMA buffers. I think this closes a race where the ENDRX bit is set after we read CSR but before we read RPR, although I haven't confirmed this. This also fixes a DMA sync bug in the original patch. [EMAIL PROTECTED]: rebased onto irq-splitup patch] [EMAIL PROTECTED]: moved to tasklet, fixed dma bug, misc cleanups] Signed-off-by: Remy Bohmer [EMAIL PROTECTED] Signed-off-by: Haavard Skinnemoen [EMAIL PROTECTED] --- drivers/serial/atmel_serial.c | 386 ++-- 1 files changed, 366 insertions(+), 20 deletions(-) diff --git a/drivers/serial/atmel_serial.c b/drivers/serial/atmel_serial.c index 990d3ab..07c2734 100644 --- a/drivers/serial/atmel_serial.c +++ b/drivers/serial/atmel_serial.c @@ -7,6 +7,8 @@ * Based on drivers/char/serial_sa1100.c, by Deep Blue Solutions Ltd. * Based on drivers/char/serial.c, by Linus Torvalds, Theodore Ts'o. * + * DMA support added by Chip Coldwell. I will ACK/Sign-off on this soon; I just want to do some tests on real hardware first. Chip - -- Charles M. Coldwell Turn on, log in, tune out Somerville, Massachusetts, New England -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHaA7cr6maj4UuBS8RAjMSAJsGcKoFKCP/R3aAPhW5hj+v3Qt6ZACgshsF 5NP6/9+NbhDAxBC/7jo8J0Y= =hx4t -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] atmel_serial: Split the interrupt handler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 18 Dec 2007, Haavard Skinnemoen wrote: On Tue, 18 Dec 2007 18:06:14 +0100 Haavard Skinnemoen [EMAIL PROTECTED] wrote: From: Remy Bohmer [EMAIL PROTECTED] Heh. That's obviously wrong. Wonder what happened there? Looks like Chip's address got mangled too. You can find me at [EMAIL PROTECTED] or [EMAIL PROTECTED] these days, although [EMAIL PROTECTED] still works for the time being. Chip - -- Charles M. Chip Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 GPG ID: 852E052F GPG FPR: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHaA87r6maj4UuBS8RApaiAKCDFvC/WtA/s0pysvMIZIsTlAcN7wCffRoa JwA3E6Kt16pU9yi1dx1lCWk= =M528 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH/RFC: [kdump] fix APIC shutdown sequence
On Wed, 8 Aug 2007, Vivek Goyal wrote: > On Tue, Aug 07, 2007 at 07:41:30PM +0200, Martin Wilck wrote: > > > > Can you explain how, on the front side bus, the IO-APIC knows whether > > a CPU has accepted the INT message? There is no response > > to the INT message on the bus, except for the EOI which comes much later. > > I'm not saying that you're wrong, I just really don't understand this > > point. > > > > I don't know what is exactly hardware protocol. I am just going by > intel documentation. I think it's important to distinguish between the LAPIC receiving an interrupt and the CPU receiving an interrupt. The former could happen without the latter if the CPU has set the TPR above the priority of the interrupt received by the LAPIC. In that case, the interrupt is kept pending in the LAPIC and recorded in the IRR if I understand the Intel documentation correctly. So I think the scenario which leaves IRR set when the kdump kernel starts is possible. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH/RFC: [kdump] fix APIC shutdown sequence
On Wed, 8 Aug 2007, Vivek Goyal wrote: On Tue, Aug 07, 2007 at 07:41:30PM +0200, Martin Wilck wrote: Can you explain how, on the front side bus, the IO-APIC knows whether a CPU has accepted the INT message? There is no response to the INT message on the bus, except for the EOI which comes much later. I'm not saying that you're wrong, I just really don't understand this point. I don't know what is exactly hardware protocol. I am just going by intel documentation. I think it's important to distinguish between the LAPIC receiving an interrupt and the CPU receiving an interrupt. The former could happen without the latter if the CPU has set the TPR above the priority of the interrupt received by the LAPIC. In that case, the interrupt is kept pending in the LAPIC and recorded in the IRR if I understand the Intel documentation correctly. So I think the scenario which leaves IRR set when the kdump kernel starts is possible. Chip -- Charles M. Chip Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH/RFC: [kdump] fix APIC shutdown sequence
On Tue, 7 Aug 2007, Vivek Goyal wrote: > On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote: > > > 1. If, under SMP, the IO-APIC logical destination field is > >set by the IRQ balancing code to one of the "other" > >CPUs (i.e. not the crashing_cpu), and an IRQ arrives > >on the respective pin after that CPU has shut down > >its local APIC (but before the IO-APIC pin is masked) > >the IRQ message can't be delivered. > > Point 1 and Point 2 seems to be same. > > > > > 2. The crashing CPU itself disables its local APIC > >before the IO-APIC, leaving a short time window > >where the IOAPIC can receive IRQs, but not > >deliver them. > > > > I doubut that it would be the issue. Looking at intel IOAPIC (82093AA) > documentation, it says that IRR bit of IOAPIC will be set only if > destination CPU has accepted the interrupt. I think you mean "destination Local APIC has accepted the interrupt" above. The Intel documentation cited above contains this text on page 12: For level triggered interrupts, this bit is set to 1 when local APIC(s) accept the level interrupt sent by the IOAPIC. The Remote IRR bit is set to 0 when an EOI message with a matching interrupt vector is received from a local APIC. The following text is from the IA-64 documentation ... Any interrupt that is received by the processor is kept pending and recorded in the Interrupt Request Register (IRR). If the processor is not servicing an interrupt, then the contents of the TPR determines whether the processor will accept a pending interrupt depending on the priority of the interrupt compared to the current TPR. If the interrupt has a higher priority, then the processor is interrupted, otherwise the interrupt is kept pending. So, I think if the CPU has interrupts disabled, but the Local APIC does not, the IRR could get set. I guess we need to be sure to turn off the Local APIC first before disabling interrupts in the CPU. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH/RFC: [kdump] fix APIC shutdown sequence
On Tue, 7 Aug 2007, Vivek Goyal wrote: On Mon, Aug 06, 2007 at 05:08:05PM +0200, Martin Wilck wrote: 1. If, under SMP, the IO-APIC logical destination field is set by the IRQ balancing code to one of the other CPUs (i.e. not the crashing_cpu), and an IRQ arrives on the respective pin after that CPU has shut down its local APIC (but before the IO-APIC pin is masked) the IRQ message can't be delivered. Point 1 and Point 2 seems to be same. 2. The crashing CPU itself disables its local APIC before the IO-APIC, leaving a short time window where the IOAPIC can receive IRQs, but not deliver them. I doubut that it would be the issue. Looking at intel IOAPIC (82093AA) documentation, it says that IRR bit of IOAPIC will be set only if destination CPU has accepted the interrupt. I think you mean destination Local APIC has accepted the interrupt above. The Intel documentation cited above contains this text on page 12: For level triggered interrupts, this bit is set to 1 when local APIC(s) accept the level interrupt sent by the IOAPIC. The Remote IRR bit is set to 0 when an EOI message with a matching interrupt vector is received from a local APIC. The following text is from the IA-64 documentation ... Any interrupt that is received by the processor is kept pending and recorded in the Interrupt Request Register (IRR). If the processor is not servicing an interrupt, then the contents of the TPR determines whether the processor will accept a pending interrupt depending on the priority of the interrupt compared to the current TPR. If the interrupt has a higher priority, then the processor is interrupted, otherwise the interrupt is kept pending. So, I think if the CPU has interrupts disabled, but the Local APIC does not, the IRR could get set. I guess we need to be sure to turn off the Local APIC first before disabling interrupts in the CPU. Chip -- Charles M. Chip Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Wed, 17 Jan 2007, Andi Kleen wrote:
> On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
> > On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
> > > I agree,... it seems drastic, but this is the only really secure
> > > solution.
> >
> > I'd like to here from Andi how he feels about this? It seems like a
> > somewhat drastic solution in some ways given a lot of hardware doesn't
> > seem to be affected (or maybe in those cases it's just really hard to
> > hit, I don't know).
>
> AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
> although there were similar problems on VIA in the past too.
> Unless a good workaround comes around soon I'll probably default
> to iommu=soft on Nvidia.
We (Sun, AMD, Nvidia and Red Hat) have been testing a patch that seems
to solve the problem. AMD and Nvidia analyzed an HDT trace that
seemed to indicate that CPU updates of the GATT were still in cache
when a subsequent table walk caused by a device load used a stale GATT
PTE. That analysis inspired this patch, submitted to this list as an
RFC. It is not obvious (to me, at least) why this problem has only
shown up on Nvidia SATA controllers.
We are continuing to investigate.
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 030eb37..1dd461a 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -69,6 +69,8 @@ static u32 gart_unmapped_entry;
#define AGPEXTERN
#endif
+#define GATT_CLFLUSH(i) asm volatile ("clflush (%0)" :: "r" (iommu_gatt_base +
(i)))
+
/* backdoor interface to AGP driver */
AGPEXTERN int agp_memory_reserved;
AGPEXTERN __u32 *agp_gatt_table;
@@ -221,6 +223,7 @@ static dma_addr_t dma_map_area(struct device *dev,
dma_addr_t phys_mem,
for (i = 0; i < npages; i++) {
iommu_gatt_base[iommu_page + i] = GPTE_ENCODE(phys_mem);
SET_LEAK(iommu_page + i);
+ GATT_CLFLUSH(iommu_page + i);
phys_mem += PAGE_SIZE;
}
return iommu_bus_base + iommu_page*PAGE_SIZE + (phys_mem & ~PAGE_MASK);
@@ -348,6 +351,7 @@ static int __dma_map_cont(struct scatterlist *sg, int
start, int stopat,
while (pages--) {
iommu_gatt_base[iommu_page] = GPTE_ENCODE(addr);
SET_LEAK(iommu_page);
+ GATT_CLFLUSH(iommu_page);
addr += PAGE_SIZE;
iommu_page++;
}
Chip
--
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem to be affected (or maybe in those cases it's just really hard to
hit, I don't know).
AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
although there were similar problems on VIA in the past too.
Unless a good workaround comes around soon I'll probably default
to iommu=soft on Nvidia.
We (Sun, AMD, Nvidia and Red Hat) have been testing a patch that seems
to solve the problem. AMD and Nvidia analyzed an HDT trace that
seemed to indicate that CPU updates of the GATT were still in cache
when a subsequent table walk caused by a device load used a stale GATT
PTE. That analysis inspired this patch, submitted to this list as an
RFC. It is not obvious (to me, at least) why this problem has only
shown up on Nvidia SATA controllers.
We are continuing to investigate.
diff --git a/arch/x86_64/kernel/pci-gart.c b/arch/x86_64/kernel/pci-gart.c
index 030eb37..1dd461a 100644
--- a/arch/x86_64/kernel/pci-gart.c
+++ b/arch/x86_64/kernel/pci-gart.c
@@ -69,6 +69,8 @@ static u32 gart_unmapped_entry;
#define AGPEXTERN
#endif
+#define GATT_CLFLUSH(i) asm volatile (clflush (%0) :: r (iommu_gatt_base +
(i)))
+
/* backdoor interface to AGP driver */
AGPEXTERN int agp_memory_reserved;
AGPEXTERN __u32 *agp_gatt_table;
@@ -221,6 +223,7 @@ static dma_addr_t dma_map_area(struct device *dev,
dma_addr_t phys_mem,
for (i = 0; i npages; i++) {
iommu_gatt_base[iommu_page + i] = GPTE_ENCODE(phys_mem);
SET_LEAK(iommu_page + i);
+ GATT_CLFLUSH(iommu_page + i);
phys_mem += PAGE_SIZE;
}
return iommu_bus_base + iommu_page*PAGE_SIZE + (phys_mem ~PAGE_MASK);
@@ -348,6 +351,7 @@ static int __dma_map_cont(struct scatterlist *sg, int
start, int stopat,
while (pages--) {
iommu_gatt_base[iommu_page] = GPTE_ENCODE(addr);
SET_LEAK(iommu_page);
+ GATT_CLFLUSH(iommu_page);
addr += PAGE_SIZE;
iommu_page++;
}
Chip
--
Charles M. Chip Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, 18 Jan 2007, Andi Kleen wrote: The Northbridge guarantees coherency over the aperture, but only if the caching attributes match. That's interesting. Makes sense, I suppose. You would need to change_page_attr() every kernel address that is mapped into the IOMMU to use an uncached aperture. AGP does this, but the frequency of mapping for the IOMMU is much higher and it would be prohibitively costly unfortunately. But it still might be a reasonable thing to do to test the theory that the problem is cache coherency across the graphics aperture, even if it isn't a long-term solution for the problem. In the past we saw corruptions from such conflicts, so this is more than just theory. I suspect you traded a more easy to trigger corruption with a more subtle one. Yup. That was the inspiration for the script. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Thu, 18 Jan 2007, Andi Kleen wrote: The Northbridge guarantees coherency over the aperture, but only if the caching attributes match. That's interesting. Makes sense, I suppose. You would need to change_page_attr() every kernel address that is mapped into the IOMMU to use an uncached aperture. AGP does this, but the frequency of mapping for the IOMMU is much higher and it would be prohibitively costly unfortunately. But it still might be a reasonable thing to do to test the theory that the problem is cache coherency across the graphics aperture, even if it isn't a long-term solution for the problem. In the past we saw corruptions from such conflicts, so this is more than just theory. I suspect you traded a more easy to trigger corruption with a more subtle one. Yup. That was the inspiration for the script. Chip -- Charles M. Chip Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Wed, 17 Jan 2007, Chip Coldwell wrote: On Wed, 17 Jan 2007, Andi Kleen wrote: On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote: On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote: I agree,... it seems drastic, but this is the only really secure solution. I'd like to here from Andi how he feels about this? It seems like a somewhat drastic solution in some ways given a lot of hardware doesn't seem to be affected (or maybe in those cases it's just really hard to hit, I don't know). AMD is looking at the issue. Only Nvidia chipsets seem to be affected, although there were similar problems on VIA in the past too. Unless a good workaround comes around soon I'll probably default to iommu=soft on Nvidia. We've just verified that configuring the graphics aperture to be write-combining instead of write-back using an MTRR also solves the problem. It appears to be a cache incoherency issue in the graphics aperture. I take it back. Further testing has revealed that this does not solve the problem. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem to be affected (or maybe in those cases it's just really hard to
hit, I don't know).
AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
although there were similar problems on VIA in the past too.
Unless a good workaround comes around soon I'll probably default
to iommu=soft on Nvidia.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
We've just verified that configuring the graphics aperture to be
write-combining instead of write-back using an MTRR also solves the
problem. It appears to be a cache incoherency issue in the graphics
aperture.
This script does the trick:
[ -- cut here -- ]
#!/bin/bash
# Read the northbridge offset 0x90 to get the size of the aperture
size=0x`lspci -xxx -s 0:18.3 | awk '/^90:/ { print $2 }'`
# bit 0 indicates the aperture is enabled, bits 1 - 3 indicate the size
if [ $((size & 1)) -eq 0 ] ; then
echo "GART disabled; exiting"
exit 0
fi
shft=$(((size >> 1) & 7))
size=$((0x200 << shft))
# Read the northbridge offset 0x94 to get the base address of the aperture
base=0x`lspci -xxx -s 0:18.3 | awk '/^90:/ { print $6 }'`
base=$((base << 25))
basehex=`printf 0x%08x $base`
printf "IOMMU aperture found at base=0x%08x size=0x%08x (%d KiB)\n" $base $size
$((size/1024))
if grep -q $basehex /proc/mtrr ; then
echo "MTRR already configured for IOMMU aperture; exiting"
exit 0
fi
echo "Configuring write-combining MTRR for IOMMU aperture"
printf "base=0x%08x size=0x%08x type=write-combining\n" $base $size >/proc/mtrr
exit 0
[ -- cut here-- ]
Chip
--
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem to be affected (or maybe in those cases it's just really hard to
hit, I don't know).
AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
although there were similar problems on VIA in the past too.
Unless a good workaround comes around soon I'll probably default
to iommu=soft on Nvidia.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
We've just verified that configuring the graphics aperture to be
write-combining instead of write-back using an MTRR also solves the
problem. It appears to be a cache incoherency issue in the graphics
aperture.
This script does the trick:
[ -- cut here -- ]
#!/bin/bash
# Read the northbridge offset 0x90 to get the size of the aperture
size=0x`lspci -xxx -s 0:18.3 | awk '/^90:/ { print $2 }'`
# bit 0 indicates the aperture is enabled, bits 1 - 3 indicate the size
if [ $((size 1)) -eq 0 ] ; then
echo GART disabled; exiting
exit 0
fi
shft=$(((size 1) 7))
size=$((0x200 shft))
# Read the northbridge offset 0x94 to get the base address of the aperture
base=0x`lspci -xxx -s 0:18.3 | awk '/^90:/ { print $6 }'`
base=$((base 25))
basehex=`printf 0x%08x $base`
printf IOMMU aperture found at base=0x%08x size=0x%08x (%d KiB)\n $base $size
$((size/1024))
if grep -q $basehex /proc/mtrr ; then
echo MTRR already configured for IOMMU aperture; exiting
exit 0
fi
echo Configuring write-combining MTRR for IOMMU aperture
printf base=0x%08x size=0x%08x type=write-combining\n $base $size /proc/mtrr
exit 0
[ -- cut here-- ]
Chip
--
Charles M. Chip Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)
On Wed, 17 Jan 2007, Chip Coldwell wrote: On Wed, 17 Jan 2007, Andi Kleen wrote: On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote: On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote: I agree,... it seems drastic, but this is the only really secure solution. I'd like to here from Andi how he feels about this? It seems like a somewhat drastic solution in some ways given a lot of hardware doesn't seem to be affected (or maybe in those cases it's just really hard to hit, I don't know). AMD is looking at the issue. Only Nvidia chipsets seem to be affected, although there were similar problems on VIA in the past too. Unless a good workaround comes around soon I'll probably default to iommu=soft on Nvidia. We've just verified that configuring the graphics aperture to be write-combining instead of write-back using an MTRR also solves the problem. It appears to be a cache incoherency issue in the graphics aperture. I take it back. Further testing has revealed that this does not solve the problem. Chip -- Charles M. Chip Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NEC IDE DVD writer breaks when writing with DMA; is this normal?
I've recently added an NEC DVD writer (ND-6450A) to my ThinkPad A30.
It breaks badly if I try to write with it with cdrecord or
dvd+rw-tools when DMA is on. With DMA off, it works, but it uses a
heck of a lot of CPU time -- the whole laptop is really really doggy.
Is this the kind of thing I should just expect from DVD writers? Or
is this a good candidate for some driver work to adjust for the quirks
of this device?
System info follows:
[boot log]
kernel: ICH3M: chipset revision 1
kernel: ICH3M: not 100%% native mode: will probe irqs later
kernel: ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio
kernel: ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:pio, hdd:pio
kernel: hda: HTS548080M9AT00, ATA DISK drive
kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
kernel: hdc: _NEC DVD+/-RW ND-6450A, ATAPI CD/DVD-ROM drive
kernel: ide1 at 0x170-0x177,0x376 on irq 15
kernel: hda: max request size: 1024KiB
kernel: hda: 156301488 sectors (80026 MB) w/7877KiB Cache, CHS=16383/255/63,
UDMA(100)
kernel: hda: hda1 hda2 < hda5 hda6 hda7 hda8 >
[error log]
Feb 18 12:13:00 kernel: sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2
cdda tray
Feb 18 12:13:00 kernel: Uniform CD-ROM driver Revision: 3.20
Feb 18 12:13:00 kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
[...]
Feb 18 12:19:46 kernel: hdc: DMA timeout retry
Feb 18 12:19:46 kernel: hdc: timeout waiting for DMA
Feb 18 12:19:46 kernel: hdc: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: ide-scsi: No active request in idescsi_eh_reset
Feb 18 12:19:46 kernel: scsi: Device offlined - not ready after error recovery:
host 0 channel 0 id 0 lun 0
Feb 18 12:19:46 kernel: SCSI error : <0 0 0 0> return code = 0x2
Feb 18 12:19:46 kernel: scsi0 (0:0): rejecting I/O to offline device
Feb 18 12:19:46 kernel: scsi0 (0:0): rejecting I/O to offline device
[hdparm -i]
Model=_NEC DVD+/-RW ND-6450A, FwRev=2.36, SerialNo=
Config={ Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2
AdvancedPM=no
[lspci -v]
:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01) (prog-if 8a
[Master SecP PriP])
Subsystem: IBM ThinkPad A/T/X Series
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at
I/O ports at
I/O ports at
I/O ports at
I/O ports at 1860 [size=16]
Memory at 2800 (32-bit, non-prefetchable) [size=1K]
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
Open Source is not an excuse to write fun code
then leave the actual work to others.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
NEC IDE DVD writer breaks when writing with DMA; is this normal?
I've recently added an NEC DVD writer (ND-6450A) to my ThinkPad A30.
It breaks badly if I try to write with it with cdrecord or
dvd+rw-tools when DMA is on. With DMA off, it works, but it uses a
heck of a lot of CPU time -- the whole laptop is really really doggy.
Is this the kind of thing I should just expect from DVD writers? Or
is this a good candidate for some driver work to adjust for the quirks
of this device?
System info follows:
[boot log]
kernel: ICH3M: chipset revision 1
kernel: ICH3M: not 100%% native mode: will probe irqs later
kernel: ide0: BM-DMA at 0x1860-0x1867, BIOS settings: hda:DMA, hdb:pio
kernel: ide1: BM-DMA at 0x1868-0x186f, BIOS settings: hdc:pio, hdd:pio
kernel: hda: HTS548080M9AT00, ATA DISK drive
kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
kernel: hdc: _NEC DVD+/-RW ND-6450A, ATAPI CD/DVD-ROM drive
kernel: ide1 at 0x170-0x177,0x376 on irq 15
kernel: hda: max request size: 1024KiB
kernel: hda: 156301488 sectors (80026 MB) w/7877KiB Cache, CHS=16383/255/63,
UDMA(100)
kernel: hda: hda1 hda2 hda5 hda6 hda7 hda8
[error log]
Feb 18 12:13:00 kernel: sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2
cdda tray
Feb 18 12:13:00 kernel: Uniform CD-ROM driver Revision: 3.20
Feb 18 12:13:00 kernel: Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
[...]
Feb 18 12:19:46 kernel: hdc: DMA timeout retry
Feb 18 12:19:46 kernel: hdc: timeout waiting for DMA
Feb 18 12:19:46 kernel: hdc: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: hdc: status error: status=0x59 { DriveReady
SeekComplete DataRequest Error }
Feb 18 12:19:46 kernel: hdc: status error: error=0x04 { AbortedCommand }
Feb 18 12:19:46 kernel: ide: failed opcode was: unknown
Feb 18 12:19:46 kernel: hdc: drive not ready for command
Feb 18 12:19:46 kernel: ide-scsi: No active request in idescsi_eh_reset
Feb 18 12:19:46 kernel: scsi: Device offlined - not ready after error recovery:
host 0 channel 0 id 0 lun 0
Feb 18 12:19:46 kernel: SCSI error : 0 0 0 0 return code = 0x2
Feb 18 12:19:46 kernel: scsi0 (0:0): rejecting I/O to offline device
Feb 18 12:19:46 kernel: scsi0 (0:0): rejecting I/O to offline device
[hdparm -i]
Model=_NEC DVD+/-RW ND-6450A, FwRev=2.36, SerialNo=
Config={ Removeable DTR=5Mbs DTR10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2
AdvancedPM=no
[lspci -v]
:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01) (prog-if 8a
[Master SecP PriP])
Subsystem: IBM ThinkPad A/T/X Series
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at ignored
I/O ports at ignored
I/O ports at ignored
I/O ports at ignored
I/O ports at 1860 [size=16]
Memory at 2800 (32-bit, non-prefetchable) [size=1K]
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
Open Source is not an excuse to write fun code
then leave the actual work to others.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] restore skb_copy_datagram, removed from 2.6.11-rc2, breaking VMWare
Those of you who are using VMWare 4.5 will find that 2.6.11-rc2
removes the public function "skb_copy_datagram", breaking VMWare
(and any other module using that interface *sigh*).
The attached patch restores the (little harmless wrapper) function.
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"What I cannot create, I do not understand." - Richard Feynman
--- x/include/linux/skbuff.h.old2005-01-22 10:03:55.0 -0500
+++ y/include/linux/skbuff.h2005-01-22 10:42:33.0 -0500
@@ -1087,4 +1087,6 @@
extern unsigned intdatagram_poll(struct file *file, struct socket *sock,
struct poll_table_struct *wait);
+extern intskb_copy_datagram(const struct sk_buff *from,
+int offset, char __user *to, int size);
extern intskb_copy_datagram_iovec(const struct sk_buff *from,
int offset, struct iovec *to,
--- x/net/core/datagram.c.old 2005-01-22 10:03:56.0 -0500
+++ y/net/core/datagram.c 2005-01-22 10:43:40.0 -0500
@@ -200,4 +200,17 @@
}
+/*
+ * Copy a datagram to a linear buffer.
+ */
+int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to,
int size)
+{
+ struct iovec iov = {
+ .iov_base = to,
+ .iov_len =size,
+ };
+
+ return skb_copy_datagram_iovec(skb, offset, , size);
+}
+
/**
* skb_copy_datagram_iovec - Copy a datagram to an iovec.
@@ -478,4 +491,5 @@
EXPORT_SYMBOL(datagram_poll);
EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec);
+EXPORT_SYMBOL(skb_copy_datagram);
EXPORT_SYMBOL(skb_copy_datagram_iovec);
EXPORT_SYMBOL(skb_free_datagram);
[PATCH] restore skb_copy_datagram, removed from 2.6.11-rc2, breaking VMWare
Those of you who are using VMWare 4.5 will find that 2.6.11-rc2
removes the public function skb_copy_datagram, breaking VMWare
(and any other module using that interface *sigh*).
The attached patch restores the (little harmless wrapper) function.
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
What I cannot create, I do not understand. - Richard Feynman
--- x/include/linux/skbuff.h.old2005-01-22 10:03:55.0 -0500
+++ y/include/linux/skbuff.h2005-01-22 10:42:33.0 -0500
@@ -1087,4 +1087,6 @@
extern unsigned intdatagram_poll(struct file *file, struct socket *sock,
struct poll_table_struct *wait);
+extern intskb_copy_datagram(const struct sk_buff *from,
+int offset, char __user *to, int size);
extern intskb_copy_datagram_iovec(const struct sk_buff *from,
int offset, struct iovec *to,
--- x/net/core/datagram.c.old 2005-01-22 10:03:56.0 -0500
+++ y/net/core/datagram.c 2005-01-22 10:43:40.0 -0500
@@ -200,4 +200,17 @@
}
+/*
+ * Copy a datagram to a linear buffer.
+ */
+int skb_copy_datagram(const struct sk_buff *skb, int offset, char __user *to,
int size)
+{
+ struct iovec iov = {
+ .iov_base = to,
+ .iov_len =size,
+ };
+
+ return skb_copy_datagram_iovec(skb, offset, iov, size);
+}
+
/**
* skb_copy_datagram_iovec - Copy a datagram to an iovec.
@@ -478,4 +491,5 @@
EXPORT_SYMBOL(datagram_poll);
EXPORT_SYMBOL(skb_copy_and_csum_datagram_iovec);
+EXPORT_SYMBOL(skb_copy_datagram);
EXPORT_SYMBOL(skb_copy_datagram_iovec);
EXPORT_SYMBOL(skb_free_datagram);
RE: ECN is on!
Not to mention, not everyone on the list runs their own mailservers. -Original Message- From: Steve Modica [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 22, 2001 12:28 To: Rogier Wolff Cc: Richard Gooch; Brent D. Norris; David S. Miller; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: ECN is on! Rogier Wolff wrote: > The "we'll turn it on in February" warning is worth NOTHING in this > situation: February comes and goes. March comes and goes. Everybody > who read the warning will think: Ok, so I must be fine. > > A warning of the form: "ECN will go on as soon as this message clears > the queues" would've been useful, as thousands (hundreds?) suddenly get > nothing anymore. > I agree with this line of thinking. The various academics studying geology have been warning California about "The Big One" for years now, and no one seems to care anymore. I don't think anyone's being lazy and I certainly don't have the information to comment on the size of their butts. So I'd rather just assume they were working very hard on other things (like getting TPC-H benchmarks to run!) Steve -- Steve Modica Manager - Networking Drivers Group "Give a man a fish, and he will eat for a day, hit him with a fish and he leaves you alone" - me - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ECN is on!
Not to mention, not everyone on the list runs their own mailservers. -Original Message- From: Steve Modica [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 22, 2001 12:28 To: Rogier Wolff Cc: Richard Gooch; Brent D. Norris; David S. Miller; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: ECN is on! Rogier Wolff wrote: The we'll turn it on in February warning is worth NOTHING in this situation: February comes and goes. March comes and goes. Everybody who read the warning will think: Ok, so I must be fine. A warning of the form: ECN will go on as soon as this message clears the queues would've been useful, as thousands (hundreds?) suddenly get nothing anymore. I agree with this line of thinking. The various academics studying geology have been warning California about The Big One for years now, and no one seems to care anymore. I don't think anyone's being lazy and I certainly don't have the information to comment on the size of their butts. So I'd rather just assume they were working very hard on other things (like getting TPC-H benchmarks to run!) Steve -- Steve Modica Manager - Networking Drivers Group Give a man a fish, and he will eat for a day, hit him with a fish and he leaves you alone - me - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alan Cox: > Chip: > > Wouldn't it be better just to *try* ioctls and see which ones work and > > which ones don't? > > 1. We have overlaps We all agree that overlaps need to be eliminated over time. In the meantime, as a coping strategy: I'll bet you that for any two given device classes, there is at least one ioctl that works on only one of them. (I'm only talking about an interim workaround! Calm down! Put down those bats!) > 2. I've seen code where people play clever ioctl tricks to deduce a > device type and it ends up looking like one of those chemistry > identification charts (hopefully minus do you see smoke ?) I don't mean to suggest that ioctls be used to deduce device types (except in the case of overlapping ioctl numbers, which shouldn't be all *that* common (I hope)). I mean to suggest that the question "What device type are you?" usually shouldn't even be asked! If you want to do X to the device on fd, just call ioctl(fd, X, ...). Either it works or it doesn't. I realize that overlapping ioctls throw a monkey wrench into this world view. Is it a bigger wrench than the wrenching pain that we'll have to live through to make device identification reliable? Depends on how many ioctls overlap, and how easily we could make them stop overlapping. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to H. Peter Anvin: > A device can inherently belong to multiple device classes, and it > really should be thought of as such. And then there are layering technologies like LVM and loopback. They should be included in a discovery, but if you limit yourself to one "device type", there's no place for them. > For example a disk may belong, at the same time, to the "scsi", > "disk" and "scsi-disk" device classes [...] True, but in a sane system, "scsi" + "disk" implies "scsi-disk". -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to James Simmons: > Graphics cards are the same way. Especially high end ones. They have pipes > as well. For low end cards you can think of them as single pipeline cards > with one pipe. It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use write(). It's a natural way to feed pipelines. But no, it's a raft of ioctl() calls. *sigh* -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Johannes Erdfelt: > I had always made the assumption that sockets were created because you > couldn't easily map IPv4 semantics onto filesystems. It's unreasonable > to have a file for every possible IP address/port you can communicate > with. I think you're right on both counts, but I'm sure you'll agree that just because some undergrad at Berkeley did something a certain way 20 years ago doesn't mean we have to follow it blindly. :-) IIRC, Plan 9 allocate TCP connections rather like Linux allocates ptys. When we allocate a pty we don't have to say what program we're going to connect to; we allocate it and then use it as we like. Similarly, in Plan 9 you allocate a TCP connection without having to say who you're going to connect to. The main differences between the Plan 9 approach and the socket approach are: 1. Plan 9 connections are filesystem entities (like our ptys) 2. Control is done via read/write on a separate control channel, which is *also* a filesystem entity. USB could use a similar approach. And since each client would allocate a new connection entity for its own use -- even if it's going to connect to a device that someone else is already connected to -- permissions becomes quite simple to manage. Come to think of it, the mechanism I'm describing could address all hotpluggable devices.... -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Linus Torvalds: > I don't see why we couldn't expose the "driver name" for any file > descriptor. Is it wise to assume that there is only one such name for *any* file descriptor? -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alexander Viro: > On Tue, 15 May 2001, James Simmons wrote: > > I would use write except we use write to draw into the framebuffer. If I > > write to the framebuffer with that data the only thing that will happen is > > I will get pretty colors on my screen. > > Yes. And we also use write to send data to printer. So what? Nobody makes > you use the same file. You're talking about /dev/fb0 vs. /dev/fb0ctl, right? Would that driver authors routinely used such clean designs. PS: No, readers, AFAIK, there is no such thing as /dev/fb0ctl. Yet. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alan Cox: > Given a file handle 'X' how do I find out what ioctl groups I should > apply to it. Wouldn't it be better just to *try* ioctls and see which ones work and which ones don't? This ioctl situation reminds me of how novice programmers assume that they have to call access() or stat() and check a file for existence and readability before calling open(). But that's just stupid when you think about it, because if the file isn't there and the open() fails, that's OK! Failures are not fatal. Similarly, ioctl failures are not fatal. Just Try Them. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alan Cox: Given a file handle 'X' how do I find out what ioctl groups I should apply to it. Wouldn't it be better just to *try* ioctls and see which ones work and which ones don't? This ioctl situation reminds me of how novice programmers assume that they have to call access() or stat() and check a file for existence and readability before calling open(). But that's just stupid when you think about it, because if the file isn't there and the open() fails, that's OK! Failures are not fatal. Similarly, ioctl failures are not fatal. Just Try Them. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alexander Viro: On Tue, 15 May 2001, James Simmons wrote: I would use write except we use write to draw into the framebuffer. If I write to the framebuffer with that data the only thing that will happen is I will get pretty colors on my screen. Yes. And we also use write to send data to printer. So what? Nobody makes you use the same file. You're talking about /dev/fb0 vs. /dev/fb0ctl, right? Would that driver authors routinely used such clean designs. PS: No, readers, AFAIK, there is no such thing as /dev/fb0ctl. Yet. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Linus Torvalds: I don't see why we couldn't expose the driver name for any file descriptor. Is it wise to assume that there is only one such name for *any* file descriptor? -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to James Simmons: Graphics cards are the same way. Especially high end ones. They have pipes as well. For low end cards you can think of them as single pipeline cards with one pipe. It still frosts my shorts that DRM (e.g. /dev/dri/card0) doesn't use write(). It's a natural way to feed pipelines. But no, it's a raft of ioctl() calls. *sigh* -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Johannes Erdfelt: I had always made the assumption that sockets were created because you couldn't easily map IPv4 semantics onto filesystems. It's unreasonable to have a file for every possible IP address/port you can communicate with. I think you're right on both counts, but I'm sure you'll agree that just because some undergrad at Berkeley did something a certain way 20 years ago doesn't mean we have to follow it blindly. :-) IIRC, Plan 9 allocate TCP connections rather like Linux allocates ptys. When we allocate a pty we don't have to say what program we're going to connect to; we allocate it and then use it as we like. Similarly, in Plan 9 you allocate a TCP connection without having to say who you're going to connect to. The main differences between the Plan 9 approach and the socket approach are: 1. Plan 9 connections are filesystem entities (like our ptys) 2. Control is done via read/write on a separate control channel, which is *also* a filesystem entity. USB could use a similar approach. And since each client would allocate a new connection entity for its own use -- even if it's going to connect to a device that someone else is already connected to -- permissions becomes quite simple to manage. Come to think of it, the mechanism I'm describing could address all hotpluggable devices -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to H. Peter Anvin: A device can inherently belong to multiple device classes, and it really should be thought of as such. And then there are layering technologies like LVM and loopback. They should be included in a discovery, but if you limit yourself to one device type, there's no place for them. For example a disk may belong, at the same time, to the scsi, disk and scsi-disk device classes [...] True, but in a sane system, scsi + disk implies scsi-disk. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
According to Alan Cox: Chip: Wouldn't it be better just to *try* ioctls and see which ones work and which ones don't? 1. We have overlaps We all agree that overlaps need to be eliminated over time. In the meantime, as a coping strategy: I'll bet you that for any two given device classes, there is at least one ioctl that works on only one of them. (I'm only talking about an interim workaround! Calm down! Put down those bats!) 2. I've seen code where people play clever ioctl tricks to deduce a device type and it ends up looking like one of those chemistry identification charts (hopefully minus do you see smoke ?) I don't mean to suggest that ioctls be used to deduce device types (except in the case of overlapping ioctl numbers, which shouldn't be all *that* common (I hope)). I mean to suggest that the question What device type are you? usually shouldn't even be asked! If you want to do X to the device on fd, just call ioctl(fd, X, ...). Either it works or it doesn't. I realize that overlapping ioctls throw a monkey wrench into this world view. Is it a bigger wrench than the wrenching pain that we'll have to live through to make device identification reliable? Depends on how many ioctls overlap, and how easily we could make them stop overlapping. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] We have no fuel on board, plus or minus 8 kilograms. -- NEAR tech - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Setting kernel options at compile time.
I'm trying to get a 2.2.19 kernel loaded on an i810 system using RPLD on a diskless system. I can get the kernel loaded and running. The problem is the i810 needs the kernel parameter "mem=xxxM" set to tell the kernel how much memory the system has since the on the i810 the kernel doesn't know how much was taken for video. The catch I'm running into is RPLD cannot pass parameters to the kernel and without this setting the system has video problem, most likely from the memory sharing issues. When the mem parameter is set when using a disk it doesn't demonstrate any problems. What I'm trying to figure out is how to compile in this setting. Thanks, Chip Schweiss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Setting kernel options at compile time.
I'm trying to get a 2.2.19 kernel loaded on an i810 system using RPLD on a diskless system. I can get the kernel loaded and running. The problem is the i810 needs the kernel parameter mem=xxxM set to tell the kernel how much memory the system has since the on the i810 the kernel doesn't know how much was taken for video. The catch I'm running into is RPLD cannot pass parameters to the kernel and without this setting the system has video problem, most likely from the memory sharing issues. When the mem parameter is set when using a disk it doesn't demonstrate any problems. What I'm trying to figure out is how to compile in this setting. Thanks, Chip Schweiss - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Your message to linux-lvm awaits moderator approval
Rik van Riel writes: >[...] Andreas' patches got dropped over and over again and comments >on the LVM code got refused by the moderators at Sistina ... "The Net interprets censorship as damage and routes around it." -- John Gilmore -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Your message to linux-lvm awaits moderator approval
Rik van Riel writes: [...] Andreas' patches got dropped over and over again and comments on the LVM code got refused by the moderators at Sistina ... "The Net interprets censorship as damage and routes around it." -- John Gilmore -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape Corruption - update 2
In article <[EMAIL PROTECTED]> you write: >On Fri, 13 Apr 2001, Nate Eldredge wrote: >> (32 bytes is the size of a cache line.) A memory tester might be >> something to try (I wrote a simple program that seemed to show the >> error better than memtest86; can send it if desired.) > >Already tried that... this system has passed some 20 hours running >memtest86... I suggest you try Cerberus: https://sourceforge.net/projects/va-ctcs/ which will viciously beat your system to within an inch of its life. If you have any motherboard problems, they're more likely to show up with Cerberus than with a simple memtest. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI Tape Corruption - update 2
In article [EMAIL PROTECTED] you write: On Fri, 13 Apr 2001, Nate Eldredge wrote: (32 bytes is the size of a cache line.) A memory tester might be something to try (I wrote a simple program that seemed to show the error better than memtest86; can send it if desired.) Already tried that... this system has passed some 20 hours running memtest86... I suggest you try Cerberus: https://sourceforge.net/projects/va-ctcs/ which will viciously beat your system to within an inch of its life. If you have any motherboard problems, they're more likely to show up with Cerberus than with a simple memtest. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
According to [EMAIL PROTECTED]:
>[EMAIL PROTECTED] (Chip Salzenberg) wrote:
>>Why not have a kernel thread and use standard RPC techniques like
>>sockets? Then you'd not have to invent anything unimportant like
>>Yet Another IPC Technique.
>
>kerneld (kmod's late unlamented predecessor) used to use Unix sockets
>to communicate from the kernel to the daemon. It forced everybody to
>link Unix sockets into the kernel but there are some people out there
>who want to use it as a module. Also the kernel code for communicating
>with kerneld was "unpleasant", see ipc/msg.c in a 2.0 kernel.
I see.
On the other hand, file-style (e.g. /proc-style) access works in Plan9
at least inpart because each client makes his own connection to the
server. Thus, the question of how clients know which response is for
them is trivially solved. ('Server' would in this case be the JFS
kernel thread.)
Sockets are apparently not the right way to go about getting
transaction support for kernel threads.
AFAIK, Alex Viro's idea of bindable namespaces provides effective
transaction support *ONLY* if there are per-process bindings. With
per-process bindings, each client that opens a connection does so
through a distinct binding; when that client's responses go back
through the same binding, only that client can see them.
I hope that Alex's namespaces patch, implementing per-process
bindings, goes into the official kernel Real Soon Now.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
According to [EMAIL PROTECTED]:
[EMAIL PROTECTED] (Chip Salzenberg) wrote:
Why not have a kernel thread and use standard RPC techniques like
sockets? Then you'd not have to invent anything unimportant like
Yet Another IPC Technique.
kerneld (kmod's late unlamented predecessor) used to use Unix sockets
to communicate from the kernel to the daemon. It forced everybody to
link Unix sockets into the kernel but there are some people out there
who want to use it as a module. Also the kernel code for communicating
with kerneld was "unpleasant", see ipc/msg.c in a 2.0 kernel.
I see.
On the other hand, file-style (e.g. /proc-style) access works in Plan9
at least inpart because each client makes his own connection to the
server. Thus, the question of how clients know which response is for
them is trivially solved. ('Server' would in this case be the JFS
kernel thread.)
Sockets are apparently not the right way to go about getting
transaction support for kernel threads.
AFAIK, Alex Viro's idea of bindable namespaces provides effective
transaction support *ONLY* if there are per-process bindings. With
per-process bindings, each client that opens a connection does so
through a distinct binding; when that client's responses go back
through the same binding, only that client can see them.
I hope that Alex's namespaces patch, implementing per-process
bindings, goes into the official kernel Real Soon Now.
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: TCP Vegas implementation for Linux
Our (VA's) kernel includes a Vegas patch: ftp://ftp.valinux.com/pub/people/chip/linux-vegas-v2-patch-2.2 -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
In article <OF791BBBC5.E3FCBEEE-ON87256A18.005BA3B7@LocalDomain> you write: >With ioctl, I can easily match a response of any kind to a request. I can >even return an English text message if I want to be friendly. But ioctl requires allocation of numbers. Ugly and hard to scale. Alex Viro's idea is cleaner, but still requires a fair amount of coding even for simple interfaces. Why not have a kernel thread and use standard RPC techniques like sockets? Then you'd not have to invent anything unimportant like Yet Another IPC Technique. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
In article OF791BBBC5.E3FCBEEE-ON87256A18.005BA3B7@LocalDomain you write: With ioctl, I can easily match a response of any kind to a request. I can even return an English text message if I want to be friendly. But ioctl requires allocation of numbers. Ugly and hard to scale. Alex Viro's idea is cleaner, but still requires a fair amount of coding even for simple interfaces. Why not have a kernel thread and use standard RPC techniques like sockets? Then you'd not have to invent anything unimportant like Yet Another IPC Technique. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP Vegas implementation for Linux
Our (VA's) kernel includes a Vegas patch: ftp://ftp.valinux.com/pub/people/chip/linux-vegas-v2-patch-2.2 -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Remote Management (was Re: Alert on LAN)
According to Terje Malmedal: > I am aware of some motherboards where you can configure the BIOS via > RS232. What I want is some way to actually reset a machine that is > hung. That's possible with VACM-style management. It's not just for BIOS. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Remote Management (was Re: Alert on LAN)
According to Terje Malmedal: I am aware of some motherboards where you can configure the BIOS via RS232. What I want is some way to actually reset a machine that is hung. That's possible with VACM-style management. It's not just for BIOS. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE poweroff -> hangup
Andre Hedrick writes: >On Thu, 15 Mar 2001, CODEZ wrote: >> ide_dmaproc: chipset supported ide_dma_timeout func only: 14 >> I have ASUS 440BX/F mb with intel PIIX4 chipset.. > >All of the 440*X Chipsets using a PIIX4/PIIX4AB/PIIX4EB are broken beyond >repair. Well, that may be so; but I get the same error -- *precisely* the same error! -- on an SiS motherboard that quite clearly lacks a PIIX4: # lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev b1) 00:01.1 Class ff00: Silicon Integrated Systems [SiS] ACPI 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 11) 00:02.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP 00:0b.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang] 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 6306 3D-AGP (rev a2) # lspci -v -s0:0 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) Flags: bus master, medium devsel, latency 32 Memory at e000 (32-bit, non-prefetchable) Capabilities: [c0] AGP version 2.0 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8a [Master SecP PriP]) Subsystem: Silicon Integrated Systems [SiS] SiS5513 EIDE Controller (A,B step) Flags: bus master, fast devsel, latency 128, IRQ 14 I/O ports at e400 I/O ports at e000 I/O ports at d800 I/O ports at d400 I/O ports at d000 So... Any ideas? > I will pop a nasty patch to get you through the almost death, but it > is nasty and not the preferred unknow solution. I await your fugly patch with bated breath and baited fishook. -- Chip Salzenberga.k.a.<[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Remote Management (was Re: Alert on LAN)
IBM says, as quoted by Terje Malmedal: > With the latest release, Alert on LAN 2 now extends IT > capabilities to remotely manage and control their > networked PCs: > > Remote system reboot upon report of a critical failure > Repair Operating System > Update BIOS image > Perform other diagnostic procedures OK, fine... but: Where are the authentication and authorization?! Surely I'm not the only person to see in this "Alert On LAN 2" the potential for a security disaster. I know I will never buy anything that supports AOL2 until its security features are openly documented and testable. > The feature I really need is to be able to reset the machine > remotely when Linux is hung. Some current PC motherboards support remote management via a serial line. Of course, you'll need software: The VA Cluster Manager (GPL'd - http://sourceforge.net/projects/vacm) can monitor and control any number of clients, limited only by the number of serial ports you can give it. VACM also includes optional client support for enhanced monitoring, e.g. of temperatures. I'm not sure which motherboards it supports, but I'm sure you can find current documentation. :-) Granted, this is not cheap. A VACM-style approach costs some money for the monitor computer, and some convenience for installing the serial lines; meanwhile, AOL2 promises to do it all over Ethernet. But with VACM, you can be sure that somebody has to log in to the monitor computer -- with security levels you control! -- before they can control or even monitor any connected clients. BTW, in the spirit of full disclosure: VACM is a product of VA Linux engineering, and I work for VA. But VACM is GPL'd and we don't charge for it, so I have little financial interest in seeing it used. I just *hate* it when people play fast & loose with my security. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Remote Management (was Re: Alert on LAN)
IBM says, as quoted by Terje Malmedal: With the latest release, Alert on LAN 2 now extends IT capabilities to remotely manage and control their networked PCs: Remote system reboot upon report of a critical failure Repair Operating System Update BIOS image Perform other diagnostic procedures OK, fine... but: Where are the authentication and authorization?! Surely I'm not the only person to see in this "Alert On LAN 2" the potential for a security disaster. I know I will never buy anything that supports AOL2 until its security features are openly documented and testable. The feature I really need is to be able to reset the machine remotely when Linux is hung. Some current PC motherboards support remote management via a serial line. Of course, you'll need software: The VA Cluster Manager (GPL'd - http://sourceforge.net/projects/vacm) can monitor and control any number of clients, limited only by the number of serial ports you can give it. VACM also includes optional client support for enhanced monitoring, e.g. of temperatures. I'm not sure which motherboards it supports, but I'm sure you can find current documentation. :-) Granted, this is not cheap. A VACM-style approach costs some money for the monitor computer, and some convenience for installing the serial lines; meanwhile, AOL2 promises to do it all over Ethernet. But with VACM, you can be sure that somebody has to log in to the monitor computer -- with security levels you control! -- before they can control or even monitor any connected clients. BTW, in the spirit of full disclosure: VACM is a product of VA Linux engineering, and I work for VA. But VACM is GPL'd and we don't charge for it, so I have little financial interest in seeing it used. I just *hate* it when people play fast loose with my security. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE poweroff - hangup
Andre Hedrick writes: On Thu, 15 Mar 2001, CODEZ wrote: ide_dmaproc: chipset supported ide_dma_timeout func only: 14 I have ASUS 440BX/F mb with intel PIIX4 chipset.. All of the 440*X Chipsets using a PIIX4/PIIX4AB/PIIX4EB are broken beyond repair. Well, that may be so; but I get the same error -- *precisely* the same error! -- on an SiS motherboard that quite clearly lacks a PIIX4: # lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev b1) 00:01.1 Class ff00: Silicon Integrated Systems [SiS] ACPI 00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 11) 00:02.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP 00:0b.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang] 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 6306 3D-AGP (rev a2) # lspci -v -s0:0 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 530 Host (rev 02) Flags: bus master, medium devsel, latency 32 Memory at e000 (32-bit, non-prefetchable) Capabilities: [c0] AGP version 2.0 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8a [Master SecP PriP]) Subsystem: Silicon Integrated Systems [SiS] SiS5513 EIDE Controller (A,B step) Flags: bus master, fast devsel, latency 128, IRQ 14 I/O ports at e400 I/O ports at e000 I/O ports at d800 I/O ports at d400 I/O ports at d000 So... Any ideas? I will pop a nasty patch to get you through the almost death, but it is nasty and not the preferred unknow solution. I await your fugly patch with bated breath and baited fishook. -- Chip Salzenberga.k.a.[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tulip] Linux 2.2.16/Tulip Smartbits testing.
John, It's the driver. We have been doing smartbits testing for more than a year and found the same results as you appear to be getting. The driver just dies and never recovers. It attempts to do interrupt mitigation(coalescing) but that appears to be useless. The solution is to write a new driver which is what we have done here... Chip _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tulip] Linux 2.2.16/Tulip Smartbits testing.
John, It's the driver. We have been doing smartbits testing for more than a year and found the same results as you appear to be getting. The driver just dies and never recovers. It attempts to do interrupt mitigation(coalescing) but that appears to be useless. The solution is to write a new driver which is what we have done here... Chip _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi
With Andre's IDE subsystem, I found the below patch necessary to use
my IDE tape drive (Exabyte Eagle TR-4). Frankly, it's been so long
since I created this patch that I can't remember the detailed reasons
for the changes. But I knew them once. :-) And it works for me.
Reminder, this is against Andre Hedrick's 2.2 IDE subsystem.
Index: drivers/block/ide-tape.c
--- drivers/block/ide-tape.c.prev
+++ drivers/block/ide-tape.cTue Dec 5 01:17:32 2000
@@ -3096,7 +3096,10 @@ static int idetape_queue_pc_tail (ide_dr
static int idetape_flush_tape_buffers (ide_drive_t *drive)
{
+ idetape_tape_t *tape = drive->driver_data;
idetape_pc_t pc;
int rc;
+ if (tape->chrdev_direction != idetape_direction_write)
+ return 0;
idetape_create_write_filemark_cmd(drive, , 0);
if ((rc = idetape_queue_pc_tail (drive,)))
@@ -5199,12 +5202,15 @@ static int idetape_chrdev_open (struct i
if (tape->chrdev_direction == idetape_direction_none) {
MOD_INC_USE_COUNT;
+ if (tape->onstream) {
#if ONSTREAM_DEBUG
- if (tape->debug_level >= 6)
- printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT in
idetape_chrdev_open-2\n");
+ if (tape->debug_level >= 6)
+ printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT"
+ " in idetape_chrdev_open-2\n");
#endif
- idetape_create_prevent_cmd(drive, , 1);
- if (!idetape_queue_pc_tail (drive,)) {
- if (tape->door_locked != DOOR_EXPLICITLY_LOCKED)
- tape->door_locked = DOOR_LOCKED;
+ idetape_create_prevent_cmd(drive, , 1);
+ if (!idetape_queue_pc_tail (drive,)) {
+ if (tape->door_locked != DOOR_EXPLICITLY_LOCKED)
+ tape->door_locked = DOOR_LOCKED;
+ }
}
idetape_analyze_headers(drive);
@@ -5258,14 +5264,17 @@ static int idetape_chrdev_release (struc
(void) idetape_rewind_tape (drive);
if (tape->chrdev_direction == idetape_direction_none) {
- if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) {
- idetape_create_prevent_cmd(drive, , 0);
- if (!idetape_queue_pc_tail (drive,))
- tape->door_locked = DOOR_UNLOCKED;
- }
- MOD_DEC_USE_COUNT;
+ if (tape->onstream) {
+ if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) {
+ idetape_create_prevent_cmd(drive, , 0);
+ if (!idetape_queue_pc_tail (drive,))
+ tape->door_locked = DOOR_UNLOCKED;
+ }
#if ONSTREAM_DEBUG
- if (tape->debug_level >= 6)
- printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in
idetape_chrdev_release\n");
+ if (tape->debug_level >= 6)
+ printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT"
+ " in idetape_chrdev_release\n");
#endif
+ }
+ MOD_DEC_USE_COUNT;
}
clear_bit (IDETAPE_BUSY, >flags);
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi
With Andre's IDE subsystem, I found the below patch necessary to use
my IDE tape drive (Exabyte Eagle TR-4). Frankly, it's been so long
since I created this patch that I can't remember the detailed reasons
for the changes. But I knew them once. :-) And it works for me.
Reminder, this is against Andre Hedrick's 2.2 IDE subsystem.
Index: drivers/block/ide-tape.c
--- drivers/block/ide-tape.c.prev
+++ drivers/block/ide-tape.cTue Dec 5 01:17:32 2000
@@ -3096,7 +3096,10 @@ static int idetape_queue_pc_tail (ide_dr
static int idetape_flush_tape_buffers (ide_drive_t *drive)
{
+ idetape_tape_t *tape = drive-driver_data;
idetape_pc_t pc;
int rc;
+ if (tape-chrdev_direction != idetape_direction_write)
+ return 0;
idetape_create_write_filemark_cmd(drive, pc, 0);
if ((rc = idetape_queue_pc_tail (drive,pc)))
@@ -5199,12 +5202,15 @@ static int idetape_chrdev_open (struct i
if (tape-chrdev_direction == idetape_direction_none) {
MOD_INC_USE_COUNT;
+ if (tape-onstream) {
#if ONSTREAM_DEBUG
- if (tape-debug_level = 6)
- printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT in
idetape_chrdev_open-2\n");
+ if (tape-debug_level = 6)
+ printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT"
+ " in idetape_chrdev_open-2\n");
#endif
- idetape_create_prevent_cmd(drive, pc, 1);
- if (!idetape_queue_pc_tail (drive,pc)) {
- if (tape-door_locked != DOOR_EXPLICITLY_LOCKED)
- tape-door_locked = DOOR_LOCKED;
+ idetape_create_prevent_cmd(drive, pc, 1);
+ if (!idetape_queue_pc_tail (drive,pc)) {
+ if (tape-door_locked != DOOR_EXPLICITLY_LOCKED)
+ tape-door_locked = DOOR_LOCKED;
+ }
}
idetape_analyze_headers(drive);
@@ -5258,14 +5264,17 @@ static int idetape_chrdev_release (struc
(void) idetape_rewind_tape (drive);
if (tape-chrdev_direction == idetape_direction_none) {
- if (tape-door_locked != DOOR_EXPLICITLY_LOCKED) {
- idetape_create_prevent_cmd(drive, pc, 0);
- if (!idetape_queue_pc_tail (drive,pc))
- tape-door_locked = DOOR_UNLOCKED;
- }
- MOD_DEC_USE_COUNT;
+ if (tape-onstream) {
+ if (tape-door_locked != DOOR_EXPLICITLY_LOCKED) {
+ idetape_create_prevent_cmd(drive, pc, 0);
+ if (!idetape_queue_pc_tail (drive,pc))
+ tape-door_locked = DOOR_UNLOCKED;
+ }
#if ONSTREAM_DEBUG
- if (tape-debug_level = 6)
- printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in
idetape_chrdev_release\n");
+ if (tape-debug_level = 6)
+ printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT"
+ " in idetape_chrdev_release\n");
#endif
+ }
+ MOD_DEC_USE_COUNT;
}
clear_bit (IDETAPE_BUSY, tape-flags);
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to J . A . Magallon: > Please, I think it would be much more useful a patch against the latest > 2.2.19-pre (if that one for 2.2.18 does not work, I have not tried) > and the latest 2.4.1-ac14, that is what people experiments with. There's no end of versions that people use. Might I suggest that Justin imitate the maintainers of lm_sensors, and create a program (shell script, Perl program, whatever) that *creates* a patch against any given Linux source tree? Obviously it could break in the face of weird trees, but even minimal flexibility would save him a lot of work ... -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to J . A . Magallon: Please, I think it would be much more useful a patch against the latest 2.2.19-pre (if that one for 2.2.18 does not work, I have not tried) and the latest 2.4.1-ac14, that is what people experiments with. There's no end of versions that people use. Might I suggest that Justin imitate the maintainers of lm_sensors, and create a program (shell script, Perl program, whatever) that *creates* a patch against any given Linux source tree? Obviously it could break in the face of weird trees, but even minimal flexibility would save him a lot of work ... -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to Matthew Jacob: > See http://www.freebsd.org/~gibbs/linux. Here at VA we're already using Jason's driver -- it works on the Intel STL2 motherboard, while Doug's driver doesn't (or didn't, a month ago). While we're discussing SCSI drivers, I'd also like to put in a good word for the Sym-2 Symbios/NCR drivers from Gerard Roudier: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/ Joe-Bob says: "Check it out." -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to Matthew Jacob: See http://www.freebsd.org/~gibbs/linux. Here at VA we're already using Jason's driver -- it works on the Intel STL2 motherboard, while Doug's driver doesn't (or didn't, a month ago). While we're discussing SCSI drivers, I'd also like to put in a good word for the Sym-2 Symbios/NCR drivers from Gerard Roudier: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/ Joe-Bob says: "Check it out." -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] inter_module_* backport to 2.2.18
arbitrary string to identify the data, must be unique
+ *
+ * Description: Check that the im_name has been registered, complain if
+ * it has not. For existing data, remove it from the
+ * inter_module_entry list.
+ */
+void inter_module_unregister(const char *im_name)
+{
+ struct list_head *tmp;
+ struct inter_module_entry *ime;
+
+ spin_lock(_lock);
+ list_for_each(tmp, _list) {
+ ime = list_entry(tmp, struct inter_module_entry, list);
+ if (strcmp(ime->im_name, im_name) == 0) {
+ list_del(&(ime->list));
+ spin_unlock(_lock);
+ kfree(ime);
+ return;
+ }
+ }
+ spin_unlock(_lock);
+ if (kmalloc_failed) {
+ printk(KERN_ERR
+ "inter_module_unregister: no entry for '%s', "
+ "probably caused by previous kmalloc failure\n",
+ im_name);
+ return;
+ }
+ else {
+ /* Program logic error, fatal */
+ printk(KERN_ERR "inter_module_unregister: no entry for '%s'", im_name);
+ BUG();
+ }
+}
+
+/**
+ * inter_module_get - return arbitrary userdata from another module.
+ * @im_name: an arbitrary string to identify the data, must be unique
+ *
+ * Description: If the im_name has not been registered, return NULL.
+ * Try to increment the use count on the owning module, if that fails
+ * then return NULL. Otherwise return the userdata.
+ */
+const void *inter_module_get(const char *im_name)
+{
+ struct list_head *tmp;
+ struct inter_module_entry *ime;
+ const void *result = NULL;
+
+ spin_lock(_lock);
+ list_for_each(tmp, _list) {
+ ime = list_entry(tmp, struct inter_module_entry, list);
+ if (strcmp(ime->im_name, im_name) == 0) {
+ if (try_inc_mod_count(ime->owner))
+ result = ime->userdata;
+ break;
+ }
+ }
+ spin_unlock(_lock);
+ return(result);
+}
+
+/**
+ * inter_module_get_request - im get with automatic request_module.
+ * @im_name: an arbitrary string to identify the data, must be unique
+ * @modname: module that is expected to register im_name
+ *
+ * Description: If inter_module_get fails, do request_module then retry.
+ */
+const void *inter_module_get_request(const char *im_name, const char *modname)
+{
+ const void *result = inter_module_get(im_name);
+ if (!result) {
+ request_module(modname);
+ result = inter_module_get(im_name);
+ }
+ return(result);
+}
+
+/**
+ * inter_module_put - release use of data from another module.
+ * @im_name: an arbitrary string to identify the data, must be unique
+ *
+ * Description: If the im_name has not been registered, complain,
+ * otherwise decrement the use count on the owning module.
+ */
+void inter_module_put(const char *im_name)
+{
+ struct list_head *tmp;
+ struct inter_module_entry *ime;
+
+ spin_lock(_lock);
+ list_for_each(tmp, _list) {
+ ime = list_entry(tmp, struct inter_module_entry, list);
+ if (strcmp(ime->im_name, im_name) == 0) {
+ if (ime->owner)
+ __MOD_DEC_USE_COUNT(ime->owner);
+ spin_unlock(_lock);
+ return;
+ }
+ }
+ spin_unlock(_lock);
+ printk(KERN_ERR "inter_module_put: no entry for '%s'", im_name);
+ BUG();
+}
+
+
+#if defined(CONFIG_MODULES)/* The rest of the source */
+
static long get_mod_name(const char *user_name, char **buf);
static void put_mod_name(char *buf);
@@ -368,4 +538,19 @@ err0:
}
+static spinlock_t unload_lock = SPIN_LOCK_UNLOCKED;
+int try_inc_mod_count(struct module *mod)
+{
+ int res = 1;
+ if (mod) {
+ spin_lock(_lock);
+ if (mod->flags & MOD_DELETED)
+ res = 0;
+ else
+ __MOD_INC_USE_COUNT(mod);
+ spin_unlock(_lock);
+ }
+ return res;
+}
+
asmlinkage int
sys_delete_module(const char *name_user)
@@ -1039,4 +1224,9 @@ sys_get_kernel_syms(struct kernel_sym *t
{
return -ENOSYS;
+}
+
+int try_inc_mod_count(struct module *mod)
+{
+ return 1;
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: FAIL: 2.2.18 + AA-VM-global-7 + serial 5.05
According to Matthias Andree:
> I have a vanilla 2.2.18 that I patch Andrea Arcangeli's VM-global-7
> patch (for 2.2.18pre25) on top, as well as I²C 2.5.4, the current
> --12-09 IDE.2.2.18 patch and ReiserFS 3.5.28. So far, so good. If I now
> patch serial 5.05 on top of that, the kernel itself detects devices, but
> does nothing if it's to boot /sbin/init. ctrl-alt-del and Magic SysRq
> are both functional and can reboot the machine.
VA's current kernel includes VM-global and serial-5.05 (and lots of
other stuff :-)). The only problem we had with serial-5.05 was its
2.2/2.4 compatibility code getting confused because 2.2.18 has more
of 2.4's init macros available. Try this:
Index: tty_io.c
===
RCS file: /cvs/valinux/kernel/linux/drivers/char/tty_io.c,v
retrieving revision 1.2
retrieving revision 1.2.12.1
diff -u -2 -p -r1.2 -r1.2.12.1
--- tty_io.c2000/08/30 21:33:27 1.2
+++ tty_io.c2000/09/28 08:21:34 1.2.12.1
@@ -2185,7 +2185,4 @@ __initfunc(int tty_init(void))
espserial_init();
#endif
-#ifdef CONFIG_SERIAL
- rs_init();
-#endif
#ifdef CONFIG_COMPUTONE
ip2_init();
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: FAIL: 2.2.18 + AA-VM-global-7 + serial 5.05
According to Matthias Andree: I have a vanilla 2.2.18 that I patch Andrea Arcangeli's VM-global-7 patch (for 2.2.18pre25) on top, as well as I²C 2.5.4, the current --12-09 IDE.2.2.18 patch and ReiserFS 3.5.28. So far, so good. If I now patch serial 5.05 on top of that, the kernel itself detects devices, but does nothing if it's to boot /sbin/init. ctrl-alt-del and Magic SysRq are both functional and can reboot the machine. VA's current kernel includes VM-global and serial-5.05 (and lots of other stuff :-)). The only problem we had with serial-5.05 was its 2.2/2.4 compatibility code getting confused because 2.2.18 has more of 2.4's init macros available. Try this: Index: tty_io.c === RCS file: /cvs/valinux/kernel/linux/drivers/char/tty_io.c,v retrieving revision 1.2 retrieving revision 1.2.12.1 diff -u -2 -p -r1.2 -r1.2.12.1 --- tty_io.c2000/08/30 21:33:27 1.2 +++ tty_io.c2000/09/28 08:21:34 1.2.12.1 @@ -2185,7 +2185,4 @@ __initfunc(int tty_init(void)) espserial_init(); #endif -#ifdef CONFIG_SERIAL - rs_init(); -#endif #ifdef CONFIG_COMPUTONE ip2_init(); -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: > On Wed, 13 Dec 2000, Chip Salzenberg wrote: > > According to Alexander Viro: > > > On Wed, 13 Dec 2000, Chip Salzenberg wrote: > > > > According to Alexander Viro: > > > > > 9P is quite simple and unlike CORBA it had been designed for taking > > > > > kernel stuff to userland. Besides, authors definitely understand > > > > > UNIX... > > > > > > > > As nice as 9P is, it'll need some tweaks to work with Linux. > > > > For example, it limits filenames to 30 characters; that's not OK. > > > > > > For RPC-style uses? Why? > > > > For the same reason C compilers recognize more than eight significant > > characters in externals, even though ANSI doesn't require them to. > > s/30/255/ and you've got a big problem with ext2... As long as names are to be created, or at least understood, by humans, there will be some limit on *usable* length. In my experience, 255 is above that limit, but 30 is below it. And I cut my teeth on a system that had exactly that length limitation (UNOS). -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: > 9P is quite simple and unlike CORBA it had been designed for taking > kernel stuff to userland. Besides, authors definitely understand > UNIX... As nice as 9P is, it'll need some tweaks to work with Linux. For example, it limits filenames to 30 characters; that's not OK. -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: 9P is quite simple and unlike CORBA it had been designed for taking kernel stuff to userland. Besides, authors definitely understand UNIX... As nice as 9P is, it'll need some tweaks to work with Linux. For example, it limits filenames to 30 characters; that's not OK. -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: On Wed, 13 Dec 2000, Chip Salzenberg wrote: According to Alexander Viro: On Wed, 13 Dec 2000, Chip Salzenberg wrote: According to Alexander Viro: 9P is quite simple and unlike CORBA it had been designed for taking kernel stuff to userland. Besides, authors definitely understand UNIX... As nice as 9P is, it'll need some tweaks to work with Linux. For example, it limits filenames to 30 characters; that's not OK. For RPC-style uses? Why? For the same reason C compilers recognize more than eight significant characters in externals, even though ANSI doesn't require them to. s/30/255/ and you've got a big problem with ext2... As long as names are to be created, or at least understood, by humans, there will be some limit on *usable* length. In my experience, 255 is above that limit, but 30 is below it. And I cut my teeth on a system that had exactly that length limitation (UNOS). -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blindingly stupid 2.2 VM bug
According to Rik van Riel:
> Luckily my patch fixes some of the suspect areas in
> VM-global [...]
Would you say that the below patch is just the try_to_free_pages
bug fix, then?
Index: mm/vmscan.c
--- mm/vmscan.c.prev
+++ mm/vmscan.c Fri Nov 24 15:17:59 2000
@@ -401,4 +401,5 @@ int try_to_free_pages(unsigned int gfp_m
int priority;
int count = SWAP_CLUSTER_MAX;
+ int loopcount = count;
int killed = 0;
@@ -409,5 +410,5 @@ int try_to_free_pages(unsigned int gfp_m
again:
- priority = 5;
+ priority = 6;
do {
while (shrink_mmap(priority, gfp_mask)) {
@@ -431,5 +432,10 @@ again:
shrink_dcache_memory(priority, gfp_mask);
- } while (--priority > 0);
+
+ /* Only lower priority if we didn't make progress. */
+ if (count == loopcount)
+ --priority;
+ loopcount = count;
+ } while (priority > 0);
done:
unlock_kernel();
@@ -454,6 +460,9 @@ done:
}
- /* Return success if we freed a page. */
- return priority > 0;
+ /* Return success if we have enough free memory or we freed a page. */
+ if (nr_free_pages > freepages.low)
+ return 1;
+
+ return count < SWAP_CLUSTER_MAX;
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] blindingly stupid 2.2 VM bug
According to Rik van Riel:
Luckily my patch fixes some of the suspect areas in
VM-global [...]
Would you say that the below patch is just the try_to_free_pages
bug fix, then?
Index: mm/vmscan.c
--- mm/vmscan.c.prev
+++ mm/vmscan.c Fri Nov 24 15:17:59 2000
@@ -401,4 +401,5 @@ int try_to_free_pages(unsigned int gfp_m
int priority;
int count = SWAP_CLUSTER_MAX;
+ int loopcount = count;
int killed = 0;
@@ -409,5 +410,5 @@ int try_to_free_pages(unsigned int gfp_m
again:
- priority = 5;
+ priority = 6;
do {
while (shrink_mmap(priority, gfp_mask)) {
@@ -431,5 +432,10 @@ again:
shrink_dcache_memory(priority, gfp_mask);
- } while (--priority 0);
+
+ /* Only lower priority if we didn't make progress. */
+ if (count == loopcount)
+ --priority;
+ loopcount = count;
+ } while (priority 0);
done:
unlock_kernel();
@@ -454,6 +460,9 @@ done:
}
- /* Return success if we freed a page. */
- return priority 0;
+ /* Return success if we have enough free memory or we freed a page. */
+ if (nr_free_pages freepages.low)
+ return 1;
+
+ return count SWAP_CLUSTER_MAX;
}
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: NFSD dentry manipulation (was Re: d_move())
ent, then
-* it is well connected. But nobody returns different dentrys do they?
-*/
- pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry);
- d_drop(tdentry); /* we never want ".." hashed */
- if (!pdentry) {
- /* I don't want to return a ".." dentry.
-* I would prefer to return an unconnected "IS_ROOT" dentry,
-* though a properly connected dentry is even better
-*/
- /* if first or last of alias list is not tdentry, use that
-* else make a root dentry
-*/
- struct list_head *aliases = >d_inode->i_dentry;
- if (aliases->next != aliases) {
- pdentry = list_entry(aliases->next, struct dentry, d_alias);
- if (pdentry == tdentry)
- pdentry = list_entry(aliases->prev, struct dentry,
d_alias);
- if (pdentry == tdentry)
- pdentry = NULL;
- if (pdentry) dget(pdentry);
- }
- if (pdentry == NULL) {
- pdentry = d_alloc_root(igrab(tdentry->d_inode), NULL);
- if (pdentry) {
- pdentry->d_flags |= DCACHE_NFSD_DISCONNECTED;
- d_rehash(pdentry);
- }
- }
- if (pdentry == NULL)
- pdentry = ERR_PTR(-ENOMEM);
+ if (parent)
+ dput(dotdot); /* not hashed, thus discarded */
+ else {
+ /* Discard the ".." dentry, then arrange for a better one. */
+ struct inode *inode = igrab(dotdot->d_inode);
+ dput(dotdot); /* not hashed, thus discarded */
+ parent = nfsd_arrange_dentry(inode);
}
- dput(tdentry); /* it is not hashed, it will be discarded */
- return pdentry;
+ return parent;
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: NFSD dentry manipulation (was Re: d_move())
inode-i_op-lookup(child-d_inode, tdentry);
- d_drop(tdentry); /* we never want ".." hashed */
- if (!pdentry) {
- /* I don't want to return a ".." dentry.
-* I would prefer to return an unconnected "IS_ROOT" dentry,
-* though a properly connected dentry is even better
-*/
- /* if first or last of alias list is not tdentry, use that
-* else make a root dentry
-*/
- struct list_head *aliases = tdentry-d_inode-i_dentry;
- if (aliases-next != aliases) {
- pdentry = list_entry(aliases-next, struct dentry, d_alias);
- if (pdentry == tdentry)
- pdentry = list_entry(aliases-prev, struct dentry,
d_alias);
- if (pdentry == tdentry)
- pdentry = NULL;
- if (pdentry) dget(pdentry);
- }
- if (pdentry == NULL) {
- pdentry = d_alloc_root(igrab(tdentry-d_inode), NULL);
- if (pdentry) {
- pdentry-d_flags |= DCACHE_NFSD_DISCONNECTED;
- d_rehash(pdentry);
- }
- }
- if (pdentry == NULL)
- pdentry = ERR_PTR(-ENOMEM);
+ if (parent)
+ dput(dotdot); /* not hashed, thus discarded */
+ else {
+ /* Discard the ".." dentry, then arrange for a better one. */
+ struct inode *inode = igrab(dotdot-d_inode);
+ dput(dotdot); /* not hashed, thus discarded */
+ parent = nfsd_arrange_dentry(inode);
}
- dput(tdentry); /* it is not hashed, it will be discarded */
- return pdentry;
+ return parent;
}
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18: d_move() with self-root dentries (Dentry Corruption!)
This may be 2.2.18 material after all I wrote last night:
> Making nfsd's d_splice() compensate for d_move's limitations is not
> only a kludge, but also it harder to keep nfsd correct.
> someday, nfsd may not be the only creator of this kind of dentry.
Sure enough, there is just such a bug *already* in nfsd. Nfsd's
cleanup after d_move is incomplete: It handles one of the dentries
being parentless, but not the other one. This bug *will* cause dentry
corruption.[1] It may well be what's been causing the hangs that my
recent patches seem to have fixed.
Therefore, in the mainline kernel, we need either the below patch to
d_move (along with a trivial simplifcation of nfsd's use of it), or an
expansion of the kludge in nfsd. You can guess which one I favor
[1] The bug can only show up when reconstructing pruned dentries, and
only under a specific pattern of client requests, so it's not
surprising that it is rarely observed in the wild.
Index: fs/dcache.c
--- fs/dcache.c.prev
+++ fs/dcache.c Mon Nov 20 22:31:09 2000
@@ -749,16 +749,28 @@ void d_move(struct dentry * dentry, stru
INIT_LIST_HEAD(>d_hash);
+ /* Switch the names */
+ switch_names(dentry, target);
+ do_switch(dentry->d_name.len, target->d_name.len);
+ do_switch(dentry->d_name.hash, target->d_name.hash);
+
+ /* Switch parentage, allowing for self-parents */
+
list_del(>d_child);
list_del(>d_child);
- /* Switch the parents and the names.. */
- switch_names(dentry, target);
do_switch(dentry->d_parent, target->d_parent);
- do_switch(dentry->d_name.len, target->d_name.len);
- do_switch(dentry->d_name.hash, target->d_name.hash);
- /* And add them back to the (new) parent lists */
- list_add(>d_child, >d_parent->d_subdirs);
- list_add(>d_child, >d_parent->d_subdirs);
+ if (dentry->d_parent != target)
+ list_add(>d_child, >d_parent->d_subdirs);
+ else {
+ INIT_LIST_HEAD(>d_child);
+ dentry->d_parent = dentry;
+ }
+ if (target->d_parent != dentry)
+ list_add(>d_child, >d_parent->d_subdirs);
+ else {
+ INIT_LIST_HEAD(>d_child);
+ target->d_parent = target;
+ }
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18: d_move() with self-root dentries
The d_move() function doesn't correctly handle dentries that have no
parents (i.e. 'x->d_parent==x'). This patch lets it do so.
Normally, the only parentless dentries are filesystem roots. However,
the NFS server creates (temporary) parentless dentries whenever dentry
pruning has deleted the dentries referring to clients' open files.
Making nfsd's d_splice() compensate for d_move's limitations is not
only a kludge, but also it harder to keep nfsd correct. Besides,
someday, nfsd may not be the only creator of this kind of dentry.
Thus, this patch. If you apply this, you'll also want to patch
fs/nfsd/nfsfh.c to stop compensating for d_move's old limitations.
(Alan, this is 2.2.19 material [if then].)
Index: fs/dcache.c
--- fs/dcache.c.prev
+++ fs/dcache.c Mon Nov 20 22:31:09 2000
@@ -749,16 +749,28 @@ void d_move(struct dentry * dentry, stru
INIT_LIST_HEAD(>d_hash);
+ /* Switch the names */
+ switch_names(dentry, target);
+ do_switch(dentry->d_name.len, target->d_name.len);
+ do_switch(dentry->d_name.hash, target->d_name.hash);
+
+ /* Switch parentage, allowing for self-parents */
+
list_del(>d_child);
list_del(>d_child);
- /* Switch the parents and the names.. */
- switch_names(dentry, target);
do_switch(dentry->d_parent, target->d_parent);
- do_switch(dentry->d_name.len, target->d_name.len);
- do_switch(dentry->d_name.hash, target->d_name.hash);
- /* And add them back to the (new) parent lists */
- list_add(>d_child, >d_parent->d_subdirs);
- list_add(>d_child, >d_parent->d_subdirs);
+ if (dentry->d_parent != target)
+ list_add(>d_child, >d_parent->d_subdirs);
+ else {
+ INIT_LIST_HEAD(>d_child);
+ dentry->d_parent = dentry;
+ }
+ if (target->d_parent != dentry)
+ list_add(>d_child, >d_parent->d_subdirs);
+ else {
+ INIT_LIST_HEAD(>d_child);
+ target->d_parent = target;
+ }
}
--
Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]>
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18: d_move() with self-root dentries
The d_move() function doesn't correctly handle dentries that have no
parents (i.e. 'x-d_parent==x'). This patch lets it do so.
Normally, the only parentless dentries are filesystem roots. However,
the NFS server creates (temporary) parentless dentries whenever dentry
pruning has deleted the dentries referring to clients' open files.
Making nfsd's d_splice() compensate for d_move's limitations is not
only a kludge, but also it harder to keep nfsd correct. Besides,
someday, nfsd may not be the only creator of this kind of dentry.
Thus, this patch. If you apply this, you'll also want to patch
fs/nfsd/nfsfh.c to stop compensating for d_move's old limitations.
(Alan, this is 2.2.19 material [if then].)
Index: fs/dcache.c
--- fs/dcache.c.prev
+++ fs/dcache.c Mon Nov 20 22:31:09 2000
@@ -749,16 +749,28 @@ void d_move(struct dentry * dentry, stru
INIT_LIST_HEAD(target-d_hash);
+ /* Switch the names */
+ switch_names(dentry, target);
+ do_switch(dentry-d_name.len, target-d_name.len);
+ do_switch(dentry-d_name.hash, target-d_name.hash);
+
+ /* Switch parentage, allowing for self-parents */
+
list_del(dentry-d_child);
list_del(target-d_child);
- /* Switch the parents and the names.. */
- switch_names(dentry, target);
do_switch(dentry-d_parent, target-d_parent);
- do_switch(dentry-d_name.len, target-d_name.len);
- do_switch(dentry-d_name.hash, target-d_name.hash);
- /* And add them back to the (new) parent lists */
- list_add(target-d_child, target-d_parent-d_subdirs);
- list_add(dentry-d_child, dentry-d_parent-d_subdirs);
+ if (dentry-d_parent != target)
+ list_add(dentry-d_child, dentry-d_parent-d_subdirs);
+ else {
+ INIT_LIST_HEAD(dentry-d_child);
+ dentry-d_parent = dentry;
+ }
+ if (target-d_parent != dentry)
+ list_add(target-d_child, target-d_parent-d_subdirs);
+ else {
+ INIT_LIST_HEAD(target-d_child);
+ target-d_parent = target;
+ }
}
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18: d_move() with self-root dentries (Dentry Corruption!)
This may be 2.2.18 material after all I wrote last night:
Making nfsd's d_splice() compensate for d_move's limitations is not
only a kludge, but also it harder to keep nfsd correct.
someday, nfsd may not be the only creator of this kind of dentry.
Sure enough, there is just such a bug *already* in nfsd. Nfsd's
cleanup after d_move is incomplete: It handles one of the dentries
being parentless, but not the other one. This bug *will* cause dentry
corruption.[1] It may well be what's been causing the hangs that my
recent patches seem to have fixed.
Therefore, in the mainline kernel, we need either the below patch to
d_move (along with a trivial simplifcation of nfsd's use of it), or an
expansion of the kludge in nfsd. You can guess which one I favor
[1] The bug can only show up when reconstructing pruned dentries, and
only under a specific pattern of client requests, so it's not
surprising that it is rarely observed in the wild.
Index: fs/dcache.c
--- fs/dcache.c.prev
+++ fs/dcache.c Mon Nov 20 22:31:09 2000
@@ -749,16 +749,28 @@ void d_move(struct dentry * dentry, stru
INIT_LIST_HEAD(target-d_hash);
+ /* Switch the names */
+ switch_names(dentry, target);
+ do_switch(dentry-d_name.len, target-d_name.len);
+ do_switch(dentry-d_name.hash, target-d_name.hash);
+
+ /* Switch parentage, allowing for self-parents */
+
list_del(dentry-d_child);
list_del(target-d_child);
- /* Switch the parents and the names.. */
- switch_names(dentry, target);
do_switch(dentry-d_parent, target-d_parent);
- do_switch(dentry-d_name.len, target-d_name.len);
- do_switch(dentry-d_name.hash, target-d_name.hash);
- /* And add them back to the (new) parent lists */
- list_add(target-d_child, target-d_parent-d_subdirs);
- list_add(dentry-d_child, dentry-d_parent-d_subdirs);
+ if (dentry-d_parent != target)
+ list_add(dentry-d_child, dentry-d_parent-d_subdirs);
+ else {
+ INIT_LIST_HEAD(dentry-d_child);
+ dentry-d_parent = dentry;
+ }
+ if (target-d_parent != dentry)
+ list_add(target-d_child, target-d_parent-d_subdirs);
+ else {
+ INIT_LIST_HEAD(target-d_child);
+ target-d_parent = target;
+ }
}
--
Chip Salzenberg- a.k.a. -[EMAIL PROTECTED]
"Give me immortality, or give me death!" // Firesign Theatre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre21: DRM update
This is an update from the main DRM tree, but with cosmetic changes
removed and only meat left. This patch is already in VA's shipping
kernel, so you know we really trust it. :-,
BTW, this patch is not fluff: It includes bug fixes. But it's pretty
big, so if you want to wait until 2.2.19 I'll understand
Index: drivers/char/Makefile
--- drivers/char/Makefile.prev
+++ drivers/char/Makefile Fri Nov 17 13:30:04 2000
@@ -12,5 +12,5 @@
SUB_DIRS :=
MOD_SUB_DIRS := $(SUB_DIRS)
-ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick drm agp
+ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick
#
@@ -395,4 +395,16 @@
endif
+ifeq ($(CONFIG_DRM),y)
+O_OBJS += drm/drm.o
+ALL_SUB_DIRS += drm
+MOD_SUB_DIRS += drm
+SUB_DIRS += drm
+else
+ ifeq ($(CONFIG_DRM),m)
+ ALL_SUB_DIRS += drm
+ MOD_SUB_DIRS += drm
+ endif
+endif
+
ifeq ($(CONFIG_INTEL_RNG),y)
O_OBJS += i810_rng.o
@@ -650,16 +662,4 @@
OX_OBJS += h8.o
endif
-
-
-ifeq ($(CONFIG_DRM),y)
-SUB_DIRS += drm
-O_OBJS += drm/drm.o
-MOD_SUB_DIRS += drm
-else
- ifeq ($(CONFIG_DRM),m)
- MOD_SUB_DIRS += drm
- endif
-endif
-
ifeq ($(L_I2C),y)
Index: drivers/char/drm/drmP.h
--- drivers/char/drm/drmP.h.prev
+++ drivers/char/drm/drmP.h Fri Nov 17 13:30:04 2000
@@ -34,4 +34,9 @@
#ifdef __KERNEL__
+#ifdef __alpha__
+/* add include of current.h so that "current" is defined
+ * before static inline funcs in wait.h. 4/21/2000 S + B */
+#include
+#endif /* __alpha__ */
#include
#include
@@ -47,8 +52,11 @@
#include
#include /* For (un)lock_kernel */
+#include
+#ifdef __alpha__
+#include /* For pte_wrprotect */
+#endif
#include
#include
#include
-#include
#ifdef CONFIG_MTRR
#include
@@ -133,8 +141,86 @@
#endif
+ /* module_init/module_exit added in 2.3.13 */
+#ifndef module_init
+#define module_init(x) int init_module(void) { return x(); }
+#endif
+#ifndef module_exit
+#define module_exit(x) void cleanup_module(void) { x(); }
+#endif
+
+ /* virt_to_page added in 2.4.0-test6 */
+#if LINUX_VERSION_CODE < 0x020400
+#define virt_to_page(kaddr) (mem_map + MAP_NR(kaddr))
+#endif
+
/* Generic cmpxchg added in 2.3.x */
#ifndef __HAVE_ARCH_CMPXCHG
/* Include this here so that driver can be
used with older kernels. */
+#if defined(__alpha__)
+static __inline__ unsigned long
+__cmpxchg_u32(volatile int *m, int old, int new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldl_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stl_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "="(prev), "="(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg_u64(volatile long *m, unsigned long old, unsigned long new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldq_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stq_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "="(prev), "="(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+ switch (size) {
+ case 4:
+ return __cmpxchg_u32(ptr, old, new);
+ case 8:
+ return __cmpxchg_u64(ptr, old, new);
+ }
+ return old;
+}
+#define cmpxchg(ptr,o,n)\
+ ({\
+ __typeof__(*(ptr)) _o_ = (o); \
+ __typeof__(*(ptr)) _n_ = (n); \
+ (__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_, \
+ (unsigned long)_n_, sizeof(*(ptr))); \
+ })
+
+#elif __i386__
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
@@ -167,4 +253,5 @@
((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o), \
(unsigned long)(n),sizeof(*(ptr
+#endif /* i386 & alpha */
#endif
@@ -316,4 +403,5 @@
int high_mark; /* High water mark */
atomic_t wfh; /* If waiting for high mark */
+ spinlock_tlock;
} drm_freelist_t;
@@ -344,4 +432,5 @@
struct drm_file *prev;
struct drm_device *dev;
+
RE: Re: 2.2.18pre21 - IP kernel level autoconfiguration
The problem seems to be deeper than that. I first encountered the problem with only bootp compiled in. In my configuration I am not able to supply kernel parameters on the client which may be why you were able to get bootp to execute. Chip > It seem somewhere between 2.2.17 and the current 2.2.18 kernel, IP > kernel level autoconfiguration has been broken. Upon kernel loading > the Ethernet card is detected and loaded properly, but the bootp code > never seems to be executed and mounting the root partion via NFS then > fails from lack of IP configuration. > I haven't had any luck tracing down the root of this problem. > Anyone else experience this problem or have a patch to fix it? Hi! I've the same behavior here: server kernel : 2.2.17 dhcpd : 2.0b1pl29 client kernel : 2.2.18-21 client cmdline: root=/dev/nfs nfsroot=/foo/bar ip=bootp After some quick tests seem that if you want bootp you _need_ to compile the client's kernel with _only_ bootp, if you have also dhcp, it doesn't work :( Dhcp into kernel is COOL and I hope that someone is porting on 2.4 ;), doesn't seem that hard hope this help, luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Re: 2.2.18pre21 - IP kernel level autoconfiguration
The problem seems to be deeper than that. I first encountered the problem with only bootp compiled in. In my configuration I am not able to supply kernel parameters on the client which may be why you were able to get bootp to execute. Chip It seem somewhere between 2.2.17 and the current 2.2.18 kernel, IP kernel level autoconfiguration has been broken. Upon kernel loading the Ethernet card is detected and loaded properly, but the bootp code never seems to be executed and mounting the root partion via NFS then fails from lack of IP configuration. I haven't had any luck tracing down the root of this problem. Anyone else experience this problem or have a patch to fix it? Hi! I've the same behavior here: server kernel : 2.2.17 dhcpd : 2.0b1pl29 client kernel : 2.2.18-21 client cmdline: root=/dev/nfs nfsroot=/foo/bar ip=bootp After some quick tests seem that if you want bootp you _need_ to compile the client's kernel with _only_ bootp, if you have also dhcp, it doesn't work :( Dhcp into kernel is COOL and I hope that someone is porting on 2.4 ;), doesn't seem that hard hope this help, luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre21: DRM update
This is an update from the main DRM tree, but with cosmetic changes
removed and only meat left. This patch is already in VA's shipping
kernel, so you know we really trust it. :-,
BTW, this patch is not fluff: It includes bug fixes. But it's pretty
big, so if you want to wait until 2.2.19 I'll understand
Index: drivers/char/Makefile
--- drivers/char/Makefile.prev
+++ drivers/char/Makefile Fri Nov 17 13:30:04 2000
@@ -12,5 +12,5 @@
SUB_DIRS :=
MOD_SUB_DIRS := $(SUB_DIRS)
-ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick drm agp
+ALL_SUB_DIRS := $(SUB_DIRS) rio ftape joystick
#
@@ -395,4 +395,16 @@
endif
+ifeq ($(CONFIG_DRM),y)
+O_OBJS += drm/drm.o
+ALL_SUB_DIRS += drm
+MOD_SUB_DIRS += drm
+SUB_DIRS += drm
+else
+ ifeq ($(CONFIG_DRM),m)
+ ALL_SUB_DIRS += drm
+ MOD_SUB_DIRS += drm
+ endif
+endif
+
ifeq ($(CONFIG_INTEL_RNG),y)
O_OBJS += i810_rng.o
@@ -650,16 +662,4 @@
OX_OBJS += h8.o
endif
-
-
-ifeq ($(CONFIG_DRM),y)
-SUB_DIRS += drm
-O_OBJS += drm/drm.o
-MOD_SUB_DIRS += drm
-else
- ifeq ($(CONFIG_DRM),m)
- MOD_SUB_DIRS += drm
- endif
-endif
-
ifeq ($(L_I2C),y)
Index: drivers/char/drm/drmP.h
--- drivers/char/drm/drmP.h.prev
+++ drivers/char/drm/drmP.h Fri Nov 17 13:30:04 2000
@@ -34,4 +34,9 @@
#ifdef __KERNEL__
+#ifdef __alpha__
+/* add include of current.h so that "current" is defined
+ * before static inline funcs in wait.h. 4/21/2000 S + B */
+#include asm/current.h
+#endif /* __alpha__ */
#include linux/config.h
#include linux/module.h
@@ -47,8 +52,11 @@
#include linux/sched.h
#include linux/smp_lock.h/* For (un)lock_kernel */
+#include linux/mm.h
+#ifdef __alpha__
+#include asm/pgtable.h /* For pte_wrprotect */
+#endif
#include asm/io.h
#include asm/mman.h
#include asm/uaccess.h
-#include asm/pgtable.h
#ifdef CONFIG_MTRR
#include asm/mtrr.h
@@ -133,8 +141,86 @@
#endif
+ /* module_init/module_exit added in 2.3.13 */
+#ifndef module_init
+#define module_init(x) int init_module(void) { return x(); }
+#endif
+#ifndef module_exit
+#define module_exit(x) void cleanup_module(void) { x(); }
+#endif
+
+ /* virt_to_page added in 2.4.0-test6 */
+#if LINUX_VERSION_CODE 0x020400
+#define virt_to_page(kaddr) (mem_map + MAP_NR(kaddr))
+#endif
+
/* Generic cmpxchg added in 2.3.x */
#ifndef __HAVE_ARCH_CMPXCHG
/* Include this here so that driver can be
used with older kernels. */
+#if defined(__alpha__)
+static __inline__ unsigned long
+__cmpxchg_u32(volatile int *m, int old, int new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldl_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stl_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "=r"(prev), "=r"(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg_u64(volatile long *m, unsigned long old, unsigned long new)
+{
+ unsigned long prev, cmp;
+
+ __asm__ __volatile__(
+ "1: ldq_l %0,%2\n"
+ " cmpeq %0,%3,%1\n"
+ " beq %1,2f\n"
+ " mov %4,%1\n"
+ " stq_c %1,%2\n"
+ " beq %1,3f\n"
+ "2: mb\n"
+ ".subsection 2\n"
+ "3: br 1b\n"
+ ".previous"
+ : "=r"(prev), "=r"(cmp), "=m"(*m)
+ : "r"((long) old), "r"(new), "m"(*m));
+
+ return prev;
+}
+
+static __inline__ unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
+{
+ switch (size) {
+ case 4:
+ return __cmpxchg_u32(ptr, old, new);
+ case 8:
+ return __cmpxchg_u64(ptr, old, new);
+ }
+ return old;
+}
+#define cmpxchg(ptr,o,n)\
+ ({\
+ __typeof__(*(ptr)) _o_ = (o); \
+ __typeof__(*(ptr)) _n_ = (n); \
+ (__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_, \
+ (unsigned long)_n_, sizeof(*(ptr))); \
+ })
+
+#elif __i386__
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
@@ -167,4 +253,5 @@
((__typeof__(*(ptr)))__cmpxchg((ptr),(unsigned long)(o), \
(unsigned long)(n),sizeof(*(ptr
+#endif /* i386 alpha */
#endif
@@ -316,4 +403,5 @@
int high_mark; /* High water mark */
atomic_t wfh; /* If waiting for high mark
2.2.18pre21 - IP kernel level autoconfiguration
It seem somewhere between 2.2.17 and the current 2.2.18 kernel, IP kernel level autoconfiguration has been broken. Upon kernel loading the Ethernet card is detected and loaded properly, but the bootp code never seems to be executed and mounting the root partion via NFS then fails from lack of IP configuration. I haven't had any luck tracing down the root of this problem. Anyone else experience this problem or have a patch to fix it? Chip Schweiss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre21 - IP kernel level autoconfiguration
It seem somewhere between 2.2.17 and the current 2.2.18 kernel, IP kernel level autoconfiguration has been broken. Upon kernel loading the Ethernet card is detected and loaded properly, but the bootp code never seems to be executed and mounting the root partion via NFS then fails from lack of IP configuration. I haven't had any luck tracing down the root of this problem. Anyone else experience this problem or have a patch to fix it? Chip Schweiss - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre13: Small patches
According to Jeff Garzik: > The correct fix is a much larger patch which changes char2uni's > declaration to include const, and then all the changes that trickle down > from there. I didn't want to presume to change an API like that, even an internal one. But of course Alan can, and I'm quite glad he did. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre13: Small patches
According to Jeff Garzik: The correct fix is a much larger patch which changes char2uni's declaration to include const, and then all the changes that trickle down from there. I didn't want to presume to change an API like that, even an internal one. But of course Alan can, and I'm quite glad he did. -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: eepro100 debug, take 2
This time, it checks for CAP_NET_ADMIN before adjusting the debug
level. (Duh)
Index: linux/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.c2000/09/06 19:54:42 1.4
+++ linux/drivers/net/eepro100.c2000/10/02 22:44:12 1.4.8.2
@@ -1,4 +1,2 @@
-#define USE_IO
-
/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
/*
@@ -40,4 +38,9 @@
*/
+/*
+ * This might fix initialization problems. --Dragan
+ */
+#define USE_IO 1
+
static const char *version =
"eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
@@ -1148,6 +1151,4 @@ static void speedo_show_state(struct net
{
struct speedo_private *sp = (struct speedo_private *)dev->priv;
- long ioaddr = dev->base_addr;
- int phy_num = sp->phy[0] & 0x1f;
int i;
@@ -1176,4 +1177,8 @@ static void speedo_show_state(struct net
#if 0
+ {
+ long ioaddr = dev->base_addr;
+ int phy_num = sp->phy[0] & 0x1f;
+
for (i = 0; i < 16; i++) {
/* FIXME: what does it mean? --SAW */
@@ -1182,4 +1187,5 @@ static void speedo_show_state(struct net
dev->name, phy_num, i, mdio_read(ioaddr, phy_num, i));
}
+ }
#endif
@@ -1509,5 +1515,5 @@ static void speedo_interrupt(int irq, vo
outw(status & 0xfc00, ioaddr + SCBStatus);
- if (speedo_debug > 4)
+ if (speedo_debug > 3)
printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n",
dev->name, status);
@@ -1932,4 +1938,11 @@ static int speedo_ioctl(struct net_devic
end_bh_atomic();
return 0;
+ case SIOCDEVPRIVATE+5: /* Set speedo debug level */
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+ speedo_debug = *(int *)rq->ifr_data;
+ printk(KERN_DEBUG "%s: set debug level to [%d].\n",
+ dev->name, speedo_debug);
+ return 0;
default:
return -EOPNOTSUPP;
@@ -1971,4 +1984,8 @@ static void set_rx_mode(struct net_devic
* set again later. */
sp->rx_mode = -1;
+ if(speedo_debug < 2)
+ printk(KERN_DEBUG "%s: The Tx ring is full -- don't add
+anything!\n"
+ "sp->cur_tx[%d], sp->dirty_tx[%d], TX_RING_SIZE[%d],
+TX_MULTICAST_SIZE[%d]\n",
+ dev->name, sp->cur_tx, sp->dirty_tx, TX_RING_SIZE,
+TX_MULTICAST_SIZE);
return;
}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18pre13: eepro100 debug tweaks
According to Alan Cox: > > + case SIOCDEVPRIVATE+5: > > + speedo_debug = *(int *)rq->ifr_data; > > + printk(KERN_DEBUG "%s: set debug level to [%d].\n", > > + dev->name, speedo_debug); > > + return 0; > > Surely that should check for root ? Now see, this is why peer review is a Good Thing. :-/ Yes, of course it should check for root. (I'm dunce-for-a-day for not seeing that immediately.) -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: Small patches from Andrea
I suppose I should let Andrea submit these, but he has such a huge
patch collection (thank you!) that I thought it might be useful to
pick out some of the smaller ones that would be less controversial
for inclusion in the main kernel.
* nanosleep-4
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
* tsc-calibration-non-compile-time-1
TSC calibration must be dynamic and not a compile time thing because
gettimeofday is dynamic and it depends on the TSCs to be in sync.
* IO-wait-2
Avoid spurious unplug of the I/O queue.
* buf-run_task_queue
Avoid spurious unplug of the I/O queue. (again!)
* account-failed-buffer-tries-1
Account also for failed buffer tries during shrink_mmap.
* overcommit-1
Make sure to not understimate the available memory (the cache and
buffers may be under the min percent).
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Tag: KERNEL-2-2-18-PRE11-PATCH-6
Patch: nanosleep-4
From: Andrea Arcangeli <[EMAIL PROTECTED]>
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
Index: linux/arch/alpha/kernel/time.c
diff -u linux/arch/alpha/kernel/time.c:1.2 linux/arch/alpha/kernel/time.c:1.2.6.1
--- linux/arch/alpha/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/alpha/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -339,8 +339,22 @@
irq_handler = timer_interrupt;
if (request_irq(TIMER_IRQ, irq_handler, 0, "timer", NULL))
panic("Could not allocate timer IRQ!");
+ do_get_fast_time = do_gettimeofday;
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* Use the cycle counter to estimate an displacement from the last time
* tick. Unfortunately the Alpha designers made only the low 32-bits of
@@ -389,13 +403,11 @@
#endif
usec += delta_usec;
- if (usec >= 100) {
- sec += 1;
- usec -= 100;
- }
tv->tv_sec = sec;
tv->tv_usec = usec;
+
+ timeval_normalize(tv);
}
void
Index: linux/arch/i386/kernel/time.c
diff -u linux/arch/i386/kernel/time.c:1.2 linux/arch/i386/kernel/time.c:1.2.6.1
--- linux/arch/i386/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/i386/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -239,6 +239,20 @@
#endif
+/* FIXME: should be inline but gcc is buggy and breaks */
+static void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution
* and better than microsecond precision on fast x86 machines with TSC.
@@ -259,13 +273,10 @@
usec += xtime.tv_usec;
read_unlock_irqrestore(_lock, flags);
- while (usec >= 100) {
- usec -= 100;
- sec++;
- }
-
tv->tv_sec = sec;
tv->tv_usec = usec;
+
+ timeval_normalize(tv);
}
void do_settimeofday(struct timeval *tv)
Index: linux/arch/ppc/kernel/time.c
diff -u linux/arch/ppc/kernel/time.c:1.2 linux/arch/ppc/kernel/time.c:1.2.14.1
--- linux/arch/ppc/kernel/time.c:1.2Thu Jul 6 22:41:19 2000
+++ linux/arch/ppc/kernel/time.cWed Sep 27 23:55:48 2000
@@ -147,6 +147,19 @@
hardirq_exit(cpu);
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv->tv_usec / 100;
+ if (__sec)
+ {
+ tv->tv_usec %= 100;
+ tv->tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution.
*/
@@ -161,10 +174,7 @@
#ifndef __SMP__
tv->tv_usec += (decrementer_count - get_dec())
* count_period_num / count_period_den;
- if (tv->tv_usec >= 100) {
- tv->tv_usec -= 100;
- tv->tv_sec++;
- }
+ timeval_normalize(tv);
#endif
restore_flags(flags);
}
Index: linux/include/linux/time.h
diff -u linux/include/linux/time.h:1.1 linux/include/li
[PATCH] 2.2.18pre13: eepro100 debug tweaks
Patch: eepro100-speedo-debug-1
From: Dragan Stancevic <[EMAIL PROTECTED]>
Debugging tweaks for eepro100 driver:
* Add ioctl to adjust speedo_debug.
* Print diagnostic when Tx ring fills up.
* Adjust debugging level of interrupt diagnostics.
* Eliminate compilation warning.
Index: linux/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.c:1.4Wed Sep 6 12:54:42 2000
+++ linux/drivers/net/eepro100.cThu Sep 28 01:07:37 2000
@@ -1,5 +1,3 @@
-#define USE_IO
-
/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
/*
NOTICE: this version of the driver is supposed to work with 2.2 kernels.
@@ -39,6 +37,11 @@
Honor PortReset timing specification.
*/
+/*
+ * This might fix initialization problems. --Dragan
+ */
+#define USE_IO 1
+
static const char *version =
"eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
"eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin
<[EMAIL PROTECTED]> and others\n";
@@ -1147,8 +1150,6 @@
static void speedo_show_state(struct net_device *dev)
{
struct speedo_private *sp = (struct speedo_private *)dev->priv;
- long ioaddr = dev->base_addr;
- int phy_num = sp->phy[0] & 0x1f;
int i;
/* Print a few items for debugging. */
@@ -1175,12 +1176,17 @@
(unsigned)sp->rx_ringp[i]->status : 0);
#if 0
+ {
+ long ioaddr = dev->base_addr;
+ int phy_num = sp->phy[0] & 0x1f;
+
for (i = 0; i < 16; i++) {
/* FIXME: what does it mean? --SAW */
if (i == 6) i = 21;
printk(KERN_DEBUG "%s: PHY index %d register %d is %4.4x.\n",
dev->name, phy_num, i, mdio_read(ioaddr, phy_num, i));
}
+ }
#endif
}
@@ -1508,7 +1514,7 @@
FCP and ER interrupts --Dragan */
outw(status & 0xfc00, ioaddr + SCBStatus);
- if (speedo_debug > 4)
+ if (speedo_debug > 3)
printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n",
dev->name, status);
@@ -1931,6 +1937,11 @@
mdio_write(ioaddr, data[0], data[1], data[2]);
end_bh_atomic();
return 0;
+ case SIOCDEVPRIVATE+5:
+ speedo_debug = *(int *)rq->ifr_data;
+ printk(KERN_DEBUG "%s: set debug level to [%d].\n",
+ dev->name, speedo_debug);
+ return 0;
default:
return -EOPNOTSUPP;
}
@@ -1970,6 +1981,10 @@
/* The Tx ring is full -- don't add anything! Hope the mode will be
* set again later. */
sp->rx_mode = -1;
+ if(speedo_debug < 2)
+ printk(KERN_DEBUG "%s: The Tx ring is full -- don't add
+anything!\n"
+ "sp->cur_tx[%d], sp->dirty_tx[%d], TX_RING_SIZE[%d],
+TX_MULTICAST_SIZE[%d]\n",
+ dev->name, sp->cur_tx, sp->dirty_tx, TX_RING_SIZE,
+TX_MULTICAST_SIZE);
return;
}
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre13: Small patches
Here's a brace of small patches that ought to be OK for 2.2.18.
adTHANKSvance for consideration
1. Fix fencepost error in ioremap's page reservation logic.
(I think the broken logic was added to support AGP.)
Index: linux/arch/i386/mm/ioremap.c
--- linux/arch/i386/mm/ioremap.c:1.2Fri Sep 1 19:03:09 2000
+++ linux/arch/i386/mm/ioremap.cThu Sep 28 00:34:40 2000
@@ -117,7 +117,7 @@
temp_addr = __va(phys_addr);
temp_end = temp_addr + (size - 1);
- for(i = MAP_NR(temp_addr); i < MAP_NR(temp_end); i++) {
+ for(i = MAP_NR(temp_addr); i <= MAP_NR(temp_end); i++) {
if(!PageReserved(mem_map + i))
return NULL;
}
2. Fix linear RAID to work even with blocks smaller than 1K.
(From Anton Altparmakov <[EMAIL PROTECTED]>)
In linux/drivers/block/linear.c:linear_map(), change:
*rsector=(block-(tmp_dev->offset)) << 1;
to:
*rsector=((block - tmp_dev->offset) << 1) + (*rsector & 1);
3. Trivial patch to fs/vfat/namei.c to avoid a compile-time warning.
Index: linux/fs/vfat/namei.c
--- linux/fs/vfat/namei.c:1.2 Fri Sep 1 19:03:16 2000
+++ linux/fs/vfat/namei.c Thu Sep 28 00:53:55 2000
@@ -676,7 +676,8 @@
i += 4;
} else {
int llen;
- nls->char2uni(ip, , op, op+1);
+ nls->char2uni((unsigned char *)ip,
+ , op, op+1);
op += 2;
ip += llen;
i += llen;
4. Config option controlling default behavior of kernels that enable
boot-time IP-Config.
* If CONFIG_IP_PNP_AUTO is set, the default is to do IP-Config at
boot time. Disable it with "ip=off".
* If CONFIG_IP_PNP_AUTO is not set, the default is *not* to do
IP-Config at boot time. Override with "ip=on", "ip=dhcp", etc.
Index: linux/net/ipv4/Config.in
diff -u linux/net/ipv4/Config.in:1.2 linux/net/ipv4/Config.in:1.2.8.1
--- linux/net/ipv4/Config.in:1.2Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/Config.inThu Sep 28 00:42:00 2000
@@ -22,6 +22,9 @@
bool ' RARP support' CONFIG_IP_PNP_RARP
# not yet ready..
# bool ' ARP support' CONFIG_IP_PNP_ARP
+ if [ "$CONFIG_IP_PNP_DHCP" = "y" -o "$CONFIG_IP_PNP_BOOTP" = "y" -o
+"$CONFIG_IP_PNP_RARP" = "y" ]; then
+bool ' Auto DHCP/BOOTP/RARP at boot' CONFIG_IP_PNP_AUTO
+ fi
fi
if [ "$CONFIG_FIREWALL" = "y" ]; then
bool 'IP: firewalling' CONFIG_IP_FIREWALL
Index: linux/net/ipv4/ipconfig.c
diff -u linux/net/ipv4/ipconfig.c:1.2 linux/net/ipv4/ipconfig.c:1.2.8.1
--- linux/net/ipv4/ipconfig.c:1.2 Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/ipconfig.c Thu Sep 28 00:42:00 2000
@@ -87,7 +87,13 @@
* Public IP configuration
*/
-int ic_enable __initdata = 0; /* IP config enabled? */
+int ic_enable __initdata = /* IP config enabled? */
+#ifdef CONFIG_IP_PNP_AUTO
+ 1
+#else
+ 0
+#endif
+;
/* Protocol choice */
static int ic_proto_enabled __initdata = 0
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: USB tweak for VAIO
Patch: usbdock-1
From: Geoff Harrison <[EMAIL PROTECTED]>
Allow short report frames via USB ... apparently they are normal for
some Sony VAIOs when docked.
Index: linux/drivers/usb/hid.c
diff -u linux/drivers/usb/hid.c:1.2 linux/drivers/usb/hid.c:1.2.2.1
--- linux/drivers/usb/hid.c:1.2 Wed Sep 27 23:44:24 2000
+++ linux/drivers/usb/hid.c Thu Sep 28 11:51:32 2000
@@ -1096,10 +1096,12 @@
return;
}
+#if 0
if (len < ((report->size - 1) >> 3) + 1) {
dbg("report %d is too short, (%d < %d)", report->id, len,
((report->size - 1) >> 3) + 1);
return;
}
+#endif
for (n = 0; n < report->maxfield; n++)
hid_input_field(device, report->field[n], data);
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre13: Small patches
Here's a brace of small patches that ought to be OK for 2.2.18.
adTHANKSvance for consideration
1. Fix fencepost error in ioremap's page reservation logic.
(I think the broken logic was added to support AGP.)
Index: linux/arch/i386/mm/ioremap.c
--- linux/arch/i386/mm/ioremap.c:1.2Fri Sep 1 19:03:09 2000
+++ linux/arch/i386/mm/ioremap.cThu Sep 28 00:34:40 2000
@@ -117,7 +117,7 @@
temp_addr = __va(phys_addr);
temp_end = temp_addr + (size - 1);
- for(i = MAP_NR(temp_addr); i MAP_NR(temp_end); i++) {
+ for(i = MAP_NR(temp_addr); i = MAP_NR(temp_end); i++) {
if(!PageReserved(mem_map + i))
return NULL;
}
2. Fix linear RAID to work even with blocks smaller than 1K.
(From Anton Altparmakov [EMAIL PROTECTED])
In linux/drivers/block/linear.c:linear_map(), change:
*rsector=(block-(tmp_dev-offset)) 1;
to:
*rsector=((block - tmp_dev-offset) 1) + (*rsector 1);
3. Trivial patch to fs/vfat/namei.c to avoid a compile-time warning.
Index: linux/fs/vfat/namei.c
--- linux/fs/vfat/namei.c:1.2 Fri Sep 1 19:03:16 2000
+++ linux/fs/vfat/namei.c Thu Sep 28 00:53:55 2000
@@ -676,7 +676,8 @@
i += 4;
} else {
int llen;
- nls-char2uni(ip, llen, op, op+1);
+ nls-char2uni((unsigned char *)ip,
+ llen, op, op+1);
op += 2;
ip += llen;
i += llen;
4. Config option controlling default behavior of kernels that enable
boot-time IP-Config.
* If CONFIG_IP_PNP_AUTO is set, the default is to do IP-Config at
boot time. Disable it with "ip=off".
* If CONFIG_IP_PNP_AUTO is not set, the default is *not* to do
IP-Config at boot time. Override with "ip=on", "ip=dhcp", etc.
Index: linux/net/ipv4/Config.in
diff -u linux/net/ipv4/Config.in:1.2 linux/net/ipv4/Config.in:1.2.8.1
--- linux/net/ipv4/Config.in:1.2Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/Config.inThu Sep 28 00:42:00 2000
@@ -22,6 +22,9 @@
bool ' RARP support' CONFIG_IP_PNP_RARP
# not yet ready..
# bool ' ARP support' CONFIG_IP_PNP_ARP
+ if [ "$CONFIG_IP_PNP_DHCP" = "y" -o "$CONFIG_IP_PNP_BOOTP" = "y" -o
+"$CONFIG_IP_PNP_RARP" = "y" ]; then
+bool ' Auto DHCP/BOOTP/RARP at boot' CONFIG_IP_PNP_AUTO
+ fi
fi
if [ "$CONFIG_FIREWALL" = "y" ]; then
bool 'IP: firewalling' CONFIG_IP_FIREWALL
Index: linux/net/ipv4/ipconfig.c
diff -u linux/net/ipv4/ipconfig.c:1.2 linux/net/ipv4/ipconfig.c:1.2.8.1
--- linux/net/ipv4/ipconfig.c:1.2 Wed Sep 6 12:54:43 2000
+++ linux/net/ipv4/ipconfig.c Thu Sep 28 00:42:00 2000
@@ -87,7 +87,13 @@
* Public IP configuration
*/
-int ic_enable __initdata = 0; /* IP config enabled? */
+int ic_enable __initdata = /* IP config enabled? */
+#ifdef CONFIG_IP_PNP_AUTO
+ 1
+#else
+ 0
+#endif
+;
/* Protocol choice */
static int ic_proto_enabled __initdata = 0
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: USB tweak for VAIO
Patch: usbdock-1
From: Geoff Harrison [EMAIL PROTECTED]
Allow short report frames via USB ... apparently they are normal for
some Sony VAIOs when docked.
Index: linux/drivers/usb/hid.c
diff -u linux/drivers/usb/hid.c:1.2 linux/drivers/usb/hid.c:1.2.2.1
--- linux/drivers/usb/hid.c:1.2 Wed Sep 27 23:44:24 2000
+++ linux/drivers/usb/hid.c Thu Sep 28 11:51:32 2000
@@ -1096,10 +1096,12 @@
return;
}
+#if 0
if (len ((report-size - 1) 3) + 1) {
dbg("report %d is too short, (%d %d)", report-id, len,
((report-size - 1) 3) + 1);
return;
}
+#endif
for (n = 0; n report-maxfield; n++)
hid_input_field(device, report-field[n], data);
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: eepro100 debug tweaks
Patch: eepro100-speedo-debug-1
From: Dragan Stancevic [EMAIL PROTECTED]
Debugging tweaks for eepro100 driver:
* Add ioctl to adjust speedo_debug.
* Print diagnostic when Tx ring fills up.
* Adjust debugging level of interrupt diagnostics.
* Eliminate compilation warning.
Index: linux/drivers/net/eepro100.c
--- linux/drivers/net/eepro100.c:1.4Wed Sep 6 12:54:42 2000
+++ linux/drivers/net/eepro100.cThu Sep 28 01:07:37 2000
@@ -1,5 +1,3 @@
-#define USE_IO
-
/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
/*
NOTICE: this version of the driver is supposed to work with 2.2 kernels.
@@ -39,6 +37,11 @@
Honor PortReset timing specification.
*/
+/*
+ * This might fix initialization problems. --Dragan
+ */
+#define USE_IO 1
+
static const char *version =
"eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html\n"
"eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin
[EMAIL PROTECTED] and others\n";
@@ -1147,8 +1150,6 @@
static void speedo_show_state(struct net_device *dev)
{
struct speedo_private *sp = (struct speedo_private *)dev-priv;
- long ioaddr = dev-base_addr;
- int phy_num = sp-phy[0] 0x1f;
int i;
/* Print a few items for debugging. */
@@ -1175,12 +1176,17 @@
(unsigned)sp-rx_ringp[i]-status : 0);
#if 0
+ {
+ long ioaddr = dev-base_addr;
+ int phy_num = sp-phy[0] 0x1f;
+
for (i = 0; i 16; i++) {
/* FIXME: what does it mean? --SAW */
if (i == 6) i = 21;
printk(KERN_DEBUG "%s: PHY index %d register %d is %4.4x.\n",
dev-name, phy_num, i, mdio_read(ioaddr, phy_num, i));
}
+ }
#endif
}
@@ -1508,7 +1514,7 @@
FCP and ER interrupts --Dragan */
outw(status 0xfc00, ioaddr + SCBStatus);
- if (speedo_debug 4)
+ if (speedo_debug 3)
printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n",
dev-name, status);
@@ -1931,6 +1937,11 @@
mdio_write(ioaddr, data[0], data[1], data[2]);
end_bh_atomic();
return 0;
+ case SIOCDEVPRIVATE+5:
+ speedo_debug = *(int *)rq-ifr_data;
+ printk(KERN_DEBUG "%s: set debug level to [%d].\n",
+ dev-name, speedo_debug);
+ return 0;
default:
return -EOPNOTSUPP;
}
@@ -1970,6 +1981,10 @@
/* The Tx ring is full -- don't add anything! Hope the mode will be
* set again later. */
sp-rx_mode = -1;
+ if(speedo_debug 2)
+ printk(KERN_DEBUG "%s: The Tx ring is full -- don't add
+anything!\n"
+ "sp-cur_tx[%d], sp-dirty_tx[%d], TX_RING_SIZE[%d],
+TX_MULTICAST_SIZE[%d]\n",
+ dev-name, sp-cur_tx, sp-dirty_tx, TX_RING_SIZE,
+TX_MULTICAST_SIZE);
return;
}
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.18pre13: Small patches from Andrea
I suppose I should let Andrea submit these, but he has such a huge
patch collection (thank you!) that I thought it might be useful to
pick out some of the smaller ones that would be less controversial
for inclusion in the main kernel.
* nanosleep-4
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
* tsc-calibration-non-compile-time-1
TSC calibration must be dynamic and not a compile time thing because
gettimeofday is dynamic and it depends on the TSCs to be in sync.
* IO-wait-2
Avoid spurious unplug of the I/O queue.
* buf-run_task_queue
Avoid spurious unplug of the I/O queue. (again!)
* account-failed-buffer-tries-1
Account also for failed buffer tries during shrink_mmap.
* overcommit-1
Make sure to not understimate the available memory (the cache and
buffers may be under the min percent).
--
Chip Salzenberg - a.k.a. - [EMAIL PROTECTED]
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Tag: KERNEL-2-2-18-PRE11-PATCH-6
Patch: nanosleep-4
From: Andrea Arcangeli [EMAIL PROTECTED]
Provide nanosleep usec resolution so that a signal flood doesn't hang
glibc folks that correctly trust the rem field to resume the nanosleep
after a syscall interruption. (without the patch nanosleep resolution
is instead 10msec on IA32 and around 1msec on alpha)
Index: linux/arch/alpha/kernel/time.c
diff -u linux/arch/alpha/kernel/time.c:1.2 linux/arch/alpha/kernel/time.c:1.2.6.1
--- linux/arch/alpha/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/alpha/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -339,8 +339,22 @@
irq_handler = timer_interrupt;
if (request_irq(TIMER_IRQ, irq_handler, 0, "timer", NULL))
panic("Could not allocate timer IRQ!");
+ do_get_fast_time = do_gettimeofday;
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv-tv_usec / 100;
+ if (__sec)
+ {
+ tv-tv_usec %= 100;
+ tv-tv_sec += __sec;
+ }
+}
+
/*
* Use the cycle counter to estimate an displacement from the last time
* tick. Unfortunately the Alpha designers made only the low 32-bits of
@@ -389,13 +403,11 @@
#endif
usec += delta_usec;
- if (usec = 100) {
- sec += 1;
- usec -= 100;
- }
tv-tv_sec = sec;
tv-tv_usec = usec;
+
+ timeval_normalize(tv);
}
void
Index: linux/arch/i386/kernel/time.c
diff -u linux/arch/i386/kernel/time.c:1.2 linux/arch/i386/kernel/time.c:1.2.6.1
--- linux/arch/i386/kernel/time.c:1.2 Wed Sep 13 08:32:22 2000
+++ linux/arch/i386/kernel/time.c Wed Sep 27 23:55:48 2000
@@ -239,6 +239,20 @@
#endif
+/* FIXME: should be inline but gcc is buggy and breaks */
+static void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv-tv_usec / 100;
+ if (__sec)
+ {
+ tv-tv_usec %= 100;
+ tv-tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution
* and better than microsecond precision on fast x86 machines with TSC.
@@ -259,13 +273,10 @@
usec += xtime.tv_usec;
read_unlock_irqrestore(xtime_lock, flags);
- while (usec = 100) {
- usec -= 100;
- sec++;
- }
-
tv-tv_sec = sec;
tv-tv_usec = usec;
+
+ timeval_normalize(tv);
}
void do_settimeofday(struct timeval *tv)
Index: linux/arch/ppc/kernel/time.c
diff -u linux/arch/ppc/kernel/time.c:1.2 linux/arch/ppc/kernel/time.c:1.2.14.1
--- linux/arch/ppc/kernel/time.c:1.2Thu Jul 6 22:41:19 2000
+++ linux/arch/ppc/kernel/time.cWed Sep 27 23:55:48 2000
@@ -147,6 +147,19 @@
hardirq_exit(cpu);
}
+static inline void
+timeval_normalize(struct timeval * tv)
+{
+ time_t __sec;
+
+ __sec = tv-tv_usec / 100;
+ if (__sec)
+ {
+ tv-tv_usec %= 100;
+ tv-tv_sec += __sec;
+ }
+}
+
/*
* This version of gettimeofday has microsecond resolution.
*/
@@ -161,10 +174,7 @@
#ifndef __SMP__
tv-tv_usec += (decrementer_count - get_dec())
* count_period_num / count_period_den;
- if (tv-tv_usec = 100) {
- tv-tv_usec -= 100;
- tv-tv_sec++;
- }
+ timeval_normalize(tv);
#endif
restore_flags(flags);
}
Index: linux/include/linux/time.h
diff -u linux/include/linux/time.h:1.1 linux/include/linux/time.h:1.1.14.1
--- linux/include/linux/time.h:1.1 Thu Jul 6 22:04:59 2000
+++ l
Re: [PATCH] 2.2.18pre13: eepro100 debug tweaks
According to Alan Cox: + case SIOCDEVPRIVATE+5: + speedo_debug = *(int *)rq-ifr_data; + printk(KERN_DEBUG "%s: set debug level to [%d].\n", + dev-name, speedo_debug); + return 0; Surely that should check for root ? Now see, this is why peer review is a Good Thing. :-/ Yes, of course it should check for root. (I'm dunce-for-a-day for not seeing that immediately.) -- Chip Salzenberg - a.k.a. - [EMAIL PROTECTED] "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
