linux-kernel - Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Jun 2011 20:07:42 +0100 (BST)
From:	Paul Parsons <lost.distance@...oo.com>
To:	Jean-François Dagenais <dagenaisj@...atest.com>
Cc:	linux-kernel@...r.kernel.org, johnpol@....mipt.ru
Subject: Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"

Hi Jean-Francois,

I think I've found the problem.

On a hunch I restored the msleep() call that had been removed from ds1wm_reset() after 2.6.39:

--- clean-3.0-rc4/drivers/w1/masters/ds1wm.c	2011-06-21 04:25:46.000000000 +0100
+++ linux-3.0-rc4/drivers/w1/masters/ds1wm.c	2011-06-24 19:58:03.340701823 +0100
@@ -182,6 +182,8 @@ static int ds1wm_reset(struct ds1wm_data
 		return 1;
 	}
 
+	msleep(1);
+
 	if (!ds1wm_data->slave_present) {
 		dev_dbg(&ds1wm_data->pdev->dev, "reset: no devices found\n");
 		return 1;

This has completely eliminated the "bus error, retrying" error messages, and the hx4700 seems to be functioning normally again.

Regards,
Paul

--- On Fri, 24/6/11, Jean-François Dagenais <dagenaisj@...atest.com> wrote:

> From: Jean-François Dagenais <dagenaisj@...atest.com>
> Subject: Re: w1/ds1wm regression after 2.6.39: "bus error, retrying"
> To: "Paul Parsons" <lost.distance@...oo.com>
> Cc: linux-kernel@...r.kernel.org, johnpol@....mipt.ru
> Date: Friday, 24 June, 2011, 17:15
> Hi Paul,
> 
> Sorry to hear that. 2.6.39's ds1wm driver did not support
> dynamically finding the slaves on the bus, it would limit
> it's search to 1 and exit. My modifications implement the
> hardware assisted search as documented by the ds1wm spec
> sheet.
> 
> There are a couple of ways you can workaround the problem
> (temporarily or permanently). You might disable the bus
> scanning altogether (like I explain below) and insert your
> slave manually (as documented in the kernel w1 docs). If
> only one slave is present, the bus master will usually just
> skip the ROM matching part of the communication by doing a
> "SKIP ROM" which essentially says to the slave "whoever you
> are, I am talking to you". You could also patch the
> ds1wm_search function to make it look like it was in 2.6.39,
> or just use the whole file if it worked fine for you.
> 
> Now, to find the real problem, could you try the
> following:
> - to limit trace noise, disable the w1 auto probe by
> setting the search count to 0, either in "wire" module load
> ("search_count=0" in /etc/modprobe.conf or the like) or int
> /sys under your w1 master instance
> - build the ds1wm with "#define DEBUG" at the top (before
> headers), this will prints lots of debug about the
> accelerated search algorithm progress. (you could also set
> the retry count to something less than 100 to also limit
> noise in the trace)
> - once booted, trigger one search manually by writing 1 in
> /sys/bus/w1/devices/w1\ bus\ master/w1_master_search
> dmesg will contain a nice trace (although big)
> 
> Do you have more than one slave device on the ds1wm bus?
> 
> I will try to help as much as I can.
> /jfd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/