Re: [PATCH *] VM patch for 2.4.0-test8

[Juan J. Quintela]

> "david" == David S Miller <[EMAIL PROTECTED]> writes:

david> In page_launder() about halfway down there is this sequence of tests
david> on LRU pages:

david> if (!clearedbuf) {
david>  ...
david> } else if (!page->mapping) {
david>  ...
david> } else if (page_count(page) > 1) {
david> } else /* page->mapping && page_count(page) == 1 */ {
david>  ...
david> }

david> Above this sequence we've done a page_cache_get.  For the final case
david> in the tests above (page->mapping != NULL && page_count(page) == 1)
david> have you checked if this ever happens or is even possible?

david> If the page is a page cache page (ie. page->mapping != NULL) it
david> should hold a reference.  Adding in our reference, the count should
david> always thus be > 1.

david> What did I miss?

I think nothing, I suppose that riel means > 2 and == 2, if we arrive
there when a page count of 1 we are in problems as you have told.

/me doing greping .. 

I can only see one place where we add a page to the page cache and we
don't increase its page count, and it is in grow_buffers().  Could
somebody explain me _why_ we don't need to do a page_cache_get(page)
in that function? 

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [bad PATCH] - arch/ppc/config.in for 2.{3,4}.* to get PCI righton G4

[Chris Bednar]

> The code in arch/ppc/config.in looks correct to me.

   Yes, to me, too. And to menuconfig and config, but
not to xconfig.


> Please provide more details on how it "doesn't work here":

   You've hit on at least one thing; the problem only comes
up in `make xconfig'; under ``General setup'', there's a
greyed-out selection for ``QSpan PCI'', and everything else
after that that depends on CONFIG_PCI (such as ``PCI device
name database'' 6 fields down, ``DECChip tulip'' and a host
of other ethernet controllers, and FireWire, to name a few)
are also grey.



> Also attach your .config file.

Well, which one? It doesn't matter whether I start
without one, or with one of mine own, or with the one
that happens to sit in Paul Mackerras' 2.4.0t8 tree...
The one I'm using was made with my hack to arch/ppc/config.in,
so it's probably not relevant, either, but I'll send it anyway.

   I feel like a dork for never thinking to try menuconfig
or even plain ole config, but I guess it needs to be fixed,
anyway.

   Thanks



Chris J. Bednar   
Director, Distributed Computing Product Group
http://AdvancedDataSolutions.com/



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

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
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_8260 is not set
# CONFIG_8xx is not set
CONFIG_ALL_PPC=y
# CONFIG_GEMINI is not set
# CONFIG_EST8260 is not set
# CONFIG_APUS is not set
# CONFIG_SMP is not set
CONFIG_ALTIVEC=y

#
# General setup
#
# CONFIG_HIGHMEM is not set
CONFIG_MOL=y
# CONFIG_ISA is not set
# CONFIG_SBUS 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=m
CONFIG_CARDBUS=y

#
# Parallel port support
#
# CONFIG_PARPORT is not set
# CONFIG_VGA_CONSOLE is not set
CONFIG_FB=y
CONFIG_FB_COMPAT_XPMAC=y
CONFIG_PPC_RTC=y
CONFIG_PROC_DEVICETREE=y
CONFIG_BOOTX_TEXT=y
# CONFIG_MOTOROLA_HOTSWAP is not set
# CONFIG_CMDLINE_BOOL is not set

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

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

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_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_LVM is not set
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y

#
# 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=y
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 is not set

#
#   IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
# CONFIG_IP_NF_MATCH_LIMIT is not set
# CONFIG_IP_NF_MATCH_MAC is not set
# CONFIG_IP_NF_MATCH_MARK is not set
# CONFIG_IP_NF_MATCH_MULTIPORT is not set
# CONFIG_IP_NF_MATCH_TOS is not set
# CONFIG_IP_NF_MATCH_STATE is not set
# CONFIG_IP_NF_MATCH_UNCLEAN is not set
# CONFIG_IP_NF_MATCH_OWNER is not set
CONFIG_IP_NF_FILTER=y
# CONFIG_IP_NF_TARGET_REJECT is not set
# CONFIG_IP_NF_TARGET_MIRROR is not set
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
# CONFIG_IP_NF_TARGET_REDIRECT is not set
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_TARGET_LOG 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=m
# 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_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
CO

Re: Update Linux 2.4 Status/TODO list

[Andre Hedrick]

Ted and LT,

I think this are the two things you wanted that were located in:

/src/tar-files/testing/direct_add/ht6560b.c
/src/tar-files/testing/direct_add/qd65xx.c
/src/tar-files/testing/direct_add/qd65xx.h

First Petr and Samuel, are these good to go into 2.4.0 ??

Cheers,

Andre Hedrick
The Linux ATA/IDE guy


/*
 *  TEMPORARY VERSION FOR HT6560A MODEL TESTING!
 *
 *  MODIFIED FOR BOTH A AND B VERSIONS
 *  2000-07-16  Petr Soucek <[EMAIL PROTECTED]>
 */

/*
 *  linux/drivers/block/ht6560b.c   Version 0.07Feb  1, 2000
 *
 *  Copyright (C) 1995-2000  Linus Torvalds & author (see below)
 */

/*
 *
 *  Version 0.01Initial version hacked out of ide.c
 *
 *  Version 0.02Added support for PIO modes, auto-tune
 *
 *  Version 0.03Some cleanups
 *
 *  Version 0.05PIO mode cycle timings auto-tune using bus-speed
 *
 *  Version 0.06Prefetch mode now defaults no OFF. To set
 *  prefetch mode OFF/ON use "hdparm -p8/-p9".
 *  Unmask irq is disabled when prefetch mode
 *  is enabled.
 *
 *  Version 0.07Trying to fix CD-ROM detection problem.
 *  "Prefetch" mode bit OFF for ide disks and
 *  ON for anything else.
 *
 *
 *  HT-6560B EIDE-controller support
 *  To activate controller support use kernel parameter "ide0=ht6560b".
 *  Use hdparm utility to enable PIO mode support.
 *
 *  Author:Mikko Ala-Fossi<[EMAIL PROTECTED]>
 * Jan Evert van Grootheest   <[EMAIL PROTECTED]>
 *
 *  Try:  http://www.maf.iki.fi/~maf/ht6560b/
 */

#define HT6560B_VERSION "v0.07"

#undef REALLY_SLOW_IO   /* most systems can safely undef this */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include "ide_modes.h"

#define DEBUG  /* remove comments for DEBUG messages */

/*
 * The special i/o-port that HT-6560B uses to configuration:
 *bit0 (0x01): "1" selects secondary interface
 *bit2 (0x04): "1" enables FIFO function
 *bit5 (0x20): "1" enables prefetched data read function  (???)
 *
 * The special i/o-port that HT-6560A uses to configuration:
 *bit0 (0x01): "0" selects secondary interface
 *bit1 (0x02): "0" enables prefetched data read function
 *bit2 (0x04): "0" enables multi-master system(?)
 *bit3 (0x08): "1" 3 cycle time, "0" 2 cycle time (?)
 */
#define HT_CONFIG_PORT0x3e6
#define HT_CONFIG(drivea) (byte)(((drivea)->drive_data & 0xff00) >> 8)
/*
 * FIFO + PREFETCH (both a/b-model)
 */
#define HT_CONFIG_DEFAULT 0x1c /* no prefetch */
/* #define HT_CONFIG_DEFAULT 0x3c */ /* with prefetch */
#define HT_CONFIG_DEFAULT_A 0x0f /* no prefetch */
/* #define HT_CONFIG_DEFAULT_A 0x0d */ /* with prefetch */
#define HT_SECONDARY_IF   0x01
#define HT_PREFETCH_MODE  0x20
#define HT_PREFETCH_MODE_A  0x02

/*
 * ht6560b Timing values:
 *
 * I reviewed some assembler source listings of htide drivers and found
 * out how they setup those cycle time interfacing values, as they at Holtek
 * call them. IDESETUP.COM that is supplied with the drivers figures out
 * optimal values and fetches those values to drivers. I found out that
 * they use IDE_SELECT_REG to fetch timings to the ide board right after
 * interface switching. After that it was quite easy to add code to
 * ht6560b.c.
 *
 * IDESETUP.COM gave me values 0x24, 0x45, 0xaa, 0xff that worked fine
 * for hda and hdc. But hdb needed higher values to work, so I guess
 * that sometimes it is necessary to give higher value than IDESETUP
 * gives.   [see cmd640.c for an extreme example of this. -ml]
 *
 * Perhaps I should explain something about these timing values:
 * The higher nibble of value is the Recovery Time  (rt) and the lower nibble
 * of the value is the Active Time  (at). Minimum value 2 is the fastest and
 * the maximum value 15 is the slowest. Default values should be 15 for both.
 * So 0x24 means 2 for rt and 4 for at. Each of the drives should have
 * both values, and IDESETUP gives automatically rt=15 st=15 for CDROMs or
 * similar. If value is too small there will be all sorts of failures.
 *
 * Timing byte consists of
 *  High nibble:  Recovery Cycle Time  (rt)
 *   The valid values range from 2 to 15. The default is 15.
 *
 *  Low nibble:   Active Cycle Time(at)
 *   The valid values range from 2 to 15. The default is 15.
 *
 * You can obtain optimized timing values by running Holtek IDESETUP.COM
 * for DOS. DOS drivers get their timing values from command line, where
 * the first value is the Recovery Time and the second value is the
 * Active Time for each drive. Smaller value gives higher speed.
 * In case of failures you should probably fall back to a higher value.
 */
#define HT_TIMING(

Re: [PATCH *] VM patch for 2.4.0-test8

[David S. Miller]

In page_launder() about halfway down there is this sequence of tests
on LRU pages:

if (!clearedbuf) {
 ...
} else if (!page->mapping) {
 ...
} else if (page_count(page) > 1) {
} else /* page->mapping && page_count(page) == 1 */ {
 ...
}

Above this sequence we've done a page_cache_get.  For the final case
in the tests above (page->mapping != NULL && page_count(page) == 1)
have you checked if this ever happens or is even possible?

If the page is a page cache page (ie. page->mapping != NULL) it
should hold a reference.  Adding in our reference, the count should
always thus be > 1.

What did I miss?

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

Re: New topic (PowerPC Linux PCI HELL)

[Andre Hedrick]

On Wed, 13 Sep 2000, David S. Miller wrote:

>Date:  Wed, 13 Sep 2000 18:00:02 -0700 (PDT)
>From: Matthew Jacob <[EMAIL PROTECTED]>
> 
>This seems to be an artifact of some OBP implementations for PPC-
>apples in particular.
> 
>It assigns both I/O and Mem addrs and IRQs, but doesn't enable
>either memory or I/O. So you have to do it for it.
> 
> Yeah, but this doesn't belong in the drivers that is for sure.

Verified, because it fails and it is way to late.

> It belongs in arch/ppc/kernel/*pci*.c
> 
> This is precisely the kind of compat stuff which should be fixed up in
> the arch-specific PCI support code.

Martin, cross-platform party on PCI stuff


Andre Hedrick
The Linux ATA/IDE guy


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

In Search of "Michel Lanners" (Re:(PowerPC Linux PCI HELL))

[Andre Hedrick]

Bogus Patch :-(

This is what I did also but more brut force with verification of IO's and
it still craps out..

On Wed, 13 Sep 2000, Daniel Jacobowitz wrote:

> On Wed, Sep 13, 2000 at 05:29:58PM -0700, Andre Hedrick wrote:
> > 
> > Okay who can teach me how to force hooks and ram this down the PPC
> > 
> > pci_write_config_word(dev, PCI_COMMAND, 0x05);
> > 
> > I have all the address registered.
> > My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> > alive.  Thus I get some of the most beuatiful lockups ever.
> > I suspect that this needs to be handled down in the arch.
> > 
> > ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
> > 
> > Basically I can not get the IO's active, regardless of BIOS on the card.
> > Yes this is the old trick that used to work of making ix86 cards run in
> > non ix86-pci slots.
> > 
> > Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> > under Mac OS, but the IO's are not enable in linux and it crash like a big
> > dog also.
> 
> I'm going to bet you need to look at Michel Lanners' (did I spell that
> right this time?) PCI patches.  For instance, I've always needed this
> hideous patch on my 7300/200 to get a Promise Ultra66 card to work:
> 
> diff -ur merging-bk/drivers/block/ide-pci.c work-bk/drivers/block/ide-pci.c
> --- merging-bk/drivers/block/ide-pci.cTue Apr  4 22:19:16 2000
> +++ work-bk/drivers/block/ide-pci.c   Thu Mar  9 15:33:25 2000
> @@ -468,6 +468,15 @@
>   printk("%s: error accessing PCI regs\n", d->name);
>   return;
>   }
> +#ifdef __powerpc__
> + if (!(pcicmd & PCI_COMMAND_IO)) {   /* is device disabled? */
> + pci_write_config_word(dev, PCI_COMMAND, pcicmd | PCI_COMMAND_IO);
> + if (pci_read_config_word(dev, PCI_COMMAND, &pcicmd)) {
> + printk("%s: error accessing PCI regs\n", d->name);
> + return;
> + }
> + }
> +#endif
>   if (!(pcicmd & PCI_COMMAND_IO)) {   /* is device disabled? */
>   /*
>* PnP BIOS was *supposed* to have set this device up for us,
> 
> 
> Dan
> 
> /\  /\
> |   Daniel Jacobowitz|__|SCS Class of 2002   |
> |   Debian GNU/Linux Developer__Carnegie Mellon University   |
> | [EMAIL PROTECTED] |  |   [EMAIL PROTECTED]  |
> \/  \/
> 

Andre Hedrick
The Linux ATA/IDE guy

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

Re: PowerPC Linux for AS/400 & RS/6000 Hardware

[Cort Dougan]

} > Cort Dougan recently announced he was no longer going to be maintaining
} > the PowerPC Linux tree.

What I'd said was I'm taking a vacation from maintaining the PPC-tree for a
while so I can do some of my real job.  I'm not abandoning it in any way -
just spending less time on it for a while.

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

Re: [bad PATCH] - arch/ppc/config.in for 2.{3,4}.* to get PCI right on G4

[Michael Elizabeth Chastain]

> The point is that there's some pollution in arch/ppc/config.in
> that doesn't allow a G4 user (for example) to configure a
> host of PCI devices.

The code in arch/ppc/config.in looks correct to me.

Please provide more details on how it "doesn't work here":

Are you using 'make config', menuconfig, or xconfig?
What menu are you on that gives the bad result?
Which PCI devices are you failing to see?

Also attach your .config file.

Michael Elizabeth Chastain

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

[PATCH *] VM patch for 2.4.0-test8

[Rik van Riel]

Hi,

The new VM patch seems has received a major amount of
code cleanup, performance tuning and stability improvement
over the last few days and is now almost production
quality, with the following 4 items left for 2.4:

- improve streaming IO performance
- out of memory handling
- integrate Ben LaHaise's readahead on the VMA level
  (and make drop_behind() work for that) .. fixes kswapd cpu eating
- (maybe) make drop_behind() work better for some cases
- testing, testing, testing, testing ...

The post-2.4 TODO list contains these items:
- physical page based aging  (reduce kswapd cpu use more and
  do better/more fair page aging)
- much much better IO clustering  (neatly abstracted away?)
- page->mapping->flush() callback for journaling and network
  filesystems   (maybe later in 2.4)
- thrashing control (like process suspension?)


The new VM already seems to be more stable under load than the
old VM and tuning has taken it so far that I'm already running
into bottle necks in /other/ places (eg. the elevator code)
when putting the system under rediculously heavy load...

I haven't had much time to do things like dbench and tiobench
testing though, which is why I'm sending this email and asking
the enthousiast benchmarkers to give the patch a try and tell
me about the results.

Oh, and please don't restrict yourself to just the synthetic
benchmarks. The VM is there to give the best results for
applications that have something like a working set and has
not been tuned yet to give good performance for benchmarks
(which seem to run very much different from any application
I've ever seen).

regards,

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

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

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

Re: [PATCH][2.4.0t8] Rewritten drivers/ide/Makefile

[Michael Elizabeth Chastain]

Hi Bartlomiej,

> - Moved $(IDE_OBJS) (now $(ide-obj-y)) from MIX_OBJS to MI_OBJS
>   due the fact that they don't export any symbols (I hope).

They don't export any symbols.

> - Removed $(LD_RFLAG), I can't find any definition of it in the
>   kernel source tree and LD docs. WTF it is (was) used for?

You are right: 15 places use it, but nobody ever defines it.
It's the same in 2.2.17 as well.

I believe the intent was to define it as something like "-m elf_i386",
so that cross builds would be more likely to work.

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

Re: 2.4.0 and ZIP ppa

[Keith Owens]

Peter Christy wrote:
> A quick fix has been to put "alias sd_mod sd" in modules.conf, but then I
> have to rem it out if I use the old kernel.

/etc/modules.conf

if `kernelversion` == 2.4
alias sd_mod sd
endif

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

Re: Update Linux 2.4 Status/TODO list

[Alexander Viro]

On Wed, 13 Sep 2000, Marco d'Itri wrote:

> On Sep 13, [EMAIL PROTECTED] wrote:
> 
>  > * Innd data corruption, probably caused by bug truncation bug (Rik
>  >   van Riel)
> This bug has not been fixed, I can still reproduce it (but not every
> time). This is how it happens:
> 
> - INN (1.7.2+insync+other patches, the debian package I maintain) is
>   running
> - active is correct
> - I post an article, which is filed with the correct number
> - for *this group only* the high value is wrong and equal to the one
>   in the active file I precedently saved (in some cases this does not
>   happen and I can't notice anything wrong in the active file)
> - I stop INN
> - the whole active file is now 100% identical to the saved copy

Ugh... How about relevant subset of strace?

> Right now it happened after the daily expire run: I stopped INN and the
> file on disk changed to the copy I saved before expire started.

Wait a minute. I don't believe in on-disk file being restored by magic,
but I could believe in page(s) being never written to disk and giving the
impression of "update that doesn't stick". You have a file shorter than
one page, so in principle it seems to point to the handling of partially
truncated pages. Hmm...

BTW, how does test8+patch to block_truncate_page() behave? And what is the
block size on your fs?

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

Re: 2.4.0 and ZIP ppa

[Douglas Gilbert]

Peter Christy wrote:
> 
> OK, after a LOT of head scratching, I 've found the problem. At some point
> in its development, the name for the scsi sd module has changed from sd_mod
> to plain sd. Now I haven't seen this mentioned anywhere in the
> documentation, and its caught my system out totally.
> 
> A quick fix has been to put "alias sd_mod sd" in modules.conf, but then I
> have to rem it out if I use the old kernel.
> 
> Is there a better solution?

That 2.4 change was introduced about 2 months ago and it
is going to be put back to sd_mod.o because too many
tools assume that.

The author of that change (in a Makefile cleanup) said 
that module name change was an oversight. 


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

Re: no virtual memory

[Rik van Riel]

On Thu, 14 Sep 2000, Tulika Pradhan wrote:

> i want to build a kernel without virtual memory support. this is
> for a ppc based embbedded system. i read somewhere that VM can
> be disabled by setting the swap space size to 0. But where do i
> do this ?

Does the system have an MMU or not?

If it doesn't have an MMU, your best bet is to start from the
ucLinux code base.

Otherwise you can use the normal Linux code base and simply
run the thing without a swap area.

regards,

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

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

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

no virtual memory

[Tulika Pradhan]

hi !

i want to build a kernel without virtual memory support. this is for
a ppc based embbedded system. i read somewhere that VM can be disabled
by setting the swap space size to 0. But where do i do this ?

please help,

tulika
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

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

Re: Redhat 6.2 Panic in boot

[Keith Owens]

On Wed, 13 Sep 2000 23:35:55 -0300, 
Gianluca Brigandi <[EMAIL PROTECTED]> wrote:
>I just installed succesfully the RedHat 6.2 in a 1000Mhz AMD server.
>After I reboot, being finished the installation, the kernel starts and
>crashes in
>the following panic:
>
>disabling CPUID serial number general protection fault: 
>(...reg dump...)
>Kernel panic: attempted to kill the idle task!
>
>Any clue about this?

Follow the instructions in linux/REPORTING-BUGS when reporting bugs.

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

I am very sorry!

[Pan Renzi]

Sorry to send the letter to the wrong place.Specially thanks to
R.B.Johnson,B.Halley,S.Vandevender,M.Kreen,dave,E.Mouw.I'll never do this
stupid thing.
BTW:Could you read this message correctly?


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

Redhat 6.2 Panic in boot

[Gianluca Brigandi]

Hi,

I just installed succesfully the RedHat 6.2 in a 1000Mhz AMD server.
After I reboot, being finished the installation, the kernel starts and
crashes in
the following panic:

disabling CPUID serial number general protection fault: 
(...reg dump...)
Kernel panic: attempted to kill the idle task!

Any clue about this?

Thanks in advance.


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

test

[Gianluca Brigandi]

Sorry, this is a test


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

[BUG] 2.2.17 final crashes

[root]

Twice now I have experienced this crash, but I do not know how to
replicate it.  The system was under normal load (netscape, xmms, and few
other minor programs)  First, xmms stopped playing.  Then, the screen
went black and the system speaker began beeping feverously.  I reached
to hit the reboot button on my case, when it rebooted itself.  I have no
watchdog support compiled in.  My system is a:
500MHz AMD-K6/2
64MB RAM
M599LMR PCChips Motherboard

The kernel I'm running is 2.2.17 w/ ext3 patch.  Config availible upon
request.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: [ANNOUNCE] Darkstar Development Project

[mberglund]

On Wed, 13 Sep 2000, Stephen Frazier wrote:

> Does *BSD run on S390?

Ummm, hello, NO they do not. This is at least PART of the point. I
believe now is my chance to get out my clue-by-four.

FreeBSD has a GREAT idea(and really NetBSD as well). We might want to
consider adopting that idea. In this case, if we work toward a standard
base system across platforms it will be that much more simple to scale
up. Unix has notoriously been a pain to move from platform to platform
because of 'little differences here and there'. 

Lets remove this obstacle, however small. Make it a little easier to
migrate up to your 'big iron'. 

Because Linux already runs on a couple of platforms even NetBSD does not
run on, it seems logical to take their good ideas and steal them while we
have the edge Otherwise, one day we will wake up and they WILL run on
S390 and the like.

Currently it would be easier for us to organise just a little more than
it would be for them to get the those platforms up and running. I doubt it
will be that way forever.
 
This is an issue of using those good ideas that we might lack, and in this
case, I am certain we lack this kind of and quality of userland and system
and kernel integration.

We need some help getting the website built and getting some of this kind
of material documented. If we can do this, the word may travel a little
better. And (hopefully) clearer.

I hope this more clearly explains some of ideas and why thier ideas may be
good ones. And if not, give the BSD update system a shot. If you are an
admin I am sure you will like at least some of the functionality.


Later,
Matt


PS: If FreeBSD DID run on PPC and S390 and offer the company I work for
all the growth potential Linux does, there is a good chance that I would
already be there. I don't want this to happen, so I am hoping that
instead, we can raise the level of integration and upgradability here. I
would hate to have to trade my penguin in for a devil!

Unix is best described as an old, sturdy tree.
It is well structured, always growing, and has passed the test of time.


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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Ragnar Kjørstad]

On Wed, Sep 13, 2000 at 08:08:12PM -0300, Rik van Riel wrote:
> On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
> > On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
> > > > Another potentially stupid question:
> > > > When the queue gets too long/old, new requests should be put in
> > > > a new queue to avoid starvation for the ones in the current
> > > > queue, right?
> > > 
> > > Indeed. That would solve the problem...
> > 
> > I think something like this: (I don't know the current code, so maybe
> > this suggestion is really stupid.)
> > 
> > struct request_queue {
> > int4start_time;
> > struct request *list;
> > struct request_queue *next;
> > }
> > 
> > struct request_queue *current_queue;
> > 
> > function too_old (struct request_queue *q) {
> > /* can actually easily be implemented using time, nr of requests
> >or any other messure of amount of work */
> > if (current_time > q->start_time + MAXTIME)
> > return 1;
> > else
> > return 0;
> > }
> > 
> > function insert_request(struct request *new) {
> > struct request_queue *q=current_queue;
> > if (new->sectornr < current_sector);
> > q=q->next;
> > while (too_old(q))
> > q=q->next;
> > insert_request(q->list, new);
> > }
> 
> This (IMHO) is wrong. When the drive has trouble keeping up
> with requests in FCFS order, we should do some elevator sorting
> to keep throughput high enough to deal with the requests we get.

The "list" in each queue should be sorted. So, even if the queue is
too old, the requests will still be sorted, but only within each queue.

> Jeff's idea would take care of this, together with a *limited*
> (say, 32 entries) queue size. Every time the "work" queue (the
> one the disk is working on) is empty, we switch queues.

OK, I called the "work" queue my "current" queue in the suggestion
above, but other than that it may not be so different.

> Processes get to put their request on the other queue, either
> until the disk takes their requests (the queues are switched)
> or until the queue is full. That way only the N highest priority
> processes can get access to the disk if we're really overloaded
> in a bad way.

I'm not sure I understand this.

New requests should always be put in the first queue that has room (is
not too old). This means that no requests will be shifted too far off
it's original order. (in other words, it is not too unfair)

> > I don't think you should allow merges. If one process is doing a big 
> > IO operation on a big file it would still get _all_ capacity, right?
> 
> Only if you were to allow unlimited merges ;)
> 
> I guess a 'decent' maximum size for one request would
> be somewhere around 256kB, since this is the amount of
> data a drive can read in the time of one disk seek...

Yes, this sounds like a good idea. (Don't know about the size though,
but testing will show)


-- 
Ragnar Kjørstad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Proposal: Linux Kernel Patch Management System

[David S. Miller]

   Date: Wed, 13 Sep 2000 10:32:03 -0400
   From: "Theodore Y. Ts'o" <[EMAIL PROTECTED]>

   In the long run, it will make your life easier, to the extent that
   having an up-to-date bug list is easier, and because then I won't
   have to continually pester people about whether certain bugs have
   been fixed.

Ok, I claim:

1) I always have an uptodate bug list for the things I maintain

2) I always notify you instantly when Linus puts up a pre-patch
   that closes bugs in areas I maintain.

3) By going over every diff by hand I (and others) spot bugs that
   would not be found easily by testing.  It's free code review
   to keep going over relative diffs like this as new pre-patches come
   out.  (I'd say there about 10 to 20 people who, like me,
   religiously read over and review the diffs between pre-patches
   as they are released.  There is _real_ value in this.  It won't
   all stop due to the patch robot, but you for one aparently will do
   it less often than you do now.)

So changing the mechanism is going to make my life easier and better
how?

But still, Ted, I respect you enough that if you are so convinced this
is going to make things better, I'm going to give it a try as is.  No
problem.

However, I contend that some of us will feel that they are being
punished for doing a good job thus far without this patch robot.

I don't think the big problem is VFS, MM, or networking bug
tracking/fixing.  The big issue really is the drivers, and it's simply
because several of the maintainers of drivers are lackadasical about
doing their job and chasing people down when bug reports are submitted
against them.

If you agree with the previous paragraph, then my final argument is
that forcing these driver "maintainers" to go through the patch robot
system will not necessarily get them to look at the bug list and hunt
people down to fix bugs.

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

Re: New topic (PowerPC Linux PCI HELL)

[Matthew Jacob]

On Wed, 13 Sep 2000, David S. Miller wrote:

>Date:  Wed, 13 Sep 2000 18:00:02 -0700 (PDT)
>From: Matthew Jacob <[EMAIL PROTECTED]>
> 
>This seems to be an artifact of some OBP implementations for PPC-
>apples in particular.
> 
>It assigns both I/O and Mem addrs and IRQs, but doesn't enable
>either memory or I/O. So you have to do it for it.
> 
> Yeah, but this doesn't belong in the drivers that is for sure.
> 
> It belongs in arch/ppc/kernel/*pci*.c
> 
> This is precisely the kind of compat stuff which should be fixed up in
> the arch-specific PCI support code.

I couldn't agree more.

However- I can only write the bits for my driver and maybe *suggest* stuff to
the PPC maintainers (I'm relatively new to having a PPC to play with).

-matt


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

Re: PowerPC Linux for AS/400 & RS/6000 Hardware

[Dan Malek]

Paul Mackerras wrote:

> I don't think this is actually correct; I believe what Cort said is
> that he is no longer maintaining the http://www.ppc.linux.org/ web
> site.

That is the way I read it as well.  Of course, I have been reading
things differently than others, lately :-).

>   He is away at the moment though.

I met with Cort for a couple of hours on Tuesday.  I thought he was
going to be back in NM sometime today (Wednesday), and I was hoping he
would have responded to the messages of confusion by now.

We discussed how to better manage the kernel source trees, and it was
pretty clear to me he intended to keep working on this.  Like all of
us, he has other jobs to do, and sometimes he just can't respond as
quickly as we like.  This kind of work has a multiplier effect as it
moves upstream.



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

Re: New topic (PowerPC Linux PCI HELL)

[David S. Miller]

   Date:Wed, 13 Sep 2000 18:00:02 -0700 (PDT)
   From: Matthew Jacob <[EMAIL PROTECTED]>

   This seems to be an artifact of some OBP implementations for PPC-
   apples in particular.

   It assigns both I/O and Mem addrs and IRQs, but doesn't enable
   either memory or I/O. So you have to do it for it.

Yeah, but this doesn't belong in the drivers that is for sure.

It belongs in arch/ppc/kernel/*pci*.c

This is precisely the kind of compat stuff which should be fixed up in
the arch-specific PCI support code.

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

Console

[Kirti Desai]

My name is Kirti Desai. I am trying to write a new
console driver.
Hence I was going through the source code and  I need
your 
help in understanding it. I would be obliged if you
can help
me out. I am working on Redgar Linux 2.2-14.12 on
Celeron 400.

* Is console related to a tty_driver? We have two
functions
register_console and register_tty_driver? How are
these two
related? 
In tty_init(tty_io.c) we register dev_tty_driver  and
dev_syscons_driver?
In console_init(tty_io.c) con_init(tty_io.c for
CONFIG_VT=y) is 
called. It registers console_driver and calls
register_console(vt_console_driver).

* To do printk we need not open the /dev/console file?
What I found was
start_kernel(init/main.c) calls console_init and
kernel_thread(init..)
which calls init is called later which opens
/dev/console.

* How are stdin/stdout/stderr mapped to the tty's?
What  want to know
if that when we call say printf in user
program,finally write(1,..) gets called which calls
tty_write ,con_write. How does tty come in
picture?

* What are /dev/console /dev/tty0, /dev/tty1 files?

Any pointer to documentation ..would be  of great
help?

Thanks,
Kirti Desai

__
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: New topic (PowerPC Linux PCI HELL)

[Matthew Jacob]

This seems to be an artifact of some OBP implementations for PPC- apples in
particular.

It assigns both I/O and Mem addrs and IRQs, but doesn't enable either memory
or I/O. So you have to do it for it.

On Wed, 13 Sep 2000, Andre Hedrick wrote:

> 
> Okay who can teach me how to force hooks and ram this down the PPC
> 
> pci_write_config_word(dev, PCI_COMMAND, 0x05);
> 
> I have all the address registered.
> My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> alive.  Thus I get some of the most beuatiful lockups ever.
> I suspect that this needs to be handled down in the arch.
> 
> ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
> 
> Basically I can not get the IO's active, regardless of BIOS on the card.
> Yes this is the old trick that used to work of making ix86 cards run in
> non ix86-pci slots.
> 
> Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> under Mac OS, but the IO's are not enable in linux and it crash like a big
> dog also.
> 
> Cheers,
> 
> 
> Andre Hedrick
> The Linux ATA/IDE guy
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

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

Re: New topic (PowerPC Linux PCI HELL)

[Daniel Jacobowitz]

On Wed, Sep 13, 2000 at 05:29:58PM -0700, Andre Hedrick wrote:
> 
> Okay who can teach me how to force hooks and ram this down the PPC
> 
> pci_write_config_word(dev, PCI_COMMAND, 0x05);
> 
> I have all the address registered.
> My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> alive.  Thus I get some of the most beuatiful lockups ever.
> I suspect that this needs to be handled down in the arch.
> 
> ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
> 
> Basically I can not get the IO's active, regardless of BIOS on the card.
> Yes this is the old trick that used to work of making ix86 cards run in
> non ix86-pci slots.
> 
> Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> under Mac OS, but the IO's are not enable in linux and it crash like a big
> dog also.

I'm going to bet you need to look at Michel Lanners' (did I spell that
right this time?) PCI patches.  For instance, I've always needed this
hideous patch on my 7300/200 to get a Promise Ultra66 card to work:

diff -ur merging-bk/drivers/block/ide-pci.c work-bk/drivers/block/ide-pci.c
--- merging-bk/drivers/block/ide-pci.c  Tue Apr  4 22:19:16 2000
+++ work-bk/drivers/block/ide-pci.c Thu Mar  9 15:33:25 2000
@@ -468,6 +468,15 @@
printk("%s: error accessing PCI regs\n", d->name);
return;
}
+#ifdef __powerpc__
+   if (!(pcicmd & PCI_COMMAND_IO)) {   /* is device disabled? */
+   pci_write_config_word(dev, PCI_COMMAND, pcicmd | PCI_COMMAND_IO);
+   if (pci_read_config_word(dev, PCI_COMMAND, &pcicmd)) {
+   printk("%s: error accessing PCI regs\n", d->name);
+   return;
+   }
+   }
+#endif
if (!(pcicmd & PCI_COMMAND_IO)) {   /* is device disabled? */
/*
 * PnP BIOS was *supposed* to have set this device up for us,


Dan

/\  /\
|   Daniel Jacobowitz|__|SCS Class of 2002   |
|   Debian GNU/Linux Developer__Carnegie Mellon University   |
| [EMAIL PROTECTED] |  |   [EMAIL PROTECTED]  |
\/  \/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] Remove LD_RFLAG (was: Rewritten drivers/ide/Makefile)

[Bartlomiej Zolnierkiewicz]

On Thu, 14 Sep 2000, Keith Owens wrote:

> On Thu, 14 Sep 2000 01:11:57 +0200 (CEST), 
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> >- Removed $(LD_RFLAG), I can't find any definition of it in the
> >  kernel source tree and LD docs. WTF it is (was) used for?
>
> LD_RFLAG was obviously intended to be extra ld flags but only when
> doing "ld -r".  Nothing in the standard tarball sets LD_RFLAG so it
> would have to be manually set by a user.  Less than half of the
> occurrences of $(LD) -r include $(LD_RFLAG) so its use (if any) is very
> inconsistent.

I have found 37 occurrences of $(LD) -r in various Makefiles and only 10
included $(LD_RFLAG). So ratio is rather like 1/4 :-)

> Remove all occurrences of LD_RFLAG.  If anybody complains then we put
> it back in but do it consistently this time, on all occurrences of
> $(LD) -r.

Done. Attached patch removes LD_RFLAG from 2.4.0-test8.

--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>


diff -uNr linux-2.4.0-test8/arch/arm/nwfpe/Makefile linux/arch/arm/nwfpe/Makefile
--- linux-2.4.0-test8/arch/arm/nwfpe/Makefile   Sat Aug 26 00:09:04 2000
+++ linux/arch/arm/nwfpe/Makefile   Thu Sep 14 02:31:43 2000
@@ -29,4 +29,4 @@
 include $(TOPDIR)/Rules.make
 
 nwfpe.o: $(MI_OBJS) $(MIX_OBJS)
-$(LD) $(LD_RFLAG) -r -o $@ $(MI_OBJS) $(MIX_OBJS)
+   $(LD) -r -o $@ $(MI_OBJS) $(MIX_OBJS)
diff -uNr linux-2.4.0-test8/drivers/acorn/scsi/Makefile 
linux/drivers/acorn/scsi/Makefile
--- linux-2.4.0-test8/drivers/acorn/scsi/Makefile   Sat Aug 26 00:09:12 2000
+++ linux/drivers/acorn/scsi/Makefile   Thu Sep 14 02:31:57 2000
@@ -51,4 +51,4 @@
 include $(TOPDIR)/Rules.make
 
 acornscsi_mod.o: acornscsi.o acornscsi-io.o
-   $(LD) $(LD_RFLAG) -r -o $@ acornscsi.o acornscsi-io.o
+   $(LD) -r -o $@ acornscsi.o acornscsi-io.o
diff -uNr linux-2.4.0-test8/drivers/char/agp/Makefile linux/drivers/char/agp/Makefile
--- linux-2.4.0-test8/drivers/char/agp/Makefile Sat Jan  8 01:59:24 2000
+++ linux/drivers/char/agp/Makefile Thu Sep 14 02:32:05 2000
@@ -19,4 +19,4 @@
 include $(TOPDIR)/Rules.make
 
 agpgart.o: agpgart_be.o agpgart_fe.o
-   $(LD) $(LD_RFLAG) -r -o $@ agpgart_be.o agpgart_fe.o
+   $(LD) -r -o $@ agpgart_be.o agpgart_fe.o
diff -uNr linux-2.4.0-test8/drivers/fc4/Makefile linux/drivers/fc4/Makefile
--- linux-2.4.0-test8/drivers/fc4/Makefile  Sat Aug 26 00:08:11 2000
+++ linux/drivers/fc4/Makefile  Thu Sep 14 02:32:12 2000
@@ -41,4 +41,4 @@
 include $(TOPDIR)/Rules.make
 
 fc4.o: $(MIX_OBJS) fc.o
-   $(LD) $(LD_RFLAG) -r -o $@ $(MIX_OBJS) fc.o
+   $(LD) -r -o $@ $(MIX_OBJS) fc.o
diff -uNr linux-2.4.0-test8/drivers/ide/Makefile linux/drivers/ide/Makefile
--- linux-2.4.0-test8/drivers/ide/Makefile  Sat Aug 26 00:08:11 2000
+++ linux/drivers/ide/Makefile  Thu Sep 14 02:34:27 2000
@@ -231,7 +231,7 @@
 include $(TOPDIR)/Rules.make
 
 ide-mod.o: ide.o ide-features.o $(IDE_OBJS)
-   $(LD) $(LD_RFLAG) -r -o $@ ide.o ide-features.o $(IDE_OBJS)
+   $(LD) -r -o $@ ide.o ide-features.o $(IDE_OBJS)
 
 ide-probe-mod.o: ide-probe.o ide-geometry.o
-   $(LD) $(LD_RFLAG) -r -o $@ ide-probe.o ide-geometry.o
+   $(LD) -r -o $@ ide-probe.o ide-geometry.o
diff -uNr linux-2.4.0-test8/drivers/media/video/Makefile 
linux/drivers/media/video/Makefile
--- linux-2.4.0-test8/drivers/media/video/Makefile  Sat Aug 26 00:09:46 2000
+++ linux/drivers/media/video/Makefile  Thu Sep 14 02:32:26 2000
@@ -90,7 +90,7 @@
 fastdep:
 
 zoran.o: zr36120.o zr36120_i2c.o zr36120_mem.o
-   $(LD) $(LD_RFLAG) -r -o $@ zr36120.o zr36120_i2c.o zr36120_mem.o
+   $(LD) -r -o $@ zr36120.o zr36120_i2c.o zr36120_mem.o
 
 bttv.o: $(bttv-objs)
-   $(LD) $(LD_RFLAG) -r -o $@ $(bttv-objs)
+   $(LD) -r -o $@ $(bttv-objs)
diff -uNr linux-2.4.0-test8/drivers/parport/Makefile linux/drivers/parport/Makefile
--- linux-2.4.0-test8/drivers/parport/Makefile  Sun Oct  3 14:57:30 1999
+++ linux/drivers/parport/Makefile  Thu Sep 14 02:32:35 2000
@@ -98,4 +98,4 @@
 
 # Special rule to build the composite parport.o module
 parport.o: $(MI_OBJS) $(MIX_OBJS)
-   $(LD) $(LD_RFLAG) -r -o $@ $(MI_OBJS) $(MIX_OBJS)
+   $(LD) -r -o $@ $(MI_OBJS) $(MIX_OBJS)
diff -uNr linux-2.4.0-test8/drivers/pcmcia/Makefile linux/drivers/pcmcia/Makefile
--- linux-2.4.0-test8/drivers/pcmcia/Makefile   Sat Aug 26 00:08:25 2000
+++ linux/drivers/pcmcia/Makefile   Thu Sep 14 02:32:47 2000
@@ -51,7 +51,7 @@
 include $(TOPDIR)/Rules.make
 
 pcmcia_core.o:  $(CORE_OBJS)
-   $(LD) $(LD_RFLAG) -r -o $@ $(CORE_OBJS)
+   $(LD) -r -o $@ $(CORE_OBJS)
 
 yenta_socket.o: $(CARDBUS_OBJS)
-   $(LD) $(LD_RFLAG) -r -o $@ yenta.o pci_socket.o
+   $(LD) -r -o $@ yenta.o pci_socket.o
diff -uNr linux-2.4.0-test8/drivers/pnp/Makefile linux/drivers/pnp/Makefile
--- linux-2.4.0-test8/drivers/pnp/Makefile  Sun Mar 26 11:56:31 2000
+++ linux/drivers/pnp/Makefile  Thu Sep 14 02:32:58 200

[2.4.x] Pentium FPU memcpy

[Aaron Tiensivu]

The last version I've spotted was for mid-2.2 and was filled with gcc 2.7-isms
in the assembler code. I was curious if anyone has updated this to version 2.4
at all because it makes all the difference in the world for me with my P60. Now
that the memcpy stuff is somewhat modularized (with the Althon MMX copy stuff),
it might be easier to adapt. 

I've tried converting it but I don't know the differences enough between currentgcc 
and old 2.7.2 assembler syntax.

Thanks!

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

New topic (PowerPC Linux PCI HELL)

[Andre Hedrick]

Okay who can teach me how to force hooks and ram this down the PPC

pci_write_config_word(dev, PCI_COMMAND, 0x05);

I have all the address registered.
My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
alive.  Thus I get some of the most beuatiful lockups ever.
I suspect that this needs to be handled down in the arch.

./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}

Basically I can not get the IO's active, regardless of BIOS on the card.
Yes this is the old trick that used to work of making ix86 cards run in
non ix86-pci slots.

Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
under Mac OS, but the IO's are not enable in linux and it crash like a big
dog also.

Cheers,


Andre Hedrick
The Linux ATA/IDE guy

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Jeff Epler]

On Wed, Sep 13, 2000 at 11:56:56PM +0200, Trond Myklebust wrote:
> After consultation with the appropriate authorities, it turns out that
> the Sun-code based clients do in fact turn off data caching entirely
> when using NLM file locking.

Entirely?  That's interesting, because for our consistency requirements we
only need the data cache to be flushed for a particular inode at the time
of a locking call.  At least if we port to Solaris (hah!) we won't have
this particular problem in our clients.

> Attribute cache consistency checking on
> NFSv4 differs from v2/v3 in that you have a new attribute that is
> guaranteed to change every time the file changes.

That would be very welcome, but it's doubtful we could get an nfsv4 server
to run on our old bsdi 1.x-based servers :)  

Thank you very much for continuing to pursue this.  I wish I were an NFS
expert, but as I may have said elsewhere, this task falls to me as the
Linux evangelist at the office.  

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

Re: linux-2.0.39-pre-8 Compile error

[Alan Cox]

> patch:  malformed patch at line 9027: \ No newline at end of file
> I check patch-2.0.39-pre8 at 9027 line.

You need patch v2.5 or higher.

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

Re: kernel BUG at ll_rw_blk.c:711!

[Rik van Riel]

On Wed, 13 Sep 2000, David S. Miller wrote:

> Known bug, Linus just hasn't made a pre-patch in a long
> time with the fix.  Here is the fix:

I'd like to confirm that this patch is /needed/ to keep
my system running with 2.4.0-test8...

> --- vanilla/linux/fs/buffer.c Wed Sep  6 08:29:45 2000
> +++ linux/fs/buffer.c Sun Sep 10 17:25:26 2000
> @@ -1758,13 +1758,13 @@
>   pos += blocksize;
>   }
>  
> + err = 0;
> + if (!buffer_mapped(bh)) {
> + get_block(inode, iblock, bh, 0);
> + if (!buffer_mapped(bh))
> + goto unlock;
> + }
>   if (!buffer_uptodate(bh)) {
> - err = 0;
> - if (!buffer_mapped(bh)) {
> - get_block(inode, iblock, bh, 0);
> - if (!buffer_mapped(bh))
> - goto unlock;
> - }
>   err = -EIO;
>   bh->b_end_io = end_buffer_io_sync;
>   ll_rw_block(READ, 1, &bh);

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

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

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

Re: [PATCH][2.4.0t8] Rewritten drivers/ide/Makefile

[Keith Owens]

On Thu, 14 Sep 2000 01:11:57 +0200 (CEST), 
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>- Removed $(LD_RFLAG), I can't find any definition of it in the
>  kernel source tree and LD docs. WTF it is (was) used for?

LD_RFLAG was obviously intended to be extra ld flags but only when
doing "ld -r".  Nothing in the standard tarball sets LD_RFLAG so it
would have to be manually set by a user.  Less than half of the
occurrences of $(LD) -r include $(LD_RFLAG) so its use (if any) is very
inconsistent.

Remove all occurrences of LD_RFLAG.  If anybody complains then we put
it back in but do it consistently this time, on all occurrences of
$(LD) -r.

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

linux-2.0.39-pre-8 Compile error

[Seiichi Nakashima]

Dear.
 
I am Seiichi Nakashima in Japan.
 
I tested linux-2.0.39-pre-8, but compile error 
occured.
 
(1) Patch error ( maybe waring only )
 
I execute
 
# tar zxf linux-2.0.38.tar.gz
# mv linux linux-2.0.38
# patch -s -p0 < patch-2.0.39-pre8 
 
Then error occured
 
patch:  malformed patch at line 9027: \ No newline at end 
of file
I check patch-2.0.39-pre8 at 9027 line.
 
..
-#endif
\ No newline at end of file
+#endif
..
 
maybe, This line do not need.
 
 
(2) Kernel compile error and stop compile.
 
I execute
 
# mv linux-2.0.38 linux-2.0.39
# ln -s linux-2.0.39 linux
# cd linux
# make mrproper
# make menuconfig ( set kernel configureation )
# make dep; make clean; make zImage > /tmp/out 
2>&1
 
Then error occured, I append compile error messages( error 
step only ).
 
make[1]: Entering directory 
`/usr/src/linux-2.0.39/drivers'set -e; for i in block char net  pci; do 
make -C $i; donemake[2]: Entering directory 
`/usr/src/linux-2.0.39/drivers/block'make all_targetsmake[3]: Entering 
directory `/usr/src/linux-2.0.39/drivers/block'gcc -D__KERNEL__ 
-I/usr/src/linux-2.0.39/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strength-reduce -pipe -m486 -malign-loops=2 
-malign-jumps=2 -malign-functions=2 -DCPU=686  -c -o ll_rw_blk.o 
ll_rw_blk.cll_rw_blk.c: In function `make_request':ll_rw_blk.c:448: 
`IDE4_MAJOR' undeclared (first use this function)ll_rw_blk.c:448: (Each 
undeclared identifier is reported only oncell_rw_blk.c:448: for each 
function it appears in.)ll_rw_blk.c:449: `IDE5_MAJOR' undeclared (first use 
this function)make[3]: *** [ll_rw_blk.o] Error 1make[3]: Leaving 
directory `/usr/src/linux-2.0.39/drivers/block'make[2]: *** [first_rule] 
Error 2make[2]: Leaving directory 
`/usr/src/linux-2.0.39/drivers/block'make[1]: *** [sub_dirs] Error 
2make[1]: Leaving directory `/usr/src/linux-2.0.39/drivers'make: *** 
[linuxsubdirs] Error 2
 
Anyone help me.
 
 
 

2.2.17: set_rtc_mmss: can't update from 53 to 4

[Kamlesh Bans]

On my system, in ./arch/i386/kernel/time.c, set_rtc_mmss is outputting the 
messages

Sep 13 15:40:04 newton kernel: set_rtc_mmss: can't update from 57 to 10
Sep 13 15:41:05 newton kernel: set_rtc_mmss: can't update from 57 to 11
Sep 13 16:04:08 newton kernel: set_rtc_mmss: can't update from 53 to 4
Sep 13 16:05:09 newton kernel: set_rtc_mmss: can't update from 53 to 5

Any ideas on what the problem might be? I'm running kernel 2.2.17 with a 
Debian 2.2 distribution on an HP NetServer 5/133 LS2 with dual Pentium 
133's, 128 MB RAM, SCSI drives, no IDE, using an SMP kernel.

Thanks,
Kamlesh Bans
Corsair Communications
Irvine, CA, USA
+1-949-838-3107

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

Re: PowerPC Linux for AS/400 & RS/6000 Hardware

[Paul Mackerras]

Dwayne Grant McConnell ([EMAIL PROTECTED]) writes:

> Cort Dougan recently announced he was no longer going to be maintaining
> the PowerPC Linux tree.

I don't think this is actually correct; I believe what Cort said is
that he is no longer maintaining the http://www.ppc.linux.org/ web
site.  I don't think he meant that he was no longer maintaining Linux
for PowerPC.  He is away at the moment though.

> > LINUX FOR POWERPC AS/400 & RS/6000
> > P:  Dwayne Grant McConnell
> > M:  [EMAIL PROTECTED]
> > W:  http://oss.software.ibm.com/developerworks/opensource/linux/projects/ppc
> > L:  [EMAIL PROTECTED]
> > S:  Maintained
> >
> > LINUX FOR POWERPC AS/400 & RS/6000
> > P:  Tom Gall
> > M:  [EMAIL PROTECTED]
> > W:  http://oss.software.ibm.com/developerworks/opensource/linux/projects/ppc
> > L:  [EMAIL PROTECTED]
> > S:  Maintained

Suggestion: do it like this:

LINUX FOR POWERPC AS/400 & RS/6000
P:  Dwayne Grant McConnell
M:  [EMAIL PROTECTED]
P:  Tom Gall
M:  [EMAIL PROTECTED]
W:  http://oss.software.ibm.com/developerworks/opensource/linux/projects/ppc
L:  [EMAIL PROTECTED]
S:  Maintained

Regards,
Paul.

-- 
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
[EMAIL PROTECTED], http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PATCH: ide-scsi.c to allow claiming of Onstream drives

[Andre Hedrick]

> The second patch that Matt refers to inserts that logic into st so
> it does not try to support these drives and fails due to the drive
> particulars. Since SCSI, USB and IDE versions of these drives exist,
> patching st is more appropriate than ide-scsi.

Okay I am a mushroom, keep feeding me crap and I will stay in the dark. ;-)

If this is the case go for it!  I just hadn not heard anything from Jack
Bombeeck but regardless, if it is covered and it will detect the
differenct in headers and reject as neede, cool.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy


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

Re: PATCH: ide-scsi.c to allow claiming of Onstream drives

[Willem Riede]

Andre Hedrick wrote:
> 
> On Wed, 13 Sep 2000, Matthew Dharm wrote:
> 
> > Attached is a patch to ide-scsi.c against 2.4.0-test8.  Please consider
> > applying it.
> >
> > This patch removes the logic which causes ide-scsi to refuse to attach
> > itself to an IDE OnStream drive.  While these drives are not supported by
> > the standard st.c driver, there is userspace support (using the sg
> > interface) which works with the ATAPI drive with ide-scsi patched with this
> > patch.
> >
> > So there really is no reason for ide-scsi to reject this device.
> 
> Yes,
> 
> There is a reason that it was put there, DI-30's require special IO that
> st.o does not know how to do.
> 
> Look at all the hoops that it took to get ide-tape to work.
> If ide-scsi would have done the trick, it would have saved headaches.

Indeed. But in the mean time, a scsi driver for Onstream drives has
been written (by me). Together with Kai Makisara I have resolved how 
to get those drives detected by this new driver (osst) and not by st.

The second patch that Matt refers to inserts that logic into st so
it does not try to support these drives and fails due to the drive
particulars. Since SCSI, USB and IDE versions of these drives exist,
patching st is more appropriate than ide-scsi.

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

[PATCH][minor] Re: [patch] VIA IDE driver v2.3

[Bartlomiej Zolnierkiewicz]

On Tue, 12 Sep 2000, Vojtech Pavlik wrote:

> Anyone interested, please test this out, if it is as problemless as
> version 2.1, I'll send this to Linus for inclusion in the kernel.

Seems to be ok. Works ok. Please consider appling *crappy* patch
which corrects one entry in /proc/ide/via and beautifies code :-)

--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>


--- via82cxxx.c Wed Sep 13 19:21:29 2000
+++ via82cxxx.c Wed Sep 13 19:27:16 2000
@@ -226,9 +226,9 @@
via_print("Post Write Buffer: %10s%20s", (t & 0x40) ? "on" : "off", (t & 
0x10) ? "on" : "off" );
 
pci_read_config_byte(dev, VIA_FIFO_CONFIG, &t);
-   via_print("FIFO size: %10d%20d", 16 - (((t >> 5) & 1) + ((t >> 6) 
& 1)) * 8,
+   via_print("FIFO Size: %10d%20d", 16 - (((t >> 5) & 1) + ((t >> 6) 
+& 1)) * 8,
  (((t >> 5) & 1) + ((t >> 6) 
& 1)) * 8);
-   via_print("Threshold Prim.:   %10s%20s", via_fifo[(t >> 2) & 3], 
via_fifo[t & 3]);
+   via_print("FIFO Threshold:%10s%20s", via_fifo[(t >> 2) & 3], 
+via_fifo[t & 3]);
 
pci_read_config_word(dev, VIA_PRI_SECTOR_SIZE, &size0);
pci_read_config_word(dev, VIA_SEC_SECTOR_SIZE, &size1);
@@ -412,9 +412,9 @@
config_chipset_for_pio(drive);
return;
}
-   
+
if (pio > 5) pio = 5;
-   
+
via_set_speed(drive, XFER_PIO_0 + pio);
 }
 
@@ -437,7 +437,7 @@
(id->dma_1word & 0x0004) ? XFER_SW_DMA_2 :
(id->dma_1word & 0x0002) ? XFER_SW_DMA_1 :
(id->dma_1word & 0x0001) ? XFER_SW_DMA_0 : 0;
-   
+
if (!speed) return (int) ide_dma_off_quietly;
 
via_set_speed(drive, speed);
@@ -579,7 +579,7 @@
  * Register /proc/ide/via entry
  */
 
-#if defined(CONFIG_PROC_FS)
+#ifdef CONFIG_PROC_FS
if (!via_proc) {
via_proc = 1;
bmide_dev = dev;

Re: PATCH: ide-scsi.c to allow claiming of Onstream drives

[Matthew Dharm]

On Wed, Sep 13, 2000 at 03:53:13PM -0700, Andre Hedrick wrote:
> 
> On Wed, 13 Sep 2000, Matthew Dharm wrote:
> 
> > Attached is a patch to ide-scsi.c against 2.4.0-test8.  Please consider
> > applying it.
> > 
> > This patch removes the logic which causes ide-scsi to refuse to attach
> > itself to an IDE OnStream drive.  While these drives are not supported by
> > the standard st.c driver, there is userspace support (using the sg
> > interface) which works with the ATAPI drive with ide-scsi patched with this
> > patch.
> > 
> > So there really is no reason for ide-scsi to reject this device.
> 
> Yes,
> 
> There is a reason that it was put there, DI-30's require special IO that
> st.o does not know how to do.
> 
> Look at all the hoops that it took to get ide-tape to work.
> If ide-scsi would have done the trick, it would have saved headaches.
> 
> Unless OnStream has changed the firmware it will fail, but please try.

I am well aware of the fact that st.c is unable to suppor this drive.  It's
also unable to support the OnStream SC-30 and SC-50 units.  Realistically,
st should reject these drives -- work is being done on a patch to st do
accomplish this.

However, the userspace solution (which uses the scsi generic interface)
_will_ work with the ATAPI drive under ide-scsi emulation.  There is also
an (experimental) kernel driver (called osst) which will do the work of st
-- this driver works with the SC-30, SC-50, and DI-30 (ATAPI) units.  Of
course, the only way either the osst or sg driver will work with my ATAPI
drive is if ide-scsi will do the emulation.

I should point out that I've tested this configuration, and it works well.

Unfortunately, ide-tape and these other drivers (both sg and osst) use
different logical formats on the tape.  Tapes made on my ATAPI drive with
osst + ide-scsi are unreadble by ide-tape.  However, they are readable on
SCSI units (and should be readble with USB units as soon as I'm done with
that driver).

The point is, there is no reason for ide-scsi to refuse to do the
emulation.  I personally find that emulation useful to do backups with.
There _is_ a reason for st.c to reject these OnStream drives, but that
logic belongs in st.c, not in ide-scsi.c

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

You should try to see the techs say "three piece suit".
-- The Chief
User Friendly, 11/23/1997

 PGP signature

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Andrea Arcangeli]

On Wed, 13 Sep 2000, Giuliano Pochini wrote:

>I had a look at the new elevator. I hope I'm not wrong here... Requests
>are added to the queue scanning it starting from the tail. When the
>new request if found in-order with ad existing one, it's inserted int

Right so that it works in O(1) if you're doing sequential I/O.

>the queue, unless it finds an existing request out of latency units. In
>that case the new rq is added before it (so it will be serviced after).

Correct. The request out of latency units will become a barrier and
nothing will be allowed to pass it.

>After it have inserted the request it walks back and decrease all
>latency counters.

Yes, it have to tell to the other requests that they are being delayed.

>So, the "unit" to measure latency is "number of requests". New requests

Yes, in the sense of I/O request (not `struct request').

>are not allowed to go before an existing one more than N times.

Correct.

>It's a good way to avoid stalls, but IMHO I thing the elevator should

Here you're talking about the latency control logic.

>not work this way. The main problem is that it doesn't minimize head
>movement. For example, when comes a request for a sector at the

The algorithm that control the latency and the one that enforce the
ordering are two separate things.

For example in 2.2.15 there's only the latter (2.2.15 was missing a
latency control mechanism).

>beginning of the disk it goes to the beginning of the queue (it's
>ordered) so it will be serviced before other rqs (it picks up rqs from
>the head). This way the higher is the block number, more likely that
>rq will wait a lot.

We're not using a SCAN ordering algorithm it's instead a CSCAN. The queue
can be for istance:

12 13 14 1 2 3

Now insert 15 (assume 15 is the last sector of the disk):

12 13 14 15 1 2 3

as you can see the higher block number of the HD will wait less time than
1 2 3 (it will pass 1 2 and 3, of course assuming they are fresh requests
and they still have some latency unit to spend).

SCAN instead would have a fairness problem where the middle of the disk
gets less latency but SCAN as well goes backwards and it's not know how
well it works in all the hardware out there. (I think that's one of the
main reasons we use CSCAN instead)

Andrea

PS. Thanks for having read and understood the internals of the 2.4.x
elevator before posting your comments, it simplifies very much the
communication.

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

Re: Update Linux 2.4 Status/TODO list

[David Ford]

"Theodore Y. Ts'o" wrote:

>Date: Tue, 12 Sep 2000 23:55:55 -0700
>From: David Ford <[EMAIL PROTECTED]>
>
>Please add 'APM resume returns the machine to the first tty, crashes
>X' This appeared w/ test8.  If this is intended, I'd be very happy to
>know if so and I can write in to xfree86 about it.  If not
>intended..fix needed.
>
> Can you send more information?  Hardware, etc.  Do we know whether this
> is a hardware specific problem, or a more general problem?

(To several people)

Yes, I will.  Until later this evening I need my laptop for work.  This evening
I'll grab the serial cable and start making kernels and modules.

AFAIK, this is a kernel issue, going backwards to a kernel that doesn't switch
back to the first tty on resume, X remains in control of the screen and is quite
happy.  The first kernel that resumes and jumps back to the first tty, X crashes.
Doing a gdb on it yields a writev() that results in a segfault.  I'll do these two
problems individually.



>> 10. To Do But Non Showstopper
>>  * PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is
>>reliable)
>>   + PCMCIA crashes on unloading pci_socket
>
>With test8, pcmcia either with kernel code, mixed, or dhinds code;
>nothing is usable.
>
> Can you send more details?  I don't have a scratch laptop to try 2.4.0,
> and I'm too chicken to put it there.  (My laptop has to work; it's a
> production machine; failure is not an option.  Among other things, the
> master 2.4.0 bug list lives there.  :-)
>
>>  * cdrecord doesn't work (produces CD-ROM coasters) w/o any errors
>>reported, works under 2.2 (Damon LoCascio)
>
>Hmm, upgrade cdrecord perhaps?  I'm using the second to last release and I'm
>not burning coasters.  cdrecord is undergoing a scsi subsystem rewrite.
>
> According to Damon LoCascio, he's using the latest cdrecord.
>
> Kernel  : 2.4.0-test5
> SCSI: Advansys APB940U Quad scsi controller
> CDRW: Yamaha 8824CDRW
> CPU : AMD K6-III @450 MHz
> Mem : 256Mb
> MB  : FIC 503+
> CDrecord: 1.6, 1.81, 1.9, 1.10
>
> He says that it works just fine under 2.2.16, and he's seeing subtle
> data corruption problems under 2.4 (sometimes only 100 bytes between
> binary files).  It could be a hardware problem where the 2.4 kernel is
> stressing things more than the 2.2 kernel; or it could be a SCSI
> controller specific problem.  It's not clear.
>
>> Fixed
>>  * Keyboard/mouse problems (should be fixed?)
>
>Related to pcmcia, no, not fixed.  Certain mixes of drivers and hardware can
>stick the interrupt until they're removed and a different card inserted.
>
> Can you give more information on this one?  What specifically is going
> on?  There's no name associated with it, which means it was entered
> while Alan was maintaining the list, so I have no history associated
> with it.  (For that matter, it may be referring to different problem
> from the one you're seeing now.)
>
> Thanks for the update, and your comments.  (The rest of your comments
> will be on the linux24.sourceforge.net web page shortly.)
>
> - Ted

Certainly.  I amonst others reported the key/mouse issue many kernels back and it
was a guess game for a while then Linus said the yenta was a red herring.  I don't
have that email anymore but there's a lot of detail to the key/mouse/pcmcia story
and I'll dig it all up and write it out again.

Basically I believe the kernel pcmcia code is off by one in the socket numbering
as dhinds socket numbering works and w/ the kernel, one socket hangs the machine
and the other socket appears to be numbered as #0 where w/ dhinds it was #1.  It
seems to wedge something physically because my laptop will forever hang at maestro
init after trying to use the top socket w/ the kernel pcmcia.  I have to remove
all power then it will boot up past the maestro init.  Note, the machine isn't
hard hung at maestro, the magic key works.  It just won't proceed through the
boot.

More to come this evening.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Jeff Epler]

I think that both the NFS server changes that Trond is suggesting and the
NFS client changes that I am suggesting have their place.

The fact that the tuple (mtime, size) is used to test to test for
unchangedness of a file indicates that the people who designed NFS
understood that just using mtime wasn't enough.  The problem is that using
(mtime, size) is not enough either, and I don't understand why anyone ever
thought it would be.  Trivial example:
write(fd, "a", 1);
llseek(fd, 0, 0);
write(fd, "b", 1);

My solution will enable the Linux client (and other clients implementing
the same fix) to achieve the coherency promised by the comment in
nfs_lock(), at the expense of slightly lower performance, no matter what
NFS server they use (even a hypothetical one with mtime resolution of a
year).

Trond's nfs server changes would enable any client communicating with it to
achieve the coherency promised in nfs_lock(), without the performance
loss, but unfortunately the changes can't be made today and don't solve
anything for non-Linux NFS servers.

Thus, the only thing that is missing from my proposal is a way to fall back
on the old invalidation code, for that time in the future where mtime
changes are always sufficient to distinguish changes n a file.  I'm not
going to sweat this, since it sounds like this isn't implemented anywhere
else and won't be in Linux for some time.  When it comes along, we can
upgrade mount and the nfs client with a new flag.

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Albert D. Cahalan]

Trond Myklebust writes:
> > " " == Albert D Cahalan <[EMAIL PROTECTED]> writes:

>> 20 bits * 3 timestamps == 60 bits 60 bits <= 8 bytes
>>
>> So you do need 8 bytes.
>
> Yes. Assuming that you want to implement the microseconds field on
> all 3 timestamps. For NFS I would only need that precision on mtime.
> Does anybody else see a need for it on ctime and/or atime?

If you don't implement all 3, you get an ugly asymetry that
messes up timestamp comparisons.

You'd get ctime> I thought of this, but I don't think it is safe.
>>
>> write to file X us=1 write to file Y us=1 write to file Y us=2
>> write to file Y us=3 write to file X us=2
>>
>> Oops, "make" on some clients will think Y is newer than X.
>>
>> Using the wrong unit would be OK, as long as it is a real
>> sub-second time unit that doesn't overflow... but then you
>> might as well convert it to microseconds.
>
> Sure, but the alternative might be to reserve some bits as an
> 'operations counter' that is incremented every time an update is
> performed. That way you might have milisecond resolution
> (which is the sort of resolution that 'jiffies' & friends offers)
> + a few extra bits that would be there for make/NFS/... update
> consistency.

No way. You still get the same errors seen on clients that don't
know you are abusing the time stamps.

The ext2 inode has 6 obviously free bytes, 6 that are only used
on filesystems marked as Hurd-type, and 8 that seem to be claimed
by competing security and EA projects. So, being wasteful, it would
be possible to have picoseconds on all 4 time stamps. Doing mere
milliseconds on 3 timestamps would leave us 16 bytes for security.

This is what we have today:

struct ext2_inode {
__u16   i_mode; /* mode (type & permission bitss) */
__u16   i_uid;  /* owner's UID */
__u32   i_size; /* size (low 32 bits) */
__u32   i_atime;/* access time */
__u32   i_ctime;/* inode change time */
__u32   i_mtime;/* modification time */
__u32   i_dtime;/* deletion time */
__u16   i_gid;  /* group ID */
__u16   i_links_count;  /* link count */
__u32   i_blocks;   /* block count */
__u32   i_flags;/* ext2 flags */
union {
__u32   i_translator;   /* translator (Hurd only) */
__u32   i_res_fork; /* resource fork (Linux privs) */
} u1;
__u32   i_block[15];/* block pointers */
__u32   i_version;  /* inode generation (for NFS) */
__u32   i_file_acl; /* file ACL */
union {
__u32   i_dir_acl;  /* directory ACL */
__u32   i_size_high;/* high 32 bits of 64-bit size */
} u2;
__u32   i_reserved1;
__u16   i_reserved2;
__u16   i_mode_high;/* extra mode bits (Hurd only) */
__u16   i_uid_high; /* high 16 bits of 32-bit UID */
__u16   i_gid_high; /* high 16 bits of 32-bit GID */
__u32   i_author;   /* author (Hurd only) */
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Update Linux 2.4 Status/TODO list

[David Ford]

"Theodore Y. Ts'o" wrote:

>Date: Tue, 12 Sep 2000 23:37:57 -0700
>From: David Ford <[EMAIL PROTECTED]>
>
>> > 4. Boot Time Failures
>> >
>> >  * Use PCI DMA 'lost interrupt' problem with some hw [which ?] (NEC
>> >Versa LX with PIIX tuning)
>>
>> If this is a rare version of the BX/LX that has a no fix errata, then it
>> will be messy to issue resets to get out of the loop.
>>
>> >  * PIIXn tuning can hang laptop (2.4.0-test8-pre6, David Ford)
>>
>> Need more details of how APM/ACPI is dorking with DMA settins by the OEM.
>
>These two are both reported by me, are the same issue.  The exact
>same kernel, one with PIIXn tuning enabled, will hang the hardware on
>boot requiring a physical power loss to restart.
>
> Ah, OK, thanks.  I've collapsed the two bug reports.  (The first one was
> added by Alan, and his lists didn't give any indication as to two
> reported the problem, so I didn't realize they were the same problem.)
>
> - Ted

Just to clarify, I meant the two PIIX entries.  The ACPI/APM line got in there by
mistake.

-d


--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard

Re: [BUG] threaded processes get stuck in rt_sigsuspend/fillonedir/exit_notify

[David Ford]

Mark Kettenis wrote:

>From: Ulrich Drepper <[EMAIL PROTECTED]>
>Date: 2000-09-13 6:35:16
>
>[EMAIL PROTECTED] writes:
>
>> I didn't realize things had changed that broke the old threading model.
>> Did Linus do more than add support for the new thread groups?  I didn't
>> think any that had changed that would break the old LinuxThread
>> programs.
>
>First he introduces CLONE_THREAD (or how it was called).  This was
>fine.  But in pre2 ore pre3 he unified CLONE_SIGHAND and CLONE_THREAD
>under the new name CLONE_SIGNAL which makes perfect if CLONE_SIGHAND
>would be used.  But it is.  Simply undo this change, separate the two
>flags.
>
> This has been fixed in test8 (final).  CLONE_SIGHAND and CLONE_THREAD
> are seperate bits again, and CLONE_SIGNAL is both of them or'ed
> together.

Something else is broken then which only happens to threaded programs on test8
stuff.

$ pse|grep defun
   88 [nscd ] exit_notify
   89 [nscd ] exit_notify
   90 [nscd ] exit_notify
   91 [nscd ] exit_notify
 1097 [host ] exit_notify
 1098 [host ] exit_notify
 1110 [host ] exit_notify
  [host ] exit_notify
 1115 [nslookup ] exit_notify
 1175 [host ] exit_notify
 1177 [host ] exit_notify
 1182 [host ] exit_notify
 1184 [host ] exit_notify
 1190 [host ] exit_notify
 1192 [host ] exit_notify
 1197 [host ] exit_notify
 1199 [host ] exit_notify
 1168 [host ] exit_notify
14899 [xmms ] exit_notify
14902 [xmms ] exit_notify
14903 [xmms ] exit_notify
[...] goes on and on.  almost 100 processes stuck now.

here's one that is currently stuck:

 8243 pan  rt_sigsuspend
 8244 pan  rt_sigsuspend
 8249 pan  rt_sigsuspend

gdb pan 8243
[...]
(gdb) bt
#0  0x40498d05 in __sigsuspend (set=0xbf7ffab4)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1  0x4044f2f4 in __pthread_wait_for_restart_signal (self=0xbf7ffe40)
at pthread.c:785
#2  0x4044cfd2 in pthread_cond_timedwait_relative_new (cond=0x80eb4f8,
mutex=0x80eebd0, abstime=0xbf7ffd64) at restart.h:26
#3  0x4044d054 in pthread_cond_timedwait (cond=0x80eb4f8, mutex=0x80eebd0,
abstime=0xbf7ffd64) at condvar.c:381
#4  0x808ade6 in queue_mainloop ()
#5  0x4044d938 in pthread_start_thread (arg=0xbf7ffe40) at manager.c:241

a kill -9 is the only thing that will kick it, but that yields a zombie.

-d







--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Rik van Riel]

On Thu, 14 Sep 2000, Ragnar Kjørstad wrote:
> On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
> > > Another potentially stupid question:
> > > When the queue gets too long/old, new requests should be put in
> > > a new queue to avoid starvation for the ones in the current
> > > queue, right?
> > 
> > Indeed. That would solve the problem...
> 
> I think something like this: (I don't know the current code, so maybe
> this suggestion is really stupid.)
> 
> struct request_queue {
>   int4start_time;
>   struct request *list;
>   struct request_queue *next;
> }
> 
> struct request_queue *current_queue;
> 
> function too_old (struct request_queue *q) {
>   /* can actually easily be implemented using time, nr of requests
>  or any other messure of amount of work */
>   if (current_time > q->start_time + MAXTIME)
>   return 1;
>   else
>   return 0;
> }
> 
> function insert_request(struct request *new) {
>   struct request_queue *q=current_queue;
>   if (new->sectornr < current_sector);
>   q=q->next;
>   while (too_old(q))
>   q=q->next;
>   insert_request(q->list, new);
> }

This (IMHO) is wrong. When the drive has trouble keeping up
with requests in FCFS order, we should do some elevator sorting
to keep throughput high enough to deal with the requests we get.

Jeff's idea would take care of this, together with a *limited*
(say, 32 entries) queue size. Every time the "work" queue (the
one the disk is working on) is empty, we switch queues.

Processes get to put their request on the other queue, either
until the disk takes their requests (the queues are switched)
or until the queue is full. That way only the N highest priority
processes can get access to the disk if we're really overloaded
in a bad way.

The current HUGE queue size is probably another reason for
the very bad latencies we sometimes see...

> > (maybe with the twist that we /do/ allow merges on the queue
> > that's being processed by the disk, but no insertions of new
> > requests)
> 
> I don't think you should allow merges. If one process is doing a big 
> IO operation on a big file it would still get _all_ capacity, right?

Only if you were to allow unlimited merges ;)

I guess a 'decent' maximum size for one request would
be somewhere around 256kB, since this is the amount of
data a drive can read in the time of one disk seek...

regards,

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

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

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

Re: configuring from kernel source directory

[Tom Leete]

Michael Elizabeth Chastain wrote:
> 
> > and then I made the soft link to point to the new directory.
> 
> If you are talking about a soft link named "linux", just completely
> delete it and reset it to the value that it had when you installed
> your distribution and then never touch it again.
> 

That breaks on applying some patches or untarring official
source trees.

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

[PATCH][2.4.0t8] Rewritten drivers/ide/Makefile

[Bartlomiej Zolnierkiewicz]

Despite rewritting it to use lists I have changed two things:
- Moved $(IDE_OBJS) (now $(ide-obj-y)) from MIX_OBJS to MI_OBJS
  due the fact that they don't export any symbols (I hope).
- Removed $(LD_RFLAG), I can't find any definition of it in the
  kernel source tree and LD docs. WTF it is (was) used for?

Regards.
--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>


--- linux-2.4.0-test8/drivers/ide/Makefile  Sat Aug 26 00:08:11 2000
+++ linux/drivers/ide/Makefile  Tue Sep 12 22:25:33 2000
@@ -1,14 +1,8 @@
 #
 # Makefile for the kernel ata, atapi, and ide block device drivers.
 #
-# Note! Dependencies are done automagically by 'make dep', which also
-# removes any old dependencies. DON'T put your own dependencies here
-# unless it's something special (ie not a .c file).
-#
-# Note 2! The CFLAGS definition is now inherited from the
-# parent makefile.
-#
-
+# 12 September 2000, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
+# Rewritten to use lists instead of if-statements.
 #
 # Note : at this point, these files are compiled on all systems.
 # In the future, some of these should be built conditionally.
@@ -19,219 +13,83 @@
 ALL_SUB_DIRS := $(SUB_DIRS)
 
 O_TARGET := idedriver.o
-O_OBJS   := ide-geometry.o
-M_OBJS   :=
-OX_OBJS :=
-MX_OBJS :=
-
-ifeq ($(CONFIG_BLK_DEV_AEC62XX),y)
-IDE_OBJS += aec62xx.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_ALI14XX),y)
-IDE_OBJS += ali14xx.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_ALI15X3),y)
-IDE_OBJS += alim15x3.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_AMD7409),y)
-IDE_OBJS += amd7409.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_BUDDHA),y)
-IDE_OBJS += buddha.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_CMD640),y)
-IDE_OBJS += cmd640.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_CMD64X),y)
-IDE_OBJS += cmd64x.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_CS5530),y)
-IDE_OBJS += cs5530.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_CY82C693),y)
-IDE_OBJS += cy82c693.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_DTC2278),y)
-IDE_OBJS += dtc2278.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_FALCON_IDE),y)
-IDE_OBJS += falconide.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_GAYLE),y)
-IDE_OBJS += gayle.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_Q40IDE),y)
-IDE_OBJS += q40ide.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_HD),y)
-O_OBJS += hd.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_HPT34X),y)
-IDE_OBJS += hpt34x.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_HPT366),y)
-IDE_OBJS += hpt366.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_HT6560B),y)
-IDE_OBJS += ht6560b.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_IDE_ICSIDE),y)
-IDE_OBJS += icside.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_IDEDMA),y)
-IDE_OBJS += ide-dma.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_IDEPCI),y)
-IDE_OBJS += ide-pci.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_ISAPNP),y)
-IDE_OBJS += ide-pnp.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_IDE_PMAC),y)
-IDE_OBJS += ide-pmac.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_MAC_IDE),y)
-IDE_OBJS += macide.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_NS87415),y)
-IDE_OBJS += ns87415.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_OPTI621),y)
-IDE_OBJS += opti621.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_PDC202XX),y)
-IDE_OBJS += pdc202xx.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_PDC4030),y)
-IDE_OBJS += pdc4030.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_PIIX),y)
-IDE_OBJS += piix.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_QD6580),y)
-IDE_OBJS += qd6580.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_IDE_RAPIDE),y)
-IDE_OBJS += rapide.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_RZ1000),y)
-IDE_OBJS += rz1000.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_SIS5513),y)
-IDE_OBJS += sis5513.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_SL82C105),y)
-IDE_OBJS += sl82c105.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_TRM290),y)
-IDE_OBJS += trm290.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_UMC8672),y)
-IDE_OBJS += umc8672.o
-endif
-
-ifeq ($(CONFIG_BLK_DEV_VIA82CXXX),y)
-IDE_OBJS += via82cxxx.o
-endif
-
-### if CONFIG_BLK_DEV_IDE is n, IDE_OBJS will be ignored
-
-ifeq ($(CONFIG_PROC_FS),y)
-IDE_OBJS += ide-proc.o
-endif
-  
-###Collect
-
-ifeq ($(CONFIG_BLK_DEV_IDE),y)
-  OX_OBJS += ide.o ide-features.o
-  O_OBJS += ide-probe.o $(IDE_OBJS)
-else
-  ifeq ($(CONFIG_BLK_DEV_IDE),m)
-  MIX_OBJS += ide.o ide-features.o $(IDE_OBJS)
-  M_OBJS += ide-mod.o ide-probe-mod.o
-  endif
-endif
-
-
-
-ifeq ($(CONFIG_BLK_DEV_IDECS),y)
-O_OBJS += ide-cs.o
-else
-  ifeq ($(CONFIG_BLK_DEV_IDECS),m)
-  M_OBJS += ide-cs.o
-  endif
-endif
-
-ifeq ($(CONFIG_BLK_DEV_IDEDISK),y)
-O_OBJS += ide-disk.o
-else
-  ifeq ($(CONFIG_BLK_DEV_IDEDISK),m)
-  M_OBJS += ide-disk.o
-  endif
-endif
-
-ifeq ($(CONFIG_BLK_DEV_IDECD),y)
-O_OBJS += ide-cd.o
-else
-  ifeq ($(CONFIG_BLK_DEV_IDECD),m)
-  M_OBJS += ide-cd.o
-  endif
-endif
-
-ifeq ($(CONFIG_BLK_DEV_IDETAPE),y)
-O_OBJS += ide-tape.o
-else
-  ifeq ($(CONFIG_BLK_DEV_IDETAPE),m)
-  M_OBJS += ide-tape.o
-  endif
-endif
-
-ifeq ($(CONFIG_BLK_DEV_IDEFLOPPY),y)
-O_OBJS += ide-floppy.o
-else
-  ifeq ($(CONFIG_BLK_DEV_IDEF

Re: [patch]2.4.0-test6 "spinlock" preemption patch

[Ralf Baechle]

On Tue, Sep 12, 2000 at 11:37:46AM +0100, Alan Cox wrote:

> That code example can in theory deadlock without any patches if the CPU's
> end up locked in sync with each other and the same one always wins the test.
> It isnt likely on current x86 but other processors are a different story

If seen systems (not processors!) that can detect such a case let one
process randomly win over the others.

  Ralf

--
"Embrace, Enhance, Eliminate" - it worked for the pope, it'll work for Bill.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Ralf Baechle]

On Tue, Sep 12, 2000 at 12:21:16AM +0200, Jamie Lokier wrote:

> > Other than the initial repository create (aka cvs checkout), BK
> > *never* moves an entire file across the wire.  Never means never and
> > includes the process of deciding what to do.  CVS moves whole files
> > just to discover there is nothing to do.
> 
> Yes, CVS over rsync is much better for that.  IMHO the ideas underlying
> the rsync protocol are most cool.

Except that this still doesn't make CVS a distributed system, so it's only
good for checkouts ...

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

Kernel oops on 2.4.0-test4 and test5 (and later): kmem_cache_grow

[Jonathan Earle]

Title: Kernel oops on 2.4.0-test4 and test5 (and later): kmem_cache_grow





Hi,


I've been having kernel oopses with the 2.4.0-test series and am including ksymoops processed output from both test4 and test5 kernels.  The same oops happens in later kernels too (I've tested test6 and test7).

The scenario is this:


I have an incoming UDP stream at 1mbit.  The router marks packets in this stream, according to port ranges, with 3 marks (via iptables v1.1.1). iproute2 builds new routing tables based on these marks, and mplsadm, with the tc patch, is called to build mpls paths using these routing tables.  Finally, the 3 egress LSPs are rate limited using tc (cbq classes) to a value less than the ingress rate (ie: I limited each LSP to 200kbit, for an aggregate egress output rate of 6t00kbit).  When I start the traffic flowing from our generator, the box panics and freezes quite solidly.  If I move the egress rate limiting to another box, it works okay.

I copied down the oopses and ran 'ksymoops < oops.txt > oops_proc.txt' and pasted them here.  The first is from kernel 2.4.0-test4 and the second from 2.4.0-test5.

Cheers!
Jon



ksymoops 0.7c on i686 2.4.0-test4.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test4/ (default)
 -m /usr/src/linux/System.map (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.


invalid operand: 
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 001b ebx: c7ffd0c0 ecx:  edx: 0082
esi: 0246 edi: c7ffd0c0 ebp: 0007 esp: c024fe70
ds: 0018 es: 0018 ss: 0018
Process swapper (pid:0, stackpage=c024f000)
Stack: c01fb794 c01fb834 0412 c7ffd0c0 0247 0007 c024fed4 c7d1602e
   c0127aaf c7ffd0c0 0007  c7d170e0 c7d1602e c01eb196 0008
   0007  c7d170e0 c7d1602e c7f8be00  c01b6aaf c7d170e0
Call trace: [][][][][][][]
    [][][][][][][][]
    [][][][][][][][]
Code: 0f 0b 83 c4 0c c7 44 24 10 01 00 00 00 89 ee 83 e6 07 b8 03


>>EIP; c01277fd    <=
Trace; c01fb794 
Trace; c01fb834 
Trace; c0127aaf 
Trace; c01eb196 
Trace; c01b6aaf 
Trace; c01b6c6f 
Trace; c01b6a84 
Trace; c019b1c4 
Trace; c01b6936 
Trace; c01b6a84 
Trace; c019efe3 
Trace; c011b17f 
Trace; c010b8ee 
Trace; c01087e0 
Trace; c01087e0 
Trace; c010a518 
Trace; c01087e0 
Trace; c01087e0 
Trace; c0100018 
Trace; c0108803 
Trace; c0108864 
Trace; c0105000 
Trace; c0100192 
Code;  c01277fd 
 <_EIP>:
Code;  c01277fd    <=
   0:   0f 0b ud2a  <=
Code;  c01277ff 
   2:   83 c4 0c  add    $0xc,%esp
Code;  c0127802 
   5:   c7 44 24 10 01 00 00  movl   $0x1,0x10(%esp,1)
Code;  c0127809 
   c:   00 
Code;  c012780a 
   d:   89 ee mov    %ebp,%esi
Code;  c012780c 
   f:   83 e6 07  and    $0x7,%esi
Code;  c012780f 
  12:   b8 03 00 00 00    mov    $0x3,%eax


Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!


1 warning issued.  Results may not be reliable.



** Kernel 2.4.0-test5


ksymoops 0.7c on i686 2.4.0-test5.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test5/ (default)
 -m /usr/src/linux/System.map (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.


invalid operand: 
CPU: 0
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 001b ebx: c7ffd0c0 ecx: c02379cc edx: 
esi: 0007 edi: c7ffd0c0 ebp: c024dee8 esp: c024de80
ds: 0018 es: 0018 ss: 0018
Process swapper (pid:0, stackpage=c024d000)
Stack: c01fa0fa c01fa19a 0412 c7ffd0c0 0246 0007 c024dee8 c6702842
   c670282e c012736f c7ffd0c0 0007  c7e70140 c670282e c01e96a6
   0008 0008  c7e70140 c670282e c7f8be00  c01b4f67
Call trace: [][][][][][][]
    [][][][][][][][]
    [][][][][][][]
Code: 0f 0b 83 c4 0c c7 44 24 10 01 00 00 00 89 f5 83 e5 07 68 03


>>EIP; c01270ed    <=
Trace; c01fa0fa 
Trace; c01fa198 
Trace; c012736f 
Trace; c01e96a6 
Trace; c01b4f67 
Trace; c01b511f 
Trace; c0199a8c 
Trace; c01

Re: Proposal: Linux Kernel Patch Management System

[Alan Cox]

> that bitkeeper has.  The problem with bitkeeper is that it's **so**
> different from CVS that it takes time to learn --- I spent a day getting
> my head wrapped around it, and I still wouldn't call myself an expert;

Another problem is that bitkeeper has not been through a security audit.

> have no problem with the license.  But if there are enough other people
> who are license fanatics who do have a problem with it, then bitkeeper
> loses a lot of value for me.  If Linus were willing to dictate from high
> that we were going to use bitkeeper, and that all patches had to come in

If Linus requires bitkeeper only then there will be two kernel trees. Linux
ceases to be free software when you require nonfree software to contribute it.

Note: I think the BK license is fair, I understand Larry's problem and I support
his right to use whatever license he likes. I also happen to support my right
to decline to use his software

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

Getting past the 16-bit dev_t limitation.

[John Byrne]

Hello,

I am working on a project that is going to find the current limit of
16-bits for device numbers to be a pain. While looking around in the
linux-kernel archive, I found a series of e-mails about this from late
last year in which was discussed the introduction of the kdev_t type
and the possible future plans for it. I've also seen from the kdev_t.h
file that the type was introduced in 1995; so it doesn't appear that
there has been a big hurry to do anything. So:

1.) Can anyone tell me if there is a (Linus approved) solution in the
works for this for the 2.4.xx kernel series?

The "kdev_t as a pointer" concept looks interesting.

I am also curious whether there are plans to do away with the whole
concept of major/minor numbers; the user-mode dev_t would just be a
unique number for a specific device with no meaning beyond that. devfs
could be used to auto-assign them as drivers register devices, perhaps.

2.) Can anyone offer advice or a pointer to patches other people have
worked on?

Given that glibc presents the user with a larger dev_t already, it seems
possible to me that we should be able to modify the kernel to support a
32-bit kdev_t with perhaps only changing glibc in user-space. I know
there would be holes, but it might be good enough for our purposes for
now without representing a horrible maintenance problem.

Please cc any replies to me directly as read the list via the archive.

Thanks,

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

Re: PATCH: ide-scsi.c to allow claiming of Onstream drives

[Andre Hedrick]

On Wed, 13 Sep 2000, Matthew Dharm wrote:

> Attached is a patch to ide-scsi.c against 2.4.0-test8.  Please consider
> applying it.
> 
> This patch removes the logic which causes ide-scsi to refuse to attach
> itself to an IDE OnStream drive.  While these drives are not supported by
> the standard st.c driver, there is userspace support (using the sg
> interface) which works with the ATAPI drive with ide-scsi patched with this
> patch.
> 
> So there really is no reason for ide-scsi to reject this device.

Yes,

There is a reason that it was put there, DI-30's require special IO that
st.o does not know how to do.

Look at all the hoops that it took to get ide-tape to work.
If ide-scsi would have done the trick, it would have saved headaches.

Unless OnStream has changed the firmware it will fail, but please try.

> A future patch to make st.c reject OnStream drives it is unable to support
> if coming soon.
> 
> Matt
> 
> -- 
> Matthew Dharm  Home: [EMAIL PROTECTED] 
> Senior Engineer, QCP Inc.Work: [EMAIL PROTECTED]
> 
> G:  Let me guess, you started on the 'net with AOL, right?
> C:  WOW! d00d! U r leet!
>   -- Greg and Customer 
> User Friendly, 2/12/1999
> 

Andre Hedrick
The Linux ATA/IDE guy

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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Ragnar Kjørstad]

On Wed, Sep 13, 2000 at 06:57:21PM -0300, Rik van Riel wrote:
> > Another potentially stupid question:
> > When the queue gets too long/old, new requests should be put in
> > a new queue to avoid starvation for the ones in the current
> > queue, right?
> 
> Indeed. That would solve the problem...

I think something like this: (I don't know the current code, so maybe
this suggestion is really stupid.)

struct request_queue {
int4start_time;
struct request *list;
struct request_queue *next;
}

struct request_queue *current_queue;

function too_old (struct request_queue *q) {
/* can actually easily be implemented using time, nr of requests
   or any other messure of amount of work */
if (current_time > q->start_time + MAXTIME)
return 1;
else
return 0;
}

function insert_request(struct request *new) {
struct request_queue *q=current_queue;
if (new->sectornr < current_sector);
q=q->next;
while (too_old(q))
q=q->next;
insert_request(q->list, new);
}

> (maybe with the twist that we /do/ allow merges on the queue
> that's being processed by the disk, but no insertions of new
> requests)

I don't think you should allow merges. If one process is doing a big 
IO operation on a big file it would still get _all_ capacity, right?



-- 
Ragnar Kjørstad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PATCH: ide-scsi.c to allow claiming of Onstream drives

[Matthew Dharm]

Attached is a patch to ide-scsi.c against 2.4.0-test8.  Please consider
applying it.

This patch removes the logic which causes ide-scsi to refuse to attach
itself to an IDE OnStream drive.  While these drives are not supported by
the standard st.c driver, there is userspace support (using the sg
interface) which works with the ATAPI drive with ide-scsi patched with this
patch.

So there really is no reason for ide-scsi to reject this device.

A future patch to make st.c reject OnStream drives it is unable to support
if coming soon.

Matt

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Senior Engineer, QCP Inc.Work: [EMAIL PROTECTED]

G:  Let me guess, you started on the 'net with AOL, right?
C:  WOW! d00d! U r leet!
-- Greg and Customer 
User Friendly, 2/12/1999


--- drivers/scsi/ide-scsi.c.old Tue Sep 12 17:52:22 2000
+++ drivers/scsi/ide-scsi.c Tue Sep 12 17:52:35 2000
@@ -582,16 +582,6 @@
failed = 0;
while ((drive = ide_scan_devices (media[i], idescsi_driver.name, NULL, 
failed++)) != NULL) {
 
-#ifndef CONFIG_BLK_DEV_IDETAPE
-   /*
-* The Onstream DI-30 does not handle clean emulation, yet.
-*/
-   if (strstr(drive->id->model, "OnStream DI-30")) {
-   printk("ide-tape: ide-scsi emulation is not supported 
for %s.\n", drive->id->model);
-   continue;
-   }
-#endif /* CONFIG_BLK_DEV_IDETAPE */
-
if ((scsi = (idescsi_scsi_t *) kmalloc (sizeof 
(idescsi_scsi_t), GFP_KERNEL)) == NULL) {
printk (KERN_ERR "ide-scsi: %s: Can't allocate a scsi 
structure\n", drive->name);
continue;

 PGP signature

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Ragnar Kjørstad]

On Wed, Sep 13, 2000 at 08:08:51PM -0400, Giuliano Pochini wrote:
> > And if so, in what unit do you want to measure
> > latency if it isn't time?
> 
> I had a look at the new elevator. I hope I'm not wrong here... Requests
> are added to the queue scanning it starting from the tail. When the
> new request if found in-order with ad existing one, it's inserted int
> the queue, unless it finds an existing request out of latency units. In
> that case the new rq is added before it (so it will be serviced after).

If I understand this correctly, that means once the queue is too long
(latency wise) the elevator will stop working completely, because all
requests will be served in the order they come in. right?

If multiple queues are used, so performance is OK even when the first
queue is full (too old), the discussion about how to tell if the queue
is too old or not (by time or requests) becomes less important. After
all, there is no reason not to start a new queue pretty often, even on a
fast device.

The correct behavoir would be to reorderder the new requests
individually even if the queue is alreaddy too long. In other words -
multiple queues.

> not work this way. The main problem is that it doesn't minimize head
> movement. For example, when comes a request for a sector at the
> beginning of the disk it goes to the beginning of the queue (it's
> ordered) so it will be serviced before other rqs (it picks up rqs from
> the head). This way the higher is the block number, more likely that
> rq will wait a lot.

If a new request is made for a sector before the current sector (the
sector of the last request to be served), the new request should be
added to the second queue even if the first one is not too old.



-- 
Ragnar Kjørstad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 SCSI doesn't compile without modules

[Mr. James W. Laferriere]

 
Hello Torben ,  My manual edit of drivers/scsi/sr.c was the same
as your patch .  And yes I am now running the 2.4-test8 .  
Tnx ,  JimL

 root@test:~# uname -a
Linux test 2.4.0-test8 #2 Wed Sep 13 14:28:35 PDT 2000 i586 unknown

 root@test:~# sh /usr/src/linux/scripts/ver_linux
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux test 2.4.0-test8 #2 Wed Sep 13 14:28:35 PDT 2000 i586 unknown
Kernel modules 2.3.11
Gnu C  egcs-2.91.66
Binutils   2.9.1.0.25
Linux C Library2.1.3
Dynamic linker ldd: version 1.9.9
Procps 2.0.6
Mount  2.10l
Net-tools  1.55
Kbd0.99
Sh-utils   2.0
cat: /proc/modules: No such file or directory
Modules Loaded 

On Wed, 13 Sep 2000, Torben Mathiasen wrote:
> On Wed, Sep 13 2000, Mr. James W. Laferriere wrote:
> > Hello Torben ,
> > Has anyone caught this one yet .  I assume it is just the same
> > patch added (manually) to sr.c/h as well ?  Tia ,  JimL
> > drivers/scsi/scsidrv.o: In function `init_sr':
> > drivers/scsi/scsidrv.o(.text+0x1cfce): undefined reference to
> > `scsi_register_module'
> > drivers/scsi/scsidrv.o: In function `exit_sr':
> > drivers/scsi/scsidrv.o(.text+0x1cfe0): undefined reference to
> > `scsi_unregister_module'
> > make: *** [vmlinux] Error 1
> Probaly, I prefer to revert to good old init/cleanup_module. Forcing
> the new module_init with older non compatible drivers seems wrong.
> I'll look into what needs to be done to get it clean.
> The patch attached goes back to the old interface, please verify its
> success. I'll then send it to Linus for test9-p1.
   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

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

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

[Andre Hedrick]

On Wed, 13 Sep 2000, Chip Salzenberg wrote:

> According to Andre Hedrick:

> So I've noticed.  Do you not believe in its technical future, or are
> you just conserving what's left of your free time?

I would be attending an ice skating party below before I would see this
included, and I am short on time.  With the addition of a PPC toy the
debugging of a second arch is heavy.  And if others arrive it will get
worse.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

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

Re: The case for a standard kernel debugger

[Timur Tabi]

** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Thu, 14 Sep 2000
08:49:50 +1100


> (5) Easier for kernel beginners to learn the kernel internals.  Having
> worked on 10+ operating systems over the years, I can testify that
> some form of kernel/OS tracing facility is extremely useful to get
> people started.

Excellent post, but I can relate to this point the most.  Using the debugger to
aid in understanding the kernel is akin, IMHO, to knowing assembly language
when programming in a high-level language.  People who understand how the
computer works (which is only possible if you know asm) are better programmers
than those who don't.  Similarly, interacting with the kernel while its doing
its "magic" makes it easier to understand that magic.

I lost a lot of respect for Linus when he made comments that basically implied
that I was not worthy of learning the Linux kernel because I did not want to do
it the hard way.


-- 
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please don't cc: me, because then I'll just 
get two copies of the same message.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Rik van Riel]

On Wed, 13 Sep 2000, Ragnar Kjørstad wrote:
> On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
> > If I may ask a potentially stupid question, how can request latency be
> > anything but a factor of time?  Latency is how /long/ you (or the computer)
> > /waits/ for something.  That defines it as a function of time.
> 
> Latency is of course a factor of time, but the point is that the
> acceptable latency differs from device to device. For a slower device
> longer latency must be acceptable, and if the relationship is linear,
> then using number of requests may be a simpler and better way of doing
> it.
> 
> Another potentially stupid question:
> When the queue gets too long/old, new requests should be put in
> a new queue to avoid starvation for the ones in the current
> queue, right?

Indeed. That would solve the problem...

> So if this is done by time, how do you know when the oldest
> request get too old? You would need to index the requests both
> by sector and time, and thus performance overhead, right?

> If you, however have a simple rule that max 100 requests should
> be put in each queue, it's easy to know when to start a new one.

The idea Jeff Merkey gave us is even simpler and should work
ok every time. I think I'll implement it RSN and try if it
works ok for Linux.

(maybe with the twist that we /do/ allow merges on the queue
that's being processed by the disk, but no insertions of new
requests)

regards,

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

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

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

Re: Q: sock output serialization

[Henner Eisen]

Hi,

> "kuznet" == kuznet  <[EMAIL PROTECTED]> writes:

>> Anyway, it seems that I can already make use the lock_sock()
>> infrastructure for fixing the output serialization, even
>> without making the whole protocol stack SMP-aware at once.

kuznet> Actually, the last task is not a rocket science as well.

Yes. It seems the most critical part is changing timer events
to honor sk->lock.users and doing sock_hold/put(). There might be
timer events where the protocol specs require immediate reaction and
which need to change socket state. For such events, it might not
be obvious how to defer them when sk->lock.users != 0.

While deferring socket input is explictly supported (by processing
the sk->backlog queue in release_sock()), there is no special support for
deferring non-input events. Maybe in addition to processing the sk->backlog
queue, release_sock could also run a backlog task_queue? Such
task_queue could be used by other events to defer actions
when sk->lock.users!=0. Is there a particular reason why such task queue
does not exist?

Henner

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Andi Kleen <[EMAIL PROTECTED]> writes:

 > Steal a couple of bytes from what ?

>From the 32-bit storage area currently allocated to i_generation on
the on-disk ext2fs inode (as per Ted's suggestion). With current
disk/computing speeds, you probably don't need the full 32 bits to
offer a reasonable guarantee of inode number uniqueness.

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

Re: The case for a standard kernel debugger

[Jeff V. Merkey]

Amen Brother

Jeff

Keith Owens wrote:
> 
> Resend, this time with cc: torvalds.
> 
> This note puts the case for including a kernel debugger in the master
> tarballs.  These points do not only apply to kdb, they apply to any
> kernel debugger.  Comments about the perceived deficiencies of kdb,
> kgdb, xmon or any other debugger are not relevant here, nor are
> questions about how or when debuggers should be activated.  I want to
> concentrate of whether the kernel should have *any* standard debugger
> at all.
> 
> If Linus still says "no" to including any debugger in the master
> tarball then that will be the end of this thread as far as I am
> concerned.  I will then talk to distributors about getting a debugger
> included in their kernels as a patch.  Hopefully the distributors who
> want a kernel debugger can then agree on a standard one.
> 
> Disclaimer: Part of my paying job is to maintain kdb.  SGI want kdb to
> be used more widely to benefit from GPL support.  More eyes
> and hands means better code for everybody.
> 
> (1) Random kernel errors are easier to document and report with a
> debugger.  Oops alone is not always enough to find a problem,
> sometimes you need to look at parameters and control blocks.  This
> is particularly true for hardware problems.
> 
> (2) Support of Linux in commercial environments will benefit from a
> standard kernel debugger.  The last thing we want is each
> commercial support contract including a different debugger and
> supplying different bug reports.  Bug reports on supported systems
> should go to the support contractor but some will filter through to
> the main linux lists.
> 
> (3) Architecture consistency.  Sparc, mips, mips64, ppc, m68k, superh,
> s390 already have remote debugger support in the standard kernel.
> i386, alpha, sparc64, arm, ia64 do not have standard debuggers,
> they have to apply extra patches.  Some architectures have extra
> debugger code in addition to the remote gdb support.
> 
> (4) Debugger consistency.  Back in 1997 there were a lot of individual
> kernel debugging patches going around for memory leaks, stack
> overflow, lockups etc.  These patches conflicted with each other so
> they were difficult for people to use.  I built the original set of
> Integrated Kernel Debugging (IKD) patches because I contend that
> having a standard debugging patch instead of lots of separate ones
> is far easier for everybody to use.  The same is true of a kernel
> debugger, having one standard debugger that all kernels use will
> improve the productivity of everyone who has to support kernel
> code, no need to learn the semantics of multiple separate
> debuggers.
> 
> (5) Easier for kernel beginners to learn the kernel internals.  Having
> worked on 10+ operating systems over the years, I can testify that
> some form of kernel/OS tracing facility is extremely useful to get
> people started.  I agree with Linus when he said
> 
>"'Use the Source, Luke, use the Source.  Be one with the code.'.
>Think of Luke Skywalker discarding the automatic firing system
>when closing on the deathstar, and firing the proton torpedo (or
>whatever) manually.  _Then_ do you have the right mindset for
>fixing kernel bugs."
> 
> But Linus has also said "The main trick is having 5 years of
> experience with those pesky oops messages ;-)".  Beginners need
> some way of getting that experience.  Reading the source from a
> cold start is an horrendous learning curve, debuggers help to see
> what the source is really doing.  Always remember that 90%+ of
> kernel users are beginners, anything that helps to convert somebody
> from kernel beginner to kernel expert cannot be bad.
> 
> (6) I contend that kernel debuggers result in better patches, most of
> the time.  Sometimes people misuse a debugger, as Linus said
> 
>"I'm afraid that I've seen too many people fix bugs by looking
>at debugger output, and that almost inevitably leads to fixing
>the symptoms rather than the underlying problems."
> 
> Does that occur?  Of course it does, I have been guilty of that
> myself over the years.  Is it inevitable?  IMNSHO, no.  Seven of
> the twelve architectures in the standard kernel already have built
> in debuggers.  Where is the evidence that these architectures have
> more bad patches because of the presence of the debuggers?
> 
> Even if somebody does submit a patch to fix the symptom instead of
> the problem, that alone is valuable information.  Fixing the
> symptom focuses attention and the associated information helps to
> fix the real problem.  We get problem patches even without
> debuggers (let's not mention the recent truncate problems ;) but
> there are enough eyes on the kernel to find problem patches and
>

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Jeff Epler <[EMAIL PROTECTED]> writes:

 > But "ctime and file size are the same" does not prove that the
 > file is unchanged.  That's the root of this problem, and why
 > NFS_CACHEINV(inode) is not enough to ensure coherency.

 > Furthermore, according to NFSv4, what I am suggesting is
 > something that a client "may choose" to do anyhow---i.e., it's
 > at least permitted by the spec, even if it's not required.

It appears I owe you an apology, and I'd better make it in public.

After consultation with the appropriate authorities, it turns out that
the Sun-code based clients do in fact turn off data caching entirely
when using NLM file locking. Attribute cache consistency checking on
NFSv4 differs from v2/v3 in that you have a new attribute that is
guaranteed to change every time the file changes.

I'm still not happy with that solution, as it means that performance
is sub-optimal for a number of interesting cases, and it screws up
mmap() royally. However it does shoot to pieces my argument that we
currently do conform to standard behaviour.

Cheers and sorry,
  Trond

BTW: the microsecond mtime resolution on the NFS server remains an
issue, but now only for the ordinary case of attribute cache
consistency checking.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0 SCSI doesn't compile without modules

[Torben Mathiasen]

On Wed, Sep 13 2000, Mr. James W. Laferriere wrote:
> 
>   Hello Torben ,
>   Has anyone caught this one yet .  I assume it is just the same
>   patch added (manually) to sr.c/h as well ?  Tia ,  JimL
> 
> drivers/scsi/scsidrv.o: In function `init_sr':
> drivers/scsi/scsidrv.o(.text+0x1cfce): undefined reference to
> `scsi_register_module'
> drivers/scsi/scsidrv.o: In function `exit_sr':
> drivers/scsi/scsidrv.o(.text+0x1cfe0): undefined reference to
> `scsi_unregister_module'
> make: *** [vmlinux] Error 1
> 
>

Probaly, I prefer to revert to good old init/cleanup_module. Forcing
the new module_init with older non compatible drivers seems wrong.
I'll look into what needs to be done to get it clean.

The patch attached goes back to the old interface, please verify its
success. I'll then send it to Linus for test9-p1.

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk


diff -ur linux-2.4.0-test8/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- linux-2.4.0-test8/drivers/scsi/sr.c Wed Sep 13 23:24:42 2000
+++ linux/drivers/scsi/sr.c Wed Sep 13 23:54:26 2000
@@ -849,13 +849,15 @@
return;
 }
 
-int init_sr(void)
+#ifdef MODULE
+
+int init_module(void)
 {
sr_template.module = THIS_MODULE;
return scsi_register_module(MODULE_SCSI_DEV, &sr_template);
 }
 
-void exit_sr(void)
+void cleanup_module(void)
 {
scsi_unregister_module(MODULE_SCSI_DEV, &sr_template);
devfs_unregister_blkdev(MAJOR_NR, "sr");
@@ -879,5 +881,4 @@
sr_template.dev_max = 0;
 }
 
-module_init(init_sr);
-module_exit(exit_sr);
+#endif /* MODULE */

The case for a standard kernel debugger

[Keith Owens]

Resend, this time with cc: torvalds.

This note puts the case for including a kernel debugger in the master
tarballs.  These points do not only apply to kdb, they apply to any
kernel debugger.  Comments about the perceived deficiencies of kdb,
kgdb, xmon or any other debugger are not relevant here, nor are
questions about how or when debuggers should be activated.  I want to
concentrate of whether the kernel should have *any* standard debugger
at all.

If Linus still says "no" to including any debugger in the master
tarball then that will be the end of this thread as far as I am
concerned.  I will then talk to distributors about getting a debugger
included in their kernels as a patch.  Hopefully the distributors who
want a kernel debugger can then agree on a standard one.

Disclaimer: Part of my paying job is to maintain kdb.  SGI want kdb to
be used more widely to benefit from GPL support.  More eyes
and hands means better code for everybody.

(1) Random kernel errors are easier to document and report with a
debugger.  Oops alone is not always enough to find a problem,
sometimes you need to look at parameters and control blocks.  This
is particularly true for hardware problems.

(2) Support of Linux in commercial environments will benefit from a
standard kernel debugger.  The last thing we want is each
commercial support contract including a different debugger and
supplying different bug reports.  Bug reports on supported systems
should go to the support contractor but some will filter through to
the main linux lists.

(3) Architecture consistency.  Sparc, mips, mips64, ppc, m68k, superh,
s390 already have remote debugger support in the standard kernel.
i386, alpha, sparc64, arm, ia64 do not have standard debuggers,
they have to apply extra patches.  Some architectures have extra
debugger code in addition to the remote gdb support.

(4) Debugger consistency.  Back in 1997 there were a lot of individual
kernel debugging patches going around for memory leaks, stack
overflow, lockups etc.  These patches conflicted with each other so
they were difficult for people to use.  I built the original set of
Integrated Kernel Debugging (IKD) patches because I contend that
having a standard debugging patch instead of lots of separate ones
is far easier for everybody to use.  The same is true of a kernel
debugger, having one standard debugger that all kernels use will
improve the productivity of everyone who has to support kernel
code, no need to learn the semantics of multiple separate
debuggers.

(5) Easier for kernel beginners to learn the kernel internals.  Having
worked on 10+ operating systems over the years, I can testify that
some form of kernel/OS tracing facility is extremely useful to get
people started.  I agree with Linus when he said

   "'Use the Source, Luke, use the Source.  Be one with the code.'.
   Think of Luke Skywalker discarding the automatic firing system
   when closing on the deathstar, and firing the proton torpedo (or
   whatever) manually.  _Then_ do you have the right mindset for
   fixing kernel bugs."

But Linus has also said "The main trick is having 5 years of
experience with those pesky oops messages ;-)".  Beginners need
some way of getting that experience.  Reading the source from a
cold start is an horrendous learning curve, debuggers help to see
what the source is really doing.  Always remember that 90%+ of
kernel users are beginners, anything that helps to convert somebody
from kernel beginner to kernel expert cannot be bad.

(6) I contend that kernel debuggers result in better patches, most of
the time.  Sometimes people misuse a debugger, as Linus said

   "I'm afraid that I've seen too many people fix bugs by looking
   at debugger output, and that almost inevitably leads to fixing
   the symptoms rather than the underlying problems."

Does that occur?  Of course it does, I have been guilty of that
myself over the years.  Is it inevitable?  IMNSHO, no.  Seven of
the twelve architectures in the standard kernel already have built
in debuggers.  Where is the evidence that these architectures have
more bad patches because of the presence of the debuggers?

Even if somebody does submit a patch to fix the symptom instead of
the problem, that alone is valuable information.  Fixing the
symptom focuses attention and the associated information helps to
fix the real problem.  We get problem patches even without
debuggers (let's not mention the recent truncate problems ;) but
there are enough eyes on the kernel to find problem patches and
remove them.  Adding a standard debugger will improve the quality
of some of those eyes at a faster rate.

So how about it Linus?  Does any of this change your mind about
including a standard kernel debugger?

Asbest

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

[Chip Salzenberg]

According to Andre Hedrick:
> On Wed, 13 Sep 2000, Chip Salzenberg wrote:
> > that reducing it isn't worthwhile.  The more de facto standard patches
> > (*cough* NFS RAID[1] HedrickIDE *ahem*) can get into the 2.2 tree [...]
> 
> Thanks Chip but the backporting to 2.2 has been terminated.

So I've noticed.  Do you not believe in its technical future, or are
you just conserving what's left of your free time?
-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early."  // MST3K
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Ragnar Kjørstad]

On Wed, Sep 13, 2000 at 11:22:16AM -0400, Michael T. Babcock wrote:
> If I may ask a potentially stupid question, how can request latency be
> anything but a factor of time?  Latency is how /long/ you (or the computer)
> /waits/ for something.  That defines it as a function of time.

Latency is of course a factor of time, but the point is that the
acceptable latency differs from device to device. For a slower device
longer latency must be acceptable, and if the relationship is linear,
then using number of requests may be a simpler and better way of doing
it.


Another potentially stupid question:
When the queue gets too long/old, new requests should be put in a new
queue to avoid starvation for the ones in the current queue, right?
So if this is done by time, how do you know when the oldest request get
too old? You would need to index the requests both by sector and time,
and thus performance overhead, right?
If you, however have a simple rule that max 100 requests should be put
in each queue, it's easy to know when to start a new one. The number 100
should be found by calculating how many requests can be served within
the acceptable latency.


-- 
Ragnar Kjørstad
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Theodore Y Ts'o <[EMAIL PROTECTED]> writes:

 > Why?  i_generation is a field which is only used by the NFS
 > server.  As far as ext2 is concerned, it's a black box value.
 > Currently, as I understand things (and you're much more the
 > export on the NFS code than I am) all 32 bits of i_generation
 > is used to enforce uniqueness of the NFS file handler across
 > the recycling of the inode (i.e., the inode is deleted, and
 > then reused for something else).  Is that right?

Yes. In effect you have a 32-bit counter that serves as a guarantees
that an inode is not reused 'within a reasonable period of time'.

 > If we were to steal, say, 8 bits of i_generation to provide a
 > subsecond indicator of freshness of the attributes by shoving
 > those 8 bits into the NFS microseconds field, this shouldn't
 > cause any incompatibilities, should it?  (Of couse, you would
 > mask out those 8 bits for the NFS file handle generation
 > algorithm, which you would only have 24 bits, which still
 > should be enough for its purposes.)

 > My understanding of the games played by the i_generation field
 > and the NFS file handle is that it's not visiable to NFS
 > clients.  True, it would mean a certain amount of confusion for
 > those clients that kept the filesystem mounted across a
 > transition between an old 2.2.16 kernel and a reboot to a new
 > kernel that interpreted the i_generation field differently, but
 > that should be the only compatibility problem I can think of.

 > Am I missing something?

We'd want to make an implementation that is generic and fits all
'commonly used' UNIX filesystems. That means that we don't want to
apply an ext2-specific hack at the VFS or nfsd levels.  The
inode-generation field is a feature on several filesystems which
already support sub-second timestamps.

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

Re: Question about Bind Souce Code

[Erik Mouw]

On Wed, 13 Sep 2000 09:33:02 +0800, Pan Renzi wrote:
> This is a multi-part message in MIME format.
> 
> --=_NextPart_000_00D6_01C01D65.9CA16860
> Content-Type: text/plain;
> charset="gb2312"
> Content-Transfer-Encoding: base64
> 
> SGksYWxsOg0KICAgIEkgd2FzIGNvbmZ1c2VkIHdoZW4gSSByZWFkIEJpbmQgU291cmNlIENvZGUo
> OS4wLjByYzUpLg0KICAgIEl0IHdhcyBpbiBsaWIvaXNjL2luY2x1ZGUvaXNjL3R5cGVzLmgsbGlu
> ZSA2MixzYWlkIGxpa2UgYmVsb3c6DQogICAgInR5cGVkZWYgc3RydWN0IGlzY19tZW0gaXNjX21l
> bV90OyINCiAgICAgYnV0IEkgY2FudCBmaW5kIGFueSBpbmZvcm1hdGlvbiBhYm91dCAic3RydWN0
> IGlzY19tZW0iIGFueXdoZXJlLFdoYXQncyB3cm9uZz9JcyB0aGVyZSBhbnlvbmUgY291bGQgZ2l2
> ZSBtZSBzb21lIGlkZWE/DQogICAgQmVzdCBSZWdhcmQuDQogICAgDQogICAgDQogICAgDQo=

I have no idea what you're trying to say, although my mailers normally
have no problem decoding MIME encoded messages. Try sending mail in plain
ASCII text instead of some unknown character set, or use a better mailer.

Anyway: this is the linux-kernel mailing list. Questions about Bind should
be asked on other mailing lists. The Internet Software Consortium has more
information about Bind:

  http://www.isc.org/products/BIND/


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

[Richard B. Johnson]

On 13 Sep 2000, Ralf Gerbig wrote:

> * Chip Salzenberg writes:
> 
> Hi Chip,
> 
> > According to Ralf Gerbig:
> >> but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels.
> 
> > You've just made L-K's understatement of the day.
> 
> [...]
> 
> so I rest my case vs shrink wrap.
> 

Yep. I installed Suse-6.4 on my laptop. Since I needed APM to work, I
recompiled the kernel source that they supplied. First, I just did
`make oldconfig` so I could duplicate the existing kernel. Well.
No such luck. There was no way in hell I could duplicate the kernel
that they supplied, with the sources that they supplied. And there
was no secret 'patch' directory either...

And I thought this was the whole idea of (GPL) [Snipped...] :

  3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,


But what do I know, I haven't bought any lawyers lately ;~)


Cheers,
Dick Johnson

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

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


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

Re: 2.4.0 SCSI doesn't compile without modules

[Mr. James W. Laferriere]

Hello Torben ,
Has anyone caught this one yet .  I assume it is just the same
patch added (manually) to sr.c/h as well ?  Tia ,  JimL

drivers/scsi/scsidrv.o: In function `init_sr':
drivers/scsi/scsidrv.o(.text+0x1cfce): undefined reference to
`scsi_register_module'
drivers/scsi/scsidrv.o: In function `exit_sr':
drivers/scsi/scsidrv.o(.text+0x1cfe0): undefined reference to
`scsi_unregister_module'
make: *** [vmlinux] Error 1


On Wed, 13 Sep 2000, Torben Mathiasen wrote:
> On Wed, Sep 13 2000, Anton Altaparmakov wrote:
> > Just discovered that if you try to compile 2.4.0-test8 without module 
> > support then the compilation (or linking to be more exact) fails at:
> > 
> > drivers/scsi/scsidrv.o: In function 'init_sd':
> > drivers/scsi/scsidrv.o(.text+0x1efa): undefined reference to 
> > 'scsi_register_module'
> > drivers/scsi/scsidrv.o: In function 'exit_sd':
> > drivers/scsi/scsidrv.o(.text+0x1f12): undefined reference to 
> > 'scsi_unregister_module'
> > 
> > I have attached the .config file with which this happens...
> >
> 
> Check the list, patch already posted.
> 
> -- 
> Torben Mathiasen <[EMAIL PROTECTED]>
> Linux ThunderLAN maintainer 
> http://tlan.kernel.dk
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

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

Re: Bug in block device read/write!

[Anton Altaparmakov]

It isn't when you are not using persistent super blocks, and if it were 
doing so that would definitely be a bug IMO.

And anyway, it occurs without using the md driver as well (on a normal 
partition as I described in my original post...).

Andries Brouwer's reply/post offered the AFAICS correct explanation that 
the last sector (512b sector size) on partitions with an odd number of 
sectors cannot be accessed at present due to the 1kb block size of the kernel.

Regards,

Anton


At 05:01 13/09/2000, [EMAIL PROTECTED] wrote:
>Date:Fri, 08 Sep 2000 03:41:27 +0100
>From: Anton Altaparmakov <[EMAIL PROTECTED]>
>
>I have been trying to get the linear md driver to work with NTFS volumes
>for several months and it never worked. - I was suspecting the NTFS 
> driver
>(after having fixed linear md and verified that at least that worked 
> fine)
>but today I finally found why it doesn't work:
>
>There is a bug in reading/writing to block devices. - It manifests itself
>in the form that partitions are too small by exactly one sector!
>
>Even though a cfdisk shows that a partition has a certain number of
>sectors, you can never seek + read and/or write to the last sector (doing
>file i/o using read/write(2) [also tried fread/fwrite(3), same result]. -
>Last sector doesn't seem to exist. However reading the actual hd 
> (/dev/hdb
>or /dev/sda, ie. affects both IDE and SCSI) instead of the partition
>(/dev/hdb7 or whatever) the sector does exist and contains the expected
>information!
>
>This isn't a bug.  The last sector is used by the md device to store the
>md superblock.
>
> - Ted
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>Please read the FAQ at http://www.tux.org/lkml/
>-
>To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>the body of a message to [EMAIL PROTECTED]

-- 

  "Education is what remains after one has forgotten everything he 
learned in school." - Albert Einstein

-- 
Anton Altaparmakov  Voice: 01223-333541(lab) / 07712-632205(mobile)
Christ's CollegeeMail: [EMAIL PROTECTED]
Cambridge CB2 3BUICQ: 8561279
United Kingdom   WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

Re: 2.4.0 SCSI doesn't compile without modules

[Torben Mathiasen]

On Wed, Sep 13 2000, Anton Altaparmakov wrote:
> Just discovered that if you try to compile 2.4.0-test8 without module 
> support then the compilation (or linking to be more exact) fails at:
> 
> drivers/scsi/scsidrv.o: In function 'init_sd':
> drivers/scsi/scsidrv.o(.text+0x1efa): undefined reference to 
> 'scsi_register_module'
> drivers/scsi/scsidrv.o: In function 'exit_sd':
> drivers/scsi/scsidrv.o(.text+0x1f12): undefined reference to 
> 'scsi_unregister_module'
> 
> I have attached the .config file with which this happens...
>

Check the list, patch already posted.

-- 
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer 
http://tlan.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Andi Kleen]

On Wed, Sep 13, 2000 at 10:35:10PM +0200, Trond Myklebust wrote:
>  > No, it does not help. i_generation is only in the NFS file
>  > handle, but not in the fattr/file id this is used for cache
>  > checks. The NFS file handle has to stay identical anyways, as
>  > long as the inode is not deleted/reused.
> 
> 
> You might be able to steal a couple of bytes and then rewrite ext2fs
> to mask those out from the 'i_generation' field, but it would mean that
> you could no longer boot your old 2.2.16 kernel without trouble on
> existing clients.

Steal a couple of bytes from what ? 

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

RE: [ANNOUNCE] Darkstar Development Project

[Stephen Frazier]

Does *BSD run on S390?

Stephen Frazier
Oklahoma Department of Corrections

-Original Message-
On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:

I just thought I would remind all the nay-sayers that the *BSD world has
been doing something along this line since at least 1990. While some of
the programs have changed, the functionality has remained largely the
same.



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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Frank van Maarseveen]

On Wed, Sep 13, 2000 at 12:42:15PM +0200, Trond Myklebust wrote:
> 
> Is there any 'standard' function for reading the microseconds fields
> in userland? I couldn't find anything with a brief search in the
> X/Open docs.
> 
Both Digital OSF/1 and Solaris use 3 undocumented spare fields in the
struct stat and filled it with a microsecond/nanosecond fraction for
atime, mtime and ctime.

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Theodore Y. Ts'o]

   Date: Wed, 13 Sep 2000 22:35:10 +0200 (CEST)
   From: Trond Myklebust <[EMAIL PROTECTED]>

   You might be able to steal a couple of bytes and then rewrite ext2fs
   to mask those out from the 'i_generation' field, but it would mean that
   you could no longer boot your old 2.2.16 kernel without trouble on
   existing clients.

Why?  i_generation is a field which is only used by the NFS server.  As
far as ext2 is concerned, it's a black box value.  Currently, as I
understand things (and you're much more the export on the NFS code than
I am) all 32 bits of i_generation is used to enforce uniqueness of the
NFS file handler across the recycling of the inode (i.e., the inode is
deleted, and then reused for something else).  Is that right?

If we were to steal, say, 8 bits of i_generation to provide a subsecond
indicator of freshness of the attributes by shoving those 8 bits into
the NFS microseconds field, this shouldn't cause any incompatibilities,
should it?  (Of couse, you would mask out those 8 bits for the NFS file
handle generation algorithm, which you would only have 24 bits, which
still should be enough for its purposes.)

My understanding of the games played by the i_generation field and the
NFS file handle is that it's not visiable to NFS clients.  True, it
would mean a certain amount of confusion for those clients that kept the
filesystem mounted across a transition between an old 2.2.16 kernel and
a reboot to a new kernel that interpreted the i_generation field
differently, but that should be the only compatibility problem I can
think of.

Am I missing something?

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

Re: Distro kernel patches (was Re: Linux 2.2.18pre4)

[Ralf Gerbig]

* Chip Salzenberg writes:

Hi Chip,

> According to Ralf Gerbig:
>> but SuSe and I believe RedHat etc. etc. _do_ ship patched kernels.

> You've just made L-K's understatement of the day.

[...]

so I rest my case vs shrink wrap.

OTOH one of the first things I do after trying a new distribution is
to replace the kernel by the latest and greatest, at least for the box
at home and mine at work.

I think I know what I am doing, or suffer otherwise. Those who want to
upgrade their kernels have a choice between vendor suplied rpms, debs,
tar.gz´s or the one and only from [ftp|http]//ftp.**.kernel.org. If they
choose the latter, I would presume they are able to patch that one to
their liking. 

OK I confess I usually chicken out and wait for those who_really_
know what they are doing, to supply their patches to the mainstream
kernel.

What I am trying to say is that I am perfectly happy to wait until the
maintainers integrate the code into the mainstream kernel.

Ralf
-- 
 P: Linus Torvalds  patch-2.2.4
-S: Buried alive in diapers
+S: Buried alive in reporters
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.17 broken with initrd

[Richard B. Johnson]

On Wed, 13 Sep 2000, Joseph Carter wrote:

> I've been fighting with this for a couple of days now.  I've been trying
> under lilo, syslinux, and grub to get the kernel to follow the documented
> behavior of executing /linuxrc if you tell it to load an initrd as it did
> back in 2.0.35 (which was the last time I actually tried to use an initrd
> for anything..)
> 
> The 2.4.0test kernels work fine.  For the record:
> 
> -­8<--  /usr/src/linux-2.2.17
>   :
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_SIZE=4096
> CONFIG_BLK_DEV_INITRD=y
>   :
> --8<--
> 
> Any ideas why this isn't working?  More importantly, if this is known not
> to work right, how are distributions coping with the inability to use
> /linuxrc?  Documentation other than that in the kernel tree which was
> written in 1996 seems to be scarce.
> 

First, see if this works. This makes a simple boot-through RAMDISK and
therefore tests it without all the other things that can go wrong.

This should help to isolate problems.

#!/bin/sh
#
#
export VER=$1
RAMDISK_IMAGE=/tmp/RamImage-${VER}
RAMDISK=/tmp/Ramdisk
TMPC=/tmp/Temp.c
TMPF=/tmp/TmpExe
DISKSIZE=2048
SYS=/usr/src/linux-${VER}/arch/i386/boot/bzImage
if [ "$1" = "" ] ;
   then
   echo "Usage:"
   echo "make_ramdisk "
   exit 1
fi
if [ ! -f ${SYS} ] ;
   then
echo "File not found, ${SYS}"
exit 1
fi
if ! dd if=/dev/fd0 of=/dev/null bs=1k count=1 2>/dev/null ;
then
   echo "Floppy drive error!"
   echo "Maybe no diskette in the drive?"
   exit 1
fi
#
#  Make a little program called modprobe. This just returns 0.
#
echo "int main(){">${TMPC}
echo "return 0;}">>${TMPC}
gcc -O2 -o modprobe ${TMPC} -static
strip modprobe 
rm ${TMPC}
#
#  Make a little program called init. This just prints a moving message and
#  waits forever.
#
echo "#include ">${TMPC}
echo "main(){">>${TMPC}
echo "int r, c;">>${TMPC}
echo "for(;;){">>${TMPC}
echo "r=rand()%25;c=rand()%68;printf(\"\033[%d;%dH Working! \", r, c);">>${TMPC}
echo "fflush(stdout);usleep(50);">>${TMPC}
echo "printf(\"\033[%d;%dH  \",r,c);fflush(stdout);">>${TMPC}
echo "}}">>${TMPC}
gcc -O2 -o init ${TMPC} -static
strip init
rm ${TMPC}
#
#  Make a RAM Disk file and mount it using the loop device.
#  Remove the lost+found directory to save space.
#
umount ${RAMDISK} 2>/dev/null
rm -rf ${RAMDISK} 2>/dev/null
mkdir  ${RAMDISK} 2>/dev/null
dd if=/dev/zero of=${RAMDISK_IMAGE} bs=1k count=${DISKSIZE}
/sbin/mke2fs -Fq ${RAMDISK_IMAGE} ${DISKSIZE}
mount -o loop -t ext2 ${RAMDISK_IMAGE} ${RAMDISK}
rmdir ${RAMDISK}/lost+found
#
#  Make the required directories in the RAM Disk.
#
mkdir -m 777 ${RAMDISK}/dev
mkdir -m 777 ${RAMDISK}/etc
mkdir -m 777 ${RAMDISK}/lib
mkdir -m 777 ${RAMDISK}/usr
mkdir -m 777 ${RAMDISK}/usr/local
mkdir -m 777 ${RAMDISK}/bin
mkdir -m 777 ${RAMDISK}/sbin
mkdir -m 777 ${RAMDISK}/tmp
mkdir -m 777 ${RAMDISK}/proc
#
#  Make the required devices.
#
mknod ${RAMDISK}/dev/null   c 1 3
mknod ${RAMDISK}/dev/ram0   b 1 0 
mknod ${RAMDISK}/dev/ram1   b 1 1
mknod ${RAMDISK}/dev/memc 1 1
mknod ${RAMDISK}/dev/ttyS0  c 4 64 
mknod ${RAMDISK}/dev/tty0   c 4 0
mknod ${RAMDISK}/dev/tty1   c 4 1
mknod ${RAMDISK}/dev/tty2   c 4 2
mknod ${RAMDISK}/dev/tty3   c 4 3
mknod ${RAMDISK}/dev/tty4   c 4 4
mknod ${RAMDISK}/dev/ttyc 5 0
mknod ${RAMDISK}/dev/ttyp0  c 3 0
mknod ${RAMDISK}/dev/ttyp1  c 3 1 
mknod ${RAMDISK}/dev/ttyp2  c 3 2 
mknod ${RAMDISK}/dev/ttyp3  c 3 3 
mknod ${RAMDISK}/dev/ttyp4  c 3 4 
mknod ${RAMDISK}/dev/ttyp5  c 3 5 
mknod ${RAMDISK}/dev/ptyp0  c 2 0 
mknod ${RAMDISK}/dev/ptyp1  c 2 1 
mknod ${RAMDISK}/dev/ptyp2  c 2 2 
mknod ${RAMDISK}/dev/ptyp3  c 2 3 
mknod ${RAMDISK}/dev/ptyp4  c 2 4 
mknod ${RAMDISK}/dev/ptyp5  c 2 5 
mknod ${RAMDISK}/dev/zero   c 1 5
#
#  Set some compatibility links.
#
ln -s /dev/tty0 ${RAMDISK}/dev/systty
ln -s /dev/tty0 ${RAMDISK}/dev/console
ln -s /dev/ram1 ${RAMDISK}/dev/ram
ln -s /lib  ${RAMDISK}/usr/lib
ln -s /lib  ${RAMDISK}/usr/local/lib
#
#
#  Copy the files and libraries. All of the files are stripped
#  to save space.
#
cp modprobe ${RAMDISK}/sbin/modprobe
cp init ${RAMDISK}/sbin/init
#
#
#  Unmount the RAM Disk. Remove its mount-point but save the file itself. 
#
sync
df  ${RAMDISK}
umount  ${RAMDISK}
rmdir   ${RAMDISK}
sync
#
#   Make an ext2 file-system on a floppy and mount it. Remove the
#   lost+found directory to save space.
#
umount /mnt 2>/dev/null
/sbin/mke2fs -q /dev/fd0
mount -t ext2 /dev/fd0 /mnt
rmdir /mnt/lost+found
#
#  Compress the RAM Disk image into a file on the mounted file-system.
#  Remove the original RAM Disk image, then copy the required boot
#  files to the mounted file-system also.
#
gzip < ${RAMDISK_IMAGE} >/mnt/initrd-${VER}
rm ${RAMDISK_IMAGE}
cp ${SYS} /mnt/vmlinuz-${VER}
cp /boot/boot.b /mnt/boot.b
#
#  Now execute lilo to install t

Fix for non-booting Alpha with BRIDGE_OTHER device

[Michal Jaegermann]

I found by an experiment that an Alpha with a device which provides
its own PCI bridge, and if that device is on a PCI bus 0, will stop
booting right after "Partition check" messages.  The only way out is
through a power switch.  One can still boot if the device in question
is plugged in a slot on a PCI bus 1.

That particular hardware which revealed the problem is in fact SCI
board from Scali ( http://www.scali.com ) used in a cluster
communication and Scali provides a fix which makes machines bootable
again.

Here it is recreated against linux-2.2.18pre6.  It will actually
apply to a wide range of kernels but with a possible line offsets
noise.

--- linux-2.2.18p/arch/alpha/kernel/bios32.c.orig   Wed Jun  7 15:26:42 2000
+++ linux-2.2.18p/arch/alpha/kernel/bios32.cWed Sep 13 14:08:05 2000
@@ -828,6 +828,7 @@
 
for (dev = bus->devices; dev; dev = dev->sibling) {
if ((dev->class >> 16 != PCI_BASE_CLASS_BRIDGE) ||
+   (dev->class >> 8 == PCI_CLASS_BRIDGE_OTHER) ||
(dev->class >> 8 == PCI_CLASS_BRIDGE_PCMCIA)) {
disable_dev(dev);
}
@@ -840,6 +841,7 @@
 
for (dev = bus->devices; dev; dev = dev->sibling) {
if ((dev->class >> 16 != PCI_BASE_CLASS_BRIDGE) ||
+   (dev->class >> 8 == PCI_CLASS_BRIDGE_OTHER) ||
(dev->class >> 8 == PCI_CLASS_BRIDGE_PCMCIA)) {
layout_dev(dev);
}
@@ -1081,6 +1083,7 @@
 */
for (dev = pci_devices; dev; dev = dev->next) {
if ((dev->class >> 16 == PCI_BASE_CLASS_BRIDGE) &&
+   (dev->class >> 8 != PCI_CLASS_BRIDGE_OTHER) &&
(dev->class >> 8 != PCI_CLASS_BRIDGE_PCMCIA))
continue;
 
It indeed makes possible to boot regardles of a slot with SCI in it and
in tests on various Alphas _without_ that device does not seem to harm
anything - which is not a big surprise as otherwise PCMCIA would likely
be a problem too.:-)  Any comments from those who sleep with PCI specs
under pillows?  Should not that be included into standart kernels?

In arch/sparc64/kernel/psycho.c exists already a code which seems to
be somewhat related.

  Michal
  [EMAIL PROTECTED]

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

Re: [patchlet] Minor cleanup in mm/swapfile.c (2.4.0t8)

[Juan J. Quintela]

> "rasmus" == Rasmus Andersen <[EMAIL PROTECTED]> writes:

rasmus> Hi.
rasmus> This patch does minor and strightforward cleanup in mm/swapfile.c.

Please, don't apply, SWP_WRITEOK is defined as two bits:

#define SWP_WRITEOK 3

that means that 
((p->flags & SWP_WRITEOK) == SWP_WRITEOK) != (p->flags & SWP_WRITEOK)



rasmus> while (1) {
rasmus> p = &swap_info[type];
rasmus> -   if ((p->flags & SWP_WRITEOK) == SWP_WRITEOK) {
rasmus> +   if (p->flags & SWP_WRITEOK) {
rasmus> swap_device_lock(p);
rasmus> offset = scan_swap_map(p, count);
rasmus> swap_device_unlock(p);



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Linux 2.2.17 broken with initrd

[Joseph Carter]

I've been fighting with this for a couple of days now.  I've been trying
under lilo, syslinux, and grub to get the kernel to follow the documented
behavior of executing /linuxrc if you tell it to load an initrd as it did
back in 2.0.35 (which was the last time I actually tried to use an initrd
for anything..)

The 2.4.0test kernels work fine.  For the record:

-­8<--  /usr/src/linux-2.2.17
  :
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
  :
--8<--

Any ideas why this isn't working?  More importantly, if this is known not
to work right, how are distributions coping with the inability to use
/linuxrc?  Documentation other than that in the kernel tree which was
written in 1996 seems to be scarce.

-- 
Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3
Software developer, Progeny Linux Systems 20F6 2261 F185 7A3E 79FC
http://www.progenylinux.com/  44F9 8FF7 D7A3 DCF9 DAB3
My opinions might not be Progeny's.  Even if they're not, I'm still right.

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Andi Kleen <[EMAIL PROTECTED]> writes:

 > On Wed, Sep 13, 2000 at 11:51:45AM -0400, Theodore Y. Ts'o
 > wrote:
>>
>> So this is a really stupid question, but I'll ask it anyway.
>> If you just need a cookie, is there any way that you might be
>> able to steal a few bits from i_generation field for that
>> purpose?  (This assumes that we only worry about solving the
>> problem for NFS.)

 > No, it does not help. i_generation is only in the NFS file
 > handle, but not in the fattr/file id this is used for cache
 > checks. The NFS file handle has to stay identical anyways, as
 > long as the inode is not deleted/reused.


You might be able to steal a couple of bytes and then rewrite ext2fs
to mask those out from the 'i_generation' field, but it would mean that
you could no longer boot your old 2.2.16 kernel without trouble on
existing clients.

I'm no expert on the consequences of such a change on ext2fs and what
it might do to other OSes, but my gut feeling is that this is perhaps
one solution that we should try to avoid.

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

2.4.0 SCSI doesn't compile without modules

[Anton Altaparmakov]

Just discovered that if you try to compile 2.4.0-test8 without module 
support then the compilation (or linking to be more exact) fails at:

drivers/scsi/scsidrv.o: In function 'init_sd':
drivers/scsi/scsidrv.o(.text+0x1efa): undefined reference to 
'scsi_register_module'
drivers/scsi/scsidrv.o: In function 'exit_sd':
drivers/scsi/scsidrv.o(.text+0x1f12): undefined reference to 
'scsi_unregister_module'

I have attached the .config file with which this happens...

Regards,

 Anton

-- 
  "Education is what remains after one has forgotten everything he 
learned in school." - Albert Einstein
-- 
Anton Altaparmakov  Voice: 01223-333541(lab) / 07712-632205(mobile)
Christ's CollegeeMail: [EMAIL PROTECTED]
Cambridge CB2 3BUICQ: 8561279
United Kingdom   WWW: http://www-stu.christs.cam.ac.uk/~aia21/


#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_M686FXSR is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_BYTES=32
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
# CONFIG_X86_UP_IOAPIC is not set

#
# General setup
#
# CONFIG_NET is not set
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
CONFIG_APM_IGNORE_USER_SUSPEND=y
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
CONFIG_APM_ALLOW_INTS=y
CONFIG_APM_REAL_MODE_POWER_OFF=y

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

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_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_LVM is not set
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_BOOT is not set
# CONFIG_AUTODETECT_RAID is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_PCI_WIP=y
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_AEC62XX_TUNING is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD7409 is not set
# CONFIG_AMD7409_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_D

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Albert D Cahalan <[EMAIL PROTECTED]> writes:

 > 20 bits * 3 timestamps == 60 bits 60 bits <= 8 bytes

 > So you do need 8 bytes.

Yes. Assuming that you want to implement the microseconds field on all 
3 timestamps. For NFS I would only need that precision on mtime.
Does anybody else see a need for it on ctime and/or atime?

 > I thought of this, but I don't think it is safe.

 > write to file X us=1 write to file Y us=1 write to file Y us=2
 > write to file Y us=3 write to file X us=2

 > Oops, "make" on some clients will think Y is newer than X.

 > Using the wrong unit would be OK, as long as it is a real
 > sub-second time unit that doesn't overflow... but then you
 > might as well convert it to microseconds.

Sure, but the alternative might be to reserve some bits as an
'operations counter' that is incremented every time an update is
performed. That way you might have milisecond resolution (which is the
sort of resolution that 'jiffies' & friends offers) + a few extra bits
that would be there for make/NFS/... update consistency.

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

Re: [ANNOUNCE] Darkstar Development Project

[mberglund]

On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:

> On Tue, 12 Sep 2000, Ralf Baechle wrote:
> > On Mon, Sep 11, 2000 at 02:39:42PM -0700, Larry McVoy wrote:
> > > On the other hand, if you do a
> > >
> > > find . -type f | xargs touch
> > > time cvs update .
> > >
> > > it will melt down your DSL line for what seems forever.  I killed it after
> > > 20 minutes, I have better things to do with my bandwidth.   It's pretty
> > > clear that CVS is comparing timestamps so if your files get modified at
> > > all, it's going to transfer them to see what needs to be updated.  The
> > > same sort of "touch all, then update" operation in BK has no effect on
> > > performance, BK doesn't do its work that way.
> > 
> > >From some random Linux source tree's .hdepend:
> > 
> > /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h: \
> >/usr/people/ralf/src/linux/linux/include/asm/mipsregs.h \
> >/usr/people/ralf/src/linux/linux/include/asm/sn/addrs.h
> > @touch /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h
> > /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/arch.h: \
> >$(wildcard /usr/people/ralf/src/linux/linux/include/config/sgi/sn0/n/mode.h)
> > @touch /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/arch.h
> > [...]
> > 
> > Linux, born to be CVS worst case ...
> 
> Which also hinders compiling kernels in `cp -rl'd read-only trees...
> 

I just thought I would remind all the nay-sayers that the *BSD world has
been doing something along this line since at least 1990. While some of
the programs have changed, the functionality has remained largely the
same. 

It can be done.It will be done.  

You don't have to help, but we could use it.

And we have paid attention to some of the valid differences between CVS
and CVsup.

Just a thought,
Matt

Unix is best described as an old, sturdy tree.
It is well structured, always growing, and has passed the test of time.

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

Re: Booting into /bin/bash

[Ion Badulescu]

On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote:

> Stick a setsid() before the tty stuff.

Have you tried it? There is a good reason why I put the setsid() call so
early in kernel's init(). Once the initialization is done, init will have
several kernel threads as part of its process group, even though it's not
a process leader itself... Yeah, inconsistent, but enough to make
setsid() fail.

At the very very least, the part of my patch that adds the setsid() call
should be applied, so process number 1 _can_ acquire a controlling tty if
it wants to.

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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Proposal: Linux Kernel Patch Management System

[Jeff Garzik]

Mitchell Blank Jr wrote:
> 
> Alan Cox wrote:
> > Humans will generally get a weird report from sending Linus a message wonder
> > what all this field stuff is and mail someone else instead.
> 
> If they're able to create a patch, hopefully they'd be able to fill in
> a simple email template (and I've seen some pretty dim folks manage to
> register domains with InterNIC, so email templates aren't that hard :-)

When I sent Linus ten or twenty patches, that means I'm filling in ten
to twenty e-mail templates, yum :)

Jeff



-- 
Jeff Garzik  | Windows NT Performance,
Building 1024| on the next "In Search Of"
MandrakeSoft, Inc.   |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[TEST] patch for eepro driver over 2.2.17

[aris]

hi,
some people reported problems in eepro boards with 2.2.17
driver. please apply this patch over 2.2.17 version.
warning: this is a _test_ patch! i've tested with etherexpress 10 (the
only board supported by this driver that i have here - donations are very
welcome ;)) and it works very well under heavy load.
for interested people: test it and tell me what you think.
thanks,

-- 
Aris
---
Aristeu Sergio Rozanski Filho [EMAIL PROTECTED]
---


--- linux/drivers/net/eepro.c.old   Tue Sep 12 15:41:50 2000
+++ linux/drivers/net/eepro.c   Wed Sep 13 12:00:49 2000
@@ -212,6 +214,12 @@
   version of the 82595 chip. */
int stepping;
spinlock_t lock; /* Serializing lock  */ 
+   unsigned rcv_ram;
+   unsigned rcv_start;
+   unsigned xmt_bar;
+   unsigned xmt_lower_limit_reg;
+   unsigned xmt_upper_limit_reg;
+   unsigned eeprom_reg;
 };
 
 /* The station (ethernet) address prefix, used for IDing the board. */
@@ -356,24 +364,20 @@
 
 #defineRCV_HEADER  8
 #define RCV_DEFAULT_RAM0x6000
-#define RCV_RAMrcv_ram
-
-static unsigned rcv_ram = RCV_DEFAULT_RAM;
+#define RCV_RAMlp->rcv_ram
 
 #define XMT_HEADER 8
 #define XMT_RAM(RAM_SIZE - RCV_RAM)
 
-#define XMT_START  ((rcv_start + RCV_RAM) % RAM_SIZE)
+#define XMT_START  ((lp->rcv_start + RCV_RAM) % RAM_SIZE)
 
-#define RCV_LOWER_LIMIT(rcv_start >> 8)
-#define RCV_UPPER_LIMIT(((rcv_start + RCV_RAM) - 2) >> 8)
+#define RCV_LOWER_LIMIT(lp->rcv_start >> 8)
+#define RCV_UPPER_LIMIT(((lp->rcv_start + RCV_RAM) - 2) >> 8)
 #define XMT_LOWER_LIMIT(XMT_START >> 8)
 #define XMT_UPPER_LIMIT(((XMT_START + XMT_RAM) - 2) >> 8)
 
 #define RCV_START_PRO  0x00
 #define RCV_START_10   XMT_RAM
-   /* by default the old driver */
-static unsigned rcv_start = RCV_START_PRO;
 
 #defineRCV_DONE0x0008
 #defineRX_OK   0x2000
@@ -422,7 +426,6 @@
 
 #defineXMT_BAR_PRO 0x0a
 #defineXMT_BAR_10  0x0b
-static unsigned xmt_bar = XMT_BAR_PRO;
 
 #defineHOST_ADDRESS_REG0x0c
 #defineIO_PORT 0x0e
@@ -440,8 +443,6 @@
 #defineXMT_UPPER_LIMIT_REG_PRO 0x0b
 #defineXMT_LOWER_LIMIT_REG_10  0x0b
 #defineXMT_UPPER_LIMIT_REG_10  0x0a
-static unsigned xmt_lower_limit_reg = XMT_LOWER_LIMIT_REG_PRO;
-static unsigned xmt_upper_limit_reg = XMT_UPPER_LIMIT_REG_PRO;
 
 /* Bank 2 registers */
 #defineXMT_Chain_Int   0x20/* Interrupt at the end of the transmit chain 
*/
@@ -466,7 +467,6 @@
 
 #define EEPROM_REG_PRO 0x0a
 #define EEPROM_REG_10  0x0b
-static unsigned eeprom_reg = EEPROM_REG_PRO;
 
 #define EESK 0x01
 #define EECS 0x02
@@ -528,7 +528,8 @@
 #define eepro_ack_tx(ioaddr) outb (TX_INT, ioaddr + STATUS_REG)
 
 /* a complete sel reset */
-#define eepro_complete_selreset(ioaddr) {  eepro_dis_int(ioaddr);\
+#define eepro_complete_selreset(ioaddr) {  \
+   /* eepro_dis_int(ioaddr); */ \
lp->stats.tx_errors++;\
eepro_sel_reset(ioaddr);\
lp->tx_end = \
@@ -537,7 +538,7 @@
lp->tx_last = 0;\
dev->tbusy=0;\
dev->trans_start = jiffies;\
-   eepro_en_int(ioaddr);\
+   /*eepro_en_int(ioaddr); */ \
eepro_en_rx(ioaddr);\
}
 
@@ -670,7 +671,15 @@
 
lp = (struct eepro_local *)dev->priv;
 
-   /* Now, get the ethernet hardware address from
+   /* default values */
+   lp->rcv_start = RCV_START_PRO;
+   lp->xmt_bar = XMT_BAR_PRO;
+   lp->xmt_lower_limit_reg = XMT_LOWER_LIMIT_REG_PRO;
+   lp->xmt_upper_limit_reg = XMT_UPPER_LIMIT_REG_PRO;
+   lp->eeprom_reg = EEPROM_REG_PRO;
+   lp->rcv_ram = RCV_DEFAULT_RAM;
+
+   /* Now, get the ethernet hardware address from
   the EEPROM */
 
station_addr[0] = read_eeprom(ioaddr, 2, dev);
@@ -682,18 +691,18 @@
station_addr[0] == 0x) {

Re: [PATCH] ACPI interpreter makefile fix

[Jeff Garzik]

Andrey Panin wrote:
> 
> Hi all,
> 
> I recently returned from Sea Launch homeport and already made a new patch :))
> 
> This patch fixes bothering problem with ACPI interpreter Makefile.
> 
> Without this patch ACPI interpreter will unconditionaly recompiled
> every kernel build.
> 
> Hope it will be usefull.

Thanks!  This is one more item off my low priority todo list :)

-- 
Jeff Garzik  | Windows NT Performance,
Building 1024| on the next "In Search Of"
MandrakeSoft, Inc.   |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patchlet] Minor cleanup in mm/swapfile.c (2.4.0t8)

[kernel]

On Wed, 13 Sep 2000, Rasmus Andersen wrote:

> Hi.
> 
> This patch does minor and strightforward cleanup in mm/swapfile.c.

SWP_WRITEOK is defined as 3, so if (foo & SWP_WRITEOK) is not equivalent
to if ((foo & SWP_WRITEOK) == SWP_WRITEOK).  Cheers,

-ben

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

Re: Update Linux 2.4 Status/TODO list

[Jeff Garzik]

"Theodore Y. Ts'o" wrote:
> 
>Date:Wed, 13 Sep 2000 08:46:00 +0200
>From: Harald Dunkel <[EMAIL PROTECTED]>
> 
>How can I submit a bug report to be added to this list?
> 
> I *try* to follow bug reports sent to Linux-kernel, but if you want to
> be sure, send it directly to me ([EMAIL PROTECTED]).
> 
> (And now for the standard spiel of developers everywhere.)
> 
> [ This has been explicitly cc'ed to Richard Gooch so he can add it to
>   the linux-kernel FAQ (http://www.tux.org/lkml/).  There is a section
>   about bug reporting, but it's a bit thin.  The old-kernel-faq maintained
>   by Frohwalt Egerer has a lot more to say on this topic; what follows
>   below has taken some ideas and lists from the old faq. ]
> 
> Please follow general good bug reporting guidelines: Remember, the
> developers don't have access to your system, and they're not mind
> readers.  Tell us which kernel version, and what your hardware is (if
> you're not sure, more details is better than less).  At the very least,
[...]

Don't forget we have linux/REPORTING-BUGS.  If that is missing some good
suggestions, update that too...

Jeff



-- 
Jeff Garzik  | Windows NT Performance,
Building 1024| on the next "In Search Of"
MandrakeSoft, Inc.   |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Proposal: Linux Kernel Patch Management System

[Theodore Y. Ts'o]

   From: "Dunlap, Randy" <[EMAIL PROTECTED]>
   Date: Wed, 13 Sep 2000 09:17:55 -0700

   I appreciate Alan and you doing the kernel Status/TODO lists,
   but I think that you ought to simplify it for yourself at
   least (not that this would help Linus) by having maintainers
   do it instead of you do it.

   I'm willing to do it for USB, but I'm not willing to duplicate
   your work if you continue to do it.  I don't expect you to
   know/understand all of the filesystem or I/O subsystem or
   VM or process issues and be able to track them without asking
   lots of questions.  (Maybe you do, but I don't think that should
   be a requirement of the status-bot.)

Tell you what.  If you're willing to handle USB bug reports, I'll
segregate them into one area, and then have you send me updates every
few days.  

The updates should hopefully include bug reports from users who post to
linux-kernel.  What I currently do is save those e-mail messages in a
mail folder, and then include their names (but not e-mail address) in
the bug list.

   You should roll up reports from maintainers for a summary
   kernel status report.

If maintainers are willing to do a good job capturing bug reports,
that's great.  We can break those out into subsystems.  The problem is
that sometimes maintainers can get egos involved and not be willing to
admit that something might be a bug, especially if the bug report
doesn't contain full information.  This works much better if the
subsystem is maintained by a team, and one person of that team is
responsible for the overal bug tracking for that subsystem.  It sounds
like  the USB subsystem meets this criteria quite handily.

   PS:  This is probably too good to be true and would require
   the assistance of lots of maintainers, but that's how it
   should be done IMO.

Well, yes, and in a perfect world Linus would be using a bug tracking
system.  But we've managed quite well despite that not being the case.  :-)

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

Re: [patchlet] Minor cleanup in mm/swapfile.c (2.4.0t8)

[Rasmus Andersen]

On Wed, Sep 13, 2000 at 08:52:54PM +0200, Rasmus Andersen wrote:
> Hi.
> 
> This patch does minor and strightforward cleanup in mm/swapfile.c.

I have been corrected on this and retract it. Sorry to bother you all.
-- 
Regards,
Rasmus([EMAIL PROTECTED])

I am two fools, I know, for loving, and for saying so. 
  -- John Donne 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/