Re: Linux 2.4.3 Compile Errors - Power Mac

2001-04-20 Thread Jeff Galloway

Jeez David.  Although it was insensitive of me to seek succor from the Linux
folks while speaking Microsoft, you needn't be so touchy about it.  I
promise I won't commit that sin again, however, at least not in these
circles.  (If it makes you feel any better, I'm using a Mac and not a
Wintel.)

For the record, I disagree with the content of your page at
http://www.infradead.org/fileexchange.html.  Viruses can indeed be hidden in
your list of (almost exclusively Microsoft) file formats.  Companies will
certainly enhance their security by following your "common sense" advice.
They can even be more secure by not accepting any email at all.  However, I
don't think that wishing the world would avoid these dominant (and very
useful) formats is a realistic expectation.  It is certainly not "common
sense" to assume as such.

Anyway, in case you may want to help, here's my problem in (virus free)
plain text:

Problem in compiling linux 2.4.3

Compile error message:

After the compiler message:

gcc D__KERNEL__ -I/home/jeff/kernel/linux/include Wall
Wstrict-prototypes O2 fomit-frame-pointer fno-strict-aliasing
D__powerpc__ -fsigned-char msoft-float pipe ffixed-r2 Wno-uninitialized
mmultiple mstring-c o fork.o fork.c

Compiler error message:

fork.c: In function Œcopy_mm:
fork.c:353: fixed or forbidden register 68 (0) was spilled for class
CR0_REGS.
This may be due to a compiler bug or to impossible asm statements or
clauses.
cpp: output pipe has been closed
make[2]: *** [fork.o] Error 1
make[2]: Leaving directory Œ/home/jeff/kernel/linux/kernel
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory Œ/home/jeff/kernel/linux/kernel
make: *** [_dir_kernel] Error 2

Compiling on Power Mac 7600, with dual processor (604e/180) installed,
running kernel 2.2.18 compiled by Jeff Galloway, but otherwise a Yellow Dog
distribution.

/proc/cpuinfo:

processor: 0
cpu: 604e
clock: 180MHz
revision: 2.2
bogomips: 360.12
zero pages: total 0 (0Kb) current: 0 (0Kb) hits: 0/1457 (0%)
machine: Power Macintosh
motherboard: AAPL,7500 MacRISC
L2 cache: 256K unified
memory: 200MB
pmac-generation: OldWorld


Configuration file:

#
# Automatically generated by make menuconfig: don't edit
#
# CONFIG_UID16 is not set

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Platform support
#
CONFIG_PPC=y
CONFIG_6xx=y
# CONFIG_4xx is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_8260 is not set
CONFIG_ALL_PPC=y
# CONFIG_APUS is not set
CONFIG_PPC601_SYNC_FIX=y
CONFIG_SMP=y
CONFIG_IRQ_ALL_CPUS=y
CONFIG_ALTIVEC=y

#
# General setup
#
# CONFIG_HIGHMEM is not set
CONFIG_MOL=y
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
CONFIG_PCI=y
CONFIG_NET=y
CONFIG_SYSCTL=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_KERNEL_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PCI_NAMES=y
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set
CONFIG_PPC_RTC=y
CONFIG_PROC_DEVICETREE=y
CONFIG_PPC_RTAS=y
CONFIG_BOOTX_TEXT=y
CONFIG_PREP_RESIDUAL=y
# CONFIG_CMDLINE_BOOL is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK=y
# CONFIG_RTNETLINK is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
# CONFIG_IP_NF_MATCH_TCPMSS is not set
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m

Re: Linux 2.4.3 Compile Errors - Power Mac

2001-04-20 Thread Jeff Galloway

Sorry, Tom about the word doc faux pas.  I've set out my problem in plain
text below.  I got my source from ftp.kernel.org.

Here's my problem:



Problem in compiling linux 2.4.3

Compile error message:

After the compiler message:

gcc D__KERNEL__ -I/home/jeff/kernel/linux/include Wall
Wstrict-prototypes O2 fomit-frame-pointer fno-strict-aliasing
D__powerpc__ -fsigned-char msoft-float pipe ffixed-r2 Wno-uninitialized
mmultiple mstring-c o fork.o fork.c

Compiler error message:

fork.c: In function Œcopy_mm:
fork.c:353: fixed or forbidden register 68 (0) was spilled for class
CR0_REGS.
This may be due to a compiler bug or to impossible asm statements or
clauses.
cpp: output pipe has been closed
make[2]: *** [fork.o] Error 1
make[2]: Leaving directory Œ/home/jeff/kernel/linux/kernel
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory Œ/home/jeff/kernel/linux/kernel
make: *** [_dir_kernel] Error 2

Compiling on Power Mac 7600, with dual processor (604e/180) installed,
running kernel 2.2.18 compiled by Jeff Galloway, but otherwise a Yellow Dog
distribution.

/proc/cpuinfo:

processor: 0
cpu: 604e
clock: 180MHz
revision: 2.2
bogomips: 360.12
zero pages: total 0 (0Kb) current: 0 (0Kb) hits: 0/1457 (0%)
machine: Power Macintosh
motherboard: AAPL,7500 MacRISC
L2 cache: 256K unified
memory: 200MB
pmac-generation: OldWorld


Configuration file:

#
# Automatically generated by make menuconfig: don't edit
#
# CONFIG_UID16 is not set

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Platform support
#
CONFIG_PPC=y
CONFIG_6xx=y
# CONFIG_4xx is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_8260 is not set
CONFIG_ALL_PPC=y
# CONFIG_APUS is not set
CONFIG_PPC601_SYNC_FIX=y
CONFIG_SMP=y
CONFIG_IRQ_ALL_CPUS=y
CONFIG_ALTIVEC=y

#
# General setup
#
# CONFIG_HIGHMEM is not set
CONFIG_MOL=y
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
CONFIG_PCI=y
CONFIG_NET=y
CONFIG_SYSCTL=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_KERNEL_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PCI_NAMES=y
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set
CONFIG_PPC_RTC=y
CONFIG_PROC_DEVICETREE=y
CONFIG_PPC_RTAS=y
CONFIG_BOOTX_TEXT=y
CONFIG_PREP_RESIDUAL=y
# CONFIG_CMDLINE_BOOL is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK=y
# CONFIG_RTNETLINK is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
# CONFIG_IP_NF_MATCH_TCPMSS is not set
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_NAT_FTP=m
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_TARGET_LOG is not set
# CONFIG_IP_NF_TARGET_TCPMSS is not set
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_NAT_NEEDED=y
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_IPX is not set
CONFIG_ATALK=y
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# 

Re: Allocated swap space versus used swap space

2001-04-20 Thread Marcelo Tosatti



On Fri, 20 Apr 2001, Marcelo Tosatti wrote:

 
 Hi, 

Argh. Silly. 

Well... 

Right now we can get a task killed by the OOM killer even if there is a
lot of _unused_ (but allocated) swap space. The reason for that is the
pre allocation of swap.

Practical example (128MB swap, 960MB ram): 

# fillmem 960 

...

   procs  memoryswap  io system cpu
 r  b  w   swpd   free   buff  cache  si  sobibo   incs  us sy
 0  0  0  0 873548   1760   9244   0   02511   3224   0 1 98
 0  0  0  0 873540   1760   9244   0   0 0 0  103 8   0 0 100
 1  0  0  0 469040   1760   9248   0   0 2 0  221   562   2 17 80
 1  0  1  91980   2068 80  98480   0 362 0   456  277   724   2 26 72
 0  1  2 128516   1560 80 106564  30 2472444 24724  443  8090   0 9  91
 0  1  0  64840 820804 84  66396 112 22436   148 22438  413  9197   1 13  87
 0  0  0  64840 820416104  66768   0   0   198 0  11922   0 0 100
 0  0  0  64840 820416104  66768   0   0 0 0  102 9   0 0 100

...

Out of Memory: Killed process 763 (fillmem).

Around 60MB was written to swap, so there was unused swap space available,
which means the task should _not_ get killed.

We cannot simply check for "(swapper_space.nrpages  0)" or count the
number of dirty swap cache pages to avoid the OOM killer from triggering,
obviously.

We can split the swap map in "used" / "allocated" bits (or something which
gives us that information), but that would be painful to do, I guess. 

Comments ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [2.4.3] PPP errors

2001-04-20 Thread Paul Mackerras

Manfred H. Winter writes:

 Apr  4 02:05:21 marvin pppd[1227]: Plugin /usr/lib/passwordfd.so loaded.
 Apr  4 02:05:21 marvin pppd[1227]: pppd 2.4.0 started by mahowi, uid 500
 Apr  4 02:05:21 marvin pppd[1227]: Perms of /dev/ttyS0 are ok, no 'mesg n' necce
 sary.

Just out of curiosity, what pppd are you running, with what patches?
I don't recognize the message about 'perms of /dev/ttyS0'.
Or does this message come from the passwordfd.so plugin?

 Modules Loaded serial sb sb_lib uart401 isa-pnp NVdriver opl3 sound 
soundcore ipt_MASQUERADE iptable_nat ip_conntrack ppp_generic slhc iptable_filter 
ip_tables af_packet khttpd autofs4 unix 8139too ide-scsi aic7xxx scsi_mod

No ppp_async loaded - that's the problem.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [Ext2-devel] ext2 inode size (on-disk)

2001-04-20 Thread Theodore Tso

On Thu, Apr 19, 2001 at 04:29:52PM -0400, Jeff Garzik wrote:
 [EMAIL PROTECTED] wrote:
  In the long run, it probably makes sense to adjust the algorithms to
  allow for non-power-of-two inode sizes,
 
 If you don't mind, does that imply packing inodes across block
 boundaries?

No, it means that padding the end of each block in the inode table so
that inodes don't cross block boundries.  (i.e., if the inode size is
150 bytes, then there's room for 6 inodes in a 1k block, with 124
bytes left over for padding.)

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Dead symbol elimination, stage 1

2001-04-20 Thread Eyal Lebedinsky

"Eric S. Raymond" wrote:
 
 David Woodhouse [EMAIL PROTECTED]:
 
  [EMAIL PROTECTED] said:
I read this as "I haven't fixed the problem because..."  not as
   "Don't fix the problem."  Please be more explicit next time so I won't
   step on your toes?
 
  "This is not a problem, please don't \"fix\" it".
 
 But it is.  The more false positives I get in the dead-symbol reports,
 the harder it will be to spot real problems like that business in the
 ARM kernel.c file.

Eric,

I found myself in similar situations in the past, and my solution was
to establish a small file of "do not report" symbols. I then use this
file to avoid reporting problems with items that I know are being
handled or are known false positives. Yes, it is not automagic, but
it does do the job.

The file might also include private notes as to the status of each
excluded symbol.

--
Eyal Lebedinsky ([EMAIL PROTECTED]) http://samba.anu.edu.au/eyal/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [Ext2-devel] ext2 inode size (on-disk)

2001-04-20 Thread Theodore Tso

On Thu, Apr 19, 2001 at 10:23:39PM -0400, Alexander Viro wrote:
 
 I'm somewhat concerned about the following: last block of inode table
 fragment may have less inodes than the rest. Reason: number of inodes
 per group should be a multiple of 8 and with inodes bigger than 128
 bytes it may give such effect. Comments?

Yup, that's right.  That shouldn't be too bad, though, since we
already calculate things by dividing by INODES_PER_BLOCK_GROUP.  So
the fact that the last block of the inode table may have some unused
space shouldn't be a problem.

 I would really, really like to end up with accurate description of
 inode table layout somewhere in Documentation/filesystems. Heck, I
 volunteer to write it down and submit into the tree ;-)

The "design and implementation of ext2" paper has a pretty good
explanation of the inode table, but of course it assumed a convenient
inode size of 128, and didn't really go into the issues of what might
happen if the inode size were larger, or not a power of two.

So yeah, getting something which explains how things work now that
things have gotten a bit more complicated would be a good thing.

- Ted


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [Ext2-devel] ext2 inode size (on-disk)

2001-04-20 Thread Theodore Tso

On Thu, Apr 19, 2001 at 11:35:40PM -0600, Andreas Dilger wrote:
 I don't _think_ that there is a requirement for a multiple-of-8 inodes
 per group.  OK, looking into mke2fs (actually lib/ext2fs/initialize.c)
 it _does_ show that it needs to be a multiple of 8, but I'm not sure
 exactly what the "bitmap splicing code" mentioned in the comment is.

It's has to be a multiple of 8 because of how e2fsprogs handles
bitmaps --- that is, it takes the various pieces of all of the
bitmaps, and butts them up together in memory.  It would be possible
to remove this restriction by reworking the e2fsprogs library code,
but quite frankly, I don't think the restriction is all that
unreasonable.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



[PATCH] update drivers/input/keybdev.c

2001-04-20 Thread Paul Mackerras

Linus,

The following patch updates drivers/input/keybdev.c so that we can
generate either linux keycodes or ADB keycodes from keyboards that use
the input layer.  We now have ADB keyboards and mice using the input
layer as well as USB, so it is very useful to have the flexibility to
choose at runtime which type of keycodes you want to receive.  You
already have in your tree all of the other changes that we need in
order to do this, just this one file got missed somehow.

This change has been approved by the maintainer, Vojtech Pavlik.

If you decide not to take this patch, please let me know so I can
send you a patch to back out the corresponding changes that have
already been made in other files.

Paul.

diff -urN linux/drivers/input/keybdev.c pmac/drivers/input/keybdev.c
--- linux/drivers/input/keybdev.c   Thu Apr 19 15:03:43 2001
+++ pmac/drivers/input/keybdev.cFri Apr 20 16:47:48 2001
@@ -38,7 +38,8 @@
 #include linux/kbd_kern.h
 
 #if defined(CONFIG_X86) || defined(CONFIG_IA64) || defined(__alpha__) || \
-defined(__mips__) || defined(CONFIG_SPARC64) || defined(CONFIG_SUPERH)
+defined(__mips__) || defined(CONFIG_SPARC64) || defined(CONFIG_SUPERH) || \
+defined(CONFIG_PPC) || defined(__mc68000__)
 
 static int x86_sysrq_alt = 0;
 #ifdef CONFIG_SPARC64
@@ -63,8 +64,46 @@
308,310,313,314,315,317,318,319,320,321,322,323,324,325,326,330,
332,340,341,342,343,344,345,346,356,359,365,368,369,370,371,372 };
 
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+extern int mac_hid_mouse_emulate_buttons(int, int, int);
+#endif /* CONFIG_MAC_EMUMOUSEBTN */
+#ifdef CONFIG_MAC_ADBKEYCODES
+extern int mac_hid_keyboard_sends_linux_keycodes(void);
+#else
+#define mac_hid_keyboard_sends_linux_keycodes()0
+#endif /* CONFIG_MAC_ADBKEYCODES */
+#if defined(CONFIG_MAC_ADBKEYCODES) || defined(CONFIG_ADB_KEYBOARD)
+static unsigned char mac_keycodes[256] = {
+ 0, 53, 18, 19, 20, 21, 23, 22, 26, 28, 25, 29, 27, 24, 51, 48,
+12, 13, 14, 15, 17, 16, 32, 34, 31, 35, 33, 30, 36, 54,128,  1,
+ 2,  3,  5,  4, 38, 40, 37, 41, 39, 50, 56, 42,  6,  7,  8,  9,
+11, 45, 46, 43, 47, 44,123, 67, 58, 49, 57,122,120, 99,118, 96,
+97, 98,100,101,109, 71,107, 89, 91, 92, 78, 86, 87, 88, 69, 83,
+84, 85, 82, 65, 42,  0, 10,103,111,  0,  0,  0,  0,  0,  0,  0,
+76,125, 75,105,124,110,115, 62,116, 59, 60,119, 61,121,114,117,
+ 0,  0,  0,  0,127, 81,  0,113,  0,  0,  0,  0, 95, 55, 55,  0,
+ 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
+ 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
+ 0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
+ 0,  0,  0,  0,  0, 94,  0, 93,  0,  0,  0,  0,  0,  0,104,102 };
+#endif /* CONFIG_MAC_ADBKEYCODES || CONFIG_ADB_KEYBOARD */
+ 
 static int emulate_raw(unsigned int keycode, int down)
 {
+#ifdef CONFIG_MAC_EMUMOUSEBTN
+   if (mac_hid_mouse_emulate_buttons(1, keycode, down))
+   return 0;
+#endif /* CONFIG_MAC_EMUMOUSEBTN */
+#if defined(CONFIG_MAC_ADBKEYCODES) || defined(CONFIG_ADB_KEYBOARD)
+   if (!mac_hid_keyboard_sends_linux_keycodes()) {
+   if (keycode  255 || !mac_keycodes[keycode])
+   return -1;
+   
+   handle_scancode((mac_keycodes[keycode]  0x7f), down);
+   return 0;
+   }
+#endif /* CONFIG_MAC_ADBKEYCODES || CONFIG_ADB_KEYBOARD */
+
if (keycode  255 || !x86_keycodes[keycode])
return -1; 
 
@@ -103,28 +142,6 @@
if (keycode == KEY_STOP)
sparc_l1_a_state = down;
 #endif
-
-   return 0;
-}
-
-#elif defined(CONFIG_ADB_KEYBOARD)
-
-static unsigned char mac_keycodes[128] =
-   { 0, 53, 18, 19, 20, 21, 23, 22, 26, 28, 25, 29, 27, 24, 51, 48,
-12, 13, 14, 15, 17, 16, 32, 34, 31, 35, 33, 30, 36, 54,128,  1,
- 2,  3,  5,  4, 38, 40, 37, 41, 39, 50, 56, 42,  6,  7,  8,  9,
-11, 45, 46, 43, 47, 44,123, 67, 58, 49, 57,122,120, 99,118, 96,
-97, 98,100,101,109, 71,107, 89, 91, 92, 78, 86, 87, 88, 69, 83,
-84, 85, 82, 65, 42,  0, 10,103,111,  0,  0,  0,  0,  0,  0,  0,
-76,125, 75,105,124,  0,115, 62,116, 59, 60,119, 61,121,114,117,
- 0,  0,  0,  0,127, 81,  0,113,  0,  0,  0,  0,  0, 55, 55 };
-
-static int emulate_raw(unsigned int keycode, int down)
-{
-   if (keycode  127 || !mac_keycodes[keycode])
-   return -1;
-
-   handle_scancode(mac_keycodes[keycode]  0x7f, down);
 
return 0;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Fix for Donald Becker's DP83815 network driver (v1.07)

2001-04-20 Thread Jeff Garzik

Ion Badulescu wrote:
 Well.. Space.c is a dinozaur. However, this is the 2.2 series and no more
 surgery will happen on this kernel, at least normally.
 
 Have you tried loading the drivers as modules? You might have more luck
 with that approach. Space.c was designed at a time when having 4 NIC's in
 a PC was "pushing the limits"...

2.2.recent has module_init/exit, so you don't even need Space.c.

-- 
Jeff Garzik   | "The universe is like a safe to which there is a
Building 1024 |  combination -- but the combination is locked up
MandrakeSoft  |  in the safe."-- Peter DeVries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Fix for Donald Becker's DP83815 network driver (v1.07)

2001-04-20 Thread Ion Badulescu

On Fri, 20 Apr 2001, Jeff Garzik wrote:

  Have you tried loading the drivers as modules? You might have more luck
  with that approach. Space.c was designed at a time when having 4 NIC's in
  a PC was "pushing the limits"...
 
 2.2.recent has module_init/exit, so you don't even need Space.c.

Check again. drivers/net builds a .a, not a .o. Trust me, I've tried.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: FW: Linux 2.4.3 Compile Errors - Power Mac

2001-04-20 Thread Paul Mackerras

Jeff Galloway writes:

 I sent this report to the people indicated below, whose names I got from the
 MAINTAINERS file in the 2.4.3 distribution, but the email address for Mr.
 MacKerras is no longer good and Mr. Chastain wrote me back that he is not
 following 2.4 issues.

I have left Linuxcare and [EMAIL PROTECTED] no longer works.
Please use [EMAIL PROTECTED]

 The compiler error message along with the menuconfig-generated configuration
 file are set out in the attached MS Word document.  I've had similar
 problems with other versions of 2.4.

Hmmm, I have to go to a lot of trouble to read Word documents, so I
don't like receiving them.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



[PATCH] [RESENT] fix bugs in HID driver

2001-04-20 Thread Paul Mackerras

[Oops, re-sent with a subject line this time...]

Linus,

This patch fixes some bugs in drivers/usb/hid.c.  Johannes Erdfelt
(the maintainer) sent it to you previously but it got missed.  Could
it go in 2.4.4 please?  Here are the comments explaining the patch
that I wrote originally:

 The first hunk just fixes some typos in s32ton.  For example, with
 n == 8, the code as it was would return 0x80 if value  127 but 0xff
 if value  -128.  With my change it returns 0x7f for value  127 and
 0x80 for value  -128.

 The second hunk fixes the "cdcd" problem that we see on apple
 keyboards that can only handle 2-key rollover.  If you type "c" "d"
 space quickly on these keyboards, you get a report with the
 error-rollover code (1) in bytes 2 - 7 (instead of the codes for the
 keys that are down).  Without this patch the code thinks that all the
 keys that were down are now up.  When you release one key you get a
 normal report again and the code thinks that the remaining keys have
 been pressed again.  The patch makes the code just discard the report
 once it sees the error-rollover code.

 The remaining hunks fix some endianness problems in the code that sets
 the keyboard leds.

Thanks,
Paul.

diff -urN linux/drivers/usb/hid.c linuxppc_2_4/drivers/usb/hid.c
--- linux/drivers/usb/hid.c Thu Feb 22 14:25:27 2001
+++ linuxppc_2_4/drivers/usb/hid.c  Mon Feb 12 13:35:00 2001
@@ -698,7 +698,7 @@
 static __inline__ __u32 s32ton(__s32 value, unsigned n)
 {
__s32 a = value  (n - 1);
-   if (a  a != -1) return value  0 ? 1  (n - 1) : (1  n) - 1;
+   if (a  a != -1) return value  0 ? 1  (n - 1) : (1  (n - 1)) - 1;
return value  ((1  n) - 1);
 }
 
@@ -1016,9 +1016,15 @@
__s32 max = field-logical_maximum;
__s32 value[count]; /* WARNING: gcc specific */

-   for (n = 0; n  count; n++)
+   for (n = 0; n  count; n++) {
value[n] = min  0 ? snto32(extract(data, offset + n * size, 
size), size) : 
extract(data, offset + n * size, 
size);
+   /* Handle the ErrorRollOver code (1) by simply ignoring this 
+report */
+   if (!(field-flags  HID_MAIN_ITEM_VARIABLE)
+value[n] = min  value[n] = max
+field-usage[value[n] - min].hid == HID_UP_KEYBOARD + 1)
+   return;
+   }
 
for (n = 0; n  count; n++) {
 
@@ -1231,7 +1237,7 @@
 
 static int hid_submit_out(struct hid_device *hid)
 {
-   hid-urbout.transfer_buffer_length = hid-out[hid-outtail].dr.length;
+   hid-urbout.transfer_buffer_length = 
+le16_to_cpup(hid-out[hid-outtail].dr.length);
hid-urbout.transfer_buffer = hid-out[hid-outtail].buffer;
hid-urbout.setup_packet = (void *) (hid-out[hid-outtail].dr);
hid-urbout.dev = hid-dev;
@@ -1271,8 +1277,8 @@
hid_set_field(field, offset, value);
hid_output_report(field-report, hid-out[hid-outhead].buffer);
 
-   hid-out[hid-outhead].dr.value = 0x200 | field-report-id;
-   hid-out[hid-outhead].dr.length = ((field-report-size - 1)  3) + 1;
+   hid-out[hid-outhead].dr.value = cpu_to_le16(0x200 | field-report-id);
+   hid-out[hid-outhead].dr.length = cpu_to_le16((field-report-size + 7)  3);
 
hid-outhead = (hid-outhead + 1)  (HID_CONTROL_FIFO_SIZE - 1);
 
@@ -1445,7 +1451,7 @@
for (n = 0; n  HID_CONTROL_FIFO_SIZE; n++) {
hid-out[n].dr.requesttype = USB_TYPE_CLASS | USB_RECIP_INTERFACE;
hid-out[n].dr.request = USB_REQ_SET_REPORT;
-   hid-out[n].dr.index = hid-ifnum;
+   hid-out[n].dr.index = cpu_to_le16(hid-ifnum);
}
 
hid-input.name = hid-name;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



No Subject

2001-04-20 Thread Paul Mackerras

Linus,

This patch fixes some bugs in drivers/usb/hid.c.  Johannes Erdfelt
(the maintainer) sent it to you previously but it got missed.  Could
it go in 2.4.4 please?  Here are the comments explaining the patch
that I wrote originally:

 The first hunk just fixes some typos in s32ton.  For example, with
 n == 8, the code as it was would return 0x80 if value  127 but 0xff
 if value  -128.  With my change it returns 0x7f for value  127 and
 0x80 for value  -128.

 The second hunk fixes the "cdcd" problem that we see on apple
 keyboards that can only handle 2-key rollover.  If you type "c" "d"
 space quickly on these keyboards, you get a report with the
 error-rollover code (1) in bytes 2 - 7 (instead of the codes for the
 keys that are down).  Without this patch the code thinks that all the
 keys that were down are now up.  When you release one key you get a
 normal report again and the code thinks that the remaining keys have
 been pressed again.  The patch makes the code just discard the report
 once it sees the error-rollover code.

 The remaining hunks fix some endianness problems in the code that sets
 the keyboard leds.

Thanks,
Paul.

diff -urN linux/drivers/usb/hid.c linuxppc_2_4/drivers/usb/hid.c
--- linux/drivers/usb/hid.c Thu Feb 22 14:25:27 2001
+++ linuxppc_2_4/drivers/usb/hid.c  Mon Feb 12 13:35:00 2001
@@ -698,7 +698,7 @@
 static __inline__ __u32 s32ton(__s32 value, unsigned n)
 {
__s32 a = value  (n - 1);
-   if (a  a != -1) return value  0 ? 1  (n - 1) : (1  n) - 1;
+   if (a  a != -1) return value  0 ? 1  (n - 1) : (1  (n - 1)) - 1;
return value  ((1  n) - 1);
 }
 
@@ -1016,9 +1016,15 @@
__s32 max = field-logical_maximum;
__s32 value[count]; /* WARNING: gcc specific */

-   for (n = 0; n  count; n++)
+   for (n = 0; n  count; n++) {
value[n] = min  0 ? snto32(extract(data, offset + n * size, 
size), size) : 
extract(data, offset + n * size, 
size);
+   /* Handle the ErrorRollOver code (1) by simply ignoring this 
+report */
+   if (!(field-flags  HID_MAIN_ITEM_VARIABLE)
+value[n] = min  value[n] = max
+field-usage[value[n] - min].hid == HID_UP_KEYBOARD + 1)
+   return;
+   }
 
for (n = 0; n  count; n++) {
 
@@ -1231,7 +1237,7 @@
 
 static int hid_submit_out(struct hid_device *hid)
 {
-   hid-urbout.transfer_buffer_length = hid-out[hid-outtail].dr.length;
+   hid-urbout.transfer_buffer_length = 
+le16_to_cpup(hid-out[hid-outtail].dr.length);
hid-urbout.transfer_buffer = hid-out[hid-outtail].buffer;
hid-urbout.setup_packet = (void *) (hid-out[hid-outtail].dr);
hid-urbout.dev = hid-dev;
@@ -1271,8 +1277,8 @@
hid_set_field(field, offset, value);
hid_output_report(field-report, hid-out[hid-outhead].buffer);
 
-   hid-out[hid-outhead].dr.value = 0x200 | field-report-id;
-   hid-out[hid-outhead].dr.length = ((field-report-size - 1)  3) + 1;
+   hid-out[hid-outhead].dr.value = cpu_to_le16(0x200 | field-report-id);
+   hid-out[hid-outhead].dr.length = cpu_to_le16((field-report-size + 7)  3);
 
hid-outhead = (hid-outhead + 1)  (HID_CONTROL_FIFO_SIZE - 1);
 
@@ -1445,7 +1451,7 @@
for (n = 0; n  HID_CONTROL_FIFO_SIZE; n++) {
hid-out[n].dr.requesttype = USB_TYPE_CLASS | USB_RECIP_INTERFACE;
hid-out[n].dr.request = USB_REQ_SET_REPORT;
-   hid-out[n].dr.index = hid-ifnum;
+   hid-out[n].dr.index = cpu_to_le16(hid-ifnum);
}
 
hid-input.name = hid-name;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Fix for Donald Becker's DP83815 network driver (v1.07)

2001-04-20 Thread Jeff Garzik

Ion Badulescu wrote:
 
 On Fri, 20 Apr 2001, Jeff Garzik wrote:
 
   Have you tried loading the drivers as modules? You might have more luck
   with that approach. Space.c was designed at a time when having 4 NIC's in
   a PC was "pushing the limits"...
 
  2.2.recent has module_init/exit, so you don't even need Space.c.
 
 Check again. drivers/net builds a .a, not a .o. Trust me, I've tried.

Sure, but if you are patching anyway, it much better to fix that than
hack space.c :)

-- 
Jeff Garzik   | "The universe is like a safe to which there is a
Building 1024 |  combination -- but the combination is locked up
MandrakeSoft  |  in the safe."-- Peter DeVries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: ac10 ide-cd oopses on boot

2001-04-20 Thread Stefan Jaschke

On Friday 20 April 2001 00:49, J . A . Magallon wrote:
 Hi,

 Just built 2.4.3-ac10 and got an oops when booting. It tries to detect
 the CD and gives the oops.
 EIP; c01bfc7c cdrom_get_entry+1c/50   =

This appears to be a known problem. Jens Axboe sent a patch in a different
thread ("SD-W2002 DVD-RAM") that fixes this. I am including it
here for your convenience. (The patch is against 2.4.4-pre4 + Jens' 
latest fixes.) 

Stefan



--- drivers/cdrom/cdrom.c~  Thu Apr 19 13:44:46 2001
+++ drivers/cdrom/cdrom.c   Thu Apr 19 13:45:33 2001
@@ -350,6 +350,12 @@
 {
int i, nr, foo;
 
+   if (!cdrom_numbers) {
+   int n_entries = CDROM_MAX_CDROMS / (sizeof(unsigned long) * 8);
+   cdrom_numbers = kmalloc(n_entries * sizeof(unsigned long), GFP_KERNEL);
+   memset(cdrom_numbers, 0, n_entries * sizeof(unsigned long));
+   }
+
nr = 0;
foo = -1;
for (i = 0; i  CDROM_MAX_CDROMS / (sizeof(unsigned long) * 8); i++) {
@@ -2696,10 +2702,6 @@
 
 static int __init cdrom_init(void)
 {
-   int n_entries = CDROM_MAX_CDROMS / (sizeof(unsigned long) * 8);
-
-   cdrom_numbers = kmalloc(n_entries * sizeof(unsigned long), GFP_KERNEL);
-
 #ifdef CONFIG_SYSCTL
cdrom_sysctl_register();
 #endif



Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

2001-04-20 Thread Luca Berra

Fuck!  I hate these things early in the morning.

what gets me extremely pissed in the whole business is that i don't
believe that splitting the mailing list is the solution to LVM problems.
Escpecially since we have a number of lusers of lwm at the time being.

I believe sistina is mostly at fault there, not for the mailing list issue
(i really don't believe people getting kicked out, while the moderation
messages are probably due to mailman braindamage)
but for political reasons (stop making it look as a sistina-only project, it pisses
everyone)

we have some serous problems here.

an lvm in the kernel which is badly broken(tm)

a better lvm (still buggy according to many kernel hackers, but better still),
which does not get into the kernel for communication reasons. (Alan can you help?
there is a lot of stuff that goes in -ac before going to mainstream)

A development model where only sistina people have access to cvs. This is bad, has the 
only
effect of pissing off people like Andreas which has been feeding patches and good 
ideas for
many months now, besides it leads to people having their own lvm tree, so everybody is
testing their development version, which has nothing to do with the version in the
goddamned kernel.

now what i propose is (some has already been said):
lets's vote for which mailing list we want to keep (and everybody accept the result)

open the goddam cvs to hackers that request access to it, you can use different 
branches
and do code freezes with cvs, so it won't hurt releases schedules.

try to ship the most evident bugfixes from cvs to linus, please all long-time kernel 
hakcers
who got involved in this help do this.

open up also the decision process (IOP 11 in beta5 and IOP 10 back in beta6
could not have happened if somebody eles knew about the IOP change.)

Regards,
L.

(Sorry for the big CC list, but i dunno who is subscribed to what anymore)



-- 
Luca Berra -- [EMAIL PROTECTED]
Communication Media  Services S.r.l.
 /"\
 \ / ASCII RIBBON CAMPAIGN
  XAGAINST HTML MAIL
 / \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



RE: 2.4 stable when?

2001-04-20 Thread George Bonser

Just to follow up on this ...

I am now running 2.4.4pre4 and it seems to be stable. If I reboot the
machine (or simply stop and restart apache) the load avg does go much higher
than I am used to seeing (near 50 for about 5 minutes or so) it does not
hang as previous kernels did.  I have the vmstat and top -i info if anyone
is curious.  It does not touch swap, though.





 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]On Behalf Of George Bonser
 Sent: Sunday, April 15, 2001 8:39 AM
 To: Rik van Riel
 Cc: [EMAIL PROTECTED]
 Subject: RE: 2.4 stable when?


 
   Is there any information that would be helpful to the kernel
   developers that I might be able to provide or is this a known issue
   that is currently being worked out?
 
  I never heard about this problem.  What would be helpful is to
  send a few minutes' (a full 'load cycle'?) worth of output from
  'vmstat 5' and some information about the configuration of the
  machine.
 
  It's possible I'll want more information later, but just the
  vmstat output would be a good start.
 
  If the data isn't too big, I'd appreciate it if you could also
  CC [EMAIL PROTECTED]
 
  regards,

 Sounds good. I think I can do this.  Also, it appears that the problem is
 related to how busy the farm is.  The machines are load balanced
 in a "least
 connections" mode. There are 5 servers in the farm. Suppose I have 300
 connections to each machine and reboot one to load the new kernel.

 When that server comes back up it is handed 300 connections all
 at once. It
 seems (and this is subjective ... does it handle things differently with
 more than 256 processes?) that when I give the machine much more than 200
 connections, it is very slow to clear them.  It seems to have trouble at
 that point clearing connections as fast as it is getting them. If I have
 less than 200 connections initially, it seems to handle things OK.

 I tried to collect some data last night but it appeared to work ok. I will
 wait for the load to come up later today and try it during its peak time.
 While I could put the balancer into a "slow start" mode, 2.2 always seemed
 to handle the burst of new connections just fine so I didn't bother.

 The machine is a UP Pentium-III 800MHz with 512MB of RAM running Debian
 Woody. It is a SuperMicro 6010L 1U unit with the SuperMicro 370DLR
 motherboard. This uses the ServerWorks ServerSet III LE chipset
 and Adaptec
 AIC-7892 Ultra160 disk controller and on-board dual Intel NIC (only using
 eth0).

 I have cut the configuration pretty much to the bone, no
 NetFilter support,
 no QoS, no Audio/Video. Tried to get it as plain vanilla as possible (my
 first step when having problems).

 I was able to run 2.4.0-test12 in this application and did for quite some
 time. I don't recall trying 2.4.1 but I know I had severe problems with
 2.4.2 and 2.4.3. Now that I think about it, I am not sure the farm was as
 busy back when I put 2.4.0 on it or that I ever rebooted during my peak
 period. This might have been a problem all along but I just never
 saw it. It
 seems to have to do with handing the machine a large number of connections
 at once and then a stream of them at a pretty good clip. It is
 getting about
 40 connections/second right this minute but that should come up a
 bit in the
 next couple of hours.

 To be quite honest, I could run this on 2.2 forever, it is just a
 webserver.
 My only reason for using 2.4 would be to see if I can go SMP on
 these things
 when my load gets higher and I get some benefit of the finer
 granularity of
 2.4 in SMP to serve a higher load with fewer machines than would
 be possible
 with 2.2. That, and just to beat on a 2.4 kernel and report any
 problems to
 you guys.


 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



[PATCH] PPP update against 2.4.4-pre5

2001-04-20 Thread Paul Mackerras

Linus, Alan,

The patch below does two things:

- It takes out the rest of the compatibility stuff that is no longer
  used, and which has the possibility of accessing memory that has
  been kfree'd (this could happen if you did a blocking read on a tty
  in PPP line discipline, and the tty hangs up).  This possibility was
  pointed out by Kevin Buhr.

- It adds packet filtering to the PPP driver.  The main point of this
  is so that you can specify that certain sorts of packets don't count
  as activity, so they don't reset the idle timer and they don't bring
  up a demand-dialled link.  This is a useful feature that I get asked
  for periodically, it's a small amount of code (in fact it's no extra
  code if you don't enable CONFIG_PPP_FILTER), and it's something I have
  had in my tree since last July without any problems.

Linus, could this go in 2.4.4 please?

Thanks,
Paul.

diff -urN linux/Documentation/Configure.help pmac/Documentation/Configure.help
--- linux/Documentation/Configure.help  Fri Apr 20 17:04:13 2001
+++ pmac/Documentation/Configure.help   Fri Apr 20 17:45:20 2001
@@ -1756,6 +1756,10 @@
   certain types of data to get through the socket. Linux Socket
   Filtering works on all socket types except TCP for now. See the text
   file Documentation/networking/filter.txt for more information.
+
+  You need to say Y here if you want to use PPP packet filtering
+  (see the CONFIG_PPP_FILTER option below).
+
   If unsure, say N.
 
 Network packet filtering
@@ -7087,6 +7091,17 @@
 
   If unsure, say N.
 
+PPP filtering (EXPERIMENTAL)
+CONFIG_PPP_FILTER
+  Say Y here if you want to be able to filter the packets passing over
+  PPP interfaces.  This allows you to control which packets count as
+  activity (i.e. which packets will reset the idle timer or bring up
+  a demand-dialled link) and which packets are to be dropped entirely.
+  You need to say Y here if you wish to use the pass-filter and
+  active-filter options to pppd.
+
+  If unsure, say N.
+
 PPP support for async serial ports
 CONFIG_PPP_ASYNC
   Say Y (or M) here if you want to be able to use PPP over standard
diff -urN linux/drivers/net/Config.in pmac/drivers/net/Config.in
--- linux/drivers/net/Config.in Fri Apr 20 17:04:33 2001
+++ pmac/drivers/net/Config.in  Fri Apr 20 17:24:04 2001
@@ -227,6 +227,7 @@
 tristate 'PPP (point-to-point protocol) support' CONFIG_PPP
 if [ ! "$CONFIG_PPP" = "n" ]; then
dep_bool '  PPP multilink support (EXPERIMENTAL)' CONFIG_PPP_MULTILINK 
$CONFIG_EXPERIMENTAL
+   bool '  PPP filtering' CONFIG_PPP_FILTER
dep_tristate '  PPP support for async serial ports' CONFIG_PPP_ASYNC $CONFIG_PPP
dep_tristate '  PPP support for sync tty ports' CONFIG_PPP_SYNC_TTY $CONFIG_PPP
dep_tristate '  PPP Deflate compression' CONFIG_PPP_DEFLATE $CONFIG_PPP
diff -urN linux/drivers/net/ppp_async.c pmac/drivers/net/ppp_async.c
--- linux/drivers/net/ppp_async.c   Thu Feb 22 14:25:14 2001
+++ pmac/drivers/net/ppp_async.cThu Mar 29 13:47:47 2001
@@ -244,11 +244,6 @@
err = 0;
break;
 
-   case PPPIOCATTACH:
-   case PPPIOCDETACH:
-   err = ppp_channel_ioctl(ap-chan, cmd, arg);
-   break;
-
default:
err = -ENOIOCTLCMD;
}
diff -urN linux/drivers/net/ppp_generic.c pmac/drivers/net/ppp_generic.c
--- linux/drivers/net/ppp_generic.c Fri Apr 20 17:04:35 2001
+++ pmac/drivers/net/ppp_generic.c  Fri Apr 20 17:31:04 2001
@@ -19,7 +19,7 @@
  * PPP driver, written by Michael Callahan and Al Longyear, and
  * subsequently hacked by Paul Mackerras.
  *
- * ==FILEVERSION 2417==
+ * ==FILEVERSION 2902==
  */
 
 #include linux/config.h
@@ -32,6 +32,7 @@
 #include linux/netdevice.h
 #include linux/poll.h
 #include linux/ppp_defs.h
+#include linux/filter.h
 #include linux/if_ppp.h
 #include linux/ppp_channel.h
 #include linux/ppp-comp.h
@@ -121,6 +122,10 @@
struct sk_buff_head mrq;/* MP: receive reconstruction queue */
 #endif /* CONFIG_PPP_MULTILINK */
struct net_device_stats stats;  /* statistics */
+#ifdef CONFIG_PPP_FILTER
+   struct sock_fprog pass_filter;  /* filter for packets to pass */
+   struct sock_fprog active_filter;/* filter for pkts to reset idle */
+#endif /* CONFIG_PPP_FILTER */
 };
 
 /*
@@ -621,6 +626,43 @@
err = 0;
break;
 
+#ifdef CONFIG_PPP_FILTER
+   case PPPIOCSPASS:
+   case PPPIOCSACTIVE:
+   {
+   struct sock_fprog uprog, *filtp;
+   struct sock_filter *code = NULL;
+   int len;
+
+   if (copy_from_user(uprog, (void *) arg, sizeof(uprog)))
+   break;
+   if (uprog.len  0) {
+   err = -ENOMEM;
+   len = uprog.len * sizeof(struct sock_filter);
+   code = kmalloc(len, GFP_KERNEL);
+   if (code == 0)
+   break;
+   

Re: Children first in fork

2001-04-20 Thread Wichert Akkerman

In article 9bn90l$anp$[EMAIL PROTECTED],
Linus Torvalds [EMAIL PROTECTED] wrote:
Not that I've tested it myself.

I did a few months ago, it didn't work.

Wichert.
-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: I can eject a mounted CD

2001-04-20 Thread Giuliano Pochini


 [Giu@Jay Giu]$ eject /mnt/cdmac/ umount: /dev/sr0 is not in the fstab (and
 you are not root) eject: unmount of `/dev/sr0' failed

Eject(1) is suid.

 I have similar problem with my swim3 floppy drive. Digging deeply I found that
 when I make do folowing steps then disk is lost and I have to reboot to get it
 back:

I can't try this case because I haven't a floppy. When I ehect the cd I can
recover it by unmounting it. But the CD is read-only. I can try with a MO, but
the actual problem is that eject is buggy. It's not a kernel bug. I'll fix it...


Bye.
Giuliano Pochini -)|(- Shiny Network {AS6665} -)|(-

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Linux 2.4.3 Compile Errors - Power Mac

2001-04-20 Thread David Woodhouse



[EMAIL PROTECTED] said:
   However, I don't think that wishing the world would avoid these
 dominant (and very useful) formats is a realistic expectation.  It is
 certainly not "common sense" to assume as such.

Of course it's not a realistic expectation. There are times when it's a pain
to have to be safe - people will always break the rules when they're in a
hurry and the document to be sent is already in an unsafe format. But taking
plain text with absolutely no formatting, in fact text which is
_degenerated_ by word wrapping c, and gratuitously putting it in a Word
document is just _so_ unnecessary that I assumed it had to be a troll.


 fork.c: In function Œcopy_mm¹:

Given what this output's been through - I'll assume it's corrupted in 
transit, shall I? 

The kind of error you're seeing is often caused by a mismatch between 
compiler and kernel. As Alan suggests, you should make sure you're using a 
PPC-specific tree because it's not up to date in the stock 2.4.3. And make 
sure you're using the recommended versions of compiler and binutils. Other 
than that, I'm afraid I don't know.

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

2001-04-20 Thread Jeff Garzik

Luca Berra wrote:
 we have some serous problems here.
[...]
 a better lvm (still buggy according to many kernel hackers, but better still),
 which does not get into the kernel for communication reasons. (Alan can you help?
 there is a lot of stuff that goes in -ac before going to mainstream)

I do not think this is a communication problem at all, but a clear lack
of understanding (perhaps willful) on the part of the "LVM maintainers"
about how to get things into the kernel.

linux/Documentation/SubmittingPatches exist to bonk people on the head
if they are screwing up, and it sounds like such is occurring now.

Quite simply,

1) Split up your patches.  How many times does it have to be said? 
Think ONE CHANGE, ONE PATCH.  Big patches full of tons of disparate
changes are impossible to review.

2) (parroting Linus)  Open source is about lack of control, not hoarding
code and lording over it.  That's why Linus will take a patch from Jens
or another knowledgeable person who says "this LVM code is broken,
-here- is a fix." -- regardless of who the "official" maintainer of the
code is listed as...

[Luca, this is not directed at you, I just used this message as an
opportunity to spout :)]

-- 
Jeff Garzik   | "The universe is like a safe to which there is a
Building 1024 |  combination -- but the combination is locked up
MandrakeSoft  |  in the safe."-- Peter DeVries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: epic100 error

2001-04-20 Thread Stefan Jaschke

On Wednesday 18 April 2001 20:40, Francois Romieu wrote:
 Hello,

 Oliver Teuber [EMAIL PROTECTED] écrit :
 [...]

  00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev
  06) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
  00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Apollo PRO] (rev
  07) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo]
  (rev 06) 00:07.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050
  00:09.0 Ethernet controller: Standard Microsystems Corp [SMC] 83C170QF
  (rev 06) 00:0b.0 Multimedia audio controller: Ensoniq ES1371
  [AudioPCI-97] (rev 06) 01:00.0 VGA compatible controller: nVidia
  Corporation Riva TnT2 [NV5] (rev 11)

 Could you:
 - send me the motherboard version+bios revision ?
 - see if there exists an updated bios ?

I don't believe the motherboard or the BIOS have anything to do with, simply because 
I have been successfully using the SMC Etherpower with three different Motherboards 
- ASUS TX97-XE, MSI K7 Pro, Gigagbyte GA-71XE4 -
and (at least) three different kernels: 2.0.x, 2.2.18, 2.4.0. 
Something between 2.4.0 and 2.4.3 breaks the epic100 driver. That's it.

Cheers,
Stefan
-- 
Stefan R. Jaschke [EMAIL PROTECTED]
http://www.jaschke-net.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [andrea@suse.de: Re: generic rwsem [Re: Alpha process table hang]]

2001-04-20 Thread David Howells

Linus Torvalds [EMAIL PROTECTED] wrote:
 I think Andrea is right. Although this file seems to be entirely
 old-fashioned and should never be used, right?

I presume you're talking about "include/asm-i386/rwsem-spin.h"... If so,
Andrea is right, there is a bug in it (repeated a number of times), though why
the tests succeeded, I'm not sure.

The file should only be used for the 80386 and maybe early 80486's where
CMPXCHG doesn't work properly, everything above that can use the XADD
implementation.

 Also, I _really_ don't see why the code is inlined at all (in the real
 linux/rwsem-spinlock.h. It shouldn't be. It should be a real function
 call, and all be done inside lib/rwsem.c inside a
 
   #ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
 
 or whatever.

Andrea seems to have changed his mind on the non-inlining in the generic case.

But if you want it totally non-inline, then that can be done. However, whilst
developing it, I did notice that that slowed things down, hence why I wanted
it kept in line.

I have some ideas on how to improve efficiency in that one anyway, based on
some a comment from Alan Cox.

 Please either set me straight, or send me a patch to remove
 asm-i386/rwsem-spin.h and fix up linux/rwsem-spinlock.h. Ok?

I think there are two seperate issues here:

  (1) asm-i386/rwsem-spin.h is wrong, and can probably be replaced with the
  generic spinlock implementation without inconveniencing people much.
  (though someone has commented that they'd want this to be inline as
   cycles are precious on the slow 80386).

  (2) "fix up linux/rwsem-spinlock.h": do you want the whole generic spinlock
  implementation made non-inline then?

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread David Woodhouse


[EMAIL PROTECTED] said:
  Doesn't this seem a little like the problems occurring with lvm right
 now? A separate tree maintained with the maintainers not wanting
 others submitting patches that conflict with their particular tree?
 It seems that any project should be able to submit any patch against
 The One True Tree: Linus' tree. 

Of course they can. Linus does apply them too. People are asking nicely 
that ESR not do so in this case, because merges are being planned. 

The contents of drivers/mtd/ are in the same situation. For some reason, I
felt it inappropriate to give every patch at every stage of development to
Linus for inclusion in the 2.4.0-test and 2.4.[123] kernels. Now I'm vaguely
happy with it all and it's stable, I'm working on cleaning up some of the 
cosmetics and breaking it up into digestible patches.

Doing primary development in CVS seems to work OK for me, and allows me to 
continue development without destabilising the One True Tree. During such 
times, it's useful to have a branch for the code which is in the One True 
Tree, so urgent fixes can be merged, and the diff against the One True Tree 
after each release has something to diff against to catch patches where 
people didn't even bother to Cc the maintainer.

I believe people were _told_ to hold off until 2.4.5-ish, or when the tree
became stable. Violent imagery was used to reinforce this instruction.
That being the case, how about holding the config changes back until after 
everyone else who's been waiting has merged their pending changes?

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



patch: cdrom_init not called correctly (was Re: ac10 ide-cd oopses on boot)

2001-04-20 Thread Jens Axboe

On Fri, Apr 20 2001, Stefan Jaschke wrote:
 On Friday 20 April 2001 00:49, J . A . Magallon wrote:
  Hi,
 
  Just built 2.4.3-ac10 and got an oops when booting. It tries to detect
  the CD and gives the oops.
  EIP; c01bfc7c cdrom_get_entry+1c/50   =
 
 This appears to be a known problem. Jens Axboe sent a patch in a different
 thread ("SD-W2002 DVD-RAM") that fixes this. I am including it
 here for your convenience. (The patch is against 2.4.4-pre4 + Jens' 
 latest fixes.) 

Indeed, and it was the missing init call as suspected. The problem is
that cdrom is consequently linked after low level drivers -- this is
really the stuff that should be fixed, but instead of rewriting all of
that this quick hack should suffice.

-- 
Jens Axboe



--- drivers/cdrom/cdrom.c~  Fri Apr 20 10:43:31 2001
+++ drivers/cdrom/cdrom.c   Fri Apr 20 10:44:21 2001
@@ -381,7 +381,7 @@
  * change it here without gcc complaining at every line.
  */
 #define ENSURE(call, bits) if (cdo-call == NULL) *change_capability = ~(bits)
-
+static int cdrom_init(void);
 int register_cdrom(struct cdrom_device_info *cdi)
 {
static char banner_printed;
@@ -397,11 +397,9 @@
if (cdo-open == NULL || cdo-release == NULL)
return -2;
if ( !banner_printed ) {
-   printk(KERN_INFO "Uniform CD-ROM driver " REVISION "\n");
banner_printed = 1;
-#ifdef CONFIG_SYSCTL
-   cdrom_sysctl_register();
-#endif /* CONFIG_SYSCTL */ 
+   printk(KERN_INFO "Uniform CD-ROM driver " REVISION "\n");
+   cdrom_init();
}
ENSURE(drive_status, CDC_DRIVE_STATUS );
ENSURE(media_changed, CDC_MEDIA_CHANGED);
@@ -477,7 +475,6 @@
 {
struct cdrom_device_info *cdi, *prev;
int major = MAJOR(unreg-dev);
-   int bit_nr, cd_index;
 
cdinfo(CD_OPEN, "entering unregister_cdrom\n"); 
 
@@ -2706,7 +2703,7 @@
 
 #endif /* CONFIG_SYSCTL */
 
-static int __init cdrom_init(void)
+static int cdrom_init(void)
 {
int n_entries = CDROM_MAX_CDROMS / (sizeof(unsigned long) * 8);
 
@@ -2729,5 +2726,4 @@
devfs_unregister(devfs_handle);
 }
 
-module_init(cdrom_init);
 module_exit(cdrom_exit);



Re: [linux-lvm] 2.4.3-ac{6,7} LVM hang

2001-04-20 Thread Jens Axboe

On Thu, Apr 19 2001, Rik van Riel wrote:
 On 19 Apr 2001, Ulrich Drepper wrote:
  Jens Axboe [EMAIL PROTECTED] writes:
  
   Does attached patch fix it?
  
  Yes.
 
 Jens, I guess we should submit these patches to Alan and Linus
 now. This way we'll get a working LVM again.

Already done

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [RFC] FW: proposal for systems that do not require security

2001-04-20 Thread Jeremy Fitzhardinge

On Tue, Apr 10, 2001 at 02:35:52PM +0200, Heusden, Folkert van wrote:
 So, I was wondering: isn't it a nice idea to have a switch in the
 configuration menu to disable entropy-gathering in the interrupt-routines,
 have some simplistic routine (like x'=(x * m + a) % p) which returns a non-
 cryptographic value, and something similar symplistic for the network-
 traffic routines?

No, that's a very bad idea.  If you think it's a problem, just remove
the random driver altogether.  It's much better for something to get
ENXIO rather than thinking it's getting real randomness.

You can still get TCP sequence numbers by sampling the cycle counter or
something.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Fix for Donald Becker's DP83815 network driver (v1.07)

2001-04-20 Thread Roberto Nibali

 The UP-APIC wouldn't help much since there really aren't other processors
 available to share the load.

Hmm, but doesn't the code in 2.4.x improve the hard IRQ signal delivery
even for UP systems with a local APIC table? I have an APIC aware board
but I have only got 1 CPU on it and I currently need to run 2.2 kernel.
But if you tell me that there is not much help, I'm ok with that, as 
long as it wouldn't be better with APIC support :)
 
 On the other hand, this is not as bad as it looks. In fact, it will
 function rather well and with relatively little overhead if all configured
 interfaces are seeing traffic on a regular basis. The IRQ dispatcher will
 simply call all registered interrupt routines, and most of them will end
 up doing something useful.

Aha, thanks for the information. Indeed you're right because I'm running
boxes with such a configuration which have already 100+ days uptime under
heavy network load.

 Well.. Space.c is a dinozaur. However, this is the 2.2 series and no more
 surgery will happen on this kernel, at least normally.

So, what is your suggestion: Does this limitation do any harm or can I
live with that and still run 16 eth devices and safely disregard the
"early initialization ..." ?
 
 Have you tried loading the drivers as modules? You might have more luck
 with that approach. Space.c was designed at a time when having 4 NIC's in
 a PC was "pushing the limits"...

Yes, I've tried it but the problem is, that I've hundreds of nodes and about
a dozen of different node setups, some with 1 NIC, some with 1 NIC and 1 quad
board, up to some with 3 NICs and 3 quadboards. I've developed an own distro
which has one kernel. Since I can't make the correct modules get loaded without
mucking around with the /etc/modules.conf, I need to compile-in the drivers. 
I'd be happy if the ethif_probe() could call the request_module() and load the
correct module and initialize the ethX. As of now I would need to adjust the
/etc/modules.conf according to the amount of quadboards I have put into my
node. Or did I miss the concept of /etc/modules.conf?
 
 Because, again, this is legacy code. It works, it does the job, that's it.
 All this crap is gone in 2.4.

I'll be porting my distribution to 2.4.x soon I think :)
 
 Like I said, try the modules approach. If that doesn't work, I'll take a
 closer look (and maybe borrow a few quads from work so I can actually test
 the code...)

Your driver works now and for me now need to mark it experimental. It also
works statically built into the kernel up to 4 quadboards. I hacked Space.c
and enhanced the ``static struct device ethX_dev = { };'' stuff. 

Roberto Nibali, ratz

-- 
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [repost] Announce: Linux-OpenLVM mailing list

2001-04-20 Thread Constantine Gavrilov

  Hmm...i guess there is a communication issue here.  It sounds like the
   message that our ML server was sending was misleading.  We were not
  rejecting mail because of content.  The ML server was rejecting it 
because
  the address was not subscribed.  Our idea was that we don't want spam.
  If it's completely unmoderated, then we will get a *lot* of spam.

I do not think there is a miscommunication here. First, someone gets an 
e-mail saying that your message "waits for moderator's approval". Then 
you get a message saying that your "message was rejected by the 
moderator because you are not subscribed to the list".

Mind it, those were bug reports, not spam. I took your beta code, tested 
it, saw real bugs and problems and wrote bug reports  BECAUSE YOU 
INCOURAGE PEOPLE TO DO SO AND GIVE THOSE EMAILS IN THE DOCUMENTATION!!!

There is no place in the source tree docs that say the list is 
moderated.  It it had said so, I would have not wasted my time. I felt 
really pissed off for waisting my time. BTW, other e-mails given in the 
documentation just bounce. If you do not want people sending bug 
reports, update your documentation. It is not polite to make people 
waste their time!

-- 

Constantine Gavrilov
Linux Leader
Optibase Ltd
7 Shenkar St, Herzliya 46120, Israel
Phone: (972-9)-970-9140
Fax:   (972-9)-958-6099


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: light weight user level semaphores

2001-04-20 Thread Olaf Titz

 Ehh.. I will bet you $10 USD that if libc allocates the next file
 descriptor on the first "malloc()" in user space (in order to use the
 semaphores for mm protection), programs _will_ break.

Of course, but this is a result from sloppy coding. In general, open()
can just return anything and about the only case where you can even
think of ignoring its result is this:
 close(0); close(1); close(2);
 open("/dev/null", O_RDWR); dup(0); dup(0);
(which is even not clean for other reasons).

I can't imagine depending on the "fact" that the first fd I open is 3,
the next is 4, etc. And what if the routine in question is not
malloc() but e.g. getpwuid()? Both are just arbitrary library
functions, and one of them clearly does open file descriptors,
depending on their implementation.

What would the reason[1] be for wanting contiguous fd space anyway?

Olaf

[1] apart from not having understood how poll() works of course.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: bizarre TCP behavior

2001-04-20 Thread Stefan Traby

On Sat, Apr 14, 2001 at 03:27:53PM +0100, Alan Cox wrote:
  For example the Zyxel 681 SDSL-Router breaks ECN by
  stripping 0x80 (ECN Cwnd Reduced) but not 0x40 (ECN Echo)
  (TOS bits) on all SYN packets (!).
  
  I complained because of this two times more than a month ago
  but they do not even respond.
 
 If the router claims to be RFC compliant then you may want to investigate
 trading standards bodies. In the UK at least things like the advertising 
 standards agency get upset by people who claim standards compliance, are shown
 not to be compliant and are not fixing things..

FYI: I just tested a beta firmare that does not break ECN.
(ZyXEL firmware v2.50(T.05)b6 | 03/28/2001)

I hope that Zyxel will make a release soon, the last official firmare
does not support it. (Ahm, people that are willing to upgrade should
do it on _both_ sides)

-- 

  ciao - 
Stefan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Linux 2.4.3-ac10

2001-04-20 Thread Geert Uytterhoeven

On Thu, 19 Apr 2001, Alan Cox wrote:
 2.4.3-ac10
 o Merge Linus 2.4.4pre4
 o Reorder frame buffer probes (Geert Uytterhoeven)

These got somewhat mixed. Remove the duplicates:

--- linux-2.4.3-ac10/drivers/video/fbmem.c.orig Fri Apr 20 09:58:50 2001
+++ linux-2.4.3-ac10/drivers/video/fbmem.c  Fri Apr 20 11:33:28 2001
@@ -205,9 +205,6 @@
 #if defined(CONFIG_FB_SIS)  (defined(CONFIG_FB_SIS_300) || 
defined(CONFIG_FB_SIS_315))
{ "sisfb", sisfb_init, sisfb_setup },
 #endif
-#ifdef CONFIG_FB_E1355
-   { "e1355fb", e1355fb_init, e1355fb_setup },
-#endif
 
/*
 * Generic drivers that are used as fallbacks
@@ -275,9 +272,6 @@
 #endif
 #ifdef CONFIG_FB_E1355
{ "e1355fb", e1355fb_init, e1355fb_setup },
-#endif
-#ifdef CONFIG_FB_DC
-   { "dcfb", dcfb_init, NULL },
 #endif
 #ifdef CONFIG_FB_DC
{ "dcfb", dcfb_init, NULL },

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Fix for Donald Becker's DP83815 network driver (v1.07)

2001-04-20 Thread Ion Badulescu

On Fri, 20 Apr 2001, Roberto Nibali wrote:

 Hmm, but doesn't the code in 2.4.x improve the hard IRQ signal delivery
 even for UP systems with a local APIC table? I have an APIC aware board
 but I have only got 1 CPU on it and I currently need to run 2.2 kernel.
 But if you tell me that there is not much help, I'm ok with that, as 
 long as it wouldn't be better with APIC support :)

I think the UP-APIC support was added primarily to support the NMI oopser 
on UP systems. I might be wrong, though.

  Well.. Space.c is a dinozaur. However, this is the 2.2 series and no more
  surgery will happen on this kernel, at least normally.
 
 So, what is your suggestion: Does this limitation do any harm or can I
 live with that and still run 16 eth devices and safely disregard the
 "early initialization ..." ?

You can safely disregard the "early initialization deferred" messages. 
They are essentially harmless.

As for the 16 eth ports limit, if you want to increase it, simply edit 
drivers/net/net_init.c and change the value of MAX_ETH_CARDS. This limit 
appears to also affect modules, so my earlier suggestion of using modules 
wouldn't have helped.

  Because, again, this is legacy code. It works, it does the job, that's it.
  All this crap is gone in 2.4.
 
 I'll be porting my distribution to 2.4.x soon I think :)

If the only thing you need from your boxes is networking-related, than 
it's probably ok. Otherwise I'd wait a bit longer before putting 2.4 on 
production servers...

 Your driver works now and for me now need to mark it experimental. 

Yeah, I guess I'll submit a patch to remove the experimental bit, after 
the current code changes are accepted..

 It also works statically built into the kernel up to 4 quadboards. I
 hacked Space.c and enhanced the ``static struct device ethX_dev = { };''
 stuff.

You shouldn't need to do that, it's just wasted memory. The ethX_dev was
used mostly to avoid probing for ISA cards, which is completely irrelevant
when using PCI cards. As for the 4 quadboards limit, see above -- all you
need to change is MAX_ETH_CARDS.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: A little problem.

2001-04-20 Thread Guennadi Liakhovetski

It is way OT here, but since Alan replied to this, I'll continue this
thread a bit: The interesting bit here, that I don't understand, is - how
in RedHat-7.0, that was released last year, libc is compiled against
2.4.0?... Did they include headers from one of pre / test versions?

Thanks
Guennadi

On Thu, 19 Apr 2001, Alan Cox wrote:

  and upgrade the Linux Kerenl from their original 2.2.16 to 2.2.18. But when
  I compile some modules, it said my kernel is 2.4.0. I check the
  /usr/include/linux/version.h as follows, found that it shows I am using
  Kernel 2.4.0.
 
 No. It shows the headers your C compiler libraries are built againt. Which is
 2.4 - and which is correct. It has nothing to do with the kernel you are 
 running
 
 -
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 

___

Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Fix for Donald Becker's DP83815 network driver (v1.07)

2001-04-20 Thread Ion Badulescu

On Fri, 20 Apr 2001, Jeff Garzik wrote:

  Check again. drivers/net builds a .a, not a .o. Trust me, I've tried.
 
 Sure, but if you are patching anyway, it much better to fix that than
 hack space.c :)

Well, I remember asking Alan if he'd prefer it done that way, and not 
getting a reply back. So I didn't press further.

The change to support __init/__exit in drivers/net is a no-brainer, and I 
did test it at the time -- it worked as expected. But it's really up to 
Alan to decide, I couldn't care less to be quite honest.

In a way I think I understand why he's reluctant: it's very easy to end up
changing the initialization order by mistake and messing up people's 
network setups.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Fix for Donald Becker's DP83815 network driver (v1.07)

2001-04-20 Thread Jeff Garzik

Ion Badulescu wrote:
 On Fri, 20 Apr 2001, Jeff Garzik wrote:
   Check again. drivers/net builds a .a, not a .o. Trust me, I've tried.

  Sure, but if you are patching anyway, it much better to fix that than
  hack space.c :)
 
 Well, I remember asking Alan if he'd prefer it done that way, and not
 getting a reply back. So I didn't press further.
 
 The change to support __init/__exit in drivers/net is a no-brainer, and I
 did test it at the time -- it worked as expected. But it's really up to
 Alan to decide, I couldn't care less to be quite honest.
 
 In a way I think I understand why he's reluctant: it's very easy to end up
 changing the initialization order by mistake and messing up people's
 network setups.

Sorry, I was talking about a local patch not a global patch.  If a user
must patch their 2.2 kernel to get the starfire driver working anyway,
then adding a change to do s/.a/.o/ on Makefiles would be simple.

That said, a 2.2.20 patch to s/.a/.o/ should not break anything at all. 
All old drivers work as before through the static call chain.  All newer
drivers using module_init/exit simply wind up being initialized after
all static initialization has occurred.  With some subsystems this does
create a chicken-and-egg situation, but not for drivers/net...

-- 
Jeff Garzik   | "The universe is like a safe to which there is a
Building 1024 |  combination -- but the combination is locked up
MandrakeSoft  |  in the safe."-- Peter DeVries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: BP6: APIC, rtl8139 sound

2001-04-20 Thread Per-Henrik Persson

Argh, I just tried the kernels up to 2.4.4-pre4, not the pre5! Some sleep
and then I will try it!

/P-H

 
Per-Henrik Persson  0703-68 53 86
[EMAIL PROTECTED]  http://www.whatever.nu

"With digital it's all or nothing!"
"Just because something doesn't work, it doesn't mean it can't be used..."


On Fri, 20 Apr 2001, Jeff Garzik wrote:

 Per-Henrik Persson wrote:
  If i start to use the NIC, like som browsing on the internet i occassionly
  get:
  
  eth0: Too much work at interrupt, IntrStatus=0x0001.
 
 You need the 8139too driver update, from 2.4.4-pre5, 2.4.3-ac7, or
 http://sourceforge.net/projects/gkernel/
 
 -- 
 Jeff Garzik   | "The universe is like a safe to which there is a
 Building 1024 |  combination -- but the combination is locked up
 MandrakeSoft  |  in the safe."-- Peter DeVries
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Fix for Donald Becker's DP83815 network driver (v1.07)

2001-04-20 Thread Ion Badulescu

On Fri, 20 Apr 2001, Jeff Garzik wrote:

 Sorry, I was talking about a local patch not a global patch.  If a user
 must patch their 2.2 kernel to get the starfire driver working anyway,
 then adding a change to do s/.a/.o/ on Makefiles would be simple.

People don't need to patch *anything* to get the starfire driver working --
it's included in 2.2.19 and working rather well I might add. :-)

This was a special case, which btw had nothing to do with the starfire 
driver itself. The user needed to support more than 8 eth ports, which 
2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't 
allow without further changes.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: rwsem benchmarks [Re: generic rwsem [Re: Alpha process table hang]]

2001-04-20 Thread David Howells


 About the benchmark you wrote it looks good measure to me, thanks.

As with all benchmarks, take with one pinch of salt and two of Mindcraft:-)

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Fix for Donald Becker's DP83815 network driver (v1.07)

2001-04-20 Thread Roberto Nibali

Hi Ion,

 I think the UP-APIC support was added primarily to support the NMI oopser
 on UP systems. I might be wrong, though.

You're right, at least from the perspective of this patch:
http://www.csd.uu.se/~mikpe/linux/upapic/upapic-2.4.1
 
 You can safely disregard the "early initialization deferred" messages.
 They are essentially harmless.

Thanks for the info. I can sleep now :)
 
 As for the 16 eth ports limit, if you want to increase it, simply edit
 drivers/net/net_init.c and change the value of MAX_ETH_CARDS. This limit
 appears to also affect modules, so my earlier suggestion of using modules
 wouldn't have helped.

Thanks a lot. And sorry I don't know the kernel sources and documentations
good enough yet.
 
 If the only thing you need from your boxes is networking-related, than
 it's probably ok. Otherwise I'd wait a bit longer before putting 2.4 on
 production servers...

It is only network related (packetfiltering and load balancing with QoS) 
and I like the improved mm. I've been testing 2.4 since its early days
and f.e. on the Intel L440GX+ boards it runs like hell, also with SMP.
Only the CPU numbering is incorrect if the kernel is SMP and you only
put in one processor. But I read somewhere that also this feature is 
normal since it seems to be impossible to give the CPUs the correct
numbers because there is no defined order of initialization.
 
 Yeah, I guess I'll submit a patch to remove the experimental bit, after
 the current code changes are accepted..

Good. Yes, I saw the patches. I might try it out back here with a 2.4.x
kernel and 4 quadboards.
 
 You shouldn't need to do that, it's just wasted memory. The ethX_dev was
 used mostly to avoid probing for ISA cards, which is completely irrelevant
 when using PCI cards. As for the 4 quadboards limit, see above -- all you
 need to change is MAX_ETH_CARDS.

Will certainly do that. And thank you again for this information.
 
Best regards,
Roberto Nibali, ratz

-- 
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Children first in fork

2001-04-20 Thread Éric Brunet

In ens.mailing-lists.linux-kernel, you wrote:
You're probably even better off just intercepting the fork, turning it
into a clone, and setting the CLONE_PTRACE option. Which (together with
tracing the parent, which you will obviously be doing already in order
to do all this in the first place) will nicely cause the child to get an
automatic SIGSTOP _and_ be already traced.

Well, I tried that, and it doesn't work. The problem is that the child
starts ptraced, but it is its parent that will receive a signal for each
syscall, and not the program that ptraces its parent. Of course, the
parent will probably be a little bit confused by that (as it doesn't expect
to receive those signals) and the monitoring programm won't see anything.

Maybe it would work if the function copy_flags in fork.c was modified
into:
-
--- fork-old.c  Fri Apr 20 12:01:09 2001
+++ fork.c  Fri Apr 20 12:05:57 2001
@@ -552,8 +552,14 @@
 
new_flags = ~(PF_SUPERPRIV | PF_USEDFPU | PF_VFORK);
new_flags |= PF_FORKNOEXEC;
-   if (!(clone_flags  CLONE_PTRACE))
+   if (!(clone_flags  CLONE_PTRACE)) {
new_flags = ~(PF_PTRACED|PF_TRACESYS);
+   if (p-p_pptr-flags = PF_PTRACED) {
+   REMOVE_LINKS(p);
+   p-p_pptr = p-p_pptr-p_pptr;
+   SET_LINKS(child);
+   }
+   }
if (clone_flags  CLONE_VFORK)
new_flags |= PF_VFORK;
p-flags = new_flags;
-
(sorry, it is a 2.2.19pre8 kernel, and I don't know what have changed
since in that file)
Ok, I haven't tried it (can't reboot a machine now), and I don't know
what I am talking about, but the idea is simply ``if CLONE_PTRACE is set,
and the parent is ptraced, then the child's effective parent should be
its grandfather.''

Was it the way it was intended to work ? As it is now, I don't see any
use of the CLONE_PTRACE flag.

ric Brunet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



[RFC and 1/2 OT] Re: ANNOUNCE New Open Source X server

2001-04-20 Thread mirabilos

- Original Message -
From: "James Simmons" [EMAIL PROTECTED]
To: "Scott Prader" [EMAIL PROTECTED]
Cc: "Linux Kernel Mailing List" [EMAIL PROTECTED]
Sent: Thursday, April 19, 2001 5:16 PM
Subject: Re: ANNOUNCE New Open Source X server



 Thank you. It is true all I want to do is help the community. I feel
as
 alot of people do XFree86 can not meet the needs of the community. It
is
 very sad that people feel that no amount of people in the open source
 community can make code of the same or better quality as XFree86 in a
 shorter period of time. I don't feel this way. Now I'm off to work on
code
 and documentation for the project. Thank you.

My idea were: why not integrate kind of Nano-X (yes I know what that is)
into the kernel, just the X server, configured by make menuconfig (or
which you like more), and just use XF86 or something different (or even
X clients running under a different machine on the net) on it.

It should then implement enough of, if not the full, X11R6 API, and have
either direct access to the gfx board or at least to the fb (might this
be speeded up?).

It doesn't need to be fullstly (?) integrated to the kernel, it may also
be a "server" (as in microkernel systems), loaded as module but on CPL3.
So a crash doesn't hang the full system: if it crashes, we have a SysRq
which kicks out the module and does either a videomode-switch to a sane
80x25 (BIOS 03), VGA (BIOS 12) or - if framebuffer-based - nothing
because
the X server and the fb are separated.
We might as well support EGA, HGC or CGA(??) cards for it; switching to
a sane mode isn't that difficult (as discussed earlier, and for HGC I
have some NASM sources), and IIRC there is a HGC framebuffer somewhere.

-mirabilos
--
)))  LICENSE FOR ABOVE MESSAGE BODY:  (((
YOU _MUST NOT_ READ  ABOVE MESSAGE BODY  IF YOU DO NOT AGREE TO THESE
TERMS.  BY READING ABOVE MESSAGE BODY  YOU _AUTOMATICALLY_ _DO AGREE_
TO THE FOLLOWING TERMS:
This mail/work is protected  by copyright law.  It _MUST NOT_ be used
otherwise than specified by the terms and conditions at:
  http://members.tripod.de/mirabilos/license.mip
The mail is, if not _explicitly_ specified differently, ONLY licensed
by these terms. THIS _CANNOT_ BE OVERRIDDEN BY ANY "TERMS OF SERVICE"
OF ANY S.PROVIDER THE MAIL GOES THROUGH, EVEN _NOT_ IF I SIGNED THEM!
--
(Sorry for the bandwidth, but some ToS force me to.)
EA F0 FF 00 F0 #$@%CARRIER LOST

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



[PATCH] update ext2 documentation

2001-04-20 Thread Andreas Dilger

The included patch updates Documentation/filesystems/ext2 to reflect
current information about ext2.  It also adds some more information
that people have told me is hard to find in other places (such as a
description of the superblock compatibility flags, file and filesystem
size limits).

I've updated the parts of the document which refer to patches and
extensions to ext2 to reflect what is currently out there (e.g.
Daniel's hashed/indexed directory code, rather than the btree code,
and Andreas Gruenbacher's EA/ACL code instead of the pure ACL code).

I've checked (and updated) the URLs at the end of the document.

Cheers, Andreas
==
--- linux-2.4.4p1.orig/Documentation/filesystems/ext2.txt   Sun Oct  1 21:21:20 
2000
+++ linux-2.4.4p1-aed/Documentation/filesystems/ext2.txtFri Apr 20 04:06:45 
+2001
@@ -4,7 +4,7 @@
 
 ext2 was originally released in January 1993.  Written by R\'emy Card,
 Theodore Ts'o and Stephen Tweedie, it was a major rewrite of the
-Extended Filesystem.  It is currently (February 1999) the predominant
+Extended Filesystem.  It is currently still (April 2001) the predominant
 filesystem in use by Linux.  There are also implementations available
 for NetBSD, FreeBSD, the GNU HURD, Windows 95/98/NT, OS/2 and RISC OS.
 
@@ -17,11 +17,11 @@
 bsddf  (*) Makes `df' act like BSD.
 minixdfMakes `df' act like Minix.
 
-check=none, nocheckPerform no checks upon the filesystem.
-check=normal   (*) Perform normal checks on the filesystem.
-check=strict   Perform extra checks on the filesystem.
+check=none, nocheck(*) Don't do extra checking of bitmaps on mount
+   (check=normal and check=strict options removed)
 
-debug  For developers only.
+debug  Extra debugging information is sent to the
+   kernel syslog.  Useful for developers.
 
 errors=continue(*) Keep going on a filesystem error.
 errors=remount-ro  Remount the filesystem read-only on an error.
@@ -30,8 +30,8 @@
 grpid, bsdgroups   Give objects the same group ID as their parent.
 nogrpid, sysvgroups(*) New objects have the group ID of their creator.
 
-resuid=n   The user which may use the reserved blocks.
-resgid=n   The group which may use the reserved blocks. 
+resuid=n   The user ID which may use the reserved blocks.
+resgid=n   The group ID which may use the reserved blocks. 
 
 sb=n   Use alternate superblock at this location.
 
@@ -53,46 +53,53 @@
 --
 
 The space in the device or file is split up into blocks.  These are
-a fixed size, of 1024, 2048 or 4096 bytes, which is decided when the
-filesystem is created.  Smaller blocks mean less wasted space per file,
-but require slightly more accounting overhead.
+a fixed size, of 1024, 2048 or 4096 bytes (8192 bytes on Alpha systems),
+which is decided when the filesystem is created.  Smaller blocks mean
+less wasted space per file, but require slightly more accounting overhead,
+and also impose other limits on the size of files and the filesystem.
+
+Block Groups
+
 
 Blocks are clustered into block groups in order to reduce fragmentation
-and minimise the amount of head seeking when reading a large amount of
-consecutive data.  Each block group has a descriptor and the array of
-descriptors is stored immediately after the superblock.  Two blocks at
-the start of each group are reserved for the block usage bitmap and
-the inode usage bitmap which show which blocks and inodes are used.
-Since each bitmap fits in a block, this means that the maximum size of
-a block group is 8 times the size of a block.
-
-The first (non-reserved) blocks in the block group are designated as
-the inode table for the block and the remainder are the data blocks.
-The block allocation algorithm attempts to allocate data blocks in the
-same block group as the inode which contains them.
+and minimise the amount of head seeking when reading a large amount
+of consecutive data.  Information about each block group is kept in a
+descriptor table stored in the block(s) immediately after the superblock.
+Two blocks near the start of each group are reserved for the block usage
+bitmap and the inode usage bitmap which show which blocks and inodes
+are in use.  Since each bitmap is limited to a single block, this means
+that the maximum size of a block group is 8 times the size of a block.
+
+The block(s) following the bitmaps in each block group are designated
+as the inode table for that block group and the remainder are the data
+blocks.  The block allocation algorithm attempts to allocate data blocks
+in the same block group as the inode which contains them.
 
 

Re: epic100 error

2001-04-20 Thread Francois Romieu

Stefan Jaschke [EMAIL PROTECTED] ecrit :
[...]
 I don't believe the motherboard or the BIOS have anything to do with, simply 

It may give a clue because the machine I wrote this mail from is a 
2.4.3 + 2*EtherPower II it looks rather fine (old asus motherbord, BX,
backuped peaceful prod server):
I tried 2.4.3 on some bp6+epic100 (2.4.0/1/2/3 + misc ac). No problems either.

Around the 10 of february, Arnd Bergmandd [EMAIL PROTECTED] had
problems with the epic100. These appeared between two revisions of the
driver that differ only in the use of DMA mapping I made at the moment.
digression
Fwiw, it was essentially a matter of coding-style as on x86 the DMA mapping
actually called the former virt_to_phys and pci_dma_sync was rather empty.
It made no design change. It may be possible I assumed some data were in
memory as they are still in some cpu registers. I'll re-re-check that.
/digression

Summary:
Arnd Bergmann:
orig epic100"DMA mapped epic100 (any version)"
(=2.4.0-ac9)
VT8363  ok  fscked but ok after bios update

Daniel Nofftz:
2.4.2   2.4.3
VT82C595ok  fscked. (no mention of bios experience)

Oliver Teuber:
2.2.19  2.4.3-ac7
VT82C598ok  fscked

Romieu:
2.2.xx  2.4.[123]
82443BX ok  ok

Now it's complicated by the fact that between 2.4.2 and 2.4.3, you
have DMA mapping + others changes in epic100 (they make sense imho).

What happen's if you compile 2.4.2 epic100 driver in a 2.4.3 tree (I) ?

[...]
 Something between 2.4.0 and 2.4.3 breaks the epic100 driver. That's it.

So far it's hard to say where it comes from.
I would really appreciate if you could give a look at (I).
If it doesn't change anything and you have spare time, some feedback
from bios experience will be welcome too.

--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



starfire update for 2.4.4-pre5

2001-04-20 Thread Ion Badulescu

Hi Jeff,

Here is the same starfire.c version I sent earlier, this time diff'ed 
against 2.4.4-pre5. It's essentially the version from 2.2.19 plus your 
2.4.4-pre5 changes minus the 2.2 compatibility stuff.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
--
--- /mnt/3/linux-2.4/drivers/net/starfire.c Thu Apr 19 15:54:59 2001
+++ linux-2.4/drivers/net/starfire.cThu Apr 19 21:39:24 2001
@@ -20,7 +20,7 @@
---
 
Linux kernel-specific changes:
-   
+
LK1.1.1 (jgarzik):
- Use PCI driver interface
- Fix MOD_xxx races
@@ -31,9 +31,45 @@
 
LK1.1.3 (Andrew Morton)
- Timer cleanups
-   
+
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+   LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+   - Support hardware Rx/Tx checksumming
+   - Use the GFP firmware taken from Adaptec's Netware driver
+
+   LK1.2.2 (Ion Badulescu)
+   - Backported to 2.2.x
+
+   LK1.2.3 (Ion Badulescu)
+   - Fix the flaky mdio interface
+   - More compat clean-ups
+
+   LK1.2.4 (Ion Badulescu)
+   - More 2.2.x initialization fixes
+
+   LK1.2.5 (Ion Badulescu)
+   - Several fixes from Manfred Spraul
+
+   LK1.2.6 (Ion Badulescu)
+   - Fixed ifup/ifdown/ifup problem in 2.4.x
+
+   LK1.2.7 (Ion Badulescu)
+   - Removed unused code
+   - Made more functions static and __init
+
+   LK1.2.8 (Ion Badulescu)
+   - Quell bogus error messages, inform about the Tx threshold
+   - Removed #ifdef CONFIG_PCI, this driver is PCI only
+
+   LK1.2.9 (Ion Badulescu)
+   - Merged Jeff Garzik's changes from 2.4.4-pre5
+   - Added 2.2.x compatibility stuff required by the above changes
+
+TODO:
+   - implement tx_timeout() properly
+   - support ethtool
 */
 
 /* These identify the driver base version and may not be removed. */
@@ -43,24 +79,60 @@
 " Updates and info at http://www.scyld.com/network/starfire.html\n";
 
 static const char version3[] =
-" (unofficial 2.4.x kernel port, version 1.1.4, August 10, 2000)\n";
+" (unofficial 2.4.x kernel port, version 1.2.9, April 19, 2001)\n";
+
+/*
+ * Adaptec's license for their Novell drivers (which is where I got the
+ * firmware files) does not allow one to redistribute them. Thus, we can't
+ * include the firmware with this driver.
+ *
+ * However, an end-user is allowed to download and use it, after
+ * converting it to C header files using starfire_firmware.pl.
+ * Once that's done, the #undef must be changed into a #define
+ * for this driver to really use the firmware. Note that Rx/Tx
+ * hardware TCP checksumming is not possible without the firmware.
+ *
+ * I'm currently [Feb 2001] talking to Adaptec about this redistribution
+ * issue. Stay tuned...
+ */
+#undef HAS_FIRMWARE
+/*
+ * The current frame processor firmware fails to checksum a fragment
+ * of length 1. If and when this is fixed, the #define below can be removed.
+ */
+#define HAS_BROKEN_FIRMWARE
 
 /* The user-configurable values.
These may be modified when a driver module is loaded.*/
 
 /* Used for tuning interrupt latency vs. overhead. */
-static int interrupt_mitigation = 0x0;
+static int interrupt_mitigation;
 
 static int debug = 1;  /* 1 normal messages, 0 quiet .. 7 verbose. */
 static int max_interrupt_work = 20;
 static int mtu;
 /* Maximum number of multicast addresses to filter (vs. rx-all-multicast).
-   The Starfire has a 512 element hash table based on the Ethernet CRC.  */
-static int multicast_filter_limit = 32;
+   The Starfire has a 512 element hash table based on the Ethernet CRC. */
+static int multicast_filter_limit = 512;
 
-/* Set the copy breakpoint for the copy-only-tiny-frames scheme.
-   Setting to  1518 effectively disables this feature. */
+#define PKT_BUF_SZ 1536/* Size of each temporary Rx buffer.*/
+/*
+ * Set the copy breakpoint for the copy-only-tiny-frames scheme.
+ * Setting to  1518 effectively disables this feature.
+ *
+ * NOTE:
+ * The ia64 doesn't allow for unaligned loads even of integers being
+ * misaligned on a 2 byte boundary. Thus always force copying of
+ * packets as the starfire doesn't allow for misaligned DMAs ;-(
+ * 23/10/2000 - Jes
+ *
+ * The Alpha and the Sparc don't allow unaligned loads, either. -Ion
+ */
+#if defined(__ia64__) || defined(__alpha__) || defined(__sparc__)
+static int rx_copybreak = PKT_BUF_SZ;
+#else
 static int rx_copybreak = 0;
+#endif
 
 /* Used to pass the media type, etc.
Both 'options[]' and 'full_duplex[]' exist for driver interoperability.
@@ -84,21 +156,9 @@
 
 /* Operational parameters that usually are not changed. */
 /* Time in jiffies before concluding the transmitter is hung. */
-#define TX_TIMEOUT  (2*HZ)
+#define TX_TIMEOUT (2*HZ)
 
-#define PKT_BUF_SZ 1536   

Re: Children first in fork

2001-04-20 Thread Thomas Pornin

In article 9bn90l$anp$[EMAIL PROTECTED] you write:
 You're probably even better off just intercepting the fork, turning it
 into a clone, and setting the CLONE_PTRACE option.

Actually it is not that simple. The child process will be traced by its
father, not the tracing program. The father must detach from its child
in order to allow the tracing program to attach to the child, and then
you have again the race condition: the child will be untraced for some
time.

The trick is to modify the return address of the call so that the child
and the father loop on the syscall. This way, you can make the father:

-- modify the child so that the child will send itself a SIGSTOP when
released
-- detach itself from the child
(-- if the child is scheduled, it stops itself)
Then the tracing process can attach to the child and handle the
situation.

I have some code almost running, doing that. Well, it works, but with
strange bugs in some occasions. I am still sorting these out. It is
utterly tricky, anyway.


--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

2001-04-20 Thread Patrick Caulfield

On Thu, Apr 19, 2001 at 04:09:32PM -0400, Jeff Garzik wrote:
 AJ Lewis wrote:
  Ok, the issue here is that we're trying to get a release out and so anything
  that majorly changes the code is getting shunted aside for the moment.  It
  would be stupid to just add everything that comes in on the ML without
  review.  Linus does the exact same thing.  I've said this before to you
  Andreas, but apparently you feel that you should have final say on whether
  your patches go in or not.
 
  As far as getting patches into the stock kernel, we've been sending patches
  to Linus for over a month now, and none of them have made it in.  Maybe
  someone has some pointers on how we get our code past his filters.
 
 Read Documentation/SubmittingPatches, and also listen to kernel hackers
 who know the block layer and want to fix lvm.

OK, we're in the process of splitting the big patch up into nice clean small
patches to go to Linus. Hopefully this should be done today, or very shortly at
least.


patrick

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [lkml]Re: ac10 ide-cd oopses on boot

2001-04-20 Thread thunder7

On Thu, Apr 19, 2001 at 09:55:46PM -0500, Jordan wrote:
 Bill Nottingham wrote:
  
  J . A . Magallon ([EMAIL PROTECTED]) said:
Can you back out the ide-cd changes Jens did and see if that fixes it ?
  
   Reverted the changes in ide-cd.[hc], and same result.
  
  You want to back out the stuff from drivers/cdrom/cdrom.c; I backed
  out the parts of the patch new there to ac10, and it worked again
  for me...
  
 That worked here as well...here is a patch that should restore
 linux/drivers/cdrom/cdrom.c back to its working ac9 state from ac10.
 
snip patch; can be found on lkml

2.4.3-ac10 wouldn't boot for me without this patch.
I have only scsi cdrom(s) on an symbios 860:

Attached devices: 
Host: scsi0 Channel: 00 Id: 02 Lun: 00
  Vendor: PLEXTOR  Model: CD-R   PX-R412C  Rev: 1.03
  Type:   CD-ROM   ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 04 Lun: 00
  Vendor: SONY Model: SDT-5000 Rev: 330B
  Type:   Sequential-AccessANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 05 Lun: 00
  Vendor: PLEXTOR  Model: CD-ROM PX-32TS   Rev: 1.02
  Type:   CD-ROM   ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: TOSHIBA  Model: DVD-ROM SD-M1401 Rev: 1008
  Type:   CD-ROM   ANSI SCSI revision: 02

With this patch, it boots just fine.

Good luck,
Jurriaan
-- 
And all the while, all the while, I still hear that call
To the land of gold and poison that beckons to us all
Do you think you're so brave just to go running to that which beckons to us all?
New Model Army - Valleys of Green and Grey
GNU/Linux 2.4.3-ac10 SMP/ReiserFS 2x1743 bogomips load av: 0.20 0.05 0.01
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: epic100 error

2001-04-20 Thread Stefan Jaschke

Hi,
it seems the epic100 driver broke between 2.4.2 and 2.4.3.
I reloaded the epic100 module with the parameter "debug=6".
Unfortunately, I cannot make much out of the log:

Apr 20 12:47:01 antares kernel: epic100.c:v1.11 1/7/2001 Written by Donald Becker 
[EMAIL PROTECTED]
Apr 20 12:47:01 antares kernel:   http://www.scyld.com/network/epic100.html
Apr 20 12:47:01 antares kernel:  (unofficial 2.4.x kernel port, version 1.1.6, January 
11, 2001)
Apr 20 12:47:01 antares kernel: epic100(00:08.0): EEPROM contents
Apr 20 12:47:01 antares kernel:  e000 2829 ec39 aa00 001d 1c08 10b8 a011   
     
Apr 20 12:47:01 antares kernel:            
     
Apr 20 12:47:01 antares kernel:  0010  1980 2100   0003  0701  
  4d53 3943 3334 5432
Apr 20 12:47:01 antares kernel:  2058 2020   0280      
     
Apr 20 12:47:01 antares kernel: epic100(00:08.0): MII transceiver #3 control 3000 
status 7809.
Apr 20 12:47:01 antares kernel: epic100(00:08.0): Autonegotiation advertising 01e1 
link partner 0001.
Apr 20 12:47:01 antares kernel: eth0: SMSC EPIC/100 83c170 at 0xd800, IRQ 9, 
00:e0:29:28:39:ec.
Apr 20 12:48:07 antares kernel: eth0: Setting half-duplex based on MII xcvr 3 register 
read of 0001.
Apr 20 12:48:07 antares kernel: eth0: epic_open() ioaddr d800 IRQ 9 status 0512 
half-duplex.
Apr 20 12:48:10 antares kernel: eth0: Media monitor tick, Tx status 000b.
Apr 20 12:48:10 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
24 RxStatus 1090021.
Apr 20 12:48:10 antares kernel: eth0: Setting full-duplex based on MII #3 link partner 
capability of 41e1.
Apr 20 12:48:15 antares kernel: eth0: Media monitor tick, Tx status 000b.
Apr 20 12:48:15 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
24 RxStatus 1090021.
Apr 20 12:48:20 antares kernel: eth0: Media monitor tick, Tx status 400b.
Apr 20 12:48:20 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
24 RxStatus 1090021.
Apr 20 12:48:25 antares kernel: eth0: Media monitor tick, Tx status 400b.
Apr 20 12:48:25 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
24 RxStatus 1090021.
Apr 20 12:48:30 antares kernel: eth0: Media monitor tick, Tx status 400b.
Apr 20 12:48:30 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
24 RxStatus 1090021.
Apr 20 12:48:35 antares kernel: eth0: Media monitor tick, Tx status 400b.
Apr 20 12:48:35 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
24 RxStatus 1090021.
Apr 20 12:48:40 antares kernel: eth0: Media monitor tick, Tx status 400b.
Apr 20 12:48:40 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
24 RxStatus 1090021.
Apr 20 12:48:45 antares kernel: eth0: Media monitor tick, Tx status 400b.
Apr 20 12:48:45 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
24 RxStatus 1090021.
Apr 20 12:48:45 antares kernel: eth0: Interrupt, status=0x00250001 new 
intstat=0x0024.
Apr 20 12:48:45 antares kernel:  In epic_rx(), entry 0 00601021.
Apr 20 12:48:45 antares kernel:   epic_rx() status was 00601021.
Apr 20 12:48:45 antares kernel: eth0: Interrupt, status=0x0024 new 
intstat=0x0024.
Apr 20 12:48:45 antares kernel: eth0: exiting interrupt, intr_status=0x24.
Apr 20 12:48:46 antares kernel: eth0: Interrupt, status=0x008d0004 new 
intstat=0x008c.
Apr 20 12:48:46 antares last message repeated 32 times
Apr 20 12:48:46 antares kernel: eth0: Too much work at interrupt, 
IntrStatus=0x008d0004.
Apr 20 12:48:46 antares kernel: eth0: exiting interrupt, intr_status=0x8d0004.
Apr 20 12:48:50 antares kernel: eth0: Media monitor tick, Tx status 400b.
Apr 20 12:48:50 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
8c RxStatus 6014a1.
Apr 20 12:48:55 antares kernel: eth0: Media monitor tick, Tx status 400b.
Apr 20 12:48:55 antares kernel: eth0: Other registers are IntMask 13bf IntStatus 
8c RxStatus 6014a1.

I also noted that there are substantial differences between the original epic100.c at
http://www.scyld.com/network/epic100.html and the version included with 2.4.3.
Who did these changes?

Stefan J.
-- 
Stefan R. Jaschke [EMAIL PROTECTED]
http://www.jaschke-net.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Linux 2.4.3 Compile Errors - Power Mac

2001-04-20 Thread Paul Mackerras

Jeff Galloway writes:

 Compiler error message:
 
 fork.c: In function Œcopy_mm:
 fork.c:353: fixed or forbidden register 68 (0) was spilled for class
 CR0_REGS.
 This may be due to a compiler bug or to impossible asm statements or
 clauses.

You need a newer gcc, I suspect you have egcs installed, and you need
to upgrade to gcc-2.95.2 or later.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [PATCH] PPP update against 2.4.4-pre5

2001-04-20 Thread Paul Mackerras

Brown-paper bag time...

The patch I sent earlier didn't include the accompanying changes to
if_ppp.h and ppp_channel.h.  Here they are.

Paul.

diff -urN linux/include/linux/if_ppp.h pmac/include/linux/if_ppp.h
--- linux/include/linux/if_ppp.hTue Mar 28 04:28:55 2000
+++ pmac/include/linux/if_ppp.h Mon Mar  5 12:16:15 2001
@@ -1,4 +1,4 @@
-/* $Id: if_ppp.h,v 1.19 1999/03/31 06:07:57 paulus Exp $   */
+/* $Id: if_ppp.h,v 1.21 2000/03/27 06:03:36 paulus Exp $   */
 
 /*
  * if_ppp.h - Point-to-Point Protocol definitions.
@@ -21,7 +21,7 @@
  */
 
 /*
- *  ==FILEVERSION 2324==
+ *  ==FILEVERSION 2724==
  *
  *  NOTE TO MAINTAINERS:
  * If you modify this file at all, please set the above date.
@@ -130,6 +130,8 @@
 #define PPPIOCSCOMPRESS_IOW('t', 77, struct ppp_option_data)
 #define PPPIOCGNPMODE  _IOWR('t', 76, struct npioctl) /* get NP mode */
 #define PPPIOCSNPMODE  _IOW('t', 75, struct npioctl)  /* set NP mode */
+#define PPPIOCSPASS_IOW('t', 71, struct sock_fprog) /* set pass filter */
+#define PPPIOCSACTIVE  _IOW('t', 70, struct sock_fprog) /* set active filt */
 #define PPPIOCGDEBUG   _IOR('t', 65, int)  /* Read debug level */
 #define PPPIOCSDEBUG   _IOW('t', 64, int)  /* Set debug level */
 #define PPPIOCGIDLE_IOR('t', 63, struct ppp_idle) /* get idle time */
diff -urN linux/include/linux/ppp_channel.h pmac/include/linux/ppp_channel.h
--- linux/include/linux/ppp_channel.h   Mon Apr  2 02:20:35 2001
+++ pmac/include/linux/ppp_channel.hThu Apr 19 19:16:39 2001
@@ -22,7 +22,6 @@
 #include linux/list.h
 #include linux/skbuff.h
 #include linux/poll.h
-#include asm/atomic.h
 
 struct ppp_channel;
 
@@ -32,7 +31,6 @@
int (*start_xmit)(struct ppp_channel *, struct sk_buff *);
/* Handle an ioctl call that has come in via /dev/ppp. */
int (*ioctl)(struct ppp_channel *, unsigned int, unsigned long);
-   
 };
 
 struct ppp_channel {
@@ -78,16 +76,6 @@
  * in the start_xmit and ioctl routines for the channel by the time
  * that ppp_unregister_channel returns.
  */
-
-/* The following are temporary compatibility stuff */
-ssize_t ppp_channel_read(struct ppp_channel *chan, struct file *file,
-char *buf, size_t count);
-ssize_t ppp_channel_write(struct ppp_channel *chan, const char *buf,
- size_t count);
-unsigned int ppp_channel_poll(struct ppp_channel *chan, struct file *file,
- poll_table *wait);
-int ppp_channel_ioctl(struct ppp_channel *chan, unsigned int cmd,
- unsigned long arg);
 
 #endif /* __KERNEL__ */
 #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Asynchronous IO

2001-04-20 Thread Stephen C. Tweedie

Hi,

On Fri, Apr 13, 2001 at 04:45:07AM -0400, Dan Maas wrote:
 IIRC the problem with implementing asynchronous *disk* I/O in Linux today is
 that the filesystem code assumes synchronous I/O operations that block the
 whole process/thread. So implementing "real" asynch I/O (without the
 overhead of creating a process context for each operation) would require
 re-writing the filesystems as non-blocking state machines. Last I heard this
 was a long-term goal, but nobody's done the work yet

SGI and Ben LaHaise both have kernel async IO functionality working,
and Ingo Molnar's Tux code has support for doing certain filesystem
lookup operations asynchronously too.  

--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: starfire update for 2.4.4-pre5

2001-04-20 Thread Ion Badulescu

On Fri, 20 Apr 2001, Jeff Garzik wrote:

 alas:
 http://gtf.org/garzik/kernel/files/patches/2.4/2.4.4/net-version-2.4.4.5.patch.gz

Oh well. Another hour, another patch to be sent out. :-)

I'll deal with CVS tomorrow, when I figure out on which disk I have enough
space for yet another tree. So I can only hope the attached diff,
generated against 2.4.4-pre5 plus the above patch, will apply cleanly.

Once these changes are accepted, the next step will be to add zerocopy 
support. I have it all ready (since January), I was just waiting for the 
zerocopy framework to be included.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
--- /mnt/3/linux-2.4/drivers/net/starfire.c Fri Apr 20 04:06:54 2001
+++ linux-2.4/drivers/net/starfire.cFri Apr 20 04:08:23 2001
@@ -20,7 +20,7 @@
---
 
Linux kernel-specific changes:
-   
+
LK1.1.1 (jgarzik):
- Use PCI driver interface
- Fix MOD_xxx races
@@ -31,27 +31,102 @@
 
LK1.1.3 (Andrew Morton)
- Timer cleanups
-   
+
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+   LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+   - Support hardware Rx/Tx checksumming
+   - Use the GFP firmware taken from Adaptec's Netware driver
+
+   LK1.2.2 (Ion Badulescu)
+   - Backported to 2.2.x
+
+   LK1.2.3 (Ion Badulescu)
+   - Fix the flaky mdio interface
+   - More compat clean-ups
+
+   LK1.2.4 (Ion Badulescu)
+   - More 2.2.x initialization fixes
+
+   LK1.2.5 (Ion Badulescu)
+   - Several fixes from Manfred Spraul
+
+   LK1.2.6 (Ion Badulescu)
+   - Fixed ifup/ifdown/ifup problem in 2.4.x
+
+   LK1.2.7 (Ion Badulescu)
+   - Removed unused code
+   - Made more functions static and __init
+
+   LK1.2.8 (Ion Badulescu)
+   - Quell bogus error messages, inform about the Tx threshold
+   - Removed #ifdef CONFIG_PCI, this driver is PCI only
+
+   LK1.2.9 (Ion Badulescu)
+   - Merged Jeff Garzik's changes from 2.4.4-pre5
+   - Added 2.2.x compatibility stuff required by the above changes
+
+   LK1.2.9a (Ion Badulescu)
+   - More updates from Jeff Garzik
+
+TODO:
+   - implement tx_timeout() properly
+   - support ethtool
 */
 
+/*
+ * Adaptec's license for their Novell drivers (which is where I got the
+ * firmware files) does not allow one to redistribute them. Thus, we can't
+ * include the firmware with this driver.
+ *
+ * However, an end-user is allowed to download and use it, after
+ * converting it to C header files using starfire_firmware.pl.
+ * Once that's done, the #undef must be changed into a #define
+ * for this driver to really use the firmware. Note that Rx/Tx
+ * hardware TCP checksumming is not possible without the firmware.
+ *
+ * I'm currently [Feb 2001] talking to Adaptec about this redistribution
+ * issue. Stay tuned...
+ */
+#undef HAS_FIRMWARE
+/*
+ * The current frame processor firmware fails to checksum a fragment
+ * of length 1. If and when this is fixed, the #define below can be removed.
+ */
+#define HAS_BROKEN_FIRMWARE
+
 /* The user-configurable values.
These may be modified when a driver module is loaded.*/
 
 /* Used for tuning interrupt latency vs. overhead. */
-static int interrupt_mitigation = 0x0;
+static int interrupt_mitigation;
 
 static int debug = 1;  /* 1 normal messages, 0 quiet .. 7 verbose. */
 static int max_interrupt_work = 20;
 static int mtu;
 /* Maximum number of multicast addresses to filter (vs. rx-all-multicast).
-   The Starfire has a 512 element hash table based on the Ethernet CRC.  */
-static int multicast_filter_limit = 32;
+   The Starfire has a 512 element hash table based on the Ethernet CRC. */
+static int multicast_filter_limit = 512;
 
-/* Set the copy breakpoint for the copy-only-tiny-frames scheme.
-   Setting to  1518 effectively disables this feature. */
+#define PKT_BUF_SZ 1536/* Size of each temporary Rx buffer.*/
+/*
+ * Set the copy breakpoint for the copy-only-tiny-frames scheme.
+ * Setting to  1518 effectively disables this feature.
+ *
+ * NOTE:
+ * The ia64 doesn't allow for unaligned loads even of integers being
+ * misaligned on a 2 byte boundary. Thus always force copying of
+ * packets as the starfire doesn't allow for misaligned DMAs ;-(
+ * 23/10/2000 - Jes
+ *
+ * The Alpha and the Sparc don't allow unaligned loads, either. -Ion
+ */
+#if defined(__ia64__) || defined(__alpha__) || defined(__sparc__)
+static int rx_copybreak = PKT_BUF_SZ;
+#else
 static int rx_copybreak = 0;
+#endif
 
 /* Used to pass the media type, etc.
Both 'options[]' and 'full_duplex[]' exist for driver interoperability.
@@ -75,21 +150,9 @@
 
 /* Operational parameters that usually are not changed. */
 /* Time in jiffies before concluding the transmitter 

RTC !

2001-04-20 Thread npunmia




Hi,

When i compiled the following program , (taken from
/usr/src/linux/Documentation/rtc.txt )


(See attached file: rtc2.c)

it gave me the following error:

[root@msatuts1 timer1]#  gcc -s -Wall -Wstrict-prototypes rtc2.c -o rtc2
In file included from rtc2.c:17:
/usr/include/linux/mc146818rtc.h:29: parse error before `rtc_lock'
/usr/include/linux/mc146818rtc.h:29: warning: data definition has no type or
storage class
rtc2.c:25: warning: return type of `main' is not `int'
[root@msatuts1 timer1]#

 Is this a bug?Can anyone tell me how to remove this parse error ?

With Regards,
--Niraj


-- Forwarded by Niraj Punmia/HSS on 04/20/2001 04:31 PM
---


Niraj Punmia
04/12/2001 02:50 PM

To:   [EMAIL PROTECTED]
cc:

Subject:  RTC !!

Hi ,

The RTC interrupt  is programmable from 2 Hz to 8192 Hz, in powers of 2. So the
interrupts that you
could get are one of the following:  0.122ms, .244ms, .488ms, .977ms,
1.953ms, 3.906ms, 7.813ms, and so on.Is there any  workaround , so that i
can use RTC
for meeting my requirement of an interrupt every 1.666..ms!!  ( I know that i
can use UTIME or #define HZ 600, but i want to know if i can use RTC for this
purpose )

With Regards,
--Niraj

-- Forwarded by Niraj Punmia/HSS on 04/12/2001 02:33 PM
---


James Stevenson [EMAIL PROTECTED] on 04/09/2001 06:42:44 PM

Please respond to [EMAIL PROTECTED]

To:   Niraj Punmia/HSS@HSS
cc:

Subject:  Re: 1. ms interrupts needed!!





Hi

instead of modifing the time irq freq you could try using the
realt time clock (rtc) it will generate irqs with better timing
and you also wont hit system performance as much by modifing the timer
ever time the timer send an irq some code is run to see it schedule need
to be called the more times schedule is called a second the worse the
system performance is because of the task switching overhead.

In local.linux-kernel-list, you wrote:



Hi.

We are simulating air interface of GPRS on LAN. A TDMA(time division multiple
access) frame duration is 40ms.  Each TDMA frame consists of 24 timeslots. Each
timeslot  is  of 40/24 ms (i.e 1.6...ms) . To know  what current
timeslot it is, we need a timer interrupt after every 1.... ms .   Since we
are implementing this on LAN, minor jitters once in a while can be tolerated
(say 0.2 ms more or less once a while would be OK).
 As of now, we are modifying the HZ value in param.h to 600.  This gives us
a CPU tick of  1. ms. (i.e 1/600sec).  I want to know if it would
affect
the perfomance of the CPU.
 Is there a better way to achieve the granularity of 1.666...ms .  Would
the
UTIME patch be a better way from performance or any other point of view  than
this method?

With Regards,
Niraj Punmia



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



--
-
Check Out: http://stev.org
E-Mail: [EMAIL PROTECTED]
  1:10pm  up 13 days, 21:05,  5 users,  load average: 0.45, 0.45, 0.47






 rtc2.c


Re: epic100 error

2001-04-20 Thread Stefan Jaschke

On Friday 20 April 2001 12:25, Francois Romieu wrote:
 Summary:
 Arnd Bergmann:
   orig epic100"DMA mapped epic100 (any version)"
   (=2.4.0-ac9)
 VT8363ok  fscked but ok after bios update

 Daniel Nofftz:
   2.4.2   2.4.3
 VT82C595  ok  fscked. (no mention of bios experience)

 Oliver Teuber:
   2.2.19  2.4.3-ac7
 VT82C598  ok  fscked

 Romieu:
   2.2.xx  2.4.[123]
 82443BX   ok  ok
Stefan Jaschke:
2.2.xx2.4.0 2.4.3 
2.4.4-pre4
AMD 761   ok ok fails  fails

# lspci
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev 01)
00:08.0 Ethernet controller: Standard Microsystems Corp [SMC] 83C170QF (rev 08)

 What happen's if you compile 2.4.2 epic100 driver in a 2.4.3 tree (I) ?
I'll try this asap.

Stefan
-- 
Stefan R. Jaschke [EMAIL PROTECTED]
http://www.jaschke-net.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: epic100 error

2001-04-20 Thread Jeff Garzik

Stefan Jaschke wrote:
 I also noted that there are substantial differences between the original epic100.c at
 http://www.scyld.com/network/epic100.html and the version included with 2.4.3.
 Who did these changes?

Francois (PCI DMA) and me (everything else).  The scyld version does not
support 2.4 kernels, so these changes were necessary.

Besides Francois changes, the biggest thing in 2.4.3 was a merge of
additional scyld.com code :)

I'm leaving on a trip so I won't be able to look at this until after
2.4.4 is released...   Maybe one of you guys is willing to play patch
circus, and go through the changes to the epic driver one by one and see
which one caused the breakage.  When I get back I'll take a look at
this.

Here's a suggestion to try: go through epic100.c and write 0x12
unconditionally to MIICfg register.  Right now it is conditional:  if
(dev-if_port...) out(0x12,ioaddr+MIICfg);

-- 
Jeff Garzik  | The difference between America and England is that
Building 1024| the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Configure.help maintainer change

2001-04-20 Thread Eric S. Raymond

Steven Cole [EMAIL PROTECTED]:
 Axel Boldt wrote:
 Eric has worked on Configure.help for some time now and I haven't,
 so he will take over official maintenance of that file.
 
 I've also been fixing up Configure.help for a while now, and helped Eric
 recently with his huge update patch for Configure.help.
 
 I'd like to be listed as a co-maintainer of Configure.help, along with ESR.

I agree this would be a good idea.
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

What if you were an idiot, and what if you were a member of Congress?
But I repeat myself.
-- Mark Twain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Linux 2.4.3 Compile Errors - Power Mac

2001-04-20 Thread Jeff Galloway

Thanks.  I'll try your suggestions and check on the version of my compiler
and binutils.

on 4/20/01 3:57 AM, David Woodhouse at [EMAIL PROTECTED] wrote:

 
 
 [EMAIL PROTECTED] said:
   However, I don't think that wishing the world would avoid these
 dominant (and very useful) formats is a realistic expectation.  It is
 certainly not "common sense" to assume as such.
 
 Of course it's not a realistic expectation. There are times when it's a pain
 to have to be safe - people will always break the rules when they're in a
 hurry and the document to be sent is already in an unsafe format. But taking
 plain text with absolutely no formatting, in fact text which is
 _degenerated_ by word wrapping c, and gratuitously putting it in a Word
 document is just _so_ unnecessary that I assumed it had to be a troll.
 
 
 fork.c: In function ?copy_mm:
 
 Given what this output's been through - I'll assume it's corrupted in
 transit, shall I?
 
 The kind of error you're seeing is often caused by a mismatch between
 compiler and kernel. As Alan suggests, you should make sure you're using a
 PPC-specific tree because it's not up to date in the stock 2.4.3. And make
 sure you're using the recommended versions of compiler and binutils. Other
 than that, I'm afraid I don't know.
 
 --
 dwmw2
 


Jeff Galloway
New York
[EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Kernel panics on raw I/O stress test

2001-04-20 Thread Takanori Kawano


 Could you try again with 2.4.4pre4 plus the below patch?
 
   
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre2/rawio-3

I suppose that 2.4.4-pre4 + rawio-3 patch still has SMP-unsafe
raw i/o code and can cause the same panic I reported.

I think the following scenario is possible if there are 3 or more CPUs.

(1) CPU0 enter rw_raw_dev()
(2) CPU0 execute alloc_kiovec(1, iobuf)// drivers/char/raw.c line 309
(3) CPU0 enter brw_kiovec(rw, 1, iobuf,..) // drivers/char/raw.c line 362
(4) CPU0 enter __wait_on_buffer()
(5) CPU0 execute run_task_queue() and wait
while buffer_locked(bh) is true.// fs/buffer.c line 152-158
(6) CPU1 enter end_buffer_io_kiobuf() with
 iobuf allocated at (2)
(7) CPU1 execute unlock_buffer()// fs/buffer.c line 1994
(8) CPU0 exit __wait_on_buffer()
(9) CPU0 exit brw_kiovec(rw, 1, iobuf,..)
(10) CPU0 execute free_kiovec(1, iobuf) // drivers/char/raw.c line 388
(11) The task on CPU2 reused the area freed
 at (10).
(12) CPU1 enter end_kio_request() and touch
 the corrupted iobuf, then panic.

---
Takanori Kawano
Hitachi Ltd,
Internet Systems Platform Division
[EMAIL PROTECTED]



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



URGENT: Help on Cache Kernel

2001-04-20 Thread Pooja Gupta

Hello there!!
   I am begineer in kernels.  I would like to know more about Cache Kernel.  Can 
anyone tell me some good links for Cache Kernel?  I have seen the stanford paper.  Can 
you suggest something other than that?
   Pooja

_
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: RTC !

2001-04-20 Thread Jesper Juhl

[EMAIL PROTECTED] wrote:

 Hi,

 When i compiled the following program , (taken from
 /usr/src/linux/Documentation/rtc.txt )

 (See attached file: rtc2.c)

 it gave me the following error:

 [root@msatuts1 timer1]#  gcc -s -Wall -Wstrict-prototypes rtc2.c -o rtc2
 In file included from rtc2.c:17:
 /usr/include/linux/mc146818rtc.h:29: parse error before `rtc_lock'
 /usr/include/linux/mc146818rtc.h:29: warning: data definition has no type or
 storage class
 rtc2.c:25: warning: return type of `main' is not `int'
 [root@msatuts1 timer1]#

  Is this a bug?Can anyone tell me how to remove this parse error ?

It works fine for me using a 2.2.16 kernel and egcs-2.91.66 (see below)...


bash-2.04$ gcc -s -Wall -Wstrict-prototypes rtc2.c -o rtc2
rtc2.c:24: warning: return type of `main' is not `int'
bash-2.04$ ./rtc2

RTC Driver Test Example.

Counting 5 update (1/sec) interrupts from reading /dev/rtc: 1 2 3 4 5
Again, from using select(2) on /dev/rtc: 1 2 3 4 5

Current RTC date/time is 20-4-2001, 12:34:01.
Alarm time now set to 12:34:06.
Waiting 5 seconds for alarm... okay. Alarm rang.

Periodic IRQ rate was 1024Hz.
Counting 20 interrupts at:
2Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
4Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
8Hz: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
16Hz:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
32Hz:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
64Hz:1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

 *** Test complete ***

Typing "cat /proc/interrupts" will show 131 more events on IRQ 8.

bash-2.04$


Regards,
Jesper Juhl
[EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [Ext2-devel] [PATCH] update ext2 documentation

2001-04-20 Thread Daniel Phillips

On Fri, 20 Apr 2001, Andreas Dilger wrote:
 The included patch updates Documentation/filesystems/ext2 to reflect
 current information about ext2.  It also adds some more information
 that people have told me is hard to find in other places (such as a
 description of the superblock compatibility flags, file and filesystem
 size limits).

To quote Oliver Twist: "Please, Sir, I want some more".  How about a
explanation of the significance of GOOD_OLD_REV, etc.  In particular, I'm
curious why CURRENT_REV is defined as GOOD_OLD_REV and not DYNAMIC_REV.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: epic100 error

2001-04-20 Thread Stefan Jaschke

On Friday 20 April 2001 13:33, Jeff Garzik wrote:
 Here's a suggestion to try: go through epic100.c and write 0x12
 unconditionally to MIICfg register.  Right now it is conditional:  if
 (dev-if_port...) out(0x12,ioaddr+MIICfg);

I changed all three such lines. Same behavior as before.

offtopic
You also cc-d this to [EMAIL PROTECTED] My message to this address 
bounced. Is this a problem with my provider only?

'A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
  [EMAIL PROTECTED]:
unrouteable mail domain "skyld.com"'
/offtopic

-- 
Stefan R. Jaschke [EMAIL PROTECTED]
http://www.jaschke-net.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: AHA-154X/1535 not recognized any more

2001-04-20 Thread Markus Schaber

On Wed, 18 Apr 2001, Alan Cox wrote:

  Well, as this device is already configured by the bios, I just tried
  to load it giving the right IO port, and got the following message:

 The kernel PnP will deconfigure it

Ah, interesting.

 The module parameters are

 aha1542=io, irq, busff, dmaspeed

I recompiled the kernel with isapnp-support and statically compiled
driver. I then typed aha1542=0x330 at the lilo prompt, but the card wasn't
recognized (see dmesg_pnp_bootparam.txt on http://schabi.de/scsi/).

isapnp will initialize the card when the check entry is removed, but
doesn't activate the driver. I'll next test with modularized driver, and
the isapnp tools.

markus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: pmd_alloc, pte_alloc, Was Re: 2.4.3 and Alpha

2001-04-20 Thread Paul Mackerras

[EMAIL PROTECTED] writes:

   Basically in the pmd, it would seem that the current design in 2.4.3 forces
 you to have pointers in there. Currently in our source we're using offsets
 instead of a 64 bit pointer... this of course saved us from having to alloc 2
 contiguous pages in memory. 

Nope, the representation of the pgd/pmd/pte entries is entirely up to
you (us :).  The pmd entries for example are accessed through pmd_none,
pmd_present, pte_offset, etc., and are set with pmd_populate.  Those
functions are all defined in asm/pgtable.h and asm/pgalloc.c.  So you
can make the representation whatever you like as long as those
functions all do the right thing.  Same goes for the pgd and pte
levels.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: AHA-154X/1535 not recognized any more

2001-04-20 Thread Markus Schaber

On Wed, 18 Apr 2001, Rafael E. Herrera wrote:

  lunix:~# isapnp pnpconfig.txt
  Board 1 has Identity 08 0f 6d b9 45 42 15 90 04:  ADP1542 Serial No 258849093 
[checksum 08]
  pnptext:60 -- Fatal - IO range check attempted while device activated
  pnptext:60 -- Fatal - Error occurred executing request 'IORESCHECK ' --- further 
action aborted

 I've a pnp sound card that fails to configure with a similar error
 message when a (CHECK) entry was found in an (IO ...) block. Removing
 those entries solved the problem. Try this in your pnpconfig.txt:

 (IO 0 (SIZE 4) (BASE 0x0330))

In this case, isapnp configures the card.

Using a modularized kernel, modprobe also loads the driver without any
further parameters:

lunix:/home/schabi/public_html/scsi# /rescue/sbin/isapnp pnpconfig_nocheck.txt
Board 1 has Identity 08 0f 6d b9 45 42 15 90 04:  ADP1542 Serial No
258849093 [checksum 08]
ADP1542/258849093[0]{SCSI Host Adapter   }: Port 0x330; IRQ10 DMA0 ---
Enabled OK
lunix:/home/schabi/public_html/scsi# modprobe aha1542
lunix:/home/schabi/public_html/scsi#
ls /proc/scsi
advansys  aha1542  ide-scsi  scsi  sg
lunix:/home/schabi/public_html/scsi# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 03 Lun: 00
  Vendor: YAMAHA   Model: CRW8424S Rev: 1.0j
  Type:   CD-ROM   ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: IOMEGA   Model: ZIP 100  Rev: 03.H
  Type:   Direct-AccessANSI SCSI revision: 
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: SAMSUNG  Model: CD-ROM SCR-3231  Rev: S104
  Type:   CD-ROM   ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 06 Lun: 00
  Vendor: IOMEGA   Model: ZIP 100 PLUS Rev: J.66
  Type:   Direct-AccessANSI SCSI revision: 02

So the isapnp tools can configure the card correctly.

markus




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Good example of the kind of thing the cross-referencer turns up.

2001-04-20 Thread Roger Gammans

On Thu, Apr 19, 2001 at 01:17:38PM -0400, Eric S. Raymond wrote:
 Go on.  Tell me this isn't an error...
 
 CONFIG_ARCH_CLPS7110: arch/arm/kernel/arch.c
 CONFIG_ARCH_CLPS711X: arch/arm/Makefile arch/arm/config.in arch/arm/kernel/Makefile 
arch/arm/kernel/entry-armv.S arch/arm/kernel/debug-armv.S 
arch/arm/def-configs/ebsa110 arch/arm/def-configs/footbridge arch/arm/def-configs/rpc 
arch/arm/def-configs/integrator
 
 Somebody forgot an edit.  I wonder what bits got permanently conditioned out?

Don't know. I think the  CONFIG_ARCH_CLPS7110 is a stub refering to
mine and Werner's (2.2) PDA port, which AFAIK hasn't been mergerd.

I think CONFIG_ARCH_CLPS711X is a completely seperate port done
by a different group to the evaluaiton boards and similiar.

I'm not sure but that's certianly what it looks like to me, I
was hoping Russell might have said something more useful.

TTFN
-- 
Roger
 Think of the mess on the carpet. Sensible people do all their
 demon-summoning in the garage, which you can just hose down afterwards.
-- [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: PCI power management

2001-04-20 Thread Benjamin Herrenschmidt

All devices should handle having power removed from them. And, all of the
drivers should as well, since that is the only way we're going to get
power management out of legacy devices and other things on the board. This
involves saving the current context on suspend, and reinitializing the
device, and restoring the context as much as possible when we resume. It
should behave almost identically to the boot-time init code.

Right. In fact, at the driver level, the power management involve
2 different things:

 - Handling context save  restore of the device state

 - Blocking of "user" (I mean user of the driver, that can be
   a kernel servicer) requests properly. In some case, this later
   thing can be done by returning errors provided that upper level
   drivers are read to handle them. For example, the IDE layer should
   probably just block the IO queues while the IDE susbsytem is powered
   off (not talking about disk sleep, but complete power off of the
   controller), while an USB host controller should probably return
   errors to URBs sent by drivers to a sleeping controller since those
   upper-level drivers should have been put to sleep before the host
   controller.
   That part is almost completely overlooked right now.

  - Some devices just can't be brought back to life from D3 state without
 a PCI reset (ATI Rage M3 for example) and that require some arch specific
 support (when it's possible at all).

When a device comes out of D3[hot], the equivalent of a soft reset is
performed. From D3[cold], PCI RST# is asserted, and the device must be
completely reinitialized.

Some devices (bad bad HW designers ;) just can't do it themselves. The
Rage M3 requires the host to assert PCI RST#, and some motherboards
provide no documented facility for that (it might be possible with Apple
ASICs for example, it's just not documented).

Also, still in the case of the Rage M3, we just can't bring it out of
D3 for the same reason we can't bring the r128 in the AGP slot of a
Cube Mac out of PowerOff : The complete init sequence of those chips
is dependent on the chip revision, requires some informations about
undocumented registers that we don't have (at least that's my understanding
from talks with ATI) and so can basically only be done by a BIOS (or
OpenFirmware driver in my case), and we can't run that on wakeup (OF
is dead on macs once the kernel takes over). So we have to limit
ourselves to D2 mode on machines that don't remove power from the
slots (powerbooks, ibooks  imacs) and we can't do deep sleep at all
on machines that remove power from the slot (Cube, G4s, ...), at least
until we figure out the proper init sequence for those cards.

So the point here, as far as the kernel is concerned, is that drivers
should have a way to let the kenrel know the min/max power state they
support.

It's not about what the device supports, it's about what the driver
supports. STR and STD imply that all devices will lose power. The drivers
are responsible for reinitializing the devices, regardless of what that
may involve. 

Right. I'm typing too fast, but that's what I meant.

Hmm. How about doing two walks of the device tree - the first calls a
save_state() function for each device, which gives it the opportunity to
allocate memory and save appropriate registers, etc. The second actually
places the device in a low power state.  

This could give the kernel the chance to disable swap, or for the action 
to be cancelled before anything is actually put to sleep.

Yup. That's approximately what I do with the PPC-specific
"sleep notifiers" we are using. The only difference is that the real
save state is done on the "sleep now" (latest) request, not on the
"sleep request" (earlier) request. 

The basic idea here is that the first pass will do all of the memory
allocation (or whatever requires all system resources to be available,
that can be sending a special power management message to the device,
like enabling the remote wakup on USB, etc...). So this first pass
requires system services (all other drivers if you prefer, especially
the swap device) to be fully alive.

The second pass will do the actual IO blocking, state save, and eventually
enter device suspend mode for cases where it's controlled by the driver.

  - On SMP, we need some way to stop other CPUs in the scheduler
 while running the last round of sleep (putting devices to sleep) at least
 until all IO layers in Linux can properly handle blocking of IO queues
 while the device sleeps.

Ugh. SMP. Not yet.

Well, if all drivers properly handle blocking of IOs, the SMP issue will
be easy to handle. Having the other CPUs run is not a problem as long as
any IO triggered by processes on theose are properly blocked by sleeping
drivers. All is needed is a cross-CPU function call to force the other
CPU into an idle loop (or a idle/sleep loop on PPC) on the very last
step of entering suspend mode.

  - We need a generic (non-x86 APM or ACPI dependant) way of 

i386 assembly timing issue

2001-04-20 Thread David Howells

I've attached two slightly different bits of i386 assembly that achieve the
same end, but in slightly different ways. Can some one tell me why Case 1 is
faster than Case 2? Case 1 involves an extra CALL instruction.

* Case 1 has a little wrapper function that saves ECX and EDX before
  calling rwsem_wake().

* Case 2 merges the contents of the wrapper with the caller.

Case 1 is what's generated by the rw-semaphore inline assembly code as of
2.4.4-pre5. Case 2 looks like it ought to be a faster version of the same
thing.

David

###
#
# CASE 1: registers saved in the rwsem_wake register saving stub
#
.text
.align 16

#
# void test_up_read(struct rw_semaphore *sem)
# {
#   up_read(sem);
# }
#
.globl test_up_read
.type   test_up_read,@function
test_up_read:
movl4(%esp), %eax
movl$-1, %edx
xadd%edx,(%eax)
js  test_up_read_contention
test_up_read_done:
ret

#
# Register saving stub for rwsem_wake
#
.globl __rwsem_wake
__rwsem_wake:
pushl   %edx
pushl   %ecx
callrwsem_wake
popl%ecx
popl%edx
ret

#
# Contention handler stub for up_read
#
.section .text.lock,"ax"
test_up_read_contention:
decl%edx
testl   $65535,%edx
jnz test_up_read_done
call__rwsem_wake
jmp test_up_read_done

###
#
# CASE 2: registers saved in the contention handler stub
#
.text
.align 16

#
# void test_up_read(struct rw_semaphore *sem)
# {
#   up_read(sem);
# }
#
.globl test_up_read
.type   test_up_read,@function
test_up_read:
movl4(%esp), %eax
movl$-1, %edx
xadd%edx,(%eax)
js  test_up_read_contention
test_up_read_done:
ret

#
# Contention handler stub for up_read
#
.section .text.lock,"ax"
test_up_read_contention:
decl%edx
testl   $65535,%edx
jnz test_up_read_done
pushl   %edx
pushl   %ecx
call__rwsem_wake
popl%ecx
popl%edx
jmp test_up_read_done
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



problem of partitioning

2001-04-20 Thread Xiong Zhao

hello,all.after i create a new logical partition using fdisk or cfdisk
and exit with "w",there always comes report saying that re-read table 
failed with error 16:device or resource busy.next time i attempt to mount
the newly created partition it comes error:mount /dev/sdx has wrong major
or minor number.the same thing happens after i reboot the machine.can
anyone give me a hand.

thanks in advance.


james

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: PCI power management

2001-04-20 Thread Jeff Garzik

Benjamin Herrenschmidt wrote:
 When a device comes out of D3[hot], the equivalent of a soft reset is
 performed. From D3[cold], PCI RST# is asserted, and the device must be
 completely reinitialized.
 
 Some devices (bad bad HW designers ;) just can't do it themselves. The
 Rage M3 requires the host to assert PCI RST#, and some motherboards
 provide no documented facility for that (it might be possible with Apple
 ASICs for example, it's just not documented).

Why should we support such a non-spec device?  Tell ATI to fix their
hardware, and tell users (a) not to use the hardware, or (b) use the
hardware with the knowledge that you are screwed when it comes to Power
Management.

Unless there are more cases like this, this should not factor at all
into the modifications to the PCI and PM code...

-- 
Jeff Garzik  | The difference between America and England is that
Building 1024| the English think 100 miles is a long distance and
MandrakeSoft | the Americans think 100 years is a long time.
 |  (random fortune)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [repost] Announce: Linux-OpenLVM mailing list

2001-04-20 Thread Doug McNaught

Miles Lane [EMAIL PROTECTED] writes:

 Gosh, this seems like a bit of a red herring, IMHO.  Do you think the
 LKML gets a "lot" of spam?  Or, how about the linux-usb-devel or
 linux-hotplug-devel lists?  None of these lists are moderated and the
 occasional spam gets sent to them, but I haven't noticed there being
 enough spam to hinder the usefulness of these lists.

That's partly because davem and Matti are rabid anti-spam weasels and
very good at it.  ;)  There are all kinds of filters (including
content-based ones) on l-k, otherwise we'd be inundated in processed
pork... 

-Doug
-- 
The rain man gave me two cures; he said jump right in,
The first was Texas medicine--the second was just railroad gin,
And like a fool I mixed them, and it strangled up my mind,
Now people just get uglier, and I got no sense of time...  --Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



problem of partitioning,continued

2001-04-20 Thread Xiong Zhao

hello.one thing i forgot.there are 24 hard disk drives in two scsi channels
made into 3 RAID 5 logical drives on my machine.each consists of 8 drives.
is the way of making the logical drive a maybe factor of the problem?help
is in need greatly.
regards


james 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



is rhl on kernel 2.4?

2001-04-20 Thread Xiong Zhao

fredhat-list red hat linux 7.1 on kernel 2.4?which release?2.4.2 or 2.4.3?
i'v downloaded and compiled a 2.4.3 kernel.i found the version
of header file package is 2.4.0 using rpm -qa|grep kernel.is this
right?where can get linux on 2.4 kernel?
thanks in advance.


xiong zhao

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: PCI power management

2001-04-20 Thread Benjamin Herrenschmidt

 Some devices (bad bad HW designers ;) just can't do it themselves. The
 Rage M3 requires the host to assert PCI RST#, and some motherboards
 provide no documented facility for that (it might be possible with Apple
 ASICs for example, it's just not documented).

Why should we support such a non-spec device?  Tell ATI to fix their
hardware, and tell users (a) not to use the hardware, or (b) use the
hardware with the knowledge that you are screwed when it comes to Power
Management.

Unless there are more cases like this, this should not factor at all
into the modifications to the PCI and PM code...

Well, I can tell all PowerBook and iBook users to forget about sleep...

Also, that would not be the first time we have to deal with poorly
documented hardware. I don't think we should refuse to handle any
hardware that is out of spec... it would be like saying Linux doesn't
support any x86 with a broken BIOS...

It's not so complicated to have the minimum flexibility for the driver
to tell it's maximum supported power level, and I don't see why it would
be a problem to use D2 instead of D3 when we don't support D3 for a given
device (either because the HW is broken, undocumented, or because our
driver just don't know how to bring back the chip to life).

If the motherboard _requires_ it (because it will cut power from the chip),
the we can refuse to enter sleep when one driver can't do it (instead of
letting the user crash the box badly).

In any case, I beleive you are focusing on a point of detail. All
I'm asking for (in this specific case) is a simple mask of flags set
by the driver to tell what it can handle. It's also useful for
devices that don't support PM on machines whose motherboard provide
facility to turn OFF power on selected cards. It would allow us to
turn off cards for drivers that can handle recovering. 

Also, I don't think the problem of powering back up the chip and
re-initing it from scratch is specific to those ATI chips. Look at
XFree, it has to run a BIOS emulator to soft boot video chips. On
PCs, I beleive you have the BIOS that re-init them when waking up
from an APM or ACPI suspend. On non-PCs when suspend is not handled
by the firmware but directly by the kernel, that's not the case.

Ben.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Dell LAtitude PCMCIA adapter

2001-04-20 Thread Marc Karasek

I have run across a problem with 2.4.3 on my Dell lattitude CPx.  It boots
ok but when it gets to bringing up the pcmcia adapter it gets a spurious
interrupt from the pcmcia socket and then fials to init.  This is the last
problem (apart from NFS.lockd) that I am having.  

If anyone has any insight into this, I am not really up on pcmcia sockets,
etc...  I would appreciate it

Marc Karasek
Sr. Firmware Engineer
iVivity Inc.
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Rocketport device driver for 2.4.3

2001-04-20 Thread Russell Coker

I am working on a VA Linux server machine model 2240 which came with a 
RocketPort serial device.

The first issue is that it doesn't have support for devfs.  I have attached a 
patch to fix this that I believe to be good (I've done the same thing for 
Stallion and Lucent WinModem drivers - it's not overly challenging).

The next problem is that accessing a port number that is greater than the 
maximum that the RockerPort PCI card supports (apparently 32 ports for my 
card) gives a kernel oops.  I have attached the output of ksymoops to this 
message.
The command that triggered this Oops was:
setserial /dev/ttr/99


diff -ru old-linux/drivers/char/rocket.c patched-linux/drivers/char/rocket.c
--- old-linux/drivers/char/rocket.c Sat Mar 31 09:50:44 2001
+++ patched-linux/drivers/char/rocket.c Fri Apr 20 12:38:51 2001
@@ -94,7 +94,15 @@
 #undef ROCKET_DEBUG_WAIT_UNTIL_SENT
 #undef ROCKET_DEBUG_RECEIVE
 #undef ROCKET_DEBUG_HANGUP
-   
+
+#ifdef CONFIG_DEVFS_FS
+#define TTR_DEVICE "ttr/%d"
+#define DEVICE_NAME TTR_DEVICE
+#else
+#define TTR_DEVICE "ttyR%d"
+#define DEVICE_NAME "ttyR"
+#endif
+
 
 /*   CAUTION!  The TIME_STAT Function relies on the Pentium 64 bit
  *register.  For various reasons related to 1.2.13, the test for this
@@ -449,7 +457,7 @@
if (IntMask  DELTA_CD) {   /* CD change  */
 #if (defined(ROCKET_DEBUG_OPEN) || defined(ROCKET_DEBUG_INTR) || \
  defined(ROCKET_DEBUG_HANGUP))
-   printk("ttyR%d CD now %s...", info-line,
+   printk(TTR_DEVICE " CD now %s...", info-line,
   (ChanStatus  CD_ACT) ? "on" : "off");
 #endif
if (!(ChanStatus  CD_ACT) 
@@ -836,7 +844,7 @@
retval = 0;
add_wait_queue(info-open_wait, wait);
 #ifdef ROCKET_DEBUG_OPEN
-   printk("block_til_ready before block: ttyR%d, count = %d\n",
+   printk("block_til_ready before block: " TTR_DEVICE ", count = %d\n",
   info-line, info-count);
 #endif
save_flags(flags); cli();
@@ -871,7 +879,7 @@
break;
}
 #ifdef ROCKET_DEBUG_OPEN
-   printk("block_til_ready blocking: ttyR%d, count = %d, flags=0x%0x\n",
+   printk("block_til_ready blocking: " TTR_DEVICE ", count = %d, 
flags=0x%0x\n",
   info-line, info-count, info-flags);
 #endif
schedule();
@@ -884,7 +892,7 @@
restore_flags(flags);
info-blocked_open--;
 #ifdef ROCKET_DEBUG_OPEN
-   printk("block_til_ready after blocking: ttyR%d, count = %d\n",
+   printk("block_til_ready after blocking: " TTR_DEVICE ", count = %d\n",
   info-line, info-count);
 #endif
if (retval)
@@ -964,7 +972,7 @@
 #endif
}
 #ifdef ROCKET_DEBUG_OPEN
-   printk("rp_open ttyR%d, count=%d\n", info-line, info-count);
+   printk("rp_open " TTR_DEVICE ", count=%d\n", info-line, info-count);
 #endif
/*
 * Info-count is now 1; so it's safe to sleep now.
@@ -1050,7 +1058,7 @@
return;
 
 #ifdef ROCKET_DEBUG_OPEN
-   printk("rp_close ttyR%d, count = %d\n", info-line, info-count);
+   printk("rp_close " TTR_DEVICE ", count = %d\n", info-line, info-count);
 #endif

save_flags(flags); cli();
@@ -1072,7 +1080,7 @@
info-count = 1;
}
if (--info-count  0) {
-   printk("rp_close: bad serial port count for ttyR%d: %d\n",
+   printk("rp_close: bad serial port count for " TTR_DEVICE ": %d\n",
   info-line, info-count);
info-count = 0;
}
@@ -1166,7 +1174,7 @@
restore_flags(flags);

 #ifdef ROCKET_DEBUG_OPEN
-   printk("rp_close ttyR%d complete shutdown\n", info-line);
+   printk("rp_close " TTR_DEVICE " complete shutdown\n", info-line);
 #endif

 }
@@ -1646,7 +1654,7 @@
return;
 
 #if (defined(ROCKET_DEBUG_OPEN) || defined(ROCKET_DEBUG_HANGUP))
-   printk("rp_hangup of ttyR%d...", info-line);
+   printk("rp_hangup of " TTR_DEVICE "...", info-line);
 #endif
/*
 * If the port is in the process of being closed, just force
@@ -2193,7 +2201,7 @@
 */
memset(rocket_driver, 0, sizeof(struct tty_driver));
rocket_driver.magic = TTY_DRIVER_MAGIC;
-   rocket_driver.name = "ttyR";
+   rocket_driver.name = DEVICE_NAME;
rocket_driver.major = TTY_ROCKET_MAJOR;
rocket_driver.minor_start = 0;
rocket_driver.num = MAX_RP_PORTS;
@@ -2235,7 +2243,11 @@
 * the minor number and the subtype code.
 */
callout_driver = rocket_driver;
+#ifdef CONFIG_DEVFS_FS
+   callout_driver.name = "cur/%d";
+#else
callout_driver.name = "cur";
+#endif
callout_driver.major = CUA_ROCKET_MAJOR;
callout_driver.minor_start = 0;
callout_driver.subtype = SERIAL_TYPE_CALLOUT;


-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark

Re: RFC: pageable kernel-segments

2001-04-20 Thread Stephen C. Tweedie

Hi,

On Tue, Apr 17, 2001 at 12:21:17PM -0700, H. Peter Anvin wrote:

  Certain parts of drivers could get the __pageable prefix or so
  (like the __init parts of drivers which get removed) for letting
  the paging-code know that it can be discared if memory-pressure
  demands it.
 
 VMS does this.  It at least used to have a great tendency to crash
 itself, because it swapped out something that was called from a driver
 that was called by the swapper -- resulting in deadlock.  You need
 iron discipline for this to work right in all circumstances.

Actually, VMS doesn't do this, precisely because it is so hard to get
right.  VMS has both paged and non-paged pools for dynamically
allocated kernel memory, but the kernel code itself is non-pageable.  

The big problem with such pageable memory isn't really device driver
deadlocks --- the easy rule which makes that work is simply never to
use paged pool from a driver which might be involved in swapping. :)
Even more tricky is the handling of kernel locking --- you cannot
access any paged memory with a spinlock held unless you have pinned
the pages in core beforehand.

--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread Eric S. Raymond

Alan Cox [EMAIL PROTECTED]:
  What is the right procedure for doing changes like this?  Is "don't
  touch that tree" a permanent condition, or am I going to get a chance
  to clean up the global CONFIG_ namespace after your next merge-down?
 
 Feeding arch related stuff to the architecture maintainers.

I shall attempt it.

  That's the main thing I'm after right now -- I want to cut down on
  the false positives in my orphaned-symbol reports so that the actual
  bugs will stand out.
 
 Teach it to read a 'symbolstoignore' file.

Someone else has already pointed out that this is not a solution that will
scale well.  It would substitute a continuing management headache for the
cleanup that's really needed.  In fact I'm reluctant to do this even for 
cases where it's clearly legitimate (CONFIG_BOOM, CONFIG_BOGUS :-)) partly
because later on it might provide an excuse for people not to do the cleanup.

 Part of the problem you are hitting right now is that most
 architectures are not yet fully in sync with 2.4 nor likely to all
 be for another few iterations.

Understood.  I'll do what I can in the architecture-independent code, then.
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

"Boys who own legal firearms have much lower rates of delinquency and
drug use and are even slightly less delinquent than nonowners of guns."
-- U.S. Department of Justice, National Institute of
   Justice, Office of Juvenile Justice and Delinquency Prevention,
   NCJ-143454, "Urban Delinquency and Substance Abuse," August 1995.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread Alan Cox

 What is the right procedure for doing changes like this?  Is "don't
 touch that tree" a permanent condition, or am I going to get a chance
 to clean up the global CONFIG_ namespace after your next merge-down?

Feeding arch related stuff to the architecture maintainers.

 That's the main thing I'm after right now -- I want to cut down on
 the false positives in my orphaned-symbol reports so that the actual
 bugs will stand out.

Teach it to read a 'symbolstoignore' file.

Part of the problem you are hitting right now is that most architectures are
not yet fully in sync with 2.4 nor likely to all be for another few iterations.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread Alan Cox

  we sent him every single one of those patches individually.  and we'd
  go insane trying to keep up with what he'd taken and what he'd dropped.
  
  until you've actually tried doing this, please don't attempt to criticise.
 
 Have _you_ tried? If I recall correctly, Linus spoke out against the

I have for one. Its definitely the wrong approach to bomb Linus with patches
when doing the merge of an architecture. All the architecture folk with in
their own trees for good reason.

Once the code is in a fit state to merge (ie actually works well with the new
2.4.x stuff and 2.4.x core stops shifting around) then the merge can get done
piece by piece.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Linux 2.4.3 Compile Errors - Power Mac

2001-04-20 Thread tom_gall

Jeff Galloway wrote:
 
 Sorry, Tom about the word doc faux pas.  I've set out my problem in plain
 text below.  I got my source from ftp.kernel.org.

Hi Jeff,

  Well that's problem #1. Source from kernel.org for 2.4 tends to not work on
PPC as it has been lagging on important patches and such. We're hoping to get
kernel.org caught up ASAP.

  Visit here to get the up to date and sometime bleeding edge source for PPC.

  http://www.fsmlabs.com/linuxppcbk.html

 Here's my problem:
 
 Problem in compiling linux 2.4.3
 
 Compile error message:
 
 After the compiler message:
 
 gcc D__KERNEL__ -I/home/jeff/kernel/linux/include Wall
 Wstrict-prototypes O2 fomit-frame-pointer fno-strict-aliasing
 D__powerpc__ -fsigned-char msoft-float pipe ffixed-r2 Wno-uninitialized
 mmultiple mstring-c o fork.o fork.c
 
 Compiler error message:
 
 fork.c: In function ?copy_mm:
 fork.c:353: fixed or forbidden register 68 (0) was spilled for class
 CR0_REGS.
 This may be due to a compiler bug or to impossible asm statements or
 clauses.

Which version of gcc do you have? You want either 2.95.2 or 2.95.3



 cpp: output pipe has been closed
 make[2]: *** [fork.o] Error 1
 make[2]: Leaving directory ?/home/jeff/kernel/linux/kernel
 make[1]: *** [first_rule] Error 2
 make[1]: Leaving directory ?/home/jeff/kernel/linux/kernel
 make: *** [_dir_kernel] Error 2
 
 Compiling on Power Mac 7600, with dual processor (604e/180) installed,
 running kernel 2.2.18 compiled by Jeff Galloway, but otherwise a Yellow Dog
 distribution.

Ah YDL ... good stuff. Hope you are on 1.2 at least. 8-)

Regards,

Tom

-- 
Tom Gall - PowerPC Linux Team"Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://oss.software.ibm.com/developerworks/opensource/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread Eric S. Raymond

Alan Cox [EMAIL PROTECTED]:
 I have for one. Its definitely the wrong approach to bomb Linus with patches
 when doing the merge of an architecture. All the architecture folk with in
 their own trees for good reason.

On the other hand, Linus has objected to the One-Big-Patch approach in
the past with respect to things like the networking and VM code.  How
are people to know what the right thing is?
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

Love your country, but never trust its government.
-- Robert A. Heinlein.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: RFC: pageable kernel-segments

2001-04-20 Thread Disconnect

On Tue, 17 Apr 2001, Oliver Neukum did have cause to say:

  load/init/etc.  Hardware setup tends to only happen once..)
 
 No they can't. Modules can't be finegrained enough to do this without wasting 
 more memory due to fragmentation than you'd gain.

Actually, don't they do this -already-?  I thought I saw somewhere on here
recently that there was a class of functions you could use in a module for
'one-off' activities.  I suspect that covers 90% of what could be paged
out (the remainder being mostly the unloading process, for non-hotswap
modules).  But IANAKG. (..not a kernel guru).

 Actually not that great.Support for different types of kernel code is there 
 to support __init and __initdata. You'd use a fixup scheme like the one used 
 in copy_[to|from]_user to trigger paging in. Page out could be handled by the 
 conventional mm.

I mis-typed - by 'major rewrite' I meant more an analysis and tagging
process, which would have to touch most of the kernel before it was
useful. But again, IANAKG so the existing swap code may already handle
that, at least in a way that it could be a ruleset (with override tags?)
instead of having to put a new set of tags everywhere.

---
-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a--? C$ ULBS*$ P L+ 
E--- W+++ N+@ o+$ K? w---+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Kernel panics on raw I/O stress test

2001-04-20 Thread Andrea Arcangeli

On Fri, Apr 20, 2001 at 08:44:35PM +0900, Takanori Kawano wrote:
 
  Could you try again with 2.4.4pre4 plus the below patch?
  
  
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre2/rawio-3
 
 I suppose that 2.4.4-pre4 + rawio-3 patch still has SMP-unsafe
 raw i/o code and can cause the same panic I reported.

I just fixed that as well last week and 2.4.4-pre4 + rawio-3 should be just SMP
safe, faster and my patch is racommended for integration.

 I think the following scenario is possible if there are 3 or more CPUs.
 
 (1) CPU0 enter rw_raw_dev()
 (2) CPU0 execute alloc_kiovec(1, iobuf)// drivers/char/raw.c line 309
 (3) CPU0 enter brw_kiovec(rw, 1, iobuf,..) // drivers/char/raw.c line 362
 (4) CPU0 enter __wait_on_buffer()

With my patch applied the kernel doesn't execute wait_on_buffer from wait_kio
here, it first executes kiobuf_wait_for_io and that is also a performance
optimization because kiobuf_wait_for_io will sleep only once and it will
get only 1 wakeup once the whole kiobuf I/O completed.

 (5) CPU0 execute run_task_queue() and wait
 while buffer_locked(bh) is true.// fs/buffer.c line 152-158
 (6) CPU1 enter end_buffer_io_kiobuf() with
  iobuf allocated at (2)
 (7) CPU1 execute unlock_buffer()// fs/buffer.c line 1994
 (8) CPU0 exit __wait_on_buffer()
 (9) CPU0 exit brw_kiovec(rw, 1, iobuf,..)
 (10) CPU0 execute free_kiovec(1, iobuf) // drivers/char/raw.c line 388
 (11) The task on CPU2 reused the area freed
  at (10).
 (12) CPU1 enter end_kio_request() and touch
  the corrupted iobuf, then panic.

The end_kio_request in CPU1 with my patch applied is executed before CPU0 can
execute wait_kio so it cannot race the above way.

Thanks for your comments (and yes you are right that the above race can happen
in all 2.4 kernels out there except in the aa latest ones).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread Eric S. Raymond

Alan Cox [EMAIL PROTECTED]:
  Alan Cox [EMAIL PROTECTED]:
   I have for one. Its definitely the wrong approach to bomb Linus
   with patches when doing the merge of an architecture. All the
   architecture folk with in their own trees for good reason.
  
  On the other hand, Linus has objected to the One-Big-Patch approach in
  the past with respect to things like the networking and VM code.  How
  are people to know what the right thing is?
 
 Who said anything about one big patch ?  Just because you have a lot
 of differences doesnt mean you send Linus one giant splat of code. I
 don't send Linus -ac for example.

OK, so maybe I'm being stupid.  But the implication of this talk of separate
port trees and architecture merges is that these guys periodically send big
resync patches to you and Linus.

If that's not what's going on, what is?
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

Never could an increase of comfort or security be a sufficient good to be
bought at the price of liberty.
-- Hillaire Belloc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread Alan Cox

 Alan Cox [EMAIL PROTECTED]:
  I have for one. Its definitely the wrong approach to bomb Linus with patches
  when doing the merge of an architecture. All the architecture folk with in
  their own trees for good reason.
 
 On the other hand, Linus has objected to the One-Big-Patch approach in
 the past with respect to things like the networking and VM code.  How
 are people to know what the right thing is?

Who said anything about one big patch ?

Just because you have a lot of differences doesnt mean you send Linus one giant
splat of code. I don't send Linus -ac for example.

Alan



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread Alan Cox

 OK, so maybe I'm being stupid.  But the implication of this talk of separate
 port trees and architecture merges is that these guys periodically send big
 resync patches to you and Linus.
 
 If that's not what's going on, what is?

People send batches of small fixes to Linus or to me. So for example the S/390
folks send me things like 'fix the mm layer to match the changes in 2.4.3'
and 'Update the DASD storage driver'. Each of which fixes one thing or one
set of things and is easy to check on its own

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: epic100 error

2001-04-20 Thread Stefan Jaschke

On Friday 20 April 2001 12:25, Francois Romieu wrote:
 What happen's if you compile 2.4.2 epic100 driver in a 2.4.3 tree (I) ?
 I would really appreciate if you could give a look at (I).

I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles and works 
without 
problems. 
This gives me a workable solution :-)

Cheers,
Stefan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: epic100 error

2001-04-20 Thread Arnaldo Carvalho de Melo

Em Fri, Apr 20, 2001 at 02:07:11PM +0200, Stefan Jaschke escreveu:
 offtopic
 'A message that you sent could not be delivered to one or more of its
 recipients. This is a permanent error. The following address(es) failed:
   [EMAIL PROTECTED]:
 unrouteable mail domain "skyld.com"'
 /offtopic

s/skyld/scyld/g

- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: light weight user level semaphores

2001-04-20 Thread Jesse Pollard

Olaf Titz [EMAIL PROTECTED]:
  Ehh.. I will bet you $10 USD that if libc allocates the next file
  descriptor on the first "malloc()" in user space (in order to use the
  semaphores for mm protection), programs _will_ break.
 
 Of course, but this is a result from sloppy coding. In general, open()
 can just return anything and about the only case where you can even
 think of ignoring its result is this:
  close(0); close(1); close(2);
  open("/dev/null", O_RDWR); dup(0); dup(0);
 (which is even not clean for other reasons).
 
 I can't imagine depending on the "fact" that the first fd I open is 3,
 the next is 4, etc. And what if the routine in question is not
 malloc() but e.g. getpwuid()? Both are just arbitrary library
 functions, and one of them clearly does open file descriptors,
 depending on their implementation.
 
 What would the reason[1] be for wanting contiguous fd space anyway?
 
 Olaf
 
 [1] apart from not having understood how poll() works of course.

Optimization use in select: If all "interesting" file id's are known
to be below "n", then only the first "n" bits in a FD_ISSET need to
be examined. As soon as the bits are scattered, it takes MUCH longer
to check for activity

It may not be the "best" way, but what I tend to do is:

 Umm - this is snipped from a multiplexed logger using FIFOs for
 and indeterminate amount of data from differet utilities sending
 text buffers (normally one line at a time but could be more).

static void fd_init(argc,argv)
int argc;   /* number of parameters */
char**argv; /* parameter list   */
{
int i,j;/* scratch counters */
static char str[50];

pnames = argv;
FD_ZERO(in_files); /* init all file descriptor sets*/

for (i = 0; i = MAX_LOG  i  argc; i++) {
sprintf(str,"/tmp/%s",pnames[i]);
mkfifo(str,0600);   /* assume it exists */
inlogfd[i] = open(str,O_RDONLY | O_NDELAY);
FD_SET(inlogfd[i],in_files);
}
used = i;
}


Then I can scan for any activity by:

do {
while (select(MAX_LOG,active,NULL,NULL,NULL) = 0) {
for(i = 0; i = used; i++) {
if (FD_ISSET(inlogfd[i],active)) {
r=ioctl(inlogfd[i],FIONREAD,n);
while (n  0) {
r = (n  BUF_MAX - 1) ? BUF_MAX - 1: n;
read(inlogfd[i],buf,r);
printbuf(pnames[i],r);
n -= r;
}
}
}
active = in_files;
}
} while (errno == EINTR);

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread Eric S. Raymond

Alan Cox [EMAIL PROTECTED]:
 People send batches of small fixes to Linus or to me. So for example
 the S/390 folks send me things like 'fix the mm layer to match the
 changes in 2.4.3' and 'Update the DASD storage driver'. Each of
 which fixes one thing or one set of things and is easy to check on
 its own

I'll continue asking stupid questions, then.  Like, under this system how
can either you or the port maintainers maintain a good representation of 
how far out of sync they are with the main tree?

The implied workflow (developers in general, up to port maintainers,
up to you and Linus) makes both technological and sociological sense.
It kind of reminds me of Anglo-Norman feudalism post-1066 ("No lord
without land, no land without a lord.").

There are a couple of funny edge cases that it doesn't seem to handle
well, though.  One is the kind I'm bumping into right now, where
somebody legitimately needs to make small (almost trivial) changes
scattered all through the tree.

Another is the case where a piece of code that needs to be changed doesn't
have an active maintainer for a third party like me to go to.

What's the neighborly way to deal with these?
-- 
a href="http://www.tuxedo.org/~esr/"Eric S. Raymond/a

"The best we can hope for concerning the people at large is that they be
properly armed."
-- Alexander Hamilton, The Federalist Papers at 184-188
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: RFC: pageable kernel-segments

2001-04-20 Thread Venkatesh Ramamurthy

  VMS does this.  It at least used to have a great tendency to crash
  itself, because it swapped out something that was called from a driver
  that was called by the swapper -- resulting in deadlock.  You need
  iron discipline for this to work right in all circumstances.

 Actually, VMS doesn't do this, precisely because it is so hard to get
 right.  VMS has both paged and non-paged pools for dynamically
 allocated kernel memory, but the kernel code itself is non-pageable.

[Venkat] This [pageable drivers] has been a nightware for NT (derived from
VMS) driver programmers. It almost divides the set of kernel API into two
halves, one which can be called at any IRQL and the other only at elevated
irql. The benefits of having pageable kernel pages is very minimal when
compared to the complexity that gets added to the kernel. We can keep the
kernel simpler(and faster) without having parts of drivers pageable. But one
more issue is having the page tables pageable...




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: is rhl on kernel 2.4?

2001-04-20 Thread John Jasen

On Fri, 20 Apr 2001, Xiong Zhao wrote:

 fredhat-list red hat linux 7.1 on kernel 2.4?which release?2.4.2 or 2.4.3?
 i'v downloaded and compiled a 2.4.3 kernel.i found the version
 of header file package is 2.4.0 using rpm -qa|grep kernel.is this
 right?where can get linux on 2.4 kernel?
 thanks in advance.

2.4.2-ac3, with about a 120 patches to it.

If you're really interested, I'll email you the spec file.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: epic100 error

2001-04-20 Thread Francois Romieu

Stefan Jaschke [EMAIL PROTECTED] ecrit :
[...]
 I copied epic100.c from 2.4.2 into the 2.4.4-pre4 tree and it compiles and works 
without 
 problems. 
 This gives me a workable solution :-)

Thanks for the info. 
Now, why do you get so much Receive Queue Empty indications...

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?

2001-04-20 Thread Alan Cox

 I'll continue asking stupid questions, then.  Like, under this system how
 can either you or the port maintainers maintain a good representation of 
 how far out of sync they are with the main tree?

diff and read the output.

[bizzare sociopolitical mumble deleted]

 well, though.  One is the kind I'm bumping into right now, where
 somebody legitimately needs to make small (almost trivial) changes
 scattered all through the tree.

Yep. But such changes are rare. Or should be. 

 Another is the case where a piece of code that needs to be changed doesn't
 have an active maintainer for a third party like me to go to.
 What's the neighborly way to deal with these?

If I get patches for stuff that doesnt seem to have a maintainer I apply them.
On the odd occasion a scream is heard in the distance it means I now know
there is an active maintainer.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: RFC: pageable kernel-segments

2001-04-20 Thread Alan Cox

 compared to the complexity that gets added to the kernel. We can keep the
 kernel simpler(and faster) without having parts of drivers pageable. But one
 more issue is having the page tables pageable...

At the moment we can almost go a stage further - when we are short of memory
we can victimise apparently idle page tables by simply deleting them. What
stops us from doing this right now is handling anonymous pages where the
page table really is needed to find the swap entries.

There is a proposal (several it seems) to make 2.5 replace the conventional
unix swap with a filesystem of backing store for anonymous objects. That will
mean each object has its own vm area and inode and thus we can start blowing
away all user mode page tables when we want.

The primary reason for it however is to simplify all the code paths that deal
with swap. All the readahead becomes common code. Swap files become loopback
mounts. We can support multiple swap implementations (just pick your swap fs).
It also lays the groundwork for doing swap using spare disk space.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Children first in fork

2001-04-20 Thread Mark Kettenis

The behaviour of CLONE_PTRACE in Linux 2.4.x is different from the
behaviour in 2.2.x.  Linus is describing the 2.4.x. behaviour, where
the program that's doing the tracing will get the events instead of
the "real" parent.  I believe the 2.2.x behaviour was pretty much
useless, and IIRC that was the reason that Linus accepted a patch for
the new behaviour.  I've tested CLONE_PTRACE in the sense that the
development version of GDB contains some code that allows debugging of
any clone() based thread stuff if the threads implementationion
specifies CLONE_PTRACE in its clone() calls.  That way GDB notices new
threads automagically.  It only works on Linux 2.4.x of course, and I
still have to hack something up to make this functionality in GDB
available to the user.

Mark
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



  1   2   3   >