headers
Peter Bex | 1 Oct 2008 10:16
Picon
Picon
Favicon

Re: Status of revivesa

On Wed, Oct 01, 2008 at 02:37:58AM +0900, Izumi Tsutsui wrote:
> wrstuden <at> NetBSD.org wrote:
> 
> > > - An assertion caused by firefox3 on 4.0 environment I reporeted
> > >   can't be reproducible 100%. (some race condition?)
> > 
> > Yes. I believe the problem is in delivering two or more unblocked upcalls 
> > at once. The second one comes out garbled. Last night, I looked at the 
> > code, and I can't see a substantive difference between the two. I'll try 
> > again tonight. I also have a test case program in mind.
> 
> I'm now trying firefox-2.0.0.17 (Bon Echo) from 4.0/i386 packages.
> It sometimes freezes silently after ~30 minutes browsing,
> but I'm not sure it's revivesa specific.

Firefox 2 freezes all the time on my macppc, running a regular -CURRENT (ie,
no revivesa).  Likely an architecture-specific problem, though (as in,
any architecture that's not i386 or amd64...)

Cheers,
Peter
--

-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
							-- Donald Knuth
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Husemann | 1 Oct 2008 10:36
Picon

Re: Status of revivesa

On Wed, Oct 01, 2008 at 10:16:08AM +0200, Peter Bex wrote:
> Firefox 2 freezes all the time on my macppc, running a regular -CURRENT (ie,
> no revivesa).  Likely an architecture-specific problem, though (as in,
> any architecture that's not i386 or amd64...)

I'm using firefox firefox-2.0.0.16 on a SMP sparc64 machine running -current
(i.e. not revivesa) and it is pretty stable for me. So: it's not anything
!= x86 ;-}

Martin
Permalink | Reply | 1 comment |
headers
Jachym Holecek | 1 Oct 2008 11:47
Picon

Re: Questions around adding a monochrome graphics/ascii display driver over gpio framework

Hello,

# Bill Blass 2008-09-30:
> My goal was to abstract the bus specifics away from the EPSON display
> driver to keep it portable.  Specifically, I added the following EPSON
> display driver sources:
> 
> - /usr/src/sys/dev/ic/s1d13700_subr.c
> - /usr/src/sys/dev/ic/s1d13700reg.h
> - /usr/src/sys/dev/ic/s1d13700var.h
> 
> ...and the following gpio source file:
> 
> - /usr/src/sys/dev/gpio/gpiocfag.c
> 
> I added the following content to /usr/src/sys/dev/gpio/files.gpio:
> 
> device  gpiocfag: s1d13700, wsemuldisplaydev
> attach  gpiocfag at gpio
> file    dev/gpio/gpiocfag.c                     gpiocfag

Looks good if 's1d12700_subc.c' is a trivial piece of code. If it's not,
it would be better to make it a driver on its own and have 'gpiocfag'
as its attachment. Something along the lines of:

  sys/conf/files:
    device foo
    file dev/ic/foo.c foo

  sys/dev/gpio/files.gpio:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Izumi Tsutsui | 1 Oct 2008 15:20
Picon
Gravatar

Re: Status of revivesa

I wrote:

> > > - An assertion caused by firefox3 on 4.0 environment I reporeted
> > >   can't be reproducible 100%. (some race condition?)
> > 
> > Yes. I believe the problem is in delivering two or more unblocked upcalls 
> > at once. The second one comes out garbled. Last night, I looked at the 
> > code, and I can't see a substantive difference between the two. I'll try 
> > again tonight. I also have a test case program in mind.
> 
> I'm now trying firefox-2.0.0.17 (Bon Echo) from 4.0/i386 packages.
> It sometimes freezes silently after ~30 minutes browsing,
> but I'm not sure it's revivesa specific.

It looks some LWPs died:
---
% ps axsw | grep firefox
100  514  531 40492   6    3  73  0 113488   276 lwpwait  DW   ttyp1  5:30.66 /usr/pkg/lib/firefox/firefox-bin 
100  514  531 40492   3    3  73  0 113488   276 -        U    ttyp1  5:30.66 /usr/pkg/lib/firefox/firefox-bin 
100  514  531 40492   1    3  73  0 113488   276 -        U    ttyp1  5:30.66 /usr/pkg/lib/firefox/firefox-bin 
100 4601  531     0   1    1  63  0     92    32 piperd   S    ttyp1  0:00.00 grep firefox 
% 
---

And it can't be killed even by kill(1) -KILL now.
---
Izumi Tsutsui
Permalink | Reply | 1 comment |
headers
Izumi Tsutsui | 1 Oct 2008 15:58
Picon
Gravatar

Re: Status of revivesa

I wrote:

> I'm also preparing mysqlbench with mysql5-server packages.

I'm not sure what parameter should be used to test pthread properly
but currently it doesn't fail:

---
UID  PID %CPU PPID    CPU LID NLWP PRI NI    VSZ   RSS WCHAN    STAT TTY        TIME COMMAND
  0  636  0.0  535   1024   1    1  63  0    164     4 wait     IW   ttyp0   0:00.02 /bin/sh /usr/pkg/bin/mysqld_safe --user
  0  941 29.1  636 149583  20   20  73  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  19   20  62  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  18   20  73  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  17   20  62  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  16   20  63  0  94028 14244 select   S    ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  15   20  62  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  14   20  62  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  13   20  62  0  94028 14244 sawait   S    ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  12   20  62  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  11   20  73  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583  10   20  73  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583   9   20  73  0  94028 14244 biowait  D    ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583   8   20  63  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583   7   20  59  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583   6   20  73  0  94028 14244 sigwait  IW   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583   5   20  59  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583   4   20  73  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583   3   20  62  0  94028 14244 select   S    ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583   2   20  61  0  94028 14244 lwpcache SL   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
  0  941 29.1  636 149583   1   20  73  0  94028 14244 select   IW   ttyp0 105:49.29 /usr/pkg/libexec/mysqld --basedir=/usr/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael | 1 Oct 2008 17:40
Picon

Re: Status of revivesa

Hello,

On Oct 1, 2008, at 4:36 AM, Martin Husemann wrote:

> On Wed, Oct 01, 2008 at 10:16:08AM +0200, Peter Bex wrote:
>> Firefox 2 freezes all the time on my macppc, running a regular - 
>> CURRENT (ie,
>> no revivesa).  Likely an architecture-specific problem, though (as  
>> in,
>> any architecture that's not i386 or amd64...)
>
> I'm using firefox firefox-2.0.0.16 on a SMP sparc64 machine running - 
> current
> (i.e. not revivesa) and it is pretty stable for me. So: it's not  
> anything
> != x86 ;-}

Firefox works fine on my dual G4, I just don't use it a log ( I prefer  
galeon if I need gecko and konqueror otherwise ). Same goes for SMP  
sparc64.

have fun
Michael
Permalink | Reply | 0 comments |
headers
Bill Stouder-Studenmund | 1 Oct 2008 18:50
Picon

can't die, was Re: Status of revivesa

On Wed, Oct 01, 2008 at 10:20:48PM +0900, Izumi Tsutsui wrote:
> I wrote:
> 
> > > > - An assertion caused by firefox3 on 4.0 environment I reporeted
> > > >   can't be reproducible 100%. (some race condition?)
> > > 
> > > Yes. I believe the problem is in delivering two or more unblocked upcalls 
> > > at once. The second one comes out garbled. Last night, I looked at the 
> > > code, and I can't see a substantive difference between the two. I'll try 
> > > again tonight. I also have a test case program in mind.
> > 
> > I'm now trying firefox-2.0.0.17 (Bon Echo) from 4.0/i386 packages.
> > It sometimes freezes silently after ~30 minutes browsing,
> > but I'm not sure it's revivesa specific.
> 
> It looks some LWPs died:
> ---
> % ps axsw | grep firefox
> 100  514  531 40492   6    3  73  0 113488   276 lwpwait  DW   ttyp1  5:30.66 /usr/pkg/lib/firefox/firefox-bin 

Ok, this thread is waiting for the others to exit.

> 100  514  531 40492   3    3  73  0 113488   276 -        U    ttyp1  5:30.66 /usr/pkg/lib/firefox/firefox-bin 
> 100  514  531 40492   1    3  73  0 113488   276 -        U    ttyp1  5:30.66 /usr/pkg/lib/firefox/firefox-bin 

And according to PS, 'U' means these are suspended.

I'm confused. It looks like we're in sigexit(). Oh....

I bet the problem is the code expects LW_WEXIT for its rapid-exit tests.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iain Hibbert | 1 Oct 2008 19:22

Re: Questions around adding a monochrome graphics/ascii display driver over gpio framework

On Tue, 30 Sep 2008, Bill Blass wrote:

> - The device for which my newly developed driver supports is a monochrome CrystalFontz graphical and
character display
> - The CrystalFontz display uses an internal EPSON s1d13700 chip to drive the display

these look awesome, so much choice!

> 2) I do not intend to operate the display as a terminal.  I intend to
> operate the display as a status display which will contain a mix of
> ascii and bitmap images.  Ideally, I'd like to see a usermode
> appliation/service drive the display, but I am unsure how the usermode
> code will interfae with the driver.

just out of interest, since you are working with a userland application to
drive this and it is hooked to GPIO, can't you use ioctls on with gpio(4)
directly to drive it? (please bear in mind that I know nothing about it
but I would have thought a hardware driver would be more useful if you
wanted to drive a wsdisplay)

(btw the website says 8-bit parallel interface for this chip, can it be
hooked to a centronics port?)

iain
Permalink | Reply | 0 comments |
headers
Bryce Simonds | 1 Oct 2008 23:41

Tracking ATA/ATAPI ioctl() calls....

Hi,

I've been attempting to send some raw commands to the ATA/ATAPI controller
in hopes to get the drive to initialize its secure erase protocol; however,
I'm not certain if the command data that I'm sending it is getting
reformatted by the kernel or not, and was hoping I could find out by tracing
through the ioctl() call.

I've gotten as far as were the ATA driver calls
d->atabus->ata_exec_command(), but I cannot figure out where this function
pointer is getting initialized and what it's being initialized to.

Any assistance would be greately appreaciated,

Thank you,
Bryce Simonds
Permalink | Reply | 0 comments |
headers
Antti Kantee | 2 Oct 2008 00:51
Picon

Re: Tracking ATA/ATAPI ioctl() calls....

On Wed, Oct 01, 2008 at 04:41:52PM -0500, Bryce Simonds wrote:
> Hi,
> 
> I've been attempting to send some raw commands to the ATA/ATAPI controller
> in hopes to get the drive to initialize its secure erase protocol; however,
> I'm not certain if the command data that I'm sending it is getting
> reformatted by the kernel or not, and was hoping I could find out by tracing
> through the ioctl() call.
> 
> I've gotten as far as were the ATA driver calls
> d->atabus->ata_exec_command(), but I cannot figure out where this function
> pointer is getting initialized and what it's being initialized to.
> 
> Any assistance would be greately appreaciated,

Try searching the sources for struct ata_bustype.  There's a few
different possibities, e.g. wdc_exec_command.
Permalink | Reply | 1 comment |

Gmane