Re: [PATCH bpf v6 1/2] lib/strncpy_from_user.c: Don't overcopy bytes after NUL terminator

On Mon, Nov 16, 2020 at 02:44:56PM -0800, Linus Torvalds wrote: > On Mon, Nov 16, 2020 at 2:15 PM Linus Torvalds > wrote: > > > > So I've verified that at least on x86-64, this doesn't really make > > code generation any worse, and I'm ok with the patch from that > > standpoint. > > .. looking

Re: [PATCH] cpufreq: dt: fix oops on armada37xx

On Sat, Jun 20, 2020 at 07:54:38PM +0200, Andrew Lunn wrote: > On Sat, Jun 20, 2020 at 05:44:49PM +0100, Ivan Kokshaysky wrote: > > Commit 0c868627e617e43a295d8 (cpufreq: dt: Allow platform specific > > intermediate callbacks) added two function pointers to the > > struct cpu

[PATCH] cpufreq: dt: fix oops on armada37xx

.174554] Unable to handle kernel execute from non-executable memory at virtual address 3f87bdc0 ... [ 29.269373] pc : 0x3f87bdc0 [ 29.272957] lr : __cpufreq_driver_target+0x138/0x580 ... Fixed by zeroing out pdata before use. Signed-off-by: Ivan Kokshaysky --- drivers/cpu

Re: [tip:x86/platform] x86/PCI/mmcfg: Switch to ECAM config mode if possible

On Fri, Jun 30, 2017 at 10:16:15AM -0700, Linus Torvalds wrote: > On Fri, Jun 30, 2017 at 7:30 AM, Thomas Gleixner wrote: > >> But MCFG problems were a long time ago and noone uses these systems > >> anymore, > >> so perhaps he is right. > > > > The obvious solution to this

Re: [tip:x86/platform] x86/PCI/mmcfg: Switch to ECAM config mode if possible

On Fri, Jun 30, 2017 at 10:16:15AM -0700, Linus Torvalds wrote: > On Fri, Jun 30, 2017 at 7:30 AM, Thomas Gleixner wrote: > >> But MCFG problems were a long time ago and noone uses these systems > >> anymore, > >> so perhaps he is right. > > > > The obvious solution to this is to force type 1

Re: [REGRESSION] 2.6.25-rc1 does not boot on Alpha

On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote: > Ivan Kokshaysky wrote: > > No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to > > to switch to vga console, but I had no time to debug this yet... > > Same basic configuration as Ivan. Concur

Re: [RFC][PATCH 2/2] xtime_lock vs update_process_times

n alpha, so this part Acked-by: Ivan Kokshaysky <[EMAIL PROTECTED]> Ivan. -- 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: [REGRESSION] 2.6.25-rc1 does not boot on Alpha

On Wed, Feb 13, 2008 at 02:04:32PM +0100, Ingo Molnar wrote: > > > Unless someone has a good idea what's causing this, I see a massive > > > "git bisect" project in my future. Won't be able to spend any time > > > with this until at least the weekend :-(. > > > > hm, is this SMP? Alpha uses

Re: [ALPHA] ES40 fails to boot with >=kernel 2.6.23

On Wed, Feb 13, 2008 at 04:22:58PM +1100, Nick Piggin wrote: > On Tuesday 12 February 2008 04:27, Raúl Porcel wrote: > > We have a Compaq AlphaServer ES40 and since 2.6.23 it won't boot. I'm > > attaching the console log and the kernel config. Looks like your 'aboot' is outdated - see

Re: [ALPHA] ES40 fails to boot with =kernel 2.6.23

On Wed, Feb 13, 2008 at 04:22:58PM +1100, Nick Piggin wrote: On Tuesday 12 February 2008 04:27, Raúl Porcel wrote: We have a Compaq AlphaServer ES40 and since 2.6.23 it won't boot. I'm attaching the console log and the kernel config. Looks like your 'aboot' is outdated - see

Re: [REGRESSION] 2.6.25-rc1 does not boot on Alpha

On Wed, Feb 13, 2008 at 02:04:32PM +0100, Ingo Molnar wrote: Unless someone has a good idea what's causing this, I see a massive git bisect project in my future. Won't be able to spend any time with this until at least the weekend :-(. hm, is this SMP? Alpha uses

Re: [REGRESSION] 2.6.25-rc1 does not boot on Alpha

On Wed, Feb 13, 2008 at 11:14:43AM -0600, Bob Tracy wrote: Ivan Kokshaysky wrote: No SMP, no PRINTK_TIMESTAMPS in my case. Looks like it dies trying to to switch to vga console, but I had no time to debug this yet... Same basic configuration as Ivan. Concur with the observation

Re: [RFC][PATCH 2/2] xtime_lock vs update_process_times

-by: Ivan Kokshaysky [EMAIL PROTECTED] Ivan. -- 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] moduleparam: fix alpha, ia64 and ppc64 compile failures

On Fri, Feb 08, 2008 at 02:46:15PM -0800, Andrew Morton wrote: > I think it would have been better to define a new CONFIG_MODULEPARAM_CONST > for those three archictures, rather than muckying up the code like this. I'd prefer to keep this as is for now (sorta the uglier the better ;-) I really

[PATCH] moduleparam: fix alpha, ia64 and ppc64 compile failures

to 'section type conflict' in those rare cases where param_set/get are local functions. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964 Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]> --- include/linux/moduleparam.h | 12 +++- 1 files changed, 11 insertions(+), 1 del

Re: [BUILD_FAILURE] 2.6.24-git18 build fails section type conflict psmouse-base

On Fri, Feb 08, 2008 at 03:30:22PM +0200, Adrian Bunk wrote: > > > On Fri, Feb 08, 2008 at 04:02:59PM +0530, Kamalesh Babulal wrote: > > >> The 2.6.24-git18 kernel build fails on the power machine with following > > >> message > > >> drivers/input/mouse/psmouse-base.c:44: error: __param_proto

[PATCH] moduleparam: fix alpha, ia64 and ppc64 compile failures

to 'section type conflict' in those rare cases where param_set/get are local functions. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964 Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] --- include/linux/moduleparam.h | 12 +++- 1 files changed, 11 insertions(+), 1 deletions

Re: [BUILD_FAILURE] 2.6.24-git18 build fails section type conflict psmouse-base

On Fri, Feb 08, 2008 at 03:30:22PM +0200, Adrian Bunk wrote: On Fri, Feb 08, 2008 at 04:02:59PM +0530, Kamalesh Babulal wrote: The 2.6.24-git18 kernel build fails on the power machine with following message drivers/input/mouse/psmouse-base.c:44: error: __param_proto causes a

Re: [PATCH] moduleparam: fix alpha, ia64 and ppc64 compile failures

On Fri, Feb 08, 2008 at 02:46:15PM -0800, Andrew Morton wrote: I think it would have been better to define a new CONFIG_MODULEPARAM_CONST for those three archictures, rather than muckying up the code like this. I'd prefer to keep this as is for now (sorta the uglier the better ;-) I really hope

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Wed, Jan 30, 2008 at 07:42:49AM -0800, Arjan van de Ven wrote: > Xorg doesn't do pci express .. Xorg core provides a set of PCI config access functions (via sysfs) for the graphics drivers. These functions do work correctly with offsets > 256 bytes. Can you guarantee that none of PCI-E video

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Tue, Jan 29, 2008 at 08:45:55PM -0700, Matthew Wilcox wrote: > On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote: > > Matthew, with Arjan's patch, is anything that currently works now > > broken? Why do you feel it is somehow "wrong"? > > lspci is broken. It used to be able to access

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Tue, Jan 29, 2008 at 08:45:55PM -0700, Matthew Wilcox wrote: On Tue, Jan 29, 2008 at 05:19:55AM -0800, Greg KH wrote: Matthew, with Arjan's patch, is anything that currently works now broken? Why do you feel it is somehow wrong? lspci is broken. It used to be able to access extended

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Wed, Jan 30, 2008 at 07:42:49AM -0800, Arjan van de Ven wrote: Xorg doesn't do pci express .. Xorg core provides a set of PCI config access functions (via sysfs) for the graphics drivers. These functions do work correctly with offsets 256 bytes. Can you guarantee that none of PCI-E video

[PATCH] alpha: fix conversion from denormal float to double

The trap handler does properly update the fraction, but not the exponent... Thanks to Paolo Bonzini <[EMAIL PROTECTED]> for the bug report and the testcase. Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]> --- arch/alpha/math-emu/math.c |2 +- 1 files changed, 1 insertions(+),

[PATCH] alpha: fix conversion from denormal float to double

The trap handler does properly update the fraction, but not the exponent... Thanks to Paolo Bonzini [EMAIL PROTECTED] for the bug report and the testcase. Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] --- arch/alpha/math-emu/math.c |2 +- 1 files changed, 1 insertions(+), 1 deletions

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote: > btw this is my main objection to your patch; it intertwines the conf1 > and mmconfig code even more. There is nothing wrong with it; please realize that mmconf and conf1 are just different cpu-side interfaces. Both produce

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Sat, Jan 12, 2008 at 07:46:32AM -0800, Arjan van de Ven wrote: > Ivan Kokshaysky <[EMAIL PROTECTED]> wrote: > > Actually I'm strongly against Arjan's patch. First, it's based on > > assumption that the MMCONFIG thing is sort of fundamentally broken > > on some system

Re: PCI Failed to allocate mem for PCI ROM

On Sat, Jan 12, 2008 at 12:27:05AM -0700, Grant Grundler wrote: > Looking at setup-bus.c:pci_bridge_check_ranges(), I'm concluding that: > [7] is IO Range. > [8] is MMIO > [9] is Prefetchable MMIO > [10] no clue...maybe used by host PCI bus controllers. #10 is for cardbus bridges, IIRC. >

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

cy config space and extended mechanism (mmconf) for the extended config space is a simple and very logical approach. It's supposed to resolve all known mmconf problems. It still allows per-device quirks (tweaking dev->cfg_size). It also allows to get rid of mmconf fallback code. Signed-off-by: Ivan

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

and very logical approach. It's supposed to resolve all known mmconf problems. It still allows per-device quirks (tweaking dev-cfg_size). It also allows to get rid of mmconf fallback code. Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] --- arch/x86/pci/mmconfig-shared.c | 35

Re: PCI Failed to allocate mem for PCI ROM

On Sat, Jan 12, 2008 at 12:27:05AM -0700, Grant Grundler wrote: Looking at setup-bus.c:pci_bridge_check_ranges(), I'm concluding that: [7] is IO Range. [8] is MMIO [9] is Prefetchable MMIO [10] no clue...maybe used by host PCI bus controllers. #10 is for cardbus bridges, IIRC. 0x10 is

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Sat, Jan 12, 2008 at 07:46:32AM -0800, Arjan van de Ven wrote: Ivan Kokshaysky [EMAIL PROTECTED] wrote: Actually I'm strongly against Arjan's patch. First, it's based on assumption that the MMCONFIG thing is sort of fundamentally broken on some systems, but none of the facts we have so

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Sat, Jan 12, 2008 at 09:45:57AM -0800, Arjan van de Ven wrote: btw this is my main objection to your patch; it intertwines the conf1 and mmconfig code even more. There is nothing wrong with it; please realize that mmconf and conf1 are just different cpu-side interfaces. Both produce

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Fri, Jan 11, 2008 at 02:38:03PM -0700, Matthew Wilcox wrote: > On Fri, Jan 11, 2008 at 01:28:30PM -0800, Linus Torvalds wrote: > > Hmm. Were all those reports root-caused to just that BAR probing? If so, > > we may be in better shape than I worried. > > I believe so. Ditto. One typical

Re: [PATCH] include/asm-alpha/core_cia.h, kernel 2.6.23.12

On Sun, Dec 30, 2007 at 07:23:53AM +0100, Anders Hammarquist wrote: > Trying to compile 2.6.23.12 on alpha (a miata) resulted in this > failure: > > cc1: warnings being treated as errors > include/asm/io_trivial.h: In function 'cia_readb': > include/asm/io_trivial.h:75: warning: passing argument

Re: [PATCH] include/asm-alpha/core_cia.h, kernel 2.6.23.12

On Sun, Dec 30, 2007 at 07:23:53AM +0100, Anders Hammarquist wrote: Trying to compile 2.6.23.12 on alpha (a miata) resulted in this failure: cc1: warnings being treated as errors include/asm/io_trivial.h: In function 'cia_readb': include/asm/io_trivial.h:75: warning: passing argument 1 of

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote: > The only quirk I see removed is a bitmap with an arbitrary size (that we > don't really know is sufficient for every system), and that is only > built using comparison between mmconf and type1 accesses. IMHO, there > is zero knowledge

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Fri, Dec 28, 2007 at 08:14:18AM -0800, Arjan van de Ven wrote: > it removes code by removing quirks / known not working stuff.. This not working stuff gets detected at probe time - see drivers/pci/probe.c:pci_cfg_space_size(). Ivan. -- To unsubscribe from this list: send the line "unsubscribe

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

config space and extended mechanism (mmconf) for the extended config space is a simple and very logical approach. It's supposed to resolve *all* known mmconf problems. And it still allows per-device quirks (tweaking dev->cfg_size). And it does *remove* code, not add anything new/untested. Signed-off-by:

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

mechanism (mmconf) for the extended config space is a simple and very logical approach. It's supposed to resolve *all* known mmconf problems. And it still allows per-device quirks (tweaking dev-cfg_size). And it does *remove* code, not add anything new/untested. Signed-off-by: Ivan Kokshaysky [EMAIL

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Fri, Dec 28, 2007 at 08:14:18AM -0800, Arjan van de Ven wrote: it removes code by removing quirks / known not working stuff.. This not working stuff gets detected at probe time - see drivers/pci/probe.c:pci_cfg_space_size(). Ivan. -- To unsubscribe from this list: send the line unsubscribe

Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote: The only quirk I see removed is a bitmap with an arbitrary size (that we don't really know is sufficient for every system), and that is only built using comparison between mmconf and type1 accesses. IMHO, there is zero knowledge in

[PATCH] moduleparam: fix alpha and ia64 compile failures

to 'section type conflict' in those rare cases where param_set/get are local functions. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964 Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]> --- include/linux/moduleparam.h | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-)

[PATCH] gameport: unexport static inline functions (alpha build fix)

These two are defined inline in linux/gameport.h. Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]> --- drivers/input/gameport/gameport.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/input/gameport/gameport.c b/drivers/input/gameport/gameport.c

[PATCH] moduleparam: fix alpha and ia64 compile failures

to 'section type conflict' in those rare cases where param_set/get are local functions. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8964 Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] --- include/linux/moduleparam.h | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff

[PATCH] gameport: unexport static inline functions (alpha build fix)

These two are defined inline in linux/gameport.h. Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] --- drivers/input/gameport/gameport.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/input/gameport/gameport.c b/drivers/input/gameport/gameport.c index bfc6061

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

On Mon, Dec 24, 2007 at 02:22:10AM -0500, Jeff Garzik wrote: > The phrase "all or none" specifically describes the current practice in > arch/x86/pci/mmconfig_{32,64}.c whereby a PCI bus always has one, and only > one, access method. > > So the problems you describe are unrelated to "all or

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

On Mon, Dec 24, 2007 at 02:22:10AM -0500, Jeff Garzik wrote: The phrase all or none specifically describes the current practice in arch/x86/pci/mmconfig_{32,64}.c whereby a PCI bus always has one, and only one, access method. So the problems you describe are unrelated to all or none as I

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

On Sun, Dec 23, 2007 at 10:15:10PM +0100, Martin Mares wrote: > > - During that probe, you set a flag if any device has capabilities that > > extend beyond 0xff. > > Can this work? The extended capabilities are not linked to the normal > ones in any way. Good point. OTOH, we *do* have a flag

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote: > Failures are more predictable and more consistent with an all-or-none > scenario. The all-or-none solutions are the least complex on the software > side, and far more widely tested than any mixed config access scheme. Nope. The

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

On Sun, Dec 23, 2007 at 12:44:30AM -0500, Jeff Garzik wrote: Failures are more predictable and more consistent with an all-or-none scenario. The all-or-none solutions are the least complex on the software side, and far more widely tested than any mixed config access scheme. Nope. The vast

Re: [patch] Make MMCONFIG space (extended PCI config space) a driver opt-in issue

On Sun, Dec 23, 2007 at 10:15:10PM +0100, Martin Mares wrote: - During that probe, you set a flag if any device has capabilities that extend beyond 0xff. Can this work? The extended capabilities are not linked to the normal ones in any way. Good point. OTOH, we *do* have a flag for the

Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

On Thu, Dec 20, 2007 at 12:08:33PM -0700, Matthew Wilcox wrote: > On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote: > > Does anybody see a down side to this? > > It'll be slower than it would be if we used mmconfig directly. Now yes, > nobody should be using pci config space in

[PATCH] mm: fix exit_mmap BUG() on a.out binary exit

hitectures are affected as well. Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]> --- fs/binfmt_aout.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c index e176d19..7596e1e 100644 --- a/fs/binfmt_aout.c +++ b/fs/binfmt_aout.c

Re: PCI resource problems caused by improper address rounding

ss when its respective resource gets allocated above the 4G mark. Note that we cannot yet guarantee correct resource allocations above 4G, though it might work in some simple cases. Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]> --- drivers/pci/setup-bus.c |7 +-- 1 files changed

Re: PCI resource problems caused by improper address rounding

cannot yet guarantee correct resource allocations above 4G, though it might work in some simple cases. Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] --- drivers/pci/setup-bus.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci

[PATCH] mm: fix exit_mmap BUG() on a.out binary exit

are affected as well. Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] --- fs/binfmt_aout.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/fs/binfmt_aout.c b/fs/binfmt_aout.c index e176d19..7596e1e 100644 --- a/fs/binfmt_aout.c +++ b/fs/binfmt_aout.c @@ -319,7 +319,6 @@ static

Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

On Thu, Dec 20, 2007 at 12:08:33PM -0700, Matthew Wilcox wrote: On Thu, Dec 20, 2007 at 02:04:31PM -0500, Tony Camuso wrote: Does anybody see a down side to this? It'll be slower than it would be if we used mmconfig directly. Now yes, nobody should be using pci config space in performance

Re: [PATCH 1/3] pci: Add pci_enable_device_{io,mem} intefaces

On Thu, Dec 20, 2007 at 03:28:08PM +1100, Benjamin Herrenschmidt wrote: > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Acked-by: Ivan Kokshaysky <[EMAIL PROTECTED]> Ivan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the bo

Re: [RFC/PATCH]] x86: pci: Disable IO/Mem on a device when resources can't be allocated

On Wed, Dec 19, 2007 at 04:10:19PM +1100, Benjamin Herrenschmidt wrote: > This patch changes the x86 PCI code to disable IO and/or Memory > decoding on a PCI device when a resource of that type failed to > be allocated. Oh, this opens up a can of worms ;-) In ideal world, the patch would be

Re: [RFC/PATCH]] x86: pci: Disable IO/Mem on a device when resources can't be allocated

On Wed, Dec 19, 2007 at 04:10:19PM +1100, Benjamin Herrenschmidt wrote: This patch changes the x86 PCI code to disable IO and/or Memory decoding on a PCI device when a resource of that type failed to be allocated. Oh, this opens up a can of worms ;-) In ideal world, the patch would be

Re: [PATCH 1/3] pci: Add pci_enable_device_{io,mem} intefaces

On Thu, Dec 20, 2007 at 03:28:08PM +1100, Benjamin Herrenschmidt wrote: Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: Ivan Kokshaysky [EMAIL PROTECTED] Ivan. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED

Re: PCI resource problems caused by improper address rounding

On Tue, Dec 18, 2007 at 12:22:34PM -0800, Richard Henderson wrote: > On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote: > > ... and that would be an X server issue!). > > Of course, fixing the X server to *handle* 64-bit BARs is the correct > solution. I've no idea how involved that

Re: [RFC/PATCH 4/4] [POWERPC] pci: Disable IO/Mem on a device when resources can't be allocated

On Tue, Dec 18, 2007 at 10:01:15AM +1100, Benjamin Herrenschmidt wrote: > @@ -1040,7 +1040,10 @@ static inline void __devinit alloc_resou > r->flags |= IORESOURCE_UNSET; > r->end -= r->start; > r->start = 0; Perhaps we should use IORESOURCE_UNSET

Re: [RFC/PATCH 1/4] pci: Add pci_enable_device_{io,mem} intefaces

On Tue, Dec 18, 2007 at 11:02:37AM +1100, Benjamin Herrenschmidt wrote: > +EXPORT_SYMBOL(pci_enable_device_io); > +EXPORT_SYMBOL(pci_enable_device_mem); > EXPORT_SYMBOL(pci_enable_device); Wouldn't it be better to export only the pci_enable_device_flags() and make these three just "static

Re: [RFC/PATCH 1/4] pci: Add pci_enable_device_{io,mem} intefaces

On Tue, Dec 18, 2007 at 11:02:37AM +1100, Benjamin Herrenschmidt wrote: +EXPORT_SYMBOL(pci_enable_device_io); +EXPORT_SYMBOL(pci_enable_device_mem); EXPORT_SYMBOL(pci_enable_device); Wouldn't it be better to export only the pci_enable_device_flags() and make these three just static inline

Re: [RFC/PATCH 4/4] [POWERPC] pci: Disable IO/Mem on a device when resources can't be allocated

On Tue, Dec 18, 2007 at 10:01:15AM +1100, Benjamin Herrenschmidt wrote: @@ -1040,7 +1040,10 @@ static inline void __devinit alloc_resou r-flags |= IORESOURCE_UNSET; r-end -= r-start; r-start = 0; Perhaps we should use IORESOURCE_UNSET universally...

Re: PCI resource problems caused by improper address rounding

On Tue, Dec 18, 2007 at 12:22:34PM -0800, Richard Henderson wrote: On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote: ... and that would be an X server issue!). Of course, fixing the X server to *handle* 64-bit BARs is the correct solution. I've no idea how involved that is,

Re: [PATCH] PCI: fix for quirk_e100_interrupt()

On Mon, Dec 17, 2007 at 01:57:33PM -0800, Kok, Auke wrote: > what kind of platform actually is doing this? It almost seems like something > is > wrong with that platform's BIOS and I wonder if this workaround should not be > more > general (IOW is it not just e100 that is affected but other

[PATCH] PCI: fix for quirk_e100_interrupt()

Check that the e100 is in the D0 power state. If it's not, it won't respond to MMIO accesses and we end up with master-abort machine checks on some platforms. Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]> --- drivers/pci/quirks.c | 14 +- 1 files changed, 13 insertions

[PATCH] PCI: fix for quirk_e100_interrupt()

Check that the e100 is in the D0 power state. If it's not, it won't respond to MMIO accesses and we end up with master-abort machine checks on some platforms. Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] --- drivers/pci/quirks.c | 14 +- 1 files changed, 13 insertions(+), 1

Re: [PATCH] PCI: fix for quirk_e100_interrupt()

On Mon, Dec 17, 2007 at 01:57:33PM -0800, Kok, Auke wrote: what kind of platform actually is doing this? It almost seems like something is wrong with that platform's BIOS and I wonder if this workaround should not be more general (IOW is it not just e100 that is affected but other

Re: Possible issue with dangling PCI BARs

On Fri, Dec 14, 2007 at 07:51:06AM +1100, Benjamin Herrenschmidt wrote: > If the device is behind a P2P bridge and the BIOS has set the windows of > that bridge so tightly that there is no room to allocate the MMIO BAR, > then a full disable/full enable would fail on a device that would >

Re: Possible issue with dangling PCI BARs

On Thu, Dec 13, 2007 at 10:20:20PM +1100, Benjamin Herrenschmidt wrote: > I may have not fully undestood you in my previous reply. You are proposing > replacing pci_enable_device_bars() with a pair of pci_enable_device_io/mem ? > > I think that would be a good idea indeed. I'm all for it. Never

[patch] alpha: build fixes

init.refok section; - unbreak CPU-specific optimization: rearrange cpuflags-y assignments so that extended -mcpu value (ev56, pca56, ev67) overrides basic one (ev5, ev6) and not vice versa. Signed-off-by: Ivan Kokshaysky <[EMAIL PROTECTED]> Ivan. --- 2.6.24-rc5/arch/alpha/Makefile

Re: Possible issue with dangling PCI BARs

On Thu, Dec 13, 2007 at 04:26:42PM +1100, Benjamin Herrenschmidt wrote: > I can try to whip up some code tomorrow I suppose, though I'm always > afraid some dodgy x86 setup will blow up... That scares me too, but something like pci_dangling_bar(dev, idx) with a default (for now) no-op

Re: Possible issue with dangling PCI BARs

On Wed, Dec 12, 2007 at 10:22:22PM -0600, Robert Hancock wrote: > For the case where you say "I want to enable decoding for this MMIO BAR, > but not that one", though, I don't see an obvious way to provide that > guarantee with certainty. Normally, one would expect that if a BAR is > mapped

Re: Possible issue with dangling PCI BARs

On Wed, Dec 12, 2007 at 10:22:22PM -0600, Robert Hancock wrote: For the case where you say I want to enable decoding for this MMIO BAR, but not that one, though, I don't see an obvious way to provide that guarantee with certainty. Normally, one would expect that if a BAR is mapped safely

Re: Possible issue with dangling PCI BARs

On Thu, Dec 13, 2007 at 04:26:42PM +1100, Benjamin Herrenschmidt wrote: I can try to whip up some code tomorrow I suppose, though I'm always afraid some dodgy x86 setup will blow up... That scares me too, but something like pci_dangling_bar(dev, idx) with a default (for now) no-op

[patch] alpha: build fixes

section; - unbreak CPU-specific optimization: rearrange cpuflags-y assignments so that extended -mcpu value (ev56, pca56, ev67) overrides basic one (ev5, ev6) and not vice versa. Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] Ivan. --- 2.6.24-rc5/arch/alpha/Makefile 2007-12-04 13:08

Re: Possible issue with dangling PCI BARs

On Thu, Dec 13, 2007 at 10:20:20PM +1100, Benjamin Herrenschmidt wrote: I may have not fully undestood you in my previous reply. You are proposing replacing pci_enable_device_bars() with a pair of pci_enable_device_io/mem ? I think that would be a good idea indeed. I'm all for it. Never

Re: Possible issue with dangling PCI BARs

On Fri, Dec 14, 2007 at 07:51:06AM +1100, Benjamin Herrenschmidt wrote: If the device is behind a P2P bridge and the BIOS has set the windows of that bridge so tightly that there is no room to allocate the MMIO BAR, then a full disable/full enable would fail on a device that would otherwise

[patch] alpha: strncpy/strncat fixes

PATH strings generated in uevent and therefore to udev problems. strncpy.S: unrelated bug I found while testing the above fix - destination is not properly zero-padded then a byte count exceeds source length. Actually this is addition to strncpy fix from last year. Signed-off-by: Ivan Koksha

[patch] alpha: strncpy/strncat fixes

generated in uevent and therefore to udev problems. strncpy.S: unrelated bug I found while testing the above fix - destination is not properly zero-padded then a byte count exceeds source length. Actually this is addition to strncpy fix from last year. Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

On Mon, Dec 10, 2007 at 09:08:53AM -0600, Bob Tracy wrote: > Ivan Kokshaysky wrote: > > For now I have reassigned the bug #9457 to myself and will gradually hack > > into udev... > > Thanks... Let me know if there's anything useful I can do to help. It turns out to be yet

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

On Mon, Dec 10, 2007 at 09:08:53AM -0600, Bob Tracy wrote: Ivan Kokshaysky wrote: For now I have reassigned the bug #9457 to myself and will gradually hack into udev... Thanks... Let me know if there's anything useful I can do to help. It turns out to be yet another strncpy() bug

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

On Sat, Dec 08, 2007 at 10:19:39PM -0600, Bob Tracy wrote: > I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my > machine starts working again if I disable it? Sheesh... Incredible... Toggling CONFIG_MAGIC_SYSRQ works for me too, so I'm finally able to reproduce the problem

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

On Sat, Dec 08, 2007 at 10:19:39PM -0600, Bob Tracy wrote: I *do* have CONFIG_MAGIC_SYSRQ set. Anyone care to bet whether my machine starts working again if I disable it? Sheesh... Incredible... Toggling CONFIG_MAGIC_SYSRQ works for me too, so I'm finally able to reproduce the problem (which

Re: PCI: Fix boot-time hang on G31/G33 PC

On Wed, Sep 26, 2007 at 03:20:40PM -0700, Jesse Barnes wrote: > Ivan, your concern is about disabling things like interrupt controllers > and power management chips during probe right? You're right that doing > that could cause problems if we get and interrupt or PMU event at just > the wrong

Re: PCI: Fix boot-time hang on G31/G33 PC

On Wed, Sep 26, 2007 at 03:20:40PM -0700, Jesse Barnes wrote: Ivan, your concern is about disabling things like interrupt controllers and power management chips during probe right? You're right that doing that could cause problems if we get and interrupt or PMU event at just the wrong

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Tue, Sep 18, 2007 at 06:30:23AM +1000, Benjamin Herrenschmidt wrote: > At this stage (but we are getting a bit OT), ppc has something like 3 > different PCI code implementations :-) I do have some plans to fix that > by switching everybody to use pci_assign_unassigned_resources() and > friends

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Mon, Sep 17, 2007 at 09:21:47AM +0800, Shaohua Li wrote: > I can confirm this is an add-in graphics card. the bfd is 00:02.0, so > it's not behind any AGP/PCI-E bridge. AFAIKS, 00:02.0 is *integrated* controller. Can you check that "graphic adapter priority" setting in BIOS is "PCI Express"

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Mon, Sep 17, 2007 at 09:21:47AM +0800, Shaohua Li wrote: I can confirm this is an add-in graphics card. the bfd is 00:02.0, so it's not behind any AGP/PCI-E bridge. AFAIKS, 00:02.0 is *integrated* controller. Can you check that graphic adapter priority setting in BIOS is PCI Express and not

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Tue, Sep 18, 2007 at 06:30:23AM +1000, Benjamin Herrenschmidt wrote: At this stage (but we are getting a bit OT), ppc has something like 3 different PCI code implementations :-) I do have some plans to fix that by switching everybody to use pci_assign_unassigned_resources() and friends but

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote: > Agreed. I have a similar problem on ppc where it's common to have things > like the main PIC on a PCI device. Note that another problem is (or at > least was, i haven't checked recently) the P2P bridge scanning code > that,

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Sun, Sep 16, 2007 at 01:52:59PM -0600, Matthew Wilcox wrote: > I don't think it would be that complicated. We could just delay probing > for mmconfig until after the pci bus probes are done. No changes to > other architectures needed. Indeed. Seems like it's a way to go. > I'm really

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Sun, Sep 16, 2007 at 11:34:35AM -0600, Robert Hancock wrote: > > The most interesting fact there is that windows *does not* clear > > PCI_COMMAND_MEMORY bits during PCI bus enumeration, so BIOS writers > > have to rely on that. Yet another reason why your patch is unsafe. > > Windows 98

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Sun, Sep 16, 2007 at 11:34:35AM -0600, Robert Hancock wrote: The most interesting fact there is that windows *does not* clear PCI_COMMAND_MEMORY bits during PCI bus enumeration, so BIOS writers have to rely on that. Yet another reason why your patch is unsafe. Windows 98 doesn't, it

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Sun, Sep 16, 2007 at 01:52:59PM -0600, Matthew Wilcox wrote: I don't think it would be that complicated. We could just delay probing for mmconfig until after the pci bus probes are done. No changes to other architectures needed. Indeed. Seems like it's a way to go. I'm really

Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote: Agreed. I have a similar problem on ppc where it's common to have things like the main PIC on a PCI device. Note that another problem is (or at least was, i haven't checked recently) the P2P bridge scanning code that, in a

  1   2   3   4   >