Re: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Greg KH <[EMAIL PROTECTED]> wrote on 07.02.2008 23:17:12: > On Tue, Jan 29, 2008 at 03:20:20PM +0100, Christoph Raisch wrote: > What is it? It has to live on some kind of bus, right? It is a piece of hardware with a firmware/hypervisor abstraction layer on top. The hypervisor provides virtualization interfaces to add and remove ethernet adapters and ports. Each port is represented in the open firmware device tree (OFDT) as a subnode of the ehea adapter node. System P has a userspace DLPAR application communicating with firmware, the kernel, and the hardware management console to change all that on the flight. This tool needs a capability to identify which open firmware device tree entry belongs to which ethernet device. Each node created by the ibmebus driver has a devspec entry associated to the device node in OFDT, used by the DLPAR application. Each port created by the ibmebus driver has a devspec entry associated to the port node in OFDT, used by the DLPAR application. > > > > host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.0/ > > total 0 ... > > -r--r--r-- 1 root root 4096 2008-01-29 14:26 devspec ... > > > > These pci functions corresponds to a > > /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 > > and > > /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 > > > > The busdriver currently does not find out, how many ports are in a > > /sys/bus/ibmebus/devices/789D.001.XX-P1. > > This is up to the hardware specific driver responsible for ehea or ehca. > > Think of a PCI card where the PCI busdriver > > can not determine how many ports are implemented on the card. > > > > How should this be mapped to /sys ? > > > > Should we try to "flatten" the ports to something like > > /sys/bus/ibmebus/devices/789D.001.XX-P1 > > /sys/bus/ibmebus/devices/789D.001.XX-P1_port0 > > /sys/bus/ibmebus/devices/789D.001.XX-P1_port1 > > ...which means physical hierarchy information would look a bit strange, > > but could be the simpler one. > > No. Why have a separate "port" device for every ethernet port? What > keeps you from just creating the different network devices for your > device, and pointing the parent to the same 789D.001.XX-P1 device? > > > I think you all are trying to make this more complex than it really is > :) If you register multiple netdevs in a ehea adapter node, how is it possible to find out which ethXXX belongs to which devspec port entry in the OFDT? Is there a simpler way than the one we chose to get this in addition? > > thanks, > > greg k-h Gruss / Regards Christoph Raisch -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Greg KH [EMAIL PROTECTED] wrote on 07.02.2008 23:17:12: On Tue, Jan 29, 2008 at 03:20:20PM +0100, Christoph Raisch wrote: What is it? It has to live on some kind of bus, right? It is a piece of hardware with a firmware/hypervisor abstraction layer on top. The hypervisor provides virtualization interfaces to add and remove ethernet adapters and ports. Each port is represented in the open firmware device tree (OFDT) as a subnode of the ehea adapter node. System P has a userspace DLPAR application communicating with firmware, the kernel, and the hardware management console to change all that on the flight. This tool needs a capability to identify which open firmware device tree entry belongs to which ethernet device. Each node created by the ibmebus driver has a devspec entry associated to the device node in OFDT, used by the DLPAR application. Each port created by the ibmebus driver has a devspec entry associated to the port node in OFDT, used by the DLPAR application. host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.0/ total 0 ... -r--r--r-- 1 root root 4096 2008-01-29 14:26 devspec ... These pci functions corresponds to a /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 and /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 The busdriver currently does not find out, how many ports are in a /sys/bus/ibmebus/devices/789D.001.XX-P1. This is up to the hardware specific driver responsible for ehea or ehca. Think of a PCI card where the PCI busdriver can not determine how many ports are implemented on the card. How should this be mapped to /sys ? Should we try to flatten the ports to something like /sys/bus/ibmebus/devices/789D.001.XX-P1 /sys/bus/ibmebus/devices/789D.001.XX-P1_port0 /sys/bus/ibmebus/devices/789D.001.XX-P1_port1 ...which means physical hierarchy information would look a bit strange, but could be the simpler one. No. Why have a separate port device for every ethernet port? What keeps you from just creating the different network devices for your device, and pointing the parent to the same 789D.001.XX-P1 device? I think you all are trying to make this more complex than it really is :) If you register multiple netdevs in a ehea adapter node, how is it possible to find out which ethXXX belongs to which devspec port entry in the OFDT? Is there a simpler way than the one we chose to get this in addition? thanks, greg k-h Gruss / Regards Christoph Raisch -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Tue, Jan 29, 2008 at 03:20:20PM +0100, Christoph Raisch wrote: > Greg KH <[EMAIL PROTECTED]> wrote on 29.01.2008 14:23:09: > > > On Tue, Jan 29, 2008 at 11:12:40AM +0100, Jan-Bernd Themann wrote: > ... > > > The sym-link is not gereated automatically as the device for portX is > added > > > to the eHEA device (as subnode) where the eHEA device is not a bus. > > > > Then please fix that, no other driver has this kind of problem, right? > > Are you just passing the wrong "device" to the networking subsystem? > > > > > If this sym-link is of interest (which I guess is the case as most > devices > > > have it) we have to create it somehow. > > > > Why would you have to do this by hand? What makes this driver so unique > > in the kernel that it would have to do this? We have lots of other > > multi-port ethernet drivers today without this issue, right? > > > > confused, > > > > greg k-h > > well, the major difference is hea is not PCI. What is it? It has to live on some kind of bus, right? > All PCI cards we checked have a 1:1 relationship between PCI function (PCI > config space) and a single ethernet port. > Even if the same Ethernet chip has two ports, it shows up as two separate > adapters from the PCI perspective (two PCI entries in /sys/bus/pci/devices > > host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.0/ > total 0 > lrwxrwxrwx 1 root root 0 2008-01-28 14:59 bus -> ../../../../bus/pci > -r--r--r-- 1 root root 4096 2008-01-28 14:59 class > -rw-r--r-- 1 root root256 2008-01-28 14:59 config > -r--r--r-- 1 root root 4096 2008-01-28 14:59 device > -r--r--r-- 1 root root 4096 2008-01-29 14:26 devspec > lrwxrwxrwx 1 root root 0 2008-01-28 14:59 driver -> > ../../../../bus/pci/drivers/e1000 > -r--r--r-- 1 root root 4096 2008-01-28 14:59 irq > -r--r--r-- 1 root root 4096 2008-01-29 14:26 local_cpus > -r--r--r-- 1 root root 4096 2008-01-28 14:59 modalias > lrwxrwxrwx 1 root root 0 2008-01-29 14:26 net:eth1 -> > ../../../../class/net/eth1 > -r--r--r-- 1 root root 4096 2008-01-28 14:59 resource > > host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.1/ > total 0 > lrwxrwxrwx 1 root root 0 2008-01-28 14:59 bus -> ../../../../bus/pci > -r--r--r-- 1 root root 4096 2008-01-28 14:59 class > -rw-r--r-- 1 root root256 2008-01-28 14:59 config > -r--r--r-- 1 root root 4096 2008-01-28 14:59 device > -r--r--r-- 1 root root 4096 2008-01-29 14:29 devspec > lrwxrwxrwx 1 root root 0 2008-01-28 14:59 driver -> > ../../../../bus/pci/drivers/e1000 > -r--r--r-- 1 root root 4096 2008-01-28 14:59 irq > -r--r--r-- 1 root root 4096 2008-01-29 14:29 local_cpus > -r--r--r-- 1 root root 4096 2008-01-28 14:59 modalias > lrwxrwxrwx 1 root root 0 2008-01-29 14:29 net:eth2 -> > ../../../../class/net/eth2 > ... > > These pci functions corresponds to a > /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 > and > /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 > > The busdriver currently does not find out, how many ports are in a > /sys/bus/ibmebus/devices/789D.001.XX-P1. > This is up to the hardware specific driver responsible for ehea or ehca. > Think of a PCI card where the PCI busdriver > can not determine how many ports are implemented on the card. > > How should this be mapped to /sys ? > > Should we try to "flatten" the ports to something like > /sys/bus/ibmebus/devices/789D.001.XX-P1 > /sys/bus/ibmebus/devices/789D.001.XX-P1_port0 > /sys/bus/ibmebus/devices/789D.001.XX-P1_port1 > ...which means physical hierarchy information would look a bit strange, > but could be the simpler one. No. Why have a separate "port" device for every ethernet port? What keeps you from just creating the different network devices for your device, and pointing the parent to the same 789D.001.XX-P1 device? Lots of PCI devices hang "class devices" off of them all the time, why would this be any different from that? I think you all are trying to make this more complex than it really is :) 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Tue, Jan 29, 2008 at 03:20:20PM +0100, Christoph Raisch wrote: Greg KH [EMAIL PROTECTED] wrote on 29.01.2008 14:23:09: On Tue, Jan 29, 2008 at 11:12:40AM +0100, Jan-Bernd Themann wrote: ... The sym-link is not gereated automatically as the device for portX is added to the eHEA device (as subnode) where the eHEA device is not a bus. Then please fix that, no other driver has this kind of problem, right? Are you just passing the wrong device to the networking subsystem? If this sym-link is of interest (which I guess is the case as most devices have it) we have to create it somehow. Why would you have to do this by hand? What makes this driver so unique in the kernel that it would have to do this? We have lots of other multi-port ethernet drivers today without this issue, right? confused, greg k-h well, the major difference is hea is not PCI. What is it? It has to live on some kind of bus, right? All PCI cards we checked have a 1:1 relationship between PCI function (PCI config space) and a single ethernet port. Even if the same Ethernet chip has two ports, it shows up as two separate adapters from the PCI perspective (two PCI entries in /sys/bus/pci/devices host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.0/ total 0 lrwxrwxrwx 1 root root 0 2008-01-28 14:59 bus - ../../../../bus/pci -r--r--r-- 1 root root 4096 2008-01-28 14:59 class -rw-r--r-- 1 root root256 2008-01-28 14:59 config -r--r--r-- 1 root root 4096 2008-01-28 14:59 device -r--r--r-- 1 root root 4096 2008-01-29 14:26 devspec lrwxrwxrwx 1 root root 0 2008-01-28 14:59 driver - ../../../../bus/pci/drivers/e1000 -r--r--r-- 1 root root 4096 2008-01-28 14:59 irq -r--r--r-- 1 root root 4096 2008-01-29 14:26 local_cpus -r--r--r-- 1 root root 4096 2008-01-28 14:59 modalias lrwxrwxrwx 1 root root 0 2008-01-29 14:26 net:eth1 - ../../../../class/net/eth1 -r--r--r-- 1 root root 4096 2008-01-28 14:59 resource host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.1/ total 0 lrwxrwxrwx 1 root root 0 2008-01-28 14:59 bus - ../../../../bus/pci -r--r--r-- 1 root root 4096 2008-01-28 14:59 class -rw-r--r-- 1 root root256 2008-01-28 14:59 config -r--r--r-- 1 root root 4096 2008-01-28 14:59 device -r--r--r-- 1 root root 4096 2008-01-29 14:29 devspec lrwxrwxrwx 1 root root 0 2008-01-28 14:59 driver - ../../../../bus/pci/drivers/e1000 -r--r--r-- 1 root root 4096 2008-01-28 14:59 irq -r--r--r-- 1 root root 4096 2008-01-29 14:29 local_cpus -r--r--r-- 1 root root 4096 2008-01-28 14:59 modalias lrwxrwxrwx 1 root root 0 2008-01-29 14:29 net:eth2 - ../../../../class/net/eth2 ... These pci functions corresponds to a /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 and /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 The busdriver currently does not find out, how many ports are in a /sys/bus/ibmebus/devices/789D.001.XX-P1. This is up to the hardware specific driver responsible for ehea or ehca. Think of a PCI card where the PCI busdriver can not determine how many ports are implemented on the card. How should this be mapped to /sys ? Should we try to flatten the ports to something like /sys/bus/ibmebus/devices/789D.001.XX-P1 /sys/bus/ibmebus/devices/789D.001.XX-P1_port0 /sys/bus/ibmebus/devices/789D.001.XX-P1_port1 ...which means physical hierarchy information would look a bit strange, but could be the simpler one. No. Why have a separate port device for every ethernet port? What keeps you from just creating the different network devices for your device, and pointing the parent to the same 789D.001.XX-P1 device? Lots of PCI devices hang class devices off of them all the time, why would this be any different from that? I think you all are trying to make this more complex than it really is :) 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: 2.6.24-rc6-mm1 - iget-stop-isofs-from-using-read_inode-fix-2.patch
How about this patch?
David
---
IGET: Fix isofs_get_block() to only return 0 on success.
From: David Howells <[EMAIL PROTECTED]>
Fix isofs_get_block() to return only 0 on success. It shouldn't return a +ve
block count for example.
Also make sure that isofs_get_blocks() doesn't accidentally return an error if
rv is 0 come the return statement.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
fs/isofs/inode.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/fs/isofs/inode.c b/fs/isofs/inode.c
index 0f5ed8c..875d37f 100644
--- a/fs/isofs/inode.c
+++ b/fs/isofs/inode.c
@@ -1022,6 +1022,7 @@ int isofs_get_blocks(struct inode *inode, sector_t
iblock_s,
rv++;
}
+ error = 0;
abort:
unlock_kernel();
return rv != 0 ? rv : error;
@@ -1033,12 +1034,15 @@ abort:
static int isofs_get_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh_result, int create)
{
+ int ret;
+
if (create) {
printk(KERN_DEBUG "%s: Kernel tries to allocate a block\n",
__func__);
return -EROFS;
}
- return isofs_get_blocks(inode, iblock, _result, 1);
+ ret = isofs_get_blocks(inode, iblock, _result, 1);
+ return ret < 0 ? ret : 0;
}
static int isofs_bmap(struct inode *inode, sector_t block)
--
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.24-rc6-mm1 - iget-stop-isofs-from-using-read_inode-fix-2.patch
How about this patch?
David
---
IGET: Fix isofs_get_block() to only return 0 on success.
From: David Howells [EMAIL PROTECTED]
Fix isofs_get_block() to return only 0 on success. It shouldn't return a +ve
block count for example.
Also make sure that isofs_get_blocks() doesn't accidentally return an error if
rv is 0 come the return statement.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
fs/isofs/inode.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/fs/isofs/inode.c b/fs/isofs/inode.c
index 0f5ed8c..875d37f 100644
--- a/fs/isofs/inode.c
+++ b/fs/isofs/inode.c
@@ -1022,6 +1022,7 @@ int isofs_get_blocks(struct inode *inode, sector_t
iblock_s,
rv++;
}
+ error = 0;
abort:
unlock_kernel();
return rv != 0 ? rv : error;
@@ -1033,12 +1034,15 @@ abort:
static int isofs_get_block(struct inode *inode, sector_t iblock,
struct buffer_head *bh_result, int create)
{
+ int ret;
+
if (create) {
printk(KERN_DEBUG %s: Kernel tries to allocate a block\n,
__func__);
return -EROFS;
}
- return isofs_get_blocks(inode, iblock, bh_result, 1);
+ ret = isofs_get_blocks(inode, iblock, bh_result, 1);
+ return ret 0 ? ret : 0;
}
static int isofs_bmap(struct inode *inode, sector_t block)
--
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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Tuesday 29 January 2008 15:20, Christoph Raisch wrote: > These pci functions corresponds to a > /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 > and > /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 > > The busdriver currently does not find out, how many ports are in a > /sys/bus/ibmebus/devices/789D.001.XX-P1. > This is up to the hardware specific driver responsible for ehea or ehca. > Think of a PCI card where the PCI busdriver > can not determine how many ports are implemented on the card. > > How should this be mapped to /sys ? > > Should we try to "flatten" the ports to something like > /sys/bus/ibmebus/devices/789D.001.XX-P1 > /sys/bus/ibmebus/devices/789D.001.XX-P1_port0 > /sys/bus/ibmebus/devices/789D.001.XX-P1_port1 > ...which means physical hierarchy information would look a bit strange, > but could be the simpler one. > > The way which corresponds to the hardware would be to > improve the kernel in such a way that hierarchical ports also wortk for > netdev_register. > Then we could keep this structure > /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 > /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 > > > So, which way should we try? > > Gruss / Regards > Christoph Raisch > > > Hi, so far we fould 2 options. The ibmebus manages (add / remove) ONLY eHEA adapters (not ehea ethernet ports). All ethernet ports have to be added / removed by the eHEA device driver when an eHEA adapter has been added by the ibmebus as a new device. This means the sysfs-links "driver" for our eHEA ethernet devices (ports) are not automatically generated. Option 1) - We can create then ourselves. Therefore we would need two functions exported and included in the proper header file: - static int driver_sysfs_add(struct device *dev) - static void driver_sysfs_remove(struct device *dev) Option 2) - we just leave it out which would be inconsistent with other pci based ethernet adapters. So far we prefer option 1. Do you see any other ways we should investigate? To resolve the build issue I've posted a first patch to remove the old sysfs links. Regards, Jan-Bernd & Christoph -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Greg KH <[EMAIL PROTECTED]> wrote on 29.01.2008 14:23:09: > On Tue, Jan 29, 2008 at 11:12:40AM +0100, Jan-Bernd Themann wrote: ... > > The sym-link is not gereated automatically as the device for portX is added > > to the eHEA device (as subnode) where the eHEA device is not a bus. > > Then please fix that, no other driver has this kind of problem, right? > Are you just passing the wrong "device" to the networking subsystem? > > > If this sym-link is of interest (which I guess is the case as most devices > > have it) we have to create it somehow. > > Why would you have to do this by hand? What makes this driver so unique > in the kernel that it would have to do this? We have lots of other > multi-port ethernet drivers today without this issue, right? > > confused, > > greg k-h well, the major difference is hea is not PCI. All PCI cards we checked have a 1:1 relationship between PCI function (PCI config space) and a single ethernet port. Even if the same Ethernet chip has two ports, it shows up as two separate adapters from the PCI perspective (two PCI entries in /sys/bus/pci/devices host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.0/ total 0 lrwxrwxrwx 1 root root 0 2008-01-28 14:59 bus -> ../../../../bus/pci -r--r--r-- 1 root root 4096 2008-01-28 14:59 class -rw-r--r-- 1 root root256 2008-01-28 14:59 config -r--r--r-- 1 root root 4096 2008-01-28 14:59 device -r--r--r-- 1 root root 4096 2008-01-29 14:26 devspec lrwxrwxrwx 1 root root 0 2008-01-28 14:59 driver -> ../../../../bus/pci/drivers/e1000 -r--r--r-- 1 root root 4096 2008-01-28 14:59 irq -r--r--r-- 1 root root 4096 2008-01-29 14:26 local_cpus -r--r--r-- 1 root root 4096 2008-01-28 14:59 modalias lrwxrwxrwx 1 root root 0 2008-01-29 14:26 net:eth1 -> ../../../../class/net/eth1 -r--r--r-- 1 root root 4096 2008-01-28 14:59 resource host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.1/ total 0 lrwxrwxrwx 1 root root 0 2008-01-28 14:59 bus -> ../../../../bus/pci -r--r--r-- 1 root root 4096 2008-01-28 14:59 class -rw-r--r-- 1 root root256 2008-01-28 14:59 config -r--r--r-- 1 root root 4096 2008-01-28 14:59 device -r--r--r-- 1 root root 4096 2008-01-29 14:29 devspec lrwxrwxrwx 1 root root 0 2008-01-28 14:59 driver -> ../../../../bus/pci/drivers/e1000 -r--r--r-- 1 root root 4096 2008-01-28 14:59 irq -r--r--r-- 1 root root 4096 2008-01-29 14:29 local_cpus -r--r--r-- 1 root root 4096 2008-01-28 14:59 modalias lrwxrwxrwx 1 root root 0 2008-01-29 14:29 net:eth2 -> ../../../../class/net/eth2 ... These pci functions corresponds to a /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 and /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 The busdriver currently does not find out, how many ports are in a /sys/bus/ibmebus/devices/789D.001.XX-P1. This is up to the hardware specific driver responsible for ehea or ehca. Think of a PCI card where the PCI busdriver can not determine how many ports are implemented on the card. How should this be mapped to /sys ? Should we try to "flatten" the ports to something like /sys/bus/ibmebus/devices/789D.001.XX-P1 /sys/bus/ibmebus/devices/789D.001.XX-P1_port0 /sys/bus/ibmebus/devices/789D.001.XX-P1_port1 ...which means physical hierarchy information would look a bit strange, but could be the simpler one. The way which corresponds to the hardware would be to improve the kernel in such a way that hierarchical ports also wortk for netdev_register. Then we could keep this structure /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 So, which way should we try? Gruss / Regards Christoph Raisch -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Tue, Jan 29, 2008 at 11:12:40AM +0100, Jan-Bernd Themann wrote: > On Monday 28 January 2008 20:22, you wrote: > > Greg KH wrote: > > > On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote: > > > > Jan-Bernd Themann wrote: > > > > > > > > This is now broken in mainline... > > > > > > > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': > > > > drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has > > > > no member named 'kobj' > > > > drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has > > > > no member named 'kobj' > > > > drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has > > > > no member named 'kobj' > > > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': > > > > drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has > > > > no member named 'kobj' > > > > > > Does the patch below fix this? That driver should not have been trying > > > to create symlinks that the driver core has already created for it. > > > > Yes, it fixes the build error, by just removing the code that got > > broken. Jan-Bernd gave a rationale for creating the symlink that > > didn't really seem to be answered. > > > > > > > > The eHEA driver tries to orginize its sys-entries as close as > > > > > possible to > > > > > other ethernet drivers. Each eHEA NIC has multiple ports which is not > > > > > that > > > > > common in PCI. This means that each port is represented by a > > > > > subdirectory > > > > > which has not the "driver" sys-link, only the root directory has. > > > > > Some tools expect to have this driver link in each port directory. > > > > > That is the reason why this link is created manually. > > In addition to the explaination above: > > Just to be sure that we talk about the same thing: > The eHEA driver controlls multiple eHEAs which have multiple > ethernet ports each. So the logical structure looks like this: > eHEA1 ---> port1 (ethX) > -> port2 (ethX+1) > -> port3 (ethX+2) >... > eHEA2 ---> port1 (eth?) > -> port2 > -> port3 >... > This structure is represented in /sys/bus/ibmebus/devices in the same way > described above. > > If you want to determine the driver belonging to an ethX, you would go > the following path: > /sys/class/net/ethX/device/driver > > > ls /sys/class/net/ethX/device: > drwxr-xr-x 2 root root0 2008-01-29 10:00 . > drwxr-xr-x 4 root root0 2008-01-29 10:00 .. > lrwxrwxrwx 1 root root0 2008-01-29 10:00 bus -> ../../../../bus/ibmebus > -r--r--r-- 1 root root 4096 2008-01-29 10:00 devspec > lrwxrwxrwx 1 root root0 2008-01-29 10:00 driver -> > ../../../../bus/ibmebus/drivers/ehea > ^ > In our case this one is created by the code that does not work any > longer. > > The sym-link is not gereated automatically as the device for portX is added > to the eHEA device (as subnode) where the eHEA device is not a bus. Then please fix that, no other driver has this kind of problem, right? Are you just passing the wrong "device" to the networking subsystem? > If this sym-link is of interest (which I guess is the case as most devices > have it) we have to create it somehow. Why would you have to do this by hand? What makes this driver so unique in the kernel that it would have to do this? We have lots of other multi-port ethernet drivers today without this issue, right? confused, 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Monday 28 January 2008 20:22, you wrote: > Greg KH wrote: > > On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote: > > > Jan-Bernd Themann wrote: > > > > > > This is now broken in mainline... > > > > > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': > > > drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has > > > no member named 'kobj' > > > drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has > > > no member named 'kobj' > > > drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has > > > no member named 'kobj' > > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': > > > drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has > > > no member named 'kobj' > > > > Does the patch below fix this? That driver should not have been trying > > to create symlinks that the driver core has already created for it. > > Yes, it fixes the build error, by just removing the code that got > broken. Jan-Bernd gave a rationale for creating the symlink that > didn't really seem to be answered. > > > > > The eHEA driver tries to orginize its sys-entries as close as possible > > > > to > > > > other ethernet drivers. Each eHEA NIC has multiple ports which is not > > > > that > > > > common in PCI. This means that each port is represented by a > > > > subdirectory > > > > which has not the "driver" sys-link, only the root directory has. > > > > Some tools expect to have this driver link in each port directory. > > > > That is the reason why this link is created manually. In addition to the explaination above: Just to be sure that we talk about the same thing: The eHEA driver controlls multiple eHEAs which have multiple ethernet ports each. So the logical structure looks like this: eHEA1 ---> port1 (ethX) -> port2 (ethX+1) -> port3 (ethX+2) ... eHEA2 ---> port1 (eth?) -> port2 -> port3 ... This structure is represented in /sys/bus/ibmebus/devices in the same way described above. If you want to determine the driver belonging to an ethX, you would go the following path: /sys/class/net/ethX/device/driver ls /sys/class/net/ethX/device: drwxr-xr-x 2 root root0 2008-01-29 10:00 . drwxr-xr-x 4 root root0 2008-01-29 10:00 .. lrwxrwxrwx 1 root root0 2008-01-29 10:00 bus -> ../../../../bus/ibmebus -r--r--r-- 1 root root 4096 2008-01-29 10:00 devspec lrwxrwxrwx 1 root root0 2008-01-29 10:00 driver -> ../../../../bus/ibmebus/drivers/ehea ^ In our case this one is created by the code that does not work any longer. The sym-link is not gereated automatically as the device for portX is added to the eHEA device (as subnode) where the eHEA device is not a bus. If this sym-link is of interest (which I guess is the case as most devices have it) we have to create it somehow. Would the following proposal work? There is an exported kernel function called "device_bind_driver" which creates the same links. However, it does some additional stuff as well and there is currently no "device_unbind_driver" yet. Either "device_unbind_driver" needs to be added or the following two already existing functions could be exported: driver_sysfs_add driver_sysfs_remove Regards, Jan-Bernd & Christoph Raisch -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Greg KH [EMAIL PROTECTED] wrote on 29.01.2008 14:23:09: On Tue, Jan 29, 2008 at 11:12:40AM +0100, Jan-Bernd Themann wrote: ... The sym-link is not gereated automatically as the device for portX is added to the eHEA device (as subnode) where the eHEA device is not a bus. Then please fix that, no other driver has this kind of problem, right? Are you just passing the wrong device to the networking subsystem? If this sym-link is of interest (which I guess is the case as most devices have it) we have to create it somehow. Why would you have to do this by hand? What makes this driver so unique in the kernel that it would have to do this? We have lots of other multi-port ethernet drivers today without this issue, right? confused, greg k-h well, the major difference is hea is not PCI. All PCI cards we checked have a 1:1 relationship between PCI function (PCI config space) and a single ethernet port. Even if the same Ethernet chip has two ports, it shows up as two separate adapters from the PCI perspective (two PCI entries in /sys/bus/pci/devices host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.0/ total 0 lrwxrwxrwx 1 root root 0 2008-01-28 14:59 bus - ../../../../bus/pci -r--r--r-- 1 root root 4096 2008-01-28 14:59 class -rw-r--r-- 1 root root256 2008-01-28 14:59 config -r--r--r-- 1 root root 4096 2008-01-28 14:59 device -r--r--r-- 1 root root 4096 2008-01-29 14:26 devspec lrwxrwxrwx 1 root root 0 2008-01-28 14:59 driver - ../../../../bus/pci/drivers/e1000 -r--r--r-- 1 root root 4096 2008-01-28 14:59 irq -r--r--r-- 1 root root 4096 2008-01-29 14:26 local_cpus -r--r--r-- 1 root root 4096 2008-01-28 14:59 modalias lrwxrwxrwx 1 root root 0 2008-01-29 14:26 net:eth1 - ../../../../class/net/eth1 -r--r--r-- 1 root root 4096 2008-01-28 14:59 resource host:/ # ls -l /sys/bus/pci/devices/\:c8\:01.1/ total 0 lrwxrwxrwx 1 root root 0 2008-01-28 14:59 bus - ../../../../bus/pci -r--r--r-- 1 root root 4096 2008-01-28 14:59 class -rw-r--r-- 1 root root256 2008-01-28 14:59 config -r--r--r-- 1 root root 4096 2008-01-28 14:59 device -r--r--r-- 1 root root 4096 2008-01-29 14:29 devspec lrwxrwxrwx 1 root root 0 2008-01-28 14:59 driver - ../../../../bus/pci/drivers/e1000 -r--r--r-- 1 root root 4096 2008-01-28 14:59 irq -r--r--r-- 1 root root 4096 2008-01-29 14:29 local_cpus -r--r--r-- 1 root root 4096 2008-01-28 14:59 modalias lrwxrwxrwx 1 root root 0 2008-01-29 14:29 net:eth2 - ../../../../class/net/eth2 ... These pci functions corresponds to a /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 and /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 The busdriver currently does not find out, how many ports are in a /sys/bus/ibmebus/devices/789D.001.XX-P1. This is up to the hardware specific driver responsible for ehea or ehca. Think of a PCI card where the PCI busdriver can not determine how many ports are implemented on the card. How should this be mapped to /sys ? Should we try to flatten the ports to something like /sys/bus/ibmebus/devices/789D.001.XX-P1 /sys/bus/ibmebus/devices/789D.001.XX-P1_port0 /sys/bus/ibmebus/devices/789D.001.XX-P1_port1 ...which means physical hierarchy information would look a bit strange, but could be the simpler one. The way which corresponds to the hardware would be to improve the kernel in such a way that hierarchical ports also wortk for netdev_register. Then we could keep this structure /sys/bus/ibmebus/devices/789D.001.XX-P1/port0 /sys/bus/ibmebus/devices/789D.001.XX-P1/port1 So, which way should we try? Gruss / Regards Christoph Raisch -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Tue, Jan 29, 2008 at 11:12:40AM +0100, Jan-Bernd Themann wrote: On Monday 28 January 2008 20:22, you wrote: Greg KH wrote: On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote: Jan-Bernd Themann wrote: This is now broken in mainline... drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj' Does the patch below fix this? That driver should not have been trying to create symlinks that the driver core has already created for it. Yes, it fixes the build error, by just removing the code that got broken. Jan-Bernd gave a rationale for creating the symlink that didn't really seem to be answered. The eHEA driver tries to orginize its sys-entries as close as possible to other ethernet drivers. Each eHEA NIC has multiple ports which is not that common in PCI. This means that each port is represented by a subdirectory which has not the driver sys-link, only the root directory has. Some tools expect to have this driver link in each port directory. That is the reason why this link is created manually. In addition to the explaination above: Just to be sure that we talk about the same thing: The eHEA driver controlls multiple eHEAs which have multiple ethernet ports each. So the logical structure looks like this: eHEA1 --- port1 (ethX) - port2 (ethX+1) - port3 (ethX+2) ... eHEA2 --- port1 (eth?) - port2 - port3 ... This structure is represented in /sys/bus/ibmebus/devices in the same way described above. If you want to determine the driver belonging to an ethX, you would go the following path: /sys/class/net/ethX/device/driver ls /sys/class/net/ethX/device: drwxr-xr-x 2 root root0 2008-01-29 10:00 . drwxr-xr-x 4 root root0 2008-01-29 10:00 .. lrwxrwxrwx 1 root root0 2008-01-29 10:00 bus - ../../../../bus/ibmebus -r--r--r-- 1 root root 4096 2008-01-29 10:00 devspec lrwxrwxrwx 1 root root0 2008-01-29 10:00 driver - ../../../../bus/ibmebus/drivers/ehea ^ In our case this one is created by the code that does not work any longer. The sym-link is not gereated automatically as the device for portX is added to the eHEA device (as subnode) where the eHEA device is not a bus. Then please fix that, no other driver has this kind of problem, right? Are you just passing the wrong device to the networking subsystem? If this sym-link is of interest (which I guess is the case as most devices have it) we have to create it somehow. Why would you have to do this by hand? What makes this driver so unique in the kernel that it would have to do this? We have lots of other multi-port ethernet drivers today without this issue, right? confused, 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Mon, Jan 28, 2008 at 01:22:04PM -0600, Nathan Lynch wrote: > Greg KH wrote: > > On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote: > > > Jan-Bernd Themann wrote: > > > > > > > > On Thursday 10 January 2008 18:34, Greg KH wrote: > > > > > > The structure device_driver(in device.h) has a member struct > > > > > > driver_private which > > > > > > contains the member kobj (according to drivers/base/base.h). > > > > > > But in device.h struct driver_private has been declared localy and > > > > > > neither defined nor included from base.h. > > > > > > So my effort to use driver->driver_private->obj also does not work. > > > > > > (I am surprised from where do you access the struct device_driver) > > > > > > > > > > That is because a driver should not be accessing such a field. > > > > > > > > > > And especially not in this manner, why would this driver be creating a > > > > > symlink that has already been created by the driver core? This whole > > > > > thing can just be removed with no problems. Can you try just removing > > > > > the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to > > > > > verify this as I don't have the hardware present to test it out. > > > > > > > > The eHEA driver tries to orginize its sys-entries as close as possible > > > > to > > > > other ethernet drivers. Each eHEA NIC has multiple ports which is not > > > > that > > > > common in PCI. This means that each port is represented by a > > > > subdirectory > > > > which has not the "driver" sys-link, only the root directory has. > > > > Some tools expect to have this driver link in each port directory. > > > > That is the reason why this link is created manually. > > > > > > > > Are there any other ways to create this link? > > > > > > > > > This is now broken in mainline... > > > > > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': > > > drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has > > > no member named 'kobj' > > > drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has > > > no member named 'kobj' > > > drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has > > > no member named 'kobj' > > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': > > > drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has > > > no member named 'kobj' > > > > Does the patch below fix this? That driver should not have been trying > > to create symlinks that the driver core has already created for it. > > Yes, it fixes the build error, by just removing the code that got > broken. Jan-Bernd gave a rationale for creating the symlink that > didn't really seem to be answered. See my other post to him. I do not see why this is not just duplicating the same exact code in the driver core. If you are trying to "fake out" userspace by saying a device is bound to a driver, well, that's just wrong. 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Greg KH wrote: > On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote: > > Jan-Bernd Themann wrote: > > > > > > On Thursday 10 January 2008 18:34, Greg KH wrote: > > > > > The structure device_driver(in device.h) has a member struct > > > > > driver_private which > > > > > contains the member kobj (according to drivers/base/base.h). > > > > > But in device.h struct driver_private has been declared localy and > > > > > neither defined nor included from base.h. > > > > > So my effort to use driver->driver_private->obj also does not work. > > > > > (I am surprised from where do you access the struct device_driver) > > > > > > > > That is because a driver should not be accessing such a field. > > > > > > > > And especially not in this manner, why would this driver be creating a > > > > symlink that has already been created by the driver core? This whole > > > > thing can just be removed with no problems. Can you try just removing > > > > the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to > > > > verify this as I don't have the hardware present to test it out. > > > > > > The eHEA driver tries to orginize its sys-entries as close as possible to > > > other ethernet drivers. Each eHEA NIC has multiple ports which is not that > > > common in PCI. This means that each port is represented by a subdirectory > > > which has not the "driver" sys-link, only the root directory has. > > > Some tools expect to have this driver link in each port directory. > > > That is the reason why this link is created manually. > > > > > > Are there any other ways to create this link? > > > > > > This is now broken in mainline... > > > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': > > drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has > > no member named 'kobj' > > drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has > > no member named 'kobj' > > drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has > > no member named 'kobj' > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': > > drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has > > no member named 'kobj' > > Does the patch below fix this? That driver should not have been trying > to create symlinks that the driver core has already created for it. Yes, it fixes the build error, by just removing the code that got broken. Jan-Bernd gave a rationale for creating the symlink that didn't really seem to be answered. -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Fri, Jan 18, 2008 at 10:16:48AM +0100, Jan-Bernd Themann wrote: > Hi, > > sorry for answering so late, I'm only tracking netdev and ppc mailing list. > > On Thursday 10 January 2008 18:34, Greg KH wrote: > > > The structure device_driver(in device.h) has a member struct > > > driver_private which > > > contains the member kobj (according to drivers/base/base.h). > > > But in device.h struct driver_private has been declared localy and > > > neither defined nor included from base.h. > > > So my effort to use driver->driver_private->obj also does not work. > > > (I am surprised from where do you access the struct device_driver) > > > > That is because a driver should not be accessing such a field. > > > > And especially not in this manner, why would this driver be creating a > > symlink that has already been created by the driver core? This whole > > thing can just be removed with no problems. Can you try just removing > > the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to > > verify this as I don't have the hardware present to test it out. > > The eHEA driver tries to orginize its sys-entries as close as possible to > other ethernet drivers. Each eHEA NIC has multiple ports which is not that > common in PCI. This means that each port is represented by a subdirectory > which has not the "driver" sys-link, only the root directory has. > Some tools expect to have this driver link in each port directory. > That is the reason why this link is created manually. > > Are there any other ways to create this link? The driver core already creates this link for you. Don't try to duplicate what is already there for you. It should just be a matter of deleting the code, and everything should be fine. See the patch that I just sent. 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote:
> Jan-Bernd Themann wrote:
> > Hi,
> >
> > sorry for answering so late, I'm only tracking netdev and ppc mailing list.
> >
> > On Thursday 10 January 2008 18:34, Greg KH wrote:
> > > > The structure device_driver(in device.h) has a member struct
> > > > driver_private which
> > > > contains the member kobj (according to drivers/base/base.h).
> > > > But in device.h struct driver_private has been declared localy and
> > > > neither defined nor included from base.h.
> > > > So my effort to use driver->driver_private->obj also does not work.
> > > > (I am surprised from where do you access the struct device_driver)
> > >
> > > That is because a driver should not be accessing such a field.
> > >
> > > And especially not in this manner, why would this driver be creating a
> > > symlink that has already been created by the driver core? This whole
> > > thing can just be removed with no problems. Can you try just removing
> > > the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to
> > > verify this as I don't have the hardware present to test it out.
> >
> > The eHEA driver tries to orginize its sys-entries as close as possible to
> > other ethernet drivers. Each eHEA NIC has multiple ports which is not that
> > common in PCI. This means that each port is represented by a subdirectory
> > which has not the "driver" sys-link, only the root directory has.
> > Some tools expect to have this driver link in each port directory.
> > That is the reason why this link is created manually.
> >
> > Are there any other ways to create this link?
>
>
> This is now broken in mainline...
>
> drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add':
> drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has
> no member named 'kobj'
> drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has
> no member named 'kobj'
> drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has
> no member named 'kobj'
> drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove':
> drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has
> no member named 'kobj'
Does the patch below fix this? That driver should not have been trying
to create symlinks that the driver core has already created for it.
Dumb, dumb, dumb...
thanks,
greg k-h
--
---
drivers/net/ehea/ehea_main.c | 37 -
1 file changed, 37 deletions(-)
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2804,34 +2804,6 @@ static void __devinit logical_port_relea
of_node_put(port->ofdev.node);
}
-static int ehea_driver_sysfs_add(struct device *dev,
-struct device_driver *driver)
-{
- int ret;
-
- ret = sysfs_create_link(>kobj, >kobj,
- kobject_name(>kobj));
- if (ret == 0) {
- ret = sysfs_create_link(>kobj, >kobj,
- "driver");
- if (ret)
- sysfs_remove_link(>kobj,
- kobject_name(>kobj));
- }
- return ret;
-}
-
-static void ehea_driver_sysfs_remove(struct device *dev,
-struct device_driver *driver)
-{
- struct device_driver *drv = driver;
-
- if (drv) {
- sysfs_remove_link(>kobj, kobject_name(>kobj));
- sysfs_remove_link(>kobj, "driver");
- }
-}
-
static struct device *ehea_register_port(struct ehea_port *port,
struct device_node *dn)
{
@@ -2856,16 +2828,8 @@ static struct device *ehea_register_port
goto out_unreg_of_dev;
}
- ret = ehea_driver_sysfs_add(>ofdev.dev, _driver.driver);
- if (ret) {
- ehea_error("failed to register sysfs driver link");
- goto out_rem_dev_file;
- }
-
return >ofdev.dev;
-out_rem_dev_file:
- device_remove_file(>ofdev.dev, _attr_log_port_id);
out_unreg_of_dev:
of_device_unregister(>ofdev);
out:
@@ -2874,7 +2838,6 @@ out:
static void ehea_unregister_port(struct ehea_port *port)
{
- ehea_driver_sysfs_remove(>ofdev.dev, _driver.driver);
device_remove_file(>ofdev.dev, _attr_log_port_id);
of_device_unregister(>ofdev);
}
--
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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote: > Jan-Bernd Themann wrote: > > Hi, > > > > sorry for answering so late, I'm only tracking netdev and ppc mailing list. > > > > On Thursday 10 January 2008 18:34, Greg KH wrote: > > > > The structure device_driver(in device.h) has a member struct > > > > driver_private which > > > > contains the member kobj (according to drivers/base/base.h). > > > > But in device.h struct driver_private has been declared localy and > > > > neither defined nor included from base.h. > > > > So my effort to use driver->driver_private->obj also does not work. > > > > (I am surprised from where do you access the struct device_driver) > > > > > > That is because a driver should not be accessing such a field. > > > > > > And especially not in this manner, why would this driver be creating a > > > symlink that has already been created by the driver core? This whole > > > thing can just be removed with no problems. Can you try just removing > > > the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to > > > verify this as I don't have the hardware present to test it out. > > > > The eHEA driver tries to orginize its sys-entries as close as possible to > > other ethernet drivers. Each eHEA NIC has multiple ports which is not that > > common in PCI. This means that each port is represented by a subdirectory > > which has not the "driver" sys-link, only the root directory has. > > Some tools expect to have this driver link in each port directory. > > That is the reason why this link is created manually. > > > > Are there any other ways to create this link? > > > This is now broken in mainline... > > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': > drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has > no member named 'kobj' > drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has > no member named 'kobj' > drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has > no member named 'kobj' > drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': > drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has > no member named 'kobj' Crap, I missed that one. I'll go fix it up right now... sorry about this. 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Fri, Jan 18, 2008 at 10:16:48AM +0100, Jan-Bernd Themann wrote: Hi, sorry for answering so late, I'm only tracking netdev and ppc mailing list. On Thursday 10 January 2008 18:34, Greg KH wrote: The structure device_driver(in device.h) has a member struct driver_private which contains the member kobj (according to drivers/base/base.h). But in device.h struct driver_private has been declared localy and neither defined nor included from base.h. So my effort to use driver-driver_private-obj also does not work. (I am surprised from where do you access the struct device_driver) That is because a driver should not be accessing such a field. And especially not in this manner, why would this driver be creating a symlink that has already been created by the driver core? This whole thing can just be removed with no problems. Can you try just removing the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to verify this as I don't have the hardware present to test it out. The eHEA driver tries to orginize its sys-entries as close as possible to other ethernet drivers. Each eHEA NIC has multiple ports which is not that common in PCI. This means that each port is represented by a subdirectory which has not the driver sys-link, only the root directory has. Some tools expect to have this driver link in each port directory. That is the reason why this link is created manually. Are there any other ways to create this link? The driver core already creates this link for you. Don't try to duplicate what is already there for you. It should just be a matter of deleting the code, and everything should be fine. See the patch that I just sent. 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Mon, Jan 28, 2008 at 01:22:04PM -0600, Nathan Lynch wrote: Greg KH wrote: On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote: Jan-Bernd Themann wrote: On Thursday 10 January 2008 18:34, Greg KH wrote: The structure device_driver(in device.h) has a member struct driver_private which contains the member kobj (according to drivers/base/base.h). But in device.h struct driver_private has been declared localy and neither defined nor included from base.h. So my effort to use driver-driver_private-obj also does not work. (I am surprised from where do you access the struct device_driver) That is because a driver should not be accessing such a field. And especially not in this manner, why would this driver be creating a symlink that has already been created by the driver core? This whole thing can just be removed with no problems. Can you try just removing the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to verify this as I don't have the hardware present to test it out. The eHEA driver tries to orginize its sys-entries as close as possible to other ethernet drivers. Each eHEA NIC has multiple ports which is not that common in PCI. This means that each port is represented by a subdirectory which has not the driver sys-link, only the root directory has. Some tools expect to have this driver link in each port directory. That is the reason why this link is created manually. Are there any other ways to create this link? This is now broken in mainline... drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj' Does the patch below fix this? That driver should not have been trying to create symlinks that the driver core has already created for it. Yes, it fixes the build error, by just removing the code that got broken. Jan-Bernd gave a rationale for creating the symlink that didn't really seem to be answered. See my other post to him. I do not see why this is not just duplicating the same exact code in the driver core. If you are trying to fake out userspace by saying a device is bound to a driver, well, that's just wrong. 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Greg KH wrote: On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote: Jan-Bernd Themann wrote: On Thursday 10 January 2008 18:34, Greg KH wrote: The structure device_driver(in device.h) has a member struct driver_private which contains the member kobj (according to drivers/base/base.h). But in device.h struct driver_private has been declared localy and neither defined nor included from base.h. So my effort to use driver-driver_private-obj also does not work. (I am surprised from where do you access the struct device_driver) That is because a driver should not be accessing such a field. And especially not in this manner, why would this driver be creating a symlink that has already been created by the driver core? This whole thing can just be removed with no problems. Can you try just removing the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to verify this as I don't have the hardware present to test it out. The eHEA driver tries to orginize its sys-entries as close as possible to other ethernet drivers. Each eHEA NIC has multiple ports which is not that common in PCI. This means that each port is represented by a subdirectory which has not the driver sys-link, only the root directory has. Some tools expect to have this driver link in each port directory. That is the reason why this link is created manually. Are there any other ways to create this link? This is now broken in mainline... drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj' Does the patch below fix this? That driver should not have been trying to create symlinks that the driver core has already created for it. Yes, it fixes the build error, by just removing the code that got broken. Jan-Bernd gave a rationale for creating the symlink that didn't really seem to be answered. -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote:
Jan-Bernd Themann wrote:
Hi,
sorry for answering so late, I'm only tracking netdev and ppc mailing list.
On Thursday 10 January 2008 18:34, Greg KH wrote:
The structure device_driver(in device.h) has a member struct
driver_private which
contains the member kobj (according to drivers/base/base.h).
But in device.h struct driver_private has been declared localy and
neither defined nor included from base.h.
So my effort to use driver-driver_private-obj also does not work.
(I am surprised from where do you access the struct device_driver)
That is because a driver should not be accessing such a field.
And especially not in this manner, why would this driver be creating a
symlink that has already been created by the driver core? This whole
thing can just be removed with no problems. Can you try just removing
the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to
verify this as I don't have the hardware present to test it out.
The eHEA driver tries to orginize its sys-entries as close as possible to
other ethernet drivers. Each eHEA NIC has multiple ports which is not that
common in PCI. This means that each port is represented by a subdirectory
which has not the driver sys-link, only the root directory has.
Some tools expect to have this driver link in each port directory.
That is the reason why this link is created manually.
Are there any other ways to create this link?
This is now broken in mainline...
drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add':
drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has
no member named 'kobj'
drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has
no member named 'kobj'
drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has
no member named 'kobj'
drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove':
drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has
no member named 'kobj'
Does the patch below fix this? That driver should not have been trying
to create symlinks that the driver core has already created for it.
Dumb, dumb, dumb...
thanks,
greg k-h
--
---
drivers/net/ehea/ehea_main.c | 37 -
1 file changed, 37 deletions(-)
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -2804,34 +2804,6 @@ static void __devinit logical_port_relea
of_node_put(port-ofdev.node);
}
-static int ehea_driver_sysfs_add(struct device *dev,
-struct device_driver *driver)
-{
- int ret;
-
- ret = sysfs_create_link(driver-kobj, dev-kobj,
- kobject_name(dev-kobj));
- if (ret == 0) {
- ret = sysfs_create_link(dev-kobj, driver-kobj,
- driver);
- if (ret)
- sysfs_remove_link(driver-kobj,
- kobject_name(dev-kobj));
- }
- return ret;
-}
-
-static void ehea_driver_sysfs_remove(struct device *dev,
-struct device_driver *driver)
-{
- struct device_driver *drv = driver;
-
- if (drv) {
- sysfs_remove_link(drv-kobj, kobject_name(dev-kobj));
- sysfs_remove_link(dev-kobj, driver);
- }
-}
-
static struct device *ehea_register_port(struct ehea_port *port,
struct device_node *dn)
{
@@ -2856,16 +2828,8 @@ static struct device *ehea_register_port
goto out_unreg_of_dev;
}
- ret = ehea_driver_sysfs_add(port-ofdev.dev, ehea_driver.driver);
- if (ret) {
- ehea_error(failed to register sysfs driver link);
- goto out_rem_dev_file;
- }
-
return port-ofdev.dev;
-out_rem_dev_file:
- device_remove_file(port-ofdev.dev, dev_attr_log_port_id);
out_unreg_of_dev:
of_device_unregister(port-ofdev);
out:
@@ -2874,7 +2838,6 @@ out:
static void ehea_unregister_port(struct ehea_port *port)
{
- ehea_driver_sysfs_remove(port-ofdev.dev, ehea_driver.driver);
device_remove_file(port-ofdev.dev, dev_attr_log_port_id);
of_device_unregister(port-ofdev);
}
--
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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Fri, Jan 25, 2008 at 01:10:48PM -0600, Nathan Lynch wrote: Jan-Bernd Themann wrote: Hi, sorry for answering so late, I'm only tracking netdev and ppc mailing list. On Thursday 10 January 2008 18:34, Greg KH wrote: The structure device_driver(in device.h) has a member struct driver_private which contains the member kobj (according to drivers/base/base.h). But in device.h struct driver_private has been declared localy and neither defined nor included from base.h. So my effort to use driver-driver_private-obj also does not work. (I am surprised from where do you access the struct device_driver) That is because a driver should not be accessing such a field. And especially not in this manner, why would this driver be creating a symlink that has already been created by the driver core? This whole thing can just be removed with no problems. Can you try just removing the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to verify this as I don't have the hardware present to test it out. The eHEA driver tries to orginize its sys-entries as close as possible to other ethernet drivers. Each eHEA NIC has multiple ports which is not that common in PCI. This means that each port is represented by a subdirectory which has not the driver sys-link, only the root directory has. Some tools expect to have this driver link in each port directory. That is the reason why this link is created manually. Are there any other ways to create this link? This is now broken in mainline... drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj' Crap, I missed that one. I'll go fix it up right now... sorry about this. 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: 2.6.24-rc6-mm1
Sorry for the *really* late answer, but I did not have any time to do linux things the last weeks. :-( On Jan 7, 2008 7:16 AM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > On Sun, 6 Jan 2008 21:03:42 +0100 > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > > On Jan 6, 2008 2:33 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > > > On Sun, 6 Jan 2008 12:35:35 +0100 > > > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > > > > On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > > > > And double using something does fit with the errors I'm seeing... > > > > > > > > > Can you try the patch to revert my IOMMU changes? > > > > > > > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12694.html -> This is the revert-patch I'm talking about later > > > > Testing for this bug is a little bit slow, as I'm compiling ~100 > > > > packages trying to trigger it. > > > > If my current testrun with the patch from > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html > > > > crashes, I will revert the hole IOMMU changes with above patch and try > > > > again. > > > > > > Thanks for testing, > > > > OK, I'm still testing this, but after 95 completed packages I'm rather > > certain that reverting the IOMMU changes with this patch fixes my > > problem. > > I didn't have time to look more into this, so I can't offer any > > concrete ideas where the bug is. Until my last mail from 7. Jan this was true, that I was not able to crash 2.6.24-rc6-mm1 with above patch. But after testing 2.6.24-rc7 with only the IOMMU changes applied it did crash once again. After looking at the patch that seems rather expected as it only touches powerpc code. (I only looked at its diffstat after testing it, so I was not aware of that fact during testing) > > If you send more patches, I'm willing to test them, but it might take > > some more time during the next week. > > Can you try 2.6.24-rc7 + the IOMMU changes? > > The patches are available at: > > http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/ > > Or if you prefer the git tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git > iommu-sg-fixes > > > > I've looked at the changes to GART but they are straightforward and > don't look wrong... The resulting 2.6.24-rc7 kernel worked for me. I compiled 146 packages without a crash. Today I finally had some time for debugging again and tried the new 2.6.24-rc8-mm1. The crash is still there, I will report that crash in current thread. Torsten -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Jan-Bernd Themann wrote: > Hi, > > sorry for answering so late, I'm only tracking netdev and ppc mailing list. > > On Thursday 10 January 2008 18:34, Greg KH wrote: > > > The structure device_driver(in device.h) has a member struct > > > driver_private which > > > contains the member kobj (according to drivers/base/base.h). > > > But in device.h struct driver_private has been declared localy and > > > neither defined nor included from base.h. > > > So my effort to use driver->driver_private->obj also does not work. > > > (I am surprised from where do you access the struct device_driver) > > > > That is because a driver should not be accessing such a field. > > > > And especially not in this manner, why would this driver be creating a > > symlink that has already been created by the driver core? This whole > > thing can just be removed with no problems. Can you try just removing > > the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to > > verify this as I don't have the hardware present to test it out. > > The eHEA driver tries to orginize its sys-entries as close as possible to > other ethernet drivers. Each eHEA NIC has multiple ports which is not that > common in PCI. This means that each port is represented by a subdirectory > which has not the "driver" sys-link, only the root directory has. > Some tools expect to have this driver link in each port directory. > That is the reason why this link is created manually. > > Are there any other ways to create this link? This is now broken in mainline... drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj' -- 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.24-rc6-mm1
Sorry for the *really* late answer, but I did not have any time to do linux things the last weeks. :-( On Jan 7, 2008 7:16 AM, FUJITA Tomonori [EMAIL PROTECTED] wrote: On Sun, 6 Jan 2008 21:03:42 +0100 Torsten Kaiser [EMAIL PROTECTED] wrote: On Jan 6, 2008 2:33 PM, FUJITA Tomonori [EMAIL PROTECTED] wrote: On Sun, 6 Jan 2008 12:35:35 +0100 Torsten Kaiser [EMAIL PROTECTED] wrote: On Jan 6, 2008 12:23 PM, FUJITA Tomonori [EMAIL PROTECTED] wrote: And double using something does fit with the errors I'm seeing... Can you try the patch to revert my IOMMU changes? http://www.mail-archive.com/[EMAIL PROTECTED]/msg12694.html - This is the revert-patch I'm talking about later Testing for this bug is a little bit slow, as I'm compiling ~100 packages trying to trigger it. If my current testrun with the patch from http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html crashes, I will revert the hole IOMMU changes with above patch and try again. Thanks for testing, OK, I'm still testing this, but after 95 completed packages I'm rather certain that reverting the IOMMU changes with this patch fixes my problem. I didn't have time to look more into this, so I can't offer any concrete ideas where the bug is. Until my last mail from 7. Jan this was true, that I was not able to crash 2.6.24-rc6-mm1 with above patch. But after testing 2.6.24-rc7 with only the IOMMU changes applied it did crash once again. After looking at the patch that seems rather expected as it only touches powerpc code. (I only looked at its diffstat after testing it, so I was not aware of that fact during testing) If you send more patches, I'm willing to test them, but it might take some more time during the next week. Can you try 2.6.24-rc7 + the IOMMU changes? The patches are available at: http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/ Or if you prefer the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git iommu-sg-fixes I've looked at the changes to GART but they are straightforward and don't look wrong... The resulting 2.6.24-rc7 kernel worked for me. I compiled 146 packages without a crash. Today I finally had some time for debugging again and tried the new 2.6.24-rc8-mm1. The crash is still there, I will report that crash in current thread. Torsten -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Jan-Bernd Themann wrote: Hi, sorry for answering so late, I'm only tracking netdev and ppc mailing list. On Thursday 10 January 2008 18:34, Greg KH wrote: The structure device_driver(in device.h) has a member struct driver_private which contains the member kobj (according to drivers/base/base.h). But in device.h struct driver_private has been declared localy and neither defined nor included from base.h. So my effort to use driver-driver_private-obj also does not work. (I am surprised from where do you access the struct device_driver) That is because a driver should not be accessing such a field. And especially not in this manner, why would this driver be creating a symlink that has already been created by the driver core? This whole thing can just be removed with no problems. Can you try just removing the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to verify this as I don't have the hardware present to test it out. The eHEA driver tries to orginize its sys-entries as close as possible to other ethernet drivers. Each eHEA NIC has multiple ports which is not that common in PCI. This means that each port is represented by a subdirectory which has not the driver sys-link, only the root directory has. Some tools expect to have this driver link in each port directory. That is the reason why this link is created manually. Are there any other ways to create this link? This is now broken in mainline... drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_add': drivers/net/ehea/ehea_main.c:2812: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2815: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c:2818: error: 'struct device_driver' has no member named 'kobj' drivers/net/ehea/ehea_main.c: In function 'ehea_driver_sysfs_remove': drivers/net/ehea/ehea_main.c:2830: error: 'struct device_driver' has no member named 'kobj' -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Hi, sorry for answering so late, I'm only tracking netdev and ppc mailing list. On Thursday 10 January 2008 18:34, Greg KH wrote: > > The structure device_driver(in device.h) has a member struct driver_private > > which > > contains the member kobj (according to drivers/base/base.h). > > But in device.h struct driver_private has been declared localy and > > neither defined nor included from base.h. > > So my effort to use driver->driver_private->obj also does not work. > > (I am surprised from where do you access the struct device_driver) > > That is because a driver should not be accessing such a field. > > And especially not in this manner, why would this driver be creating a > symlink that has already been created by the driver core? This whole > thing can just be removed with no problems. Can you try just removing > the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to > verify this as I don't have the hardware present to test it out. The eHEA driver tries to orginize its sys-entries as close as possible to other ethernet drivers. Each eHEA NIC has multiple ports which is not that common in PCI. This means that each port is represented by a subdirectory which has not the "driver" sys-link, only the root directory has. Some tools expect to have this driver link in each port directory. That is the reason why this link is created manually. Are there any other ways to create this link? Regards, Jan-Bernd Themann + Christoph Raisch -- 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.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
Hi, sorry for answering so late, I'm only tracking netdev and ppc mailing list. On Thursday 10 January 2008 18:34, Greg KH wrote: The structure device_driver(in device.h) has a member struct driver_private which contains the member kobj (according to drivers/base/base.h). But in device.h struct driver_private has been declared localy and neither defined nor included from base.h. So my effort to use driver-driver_private-obj also does not work. (I am surprised from where do you access the struct device_driver) That is because a driver should not be accessing such a field. And especially not in this manner, why would this driver be creating a symlink that has already been created by the driver core? This whole thing can just be removed with no problems. Can you try just removing the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to verify this as I don't have the hardware present to test it out. The eHEA driver tries to orginize its sys-entries as close as possible to other ethernet drivers. Each eHEA NIC has multiple ports which is not that common in PCI. This means that each port is represented by a subdirectory which has not the driver sys-link, only the root directory has. Some tools expect to have this driver link in each port directory. That is the reason why this link is created manually. Are there any other ways to create this link? Regards, Jan-Bernd Themann + Christoph Raisch -- 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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 6:04:28 pm [EMAIL PROTECTED] wrote: > On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said: > > http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff > >;h=02f1c89d6e36507476f78108a3dcc78538be460b > > Initial testing indicates that 2.6.24-rc6-mm1 plus this one commit is > behaving itself correctly - my Tcl test case that reliably demonstrated > wedges during SYN handling is definitively fixed, and the current issue > with hangs with data pending seems to be gone as well (after admittedly > light testing). > > Thanks for finding the commit that fixed it... No problem, glad to hear that fixed the problem. It's already in Linus' tree so any future -mm kernels as well as 2.6.24 should be problem-free, at least with respect to this ;) -- paul moore linux security @ hp -- 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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said: > > http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b Initial testing indicates that 2.6.24-rc6-mm1 plus this one commit is behaving itself correctly - my Tcl test case that reliably demonstrated wedges during SYN handling is definitively fixed, and the current issue with hangs with data pending seems to be gone as well (after admittedly light testing). Thanks for finding the commit that fixed it... pgpbYeOLHYJaR.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 2:37:02 pm [EMAIL PROTECTED] wrote: > On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said: > > There have been quite a few changes in lblnet-2.6_testing since > > 2.6.24-rc6-mm1 so I would recommend taking the whole tree. I'm also not > > quite sure if > > Weird. I did a 'git clone > git://git.infradead.org/users/pcmoore/lblnet-2.6_testing' into a new > directory this morning, and doing a 'git log' against that only showed the > one added commit: > > commit 5d95575903fd3865b884952bd93c339d48725c33 > Author: Paul Moore <[EMAIL PROTECTED]> > Date: Wed Jan 9 15:30:23 2008 -0500 > > SELinux: Add warning messages on network denial due to error > > Currently network traffic can be sliently dropped due to non-avc errors > which can lead to much confusion when trying to debug the problem. This > patch adds warning messages so that when these events occur there is a user > visible notification. > > Signed-off-by: Paul Moore <[EMAIL PROTECTED]> > > commit 9259ca5fd8b9fbdd2c3edade593dead905d8391e > Author: Paul Moore <[EMAIL PROTECTED]> > Date: Wed Jan 9 15:30:23 2008 -0500 > > SELinux: Add network ingress and egress control permission checks > (already in 24-rc6-mm1). > > Somebody please tell me it's my git-idiocy.. It might be something on my end with managing the lblnet-2.6_testing git tree; I'm still pretty clueless when it comes to git. I've got a git tree on my dev machine which is backed against Linus' tree and managed via stacked-git. I update the patches in this tree, refresh them against new bits from Linus, etc and when something significant changes I update the git tree on infradead.org and post a new patchset to the related lists. The process of updating the git tree on infradead.org usually involves deleting the entire tree located there, re-creating it, and then doing a git-push from my dev machine. I have no idea if this is "correct" or not, but I've often wondered if this is a the "right" way to do it ... -- paul moore linux security @ hp -- 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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said: > There have been quite a few changes in lblnet-2.6_testing since > 2.6.24-rc6-mm1 > so I would recommend taking the whole tree. I'm also not quite sure if Weird. I did a 'git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_testing' into a new directory this morning, and doing a 'git log' against that only showed the one added commit: commit 5d95575903fd3865b884952bd93c339d48725c33 Author: Paul Moore <[EMAIL PROTECTED]> Date: Wed Jan 9 15:30:23 2008 -0500 SELinux: Add warning messages on network denial due to error Currently network traffic can be sliently dropped due to non-avc errors which can lead to much confusion when trying to debug the problem. This patch adds warning messages so that when these events occur there is a user visible notification. Signed-off-by: Paul Moore <[EMAIL PROTECTED]> commit 9259ca5fd8b9fbdd2c3edade593dead905d8391e Author: Paul Moore <[EMAIL PROTECTED]> Date: Wed Jan 9 15:30:23 2008 -0500 SELinux: Add network ingress and egress control permission checks (already in 24-rc6-mm1). Somebody please tell me it's my git-idiocy.. > simply reverting the "Convert the netif code to use ifindex values" patch > would solve the problem as there are other patches in the rc6-mm1 tree that > rely on skb->iif being valid (new code, not converted code). That would explain why I'm still seeing issues.. > If you want to > stick with a _relatively_ vanilla rc6-mm1 tree I would leave everything in > and simply apply the following patch which solved the skb_clone()/iif > problem: > > http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b OK, I'll go look at that.. pgpoFfksm9xOZ.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 1:50:39 pm [EMAIL PROTECTED] wrote: > On Mon, 14 Jan 2008 13:22:10 EST, [EMAIL PROTECTED] said: > > Apparently the only new commit in there since the tree that was in > > 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some > > warning printk's. Would it be more productive to test against the full > > tree, or leaving out the one commit I already reverted? > > Nevermind... :) > > The new commit won't apply with the other one reverted - it patches > security/selinux/netnode.c which was created by the problematic commit... There have been quite a few changes in lblnet-2.6_testing since 2.6.24-rc6-mm1 so I would recommend taking the whole tree. I'm also not quite sure if simply reverting the "Convert the netif code to use ifindex values" patch would solve the problem as there are other patches in the rc6-mm1 tree that rely on skb->iif being valid (new code, not converted code). If you want to stick with a _relatively_ vanilla rc6-mm1 tree I would leave everything in and simply apply the following patch which solved the skb_clone()/iif problem: http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b -- paul moore linux security @ hp -- 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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 13:22:10 EST, [EMAIL PROTECTED] said: > Apparently the only new commit in there since the tree that was in > 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some warning > printk's. Would it be more productive to test against the full tree, or > leaving out the one commit I already reverted? Nevermind... :) The new commit won't apply with the other one reverted - it patches security/selinux/netnode.c which was created by the problematic commit... pgpPv4tdzmRsp.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 13:05:48 EST, [EMAIL PROTECTED] said: > I'm pulling git://git.infradead.org/users/pcmoore/lblnet-2.6_testing at the > moment, and seeing if there's already a fix in there for this. Apparently the only new commit in there since the tree that was in 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some warning printk's. Would it be more productive to test against the full tree, or leaving out the one commit I already reverted? pgpm8ZBFbvaFt.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 11:36:40 EST, Paul Moore said: > Are you still only seeing these problems on loopback? I can't help but > wonder > if this is the skb_clone() problem where it wasn't copying skb->iif causing > SELinux to silently drop the packets. Yes, I've only spotted it on loopback. The odd part is that I had reverted the one commit 9c6ad8f6895db7a517c04c2147cb5e7ffb83a315 "Convert the netif code to use ifindex values" - so either I managed to get the revert terribly wrong, or there's something else odd going on. The first time around, I was seeing hangs during a TCP 3-packet handshake - this time data flows for some number of packets before hanging. I'm pulling git://git.infradead.org/users/pcmoore/lblnet-2.6_testing at the moment, and seeing if there's already a fix in there for this. pgpy8SeXTkYp6.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 11:15:38 am [EMAIL PROTECTED] wrote: > On Sun, 13 Jan 2008 02:35:33 EST, [EMAIL PROTECTED] said: > > I'm seeing problems with Sendmail on 24-rc6-mm1, where the main Sendmail > > is listening on ::1/25, and Fetchmail connects to 127.0.0.1:25 to inject > > mail it has just fetched from an outside server via IMAP - it will often > > just hang and not make any further progress. Looking at netstat shows > > something interesting: > > > > % netstat -n -a -A inet | grep 25 > > tcp0 5108 127.0.0.1:59355 127.0.0.1:25 > > ESTABLISHED > > The IPv6 is apparently a red herring - this morning I'm seeing the same > problem with another totally separate pair of programs that are IPv4-only, > hanging on loopback. Are you still only seeing these problems on loopback? I can't help but wonder if this is the skb_clone() problem where it wasn't copying skb->iif causing SELinux to silently drop the packets. Then again, I'm not sure if there is a clone operation in the code path are going down. From what I can remember I only saw clones on some of the multicast stuff but I'm still learning some of the darker corners of the stack. If you've got some spare cycles, the kernel below should both have the clone/iif fix (it's in Linus' tree now) as well as some printks when errors occur so packet's are no longer silently dropped by SELinux. * git://git.infradead.org/users/pcmoore/lblnet-2.6_testing -- paul moore linux security @ hp -- 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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Sun, 13 Jan 2008 02:35:33 EST, [EMAIL PROTECTED] said: > I'm seeing problems with Sendmail on 24-rc6-mm1, where the main Sendmail is > listening on ::1/25, and Fetchmail connects to 127.0.0.1:25 to inject mail it > has just fetched from an outside server via IMAP - it will often just hang and > not make any further progress. Looking at netstat shows something interesting: > > % netstat -n -a -A inet | grep 25 > tcp0 5108 127.0.0.1:59355 127.0.0.1:25 > ESTABLISHED The IPv6 is apparently a red herring - this morning I'm seeing the same problem with another totally separate pair of programs that are IPv4-only, hanging on loopback. pgp0CbrEUPqh3.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Sun, 13 Jan 2008 02:35:33 EST, [EMAIL PROTECTED] said: I'm seeing problems with Sendmail on 24-rc6-mm1, where the main Sendmail is listening on ::1/25, and Fetchmail connects to 127.0.0.1:25 to inject mail it has just fetched from an outside server via IMAP - it will often just hang and not make any further progress. Looking at netstat shows something interesting: % netstat -n -a -A inet | grep 25 tcp0 5108 127.0.0.1:59355 127.0.0.1:25 ESTABLISHED The IPv6 is apparently a red herring - this morning I'm seeing the same problem with another totally separate pair of programs that are IPv4-only, hanging on loopback. pgp0CbrEUPqh3.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 11:15:38 am [EMAIL PROTECTED] wrote: On Sun, 13 Jan 2008 02:35:33 EST, [EMAIL PROTECTED] said: I'm seeing problems with Sendmail on 24-rc6-mm1, where the main Sendmail is listening on ::1/25, and Fetchmail connects to 127.0.0.1:25 to inject mail it has just fetched from an outside server via IMAP - it will often just hang and not make any further progress. Looking at netstat shows something interesting: % netstat -n -a -A inet | grep 25 tcp0 5108 127.0.0.1:59355 127.0.0.1:25 ESTABLISHED The IPv6 is apparently a red herring - this morning I'm seeing the same problem with another totally separate pair of programs that are IPv4-only, hanging on loopback. Are you still only seeing these problems on loopback? I can't help but wonder if this is the skb_clone() problem where it wasn't copying skb-iif causing SELinux to silently drop the packets. Then again, I'm not sure if there is a clone operation in the code path are going down. From what I can remember I only saw clones on some of the multicast stuff but I'm still learning some of the darker corners of the stack. If you've got some spare cycles, the kernel below should both have the clone/iif fix (it's in Linus' tree now) as well as some printks when errors occur so packet's are no longer silently dropped by SELinux. * git://git.infradead.org/users/pcmoore/lblnet-2.6_testing -- paul moore linux security @ hp -- 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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 11:36:40 EST, Paul Moore said: Are you still only seeing these problems on loopback? I can't help but wonder if this is the skb_clone() problem where it wasn't copying skb-iif causing SELinux to silently drop the packets. Yes, I've only spotted it on loopback. The odd part is that I had reverted the one commit 9c6ad8f6895db7a517c04c2147cb5e7ffb83a315 Convert the netif code to use ifindex values - so either I managed to get the revert terribly wrong, or there's something else odd going on. The first time around, I was seeing hangs during a TCP 3-packet handshake - this time data flows for some number of packets before hanging. I'm pulling git://git.infradead.org/users/pcmoore/lblnet-2.6_testing at the moment, and seeing if there's already a fix in there for this. pgpy8SeXTkYp6.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 13:05:48 EST, [EMAIL PROTECTED] said: I'm pulling git://git.infradead.org/users/pcmoore/lblnet-2.6_testing at the moment, and seeing if there's already a fix in there for this. Apparently the only new commit in there since the tree that was in 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some warning printk's. Would it be more productive to test against the full tree, or leaving out the one commit I already reverted? pgpm8ZBFbvaFt.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 13:22:10 EST, [EMAIL PROTECTED] said: Apparently the only new commit in there since the tree that was in 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some warning printk's. Would it be more productive to test against the full tree, or leaving out the one commit I already reverted? voice=Emily Litella Nevermind... /voice :) The new commit won't apply with the other one reverted - it patches security/selinux/netnode.c which was created by the problematic commit... pgpPv4tdzmRsp.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 1:50:39 pm [EMAIL PROTECTED] wrote: On Mon, 14 Jan 2008 13:22:10 EST, [EMAIL PROTECTED] said: Apparently the only new commit in there since the tree that was in 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some warning printk's. Would it be more productive to test against the full tree, or leaving out the one commit I already reverted? voice=Emily Litella Nevermind... /voice :) The new commit won't apply with the other one reverted - it patches security/selinux/netnode.c which was created by the problematic commit... There have been quite a few changes in lblnet-2.6_testing since 2.6.24-rc6-mm1 so I would recommend taking the whole tree. I'm also not quite sure if simply reverting the Convert the netif code to use ifindex values patch would solve the problem as there are other patches in the rc6-mm1 tree that rely on skb-iif being valid (new code, not converted code). If you want to stick with a _relatively_ vanilla rc6-mm1 tree I would leave everything in and simply apply the following patch which solved the skb_clone()/iif problem: http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b -- paul moore linux security @ hp -- 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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said: There have been quite a few changes in lblnet-2.6_testing since 2.6.24-rc6-mm1 so I would recommend taking the whole tree. I'm also not quite sure if Weird. I did a 'git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_testing' into a new directory this morning, and doing a 'git log' against that only showed the one added commit: commit 5d95575903fd3865b884952bd93c339d48725c33 Author: Paul Moore [EMAIL PROTECTED] Date: Wed Jan 9 15:30:23 2008 -0500 SELinux: Add warning messages on network denial due to error Currently network traffic can be sliently dropped due to non-avc errors which can lead to much confusion when trying to debug the problem. This patch adds warning messages so that when these events occur there is a user visible notification. Signed-off-by: Paul Moore [EMAIL PROTECTED] commit 9259ca5fd8b9fbdd2c3edade593dead905d8391e Author: Paul Moore [EMAIL PROTECTED] Date: Wed Jan 9 15:30:23 2008 -0500 SELinux: Add network ingress and egress control permission checks (already in 24-rc6-mm1). Somebody please tell me it's my git-idiocy.. simply reverting the Convert the netif code to use ifindex values patch would solve the problem as there are other patches in the rc6-mm1 tree that rely on skb-iif being valid (new code, not converted code). That would explain why I'm still seeing issues.. If you want to stick with a _relatively_ vanilla rc6-mm1 tree I would leave everything in and simply apply the following patch which solved the skb_clone()/iif problem: http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b OK, I'll go look at that.. pgpoFfksm9xOZ.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Monday 14 January 2008 6:04:28 pm [EMAIL PROTECTED] wrote: On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said: http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff ;h=02f1c89d6e36507476f78108a3dcc78538be460b Initial testing indicates that 2.6.24-rc6-mm1 plus this one commit is behaving itself correctly - my Tcl test case that reliably demonstrated wedges during SYN handling is definitively fixed, and the current issue with hangs with data pending seems to be gone as well (after admittedly light testing). Thanks for finding the commit that fixed it... No problem, glad to hear that fixed the problem. It's already in Linus' tree so any future -mm kernels as well as 2.6.24 should be problem-free, at least with respect to this ;) -- paul moore linux security @ hp -- 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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said: http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b Initial testing indicates that 2.6.24-rc6-mm1 plus this one commit is behaving itself correctly - my Tcl test case that reliably demonstrated wedges during SYN handling is definitively fixed, and the current issue with hangs with data pending seems to be gone as well (after admittedly light testing). Thanks for finding the commit that fixed it... pgpbYeOLHYJaR.pgp Description: PGP signature
Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
[EMAIL PROTECTED] wrote:
>
> Any ideas?
Please provide a packet dump on both sides (or at least the sender
side).
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
[EMAIL PROTECTED] wrote:
Any ideas?
Please provide a packet dump on both sides (or at least the sender
side).
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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.24-rc6-mm1 (driver core/sysfs)
On Mon, Dec 31, 2007 at 12:11:15PM -0800, Randy Dunlap wrote: > On Sat, 22 Dec 2007 23:30:56 -0800 Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ > > > With CONFIG_BLOCK=n: > > LD drivers/block/built-in.o > /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c: In function > 'device_add_class_symlinks': > /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c:707: error: > 'part_type' undeclared (first use in this function) > /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c: In function > 'device_remove_class_symlinks': > /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c:746: error: > 'part_type' undeclared (first use in this function) > make[3]: *** [drivers/base/core.o] Error 1 > > > and that is after fixing (in some sense) the first CONFIG_BLOCK=n > problem with the patch below. Please test lots of configs. > and/or use 'make randconfig' (automated, scripted, e.g., etc.). > maybe check Documentation/SubmitChecklist. :) Ingo seems to be saying that he has some kind of "automated" build system to do this kind of checking. Ingo, did you ever post how you did this anywhere? I have enough spare machines here that I should be able to set up something to test my stuff this way easier than doing it by hand all the time (as the above problem proves I do miss things :( ) > --- > > From: Randy Dunlap <[EMAIL PROTECTED]> > > Parts of driver core use blk_lookup_devt() when CONFIG_BLOCK=n, > so provide an short inline version of it for that case. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Thanks for this patch, I've merged it with the original block patch so there is no regression along the way. 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: 2.6.24-rc6-mm1 (driver core/sysfs)
On Mon, Dec 31, 2007 at 12:11:15PM -0800, Randy Dunlap wrote: On Sat, 22 Dec 2007 23:30:56 -0800 Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ With CONFIG_BLOCK=n: LD drivers/block/built-in.o /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c: In function 'device_add_class_symlinks': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c:707: error: 'part_type' undeclared (first use in this function) /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c: In function 'device_remove_class_symlinks': /local/linsrc/linux-2.6.24-rc6-mm1/drivers/base/core.c:746: error: 'part_type' undeclared (first use in this function) make[3]: *** [drivers/base/core.o] Error 1 and that is after fixing (in some sense) the first CONFIG_BLOCK=n problem with the patch below. Please test lots of configs. and/or use 'make randconfig' (automated, scripted, e.g., etc.). maybe check Documentation/SubmitChecklist. :) Ingo seems to be saying that he has some kind of automated build system to do this kind of checking. Ingo, did you ever post how you did this anywhere? I have enough spare machines here that I should be able to set up something to test my stuff this way easier than doing it by hand all the time (as the above problem proves I do miss things :( ) --- From: Randy Dunlap [EMAIL PROTECTED] Parts of driver core use blk_lookup_devt() when CONFIG_BLOCK=n, so provide an short inline version of it for that case. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Thanks for this patch, I've merged it with the original block patch so there is no regression along the way. 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Tue, Jan 08, 2008 at 10:03:05PM +0530, Sudhir Kumar wrote: > Hi Andrew, > Kernel build fails on my machine with error : > > > LD drivers/net/ehea/built-in.o > CC [M] drivers/net/ehea/ehea_main.o > drivers/net/ehea/ehea_main.c: In function ???ehea_driver_sysfs_add???: > drivers/net/ehea/ehea_main.c:2812: error: ???struct device_driver??? has no > member named ???kobj??? > drivers/net/ehea/ehea_main.c:2815: error: ???struct device_driver??? has no > member named ???kobj??? > drivers/net/ehea/ehea_main.c:2818: error: ???struct device_driver??? has no > member named ???kobj??? > drivers/net/ehea/ehea_main.c: In function ???ehea_driver_sysfs_remove???: > drivers/net/ehea/ehea_main.c:2830: error: ???struct device_driver??? has no > member named ???kobj??? > make[3]: *** [drivers/net/ehea/ehea_main.o] Error 1 > make[2]: *** [drivers/net/ehea] Error 2 > make[1]: *** [drivers/net] Error 2 > make: *** [drivers] Error 2 > > The structure device_driver(in device.h) has a member struct driver_private > which > contains the member kobj (according to drivers/base/base.h). > But in device.h struct driver_private has been declared localy and > neither defined nor included from base.h. > So my effort to use driver->driver_private->obj also does not work. > (I am surprised from where do you access the struct device_driver) That is because a driver should not be accessing such a field. And especially not in this manner, why would this driver be creating a symlink that has already been created by the driver core? This whole thing can just be removed with no problems. Can you try just removing the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to verify this as I don't have the hardware present to test it out. 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: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c
On Tue, Jan 08, 2008 at 10:03:05PM +0530, Sudhir Kumar wrote: Hi Andrew, Kernel build fails on my machine with error : LD drivers/net/ehea/built-in.o CC [M] drivers/net/ehea/ehea_main.o drivers/net/ehea/ehea_main.c: In function ???ehea_driver_sysfs_add???: drivers/net/ehea/ehea_main.c:2812: error: ???struct device_driver??? has no member named ???kobj??? drivers/net/ehea/ehea_main.c:2815: error: ???struct device_driver??? has no member named ???kobj??? drivers/net/ehea/ehea_main.c:2818: error: ???struct device_driver??? has no member named ???kobj??? drivers/net/ehea/ehea_main.c: In function ???ehea_driver_sysfs_remove???: drivers/net/ehea/ehea_main.c:2830: error: ???struct device_driver??? has no member named ???kobj??? make[3]: *** [drivers/net/ehea/ehea_main.o] Error 1 make[2]: *** [drivers/net/ehea] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 The structure device_driver(in device.h) has a member struct driver_private which contains the member kobj (according to drivers/base/base.h). But in device.h struct driver_private has been declared localy and neither defined nor included from base.h. So my effort to use driver-driver_private-obj also does not work. (I am surprised from where do you access the struct device_driver) That is because a driver should not be accessing such a field. And especially not in this manner, why would this driver be creating a symlink that has already been created by the driver core? This whole thing can just be removed with no problems. Can you try just removing the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to verify this as I don't have the hardware present to test it out. 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: 2.6.24-rc6-mm1
On Wed, 9 Jan 2008 10:04:42 +0100
Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 08:57:53AM +0900, FUJITA Tomonori wrote:
> ...
> > diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> > new file mode 100644
> > index 000..495575a
> > --- /dev/null
> > +++ b/lib/iommu-helper.c
> > @@ -0,0 +1,80 @@
> > +/*
> > + * IOMMU helper functions for the free area management
> > + */
> > +
> > +#include
> > +#include
> > +
> > +static unsigned long find_next_zero_area(unsigned long *map,
> > +unsigned long size,
> > +unsigned long start,
> > +unsigned int nr,
> > +unsigned long align_mask)
> > +{
> > + unsigned long index, end, i;
> > +again:
> > + index = find_next_zero_bit(map, size, start);
> > +
> > + /* Align allocation */
> > + index = (index + align_mask) & ~align_mask;
> > +
> > + end = index + nr;
> > + if (end >= size)
> > + return -1;
>
> This '>=' looks doubtful to me, e.g.:
> map points to 0s only, size = 64, nr = 64,
> we get: index = 0; end = 64;
> and: return -1 ?!
You are right. I did it only because I didn't want to change the
original code (iommu_range_alloc in arch/powerpc/kernel/iommu.c). I
thought that there might be a mysterious reason for it so I let it
alone since it's tiny loss.
Thanks,
--
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.24-rc6-mm1
On Wed, Jan 09, 2008 at 08:57:53AM +0900, FUJITA Tomonori wrote:
...
> diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> new file mode 100644
> index 000..495575a
> --- /dev/null
> +++ b/lib/iommu-helper.c
> @@ -0,0 +1,80 @@
> +/*
> + * IOMMU helper functions for the free area management
> + */
> +
> +#include
> +#include
> +
> +static unsigned long find_next_zero_area(unsigned long *map,
> + unsigned long size,
> + unsigned long start,
> + unsigned int nr,
> + unsigned long align_mask)
> +{
> + unsigned long index, end, i;
> +again:
> + index = find_next_zero_bit(map, size, start);
> +
> + /* Align allocation */
> + index = (index + align_mask) & ~align_mask;
> +
> + end = index + nr;
> + if (end >= size)
> + return -1;
This '>=' looks doubtful to me, e.g.:
map points to 0s only, size = 64, nr = 64,
we get: index = 0; end = 64;
and: return -1 ?!
Regards,
Jarek P.
--
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.24-rc6-mm1
On Wed, Jan 09, 2008 at 08:57:53AM +0900, FUJITA Tomonori wrote:
...
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
new file mode 100644
index 000..495575a
--- /dev/null
+++ b/lib/iommu-helper.c
@@ -0,0 +1,80 @@
+/*
+ * IOMMU helper functions for the free area management
+ */
+
+#include linux/module.h
+#include linux/bitops.h
+
+static unsigned long find_next_zero_area(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
+
+ end = index + nr;
+ if (end = size)
+ return -1;
This '=' looks doubtful to me, e.g.:
map points to 0s only, size = 64, nr = 64,
we get: index = 0; end = 64;
and: return -1 ?!
Regards,
Jarek P.
--
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.24-rc6-mm1
On Wed, 9 Jan 2008 10:04:42 +0100
Jarek Poplawski [EMAIL PROTECTED] wrote:
On Wed, Jan 09, 2008 at 08:57:53AM +0900, FUJITA Tomonori wrote:
...
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
new file mode 100644
index 000..495575a
--- /dev/null
+++ b/lib/iommu-helper.c
@@ -0,0 +1,80 @@
+/*
+ * IOMMU helper functions for the free area management
+ */
+
+#include linux/module.h
+#include linux/bitops.h
+
+static unsigned long find_next_zero_area(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
+
+ end = index + nr;
+ if (end = size)
+ return -1;
This '=' looks doubtful to me, e.g.:
map points to 0s only, size = 64, nr = 64,
we get: index = 0; end = 64;
and: return -1 ?!
You are right. I did it only because I didn't want to change the
original code (iommu_range_alloc in arch/powerpc/kernel/iommu.c). I
thought that there might be a mysterious reason for it so I let it
alone since it's tiny loss.
Thanks,
--
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.24-rc6-mm1
On Wed, 09 Jan 2008 09:54:45 +0900
FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > > --- a/lib/iommu-helper.c~a
> > > +++ a/lib/iommu-helper.c
> > > @@ -8,15 +8,20 @@
> > > static unsigned long find_next_zero_area(unsigned long *map,
> > >unsigned long size,
> > >unsigned long start,
> > > - unsigned int nr)
> > > + unsigned int nr,
> > > + unsigned long align_mask)
> > > {
> > > unsigned long index, end, i;
> > > again:
> > > index = find_next_zero_bit(map, size, start);
> > > +
> > > + /* Align allocation */
> > > + index = (index + align_mask) & ~align_mask;
> >
> > The ALIGN() macro is the approved way of doing this.
> >
> > (I don't think ALIGN adds much value really, especially given that you've
> > commented what's going on, but I guess it does make reviewing and reading a
> > little easier).
>
> Would be better to use __ALIGN_MASK? I can find only one user who
> directly use __ALIGN_MASK. The POWER IOMMU calculates align_mask by
> itself so it's easier to pass align_mask as an argument.
ALIGN() should be OK - its aditional type coercion isn't useful in this
case but ALIGN() is the official interface.
I don't see any reason why vermilion.c had to reach for __ALIGN_MASK. I'll
switch it to ALIGN().
--
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.24-rc6-mm1
On Tue, 8 Jan 2008 16:27:39 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 09 Jan 2008 08:57:53 +0900
> FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
>
> > Andrew, can you replace
> >
> > iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch
> >
> > with the updated patch:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html
> >
> > For your convenience I've attached the updated patch too.
>
>
Thanks for putting the fix to -mm.
> > --- a/lib/iommu-helper.c~a
> > +++ a/lib/iommu-helper.c
> > @@ -8,15 +8,20 @@
> > static unsigned long find_next_zero_area(unsigned long *map,
> > unsigned long size,
> > unsigned long start,
> > -unsigned int nr)
> > +unsigned int nr,
> > +unsigned long align_mask)
> > {
> > unsigned long index, end, i;
> > again:
> > index = find_next_zero_bit(map, size, start);
> > +
> > + /* Align allocation */
> > + index = (index + align_mask) & ~align_mask;
>
> The ALIGN() macro is the approved way of doing this.
>
> (I don't think ALIGN adds much value really, especially given that you've
> commented what's going on, but I guess it does make reviewing and reading a
> little easier).
Would be better to use __ALIGN_MASK? I can find only one user who
directly use __ALIGN_MASK. The POWER IOMMU calculates align_mask by
itself so it's easier to pass align_mask as an argument.
--
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.24-rc6-mm1
On Wed, 09 Jan 2008 08:57:53 +0900
FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> Andrew, can you replace
>
> iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch
>
> with the updated patch:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html
>
> For your convenience I've attached the updated patch too.
> --- a/lib/iommu-helper.c~a
> +++ a/lib/iommu-helper.c
> @@ -8,15 +8,20 @@
> static unsigned long find_next_zero_area(unsigned long *map,
>unsigned long size,
>unsigned long start,
> - unsigned int nr)
> + unsigned int nr,
> + unsigned long align_mask)
> {
> unsigned long index, end, i;
> again:
> index = find_next_zero_bit(map, size, start);
> +
> + /* Align allocation */
> + index = (index + align_mask) & ~align_mask;
The ALIGN() macro is the approved way of doing this.
(I don't think ALIGN adds much value really, especially given that you've
commented what's going on, but I guess it does make reviewing and reading a
little easier).
> end = index + nr;
> - if (end > size)
> + if (end >= size)
> return -1;
> - for (i = index + 1; i < end; i++) {
> + for (i = index; i < end; i++) {
> if (test_bit(i, map)) {
> start = i+1;
> goto again;
> @@ -50,9 +55,8 @@ unsigned long iommu_area_alloc(unsigned
> {
> unsigned long index;
> again:
> - index = find_next_zero_area(map, size, start, nr);
> + index = find_next_zero_area(map, size, start, nr, align_mask);
> if (index != -1) {
> - index = (index + align_mask) & ~align_mask;
> if (is_span_boundary(index, nr, shift, boundary_size)) {
> /* we could do more effectively */
> start = index + 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: 2.6.24-rc6-mm1
On Tue, 8 Jan 2008 16:59:48 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
>
> > The patches are available at:
> >
> > http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/
> >
> > Or if you prefer the git tree:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git
> > iommu-sg-fixes
>
> btw., these improvements to the IOMMU code are in -mm and will go into
> v2.6.25, right? The changes look robust to me.
Thanks, they have been in -mm though the iommu helper fix hasn't
yet. Balbir Singh found the bug in 2.6.24-rc6-mm1. I've just check
mmotm and found that the IOMMU helper patch doesn't include the fix.
Andrew, can you replace
iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch
with the updated patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html
For your convenience I've attached the updated patch too.
Hopefully, they will go into v2.6.25. At least, I hope that the
patches (0001-0011) that make the IOMMUs respect segment size limits
when merging sg lists will be merged. They are simple and I got ACKs
on POWER and PARISC.
Thanks,
=
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH] add IOMMU helper functions for the free area management
This adds IOMMU helper functions for the free area management. These
functions take care of LLD's segment boundary limit for IOMMUs. They would be
useful for IOMMUs that use bitmap for the free area management.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
include/linux/iommu-helper.h |7
lib/Makefile |1 +
lib/iommu-helper.c | 80 ++
3 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 include/linux/iommu-helper.h
create mode 100644 lib/iommu-helper.c
diff --git a/include/linux/iommu-helper.h b/include/linux/iommu-helper.h
new file mode 100644
index 000..4dd4c04
--- /dev/null
+++ b/include/linux/iommu-helper.h
@@ -0,0 +1,7 @@
+extern unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
+ unsigned long start, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size,
+ unsigned long align_mask);
+extern void iommu_area_free(unsigned long *map, unsigned long start,
+ unsigned int nr);
diff --git a/lib/Makefile b/lib/Makefile
index b6793ed..0e7383f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_SMP) += percpu_counter.o
obj-$(CONFIG_AUDIT_GENERIC) += audit.o
obj-$(CONFIG_SWIOTLB) += swiotlb.o
+obj-$(CONFIG_IOMMU_HELPER) += iommu-helper.o
obj-$(CONFIG_FAULT_INJECTION) += fault-inject.o
lib-$(CONFIG_GENERIC_BUG) += bug.o
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
new file mode 100644
index 000..495575a
--- /dev/null
+++ b/lib/iommu-helper.c
@@ -0,0 +1,80 @@
+/*
+ * IOMMU helper functions for the free area management
+ */
+
+#include
+#include
+
+static unsigned long find_next_zero_area(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) & ~align_mask;
+
+ end = index + nr;
+ if (end >= size)
+ return -1;
+ for (i = index; i < end; i++) {
+ if (test_bit(i, map)) {
+ start = i+1;
+ goto again;
+ }
+ }
+ return index;
+}
+
+static inline void set_bit_area(unsigned long *map, unsigned long i,
+ int len)
+{
+ unsigned long end = i + len;
+ while (i < end) {
+ __set_bit(i, map);
+ i++;
+ }
+}
+
+static inline int is_span_boundary(unsigned int index, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size)
+{
+ shift = (shift + index) & (boundary_size - 1);
+ return shift + nr > boundary_size;
+}
+
+unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
+ unsigned long start, unsigned int nr,
+ unsigned long shift, unsigned long boundary_size,
+ unsigned long align_mask)
+{
+ unsigned long index;
+again:
+ index = find_next_zero_area(map, size, start, nr, align_mask);
+ if (index != -1) {
+ if (is_span_boundary(index, nr, shift, boundary_size)) {
+ /* we could do more
Re: 2.6.24-rc6-mm1
* FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > The patches are available at: > > http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/ > > Or if you prefer the git tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git > iommu-sg-fixes btw., these improvements to the IOMMU code are in -mm and will go into v2.6.25, right? The changes look robust to me. 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.24-rc6-mm1
* FUJITA Tomonori [EMAIL PROTECTED] wrote: The patches are available at: http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/ Or if you prefer the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git iommu-sg-fixes btw., these improvements to the IOMMU code are in -mm and will go into v2.6.25, right? The changes look robust to me. 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.24-rc6-mm1
On Tue, 8 Jan 2008 16:59:48 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* FUJITA Tomonori [EMAIL PROTECTED] wrote:
The patches are available at:
http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/
Or if you prefer the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git
iommu-sg-fixes
btw., these improvements to the IOMMU code are in -mm and will go into
v2.6.25, right? The changes look robust to me.
Thanks, they have been in -mm though the iommu helper fix hasn't
yet. Balbir Singh found the bug in 2.6.24-rc6-mm1. I've just check
mmotm and found that the IOMMU helper patch doesn't include the fix.
Andrew, can you replace
iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch
with the updated patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html
For your convenience I've attached the updated patch too.
Hopefully, they will go into v2.6.25. At least, I hope that the
patches (0001-0011) that make the IOMMUs respect segment size limits
when merging sg lists will be merged. They are simple and I got ACKs
on POWER and PARISC.
Thanks,
=
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH] add IOMMU helper functions for the free area management
This adds IOMMU helper functions for the free area management. These
functions take care of LLD's segment boundary limit for IOMMUs. They would be
useful for IOMMUs that use bitmap for the free area management.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
include/linux/iommu-helper.h |7
lib/Makefile |1 +
lib/iommu-helper.c | 80 ++
3 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 include/linux/iommu-helper.h
create mode 100644 lib/iommu-helper.c
diff --git a/include/linux/iommu-helper.h b/include/linux/iommu-helper.h
new file mode 100644
index 000..4dd4c04
--- /dev/null
+++ b/include/linux/iommu-helper.h
@@ -0,0 +1,7 @@
+extern unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
+ unsigned long start, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size,
+ unsigned long align_mask);
+extern void iommu_area_free(unsigned long *map, unsigned long start,
+ unsigned int nr);
diff --git a/lib/Makefile b/lib/Makefile
index b6793ed..0e7383f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_SMP) += percpu_counter.o
obj-$(CONFIG_AUDIT_GENERIC) += audit.o
obj-$(CONFIG_SWIOTLB) += swiotlb.o
+obj-$(CONFIG_IOMMU_HELPER) += iommu-helper.o
obj-$(CONFIG_FAULT_INJECTION) += fault-inject.o
lib-$(CONFIG_GENERIC_BUG) += bug.o
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
new file mode 100644
index 000..495575a
--- /dev/null
+++ b/lib/iommu-helper.c
@@ -0,0 +1,80 @@
+/*
+ * IOMMU helper functions for the free area management
+ */
+
+#include linux/module.h
+#include linux/bitops.h
+
+static unsigned long find_next_zero_area(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
+
+ end = index + nr;
+ if (end = size)
+ return -1;
+ for (i = index; i end; i++) {
+ if (test_bit(i, map)) {
+ start = i+1;
+ goto again;
+ }
+ }
+ return index;
+}
+
+static inline void set_bit_area(unsigned long *map, unsigned long i,
+ int len)
+{
+ unsigned long end = i + len;
+ while (i end) {
+ __set_bit(i, map);
+ i++;
+ }
+}
+
+static inline int is_span_boundary(unsigned int index, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size)
+{
+ shift = (shift + index) (boundary_size - 1);
+ return shift + nr boundary_size;
+}
+
+unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
+ unsigned long start, unsigned int nr,
+ unsigned long shift, unsigned long boundary_size,
+ unsigned long align_mask)
+{
+ unsigned long index;
+again:
+ index = find_next_zero_area(map, size, start, nr, align_mask);
+ if (index != -1) {
+ if (is_span_boundary(index, nr, shift, boundary_size)) {
+ /* we could do more
Re: 2.6.24-rc6-mm1
On Wed, 09 Jan 2008 08:57:53 +0900
FUJITA Tomonori [EMAIL PROTECTED] wrote:
Andrew, can you replace
iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch
with the updated patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html
For your convenience I've attached the updated patch too.
generates the incremental
--- a/lib/iommu-helper.c~a
+++ a/lib/iommu-helper.c
@@ -8,15 +8,20 @@
static unsigned long find_next_zero_area(unsigned long *map,
unsigned long size,
unsigned long start,
- unsigned int nr)
+ unsigned int nr,
+ unsigned long align_mask)
{
unsigned long index, end, i;
again:
index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
The ALIGN() macro is the approved way of doing this.
(I don't think ALIGN adds much value really, especially given that you've
commented what's going on, but I guess it does make reviewing and reading a
little easier).
end = index + nr;
- if (end size)
+ if (end = size)
return -1;
- for (i = index + 1; i end; i++) {
+ for (i = index; i end; i++) {
if (test_bit(i, map)) {
start = i+1;
goto again;
@@ -50,9 +55,8 @@ unsigned long iommu_area_alloc(unsigned
{
unsigned long index;
again:
- index = find_next_zero_area(map, size, start, nr);
+ index = find_next_zero_area(map, size, start, nr, align_mask);
if (index != -1) {
- index = (index + align_mask) ~align_mask;
if (is_span_boundary(index, nr, shift, boundary_size)) {
/* we could do more effectively */
start = index + 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: 2.6.24-rc6-mm1
On Tue, 8 Jan 2008 16:27:39 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 09 Jan 2008 08:57:53 +0900
FUJITA Tomonori [EMAIL PROTECTED] wrote:
Andrew, can you replace
iommu-sg-add-iommu-helper-functions-for-the-free-area-management.patch
with the updated patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html
For your convenience I've attached the updated patch too.
generates the incremental
Thanks for putting the fix to -mm.
--- a/lib/iommu-helper.c~a
+++ a/lib/iommu-helper.c
@@ -8,15 +8,20 @@
static unsigned long find_next_zero_area(unsigned long *map,
unsigned long size,
unsigned long start,
-unsigned int nr)
+unsigned int nr,
+unsigned long align_mask)
{
unsigned long index, end, i;
again:
index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
The ALIGN() macro is the approved way of doing this.
(I don't think ALIGN adds much value really, especially given that you've
commented what's going on, but I guess it does make reviewing and reading a
little easier).
Would be better to use __ALIGN_MASK? I can find only one user who
directly use __ALIGN_MASK. The POWER IOMMU calculates align_mask by
itself so it's easier to pass align_mask as an argument.
--
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.24-rc6-mm1
On Wed, 09 Jan 2008 09:54:45 +0900
FUJITA Tomonori [EMAIL PROTECTED] wrote:
--- a/lib/iommu-helper.c~a
+++ a/lib/iommu-helper.c
@@ -8,15 +8,20 @@
static unsigned long find_next_zero_area(unsigned long *map,
unsigned long size,
unsigned long start,
- unsigned int nr)
+ unsigned int nr,
+ unsigned long align_mask)
{
unsigned long index, end, i;
again:
index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
The ALIGN() macro is the approved way of doing this.
(I don't think ALIGN adds much value really, especially given that you've
commented what's going on, but I guess it does make reviewing and reading a
little easier).
Would be better to use __ALIGN_MASK? I can find only one user who
directly use __ALIGN_MASK. The POWER IOMMU calculates align_mask by
itself so it's easier to pass align_mask as an argument.
ALIGN() should be OK - its aditional type coercion isn't useful in this
case but ALIGN() is the official interface.
I don't see any reason why vermilion.c had to reach for __ALIGN_MASK. I'll
switch it to ALIGN().
--
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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, 7 Jan 2008 17:50:49 +0100 (CET) Thomas Gleixner wrote: > On Mon, 7 Jan 2008, Randy Dunlap wrote: > > On Mon, 7 Jan 2008 15:56:09 +0100 Ingo Molnar wrote: > > > i'm also wondering - what would be the easiest way to integrate kexec > > > into an automated test environment. If i have a bzImage kernel, is kexec > > > still supposed to work? Could i for example do a reboot into a new > > > (kexec-enabled) kernel via kexec in essence? > > > > My daily/nightly kernel test runs use kexec to boot the test kernel. > > Well, did thru 2.6.24-rc6-git9, but they fail after that. > > Hopefully this patch fixes things. > > The patch in question is not in mainline, it's in the mm branch of > x86.git. So the problem in mainline is a different one. Could you > bisect it please ? Ugh. As happens during demos, this (kexec failure) won't happen for me when I want it to. I'll keep an eye out for it... --- ~Randy -- 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.24-rc6-mm1] Build Failure on ppc64 with CONFIG_USB_GADGET not set.
Hi, Am Montag 07 Januar 2008 schrieb Andrew Morton: > Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > This is evil select playing games (again). > > We have LEDS_CLASS equal y but NEW_LEDS equal n > > Ah, OK, thanks. > > I'll switch oz99x-i2c-button-and-led-support-driver.patch over to using > non-evil `depends on LEDS_CLASS'. If you wait a moment, I'll send you an updated patch that makes LED support optional in the driver. HS -- 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.24-rc6-mm1] Build Failure on ppc64 with CONFIG_USB_GADGET not set.
On Mon, 7 Jan 2008 20:15:31 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > On Mon, Jan 07, 2008 at 09:49:55AM -0800, Andrew Morton wrote: > > On Mon, 7 Jan 2008 16:53:58 +0530 "sudhir kumar" <[EMAIL PROTECTED]> wrote: > > > > > Hi Andrew! > > > > > > Kernel build fails on my ppc64 machine. It seems to be a dependency > > > problem with CONFIG_USB_GADGET not set. > > > Config file is attached. > > > > > > CC init/version.o > > > LD init/built-in.o > > > LD .tmp_vmlinux1 > > > drivers/built-in.o: In function `oz99x_remove': > > > drivers/i2c/chips/oz99x.c:660: undefined reference to > > > `.led_classdev_unregister' > > > drivers/built-in.o: In function `oz99x_configure_leds': > > > drivers/i2c/chips/oz99x.c:314: undefined reference to > > > `.led_classdev_register' > > > make: *** [.tmp_vmlinux1] Error 1 > > > > > > > Strange. > > > > oz99x-i2c-button-and-led-support-driver.patch has > > > > +config OZ99X > > + tristate "O2 Micro/ETC OZ990/OZ992 SMBus chip" > > + depends on I2C > > + select INPUT_POLLDEV > > + select LEDS_CLASS > > > > and your .config gives > > > > box:/usr/src/25> grep LEDS .config > > # CONFIG_NEW_LEDS is not set > > CONFIG_LEDS_CLASS=y > > > > so drivers/leds/led-class.o should be linked into your vmlinux. But that > > obviously isn't happening. > Because CONFIG_NEW_LEDS is not set we do not visit drivers/leds due to: > obj-$(CONFIG_NEW_LEDS) += leds/ > in drivers/Makefile > > This is evil select playing games (again). > We have LEDS_CLASS equal y but NEW_LEDS equal n > Ah, OK, thanks. I'll switch oz99x-i2c-button-and-led-support-driver.patch over to using non-evil `depends on LEDS_CLASS'. -- 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.24-rc6-mm1] Build Failure on ppc64 with CONFIG_USB_GADGET not set.
On Mon, Jan 07, 2008 at 09:49:55AM -0800, Andrew Morton wrote: > On Mon, 7 Jan 2008 16:53:58 +0530 "sudhir kumar" <[EMAIL PROTECTED]> wrote: > > > Hi Andrew! > > > > Kernel build fails on my ppc64 machine. It seems to be a dependency > > problem with CONFIG_USB_GADGET not set. > > Config file is attached. > > > > CC init/version.o > > LD init/built-in.o > > LD .tmp_vmlinux1 > > drivers/built-in.o: In function `oz99x_remove': > > drivers/i2c/chips/oz99x.c:660: undefined reference to > > `.led_classdev_unregister' > > drivers/built-in.o: In function `oz99x_configure_leds': > > drivers/i2c/chips/oz99x.c:314: undefined reference to > > `.led_classdev_register' > > make: *** [.tmp_vmlinux1] Error 1 > > > > Strange. > > oz99x-i2c-button-and-led-support-driver.patch has > > +config OZ99X > + tristate "O2 Micro/ETC OZ990/OZ992 SMBus chip" > + depends on I2C > + select INPUT_POLLDEV > + select LEDS_CLASS > > and your .config gives > > box:/usr/src/25> grep LEDS .config > # CONFIG_NEW_LEDS is not set > CONFIG_LEDS_CLASS=y > > so drivers/leds/led-class.o should be linked into your vmlinux. But that > obviously isn't happening. Because CONFIG_NEW_LEDS is not set we do not visit drivers/leds due to: obj-$(CONFIG_NEW_LEDS) += leds/ in drivers/Makefile This is evil select playing games (again). We have LEDS_CLASS equal y but NEW_LEDS equal n 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/
Re: [2.6.24-rc6-mm1] Build Failure on ppc64 with CONFIG_USB_GADGET not set.
On Mon, 7 Jan 2008 16:53:58 +0530 "sudhir kumar" <[EMAIL PROTECTED]> wrote: > Hi Andrew! > > Kernel build fails on my ppc64 machine. It seems to be a dependency > problem with CONFIG_USB_GADGET not set. > Config file is attached. > > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > drivers/built-in.o: In function `oz99x_remove': > drivers/i2c/chips/oz99x.c:660: undefined reference to > `.led_classdev_unregister' > drivers/built-in.o: In function `oz99x_configure_leds': > drivers/i2c/chips/oz99x.c:314: undefined reference to `.led_classdev_register' > make: *** [.tmp_vmlinux1] Error 1 > Strange. oz99x-i2c-button-and-led-support-driver.patch has +config OZ99X + tristate "O2 Micro/ETC OZ990/OZ992 SMBus chip" + depends on I2C + select INPUT_POLLDEV + select LEDS_CLASS and your .config gives box:/usr/src/25> grep LEDS .config # CONFIG_NEW_LEDS is not set CONFIG_LEDS_CLASS=y so drivers/leds/led-class.o should be linked into your vmlinux. But that obviously isn't happening. -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, 7 Jan 2008, Randy Dunlap wrote: > On Mon, 7 Jan 2008 15:56:09 +0100 Ingo Molnar wrote: > > i'm also wondering - what would be the easiest way to integrate kexec > > into an automated test environment. If i have a bzImage kernel, is kexec > > still supposed to work? Could i for example do a reboot into a new > > (kexec-enabled) kernel via kexec in essence? > > My daily/nightly kernel test runs use kexec to boot the test kernel. > Well, did thru 2.6.24-rc6-git9, but they fail after that. > Hopefully this patch fixes things. The patch in question is not in mainline, it's in the mm branch of x86.git. So the problem in mainline is a different one. Could you bisect it please ? Thanks, tglx -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, Jan 07, 2008 at 08:22:37AM -0800, Randy Dunlap wrote: > On Mon, 7 Jan 2008 15:56:09 +0100 Ingo Molnar wrote: > > > > > * Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > > > On Mon, 7 Jan 2008, Dhaval Giani wrote: > > > > > > > Hi Andrew, Ingo, Thomas, Peter, > > > > > > > > x86: revert i386: handle an initrd in highmem > > > > > > > > The patch caused a failure while booting a kexec kernel. > > > > (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) > > > > > > > > The following patch reverts it. > > > > > > > > Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]> > > > > > > Thanks for tracking this down. I'll pull the patch from the x86 git > > > tree as well. > > > > Dhaval, how about the other problem you had - do you have any guess > > what it might be related to? > > > > i'm also wondering - what would be the easiest way to integrate kexec > > into an automated test environment. If i have a bzImage kernel, is kexec > > still supposed to work? Could i for example do a reboot into a new > > (kexec-enabled) kernel via kexec in essence? > > My daily/nightly kernel test runs use kexec to boot the test kernel. > Well, did thru 2.6.24-rc6-git9, but they fail after that. > Hopefully this patch fixes things. > hmmm. I don't think so. This revert is from the x86 git tree (-mm) (I think targetted for 2.6.25). Probably a bisect might help there. -- regards, Dhaval -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, 7 Jan 2008 15:56:09 +0100 Ingo Molnar wrote: > > * Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > On Mon, 7 Jan 2008, Dhaval Giani wrote: > > > > > Hi Andrew, Ingo, Thomas, Peter, > > > > > > x86: revert i386: handle an initrd in highmem > > > > > > The patch caused a failure while booting a kexec kernel. > > > (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) > > > > > > The following patch reverts it. > > > > > > Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]> > > > > Thanks for tracking this down. I'll pull the patch from the x86 git > > tree as well. > > Dhaval, how about the other problem you had - do you have any guess > what it might be related to? > > i'm also wondering - what would be the easiest way to integrate kexec > into an automated test environment. If i have a bzImage kernel, is kexec > still supposed to work? Could i for example do a reboot into a new > (kexec-enabled) kernel via kexec in essence? My daily/nightly kernel test runs use kexec to boot the test kernel. Well, did thru 2.6.24-rc6-git9, but they fail after that. Hopefully this patch fixes things. --- ~Randy -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, Jan 07, 2008 at 03:56:09PM +0100, Ingo Molnar wrote: > > * Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > On Mon, 7 Jan 2008, Dhaval Giani wrote: > > > > > Hi Andrew, Ingo, Thomas, Peter, > > > > > > x86: revert i386: handle an initrd in highmem > > > > > > The patch caused a failure while booting a kexec kernel. > > > (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) > > > > > > The following patch reverts it. > > > > > > Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]> > > > > Thanks for tracking this down. I'll pull the patch from the x86 git > > tree as well. > > Dhaval, how about the other problem you had - do you have any guess > what it might be related to? > other problem? The load_balance_monitor one? (We are still looking into that one, just seems that se (as usual :) ) is turning out to be null). > i'm also wondering - what would be the easiest way to integrate kexec > into an automated test environment. If i have a bzImage kernel, is kexec > still supposed to work? Could i for example do a reboot into a new > (kexec-enabled) kernel via kexec in essence? > Yes, I use a bzImage kernel to reboot using kexec. I use a script which just sets it up for me. (I can send it to you separately). -- regards, Dhaval -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
* Thomas Gleixner <[EMAIL PROTECTED]> wrote: > On Mon, 7 Jan 2008, Dhaval Giani wrote: > > > Hi Andrew, Ingo, Thomas, Peter, > > > > x86: revert i386: handle an initrd in highmem > > > > The patch caused a failure while booting a kexec kernel. > > (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) > > > > The following patch reverts it. > > > > Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]> > > Thanks for tracking this down. I'll pull the patch from the x86 git > tree as well. Dhaval, how about the other problem you had - do you have any guess what it might be related to? i'm also wondering - what would be the easiest way to integrate kexec into an automated test environment. If i have a bzImage kernel, is kexec still supposed to work? Could i for example do a reboot into a new (kexec-enabled) kernel via kexec in essence? 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: [PATCH -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, 7 Jan 2008, Dhaval Giani wrote: > Hi Andrew, Ingo, Thomas, Peter, > > x86: revert i386: handle an initrd in highmem > > The patch caused a failure while booting a kexec kernel. > (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) > > The following patch reverts it. > > Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]> Thanks for tracking this down. I'll pull the patch from the x86 git tree as well. tglx -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
Hi Andrew, Ingo, Thomas, Peter,
x86: revert i386: handle an initrd in highmem
The patch caused a failure while booting a kexec kernel.
(http://lkml.org/lkml/2008/1/7/42 has the bisect details.)
The following patch reverts it.
Signed-off-by: Dhaval Giani <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
---
arch/x86/boot/header.S |5 -
arch/x86/kernel/setup_32.c | 113 +++--
2 files changed, 19 insertions(+), 99 deletions(-)
Index: linux-2.6.24-rc6/arch/x86/boot/header.S
===
--- linux-2.6.24-rc6.orig/arch/x86/boot/header.S
+++ linux-2.6.24-rc6/arch/x86/boot/header.S
@@ -195,13 +195,10 @@ cmd_line_ptr: .long 0 # (Header
version
# can be located anywhere in
# low memory 0x1 or higher.
-ramdisk_max: .long 0x7fff
+ramdisk_max: .long (-__PAGE_OFFSET-(512 << 20)-1) & 0x7fff
# (Header version 0x0203 or later)
# The highest safe address for
# the contents of an initrd
- # The current kernel allows up to 4 GB,
- # but leave it at 2 GB to avoid
- # possible bootloader bugs.
kernel_alignment: .long CONFIG_PHYSICAL_ALIGN #physical addr alignment
#required for protected mode
Index: linux-2.6.24-rc6/arch/x86/kernel/setup_32.c
===
--- linux-2.6.24-rc6.orig/arch/x86/kernel/setup_32.c
+++ linux-2.6.24-rc6/arch/x86/kernel/setup_32.c
@@ -583,95 +583,6 @@ static void __init relocate_initrd(void)
#endif /* CONFIG_BLK_DEV_INITRD */
-#ifdef CONFIG_BLK_DEV_INITRD
-
-static bool do_relocate_initrd = false;
-
-static void __init reserve_initrd(void)
-{
- unsigned long ramdisk_image = boot_params.hdr.ramdisk_image;
- unsigned long ramdisk_size = boot_params.hdr.ramdisk_size;
- unsigned long ramdisk_end = ramdisk_image + ramdisk_size;
- unsigned long end_of_lowmem = max_low_pfn << PAGE_SHIFT;
- unsigned long ramdisk_here;
-
- if (ramdisk_end < ramdisk_image) {
- printk(KERN_ERR "initrd wraps around end of memory\n"
- KERN_ERR "disabling initrd\n");
- initrd_start = 0;
- return;
- }
- if (ramdisk_size >= end_of_lowmem/2) {
- printk(KERN_ERR "initrd too large to handle\n"
- KERN_ERR "disabling initrd\n");
- initrd_start = 0;
- return;
- }
- if (ramdisk_end <= end_of_lowmem) {
- /* All in lowmem, easy case */
- reserve_bootmem(ramdisk_image, ramdisk_size);
- initrd_start = ramdisk_image + PAGE_OFFSET;
- initrd_end = initrd_start+ramdisk_size;
- return;
- }
-
- /* We need to move the initrd down into lowmem */
- ramdisk_here = (end_of_lowmem - ramdisk_size) & PAGE_MASK;
-
- /* Note: this includes all the lowmem currently occupied by
- the initrd, we rely on that fact to keep the data intact. */
- reserve_bootmem(ramdisk_here, ramdisk_size);
- initrd_start = ramdisk_here + PAGE_OFFSET;
- initrd_end = initrd_start + ramdisk_size;
-
- do_relocate_initrd = true;
-}
-
-#define MAX_MAP_CHUNK (NR_FIX_BTMAPS << PAGE_SHIFT)
-
-static void __init relocate_initrd(void)
-{
- unsigned long ramdisk_image = boot_params.hdr.ramdisk_image;
- unsigned long ramdisk_size = boot_params.hdr.ramdisk_size;
- unsigned long end_of_lowmem = max_low_pfn << PAGE_SHIFT;
- unsigned long ramdisk_here;
- unsigned long slop, clen, mapaddr;
- char *p, *q;
-
- if (!do_relocate_initrd)
- return; /* Nothing to do here... */
-
- ramdisk_here = initrd_start - PAGE_OFFSET;
- q = (char *)initrd_start;
-
- /* Copy any lowmem portion of the initrd */
- if (ramdisk_image < end_of_lowmem) {
- clen = end_of_lowmem - ramdisk_image;
- p = (char *)__va(ramdisk_image);
- memcpy(q, p, clen);
- q += clen;
- ramdisk_image += clen;
- ramdisk_size -= clen;
- }
-
- /* Copy the highmem portion of the initrd */
- while (ramdisk_size) {
- slop = ramdisk_image & ~PAGE_MASK;
- clen = ramdisk_size;
- if (clen > MAX_MAP_CHUNK-slop)
- clen = MAX_MAP_CHUNK-slop;
- mapaddr = ramdisk_image & PAGE_MASK;
- p = bt_ioremap(mapaddr, clen+slop);
-
[PATCH -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
Hi Andrew, Ingo, Thomas, Peter,
x86: revert i386: handle an initrd in highmem
The patch caused a failure while booting a kexec kernel.
(http://lkml.org/lkml/2008/1/7/42 has the bisect details.)
The following patch reverts it.
Signed-off-by: Dhaval Giani [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: Thomas Gleixner [EMAIL PROTECTED]
Cc: H. Peter Anvin [EMAIL PROTECTED]
---
arch/x86/boot/header.S |5 -
arch/x86/kernel/setup_32.c | 113 +++--
2 files changed, 19 insertions(+), 99 deletions(-)
Index: linux-2.6.24-rc6/arch/x86/boot/header.S
===
--- linux-2.6.24-rc6.orig/arch/x86/boot/header.S
+++ linux-2.6.24-rc6/arch/x86/boot/header.S
@@ -195,13 +195,10 @@ cmd_line_ptr: .long 0 # (Header
version
# can be located anywhere in
# low memory 0x1 or higher.
-ramdisk_max: .long 0x7fff
+ramdisk_max: .long (-__PAGE_OFFSET-(512 20)-1) 0x7fff
# (Header version 0x0203 or later)
# The highest safe address for
# the contents of an initrd
- # The current kernel allows up to 4 GB,
- # but leave it at 2 GB to avoid
- # possible bootloader bugs.
kernel_alignment: .long CONFIG_PHYSICAL_ALIGN #physical addr alignment
#required for protected mode
Index: linux-2.6.24-rc6/arch/x86/kernel/setup_32.c
===
--- linux-2.6.24-rc6.orig/arch/x86/kernel/setup_32.c
+++ linux-2.6.24-rc6/arch/x86/kernel/setup_32.c
@@ -583,95 +583,6 @@ static void __init relocate_initrd(void)
#endif /* CONFIG_BLK_DEV_INITRD */
-#ifdef CONFIG_BLK_DEV_INITRD
-
-static bool do_relocate_initrd = false;
-
-static void __init reserve_initrd(void)
-{
- unsigned long ramdisk_image = boot_params.hdr.ramdisk_image;
- unsigned long ramdisk_size = boot_params.hdr.ramdisk_size;
- unsigned long ramdisk_end = ramdisk_image + ramdisk_size;
- unsigned long end_of_lowmem = max_low_pfn PAGE_SHIFT;
- unsigned long ramdisk_here;
-
- if (ramdisk_end ramdisk_image) {
- printk(KERN_ERR initrd wraps around end of memory\n
- KERN_ERR disabling initrd\n);
- initrd_start = 0;
- return;
- }
- if (ramdisk_size = end_of_lowmem/2) {
- printk(KERN_ERR initrd too large to handle\n
- KERN_ERR disabling initrd\n);
- initrd_start = 0;
- return;
- }
- if (ramdisk_end = end_of_lowmem) {
- /* All in lowmem, easy case */
- reserve_bootmem(ramdisk_image, ramdisk_size);
- initrd_start = ramdisk_image + PAGE_OFFSET;
- initrd_end = initrd_start+ramdisk_size;
- return;
- }
-
- /* We need to move the initrd down into lowmem */
- ramdisk_here = (end_of_lowmem - ramdisk_size) PAGE_MASK;
-
- /* Note: this includes all the lowmem currently occupied by
- the initrd, we rely on that fact to keep the data intact. */
- reserve_bootmem(ramdisk_here, ramdisk_size);
- initrd_start = ramdisk_here + PAGE_OFFSET;
- initrd_end = initrd_start + ramdisk_size;
-
- do_relocate_initrd = true;
-}
-
-#define MAX_MAP_CHUNK (NR_FIX_BTMAPS PAGE_SHIFT)
-
-static void __init relocate_initrd(void)
-{
- unsigned long ramdisk_image = boot_params.hdr.ramdisk_image;
- unsigned long ramdisk_size = boot_params.hdr.ramdisk_size;
- unsigned long end_of_lowmem = max_low_pfn PAGE_SHIFT;
- unsigned long ramdisk_here;
- unsigned long slop, clen, mapaddr;
- char *p, *q;
-
- if (!do_relocate_initrd)
- return; /* Nothing to do here... */
-
- ramdisk_here = initrd_start - PAGE_OFFSET;
- q = (char *)initrd_start;
-
- /* Copy any lowmem portion of the initrd */
- if (ramdisk_image end_of_lowmem) {
- clen = end_of_lowmem - ramdisk_image;
- p = (char *)__va(ramdisk_image);
- memcpy(q, p, clen);
- q += clen;
- ramdisk_image += clen;
- ramdisk_size -= clen;
- }
-
- /* Copy the highmem portion of the initrd */
- while (ramdisk_size) {
- slop = ramdisk_image ~PAGE_MASK;
- clen = ramdisk_size;
- if (clen MAX_MAP_CHUNK-slop)
- clen = MAX_MAP_CHUNK-slop;
- mapaddr = ramdisk_image PAGE_MASK;
- p = bt_ioremap(mapaddr, clen+slop);
- memcpy(q, p+slop, clen);
Re: [PATCH -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, 7 Jan 2008, Dhaval Giani wrote: Hi Andrew, Ingo, Thomas, Peter, x86: revert i386: handle an initrd in highmem The patch caused a failure while booting a kexec kernel. (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) The following patch reverts it. Signed-off-by: Dhaval Giani [EMAIL PROTECTED] Thanks for tracking this down. I'll pull the patch from the x86 git tree as well. tglx -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
* Thomas Gleixner [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2008, Dhaval Giani wrote: Hi Andrew, Ingo, Thomas, Peter, x86: revert i386: handle an initrd in highmem The patch caused a failure while booting a kexec kernel. (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) The following patch reverts it. Signed-off-by: Dhaval Giani [EMAIL PROTECTED] Thanks for tracking this down. I'll pull the patch from the x86 git tree as well. Dhaval, how about the other problem you had - do you have any guess what it might be related to? i'm also wondering - what would be the easiest way to integrate kexec into an automated test environment. If i have a bzImage kernel, is kexec still supposed to work? Could i for example do a reboot into a new (kexec-enabled) kernel via kexec in essence? 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: [PATCH -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, Jan 07, 2008 at 03:56:09PM +0100, Ingo Molnar wrote: * Thomas Gleixner [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2008, Dhaval Giani wrote: Hi Andrew, Ingo, Thomas, Peter, x86: revert i386: handle an initrd in highmem The patch caused a failure while booting a kexec kernel. (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) The following patch reverts it. Signed-off-by: Dhaval Giani [EMAIL PROTECTED] Thanks for tracking this down. I'll pull the patch from the x86 git tree as well. Dhaval, how about the other problem you had - do you have any guess what it might be related to? other problem? The load_balance_monitor one? (We are still looking into that one, just seems that se (as usual :) ) is turning out to be null). i'm also wondering - what would be the easiest way to integrate kexec into an automated test environment. If i have a bzImage kernel, is kexec still supposed to work? Could i for example do a reboot into a new (kexec-enabled) kernel via kexec in essence? Yes, I use a bzImage kernel to reboot using kexec. I use a script which just sets it up for me. (I can send it to you separately). -- regards, Dhaval -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, 7 Jan 2008 15:56:09 +0100 Ingo Molnar wrote: * Thomas Gleixner [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2008, Dhaval Giani wrote: Hi Andrew, Ingo, Thomas, Peter, x86: revert i386: handle an initrd in highmem The patch caused a failure while booting a kexec kernel. (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) The following patch reverts it. Signed-off-by: Dhaval Giani [EMAIL PROTECTED] Thanks for tracking this down. I'll pull the patch from the x86 git tree as well. Dhaval, how about the other problem you had - do you have any guess what it might be related to? i'm also wondering - what would be the easiest way to integrate kexec into an automated test environment. If i have a bzImage kernel, is kexec still supposed to work? Could i for example do a reboot into a new (kexec-enabled) kernel via kexec in essence? My daily/nightly kernel test runs use kexec to boot the test kernel. Well, did thru 2.6.24-rc6-git9, but they fail after that. Hopefully this patch fixes things. --- ~Randy -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, Jan 07, 2008 at 08:22:37AM -0800, Randy Dunlap wrote: On Mon, 7 Jan 2008 15:56:09 +0100 Ingo Molnar wrote: * Thomas Gleixner [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2008, Dhaval Giani wrote: Hi Andrew, Ingo, Thomas, Peter, x86: revert i386: handle an initrd in highmem The patch caused a failure while booting a kexec kernel. (http://lkml.org/lkml/2008/1/7/42 has the bisect details.) The following patch reverts it. Signed-off-by: Dhaval Giani [EMAIL PROTECTED] Thanks for tracking this down. I'll pull the patch from the x86 git tree as well. Dhaval, how about the other problem you had - do you have any guess what it might be related to? i'm also wondering - what would be the easiest way to integrate kexec into an automated test environment. If i have a bzImage kernel, is kexec still supposed to work? Could i for example do a reboot into a new (kexec-enabled) kernel via kexec in essence? My daily/nightly kernel test runs use kexec to boot the test kernel. Well, did thru 2.6.24-rc6-git9, but they fail after that. Hopefully this patch fixes things. hmmm. I don't think so. This revert is from the x86 git tree (-mm) (I think targetted for 2.6.25). Probably a bisect might help there. -- regards, Dhaval -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, 7 Jan 2008, Randy Dunlap wrote: On Mon, 7 Jan 2008 15:56:09 +0100 Ingo Molnar wrote: i'm also wondering - what would be the easiest way to integrate kexec into an automated test environment. If i have a bzImage kernel, is kexec still supposed to work? Could i for example do a reboot into a new (kexec-enabled) kernel via kexec in essence? My daily/nightly kernel test runs use kexec to boot the test kernel. Well, did thru 2.6.24-rc6-git9, but they fail after that. Hopefully this patch fixes things. The patch in question is not in mainline, it's in the mm branch of x86.git. So the problem in mainline is a different one. Could you bisect it please ? Thanks, tglx -- 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.24-rc6-mm1] Build Failure on ppc64 with CONFIG_USB_GADGET not set.
On Mon, 7 Jan 2008 16:53:58 +0530 sudhir kumar [EMAIL PROTECTED] wrote: Hi Andrew! Kernel build fails on my ppc64 machine. It seems to be a dependency problem with CONFIG_USB_GADGET not set. Config file is attached. CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `oz99x_remove': drivers/i2c/chips/oz99x.c:660: undefined reference to `.led_classdev_unregister' drivers/built-in.o: In function `oz99x_configure_leds': drivers/i2c/chips/oz99x.c:314: undefined reference to `.led_classdev_register' make: *** [.tmp_vmlinux1] Error 1 Strange. oz99x-i2c-button-and-led-support-driver.patch has +config OZ99X + tristate O2 Micro/ETC OZ990/OZ992 SMBus chip + depends on I2C + select INPUT_POLLDEV + select LEDS_CLASS and your .config gives box:/usr/src/25 grep LEDS .config # CONFIG_NEW_LEDS is not set CONFIG_LEDS_CLASS=y so drivers/leds/led-class.o should be linked into your vmlinux. But that obviously isn't happening. -- 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.24-rc6-mm1] Build Failure on ppc64 with CONFIG_USB_GADGET not set.
On Mon, Jan 07, 2008 at 09:49:55AM -0800, Andrew Morton wrote: On Mon, 7 Jan 2008 16:53:58 +0530 sudhir kumar [EMAIL PROTECTED] wrote: Hi Andrew! Kernel build fails on my ppc64 machine. It seems to be a dependency problem with CONFIG_USB_GADGET not set. Config file is attached. CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `oz99x_remove': drivers/i2c/chips/oz99x.c:660: undefined reference to `.led_classdev_unregister' drivers/built-in.o: In function `oz99x_configure_leds': drivers/i2c/chips/oz99x.c:314: undefined reference to `.led_classdev_register' make: *** [.tmp_vmlinux1] Error 1 Strange. oz99x-i2c-button-and-led-support-driver.patch has +config OZ99X + tristate O2 Micro/ETC OZ990/OZ992 SMBus chip + depends on I2C + select INPUT_POLLDEV + select LEDS_CLASS and your .config gives box:/usr/src/25 grep LEDS .config # CONFIG_NEW_LEDS is not set CONFIG_LEDS_CLASS=y so drivers/leds/led-class.o should be linked into your vmlinux. But that obviously isn't happening. Because CONFIG_NEW_LEDS is not set we do not visit drivers/leds due to: obj-$(CONFIG_NEW_LEDS) += leds/ in drivers/Makefile This is evil select playing games (again). We have LEDS_CLASS equal y but NEW_LEDS equal n 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/
Re: [2.6.24-rc6-mm1] Build Failure on ppc64 with CONFIG_USB_GADGET not set.
On Mon, 7 Jan 2008 20:15:31 +0100 Sam Ravnborg [EMAIL PROTECTED] wrote: On Mon, Jan 07, 2008 at 09:49:55AM -0800, Andrew Morton wrote: On Mon, 7 Jan 2008 16:53:58 +0530 sudhir kumar [EMAIL PROTECTED] wrote: Hi Andrew! Kernel build fails on my ppc64 machine. It seems to be a dependency problem with CONFIG_USB_GADGET not set. Config file is attached. CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `oz99x_remove': drivers/i2c/chips/oz99x.c:660: undefined reference to `.led_classdev_unregister' drivers/built-in.o: In function `oz99x_configure_leds': drivers/i2c/chips/oz99x.c:314: undefined reference to `.led_classdev_register' make: *** [.tmp_vmlinux1] Error 1 Strange. oz99x-i2c-button-and-led-support-driver.patch has +config OZ99X + tristate O2 Micro/ETC OZ990/OZ992 SMBus chip + depends on I2C + select INPUT_POLLDEV + select LEDS_CLASS and your .config gives box:/usr/src/25 grep LEDS .config # CONFIG_NEW_LEDS is not set CONFIG_LEDS_CLASS=y so drivers/leds/led-class.o should be linked into your vmlinux. But that obviously isn't happening. Because CONFIG_NEW_LEDS is not set we do not visit drivers/leds due to: obj-$(CONFIG_NEW_LEDS) += leds/ in drivers/Makefile This is evil select playing games (again). We have LEDS_CLASS equal y but NEW_LEDS equal n Ah, OK, thanks. I'll switch oz99x-i2c-button-and-led-support-driver.patch over to using non-evil `depends on LEDS_CLASS'. -- 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.24-rc6-mm1] Build Failure on ppc64 with CONFIG_USB_GADGET not set.
Hi, Am Montag 07 Januar 2008 schrieb Andrew Morton: Sam Ravnborg [EMAIL PROTECTED] wrote: This is evil select playing games (again). We have LEDS_CLASS equal y but NEW_LEDS equal n Ah, OK, thanks. I'll switch oz99x-i2c-button-and-led-support-driver.patch over to using non-evil `depends on LEDS_CLASS'. If you wait a moment, I'll send you an updated patch that makes LED support optional in the driver. HS -- 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 -mm/x86] revert i386: handle an initrd in highmem (Was Re: 2.6.24-rc6-mm1)
On Mon, 7 Jan 2008 17:50:49 +0100 (CET) Thomas Gleixner wrote: On Mon, 7 Jan 2008, Randy Dunlap wrote: On Mon, 7 Jan 2008 15:56:09 +0100 Ingo Molnar wrote: i'm also wondering - what would be the easiest way to integrate kexec into an automated test environment. If i have a bzImage kernel, is kexec still supposed to work? Could i for example do a reboot into a new (kexec-enabled) kernel via kexec in essence? My daily/nightly kernel test runs use kexec to boot the test kernel. Well, did thru 2.6.24-rc6-git9, but they fail after that. Hopefully this patch fixes things. The patch in question is not in mainline, it's in the mm branch of x86.git. So the problem in mainline is a different one. Could you bisect it please ? Ugh. As happens during demos, this (kexec failure) won't happen for me when I want it to. I'll keep an eye out for it... --- ~Randy -- 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.24-rc6-mm1
On Sun, 6 Jan 2008 21:03:42 +0100
"Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Jan 6, 2008 2:33 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > On Sun, 6 Jan 2008 12:35:35 +0100
> > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > > On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > > > On Sun, 6 Jan 2008 11:41:10 +0100
> > > > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > > > > I will applie your patch and see if this hunk from
> > > > > find_next_zero_area() makes a difference:
> > > > >
> > > > >end = index + nr;
> > > > > - if (end > size)
> > > > > + if (end >= size)
> > > > > return -1;
>
> -> that might still have made a difference, but ...
>
> > > > > - for (i = index + 1; i < end; i++) {
> > > > > + for (i = index; i < end; i++) {
>
> ... as you say below, the test for the index position is only needed
> if index is modified after find_next_zero_bit().
>
> > > > > if (test_bit(i, map)) {
> > > >
> > > > The patch should not make a difference for X86_64.
> > >
> > > Hmm...
> > > arch/x86/kernel/pci-gart_64.c:
> > > alloc_iommu() calls iommu_area_alloc()
> > > lib/iommu-helper.c:
> > > iommu_area_alloc() calls find_next_zero_area()
> > > -> so the above code should be called even on X86_64
> >
> > Oops, I meant that the patch fixes the align allocation (non zero
> > align_mask case). X86_64 doesn't use the align allocation.
> >
> >
> > > And the change in the for loop means that 'index' will now be tested,
> > > but with the old code it was not.
> >
> > With the old code, 'index' is tested by find_next_zero_bit.
> >
> > With the new code and non zero align_mask case, 'index' is not tested
> > by find_next_zero_bit. So test_bit needs to start with 'index'.
> >
> > So If I understand the correctly, this patch should not make a
> > difference for x86_64 though I might miss something.
>
> You did not miss anything.
> After 18 packages my system crashed again.
>
> > > And double using something does fit with the errors I'm seeing...
> > >
> > > > Can you try the patch to revert my IOMMU changes?
> > > >
> > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12694.html
> > >
> > > Testing for this bug is a little bit slow, as I'm compiling ~100
> > > packages trying to trigger it.
> > > If my current testrun with the patch from
> > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html
> > > crashes, I will revert the hole IOMMU changes with above patch and try
> > > again.
> >
> > Thanks for testing,
>
> OK, I'm still testing this, but after 95 completed packages I'm rather
> certain that reverting the IOMMU changes with this patch fixes my
> problem.
> I didn't have time to look more into this, so I can't offer any
> concrete ideas where the bug is.
>
> If you send more patches, I'm willing to test them, but it might take
> some more time during the next week.
Can you try 2.6.24-rc7 + the IOMMU changes?
The patches are available at:
http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/
Or if you prefer the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git
iommu-sg-fixes
I've looked at the changes to GART but they are straightforward and
don't look wrong...
Thanks,
--
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.24-rc6-mm1: sparc64: undefined reference to `vmemmap_table'
From: Andrew Morton <[EMAIL PROTECTED]> Date: Sun, 6 Jan 2008 02:15:54 -0800 > On Sun, 6 Jan 2008 11:03:02 +0100 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote: > > > This is from allnoconfig on sparc64: > > > > LD .tmp_vmlinux1 > > arch/sparc64/kernel/head.o: In function `kvmap_vmemmap': > > (.text+0x34ec): undefined reference to `vmemmap_table' > > arch/sparc64/kernel/head.o: In function `kvmap_vmemmap': > > (.text+0x34f4): undefined reference to `vmemmap_table' > > Happens in mainline too. Maybe arch/sparc64/kernel/ktlb.S needs to be > taught about CONFIG_SPARSEMEM_VMEMMAP=n. It's pointless to support this thing being off. If possible I'd like a method to force it always to be enabled and I'll look into doing that. -- 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.24-rc6-mm1
On Jan 6, 2008 2:33 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jan 2008 12:35:35 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > > On Sun, 6 Jan 2008 11:41:10 +0100
> > > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > > > I will applie your patch and see if this hunk from
> > > > find_next_zero_area() makes a difference:
> > > >
> > > >end = index + nr;
> > > > - if (end > size)
> > > > + if (end >= size)
> > > > return -1;
-> that might still have made a difference, but ...
> > > > - for (i = index + 1; i < end; i++) {
> > > > + for (i = index; i < end; i++) {
... as you say below, the test for the index position is only needed
if index is modified after find_next_zero_bit().
> > > > if (test_bit(i, map)) {
> > >
> > > The patch should not make a difference for X86_64.
> >
> > Hmm...
> > arch/x86/kernel/pci-gart_64.c:
> > alloc_iommu() calls iommu_area_alloc()
> > lib/iommu-helper.c:
> > iommu_area_alloc() calls find_next_zero_area()
> > -> so the above code should be called even on X86_64
>
> Oops, I meant that the patch fixes the align allocation (non zero
> align_mask case). X86_64 doesn't use the align allocation.
>
>
> > And the change in the for loop means that 'index' will now be tested,
> > but with the old code it was not.
>
> With the old code, 'index' is tested by find_next_zero_bit.
>
> With the new code and non zero align_mask case, 'index' is not tested
> by find_next_zero_bit. So test_bit needs to start with 'index'.
>
> So If I understand the correctly, this patch should not make a
> difference for x86_64 though I might miss something.
You did not miss anything.
After 18 packages my system crashed again.
> > And double using something does fit with the errors I'm seeing...
> >
> > > Can you try the patch to revert my IOMMU changes?
> > >
> > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12694.html
> >
> > Testing for this bug is a little bit slow, as I'm compiling ~100
> > packages trying to trigger it.
> > If my current testrun with the patch from
> > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html
> > crashes, I will revert the hole IOMMU changes with above patch and try
> > again.
>
> Thanks for testing,
OK, I'm still testing this, but after 95 completed packages I'm rather
certain that reverting the IOMMU changes with this patch fixes my
problem.
I didn't have time to look more into this, so I can't offer any
concrete ideas where the bug is.
If you send more patches, I'm willing to test them, but it might take
some more time during the next week.
Thanks for looking into this.
Torsten
--
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.24-rc6-mm1
On Sun, Jan 06, 2008 at 11:30:48AM +0100, Torsten Kaiser wrote: ... > I think this bug is highly timing dependent. Its not always the same > package that dies and as this is a SMP system I would guess two CPUs > using the same data will trigger this. > And using the poison-option will definitily slow the system down and > mess up the timings. Of course it looks like using the same data, but it seems there is no reason to think it needs the same time: e.g. some timer or workqueue could retrigger after it's supposed to be killed. Any additional debugging/poisonning might help to see it earlier, so this should be safer for your system, but, most probably this would show data from the damaged side, so not necessarily very helpful. > What also speaks against the 'safer' offsets is, that after adding my > notfreed-byte to skbuff the bug still triggered in the same way. We are not even sure skbuffs were directly affected by this or they were incorrectly freed because of other structures beeing damaged? IMHO, e.g. starting your system with limited memory should cause faster memory reclaiming, and thus more often triggering of these bugs, but of course I can be wrong. Jarek P. -- 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.24-rc6-mm1
On Sun, 6 Jan 2008 12:35:35 +0100
"Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > On Sun, 6 Jan 2008 11:41:10 +0100
> > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > > I will applie your patch and see if this hunk from
> > > find_next_zero_area() makes a difference:
> > >
> > >end = index + nr;
> > > - if (end > size)
> > > + if (end >= size)
> > > return -1;
> > > - for (i = index + 1; i < end; i++) {
> > > + for (i = index; i < end; i++) {
> > > if (test_bit(i, map)) {
> >
> > The patch should not make a difference for X86_64.
>
> Hmm...
> arch/x86/kernel/pci-gart_64.c:
> alloc_iommu() calls iommu_area_alloc()
> lib/iommu-helper.c:
> iommu_area_alloc() calls find_next_zero_area()
> -> so the above code should be called even on X86_64
Oops, I meant that the patch fixes the align allocation (non zero
align_mask case). X86_64 doesn't use the align allocation.
> And the change in the for loop means that 'index' will now be tested,
> but with the old code it was not.
With the old code, 'index' is tested by find_next_zero_bit.
With the new code and non zero align_mask case, 'index' is not tested
by find_next_zero_bit. So test_bit needs to start with 'index'.
So If I understand the correctly, this patch should not make a
difference for x86_64 though I might miss something.
> And double using something does fit with the errors I'm seeing...
>
> > Can you try the patch to revert my IOMMU changes?
> >
> > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12694.html
>
> Testing for this bug is a little bit slow, as I'm compiling ~100
> packages trying to trigger it.
> If my current testrun with the patch from
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html
> crashes, I will revert the hole IOMMU changes with above patch and try again.
Thanks for testing,
--
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.24-rc6-mm1
On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jan 2008 11:41:10 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > I will applie your patch and see if this hunk from
> > find_next_zero_area() makes a difference:
> >
> >end = index + nr;
> > - if (end > size)
> > + if (end >= size)
> > return -1;
> > - for (i = index + 1; i < end; i++) {
> > + for (i = index; i < end; i++) {
> > if (test_bit(i, map)) {
>
> The patch should not make a difference for X86_64.
Hmm...
arch/x86/kernel/pci-gart_64.c:
alloc_iommu() calls iommu_area_alloc()
lib/iommu-helper.c:
iommu_area_alloc() calls find_next_zero_area()
-> so the above code should be called even on X86_64
And the change in the for loop means that 'index' will now be tested,
but with the old code it was not.
And double using something does fit with the errors I'm seeing...
> Can you try the patch to revert my IOMMU changes?
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg12694.html
Testing for this bug is a little bit slow, as I'm compiling ~100
packages trying to trigger it.
If my current testrun with the patch from
http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html
crashes, I will revert the hole IOMMU changes with above patch and try again.
Torsten
--
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.24-rc6-mm1
On Sun, 6 Jan 2008 11:41:10 +0100
"Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> On Jan 6, 2008 4:28 AM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > On Sat, 5 Jan 2008 17:25:24 -0800
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > > wrote:
> > > > But the cause of my mail is the following question:
> > > > Regarding my "iommu-sg-merging-patches are new in -rc3-mm and could be
> > > > the cause"-suspicion I looked at these patches and came across these
> > > > hunks:
> > > >
> > > > This is removed from arch/x86/lib/bitstr_64.c:
> > > > -/* Find string of zero bits in a bitmap */
> > > > -unsigned long
> > > > -find_next_zero_string(unsigned long *bitmap, long start, long nbits,
> > > > int len)
> > > > -{
> > > > - unsigned long n, end, i;
> > > > -
> > > > - again:
> > > > - n = find_next_zero_bit(bitmap, nbits, start);
> > > > - if (n == -1)
> > > > - return -1;
> > > > -
> > > > - /* could test bitsliced, but it's hardly worth it */
> > > > - end = n+len;
> > > > - if (end > nbits)
> > > > - return -1;
> > > > - for (i = n+1; i < end; i++) {
> > > > - if (test_bit(i, bitmap)) {
> > > > - start = i+1;
> > > > - goto again;
> > > > - }
> > > > - }
> > > > - return n;
> > > > -}
> > > >
> > > > This is added to lib/iommu-helper.c:
> > > > +static unsigned long find_next_zero_area(unsigned long *map,
> > > > +unsigned long size,
> > > > +unsigned long start,
> > > > +unsigned int nr)
> > > > +{
> > > > + unsigned long index, end, i;
> > > > +again:
> > > > + index = find_next_zero_bit(map, size, start);
> > > > + end = index + nr;
> > > > + if (end > size)
> > > > + return -1;
> > > > + for (i = index + 1; i < end; i++) {
> > > > + if (test_bit(i, map)) {
> > > > + start = i+1;
> > > > + goto again;
> > > > + }
> > > > + }
> > > > + return index;
> > > > +}
> > > >
> > > > The old version checks, if find_next_zero_bit returns -1, the new
> > > > version doesn't do this.
> > > > Is this intended and can find_next_zero_bit never fail?
> > > > Hmm... but in the worst case it should only loop forever if I'm
> > > > reading this right (index = -1 => for-loop counts from 0 to nr, if any
> > > > bit is set it will jump to "again:" and if the next call to
> > > > find_next_zero_bit also fails, its an endless loop)
> >
> > find_next_zero_bit returns -1?
> >
> > It seems that x86_64 doesn't.
>
> I'm sorry. I didn't look into find_next_zero_bit, I only noted that
> the old version did check for -1 and the new one didn't.
> Obviously the old check was superfluous.
>
> > POWER and SPARC64 IOMMUs use
> > find_next_zero_bit too but both doesn't check if find_next_zero_bit
> > returns -1. If find_next_zero_bit fails, it returns size. So it
> > doesn't leads to an endless loop.
>
> Yes, this can't happen. It was a wrong assumption on my part.
>
> > But this patch has other bugs that break POWER IOMMUs.
> >
> > If you use the IOMMUs on POWER, please try the following patch:
>
> I'm using CONFIG_GART_IOMMU=y on x86_64.
>
> > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html
>
> I also noted the line "index = (index + align_mask) & ~align_mask;" in
> iommu_area_alloc() and didn't understand what this was trying to do
> and how this should work, but as arch/x86/kernel/pci-gart_64.c always
> uses 0 as align_mask I just ignored it.
Yeah, it's for only POWER IOMMUs. It's meaningless for gart and
calgary IOMMUs.
> I will applie your patch and see if this hunk from
> find_next_zero_area() makes a difference:
>
>end = index + nr;
> - if (end > size)
> + if (end >= size)
> return -1;
> - for (i = index + 1; i < end; i++) {
> + for (i = index; i < end; i++) {
> if (test_bit(i, map)) {
The patch should not make a difference for X86_64.
Can you try the patch to revert my IOMMU changes?
http://www.mail-archive.com/[EMAIL PROTECTED]/msg12694.html
--
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.24-rc6-mm1
On Jan 6, 2008 4:28 AM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sat, 5 Jan 2008 17:25:24 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > wrote:
> > > But the cause of my mail is the following question:
> > > Regarding my "iommu-sg-merging-patches are new in -rc3-mm and could be
> > > the cause"-suspicion I looked at these patches and came across these
> > > hunks:
> > >
> > > This is removed from arch/x86/lib/bitstr_64.c:
> > > -/* Find string of zero bits in a bitmap */
> > > -unsigned long
> > > -find_next_zero_string(unsigned long *bitmap, long start, long nbits, int
> > > len)
> > > -{
> > > - unsigned long n, end, i;
> > > -
> > > - again:
> > > - n = find_next_zero_bit(bitmap, nbits, start);
> > > - if (n == -1)
> > > - return -1;
> > > -
> > > - /* could test bitsliced, but it's hardly worth it */
> > > - end = n+len;
> > > - if (end > nbits)
> > > - return -1;
> > > - for (i = n+1; i < end; i++) {
> > > - if (test_bit(i, bitmap)) {
> > > - start = i+1;
> > > - goto again;
> > > - }
> > > - }
> > > - return n;
> > > -}
> > >
> > > This is added to lib/iommu-helper.c:
> > > +static unsigned long find_next_zero_area(unsigned long *map,
> > > +unsigned long size,
> > > +unsigned long start,
> > > +unsigned int nr)
> > > +{
> > > + unsigned long index, end, i;
> > > +again:
> > > + index = find_next_zero_bit(map, size, start);
> > > + end = index + nr;
> > > + if (end > size)
> > > + return -1;
> > > + for (i = index + 1; i < end; i++) {
> > > + if (test_bit(i, map)) {
> > > + start = i+1;
> > > + goto again;
> > > + }
> > > + }
> > > + return index;
> > > +}
> > >
> > > The old version checks, if find_next_zero_bit returns -1, the new
> > > version doesn't do this.
> > > Is this intended and can find_next_zero_bit never fail?
> > > Hmm... but in the worst case it should only loop forever if I'm
> > > reading this right (index = -1 => for-loop counts from 0 to nr, if any
> > > bit is set it will jump to "again:" and if the next call to
> > > find_next_zero_bit also fails, its an endless loop)
>
> find_next_zero_bit returns -1?
>
> It seems that x86_64 doesn't.
I'm sorry. I didn't look into find_next_zero_bit, I only noted that
the old version did check for -1 and the new one didn't.
Obviously the old check was superfluous.
> POWER and SPARC64 IOMMUs use
> find_next_zero_bit too but both doesn't check if find_next_zero_bit
> returns -1. If find_next_zero_bit fails, it returns size. So it
> doesn't leads to an endless loop.
Yes, this can't happen. It was a wrong assumption on my part.
> But this patch has other bugs that break POWER IOMMUs.
>
> If you use the IOMMUs on POWER, please try the following patch:
I'm using CONFIG_GART_IOMMU=y on x86_64.
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html
I also noted the line "index = (index + align_mask) & ~align_mask;" in
iommu_area_alloc() and didn't understand what this was trying to do
and how this should work, but as arch/x86/kernel/pci-gart_64.c always
uses 0 as align_mask I just ignored it.
I will applie your patch and see if this hunk from
find_next_zero_area() makes a difference:
end = index + nr;
- if (end > size)
+ if (end >= size)
return -1;
- for (i = index + 1; i < end; i++) {
+ for (i = index; i < end; i++) {
if (test_bit(i, map)) {
Torsten
--
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.24-rc6-mm1
On Jan 6, 2008 9:27 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote: > On Sat, Jan 05, 2008 at 03:52:32PM +0100, Torsten Kaiser wrote: > ... > > So my personal conclusion would be, that someone is writing to memory > > that he no longer owns. Most probably 0-bytes. (the complete_routine > > got NULLed and the warning about dst->__refcnt being 0). > > > > Use-after-free or something else? > > I agree: your conclusion seems to be the most probable explanation for > this. Then it could be really hard to solve this without bisection or > something similar. But there is some probabability this something could > try kfree later too, but simply this list debugging triggers earlier. As for example in the case when it dies in ieee1394-thread the list is so corrupted that it will die anyway. But I might try this anyway, as I don't really have a better idee. > > > > If you think some other slub_debug might catch it, I would try this... > > You can try to add "U" to these other slub_debug options. As a matter > of fact, if your above diagnose is right, it seems you risk to damage > your system or even the box with these tests, so if you want to > continue, you should probably turn any possible debugging on (not in > mm only). I did not add U, because I thought that would only needed to trace memory leaks. And I hoped that using P (poison) would catch any later use (after free). > BTW, you've written that some debugging options seem to delay the bug. > Since they often change sizes of some structures than such wrong > writes could have some 'safer' offsets. So, this could really delay > e.g. these list's bugs, but maybe this could also let to stay 'alive' > to such wrong kfree? I think this bug is highly timing dependent. Its not always the same package that dies and as this is a SMP system I would guess two CPUs using the same data will trigger this. And using the poison-option will definitily slow the system down and mess up the timings. What also speaks against the 'safer' offsets is, that after adding my notfreed-byte to skbuff the bug still triggered in the same way. I'm currently looking at http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html ,trying to understand if this is relevant for me on x86_64. Torsten -- 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/
