On Sat, Dec 6, 2014 at 12:22 AM, One Thousand Gnomes
wrote:
>
>> 2.a. If task A has sufficient capabilities to send signals to task B, then
>> task A is already in position to do anything it wants with task B, including
>> killing it outright.
>
> Not entirely true.
>
> - We have securirty models
On Sat, Dec 6, 2014 at 6:23 AM, Bastien ROUCARIES
wrote:
>
>
> See senfd recvfd in gnulib. It wirk even under solaris
>
What's so special about a thin wrapper around domain sockets/named
fifos (solaris style)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Sat, Dec 6, 2014 at 6:23 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
See senfd recvfd in gnulib. It wirk even under solaris
What's so special about a thin wrapper around domain sockets/named
fifos (solaris style)?
--
To unsubscribe from this list: send the line unsubscribe
On Sat, Dec 6, 2014 at 12:22 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
2.a. If task A has sufficient capabilities to send signals to task B, then
task A is already in position to do anything it wants with task B, including
killing it outright.
Not entirely true.
- We have
On Wed, Dec 3, 2014 at 9:41 PM, Richard Cochran
wrote:
> In any case, I find it hard to believe that the traditional method is
> really so bad. The explanation of why this new way is needed boils
> down to: "unix programming is so hard to get right."
Surely, this can be said about any new
I would like to present my second attempt at file descriptor duplication over
Posix.1b real-time signal transport. All the constructive points raised
in the previous discussion are believed to be addressed.
To this end, I would like to address some concerns raised in the preceding
discussion:
1.
within the siginfo data).
Signed-off-by: Alex Dubov
---
arch/x86/syscalls/syscall_32.tbl | 2 +
arch/x86/syscalls/syscall_64.tbl | 1 +
include/asm-generic/siginfo.h | 1 +
include/linux/syscalls.h | 1 +
include/uapi/asm-generic/siginfo.h | 1 +
init/Kconfig
within the siginfo data).
Signed-off-by: Alex Dubov oa...@yahoo.com
---
arch/x86/syscalls/syscall_32.tbl | 2 +
arch/x86/syscalls/syscall_64.tbl | 1 +
include/asm-generic/siginfo.h | 1 +
include/linux/syscalls.h | 1 +
include/uapi/asm-generic/siginfo.h | 1 +
init/Kconfig
I would like to present my second attempt at file descriptor duplication over
Posix.1b real-time signal transport. All the constructive points raised
in the previous discussion are believed to be addressed.
To this end, I would like to address some concerns raised in the preceding
discussion:
1.
On Wed, Dec 3, 2014 at 9:41 PM, Richard Cochran
richardcoch...@gmail.com wrote:
In any case, I find it hard to believe that the traditional method is
really so bad. The explanation of why this new way is needed boils
down to: unix programming is so hard to get right.
Surely, this can be said
On Wed, Dec 3, 2014 at 2:40 PM, Al Viro wrote:
> On Wed, Dec 03, 2014 at 01:22:33PM +1100, Alex Dubov wrote:
>
>> On a less related note, I hope you will agree that the simpler
>> mechanism for this very in-demand feature is long overdue on Linux
>> (every man and his do
On Wed, Dec 3, 2014 at 4:00 AM, Al Viro wrote:
> On Tue, Dec 02, 2014 at 03:35:18PM +1100, Alex Dubov wrote:
>> +
>> + if (rc < 0)
>> + __close_fd(dst_files, s_info.si_int);
>
> Oh, lovely... And we are guaranteed that it still the same file,
On Wed, Dec 3, 2014 at 3:42 AM, Eric Dumazet wrote:
> On Wed, 2014-12-03 at 03:23 +1100, Alex Dubov wrote:
>
> Tell me how a 128 threads program can use this new mechanism in a
> scalable way.
>
> One signal per thread ?
What for?
Kernel will deliver the signal only to the th
On Wed, Dec 3, 2014 at 2:26 AM, Jonathan Corbet wrote:
> On Tue, 2 Dec 2014 15:35:17 +1100
> Alex Dubov wrote:
>
>
> - Messing with another process's file descriptor table without its
>knowledge looks like a possible source of all kinds problems. Might
>the
On Wed, Dec 3, 2014 at 2:33 AM, Eric Dumazet wrote:
> On Wed, 2014-12-03 at 01:47 +1100, Alex Dubov wrote:
>> > User A can send fd(s) to processes belonging to user B, even if user B
>> > does (probably) not want this to happen ?
>>
>> 1. Process A must have
> User A can send fd(s) to processes belonging to user B, even if user B
> does (probably) not want this to happen ?
1. Process A must have sufficient permissions to signal process B.
This will only happen if process A belongs to the same user as process
B or has elevated capabilities, which can
On Tue, Dec 2, 2014 at 10:42 PM, Michal Simek wrote:
> On 12/02/2014 09:01 AM, Geert Uytterhoeven wrote:
>> This really needs a CC to linux-arch (added).
>>
>> On Tue, Dec 2, 2014 at 5:35 AM, Alex Dubov wrote:
>>> Signed-off-by: Alex Dubov
>>> ---
On Tue, Dec 2, 2014 at 7:01 PM, Geert Uytterhoeven wrote:
> This really needs a CC to linux-arch (added).
>
>
> You forgot to update NR_syscalls in arch/m68k/include/asm/unistd.h.
>
Noted. I would assume that other architectures may have similar
problems (I only tested
my submission on x86_64).
On Tue, Dec 2, 2014 at 7:01 PM, Geert Uytterhoeven ge...@linux-m68k.org wrote:
This really needs a CC to linux-arch (added).
You forgot to update NR_syscalls in arch/m68k/include/asm/unistd.h.
Noted. I would assume that other architectures may have similar
problems (I only tested
my
On Tue, Dec 2, 2014 at 10:42 PM, Michal Simek mon...@monstr.eu wrote:
On 12/02/2014 09:01 AM, Geert Uytterhoeven wrote:
This really needs a CC to linux-arch (added).
On Tue, Dec 2, 2014 at 5:35 AM, Alex Dubov alex.du...@gmail.com wrote:
Signed-off-by: Alex Dubov oa...@yahoo.com
User A can send fd(s) to processes belonging to user B, even if user B
does (probably) not want this to happen ?
1. Process A must have sufficient permissions to signal process B.
This will only happen if process A belongs to the same user as process
B or has elevated capabilities, which can
On Wed, Dec 3, 2014 at 2:33 AM, Eric Dumazet eric.duma...@gmail.com wrote:
On Wed, 2014-12-03 at 01:47 +1100, Alex Dubov wrote:
User A can send fd(s) to processes belonging to user B, even if user B
does (probably) not want this to happen ?
1. Process A must have sufficient permissions
On Wed, Dec 3, 2014 at 2:26 AM, Jonathan Corbet cor...@lwn.net wrote:
On Tue, 2 Dec 2014 15:35:17 +1100
Alex Dubov alex.du...@gmail.com wrote:
- Messing with another process's file descriptor table without its
knowledge looks like a possible source of all kinds problems. Might
On Wed, Dec 3, 2014 at 3:42 AM, Eric Dumazet eric.duma...@gmail.com wrote:
On Wed, 2014-12-03 at 03:23 +1100, Alex Dubov wrote:
Tell me how a 128 threads program can use this new mechanism in a
scalable way.
One signal per thread ?
What for?
Kernel will deliver the signal only
On Wed, Dec 3, 2014 at 4:00 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Dec 02, 2014 at 03:35:18PM +1100, Alex Dubov wrote:
+
+ if (rc 0)
+ __close_fd(dst_files, s_info.si_int);
Oh, lovely... And we are guaranteed that it still the same file, because
On Wed, Dec 3, 2014 at 2:40 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Wed, Dec 03, 2014 at 01:22:33PM +1100, Alex Dubov wrote:
On a less related note, I hope you will agree that the simpler
mechanism for this very in-demand feature is long overdue on Linux
(every man and his dog
signal queue, the newly created file descriptor will be
promptly closed.
Signed-off-by: Alex Dubov
---
fs/Makefile | 1 +
fs/sendfd.c | 82
init/Kconfig | 11
3 files changed, 94 insertions(+)
create mode 100644 fs/sendfd.c
Signed-off-by: Alex Dubov
---
arch/arm/include/uapi/asm/unistd.h| 1 +
arch/arm/kernel/calls.S | 1 +
arch/arm64/include/asm/unistd32.h | 2 ++
arch/ia64/include/uapi/asm/unistd.h | 1 +
arch/ia64/kernel/entry.S | 1 +
arch/m68k
A common requirement in parallel processing applications (relied upon by
popular network servers, databases and various other applications) is to
pass open file descriptors between processes. Historically, several mechanisms
existed to support this requirement, such as those provided by "cmsg"
Signed-off-by: Alex Dubov oa...@yahoo.com
---
arch/arm/include/uapi/asm/unistd.h| 1 +
arch/arm/kernel/calls.S | 1 +
arch/arm64/include/asm/unistd32.h | 2 ++
arch/ia64/include/uapi/asm/unistd.h | 1 +
arch/ia64/kernel/entry.S | 1
A common requirement in parallel processing applications (relied upon by
popular network servers, databases and various other applications) is to
pass open file descriptors between processes. Historically, several mechanisms
existed to support this requirement, such as those provided by cmsg
signal queue, the newly created file descriptor will be
promptly closed.
Signed-off-by: Alex Dubov oa...@yahoo.com
---
fs/Makefile | 1 +
fs/sendfd.c | 82
init/Kconfig | 11
3 files changed, 94 insertions(+)
create mode 100644
not
obvious how it is supposed to be handled these days.
From: Larry Finger
To: Catalin Marinas
Cc: Alex Dubov ; Linux Kernel Mailing List
; Kay Sievers ; Greg
Kroah-Hartman
Sent: Monday, 7 October 2013 11:02 AM
Subject: Re: [PATCH] memstick: Fix memory leak
not
obvious how it is supposed to be handled these days.
From: Larry Finger larry.fin...@lwfinger.net
To: Catalin Marinas catalin.mari...@arm.com
Cc: Alex Dubov oa...@yahoo.com; Linux Kernel Mailing List
linux-kernel@vger.kernel.org; Kay Sievers kay.siev...@vrfy.org
>
>
> Hi Alex:
Hi,
>
> Do you have any comment on the MEMSTICK part in this v7 patchset? Can
> you help to merge the patch to the kernel tree?
I'm afraid that presently I don't have much time to look at the memstick
related stuff any further. Hopefully, somebody else can step in and take
Hi Alex:
Hi,
Do you have any comment on the MEMSTICK part in this v7 patchset? Can
you help to merge the patch to the kernel tree?
I'm afraid that presently I don't have much time to look at the memstick
related stuff any further. Hopefully, somebody else can step in and take a
--- Al Viro <[EMAIL PROTECTED]> wrote:
> readl(sock + ...) that should've been readl(sock->addr + ...)
>
Thanks. It's a first member in struct, so the problem was just sitting there
unnoticed.
Be a
--- Al Viro [EMAIL PROTECTED] wrote:
readl(sock + ...) that should've been readl(sock-addr + ...)
Thanks. It's a first member in struct, so the problem was just sitting there
unnoticed.
Be a
Signed-off-by: Alex Dubov <[EMAIL PROTECTED]>
---
drivers/memstick/core/mspro_block.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/memstick/core/mspro_block.c
b/drivers/memstick/core/mspro_block.c
index b9bd0aa..423ad8c 100644
--- a/drivers/me
Signed-off-by: Alex Dubov [EMAIL PROTECTED]
---
drivers/memstick/core/mspro_block.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/memstick/core/mspro_block.c
b/drivers/memstick/core/mspro_block.c
index b9bd0aa..423ad8c 100644
--- a/drivers/memstick
Signed-off-by: Alex Dubov <[EMAIL PROTECTED]>
--- mspro_block.c.orig 2008-02-04 15:25:16.0 +1100
+++ mspro_block.c 2008-02-04 15:26:28.226886699 +1100
@@ -668,20 +668,13 @@
spin_lock_irqsave(>q_lock, flags);
if
Signed-off-by: Alex Dubov [EMAIL PROTECTED]
--- mspro_block.c.orig 2008-02-04 15:25:16.0 +1100
+++ mspro_block.c 2008-02-04 15:26:28.226886699 +1100
@@ -668,20 +668,13 @@
spin_lock_irqsave(msb-q_lock, flags);
if (rc = 0
* Mark shared inline functions as static
* Use member-at-a-time assignment for protocol structures
* Comments for publicly exported functions
* Use end_queued_request to end unhandled block layer requests
* Use sysfs attribute group to export MSPro attributes
* Fix includes
* Use scnprintf
* Mark shared inline functions as static
* Use member-at-a-time assignment for protocol structures
* Comments for publicly exported functions
* Use end_queued_request to end unhandled block layer requests
* Use sysfs attribute group to export MSPro attributes
* Fix includes
* Use scnprintf
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
>
> > From: Alex Dubov <[EMAIL PROTECTED]>
> >
> > Sony MemoryStick cards are used in many products manufactured by Sony. They
> > are available
--- Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
From: Alex Dubov [EMAIL PROTECTED]
Sony MemoryStick cards are used in many products manufactured by Sony. They
are available both as storage and as IO expansion cards. Currently
--- Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > Sony MemoryStick cards are used in many products manufactured by Sony. They
> > are available both as storage and as IO expansion cards. Currently, only
> > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
--- Mariusz Kozlowski [EMAIL PROTECTED] wrote:
Hello,
Sony MemoryStick cards are used in many products manufactured by Sony. They
are available both as storage and as IO expansion cards. Currently, only
MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
>
> > From: Alex Dubov <[EMAIL PROTECTED]>
> >
> > Sony MemoryStick cards are used in many products manufactured by Sony. They
> > are available
--- Andrew Morton [EMAIL PROTECTED] wrote:
On Wed, 2 Jan 2008 17:42:24 +1100 [EMAIL PROTECTED] wrote:
From: Alex Dubov [EMAIL PROTECTED]
Sony MemoryStick cards are used in many products manufactured by Sony. They
are available both as storage and as IO expansion cards. Currently
--- Carlos Corbacho <[EMAIL PROTECTED]> wrote:
>
> So do we require changes to the userspace udev rules here, or just some use
> of
> modalias in the drivers?
>
It was handled by whoever manages the distro's udev rules until now. Here's the
example:
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Dec 31 2007 00:01, Carlos Corbacho wrote:
> >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
> >> From: Alex Dubov <[EMAIL PROTECTED]>
> >>
> >> Sony MemoryStick c
> However, my only concerns are that:
>
> 1) tifm_ms was not autoloaded
> 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not.
>
> Although, whether this is an issue with userspace (ie. udev) not dealing with
> the modules properly, I don't know.
>
This is exactly the
--- Jan Engelhardt [EMAIL PROTECTED] wrote:
On Dec 31 2007 00:01, Carlos Corbacho wrote:
On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
From: Alex Dubov [EMAIL PROTECTED]
Sony MemoryStick cards are used in many products manufactured by Sony. They
are available both
However, my only concerns are that:
1) tifm_ms was not autoloaded
2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not.
Although, whether this is an issue with userspace (ie. udev) not dealing with
the modules properly, I don't know.
This is exactly the same as
--- Carlos Corbacho [EMAIL PROTECTED] wrote:
So do we require changes to the userspace udev rules here, or just some use
of
modalias in the drivers?
It was handled by whoever manages the distro's udev rules until now. Here's the
example:
After a much longer, than expected, time I managed to implement a support for
MemoryStick (read-only currently, as there's still a subtle data corruption bug
with writes) and MemoryStick Pro cards. The implementation follows the MMC
driver model (there exist MSIO cards, but none are supported
After a much longer, than expected, time I managed to implement a support for
MemoryStick (read-only currently, as there's still a subtle data corruption bug
with writes) and MemoryStick Pro cards. The implementation follows the MMC
driver model (there exist MSIO cards, but none are supported
["if (!x & y)" patches from [EMAIL PROTECTED]
> >
> > While we're at it, below is somewhat ugly sparse patch for detecting
> > "&& 0x" typos.
> >
>
> The maintainer for tifm is Alex Dubov, so cc:ing him.
>
> >
ugly sparse patch for detecting
0x typos.
The maintainer for tifm is Alex Dubov, so cc:ing him.
drivers/mmc/host/tifm_sd.c:183:9: warning: dubious 0x
if ((r_data-flags MMC_DATA_WRITE)
DATA_CARRY)
writel(host-bounce_buf_data[0],
host
--- "Renato S. Yamane" <[EMAIL PROTECTED]> wrote:
> When I insert a SDCard in my laptop M45-S355 my system crash because
> tifm start a infinite loop. See below more detail about SD/MMC Card and
> infinite loop.
If you are using the built-in version found in 2.6.21 then it is a known
Not really.
Current svn has read-only support for legacy MS (not mspro yet). I'm still
working on it. The
major difference: mmc/sd has an open spec, sony ms has none.
--- Norbert Preining <[EMAIL PROTECTED]> wrote:
> Hi Alex, hi all,
>
> I have an Acer TM3012 with
> 0a:09.2 Mass storage
Not really.
Current svn has read-only support for legacy MS (not mspro yet). I'm still
working on it. The
major difference: mmc/sd has an open spec, sony ms has none.
--- Norbert Preining [EMAIL PROTECTED] wrote:
Hi Alex, hi all,
I have an Acer TM3012 with
0a:09.2 Mass storage controller:
--- Renato S. Yamane [EMAIL PROTECTED] wrote:
When I insert a SDCard in my laptop M45-S355 my system crash because
tifm start a infinite loop. See below more detail about SD/MMC Card and
infinite loop.
If you are using the built-in version found in 2.6.21 then it is a known
problem. You
>
> > > - Do we need freezeable workqueues ?
> >
> > Well, we have at least one case in which they appear to be useful.
>
I need freezeable wq exactly for the fact that they are synchronized with
suspend/resume. My
workitem may do device_register/unregister and it can (and will be)
- Do we need freezeable workqueues ?
Well, we have at least one case in which they appear to be useful.
I need freezeable wq exactly for the fact that they are synchronized with
suspend/resume. My
workitem may do device_register/unregister and it can (and will be) scheduled
from
I don't have any particular need in multithreaded wq, but I do need it
freezeable. Freezeability
simplifies things quite a lot. This is ok with me:
> -#define create_freezeable_workqueue(name) __create_workqueue((name), 0, 1)
> +#define create_freezeable_workqueue(name)
I don't have any particular need in multithreaded wq, but I do need it
freezeable. Freezeability
simplifies things quite a lot. This is ok with me:
-#define create_freezeable_workqueue(name) __create_workqueue((name), 0, 1)
+#define create_freezeable_workqueue(name) __create_workqueue((name),
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Sergey Yanovich wrote:
> > I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
> > After [tifm_sd] is loaded. My smoke test script at
> >
> > http://bugzilla.kernel.org/attachment.cgi?id=11240=view
> >
> > reliably hangs suspend.
>
> I
> After [tifm_sd] is loaded. My smoke test script at
>
> http://bugzilla.kernel.org/attachment.cgi?id=11240=view
>
> reliably hangs suspend.
>
What is "modprobe tifm"? What modules have you loaded when it hangs?
__
Do You Yahoo!?
Tired of spam?
After [tifm_sd] is loaded. My smoke test script at
http://bugzilla.kernel.org/attachment.cgi?id=11240action=view
reliably hangs suspend.
What is modprobe tifm? What modules have you loaded when it hangs?
__
Do You Yahoo!?
Tired of spam?
--- Pierre Ossman [EMAIL PROTECTED] wrote:
Sergey Yanovich wrote:
I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
After [tifm_sd] is loaded. My smoke test script at
http://bugzilla.kernel.org/attachment.cgi?id=11240action=view
reliably hangs suspend.
I really
> It seems a bit out-of-date. Here is the output:
>
It clearly says there that the driver is for 2.6.20. The changes needed for
2.6.21 are actually
very small (couple of fields in the mmc layer were renamed).
In general, it is impossible to maintain out-of-tree driver in sync with kernel
tree
>
> I have submitted my version only after I have failed to find a stable
> version of your driver for the current kernel. If there is one, just
> post link to the patch. If not, let's make one.
>
As I already said, I'm not aware of any issues with version 0.8 of the driver.
If you have any
I have submitted my version only after I have failed to find a stable
version of your driver for the current kernel. If there is one, just
post link to the patch. If not, let's make one.
As I already said, I'm not aware of any issues with version 0.8 of the driver.
If you have any
problems
It seems a bit out-of-date. Here is the output:
It clearly says there that the driver is for 2.6.20. The changes needed for
2.6.21 are actually
very small (couple of fields in the mmc layer were renamed).
In general, it is impossible to maintain out-of-tree driver in sync with kernel
tree -
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Sergey Yanovich wrote:
> >
> > I have found it easier to rewrite the driver, than to fix.
>
> Before you get your hopes up, this development model is not one that will get
> your code merged upstream. You should really try to work with Alex, not
--- Pierre Ossman [EMAIL PROTECTED] wrote:
Sergey Yanovich wrote:
I have found it easier to rewrite the driver, than to fix.
Before you get your hopes up, this development model is not one that will get
your code merged upstream. You should really try to work with Alex, not side
step
>
> I am not in any way argue that your driver architecture is wrong or that you
> should change anything. My point was simple. [tifm_sd] can only work with
> [tifm_7xx1]. If you add support for let's say [tifm_8xx2] in the future, which
> would have port offsets different that [tifm_7xx1], you
--- Sergey Yanovich <[EMAIL PROTECTED]> wrote:
> > > For a typical, non-linux-geek user there are just two states of the
> > > device -
> > > available and not available. Ububtu is famous for its end-user support.
> > > They ship your driver since linux-2.6.17. But they pack it in one module.
>
--- Sergey Yanovich [EMAIL PROTECTED] wrote:
For a typical, non-linux-geek user there are just two states of the
device -
available and not available. Ububtu is famous for its end-user support.
They ship your driver since linux-2.6.17. But they pack it in one module.
And that is
I am not in any way argue that your driver architecture is wrong or that you
should change anything. My point was simple. [tifm_sd] can only work with
[tifm_7xx1]. If you add support for let's say [tifm_8xx2] in the future, which
would have port offsets different that [tifm_7xx1], you would
> Finally, tifm_sd module needs to be manually inserted.
By the way, the driver emits custom uevent when the new card is detected. I was
going to look at
this some day in the future, but if you want to mess a little with hotplug
scripts the issue can
be easily solved.
As I already said before,
Finally, tifm_sd module needs to be manually inserted.
By the way, the driver emits custom uevent when the new card is detected. I was
going to look at
this some day in the future, but if you want to mess a little with hotplug
scripts the issue can
be easily solved.
As I already said before,
daily
suspending/resuming) without a single glitch.
This patch only provides sources.
[PATCH1/2] [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7
Kernel configuration in this message.
[PATCH2/2] [mmc] alternative TIFM driver config for 2.6.21-rc7
Alex Dubov has done exceptionally great lots of work to
/resuming) without a single glitch.
This patch only provides sources.
[PATCH1/2] [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7
Kernel configuration in this message.
[PATCH2/2] [mmc] alternative TIFM driver config for 2.6.21-rc7
Alex Dubov has done exceptionally great lots of work to teach
In fact, this is fixed in already queued patch set.
--- Daniel Drake <[EMAIL PROTECTED]> wrote:
> Noticed this in user logs.
>
> Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
>
> Index: linux/drivers/mmc/tifm_sd.c
> ===
> ---
In fact, this is fixed in already queued patch set.
--- Daniel Drake [EMAIL PROTECTED] wrote:
Noticed this in user logs.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux/drivers/mmc/tifm_sd.c
===
---
Problem 2: After a data crc error all subsequent commands fail. May it be
caused by stop command
leaving card in some bad state (something clearable by SEND_STATUS)? On the
other hand, is there a
real need to issue a stop command in case main command failed?
Example:
Mar 14 09:25:13
Recently, I've obtained a bug report concerning an MMC card. Two problems are
described, both
sporadic.
Problem 1: illegal ocr value is returned. You may notice, in the non-working
case, obviously
incorrect ocr value (0x) is returned. The card won't work after this,
unless reinserted.
Recently, I've obtained a bug report concerning an MMC card. Two problems are
described, both
sporadic.
Problem 1: illegal ocr value is returned. You may notice, in the non-working
case, obviously
incorrect ocr value (0x) is returned. The card won't work after this,
unless reinserted.
Problem 2: After a data crc error all subsequent commands fail. May it be
caused by stop command
leaving card in some bad state (something clearable by SEND_STATUS)? On the
other hand, is there a
real need to issue a stop command in case main command failed?
Example:
Mar 14 09:25:13
> >
> > mmc_rescan
> > mmc_register_card
> > device_add
> > mmc_block_probe
> > mmc_block_alloc
> > -> queue thread starts running
> > add_disk
> > -> issues a lot of requests; card fails, my drivers calls
> > mmc_remove_host, which in
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Alex Dubov wrote:
> >
> > You'll agree, I think, that add_disk in mmc_block_probe issues a lot of
> > requests (reads
> partition
> > table, fs superblocks and such - plenty of room for critical errors).
--- Pierre Ossman [EMAIL PROTECTED] wrote:
Alex Dubov wrote:
You'll agree, I think, that add_disk in mmc_block_probe issues a lot of
requests (reads
partition
table, fs superblocks and such - plenty of room for critical errors). Then,
driver's remove
method
will not be called
mmc_rescan
mmc_register_card
device_add
mmc_block_probe
mmc_block_alloc
- queue thread starts running
add_disk
- issues a lot of requests; card fails, my drivers calls
mmc_remove_host, which in
correction: my driver schedules
> > This is hard to trigger problem, so I'll spare you the rather lengthy log.
> > It happens if card timeouts and mmc_remove_host is called while
> > mmc_register_card is still in
> > progress (the hint was in crash dump). If I sleep before remove, it gives
> > the
> mmc_register_card
> >
>
> I don't see how that is possible. mmc_block's remove routine waits for mmcqd
> to
> exit, so there can't be any code still alive that has a request going. (I am
> also completely unable to reproduce this problem here).
>
> Add more printk:s do verify how the code in mmc_block executes.
>
> I don't see that - as I say above, the correct sequence is:
>
> - host device resume
> - calls mmc_resume_host()
> - child's device resume (mmc_blk_resume)
> - mmc_queue_resume()
>
Of course, I understand that this is a correct sequence. It simply was not
obvious to me that host
I don't see that - as I say above, the correct sequence is:
- host device resume
- calls mmc_resume_host()
- child's device resume (mmc_blk_resume)
- mmc_queue_resume()
Of course, I understand that this is a correct sequence. It simply was not
obvious to me that host
will
1 - 100 of 132 matches
Mail list logo
