3.4.58-stable review
Subsystems (15)
Greg Kroah-Hartman
maintainercover 3.4.58-stable review
This is the start of the stable review cycle for the 3.4.58 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Aug 15 06:34:52 UTC 2013. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.58-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.4.58-rc1
Joshua Zhu <[email protected]>
perf tools: Add anonymous huge page recognition
NeilBrown <[email protected]>
vfs: d_obtain_alias() needs to use "/" as default name.
Arnd Bergmann <[email protected]>
SCSI: nsp32: use mdelay instead of large udelay constants
Andrew Vagin <[email protected]>
tracing: Fix fields of struct trace_iterator that are zeroed by mistake
Oleg Nesterov <[email protected]>
debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)
Julius Werner <[email protected]>
usb: core: don't try to reset_device() a port that got just disconnected
Chen Gang <[email protected]>
cifs: extend the buffer length enought for sprintf() using
Piotr Sarna <[email protected]>
ext4: fix mount/remount error messages for incompatible mount options
Amit Shah <[email protected]>
virtio: console: return -ENODEV on all read operations after unplug
Amit Shah <[email protected]>
virtio: console: fix raising SIGIO after port unplug
Amit Shah <[email protected]>
virtio: console: clean up port data immediately at time of unplug
Amit Shah <[email protected]>
virtio: console: fix race in port_fops_open() and port unplug
Amit Shah <[email protected]>
virtio: console: fix race with port unplug and open/close
Curt Brune <[email protected]>
hwmon: (adt7470) Fix incorrect return code check
Theodore Ts'o <[email protected]>
ext4: make sure group number is bumped after a inode allocation race
[email protected] <[email protected]>
SCSI: megaraid_sas: megaraid_sas driver init fails in kdump kernel
Martin K. Petersen <[email protected]>
SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set
-------------
Diffstat:
Makefile | 4 +- drivers/char/virtio_console.c | 47 ++++++++++++--------- drivers/hwmon/adt7470.c | 2 +- drivers/scsi/megaraid/megaraid_sas_base.c | 20 ++++++--- drivers/scsi/nsp32.c | 2 +- drivers/scsi/scsi.c | 3 ++ drivers/usb/core/hub.c | 5 ++- fs/cifs/cifsencrypt.c | 2 +- fs/cifs/cifsglob.h | 1 + fs/cifs/connect.c | 7 ++-- fs/cifs/sess.c | 6 +-- fs/dcache.c | 2 +- fs/debugfs/inode.c | 69 ++++++++++--------------------- fs/ext4/ialloc.c | 10 ++--- fs/ext4/super.c | 17 +++++++- include/linux/ftrace_event.h | 4 +- kernel/trace/trace.c | 1 + tools/perf/util/map.c | 3 +- 18 files changed, 112 insertions(+), 93 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/17 SCSI: Dont attempt to send extended INQUIRY command if skip_vpd_pages is set
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Martin K. Petersen" <[email protected]>
commit 7562523e84ddc742fe1f9db8bd76b01acca89f6b upstream.
If a device has the skip_vpd_pages flag set we should simply fail the scsi_get_vpd_page() call.
--- drivers/scsi/scsi.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/scsi/scsi.c +3 -0
@@ -1025,6 +1025,9 @@ int scsi_get_vpd_page(struct scsi_device {int i, result; +if (sdev->skip_vpd_pages) + goto fail; +/* Ask for all the pages supported by this device */ result =scsi_vpd_inquiry (sdev, buf,0 , buf_len);if (result)
Greg Kroah-Hartman
maintainerPATCH 2/17 SCSI: megaraid_sas: megaraid_sas driver init fails in kdump kernel
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "[email protected]" <[email protected]>
commit 6431f5d7c6025f8b007af06ea090de308f7e6881 upstream.
Problem: When Hardware IOMMU is on, megaraid_sas driver initialization fails in kdump kernel with LSI MegaRAID controller(device id-0x73).
Actually this issue needs fix in firmware, but for firmware running in field, this driver fix is proposed to resolve the issue. At firmware initialization time, if firmware does not come to ready state, driver will reset the adapter and retry for firmware transition to ready state unconditionally(not only executed for kdump kernel).
--- drivers/scsi/megaraid/megaraid_sas_base.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-)
drivers/scsi/megaraid/megaraid_sas_base.c +15 -5
@@ -3493,11 +3493,21 @@ static int megasas_init_fw(struct megasabreak ; } -/* -* We expect the FW state to be READY -*/ -if (megasas_transition_to_ready (instance,0 )) - goto fail_ready_state; +if (megasas_transition_to_ready (instance,0 )) { +atomic_set (&instance->fw_reset_no_pci_access,1 ); + instance->instancet->adp_reset + (instance, instance->reg_set); +atomic_set (&instance->fw_reset_no_pci_access,0 ); +dev_info (&instance->pdev->dev, +"megasas: FW restarted successfully from %s!\n" , + __func__); + +/*waitting for about 30 second before retry*/ +ssleep (30 ); + +if (megasas_transition_to_ready (instance,0 )) + goto fail_ready_state; + }/* Check if MSI-X is supported while in ready state */ msix_enable = (instance->instancet->read_fw_status_reg(reg_set) &
Greg Kroah-Hartman
maintainerPATCH 3/17 ext4: make sure group number is bumped after a inode allocation race
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit a34eb503742fd25155fd6cff6163daacead9fbc3 upstream.
When we try to allocate an inode, and there is a race between two CPU's trying to grab the same inode, _and_ this inode is the last free inode in the block group, make sure the group number is bumped before we continue searching the rest of the block groups. Otherwise, we end up searching the current block group twice, and we end up skipping searching the last block group. So in the unlikely situation where almost all of the inodes are allocated, it's possible that we will return ENOSPC even though there might be free inodes in that last block group.
--- fs/ext4/ialloc.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
fs/ext4/ialloc.c +5 -5
@@ -687,11 +687,8 @@ repeat_in_this_group: ino =ext4_find_next_zero_bit ((unsigned long *) inode_bitmap_bh->b_data,EXT4_INODES_PER_GROUP (sb), ino); -if (ino >=EXT4_INODES_PER_GROUP (sb)) { -if (++group == ngroups) - group =0 ; -continue ; - } +if (ino >=EXT4_INODES_PER_GROUP (sb)) + goto next_group;if (group ==0 && (ino+1 ) <EXT4_FIRST_INO (sb)) {ext4_error (sb,"reserved inode found cleared - " "inode=%lu" , ino +1 );
@@ -709,6 +706,9 @@ repeat_in_this_group: goto got;/* we grabbed the inode! */ if (ino <EXT4_INODES_PER_GROUP (sb)) goto repeat_in_this_group; +next_group: +if (++group == ngroups) + group =0 ; } err = -ENOSPC ; goto out;
Greg Kroah-Hartman
maintainerPATCH 4/17 hwmon: (adt7470) Fix incorrect return code check
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Curt Brune <[email protected]>
commit 93d783bcca69bfacc8dc739d8a050498402587b5 upstream.
In adt7470_write_word_data(), which writes two bytes using i2c_smbus_write_byte_data(), the return codes are incorrectly AND-ed together when they should be OR-ed together.
The return code of i2c_smbus_write_byte_data() is zero for success.
The upshot is only the first byte was ever written to the hardware. The 2nd byte was never written out.
I noticed that trying to set the fan speed limits was not working correctly on my system. Setting the fan speed limits is the only code that uses adt7470_write_word_data(). After making the change the limit settings work and the alarms work also.
--- drivers/hwmon/adt7470.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/hwmon/adt7470.c +1 -1
@@ -215,7 +215,7 @@ static inline int adt7470_write_word_dat u16 value) {return i2c_smbus_write_byte_data (client, reg, value &0xFF ) - &&i2c_smbus_write_byte_data (client, reg +1 , value >>8 ); + ||i2c_smbus_write_byte_data (client, reg +1 , value >>8 ); }static void adt7470_init_client (struct i2c_client *client)
Greg Kroah-Hartman
maintainerPATCH 5/17 virtio: console: fix race with port unplug and open/close
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amit Shah <[email protected]>
commit 057b82be3ca3d066478e43b162fc082930a746c9 upstream.
There's a window between find_port_by_devt() returning a port and us taking a kref on the port, where the port could get unplugged. Fix it by taking the reference in find_port_by_devt() itself.
Problem reported and analyzed by Mateusz Guzik.
--- drivers/char/virtio_console.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)
drivers/char/virtio_console.c +6 -7
@@ -256,9 +256,12 @@ static struct port *find_port_by_devt_inunsigned long flags;spin_lock_irqsave (&portdev->ports_lock, flags); -list_for_each_entry (port, &portdev->ports, list) -if (port->cdev->dev == dev) +list_for_each_entry (port, &portdev->ports, list) { +if (port->cdev->dev == dev) { +kref_get (&port->kref); goto out; + } + } port =NULL ; out:spin_unlock_irqrestore (&portdev->ports_lock, flags);
@@ -789,14 +792,10 @@ static int port_fops_open(struct inode *struct port *port;int ret; +/* We get the port with a kref here */ port =find_port_by_devt (cdev->dev); filp->private_data = port; -/* Prevent against a port getting hot-unplugged at the same time */ -spin_lock_irq (&port->portdev->ports_lock); -kref_get (&port->kref); -spin_unlock_irq (&port->portdev->ports_lock); -/* * Don't allow opening of console port devices -- that's done * via /dev/hvc
Greg Kroah-Hartman
maintainerPATCH 6/17 virtio: console: fix race in port_fops_open() and port unplug
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amit Shah <[email protected]>
commit 671bdea2b9f210566610603ecbb6584c8a201c8c upstream.
Between open() being called and processed, the port can be unplugged. Check if this happened, and bail out.
A simple test script to reproduce this is:
while true; do for i in $(seq 1 100); do echo $i > /dev/vport0p3; done; done;
This opens and closes the port a lot of times; unplugging the port while this is happening triggers the bug.
--- drivers/char/virtio_console.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/char/virtio_console.c +4 -0
@@ -794,6 +794,10 @@ static int port_fops_open(struct inode */* We get the port with a kref here */ port =find_port_by_devt (cdev->dev); +if (!port) { +/* Port was unplugged before we could proceed */ +return -ENXIO ; + } filp->private_data = port;/*
Greg Kroah-Hartman
maintainerPATCH 7/17 virtio: console: clean up port data immediately at time of unplug
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amit Shah <[email protected]>
commit ea3768b4386a8d1790f4cc9a35de4f55b92d6442 upstream.
We used to keep the port's char device structs and the /sys entries around till the last reference to the port was dropped. This is actually unnecessary, and resulted in buggy behaviour:
1. Open port in guest
2. Hot-unplug port
3. Hot-plug a port with the same 'name' property as the unplugged one
This resulted in hot-plug being unsuccessful, as a port with the same name already exists (even though it was unplugged).
This behaviour resulted in a warning message like this one:
-------------------8<---------------------------------------
WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted) Hardware name: KVM
sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1'
Call Trace: [<ffffffff8106b607>] ? warn_slowpath_common+0x87/0xc0 [<ffffffff8106b6f6>] ? warn_slowpath_fmt+0x46/0x50 [<ffffffff811f2319>] ? sysfs_add_one+0xc9/0x130 [<ffffffff811f23e8>] ? create_dir+0x68/0xb0 [<ffffffff811f2469>] ? sysfs_create_dir+0x39/0x50 [<ffffffff81273129>] ? kobject_add_internal+0xb9/0x260 [<ffffffff812733d8>] ? kobject_add_varg+0x38/0x60 [<ffffffff812734b4>] ? kobject_add+0x44/0x70 [<ffffffff81349de4>] ? get_device_parent+0xf4/0x1d0 [<ffffffff8134b389>] ? device_add+0xc9/0x650
-------------------8<---------------------------------------
Instead of relying on guest applications to release all references to the ports, we should go ahead and unregister the port from all the core layers. Any open/read calls on the port will then just return errors, and an unplug/plug operation on the host will succeed as expected.
This also caused buggy behaviour in case of the device removal (not just a port): when the device was removed (which means all ports on that device are removed automatically as well), the ports with active users would clean up only when the last references were dropped -- and it would be too late then to be referencing char device pointers, resulting in oopses:
-------------------8<---------------------------------------
PID: 6162 TASK: ffff8801147ad500 CPU: 0 COMMAND: "cat"
#0 [ffff88011b9d5a90] machine_kexec at ffffffff8103232b #1 [ffff88011b9d5af0] crash_kexec at ffffffff810b9322 #2 [ffff88011b9d5bc0] oops_end at ffffffff814f4a50
#3 [ffff88011b9d5bf0] die at ffffffff8100f26b
#4 [ffff88011b9d5c20] do_general_protection at ffffffff814f45e2 #5 [ffff88011b9d5c50] general_protection at ffffffff814f3db5
[exception RIP: strlen+2]
RIP: ffffffff81272ae2 RSP: ffff88011b9d5d00 RFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880118901c18 RCX: 0000000000000000
RDX: ffff88011799982c RSI: 00000000000000d0 RDI: 3a303030302f3030
RBP: ffff88011b9d5d38 R8: 0000000000000006 R9: ffffffffa0134500
R10: 0000000000001000 R11: 0000000000001000 R12: ffff880117a1cc10
R13: 00000000000000d0 R14: 0000000000000017 R15: ffffffff81aff700
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #6 [ffff88011b9d5d00] kobject_get_path at ffffffff8126dc5d #7 [ffff88011b9d5d40] kobject_uevent_env at ffffffff8126e551 #8 [ffff88011b9d5dd0] kobject_uevent at ffffffff8126e9eb #9 [ffff88011b9d5de0] device_del at ffffffff813440c7
-------------------8<---------------------------------------
So clean up when we have all the context, and all that's left to do when the references to the port have dropped is to free up the port struct itself.
--- drivers/char/virtio_console.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
drivers/char/virtio_console.c +8 -8
@@ -1257,14 +1257,6 @@ static void remove_port(struct kref *kre port = container_of(kref, struct port, kref); -sysfs_remove_group (&port->dev->kobj, &port_attribute_group); -device_destroy (pdrvdata.class, port->dev->devt); -cdev_del (port->cdev); - -kfree (port->name); - -debugfs_remove (port->debugfs_file); -kfree (port); }
@@ -1318,6 +1310,14 @@ static void unplug_port(struct port *por*/ port->portdev =NULL ; +sysfs_remove_group (&port->dev->kobj, &port_attribute_group); +device_destroy (pdrvdata.class, port->dev->devt); +cdev_del (port->cdev); + +kfree (port->name); + +debugfs_remove (port->debugfs_file); +/* * Locks around here are not necessary - a port can't be * opened after we removed the port struct from ports_list
Greg Kroah-Hartman
maintainerPATCH 8/17 virtio: console: fix raising SIGIO after port unplug
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amit Shah <[email protected]>
commit 92d3453815fbe74d539c86b60dab39ecdf01bb99 upstream.
SIGIO should be sent when a port gets unplugged. It should only be sent to prcesses that have the port opened, and have asked for SIGIO to be delivered. We were clearing out guest_connected before calling send_sigio_to_port(), resulting in a sigio not getting sent to processes.
Fix by setting guest_connected to false after invoking the sigio function.
--- drivers/char/virtio_console.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/char/virtio_console.c +5 -3
@@ -1286,12 +1286,14 @@ static void unplug_port(struct port *porspin_unlock_irq (&port->portdev->ports_lock);if (port->guest_connected) { +/* Let the app know the port is going down. */ +send_sigio_to_port (port); + +/* Do this after sigio is actually sent */ port->guest_connected = false; port->host_connected = false; -wake_up_interruptible (&port->waitqueue); -/* Let the app know the port is going down. */ -send_sigio_to_port (port); +wake_up_interruptible (&port->waitqueue); }if (is_console_port (port)) {
Greg Kroah-Hartman
maintainerPATCH 9/17 virtio: console: return -ENODEV on all read operations after unplug
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amit Shah <[email protected]>
commit 96f97a83910cdb9d89d127c5ee523f8fc040a804 upstream.
If a port gets unplugged while a user is blocked on read(), -ENODEV is returned. However, subsequent read()s returned 0, indicating there's no host-side connection (but not indicating the device went away).
This also happened when a port was unplugged and the user didn't have any blocking operation pending. If the user didn't monitor the SIGIO signal, they won't have a chance to find out if the port went away.
Fix by returning -ENODEV on all read()s after the port gets unplugged. write() already behaves this way.
--- drivers/char/virtio_console.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/char/virtio_console.c +5 -1
@@ -633,6 +633,10 @@ static ssize_t port_fops_read(struct fil port = filp->private_data; +/* Port is hot-unplugged. */ +if (!port->guest_connected) +return -ENODEV ; +if (!port_has_data (port)) {/* * If nothing's connected on the host just return 0 in
@@ -649,7 +653,7 @@ static ssize_t port_fops_read(struct filif (ret <0 )return ret; } -/* Port got hot-unplugged. */ +/* Port got hot-unplugged while we were waiting above. */ if (!port->guest_connected)return -ENODEV ;/*
Greg Kroah-Hartman
maintainerPATCH 10/17 ext4: fix mount/remount error messages for incompatible mount options
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Piotr Sarna <[email protected]>
commit 6ae6514b33f941d3386da0dfbe2942766eab1577 upstream.
Commit 5688978 ("ext4: improve handling of conflicting mount options") introduced incorrect messages shown while choosing wrong mount options.
First of all, both cases of incorrect mount options, "data=journal,delalloc" and "data=journal,dioread_nolock" result in the same error message.
Secondly, the problem above isn't solved for remount option: the mismatched parameter is simply ignored. Moreover, ext4_msg states that remount with options "data=journal,delalloc" succeeded, which is not true.
To fix it up, I added a simple check after parse_options() call to ensure that data=journal and delalloc/dioread_nolock parameters are not present at the same time.
--- fs/ext4/super.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
fs/ext4/super.c +16 -1
@@ -3232,7 +3232,7 @@ static int ext4_fill_super(struct super_ }if (test_opt (sb,DIOREAD_NOLOCK )) {ext4_msg (sb,KERN_ERR ,"can't mount with " -"both data=journal and delalloc" ); +"both data=journal and dioread_nolock" ); goto failed_mount; }if (test_opt (sb,DELALLOC ))
@@ -4397,6 +4397,21 @@ static int ext4_remount(struct super_blo goto restore_opts; } +if (test_opt (sb,DATA_FLAGS ) ==EXT4_MOUNT_JOURNAL_DATA ) { +if (test_opt2 (sb,EXPLICIT_DELALLOC )) { +ext4_msg (sb,KERN_ERR ,"can't mount with " +"both data=journal and delalloc" ); + err = -EINVAL ; + goto restore_opts; + } +if (test_opt (sb,DIOREAD_NOLOCK )) { +ext4_msg (sb,KERN_ERR ,"can't mount with " +"both data=journal and dioread_nolock" ); + err = -EINVAL ; + goto restore_opts; + } + } +if (sbi->s_mount_flags &EXT4_MF_FS_ABORTED )ext4_abort (sb,"Abort forced by user" );
Greg Kroah-Hartman
maintainerPATCH 11/17 cifs: extend the buffer length enought for sprintf() using
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Gang <[email protected]>
commit 057d6332b24a4497c55a761c83c823eed9e3f23b upstream.
For cifs_set_cifscreds() in "fs/cifs/connect.c", 'desc' buffer length is 'CIFSCREDS_DESC_SIZE' (56 is less than 256), and 'ses->domainName' length may be "255 + '\0'".
The related sprintf() may cause memory overflow, so need extend related buffer enough to hold all things.
It is also necessary to be sure of 'ses->domainName' must be less than 256, and define the related macro instead of hard code number '256'.
--- fs/cifs/cifsencrypt.c | 2 +- fs/cifs/cifsglob.h | 1 + fs/cifs/connect.c | 7 ++++--- fs/cifs/sess.c | 6 +++--- 4 files changed, 9 insertions(+), 7 deletions(-)
fs/cifs/cifsencrypt.c +1 -1
@@ -369,7 +369,7 @@ find_domain_name(struct cifs_ses *ses, cif (blobptr + attrsize > blobend)break ;if (type ==NTLMSSP_AV_NB_DOMAIN_NAME ) { -if (!attrsize) +if (!attrsize || attrsize >=CIFS_MAX_DOMAINNAME_LEN )break ;if (!ses->domainName) { ses->domainName =
fs/cifs/cifsglob.h +1 -0
@@ -38,6 +38,7 @@#define MAX_TREE_SIZE (2 + MAX_SERVER_SIZE + 1 + MAX_SHARE_SIZE + 1)#define MAX_SERVER_SIZE 15#define MAX_SHARE_SIZE 80 +#define CIFS_MAX_DOMAINNAME_LEN 256/* max domain name length */ #define MAX_USERNAME_SIZE 256/* reasonable maximum for current servers */ #define MAX_PASSWORD_SIZE 512/* max for windows seems to be 256 wide chars */
fs/cifs/connect.c +4 -3
@@ -1698,7 +1698,8 @@ cifs_parse_mount_options(const char *mouif (string ==NULL ) goto out_nomem; -if (strnlen (string,256 ) ==256 ) { +if (strnlen (string,CIFS_MAX_DOMAINNAME_LEN ) + ==CIFS_MAX_DOMAINNAME_LEN ) {printk (KERN_WARNING "CIFS: domain name too" " long\n" ); goto cifs_parse_mount_err;
@@ -2356,8 +2357,8 @@ cifs_put_smb_ses(struct cifs_ses *ses)#ifdef CONFIG_KEYS -/* strlen("cifs:a:") + INET6_ADDRSTRLEN + 1 */ -#define CIFSCREDS_DESC_SIZE (7 + INET6_ADDRSTRLEN + 1) +/* strlen("cifs:a:") + CIFS_MAX_DOMAINNAME_LEN + 1 */ +#define CIFSCREDS_DESC_SIZE (7 + CIFS_MAX_DOMAINNAME_LEN + 1)/* Populate username and pw fields from keyring if possible */ static int
fs/cifs/sess.c +3 -3
@@ -198,7 +198,7 @@ static void unicode_domain_string(char * bytes_ret =0 ; }else bytes_ret =cifs_strtoUTF16 ((__le16 *) bcc_ptr, ses->domainName, -256 , nls_cp); +CIFS_MAX_DOMAINNAME_LEN , nls_cp); bcc_ptr +=2 * bytes_ret; bcc_ptr +=2 ;/* account for null terminator */
@@ -256,8 +256,8 @@ static void ascii_ssetup_strings(char **/* copy domain */ if (ses->domainName !=NULL ) { -strncpy (bcc_ptr, ses->domainName,256 ); - bcc_ptr +=strnlen (ses->domainName,256 ); +strncpy (bcc_ptr, ses->domainName,CIFS_MAX_DOMAINNAME_LEN ); + bcc_ptr +=strnlen (ses->domainName,CIFS_MAX_DOMAINNAME_LEN ); }/* else we will send a null domain name so the server will default to its own domain */ *bcc_ptr =0 ;
Greg Kroah-Hartman
maintainerPATCH 12/17 usb: core: dont try to reset_device() a port that got just disconnected
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julius Werner <[email protected]>
commit 481f2d4f89f87a0baa26147f323380e31cfa7c44 upstream.
The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() function based on whether there was a device attached to the port.
However, there are device/hub combinations (found with a JetFlash Transcend mass storage stick (8564:1000) on the root hub of an Intel LynxPoint PCH) which can transition to the SS.Inactive state on disconnect (and stay there long enough for the host to notice). In this case, above-mentioned reset check will call usb_reset_device() on the stale device data structure. The kernel will send pointless LPM control messages to the no longer connected device address and can even cause several 5 second khubd stalls on some (buggy?) host controllers, before finally accepting the device's fate amongst a flurry of error messages.
This patch makes the choice of reset dependent on the port status that has just been read from the hub in addition to the existence of an in-kernel data structure for the device, and only proceeds with the more extensive reset if both are valid.
--- drivers/usb/core/hub.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/usb/core/hub.c +3 -2
@@ -3890,7 +3890,8 @@ static void hub_events(void) hub->hdev->children[i -1 ];dev_dbg (hub_dev,"warm reset port %d\n" , i); -if (!udev) { +if (!udev || !(portstatus & +USB_PORT_STAT_CONNECTION )) { status =hub_port_reset (hub, i,NULL ,HUB_BH_RESET_TIME , true);
@@ -3900,8 +3901,8 @@ static void hub_events(void)usb_lock_device (udev); status =usb_reset_device (udev);usb_unlock_device (udev); + connect_change =0 ; } - connect_change =0 ; }if (connect_change)
Greg Kroah-Hartman
maintainerPATCH 13/17 debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs)
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <[email protected]>
commit 776164c1faac4966ab14418bb0922e1820da1d19 upstream.
debugfs_remove_recursive() is wrong,
1. it wrongly assumes that !list_empty(d_subdirs) means that this dir should be removed.
This is not that bad by itself, but:
2. if d_subdirs does not becomes empty after __debugfs_remove() it gives up and silently fails, it doesn't even try to remove other entries.
However ->d_subdirs can be non-empty because it still has the already deleted !debugfs_positive() entries.
3. simple_release_fs() is called even if __debugfs_remove() fails.
Suppose we have
dir1/ dir2/ file2 file1
and someone opens dir1/dir2/file2.
Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes away.
But debugfs_remove_recursive(dir1) silently fails and doesn't remove this directory. Because it tries to delete (the already deleted) dir1/dir2/file2 again and then fails due to "Avoid infinite loop" logic.
Test-case:
#!/bin/sh
cd /sys/kernel/debug/tracing
echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events sleep 1000 < events/probe/sigprocmask/id & echo -n >| kprobe_events
[ -d events/probe ] && echo "ERR!! failed to rm probe"
And after that it is not possible to create another probe entry.
With this patch debugfs_remove_recursive() skips !debugfs_positive() files although this is not strictly needed. The most important change is that it does not try to make ->d_subdirs empty, it simply scans the whole list(s) recursively and removes as much as possible.
--- fs/debugfs/inode.c | 69 ++++++++++++++++------------------------------------- 1 file changed, 22 insertions(+), 47 deletions(-)
fs/debugfs/inode.c +22 -47
@@ -527,8 +527,7 @@ EXPORT_SYMBOL_GPL(debugfs_remove);*/ void debugfs_remove_recursive (struct dentry *dentry) { -struct dentry *child; -struct dentry *parent; +struct dentry *child, *next, *parent;if (!dentry)return ;
@@ -538,61 +537,37 @@ void debugfs_remove_recursive(struct denreturn ; parent = dentry; + down:mutex_lock (&parent->d_inode->i_mutex); +list_for_each_entry_safe (child, next, &parent->d_subdirs, d_u.d_child) { +if (!debugfs_positive (child)) +continue ; -while (1 ) { -/* -* When all dentries under "parent" has been removed, -* walk up the tree until we reach our starting point. -*/ -if (list_empty (&parent->d_subdirs)) { -mutex_unlock (&parent->d_inode->i_mutex); -if (parent == dentry) -break ; - parent = parent->d_parent; -mutex_lock (&parent->d_inode->i_mutex); - } - child = list_entry(parent->d_subdirs.next, struct dentry, - d_u.d_child); - next_sibling: - -/* -* If "child" isn't empty, walk down the tree and -* remove all its descendants first. -*/ +/* perhaps simple_empty(child) makes more sense */ if (!list_empty (&child->d_subdirs)) {mutex_unlock (&parent->d_inode->i_mutex); parent = child; -mutex_lock (&parent->d_inode->i_mutex); -continue ; + goto down; } -__debugfs_remove (child, parent); -if (parent->d_subdirs.next == &child->d_u.d_child) { -/* -* Try the next sibling. -*/ -if (child->d_u.d_child.next != &parent->d_subdirs) { - child =list_entry (child->d_u.d_child.next, - struct dentry, - d_u.d_child); - goto next_sibling; - } - -/* -* Avoid infinite loop if we fail to remove -* one dentry. -*/ -mutex_unlock (&parent->d_inode->i_mutex); -break ; - } -simple_release_fs (&debugfs_mount, &debugfs_mount_count); + up: +if (!__debugfs_remove (child, parent)) +simple_release_fs (&debugfs_mount, &debugfs_mount_count); } - parent = dentry->d_parent; +mutex_unlock (&parent->d_inode->i_mutex); + child = parent; + parent = parent->d_parent;mutex_lock (&parent->d_inode->i_mutex); -__debugfs_remove (dentry, parent); + +if (child != dentry) { + next = list_entry(child->d_u.d_child.next, struct dentry, + d_u.d_child); + goto up; + } + +if (!__debugfs_remove (child, parent)) +simple_release_fs (&debugfs_mount, &debugfs_mount_count);mutex_unlock (&parent->d_inode->i_mutex); -simple_release_fs (&debugfs_mount, &debugfs_mount_count); }EXPORT_SYMBOL_GPL (debugfs_remove_recursive);
Greg Kroah-Hartman
maintainerPATCH 14/17 tracing: Fix fields of struct trace_iterator that are zeroed by mistake
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Vagin <[email protected]>
commit ed5467da0e369e65b247b99eb6403cb79172bcda upstream.
tracing_read_pipe zeros all fields bellow "seq". The declaration contains a comment about that, but it doesn't help.
The first field is "snapshot", it's true when current open file is snapshot. Looks obvious, that it should not be zeroed.
The second field is "started". It was converted from cpumask_t to cpumask_var_t (v2.6.28-4983-g4462344), in other words it was converted from cpumask to pointer on cpumask.
Currently the reference on "started" memory is lost after the first read from tracing_read_pipe and a proper object will never be freed.
The "started" is never dereferenced for trace_pipe, because trace_pipe can't have the TRACE_FILE_ANNOTATE options.
--- include/linux/ftrace_event.h | 4 +++- kernel/trace/trace.c | 1 + 2 files changed, 4 insertions(+), 1 deletion(-)
include/linux/ftrace_event.h +3 -1
@@ -71,6 +71,8 @@ struct trace_iterator {/* trace_seq for __print_flags() and __print_symbolic() etc. */ struct trace_seq tmp_seq; +cpumask_var_t started; +/* The below is zeroed out in pipe_read */ struct trace_seq seq;struct trace_entry *ent;
@@ -83,7 +85,7 @@ struct trace_iterator {loff_t pos;long idx; -cpumask_var_t started; +/* All new field here will be zeroed out in pipe_read */ };
kernel/trace/trace.c +1 -0
@@ -3478,6 +3478,7 @@ waitagain:memset (&iter->seq,0 ,sizeof (struct trace_iterator ) - offsetof(struct trace_iterator , seq)); +cpumask_clear (iter->started); iter->pos =-1 ;trace_event_read_lock ();
Greg Kroah-Hartman
maintainerPATCH 15/17 SCSI: nsp32: use mdelay instead of large udelay constants
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit b497ceb964a80ebada3b9b3cea4261409039e25a upstream.
ARM cannot handle udelay for more than 2 miliseconds, so we should use mdelay instead for those.
--- drivers/scsi/nsp32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/nsp32.c +1 -1
@@ -2926,7 +2926,7 @@ static void nsp32_do_bus_reset(nsp32_hw_* reset SCSI bus */ nsp32_write1 (base,SCSI_BUS_CONTROL ,BUSCTL_RST ); -udelay (RESET_HOLD_TIME ); +mdelay (RESET_HOLD_TIME /1000 );nsp32_write1 (base,SCSI_BUS_CONTROL ,0 );for (i =0 ; i <5 ; i++) { intrdat =nsp32_read2 (base,IRQ_STATUS );/* dummy read */
Greg Kroah-Hartman
maintainerPATCH 16/17 vfs: d_obtain_alias() needs to use "/" as default name.
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit b911a6bdeef5848c468597d040e3407e0aee04ce upstream.
NFS appears to use d_obtain_alias() to create the root dentry rather than d_make_root. This can cause 'prepend_path()' to complain that the root has a weird name if an NFS filesystem is lazily unmounted. e.g. if "/mnt" is an NFS mount then
{ cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; }
will cause a WARN message like
WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0() ... Root dentry has weird name <>
to appear in kernel logs.
So change d_obtain_alias() to use "/" rather than "" as the anonymous name.
--- fs/dcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/dcache.c +1 -1
@@ -1556,7 +1556,7 @@ EXPORT_SYMBOL(d_find_any_alias);*/ struct dentry *d_obtain_alias (struct inode *inode) { -static const struct qstr anonstring = { .name ="" }; +static const struct qstr anonstring = { .name ="/" , .len =1 };struct dentry *tmp;struct dentry *res;
Greg Kroah-Hartman
maintainerPATCH 17/17 perf tools: Add anonymous huge page recognition
In reply to Greg Kroah-Hartman3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joshua Zhu <[email protected]>
commit d0528b5d71faf612014dd7672e44225c915344b2 upstream.
Judging anonymous memory's vm_area_struct, perf_mmap_event's filename will be set to "//anon" indicating this vma belongs to anonymous memory.
Once hugepage is used, vma's vm_file points to hugetlbfs. In this way, this vma will not be regarded as anonymous memory by is_anon_memory() in perf user space utility.
--- tools/perf/util/map.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
tools/perf/util/map.c +2 -1
@@ -15,7 +15,8 @@ const char *map_type__name[MAP__NR_TYPESstatic inline int is_anon_memory (const char *filename) { -return strcmp (filename,"//anon" ) ==0 ; +return !strcmp (filename,"//anon" ) || + !strcmp (filename,"/anon_hugepage (deleted)" ); }static inline int is_no_dso_memory (const char *filename)
Guenter Roeck
maintainerQuoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.58 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 7 lines
Responses should be made by Thu Aug 15 06:34:52 UTC 2013. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.58-rc1.gzand the diffstat can be found below.
Cross build results:
Total builds: 62 Total build errors: 10
qemu:
mips, ppc, x86, x86_64 pass (boot to login prompt)
Details:
http://server.roeck-us.net:8010/waterfall
Everything as expected.
Guenter
Greg Kroah-Hartman
maintainerQuoted 9 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.58 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Aug 15 06:34:52 UTC 2013. Anything received after that time might be too late.
Quoted 6 lines
Quoted 4 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.58-rc1.gzand the diffstat can be found below.
Cross build results:
Total builds: 62 Total build errors: 10
As I'm sticking with 3.4 for another year, should I work to fix those build errors?
Quoted 5 lines
qemu:
mips, ppc, x86,x86_64pass (boot to login prompt)Details:
http://server.roeck-us.net:8010/waterfall
I tried to find the build errors here, but can't seem to see them. What should I be looking for?
thanks,
greg k-h
Guenter Roeck
maintainerQuoted 20 lines · Greg Kroah-Hartman
Quoted 9 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.58 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Aug 15 06:34:52 UTC 2013. Anything received after that time might be too late.
Quoted 6 lines
Quoted 4 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.58-rc1.gzand the diffstat can be found below.
Cross build results:
Total builds: 62 Total build errors: 10As I'm sticking with 3.4 for another year, should I work to fix those build errors?
Quoted 9 lines
Quoted 5 lines
qemu:
mips, ppc, x86,x86_64pass (boot to login prompt)Details:
http://server.roeck-us.net:8010/waterfallI tried to find the build errors here, but can't seem to see them. What should I be looking for?
You won't. System isn't set up for it yet, sorry. I keep the logs in /tmp on the build servers for the time being, so you'd need a login ;).
I copied the individual log files for the 3.4 build to http://roeck-us.net/linux/logs
in case you want to browse through it.
Here is a summary.
mips/allmodconfig:drivers/net/ethernet/3com/3c59x.c: In function 'vortex_init_one':drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of function 'pci_iomap'
We have seen that before in 3.10. Commit 78857614104 (MIPS: Expose missing pci_io{map,unmap} declarations) fixes it.
sound/oss/soundcard.c:69:31: error: 'MAX_DMA_CHANNELS' undeclared here (not in a function)
This requiresd4702b189c sound: Fix make allmodconfig on MIPS a62ee234a5 sound: Fix make allmodconfig on MIPS correctly
Unfortunately, after applying those patches the build still fails with
ERROR: "min_low_pfn" [drivers/net/wireless/ath/ath6kl/ath6kl_sdio.ko] undefined!
This has been fixed upstream with commit 8b9232141b (MIPS: Rewrite pfn_valid to work in modules, too), which applies but results in build failures. There is a patch from Ben Hutchings which removes the use of virt_addr_valid() (which causes the problem) from the ath6kl driver, but that is not in mainline.
powerpc/chroma_defconfig:arch/powerpc/mm/numa.c: In function 'do_init_bootmem':arch/powerpc/mm/numa.c:529:19: error: 'aa.arrays' may be used uninitialized in this function [-Werror=maybe-uninitialized] arch/powerpc/mm/numa.c:642:22: note: 'aa.arrays' was declared here
cc1: all warnings being treated as errors
No idea. Code looks all different in 3.10.
arm/allmodconfig:
Error in configuration file after "make allmodconfig". It suggests to run "make oldconfig" to update it. I tried that, but it fails as well. Not sure if it is worth looking into it.
m68k/allmodconfig:drivers/hid/hid-microsoft.c: In function 'ms_report_fixup':drivers/hid/hid-microsoft.c:52:18: error: macro "memcmp" passed 6 arguments, but takes just 3 drivers/hid/hid-microsoft.c:51:5: error: 'memcmp' undeclared (first use in this function) drivers/hid/hid-microsoft.c:51:5: note: each undeclared identifier is reported only once for each function it appears in
microblaze/mmu_defconfig:build/scripts/gen_initramfs_list.sh: Cannot open 'rootfs.cpio' make[1]: *** [usr/initramfs_data.cpio.gz] Error 1
make: *** [usr] Error 2
CONFIG_INITRAMFS_SOURCE=rootfs.cpio in the config file probably isn't such a good idea.
Upstream commit d0e045401f26 (microblaze: Update microblaze defconfigs) addresses this problem, but it can not be applied directly. It defines CONFIG_HIGHMEM=y, CONFIG_PCI=y, and CONFIG_PCI_XILINX=y, which do not build in 3.4. It builds successfully if I apply d0e045401f26 and remove those three definitions.
blackfin/defconfig:
ERROR: "vm_iomap_memory" [drivers/video/fb.ko] undefined! make[1]: *** [__modpost] Error 1
sh/defconfig:drivers/built-in.o: In function `fb_mmap':
fbmem.c:(.text+0x5e8): undefined reference to `vm_iomap_memory'
Both look similar and might be easy to fix if someone knows what is wrong.
cris/...:
In file included from include/linux/page-flags.h:8:0,
from kernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t' include/linux/types.h:29:1: error: unknown type name '__kernel_off_t' include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t' include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t' include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'
That one might be tricky (or simple if someone knows what is wrong).
Guenter
Quoted 7 lines · Guenter Roeck
powerpc/chroma_defconfig:
arch/powerpc/mm/numa.c: In function 'do_init_bootmem':arch/powerpc/mm/numa.c:529:19: error: 'aa.arrays' may be used uninitialized in this function [-Werror=maybe-uninitialized]arch/powerpc/mm/numa.c:642:22: note: 'aa.arrays' was declared here
cc1: all warnings being treated as errorsNo idea. Code looks all different in 3.10.
Never seen in my log collection from kissb, which doesn't build chroma_defconfig.
Quoted 5 lines
m68k/allmodconfig:
drivers/hid/hid-microsoft.c: In function 'ms_report_fixup':drivers/hid/hid-microsoft.c:52:18: error: macro "memcmp" passed 6 arguments, but takes just 3drivers/hid/hid-microsoft.c:51:5: error: 'memcmp' undeclared (first use in this function)drivers/hid/hid-microsoft.c:51:5: note: each undeclared identifier is reported only once for each function it appears in
Fixed in v3.7-rc6:
commit 6b90466cfec2a2fe027187d675d8d14217c12d82
Author: Jiri Slaby <[email protected]> Date: Mon Nov 12 10:16:09 2012 +0100
HID: microsoft: do not use compound literal - fix build
Quoted 9 lines
blackfin/defconfig:
ERROR: "vm_iomap_memory" [drivers/video/fb.ko] undefined! make[1]: *** [__modpost] Error 1sh/defconfig:
drivers/built-in.o: In function `fb_mmap':
fbmem.c:(.text+0x5e8): undefined reference to `vm_iomap_memory'Both look similar and might be easy to fix if someone knows what is wrong.
Fixed in v3.9:
commit 3c0b9de6d37a481673e81001c57ca0e410c72346
Author: Linus Torvalds <[email protected]> Date: Sat Apr 27 13:25:38 2013 -0700
vm: add no-mmu vm_iomap_memory() stub
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Fixed in v3.5-rc1:
commit 74f077d2a7651409c44bb323471f219a4b0d2aab
Author: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200
cris: posix_types.h, include asm-generic/posix_types.h
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Guenter Roeck
maintainerQuoted 18 lines · Geert Uytterhoeven
Quoted 7 lines · Guenter Roeck
powerpc/chroma_defconfig:
arch/powerpc/mm/numa.c: In function 'do_init_bootmem':arch/powerpc/mm/numa.c:529:19: error: 'aa.arrays' may be used uninitialized in this function [-Werror=maybe-uninitialized]arch/powerpc/mm/numa.c:642:22: note: 'aa.arrays' was declared here
cc1: all warnings being treated as errorsNo idea. Code looks all different in 3.10.
Never seen in my log collection from kissb, which doesn't build
chroma_defconfig.Quoted 5 lines
m68k/allmodconfig:
drivers/hid/hid-microsoft.c: In function 'ms_report_fixup':drivers/hid/hid-microsoft.c:52:18: error: macro "memcmp" passed 6 arguments, but takes just 3drivers/hid/hid-microsoft.c:51:5: error: 'memcmp' undeclared (first use in this function)drivers/hid/hid-microsoft.c:51:5: note: each undeclared identifier is reported only once for each function it appears in
Quoted 8 lines
Fixed in v3.7-rc6:
commit
6b90466cfec2a2fe027187d675d8d14217c12d82Author: Jiri Slaby <[email protected]> Date: Mon Nov 12 10:16:09 2012 +0100HID: microsoft: do not use compound literal - fix build
Confirmed. Patching this commit into 3.4 fixes the build for m68k/allmodconfig.
Quoted 10 lines
Quoted 9 lines
blackfin/defconfig:
ERROR: "vm_iomap_memory" [drivers/video/fb.ko] undefined! make[1]: *** [__modpost] Error 1sh/defconfig:
drivers/built-in.o: In function `fb_mmap':
fbmem.c:(.text+0x5e8): undefined reference to `vm_iomap_memory'Both look similar and might be easy to fix if someone knows what is wrong.
Quoted 8 lines
Fixed in v3.9:
commit
3c0b9de6d37a481673e81001c57ca0e410c72346Author: Linus Torvalds <[email protected]> Date: Sat Apr 27 13:25:38 2013 -0700vm: add no-mmu
vm_iomap_memory()stub
Confirmed. Patching this commit into 3.4 fixes the build for both blackbuid/defconfig and sh/defconfig.
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.h
It does fix above error, but then there is another error:
AS arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
AS arch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1
Guenter
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1
commit 7b91747d42a1012e3781dd09fa638d113809e3fd
Author: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200
cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Most of these have been purged years ago. This one silently lived on until commit 69349c2dc01c489eccaa4c472542c08e370c6d7e
"kconfig: fix IS_ENABLED to not require all options to be defined"
In the above, we use some macro trickery to create a conditional that is valid in CPP and in C usage. However that trickery doesn't sit well if you have the legacy "-traditional" flag enabled. You'll get:
AS arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:
include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[2]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
Everything builds fine w/o "-traditional" so simply drop it from this location as well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Guenter Roeck
maintainerQuoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1
Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1
This has been fixed with commit 473e162e (CRIS: Add _sdata to vmlinux.lds.S).
So, in summary, we have
473e162e CRIS: Add _sdata to vmlinux.lds.S69349c2d cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile 7b91747d cris: posix_types.h, include asm-generic/posix_types.h
With those three patches applied, cris targets build in 3.4.y.
Guenter
Greg Kroah-Hartman
maintainerQuoted 50 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).
Quoted 7 lines
So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.hWith those three patches applied, cris targets build in 3.4.y.
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
thanks,
greg k-h
Guenter Roeck
maintainerQuoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.h
Quoted 6 lines
Quoted 1 line
With those three patches applied, cris targets build in 3.4.y.
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
I am quite sure you do ;).
I updated my tree and started a build on 3.4. Let's see how it goes.
Guenter
Guenter Roeck
maintainerQuoted 49 lines · Greg Kroah-Hartman
Quoted 48 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1
Quoted 5 lines
Quoted 5 lines
This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S
473e162e also fixes the cris builds in 3.0, so it might make sense to apply it there as well, at least if 3.0 has some lifetime left.
Guenter
Greg Kroah-Hartman
maintainerQuoted 50 lines · Guenter Roeck
Quoted 49 lines · Greg Kroah-Hartman
Quoted 48 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S
473e162ealso fixes the cris builds in 3.0, so it might make sense to apply it there as well, at least if 3.0 has some lifetime left.
It's easy enough, I've queued it up now.
greg k-h
Guenter Roeck
maintainerQuoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.h
Quoted 6 lines
Quoted 1 line
With those three patches applied, cris targets build in 3.4.y.
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
frv build in 3.4 is fixed with
b9e892f frv: Use core allocator for task_struct 25d0c52 frv: Use correct size for task_struct allocation
25d0c52 must be applied first.
Guenter
Greg Kroah-Hartman
maintainerQuoted 65 lines · Guenter Roeck
Quoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.hQuoted 6 lines
Quoted 1 line
With those three patches applied, cris targets build in 3.4.y.
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
Quoted 6 lines
frv build in 3.4 is fixed with
b9e892f frv: Use core allocator for
task_struct25d0c52 frv: Use correct size fortask_structallocation25d0c52 must be applied first.
Where did you get those git ids from?
cce4517f33384c3794c759e206cc8e1bb6df146b is frv: Use correct size for task_struct allocation.
c6ae063aaf3786b9db7f19a90bf4ed8aaebb7f90 is frv: Use core allocator for task_struct.
I'll queue them up, but you might want to check your git tree...
thanks,
greg k-h
Guenter Roeck
maintainerQuoted 75 lines · Greg Kroah-Hartman
Quoted 65 lines · Guenter Roeck
Quoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.hQuoted 6 lines
Quoted 1 line
With those three patches applied, cris targets build in 3.4.y.
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
Quoted 6 lines
frv build in 3.4 is fixed with
b9e892f frv: Use core allocator for
task_struct25d0c52 frv: Use correct size fortask_structallocation25d0c52 must be applied first.
Where did you get those git ids from?
Quoted 8 lines
cce4517f33384c3794c759e206cc8e1bb6df146bis frv: Use correct size fortask_structallocation.
c6ae063aaf3786b9db7f19a90bf4ed8aaebb7f90is frv: Use core allocator fortask_struct.I'll queue them up, but you might want to check your git tree...
I screwed up - those are the IDs I got after cherry-picking the patches into my tree. Sorry for that.
Guenter
Guenter Roeck
maintainerQuoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.h
Quoted 6 lines
Quoted 1 line
With those three patches applied, cris targets build in 3.4.y.
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
Besides the now failing mips buids;
Building arm:allmodconfig ... failed
--------------
Error log:
.config:25:warning: symbol value '' invalid for PHYS_OFFSET
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** No rule to make target include/config/auto.conf', needed by include/config/kernel.release'. Stop.
That was "fixed" by a complete arm Kconfig overhaul. I don't think you want that in 3.4.
--------------
Building frv:defconfig ... failed
--------------
Error log:
[ ... ]kernel/fork.c: In function 'free_task':kernel/fork.c:174:2: error: implicit declaration of function 'free_task_struct' [-Werror=implicit-function-declaration] kernel/fork.c: In function 'dup_task_struct':kernel/fork.c:266:2: error: implicit declaration of function 'alloc_task_struct_node' [-Werror=implicit-function-declaration] kernel/fork.c:266:6: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
make[1]: *** [kernel/fork.o] Error 1
I already sent you a sha with a fix for that.
---------------
Building powerpc:chroma_defconfig ... failed
--------------
Error log:arch/powerpc/mm/numa.c: In function 'do_init_bootmem':arch/powerpc/mm/numa.c:529:19: error: 'aa.arrays' may be used uninitialized in this function [-Werror=maybe-uninitialized] arch/powerpc/mm/numa.c:642:22: note: 'aa.arrays' was declared here
cc1: all warnings being treated as errors
make[1]: *** [arch/powerpc/mm/numa.o] Error 1
make: *** [arch/powerpc/mm] Error 2
make: *** Waiting for unfinished jobs....
--------------
That's all. Assuming you revert the mips patch (MIPS: Rewrite pfn_valid to work in modules, too) and apply the frv patch, we are down to three build failures out of 64 builds. Not too bad.
I now see an occasional qemu runtime crash on the x86 target on 3.4. It doesn't happen all the time, so it is hard to determine if it is a new problem or an old one. I'll try to find out. The crash is seen during reboot in native_nmi_stop_other_cpus(), if that rings a bell with anyone.
Guenter
Greg Kroah-Hartman
maintainerQuoted 74 lines · Guenter Roeck
Quoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.hQuoted 6 lines
Quoted 1 line
With those three patches applied, cris targets build in 3.4.y.
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
Besides the now failing mips buids;
Building arm:allmodconfig ... failed
--------------
Error log:
.config:25:warning: symbol value '' invalid forPHYS_OFFSET
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** No rule to make targetinclude/config/auto.conf', needed byinclude/config/kernel.release'. Stop.
Quoted 3 lines
That was "fixed" by a complete arm
Kconfigoverhaul. I don't think you want that in 3.4.
--------------
Not a "complete" overhaul, no. But getting a default allmodconfig building for arm would be nice, if possible.
thanks,
greg k-h
Guenter Roeck
maintainerQuoted 75 lines · Greg Kroah-Hartman
Quoted 74 lines · Guenter Roeck
Quoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.hQuoted 6 lines
Quoted 1 line
With those three patches applied, cris targets build in 3.4.y.
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
Besides the now failing mips buids;
Building arm:allmodconfig ... failed
--------------
Error log:
.config:25:warning: symbol value '' invalid forPHYS_OFFSET
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** No rule to make targetinclude/config/auto.conf', needed byinclude/config/kernel.release'. Stop.
Quoted 7 lines
Quoted 3 lines
That was "fixed" by a complete arm
Kconfigoverhaul. I don't think you want that in 3.4.
--------------Not a "complete" overhaul, no. But getting a default allmodconfig building for arm would be nice, if possible.
I agree. I'll look into it a bit further.
Also, to keep you busy:
cd8d2331 alpha: makefile: don't enforce small data model for kernel builds
fixes the alpha defconfig build for 3.4.
Guenter
Greg Kroah-Hartman
maintainerQuoted 10 lines · Guenter Roeck
Quoted 7 lines · Greg Kroah-Hartman
Quoted 3 lines
That was "fixed" by a complete arm
Kconfigoverhaul. I don't think you want that in 3.4.
--------------Not a "complete" overhaul, no. But getting a default allmodconfig building for arm would be nice, if possible.
I agree. I'll look into it a bit further.
Thanks, much appreciated.
Quoted 5 lines
Also, to keep you busy:
cd8d2331alpha: makefile: don't enforce small data model for kernel buildsfixes the alpha defconfig build for 3.4.
Nice, now applied.
greg k-h
Guenter Roeck
maintainerQuoted 57 lines · Greg Kroah-Hartman
Quoted 56 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.h
Quoted 6 lines
Quoted 1 line
With those three patches applied, cris targets build in 3.4.y.
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
One more patch to apply to 3.4:
aa709f3bc powerpc/numa: Avoid stupid uninitialized warning from gcc
This fixes the powerpc:chroma_defconfig build.
Guenter
Greg Kroah-Hartman
maintainerQuoted 60 lines · Guenter Roeck
Quoted 59 lines · Greg Kroah-Hartman
Quoted 57 lines · Guenter Roeck
Quoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Quoted 6 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile
Great, thanks for tracking this down.
With both patches applied, we are almost there. Next error:
kernel/built-in.o: In function `core_kernel_data':
(.text+0x12e38): undefined reference to `_sdata'
make: *** [vmlinux] Error 1This has been fixed with commit
473e162e(CRIS: Add_sdatatovmlinux.lds.S).So, in summary, we have
473e162eCRIS: Add_sdatatovmlinux.lds.S69349c2dcris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile7b91747dcris:posix_types.h, includeasm-generic/posix_types.hWith those three patches applied, cris targets build in 3.4.y.
Quoted 7 lines
Quoted 4 lines
Wonderful, I've now applied all of these.
Anything else I'm missing for 3.4?
One more patch to apply to 3.4:
aa709f3bcpowerpc/numa: Avoid stupid uninitialized warning from gcc
Now applied, thanks.
greg k-h
Greg Kroah-Hartman
maintainerQuoted 32 lines · Geert Uytterhoeven
Quoted 21 lines · Guenter Roeck
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
Quoted 9 lines
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1
Quoted 3 lines
commit
7b91747d42a1012e3781dd09fa638d113809e3fdAuthor: Paul Gortmaker <[email protected]> Date: Wed Apr 18 21:58:43 2012 +0200
Thanks, now applied.
greg k-h
Quoted 41 lines · Guenter Roeck
Quoted 18 lines · Geert Uytterhoeven
Quoted 7 lines · Guenter Roeck
powerpc/chroma_defconfig:
arch/powerpc/mm/numa.c: In function 'do_init_bootmem':arch/powerpc/mm/numa.c:529:19: error: 'aa.arrays' may be used uninitialized in this function [-Werror=maybe-uninitialized]arch/powerpc/mm/numa.c:642:22: note: 'aa.arrays' was declared here
cc1: all warnings being treated as errorsNo idea. Code looks all different in 3.10.
Never seen in my log collection from kissb, which doesn't build
chroma_defconfig.Quoted 5 lines
m68k/allmodconfig:
drivers/hid/hid-microsoft.c: In function 'ms_report_fixup':drivers/hid/hid-microsoft.c:52:18: error: macro "memcmp" passed 6 arguments, but takes just 3drivers/hid/hid-microsoft.c:51:5: error: 'memcmp' undeclared (first use in this function)drivers/hid/hid-microsoft.c:51:5: note: each undeclared identifier is reported only once for each function it appears inQuoted 8 lines
Fixed in v3.7-rc6:
commit
6b90466cfec2a2fe027187d675d8d14217c12d82Author: Jiri Slaby <[email protected]> Date: Mon Nov 12 10:16:09 2012 +0100HID: microsoft: do not use compound literal - fix build
Confirmed. Patching this commit into 3.4 fixes the build for m68k/allmodconfig.
Quoted 12 lines
Quoted 9 lines
blackfin/defconfig:
ERROR: "vm_iomap_memory" [drivers/video/fb.ko] undefined! make[1]: *** [__modpost] Error 1sh/defconfig:
drivers/built-in.o: In function `fb_mmap':
fbmem.c:(.text+0x5e8): undefined reference to `vm_iomap_memory'Both look similar and might be easy to fix if someone knows what is wrong.
Fixed in v3.9:
Quoted 9 lines
Quoted 6 lines
commit
3c0b9de6d37a481673e81001c57ca0e410c72346Author: Linus Torvalds <[email protected]> Date: Sat Apr 27 13:25:38 2013 -0700vm: add no-mmu
vm_iomap_memory()stubConfirmed. Patching this commit into 3.4 fixes the build for both blackbuid/defconfig and sh/defconfig.
It looks like this one could be applied to the 3.5 kernel as well (all the others are already there). Thanks, I'll queue it for the next release.
Cheers,
Signature · 1 line
Luis
Quoted 36 lines
Quoted 11 lines
Quoted 10 lines
cris/...: In file included from
include/linux/page-flags.h:8:0, fromkernel/bounds.c:9:include/linux/types.h:25:1: error:
unknown type name '__kernel_ino_t'include/linux/types.h:29:1:
error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error:
unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 8 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.hIt does fix above error, but then there is another error:
AS
arch/cris/arch-v10/lib/checksum.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksum.o] Error 1
make[1]: *** Waiting for unfinished jobs....
ASarch/cris/arch-v10/lib/checksumcopy.o
In file included from <command-line>:4:0:/home/groeck/src/linux-stable/include/linux/kconfig.h:23:0: error: syntax error in macro parameter list make[1]: *** [arch/cris/arch-v10/lib/checksumcopy.o] Error 1Guenter
--
To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Greg Kroah-Hartman
maintainerQuoted 7 lines · Geert Uytterhoeven
Quoted 5 lines · Guenter Roeck
m68k/allmodconfig:
drivers/hid/hid-microsoft.c: In function 'ms_report_fixup':drivers/hid/hid-microsoft.c:52:18: error: macro "memcmp" passed 6 arguments, but takes just 3drivers/hid/hid-microsoft.c:51:5: error: 'memcmp' undeclared (first use in this function)drivers/hid/hid-microsoft.c:51:5: note: each undeclared identifier is reported only once for each function it appears in
Quoted 7 lines
Fixed in v3.7-rc6:
commit
6b90466cfec2a2fe027187d675d8d14217c12d82Author: Jiri Slaby <[email protected]> Date: Mon Nov 12 10:16:09 2012 +0100HID: microsoft: do not use compound literal - fix build
Now applied.
Quoted 10 lines
Quoted 9 lines
blackfin/defconfig:
ERROR: "vm_iomap_memory" [drivers/video/fb.ko] undefined! make[1]: *** [__modpost] Error 1sh/defconfig:
drivers/built-in.o: In function `fb_mmap':
fbmem.c:(.text+0x5e8): undefined reference to `vm_iomap_memory'Both look similar and might be easy to fix if someone knows what is wrong.
Quoted 7 lines
Fixed in v3.9:
commit
3c0b9de6d37a481673e81001c57ca0e410c72346Author: Linus Torvalds <[email protected]> Date: Sat Apr 27 13:25:38 2013 -0700vm: add no-mmu
vm_iomap_memory()stub
Now applied.
Quoted 11 lines
Quoted 10 lines
cris/...:
In file included frominclude/linux/page-flags.h:8:0,
fromkernel/bounds.c:9:include/linux/types.h:25:1: error: unknown type name '__kernel_ino_t'include/linux/types.h:29:1: error: unknown type name '__kernel_off_t'include/linux/types.h:30:1: error: unknown type name '__kernel_pid_t'include/linux/types.h:31:1: error: unknown type name '__kernel_daddr_t'include/linux/types.h:33:1: error: unknown type name '__kernel_suseconds_t'That one might be tricky (or simple if someone knows what is wrong).
Quoted 7 lines
Fixed in v3.5-rc1:
commit
74f077d2a7651409c44bb323471f219a4b0d2aabAuthor: Jiri Slaby <[email protected]> Date: Mon Apr 2 13:40:17 2012 +0200cris:
posix_types.h, includeasm-generic/posix_types.h
Now applied.
Thanks for digging these out.
greg k-h
Greg Kroah-Hartman
maintainerQuoted 11 lines · Guenter Roeck
I copied the individual log files for the 3.4 build to http://roeck-us.net/linux/logs
in case you want to browse through it.Here is a summary.
mips/allmodconfig:
drivers/net/ethernet/3com/3c59x.c: In function 'vortex_init_one':drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of function 'pci_iomap'We have seen that before in 3.10. Commit 78857614104 (MIPS: Expose missing pci_io{map,unmap} declarations) fixes it.
Now applied.
Quoted 5 lines
sound/oss/soundcard.c:69:31: error: 'MAX_DMA_CHANNELS' undeclared here (not in a function)This requires
d4702b189csound: Fix make allmodconfig on MIPSa62ee234a5sound: Fix make allmodconfig on MIPS correctly
Now applied.
Quoted 6 lines
Unfortunately, after applying those patches the build still fails with
ERROR: "
min_low_pfn" [drivers/net/wireless/ath/ath6kl/ath6kl_sdio.ko] undefined!This has been fixed upstream with commit
8b9232141b(MIPS: Rewritepfn_validto work in modules, too), which applies but results in build failures.
What failures? I've applied this now, as it makes sense.
Quoted 3 lines
There is a patch from Ben Hutchings which removes the use of
virt_addr_valid()(which causes the problem) from the ath6kl driver, but that is not in mainline.
Ok, I think I'll stop there for MIPS, that's a good start...
Quoted 5 lines
microblaze/mmu_defconfig:
build/scripts/gen_initramfs_list.sh: Cannot open 'rootfs.cpio' make[1]: *** [usr/initramfs_data.cpio.gz] Error 1
make: *** [usr] Error 2
Quoted 8 lines
CONFIG_INITRAMFS_SOURCE=rootfs.cpioin the config file probably isn't such a good idea.Upstream commit
d0e045401f26(microblaze: Update microblaze defconfigs) addresses this problem, but it can not be applied directly. It definesCONFIG_HIGHMEM=y,CONFIG_PCI=y, andCONFIG_PCI_XILINX=y, which do not build in 3.4. It builds successfully if I applyd0e045401f26and remove those three definitions.
I've now done that, thanks.
greg k-h
Guenter Roeck
maintainerQuoted 30 lines · Greg Kroah-Hartman
Quoted 11 lines · Guenter Roeck
I copied the individual log files for the 3.4 build to http://roeck-us.net/linux/logs
in case you want to browse through it.Here is a summary.
mips/allmodconfig:
drivers/net/ethernet/3com/3c59x.c: In function 'vortex_init_one':drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of function 'pci_iomap'We have seen that before in 3.10. Commit 78857614104 (MIPS: Expose missing pci_io{map,unmap} declarations) fixes it.
Now applied.
Quoted 5 lines
sound/oss/soundcard.c:69:31: error: 'MAX_DMA_CHANNELS' undeclared here (not in a function)This requires
d4702b189csound: Fix make allmodconfig on MIPSa62ee234a5sound: Fix make allmodconfig on MIPS correctlyNow applied.
Quoted 6 lines
Unfortunately, after applying those patches the build still fails with
ERROR: "
min_low_pfn" [drivers/net/wireless/ath/ath6kl/ath6kl_sdio.ko] undefined!This has been fixed upstream with commit
8b9232141b(MIPS: Rewritepfn_validto work in modules, too), which applies but results in build failures.
Quoted 8 lines
What failures? I've applied this now, as it makes sense.
Quoted 3 lines
There is a patch from Ben Hutchings which removes the use of
virt_addr_valid()(which causes the problem) from the ath6kl driver, but that is not in mainline.Ok, I think I'll stop there for MIPS, that's a good start...
I screwed up my stable repo clone again :(, so the full build will take a bit.
mips builds on on 3.4 with all patches applied now fail with:arch/mips/include/asm/page.h: Assembler messages:arch/mips/include/asm/page.h:178: Error: Unrecognized opcode static inline int pfn_valid(unsigned long pfn)' arch/mips/include/asm/page.h:179: Error: junk at end of line, first unrecognized character is {' arch/mips/include/asm/page.h:181: Error: Unrecognized opcode extern unsigned long max_mapnr' arch/mips/include/asm/page.h:183: Error: Unrecognized opcode return pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr' arch/mips/include/asm/page.h:184: Error: junk at end of line, first unrecognized character is `}'
This is the error I referred to above. Reverting above pfn rework patch fixes that problem, so you might want to remove that patch from the patch queue for now.
Guenter
Quoted 16 lines · Guenter Roeck
I screwed up my stable repo clone again :(, so the full build will take a bit.
mips builds on on 3.4 with all patches applied now fail with:
arch/mips/include/asm/page.h: Assembler messages:arch/mips/include/asm/page.h:178: Error: Unrecognized opcodestatic inline int pfn_valid(unsigned long pfn)' arch/mips/include/asm/page.h:179: Error: junk at end of line, first unrecognized character is{'arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern unsigned longmax_mapnr'arch/mips/include/asm/page.h:183: Error: Unrecognized opcodereturn pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr' arch/mips/include/asm/page.h:184: Error: junk at end of line, first unrecognized character is}'
Quoted 3 lines
This is the error I referred to above. Reverting above pfn rework patch fixes that problem,
so you might want to remove that patch from the patch queue for now.
Perhaps this one got applied too soon?
commit 730b8dfe016dd1e91f73d8d3e6724da91397171c
Author: Ralf Baechle <[email protected]> Date: Fri Dec 28 15:18:02 2012 +0100
MIPS: page.h: Remove now unnecessary #ifndef __ASSEMBLY__ wrapper.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Guenter Roeck
maintainerQuoted 21 lines · Geert Uytterhoeven
Quoted 16 lines · Guenter Roeck
I screwed up my stable repo clone again :(, so the full build will take a bit.
mips builds on on 3.4 with all patches applied now fail with:
arch/mips/include/asm/page.h: Assembler messages:arch/mips/include/asm/page.h:178: Error: Unrecognized opcodestatic inline int pfn_valid(unsigned long pfn)' arch/mips/include/asm/page.h:179: Error: junk at end of line, first unrecognized character is{'arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern unsigned longmax_mapnr'arch/mips/include/asm/page.h:183: Error: Unrecognized opcodereturn pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr' arch/mips/include/asm/page.h:184: Error: junk at end of line, first unrecognized character is}'Quoted 3 lines
This is the error I referred to above. Reverting above pfn rework patch fixes that problem,
so you might want to remove that patch from the patch queue for now.
Quoted 8 lines
Perhaps this one got applied too soon?
commit
730b8dfe016dd1e91f73d8d3e6724da91397171cAuthor: Ralf Baechle <[email protected]> Date: Fri Dec 28 15:18:02 2012 +0100MIPS:
page.h: Remove now unnecessary #ifndef__ASSEMBLY__wrapper.
I applied it on top of the other patches, but that did not help. On the contrary, I get even more errors. Must be something else, or it needs even more patches.
Guenter
Guenter Roeck
maintainerQuoted 23 lines · Geert Uytterhoeven
Quoted 16 lines · Guenter Roeck
I screwed up my stable repo clone again :(, so the full build will take a bit.
mips builds on on 3.4 with all patches applied now fail with:
arch/mips/include/asm/page.h: Assembler messages:arch/mips/include/asm/page.h:178: Error: Unrecognized opcodestatic inline int pfn_valid(unsigned long pfn)' arch/mips/include/asm/page.h:179: Error: junk at end of line, first unrecognized character is{'arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern unsigned longmax_mapnr'arch/mips/include/asm/page.h:183: Error: Unrecognized opcodereturn pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr' arch/mips/include/asm/page.h:184: Error: junk at end of line, first unrecognized character is}'Quoted 3 lines
This is the error I referred to above. Reverting above pfn rework patch fixes that problem,
so you might want to remove that patch from the patch queue for now.Perhaps this one got applied too soon?
Quoted 8 lines
commit
730b8dfe016dd1e91f73d8d3e6724da91397171cAuthor: Ralf Baechle <[email protected]> Date: Fri Dec 28 15:18:02 2012 +0100MIPS:
page.h: Remove now unnecessary #ifndef__ASSEMBLY__wrapper.Signed-off-by Ralf Baechle <[email protected]>
Actually, you are on the right track, only in the opposite direction. The problem is that commit 8b9232141b changed
#define pfn_valid ...
to
static inline pfn_valid()
in arch/mips/include/asm/page.h. In the 3.4 kernel the file _is_ still included from assembler code. This obviously doesn't work.
Fix would be to surround the new static inline function with #ifndef __ASSEMBLY__. With this change, "mips allmodconfig" compiles with the 3.4 kernel. It should be a safe change, since the static inline will never be used from assembler code.
Question is if that would be acceptable as back-port of 8b9232141b to 3.4. Greg, any comments ? If it is ok I can submit a back-port request with the modified patch to -stable. That would be one more build fixed, three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
Thanks,
Guenter
Greg Kroah-Hartman
maintainerQuoted 46 lines · Guenter Roeck
Quoted 23 lines · Geert Uytterhoeven
Quoted 16 lines · Guenter Roeck
I screwed up my stable repo clone again :(, so the full build will take a bit.
mips builds on on 3.4 with all patches applied now fail with:
arch/mips/include/asm/page.h: Assembler messages:arch/mips/include/asm/page.h:178: Error: Unrecognized opcodestatic inline int pfn_valid(unsigned long pfn)' arch/mips/include/asm/page.h:179: Error: junk at end of line, first unrecognized character is{'arch/mips/include/asm/page.h:181: Error: Unrecognized opcode `extern unsigned longmax_mapnr'arch/mips/include/asm/page.h:183: Error: Unrecognized opcodereturn pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr' arch/mips/include/asm/page.h:184: Error: junk at end of line, first unrecognized character is}'Quoted 3 lines
This is the error I referred to above. Reverting above pfn rework patch fixes that problem,
so you might want to remove that patch from the patch queue for now.Perhaps this one got applied too soon?
Quoted 8 lines
commit
730b8dfe016dd1e91f73d8d3e6724da91397171cAuthor: Ralf Baechle <[email protected]> Date: Fri Dec 28 15:18:02 2012 +0100MIPS:
page.h: Remove now unnecessary #ifndef__ASSEMBLY__wrapper.Signed-off-by Ralf Baechle <[email protected]>Actually, you are on the right track, only in the opposite direction. The problem is that commit
8b9232141bchanged#define pfn_valid ...to
static inlinepfn_valid()
inarch/mips/include/asm/page.h. In the 3.4 kernel the file _is_ still included from assembler code. This obviously doesn't work.Fix would be to surround the new static inline function with #ifndef
__ASSEMBLY__. With this change, "mips allmodconfig" compiles with the 3.4 kernel. It should be a safe change, since the static inline will never be used from assembler code.
Quoted 4 lines
Question is if that would be acceptable as back-port of
8b9232141bto 3.4. Greg, any comments ? If it is ok I can submit a back-port request with the modified patch to -stable. That would be one more build fixed, three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
That sounds reasonable to me, as it is a valid fix, and I do know of some MIPS people using 3.4 (although their versions all seem to be heavily patched, perhaps for issues like this, I don't really know...)
So, feel free to send such a backport on to me.
thanks,
greg k-h
Guenter Roeck
maintainerOn 08/15/2013 10:10 PM, Greg Kroah-Hartman wrote:
[ .. ]
Quoted 2 lines
Quoted 1 line
three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
Please add (in this order) the following patches to 3.4.
de36e66d5f sparc32: add ucmpdi274c7b28953 sparc32: Add ucmpdi2.o to obj-y instead of lib-y.
This fixes the sparc32:defconfig build error.
Thanks,
Guenter
Greg Kroah-Hartman
maintainerQuoted 6 lines · Guenter Roeck
On 08/15/2013 10:10 PM, Greg Kroah-Hartman wrote:
[ .. ]Quoted 2 lines
Quoted 1 line
three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
Quoted 6 lines
Please add (in this order) the following patches to 3.4.
de36e66d5fsparc32: add ucmpdi274c7b28953sparc32: Add ucmpdi2.o to obj-y instead of lib-y.This fixes the sparc32:defconfig build error.
Now applied, thanks.
greg k-h
Guenter Roeck
maintainerQuoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Guenter Roeck
On 08/15/2013 10:10 PM, Greg Kroah-Hartman wrote:
[ .. ]Quoted 2 lines
Quoted 1 line
three to go (arm:allmodconfig, sparc32:defconfig, and sparc64:allmodconfig).
Quoted 9 lines
Quoted 6 lines
Please add (in this order) the following patches to 3.4.
de36e66d5fsparc32: add ucmpdi274c7b28953sparc32: Add ucmpdi2.o to obj-y instead of lib-y.This fixes the sparc32:defconfig build error.
Now applied, thanks.
Down to three failures now, out of 69 builds.
Still failing:
arm:allmodconfig
sparc64:allmodconfig
xtensa:defconfig
None of those appear simple to fix.
In case someone wants to have a look, here is the latest log:
http://server.roeck-us.net:8010/builders/stable-queue-3.4/builds/45/steps/shell/logs/stdio
Guenter
Quoted 3 lines · Guenter Roeck
Still failing:
sparc64:allmodconfig/opt/buildbot/slave/stable-queue-3_4/build/usr/include/linux/types.h:27:1: error: unknown type name ‘__u16’
According to my log collection, this same error message was fixed in v3.3-rc2, but I couldn't easily find a matching commit.
But this is v3.4-stable, which is after v3.3-rc2, so it got reintroduced?
Quoted 2 lines
xtensa:defconfig
dev.c:(.text.unlikely+0x3): dangerous relocation: l32r: literal placed after use: .literal.unlikely
Fixed in v3.7-rc1:
commit f6a03a12ecdbe0dd80a55f6df3b7206c5a403a49
Author: Max Filippov <[email protected]> Date: Mon Sep 17 05:44:31 2012 +0400
xtensa: fix linker script transformation for .text.unlikely
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Guenter Roeck
maintainerQuoted 9 lines · Geert Uytterhoeven
Quoted 3 lines · Guenter Roeck
Still failing:
sparc64:allmodconfig/opt/buildbot/slave/stable-queue-3_4/build/usr/include/linux/types.h:27:1: error: unknown type name ‘__u16’According to my log collection, this same error message was fixed in v3.3-rc2, but I couldn't easily find a matching commit.
But this is v3.4-stable, which is after v3.3-rc2, so it got reintroduced?
It was fixed recently with
commit cbf1ef6b3345d2cc7e62407eec6a6f72a8b1346f
Author: Sam Ravnborg <[email protected]> Date: Sun Mar 31 07:01:47 2013 +0000
sparc: use asm-generic version of types.h
and
commit a2d34dd41212032c03e77bc30c2023725def841a
Author: Sam Ravnborg <[email protected]> Date: Sat Mar 30 11:44:22 2013 +0000
sparc: use generic headers
I tried to apply those patches, but it failed miserably due to the userspace/kernel header separation. Given that, I figured that it would be too invasive to fix, at least for me.
Quoted 11 lines
Quoted 2 lines
xtensa:defconfig
dev.c:(.text.unlikely+0x3): dangerous relocation: l32r: literal placed after use: .literal.unlikelyFixed in v3.7-rc1:
commit
f6a03a12ecdbe0dd80a55f6df3b7206c5a403a49Author: Max Filippov <[email protected]> Date: Mon Sep 17 05:44:31 2012 +0400xtensa: fix linker script transformation for .text.unlikely
Yes, that fixes this problem, except now we get another known error:
kernel/built-in.o:(.text+0x8c8): undefined reference to `_sdata'
which you had fixed with
commit 5e7b6ed8e9bf3c8e3bb579fd0aec64f6526f8c81
Author: Geert Uytterhoeven <[email protected]> Date: Wed Jun 20 12:52:58 2012 -0700
xtensa: replace xtensa-specific _f{data,text} by _s{data,text}After applying both patches to the 3.4-stable queue, xtensa:defconfig builds successfully.
Thanks,
Guenter
Greg Kroah-Hartman
maintainerQuoted 47 lines · Guenter Roeck
Quoted 9 lines · Geert Uytterhoeven
Quoted 3 lines · Guenter Roeck
Still failing:
sparc64:allmodconfig/opt/buildbot/slave/stable-queue-3_4/build/usr/include/linux/types.h:27:1: error: unknown type name ‘__u16’According to my log collection, this same error message was fixed in v3.3-rc2, but I couldn't easily find a matching commit.
But this is v3.4-stable, which is after v3.3-rc2, so it got reintroduced?It was fixed recently with
commit
cbf1ef6b3345d2cc7e62407eec6a6f72a8b1346fAuthor: Sam Ravnborg <[email protected]> Date: Sun Mar 31 07:01:47 2013 +0000sparc: use asm-generic version of
types.hand
commit
a2d34dd41212032c03e77bc30c2023725def841aAuthor: Sam Ravnborg <[email protected]> Date: Sat Mar 30 11:44:22 2013 +0000sparc: use generic headers
I tried to apply those patches, but it failed miserably due to the userspace/kernel header separation. Given that, I figured that it would be too invasive to fix, at least for me.
Quoted 11 lines
Quoted 2 lines
xtensa:defconfig
dev.c:(.text.unlikely+0x3): dangerous relocation: l32r: literal placed after use: .literal.unlikelyFixed in v3.7-rc1:
commit
f6a03a12ecdbe0dd80a55f6df3b7206c5a403a49Author: Max Filippov <[email protected]> Date: Mon Sep 17 05:44:31 2012 +0400xtensa: fix linker script transformation for .text.unlikely
Yes, that fixes this problem, except now we get another known error:
kernel/built-in.o:(.text+0x8c8): undefined reference to `_sdata'
which you had fixed with
Quoted 8 lines
commit
5e7b6ed8e9bf3c8e3bb579fd0aec64f6526f8c81Author: Geert Uytterhoeven <[email protected]> Date: Wed Jun 20 12:52:58 2012 -0700xtensa: replace xtensa-specific _f{data,text} by _s{data,text}After applying both patches to the 3.4-stable queue, xtensa:defconfig builds successfully.
Thanks, both now applied.
greg k-h
Greg Kroah-Hartman
maintainerQuoted 50 lines · Guenter Roeck
Quoted 30 lines · Greg Kroah-Hartman
Quoted 11 lines · Guenter Roeck
I copied the individual log files for the 3.4 build to http://roeck-us.net/linux/logs
in case you want to browse through it.Here is a summary.
mips/allmodconfig:
drivers/net/ethernet/3com/3c59x.c: In function 'vortex_init_one':drivers/net/ethernet/3com/3c59x.c:1031:2: error: implicit declaration of function 'pci_iomap'We have seen that before in 3.10. Commit 78857614104 (MIPS: Expose missing pci_io{map,unmap} declarations) fixes it.
Now applied.
Quoted 5 lines
sound/oss/soundcard.c:69:31: error: 'MAX_DMA_CHANNELS' undeclared here (not in a function)This requires
d4702b189csound: Fix make allmodconfig on MIPSa62ee234a5sound: Fix make allmodconfig on MIPS correctlyNow applied.
Quoted 6 lines
Unfortunately, after applying those patches the build still fails with
ERROR: "
min_low_pfn" [drivers/net/wireless/ath/ath6kl/ath6kl_sdio.ko] undefined!This has been fixed upstream with commit
8b9232141b(MIPS: Rewritepfn_validto work in modules, too), which applies but results in build failures.Quoted 8 lines
What failures? I've applied this now, as it makes sense.
Quoted 3 lines
There is a patch from Ben Hutchings which removes the use of
virt_addr_valid()(which causes the problem) from the ath6kl driver, but that is not in mainline.Ok, I think I'll stop there for MIPS, that's a good start...
I screwed up my stable repo clone again :(, so the full build will take a bit.
mips builds on on 3.4 with all patches applied now fail with:
arch/mips/include/asm/page.h: Assembler messages:arch/mips/include/asm/page.h:178: Error: Unrecognized opcodestatic inline int pfn_valid(unsigned long pfn)' arch/mips/include/asm/page.h:179: Error: junk at end of line, first unrecognized character is{'arch/mips/include/asm/page.h:181: Error: Unrecognized opcodeextern unsigned long max_mapnr' arch/mips/include/asm/page.h:183: Error: Unrecognized opcodereturn pfn>=ARCH_PFN_OFFSET&&pfn<max_mapnr'arch/mips/include/asm/page.h:184: Error: junk at end of line, first unrecognized character is `}'
Quoted 2 lines
This is the error I referred to above. Reverting above pfn rework patch fixes that problem, so you might want to remove that patch from the patch queue for now.
Ok, now removed, thanks.
greg k-h
Guenter Roeck
maintainerQuoted 20 lines · Greg Kroah-Hartman
Quoted 9 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.58 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Aug 15 06:34:52 UTC 2013. Anything received after that time might be too late.
Quoted 6 lines
Quoted 4 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.58-rc1.gzand the diffstat can be found below.
Cross build results:
Total builds: 62 Total build errors: 10As I'm sticking with 3.4 for another year, should I work to fix those build errors?
Quoted 9 lines
Quoted 5 lines
qemu:
mips, ppc, x86,x86_64pass (boot to login prompt)Details:
http://server.roeck-us.net:8010/waterfallI tried to find the build errors here, but can't seem to see them. What should I be looking for?
I changed the build script to display the logs for failed builds directly, and initiated a rebuild. If it works, the logs for all failed builds should be available on the build status page in about two hours.
Guenter
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 3.4.58 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Aug 15 06:34:52 UTC 2013. Anything received after that time might be too late.
Quoted 8 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.58-rc1.gzand the diffstat can be found below.
thanks,
greg k-h
Patches applied cleanly to 3.0.90, 3.4.57 and 3.10.6
Compiled and booted on the following systems:
Samsung Series 9 900X4C Intel Corei5:
(3.4.58-rc1, 3.10.7-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
(3.0.91-rc1, 3.4.58-rc1, and 3.10.7-rc1)dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. dmesg emerg, crit, alert, err are clean. No regressions in warn.
Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
(3.0.91-rc1, 3.4.58-rc1, and 3.10.7-rc1)
Cross-compile tests results:
alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.10.y
blackfin: defconfig passed on all
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.10.y
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all
-- Shuah
Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) [email protected] | (970) 672-0658