Re: Call for FreeBSD status reports

[Max Laier]

All,

as I wrote last week:
> Submissions are due on April 15.  Thanks a lot, and we are hoping for a
> big turn-out.

As always this is not final, but please get your reports ready by monday and 
maybe let us know that you are planing to submit.  Unfortunately we have a 
dramatically lower turn-out so far, I hope to see more reports floating in 
over the weekend.  Thanks a lot!

http://www.FreeBSD.org/news/status/

-- 
/"\  Best regards,  | [EMAIL PROTECTED]
\ /  Max Laier  | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | [EMAIL PROTECTED]
/ \  ASCII Ribbon Campaign  | Against HTML Mail and News


pgpzjEfeKTwwn.pgp
Description: PGP signature

Re: MDELAY()

[Dipjyoti Saikia]

Hi,

DELAY() in FreeBSD uses a busy loop . I am looking for something like
sleep_on_timeout() call in Linux . (dont' want to waste the CPU cycles
by  DELAY'ing)

As I am pretty new to programming with Free BSD ,  can you help me
with  some details about equivalent implementation(wait queues etc) in
Free BSD .

---Dip


On 4/13/05, Brooks Davis <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 13, 2005 at 02:33:22AM +0530, Dipjyoti Saikia wrote:
> > Hi,
> >
> > Can any one help me out with a better Implementation of MDELAY() in
> > FreeBSD kernel 4.10
> 
> Please start by defining better.
> 
> -- Brooks
> 
> --
> Any statement of the form "X is the one, true Y" is FALSE.
> PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
> 
> 
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MDELAY()

[Daniel O'Connor]

On Fri, 15 Apr 2005 21:46, Dipjyoti Saikia wrote:
> DELAY() in FreeBSD uses a busy loop . I am looking for something like
> sleep_on_timeout() call in Linux . (dont' want to waste the CPU cycles
> by  DELAY'ing)

tsleep/msleep/timeout are probably what you want.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgpZBDhyMCe8D.pgp
Description: PGP signature

Re: MDELAY()

[ALeine]

[EMAIL PROTECTED] wrote: 

> DELAY() in FreeBSD uses a busy loop . I am looking for something
> like sleep_on_timeout() call in Linux . (dont' want to waste the CPU
> cycles by  DELAY'ing)

You may want to check out timeout(9) / untimeout(9), see man 9 timeout
for details.
 
> As I am pretty new to programming with Free BSD ,  can you help
> me with some details about equivalent implementation(wait queues
> etc) in Free BSD .

Reading the man pages for asleep(9) / wakeup(9) should give you a
good introduction.

ALeine
___
WebMail FREE http://mail.austrosearch.net 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MDELAY()

[Joseph Koshy]

> sleep_on_timeout() call in Linux . (dont' want to waste the CPU cycles

You may want to try the manual pages.

% man -k sleep | fgrep '(9)'  
endtsleep(9), sleepinit(9), unsleep(9) - manage the queues of sleeping processes
init_sleepqueues(9) ... sleepq_wait_sig(9) - manage the queues of
sleeping threads
sleep(9), msleep(9), tsleep(9), wakeup(9) - wait for events
vm_page_sleep_busy(9)- wait for a busy page to become unbusy

% man -k DELAY | fgrep '(9)'
DELAY(9) - busy loop for an interval

-- 
FreeBSD Volunteer, http://people.freebsd.org/~jkoshy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NFS client/buffer cache deadlock

[Marc Olzheim]

On Fri, Apr 15, 2005 at 01:08:21AM -0400, Brian Fundakowski Feldman wrote:
> I'll spare a lengthy write-up because I think the patch documents it well
> enough.  It certainly appears to fix things here when doing very large
> block-sized writes, but it also reduces the throughput with those block
> sizes.  (I don't think there should be any difference when using reasonable
> block sizes).

Is this supposed to fix kern/79208 ?

Marc


pgps4BytOYqIO.pgp
Description: PGP signature

Re: immenent disk failure ?

[Bill Vermillion]

On or about Fri, Apr 15, 2005 at 12:01 , while attempting a 
Zarathustra emulation [EMAIL PROTECTED] thus spake:



> Message: 4
> Date: Thu, 14 Apr 2005 10:58:02 -0500 (CDT)
> From: "H. S." <[EMAIL PROTECTED]>
> Subject: imminent disk failure ?

...

> I have a server running 4.X for almost two years now, without
> problems - rock solid as it should be - yesterday the server
> became unresponsive, now that I have access again, and while
> checking the logs, I found this as the last message before the
> unresponsiveness:

> /kernel: ad0: READ command timeout tag=0 serv=0 - resetting

> The next message is the system getting back on, 1hour later.

> I have not changed anything kernel-related on this system for
> a long time (jul 2004), just apply the occasional kernel patch
> and rebuild/reboot the system. I never encountered this problem
> before. Could this message mean this disk is giving its last
> breaths ?

It might help if we knew a bit more about the system such
a drive make and model - you can see that in dmesg.  That may
point out some device that is known to be problematic.

The last time I got timeout errors like that was in the 3.x era
with a SCSI controller.   Last IDE problem I had was a bad read
that force the system into PIO mode with over 75% performance
decrease.   The only way around that one that I was aware of was a
reboot.

Bill

-- 
Bill Vermillion - bv @ wjv . com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MDELAY()

[Joerg Sonnenberger]

On Fri, Apr 15, 2005 at 06:03:11AM -0700, ALeine wrote:
> [EMAIL PROTECTED] wrote: 
> 
> > DELAY() in FreeBSD uses a busy loop . I am looking for something
> > like sleep_on_timeout() call in Linux . (dont' want to waste the CPU
> > cycles by  DELAY'ing)
> 
> You may want to check out timeout(9) / untimeout(9), see man 9 timeout
> for details.

You should not use timeout(9) without a very good reason, the callout_*
interface is prefered.

Joerg
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NFS client/buffer cache deadlock

[Brian Fundakowski Feldman]

On Fri, Apr 15, 2005 at 03:21:08PM +0200, Marc Olzheim wrote:
> On Fri, Apr 15, 2005 at 01:08:21AM -0400, Brian Fundakowski Feldman wrote:
> > I'll spare a lengthy write-up because I think the patch documents it well
> > enough.  It certainly appears to fix things here when doing very large
> > block-sized writes, but it also reduces the throughput with those block
> > sizes.  (I don't think there should be any difference when using reasonable
> > block sizes).
> 
> Is this supposed to fix kern/79208 ?

Yes, it does; would you like to try a more recent version of the patch?
It's actually against -STABLE, but it needs to be tested in -CURRENT if
it's going ot try to make it into 5.x (or hopefully 5.4-RELEASE).

See: 

This also implements non-blocking writes for NFS clients and will
do the right thing (perform a continuous write, flushing as it goes,
and causing no drop in performance) for "non-atomic" I/O, but I
don't know of any interface that allows you to do non-atomic writes.

Buggy applications can break because of this.  The behavior is almost
never going to be different until you start trying to use extremely
large (say, over a megabyte) writes: if you actually depend on writes
being complete and atomic, you check that what you intended to write
(a reasonable amount) was exactly what was written in a single system
call.  If you don't, then you're supposed to correctly handle short
writes by completing them yourself.

If your application expects to have multiple interleaved appenders do
the right thing for these giant writes, I don't expect it will work.
The implmentation, but not the manpage, would continue to match the
POSIX semantics (with regard to short writes).

See: 

If it expects NFS-level append atomicity of large writes, it will not
get that.  If it expects local-machine-level append atomicity of large
writes, it could get that if we provide an interface for !IO_UNIT.
Note that file locking is also an option...  I don't believe there is
any way to provide unlimited-sized, retryable (in the NFS atomic
transaction level), NFS client writes.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: immenent disk failure ?

[Brian Fundakowski Feldman]

On Fri, Apr 15, 2005 at 10:10:52AM -0400, Bill Vermillion wrote:
> On or about Fri, Apr 15, 2005 at 12:01 , while attempting a 
> Zarathustra emulation [EMAIL PROTECTED] thus spake:
> 
> 
> 
> > Message: 4
> > Date: Thu, 14 Apr 2005 10:58:02 -0500 (CDT)
> > From: "H. S." <[EMAIL PROTECTED]>
> > Subject: imminent disk failure ?
> 
> ...
> 
> > I have a server running 4.X for almost two years now, without
> > problems - rock solid as it should be - yesterday the server
> > became unresponsive, now that I have access again, and while
> > checking the logs, I found this as the last message before the
> > unresponsiveness:
> 
> > /kernel: ad0: READ command timeout tag=0 serv=0 - resetting
> 
> > The next message is the system getting back on, 1hour later.
> 
> > I have not changed anything kernel-related on this system for
> > a long time (jul 2004), just apply the occasional kernel patch
> > and rebuild/reboot the system. I never encountered this problem
> > before. Could this message mean this disk is giving its last
> > breaths ?
> 
> It might help if we knew a bit more about the system such
> a drive make and model - you can see that in dmesg.  That may
> point out some device that is known to be problematic.
> 
> The last time I got timeout errors like that was in the 3.x era
> with a SCSI controller.   Last IDE problem I had was a bad read
> that force the system into PIO mode with over 75% performance
> decrease.   The only way around that one that I was aware of was a
> reboot.

For any disk within perhaps the last five years you should be able to
just use SMART to perform a thorough health test on your hard drives
and view their statistics and error logs.  I don't know why it doesn't
currently do much on SCSI, but ports/sysutils/smartmontools works
great for ATA.

-- 
Brian Fundakowski Feldman   \'[ FreeBSD ]''\
  <> [EMAIL PROTECTED]   \  The Power to Serve! \
 Opinions expressed are my own.   \,,\
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MDELAY()

[Daniel O'Connor]

On Sat, 16 Apr 2005 00:34, Joerg Sonnenberger wrote:
> > You may want to check out timeout(9) / untimeout(9), see man 9 timeout
> > for details.
>
> You should not use timeout(9) without a very good reason, the callout_*
> interface is prefered.

Can someone add a warning to the top of the makefile similar to the one for 
spl?

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgpGG3Fv9PUgX.pgp
Description: PGP signature

Re: MDELAY()

[Joerg Sonnenberger]

On Sat, Apr 16, 2005 at 01:12:42AM +0930, Daniel O'Connor wrote:
> On Sat, 16 Apr 2005 00:34, Joerg Sonnenberger wrote:
> > > You may want to check out timeout(9) / untimeout(9), see man 9 timeout
> > > for details.
> >
> > You should not use timeout(9) without a very good reason, the callout_*
> > interface is prefered.
> 
> Can someone add a warning to the top of the makefile similar to the one for 
> spl?

It's not that bad, timeout(9) has a few cases, where replacing it involves
work. I've done that in DragonFly, I know what I'm talking about.

The reason for this advice is that the timeout(9) API has two major short
comings:
(a) It depends on some internal magic to provide the storage, but doesn't
have a clear way to handle errors. The storage space can be a few hundred
KB of kernel memory mostly wasted.
(b) It is difficult to cancel all outstanding timers correctly because
the race conditions are difficult to avoid when calling untimeout.

Since (b) is pretty much a requirement for the kernel nowaday and you
have to keep track of the return value anyway, you can almost mechanically
convert such code to the callout_* interface. That also avoids (a).

Concerning your original question about the inefficiency of DELAY, what
timeouts are we talking about? For anything in the area of a few micro seconds,
DELAY is most likely better, because it avoids context switches and
the associated cache pollution.

Joerg
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

core dump submissions with send-pr?

[nahthan subramanian]

Hello,
 
  I have a few recent 5.3 panics I would like to submit.  send-pr always bails 
telling me that it is
out of space, despite the fact that the local filesystems have plenty of space 
free:
 
pixie# send-pr -a ./backtrace -a ./uname-output -a ./messages -a 
./sysctl-a-output -a ./dmesg.output -a ./GENERIC -a ./SMP -a 
/u/nate/proj/FreeBSD/crashes/bldf2.eng/vmcore.0.gz
/usr/bin/send-pr: Out of space

What is the proper method for submitting cores along with backtraces to the 
FreeBSD development team?  Is it useful to submit cores, or is the backtrace 
sufficient?
Thank you,
 


-
Yahoo! Mail Mobile
 Take Yahoo! Mail with you! Check email on your mobile phone.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: core dump submissions with send-pr?

[Joseph Koshy]

> What is the proper method for submitting cores along with 
> backtraces to the FreeBSD development team?  Is it useful to 
> submit cores, or is the backtrace sufficient?
 
Firstly, GNATS works over email and sending in a 4GB+ MIME 
encoded core file could overload the mail servers of not
just the FreeBSD project, but also those of the volunteers who
track the freebsd-bugs list.

Secondly the GNATS repository is itself replicated on many 
sites and so you would also earn the wrath of mirror
site admins across the world :).


Instead, you could first describe the problem on -stable.  
It may turn out to be a known problem (you can check yourself 
with a quick browse of the archives).

If it *is* a new bug then please do file a PR with a backtrace, 
your machine configuration, and a description of the problem.  
Many times a core file is not necessary, but if needed it
generally suffices to put it up somewhere where a developer 
can access it.

-- 
FreeBSD Volunteer, http://people.freebsd.org/~jkoshy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ASUS DRW-1608P, doesn't write anything

[David E. Cross]

I have problem with an ASUS DRW-1609P with both 5.3 and 5.4.  It won't
write any media.  Even "burncd" fails with the following error:

(Yes, I know I have "test" mode on, I got tired of making coasters)
> burncd -f /dev/acd0 -s max -v -t data file.iso  fixate
> adding type 0x08 file mp3.iso.aa size 72 KB 36 blocks
> next writeable LBA 2136
> addr = 2136 size = 73728 blocks = 36
> writing from file mp3.iso.aa size 72 KB
> written this track 1120 KB (0%) total 1120 KB
> only wrote -1 of 32768 bytes: Device busy

Relevent line from dmesg:

acd0: DVDR  at ata1-master PIO4

atapicam doesn't fix it.  UDMA doesn't fix it.  GENERIC kernel.

Reading works fine.

Suggestions?

-- 
David E. Cross
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ASUS DRW-1608P, doesn't write anything

[soralx]

> I have problem with an ASUS DRW-1609P with both 5.3 and 5.4.  It won't
> write any media.  Even "burncd" fails with the following error:
>
> (Yes, I know I have "test" mode on, I got tired of making coasters)
>
> > burncd -f /dev/acd0 -s max -v -t data file.iso  fixate
> > adding type 0x08 file mp3.iso.aa size 72 KB 36 blocks
> > next writeable LBA 2136
> > addr = 2136 size = 73728 blocks = 36
> > writing from file mp3.iso.aa size 72 KB
> > written this track 1120 KB (0%) total 1120 KB
> > only wrote -1 of 32768 bytes: Device busy
>
> Relevent line from dmesg:
>
> acd0: DVDR  at ata1-master PIO4
>
> atapicam doesn't fix it.  UDMA doesn't fix it.  GENERIC kernel.
>
> Reading works fine.
>
> Suggestions?

Same with:

acd1:  DVDR drive at ata1 as slave
acd1: read 5511KB/s (5511KB/s) write 2755KB/s (2755KB/s), 2000KB buffer, PIO4
acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet
acd1: Writes: CDR, CDRW, DVDR, test write, burnproof
acd1: Audio: play, 256 volume levels
acd1: Mechanism: ejectable tray, unlocked
acd1: Medium: no/blank disc

I simply use it through ATAPICAM layer with cdrecord - always
worked perfectly.

Would be interesting to know why these devices don't behave properly.

Timestamp: 0x4260B31F
[SorAlx]  http://cydem.org.ua/
ridin' VN1500-B2

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"