* Re: mpc5200b and floating point
From: Dan Malek @ 2006-03-31 18:58 UTC (permalink / raw)
To: Roger Larsson; +Cc: linuxppc-embedded
In-Reply-To: <200603312027.22359.roger.larsson@norran.net>
On Mar 31, 2006, at 1:27 PM, Roger Larsson wrote:
> Since a lot of PowerPC do not have floating point processor your tools
> might be setup to compile without it (compare with sse2 on x86).
Nearly all of the PowerPC do have floating point, only a few do not.
It's highly unlikely to find a PowerPC tool set that was custom
built to not enable floating point. Don't forget that the compiler
flags are only a small part of the picture, you need matching
compiler run time support and application libraries as well.
Just using the compiler flags and not selecting the proper
libraries will not be a positive experience.
-- Dan
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Linas Vepstas @ 2006-03-31 17:06 UTC (permalink / raw)
To: Greg KH
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <20060331054654.GA6632@kroah.com>
On Thu, Mar 30, 2006 at 09:46:54PM -0800, Greg KH wrote:
>
> (hint, use a tab...)
glurg.
[PATCH]: e1000: prevent statistics from getting garbled during reset.
If a PCI bus error/fault triggers a PCI bus reset, attempts to get the
ethernet packet count statistics from the hardware will fail, returning
garbage data upstream. This patch skips statistics data collection
if the PCI device is not on the bus.
This patch presumes that an earlier patch,
[PATCH] PCI Error Recovery: e1000 network device driver
has already been applied.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/net/e1000/e1000_main.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.16-git6/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.16-git6.orig/drivers/net/e1000/e1000_main.c 2006-03-30 17:51:37.924162779 -0600
+++ linux-2.6.16-git6/drivers/net/e1000/e1000_main.c 2006-03-30 17:54:07.659188391 -0600
@@ -3069,14 +3069,18 @@ void
e1000_update_stats(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
+ struct pci_dev *pdev = adapter->pdev;
unsigned long flags;
uint16_t phy_tmp;
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
- /* Prevent stats update while adapter is being reset */
+ /* Prevent stats update while adapter is being reset,
+ * or if the pci connection is down. */
if (adapter->link_speed == 0)
return;
+ if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
+ return;
spin_lock_irqsave(&adapter->stats_lock, flags);
^ permalink raw reply
* Re: mpc5200b and floating point
From: White @ 2006-03-31 18:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060331133619.GD7738@localhost.localdomain>
Am Fri, 31 Mar 2006 15:36:20 +0200 schrieb Sascha Hauer
<s.hauer@pengutronix.de> :
Please check your Toolchain.
Have you build it ?
Do you use glibc or something like uclibc ?
At my beginning with mpc5200 i hat simular problems.
I had the wrong Compilerflags during build of my ToolChain.
(uclibc).
Good Luck.
> Hi,
>
> I'm working with a mpc5200b custom board and I'm trying to run an
> application with floating point. All floating point variables seem to
> zero all the time. Since I'm not very familiar with powerpc it might be
> something stupid I have overlooked.
> Any hints?
>
> Thank you,
>
> Sascha Hauer
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: mpc5200b and floating point
From: Roger Larsson @ 2006-03-31 18:27 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060331133619.GD7738@localhost.localdomain>
On fredag 31 mars 2006 15.36, Sascha Hauer wrote:
> Hi,
>
> I'm working with a mpc5200b custom board and I'm trying to run an
> application with floating point. All floating point variables seem to
> zero all the time. Since I'm not very familiar with powerpc it might be
> something stupid I have overlooked.
Since a lot of PowerPC do not have floating point processor your tools
might be setup to compile without it (compare with sse2 on x86).
Check your compiler flags again.
Define -mcpu= and -mhard-float
Undefine -msoft-float
/RogerL
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: EEH Cleanup
From: Linas Vepstas @ 2006-03-31 18:04 UTC (permalink / raw)
To: Nathan Fontenot, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200603311013.22208.nfont@austin.ibm.com>
Please apply.
This patch removes unnecessary exports, marks functions as static when
possible, and simplifies some list-related code.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
Paul, please apply and forward upstream.
On Fri, Mar 31, 2006 at 10:13:21AM -0600, Nathan Fontenot wrote:
> This patch removes unnecessary exports, marks functions as static when
> possible, and simplifies some list-related code.
Nathan's original patch did not apply cleanly for me, nor did it build
cleanly. However, the one below does.
Linas.
arch/powerpc/platforms/pseries/eeh.c | 62 ++++++++++++++++-------------------
include/asm-powerpc/eeh.h | 20 -----------
2 files changed, 30 insertions(+), 52 deletions(-)
Index: linux-2.6.16-git19/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.16-git19.orig/arch/powerpc/platforms/pseries/eeh.c 2006-03-31 11:38:49.000000000 -0600
+++ linux-2.6.16-git19/arch/powerpc/platforms/pseries/eeh.c 2006-03-31 11:54:24.901762378 -0600
@@ -865,7 +865,7 @@ void __init eeh_init(void)
* on the CEC architecture, type of the device, on earlier boot
* command-line arguments & etc.
*/
-void eeh_add_device_early(struct device_node *dn)
+static void eeh_add_device_early(struct device_node *dn)
{
struct pci_controller *phb;
struct eeh_early_enable_info info;
@@ -882,7 +882,6 @@ void eeh_add_device_early(struct device_
info.buid_lo = BUID_LO(phb->buid);
early_enable_eeh(dn, &info);
}
-EXPORT_SYMBOL_GPL(eeh_add_device_early);
void eeh_add_device_tree_early(struct device_node *dn)
{
@@ -893,20 +892,6 @@ void eeh_add_device_tree_early(struct de
}
EXPORT_SYMBOL_GPL(eeh_add_device_tree_early);
-void eeh_add_device_tree_late(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- eeh_add_device_late(dev);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
- struct pci_bus *subbus = dev->subordinate;
- if (subbus)
- eeh_add_device_tree_late(subbus);
- }
- }
-}
-
/**
* eeh_add_device_late - perform EEH initialization for the indicated pci device
* @dev: pci device for which to set up EEH
@@ -914,7 +899,7 @@ void eeh_add_device_tree_late(struct pci
* This routine must be used to complete EEH initialization for PCI
* devices that were added after system boot (e.g. hotplug, dlpar).
*/
-void eeh_add_device_late(struct pci_dev *dev)
+static void eeh_add_device_late(struct pci_dev *dev)
{
struct device_node *dn;
struct pci_dn *pdn;
@@ -933,16 +918,33 @@ void eeh_add_device_late(struct pci_dev
pci_addr_cache_insert_device (dev);
}
-EXPORT_SYMBOL_GPL(eeh_add_device_late);
+
+void eeh_add_device_tree_late(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ eeh_add_device_late(dev);
+ if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+ struct pci_bus *subbus = dev->subordinate;
+ if (subbus)
+ eeh_add_device_tree_late(subbus);
+ }
+ }
+}
+EXPORT_SYMBOL_GPL(eeh_add_device_tree_late);
/**
* eeh_remove_device - undo EEH setup for the indicated pci device
* @dev: pci device to be removed
*
- * This routine should be when a device is removed from a running
- * system (e.g. by hotplug or dlpar).
+ * This routine should be called when a device is removed from
+ * a running system (e.g. by hotplug or dlpar). It unregisters
+ * the PCI device from the EEH subsystem. I/O errors affecting
+ * this device will no longer be detected after this call; thus,
+ * i/o errors affecting this slot may leave this device unusable.
*/
-void eeh_remove_device(struct pci_dev *dev)
+static void eeh_remove_device(struct pci_dev *dev)
{
struct device_node *dn;
if (!dev || !eeh_subsystem_enabled)
@@ -958,21 +960,17 @@ void eeh_remove_device(struct pci_dev *d
PCI_DN(dn)->pcidev = NULL;
pci_dev_put (dev);
}
-EXPORT_SYMBOL_GPL(eeh_remove_device);
void eeh_remove_bus_device(struct pci_dev *dev)
{
+ struct pci_bus *bus = dev->subordinate;
+ struct pci_dev *child, *tmp;
+
eeh_remove_device(dev);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
- struct pci_bus *bus = dev->subordinate;
- struct list_head *ln;
- if (!bus)
- return;
- for (ln = bus->devices.next; ln != &bus->devices; ln = ln->next) {
- struct pci_dev *pdev = pci_dev_b(ln);
- if (pdev)
- eeh_remove_bus_device(pdev);
- }
+
+ if (bus && dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+ list_for_each_entry_safe(child, tmp, &bus->devices, bus_list)
+ eeh_remove_bus_device(child);
}
}
EXPORT_SYMBOL_GPL(eeh_remove_bus_device);
Index: linux-2.6.16-git19/include/asm-powerpc/eeh.h
===================================================================
--- linux-2.6.16-git19.orig/include/asm-powerpc/eeh.h 2006-03-19 23:53:29.000000000 -0600
+++ linux-2.6.16-git19/include/asm-powerpc/eeh.h 2006-03-31 11:47:35.000000000 -0600
@@ -60,24 +60,10 @@ void __init pci_addr_cache_build(void);
* device (including config space i/o). Call eeh_add_device_late
* to finish the eeh setup for this device.
*/
-void eeh_add_device_early(struct device_node *);
-void eeh_add_device_late(struct pci_dev *dev);
void eeh_add_device_tree_early(struct device_node *);
void eeh_add_device_tree_late(struct pci_bus *);
/**
- * eeh_remove_device - undo EEH setup for the indicated pci device
- * @dev: pci device to be removed
- *
- * This routine should be called when a device is removed from
- * a running system (e.g. by hotplug or dlpar). It unregisters
- * the PCI device from the EEH subsystem. I/O errors affecting
- * this device will no longer be detected after this call; thus,
- * i/o errors affecting this slot may leave this device unusable.
- */
-void eeh_remove_device(struct pci_dev *);
-
-/**
* eeh_remove_device_recursive - undo EEH for device & children.
* @dev: pci device to be removed
*
@@ -116,12 +102,6 @@ static inline int eeh_dn_check_failure(s
static inline void pci_addr_cache_build(void) { }
-static inline void eeh_add_device_early(struct device_node *dn) { }
-
-static inline void eeh_add_device_late(struct pci_dev *dev) { }
-
-static inline void eeh_remove_device(struct pci_dev *dev) { }
-
static inline void eeh_add_device_tree_early(struct device_node *dn) { }
static inline void eeh_add_device_tree_late(struct pci_bus *bus) { }
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Rick Jones @ 2006-03-31 17:36 UTC (permalink / raw)
Cc: netdev, linux-pci, linux-kernel, linuxppc-dev
In-Reply-To: <20060331170319.GV2172@austin.ibm.com>
> 2) What's wrong with taking deltas? Typical through-put performance
> measurement is done by pre-loading the pipes (i.e. running for
> a few minutes wihtout measuring, then starting the measurement).
> I'd think that snapshotting the numbers would be easier, and is
> trivially doable in user-space. I guess I don't understand why
> you need a new kernel featre to imlement this.
ftp://ftp.cup.hp.com/dist/networking/tools/beforeafter.tar.gz
Not my code, I've used it with success against ethtool -S output.
rick jones
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Jeff V. Merkey @ 2006-03-31 18:40 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <20060331170319.GV2172@austin.ibm.com>
Linas Vepstas wrote:
>On Thu, Mar 30, 2006 at 09:14:56PM -0700, Jeffrey V. Merkey wrote:
>
>
>>Yes, we need one. The adapter needs to maintain these stats from the
>>registers in the kernel structure and not
>>its own local variables.
>>
>>
>
>Did you read the code to see what the adapter does with these stats?
>Among other things, it uses them to adaptively modulate transmit rates
>to avoid collisions. Just clearing the hardware-private stats will mess
>up that function.
>
>
>
I noticed that.
>>That way, when someone calls to clear the stats
>>for testing and analysis purposes,
>>they zero out and are reset.
>>
>>
>
>1) ifdown/ifup is guarenteed to to clear things. Try that.
>
>
No, not dynamic. I'll patch the driver locally, thanks.
Jeff
>2) What's wrong with taking deltas? Typical through-put performance
>measurement is done by pre-loading the pipes (i.e. running for
>a few minutes wihtout measuring, then starting the measurement).
>I'd think that snapshotting the numbers would be easier, and is
>trivially doable in user-space. I guess I don't understand why
>you need a new kernel featre to imlement this.
>
>--linas
>
>
>
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Linas Vepstas @ 2006-03-31 17:03 UTC (permalink / raw)
To: Jeffrey V. Merkey
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <442CACC0.1060308@wolfmountaingroup.com>
On Thu, Mar 30, 2006 at 09:14:56PM -0700, Jeffrey V. Merkey wrote:
> Yes, we need one. The adapter needs to maintain these stats from the
> registers in the kernel structure and not
> its own local variables.
Did you read the code to see what the adapter does with these stats?
Among other things, it uses them to adaptively modulate transmit rates
to avoid collisions. Just clearing the hardware-private stats will mess
up that function.
> That way, when someone calls to clear the stats
> for testing and analysis purposes,
> they zero out and are reset.
1) ifdown/ifup is guarenteed to to clear things. Try that.
2) What's wrong with taking deltas? Typical through-put performance
measurement is done by pre-loading the pipes (i.e. running for
a few minutes wihtout measuring, then starting the measurement).
I'd think that snapshotting the numbers would be easier, and is
trivially doable in user-space. I guess I don't understand why
you need a new kernel featre to imlement this.
--linas
^ permalink raw reply
* [PATCH] powerpc/pseries: EEH Cleanup
From: Nathan Fontenot @ 2006-03-31 16:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
This patch removes unnecessary exports, marks functions as static when
possible, and simplifies some list-related code.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Index: nfont/kernel/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- nfont.orig/kernel/arch/powerpc/platforms/pseries/eeh.c 2006-03-27
16:04:52.%N -0600
+++ nfont/kernel/arch/powerpc/platforms/pseries/eeh.c 2006-03-31 09:02:17.%N
-0600
@@ -865,7 +865,7 @@ void __init eeh_init(void)
* on the CEC architecture, type of the device, on earlier boot
* command-line arguments & etc.
*/
-void eeh_add_device_early(struct device_node *dn)
+static void eeh_add_device_early(struct device_node *dn)
{
struct pci_controller *phb;
struct eeh_early_enable_info info;
@@ -882,7 +882,6 @@ void eeh_add_device_early(struct device_
info.buid_lo = BUID_LO(phb->buid);
early_enable_eeh(dn, &info);
}
-EXPORT_SYMBOL_GPL(eeh_add_device_early);
void eeh_add_device_tree_early(struct device_node *dn)
{
@@ -914,7 +913,7 @@ void eeh_add_device_tree_late(struct pci
* This routine must be used to complete EEH initialization for PCI
* devices that were added after system boot (e.g. hotplug, dlpar).
*/
-void eeh_add_device_late(struct pci_dev *dev)
+static void eeh_add_device_late(struct pci_dev *dev)
{
struct device_node *dn;
struct pci_dn *pdn;
@@ -933,16 +932,18 @@ void eeh_add_device_late(struct pci_dev
pci_addr_cache_insert_device (dev);
}
-EXPORT_SYMBOL_GPL(eeh_add_device_late);
/**
* eeh_remove_device - undo EEH setup for the indicated pci device
* @dev: pci device to be removed
*
- * This routine should be when a device is removed from a running
- * system (e.g. by hotplug or dlpar).
+ * This routine should be called when a device is removed from
+ * a running system (e.g. by hotplug or dlpar). It unregisters
+ * the PCI device from the EEH subsystem. I/O errors affecting
+ * this device will no longer be detected after this call; thus,
+ * i/o errors affecting this slot may leave this device unusable.
*/
-void eeh_remove_device(struct pci_dev *dev)
+static void eeh_remove_device(struct pci_dev *dev)
{
struct device_node *dn;
if (!dev || !eeh_subsystem_enabled)
@@ -958,22 +959,18 @@ void eeh_remove_device(struct pci_dev *d
PCI_DN(dn)->pcidev = NULL;
pci_dev_put (dev);
}
-EXPORT_SYMBOL_GPL(eeh_remove_device);
void eeh_remove_bus_device(struct pci_dev *dev)
{
+ struct pci_bus *bus = dev->subordinate;
+ struct pci_dev *child, *tmp;
+
eeh_remove_device(dev);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
- struct pci_bus *bus = dev->subordinate;
- struct list_head *ln;
- if (!bus)
- return;
- for (ln = bus->devices.next; ln != &bus->devices; ln =
ln->next) {
- struct pci_dev *pdev = pci_dev_b(ln);
- if (pdev)
- eeh_remove_bus_device(pdev);
- }
- }
+
+ if (bus && dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+ list_for_each_entry_safe(child, tmp, &bus->devices, bus_list)
+ eeh_remove_bus_device(child);
+ }
}
EXPORT_SYMBOL_GPL(eeh_remove_bus_device);
Index: nfont/kernel/include/asm-powerpc/eeh.h
===================================================================
--- nfont.orig/kernel/include/asm-powerpc/eeh.h 2006-03-27 16:05:00.%N -0600
+++ nfont/kernel/include/asm-powerpc/eeh.h 2006-03-29 15:26:57.%N -0600
@@ -60,24 +60,10 @@ void __init pci_addr_cache_build(void);
* device (including config space i/o). Call eeh_add_device_late
* to finish the eeh setup for this device.
*/
-void eeh_add_device_early(struct device_node *);
-void eeh_add_device_late(struct pci_dev *dev);
void eeh_add_device_tree_early(struct device_node *);
void eeh_add_device_tree_late(struct pci_bus *);
/**
- * eeh_remove_device - undo EEH setup for the indicated pci device
- * @dev: pci device to be removed
- *
- * This routine should be called when a device is removed from
- * a running system (e.g. by hotplug or dlpar). It unregisters
- * the PCI device from the EEH subsystem. I/O errors affecting
- * this device will no longer be detected after this call; thus,
- * i/o errors affecting this slot may leave this device unusable.
- */
-void eeh_remove_device(struct pci_dev *);
-
-/**
* eeh_remove_device_recursive - undo EEH for device & children.
* @dev: pci device to be removed
*
@@ -116,12 +102,6 @@ static inline int eeh_dn_check_failure(s
static inline void pci_addr_cache_build(void) { }
-static inline void eeh_add_device_early(struct device_node *dn) { }
-
-static inline void eeh_add_device_late(struct pci_dev *dev) { }
-
-static inline void eeh_remove_device(struct pci_dev *dev) { }
-
static inline void eeh_add_device_tree_early(struct device_node *dn) { }
static inline void eeh_add_device_tree_late(struct pci_bus *bus) { }
^ permalink raw reply
* [PATCH Resend] misc lparcfg fixes
From: Will Schmidt @ 2006-03-31 15:07 UTC (permalink / raw)
To: linuxppc-dev, paulus, will_schmidt
Please apply...
(Resending with patch inline)
This patch fixed several problems with the lparcfg code. In case
someone gets a sense of deja-vu, part of this was submitted last Sep, I
thought the changes went in, but either got backed out, or just got
lost.
First, change the local_buffer declaration to be unsigned char *. We
had a bad-math problem in a 2.4 tree which was built with a
"-fsigned-char" parm. I dont believe we ever build with that parm
now-a-days, but to be safe, I'd prefer the declaration be explicit.
Second, fix a bad math calculation for splpar_strlen.
Third, on the rtas_call for get-system-parameter, pass in
RTAS_DATA_BUF_SIZE for the rtas_data_buf size, instead of letting random
data determine the size. Until recently, we've had a sufficiently
large 'random data' value get passed in, so the function just happens to
have worked OK. Now it's getting passed a '0', which causes the
rtas_call to return success, but no data shows up in the buffer.
(oops!). This was found by the LTC test org.
This is in a branch of code that only gets run on SPLPAR systems.
Tested on power5 Lpar.
Signed-off-by: Will Schmidt <willschm@us.ibm.com>
---
diff -Naur 2.6/arch/powerpc/kernel/lparcfg.c 2.6.mar30/arch/powerpc/kernel/lparcfg.c
--- 2.6/arch/powerpc/kernel/lparcfg.c 2006-03-20 02:15:57.000000000 -0800
+++ 2.6.mar30/arch/powerpc/kernel/lparcfg.c 2006-03-30 12:06:34.323023840 -0800
@@ -37,7 +37,7 @@
#include <asm/prom.h>
#include <asm/vdso_datapage.h>
-#define MODULE_VERS "1.6"
+#define MODULE_VERS "1.7"
#define MODULE_NAME "lparcfg"
/* #define LPARCFG_DEBUG */
@@ -242,7 +242,7 @@
{
int call_status;
- char *local_buffer = kmalloc(SPLPAR_MAXLENGTH, GFP_KERNEL);
+ unsigned char *local_buffer = kmalloc(SPLPAR_MAXLENGTH, GFP_KERNEL);
if (!local_buffer) {
printk(KERN_ERR "%s %s kmalloc failure at line %d \n",
__FILE__, __FUNCTION__, __LINE__);
@@ -254,7 +254,8 @@
call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
NULL,
SPLPAR_CHARACTERISTICS_TOKEN,
- __pa(rtas_data_buf));
+ __pa(rtas_data_buf),
+ RTAS_DATA_BUF_SIZE);
memcpy(local_buffer, rtas_data_buf, SPLPAR_MAXLENGTH);
spin_unlock(&rtas_data_buf_lock);
@@ -275,7 +276,7 @@
#ifdef LPARCFG_DEBUG
printk(KERN_INFO "success calling get-system-parameter \n");
#endif
- splpar_strlen = local_buffer[0] * 16 + local_buffer[1];
+ splpar_strlen = local_buffer[0] * 256 + local_buffer[1];
local_buffer += 2; /* step over strlen value */
memset(workbuffer, 0, SPLPAR_MAXLENGTH);
^ permalink raw reply
* Re: snd-aoa: new apple sound driver
From: Johannes Berg @ 2006-03-31 14:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: debian-powerpc, Alastair Poole
In-Reply-To: <1143547826.13615.24.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
Just FYI if anyone's thinking about using this:
> GPIO stuff.
Started, you can now turn on/off the lineout/speakers/headphones (note:
powerbooks have line out, not headphones despite the symbol on them),
but automatic switching isn't done yet.
Only on new machines with PMFs though.
> Clock setting.
Done except for master/slave switching.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: moving board support from arch/ppc/ to arch/powerpc
From: Kumar Gala @ 2006-03-31 14:39 UTC (permalink / raw)
To: Zang Roy-r61911
Cc: linuxppc-dev list, Paul Mackerras, linux kernel mailing list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467305790AEB@zch01exm40.ap.freescale.net>
On Mar 31, 2006, at 4:44 AM, Zang Roy-r61911 wrote:
> Hi,
> I am moving mpc7448 hpc2 support from arch/ppc to arch/powerpc and
> plan to summit it to open source tree future. Is there any good
> suggestion or reference?
> Thanks a lot!
All ports under arch/powerpc are required to use a flat device tree
to boot. Look at Documentation/powerpc/booting-without-of.txt
for details on how that is done. Beyond that there isn't too much
different from arch/ppc to arch/powerpc. Take a look at the 83xx or
85xx platforms for comparison examples between arch/ppc & arch/powerpc.
I'd suggest for working up your flat dev tree for the bridge on HPC2
and post that to the linuxppc-dev list for review and then go from
there.
- kumar
^ permalink raw reply
* mpc5200b and floating point
From: Sascha Hauer @ 2006-03-31 13:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm working with a mpc5200b custom board and I'm trying to run an
application with floating point. All floating point variables seem to
zero all the time. Since I'm not very familiar with powerpc it might be
something stupid I have overlooked.
Any hints?
Thank you,
Sascha Hauer
^ permalink raw reply
* Re: Bestcomm Firmware update
From: Andrey Volkov @ 2006-03-31 11:41 UTC (permalink / raw)
To: bennett78; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <442C5A75.7030107@digis.net>
Hello, Frank.
On Friday, March 31, 2006, bennett78 wrote:
> SoSoComm Dudes:
VERY, VERY BIG thanks to you :-))), finally we can do something more
sensible with it (like scatter-gather).
> I was able to contact Davide Santo, AN2604 "Introduction to BestComm".
> He admitted
> the short commings of his document in the area of Firmware instruction
> info and gave
> me a name of a guy, Ed in the ASIC design area in Austin. Ed has agreed
> to answer
> questions, push for resources to provide a support tool and provided me
> with a document
> from their head programmer "SmartDMA Hand-Assembly Guides" (see attached
> pdf).
> With this secret decoded ring I was able to put together a disassembler,
> see attached
> disasm.c. Cut and paste your favorite Task into fw[] array at the
> beginning,
> "cc -o d disasm.c ; d" It's not perfect, but useful- Enjoy. Sorry I'm not
> sure where or if you guys want to check this stuff into a git
> repository, somewhere
> and hope ozlabs is not fussy about attachments!
But it could be start point for a kernel compiler :).
> If we can formulate a list of questions Ed might be able to help, I'll
> start:
> o what does init=31 mean?
> AN2604 say init=0 means always requestor and 31 is reserved but
> referenced
> alot in the F/W comments
> o Need more info on how MORE works
> o Tell us about LCD levels. Only 2? (let's call a LCD indent a level)
> LCD seems to reset DRD to 1A. DRD2B1or2 follow a DRD2A (ext=1)?
> o LCD[28:23]orLCD[20:15] or LCD[11:6] what is extraN?
> drop 101nnn - extraN
> add 1nnnnn - indexN
> o how many DRD2B1[2] can be stacked up?
> o when is/can a LDC Literal used? and how?
I'll reread my drafts at next week too, so may be this list will be
extended.
--
Regards,
Andrey Volkov
^ permalink raw reply
* Re: pci-x
From: Vitaly Bordug @ 2006-03-31 11:50 UTC (permalink / raw)
To: Carlos Mitidieri; +Cc: linuxppc-embedded
In-Reply-To: <200603310852.29987.carlos.mitidieri@sysgo.com>
On Fri, 31 Mar 2006 08:52:28 +0200
Carlos Mitidieri <carlos.mitidieri@sysgo.com> wrote:
> Hi,
>
> I am using a Rev PILOT board, S/N:0251
> To my discernment, a Rev PILOT is lower than a Rev A.
> Is that correct?
>
> By the way, thank you very much.
>
Yes, that is correct.
There are some notes in u-boot documentation also, that might be interesting for you:
<citate>
1.0 Nomenclature
For some reason, the HW designers describe the switch settings
in terms of 0 and 1, and then map that to physical switches where
the label "On" refers to logic 0 and "Off" (unlabeled) is logic 1.
Luckily, we're SW types and virtual settings are handled daily.
The switches for the Rev A board are numbered differently than
for the Pilot board. Oh yeah.
Switch bits are numbered 1 through, like, 4 6 8 or 10, but the
bits may contribute to signals that are numbered based at 0,
and some of those signals may be high-bit-number-0 too. Heed
well the names and labels and do not get confused.
"Off" == 1
"On" == 0
SW18 is switch 18 as silk-screened onto the board.
SW4[8] is the bit labled 8 on Switch 4.
SW2[1:6] refers to bits labeled 1 through 6 in order on switch 2
SW3[7:1] refers to bits labeled 7 through 1 in order on switch 3
1.1 For the MPC85xxADS Pilot Board
First, make sure the board default setting is consistent with the document
shipped with your board. Then apply the following changes:
SW3[1-6]="all OFF" (boot from 32bit flash, no boot sequence is used)
SW10[2-6]="all OFF" (turn on CPM SCC for serial port,works for 8540/8560)
SW11[2]='OFF for 8560, ON for 8540' (toggle 8540.8560 mode)
SW11[7]='ON' (rev2), 'OFF' (rev1)
SW4[7-8]="OFF OFF" (enable serial ports,I'm using the top serial connector)
SW22[1-4]="OFF OFF ON OFF"
SW5[1-10[="ON ON OFF OFF OFF OFF OFF OFF OFF OFF"
J1 = "Enable Prog" (Make sure your flash is programmable for development)
If you want to test PCI functionality with a 33Mhz PCI card, you will
have to change the system clock from the default 66Mhz to 33Mhz by
setting SW15[1]="OFF" and SW17[8]="OFF". After that you may also need
double your platform clock(SW6) because the system clock is now only
half of its original value. For example, if at 66MHz your system
clock showed SW6[0:1] = 01, then at 33MHz SW6[0:1] it should be 10.
SW17[8] ------+ SW6
SW15[1] ----+ | [0:1]
V V V V
33MHz 1 1 1 0
66MHz 0 0 0 1
Hmmm... That SW6 setting description is incomplete but it works.
1.3 For the MPC85xxADS Rev A Board
As shipped, the board should be a 33MHz PCI bus with a CPU Clock
rate of 825 +/- fuzz:
Clocks: CPU: 825 MHz, CCB: 330 MHz, DDR: 165 MHz, LBC: 82 MHz
For 33MHz PCI, the switch settings should be like this:
SW18[7:1] = 0100001 = M==33 => 33MHz
SW18[8] = 1 => PWD Divider == 16
SW16[1:2] = 11 => N == 16 as PWD==1
Use the magical formula:
Fout (MHz) = 16 * M / N = 16 * 33 / 16 = 33 MHz
SW7[1:4] = 1010 = 10 => 10 x 33 = 330 CCB Sysclk
SW7[5:6] = 01 => 5:2 x 330 = 825 Core clock
For 66MHz PCI, the switch settings should be like this:
SW18[7:1] = 0100001 = M==33 => 33MHz
SW18[8] = 0 => PWD Divider == 1
SW16[1:2] = 01 => N == 8 as PWD == 0
Use the magical formula:
Fout (MHz) = 16 * M / N = 16 * 33 / 8 = 66 MHz
SW7[1:4] = 0101 = 5 => 5 x 66 = 330 CCB
Sysclk SW7[5:6] = 01 => 5:2 x 330 = 825 Core
clock
</citate>
> > Are you using a Rev A or higher board? PCI-X doesn't work on earlier
> > systems.
> >
> > Also, make sure your board is configured to run PCI at 66 MHz. PCI-X
> > doesn't work at 33 MHz.
> >
> >
> > Andy Fleming
>
> Best regards,
> --
> Carlos Mitidieri
> SYSGO AG - Office Ulm
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] PowerMac11,2 i2c-bus@0 duplicate dev-tree workaround
From: Johannes Berg @ 2006-03-31 9:42 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1143783444.28005.10.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Fri, 2006-03-31 at 16:37 +1100, Michael Ellerman wrote:
> OK, that sounds a little complicated. I'm just worried about having lots
> workarounds in the unflattening code, the code's hard enough to read as
> it is.
Yeah that's a good argument.
> I think it's preferable to do the workarounds in the code that
> needs the workaround, that way they're isolated in certain parts of the
> code rather than all in the unflattening.
I'd really prefer to have these nodes vanish from the complete node
chain so we don't have the workarounds cluttering up the rather high
levels with machine dependent code. I'll find a better place to put it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: pci-x
From: Carlos Mitidieri @ 2006-03-31 6:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <621AE6AC-D37E-4EB5-9390-7050B654C692@freescale.com>
Hi,
I am using a Rev PILOT board, S/N:0251
To my discernment, a Rev PILOT is lower than a Rev A.
Is that correct?
By the way, thank you very much.
> Are you using a Rev A or higher board? PCI-X doesn't work on earlier
> systems.
>
> Also, make sure your board is configured to run PCI at 66 MHz. PCI-X
> doesn't work at 33 MHz.
>
>
> Andy Fleming
Best regards,
--
Carlos Mitidieri
SYSGO AG - Office Ulm
^ permalink raw reply
* Re: Bestcomm Firmware update
From: Sylvain Munaut @ 2006-03-31 6:12 UTC (permalink / raw)
To: bennett78; +Cc: linuxppc-embedded
In-Reply-To: <442C5A75.7030107@digis.net>
bennett78 wrote:
> SoSoComm Dudes:
>
> I was able to contact Davide Santo, AN2604 "Introduction to
> BestComm". He admitted
> the short commings of his document in the area of Firmware instruction
> info and gave
> me a name of a guy, Ed in the ASIC design area in Austin. Ed has
> agreed to answer
> questions, push for resources to provide a support tool and provided
> me with a document
> from their head programmer "SmartDMA Hand-Assembly Guides" (see
> attached pdf).
>
Great document ! At last some documentation ... Thanks very much !
> With this secret decoded ring I was able to put together a
> disassembler, see attached
> disasm.c. Cut and paste your favorite Task into fw[] array at the
> beginning,
> "cc -o d disasm.c ; d" It's not perfect, but useful- Enjoy. Sorry
> I'm not
> sure where or if you guys want to check this stuff into a git
> repository, somewhere
> and hope ozlabs is not fussy about attachments!
I can put it on line on a webserver. I guess Freescale gave you
permission to publish
this document ?
> If we can formulate a list of questions Ed might be able to help, I'll
> start:
> o what does init=31 mean?
> AN2604 say init=0 means always requestor and 31 is reserved but
> referenced
> alot in the F/W comments
> o Need more info on how MORE works
> o Tell us about LCD levels. Only 2? (let's call a LCD indent a level)
> LCD seems to reset DRD to 1A. DRD2B1or2 follow a DRD2A (ext=1)?
> o LCD[28:23]orLCD[20:15] or LCD[11:6] what is extraN?
> drop 101nnn - extraN
> add 1nnnnn - indexN
> o how many DRD2B1[2] can be stacked up?
> o when is/can a LDC Literal used? and how?
I'll read the document more deeply this week end with the task code
beside me,
try to see if some things are still unclear.
Sylvain
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Greg KH @ 2006-03-31 5:46 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <20060331000208.GS2172@austin.ibm.com>
On Thu, Mar 30, 2006 at 06:02:08PM -0600, Linas Vepstas wrote:
> - /* Prevent stats update while adapter is being reset */
> + /* Prevent stats update while adapter is being reset,
> + * or if the pci connection is down. */
> if (adapter->link_speed == 0)
> return;
> + if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
> + return;
Coding style is still wrong here :(
(hint, use a tab...)
thanks,
greg k-h
^ permalink raw reply
* Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-03-31 5:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
to receive the following updates:
arch/powerpc/kernel/setup_32.c | 6 ----
arch/powerpc/kernel/traps.c | 9 ++----
arch/powerpc/platforms/83xx/mpc834x_sys.c | 40 +++++++++++++++---------------
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 40 +++++++++++++++---------------
4 files changed, 43 insertions(+), 52 deletions(-)
Kumar Gala:
powerpc: merge machine_check_exception between ppc32 & ppc64
powerpc: converted embedded platforms to use new define_machine support
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index a72bf5d..69ac257 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -50,7 +50,6 @@
#include <asm/kgdb.h>
#endif
-extern void platform_init(void);
extern void bootx_init(unsigned long r4, unsigned long phys);
boot_infos_t *boot_infos;
@@ -138,12 +137,7 @@ void __init machine_init(unsigned long d
strlcpy(cmd_line, CONFIG_CMDLINE, sizeof(cmd_line));
#endif /* CONFIG_CMDLINE */
-#ifdef CONFIG_PPC_MULTIPLATFORM
probe_machine();
-#else
- /* Base init based on machine type. Obsoloete, please kill ! */
- platform_init();
-#endif
#ifdef CONFIG_6xx
if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 4cbde21..064a525 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -228,7 +228,7 @@ void system_reset_exception(struct pt_re
*/
static inline int check_io_access(struct pt_regs *regs)
{
-#ifdef CONFIG_PPC_PMAC
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32)
unsigned long msr = regs->msr;
const struct exception_table_entry *entry;
unsigned int *nip = (unsigned int *)regs->nip;
@@ -261,7 +261,7 @@ static inline int check_io_access(struct
return 1;
}
}
-#endif /* CONFIG_PPC_PMAC */
+#endif /* CONFIG_PPC_PMAC && CONFIG_PPC32 */
return 0;
}
@@ -308,8 +308,8 @@ platform_machine_check(struct pt_regs *r
void machine_check_exception(struct pt_regs *regs)
{
-#ifdef CONFIG_PPC64
int recover = 0;
+ unsigned long reason = get_mc_reason(regs);
/* See if any machine dependent calls */
if (ppc_md.machine_check_exception)
@@ -317,8 +317,6 @@ void machine_check_exception(struct pt_r
if (recover)
return;
-#else
- unsigned long reason = get_mc_reason(regs);
if (user_mode(regs)) {
regs->msr |= MSR_RI;
@@ -462,7 +460,6 @@ void machine_check_exception(struct pt_r
* additional info, e.g. bus error registers.
*/
platform_machine_check(regs);
-#endif /* CONFIG_PPC64 */
if (debugger_fault_handler(regs))
return;
diff --git a/arch/powerpc/platforms/83xx/mpc834x_sys.c b/arch/powerpc/platforms/83xx/mpc834x_sys.c
index 7c18b4c..7e789d2 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_sys.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_sys.c
@@ -158,25 +158,25 @@ static int __init mpc834x_rtc_hookup(voi
late_initcall(mpc834x_rtc_hookup);
#endif
-void __init platform_init(void)
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init mpc834x_sys_probe(void)
{
- /* setup the PowerPC module struct */
- ppc_md.setup_arch = mpc834x_sys_setup_arch;
-
- ppc_md.init_IRQ = mpc834x_sys_init_IRQ;
- ppc_md.get_irq = ipic_get_irq;
-
- ppc_md.restart = mpc83xx_restart;
-
- ppc_md.time_init = mpc83xx_time_init;
- ppc_md.set_rtc_time = NULL;
- ppc_md.get_rtc_time = NULL;
- ppc_md.calibrate_decr = generic_calibrate_decr;
-
- ppc_md.progress = udbg_progress;
-
- if (ppc_md.progress)
- ppc_md.progress("mpc834x_sys_init(): exit", 0);
-
- return;
+ /* We always match for now, eventually we should look at the flat
+ dev tree to ensure this is the board we are suppose to run on
+ */
+ return 1;
}
+
+define_machine(mpc834x_sys) {
+ .name = "MPC834x SYS",
+ .probe = mpc834x_sys_probe,
+ .setup_arch = mpc834x_sys_setup_arch,
+ .init_IRQ = mpc834x_sys_init_IRQ,
+ .get_irq = ipic_get_irq,
+ .restart = mpc83xx_restart,
+ .time_init = mpc83xx_time_init,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index b7821db..5eeff37 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -220,25 +220,25 @@ void mpc85xx_ads_show_cpuinfo(struct seq
seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
}
-void __init platform_init(void)
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init mpc85xx_ads_probe(void)
{
- ppc_md.setup_arch = mpc85xx_ads_setup_arch;
- ppc_md.show_cpuinfo = mpc85xx_ads_show_cpuinfo;
-
- ppc_md.init_IRQ = mpc85xx_ads_pic_init;
- ppc_md.get_irq = mpic_get_irq;
-
- ppc_md.restart = mpc85xx_restart;
- ppc_md.power_off = NULL;
- ppc_md.halt = NULL;
-
- ppc_md.time_init = NULL;
- ppc_md.set_rtc_time = NULL;
- ppc_md.get_rtc_time = NULL;
- ppc_md.calibrate_decr = generic_calibrate_decr;
-
- ppc_md.progress = udbg_progress;
-
- if (ppc_md.progress)
- ppc_md.progress("mpc85xx_ads platform_init(): exit", 0);
+ /* We always match for now, eventually we should look at the flat
+ dev tree to ensure this is the board we are suppose to run on
+ */
+ return 1;
}
+
+define_machine(mpc85xx_ads) {
+ .name = "MPC85xx ADS",
+ .probe = mpc85xx_ads_probe,
+ .setup_arch = mpc85xx_ads_setup_arch,
+ .init_IRQ = mpc85xx_ads_pic_init,
+ .show_cpuinfo = mpc85xx_ads_show_cpuinfo,
+ .get_irq = mpic_get_irq,
+ .restart = mpc85xx_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
^ permalink raw reply related
* Re: [PATCH] PowerMac11,2 i2c-bus@0 duplicate dev-tree workaround
From: Michael Ellerman @ 2006-03-31 5:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1143758297.5388.12.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]
On Fri, 2006-03-31 at 00:38 +0200, Johannes Berg wrote:
> On Thu, 2006-03-30 at 17:28 +1100, Michael Ellerman wrote:
>
> > I don't understand why we need this patch? If we care about getting the
> > "right" node why not check for that where we care?
>
> It's not just a single node but also contains sub-nodes. In one of them,
> one of those sub nodes is there but contains bogus info, and in the
> other both are there and contain the right info. Some things that work
> off these bus nodes are detected twice if they're there, and they're
> used in at least two places that I know of.
OK, that sounds a little complicated. I'm just worried about having lots
workarounds in the unflattening code, the code's hard enough to read as
it is. I think it's preferable to do the workarounds in the code that
needs the workaround, that way they're isolated in certain parts of the
code rather than all in the unflattening.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Jeffrey V. Merkey @ 2006-03-31 4:14 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <20060331003506.GU2172@austin.ibm.com>
Linas Vepstas wrote:
>On Thu, Mar 30, 2006 at 06:05:45PM -0700, Jeff V. Merkey wrote:
>
>
>>Linas Vepstas wrote:
>>
>>
>
>Well, these comments have nothing to do with my patch, but ...
>anyway ...
>
>
>
>>The driver also needs to be fixed to allow clearing of the stats (like
>>all the other adapter drivers). At present, when I run performance
>>and packet drop counts on the cards, I cannot reset the stats with this
>>code because the driver stores them in the e100_adapter
>>structure. This is busted.
>>
>>This function:
>>
>>int clear_network_device_stats(BYTE *name)
>>
>>
>
>I couldn't find such a function in the kernel.
>
>
>
>>does not work on e1000 due to this section of code:
>>
>>void
>>e1000_update_stats(struct e1000_adapter *adapter)
>>{
>>
>>adapter->stats.xofftxc += E1000_READ_REG(hw, XOFFTXC);
>>adapter->stats.fcruc += E1000_READ_REG(hw, FCRUC);
>>
>>
>
>These are hardware stats ... presumably useless without
>a detailed understanding of the guts of the e1000.
>
>
>
>>//NOTE These stats need to be stored in the stats structure so they can
>>be cleared by
>>statistics monitoring programs.
>>
>>
>
>I can't imagine what generic interface would allow these
>to be viewed.
>
>
>
>>/* Fill out the OS statistics structure */
>>
>>adapter->net_stats.rx_packets = adapter->stats.gprc;
>>adapter->net_stats.tx_packets = adapter->stats.gptc;
>>adapter->net_stats.rx_bytes = adapter->stats.gorcl;
>>adapter->net_stats.tx_bytes = adapter->stats.gotcl;
>>
>>
>
>Now *these* are generic ... and fixing this so that the
>stats increment instead of over-riding would take
>maybe half-an-hour or so; this is not hard to do ... !?
>
>Do you want me to write a patch to do this?
>
>--lina
>
>
Yes, we need one. The adapter needs to maintain these stats from the
registers in the kernel structure and not
its own local variables. That way, when someone calls to clear the stats
for testing and analysis purposes,
they zero out and are reset.
The code fragment above is in our analysis code not the kernel, but we
use it to test performance of various
vendor cards. It's provided as an example of this capability.
Jeff
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
^ permalink raw reply
* Re: U-boot CPU post failure on 405gp
From: Martin Hicks @ 2006-03-31 0:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060330211143.GK27792@bork.org>
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
On Thu, Mar 30, 2006 at 04:11:43PM -0500, Martin Hicks wrote:
>
> POST cpu link = 0
> ret = -1, link = 0, code = 03fa5ab8, lr = 0
>
> It looks clear to me that link == 0, so the test worked fine.
>
> However, if I take away the "static" from the cpu_post_test_bc()
> declaration then everything works fine.
>
> I've posted "objdump -dS" output for post/cpu/b.o with and without
> cpu_post_test_bc() declared as static at:
It looks like the problem is the automatic inlining of the static
function. If I declare cpu_post_test_bc as:
__attribute__((noinline))
static int cpu_post_test_bc (ulong cmd, ulong bo, ulong bi,
int pjump, int dec, int link, ulong pctr, ulong cr)
Then the test completes.
mh
--
Martin Hicks || mort@bork.org || PGP/GnuPG: 0x4C7F2BEE
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Jeff V. Merkey @ 2006-03-31 1:05 UTC (permalink / raw)
To: Linas Vepstas
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <20060331000208.GS2172@austin.ibm.com>
Linas Vepstas wrote:
>On Thu, Mar 30, 2006 at 03:39:28PM -0600, Linas Vepstas wrote:
>
>
>>Please review, sign-off/ack, and forward upstream.
>>--linas
>>
>>
>
>Per feedback, here's a slightly more human-readable version.
>--linas
>
>[PATCH]: e1000: prevent statistics from getting garbled during reset.
>
>If a PCI bus error/fault triggers a PCI bus reset, attempts to get the
>ethernet packet count statistics from the hardware will fail, returning
>garbage data upstream. This patch skips statistics data collection
>if the PCI device is not on the bus.
>
>This patch presumes that an earlier patch,
>[PATCH] PCI Error Recovery: e1000 network device driver
>has already been applied.
>
>Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
>----
> drivers/net/e1000/e1000_main.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletion(-)
>
>Index: linux-2.6.16-git6/drivers/net/e1000/e1000_main.c
>===================================================================
>--- linux-2.6.16-git6.orig/drivers/net/e1000/e1000_main.c 2006-03-30 17:51:37.924162779 -0600
>+++ linux-2.6.16-git6/drivers/net/e1000/e1000_main.c 2006-03-30 17:54:07.659188391 -0600
>@@ -3069,14 +3069,18 @@ void
> e1000_update_stats(struct e1000_adapter *adapter)
> {
> struct e1000_hw *hw = &adapter->hw;
>+ struct pci_dev *pdev = adapter->pdev;
> unsigned long flags;
> uint16_t phy_tmp;
>
> #define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
>
>- /* Prevent stats update while adapter is being reset */
>+ /* Prevent stats update while adapter is being reset,
>+ * or if the pci connection is down. */
> if (adapter->link_speed == 0)
> return;
>+ if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
>+ return;
>
> spin_lock_irqsave(&adapter->stats_lock, flags);
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
The driver also needs to be fixed to allow clearing of the stats (like
all the other adapter drivers). At present, when I run performance
and packet drop counts on the cards, I cannot reset the stats with this
code because the driver stores them in the e100_adapter
structure. This is busted.
This function:
int clear_network_device_stats(BYTE *name)
{
register int i;
i = get_dev_index_by_name(name);
if (i != -1)
{
if (ndevs[i])
{
struct net_device_stats *stats;
stats = (ndevs[i]->get_stats)(ndevs[i]);
if (stats)
{
stats->rx_packets = 0;
stats->tx_packets = 0;
stats->rx_bytes = 0;
stats->tx_bytes = 0;
stats->multicast = 0;
stats->collisions = 0;
stats->rx_errors = 0;
stats->rx_length_errors = 0;
stats->rx_crc_errors = 0;
stats->rx_frame_errors = 0;
stats->rx_fifo_errors = 0;
stats->rx_missed_errors = 0;
stats->tx_errors = 0;
stats->tx_aborted_errors = 0;
stats->tx_window_errors = 0;
stats->tx_carrier_errors = 0;
P_Print("solera: stats cleared for %s\n", ndevs[i]->name);
return 0;
}
}
return 0;
}
return -1;
}
does not work on e1000 due to this section of code:
void
e1000_update_stats(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
unsigned long flags;
uint16_t phy_tmp;
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
spin_lock_irqsave(&adapter->stats_lock, flags);
/* these counters are modified from e1000_adjust_tbi_stats,
* called from the interrupt context, so they must only
* be written while holding adapter->stats_lock
*/
adapter->stats.crcerrs += E1000_READ_REG(hw, CRCERRS);
adapter->stats.gprc += E1000_READ_REG(hw, GPRC);
adapter->stats.gorcl += E1000_READ_REG(hw, GORCL);
adapter->stats.gorch += E1000_READ_REG(hw, GORCH);
adapter->stats.bprc += E1000_READ_REG(hw, BPRC);
adapter->stats.mprc += E1000_READ_REG(hw, MPRC);
adapter->stats.roc += E1000_READ_REG(hw, ROC);
adapter->stats.prc64 += E1000_READ_REG(hw, PRC64);
adapter->stats.prc127 += E1000_READ_REG(hw, PRC127);
adapter->stats.prc255 += E1000_READ_REG(hw, PRC255);
adapter->stats.prc511 += E1000_READ_REG(hw, PRC511);
adapter->stats.prc1023 += E1000_READ_REG(hw, PRC1023);
adapter->stats.prc1522 += E1000_READ_REG(hw, PRC1522);
adapter->stats.symerrs += E1000_READ_REG(hw, SYMERRS);
adapter->stats.mpc += E1000_READ_REG(hw, MPC);
adapter->stats.scc += E1000_READ_REG(hw, SCC);
adapter->stats.ecol += E1000_READ_REG(hw, ECOL);
adapter->stats.mcc += E1000_READ_REG(hw, MCC);
adapter->stats.latecol += E1000_READ_REG(hw, LATECOL);
adapter->stats.dc += E1000_READ_REG(hw, DC);
adapter->stats.sec += E1000_READ_REG(hw, SEC);
adapter->stats.rlec += E1000_READ_REG(hw, RLEC);
adapter->stats.xonrxc += E1000_READ_REG(hw, XONRXC);
adapter->stats.xontxc += E1000_READ_REG(hw, XONTXC);
adapter->stats.xoffrxc += E1000_READ_REG(hw, XOFFRXC);
adapter->stats.xofftxc += E1000_READ_REG(hw, XOFFTXC);
adapter->stats.fcruc += E1000_READ_REG(hw, FCRUC);
adapter->stats.gptc += E1000_READ_REG(hw, GPTC);
adapter->stats.gotcl += E1000_READ_REG(hw, GOTCL);
adapter->stats.gotch += E1000_READ_REG(hw, GOTCH);
adapter->stats.rnbc += E1000_READ_REG(hw, RNBC);
adapter->stats.ruc += E1000_READ_REG(hw, RUC);
adapter->stats.rfc += E1000_READ_REG(hw, RFC);
adapter->stats.rjc += E1000_READ_REG(hw, RJC);
adapter->stats.torl += E1000_READ_REG(hw, TORL);
adapter->stats.torh += E1000_READ_REG(hw, TORH);
adapter->stats.totl += E1000_READ_REG(hw, TOTL);
adapter->stats.toth += E1000_READ_REG(hw, TOTH);
adapter->stats.tpr += E1000_READ_REG(hw, TPR);
adapter->stats.ptc64 += E1000_READ_REG(hw, PTC64);
adapter->stats.ptc127 += E1000_READ_REG(hw, PTC127);
adapter->stats.ptc255 += E1000_READ_REG(hw, PTC255);
adapter->stats.ptc511 += E1000_READ_REG(hw, PTC511);
adapter->stats.ptc1023 += E1000_READ_REG(hw, PTC1023);
adapter->stats.ptc1522 += E1000_READ_REG(hw, PTC1522);
adapter->stats.mptc += E1000_READ_REG(hw, MPTC);
adapter->stats.bptc += E1000_READ_REG(hw, BPTC);
//NOTE These stats need to be stored in the stats structure so they can
be cleared by
statistics monitoring programs.
/* used for adaptive IFS */
hw->tx_packet_delta = E1000_READ_REG(hw, TPT);
adapter->stats.tpt += hw->tx_packet_delta;
hw->collision_delta = E1000_READ_REG(hw, COLC);
adapter->stats.colc += hw->collision_delta;
if(hw->mac_type >= e1000_82543) {
adapter->stats.algnerrc += E1000_READ_REG(hw, ALGNERRC);
adapter->stats.rxerrc += E1000_READ_REG(hw, RXERRC);
adapter->stats.tncrs += E1000_READ_REG(hw, TNCRS);
adapter->stats.cexterr += E1000_READ_REG(hw, CEXTERR);
adapter->stats.tsctc += E1000_READ_REG(hw, TSCTC);
adapter->stats.tsctfc += E1000_READ_REG(hw, TSCTFC);
}
/* Fill out the OS statistics structure */
adapter->net_stats.rx_packets = adapter->stats.gprc;
adapter->net_stats.tx_packets = adapter->stats.gptc;
adapter->net_stats.rx_bytes = adapter->stats.gorcl;
adapter->net_stats.tx_bytes = adapter->stats.gotcl;
adapter->net_stats.multicast = adapter->stats.mprc;
adapter->net_stats.collisions = adapter->stats.colc;
/* Rx Errors */
adapter->net_stats.rx_errors = adapter->stats.rxerrc +
adapter->stats.crcerrs + adapter->stats.algnerrc +
adapter->stats.rlec + adapter->stats.rnbc +
adapter->stats.mpc + adapter->stats.cexterr;
adapter->net_stats.rx_dropped = adapter->stats.rnbc;
adapter->net_stats.rx_length_errors = adapter->stats.rlec;
adapter->net_stats.rx_crc_errors = adapter->stats.crcerrs;
adapter->net_stats.rx_frame_errors = adapter->stats.algnerrc;
adapter->net_stats.rx_fifo_errors = adapter->stats.mpc;
adapter->net_stats.rx_missed_errors = adapter->stats.mpc;
/* Tx Errors */
adapter->net_stats.tx_errors = adapter->stats.ecol +
adapter->stats.latecol;
adapter->net_stats.tx_aborted_errors = adapter->stats.ecol;
adapter->net_stats.tx_window_errors = adapter->stats.latecol;
adapter->net_stats.tx_carrier_errors = adapter->stats.tncrs;
/* Tx Dropped needs to be maintained elsewhere */
/* Phy Stats */
if(hw->media_type == e1000_media_type_copper) {
if((adapter->link_speed == SPEED_1000) &&
(!e1000_read_phy_reg(hw, PHY_1000T_STATUS, &phy_tmp))) {
phy_tmp &= PHY_IDLE_ERROR_COUNT_MASK;
adapter->phy_stats.idle_errors += phy_tmp;
}
if((hw->mac_type <= e1000_82546) &&
(hw->phy_type == e1000_phy_m88) &&
!e1000_read_phy_reg(hw, M88E1000_RX_ERR_CNTR, &phy_tmp))
adapter->phy_stats.receive_errors += phy_tmp;
}
spin_unlock_irqrestore(&adapter->stats_lock, flags);
}
^ permalink raw reply
* Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
From: Linas Vepstas @ 2006-03-31 0:35 UTC (permalink / raw)
To: Jeff V. Merkey
Cc: netdev, linux-kernel, jesse.brandeburg, linuxppc-dev,
john.ronciak, jeffrey.t.kirsher, linux-pci, Jeff Garzik
In-Reply-To: <442C8069.507@wolfmountaingroup.com>
On Thu, Mar 30, 2006 at 06:05:45PM -0700, Jeff V. Merkey wrote:
>
> Linas Vepstas wrote:
Well, these comments have nothing to do with my patch, but ...
anyway ...
> The driver also needs to be fixed to allow clearing of the stats (like
> all the other adapter drivers). At present, when I run performance
> and packet drop counts on the cards, I cannot reset the stats with this
> code because the driver stores them in the e100_adapter
> structure. This is busted.
>
> This function:
>
> int clear_network_device_stats(BYTE *name)
I couldn't find such a function in the kernel.
> does not work on e1000 due to this section of code:
>
> void
> e1000_update_stats(struct e1000_adapter *adapter)
> {
>
> adapter->stats.xofftxc += E1000_READ_REG(hw, XOFFTXC);
> adapter->stats.fcruc += E1000_READ_REG(hw, FCRUC);
These are hardware stats ... presumably useless without
a detailed understanding of the guts of the e1000.
> //NOTE These stats need to be stored in the stats structure so they can
> be cleared by
> statistics monitoring programs.
I can't imagine what generic interface would allow these
to be viewed.
> /* Fill out the OS statistics structure */
>
> adapter->net_stats.rx_packets = adapter->stats.gprc;
> adapter->net_stats.tx_packets = adapter->stats.gptc;
> adapter->net_stats.rx_bytes = adapter->stats.gorcl;
> adapter->net_stats.tx_bytes = adapter->stats.gotcl;
Now *these* are generic ... and fixing this so that the
stats increment instead of over-riding would take
maybe half-an-hour or so; this is not hard to do ... !?
Do you want me to write a patch to do this?
--linas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox