* Re: Adventure - the answer to what went wrong?
From: Dan Olson @ 2002-12-12 20:41 UTC (permalink / raw)
To: Linux 8086
In-Reply-To: <1039724964.1821.28.camel@cool>
> > Also, the file size is 84k, but that doesn't mean that the code segment is
> > going to be more than 64k, does it? Does the whole file get loaded into
> > memory and executed, or can there be other "stuff" in that file besides
> > executable code that may not get loaded into the code segment? I haven't
> > messed with this stuff in a while, so I don't remember :)
> >
> > Dan
>
> It is ok for a file to be bigger than 64K since initialized data exist
> in the file along with the code.
>
> Harry
That's what I was thinking, just haven't done any x86 asm for a while.
Dan
^ permalink raw reply
* Re: [PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER
From: Jens Axboe @ 2002-12-12 20:40 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: James Bottomley, dougg, linux-scsi
In-Reply-To: <20021212203903.A8484@infradead.org>
On Thu, Dec 12 2002, Christoph Hellwig wrote:
> On Thu, Dec 12, 2002 at 06:42:41PM +0100, Jens Axboe wrote:
> > Hmm, I _may_ be wrong but I think the main reason for GET_IDLUN and
> > GET_BUS_NUMBER in the generic block layer is to stop them from failing
> > in libscg and thus fooling it into believing we are scsi. You would need
> > to check libscg/scsi-linux-sg.c to be sure.
> >
> > For one thing, we need to maintain the behaviour we have now of _not_
> > failing them for ata devices. If you want to pass them down to SCSI as
> > well and get the right id/lun and bus, fine, but don't break the ata
> > one.
>
> I disagree. USerspace needs changes to support SG_IO on block device anyway
> so we should do it properly. There is no harm in changing interface during
How do you figure? Some of them probably, but most should just work
(provided they use SG_IO ioctl, of course).
> 2.5. IMHO most of the silly sg ioctl stubs in drivers/block/scsi_ioctl.c
> should just die.
Feel free, I don't have time to do it right now.
--
Jens Axboe
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Christoph Hellwig @ 2002-12-12 20:39 UTC (permalink / raw)
To: Justin T. Gibbs, James Bottomley, linux-scsi
In-Reply-To: <20021212202052.GC8842@redhat.com>
On Thu, Dec 12, 2002 at 03:20:52PM -0500, Doug Ledford wrote:
> > you could fix that? A PCI driver is not supposed to stop over already
> > claimed device.
>
> If you've got a test machine, the attached patch would I think fix the
> problem. Let me know if it does in fact work for you and I'll commit it
> to the tree.
I'll test it as soon as I recovered from the company christmas party today..
^ permalink raw reply
* Re: [PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER
From: Christoph Hellwig @ 2002-12-12 20:39 UTC (permalink / raw)
To: Jens Axboe; +Cc: James Bottomley, dougg, linux-scsi
In-Reply-To: <20021212174241.GB6481@suse.de>
On Thu, Dec 12, 2002 at 06:42:41PM +0100, Jens Axboe wrote:
> Hmm, I _may_ be wrong but I think the main reason for GET_IDLUN and
> GET_BUS_NUMBER in the generic block layer is to stop them from failing
> in libscg and thus fooling it into believing we are scsi. You would need
> to check libscg/scsi-linux-sg.c to be sure.
>
> For one thing, we need to maintain the behaviour we have now of _not_
> failing them for ata devices. If you want to pass them down to SCSI as
> well and get the right id/lun and bus, fine, but don't break the ata
> one.
I disagree. USerspace needs changes to support SG_IO on block device anyway
so we should do it properly. There is no harm in changing interface during
2.5. IMHO most of the silly sg ioctl stubs in drivers/block/scsi_ioctl.c
should just die.
^ permalink raw reply
* Re: Is the preemptive kernel patch unsafe for 8xx/PPC?
From: Joakim Tjernlund @ 2002-12-12 20:35 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev
In-Reply-To: <5.1.0.14.2.20021212102609.02d48730@pop.prodigy.net>
Was that the 2.4.19-2 patch? What were the bugs and have you fixed them?
According to the message Robert posted on lkm is the 2.4.20-1 patch only a
rediff of the latest 2.4.19 patch.
BTW, I am on the 2_4_devel branch.
Jocke
> At 04:56 AM 12/12/2002, you wrote:
> >I am testing the latest(2.4.20-1) preemtive kernel patch from Robert Love and
> >I wonder if anybody know if it's unsafe/not working for 8xx or PPC in general?
>
> I haven't tested patch for 2.4.20 but patch for 2.4.19 contained some bugs.
>
>
> Eugene Surovegin <mailto:ebs@innocent.com>
>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: Nivedita Singhvi @ 2002-12-12 20:37 UTC (permalink / raw)
To: stefano.andreani.ap, linux-kernel
> Never say never ;-)
> I need to change it now as a temporary workaround for a problem in the UMTS core \
> network of my company. But I think there could be thousands of situations where a \
> fine tuning of this TCP parameter could be useful.
>
> Any contributes on the problem?
If what you are trying to do is terminate the connection earlier,
than reduce the tcp sysctl variable tcp_retries2. This should be the
maximum number of retransmits TCP will make in established state.
The TCP_RTO_MAX parameter is simply an *upper bound* on the
value of the retransmission timeout, which increases exponentially
from the original timeout value.
thanks,
Nivedita
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: Alan Cox @ 2002-12-12 21:16 UTC (permalink / raw)
To: Andreani Stefano; +Cc: David S. Miller, Linux Kernel Mailing List, linux-net
In-Reply-To: <047ACC5B9A00D741927A4A32E7D01B73D66178@RMEXC01.h3g.it>
On Thu, 2002-12-12 at 20:18, Andreani Stefano wrote:
> Never say never ;-)
> I need to change it now as a temporary workaround for a problem in the UMTS core network of my company. But I think there could be thousands of situations where a fine tuning of this TCP parameter could be useful.
>
The default is too short ?
^ permalink raw reply
* Re: Adventure - the answer to what went wrong?
From: Harry Kalogirou @ 2002-12-12 20:29 UTC (permalink / raw)
To: Dan Olson; +Cc: Linux 8086
In-Reply-To: <20021212122436.C57693-100000@agora.rdrop.com>
> Also, the file size is 84k, but that doesn't mean that the code segment is
> going to be more than 64k, does it? Does the whole file get loaded into
> memory and executed, or can there be other "stuff" in that file besides
> executable code that may not get loaded into the code segment? I haven't
> messed with this stuff in a while, so I don't remember :)
>
> Dan
It is ok for a file to be bigger than 64K since initialized data exist
in the file along with the code.
Harry
^ permalink raw reply
* Re: R: Kernel bug handling TCP_RTO_MAX?
From: David S. Miller @ 2002-12-12 20:32 UTC (permalink / raw)
To: stefano.andreani.ap; +Cc: linux-kernel, linux-net
In-Reply-To: <047ACC5B9A00D741927A4A32E7D01B73D66178@RMEXC01.h3g.it>
From: "Andreani Stefano" <stefano.andreani.ap@h3g.it>
Date: Thu, 12 Dec 2002 21:18:21 +0100
Never say never ;-)
I need to change it now as a temporary workaround for a problem in
the UMTS core network of my company. But I think there could be
thousands of situations where a fine tuning of this TCP parameter
could be useful.
You still aren't giving specific examples and details of
the problem you are seeing.
^ permalink raw reply
* Re: Adventure - the answer to what went wrong?
From: Dan Olson @ 2002-12-12 20:27 UTC (permalink / raw)
To: Linux 8086
In-Reply-To: <1039726339.22174.29.camel@irongate.swansea.linux.org.uk>
Also, the file size is 84k, but that doesn't mean that the code segment is
going to be more than 64k, does it? Does the whole file get loaded into
memory and executed, or can there be other "stuff" in that file besides
executable code that may not get loaded into the code segment? I haven't
messed with this stuff in a while, so I don't remember :)
Dan
On Thu, 12 Dec 2002, Alan Cox wrote:
> On Thu, 2002-12-12 at 19:11, Richard Wallman wrote:
> > I put forward the theory that it fails because the two strings are not
> > in the same 64Kb segment. The reason no-one has found this problem
> > before is that so far all of the binaries have been <64Kb in size.
>
> ELKS only supports a max of 64K code / 64K data per app...
>
>
>
> Alan
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: pci-skeleton duplex check
From: Jeff Garzik @ 2002-12-12 20:32 UTC (permalink / raw)
To: Donald Becker; +Cc: Roger Luethi, netdev, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212120857570.10674-100000@beohost.scyld.com>
Donald Becker wrote:
> [[ I don't know why I bother. The people that now control what goes into
> the kernel would rather put in random patches from other people than
> accept a correct fix from me. ]]
I'm very interested in applying fixes from you! I am publicly begging
you to do so, and even CC'ing lkml on my request.
Please re-post any patches I or Andrew missed.
Jeff
^ permalink raw reply
* Re: atyfb in 2.5.51
From: Pavel Machek @ 2002-12-12 20:23 UTC (permalink / raw)
To: Alan Cox
Cc: David S. Miller, jsimmons, benh, paulus,
Linux Kernel Mailing List, linux-fbdev-devel
In-Reply-To: <1039642510.18467.40.camel@irongate.swansea.linux.org.uk>
Hi!
> On Wed, 2002-12-11 at 20:43, David S. Miller wrote:
> > fbdev is nice, in the specific cases where the device fits the fbdev
> > model, because once you have the kernel bits you have X support :)
>
> fbdev also can't be used in some situations on x86. Deeply fascinating
> things happen on some x86 processors if you execute a loop of code with
> an instruction that crosses two different memory types.
Sounds like cpu bug to me? What cpus are affected?
Could be worked around by pointing debug register at memory boundary?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* [Linux-ia64] Re: [PATCH] fill in si_code for fpu faults
From: Jesse Barnes @ 2002-12-12 20:23 UTC (permalink / raw)
To: linux-ia64
[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]
On Thu, Dec 12, 2002 at 11:14:31AM -0800, David Mosberger wrote:
> Basically OK with me, however:
>
> o What's the point of declaring fp_fault_info in a header file? It's
> used only in one place.
No particular reason. Fixed.
> o si_code is NOT a bitmask; it makes no sense at all for
> fp_fault_si_code() to OR multiple values together; this makes me
> highly suspicious that there is a misunderstanding somewhere...
Yes, there was a misunderstanding, but I think I get it now. Fixed.
> o Who defined FP_SWASST and FPE_DENORM? I don't recall seeing them
> in the ia64 psABI and they definitely look ia64-specific, so their
> names should at least be prefixed by a double-underscore
> (siginfo.h).
Yeah, they're ia64 specific, so I've prefixed them, but I'm not sure if
they're valid from an ABI perspective. Should we just return FPE_FLTINV
for those cases?
> o If you add stuff to asm/siginfo.h, don't forget to update glibc (in
> sysdeps/unix/sysv/linux/ia64/bits/siginfo.h).
Ok.
Hope this is a little better.
Thanks for looking at this,
Jesse
[-- Attachment #2: fpswa-si_code-decode-2.4.19-ia64.patch --]
[-- Type: text/plain, Size: 5727 bytes --]
diff -Naur -X /home/jbarnes/dontdiff linux-2.4.19-ia64/arch/ia64/kernel/traps.c linux-2.4.19-ia64-fpswa/arch/ia64/kernel/traps.c
--- linux-2.4.19-ia64/arch/ia64/kernel/traps.c Thu Dec 12 10:15:57 2002
+++ linux-2.4.19-ia64-fpswa/arch/ia64/kernel/traps.c Thu Dec 12 12:22:24 2002
@@ -45,6 +45,37 @@
static fpswa_interface_t *fpswa_interface;
+/*
+ * fp fault isr.code <-> siginfo.si_code mapping
+ */
+static struct _fp_fault_info {
+ unsigned long isr_code_bit;
+ int si_code; /* SIGFPE si_code */
+} fp_fault_info[] = {
+ { 1<<0, FPE_FLTINV },
+ { 1<<1, __FPE_DENORM },
+ { 1<<2, FPE_FLTDIV },
+ { 1<<3, __FPE_SWASST },
+ { 1<<4, FPE_FLTINV },
+ { 1<<5, __FPE_DENORM },
+ { 1<<6, FPE_FLTDIV },
+ { 1<<7, __FPE_SWASST },
+};
+
+static inline int
+fp_fault_si_code(__u64 isr)
+{
+ int i;
+ int nr_entries;
+ nr_entries = sizeof(fp_fault_info)/sizeof(struct fp_fault_info);
+
+ for (i = 0; i < nr_entries; i++) {
+ if (isr & fp_fault_info[i].isr_code_bit)
+ return fp_fault_info[i].si_code;
+ }
+ return FPE_FLTINV; /* no code found? */
+}
+
void __init
trap_init (void)
{
@@ -336,8 +367,9 @@
fpu_swa_count = 0;
if ((++fpu_swa_count < 5) && !(current->thread.flags & IA64_THREAD_FPEMU_NOPRINT)) {
last_time = jiffies;
- printk(KERN_WARNING "%s(%d): floating-point assist fault at ip %016lx\n",
- current->comm, current->pid, regs->cr_iip + ia64_psr(regs)->ri);
+ printk(KERN_WARNING "%s(%d): floating-point assist %s ",
+ current->comm, current->pid, fp_fault ? "fault:" : "trap");
+ printk("ip=%016lx, isr=%16lx\n", regs->cr_iip + ia64_psr(regs)->ri, isr);
}
exception = fp_emulate(fp_fault, bundle, ®s->cr_ipsr, ®s->ar_fpsr, &isr, ®s->pr,
@@ -556,6 +588,8 @@
siginfo.si_signo = SIGFPE;
siginfo.si_errno = 0;
siginfo.si_code = FPE_FLTINV;
+ if (vector == 32) /* decode fault into si_code */
+ siginfo.si_code = fp_fault_si_code(isr);
siginfo.si_addr = (void *) (regs->cr_iip + ia64_psr(regs)->ri);
siginfo.si_flags = __ISR_VALID;
siginfo.si_isr = isr;
diff -Naur -X /home/jbarnes/dontdiff linux-2.4.19-ia64/include/asm-ia64/#fpu.h# linux-2.4.19-ia64-fpswa/include/asm-ia64/#fpu.h#
--- linux-2.4.19-ia64/include/asm-ia64/#fpu.h# Wed Dec 31 16:00:00 1969
+++ linux-2.4.19-ia64-fpswa/include/asm-ia64/#fpu.h# Thu Dec 12 12:14:31 2002
@@ -0,0 +1,65 @@
+#ifndef _ASM_IA64_FPU_H
+#define _ASM_IA64_FPU_H
+
+/*
+ * Copyright (C) 1998, 1999 Hewlett-Packard Co
+ * Copyright (C) 1998, 1999 David Mosberger-Tang <davidm@hpl.hp.com>
+ */
+
+#include <asm/types.h>
+
+/* floating point status register: */
+#define FPSR_TRAP_VD (1 << 0) /* invalid op trap disabled */
+#define FPSR_TRAP_DD (1 << 1) /* denormal trap disabled */
+#define FPSR_TRAP_ZD (1 << 2) /* zero-divide trap disabled */
+#define FPSR_TRAP_OD (1 << 3) /* overflow trap disabled */
+#define FPSR_TRAP_UD (1 << 4) /* underflow trap disabled */
+#define FPSR_TRAP_ID (1 << 5) /* inexact trap disabled */
+#define FPSR_S0(x) ((x) << 6)
+#define FPSR_S1(x) ((x) << 19)
+#define FPSR_S2(x) (__IA64_UL(x) << 32)
+#define FPSR_S3(x) (__IA64_UL(x) << 45)
+
+/* floating-point status field controls: */
+#define FPSF_FTZ (1 << 0) /* flush-to-zero */
+#define FPSF_WRE (1 << 1) /* widest-range exponent */
+#define FPSF_PC(x) (((x) & 0x3) << 2) /* precision control */
+#define FPSF_RC(x) (((x) & 0x3) << 4) /* rounding control */
+#define FPSF_TD (1 << 6) /* trap disabled */
+
+/* floating-point status field flags: */
+#define FPSF_V (1 << 7) /* invalid operation flag */
+#define FPSF_D (1 << 8) /* denormal/unnormal operand flag */
+#define FPSF_Z (1 << 9) /* zero divide (IEEE) flag */
+#define FPSF_O (1 << 10) /* overflow (IEEE) flag */
+#define FPSF_U (1 << 11) /* underflow (IEEE) flag */
+#define FPSF_I (1 << 12) /* inexact (IEEE) flag) */
+
+/* floating-point rounding control: */
+#define FPRC_NEAREST 0x0
+#define FPRC_NEGINF 0x1
+#define FPRC_POSINF 0x2
+#define FPRC_TRUNC 0x3
+
+#define FPSF_DEFAULT (FPSF_PC (0x3) | FPSF_RC (FPRC_NEAREST))
+
+/* This default value is the same as HP-UX uses. Don't change it
+ without a very good reason. */
+#define FPSR_DEFAULT (FPSR_TRAP_VD | FPSR_TRAP_DD | FPSR_TRAP_ZD \
+ | FPSR_TRAP_OD | FPSR_TRAP_UD | FPSR_TRAP_ID \
+ | FPSR_S0 (FPSF_DEFAULT) \
+ | FPSR_S1 (FPSF_DEFAULT | FPSF_TD | FPSF_WRE) \
+ | FPSR_S2 (FPSF_DEFAULT | FPSF_TD) \
+ | FPSR_S3 (FPSF_DEFAULT | FPSF_TD))
+
+# ifndef __ASSEMBLY__
+
+struct ia64_fpreg {
+ union {
+ unsigned long bits[2];
+ } u;
+} __attribute__ ((aligned (16)));
+
+# endif /* __ASSEMBLY__ */
+
+#endif /* _ASM_IA64_FPU_H */
diff -Naur -X /home/jbarnes/dontdiff linux-2.4.19-ia64/include/asm-ia64/fpu.h linux-2.4.19-ia64-fpswa/include/asm-ia64/fpu.h
--- linux-2.4.19-ia64/include/asm-ia64/fpu.h Sun Feb 6 18:42:40 2000
+++ linux-2.4.19-ia64-fpswa/include/asm-ia64/fpu.h Thu Dec 12 10:11:45 2002
@@ -54,6 +54,11 @@
# ifndef __ASSEMBLY__
+struct fp_fault_info {
+ unsigned long isr_code_bit;
+ int si_code; /* SIGFPE si_code */
+};
+
struct ia64_fpreg {
union {
unsigned long bits[2];
diff -Naur -X /home/jbarnes/dontdiff linux-2.4.19-ia64/include/asm-ia64/siginfo.h linux-2.4.19-ia64-fpswa/include/asm-ia64/siginfo.h
--- linux-2.4.19-ia64/include/asm-ia64/siginfo.h Thu Dec 12 10:15:59 2002
+++ linux-2.4.19-ia64-fpswa/include/asm-ia64/siginfo.h Thu Dec 12 12:18:52 2002
@@ -172,6 +172,8 @@
#define __FPE_DECERR (__SI_FAULT|11) /* packed decimal error */
#define __FPE_INVASC (__SI_FAULT|12) /* invalid ASCII digit */
#define __FPE_INVDEC (__SI_FAULT|13) /* invalid decimal digit */
+#define __FPE_SWASST (__SI_FAULT|14) /* software assist fault */
+#define __FPE_DENORM (__SI_FAULT|15) /* denormal/unnormal operand */
#define NSIGFPE 13
/*
^ permalink raw reply
* Re: "bio too big" error
From: Joe Thornber @ 2002-12-12 20:29 UTC (permalink / raw)
To: Wil Reichert; +Cc: Joe Thornber, linux-kernel
In-Reply-To: <1039718098.433.13.camel@darwin>
On Thu, Dec 12, 2002 at 01:34:59PM -0500, Wil Reichert wrote:
> Yeah, ditching patch 5 makes my lvm functional again. Things are
> definately better now. I haven't attempted to stress it, but the entire
> hanging console / zombie process bit has gone away. Everything appears
> to work normally. A couple test cp's shows nothing abnormal, but
> playing an ogg still results in the following.
>
> Dec 12 13:32:20 darwin kernel: bio too big device ide2(33,0) (256 > 255)
> Dec 12 13:32:51 darwin last message repeated 3 times
> Dec 12 13:33:55 darwin last message repeated 6 times
>
> Any other tests I should do?
I'm now seeing some corruption with large files, so I'll fix that and
hope that it solves your problem too. wrt. the device size bug that
you're experiencing could you mail me (not the list) your .config
please ?
- Joe
^ permalink raw reply
* Re: Adventure - the answer to what went wrong?
From: Harry Kalogirou @ 2002-12-12 20:21 UTC (permalink / raw)
To: Richard Wallman; +Cc: Linux 8086
In-Reply-To: <200212121911.gBCJB75G012842@eddie.loc>
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
> Gave it a bit of thought today, and I think I know what happened.
>
> Looking at the libc sources, it looks like the strcmp and strncmp
> functions assume that both strings are in the same 64Kb segment. (There
> may be other functions that make this assumption as well, but I haven't
> really looked).
They assume right! In ELKS DS=SS=ES.
By the way, the CVS ELKS tree solves many memory problems but requires a
patch to the linker that I posted here some time ago and never got in
the linker tree... :(
Harry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Doug Ledford @ 2002-12-12 20:20 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Justin T. Gibbs, James Bottomley, linux-scsi
In-Reply-To: <20021211181745.A30253@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]
On Wed, Dec 11, 2002 at 06:17:46PM +0000, Christoph Hellwig wrote:
>
> Yupp, it currently crashes when I have both compiled in. Dough, any chance
> you could fix that? A PCI driver is not supposed to stop over already
> claimed device.
If you've got a test machine, the attached patch would I think fix the
problem. Let me know if it does in fact work for you and I'll commit it
to the tree.
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
[-- Attachment #2: aic-playnice.patch --]
[-- Type: text/plain, Size: 3647 bytes --]
===== drivers/scsi/aic7xxx_old.c 1.37 vs edited =====
--- 1.37/drivers/scsi/aic7xxx_old.c Fri Nov 22 00:34:44 2002
+++ edited/drivers/scsi/aic7xxx_old.c Thu Dec 12 13:35:23 2002
@@ -9246,12 +9246,22 @@
{
/* duplicate PCI entry, skip it */
kfree(temp_p);
- temp_p = NULL;
+ continue;
}
current_p = current_p->next;
}
- if ( temp_p == NULL )
+ if(!pci_request_regions(temp_p->pdev, "aic7xxx"))
+ {
+ printk("aic7xxx: <%s> at PCI %d/%d/%d\n",
+ board_names[aic_pdevs[i].board_name_index],
+ temp_p->pci_bus,
+ PCI_SLOT(temp_p->pci_device_fn),
+ PCI_FUNC(temp_p->pci_device_fn));
+ printk("aic7xxx: I/O ports already in use, ignoring.\n");
+ kfree(temp_p);
continue;
+ }
+
if (aic7xxx_verbose & VERBOSE_PROBE2)
printk("aic7xxx: <%s> at PCI %d/%d\n",
board_names[aic_pdevs[i].board_name_index],
@@ -9283,20 +9293,6 @@
pci_write_config_dword(pdev, DEVCONFIG, devconfig);
#endif /* AIC7XXX_STRICT_PCI_SETUP */
- if(temp_p->base && !request_region(temp_p->base, MAXREG - MINREG,
- "aic7xxx"))
- {
- printk("aic7xxx: <%s> at PCI %d/%d/%d\n",
- board_names[aic_pdevs[i].board_name_index],
- temp_p->pci_bus,
- PCI_SLOT(temp_p->pci_device_fn),
- PCI_FUNC(temp_p->pci_device_fn));
- printk("aic7xxx: I/O ports already in use, ignoring.\n");
- kfree(temp_p);
- temp_p = NULL;
- continue;
- }
-
temp_p->unpause = INTEN;
temp_p->pause = temp_p->unpause | PAUSE;
if ( ((temp_p->base == 0) &&
@@ -9309,9 +9305,7 @@
PCI_SLOT(temp_p->pci_device_fn),
PCI_FUNC(temp_p->pci_device_fn));
printk("aic7xxx: Controller disabled by BIOS, ignoring.\n");
- kfree(temp_p);
- temp_p = NULL;
- continue;
+ goto skip_pci_controller;
}
#ifdef MMAPIO
@@ -9353,9 +9347,7 @@
PCI_SLOT(temp_p->pci_device_fn),
PCI_FUNC(temp_p->pci_device_fn));
printk("aic7xxx: Controller disabled by BIOS, ignoring.\n");
- kfree(temp_p);
- temp_p = NULL;
- continue;
+ goto skip_pci_controller;
}
}
}
@@ -9398,10 +9390,7 @@
if (aic7xxx_chip_reset(temp_p) == -1)
{
- release_region(temp_p->base, MAXREG - MINREG);
- kfree(temp_p);
- temp_p = NULL;
- continue;
+ goto skip_pci_controller;
}
/*
* Very quickly put the term setting back into the register since
@@ -9687,6 +9676,10 @@
}
temp_p->next = NULL;
found++;
+ continue;
+skip_pci_controller:
+ pci_release_regions(temp_p->pdev);
+ kfree(temp_p);
} /* Found an Adaptec PCI device. */
else /* Well, we found one, but we couldn't get any memory */
{
@@ -10969,14 +10962,16 @@
if(p->irq)
free_irq(p->irq, p);
- if(p->base)
- release_region(p->base, MAXREG - MINREG);
#ifdef MMAPIO
if(p->maddr)
{
iounmap((void *) (((unsigned long) p->maddr) & PAGE_MASK));
}
#endif /* MMAPIO */
+ if(!p->pdev)
+ release_region(p->base, MAXREG - MINREG);
+ else
+ pci_release_regions(p->pdev);
prev = NULL;
next = first_aic7xxx;
while(next != NULL)
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Mark Mielke @ 2002-12-12 20:36 UTC (permalink / raw)
To: Terje Eggestad; +Cc: H. Peter Anvin, linux-kernel, Dave Jones
In-Reply-To: <1039686176.25186.195.camel@pc-16.office.scali.no>
On Thu, Dec 12, 2002 at 10:42:56AM +0100, Terje Eggestad wrote:
> On ons, 2002-12-11 at 19:50, H. Peter Anvin wrote:
> > Terje Eggestad wrote:
> > > PS: rdtsc on P4 is also painfully slow!!!
> > Now that's just braindead...
> It takes about 11 cycles on athlon, 34 on PII, and a whooping 84 on P4.
> For a simple op like that, even 11 is a lot... Really makes you wonder.
Some of this discussion is a little bit unfair. My understanding of what
Intel has done with the P4, is create an architecture that allows for
higher clock rates. Sure the P4 might take 84, vs PII 34, but how many
PII 2.4 Ghz machines have you ever seen on the market?
Certainly, some of their decisions seem to be a little odd on the surface.
That doesn't mean the situation is black and white.
mark
--
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
^ permalink raw reply
* Re: 2.5.51 breaks ALSA AWE32
From: Kai Germaschewski @ 2002-12-12 20:26 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: John Bradford, perex, linux-kernel
In-Reply-To: <20021212195258.GA12691@mars.ravnborg.org>
On Thu, 12 Dec 2002, Sam Ravnborg wrote:
> kbuild check if any obj-* value has been assigned a value,
> so an empty assignment does not help.
>
> I have made a patch that works this time.
>
> Kai, any ideas how to do this in a better way?
The minimal fix I can think of would be
===== sound/synth/Makefile 1.8 vs edited =====
--- 1.8/sound/synth/Makefile Mon Jun 10 19:49:43 2002
+++ edited/sound/synth/Makefile Thu Dec 12 14:16:02 2002
@@ -14,6 +14,6 @@
obj-$(CONFIG_SND_SBAWE) += snd-util-mem.o
endif
-obj-$(CONFIG_SND) += emux/
+obj-$(CONFIG_SND_SEQUENCER) += emux/
include $(TOPDIR)/Rules.make
While we're at it, a bit of cleaning up shouldn't hurt, though, so the
complete suggested patch would be
===== sound/synth/Makefile 1.8 vs edited =====
--- 1.8/sound/synth/Makefile Mon Jun 10 19:49:43 2002
+++ edited/sound/synth/Makefile Thu Dec 12 14:20:47 2002
@@ -10,10 +10,10 @@
# Toplevel Module Dependency
obj-$(CONFIG_SND_EMU10K1) += snd-util-mem.o
obj-$(CONFIG_SND_TRIDENT) += snd-util-mem.o
-ifeq ($(subst m,y,$(CONFIG_SND_SEQUENCER)),y)
+ifdef CONFIG_SND_SEQUENCER
obj-$(CONFIG_SND_SBAWE) += snd-util-mem.o
endif
-obj-$(CONFIG_SND) += emux/
+obj-$(CONFIG_SND_SEQUENCER) += emux/
include $(TOPDIR)/Rules.make
===== sound/synth/emux/Makefile 1.4 vs edited =====
--- 1.4/sound/synth/emux/Makefile Tue Jun 18 04:16:20 2002
+++ edited/sound/synth/emux/Makefile Thu Dec 12 14:20:08 2002
@@ -5,16 +5,11 @@
export-objs := emux.o
-snd-emux-synth-objs := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
- emux_effect.o emux_proc.o soundfont.o
-ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
- snd-emux-synth-objs += emux_oss.o
-endif
+snd-emux-synth-y := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
+ emux_effect.o emux_proc.o soundfont.o
+snd-emux-synth-$(CONFIG_SND_SEQUENCER_OSS) += emux_oss.o
-# Toplevel Module Dependency
-ifeq ($(subst m,y,$(CONFIG_SND_SEQUENCER)),y)
- obj-$(CONFIG_SND_SBAWE) += snd-emux-synth.o
- obj-$(CONFIG_SND_EMU10K1) += snd-emux-synth.o
-endif
+obj-$(CONFIG_SND_SBAWE) += snd-emux-synth.o
+obj-$(CONFIG_SND_EMU10K1) += snd-emux-synth.o
include $(TOPDIR)/Rules.make
However, synth/Makefile still has the ugly ifdef in there, which wouldn't
be necessary if we entered synth/ just when CONFIG_SND_SEQUENCER is set.
It looks like more generic routines are in synth/ (util-mem), though,
which IMO shouldn't be there, but rather in some lib/ or whatever dir. So
there's the opportunity for further cleanup, but I'll leave that to the
ALSA people. Anybody care for testing the second patch above?
--Kai
^ permalink raw reply
* [PATCH 2.4-ac] Via 8233 Sound
From: Nathaniel Russell @ 2002-12-12 20:24 UTC (permalink / raw)
To: alan; +Cc: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 201 bytes --]
Thank you Alan is this what you were talking about.
It worked for me now i can use my onboard Sound. Thank you. Oh here is the
patch for you.
Nathaniel
CC reddog83@chartermi.net not subscribed to list
[-- Attachment #2: Via 8233 --]
[-- Type: TEXT/PLAIN, Size: 402 bytes --]
diff -urN linux-ac/drivers/sound/via82cxxx_audio.c linux/drivers/sound/via82cxxx_audio.c
--- linux-ac/drivers/sound/via82cxxx_audio.c 2002-12-12 03:21:04.000000000 -0500
+++ linux/drivers/sound/via82cxxx_audio.c 2002-12-12 14:54:36.000000000 -0500
@@ -885,7 +885,7 @@
spin_unlock_irq (&card->lock);
- synchronize_irq(card->pdev->irq);
+ synchronize_irq();
DPRINTK ("EXIT\n");
}
^ permalink raw reply
* R: Kernel bug handling TCP_RTO_MAX?
From: Andreani Stefano @ 2002-12-12 20:18 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, linux-net
Never say never ;-)
I need to change it now as a temporary workaround for a problem in the UMTS core network of my company. But I think there could be thousands of situations where a fine tuning of this TCP parameter could be useful.
Any contributes on the problem?
Stefano.
-----Messaggio originale-----
Da: David S. Miller [mailto:davem@redhat.com]
Inviato: giovedì 12 dicembre 2002 20.59
A: Andreani Stefano
Cc: linux-kernel@vger.kernel.org; linux-net@vger.kernel.org
Oggetto: Re: Kernel bug handling TCP_RTO_MAX?
From: "Andreani Stefano" <stefano.andreani.ap@h3g.it>
Date: Thu, 12 Dec 2002 20:15:42 +0100
Problem: I need to change the max value of the TCP retransmission
timeout.
Why? There should be zero reason to change this value.
^ permalink raw reply
* Re: Pinning kernel memory
From: Rik van Riel @ 2002-12-12 20:15 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: linux-kernel
In-Reply-To: <1039712449.3df8c0c183dfe@rumms.uni-mannheim.de>
On Thu, 12 Dec 2002, Thomas Schlichter wrote:
> I want to create a big area of unswappable, physical continuous kernel memory
> for hardware testing purposes. Currently I allocate the memory using
> alloc_pages(GFP_KERNEL, order) and after this I pin it using
> SetPageReserved(page) for each page.
Kernel memory is never swappable, so there is no need to "pin it".
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
^ permalink raw reply
* Re: Kernel bug handling TCP_RTO_MAX?
From: Richard B. Johnson @ 2002-12-12 20:18 UTC (permalink / raw)
To: Andreani Stefano; +Cc: linux-kernel, linux-net
In-Reply-To: <047ACC5B9A00D741927A4A32E7D01B73D66176@RMEXC01.h3g.it>
On Thu, 12 Dec 2002, Andreani Stefano wrote:
> Problem: I need to change the max value of the TCP retransmission timeout.
>
> Background: According to Karn's exponential backoff algorithm, when the
> receiver doesn't acknowledge packets for a while, the sender should
> retransmit the latest not acknowledged packet several times increasing
> the delay (RTO) since this delay reaches the Max Retransmission Timeout
> Value.
>
> Testing environment: Red Hat Linux release 7.2 (Enigma), Kernel 2.4.7-10
> on an i686, Kernel 2.4.7-10.
>
> Test details: I supposed this timeout in Linux was TCP_RTO_MAX, so I
> changed in /include/net/tcp.h the following line:
>
> #define TCP_RTO_MAX ((unsigned)(6*HZ)) //It was: ((unsigned)(120*HZ))
>
> Then I recompiled the kernel, rebooted the machine and tested the solution.
> The result I obtained was the same I had before this modification.
>
> I'm confident there isn't an error in the testing procedure because I
> already tested with a Solaris server the same procedure (changing the
> tcp_rexmit_interval_max variable) and it works. I'm just trying to
> reproduce the modification of that parameter in Linux.
>
> Could it be a bug on the RTO calculation algorithm, or there is something
> I mistook?
>
> This is the first time I get into the linux kernel, so please be patient!
>
> Thanks,
>
> Stefano.
No file like /include/net/tcp.h is used in the compilation of the kernel.
Perhaps you mean ../linux-VERS/include/net/tcp.h (make sure you are
not compiling against some user-space headers).
Also, please fix your mailer line-wrap. Unix/Linux machines put '\n'
on or before the 80th character.
Once you check this out, search through that file, looking for "RTO".
There are many things that affect the retransmit interval. FYI the
current algorithm is correct and the minimum time to retransmit must
not be changed if you put this on a "live" network. If you were to
do this, your Linux machine gets an unfair advantage on a congested
network. This may seem great at first, but eventually your machine
will actually need to receive some some data. By taking over the
wire, you will end up with a bunch of hosts that were backed off,
now trying to jam packets into your machine. The result will be
poor performance because many packets will have to be dumped on
the floor, requiring an eventual retransmit.
Also, remember to install the new kernel before you re-boot. Some
persons forget that they actually have to install the kernel. They
compile it, smile when it completes, then reboot.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* detecting layout in RAID
From: Anu @ 2002-12-12 20:12 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021211183059.A19030@light-brigade.mit.edu>
hello,
I am trying to detect layouts of the RAID configuration (I have a
software RAID set up. ) Mine is currently left symmetric and the way I am
trying to detect layout is to reaad consecutive blocks and look for
whether there is a big dp when it has to move all the way across..
there seems to be no such thing. e.g.
1 2 3 P
5 6 P 4
9 P 7 8
P 10 11 12
should show some timing difference when block 5 is read - i get an
exponentially decreasing curve !
any ideas? or other newsgroups i can hit
^ permalink raw reply
* Re: [PATCH 2.4-ac] Via 8233 Sound not working
From: Alan Cox @ 2002-12-12 20:10 UTC (permalink / raw)
To: Nathaniel Russell; +Cc: alan, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212121459570.3368-300000@reddog.example.net>
Humm I didnt build it SMP so missed that case I guess. CHange to
synchronize_irq()
^ permalink raw reply
* [PATCH 2.4-ac] Via 8233 Sound not working
From: Nathaniel Russell @ 2002-12-12 20:08 UTC (permalink / raw)
To: alan; +Cc: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 251 bytes --]
I needed this patch to compile so i just commented the
synchronize_irq bit out. I have included the patch and the error message.
This is a temp fix i don't know if this is correct or not.
Nathaniel
CC me at reddog83@chartermi.net as im not subscribed
[-- Attachment #2: Via 8233 --]
[-- Type: TEXT/PLAIN, Size: 421 bytes --]
diff -urN linux-ac/drivers/sound/via82cxxx_audio.c linux/drivers/sound/via82cxxx_audio.c
--- linux-ac/drivers/sound/via82cxxx_audio.c 2002-12-12 03:21:04.000000000 -0500
+++ linux/drivers/sound/via82cxxx_audio.c 2002-12-12 14:54:36.000000000 -0500
@@ -885,7 +885,7 @@
spin_unlock_irq (&card->lock);
- synchronize_irq(card->pdev->irq);
+/* synchronize_irq(card->pdev->irq); */
DPRINTK ("EXIT\n");
}
[-- Attachment #3: Error Message from Compile --]
[-- Type: TEXT/PLAIN, Size: 468 bytes --]
via82cxxx_audio.c:888:40: macro "synchronize_irq" passed 1 arguments, but takes just 0
via82cxxx_audio.c: In function `via_chan_free':
via82cxxx_audio.c:888: `synchronize_irq' undeclared (first use in this function)
via82cxxx_audio.c:888: (Each undeclared identifier is reported only once
via82cxxx_audio.c:888: for each function it appears in.)
make[2]: *** [via82cxxx_audio.o] Error 1
make[1]: *** [_modsubdir_sound] Error 2
make: *** [_mod_drivers] Error 2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.