headers
wcohen at redhat dot com | 1 Jan 2007 17:51
Favicon

[Bug translator/3785] systmtap.sample/poll_map.stp dies on 2.6.18-1.2868.fc6 kernel


------- Additional Comments From wcohen at redhat dot com  2007-01-01 16:51 -------
This is an IBM T41 Thinkpad with a Pentium M processor running FC6 updated via
yum. The machine has has 512M of memory.

The problem is still triggered on the system with the latest checkout of systemtap:

BUG: unable to handle kernel NULL pointer dere8
 printing eip:                                                                  
c0460579                                                                        
*pde = 06579067                                                                 
Oops: 0000 [#1]                                                                 
SMP                                                                             
last sysfs file: /module/uhci_hcd/sections/.text                                
Modules linked in: stap_a058fcd7029f5c9bb738cfca0ac4c0fc_35799(U) autofs4 hidp d
CPU:    0                                                                       
EIP:    0060:[<c0460579>]    Not tainted VLI                                    
EFLAGS: 00210202   (2.6.18-1.2868.fc6 #1)

I don't yet have a kdump from the problem.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=3785

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
fche at redhat dot com | 1 Jan 2007 18:37
Favicon

[Bug translator/3785] systmtap.sample/poll_map.stp dies on 2.6.18-1.2868.fc6 kernel


------- Additional Comments From fche at redhat dot com  2007-01-01 17:37 -------
I added some text to http://sourceware.org/systemtap/wiki/HowToReportBugs to
help gather needed info.  See the bottom few points of 'System crashes'.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=3785

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
wcohen at redhat dot com | 1 Jan 2007 20:39
Favicon

[Bug translator/3785] systemtap.sample/poll_map.stp dies on 2.6.18-1.2868.fc6 kernel


------- Additional Comments From wcohen at redhat dot com  2007-01-01 19:39 -------
I have thought about this a bit more and I am wondering if the elfutils-0.123 on
the fc6 machine might be causing the problem. The systemtap is built using
elfutils 0.124 and has it's own shared library installed in a local directory.

Looking at the position of the EIP it looks like it is in sys_munlockall of this
kernel. However, having a probe that only instruments that one function doesn't
crash. The probe is set at 0xc046054aUL the EIP is reported at c0460579:

c0460549 <sys_munlockall>:
c0460549:	53                   	push   %ebx
c046054a:	89 e0                	mov    %esp,%eax
c046054c:	25 00 f0 ff ff       	and    $0xfffff000,%eax
c0460551:	8b 00                	mov    (%eax),%eax
c0460553:	8b 80 84 00 00 00    	mov    0x84(%eax),%eax
c0460559:	83 c0 38             	add    $0x38,%eax
c046055c:	e8 e7 8e fd ff       	call   c0439448 <down_write>
c0460561:	31 c0                	xor    %eax,%eax
c0460563:	e8 65 fd ff ff       	call   c04602cd <do_mlockall>
c0460568:	89 c3                	mov    %eax,%ebx
c046056a:	89 e0                	mov    %esp,%eax
c046056c:	25 00 f0 ff ff       	and    $0xfffff000,%eax
c0460571:	8b 00                	mov    (%eax),%eax
c0460573:	8b 80 84 00 00 00    	mov    0x84(%eax),%eax
c0460579:	83 c0 38             	add    $0x38,%eax
c046057c:	e8 b1 8e fd ff       	call   c0439432 <up_write>
c0460581:	89 d8                	mov    %ebx,%eax
c0460583:	5b                   	pop    %ebx
c0460584:	c3                   	ret
(Continue reading)

Permalink | Reply | 0 comments |
headers
wcohen at redhat dot com | 1 Jan 2007 21:10
Favicon

[Bug translator/3785] systemtap.sample/poll_map.stp dies on 2.6.18-1.2868.fc6 kernel


------- Additional Comments From wcohen at redhat dot com  2007-01-01 20:10 -------
Get exactly the same crash with using the stock systemtap rpm with the
poll_map.stp. The machine has virtually no load on it when the example is run
(and crashes).  This machine is normal installation of fedora core 6 updated
with "yum update". What was the i686 configuration used to attempt to replicate
this problem? Below are details about the machine.

$ rpm -q systemtap gcc elfutils
systemtap-0.5.10-1.fc6
gcc-4.1.1-30
elfutils-0.123-1.fc6
$ uname -a
Linux montague.devel.redhat.com 2.6.18-1.2868.fc6 #1 SMP Fri Dec 15 17:31:29 EST
2006 i686 i686 i386 GNU/Linux
[wcohen <at> montague systemtap.samples]$ more /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Pentium(R) M processor 1600MHz
stepping        : 5
cpu MHz         : 1594.855
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
(Continue reading)

Permalink | Reply | 4 comments |
headers
fche at redhat dot com | 2 Jan 2007 06:08
Favicon

[Bug releng/3519] collect useful sample scripts


------- Additional Comments From fche at redhat dot com  2007-01-02 05:08 -------
A few samples from the wiki now grace src/examples.
It's just a start though.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=3519

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
wcohen at redhat dot com | 2 Jan 2007 22:31
Favicon

[Bug translator/3785] systemtap.sample/poll_map.stp dies on 2.6.18-1.2868.fc6 kernel


------- Additional Comments From wcohen at redhat dot com  2007-01-02 21:31 -------
The stock kdump in the fc6 doesn't work with Pentium M because the processor
doesn't have the PAE support and the fc6 kernel-kdump requires PAE support. :(

Suspect the problem is related to Pentium M or the laptop environment.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=3785

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
fche at redhat dot com | 3 Jan 2007 16:17
Favicon

[Bug translator/3823] New: internationalize the thing

use gettext or another library for translator strings
investigate what to do with respect to scripts / tapsets

--

-- 
           Summary: internationalize the thing
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P3
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com

http://sourceware.org/bugzilla/show_bug.cgi?id=3823

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
Quentin Barnes | 3 Jan 2007 23:39
Picon

Re: boosting with preemptable kernel

>Hi Quentin,
>
>Actually, I discussed a similar idea internally with Satoshi.
>And we decided the current approach is better than that, because,
>
>Trampoline approach
>- depends on the architecture. not general solution.
>- increases overhead by executing trampoline code.
>- is useful ONLY for booster, but is NOT useful for djprobe.
>
>Garbage Collector (and Safety check routine)
>- does NOT depends on the architecture.
>- does NOT increase overhead when probing.
>- is useful for not only booster but also djprobe.
>
>Thus, I posted GC patch, and it was merged to -mm tree.
>http://sources.redhat.com/ml/systemtap/2006-q4/msg00453.html
>
>And, I know there is a weak point in the GC. It will take
>a time to freeze processes. But I tried to reduce the
>frequency of executing the GC by using the "dirty" flag and
>some conditions. I also think we can control when it
>works by introducing commit_kprobes() interface.
>
>> (If you'd like, you can copy any or all of this post to the
>> systemtap mailing list.)
>
>Thanks, I Cc this to the SystemTap ML.

I didn't see your reply until about three weeks after you wrote it.
(Continue reading)

Permalink | Reply | 3 comments |
headers
fche at redhat dot com | 4 Jan 2007 23:33
Favicon

[Bug runtime/3708] Array elements set to 0 or NULL should not be automatically deleted


------- Additional Comments From fche at redhat dot com  2007-01-04 22:33 -------
I have no objection to changing this policy,
even if it breaks some existing script.  Of
course, old test cases would have to be updated
and/or new ones created to validate the change.

--

-- 

http://sourceware.org/bugzilla/show_bug.cgi?id=3708

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
Mike Mason | 5 Jan 2007 00:38
Picon
Favicon

0's & NULLs in associative arrays

In the systemtap meeting this morning we discussed whether systemtap should allow 0's to be stored in array
elements. Currently, storing a 0 deletes the element, which means the membership check and foreach
statements can't see it.  Here's what I recall from the discussion.

Some concerns were:
- might break some existing scripts
- this is the way Dtrace does it
- current implementation simplifies the API.  You don't have to check if an index exists before reading it. 
Simplifies the implementation.
- not auto deleting 0 elements will take up more space

It was also mentioned that someone might want to increment/decrement an element value and have it auto
delete when it reaches zero. No one thought this was a required behavior. This can also be done with an
explicit delete.

Someone said this behavior is not documented and no one should depend on it in their scripts.  However, the
tutorial does say "Assigning a null value in effect deletes the element" on page 8.  That's the only mention
I've found.

I believe the consensus was to change the behavior such that elements are *not* deleted when set to 0,
essentially removing the auto delete feature.  These elements could then be seen by the membership check
and foreach statements.  All other behavior would remain the same (i.e, referencing nonexistent
elements still returns 0).

Can anybody think of a reason not to make this change?
Permalink | Reply | 0 comments |

Gmane