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

[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)

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

[PATCH] update drivers/input/keybdev.c

[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 
 
 #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: [Ext2-devel] ext2 inode size (on-disk)

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

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

[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: Dead symbol elimination, stage 1

[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]) 
-
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)

[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: [2.4.3] PPP errors

[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: Allocated swap space versus used swap space

[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: Linux 2.4.3 Compile Errors - Power Mac

[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
# CONFI

Re: Linux 2.4.3 Compile Errors - Power Mac

[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
CO

Allocated swap space versus used swap space

[Marcelo Tosatti]

Hi, 



-
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] 2.4.3-ac{6,7} LVM hang

[Arjan Filius]

Hello Jens,

Yes this fixes it.

I'm running 2.4.4-pre4 with only your patch applied.

Greatings,


On Thu, 19 Apr 2001, Jens Axboe wrote:

> On Thu, Apr 19 2001, Arjan Filius wrote:
> > Hello,
> >
> > Same here as reported.
> > restoring lvm.c from 2.4.3 into 2.4.4-pre? "fixes" this. (tested not ac's
> > kernel)
>
> Does attached patch fix it?
>
>

-- 
Arjan Filius
mailto:[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)

[Ion Badulescu]

On Thu, 19 Apr 2001, Roberto Nibali wrote:

> A 2.2.x UP-APIC patch would maybe improve things here while under
> heavy load. I'm using such boxes as packetfilters. All quadboards
> get IRQ 11 which is rather nasty considering a possible throughput
> of 40Mbit/s per NIC.

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

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.

> Would be nice if I could fix the "early initialization ..." problem
> too. I'm still checking the Space.c code:
[snip]

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

> Why isn't it possible to put the "probed" counter into the Space.c for all
> network drivers? So people would not need to care about and the driver
> code would yet be more generic (at least a little bit).

Because, again, this is legacy code. It works, it does the job, that's it. 
All this crap is gone in 2.4.

> Any pointers, sources are welcome and in hope for some further wisdom,

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

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: [Ext2-devel] ext2 inode size (on-disk)

[Andreas Dilger]

Al writes:
> I don't think that it's needed - old kernels (up to -CURRENT ;-) will
> simply refuse to mount if ->s_inode_size != 128. Old utilites may be
> trickier, though...

Probably would need an incompat flag for changing the inode size anyways,
so old utilities wouldn't set that anyways.

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

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.

In the end, it doesn't really matter much - if we go with multiple-of-2
inode sizes, all it means is that we may need to have multiple-of-2 (or
possibly 4 for 512-byte inodes in a 1k block filesystem) inode table
blocks in each group.  Not a big deal.  The code already handles this.

> 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 ;-)

I can write a few words as well.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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?

[Rik van Riel]

On Fri, 20 Apr 2001, Albert D. Cahalan wrote:

> This sucks for users of that architecture. Also, though not
> applicable to PA-RISC, it sucks for sub-architecture porters.
> (by sub-architecture I mean: Mac, PReP, PowerCore, BeBox, etc.)

As you said it so eloquently a few paragraphs down:

"send patches!"

cheers,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

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

-
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 merge issues

[Russell Cattelan]

james rich wrote:

> Hi folks,
> I'm sure many here have read the discussion on lkml about lvm and
> the problems that team is having.  As part of that discussion it was said:

I'm not entirely familiar with the issues surrounding lvm development, I know
things
are not in good shape right now.

But I would say the following statement is unrealistic.
Trying to manage a large software project without source code control is
an even bigger nightmare than with source code control.
patch is NOT a source code control tool.
In fact a good source code control system would allow patch incremental
generation,
This is actually one glaring limitation of CVS, the ability group a set of
changes
together, aka "mod"
(Bitkeeper has addressed a lot of these issues; it can generate or accept
incremental
patch sets)

The lvm problems seems to be more of wetware issue than a source code
control tool issue.

Hopefully XFS will be able to keep ahead the problem of dramatically
diverging
code bases by staying active with Linus's releases.

> Dan Kegel <[EMAIL PROTECTED]>:
> >I know very little about LVM, but from watching earlier projects
> >in the same situation you're in now, the path you need to follow
> >seems clear:
> >   Stop using CVS internally for development.
> >   It makes checking in changes without submitting them to
> >   Linus too easy.
>
> >To get sync'd back up, *start with the standard kernel*,
> >and start generating clean, human-understandable patches one
> >at a time that bring it up to where you want.
>
> I am wondering how the XFS team plans on avoiding the same problems once
> XFS becomes part of the kernel.  Is there potential for problems with SGI
> "losing control" over the source or direction of XFS once Linus puts it in
> his tree?
>
> How does the above comment relate to the XFS team's plans on patches to
> XFS and related areas once XFS is in?
>
> Just want to get these issues into the air before rancor and ill will
> spread...
>
> P.S. XFS has been extremely solid and has saved me a lot of time waiting
> for fscks.  I am really impressed by the professionalism of the XFS team.
> Hopefully I can contribute soon - working on a slackware boot/modules/root
> disk set for XFS.
>
> James Rich
> [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: OK, let's try cleaning up another nit. Is anyone paying attention?

[Albert D. Cahalan]

Matthew Wilcox writes:
> On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:

>> 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.
>
> every single architecture has their own development tree.

This sucks for users of that architecture. Also, though not
applicable to PA-RISC, it sucks for sub-architecture porters.
(by sub-architecture I mean: Mac, PReP, PowerCore, BeBox, etc.)

It's hard enough deciding between Linus and Alan. I'm not at all
happy trying to pick through obscure CVS and BitKeeper trees that
might not be up-to-data with the latest mainstream bug fixes.

> the pa project
> has not been running as long as the other ports, and has a large amount of
> development going on.  i count 28 commits for april (so far), 75 commits
> for march, 187 for february and 112 for january (to the kernel tree, other
> parts of the port also have commit messages).  linus would go insane if
> 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
PowerPC people doing the exact same thing. So unless you get told to
quit annoying him with patches, sending them is the safe bet.

Well here we go. It's about IrDA though, not PowerPC. Read it!
http://lwn.net/2000/1109/a/lt-IrDA.php3

-
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

[Ion Badulescu]

On Thu, 19 Apr 2001, Jeff Garzik wrote:

> I should have gotten off my butt and mentioned this...  I would prefer a
> patch without the 2.2.x compat stuff.  So instead of all that compat
> code, have
>   #include "starfire-2.2.h"
> or similar...
> 
> And then starfire-2.2.h would only exist on 2.2.x.

Hard to please, aren't we. :-)

All right, is this version more pleasant to the eye? It's identical to the 
previous one, but with all the 2.2 ifdef'ed code replaced with an #include 
"starfire-kcomp22.h".

[Now of course starfire-kcomp22.h doesn't exist on 2.4, which -- if you 
stick to your own principles from 2 months ago -- will naturally lead to 
the question, what is this doing in the tree, it's referencing code that 
doesn't exist in the tree, etc, etc. And round and round we go again. :-{

Or maybe not. Hopefully...]

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-ac/drivers/net/starfire.c  Thu Apr 19 15:58:57 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 = 0;
+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 does

Re: BP6: APIC, rtl8139 & sound

[Jeff Garzik]

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: OK, let's try cleaning up another nit. Is anyone paying attention?

[Matthew Wilcox]

On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:
> 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.

every single architecture has their own development tree.  the pa project
has not been running as long as the other ports, and has a large amount of
development going on.  i count 28 commits for april (so far), 75 commits
for march, 187 for february and 112 for january (to the kernel tree, other
parts of the port also have commit messages).  linus would go insane if
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.

-
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

[Steven Cole]

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.

Steven

Here is an alternative patch, against 2.4.3-ac10:

--- linux/MAINTAINERS.ac10  Thu Apr 19 21:54:37 2001
+++ linux/MAINTAINERS   Thu Apr 19 22:00:06 2001
@@ -280,8 +280,10 @@
 S: Maintained
 
 CONFIGURE.HELP
-P: Axel Boldt
-M: [EMAIL PROTECTED]
+P: Eric S. Raymond
+M: Eric S. Raymond <[EMAIL PROTECTED]>
+P: Steven P. Cole
+M: Steven P. Cole <[EMAIL PROTECTED]>
 S: Maintained
 
 COSA/SRP SYNC SERIAL DRIVER
--- linux/Documentation/Configure.help.ac10 Thu Apr 19 22:01:20 2001
+++ linux/Documentation/Configure.help  Thu Apr 19 22:02:58 2001
@@ -1,4 +1,5 @@
-# Maintained by Axel Boldt ([EMAIL PROTECTED])
+# Maintained by Eric S. Raymond <[EMAIL PROTECTED]>
+# and by Steven P. Cole <[EMAIL PROTECTED]>
 #
 # This version of the Linux kernel configuration help texts
 # corresponds to the kernel versions 2.4.x.
-
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/

BP6: APIC, rtl8139 & sound

[Per-Henrik Persson]

Hi,

I'v been lurking around all archives from this list trying to find an
answer to my problem but with no success so I take the step ant mail it to
this list.

My hardware setup is as following:

Abit BP6, 2xCeleron 366, G400, old Matrox-card, sym53c8xx SCSI, Trident
4DWave NX sound, rtl8139 NIC.

lspci: 
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge
(rev 03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:09.0 Multimedia audio controller: Trident Microsystems 4DWave NX (rev
02)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev
10)
00:0d.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c895
(rev 01)
00:0f.0 Display controller: Matrox Graphics, Inc. MGA 2064W [Millennium]
(rev 01)
00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)
00:13.1 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev
03)

cat /proc/interupts: 
   CPU0   CPU1   
  0:  79118  75272IO-APIC-edge  timer
  1:   2261   2358IO-APIC-edge  keyboard
  2:  0  0  XT-PIC  cascade
  8:  0  1IO-APIC-edge  rtc
 12:  33056  32767IO-APIC-edge  PS/2 Mouse
 14:  3 22IO-APIC-edge  ide0
 15:  8 24IO-APIC-edge  ide1
 16:  0  0   IO-APIC-level  mga@PCI:1:0:0
 17:100 94   IO-APIC-level  sym53c8xx
 18:  45894  45820   IO-APIC-level  ide2, eth0
 19:  38881  40110   IO-APIC-level  usb-uhci, Trident 4DWave PCI
NMI:  0  0 
LOC: 154313 154315 
ERR:6994982

I recently made a full reinstall of my Debian-system, from scratch. I also
upgraded to 2.4.3, ALSA for sound. Now I have a lot of problems!

When using my system, not using the NIC, not using sound I get some errors
like: 

APIC error on CPU0: 02(02)
APIC error on CPU1: 01(01)
APIC error on CPU0: 02(02)
APIC error on CPU1: 01(01)

If i start to use the NIC, like som browsing on the internet i occassionly
get:

eth0: Too much work at interrupt, IntrStatus=0x0001.

The number of that kind of messages increases with harder network
traffic. A floodping TO my computer generates like 50 messages...

If I then start to use the sound (playing MP3's) i sometimes get _small_
lockups when X won't respond. If I at the same time generate some activity
on the harddisk connected to IDE2 I get longer lockups. A "cat
/proc/interupts" shows that I get a lot of interupt errors :(

Every now and then i get a lockup for like 10 seconds and as you can see
from my /proc/interupts above I get MILLIONS of interrupt errors! A
"dmesg" will give me an infinite stream of APIC-errors...

Do anyone have a solution for my problem? 

Last but not least, I haven't joined the kernel-list because I have some
troubles with the internet connection to my mailserver. Would it be
possible to CC all answers to [EMAIL PROTECTED] ?

Thanx in advance,

P-H


 
Per-Henrik Persson 0703-68 53 86
[EMAIL PROTECTED] http://www.whatever.nu
   -stupid webcam online 24h a day
"With digital it's all or nothing!"
"Just because something doesn't work, it doesn't mean it can't be used..."


-
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: PNP BIOS and parport_pc - dma found but not used

[Pavel Roskin]

Hello, Gunther!

On Thu, 19 Apr 2001, Gunther Mayer wrote:

> > PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1
>^^ culprit !

For some reason I'm not getting that message anymore. PnPBIOS is in the
kernel, parport_pc is a module. This time I rebooted with the parport_pc
module already installed, as opposed to the first time when I compiled and
inserted it without a reboot.

I'm puzzled. Just in case, it's my .config:
http://www.red-bean.com/~proski/linux/config

Anyway, the result is still the same, just without this message.

> 1) Search for the right two-digit PNP handle for device "0104d041":

this is 01.

>cat /proc/bus/pnb/devices

01  0104d04107:01:000080
02  0105d04107:00:020180
06  0007d04101:02:000003
08  010cd04105:00:000003
09  d04108:00:010003
0a  0001d04108:02:010003
0b  000bd04108:03:010003
0c  0303d04109:00:00000b
0d  040cd0410b:01:000003
0e  0002d04108:01:010003
0f  0008d04108:80:000003
10  030ad04106:04:000003
11  020cd04108:80:ff0003

> 2) Send cat /proc/bus/pnp/01 | od -tx1

000 2a 00 00 22 80 00 47 01 78 03 78 03 00 08 47 01
020 78 07 78 07 00 08 79 00 30 2a 0a 00 22 80 00 47
040 01 bc 03 bc 03 00 03 47 01 bc 07 bc 07 00 03 30
060 2a 0a 00 22 80 00 47 01 78 03 78 03 00 08 47 01
100 78 07 78 07 00 08 30 2a 0a 00 22 20 00 47 01 78
120 02 78 02 00 08 47 01 78 06 78 06 00 08 38 79 00
140 79 00

Settings:
Parallel port mode: ECP+EPP
ECP DMA select: 3

-- 
Regards,
Pavel Roskin

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

[james rich]

On Thu, 19 Apr 2001, Matthew Wilcox wrote:

> On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote:
> > 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?
> 

[snip]

> My preference would be for you to fetch our tree 

> and submit patches to us, which will get to Linus in the fullness of time.

Truly this is not meant to be negative - don't take it as such.

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.

James Rich
[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/

ISDN compile fix for 2.4.4-pre5

[Karsten Keil]

Hi,

seems that somehow isdn.h changes get lost during the merge.
Following patch fix this and some other minor things.
 
-- 
Karsten Keil
SuSE Labs
ISDN development

diff -urN linux-2.4.4p5.org/drivers/isdn/hisax/md5sums.asc 
linux/drivers/isdn/hisax/md5sums.asc
--- linux-2.4.4p5.org/drivers/isdn/hisax/md5sums.ascSun Apr 15 20:36:46 2001
+++ linux/drivers/isdn/hisax/md5sums.ascFri Apr 20 04:50:38 2001
@@ -7,27 +7,27 @@
 # cards in the moment.
 # Read ../../../Documentation/isdn/HiSax.cert for more informations.
 # 
-ca7bd9bac39203f3074f3f093948cc3c  isac.c
-a2ad619fd404b3149099a2984de9d23c  isdnl1.c
-d2a78e407f3d94876deac160c6f9aae6  isdnl2.c
-e7932ca7ae39c497c17f13a2e1434fcd  isdnl3.c
-afb5f2f4ac296d6de45c856993b161e1  tei.c
-00023e2a482cb86a26ea870577ade5d6  callc.c
-a1834e9b2ec068440cff2e899eff4710  cert.c
-1551f78b3cd01097ecd586b5c96d0765  l3dss1.c
-89aecf3a80489c723dc885fcaa4aba1b  l3_1tr6.c
-1685c1ddfecf3e1b88ae5f3d7202ce69  elsa.c
-6d7056d1558bf6cc57dd89b7b260dc27  diva.c
-4398918680d45c4618bb48108ea0c282  sedlbauer.c
+9663cc9f4374c361197d394f6d27c459  isac.c
+9666c672c0fa0e65d5cc5b322f10a18c  isdnl1.c
+9250f15b932dfc36855aa120b896ed0b  isdnl2.c
+0cc2ef892bdb4a2be473e00eb1398950  isdnl3.c
+cac9c32fff889c57ff50d59823053019  tei.c
+665044a72334336533ac79da1a831b17  callc.c
+e592db58630c1f1029cc064110108156  cert.c
+fadeb3b85bb23bc1ac48470c0848d6fa  l3dss1.c
+cf7dec9fac6283716904d26b99188476  l3_1tr6.c
+65d9e5471bc129624f858ebcf0743525  elsa.c
+b4cf8a4dceed9ea6dcba65a85b4eecc7  diva.c
+99e67bea8f6945fa0d4e0aded5bf0fa0  sedlbauer.c
 # end of md5sums
 
 -BEGIN PGP SIGNATURE-
 Version: 2.6.3i
 Charset: noconv
 
-iQCVAwUBOlxeLTpxHvX/mS9tAQH6RwP8DhyvqAnXFV6WIGi16iQ3vKikkPoqnDQs
-GEn5uCW0dPYKlwthD2Grj/JbMYZhOmCFuDxF7ufJnjTSDe/D8XNe2wngxzAiwcIe
-WjCrT8X95cuP3HZHscbFTEinVV0GAnoI0ZEgs5eBDhVHDqILLYMaTFBQaRH3jgXc
-i5VH88jPfUM=
-=qc+J
+iQCVAwUBOt+j/jpxHvX/mS9tAQGXwAP/U4voKzXAcTfo9CqJhHN92GRxunj6mlvn
+H+1pxSe0GdtC7BlrPhrokB5dNSwewk89Z5t7kTD76kx2FFuTcXBJxbgH7LZVF3ga
+JX92bOWQekHMH7Hk12Qc7zpeTmPzY02pvVc37Eo614BCvJMCk02cpQyo8a5wWRKH
+8vpQkQKiSyY=
+=FFLG
 -END PGP SIGNATURE-
diff -urN linux-2.4.4p5.org/include/linux/isdn.h linux/include/linux/isdn.h
--- linux-2.4.4p5.org/include/linux/isdn.h  Fri Apr 20 04:55:51 2001
+++ linux/include/linux/isdn.h  Fri Apr 20 04:50:16 2001
@@ -1,4 +1,4 @@
-/* $Id: isdn.h,v 1.111.6.1 2001/02/07 11:31:31 kai Exp $
+/* $Id: isdn.h,v 1.111.6.5 2001/04/20 02:40:48 keil Exp $
 
  * Main header for the Linux ISDN subsystem (linklevel).
  *
@@ -25,7 +25,9 @@
 #ifndef isdn_h
 #define isdn_h
 
+#ifdef __KERNEL__
 #include 
+#endif
 #include 
 
 #define ISDN_TTY_MAJOR43
@@ -37,8 +39,14 @@
  * the correspondent code in isdn.c
  */
 
+#ifdef USE_MINIMUM_MEM
+/* Save memory */
+#define ISDN_MAX_DRIVERS2
+#define ISDN_MAX_CHANNELS   8
+#else
 #define ISDN_MAX_DRIVERS32
 #define ISDN_MAX_CHANNELS   64
+#endif
 #define ISDN_MINOR_B0
 #define ISDN_MINOR_BMAX (ISDN_MAX_CHANNELS-1)
 #define ISDN_MINOR_CTRL 64
@@ -98,6 +106,12 @@
 
 #define IIOCDRVCTL  _IO('I',128)
 
+/* cisco hdlck device private ioctls */
+#define SIOCGKEEPPERIOD(SIOCDEVPRIVATE + 0)
+#define SIOCSKEEPPERIOD(SIOCDEVPRIVATE + 1)
+#define SIOCGDEBSERINT (SIOCDEVPRIVATE + 2)
+#define SIOCSDEBSERINT (SIOCDEVPRIVATE + 3)
+
 /* Packet encapsulations for net-interfaces */
 #define ISDN_NET_ENCAP_ETHER  0
 #define ISDN_NET_ENCAP_RAWIP  1
@@ -258,9 +272,9 @@
  ((x & ISDN_USAGE_MASK)==ISDN_USAGE_VOICE) )
 
 /* Timer-delays and scheduling-flags */
-#define ISDN_TIMER_RES 3 /* Main Timer-Resolution   */
-#define ISDN_TIMER_02SEC   (HZ/(ISDN_TIMER_RES+1)/5) /* Slow-Timer1 .2 sec  */
-#define ISDN_TIMER_1SEC(HZ/(ISDN_TIMER_RES+1))   /* Slow-Timer2 1 sec   */
+#define ISDN_TIMER_RES 4 /* Main Timer-Resolution   */
+#define ISDN_TIMER_02SEC   (HZ/ISDN_TIMER_RES/5) /* Slow-Timer1 .2 sec  */
+#define ISDN_TIMER_1SEC(HZ/ISDN_TIMER_RES)   /* Slow-Timer2 1 sec   */
 #define ISDN_TIMER_RINGING 5 /* tty RINGs = ISDN_TIMER_1SEC * this factor   */
 #define ISDN_TIMER_KEEPINT10 /* Cisco-Keepalive = ISDN_TIMER_1SEC * this factor */
 #define ISDN_TIMER_MODEMREAD   1
@@ -269,13 +283,11 @@
 #define ISDN_TIMER_MODEMXMIT   8
 #define ISDN_TIMER_NETDIAL16 
 #define ISDN_TIMER_NETHANGUP  32
-#define ISDN_TIMER_KEEPALIVE 128 /* Cisco-Keepalive */
 #define ISDN_TIMER_CARRIER   256 /* Wait for Carrier */
 #define ISDN_TIMER_FAST  (ISDN_TIMER_MODEMREAD | ISDN_TIMER_MODEMPLUS | \
   ISDN_TIMER_MODEMXMIT)
 #define ISDN_TIMER_SLOW  (ISDN_TIMER_MODEMRING | ISDN_TIMER_NETHANGUP | \
-  ISDN_TIMER_NETDIAL | ISDN_TIMER_KEEPALIVE | \
-  ISDN_TIMER_CARRIER)
+  ISDN_TIMER_NETDIAL | ISDN_TIMER_CARRIER)
 
 /* Timeout-Values for i

Re: active after unmount?

[Matthew Jacob]

Double cool then.

> 
> 
> On Thu, 19 Apr 2001, Matthew Jacob wrote:
> 
> > 
> > 'kay, great, thanks.. I'll put it in and see if things show up again
> 
> Guys, it's a known bug, fixed in 2.4.4-pre3. See the change to fs/super.c
> between 2.4.4-pre2 and 2.4.4-pre3 - it's quite small.
> 

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

[Matthew Wilcox]

On Thu, Apr 19, 2001 at 11:00:09PM -0400, Eric S. Raymond wrote:
> 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?

Our current status is that we've got a patch with Alan that's been sitting
in his tree for a while (things got trickier than he expected and he
hasn't been able to merge that upstream to Linus yet).  Meanwhile we've
carried on development as normal.  So even after the patches in Alan's
tree land, we've still got a fair hunk of changes to go in.

My preference would be for you to fetch our tree 

cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs/parisc login
[no password]

cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs/parisc co linux

and submit patches to us, which will get to Linus in the fullness of time.
I'm aware this might not be terribly satisfactory for you, but we're
doing our best not to lose our way amid the churn of development right
now and having patches which haven't followed a progression through
us makes that significantly harder.

> Could I ask you to audit your tree and change the prefix on any 
> CONFIG_ symbols that are private over there?  This would make life 
> easier for my auditing tools (kxref and Stephen Cole's ach script).

I don't think we have any of those.  We certainly have symbols which are
defined for symmetry and may not actually be used yet (CONFIG_PA11 might not
be, perhaps).  But that's what happens when you're developing software :-)

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

kernel patch to Solaris

[news news]

Hi Everyone,

In stead of Linux, I have a question about
doing a kernel patch to SUN's Solaris.


We are working on a project, and it turns out
we might have to modify the I/O's behavior.
Therefore, we are thinking to put in a kernel patch
to the Solaris OS.

Is there anything we need to consider before we
put in the patch such as:

(*) Whether need permission from SUN Microsystem
(*) Whether it would affect the service agreement

I would think many commercial package softwares
have done the same thing.(modify the OS's behavior)
Many thanks for your  input.

Mike.
_
Get your FREE download of MSN Explorer at http://explorer.msn.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: OK, let's try cleaning up another nit. Is anyone paying attention?

[Eric S. Raymond]

Matthew Wilcox <[EMAIL PROTECTED]>:
> On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote:
> > Remove dead CONFIG_BINFMT_JAVA symbol.
> 
> Please don't do this, it just makes merging our patches with Linus harder.

Bother.  I've now heard "don't touch that tree!" from you and the ARM
folks.  I'm trying to be a good neighbor, here, but there is some
cleanup I want to do that crosses port boundaries.  (None of this is CML2,
BTW; I'm now addressing problems that are common to CML1 as well.)

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?

Could I ask you to audit your tree and change the prefix on any 
CONFIG_ symbols that are private over there?  This would make life 
easier for my auditing tools (kxref and Stephen Cole's ach script).

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.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety."
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759.
-
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

[Jordan]

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

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.

Jordan

--- linux_corrupt_cdrom/drivers/cdrom/cdrom.c   Thu Apr 19 19:31:00 2001
+++ linux/drivers/cdrom/cdrom.c Wed Apr 18 01:49:05 2001
@@ -279,9 +279,6 @@
 static int lockdoor = 1;
 /* will we ever get to use this... sigh. */
 static int check_media_type;
-static unsigned long *cdrom_numbers;
-static DECLARE_MUTEX(cdrom_sem);
-
 MODULE_PARM(debug, "i");
 MODULE_PARM(autoclose, "i");
 MODULE_PARM(autoeject, "i");
@@ -343,38 +340,6 @@
check_media_change: cdrom_media_changed,
 };
 
-/*
- * get or clear a new cdrom number, run under cdrom_sem
- */
-static int cdrom_get_entry(void)
-{
-   int i, nr, foo;
-
-   nr = 0;
-   foo = -1;
-   for (i = 0; i < CDROM_MAX_CDROMS / (sizeof(unsigned long) * 8); i++) {
-   if (cdrom_numbers[i] == ~0UL) {
-   nr += sizeof(unsigned long) * 8;
-   continue;
-   }
-   foo = ffz(cdrom_numbers[i]);
-   set_bit(foo, &cdrom_numbers[i]);
-   nr += foo;
-   break;
-   }
-
-   return foo == -1 ? foo : nr;
-}
-
-static void cdrom_clear_entry(struct cdrom_device_info *cdi)
-{
-   int bit_nr = cdi->nr & ~(sizeof(unsigned long) * 8);
-   int cd_index = cdi->nr / (sizeof(unsigned long) * 8);
-
-   clear_bit(bit_nr, &cdrom_numbers[cd_index]);
-}
-
-
 /* This macro makes sure we don't have to check on cdrom_device_ops
  * existence in the run-time routines below. Change_capability is a
  * hack to have the capability flags defined const, while we can still
@@ -389,6 +354,7 @@
 struct cdrom_device_ops *cdo = cdi->ops;
 int *change_capability = (int *)&cdo->capability; /* hack */
char vname[16];
+   static unsigned int cdrom_counter;
 
cdinfo(CD_OPEN, "entering register_cdrom\n"); 
 
@@ -429,17 +395,7 @@
 
if (!devfs_handle)
devfs_handle = devfs_mk_dir (NULL, "cdroms", NULL);
-
-   /*
-* get new cdrom number
-*/
-   down(&cdrom_sem);
-   cdi->nr = cdrom_get_entry();
-   up(&cdrom_sem);
-   if (cdi->nr == -1)
-   return -ENOMEM;
-
-   sprintf(vname, "cdrom%u", cdi->nr);
+   sprintf (vname, "cdrom%u", cdrom_counter++);
if (cdi->de) {
int pos;
devfs_handle_t slave;
@@ -462,13 +418,9 @@
S_IFBLK | S_IRUGO | S_IWUGO,
&cdrom_fops, NULL);
}
-
-   down(&cdrom_sem);
+   cdinfo(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
cdi->next = topCdromPtr;
topCdromPtr = cdi;
-   up(&cdrom_sem);
-
-   cdinfo(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
return 0;
 }
 #undef ENSURE
@@ -477,14 +429,12 @@
 {
struct cdrom_device_info *cdi, *prev;
int major = MAJOR(unreg->dev);
-   int bit_nr, cd_index;
 
cdinfo(CD_OPEN, "entering unregister_cdrom\n"); 
 
if (major < 0 || major >= MAX_BLKDEV)
return -1;
 
-   down(&cdrom_sem);
prev = NULL;
cdi = topCdromPtr;
while (cdi != NULL && cdi->dev != unreg->dev) {
@@ -492,20 +442,14 @@
cdi = cdi->next;
}
 
-   if (cdi == NULL) {
-   up(&cdrom_sem);
+   if (cdi == NULL)
return -2;
-   }
-
-   cdrom_clear_entry(cdi);
-
if (prev)
prev->next = cdi->next;
else
topCdromPtr = cdi->next;
-   up(&cdrom_sem);
cdi->ops->n_minors--;
-   devfs_unregister(cdi->de);
+   devfs_unregister (cdi->de);
cdinfo(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
return 0;
 }
@@ -514,14 +458,10 @@
 {
struct cdrom_device_info *cdi;
 
-   down(&cdrom_sem);
-
cdi = topCdromPtr;
while (cdi != NULL && cdi->dev != dev)
cdi = cdi->next;
 
-   up(&cdrom_sem);
-
return cdi;
 }
 
@@ -2489,8 +2429,6 @@
}
 
pos = sprintf(info, "CD-ROM information, " VERSION "\n");
-
-   down(&cdrom_sem);

pos += sprintf(info+pos, "\ndrive name:\t");
for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi-

Re: IP Acounting Idea for 2.5

[Ton Hospel]

In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> writes:
>> > No he isnt confused, you are trying to dictate policy.
>> 
>> What then *is* the policy?
> 
> The policy is not to have policy. It works as well in kernel design as politics.
> 
> Alan
> 
Since my job is in fact mainly this kind of apps, i really feel strongly
about this. 

Resettable counters are evil.

Having resettable counters may not sound like it, but it is in fact policy.
It forces all apps to add code to detect these resets (and then give 
warnings/errors, since there is just no way to do anything sensible with
them), since ignoring them will seemingly cause up to 2**32 counts suddenly.

It is also doing something in kernelspace which can be done in userspace,
which is normally considered a big nono.

Proposal: have a snapshot command, that remembers the current value of a
counter. Then have two interfaces: one that shows the continuous counter
and one that shows the subtraction of the current value from the snapshot.
The first can be used by used by serious applications (don't have to
add code to give warnings about dataloss), and the second can be used by 
users who want to watch the counters a bit to get a feel for what a rule
is doing.

I really think cisco got this right: from the commandline interface
you can reset counters, and watch them, the SNMP counters however just
keep going and going and going independently from this.

(I think this snapshotting belongs in the apps reading the counters
really, but if you really insist on a kernel based reset, this might be
reasonable).
-
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:

[Francois Cami]

Vibol Hou wrote:
> 
> Hi,
> 
> I'm using 2.4.4-pre3 and get this message occasionally when the system is
> loaded:
> 
> Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401.
> Apr 17 16:10:12 omega kernel: eth0: Too much work in interrupt, status e401.

I got that one too, PC is ASUS P2B-DS with two PII-350, 384MB RAM,
3C905B.
I've tried 3C905C to no avail.
The e401 status seems to be that there is too much load on the card to
be treated in the 20 (2.2.17) or 32 (2.2.19, 2.4.x) loops of the
interruption
check routine (stop/hit me if i'm wrong please). 
I think we should try (MM. Donald Becker or Andrew Norton, 
is this a Bad Thing ?) to change max_interrupt_work (3c59x.c, row 171)
to 64
or maybe even higher. Haven't had the guts to try on the production
machine
right now =)

> The nic is a 3Com 3c905B. Is this a bad thing?

I heard they work fine... 

François Cami
There And Back Again
-
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

[Ulrich Drepper]

Alexander Viro <[EMAIL PROTECTED]> writes:

> > If the new interface can be useful for anything it must allow to
> > implement process-shared POSIX mutexes.
> 
> Pardon me the bluntness, but... Why?

Because otherwise there is no reason to even waste a second with this.
At least for me and everybody else who has interest in portable solutions.

I don't care how it's implemented.  Look at the code example I posted.
If you can provide an implementation which can implement anonymous
inter-process mutexes then ring again.  Until then I'll wait.  If you
implement something else I couldn't care less since it's useless for
me.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.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: ac10 ide-cd oopses on boot

[Bill Nottingham]

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

Bill
-
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?

[Matthew Wilcox]

On Thu, Apr 19, 2001 at 18:50:34 EDT, Eric S. Raymond wrote:
> Remove dead CONFIG_BINFMT_JAVA symbol.

Please don't do this, it just makes merging our patches with Linus harder.
This has already been done in our tree since Feb 1.  In fact, please
don't touch anything in the tree which is PA specific; we have a large
arch update pending.

http://puffin.external.hp.com/cvs/linux/arch/parisc/config.in?log=y

shows the current state of our config.in, if you're curious.  If you
have any changes you want to make, don't hesitate to coordinate with us
by mailing [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] ext2 inode size (on-disk)

[Alexander Viro]

On Thu, 19 Apr 2001 [EMAIL PROTECTED] wrote:

> This was a project that was never completed.  I thought at one point
> of allowing the inode size to be not a power of 2, but if you do that,
> you really want to avoid letting an inode cross a block boundary ---
> for reliability and performance reasons if nothing else.   

Agreed.

> In the long run, it probably makes sense to adjust the algorithms to
> allow for non-power-of-two inode sizes, but require an incompatible
> filesystem feature flag (so that older kernels and filesystem
> utilities won't choke when mounting filesystems with non-standard
> sized inodes.

I don't think that it's needed - old kernels (up to -CURRENT ;-) will
simply refuse to mount if ->s_inode_size != 128. Old utilites may be
trickier, though...

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?

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 ;-)
Al

-
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 inode size (on-disk)

[Alexander Viro]

On Thu, 19 Apr 2001, Andreas Dilger wrote:

> Strange, I run "mke2fs -I 192 /dev/hdc2" and do not have a segfault or any
> problems with e2fsck or debugfs on the resulting filesystem.  I'm running
> 1.20-WIP, but I don't think anything was changed in this area for some time.
 
May depend on the libc version/size of device/phase of the moon. I've
got segfaults with 1.18, 1.19 and 1.20-WIP on a Debian box with glibc
2.1.3-18 and 20Mb image. What really happens is memory corruption in
libe2fs (ext2_write_inode()), segfault comes later (usually in free()).

> Basically, packing inodes across block boundaries is TOTALLY broken.
> This can lead to all sorts of data corruption issues if one block is
> written to disk, and the other is not.  For that matter, the same would

Yup.

> PS - is this a code cleanup issue, or do you have some reason that you want
>  to increase the inode size?

Code cleanup
Al

-
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] 2.4.3-ac{6,7} LVM hang

[Rik van Riel]

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.

Waiting for the next official LVM release (and the next set of
bugs) doesn't seem like a very productive way to me ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

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

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

SGI Visual Workstation support?

[He Ding]

Hi,

I tried to compile kernel 2.4.3. with SGI Visual Workstation support
selected.

I got the error as follows:

ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o  drivers/char/agp/agp.o
drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o
drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o
drivers/pcmcia/pcmcia.o drivers/net/pcmcia/pcmcia_net.o drivers/pnp/pnp.o
drivers/video/video.o drivers/usb/usbdrv.o \
net/network.o \
/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a
/usr/src/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
arch/i386/kernel/kernel.o: In function `enable_irq':
arch/i386/kernel/kernel.o(.text+0x3713): undefined reference to
`irq_vector'
arch/i386/kernel/kernel.o: In function `timer_interrupt':
arch/i386/kernel/kernel.o(.text+0x6947): undefined reference to
`smp_found_config'
arch/i386/kernel/kernel.o: In function `disconnect_bsp_APIC':
arch/i386/kernel/kernel.o(.text+0x8aa2): undefined reference to `pic_mode'
arch/i386/kernel/kernel.o: In function `init_VISWS_APIC_irqs':
arch/i386/kernel/kernel.o(.text+0x9177): undefined reference to
`setup_x86_irq'
arch/i386/kernel/kernel.o: In function `pcibios_fixup_irqs':
arch/i386/kernel/kernel.o(.text.init+0x3002): undefined reference to
`visws_get_PCI_irq_vector'
arch/i386/kernel/kernel.o: In function `do_boot_cpu':
arch/i386/kernel/kernel.o(.text.init+0x3966): undefined reference to
`apic_version'
arch/i386/kernel/kernel.o: In function `smp_boot_cpus':
arch/i386/kernel/kernel.o(.text.init+0x3e7b): undefined reference to
`boot_cpu_id'
arch/i386/kernel/kernel.o(.text.init+0x3eb4): undefined reference to
`smp_found_config'
arch/i386/kernel/kernel.o(.text.init+0x3ec7): undefined reference to
`boot_cpu_id'
arch/i386/kernel/kernel.o(.text.init+0x3ece): undefined reference to
`phys_cpu_present_map'
arch/i386/kernel/kernel.o(.text.init+0x3ef9): undefined reference to
`phys_cpu_present_map'
arch/i386/kernel/kernel.o(.text.init+0x3eff): undefined reference to
`boot_cpu_id'
arch/i386/kernel/kernel.o(.text.init+0x3f06): undefined reference to
`apic_version'
arch/i386/kernel/kernel.o(.text.init+0x3f2e): undefined reference to
`phys_cpu_present_map'
arch/i386/kernel/kernel.o(.text.init+0x3f62): undefined reference to
`smp_found_config'
arch/i386/kernel/kernel.o(.text.init+0x3f76): undefined reference to
`phys_cpu_present_map'
arch/i386/kernel/kernel.o(.text.init+0x3fb7): undefined reference to
`boot_cpu_id'
arch/i386/kernel/kernel.o(.text.init+0x3fd7): undefined reference to
`phys_cpu_present_map'
arch/i386/kernel/kernel.o(.text.init+0x3ff2): undefined reference to
`boot_cpu_id'
arch/i386/kernel/kernel.o(.text.init+0x4003): undefined reference to
`phys_cpu_present_map'
arch/i386/kernel/kernel.o(.text.init+0x4037): undefined reference to
`phys_cpu_present_map'
arch/i386/kernel/kernel.o: In function `connect_bsp_APIC':
arch/i386/kernel/kernel.o(.text.init+0x4162): undefined reference to
`pic_mode'
arch/i386/kernel/kernel.o: In function `setup_local_APIC':
arch/i386/kernel/kernel.o(.text.init+0x42a3): undefined reference to
`phys_cpu_present_map'
arch/i386/kernel/kernel.o(.text.init+0x432d): undefined reference to
`pic_mode'
arch/i386/kernel/kernel.o: In function `init_apic_mappings':
arch/i386/kernel/kernel.o(.text.init+0x43fb): undefined reference to
`smp_found_config'
arch/i386/kernel/kernel.o(.text.init+0x4404): undefined reference to
`mp_lapic_addr'
arch/i386/kernel/kernel.o(.text.init+0x4451): undefined reference to
`boot_cpu_id'
arch/i386/kernel/kernel.o(.text.init+0x4464): undefined reference to
`boot_cpu_id'
drivers/pci/driver.o: In function `pci_fixup_device':
drivers/pci/driver.o(.text+0x11a7): undefined reference to
`pcibios_fixups'
make: *** [vmlinux] Error 1


Eric He 
PhD candidate
Electronic Visualization Laboratory
University of Illinois at Chicago 
(312) 996-3002



-
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

[Dan Kegel]

Dear Sistina:

I know very little about LVM, but from watching earlier projects
in the same situation you're in now, the path you need to follow
seems clear:
   Stop using CVS internally for development.
   It makes checking in changes without submitting them to 
   Linus too easy.

To get sync'd back up, *start with the standard kernel*,
and start generating clean, human-understandable patches one 
at a time that bring it up to where you want.

Once you've achieved that, have your programmers generate patches 
rather than checking in to CVS, and feed the patches to Linus 
at the same time you hand them out to your other programmers.
Individual programmers may need to do more testing this way, but
c'est la vie.

This is the only way to achieve union with the standard kernel.

So many projects have failed to learn this lesson...
ignore it at your peril.
- Dan
-
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

[Alexander Viro]

On 19 Apr 2001, Ulrich Drepper wrote:

> Linus Torvalds <[EMAIL PROTECTED]> writes:
> 
> > I'm not interested in re-creating the idiocies of Sys IPC.
> 
> I'm not talking about sysv semaphores (couldn't care less).  And you
> haven't read any of the mails with examples I sent.
> 
> If the new interface can be useful for anything it must allow to
> implement process-shared POSIX mutexes.

Pardon me the bluntness, but... Why?
* on _any_ UNIX we can implement semaphore (object that has Dijkstra's
P and V operations, whatever) shared by processes that have access to pipe.
In a portable way. That's the part of pipe semantics that had been there
since way before v6. Pre-sysv, pre-POSIX, etc. When named pipes appeared
the same semantics had been carried to them. Agreed so far?
* if we have shared memory _and_ some implementation of semaphores
we can (on architectures that allow atomic_dec() and atomic_inc()) produce
semaphores that work via memory access in uncontended case and use slow
semaphores to handle contention side of the business. Nothing UNIX-specific
here.
* such objects _are_ useful. They are reasonably portable and
if they fit the task at hand and are cheaper than POSIX mutexes - that's
all rationale one could need for using them.

Sure, the variant I've posted was intra-process only, simply because it
uses normal pipes. Implementation with named pipes is also trivial -
when you map the shared area, allocate private one of the corresponding
size and keep descriptors there. End of story.

AFAICS mechanism is portable enough (and even on the architectures that
do not allow atomic userland operations we can survive - just fall back
to "slow" ones via read()/write() on pipes).  And excuse me, but when
one writes an application code the question is not "how to make it use
POSIX semaphores", it's "how to get the serialization I need in a
portable way".

-
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

[Paul Jakma]

On Thu, 19 Apr 2001, Andreas Dilger wrote:

> went in, but not other stuff.  Also, it doesn't appear that any of the
> LVM changes are making it into the stock kernel, which is basically a
> recepie for disaster.

agreed... after the problematic inclusion of 0.9 into the kernel i
asked on sistina LVM list whether they could try to be a bit more
proactive about feeding patches on to linus, to make life easier for
LVM users - they had fixes for the problems of 0.9 but never, and
still to this day have not, fed the code on.

Still to this day, nothing from them but announcements on l-k of
various betas. AFAIK all the patches for LVM submitted to linus since
0.8 went in have been from core linux developers (Andrea, Jens,
etc.), not sistina.

shame... their LVM is really nice to use. Just frustrating that they
do want to feed the code on... more frustrating still when you
consider the lobbying that went on to try persuade l-k that LVM
should go in.

> Cheers, Andreas

obHiddenCode: lm-sensors... used to use this a long time ago.

regards,
-- 
Paul Jakma  [EMAIL PROTECTED]   [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
Happiness is twin floppies.

-
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

[Jeff Garzik]

Ion wrote:
> On Thu, 19 Apr 2001 21:14:32 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
> 
> > 2.4.3-ac10
> > o   Merge Linus 2.4.4pre4
> 
> Well, it seems you have backed out my starfire changes when you merged
> Jeff Garzik's changes from 2.4.4pre4. So here's a new version, diff'ed
> against 2.4.3-ac10, which includes all of Jeff's changes from 2.4.3pre[45].
> 
> BTW Jeff, do you want me to send these updates to you instead of Alan,
> diff'ed against 2.4.x-pre_latest? Right now we're just wasting each
> other's time by making conflicting changes to different trees.

I should have gotten off my butt and mentioned this...  I would prefer a
patch without the 2.2.x compat stuff.  So instead of all that compat
code, have
#include "starfire-2.2.h"
or similar...

And then starfire-2.2.h would only exist on 2.2.x.

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

Configure.help maintainer change

[Axel Boldt]

Eric has worked on Configure.help for some time now and I haven't,
so he will take over official maintenance of that file.

The attached patch is against 2.4.3.

Axel

--- linux/MAINTAINERS   Mon Mar 26 04:14:20 2001
+++ linux/MAINTAINERS.new   Fri Apr 20 03:05:23 2001
@@ -273,8 +273,8 @@
 S: Maintained
 
 CONFIGURE.HELP
-P: Axel Boldt
-M: [EMAIL PROTECTED]
+P: Eric S. Raymond
+M: [EMAIL PROTECTED]
 S: Maintained
 
 COSA/SRP SYNC SERIAL DRIVER
--- linux/Documentation/Configure.help  Mon Mar 26 04:24:31 2001
+++ linux/Documentation/Configure.help.new  Fri Apr 20 03:06:50 2001
@@ -1,4 +1,4 @@
-# Maintained by Axel Boldt ([EMAIL PROTECTED])
+# Maintained by Eric S. Raymond ([EMAIL PROTECTED])
 #
 # This version of the Linux kernel configuration help texts
 # corresponds to the kernel versions 2.4.x.

-
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"]]

[Andrea Arcangeli]

On Fri, Apr 20, 2001 at 12:28:09AM +0100, D . W . Howells wrote:
> I benchmarked four different environments:
> 
>   (1) 2.4.4-pre3 + Andrea's generic rwsem patch
>   (2) 2.4.4-pre4 using XADD to implement the rwsems
>   (3) same as (2) but with a tweak to make rwsem_wake() less fair
>   (4) 2.4.4-pre3 using my generic spinlock code to implement the rwsems
> 
> David
> 
> 
> TEST  NUM READERS NUM WRITERS CONTENTION
> ===   === === ==
> rwsem-rw  4   2   r-w & w-w
> rwsem-ro  4   0   no
> rwsem-wo  0   4   w-w only
> rwsem-r1  1   0   no
> rwsem-w1  0   1   no
> rwsem-r2  2   0   no
> 
> 
> ENVIRONMENT   TESTSCHED   READERS WRITERS
> ===   === === === ===
> Linux-2.4.4-pre3 + AA-rwsem   rws-rw  no   33302811009
>3331972 994
[..]
> ---   --- --- --- ---
> Linux-2.4.4-pre4 [GENERIC-SPIN]   rws-rw  no545138  274002
> 545378  273785
>   yes   755343  187874
> 745888  185562

Some explanation on the above extreme difference. In the misc rw benchmark the
reason in the same amount of time I get a total number of down 3332966 and you
get only 819163 is that I provide recursive down_read and that in turn can
starve the down_write (my first patches weren't implementing fair semaphores).

As you can see in my post of yesterday I made my semaphores fair in my last
patches (from rwsem-generic-5). (you didn't said which patch you used exactly
but obviously it was earlier than the -5 revision)

I'm uncertain if I should drop the list_empty() check from the fast path and if
I should still allow up_* to be called from irq/softirq, if I reduce the max
number of sleepers to 2^16 and I will provide weaker wakeup semantics I won't
be penalizied anymore and then we'll really compare apples to orange making the
comparison more interesting (probably I will do because later on I can probably
re-add that two features without too much pain).

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

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: [linux-lvm] 2.4.3-ac{6,7} LVM hang

[Ulrich Drepper]

Jens Axboe <[EMAIL PROTECTED]> writes:

> Does attached patch fix it?

Yes.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.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: Linux 2.4.3-ac10

[Ion Badulescu]

On Thu, 19 Apr 2001 21:14:32 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:

> 2.4.3-ac10
> o   Merge Linus 2.4.4pre4

Well, it seems you have backed out my starfire changes when you merged
Jeff Garzik's changes from 2.4.4pre4. So here's a new version, diff'ed
against 2.4.3-ac10, which includes all of Jeff's changes from 2.4.3pre[45].

BTW Jeff, do you want me to send these updates to you instead of Alan,
diff'ed against 2.4.x-pre_latest? Right now we're just wasting each
other's time by making conflicting changes to different trees.

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-ac/drivers/net/starfire.c  Thu Apr 19 15:58:57 2001
+++ linux-2.4/drivers/net/starfire.cThu Apr 19 17:41:01 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 = 0;
+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
 
 /

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

[Andreas Dilger]

AJ writes:
> 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.

Actually, the whole idea of "trying to get a release out" is part of the
problem.  If patches were included into CVS and sent sent to Linus as they
arrived we wouldn't be in this situation.  My take on this is that holding
back legitimate patches "to get the release out" ends up accumulating so
many changes that it is impossible to sync up later. The Linux kernel is a
successful project because Linus generally accepts everything that is a 
bug fix or code cleanup (features are another matter, but very little if
any of the patches I send you are "features").

> It would be stupid to just add everything that comes in on the ML without
> review.  Linus does the exact same thing.

Yes, it would be stupid to "just accept everything" that is sent to the
mailing list, but really, I've done a pretty good job of submitting patches
in small, self-contained pieces IMHO (even if it happens that I send a lot
of such patches at one time).  I mean the code has to be cleaned up at some
time, so we may as well do it sooner rather than later.

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

Well, I would hope that given the fact I've been working on LVM considerably
longer than anyone else at Sistina (excluding Heinz) that you might just
trust my judgement a bit more.  I'm _trying_ to contribute to LVM, and do
so in easy-to-digest pieces, but given that it is hard to get patches into
CVS, and my codebase is increasingly divergent from your CVS tree.

I have better ways to spend my time than going through 10,000 lines of
diff and guessing which parts are new, and which parts have been held of
"for the next release".  The EVMS code is starting out clean, and I hope
I can help keep it that way.

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

That's because the "release" patches are too huge now.  If it were up to me,
and I've asked you a couple of times on this, I would have already sent a
whole bunch of bug fixes to Linus as small, self-contained patches.  However,
I held back because you asked me not to send patches to Linus directly.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: active after unmount?

[Alexander Viro]

On Thu, 19 Apr 2001, Matthew Jacob wrote:

> 
> 'kay, great, thanks.. I'll put it in and see if things show up again

Guys, it's a known bug, fixed in 2.4.4-pre3. See the change to fs/super.c
between 2.4.4-pre2 and 2.4.4-pre3 - it's quite small.

-
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

[J . A . Magallon]

On 04.20 Udo A. Steinberg wrote:
> Alan Cox wrote:
> > 
> > > Just built 2.4.3-ac10 and got an oops when booting. It tries to detect
> > > the CD and gives the oops.
> 
> I'm getting a similar oops with -ac10. I initially thought this might be
> a result of switching to gcc-2.95.3, because -ac9 runs fine when built
> with gcc-2.95.2, but if others have seen this too, it's probably the
> cdrom code indeed.
> 

Mine is built with gcc-2.96-0.48mdk.

--
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.3-ac9 #1 SMP Wed Apr 18 10:35:48 CEST 2001 i686

-
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

[Patrick Mochel]

>  - There need to be some arch "hooks" in this mecanism. Some machines
> have the ability (from the arch specific code, by tweaking ASIC bits)
> to remove clock and/or power from selected devices. That mean power
> management can be done even with devices not supporting PCI PM provided
> that the driver can recover them from a PowerOn reset.

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.

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

>  - The current scheme provide no way for the kernel to "know" if a
> driver can handle recovering the device from a PowerOn reset. Some
> drivers can, some can't (the video drivers usually can't as they
> require the board's PLL to be properly setup by the BIOS). Some
> advanced PM modes we use on pmacs will cause the motherboard ASIC to
> turn off power to PCI & AGP cards when putting the machine to sleep.
> We need a way to prevent/allow this "deep sleep" mode depending
> on what the card supports.

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. 

>  - Ordering of power management may matter. On PowerBooks, we run
> through all notifiers first with a "sleep request" message. None of
> the drivers will actually put anything to sleep at this point, but
> they will allocate all the memory the might need for doing so (saving
> state, saving a framebuffer in some cases, etc...). Once all devices
> have accepted the request (they can refuse it), I then send a 
> "sleep now" message. This way, I can make sure all memory allocations
> have been performed and disks properly sync'ed before putting the swap
> devices to sleep and such things. 

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.

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

>  - We need a generic (non-x86 APM or ACPI dependant) way of including
> userland process that request it in the loop. Some userland process
> that bang hardware directly (X, but not only X) need to be properly
> suspended (and the kernel has to wait for ack from them before continuing
> with devices sleep).

Hmm. Like init?

> Yup. They should also be able to return an error (fail or just limit
> to a higher level like D2). They should also be able to tell the kernel
> if they support recovering from a power down.

Another sleep level is not acceptable when entering a system sleep state,
except for S2, but I've never seen a system that supports that. Power will
be cut to all devices, and there is no getting around it. If the driver
can't support reinitializing the device, it should return an error and the
sleep request be cancelled.

The PCI PM Capabilities can be read from a device's config space. The PCI
PM Spec has register descriptions. There are also #defines for the fields
in pci.h. So a driver can know exactly what is expected of it.

> >It is up to the drivers to implement ::suspend() and ::resume(), and few
> >do.  The few that do, even fewer work well in practice.
> 
> I would have preferred that a PM node be created for each PCI node and
> have the PM nodes organised as a tree structure. That way, arch fixup
> hooks can re-arrange the tree as the PCI bus->child dependency may not
> be true. On some portables, some ASICs located on the PCI bus are not
> dependent on their parent host bridge power plane.

I favor the idea of having a tree view of _all_ devices in the system, but
that's another story, and something I discussed in a post to the
linux-power list.

The PCI bus-child dependency and ordering should always be true, AFAIK.
Some PCI functions may have another source of power, but should only be
to support the generation of wa

Re: ac10 ide-cd oopses on boot

[Udo A. Steinberg]

Alan Cox wrote:
> 
> > Just built 2.4.3-ac10 and got an oops when booting. It tries to detect
> > the CD and gives the oops.

I'm getting a similar oops with -ac10. I initially thought this might be
a result of switching to gcc-2.95.3, because -ac9 runs fine when built
with gcc-2.95.2, but if others have seen this too, it's probably the
cdrom code indeed.

> Can you back out the ide-cd changes Jens did and see if that fixes it ?

I'll try that tomorrow, too.

Regards,
Udo.

--

ksymoops 2.3.7 on i686 2.4.3-ac9.  Options used
 -v /usr/src/linux/vmlinux (specified)
 -K (specified)
 -l /proc/modules (default)
 -o /lib/modules/2.4.3-ac10 (specified)
 -m /boot/System.map-2.4.3-ac10 (specified)

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel NULL pointer dereference at virtual address 
Oops: 
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010297
eax: 000d  ebx:   ecx:   edx: 
esi:   edi: c1469ae8  ebp: 0021  ebp: cffe5ee0
ds: 0018  es: 0018  ss: 0018
Process swapper (pid: 1, stackpage=cffe5000)
Stack: c0276018 c0275fb4 c01b9dbf c1469a00 c02e31f4 c1469b18 c02e3100 0001
   0286 0001 0001 c0113623 c02b5fe1 0246 c0113574 c0244e02
   c0244e9d c1469a00 c02e3100 c01b91cb c02448ec c02e3100 c1469037 c0244fc0
Call Trace: [] [] [] [] []
[] [] [] []
Code: 8b 04 8a 83 f8 ff 75 0c 83 c6 20 eb e7 8d b4 26 00 00 00 00
 
>>EIP; c01b9bac<=
Trace; c01b9dbf 
Trace; c0113623 
Trace; c0113574 
Trace; c01b91cb 
Trace; c01b8d0c 
Trace; c01b976a 
Trace; c01b9af1 
Trace; c0105007 
Trace; c0105488 
Code;  c01b9bac 
 <_EIP>:
Code;  c01b9bac<=
   0:   8b 04 8a  movl   (%edx,%ecx,4),%eax   <=
Code;  c01b9baf 
   3:   83 f8 ff  cmpl   $0x,%eax
Code;  c01b9bb2 
   6:   75 0c jne14 <_EIP+0x14> c01b9bc0 

Code;  c01b9bb4 
   8:   83 c6 20  addl   $0x20,%esi
Code;  c01b9bb7 
   b:   eb e7 jmpfff4 <_EIP+0xfff4> c01b9ba0 

Code;  c01b9bb9 
   d:   8d b4 26 00 00 00 00  leal   0x0(%esi,1),%esi
 
<0>Kernel panic: Attempted to kill init!
-
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: Real Time Traffic Flow Measurement - anybody working on it?

[Edgar Toernig]

Hi,

Michael Clark wrote:
> 
> An obvious kernel improvement for userspace meters like NeTraMet would
> be to give libpcap's pcap_read a kernel interface that can return more
> than one packet at a time (the libpcap interface has this capability).

It's already there - the turbo packet interface (PACKET_RX_RING sockopt).
Very nice and fast.  Direct transfer to mmapped memory.

> An additional feature for network devices that could support it (not
> sure if this is feasible) would be to switch to an 'interrupt when
> packet buffer full' when in promiscuous mode.

With the RX_RING you can poll a memory location in the mmapped memory
to detect whether there are new packets.  You basically only perform
a system call (poll/select) if there's nothing more to do.

Ciao, ET.

-
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-pm-devel] Re: PCI power management

[Patrick Mochel]

> >  - 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.
> 
> I think either Rusty or Anton wrote code to enable and disable CPUs...
> 
> CPU hotplugging but it would be useful for PM too.

There's more than that, too. The ACPI spec says that the system must be
able to handle complete dynamic reconfiguration of the system during
suspend/resume. Basically an ideal solution would assume that any device
could have been added or removed while the system was asleep, so it must
account for it by initializing the device and allocating system resources.

Granted CPU hotplugging is a different ballpark, but it's the same league.

-pat

-
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] generic rw_semaphores, compile warnings patch

[David S. Miller]

D.W.Howells writes:
 > This patch (made against linux-2.4.4-pre4) gets rid of some warnings obtained 
 > when using the generic rwsem implementation.

Have a look at pre5, this is already fixed.

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

[PATCH] reiserfs should daemonize

[Chris Mason]

Hi guys,

The reiserfs commit thread needs to daemonize.  This patch
was actually from Andi Kleen eons ago (but blame me if 
it breaks).  Please apply.

Against 2.4.3:

--- linux/fs/reiserfs/journal.c Thu Apr 19 14:02:56 2001
+++ linux/fs/reiserfs/journal.c Thu Apr 19 18:11:57 2001
@@ -1814,16 +1814,14 @@
 ** then run the per filesystem commit task queue when we wakeup.
 */
 static int reiserfs_journal_commit_thread(void *nullp) {
-  exit_files(current);
-  exit_mm(current);
+
+  daemonize() ;
 
   spin_lock_irq(¤t->sigmask_lock);
   sigfillset(¤t->blocked);
   recalc_sigpending(current);
   spin_unlock_irq(¤t->sigmask_lock);
 
-  current->session = 1;
-  current->pgrp = 1;
   sprintf(current->comm, "kreiserfsd") ;
   lock_kernel() ;
   while(1) {


-
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] generic rw_semaphores, compile warnings patch

[D . W . Howells]

This patch (made against linux-2.4.4-pre4) gets rid of some warnings obtained 
when using the generic rwsem implementation.

David



diff -uNr linux-2.4.4-pre4/include/linux/rwsem.h linux/include/linux/rwsem.h
--- linux-2.4.4-pre4/include/linux/rwsem.h  Thu Apr 19 22:07:49 2001
+++ linux/include/linux/rwsem.h Thu Apr 19 23:52:41 2001
@@ -42,20 +42,24 @@
 #include 
 #include 
 
-#ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
-#include  /* use a generic implementation */
-#else
-#include  /* use an arch-specific implementation */
-#endif
+struct rw_semaphore;
 
 /* defined contention handler functions for the generic case
  * - these are also used for the exchange-and-add based algorithm
  */
-#if defined(CONFIG_RWSEM_GENERIC) || defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
+#if defined(CONFIG_RWSEM_GENERIC_SPINLOCK) || defined(CONFIG_RWSEM_XCHGADD_ALGORITHM)
 /* we use FASTCALL convention for the helpers */
 extern struct rw_semaphore *FASTCALL(rwsem_down_read_failed(struct rw_semaphore 
*sem));
 extern struct rw_semaphore *FASTCALL(rwsem_down_write_failed(struct rw_semaphore 
*sem));
 extern struct rw_semaphore *FASTCALL(rwsem_wake(struct rw_semaphore *sem));
+#endif
+
+/* access the actual implementation of the rwsems
+ */
+#ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
+#include  /* use a generic implementation */
+#else
+#include  /* use an arch-specific implementation */
 #endif
 
 #ifndef rwsemtrace

Re: ac10 ide-cd oopses on boot

[J . A . Magallon]

On 04.20 Alan Cox wrote:
> > Just built 2.4.3-ac10 and got an oops when booting. It tries to detect
> > the CD and gives the oops.
> 
> 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.

Bootlog from ac9:

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive
hdc: CREATIVE CD5230E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hdc: ATAPI 52X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
 here, ac10 oopses >>
hda: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm
ide-floppy: hda: I/O error, pc = 5a, key =  5, asc = 24, ascq =  0

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.3-ac9 #1 SMP Wed Apr 18 10:35:48 CEST 2001 i686

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

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

[D . W . Howells]

You asked for some benchmarks Andrea, so I've obtained some.

The set of test modules can be found at:

ftp://infradead.org/pub/people/dwh/rwsem-test.tar.bz2

(This also includes rwsem-stat.txt which has a copy of the benchmark results 
in as well)

There are six test programs. They can be made for i386 by the following 
command:

make

And can also be made to invoke the scheduler after each pass through the loop:

make SCHED=yes

I ran each individual test twice, hence the two sets of results for 
permutation.

My machine is a Dual 400MHz PII with an 440BX chipset. All the tests were run 
in runlevel 3 with no other applications running.

I benchmarked four different environments:

(1) 2.4.4-pre3 + Andrea's generic rwsem patch
(2) 2.4.4-pre4 using XADD to implement the rwsems
(3) same as (2) but with a tweak to make rwsem_wake() less fair
(4) 2.4.4-pre3 using my generic spinlock code to implement the rwsems

David


TESTNUM READERS NUM WRITERS CONTENTION
=== === === ==
rwsem-rw4   2   r-w & w-w
rwsem-ro4   0   no
rwsem-wo0   4   w-w only
rwsem-r11   0   no
rwsem-w10   1   no
rwsem-r22   0   no


ENVIRONMENT TESTSCHED   READERS WRITERS
=== === === === ===
Linux-2.4.4-pre3 + AA-rwsem rws-rw  no   33302811009
 3331972 994
yes  1767102  607091
 1743420  642095
rws-ro  no   2534630n/a
 3535202n/a
yes  2837218n/a
 3164814n/a
rws-wo  no  n/a  2507449
n/a  2399102
yes n/a  1568467
n/a  1412262
rws-r1  no   9232485n/a
 9217585n/a
yes  5483757n/a
 5487028n/a
rws-w1  no  n/a  9900333
n/a  9918021
yes n/a  5745657
n/a  5747063
rws-r2  no   3499275n/a
 3518590n/a
yes  3184431n/a
 3180287n/a

--- --- --- --- ---
Linux-2.4.4-pre4 [XADD] rws-rw  no563388  283005
  558159  280288
yes   683670  197017
  700714  194316
rws-ro  no   6316985n/a
 6314241n/a
yes  4309406n/a
 4575043n/a
rws-wo  no  n/a   765699
n/a   763876
yes n/a   650512
n/a   652287
rws-r1  no  15171532n/a
15158899n/a
yes  7222310n/a
 7229793n/a
rws-w1  no  n/a 13942744
n/a 13991823
yes n/a  7362605
n/a  7356127
rws-r2  no   5517671n/a
 5516168n/a
yes  3452796n/a
  

ac10 ide-cd oopses on boot

[J . A . Magallon]

Hi, 

Just built 2.4.3-ac10 and got an oops when booting. It tries to detect
the CD and gives the oops.

Here follows the oops both raw and decoded:

Unable to handle kernel NULL pointer dereference at virtual address 
 printing eip:
c01bfc7c
pgd entry c0101000: 
pmd entry c0101000: 
.. pmd not present!
Oops: 
CPU:1
EIP:0010:[]
EFLAGS: 00010297
eax: 000d   ebx:    ecx:    eax: 
esi:    edi: c15d84e8   ebp: c019e790   esp: c15f9ee8
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c15f9000)
Stack: c0248fbc  c01bfeac 0001 c0239e04 c0289841 0246 0001
   c02cdfb0 c0118af8 c02cdfb0 c0220524 0080 c019f356 c021ff4c 0001
   00701600  0007122a 03297371 ff00c023 8000 c15d84e8
c02cdfb0
Call Trace: [] [] [] []
[] [] []
[] [] [] []
Code: 8b 04 8a 83 f8 ff 75 0c 83 c6 20 eb e7 8d b4 26 00 00 00 00
 <0>Kernel panic: Attempted to kill init

ksymoops 2.4.1 on i686 2.4.3-ac9.  Options used
 -v /usr/src/linux-2.4.3-ac10/vmlinux (specified)
 -K (specified)
 -L (specified)
 -o /lib/modules/2.4.3-ac9/ (default)
 -m /boot/System.map-2.4.3-ac10 (specified)

No modules in ksyms, skipping objects
Unable to handle kernel NULL pointer dereference at virtual address 
c01bfc7c
Oops: 
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010297
eax: 000d   ebx:    ecx:    eax: 
esi:    edi: c15d84e8   ebp: c019e790   esp: c15f9ee8
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c15f9000)
Stack: c0248fbc  c01bfeac 0001 c0239e04 c0289841 0246 0001
   c02cdfb0 c0118af8 c02cdfb0 c0220524 0080 c019f356 c021ff4c 0001
   00701600  0007122a 03297371 ff00c023 8000 c15d84e8
c02cdfb0
Call Trace: [] [] [] []
[] [] []
 [] [] [] []
Code: 8b 04 8a 83 f8 ff 75 0c 83 c6 20 eb e7 8d b4 26 00 00 00 00

>>EIP; c01bfc7c<=
Trace; c01bfeac 
Trace; c0118af8 
Trace; c019f356 
Trace; ff00c023 
Trace; c019f903 
Trace; c019fc66 
Trace; c0105000 
Trace; c0105028 
Trace; c0105000 
Trace; c0105516 
Trace; c0105000 
Code;  c01bfc7c 
 <_EIP>:
Code;  c01bfc7c<=
   0:   8b 04 8a  mov(%edx,%ecx,4),%eax   <=
Code;  c01bfc7f 
   3:   83 f8 ff  cmp$0x,%eax
Code;  c01bfc82 
   6:   75 0c jne14 <_EIP+0x14> c01bfc90

Code;  c01bfc84 
   8:   83 c6 20  add$0x20,%esi
Code;  c01bfc87 
   b:   eb e7 jmpfff4 <_EIP+0xfff4> c01bfc70

Code;  c01bfc89 
   d:   8d b4 26 00 00 00 00  lea0x0(%esi,1),%esi

 <0>Kernel panic: Attempted to kill init


-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.3-ac9 #1 SMP Wed Apr 18 10:35:48 CEST 2001 i686

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

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

[Eric S. Raymond]

Remove dead CONFIG_BINFMT_JAVA symbol.

--- arch/cris/config.in 2001/04/18 14:18:58 1.1
+++ arch/cris/config.in 2001/04/18 14:19:11
@@ -18,9 +18,6 @@
 bool 'System V IPC' CONFIG_SYSVIPC
 
 tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF
-if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-  tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA
-fi
 
 bool 'Use kernel gdb debugger' CONFIG_KGDB
 
--- arch/cris/defconfig 2001/04/18 14:31:34 1.1
+++ arch/cris/defconfig 2001/04/18 14:31:39
@@ -14,7 +14,6 @@
 CONFIG_NET=y
 CONFIG_SYSVIPC=y
 CONFIG_BINFMT_ELF=y
-# CONFIG_BINFMT_JAVA is not set
 # CONFIG_KGDB is not set
 # CONFIG_ETRAX_WATCHDOG is not set
 CONFIG_USE_SERIAL_CONSOLE=y
--- arch/parisc/config.in   2001/04/18 14:18:08 1.1
+++ arch/parisc/config.in   2001/04/18 14:18:28
@@ -66,9 +66,6 @@
 tristate 'Kernel support for SOM binaries' CONFIG_BINFMT_SOM
 tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF
 tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC
-if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
-  tristate 'Kernel support for JAVA binaries (obsolete)' CONFIG_BINFMT_JAVA
-fi
 
 endmenu
 
--- arch/parisc/defconfig   2001/04/18 14:18:49 1.1
+++ arch/parisc/defconfig   2001/04/18 14:18:53
@@ -40,7 +40,6 @@
 CONFIG_BINFMT_SOM=y
 CONFIG_BINFMT_ELF=y
 # CONFIG_BINFMT_MISC is not set
-# CONFIG_BINFMT_JAVA is not set
 
 #
 # Parallel port support

End of diffs.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

Such are a well regulated militia, composed of the freeholders,
citizen and husbandman, who take up arms to preserve their property,
as individuals, and their rights as freemen.
-- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" 
referred to in the Second Amendment to the Constitution.
-
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

[Ulrich Drepper]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> I'm not interested in re-creating the idiocies of Sys IPC.

I'm not talking about sysv semaphores (couldn't care less).  And you
haven't read any of the mails with examples I sent.

If the new interface can be useful for anything it must allow to
implement process-shared POSIX mutexes.  The user-level representation
of these mutexes are simple variables which in the case of
inter-process mutexes are placed in shared memory.  These variables
must be usable with the normal pthread_mutex_lock() functions and
perform whatever is needed.

Whether the pthread_mutex_init() function for shared mutexes is doing
a lot more work and allocates even more memory, I don't care.  The
standard certainly permits this and every pthread_mutex_init() must
have a pthread_mutex_destroy() which allows allocating and freeing
resources (no file descriptor, though).  So, yes, your FS_create
syscall can allocate something.

But the question is what handle to put in the pthread_mutex_t variable
so the different processes can use the mutex.  It cannot be a file
descriptor since it's not shared between processes.  It cannot be a
pointer to some other place in the virtual memory since the place
pointed to might not be (and probably isn't if FS_create is allocating
something in the process setting up the mutex).  You could put some
magic cookie in the pthread_mutex_t object the kernel can then use.


So, instead of repeating over and over again the same old story, fill
in the gaps here:


  int
  pthread_mutex_init (pthread_mutex_t *mutex,
  const pthread_mutexattr_t *mutex_attr)
  {
if (mutex_attr != NULL && mutex_attr->__pshared != 0)
  {
... FILL IN HERE ...
  }
else
  ...intra-process mutex, uninteresting here...
  }

  int
  pthread_mutex_lock (pthread_mutex_t *mutex)
  {
if (mutex_attr != NULL && mutex_attr->__pshared != 0)
  {
... FILL IN HERE ...
  }
else
  ...intra-process mutex, uninteresting here...
  }

  int
  pthread_mutex_destroy (pthread_mutex_t *mutex)
  {
if (mutex_attr != NULL && mutex_attr->__pshared != 0)
  {
... FILL IN HERE ...
  }
else
  ...intra-process mutex, uninteresting here...
  }


These functions must work with something like this:

~ cons.c ~~
#include 
#include 
#include 
#include 
#include 

int
main (int argc, char *argv[])
{
  char tmpl[] = "/tmp/fooXX";
  int fd = mkstemp (tmpl);
  pthread_mutexattr_t attr;
  pthread_mutex_t *m1;
  pthread_mutex_t *m2;
  void *addr;
  volatile int *i;

  pthread_mutexattr_init (&attr);
  pthread_mutexattr_setpshared (&attr, PTHREAD_PROCESS_SHARED);

  ftruncate (fd, 2 * sizeof (*m1) + sizeof (int));
  addr = mmap (NULL, sizeof (*m1), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
  m1 = addr;
  m2 = m1 + 1;
  i = (int *) (m2 + 1);
  *i = 0;

  pthread_mutex_init (m1, &attr);
  pthread_mutex_lock (m1);

  pthread_mutex_init (m2, &attr);
  pthread_mutex_lock (m2);

  if (fork () == 0)
{
  char buf[10];
  snprintf (buf, sizeof buf, "%d", fd);
  execl ("./prod", "prod", buf, NULL);
}

  while (1)
{
  pthread_mutex_lock (m1);
  printf ("*i = %d\n", *i);
  pthread_mutex_unlock (m2);
}

  return 0;
}
~~prod.c ~~
#include 
#include 
#include 
#include 
#include 

int
main (int argc, char *argv[])
{
  int fd = atoi (argv[1]);
  void *addr;
  pthread_mutex_t *m1;
  pthread_mutex_t *m2;
  volatile int *i;

  addr = mmap (NULL, sizeof (*m1), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
  m1 = addr;
  m2 = m1 + 1;
  i = (int *) (m2 + 1);

  while (1)
{
  ++*i;
  pthread_mutex_unlock (m1);
  pthread_mutex_lock (m2);
}

  return 0;
}
~~~

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.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: light weight user level semaphores

[Rogier Wolff]

Alan Cox wrote:
> > > libc is entitled to, and most definitely does exactly that. Take a look at
> > > things like gethostent, getpwent etc etc.
> > 
> > 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.
> > 
> > You want to take the bet?
> 
> Its not normally a good idea to take a Linus bet, but this time Im obviously
> missing something. fd0-2 will be passed in (and if not then shit already
> happens - see old bugtraq on the matter for setuid apps, glibc bugs)
> 
> So the C library gets fd 3
> My first fopen gets fd 4.

Code may 
close (0);
close (1);
close (2); 
... 
malloc (); 

/* Now open our controlling TTY/ stdin .. */ 
fd = open (... ) ;

After taking care of this (*), problem I find the fd trick WAY more
appealing than Linus' magic numbers. With file descriptors we have a
"small integer which can be validated quickly". We also have storage
for a private pointer somewhere in the fd structure. 

If people are TOO afraid of breaking something, creating a new set of
small integers handled similarly as "fds" would do fine. (Maybe here
we'd allocate just a few, and reallocate when neccesary).

Roger. 

(*) I bet that 
get_sem_fd () 
{
int rv;
int fd; 
fd = get_fd ();
if (fd < 5) {
rv = get_sem_fd ();
close(fd);
fd = rv; 
  } 
return fd; 
}

will not break much. (UGLY coding. Don't tell me.)

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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/

Current Security Module snapshot

[Greg KH]

Hi,

Just to keep people informed (hi Miles!) that since the announcement of
the linux-security-module mailing list, some actual work has come out of
it.  Actual working code has been posted, which shows the current state,
and the general model of what people are working toward.  This post and
the patch can be found at:
http://marc.theaimsgroup.com/?l=linux-security-module&m=98764307916530&w=2

Comments on this are welcomed on either this list, or on the
linux-security-module list.

thanks,

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg
-
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: active after unmount?

[Matthew Jacob]

'kay, great, thanks.. I'll put it in and see if things show up again


-
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: aha1542 fails in 2.4.4-pre4

[Jens Axboe]

On Thu, Apr 19 2001, Jonathan Hudson wrote:
> 
> Just rebuilt an old box (Celeron 400) with an aha1542 and SCSI
> CD-ROM. Get the following:

Known bug, on my list, will fix.

-- 
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: active after unmount?

[Andi Kleen]

On Thu, Apr 19, 2001 at 02:56:15PM -0700, Matthew Jacob wrote:
> 
> 
> On Thu, 19 Apr 2001, Brian J. Watson wrote:
> 
> > > Unmounting a SCSI disk device succeeded, and yielded:
> > > 
> > > Red Hat Linux release 6.2 (Zoot)
> > > Kernel 2.4.3 on a 2-processor i686
> > > 
> > > chico login: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have
> > > a nice day...
> > > 
> > 
> > 
> > This message comes out of kill_super(). I would guess that somebody's
> > mismanaging VFS refcounts, but there's not enough info here to diagnose the
> > problem. What filesystem are you using? Is this reproducible? What do you have
> > to do between mounting and unmounting to reproduce the problem?
> 
> >>ext2<<, haven't reproduced it yet, on a 2x686 256MB memory,
> SCSI midlayer default, with 2.4.3.

I've seen it a lot with the autofs. You can check what it is with the
following small debug patch.

Index: fs/inode.c
===
RCS file: /cvs/linux/fs/inode.c,v
retrieving revision 1.122
diff -u -u -r1.122 inode.c
--- fs/inode.c  2001/03/24 09:36:25 1.122
+++ fs/inode.c  2001/04/19 22:07:17
@@ -443,6 +443,13 @@
count++;
continue;
}
+#if 1
+   printk("inode %u:%lu busy\n", inode->i_dev, inode->i_ino); 
+   if (inode->i_dentry.next != &inode->i_dentry) 
+   printk("for file %s\n", 
+   list_entry(inode->i_dentry.next, struct dentry, d_alias)->d_name.name);  
+#endif 
+   
busy = 1;
}
/* only unused inodes may be cached with i_count zero */


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

aha1542 fails in 2.4.4-pre4

[Jonathan Hudson]

Just rebuilt an old box (Celeron 400) with an aha1542 and SCSI
CD-ROM. Get the following:

(aha1542 as module)
 
Apr 19 21:22:04 kanga kernel: Configuring Adaptec (SCSI-ID 7) at IO:330, IRQ 10, DMA 
priority 6 
Apr 19 21:22:04 kanga kernel: scsi0 : Adaptec 1542 
Apr 19 21:22:04 kanga kernel:   Vendor: SONY  Model: CD-ROM CDU-8003A  Rev: 1.9a 
Apr 19 21:22:04 kanga kernel:   Type:   CD-ROM ANSI SCSI 
revision: 02 
Apr 19 21:22:04 kanga kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 
0 
Apr 19 21:22:06 kanga kernel: sr0: scsi-1 drive 
Apr 19 21:22:06 kanga kernel: Uniform CD-ROM driver Revision: 3.12 
Apr 19 21:22:20 kanga kernel: sr: ran out of mem for scatter pad 
Apr 19 21:22:20 kanga kernel:  I/O error: dev 0b:00, sector 376 
Apr 19 21:22:20 kanga kernel: isofs_read_super: bread failed, dev=0b:00, 
iso_blknum=94, block=188 
Apr 19 21:23:41 kanga kernel: sr: ran out of mem for scatter pad 
Apr 19 21:23:41 kanga kernel:  I/O error: dev 0b:00, sector 64 

(aha1542 in kernel)
Apr 19 22:37:49 kanga automount[247]: attempting to mount entry /mnt/cdrom
Apr 19 22:37:50 kanga kernel: sr: ran out of mem for scatter pad
Apr 19 22:37:50 kanga kernel: Kernel panic: scsi_free:Bad offset

Works fine in 2.2.19.

-
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: active after unmount?

[Brian J. Watson]

> Unmounting a SCSI disk device succeeded, and yielded:
> 
> Red Hat Linux release 6.2 (Zoot)
> Kernel 2.4.3 on a 2-processor i686
> 
> chico login: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have
> a nice day...
> 


This message comes out of kill_super(). I would guess that somebody's
mismanaging VFS refcounts, but there's not enough info here to diagnose the
problem. What filesystem are you using? Is this reproducible? What do you have
to do between mounting and unmounting to reproduce the problem?

--
Brian Watson
Compaq Computer
-
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: active after unmount?

[Matthew Jacob]

On Thu, 19 Apr 2001, Brian J. Watson wrote:

> > Unmounting a SCSI disk device succeeded, and yielded:
> > 
> > Red Hat Linux release 6.2 (Zoot)
> > Kernel 2.4.3 on a 2-processor i686
> > 
> > chico login: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have
> > a nice day...
> > 
> 
> 
> This message comes out of kill_super(). I would guess that somebody's
> mismanaging VFS refcounts, but there's not enough info here to diagnose the
> problem. What filesystem are you using? Is this reproducible? What do you have
> to do between mounting and unmounting to reproduce the problem?

>>ext2<<, haven't reproduced it yet, on a 2x686 256MB memory,
SCSI midlayer default, with 2.4.3.

-matt



-
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

[Miles Lane]

Alan Cox wrote:

>>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.
>>
> 
> Has it occured to you that some of this might be because the code does stuff
> like hide flags in the low bits of addresses and do unchecked kmallocs ?
> Things people have tried to send patches for ..
> 
> The best way to get stuff to Linus is to feed him changes one at a time and
> make them all clean and clearly correct. When I have a big set of changes I
> normally start by feeding Linus all the 'fluff' - spelling checks and small
> warning fixes. After that its normally easy to pick out changes one at a time
> and feed them on.
> 
> Given 500 lines of mixed up diff it is very hard to verify the correctness of
> anything. 


The IrDA folks have had a similar struggle.  AJ, perhaps it would be
helpful for you to read the discussion that took place regarding getting
a bunch of IrDA code merged into the 2.4 tree:

http://www.pasta.cs.uit.no/pipermail/linux-irda/2000-November/001923.html

Dag Brattli <[EMAIL PROTECTED]> eventually had a discussion with Linus and
hashed out what he needed to do to get Linus to accept his big patch. 
It all
worked out very well, IIRC.

Miles

-
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] 2.4.3-ac{6,7} LVM hang

[Jens Axboe]

On Thu, Apr 19 2001, Arjan Filius wrote:
> Hello,
> 
> Same here as reported.
> restoring lvm.c from 2.4.3 into 2.4.4-pre? "fixes" this. (tested not ac's
> kernel)

Does attached patch fix it?

-- 
Jens Axboe



--- /opt/kernel/linux-2.4.4-pre4/drivers/md/lvm.c   Wed Apr 18 14:37:34 2001
+++ drivers/md/lvm.cThu Apr 19 23:40:39 2001
@@ -1674,10 +1674,11 @@
   int rw,
   struct buffer_head *bh)
 {
-   int ret = lvm_map(bh, rw);
-   if (ret < 0)
-   buffer_IO_error(bh);
-   return ret;
+   if (lvm_map(bh, rw) >= 0)
+   return 1;
+
+   buffer_IO_error(bh);
+   return 0;
 }
 
 

Re: Your message to linux-lvm awaits moderator approval

[Chip Salzenberg]

Rik van Riel writes:
>[...] Andreas' patches got dropped over and over again and comments
>on the LVM code got refused by the moderators at Sistina ...

"The Net interprets censorship as damage and routes around it."
-- John Gilmore

-- 
Chip Salzenberg  - a.k.a. - <[EMAIL PROTECTED]>
 "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech
-
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

[Linus Torvalds]

On 19 Apr 2001, Ulrich Drepper wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > > I fail to see how this works across processes.
> >
> > It's up to FS_create() to create whatever shared mapping is needed.
>
> No, the point is that FS_create is *not* the one creating the shared
> mapping.  The user is explicitly doing this her/himself.

No.

Who creates the shared mapping is _irrelevant_, because it ends up being
entirely a function of what the chosen interface is.

For example, quote often you want semaphores for threading purposes only,
and then you don't need a shared mapping at all. So you'd use the proper
interfaces for that, and for that, your "thread_semaphore()" function
would just do a malloc() and initialize the memory to zero. Doing a mmap
or something like that would just be stupid, because you're protecting
only one VM space anyway.

In other cases, you may need to have process-wide semaphores, and you'd
use "process_semaphore(char *ID)" or something, which actually does a
mmap() on a shared file. Or you'd have "fork_semaphore()" that creates a
semaphore that is valid across forks, not not valid across execve's and
cannot be passed around.

So normally the user does NOT create the shared mapping himself. Normally
you'd just use the "proper interface" for your needs, nothing more.

Sure, you can have the option of saying "I've created this shared memory
region, please make it use the generic semaphore engine code", but quite
frankly I think that is a BAD IDEA. Why? Because it won't work portably
across architectures anyway. You don't know what the requirements of the
architecture are, so it should be done by a nice "semaphore library". NOT
by the user.

Remember: these semaphores are NOT a new SysV bogosity. These semaphores
are a new interface, with sane performance and sane design. And you can
have multiple external interfaces to the same "semaphore engine".

I'm not interested in re-creating the idiocies of Sys IPC.

Linus

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

[Alan Cox]

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

Re: light weight user level semaphores

[Alan Cox]

> Are you sure, you can implement SMP-safe, atomic operations (which you need
> for all up()/down() in user space) WITHOUT using privileged
> instructions on ALL archs Linux supports?

You don't need to. For some architectures the semaphore code would always call
into the kernel. For those that allow fast locks in userspace it won't. The
API is the thing, and the public exposure would I assume be pthreads 


-
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

[Tomas Jura]

On Sat, Apr 14, 2001 at 12:12:28AM +0200, Giuliano Pochini wrote:
> 
> My fstab:
> 
> /dev/cdrom  /mnt/cdrom  iso9660 noauto,user,ro 0 0
> /dev/cdrom  /mnt/cdmac  hfs noauto,user,ro 0 0
> 
> I insert an apple cd (hfs) and mount /mnt/cdmac If I type eject /mnt/cdrom
> the cd momes out but df shows it's still mounted:
> 
> /dev/sr0667978667978 0 100% /mnt/cdmac
> 
> It's funny it don't let me eject cdmac
> 
> [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
> 

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:

floppy = open(/dev/fd0);
ioctl( floopy, FDGETDRVPRM, &fdp) /* some *invalid* ioctl */
exit

Device is lost for root too. It is impossible to make any operation on this
device anymore. And adding some debuging messages showed me that there is no
problem in swim3 device driver. Still digging...(but have no much time to do
this ;-( )

Hw&Sw: PowerPC G3 beige, kernel 2.4.3, devfs

Tomas

P.S. CC to me, I'm not in linux-kernel list. Only in linux-ppc


-
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

[Alan Cox]

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

Well Keith is on holiday I believe and Paul is moving from Linuxcare.

> Any suggestions on the solution to my problem?

Build PPC from the linuxppc trees not the base one - it isnt yet all nicely
merged in 2.4
-
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

[David Woodhouse]

[EMAIL PROTECTED] said:
>  I have not yet heard from Mr. Owens.

This does not surprise me, given the content of your email.

> The compiler error message along with the menuconfig-generated
> configuration file are set out in the attached MS Word document.

I have to assume that you're just winding us up here, rather than genuinely
in need of assistance. Word documents are not an appropriate form in which
to exchange such information across security domains; especially in public
fora - and I won't insult your intelligence by assuming that you believe
otherwise.

cf. http://www.infradead.org/fileexchange.html

--
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: Problems with Toshiba SD-W2002 DVD-RAM drive (IDE)

[Stefan Jaschke]

On Thursday 19 April 2001 15:03, Jens Axboe wrote:
> On Thu, Apr 19 2001, Stefan Jaschke wrote:
> > OK. I'll check again with 2.4.4-pre4+patches:
> > (1) Mounting the SuSE DVD-ROM (-t iso9660) from /dev/hdc on /dvd and
> > reading from /dvd works. Same for CD-ROMs. I don't have a formatted
> > DVD-RAM.
> > (2) Reading with "dd if=/dev/hdc ..."
> >(2.1) works with CD-ROM inserted
> >(2.2) fails with DVD-ROM inserted
>
> dd fails with DVD-ROM inserted??? In the same way? Is this the SuSE DVD,
> and not a movie DVD? Also, check dmesg for errors.
> >(2.3) fails with DVD-RAM inserted

"dd if=/dev/hdc of=/dev/null bs=2k count=3" produces the same strace, whether
the DVD-RAM or the SuSE DVD-ROM is inserted. I interpret the fact that the
first read() returns 0 as some lower layer coming to the conclusion that
"/dev/hdc" has length 0. 
The only line that appears in the system logs is
  "VFS: Disk change detected on device ide1(22,0)"
when I change the disks.

> > (3) Writing with "dd of=/dev/hdc ..." works (with DVD-RAM inserted).
> > (4) "mke2fs -b 2048 /dev/hdc" fails (with DVD-RAM inserted).
I took a closer look at the strace of the "mke2fs ...". The first system call
that fails is
old_mmap(NULL, 504938496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = -1 ENOMEM
It asks for 481MB, which I simply don't have. (128MB RAM,  256MB swap).
So, this may be unrelated to the kernel, just a quirk of mke2fs to ask for
that much memory.

> Could be, try
> cat /proc/ide/hdc/capacity
0  (with empty tray)
8946816   (with single-sided 4.7GB DVD-RAM)
4875840   (with single-sided 2.6GB DVD-RAM)
9106700   (with SuSE DVD-ROM)
1325240   (with SuSE CD-ROM)

Seem to be 512 Byte blocks. Looks OK.

> And lets stick to hardware for now, ok? :-)
This means "There is hope to get the drive working under Linux"?

Correct me if I am wrong in my interpretations.

There are two mysteries (for me at least) left:
(1) Why does mke2fs need 481MB memory?
(2) Why does the very first read() on /dev/hdc return EOF?

What would you suggest to try next?

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-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[Kurt Garloff]

Hi AJ,

On Thu, Apr 19, 2001 at 02:40:15PM -0500, AJ Lewis wrote:
> The list is now open.  I've talked to our admin and he's opening it up.
> Send me e-mail if it doesn't work, 'cause something else is broken.

to me it looks like your reactions are too late.

I suggest you Sistina people accept the fact the there is an open list
(better) managed by somebody else now and you all move there and use this as
a forum for your discussions from now on. Just send the new list admin a
list with your people to be subscribed ... and I can not imagine they will
refuse to help you. (Otherwise they would be as closed-minded as you were.)

Maintaining a project which got integrated into the kernel and forms a
critical part of it (if there are bugs) is not an easy thing to do, and you
should expect controversary discussions. On the one hand you want to fix
things and introduce small and large improvements, on the other hand you
don't want to take risks. Just get used to it.

You'll always have a newer version to test than the one in the kernel.
However, it works best if you try to submit your changes as often as
possible. Of course I know, this is close to impossible when you have to
redesign stuff and have to wait for stabilization ...

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

 PGP signature

Re: light weight user level semaphores

[Ulrich Drepper]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> > I fail to see how this works across processes.
> 
> It's up to FS_create() to create whatever shared mapping is needed.

No, the point is that FS_create is *not* the one creating the shared
mapping.  The user is explicitly doing this her/himself.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.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: FW: Linux 2.4.3 Compile Errors - Power Mac

[tom_gall]

Jeff Galloway wrote:
> 
> 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.

Hi Jeff,

  Hmm Paul is around his email just changed and the pmac maintainer is now
Ben, but that issue aside where did you get your 2.4.3 sources from that you are
trying to build?

  http://www.fsmlabs.com/linuxppcbk.html is the location you want to pull stuff
from.

> I have not yet heard from Mr. Owens.
> 
> Any suggestions on the solution to my problem?

  Well suggestion one is DON'T GIVE US A WORD DOCUMENT! Plain text please, then
we can actually read what's wrong.

  Best to post to [EMAIL PROTECTED] That's one of the lists that
the PPC Linux watches.
 
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: Dead symbol elimination, stage 1

[David Woodhouse]

[EMAIL PROTECTED] said:
>  For instance, a quick scan of my latest ARM patch reveals: 
> src@raistlin:[2]:<1009> grep 'diff.*Config.in' rmk1
> diff -urN linux-orig/drivers/mtd/Config.in linux/drivers/mtd/Config.in

Please could you make sure that whatever changes you have are in my CVS - 
I'm working on getting ready to sync up.

--
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: [kbuild-devel] Dead symbol elimination, stage 1

[Kai Germaschewski]

On Thu, 19 Apr 2001, Eric S. Raymond wrote:

> The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
> source tree.  It corrects a typo involving CONFIG_GEN_RTC.  Another typo
> involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol
> is never set in these files.

While I think your work CONFIG_ cleanup is generally a good idea and will
remove a lot of cruft, I don't think the defconfigs are worth the effort
(but maybe I'm missing something).

First, they are only used as defaults, and any inconsistency should get
cleaned up before the user even sees it.

Second, removing dead entries is not all which is needed to get a
defconfig which is necessarily consistent. So if you want to have these,
why don't you do a

cp arch/$ARCH/defconfig .config
make oldconfig

AFAICS, this should remove old cruft and provide a .config (to be used as
defconfig) which is consistent with the current config.in's.


Anyway, I put together a patch which should clean up some issues which I
was reminded of because of your work in the ISDN subsystem. I appended it,
I hope the maintainer of the Eicon code (Armin) will clean up the missing
Configure.help entries for his drivers.

--Kai

diff -ur linux-2.4.4-pre4/Documentation/Configure.help 
linux-2.4.4-pre4.config/Documentation/Configure.help
--- linux-2.4.4-pre4/Documentation/Configure.help   Thu Apr 19 21:49:17 2001
+++ linux-2.4.4-pre4.config/Documentation/Configure.helpThu Apr 19 23:00:40 
+2001
@@ -15430,6 +15430,16 @@
   This enables HiSax support for the AMD7930 chips on some SPARCs.
   This code is not finished yet.

+ELSA PCMCIA MicroLink cards
+CONFIG_HISAX_ELSA_CS
+  This enables the PCMCIA client driver for the Elsa PCMCIA MicroLink
+  card
+
+Sedlbauer PCMCIA cards
+CONFIG_HISAX_SEDLBAUER_CS $CONFIG_PCMCIA
+  This enables the PCMCIA client driver for the Sedlbauer Speed Star
+  and Speed Star II cards.
+
 PCBIT-D support
 CONFIG_ISDN_DRV_PCBIT
   This enables support for the PCBIT ISDN-card. This card is
@@ -15503,6 +15513,33 @@
   compile it as a module, say M here and read
   Documentation/modules.txt.

+CAPI2.0 /dev/capi20 support
+CONFIG_ISDN_CAPI_CAPI20
+  This option will provide the CAPI 2.0 interface to userspace
+  applications via /dev/capi20. Applications should use the standardized
+  libcapi20 to access this functionality. You should say Y/M here.
+
+CAPI2.0 Middleware support
+CONFIG_ISDN_CAPI_MIDDLEWARE
+  This option will enhance the capabilities of the /dev/capi20 interface.
+  It will provide a means of moving a data connection, established
+  via the usual /dev/capi20 interface to a special tty device. If you want
+  to use pppd with pppdcapiplugin to dial up to your ISP, say Y here.
+
+CAPI2.0 filesystem support
+CONFIG_ISDN_CAPI_CAPIFS_BOOL
+  This option provides a special file system, similar to /dev/pts with
+  device nodes for the special ttys established by using the middleware
+  extension above. If you want to use pppd with pppdcapiplugin to dial up
+  to your ISP, say Y here.
+
+CAPI2.0 capidrv interface support
+CONFIG_ISDN_CAPI_CAPIDRV
+  This option provides the glue code to hook up CAPI driven cards to
+  the legacy isdn4linux link layer. If you have a card which is supported
+  by a CAPI driver, but still want to use old features like ippp
+  interfaces or ttyI emulation, say Y/M here.
+
 AVM B1 ISA support
 CONFIG_ISDN_DRV_AVMB1_B1ISA
   Enable support for the ISA version of the AVM B1 card.
@@ -15523,6 +15560,11 @@
 AVM B1/M1/M2 PCMCIA support
 CONFIG_ISDN_DRV_AVMB1_B1PCMCIA
   Enable support for the PCMCIA version of the AVM B1 card.
+
+AVM B1/M1/M2 PCMCIA cs module
+CONFIG_ISDN_DRV_AVMB1_AVM_CS
+  Enable the PCMCIA client driver for the AVM B1/M1/M2
+  PCMCIA cards.

 AVM T1/T1-B PCI support
 CONFIG_ISDN_DRV_AVMB1_T1PCI
diff -ur linux-2.4.4-pre4/drivers/isdn/Config.in 
linux-2.4.4-pre4.config/drivers/isdn/Config.in
--- linux-2.4.4-pre4/drivers/isdn/Config.in Thu Apr 19 21:49:37 2001
+++ linux-2.4.4-pre4.config/drivers/isdn/Config.in  Thu Apr 19 22:49:07 2001
@@ -110,8 +110,8 @@
 tristate   'CAPI2.0 support' CONFIG_ISDN_CAPI
 if [ "$CONFIG_ISDN_CAPI" != "n" ]; then
bool'  Verbose reason code reporting (kernel size +=7K)' 
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON
-   dep_bool'  CAPI2.0 Middleware support (EXPERIMENTAL)' 
CONFIG_ISDN_CAPI_MIDDLEWARE $CONFIG_EXPERIMENTAL
dep_tristate'  CAPI2.0 /dev/capi support' CONFIG_ISDN_CAPI_CAPI20 
$CONFIG_ISDN_CAPI
+   dep_mbool   '  CAPI2.0 Middleware support (EXPERIMENTAL)' 
+CONFIG_ISDN_CAPI_MIDDLEWARE $CONFIG_ISDN_CAPI_CAPI20 $CONFIG_EXPERIMENTAL
if [ "$CONFIG_ISDN_CAPI_MIDDLEWARE" = "y" ]; then
   dep_mbool'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS_BOOL 
$CONFIG_ISDN_CAPI_CAPI20
   if [ "$CONFIG_ISDN_CAPI_CAPIFS_BOOL" = "y" ]; then
diff -ur linux-2.4.4-pre4/drivers/isdn/avmb1/b1dma.c 
linux-2.4.4-pre4.config/drivers/isdn/avmb1/b1dma.c
--- linux-2.

RE: A little problem.

[Bingner Sam J. Contractor RSIS]

sounds to me like you have the wrong source in /usr/src/linux there is a
module you can install, or you can do it as I normally would...

obtain kernel source for 2.2.18 from ftp.kernel.org and put it in "/usr/src"
(/pub/linux/kernel/v2.2/linux-2.2.18.tar.bz2)

remove the symlink in /usr/src
"rm -f /usr/src/linux"

extract the new kernel source tree
"cd /usr/src ; tar xfI linux-2.2.18.tar.bz2"

rename the directory to kernel version and create symlink (for consistancy)
"mv linux linux-2.2.18 ; ln -s linux-2.2.18 linux"


Sam Bingner
PACAF CSS/SCHE
Contractor RSIS
DSN 315 449-7889
COMM808 449-7889


-Original Message-
From: Hai Xu [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 10:47 AM
To: [EMAIL PROTECTED]
Subject: A little problem.kernel


Dear all,

I have a question about the kernel used by the RedHat. I am using Redhat 7.0
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.

#include 
#if defined(__module__smp)
#define UTS_RELEASE "2.4.0-0.26smp"
#else
#define UTS_RELEASE "2.4.0-0.26"
#endif
#define LINUX_VERSION_CODE 132096
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))


 But when I "cat /proc/version", it will give me:

Linux version 2.2.18-rtl (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #1 Thu Apr 5 23:10:12 EDT 2001

So I am totally confused by the RedHat. So could you please tell me how to
solve this problem?

I just want to use the 2.2.18 without the 2.4.0. I did not install this one,
I also do not know where this one comes from.

Thanks in advance.
Hai Xu



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

Re: Cross-referencing frenzy

[Jim Treadway]

On Thu, 19 Apr 2001, Eric S. Raymond wrote:

> Andreas Dilger <[EMAIL PROTECTED]>:
> > However, I'm not sure that your reasoning for removing these is correct.
> > For example, one symbol that I saw was CONFIG_EXT2_CHECK, which is code
> > that used to be enabled in the kernel, but is currently #ifdef'd out with
> > the above symbol.  When Ted changed this, he wasn't sure whether we would
> > need the code again in the future.  I enable it sometimes when I'm doing
> > ext2 development, but it may not be worthy of a separate config option
> > that 99.9% of people will just be confused about.
>
> I think things like that don't belong in the CONFIG_ namespace to begin
> with.

How about CONFIG_DEBUG_ or just simply DEBUG_?  You could even have a CML
add-on or switch that configures the various DEBUG_ options (but perhaps
thats a bit too strange).


-
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

[Linus Torvalds]

On Thu, 19 Apr 2001, Ingo Oeser wrote:

> On Thu, Apr 19, 2001 at 09:11:56AM -0700, Linus Torvalds wrote:
> > No, this is NOT what the UNIX dogmas are all about.
> >
> > When UNIX says "everything is a file", it really means that "everything is
> > a stream of bytes". Things like magic operations on file desciptors are
> > _anathema_ to UNIX. ioctl() is the worst wart of UNIX. Having magic
> > semantics of file descriptors is NOT Unix dogma at all, it is a horrible
> > corruption of the original UNIX cleanlyness.
>
> Right. And on semaphores, this stream is exactly 0 bytes long.
> This is perfectly normal and can be handled by all applications
> I'm aware of.

It's perfectly normal, but it does NOT conform to the idea "everything is
a file".

The fact that there are other ugly examples (ioctls and special files)
does not mean that adding a new one is a good idea.

When people say "everything is a file", they mean that it can be _used_ as
a file, not that it can passably return a valid error code.

Linus

-
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: sk->state_chage is not called for listening sockets

[David S. Miller]

Pete Zaitcev writes:
 > With that in mind, would the following chage have any ill effects?
 > It does not seem to break anything obvious, but I am worried about
 > a performance degradation for some retarded benchmark.
 > 
 > diff -u -U 4 linux-2.4.3/net/ipv4/tcp_input.c linux-2.4.3-nfs/net/ipv4/tcp_input.c
 > --- linux-2.4.3/net/ipv4/tcp_input.c Fri Feb  9 11:34:13 2001
 > +++ linux-2.4.3-nfs/net/ipv4/tcp_input.c Thu Apr 12 23:23:59 2001

I've applied this patch, thanks.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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

[Linus Torvalds]

On Thu, 19 Apr 2001, Ingo Oeser wrote:
>
> Are you sure, you can implement SMP-safe, atomic operations (which you need
> for all up()/down() in user space) WITHOUT using privileged
> instructions on ALL archs Linux supports?

Why do you care?

Sure, there are broken architectures out there. They'd need system calls.
They'd be slow. That's THEIR problem.

No sane architecture has this limitation.

Linus

-
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

[AJ Lewis]

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.
> 
> And I wonder, if kernel hackers are saying lvm is broken... why do you
> want to freeze it and ship it in that state?

Hmm...perhaps I didn't make myself clear.  AFAIK Heinz is not putting
cosmetic changes into the CVS.  The team should be putting fixes in.  If
they aren't it's because they are dealing with backlog.

As far as the smaller patches go.  I know.  We're working on it; really we
are.

Regards,
-- 
AJ Lewis
Sistina Software Inc.  Voice:  612-379-3951
1313 5th St SE, Suite 111  Fax:612-379-3952
Minneapolis, MN 55414  E-Mail: [EMAIL PROTECTED]
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-Begin Obligatory Humorous Quote
There's nary an animal alive that can outrun a greased Scotsman.
   - Groundskeeper Willie
-End Obligatory Humorous Quote--

 PGP signature

Re: light weight user level semaphores

[Linus Torvalds]

On 19 Apr 2001, Ulrich Drepper wrote:

> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > Looks good to me. Anybody want to try this out and test some benchmarks?
>
> I fail to see how this works across processes.

It's up to FS_create() to create whatever shared mapping is needed.

For threads, you don't need anything special.

For fork()'d helper stuff, you'd use MAP_ANON | MAP_SHARED.

For execve(), you need shm shared memory or MAP_SHARED on a file.

It all depends on your needs.

Linus

-
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

[Ingo Oeser]

On Thu, Apr 19, 2001 at 09:11:56AM -0700, Linus Torvalds wrote:
> No, this is NOT what the UNIX dogmas are all about.
> 
> When UNIX says "everything is a file", it really means that "everything is
> a stream of bytes". Things like magic operations on file desciptors are
> _anathema_ to UNIX. ioctl() is the worst wart of UNIX. Having magic
> semantics of file descriptors is NOT Unix dogma at all, it is a horrible
> corruption of the original UNIX cleanlyness.

Right. And on semaphores, this stream is exactly 0 bytes long.
This is perfectly normal and can be handled by all applications
I'm aware of.

My idea violates nothing here.

> Please don't excuse "semaphore file descriptors" with the "everything is a
> file" mantra. It is not at ALL applicable.
> 
> The "everything is a file" mantra is to make pipe etc meaningful -
> processes don't have to worry about whether the fd they have is from a
> file open, a pipe() system call, opening a special block device, or a
> socket()+connect() thing. They can just read and write. THAT is what UNIX
> is all about.
 
Right. And with my approach read() and write() with a buffer
pointer != NULL would either yield an return value of "0" or
-1 and set errno=EINVAL ("object not suitable for reading/writing").
Anyway they should return IMMIDIATELY in these cases.

We already have these special semantics with devices. Look at
/dev/sgX for an example how we pass even structured data via
normal read/write (instead of "stream of bytes").

> And this is obviously NOT true of a "magic file descriptors for
> semaphores". You can't pass it off as stdin to another process and expect
> anything useful from it unless the other process _knows_ it is a special
> semaphore thing and does mmap magic or something.

see above. NOTHING special about this idea. No magic handling
involved, unless the user of the fd knows what it is. For other
users it will be just a normal fd with normal operations, since
the special case is hidden well enough. 

This is even WAY simpler as all that tty-crap and similar
devices, which read/write very dependend on their actual ioctl
configuration.

But since stupid POSIX forbids using fds for semaphores
(according to Ulrich Drepper), this nice, simple and
non-intrusive solution is out.

Instead we should go with several new syscalls, user space
dependencies, strange error handling and yet-to-discuss
semantics.

Everybody else byt you would have been kicked out by the core
people for suggesting this ;-)

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
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/

A little problem.

[Hai Xu]

Dear all,

I have a question about the kernel used by the RedHat. I am using Redhat 7.0
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.

#include 
#if defined(__module__smp)
#define UTS_RELEASE "2.4.0-0.26smp"
#else
#define UTS_RELEASE "2.4.0-0.26"
#endif
#define LINUX_VERSION_CODE 132096
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))


 But when I "cat /proc/version", it will give me:

Linux version 2.2.18-rtl (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #1 Thu Apr 5 23:10:12 EDT 2001

So I am totally confused by the RedHat. So could you please tell me how to
solve this problem?

I just want to use the 2.2.18 without the 2.4.0. I did not install this one,
I also do not know where this one comes from.

Thanks in advance.
Hai Xu



-
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: CONFIG_PACKET_MMAP help

[Edgar Toernig]

Hi,

[EMAIL PROTECTED] wrote:
> 
> 1. for tp_frame_size, I dont want to truncate any data on ethernet, I
> need 1514 bytes, is this the best way to do it and not waste space?
> 
> static const int TURBO_FRAME_SIZE=
>  TPACKET_ALIGN(TPACKET_ALIGN(sizeof(tpacket_hdr)) +
>TPACKET_ALIGN(sizeof(struct sockaddr_ll)+ETH_HLEN) + 1500);

Looks OK.  Maybe instead of ETH_HLEN min(ETH_HLEN,16)?  The framesize
calculation is really strange...

> 2. what is tp_block_nr for?  I dont understand it, I just set it to 1
> and make tp_block_size big enough for all the frames I need, so its
> just one contiguous space, all I need is about a megabyte I think.

Better go the other way around - set tb_block_size to PAGE_SIZE and
tb_block_nr appropriate.  tb_block_size is the contiguous physical memory
the kernel tries to allocate.  Anything above PAGE_SIZE is likely to fail.
For you that would mean only 2 packets per 4k-page.  You could try to
start with bigger (power of 2) block sizes and go down to smaller ones if
it fails (ENOMEM). [1].  Btw, there's in implicit limit on tb_block_nr.
The vector to manage the blocks is kmalloc'ed and may not be larger than
128kb giving max 32768 blocks.  Hmm... moment... seems there's a similar
limit for tp_frame_nr (max 32768 frames).  I'm pretty sure _that_ limit
was not there when I worked with this during 2.3.  Not so nice on gigabit
ethernet :-(

> 3. is this the general approach for the api?
> [...]

Looks OK too.

>if (tp->status == 0) poll() for pollin on the socket  /* is there a
>race here? */

No race.

> 4. what does the copy threshold setsockopt tuning accomplish? doesnt it always
> have to copy anyway, to the mmaped area?

I haven't used it myself.  Reading the sources it does something different.
Afaics when active if there's a packet that has been truncated by the
framesize it is additionally stored in the socket's receive queue to be
fetched by a normal read/recv.  It notifies you about this by setting
the TP_STATUS_COPY bit.  So it seems to mean: copy to socket if threshold
(framesize) exceeded.

Ciao, ET.


[1] The PACKET_RX_RING sockopt accepts all block sizes that are a multiple
of PAGE_SIZE but always allocates a power of 2 size chunk.  So using non
power of 2 sizes will waste locked kernel memory.

-
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

[Ulrich Drepper]

Ingo Oeser <[EMAIL PROTECTED]> writes:

> Are you sure, you can implement SMP-safe, atomic operations (which you need
> for all up()/down() in user space) WITHOUT using privileged
> instructions on ALL archs Linux supports?

Which processors have no such instructions but are SMP-capable?

> How do we do this on nccNUMA machines later? How on clusters[1]?

Clusters are not my problem.  They require additional software.  And
NUMA machines maybe be requiring a certain sequence in which the
operations must be performed and the hardware should take care of the
rest.


I don't really care what the final implementation will be like.  For
UP and SMP machines I definitely want to have as much as possible at
user-level.  If you need a special libpthread for NUMA machines, so be
it.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.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: Your message to linux-lvm awaits moderator approval

[Rik van Riel]

On Thu, 19 Apr 2001, Christoph Hellwig wrote:
> On Thu, Apr 19, 2001 at 09:56:52PM +0200, [EMAIL PROTECTED] wrote:
> > Your mail to 'linux-lvm' with the subject
> >
> > Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list
> >
> > Is being held until the list moderator can review it for approval.

[snip moderator message]

> This doesn't look very open btw.  And I'm a longtime subsriber to linux-lvm...

It seems I was also put on moderation just after the message
that they opened up the list.

Either they're not telling us the truth, or they don't know
how to handle their mailer setup. I don't particularly care
which, because with both possible reasons I've pretty much
lost trust in their ability to handle Linux LVM development.

Well, no, I've lost it a long time ago after Andreas' patches
got dropped over and over again and comments on the LVM code
got refused by the moderators at Sistina ...

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.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/

PROBLEM: Segfault reading SCSI MO - System hang while writing

[Thomas Herberg]

[1.] Segfault reading SCSI MO - System hang while writing

[2.] Hello *
with kernel 2.4.x (actually 2.4.3) i ran into a problem acessing my SCSI MO. 
As everything works fine with 2.2.x (actually 19) the problem seems to be new 
in the 2.4.x kernel series and therefore you might want to take a look. 

I can mount the MO (/dev/sda) as /mnt/mod fs:vfat and do a ls with no problem 
or warning and i can cd to the directories of the MO. But if i try to open a 
file for example to copy it to somewhere i get a segfault. A try to write to 
it is even more worse, my system hangs immediately. After the error the 
device can't be unmounted any more. 

I don't think that the problem is in the hardware related driver (sym53c8xx) 
because i tried it with the ncr53c8xx and 53c7,8xx too with the same result. 
What i tried also is to mount the MO as msdos and umsdos and it produced the 
segfault too.

[3.] SCSI vfat 53c810 MO

[4.] Linux version 2.4.3 (root@camelot) (gcc version 2.95.2 19991024 
(release)) #4 Wed Apr 18 15:09:02 CEST 2001

[5.] ksymoops.out
[6.] cp /mnt/mod/somefile /tmp -> Segfault cp somefile /mnt/mod/somefile  
-> crash
[7.] Environment
[7.1.] ver_linux.out
[7.2.] cpuinfo.out
[7.3.] modules.out
[7.4.] ioports.out, iomem.out
[7.5.] lspci.out 
[7.6.] scsi.out

greetings

Thomas Herberg

Email: [EMAIL PROTECTED]



ksymoops 2.4.0 on i686 2.4.3.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.3/ (default)
 -m /boot/System.map-2.4.3 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Apr 19 17:35:07 camelot kernel: Unable to handle kernel NULL pointer dereference at 
virtual address 
Apr 19 17:35:07 camelot kernel: 
Apr 19 17:35:07 camelot kernel: *pde = 
Apr 19 17:35:07 camelot kernel: Oops: 
Apr 19 17:35:07 camelot kernel: CPU:0
Apr 19 17:35:07 camelot kernel: EIP:0010:[<>]
Using defaults from ksymoops -t elf32-i386 -a i386
Apr 19 17:35:07 camelot kernel: EFLAGS: 00010286
Apr 19 17:35:07 camelot kernel: eax:    ebx: c68352a0   ecx: 1000   edx: 
c68352c0
Apr 19 17:35:07 camelot kernel: esi: bfffe19c   edi:    ebp: 1000   esp: 
c0a9ff80
Apr 19 17:35:07 camelot kernel: ds: 0018   es: 0018   ss: 0018
Apr 19 17:35:07 camelot kernel: Process cp (pid: 1383, stackpage=c0a9f000)
Apr 19 17:35:07 camelot kernel: Stack: c014e68d c68352a0 bfffe19c 1000 c68352c0 
c68352a0 ffea c012bc06 
Apr 19 17:35:07 camelot kernel:c68352a0 bfffe19c 1000 c68352c0 c0a9e000 
b694 bfffe19c b244 
Apr 19 17:35:07 camelot kernel:c0106d5f 0003 bfffe19c 1000 b694 
bfffe19c b244 0003 
Apr 19 17:35:07 camelot kernel: Call Trace: [fat_file_read+45/52] [sys_read+150/204] 
[system_call+51/56] 
Apr 19 17:35:07 camelot kernel: Code:  Bad EIP value.

>>EIP;  Before first symbol


1 warning issued.  Results may not be reliable.


If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux camelot 2.4.3 #4 Wed Apr 18 15:09:02 CEST 2001 i686 unknown
 
Gnu C  2.95.2
Gnu make   3.79.1
binutils   2.10.0.33
util-linux 2.10q
modutils   2.4.2
e2fsprogs  1.19
PPP2.4.0
isdn4k-utils   3.1pre1a
Linux C Libraryx1 root root  1382179 Jan 19 07:14 /lib/libc.so.6
Dynamic linker (ldd)   2.2
Procps 2.0.7
Net-tools  1.57
Kbd1.02
Sh-utils   2.0
Modules Loaded sb sb_lib uart401 sound soundcore isa-pnp af_packet hisax isdn 
ipchains ntfs


processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 6
model name  : Celeron (Mendocino)
stepping: 0
cpu MHz : 334.098
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 
mmx fxsr
bogomips: 666.82



sb  7376   0 (autoclean)
sb_lib 33728   0 (autoclean) [sb]
uart401 6384   0 (autoclean) [sb_lib]
sound  56976   0 (autoclean) [sb_lib uart401]
soundcore   3952   5 (autoclean) [sb_lib sound]
isa-pnp28016   0 (autoclean) [sb]
af_packet   7968   1 (autoclean)
hisax 135760   4
isdn  

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

[Miles Lane]

AJ Lewis wrote:

> On Thu, Apr 19, 2001 at 08:02:50PM +0100, Alan Cox wrote:
> 
>>Well their approach to patches that fix bugs is to reject emails. They've done
>>that to stuff I've reported any many others. So there is a problem. And its
>>kind of hard to discuss a problem when you are being moderated out of existance.
>>
> 
> 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.


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.


Miles

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