An error occurred fetching the project authors.
  1. 23 Nov, 2007 40 commits
    • Linus Torvalds's avatar
      Import 2.3.30pre4 · 583f5775
      Linus Torvalds authored
      583f5775
    • Linus Torvalds's avatar
      Import 2.3.30pre2 · 3b2e203d
      Linus Torvalds authored
      3b2e203d
    • Linus Torvalds's avatar
      Import 2.3.29 · 2cc90c98
      Linus Torvalds authored
      2cc90c98
    • Linus Torvalds's avatar
      Import 2.3.23pre1 · 58cf0ac4
      Linus Torvalds authored
      58cf0ac4
    • Linus Torvalds's avatar
      Import 2.3.20pre1 · a3c57c1b
      Linus Torvalds authored
      a3c57c1b
    • Linus Torvalds's avatar
      Import 2.3.18pre1 · 9af6f6e4
      Linus Torvalds authored
      9af6f6e4
    • Linus Torvalds's avatar
      Import 2.3.17pre1 · ba51f1a1
      Linus Torvalds authored
      ba51f1a1
    • Linus Torvalds's avatar
      Import 2.3.16 · 0d447745
      Linus Torvalds authored
      0d447745
    • Linus Torvalds's avatar
      Import 2.3.16pre1 · 9aa2c66a
      Linus Torvalds authored
      9aa2c66a
    • Linus Torvalds's avatar
      Linux 2.3.15 · 95857c64
      Linus Torvalds authored
      There's a rather huge patch-set out there now, taking the 2.3.x series to
      2.3.15.
      This has a lot of the merge code I've been sent over the last two weeks,
      but I will invariably have missed some, if for no other reason than simply
      that I got absolutely _flooded_ by people sending me patches.
      
      One of the more interesting things was the SMP pipe cleanup sent by
      Richard, but try as I might it was never really stable under load on x86 -
      not with the plain semaphores in 2.3.14, and not with the patches Andrea
      had either. I assume Richard tested it on an alpha with the much more
      well-thought-out atomic operation that the alpha provides.
      
      I ended up rewriting the x86 semaphore code (and some of Richards pipe
      code too, for that matter, to get rid of some races in waking things up),
      and it doesn't show the problems I saw before, but hey, maybe I just
      exchanged one set of problems for another set that I can't trigger any
      more. Give me feedback, please.
      
      Other features that don't impact everybody, but are rather major:
       - ATM support merged in
       - firewalling is gone (again), replaced by an even more generic netfilter
         facility.
       - general networking merges and updates
       - Various driver updates (ISDN, ISA PnP, sound, fbcon, usb, intelliport,
         you name it)
       - make system call return type "long" even if the system call only
         returns valid data in the lower order bits - we use the high bits for
         error handling, and some 64-bit architectures care (read: the Merced
         calling conventions want this because they don't automatically extend
         the return type - I bet it will be a new portability issue for other
         programs than just the kernel)
      
      Have fun,
                      Linus
      95857c64
    • Linus Torvalds's avatar
      Import 2.3.15pre3 · 9ec0c4e2
      Linus Torvalds authored
      9ec0c4e2
    • Linus Torvalds's avatar
      Import 2.3.15pre2 · 93ef77fa
      Linus Torvalds authored
      93ef77fa
    • Linus Torvalds's avatar
      Import 2.3.14pre1 · 6bbf087e
      Linus Torvalds authored
      6bbf087e
    • Linus Torvalds's avatar
      Import 2.3.13pre8 · ba2552ef
      Linus Torvalds authored
      ba2552ef
    • Linus Torvalds's avatar
      Import 2.3.13pre7 · 20046205
      Linus Torvalds authored
      20046205
    • Linus Torvalds's avatar
      Import 2.3.13pre6 · 152e5911
      Linus Torvalds authored
      152e5911
    • Linus Torvalds's avatar
      Import 2.3.13pre5 · e3be5730
      Linus Torvalds authored
      e3be5730
    • Linus Torvalds's avatar
      Import 2.3.10pre4 · 539fdbe4
      Linus Torvalds authored
      539fdbe4
    • Linus Torvalds's avatar
      Linux-2.3.7.. Let's be careful out there.. · cbf5d468
      Linus Torvalds authored
      The new and much improved fully page-cache based filesystem code is now
      apparently stable, and works wonderfully well performancewise. We fixed
      all known issues with the IO subsystem: it scales well in SMP, and it
      avoids unnecessary copies and unnecessary temporary buffers for write-out.
      
      The shared mapping code in particular is much cleaner and also a _lot_
      faster.
      
      In short, it's perfect. And we want as many people as possible out there
      testing out the new cool code, and bask in the success stories..
      HOWEVER. _Just_ in case something goes wrong [ extremely unlikely of
      course. Sure. Sue me ], we want to indeminfy ourselves. There just might
      be a bug hiding there somewhere, and it might eat your filesystem while
      laughing in glee over you being naive and testing new code. So you have
      been warned.
      
      In particular, there's some indication that it might have problems on
      sparc still (and/or other architectures), possibly due to the ext2fs byte
      order cleanups that have also been done in order to reach the
      afore-mentioned state of perfection.
      I'd be especially interested in people running databases on top of Linux:
      Solid server in particular is very fsync-happy, and that's one of the
      operations that have been speeded up by orders of magnitude.
      
                              Linus
      cbf5d468
    • Linus Torvalds's avatar
      Linux 2.3.7pre6 · 353ca85a
      Linus Torvalds authored
      Anybody who is interested in FS performance should take a look at the
      latest pre-patch of 2.3.7 (only pre-6 and possibly later: do NOT get any
      earlier versions. pre-5 still causes file corruption, pre-6 looks good so
      far).
      
      Careful, though: I fixed the problem that caused some corruption less than
      an hour ago, and while my tests indicate it all works fine, this is a very
      fundamental change. The difference to earlier kernels is:
      
       - ext2 (and some other block device filesystems that have been taught
         about it) uses write-through from the page cache instead of having a
         separate buffer cache and the page cache to maintain dirty state. This
         means much less memory pressure in certain situations, and it also
         means that we can avoid unnecessary copies.
       - the page cache has been threaded, so on SMP you can actually get
         noticeable speedups from processes that do concurrent file accesses.
       - lower-latency read paths, especially the cached case.
      
      Both of these are big, and fundamental changes. So don't mistake me when I
      say it is experimental: Ingo, David and I have been spending the last
      weeks (especialy Ingo, who deserves a _lot_ of credit for this all: I
      designed much of it, but Ingo made it a reality. Thanks Ingo) on making it
      do the right thing and be stable, but if you worry about not having
      backups you might not want to play with it even so. It took us this long
      just to make it work reliably enough that we can't find any obvious
      problems..
      
      The interesting areas are things like
       - writes to shared mappings now go blindingly fast. We're talking mondo
         cleanups here. We used to do really badly on this, now we do really
         well.
       - does bdflush still do the right thing? There may be a _lot_ of tweaking
         to do to get everything working at full capacity.
       - can people confirm that it is stable for everybody?
       - if anybody has 8-way machines etc, scalability is interesting. It
         should scale to 8-way no problem. We used to scale to 1-way, barely.
         Numbers?
       - fsync(). It doesn't work right now, but it should be easy to make it
         work well on big files etc - something we've never been able to do
         before (we used to lack the indexing from file to dirty blocks: now we
         have access to that quite automatically thanks to having the
         inode->page index in place, and the dirty blocks are right there)
      
      and I'd really appreciate comments from people, as long as people are
      aware that it _looks_ stable but we don't guarantee anything at this
      point.
      
                      Linus
      353ca85a
    • Linus Torvalds's avatar
      Linux 2.2.3pre3 · 777720de
      Linus Torvalds authored
      There's a new pre-patch for 2.2.3, one that I was already going to make
      the final 2.2.3, but I decided that I'm chicken after all, and that I
      might as well let some people check that it's sane.
      This pre-2.2.3 does:
      
       - Fix some silly NFS problems. Some of them can be quite bad: lost error
         notification of asynchronous writes, which can result in horrible
         problems (including lost email etc). Most people wouldn't ever notice,
         so don't panic, but forgetting about the error notification certainly
         counts as a brown paper bag.
       - Alpha should compile and work again
       - Various driver updates. This is actually the bulk of the patch, with
         IRDA updates, some scsi, video and sound driver updates etc.
       - The "mmap forgets about the file that was mapped" bug that has been
         discussed here. Only affected certain drivers.
       - shaper atomicity fixes
       - various minor TCP fixes
       - buffer growth fix and recursive IO memory reclaim fix from Andrea
       - network filter compiles ;)
       - unix gc fixes
      
      Tell me if you see problems, because I'm going to release it as 2.2.3
      unless people tell me otherwise..
      
                      Linus
      777720de
    • Linus Torvalds's avatar
      2.2.0-final · 182f4220
      Linus Torvalds authored
      Hoya,
       there's now a 2.2.0-pre9 on ftp.kernel.org, and when you compile it it
      will call itself 2.2.0-final. The reason is fairly obvious: enough is
      enough, and I can't make pre-kernels forever, it just dilutes the whole
      idea. The only reason the tar-file is not called 2.2.0 is that I want to
      avoid having any embarrassing typos that cause it to not compile under
      reasonable configurations or something like that. Unreasonable
      configurations I no longer care about.
      
      Every program has bugs, and I'm sure there are still bugs in this. Get
      over it - we've done our best, and nobody ever believed that there
      wouldn't be 2.2.x kernels to fix problems as they come up, and delaying
      2.2.0 forever is not an option.
      
      I have a wedding anniversary and a company party coming up, so I'm taking
      a few days off - when I get back I expect to take this current 2.2.0-final
      and just remove the "-final" from the Makefile, and that will be it. I
      suspect somebody _will_ find something embarrassing enough that I would
      fix it too, but let's basically avoid planning on that.
      In short, before you post a bug-report about 2.2.0-final, I'd like you to
      have the following simple guidelines:
       "Is this something Linus would be embarrassed enough about that he would
        wear a brown paper bag over his head for a month?"
      and
       "Is this something that normal people would ever really care deeply
        about?"
      
      If the answer to either question is "probably not", then please consider
      just politely discussing it as a curiosity on the kernel mailing lists
      rather than even sending email about it to me: I've been too busy the last
      few weeks, and I'd really appreciate it if I could just forget the worries
      of a release for a few days..
      
      But if you find something hilariously stupid I did, feel free to share it
      with me, and we'll laugh about it together (and I'll avoid wearing the
      brown paper bag on my head during the month of February). Do we have a
      deal?
      
      I've seen people working on a 2.2.0 announcement, and I'm happy - I've
      been too busy to think straight, much less worry about details like that.
      If everything turns out ok, I'll have a few memorable bloopers in my
      mailbox but nothing worse than that, and I can sit down and actually read
      the announcement texts that people have been discussing.
      
      ObFeatures:
       - m68k sync
       - various minor driver fixes (irda, net drivers, scsi, video, isdn)
       - SGI Visual Workstation support
       - adjtimex update to the latest standards
       - vfat silly buglet fix
       - semaphores work on alpha again
       - drop the inline strstr() that gcc got wrong whatever we did
       - kswapd needed to be a bit more aggressive
       - minor TCP retransmission and delack fixes
      Until Monday,
                              Linus
      182f4220
    • Linus Torvalds's avatar
      Import 2.1.121pre1 · 716454f0
      Linus Torvalds authored
      716454f0
    • Linus Torvalds's avatar
      Import 2.1.118 · 792ee2cd
      Linus Torvalds authored
      792ee2cd
    • Linus Torvalds's avatar
      Import 2.1.110pre2 · a19c0fb8
      Linus Torvalds authored
      a19c0fb8
    • Linus Torvalds's avatar
      Linux 2.1.103 · 05d033de
      Linus Torvalds authored
      >   I finnaly get the IRQ detection working with this patch,
      >  in linux-2.1.102/arch/i386/kernel/irq.c :
      Ok, does it still work with 2.1.103?
      2.1.103 has this patch, and also changes certain other things wrt interrupts in
      a way that both Edgar and Ingo seem to agree on, and it's been stable on
      certain boxes where plain 2.1.102 wasn't.
      
      2.1.103 also disables the early Cyrix cpuid stuff, because we now seem to
      have confirmation that this is what corrupts DMA IDE transfers (the cyrix
      code steps on magic motherboard IO ports - which Intel probably put there
      specially to mess with Cyrix. But maybe I'm just cynical). So people that
      have had problems with disk corruption and are brave enough to try, this
      could be an interesting experiment.
      [ Thanks to Gerard Roudier and Alan Cox for chasing down the IDE
        corruption issue, btw ]
      
                      Linus
      05d033de
    • Linus Torvalds's avatar
      Import 2.1.100pre2 · 57afa237
      Linus Torvalds authored
      57afa237
    • Linus Torvalds's avatar
      pre-2.1.99-3 · 6b6e62fd
      Linus Torvalds authored
      There's a new pre-patch on ftp.kernel.org, that does:
      
       - the networking fixes that didn't get into 98 due to various mess-ups
       - mtrr patches are there by default
       - all the irq fixes we know of to date are there (and hopefully even the
         ne2000 things should work with the SELF-IPI change)
       - various documentation updates and bugfixes (the best way to know that a
         stable kernel is approaching is to notice that somebody starts to
         spellcheck the kernel - it has so far never failed)
      
      in short, all known bugs should be fixed, but hey, what else is new?
      
                      Linus
      6b6e62fd
    • Linus Torvalds's avatar
      Linux 2.1.98 · 61cb5dec
      Linus Torvalds authored
      I just released a fairly small patch to 97 to bring it up to 98.
      
      I've gotten a lot of patches in the mail for the last week, and I've been
      ignoring most of them for obvious reasons. They aren't in any in-queue,
      you can more-or-less consider them lost - but don't resend them all
      immediately, because if I get another huge batch of patches then I'll just
      have to ignore them again.
      
      We're going slow and easy, and the plan is to not only keep me sane in the
      midst of all the diapers, but I'll also at the same time take the
      opportunity to actually enforce the feature-freeze. You've known about it
      for a long time, _tough_.
      
      Anyway, 2.1.98 _should_ fix:
      
       - the IDE/SCSI lockups. The irq enable/disable code was broken, and could
         do some really bad things. This tended to lock up the machine if you
         accessed your IDE disks heavily, or in particular if you had a mixture
         of IDE and SCSI and used them at the same time. Tell me if you still
         have problems - I'm sure there are still bugs left, and I want to hear
         about them.
       - memory management especially on small-memory machines. I think I made a
         good change to the allocation logic, and I'm hoping it will fix the bad
         bahevaiour on those wimpy machines that all you losers out there are
         using that have less than half a Gig of RAM. It certainly still works
         fine on my machine, and I'm certainly still too lazy to test it out on
         anything smaller.
      
      There's a few other updates too: the asm constraints are fixed, so it
      should compile again with other compiler versions than the particular one
      I happen to be using. And some of the SCSI drivers have been updated a
      bit.
      
      There's been a lot of discussion and patches on capabilities, and I
      haven't applied them yet, I'll let them simmer a bit. Similarly, I've seen
      so many pathes to kmod that my head is spinning, and as I don't use
      modules myself I'd really like to get feedback from users about the
      different patches, so that maybe I'll get something that everybody can
      agree on as acceptable. Right now I don't know which patch I should even
      begin looking at.
      
                      Linus
      61cb5dec
    • Linus Torvalds's avatar
      2.1.97 - for brave people only. · 5d2e518d
      Linus Torvalds authored
      I made a 2.1.97 release, in order to synch up with some large patch-sets
      I've gotten (non-x86 architecture updates). But due to the new baby this
      really hasn't been through my usual exhaustive stress-test ("make bzImage"
      + "boot") so buyer beware.
      
                      Linus
      5d2e518d
    • Linus Torvalds's avatar
      Import 2.1.95pre1 · 2dcb1dcf
      Linus Torvalds authored
      2dcb1dcf
    • Linus Torvalds's avatar
      Linux 2.1.93 · 3dd28001
      Linus Torvalds authored
      2.1.93 is out there. It is broken on other platforms than x86, because I
      had to move some initialization code around, but this shoul dbe very easy
      to fix (moving the device init code later makes a _lot_ of things easier:
      the system is essentially up and running, and "kmalloc()" etc actually
      works).
      
      Now the PCI init code actually has the full SMP knowledge, which it needs
      in order to get the interrupt mapping stuff right (for example - it might
      eventually need it for other reasons too).
      
      The PCI code has generally been cleaned up - thanks to Martin Mares (the
      PCI cleanup is what forced me to do the other changes - anything else
      would simply have been too ugly).
      
      2.1.93 should also fix the stupid things in 92 (modules don't load due to
      missing symbols, and NULL pointer dereferences in /proc under certain
      circumstances etc).
      
      The kernel should also be better at detecting the really low memory
      circumstances, and eventually return NULL instead of just looping forever
      trying to find a page that it won't ever find.
      
                              Linus
      
      [tytso on ext2fs changes:]
      These patches provide the following enhancements to ext2.
              * Fixed a bug where we weren't byte-swapping the feature set
                      flags before checking EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER
              * Added Stephen Tweedie's patches to allow the number of file
                      blocks which will be preallocated to be tuned (instead
                      of being fixed at 8 blocks).
              * Added Stephen Tweedie's patches to allow directory blocks to
                      be preallocated.  This change is only activated if the
                      EXT2_FEATURE_COMPAT_DIR_PREALLOC is enabled.  (There
                      will soon be a new release of e2fsprogs that will
                      allow you to turn this on.)  The change is compatible
                      with older kernels (that's why it's a COMPAT feature),
                      but we need to flag it in the feature set because the
                      e2fsck needs a few changes to support this.
              * Added future support for B-trees in directories.  I have a
                      design in mind which is fully read/only compatible
                      with the existing ext2 directories, which will make
                      its debut in the 2.3 kernel series.  This patch will
                      allow 2.2 kernels to mount filesystems with B-tree
                      directories read-write; if a 2.2 kernel tries to
                      modify a B-tree directory, the B-tree valid bit will
                      be turned off, since the B-tree structures won't be
                      updated by 2.2 kernels.  2.0 kernels will be able to
                      mount filesystems with B-tree directories read-only.
                      This defines a new feature, EXT2_FEATURE_RO_COMPAT_BTREE_DIR.
              * Added Jakub Jelinek's support for large files on 64-bit
                      platforms.  On a 64-bit platform, the first time you
                      expand a file past the 32-bit boundary, the
                      EXT2_FEATURE_RO_COMPAT_LARGE_FILE is turned on.
                      2.0 machines will be able to mount such filesystems
                      read-only.  2.2 kernels on 32-bit platforms will be
                      able such filesystems read-write, but they will only
                      be able to see the first 2**32 bytes of the file, and
                      any attempt to open a large file for read/write access
                      will cause an EBIGF error.
              * Added support for storing the file type in the directory
                      entry.  This optimization was added to BSD 4.4 and
                      makes a very big difference for a number of
                      operations, since application programs can avoid doing
                      a stat in a number of situations.  Support for this is
                      in the GNU user-land utilities, and is in glibc
                      already.  Beyond this patch, we also need to implement
                      a new getdents system call that will return the
                      information all the way to libc.
                      The reason why it's important to get this change into
                      2.2 is that it requires "stealing" 8-bits from the
                      name_len field of the directory entry.  Ext2fs limits
                      you to 255 characters in a file name, so the high-byte
                      of name_len is always zero.  However, older kernels
                      look at both bytes of name_len, and will get confused
                      if we try to store something there.  So we can only
                      update the file type field if the feature
                      EXT2_FEATURE_INCOMPAT_FILETYPE is enabled.
                      I want to get this support into the 2.2 kernel, since
                      even if it isn't used much (because people will want
                      their filesystems to be compatible with 2.0 kernels),
                      we will be able to migrate smoothly to using this
                      feature by default in the future.
      3dd28001
    • Linus Torvalds's avatar
      Import 2.1.92pre2 · 5e71242d
      Linus Torvalds authored
      5e71242d
    • Linus Torvalds's avatar
      Import 2.1.91pre1 · f26125cb
      Linus Torvalds authored
      f26125cb
    • Linus Torvalds's avatar
      Import 2.1.82 · 47c1864c
      Linus Torvalds authored
      47c1864c
    • Linus Torvalds's avatar
      Import 2.1.76 · 3c8de19e
      Linus Torvalds authored
      3c8de19e
    • Linus Torvalds's avatar
      Import 2.1.75 · 76315b72
      Linus Torvalds authored
      76315b72
    • Linus Torvalds's avatar
      Import 2.1.73 · 97ccc379
      Linus Torvalds authored
      97ccc379
    • Linus Torvalds's avatar
      Import 2.1.71 · 56dafec3
      Linus Torvalds authored
      56dafec3
    • Linus Torvalds's avatar
      Import 2.1.68 · 7f563ad6
      Linus Torvalds authored
      7f563ad6