- 27 Jan, 2005 3 commits
-
-
Kumar Gala authored
Fixes instances where gfar_read() was invoked in debug codewith a value, rather than a pointer. Signed-of-by:
Andy Fleming <afleming@freescale.com> Signed-of-by:
Jeff Garzik <jgarzik@pobox.com>
-
Andrew Morton authored
From: Steven Rostedt <rostedt@goodmis.org> If the transmit buffer of the e100 overflowed, then the system would hang. This was caused because the e100 driver would stop the queue, and netpoll_send_pkt in netpoll.c would then loop forever. This is because the e100 net_poll would never start the queue again after the transmits have completed. For those that use the e100 and netconsole, all you need to do is a sysreq 't' to lock up the system. Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Alexander Viro authored
Fixes breakage in getting MAC address on built-in tulip in alphastation 200 - without delay we are skipping bytes. Signed-off-by:
Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by:
-
- 26 Jan, 2005 2 commits
-
-
Herbert Pötzl authored
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>
-
bk://kernel.bkbits.net/davem/net-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
- 25 Jan, 2005 35 commits
-
-
Thomas Graf authored
Signed-off-by:
Thomas Graf <tgraf@suug.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
James Bottomley authored
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:
-
Herbert Xu authored
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:
-
http://linux-mh.bkbits.net/bluetooth-2.6David S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
Andrew Morton authored
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 authored
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:
-
Michal Ostrowski authored
Signed-off-by: -
Rusty Russell authored
Andreas Schwab <schwab@suse.de> points out that the ipt_conntrack match exposes struct
-
Rusty Russell authored
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:
-
Randy Dunlap authored
Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
-
Nathan Lynch authored
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:
-
Olaf Hering authored
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:
-
Rusty Russell authored
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:
-
Antonino Daplas authored
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:
-
Antonino Daplas authored
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 authored
Save blank state after do_blank|unblank_screen() since this flag is checked in fbcon_blank(). Signed-off-by:
-
Antonino Daplas authored
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 authored
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 authored
Set accelerator id for radeonfb. This id is checked by some user apps such as DirectFB. Signed-off-by:
-
Gerd Knorr authored
Signed-off-by:
-
Gerd Knorr authored
New version, this time using a #define, which should kill the reference to need_* as well ... Signed-off-by:
-
Gerd Knorr authored
- fix saa7134 module loading issues. Signed-off-by:
Gerd Knorr <kraxel@bytesex.org> Signed-off-by:
-
Gerd Knorr authored
- some cleanups merged. - use new tveeprom module to configure Hauppauge cards. - add new tv cards. Signed-off-by:
-
Gerd Knorr authored
This patch enables IR support for one AverMedia card and drops a obsolete function. Signed-off-by:
-
Gerd Knorr authored
- minor msp3400 updates. - add tea6320 support. Signed-off-by:
-
Gerd Knorr authored
Add a module which can parse config informations out of TV card eeproms. Will be used by bttv, cx88 and ivtv. Signed-off-by:
-
Gerd Knorr authored
- add new tuner types. - add support for digital tv tuning. - make tda9887 output ports more configurable. Signed-off-by:
-
Gerd Knorr authored
Add new tuner type to the v4l2 API. Signed-off-by:
-
Gerd Knorr authored
- Fix a memory leak in video-buf.c - Small update for the video-buf-dvb.c module. Signed-off-by:
-
Gerd Knorr authored
Remove unneeded casts of (void *) pointers. Signed-off-by:
Domen Puncer <domen@coderock.org> Signed-off-by:
-
Gerd Knorr authored
Remove unneeded casts of (void *) pointers. Signed-off-by:
-
Gerd Knorr authored
Remove unneeded casts of (void *) pointers. Signed-off-by:
-
Gerd Knorr authored
From: Michael Geng <linux@MichaelGeng.de> This patch switches the videotext drivers over to use the _IO macros for ioctls. video_usercopy() works correctly then. The drivers will also map the old to the new ioctl numbers to make sure old apps don't break. The patch also updates Documentation/ioctl.h to reflect that change. and deletes a unused struct in include/linux/videotext.h. Signed-off-by:
-
Dominik Brodowski authored
With Randy Dunlap <rddunlap@osdl.org> PCMCIA: convert internal I/O port addresses to unsigned long (kio_addr_t). Dominik pointed out that some ioaddr_t data are exposed to userspace, so don't touch those structures. Linus said: But the right thing is definitely to make an IO port pointer be "unsigned int" or even "unsigned long". URL: http://lkml.org/lkml/2005/1/11/168Signed-off-by:
Dominik Brodowski <linux@brodo.de> Signed-off-by:
-
Dominik Brodowski authored
From: Christoph Hellwig <hch@lst.de> socket->{a,c}_region aren't ever touched elsewhere, so let's kill this. Signed-off-by:Christoph Hellwig <hch@lst.de> Signed-off-by:
-
