So the two week merge window has closed, and just as well - because we had a lot of changes. As usual. Certainly I had no urges to keep the window open to get those last remaining few megabytes of patches.. The changes follow roughly the same pattern they have before: one third crap (that is, "staging" - the new random drivers that aren't really ready to be merged properly but get into the tree in the hope that they'll get better some day), one third real drivers, and one third "rest". And just to not break a new tradition, there's a few new filesystems in this release too: - "nilfs2" has been brewing for a long while, and is another log-structured filesystem that does snapshotting. Just google for 'nilfs2' for more details. - "exofs" implements a filesystem on top of an external object store (ie not a traditional storage of a linear array of anonymous blocks, but a "smart" disk that does objects). See Documentation/filesystems/exofs.txt for some details. - fscache/cachefiles is not really a filesystem, but infrastructure to do caching of remote filesystems in the local filesystem, and NFS and AFS have been updated to be able to use it. I'm personally hoping that we'll run out of filesystems rather than continue this new tradition indefinitely, but we'll see. But we've got older filesystems updated too: btrfs hopefully uses less stack space and is usable with a 4k stack, reiserfs got some updates, and a lot of other filesystems got minor refreshes. The ext3 changes are small enough to not show up in any dirstat, but hey, I think the fsync latency changes are interesting and probably more relevant to lots of people than most of the other changes. Other? Arch updates - amainly rm, powerpc, sh and x86. Firmware updates. And lots and lots of driver updates, including some more core suspend/resume changes (hopefully the last really fundamental ones). Go out and try it, Linus --
I was really hoping some of the Xen dom0 patches would be merged to lessen the load as time goes on an prevent a large Xen dump all at once. Is there any reason NONE of these patches made it upstream this round, or the past few for the matter? Regards, Kevin Bowling --
[cc'ing Jeremy] /me was interested in this as well, Jeremy - can you comment on that? Thanks, Christian. -- Bruce Schneier has an Olympic-sized entropy pool. --
On and ia64 system with a QLA12160 adapter, my boot fails with:
qla1280: QLA12160 found on PCI bus 0, dev 3
qla1280 0001:00:03.0: PCI INT A -> GSI 61 (level, low) -> IRQ 61
scsi(0): Enabling SN2 PCI DMA dual channel lockup workaround
qla1280 0001:00:03.0: firmware: using built-in firmware qlogic/12160.bin
qla1280_mailbox_command: Command failed, mailbox0 = 0x0007, mailbox_out0 = 0x4003, istatus = 0x6000
m0 4003, m1 b141, m2 5555, m3 aa55
m4 55aa, m5 a5a5, m6 5a5a, m7 2525
scsi(0): RISC checksum failed.
scsi(0): initialize: pci probe failed!
qla1x160: Failed to initialize adapter
qla1280 0001:00:03.0: PCI INT A disabled
I did a git-bisect and narrowed it down to:
commit 1bfa11db712cbf4af1ae037cd25fd4f781f0c215
Author: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Date: Thu Apr 2 11:13:17 2009 +0530
[SCSI] qla1280: use request_firmware
Firmware blob is little endian looks like this...
unsigned char Version1
unsigned char Version2
unsigned char Version3
unsigned char Padding
unsigned short start_address
unsigned short data
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
When I revert that commit from the 2.6.30-rc1 revision, I get a bootable
system.
Thanks,
Robin
--
Does this fix it?
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index 351b56c..b6f8382 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -1663,7 +1663,7 @@ qla1280_load_firmware_pio(struct scsi_qla_host
*ha)
/* Load RISC code. */
risc_address = ha->fwstart;
- fw_data = (const __le16 *)&fw->data[4];
+ fw_data = (const __le16 *)&fw->data[3];
risc_code_size = (fw->size - 6) / 2;
for (i = 0; i < risc_code_size; i++) {
@@ -1722,7 +1722,7 @@ qla1280_load_firmware_dma(struct scsi_qla_host
*ha)
/* Load RISC code. */
risc_address = ha->fwstart;
- fw_data = (const __le16 *)&fw->data[4];
+ fw_data = (const __le16 *)&fw->data[3];
risc_code_size = (fw->size - 6) / 2;
dprintk(1, "%s: DMA RISC code (%i) words\n",
--
dwmw2
--
Brain fade; don't bother with that one. I think it should be &fw->data[6] instead. -- dwmw2 --
According to Jeremy, that fixed it. Just added it to my workarea and started a build. Thanks, Robin --
Thanks for the report. After successful feedback from Jeremy, I've added
the commit below to git://git.infradead.org/~dwmw2/firmware-2.6.git,
From: David Woodhouse <David.Woodhouse@intel.com>
Date: Wed, 8 Apr 2009 01:22:36 -0700
Subject: [PATCH] qla1280: Fix off-by-some error in firmware loading.
We were calculating the wrong address for the start of the data.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Jeremy Higdon <jeremy@sgi.com>
---
drivers/scsi/qla1280.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index 351b56c..d030db9 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -1663,7 +1663,7 @@ qla1280_load_firmware_pio(struct scsi_qla_host *ha)
/* Load RISC code. */
risc_address = ha->fwstart;
- fw_data = (const __le16 *)&fw->data[4];
+ fw_data = (const __le16 *)&fw->data[6];
risc_code_size = (fw->size - 6) / 2;
for (i = 0; i < risc_code_size; i++) {
@@ -1722,7 +1722,7 @@ qla1280_load_firmware_dma(struct scsi_qla_host *ha)
/* Load RISC code. */
risc_address = ha->fwstart;
- fw_data = (const __le16 *)&fw->data[4];
+ fw_data = (const __le16 *)&fw->data[6];
risc_code_size = (fw->size - 6) / 2;
dprintk(1, "%s: DMA RISC code (%i) words\n",
--
1.6.2.2
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
--
Hello David, you have updated the tree, so better send new pull request to Linus to avoid any confusions :-) Thanks, -- JSR --
The URL is above; he's clever enough to work it out. If he still hasn't pulled it by the time I get home, I'll send another request. -- dwmw2 --
Booting an ia64 box with a tg3 adapter results in no network. If I look at the MAC address of the adapter, it has changed radically from the original MAC. The original MAC continues to be reported by EFI and booting an old kernel gets the correct MAC. Good MAC: 08:00:69:13:E6:3C Bad MAC: 00:00:3C:E6:13:69 (recreated from memory) If I set the MAC using ifconfig, then everything works normally. Robin --
I would like to ask again if you can pull new Microblaze arch to your tree. All patches go to arch/microblaze folder (+ one change in serial Kconfig). Ingo reviewed all patches. Ingo told me that you are just busy and you added Microblaze at the end you huge merge list. I was OK with it and wait and I see that Microblaze wasn't there. My request is in LKML from 28.3.2008. We sent you some private email but we don't have any your response. Thomas Gleixner wrote you private email too. Do you have any response? I am going to send you my request in special email again. Is that anything wrong with Microblaze or don't you want to add new arch? Thanks, -- Michal Simek, Ing. (M.Eng) PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663 --
On Wed, Apr 8, 2009 at 8:20 AM, Linus Torvalds There is no way to build if one has CONFIG_SERIAL_MAX3100 selected to be 'y' or 'm' - there is not max3100.c at all... -- Thanks, Jike --
