From ec9a13cdbfc8cf29502096ca69b65f07184a9b2c Mon Sep 17 00:00:00 2001 From: Nigel Cunningham Date: Tue, 9 Dec 2008 22:40:20 +1100 Subject: ieee1394: node manager causes up to ~3.25s delay in freezing tasks The firewire nodemanager function "nodemgr_host_thread" contains a loop that calls try_to_freeze near the top of the loop, but then delays for up to 3.25 seconds (plus time to do work) before getting back to the top of the loop. When starting a cycle post-boot, this doesn't seem to bite, but it is causing a noticeable delay at boot time, when freezing processes prior to starting to read the image. The following patch adds invocation of try_to_freeze to the subloops that are used in the body of this function. With these additions, the time to freeze when starting to resume at boot time is virtually zero. I'm no expert on firewire, and so don't know that we shouldn't check the return value and jump back to the top of the loop or such like after being frozen, but I submit it for your consideration. Signed-off-by: Nigel Cunningham The delay until nodemgr freezes was up to 0.25s (plus time for node probes) in Linux 2.6.27 and older and up to 3.25s (plus ~) since Linux 2.6.28-rc1, hence much more noticeable. try_to_freeze() without any jump is correct. The surrounding code in the respective loops will catch whether another bus reset happens during the freeze and handle it. Signed-off-by: Stefan Richter --- drivers/ieee1394/nodemgr.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'drivers/ieee1394/nodemgr.c') diff --git a/drivers/ieee1394/nodemgr.c b/drivers/ieee1394/nodemgr.c index 9e39f73282ee..d333ae22459c 100644 --- a/drivers/ieee1394/nodemgr.c +++ b/drivers/ieee1394/nodemgr.c @@ -1685,6 +1685,7 @@ static int nodemgr_host_thread(void *data) g = get_hpsb_generation(host); for (i = 0; i < 4 ; i++) { msleep_interruptible(63); + try_to_freeze(); if (kthread_should_stop()) goto exit; @@ -1725,6 +1726,7 @@ static int nodemgr_host_thread(void *data) /* Sleep 3 seconds */ for (i = 3000/200; i; i--) { msleep_interruptible(200); + try_to_freeze(); if (kthread_should_stop()) goto exit; -- cgit v1.2.3 From 25a41b280083259d05d68f61633194344a1f8a9f Mon Sep 17 00:00:00 2001 From: Stefan Richter Date: Sat, 13 Dec 2008 01:43:59 +0100 Subject: ieee1394: add quirk fix for Freecom HDD According to http://bugzilla.kernel.org/show_bug.cgi?id=12206, Freecom FireWire Hard Drive 1TB reports max_rom=2 but returns garbage if block read requests are used to read the config ROM. Force max_rom=0 to limit them to quadlet read requests. Reported-by: Christian Mueller Signed-off-by: Stefan Richter --- drivers/ieee1394/nodemgr.c | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'drivers/ieee1394/nodemgr.c') diff --git a/drivers/ieee1394/nodemgr.c b/drivers/ieee1394/nodemgr.c index d333ae22459c..79ef5fd928ae 100644 --- a/drivers/ieee1394/nodemgr.c +++ b/drivers/ieee1394/nodemgr.c @@ -115,8 +115,14 @@ static int nodemgr_bus_read(struct csr1212_csr *csr, u64 addr, u16 length, return error; } +#define OUI_FREECOM_TECHNOLOGIES_GMBH 0x0001db + static int nodemgr_get_max_rom(quadlet_t *bus_info_data, void *__ci) { + /* Freecom FireWire Hard Drive firmware bug */ + if (be32_to_cpu(bus_info_data[3]) >> 8 == OUI_FREECOM_TECHNOLOGIES_GMBH) + return 0; + return (be32_to_cpu(bus_info_data[2]) >> 8) & 0x3; } -- cgit v1.2.3