[PATCH] ipt_TOS fix.

[Rusty Russell]

Linus, please apply v2.4.0.

ipt_TOS checksum calculations were completely broken, causing bad csum
packets.  Whoever implemented it didn't understand the code it was
copied from.

This fixes the problem (tested in userspace against all TOS changes).

Rusty.
--
Premature optmztion is rt of all evl. --DK

diff -urN -I \$.*\$ -X /tmp/kerndiff.ZtZl97 --minimal 
linux-2.4.0-official/net/ipv4/netfilter/ipt_TOS.c 
working-2.4.0/net/ipv4/netfilter/ipt_TOS.c
--- linux-2.4.0-official/net/ipv4/netfilter/ipt_TOS.c   Fri Apr 28 08:43:15 2000
+++ working-2.4.0/net/ipv4/netfilter/ipt_TOS.c  Mon Jan 29 18:40:37 2001
@@ -19,11 +19,11 @@
const struct ipt_tos_target_info *tosinfo = targinfo;
 
if ((iph->tos & IPTOS_TOS_MASK) != tosinfo->tos) {
-   u_int8_t diffs[2];
+   u_int16_t diffs[2];
 
-   diffs[0] = iph->tos;
+   diffs[0] = htons(iph->tos) ^ 0x;
iph->tos = (iph->tos & IPTOS_PREC_MASK) | tosinfo->tos;
-   diffs[1] = iph->tos;
+   diffs[1] = htons(iph->tos);
iph->check = csum_fold(csum_partial((char *)diffs,
sizeof(diffs),
iph->check^0x));
-
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: PCI IRQ routing problem in 2.4.0

[Linus Torvalds]

On Mon, 29 Jan 2001, Robert Siemer wrote:
> 
> Further I always see '09' in the Configuration Space at Interrupt_Line
> (0x3c) for the 00:01.2 USB Controller. But 2.4.0 says:
>   Interrupt: pin A routed to IRQ 12
> while 2.4.0-test9 states:
>   Interrupt: pin A routed to IRQ 9

Ahhah!

I bet it's the code that goes through all PCI devices, and tries to find
devices that have the same "pirq" (aka "link") value in the tables.

How about this patch? I bet that you'll get a message about pirq table
conflicts. Does USB end up working afterwards?

Linus


--- v2.4.0/linux/arch/i386/kernel/pci-irq.c Wed Jan  3 20:45:26 2001
+++ linux/arch/i386/kernel/pci-irq.cSun Jan 28 23:36:48 2001
@@ -462,18 +462,9 @@
irq = pirq & 0xf;
DBG(" -> hardcoded IRQ %d\n", irq);
msg = "Hardcoded";
-   if (dev->irq && dev->irq != irq) {
-   printk("IRQ routing conflict in pirq table! Try 
'pci=autoirq'\n");
-   return 0;
-   }
} else if (r->get && (irq = r->get(pirq_router_dev, dev, pirq))) {
DBG(" -> got IRQ %d\n", irq);
msg = "Found";
-   /* We refuse to override the dev->irq information. Give a warning! */
-   if (dev->irq && dev->irq != irq) {
-   printk("IRQ routing conflict in pirq table! Try 
'pci=autoirq'\n");
-   return 0;
-   }
} else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
DBG(" -> assigning IRQ %d", newirq);
if (r->set(pirq_router_dev, dev, pirq, newirq)) {
@@ -504,6 +495,11 @@
if (!info)
continue;
if (info->irq[pin].link == pirq) {
+   /* We refuse to override the dev->irq information. Give a 
+warning! */
+   if (dev2->irq && dev2->irq != irq) {
+   printk("IRQ routing conflict in pirq table for device 
+%s\n", dev2->slot_name);
+   continue;
+   }
dev2->irq = irq;
pirq_penalty[irq]++;
if (dev != dev2)

-
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: ECN: Clearing the air (fwd)

[David S. Miller]

James Sutherland writes:
 > Except you can detect and deal with these "PMTU black holes". Just as you
 > should detect and deal with ECN black holes. Maybe an ideal Internet
 > wouldn't have them, but this one does. If you can find an ideal Internet,
 > go code for it: until then, stick with the real one. It's all we've got.

Guess what, Linux works not around PMTU black holes either for the
same exact reason we will not work around ECN.

I'm getting a bit tired of you, and I suppose others are as
well.  You are being nothing but a pompous ass.

Anyways, let me quote a comment from the Linux source code where
we would have done PMTU black hole detection:

/* NOTE. draft-ietf-tcpimpl-pmtud-01.txt requires pmtu black
   hole detection. :-(

   It is place to make it. It is not made. I do not want
   to make it. It is disguisting. It does not work in any
   case. Let me to cite the same draft, which requires for
   us to implement this:

   "The one security concern raised by this memo is that ICMP black holes
   are often caused by over-zealous security administrators who block
   all ICMP messages.  It is vitally important that those who design and
   deploy security systems understand the impact of strict filtering on
   upper-layer protocols.  The safest web site in the world is worthless
   if most TCP implementations cannot transfer data from it.  It would
   be far nicer to have all of the black holes fixed rather than fixing
   all of the TCP implementations."

   Golden words :-).
   */

Later,
David S. Miller
[EMAIL PROTECTED]
-
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: PCI IRQ routing problem in 2.4.0 (SiS results part 2)

[Linus Torvalds]

On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
> | Which one was it you got a PIRQ conflict for before? as it te device at
> | 00:01.00 with the strange "0x62" entry?
> 
> Yes.

You've got the pirq setup from hell.

Mind doing that "dump_pirq" thing, preferably run on an _unmodified_ 2.4.0
kernel (ie none of my test-hacks) or on a 2.2.x kernel (that doesn't even
_try_ to do any routing at all - or you can get the same effect by just
making "set_sis_pirq()" always just return 0 without doing anything)?

I don't want to get quantum effects of the observer changing what is being
observed..

> | How about you try adding the line
> | pirq = (pirq-1) & 3;
> | at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
> | SiS routines). What happens then?
> 
> Done.

Not any better. The thing just moves around, it seems.

I'll think about this, and try to find the SiS irq routing register spec
somewhere..

Linus

-
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: ECN: Clearing the air (fwd)

[David S. Miller]

David Lang writes:
 > I am behind a raptor firewall and ran the test that David M posted a
 > couple days ago and was able to sucessfully connect to his test machine.
 > 
 > so either raptor tolorates ECN (at least in the verion I am running) or
 > the test was not valid.

Did you actually list a directory or something and make
sure my workstation made a new connection _back_ to you?

If you are using passive FTP and/or did not do a directory
listing, you did the test incorrectly.  The directory listing
is what will test the ECN'ness of your local firewall.

Later,
David S. Miller
[EMAIL PROTECTED]
-
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: Renaming lost+found

[Andreas Dilger]

H. Peter Anvin writes:
> Hello people... the original question was: can lost+found be
> *renamed*, i.e. does the tools (e2fsck ) use "/lost+found" by name,
> or by inode?  As far as I know it always uses the same inode number
> (11), but I don't know if that is anywhere enforced.

Bzzt.  /lost+found just happens to use inode 11 on 99.9% of filesystems
because it is the first inode available when mke2fs is creating the
filesystem.  If you check , it has:

#define EXT2_GOOD_OLD_FIRST_INO 11

It is perfectly acceptable to delete lost+found, and create it again
with mklost+found, and chances are it will have a different inode...
Just tested it, and sure enough, I got inode 612 for lost+found this time.
I'm pretty sure that e2fsck looks for the name /lost+found, rather than
inode 11.

This means that with stock e2fsck, mke2fs, mklost+found, you can't rename
lost+found and expect anything to work.  However, I would imagine it isn't
_too_ hard to change these tools to create a different directory, and for
e2fsck to look for the standard or the new directory to put nameless inodes.

Looking at the e2fsck source, there only appears to be a single instance of
the string "lost+found", in e2fsck/pass3.c:get_lost_and_found():

static const char name[] = "lost+found";

Same with misc/mke2fs.c:create_lost_and_found() and misc/mklost+found.

Cheers, Andreas

PS - don't blame me if you never find your files after a bad crash.  At
 least when it is called "lost+found" you occasionally have a look
 in there.
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
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: PCI IRQ routing problem in 2.4.0

[Robert Siemer]

From: Linus Torvalds <[EMAIL PROTECTED]>
> On Mon, 29 Jan 2001, Robert Siemer wrote:
> > > 
> > > and see if that changes the behaviour. 
> > 
> > It doesn't.   A diff from the kernel output is following. Maybe it
> > helps...
> 
> Actually, this looks like it _did_ fix something - now the kernel no
> longer thinks there is a IRQ routing conflict, so it does seem to be
> happier.
> 
> Also, while you're unhappy that it assigns irq 12 instead of 9, the pirq
> table actually says that it's ok, and again the code seems to say that
> this was actually what the system was set up for.

I'm not just unhappy to be unable to control the IRQs with the bios
anymore, sym53c8xx doesn't want to share IRQs with the usb
subsystem in this case... (kernel panic (killing interrupt handler(?))
and reboot (rebooting in 60 seconds))

2.4.0-test9 behaviour was different. It really used what the 'bios
box' stated during bootup. - A way to set the IRQ distribution via
kernel-params is okay for me, too.

> Can you re-iterate what the failure mode is, again? Preferable with
> this kernel that definitely looks like it at least agrees with what
> the BIOS tells it.

I'm native German - what is 'failure mode'?

2.4.0-test9 agrees with the bios. [Currently I gave my VGA card (the
S3) an IRQ - without one in the bios 2.4.0-test9 was happy, but 2.4.0
gave it IRQ 8 on its own.]

> Oh, and please do a "lspci -vvvxxx" as root and send me that as
> well.

Okay. For 2.4.0-test9 it's following immediately. After that a
diff of "lspci -vvx" from 2.4.0-test9 to 2.4.0 is included.

Full "lspci -vvx" are in my original post:
http://boudicca.tux.org/hypermail/linux-kernel/latest/0130.html

To mention it: I have also an ASUS SP97 like Aaron Tiensivu. But the
XV version with (unused) onboard VGA.

Further I always see '09' in the Configuration Space at Interrupt_Line
(0x3c) for the 00:01.2 USB Controller. But 2.4.0 says:
  Interrupt: pin A routed to IRQ 12
while 2.4.0-test9 states:
  Interrupt: pin A routed to IRQ 9

Please tell me if it helps te see a "lspci -vvvxxx" from 2.4.0 and
whether I should give some 2.4.0-test?? a try...
I must go to bed now - otherwise my mother kills me when she reads
linux-kernel tomorrow... (-:


00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5597 [SiS5582] (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Region 1: I/O ports at 
Region 2: I/O ports at 
Region 3: I/O ports at 
Region 4: I/O ports at d000 [size=16]
00: 39 10 13 55 01 00 00 00 d0 8f 01 01 00 20 80 00
10: 01 e4 00 00 01 e0 00 00 01 d8 00 00 01 d4 00 00
20: 01 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0c 01 00 00
40: 00 00 00 00 00 00 00 00 00 07 e0 00 00 02 00 02
50: 00 01 07 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 10) (prog-if 10 
[OHCI])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-  [disabled] [size=64K]
00: 33 53 f0 88 83 00 00 02 00 00 00 03 00 00 00 00
10: 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0e 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 03)
Subsystem: Tekram Technology Co.,Ltd. DC390F Ultra Wide SCSI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium 

Re: PCI IRQ routing problem in 2.4.0 (SiS results part 2)

[Aaron Tiensivu]

| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?

Yes.

| How about you try adding the line
| pirq = (pirq-1) & 3;
| at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
| SiS routines). What happens then?

Done.

Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3
20010125 (prerelease)) #4 Mon Jan 29 01:53:12 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 000a @  (usable)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 03efd000 @ 0010 (usable)
 BIOS-e820: 2000 @ 03ffd000 (ACPI data)
 BIOS-e820: 1000 @ 03fff000 (ACPI NVS)
 BIOS-e820: 0001 @  (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c000 for 4096 bytes.
On node 0 totalpages: 16381
zone(0): 4096 pages.
zone(1): 12285 pages.
zone(2): 0 pages.
APIC turned off by hardware.
mapped APIC to e000 (01112000)
Kernel command line: auto BOOT_IMAGE=lnew ro root=341
BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage
Initializing CPU#0
Detected 374.227 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 747.11 BogoMIPS
Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k
data, 188k init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
VFS: Diskquotas version dquot_6.5.0 initialized
CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008021bf 808029bf  0002
CPU: After generic, caps: 008021bf 808029bf  0002
CPU: Common caps: 008021bf 808029bf  0002
CPU: AMD-K6(tm) 3D processor stepping 0c
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: AMD K6
PCI: BIOS32 Service Directory structure at 0xc00f9b50
PCI: BIOS32 Service Directory entry at 0xf04d0
PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00
PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Setting max latency to 32
PCI: IDE base address trash cleared for 00:01.1
PCI: IDE base address fixup for 00:01.1
PCI: Scanning for ghost devices on bus 0
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00f0af0
00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8
00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8
00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8
00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/
00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
PCI: IRQ fixup
PCI: Allocating resources
PCI: Resource d000-d00f (f=101, d=0, p=0)
PCI: Resource dd00-dd000fff (f=200, d=0, p=0)
PCI: Resource b800-b807 (f=101, d=0, p=0)
PCI: Resource dc80-dc87 (f=200, d=0, p=0)
PCI: Resource e000-e7ff (f=1208, d=0, p=0)
PCI: Resource df00-df000fff (f=1208, d=0, p=0)
PCI: Resource b400-b41f (f=101, d=0, p=0)
PCI: Resource dc00-dc0f (f=200, d=0, p=0)
PCI: Resource de00-de3f (f=1208, d=1, p=1)
PCI: Resource db80-db80 (f=200, d=1, p=1)
PCI: Resource b000-b07f (f=101, d=1, p=1)
PCI: Sorting device list...
Disabling direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 41341kB/31006kB, 128 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 09
IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl  -> newirq=10 -> got IRQ
10
PCI: Found IRQ 10 for device 00:01.1
PCI: The same IRQ used for device 00:01.2
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS5597
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
hda: ST5660A, ATA DISK drive
hdb: IBM-DJAA-31700, ATA DISK drive
hdc: Maxtor 72700 AP, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 1066184 sectors (546 MB) w/256KiB 

Re: PCI IRQ routing problem in 2.4.0 (SiS results part 2)

[Aaron Tiensivu]

| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?

Yes.

| How about you try adding the line
| pirq = (pirq-1) & 3;
| at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
| SiS routines). What happens then?

Done.

Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3
20010125 (prerelease)) #4 Mon Jan 29 01:53:12 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 000a @  (usable)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 03efd000 @ 0010 (usable)
 BIOS-e820: 2000 @ 03ffd000 (ACPI data)
 BIOS-e820: 1000 @ 03fff000 (ACPI NVS)
 BIOS-e820: 0001 @  (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c000 for 4096 bytes.
On node 0 totalpages: 16381
zone(0): 4096 pages.
zone(1): 12285 pages.
zone(2): 0 pages.
APIC turned off by hardware.
mapped APIC to e000 (01112000)
Kernel command line: auto BOOT_IMAGE=lnew ro root=341
BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage
Initializing CPU#0
Detected 374.227 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 747.11 BogoMIPS
Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k
data, 188k init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
VFS: Diskquotas version dquot_6.5.0 initialized
CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008021bf 808029bf  0002
CPU: After generic, caps: 008021bf 808029bf  0002
CPU: Common caps: 008021bf 808029bf  0002
CPU: AMD-K6(tm) 3D processor stepping 0c
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: AMD K6
PCI: BIOS32 Service Directory structure at 0xc00f9b50
PCI: BIOS32 Service Directory entry at 0xf04d0
PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00
PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Setting max latency to 32
PCI: IDE base address trash cleared for 00:01.1
PCI: IDE base address fixup for 00:01.1
PCI: Scanning for ghost devices on bus 0
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00f0af0
00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8
00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8
00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8
00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/
00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
PCI: IRQ fixup
PCI: Allocating resources
PCI: Resource d000-d00f (f=101, d=0, p=0)
PCI: Resource dd00-dd000fff (f=200, d=0, p=0)
PCI: Resource b800-b807 (f=101, d=0, p=0)
PCI: Resource dc80-dc87 (f=200, d=0, p=0)
PCI: Resource e000-e7ff (f=1208, d=0, p=0)
PCI: Resource df00-df000fff (f=1208, d=0, p=0)
PCI: Resource b400-b41f (f=101, d=0, p=0)
PCI: Resource dc00-dc0f (f=200, d=0, p=0)
PCI: Resource de00-de3f (f=1208, d=1, p=1)
PCI: Resource db80-db80 (f=200, d=1, p=1)
PCI: Resource b000-b07f (f=101, d=1, p=1)
PCI: Sorting device list...
Disabling direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 41341kB/31006kB, 128 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 09
IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl  -> newirq=10 -> got IRQ
10
PCI: Found IRQ 10 for device 00:01.1
PCI: The same IRQ used for device 00:01.2
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS5597
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
hda: ST5660A, ATA DISK drive
hdb: IBM-DJAA-31700, ATA DISK drive
hdc: Maxtor 72700 AP, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 1066184 sectors (546 MB) w/256KiB 

Re: Renaming lost+found

[Mike Galbraith]

On Sun, 28 Jan 2001, Mo McKinlay wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Today, H. Peter Anvin ([EMAIL PROTECTED]) wrote:
> 
>   > Hello people... the original question was: can lost+found be
>   > *renamed*, i.e. does the tools (e2fsck ) use "/lost+found" by name,
>   > or by inode?  As far as I know it always uses the same inode number
>   > (11), but I don't know if that is anywhere enforced.
> 
> I seem to recall e2fsck complaining when I renamed lost+found, but that
> may well be a consistency check. Don't quote me on this, though.

(pretty easy to find out:)

[root]:# fsck -f /test
Parallelizing fsck version 1.19 (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create?

It created lost+found with inode 183 as 11 was used by renamed dir.
No idea if it would have trouble salvaging a corrupt fs after this.
(but logic says no it dare not)

-Mike

-
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.4.1-pre11 remove pcmcia compatibility from Makefile

[Keith Owens]

The _modinst_post_pcmcia target was added to Makefile in 2.4.0-test6-pre3,
August 5 2000.  It was a compatibility aid until people upgraded to a
version of pcmcia-cs that used modprobe instead of insmod.  Five months
later, it is time to remove _modinst_post_pcmcia.

Linus, please apply at any convenient time, no hurry.


Index: 1-pre11.1/Makefile
--- 1-pre11.1/Makefile Mon, 29 Jan 2001 10:00:50 +1100 kaos (linux-2.4/T/c/50_Makefile 
1.1.2.10 644)
+++ 1-pre11.1(w)/Makefile Mon, 29 Jan 2001 17:10:07 +1100 kaos 
+(linux-2.4/T/c/50_Makefile 1.1.2.10 644)
@@ -372,17 +372,8 @@ else
 depmod_opts:= -b $(INSTALL_MOD_PATH) -r
 endif
 .PHONY: _modinst_post
-_modinst_post: _modinst_post_pcmcia
+_modinst_post:
if [ -r System.map ]; then $(DEPMOD) -ae -F System.map $(depmod_opts) 
$(KERNELRELEASE); fi
-
-# Backwards compatibilty symlinks for people still using old versions
-# of pcmcia-cs with hard coded pathnames on insmod.  Remove
-# _modinst_post_pcmcia for kernel 2.4.1.
-.PHONY: _modinst_post_pcmcia
-_modinst_post_pcmcia:
-   cd $(MODLIB); \
-   mkdir -p pcmcia; \
-   find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
 
 .PHONY: $(patsubst %, _modinst_%, $(SUBDIRS))
 $(patsubst %, _modinst_%, $(SUBDIRS)) :

-
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.4.0 Networking oddity

[Daniel Walton]

The server in question is running the tulip driver.  dmesg reports:

Linux Tulip driver version 0.9.13 (January 2, 2001)

I have seen this same behavior on a couple of my servers running 3com 
3c905c adaptors as well.

The last time I was experiencing it I rebooted the system and it didn't 
solve the problem.  When it came up it was still lagging.  This would lead 
me to believe that it is caused by some sort of network condition, but what 
I don't know.

If anyone has ideas, I'd be more than happy to run tests/provide more info..

-Dan



At 10:14 PM 1/28/2001 -0500, you wrote:
>In mailing-lists.linux-kernel, you wrote:
>
> >I am running a web server under the new 2.4.0 kernel and am experiencing
> >some intermittent odd behavior from the kernel.  The machine will sometimes
> >go through cycles where network response becomes slow even though top
> >reports over 60% idle CPU time.   When this is happening ping goes from
> >reasonable response times to response times of several seconds in cycles of
> >about 15 to 20 seconds.
>
>FWIW, I have seen behaviour like this under kernel 2.2.x and 2.4.x,
>for me taking the interface down and then bringing it back up usually
>makes the problem stop, at least for the moment.
>
>I have always assumed that it is caused by a bug in the Ethernet card
>driver, as the first time I noticed this behaviour, I was using the
>Realtek 8139 driver about two years ago, it was really not good
>hardware and the driver was pretty new.  Anyway, it would do this, so
>I contacted Donald Becker about it, he pointed me to a newer version
>of the driver that did it _much_ less often.
>
>Cheers,
>Wayne

-
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: PCI IRQ routing problem in 2.4.0

[Linus Torvalds]

On Mon, 29 Jan 2001, Robert Siemer wrote:
> > 
> > and see if that changes the behaviour. 
> 
> It doesn't.   A diff from the kernel output is following. Maybe it
> helps...

Actually, this looks like it _did_ fix something - now the kernel no
longer thinks there is a IRQ routing conflict, so it does seem to be
happier.

Also, while you're unhappy that it assigns irq 12 instead of 9, the pirq
table actually says that it's ok, and again the code seems to say that
this was actually what the system was set up for.

Can you re-iterate what the failure mode is, again? Preferable with this
kernel that definitely looks like it at least agrees with what the BIOS
tells it.

Oh, and please do a "lspci -vvvxxx" as root and send me that as well.

Thanks,

Linus

-
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.4.0 Networking oddity

[Wayne Whitney]

In mailing-lists.linux-kernel, you wrote:

>I am running a web server under the new 2.4.0 kernel and am experiencing 
>some intermittent odd behavior from the kernel.  The machine will sometimes 
>go through cycles where network response becomes slow even though top 
>reports over 60% idle CPU time.   When this is happening ping goes from 
>reasonable response times to response times of several seconds in cycles of 
>about 15 to 20 seconds.

FWIW, I have seen behaviour like this under kernel 2.2.x and 2.4.x,
for me taking the interface down and then bringing it back up usually
makes the problem stop, at least for the moment.

I have always assumed that it is caused by a bug in the Ethernet card
driver, as the first time I noticed this behaviour, I was using the
Realtek 8139 driver about two years ago, it was really not good
hardware and the driver was pretty new.  Anyway, it would do this, so
I contacted Donald Becker about it, he pointed me to a newer version
of the driver that did it _much_ less often.

Cheers,
Wayne

-
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: PCI IRQ routing problem in 2.4.0

[Robert Siemer]

From: Linus Torvalds <[EMAIL PROTECTED]>
> On Mon, 29 Jan 2001, Robert Siemer wrote:

> (...) that's really interesting..
> 
> > Device 00:01.0 (slot 0): ISA bridge
> >   INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> >   INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> >   INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> >   INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> 
> Your "link" values are in the range 1-4. Which makes perfect sense, but
> that's absolutely _not_ what the Linux SiS routing code expects (the code 
> seems to expect them to be ASCII 'A' - 'D').
> 
> It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
> arch/i386/kernel/pci-irq.c are broken for your setup.
> 
> Can you replace them with the following:
> 
>   static int pirq_sis_get(struct pci_dev *router, struct pci_dev *dev, int pirq)
>   {
>   if (pirq <= 4) {
>   u8 x;
>   pci_read_config_byte(router, 0x40+pirq, );
>   return (x & 0x80) ? 0 : (x & 0xf);
>   }
>   printk("Unknown SiS pirq value %d\n", pirq);
>   return 0;
>   }
> 
> and
> 
>   static int pirq_sis_set(struct pci_dev *router, struct pci_dev *dev, int pirq, 
>int irq)
>   {
>   if (pirq <= 4) {
>   pci_write_config_byte(router, 0x40 + pirq, irq);
>   return 1;
>   }
>   printk("Unknown SiS pirq value %d\n", pirq);
>   return 0;
>   }
> 
> and see if that changes the behaviour. 

It doesn't.   A diff from the kernel output is following. Maybe it
helps...

Thanks,
Robert


--- dmesg.2.4.0.debug   Sun Jan 28 21:09:46 2001
+++ dmesg.2.4.0 Mon Jan 29 06:25:53 2001
@@ -1,4 +1,4 @@
-Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
19990314/Linux (egcs-1.1.2 release)) #4 Sun Jan 28 19:03:05 CET 2001
+Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 
+19990314/Linux (egcs-1.1.2 release)) #5 Mon Jan 29 06:19:16 CET 2001
 BIOS-provided physical RAM map:
  BIOS-e820: 0009fc00 @  (usable)
  BIOS-e820: 0400 @ 0009fc00 (reserved)
@@ -231,8 +231,9 @@
 bttv: using 2 buffers with 2080k (4160k total) for capture
 BT848 and your chipset may not work together.
 bttv: Bt8xx card found (0).
-IRQ for 00:09.0:0 -> PIRQ 04, mask 1eb8, excl  -> newirq=11 -> got IRQ 7
-IRQ routing conflict in pirq table! Try 'pci=autoirq'
+IRQ for 00:09.0:0 -> PIRQ 04, mask 1eb8, excl  -> newirq=11 -> got IRQ 11
+PCI: Found IRQ 11 for device 00:09.0
+PCI: The same IRQ used for device 00:09.1
 bttv0: Bt878 (rev 2) at 00:09.0, irq: 11, latency: 32, memory: 0xe780
 bttv0: subsystem: 0070:13eb  =>  Hauppauge WinTV  =>  card=10
 bttv0: model: BT878(Hauppauge new (bt878)) [autodetected]
@@ -278,8 +279,8 @@
 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
 SIS5513: IDE controller on PCI bus 00 dev 09
 PCI: Enabling device 00:01.1 ( -> 0001)
-IRQ for 00:01.1:0 -> PIRQ 01, mask 1eb8, excl  -> newirq=12 -> assigning IRQ 12 
... OK
-PCI: Assigned IRQ 12 for device 00:01.1
+IRQ for 00:01.1:0 -> PIRQ 01, mask 1eb8, excl  -> newirq=12 -> got IRQ 12
+PCI: Found IRQ 12 for device 00:01.1
 PCI: The same IRQ used for device 00:01.2
 PCI: The same IRQ used for device 00:0c.0
 SIS5513: chipset revision 208
-
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: PCI IRQ routing problem in 2.4.0

[Linus Torvalds]

On Sun, 28 Jan 2001, Tim Hockin wrote:
> 
> In reading the PIRQ specs, and making it work for our board, I thought
> about this.  PIRQ states that link is chipset-dependant.  No chipset that I
> have seen specifies what link should be.  So, as this case demonstrates, it
> may be 'A' - the value the chipset expects, or 1, the logical index.
> Either one makes sense, assuming the PIRQ routing code knows what link
> means.  Here we see two BIOS vendors/versions that apparently do it
> differently for the same chipset.Grrr.

They _may_ do the same thing for the same chipset, it's just that we don't
know exactly what that "same" thing is.

Ok, I want to see what people have. ANYBODY who has a SiS chipset, please
take 5 seconds to do this as root (yes, you need to be root):

dump_pirq | mail -s "dump_pirq" [EMAIL PROTECTED]

and I'm attaching the "dump_pirq" perl script here in this email so that
you don't even have to go to the bother of finding it on the net.

Oh, before you bombard me with email, please check that dump_pirq actually
prints out a PIRQ table. If it says

No PCI interrupt routing table was found.

followed by a router dump, it's not interesting, and I'd rather not get
a million of those particular emails, ok?

In fact, even if you don't have a SiS chipset, you could do the above. The
exception to that rule is if you have an Intel PIIX router, in which case
we pretty much _know_ that we do the right thing already. 

(And _please_ don't make the subject line anything fancy. I want that
subject line to be "dump_pirq" and nothing else, ok?)

Linus


#!/usr/bin/perl
#
# dump_pirq 1.20 2000/12/19 19:19:52
#
# A utility to parse the BIOS PCI IRQ Routing Table
#
# Copyright (C) 2000 David A. Hinds -- [EMAIL PROTECTED]
#

#---

sub dev {
my($devfn) = @_;
sprintf "%02x.%d", ($devfn>>3), ($devfn&7);
}

sub print_mask
{
my($mask) = @_;
printf "0x%04x [", $mask;
for (my $i = 0; $i < 16; $i++) {
next if (!($mask & (1<<$i)));
$mask &= ~(1<<$i);
print (($mask) ? "$i," : "$i");
}
print "]\n";
}

sub row {
my($tag, $link, $mask) = @_;
if ($link != 0) {
printf "  INT$tag: link 0x%02x, irq mask ", $link;
print_mask($mask);
}
}

sub class_of
{
my($slot) = @_;
open(IN, "/sbin/lspci -s $slot |");
$_ = ;
close(IN);
return (/^... ([^:]+):/) ? $1 : "";
}

sub parse_pirq
{
my($buf) = @_;

my($p) = index($buf, "\$PIR");
my($minor,$major,$size,$rbus,$rdev,$mask,$cvd,$mini) =
unpack "CCSCCSLL", substr($buf, $p+4, 16);

printf "Interrupt routing table found at address 0xf%04x:\n", $p;
printf "  Version $major.$minor, size 0x%04x\n", $size;
printf "  Interrupt router is device %02x:%s\n", $rbus, dev($rdev);
print "  PCI exclusive interrupt mask: ";
print_mask($mask);
if ($cvd) {
printf("  Compatible router: vendor 0x%04x device 0x%04x\n",
   ($cvd & 0x), ($cvd >> 16));
}

$ofs = 32;
while ($ofs < $size) {
# Parse a table entry describing a single PCI device
($bus, $devfn, $la, $ma, $lb, $mb, $lc, $mc, $ld, $md, $slot) =
unpack "CCCSCSCSCSC", substr($buf, $p+$ofs, 15);
$s = sprintf "%02x:%s", $bus, dev($devfn);
printf "\nDevice $s (slot $slot): %s\n", class_of($s);
row("A", $la, $ma); row("B", $lb, $mb);
row("C", $lc, $mc); row("D", $ld, $md);
push(@{$dev{$la}}, $s . "1");
push(@{$dev{$lb}}, $s . "2");
push(@{$dev{$lc}}, $s . "3");
push(@{$dev{$ld}}, $s . "4");
$ofs += 16;
}
return ($rbus, $rdev, $cvd);
}

#---

# The link values in the interrupt routing table are implementation
# dependent.  Here, we'll try to interpret the link values for some
# known PCI bridge types.

%pIIx = (0x122e8086, "82371FB PIIX",
 0x70008086, "82371SB PIIX3",
 0x71108086, "82371AB PIIX4/PIIX4E",
 0x71988086, "82443MX",
 0x24108086, "82801AA ICH",
 0x24208086, "82801AB ICH0",
 0x24408086, "82801BA ICH2",
 0x244c8086, "82801BAM ICH2-M");

%via = (0x05861106, "82C586",
0x05961106, "82C596",
0x06861106, "82C686");

%opti = (0xc7001045, "82C700");

%pico = (0x00021066, "PT86C523");

%ali = (0x153310b9, "Aladdin M1533");

%sis = (0x04961039, "85C496/497",
0x00081039, "85C503");

%cyrix = (0x01001078, "5530");

%all_routers = (%pIIx, %via, %opti, %pico, %ali, %sis, %cyrix);

sub outb
{
my($data,$port) = @_;
open(IO, ">/dev/port") || die;
sysseek(IO, $port, 0) || die;
my $x = pack "C", $data;
syswrite(IO, $x, 1);
close(IO);
}

sub inb
{
my($port) = @_;
my($data);
 

[PROBLEM?] PCI Probe failing? 2.4.x kernels

[Shawn Starr]

snip from dmesg:

PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 00:09.0
  got res[1000:10ff] for resource 0 of ATI Technologies Inc 3D
Rage I/II 215GT [Mach64 GT]
Limiting direct PCI/PCI transfers.

What does this mean?

The video card should be using irq 10 according to the BIOS on bootup.
The video card shares int 10 with other devices as well.

   CPU0
  0:1614217  XT-PIC  timer
  1:  20928  XT-PIC  keyboard
  2:  0  XT-PIC  cascade
  4: 143613  XT-PIC  serial
  5: 384574  XT-PIC  soundblaster
  8:  1  XT-PIC  rtc
  9:  78029  XT-PIC  eth0
 14:  17015  XT-PIC  ide0
 15: 47  XT-PIC  ide1


Why is it limiting PCI/PCI transfers?

Shawn.

-
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.4.0 Networking oddity

[Daniel Walton]

I am running a web server under the new 2.4.0 kernel and am experiencing 
some intermittent odd behavior from the kernel.  The machine will sometimes 
go through cycles where network response becomes slow even though top 
reports over 60% idle CPU time.   When this is happening ping goes from 
reasonable response times to response times of several seconds in cycles of 
about 15 to 20 seconds.

As a test I pinged another machine on the same network segment and received 
the same results listed above.  On the other hand, I pinged from the other 
machine on the LAN to the problem machine and the ping times were a 
consistent 0.1ms.  This tells me two things.  One, that the network switch 
was not causing the problem, and two, that the problem is very likely 
somewhere in the handoff of packets from kernel-land to user-land on the 
problem server.

Here is the ping results from the problem server to another machine on the 
same segment:

77 packets transmitted, 77 packets received, 0% packet loss
round-trip min/avg/max = 0.2/4368.1/15126.6 ms


Here are the ping results from the other machine to the problem server 
taken at exactly the same time:

116 packets transmitted, 115 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.3 ms


A little information about what I'm running.  The server is running about 
700Kbps continuous network output from nearly a thousand concurrent 
connections.  The web server is a single process which utilizes the 
select/poll method of multiplexing.  The machine is an 1gig Athlon 
processor with 512megs with RedHat 6.2 installed.

I have the following tweaks setup in my rc.local file:

echo "7168 32767 65535" > /proc/sys/net/ipv4/tcp_mem
echo 32768 > /proc/sys/net/ipv4/tcp_max_orphans
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 4 > /proc/sys/net/ipv4/tcp_syn_retries
echo 7 > /proc/sys/net/ipv4/tcp_retries2
echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 30 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 16384 > /proc/sys/fs/file-max
echo 16384 > /proc/sys/kernel/rtsig-max


Am I simply missing something in my tweaks or is this a bug?  I would be 
happy to supply more information if it would help anyone in the know on a 
problem like this.

I appreciate any light anyone can shed on this subject.  I've been trying 
to find the source of this problem for some time now.

Daniel Walton



-
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: PCI IRQ routing problem in 2.4.0 (SiS results)

[Linus Torvalds]

On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
> 
> My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl
> (It is SiS 5598 based)

Your pirq values are different - they are in the 0x41-0x44 range, like the
old SiS router code assumes. Except for one that has value 0x62, which the
old SiS code actually refused to set because it refused anything that
matches (x & 0x20).

I suspect that the low bits are the "PCI interrupt number", and that the
high bits are some other state information. (ie 0x02, 0x42 and 0x62 all
imply PCI irq INTB, just with different flags set for some reason).

Which one was it you got a PIRQ conflict for before? as it te device at
00:01.00 with the strange "0x62" entry?

How about you try adding the line

pirq = (pirq-1) & 3;

at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
SiS routines). What happens then?

Linus

-
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 to run IrDA with no modules in 2.4.x

[Pete Zaitcev]

A minor problem here - module_init(irda_proto_init) got bracketed
by #ifdef MODULE and became ineffective if compiled without modules.

-- Pete

diff -ur -X dontdiff linux-2.4.1-pre11/net/irda/af_irda.c 
linux-2.4.1-pre11-p3/net/irda/af_irda.c
--- linux-2.4.1-pre11/net/irda/af_irda.cSat Nov 11 18:11:23 2000
+++ linux-2.4.1-pre11-p3/net/irda/af_irda.c Sun Jan 28 21:31:16 2001
@@ -2409,6 +2409,7 @@
 #endif
return 0;
 }
+module_init(irda_proto_init);
 
 /*
  * Function irda_proto_cleanup (void)
@@ -2429,11 +2430,9 @@

 return;
 }
-module_init(irda_proto_init);
 module_exit(irda_proto_cleanup);
  
 MODULE_AUTHOR("Dag Brattli <[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("The Linux IrDA Protocol Subsystem"); 
 MODULE_PARM(irda_debug, "1l");
 #endif /* MODULE */
-
-
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: PCI IRQ routing problem in 2.4.0

[Tim Hockin]

> > Device 00:01.0 (slot 0): ISA bridge
> >   INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> >   INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> >   INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> >   INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
> 
> Your "link" values are in the range 1-4. Which makes perfect sense, but
> that's absolutely _not_ what the Linux SiS routing code expects (the code 
> seems to expect them to be ASCII 'A' - 'D').


In reading the PIRQ specs, and making it work for our board, I thought
about this.  PIRQ states that link is chipset-dependant.  No chipset that I
have seen specifies what link should be.  So, as this case demonstrates, it
may be 'A' - the value the chipset expects, or 1, the logical index.
Either one makes sense, assuming the PIRQ routing code knows what link
means.  Here we see two BIOS vendors/versions that apparently do it
differently for the same chipset.Grrr.


-
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: PCI IRQ routing problem in 2.4.0 (SiS results)

[Aaron Tiensivu]

| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are broken for your setup.

My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl
(It is SiS 5598 based)

| Anybody else with SiS chipsets that want to try the above? Please..

Here is my dmesg:
Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3
20010125 (prerelease)) #3 Mon Jan 29 00:16:07 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 000a @  (usable)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 03efd000 @ 0010 (usable)
 BIOS-e820: 2000 @ 03ffd000 (ACPI data)
 BIOS-e820: 1000 @ 03fff000 (ACPI NVS)
 BIOS-e820: 0001 @  (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c000 for 4096 bytes.
On node 0 totalpages: 16381
zone(0): 4096 pages.
zone(1): 12285 pages.
zone(2): 0 pages.
APIC turned off by hardware.
mapped APIC to e000 (01112000)
Kernel command line: auto BOOT_IMAGE=lnew ro root=341
BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage
Initializing CPU#0
Detected 374.229 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 747.11 BogoMIPS
Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k
data, 188k init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
VFS: Diskquotas version dquot_6.5.0 initialized
CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008021bf 808029bf  0002
CPU: After generic, caps: 008021bf 808029bf  0002
CPU: Common caps: 008021bf 808029bf  0002
CPU: AMD-K6(tm) 3D processor stepping 0c
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: AMD K6
PCI: BIOS32 Service Directory structure at 0xc00f9b50
PCI: BIOS32 Service Directory entry at 0xf04d0
PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00
PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Setting max latency to 32
PCI: IDE base address trash cleared for 00:01.1
PCI: IDE base address fixup for 00:01.1
PCI: Scanning for ghost devices on bus 0
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00f0af0
00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8
00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8
00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8
00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/
00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
PCI: IRQ fixup
PCI: Allocating resources
PCI: Resource d000-d00f (f=101, d=0, p=0)
PCI: Resource dd00-dd000fff (f=200, d=0, p=0)
PCI: Resource b800-b807 (f=101, d=0, p=0)
PCI: Resource dc80-dc87 (f=200, d=0, p=0)
PCI: Resource e000-e7ff (f=1208, d=0, p=0)
PCI: Resource df00-df000fff (f=1208, d=0, p=0)
PCI: Resource b400-b41f (f=101, d=0, p=0)
PCI: Resource dc00-dc0f (f=200, d=0, p=0)
PCI: Resource de00-de3f (f=1208, d=1, p=1)
PCI: Resource db80-db80 (f=200, d=1, p=1)
PCI: Resource b000-b07f (f=101, d=1, p=1)
PCI: Sorting device list...
Disabling direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 41341kB/31006kB, 128 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 09
IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl  -> newirq=10Unknown SiS
pirq value 98
 -> assigning IRQ 10Unknown SiS pirq value 98
 ... failed
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS5597
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
hda: ST5660A, ATA 

Re: PCI IRQ routing problem in 2.4.0 (SiS results)

[Aaron Tiensivu]

| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are broken for your setup.

My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl
(It is SiS 5598 based)

| Anybody else with SiS chipsets that want to try the above? Please..

Here is my dmesg:
Linux version 2.4.0-ac12 ([EMAIL PROTECTED]) (gcc version 2.95.3
20010125 (prerelease)) #3 Mon Jan 29 00:16:07 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 000a @  (usable)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 03efd000 @ 0010 (usable)
 BIOS-e820: 2000 @ 03ffd000 (ACPI data)
 BIOS-e820: 1000 @ 03fff000 (ACPI NVS)
 BIOS-e820: 0001 @  (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c000 for 4096 bytes.
On node 0 totalpages: 16381
zone(0): 4096 pages.
zone(1): 12285 pages.
zone(2): 0 pages.
APIC turned off by hardware.
mapped APIC to e000 (01112000)
Kernel command line: auto BOOT_IMAGE=lnew ro root=341
BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage
Initializing CPU#0
Detected 374.229 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 747.11 BogoMIPS
Memory: 62368k/65524k available (940k kernel code, 2772k reserved, 327k
data, 188k init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
VFS: Diskquotas version dquot_6.5.0 initialized
CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008021bf 808029bf  0002
CPU: After generic, caps: 008021bf 808029bf  0002
CPU: Common caps: 008021bf 808029bf  0002
CPU: AMD-K6(tm) 3D processor stepping 0c
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: AMD K6
PCI: BIOS32 Service Directory structure at 0xc00f9b50
PCI: BIOS32 Service Directory entry at 0xf04d0
PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00
PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Setting max latency to 32
PCI: IDE base address trash cleared for 00:01.1
PCI: IDE base address fixup for 00:01.1
PCI: Scanning for ghost devices on bus 0
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00f0af0
00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8
00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8
00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8
00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/
00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
PCI: IRQ fixup
PCI: Allocating resources
PCI: Resource d000-d00f (f=101, d=0, p=0)
PCI: Resource dd00-dd000fff (f=200, d=0, p=0)
PCI: Resource b800-b807 (f=101, d=0, p=0)
PCI: Resource dc80-dc87 (f=200, d=0, p=0)
PCI: Resource e000-e7ff (f=1208, d=0, p=0)
PCI: Resource df00-df000fff (f=1208, d=0, p=0)
PCI: Resource b400-b41f (f=101, d=0, p=0)
PCI: Resource dc00-dc0f (f=200, d=0, p=0)
PCI: Resource de00-de3f (f=1208, d=1, p=1)
PCI: Resource db80-db80 (f=200, d=1, p=1)
PCI: Resource b000-b07f (f=101, d=1, p=1)
PCI: Sorting device list...
Disabling direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 41341kB/31006kB, 128 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 09
IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl  -> newirq=10Unknown SiS
pirq value 98
 -> assigning IRQ 10Unknown SiS pirq value 98
 ... failed
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS5597
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
hda: ST5660A, ATA 

Re: Poor SCSI drive performance on SMP machine, 2.2.16

[paradox3]

Here is the output from dmesg. How do I tell if it is improperly terminated?

Thanks, Para-dox ([EMAIL PROTECTED])




- Original Message -
From: "Michael Brown" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 28, 2001 11:12 PM
Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16


> Your problem appears to be improper SCSI termination.
>
> You need to either
>   1) make sure your SCSI drive has termination enabled
> or
>   2) move your SCSI drive to the middle connector and put a terminator on
> the last connector
>
> Check your syslog and post to l-k the part where it detects your drives.
> I'll bet the adapter is throttling back quite dramatically in the presence
> of improper termination.
>
> --
> Michael Brown
>
> _
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>


(scsi0)  found at PCI 0/12/0
(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.31/3.2.4
   
scsi : 1 host.
(scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 15.
  Vendor: IBM   Model: DGHS09U   Rev: 0350
  Type:   Direct-Access  ANSI SCSI revision: 03
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
scsi : detected 1 SCSI disk total.
SCSI device sda: hdwr sector= 512 bytes. Sectors= 17916240 [8748 MB] [8.7 GB]
Partition check:
 sda: sda1 sda2 sda3

Re: PCI IRQ routing problem in 2.4.0

[Linus Torvalds]

On Mon, 29 Jan 2001, Robert Siemer wrote:
> From: Linus Torvalds <[EMAIL PROTECTED]>
> 
> > Another one..
> 
> > Robert, can you get the dump_pirq script from the pcmcia_cs package
> > and send the output to us?
> 
> ...it seems to reflect my settings in the bios:

No, but that's really interesting..

> Device 00:01.0 (slot 0): ISA bridge
>   INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
>   INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
>   INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
>   INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]

Your "link" values are in the range 1-4. Which makes perfect sense, but
that's absolutely _not_ what the Linux SiS routing code expects (the code 
seems to expect them to be ASCII 'A' - 'D').

It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
arch/i386/kernel/pci-irq.c are broken for your setup.

Can you replace them with the following:

static int pirq_sis_get(struct pci_dev *router, struct pci_dev *dev, int pirq)
{
if (pirq <= 4) {
u8 x;
pci_read_config_byte(router, 0x40+pirq, );
return (x & 0x80) ? 0 : (x & 0xf);
}
printk("Unknown SiS pirq value %d\n", pirq);
return 0;
}

and

static int pirq_sis_set(struct pci_dev *router, struct pci_dev *dev, int pirq, 
int irq)
{
if (pirq <= 4) {
pci_write_config_byte(router, 0x40 + pirq, irq);
return 1;
}
printk("Unknown SiS pirq value %d\n", pirq);
return 0;
}

and see if that changes the behaviour. 

Anybody else with SiS chipsets that want to try the above? Please..

Linus

-
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: PCI IRQ routing problem in 2.4.0

[Robert Siemer]

From: Linus Torvalds <[EMAIL PROTECTED]>

> Another one..

> Robert, can you get the dump_pirq script from the pcmcia_cs package
> and send the output to us?

...it seems to reflect my settings in the bios:


Interrupt routing table found at address 0xf0a50:
  Version 1.0, size 0x0080
  Interrupt router is device 00:01.0
  PCI exclusive interrupt mask: 0x []
  Compatible router: vendor 0x1039 device 0x0008

Device 00:0c.0 (slot 1): SCSI storage controller
  INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]

Device 00:0b.0 (slot 2): VGA compatible controller
  INTA: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTB: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTC: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTD: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]

Device 00:0a.0 (slot 3): Ethernet controller
  INTA: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTB: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTC: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTD: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]

Device 00:09.0 (slot 4): Multimedia video controller
  INTA: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTB: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTC: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTD: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]

Device 00:01.0 (slot 0): ISA bridge
  INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]

Device 00:13.0 (slot 0): VGA compatible controller
  INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
  INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]

Interrupt router at 00:01.0: SiS 85C503 PCI-to-ISA bridge
  INTA (link 0x41): irq 12
  INTB (link 0x42): irq 14
  INTC (link 0x43): irq 10
  INTD (link 0x44): irq 11
-
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: Linux-2.4.1-pre11 / ll_rw_b watermark metric?

[Dieter Nützel]

Am Montag, 29. Januar 2001 04:46 schrieb Jens Axboe:
> On Mon, Jan 29 2001, Dieter Nützel wrote:
> > I have pre11 running with Andrea's suggested fix.
> >
> > high_queued_sectors = total_ram / 3;
> > low_queued_sectors = high_queued_sectors / 2;
> > if (low_queued_sectors < 0)
> > low_queued_sectors = total_ram / 2;
> >
> > /*
> >  * for big RAM machines (>= 384MB), use more for I/O
> >  */
> > /*
> > if (total_ram >= MB(384)) {
> > high_queued_sectors = (total_ram * 4) / 5;
> > low_queued_sectors = high_queued_sectors - MB(128);
> > }
> > */
> >
> > Shouldn't it be clean for a 2.4.1 release?
>
> With enough swap the numbers I saw were not conclusive. I promised
> to test which I haven't gotten done yet, I will do this tomorrow
> and make sure we have the right ratios. However, I don't think
> the pre11 numbers are much off - do you have any results?

I have 256 MB RAM and 200 MB swap but nothing of the later was used during 
"dbench 48". It was nothing spectacular but a litte bit faster with the above.
Attention: Results only from memory...;-)

Good night.
Dieter
-
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: D state after applying ps hang patch

[Jens Axboe]

On Mon, Jan 29 2001, Jens Axboe wrote:
> Try this ll_rw_blk.c change instead, on top of pre11. Include
> Linus' mm fixes of course.

On top of ac12 I mean, pre11 already has a different (but functional)
change.

-- 
Jens Axboe

-
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: Linux-2.4.1-pre11

[Jeff Garzik]

Drew Bertola wrote:
> 
> Drew Bertola writes:
> > Andrew's latest ACPI fixes (acpica-linux-2125 patched against
> > 2.4.0) compile fine here and don't hang on my Vaio after loading
> > tables.
> >
> > That's a start.  I'll play around some more.
> 
> Unfortunately, pcmcia modules fail to load.  I can't understand the
> interaction.
> 
> The message displayed on boot when starting the service says:
> 
> ds: no socket drivers loaded

Personally I advocate building all pcmcia stuff into the kernel.  It has
never failed before, and its core hardware on your laptop, so it will
always be there.  Why bother with modules at all for core
functionality...

Jeff


-- 
Jeff Garzik   | "You see, in this world there's two kinds of
Building 1024 |  people, my friend: Those with loaded guns
MandrakeSoft  |  and those who dig. You dig."  --Blondie
-
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: D state after applying ps hang patch

[Jens Axboe]

On Sun, Jan 28 2001, David Ford wrote:
> The one LInus posted plus his addendum for the ll_rw_blk.
> http://blue-labs.org/patches/ps-hang.patch

You merged it wrong, Linus suggested to remove the entire

if (!list_empty(>request_freelist[rw])) {
blk_refill_freelist(q, rw);
list_add(>table, >request_freelist[rw]);
return;
}

In fact, with the change you made the box can't possible survive
for very long - once the queue freelists are empty, you will
deadlock immediately.

Try this ll_rw_blk.c change instead, on top of pre11. Include
Linus' mm fixes of course.

--- /opt/kernel/linux-2.4.1-pre10/drivers/block/ll_rw_blk.c Thu Jan 25 19:15:12 
2001
+++ drivers/block/ll_rw_blk.c   Sun Jan 28 19:22:20 2001
@@ -633,6 +634,8 @@
if (!list_empty(>request_freelist[rw])) {
blk_refill_freelist(q, rw);
list_add(>table, >request_freelist[rw]);
+   if (waitqueue_active(>wait_for_request))
+   wake_up_nr(>wait_for_request, 2);
return;
}
 

-- 
Jens Axboe

-
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: Linux-2.4.1-pre11 / ll_rw_b watermark metric?

[Jens Axboe]

On Mon, Jan 29 2001, Dieter Nützel wrote:
> I have pre11 running with Andrea's suggested fix.
> 
> high_queued_sectors = total_ram / 3;
> low_queued_sectors = high_queued_sectors / 2;
> if (low_queued_sectors < 0)
> low_queued_sectors = total_ram / 2;
>  
> /*
>  * for big RAM machines (>= 384MB), use more for I/O
>  */
> /*
> if (total_ram >= MB(384)) {
> high_queued_sectors = (total_ram * 4) / 5;
> low_queued_sectors = high_queued_sectors - MB(128);
> }
> */
> 
> Shouldn't it be clean for a 2.4.1 release?

With enough swap the numbers I saw were not conclusive. I promised
to test which I haven't gotten done yet, I will do this tomorrow
and make sure we have the right ratios. However, I don't think
the pre11 numbers are much off - do you have any results?

-- 
Jens Axboe

-
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: Linux-2.4.1-pre11 / ll_rw_b watermark metric?

[Dieter Nützel]

I have pre11 running with Andrea's suggested fix.

high_queued_sectors = total_ram / 3;
low_queued_sectors = high_queued_sectors / 2;
if (low_queued_sectors < 0)
low_queued_sectors = total_ram / 2;
 
/*
 * for big RAM machines (>= 384MB), use more for I/O
 */
/*
if (total_ram >= MB(384)) {
high_queued_sectors = (total_ram * 4) / 5;
low_queued_sectors = high_queued_sectors - MB(128);
}
*/

Shouldn't it be clean for a 2.4.1 release?

-Dieter
-
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: ECN: Clearing the air (fwd)

[David Lang]

I am behind a raptor firewall and ran the test that David M posted a
couple days ago and was able to sucessfully connect to his test machine.

so either raptor tolorates ECN (at least in the verion I am running) or
the test was not valid.

David Lang

On Sun, 28 Jan 2001, jamal wrote:

> Date: Sun, 28 Jan 2001 11:15:24 -0500 (EST)
> From: jamal <[EMAIL PROTECTED]>
> To: James Sutherland <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: ECN: Clearing the air (fwd)
>
>
>
> On Sun, 28 Jan 2001, James Sutherland wrote:
>
> > On Sun, 28 Jan 2001, jamal wrote:
> > > There were people who made the suggestion that TCP should retry after a
> > > RST because it "might be an anti-ECN path"
> >
> > That depends what you mean by "retry"; I wanted the ability to attempt a
> > non-ECN connection. i.e. if I'm a mailserver, and try connecting to one of
> > Hotmail's MX hosts with ECN, I'll get RST every time. I would like to be
> > able to retry with ECN disabled for that connection.
> >
>
> We are allowing two rules to be broken, one is RFC 793 which
> clearly and unambigously defines what a RST means. the second is
> the firewall or IDS box which clearly is in violation.
> The simplest thing in this chaos is to fix the firewall because it is in
> violation to begin with.
> I think it is silly to try to be "robust against RSTs" because of ECN.
> What if the RST was genuine?
>
> I see that we mostly have philosphical differences. You'd rather adapt
> to the criminal and most people would rather have the criminal adjust to
> society.
>
> I think CISCO have been very good in responding fast. I blame the site
> owners who dont want to go beyond their 9-5 job and upgrade their boxes.
> In the old internet where only hackers were qualified for such jobs, the
> upgrade would have happened by now at hotmail. I suppose it's part of
> growing pains.
> If you think the CISCOs were bad sending RSTs, i am sure you havent heard
> about the Raptor firewalls. They dont even bother to send you anything if
> you have ECN enabled ;-> Simply swallow your SYNs.
> So tell me, what do you propose we deal with these? Do we further
> disambiguate or assume the packet was lost?
> I actually bothered calling Raptor, they chose to ignore me.
>
> You should never ASSume anything about something that is "reserved".
> I posted the definition from the collegiate dictionary, but i am sure most
> dictionaries would give the same definition.
>
> It's too bad we end up defining protocols using English. We should use
> mathematical equations to remove any ambiguity ;->
>
> cheers,
> jamal
>
> -
> 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/
>
-
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: D state after applying ps hang patch

[David Ford]

The one LInus posted plus his addendum for the ll_rw_blk.
http://blue-labs.org/patches/ps-hang.patch

-d

Jens Axboe wrote:

> On Mon, Jan 29 2001, David Ford wrote:
> > kernel 2.4.0-ac12
> >
> > # ps -eo user,pid,args,wchan|egrep "imap|update|procmail"
> > root 7 [kupdate]get_request_wait
> > david  627 imapdget_request_wait
> > david  752 procmail -f linu down
> > david  761 procmail -f linu down
> > david  799 procmail -f linu down
> > david  854 procmail -f linu down
> > david  886 procmail -f linu down
> > david  847 imapdget_request_wait
> > david 1079 procmail -f linu down
> > david 3280 imapdinterruptible_sleep_on_locked
> > david 3321 imapdinterruptible_sleep_on_locked
> >
> > and the cpu load is artificially inflated to 9.17
>
> Which patch specifically?

--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



-
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: troubles with devfs ?

[Ingo Oeser]

On Sun, Jan 28, 2001 at 06:21:52PM +0100, Pierfrancesco Caci wrote:
> 
> This happens on a freshly booted 2.4.0 macine, with devfs and devfsd
> running.
> 
> I got the oops by doing
> # cd /dev
> # ls -las
> (segmentation fault)
> 
> The first oops causes the death of devfsd.

No such problems here and cannot reproduce this behavior. But I
have no real SCSI adaptor. Only ide-scsi and imm (Iomega-ZIP+).

So this might be an SCSI-Issue...

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
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/

[SLUG] RE: Linux Disk Performance/File IO per process

[Tony . Young]

> -Original Message-
> From: Chris Evans [mailto:[EMAIL PROTECTED]]
> Sent: Monday, 29 January 2001 13:04
> To: Tony Young
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Linux Disk Performance/File IO per process
> 
> 
> 
> On Mon, 29 Jan 2001 [EMAIL PROTECTED] wrote:
> 
> > All,
> >
> > I work for a company that develops a systems and 
> performance management
> > product for Unix (as well as PC and TANDEM) called 
> PROGNOSIS. Currently we
> > support AIX, HP, Solaris, UnixWare, IRIX, and Linux.
> >
> > I've hit a bit of a wall trying to expand the data provided 
> by our Linux
> > solution - I can't seem to find anywhere that provides the 
> metrics needed to
> > calculate disk busy in the kernel! This is a major piece of 
> information that
> > any mission critical system administrator needs to 
> successfully monitor
> > their systems.
> 
> Stephen Tweedie has a rather funky i/o stats enhancement patch which
> should provide what you need. It comes with RedHat7.0 and gives decent
> disk statistics in /proc/partitions.
> 
> Unfortunately this patch is not yet in the 2.2 or 2.4 kernel. 
> I'd like to
> see it make the kernel as a 2.4.x item. Failing that, it'll 
> probably make
> the 2.5 kernel.
> 
> Cheers
> Chris
>

Thanks to both Jens and Chris - this provides the information I need to
obtain our busy rate
It's unfortunate that the kernel needs to be patched to provide this
information - hopefully it will become part of the kernel soon.

I had a response saying that this shouldn't become part of the kernel due to
the performance cost that obtaining such data will involve. I agree that a
cost is involved here, however I think it's up to the user to decide which
cost is more expensive to them - getting the data, or not being able to see
how busy their disks are. My feeling here is that this support could be user
configurable at run time - eg 'cat 1 > /proc/getdiskperf'.

Thanks for your quick responses.

Tony...


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: [PATCH] dynamic IP support for 2.4.0 (SIOCKILLADDR)

[Albert D. Cahalan]

John Fremlin writes:

> When the IP address of an interface changes, TCP connections with the
> old source address are useless. Applications are not notified of this
> and time out ordinarily, just as if nothing had happened. This is
> behaviour isn't very helpful when you have a dynamic IP and know
> you're probably not going to get the old one back. In that case, you
...
> I patched userspace ppp-2.4.0 to use this functionality. It would be
> better if SIOCKILLADDR were not used until we are sure that the new IP
> is in fact different from the old one, but pppd in demand mode would

I get the same IP about 2/3 of the time, so it is pretty important
to avoid killing connections until after the new IP is known.
-
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] Making Cyrix III boot

[Ingo Oeser]

Hi,

On Sun, Jan 28, 2001 at 10:31:52AM -0800, Linus Torvalds wrote:
> I just uploaded it to kernel.org, and I expect that I'll do the final
> 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
> pre-kernel works for you..

The Cyrix III of my employer doesn't boot without this patch.
Reason: There are no MSRs in this range.

Since hpa didn't send a better fix, I attached the band-aid fix
for you, so that people can boot.

Linus, please apply.

Regards

Ingo Oeser

--- linux-2.4.1-pre11/arch/i386/kernel/setup.c.orig Mon Jan 29 03:35:08 2001
+++ linux-2.4.1-pre11/arch/i386/kernel/setup.c  Mon Jan 29 03:36:41 2001
@@ -1401,10 +1401,11 @@
wrmsr (0x1107, lo, hi);
 
set_bit(X86_FEATURE_CX8, >x86_capability);
+   /* FIXME: This is only band-aid. Will be fixed 
+properly -ioe
rdmsr (0x8001, lo, hi);
if (hi & (1<<31))
set_bit(X86_FEATURE_3DNOW, 
>x86_capability);
-
+   */
get_model_name(c);
display_cacheinfo(c);
break;

-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
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: Linux-2.4.1-pre11

[Linus Torvalds]

On Sun, 28 Jan 2001, David D.W. Downey wrote:
> 
> I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the
> /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/
> directories. Is it somewhere different?

All my "current" test-patches are always under /pub/linux/kernel/testing.

The "v2.4/test-kernels/ directory is for historic files - the
test-kernels that led up to 2.4.0

Linus

-
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: PDC20265, disk corruption and NMI watchdog...

[Petr Vandrovec]

On Mon, Jan 28, 2001 at 17:36 Andre Hedrick wrote:
> 
> Everything but a kernel version :-(

Sorry. Corruption happens since I have this motherboard just before
christmas - something about 2.4.0-test13-pre2. It was not so massive
as today - with 2.4.0-ac10 (before it just died, today it damaged
hdh in addition). I got corruption/lockup with other versions (test13-pre3,
test13-pre7, 2.4.0, 2.4.0-ac3, 2.4.0-ac8, 2.4.0-ac9) too,
but as this one (ac10) does NMI watchdog on UP, I finally found
what's wrong instead of silent death - it is why I finally wrote
this letter - so you can either __sti() or mdelay() in ide_delay_50ms.
So others will not suffer from silent death instead of IDE reset...

Then I can test whether promise recovers from this - I doubt, as it
looks like that some data for /dev/hde landed on /dev/hdh (impossible,
I know...).

> On Mon, 29 Jan 2001, Petr Vandrovec wrote:
> 
> >   why on Earth ide_delay_50ms uses jiffies instead of mdelay(50) ?!
> > It is invoked with interrupts disabled, causing NMI watchdog detected
> > on my system, leading to complete crash of system.

For now I said that both disks should use PIO4 and it looks stable...
But there is visible difference in speed between PIO4 and UDMA5 ;-)

I have no idea whether TOSHIBA can do UDMA CRCs, but it works fine
at work, where I connected it to i440BX, and since November I
connect it to VIA694X/686A. Both in UDMA2 mode without troubles.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]

-
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/

[META] proposal to set up digestifier for linux-kernel

[Romain Kang]

After a hiatus from linux-kernel, I find that the lack of a digest on
the new server is a nuisance.  I'm thinking of setting up a Majordomo
digestifier, with the caveat that non-plaintext messages may have some
displaced bits. 

Would there be an interest in this?

Romain Kang Disclaimer: I speak for myself alone,
[EMAIL PROTECTED]except when indicated otherwise.
-
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] devfsd, compiling on glibc22x

[Albert D. Cahalan]

Ulrich Drepper writes:
> Pierre Rousselet <[EMAIL PROTECTED]> writes:
>
>> for me :
>> make CFLAGS='-O2 -I. -D_GNU_SOURCE' 
>> compiles without any patch. is it correct ?
>
> Yes.  RTLD_NEXT is not in any standard, it's an extension available
> via -D_GNU_SOURCE.

This isn't a HURD feature.
This isn't even a C library feature.
This is a Linux feature.

So the _GNU_SOURCE thing is just plain wrong. Quit trying to
rename the OS.

Since there are so many standards to choose from, putting all features
into the default would be most obvious. Else what, pure C89 maybe?
Dang new-fangled standards might break something. Normal UNIX systems
don't make developers jump through hoops to get access to stuff; they
instead provide clean namespaces upon request.


-
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: linux-2.4.1-pre11

[Louis Garcia]

Arnaldo Carvalho de Melo wrote:

> Em Sun, Jan 28, 2001 at 06:55:25PM -0500, Louis Garcia escreveu:
> 
>> I am getting messages everytime I use the network from my RH7 + 
>> kernel-2.4.1-pre11 system:
>> 
>> modprobe: modprobe: Can't locate module net-pf-10
>> 
>> I have checked my .config  and can't find that modules. This does not 
>> happen with 2.4.0 kernel, only with the latest pre series maybe pre7 on.
> 
> 
> you haven't included support for IPv6 and your distribution initscripts is
> trying to load it for some reason, two solutions:
> 
> 1. enable IPv6 in your kernel build
> 2. disable it in your /etc/modules.conf file, like this:
> 
> alias net-pf-10 off
> 
> - Arnaldo
> 
> 
> 
Anyone have an idea where in the initscripts does this happen?

-
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: Linux-2.4.1-pre11

[Dieter Nützel]

Am Sonntag, 28. Januar 2001 22:46 schrieb Linus Torvalds:
> On Sun, 28 Jan 2001, Dieter Nützel wrote:
> > > I just uploaded it to kernel.org, and I expect that I'll do the final
> > > 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that
> > > the pre-kernel works for you..
> >
> > Hello Linus,
> >
> > can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release
> > updated: 1-25-2001)  in 2.4.1 final?
>
> Does it fix stuff? Andrew?

I am the loser :-(
2.4.1-pre10 (with Andrew's ACPI fixes included) and
2.4.1-pre11 + 1-25-2001 patch bring back the pppd slowdown on my system.

2.4.1-pre9 was fine...

AMD K7
MSI MS-6167 Rev. 1.0B (Irongate C4)

-Dieter
-
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: Linux Disk Performance/File IO per process

[Chris Evans]

On Mon, 29 Jan 2001 [EMAIL PROTECTED] wrote:

> All,
>
> I work for a company that develops a systems and performance management
> product for Unix (as well as PC and TANDEM) called PROGNOSIS. Currently we
> support AIX, HP, Solaris, UnixWare, IRIX, and Linux.
>
> I've hit a bit of a wall trying to expand the data provided by our Linux
> solution - I can't seem to find anywhere that provides the metrics needed to
> calculate disk busy in the kernel! This is a major piece of information that
> any mission critical system administrator needs to successfully monitor
> their systems.

Stephen Tweedie has a rather funky i/o stats enhancement patch which
should provide what you need. It comes with RedHat7.0 and gives decent
disk statistics in /proc/partitions.

Unfortunately this patch is not yet in the 2.2 or 2.4 kernel. I'd like to
see it make the kernel as a 2.4.x item. Failing that, it'll probably make
the 2.5 kernel.

Cheers
Chris

-
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/

[SLUG] Re: Linux Disk Performance/File IO per process

[Jens Axboe]

On Mon, Jan 29 2001, [EMAIL PROTECTED] wrote:
> All,
> 
> I work for a company that develops a systems and performance management
> product for Unix (as well as PC and TANDEM) called PROGNOSIS. Currently we
> support AIX, HP, Solaris, UnixWare, IRIX, and Linux.
> 
> I've hit a bit of a wall trying to expand the data provided by our Linux
> solution - I can't seem to find anywhere that provides the metrics needed to
> calculate disk busy in the kernel! This is a major piece of information that
> any mission critical system administrator needs to successfully monitor
> their systems.

The stock kernel doesn't provide either, but at least with Stephen's
sard patches you can get system wide I/O metrics.

ftp.linux.org.uk/pub/linux/sct/fs/profiling

-- 
Jens Axboe



-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

Re: Support for 802.11 cards?

[Anton Blanchard]

Hi,
 
>   Last I knew (straight from the Lucent people), the ISA bridge
> card worked fine and the PCI card did NOT work at all.  I've since
> confirmed that, first hand, myself (I currently have the ISA bridge in
> operation) on the 2.2 kernels.  The ISA bridge also works on the 2.4
> kernels but I have not retested the PCI bridge on 2.4.  The Lucent
> people claim that the Linux pcmcia people are aware of the problem.

I have a PCI -> PCMCIA bridge + lucent wavelan card working fine with the
GPL driver (not the Lucent proprietory one) and 2.4. From memory all I had
to do was stop pcmcia-cs from using the lower io port range (there must
have been conflicts with existing devices).

#include port 0x100-0x4ff, port 0x800-0x8ff, port 0xc00-0xcff
include port 0x800-0x8ff, port 0xc00-0xcff

Anton
-
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: display problem with matroxfb

[Trevor Hemsley]

On Mon, 29 Jan 2001 00:30:34, Petr Vandrovec <[EMAIL PROTECTED]> 
wrote:

> > > you do not have to specify vesa,pixclock,hslen and vslen, as you leave
> > > them on defaults. 
> > 
> > Talking of defaults for matroxfb, would you consider limiting the fv: 
> > value default to something reasonable that'll work on all monitors? It
> > took me several recompiles/reboots to get a setting that would not put
> > my monitor into auto-powerdown. If you defaulted to fv:60 then it 
> > would work on 99.9% of monitors and then people could override that 
> > upwards. I have a Philips 201B 21" monitor and was using 
> > 
> > append="video=matrox:vesa:400"
> > 
> > and this was setting too high a vertical refresh rate for the monitors
> > capabilities. Adding fv:85 lets it work. The card is a Matrox 
> > Millennium G200 8MB SDRAM.
> 
> Are you sure that it did not run out of horizontal sync, or something
> like that? vesa:400 == vesa:0x190 == 1152x864/60Hz... And it powers
> up in 60Hz, at least here ;-)
> 
> See timmings array in drivers/video/matrox/matroxfb_base.c - all videomodes
> except XXXx400 powerups in fv=60Hz unless you specified fh/fv/pixclock.
> XXXx400 powerups with fv=70Hz, like standard VGA does.

Looks like one you've already fixed. I've retested and recreated it 
but it only happens with 2.2.13 not with the other two kernel sources 
I have (2.2.18 and 2.4.0). I also misinformed you about the way to 
recreate it, I had specified only append="matrox" in my lilo.conf. It 
was 2.2.13 that I did my experimentation on to get it to work in the 
first place and never bothered to retest afterwards. Sorry for the 
false alarm...

-- 
Trevor Hemsley, Brighton, UK.
[EMAIL PROTECTED]
-
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/

[SLUG] Linux Disk Performance/File IO per process

[Tony . Young]

All,

I work for a company that develops a systems and performance management
product for Unix (as well as PC and TANDEM) called PROGNOSIS. Currently we
support AIX, HP, Solaris, UnixWare, IRIX, and Linux.

I've hit a bit of a wall trying to expand the data provided by our Linux
solution - I can't seem to find anywhere that provides the metrics needed to
calculate disk busy in the kernel! This is a major piece of information that
any mission critical system administrator needs to successfully monitor
their systems.

I've looked in /proc - it provides I/O rates, but no time related
information (which is required to calculate busy%)
I've looked in the 2.4 kernel source
(drivers/block/ll_rw_blk.c,include/linux/kernel_stat.h - dk_drive* arrays) -
but can only see those /proc I/O rates being calculated.

Is this data provided somewhere that I haven't looked? Or does the kernel
really not provide the data necessary to calculate a busy rate?

I'm also interested in finding out file I/O metrics on a per process basis.
The CSA project run by SGI (http://oss.sgi.com/projects/csa) seems to
provide summarised I/O metrics per process using a loadable kernel module.
That is, it provides I/O rates for a process, but not for each file open by
that process.

Are there any existing methods to obtain this data? If so, can someone point
me in the right direction?
If not, what is the possibility of 'people-in-the-know' working towards
making these sort of metrics available from the kernel?
Could some of these metrics be added to the CSA project? (directed at the
CSA people of course.)

I'm more than willing to put in time to get these metrics into the kernel.
However, I'm new to kernel development, so it would take longer for me than
for someone who knows the code. But if none of the above questions can
really be answered I'd appreciate some direction as to where in the kernel
would be a good place to calculate/extract these metrics.

I believe that the lack of these metrics will make it difficult for Linux to
move into the mission critical server market. For this reason I'm keen to
see this information made available.

Thank you all for any help you may be able to provide.

I'm not actually subscribed to either the CSA or the linux-kernel mailing
lists, so I'd appreciate being CC'ed on any replies.
Thanks.

Tony...
--
Tony Young
Senior Software Engineer
Integrated Research Limited
Level 10, 168 Walker St
North Sydney NSW 2060, Australia
Ph: +61 2 9966 1066
Fax: +61 2 9966 1042
Mob: 0414 649942
[EMAIL PROTECTED]
www.ir.com


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug

RE: [patch] smbfs cache rewrite - 2nd try

[Rainer Mager]

This is working great for me so far. I've now got my full 1G RAM and samba
seems to be working fine. Woohoo! One more oops dead.

Put it in the official kernel. Put it in the official kernel. Put it in
the err, excuse me. I was chanting again.


--Rainer


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Urban Widmark
> Sent: Monday, January 29, 2001 1:23 AM
> To: [EMAIL PROTECTED]
> Cc: Rainer Mager; Scott A. Sibert
> Subject: [patch] smbfs cache rewrite - 2nd try
>
>
>
> Smbfs testers wanted, with or without highmem boxes.

-
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: Linux-2.4.1-pre11

[Arnaldo Carvalho de Melo]

Em Sun, Jan 28, 2001 at 08:10:41PM -0500, Michael H. Warfield escreveu:
>   Damn...  So much for typing too fast...  Screwed it up...

t fast 8)
 
> > Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz
> 
>   Patch was in /pub/linux/kernel/test/patch-2.4.1-pre11.gz
> 
>   Cut and paste screwup.  Sorry.

screwed again, there's no test directory, testing is the right one:

http://www.kernel.org/pub/linux/kernel/testing

- Arnaldo
-
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: PDC20265, disk corruption and NMI watchdog...

[Andre Hedrick]

Everything but a kernel version :-(

On Mon, 29 Jan 2001, Petr Vandrovec wrote:

> Short story:
> 
> Hi Andre,
>   why on Earth ide_delay_50ms uses jiffies instead of mdelay(50) ?!
> It is invoked with interrupts disabled, causing NMI watchdog detected
> on my system, leading to complete crash of system.
> 
> Long story:
> 
> At home I have Asus A7V motherboard with 1G Athlon, and onboard
> PDC20265 and VIA KT133. Only CDROM is connected to VIA (as I was
> not able to get any ATAPI device with Promise under Linux).
> To primary master of PDC (hde) there is IBM-DTLA-307045, happilly
> running in UDMA5 mode. As secondary slave (hdh) there is removable
> hdd TOSHIBA MK6409MAV - I use this hdd to transport data between
> work, home and grandparents.
> 
> On every weekend I bring debian packages on this hdd home, as downloading
> couple of MBs each weekend is not acceptable for dialup connection.
> But data are never copied OK from one hdd (hdh) to another (hde) -
> - hdh runs in UDMA2, hde in UDMA5. There are always 4 different bytes
> in couple of files - corrupted bytes are always on word boundary, but
> sometime they are on dword, sometime they are not. Data are never
> moved, they are just random bytes... It looks like that
> problem is with removable HDD (source), not with UDMA5 destination.
> 
> So I decided to 'hdparm -d1 -X 65 /dev/hdh' to switch it to UDMA1.
> i was awarded by (4 times):
> 
> hde: dma_intr: bad DMA status
> hde: dma_intr: status = 0x50 { DriveReady SeekComplete }
> 
> and
> 
> hde: DMA disabled
> NMI watchdog detected lockup on CPU0, registers:
> ...
> Dump says that ide_delay_50ms was invoked with interrupts disabled
> in swapper task, through pdc202xx_reset -> do_reset1 -> ide_do_reset -> 
> ide_error -> ide_dma_intr -> ide_intr -> handle_IRQ_event -> do_IRQ -> 
> (interrupt) -> default_idle -> cpu_idle.
> 
> I have no idea why it compalined on hde, when I hdparm-ed hdh...
> So I rebooted - and after reboot fsck of hde* passed ok, but on
> hdh* it was not able to find debian tree - directory tree was cut to about
> 7 parts which were reconnected to /lost+found. Probably someone took
> deep look at some inodes, as fsck found about 1000 errors - it is too
> much from filesystem which could be modified only due to atime changes...
> 
> So I my questions are: 
> Is it ok to use pdc202xx driver at all? It does not complain about UDMA CRC 
>   errors, but data are (always) corrupted.
> Should I return back to UDMA66 VIA instead of UDMA100 promise? 
> Should I rejumper my removable HDD to be master, and not slave?
>   Thanks,
>   Petr Vandrovec
>   [EMAIL PROTECTED]  
> 
> 
> -
> 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/
> 

Andre Hedrick
Linux ATA Development

-
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: Linux-2.4.1-pre11

[Derek Wildstar]

On Sun, 28 Jan 2001, Derek Wildstar wrote:

> OK, tried the patch and it worked, don't remember the exact errors with
> the .tar.gz, there were 7 or so undefined references.
>
> ACPI soft-hangs one step before (after looking at the non-debug source
> it may be the same place) it did last time, right after it prints:
>
> ACPI: Core Subsystem version [20010125]
>
> grabbing the debug version now to see if i can get more info.

OK, the debug version printed the following:

 tbxface-0089: ACPI Tables successfully loaded
Parsing Methods:(more dots, i can count if needed)
173 Control Methods found and parsed (602 nodes total)
ACPI Namespace successfully loaded at root c042f718
ACPI: Core Subsystem version [20010125]
evxfevnt-0082: Transition to ACPI mode successful
Executing device _INI methods:

The cursor stays at the end of the last line.

Let me know if there is anything you would like me to try.

-dwild

-
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: Linux-2.4.1-pre11

[Bob Chiodini]

How about:

http://www.us.kernel.org/pub/linux/kernel/testing/patch-2.4.1-pre11.gz

Bob...

"David D.W. Downey" wrote:

> >   Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz
> >
>
> I'm on ftp.kernel.org right this second in /pub/linux/kernel/v2.4/
>
> There is only a test-kernels/ subdir there, not a test/
>
> test-kernels/ does not contain the patch.
>
> David
>
> -
> 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/

--

[EMAIL PROTECTED]



-
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: Linux-2.4.1-pre11

[Michael H. Warfield]

Damn...  So much for typing too fast...  Screwed it up...

On Sun, Jan 28, 2001 at 07:59:47PM -0500, Michael H. Warfield wrote:
> On Sun, Jan 28, 2001 at 04:55:51PM -0800, David D.W. Downey wrote:

> > Hi Linus,
> > Sorry to bother you. I'm trying to find where you uploaded
> > linux-2.4.1-pre11.

> > I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the
> > /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/
> > directories. Is it somewhere different?

>   Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz

Patch was in /pub/linux/kernel/test/patch-2.4.1-pre11.gz

Cut and paste screwup.  Sorry.

[...]

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
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: Linux-2.4.1-pre11

[Luc de Louw]

Hi Linus

On Sun, 28 Jan 2001, Linus Torvalds wrote:


> 
> I just uploaded it to kernel.org, and I expect that I'll do the final
> 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
> pre-kernel works for you..

yes, it works :-)

> 
> The main noticeable things in pre11 are fixing some bugs that crept in
> after 2.4.0 - the block device queuing improvements could lose wakeups
> under extreme load by multiple clients, and the vmscanning "get rid of
> special return codes for shared memory" thing had missed a bit.
> 
> This should also fix the VIA IDE driver issues (if you want safe, do NOT
> enable auto-dma), and the reported problems with hpt366 controllers and
> IBM drives. Hopefully these were the last major IDE issues for a while.

It works fine for me

> 
> Also, can people who have had unhappy relationships with their eepro100
> please try to cuddle and make up again? The eepro100 changes should fix
> the problem of having posted writes that basically made some of the timing
> not work out.

I'll try that at monday ( In a couple of hours I'm at work) .

> 
>   Linus
> 



Have a nice trip and enjoy NYC! weatherforcast for monday and wednesday
looks great, visit the empire state buiöding its gread (if you get the
time) I wish I could at LinuxWold too  Have fun

rgds

Luc de Louw



-
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: Linux-2.4.1-pre11

[David D.W. Downey]

Nevermind. I found it.

It's actually residing in /pub/linux/kernel/testing/ and NOT in
/pub/linux/kernel/v2.4/ or it's subdirs.


David D.W. Downey


-
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: Linux-2.4.1-pre11

[David D.W. Downey]

>   Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz
> 



I'm on ftp.kernel.org right this second in /pub/linux/kernel/v2.4/

There is only a test-kernels/ subdir there, not a test/

test-kernels/ does not contain the patch.


David


-
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: Linux-2.4.1-pre11

[Michael H. Warfield]

On Sun, Jan 28, 2001 at 04:55:51PM -0800, David D.W. Downey wrote:

> Hi Linus,
>   Sorry to bother you. I'm trying to find where you uploaded
> linux-2.4.1-pre11.

> I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the
> /pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/
> directories. Is it somewhere different?

Patch was in /pub/linux/kernel/v2.4/test/patch-2.4.1-pre11.gz

> Also, Alan, I grabbed your patch-2.4.0-ac11.gz file from your directory on
> ftp.kernel.org. Does this contain the updated VIA IDE support that Linus
> was talking about in the 2.4.1-pre11?

> I'm thinking either kernel.org hasn't posted the 2.4.1-pre11 or I totally
> misunderstand the directory layout on kernel.org.

Close...

> A URL to the right patch or, preferably, full source for 2.4.1-pre11 would
> be great.

> Thanks,

> David D.W. Downey

[...]

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
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/

PDC20265, disk corruption and NMI watchdog...

[Petr Vandrovec]

Short story:

Hi Andre,
  why on Earth ide_delay_50ms uses jiffies instead of mdelay(50) ?!
It is invoked with interrupts disabled, causing NMI watchdog detected
on my system, leading to complete crash of system.

Long story:

At home I have Asus A7V motherboard with 1G Athlon, and onboard
PDC20265 and VIA KT133. Only CDROM is connected to VIA (as I was
not able to get any ATAPI device with Promise under Linux).
To primary master of PDC (hde) there is IBM-DTLA-307045, happilly
running in UDMA5 mode. As secondary slave (hdh) there is removable
hdd TOSHIBA MK6409MAV - I use this hdd to transport data between
work, home and grandparents.

On every weekend I bring debian packages on this hdd home, as downloading
couple of MBs each weekend is not acceptable for dialup connection.
But data are never copied OK from one hdd (hdh) to another (hde) -
- hdh runs in UDMA2, hde in UDMA5. There are always 4 different bytes
in couple of files - corrupted bytes are always on word boundary, but
sometime they are on dword, sometime they are not. Data are never
moved, they are just random bytes... It looks like that
problem is with removable HDD (source), not with UDMA5 destination.

So I decided to 'hdparm -d1 -X 65 /dev/hdh' to switch it to UDMA1.
i was awarded by (4 times):

hde: dma_intr: bad DMA status
hde: dma_intr: status = 0x50 { DriveReady SeekComplete }

and

hde: DMA disabled
NMI watchdog detected lockup on CPU0, registers:
...
Dump says that ide_delay_50ms was invoked with interrupts disabled
in swapper task, through pdc202xx_reset -> do_reset1 -> ide_do_reset -> 
ide_error -> ide_dma_intr -> ide_intr -> handle_IRQ_event -> do_IRQ -> 
(interrupt) -> default_idle -> cpu_idle.

I have no idea why it compalined on hde, when I hdparm-ed hdh...
So I rebooted - and after reboot fsck of hde* passed ok, but on
hdh* it was not able to find debian tree - directory tree was cut to about
7 parts which were reconnected to /lost+found. Probably someone took
deep look at some inodes, as fsck found about 1000 errors - it is too
much from filesystem which could be modified only due to atime changes...

So I my questions are: 
Is it ok to use pdc202xx driver at all? It does not complain about UDMA CRC 
  errors, but data are (always) corrupted.
Should I return back to UDMA66 VIA instead of UDMA100 promise? 
Should I rejumper my removable HDD to be master, and not slave?
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]  


-
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: Linux-2.4.1-pre11

[David D.W. Downey]

Hi Linus,
Sorry to bother you. I'm trying to find where you uploaded
linux-2.4.1-pre11.

I was on ftp.kernel.org and ftp.us.kernel.org and could not find it in the
/pub/linux/kernel/v2.4 or /pub/linux/kernel/v2.4/test-kernels/
directories. Is it somewhere different?

Also, Alan, I grabbed your patch-2.4.0-ac11.gz file from your directory on
ftp.kernel.org. Does this contain the updated VIA IDE support that Linus
was talking about in the 2.4.1-pre11?

I'm thinking either kernel.org hasn't posted the 2.4.1-pre11 or I totally
misunderstand the directory layout on kernel.org.

A URL to the right patch or, preferably, full source for 2.4.1-pre11 would
be great.

Thanks,

David D.W. Downey


On Sun, 28 Jan 2001, Linus Torvalds wrote:

> 
> I just uploaded it to kernel.org, and I expect that I'll do the final
> 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
> pre-kernel works for you..
> 
> The main noticeable things in pre11 are fixing some bugs that crept in
> after 2.4.0 - the block device queuing improvements could lose wakeups
> under extreme load by multiple clients, and the vmscanning "get rid of
> special return codes for shared memory" thing had missed a bit.
> 
> This should also fix the VIA IDE driver issues (if you want safe, do NOT
> enable auto-dma), and the reported problems with hpt366 controllers and
> IBM drives. Hopefully these were the last major IDE issues for a while.
> 
> Also, can people who have had unhappy relationships with their eepro100
> please try to cuddle and make up again? The eepro100 changes should fix
> the problem of having posted writes that basically made some of the timing
> not work out.
> 
>   Linus
> 
> -
> pre11:
>  - Trond Myklebust: NFS/RPC client SMP fixes
>  - rth: alpha pyxis and cabriolet fixes
>  - remove broken sys_wait4() declarations
>  - disable radeon debugging code
>  - VIA IDE driver should not enable autodma unless asked for
>  - Andrey Savochkin: eepro100 update. Should fix the resource timing problems.
>  - Jeff Garzik: via82cxxx_audio update
>  - YMF7xx PCI audio update: get rid of old broken driver, make new
>driver handle legacy control too. 
>  - fix missed wakeup on block device request list
>  - hpt366 controller doesn't play nice with some IBM harddisks
>  - remove inode pages from the page cache only after having removed them
>from the page tables.
>  - shared memory out-of-swap writepage() fixup (no more magic return)
> 
> pre10:
>  - got a few too-new R128 #defines in the Radeon merge. Fix.
>  - tulip driver update from Jeff Garzik
>  - more cpq and DAC elevator fixes from Jens. Looks good.
>  - Petr Vandrovec: nicer ncpfs behaviour
>  - Andy Grover: APCI update
>  - Cort Dougan: PPC update
>  - David Miller: sparc updates
>  - David Miller: networking updates
>  - Neil Brown: RAID5 fixes
> 
> pre9:
>  - cpq array driver elevator fixes 
>  - merge radeon driver from X CVS tree
>  - ispnp cleanups
>  - emu10k unlock on error fixes
>  - hpfs doesn't allow truncate to larger
> 
> pre8:
>  - Don't drop a megabyte off the old-style memory size detection
>  - remember to UnlockPage() in ramfs_writepage()
>  - 3c59x driver update from Andrew Morton
>  - egcs-1.1.2 miscompiles depca: workaround by Andrew Morton
>  - dmfe.c module init fix: Andrew Morton
>  - dynamic XMM support. Andrea Arkangeli.
>  - ReiserFS merge
>  - USB hotplug updates/fixes
>  - boots on real i386 machines
>  - blk-14 from Jens Axboe
>  - fix DRM R128/AGP dependency
>  - fix n_tty "canon" mode SMP race
>  - ISDN fixes
>  - ppp UP deadlock attack fix
>  - FAT fat_cache SMP race fix
>  - VM balancing tuning
>  - Locked SHM segment deadlock fix
>  - fork() page table copy race fix
> 
> -
> 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/
> 

-
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: problem exporting symbols from a lkm

[Keith Owens]

On Sun, 28 Jan 2001 19:16:06 +0100, 
SR (c) 2000 <[EMAIL PROTECTED]> wrote:
>my /proc/ksyms shows that the exported symbols from 8390.o are different
>from the other symbols because they have  "_R__ver_" in front of them.

FAQ http://www.tux.org/lkml/#s8-8

-
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: Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.xkernels?

[Shawn Starr]

>  Andrew Morton
> <[EMAIL PROTECTED]> wrote:

Ok, I've backed out of the low-latency patch but kept the timepegs patch in.
I've applied your reiserfs low-latency patch on a stock 2.4.1-pre11 kernel.

Let's see what happens :)

Shawn.



-
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: D state after applying ps hang patch

[Jens Axboe]

On Mon, Jan 29 2001, David Ford wrote:
> kernel 2.4.0-ac12
> 
> # ps -eo user,pid,args,wchan|egrep "imap|update|procmail"
> root 7 [kupdate]get_request_wait
> david  627 imapdget_request_wait
> david  752 procmail -f linu down
> david  761 procmail -f linu down
> david  799 procmail -f linu down
> david  854 procmail -f linu down
> david  886 procmail -f linu down
> david  847 imapdget_request_wait
> david 1079 procmail -f linu down
> david 3280 imapdinterruptible_sleep_on_locked
> david 3321 imapdinterruptible_sleep_on_locked
> 
> and the cpu load is artificially inflated to 9.17

Which patch specifically?

-- 
Jens Axboe
-
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: display problem with matroxfb

[Petr Vandrovec]

> > you do not have to specify vesa,pixclock,hslen and vslen, as you leave
> > them on defaults. 
> 
> Talking of defaults for matroxfb, would you consider limiting the fv: 
> value default to something reasonable that'll work on all monitors? It
> took me several recompiles/reboots to get a setting that would not put
> my monitor into auto-powerdown. If you defaulted to fv:60 then it 
> would work on 99.9% of monitors and then people could override that 
> upwards. I have a Philips 201B 21" monitor and was using 
> 
> append="video=matrox:vesa:400"
> 
> and this was setting too high a vertical refresh rate for the monitors
> capabilities. Adding fv:85 lets it work. The card is a Matrox 
> Millennium G200 8MB SDRAM.

Are you sure that it did not run out of horizontal sync, or something
like that? vesa:400 == vesa:0x190 == 1152x864/60Hz... And it powers
up in 60Hz, at least here ;-)

See timmings array in drivers/video/matrox/matroxfb_base.c - all videomodes
except XXXx400 powerups in fv=60Hz unless you specified fh/fv/pixclock.
XXXx400 powerups with fv=70Hz, like standard VGA does.
Petr Vandrovec
[EMAIL PROTECTED]

-
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: linux-2.4.1-pre11

[Arnaldo Carvalho de Melo]

Em Sun, Jan 28, 2001 at 06:55:25PM -0500, Louis Garcia escreveu:
> I am getting messages everytime I use the network from my RH7 + 
> kernel-2.4.1-pre11 system:
> 
> modprobe: modprobe: Can't locate module net-pf-10
> 
> I have checked my .config  and can't find that modules. This does not 
> happen with 2.4.0 kernel, only with the latest pre series maybe pre7 on.

you haven't included support for IPv6 and your distribution initscripts is
trying to load it for some reason, two solutions:

1. enable IPv6 in your kernel build
2. disable it in your /etc/modules.conf file, like this:

alias net-pf-10 off

- Arnaldo
-
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: Support for 802.11 cards?

[Joe deBlaquiere]

There is a rather informative discussion of wireless support at :

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.html

Though possibly a little out of date, the author of this obviously did 
their research. Kudos!

--
Joe

Michael H. Warfield wrote:

> On Sun, Jan 28, 2001 at 05:07:33PM -0500, John Jasen wrote:
> 
>> On Sun, 28 Jan 2001, Mike Pontillo wrote:
> 
> 
>>> I was wondering what 802.11 PCI cards anyone knows of that run
>>> under Linux-2.4. (or 2.2 for that matter)
>> 
> 
>> I _think_ a good many of the 802.11 wireless ISA and PCI cards are just
>> bus to PCMCIA adapters, so it would be a question of whether or not the
>> PCMCIA card is supported and if the bridge is supported.
> 
> 
>   Last I knew (straight from the Lucent people), the ISA bridge
> card worked fine and the PCI card did NOT work at all.  I've since
> confirmed that, first hand, myself (I currently have the ISA bridge in
> operation) on the 2.2 kernels.  The ISA bridge also works on the 2.4
> kernels but I have not retested the PCI bridge on 2.4.  The Lucent
> people claim that the Linux pcmcia people are aware of the problem.
> 
>   Mike



-
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/

D state after applying ps hang patch

[David Ford]

kernel 2.4.0-ac12

# ps -eo user,pid,args,wchan|egrep "imap|update|procmail"
root 7 [kupdate]get_request_wait
david  627 imapdget_request_wait
david  752 procmail -f linu down
david  761 procmail -f linu down
david  799 procmail -f linu down
david  854 procmail -f linu down
david  886 procmail -f linu down
david  847 imapdget_request_wait
david 1079 procmail -f linu down
david 3280 imapdinterruptible_sleep_on_locked
david 3321 imapdinterruptible_sleep_on_locked

and the cpu load is artificially inflated to 9.17

-d

--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



-
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: ECN: Clearing the air (fwd)

[Jamie Lokier]

Gregory Maxwell wrote:
> > > There is nothing silly with the decision, davem is simply a modern day
> > > internet hero.
> > 
> > No. If it were something essential, perhaps, but it's just a minor
> > performance tweak to cut packet loss over congested links. It's not
> > IPv6. It's not PMTU. It's not even very useful right now!
> 
> No. ECN is essential to the continued stability of the Internet. Without
> probabilistic queuing (i.e. RED) and ECN the Internet will continue to have
> retransmit synchronization and once congested stay congested until people get
> frustrated and give it up for a little bit.

There are other forms of probabilistic queuing, and RED+ECN may not be
one of the ones which scales as the net gets larger  We're keen on
latency, burst avoidance and other quality guarantees these days.  ECN
is an improvement of just RED alone of course.

-- Jamie
-
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: Linux-2.4.1-pre11

[Drew Bertola]

Drew Bertola writes:
> Drew Bertola writes:
> > Andrew's latest ACPI fixes (acpica-linux-2125 patched against
> > 2.4.0) compile fine here and don't hang on my Vaio after loading
> > tables.
> > 
> > That's a start.  I'll play around some more.
> 
> Unfortunately, pcmcia modules fail to load.  I can't understand the
> interaction.  
> 
> The message displayed on boot when starting the service says:
> 
> ds: no socket drivers loaded

I resolved this issue by using yenta_socket.

For my RH7.0 system, /etc/sysconfig/pcmcia needs to be edited to show:

PCIC=yenta_socket

-- 
Drew Bertola  | Send a text message to my pager or cell ... 
  |   http://jpager.com/Drew

-
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/

linux-2.4.1-pre11

[Louis Garcia]

I am getting messages everytime I use the network from my RH7 + 
kernel-2.4.1-pre11 system:

modprobe: modprobe: Can't locate module net-pf-10

I have checked my .config  and can't find that modules. This does not 
happen with 2.4.0 kernel, only with the latest pre series maybe pre7 on.

Lou

-
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: Poor SCSI drive performance on SMP machine, 2.2.16

[Johan Kullstam]

"paradox3" <[EMAIL PROTECTED]> writes:

> I did this:
> 
> date
> dd if=/dev/zero of=TESTFILE bs=1024 count=102400
> date
> sync
> date
> 
> 
> and I gave the time differences from the first to the last
> timestamp.

hmm.  i ran this on my old ppro200 with adaptec 2940uw and ibm
DDRS-39130W drive.

sophia(jk)$ cat foo 
date
dd if=/dev/zero of=TESTFILE bs=1024 count=102400
date
sync
sync
sync
date

i get

sophia(jk)$ time bash foo
Sun Jan 28 18:41:52 EST 2001
102400+0 records in
102400+0 records out
Sun Jan 28 18:42:11 EST 2001
Sun Jan 28 18:42:13 EST 2001

real0m20.803s
user0m0.400s
sys 0m8.780s

and this during a full kernel compile.

i get similar decent results using my other computer with a symbios
8751sp and fujitsu and seagate drives.

something must be messed up in a configuration somewhere.  are you
sure you are running the drive in synchronous ultra wide mode?  is you
termination good?

> Regards, Para-dox ([EMAIL PROTECTED])
> 
> 
> 
> - Original Message -
> From: "Bruce Harada" <[EMAIL PROTECTED]>
> To: "paradox3" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Sunday, January 28, 2001 2:31 PM
> Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16
> 
> 
> >
> > Hm. As a point of comparison, I use a similar system to yours (full SCSI,
> > though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the
> > same disk, in around 13 seconds. Where are you copying to the SCSI drive
> > from - the same drive, an IDE disk, CDROM? If IDE, what are its
> > particulars? (Check with hdparm -iI /dev/hd?)
> >
> > --
> > Bruce Harada
> > [EMAIL PROTECTED]
> >
> >
> >
> > On Sun, 28 Jan 2001 12:44:29 -0500
> > "paradox3" <[EMAIL PROTECTED]> wrote:
> > >
> > > I don't get any messages relating to the drives in any syslog output.
> > >
> > > >
> > > > Do you get messages like the ones below in /var/log/messages?
> > > >
> > > >   sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs
> > > >   sym53c875-0-<0,0>: tagged command queue depth set to 7
> > > >
> > > > In fact, do you get any messages in your log files that look like they
> > > > might be related?
> > > >
> > -
> > 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/
> >
> 
> -
> 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/

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
-
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: Linux-2.4.1-pre11

[Drew Bertola]

Drew Bertola writes:
> Andrew's latest ACPI fixes (acpica-linux-2125 patched against
> 2.4.0) compile fine here and don't hang on my Vaio after loading
> tables.
> 
> That's a start.  I'll play around some more.

Unfortunately, pcmcia modules fail to load.  I can't understand the
interaction.  

The message displayed on boot when starting the service says:

ds: no socket drivers loaded

-- 
Drew Bertola  | Send a text message to my pager or cell ... 
  |   http://jpager.com/Drew

-
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/

[IGNORE] Re: Kernel 2.4.1pre11 - Compile bug - Function prototype change?

[Shawn Starr]

Nevermind, the low-latency patch changed this function.. ignore
Shawn Starr wrote:

> in include/linux/mm.h:
>
> -extern void zap_page_range(struct mm_struct *mm, unsigned long address,
> unsigned long size, int actions);
> +extern void zap_page_range(struct mm_struct *mm, unsigned long address,
> unsigned long size)
>
> The function has changed and breaks memory.c ?
>
> memory.c:352: conflicting types for `zap_page_range'
> /usr/src/linux/include/linux/mm.h:396: previous declaration of
> `zap_page_range'
> make[2]: *** [memory.o] Error 1
> make[2]: Leaving directory `/usr/src/linux/mm'
> make[1]: *** [first_rule] Error 2
> make[1]: Leaving directory `/usr/src/linux/mm'
> make: *** [_dir_mm] Error 2
>
> Shawn.

-
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: Support for 802.11 cards?

[Michael H. Warfield]

On Sun, Jan 28, 2001 at 05:07:33PM -0500, John Jasen wrote:
> On Sun, 28 Jan 2001, Mike Pontillo wrote:

> > I was wondering what 802.11 PCI cards anyone knows of that run
> > under Linux-2.4. (or 2.2 for that matter)

> I _think_ a good many of the 802.11 wireless ISA and PCI cards are just
> bus to PCMCIA adapters, so it would be a question of whether or not the
> PCMCIA card is supported and if the bridge is supported.

Last I knew (straight from the Lucent people), the ISA bridge
card worked fine and the PCI card did NOT work at all.  I've since
confirmed that, first hand, myself (I currently have the ISA bridge in
operation) on the 2.2 kernels.  The ISA bridge also works on the 2.4
kernels but I have not retested the PCI bridge on 2.4.  The Lucent
people claim that the Linux pcmcia people are aware of the problem.

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
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/

Kernel 2.4.1pre11 - Compile bug - Function prototype change?

[Shawn Starr]

in include/linux/mm.h:

-extern void zap_page_range(struct mm_struct *mm, unsigned long address,
unsigned long size, int actions);
+extern void zap_page_range(struct mm_struct *mm, unsigned long address,
unsigned long size)

The function has changed and breaks memory.c ?

memory.c:352: conflicting types for `zap_page_range'
/usr/src/linux/include/linux/mm.h:396: previous declaration of
`zap_page_range'
make[2]: *** [memory.o] Error 1
make[2]: Leaving directory `/usr/src/linux/mm'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/mm'
make: *** [_dir_mm] Error 2

Shawn.

-
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: Poor SCSI drive performance on SMP machine, 2.2.16

[paradox3]

> It sounds to me like you have a SCSI bus problem. Have you checked
> termination? Cable quality? Cable lengths?

Forgive me, I'm rather ignorant of SCSI hardware.All that I have is a
cable (appears
to be good quality, came with motherboard) about 60 centimeters long going
from the
motherboard to my hard drive. There is an unused/empty port in between.

>
> Do you have tagged queuing enabled for aic7xxx? It's a config option
> and you can adjust the maximum queue depth. You can see the current
> settings by cat /proc/scsi/aic7xxx/0
>
/proc/scsi only contains a single file named "scsi" with brief info about
the drive
According to my last save kernel config, tagged command queueing is not
enabled by default.
Could this be the problem?


> Do you have write caching enabled on the drive? scsiinfo -c /dev/sdx
> will tell you if you do.
I don't seem to have scsiinfo.

>
> As a data point, I copied a 650MB file to another file on the same
> 10krpm disk and sync'ed in about the same time it takes you to write
> 100MB. I've also copied it from a slower 7200rpm disk to my 10krpm IBM
> drive and sync'ed in 1 min 19 secs which is about the read speed of
> the slower disk.
>
> --
> Trevor Hemsley, Brighton, UK.
> [EMAIL PROTECTED]
>

-
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: Linux-2.4.1-pre11

[Drew Bertola]

Andrew's latest ACPI fixes (acpica-linux-2125 patched against
2.4.0) compile fine here and don't hang on my Vaio after loading
tables.

That's a start.  I'll play around some more.

Jeff Garzik writes:
> Linus Torvalds wrote:
> > On Sun, 28 Jan 2001, Dieter Nützel wrote:
> > > > I just uploaded it to kernel.org, and I expect that I'll do the final
> > > > 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
> > > > pre-kernel works for you..
> > >
> > > Hello Linus,
> > >
> > > can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release
> > > updated: 1-25-2001)  in 2.4.1 final?
> > 
> > Does it fix stuff? Andrew?
> 
> I'm running it here..  No problems yet on my Toshiba test laptop, which
> is the same behavior (for me) on 2.4.0-pre10 vanilla.
> 
> ACPI changelog, from
> http://developer.intel.com/technology/IAPC/acpi/index.htm follows...
> 
> 
> > Summary of changes for this label: 01_25_01
> > 
> > Core ACPI CA Subsystem:
> > Restructured the implementation of object store support within the 
> > interpreter.  This includes support for the Store operator as well
> > as any ASL operators that include a target operand.
> > 
> > Partially implemented support for Implicit Result-to-Target conversion.
> > This is when a result object is converted on the fly to the type of
> > an existing target object.  Completion of this support is pending
> > further analysis of the ACPI specification concerning this matter.
> > 
> > CPU-specific code has been removed from the subsystem (hardware directory).
> > 
> > New Power Management Timer functions added
> > 
> > Linux OS Services Layer (OSL):
> > Moved system state transition code to the core, fixed it, and modified
> > Linux OSL accordingly.
> > 
> > Fixed C2 and C3 latency calculations.
> > 
> > We no longer use the compilation date for the version message on
> > initialization, but retrieve the version from AcpiGetSystemInfo().
> > 
> > Incorporated for fix Sony VAIO machines.
> > 
> > Documentation:
> > The Programmer Reference has been updated and reformatted.
> > 
> > ASL Compiler:
> > Version X2013:
> > Fixed a problem where the line numbering and error reporting could get out
> > of sync in the presence of multiple include files.
> -
> 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/

-- 
Drew Bertola  | Send a text message to my pager or cell ... 
  |   http://jpager.com/Drew

-
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: Moving from kernel 2.2 to 2.4

[John Jasen]

On Sun, 28 Jan 2001, Alec Smith wrote:

> I understand a large portion of the kernel 2.4 networking code was updated
> and/or completely replaced. Under 2.2 I have ipchains configured to do
> basic masquerading for my local LAN. Is there a straightforward guide which
> describes how to do masquerading and firewalling with 2.4 after moving up
> from 2.2?

http://netfilter.kernelnotes.org/unreliable-guides/

In general, you _have to_ upgrade modutils to at least a 2.3.x revision.

If you use devfs, you almost have to install devfsd, and you really need
to upgrade util-linux (there's a bug in older versions of /bin/login that
barf on the new tty scheme).

I usually do it by compiling and installing a 2.4 kernel; compiling,
installing devfsd (and adding an entry very early in rc.sysinit for it);
installing modutils; and installing util-linux -- then rebooting to test
the new kernel.


--
-- John E. Jasen ([EMAIL PROTECTED])
-- In theory, theory and practise are the same. In practise, they aren't.

-
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/

My appologies

[Thunder from the hill]

Hi, all,

My mailer (NS4.76/Linux 2.4.0-test10) has corrupted some messages and
send them at least twice. I apologize for that, please don't be worried.

Thunder
---
Woah... I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard
god...
-
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/

raiserfs, 2.4.1preX and nfs

[CaT]

I'm tempted to use raiserfs on a 45gig raid partition because I don't
want to grow old and die before it finishes fscking. The main hassle
is that that partition will be NFSed out and in the past there have
been mutterings of rfs hacing hassles with nfs. Have these been sorted?
Is there anything else I'd need to know about? A journalled fs would
be way nice to have and I need to make a decision between ext2 and rfs
asap.

any help would be greatly appreciated.

-- 
CaT ([EMAIL PROTECTED])*** Jenna has joined the channel.
 speaking of mental giants..
 me, a giant, bullshit
 And i'm not mental
- An IRC session, 20/12/2000

-
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/

Moving from kernel 2.2 to 2.4

[Alec Smith]

I understand a large portion of the kernel 2.4 networking code was updated 
and/or completely replaced. Under 2.2 I have ipchains configured to do 
basic masquerading for my local LAN. Is there a straightforward guide which 
describes how to do masquerading and firewalling with 2.4 after moving up 
from 2.2?

Thanks,
Alec

-
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/

Ram disk problems in 2.4.0ac12

[Keith Owens]

On Fri, 26 Jan 2001 17:46:12 -0800 (PST), 
"Sergey Kubushin" <[EMAIL PROTECTED]> wrote:
>Modules still don't load:
>
>=== Cut ===
>ide-mod.o: Can't handle sections of type 32131
>ide-probe-mod.o: Can't handle sections of type 256950710
>ide-disk.o: Can't handle sections of type 688840897
>ext2.o: Can't handle sections of type 69429248
>=== Cut ===

modutils has been ruled out as the cause of this problem.  The objects
are valid but when they are loaded they come up as corrupt.  Modules
work fine for me on 2.4.0-ac12, when they are loaded from disk.  Both
people reporting this bug are using initrd so the obvious culprit is
the ram disk code.

-
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/

ECN connectivity surveys

[Dax Kelson]

For test methodology and results go to this website, about 1/3 the way
down you'll see the ECN bullet point.

http://www.aciri.org/tbit/

Dax Kelson
Guru Labs

-
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: Linux-2.4.1-pre11

[Derek Wildstar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 28 Jan 2001, Linus Torvalds wrote:

> On Sun, 28 Jan 2001, Dieter Nützel wrote:
>
> > > I just uploaded it to kernel.org, and I expect that I'll do the final
> > > 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
> > > pre-kernel works for you..
> >
> > Hello Linus,
> >
> > can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release
> > updated: 1-25-2001)  in 2.4.1 final?
>
> Does it fix stuff? Andrew?
>
I just tried adding this to 2.4.1-pre11 and the compile failed, the
problem i've been having with ACPI is the kernel soft-hangs just after
loading the tables.  Using APM or no power management at all doesn't hang.

Hardware: Dell Inspiron 5000e, bios A04 (latest provided by Dell)

I have heard of some bugs in Dell's ACPI implementation, but since so many
people have dell machines it may be worth trying to work around, or even
detect the buggy implementation and disable ACPI with an error printed.

I can donate time if needed, just let me know what needs to be tested.

Thanks,
dwild
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjp0mHAACgkQhazASHM/AFMr0ACgjPE3+hzS05N5gt1qvl5Pgue7
smcAoIITSnkaawBXj+zToaajc9NgfrlK
=n4fr
-END PGP SIGNATURE-


-
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: Support for 802.11 cards?

[John Jasen]

On Sun, 28 Jan 2001, Mike Pontillo wrote:

>   I was wondering what 802.11 PCI cards anyone knows of that run
> under Linux-2.4. (or 2.2 for that matter)

I _think_ a good many of the 802.11 wireless ISA and PCI cards are just
bus to PCMCIA adapters, so it would be a question of whether or not the
PCMCIA card is supported and if the bridge is supported.



-
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/

Support for 802.11 cards?

[Mike Pontillo]

Hello,

I was wondering what 802.11 PCI cards anyone knows of that run 
under Linux-2.4. (or 2.2 for that matter)

I have looked at Documentation/Configure.help and done a quick
grep of all the documentation for "802.11" without much luck. I can't seem
to find anything related to the aironet cards that are mentioned in
./Configure.help -- it would be a matter of guesswork for me to figure out
which, if any, Cisco card is the same one that the kernel supports.

Does anyone know if anyone has released (working) drivers for
their 802.11 cards that have not been incorporated into the kernel?

I know D-Link has some 802.11 cards out right now, but I haven't
seen any mention of support for Linux. I know other D-Link devices are
supported; does anyone know if someone is working on a driver for their
card? If not, have they been receptive to requests for documentation?

Thanks!

Mike Pontillo

-
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: Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.xkernels?

[Shawn Starr]

Will this patch work with the low-latency patch? I have a few other patches in this 
kernel (one
fixing the ps hang issue).

Andrew Morton wrote:

> Shawn Starr wrote:
> >
> > Andrew, the patch HAS made a difference. For example, while untaring 
>glibc-2.2.1.tar.gz the
> > system was not sluggish (mouse movements in X) etc.
> >
> > Seems to be a go for latency improvements on this system.
>
> Shawn,
>
> could you please try this patch in a pristine 2.4.1-pre10? It
> gets reiserfs down to 4 milliseconds worst case.  If the
> system's interactivity is still sluggish with this then
> reiserfs isn't the cause.
>
> Thanks.
>
> --- linux-2.4.1-pre10/include/linux/reiserfs_fs.h   Tue Jan 23 19:28:16 2001
> +++ linux-akpm/include/linux/reiserfs_fs.h  Sun Jan 28 22:37:11 2001
> @@ -1161,7 +1161,8 @@
>  #define fs_generation(s) ((s)->u.reiserfs_sb.s_generation_counter)
>  #define get_generation(s) atomic_read (_generation(s))
>  #define FILESYSTEM_CHANGED_TB(tb)  (get_generation((tb)->tb_sb) != (tb)->fs_gen)
> -#define fs_changed(gen,s) (gen != get_generation (s))
> +#define __fs_changed(gen,s) (gen != get_generation (s))
> +#define fs_changed(gen,s) ({if (current->need_resched) schedule(); 
>__fs_changed(gen,s);})
>
>
>  /***/
> --- linux-2.4.1-pre10/fs/reiserfs/journal.c Tue Jan 23 19:28:15 2001
> +++ linux-akpm/fs/reiserfs/journal.cSun Jan 28 22:31:12 2001
> @@ -2649,6 +2649,8 @@
>}
>  #endif
>wait_on_buffer(bh) ;
> +  if (current->need_resched)
> +   schedule();
>  }
>  retry_count++ ;
>}
> @@ -3085,6 +3087,8 @@
>  /* copy all the real blocks into log area.  dirty log blocks */
>  if (test_bit(BH_JDirty, >bh->b_state)) {
>struct buffer_head *tmp_bh ;
> +  if (current->need_resched)
> +schedule();
>tmp_bh = getblk(p_s_sb->s_dev, reiserfs_get_journal_block(p_s_sb) +
>  ((cur_write_start + jindex) % JOURNAL_BLOCK_COUNT),
>p_s_sb->s_blocksize) ;
> -
> 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/

-
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: Q: Release of 2.4.1

[Linus Torvalds]

In article <01a301c0895e$b142cc90$[EMAIL PROTECTED]>,
mirabilos <[EMAIL PROTECTED]> wrote:
>Does 2.4.1 when released, include e.g. Jens' loop patch?
>Because it seems stable and loop else were buggy.

Only if Jens sends it to me in a timely fashion (which by now means
"real soon").

Linus
-
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: Linux-2.4.1-pre11

[Jeff Garzik]

Linus Torvalds wrote:
> On Sun, 28 Jan 2001, Dieter Nützel wrote:
> > > I just uploaded it to kernel.org, and I expect that I'll do the final
> > > 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
> > > pre-kernel works for you..
> >
> > Hello Linus,
> >
> > can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release
> > updated: 1-25-2001)  in 2.4.1 final?
> 
> Does it fix stuff? Andrew?

I'm running it here..  No problems yet on my Toshiba test laptop, which
is the same behavior (for me) on 2.4.0-pre10 vanilla.

ACPI changelog, from
http://developer.intel.com/technology/IAPC/acpi/index.htm follows...


> Summary of changes for this label: 01_25_01
> 
> Core ACPI CA Subsystem:
> Restructured the implementation of object store support within the 
> interpreter.  This includes support for the Store operator as well
> as any ASL operators that include a target operand.
> 
> Partially implemented support for Implicit Result-to-Target conversion.
> This is when a result object is converted on the fly to the type of
> an existing target object.  Completion of this support is pending
> further analysis of the ACPI specification concerning this matter.
> 
> CPU-specific code has been removed from the subsystem (hardware directory).
> 
> New Power Management Timer functions added
> 
> Linux OS Services Layer (OSL):
> Moved system state transition code to the core, fixed it, and modified
> Linux OSL accordingly.
> 
> Fixed C2 and C3 latency calculations.
> 
> We no longer use the compilation date for the version message on
> initialization, but retrieve the version from AcpiGetSystemInfo().
> 
> Incorporated for fix Sony VAIO machines.
> 
> Documentation:
> The Programmer Reference has been updated and reformatted.
> 
> ASL Compiler:
> Version X2013:
> Fixed a problem where the line numbering and error reporting could get out
> of sync in the presence of multiple include files.
-
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] enabling LKM for custom beeper

[Christian W. Zuckschwerdt]

Hi Linus, Alan,

this patch has proven to be stable an useable. It hasn't changed 
since 2.2.13.

The patch affects kd_mksound and kd_nosound which are responsible for
generating sound.
The default behaviour won't be changed but it's now possible for a LKM to
hook into these calls and change the way the system bell rings.

Changes in struct timer_list made a separate patch for 2.4.0 necessary.

Please incorporante into next release of 2.{2,4} if appropriate; TIA,

  cu.
:
Christian


--- drivers/char/vt.c.orig  Mon Aug  9 21:04:39 1999
+++ drivers/char/vt.c   Sun Jan 23 17:10:28 2000
@@ -92,18 +92,20 @@
 || (defined(__mips__) && !defined(CONFIG_SGI))
 
 static void
-kd_nosound(unsigned long ignored)
+_kd_nosound(unsigned long ignored)
 {
/* disable counter 2 */
outb(inb_p(0x61)&0xFC, 0x61);
return;
 }
 
-void
+void (*kd_nosound)(unsigned long ignored) = _kd_nosound;
+
+static void
 _kd_mksound(unsigned int hz, unsigned int ticks)
 {
static struct timer_list sound_timer = { NULL, NULL, 0, 0,
-kd_nosound };
+_kd_nosound };
 
unsigned int count = 0;
 
--- kernel/ksyms.c.orig Wed Oct 20 02:14:02 1999
+++ kernel/ksyms.c  Sun Jan 23 17:10:28 2000
@@ -62,6 +62,9 @@
 extern void free_dma(unsigned int dmanr);
 extern spinlock_t dma_spin_lock;
 
+extern void (*kd_nosound)(unsigned long ignored);
+extern void (*kd_mksound)(unsigned int count, unsigned int ticks);
+
 #ifdef CONFIG_MODVERSIONS
 const struct module_symbol __export_Using_Versions
 __attribute__((section("__ksymtab"))) = {
@@ -341,6 +344,8 @@
 EXPORT_SYMBOL(register_reboot_notifier);
 EXPORT_SYMBOL(unregister_reboot_notifier);
 EXPORT_SYMBOL(_ctype);
+EXPORT_SYMBOL(kd_nosound);
+EXPORT_SYMBOL(kd_mksound);
 EXPORT_SYMBOL(secure_tcp_sequence_number);
 EXPORT_SYMBOL(get_random_bytes);
 EXPORT_SYMBOL(securebits);
--- include/linux/vt_kern.h.origFri Oct 22 01:48:41 1999
+++ include/linux/vt_kern.h Sun Jan 23 17:10:28 2000
@@ -30,7 +30,7 @@
struct wait_queue *paste_wait;
 } *vt_cons[MAX_NR_CONSOLES];
 
-void (*kd_mksound)(unsigned int hz, unsigned int ticks);
+extern void (*kd_mksound)(unsigned int hz, unsigned int ticks);
 
 /* console.c */
 


--- linux-2.4.0-pristine/drivers/char/vt.c  Thu Jan  4 22:00:55 2001
+++ linux-2.4.0/drivers/char/vt.c   Sun Jan 28 21:01:37 2001
@@ -98,17 +98,19 @@
 || (defined(__arm__) && defined(CONFIG_HOST_FOOTBRIDGE))
 
 static void
-kd_nosound(unsigned long ignored)
+_kd_nosound(unsigned long ignored)
 {
/* disable counter 2 */
outb(inb_p(0x61)&0xFC, 0x61);
return;
 }
 
-void
+void (*kd_nosound)(unsigned long ignored) = _kd_nosound;
+
+static void
 _kd_mksound(unsigned int hz, unsigned int ticks)
 {
-   static struct timer_list sound_timer = { function: kd_nosound };
+   static struct timer_list sound_timer = { function: _kd_nosound };
unsigned int count = 0;
unsigned long flags;
 
--- linux-2.4.0-pristine/include/linux/vt_kern.hThu Jan  4 23:51:24 2001
+++ linux-2.4.0/include/linux/vt_kern.h Sun Jan 28 21:00:32 2001
@@ -30,7 +30,7 @@
wait_queue_head_t paste_wait;
 } *vt_cons[MAX_NR_CONSOLES];
 
-void (*kd_mksound)(unsigned int hz, unsigned int ticks);
+extern void (*kd_mksound)(unsigned int hz, unsigned int ticks);
 
 /* console.c */
 
--- linux-2.4.0-pristine/kernel/ksyms.c Wed Jan  3 01:45:37 2001
+++ linux-2.4.0/kernel/ksyms.c  Sun Jan 28 21:00:32 2001
@@ -62,6 +62,9 @@
 extern void free_dma(unsigned int dmanr);
 extern spinlock_t dma_spin_lock;
 
+extern void (*kd_nosound)(unsigned long ignored);
+extern void (*kd_mksound)(unsigned int count, unsigned int ticks);
+
 #ifdef CONFIG_MODVERSIONS
 const struct module_symbol __export_Using_Versions
 __attribute__((section("__ksymtab"))) = {
@@ -455,6 +458,8 @@
 EXPORT_SYMBOL(machine_halt);
 EXPORT_SYMBOL(machine_power_off);
 EXPORT_SYMBOL(_ctype);
+EXPORT_SYMBOL(kd_nosound);
+EXPORT_SYMBOL(kd_mksound);
 EXPORT_SYMBOL(secure_tcp_sequence_number);
 EXPORT_SYMBOL(get_random_bytes);
 EXPORT_SYMBOL(securebits);

Re: ECN fixes for Cisco gear

[Lincoln Dale]

Hi,

At 02:33 PM 28/01/2001 -0700, Dax Kelson wrote:
>Here is the fix for PIX:
>
>(see
>http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds23698)
> Bud ID: CSCds23698
> Headline: PIX sends RSET in response to tcp connections with ECN
>  bits set
> Product: PIX
> Component: fw
> Severity: 2 Status: R [Resolved]
> Version Found: 5.1(1)
> Fixed-in Version: 5.1(2.206) 5.1(2.207)  5.2(1.200)

fixes have been incorporated for a number of different release trains for 
the pix.

Fixed-In Version now covers releases:
 5.1(2.206), 5.1(2.207), 5.2(1.200), 6.0(0.100), 5.2(3.210)


cheers,

lincoln.
NB. it has been posted that Raptor filewalls will also apparently fail to 
allow connections with ECN bits set.

-
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: Linux-2.4.1-pre11

[Linus Torvalds]

On Sun, 28 Jan 2001, Dieter Nützel wrote:

> > I just uploaded it to kernel.org, and I expect that I'll do the final
> > 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the
> > pre-kernel works for you..
> 
> Hello Linus,
> 
> can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release 
> updated: 1-25-2001)  in 2.4.1 final?

Does it fix stuff? Andrew?

Linus

-
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: Renaming lost+found

[Mo McKinlay]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Today, H. Peter Anvin ([EMAIL PROTECTED]) wrote:

  > Hello people... the original question was: can lost+found be
  > *renamed*, i.e. does the tools (e2fsck ) use "/lost+found" by name,
  > or by inode?  As far as I know it always uses the same inode number
  > (11), but I don't know if that is anywhere enforced.

I seem to recall e2fsck complaining when I renamed lost+found, but that
may well be a consistency check. Don't quote me on this, though.

Mo.

- -- 
Mo McKinlay
[EMAIL PROTECTED]
- -
GnuPG/PGP Key: pub  1024D/76A275F9 2000-07-22





-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjp0kgYACgkQRcGgB3aidfngIACdH4Ze9KRUS/jExERYM0Jt0n4e
WyMAoKxzOr7KnVeEoHCHKlCBjNcncx8U
=myDq
-END PGP SIGNATURE-

-
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: Renaming lost+found

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Thunder from the hill <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> > A file-system without a lost+found directory is like love without sex.
> You mean, possible but leaving you unsatisfied? Well, I think a file
> system without a lost+found is a lot worse.
> 

Hello people... the original question was: can lost+found be
*renamed*, i.e. does the tools (e2fsck ) use "/lost+found" by name,
or by inode?  As far as I know it always uses the same inode number
(11), but I don't know if that is anywhere enforced.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

ECN fixes for Cisco gear

[Dax Kelson]

In Sept of 2000, I did a survey of 30,000 websites and found that 8% of
them were unreachable from an ECN capable client.  Two major culprits were
identified, the Cisco PIX and Local Director.  To Cisco's credit, fixes
were released quickly.

Here is a message I sent with info about the Cisco updates:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0010.1/1205.html

Here is the fix for PIX:


(see
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds23698)
Bud ID: CSCds23698
Headline: PIX sends RSET in response to tcp connections with ECN
 bits set
Product: PIX
Component: fw
Severity: 2 Status: R [Resolved]
Version Found: 5.1(1) Fixed-in Version: 5.1(2.206) 5.1(2.207)
 5.2(1.200)


Here is the fix for Local Director:


(see
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCds40921)
Bug Id : CSCds40921
 Headline: LD rejects syn with reserved bits set in flags field of TCP hdr
 Product: ld
 Component: rotor
 Severity: 3 Status: R [Resolved]
 Version Found: 3.3(3) Fixed-in Version: 3.3.3.107


Dax Kelson
Guru Labs

-
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/

ISAPnP Buglet in 2.4.0

[Steven Walter]

Problem in a nutshell:  The module for my soundcard (cs4232.o) won't
load until after a "cat /proc/isapnp" has been run.  I'm guessing
(though not sure) that this isn't the intended behavior.  ISAPnP is
compiled into the kernel, and detects the card correctly during boot, as
evidenced by the boot messages.  Doesn't seem like a huge deal, any idea
where the problem lies?
-- 
-Steven
Never ask a geek why, just nod your head and slowly back away.
-
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: CPU error codes

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:James Sutherland <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Thu, 25 Jan 2001, Alan Cox wrote:
> 
> > > I was wondering if someone could tell me where I can find
> > > Xeon Pentium III cpu error messages/codes
> > 
> > In the intel databook. Generally an MCE indicates hardware/power/cooling
> > issues
> 
> Doesn't an MCE also cover some hardware memory problems - parity/ECC
> issues etc?
> 

Not main memory, but it does include cache errors.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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] aci.c and related files reworked for 2.4.0

[Robert Siemer]

Hi Thomas an linux-sound (:  !

I made up a new patch for the aci.c and related files. It's for
miroSOUND sound cards.

It applies cleanly against 2.4.0, but problems can occur when not
compiled as modules. - I will work on this issue, but my box has
problems booting completely into 2.4.0 (PCI IRQ routing...). So it
will take some time.

The patch is technically the same as in my initially post on
linux-kernel for test8:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0009.2/0260.html


Thomas, please try it and tell me if it fits your needs.

Further I would be pleased to hear from more people using this sound
hardware... (:


Bye,
Robert

diff -urN -X dontdiff linux-vanilla/CREDITS linux/CREDITS
--- linux-vanilla/CREDITS   Sun Dec 31 18:27:57 2000
+++ linux/CREDITS   Sat Jan 27 16:25:01 2001
@@ -2427,6 +2427,14 @@
 S: San Jose, California
 S: USA
 
+N: Robert Siemer
+E: [EMAIL PROTECTED]
+P: 2048/C99A4289 2F DC 17 2E 56 62 01 C8  3D F2 AC 09 F2 E5 DD EE
+D: miroSOUND PCM20 radio RDS driver, ACI rewrite
+S: Klosterweg 28 / i309
+S: 76131 Karlsruhe
+S: Germany
+
 N: Jaspreet Singh
 E: [EMAIL PROTECTED]
 W: www.sangoma.com
diff -urN -X dontdiff linux-vanilla/Documentation/Configure.help 
linux/Documentation/Configure.help
--- linux-vanilla/Documentation/Configure.help  Thu Jan  4 22:00:55 2001
+++ linux/Documentation/Configure.help  Sat Jan 27 16:25:02 2001
@@ -14336,7 +14336,7 @@
 
   If unsure, say Y.
 
-ACI mixer (miroPCM12/PCM20)
+ACI mixer (miroSOUND PCM1-pro/PCM12/PCM20)
 CONFIG_SOUND_ACI_MIXER
   ACI (Audio Command Interface) is a protocol used to communicate with
   the microcontroller on some sound cards produced by miro, e.g. the
@@ -14345,8 +14345,8 @@
 
   This Voxware ACI driver currently only supports the ACI functions on
   the miroSOUND PCM12 and PCM20 cards. On the PCM20, ACI also controls
-  the radio tuner. This is supported in the video4linux
-  radio-miropcm20 driver.
+  the radio tuner. This is supported in the video4linux miropcm20
+  driver.
 
 SB32/AWE support
 CONFIG_SOUND_AWE32_SYNTH
@@ -16087,11 +16087,11 @@
   say M here and read Documentation/modules.txt. The module will be
   called i2c-parport.o.
 
-Miro PCM20 Radio
+miroSOUND PCM20 radio
 CONFIG_RADIO_MIROPCM20
   Choose Y here if you have this FM radio card. You also need to say Y
-  to "ACI mixer (miroPCM12/PCM20)" (in "additional low level sound
-  drivers") for this to work.
+  to "ACI mixer (miroSOUND PCM1-pro/PCM12/PCM20)" (in "Sound") for
+  this to work.
 
   In order to control your radio card, you will need to use programs
   that are compatible with the Video for Linux API. Information on 
@@ -16101,7 +16101,7 @@
   If you want to compile this driver as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want),
   say M here and read Documentation/modules.txt. The module will be
-  called radio-miropcm20.o
+  called miropcm20.o
 
 GemTek Radio Card
 CONFIG_RADIO_GEMTEK
diff -urN -X dontdiff linux-vanilla/Documentation/sound/PCM1-pro 
linux/Documentation/sound/PCM1-pro
--- linux-vanilla/Documentation/sound/PCM1-pro  Tue Apr 13 01:18:27 1999
+++ linux/Documentation/sound/PCM1-pro  Thu Jan  1 01:00:00 1970
@@ -1,17 +0,0 @@
-In Documentation/sound/README.OSS was a remark saying noone was sure the
-mixer on the PCM1-pro worked with the ACI driver. Well, it does.
-I've been using the drivers for the MAD16 and the driver for the mixer
-since kernel 2.0.32 with a MiroSound PCM1-pro and it works great.
-
-I've got it working with the following configuration:
-
-MAD16 audio I/O base = 530
-MAD16  audio IRQ = 7
-MAD16 Audio DMA = 1
-MAD16 MIDI I/O = 330
-MAD16 MIDI IRQ = 9
-
-And I've enabled the ACI mixer (miro PCM12) .
-
-
-Bas van der Linden.
diff -urN -X dontdiff linux-vanilla/Documentation/sound/README.OSS 
linux/Documentation/sound/README.OSS
--- linux-vanilla/Documentation/sound/README.OSSFri Jul 28 21:50:52 2000
+++ linux/Documentation/sound/README.OSSSat Jan 27 16:23:15 2001
@@ -17,6 +17,7 @@
 document can be still interesting and very helpful.
 
 [ File edited 17.01.1999 - Riccardo Facchetti ]
+[ Edited miroSOUND section 17.09.2000 - Robert Siemer ]
 
 OSS/Free version 3.8 release notes
 --
@@ -1325,26 +1326,38 @@
 miroSOUND
 -
 
-The miroSOUND PCM12 has been used successfully. This card is based on
-the MAD16, OPL4, and CS4231A chips and everything said in the section
-about MAD16 cards applies here, too. The only major difference between
-the PCM12 and other MAD16 cards is that instead of the mixer in the
-CS4231 codec a separate mixer controlled by an on-board 80C32
-microcontroller is used. Control of the mixer takes place via the ACI
-(miro's audio control interface) protocol that is implemented in a
-separate lowlevel driver. Make sure you compile this ACI driver
-together with the normal MAD16 support when you use a miroSOUND PCM12
-card. The ACI mixer is controlled by /dev/mixer and the 

Re: [PATCH] doc update/fixes for sysrq.txt

[Jeremy M. Dolan]

On Sun, 28 Jan 2001 11:35:50 +, David Ford wrote:
> AFAIK, this hasn't ever been true.  I have never had to specifically
> enable it at run time.

I was suspicious of that in the old doc but thought I'd leave it in...
Should have asked for feedback on it, but you caught it anyway, thanks!

Here's a patch against the first that simply removes the lines.

/jmd


--- Documentation/sysrq.txt~Sun Jan 28 14:41:44 2001
+++ Documentation/sysrq.txt Sun Jan 28 14:41:52 2001
@@ -15,9 +15,6 @@
 
 echo "0" > /proc/sys/kernel/sysrq
 
-Note that previous versions disabled sysrq by default, and you were required
-to specifically enable it at run-time. That is not the case any longer.
-
 *  How do I use the magic SysRq key?
 
 On x86   - You press the key combo 'ALT-SysRq-'. Note - Some
-
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/