Re: [PATCH] alignment issue with ipchains

[NIIBE Yutaka]

David S. Miller wrote:
 > Could you send me a patch which fixes the problem in this way?

Sure.  Here is the one.  The occurrence of the IP_XXX corresponds the
one in switch/case.

Thank you for your time,

--- linux-2.4.0-test8-pre6/net/ipv4/ip_sockglue.c   Fri Aug 11 05:01:26 2000
+++ linux/net/ipv4/ip_sockglue.cSat Sep  9 14:42:25 2000
@@ -380,15 +380,22 @@ int ip_setsockopt(struct sock *sk, int l
 {
int val=0,err;
 
-   if(optlen>=sizeof(int)) {
-   if(get_user(val, (int *) optval))
-   return -EFAULT;
-   } else if(optlen>=sizeof(char)) {
-   unsigned char ucval;
-   if(get_user(ucval, (unsigned char *) optval))
-   return -EFAULT;
-   val = (int)ucval;
-   }
+   if (optname == IP_PKTINFO || optname == IP_RECVTTL
+   || optname == IP_RECVTOS || optname == IP_RECVOPTS
+   || optname == IP_RETOPTS || optname == IP_TOS
+   || optname == IP_TTL || optname == IP_HDRINCL
+   || optname == IP_MTU_DISCOVER || optname == IP_RECVERR
+   || optname == IP_MULTICAST_TTL || optname == IP_MULTICAST_LOOP
+   || optname == IP_ROUTER_ALERT)
+   if(optlen>=sizeof(int)) {
+   if(get_user(val, (int *) optval))
+   return -EFAULT;
+   } else if(optlen>=sizeof(char)) {
+   unsigned char ucval;
+   if(get_user(ucval, (unsigned char *) optval))
+   return -EFAULT;
+   val = (int)ucval;
+   }
/* If optlen==0, it is equivalent to val == 0 */

if(level!=SOL_IP)
-
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/

[PROBLEM] - Kernel 2.4.0-test8 panics (addendum: rebooted suddenly while writing about the "panic" problem .. this is my second attempt)

[Ravindra Jaju]

Hello.

My kernel panicked at /net/core/skbuff.c (line: 93 "BUG();")
That was the first time when I booted into it.

The second time, it was fine till about 2 hours, while I was writing *this* mail. 
Rebooted all of 
a sudden (no idea as to where the problem was. It was _quick_. No messages, nothing).

This is my first post. Please do correct me if I've supplied incomplete information. 
(the output
of dmesg follows)

regards,
jaju


Linux version 2.4.0-test8 ([EMAIL PROTECTED]) (gcc version 2.96 2724 
(experimental)) #4 Sat Sep 9 03:55:44 IST 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 4000 @ 000dc000 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 07f0 @ 0010 (usable)
 BIOS-e820: 0004 @ fffc (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 c009fc00 for 4096 bytes.
On node 0 totalpages: 32768
zone(0): 4096 pages.
zone(1): 28672 pages.
zone(2): 0 pages.
mapped APIC to e000 (01203000)
Kernel command line: BOOT_IMAGE=2.4-8 ro root=308 BOOT_FILE=/boot/2.4.0-8 
video=matrox:vesa:443
Initializing CPU#0
Detected 549964677 Hz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1097.73 BogoMIPS
Memory: 126972k/131072k available (1140k kernel code, 3712k reserved, 85k data, 204k 
init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
CPU: Intel Pentium III (Katmai) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xfdb91, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: ST317221A, ATA DISK drive
hdb: ST38420A, ATA DISK drive
hdc: SAMSUNG CD-ROM SC-152B, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 33683328 sectors (17246 MB) w/512KiB Cache, CHS=2096/255/63, UDMA(33)
hdb: 16841664 sectors (8623 MB) w/512KiB Cache, CHS=1048/255/63, UDMA(33)
Partition check:
 hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9 hda10 >
 hdb: hdb1 hdb2 hdb3 < hdb5 hdb6 hdb7 hdb8 > hdb4
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
kmem_create: Forcing size word alignment - nfs_fh
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 204k freed
Adding Swap: 136512k swap-space (priority -1)
es1371: version v0.26 time 07:40:11 Sep  9 2000
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
es1371: found es1371 rev 8 at io 0xd800 irq 10
es1371: features: joystick 0x0
ac97_codec: AC97 audio codec, id: 0x4352:0x5913 (Cirrus Logic CS4297A)
8139too Fast Ethernet driver 0.9.8 loaded
eth0: RealTek RTL8139 Fast Ethernet board found at 0xef00, IRQ 9
eth0:   Chip is 'RTL-8139B'
eth0:   MAC address 00:50:bf:0a:4a:bc.
eth1: RealTek RTL8139 Fast Ethernet board found at 0xee00, IRQ 12
eth1:   Chip is 'RTL-8139A'
eth1:   MAC address 00:00:e8:7c:a2:98.
eth0: Setting full-duplex based on MII #32 link partner ability of 45e1.
eth1: Setting full-duplex based on MII #32 link partner ability of 45e1.
eth0: Promiscuous mode enabled.
device eth0 entered promiscuous mode
ip_tables: (c)2000 Netfilter core team
-
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] alignment issue with ipchains

[David S. Miller]

   From: NIIBE Yutaka <[EMAIL PROTECTED]>
   Date: Sat, 09 Sep 2000 12:18:28 +0900

   I'd like to explain my point clearly.  My point is that accessing
   with get_user as int is questionable.  In my case, it's string.  I
   don't think all the string argment to the kernel should be aligned.

Thank you for the explanation.

I agree with your logic, but not with the fix you sent here before.

I would much rather see a test for the socket option cases that use
the "val", and in those cases do the get_user calls.  Ie. something
like:

if (optname == X || optname == Y || optname == Z || ...) {
if(optlen>=sizeof(int)) {
if(get_user(val, (int *) optval))
   ...
}

Could you send me a patch which fixes the problem in this way?

Thank you.

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: Whining about MIME formatted email

[Albert D. Cahalan]

Ragnar Hojland Esp writes:
> On Fri, Sep 08, 2000 at 11:10:13PM +0200, Kurt Garloff wrote:
> > Stop making stupid statements like this, please, and comparing well-d=
> efined
> > RFC standards with proprietary formats.=20
> > MIME is a way for people that happen to use non 7bit characters to be=
>  able
> > to print their name correctly, even in presence of MTAs somewhere in =
> between
> 
> You can say it louder but you can't say it clearer.  I'd love to know t=
> hat
> my surname shows up correctly everywhere.   BTW, mutt shows M=
> IME
> patches in plain text without any problems 


That would be the "H=F8jland" in your .sig, right?
No problem, '=' is a standard character.

My MUA has been RFC-compliant since before this "MIME" thing existed,
so I can see the full ASCII character set. That includes the carat,
underscore, back tick, backslash, vertical bar, at symbol, octothorpe,
and both braces.


> --=20
> /|  Ragnar H=F8jland Freedom - Linux - OpenGL  Fingerprint =
>  94C4B
> \ o.O|   2F0D27DE025BE2=
> 302C
>  =3D(_)=3D  "Thou shalt not follow the NULL pointer for  104B78C56 =
> B72F0822
>U chaos and madness await thee at its end."   hkp://keys.pgp=
> =2Ecom
> 
> Handle via comment channels only.
> -
> 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: write permissions and root.

[Andrew McNabb]

On Fri, 8 Sep 2000, Adam wrote:

> Hmm can someone remind me what (if) is the reason root is not bound by 
> write permissions? 

Because linux is not a trusted operating system.  On linux,
root = uid 0 = superuser. 


> [root@pepsi /tmp]# su adam
> [adam@pepsi /tmp]$ touch blah
> [adam@pepsi /tmp]$ chmod -w blah 
> [adam@pepsi /tmp]$ echo hi > blah 
> bash2: blah: Permission denied
> [adam@pepsi /tmp]$ exit
> exit
> [root@pepsi /tmp]# echo hi > blah 
> [root@pepsi /tmp]# ls -l blah
> -r--r--r--1 adam adam3 Sep  8 21:11 blah
> 
> if this matters it is 2.4.0-test7

Correct me if I'm wrong, but I believe that all non-TOS
unices have behaved this way since the 70s.


--
Andrew McNabb
[EMAIL PROTECTED]
http://www.mcnabbs.org/

-
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: Whining about MIME formatted email

[Ragnar Hojland Espinosa]

On Fri, Sep 08, 2000 at 11:10:13PM +0200, Kurt Garloff wrote:
> Stop making stupid statements like this, please, and comparing well-defined
> RFC standards with proprietary formats. 
> MIME is a way for people that happen to use non 7bit characters to be able
> to print their name correctly, even in presence of MTAs somewhere in between

You can say it louder but you can't say it clearer.  I'd love to know that
my surname shows up correctly everywhere.   BTW, mutt shows MIME
patches in plain text without any problems 
-- 
/|  Ragnar Højland Freedom - Linux - OpenGL  Fingerprint  94C4B
\ o.O|   2F0D27DE025BE2302C
 =(_)=  "Thou shalt not follow the NULL pointer for  104B78C56 B72F0822
   U chaos and madness await thee at its end."   hkp://keys.pgp.com

Handle via comment channels only.
-
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] alignment issue with ipchains

[NIIBE Yutaka]

Hi David, 

I'd like to explain my point clearly.  My point is that accessing with
get_user as int is questionable.  In my case, it's string.  I don't
think all the string argment to the kernel should be aligned.

David S. Miller wrote:
 > Why not make sure in the user tools that the argument is properly
 > aligned to 4 bytes?

Because (I think) it's not needed by the interface definition.

 > I would really like to see specific examples of the failure before I
 > consider this issue further.

OK, here's example (I'm talking about ipchains 1.3.8 or 9):

   # ipchains -F input

Here, on SuperH, the string of command line argument "input" is not
aligned to 4-byte boundary.  The argument to main argv ("input") goes
through the setsockopt.

main --> flush_entries --> libipfwc.c:ipfwc_flush_entries
--> do_setsockopt --> setsockopt

For the optname IP_FW_APPEND...IP_FW_MASQ_CTL, the type of the value
is not integer but string.  Accessing as int is rather violent.

I guess that on Sparc or Alpha the command line argument string is
4-byte aligned.
-- 
-
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] Cache alias issues for swapped page

[NIIBE Yutaka]

For SH-4 (with virtually indexed, physically tagged cache), we have
problems with swap.

I think that there're bugs in do_swap_page and try_to_swap_out.
I've read "Documentation/cachetlb.txt" and I know that now is
the transition to newer interface, but we need a fix at the moment
with old interface.

(1) Flush is needed at do_swap_page

With current implementation, cache is flushed when it is swapped in
synchronously.  When it is swapped in asynchronously
(swapfile.c:try_to_unuse, memory.c:swapin_readahead), there's no
flushing which causes alias.

(2) Flush is needed at try_to_swap

When swap out, flushing is needed for physical tag too.

Here's a patch to indicate the issues.

diff -ruN linux-2.4.0-test8-pre6/mm/memory.c linux/mm/memory.c
--- linux-2.4.0-test8-pre6/mm/memory.c  Thu Sep  7 09:56:19 2000
+++ linux/mm/memory.c   Mon Sep  4 15:25:17 2000
@@ -1068,9 +1068,6 @@
unlock_kernel();
if (!page)
return -1;
-
-   flush_page_to_ram(page);
-   flush_icache_page(vma, page);
}
 
mm->rss++;
@@ -1093,6 +1090,8 @@
} else
UnlockPage(page);
 
+   flush_page_to_ram(page);
+   flush_icache_page(vma, page);
set_pte(page_table, pte);
/* No need to invalidate - it was non-present before */
update_mmu_cache(vma, address, pte);
diff -ruN linux-2.4.0-test8-pre6/mm/vmscan.c linux/mm/vmscan.c
--- linux-2.4.0-test8-pre6/mm/vmscan.c  Thu Sep  7 09:56:19 2000
+++ linux/mm/vmscan.c   Mon Sep  4 15:25:18 2000
@@ -138,6 +138,7 @@
 *
 * That would get rid of a lot of problems.
 */
+   flush_page_to_ram(page);
flush_cache_page(vma, address);
if (vma->vm_ops && (swapout = vma->vm_ops->swapout)) {
int error;
-- 
-
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] alignment issue with ipchains

[David S. Miller]

   From: NIIBE Yutaka <[EMAIL PROTECTED]>
   Date:Sat, 09 Sep 2000 11:25:28 +0900

   Here's a patch, avoiding useless access.

This seems like a large ugly hack.

Why not make sure in the user tools that the argument is properly
aligned to 4 bytes?

IP-chains works fine on Alpha and Sparc which have the same alignment
restrictions as Super-H for loading 4-byte values.  Thus why is SH so
special and require this ugly hack?

I would really like to see specific examples of the failure before I
consider this issue further.

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/

[PATCH] alignment issue with ipchains

[NIIBE Yutaka]

With ipchains, we have alignment problem.  H. Kambara
<[EMAIL PROTECTED]> found that it core dumps on SuperH machine.

The cause of this problem is get_user accesses wrongly in
ip_setsockopt.

Here's a patch, avoiding useless access.

diff -ruN linux-2.4.0-test8-pre6/net/ipv4/ip_sockglue.c kernel/net/ipv4/ip_sockglue.c
--- linux-2.4.0-test8-pre6/net/ipv4/ip_sockglue.c   Fri Aug 11 05:01:26 2000
+++ kernel/net/ipv4/ip_sockglue.c   Thu Aug 24 16:30:33 2000
@@ -39,6 +39,9 @@
 #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
 #include 
 #endif
+#ifdef CONFIG_NETFILTER
+#include 
+#endif
 
 #include 
 #include 
@@ -380,15 +383,18 @@
 {
int val=0,err;
 
-   if(optlen>=sizeof(int)) {
-   if(get_user(val, (int *) optval))
-   return -EFAULT;
-   } else if(optlen>=sizeof(char)) {
-   unsigned char ucval;
-   if(get_user(ucval, (unsigned char *) optval))
-   return -EFAULT;
-   val = (int)ucval;
-   }
+#ifdef CONFIG_NETFILTER
+   if (!(optname >= IP_FW_APPEND && optname <= IP_FW_MASQ_CTL))
+#endif
+   if(optlen>=sizeof(int)) {
+   if(get_user(val, (int *) optval))
+   return -EFAULT;
+   } else if(optlen>=sizeof(char)) {
+   unsigned char ucval;
+   if(get_user(ucval, (unsigned char *) optval))
+   return -EFAULT;
+   val = (int)ucval;
+   }
/* If optlen==0, it is equivalent to val == 0 */

if(level!=SOL_IP)
-
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-required!] Recent kernels show problems in handling VERY large HDs

[Andreas Eibach]

Hi everybody,

my name is Andreas Eibach and it's the first time I'm here.

I'm aware of the fact that posting here requires having read ALL FAQs and
available documents before doing that.
I did this, of course.

But since the problem seems brand-new (due to the fact that these huge-sized
HDs are very new), I could, however, find questions and answers on the ML
archives, but still no solution of this recent problem.

Please apologize this being longer than usual posts, but I feel the need to
go into detail very much so that the problem can be fixed soon.

My setup is: (relevant things only)

AMD K6-266 (oc'ed  @300)
Motherboard GA-586 SG  w/AWARD BIOS 4.51PG
(no updates available anymore from the manufacturer! 586sg  BIOS rev. is
1.15)
SDRAM
Maxtor 60 GB hard drive:
   - Capacity Limitation Jumper J46 APPLIED (otherwise BIOS does not
recognize the HD at all!)
   (note: this lets the HD look like a 32 GB one, causing total confusion
with the kernel)
   - EZDrive (aka MaxBlast) APPLIED (as _prescribed_ by original
documentation for older BIOSes)

---

Linux SuSE 6.2, Kernels 2.2.10, 2.2.15, 2.4.0 test4
NOT TESTED YET: 2.2.17 (should I give it a try?)
Util-Linux 2.9f (from the distribution)
(Note: I've got latest 2.10o tarball here now, one of my suspects causing
the errors below was Fdisk at first)

Now my outputs: (slightly shortened)


Linux version 2.4.0-test4 (root@janus) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #2 Wed Sep 6 16:38:45 MEST 2000
[...]
Kernel command line: root=/dev/hdc11 ro single BOOT_IMAGE=bzi_240
Initializing CPU#0
Detected 300681014 Hz processor.
[...]
CPU: AMD-K6tm w/ multimedia extensions stepping 00
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
[...] (pci stuff)
[...] (net4 stuff)
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 01
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS5591
ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:pio, hdd:pio
^^
hda: Maxtor 96147U8, ATA DISK drive
^^
hdb: CD-532E-A, ATAPI CDROM drive
hdc: IBM-DTTA-350840, ATA DISK drive
hdd: ST33232A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 120060864 sectors (61471 MB) w/2048KiB Cache, CHS=7473/255/63, UDMA(33)
[...] (hdc: / hdd: / hdb:)
Uniform CD-ROM driver Revision: 3.11
Partition check:
 hda:hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: status timeout: status=0xd8 { Busy }

OUCH...

hda: DMA disabled
hdb: DMA disabled
hda: drive not ready for command

OUCHIE...

ide0: reset: success
 [EZD] [remap 0->1] [7473/255/63] hda1 hda2 hda3 < hda5 hda6 hda7 hda8 hda9
hda10 hda11 hda12hda: read_intr: status=0x59 { DriveReady SeekComplete
DataRequest Error }
hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
ide0: reset: success
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
ide0: reset: success
hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265, sector=0
end_request: I/O error, dev 03:0d (hda), sector 0

AYEEE  OH MY GOD...

 > hda4
 hdc: [PTBL] [1027/255/63] hdc3 < hdc5 hdc6 hdc7 hdc8 hdc9 hdc10 hdc11 hdc12
>
 hdd: [PTBL] [781/128/63] hdd3 < hdd5 hdd6 hdd7 hdd8 >
[...]
[EXT II FS 0.5b, 95/08/09, bs=1024, fs=1024, gc=11, bpg=8192, ipg=4016,
mo=160b]

Well this doesn't look _that_ nice... :)

So what did I do?

Since my Maxtor HD contains already 8 Windows partitions and is supposed to
"get Linux" on the 3rd third, I deleted everything except those Windows
partitions. Then I 

Re: Availability of kdb

[Oliver Xymoron]

On Wed, 6 Sep 2000, Linus Torvalds wrote:

> Apparently, if you follow the arguments, not having a kernel debugger
> leads to various maladies:
>  - you crash when something goes wrong, and you fsck and it takes forever
>and you get frustrated.
>  - people have given up on Linux kernel programming because it's too hard
>and too time-consuming
>  - it takes longer to create new features.
> 
> And nobody has explained to me why these are _bad_ things.

There are those, but there are others, most of which are so obvious[1]
we're not mentioning them, assuming you're familiar with them too. I
usually eschew debuggers as well, but I'm beginning to suspect that you've
spent so much of your programming life immersed in the kernel that you
haven't used a debugger enough to know what sorts of things it's actually
good for. Not all the world's a nail, but there are times when the bigger
hammer approach is the right one.

One of these days you should give revision control a try too. Not to
mention bug tracking. :P

[1] eg I've found many a compiler bug in 5 minutes of single stepping that
days of eyeballing source and adding printfs failed to discover. 

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."

-
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: Notebook disk spindown

[Andre Hedrick]

On Fri, 8 Sep 2000, Russell King wrote:

> Jamie Lokier writes:
> > With laptops, people are willing
> > to assume the RAM is reliable -- accidentally pulling the plug out won't
> > lose the data.
> 
> But a buggy apm implementation and the battery running down can.
> 
> (and I've seen my Thinkpad 380XD with RH's 2.2.14-5.0 kernel and
> RH's apmd run itself dead.  Kill apmd and it'll do the right thing
> and suspend, then hibernate.  And no, I haven't even attempted to
> debugg it yet).

Russell,

You know that it would take me 25 minutes or less to fix the code if I had
a full native taskfile.  This would allow a (void *)(void) to be set in
kernel apmd and have all the drive data and callouts.

But that is not doable until 2.5, sorry.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

-
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] Name-clash between paride & hamradio

[David Weinehall]

On Fri, 8 Sep 2000, Linus Torvalds wrote:

> 
> 
> On Sat, 9 Sep 2000, David Weinehall wrote:
> > 
> > This patches changes the names of the init-functions for the
> > hamradio-drivers pt.c and pi2.c. None of the new names are used anywhere
> > else in the kernel.
> 
> Patch applied, but I also wonder why these things are global names anyway?
> Why not just change them to be static?

Beats the hell out of me, but as I attributed to some rational decision
what I didn't want to attribute to stupidity, I decided this patch was
the sanest... Maintainers of Hamradio (and ParIDE), feel free to comment.


/David
  _ _ 
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky // 
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: [packet-writing] [release] packet-0.0.2c

[adam]

> Try attached patch, I hadn't noticed the segment counts were wrong
> because I have implicit recounting.

Yes, this patch fixes the problem, thanks. Once I aplied I could mount the
cd and write a file to it, so it seems to work.

Three semi-related comments.

The udf from cvs tree has annoying habbit to put udf.o in /fs/udf.o dir
while new modutils put udf.o in kernel/fs/udf/udf.o so if you are not
carefull you still will load old udf.o driver, evern after unning 'make
install' from udf cvs tree.

So when using packet mode with udf I get just 450mb out of 650mb cd?

pktcdvd reports the read speed as 6x, shouldn't it be 8x as this is 8432
drive.

Just for kicks I have attached output of dmesg while using the cd-rw to
mount and write in block mode on udf filesystem.

Thanks for great work! I finally should be able to use cd-rw in packet
mode!

-- 
Adam
http://www.eax.com  The Supreme Headquarters of the 32 bit registers


Linux version 2.4.0-test7-packet (root@pepsi) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #24 SMP Fri Sep 8 20:26:35 EDT 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (usable)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 1000 @ fec0 (reserved)
 BIOS-e820: 1000 @ fee0 (reserved)
 BIOS-e820: 0001 @  (reserved)
 BIOS-e820: 0bef @ 0010 (usable)
 BIOS-e820: d000 @ 0bff3000 (ACPI data)
 BIOS-e820: 3000 @ 0bff (ACPI NVS)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
found SMP MP-table at 000f5ae0
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 49136
zone(0): 4096 pages.
zone(1): 45040 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0
Processor #0 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
Bootup CPU
Processor #1 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
Bus #0 is PCI   
Bus #1 is PCI   
Bus #2 is ISA   
I/O APIC #2 Version 17 at 0xFEC0.
Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00
Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01
Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02
Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03
Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04
Int: type 0, pol 0, trig 0, bus 2, IRQ 05, APIC ID 2, APIC INT 05
Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06
Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07
Int: type 0, pol 1, trig 1, bus 2, IRQ 08, APIC ID 2, APIC INT 08
Int: type 0, pol 0, trig 0, bus 2, IRQ 0d, APIC ID 2, APIC INT 0d
Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e
Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f
Int: type 0, pol 3, trig 3, bus 0, IRQ 1f, APIC ID 2, APIC INT 13
Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 13
Int: type 0, pol 3, trig 3, bus 0, IRQ 34, APIC ID 2, APIC INT 11
Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 2, APIC INT 10
Int: type 0, pol 3, trig 3, bus 0, IRQ 4c, APIC ID 2, APIC INT 12
Int: type 0, pol 3, trig 3, bus 0, IRQ 4d, APIC ID 2, APIC INT 12
Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10
Int: type 2, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 17
Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00
Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01
Processors: 2
mapped APIC to e000 (fee0)
mapped IOAPIC to d000 (fec0)
Kernel command line: BOOT_IMAGE=packet ro root=2103 ip=off video=matrox:off 
video=vga16:off hdc=ide-scsi console=ttyS0,9600 console=tty0 single
ide_setup: hdc=ide-scsi
Initializing CPU#0
Detected 551262798 Hz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1101.00 BogoMIPS
Memory: 190908k/196544k available (1482k kernel code, 5248k reserved, 118k data, 216k 
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' 

Re: [patch] Name-clash between paride & hamradio

[Linus Torvalds]

On Sat, 9 Sep 2000, David Weinehall wrote:
> 
> This patches changes the names of the init-functions for the
> hamradio-drivers pt.c and pi2.c. None of the new names are used anywhere
> else in the kernel.

Patch applied, but I also wonder why these things are global names anyway?
Why not just change them to be static?

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] Name-clash between paride & hamradio

[David Weinehall]

This patch fixes a init-function name-clash between some code in paride
and net/hamradio. Apparently, _noone_ uses these simultaneous, as this
bug has existed since the times of v2.0.xx at least...

This patches changes the names of the init-functions for the
hamradio-drivers pt.c and pi2.c. None of the new names are used anywhere
else in the kernel.

Alan: this needs fixing in the v2.2-tree too, probably. But I don't have
a v2.2 kerneltree on my computer at the moment, so I couldn't produce a
patch for you. Guess you can hack it up yourself?


/David
  _ _ 
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky // 
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: [PATCH] af_netrom.c: do resource release on failure

[Arnaldo Carvalho de Melo]

Em Fri, Sep 08, 2000 at 08:33:45PM +0200, Torben Mathiasen escreveu:
> On Fri, Sep 08 2000, Arnaldo Carvalho de Melo wrote:
> > Hi,
> > 
> > Please take a look and consider applying. Some of it are small cleanups, if
> > they're deemed unnecessary, lemme now and I'm back it off. I think that there
> > are some more unchecked calls that need fixing, but I think its better to keep
> > the patches smaller and incremental, what do you think?
> >
> 
> How about converting the cli() code to spin_locks while we are at it?

Possible, yes, but I want to send the patches in an incremental way. I'm adding
"converting cli to spinlocks" to my TODO list.

- 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: [packet-writing] [release] packet-0.0.2c

[Jens Axboe]

On Fri, Sep 08 2000, [EMAIL PROTECTED] wrote:
> Incorrect number of segments after building list
> nr_segments is 3
> counted segments is 20
> Flags 0 0
> Segment 0xc59cf920, blocks 4, addr 0x59177ff
[snip]

Try attached patch, I hadn't noticed the segment counts were wrong
because I have implicit recounting.

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs


--- drivers/scsi/scsi_merge.c~  Sat Sep  9 00:20:15 2000
+++ drivers/scsi/scsi_merge.c   Sat Sep  9 00:21:49 2000
@@ -818,11 +818,7 @@
/*
 * First we need to know how many scatter gather segments are needed.
 */
-   if (!sg_count_valid) {
-   count = __count_segments(req, use_clustering, dma_host, NULL);
-   } else {
-   count = req->nr_segments;
-   }
+   count = __count_segments(req, use_clustering, dma_host, NULL);
 
/*
 * If the dma pool is nearly empty, then queue a minimal request

Installing kernel-2.4.test6

[Ibrahim El-Shafei]

Hi all,
I got this error when I tried to 'make bzImage' or 'make install' ...etc
the error is attached with this message and the makefile also attached

thankx for your help

Yours,
Ibrahim El-Shafei

_/\_/\_
  / 0 ! O \
0| <___> |0
  \___/

 Makefile

gcc -D__KERNEL__ -I/tmp/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -pipe -fno-strength-reduce  -c -o init/main.o init/main.c
{standard input}: Assembler messages:
{standard input}:357: Error: no such 386 instruction: `ldmxcsr'
{standard input}:363: Error: no such 386 instruction: `movups'
{standard input}:364: Error: no such 386 instruction: `movups'
{standard input}:365: Error: no such 386 instruction: `divps'
{standard input}:375: Error: no such 386 instruction: `ldmxcsr'
make: *** [init/main.o] Error 1

Re: [packet-writing] [release] packet-0.0.2c

[adam]

it is no go for me. it panics kernel for me when I try to mount it. Panic
below. (note this panic actually does not finish, it just print this msg
but after this system is still running, but trying to unmount anything,
sync or shutdown will just hang..)

Linux version 2.4.0-test7-packet (root@pepsi) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #23 SMP Fri Sep 8 18:08:23 EDT 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (usable)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 1000 @ fec0 (reserved)
 BIOS-e820: 1000 @ fee0 (reserved)
 BIOS-e820: 0001 @  (reserved)
 BIOS-e820: 0bef @ 0010 (usable)
 BIOS-e820: d000 @ 0bff3000 (ACPI data)
 BIOS-e820: 3000 @ 0bff (ACPI NVS)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
found SMP MP-table at 000f5ae0
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 49136
zone(0): 4096 pages.
zone(1): 45040 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0
Processor #0 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
Bootup CPU
Processor #1 Pentium(tm) Pro APIC version 17
Floating point unit present.
Machine Exception supported.
64 bit compare & exchange supported.
Internal APIC present.
Bus #0 is PCI   
Bus #1 is PCI   
Bus #2 is ISA   
I/O APIC #2 Version 17 at 0xFEC0.
Int: type 3, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 00
Int: type 0, pol 0, trig 0, bus 2, IRQ 01, APIC ID 2, APIC INT 01
Int: type 0, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 02
Int: type 0, pol 0, trig 0, bus 2, IRQ 03, APIC ID 2, APIC INT 03
Int: type 0, pol 0, trig 0, bus 2, IRQ 04, APIC ID 2, APIC INT 04
Int: type 0, pol 0, trig 0, bus 2, IRQ 05, APIC ID 2, APIC INT 05
Int: type 0, pol 0, trig 0, bus 2, IRQ 06, APIC ID 2, APIC INT 06
Int: type 0, pol 0, trig 0, bus 2, IRQ 07, APIC ID 2, APIC INT 07
Int: type 0, pol 1, trig 1, bus 2, IRQ 08, APIC ID 2, APIC INT 08
Int: type 0, pol 0, trig 0, bus 2, IRQ 0d, APIC ID 2, APIC INT 0d
Int: type 0, pol 0, trig 0, bus 2, IRQ 0e, APIC ID 2, APIC INT 0e
Int: type 0, pol 0, trig 0, bus 2, IRQ 0f, APIC ID 2, APIC INT 0f
Int: type 0, pol 3, trig 3, bus 0, IRQ 1f, APIC ID 2, APIC INT 13
Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 13
Int: type 0, pol 3, trig 3, bus 0, IRQ 34, APIC ID 2, APIC INT 11
Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 2, APIC INT 10
Int: type 0, pol 3, trig 3, bus 0, IRQ 4c, APIC ID 2, APIC INT 12
Int: type 0, pol 3, trig 3, bus 0, IRQ 4d, APIC ID 2, APIC INT 12
Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10
Int: type 2, pol 0, trig 0, bus 2, IRQ 00, APIC ID 2, APIC INT 17
Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00
Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01
Processors: 2
mapped APIC to e000 (fee0)
mapped IOAPIC to d000 (fec0)
Kernel command line: BOOT_IMAGE=packet ro root=2103 ip=off video=matrox:off 
video=vga16:off hdc=ide-scsi console=ttyS0,9600 console=tty0
ide_setup: hdc=ide-scsi
Initializing CPU#0
Detected 551262515 Hz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1101.00 BogoMIPS
Memory: 190908k/196544k available (1482k kernel code, 5248k reserved, 118k data, 216k 
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED])
CPU0: Intel Celeron (Mendocino) stepping 05
per-CPU timeslice cutoff: 356.82 usecs.
Getting VERSION: 40011
Getting VERSION: 40011
Getting ID: 0
Getting ID: f00
Getting LVT0: 700
Getting LVT1: 400
enabled ExtINT on CPU#0
ESR value before enabling vector: 
ESR value after enabling vector: 
CPU present map: 3
Booting processor 1/1 eip 2000
Setting warm reset code and vector.
1.
2.
3.
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1.
After apic_write.
Startup point 1.
Initializing CPU#1
Waiting for send to finish...
CPU#1 (phys ID: 1) waiting for CALLOUT
+Sending STARTUP 

Re: Notebook disk spindown

[Kurt Garloff]

On Sat, Sep 09, 2000 at 12:32:27AM +0200, Jamie Lokier wrote:
> You're right, but what you're missing is that with "noflushd", it was
> possible to keep the disk spun down _even with pending writes_.

You may tweak /proc/sys/vm/bdflush
to have it collect data for a long time before it is written to disk. This
incurs some risk though: Your memory will get less and less, because more
and more is occupied byt dirty buffers. At a certain percentage (first
bdflush param), it will start to write to disk ...

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security
-
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: Notebook disk spindown

[Richard Gooch]

Jamie Lokier writes:
> Russell King wrote:
> > > With laptops, people are willing
> > > to assume the RAM is reliable -- accidentally pulling the plug out won't
> > > lose the data.
> > 
> > But a buggy apm implementation and the battery running down can.
> 
> Well, perhaps the risk is worth it.

At the least, people should be able to choose whether they are willing
to take the risk or not. So a CONFIG_ option would do.
Has such a patch been submitted?

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [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: Oops on boot with both 2.2.17 and 2.4.0t8p6

[Andrew Burgess]

> >Oops from 2.2.17 (some more before this, but it went offscreen):
...
> You need to capture and decode the first oops.  Compile a kernel with a
> serial console and capture the oops log on a second machine. 

Or set your console for more than 80x25 using SVGATextMode. I use
/usr/sbin/SVGATextMode -rx 80x50x8
-
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.0-test8

[Jamie Lokier]

Linus Torvalds wrote:
> It's about the fact that when I chose the GPL, I did it because I wanted
> the source-code to be free and unencumbered. Forever. Whether I maintained
> that code or not. I didn't want my code to have any extra rules and
> regulations - the GPLv2 is already quite complex enough, but it is, in my
> opinion the "minimum required" complexity. So it suited and continues to
> suit my needs and opinions admirably.

I happen to like that point of view.  I use the GPLv2 myself extensively
for the same reason.

> Thus the (current) limitation to v2. And only, obviously, for code _I_
> wrote and hold the copyright to.
...
> In the likely case that the GPL v3 is fine, I will license all my code
> under "v2-v3". Maybe it even clarifies the issue of "similar in spirit",
> so that I wouldn't need to worry at all about what the FSF considers
> "similar" ever again, and I can stop worrying altogether.

Here I am concerned.  I'm concerned about the other authors.

You often accept contributions to your kernel where the license isn't
specified by the contributor.  We must assume the contributor is content
with the kernel's own license.

Now, someone may contribute a large patch to your GPLv2 kernels.  The
person has _not_ granted you the right to retroactively change _their_
license to "v2-v3".

Maybe it seems reasonable to relicense contributed code from "v2 only"
to "v2-v3".  But is it really?  It seems _far_ from reasonable to
relicense contributed code to a non-GPL license.  So what makes it
reasonable to relax the version?

> Quite frankly, I'm probably just jumpy. And part of this is very much
> pre-emptive: making sure that the FSF knows that whatever they do, they
> have to take other peoples feelings into account too, and not just make a
> new version of the GPL on their own whims. 
> 
> So don't read _too_ much into this. It just means that the FSF does not
> have a blanket permission to expand upon the GPL as far as my personal
> code is concerned. Nothing more.

I assumed as much.

For the moment may I propose an interim statement?

You state that _your_ code is clearly GPL "v2 only", but you might
change your mind.

Let's state that others' _contributed_ code is GPL "v2 or later" unless
the contributor states otherwise.  So that, if you do decide to go with
GPLv3 later, you actually have permission to do that.

It would be good anyway to have a clear statement on the status of
contributed code.  It is most of the kernel.

-- 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: DAC960 SMP deadlock fix

[Andrea Arcangeli]

On Fri, 8 Sep 2000, Leonard N. Zubkoff wrote:

>I'm testing the modified driver out in the released 2.2.17 and getting the
>following messages while running mke2fs.  Is this a known problem with 2.2.17,
>or something introduced by the change in waiting behavior?

It's known VM problem (unrelated to the DAC960 fix). This patch (against
2.2.18pre2aa2) fixes it:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre2/VM-global-2.2.18pre2-6.bz2

Andrea

-
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] af_netrom.c: do resource release on failure

[David S. Miller]

   Date:Fri, 8 Sep 2000 20:33:45 +0200
   From: Torben Mathiasen <[EMAIL PROTECTED]>

   How about converting the cli() code to spin_locks while we are at
   it?

There are many protocols which are of this nature, I did appletalk
spinlocking for example.  I didn't even finish cleaning appltalk up,
it still is a "stupid" protocol in that it still changes packet
contents during input packet processing, for example.  Only after
that would appletalk be %100 "new-style".

I encourage people to do the spinlocking and receive processing fixups
for these protocols, but it is pain in the ass because many of these
protocols are hard to test without the correct kit being available.

(The work is also a bit depressing, doing SMP locking really shows how
 buggy and full of races these lesser used protocols are.)

We have wrappers etc. to handle these non-converted protocols so that
they function in 2.4.x as properly as they did in 2.2.x, so it's not
really a matter of them being less correct until spinlocked.  The only
large gain we would achieve from this work would be cleaner code plus
the ability to remove the wrappers and the "stupid protocol receive
packet mangling" support in netif_rx.

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: Linux-2.4.0-test8

[Linus Torvalds]

On Sat, 9 Sep 2000, Jamie Lokier wrote:
> 
> > I think an appropriate concern. The future GPL is constrained by the GPLv2
> > clause 9 to be 'similar in spirit...'. You also dont ever have to take any
> > code that specifies GPLv3 or later.
> 
> Linus, nobody can ever force GPLv3 upon you.  If you don't like GPLv3
> when you actually see one, then you can restrict the kernel to GPLv2
> only and refuse contributions that don't honour that.

As I already explained to Alan in a private email, it's not about me
accepting other peoples GPLv3 code.

It's about the fact that when I chose the GPL, I did it because I wanted
the source-code to be free and unencumbered. Forever. Whether I maintained
that code or not. I didn't want my code to have any extra rules and
regulations - the GPLv2 is already quite complex enough, but it is, in my
opinion the "minimum required" complexity. So it suited and continues to
suit my needs and opinions admirably.

The fact that I still maintain my own code and can choose to ignore other
peoples code doesn't change that feeling. I want _my_ code to be out
there, freely available, and unencumbered by any extra restrictions,
forever and ever. Regardless of whether it is I who maintain it or not. I
obviously won't be able to maintain it _forever_, after all.

And I'd hate to see my code become part of something I don't like. 

Thus the (current) limitation to v2. And only, obviously, for code _I_
wrote and hold the copyright to.

> I wouldn't be surprised if GPLv3 simply clarifies things.  Clearer legal
> language, clearer on dynamic linking etc.

I hope so. And yes, in the end I _believe_ so. It's just that I used to
believe so without even thinking about it. Last week some people opened my
eyes to the fact that I can't just take it for granted.

In the likely case that the GPL v3 is fine, I will license all my code
under "v2-v3". Maybe it even clarifies the issue of "similar in spirit",
so that I wouldn't need to worry at all about what the FSF considers
"similar" ever again, and I can stop worrying altogether.

I'm not against a new version of the GPL - I'm just spooked by some of the
things that have been discussed that _might_ be part of a new version of
the GPL. Things that would mean that if I didn't limit my code to the v2,
future code maintainers might use my code with restrictions or other
things that I never agreed to.

Quite frankly, I'm probably just jumpy. And part of this is very much
pre-emptive: making sure that the FSF knows that whatever they do, they
have to take other peoples feelings into account too, and not just make a
new version of the GPL on their own whims. 

So don't read _too_ much into this. It just means that the FSF does not
have a blanket permission to expand upon the GPL as far as my personal
code is concerned. Nothing more.

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: Notebook disk spindown

[Jamie Lokier]

Russell King wrote:
> > With laptops, people are willing
> > to assume the RAM is reliable -- accidentally pulling the plug out won't
> > lose the data.
> 
> But a buggy apm implementation and the battery running down can.

Well, perhaps the risk is worth it.

-- 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: [RFC] Wine speedup through kernel module

[J. Robert von Behren]

Hey David - 

Since at least two of us agree that having dynamically allocated syscall
table entries would be handy, perhaps that is worth pursuing.  I suppose
the one issue (as you mention below) is that you might need a large
number of these free entries.  Does anyone know if there would be any
adverse side effect to doubleing or quadrupling the size of the system
call table?  At first blush, I can't think of any reasons not to.

That said, as a stopgap, I still believe a char device could do the
trick

> "J. Robert von Behren" <[EMAIL PROTECTED]> wrote:
> > FWIW, this can be done with relatively low overhead by creating a
> > miscelaneous character device, and just using write() to write in the
> > arguments.  This is a bit worse than passing things through registers,
> > but doesn't seem all that bad.
> 
> How do you emulate calls that return more than just a single integer? 

As one of the function arguments (that are written to the char device)
just pass in a pointer to a user-space buffer, and have the kernel fill
it in w/ appropriate data for that call.  You can do the same thing as
read() or others, its just that the args are passed via a memory copy,
rather than in registers.  If you actually want to return a large struct
as a return value, you'd need to do some sort of kernel to user copy
anyway - the only difference is that it would go onto the stack
instead.  Passing in a buffer seems cleaner to me.

> Plus if
> you do it that way, someone can play havoc with the system with the cat
> command, or if something tries to use the wrong fd.

No.  The way it would work is that you would open up the character
device from user space.  All fops to the returned FD, are passed to the
module code.  The module code reads in the data from the write() call,
translates this to arguments, and then does the same sanity checking
that any system call should do (make sure pointers refer to things in
the user's address space, copy data to kernel space, etc.)

Basically an academic point, though, since dynamic management of the
system call table would seem to be cleaner.

-Rob
-
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: Notebook disk spindown

[Russell King]

Jamie Lokier writes:
> With laptops, people are willing
> to assume the RAM is reliable -- accidentally pulling the plug out won't
> lose the data.

But a buggy apm implementation and the battery running down can.

(and I've seen my Thinkpad 380XD with RH's 2.2.14-5.0 kernel and
RH's apmd run itself dead.  Kill apmd and it'll do the right thing
and suspend, then hibernate.  And no, I haven't even attempted to
debugg it yet).
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
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: Notebook disk spindown

[Jamie Lokier]

Russell King wrote:
> > *a silent hard disk hard disk is no longer feasible since kernel
> > 2.2.11*.
> 
> Yes it is.  I have one of my machines (which NFS serves a NFS root
> client, both of which are on 24 hours a day) capable of spinning
> down for up to 4 hours at a time, with no kernel modifications
> what so ever.

You're right, but what you're missing is that with "noflushd", it was
possible to keep the disk spun down _even with pending writes_.

> It does.  You really want to think about how you partition your disk
> in conjunction with what the filesystems will contain, and what options
> you want to mount with.  The options that you're looking for are:
> 
>   nodiratime
>   noatime
> 
> Use of these prevents the update of the "access times" for files.
>
> Oh, I also have /var/run and /var/lock as a ramdisk (they only
> refer to current system state).
> 
> Some user space programs will need to be modified - cron and ypbind
> are the two that spring to mind.  cron to prevent it writing to
> /var/log/cron (not the security concerns with this mod), and to place
> ypbind's temporary file that it polls once every 10 seconds into
> /var/run.

These suggestions are good for laptops because they reduce the amount of
pending writeback, even with "noflushd".

However, they still don't save you from spinning up the disk when you
_do_ write something and you have enough RAM to hold the data for a few
hours until you must spin up the disk.

E.g. you might compile a program or send some mail.  These things write
to the "disk", but you don't have to really spin up your disk if there's
enough RAM to hold the pending writes.  With laptops, people are willing
to assume the RAM is reliable -- accidentally pulling the plug out won't
lose the data.

-- 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: DAC960 SMP deadlock fix

[Leonard N. Zubkoff]

  Date: Thu, 7 Sep 2000 18:33:36 +0200 (CEST)
  From: Andrea Arcangeli <[EMAIL PROTECTED]>

Andrea,

I'm testing the modified driver out in the released 2.2.17 and getting the
following messages while running mke2fs.  Is this a known problem with 2.2.17,
or something introduced by the change in waiting behavior?

Leonard

VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
VM: do_try_to_free_pages failed for mke2fs...
-
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: test8-pre6 file corruption and oops

[Keith Owens]

On Fri, 08 Sep 2000 23:09:14 +0200, 
Kenneth Johansson <[EMAIL PROTECTED]> wrote:
>I have now put "-k /boot/System.map-$(uname -r)" as argument to klogd
>so it can't possibly choose the wrong file but is there some
>reason to turn off the lookup in klogd and use ksymoops ??

klogd only handles some architectures.  klogd only knows about some
messages for the architectures it does handle.  klogd does not verify
that it was passed the correct System.map.  klogd does not always know
about loaded modules.  Even when klogd knows about loaded modules, it
does not use the __insmod symbols to correctly map the modules.  I
could go on but you get the idea.

-
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: Problems with bluesmoke.c in 2.2.17

[Alan Cox]

> And here's another sample output for you:
> 
> CPU 1: Machine Check Exception: 0004<0>Bank 0: f20001000800general 
>protection fault: 
> CPU:1
> EIP:0010:[mcheck_fault+263/368]
> EFLAGS: 00010246
> ...
> 
> I seldom get a log entry, most of the time I get the first line on all my
> xterms and then a hard lock.
> 
> And Alan, in case you don't know about it, there's a kernel module
> that reports RAM ECC errors at http://www.anime.net/~goemon/linux-ecc/
> It seems related, maybe you will find some of the code useful.

It handles the bus/chipset layer above what the MCE code monitors. Its the
other half of the code. And yes both are important. Its difficult to claim
a highly available and reliable system when it doesnt detect and log errors
for analysis.

I've fixed a couple of bugs, when 2.2.18pre4 is out can you try it and get
another trap out of it. It should this time log it nicely and panic cleanly
not oops.


-
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: Problems with bluesmoke.c in 2.2.17

[Andrew Burgess]

And here's another sample output for you:

CPU 1: Machine Check Exception: 0004<0>Bank 0: f20001000800general 
protection fault: 
CPU:1
EIP:0010:[mcheck_fault+263/368]
EFLAGS: 00010246
...

I seldom get a log entry, most of the time I get the first line on all my
xterms and then a hard lock.

And Alan, in case you don't know about it, there's a kernel module
that reports RAM ECC errors at http://www.anime.net/~goemon/linux-ecc/
It seems related, maybe you will find some of the code useful.

Thanks again
Andrew


-
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: Oops on boot with both 2.2.17 and 2.4.0t8p6

[Keith Owens]

On Fri, 8 Sep 2000 14:48:51 +0200, 
Rasmus Andersen <[EMAIL PROTECTED]> wrote:
>I just got hold of an old machine (P75, 32MB RAM). On trying to install
>RH 6.2 on it, I got an oops after loading the kernel from the boot floppy.
>I then tried to boot a 2.4.0-test8-pre6 (made with make bzdisk), but got
>an oops. The same with 2.2.17.
>
>Oops from 2.2.17 (some more before this, but it went offscreen):
>
>Code:<1>Unable to handle kernel NULL pointer dereference at virtual address 0292
>>>EIP; c0107f27<=

The first oops is the important one in this case, some code has taken a
branch to invalid storage.  The second oops is the kernel trying to
print the code fro9m the first oops and gives no useful data.

You need to capture and decode the first oops.  Compile a kernel with a
serial console and capture the oops log on a second machine.  See
linux/Documentation/{serial-console.txt,oops-tracing.txt} on a recent
2.4 kernel.  Also upgrade ksymoops for 2.4.

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

Bugs in test7

[John B. Jacobsen]

umsdos wont compile
make modules_install fails because
stallion.o doesnt exist

Regards

John
-
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] panic when booting Intel XXPRESS SMP boards

[Alan Cox]

> I'd love to have somebody (yes, you) look at the actual MP table and see
> if there is something special with the XXPRESS bus, but in the end even if
> we don't know a bus we're better off always just mentioning the fact
> ("Unknown bus ") and going on with our life. Maybe the system won't
> work simply becasue we won't find any critical devices off the bus, but if
> we panic we _know_ that it won't work, so..

By way of comment to back that up - 2.2 has been booted on boxes with both
xpress bus (works fine) and corollary cbus (panics cleanly unable to find
devices) so I think printking a warning and carrying on is a good choice

-
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] af_netrom.c: do resource release on failure

[Marcelo Tosatti]

On Fri, 8 Sep 2000, Torben Mathiasen wrote:

> > ipx is using cli() too.
> >
> 
> Mmmm, any reason for this besides just lazyness? I'd hate to do it, cause 
> I'd hate to test it 8)

Because it was never really needed. 

If someone complains about it, it will be done.




-
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: Loss of network connectivity

[Andrew McNabb]

On Fri, 8 Sep 2000, Andrew Clayton wrote:

> I am running on a Compaq Armada E500 laptop, and after about a days worth 
> of the pcmcia network card being registered, the system looses network 
> connectivity with the following being logged to /var/log/messages

> eth0: Resetting the Tx ring pointer.
> eth0: Tx Ring full, refusing to send buffer.

> The card in question is a 3Com 3CCFE575BT


This is a known problem.  There's a bug with the 3Com Card,
where it gives up transmitting if there are a lot of collisions
in a row.  David Hinds and Andrew Morton have spent some time
on this recently, and it seems to be doing a lot better.

There are still some problems, especially if the card gets
excessively warm (don't ask me why...).  If your network
isn't to collisiony, download the latest beta pcmcia package,
and it should work.



--
Andrew McNabb
[EMAIL PROTECTED]
http://www.mcnabbs.org/

-
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 & cisco firewall

[Alan Cox]

> > sites which RST these ECN carrying packets are the ones which disturb
> > me the most, in the Cisco PIX case does the firewall send a reset
> 
> So, how would properly written pre-ECN software indicate
> rejection of packets with the unknown ECN flag?

By leaving the bits as zero

-
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: Problems with bluesmoke.c in 2.2.17

[Alan Cox]

> Based on what bluesmoke.c said about my 2nd PII-333 CPU I just got
> Intel to give me an RMA number for its replacement. Thank you Alan Cox ;-)

I'd like to finish verifying the code first but umm ok. Do send me traces
if you get any of these exceptions. I've still had no answer to my request
for intel to testbed verify this stuff



-
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.0-test8

[Alan Cox]

> If anybody wants to explicitly state that their code will be valid under
> any version of the GPL (current or future - whatever they may look like),
> please send patches to say so for the code in question. If you've used the
> FSF boiler-place copyright notice, you already have this in place (it says
> "v2 or later" - the FSF itself doesn't recommend v1 any more).

Every line of code I wrote is under the GPLv2 or later (except those bits
I contributed that were BSD non advertising derived and which I left the BSD
license on). 

> (Me, I'm taking the careful "wait and see" approach. I don't know if a GPL
> v3 is imminent, and I don't know if the issues discussed will even
> _become_ real issues, so you might as well consider me a paranoid, if
> careful, bastard).

I think an appropriate concern. The future GPL is constrained by the GPLv2
clause 9 to be 'similar in spirit...'. You also dont ever have to take any
code that specifies GPLv3 or later.

Alan


-
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: Whining about MIME formatted email

[Kurt Garloff]

On Fri, Sep 08, 2000 at 06:33:34PM +1100, Keith Owens wrote:
> Exmh handles MIME just fine and MIME is useful for some things.  Other
> people (including Linus) have made it clear that MIME is not welcome on
> linux-kernel, plain text format is always better when you are sending
> plain text.  What next, rich text format and HTML with multiple copies
> of the text, MSWord format?

Stop making stupid statements like this, please, and comparing well-defined
RFC standards with proprietary formats. 
MIME is a way for people that happen to use non 7bit characters to be able
to print their name correctly, even in presence of MTAs somewhere in between
that don't handle 8bit. Or with PGP, which also prefers 7bit ...
You'll probably complain about me using a GnuPG signature as well.

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security

 PGP signature

Re: test8-pre6 file corruption and oops

[Kenneth Johansson]

"Juan J. Quintela" wrote:

> > "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes:
>
> kenneth> Is there some way I can fix the old report I don't have a unprocessed 
>version of the oops as klogd "fixed" it automatically.
>
> I don't think so.  It is a good idea to run klogd with the -x option,
> to prevent him from doind the translation.

I checked into this some more and debian have a patched version that actually gets it 
right and it did not take the symbols from the
System.map link. It was easy to check as that mapfile don't even have the "__mon_yday" 
symbol so it must have got the symbols from
another file and unless it's seriously broken it should have picked the right one.

So it lookes like the call trace was wrong and not the map file.

I have now put "-k /boot/System.map-$(uname -r)" as argument to klogd so it can't 
possibly choose the wrong file but is there some
reason to turn off the lookup in klogd and use ksymoops ??







-
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] panic when booting Intel XXPRESS SMP boards

[Kurt Garloff]

On Fri, Sep 08, 2000 at 12:25:48PM -0700, Linus Torvalds wrote:
> On Fri, 8 Sep 2000, Maciej W. Rozycki wrote:
> >  I think we must panic() for an unknown bus that has an I/O APIC interrupt
> > routed from that is marked as "conforming to the bus spec" in the MP
> > table.  Trying to assume any defaults is unsafe and is not any better --
> > we may guess them upon the first interested user reports such a problem.
> > This should trigger on a small amount of unusual system if any at all.
> 
> Note that then we should move the panic to the irq routing part (ie
> MPBIOS_trigger() and MPBIOS_polarity friends). Although right now we have
> just a printk() there, and I think I'd prefer it that way. Maybe just make
> it bigger letters..

Indeed. There may be devices on the XXX bus configured by the BIOS that we
never want to use anyway ...
The driver will not find the device anyway, so no danger AFAICS.

Regards,
-- 
Kurt Garloff  <[EMAIL PROTECTED]>  Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG   SCSI, Security

 PGP signature

Re: [PATCH] af_netrom.c: do resource release on failure

[Torben Mathiasen]

On Fri, Sep 08 2000, Marcelo Tosatti wrote:
> 
> On Fri, 8 Sep 2000, Torben Mathiasen wrote:
> 
> > On Fri, Sep 08 2000, Arnaldo Carvalho de Melo wrote:
> > > Hi,
> > > 
> > >   Please take a look and consider applying. Some of it are small cleanups, if
> > > they're deemed unnecessary, lemme now and I'm back it off. I think that there
> > > are some more unchecked calls that need fixing, but I think its better to keep
> > > the patches smaller and incremental, what do you think?
> > >
> > 
> > How about converting the cli() code to spin_locks while we are at it?
> 
> ipx is using cli() too.
>

Mmmm, any reason for this besides just lazyness? I'd hate to do it, cause 
I'd hate to test it 8)

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
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: Problems with bluesmoke.c in 2.2.17

[Andrew Burgess]

>
Based on what bluesmoke.c said about my 2nd PII-333 CPU I just got
Intel to give me an RMA number for its replacement. Thank you Alan Cox ;-)

:

~v

-
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: Notebook disk spindown

[Russell King]

Tim Brunne writes:
> *a silent hard disk hard disk is no longer feasible since kernel
> 2.2.11*.

Yes it is.  I have one of my machines (which NFS serves a NFS root
client, both of which are on 24 hours a day) capable of spinning
down for up to 4 hours at a time, with no kernel modifications
what so ever.

> Shouldn't Linux support hard disk spindown during periods of
> inactivity? Is the tiny patch worth of being included into standard
> kernels?

It does.  You really want to think about how you partition your disk
in conjunction with what the filesystems will contain, and what options
you want to mount with.  The options that you're looking for are:

nodiratime
noatime

Use of these prevents the update of the "access times" for files.

Oh, I also have /var/run and /var/lock as a ramdisk (they only
refer to current system state).

Some user space programs will need to be modified - cron and ypbind
are the two that spring to mind.  cron to prevent it writing to
/var/log/cron (not the security concerns with this mod), and to place
ypbind's temporary file that it polls once every 10 seconds into
/var/run.

Hope this helps.
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
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.0-test8

[Linus Torvalds]

Ok, as the truncate problems really seem to be fixed, it's time to do an
official test8, the first development kernel in about a year and a half
that should have a working truncate() again. Thanks to everybody who
tested, and especially to Al Viro who did a lot of the heavy lifting.

There are a number of other various changes there too - the truncate fix
itself was fairly small, it was just more complex than most problems that
can be solved in 50 lines of code.

The only one of any note that I'd like to point out directly is the
clarification in the COPYING file, making it clear that it's only _that_
particular version of the GPL that is valid for the kernel. This should
not come as any surprise, as that's the same license that has been there
since 0.12 or so, but I thought I'd make that explicit.

Why? There's been some discussions of a GPL v3 which would limit licensing
to certain "well-behaved" parties, and I'm not sure I'd agree with such
restrictions - and the GPL itself allows for "any version" so I wanted to
make this part unambigious as far as my personal code is concerned.

The reason I wanted to mention that particular issue here explicitly
(rather than as just a one-liner in the changelog) is that code written by
others is obviously under _their_ discretion, and not limited by my
personal foibles, fears and misgivings.

If anybody wants to explicitly state that their code will be valid under
any version of the GPL (current or future - whatever they may look like),
please send patches to say so for the code in question. If you've used the
FSF boiler-place copyright notice, you already have this in place (it says
"v2 or later" - the FSF itself doesn't recommend v1 any more).

(Me, I'm taking the careful "wait and see" approach. I don't know if a GPL
v3 is imminent, and I don't know if the issues discussed will even
_become_ real issues, so you might as well consider me a paranoid, if
careful, bastard).

Linus

-
test8:
 - pre1
- Oops. Moved back stallion.c to drivers/char. It's not a TV driver.
  Never has been, and I don't see it ever really becoming one ;)
- mca.c: outp_b() should be outb_p().  Obviously nobody actually
  _uses_ the MCA bus any more ;)
- umsdos should be ok again after the page_address() type-changes.
- re-enable asynchronous read-ahead code.
- Sun ESP driver update
- netfilter debug fixes
- IPv6 needs to register before proto_init()
- socket() error code fix (EAFNOSUPPORT instead of EINVAL)
- potential TCP socket leak fix
- don't self-deadlock on the kbd_controller_lock when probing for the mouse
- CONFIG_SMB_NLS_REMOTE didn't work. Silly typo.
- scheduler wakeup race condition could cause delayed scheduling on SMP..
- net/packet/af_packet.c: use the standard macros for marking page resevredness
- ncpfs buffer-overflow fix
- thread groups, take 1.
- USB storage driver update
 - pre2
- The TCP socket leak patch _really_ went in this time.
- get rid of more suser() checks in networking.. It's "capable(CAP_NET_ADMIN)".
- sparc updates
- alpha updates. Fast alpha xor for raid. AP1000 updates.
- Wonders never cease. digiboard driver updates. Christoph Lameter is BAAACK!
- SiS frame buffer driver updates. Can be used without a BIOS.
- nfsd interface cleanup.
- fix potential buffer overruns in get_partition_list.  Remove
  limitation of one page. 
- floppy driver capability cleanups. Use "request_region()".
- handle dcache flushing when there are shared user mappings that
  may be dirty. 
- get rid of the "_ret()" user access macros. They are more complex than
  just doing the return directly and they hide what's going on.
- fix up broken BIOSes that don't give unique ID's to different APICs
- make more of the drm drivers compile on other platforms and know
  about the signal blocking issues.
- net/atm/mpoa_proc.c: user-space access thinko
- pcmcia: David Hinds: merge updates from 3.1.20
- pcmcia: non-ISA machines really shouldn't use ISA interrupts ;)
- ext2: truncate races and error code return fixes
- true shared signals for pthreads..
 - pre3:
- ext2: final truncate piece - fix the innd problem.
- use "sfence" for x86 memory barrier when available.
- remove the thread-group signal code for now: no feedback.
  Leave the cleanups in place so that we can add it back in
  cleanly later, but remove the new features.
- ARM update.
- released for Al Viro to check the truncate thing
 - pre4:
- truncate really fixed this time. Everybody agrees.
 - pre5:
- truncate. Guess what? We threw away the key to the clue-box.
- simplify signal notification. And remember the spinlock.
- VIA ide driver update (well, rewrite - the old one was buggy and broken)
- network driver fixes (not checking for oom etc)
- USB serial driver SMP locking fixes
- fix memory leak 

Bugs in test7

[John B. Jacobsen]

umsdos wont compile
make modules_install fails because
stallion.o doesnt exist

Regards

John
-
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: Multiple Keyboards in 2.2/2.4?

[Adam Sampson]

On Thu, Sep 07, 2000 at 10:00:05AM -0400, James Simmons wrote:
> On the console level their are complex issues as well. Consider a
> system with 4 VTs attached to one machine. What if one person pressed
> Ctrl-Alt-Del. Anyone can bring the system down when multiple people depend
> on it.

That particular one is a userspace issue; you can simply tell init not to do
anything when Ctrl-Alt-Del is pressed. (You'd also want to disable
magic-sysrq for the same reason.)

-- 

Adam Sampson
[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: [RFC] Wine speedup through kernel module

[Adam Sampson]

On Thu, Sep 07, 2000 at 10:46:58AM +0200, Martin Dalecki wrote:
> > I've done an implementation of some of the Win32 "system calls" in a kernel
> > module in an attempt to speed up Wine.
>
> Please by no way don't include this patch into the official tree.
> It's insane due to the following:
> 
> 1. Linux is UNIX not NT... (in terms of API)

I also don't think this patch should go into the official tree, but in my
case it's because it's too closely related to the WINE userspace libraries;
it should become part of the WINE tree instead. (Note that this is how other
packages such as ALSA and lm_sensors are maintained.)

However, I don't see any problems with having a kernel module to emulate a
different API. We already have code to emulate different UNIX APIs in the
IBCS system; having some support for emulating the Win32 system call
interface could potentially be useful.

> 2. WINE in itself is barely usefull - even in fact non existant, since
> there is no official stable release out there.

Flamebait, but I don't think this is true. WINE is very useful---plenty of
apps and games run on it, and it can be a real lifesaver if you get thrown a
self-extracting archive that unzip chokes on. (Note that Corel are using
WINE for Wordperfect Office under Unix now.) WINE's still-ALPHA status
reflects the caution of its developers rather than the quality of its code;
note that plenty of other packages (lesstif, kbd, WindowMaker, ORBit, ALSA,
bin86, esd, links etc.) still retain "alpha" (<1.0) version numbers despite
being stable, reliable and widely-used.

-- 

Adam Sampson
[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: kernel debugger...

[Jeff V. Merkey]

Rik van Riel wrote:
> 
>
> > NDS provides no value to Linux unless it's integrated into the
> > OS, which will happen when MANOS goes out next year around
> > March.  NDS is more of a Microsoft play than a Linux play and
> > Linux already has better internet directory technology than NDS
> > -- NDS is better for managing LAN's.
> 
> It should be interesting to see what happens here. First
> SAMBA, then the Kerberos thing and now NDS ... looks like
> we might be able to beat Microsoft on their home turf ;)

Here's what they sent me day before yesterday, right before they had the
lawyers come after us, and I dissolved our contracts.  Draw your own
conclusions:

...from Microsoft .

... Microsoft has not had time to drill into this but we do want to make
sure that you are not in any way compromising any Microsoft Confidential
Information in your actions or your communications. Some of your
comments in various newsgroups in support of Linux and MANOS have been
sent to me with concerns and we need to look more carefully and will
respond to you directly, but I can say that at this time we do not see
any business benefits to us to support a R/W NTFS on Linux as you have
proposed and are concerned about support problems that some of your
ideas are creating for us with your Linux projects.  Truly, all your
ideas need to be viewed by the industry as your own and we don't want to
it to publically appear that we influence them or participate, if that
is responsive to your question.

:-)

Jeff

> 
> (yes, I know IRIX has the SAMBA performance record, but
> still... ;))
> 
> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/   http://www.surriel.com/
-
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: [RFC] Wine speedup through kernel module

[David Howells]

"J. Robert von Behren" <[EMAIL PROTECTED]> wrote:
> FWIW, this can be done with relatively low overhead by creating a
> miscelaneous character device, and just using write() to write in the
> arguments.  This is a bit worse than passing things through registers,
> but doesn't seem all that bad.

How do you emulate calls that return more than just a single integer? Plus if
you do it that way, someone can play havoc with the system with the cat
command, or if something tries to use the wrong fd.

Far better to use ioctl() I think.

> Nonetheless, having some entries in the syscall table that are
> designated as "dynamically allocatable" would be a nifty trick.  If the
> kernel managed these, modules coluld safely grab a few at load time, and
> then declare which indices to use via a /proc file.

My thought exactly, except that you either need one or a great many.

David Howells
-
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] af_netrom.c: do resource release on failure

[Marcelo Tosatti]

On Fri, 8 Sep 2000, Torben Mathiasen wrote:

> On Fri, Sep 08 2000, Arnaldo Carvalho de Melo wrote:
> > Hi,
> > 
> > Please take a look and consider applying. Some of it are small cleanups, if
> > they're deemed unnecessary, lemme now and I'm back it off. I think that there
> > are some more unchecked calls that need fixing, but I think its better to keep
> > the patches smaller and incremental, what do you think?
> >
> 
> How about converting the cli() code to spin_locks while we are at it?

ipx is using cli() too.




-
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] panic when booting Intel XXPRESS SMP boards

[Linus Torvalds]

On Fri, 8 Sep 2000, Maciej W. Rozycki wrote:
> 
>  I think we must panic() for an unknown bus that has an I/O APIC interrupt
> routed from that is marked as "conforming to the bus spec" in the MP
> table.  Trying to assume any defaults is unsafe and is not any better --
> we may guess them upon the first interested user reports such a problem.
> This should trigger on a small amount of unusual system if any at all.

Note that then we should move the panic to the irq routing part (ie
MPBIOS_trigger() and MPBIOS_polarity friends). Although right now we have
just a printk() there, and I think I'd prefer it that way. Maybe just make
it bigger letters..

> > It looks like the simplest solution is to just make bus number 0 be
> > "unknown", and leave it at that (and start ISA etc from 1).  Wouldn't you
> > agree?
> 
>  We cannot asume any bus is of any type -- it may be ISA or PCI or
> whatever.  Jean-Marc actually reported: 
> 
> Bus #0 is PCI
> Bus #1 is PCI
> Bus #18 is XPRESS
> Bus #19 is EISA

No, I meant our internal numbers for the bus: the MP_BUS_ISA etc numberng
scheme. Let's make _that_ numbering scheme say that "0" is just unknown,
and let's initialize unknown buses to zero (right now we initialize the
_first_ unknown bus to -1, but all other unknown buses are 0, which is
really the same thing as MP_BUS_ISA).

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: Bug in block device read/write!

[Andries Brouwer]

On Fri, Sep 08, 2000 at 03:41:27AM +0100, Anton Altaparmakov wrote:

> [kernel-2.4.0-test3 to kernel-2.4.0-test8-pre6, bug present in those two, 
> didn't try others]
> 
> I have been trying to get the linear md driver to work with NTFS volumes 
> for several months and it never worked. - I was suspecting the NTFS driver 
> (after having fixed linear md and verified that at least that worked fine) 
> but today I finally found why it doesn't work:
> 
> There is a bug in reading/writing to block devices. - It manifests itself 
> in the form that partitions are too small by exactly one sector!
> 
> Even though a cfdisk shows that a partition has a certain number of 
> sectors, you can never seek + read and/or write to the last sector (doing 
> file i/o using read/write(2) [also tried fread/fwrite(3), same result]. - 
> Last sector doesn't seem to exist. However reading the actual hd (/dev/hdb 
> or /dev/sda, ie. affects both IDE and SCSI) instead of the partition 
> (/dev/hdb7 or whatever) the sector does exist and contains the expected 
> information!

The size of a partition (as seen by fdisk) is a number of 512-byte sectors.
The size of a partition (as seen by the kernel, for reading and writing)
is a number of 1024-byte blocks. This number is 1 for an extended partition
(just enough to put LILO there) and number_of_sectors/2 otherwise.

[see fs/partitions/check.c:grok_partitions()
dev->sizes[i] = dev->part[i].nr_sects >> (BLOCK_SIZE_BITS - 9);
]

Thus, indeed, if the number of sectors in the partition is odd
you are presently unable to read the last sector by accessing
the partition, but you can access it via the whole-disk device.


Andries
-
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: Compilation failure on Alpha with test8-pre[2-6]

[Richard Henderson]

On Fri, Sep 08, 2000 at 04:58:33PM +0400, Ivan Kokshaysky wrote:
> Yes, I can reproduce this with gcc-2.95.2 (compiles cleanly with 2.96).
> Looks like older gcc doesn't like when output operand 5 listed
> also as input. Hmm.
> Simple swapping operands 4 and 5 makes gcc happy.

I've got a patch to rearrange this whole sets of codes
into something a bit cleaner.  I'll see about forwarding
it shortly.


r~
-
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: Compilation failure on Alpha with test8-pre[2-6]

[Richard Henderson]

On Fri, Sep 08, 2000 at 08:36:58PM +0400, Ivan Kokshaysky wrote:
> FWIW, here are __xchg_u8 and __xchg_u16 for Alpha.

I like it.  


r~
-
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 & cisco firewall

[Albert D. Cahalan]

David S. Miller writes:
>From: Ulrich Kiermayr <[EMAIL PROTECTED]>

>
>  Reserved:  6 bits
> 
>   Reserved for future use.  Must be zero.
>
> 
>The point is: 'must be zero' is redefined by rfc2481 (ECN).
> 
> The authors of rfc793 probably, in all honesty, really meant
> "must be set to zero by current implementations".
> 
> Even though they did not say this, several pages later they bestow
> upon us the concept of being liberal in what one accepts.  Perhaps

To be "liberal in what one accepts" you get rid of firewalls.
The whole point of a firewall is to be conservative.

> sites which RST these ECN carrying packets are the ones which disturb
> me the most, in the Cisco PIX case does the firewall send a reset

So, how would properly written pre-ECN software indicate
rejection of packets with the unknown ECN flag?

> That's a really anal, zero purpose, check to put into a firewall.
> I don't know of even any embedded printer stacks that puke when
> the reserved flag bits are non-zero.  The only things this protects
> anyone from are extensions such as ECN :-)

Who knows what attacks might be done with future extensions?
Your firewall is buggy if it passes strange packets.
-
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 kernel TCP, network connections and iptables

[George Athanassopoulos]

On Fri, 8 Sep 2000, Andi Kleen wrote:

:The source address does not matter.

  Well from the attacker's point of view I believe it does. For many reasons
  starting from the fact that the more ip addresses, the more difficult to
  block (per ip-blocking firewall basis) and, if there is a chance for the
  linux ipv4 code of handling some kind of floods per host basis (eg buffering
  "bad" hostips for some time for doing some special communication with those),
  then it is even worse. Btw the same can happen with userspace code doing
  buffering.

:Define netdead exactly. The machine is very unresponsive to any local input,
:correct ?

  During the attack and while the machine is replying RST's, seems like the
  NIC cannot get a chance to send a single packet to machines connected to
  the same switch. If, I disable replying of RST's (with ipfw - that is
  allow only incoming and outgoing packets at specific ports), even when during
  the attack is going on, the linux machine can happily communicate with others.

:Not quite. The reason is that it processes so many interrupts that it cannot
:do any other work.  The NIC interrupts feeds packet much faster than the
:network bottom half can process them. The NIC interrupt and the NETBH
:are running near continuously, not leaving any CPU time for anything else.
:
:It is a well known weakness. Get two machines connected via fast ethernet. 
:Send a stream of 64byte UDP packets from one to the other without any rate
:limit. The other is nearly dead (and it doesn't send any RSTs at all). It 
:helps a bit to have a NIC that does proper interrupt mitigation in this 
:case and does flow control with your NIC [e.g. there are some hacked tulip 
:drivers that handle it better, most gigabit ethernet chips also handle it 
:better because it is a bigger problem on gigabit ethernet]
:
:I think your analysis of that the replied RSTs are the main problem is not
:quite correct. 

  During the attack the linux does not have any special load and internaly,
  processes and everything are doing great (either when replying RSTs or when
  I have disabled them). But if it is replying RSTs, I can only sit at the
  console and see it is doing great because it is unreachable (meaning it takes
  about 15 minutes to get an established an ssh connection to it) from everywhere
  else. In other words, apart from its network connectivity, all else is
  doing great.

:I don't know why you're blocking non ACK packets, it does not make much sense.

  If you live in an ideal networld, it doesn't. I don't.

:It seems your firewall can take packet floods better than your IRC server.
:Not suprising.

  Actually it is not a masquerading firewall. It is only an ip-blocking
  firewall. It does not take any flood. It justs forwards packets as it's
  been told to and that includes all incoming TCP packets with ACK bit set at
  defined port ranges.

:It'll probably help against clueless script kiddies that only run a single
:attack script, but be warned that there are other ways to make TCP bounce 
:packets as well (given an established connection) 

  The fact is that I am doing fine with all the other ways except for this one
  from the script kiddies and that's because they make my 100mbps NIC
  sing back lots of RSTs flooding itself (and the rest on the network path
  that packets follow) off.

--
George Athanassopoulos
http://www.real.macedonia.gr
http://www.egnatia.ee.auth.gr

-
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] af_netrom.c: do resource release on failure

[Torben Mathiasen]

On Fri, Sep 08 2000, Arnaldo Carvalho de Melo wrote:
> Hi,
> 
>   Please take a look and consider applying. Some of it are small cleanups, if
> they're deemed unnecessary, lemme now and I'm back it off. I think that there
> are some more unchecked calls that need fixing, but I think its better to keep
> the patches smaller and incremental, what do you think?
>

How about converting the cli() code to spin_locks while we are at it?

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
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 debugger...

[Rik van Riel]

On Fri, 8 Sep 2000, Jeff V. Merkey wrote:

> This thread is dead.  I am porting the MANOS debugger to Linux,

Ohhh cool. While I don't use debuggers myself, I know people
who really like having a good debugger around and are more
productive finding and fixing problems when they have one.

A debugger is a good tool for some people and, IMHO, it would
be good for those people to have the choice of applying your
patch and fixing the problems in their style...

[snip NTFS on Linux announcement ... cool]

> NDS provides no value to Linux unless it's integrated into the
> OS, which will happen when MANOS goes out next year around
> March.  NDS is more of a Microsoft play than a Linux play and
> Linux already has better internet directory technology than NDS
> -- NDS is better for managing LAN's.

It should be interesting to see what happens here. First
SAMBA, then the Kerberos thing and now NDS ... looks like
we might be able to beat Microsoft on their home turf ;)

(yes, I know IRIX has the SAMBA performance record, but
still... ;))

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
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 debugger...

[Jeff V. Merkey]

This thread is dead.  I am porting the MANOS debugger to Linux, and I
have dissolved TRG's incestuous relationship with Microsoft so we could
integrate a full NTFS on Linux -- two issues down.  NDS provides no
value to Linux unless it's integrated into the OS, which will happen
when MANOS goes out next year around March.   NDS is more of a Microsoft
play than a Linux play and Linux already has better internet directory
technology than NDS -- NDS is better for managing LAN's. 

:-)

Jeff

Stephen Williams wrote:
> 
> >From:   "Jeff V. Merkey" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
> Linux
> 
> >"The lack of a Kernel Debugger and other basic kernel level facilities on
> >Linux make TRG's job about 20 times harder on Linux and take almost 10
> >times as long as is possible on NT, NetWare, or MANOS to develop
> >software asa result ofthis."
> 
> I'm right now arguing with win2000 PnP insanity for my *PCI* device, and
> I can say with some confidence that Linux driver development is so much
> easier that it's not funny.
> 
> The horror, the horror
> --
> Steve Williams"The woods are lovely, dark and deep.
> [EMAIL PROTECTED]  But I have promises to keep,
> [EMAIL PROTECTED]and lines to code before I sleep,
> http://www.picturel.com   And lines to code before I sleep."
> 
> -
> 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: kernel debugger...

[Stephen Williams]

>From:   "Jeff V. Merkey" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
Linux

>"The lack of a Kernel Debugger and other basic kernel level facilities on
>Linux make TRG's job about 20 times harder on Linux and take almost 10
>times as long as is possible on NT, NetWare, or MANOS to develop
>software asa result ofthis."

I'm right now arguing with win2000 PnP insanity for my *PCI* device, and
I can say with some confidence that Linux driver development is so much
easier that it's not funny.


The horror, the horror
-- 
Steve Williams"The woods are lovely, dark and deep.
[EMAIL PROTECTED]  But I have promises to keep,
[EMAIL PROTECTED]and lines to code before I sleep,
http://www.picturel.com   And lines to code before I sleep."


-
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: modules_install?

[Rik van Riel]

On Fri, 8 Sep 2000, Alan Cox wrote:

> > PS: How the hell did we go from complaining about the "stubby modules tree"
> 
> We ??
> 
> I thought you were on a one man insulting session aimed at the
> Makefile maintainer ?

Maybe there's someone with him that prevents him from
releasing his superiour open source makefile technology
to the general public? ;)

cheers,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
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 debugger...

[Alexander Stohr]

I am refering to:

>Date:   Sat, 02 Sep 2000 15:00:20 -0600
>From:   "Jeff V. Merkey" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
Linux

>"The lack of a Kernel Debugger and other basic kernel level facilities on
>Linux make TRG's job about 20 times harder on Linux and take almost 10
>times as long as is possible on NT, NetWare, or MANOS to develop
>software asa result ofthis."

Nope, you are false... There is a kernel debugger, i did test drive it
for a few nice things. Its called PrivateICE or short pICE. It was
availabel via a website which URL i have not yet handy and it
truely does source and assembler debugging of kernel modules now.

Unfortunately AFAIK its not stable until Monday and its source
is not yet published - but in fact there _is_ such a promising project.

Bye, AlexS.

PS: i am not subscribed to this list.

-
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-test8-pre1 is quite bad / how about integrating Rik's VM

[Nix]

Martin Dalecki <[EMAIL PROTECTED]> writes:

> There is some facility allowing to implement this kind of things
> in the C++ part of the most recent EGCS version which makes implementing
> such things "relatively" easy - basiclly there is the provision to dump
> the parser trees as easy to process ascii text already there.
> 
> Basically I think this dererr of syntactical analysis can only be
> implementen by serious help from the compiler.

Luckily, as you said, GCC can do it :) g++ only, for now, but this
should change.

> Maybe this is a new argument to facilitate at least correct syntactical
> processing of the kernel by  the C++ flavour of EGCS?

No. By the time GCC 3.0 comes out, function-at-a-time processing will
have migrated to C as well; the process is already underway.

> Please note that this wouldn't need to generate really executable code -
> which as we all know is rather difficult due to the extensive runtime
> support as well as ehm. the wired calling conventions C++ is oppressing
> on the compiler... Just correct syntactical processing is all what's
> neccessary -

But it isn't needed; GCC 3.0 should support this sort of thing in C,
too, unless there is something I am missing.

-- 
`OS's and GUI's come and go, only Emacs has lasting power.' --- Per Abrahamsen
-
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/

[release] packet-0.0.2c

[Jens Axboe]

Hi,

This project has been sleeping for a while, so I thought it was about time
something happened. And now it has - I've put up version 0.0.2c of the
CD-RW packet writing module, aka the "happy birthday grandma" release 8)

A summary of some of the changes:

- inc usage count of buffer heads
- add internal buffer pool to avoid deadlock on oom
- gather data for as many buffers as we have, before initiating write. this
  allows the laser to stay on longer, giving better performance.
- fix always busy when tray can't be locked
- remove request duplication nastiness, inject directly into the target
- adapted to devfs and elevator changes
- added proc interface

Not a whole lot, this is just to get the ball rolling again. However,
the addition of the internal buffer pool was something that should have
been added a long time ago. So this release should be significantly more
stable than 0.0.2b -- at least it is for me, your mileage may vary.

The patch is against 2.4.0-test7 and can be found at:

*.kernel.org/pub/linux/kernel/people/axboe/packet

or

http://sourceforge.net/projects/packet-cd/

-- 
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE 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: [RFC] Wine speedup through kernel module

[J. Robert von Behren]

David Howells wrote:

>  (2) Some sort of support for (dynamically allocated) system calls implemented
>  in modules.

FWIW, this can be done with relatively low overhead by creating a
miscelaneous character device, and just using write() to write in the
arguments.  This is a bit worse than passing things through registers,
but doesn't seem all that bad.

Nonetheless, having some entries in the syscall table that are
designated as "dynamically allocatable" would be a nifty trick.  If the
kernel managed these, modules coluld safely grab a few at load time, and
then declare which indices to use via a /proc file.

-Rob von Behren
-
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] af_netrom.c: do resource release on failure

[Arnaldo Carvalho de Melo]

Hi,

Please take a look and consider applying. Some of it are small cleanups, if
they're deemed unnecessary, lemme now and I'm back it off. I think that there
are some more unchecked calls that need fixing, but I think its better to keep
the patches smaller and incremental, what do you think?

- Arnaldo

--- linux-2.4.0-test8-6/include/net/nrcall.hFri Apr 12 03:49:47 1996
+++ linux-2.4.0-test8-6.acme/include/net/nrcall.h   Fri Sep  8 14:05:19 2000
@@ -1,2 +1,2 @@
 /* Separate to keep compilation of protocols.c simpler */
-extern void nr_proto_init(struct net_proto *pro);
+extern int nr_proto_init(struct net_proto *pro);
--- linux-2.4.0-test8-6/net/netrom/af_netrom.c  Thu Sep  7 14:01:43 2000
+++ linux-2.4.0-test8-6.acme/net/netrom/af_netrom.c Fri Sep  8 14:03:49 2000
@@ -31,6 +31,8 @@
  * NET/ROM 007 Jonathan(G4KLX) New timer architecture.
  * Impmented Idle timer.
  * Arnaldo C. Melo s/suser/capable/, micro cleanups
+ * Arnaldo C. Melo further cleanups, do resource release on
+ * failure in nr_proto_init
  */
 
 #include 
@@ -68,6 +70,9 @@
 
 int nr_ndevs = 4;
 
+static const char __initdata *version_info =
+   "G4KLX NET/ROM for Linux. Version 0.7 for AX25.037 Linux 2.1\n";
+
 int sysctl_netrom_default_path_quality= NR_DEFAULT_QUAL;
 int sysctl_netrom_obsolescence_count_initialiser  = NR_DEFAULT_OBS;
 int sysctl_netrom_network_ttl_initialiser = NR_DEFAULT_TTL;
@@ -128,20 +133,18 @@
 
if ((s = nr_list) == sk) {
nr_list = s->next;
-   restore_flags(flags);
-   return;
+   goto out;
}
 
while (s != NULL && s->next != NULL) {
if (s->next == sk) {
s->next = sk->next;
-   restore_flags(flags);
-   return;
+   goto out;
}
 
s = s->next;
}
-
+out:
restore_flags(flags);
 }
 
@@ -201,15 +204,12 @@
save_flags(flags);
cli();
 
-   for (s = nr_list; s != NULL; s = s->next) {
-   if (ax25cmp(>protinfo.nr->source_addr, addr) == 0 && s->state == 
TCP_LISTEN) {
-   restore_flags(flags);
-   return s;
-   }
-   }
+   for (s = nr_list; s != NULL; s = s->next)
+   if (ax25cmp(>protinfo.nr->source_addr, addr) == 0 && s->state == 
+TCP_LISTEN)
+   break;
 
restore_flags(flags);
-   return NULL;
+   return s;
 }
 
 /*
@@ -223,16 +223,12 @@
save_flags(flags);
cli();
 
-   for (s = nr_list; s != NULL; s = s->next) {
-   if (s->protinfo.nr->my_index == index && s->protinfo.nr->my_id == id) {
-   restore_flags(flags);
-   return s;
-   }
-   }
+   for (s = nr_list; s != NULL; s = s->next)
+   if (s->protinfo.nr->my_index == index && s->protinfo.nr->my_id == id)
+   break;
 
restore_flags(flags);
-
-   return NULL;
+   return s;
 }
 
 /*
@@ -246,16 +242,14 @@
save_flags(flags);
cli();
 
-   for (s = nr_list; s != NULL; s = s->next) {
-   if (s->protinfo.nr->your_index == index && s->protinfo.nr->your_id == 
id && ax25cmp(>protinfo.nr->dest_addr, dest) == 0) {
-   restore_flags(flags);
-   return s;
-   }
-   }
+   for (s = nr_list; s != NULL; s = s->next)
+   if (s->protinfo.nr->your_index == index &&
+   s->protinfo.nr->your_id == id &&
+   ax25cmp(>protinfo.nr->dest_addr, dest) == 0)
+   break;
 
restore_flags(flags);
-
-   return NULL;
+   return s;
 }
 
 /*
@@ -389,10 +383,9 @@
return -EINVAL;
sk->protinfo.nr->idle = opt * 60 * HZ;
return 0;
-
-   default:
-   return -ENOPROTOOPT;
}
+
+   return -ENOPROTOOPT;
 }
 
 static int nr_getsockopt(struct socket *sock, int level, int optname,
@@ -1122,12 +1115,11 @@
}
 
case SIOCGSTAMP:
-   if (sk != NULL) {
-   if (sk->stamp.tv_sec == 0)
-   return -ENOENT;
-   return copy_to_user((void *)arg, >stamp, 
sizeof(struct timeval)) ? -EFAULT : 0;
-   }
-   return -EINVAL;
+   if (!sk)
+   return -EINVAL;
+   if (sk->stamp.tv_sec == 0)
+   return -ENOENT;
+   return copy_to_user((void *)arg, >stamp, sizeof(struct 
+timeval)) ? 

Re: [PATCH] panic when booting Intel XXPRESS SMP boards

[Linus Torvalds]

On Fri, 8 Sep 2000, Maciej W. Rozycki wrote:
> 
>  While you may surely use your patch for now, I don't think it's good as a
> general solution.  I think we should either handle all busses (some of
> them were never actually used for i386 machines) or leave the code as is. 
> By handling of all busses I mean not to choke on them unless there is an
> interrupt entry referring to such a bus.  This would fullfill the first
> reason but not the second one.  That wouldn't be a major failure, I
> suppose, as we are not collectors of hardware configuration specs anyway
> (anyone?). 

I'm doing an alternative patch that just igores unknown buses, because
paniccing is definitely the wrong answer for anything but some early
debugging ("did I catch all the relevant cases?").

It looks like the simplest solution is to just make bus number 0 be
"unknown", and leave it at that (and start ISA etc from 1).  Wouldn't you
agree?

I'd love to have somebody (yes, you) look at the actual MP table and see
if there is something special with the XXPRESS bus, but in the end even if
we don't know a bus we're better off always just mentioning the fact
("Unknown bus ") and going on with our life. Maybe the system won't
work simply becasue we won't find any critical devices off the bus, but if
we panic we _know_ that it won't work, so..

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: Scalability Efforts

[Rik van Riel]

On Thu, 7 Sep 2000, Marty Fouts wrote:

> FWIW, large system scalability, especially NUMA is not tractable
> with a 'one size (algorithm) fits all' approach, and can be a
> significant test of the degree of modularity in your system.

> Different relative costs of access to the different levels of
> the memory hierarchy and different models of cache concurrency,
> especially, tend to make what works for system A be maximally
> pessimal for system B.

The first thing to tackle is making sure a lot of global
things in the system become per-node.

Something like that will increase scalability on various
kinds of hardware while not affecting performance adversely
on other systems.

Other scalability things will have to receive more care
as to not upset existing systems, but I'm sure we'll be
able to get a long way by simply moving things into local
structures...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
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] BeOS fs support for 2.2.16 update

[Miles Lott]

This is the third in a series to add readonly BeOS fs
support to 2.2.16.  Changes in this version:

o re-enabled functions in debug.c - must edit include/linux/beos_fs.h
  and enable BEOS_DEBUG define to use.  Removed most printk's.
o Beginning of write support.  This does not work, yet.

Notes:  I will release another patch for 2.2.18preX if desired, but
  the only part that fuzzes out is the patching of fs.h, which should
  be easy enough to fix.
I am in contact with the author of befs and the original author
  of this code, so hopefully write support will happen RSN.
I plan to continue working to port to 2.4, but am thinking to
  wait until the outcome of write support efforts.

Am I attaching this correctly?
TIA
-- 

Miles Lott - http://milosch.net
Handspring Visor USB and BeOS FS support for Linux
 2.2.16-beos09082000.patch.gz

Re: [PATCH] panic when booting Intel XXPRESS SMP boards

[Maciej W. Rozycki]

On Fri, 8 Sep 2000, Jean-Marc Saffroy wrote:

> We have here an older SMP machine (NCR Globalyst S40, quad Pentium 100)
> with an Intel Xtended Xpress (or XXPRESS) motherboard, and all development
> kernels since 2.3.20 don't boot with SMP on it, because they panic when
> they discover a bus type they don't know ("XPRESS") when parsing the bus
> entries in the MP Configuration Table.

 Hmm, I guess panic() is there for two reasons.  First to avoid booting on
a machine we may have trouble to handle.  Second to make people with such
hardware contact us (like you did ;-) ). 

 While you may surely use your patch for now, I don't think it's good as a
general solution.  I think we should either handle all busses (some of
them were never actually used for i386 machines) or leave the code as is. 
By handling of all busses I mean not to choke on them unless there is an
interrupt entry referring to such a bus.  This would fullfill the first
reason but not the second one.  That wouldn't be a major failure, I
suppose, as we are not collectors of hardware configuration specs anyway
(anyone?). 

 I'll provide real code, but due to a vacation no earlier than after the
following week.  Anyone feel free to work on it earlier. ;-) 

 Would you please check if your MP table really makes use of the XPRESS
bus or does it just define it?  Or send me your MP table if you prefer me
to do the analysis (it's dumped at the very beginning of the bootstrap log
-- you may need to specify `dmesg -s 32768' to get that part). 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+

-
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: Compilation failure on Alpha with test8-pre[2-6]

[Ivan Kokshaysky]

On Sat, Sep 09, 2000 at 12:50:38AM +1100, Anton Blanchard wrote:
> Yeah on most architectures you cant do an xchg of a 16 bit quantity.
> Rusty has a patch:
> 
...
FWIW, here are __xchg_u8 and __xchg_u16 for Alpha.

Ivan.

--- 2.4.0t8p6/include/asm-alpha/system.hThu Sep  7 19:01:46 2000
+++ linux/include/asm-alpha/system.hFri Sep  8 20:12:47 2000
@@ -347,6 +347,56 @@ extern void __global_restore_flags(unsig
  */
 
 extern __inline__ unsigned long
+__xchg_u8(volatile char *m, unsigned long val)
+{
+   unsigned long tmp1, tmp2, addr64;
+
+   __asm__ __volatile__(
+   "   andnot  %4,7,%3\n"
+   "   insbl   %0,%4,%1\n"
+   "1: ldq_l   %2,0(%3)\n"
+   "   extbl   %2,%4,%0\n"
+   "   mskbl   %2,%4,%2\n"
+   "   or  %1,%2,%2\n"
+   "   stq_c   %2,0(%3)\n"
+   "   beq %2,2f\n"
+   "   mb\n"
+   ".subsection 2\n"
+   "2: br  1b\n"
+   ".previous"
+   : "=" (val), "=r" (tmp1), "=r" (tmp2), "=r" (addr64)
+   : "r" ((long)m), "0" (val)
+   : "memory");
+
+   return val;
+}
+
+extern __inline__ unsigned long
+__xchg_u16(volatile short *m, unsigned long val)
+{
+   unsigned long tmp1, tmp2, addr64;
+
+   __asm__ __volatile__(
+   "   andnot  %4,7,%3\n"
+   "   inswl   %0,%4,%1\n"
+   "1: ldq_l   %2,0(%3)\n"
+   "   extwl   %2,%4,%0\n"
+   "   mskwl   %2,%4,%2\n"
+   "   or  %1,%2,%2\n"
+   "   stq_c   %2,0(%3)\n"
+   "   beq %2,2f\n"
+   "   mb\n"
+   ".subsection 2\n"
+   "2: br  1b\n"
+   ".previous"
+   : "=" (val), "=r" (tmp1), "=r" (tmp2), "=r" (addr64)
+   : "r" ((long)m), "0" (val)
+   : "memory");
+
+   return val;
+}
+
+extern __inline__ unsigned long
 __xchg_u32(volatile int *m, unsigned long val)
 {
unsigned long dummy;
@@ -394,6 +444,10 @@ static __inline__ unsigned long
 __xchg(volatile void *ptr, unsigned long x, int size)
 {
switch (size) {
+   case 1:
+   return __xchg_u8(ptr, x);
+   case 2:
+   return __xchg_u16(ptr, x);
case 4:
return __xchg_u32(ptr, x);
case 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: Problems with bluesmoke.c in 2.2.17

[Alan Cox]

> The other day I got the patch for 2.2.17 and after just over a day of normal
> operation, while my sister was playing kpat (KDE solitaire) yesterday
> afternoon, X died and dropped her out to the console.
> After she told me about it later on I found this at the bottom of my dmesg:
> 
> CPU 0: Machine Check Exception: 0004<0>Bank 3: b2080a01general 
>protection fault: 

Ok I print low,high which was wrong - it should read 0004
which is 'machine check in progress'

So its a real machinme check

> CPU:0
> EIP:0010:[]

Oh beautiful. This is wonderful. I've been hoping for a chance to test the MCE
code. Ok you might not agree 8)

Right there is missing \n I'll go fix but the rest of it says

b2  -   register valid, uncorrected error, error enabled
0008-   model specific data
0a01-   memory access,
generic error
l1 cache
processor responding to request


So there we are - a real live CPU error

> Sep  7 17:51:57 fury kernel: CPU 0: Machine Check Exception: 0004<0>Bank 
>0: b200
> 00800800general protection fault: 

b2  -   register valid uncorrected error, error enabled
0008-   model specific data
0800-   memory access, local processor originated request, l0
generic error


-
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: Availability of kdb

[Michael Elizabeth Chastain]

> There are people today that refuse to use computers for writeing,
> and they have good arguments, ...

Harken back to David Miller, who wrote about occupying his hands
with something to keep them the hell off the keyboard while he is
meditating on a screen full of code.

One of my debugging tools is a printer.  I print out bunches of
source code and trace files and then I go to a room *without* any
computers in it and I read for a while.

And I still write a lot of source code with pen and paper.

Michael Elizabeth Chastain

"love without fear"
-
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 kernel TCP, network connections and iptables

[kuznet]

Hello!

> Well, it looks like you're getting hit with stream.c or raped.c and what
> I'm passing on is just what I picked up from a CERT guy at Usenix.  He
> claimed that stream.c worked by exploiting a long path through the kernel

He just said a crap. All the discussion around stream.c is banal
ether pollution.


> to bring the machine to its knees.

The same happens if you send any kind of packets. F.e. nice
method uncatchable by any firewall is to open good TCP connection
and to feed it with single byte packets. 8)

The only way to fight this is not to attach machine to fast network
or to slow down network artificially. 8)

Alexey
-
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: Availability of kdb

[Patrick J. LoPresti]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> Sure. I just don't see many end-users single-stepping through
> interrupt handlers etc.
> 
> But yes, there probably are a few.

I think you would be surprised, and I speak as someone who has found
and fixed race conditions in your kernel.

There are more Linux users who are competent with x86 hardware and SMP
issues than there are Linux developers.  A *lot* more.

When these technically savvy users have a problem, they want to
diagnose it as best they can and then hand it off to a kernel expert
to analyse and to fix.  They wish they had the time to understand the
kernel deeply and come up with the "right" solution, but they don't;
and the expert can do the job ten times faster anyway.

If you give us better diagnostic tools, your kernel *will* improve
faster.  Whether this benefit outweighs the cost is, of course, up to
you.

 - Pat
-
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: Availability of kdb

[Andrew Scott]

On 6 Sep 2000, at 14:03, Linus Torvalds wrote:

> In article <[EMAIL PROTECTED]>,

> >Linus Torvalds wrote:
> 
> Think of rabbits. And think of how the wolf helps them in the end. Not
> by being nice, no. But the rabbits breed, and they are better for having
> to worry a bit.

No matter how much they think about it, or how smart they are, 
they'll alway be food for wolves unless they develop the ability to 
use tools. It isn't smarts and thinking, though they certainly help, 
it's the ability to make and use tools that does it.  

There are all kinds of tools. In many cases you don't need to use 
them. War and Peace was written with a pen. There are people today 
that refuse to use computers for writeing, and they have good 
arguments, but if Tolstoy was born today, he'd probably use a Word 
processor, and he'd probably have written a sequel! It probably 
wouldn't have been the same book, though, and this is not to say it 
would be any better or worse. At least one writer that I'm aware of, 
output slowed considerably when he switched to a word processor 
because it became so easy to edit, that he spent much more time 
tweaking his work.

Most of the people who write and don't use a word processing 'tool' 
are people who didn't grow up with them.

Linux is really just a hobby for a few people. The sort of people who 
insist on climbing cliffs without safety gear. This is ok. It's your 
hobby, but I think that people should understand that it _is_ a hobby.



--Mailed via Pegasus 3.12 & Mercury 1.44---
[EMAIL PROTECTED]Fax (617)373-2942
Andrew Scott   Tel (617)373-5278   _
Northeastern University--138 Meserve Hall / \   /
College of Arts & Sciences-Deans Office  / \ \ /
Boston, Ma. 02115   /   \_/

-
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: spin_lock forgets to clobber memory and other smp fixes [was

[kuznet]

Hello!

> > I guess Alexey point is that the current compiler doesn't notice that.

Rather I proposed explanation, why missing barrier does not
have any effect. 8)8)

Alexey
-
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 kernel TCP, network connections and iptables

[Andi Kleen]

On Fri, Sep 08, 2000 at 05:49:35PM +0300, George Athanassopoulos wrote:
> On Fri, 8 Sep 2000, Andi Kleen wrote:
> 
> :The only way to fix that with TCP is to pull the plug.  You probably didn't
> :understand it, but the RST is only *one* way where TCP replies, but there
> :are lots of other ways too (like ACKs) 
> 
>   I think I know how TCP works but seems like you analyze the subject
>   without having tested in practise.
> 
>   In case you want to test it yourself and see:
>   Well on 4 machines located on different LANs (C class netblocks),
>   run a program as root which constructs TCP ACK packets (win 65535 as shown
>   in my previous tcpdump piece), and sends them coming from different
>   ip addresses (of the same class c netblock though) hitting the same

The source address does not matter.

>   target ip address on random target ports (try random source ports as well).
>   While the attack is going on, your machine is netdead.

Define netdead exactly. The machine is very unresponsive to any local input,
correct ?

>   If not, add 2 more class c netblocks on the attack and it is for sure. And
>   that's because your machine send so many RST's back.

Not quite. The reason is that it processes so many interrupts that it cannot
do any other work.  The NIC interrupts feeds packet much faster than the
network bottom half can process them. The NIC interrupt and the NETBH
are running near continuously, not leaving any CPU time for anything else.

It is a well known weakness. Get two machines connected via fast ethernet. 
Send a stream of 64byte UDP packets from one to the other without any rate
limit. The other is nearly dead (and it doesn't send any RSTs at all). It 
helps a bit to have a NIC that does proper interrupt mitigation in this 
case and does flow control with your NIC [e.g. there are some hacked tulip 
drivers that handle it better, most gigabit ethernet chips also handle it 
better because it is a bigger problem on gigabit ethernet]

I think your analysis of that the replied RSTs are the main problem is not
quite correct. 

>   If you think this is only a "bandwidth" issue with 4 machines against one,
>   try with source attacker machines located on less bandwidth than the target
>   or even the "sum" of their bandwidth less (but not much less) than the
>   target's.
>   The attackers have studied really carefully TCp protocol and
>   why they have choosen ACK bit set for the offending packets (well another
>   reason is because I block non-ACK incoming packets before they enter
>   my netblock with a firewall). Else, sending just TCP packets with no bits

They did it because that hit a well known bug in BSD stacks (making the
stack do much more work than for a simple RST). On Linux it doesn't matter
much.

I don't know why you're blocking non ACK packets, it does not make much sense.

>   Afterall, I have an end-user solution about it in case you
>   are interested: I take FTP service off to another machine and I firewall
>   (ip-block) all packets except for those coming in listening ports and it is
>   over.

It seems your firewall can take packet floods better than your IRC server.
Not suprising.
> 
>   Since I believe we are wasting reader's time, I made my point and
>   let the ones who handle linux's kernel ipv4 decide wether or not somethng
>   should be done at kernel level. For me this email thread is over unless
>   something else about it comes up as "solution"/better-way-of-handling it.
>   Better than nothing, is for sure that delay of sending RSTs that Alan
>   suggested IMHO.

It'll probably help against clueless script kiddies that only run a single
attack script, but be warned that there are other ways to make TCP bounce 
packets as well (given an established connection) 



-Andi
-
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 FAT FS is broken for 2028 blocksize

[Yuri Pudgorodsky]

Hi!

Recently I tried to read old VFAT-formatted MO disk with 2.4.0-test7 kernel.
Long time ago in the days of 2.3.x such operation caused no problems.

Today 2.4.0-testX kernels OOPSes at fat_file_read(), trying to
dereference NULL pointer at (inode->i_sb)->cvf_format->cvf_file_read

Due to 2028 bytes/sector nature of 640MB MO disk,
cvf_format has been initialied to bigblock_cvf.

Here is where a nice NULL pointer coming from,
exactly from between default_fat_bmap() and
default_fat_file_write().

What is this all about?
Incomplete implementation or some kind of typo?



struct cvf_format bigblock_cvf = {
 0, /* version - who cares? */
 "big_blocks",
 0, /* flags - who cares? */
 NULL,
 NULL,
 NULL,
 bigblock_fat_bread,
 bigblock_fat_bread,
 bigblock_fat_brelse,
 bigblock_fat_mark_buffer_dirty,
 bigblock_fat_set_uptodate,
 bigblock_fat_is_uptodate,
 bigblock_fat_ll_rw_block,
 default_fat_access,
 NULL,
 default_fat_bmap,
 NULL,
^^
 default_fat_file_write,
 NULL,
 NULL
};


-
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 kernel TCP, network connections and iptables

[George Athanassopoulos]

On Fri, 8 Sep 2000, Andi Kleen wrote:

:The only way to fix that with TCP is to pull the plug.  You probably didn't
:understand it, but the RST is only *one* way where TCP replies, but there
:are lots of other ways too (like ACKs) 

  I think I know how TCP works but seems like you analyze the subject
  without having tested in practise.

  In case you want to test it yourself and see:
  Well on 4 machines located on different LANs (C class netblocks),
  run a program as root which constructs TCP ACK packets (win 65535 as shown
  in my previous tcpdump piece), and sends them coming from different
  ip addresses (of the same class c netblock though) hitting the same
  target ip address on random target ports (try random source ports as well).
  While the attack is going on, your machine is netdead.
  If not, add 2 more class c netblocks on the attack and it is for sure. And
  that's because your machine send so many RST's back.
  If you think this is only a "bandwidth" issue with 4 machines against one,
  try with source attacker machines located on less bandwidth than the target
  or even the "sum" of their bandwidth less (but not much less) than the
  target's.
  The attackers have studied really carefully TCp protocol and
  why they have choosen ACK bit set for the offending packets (well another
  reason is because I block non-ACK incoming packets before they enter
  my netblock with a firewall). Else, sending just TCP packets with no bits
  the same result (of replying RSTs) would have happened. Just notice the
  win 65535 in conjuction with the ACK bit set. Ask yourself: can it be
  done the same way with other bit sets (like RST), or hitting used ports
  (and/or listening ports). I guess the prefered method of ACK-bit-set-
  only attack, is the most harmful and gives full impact than any other
  TCP attack of similar kind (considering I am already firewalling TCP
  at a previous point - as much as I can because of services as FTP...)
  and that's because it forces the target machine to reply its worst flood.

:If you think you don't want such "weakness"es you should probably look
:for a different protocol than TCP. I don't know any that would fix it.
:The funny thing is that IPSec et.all.  don't help here at all.

  We are going way off topic. I am not complaining or looking for
  any other ways to "solve my problem". I feel (and insist) that
  there is a "weakness" on TCP protocol that can be exploited really
  easy and cause problems. I have isolated ANY kind of network attacks all
  these years but this one seems to be the only one that cannot be
  faced without touching the kernel. That is, everyone knows that
  you have to count on the kernel to behave well at some point and later
  cooperate with userspace programs etc to carry out your task. I feel
  (wether right or wrong I do not know that's why I am asking here) that
  the RST reply from incoming TRASH (flood) packets on unused ports, is
  too fast or it is not handled as smart.

  Afterall, I have an end-user solution about it in case you
  are interested: I take FTP service off to another machine and I firewall
  (ip-block) all packets except for those coming in listening ports and it is
  over.

  Since I believe we are wasting reader's time, I made my point and
  let the ones who handle linux's kernel ipv4 decide wether or not somethng
  should be done at kernel level. For me this email thread is over unless
  something else about it comes up as "solution"/better-way-of-handling it.
  Better than nothing, is for sure that delay of sending RSTs that Alan
  suggested IMHO.

  Thanks for your comments.

--
George Athanassopoulos
http://www.real.macedonia.gr
http://www.egnatia.ee.auth.gr

-
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: Compilation failure on Alpha with test8-pre[2-6]

[Christopher C. Chimelis]

On Sat, 9 Sep 2000, Anton Blanchard wrote:

> Yeah on most architectures you cant do an xchg of a 16 bit quantity.
> Rusty has a patch:

That's what I thought as well, at least for Alpha's case.  Thanks...will
try both patches and let you all know how it goes...

C


-
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: Compilation failure on Alpha with test8-pre[2-6]

[Anton Blanchard]

 
> Great.  I'll apply the patch and see where the next breakage is :-P  I
> believe there was a problem in the netfilter code
> (net/ipv4/netfilter/ipt_REJECT.c, lines 67-68) with the selection of
> which xchg() to use (either __xchg_u32() or __xchg_u64()as detailed in
> include/asm-alpha/system.h) since it's apparently trying to use
> __xchg_called_with_bad_pointer(), which is undefined on purpose.  So
> either something's not getting called properly or the detection is messed
> up (still have to look into it).

Yeah on most architectures you cant do an xchg of a 16 bit quantity.
Rusty has a patch:

diff -ur -X /tmp/fileAYCCtF --minimal 
linux-2.4.0-test7-6/net/ipv4/netfilter/ipt_REJECT.c 
working-2.4.0-test7-6/net/ipv4/netfilter/ipt_REJECT.c
--- linux-2.4.0-test7-6/net/ipv4/netfilter/ipt_REJECT.c Tue Aug 22 17:28:14 2000
+++ working-2.4.0-test7-6/net/ipv4/netfilter/ipt_REJECT.c   Wed Aug 23 18:46:15 
+2000
@@ -27,6 +27,7 @@
struct tcphdr *otcph, *tcph;
struct rtable *rt;
unsigned int otcplen;
+   u_int16_t tmp;
int needs_ack;
 
/* IP header checks: fragment, too short. */
@@ -64,8 +65,11 @@
 
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
 
+   /* Swap source and dest */
nskb->nh.iph->daddr = xchg(>nh.iph->saddr, nskb->nh.iph->daddr);
-   tcph->source = xchg(>dest, tcph->source);
+   tmp = tcph->source;
+   tcph->source = tcph->dest;
+   tcph->dest = tmp;
 
/* Truncate to length (no data) */
tcph->doff = sizeof(struct tcphdr)/4;

-
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: [RFC] Wine speedup through kernel module

[Andi Kleen]

On Fri, Sep 08, 2000 at 02:12:09PM +0100, David Howells wrote:
> 
>  (1) A death-knell callback list to be placed in the task structure. Each
>  function so listed (if any) would be invoked upon exit, signal-death or
>  execve.

The SGI accounting project (and other accouting projects which are underway)
will need similar hooks, so it is not even only required for Wine.

> 
>  (2) Some sort of support for (dynamically allocated) system calls implemented
>  in modules.

Well, that already exists. It is called ioctl. How would the user look up
dynamically allocated system calls anyways, assuming multiple modules etc.? 
Ioctls have that name space probably already neatly solved.



-Andi
-
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: Drivers that potentially leave state as TASK_{UN}INTERRUPTIBLE

[John Levon]

On Wed, 6 Sep 2000, George Anzinger wrote:

> Actually I was not quite correct.  The call to timeout WILL return
> immediately, however, the timeout code will clean up the timer, so there
> should be no worry there.  It is a bug in that the sleep does not happen
> as expected.  I saw at least one place where there were comments about
> it not working.. and he did not set the state.

This was driver/sound/maestro.c btw

john


-- 
"Premature generalization is the root of all evil."
   - Karl Fogel

-
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: Compilation failure on Alpha with test8-pre[2-6]

[Christopher C. Chimelis]

On Fri, 8 Sep 2000, Ivan Kokshaysky wrote:

> Yes, I can reproduce this with gcc-2.95.2 (compiles cleanly with 2.96).
> Looks like older gcc doesn't like when output operand 5 listed
> also as input. Hmm.
> Simple swapping operands 4 and 5 makes gcc happy.

Great.  I'll apply the patch and see where the next breakage is :-P  I
believe there was a problem in the netfilter code
(net/ipv4/netfilter/ipt_REJECT.c, lines 67-68) with the selection of
which xchg() to use (either __xchg_u32() or __xchg_u64()as detailed in
include/asm-alpha/system.h) since it's apparently trying to use
__xchg_called_with_bad_pointer(), which is undefined on purpose.  So
either something's not getting called properly or the detection is messed
up (still have to look into it).

C

-
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: Whining about MIME formatted email

[john slee]

On Fri, Sep 08, 2000 at 06:33:34PM +1100, Keith Owens wrote:
> plain text.  What next, rich text format and HTML with multiple copies
> of the text, MSWord format?

don't joke.  a certain government department here (that shall remain
unnamed) has an email system that *automatically* converts everything to
rtf.  it's, well, yuk? :-(

j.

-- 
john slee <[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: Compilation failure on Alpha with test8-pre[2-6]

[Ivan Kokshaysky]

On Fri, Sep 08, 2000 at 04:19:25AM -0400, Christopher C. Chimelis wrote:
> xor.c: In function `xor_block_alpha':
> xor.c:1791: inconsistent operand constraints in an `asm'
> xor.c: In function `xor_block_alpha_prefetch':
> xor.c:2213: inconsistent operand constraints in an `asm'
> 
Yes, I can reproduce this with gcc-2.95.2 (compiles cleanly with 2.96).
Looks like older gcc doesn't like when output operand 5 listed
also as input. Hmm.
Simple swapping operands 4 and 5 makes gcc happy.

Ivan.

--- 2.4.0p8t5/drivers/block/xor.c   Wed Sep  6 11:57:49 2000
+++ linux/drivers/block/xor.c   Fri Sep  8 16:20:27 2000
@@ -1667,12 +1667,12 @@
ldq %1,8(%6)
ldq %2,16(%6)
ldq %3,24(%6)
-   ldq %4,32(%6)
+   ldq %5,32(%6)
ldq %0,%7(%0)
ldq %1,%7(%1)
ldq %2,%7(%2)
ldq %3,%7(%3)
-   ldq %4,%7(%4)
+   ldq %5,%7(%5)
.align 4
 5:
ldq $0,0(%0)
@@ -1680,13 +1680,13 @@
ldq $2,0(%2)
ldq $3,0(%3)
 
-   ldq $4,0(%4)
+   ldq $4,0(%5)
ldq $5,8(%0)
ldq $6,8(%1)
ldq $7,8(%2)
 
ldq $16,8(%3)
-   ldq $17,8(%4)
+   ldq $17,8(%5)
ldq $18,16(%0)
ldq $19,16(%1)
 
@@ -1695,7 +1695,7 @@
ldq $21,16(%3)
xor $2,$3,$3# 6 cycles from $3 load
 
-   ldq $0,16(%4)
+   ldq $0,16(%5)
xor $1,$3,$3
ldq $1,24(%0)
xor $3,$4,$4# 7 cycles from $4 load
@@ -1715,7 +1715,7 @@
ldq $4,24(%3)
xor $21,$0,$0   # 7 cycles from $0 load
 
-   ldq $5,24(%4)
+   ldq $5,24(%5)
xor $20,$0,$0
ldq $6,32(%0)
ldq $7,32(%1)
@@ -1727,7 +1727,7 @@

ldq $17,32(%3)
xor $2,$4,$4
-   ldq $18,32(%4)
+   ldq $18,32(%5)
ldq $19,40(%0)
 
ldq $20,40(%1)
@@ -1737,7 +1737,7 @@
 
stq $5,24(%0)
xor $6,$7,$7# 7 cycles from $7 load
-   ldq $1,40(%4)
+   ldq $1,40(%5)
ldq $2,48(%0)
 
ldq $3,48(%1)
@@ -1747,7 +1747,7 @@
 
ldq $5,48(%3)
xor $16,$18,$18
-   ldq $6,48(%4)
+   ldq $6,48(%5)
xor $19,$20,$20 # 7 cycles from $20 load
 
stq $18,32(%0)
@@ -1758,7 +1758,7 @@
ldq $16,56(%1)
ldq $17,56(%2)
ldq $18,56(%3)
-   ldq $19,56(%4)
+   ldq $19,56(%5)
 
xor $21,$1,$1
xor $2,$3,$3# 9 cycles from $3 load
@@ -1772,21 +1772,21 @@
 
stq $6,48(%0)
xor $16,$18,$18
-   subq %5,1,%5
+   subq %4,1,%4
xor $18,$19,$19 # 8 cycles from $19 load
 
stq $19,56(%0)
-   addq %4,64,%4
+   addq %5,64,%5
addq %3,64,%3
addq %2,64,%2
 
addq %1,64,%1
addq %0,64,%0
-   bgt %5,5b"
-   : "="(d), "="(s1), "="(s2), "="(s3), "=r"(s4), "=r"(lines)
+   bgt %4,5b"
+   : "="(d), "="(s1), "="(s2), "="(s3), "=r"(lines), "=r"(s4)
/* ARG! We've run out of asm arguments!  We've got to reload
   all those pointers we just loaded.  */
-   : "r"(bh_ptr), "i" (&((struct buffer_head *)0)->b_data), "5"(lines)
+   : "r"(bh_ptr), "i" (&((struct buffer_head *)0)->b_data), "4"(lines)
: "memory", "$0", "$1", "$2", "$3", "$4", "$5", "$6", "$7",
  "$16", "$17", "$18", "$19", "$20", "$21");
return;
@@ -2084,12 +2084,12 @@
ldq %1,8(%6)
ldq %2,16(%6)
ldq %3,24(%6)
-   ldq %4,32(%6)
+   ldq %5,32(%6)
ldq %0,%7(%0)
ldq %1,%7(%1)
ldq %2,%7(%2)
ldq %3,%7(%3)
-   ldq %4,%7(%4)
+   ldq %5,%7(%5)
.align 4
 5:
ldq $0,0(%0)
@@ -2097,13 +2097,13 @@
ldq $2,0(%2)
ldq $3,0(%3)
 
-   ldq $4,0(%4)
+   ldq $4,0(%5)
ldq $5,8(%0)
ldq $6,8(%1)
ldq $7,8(%2)
 
ldq $16,8(%3)
-   ldq $17,8(%4)
+   ldq $17,8(%5)
ldq $18,16(%0)
ldq $19,16(%1)
 
@@ -2112,7 +2112,7 @@
ldq $21,16(%3)
xor $2,$3,$3# 6 cycles from $3 load
 
-   ldq $0,16(%4)
+   ldq $0,16(%5)
xor $1,$3,$3
ldq $1,24(%0)
xor $3,$4,$4# 7 cycles from $4 load
@@ -2132,7 +2132,7 @@
ldq $4,24(%3)
xor $21,$0,$0   # 7 cycles from $0 load
 
-   ldq $5,24(%4)
+   ldq $5,24(%5)
xor $20,$0,$0
ldq $6,32(%0)
ldq $7,32(%1)
@@ -2144,7 +2144,7 @@

ldq $17,32(%3)
xor $2,$4,$4
-   ldq $18,32(%4)
+   ldq $18,32(%5)
ldq $19,40(%0)
 
ldq $20,40(%1)
@@ -2154,7 +2154,7 @@
 
stq $5,24(%0)
xor $6,$7,$7# 7 cycles from $7 load
-   ldq $1,40(%4)
+   ldq $1,40(%5)
ldq $2,48(%0)
 
ldq $3,48(%1)
@@ -2164,7 +2164,7 @@
 
ldq $5,48(%3)
xor $16,$18,$18
-   ldq $6,48(%4)
+   ldq $6,48(%5)
xor $19,$20,$20 # 7 cycles from $20 load
 
stq $18,32(%0)
@@ -2175,7 +2175,7 @@

Oops on boot with both 2.2.17 and 2.4.0t8p6

[Rasmus Andersen]

Hi.

I just got hold of an old machine (P75, 32MB RAM). On trying to install
RH 6.2 on it, I got an oops after loading the kernel from the boot floppy.
I then tried to boot a 2.4.0-test8-pre6 (made with make bzdisk), but got
an oops. The same with 2.2.17.

Any help would be appreciated.



Oops from 2.2.17 (some more before this, but it went offscreen):

ksymoops 0.7c on i686 2.2.17pre13.  Options used
 -V (specified)
 -K (specified)
 -L (specified)
 -O (specified)
 -m 2.2.17/linux/System.map (specified)

Code:<1>Unable to handle kernel NULL pointer dereference at virtual address 0292
Oops: 0
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: 0292 ebx:  ecx: 0293 edx: 0001
esi: 00098800 edi: c1ffa000 ebp: c280 esp: c1ff9ef4
ds: 0018 es: 0018 ss: 0018
Stack: 0292 c02220c8 0082 0293 c300 c0107f85 c1ff9f54 c017e596
   c017ff8e   c101d4a3 c017ff8e c1ff9f54  c1ff8000
   c00e8130  c02220c8 c1fe7910 c1fe7961 c0107bc9 c1ff9f54 
Call Trace: [] [] [] [] [] 
[] []
[] [] [] []
Code: 0f b6 0c 03 89 4c 24 14 51 68 8e e5 17 c0 e8 de a4 00 00 83

>>EIP; c0107f27<=
Trace; c300 
Trace; c0107f85 
Trace; c917e596 
Trace; c197ff8e 
Trace; c919d4a3 
Trace; c017ff8e 
Trace; c0107bc9 
Trace; c0116116 
Trace; c0116141 
Trace; c101615f 
Trace; c01065f3 
Code;  c0107f27 
 <_EIP>:
Code;  c0107f27<=
   0:   0f b6 0c 03   movzbl (%ebx,%eax,1),%ecx   <=
Code;  c0107f2b 
   4:   89 4c 24 14   mov%ecx,0x14(%esp,1)
Code;  c0107f2f 
   8:   51push   %ecx
Code;  c0107f30 
   9:   68 8e e5 17 c0push   $0xc017e58e
Code;  c0107f35 
   e:   e8 de a4 00 00call   a4f1 <_EIP+0xa4f1> c0112418 
Code;  c0107f3a 
  13:   83 00 00  addl   $0x0,(%eax)



Oops from 2.4.0-test8-pre6:

ksymoops 0.7c on i686 2.2.17pre13.  Options used
 -V (specified)
 -K (specified)
 -L (specified)
 -O (specified)
 -m System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 0296
 0296
Oops: 
CPU: 0
EIP: 0010:[<0296>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 12782
eax: 000f3800 ebx: 0010 ecx: 0001 edx: 
esi: c00e8130 edi: c00e8138 ebp: c00e8134 esp: c10bdf80
ds: 0018 es: 0018 ss:0018
Stack: c01df199 49435025 c00e8130 c00e8138 c00e8134 0008e000 000f 
   c01dbfdc  c0105000 0008e000 c10bdfb0 c01df380   c0105000
   c01dfac4 00010f00 c01dbfdc c01e8f8e 00010f00 c01dcaa0 00010f00 c01dbfdc
Call Trace: [] [] [] []
Code: Bad EIP value
Warning (Oops_code): trailing garbage ignored on Code: line
  Text: 'Code: Bad EIP value'
  Garbage: 'IP value'
Error (Oops_code_values): invalid value 0xBad in Code line, must be 2, 4, 8 or 16 
digits, value ignored
Error (Oops_code_values): invalid value 0xE in Code line, must be 2, 4, 8 or 16 
digits, value ignored

>>EIP; 0296 Before first symbol   <=
Trace; c0105000 
Trace; c0105000 
Trace; c01070df 
Trace; c0107517 
Code;  0296 Before first symbol
 <_EIP>:

Kernel Panic: Attempted to kill init.

1 warning and 2 errors issued.  Results may not be reliable.


-- 
Rasmus([EMAIL PROTECTED])

"An intellectual is someone who has been educated beyond their intelligence."
-
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/

Problems with bluesmoke.c in 2.2.17

[Harley Anderson]

The other day I got the patch for 2.2.17 and after just over a day of normal
operation, while my sister was playing kpat (KDE solitaire) yesterday
afternoon, X died and dropped her out to the console.
After she told me about it later on I found this at the bottom of my dmesg:

CPU 0: Machine Check Exception: 0004<0>Bank 3: b2080a01general 
protection fault: 
CPU:0
EIP:0010:[]
EFLAGS: 00010246
eax: 00080a01   ebx: 3200   ecx: 040d   edx: 3200
esi: 000c   edi: 0003   ebp: 0003   esp: c8931f98
ds: 0018   es: 0018   ss: 0018
Process kwm (pid: 998, process nr: 33, stackpage=c8931000)
Stack: bfffe458 bfffe438 0005 c893 040d  0004 00080a01
   c010a035 c8931fc4  40276c60 4055b548 0028 080dd4f0 bfffe458
   bfffe438 080dd4f0 002b 002b  40189e68 0023 00010216
Call Trace: []
Code: 0f 30 a1 04 e4 1b c0 89 44 24 10 45 3b 6c 24 10 0f 8c 3b ff

I was a bit surprised to get something like this in a stable kernel (I have
been running 2.3.99 and up with no significant problems, until today anyway).

I rebooted, mostly to change to a smaller fb mode. And then a few hours later
while in X again, pushing netscape a bit hard maybe.. and then it rebooted itself.

Found this in my syslog afterwards:

Sep  7 17:51:57 fury kernel: CPU 0: Machine Check Exception: 0004<0>Bank 
0: b200
00800800general protection fault: 
Sep  7 17:51:57 fury kernel: CPU 0: Machine Check Exception: 0004<0>Bank 
0: b200
00800800general protection fault: 
Sep  7 17:51:57 fury kernel: CPU:0


I tracked the "Machine Check Exception:" bit down to arch/kernel/bluesmoke.c
(a forboding name for a piece of code).
A new file according to the patch and something that wasn't in Alan's list of
changes for the release.

Most of it is well over my head, but I was wondering how something like this
gets into a stable kernel when it has worked fine without it for so long and
buggers up when it's added in.

Entire dmesg from that day follows. Thought /proc/cpuinfo might be useful too..

Linux version 2.2.17 (root@fury) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 
release)) #3 Tue Sep 5 19:20:19 EST 2000
Detected 300686 kHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 599.65 BogoMIPS
Memory: 193204k/196608k available (748k kernel code, 412k reserved, 2188k data, 56k 
init)
Dentry hash table entries: 32768 (order 6, 256k)
Buffer cache hash table entries: 262144 (order 8, 1024k)
Page cache hash table entries: 65536 (order 6, 256k)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium II (Klamath) stepping 04
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xfae60
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 262144 bhash 65536)
Starting kswapd v 1.5 
vesafb: framebuffer at 0xe600, mapped to 0xcc80, size 4096k
vesafb: mode is 1024x768x8, linelength=1024, pages=4
vesafb: protected mode interface info at c000:0584
vesafb: scrolling: redraw
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)
Real Time Clock Driver v1.09
loop: registered device at major 7
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: WDC AC36400L, ATA DISK drive
hdb: CD-ROM 36X/AKU, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: WDC AC36400L, 6149MB w/256kB Cache, CHS=784/255/63, UDMA
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Partition check:
 hda: hda1 hda2 hda3 hda4
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 56k freed
rtl8139.c:v1.07 5/6/99 Donald Becker 
http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html
eth0: RealTek RTL8139 Fast Ethernet at 0xe400, IRQ 9, 00:48:54:3f:62:a3.
es1370: version v0.31 time 19:25:42 Sep  5 2000
es1370: found adapter at io 0xe800 irq 10
es1370: features: joystick off, line in, mic impedance 0
es1370: unloading
CPU 0: Machine Check Exception: 0004<0>Bank 3: b2080a01general 
protection fault: 
CPU:0
EIP:0010:[]
EFLAGS: 00010246
eax: 00080a01   ebx: 3200   ecx: 040d   edx: 3200
esi: 000c   edi: 0003   ebp: 0003   esp: c8931f98
ds: 0018   es: 0018   ss: 

Recurring oops in test7

[Harley Anderson]

While preparing my first ever post to lkml just now about a problem in 2.2.17
(which I will post after this hopefully), I was fortunate enough to get my
first ever oops. I was in X at the time so I was unaware of the happy occasion.
All I noticed was su segfault once or thrice and then I couldn't start any
more xterms in wmaker.
The machine locked up very soon after, tried to log in from another box and it
was indeed non-recoverable.

Below is my dmesg and the spam I found in syslog after I rebooted.

Linux version 2.4.0-test7 (root@fury) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #23 Thu Aug 24 17:19:42 EST 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 0001 @  (reserved)
 BIOS-e820: 0bf0 @ 0010 (usable)
On node 0 totalpages: 49152
zone(0): 4096 pages.
zone(1): 45056 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=test7 ro root=304 reboot=warm
Initializing CPU#0
Detected 300690234 Hz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 599.65 BogoMIPS
Memory: 191756k/196608k available (912k kernel code, 4464k reserved, 77k data, 184k 
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Intel Pentium II (Klamath) stepping 04
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xfae60, last bus=1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7000] at 00:07.0
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: WDC AC36400L, ATA DISK drive
hdb: CD-ROM 36X/AKU, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 12594960 sectors (6449 MB) w/256KiB Cache, CHS=784/255/63, UDMA(33)
Partition check:
 hda: hda1 hda2 hda3 hda4
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 184k freed
8139too Fast Ethernet driver 0.9.7 loaded
eth0: RealTek RTL8139 Fast Ethernet board found at 0xec00, IRQ 9
eth0:   Chip is 'RTL-8139A'
eth0:   MAC address 00:48:54:3f:62:a3.
ip_tables: (c)2000 Netfilter core team
ip_conntrack (1536 buckets, 12288 max)


Sep  8 19:15:01 fury kernel: serial: failed to unregister serial driver (-16)
Sep  8 19:15:01 fury kernel: serial: failed to unregister callout driver (-16)
Sep  8 19:15:03 fury kernel: Unable to handle kernel paging request at virtual address 
cc839570
Sep  8 19:15:03 fury kernel: Unable to handle kernel paging request at virtual address 
cc839570
Sep  8 19:15:03 fury kernel:  printing eip:
Sep  8 19:15:03 fury kernel: c015bde4
Sep  8 19:15:03 fury kernel: *pde = 0bc85063
Sep  8 19:15:03 fury kernel: *pde = 0bc85063
Sep  8 19:15:03 fury kernel: *pte = 
Sep  8 19:15:03 fury kernel: *pte = 
Sep  8 19:15:03 fury kernel: Oops: 
Sep  8 19:15:03 fury kernel: CPU:0
Sep  8 19:15:03 fury kernel: EIP:0010:[get_tty_driver+28/76]
Sep  8 19:15:03 fury kernel: EFLAGS: 00010286
Sep  8 19:15:03 fury kernel: eax: 0004   ebx:    ecx: c372dd20   edx: 
cc839560
Sep  8 19:15:03 fury kernel: esi: 0004   edi: c01e8b64   ebp: 0004   esp: 
c5961efc
Sep  8 19:15:03 fury kernel: ds: 0018   es: 0018   ss: 0018
Sep  8 19:15:03 fury kernel: Process gpm (pid: 84, stackpage=c5961000)
Sep  8 19:15:03 fury kernel: Stack: c01ed9e0 0020 c012b7a6 0400 ffed 
c372dd20 cbfb51e0 cbfcb960 
Sep  8 19:15:03 fury kernel:0020 0064 ffeb cbfb51e0 0001 
c562a000 c012b933 0004 
Sep  8 19:15:03 fury kernel: c372dd20 cbfb51e0 ffe9 c012abe6 
cbfb51e0 c372dd20 400fd9b4 
Sep  8 19:15:03 fury kernel: Call Trace: [get_chrfops+106/224] [chrdev_open+39/80] 
[dentry_open+194/336] [filp_open+82/92] [sys_open+56/180] [system_call+51/56] 
Sep  8 

Re: [OT] Re: Availability of kdb

[Chris Meadors]

Now that is what I want on a t-shirt.  ;)

On Thu, 7 Sep 2000, Peter Samuelson wrote:

> [Now, centuries-old theological arguments may well be of supreme
> importance in some ways -- an undeniably subjective and personal
> judgment -- but in terms of Linux kernel development they are usually
> considered even more off-topic than the latest clever AC quote.]

-- 
Two penguins were walking on an iceburg.  The first one said to the
second, "you look like you are wearing a tuxedo."  The second one said,
"I might be..."
  --David Lynch, Twin Peaks

-
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.2.17 build reboots

[Richard B. Johnson]

On Fri, 8 Sep 2000, Mark Hindley wrote:

> I have just spent a frustrating day trying to rebuild the 2.2.17 kernel for
> my new Debian potato installation.
> 
[Snipped...]
As a temporary work-around, try a 'append="mem=NNN"' in lilo.conf. So far
everybody who has had symptoms like this has been sucessful booting after
forcing a different memory size than what Linux is interpreting what
the BIOS reports. It is quite probably a bug, probably a boundary
condition with certain amounts of RAM. 

If you have two or more memory "sticks", just remove one and attempt to
boot from your floppy. This might tend to prove the theory.


Cheers,
Dick Johnson

Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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 & cisco firewall

[Alan Cox]

> > the reserved flag bits are non-zero.  The only things this protects
> > anyone from are extensions such as ECN :-)
> 
> To be fair even older netfilter had the same problem (ipt_unclean would
> complain about the reserved bits). It is probably a common bug.  

The current British Standard kitemark for a firewall appears to require the
bug 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/