- 11 Jun, 2007 29 commits
-
-
Andrew Morton authored
I quuestion the testing status of that patch! Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Jaroslav Kysela <perex@suse.cz> Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ingo Molnar authored
Make timer-stats have almost zero overhead when enabled in the config but not used. (this way distros can enable it more easily) Also update the documentation about overhead of timer_stats - it was written for the first version which had a global lock and a linear list walk based lookup ;-) Andrew says: And this. Not a bugfix, but trivial and obvious and apparently some distros don't want to enable timer_stats because of the performance issue, but powertop uses timer_stats. Ingo replies: seconded. I have tested this with and without CONFIG_TIMER_STATS, with and without timer_stats collection activated. Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Bjorn Steinbrink authored
Fix two races in the timer stats lookup code. One by ensuring that the initialization of a new entry is finished upon insertion of that entry. The other by cleaning up the hash table when the entries array is cleared, so that we don't have any "pre-inserted" entries. Thanks to Eric Dumazet for reminding me of the memory barriers. Signed-off-by:
Bjorn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by:
Ian Kumlien <pomac@vapor.com> Acked-by:
-
Oleg Nesterov authored
Spotted by Satoru Takeuchi. kill_pgrp(task_pgrp(current)) sends the signal to the current's thread group, but can choose any sub-thread as a target for signal_wake_up(). This means that job_control() and tty_check_change() may return -ERESTARTSYS without signal_pending(). Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> Cc: Roland McGrath <roland@redhat.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: <stable@kernel.org> Signed-off-by:
-
Zou Nan hai authored
On systems with huge amount of physical memory, VFS cache and memory memmap may eat all available system memory under 4G, then the system may fail to allocate swiotlb bounce buffer. There was a fix for this issue in arch/x86_64/mm/numa.c, but that fix dose not cover sparsemem model. This patch add fix to sparsemem model by first try to allocate memmap above 4G. Signed-off-by:
Zou Nan hai <nanhai.zou@intel.com> Acked-by:
Suresh Siddha <suresh.b.siddha@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: <stable@kernel.org> Signed-off-by:
-
Jason Gaston authored
This patch updates the Intel ICH9M LPC Controller DID's, due to a specification change. Signed-off-by:
Jason Gaston <jason.d.gaston@intel.com> Cc: <stable@kernel.org> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Jay Cliburn authored
The Via VT3351 APIC does not play well with MSI and unleashes a flood of APIC errors when MSI is used to deliver interrupts. The problem was recently exposed when the atl1 network device driver, which enables MSI by default, stimulated APIC errors on an Asus M2V mainboard, which employs the Via VT3351. See http://bugzilla.kernel.org/show_bug.cgi?id=8472 for additional details on this bug. Signed-off-by:
Jay Cliburn <jacliburn@bellsouth.net> Signed-off-by:
-
Andrew Morton authored
Local variable `i' is a byte-counter. Don't use it as an index into an array of le32's. Reported-by:
"young dave" <hidave.darkstar@gmail.com> Cc: "Christoph Lameter" <clameter@sgi.com> Acked-by:
Anton Altaparmakov <aia21@cantab.net> Cc: <stable@kernel.org> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Tejun Heo authored
SB600 claims it can do 64bit DMA but it can't. Disable it. Signed-off-by:
Tejun Heo <htejun@gmail.com> Signed-off-by:
-
Hugh Dickins authored
Why is it that since the 2f1a2ccb console UTF-8 fixes went into 2.6.22-rc1, the PowerMac G5 shows only inverse video question marks for the text on tty2-6? whereas tty1 is fine, and so is x86. No fault of that patch: by removing the old fallback behaviour, it reveals that 32-bit setfont running on 64-bit kernels has only really worked on the current console, the rest getting faked by that inadequate fallback. Bring the compat do_unimap_ioctl into line with the main one: PIO_UNIMAP and GIO_UNIMAP apply to the specified tty, not redirected to fg_console. Use the same checks, and most particularly, remember to check access_ok: con_set_unimap and con_get_unimap are using __get_user and __put_user. And the compat vt_check should ask for the same capability as the main one, CAP_SYS_TTY_CONFIG rather than CAP_SYS_ADMIN. Added in vt_ioctl's vc_cons_allocated check for safety, though failure may well be impossible. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Daniel Drake authored
ZD1211 appears to be back in production: a number of new devices have been appearing! Some of them are using new radios. This patch adds support for the next generation AL2230 RF chip which has been spotted in a few new devices. [As this patch was too late for 2.6.21, the kernel was modified to reject AL2230S devices because for me and others, the devices silently failed (and this looked like a driver bug). After doing so, a few people reported that AL2230S devices were working correctly for them even before AL2230S support was present. I'd like to propose that we fix both situations by backporting the AL2230S support into 2.6.21-stable] Signed-off-by:
Daniel Drake <dsd@gentoo.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Oliver Endriss authored
Revert changeset http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=e7c424bbf9aa;style=gitweb Petri Helin found that this changeset broke tuning: 'Well, after going through the changes that might have had effect on tuning, I found out the one which had caused this problem. I do not know the actual reason behind the change, but the changelog says that it was meant to "Fix TD1316 tuner for DVBC". But at least in my case it seams to have broken the tuner instead.' Signed-off-by:
Oliver Endriss <o.endriss@gmx.de> Thanks-to: Petri Helin <phelin@googlemail.com> Acked-by:
e9hack <e9hack@googlemail.com> Acked-by:
Thomas Kaiser <linux-dvb@kaiser-linux.li> Signed-off-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Acked-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Stefan Richter authored
This adds a real parent device to eth1394's ethX device like in Linux 2.6.20 and older. However, due to unfinished conversion of the ieee1394 away from class_device, we now refer to the FireWire controller's PCI device as the parent, not to the ieee1394 driver's fw-host device. Having a real parent device instead of a virtual one allows udev scripts to distinguish eth1394 interfaces from networking bridges, bondings and the likes. Fixes a regression since 2.6.21: https://bugs.gentoo.org/show_bug.cgi?id=177199Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Roland Scheidegger authored
The i8042 driver fails detection of the AUX port with some chips, because they apparently do not change the I8042_CTR_AUXDIS bit immediately. This is known to affect at least HP500/HP510 notebooks, consequently the built-in touchpad will not work. The patch will simply reread the value until it gets the expected value or a retry limit is hit, without touching other workaround code in the same area. Signed-off-by:
Roland Scheidegger <sroland@tungstengraphics.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Daniel Drake authored
Commit 93c8bf45 modified the USB device matching behaviour to ignore interface class matches if the device class is vendor-specific. This patch adds explicit ID matches for Logitech QuickCam devices, which have a vendor specific device class (but standards-compliant audio interfaces). This fixes a 2.6.20 regression where the audio component of these devices was no longer usable. http://bugs.gentoo.org/show_bug.cgi?id=175715 https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/93822 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3040 Based on a patch from sergiom Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Auke Kok authored
To assure the symmetry of poll enable/disable in up/down, we should initialize the netdevice to be poll_disabled at load time. Doing this after register_netdevice leaves us open to another race, so lets move all the netif_* calls above register_netdevice so the stack starts out how we expect it to be. Signed-off-by:
Auke Kok <auke-jan.h.kok@intel.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Doug Chapman <doug.chapman@hp.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Sergei Shtylyov authored
HPT36x chip don't seem to have the channel enable bits, so prevent the IDE core from checking them... Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: <bzolnier@gmail.com> Signed-off-by:
-
Jiri Slaby authored
An omitted unlock. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Takashi Iwai authored
Some boards have the audio codec on slot #3 while the modem codec on slot #0. The driver should continue to probe the slots when no audio codec is found. This fixes the problem of no device on Toshiba A100 (and some other ATI SB450 devices). Signed-off-by:
-
Takashi Iwai authored
Probing the codec slots on ATI controller causes problems on some devices like Acer laptops. On these devices, reading from codec slot 3 results in the communication failure with the codec chip. Meanwhile, some laptops (e.g. Gateway) have the codec connection only on slot 3, and probing this slot is mandatory for them. The patch improves the probing robustness. The additional slots are now checked only when no codecs are found in the primary three slots. Signed-off-by:
-
Thomas Gleixner authored
The NOHZ patch contains a check for softirqs pending when a CPU goes idle. The BUG is unrelated to NOHZ, it just was made visible by the NOHZ patch. The BUG showed up mainly on P4 / hyperthreading enabled machines which lead the investigations into the wrong direction in the first place. The real cause is in cond_resched_softirq(): cond_resched_softirq() is enabling softirqs without invoking the softirq daemon when softirqs are pending. This leads to the warning message in the NOHZ idle code: t1 runs softirq disabled code on CPU#0 interrupt happens, softirq is raised, but deferred (softirqs disabled) t1 calls cond_resched_softirq() enables softirqs via _local_bh_enable() calls schedule() t2 runs t1 is migrated to CPU#1 t2 is done and invokes idle() NOHZ detects the pending softirq Fix: change _local_bh_enable() to local_bh_enable() so the softirq daemon is invoked. Thanks to Anant Nitya for debugging this with great patience ! Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Oleg Nesterov authored
It is a known fact that freezeable multithreaded workqueues doesn't like CPU_DEAD. We keep them only for the incoming CPU-hotplug rework. Sadly, we can't just kill create_freezeable_workqueue() right now, make them singlethread. Signed-off-by:
-
Miklos Szeredi authored
The wrong lookup flag was tested in ->create() causing havoc (error or Oops) when a regular file was created with mknod() in a fuse filesystem. Thanks to J. Cameijo Cerdeira for the report. Kernels 2.6.18 onward are affected. Please apply to -stable as well. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
NeilBrown authored
It is possible that real data or metadata follows the bitmap without full page alignment. So limit the last write to be only the required number of bytes, rounded up to the hard sector size of the device. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
If a raid0 has a component device larger than 4TB, and is accessed on a 32bit machines, then as 'chunk' is unsigned lock, chunk << chunksize_bits can overflow (this can be as high as the size of the device in KB). chunk itself will not overflow (without triggering a BUG). So change 'chunk' to be 'sector_t, and get rid of the 'BUG' as it becomes impossible to hit. Cc: "Jeff Zheng" <Jeff.Zheng@endace.com> Signed-off-by:
-
Andi Kleen authored
Only try to allocate MSRs once instead of for every CPU. This assumes the MSRs are the same on all CPUs which is currently true. P4-HT is a special case for different SMT threads, but the code always saves/restores all MSRs so it works identical. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Thomas Gleixner authored
The warning in the NOHZ code, which triggers when a CPU goes idle with softirqs pending can fill up the logs quite quickly. Rate limit the output until we found the root cause of that problem. Signed-off-by:
-
Thomas Gleixner authored
Booting a SMP kernel with maxcpus=1 on a SMP system leads to a hard hang, because ACPI ignores the maxcpus setting and sends timer broadcast info for the offline CPUs. This results in a stuck for ever call to smp_call_function_single() on an offline CPU. Ignore the bogus information and print a kernel error to remind ACPI folks to fix it. Affects 2.6.21 / 2.6.22-rc Signed-off-by:
-
Thomas Gleixner authored
Some systems have a HPET which is not incrementing, which leads to a complete hang. Detect it during HPET setup. Signed-off-by:
-
- 07 Jun, 2007 5 commits
-
-
Chris Wright authored
-
Patrick McHardy authored
[PATCH] NETFILTER: {ip, nf}_conntrack_sctp: fix remotely triggerable NULL ptr dereference (CVE-2007-2876) When creating a new connection by sending an unknown chunk type, we don't transition to a valid state, causing a NULL pointer dereference in sctp_packet when accessing sctp_timeouts[SCTP_CONNTRACK_NONE]. Fix by don't creating new conntrack entry if initial state is invalid. Noticed by Vilmos Nebehaj <vilmos.nebehaj@ramsys.hu> CC: Kiran Kumar Immidi <immidi_kiran@yahoo.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Chris Wright authored
Use simple_read_from_buffer to avoid possible underflow in cpuset_tasks_read which could allow user to read kernel memory. Note: This is fixed upstream in 85badbdfSigned-off-by:
-
Matt Mackall authored
Add data from zero-entropy random_writes directly to output pools to avoid accounting difficulties on machines without entropy sources. Tested on lguest with all entropy sources disabled. Signed-off-by:
Matt Mackall <mpm@selenic.com> Acked-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Matt Mackall authored
Fix cast error in entropy extraction. Add comments explaining the magic 16. Remove extra confusing loop variable. Signed-off-by:
-
- 24 May, 2007 2 commits
-
-
Chris Wright authored
-
Jordan Crouse authored
Allow in-place crypto operations. Also remove the coherent user flag (we use it automagically now), and by default use the user written key rather then the HW hidden key - this makes crypto just work without any special considerations, and thats OK, since its our only usage model. Signed-off-by:
Jordan Crouse <jordan.crouse@amd.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
- 23 May, 2007 4 commits
-
-
Chris Wright authored
-
Herbert Xu authored
The function crypto_mod_put first frees the algorithm and then drops the reference to its module. Unfortunately we read the module pointer which after freeing the algorithm and that pointer sits inside the object that we just freed. So this patch reads the module pointer out before we free the object. Thanks to Luca Tettamanti for reporting this. Signed-off-by:
-
Daniel Drake authored
When the PST tables are broken, powernow-k7 uses ACPI's processor_perflib to deduce the available frequency multipliers from the _PSS tables. Upon frequency change, processor_perflib performs some verification on the frequency (checks that it's within allowable bounds). powernow-k7 deals with absolute frequencies in KHz, whereas perflib only deals with MHz values. When performing the above verification, perflib multiplies the MHz values by 1000 to obtain the KHz value. We then end up with situations like the following: - powernow-k7 multiplies the multiplier by the FSB, and obtains a value such as 1266768 KHz - perflib belives the same state has frequency of 1266 MHz - acpi_processor_ppc_notifier calls cpufreq_verify_within_limits to verify that 1266768 is in the allowable range of 0 to 1266000 (i.e. 1266 * 1000) - it's not, so that frequency is rejected - the maximum CPU frequency is not reachable This patch solves the problem by rounding up the MHz values stored in perflib's tables. Additionally it corrects a broken URL. It also fixes http://bugzilla.kernel.org/show_bug.cgi?id=8255 although this case is a bit different: the frequencies in the _PSS tables are wildly wrong, but we get better results if we force ACPI to respect the fsb * multiplier calculations (even though it seems that the multiplier values aren't entirely correct either). Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Dave Jones authored
Mark Langsdorf points out that the correct define for this revision bump is 0x80000. Also to save us having to keep renaming the #define, give it a more meaningful name. Signed-off-by:
-
