Commits · 0a10109ba0124306a05531610076aea5799a49c8 · nexedi / linux

27 Jan, 2005 2 commits

[PATCH] SATA AHCI support for Intel ICH7R · 0a10109b

Jason Gaston authored Jan 27, 2005

This patch adds the Intel ICH7R DID's to the ahci.c SATA AHCI driver
for ICH7R SATA support.
Signed-off-by:  Jason Gaston <Jason.d.gaston@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

0a10109b

[libata sata_sil] add another Seagate driver to blacklist · d2ba360a
Haroldo Gamal authored Jan 27, 2005

d2ba360a

26 Jan, 2005 2 commits

[PATCH] fix ext3 quota allocation bug on error path ... · c4eadeb7

Herbert Pötzl authored Jan 25, 2005

looking at ext3_xattr_block_set() [fs/ext3/xattr.c] ...
I see that

                                error = -EDQUOT;
                                if (DQUOT_ALLOC_BLOCK(inode, 1))
                                        goto cleanup;

allocates a quota block, but right after that several
error echecks happen ...

                                if (error)
                                        goto cleanup;

and I don't see any DQUOT_FREE_BLOCK() in the errorpath

cleanup:
        if (ce)
                mb_cache_entry_release(ce);
        brelse(new_bh); 
        if (!(bs->bh && s->base == bs->bh->b_data))
                kfree(s->base);

        return error;

I'd suggest the attached fix.
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

c4eadeb7

Merge bk://kernel.bkbits.net/davem/net-2.6 · 9a6008b6
Linus Torvalds authored Jan 25, 2005
```
into ppc970.osdl.org:/home/torvalds/v2.6/linux
```
9a6008b6

25 Jan, 2005 36 commits

[NET]: Set NLM_F_MULTI for neighbour rtnetlink messages to userspace. · 7e09b979
Thomas Graf authored Jan 25, 2005
```
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
```
7e09b979

[PATCH] fix broken cross compiles · 0bfe221f

James Bottomley authored Jan 25, 2005

The change to kbuild to use -isystem `gcc -print-file-name=include`
broke our parisc crosscompile (and presumably everyone else's).

The reason is that you have a := in the NOSTDINC_FLAGS rule, which is
evaluated in situ (i.e.  before we've had a chance to set CROSSCOMPILE
on CC) so the gcc include path is actually the native one not the
crosscompiler one.  On parisc this causes us to be unable to handle
_builtin_va functions, but I bet there are a heap of other problems. 
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

0bfe221f

[XFRM]: Probe selected algorithm only. · d113f0f0

Herbert Xu authored Jan 25, 2005

This patch removes an annoying problem in xfrm_user.  As it is every
time an SA is added it probes every known algorithm in the universe.
Now if they all existed it would be OK.  However, for the ones which
don't actually exist this causes multiple /sbin/modprobe processes to
be spawned which slows the system down when you're adding hundreds of
SAs.

Since we know the type of algorithm required when we're adding a new
SA, we can get away with only probing the selected algorithms.  This
is what the following patch does for xfrm_user.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: James Morris <jmorris@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

d113f0f0

Merge http://linux-mh.bkbits.net/bluetooth-2.6 · 7a303cfd
David S. Miller authored Jan 25, 2005
```
into nuts.davemloft.net:/disk1/BK/net-2.6
```
7a303cfd

[TUN/TAP]: Add missing trans_start and last_rx setting. · b8dcfacc

Andrew Morton authored Jan 25, 2005

But as stated in bonding.txt, the ARP monitor requires the underlying
driver to update dev->trans_start and dev->last_rx.

The patch below adds the required functionality to the TUN/TAP driver.
Please test if this helps in your case.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

b8dcfacc

[NET]: netpoll: Fix NAPI polling race on SMP · e1809d4f

Andrew Morton authored Jan 25, 2005

From: Matt Mackall <mpm@selenic.com>

This avoids a nasty NAPI race by checking that work was actually scheduled
for the CPU netpoll is running on and pulls the NAPI-specific code out into
a separate function.

Original idea from Jeff Moyer
Tested by Andrew Tridgell
Signed-off-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

e1809d4f

[MAINTAINERS]: Fix my email address in PPPOE entry. · df0d0130
Michal Ostrowski authored Jan 25, 2005
```
Signed-off-by: David S. Miller <davem@davemloft.net>
```
df0d0130
[NETFILTER]: Avoid breaking userspace due to tuple change · a1a8d5dd
Rusty Russell authored Jan 25, 2005
```
Andreas Schwab <schwab@suse.de> points out that the ipt_conntrack
match exposes struct
```
a1a8d5dd

[NETFILTER]: IRC Zero Port Fix · 046ee630

Rusty Russell authored Jan 25, 2005

Ian Kumlien reported that new NAT code started sending out DCC
requests with 0 as the IP address. That prompted me to write a simple
IRC test case, which both illustrated the bug, and found another one
in that the wrong expectation was being set up when NAT occurred.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

046ee630

[VLAN]: Eliminate gcc warnings with PROC_FS=n · 234a7aee

Randy Dunlap authored Jan 25, 2005

Signed-off-by: Randy Dunlap <rddunlap@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

234a7aee

[PATCH] ppc64: fix use kref for device_node refcounting (fix) · 2bf82952

Nathan Lynch authored Jan 25, 2005

The recent ppc64 patch to use kref for device_node refcounting
introduced an unbalanced get/put in of_add_node which would cause
newly-added device nodes to be prematurely freed.  Sorry for the
screwup, a more rigorously tested fix follows.
Signed-off-by: Nathan Lynch <nathanl@austin.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

2bf82952

[PATCH] fix architecture names in hugetlbpage.txt · f05de2a3

Olaf Hering authored Jan 25, 2005

Anton fixed the code recently, but forgot to fix the documentation.  There
is no "ia32" thing, its i386.  The other thing is named 'ia64' in arch/
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

f05de2a3

[PATCH] Include type information as module info where possible · 7a1ebbdf

Rusty Russell authored Jan 25, 2005

Module parameters no longer have a type in general, as we use a callback
system (module_param_call()).  However, it's useful to include type
information in the commonly-used wrappers: module_param,
module_param_string and module_param_array.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

7a1ebbdf

[PATCH] matroxfb: FB_MATROX_G Kconfig changes · db8f4702

Antonino Daplas authored Jan 25, 2005

The current Kconfig entries for the Matrox G cards are quite confusing:

  config FB_MATROX_G450
          bool "G100/G200/G400/G450/G550 support"
          depends on FB_MATROX

  config FB_MATROX_G100A
          bool "G100/G200/G400 support"
          depends on FB_MATROX && !FB_MATROX_G450

  The patch below contains:
  - remove FB_MATROX_G100{,A} and rename FB_MATROX_G to FB_MATROX_G450
    (FB_MATROX_G450 included support from the G100 to the G550, so
     I don't see any non-historic reason why to call it G450)
  - small update for the FB_MATROX_G Kconfig text

  The disadvantage of this patch is, that you can no longer select support
  only for the G100-G400 without supporting the G450 and G550. But
  compared with the current confusing Kconfig setup, I don't think that's
  a big issue.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

db8f4702

[PATCH] backlight: Fix compile error if CONFIG_FB is unset · b20c5249

Antonino Daplas authored Jan 25, 2005

With Andrew Zabolotny <zap@homelink.ru>

   LD      init/built-in.o
    LD      .tmp_vmlinux1
  drivers/built-in.o(.text+0x9bfa): In function `lcd_device_register':
  : undefined reference to `fb_register_client'
  drivers/built-in.o(.text+0x9ce3): In function `lcd_device_unregister':
  : undefined reference to `fb_unregister_client'
  drivers/built-in.o(.text+0xa16a): In function `backlight_device_register':
  : undefined reference to `fb_register_client'
  drivers/built-in.o(.text+0xa253): In function `backlight_device_unregister':
  : undefined reference to `fb_unregister_client'
  make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

b20c5249

[PATCH] fbcon: Save blank state last · e2d6be2f

Antonino Daplas authored Jan 25, 2005

Save blank state after do_blank|unblank_screen() since this flag is checked in
fbcon_blank().
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

e2d6be2f

[PATCH] intelfb: Workaround for 830M · 4efc7303

Antonino Daplas authored Jan 25, 2005

This is a work around for the 830M with intelfb.  Relative to 2.6.10.  Without
this patch, updates to the DSPACNTR register will be ignored.

On the 830M, the display plane needs to be enabled before writing to any of
the other bits in the DSPACNTR register.

This patch detects the specific case, temporarily enables the plane, updates
the register, and then disables the plane.  It also appears to require some
settling time, but not an entire frame's time.

Without this change, the pixel format fields in DSPACNTR won't get written on
the 830M.
Signed-off-by: Andrew Pfiffer <andrewx.k.pfiffer@intel.com>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

4efc7303

[PATCH] vesafb: Change return error id · ceca3893

Antonino Daplas authored Jan 25, 2005

With <Stuart_Hayes@Dell.com>

I'm getting a message in dmesg: "localhost kernel: vesafb: probe of vesafb0
failed with error -6"

I searched the web, and found that a lot of people are getting this, but I
couldn't find an answer, so I looked into it.

This appears to be because "vesafb" returns -ENXIO ("No such device or
address") when its probe function fails.  However, driverse/base/bus.c spews
an error message during device_attach() if a matching driver's probe function
returns anything but -ENODEV ("No such device").
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ceca3893

[PATCH] radeonfb: Set accelerator id · 5244820e

Antonino Daplas authored Jan 25, 2005

Set accelerator id for radeonfb.  This id is checked by some user apps such as
DirectFB.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

5244820e