bug in asm-ppc/div64.h

bug in asm-ppc/div64.h

[Bastien Nocera]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

Hello,

While chasing a date bug in smbfs with Urban Widmark, it so happened
that we stumbled across a bug in do_div on PPC 32bit, ie. it doesn't
work.

I attached a test case, provided by Urban. do_div is used in quite a few
places like vsprintf, the matrox fb code, etc.

When running on x86:
now: 1047238073
adjusted: 24edd64059e100
/ 10000000: 3df4e80a
1039460362

Check the run on PPC. It's wrong by quite a scale.

Any ideas on how to solve this properly ?

Cheers

--
/Bastien Nocera
http://www.redhat.com

Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away.
                                                Antoine de Saint-Exupery
--
/Bastien Nocera
http://hadess.net

#2  0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from
/lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity);
Segmentation fault

[-- Attachment #2: smbfs-time.c --]
[-- Type: text/x-c, Size: 550 bytes --]

#include <stdio.h>
#include <time.h>
#include <asm/types.h>
#include <asm/div64.h>

typedef  __u64 u64;

#define NTFS_TIME_OFFSET ((u64)(369*365 + 89) * 24 * 3600 * 10000000)

static time_t
smb_ntutc2unixutc(u64 ntutc)
{
	u64 t = ntutc - NTFS_TIME_OFFSET;
	printf("adjusted: %Lx\n", t);

	do_div(t, 10000000);
	printf("/ 10000000: %Lx\n", t);

	return (time_t)t;
}

int main()
{
    time_t t;

    t = time(NULL);
    printf("now: %ld\n", t);

    t = smb_ntutc2unixutc(0x01c29fb515986100LL);
    printf("%ld\n", t);
}

Debugging

[Giuliano Pochini]

Does xmon work ?  When something oopses I see the xmon prompt, but
I can't type anything - machine completely freezed. SysReq commands
also are disabled and I must hit the hard reset button.
I disabled xmon so oops messages show up on the console and in the
logs, but I have problems with them too. ksymoops spits a lot of
warnings about non-matching addresses, etc. and the function where
the oops occurred is always "may not be reliable". To locate the
bug I put a lot of printk in my driver and - murphy's surprise -
oopses do not have a backtrace anymore, just one unresolvable
address. #:-6
I'm using 2.4.21p4 on a blue G3. I recompiled Kernel, modules, ALSA
to be sure System.map is the right one.

Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Debugging

[Olaf Hering]

 On Tue, Mar 11, Giuliano Pochini wrote:

> I'm using 2.4.21p4 on a blue G3. I recompiled Kernel, modules, ALSA
> to be sure System.map is the right one.

Get an ADB keyboard and use that for xmon.


--
A: No.
Q: Should I include quotations after my reply?

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Debugging

[Giuliano Pochini]

On 11-Mar-2003 Olaf Hering wrote:
>
>  On Tue, Mar 11, Giuliano Pochini wrote:
>
>> I'm using 2.4.21p4 on a blue G3. I recompiled Kernel, modules, ALSA
>> to be sure System.map is the right one.
>
> Get an ADB keyboard and use that for xmon.

:( I sold it a few months ago. Can macs without ADB run xmon ?


Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Debugging

[Olaf Hering]

 On Thu, Mar 13, Giuliano Pochini wrote:

>
> On 11-Mar-2003 Olaf Hering wrote:
> >
> >  On Tue, Mar 11, Giuliano Pochini wrote:
> >
> >> I'm using 2.4.21p4 on a blue G3. I recompiled Kernel, modules, ALSA
> >> to be sure System.map is the right one.
> >
> > Get an ADB keyboard and use that for xmon.
>
> :( I sold it a few months ago. Can macs without ADB run xmon ?

Via Firewire maybe, but your onboard pcilynx controller ist not supported.

--
A: No.
Q: Should I include quotations after my reply?

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

debugging..

[Ingo Flaschberger]

Hey...

i have a system where i can't set the kernel command-line... searching for
"debug" about an hour did not help..(

how else could i get debugging infos (i have already modified
kernel/printk.c).

thnx & bye, Ingo

--
we own the fibre; 9.6.98 illiad

Debugging

[techmail]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

Hi,

 

Perhaps this is a stupid question which has been asked too many times,
but I wasn't able to find it.

 

If I do "service iptables start" nothing happens, so when I do "service
iptables status" it says "Firewall is stopped."

 

Because I want to know where in the process the error is I'd like to
know how to debug it. Is there any information on debugging to see what
error it displays?

 

Kind regards,

 

Robert Hazenveld


[-- Attachment #2: Type: text/html, Size: 2663 bytes --]

RE: Debugging

[Daniel Chemko]

This is a redhat bug, not netfilter.

If you are adept at bash scripting, you may want to try bash -x service firewall start.

Enjoy!



-----Original Message-----
From:	techmail@safe2surf.nl [mailto:techmail@safe2surf.nl]
Sent:	Sun 10/19/2003 3:24 PM
To:	netfilter@lists.netfilter.org
Cc:	
Subject:	Debugging
Hi,

 

Perhaps this is a stupid question which has been asked too many times,
but I wasn't able to find it.

 

If I do "service iptables start" nothing happens, so when I do "service
iptables status" it says "Firewall is stopped."

 

Because I want to know where in the process the error is I'd like to
know how to debug it. Is there any information on debugging to see what
error it displays?

 

Kind regards,

 

Robert Hazenveld

RE: Debugging

[techmail]

[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]

That did the trick. Stupid not to notice it, but indeed, the iptables
file wasn't present in /etc/sysconfig, so I did "service iptables save"
and it saved the ruleset (which is non-existent atm). Afterwards the
service came online as expected. Now I can get back to learning how to
write the rules ;-)

 

Thanks!

 

Robert Hazenveld

 

-----Original Message-----
From: George Vieira [mailto:georgev@citadelcomputer.com.au] 
Sent: maandag 20 oktober 2003 0:41
To: techmail@safe2surf.nl
Subject: RE: Debugging

 

vi /etc/init.d/iptables

 

check inside for anything it's testing for to exist before it'll even
run the script.

From memory it checks for /etc/sysconfig/iptables file which contains
the rules you want to add to the machine, if this doesn't exist then the
script stops..

 

I would remove all of the script contents and write your own iptables
script, it's not hard once you know exaclty what you want for a
firewall..

 

Thanks,

 

____________________________________________
George Vieira
Citadel Computer Systems Pty Ltd   Systems Manager   georgev AT
citadelcomputer DOT com DOT au   

Citadel Computer Systems Pty Ltd

Phone : +61 2 9955 2644   HelpDesk: +61 2 9955 2698
<http://www.citadelcomputer.com.au/>  http://www.citadelcomputer.com.au
<http://www.citadelcomputer.com.au/>  

 

 

-----Original Message-----
From: techmail@safe2surf.nl [mailto:techmail@safe2surf.nl]
Sent: Monday, 20 October 2003 8:24 AM
To: netfilter@lists.netfilter.org
Subject: Debugging

Hi,

 

Perhaps this is a stupid question which has been asked too many times,
but I wasn't able to find it.

 

If I do "service iptables start" nothing happens, so when I do "service
iptables status" it says "Firewall is stopped."

 

Because I want to know where in the process the error is I'd like to
know how to debug it. Is there any information on debugging to see what
error it displays?

 

Kind regards,

 

Robert Hazenveld


[-- Attachment #2: Type: text/html, Size: 11461 bytes --]

Debugging

[Scott Becker]

On the two servers I've installed RHEL 4 on, I've had trouble with grub. 
It's the combination of grub and the new I2O_block driver. I suspect the 
grub patch to support I2O is lacking.

I was wondering if Grub 0.95 or 2.0 has a facility to trace the changes 
being made when grub-install is being ran. After an install or an update 
I had to run grub-install to get it to boot again. In theory, this 
shouldn't be neccessary. Since it was, I thought it would be useful to 
be able to compare the areas of the disk written to during grub-install 
with what was written there before so that I could trace down the problem.

    thanks
    scottb

Re: Debugging

[Hollis Blanchard]

On May 13, 2005, at 7:05 PM, Scott Becker wrote:

> On the two servers I've installed RHEL 4 on, I've had trouble with 
> grub. It's the combination of grub and the new I2O_block driver. I 
> suspect the grub patch to support I2O is lacking.

Are you referring to a particular patch?

> I was wondering if Grub 0.95 or 2.0 has a facility to trace the 
> changes being made when grub-install is being ran. After an install or 
> an update I had to run grub-install to get it to boot again. In 
> theory, this shouldn't be neccessary. Since it was, I thought it would 
> be useful to be able to compare the areas of the disk written to 
> during grub-install with what was written there before so that I could 
> trace down the problem.

I don't see anything like that in GRUB2's grub-setup.c, but it is a 
good idea.

I also don't see anything like that in GRUB Legacy's "grub". You could 
always strace...

-Hollis

Re: Debugging

[Scott Becker]

I'm not familiar with strace (I'm just an imaging app programmer [on doze]).

The patch I'm referring to is on this page:
http://i2o.shadowconnect.com/download.php

I believe that since RH now defaults to using I2O_block for raid 
controllers instead of dpt_i2o from adaptec, then their shipping version 
of grub would have this patch applied.

Perhaps the patch could be reviewed, fixed and applied to GRUB2 and 
Legacy by folks who know grub (not I).

    thanks
    scottb


Hollis Blanchard wrote:

> On May 13, 2005, at 7:05 PM, Scott Becker wrote:
>
>> On the two servers I've installed RHEL 4 on, I've had trouble with 
>> grub. It's the combination of grub and the new I2O_block driver. I 
>> suspect the grub patch to support I2O is lacking.
>
>
> Are you referring to a particular patch?
>
>> I was wondering if Grub 0.95 or 2.0 has a facility to trace the 
>> changes being made when grub-install is being ran. After an install 
>> or an update I had to run grub-install to get it to boot again. In 
>> theory, this shouldn't be neccessary. Since it was, I thought it 
>> would be useful to be able to compare the areas of the disk written 
>> to during grub-install with what was written there before so that I 
>> could trace down the problem.
>
>
> I don't see anything like that in GRUB2's grub-setup.c, but it is a 
> good idea.
>
> I also don't see anything like that in GRUB Legacy's "grub". You could 
> always strace...
>
> -Hollis
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Debugging

[pjones]

On Wed, 2005-05-18 at 08:59 -0700, Scott Becker wrote:
> I'm not familiar with strace (I'm just an imaging app programmer [on doze]).
> 
> The patch I'm referring to is on this page:
> http://i2o.shadowconnect.com/download.php
> 
> I believe that since RH now defaults to using I2O_block for raid 
> controllers instead of dpt_i2o from adaptec, then their shipping version 
> of grub would have this patch applied.

We've got a similar patch, it's not actually this particular one.

-- 
  Peter

Debugging

[Lares Moreau]

OKay this is a noobie question,

I have all the kernel debugging options turned.  Now how do I change the
kernel logging level from prompt?  Or do I?

I have 'loglevel=7' appended to my kernel line in grub.  Is that all I
need or is there more to it?

Worry not I have syslog-ng setup properly

-Lares

Re: Debugging

[Randy.Dunlap]

On Fri, 9 Sep 2005, Lares Moreau wrote:

> OKay this is a noobie question,
>
> I have all the kernel debugging options turned.  Now how do I change the
> kernel logging level from prompt?  Or do I?
>
> I have 'loglevel=7' appended to my kernel line in grub.  Is that all I
> need or is there more to it?
>
> Worry not I have syslog-ng setup properly

'loglevel=7' should be sufficient, except that I have seen some
distro's init scripts change it during bootup, so just be aware
of that (or search for it).

I usually use loglevel or 8 or 9 (via alt-sysrq-N).  According to
Documentation/kernel-parameters.txt:
loglevel=	All Kernel Messages with a loglevel smaller than the
		console loglevel will be printed to the console.
so using a value of 7 would omit KERN_DEBUG messages.
		7 (KERN_DEBUG)		debug-level messages

-- 
~Randy

Debugging

[James Colannino]

Hey everyone.  I have a small program that I had written a while ago in 
C to help me study for my Spanish class.  I decided to rewrite some code 
recently being that I have a little more experience, and found that the 
program does not function properly when I compile with -O2 optimizations 
(I'm using GCC.)  It works as it should, however, when there are no 
optimizations.  How exactly should I go about debugging this and 
figuring out what code is causing the problem?  I could compile it with 
the -g option and feed it to GDB, but then doesn't debugging not work 
very well when you've done optimizations?  Is -O2 a low enough level of 
optimization that I shouldn't have a problem?  Debugging is one of the 
many things I know extremely little about, so I'm very in the dark 
here.  Any input would be greatly appreciated :)  Thanks very much in 
advance.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"If Carpenters made houses the way programmers design programs, the first woodpecker to come along would destroy all of civilization." --Computer Proverb

Re: Debugging

[Steve Graegert]

On 1/29/06, James Colannino <james@colannino.org> wrote:
> Hey everyone.  I have a small program that I had written a while ago in
> C to help me study for my Spanish class.  I decided to rewrite some code
> recently being that I have a little more experience, and found that the
> program does not function properly when I compile with -O2 optimizations
> (I'm using GCC.)  It works as it should, however, when there are no
> optimizations.  How exactly should I go about debugging this and
> figuring out what code is causing the problem?  I could compile it with
> the -g option and feed it to GDB, but then doesn't debugging not work
> very well when you've done optimizations?  Is -O2 a low enough level of
> optimization that I shouldn't have a problem?  Debugging is one of the
> many things I know extremely little about, so I'm very in the dark
> here.  Any input would be greatly appreciated :)  Thanks very much in
> advance.

James,

debugging optimized code is very difficult for the following reasons
(to name a few):

   - due to a technique known as "common subexpression elimination"
you may not be able to stop on certain statements, although you think
it should be possible.,
   - instruction scheduling causes statements (typically those
resulting in load/store operations as found in computations of values)
to be moved around, i.e. move them close to the location where they
are used,
   - sometimes similar code fragments are merged so that the program
counter jumps to unexpected locations (often seen with return or break
statements).

There are other anomalies you may encounter when debugging optimized
code and I therefore recommend to increase the level of optimization
step by step beginning with -O0 and then to debug at each level to
check for unexpected values of variables and other bogus behavior.  I
am sure the GCC/gdb manual will reveal some helpful information about
debugging.

	\Steve

--

Steve Graegert <graegerts@gmail.com>
Software Consultant {C/C++ && Java && .NET}
Office: +49 9131 7123988
Mobile: +49 1520 9289212

Re: Debugging

[Glynn Clements]

James Colannino wrote:

> Hey everyone.  I have a small program that I had written a while ago in 
> C to help me study for my Spanish class.  I decided to rewrite some code 
> recently being that I have a little more experience, and found that the 
> program does not function properly when I compile with -O2 optimizations 
> (I'm using GCC.)  It works as it should, however, when there are no 
> optimizations.  How exactly should I go about debugging this and 
> figuring out what code is causing the problem?  I could compile it with 
> the -g option and feed it to GDB, but then doesn't debugging not work 
> very well when you've done optimizations?  Is -O2 a low enough level of 
> optimization that I shouldn't have a problem?  Debugging is one of the 
> many things I know extremely little about, so I'm very in the dark 
> here.  Any input would be greatly appreciated :)  Thanks very much in 
> advance.

Debugging optimised code is hard, as many of the expressions and
variables which appear in the source code simply don't exist in the
optimised machine code.

One option is to identify exactly which optimisations are problematic
by enabling or disabling specific optimisations using the various -f
switches. That might give you some clues as to where the problems lie.

Probably the most common reasons for code breaking when optimisation
is enabled are aliasing bugs, i.e. where a storage location is
referenced in multiple ways. This is particularly common if you use
pointer type casts or "type-punning" (storing a value in one field of
a union then reading from another field with a different type). Try
using -fno-strict-aliasing to see if aliasing is the problem.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: Debugging

[James Colannino]

Glynn Clements wrote:

>One option is to identify exactly which optimisations are problematic
>by enabling or disabling specific optimisations using the various -f
>switches. That might give you some clues as to where the problems lie.
>  
>

That's an awesome idea.  Thank you.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"If Carpenters made houses the way programmers design programs, the first woodpecker to come along would destroy all of civilization." --Computer Proverb

Re: Debugging

[James Colannino]

Patrick Leslie Polzer wrote:

>First, define "does not function properly".  Does it dump code, is there a
>logic error?
>  
>

Sorry; I should have explained myself more clearly.  It's a logic error 
(I think.)  What's weird is that I ran strace to compare the various 
system calls used with the un-optimized version vs. the optimized 
version, and they were both the same up to the point where the optimized 
one failed.  Of course that isn't a reflection of the actual machine 
code, so I guess that wouldn't necessarily help me out too much.

>Then go about finding the offending line(s) of code.
>Watch out for obscure tricks, side-effects, wild pointers and illegal casts.
>Compile with -Wall and, to enforce your discipline, treat every warning as
>-Werror.
>  
>

Without -Wall, I get no errors (I always do my best to get rid of 
warnings.)  I'll try it with -Wall though and see what happens.

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"If Carpenters made houses the way programmers design programs, the first woodpecker to come along would destroy all of civilization." --Computer Proverb

Re: Debugging

[James Colannino]

James Colannino wrote:

>> Then go about finding the offending line(s) of code.
>> Watch out for obscure tricks, side-effects, wild pointers and illegal 
>> casts.
>> Compile with -Wall and, to enforce your discipline, treat every 
>> warning as
>> -Werror.
>
> Without -Wall, I get no errors (I always do my best to get rid of 
> warnings.)  I'll try it with -Wall though and see what happens.


*embarrased* using -Wall gave me the following error:

database.c:68: warning: implicit declaration of function `close'

That made me realize that I was trying to use the system call open 
instead of the standard library function fclose.  Once I fixed that, the 
code worked both when it was optimized and when it was not.  I think 
from now on I'll be using -Wall ;)  Thanks to everyone who responded.  
I'm glad I don't have to run this through a debugger....yet :)

James

-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

"If Carpenters made houses the way programmers design programs, the first woodpecker to come along would destroy all of civilization." --Computer Proverb