2009/5/13 pluknet :
> 2009/5/13 John Baldwin :
>> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
>>> Hi.
>>>
>>> From just another box (not from the first two mentioned earlier)
>>> with a similar locking issue. If it would make sense, since there are
>>> possibly a bit different conditions.
>>>
On Tuesday 12 May 2009 11:52:29 am David Johnson wrote:
> I may have made a mistake though, and briefly turned on debugging earlier
> in the session. I'll get another trace this evening when I have time, to
> double check.
Yup, I must have turned on debugging earlier in that session. All I can get
2009/5/13 John Baldwin :
> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
>> Hi.
>>
>> From just another box (not from the first two mentioned earlier)
>> with a similar locking issue. If it would make sense, since there are
>> possibly a bit different conditions.
>> clock proc here is on swi4, I
On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
> Hi.
>
> From just another box (not from the first two mentioned earlier)
> with a similar locking issue. If it would make sense, since there are
> possibly a bit different conditions.
> clock proc here is on swi4, I hope it's a non-important diffe
On Wed, May 13, 2009 at 10:52:34AM +1200, Nigel Wohlers wrote:
> On 13/5/09 8:41 AM, Xin LI wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >Hi David,
> >
> >David Samms wrote:
> >>After upgrading to 7.2 (amd64) some customers complained of very poor
> >>bandwidth. Upon investigat
On 13/5/09 8:41 AM, Xin LI wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi David,
David Samms wrote:
After upgrading to 7.2 (amd64) some customers complained of very poor
bandwidth. Upon investigation all the effected customers were ATT DSL
clients located all over the USA, not in a s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, David,
David Samms wrote:
> Xin LI wrote:
>> Hi David,
>>
>> David Samms wrote:
>>> After upgrading to 7.2 (amd64) some customers complained of very poor
>>> bandwidth. Upon investigation all the effected customers were ATT DSL
>>> clients locate
On Tue, May 12, 2009 at 05:31:01PM -0400, David Samms wrote:
>
> Setting sysctl net.inet.tcp.tso=0 resolved the issue completely. What
> does sysctl net.inet.tcp.tso=0 do?
# sysctl -d net.inet.tcp.tso
net.inet.tcp.tso: Enable TCP Segmentation Offload
I had a similar problem with a different N
Yani Karydis wrote:
Hello,
Since upgrading to 7.2-RELEASE, dmesg displays the following after
booting the system.
(probe3:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe3:ahc0:0:3:0): CAM Status: SCSI Status Error
(probe3:ahc0:0:3:0): SCSI Status: Check Condition
(probe3:ahc0:0:3:0): UN
Xin LI wrote:
Hi David,
David Samms wrote:
After upgrading to 7.2 (amd64) some customers complained of very poor
bandwidth. Upon investigation all the effected customers were ATT DSL
clients located all over the USA, not in a single city, nor were other
ISPs effected. The server is a Supermic
2009/5/12 John Baldwin :
> On Tuesday 12 May 2009 2:12:27 am pluknet wrote:
>> 2009/5/11 John Baldwin :
>> > On Monday 04 May 2009 11:41:35 pm pluknet wrote:
>> >> 2009/5/1 John Baldwin :
>> >> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
>> >> >> Hi folks.
>> >> >>
>> >> >> Today I got a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi David,
David Samms wrote:
> After upgrading to 7.2 (amd64) some customers complained of very poor
> bandwidth. Upon investigation all the effected customers were ATT DSL
> clients located all over the USA, not in a single city, nor were other
> IS
Dan Nelson wrote:
In the last episode (May 12), martinko said:
I've just tried 7.2-RELEASE (amd64) on Asus M3A78-EM motherboard and
booting got stuck with the following:
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
From what I've found via Google it should be fixe
On Tuesday 12 May 2009 08:17:51 am Robert Noland wrote:
> On Sat, 2009-05-09 at 18:41 -0700, David Johnson wrote:
> > On Friday 08 May 2009 03:31:04 pm Robert Noland wrote:
> > > In order to guess what might be causing this, drm debugging needs to be
> > > enabled before the hang, so that we can ho
I have a co-lo server I've been maintaining for a few years now running IDE
drives on a mostly terrible UPS. A few months ago, when it returned from a
power outage (running 6.2-R) I started noticing the following in my daily
security email:
Checking setuid files and devices:
find:
/var/db/portsn
After upgrading to 7.2 (amd64) some customers complained of very poor
bandwidth. Upon investigation all the effected customers were ATT DSL
clients located all over the USA, not in a single city, nor were other
ISPs effected. The server is a Supermicro with dual (quad core)
processors with a
On Tuesday 12 May 2009 12:10:25 pm Riccardo Torrini wrote:
> On Tue, May 12, 2009 at 11:44:20AM -0400, John Baldwin wrote:
>
> > If you can get a stack trace, that would be most helpful.
> > My guess is that the recovery thread is holding the mpt lock
> > and calling some CAM routine which attempt
On Tue, May 12, 2009 at 11:44:20AM -0400, John Baldwin wrote:
> If you can get a stack trace, that would be most helpful.
> My guess is that the recovery thread is holding the mpt lock
> and calling some CAM routine which attempts to relock it via
> cam_periph_lock(). A stack trace would be most
On Sat, May 9, 2009 at 3:12 AM, David Malone wrote:
> On Fri, May 08, 2009 at 10:51:02AM -0300, Eduardo Meyer wrote:
>> However what I see regarding proc usage is by uid 82 is:
>>
>> # ps -U 82 | wc -l
>> 723
>>
>> Proccess count for UID 82 is never highter than 913 (monitored the
>> last who
On Sat, May 9, 2009 at 3:12 AM, David Malone wrote:
> On Fri, May 08, 2009 at 10:51:02AM -0300, Eduardo Meyer wrote:
>> However what I see regarding proc usage is by uid 82 is:
>>
>> # ps -U 82 | wc -l
>> 723
>>
>> Proccess count for UID 82 is never highter than 913 (monitored the
>> last who
On Tuesday 12 May 2009 11:20:14 am Riccardo Torrini wrote:
> On Mon, May 11, 2009 at 02:07:19PM -0400, John Baldwin wrote:
>
> > Do you have kernel crashdumps enabled and a swap partition?
> > If so, do you happen to have any files in /var/crash?
>
> Yes, but I'm unable to produce a crash dump :
On Tuesday 12 May 2009 2:12:27 am pluknet wrote:
> 2009/5/11 John Baldwin :
> > On Monday 04 May 2009 11:41:35 pm pluknet wrote:
> >> 2009/5/1 John Baldwin :
> >> > On Thursday 30 April 2009 2:36:34 am pluknet wrote:
> >> >> Hi folks.
> >> >>
> >> >> Today I got a new locking issue.
> >> >> This is
On Mon, May 11, 2009 at 02:07:19PM -0400, John Baldwin wrote:
> Do you have kernel crashdumps enabled and a swap partition?
> If so, do you happen to have any files in /var/crash?
Yes, but I'm unable to produce a crash dump :-(
Tryed even with voodoo, added and removed options to
kernel (kdb, gd
On Sat, 2009-05-09 at 18:41 -0700, David Johnson wrote:
> On Friday 08 May 2009 03:31:04 pm Robert Noland wrote:
> > In order to guess what might be causing this, drm debugging needs to be
> > enabled before the hang, so that we can hopefully figure out what leads
> > up to the hung GPU.
>
> I'm n
Hello,
Since upgrading to 7.2-RELEASE, dmesg displays the following after
booting the system.
(probe3:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
(probe3:ahc0:0:3:0): CAM Status: SCSI Status Error
(probe3:ahc0:0:3:0): SCSI Status: Check Condition
(probe3:ahc0:0:3:0): UNIT ATTENTION asc:29,0
Daniel Bond writes:
> I have a NetBSD 5.0 installation on my private server, I'll start
> looking at how they have implemented PAM.
Specifically, you should look at how they've adapted their passwd(1) and
what pam_sm_chauthtok() looks like in their PAM modules.
DES
--
Dag-Erling Smørgrav - d...
Hi Steve and Oliver,
thanks for your replies. Sorry it has taken me some time to reply. I'm
willing to put in some time into this issue too, maybe we could do a
joint effort on this?
The problem report with the most information in is http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/71290
-
On 5/12/09, Attila Nagy wrote:
> Hello,
>
> I have a strange error on FreeBSD 7-STABLE (compiled on 7th May, just
> few commits after the release, but an earlier kernel did the same).
>
> I'm doing several parallel rsyncs from a machine to another (let's call
> them source and destination). The so
Hello,
I have a strange error on FreeBSD 7-STABLE (compiled on 7th May, just
few commits after the release, but an earlier kernel did the same).
I'm doing several parallel rsyncs from a machine to another (let's call
them source and destination). The source contains maildirs, so there are
so
> Basic data on my experience with the xpt_config hang; I have more
> detail if needed, but I doubt anyone will believe it. I'm not even
> sure I do.
I am not sure what you mean by that ... something odd about the hang ?
For what it's worth, I have also seen this - I get (or got) precisely
the sa
I have been trying to understand the failure better:
(kgdb) frame 10
#10 0x80473265 in usb_transfer_complete (xfer=0xff00045cbc00)
at /red/public/freebsd/sources/stable/sys/dev/usb/usbdi.c:949
949 STAILQ_REMOVE_HEAD(&pipe->queue, next);
(kgdb) list
944 #ifd
31 matches
Mail list logo
