Re: 2.6.26-git0: IDE oops during boot
Nish Aravamudan wrote:
> On 2/7/08, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>> On Thursday 07 February 2008, Kamalesh Babulal wrote:
>>> Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday 06 February 2008, Pavel Machek wrote:
> On Wed 2008-02-06 11:53:34, Pavel Machek wrote:
>> Hi!
>>
>> Trying to boot 2.6.25-git0 (few days old), I get
>>
>> BUG: unable to handle kernel paging request at ..ffb0
>> IP at init_irq+0x42e
init_irq? hmm...
>> Call trace:
>> ide_device_add_all
this comes from ide-generic
(Generic IDE host driver)
>> ide_generic_init
>> kernel_init
>> child_rip
>> vgacon_cursor
>> kernel_init
>> child_rip
>>
>> Excerpt from config:
>>
>> CONFIG_IDE=y
>> CONFIG_BLK_DEV_IDE=y
> Disabling CONFIG_IDE made my machine boot, as it was using libata
> anyway.
Kamalesh/Pavel:
Could you try latest git and see if the OOPS is still there?
[ Yeah, I'm unable to reproduce it. :( ]
Thanks,
Bart
>>> Hi Bart,
>>>
>>> The panic is reproducible with the 2.6.24-git16 kernel, the call trace is
>>> similar to the previous one
>> Thanks, I again reviewed ide-probe.c changes but nothing seems wrong...
>>
>> Could you please bisect it down to the guilty commit?
>
> Kamalesh, were you able to bisect this down? I just got hit by the
> same panic on a 4-way x86_64, with 2.6.24-git22.
>
> Thanks,
> Nish
Hi Nish,
I tried bisecting and the guilty patch seems to be
36501650ec45b1db308c3b51886044863be2d762 is first bad commit
commit 36501650ec45b1db308c3b51886044863be2d762
Author: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Date: Fri Feb 1 23:09:31 2008 +0100
ide: keep pointer to struct device instead of struct pci_dev in ide_hwif_t
the gdb output, also points to the changes made by the guilty patch
(gdb) p ide_device_add_all
$1 = {int (u8 *, const struct ide_port_info *)} 0x804176ac
(gdb) p/x 0x804176ac+0xb60
$2 = 0x8041820c
(gdb) l *0x8041820c
0x8041820c is in ide_device_add_all (drivers/ide/ide-probe.c:1249).
1244goto out;
1245}
1246
1247sg_init_table(hwif->sg_table, hwif->sg_max_nents);
1248
1249if (init_irq(hwif) == 0)
1250goto done;
1251
1252old_irq = hwif->irq;
1253/*
(gdb)
(gdb) p init_irq
$1 = {int (ide_hwif_t *)} 0x8041721f
(gdb) p/x 0x8041721f+0x1a4
$2 = 0x804173c3
(gdb) l *0x804173c3
0x804173c3 is in init_irq (include/asm/pci.h:101).
96 /* Returns the node based on pci bus */
97 static inline int __pcibus_to_node(struct pci_bus *bus)
98 {
99 struct pci_sysdata *sd = bus->sysdata;
100
101 return sd->node;
102 }
103
104 static inline cpumask_t __pcibus_to_cpumask(struct pci_bus *bus)
105 {
(gdb)
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: raw_pci_read in quirk_intel_irqbalance
On Sun, Feb 10, 2008 at 10:04:16PM -0700, Matthew Wilcox wrote:
> > "A disabled or non-existent device's configuration register space is
> > hidden. A disabled or non-existent device will return all ones for reads
> > and will drop writes just as if the cycle terminated with a Master Abort
> > on PCI."
>
> I'd like to thank Grant for pointing out to me that this is exactly what
> the write immediately above this is doing -- enabling device 8 to
> respond to config space cycles.
welcome.
...
> >From f565b65591a3f90a272b1d511e4ab1728861fe77 Mon Sep 17 00:00:00 2001
> From: Matthew Wilcox <[EMAIL PROTECTED]>
> Date: Sun, 10 Feb 2008 23:18:15 -0500
> Subject: [PATCH] Use proper abstractions in quirk_intel_irqbalance
>
> Since we may not have a pci_dev for the device we need to access, we can't
> use pci_read_config_word. But raw_pci_read is an internal implementation
> detail; it's better to use the architected pci_bus_read_config_word
> interface. Using PCI_DEVFN instead of a mysterious constant helps
> reassure everyone that we really do intend to access device 8.
>
> Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
> ---
> arch/x86/kernel/quirks.c |9 ++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
> index 1941482..c47208f 100644
> --- a/arch/x86/kernel/quirks.c
> +++ b/arch/x86/kernel/quirks.c
> @@ -11,7 +11,7 @@
> static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
> {
> u8 config, rev;
> - u32 word;
> + u16 word;
>
> /* BIOS may enable hardware IRQ balancing for
>* E7520/E7320/E7525(revision ID 0x9 and below)
> @@ -26,8 +26,11 @@ static void __devinit quirk_intel_irqbalance(struct
> pci_dev *dev)
> pci_read_config_byte(dev, 0xf4, );
> pci_write_config_byte(dev, 0xf4, config|0x2);
Can you also add a comment which points at the Intel documentation?
http://download.intel.com/design/chipsets/datashts/30300702.pdf
Page 34 documents 0xf4 register.
And I just doubled checked that the 0xf4 register value is restored later
in the quirk (obvious when you look at the code but not from the patch).
> - /* read xTPR register */
> - raw_pci_read(0, 0, 0x40, 0x4c, 2, );
> + /*
> + * read xTPR register. We may not have a pci_dev for device 8
> + * because it might be hidden until the above write.
> + */
> + pci_bus_read_config_word(dev->bus, PCI_DEVFN(8, 0), 0x4c, );
Yeah, this should work even though we don't have a dev for it.
Acked-by: Grant Grundler <[EMAIL PROTECTED]>
thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vmsplice exploit fix (was: splice: fix user pointer access in get_iovec_page_array)
Hi Daniel, On Feb 11, 2008 9:29 AM, Daniel Phillips <[EMAIL PROTECTED]> wrote: > I think many users would first go to kernel.org on a day like today, as > I did. Nothing to see there. We could do a way better job of getting > the word out. Any suggestions what I could have done better here? As soon as Linus merged the patch, I sent it to [EMAIL PROTECTED] and expected information to spread from there. I did also follow up on some vendor bugzillas (Debian, RHEL, Fedora) to make sure they were aware of the merged patch (they were). Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH] vmsplice exploit fix (was: splice: fix user pointer access in get_iovec_page_array)
On Sun, Feb 10, 2008 at 11:29:50PM -0800, Daniel Phillips wrote: > Kudos to all involved in the rapid response. But. > > Information on patching this vulnerability is not available front and > center in many of the places you would expect: kernel.org front page, > debian.org front page, covered on planet.debian.org but without a > pointer to the patch, and so on. So this post provides a subject line > for Google to find, and for good measure mentions the word > vulnerability. All currently active Linux kernel versions are now released with a fix for this problem. We have released them through our normal channels, with the needed information as to what the problem is, a pointer to the CVE number, and the patch itself. I don't think there's much more we need to do here, do you? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22.18
diff --git a/Makefile b/Makefile index 6a949eb..99c5e87 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 22 -EXTRAVERSION = .17 +EXTRAVERSION = .18 NAME = Holy Dancing Manatees, Batman! # *DOCUMENTATION* diff --git a/fs/splice.c b/fs/splice.c index e263d3b..dbbe267 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -1182,6 +1182,9 @@ static int get_iovec_page_array(const struct iovec __user *iov, if (unlikely(!base)) break; + if (!access_ok(VERIFY_READ, base, len)) + break; + /* * Get this base offset and number of pages, then map * in the user pages. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.22.18
We (the -stable team) are announcing the release of the 2.6.22.18 kernel. It fixes one thing, CVE-2008-0600. All users of the 2.6.22 series, with untrusted local users are strongly encouraged to upgrade. I'll also be replying to this message with a copy of the patch between 2.6.22.17 and 2.6.22.18 The updated 2.6.22.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=summary thanks, greg k-h Makefile|2 +- fs/splice.c |3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) Summary of changes from v2.6.22.17 to v2.6.22.18 Bastian Blank (1): splice: fix user pointer access in get_iovec_page_array() (CVE-2008-0600) Greg Kroah-Hartman (1): Linux 2.6.22.18 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] vfs: optimization to /proc//mountinfo patch
On Mon, 2008-02-04 at 01:28 -0800, Andrew Morton wrote: > On Mon, 04 Feb 2008 01:15:05 -0800 Ram Pai <[EMAIL PROTECTED]> wrote: > > > 1) reports deleted inode in dentry_path() consistent with that in __d_path() > > 2) modified __d_path() to use prepend(), reducing the size of __d_path() > > 3) moved all the functionality that reports mount information in /proc under > > CONFIG_PROC_FS. > > > > Could not verify if the code would work with CONFIG_PROC_FS=n, since it was > > impossible to disable CONFIG_PROC_FS. Looking for ideas on how to disable > > CONFIG_PROC_FS. this worked. thanks. There was one place in ipv4 that failed compilation with proc_fs disabled. Fixed that. Otherwise everything compiled cleanly. > > Do `make menuconfig', then hit '/' and search for "proc_fs". > > It'll tell you that you need to set EMBEDDED=y to disable procfs. > > > fs/dcache.c | 59 > > +++ > > fs/namespace.c |2 + > > fs/seq_file.c|2 + > > include/linux/dcache.h |3 ++ > > include/linux/seq_file.h |3 ++ > > Please resend after testing that, thanks. with procfs disabled, the boot fails, since nash(fedora's startup script) which links with libc.so library has dependencies on /proc. Nash segfaults and so does init. looking for ideas. without passing this hurdle, its hard to test the patch :( RP -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vmsplice exploit fix (was: splice: fix user pointer access in get_iovec_page_array)
Kudos to all involved in the rapid response. But. Information on patching this vulnerability is not available front and center in many of the places you would expect: kernel.org front page, debian.org front page, covered on planet.debian.org but without a pointer to the patch, and so on. So this post provides a subject line for Google to find, and for good measure mentions the word vulnerability. Also, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953 I think many users would first go to kernel.org on a day like today, as I did. Nothing to see there. We could do a way better job of getting the word out. Patch attached as posted above by Pekka. For the mortals among us: cd linux-2.6.recent && patch Cc: <[EMAIL PROTECTED]> Cc: Jens Axboe <[EMAIL PROTECTED]> Cc: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]> --- Bastian, can I have your Signed-off-by for this, please? Oliver, Niki, can you please confirm this closes the hole? fs/splice.c |3 +++ 1 file changed, 3 insertions(+) Index: linux-2.6/fs/splice.c === --- linux-2.6.orig/fs/splice.c +++ linux-2.6/fs/splice.c @@ -1237,6 +1237,9 @@ static int get_iovec_page_array(const st if (unlikely(!base)) break; + if (unlikely(!access_ok(VERIFY_READ, base, len))) + break; + /* * Get this base offset and number of pages, then map * in the user pages.
[SCSI] ses: fix memory leaks
please check it...
---
From: Yinghai Lu <[EMAIL PROTECTED]>
[SCSI] ses: fix memory leaks
fix leaking with scomp leaking when failing. Also free page10 on
driver removal and remove one extra space.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/ses.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
Index: linux-2.6/drivers/scsi/ses.c
===
--- linux-2.6.orig/drivers/scsi/ses.c
+++ linux-2.6/drivers/scsi/ses.c
@@ -416,11 +416,11 @@ static int ses_intf_add(struct class_dev
int i, j, types, len, components = 0;
int err = -ENOMEM;
struct enclosure_device *edev;
- struct ses_component *scomp;
+ struct ses_component *scomp = NULL;
if (!scsi_device_enclosure(sdev)) {
/* not an enclosure, but might be in one */
- edev = enclosure_find(>host->shost_gendev);
+ edev = enclosure_find(>host->shost_gendev);
if (edev) {
ses_match_to_enclosure(edev, sdev);
class_device_put(>cdev);
@@ -456,9 +456,6 @@ static int ses_intf_add(struct class_dev
if (!buf)
goto err_free;
- ses_dev->page1 = buf;
- ses_dev->page1_len = len;
-
result = ses_recv_diag(sdev, 1, buf, len);
if (result)
goto recv_failed;
@@ -473,6 +470,9 @@ static int ses_intf_add(struct class_dev
type_ptr[0] == ENCLOSURE_COMPONENT_ARRAY_DEVICE)
components += type_ptr[1];
}
+ ses_dev->page1 = buf;
+ ses_dev->page1_len = len;
+ buf = NULL;
result = ses_recv_diag(sdev, 2, hdr_buf, INIT_ALLOC_SIZE);
if (result)
@@ -489,6 +489,7 @@ static int ses_intf_add(struct class_dev
goto recv_failed;
ses_dev->page2 = buf;
ses_dev->page2_len = len;
+ buf = NULL;
/* The additional information page --- allows us
* to match up the devices */
@@ -506,11 +507,12 @@ static int ses_intf_add(struct class_dev
goto recv_failed;
ses_dev->page10 = buf;
ses_dev->page10_len = len;
+ buf = NULL;
no_page10:
- scomp = kmalloc(sizeof(struct ses_component) * components, GFP_KERNEL);
+ scomp = kzalloc(sizeof(struct ses_component) * components, GFP_KERNEL);
if (!scomp)
- goto err_free;
+ goto err_free;
edev = enclosure_register(cdev->dev, sdev->sdev_gendev.bus_id,
components, _enclosure_callbacks);
@@ -521,10 +523,9 @@ static int ses_intf_add(struct class_dev
edev->scratch = ses_dev;
for (i = 0; i < components; i++)
- edev->component[i].scratch = scomp++;
+ edev->component[i].scratch = scomp + i;
/* Page 7 for the descriptors is optional */
- buf = NULL;
result = ses_recv_diag(sdev, 7, hdr_buf, INIT_ALLOC_SIZE);
if (result)
goto simple_populate;
@@ -532,6 +533,8 @@ static int ses_intf_add(struct class_dev
len = (hdr_buf[2] << 8) + hdr_buf[3] + 4;
/* add 1 for trailing '\0' we'll use */
buf = kzalloc(len + 1, GFP_KERNEL);
+ if (!buf)
+ goto simple_polulate;
result = ses_recv_diag(sdev, 7, buf, len);
if (result) {
simple_populate:
@@ -598,6 +601,7 @@ static int ses_intf_add(struct class_dev
err = -ENODEV;
err_free:
kfree(buf);
+ kfree(scomp);
kfree(ses_dev->page10);
kfree(ses_dev->page2);
kfree(ses_dev->page1);
@@ -630,6 +634,7 @@ static void ses_intf_remove(struct class
ses_dev = edev->scratch;
edev->scratch = NULL;
+ kfree(ses_dev->page10);
kfree(ses_dev->page1);
kfree(ses_dev->page2);
kfree(ses_dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.25-rc1 , syntax error near unexpected token `;'
On Feb 10, 2008 5:47 PM, Mr. James W. Laferriere <[EMAIL PROTECTED]> wrote: > Hello All , grabbed using git just moments ago . > > make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install modules_install > > ...snip... > make -f scripts/Makefile.clean obj=sound/usb/usx2y > make -f scripts/Makefile.clean obj=usr >rm -rf .tmp_versions >rm -f arch/x86/boot/fdimage arch/x86/boot/image.iso > arch/x86/boot/mtools.conf > vmlinux System.map .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map > rm -f include/config/kernel.release > echo 2.6.25-rc1 > include/config/kernel.release > set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE > 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + > (c))';) > < /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [ > -r > include/linux/version.h ] && cmp -s include/linux/version.h > include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv > -f include/linux/version.h.tmp include/linux/version.h; fi > /bin/sh: -c: line 0: syntax error near unexpected token `;' > /bin/sh: -c: line 0: `set -e; ; mkdir -p include/linux/;(echo \#define > LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + > ((b) << 8) + (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile > > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s > include/linux/version.h include/linux/version.h.tmp; then rm -f > include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp > include/linux/version.h; fi' > make: *** [include/linux/version.h] Error 2 > > > # scripts/ver_linux > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > > Linux filesrv2 2.6.23-rc9 #1 SMP Wed Oct 3 02:12:33 UTC 2007 i686 pentium4 > i386 GNU/Linux > > Gnu C 3.4.6 > Gnu make 3.81 > binutils 2.15.92.0.2 > util-linux 2.12r > mount 2.12r > module-init-tools 3.2.2 > e2fsprogs 1.38 > jfsutils 1.1.11 > reiserfsprogs 3.6.19 > xfsprogs 2.8.10 > pcmciautils014 > pcmcia-cs 3.2.8 > quota-tools3.13. > PPP2.4.4 > Linux C Library2.3.6 > Dynamic linker (ldd) 2.3.6 > Linux C++ Library 6.0.3 > Procps 3.2.7 > Net-tools 1.60 > Kbd1.12 > oprofile 0.9.1 > Sh-utils 5.97 > udev 097 > Modules Loaded > > -- Please send your .config as well so someone can try to reproduce this. And have you done a make mrproper first before trying to compile? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Netfilter fixes to 2.6.24-git
David Miller wrote: From: Jan Engelhardt <[EMAIL PROTECTED]> Date: Sun, 10 Feb 2008 22:02:35 +0100 (CET) I have been unable to reach the netfilter and net maintainers the past week regarding inclusion of patches, but most importantly a group of fixes at [0]-[3]. I am kind of at a loss here but to turn up the volume and write to more people on how to proceed. You just need to be patient and wait for Patrick to get to your patches, it's as simple as that :-) Patrick is normally very responsive, so whatever it is it has to be a temporary issue. Indeed, I'm currently ill and not really up for much working, but this will hopefully get better soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kvm: no hardware support
I enable vmx and svm option for KVM in .config
on amd SVM enable system
vmx get tried at first
and get
kvm: no hardware support
Calling initcall 0x80c2d465: vmx_init+0x0/0x119()
kvm: no hardware support
initcall 0x80c2d465: vmx_init+0x0/0x119() returned -95.
initcall 0x80c2d465 ran for 2 msecs: vmx_init+0x0/0x119()
initcall at 0x80c2d465: vmx_init+0x0/0x119(): returned with
error code -95
Calling initcall 0x80c2d57e: svm_init+0x0/0x13()
initcall 0x80c2d57e: svm_init+0x0/0x13() returned 0.
initcall 0x80c2d57e ran for 0 msecs: svm_init+0x0/0x13()
suggest you add .name in ops like "vmx" or "svm"
and that message can become
kvm: no hardware support for vmx
or
kvm: no hardware support for svm
or just remove that line.
}
if (!ops->cpu_has_kvm_support()) {
-printk(KERN_ERR "kvm: no hardware support\n");
r = -EOPNOTSUPP;
goto out;
}
YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.16
diff --git a/Makefile b/Makefile index 8920cb8..3a932c7 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 23 -EXTRAVERSION = .15 +EXTRAVERSION = .16 NAME = Arr Matey! A Hairy Bilge Rat! # *DOCUMENTATION* diff --git a/fs/splice.c b/fs/splice.c index 2aa8f5a..1a9c0e6 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -1289,7 +1289,7 @@ static int get_iovec_page_array(const struct iovec __user *iov, if (unlikely(!len)) break; error = -EFAULT; - if (unlikely(!base)) + if (!access_ok(VERIFY_READ, base, len)) break; /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.23.16
We (the -stable team) are announcing the release of the 2.6.23.16 kernel. It fixes one thing, CVE-2008-0600. All users of the 2.6.23 series, with untrusted local users are strongly encouraged to upgrade. I'll also be replying to this message with a copy of the patch between 2.6.23.15 and 2.6.23.16 The updated 2.6.23.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=summary thanks, greg k-h Makefile|2 +- fs/splice.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Summary of changes from v2.6.23.15 to v2.6.23.16 Bastian Blank (1): splice: fix user pointer access in get_iovec_page_array() Greg Kroah-Hartman (1): Linux 2.6.23.16 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.24.2
diff --git a/Makefile b/Makefile index e6a6eec..6f79564 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 24 -EXTRAVERSION = .1 +EXTRAVERSION = .2 NAME = Err Metey! A Heury Beelge-a Ret! # *DOCUMENTATION* diff --git a/fs/splice.c b/fs/splice.c index 36fdc61..e313478 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -1239,7 +1239,7 @@ static int get_iovec_page_array(const struct iovec __user *iov, if (unlikely(!len)) break; error = -EFAULT; - if (unlikely(!base)) + if (!access_ok(VERIFY_READ, base, len)) break; /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.6.24.2
We (the -stable team) are announcing the release of the 2.6.24.2 kernel. It fixes one thing, CVE-2008-0600. All users of the 2.6.24 series, with untrusted local users are strongly encouraged to upgrade. I'll also be replying to this message with a copy of the patch between 2.6.24.1 and 2.6.24.2 The updated 2.6.24.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.24.y.git and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.24.y.git;a=summary thanks, greg k-h Makefile|2 +- fs/splice.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Summary of changes from v2.6.24.1 to v2.6.24.2 == Bastian Blank (1): splice: fix user pointer access in get_iovec_page_array() Greg Kroah-Hartman (1): Linux 2.6.24.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] splice: fix user pointer access in get_iovec_page_array()
Linux pancs 2.6.22.17-opt2-cve2 #1 SMP Sun Feb 10 16:22:37 CET 2008
i686 GNU/Linux
---
Linux vmsplice Local Root Exploit
By qaaz
---
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7f95000 .. 0xb7fc7000
[-] vmsplice: Bad address
---
Linux vmsplice Local Root Exploit
By qaaz
---
[+] addr: 0xc01112e9
[-] wtf
the patch is good for 2.6.22.y
On 2/11/08, Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 10, 2008 at 04:47:57PM +0200, Pekka J Enberg wrote:
> > From: Bastian Blank <[EMAIL PROTECTED]>
> >
> > The commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user
> > pointer access verification") added access_ok() to
> copy_from_user_mmap_sem()
> > which only ensures we can copy the struct iovecs from userspace to the
> kernel
> > but we also must check whether we can access the actual memory region
> pointed
> > to by the struct iovec to close the local root exploit.
> >
> > Cc: <[EMAIL PROTECTED]>
> > Cc: Jens Axboe <[EMAIL PROTECTED]>
> > Cc: Andrew Morton <[EMAIL PROTECTED]>
> > Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
> > ---
> > Bastian, can I have your Signed-off-by for this, please? Oliver, Niki, can
> > you please confirm this closes the hole?
>
> Pekka, I confirm that it also closes the hole once backported to 2.6.22.
>
> Willy
>
>
--
Thanks,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1: Lguest build failure
Hi Rusty Just got this build failure while building -rc1 - Root device is (254, 0) Setup is 12216 bytes (padded to 12288 bytes). System is 1915 kB Kernel: arch/x86/boot/bzImage is ready (#3) Building modules, stage 2. MODPOST 683 modules ERROR: "LGUEST_PAGES_guest_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_gdt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_cr3" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_idt_desc" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_gdt" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_host_sp" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_regs_trapnum" [drivers/lguest/lg.ko] undefined! ERROR: "LGUEST_PAGES_guest_idt_desc" [drivers/lguest/lg.ko] undefined! WARNING: modpost: Found 4 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 .config below - # # Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc1 # Mon Feb 11 01:07:43 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_TASK_XACCT is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_KPROBES=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set #
Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)
Arjan van de Ven wrote: > On Mon, 11 Feb 2008 03:25:33 -0200 > "Carlos R. Mafra" <[EMAIL PROTECTED]> wrote: > >> The problem with suspend to RAM is that right after typing (from >> inside X) 'echo mem > /sys/power/state' the screen becomes black and >> the laptop freezes. I have to use SysRq+b to reboot. >> >> I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but >> the compilation fails. It turns out that I have to revert also >> 9a0b8415 and 9b12e18c to be able to compile without errors. >> >> After reverting the 3 commits mentioned above, the resulting >> 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is >> better that 2.6.24, because now it resumes directly into X and I >> don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to >> do before). >> >> The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in >> 64-bit mode, with the following graphics card: >> VGA compatible controller: Intel Corporation Mobile GM965/GL960 >> Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) >> >> If there is anything else I can do to help please let me know. > > > this may be a BIOS bug; I'll let Venki dig into this ... but can you send the > output of > the dmidecode program to the list? If we need to start blacklisting bioses > that information > is going to be needed ;( I am sending the dmidecode output attached (I erased the UUID). Thanks for the prompt answer! # dmidecode 2.9 SMBIOS 2.4 present. 17 structures occupying 710 bytes. Table at 0x000DC010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Phoenix Technologies LTD Version: R1120J7 Release Date: 07/04/2007 Address: 0xE6C60 Runtime Size: 103328 bytes ROM Size: 1024 kB Characteristics: PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 8042 keyboard services are supported (int 9h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported AGP is supported Smart battery is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 12.0 Firmware Revision: 12.0 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Sony Corporation Product Name: VGN-FZ240E Version: C60034YU Serial Number: 28209434-3041267 UUID: ----x Wake-up Type: Power Switch SKU Number: N/A Family: N/A Handle 0x0002, DMI type 2, 10 bytes Base Board Information Manufacturer: Sony Corporation Product Name: VAIO Version: N/A Serial Number: N/A Handle 0x0003, DMI type 3, 17 bytes Chassis Information Manufacturer: Sony Corporation Type: Notebook Lock: Not Present Version: N/A Serial Number: N/A Asset Tag: N/A Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: N/A Type: Central Processor Family: Other Manufacturer: GenuineIntel ID: FD 06 00 00 FF FB EB BF Version: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz Voltage: 1.2 V External Clock: 200 MHz Max Speed: 2000 MHz Current Speed: 2000 MHz Status: Populated, Enabled Upgrade: None L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: 0x0007 Serial Number: N/A Asset Tag: N/A Part Number: N/A Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1 Cache Configuration: Enabled, Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 64 KB Maximum Size: 64 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Other Speed: Unknown Error Correction Type: Single-bit ECC System Type: Data Associativity: 8-way Set-associative Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2 Cache Configuration: Enabled, Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 2048 KB Maximum Size: 2048 KB Supported SRAM Types: Burst
Re: [PATCH] Change pci_raw_ops to pci_raw_read/write
On Feb 10, 2008 6:53 PM, Robert Hancock <[EMAIL PROTECTED]> wrote: > > Yinghai Lu wrote: > > On Feb 10, 2008 12:45 PM, Matthew Wilcox <[EMAIL PROTECTED]> wrote: .. > >> I've attached the two patches that I believe are the ones we want. We > >> can (and should) fix quirk_intel_irqbalance separately. > > > > Andrew, > > > > those two patch just got into linus 2.6.25-rc1. > > > > I assume that you will drop > > gregkh-pci-pci-make-pci-extended-config-space-a-driver-opt-in.patch in > > -mm. > > > > please check some updated patches in -mm that could be affected. hope > > it could save you some time > > > > x86-validate-against-acpi-motherboard-resources.patch > > x86-clear-pci_mmcfg_virt-when-mmcfg-get-rejected.patch > > x86-mmconf-enable-mcfg-early.patch > > x86_64-check-msr-to-get-mmconfig-for-amd-family-10h-opteron-v3.patch > > I don't think any of these patches are affected. They all affect whether > to use MMCONFIG globally or not, regardless of whether not particular > accesses will use it. what i mean: gregkh-pci-pci-make-pci-extended-config-space-a-driver-opt-in.patch is not needed. and > > x86-validate-against-acpi-motherboard-resources.patch > > x86-clear-pci_mmcfg_virt-when-mmcfg-get-rejected.patch > > x86-mmconf-enable-mcfg-early.patch > > x86_64-check-msr-to-get-mmconfig-for-amd-family-10h-opteron-v3.patch need some update because of changes by "Change pci_raw_ops to pci_raw_read/write" patch. such as pci_conf1_read became static...unreachable_devices() is gone.. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xfs: convert beX_add to beX_add_cpu (new common API)
On Sun, Feb 10, 2008 at 11:18:09AM +0100, Marcin Slusarz wrote: > This patch was in Andrew tree, but it was uncomplete. > Here is updated version. > > --- > remove beX_add functions and replace all uses with beX_add_cpu > > Signed-off-by: Marcin Slusarz <[EMAIL PROTECTED]> > --- Looks good. You can add a: Reviewed-by: Dave Chinner <[EMAIL PROTECTED]> To the patch. Andrew - feel free to push this to Linus with the other 2 patches in this series when you are ready. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, 2008-02-11 at 03:25 -0200, Carlos R. Mafra wrote: > Hi, > > I want to report that suspend to RAM stopped working on my Sony Vaio > VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down > to: > > commit bc71bec91f9875ef825d12104acf3bf4ca215fa4 > Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Date: Thu Jan 31 17:35:04 2008 -0800 > > ACPI: enable MWAIT for C1 idle I normally hate to throw in a 'me-too', but I'm also seeing a suspend-to-ram regression on my Thinkpad R61i that I've managed to bisect down to the same patch series. You beat me emailing the issue to the list by a few minutes :) > The problem with suspend to RAM is that right after typing (from inside X) > 'echo mem > /sys/power/state' the screen becomes black and the laptop > freezes. I have to use SysRq+b to reboot. My symptoms in this case are slightly different - the suspend appears to work correctly, and is fast. However, when I resume, the screen lights up quickly, but the system hangs for nearly a minute with the suspend light still on solid before it actually resumes. No delay is visible in dmesg; this apparently happens before the "return to C". > I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but > the compilation fails. It turns out that I have to revert also 9a0b8415 and > 9b12e18c to be able to compile without errors. > > After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel > can suspend to RAM again (and I must say that it is better that 2.6.24, > because > now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 > to > go back to X as I used to do before). I just tried reverting the above-mentioned 3 commits, doing so fixes the delay. > The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit > mode, with the > following graphics card: > VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated > Graphics Controller (rev 0c) (prog-if 00 [VGA]) Rather similar system - I have a core 2 duo 1.5 running x86_64 gentoo, and a GM965 chip (using uvesafb) > > If there is anything else I can do to help please let me know. > > Carlos R. Mafra -- Calvin Walton <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops report for the week upto Feb 10th 2008
Alexey Dobriyan wrote: On Sun, Feb 10, 2008 at 04:35:51PM -0800, Arjan van de Ven wrote: Rank 3: remove_proc_entry WARN_ON at fs/proc/generic.c:736 Reported 20 times (38 total reports) This WARN_ON is there if code tries to remove a non-empty /proc directory. Most reports are tainted, pointing at a bug in a binary module. Without the WARN_ON improvements from 2.6.25-rc1 it'll be hard to figure out which module is guilty. Easy, I'll submit patch RSN. to fix it or to print modules? (the later is already done in 2.6.25-rc1, just not in 2.6.24 yet) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25-rc1 regression] Suspend to RAM (bisected)
On Mon, 11 Feb 2008 03:25:33 -0200 "Carlos R. Mafra" <[EMAIL PROTECTED]> wrote: > The problem with suspend to RAM is that right after typing (from > inside X) 'echo mem > /sys/power/state' the screen becomes black and > the laptop freezes. I have to use SysRq+b to reboot. > > I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but > the compilation fails. It turns out that I have to revert also > 9a0b8415 and 9b12e18c to be able to compile without errors. > > After reverting the 3 commits mentioned above, the resulting > 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is > better that 2.6.24, because now it resumes directly into X and I > don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to > do before). > > The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in > 64-bit mode, with the following graphics card: > VGA compatible controller: Intel Corporation Mobile GM965/GL960 > Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) > > If there is anything else I can do to help please let me know. this may be a BIOS bug; I'll let Venki dig into this ... but can you send the output of the dmidecode program to the list? If we need to start blacklisting bioses that information is going to be needed ;( -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops report for the week upto Feb 10th 2008
On Sun, Feb 10, 2008 at 04:35:51PM -0800, Arjan van de Ven wrote: > Rank 3: remove_proc_entry > WARN_ON at fs/proc/generic.c:736 > Reported 20 times (38 total reports) > This WARN_ON is there if code tries to remove a non-empty /proc > directory. > Most reports are tainted, pointing at a bug in a binary module. > Without the WARN_ON improvements from 2.6.25-rc1 it'll be hard to > figure out which module is guilty. Easy, I'll submit patch RSN. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Netfilter fixes to 2.6.24-git
From: Jan Engelhardt <[EMAIL PROTECTED]> Date: Sun, 10 Feb 2008 22:02:35 +0100 (CET) > I have been unable to reach the netfilter and net maintainers the past > week regarding inclusion of patches, but most importantly a group of > fixes at [0]-[3]. I am kind of at a loss here but to turn up the volume > and write to more people on how to proceed. You just need to be patient and wait for Patrick to get to your patches, it's as simple as that :-) Patrick is normally very responsive, so whatever it is it has to be a temporary issue. Because of LCA08 etc. I myself wasn't even able to get any networking bug fix submissions into 2.6.24.1 Big deal, we'll just get it into the next 2.6.24.x release. Thanks for your patience. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops report for the week upto Feb 10th 2008
On Monday 11 February 2008 11:35, Arjan van de Ven wrote: > The http://www.kerneloops.org website collects kernel oops and > warning reports from various mailing lists and bugzillas as well as > with a client users can install to auto-submit oopses. > Below is a top 10 list of the oopses/backtraces collected in the last 7 > days. (Reports prior to 2.6.23 have been omitted in collecting the top 10) > > This week, a total of 323 oopses and warnings have been reported, > compared to 110 reports in the previous week. > > (This sharp increase is due to Fedora 9 alpha shipping the oops data > collection client in the default install, giving us much wider coverage > in the issues that actual users hit; many thanks to the Fedora project > for this) > > With the 2.6.25-rc1 release out, this will be the last report that includes > 2.6.23; future reports will only include issues from 2.6.24 and later. > > > Rank 1: set_dentry_child_flags > WARN_ON at fs/inotify.c:172 set_dentry_child_flags > Reported 93 times (116 total reports) > This is a user triggered WARN_ON in inotify. Sadly inotify seems to be > unmaintained. More info: > http://www.kerneloops.org/search.php?search=set_dentry_child_flags I was never able to trigger this or get anyone to reliably trigger it with a debug patch in. Which is why it has taken so long to fix. It looks like kde4 is triggering this big rash of new reports. Anyway, I have fixed a race or two and removed that warning code (which was also a little racy). So I think that should be OK. > Rank 9: mark_buffer_dirty > WARN_ON at fs/buffer.c:1169 > This indicates that a non-uptodate buffer is marked dirty. > This can lead to data corruption! > Reported 5 times (12 total reports) - Only seen since 2.6.24-rc6 > Usually happens during umount() > More info: http://www.kerneloops.org/search.php?search=mark_buffer_dirty That's interesting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: m68knommu compile error
Martin Schwidefsky wrote: On Sat, 2008-02-09 at 11:21 +0100, Martin Schwidefsky wrote: On Sat, 2008-02-09 at 00:25 +0200, Adrian Bunk wrote: Commit 2f569afd9ced9ebec9a6eb3dbf6f83429be0a7b4 breaks m68knommu: Does the patch below fixes the problem? I tried to cross compile for m68knommu but it seems like you need a special m68k compiler to get it compile all the way through. With the patch it did fail with a different error, so I assume it is fixed. The problem is that the pgtable_t is simply missing for m68knommu, I must have overlooked a reject for one of the constant regenerations of the patch to keep up with upstream. Sorry about that. This is a problem for all nommu architectures. The patch fixed all four of them. Confirmed, good for m68knommu. Acked-by: Greg Ungerer <[EMAIL PROTECTED]> -- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IO queuing and complete affinity with threads (was Re: [PATCH 0/8] IO queuing and complete affinity)
On Fri, Feb 08, 2008 at 08:59:55AM +0100, Jens Axboe wrote: > > > > At least they reported it to be the most efficient scheme in their > > > > testing, and Dave thought that migrating completions out to submitters > > > > might be a bottleneck in some cases. > > > > > > More so than migrating submitters to completers? The advantage of only > > > movign submitters is that you get rid of the completion locking. Apart > > > from that, the cost should be the same, especially for the thread based > > > solution. > > > > Not specifically for the block layer, but higher layers like xfs. > > True, but that's parallel to the initial statement - that migrating > completers is most costly than migrating submitters. So I'd like Dave to > expand on why he thinks that migrating completers it more costly than > submitters, APART from the locking associated with adding the request to > a remote CPU list. What I think Nick is referring to is the comments I made that at a higher layer (e.g. filesystems) migrating completions to the submitter CPU may be exactly the wrong thing to do. I don't recall making any comments on migrating submitters - I think others have already commented on that so I'll ignore that for the moment and try to explain why completion on submitter CPU /may/ be bad. For example, in the case of XFS it is fine for data I/O but it is wrong for transaction I/O completion. We want to direct all transaction completions to as few CPUs as possible (one, ideally) so that all the completion processing happens on the same CPU, rather than bouncing global cachelines and locks between all the CPUs taking completion interrupts. In more detail, the XFS transaction subsystem is asynchronous. We submit the transaction I/O on the CPU that creates the transaction so the I/O can come from any CPU in the system. If we then farm the completion processing out to the submission CPU, that will push it all over the machine and guarantee that we bounce all of the XFS transaction log structures and locks all over the machine on completion as well as submission (right now it's lots of submission CPUs, few completion CPUs). An example how bad this can get - this patch: http://oss.sgi.com/archives/xfs/2007-11/msg00217.html which prevents simultaneous access to the items tracked in the log during transaction reservation. Having several hundred CPUs trying to hit this list at once is really bad for performance - the test app on the 2048p machine that saw this problem went from ~5500s runtime down to 9s with the above patch. I use this example because the transaction I/O completion touches exactly the same list, locks and structures but is limited in distribution (and therefore contention) by the number of simultaneous I/O completion CPUs. Doing completion on the submitter CPU will cause much wider distribution of completion processing and introduce exactly the same issues as the transaction reservation side had. As it goes, with large, multi-device volumes (e.g. big stripe) we already see issues with simultaneous completion processing (e.g. the 8p machine mentioned in the above link), so I'd really like to avoid making these problems worse Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.25-rc1 regression] Suspend to RAM (bisected)
Hi, I want to report that suspend to RAM stopped working on my Sony Vaio VGN-FZ240E in 2.6.25-rc1 and that I could bisect the problem down to: commit bc71bec91f9875ef825d12104acf3bf4ca215fa4 Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Thu Jan 31 17:35:04 2008 -0800 ACPI: enable MWAIT for C1 idle Add MWAIT idle for C1 state instead of halt, on platforms that support C1 state with MWAIT. Renames cx->space_id to something more appropriate. Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> Signed-off-by: Len Brown <[EMAIL PROTECTED]> The problem with suspend to RAM is that right after typing (from inside X) 'echo mem > /sys/power/state' the screen becomes black and the laptop freezes. I have to use SysRq+b to reboot. I tried to revert the above commit (bc71bec) on top of 2.6.25-rc1, but the compilation fails. It turns out that I have to revert also 9a0b8415 and 9b12e18c to be able to compile without errors. After reverting the 3 commits mentioned above, the resulting 2.6.25-rc1 kernel can suspend to RAM again (and I must say that it is better that 2.6.24, because now it resumes directly into X and I don't need to use Crtl-Alt-F1 and Alt-F7 to go back to X as I used to do before). The laptop is a Core 2 Duo T7250 2.0 GHz, running Mandriva 2008.0 in 64-bit mode, with the following graphics card: VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) If there is anything else I can do to help please let me know. Carlos R. Mafra -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi: ses fix mem leaking when fail to add intf
On Sunday 10 February 2008 08:28:38 pm James Bottomley wrote: > > On Sat, 2008-02-09 at 15:15 -0800, Yinghai Lu wrote: > > [PATCH] scsi: ses fix mem leaking when fail to add intf > > > > fix leaking with scomp leaking when failing. > > also remove one extra space. > > There are still a few extraneous code moves in this one. This is about > the correct minimal set, isn't it? if buf allocation for page 7 get NULL... if put + if (!buf) + goto err_free; still not right, because still undo edev = enclosure_register(cdev->dev, sdev->sdev_gendev.bus_id, components, _enclosure_callbacks); all just add + if (!buf) + goto simple_populate; there? YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: raw_pci_read in quirk_intel_irqbalance
On Sun, Feb 10, 2008 at 04:02:04PM -0700, Matthew Wilcox wrote:
> The line in question reads:
>
> /* read xTPR register */
> raw_pci_read(0, 0, 0x40, 0x4c, 2, );
>
> That's domain 0, bus 0, device 8, function 0, address 0x4c, length 2.
>
> I've checked the public E7525 and E7520 MCH datasheets, and they don't
> document the xTPR registers; nor do any of the devices in the datasheet
> have registers documented at 0x4c.
>
> You can see from my lspci above that I don't _have_ a device 8 on bus 0.
> The aforementioned documentation says:
>
> "A disabled or non-existent device's configuration register space is
> hidden. A disabled or non-existent device will return all ones for reads
> and will drop writes just as if the cycle terminated with a Master Abort
> on PCI."
I'd like to thank Grant for pointing out to me that this is exactly what
the write immediately above this is doing -- enabling device 8 to
respond to config space cycles.
> Now, my E7525 isn't affected by this quirk as it has a revision greater
> than 0x9. So maybe it's expected that device 8 is hidden on my machine;
> that it's only present on revisions up to 0x9. But maybe device 8 is
> always hidden, and that's why the author used raw_pci_ops?
>
> We can still do better than this, though. We can do:
>
> - raw_pci_read(0, 0, 0x40, 0x4c, 2, );
> + pci_bus_read_config_word(dev->bus, PCI_DEVFN(8, 0), 0x4c, );
>
> Using PCI_DEVFN tells people you really did mean device 8, and it's not
> a braino for device 4 or 2 (how many bits for slot and function again?)
Here's the patch to implement the above two suggestions:
>From f565b65591a3f90a272b1d511e4ab1728861fe77 Mon Sep 17 00:00:00 2001
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Sun, 10 Feb 2008 23:18:15 -0500
Subject: [PATCH] Use proper abstractions in quirk_intel_irqbalance
Since we may not have a pci_dev for the device we need to access, we can't
use pci_read_config_word. But raw_pci_read is an internal implementation
detail; it's better to use the architected pci_bus_read_config_word
interface. Using PCI_DEVFN instead of a mysterious constant helps
reassure everyone that we really do intend to access device 8.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
arch/x86/kernel/quirks.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index 1941482..c47208f 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -11,7 +11,7 @@
static void __devinit quirk_intel_irqbalance(struct pci_dev *dev)
{
u8 config, rev;
- u32 word;
+ u16 word;
/* BIOS may enable hardware IRQ balancing for
* E7520/E7320/E7525(revision ID 0x9 and below)
@@ -26,8 +26,11 @@ static void __devinit quirk_intel_irqbalance(struct pci_dev
*dev)
pci_read_config_byte(dev, 0xf4, );
pci_write_config_byte(dev, 0xf4, config|0x2);
- /* read xTPR register */
- raw_pci_read(0, 0, 0x40, 0x4c, 2, );
+ /*
+* read xTPR register. We may not have a pci_dev for device 8
+* because it might be hidden until the above write.
+*/
+ pci_bus_read_config_word(dev->bus, PCI_DEVFN(8, 0), 0x4c, );
if (!(word & (1 << 13))) {
dev_info(>dev, "Intel E7520/7320/7525 detected; "
--
1.5.2.5
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi: ses fix mem leaking when fail to add intf
On Sat, 2008-02-09 at 15:15 -0800, Yinghai Lu wrote:
> [PATCH] scsi: ses fix mem leaking when fail to add intf
>
> fix leaking with scomp leaking when failing.
> also remove one extra space.
There are still a few extraneous code moves in this one. This is about
the correct minimal set, isn't it?
James
---
From: Yinghai Lu <[EMAIL PROTECTED]>
Date: Sat, 9 Feb 2008 15:15:47 -0800
Subject: [SCSI] ses: fix memory leaks
fix leaking with scomp leaking when failing. Also free page10 on
driver removal and remove one extra space.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/ses.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index 2a6e4f4..8abc4a9 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -416,11 +416,11 @@ static int ses_intf_add(struct class_device *cdev,
int i, j, types, len, components = 0;
int err = -ENOMEM;
struct enclosure_device *edev;
- struct ses_component *scomp;
+ struct ses_component *scomp = NULL;
if (!scsi_device_enclosure(sdev)) {
/* not an enclosure, but might be in one */
- edev = enclosure_find(>host->shost_gendev);
+ edev = enclosure_find(>host->shost_gendev);
if (edev) {
ses_match_to_enclosure(edev, sdev);
class_device_put(>cdev);
@@ -456,9 +456,6 @@ static int ses_intf_add(struct class_device *cdev,
if (!buf)
goto err_free;
- ses_dev->page1 = buf;
- ses_dev->page1_len = len;
-
result = ses_recv_diag(sdev, 1, buf, len);
if (result)
goto recv_failed;
@@ -473,6 +470,9 @@ static int ses_intf_add(struct class_device *cdev,
type_ptr[0] == ENCLOSURE_COMPONENT_ARRAY_DEVICE)
components += type_ptr[1];
}
+ ses_dev->page1 = buf;
+ ses_dev->page1_len = len;
+ buf = NULL;
result = ses_recv_diag(sdev, 2, hdr_buf, INIT_ALLOC_SIZE);
if (result)
@@ -489,6 +489,7 @@ static int ses_intf_add(struct class_device *cdev,
goto recv_failed;
ses_dev->page2 = buf;
ses_dev->page2_len = len;
+ buf = NULL;
/* The additional information page --- allows us
* to match up the devices */
@@ -506,11 +507,12 @@ static int ses_intf_add(struct class_device *cdev,
goto recv_failed;
ses_dev->page10 = buf;
ses_dev->page10_len = len;
+ buf = NULL;
no_page10:
- scomp = kmalloc(sizeof(struct ses_component) * components, GFP_KERNEL);
+ scomp = kzalloc(sizeof(struct ses_component) * components, GFP_KERNEL);
if (!scomp)
- goto err_free;
+ goto err_free;
edev = enclosure_register(cdev->dev, sdev->sdev_gendev.bus_id,
components, _enclosure_callbacks);
@@ -521,7 +523,7 @@ static int ses_intf_add(struct class_device *cdev,
edev->scratch = ses_dev;
for (i = 0; i < components; i++)
- edev->component[i].scratch = scomp++;
+ edev->component[i].scratch = scomp + i;
/* Page 7 for the descriptors is optional */
buf = NULL;
@@ -598,6 +600,7 @@ static int ses_intf_add(struct class_device *cdev,
err = -ENODEV;
err_free:
kfree(buf);
+ kfree(scomp);
kfree(ses_dev->page10);
kfree(ses_dev->page2);
kfree(ses_dev->page1);
@@ -630,6 +633,7 @@ static void ses_intf_remove(struct class_device *cdev,
ses_dev = edev->scratch;
edev->scratch = NULL;
+ kfree(ses_dev->page10);
kfree(ses_dev->page1);
kfree(ses_dev->page2);
kfree(ses_dev);
--
1.5.3.8
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] cpufreq: change cpu freq tables to per_cpu variables
On Fri, Feb 08, 2008 at 03:37:39PM -0800, Mike Travis wrote: > Change cpu frequency tables from arrays to per_cpu variables. > > Based on linux-2.6.git + x86.git Looks ok to me. Would you like me to push this though cpufreq.git, or do you want the series to go through all in one? Dave -- http://www.codemonkey.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops with hostap_pci (?)
Hi, A few days back I started having strange lockups on a gateway machine so I started looking at things. Then I compiled the 2.6.24.1 kernel and started having oopses not long after upping the wlan0 (hostap_pci) interface. So I enabled netconsole and got a few logs. Now the sad point is that I'm getting an oops even with my older kernel which used to be fine (2.6.23.9). I also checked with 2.6.24 and the effects are the same: I boot, I up the wlan0 interface and a few seconds or minutes later, boom! Sometimes only rmmod'ing hostap_pci triggers the oops. I'm suspecting some hardware problem and have already checked the ram with memtest86+ and tested with only one memory module out of two plugged: same thing. If anybody could take a look at these and shed some light on that issue... Thanks a lot, Ignacy -- Save the whales. Feed the hungry. Free the mallocs. With kernel 2.6.24.1 BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: f08f50c2 *pde = Oops: [#1] Modules linked in: lirc_serial(F) lirc_dev cls_fw sch_prio sch_htb iptable_nat xt_limit xt_state ipt_REJECT xt_tcpudp ipt_LOG xt_DSCP xt_dscp xt_mark nf_conntrack_ipv4 xt_CONNMARK xt_MARK iptable_mangle iptable_filter ip_tables x_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack ipv6 evdev hostap_pci i2c_viapro hostap via686a ieee80211_crypt ide_cd Pid: 0, comm: swapper Tainted: GF (2.6.24.1 #5) EIP: 0060:[] EFLAGS: 00010297 CPU: 0 EIP is at hostap_80211_rx+0x41d/0xecf [hostap] EAX: eec28460 EBX: ECX: eec28444 EDX: ESI: efbb8434 EDI: EBP: efbb843e ESP: c0419e74 DS: 007b ES: 007b FS: GS: SS: 0068 Process swapper (pid: 0, ti=c0418000 task=c03e4300 task.ti=c0418000) Stack: 0080 004c 0001 c0419f2c c0419f30 ef3ab760 0018 0100 eec28444 1148 0040 c9c0 0001 ef8d3370 2a40 04b1cd93 000a1e00 1148 013a1148 685b0900 ef8d3000 1f714b23 685b0900 Call Trace: [] hostap_rx_tasklet+0x11f/0x145 [hostap_pci] [] run_timer_softirq+0x11/0x12f [] tasklet_action+0x32/0x52 [] __do_softirq+0x35/0x75 [] do_softirq+0x22/0x26 [] irq_exit+0x29/0x58 [] do_IRQ+0x58/0x6b [] common_interrupt+0x23/0x28 [] mod_sysfs_init+0x17/0x6d [] arch_setup_additional_pages+0x121/0x13a [] acpi_processor_idle+0x244/0x3c4 [] cpu_idle+0x43/0x5d [] start_kernel+0x237/0x23c [] unknown_bootoption+0x0/0x195 === Code: 0a 8b 4c 24 24 8b 59 1c eb 21 83 bb d8 00 00 00 04 75 16 8d 83 dc 00 00 00 b9 06 00 00 00 89 ea e8 0b d1 91 cf 85 c0 74 18 89 fb <8b> 3b 0f 18 07 90 8b 44 24 24 83 c0 1c 39 c3 75 ce e9 44 0a 00 EIP: [] hostap_80211_rx+0x41d/0xecf [hostap] SS:ESP 0068:c0419e74 Kernel panic - not syncing: Fatal exception in interrupt wlan0ap: SW TICK stuck? bits=0x0 EvStat=8001 IntEn=e018 With kernel 2.6.24.1 BUG: unable to handle kernel paging request at virtual address abdb24ce printing eip: f08ea0c2 *pde = Oops: [#1] Modules linked in: cls_fw sch_prio sch_htb iptable_nat xt_limit xt_state ipt_REJECT xt_tcpudp ipt_LOG xt_DSCP xt_dscp xt_mark nf_conntrack_ipv4 xt_CONNMARK xt_MARK iptable_mangle iptable_filter ip_tables x_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack ipv6 evdev hostap_pci i2c_viapro via686a hostap ieee80211_crypt ide_cd Pid: 0, comm: swapper Not tainted (2.6.24.1 #5) EIP: 0060:[] EFLAGS: 00010202 CPU: 0 EIP is at hostap_80211_rx+0x41d/0xecf [hostap] EAX: efa68460 EBX: abdb24ce ECX: efa68444 EDX: ESI: ef1e1034 EDI: abdb24ce EBP: ef1e103e ESP: c0419e74 DS: 007b ES: 007b FS: GS: SS: 0068 Process swapper (pid: 0, ti=c0418000 task=c03e4300 task.ti=c0418000) Stack: 0080 c045358c 0001 c0453570 c0419f30 eec598e0 0018 0100 efa68444 1148 0040 1f90 0001 eec29370 5a40 0080ce43 000a1e00 1148 013a1148 685b0900 eec29000 1f714b23 685b0900 Call Trace: [] hostap_rx_tasklet+0x11f/0x145 [hostap_pci] [] tasklet_action+0x32/0x52 [] __do_softirq+0x35/0x75 [] do_softirq+0x22/0x26 [] irq_exit+0x29/0x58 [] do_IRQ+0x58/0x6b [] common_interrupt+0x23/0x28 [] mod_sysfs_init+0x17/0x6d [] arch_setup_additional_pages+0x121/0x13a [] acpi_processor_idle+0x244/0x3c4 [] cpu_idle+0x43/0x5d [] start_kernel+0x237/0x23c [] unknown_bootoption+0x0/0x195 === Code: 0a 8b 4c 24 24 8b 59 1c eb 21 83 bb d8 00 00 00 04 75 16 8d 83 dc 00 00 00 b9 06 00 00 00 89 ea e8 0b 81 92 cf 85 c0 74 18 89 fb <8b> 3b 0f 18 07 90 8b 44 24 24 83 c0 1c 39 c3 75 ce e9 44 0a 00 EIP: [] hostap_80211_rx+0x41d/0xecf [hostap] SS:ESP 0068:c0419e74 Kernel panic - not syncing: Fatal exception in interrupt wlan0ap: SW TICK stuck? bits=0x0 EvStat=8001 IntEn=e018 With kernel 2.6.24 BUG: unable to handle kernel paging request at virtual address 630e0021 printing eip: f08f20c2 *pde = Oops: [#1] Modules linked in: cls_fw sch_prio sch_htb iptable_nat xt_limit xt_state ipt_REJECT
Re: Linux 2.6.25-rc1
On Sunday 10 February 2008, Linus Torvalds wrote: >Ok, it's a bloody large -rc (as was 24-rc1, for that matter), probably >because the 2.6.24 release cycle dragged out, so people had a lot of >things pending. > >The full diff is something like 11MB and 1.4M lines of diffs, with the >bulk of the stuff being in architecture updates and drivers. > >Just to have some fun, I did trivial statistics, and of the 1.4M lines of >diffs, about 38% - 530k lines - were in architecture files (400k+ lines of >diffs in arch/, 100k+ lines of diffs in include/asm-*), and another big >chunk is in drivers (including sound) at about 44% - 610k lines - of >changes. > >The rest comes in much smaller, but still noticeable is networking (8% - >110k lines), with filesystems at 4%, and documentation at about 2%. The >remaining crumbles being spread out mostly over block layer, crypto, >kernel core, and security layer updates (ie SElinux and smack). > >[ Just to make it more obvious how driver and architecture-dominated the > kernel changelogs are: just the network driver changes were 200kloc, and > even just infiniband - which came way behind not just networking > drivers, but also DVB, SCSI, char and ide - generated more lines of code > changed than the "core" kernel code under the kernel/ subdirectory. > > And that's despite the fact that the "core" code was actually under a > fairly active merge cycle, with a lot of namespace- and scheduling- > related stuff. ] > >Now, some of that is files moving about and other reorganizations (SH and >to a lesser degree sparc starting to merge 32-bit and 64-bit >architectures), but most of it really is just the normal flood of changes >and new driver or platform support. > >The full shortlog is half a meg in size (and the diffstat is even bigger), >so I won't be including that here, but some things that may be worth >pointing out not because they are big in line sizes, but because they have >potential to be noticed by more people: > > - the intel graphics driver is starting to do suspend/resume natively > (ie even without X support), which is a welcome sign of the times and > may help some people. It helped on my laptop. > > - Other suspend/resume changes in device access ordering etc, and the > usual ACPI changes means that we really want reports from people about > this all even if you don't have intel graphics. > > - Lots of cleanups from the x86 merge (making more and more use of common > files), but also the big page attribute stuff is in and caused a fair > amount of churn, and while most of the issues should have been very > obvious and all got fixed, this is definitely one of those things that > we want a lot of very wide testing of to make sure nothing regressed. > > - fair number of changes to things like the legacy IDE drivers too, and a > totally new driver for the very common PCIE version of the Intel e1000 > network card etc. > > - .. and I've probably totally forgotten about tons of other stuff I > should have mentioned, but the point is that not only do we have lots > of new core, we do have a fair amout of changes to basic stuff that can > actually affect perfectly bog-standard hardware setups. > >So give it all a good testing. I just did, and while non-x seems stable, the latest nvidia driver, about a week old, will not build a valid kernel module, so X bails out with a failed to load it, even though its sitting in /lib/modules/`uname -r`/kernel/drivers/video with exactly the same length as the one built for 2.6.24. The nvidia-installer log recommends doing a 'make prepare' which I did, but nvidia still errors out during the module build. So obviously I am back to 2.6.24, and my next stop is the nvidia web site to see if they have a fix. Other than that, it feels good. > Linus >-- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Idleness is the holiday of fools. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [WATCHDOG] it8712f_wdt support for 16-bit timeout values, WDIOC_GETSTATUS
This patch adds support for 16-bit watchdog timeout values which are
available in chip revisions >= 0x08. Values <= 65535 are seconds precision,
otherwise minutes precision is used up to a maximum value of 3932100. Added
implementation for WDIOC_GETSTATUS which checks the WDT status bit in the
WDT control register.
Signed-off-by: Andrew Paprocki <[EMAIL PROTECTED]>
---
drivers/watchdog/it8712f_wdt.c | 82
1 files changed, 66 insertions(+), 16 deletions(-)
diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c
index 1b6d7d1..803c699 100644
--- a/drivers/watchdog/it8712f_wdt.c
+++ b/drivers/watchdog/it8712f_wdt.c
@@ -7,7 +7,8 @@
*
*drivers/char/watchdog/scx200_wdt.c
*drivers/hwmon/it87.c
- * IT8712F EC-LPC I/O Preliminary Specification 0.9.2.pdf
+ * IT8712F EC-LPC I/O Preliminary Specification 0.8.2
+ * IT8712F EC-LPC I/O Preliminary Specification 0.9.3
*
*This program is free software; you can redistribute it and/or
*modify it under the terms of the GNU General Public License as
@@ -40,6 +41,7 @@ MODULE_DESCRIPTION("IT8712F Watchdog Driver");
MODULE_LICENSE("GPL");
MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
+static int max_units = 255;
static int margin = 60; /* in seconds */
module_param(margin, int, 0);
MODULE_PARM_DESC(margin, "Watchdog margin in seconds");
@@ -51,6 +53,7 @@ MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown
on close");
static struct semaphore it8712f_wdt_sem;
static unsigned expect_close;
static spinlock_t io_lock;
+static unsigned char revision;
/* Dog Food address - We use the game port address */
static unsigned short address;
@@ -108,6 +111,15 @@ superio_inw(int reg)
return val;
}
+static void
+superio_outw(int val, int reg)
+{
+outb(reg++, REG);
+outb((val >> 8) & 0xff, VAL);
+outb(reg, REG);
+outb(val & 0xff, VAL);
+}
+
static inline void
superio_select(int ldn)
{
@@ -143,15 +155,33 @@ static void
it8712f_wdt_update_margin(void)
{
int config = WDT_OUT_KRST | WDT_OUT_PWROK;
+int units = margin;
+
+/* Switch to minutes precision if the configured margin
+ * value does not fit within the register width.
+ */
+if (units <= max_units) {
+config |= WDT_UNIT_SEC; /* else UNIT is MINUTES */
+printk(KERN_INFO NAME ": timer margin %d seconds\n",
units);
+} else {
+units /= 60;
+printk(KERN_INFO NAME ": timer margin %d minutes\n",
units);
+}
+superio_outb(config, WDT_CONFIG);
+
+if (revision >= 0x08)
+superio_outw(units, WDT_TIMEOUT);
+else
+superio_outb(units, WDT_TIMEOUT);
+}
- printk(KERN_INFO NAME ": timer margin %d seconds\n", margin);
-
- /* The timeout register only has 8bits wide */
- if (margin < 256)
- config |= WDT_UNIT_SEC; /* else UNIT are MINUTES */
- superio_outb(config, WDT_CONFIG);
-
- superio_outb((margin > 255) ? (margin / 60) : margin, WDT_TIMEOUT);
+static int
+it8712f_wdt_get_status(void)
+{
+if (superio_inb(WDT_CONTROL) & 0x01)
+return WDIOF_CARDRESET;
+else
+return 0;
}
static void
@@ -234,7 +264,7 @@ it8712f_wdt_ioctl(struct inode *inode, struct file
*file,
.firmware_version = 1,
.options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
};
- int new_margin;
+ int value;
switch (cmd) {
default:
@@ -244,17 +274,27 @@ it8712f_wdt_ioctl(struct inode *inode, struct file
*file,
return -EFAULT;
return 0;
case WDIOC_GETSTATUS:
+superio_enter();
+superio_select(LDN_GPIO);
+
+value = it8712f_wdt_get_status();
+
+superio_exit();
+
+ return put_user(value, p);
case WDIOC_GETBOOTSTATUS:
- return put_user(0, p);
+return put_user(0, p);
case WDIOC_KEEPALIVE:
it8712f_wdt_ping();
return 0;
case WDIOC_SETTIMEOUT:
- if (get_user(new_margin, p))
+ if (get_user(value, p))
return -EFAULT;
- if (new_margin < 1)
+ if (value < 1)
return -EINVAL;
- margin = new_margin;
+if (value > (max_units * 60))
+return -EINVAL;
+ margin = value;
superio_enter();
superio_select(LDN_GPIO);
@@ -262,6 +302,7 @@ it8712f_wdt_ioctl(struct inode *inode, struct file
*file,
superio_exit();
it8712f_wdt_ping();
+/* Fall through */
case WDIOC_GETTIMEOUT:
if (put_user(margin, p))
Re: [PATCH] Change pci_raw_ops to pci_raw_read/write
Yinghai Lu wrote: On Feb 10, 2008 12:45 PM, Matthew Wilcox <[EMAIL PROTECTED]> wrote: On Sun, Feb 10, 2008 at 12:24:18PM -0800, Linus Torvalds wrote: On Sun, 10 Feb 2008, Yinghai Lu wrote: I suggest Ivan's patch be merged ASAP as it actually fixes bugs. This patch is just cleanup (and takes care of some future concerns). your patch and Ivan's patch should be merged in one... I really don't care whether they get merges as one or separately, but I think it should be merged _now_ (-rc1 is already delayed), and I'd like to see the final versions of both. Does anybody have them in a final agreed-upon format (preferably with that oddness in quirk_intel_irqbalance also fixed?) I just looked at fixing that -- the reason seems to be that we don't actually have the struct pci_dev at that point. I can fix it, but I think it's actually buggy. I want to look at some chipset docs to confirm that though. I've attached the two patches that I believe are the ones we want. We can (and should) fix quirk_intel_irqbalance separately. Andrew, those two patch just got into linus 2.6.25-rc1. I assume that you will drop gregkh-pci-pci-make-pci-extended-config-space-a-driver-opt-in.patch in -mm. please check some updated patches in -mm that could be affected. hope it could save you some time x86-validate-against-acpi-motherboard-resources.patch x86-clear-pci_mmcfg_virt-when-mmcfg-get-rejected.patch x86-mmconf-enable-mcfg-early.patch x86_64-check-msr-to-get-mmconfig-for-amd-family-10h-opteron-v3.patch I don't think any of these patches are affected. They all affect whether to use MMCONFIG globally or not, regardless of whether not particular accesses will use it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: Forcing PIO0 mode on reset must not freeze system
Hello,
Holger Macht wrote:
> Calling ap->ops->set_piomode(ap, dev) on a device/controller which got
> already removed, locks the system hard. Reproducibly on an X60 attached to
> a dock station containing a cdrom device with doing
>
> $ echo 1 > /sys/devices/platform/dock.0/undock && echo 123 > /dev/sr0
>
> This calls ata_eh_reset(...) which in turn tries to force PIO mode 0. But
> the device is already gone.
>
> Bisecting revealed the following commit as culprit:
>
> commit cdeab1140799f09c5f728a5ff85e0bdfa5679cd2
> Author: Tejun Heo <[EMAIL PROTECTED]>
> Date: Mon Oct 29 16:41:09 2007 +0900
>
> libata: relocate forcing PIO0 on reset
>
> Forcing PIO0 on reset was done inside ata_bus_softreset(), which is a
> bit out of place as it should be applied to all resets - hard, soft
> and implementation which don't use ata_bus_softreset(). Relocate it
> such that...
>
> * For new EH, it's done in ata_eh_reset() before calling prereset.
>
> * For old EH, it's done before calling ap->ops->phy_reset() in
> ata_bus_probe().
>
> This makes PIO0 forced after all resets. Another difference is that
> reset itself is done after PIO0 is forced.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> Acked-by: Alan Cox <[EMAIL PROTECTED]>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
>
>
> ATTENTION! The following patch solves the problem on my system, but please
> be aware that I don't really know what I'm doing because I don't have the
> big picture. There's surely a better way to check if the device/controller
> is still functional than calling ata_link_{online,offline}.
In the above example, even the reset sequence itself can cause hang if
the hardware is implemented slightly differently. The reason why
set_piomode() locks up but reset sequence doesn't is simple dumb luck.
I think the proper fix is to tell libata to detach the cdrom before
undocking.
> Signed-off-by: Holger Macht <[EMAIL PROTECTED]>
NACK.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] kgdb light, v6
On Feb 10, 2008 2:40 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Jan Kiszka <[EMAIL PROTECTED]> wrote: > > > Ingo, please keep the original annotations, they where correct and > > should have been optimal (under the given constraints or runtime > > reconfiguration). > > agreed. I've regenerated the -v7 tree with this trivial revert. Tip is > commit 04b94b1dd5197bf737073ebbd4189ffdfdcea534, updated shortlog, > diffstat and patch can be found below. Tree is at: > > git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.git > something related or not. my server doesn't have serial connector. the SP has serial port to host's internal serial port. I need to ssh to SP ( service processor) and start console there. wonder if there is program that is running on SP, and one program on develop workstation --- make it have one virtual serial port gdb or other legacy serial port program could use that virtual serial port. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lksctp-developers] [PATCH 8/8] : Use FIELD_SIZEOF
Alexey Dobriyan wrote:
On Sun, Feb 10, 2008 at 09:16:04PM +0100, Julia Lawall wrote:
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -618,7 +618,7 @@ static inline int param_type2af(__be16 t
static inline int sctp_sanity_check(void)
{
SCTP_ASSERT(sizeof(struct sctp_ulpevent) <=
- sizeof(((struct sk_buff *)0)->cb),
+ FIELD_SIZEOF(struct sk_buff, cb),
"SCTP: ulpevent does not fit in skb!\n", return 0);
return 1;
Same here. Use BUILD_BUG_ON instead.
Ack. BUILD_BUG_ON is definitely appropriate here, especially considering
that SCTP_ASSERT compiles to nothing with debugging turned off.
-vlad
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Lksctp-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/lksctp-developers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mlx4: fix build break
On Fri, Feb 08, 2008 at 03:16:53PM -0800, Roland Dreier wrote: > mlx4_core: For 64-bit systems, vmap() kernel queue buffers Hi, The above patch caused this to pop up on powerpc allyesconfig, looks like a missing include file: drivers/net/mlx4/alloc.c: In function 'mlx4_buf_alloc': drivers/net/mlx4/alloc.c:162: error: implicit declaration of function 'vmap' drivers/net/mlx4/alloc.c:162: error: 'VM_MAP' undeclared (first use in this function) drivers/net/mlx4/alloc.c:162: error: (Each undeclared identifier is reported only once drivers/net/mlx4/alloc.c:162: error: for each function it appears in.) drivers/net/mlx4/alloc.c:162: warning: assignment makes pointer from integer without a cast drivers/net/mlx4/alloc.c: In function 'mlx4_buf_free': drivers/net/mlx4/alloc.c:187: error: implicit declaration of function 'vunmap' Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> diff --git a/drivers/net/mlx4/alloc.c b/drivers/net/mlx4/alloc.c index 521dc03..75ef9d0 100644 --- a/drivers/net/mlx4/alloc.c +++ b/drivers/net/mlx4/alloc.c @@ -34,6 +34,7 @@ #include #include #include +#include #include "mlx4.h" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1-ext4-1 patchset released
This is a new ext4 patchset which is synchronized with the 2.6.25-rc1 release. No new patches were added, just patches removed because they have been accepted upstream. At this point, I do not anticipate any more patches to ext4 that will change the on-disk format. The focus is on the optimization patches (i.e., delayed allocation support) fine-tuning performance, and fixing any bugs which turn up as more people use ext4. As a git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 2.6.25-rc1-ext4-1 http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=shortlog;h=2.6.25-rc1-ext4-1 As a patchset: ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-patches/2.6.25-rc1-ext4-1 - Ted Akira Fujita (4): ext4: online defrad header file changes ext4: online defrag-- Allocate new contiguous blocks with mballoc ext4: online defrag -- Move the file data to the new blocks Free space fragmentation functions Alex Tomas (2): vfs: add basic delayed allocation support ext4: Add basic delayed allocation support Andi Kleen (2): Remove incorrect BKL comments in ext4 Convert ext4 to use unlocked_ioctl v2 Aneesh Kumar K.V (3): ext4: undo the stable boundary patch changes ext4: Enable delalloc and mballoc by default. ext4: Show delalloc options Mingming Cao (3): jbd: blocks reservation fix for large block support jbd2: blocks reservation fix for large block support ext4: remove read-inode from defrag code,replace with ext4_iget() Theodore Ts'o (2): ext4: Stable/Unstable boundary ext4: New inode allocation for FLEX_BG meta-data groups. fs/buffer.c |3 +- fs/ext4/Makefile|2 +- fs/ext4/balloc.c| 28 +- fs/ext4/defrag.c| 2206 +++ fs/ext4/dir.c |4 +- fs/ext4/extents.c | 65 +- fs/ext4/file.c |2 +- fs/ext4/ialloc.c| 96 ++ fs/ext4/inode.c | 166 +++- fs/ext4/ioctl.c | 25 +- fs/ext4/mballoc.c |7 + fs/ext4/super.c | 78 ++- fs/jbd/journal.c|7 +- fs/jbd2/journal.c |7 +- fs/mpage.c | 406 +++ include/linux/ext4_fs.h | 100 ++- include/linux/ext4_fs_extents.h | 22 + include/linux/ext4_fs_sb.h |3 + include/linux/mpage.h |2 + 19 files changed, 3183 insertions(+), 46 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2] x86: explicit call to mmiotrace in do_page_fault()
On Sun, 2008-02-10 at 20:05 +0200, Pekka Paalanen wrote: > Sorry Jan and Pavel, I forgot to CC you in the first go of this > patch. If this makes it into mainline, I don't think it will be left > there for many kernel versions. I plan to make kmmio.h as the API towards > modules in the future, and the page fault callback will "disappear". > I think madwifi could use just fine the kmmio.h functions, if it > works basically just like mmiotrace. In fact, the tracing version of MadWifi has a directory called mmiotrace with the files lifted from nouveau. I guess if will just stay in sync with the upstream. Many thanks for pushing it into the kernel. -- Regards, Pavel Roskin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Change pci_raw_ops to pci_raw_read/write
On Feb 10, 2008 12:45 PM, Matthew Wilcox <[EMAIL PROTECTED]> wrote: > > On Sun, Feb 10, 2008 at 12:24:18PM -0800, Linus Torvalds wrote: > > On Sun, 10 Feb 2008, Yinghai Lu wrote: > > > > > > > > I suggest Ivan's patch be merged ASAP as it actually fixes bugs. > > > > This patch is just cleanup (and takes care of some future concerns). > > > > > > your patch and Ivan's patch should be merged in one... > > > > I really don't care whether they get merges as one or separately, but I > > think it should be merged _now_ (-rc1 is already delayed), and I'd like to > > see the final versions of both. Does anybody have them in a final > > agreed-upon format (preferably with that oddness in quirk_intel_irqbalance > > also fixed?) > > I just looked at fixing that -- the reason seems to be that we don't > actually have the struct pci_dev at that point. I can fix it, but I > think it's actually buggy. I want to look at some chipset docs to > confirm that though. > > I've attached the two patches that I believe are the ones we want. We > can (and should) fix quirk_intel_irqbalance separately. Andrew, those two patch just got into linus 2.6.25-rc1. I assume that you will drop gregkh-pci-pci-make-pci-extended-config-space-a-driver-opt-in.patch in -mm. please check some updated patches in -mm that could be affected. hope it could save you some time x86-validate-against-acpi-motherboard-resources.patch x86-clear-pci_mmcfg_virt-when-mmcfg-get-rejected.patch x86-mmconf-enable-mcfg-early.patch x86_64-check-msr-to-get-mmconfig-for-amd-family-10h-opteron-v3.patch YH x.tar.bz2 Description: BZip2 compressed data
Re: Linux 2.6.25-rc1 , syntax error near unexpected token `;'
Hello All , grabbed using git just moments ago . make V=1 KBUILD_VERBOSE=1 INSTALL_PATH=/boot clean all install modules_install ...snip... make -f scripts/Makefile.clean obj=sound/usb/usx2y make -f scripts/Makefile.clean obj=usr rm -rf .tmp_versions rm -f arch/x86/boot/fdimage arch/x86/boot/image.iso arch/x86/boot/mtools.conf vmlinux System.map .tmp_kallsyms* .tmp_version .tmp_vmlinux* .tmp_System.map rm -f include/config/kernel.release echo 2.6.25-rc1 > include/config/kernel.release set -e; ; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp include/linux/version.h; fi /bin/sh: -c: line 0: syntax error near unexpected token `;' /bin/sh: -c: line 0: `set -e; ; mkdir -p include/linux/;(echo \#define LINUX_VERSION_CODE 132633; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < /usr/src/linux-2.6.25-rc1-git/Makefile > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else ; mv -f include/linux/version.h.tmp include/linux/version.h; fi' make: *** [include/linux/version.h] Error 2 # scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux filesrv2 2.6.23-rc9 #1 SMP Wed Oct 3 02:12:33 UTC 2007 i686 pentium4 i386 GNU/Linux Gnu C 3.4.6 Gnu make 3.81 binutils 2.15.92.0.2 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.38 jfsutils 1.1.11 reiserfsprogs 3.6.19 xfsprogs 2.8.10 pcmciautils014 pcmcia-cs 3.2.8 quota-tools3.13. PPP2.4.4 Linux C Library2.3.6 Dynamic linker (ldd) 2.3.6 Linux C++ Library 6.0.3 Procps 3.2.7 Net-tools 1.60 Kbd1.12 oprofile 0.9.1 Sh-utils 5.97 udev 097 Modules Loaded -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | Network Engineer | 2133McCullam Ave | Give me Linux | | [EMAIL PROTECTED] | Fairbanks, AK. 99701 | only on AXP | +--+ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kgdb in git-x86#mm review
I sent Jan & Jason earlier a quick review of the kgdb code currently in git-x86#mm. The kgdb code in git-x86#mm is right now is totally broken of course because the CFI annotations in assembler code are gone now, but they are needed for gdb use. And the bogus fault handling code is still in there, but Jason apprently fixed that one. Here are the other commments I wrote just in case someone is interested. Overall I would say there is quite a lot of stuff to clean up still. ok, doing a review on the code in git-x86#mm. I have not read everything in detail, just a quick skip over. My personal test for clean kernel debugger integration is if the debugger could be made a loadable (but not unloadable) module with minor/no effort. How far away is your code from that? The 32bit in_exception_stack code looks weird. Are you sure you cannot just use the pt_regs passed to the die notifier? It might be safer to explicitely disable interrupts early in the notifier. You should probably use simple_strtoul() instead of inventing an own hex parser in kgdb.c. And sprintf instead of an own hex writer. In general more use sprintf would probably shorten a lot of the parser code. The num_online_cpu()s check in getthread() looks weird. What is that supposed to do? kgdb_softlock_notify: I think the right way to handle this is just calling touch_softlockup_watchdog() (or perhaps better touch_nmi_watchdog) Actually it should be only needed once when you exit the debugger for soft lockup, but regularly for nmi watchdog. On x86 it is ok, but on other architectures i'm suspect the SMP synchronization with atomics might benefit from more memory barriers. gdb_cmd_reboot: always calling emergency_sync looks dangerous. In fact i suspect if you hold the other CPUs the changes are good it will lock up. You should at least offer a option to not call that (or better don't do it by default). Even machine_start is likely lock up actually if the other CPUs are truly halted (as they should be) because it will try to halt them. So if anything I suspect you need to exit the debugger first before executing this. The logic to halt all the other CPUs in kgdb_handle_exception et.al. looks a little fragile. It would be probably best to use the same as kcrash uses factored out into a common function. One obvious problem is that it is racy against cpu hotplug, but there are likely others too. With a better implementation you likely wouldn't need the mdelay(2) hack further down. You should use raw spinlocks everywhere in the debugger -- i don't think you want lockdep etc. anywhere. The unregister hook stuff looks racy against NMIs etc. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Btrfs v0.12 released
From: Chris Mason <[EMAIL PROTECTED]>
Date: Wed, 6 Feb 2008 12:00:13 -0500
> So, here's v0.12.
I couldn't even make a filesystem on sparc64 without the following
patch.
The first problem is that these SETGET macros lose typing information,
and therefore can't see the 'packed' attribute and therefore take
unaligned access SIGBUS signals on sparc64 when trying to derefernce
the member.
The next problem is a similar issue in btrfs_name_hash(). This gets
passed things like which is a member of a packed
structure, losing this packed'ness information btrfs_name_hash()
performs a potentially unaligned memory access, again resulting in a
SIGBUS.
This function never returns an error, so the simplest fix was to
return the hash value which avoids all of the issues. In attempting
other schemes to fix this, I found it very difficult to give gcc
a packed attribute for that "u64 *" argument other than to create
some new pseudo structure which would have been ugly.
Similar code lives in the btrfs kernel code too, I'll try to get a
partition at least mounted and working minimally and if successful
I'll send you patches for that too.
diff -up --recursive --new-file vanilla/btrfs-progs-0.12/ctree.h
btrfs-progs-0.12/ctree.h
--- vanilla/btrfs-progs-0.12/ctree.h2008-02-06 08:37:45.0 -0800
+++ btrfs-progs-0.12/ctree.h2008-02-10 16:53:24.0 -0800
@@ -451,18 +451,16 @@ static inline void btrfs_set_##name(stru
static inline u##bits btrfs_##name(struct extent_buffer *eb, \
type *s) \
{ \
- unsigned long offset = (unsigned long)s + \
- offsetof(type, member); \
- __le##bits *tmp = (__le##bits *)(eb->data + offset);\
- return le##bits##_to_cpu(*tmp); \
+ unsigned long offset = (unsigned long)s;\
+ type *p = (type *) (eb->data + offset); \
+ return le##bits##_to_cpu(p->member);\
} \
static inline void btrfs_set_##name(struct extent_buffer *eb, \
type *s, u##bits val) \
{ \
- unsigned long offset = (unsigned long)s + \
- offsetof(type, member); \
- __le##bits *tmp = (__le##bits *)(eb->data + offset);\
- *tmp = cpu_to_le##bits(val);\
+ unsigned long offset = (unsigned long)s;\
+ type *p = (type *) (eb->data + offset); \
+ p->member = cpu_to_le##bits(val); \
}
#define BTRFS_SETGET_STACK_FUNCS(name, type, member, bits) \
diff -up --recursive --new-file vanilla/btrfs-progs-0.12/dir-item.c
btrfs-progs-0.12/dir-item.c
--- vanilla/btrfs-progs-0.12/dir-item.c 2008-02-06 08:37:45.0 -0800
+++ btrfs-progs-0.12/dir-item.c 2008-02-10 17:03:34.0 -0800
@@ -71,8 +71,7 @@ int btrfs_insert_xattr_item(struct btrfs
key.objectid = dir;
btrfs_set_key_type(, BTRFS_XATTR_ITEM_KEY);
- ret = btrfs_name_hash(name, name_len, );
- BUG_ON(ret);
+ key.offset = btrfs_name_hash(name, name_len);
path = btrfs_alloc_path();
if (!path)
return -ENOMEM;
@@ -122,8 +121,7 @@ int btrfs_insert_dir_item(struct btrfs_t
key.objectid = dir;
btrfs_set_key_type(, BTRFS_DIR_ITEM_KEY);
- ret = btrfs_name_hash(name, name_len, );
- BUG_ON(ret);
+ key.offset = btrfs_name_hash(name, name_len);
path = btrfs_alloc_path();
data_size = sizeof(*dir_item) + name_len;
dir_item = insert_with_overflow(trans, root, path, , data_size,
@@ -196,8 +194,7 @@ struct btrfs_dir_item *btrfs_lookup_dir_
key.objectid = dir;
btrfs_set_key_type(, BTRFS_DIR_ITEM_KEY);
- ret = btrfs_name_hash(name, name_len, );
- BUG_ON(ret);
+ key.offset = btrfs_name_hash(name, name_len);
ret = btrfs_search_slot(trans, root, , path, ins_len, cow);
if (ret < 0)
@@ -258,8 +255,7 @@ struct btrfs_dir_item *btrfs_lookup_xatt
key.objectid = dir;
btrfs_set_key_type(, BTRFS_XATTR_ITEM_KEY);
- ret = btrfs_name_hash(name, name_len, );
- BUG_ON(ret);
+ key.offset = btrfs_name_hash(name, name_len);
ret = btrfs_search_slot(trans, root, , path, ins_len, cow);
if (ret < 0)
return ERR_PTR(ret);
diff -up --recursive --new-file vanilla/btrfs-progs-0.12/dir-test.c
btrfs-progs-0.12/dir-test.c
--- vanilla/btrfs-progs-0.12/dir-test.c 2008-02-06
Re: [PATCH] make /dev/kmem a config option
On Mon, 11 Feb 2008 01:13:09 +0100 (CET)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Feb 10 2008 15:55, Arjan van de Ven wrote:
> >+#ifdef CONFIG_DEVKMEM
> > /*
> > * This function reads the *virtual* memory as seen by the kernel.
> > */
> >@@ -585,6 +588,11 @@ static ssize_t write_kmem(struct file * file,
> >const char __user * buf,
> > *ppos = p;
> > return virtr + wrote;
> > }
> >+#else
> >+#define read_kmem NULL
> >+#define write_kmem NULL
> >+#define mmap_kmem NULL
> >+#endif
>
> Is the #else case needed? All kmem_fops uses seem #ifdef'ed out
> anyway, except kmem_fops itself. In other words,
>
> +#ifdef CONFIG_DEVKMEM
> static const struct file_operations kmem_fops = {
> ...
> }
> +#endif
>
> and do away with the three defines. No? :)
yup you're right; updated patch below
---
Subject: [PATCH] make /dev/kmem a config option
From: Arjan van de Ven <[EMAIL PROTECTED]>
This patch makes /dev/kmem a config option; /dev/kmem is VERY rarely
used, and when used, it's generally for no good (rootkits tend to be
the most common users). With this config option, users have the
choice to disable /dev/kmem, saving some size as well.
A patch to disable /dev/kmem has been in the Fedora and RHEL kernels for
4+ years now without any known problems or legit users of /dev/kmem.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/char/Kconfig |8
drivers/char/mem.c | 10 ++
2 files changed, 18 insertions(+)
Index: linux.trees.git/drivers/char/Kconfig
===
--- linux.trees.git.orig/drivers/char/Kconfig
+++ linux.trees.git/drivers/char/Kconfig
@@ -80,6 +80,14 @@ config VT_HW_CONSOLE_BINDING
information. For framebuffer console users, please refer to
.
+config DEV_KMEM
+ bool "/dev/kmem virtual device support"
+ help
+ Say Y here if you want to support the /dev/kmem device. The
+ /dev/kmem device is rarely used, but can be used for certain
+ kind of kernel debugging operations.
+ When in doubt, say "N".
+
config SERIAL_NONSTANDARD
bool "Non-standard serial port support"
depends on HAS_IOMEM
Index: linux.trees.git/drivers/char/mem.c
===
--- linux.trees.git.orig/drivers/char/mem.c
+++ linux.trees.git/drivers/char/mem.c
@@ -295,6 +295,7 @@ static int mmap_mem(struct file * file,
return 0;
}
+#ifdef CONFIG_DEVKMEM
static int mmap_kmem(struct file * file, struct vm_area_struct * vma)
{
unsigned long pfn;
@@ -315,6 +316,7 @@ static int mmap_kmem(struct file * file,
vma->vm_pgoff = pfn;
return mmap_mem(file, vma);
}
+#endif
#ifdef CONFIG_CRASH_DUMP
/*
@@ -353,6 +355,7 @@ static ssize_t read_oldmem(struct file *
extern long vread(char *buf, char *addr, unsigned long count);
extern long vwrite(char *buf, char *addr, unsigned long count);
+#ifdef CONFIG_DEVKMEM
/*
* This function reads the *virtual* memory as seen by the kernel.
*/
@@ -557,6 +560,7 @@ static ssize_t write_kmem(struct file *
*ppos = p;
return virtr + wrote;
}
+#endif
#ifdef CONFIG_DEVPORT
static ssize_t read_port(struct file * file, char __user * buf,
@@ -734,6 +738,7 @@ static const struct file_operations mem_
.get_unmapped_area = get_unmapped_area_mem,
};
+#ifdef CONFIG_DEVKMEM
static const struct file_operations kmem_fops = {
.llseek = memory_lseek,
.read = read_kmem,
@@ -742,6 +747,7 @@ static const struct file_operations kmem
.open = open_kmem,
.get_unmapped_area = get_unmapped_area_mem,
};
+#endif
static const struct file_operations null_fops = {
.llseek = null_lseek,
@@ -820,11 +826,13 @@ static int memory_open(struct inode * in
filp->f_mapping->backing_dev_info =
_mappable_cdev_bdi;
break;
+#ifdef CONFIG_DEVKMEM
case 2:
filp->f_op = _fops;
filp->f_mapping->backing_dev_info =
_mappable_cdev_bdi;
break;
+#endif
case 3:
filp->f_op = _fops;
break;
@@ -873,7 +881,9 @@ static const struct {
const struct file_operations*fops;
} devlist[] = { /* list of minor devices */
{1, "mem", S_IRUSR | S_IWUSR | S_IRGRP, _fops},
+#ifdef CONFIG_DEVKMEM
{2, "kmem",S_IRUSR | S_IWUSR | S_IRGRP, _fops},
+#endif
{3, "null",S_IRUGO | S_IWUGO, _fops},
#ifdef CONFIG_DEVPORT
{4, "port",S_IRUSR | S_IWUSR | S_IRGRP, _fops},
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line
Linux 2.6.25-rc1
Ok, it's a bloody large -rc (as was 24-rc1, for that matter), probably because the 2.6.24 release cycle dragged out, so people had a lot of things pending. The full diff is something like 11MB and 1.4M lines of diffs, with the bulk of the stuff being in architecture updates and drivers. Just to have some fun, I did trivial statistics, and of the 1.4M lines of diffs, about 38% - 530k lines - were in architecture files (400k+ lines of diffs in arch/, 100k+ lines of diffs in include/asm-*), and another big chunk is in drivers (including sound) at about 44% - 610k lines - of changes. The rest comes in much smaller, but still noticeable is networking (8% - 110k lines), with filesystems at 4%, and documentation at about 2%. The remaining crumbles being spread out mostly over block layer, crypto, kernel core, and security layer updates (ie SElinux and smack). [ Just to make it more obvious how driver and architecture-dominated the kernel changelogs are: just the network driver changes were 200kloc, and even just infiniband - which came way behind not just networking drivers, but also DVB, SCSI, char and ide - generated more lines of code changed than the "core" kernel code under the kernel/ subdirectory. And that's despite the fact that the "core" code was actually under a fairly active merge cycle, with a lot of namespace- and scheduling- related stuff. ] Now, some of that is files moving about and other reorganizations (SH and to a lesser degree sparc starting to merge 32-bit and 64-bit architectures), but most of it really is just the normal flood of changes and new driver or platform support. The full shortlog is half a meg in size (and the diffstat is even bigger), so I won't be including that here, but some things that may be worth pointing out not because they are big in line sizes, but because they have potential to be noticed by more people: - the intel graphics driver is starting to do suspend/resume natively (ie even without X support), which is a welcome sign of the times and may help some people. It helped on my laptop. - Other suspend/resume changes in device access ordering etc, and the usual ACPI changes means that we really want reports from people about this all even if you don't have intel graphics. - Lots of cleanups from the x86 merge (making more and more use of common files), but also the big page attribute stuff is in and caused a fair amount of churn, and while most of the issues should have been very obvious and all got fixed, this is definitely one of those things that we want a lot of very wide testing of to make sure nothing regressed. - fair number of changes to things like the legacy IDE drivers too, and a totally new driver for the very common PCIE version of the Intel e1000 network card etc. - .. and I've probably totally forgotten about tons of other stuff I should have mentioned, but the point is that not only do we have lots of new core, we do have a fair amout of changes to basic stuff that can actually affect perfectly bog-standard hardware setups. So give it all a good testing. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [POWERPC] Wire up new timerfd syscalls
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> --- include/asm-powerpc/systbl.h |4 +++- include/asm-powerpc/unistd.h |6 -- 2 files changed, 7 insertions(+), 3 deletions(-) Kernel built for ppc64_defconfig, pseries_defconfig, iseries_defconfig, cell_defconfig and pmac32_defconfig. The latter failed because check_media_bay is still undefined (i.e. for unrelated reasons). This has been tested on a pseries_defconfig kernel using the posted test program built for 64 and 32 bit. diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h index e996521..ae7085c 100644 --- a/include/asm-powerpc/systbl.h +++ b/include/asm-powerpc/systbl.h @@ -309,8 +309,10 @@ SYSCALL_SPU(getcpu) COMPAT_SYS(epoll_pwait) COMPAT_SYS_SPU(utimensat) COMPAT_SYS_SPU(signalfd) -SYSCALL(ni_syscall) +SYSCALL_SPU(timerfd_create) SYSCALL_SPU(eventfd) COMPAT_SYS_SPU(sync_file_range2) COMPAT_SYS(fallocate) SYSCALL(subpage_prot) +COMPAT_SYS_SPU(timerfd_settime) +COMPAT_SYS_SPU(timerfd_gettime) diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h index fedc4b8..ce91bb6 100644 --- a/include/asm-powerpc/unistd.h +++ b/include/asm-powerpc/unistd.h @@ -328,15 +328,17 @@ #define __NR_epoll_pwait 303 #define __NR_utimensat 304 #define __NR_signalfd 305 -#define __NR_timerfd 306 +#define __NR_timerfd_create306 #define __NR_eventfd 307 #define __NR_sync_file_range2 308 #define __NR_fallocate 309 #define __NR_subpage_prot 310 +#define __NR_timerfd_settime 311 +#define __NR_timerfd_gettime 312 #ifdef __KERNEL__ -#define __NR_syscalls 311 +#define __NR_syscalls 313 #define __NR__exit __NR_exit #define NR_syscalls__NR_syscalls -- 1.5.4 -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make /dev/kmem a config option
On Mon, 11 Feb 2008 01:13:09 +0100 (CET)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Feb 10 2008 15:55, Arjan van de Ven wrote:
> >+#ifdef CONFIG_DEVKMEM
> > /*
> > * This function reads the *virtual* memory as seen by the kernel.
> > */
> >@@ -585,6 +588,11 @@ static ssize_t write_kmem(struct file * file,
> >const char __user * buf,
> > *ppos = p;
> > return virtr + wrote;
> > }
> >+#else
> >+#define read_kmem NULL
> >+#define write_kmem NULL
> >+#define mmap_kmem NULL
> >+#endif
>
> Is the #else case needed? All kmem_fops uses seem #ifdef'ed out
> anyway, except kmem_fops itself. In other words,
>
> +#ifdef CONFIG_DEVKMEM
> static const struct file_operations kmem_fops = {
> ...
> }
> +#endif
>
> and do away with the three defines. No? :)
hmm I tried that first, and didn't work
but that wasn't on the final version of the patch so let me try again..
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Oops report for the week upto Feb 10th 2008
The http://www.kerneloops.org website collects kernel oops and warning reports from various mailing lists and bugzillas as well as with a client users can install to auto-submit oopses. Below is a top 10 list of the oopses/backtraces collected in the last 7 days. (Reports prior to 2.6.23 have been omitted in collecting the top 10) This week, a total of 323 oopses and warnings have been reported, compared to 110 reports in the previous week. (This sharp increase is due to Fedora 9 alpha shipping the oops data collection client in the default install, giving us much wider coverage in the issues that actual users hit; many thanks to the Fedora project for this) With the 2.6.25-rc1 release out, this will be the last report that includes 2.6.23; future reports will only include issues from 2.6.24 and later. Rank 1: set_dentry_child_flags WARN_ON at fs/inotify.c:172 set_dentry_child_flags Reported 93 times (116 total reports) This is a user triggered WARN_ON in inotify. Sadly inotify seems to be unmaintained. More info: http://www.kerneloops.org/search.php?search=set_dentry_child_flags Rank 2: __ieee80211_rx_handle_packet WARN_ON at net/mac80211/rx.c:1704 __ieee80211_rx_handle_packet Reported 35 times (82 total reports) This is the well known packet alignment issue; fix in progress More info: http://www.kerneloops.org/search.php?search=__ieee80211_rx_handle_packet Rank 3: remove_proc_entry WARN_ON at fs/proc/generic.c:736 Reported 20 times (38 total reports) This WARN_ON is there if code tries to remove a non-empty /proc directory. Most reports are tainted, pointing at a bug in a binary module. Without the WARN_ON improvements from 2.6.25-rc1 it'll be hard to figure out which module is guilty. More info: http://www.kerneloops.org/search.php?search=remove_proc_entry Rank 4: bad_io_access WARN_ON at lib/iomap.c:44 Reported 15 times (21 total reports) This is a bug in the ata_bmdma code More info: http://www.kerneloops.org/search.php?search=bad_io_access Rank 5: sysctl_print_path Reported 28 times (41 total reports) This is a bug in the binary-only madwifi module. More info: http://www.kerneloops.org/search.php?search=sysctl_print_path Rank 6: dma_free_coherent WARN_ON at arch/x86/kernel/pci-dma_32.c:66 Reported 9 times (11 total reports) This bug happened with the acx, arcmsr, sym2 and generic ata drivers More info: http://www.kerneloops.org/search.php?search=dma_free_coherent Rank 7: _spin_unlock_irqrestore Soft lockup Reported 7 times (11 total reports) In all cases it happened via scsi_dispatch_cmd More info: http://www.kerneloops.org/search.php?search=_spin_unlock_irqrestore Rank 8: uart_flush_buffer The well known bluetooth tty flush bug A fix for this bug has been merged into 2.6.25-rc1 Reported 6 times (67 total reports) More info: http://www.kerneloops.org/search.php?search=uart_flush_buffer Rank 9: mark_buffer_dirty WARN_ON at fs/buffer.c:1169 This indicates that a non-uptodate buffer is marked dirty. This can lead to data corruption! Reported 5 times (12 total reports) - Only seen since 2.6.24-rc6 Usually happens during umount() More info: http://www.kerneloops.org/search.php?search=mark_buffer_dirty Rank 10: sysfs_add_one WARN_ON at fs/sysfs/dir.c:424 (duplicate filename) Reported 5 times (57 total reports) Seems to happen mostly with ALSA More info: http://www.kerneloops.org/search.php?search=sysfs_add_one -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Prevent IDE boot ops on NUMA system in mainline
Without this patch a Opteron test system here oopses at boot with currentg git.
Calling to_pci_dev() on a NULL pointer gives a negative value so the following
NULL
pointer check never triggers and then an illegal address is referenced. Check
the
unadjusted original device pointer for NULL instead.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/include/linux/ide.h
===
--- linux.orig/include/linux/ide.h
+++ linux/include/linux/ide.h
@@ -1294,7 +1294,7 @@ static inline void ide_dump_identify(u8
static inline int hwif_to_node(ide_hwif_t *hwif)
{
struct pci_dev *dev = to_pci_dev(hwif->dev);
- return dev ? pcibus_to_node(dev->bus) : -1;
+ return hwif->dev ? pcibus_to_node(dev->bus) : -1;
}
static inline ide_drive_t *ide_get_paired_drive(ide_drive_t *drive)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.25-rc1 3/3] gpio: define gpio_is_valid()
From: Guennadi Liakhovetski <[EMAIL PROTECTED]>
Introduce a gpio_is_valid() predicate; use it in gpiolib.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
[ use inline function; follow the gpio_* naming convention;
work without gpiolib; all programming interfaces need docs ]
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Documentation/gpio.txt | 10 ++
drivers/gpio/gpiolib.c | 14 +++---
include/asm-generic/gpio.h | 12
3 files changed, 29 insertions(+), 7 deletions(-)
--- g26.orig/Documentation/gpio.txt 2008-02-10 16:06:30.0 -0800
+++ g26/Documentation/gpio.txt 2008-02-10 16:09:54.0 -0800
@@ -102,6 +102,16 @@ type of GPIO controller, and on one part
The numbers need not be contiguous; either of those platforms could also
use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
+If you want to initialize a structure with an invalid GPIO number, use
+some negative number (perhaps "-EINVAL"); that will never be valid. To
+test if a number could reference a GPIO, you may use this predicate:
+
+ int gpio_is_valid(int number);
+
+A number that's not valid will be rejected by calls which may request
+or free GPIOs (see below). Other numbers may also be rejected; for
+example, a number might be valid but unused on a given board.
+
Whether a platform supports multiple GPIO controllers is currently a
platform-specific implementation issue.
--- g26.orig/drivers/gpio/gpiolib.c 2008-02-10 16:09:51.0 -0800
+++ g26/drivers/gpio/gpiolib.c 2008-02-10 16:09:54.0 -0800
@@ -96,7 +96,7 @@ int gpiochip_add(struct gpio_chip *chip)
* dynamic allocation. We don't currently support that.
*/
- if (chip->base < 0 || (chip->base + chip->ngpio) >= ARCH_NR_GPIOS) {
+ if (chip->base < 0 || !gpio_is_valid(chip->base + chip->ngpio)) {
status = -EINVAL;
goto fail;
}
@@ -171,7 +171,7 @@ int gpio_request(unsigned gpio, const ch
spin_lock_irqsave(_lock, flags);
- if (gpio >= ARCH_NR_GPIOS)
+ if (!gpio_is_valid(gpio))
goto done;
desc = _desc[gpio];
if (desc->chip == NULL)
@@ -206,7 +206,7 @@ void gpio_free(unsigned gpio)
unsigned long flags;
struct gpio_desc*desc;
- if (gpio >= ARCH_NR_GPIOS) {
+ if (!gpio_is_valid(gpio)) {
WARN_ON(extra_checks);
return;
}
@@ -242,7 +242,7 @@ const char *gpiochip_is_requested(struct
{
unsigned gpio = chip->base + offset;
- if (gpio >= ARCH_NR_GPIOS || gpio_desc[gpio].chip != chip)
+ if (!gpio_is_valid(gpio) || gpio_desc[gpio].chip != chip)
return NULL;
if (test_bit(FLAG_REQUESTED, _desc[gpio].flags) == 0)
return NULL;
@@ -273,7 +273,7 @@ int gpio_direction_input(unsigned gpio)
spin_lock_irqsave(_lock, flags);
- if (gpio >= ARCH_NR_GPIOS)
+ if (!gpio_is_valid(gpio))
goto fail;
chip = desc->chip;
if (!chip || !chip->get || !chip->direction_input)
@@ -311,7 +311,7 @@ int gpio_direction_output(unsigned gpio,
spin_lock_irqsave(_lock, flags);
- if (gpio >= ARCH_NR_GPIOS)
+ if (!gpio_is_valid(gpio))
goto fail;
chip = desc->chip;
if (!chip || !chip->set || !chip->direction_output)
@@ -528,7 +528,7 @@ static int gpiolib_show(struct seq_file
/* REVISIT this isn't locked against gpio_chip removal ... */
- for (gpio = 0; gpio < ARCH_NR_GPIOS; gpio++) {
+ for (gpio = 0; gpio_is_valid(gpio); gpio++) {
if (chip == gpio_desc[gpio].chip)
continue;
chip = gpio_desc[gpio].chip;
--- g26.orig/include/asm-generic/gpio.h 2008-02-10 16:09:51.0 -0800
+++ g26/include/asm-generic/gpio.h 2008-02-10 16:09:54.0 -0800
@@ -16,6 +16,12 @@
#define ARCH_NR_GPIOS 256
#endif
+static inline int gpio_is_valid(int number)
+{
+ /* only some non-negative numbers are valid */
+ return ((unsigned)number) < ARCH_NR_GPIOS;
+}
+
struct seq_file;
struct module;
@@ -99,6 +105,12 @@ extern int __gpio_cansleep(unsigned gpio
#else
+static inline int gpio_is_valid(int number)
+{
+ /* only non-negative numbers are valid */
+ return number >= 0;
+}
+
/* platforms that don't directly support access to GPIOs through I2C, SPI,
* or other blocking infrastructure can use these wrappers.
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 2.6.25-rc1 2/3] gpiolib: i2c/spi drivers handler rmmod better
From: Guennadi Liakhovetski <[EMAIL PROTECTED]> Use the newly introduced owner field in struct gpio_chip to protect the current (small) set of non-SOC GPIO drivers from being unloaded while any of their GPIOs are in use. Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> [ add mcp23s08 and pcf857x ] Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- drivers/gpio/mcp23s08.c |1 + drivers/gpio/pca953x.c |1 + drivers/gpio/pcf857x.c |1 + 3 files changed, 3 insertions(+) --- g26.orig/drivers/gpio/mcp23s08.c2008-02-10 16:06:30.0 -0800 +++ g26/drivers/gpio/mcp23s08.c 2008-02-10 16:09:52.0 -0800 @@ -239,6 +239,7 @@ static int mcp23s08_probe(struct spi_dev mcp->chip.base = pdata->base; mcp->chip.ngpio = 8; mcp->chip.can_sleep = 1; + mcp->chip.owner = THIS_MODULE; spi_set_drvdata(spi, mcp); --- g26.orig/drivers/gpio/pca953x.c 2008-02-10 16:06:30.0 -0800 +++ g26/drivers/gpio/pca953x.c 2008-02-10 16:09:52.0 -0800 @@ -188,6 +188,7 @@ static void pca953x_setup_gpio(struct pc gc->base = chip->gpio_start; gc->ngpio = gpios; gc->label = chip->client->name; + gc->owner = THIS_MODULE; } static int __devinit pca953x_probe(struct i2c_client *client) --- g26.orig/drivers/gpio/pcf857x.c 2008-02-10 16:06:30.0 -0800 +++ g26/drivers/gpio/pcf857x.c 2008-02-10 16:09:52.0 -0800 @@ -159,6 +159,7 @@ static int pcf857x_probe(struct i2c_clie gpio->chip.base = pdata->gpio_base; gpio->chip.can_sleep = 1; + gpio->chip.owner = THIS_MODULE; /* NOTE: the OnSemi jlc1562b is also largely compatible with * these parts, notably for output. It has a low-resolution -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
On Sunday 10 February 2008, Adrian McMenamin wrote:
> +static int dc_pad_connect(struct maple_device *mdev)
> +{
> + ...
> + if (data&(1<= 0)
could use a few spaces in that first expression
> +/* allow the controller to be used */
> +static int probe_maple_controller(struct device *dev)
> +{
> + struct maple_device *mdev = to_maple_dev(dev);
> + struct maple_driver *mdrv = to_maple_driver(dev->driver);
> + int error;
> +
> + error = dc_pad_connect(mdev);
> + if (error)
> + return error;
> +
> + mdev->driver = mdrv;
> +
> + return 0;
> +}
> +
> +static struct maple_driver dc_pad_driver = {
> + .function = MAPLE_FUNC_CONTROLLER,
> + .connect = dc_pad_connect,
> + .disconnect = dc_pad_disconnect,
> + .drv = {
> + .name = "Dreamcast_controller",
> + .probe = probe_maple_controller,
> + },
> +};
no remove function ? looks like the probe() forces a connect, but there's no
remove() to force a disconnect ...
-mike
signature.asc
Description: This is a digitally signed message part.
[patch 2.6.25-rc1 1/3] gpiolib: better rmmod infrastructure
From: Guennadi Liakhovetski <[EMAIL PROTECTED]>
As long as one or more GPIOs on a gpio chip are used its driver should not
be unloaded. The existing mechanism (gpiochip_remove failure) doesn't
address that, since rmmod can no longer be made to fail by having the
cleanup code report errors. Module usecounts are the solution.
Assuming standard "initialize struct to zero" policies, this change won't
affect SOC platform drivers. However, drivers for external chips (on I2C
and SPI busses) should be updated if they can be built as modules.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
[ gpio_ensure_requested() needs to update module usecounts too ]
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/gpiolib.c | 15 ---
include/asm-generic/gpio.h |2 ++
2 files changed, 14 insertions(+), 3 deletions(-)
--- g26.orig/drivers/gpio/gpiolib.c 2008-02-10 16:06:30.0 -0800
+++ g26/drivers/gpio/gpiolib.c 2008-02-10 16:18:35.0 -0800
@@ -68,6 +68,9 @@ static void gpio_ensure_requested(struct
if (test_and_set_bit(FLAG_REQUESTED, >flags) == 0) {
pr_warning("GPIO-%d autorequested\n", (int)(desc - gpio_desc));
desc_set_label(desc, "[auto]");
+ if (!try_module_get(desc->chip->owner))
+ pr_err("GPIO-%d: module can't be gotten \n",
+ (int)(desc - gpio_desc));
}
}
@@ -177,6 +180,9 @@ int gpio_request(unsigned gpio, const ch
if (desc->chip == NULL)
goto done;
+ if (!try_module_get(desc->chip->owner))
+ goto done;
+
/* NOTE: gpio_request() can be called in early boot,
* before IRQs are enabled.
*/
@@ -184,8 +190,10 @@ int gpio_request(unsigned gpio, const ch
if (test_and_set_bit(FLAG_REQUESTED, >flags) == 0) {
desc_set_label(desc, label ? : "?");
status = 0;
- } else
+ } else {
status = -EBUSY;
+ module_put(desc->chip->owner);
+ }
done:
if (status)
@@ -209,9 +217,10 @@ void gpio_free(unsigned gpio)
spin_lock_irqsave(_lock, flags);
desc = _desc[gpio];
- if (desc->chip && test_and_clear_bit(FLAG_REQUESTED, >flags))
+ if (desc->chip && test_and_clear_bit(FLAG_REQUESTED, >flags)) {
desc_set_label(desc, NULL);
- else
+ module_put(desc->chip->owner);
+ } else
WARN_ON(extra_checks);
spin_unlock_irqrestore(_lock, flags);
--- g26.orig/include/asm-generic/gpio.h 2008-02-10 16:06:30.0 -0800
+++ g26/include/asm-generic/gpio.h 2008-02-10 16:18:30.0 -0800
@@ -17,6 +17,7 @@
#endif
struct seq_file;
+struct module;
/**
* struct gpio_chip - abstract a GPIO controller
@@ -48,6 +49,7 @@ struct seq_file;
*/
struct gpio_chip {
char*label;
+ struct module *owner;
int (*direction_input)(struct gpio_chip *chip,
unsigned offset);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make /dev/kmem a config option
On Feb 10 2008 15:55, Arjan van de Ven wrote:
>+#ifdef CONFIG_DEVKMEM
> /*
> * This function reads the *virtual* memory as seen by the kernel.
> */
>@@ -585,6 +588,11 @@ static ssize_t write_kmem(struct file * file, const char
>__user * buf,
> *ppos = p;
> return virtr + wrote;
> }
>+#else
>+#define read_kmem NULL
>+#define write_kmem NULL
>+#define mmap_kmem NULL
>+#endif
Is the #else case needed? All kmem_fops uses seem #ifdef'ed out anyway,
except kmem_fops itself. In other words,
+#ifdef CONFIG_DEVKMEM
static const struct file_operations kmem_fops = {
...
}
+#endif
and do away with the three defines. No? :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.24.x-stable request for 69f817b654d683265118188bbfb8bc0d8978cce6 and ece8edddf067d21c4e5abfe3f1205da1588edbb2
Hi; On 2.6.24.1-stable kernel review cycle, i requested inclusions of commit 69f817b654d683265118188bbfb8bc0d8978cce6 (mac80211: Restore rx.fc before every invocation of ieee80211_invoke_rx_handlers) and ece8edddf067d21c4e5abfe3f1205da1588edbb2 (mac80211: hardware scan rework) into -stable one (they solved disable_hw_scan=1 workaround for wpa_secured hidden AP problem). And -stable team said they would rather these comes from either the wireless maintainer or the network maintainer to verify that they are needed, and the backports works properly. So, if possible, could you please consider sending these to -stable? Cheers -- S.Çağlar Onur <[EMAIL PROTECTED]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] make /dev/kmem a config option
Subject: [PATCH] make /dev/kmem a config option
From: Arjan van de Ven <[EMAIL PROTECTED]>
This patch makes /dev/kmem a config option; /dev/kmem is VERY rarely
used, and when used, it's generally for no good (rootkits tend to be
the most common users). With this config option, users have the
choice to disable /dev/kmem, saving some size as well.
A patch to disable /dev/kmem has been in the Fedora and RHEL kernels for
4+ years now without any known problems or legit users of /dev/kmem.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
drivers/char/Kconfig |8
drivers/char/mem.c | 12
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 4666295..7716af0 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -80,6 +80,14 @@ config VT_HW_CONSOLE_BINDING
information. For framebuffer console users, please refer to
.
+config DEV_KMEM
+ bool "/dev/kmem virtual device support"
+ help
+ Say Y here if you want to support the /dev/kmem device. The
+ /dev/kmem device is rarely used, but can be used for certain
+ kind of kernel debugging operations.
+ When in doubt, say "N".
+
config SERIAL_NONSTANDARD
bool "Non-standard serial port support"
depends on HAS_IOMEM
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 3745e6b..49c5fac 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -323,6 +323,7 @@ static int mmap_mem(struct file * file, struct
vm_area_struct * vma)
return 0;
}
+#ifdef CONFIG_DEVKMEM
static int mmap_kmem(struct file * file, struct vm_area_struct * vma)
{
unsigned long pfn;
@@ -343,6 +344,7 @@ static int mmap_kmem(struct file * file, struct
vm_area_struct * vma)
vma->vm_pgoff = pfn;
return mmap_mem(file, vma);
}
+#endif
#ifdef CONFIG_CRASH_DUMP
/*
@@ -381,6 +383,7 @@ static ssize_t read_oldmem(struct file *file, char __user
*buf,
extern long vread(char *buf, char *addr, unsigned long count);
extern long vwrite(char *buf, char *addr, unsigned long count);
+#ifdef CONFIG_DEVKMEM
/*
* This function reads the *virtual* memory as seen by the kernel.
*/
@@ -585,6 +588,11 @@ static ssize_t write_kmem(struct file * file, const char
__user * buf,
*ppos = p;
return virtr + wrote;
}
+#else
+#define read_kmem NULL
+#define write_kmem NULL
+#define mmap_kmem NULL
+#endif
#ifdef CONFIG_DEVPORT
static ssize_t read_port(struct file * file, char __user * buf,
@@ -848,11 +856,13 @@ static int memory_open(struct inode * inode, struct file
* filp)
filp->f_mapping->backing_dev_info =
_mappable_cdev_bdi;
break;
+#ifdef CONFIG_DEVKMEM
case 2:
filp->f_op = _fops;
filp->f_mapping->backing_dev_info =
_mappable_cdev_bdi;
break;
+#endif
case 3:
filp->f_op = _fops;
break;
@@ -901,7 +911,9 @@ static const struct {
const struct file_operations*fops;
} devlist[] = { /* list of minor devices */
{1, "mem", S_IRUSR | S_IWUSR | S_IRGRP, _fops},
+#ifdef CONFIG_DEVKMEM
{2, "kmem",S_IRUSR | S_IWUSR | S_IRGRP, _fops},
+#endif
{3, "null",S_IRUGO | S_IWUGO, _fops},
#ifdef CONFIG_DEVPORT
{4, "port",S_IRUSR | S_IWUSR | S_IRGRP, _fops},
--
1.5.3.4
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git patches] IDE fixes
Hi,
We merged _a_lot_ of IDE patches for 2.6.25 so no wonder that a few bugs
showed up (yes, mostly brown paper ones of mine :). This update should
put it under control again (there are two more open regression bugreports
left and they are going to be addressed as soon as we have more data).
- fix nasty bug in handling of flush requests (extra thanks to Sebastian
Siewior / James Bottomley / Christoph Hellwig for help with fixing it)
- fix ide_port_init() regression (spotted by Atsushi Nemoto)
- fix build of bast-ide of gayle host drivers (Adrian Bunk)
- fixes for Palm BK3710 support (Sergei Shtylyov and me)
- fix another possible ide-cd panic (Kiyoshi Ueda)
- other minor fixes
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
to receive the following updates:
drivers/ide/Kconfig| 26 --
drivers/ide/arm/bast-ide.c | 12 ++
drivers/ide/arm/palm_bk3710.c | 74 ---
drivers/ide/ide-cd.c |2 +-
drivers/ide/ide-disk.c | 18 ++
drivers/ide/ide-dma.c | 14
drivers/ide/ide-io.c | 19 ++
drivers/ide/ide-iops.c | 10 +
drivers/ide/ide-lib.c |9 -
drivers/ide/ide-probe.c|4 +-
drivers/ide/ide-tape.c | 34 --
drivers/ide/ide.c |4 +--
drivers/ide/legacy/gayle.c |2 +-
drivers/ide/pci/cs5520.c |5 ---
drivers/ide/pci/pdc202xx_old.c | 22
include/linux/ide.h| 11 +++---
16 files changed, 107 insertions(+), 159 deletions(-)
Adrian Bunk (1):
ide: fix ide/legacy/gayle.c compilation
Bartlomiej Zolnierkiewicz (12):
palm_bk3710: ide_register_hw() -> ide_device_add()
palm_bk3710: fix ide_unregister() usage
palm_bk3710: port initialization/probing bugfix
palm_bk3710: use struct ide_port_info
pdc202xx_old: always enable burst mode
ide: remove stale version number
ide-tape: remove never executed code
bast-ide: build fix
ide-disk: fix flush requests (take 2)
ide: ide_init_port() bugfix
ide: fix comment in init_irq()
ide: remove stale comment from ide-lib.c
Benjamin Herrenschmidt (1):
cs5520: remove stale comment
Borislav Petkov (1):
ide-cd: replace ntohs with generic byteorder macro be16_to_cpu
Kiyoshi Ueda (1):
ide: another possible ide panic fix for blk-end-request
Sergei Shtylyov (2):
ide: insert BUG_ON() into __ide_set_handler() (take 2)
ide: introduce CONFIG_BLK_DEV_IDEDMA_SFF option
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index 043c34a..df752e6 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -378,6 +378,9 @@ config BLK_DEV_IDEPNP
would like the kernel to automatically detect and activate
it, say Y here.
+config BLK_DEV_IDEDMA_SFF
+ bool
+
if PCI
comment "PCI IDE chipsets support"
@@ -459,6 +462,7 @@ config BLK_DEV_RZ1000
config BLK_DEV_IDEDMA_PCI
bool
select BLK_DEV_IDEPCI
+ select BLK_DEV_IDEDMA_SFF
config BLK_DEV_AEC62XX
tristate "AEC62XX chipset support"
@@ -688,23 +692,6 @@ config BLK_DEV_PDC202XX_OLD
If unsure, say N.
-config PDC202XX_BURST
- bool "Special UDMA Feature"
- depends on BLK_DEV_PDC202XX_OLD
- help
- This option causes the pdc202xx driver to enable UDMA modes on the
- PDC202xx even when the PDC202xx BIOS has not done so.
-
- It was originally designed for the PDC20246/Ultra33, whose BIOS will
- only setup UDMA on the first two PDC20246 cards. It has also been
- used successfully on a PDC20265/Ultra100, allowing use of UDMA modes
- when the PDC20265 BIOS has been disabled (for faster boot up).
-
- Please read the comments at the top of
- .
-
- If unsure, say N.
-
config BLK_DEV_PDC202XX_NEW
tristate "PROMISE PDC202{68|69|70|71|75|76|77} support"
select BLK_DEV_IDEDMA_PCI
@@ -1016,7 +1003,7 @@ config BLK_DEV_Q40IDE
config BLK_DEV_PALMCHIP_BK3710
tristate "Palmchip bk3710 IDE controller support"
depends on ARCH_DAVINCI
- select BLK_DEV_IDEDMA_PCI
+ select BLK_DEV_IDEDMA_SFF
help
Say Y here if you want to support the onchip IDE controller on the
TI DaVinci SoC
@@ -1124,7 +,8 @@ config BLK_DEV_UMC8672
endif
config BLK_DEV_IDEDMA
- def_bool BLK_DEV_IDEDMA_PCI || BLK_DEV_IDEDMA_PMAC ||
BLK_DEV_IDEDMA_ICS || BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA
+ def_bool BLK_DEV_IDEDMA_SFF || BLK_DEV_IDEDMA_PMAC || \
+BLK_DEV_IDEDMA_ICS || BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA
config IDE_ARCH_OBSOLETE_INIT
def_bool ALPHA || (ARM && !ARCH_L7200) || BLACKFIN || X86 || IA64 ||
M32R || MIPS || PARISC || PPC || (SUPERH64 && BLK_DEV_IDEPCI) || SPARC
diff --git a/drivers/ide/arm/bast-ide.c
[PATCH] Documentation: prune redundant SubmitChecklist items
From: J. Bruce Fields <[EMAIL PROTECTED]> Kernel style is mentioned twice, and the git apply trick is a bit redundant given the checkpatch.pl recommendation (which also checks for bad whitespace). Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]> --- Documentation/SubmitChecklist | 16 +--- 1 files changed, 5 insertions(+), 11 deletions(-) diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index 34e06d2..da10e07 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist @@ -20,7 +20,11 @@ kernel patches. 4: ppc64 is a good architecture for cross-compilation checking because it tends to use `unsigned long' for 64-bit quantities. -5: Matches kernel coding style(!) +5: Check your patch for general style as detailed in + Documentation/CodingStyle. Check for trivial violations with the + patch style checker prior to submission (scripts/checkpatch.pl). + You should be able to justify all violations that remain in + your patch. 6: Any new or modified CONFIG options don't muck up the config menu. @@ -79,13 +83,3 @@ kernel patches. 23: Tested after it has been merged into the -mm patchset to make sure that it still works with all of the other queued patches and various changes in the VM, VFS, and other subsystems. - -24: Avoid whitespace damage such as indenting with spaces or whitespace -at the end of lines. You can test this by feeding the patch to -"git apply --check --whitespace=error-all" - -25: Check your patch for general style as detailed in -Documentation/CodingStyle. Check for trivial violations with the -patch style checker prior to submission (scripts/checkpatch.pl). -You should be able to justify all violations that remain in -your patch. -- 1.5.4.rc2.60.gb2e62 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi_error: Fix language abuse.
On Sat, Feb 09, 2008 at 01:50:20PM +, Alan Cox wrote: > On Fri, 08 Feb 2008 20:32:54 -0500 Douglas Gilbert <[EMAIL PROTECTED]> wrote: > > Alan Cox wrote: > > > The word "illegal" has a precise dictionary meaning of "prohibited by > > > law". > > > > Also "contrary to or forbidden by official rules, regulations, etc". > > The OED I have here doesn't seem to think so, however if the words are > the ones used in the T10 documentation then I'm happy to drop the patch. Not everyone believes in the OED's definitions. I prefer Chambers (in general), which has the (online) definition: illegal adj 1 against the law; not legal. Also called unlawful. 2 not authorized by law or by specific rules which apply. ETYMOLOGY: 17c: from Latin illegalis. I believe the second definition would apply here. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Silent compiler warning introduced by commit 801c135ce73d5df1caf3eca35b66a10824ae0707 (UBI: Unsorted Block Images)
Hi;
10 Şub 2008 Paz tarihinde, Jiri Slaby şunları yazmıştı:
> I think this is not correct. You change the err which caused the failure. You
> change it even to 0 if it doesn't fail and the whole function will seem like
> non-failing.
My bad, sorry for not looking carefully. Assuming a refactoring is not desired
for just a compiler warning, is following acceptable (this kind of plain
messages seems heavily used in vmt.c, so i'm again assuming its OK to use such
style)?
commit 801c135ce73d5df1caf3eca35b66a10824ae0707 (UBI: Unsorted Block Images)
introduced the warning
drivers/mtd/ubi/vmt.c: In function `ubi_create_volume':
drivers/mtd/ubi/vmt.c:379: warning: statement with no effect
drivers/mtd/ubi/vmt.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/ubi/vmt.c b/drivers/mtd/ubi/vmt.c
index a3ca225..46410f6 100644
--- a/drivers/mtd/ubi/vmt.c
+++ b/drivers/mtd/ubi/vmt.c
@@ -376,7 +376,8 @@ out_sysfs:
get_device(>dev);
volume_sysfs_close(vol);
out_gluebi:
- ubi_destroy_gluebi(vol);
+ if(ubi_destroy_gluebi(vol))
+ ubi_err("cannot destroy device");
out_cdev:
cdev_del(>cdev);
out_mapping:
Cheers
--
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] splice: fix user pointer access in get_iovec_page_array()
On Sun, Feb 10, 2008 at 04:47:57PM +0200, Pekka J Enberg wrote:
> From: Bastian Blank <[EMAIL PROTECTED]>
>
> The commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user
> pointer access verification") added access_ok() to copy_from_user_mmap_sem()
> which only ensures we can copy the struct iovecs from userspace to the kernel
> but we also must check whether we can access the actual memory region pointed
> to by the struct iovec to close the local root exploit.
>
> Cc: <[EMAIL PROTECTED]>
> Cc: Jens Axboe <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
> ---
> Bastian, can I have your Signed-off-by for this, please? Oliver, Niki, can
> you please confirm this closes the hole?
Pekka, I confirm that it also closes the hole once backported to 2.6.22.
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: I/O collisions w/ hwmon/it87.c and watchdog/it8712f_wdt.c? (Super I/O chips in general..)
Does it make sense to use the drivers/mfd directory for Super I/O chips then? Is there any problem with having other hwmon, watchdog, etc depend on drivers/mfd? Should this kind of setup for platform devices be documented in the driver-model? -Andrew On Feb 10, 2008 6:05 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > > Since these chips touch many different parts of traditionally separate > > driver areas, how should the drivers be structured so that they can > > all talk to the chip? Should the low level communications routines for > > the chip live in a library which all the drivers could use? > > Probably yes. And that if possible should manage all the locking. Thats > roughly how the majority of drivers do it. Some export the lock from base > code and inline the accessors depending how complex it is. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] sparc: fix build
Fix build failures on sparc: In file included from include/linux/mm.h:39, from include/linux/memcontrol.h:24, from include/linux/swap.h:8, from include/linux/suspend.h:7, from init/do_mounts.c:6: include/asm/pgtable.h:344: warning: parameter names (without types) in function declaration include/asm/pgtable.h:345: warning: parameter names (without types) in function declaration include/asm/pgtable.h:346: error: expected '=', ',', ';', 'asm' or '__attribute__' before '___f___swp_entry' and arch/sparc/kernel/led.c: In function 'led_blink': arch/sparc/kernel/led.c:35: error: invalid use of undefined type 'struct timer_list' arch/sparc/kernel/led.c:35: error: 'jiffies' undeclared (first use in this function) arch/sparc/kernel/led.c:35: error: (Each undeclared identifier is reported only once arch/sparc/kernel/led.c:35: error: for each function it appears in.) arch/sparc/kernel/led.c:36: error: 'avenrun' undeclared (first use in this function) arch/sparc/kernel/led.c:36: error: 'FSHIFT' undeclared (first use in this function) arch/sparc/kernel/led.c:36: error: 'HZ' undeclared (first use in this function) arch/sparc/kernel/led.c:37: error: invalid use of undefined type 'struct timer_list' arch/sparc/kernel/led.c:39: error: invalid use of undefined type 'struct timer_list' arch/sparc/kernel/led.c:40: error: invalid use of undefined type 'struct timer_list' arch/sparc/kernel/led.c:42: error: implicit declaration of function 'add_timer' arch/sparc/kernel/led.c: In function 'led_write_proc': arch/sparc/kernel/led.c:70: error: implicit declaration of function 'copy_from_user' arch/sparc/kernel/led.c:84: error: implicit declaration of function 'del_timer_sync' arch/sparc/kernel/led.c: In function 'led_init': arch/sparc/kernel/led.c:109: error: implicit declaration of function 'init_timer' arch/sparc/kernel/led.c:110: error: invalid use of undefined type 'struct timer_list' Cc: Adrian Bunk <[EMAIL PROTECTED]> Cc: Robert Reif <[EMAIL PROTECTED]> Signed-off-by: David Rientjes <[EMAIL PROTECTED]> --- arch/sparc/kernel/led.c|3 ++- include/linux/memcontrol.h |3 --- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/sparc/kernel/led.c b/arch/sparc/kernel/led.c --- a/arch/sparc/kernel/led.c +++ b/arch/sparc/kernel/led.c @@ -1,8 +1,9 @@ -#include #include #include #include #include +#include +#include #include diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -20,9 +20,6 @@ #ifndef _LINUX_MEMCONTROL_H #define _LINUX_MEMCONTROL_H -#include -#include - struct mem_cgroup; struct page_cgroup; struct page; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
nfsd fixes for 2.6.25
The following changes are available from the for-linus branch of the git repository at: git://linux-nfs.org/~bfields/linux.git for-linus The four patches from Jeff Layton fix a bug that can allow an unresponsive client to hang lockd. The other two patches are minor compile fixes. --b. J. Bruce Fields (1): nfsd: clean up svc_reserve_auth() Jeff Layton (4): NLM: set RPC_CLNT_CREATE_NOPING for NLM RPC clients NLM: have server-side RPC clients default to soft RPC tasks NLM: don't reattempt GRANT_MSG when there is already an RPC in flight NLM: don't requeue block if it was invalidated while GRANT_MSG was in flight Roland Dreier (1): SUNPRC: Fix printk format warning fs/lockd/host.c | 10 +- fs/lockd/svclock.c| 28 include/linux/sunrpc/svc.h| 13 + net/sunrpc/xprtrdma/svc_rdma_sendto.c |3 ++- 4 files changed, 40 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi_error: Fix language abuse.
Alan Cox wrote: On Fri, 08 Feb 2008 20:32:54 -0500 Douglas Gilbert <[EMAIL PROTECTED]> wrote: Alan Cox wrote: The word "illegal" has a precise dictionary meaning of "prohibited by law". Also "contrary to or forbidden by official rules, regulations, etc". The OED I have here doesn't seem to think so, however if the words are the ones used in the T10 documentation then I'm happy to drop the patch. The OED (Oxford English dictionary) seems to be at odds with most other online dictionaries with respect to the word illegal. I find the following 'illegal' entry (at www.askoxford.com) daft: "USAGE Both illegal and unlawful can mean 'contrary to or forbidden by law', but unlawful has a broader meaning 'not permitted by rules': thus handball in soccer is unlawful, but not illegal." So if we followed the OED's advice then SCSI's "illegal request" would become "unlawful request". I'm yet to see the word "unlawful" in any technical standard ... Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ide: remove stale comment from ide-lib.c
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-lib.c |9 -
1 file changed, 9 deletions(-)
Index: b/drivers/ide/ide-lib.c
===
--- a/drivers/ide/ide-lib.c
+++ b/drivers/ide/ide-lib.c
@@ -21,15 +21,6 @@
#include
#include
-/*
- * IDE library routines. These are plug in code that most
- * drivers can use but occasionally may be weird enough
- * to want to do their own thing with
- *
- * Add common non I/O op stuff here. Make sure it has proper
- * kernel-doc function headers or your patch will be rejected
- */
-
static const char *udma_str[] =
{ "UDMA/16", "UDMA/25", "UDMA/33", "UDMA/44",
"UDMA/66", "UDMA/100", "UDMA/133", "UDMA7" };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ide: fix comment in init_irq()
APUS support is gone... Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> --- drivers/ide/ide-probe.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/drivers/ide/ide-probe.c === --- a/drivers/ide/ide-probe.c +++ b/drivers/ide/ide-probe.c @@ -1051,7 +1051,7 @@ static int init_irq (ide_hwif_t *hwif) int sa = 0; #if defined(__mc68000__) sa = IRQF_SHARED; -#endif /* __mc68000__ || CONFIG_APUS */ +#endif /* __mc68000__ */ if (IDE_CHIPSET_IS_PCI(hwif->chipset)) sa = IRQF_SHARED; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] ide: add struct ide_port_info instances to legacy host drivers
On Sunday 10 February 2008, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 10 February 2008, Atsushi Nemoto wrote:
> > On Sun, 06 Jan 2008 18:03:10 +0100, Bartlomiej Zolnierkiewicz <[EMAIL
> > PROTECTED]> wrote:
> > > + /* reset DMA masks only for SFF-style DMA controllers */
> > > + if ((d->host_flags && IDE_HFLAG_NO_DMA) == 0 && hwif->dma_base == 0)
> > > + hwif->swdma_mask = hwif->mwdma_mask = hwif->ultra_mask = 0;
> >
> > It might be too late, but "host_flags && IDE_HFLAGS_NO_DMA" seems
> > wrong for me.
>
> It is too late for -git but not too late for 2.6.25-rc1. ;-)
>
> Could you make a patch please?
I went ahead and made a patch (sorry, I needed it for git pull request :).
From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Subject: [PATCH] ide: ide_init_port() bugfix
On Sunday 10 February 2008, Atsushi Nemoto wrote:
> On Sun, 06 Jan 2008 18:03:10 +0100, Bartlomiej Zolnierkiewicz <[EMAIL
> PROTECTED]> wrote:
> > + /* reset DMA masks only for SFF-style DMA controllers */
> > + if ((d->host_flags && IDE_HFLAG_NO_DMA) == 0 && hwif->dma_base == 0)
> > + hwif->swdma_mask = hwif->mwdma_mask = hwif->ultra_mask = 0;
>
> It might be too late, but "host_flags && IDE_HFLAGS_NO_DMA" seems
> wrong for me.
Fix regression caused by commmit c413b9b94d9a8e7548cc4b2e04b7df0439ce76fd
("ide: add struct ide_port_info instances to legacy host drivers").
Reported-by: Atsushi Nemoto <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-probe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/ide/ide-probe.c
===
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -1355,7 +1355,7 @@ static void ide_init_port(ide_hwif_t *hw
hwif->ultra_mask = d->udma_mask;
/* reset DMA masks only for SFF-style DMA controllers */
- if ((d->host_flags && IDE_HFLAG_NO_DMA) == 0 && hwif->dma_base == 0)
+ if ((d->host_flags & IDE_HFLAG_NO_DMA) == 0 && hwif->dma_base == 0)
hwif->swdma_mask = hwif->mwdma_mask = hwif->ultra_mask = 0;
if (d->host_flags & IDE_HFLAG_RQSIZE_256)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: I/O collisions w/ hwmon/it87.c and watchdog/it8712f_wdt.c? (Super I/O chips in general..)
> Since these chips touch many different parts of traditionally separate > driver areas, how should the drivers be structured so that they can > all talk to the chip? Should the low level communications routines for > the chip live in a library which all the drivers could use? Probably yes. And that if possible should manage all the locking. Thats roughly how the majority of drivers do it. Some export the lock from base code and inline the accessors depending how complex it is. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] x86 updates
* Thomas Gleixner <[EMAIL PROTECTED]> wrote: > On Sun, 10 Feb 2008, Linus Torvalds wrote: > > On Sat, 9 Feb 2008, Randy Dunlap wrote: > > > > So Thomas, don't do this. I don't like it. The same way I didn't like > > seeing Ingo trying to mix in a kgdb pull into his x86 pull. Keep these > > things separate - git is *really* good at having multiple branches with > > different lines of development, use it that way (or send odd-ball misc > > patches just as emails). > > Please accept my apologies. > > I went through the content, pointed out the other two non x86 patches > and did not notice the vsprintf one. My bad. and i'd like to apologize for the misleading Subject line which said "Subject: x86: ...". That i think made us miss the generic impact later on (we remind ourselves about non-arch/x86 patches via Subject line annotations and via looking at the diffstat before pull requests), and the accidentally missing diffstat just removed the last-line defense against such annotation mistakes. btw., i was -->.<--- this close to removing this patch from x86.git altogether - because it had a bug (which already shows its non-obviousness) and i didnt think this complication was worth it. When that happened i took a really hard look at its correctness and worthiness and narrowly decided to keep it - but enforced an unusually long testing interval for this patch. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] SH/Dreamcast - joystick (controlpad)
Changes to the Kconfig and Makefile needed to build the Maple controlpad code. Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]> == diff --combined drivers/input/joystick/Kconfig index 7c662ee,7c662ee..3566fa2 --- a/drivers/input/joystick/Kconfig +++ b/drivers/input/joystick/Kconfig @@@ -282,4 -282,4 +282,17 @@@ config JOYSTICK_XPAD_LED This option enables support for the LED which surrounds the Big X on XBox 360 controller. +config JOYSTICK_MAPLE + tristate "Dreamcast control pad" + depends on SH_DREAMCAST + select MAPLE + help +Say Y here if you have a SEGA Dreamcast and want to use your +controller. + +Most Dreamcast users will say Y. + +To compile this as a module choose M here: the +module will be called maplecontrol. + endif diff --combined drivers/input/joystick/Makefile index e855abb,e855abb..62929ef --- a/drivers/input/joystick/Makefile +++ b/drivers/input/joystick/Makefile @@@ -27,5 -27,5 +27,6 @@@ obj-$(CONFIG_JOYSTICK_TURBOGRAFX) += tu obj-$(CONFIG_JOYSTICK_TWIDJOY)+= twidjoy.o obj-$(CONFIG_JOYSTICK_WARRIOR)+= warrior.o obj-$(CONFIG_JOYSTICK_XPAD) += xpad.o + obj-$(CONFIG_JOYSTICK_MAPLE) += maplecontrol.o obj-$(CONFIG_JOYSTICK_IFORCE) += iforce/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
raw_pci_read in quirk_intel_irqbalance
On Sun, Feb 10, 2008 at 01:45:57PM -0700, Matthew Wilcox wrote: > I just looked at fixing that -- the reason seems to be that we don't > actually have the struct pci_dev at that point. I can fix it, but I > think it's actually buggy. I want to look at some chipset docs to > confirm that though. I don't think I fully understand what's going on here. So here's what I've been able to glean; hopefully someone who understands this better can help out. I happen to have an E7525-based machine, so here's an lspci of bus 0: 00:00.0 Host bridge: Intel Corporation E7525 Memory Controller Hub (rev 0a) 00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 0a) 00:03.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A1 (rev 0a) 00:04.0 PCI bridge: Intel Corporation E7525/E7520 PCI Express Port B (rev 0a) 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801EB (ICH5) SATA Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) The line in question reads: /* read xTPR register */ raw_pci_read(0, 0, 0x40, 0x4c, 2, ); That's domain 0, bus 0, device 8, function 0, address 0x4c, length 2. I've checked the public E7525 and E7520 MCH datasheets, and they don't document the xTPR registers; nor do any of the devices in the datasheet have registers documented at 0x4c. You can see from my lspci above that I don't _have_ a device 8 on bus 0. The aforementioned documentation says: "A disabled or non-existent device's configuration register space is hidden. A disabled or non-existent device will return all ones for reads and will drop writes just as if the cycle terminated with a Master Abort on PCI." Now, my E7525 isn't affected by this quirk as it has a revision greater than 0x9. So maybe it's expected that device 8 is hidden on my machine; that it's only present on revisions up to 0x9. But maybe device 8 is always hidden, and that's why the author used raw_pci_ops? We can still do better than this, though. We can do: - raw_pci_read(0, 0, 0x40, 0x4c, 2, ); + pci_bus_read_config_word(dev->bus, PCI_DEVFN(8, 0), 0x4c, ); Using PCI_DEVFN tells people you really did mean device 8, and it's not a braino for device 4 or 2 (how many bits for slot and function again?) I'll see if I can dig up the internal documentation for the xTPR register when I'm at work on Monday. But I've never gone looking for internal documentation before, so I have no idea how easy it will be to find ;-) -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: remove over noisy debug printk
pageattr-test.c contains a noisy debug printk that people reported.
The condition under which it prints (randomly tapping into a mem_map[]
hole and not being able to c_p_a() there) is valid behavior and not
interesting to report.
Remove it.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/mm/pageattr-test.c |7 ---
1 file changed, 7 deletions(-)
Index: linux-2.6/arch/x86/mm/pageattr-test.c
===
--- linux-2.6.orig/arch/x86/mm/pageattr-test.c
+++ linux-2.6/arch/x86/mm/pageattr-test.c
@@ -40,7 +40,6 @@ struct split_state {
static int print_split(struct split_state *s)
{
long i, expected, missed = 0;
- int printed = 0;
int err = 0;
s->lpg = s->gpg = s->spg = s->exec = 0;
@@ -53,12 +52,6 @@ static int print_split(struct split_stat
pte = lookup_address(addr, );
if (!pte) {
- if (!printed) {
- dump_pagetable(addr);
- printk(KERN_INFO "CPA %lx no pte level %d\n",
- addr, level);
- printed = 1;
- }
missed++;
i++;
continue;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] SH/Dreamcast - joystick (Control pad)
Adds support for the Dreamcast control pad.
This is a port of the 2.4 driver (never in mainline) by Yaegashi
Takeshi.
Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>
==
--- /dev/null 2007-10-16 19:02:41.0 +0100
+++ drivers/input/joystick/maplecontrol.c 2008-02-10 22:50:17.0
+
@@ -0,0 +1,215 @@
+/*
+ * SEGA Dreamcast controller driver
+ * Based on drivers/usb/iforce.c
+ *
+ * Copyright Yaegashi Takeshi, 2001
+ * Ported to 2.6 by Adrian McMenamin, 2008
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("YAEGASHI Takeshi <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("SEGA Dreamcast controller driver");
+MODULE_LICENSE("GPL");
+
+struct dc_pad {
+ struct input_dev *dev;
+ int open;
+};
+
+static void dc_pad_callback(struct mapleq *mq)
+{
+ unsigned short buttons;
+ struct maple_device *mapledev = mq->dev;
+ struct dc_pad *pad = mapledev->private_data;
+ struct input_dev *dev = pad->dev;
+ unsigned char *res = mq->recvbuf;
+
+ buttons = ~*(unsigned short *)(res+8);
+
+ input_report_abs(dev, ABS_HAT0Y,
+(buttons & 0x0010 ? -1:0) + (buttons & 0x0020 ? 1:0));
+ input_report_abs(dev, ABS_HAT0X,
+(buttons & 0x0040 ? -1:0) + (buttons & 0x0080 ? 1:0));
+ input_report_abs(dev, ABS_HAT1Y,
+(buttons & 0x1000 ? -1:0) + (buttons & 0x2000 ? 1:0));
+ input_report_abs(dev, ABS_HAT1X,
+(buttons & 0x4000 ? -1:0) + (buttons & 0x8000 ? 1:0));
+
+ input_report_key(dev, BTN_C, buttons & 0x0001);
+ input_report_key(dev, BTN_B, buttons & 0x0002);
+ input_report_key(dev, BTN_A, buttons & 0x0004);
+ input_report_key(dev, BTN_START, buttons & 0x0008);
+ input_report_key(dev, BTN_Z, buttons & 0x0100);
+ input_report_key(dev, BTN_Y, buttons & 0x0200);
+ input_report_key(dev, BTN_X, buttons & 0x0400);
+ input_report_key(dev, BTN_SELECT, buttons & 0x0800);
+
+ input_report_abs(dev, ABS_GAS, res[10]);
+ input_report_abs(dev, ABS_BRAKE, res[11]);
+ input_report_abs(dev, ABS_X, res[12]);
+ input_report_abs(dev, ABS_Y, res[13]);
+ input_report_abs(dev, ABS_RX,res[14]);
+ input_report_abs(dev, ABS_RY,res[15]);
+}
+
+static int dc_pad_open(struct input_dev *dev)
+{
+ struct dc_pad *pad = dev->private;
+ pad->open++;
+ return 0;
+}
+
+static void dc_pad_close(struct input_dev *dev)
+{
+ struct dc_pad *pad = dev->private;
+ pad->open--;
+}
+
+static int dc_pad_connect(struct maple_device *mdev)
+{
+ int i, error;
+ unsigned long data = be32_to_cpu(mdev->devinfo.function_data[0]);
+ struct dc_pad *pad;
+ struct input_dev *dev;
+
+ const short btn_bit[32] = {
+ BTN_C, BTN_B, BTN_A, BTN_START, -1, -1, -1, -1,
+ BTN_Z, BTN_Y, BTN_X, BTN_SELECT, -1, -1, -1, -1,
+ -1, -1, -1, -1, -1, -1, -1, -1,
+ -1, -1, -1, -1, -1, -1, -1, -1,
+ };
+
+ const short abs_bit[32] = {
+ -1, -1, -1, -1, ABS_HAT0Y, ABS_HAT0Y, ABS_HAT0X, ABS_HAT0X,
+ -1, -1, -1, -1, ABS_HAT1Y, ABS_HAT1Y, ABS_HAT1X, ABS_HAT1X,
+ ABS_GAS, ABS_BRAKE, ABS_X, ABS_Y, ABS_RX, ABS_RY, -1, -1,
+ -1, -1, -1, -1, -1, -1, -1, -1,
+ };
+
+ pad = kzalloc(sizeof(struct dc_pad), GFP_KERNEL);
+ if (!pad)
+ return -ENOMEM;
+
+ dev = input_allocate_device();
+ if (!dev) {
+ kfree(pad);
+ return -ENOMEM;
+ }
+
+ pad->dev = dev;
+
+ mdev->private_data = pad;
+
+ for (i = 0; i < 32; i++)
+ if (data & (1<= 0)
+ pad->dev->keybit[BTN_JOYSTICK/32] |= BIT(btn_bit[i]);
+
+ if (pad->dev->keybit[BTN_JOYSTICK/32])
+ pad->dev->evbit[0] |= BIT(EV_KEY);
+
+ for (i = 0; i < 32; i++)
+ if (data&(1<= 0)
+ pad->dev->absbit[0] |= BIT(abs_bit[i]);
+
+ if (pad->dev->absbit[0])
+ pad->dev->evbit[0] |= BIT(EV_ABS);
+
+ for (i = ABS_X; i <= ABS_BRAKE; i++) {
+ pad->dev->absmax[i] = 255;
+ pad->dev->absmin[i] = 0;
+ pad->dev->absfuzz[i] = 0;
+ pad->dev->absflat[i] = 0;
+ }
+
+ for (i = ABS_HAT0X; i <= ABS_HAT3Y; i++) {
+ pad->dev->absmax[i] = 1;
+ pad->dev->absmin[i] = -1;
+ pad->dev->absfuzz[i] = 0;
+ pad->dev->absflat[i] = 0;
+ }
+
+ pad->dev->private = pad;
+ pad->dev->open = dc_pad_open;
+ pad->dev->close = dc_pad_close;
+ pad->dev->event = NULL;
+ pad->dev->dev.parent = >dev;
+ pad->dev->name = mdev->product_name;
+ pad->dev->id.bustype = BUS_HOST;
+
Re: scsi/arm/fas216.c compile error
On Sun, 2008-02-10 at 22:02 +, Russell King wrote:
> On Sun, Feb 10, 2008 at 08:20:24AM -0600, James Bottomley wrote:
> >
> > On Sun, 2008-02-10 at 13:58 +, Russell King wrote:
> > > On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
> > > > It's in mainline 84ac86ca8c6787f9efff28bc04b1b65fe0a5c310
> > > > [SCSI] arm: convert to accessors and !use_sg cleanup
> > > >
> > > > Thanks for checking. This patch was in scsi-pending tree since forever,
> > > > And we were unable
> > > > to get a responsive maintainer to ACK on them. until the breakage cause
> > > > went into mainline
> > > > we finally managed a Tested-by:.
> > > >
> > > > I guess sometimes people are so busy, you need a bulldozer to shove 20
> > > > minutes into they're
> > > > schedule.
> > >
> > > Oh, I was ill for most of December, particularly at the time that you
> > > sent the patch, and by the time I recovered, it was buried in my mailbox.
> > >
> > > Suggest you have some consideration for others who might not be able to
> > > do your beg and call at the immediate moment that you want it, and
> > > consider that their email management skills may not be as l33t as yours.
> >
> > OK, sorry about this, it's a bit of a cockup all around. The patch that
> > fixes this problem is still in SCSI pending largely because it's patch
> > description:
> >
> > [SCSI] fas216: Use scsi_eh API for REQUEST_SENSE invocation
> >
> > Doesn't lead one to think it might be build critical, so I concentrated
> > on getting the other arm patch out.
> >
> > Russell, could you give it a quick test, and I'll put it in with a
> > tested-by tag?
>
> It's not looking good:
>
> CC drivers/scsi/arm/fas216.o
> drivers/scsi/arm/fas216.c: In function `fas216_rq_sns_done':
> drivers/scsi/arm/fas216.c:2021: warning: passing arg 2 of
> `scsi_eh_restore_cmnd' from incompatible pointer type
> drivers/scsi/arm/fas216.c: In function `fas216_std_done':
> drivers/scsi/arm/fas216.c:2107: warning: passing arg 2 of `scsi_eh_prep_cmnd'
> from incompatible pointer type
>
> Since the second argument of scsi_eh_prep_cmnd is 'struct scsi_eh_save *ses'
> this patch is most definitely bad. Not even booted it.
Yes, there looks to be a fatal screw up in the definition in
FAS216_Info. Could you try this ... I think I've corrected it.
James
---
>From 35be7297dc581b42c05ea7751ee595b0ce78f669 Mon Sep 17 00:00:00 2001
From: Boaz Harrosh <[EMAIL PROTECTED]>
Date: Mon, 10 Sep 2007 22:39:11 +0300
Subject: [SCSI] fas216: Use scsi_eh API for REQUEST_SENSE invocation
- Use new scsi_eh_prep/restor_cmnd() for synchronous
REQUEST_SENSE invocation.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
Cc: Russell King <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/arm/fas216.c | 16 +++-
drivers/scsi/arm/fas216.h |3 +++
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c
index fb5f202..a715632 100644
--- a/drivers/scsi/arm/fas216.c
+++ b/drivers/scsi/arm/fas216.c
@@ -2018,6 +2018,7 @@ static void fas216_rq_sns_done(FAS216_Info *info, struct
scsi_cmnd *SCpnt,
* the upper layers to process. This would have been set
* correctly by fas216_std_done.
*/
+ scsi_eh_restore_cmnd(SCpnt, >ses);
SCpnt->scsi_done(SCpnt);
}
@@ -2103,23 +2104,12 @@ request_sense:
if (SCpnt->cmnd[0] == REQUEST_SENSE)
goto done;
+ scsi_eh_prep_cmnd(SCpnt, >ses, NULL, 0, ~0);
fas216_log_target(info, LOG_CONNECT, SCpnt->device->id,
"requesting sense");
- memset(SCpnt->cmnd, 0, sizeof (SCpnt->cmnd));
- SCpnt->cmnd[0] = REQUEST_SENSE;
- SCpnt->cmnd[1] = SCpnt->device->lun << 5;
- SCpnt->cmnd[4] = sizeof(SCpnt->sense_buffer);
- SCpnt->cmd_len = COMMAND_SIZE(SCpnt->cmnd[0]);
- SCpnt->SCp.buffer = NULL;
- SCpnt->SCp.buffers_residual = 0;
- SCpnt->SCp.ptr = (char *)SCpnt->sense_buffer;
- SCpnt->SCp.this_residual = sizeof(SCpnt->sense_buffer);
- SCpnt->SCp.phase = sizeof(SCpnt->sense_buffer);
+ init_SCp(SCpnt);
SCpnt->SCp.Message = 0;
SCpnt->SCp.Status = 0;
- SCpnt->request_bufflen = sizeof(SCpnt->sense_buffer);
- SCpnt->sc_data_direction = DMA_FROM_DEVICE;
- SCpnt->use_sg = 0;
SCpnt->tag = 0;
SCpnt->host_scribble = (void *)fas216_rq_sns_done;
diff --git a/drivers/scsi/arm/fas216.h b/drivers/scsi/arm/fas216.h
index 00e5f05..b65f4cf 100644
--- a/drivers/scsi/arm/fas216.h
+++ b/drivers/scsi/arm/fas216.h
@@ -16,6 +16,8 @@
#define NO_IRQ 255
#endif
+#include
+
#include "queue.h"
#include "msgqueue.h"
@@ -311,6 +313,7 @@ typedef struct {
/* miscellaneous */
int internal_done; /* flag to indicate
request done */
+ struct scsi_eh_save ses;/* holds request sense restore
Re: [patch] kgdb light, v6
Bartlomiej Zolnierkiewicz wrote: > On Sunday 10 February 2008, Jan Kiszka wrote: >> Ingo Molnar wrote: >>> * Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > +static int init_kgdboc(void) __init >>> done. >> Uuh, careful. We need this for runtime reconfiguration. > > it is used only for 'module_init(init_kgdboc);' in v6 Yeah, the usage chain is not obvious (given I'm looking at the right version ATM - git just spits at me), the issue moved to param_set_kgdboc_var which has to call into configure_kgdboc - now __init. Ingo, please keep the original annotations, they where correct and should have been optimal (under the given constraints or runtime reconfiguration). Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] kgdb light, v6
* Jan Kiszka <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > > * Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > >>> +static int init_kgdboc(void) > >> __init > > > > done. > > Uuh, careful. We need this for runtime reconfiguration. i think v7 is fine. worst-case we'll get a nice fat section warning :-) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] move wakeup code to .c
I think .c wakeup code is ready for some more testing. HPA and Rafael
did coding, so I added them as signed-off-by:. (Plus Rafael actually
thinks its ready for -mm, I agree.)
Pavel
---
Move wakeup code to .c, so that video mode setting code can be shared
between boot and wakeup. Remove nasty assembly code in 64-bit case by
re-using trampoline code. Stack setup was fixed to clear high 16bits
of %esp, maybe that fixes some machines.
.c code sharing and morse code was done H. Peter Anvin, Sam Ravnborg
reviewed kbuild related stuff, and it seems okay to him. Rafael did
some cleanups.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Reviewed-by: Sam Ravnborg <[EMAIL PROTECTED]>
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index f88458e..84a09eb 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -30,7 +30,7 @@ subdir- := compressed
setup-y+= a20.o cmdline.o copy.o cpu.o cpucheck.o edd.o
setup-y+= header.o main.o mca.o memory.o pm.o pmjump.o
-setup-y+= printf.o string.o tty.o video.o version.o
+setup-y+= printf.o string.o tty.o video.o video-mode.o
version.o
setup-$(CONFIG_X86_APM_BOOT) += apm.o
setup-$(CONFIG_X86_VOYAGER) += voyager.o
diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h
index 7822a49..0957807 100644
--- a/arch/x86/boot/boot.h
+++ b/arch/x86/boot/boot.h
@@ -286,6 +286,11 @@ int getchar_timeout(void);
/* video.c */
void set_video(void);
+/* video-mode.c */
+int set_mode(u16 mode);
+int mode_defined(u16 mode);
+void probe_cards(int unsafe);
+
/* video-vesa.c */
void vesa_store_edid(void);
diff --git a/arch/x86/boot/video-bios.c b/arch/x86/boot/video-bios.c
index ff664a1..39e247e 100644
--- a/arch/x86/boot/video-bios.c
+++ b/arch/x86/boot/video-bios.c
@@ -50,6 +50,7 @@ static int set_bios_mode(u8 mode)
if (new_mode == mode)
return 0; /* Mode change OK */
+#ifndef _WAKEUP
if (new_mode != boot_params.screen_info.orig_video_mode) {
/* Mode setting failed, but we didn't end up where we
started. That's bad. Try to revert to the original
@@ -59,13 +60,18 @@ static int set_bios_mode(u8 mode)
: "+a" (ax)
: : "ebx", "ecx", "edx", "esi", "edi");
}
+#endif
return -1;
}
static int bios_probe(void)
{
u8 mode;
+#ifdef _WAKEUP
+ u8 saved_mode = 0x03;
+#else
u8 saved_mode = boot_params.screen_info.orig_video_mode;
+#endif
u16 crtc;
struct mode_info *mi;
int nmodes = 0;
diff --git a/arch/x86/boot/video-mode.c b/arch/x86/boot/video-mode.c
new file mode 100644
index 000..18bacb3
--- /dev/null
+++ b/arch/x86/boot/video-mode.c
@@ -0,0 +1,173 @@
+/* -*- linux-c -*- --- *
+ *
+ * Copyright (C) 1991, 1992 Linus Torvalds
+ * Copyright 2007-2008 rPath, Inc. - All Rights Reserved
+ *
+ * This file is part of the Linux kernel, and is made available under
+ * the terms of the GNU General Public License version 2.
+ *
+ * --- */
+
+/*
+ * arch/i386/boot/video-mode.c
+ *
+ * Set the video mode. This is separated out into a different
+ * file in order to be shared with the ACPI wakeup code.
+ */
+
+#include "boot.h"
+#include "video.h"
+#include "vesa.h"
+
+/*
+ * Common variables
+ */
+int adapter; /* 0=CGA/MDA/HGC, 1=EGA, 2=VGA+ */
+u16 video_segment;
+int force_x, force_y; /* Don't query the BIOS for cols/rows */
+
+int do_restore = 0;/* Screen contents changed during mode flip */
+int graphic_mode; /* Graphic mode with linear frame buffer */
+
+/* Probe the video drivers and have them generate their mode lists. */
+void probe_cards(int unsafe)
+{
+ struct card_info *card;
+ static u8 probed[2];
+
+ if (probed[unsafe])
+ return;
+
+ probed[unsafe] = 1;
+
+ for (card = video_cards; card < video_cards_end; card++) {
+ if (card->unsafe == unsafe) {
+ if (card->probe)
+ card->nmodes = card->probe();
+ else
+ card->nmodes = 0;
+ }
+ }
+}
+
+/* Test if a mode is defined */
+int mode_defined(u16 mode)
+{
+ struct card_info *card;
+ struct mode_info *mi;
+ int i;
+
+ for (card = video_cards; card < video_cards_end; card++) {
+ mi = card->modes;
+ for (i = 0; i < card->nmodes; i++, mi++) {
+ if (mi->mode == mode)
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
+/* Set mode (without
Re: [PATCH 2/8] drivers/block: Use FIELD_SIZEOF
On Sun, 10 Feb 2008 21:08:49 +0100 (CET) Julia Lawall <[EMAIL PROTECTED]> wrote: > > From: Julia Lawall <[EMAIL PROTECTED]> > > Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code > that matches its definition. > > The modification was made using the following semantic patch > (http://www.emn.fr/x-info/coccinelle/) > > // > @haskernel@ > @@ > > #include > > @depends on haskernel@ > type t; > identifier f; > @@ > > - (sizeof(((t*)0)->f)) > + FIELD_SIZEOF(t, f) > > @depends on haskernel@ > type t; > identifier f; > @@ > > - sizeof(((t*)0)->f) > + FIELD_SIZEOF(t, f) > // > > Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> Acked-by: Stephen Rothwell <[EMAIL PROTECTED]> -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpe99uD65tTC.pgp Description: PGP signature
Re: [PATCH] SUNPRC: Fix printk format warning
On Fri, Feb 08, 2008 at 04:02:04PM -0800, Roland Dreier wrote:
> net/sunrpc/xprtrdma/svc_rdma_sendto.c:160: warning: format '%llx' expects
> type 'long long unsigned int', but argument 3 has type 'u64'
OK, thanks. Applied (with the long line split).
--b.
>
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
> ---
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
> b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
> index 3e32194..4b913e7 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_sendto.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_sendto.c
> @@ -159,7 +159,7 @@ static int send_write(struct svcxprt_rdma *xprt, struct
> svc_rqst *rqstp,
> BUG_ON(sge_count >= 32);
> dprintk("svcrdma: RDMA_WRITE rmr=%x, to=%llx, xdr_off=%d, "
> "write_len=%d, xdr_sge=%p, sge_count=%d\n",
> - rmr, to, xdr_off, write_len, xdr_sge, sge_count);
> + rmr, (unsigned long long) to, xdr_off, write_len, xdr_sge,
> sge_count);
>
> ctxt = svc_rdma_get_context(xprt);
> ctxt->count = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86: Why have __copy_from_user_ll_nocache* been exported?
> * Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > Sorry Andrew. > > > > I misunderstood the patch flow. > > > > And much more important, the tone of my email was not appropriate. > > > > Due to unrelated reasons I was Thursday evening in a mood in which I > > should not have left emails out of my postponed folder without > > sleeping a night over them. > > > > I hope you accept my apology. > > i'd like to apologize to you too Adrian - i should have been (a lot) > more patient as well - the merge window is not for the faint hearted i > guess :-/ Apology accepted. > Ingo cu Adrian BTW: Your emails really brought me near to leaving kernel development. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] kgdb light, v6
On Sunday 10 February 2008, Ingo Molnar wrote:
[...]
> > > +__setup("kgdboc=", kgdboc_option_setup);
> >
> > no need for obsolete __setup, we have module_param_call() below
>
> it's needed for bzImage kernels. I just tested it and without __setup()
> no init sequence is run and KGDB is not activated.
weird, should work with "kgdboc.kgdboc=" parameter
[...]
> > > +#ifndef KGDB_MAX_BREAKPOINTS
> > > +# define KGDB_MAX_BREAKPOINTS1000
> > > +#endif
> > > +
> > > +#define KGDB_HW_BREAKPOINT 1
> >
> > unused
>
> hm, both KGDB_MAX_BREAKPOINTS and KGDB_HW_BREAKPOINT are used.
my bad
[...]
> > if kgdb_isremovedbreak() helper is moved before kgdb_set_sw_break()
> > and converted to return 'i' on success and '-1' on failure then it can
> > be used instead the above for () loop
>
> dunno - that would complicate arch/x86/kernel/kgdb.c's use of
> kgdb_isremovedbreak() and looks a bit complex. If you feel strongly
the whole difference w.r.t. arch/x86/kernel/kgdb.c should be:
- if (exception == 3 && kgdb_isremovedbreak(regs->ip - 1)) {
+ if (exception == 3 && kgdb_isremovedbreak(regs->ip - 1) >= 0) {
> about it, could you send a patch?
well, maybe in the future if nobody fixes it :)
[ added as low-prio to my TODO... ]
Thanks for fixing all the other stuff.
Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] kgdb light, v6
On Sunday 10 February 2008, Jan Kiszka wrote: > Ingo Molnar wrote: > > * Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > >>> +static int init_kgdboc(void) > >> __init > > > > done. > > Uuh, careful. We need this for runtime reconfiguration. it is used only for 'module_init(init_kgdboc);' in v6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Whine about suspicious return values from module's ->init() hook
On Wed, Feb 06, 2008 at 05:55:26PM +1100, Rusty Russell wrote:
> On Wednesday 06 February 2008 10:37:52 Andrew Morton wrote:
> > On Wed, 6 Feb 2008 09:48:10 +1100
> >
> > Rusty Russell <[EMAIL PROTECTED]> wrote:
> > > > It's a no-brainer.
> > >
> > > For non-developers, WARN_ON is a noop.
> >
> > Oh.. Rusty. The mailing list and bugzilla are *full* of WARN_ON reports
> > from testers. Your statement is empirically wrong.
>
> My apologies. I had extrapolated from my own behaviour: I don't notice
> WARN_ON unless something else goes wrong to make me look in the logs.
>
> > > BUG_ON() will make us fix it in return for short-term pain.
> >
> > Pain to our users and testers. People upon whom we are very dependent and
> > to whom we are hugely indebted. People who I have to spend a lot of time
> > defending from the likes of you!
>
> I think you misunderstand. I proposed that we audit all the code before such
> a change. We shouldn't do *anything* until we can estimate the impact this
> change will have.
With such rate of changes, good luck doing that.
Good example is sysctl checks. There was initial influx of reports and
they were fixed and there were no sysctl reports recently.
> Our users deserve better than "I don't know if this will break anything so I
> used WARN_ON". They deserve "we have confidence that this change won't break
> any existing code".
>
> Now, if an audit is impractical or unreliable, we are better off with a
> WARN_ON.
It's impractical as in it's extremely boring to read every modules init
function and propagate return values in mind.
> But it is still an admission of ignorance.
I love BUG_ON and BUILD_BUG_ON very much but on such scale you can't
just throw them in.
Here goes version 2 with improved changelog. Let's put in -mm and see
what happens, then put it in mainline and see what happens.
[PATCH v2] Whine about suspicious return values from module's ->init() hook
Return value convention of module's init functions is 0/-E. Sometimes, e.g.
during forward-porting mistakes happen and buggy module created, where result
of comparison "workqueue != NULL" is propagated all the way up to
sys_init_module. What happens is that some other module created workqueue in
question, our module created it again and module was successfully loaded.
Or it could be some other bug.
Let's make such mistakes much more visible. In retrospective, such messages
would noticeably shorten some of my head-scratching sessions.
Note, that dump_stack() is just a way to get attention from user.
Sample message:
sys_init_module: 'foo'->init suspiciously returned 1, it should follow 0/-E
convention
sys_init_module: loading module anyway...
Pid: 4223, comm: modprobe Not tainted
2.6.24-25f666300625d894ebe04bac2b4b3aadb907c861 #5
Call Trace:
[] sys_init_module+0xe5/0x1d0
[] system_call_after_swapgs+0x7b/0x80
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
kernel/module.c |8
1 file changed, 8 insertions(+)
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2174,6 +2174,14 @@ sys_init_module(void __user *umod,
wake_up(_wq);
return ret;
}
+ if (ret > 0) {
+ printk(KERN_WARNING "%s: '%s'->init suspiciously returned %d, "
+ "it should follow 0/-E convention\n"
+ KERN_WARNING "%s: loading module anyway...\n",
+ __func__, mod->name, ret,
+ __func__);
+ dump_stack();
+ }
/* Now it's a first class citizen! */
mutex_lock(_mutex);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Silent compiler warning introduced by acea6852f32b8805e166d885ed7e9f0c7cd10d41 ([BLUETOOTH]: Move children of connection device to NULL before connection down.)
Hi;
10 Şub 2008 Paz tarihinde, Linus Torvalds şunları yazmıştı:
>
> On Sun, 10 Feb 2008, S.Çağlar Onur wrote:
> > > >
> > > > - while (dev = device_find_child(>dev, NULL, __match_tty)) {
> > > > + while ((dev = device_find_child(>dev, NULL, __match_tty))
> > > > != NULL) {
> > > >
> > > Why do you need '!= NULL'?
> >
> > I thought its more readable than
> >
> > while ((dev = device_find_child(>dev, NULL, __match_tty))) {
>
> Yes indeed. I hate the idiotic "double parenthesis without any meaning".
> I'd much rather see "((..) != NULL)" than "((..))", because the latter is
> totally meaningless semantically (although gcc gives it semantics).
But you still not merged this one :), is there any problem exists or would you
prefer this comes from with a subsystem tree (which means i'm doing wrong thing
with sending these trivial patches to you)?
Cheers
--
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: scsi/arm/fas216.c compile error
On Sun, Feb 10, 2008 at 08:20:24AM -0600, James Bottomley wrote:
>
> On Sun, 2008-02-10 at 13:58 +, Russell King wrote:
> > On Sun, Feb 10, 2008 at 03:07:09PM +0200, Boaz Harrosh wrote:
> > > It's in mainline 84ac86ca8c6787f9efff28bc04b1b65fe0a5c310
> > > [SCSI] arm: convert to accessors and !use_sg cleanup
> > >
> > > Thanks for checking. This patch was in scsi-pending tree since forever,
> > > And we were unable
> > > to get a responsive maintainer to ACK on them. until the breakage cause
> > > went into mainline
> > > we finally managed a Tested-by:.
> > >
> > > I guess sometimes people are so busy, you need a bulldozer to shove 20
> > > minutes into they're
> > > schedule.
> >
> > Oh, I was ill for most of December, particularly at the time that you
> > sent the patch, and by the time I recovered, it was buried in my mailbox.
> >
> > Suggest you have some consideration for others who might not be able to
> > do your beg and call at the immediate moment that you want it, and
> > consider that their email management skills may not be as l33t as yours.
>
> OK, sorry about this, it's a bit of a cockup all around. The patch that
> fixes this problem is still in SCSI pending largely because it's patch
> description:
>
> [SCSI] fas216: Use scsi_eh API for REQUEST_SENSE invocation
>
> Doesn't lead one to think it might be build critical, so I concentrated
> on getting the other arm patch out.
>
> Russell, could you give it a quick test, and I'll put it in with a
> tested-by tag?
It's not looking good:
CC drivers/scsi/arm/fas216.o
drivers/scsi/arm/fas216.c: In function `fas216_rq_sns_done':
drivers/scsi/arm/fas216.c:2021: warning: passing arg 2 of
`scsi_eh_restore_cmnd' from incompatible pointer type
drivers/scsi/arm/fas216.c: In function `fas216_std_done':
drivers/scsi/arm/fas216.c:2107: warning: passing arg 2 of `scsi_eh_prep_cmnd'
from incompatible pointer type
Since the second argument of scsi_eh_prep_cmnd is 'struct scsi_eh_save *ses'
this patch is most definitely bad. Not even booted it.
>
> Thanks,
>
> James
>
> ---
>
> From: Boaz Harrosh <[EMAIL PROTECTED]>
> Date: Mon, 10 Sep 2007 22:39:11 +0300
> Subject: [SCSI] fas216: Use scsi_eh API for REQUEST_SENSE invocation
>
> - Use new scsi_eh_prep/restor_cmnd() for synchronous
> REQUEST_SENSE invocation.
>
> Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
> Cc: Russell King <[EMAIL PROTECTED]>
> Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
> ---
> drivers/scsi/arm/fas216.c | 16 +++-
> drivers/scsi/arm/fas216.h |3 +++
> 2 files changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/scsi/arm/fas216.c b/drivers/scsi/arm/fas216.c
> index fb5f202..a715632 100644
> --- a/drivers/scsi/arm/fas216.c
> +++ b/drivers/scsi/arm/fas216.c
> @@ -2018,6 +2018,7 @@ static void fas216_rq_sns_done(FAS216_Info *info,
> struct scsi_cmnd *SCpnt,
>* the upper layers to process. This would have been set
>* correctly by fas216_std_done.
>*/
> + scsi_eh_restore_cmnd(SCpnt, >ses);
> SCpnt->scsi_done(SCpnt);
> }
>
> @@ -2103,23 +2104,12 @@ request_sense:
> if (SCpnt->cmnd[0] == REQUEST_SENSE)
> goto done;
>
> + scsi_eh_prep_cmnd(SCpnt, >ses, NULL, 0, ~0);
> fas216_log_target(info, LOG_CONNECT, SCpnt->device->id,
> "requesting sense");
> - memset(SCpnt->cmnd, 0, sizeof (SCpnt->cmnd));
> - SCpnt->cmnd[0] = REQUEST_SENSE;
> - SCpnt->cmnd[1] = SCpnt->device->lun << 5;
> - SCpnt->cmnd[4] = sizeof(SCpnt->sense_buffer);
> - SCpnt->cmd_len = COMMAND_SIZE(SCpnt->cmnd[0]);
> - SCpnt->SCp.buffer = NULL;
> - SCpnt->SCp.buffers_residual = 0;
> - SCpnt->SCp.ptr = (char *)SCpnt->sense_buffer;
> - SCpnt->SCp.this_residual = sizeof(SCpnt->sense_buffer);
> - SCpnt->SCp.phase = sizeof(SCpnt->sense_buffer);
> + init_SCp(SCpnt);
> SCpnt->SCp.Message = 0;
> SCpnt->SCp.Status = 0;
> - SCpnt->request_bufflen = sizeof(SCpnt->sense_buffer);
> - SCpnt->sc_data_direction = DMA_FROM_DEVICE;
> - SCpnt->use_sg = 0;
> SCpnt->tag = 0;
> SCpnt->host_scribble = (void *)fas216_rq_sns_done;
>
> diff --git a/drivers/scsi/arm/fas216.h b/drivers/scsi/arm/fas216.h
> index 00e5f05..3e73e26 100644
> --- a/drivers/scsi/arm/fas216.h
> +++ b/drivers/scsi/arm/fas216.h
> @@ -16,6 +16,8 @@
> #define NO_IRQ 255
> #endif
>
> +#include
> +
> #include "queue.h"
> #include "msgqueue.h"
>
> @@ -311,6 +313,7 @@ typedef struct {
>
> /* miscellaneous */
> int internal_done; /* flag to indicate
> request done */
> + struct scsi_eh_save *ses; /* holds request sense restore
> info */
Looks to me like this line has a stray '*' on?
> unsigned long magic_end;
> } FAS216_Info;
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from
Re: sparc compile error
David Rientjes wrote: Please try Linus' latest git that includes 60c12b12 (from yesterday) that fixes this issue. I get this with latest git: CC init/do_mounts.o In file included from include/linux/mm.h:39, from include/linux/memcontrol.h:24, from include/linux/swap.h:8, from include/linux/suspend.h:7, from init/do_mounts.c:6: include/asm/pgtable.h:344: warning: parameter names (without types) in function declaration include/asm/pgtable.h:345: warning: parameter names (without types) in function declaration include/asm/pgtable.h:346: error: expected '=', ',', ';', 'asm' or '__attribute__' before '___f___swp_entry' make[1]: *** [init/do_mounts.o] Error 1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24 oops
Hello, I encountered an oops while playing a movie with mplayer. (couple of hours before, I tried this exploit: http://www.securityfocus.com/data/vulnerabilities/exploits/27704.c so the oops may be induced by the exploit.) [12695.120141] Unable to handle kernel paging request at 1000 RIP: [12695.120152] [] find_get_page+0x3b/0x80 [12695.120166] PGD 0 [12695.120172] Oops: [1] PREEMPT SMP [12695.120180] CPU 0 [12695.120184] Modules linked in: cdc_ether usbnet mii cdc_acm usb_storage des_generic cbc nfs lockd rpcsec_gss_krb5 auth_rpcgss sunrpc i915 drm rfcomm l2cap bluetooth fuse arc4 ecb blkcipher e1000 ehci_hcd uhci_hcd snd_hda_intel thinkpad_acpi intel_agp [12695.120228] Pid: 10382, comm: mplayer Not tainted 2.6.24 #2 [12695.120232] RIP: 0010:[] [] find_get_page+0x3b/0x80 [12695.120242] RSP: 0018:8100794d7ca8 EFLAGS: 00210006 [12695.120247] RAX: 1000 RBX: 1000 RCX: [12695.120252] RDX: 81000efe RSI: 0001b3c0 RDI: [12695.120257] RBP: 81007ceffeb8 R08: R09: 80270330 [12695.120262] R10: R11: 0001 R12: 0001b3c0 [12695.120267] R13: 0001 R14: 81000cf8a728 R15: 81000cf8a6c0 [12695.120273] FS: 2af6ae621610() GS:8062b000() knlGS: [12695.120278] CS: 0010 DS: ES: CR0: 8005003b [12695.120283] CR2: 1000 CR3: 512b7000 CR4: 06e0 [12695.120288] DR0: DR1: DR2: [12695.120292] DR3: DR6: 0ff0 DR7: 0400 [12695.120298] Process mplayer (pid: 10382, threadinfo 8100794d6000, task 81007c23) [12695.120303] Stack: 8100794d7ed8 81007ceffea0 0001b3c0 80270efb [12695.120313] 00037000 80270330 8100794d7d68 8100794d7e58 [12695.120322] 81000cf8a728 81007ceffd78 0001b3c1 0001b3bf [12695.120329] Call Trace: [12695.120338] [] do_generic_mapping_read+0x10b/0x400 [12695.120345] [] file_read_actor+0x0/0x1a0 [12695.120355] [] generic_file_aio_read+0xff/0x1b0 [12695.120366] [] do_sync_read+0xd9/0x120 [12695.120373] [] enqueue_hrtimer+0x6e/0x110 [12695.120383] [] autoremove_wake_function+0x0/0x30 [12695.120391] [] do_nanosleep+0x69/0x90 [12695.120397] [] hrtimer_nanosleep+0x78/0x140 [12695.120404] [] hrtimer_wakeup+0x0/0x30 [12695.120411] [] do_nanosleep+0x55/0x90 [12695.120417] [] vfs_read+0xc5/0x160 [12695.120422] [] sys_read+0x3b/0x90 [12695.120429] [] sys_read+0x53/0x90 [12695.120437] [] system_call+0x7e/0x83 [12695.120444] [12695.120446] [12695.120447] Code: 48 8b 00 48 89 da 25 00 40 02 00 48 3d 00 40 02 00 74 22 f0 [12695.120472] RIP [] find_get_page+0x3b/0x80 [12695.120480] RSP [12695.120484] CR2: 1000 [12695.120490] ---[ end trace a272000ffa9585c7 ]--- [12695.120496] note: mplayer[10382] exited with preempt_count 1 -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] kgdb light, v6
Ingo Molnar wrote: > * Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: >>> +static int init_kgdboc(void) >> __init > > done. Uuh, careful. We need this for runtime reconfiguration. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pata_sil680 regression 2.6.22->2.6.24
> Robert Lowery wrote: >> Hi Folks, >> >> Having recently upgaded my Ubuntu install from Gutsy to Hardy, my 750GB >> Seagate disk connected via a SiI680 PCI card is no longer detected. I >> suspect this is caused by the MMIO changes in 2.6.24. Strangely in >> 2.6.22 >> the drive appears as sda1, but on 2.6.24 it appears as a non functioning >> hde. >> >> A working 2.6.22 based system reports >> >> Feb 10 01:49:22 myth-backend kernel: [ 88.296373] sil680: BA5_EN = 1 >> clock = 00 >> Feb 10 01:49:22 myth-backend kernel: [ 88.296401] sil680: BA5_EN = 1 >> clock = 10 >> Feb 10 01:49:22 myth-backend kernel: [ 88.296479] sil680: 133MHz >> clock. >> Feb 10 01:49:22 myth-backend kernel: [ 88.296672] ACPI: PCI Interrupt >> :00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 >> Feb 10 01:49:22 myth-backend kernel: [ 88.297584] scsi2 : pata_sil680 >> Feb 10 01:49:22 myth-backend kernel: [ 88.298142] scsi3 : pata_sil680 >> Feb 10 01:49:22 myth-backend kernel: [ 88.298398] ata1: PATA max >> UDMA/133 cmd 0x00019000 ctl 0x00018802 bmdma 0x00017800 irq 19 >> Feb 10 01:49:22 myth-backend kernel: [ 88.298409] ata2: PATA max >> UDMA/133 cmd 0x00018400 ctl 0x00018002 bmdma 0x00017808 irq 19 >> Feb 10 01:49:22 myth-backend kernel: [ 88.530102] ata1.00: ATA-7: >> ST3750640A, 3.AAE, max UDMA/100 >> Feb 10 01:49:22 myth-backend kernel: [ 88.530139] ata1.00: 1465149168 >> sectors, multi 0: LBA48 >> Feb 10 01:49:22 myth-backend kernel: [ 88.604735] ata1.00: configured >> for UDMA/100 >> >> A non working 2.6.24 based system reports >> >> Feb 9 16:19:28 myth-backend kernel: [ 81.149973] SiI680: IDE >> controller >> (0x1095:0x0680 rev 0x02) at PCI slot :00:0d.0 >> Feb 9 16:19:28 myth-backend kernel: [ 81.150031] ACPI: PCI Interrupt >> :00:0d.0[A] -> GSI 19 (level, low) -> IRQ 19 >> Feb 9 16:19:28 myth-backend kernel: [ 81.150094] SiI680: BASE CLOCK >> == 133 >> Feb 9 16:19:28 myth-backend kernel: [ 81.150104] SiI680: 100% native >> mode on irq 19 >> Feb 9 16:19:28 myth-backend kernel: [ 81.150121] ide2: MMIO-DMA , >> BIOS settings: hde:pio, hdf:pio >> Feb 9 16:19:28 myth-backend kernel: [ 81.150145] ide3: MMIO-DMA , >> BIOS settings: hdg:pio, hdh:pio >> Feb 9 16:19:28 myth-backend kernel: [ 82.113860] hde: þþÿþ`KÐ, ATA >> DISK >> drive >> Feb 9 16:19:28 myth-backend kernel: [ 82.114038] ide2 at >> 0xf882a080-0xf882a087,0xf882a08a on irq 19 > > This is not pata_sil680, this is drivers/ide trying to operate this > card. Has something changed in your kernel config? Hi Robert, Thanks for your reply. I'm not sure if the kernel config has changed as I am using the stock ubuntu kernels. Perhaps I should log a bug with ubuntu. If it helps, the pata_sil680 module is loaded (visible in /proc/modules) when I boot either kernel, it just doesn't detect my 750GB drive in the 2.6.24 based kernel. > >> >> Note, my bios does not support 750GB drives, so the drive is not >> configured in the card BIOS. This has not stopped linux detecting it ok >> in the past. >> >> Please let me know if I need to provide any more information or >> additional >> testing. >> >> Thanks >> >> -Rob >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" >> in >> the body of a message to [EMAIL PROTECTED] >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/6] kgdb light
* Sam Ravnborg <[EMAIL PROTECTED]> wrote: > I promote the "select HAVE_*" style on all new stuff and expect that a > herd of janitors one day pick it up and convert most of the old-style > stuff. And if you look around then you will see that for this merge > window almost all new stuff used "select HAVE_" so we on the right > track. yeah, it's not like i'm complaining - you are doing a terrific job with kbuild and kconfig. Perhaps instead of outright converting it (which needs thought and real hard work), how about just running a quick script over all Kconfigs and marking old-style entries as: # TODO: this stuff needs to be fixed, see Documentation/blah.txt ? Should be 15 minutes of awk and can be committed right after -rc1. Annoying messages like that tend to get the attention of architecture maintainers :-) The Kconfig rules are not always obvious so people need help. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.26-git0: IDE oops during boot
On 2/7/08, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > > On Thursday 07 February 2008, Kamalesh Babulal wrote: > > Bartlomiej Zolnierkiewicz wrote: > > > Hi, > > > > > > On Wednesday 06 February 2008, Pavel Machek wrote: > > >> On Wed 2008-02-06 11:53:34, Pavel Machek wrote: > > >>> Hi! > > >>> > > >>> Trying to boot 2.6.25-git0 (few days old), I get > > >>> > > >>> BUG: unable to handle kernel paging request at ..ffb0 > > >>> IP at init_irq+0x42e > > > > > > init_irq? hmm... > > > > > >>> Call trace: > > >>> ide_device_add_all > > > > > > this comes from ide-generic > > > (Generic IDE host driver) > > > > > >>> ide_generic_init > > >>> kernel_init > > >>> child_rip > > >>> vgacon_cursor > > >>> kernel_init > > >>> child_rip > > >>> > > >>> Excerpt from config: > > >>> > > >>> CONFIG_IDE=y > > >>> CONFIG_BLK_DEV_IDE=y > > >> Disabling CONFIG_IDE made my machine boot, as it was using libata > > >> anyway. > > > > > > Kamalesh/Pavel: > > > > > > Could you try latest git and see if the OOPS is still there? > > > > > > [ Yeah, I'm unable to reproduce it. :( ] > > > > > > Thanks, > > > Bart > > Hi Bart, > > > > The panic is reproducible with the 2.6.24-git16 kernel, the call trace is > > similar to the previous one > > Thanks, I again reviewed ide-probe.c changes but nothing seems wrong... > > Could you please bisect it down to the guilty commit? Kamalesh, were you able to bisect this down? I just got hit by the same panic on a 4-way x86_64, with 2.6.24-git22. Thanks, Nish -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] avoid kmemcheck warning in epoll
Epoll calls rb_set_parent(n, n) to initialize the rb-tree node, but
rb_set_parent() accesses node's pointer in its code. This creates a
warning in kmemcheck (reported by Vegard Nossum) about an uninitialized
memory access. The warning is harmless since the following rb-tree node
insert is going to overwrite the node data. In any case I think it's
better to not have that happening at all, and fix it by properly
initializing the data.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
fs/eventpoll.c |2 +-
include/linux/rbtree.h | 12
2 files changed, 13 insertions(+), 1 deletion(-)
Index: linux-2.6.mod/fs/eventpoll.c
===
--- linux-2.6.mod.orig/fs/eventpoll.c 2008-02-10 12:36:20.0 -0800
+++ linux-2.6.mod/fs/eventpoll.c2008-02-10 12:50:41.0 -0800
@@ -260,7 +260,7 @@
/* Special initialization for the RB tree node to detect linkage */
static inline void ep_rb_initnode(struct rb_node *n)
{
- rb_set_parent(n, n);
+ rb_init_node(n, n);
}
/* Removes a node from the RB tree and marks it for a fast is-linked check */
Index: linux-2.6.mod/include/linux/rbtree.h
===
--- linux-2.6.mod.orig/include/linux/rbtree.h 2008-02-10 12:36:13.0
-0800
+++ linux-2.6.mod/include/linux/rbtree.h2008-02-10 12:51:57.0
-0800
@@ -112,6 +112,18 @@
struct rb_node *rb_node;
};
+/**
+ * rb_init_node - Initializes the node internal data
+ *
+ * @node: Pointer to the RB-Tree node
+ * @parent: Pointer to the parent node, or NULL
+ *
+ */
+static inline void rb_init_node(struct rb_node *node, struct rb_node *parent)
+{
+ node->rb_parent_color = (unsigned long) parent;
+ node->rb_left = node->rb_right = NULL;
+}
#define rb_parent(r) ((struct rb_node *)((r)->rb_parent_color & ~3))
#define rb_color(r) ((r)->rb_parent_color & 1)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] kgdb light, v6
* Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > > no. These are not DocBook comments, if you look carefully at the > > format [it's not a leading '/**' comment block]. But obviously > > documenting this in the include file is very useful, because that's > > where people look first, so i kept it. (the APIs will not deviate > > across architectures) > > comments and variable names in include files have a tendency for going > out-of-sync in the long term so IMO having a DocBook to point people > at would be a better solution (+ it would shrink by 122 > lines) yes, i very much agree in general, but this is a _SPECIAL CASE_, and i already tried to point that out to Christoph but he's not the type of guy who listens to others all that easily when it comes to his pet peeves ;-) this is a special case because it's an _architecture facility_. read: right now we have 25 architectures, and this means that in a year we'll have 25 arch/*/kernel/kgdb.c files. What will be more likely to get out of sync, 25 full sets of DocBook entries of the same thing, spread across 25 architectures - or that lone single include/linux/kgdb.h file that is looked at by everyone? And what will be easier to update if we extend any of the APIs? so the DocBook rules are fine, but in this SPECIAL CASE they cause the possibly worst solution: total information anarchy! the correct approach is to put the _arch specific_ details into the arch/*/kernel/kgdb.c files, and to keep the generic bits in include/linux/kgdb.h. KGDB did exactly that and it's by far the cleanest and most maintainable approach. If DocBook does not pick that up then it's a _DocBook problem_. I dont mind adding some dummy weak aliases to kernel/kgdb.c for DocBook to pick up, to help solve this DocBook problem - but to blame it on KGDB is way off the mark. It used to be the crappiest piece of sh*t everyone would laugh about when looking at (right before suffering permanent brain damage), but now it's one of the cleanest and most CodingStyle conform kernel subsystems :-) case in point: errors lines of code errors/KLOC kernel/kgdb.c 01839 0 fs/xfs/ 2102 106019 19.8 right, XFS has more than 2 thousand bona fide CodingStyle violations! But yeah, it has the luxory of upstream integration ... ;-) [ not that i want to pick on XFS - it's a very clean codebase in my opinion, considering its fundamental complexity. It's just that anyone who wants to find a style error in KGDB now has to search _hard_ ;-) ] Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [0/6] kgdb light
> > btw., we should convert all those current: > > config ARCH_POPULATES_NODE_MAP > def_bool y > > config AUDIT_ARCH > bool > default X86_64 > > config ARCH_SUPPORTS_AOUT > def_bool y > > instances to select lines after config X86 / config X86_64. > > KGDB just followed the current Kconfig style status quo. Indeed. I just do not have time to do so. A day-time job that is not about kernel-hacking, three kids and a wife etc. consumes some decent amount of time and leaves only a few hours for linux. And I am a strange person that actually needs to sleep several hours each night (as my baby daughter permits me to). I promote the "select HAVE_*" style on all new stuff and expect that a herd of janitors one day pick it up and convert most of the old-style stuff. And if you look around then you will see that for this merge window almost all new stuff used "select HAVE_" so we on the right track. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
