* [LARTC] CBQ rate question
From: René Serral @ 2002-12-20 13:45 UTC (permalink / raw)
To: lartc
In the IST-LONG project (http://www.ist-long.com) we are using TC to make our
QoS IPv6 experiments and we have one question, in CBQ, how the "rate" is
calculated? I mean, when I write "...rate 200000 bps...", this 200Kbps are
level-3 bits per second, or they include level-2 bits....
Thanks in advance.
--
---------------------------------------------------------------
René Serral Universitat Politècnica de Catalunya
rserral@ac.upc.es
UPC Campus Nord, Ed. D4 Tel: +34 934 017 432
Barcelona 08034
---------------------------------------------------------------
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* IO Input based on DSDT
From: Matthew Tippett @ 2002-12-20 13:45 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
A quick question...
Based on the DSDT, is it possible to write userland applications that
interrogate the same ports as the DSDT? For example, the battery
information method _BIF calls the BIF_ which is the following code.
Arg0 is the battery index.
SX10()
SX30(0x1)
SX30(Arg0)
SX11()
Store(SX42(), Index(BIFP, 0x0, ))
Store(SX42(), Index(BIFP, 0x1, ))
Store(SX42(), Index(BIFP, 0x2, ))
Store(SX42(), Index(BIFP, 0x3, ))
Store(SX42(), Index(BIFP, 0x4, ))
Store(SX42(), Index(BIFP, 0x5, ))
Store(SX42(), Index(BIFP, 0x6, ))
Store(SX42(), Index(BIFP, 0x7, ))
Store(SX42(), Index(BIFP, 0x8, ))
Store(SX45(), Index(BIFP, 0x9, ))
Store(SX45(), Index(BIFP, 0xa, ))
Store(SX45(), Index(BIFP, 0xb, ))
Store(SX45(), Index(BIFP, 0xc, ))
SX12()
Return(BIFP)
Which is fairly obviously a 'configure', 'read', 'set structure',
'return'.
The question I have is that by digging deep enough into the call graph
will I end up with a set of ports that would allow me to extract the
data that I want, so that I can then rebuild a working DSDT.
And by extension, could I take some actions that occur on ports, and
then look at making those available via ACPI? (Such as fan control
which is ignored in the Dell i8200 DSDT).
Regards,
Matt
--
Matthew Tippett - matthew.tippett-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org - (416) 435-4118
Technology Forum - http://www.technology-forum.org/
Commercial Open Source - http://www.commercialos.org/
-----
The information contained in this message is proprietary of Casero Inc.,
protected from disclosure, and may be privileged. The information is
intended to be conveyed only to the designated recipient(s) of the
message. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, use, distribution or
copying of this communication is strictly prohibited and may be
unlawful. If you have received this communication in error, please
notify us immediately by replying to the message and deleting it from
your computer. Thank you.
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* OT: Which Gigabit ethernet card?
From: Jurgen Kramer @ 2002-12-20 13:45 UTC (permalink / raw)
To: linux-kernel
Hi,
I know this is a bit OT but because here are the kernel driver hackers
this might be the right place to ask.
I am looking for a couple of PCI Gigabit ethernet adapters to play
around with SAN/NAS stuff like iSCSI and HyperSCSI and the like. There
are variuos adapters around which work with Linux. My choice would be
based on the following:
- Relatively cheap, around $100/EUR100
- 32 bit/33MHz PCI compatible
- Low cpu usage
- Busmaster DMA
- Opensource Linux driver
- zero-copy capable
- etc.
What card is best? 3Com, Intel or National Semi based?
Thanks,
Jurgen
^ permalink raw reply
* Re: [PATCH] 2.5.52: compilation fixes for alpha
From: Hannes Reinecke @ 2002-12-20 14:45 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Linux Kernel
In-Reply-To: <Pine.LNX.4.44.0212200839320.11457-100000@gfrw1044.bocc.de>
[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]
Jochen Friedrich wrote:
> Hi Hannes,
>
>
>>attached are some compilation fixes needed to get the alpha port up and
>>running. Note: These fixes are on top of patch-2.5.52-bk3 in the
>>2.5/testing directory, which contain some neccessary fixes regarding
>>exception handling.
>
>
> Is there an additional patch missing?
>
> arch/alpha/mm/extable.c: In function `search_exception_table':
> arch/alpha/mm/extable.c:48: `module_list' undeclared (first use in this
> function)
>
Shit. I forgot that one (I knew there was something missing).
Try the attached patch instead; it's identical to the previous one, I
just appended the patch for arch/alpha/mm/extable.c
Let me know whether it works.
Note: Module loading is still likely to be buggered, since it
appearantly relies on newer modutils (I'm a bit out of touch with
current events). But at least it compiles and runs, even with modules
enabled. I see what I can dig out re. modules.
> This is -bk3 from v2.5/snapshots +your patch (-bk4 +your patch fails to
> compile with the same message).
>
Small wonder. Alpha fixes always tend to be a bit uncared-for.
> It looks like i386 replaced the loop through module_list by a walk through
> extables which is not yet in alpha code.
>
Indeed. Alternatively you can copy the code from i386, which is quite
generic (and that's what I did anyway).
> Thanks,
Nae bother.
Cheers,
Hannes
[-- Attachment #2: bk3-alpha.patch --]
[-- Type: text/plain, Size: 6449 bytes --]
--- arch/alpha/kernel/Makefile.orig Thu Dec 19 17:44:23 2002
+++ arch/alpha/kernel/Makefile Thu Dec 19 17:44:30 2002
@@ -26,6 +26,7 @@
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_PCI) += pci.o pci_iommu.o
obj-$(CONFIG_SRM_ENV) += srm_env.o
+obj-$(CONFIG_MODULES) += module.o
ifdef CONFIG_ALPHA_GENERIC
--- arch/alpha/vmlinux.lds.S.orig Thu Dec 19 17:55:58 2002
+++ arch/alpha/vmlinux.lds.S Thu Dec 19 17:57:35 2002
@@ -55,6 +55,12 @@
__setup_end = .;
}
+ __param ALIGN(16): {
+ __start___param = .;
+ *(__param);
+ __stop___param = .;
+ }
+
.initcall.init ALIGN(8): {
__initcall_start = .;
*(.initcall1.init)
--- include/asm-alpha/module.h.orig Thu Dec 19 13:26:01 2002
+++ include/asm-alpha/module.h Thu Dec 19 13:34:11 2002
@@ -1,6 +1,11 @@
#ifndef _ASM_ALPHA_MODULE_H
#define _ASM_ALPHA_MODULE_H
-/* Module rewrite still in progress. */
+struct mod_arch_specific
+{
+};
+#define Elf_Shdr Elf64_Shdr
+#define Elf_Sym Elf64_Sym
+#define Elf_Ehdr Elf64_Ehdr
#endif /* _ASM_ALPHA_MODULE_H */
--- /dev/null Tue Oct 22 14:39:45 2002
+++ arch/alpha/kernel/module.c Thu Dec 19 17:48:41 2002
@@ -0,0 +1,135 @@
+/* Kernel module help for Alpha.
+ Copyright (C) 2002 Richard Henderson.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License along
+ with this program; if not, write to the Free Software Foundation, Inc.,
+ 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
+
+#include <linux/moduleloader.h>
+#include <linux/elf.h>
+#include <linux/vmalloc.h>
+#include <linux/fs.h>
+#include <linux/string.h>
+#include <linux/kernel.h>
+
+#if 0
+#define DEBUGP printk
+#else
+#define DEBUGP(fmt , ...)
+#endif
+
+void *module_alloc(unsigned long size)
+{
+ if (size == 0)
+ return NULL;
+ return vmalloc(size);
+}
+
+/* Free memory returned from module_alloc */
+void module_free(struct module *mod, void *module_region)
+{
+ vfree(module_region);
+ /* FIXME: If module_region == mod->init_region, trim exception
+ table entries. */
+}
+
+/* We don't need anything special. */
+long module_core_size(const Elf64_Ehdr *hdr,
+ const Elf64_Shdr *sechdrs,
+ const char *secstrings,
+ struct module *module)
+{
+ return module->core_size;
+}
+
+long module_init_size(const Elf64_Ehdr *hdr,
+ const Elf64_Shdr *sechdrs,
+ const char *secstrings,
+ struct module *module)
+{
+ return module->init_size;
+}
+
+int apply_relocate(Elf64_Shdr *sechdrs,
+ const char *strtab,
+ unsigned int symindex,
+ unsigned int relsec,
+ struct module *me)
+{
+ return -ENOEXEC;
+}
+
+int apply_relocate_add(Elf64_Shdr *sechdrs,
+ const char *strtab,
+ unsigned int symindex,
+ unsigned int relsec,
+ struct module *me)
+{
+ Elf64_Rela *rela = (void *)sechdrs[relsec].sh_offset;
+ Elf64_Sym *sym;
+ char *location;
+ unsigned long i;
+
+ for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rela); i++) {
+ unsigned long r_type = ELF64_R_TYPE(rela[i].r_info);
+ unsigned long value = 0;
+
+ /* This is where to make the change */
+ location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_offset
+ + rela[i].r_offset;
+
+ if (r_type == R_ALPHA_RELATIVE) {
+ /* Binutils before 2.12 or so are borken. We should
+ have the RELATIVE offset as the addend of the
+ relocation. If it's not present, fall back to the
+ value at the relocation address. */
+ u64 addend = rela[i].r_addend;
+ if (addend == 0)
+ addend = *(u64 *)location;
+
+ *(u64 *)location = (u64)me->module_core + addend;
+ continue;
+ }
+
+ /* This is the symbol it is referring to. */
+ sym = (Elf64_Sym *)sechdrs[symindex].sh_offset
+ + ELF64_R_SYM(rela[i].r_info);
+ if (!sym->st_value) {
+ printk(KERN_WARNING "%s: Unknown symbol %s\n",
+ me->name, strtab + sym->st_name);
+ return -ENOENT;
+ }
+ value += rela[i].r_addend;
+
+ switch (r_type) {
+ case R_ALPHA_GLOB_DAT:
+ case R_ALPHA_JMP_SLOT:
+ case R_ALPHA_REFQUAD:
+ *(u64 *)location = value;
+ break;
+ default:
+ printk(KERN_ERR "module %s: Unknown relocation: %lu\n",
+ me->name, r_type);
+ return -ENOEXEC;
+ }
+ }
+
+ return 0;
+}
+
+int module_finalize(const Elf_Ehdr *hdr,
+ const Elf_Shdr *sechdrs,
+ struct module *me)
+{
+ return 0;
+}
--- arch/alpha/mm/extable.c.orig Thu Dec 19 13:23:51 2002
+++ arch/alpha/mm/extable.c Thu Dec 19 13:30:34 2002
@@ -33,23 +33,24 @@
unsigned
search_exception_table(unsigned long addr)
{
- unsigned ret;
+ unsigned ret = 0;
#ifndef CONFIG_MODULES
ret = search_one_table(__start___ex_table, __stop___ex_table-1, addr);
#else
extern spinlock_t modlist_lock;
unsigned long flags;
- /* The kernel is the last "module" -- no need to treat it special. */
- struct module *mp;
+ struct list_head *i;
- ret = 0;
+ /* The kernel is the last "module" -- no need to treat it special. */
spin_lock_irqsave(&modlist_lock, flags);
- for (mp = module_list; mp ; mp = mp->next) {
- if (!mp->ex_table_start || !(mp->flags&(MOD_RUNNING|MOD_INITIALIZING)))
+ list_for_each(i, &extables) {
+ struct exception_table *ex
+ = list_entry(i, struct exception_table, list);
+ if (ex->num_entries == 0)
continue;
- ret = search_one_table(mp->ex_table_start,
- mp->ex_table_end - 1, addr);
+ ret = search_one_table(ex->entry,
+ ex->entry + ex->num_entries - 1, addr);
if (ret)
break;
}
^ permalink raw reply
* Re: [PATCH] joydev: fix HZ->millisecond transformation
From: Vojtech Pavlik @ 2002-12-20 13:24 UTC (permalink / raw)
To: george anzinger; +Cc: Bjorn Helgaas, Marcelo Tosatti, linux-kernel
In-Reply-To: <3E02F3EE.C1367073@mvista.com>
On Fri, Dec 20, 2002 at 02:41:50AM -0800, george anzinger wrote:
> Bjorn Helgaas wrote:
> >
> > * fix a problem with HZ->millisecond transformation on
> > non-x86 archs (from 2.5 change by vojtech@suse.cz)
> >
> > Applies to 2.4.20.
> >
> > diff -Nru a/drivers/input/joydev.c b/drivers/input/joydev.c
> > --- a/drivers/input/joydev.c Mon Dec 16 12:16:32 2002
> > +++ b/drivers/input/joydev.c Mon Dec 16 12:16:32 2002
> > @@ -50,6 +50,8 @@
> > #define JOYDEV_MINORS 32
> > #define JOYDEV_BUFFER_SIZE 64
> >
> > +#define MSECS(t) (1000 * ((t) / HZ) + 1000 * ((t) % HZ) / HZ)
> Uh...
> ^^^^^^^^^^^^^^^^
> by definition this is zero, is it not?
No, both parts of the equaition can be nonzero.
Though it might be easier to say (1000 * t) / HZ, now that I think about
it.
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* Re: [PATCH]: test_bit returns int in all the architectures
From: Ralf Baechle @ 2002-12-20 12:59 UTC (permalink / raw)
To: Juan Quintela; +Cc: mipslist
In-Reply-To: <m2fzstgffx.fsf@demo.mitica>
On Fri, Dec 20, 2002 at 11:20:02AM +0100, Juan Quintela wrote:
> to be consistent with everybody else, test_bit should return a
> int. Notice that it only returns 0/1, not a big deal.
I'm using below patch instead.
Ralf
Index: include/asm-mips/bitops.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/bitops.h,v
retrieving revision 1.21.2.9
diff -u -r1.21.2.9 bitops.h
--- include/asm-mips/bitops.h 5 Dec 2002 03:25:20 -0000 1.21.2.9
+++ include/asm-mips/bitops.h 20 Dec 2002 12:54:10 -0000
@@ -582,9 +582,9 @@
* @nr: bit number to test
* @addr: Address to start counting from
*/
-static __inline__ int test_bit(int nr, volatile void *addr)
+static inline int test_bit(int nr, volatile void *addr)
{
- return ((1UL << (nr & 31)) & (((const unsigned int *) addr)[nr >> 5])) != 0;
+ return 1UL & (((const volatile unsigned long *) addr)[nr >> SZLONG_LOG] >> (nr & SZLONG_MASK));
}
/*
Index: include/asm-mips64/bitops.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/bitops.h,v
retrieving revision 1.15.2.10
diff -u -r1.15.2.10 bitops.h
--- include/asm-mips64/bitops.h 5 Dec 2002 03:25:20 -0000 1.15.2.10
+++ include/asm-mips64/bitops.h 20 Dec 2002 12:54:12 -0000
@@ -302,9 +302,9 @@
* @nr: bit number to test
* @addr: Address to start counting from
*/
-static inline unsigned long test_bit(int nr, volatile void * addr)
+static inline int test_bit(int nr, volatile void * addr)
{
- return 1UL & (((volatile unsigned long *) addr)[nr >> 6] >> (nr & 0x3f));
+ return 1UL & (((const volatile unsigned long *) addr)[nr >> SZLONG_LOG] >> (nr & SZLONG_MASK));
}
/*
^ permalink raw reply
* Re: Minicom fails
From: Frank Roberts - SOTL @ 2002-12-20 12:55 UTC (permalink / raw)
To: Peter, linux-newbie
In-Reply-To: <200212200700.gBK704603967@philonline.com>
If it works you are correct.
Frank
On Friday 20 December 2002 02:00, Peter wrote:
> Peter said:
> > After I run a RH7.3 upgrade I can't access anymore minicom as a user.
> > I get the following message: ]$ minicom Device /dev/ttyS0 lock failed:
> > Operation not permitted.
>
> Thanks Frank!
>
> The first thing I did was reading the man pages after the opening failure.
> I got nothing out of it.
>
> What I did now was setting the group of /var/lock to user and I can open
> minicom again.
>
> Was this the right way to do it?
>
> Regards
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* RE: [parisc-linux] 2.4.21-pre2 : sysctl.h pb
From: jsoe0708 @ 2002-12-20 12:53 UTC (permalink / raw)
To: parisc-linux
In-Reply-To: <3E0085D0000004FA@ocpmta5.freegates.net>
??
Actual mesage is:
Hi all,
Merging 2.4.21-pre2 with parisc tree, I notice the following the followin=
g
pb:
diff -urN linux-2.4.21-pre1/include/linux/sysctl.h linux-2.4.21-pre2/incl=
ude/linux/sysctl.h
--- linux-2.4.21-pre1/include/linux/sysctl.h Thu Nov 28 15:53:15 2002
+++ linux-2.4.21-pre2/include/linux/sysctl.h Wed Dec 18 14:16:28 2002
@@ -124,6 +124,7 @@
KERN_CORE_USES_PID=3D52, /* int: use core or core.%pid *=
/
KERN_TAINTED=3D53, /* int: various kernel tainted flags */=
KERN_CADPID=3D54, /* int: PID of the process to notify on=
CAD */
+ KERN_CORE_PATTERN=3D56, /* string: pattern for core-files */
};
into linux-2.4.21-pre1-pa15/include/linux/sysctl.h
KERN_TAINTED=3D53, /* int: various kernel tainted flags */=
KERN_CADPID=3D54, /* int: PID of the process to notify on=
CAD */
KERN_HPPA_PWRSW=3D55, /* int: hppa soft-power enable */
KERN_HPPA_UNALIGNED=3D56, /* int: hppa unaligned-trap enable */
};
^^^^ same as new KERN_CORE_PATTERN
What should I to do?
Sorry,
Joel
*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be
^ permalink raw reply
* [parisc-linux] 2.4.21-pre2 : sysctl.h pb
From: jsoe0708 @ 2002-12-20 12:48 UTC (permalink / raw)
To: parisc-linux
Hi all,
Merging 2.4.21-pre2 with parisc tree, I notice the following the followin=
g
pb:
diff -urN linux-2.4.21-pre1/include/linux/sysctl.h linux-2.4.21-pre2/incl=
ude/linux/sysctl.h
--- linux-2.4.21-pre1/include/linux/sysctl.h Thu Nov 28 15:53:15 2002
+++ linux-2.4.21-pre2/include/linux/sysctl.h Wed Dec 18 14:16:28 2002
@@ -124,6 +124,7 @@
KERN_CORE_USES_PID=3D52, /* int: use core or core.%pid *=
/
KERN_TAINTED=3D53, /* int: various kernel tainted flags */=
KERN_CADPID=3D54, /* int: PID of the process to notify on=
CAD */
+ KERNhttp://webmail.tiscali.be/mail/MessageCompose?sid=3DF39CE574C=
27DDBCF1206D1BB891159045C80B6DB&userid=3Djsoe0708@tiscali.be&seq=3DC&auth=
=3D3WR5O5FJOCJG1FDS&style=3Dfrans&abcompose=3D0
:: envoyer_CORE_PATTERN=3D56, /* string: pattern for core-files */
};
into linux-2.4.21-pre1-pa15/include/linux/sysctl.h
KERN_TAINTED=3D53, /* int: various kernel tainted flags */=
KERN_CADPID=3D54, /* int: PID of the process to notify on=
CAD */
KERN_HPPA_PWRSW=3D55, /* int: hppa soft-power enable */
KERN_HPPA_UNALIGNED=3D56, /* int: hppa unaligned-trap enable */
};
^^^^ same as new KERN_CORE_PATTERN
What should I to do?
Joel
*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be
^ permalink raw reply
* Re: [PATCH] zero-size E820 memory (kernel start-up failure)
From: Dave Jones @ 2002-12-20 12:54 UTC (permalink / raw)
To: xela; +Cc: hpa, linux-kernel
In-Reply-To: <3E02F8E1.70509@slit.de>
On Fri, Dec 20, 2002 at 12:02:57PM +0100, Alexander Achenbach wrote:
> Up to 2.4.20, a zero-size E820 memory region (eg 0xa0000 - 0xa0000)
> reported by the BIOS causes 'sanitize_e820_map' to take the end of this
> region as the start of another region, producing two overlapping regions
> extending to the end of addressable memory. If the zero-size region is of
> a higher type than 'usable RAM' (eg 'reserved'), this causes all memory
> above the zero-size region to be marked unusable (leaving 640k as of the
> above example -- the kernel fails to start at all).
>
> The patch adds code to remove empty entries before sorting regions. It
> was generated for a 2.4.20 kernel.
Looks good to me. Care to do a similar patch for 2.5 ?
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: PATCH 2.5.x disable BAR when sizing
From: Ivan Kokshaysky @ 2002-12-20 12:53 UTC (permalink / raw)
To: davidm; +Cc: Linus Torvalds, linux-kernel
In-Reply-To: <15874.58889.846488.868570@napali.hpl.hp.com>
On Fri, Dec 20, 2002 at 01:42:33AM -0800, David Mosberger wrote:
> If certain bridges cause
> problems, perhaps those need to be special-cased?
Couple of days ago I mindlessly suggested exactly that, but I
take it back.
Not only *all* classes of bridges would be special-cased:
turning off IO and MEM in the PCI command register disables the legacy I/O
ports and memory on some VGAs. Guess what happens if someone decides
to printk in the meantime.
Ivan.
^ permalink raw reply
* AW: Test program for raid
From: SCHEP. - Schepke, Arnt @ 2002-12-20 12:40 UTC (permalink / raw)
To: 'linux-raid@vger.kernel.org'
My RAID-Problems I described earlier in thread "SW-RAID 1 and kernel
2.4.18", started at 26.Nov 02.
We tested the computers with a shell script "stress.sh", which copies a
directory and compares the checksum. This happens in 50 threads at the same
time. My group tested the computers about 24h, another group in our company
tested 3 or more days. The computers of that group stopped working after 3
or 4 days. 2 Computers are probably killed by the tests, they don't start
anymore (no bios start after pressing start button).
Tests were run with 3 different disks (Maxtor, Seagate, IBM), 2 different
Mainboards (MSI with VIA chipset, Asus with Intel Chipset), with and without
removable frames, Red Hat 7, SuSE 7.3 and 8.0, always Filesystem Ext3
No errors in /var/log/messages were in the tests with DMA off (SuSE 7.3 with
Kernel 2.4.18, MSI board, IBM disks).
Errors:
- in /var/log/messages:
- BadCRC:
linux kernel: hdc: dma_intr: status=0x51 { DriveReady SeekComplete
Error }
linux kernel: hdc: dma_intr: error=0x84 { DriveStatusError BadCRC }
- DMA Timeout (on a test system without removable disk frames and on
the system with Red Hat7):
linux kernel: hda: timeout waiting for DMA
linux kernel: ide_dmaproc: chipset supported ide_dma_timeout func
only: 14
linux kernel: blk: queue c03564e4, I/O limit 4095Mb (mask
0xffffffff)
linux kernel: hda: status timeout: status=0xd0 { Busy }
linux kernel: hda: drive not ready for command
linux kernel: ide0: reset: success
- Drives are removed from RAID (especially uncool if it was the last Drive
in the Array)
- some Computers are always rebuilding the Array, after finishing the
rebuild it starts again.
- resync array after normal shutdown
- computer stops working (no error logs even on a mounted external drive)
Possible causes:
- maybe bad removable frames for HDDs (the DMA Error BadCRC was
- bad power supply, but ours should be a good one (300W, in Tests passed as
good)
- DMA errors in the kernel?
- SuSE found a bug in the kernel (SuSE specific), which causes problems
with more than one disk.
Regards
Arnt
by the way, I'm out of office because of this big party in some days. Back
for discussion in january.
-----Ursprüngliche Nachricht-----
Von: Gordon Henderson [mailto:gordon@drogon.net]
Gesendet am: Donnerstag, 19. Dezember 2002 13:13
An: SCHEP. - Schepke, Arnt
Cc: 'linux-raid@vger.kernel.org'
Betreff: Re: Test program for raid
On Thu, 19 Dec 2002, SCHEP. - Schepke, Arnt wrote:
> Hi,
> just a little question: I want to test my Software-RAID1 System.
> I have some errors and want something like a one year usage in a one day
> test.
What sort of errors?
> Do you have an idea what program to use?
It depends on what you want to test ...
To test the disk system, data paths and so on, I use 'bonnie' which is a
disk benchmark program. I run about 6 or 8 of them in a loop for several
days (if possible) before making a server go live. Running more than one
is obviously no use as a benchmark, but it does seem give it it good
thrashing. The trick is to not start them at the same time, but to stagger
them - that way you get a good mix of the different operations that Bonnie
performs.
I use this:
#!/bin/sh
# /usr/local/bin/dob
dobon & sleep 120 ; dobon & sleep 120
dobon & sleep 120 ; dobon & sleep 120
dobon & sleep 120 ; dobon & sleep 120
dobon & sleep 120 ; dobon & sleep 120
And:
#!/bin/csh
# /usr/local/bin/dobon
@ n = 1
while (1)
echo Pass number $n
bonnie -s1047 -n0 -u0
@ n++
end
You many have to alter the flags to bonnie depending on what version you
use (this is for bonnie++ as supplied with Debian 3)
Make sure the filesystem has enough disk space - this will require 8GB of
disk space...
I've managed to break an IBM server raid controller with this - so much
for RAID in hardware. IBM acknowledge the fault too and are supposed to be
working on it... Don't buy IBM, stick to software raid :)
However, I recently had a Linux (s/w raid + ext2) system which would run
this all night, but FAIL on FSCK... So after running this for some time,
stop it, then umount the filesystem and run several FSCKs on it. (The
failure reason was an AMD hardware fault - cured by plugging in a PS2
mouse and compiling the mouse driver back into the kernel)
Good luck!
Gordon
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" 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: What do you think, is compatible locking solvable at all?
From: Michal Samek @ 2002-12-20 12:35 UTC (permalink / raw)
To: Sergey Suleymanov; +Cc: Linux-MSDOS Mailing list
In-Reply-To: <87wum4oqph.fsf@eatpbank.ru>
On Pá, 2002-12-20 at 12:49, Sergey Suleymanov wrote:
>
> What about Bart's mfs64 patch? I remember it worked.
Unfortunatelly not for me. To be sure I've tested it again and I must
say for me it brokes things at all - I can see only the first record of
every .dbf table I open, on both smbfs and native linux mounts. Foxplus
is also confused opening it's resource file. I'm using 2.4.19 and
nothing special I guess. System is updated rh7.3. I wrote it some days
ago to this list but nobody replied.
--
Michal Samek <webmaster@tony.cz>
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" 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
* Next round of AGPGART fixes.
From: Dave Jones @ 2002-12-20 12:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel
Linus,
Please pull from bk://linux-dj.bkbits.net/agpgart to get at the
following fixes..
- AGP 3.0 now compiles as a module too.
- beginnings of VIA KT400 AGP 3.0 support.
(Not functional yet, more work needed).
- corrected handling of AGP capability bit in PCI headers for chipset drivers.
This should fix the problems on I815 and similar chipsets.
- small cleanups (making functions static, making things __initdata etc)
- Hopefully fix AMD K8 GART driver
- Fix module exit routine in backend
- Unmark some things __init (The cause of many modules bugs)
- agp_generic_agp_3_0_enable() now returns FALSE to the chipset driver
if it can't configure in 3.0 mode instead of falling back to
generic 2.0 routines.
- Export agp_generic_agp_3_0_enable() to work as module.
- Missing HP ZX1/Intel I460 fixes from David Mosberger (My bad)
- Changed I7505 driver to handle new agp_generic_agp_3_0_enable semantics.
- Renamed some VIA chipsets.
Makefile | 2
agp.h | 4 +
ali-agp.c | 21 +++++----
amd-k7-agp.c | 26 +++++------
amd-k8-agp.c | 18 +++++--
backend.c | 27 +++--------
frontend.c | 2
generic-3.0.c | 14 ++----
hp-agp.c | 18 +++----
i460-agp.c | 35 ++++++++-------
i7x05-agp.c | 32 +++++++------
intel-agp.c | 134 ++++++++++++++++++++++++++++------------------------------
sis-agp.c | 27 +++++------
sworks-agp.c | 59 ++++++++-----------------
via-agp.c | 99 +++++++++++++++++++++++++++++++++++-------
15 files changed, 283 insertions(+), 235 deletions(-)
GNU diff for those who care (against Linus' bk tree) is at
ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/2.5.52/agpgart-fixes-1.diff
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Walnut configuration (old problem)
From: llandre @ 2002-12-20 12:33 UTC (permalink / raw)
To: linuxppc-embedded
I've just start working with the Walnut board. I downloaded:
1) linuxppc_2_4 with rsync
2) linuxppc_2_4_devel with rsync
3) linuxppc_2_4_devel with bk
but in all cases I encountered the same problem described here
http://lists.linuxppc.org/linuxppc-embedded/200207/msg00005.html.
I followed the instructions proposed here
http://lists.linuxppc.org/linuxppc-embedded/200207/msg00006.html but this
didn't solve the problem.
Anybody can help me?
Thanks in advance,
llandre
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH] Fix CPU bitmask truncation
From: Andreas Schwab @ 2002-12-20 12:17 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: torvalds, linux-kernel, bjorn_helgaas
In-Reply-To: <20021220103028.GB9704@holomorphy.com>
William Lee Irwin III <wli@holomorphy.com> writes:
|> ===== include/linux/init_task.h 1.19 vs edited =====
|> --- 1.19/include/linux/init_task.h Sun Sep 29 07:02:55 2002
|> +++ edited/include/linux/init_task.h Fri Dec 20 02:22:04 2002
|> @@ -63,7 +63,7 @@
|> .prio = MAX_PRIO-20, \
|> .static_prio = MAX_PRIO-20, \
|> .policy = SCHED_NORMAL, \
|> - .cpus_allowed = -1, \
|> + .cpus_allowed = ~0UL, \
This is useless. Assigning -1 to any unsigned type is garanteed to give
you all bits one, and with two's complement this also holds for any signed
type.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Jamie Lokier @ 2002-12-20 12:06 UTC (permalink / raw)
To: Ulrich Drepper, Linus Torvalds
Cc: bart, davej, hpa, terje.eggestad, matti.aarnio, hugh, mingo,
linux-kernel
In-Reply-To: <3E02EC30.8030407@redhat.com>
This is a suggestion on a small performance improvement.
Ulrich Drepper wrote:
> int $0x80 -> call *%gs:0x18
The calling convention has been (slightly) changed - i.e. 6 argument
calls don't work, so why not go a bit further: allow the vsyscall entry
point to clobber more GPRs?
I see 3 pushes and pops in the vsyscall page (if I've looked at the
correct patch from Linus), to preserve %ecx, %edx and %ebp:
vsyscall:
pushl %ebp
pushl %ecx
pushl %edx
0:
movl %esp,%ebp
sysenter
jmp 0b
popl %edx
popl %ecx
popl %ebp
ret
The benefit is that this allows Glibc to do a wholesale replacement of
"int $0x80" -> "single call instruction". Otherwise, those pushes are
completely unnecessary. It could be this short instead:
vsyscall:
movl %esp,%ebp
sysenter
jmp vsyscall
ret
It is nice to be able to use the _exact_ same convention in glibc, for
getting a patch out of the door quickly. But it is just as easy to do
that putting the pushes and pops into the library itself:
Instead of
int $0x80 -> call *%gs:0x18
Write
int $0x80 -> pushl %ebp
pushl %ecx
pushl %edx
call *%gs:0x18
popl %edx
popl %ecx
popl %ebp
It has exactly the same cost as the current patches, but provides
userspace with more optimisation flexibility, using an asm clobber
list instead of explicit instructions for inline syscalls, etc.
Cheers,
-- Jamie
^ permalink raw reply
* 2.4.20-aa and LARGE Squid process -> SIGSEGV
From: Ralf Hildebrandt @ 2002-12-20 11:48 UTC (permalink / raw)
To: linux-kernel
Hi!
Right now we're trying to implement a large scale Squid proxy on
Debian/testing. We're using 2.4.20-aa and Squid-2.4.7-1.
We're encountering sporadic crashes of the squid children (SIGSEGV,
signal 11). We were investigating in several directions:
* the Kernel has highmem support enabled (we have 2GB RAM and 4 GB swap)
* we tried different kernels (with or without highmem support)
* we tried another squid version (Squid-2.4.6 from the "stable"
distribution of Debian)
* We recompiled Squid using gcc-3.2, since -- according to the FAQ --
squid may crash with signal 11 with optimization enabled when using
gcc-2.95.4 (Debian uses gcc-2.95.4, but still build squid using -O!)
* we closely observed dmesg, messages and syslog. No oddities were
found. Squid simply crashes.
* we tried both ufs and aufs as cache filesystems, since the FAQ tells
us the async I/O may have bugs.
* We use two identical machines -- the crash happens on both machines.
Same CPU, disks, RAM, manufacturer, heck -- even the same series!
To no avail -- Squid simply crashes from time to time. It's
impossible to predict when.
Then we wrote a program which allocates large amounts of memory:
--- snip ---
#include <stdlib.h>
#include <stdio.h>
main(){
char *buf;
long c;
FILE *fp;
fp = fopen("/dev/null","a");
while(1){
buf = (char *)malloc(100000000);
c = random();
if (c > 100000000)
continue;
fprintf(fp,"%c",buf[c]);
printf("hier\n");
}
}
--- snip ---
And we found that this program will be killed with a SIGSEGV as well.
So, what are we doing wrong? Since we have 2GB RAM and 4GB swap,
shouldn't the machine start to swap and execute the program above
successfully?
# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 2119065600 2111709184 7356416 0 299008 1438240768
Swap: 4293509120 0 4293509120
MemTotal: 2069400 kB
MemFree: 7184 kB
MemShared: 0 kB
Buffers: 292 kB
Cached: 1404532 kB
SwapCached: 0 kB
Active: 387796 kB
Inactive: 1317064 kB
HighTotal: 1703872 kB
HighFree: 2960 kB
LowTotal: 365528 kB
LowFree: 4224 kB
SwapTotal: 4192880 kB
SwapFree: 4192880 kB
BigFree: 0 kB
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.80GHz
stepping : 7
cpu MHz : 2785.629
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 5557.45
# cat /proc/swaps
Filename Type Size Used Priority
/dev/sda6 partition 2096440 0 -1
/dev/sda7 partition 2096440 0 -2
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
I've got the perfect system. I never need to do maintenance on it, or
software upgrades, patches, or anything. It's great. It never wakes me up,
or gets hacked into. It's completely perfect. That was the first step in
my plan to build the perfect Postfix system.
The second step is to plug it in.
^ permalink raw reply
* Re: What is the difference between modprobe and insmod?
From: Dharmendra.T @ 2002-12-20 11:50 UTC (permalink / raw)
To: bobo; +Cc: netfilter, bobowd
In-Reply-To: <20021220070647.BA0B01C959464@sm181.163.com>
The difference is that lsmod won't insert the dependent modules whereas
the modprobe does.
Dharmendra.T
Linux Security Expert
On Fri, 2002-12-20 at 12:41, bobo wrote:
>
>
> While writing IPtables scripts,there are two command: modprobe and insmod.
>
> In some example,some use : modprobe ip_tables,but others use: insmod ip_tables.
>
> Why? Is there difference between them?
>
>
> Thanks
>
>
^ permalink raw reply
* Re: What do you think, is compatible locking solvable at all?
From: Sergey Suleymanov @ 2002-12-20 11:49 UTC (permalink / raw)
To: Linux-MSDOS Mailing list
In-Reply-To: <1040377552.15559.0.camel@localhost.localdomain>
>>>>> Michal Samek writes:
Michal> Oh, I must say a bit more about it; I've mentioned samba
Michal> because it's the target environment but the problem really
Michal> starts somewhere between dosemu and linux fs
Michal> differrencies. Locking isn't working even on lredired linux
Michal> local ext2/3 fs for me and my clipper app, not only on smbfs
Michal> mounted lredired.
What about Bart's mfs64 patch? I remember it worked.
--
Sergey Suleymanov
^ permalink raw reply
* dosemu-1.1.4 compile error.
From: Michael @ 2002-12-20 11:43 UTC (permalink / raw)
To: linux-msdos
make[2]: Entering directory `/home/michael/stuff/progs/install/dosemu/dosemu-1.1.4/src/base/init'
bison -y -v -do parser.c parser.y
parser.y:1338.3-61: type clash (`' `i_value') on default action
make[2]: *** [parser.c] Error 1
make[2]: Leaving directory `/home/michael/stuff/progs/install/dosemu/dosemu-1.1.4/src/base/init'
make[1]: *** [base/init] Error 2
make[1]: Leaving directory `/home/michael/stuff/progs/install/dosemu/dosemu-1.1.4/src'
make: *** [default] Error 2
bison (GNU Bison) 1.50
gcc (GCC) 3.2.1
Thanks :P
^ permalink raw reply
* Re: ACCEPT/DROP
From: Thomas Heinz @ 2002-12-20 11:36 UTC (permalink / raw)
To: Venkatesh Prasad Ranganath; +Cc: netfilter, nf
In-Reply-To: <3E02F42E.3080306@cox.net>
Hi Venkatesh
You wrote:
> I was looking into the iptables implementation and was intrigued about
> how iptables would handle a situation in which we have identical rules
> except for their targets which are contradicting, say ACCEPT and DROP.
> By looking at ipt_do_table() function it seems that the first
> non-IPT_RETURN verdict from any standard target will end the traversal
> of a chain of a table, which seems to be a bit odd. First, such
> conflicting rules must not be allowed. Even beyond, this fails in the
> situation where you have a dropping rule added after an accepting rule.
You misunderstand the definition of conflicting rules in the context
of the packet classification problem. A conflict occurs if there are
two or more matching rules with the same minimal cost. Since the cost of
a rule is equivalent to its position in the chain[1] and the position is
unique there are no conflicts by definition.
This holds for both iptables and nf-hipac.
[1] at least if you're not using user-defined chains; but even if user-
defined chains come into play the costs are in fact unique
> For example, a packet from m.n.o.p to a.b.c.d would be accepted at
> a.b.c.d because of the first rule, although it had to be dropped
> according to the second rule. And this would result because of the
> order in which the rules are added to the table.
This behaviour is intended. The packet classification problem is about
finding the matching rule with minimal cost.
Thomas
^ permalink raw reply
* Re: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
From: William Lee Irwin III @ 2002-12-20 11:29 UTC (permalink / raw)
To: Christoph Hellwig, James Cleverdon, Pallipadi, Venkatesh,
Linux Kernel, Martin Bligh, John Stultz, Nakajima, Jun,
Mallick, Asit K, Saxena, Sunil, kevin.vanmaren
In-Reply-To: <20021220112401.GB7644@holomorphy.com>
On Thu, Dec 19, 2002 at 06:04:55PM -0800, James Cleverdon wrote:
>>> A generic patch should also support Unisys' new box, the ES7000 or
>>> some such.
On Fri, Dec 20, 2002 at 08:00:50AM +0000, Christoph Hellwig wrote:
>> That box needs more changes than just the apic setup. Unfortunately
>> unisys thinks they shouldn't send their patches to lkml, but when you see
>> them e.g. in the suse tree it's a bit understandable that they don't want
>> anyone to really see their mess :)
>> And btw, the box isn't that new, but three years ago or so when they first
>> showed it on cebit they even refused to talk about linux due to their
>> restrictive agreements with Microsoft..
On Fri, Dec 20, 2002 at 03:24:01AM -0800, William Lee Irwin III wrote:
> Kevin, you're the only lkml-posting contact point I know of within Unisys.
> Is there any chance you could flag down some of the ia32 crew there for
> some commentary on this stuff? (or do so yourself if you're in it)
Sorry for the meaningless post -- I forgot to add Kevin to the cc: list.
Bill
^ permalink raw reply
* Re: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
From: William Lee Irwin III @ 2002-12-20 11:24 UTC (permalink / raw)
To: Christoph Hellwig, James Cleverdon, Pallipadi, Venkatesh,
Linux Kernel, Martin Bligh, John Stultz, Nakajima, Jun,
Mallick, Asit K, Saxena, Sunil
In-Reply-To: <20021220080050.A23184@infradead.org>
On Thu, Dec 19, 2002 at 06:04:55PM -0800, James Cleverdon wrote:
>> A generic patch should also support Unisys' new box, the ES7000 or
>> some such.
On Fri, Dec 20, 2002 at 08:00:50AM +0000, Christoph Hellwig wrote:
> That box needs more changes than just the apic setup. Unfortunately
> unisys thinks they shouldn't send their patches to lkml, but when you see
> them e.g. in the suse tree it's a bit understandable that they don't want
> anyone to really see their mess :)
> And btw, the box isn't that new, but three years ago or so when they first
> showed it on cebit they even refused to talk about linux due to their
> restrictive agreements with Microsoft..
Kevin, you're the only lkml-posting contact point I know of within Unisys.
Is there any chance you could flag down some of the ia32 crew there for
some commentary on this stuff? (or do so yourself if you're in it)
Thanks,
Bill
^ permalink raw reply
* Re: shared pagetable benchmarking
From: William Lee Irwin III @ 2002-12-20 11:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: Dave McCracken, linux-mm
In-Reply-To: <3E02FACD.5B300794@digeo.com>
On Fri, Dec 20, 2002 at 03:11:09AM -0800, Andrew Morton wrote:
> Did a bit of timing and profiling. It's a uniprocessor
> kernel, 7G, PAE.
> The workload is application and removal of ~80 patches using
> my patch scripts. Tons and tons of forks from bash.
> 2.5 ends up being 13% slower than 2.4, after disabling highpte
> to make it fair. 3%-odd of this is HZ=1000. So say 10%.
> Pagetable sharing actually slowed this test down by several
> percent overall. Which is unfortunate, because the main
> thing which Linus likes about shared pagetables is that it
> "speeds up forks".
> Is there anything we can do to fix all of this up a bit?
For testing purposes, try removing the opportunistic mmap()-time
sharing.
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ 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.