|
From: Logan G. <log...@gm...> - 2006-01-12 02:47:47
|
Hello all. I am using valgrind 3.2.0 from SVN as of Friday 01/06/2006 on a PowerPC 440= GP Embedded Processor running kernel Linux 2.4.21. I have built valgrind on the board and am getting the following error when I run a decently heavy multi threaded (30 threads) application. I had to add support for a number of ioctl() calls but that went fairly easily thanks to the documentation -- however I am unable to continue debugging my program past this error. Any help / advice would be greatly appreciated. A strange note. When I build the application statically linked I still see the 'set address range perms' warning message (many many times)but did not get a 'the impossible' happened error -- I also got a (lot) of memory condition warnings but I am almost positive that is because the glibc suppression's are not being used for my statically linked executable. =3D=3D1953=3D=3D Warning: set address range perms: large range 4294960294, = a 0, v 0 =3D=3D1951=3D=3D Warning: set address range perms: large range 4294960294, = a 0, v 0 Memcheck: the 'impossible' happened: create_MAC_Chunk: shadow area is accessible =3D=3D1929=3D=3D at 0x70014FFC: report_and_quit (m_libcassert.c:136) =3D=3D1929=3D=3D by 0x700152E0: panic (m_libcassert.c:209) =3D=3D1929=3D=3D by 0x70015374: vgPlain_tool_panic (m_libcassert.c:224) =3D=3D1929=3D=3D by 0x70001E18: create_MAC_Chunk (mac_malloc_wrappers.c:= 145) =3D=3D1929=3D=3D by 0x700024F0: vgMAC_new_block (mac_malloc_wrappers.c:2= 00) =3D=3D1929=3D=3D by 0x7003DCF8: do_client_request (scheduler.c:984) =3D=3D1929=3D=3D by 0x7003D644: vgPlain_scheduler (scheduler.c:720) =3D=3D1929=3D=3D by 0x70053398: thread_wrapper (syswrap-linux.c:86) =3D=3D1929=3D=3D by 0x700534CC: run_a_thread_NORETURN (syswrap-linux.c:1= 19) =3D=3D1929=3D=3D by 0x7005361C: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:206) =3D=3D1929=3D=3D by 0x7005FE74: (within /usr/local/lib/valgrind/ppc32-li= nux/memcheck) =3D=3D1929=3D=3D by 0x26: ??? =3D=3D1929=3D=3D by 0x444E5CEC: ??? =3D=3D1929=3D=3D by 0x700635B0: myvprintf_str (m_debuglog.c:266) =3D=3D1929=3D=3D by 0x702283F4: ??? =3D=3D1929=3D=3D by 0xB57: ??? =3D=3D1929=3D=3D by 0xFFFFFFFE: ??? =3D=3D1929=3D=3D by 0x438FDC70: ??? =3D=3D1929=3D=3D by 0x28000080: ??? =3D=3D1929=3D=3D by 0x44415D84: ??? =3D=3D1929=3D=3D by 0x444E5CEC: ??? =3D=3D1929=3D=3D by 0x70016584: send_bytes_to_logging_sink (m_libcprint.= c:65) =3D=3D1929=3D=3D by 0x51: ??? -- Thanks; Logan Gabriel. |
|
From: Julian S. <js...@ac...> - 2006-01-12 02:59:02
|
> Memcheck: the 'impossible' happened: > create_MAC_Chunk: shadow area is accessible > ==1929== at 0x70014FFC: report_and_quit (m_libcassert.c:136) > ==1929== by 0x700152E0: panic (m_libcassert.c:209) is probably a side-effect of > ==1953== Warning: set address range perms: large range 4294960294, a 0, v 0 > ==1951== Warning: set address range perms: large range 4294960294, a 0, v 0 For some reason, valgrind is being told to mark almost the entirety of the process' address space as accessible. One place where address space permissions are changed is in syscall wrappers. Note that 4294960294 differs from 2^32 by just 7002 (iow, it's (unsigned int)(-7002))). Is it possible that your ioctl wrappers have some signedness error which is causing -7002 rather than 7002 to be passed as a length in POST_MEM_WRITE (not sure of the name) or similar macros in your ioctl wrappers? J |
|
From: Logan G. <log...@gm...> - 2006-01-12 04:27:06
|
I'm not sure if this helps or not but I saw the large range 4294960294
before I wrote the ioctl wrappers. The ioctl wrappers do not actually
use the POST/PRE MEM_WRITE -- the ioctl's
do not actually use (read from or write to) the third param.
The real ioctl's are:
#define XX_IOCTL_1 _IO (0xE7, 0x00)
#define XX_IOCTL_2 _IO (0xE7, 0x01)
#define XX_IOCTL_3 _IO (0xE7, 0x06)
#define XX_IOCTL_4 _IO (0xE7, 0x07)
.... and so on.
The code I added was in:
coregrind/m_syswrap/syswrap-generic.c:
#define VKI_XX_IOCTL_1 _VKI_IO(0xE7, 0x00)
#define VKI_XX_IOCTL_2 _VKI_IO(0xE7, 0x01)
#define VKI_XX_IOCTL_3 _VKI_IO(0xE7, 0x06)
#define VKI_XX_IOCTL_4 _VKI_IO(0xE7, 0x07)
PRE(sys_ioctl)
{
....
switch (ARG2 /* request */) {
case VKI_XX_IOCTL_1:
case VKI_XX_IOCTL_2:
case VKI_XX_IOCTL_3:
case VKI_XX_IOCTL_4:
break;
....
}
However I (just now) noticed that in my haste to leave the office at a
decent hour (before 9pm) I forgot to add cases to POST(sys_ioctl).
Would this still be an issue --- even knowing that the ioctl's do not
read from or write to the third param?
On 1/11/06, Julian Seward <js...@ac...> wrote:
>
> > Memcheck: the 'impossible' happened:
> > create_MAC_Chunk: shadow area is accessible
> > =3D=3D1929=3D=3D at 0x70014FFC: report_and_quit (m_libcassert.c:136)
> > =3D=3D1929=3D=3D by 0x700152E0: panic (m_libcassert.c:209)
>
> is probably a side-effect of
>
> > =3D=3D1953=3D=3D Warning: set address range perms: large range 42949602=
94, a 0, v 0
> > =3D=3D1951=3D=3D Warning: set address range perms: large range 42949602=
94, a 0, v 0
>
> For some reason, valgrind is being told to mark almost the entirety
> of the process' address space as accessible. One place where address
> space permissions are changed is in syscall wrappers.
>
> Note that 4294960294 differs from 2^32 by just 7002 (iow, it's
> (unsigned int)(-7002))). Is it possible that your ioctl wrappers have
> some signedness error which is causing -7002 rather than 7002 to
> be passed as a length in POST_MEM_WRITE (not sure of the name) or similar
> macros in your ioctl wrappers?
>
> J
>
--
Thanks;
Logan Gabriel.
|
|
From: Julian S. <js...@ac...> - 2006-01-12 11:48:05
|
> I'm not sure if this helps or not but I saw the large range 4294960294 > before I wrote the ioctl wrappers. Ok, so it's a pre-existing bug :-) Perhaps an endianness thing -- the ppc port hasn't been hammered as much as the x86/amd64 ports. > > > ==1953== Warning: set address range perms: large range 4294960294, We need to know why this happened. Can you find the place this is printed (mc_main.c, around about line 490) and put "tl_assert(0)" immediately after it; rebuild; rerun. This should give a backtrace showing how V got there. My feeling is (and this could be wrong) that once we know that, the bug should be relatively simple to fix. Alternatively .. make a simple C test program which shows the problem and can be examined at this end. J |
|
From: Logan G. <log...@gm...> - 2006-01-12 17:49:40
|
Here is the output: =3D=3D2272=3D=3D Warning: set address range perms: large range 4294960294, = a 0, v 0 Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible' happene= d. =3D=3D2272=3D=3D at 0x70015010: report_and_quit (m_libcassert.c:136) =3D=3D2272=3D=3D by 0x70015260: vgPlain_assert_fail (m_libcassert.c:199) =3D=3D2272=3D=3D by 0x70003E7C: set_address_range_perms (mc_main.c:573) =3D=3D2272=3D=3D by 0x7004E448: vgSysWrap_generic_sys_read_after (priv_types_n_macros.h:249) =3D=3D2272=3D=3D by 0x7005236C: vgPlain_post_syscall (syswrap-main.c:934= ) =3D=3D2272=3D=3D by 0x7005213C: vgPlain_client_syscall (syswrap-main.c:8= 60) =3D=3D2272=3D=3D by 0x7003D268: handle_syscall (scheduler.c:624) =3D=3D2272=3D=3D by 0x7003D670: vgPlain_scheduler (scheduler.c:725) =3D=3D2272=3D=3D by 0x700533E0: thread_wrapper (syswrap-linux.c:86) =3D=3D2272=3D=3D by 0x70053514: run_a_thread_NORETURN (syswrap-linux.c:1= 19) =3D=3D2272=3D=3D by 0x70053664: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:206) =3D=3D2272=3D=3D by 0x7005FEBC: (within /usr/local/lib/valgrind/ppc32-li= nux/memcheck) =3D=3D2272=3D=3D by 0x44887A1C: ??? =3D=3D2272=3D=3D by 0x700635F8: myvprintf_str (m_debuglog.c:266) On 1/12/06, Julian Seward <js...@ac...> wrote: > > > I'm not sure if this helps or not but I saw the large range 4294960294 > > before I wrote the ioctl wrappers. > > Ok, so it's a pre-existing bug :-) Perhaps an endianness thing -- the > ppc port hasn't been hammered as much as the x86/amd64 ports. > > > > > =3D=3D1953=3D=3D Warning: set address range perms: large range 4294= 960294, > > We need to know why this happened. Can you find the place this is > printed (mc_main.c, around about line 490) and put "tl_assert(0)" > immediately after it; rebuild; rerun. This should give a backtrace showi= ng > how V got there. My feeling is (and this could be wrong) that once > we know that, the bug should be relatively simple to fix. > > Alternatively .. make a simple C test program which shows the problem > and can be examined at this end. > > J > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Thanks; Logan Gabriel. |
|
From: Julian S. <js...@ac...> - 2006-01-12 17:59:44
|
> ==2272== Warning: set address range perms: large range 4294960294, a 0, v 0 > > Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible' > happened. ==2272== at 0x70015010: report_and_quit (m_libcassert.c:136) > ==2272== by 0x70015260: vgPlain_assert_fail (m_libcassert.c:199) > ==2272== by 0x70003E7C: set_address_range_perms (mc_main.c:573) > ==2272== by 0x7004E448: vgSysWrap_generic_sys_read_after > (priv_types_n_macros.h:249) > ==2272== by 0x7005236C: vgPlain_post_syscall (syswrap-main.c:934) > ==2272== by 0x7005213C: vgPlain_client_syscall (syswrap-main.c:860) > ==2272== by 0x7003D268: handle_syscall (scheduler.c:624) > ==2272== by 0x7003D670: vgPlain_scheduler (scheduler.c:725) > ==2272== by 0x700533E0: thread_wrapper (syswrap-linux.c:86) > ==2272== by 0x70053514: run_a_thread_NORETURN (syswrap-linux.c:119) > ==2272== by 0x70053664: vgModuleLocal_start_thread_NORETURN Well, umm. The problem is certainly syscall related, but this stack trace lacks the critical frame which would indicate which syscall it is. (What was really called from syswrap-main.c:934?) Can you rerun with --trace-syscalls=yes. This should give an strace-style log of syscalls. Just send the couple of lines prior to the "Warning" line. J |
|
From: Julian S. <js...@ac...> - 2006-01-12 18:12:45
|
Cancel that last message - I didn't read the backtrace carefully
enough. It's handling a read syscall, but what _seems_ (note,
superficial analysis :-) to be happening is that the kernel is
saying the syscall succeeded and read -7002 bytes of data. Cool.
The immediate trigger of the problem is this
POST(sys_read)
{
vg_assert(SUCCESS);
POST_MEM_WRITE( ARG2, RES );
}
(syswrap-generic.c:4785). What happens if you change "RES" to
"0x7FFFFFFF & (RES)" ?
J
> > Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible'
> > happened. ==2272== at 0x70015010: report_and_quit (m_libcassert.c:136)
> > ==2272== by 0x70015260: vgPlain_assert_fail (m_libcassert.c:199)
> > ==2272== by 0x70003E7C: set_address_range_perms (mc_main.c:573)
> > ==2272== by 0x7004E448: vgSysWrap_generic_sys_read_after
> > (priv_types_n_macros.h:249)
> > ==2272== by 0x7005236C: vgPlain_post_syscall (syswrap-main.c:934)
> > ==2272== by 0x7005213C: vgPlain_client_syscall (syswrap-main.c:860)
> > ==2272== by 0x7003D268: handle_syscall (scheduler.c:624)
> > ==2272== by 0x7003D670: vgPlain_scheduler (scheduler.c:725)
> > ==2272== by 0x700533E0: thread_wrapper (syswrap-linux.c:86)
> > ==2272== by 0x70053514: run_a_thread_NORETURN (syswrap-linux.c:119)
> > ==2272== by 0x70053664: vgModuleLocal_start_thread_NORETURN
>
> Well, umm. The problem is certainly syscall related, but this stack
> trace lacks the critical frame which would indicate which syscall it
> is. (What was really called from syswrap-main.c:934?)
>
> Can you rerun with --trace-syscalls=yes. This should give an
> strace-style log of syscalls. Just send the couple of lines
> prior to the "Warning" line.
>
> J
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Logan G. <log...@gm...> - 2006-01-12 19:21:17
|
Yes that is correct, The system call is returning -7002 in one
condition.... and -7001 in a different condition. I will go change
the code and re run in an hour or two after lunch... thanks for the
prompt replies =3D).
On 1/12/06, Julian Seward <js...@ac...> wrote:
>
> Cancel that last message - I didn't read the backtrace carefully
> enough. It's handling a read syscall, but what _seems_ (note,
> superficial analysis :-) to be happening is that the kernel is
> saying the syscall succeeded and read -7002 bytes of data. Cool.
>
> The immediate trigger of the problem is this
>
> POST(sys_read)
> {
> vg_assert(SUCCESS);
> POST_MEM_WRITE( ARG2, RES );
> }
>
> (syswrap-generic.c:4785). What happens if you change "RES" to
> "0x7FFFFFFF & (RES)" ?
>
> J
>
>
> > > Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible'
> > > happened. =3D=3D2272=3D=3D at 0x70015010: report_and_quit (m_libca=
ssert.c:136)
> > > =3D=3D2272=3D=3D by 0x70015260: vgPlain_assert_fail (m_libcassert.=
c:199)
> > > =3D=3D2272=3D=3D by 0x70003E7C: set_address_range_perms (mc_main.c=
:573)
> > > =3D=3D2272=3D=3D by 0x7004E448: vgSysWrap_generic_sys_read_after
> > > (priv_types_n_macros.h:249)
> > > =3D=3D2272=3D=3D by 0x7005236C: vgPlain_post_syscall (syswrap-main=
.c:934)
> > > =3D=3D2272=3D=3D by 0x7005213C: vgPlain_client_syscall (syswrap-ma=
in.c:860)
> > > =3D=3D2272=3D=3D by 0x7003D268: handle_syscall (scheduler.c:624)
> > > =3D=3D2272=3D=3D by 0x7003D670: vgPlain_scheduler (scheduler.c:725=
)
> > > =3D=3D2272=3D=3D by 0x700533E0: thread_wrapper (syswrap-linux.c:86=
)
> > > =3D=3D2272=3D=3D by 0x70053514: run_a_thread_NORETURN (syswrap-lin=
ux.c:119)
> > > =3D=3D2272=3D=3D by 0x70053664: vgModuleLocal_start_thread_NORETUR=
N
> >
> > Well, umm. The problem is certainly syscall related, but this stack
> > trace lacks the critical frame which would indicate which syscall it
> > is. (What was really called from syswrap-main.c:934?)
> >
> > Can you rerun with --trace-syscalls=3Dyes. This should give an
> > strace-style log of syscalls. Just send the couple of lines
> > prior to the "Warning" line.
> >
> > J
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files for problems? Stop! Download the new AJAX search engine that ma=
kes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
Thanks;
Logan Gabriel.
|
|
From: Logan G. <log...@gm...> - 2006-01-12 20:37:11
|
=3D=3D1319=3D=3D Warning: set address range perms: large range 2147476646, =
a 0, v 0
Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible' happene=
d.
=3D=3D1319=3D=3D at 0x70015010: report_and_quit (m_libcassert.c:136)
=3D=3D1319=3D=3D by 0x70015260: vgPlain_assert_fail (m_libcassert.c:199)
=3D=3D1319=3D=3D by 0x70003E7C: set_address_range_perms (mc_main.c:573)
=3D=3D1319=3D=3D by 0x7004E44C: vgSysWrap_generic_sys_read_after
(priv_types_n_macros.h:249)
=3D=3D1319=3D=3D by 0x70052370: vgPlain_post_syscall (syswrap-main.c:934=
)
=3D=3D1319=3D=3D by 0x70052140: vgPlain_client_syscall (syswrap-main.c:8=
60)
=3D=3D1319=3D=3D by 0x7003D268: handle_syscall (scheduler.c:624)
=3D=3D1319=3D=3D by 0x7003D670: vgPlain_scheduler (scheduler.c:725)
=3D=3D1319=3D=3D by 0x700533E4: thread_wrapper (syswrap-linux.c:86)
=3D=3D1319=3D=3D by 0x70053518: run_a_thread_NORETURN (syswrap-linux.c:1=
19)
=3D=3D1319=3D=3D by 0x70053668: vgModuleLocal_start_thread_NORETURN
(syswrap-linux.c:206)
=3D=3D1319=3D=3D by 0x7005FEC0: (within /usr/local/lib/valgrind/ppc32-li=
nux/memcheck)
=3D=3D1319=3D=3D by 0x4483BA1C: ???
On 1/12/06, Logan Gabriel <log...@gm...> wrote:
> Yes that is correct, The system call is returning -7002 in one
> condition.... and -7001 in a different condition. I will go change
> the code and re run in an hour or two after lunch... thanks for the
> prompt replies =3D).
>
> On 1/12/06, Julian Seward <js...@ac...> wrote:
> >
> > Cancel that last message - I didn't read the backtrace carefully
> > enough. It's handling a read syscall, but what _seems_ (note,
> > superficial analysis :-) to be happening is that the kernel is
> > saying the syscall succeeded and read -7002 bytes of data. Cool.
> >
> > The immediate trigger of the problem is this
> >
> > POST(sys_read)
> > {
> > vg_assert(SUCCESS);
> > POST_MEM_WRITE( ARG2, RES );
> > }
> >
> > (syswrap-generic.c:4785). What happens if you change "RES" to
> > "0x7FFFFFFF & (RES)" ?
> >
> > J
> >
> >
> > > > Memcheck: mc_main.c:584 (set_address_range_perms): the 'impossible'
> > > > happened. =3D=3D2272=3D=3D at 0x70015010: report_and_quit (m_lib=
cassert.c:136)
> > > > =3D=3D2272=3D=3D by 0x70015260: vgPlain_assert_fail (m_libcasser=
t.c:199)
> > > > =3D=3D2272=3D=3D by 0x70003E7C: set_address_range_perms (mc_main=
.c:573)
> > > > =3D=3D2272=3D=3D by 0x7004E448: vgSysWrap_generic_sys_read_after
> > > > (priv_types_n_macros.h:249)
> > > > =3D=3D2272=3D=3D by 0x7005236C: vgPlain_post_syscall (syswrap-ma=
in.c:934)
> > > > =3D=3D2272=3D=3D by 0x7005213C: vgPlain_client_syscall (syswrap-=
main.c:860)
> > > > =3D=3D2272=3D=3D by 0x7003D268: handle_syscall (scheduler.c:624)
> > > > =3D=3D2272=3D=3D by 0x7003D670: vgPlain_scheduler (scheduler.c:7=
25)
> > > > =3D=3D2272=3D=3D by 0x700533E0: thread_wrapper (syswrap-linux.c:=
86)
> > > > =3D=3D2272=3D=3D by 0x70053514: run_a_thread_NORETURN (syswrap-l=
inux.c:119)
> > > > =3D=3D2272=3D=3D by 0x70053664: vgModuleLocal_start_thread_NORET=
URN
> > >
> > > Well, umm. The problem is certainly syscall related, but this stack
> > > trace lacks the critical frame which would indicate which syscall it
> > > is. (What was really called from syswrap-main.c:934?)
> > >
> > > Can you rerun with --trace-syscalls=3Dyes. This should give an
> > > strace-style log of syscalls. Just send the couple of lines
> > > prior to the "Warning" line.
> > >
> > > J
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through lo=
g
> > > files for problems? Stop! Download the new AJAX search engine that =
makes
> > > searching your log files as easy as surfing the web. DOWNLOAD SPLUN=
K!
> > > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > > _______________________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
>
>
> --
> Thanks;
> Logan Gabriel.
>
--
Thanks;
Logan Gabriel.
|
|
From: Julian S. <js...@ac...> - 2006-01-12 20:54:09
|
> ==1319== Warning: set address range perms: large range 2147476646, a 0, v 0 Yeh. That's because I suggested the wrong thing. RES is the result of the syscall (-7002) and the POST_MEM_WRITE is calling set_address_range_perms. What I should have said is - try the absolute value of RES: ( ((Int)RES) < 0 : -(RES) : (RES) ) > > Yes that is correct, The system call is returning -7002 in one > > condition.... and -7001 in a different condition. Nevertheless I don't understand how read() can succeed and return a negative value. J |
|
From: Logan G. <log...@gm...> - 2006-01-12 20:56:16
|
I think your patch will work -- I added code to do a specific check for -7002 and post a 0 byte memory write and that has worked around the issue. The reason the read is returning a -7002 is the (custom) hardware driver was written to return -7002 as a status value in a certain condition. A more standard way would have been to write to the third ioctl param but that was not done =3D). Thanks a lot for the help I can continue to debug my application now =3D) On 1/12/06, Julian Seward <js...@ac...> wrote: > > > =3D=3D1319=3D=3D Warning: set address range perms: large range 21474766= 46, a 0, v 0 > > Yeh. That's because I suggested the wrong thing. RES is the result of > the syscall (-7002) and the POST_MEM_WRITE is calling set_address_range_p= erms. > > What I should have said is - try the absolute value of RES: > > ( ((Int)RES) < 0 : -(RES) : (RES) ) > > > > Yes that is correct, The system call is returning -7002 in one > > > condition.... and -7001 in a different condition. > > Nevertheless I don't understand how read() can succeed and return a > negative value. > > J > -- Thanks; Logan Gabriel. |
|
From: Igmar P. <mai...@jd...> - 2006-01-13 13:21:53
|
> I think your patch will work -- I added code to do a specific check > for -7002 and post a 0 byte memory write and that has worked around > the issue. The reason the read is returning a -7002 is the (custom) > hardware driver was written to return -7002 as a status value in a > certain condition. Please mention this information in your startpost next time; using non-default error codes will definitely lead to buggy userspace code. I would suggest rewriting the driver to do the proper thing (that is, return a standard error code, and write an ioctl() to retrieve the driver-specific error code. Regards, Igmar |
|
From: Dirk M. <dm...@gm...> - 2006-01-13 08:45:27
|
On Thursday 12 January 2006 21:56, Logan Gabriel wrote: > I think your patch will work -- I added code to do a specific check > for -7002 and post a 0 byte memory write and that has worked around > the issue. The reason the read is returning a -7002 is the (custom) > hardware driver was written to return -7002 as a status value in a > certain condition. Oh, thats invalid though. Error return values are guaranteed to be in the range of -4095..-1. Dirk |
|
From: Tom H. <to...@co...> - 2006-01-13 08:53:37
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Thursday 12 January 2006 21:56, Logan Gabriel wrote:
>
>> I think your patch will work -- I added code to do a specific check
>> for -7002 and post a 0 byte memory write and that has worked around
>> the issue. The reason the read is returning a -7002 is the (custom)
>> hardware driver was written to return -7002 as a status value in a
>> certain condition.
>
> Oh, thats invalid though. Error return values are guaranteed to be in the
> range of -4095..-1.
On x86 and amd64 they are - on PPC the error flag is out of band so
there are no reserved error values.
It certainly sounds like the driver is doing something completely
bogus though.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|