From patfbsd at davenulle.org  Sun Mar  1 04:00:16 2009
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Sun Mar  1 04:00:30 2009
Subject: [7-STABLE] ndis interacts badly with powerd
Message-ID: <20090301130018.4bb7f349@baby-jane.lamaiziere.net>

Hi,

[7-STABLE/i386-SMP]

When I enable powerd, ndis takes all the CPU. Powerd alone and ndis
alone works fine.

The kernel threads "Windows DCP0" and "ndis0 taskq" run at
100%. But the machine is still running (but is very very slow), I can
kldunload my ndis module and all is ok.

I tried with a kernel (GENERIC) without SMP but there is the same
problem.

Any idea? Thanks. 

CPU: Intel(R) Core(TM)2 Duo CPU T7500  @ 2.20GHz (2194.52-MHz 686-class
CPU)
cpu0: <ACPI CPU> on acpi0 
est0: <Enhanced SpeedStep Frequency Control> on cpu0 
p4tcc0: <CPU Frequency Thermal Control> on cpu0

Ndis:
ndis0: <Atheros AR5008 Wireless Network Adapter> mem
0x97300000-0x9730ffff irq 16 at device 0.0 on pci11 
ndis0: [ITHREAD]
ndis0: NDIS API version: 5.1
NDIS: open file /compat/ndis/preparse.ini failed: 2
NDIS: open file /compat/ndis/regAdd.txt failed: 2
ndis0: WARNING: using obsoleted if_watchdog interface
ndis0: Ethernet address: 00:1e:52:76:65:60
NDIS: open file /compat/ndis/preparse.ini failed: 2
NDIS: open file /compat/ndis/regAdd.txt failed: 2
ndis0: setting BSSID failed: 45
From petefrench at ticketswitch.com  Sun Mar  1 06:58:05 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sun Mar  1 06:58:12 2009
Subject: vm_thread_new: kstack allocation failed with
	vm.kmem_size="1536M"
In-Reply-To: <20090301031001.GB3465@dan.emsphone.com>
Message-ID: <E1Ldn77-000AGN-FT@dilbert.ticketswitch.com>

> I'm running 7-STABLE as of Feb 26 or so.  Commit r187466 on Jan 20 bumped up
> kmem_size_max on amd64 to 3.6GB:
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=187466

Mmmmm.... now I am wworried about upgrading to STABLE! ;) I can't
think of a reason why I am seeing what I am seeing - on 7.1-RELEASE
I am certainly icreasing the limits not decreasing them, yet I
am seeing it running out of memory on the larger limit.

Note that these machines have no swap - but then since the system runs fine
on a 4gig machine with 4 gig of sap, I made the assumption that if
the machine was expanded to 8 gig of real memory it no longer needs the
swap, as it now has as much real RAM in it as real+swap was before.

-pete.
From alan.l.cox at gmail.com  Sun Mar  1 11:45:11 2009
From: alan.l.cox at gmail.com (Alan Cox)
Date: Sun Mar  1 11:45:24 2009
Subject: vm_thread_new: kstack allocation failed with
	vm.kmem_size="1536M"
In-Reply-To: <E1Ldn77-000AGN-FT@dilbert.ticketswitch.com>
References: <20090301031001.GB3465@dan.emsphone.com>
	<E1Ldn77-000AGN-FT@dilbert.ticketswitch.com>
Message-ID: <ca3526250903011145h3d7ac384ydfa4828f39b11754@mail.gmail.com>

On Sun, Mar 1, 2009 at 8:57 AM, Pete French <petefrench@ticketswitch.com>wrote:

> > I'm running 7-STABLE as of Feb 26 or so.  Commit r187466 on Jan 20 bumped
> up
> > kmem_size_max on amd64 to 3.6GB:
> >
> > http://svn.freebsd.org/viewvc/base?view=revision&revision=187466
>
> Mmmmm.... now I am wworried about upgrading to STABLE! ;) I can't
> think of a reason why I am seeing what I am seeing - on 7.1-RELEASE
> I am certainly icreasing the limits not decreasing them, yet I
> am seeing it running out of memory on the larger limit.
>
> Note that these machines have no swap - but then since the system runs fine
> on a 4gig machine with 4 gig of sap, I made the assumption that if
> the machine was expanded to 8 gig of real memory it no longer needs the
> swap, as it now has as much real RAM in it as real+swap was before.
>
> -pete.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>

When you adjust the kmem size, you are playing a zero-sum game.  When you
increase the kmem size, the additional space for the kernel's heap has to
come from somewhere.  One effect is that the available space for kernel
thread stacks is reduced.

If you're going to adjust kmem size, you should keep an eye on "sysctl
vm.kvm_free".

Regards,
Alan
From n-butcher at fusiongol.com  Sun Mar  1 17:24:25 2009
From: n-butcher at fusiongol.com (Nathan Butcher)
Date: Sun Mar  1 17:24:32 2009
Subject: ural driver stalls under FreeBSD7.1
In-Reply-To: <uh7d4d4rmel.fsf@P142.sics.se>
References: <49A61894.5040804@fusiongol.com>	<20090226045340.GC70144@weongyo.cdnetworks.kr>	<uh7hc2h13a7.fsf@P142.sics.se>
	<49A74A21.1050109@freebsd.org>	<20090227035532.GC72273@weongyo.cdnetworks.kr>
	<uh7d4d4rmel.fsf@P142.sics.se>
Message-ID: <49AB3544.6000008@fusiongol.com>

Bengt Ahlgren wrote:
> Weongyo Jeong <weongyo.jeong@gmail.com> writes:
> 
>> On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote:
>>> Bengt Ahlgren wrote:
>>>> Weongyo Jeong <weongyo.jeong@gmail.com> writes:
>>>>  
>>>>> On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote:
>>>>>    
>>>>>> I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor.
>>>>>> It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1
>>>>>>
>>>>>> Typically, It works for a while until eventually it stalls data
>>>>>> transfers completely. It always seems to do this after an unspecified
>>>>>> amount of time.
>>>>>>
>>>>>> I know the hardware isn't at fault because the device works fine under
>>>>>> Linux.
>>>>>>      
>>>>> Could you please check that `ifconfig <ifname> -bgscan' disabling the
>>>>> background scan helps your symptom?
>>>> The above sounds like the same problem as this:
>>>>
>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html
>>>> http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>>>>
>>>> The problem is in the background scanning logic in sys/net80211.
>>> I don't see how you come to this conclusion.  ural is a totally 
>>> different driver than ath and so far as I can recall you never found the 
>>> cause for your problem w/ ath.  Most of the usb wireless drivers do a 
>>> haphazard job of synchronizing async tasks like bg scan with the 
>>> foreground tx/rx processing.  This can lead to firmware and/or usb 
>>> issues.  ath does not have these issues but I am aware of at least one 
>>> problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD).
>> I agree with sam because I saw some cases like stalls during background
>> scanning that most of them I think it's caused by H/W miss-operation or
>> miss-configuration by mistakes of driver.
> 
> Looking into if_ural (1.69.6.1 - 7.1R version), it partly has the same
> calls to net80211 which causes problems for ath.
> 
> At line 1477, it has the same test as ath has to check for bg
> scanning:
> 
> 			if (ic->ic_flags & IEEE80211_F_SCAN)
> 				ieee80211_cancel_scan(ic);
> 
> That means that ieee80211_cancel_scan won't be called in the window
> between when scan_next is run (which resets IEEE80211_F_SCAN), and
> ieee80211_bg_scan is called the next time (setting IEEE80211_F_SCAN
> again).  This is the same problem as ath has.
> 
> But I can't find that ural calls ieee80211_pwrsave to queue packets if
> a bgscan was running.  It seems that it just merrily tries to send
> packets despite scanning is going on.
> 
> Please note that even though ieee80211_cancel_scan IS called, that
> won't take effect until the next clock tick.  So if the output routine
> just carries on with sending a packet, it will do so in the middle of
> the scan.  This is something that should be fixed in net80211.
> 
> So, I find that ural also suffers from the problem with the scanning
> logic in net80211.

...and turning bgscan off, as per Jeong's advice has solved the problem
for me. So yes, background scanning is responsible for the hangs in ural.

From yanefbsd at gmail.com  Sun Mar  1 19:10:02 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Sun Mar  1 19:10:10 2009
Subject: Outstanding issues with LG GGC-H20L on 7.0/8
Message-ID: <3E0302A6-6A0B-4C11-8CC2-B611B412C2E7@gmail.com>

	I've been mute about this for a while, but I figured I should report  
it.
	My BlueRay DVD drive combo has a number of quirks that need to be  
worked out with ata(4):
	- It plays audio/data CD media perfectly fine, and data DVDs  
perfectly fine.
	- It doesn't play region locked DVDs, but it will play region  
unlocked DVDs (mplayer, vlc).
	- It suffers from frequent burn errors (burncd, cdrecord, growisofs)  
during the burn process (not the fixation process).

	I've seen complaints about the firmware maker (Matsushita) on some  
mplayer sites and how the drives suck, but they were complaining about  
region locking, and this issue with the drive appears to be  
centralized in a more ata specific way.
	I'm using an extremely up-to-date CURRENT (today, 4pm), and I've seen  
this issue occur with 7.0-RELEASE, PC-BSD, and 8-CURRENT, so I doubt  
that the issues are regression related.
	The idenf for the drive is: `HL-DT-ST BDDVDRW GGC-H20L 1.03'; a link  
to the specs sheet can be found here: <http://us.lge.com/download/product/file/1000003670/h_ggch20l_spec_sheet.pdf 
 >. They don't have a product page though and it wasn't listed on the  
website :(.
	Will provide more data as requested.
Thanks,
-Garrett
From aryeh.friedman at gmail.com  Sun Mar  1 21:25:06 2009
From: aryeh.friedman at gmail.com (Aryeh M. Friedman)
Date: Sun Mar  1 21:25:13 2009
Subject: gmirror does not initialize properally
Message-ID: <49AB66A4.4030509@gmail.com>

I have started the procedure for mirroring drives and everything works 
fine upto its first mount attempt (read only root... premounted before 
/etc/rc runs) and then sees no slices... what I mean is 
/dev/mirror/gm0Sxy never appears in the ls of /dev/mirror [bur 
/dev/mirror/gm0 does _exist_).... here is the output from kldstat:

Id Refs Address    Size     Name
 1   19 0xc0400000 94f054   kernel
 2    1 0xc0d50000 84c4     linprocfs.ko
 3    3 0xc0d59000 27744    linux.ko
 4    1 0xc0d81000 161c8    geom_mirror.ko
 5    1 0xc0d98000 15484    snd_hda.ko
 6    2 0xc0dae000 4938c    sound.ko
 7    1 0xc0df8000 23e4     accf_http.ko
 8    1 0xc0dfb000 75aa64   nvidia.ko
 9    1 0xc1556000 68304    acpi.ko

From aryeh.friedman at gmail.com  Sun Mar  1 21:34:51 2009
From: aryeh.friedman at gmail.com (Aryeh M. Friedman)
Date: Sun Mar  1 21:34:59 2009
Subject: gmirror does not initialize properally
In-Reply-To: <49AB66A4.4030509@gmail.com>
References: <49AB66A4.4030509@gmail.com>
Message-ID: <49AB68CA.9010603@gmail.com>

Aryeh M. Friedman wrote:
> I have started the procedure for mirroring drives and everything works 
> fine upto its first mount attempt (read only root... premounted before 
> /etc/rc runs) and then sees no slices... what I mean is 
> /dev/mirror/gm0Sxy never appears in the ls of /dev/mirror [bur 
> /dev/mirror/gm0 does _exist_).... here is the output from kldstat:
>
> Id Refs Address    Size     Name
> 1   19 0xc0400000 94f054   kernel
> 2    1 0xc0d50000 84c4     linprocfs.ko
> 3    3 0xc0d59000 27744    linux.ko
> 4    1 0xc0d81000 161c8    geom_mirror.ko
> 5    1 0xc0d98000 15484    snd_hda.ko
> 6    2 0xc0dae000 4938c    sound.ko
> 7    1 0xc0df8000 23e4     accf_http.ko
> 8    1 0xc0dfb000 75aa64   nvidia.ko
> 9    1 0xc1556000 68304    acpi.ko
>
>
Forgot:

FreeBSD flosoft.no-ip.biz 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Sun 
Feb  1 18:13:54 UTC 2009     
root@flosoft.no-ip.biz:/usr/obj/usr/src/sys/GENERIC  i386


From andrew at modulus.org  Sun Mar  1 22:14:46 2009
From: andrew at modulus.org (Andrew Snow)
Date: Sun Mar  1 22:15:30 2009
Subject: gmirror does not initialize properally
In-Reply-To: <49AB66A4.4030509@gmail.com>
References: <49AB66A4.4030509@gmail.com>
Message-ID: <49AB78D1.4090000@modulus.org>


Perhaps you used "gmirror configure" instead of "gmirror label" when you 
created the gmirror?

You need to use "label" mode to actually save the configuration to disks 
for use on next bootup.


- Andrew

From andrew at modulus.org  Sun Mar  1 22:15:34 2009
From: andrew at modulus.org (Andrew Snow)
Date: Sun Mar  1 22:15:40 2009
Subject: gmirror does not initialize properally
In-Reply-To: <49AB66A4.4030509@gmail.com>
References: <49AB66A4.4030509@gmail.com>
Message-ID: <49AB7903.4050104@modulus.org>


Sorry, I meant "label -h" instead of just plain "label"... was getting 
confused with gstripe.
From mah at jump-ing.de  Mon Mar  2 02:13:08 2009
From: mah at jump-ing.de (Markus Hitter)
Date: Mon Mar  2 02:13:28 2009
Subject: powerd causing crash on Mini-ITX EN1200
In-Reply-To: <f80199c40902260944q430b7faavd9fc7891c6ecb7b0@mail.gmail.com>
References: <f80199c40902260944q430b7faavd9fc7891c6ecb7b0@mail.gmail.com>
Message-ID: <F5A1D5F3-5DBE-453D-8FEC-1AD034803922@jump-ing.de>


Am 26.02.2009 um 18:44 schrieb Ross Penner:

> When I enable powerd, it is only but a matter of time before my
> machine will lock up completely. I've had this problem since I've
> migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any
> problems.

As FreeBSD Stable is a continuous development, you have good chances  
to narrow down the culprit by bisecting. The assumption is, one  
single SVN commit broke your functionality and you just have to find  
out which one.

Get sources from SVN, then switch to the earliest Stable/7 to confirm  
your assumption ("it broke with 7"). If it works, check out a few  
thousand SVN revisions later, try again. If it doesn't work, switch  
to an earlier revision, a late Stable/6. Each step cuts the number of  
SVN revisions in question in half, after some 10 or 12 iterations  
you're down to a single revision.

Having a single revision pretty much directly points you to what the  
problem is. This helps developers very much and with some luck you  
can reverse-apply this change to a more recent set of the sources.


MarKus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/




From Josef.Karthauser at geomerics.com  Mon Mar  2 02:47:23 2009
From: Josef.Karthauser at geomerics.com (Josef Karthauser)
Date: Mon Mar  2 02:47:30 2009
Subject: Using ZFS swap hangs my machine :(.
Message-ID: <A78F73023D9DAC4B967091570A1540CF46F74D@THHS2EXBE1X.hostedservice2.net>

Is anyone successfully using ZFS swap under 7.1? 

 

I've created a VZOL for my swap partition, and can read and write to it
ok using 'dd', but whenever the kernel uses it the machine hangs solid.
:/.

 

Is this a known problem, or do I have some local weirdness going on?

 

Joe

 

brahe# uname -a

FreeBSD brahe.geomerics.com 7.1-STABLE FreeBSD 7.1-STABLE #12: Tue Jan
13 15:40:45 GMT 2009
root@brahe.geomerics.com:/usr/obj/usr/src/sys/BRAHE  amd64

 

% zfs get all store/swap

brahe# zfs get all store/swap

NAME        PROPERTY          VALUE                  SOURCE

store/swap  type              volume                 -

store/swap  creation          Fri Apr 18  8:13 2008  -

store/swap  used              1.06G                  -

store/swap  available         634G                   -

store/swap  referenced        1.06G                  -

store/swap  compressratio     1.00x                  -

store/swap  reservation       6G                     local

store/swap  volsize           6G                     -

store/swap  volblocksize      8K                     -

store/swap  checksum          on                     default

store/swap  compression       off                    default

store/swap  readonly          off                    default

store/swap  shareiscsi        off                    default

store/swap  copies            1                      default

store/swap  org.freebsd:swap  on                     local

 

 

From ivoras at freebsd.org  Mon Mar  2 05:01:03 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Mon Mar  2 05:01:09 2009
Subject: Using ZFS swap hangs my machine :(.
In-Reply-To: <A78F73023D9DAC4B967091570A1540CF46F74D@THHS2EXBE1X.hostedservice2.net>
References: <A78F73023D9DAC4B967091570A1540CF46F74D@THHS2EXBE1X.hostedservice2.net>
Message-ID: <gogla3$7vg$1@ger.gmane.org>

Josef Karthauser wrote:
> Is anyone successfully using ZFS swap under 7.1? 

It is well known swapping on ZFS doesn't work. See
http://wiki.freebsd.org/ZFSKnownProblems for more information.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090302/b6267e56/signature.pgp
From avg at icyb.net.ua  Mon Mar  2 05:23:52 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon Mar  2 05:23:59 2009
Subject: devd question
In-Reply-To: <20090228143453.GX41617@deviant.kiev.zoral.com.ua>
References: <y9lljrq1z89.fsf@deinprogramm.de>
	<20090228143453.GX41617@deviant.kiev.zoral.com.ua>
Message-ID: <49ABDDE2.6090402@icyb.net.ua>

on 28/02/2009 16:34 Kostik Belousov said the following:
> On Sat, Feb 28, 2009 at 02:13:10PM +0100, Michael Sperber wrote:
>> I'm trying to make devd run an stty command whenever a USB serial device
>> is attached.  Unfortunately, $device-name is ucom[0-9] and the device
>> names are /dev/cuaU[0-9] - how do I get the correct name in the device
>> action?  I haven't found a way to extract the number by itself, so I'm
>> stuck with specifying a separate rule for each number, like so:
>>
>> attach 100 {
>>         device-name "ucom0";
>>         action "stty -f /dev/cuaU0.init raw";
>> };
>>
>> Help would be much appreciated!
> 
> There are some other notifications that are send through devctl when
> cdev is created. They have system set to DEVFS, subsystem to CDEV,
> and type CREATE. The data is the /dev node name. I am not sure how
> to assign the action in the devd.

A tested example:
notify 1000 {
        match   "system"                "DEVFS";
        match   "subsystem"             "CDEV";
        match   "cdev"                  "^da[0-9]+$";
        action  "echo 't120o3l32 b>c+f+16' > /dev/speaker";
};

-- 
Andriy Gapon
From avg at icyb.net.ua  Mon Mar  2 05:53:33 2009
From: avg at icyb.net.ua (Andriy Gapon)
Date: Mon Mar  2 05:53:40 2009
Subject: devd question
In-Reply-To: <y9l63isav8g.fsf@deinprogramm.de>
References: <y9lljrq1z89.fsf@deinprogramm.de>	<20090228143453.GX41617@deviant.kiev.zoral.com.ua>	<49ABDDE2.6090402@icyb.net.ua>
	<y9l63isav8g.fsf@deinprogramm.de>
Message-ID: <49ABE4D7.1060403@icyb.net.ua>

on 02/03/2009 15:51 Michael Sperber said the following:
> Andriy Gapon <avg@icyb.net.ua> writes:
> 
>> on 28/02/2009 16:34 Kostik Belousov said the following:
>>> On Sat, Feb 28, 2009 at 02:13:10PM +0100, Michael Sperber wrote:
>>>> I'm trying to make devd run an stty command whenever a USB serial device
>>>> is attached.  Unfortunately, $device-name is ucom[0-9] and the device
>>>> names are /dev/cuaU[0-9] - how do I get the correct name in the device
>>>> action?  I haven't found a way to extract the number by itself, so I'm
>>>> stuck with specifying a separate rule for each number, like so:
>>>>
>>>> attach 100 {
>>>>         device-name "ucom0";
>>>>         action "stty -f /dev/cuaU0.init raw";
>>>> };
>>>>
>>>> Help would be much appreciated!
>>> There are some other notifications that are send through devctl when
>>> cdev is created. They have system set to DEVFS, subsystem to CDEV,
>>> and type CREATE. The data is the /dev node name. I am not sure how
>>> to assign the action in the devd.
>> A tested example:
>> notify 1000 {
>>         match   "system"                "DEVFS";
>>         match   "subsystem"             "CDEV";
>>         match   "cdev"                  "^da[0-9]+$";
>>         action  "echo 't120o3l32 b>c+f+16' > /dev/speaker";
>> };
> 
> I'm probably not understanding this---but how is the device number
> transferred from the "cdev" match to the "action" line?

You don't need to, you can use /dev/$cdev in action line.

-- 
Andriy Gapon
From ghelmer at palisadesys.com  Mon Mar  2 06:11:17 2009
From: ghelmer at palisadesys.com (Guy Helmer)
Date: Mon Mar  2 06:11:30 2009
Subject: 7.1 hangs in cache_lookup mutex?
In-Reply-To: <49A80A55.5070004@palisadesys.com>
References: <49A46AB4.3080003@palisadesys.com>	<200902261648.32845.jhb@freebsd.org>	<49A7173B.4030608@palisadesys.com>	<200902261753.29607.jhb@freebsd.org>
	<49A80A55.5070004@palisadesys.com>
Message-ID: <49ABE8FB.3060202@palisadesys.com>

Guy Helmer wrote:
> John Baldwin wrote:
>> On Thursday 26 February 2009 5:27:07 pm Guy Helmer wrote:
>>  
>>> John Baldwin wrote:
>>>    
>>>> On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote:
>>>>        
>>>>> db> show sleepchain 23110
>>>>> thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK
>>>>> thread 100208 (pid 23092, kvoop) is on a run queue
>>>>> db> show sleepchain 23092
>>>>> thread 100208 (pid 23092, kvoop) is on a run queue
>>>>>             
>>>> Ah, so this is normal (well, mostly) in that kvoop is simply on the 
>>>> run       
>> queue  
>>>> waiting for a CPU.  Can you find the thread pointer for kvoop and 
>>>> check on things such as if it is pinned and if so to which CPU 
>>>> (td_pinned will tell you the first, and td_sched->ts_cpu will tell 
>>>> you the second with ULE).
>>>>         
>>> (kgdb) print td->td_pinned
>>> $2 = 0
>>>     
>>
>> Ok, not pinned.
>>
>>  
>>>  From my captured ddb run:
>>> cpuid        = 3
>>> curthread    = 0xc5e2f000: pid 23090 "filter"
>>> curpcb       = 0xe6f90d90
>>> fpcurthread  = none
>>> idlethread   = 0xc442daf0: pid 11 "idle: cpu3"
>>> APIC ID      = 7
>>> currentldt   = 0x50
>>> spin locks held:
>>>     
>>
>> At http://www.freebsd.org/~jhb/gdb/ you can find my kgdb scripts.  If 
>> you source gdb6 you can run 'runtds' which will show you what each 
>> CPU is doing (more or less) in ps-style output.
>>
>>  
>>> I sure wish I could find the root cause of the hangs.  On a hunch, I 
>>> tried setting "machdep.cpu_idle_hlt=0" on the amd64 machine, and it 
>>> has run 32 hours without a hang.  It could just be coincidence, 
>>> though...
>>>     
>>
>> Ahhh, that actually could explain it perhaps.  Do your CPUs support 
>> C2 or higher sleep states for idle?  You can try limiting it to only 
>> C1 (or disable C1E in your BIOS if it has an option for that) to see 
>> if that fixes it.
>>
>>   
> I don't think the CPUs support anything lower than C1 - there is no 
> hw.acpi.cpu.cx_supported sysctl node, and hw.cpi.cpu.cx_lowest is C1.  
> C1-Enhanced was already disabled in the BIOS, at least on the machine 
> running amd64.  48 hours of runtime, and no hangs seen yet.  I did 
> reboot it this morning to check the sleep settings in the BIOS.
Despite having machdep.cpu_idle_hlt=0, the machine wedged for 40 hours 
over the weekend but came back to life by itself.  Could this be lost 
IPIs, or a bug in the scheduler?

Guy
From sperber at deinprogramm.de  Mon Mar  2 06:11:17 2009
From: sperber at deinprogramm.de (Michael Sperber)
Date: Mon Mar  2 06:11:31 2009
Subject: devd question
In-Reply-To: <49ABDDE2.6090402@icyb.net.ua> (Andriy Gapon's message of "Mon,
	02 Mar 2009 15:23:46 +0200")
References: <y9lljrq1z89.fsf@deinprogramm.de>
	<20090228143453.GX41617@deviant.kiev.zoral.com.ua>
	<49ABDDE2.6090402@icyb.net.ua>
Message-ID: <y9l63isav8g.fsf@deinprogramm.de>


Andriy Gapon <avg@icyb.net.ua> writes:

> on 28/02/2009 16:34 Kostik Belousov said the following:
>> On Sat, Feb 28, 2009 at 02:13:10PM +0100, Michael Sperber wrote:
>>> I'm trying to make devd run an stty command whenever a USB serial device
>>> is attached.  Unfortunately, $device-name is ucom[0-9] and the device
>>> names are /dev/cuaU[0-9] - how do I get the correct name in the device
>>> action?  I haven't found a way to extract the number by itself, so I'm
>>> stuck with specifying a separate rule for each number, like so:
>>>
>>> attach 100 {
>>>         device-name "ucom0";
>>>         action "stty -f /dev/cuaU0.init raw";
>>> };
>>>
>>> Help would be much appreciated!
>> 
>> There are some other notifications that are send through devctl when
>> cdev is created. They have system set to DEVFS, subsystem to CDEV,
>> and type CREATE. The data is the /dev node name. I am not sure how
>> to assign the action in the devd.
>
> A tested example:
> notify 1000 {
>         match   "system"                "DEVFS";
>         match   "subsystem"             "CDEV";
>         match   "cdev"                  "^da[0-9]+$";
>         action  "echo 't120o3l32 b>c+f+16' > /dev/speaker";
> };

I'm probably not understanding this---but how is the device number
transferred from the "cdev" match to the "action" line?

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
From lehmann at ans-netz.de  Mon Mar  2 08:05:27 2009
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon Mar  2 08:05:34 2009
Subject: restart a script in etc/rc.d
Message-ID: <20090302163843.cc66c55e.lehmann@ans-netz.de>

Hi,

I've below etc/rc.d bacula-fd and I copied it to bacula-fd2 because I
need to run 2 file daemons.
I'Ve modified every variable for the 2nd start script to be independent
from the first one.
It works so far but when I issue etc/rc.d/bacula-fd restart it also stops
the process started by bacula-fd2 probably because 

+ _find_processes /usr/local/sbin/bacula-fd . -ax

gets executed or whatever.

Is there a way in the rc.d scope to define to only look for the pid in
the pid file (why do we have them anyway when we search everytime) and
only kill the PID listed in the pid file?


root@nudel olivleh1> cat /var/run/bacula-fd.910
bacula-fd.9102.pid  bacula-fd.9104.pid  
root@nudel olivleh1> cat /var/run/bacula-fd.910*
33076
33125
root@nudel olivleh1> ps auxww | grep bacula-fd | grep -v SsJ
root     33076  0.0  0.4  8160  2980  ??  Ss    4:31PM   0:00.02 /usr/local/sbin/bacula-fd -u root -g wheel -v -c /usr/local/etc/bacula-fd.conf
root     33125  0.0  0.4  8160  2980  ??  Ss    4:35PM   0:00.01 /usr/local/sbin/bacula-fd -u root -g wheel -v -c /usr/local/etc/bacula-fd2.conf
root@nudel olivleh1> /usr/local/etc/rc.d/bacula-fd restart
Stopping bacula_fd.
Starting bacula_fd.
root@nudel olivleh1> ps auxww | grep bacula-fd | grep -v SsJ
root     33151  0.4  0.4  7136  2968  ??  Ss    4:36PM   0:00.01 /usr/local/sbin/bacula-fd -u root -g wheel -v -c /usr/local/etc/bacula-fd.conf
root@nudel olivleh1> /usr/local/etc/rc.d/bacula-fd2 restart
bacula_fd2 not running? (check /var/run/bacula-fd.9104.pid).
Starting bacula_fd2.
root@nudel olivleh1> ps auxww | grep bacula-fd | grep -v SsJ
root     33170  0.5  0.4  7136  2968  ??  Ss    4:36PM   0:00.01 /usr/local/sbin/bacula-fd -u root -g wheel -v -c /usr/local/etc/bacula-fd2.conf
root     33151  0.0  0.4  7136  2968  ??  Ss    4:36PM   0:00.01 /usr/local/sbin/bacula-fd -u root -g wheel -v -c /usr/local/etc/bacula-fd.conf

-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/
From jhb at freebsd.org  Mon Mar  2 10:32:00 2009
From: jhb at freebsd.org (John Baldwin)
Date: Mon Mar  2 10:32:07 2009
Subject: 7.1 new install halts on BTX error
In-Reply-To: <alpine.DEB.1.10.0901142326370.12175@martello.ucc.gu.uwa.edu.au>
References: <alpine.DEB.1.10.0901142326370.12175@martello.ucc.gu.uwa.edu.au>
Message-ID: <200903021210.39757.jhb@freebsd.org>

On Wednesday 28 January 2009 10:13:46 pm David Adam wrote:
> I upgraded my 7.0 system to 7.1-RELEASE with freebsd-update only to find 
> that it no longer boots correctly, instead crashing with a BTX backtrace. 
> If I break to the loader prompt and use 'ls /boot', I also get a 
> backtrace.
> 
> A new install of 7.1 on this hardware using a separate SCSI card and drive 
> array also leads to a BTX backtrace. I have copied this below as the first 
> (most repeatable) error and also included the other problems.
> 
> A fresh install of 7.0 works fine. FreeSBIE 1.0, based on FreeBSD 5.3, 
> also boots fine and will happily list the contents of the original drive's 
> /boot in the loader, although refuses to load the kernel. The FreeBSD 7.1 
> install CD also boots and allows me to install over FTP.
> 
> I have run into BTX problems on this machine before under -CURRENT (see 
> http://lists.freebsd.org/pipermail/freebsd-current/2008-October/089460.html
> ). Dmesg from 7.0 in 
> http://www.freebsd.org/cgi/query-pr.cgi?prp=125769-1-txt&n=/patch.txt
> 
> A new install of 7.1-RELEASE on separate disks leads to this backtrace:
> int=0000000d  err=00001840  efl=00010207  eip=00000511
> eax=04551364  ebx=00000000  ecx=00495cae  edx=00495cae
> esi=00000009  edi=00000001  ebp=00000000  esp=00495cae
> cs=002b  ds=0033  es=0033    fs=0033  gs=0033  ss=0033
> cs:eip=17 00 00 00 00 00 00 0c-00 00 00 00 00 00 00 b9
>        ae 5c 49 00 00 00 00 b9-ae 5c 49 00 00 00 00 c8
> ss:esp=43 18 3c 01 74 08 3c 04-0f 85 e4 00 00 00 0f b6
>        43 19 88 86 94 00 00 00-c7 46 30 00 00 00 00 3c
> 
> BTX error on boot with the 7.0 partition that has been upgraded to 7.1:
> 
> int=0000000d  err=00000000  efl=00010a92  eip=00000430
> eax=ffffff4c  ebx=00006c94  ecx=00000001  edx=00000080
> esi=00000001  edi=ffff9416  ebp=00000000  esp=0008f8b4
> cs=002b  ds=0033  es=002b    fs=0033  gs=0033  ss=0033
> cs:eip=6c 7f 94 48 00 00 00 00-0f af c1 47 00 00 00 00
>        00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> ss:eip=2b 00 00 00 33 00 00 00-00 0c 04 00 5f ad 08 04
>        00 00 00 00 0f 00 00 00-00 00 00 00 24 1c 06 00
> BTX halted
> 
> If I break to the loader prompt and try 'ls /boot', I get this backtrace:
> 
> int=00000006  err=00000000  efl=00010203  eip=00040c08
> eax=000000c6  ebx=00000008  ecx=eb000000  edx=000000c6
> esi=00000004  edi=000000c2  ebp=00000000  esp=0008f8b4
> cs=002b  ds=0033  es=002b    fs=0033  gs=0033  ss=0033
> cs:eip=8f 49 40 00 94 49 00 cb-00 00 04 00 00 00 fc 07
>        80 00 00 00 04 00 00 00-94 49 00 00 00 00 00 00
> ss:eip=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
>        00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
> BTX halted
> 
> Any thoughts or suggestions? I will stay on 7.0 for now but have a fairly 
> large supply of spare drives so I can test new installs if required.

I wonder if your stack is growing into the heap (the GPT stuff made the
loader a bit bigger).  You can try something like this:

--- //depot/vendor/freebsd/src/sys/boot/i386/libi386/Makefile	2007/10/12 17:12:19
+++ //depot/user/jhb/boot/sys/boot/i386/libi386/Makefile	2009/03/02 17:08:30
@@ -33,6 +33,10 @@
 CFLAGS+= -DSMBIOS_SERIAL_NUMBERS
 .endif
 
+.if !defined(LOADER_NO_GPT_SUPPORT)
+CFLAGS+=	-DLOADER_GPT_SUPPORT
+.endif
+
 # Include simple terminal emulation (cons25-compatible)
 CFLAGS+= -DTERM_EMU
 
--- //depot/vendor/freebsd/src/sys/boot/i386/libi386/biosdisk.c	2008/11/19 16:05:14
+++ //depot/user/jhb/boot/sys/boot/i386/libi386/biosdisk.c	2009/03/02 17:08:30
@@ -68,12 +68,14 @@
 # define DEBUG(fmt, args...)
 #endif
 
+#ifdef LOADER_GPT_SUPPORT
 struct gpt_part {
     int		gp_index;
     uuid_t	gp_type;
     uint64_t	gp_start;
     uint64_t	gp_end;
 };
+#endif
 
 struct open_disk {
     int			od_dkunit;		/* disk unit number */
@@ -90,25 +92,31 @@
 #define BD_FLOPPY		0x0004
 #define BD_LABELOK		0x0008
 #define BD_PARTTABOK		0x0010
+#ifdef LOADER_GPT_SUPPORT
 #define	BD_GPTOK		0x0020
+#endif
     union {
 	struct {
 	    struct disklabel		mbr_disklabel;
 	    int				mbr_nslices;	/* slice count */
 	    struct dos_partition	mbr_slicetab[NEXTDOSPART];
 	} _mbr;
+#ifdef LOADER_GPT_SUPPORT
 	struct {
 	    int				gpt_nparts;		
 	    struct gpt_part		*gpt_partitions;
 	} _gpt;
+#endif
     } _data;
 };
 
 #define	od_disklabel		_data._mbr.mbr_disklabel
 #define	od_nslices		_data._mbr.mbr_nslices
 #define	od_slicetab		_data._mbr.mbr_slicetab
+#ifdef LOADER_GPT_SUPPORT
 #define	od_nparts		_data._gpt.gpt_nparts
 #define	od_partitions		_data._gpt.gpt_partitions
+#endif
 
 /*
  * List of BIOS devices, translation from disk unit number to
@@ -130,8 +138,10 @@
 
 static int	bd_int13probe(struct bdinfo *bd);
 
+#ifdef LOADER_GPT_SUPPORT
 static void	bd_printgptpart(struct open_disk *od, struct gpt_part *gp,
 		    char *prefix, int verbose);
+#endif
 static void	bd_printslice(struct open_disk *od, struct dos_partition *dp,
 		    char *prefix, int verbose);
 static void	bd_printbsdslice(struct open_disk *od, daddr_t offset,
@@ -163,8 +173,10 @@
 static int	bd_open_mbr(struct open_disk *od, struct i386_devdesc *dev);
 static int	bd_bestslice(struct open_disk *od);
 static void	bd_checkextended(struct open_disk *od, int slicenum);
+#ifdef LOADER_GPT_SUPPORT
 static int	bd_open_gpt(struct open_disk *od, struct i386_devdesc *dev);
 static struct gpt_part *bd_best_gptpart(struct open_disk *od);
+#endif
 
 /*
  * Translate between BIOS device numbers and our private unit numbers.
@@ -286,6 +298,7 @@
 	
 	if (!bd_opendisk(&od, &dev)) {
 
+#ifdef LOADER_GPT_SUPPORT
 	    /* Do we have a GPT table? */
 	    if (od->od_flags & BD_GPTOK) {
 		for (j = 0; j < od->od_nparts; j++) {
@@ -293,9 +306,10 @@
 			od->od_partitions[j].gp_index);
 		    bd_printgptpart(od, &od->od_partitions[j], line, verbose);
 		}
-
+	    } else
+#endif
 	    /* Do we have a partition table? */
-	    } else if (od->od_flags & BD_PARTTABOK) {
+	    if (od->od_flags & BD_PARTTABOK) {
 		dptr = &od->od_slicetab[0];
 
 		/* Check for a "dedicated" disk */
@@ -339,6 +353,7 @@
     return (buf);
 }
 
+#ifdef LOADER_GPT_SUPPORT
 static uuid_t efi = GPT_ENT_TYPE_EFI;
 static uuid_t freebsd_boot = GPT_ENT_TYPE_FREEBSD_BOOT;
 static uuid_t freebsd_ufs = GPT_ENT_TYPE_FREEBSD_UFS;
@@ -380,6 +395,7 @@
 	    stats);
     pager_output(line);
 }
+#endif
 
 /*
  * Print information about slices on a disk.  For the size calculations we
@@ -561,8 +577,10 @@
     }
 
     /* Determine disk layout. */
+#ifdef LOADER_GPT_SUPPORT
     error = bd_open_gpt(od, dev);
     if (error)
+#endif
 	error = bd_open_mbr(od, dev);
     
  out:
@@ -826,6 +844,7 @@
 	return (prefslice);
 }
 
+#ifdef LOADER_GPT_SUPPORT
 static int
 bd_open_gpt(struct open_disk *od, struct i386_devdesc *dev)
 {
@@ -1003,6 +1022,7 @@
     }
     return (prefpart);
 }
+#endif
 
 static int 
 bd_close(struct open_file *f)
@@ -1022,8 +1042,10 @@
     if (od->od_flags & BD_FLOPPY)
 	delay(3000000);
 #endif
+#ifdef LOADER_GPT_SUPPORT
     if (od->od_flags & BD_GPTOK)
 	free(od->od_partitions);
+#endif
     free(od);
 }
 
--- //depot/vendor/freebsd/src/sys/boot/i386/libi386/devicename.c	2008/11/17 20:55:47
+++ //depot/user/jhb/boot/sys/boot/i386/libi386/devicename.c	2009/03/02 17:08:30
@@ -120,6 +120,7 @@
 		err = EUNIT;
 		goto fail;
 	    }
+#ifdef LOADER_GPT_SUPPORT
 	    if (*cp == 'p') {		/* got a GPT partition */
 		np = cp + 1;
 		slice = strtol(np, &cp, 10);
@@ -133,6 +134,7 @@
 		}
 		partition = 0xff;
 	    } else {
+#endif
 		if (*cp == 's') {		/* got a slice number */
 		    np = cp + 1;
 		    slice = strtol(np, &cp, 10);
@@ -149,7 +151,9 @@
 		    }
 		    cp++;
 		}
+#ifdef LOADER_GPT_SUPPORT
 	    }
+#endif
 	} else {
 		cp = np;
 	}
@@ -227,14 +231,18 @@
     case DEVT_DISK:
 	cp = buf;
 	cp += sprintf(cp, "%s%d", dev->d_dev->dv_name, dev->d_unit);
+#ifdef LOADER_GPT_SUPPORT
 	if (dev->d_kind.biosdisk.partition == 0xff) {
 	    cp += sprintf(cp, "p%d", dev->d_kind.biosdisk.slice);
 	} else {
+#endif
 	    if (dev->d_kind.biosdisk.slice > 0)
 		cp += sprintf(cp, "s%d", dev->d_kind.biosdisk.slice);
 	    if (dev->d_kind.biosdisk.partition >= 0)
 		cp += sprintf(cp, "%c", dev->d_kind.biosdisk.partition + 'a');
+#ifdef LOADER_GPT_SUPPORT
 	}
+#endif
 	strcat(cp, ":");
 	break;
 
--- //depot/vendor/freebsd/src/sys/boot/i386/loader/Makefile	2009/02/21 15:10:32
+++ //depot/user/jhb/boot/sys/boot/i386/loader/Makefile	2009/03/02 17:08:30
@@ -51,6 +51,9 @@
 .if !defined(LOADER_NO_GZIP_SUPPORT)
 CFLAGS+=	-DLOADER_GZIP_SUPPORT
 .endif
+.if !defined(LOADER_NO_GPT_SUPPORT)
+CFLAGS+=	-DLOADER_GPT_SUPPORT
+.endif
 
 # Always add MI sources 
 .PATH:		${.CURDIR}/../../common
@@ -91,12 +94,14 @@
 loader.help: help.common help.i386
 	cat ${.ALLSRC} | awk -f ${.CURDIR}/../../common/merge_help.awk > ${.TARGET}
 
+.if !defined(NOFORTH)
 .PATH: ${.CURDIR}/../../forth 
 FILES=	loader loader.help loader.4th support.4th loader.conf
 FILES+= screen.4th frames.4th beastie.4th
 # XXX INSTALLFLAGS_loader= -b
 FILESMODE_loader= ${BINMODE} -b
 FILESDIR_loader.conf=	/boot/defaults
+.endif
 
 .if !exists(${DESTDIR}/boot/loader.rc)
 FILES+=	loader.rc
--- //depot/vendor/freebsd/src/sys/boot/i386/loader/main.c	2008/11/17 20:55:47
+++ //depot/user/jhb/boot/sys/boot/i386/loader/main.c	2009/03/02 17:08:30
@@ -102,7 +102,7 @@
      */
     bios_getmem();
 
-#if defined(LOADER_BZIP2_SUPPORT) || defined(LOADER_FIREWIRE_SUPPORT) || defined(LOADER_ZFS_SUPPORT)
+#if defined(LOADER_BZIP2_SUPPORT) || defined(LOADER_FIREWIRE_SUPPORT) || defined(LOADER_GPT_SUPPORT) || defined(LOADER_ZFS_SUPPORT)
     heap_top = PTOV(memtop_copyin);
     memtop_copyin -= 0x300000;
     heap_bottom = PTOV(memtop_copyin);

-- 
John Baldwin
From rsmith at xs4all.nl  Mon Mar  2 10:42:03 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Mon Mar  2 10:42:11 2009
Subject: devd question
In-Reply-To: <49ABDDE2.6090402@icyb.net.ua>
References: <y9lljrq1z89.fsf@deinprogramm.de>
	<20090228143453.GX41617@deviant.kiev.zoral.com.ua>
	<49ABDDE2.6090402@icyb.net.ua>
Message-ID: <20090302182839.GA89715@slackbox.xs4all.nl>

On Mon, Mar 02, 2009 at 03:23:46PM +0200, Andriy Gapon wrote:
> on 28/02/2009 16:34 Kostik Belousov said the following:
> > On Sat, Feb 28, 2009 at 02:13:10PM +0100, Michael Sperber wrote:
> >> I'm trying to make devd run an stty command whenever a USB serial device
> >> is attached.  Unfortunately, $device-name is ucom[0-9] and the device
> >> names are /dev/cuaU[0-9] - how do I get the correct name in the device
> >> action?  I haven't found a way to extract the number by itself, so I'm
> >> stuck with specifying a separate rule for each number, like so:
> >>
> >> attach 100 {
> >>         device-name "ucom0";
> >>         action "stty -f /dev/cuaU0.init raw";
> >> };
> >>
> >> Help would be much appreciated!
> > 
> > There are some other notifications that are send through devctl when
> > cdev is created. They have system set to DEVFS, subsystem to CDEV,
> > and type CREATE. The data is the /dev node name. I am not sure how
> > to assign the action in the devd.
> 
> A tested example:
> notify 1000 {
>         match   "system"                "DEVFS";
>         match   "subsystem"             "CDEV";
>         match   "cdev"                  "^da[0-9]+$";
>         action  "echo 't120o3l32 b>c+f+16' > /dev/speaker";
> };

This system is missing from the devd.conf manual page, nor is DEVFS
mentioned in /usr/share/examples/etc/devd.conf. Is it documented
somewhere else?
 
Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090302/982a0d7c/attachment.pgp
From kostikbel at gmail.com  Mon Mar  2 10:49:01 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Mon Mar  2 10:49:08 2009
Subject: devd question
In-Reply-To: <20090302182839.GA89715@slackbox.xs4all.nl>
References: <y9lljrq1z89.fsf@deinprogramm.de>
	<20090228143453.GX41617@deviant.kiev.zoral.com.ua>
	<49ABDDE2.6090402@icyb.net.ua>
	<20090302182839.GA89715@slackbox.xs4all.nl>
Message-ID: <20090302184853.GE41617@deviant.kiev.zoral.com.ua>

On Mon, Mar 02, 2009 at 07:28:39PM +0100, Roland Smith wrote:
> On Mon, Mar 02, 2009 at 03:23:46PM +0200, Andriy Gapon wrote:
> > on 28/02/2009 16:34 Kostik Belousov said the following:
> > > On Sat, Feb 28, 2009 at 02:13:10PM +0100, Michael Sperber wrote:
> > >> I'm trying to make devd run an stty command whenever a USB serial device
> > >> is attached.  Unfortunately, $device-name is ucom[0-9] and the device
> > >> names are /dev/cuaU[0-9] - how do I get the correct name in the device
> > >> action?  I haven't found a way to extract the number by itself, so I'm
> > >> stuck with specifying a separate rule for each number, like so:
> > >>
> > >> attach 100 {
> > >>         device-name "ucom0";
> > >>         action "stty -f /dev/cuaU0.init raw";
> > >> };
> > >>
> > >> Help would be much appreciated!
> > > 
> > > There are some other notifications that are send through devctl when
> > > cdev is created. They have system set to DEVFS, subsystem to CDEV,
> > > and type CREATE. The data is the /dev node name. I am not sure how
> > > to assign the action in the devd.
> > 
> > A tested example:
> > notify 1000 {
> >         match   "system"                "DEVFS";
> >         match   "subsystem"             "CDEV";
> >         match   "cdev"                  "^da[0-9]+$";
> >         action  "echo 't120o3l32 b>c+f+16' > /dev/speaker";
> > };
> 
> This system is missing from the devd.conf manual page, nor is DEVFS
> mentioned in /usr/share/examples/etc/devd.conf. Is it documented
> somewhere else?

No, it is not documented anywhere.
Feel free to send me the documentation patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090302/852f7767/attachment.pgp
From lehmann at ans-netz.de  Mon Mar  2 11:25:25 2009
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon Mar  2 11:25:32 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>
	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
Message-ID: <20090302202520.eaf09b15.lehmann@ans-netz.de>

Hi Doug,

Doug Barton wrote:

> Also, the assignment of pidfile should really come after the defaults are 
> set.
> 
> If you do all that and it still doesn't work, send a diff of your two rc.d 
> scripts to the list.

PROVIDE is in both cases "utility" (probably a generic unchanged default)
 - I've changed it to utility2 for bacula-fd2 with no changes. Here the diff:

root@nudel rc.d> diff -u bacula-fd*
--- bacula-fd   2009-02-15 23:25:03.000000000 +0100
+++ bacula-fd2  2009-03-02 20:22:40.000000000 +0100
@@ -16,16 +16,16 @@
 
 . /etc/rc.subr
 
-name="bacula_fd"
+name="bacula_fd2"
 rcvar=${name}_enable
 command=/usr/local/sbin/bacula-fd
 
 load_rc_config $name
 
-pidfile="${bacula_fd_pidfile}"
+pidfile="${bacula_fd2_pidfile}"
 
-: ${bacula_fd_enable="NO"}
-: ${bacula_fd_flags=" -u root -g wheel -v -c /usr/local/etc/bacula-fd.conf"}
-: ${bacula_fd_pidfile="/var/run/bacula-fd.9102.pid"}
+: ${bacula_fd2_enable="NO"}
+: ${bacula_fd2_flags=" -u root -g wheel -v -c /usr/local/etc/bacula-fd2.conf"}
+: ${bacula_fd2_pidfile="/var/run/bacula-fd.9104.pid"}
 
 run_rc_command "$1"
Exit 1
root@nudel rc.d> grep bacula_fd /etc/rc.conf
bacula_fd_enable="YES"
bacula_fd2_enable="YES"
bacula_fd2_flags=" -u root -g wheel -v -c /usr/local/etc/bacula-fd2.conf"
bacula_fd2_pidfile="/var/run/bacula-fd.9104.pid"
root@nudel rc.d> 

-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/
From dougb at FreeBSD.org  Mon Mar  2 11:31:58 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Mon Mar  2 11:32:07 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <20090302163843.cc66c55e.lehmann@ans-netz.de>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>
Message-ID: <alpine.BSF.2.00.0903021100190.59723@qbhto.arg>

On Mon, 2 Mar 2009, Oliver Lehmann wrote:

> Hi,
>
> I've below etc/rc.d bacula-fd and I copied it to bacula-fd2 because I
> need to run 2 file daemons.
> I'Ve modified every variable for the 2nd start script to be independent
> from the first one.
> It works so far but when I issue etc/rc.d/bacula-fd restart it also stops
> the process started by bacula-fd2 probably because
>
> + _find_processes /usr/local/sbin/bacula-fd . -ax
>
> gets executed or whatever.
>
> Is there a way in the rc.d scope to define to only look for the pid in
> the pid file (why do we have them anyway when we search everytime) and
> only kill the PID listed in the pid file?

Well that is certainly how it is supposed to work, and that script defines 
pidfile which should prevent it from doing what you're suggesting. So 
let's check your work. :)

To accomplish what you want you would have to change all of the following 
in your duplicate script:

1. filename (IOW, you need 2 scripts with different names)
2. PROVIDE
3. name=
4. rcvar= (If you redefine $name that should be enough)
5. pidfile=
6. The names of the variables in the default assignments

Also, the assignment of pidfile should really come after the defaults are 
set.

If you do all that and it still doesn't work, send a diff of your two rc.d 
scripts to the list.


hope this helps,

Doug

-- 

     This .signature sanitized for your protection

From dougb at FreeBSD.org  Mon Mar  2 12:10:47 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Mon Mar  2 12:10:57 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <20090302202520.eaf09b15.lehmann@ans-netz.de>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
	<20090302202520.eaf09b15.lehmann@ans-netz.de>
Message-ID: <49AC3D3C.8040106@FreeBSD.org>

Oliver Lehmann wrote:
> Hi Doug,
> 
> Doug Barton wrote:
> 
>> Also, the assignment of pidfile should really come after the defaults are 
>> set.
>>
>> If you do all that and it still doesn't work, send a diff of your two rc.d 
>> scripts to the list.
> 
> PROVIDE is in both cases "utility" (probably a generic unchanged default)
>  - I've changed it to utility2 for bacula-fd2 with no changes. Here the diff:

That's arguably a bug. It should be something more descriptive. The
standard is that the name of the script file, the $name variable and
the PROVIDE line should all match.

> root@nudel rc.d> diff -u bacula-fd*
> --- bacula-fd   2009-02-15 23:25:03.000000000 +0100
> +++ bacula-fd2  2009-03-02 20:22:40.000000000 +0100
> @@ -16,16 +16,16 @@
>  
>  . /etc/rc.subr
>  
> -name="bacula_fd"
> +name="bacula_fd2"
>  rcvar=${name}_enable
>  command=/usr/local/sbin/bacula-fd
>  
>  load_rc_config $name
>  
> -pidfile="${bacula_fd_pidfile}"
> +pidfile="${bacula_fd2_pidfile}"

You missed the bit where I said that this should come after the
assignment of the defaults below.

> -: ${bacula_fd_enable="NO"}
> -: ${bacula_fd_flags=" -u root -g wheel -v -c /usr/local/etc/bacula-fd.conf"}
> -: ${bacula_fd_pidfile="/var/run/bacula-fd.9102.pid"}
> +: ${bacula_fd2_enable="NO"}
> +: ${bacula_fd2_flags=" -u root -g wheel -v -c /usr/local/etc/bacula-fd2.conf"}
> +: ${bacula_fd2_pidfile="/var/run/bacula-fd.9104.pid"}
>  
>  run_rc_command "$1"
> Exit 1
> root@nudel rc.d> grep bacula_fd /etc/rc.conf
> bacula_fd_enable="YES"
> bacula_fd2_enable="YES"
> bacula_fd2_flags=" -u root -g wheel -v -c /usr/local/etc/bacula-fd2.conf"
> bacula_fd2_pidfile="/var/run/bacula-fd.9104.pid"

Have you confirmed that the two pid files exist, and that they contain
the right information?

Doug

-- 

    This .signature sanitized for your protection
From rsmith at xs4all.nl  Mon Mar  2 12:13:59 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Mon Mar  2 12:14:10 2009
Subject: devd question
In-Reply-To: <20090302184853.GE41617@deviant.kiev.zoral.com.ua>
References: <y9lljrq1z89.fsf@deinprogramm.de>
	<20090228143453.GX41617@deviant.kiev.zoral.com.ua>
	<49ABDDE2.6090402@icyb.net.ua>
	<20090302182839.GA89715@slackbox.xs4all.nl>
	<20090302184853.GE41617@deviant.kiev.zoral.com.ua>
Message-ID: <20090302201349.GA92315@slackbox.xs4all.nl>

On Mon, Mar 02, 2009 at 08:48:53PM +0200, Kostik Belousov wrote:
<snip>
> > This system is missing from the devd.conf manual page, nor is DEVFS
> > mentioned in /usr/share/examples/etc/devd.conf. Is it documented
> > somewhere else?
> 
> No, it is not documented anywhere.
> Feel free to send me the documentation patch.

After some digging, I found the function devctl_notify in the kernel
sources (/usr/src/sys/kern/subr_bus.c). Is looks like the only way that events
are sent to devd, correct? If so, I can just use "grep -A 1 -R 'devctl_notify('"
from /usr/src/sys to find all types of events.

I'll go and pull the source for devd.conf from HEAD and 7-STABLE, and
incorporate what I find. Should I file a PR when I'm done?

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090302/ad48fda4/attachment.pgp
From oliver at FreeBSD.org  Mon Mar  2 13:02:30 2009
From: oliver at FreeBSD.org (Oliver Lehmann)
Date: Mon Mar  2 13:02:42 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <49AC3D3C.8040106@FreeBSD.org>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>
	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
	<20090302202520.eaf09b15.lehmann@ans-netz.de>
	<49AC3D3C.8040106@FreeBSD.org>
Message-ID: <20090302210228.44973.qmail@avocado.salatschuessel.net>

Doug Barton writes: 

> You missed the bit where I said that this should come after the
> assignment of the defaults below.

Ok, but... 

> Have you confirmed that the two pid files exist, and that they contain
> the right information?

Yes they both exists (probably because I define the variable in rc.conf
too). See my initial mail where I cat the contents of both files - they
both contain the right PID for their specific process. 

So - where is the problem now?
From dougb at FreeBSD.org  Mon Mar  2 13:05:35 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Mon Mar  2 13:05:47 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <20090302210228.44973.qmail@avocado.salatschuessel.net>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>
	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
	<20090302202520.eaf09b15.lehmann@ans-netz.de>
	<49AC3D3C.8040106@FreeBSD.org>
	<20090302210228.44973.qmail@avocado.salatschuessel.net>
Message-ID: <49AC4A1E.3050102@FreeBSD.org>

Oliver Lehmann wrote:
> Doug Barton writes:
>> You missed the bit where I said that this should come after the
>> assignment of the defaults below.
> 
> Ok, but...
>> Have you confirmed that the two pid files exist, and that they contain
>> the right information?
> 
> Yes they both exists (probably because I define the variable in rc.conf
> too). See my initial mail where I cat the contents of both files - they
> both contain the right PID for their specific process.
> So - where is the problem now?

Do this:
script bacula-fd2.log
sh -x /usr/local/etc/rc.d/bacula-fd2 restart

If the log is not too long, send it to the list. If it is, gzip it first.

Doug

-- 

    This .signature sanitized for your protection
From glen.j.barber at gmail.com  Mon Mar  2 13:40:03 2009
From: glen.j.barber at gmail.com (Glen Barber)
Date: Mon Mar  2 13:40:20 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <4ad871310903021310t46aecd98i56237d3eb6e4eafe@mail.gmail.com>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>
	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
	<20090302202520.eaf09b15.lehmann@ans-netz.de>
	<4ad871310903021310t46aecd98i56237d3eb6e4eafe@mail.gmail.com>
Message-ID: <4ad871310903021312n63b5dbefg25e2ed5adbd4a954@mail.gmail.com>

On Mon, Mar 2, 2009 at 4:10 PM, Glen Barber <glen.j.barber@gmail.com> wrote:
> On Mon, Mar 2, 2009 at 2:25 PM, Oliver Lehmann <lehmann@ans-netz.de> wrote:
>> Hi Doug,
>>
>> Doug Barton wrote:
>>
>>> Also, the assignment of pidfile should really come after the defaults are
>>> set.
>>>
>>> If you do all that and it still doesn't work, send a diff of your two rc.d
>>> scripts to the list.
>>
>> PROVIDE is in both cases "utility" (probably a generic unchanged default)
>> ?- I've changed it to utility2 for bacula-fd2 with no changes. Here the diff:
>>
>> root@nudel rc.d> diff -u bacula-fd*
>> --- bacula-fd ? 2009-02-15 23:25:03.000000000 +0100
>> +++ bacula-fd2 ?2009-03-02 20:22:40.000000000 +0100
>> @@ -16,16 +16,16 @@
>>
>> ?. /etc/rc.subr
>>
>> -name="bacula_fd"
>> +name="bacula_fd2"
>> ?rcvar=${name}_enable
>> ?command=/usr/local/sbin/bacula-fd
>>
>
> I didn't see anyone else mention this -- did you change 'bacula-fd' to
> 'bacula-fd2'?
>

Actually... That may not work (although, you could create a symlink,
but I doubt that'll help).  Ignore my noise.

-- 
Glen Barber
From glen.j.barber at gmail.com  Mon Mar  2 13:40:18 2009
From: glen.j.barber at gmail.com (Glen Barber)
Date: Mon Mar  2 13:40:32 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <20090302202520.eaf09b15.lehmann@ans-netz.de>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>
	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
	<20090302202520.eaf09b15.lehmann@ans-netz.de>
Message-ID: <4ad871310903021310t46aecd98i56237d3eb6e4eafe@mail.gmail.com>

On Mon, Mar 2, 2009 at 2:25 PM, Oliver Lehmann <lehmann@ans-netz.de> wrote:
> Hi Doug,
>
> Doug Barton wrote:
>
>> Also, the assignment of pidfile should really come after the defaults are
>> set.
>>
>> If you do all that and it still doesn't work, send a diff of your two rc.d
>> scripts to the list.
>
> PROVIDE is in both cases "utility" (probably a generic unchanged default)
> ?- I've changed it to utility2 for bacula-fd2 with no changes. Here the diff:
>
> root@nudel rc.d> diff -u bacula-fd*
> --- bacula-fd ? 2009-02-15 23:25:03.000000000 +0100
> +++ bacula-fd2 ?2009-03-02 20:22:40.000000000 +0100
> @@ -16,16 +16,16 @@
>
> ?. /etc/rc.subr
>
> -name="bacula_fd"
> +name="bacula_fd2"
> ?rcvar=${name}_enable
> ?command=/usr/local/sbin/bacula-fd
>

I didn't see anyone else mention this -- did you change 'bacula-fd' to
'bacula-fd2'?


-- 
Glen Barber
From artis.caune at gmail.com  Mon Mar  2 14:10:56 2009
From: artis.caune at gmail.com (Artis Caune)
Date: Mon Mar  2 14:12:50 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <9e20d71e0903021355i3ad66b8fx14bdc3b395e311a5@mail.gmail.com>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>
	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
	<20090302202520.eaf09b15.lehmann@ans-netz.de>
	<9e20d71e0903021355i3ad66b8fx14bdc3b395e311a5@mail.gmail.com>
Message-ID: <9e20d71e0903021410i26ca8088oc2de76009b2773d2@mail.gmail.com>

2009/3/2 Artis Caune <artis.caune@gmail.com>:
> 2009/3/2 Oliver Lehmann <lehmann@ans-netz.de>:
>> root@nudel rc.d> grep bacula_fd /etc/rc.conf
>> bacula_fd_enable="YES"
>> bacula_fd2_enable="YES"
>> bacula_fd2_flags=" -u root -g wheel -v -c /usr/local/etc/bacula-fd2.conf"
>> bacula_fd2_pidfile="/var/run/bacula-fd.9104.pid"
>
> can you try with:
> ? ?bacula_fd_pidfile="/var/run/bacula-fd.9102.pid"
> in /etc/rc.conf ?


There is logic error in bacula rc.d script. It should first set
default variables and only then use them.
    pidfile="${bacula_fd_pidfile}"
    : ${bacula_fd_pidfile="/var/run/bacula-fd.9102.pid"}

If you don't set pidfile in rc.conf, pidfile is "" so it kills all bacula-fd's





-- 
regards,
Artis Caune

<----. CCNA | BSDA
<----|====================
<----' didii FreeBSD
From dougb at FreeBSD.org  Mon Mar  2 14:23:38 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Mon Mar  2 14:23:45 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <9e20d71e0903021410i26ca8088oc2de76009b2773d2@mail.gmail.com>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>	
	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>	
	<20090302202520.eaf09b15.lehmann@ans-netz.de>	
	<9e20d71e0903021355i3ad66b8fx14bdc3b395e311a5@mail.gmail.com>
	<9e20d71e0903021410i26ca8088oc2de76009b2773d2@mail.gmail.com>
Message-ID: <49AC5C66.70301@FreeBSD.org>

Artis Caune wrote:
> 2009/3/2 Artis Caune <artis.caune@gmail.com>:
>> 2009/3/2 Oliver Lehmann <lehmann@ans-netz.de>:
>>> root@nudel rc.d> grep bacula_fd /etc/rc.conf
>>> bacula_fd_enable="YES"
>>> bacula_fd2_enable="YES"
>>> bacula_fd2_flags=" -u root -g wheel -v -c /usr/local/etc/bacula-fd2.conf"
>>> bacula_fd2_pidfile="/var/run/bacula-fd.9104.pid"
>> can you try with:
>>    bacula_fd_pidfile="/var/run/bacula-fd.9102.pid"
>> in /etc/rc.conf ?
> 
> 
> There is logic error in bacula rc.d script. It should first set
> default variables and only then use them.
>     pidfile="${bacula_fd_pidfile}"
>     : ${bacula_fd_pidfile="/var/run/bacula-fd.9102.pid"}
> 
> If you don't set pidfile in rc.conf, pidfile is "" so it kills all bacula-fd's

Yes, I tried to convince the OP to fix this, but he thought he had it
covered, so I'm giving him the opportunity to prove me wrong. :)
You've correctly identified what I believe to be the issue however.
(Namely that there is a disconnect between the variable "pidfile"
which is used throughout rc.subr, and ${name}_pidfile which has to be
assigned to $pidfile properly in the rc.d script or it won't work.)

I have "on my list" making this pidfile assignment internal to rc.subr
and therefore removing one more bullet from the foot-shooting gun, but
that would only help people who have the latest version of rc.subr,
which means that even if I fix it today we will still have to support
properly setting pidfile in the scripts for years (and versions of
FreeBSD) to come. Thus it's in the "less urgent" category.

Another potential solution would be to rewrite rc.subr to prefer
${name}_pidfile in all cases where it is defined, but then you still
have the backwards compatibility issue to deal with.


Doug

-- 

    This .signature sanitized for your protection
From artis.caune at gmail.com  Mon Mar  2 14:24:30 2009
From: artis.caune at gmail.com (Artis Caune)
Date: Mon Mar  2 14:24:37 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <20090302202520.eaf09b15.lehmann@ans-netz.de>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>
	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
	<20090302202520.eaf09b15.lehmann@ans-netz.de>
Message-ID: <9e20d71e0903021355i3ad66b8fx14bdc3b395e311a5@mail.gmail.com>

2009/3/2 Oliver Lehmann <lehmann@ans-netz.de>:
> root@nudel rc.d> grep bacula_fd /etc/rc.conf
> bacula_fd_enable="YES"
> bacula_fd2_enable="YES"
> bacula_fd2_flags=" -u root -g wheel -v -c /usr/local/etc/bacula-fd2.conf"
> bacula_fd2_pidfile="/var/run/bacula-fd.9104.pid"

can you try with:
    bacula_fd_pidfile="/var/run/bacula-fd.9102.pid"
in /etc/rc.conf ?





-- 
regards,
Artis Caune

<----. CCNA | BSDA
<----|====================
<----' didii FreeBSD
From nicolas at boiteameuh.org  Mon Mar  2 14:24:56 2009
From: nicolas at boiteameuh.org (nicolas@boiteameuh.org)
Date: Mon Mar  2 14:25:04 2009
Subject: IPC Sys5 for amd64?
Message-ID: <20090302220729.GN14832@boiteameuh.org>

Hi all,

I'm trying to install a PostgreSQL db on FreeBSD 7.1-RELEASE amd64.
It's seems I can't allocate a shared memory segment more than 2GB.
I tune sysctl ipc.shm* values but without effects.

IPC Sys5 isn't "64bit-aware" or the problem is elsewhere?

Regards,

-- 
Nicolas Haller
From max at love2party.net  Mon Mar  2 15:00:47 2009
From: max at love2party.net (Max Laier)
Date: Mon Mar  2 15:00:54 2009
Subject: IPC Sys5 for amd64?
In-Reply-To: <20090302220729.GN14832@boiteameuh.org>
References: <20090302220729.GN14832@boiteameuh.org>
Message-ID: <200903022347.59422.max@love2party.net>

On Monday 02 March 2009 23:07:30 nicolas@boiteameuh.org wrote:
> Hi all,
>
> I'm trying to install a PostgreSQL db on FreeBSD 7.1-RELEASE amd64.
> It's seems I can't allocate a shared memory segment more than 2GB.
> I tune sysctl ipc.shm* values but without effects.
>
> IPC Sys5 isn't "64bit-aware" or the problem is elsewhere?

It looks like shm_segsz in struct shmid_ds is of type int, so that will limit 
your segment.  Also there are the kernel config options SHMMAX and SHMMAXPGS.

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
From aryeh.friedman at gmail.com  Mon Mar  2 16:18:12 2009
From: aryeh.friedman at gmail.com (Aryeh M. Friedman)
Date: Mon Mar  2 16:18:19 2009
Subject: gmirror does not initialize properally
In-Reply-To: <49AB7903.4050104@modulus.org>
References: <49AB66A4.4030509@gmail.com> <49AB7903.4050104@modulus.org>
Message-ID: <49AC773F.6080908@gmail.com>

Andrew Snow wrote:
>
> Sorry, I meant "label -h" instead of just plain "label"... was getting 
> confused with gstripe.
>
No matter what I attempt to do with the source drive (ad8) I get 
oprtation not permitted... it lets me install the slave drive (ad14) 
just fine:



flosoft# gmirror label -h -vb round-robin gm0 /dev/ad14
Metadata value stored on ad14.
Done.
flosoft# gmirror status
      Name    Status  Components
mirror/gm0  COMPLETE  ad14
flosoft# gmirror insert gm0 /dev/ad8
gmirror: Cannot access provider ad8.
flosoft# gmirror insert gm0 /dev/ad8s2
gmirror: Provider ad8s2 too small.
flosoft# gmirror insert gm0 /dev/ad8s2a
gmirror: Provider ad8s2a too small.
flosoft# gmirror label -vb round-robin gm0 /dev/da0
gmirror: Can't get informations about /dev/da0: No such file or directory.
flosoft# gmirror label -vb round-robin gm0 /dev/ad8
gmirror: Can't store metadata on /dev/ad8: Operation not permitted.

From hk at alogis.com  Mon Mar  2 19:03:57 2009
From: hk at alogis.com (Holger Kipp)
Date: Mon Mar  2 19:04:04 2009
Subject: gmirror does not initialize properally
In-Reply-To: <49AC773F.6080908@gmail.com>
References: <49AB66A4.4030509@gmail.com> <49AB7903.4050104@modulus.org>
	<49AC773F.6080908@gmail.com>
Message-ID: <20090303025146.GA57952@intserv.int1.b.intern>

On Mon, Mar 02, 2009 at 07:18:07PM -0500, Aryeh M. Friedman wrote:
> Andrew Snow wrote:
> >
> >Sorry, I meant "label -h" instead of just plain "label"... was getting 
> >confused with gstripe.
> >
> No matter what I attempt to do with the source drive (ad8) I get 
> oprtation not permitted... it lets me install the slave drive (ad14) 
> just fine:
> 
> 
> 
> flosoft# gmirror label -h -vb round-robin gm0 /dev/ad14
> Metadata value stored on ad14.
> Done.
> flosoft# gmirror status
>      Name    Status  Components
> mirror/gm0  COMPLETE  ad14
> flosoft# gmirror insert gm0 /dev/ad8
> gmirror: Cannot access provider ad8.
> flosoft# gmirror insert gm0 /dev/ad8s2
> gmirror: Provider ad8s2 too small.
> flosoft# gmirror insert gm0 /dev/ad8s2a
> gmirror: Provider ad8s2a too small.
> flosoft# gmirror label -vb round-robin gm0 /dev/da0
> gmirror: Can't get informations about /dev/da0: No such file or directory.
> flosoft# gmirror label -vb round-robin gm0 /dev/ad8
> gmirror: Can't store metadata on /dev/ad8: Operation not permitted.

was ad8 part of gmirror once? in that case you might want to try
gmirror forget 
such that gmirror will forget about not connected components first.
Only then storing new metadata on /dev/ad8 might be permitted again.
I experienced such a problem once when I played with gmirror setup
during new server installation...

Best regards,
Holger
From lehmann at ans-netz.de  Mon Mar  2 21:52:12 2009
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon Mar  2 21:52:19 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <49AC5C66.70301@FreeBSD.org>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>
	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>
	<20090302202520.eaf09b15.lehmann@ans-netz.de>
	<9e20d71e0903021355i3ad66b8fx14bdc3b395e311a5@mail.gmail.com>
	<9e20d71e0903021410i26ca8088oc2de76009b2773d2@mail.gmail.com>
	<49AC5C66.70301@FreeBSD.org>
Message-ID: <20090303065208.87200365.lehmann@ans-netz.de>

Doug Barton wrote:

> Artis Caune wrote:
> > There is logic error in bacula rc.d script. It should first set
> > default variables and only then use them.
> >     pidfile="${bacula_fd_pidfile}"
> >     : ${bacula_fd_pidfile="/var/run/bacula-fd.9102.pid"}
> > 
> > If you don't set pidfile in rc.conf, pidfile is "" so it kills all bacula-fd's
> 
> Yes, I tried to convince the OP to fix this, but he thought he had it
> covered, so I'm giving him the opportunity to prove me wrong. :)

Yeah this did it - Its working now.
I thought you where just telling me that to have another pidfile for the
2nd start script - I missed the point that it was empty for the first one
and because of that it is falling back to ps...

I'll probably write a PR and commit it after aproval for PROVIDE and the
pidfile setting...

-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/
From ross.penner at gmail.com  Tue Mar  3 00:00:18 2009
From: ross.penner at gmail.com (Ross Penner)
Date: Tue Mar  3 00:00:38 2009
Subject: powerd causing crash on Mini-ITX EN1200
In-Reply-To: <F5A1D5F3-5DBE-453D-8FEC-1AD034803922@jump-ing.de>
References: <f80199c40902260944q430b7faavd9fc7891c6ecb7b0@mail.gmail.com>
	<F5A1D5F3-5DBE-453D-8FEC-1AD034803922@jump-ing.de>
Message-ID: <f80199c40903030000g2fba7e57g91d06a498b6c2f04@mail.gmail.com>

On Mon, Mar 2, 2009 at 2:13 AM, Markus Hitter <mah@jump-ing.de> wrote:
>
> Am 26.02.2009 um 18:44 schrieb Ross Penner:
>
>> When I enable powerd, it is only but a matter of time before my
>> machine will lock up completely. I've had this problem since I've
>> migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any
>> problems.
>
> As FreeBSD Stable is a continuous development, you have good chances to
> narrow down the culprit by bisecting. The assumption is, one single SVN
> commit broke your functionality and you just have to find out which one.
>
> Get sources from SVN, then switch to the earliest Stable/7 to confirm your
> assumption ("it broke with 7"). If it works, check out a few thousand SVN
> revisions later, try again. If it doesn't work, switch to an earlier
> revision, a late Stable/6. Each step cuts the number of SVN revisions in
> question in half, after some 10 or 12 iterations you're down to a single
> revision.
>
> Having a single revision pretty much directly points you to what the problem
> is. This helps developers very much and with some luck you can reverse-apply
> this change to a more recent set of the sources.
>
>
> MarKus
>
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. Markus Hitter
> http://www.jump-ing.de/

Thanks for the idea! is downgrading possible or will I have to reinstall?
From cristiano.deana at gmail.com  Tue Mar  3 02:24:30 2009
From: cristiano.deana at gmail.com (Cristiano Deana)
Date: Tue Mar  3 02:24:37 2009
Subject: bce: unable to fix media
Message-ID: <d8a4930a0903030202u5e965e3o9a630529de375f8d@mail.gmail.com>

Hi,

tuning my network fixing nic's speed and duplex (both on server and
switch) i got this error with bce driver:

# ifconfig bce0
bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=1bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4>
        ether 00:15:c5:fe:11:01
        inet 192.168.1.13 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (1000baseSX <full-duplex>)
        status: active
# ifconfig bce0 media 1000baseSX
ifconfig: SIOCSIFMEDIA (media): Device not configured

or (according to bce(4)):

# ifconfig bce0 media 1000baseTX
ifconfig: SIOCSIFMEDIA (media): Device not configured

system:
# uname -rsm
FreeBSD 7.1-RELEASE-p3 amd64

bce0@pci0:6:0:0:        class=0x020000 card=0x01bb1028 chip=0x16ac14e4
rev=0x12 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'NetXtreme II BCM5708S Gigabit Ethernet'
    class      = network
    subclass   = ethernet

bce0: <Broadcom NetXtreme II BCM5708 1000Base-SX (B2)> mem
0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci6
miibus0: <MII bus> on bce0
brgphy0: <BCM5708S 1000/2500BaseSX PHY> PHY 2 on miibus0
brgphy0:  1000baseSX-FDX, auto
bce0: Ethernet address: 00:15:c5:fe:0f:c6
bce0: [ITHREAD]
bce0: ASIC (0x57081021); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W
(0x02090105); Flags( MFW MSI )

-- 
Cris, member of G.U.F.I
Italian FreeBSD User Group
http://www.gufi.org/
From mah at jump-ing.de  Tue Mar  3 03:03:29 2009
From: mah at jump-ing.de (Markus Hitter)
Date: Tue Mar  3 03:03:37 2009
Subject: powerd causing crash on Mini-ITX EN1200
In-Reply-To: <f80199c40903030000g2fba7e57g91d06a498b6c2f04@mail.gmail.com>
References: <f80199c40902260944q430b7faavd9fc7891c6ecb7b0@mail.gmail.com>
	<F5A1D5F3-5DBE-453D-8FEC-1AD034803922@jump-ing.de>
	<f80199c40903030000g2fba7e57g91d06a498b6c2f04@mail.gmail.com>
Message-ID: <6667FB2D-BBB5-4E1D-B08D-B31679E04595@jump-ing.de>


Am 03.03.2009 um 09:00 schrieb Ross Penner:

> On Mon, Mar 2, 2009 at 2:13 AM, Markus Hitter <mah@jump-ing.de> wrote:
>>
>> Am 26.02.2009 um 18:44 schrieb Ross Penner:
>>
>>> When I enable powerd, it is only but a matter of time before my
>>> machine will lock up completely. I've had this problem since I've
>>> migrated to FreeBSD 7 from 6. FreeBSD 6 never seemed to have any
>>> problems.
>>
>> As FreeBSD Stable is a continuous development, you have good  
>> chances to
>> narrow down the culprit by bisecting. The assumption is, one  
>> single SVN
>> commit broke your functionality and you just have to find out  
>> which one.
>>
>> Get sources from SVN, then switch to the earliest Stable/7 to  
>> confirm your
>> assumption ("it broke with 7"). If it works, check out a few  
>> thousand SVN
>> revisions later, try again. If it doesn't work, switch to an earlier
>> revision, a late Stable/6. Each step cuts the number of SVN  
>> revisions in
>> question in half, after some 10 or 12 iterations you're down to a  
>> single
>> revision.
>>
>> Having a single revision pretty much directly points you to what  
>> the problem
>> is. This helps developers very much and with some luck you can  
>> reverse-apply
>> this change to a more recent set of the sources.
>
> Thanks for the idea! is downgrading possible or will I have to  
> reinstall?

Downgrading is possible. "make buildkernel", "make buildworld", etc.


MarKus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/




From pyunyh at gmail.com  Tue Mar  3 04:00:52 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue Mar  3 04:00:59 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <22F5A82D-290D-4B84-92AB-670EDB49AF22@stevenwills.com>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
	<20090226041023.GD63173@michelle.cdnetworks.co.kr>
	<594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com>
	<20090226042732.GE63173@michelle.cdnetworks.co.kr>
	<22F5A82D-290D-4B84-92AB-670EDB49AF22@stevenwills.com>
Message-ID: <20090303120734.GB84434@michelle.cdnetworks.co.kr>

On Thu, Feb 26, 2009 at 12:36:48AM -0500, Steve Wills wrote:
> On Feb 25, 2009, at 11:27 PM, Pyun YongHyeon wrote:
> 
> >On Wed, Feb 25, 2009 at 11:15:38PM -0500, Steve Wills wrote:
> >
> >[...]
> >>>I guess re(4) thinks it lost established link. How about unplug and
> >>>then replug UTP cable? Would you show me "devinfo -rv | grep phy"?
> >>
> >>rgephy0 pnpinfo oui=0x732 model=0x11 rev=0x2 at phyno=1
> >>
> >
> >And unpluging/repluging didn't help?
> 
> No, didn't help.
> 

Ok, when you plug UTP cable can you see "re0: link state changed to
UP" in dmesg output? Or if you unplug the cable, you should see
"re0: link state changed to DOWN"(With "tail -f /var/log/message",
you can easily check this.)
If this is not the case something is wrong on RTL8168D. Since
you've said re0 works for a short time, can you see "re0: link
state changed to DOWN" on your dmesg output right before seeing
"re0: PHY read failed" message?

I've also attached patch which may apply to your case. Would you
give it spin? Note, the patch was generated against CURRENT, so
you should use re(4) in CURRENT. Just save your old re(4)/rl(4)
files and download if_re.c, if_rl.c and if_rlreg.h from CURRENT
and apply the patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: re.RTL8168D.patch
Type: text/x-diff
Size: 2128 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090303/530fd1cb/re.RTL8168D.bin
From pyunyh at gmail.com  Tue Mar  3 04:25:13 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue Mar  3 04:25:21 2009
Subject: bce: unable to fix media
In-Reply-To: <d8a4930a0903030202u5e965e3o9a630529de375f8d@mail.gmail.com>
References: <d8a4930a0903030202u5e965e3o9a630529de375f8d@mail.gmail.com>
Message-ID: <20090303123156.GC84434@michelle.cdnetworks.co.kr>

On Tue, Mar 03, 2009 at 11:02:13AM +0100, Cristiano Deana wrote:
> Hi,
> 
> tuning my network fixing nic's speed and duplex (both on server and
> switch) i got this error with bce driver:
> 
> # ifconfig bce0
> bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=1bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4>
>         ether 00:15:c5:fe:11:01
>         inet 192.168.1.13 netmask 0xffffff00 broadcast 192.168.1.255
>         media: Ethernet autoselect (1000baseSX <full-duplex>)
>         status: active
> # ifconfig bce0 media 1000baseSX
> ifconfig: SIOCSIFMEDIA (media): Device not configured
> 

I don't have experience on bce(4) hardwares so I'm not sure but how
about adding full-duplex?
e.g. ifconfig bce0 media 1000baseSX mediaopt full-duplex
For gigabit connections you should always use auto-negotiation.
There is no need to manually specify link speed/duplex except
connecting to broken link partners.

> or (according to bce(4)):
> 
> # ifconfig bce0 media 1000baseTX
> ifconfig: SIOCSIFMEDIA (media): Device not configured
> 

I guess your PHY type is not for 1000baseT. That's not valid option
for your controller.

> system:
> # uname -rsm
> FreeBSD 7.1-RELEASE-p3 amd64
> 
> bce0@pci0:6:0:0:        class=0x020000 card=0x01bb1028 chip=0x16ac14e4
> rev=0x12 hdr=0x00
>     vendor     = 'Broadcom Corporation'
>     device     = 'NetXtreme II BCM5708S Gigabit Ethernet'
>     class      = network
>     subclass   = ethernet
> 
> bce0: <Broadcom NetXtreme II BCM5708 1000Base-SX (B2)> mem
> 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci6
> miibus0: <MII bus> on bce0
> brgphy0: <BCM5708S 1000/2500BaseSX PHY> PHY 2 on miibus0
> brgphy0:  1000baseSX-FDX, auto
> bce0: Ethernet address: 00:15:c5:fe:0f:c6
> bce0: [ITHREAD]
> bce0: ASIC (0x57081021); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W
From cristiano.deana at gmail.com  Tue Mar  3 05:26:13 2009
From: cristiano.deana at gmail.com (Cristiano Deana)
Date: Tue Mar  3 05:26:22 2009
Subject: bce: unable to fix media
In-Reply-To: <20090303123156.GC84434@michelle.cdnetworks.co.kr>
References: <d8a4930a0903030202u5e965e3o9a630529de375f8d@mail.gmail.com>
	<20090303123156.GC84434@michelle.cdnetworks.co.kr>
Message-ID: <d8a4930a0903030526m4807cc3hc0b5df2d41696ffc@mail.gmail.com>

2009/3/3 Pyun YongHyeon <pyunyh@gmail.com>:

>> # ifconfig bce0 media 1000baseSX
>> ifconfig: SIOCSIFMEDIA (media): Device not configured

> I don't have experience on bce(4) hardwares so I'm not sure but how
> about adding full-duplex?
> e.g. ifconfig bce0 media 1000baseSX mediaopt full-duplex

Thanks, that works. But put the card in "no carrier".
I will let in autoselect


>> or (according to bce(4)):
>>
>> # ifconfig bce0 media 1000baseTX
>> ifconfig: SIOCSIFMEDIA (media): Device not configured
>>
>
> I guess your PHY type is not for 1000baseT. That's not valid option
> for your controller.

I think there is a typo o incomplete description in bce(4):

     1000baseTX   Set 1000baseTX operation over twisted pair.  Only
                  full-duplex mode is supported.

No entry for "1000baseSX".

-- 
Cris, member of G.U.F.I
Italian FreeBSD User Group
http://www.gufi.org/
From ivoras at freebsd.org  Tue Mar  3 05:30:00 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Tue Mar  3 05:30:09 2009
Subject: IPC Sys5 for amd64?
In-Reply-To: <20090302220729.GN14832@boiteameuh.org>
References: <20090302220729.GN14832@boiteameuh.org>
Message-ID: <gojbcc$4es$1@ger.gmane.org>

nicolas@boiteameuh.org wrote:
> Hi all,
> 
> I'm trying to install a PostgreSQL db on FreeBSD 7.1-RELEASE amd64.
> It's seems I can't allocate a shared memory segment more than 2GB.
> I tune sysctl ipc.shm* values but without effects.
> 
> IPC Sys5 isn't "64bit-aware" or the problem is elsewhere?

Yes, SYSVSHM is limited to 2 GB in 7.1. It has recently been extended in
-CURRENT, it will probably be MFC-ed to 7-STABLE (7.2) soon.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090303/90008447/signature.pgp
From karl at denninger.net  Tue Mar  3 05:35:55 2009
From: karl at denninger.net (Karl Denninger)
Date: Tue Mar  3 05:36:02 2009
Subject: IPC Sys5 for amd64?
In-Reply-To: <gojbcc$4es$1@ger.gmane.org>
References: <20090302220729.GN14832@boiteameuh.org>
	<gojbcc$4es$1@ger.gmane.org>
Message-ID: <49AD3237.2050208@denninger.net>

Ivan Voras wrote:
> nicolas@boiteameuh.org wrote:
>   
>> Hi all,
>>
>> I'm trying to install a PostgreSQL db on FreeBSD 7.1-RELEASE amd64.
>> It's seems I can't allocate a shared memory segment more than 2GB.
>> I tune sysctl ipc.shm* values but without effects.
>>
>> IPC Sys5 isn't "64bit-aware" or the problem is elsewhere?
>>     
>
> Yes, SYSVSHM is limited to 2 GB in 7.1. It has recently been extended in
> -CURRENT, it will probably be MFC-ed to 7-STABLE (7.2) soon.
>   
Aha!  Well, that makes sense :)

I was wondering why I could tune up the sysctls but the call to allocate 
still failed :)

For those of us who have complex dbms installations that would be VERY 
useful, as RAM is cheap nowdays.

-- 
--
Karl Denninger
karl@denninger.net


From ltning at anduin.net  Tue Mar  3 07:22:27 2009
From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=)
Date: Tue Mar  3 07:22:34 2009
Subject: carpX: incorrect hash with IP aliases
Message-ID: <D4FB7A0E-9CA3-4B60-A2C7-3231ACFDBAA8@anduin.net>

Hi,

whenever I configure an extra IP on one of my CARP interfaces, traffic  
on that particular subnet slows to a crawl (the primary IP of the  
interface is the gateway IP), and I get lots of
  carp4: incorrect hash
in dmesg.

I see this issue referenced also in
   http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017160.html
and there are suggestions this is a known issue - however I still see  
it in FreeBSD 7.1 (pfSense 1.2.3-prerelease). I cannot find a PR on  
this, but my searching skills may be inadequate..

Am I doing something wrong? I tried assigning the alias with both /32  
and /24 netmasks.

/Eirik
From torfinn.ingolfsen at broadpark.no  Tue Mar  3 08:32:43 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Tue Mar  3 08:32:55 2009
Subject: bce: unable to fix media
In-Reply-To: <d8a4930a0903030526m4807cc3hc0b5df2d41696ffc@mail.gmail.com>
References: <d8a4930a0903030202u5e965e3o9a630529de375f8d@mail.gmail.com>
	<20090303123156.GC84434@michelle.cdnetworks.co.kr>
	<d8a4930a0903030526m4807cc3hc0b5df2d41696ffc@mail.gmail.com>
Message-ID: <20090303173240.898a5d6a.torfinn.ingolfsen@broadpark.no>

On Tue, 03 Mar 2009 14:26:11 +0100
Cristiano Deana <cristiano.deana@gmail.com> wrote:

> I think there is a typo o incomplete description in bce(4):
> 
>      1000baseTX   Set 1000baseTX operation over twisted pair.  Only
>                   full-duplex mode is supported.
> 
> No entry for "1000baseSX".

Is anyone (besides you) using bce adapter with fibre-optic[1] PHY's?
Perhaps it is not tested much?

References:
1) http://en.wikipedia.org/wiki/Gigabit_ethernet#1000BASE-SX
-- 
Regards,
Torfinn Ingolfsen

From dougb at FreeBSD.org  Tue Mar  3 08:48:41 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Tue Mar  3 08:48:52 2009
Subject: restart a script in etc/rc.d
In-Reply-To: <20090303065208.87200365.lehmann@ans-netz.de>
References: <20090302163843.cc66c55e.lehmann@ans-netz.de>	<alpine.BSF.2.00.0903021100190.59723@qbhto.arg>	<20090302202520.eaf09b15.lehmann@ans-netz.de>	<9e20d71e0903021355i3ad66b8fx14bdc3b395e311a5@mail.gmail.com>	<9e20d71e0903021410i26ca8088oc2de76009b2773d2@mail.gmail.com>	<49AC5C66.70301@FreeBSD.org>
	<20090303065208.87200365.lehmann@ans-netz.de>
Message-ID: <49AD5F60.7040208@FreeBSD.org>

Oliver Lehmann wrote:
> Doug Barton wrote:
> 
>> Artis Caune wrote:
>>> There is logic error in bacula rc.d script. It should first set
>>> default variables and only then use them.
>>>     pidfile="${bacula_fd_pidfile}"
>>>     : ${bacula_fd_pidfile="/var/run/bacula-fd.9102.pid"}
>>>
>>> If you don't set pidfile in rc.conf, pidfile is "" so it kills all bacula-fd's
>> Yes, I tried to convince the OP to fix this, but he thought he had it
>> covered, so I'm giving him the opportunity to prove me wrong. :)
> 
> Yeah this did it - Its working now.
> I thought you where just telling me that to have another pidfile for the
> 2nd start script - I missed the point that it was empty for the first one
> and because of that it is falling back to ps...
> 
> I'll probably write a PR and commit it after aproval for PROVIDE and the
> pidfile setting...

Excellent. :)


Doug

-- 

    This .signature sanitized for your protection
From bp at barryp.org  Tue Mar  3 09:31:32 2009
From: bp at barryp.org (Barry Pederson)
Date: Tue Mar  3 09:31:46 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <200902172307.n1HN74ml025580@pyroxene.sentex.ca>
References: <499551B9.7050805@samsco.org>
	<200902172307.n1HN74ml025580@pyroxene.sentex.ca>
Message-ID: <49AD6130.8040703@barryp.org>

Mike Tancsa wrote:
> At 05:55 AM 2/13/2009, Scott Long wrote:
> 
>> If, instead, it reports a value of '1', you are likely affected.  Note
>> that it may be normal for USB memory devices to report a low number.
>> Also, many legacy SCSI disks, and devices that are not disks, may also 
>> be expected to report a low number.
> 
> Hi Scott,
>         I tested with the patch on my areca controller, and it still 
> reports 1 post patch.  (On RELENG_6, it shows 255 with the same controller)

I can report a "metoo" on a 7.0-RELEASE-p3 machine with an Areca 
ARC-1212 card and SATA drives.  "camcontrol tags da0" reports:

	(pass0:arcmsr0:0:0:0): device openings: 1

The machine is just a dog sometimes.  Haven't tried the patch though.

	Barry

From max at love2party.net  Tue Mar  3 09:52:15 2009
From: max at love2party.net (Max Laier)
Date: Tue Mar  3 09:52:22 2009
Subject: carpX: incorrect hash with IP aliases
In-Reply-To: <D4FB7A0E-9CA3-4B60-A2C7-3231ACFDBAA8@anduin.net>
References: <D4FB7A0E-9CA3-4B60-A2C7-3231ACFDBAA8@anduin.net>
Message-ID: <200903031852.11731.max@love2party.net>

On Tuesday 03 March 2009 15:57:50 Eirik ?verby wrote:
> Hi,
>
> whenever I configure an extra IP on one of my CARP interfaces, traffic
> on that particular subnet slows to a crawl (the primary IP of the
> interface is the gateway IP), and I get lots of
>   carp4: incorrect hash
> in dmesg.
>
> I see this issue referenced also in
>    http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017160.html
> and there are suggestions this is a known issue - however I still see
> it in FreeBSD 7.1 (pfSense 1.2.3-prerelease). I cannot find a PR on
> this, but my searching skills may be inadequate..

You might be referring to http://www.freebsd.org/cgi/query-pr.cgi?pr=121574 
which should have been fixed with rev 1.54 (MFC'ed in 1.52.2.1 to RELENG_7) of 
ip_carp.c

> Am I doing something wrong? I tried assigning the alias with both /32
> and /24 netmasks.

Make sure that you are configuring the same aliases with the same netmasks on 
all members of the carp group - preferably before bringing the interface up 
for the first time (though it should properly recalculate the hashes as you 
add aliases).  As you seem to be using pfsense you might want to check with 
them to make sure they have the fix in their build - though I recall it was a 
joined effort back then.

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
From mike at sentex.net  Tue Mar  3 10:40:46 2009
From: mike at sentex.net (Mike Tancsa)
Date: Tue Mar  3 10:40:59 2009
Subject: HEADS UP: Major CAM performance regression
In-Reply-To: <49AD6130.8040703@barryp.org>
References: <499551B9.7050805@samsco.org>
	<200902172307.n1HN74ml025580@pyroxene.sentex.ca>
	<49AD6130.8040703@barryp.org>
Message-ID: <200903031840.n23IeXuk032580@lava.sentex.ca>

At 11:56 AM 3/3/2009, Barry Pederson wrote:

>I can report a "metoo" on a 7.0-RELEASE-p3 machine with an Areca 
>ARC-1212 card and SATA drives.  "camcontrol tags da0" reports:
>
>         (pass0:arcmsr0:0:0:0): device openings: 1
>
>The machine is just a dog sometimes.  Haven't tried the patch though.


RELENG_7 has all the fixes in.  There seem to be quite a few cam 
fixes plus the one areca fix.  With the patches, post reboot I now see

da1: Command Queueing Enabled

raw throughput seems to be the same (which is should). It when there 
are multiple reads/writes that the biggest difference should show up.

         ---Mike 

From sullrich at gmail.com  Tue Mar  3 10:56:30 2009
From: sullrich at gmail.com (Scott Ullrich)
Date: Tue Mar  3 10:56:38 2009
Subject: carpX: incorrect hash with IP aliases
In-Reply-To: <200903031852.11731.max@love2party.net>
References: <D4FB7A0E-9CA3-4B60-A2C7-3231ACFDBAA8@anduin.net>
	<200903031852.11731.max@love2party.net>
Message-ID: <d5992baf0903031023o600fc36g93a21032b749a49b@mail.gmail.com>

On Tue, Mar 3, 2009 at 12:52 PM, Max Laier <max@love2party.net> wrote:
[snip]
> Make sure that you are configuring the same aliases with the same netmasks on
> all members of the carp group - preferably before bringing the interface up
> for the first time (though it should properly recalculate the hashes as you
> add aliases). ?As you seem to be using pfsense you might want to check with
> them to make sure they have the fix in their build - though I recall it was a
> joined effort back then.

1.2.3 is based on 7.1 so this patch should be in the base system now.

Scott
From patfbsd at davenulle.org  Tue Mar  3 13:03:26 2009
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Tue Mar  3 13:03:33 2009
Subject: [7-STABLE] ndis interacts badly with powerd
In-Reply-To: <20090301130018.4bb7f349@baby-jane.lamaiziere.net>
References: <20090301130018.4bb7f349@baby-jane.lamaiziere.net>
Message-ID: <20090303220331.4efe625d@baby-jane.lamaiziere.net>

Le Sun, 1 Mar 2009 13:00:18 +0100,
Patrick Lamaizi?re <patfbsd@davenulle.org>:

> [7-STABLE/i386-SMP]
> 
> When I enable powerd, ndis takes all the CPU. Powerd alone and ndis
> alone works fine.
> 
> The kernel threads "Windows DCP0" and "ndis0 taskq" run at
> 100%. But the machine is still running (but is very very slow), I can
> kldunload my ndis module and all is ok.
> 
> I tried with a kernel (GENERIC) without SMP but there is the same
> problem.
> 
> Any idea? Thanks. 

The problem was simply that the frequency was lowered too many. I have
to limit the frequency with debug.cpufreq.lowest.

Sorry!
From ltning at anduin.net  Tue Mar  3 13:22:27 2009
From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=)
Date: Tue Mar  3 13:22:35 2009
Subject: carpX: incorrect hash with IP aliases
In-Reply-To: <d5992baf0903031023o600fc36g93a21032b749a49b@mail.gmail.com>
References: <D4FB7A0E-9CA3-4B60-A2C7-3231ACFDBAA8@anduin.net>
	<200903031852.11731.max@love2party.net>
	<d5992baf0903031023o600fc36g93a21032b749a49b@mail.gmail.com>
Message-ID: <A9BDC017-A26A-41CF-8716-AC67271356D2@anduin.net>

On Mar 3, 2009, at 19:23, Scott Ullrich wrote:

> On Tue, Mar 3, 2009 at 12:52 PM, Max Laier <max@love2party.net> wrote:
> [snip]
>> Make sure that you are configuring the same aliases with the same  
>> netmasks on
>> all members of the carp group - preferably before bringing the  
>> interface up
>> for the first time (though it should properly recalculate the  
>> hashes as you
>> add aliases).  As you seem to be using pfsense you might want to  
>> check with
>> them to make sure they have the fix in their build - though I  
>> recall it was a
>> joined effort back then.
>
> 1.2.3 is based on 7.1 so this patch should be in the base system now.

Excellent. And I just found that my second cluster member was not on  
1.2.3 ... I'm updating both to the latest snapshot and will be trying  
again. Thanks.

/Eirik


> Scott
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "
>

From onemda at gmail.com  Tue Mar  3 14:51:08 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Tue Mar  3 14:51:15 2009
Subject: [7-STABLE] ndis interacts badly with powerd
In-Reply-To: <20090303220331.4efe625d@baby-jane.lamaiziere.net>
References: <20090301130018.4bb7f349@baby-jane.lamaiziere.net>
	<20090303220331.4efe625d@baby-jane.lamaiziere.net>
Message-ID: <3a142e750903031451s3dc35df5gbc7f9672e1b1df54@mail.gmail.com>

On 3/3/09, Patrick Lamaiziere <patfbsd@davenulle.org> wrote:
> Le Sun, 1 Mar 2009 13:00:18 +0100,
> Patrick Lamaiziere <patfbsd@davenulle.org>:
>
>> [7-STABLE/i386-SMP]
>>
>> When I enable powerd, ndis takes all the CPU. Powerd alone and ndis
>> alone works fine.
>>
>> The kernel threads "Windows DCP0" and "ndis0 taskq" run at
>> 100%. But the machine is still running (but is very very slow), I can
>> kldunload my ndis module and all is ok.
>>
>> I tried with a kernel (GENERIC) without SMP but there is the same
>> problem.
>>
>> Any idea? Thanks.
>
> The problem was simply that the frequency was lowered too many. I have
> to limit the frequency with debug.cpufreq.lowest.

How much small it was?
powerd -b min with 125 freq works fine on CURRENT with ndis for me
(except that in such case watchdog errors are displayed on console if connection
is heavily used)

Note that ndis watchdog stuff have been rewritten on CURRENT.

-- 
Paul
From pyunyh at gmail.com  Tue Mar  3 17:03:28 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue Mar  3 17:03:35 2009
Subject: bce: unable to fix media
In-Reply-To: <d8a4930a0903030526m4807cc3hc0b5df2d41696ffc@mail.gmail.com>
References: <d8a4930a0903030202u5e965e3o9a630529de375f8d@mail.gmail.com>
	<20090303123156.GC84434@michelle.cdnetworks.co.kr>
	<d8a4930a0903030526m4807cc3hc0b5df2d41696ffc@mail.gmail.com>
Message-ID: <20090304011019.GA87142@michelle.cdnetworks.co.kr>

On Tue, Mar 03, 2009 at 02:26:11PM +0100, Cristiano Deana wrote:
> 2009/3/3 Pyun YongHyeon <pyunyh@gmail.com>:
> 
> >> # ifconfig bce0 media 1000baseSX
> >> ifconfig: SIOCSIFMEDIA (media): Device not configured
> 
> > I don't have experience on bce(4) hardwares so I'm not sure but how
> > about adding full-duplex?
> > e.g. ifconfig bce0 media 1000baseSX mediaopt full-duplex
> 
> Thanks, that works. But put the card in "no carrier".
> I will let in autoselect
> 

Yeah, that would be the reason why you always have to rely on
auto-negotiation.

> 
> >> or (according to bce(4)):
> >>
> >> # ifconfig bce0 media 1000baseTX
> >> ifconfig: SIOCSIFMEDIA (media): Device not configured
> >>
> >
> > I guess your PHY type is not for 1000baseT. That's not valid option
> > for your controller.
> 
> I think there is a typo o incomplete description in bce(4):
> 
>      1000baseTX   Set 1000baseTX operation over twisted pair.  Only
>                   full-duplex mode is supported.
> 
> No entry for "1000baseSX".
> 

bce(4) man page should reflect reality. I think the man page was
written when there was no support for TBI. Things has changed since
then(e.g BCM5709, 1000baseSX/2500baseSX support etc).
Xin Li, would you take care of this?(CCed)
From killing at multiplay.co.uk  Tue Mar  3 17:09:16 2009
From: killing at multiplay.co.uk (Steven Hartland)
Date: Tue Mar  3 17:09:23 2009
Subject: HEADS UP: Major CAM performance regression
References: <499551B9.7050805@samsco.org><200902172307.n1HN74ml025580@pyroxene.sentex.ca><49AD6130.8040703@barryp.org>
	<200903031840.n23IeXuk032580@lava.sentex.ca>
Message-ID: <A6604B9BCB15496980ACA8304444633C@multiplay.co.uk>

That's areca fix is a really interesting fix for us. I applied it to our
rrd graph machine which constantly becomes unresponsive currently under
high IO load for periods at a time.

I can confirm that we also now get Command Queuing Enabled and that
camcontrol tags da0 is reporting more that is expected.
(pass0:arcmsr0:0:0:0): device openings: 255

I cant say for sure if this has helped as our testing is quite
subjective for the most part i.e. does my ssh session stop responding.

I can however say the machine is still locking on a regular basis
apparently due to the IO load as its doing very little else.

Our test here is to run a very simple piece of C:
[code]
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main( char **argv, int argc )
{
        time_t last = time( NULL );
        while ( 1 )
        {
                time_t now = time( NULL );
                time_t diff = now - last;
                if ( diff >= 2 )
                {
                        fprintf( stderr, "stalled for %d seconds\n", diff );
                }
                fprintf( stderr, ctime( &now ) );
                last = now;
                sleep ( 1 );
        }
        
        exit( 0 );
}
[/code]

[log]
Wed Mar  4 00:31:36 2009
Wed Mar  4 00:31:37 2009
stalled for 4 seconds
Wed Mar  4 00:31:41 2009
Wed Mar  4 00:31:42 2009
Wed Mar  4 00:31:43 2009
Wed Mar  4 00:31:44 2009
Wed Mar  4 00:31:45 2009
stalled for 5 seconds
Wed Mar  4 00:31:50 2009
Wed Mar  4 00:31:51 2009
stalled for 4 seconds
Wed Mar  4 00:31:55 2009
Wed Mar  4 00:31:56 2009
stalled for 2 seconds
Wed Mar  4 00:31:58 2009
Wed Mar  4 00:31:59 2009
[/log]

As you can see above there a several multi second pauses where above exe
was stalled.

At the points of stall the process using serious IO are bufdaemon and
or syncer.

Anyway off thread, thanks for alot for fix to the areca driver Scott, I'm
sure it will even if it doesnt totally solve our performance issue here.

    Regards
    Steve
 
----- Original Message ----- 
From: "Mike Tancsa" <mike@sentex.net>


> At 11:56 AM 3/3/2009, Barry Pederson wrote:
> 
>>I can report a "metoo" on a 7.0-RELEASE-p3 machine with an Areca 
>>ARC-1212 card and SATA drives.  "camcontrol tags da0" reports:
>>
>>         (pass0:arcmsr0:0:0:0): device openings: 1
>>
>>The machine is just a dog sometimes.  Haven't tried the patch though.
> 
> 
> RELENG_7 has all the fixes in.  There seem to be quite a few cam 
> fixes plus the one areca fix.  With the patches, post reboot I now see
> 
> da1: Command Queueing Enabled
> 
> raw throughput seems to be the same (which is should). It when there 
> are multiple reads/writes that the biggest difference should show up.
> 
>         ---Mike 
> 
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From ltning at anduin.net  Wed Mar  4 04:50:12 2009
From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=)
Date: Wed Mar  4 04:50:20 2009
Subject: carpX: incorrect hash with IP aliases
In-Reply-To: <d5992baf0903031023o600fc36g93a21032b749a49b@mail.gmail.com>
References: <D4FB7A0E-9CA3-4B60-A2C7-3231ACFDBAA8@anduin.net>
	<200903031852.11731.max@love2party.net>
	<d5992baf0903031023o600fc36g93a21032b749a49b@mail.gmail.com>
Message-ID: <C5321AF6-B308-4FE4-A098-43D37DC0E2FF@anduin.net>

On Mar 3, 2009, at 19:23, Scott Ullrich wrote:

> On Tue, Mar 3, 2009 at 12:52 PM, Max Laier <max@love2party.net> wrote:
> [snip]
>> Make sure that you are configuring the same aliases with the same  
>> netmasks on
>> all members of the carp group - preferably before bringing the  
>> interface up
>> for the first time (though it should properly recalculate the  
>> hashes as you
>> add aliases).  As you seem to be using pfsense you might want to  
>> check with
>> them to make sure they have the fix in their build - though I  
>> recall it was a
>> joined effort back then.
>
> 1.2.3 is based on 7.1 so this patch should be in the base system now.

Just tested, and this seems to work.
Now I just need to figure out how to make sure both carp nodes have  
the IPs added/removed at ~exactly the same time..

/Eirik


> Scott
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "
>

From max at love2party.net  Wed Mar  4 05:20:27 2009
From: max at love2party.net (Max Laier)
Date: Wed Mar  4 05:20:34 2009
Subject: carpX: incorrect hash with IP aliases
In-Reply-To: <C5321AF6-B308-4FE4-A098-43D37DC0E2FF@anduin.net>
References: <D4FB7A0E-9CA3-4B60-A2C7-3231ACFDBAA8@anduin.net>
	<d5992baf0903031023o600fc36g93a21032b749a49b@mail.gmail.com>
	<C5321AF6-B308-4FE4-A098-43D37DC0E2FF@anduin.net>
Message-ID: <200903041420.23598.max@love2party.net>

On Wednesday 04 March 2009 13:50:09 Eirik ?verby wrote:
> On Mar 3, 2009, at 19:23, Scott Ullrich wrote:
> > On Tue, Mar 3, 2009 at 12:52 PM, Max Laier <max@love2party.net> wrote:
> > [snip]
> >
> >> Make sure that you are configuring the same aliases with the same
> >> netmasks on
> >> all members of the carp group - preferably before bringing the
> >> interface up
> >> for the first time (though it should properly recalculate the
> >> hashes as you
> >> add aliases).  As you seem to be using pfsense you might want to
> >> check with
> >> them to make sure they have the fix in their build - though I
> >> recall it was a
> >> joined effort back then.
> >
> > 1.2.3 is based on 7.1 so this patch should be in the base system now.
>
> Just tested, and this seems to work.
> Now I just need to figure out how to make sure both carp nodes have
> the IPs added/removed at ~exactly the same time..

Just ifconfig down the BACKUP, change the config on both and bring the BACKUP 
back up ;)

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
From wahjava.ml at gmail.com  Wed Mar  4 08:38:12 2009
From: wahjava.ml at gmail.com (Ashish SHUKLA)
Date: Wed Mar  4 08:38:20 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
Message-ID: <87wsb5clk9.fsf@chateau.d.lf>

Hi everone,

While trying to update my 'qt4-gui' port, gcc segfaults during
compilation. I'm running FreeBSD 7.1-STABLE (amd64 architecture) updated
on 3rd March, 2009.

#v+
c++ -c -pipe -msse -msse2 -msse3 -mmmx -march=nocona -march=nocona -g -fno-exceptions -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -pipe -msse -msse2 -msse3 -mmmx -march=nocona -march=nocona -g -Wall -W -fPIC -DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_RASTER_IMAGEENGINE -DQT_HAVE_MMX -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQ_INTERNAL_QAPP_SRC -DQT_NO_DEBUG -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include/QtCore -I../../include/QtCore -I../../include -I../../include/QtGui -I.rcc/release-shared -I/usr/local/include/freetype2 -I../3rdparty/harfbuzz/src -Idialogs -I.moc/release-shared -I/usr/local/include -I.uic/release-shared -I/usr/local/include -o .obj/release-shared/qpolygon.o painting/qpolygon.cpp
painting/qpolygon.cpp: In member function 'void QPolygon::setPoints(int, int, int, ...)':
painting/qpolygon.cpp:311: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1

Stop in /usr/ports/x11-toolkits/qt4-gui/work/qt-x11-opensource-src-4.4.3/src/gui.
*** Error code 1

Stop in /usr/ports/x11-toolkits/qt4-gui.
*** Error code 1

Stop in /usr/ports/x11-toolkits/qt4-gui.
#v-

The complete build log, qpolygon.cpp and qpolygon.i (pre-processed
output) is available in crash.tar.bz2[1], which I've uploaded to web. I
tried to debug using gdb but it seems the segfault is handled internally
by GCC.

So, should I file a PR for this or should I report this to GCC bugtracker.

References:
[1]  http://wahjava.googlepages.com/crash.tar.bz2

Thanks in advance.
-- 
Ashish SHUKLA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090304/ac497ea3/attachment.pgp
From hk at alogis.com  Wed Mar  4 11:18:01 2009
From: hk at alogis.com (Holger Kipp)
Date: Wed Mar  4 11:18:08 2009
Subject: Can we expect a ZFS MFC anytime soon?
Message-ID: <20090304191758.GA6221@intserv.int1.b.intern>

Hi,

subject says it all. Is it possible to get all the latest ZFS improvements
in 7-STABLE as well in a not too distant future? Is anything planned yet?

Best regards,
Holger
From patfbsd at davenulle.org  Wed Mar  4 11:26:38 2009
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Wed Mar  4 11:26:45 2009
Subject: [7-STABLE] ndis interacts badly with powerd
In-Reply-To: <3a142e750903031451s3dc35df5gbc7f9672e1b1df54@mail.gmail.com>
References: <20090301130018.4bb7f349@baby-jane.lamaiziere.net>
	<20090303220331.4efe625d@baby-jane.lamaiziere.net>
	<3a142e750903031451s3dc35df5gbc7f9672e1b1df54@mail.gmail.com>
Message-ID: <20090304202643.697ce0a4@baby-jane.lamaiziere.net>

Le Tue, 3 Mar 2009 23:51:06 +0100,
"Paul B. Mahol" <onemda@gmail.com>:

> > The problem was simply that the frequency was lowered too many. I
> > have to limit the frequency with debug.cpufreq.lowest.
> 
> How much small it was?
> powerd -b min with 125 freq works fine on CURRENT with ndis for me
> (except that in such case watchdog errors are displayed on console if
> connection is heavily used)
> Note that ndis watchdog stuff have been rewritten on CURRENT.

Here I've got some troubles under 400 MHz, at 400 MHz I'm able to unload
the ndis module, at 100 MHz the machine hangs (must use a hard shutdown)

I've set debug.cpufreq.lowest=600

Regards.
From darius at dons.net.au  Wed Mar  4 16:16:02 2009
From: darius at dons.net.au (Daniel O'Connor)
Date: Wed Mar  4 16:16:26 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
In-Reply-To: <87wsb5clk9.fsf@chateau.d.lf>
References: <87wsb5clk9.fsf@chateau.d.lf>
Message-ID: <200903051028.06645.darius@dons.net.au>

On Thursday 05 March 2009 02:44:14 Ashish SHUKLA wrote:
> Hi everone,
>
> While trying to update my 'qt4-gui' port, gcc segfaults during
> compilation. I'm running FreeBSD 7.1-STABLE (amd64 architecture) updated
> on 3rd March, 2009.

I would not rule out a hardware problem - seg faults while compiling heavy 
code (ie big C++ projects :) can be indicative of memory/CPU/PSU/motherboard 
problems.

I'd suggest running memtest86 and prime95 for a few hours if you can.

I'll start a build of qt4-gui on a 7.1 box I have but it will probably be a 
while before I get an answer :)

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090305/9ec5327b/attachment.pgp
From doconnor at gsoft.com.au  Wed Mar  4 16:26:28 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Mar  4 16:26:40 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
In-Reply-To: <200903051028.06645.darius@dons.net.au>
References: <87wsb5clk9.fsf@chateau.d.lf>
	<200903051028.06645.darius@dons.net.au>
Message-ID: <200903051056.24458.doconnor@gsoft.com.au>

On Thursday 05 March 2009 10:27:59 Daniel O'Connor wrote:
> On Thursday 05 March 2009 02:44:14 Ashish SHUKLA wrote:
> > Hi everone,
> >
> > While trying to update my 'qt4-gui' port, gcc segfaults during
> > compilation. I'm running FreeBSD 7.1-STABLE (amd64 architecture) updated
> > on 3rd March, 2009.
>
> I would not rule out a hardware problem - seg faults while compiling heavy
> code (ie big C++ projects :) can be indicative of
> memory/CPU/PSU/motherboard problems.
>
> I'd suggest running memtest86 and prime95 for a few hours if you can.
>
> I'll start a build of qt4-gui on a 7.1 box I have but it will probably be a
> while before I get an answer :)

Oops sent the previous message from the wrong address.

Anyway, I just finished compiling qt4 (This C2D is faster than I expected :)

It is running i386 FreeBSD however..

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090305/a83a6540/attachment.pgp
From wahjava.ml at gmail.com  Wed Mar  4 19:29:33 2009
From: wahjava.ml at gmail.com (Ashish SHUKLA)
Date: Wed Mar  4 19:29:39 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
In-Reply-To: <200903051028.06645.darius@dons.net.au> (Daniel O'Connor's
	message of "Thu, 5 Mar 2009 10:27:59 +1030")
References: <87wsb5clk9.fsf@chateau.d.lf>
	<200903051028.06645.darius@dons.net.au>
Message-ID: <87iqmohcl5.fsf@chateau.d.lf>

Daniel O'Connor writes:
> On Thursday 05 March 2009 02:44:14 Ashish SHUKLA wrote:
>> Hi everone,
>> 
>> While trying to update my 'qt4-gui' port, gcc segfaults during
>> compilation. I'm running FreeBSD 7.1-STABLE (amd64 architecture) updated
>> on 3rd March, 2009.

> I would not rule out a hardware problem - seg faults while compiling heavy 
> code (ie big C++ projects :) can be indicative of memory/CPU/PSU/motherboard 
> problems.

Okay, but I even tried compiling that file manually and that also
resulted in segfault.

> I'd suggest running memtest86 and prime95 for a few hours if you can.

I'll try running memtest86.

Thanks
-- 
Ashish SHUKLA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090305/9104b5d6/attachment.pgp
From atkin901 at yahoo.com  Thu Mar  5 08:48:33 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Thu Mar  5 08:48:41 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
References: <87wsb5clk9.fsf@chateau.d.lf>
	<200903051028.06645.darius@dons.net.au>
	<87iqmohcl5.fsf@chateau.d.lf>
Message-ID: <goovod$bba$1@ger.gmane.org>

Ashish SHUKLA wrote:

> Daniel O'Connor writes:
>> On Thursday 05 March 2009 02:44:14 Ashish SHUKLA wrote:
>>> Hi everone,
>>> 
>>> While trying to update my 'qt4-gui' port, gcc segfaults during
>>> compilation. I'm running FreeBSD 7.1-STABLE (amd64 architecture) updated
>>> on 3rd March, 2009.
> 
>> I would not rule out a hardware problem - seg faults while compiling
>> heavy code (ie big C++ projects :) can be indicative of
>> memory/CPU/PSU/motherboard problems.
> 
> Okay, but I even tried compiling that file manually and that also
> resulted in segfault.
> 
>> I'd suggest running memtest86 and prime95 for a few hours if you can.
> 
> I'll try running memtest86.
> 
> Thanks

I believe superpages were mfc'd to -stable as well.   I have one machine 
that faults in gcc with this turned on.   You can try adding 

vm.pmap.pg_ps_enabled="0"

to /boot/loader.conf, rebooting and see if that fixes the problem.  If so,  
you might provide the list with your hardware configuration.

For reference:
http://thread.gmane.org/gmane.os.freebsd.current/110586/focus=111337
http://article.gmane.org/gmane.os.freebsd.current/111307
-- 
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);


From nicolas at boiteameuh.org  Thu Mar  5 09:38:27 2009
From: nicolas at boiteameuh.org (Nicolas Haller)
Date: Thu Mar  5 09:38:34 2009
Subject: IPC Sys5 for amd64?
In-Reply-To: <gojbcc$4es$1@ger.gmane.org>
References: <20090302220729.GN14832@boiteameuh.org>
	<gojbcc$4es$1@ger.gmane.org>
Message-ID: <20090305173824.GA23630@boiteameuh.org>

On Tue, Mar 03, 2009 at 02:29:21PM +0100, Ivan Voras wrote:
> nicolas@boiteameuh.org wrote:
> > 
> > IPC Sys5 isn't "64bit-aware" or the problem is elsewhere?

> Yes, SYSVSHM is limited to 2 GB in 7.1. It has recently been extended in
> -CURRENT, it will probably be MFC-ed to 7-STABLE (7.2) soon.

Nice :-)

Thanks for the answer.

-- 
Nicolas Haller
From user at vk2pj.dyndns.org  Thu Mar  5 10:12:10 2009
From: user at vk2pj.dyndns.org (user@vk2pj.dyndns.org)
Date: Thu Mar  5 10:12:21 2009
Subject: IPC Sys5 for amd64?
In-Reply-To: <20090302220729.GN14832@boiteameuh.org>
References: <20090302220729.GN14832@boiteameuh.org>
Message-ID: <20090305181156.GK3540@server.vk2pj.dyndns.org>

On 2009-Mar-02 23:07:30 +0100, nicolas@boiteameuh.org wrote:
>It's seems I can't allocate a shared memory segment more than 2GB.
>I tune sysctl ipc.shm* values but without effects.
>
>IPC Sys5 isn't "64bit-aware" or the problem is elsewhere?

SysV shm doesn't make it clear whether segments can exceed 2GB even
on commercial 64-bit OSs (they can on Solaris but can't on Tru64).
The work-around Oracle uses on Tru64 is to allocate multiple 2GB
segments.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090305/d3d93303/attachment.pgp
From jhb at freebsd.org  Thu Mar  5 12:40:46 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Mar  5 12:40:52 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
In-Reply-To: <goovod$bba$1@ger.gmane.org>
References: <87wsb5clk9.fsf@chateau.d.lf> <87iqmohcl5.fsf@chateau.d.lf>
	<goovod$bba$1@ger.gmane.org>
Message-ID: <200903051449.59782.jhb@freebsd.org>

On Thursday 05 March 2009 11:48:11 am Mark Atkinson wrote:
> Ashish SHUKLA wrote:
> 
> > Daniel O'Connor writes:
> >> On Thursday 05 March 2009 02:44:14 Ashish SHUKLA wrote:
> >>> Hi everone,
> >>> 
> >>> While trying to update my 'qt4-gui' port, gcc segfaults during
> >>> compilation. I'm running FreeBSD 7.1-STABLE (amd64 architecture) updated
> >>> on 3rd March, 2009.
> > 
> >> I would not rule out a hardware problem - seg faults while compiling
> >> heavy code (ie big C++ projects :) can be indicative of
> >> memory/CPU/PSU/motherboard problems.
> > 
> > Okay, but I even tried compiling that file manually and that also
> > resulted in segfault.
> > 
> >> I'd suggest running memtest86 and prime95 for a few hours if you can.
> > 
> > I'll try running memtest86.
> > 
> > Thanks
> 
> I believe superpages were mfc'd to -stable as well.   I have one machine 
> that faults in gcc with this turned on.   You can try adding 
> 
> vm.pmap.pg_ps_enabled="0"
> 
> to /boot/loader.conf, rebooting and see if that fixes the problem.  If so,  
> you might provide the list with your hardware configuration.

Note that superpages is not on by default in 7 the way it is in 8.  BTW, can 
you get more details from your actual crash dump?  I'm not sure if there's a 
way you can either add some debug printfs or something else to determine what 
the faulting address that results in the SIGBUS you are seeing?

-- 
John Baldwin
From wahjava.ml at gmail.com  Thu Mar  5 15:35:55 2009
From: wahjava.ml at gmail.com (Ashish SHUKLA)
Date: Thu Mar  5 15:36:02 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
In-Reply-To: <200903051449.59782.jhb@freebsd.org> (John Baldwin's message of
	"Thu, 5 Mar 2009 14:49:59 -0500")
References: <87wsb5clk9.fsf@chateau.d.lf> <87iqmohcl5.fsf@chateau.d.lf>
	<goovod$bba$1@ger.gmane.org> <200903051449.59782.jhb@freebsd.org>
Message-ID: <87r61bbl1c.fsf@chateau.d.lf>

John Baldwin writes:
> On Thursday 05 March 2009 11:48:11 am Mark Atkinson wrote:
>> Ashish SHUKLA wrote:
>> 
>> > Daniel O'Connor writes:
>> >> On Thursday 05 March 2009 02:44:14 Ashish SHUKLA wrote:
>> >>> Hi everone,
>> >>> 
>> >>> While trying to update my 'qt4-gui' port, gcc segfaults during
>> >>> compilation. I'm running FreeBSD 7.1-STABLE (amd64 architecture) updated
>> >>> on 3rd March, 2009.
>> > 
>> >> I would not rule out a hardware problem - seg faults while compiling
>> >> heavy code (ie big C++ projects :) can be indicative of
>> >> memory/CPU/PSU/motherboard problems.
>> > 
>> > Okay, but I even tried compiling that file manually and that also
>> > resulted in segfault.
>> > 
>> >> I'd suggest running memtest86 and prime95 for a few hours if you can.
>> > 
>> > I'll try running memtest86.

I've tried memtest86+ with two passes and no memory related errors are
recieved.

>> > 
>> > Thanks
>> 
>> I believe superpages were mfc'd to -stable as well.   I have one machine 
>> that faults in gcc with this turned on.   You can try adding 
>> 
>> vm.pmap.pg_ps_enabled="0"
>> 
>> to /boot/loader.conf, rebooting and see if that fixes the problem.  If so,  
>> you might provide the list with your hardware configuration.

I booted with above line but nothing changed. Then I booted in to my old
kernel (dated January 29, 2009) with new userland, but there also I
received that segfault, so I guess this is something userspace related.

BtW, I also tried compiling deskutils/google-gadgets 0.10.5[1] port and
there too I've received similar segfault.

I'm attaching the output of 'dmesg' booted in verbose logging mode in both
the kernels. The boot.new.log contains output from booting in new
kernel, whereas boot.old.log contains output from booting in old
kernel.

References:
[1]  http://www.freebsd.org/cgi/query-pr.cgi?pr=132291

HTH
-- 
Ashish SHUKLA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090305/a6b98416/attachment.pgp
From wahjava.ml at gmail.com  Thu Mar  5 15:38:29 2009
From: wahjava.ml at gmail.com (Ashish SHUKLA)
Date: Thu Mar  5 15:38:35 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
In-Reply-To: <200903051449.59782.jhb@freebsd.org> (John Baldwin's message of
	"Thu, 5 Mar 2009 14:49:59 -0500")
References: <87wsb5clk9.fsf@chateau.d.lf> <87iqmohcl5.fsf@chateau.d.lf>
	<goovod$bba$1@ger.gmane.org> <200903051449.59782.jhb@freebsd.org>
Message-ID: <87mybzbkwu.fsf@chateau.d.lf>

Skipped content of type multipart/signed-------------- next part --------------
A non-text attachment was scrubbed...
Name: boot.old.log.gz
Type: application/octet-stream
Size: 9793 bytes
Desc: old boot log
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090305/8424d6d1/boot.old.log.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boot.new.log.gz
Type: application/octet-stream
Size: 10352 bytes
Desc: new boot log
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090305/8424d6d1/boot.new.log.obj
From spawk at acm.poly.edu  Thu Mar  5 17:22:21 2009
From: spawk at acm.poly.edu (Boris Kochergin)
Date: Thu Mar  5 17:22:30 2009
Subject: "Fatal trap 12: page fault while in kernel mode" on 7.1/amd64, but
 not 7.0
Message-ID: <49B07482.4080208@acm.poly.edu>

Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started 
getting a bunch of these at a pretty high frequency (a few hours to a 
day apart):

http://acm.poly.edu/~spawk/IMG00033.jpg

The "current process" is always httpd. They're particularly annoying 
because the machine doesn't actually ever reboot, requiring manual 
intervention. Reverting the kernel back to 7.0 makes the panic go away, 
and the machine had been happily running 7.0 for about a year 
beforehand. I realize that the photo hardly contains any useful 
debugging information, but I was hoping it might look familiar to 
someone. If not, I guess I'll come back with a backtrace.

-Boris
From wahjava.ml at gmail.com  Fri Mar  6 01:33:44 2009
From: wahjava.ml at gmail.com (Ashish SHUKLA)
Date: Fri Mar  6 01:33:51 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
In-Reply-To: <20090306001224.GA8231@ace.cs.uoi.gr> (Nikos Ntarmos's message of
	"Fri, 6 Mar 2009 02:12:24 +0200")
References: <87wsb5clk9.fsf@chateau.d.lf> <87iqmohcl5.fsf@chateau.d.lf>
	<goovod$bba$1@ger.gmane.org> <200903051449.59782.jhb@freebsd.org>
	<87r61bbl1c.fsf@chateau.d.lf> <20090306001224.GA8231@ace.cs.uoi.gr>
Message-ID: <87ocwfxafz.fsf@chateau.d.lf>

Nikos Ntarmos writes:

[...]


> Hi there.

> Could you be running out of memory during that compilation? I'd suggest
> adding some swap space[1] and trying again, or play around with lower gcc
> optimization levels (-O0, -O).

I'm already using a 2 GiB swap device. I added -dH option in existing c++
command-line[1] to force it to dump a core file, and then I loaded it in
gdb and following is the backtrace.

#v+
(gdb) bt
#0  0x000000000088893c in kill () at kill.S:2
#1  0x00000000008879c4 in abort ()
    at /usr/src/lib/libc/stdlib/abort.c:65
#2  0x0000000000811fb3 in real_abort ()
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/diagnostic.c:652
#3  0x000000000081239b in diagnostic_action_after_output (
    context=0x575, diagnostic=0x6)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/diagnostic.c:270
#4  0x00000000008120f5 in diagnostic_report_diagnostic (
    context=0xbb16e0, diagnostic=0x7fffffffcad0)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/diagnostic.c:409
#5  0x0000000000812312 in internal_error (gmsgid=Variable "gmsgid" is not available.
)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/diagnostic.c:588
#6  0x000000000055c07d in crash_signal (signo=Variable "signo" is not available.
)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:607
#7  <signal handler called>
#8  gimplify_va_arg_expr (expr_p=0x80521de00, pre_p=0x7fffffffd2d0, 
    post_p=0x7fffffffd2c8)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/builtins.c:4377
#9  0x00000000007e9881 in gimplify_expr (expr_p=0x80521de00, 
    pre_p=0x7fffffffd2d0, post_p=0x7fffffffd2c8, 
    gimple_test_f=0x7f1cb3 <is_gimple_reg_rhs>, fallback=fb_rvalue)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:5545
#10 0x00000000007e8b83 in gimplify_modify_expr (
    expr_p=0x7fffffffd400, pre_p=0x7fffffffd2d0, 
    post_p=0x7fffffffd2c8, want_value=0 '\0')
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:3565
#11 0x00000000007e9c25 in gimplify_expr (expr_p=0x7fffffffd400, 
    pre_p=0x7fffffffd2d0, post_p=0x7fffffffd2c8, 
    gimple_test_f=0x7f1bf5 <is_gimple_stmt>, fallback=fb_none)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:5518
#12 0x00000000007eb1b4 in gimplify_to_stmt_list (
    stmt_p=0x7fffffffd400)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:4309
#13 0x00000000007e958f in gimplify_expr (expr_p=0x805216e90, 
    pre_p=0x7fffffffd410, post_p=0x7fffffffd408, 
    gimple_test_f=0x7f1bf5 <is_gimple_stmt>, fallback=fb_none)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:4124
#14 0x00000000007e9919 in gimplify_expr (expr_p=0x7fffffffd588, 
    pre_p=0x7fffffffd530, post_p=0x7fffffffd528, 
    gimple_test_f=0x7f1bf5 <is_gimple_stmt>, fallback=fb_none)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:3746
#15 0x0000000000488dac in gimplify_cp_loop (cond=Variable "cond" is not available.
)
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/cp-gimplify.c:246
#16 0x0000000000489151 in cp_gimplify_expr (expr_p=0x805216e70, 
    pre_p=0x7fffffffd720, post_p=0x7fffffffd718)
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/cp-gimplify.c:283
#17 0x00000000007e8fbe in gimplify_expr (expr_p=0x805216e70, 
    pre_p=0x7fffffffd720, post_p=0x7fffffffd718, 
    gimple_test_f=0x7f1bf5 <is_gimple_stmt>, fallback=fb_none)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:5449
#18 0x00000000007e9919 in gimplify_expr (expr_p=0x80521dfe0, 
    pre_p=0x7fffffffd840, post_p=0x7fffffffd838, 
    gimple_test_f=0x7f1bf5 <is_gimple_stmt>, fallback=fb_none)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:3746
#19 0x00000000007eb1b4 in gimplify_to_stmt_list (stmt_p=0x80521dfe0)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:4309
#20 0x00000000007ea13d in gimplify_expr (expr_p=0x803ee97b0, 
    pre_p=0x7fffffffd980, post_p=0x7fffffffd978, 
    gimple_test_f=0x7f1bf5 <is_gimple_stmt>, fallback=fb_none)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:1091
#21 0x00000000007eabc8 in gimplify_body (body_p=0x803ee97b0, 
    fndecl=0x803ee9700, do_parms=1 '\001')
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:6317
#22 0x00000000007eadaf in gimplify_function_tree (fndecl=0x803ee9700)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/gimplify.c:6393
#23 0x000000000048e208 in c_genericize (fndecl=0x803ee9700)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-gimplify.c:106
#24 0x0000000000488c18 in cp_genericize (fndecl=0x803ee9700)
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/cp-gimplify.c:755
#25 0x00000000004287bb in finish_function (flags=0)
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/decl.c:11336
#26 0x000000000045824f in cp_parser_function_definition_after_declarator (parser=0x800c07c80, inline_p=0 '\0')
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parser.c:15650
#27 0x0000000000458684 in cp_parser_init_declarator (
    parser=0x800c07c80, decl_specifiers=0x7fffffffdbb0, checks=0x0, 
    function_definition_allowed_p=1 '\001', member_p=0 '\0', 
    declares_class_or_enum=Variable "declares_class_or_enum" is not available.
)
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parser.c:15582
#28 0x000000000044ea23 in cp_parser_simple_declaration (
    parser=0x800c07c80, function_definition_allowed_p=Variable "function_definition_allowed_p" is not available.
)
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parser.c:7431
#29 0x0000000000454f1a in cp_parser_block_declaration (
    parser=0x800c07c80, statement_p=0 '\0')
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parser.c:7331
#30 0x0000000000458ee4 in cp_parser_declaration (parser=0x800c07c80)
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parser.c:7247
#31 0x0000000000459335 in cp_parser_declaration_seq_opt (
    parser=0x800c07c80)
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parser.c:7142
#32 0x0000000000459930 in c_parse_file ()
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/parser.c:2845
#33 0x000000000040074b in c_common_parse_file (set_yydebug=Variable "set_yydebug" is not available.
)
    at /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/c-opts.c:1184
#34 0x000000000055d2e8 in toplev_main (argc=Variable "argc" is not available.
)
    at /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:1035
#35 0x00000000004001ae in _start (ap=Variable "ap" is not available.
)
    at /usr/src/lib/csu/amd64/crt1.c:92
#36 0x0000000000000000 in ?? ()
#37 0x0000000000000042 in ?? ()
#38 0x00007fffffffe1a8 in ?? ()

[...]

#1114 0x01a1c0c748006a10 in ?? ()
#1115 0x66fdebf4050f0000 in ?? ()
#1116 0x9066669066669066 in ?? ()
#1117 0x00007fffffffde28 in ?? ()
#1118 0x0000000000000042 in ?? ()
#1119 0x00007fffffffe040 in ?? ()
#1120 0x000000000000000e in ?? ()
Cannot access memory at address 0x800000000000
#v-

References:
[1]  http://news.gmane.org/find-root.php?message_id=%3c84dead720902121838p3a72f993xc1c52104c666ed0a%40mail.gmail.com%3e

HTH
-- 
Ashish SHUKLA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090306/49f3014b/attachment.pgp
From kostikbel at gmail.com  Fri Mar  6 02:20:40 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Fri Mar  6 02:20:47 2009
Subject: "Fatal trap 12: page fault while in kernel mode" on 7.1/amd64,
	but not 7.0
In-Reply-To: <49B07482.4080208@acm.poly.edu>
References: <49B07482.4080208@acm.poly.edu>
Message-ID: <20090306102037.GA41617@deviant.kiev.zoral.com.ua>

On Thu, Mar 05, 2009 at 07:55:30PM -0500, Boris Kochergin wrote:
> Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started 
> getting a bunch of these at a pretty high frequency (a few hours to a 
> day apart):
> 
> http://acm.poly.edu/~spawk/IMG00033.jpg
> 
> The "current process" is always httpd. They're particularly annoying 
> because the machine doesn't actually ever reboot, requiring manual 
> intervention. Reverting the kernel back to 7.0 makes the panic go away, 
> and the machine had been happily running 7.0 for about a year 
> beforehand. I realize that the photo hardly contains any useful 
> debugging information, but I was hoping it might look familiar to 
> someone. If not, I guess I'll come back with a backtrace.

You need to provide the backtrace from kgdb.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090306/e8b4faee/attachment.pgp
From gavin at FreeBSD.org  Fri Mar  6 02:21:01 2009
From: gavin at FreeBSD.org (Gavin Atkinson)
Date: Fri Mar  6 02:21:13 2009
Subject: "Fatal trap 12: page fault while in kernel mode" on 7.1/amd64, 
	but not 7.0
In-Reply-To: <49B07482.4080208@acm.poly.edu>
References: <49B07482.4080208@acm.poly.edu>
Message-ID: <1236334857.88789.4.camel@buffy.york.ac.uk>

On Thu, 2009-03-05 at 19:55 -0500, Boris Kochergin wrote:
> Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started 
> getting a bunch of these at a pretty high frequency (a few hours to a 
> day apart):
> 
> http://acm.poly.edu/~spawk/IMG00033.jpg
> 
> The "current process" is always httpd. They're particularly annoying 
> because the machine doesn't actually ever reboot, requiring manual 
> intervention. Reverting the kernel back to 7.0 makes the panic go away, 
> and the machine had been happily running 7.0 for about a year 
> beforehand. I realize that the photo hardly contains any useful 
> debugging information, but I was hoping it might look familiar to 
> someone. If not, I guess I'll come back with a backtrace.

A backtrace will almost certainly be necessary to figure out what this
issue is, although there is a possibility that the output of
"addr2line -e /boot/kernel/kernel.symbols 0x8:0xffffffff802d7010"
might help, assuming you've not recompiled your kernel yet.  (That
number should be the same as the "instruction pointer" shown by the
panic, but as the photo is quite blurred there's a chance I've got it
wrong, if you have a better picture of it or wrote it down then use
that)

Gavin
From atkin901 at yahoo.com  Fri Mar  6 06:54:18 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Fri Mar  6 06:54:25 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
References: <87wsb5clk9.fsf@chateau.d.lf> <87iqmohcl5.fsf@chateau.d.lf>
	<goovod$bba$1@ger.gmane.org> <200903051449.59782.jhb@freebsd.org>
Message-ID: <gordei$hs7$1@ger.gmane.org>

John Baldwin wrote:
>> I believe superpages were mfc'd to -stable as well.   I have one machine
>> that faults in gcc with this turned on.   You can try adding
>> 
>> vm.pmap.pg_ps_enabled="0"
>> 
>> to /boot/loader.conf, rebooting and see if that fixes the problem.  If
>> so, you might provide the list with your hardware configuration.
> 
> Note that superpages is not on by default in 7 the way it is in 8.  BTW,
> can
> you get more details from your actual crash dump?  I'm not sure if there's
> a way you can either add some debug printfs or something else to determine
> what the faulting address that results in the SIGBUS you are seeing?

Ahh, my bad, I didn't realize it defaulted to off.   I'm not having any luck 
at diagnosing it further, the stack is so far gone at that point.   Since 
no-one else is really seeing my issue at this point, I'm going to wait until 
I have some different, slower memory to try.    For now, disabling 
superpages works well.

If Ashish is still having issues, I've seen this sort of thing with runtime 
library problems.   Bad libmap entries and disk corruption can cause this.   
If you can complete a buildworld, a fresh buildworld and installworld with 
make delete-old might solve your compilation problems.    If qt depends on 
the gcc in ports, you may have to rebuild that one as well afterwards.

-- 
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);


From wahjava.ml at gmail.com  Fri Mar  6 07:48:31 2009
From: wahjava.ml at gmail.com (Ashish SHUKLA)
Date: Fri Mar  6 07:48:37 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
In-Reply-To: <gordei$hs7$1@ger.gmane.org> (Mark Atkinson's message of "Fri, 06
	Mar 2009 06:54:08 -0800")
References: <87wsb5clk9.fsf@chateau.d.lf> <87iqmohcl5.fsf@chateau.d.lf>
	<goovod$bba$1@ger.gmane.org> <200903051449.59782.jhb@freebsd.org>
	<gordei$hs7$1@ger.gmane.org>
Message-ID: <87vdqmirep.fsf@chateau.d.lf>

Mark Atkinson writes:

[...]

> If Ashish is still having issues, I've seen this sort of thing with runtime 
> library problems.   Bad libmap entries and disk corruption can cause this.   
> If you can complete a buildworld, a fresh buildworld and installworld with 
> make delete-old might solve your compilation problems.    If qt depends on 
> the gcc in ports, you may have to rebuild that one as well afterwards.

Okay, I'll try updating my box again.

-- 
Ashish SHUKLA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090306/e29584da/attachment.pgp
From oliver.pntr at gmail.com  Fri Mar  6 10:11:44 2009
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Fri Mar  6 10:11:51 2009
Subject: Sata disc management
Message-ID: <6101e8c40903060950x7c34da32gb9e460d832e0a5c6@mail.gmail.com>

Hi all!

How to can I stop the idle sata disc under fbsd (for power save) ? I
searched many hours on google, but I don't find any information for
it, only for scsi subsystem. I think a program like camcontrol, but
for sata disk.

Thanks,
Oliver
From henry.hu.sh at gmail.com  Fri Mar  6 10:57:59 2009
From: henry.hu.sh at gmail.com (Henry Hu)
Date: Fri Mar  6 10:58:07 2009
Subject: Problems about usbhidaction
Message-ID: <53a1e0710903061057o1bb897e3y7793af39b4be6914@mail.gmail.com>

Hi,

Today I got a new USB keyboard,
ukbd0: <Microsoft Natural\M-. Ergonomic Keyboard 4000, class 0/0, rev
2.00/1.73, addr 2> on uhub3
kbd2 at ukbd0
uhid0: <Microsoft Natural\M-. Ergonomic Keyboard 4000, class 0/0, rev
2.00/1.73, addr 2> on uhub3

Normal keys are sent through ukbd0, and special keys (volume up, etc)
are sent through uhid0.
I tried to use usbhidaction to make the special keys functional, and I
found that there are some problems about usbhidaction:
1. The length of data it tried to read is wrong.
From henry.hu.sh at gmail.com  Fri Mar  6 11:13:02 2009
From: henry.hu.sh at gmail.com (Henry Hu)
Date: Fri Mar  6 11:13:09 2009
Subject: Problems about usbhidaction
In-Reply-To: <53a1e0710903061057o1bb897e3y7793af39b4be6914@mail.gmail.com>
References: <53a1e0710903061057o1bb897e3y7793af39b4be6914@mail.gmail.com>
Message-ID: <53a1e0710903061113x6f8130bdvab131a69094a694b@mail.gmail.com>

Hi,

Today I got a new USB keyboard,
ukbd0: <Microsoft Natural\M-. Ergonomic Keyboard 4000, class 0/0, rev
2.00/1.73, addr 2> on uhub3
kbd2 at ukbd0
uhid0: <Microsoft Natural\M-. Ergonomic Keyboard 4000, class 0/0, rev
2.00/1.73, addr 2> on uhub3

Normal keys are sent through ukbd0, and special keys (volume up, etc)
are sent through uhid0.
I tried to use usbhidaction to make the special keys functional, and I
found that there are some problems about usbhidaction:
1. The length of data it tried to read is wrong.
According to the UHID Device Class Definition, if Report ID tags are
used in the Report descriptor, there would be a 1-byte report ID
prefix before the report data. But if no Report ID tags are used, then
the report ID prefix is omitted.
But usbhidaction does not admit this (I modified libusbhid to allow
client program to know if Report ID tags have appeared), and always
reads one byte less than the data received, and the parse of the data
received leads to a wrong result. However I found that usbhidctl
somewhere admit this (although the way it handles it seems like a
hack).
I modified usbhidaction to read one more byte if it found that Report
ID tags had appeared. This also needs some modification to libusbhid.
2. There's no way to specify report ID.
There should be one way to specify which Report ID one item is
referring to, and usbhidaction should check the report ID prefix to
determine if the item is corresponding to it.
3. ioctl USB_GET_REPORT_ID returns 0
According to the Definition, report ID 0 is reserved and should not be used.
In fact, this keyboard sent its special key events with report ID = 1.
So I have to hack usbhidaction to set reportid to 1. I think this is
not right and should be fixed.
In the Definition, there might be multiple report IDs, so why there's
such an ioctl?
4. usbhidctl does not set reportid.
reportid in usbhidctl is always zero. There's even no ioctl to set it.
So to use it to listen to events I had manually changed reportid to 1.
I think there should be an option to set which report ID to listen to.

PS. Sorry for the incomplete mail. I've not been used to the new
keyboard yet....

Cheers,
Henry
From ertr1013 at student.uu.se  Fri Mar  6 12:47:01 2009
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Fri Mar  6 12:47:09 2009
Subject: Sata disc management
In-Reply-To: <6101e8c40903060950x7c34da32gb9e460d832e0a5c6@mail.gmail.com>
References: <6101e8c40903060950x7c34da32gb9e460d832e0a5c6@mail.gmail.com>
Message-ID: <20090306204638.GA59083@owl.midgard.homeip.net>

On Fri, Mar 06, 2009 at 06:50:10PM +0100, Oliver Pinter wrote:
> Hi all!
> 
> How to can I stop the idle sata disc under fbsd (for power save) ? I
> searched many hours on google, but I don't find any information for
> it, only for scsi subsystem. I think a program like camcontrol, but
> for sata disk.
> 

The sysutils/ataidle port ought to do the trick.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From spawk at acm.poly.edu  Fri Mar  6 14:01:24 2009
From: spawk at acm.poly.edu (Boris Kochergin)
Date: Fri Mar  6 14:01:31 2009
Subject: "Fatal trap 12: page fault while in kernel mode" on 7.1/amd64, 
 but not 7.0
In-Reply-To: <1236334857.88789.4.camel@buffy.york.ac.uk>
References: <49B07482.4080208@acm.poly.edu>
	<1236334857.88789.4.camel@buffy.york.ac.uk>
Message-ID: <49B19D28.1060803@acm.poly.edu>

Gavin Atkinson wrote:
> On Thu, 2009-03-05 at 19:55 -0500, Boris Kochergin wrote:
>   
>> Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started 
>> getting a bunch of these at a pretty high frequency (a few hours to a 
>> day apart):
>>
>> http://acm.poly.edu/~spawk/IMG00033.jpg
>>
>> The "current process" is always httpd. They're particularly annoying 
>> because the machine doesn't actually ever reboot, requiring manual 
>> intervention. Reverting the kernel back to 7.0 makes the panic go away, 
>> and the machine had been happily running 7.0 for about a year 
>> beforehand. I realize that the photo hardly contains any useful 
>> debugging information, but I was hoping it might look familiar to 
>> someone. If not, I guess I'll come back with a backtrace.
>>     
>
> A backtrace will almost certainly be necessary to figure out what this
> issue is, although there is a possibility that the output of
> "addr2line -e /boot/kernel/kernel.symbols 0x8:0xffffffff802d7010"
> might help, assuming you've not recompiled your kernel yet.  (That
> number should be the same as the "instruction pointer" shown by the
> panic, but as the photo is quite blurred there's a chance I've got it
> wrong, if you have a better picture of it or wrote it down then use
> that)
>
> Gavin
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>   
Here it is, with some additional information afterward:

Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x30
fault code              = supervisor read data, page not present
instruction pointer     = 0x8:0xffffffff80293faf
stack pointer           = 0x10:0xffffffff9cbaea70
frame pointer           = 0x10:0xffffff000fc14000
code segment            = base 0x0, limit 0xfffff, type 0x1b
                       = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = resume, IOPL = 0
current process         = 881 (httpd)
trap number             = 12
panic: page fault
cpuid = 1
Uptime: 1m51s
Physical memory: 8185 MB
Dumping 328 MB: 313 297 281 265 249 233 217 201 185 169 153 137 121 105 
89 73 57 41 25 9

#0  doadump () at pcpu.h:195
195     pcpu.h: No such file or directory.
       in pcpu.h
(kgdb) where
#0  doadump () at pcpu.h:195
#1  0xffffff000fc14000 in ?? ()
#2  0xffffffff8025eba9 in boot (howto=260) at 
/usr/src-7.1/sys/kern/kern_shutdown.c:418
#3  0xffffffff8025efb2 in panic (fmt=0x104 <Address 0x104 out of 
bounds>) at /usr/src-7.1/sys/kern/kern_shutdown.c:574
#4  0xffffffff803df5c3 in trap_fatal (frame=0xffffff000fc14000, 
eva=Variable "eva" is not available.
) at /usr/src-7.1/sys/amd64/amd64/trap.c:764
#5  0xffffffff803e018f in trap (frame=0xffffffff9cbae9c0) at 
/usr/src-7.1/sys/amd64/amd64/trap.c:290
#6  0xffffffff803c5c4e in calltrap () at 
/usr/src-7.1/sys/amd64/amd64/exception.S:209
#7  0xffffffff80293faf in turnstile_broadcast (ts=0x0, queue=0) at 
/usr/src-7.1/sys/kern/subr_turnstile.c:836
#8  0xffffffff8025256a in _mtx_unlock_sleep (m=0xffffffff80593538, 
opts=Variable "opts" is not available.
) at /usr/src-7.1/sys/kern/kern_mutex.c:619
#9  0xffffffff80275ed3 in __umtx_op_cv_wait (td=0x1ee, uap=Variable 
"uap" is not available.
) at /usr/src-7.1/sys/kern/kern_umtx.c:312
#10 0xffffffff803dfb78 in syscall (frame=0xffffffff9cbaec80) at 
/usr/src-7.1/sys/amd64/amd64/trap.c:907
#11 0xffffffff803c5e5b in Xfast_syscall () at 
/usr/src-7.1/sys/amd64/amd64/exception.S:330
#12 0x0000000800f5354c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)

The dump was difficult to acquire--the system would often lock up after 
dumping only a portion of the memory it wanted to save. I can also now 
trigger the panic pretty reliably using this bit of script:

#!/usr/local/bin/bash

for i in {1..900}
do
wget --quiet -O /dev/null http://acm.poly.edu/wiki/Hosting &
done

...where the URL is a MediaWiki installation on the afflicted machine.

-Boris
From oliver.pntr at gmail.com  Fri Mar  6 17:35:20 2009
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Fri Mar  6 17:35:27 2009
Subject: Sata disc management
In-Reply-To: <49B19C96.3050603@smo.de>
References: <6101e8c40903060950x7c34da32gb9e460d832e0a5c6@mail.gmail.com>
	<49B19C96.3050603@smo.de>
Message-ID: <6101e8c40903061735p55834b27u7ed51b2c25fb710e@mail.gmail.com>

thanks, the sysutils/ataidle is the best answer

On 3/6/09, Philipp Ost <pj@smo.de> wrote:
> Oliver Pinter wrote:
>> How to can I stop the idle sata disc under fbsd (for power save) ? I
>> searched many hours on google, but I don't find any information for
>> it, only for scsi subsystem. I think a program like camcontrol, but
>> for sata disk.
>
> Did you (already) check your BIOS if there's such an option?
>
> HTH,
> Philipp
>
From spawk at acm.poly.edu  Fri Mar  6 18:22:36 2009
From: spawk at acm.poly.edu (Boris Kochergin)
Date: Fri Mar  6 18:22:43 2009
Subject: Sata disc management
In-Reply-To: <6101e8c40903061735p55834b27u7ed51b2c25fb710e@mail.gmail.com>
References: <6101e8c40903060950x7c34da32gb9e460d832e0a5c6@mail.gmail.com>	<49B19C96.3050603@smo.de>
	<6101e8c40903061735p55834b27u7ed51b2c25fb710e@mail.gmail.com>
Message-ID: <49B1DA5F.2030408@acm.poly.edu>

7.1 adds the "spindown" command to atacontrol(8), which may also be 
worth a look.

-Boris

Oliver Pinter wrote:
> thanks, the sysutils/ataidle is the best answer
>
> On 3/6/09, Philipp Ost <pj@smo.de> wrote:
>   
>> Oliver Pinter wrote:
>>     
>>> How to can I stop the idle sata disc under fbsd (for power save) ? I
>>> searched many hours on google, but I don't find any information for
>>> it, only for scsi subsystem. I think a program like camcontrol, but
>>> for sata disk.
>>>       
>> Did you (already) check your BIOS if there's such an option?
>>
>> HTH,
>> Philipp
>>
>>     
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>   
From pj at smo.de  Fri Mar  6 19:51:04 2009
From: pj at smo.de (Philipp Ost)
Date: Fri Mar  6 19:51:11 2009
Subject: Sata disc management
In-Reply-To: <6101e8c40903060950x7c34da32gb9e460d832e0a5c6@mail.gmail.com>
References: <6101e8c40903060950x7c34da32gb9e460d832e0a5c6@mail.gmail.com>
Message-ID: <49B19C96.3050603@smo.de>

Oliver Pinter wrote:
> How to can I stop the idle sata disc under fbsd (for power save) ? I
> searched many hours on google, but I don't find any information for
> it, only for scsi subsystem. I think a program like camcontrol, but
> for sata disk.

Did you (already) check your BIOS if there's such an option?

HTH,
Philipp
From zkolic at sbb.co.yu  Fri Mar  6 23:24:29 2009
From: zkolic at sbb.co.yu (Zoran Kolic)
Date: Fri Mar  6 23:24:37 2009
Subject: cd ripping to flac
Message-ID: <20090307071228.GA1134@faust.net>

Howdy!
I'd like to rip my cd-s to flac files using some
command line app, like cdda2wav or cdparanoia.
Using pipe to flac utility would be nice and the
way I'd take. What program acts in that matter?
Since cdda2wav is in the base, I suppose people
use it regurarly. Something like:
 program {options} - | flac - flac_file.flac
One more thing bothers me. I cannot see songs on
the cd in the way of "/dev/acd0t1". I tried to
stress it using cdcontrol, but no way. The kernel
is customized, no sound in it, and a lot of others
has gone. The box is speakers-free, so cannot
check if it plays in deed.
Best regards

                         Zoran

From wahjava.ml at gmail.com  Sat Mar  7 00:27:50 2009
From: wahjava.ml at gmail.com (Ashish SHUKLA)
Date: Sat Mar  7 00:27:57 2009
Subject: GCC segfaulting while trying to compile latest Qt4 code
In-Reply-To: <87vdqmirep.fsf@chateau.d.lf> (Ashish SHUKLA's message of "Fri,
	06 Mar 2009 21:18:14 +0530")
References: <87wsb5clk9.fsf@chateau.d.lf> <87iqmohcl5.fsf@chateau.d.lf>
	<goovod$bba$1@ger.gmane.org> <200903051449.59782.jhb@freebsd.org>
	<gordei$hs7$1@ger.gmane.org> <87vdqmirep.fsf@chateau.d.lf>
Message-ID: <874oy57n64.fsf@chateau.d.lf>

Ashish SHUKLA writes:
> Mark Atkinson writes:

> [...]

>> If Ashish is still having issues, I've seen this sort of thing with runtime 
>> library problems.   Bad libmap entries and disk corruption can cause this.   
>> If you can complete a buildworld, a fresh buildworld and installworld with 
>> make delete-old might solve your compilation problems.    If qt depends on 
>> the gcc in ports, you may have to rebuild that one as well afterwards.

> Okay, I'll try updating my box again.

After updating (kernel & world) no more such errors.

-- 
Ashish SHUKLA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090307/3051bf44/attachment.pgp
From rsmith at xs4all.nl  Sat Mar  7 01:01:04 2009
From: rsmith at xs4all.nl (Roland Smith)
Date: Sat Mar  7 01:01:12 2009
Subject: cd ripping to flac
In-Reply-To: <20090307071228.GA1134@faust.net>
References: <20090307071228.GA1134@faust.net>
Message-ID: <20090307090054.GA23931@slackbox.xs4all.nl>

On Sat, Mar 07, 2009 at 08:12:28AM +0100, Zoran Kolic wrote:
> Howdy!
> I'd like to rip my cd-s to flac files using some
> command line app, like cdda2wav or cdparanoia.
> Using pipe to flac utility would be nice and the
> way I'd take. What program acts in that matter?

It won't work if you want the songs to have the right metadata; You'd
have to supply that to the pipe in some way...

For ripping I use cdparanoia: 'cdparanoia -B 1' rips all tracks.

The following perl scripts reads a text file containing the metadata
(artist, album name, track data) and calls flac:

----- make-flac -----
#!/usr/bin/perl
#
# Compiles a list of wav files into flac files.
#
# Author: R.F. Smith <rsmith@xs4all.nl>
# Time-stamp: <2008-07-30 23:53:00 rsmith>
#
# I, the copyright holder of this work, hereby release it into
# the public domain. This applies worldwide.
#
# In case this is not legally possible, I grant any entity the right to use
# this work for any purpose, without any conditions, unless such conditions
# are required by law.

# Check for programs that this script needs.
chomp($flac = `which flac 2>/dev/null`);
-x $flac || die "Cannot find flac: $!\n";
#chomp($norm = `which normalize 2>/dev/null`);
#-x $norm || die "Cannot find normalize: $!\n";

# Get the name of the file containing the titles.
if ($ARGV[0] ne "") {
    $fname = $ARGV[0];
} else {
    $fname = "titles";
}

# open the list of song titles
open (TITELS, $fname) || die "cannot open $fname: $!\n";

# The titles file format is as follows:
# ------------------------------------
# album title
# artist
# 01 title of 1st song
# ..
# 14 title of 14th song
# ..

# get the album title and performer name
chomp($album = <TITELS>);
$album ne "" || die "cannot read album name";
chomp($artist = <TITELS>);
$artist ne "" || die "cannot read artist name";

# Normalize the wav files.
#printf("Normalizing .wav files...\n");
#`$norm -b track*.cdda.wav`;

# go over all the songs
while(<TITELS>) {
    chomp;
    ($num, $title) = split (' ', $_, 2);
    printf ("Encoding \"%s\" as %s\n", $title, "track".$num.".flac");
    # invoke the flac encoder.
    do {
        $rc = system ($flac, "-8", "-TARTIST=".$artist, "-TALBUM=".$album, 
                      "-TTITLE=".$title,  "-TTRACKNUMBER=".$num, 
                      "-o", "track".$num.".flac", "track".$num.".cdda.wav");
        if ($rc != 0) {print "\nError,", $rc, "starting again";}
    } until $rc == 0;
}
----- make-flac -----


Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090307/0794422a/attachment.pgp
From zkolic at sbb.co.yu  Sat Mar  7 06:39:45 2009
From: zkolic at sbb.co.yu (Zoran Kolic)
Date: Sat Mar  7 06:39:58 2009
Subject: cd ripping to flac
In-Reply-To: <20090307090054.GA23931@slackbox.xs4all.nl>
References: <20090307071228.GA1134@faust.net>
	<20090307090054.GA23931@slackbox.xs4all.nl>
Message-ID: <20090307143421.GA942@faust.net>

Thanx for reply!

> It won't work if you want the songs to have the right metadata; You'd
> have to supply that to the pipe in some way...

K. I would use metaflac anyway.

> For ripping I use cdparanoia: 'cdparanoia -B 1' rips all tracks.

I was intended to have something like:
  cdparanoia -B - | flac -

> The following perl scripts reads a text file containing the metadata
> (artist, album name, track data) and calls flac:
> 
> ----- make-flac -----
> #!/usr/bin/perl
> #
> # Compiles a list of wav files into flac files.
> #
> # Author: R.F. Smith <rsmith@xs4all.nl>
> # Time-stamp: <2008-07-30 23:53:00 rsmith>
> #
> # I, the copyright holder of this work, hereby release it into
> # the public domain. This applies worldwide.
> #
> # In case this is not legally possible, I grant any entity the right to use
> # this work for any purpose, without any conditions, unless such conditions
> # are required by law.
> 
> # Check for programs that this script needs.
> chomp($flac = `which flac 2>/dev/null`);
> -x $flac || die "Cannot find flac: $!\n";
> #chomp($norm = `which normalize 2>/dev/null`);
> #-x $norm || die "Cannot find normalize: $!\n";
> 
> # Get the name of the file containing the titles.
> if ($ARGV[0] ne "") {
>     $fname = $ARGV[0];
> } else {
>     $fname = "titles";
> }
> 
> # open the list of song titles
> open (TITELS, $fname) || die "cannot open $fname: $!\n";
> 
> # The titles file format is as follows:
> # ------------------------------------
> # album title
> # artist
> # 01 title of 1st song
> # ..
> # 14 title of 14th song
> # ..
> 
> # get the album title and performer name
> chomp($album = <TITELS>);
> $album ne "" || die "cannot read album name";
> chomp($artist = <TITELS>);
> $artist ne "" || die "cannot read artist name";
> 
> # Normalize the wav files.
> #printf("Normalizing .wav files...\n");
> #`$norm -b track*.cdda.wav`;
> 
> # go over all the songs
> while(<TITELS>) {
>     chomp;
>     ($num, $title) = split (' ', $_, 2);
>     printf ("Encoding \"%s\" as %s\n", $title, "track".$num.".flac");
>     # invoke the flac encoder.
>     do {
>         $rc = system ($flac, "-8", "-TARTIST=".$artist, "-TALBUM=".$album, 
>                       "-TTITLE=".$title,  "-TTRACKNUMBER=".$num, 
>                       "-o", "track".$num.".flac", "track".$num.".cdda.wav");
>         if ($rc != 0) {print "\nError,", $rc, "starting again";}
>     } until $rc == 0;
> }
> ----- make-flac -----

He-he! flac defaults to -5, I think. Probably it would do the same trick
as pipe, just metadata are stored with no nad work. Thank you once
more.
Best regards

                                       Zoran

From zkolic at sbb.co.yu  Sat Mar  7 06:39:45 2009
From: zkolic at sbb.co.yu (Zoran Kolic)
Date: Sat Mar  7 06:39:59 2009
Subject: cd ripping to flac
In-Reply-To: <49B2399E.5070206@ksu.ru>
References: <20090307071228.GA1134@faust.net> <49B2399E.5070206@ksu.ru>
Message-ID: <20090307143900.GB942@faust.net>

> audio/abcde

Thank you for reply.
As I see in Makefile, abcde uses cdparanoia as
an engine for the job. I think I should stay
with simple app.
My thinkering was: what is the background app
people on this list use? I consider either
cdparanoia or cdda2wav. What makes me nervous is
I do not see device in /dev directory. I should
point to tracks on the cd, like acd0t1 etc.
Best regards

                             Zoran

From zkolic at sbb.co.yu  Sat Mar  7 07:00:06 2009
From: zkolic at sbb.co.yu (Zoran Kolic)
Date: Sat Mar  7 07:00:13 2009
Subject: cd ripping to flac
Message-ID: <20090307145926.GA1138@faust.net>

K, this command as root makes the flac file:
  cdparanoia 1 - | flac - -o song.flac
-rw-r--r--  1 root  wheel  23560791 Mar  7 15:53 song.flac
At this moment I cannot check if it plays correctly.
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 14 bytes
  maximum framesize: 12670 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 9603804
etc.
Best regards

                        Zoran

From tobias.rehbein at web.de  Sat Mar  7 07:35:02 2009
From: tobias.rehbein at web.de (Tobias Rehbein)
Date: Sat Mar  7 07:35:10 2009
Subject: cd ripping to flac
In-Reply-To: <20090307143900.GB942@faust.net>
References: <20090307071228.GA1134@faust.net> <49B2399E.5070206@ksu.ru>
	<20090307143900.GB942@faust.net>
Message-ID: <20090307151053.GA52319@sushi.pseudo.local>

Am Sat, Mar 07, 2009 at 03:39:00PM +0100 schrieb Zoran Kolic:
> > audio/abcde
> 
> Thank you for reply.
> As I see in Makefile, abcde uses cdparanoia as
> an engine for the job. I think I should stay
> with simple app.

Right now I'm ripping my CD collection using audio/ripit. It's a great tool, you
should have a look at it. It supports different ripping engines and encoders.
If you want you can encode into different codecs with one go.

> My thinkering was: what is the background app
> people on this list use? I consider either

Me, I'm using cdparanoia. It stumbles over mixed-mode and enhanced CDs but the
--ghost option of ripit fixes this issue.

Regards

Tobias

-- 
Tobias Rehbein

PGP key:         4F2AE314
    server:      keys.gnupg.net
    fingerprint: ECDA F300 1B6E 9B87 8524  8663 E8B6 3138 4F2A E314
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090307/ea1b10e8/attachment.pgp
From ianjhart at ntlworld.com  Sat Mar  7 09:18:19 2009
From: ianjhart at ntlworld.com (ian j hart)
Date: Sat Mar  7 09:18:26 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090120024519.GB79785@cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<200901191833.51320.jkim@FreeBSD.org>
	<20090120024519.GB79785@cdnetworks.co.kr>
Message-ID: <200903071717.57915.ianjhart@ntlworld.com>

On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote:
> On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote:
>  > On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote:
>  > > I found something interesting.  I have another RTL8169SC that works
>  > > perfectly fine without the patch.  The hardware revision is
>  > > 0x18000000.  After reading Linux driver (drivers/net/r8169c), I
>  > > realised they use different masks for hardware revisions.  With
>  > > their logic, non-working chip seems to be 0x98000000 (8110SCe)
>  > > while working chip seems to be 0x18000000 (8110SCd) with
>  > > 0xfc800000. FYI...
>  >
>  > Now armed with the information, I made it work without reverting
>  > memory mapped I/O. :-)
>  >
>  > http://people.freebsd.org/~jkim/re/re.current2.diff
>  > http://people.freebsd.org/~jkim/re/re.stable2.diff
>
> I like the patch. Since only RTL8169 family uses mask 0xfc800000
> it would be even better we can limit checking scope for RTL8169SC
> by comparing PCI device id. I don't know what other side effect
> would happen if the mask 0xfc800000 would be used on 8101/8168
> controllers.
> If the patch works on RTL8169SC would you commit the patch?
> I'd like to see multiple commits separated by each enhancements
> as the patch contains several fixes which are not directly related
> with the issue.

Where are we on this?

I have a headless firewall box which is not happy with 7.1-RELEASE. I've upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY read failed' errors, although the network did come up, which was an improvement.

Is there a patch I can try?

http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174&proname=AD3RTLAN-G

re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0
re0: Chip rev. 0x18000000
re0: MAC rev. 0x00000000
re0: Ethernet address: 00:30:18:ae:1a:1b
re0: [FILTER]
re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0
re1: Chip rev. 0x18000000
re1: MAC rev. 0x00000000
re1: Ethernet address: 00:30:18:ae:1a:1c
re1: [FILTER]
re2: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0
re2: Chip rev. 0x18000000
re2: MAC rev. 0x00000000
re2: Ethernet address: 00:30:18:ae:1a:1d
re2: [FILTER]

re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00
re1@pci0:0:11:0:        class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00
re2@pci0:0:12:0:        class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00

Thanks

-- 
ian j hart
From mike at jellydonut.org  Sat Mar  7 09:32:13 2009
From: mike at jellydonut.org (Michael Proto)
Date: Sat Mar  7 09:32:20 2009
Subject: cd ripping to flac
In-Reply-To: <20090307071228.GA1134@faust.net>
References: <20090307071228.GA1134@faust.net>
Message-ID: <1de79840903070911n4fd3853cl4cc96bab77bd87f5@mail.gmail.com>

On Sat, Mar 7, 2009 at 2:12 AM, Zoran Kolic <zkolic@sbb.co.yu> wrote:
> Howdy!
> I'd like to rip my cd-s to flac files using some
> command line app, like cdda2wav or cdparanoia.
> Using pipe to flac utility would be nice and the
> way I'd take. What program acts in that matter?
> Since cdda2wav is in the base, I suppose people
> use it regurarly. Something like:
> ?program {options} - | flac - flac_file.flac
> One more thing bothers me. I cannot see songs on
> the cd in the way of "/dev/acd0t1". I tried to
> stress it using cdcontrol, but no way. The kernel
> is customized, no sound in it, and a lot of others
> has gone. The box is speakers-free, so cannot
> check if it plays in deed.

Take a look at ports/audio/abcde, great command-line util with
configurable options for ripper and encoder.


-Proto
From kostikbel at gmail.com  Sat Mar  7 10:25:27 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sat Mar  7 10:25:34 2009
Subject: "Fatal trap 12: page fault while in kernel mode" on 7.1/amd64,
	but not 7.0
In-Reply-To: <49B19D28.1060803@acm.poly.edu>
References: <49B07482.4080208@acm.poly.edu>
	<1236334857.88789.4.camel@buffy.york.ac.uk>
	<49B19D28.1060803@acm.poly.edu>
Message-ID: <20090307182521.GH41617@deviant.kiev.zoral.com.ua>

On Fri, Mar 06, 2009 at 05:01:12PM -0500, Boris Kochergin wrote:
> Gavin Atkinson wrote:
> >On Thu, 2009-03-05 at 19:55 -0500, Boris Kochergin wrote:
> >  
> >>Ahoy. I recently upgraded an amd64 machine to 7.1-RELEASE, and started 
> >>getting a bunch of these at a pretty high frequency (a few hours to a 
> >>day apart):
> >>
> >>http://acm.poly.edu/~spawk/IMG00033.jpg
> >>
> >>The "current process" is always httpd. They're particularly annoying 
> >>because the machine doesn't actually ever reboot, requiring manual 
> >>intervention. Reverting the kernel back to 7.0 makes the panic go away, 
> >>and the machine had been happily running 7.0 for about a year 
> >>beforehand. I realize that the photo hardly contains any useful 
> >>debugging information, but I was hoping it might look familiar to 
> >>someone. If not, I guess I'll come back with a backtrace.
> >>    
> >
> >A backtrace will almost certainly be necessary to figure out what this
> >issue is, although there is a possibility that the output of
> >"addr2line -e /boot/kernel/kernel.symbols 0x8:0xffffffff802d7010"
> >might help, assuming you've not recompiled your kernel yet.  (That
> >number should be the same as the "instruction pointer" shown by the
> >panic, but as the photo is quite blurred there's a chance I've got it
> >wrong, if you have a better picture of it or wrote it down then use
> >that)
> >
> >Gavin
> >_______________________________________________
> >freebsd-stable@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> >  
> Here it is, with some additional information afterward:
> 
> Unread portion of the kernel message buffer:
> kernel trap 12 with interrupts disabled
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address   = 0x30
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x8:0xffffffff80293faf
> stack pointer           = 0x10:0xffffffff9cbaea70
> frame pointer           = 0x10:0xffffff000fc14000
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                       = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 881 (httpd)
> trap number             = 12
> panic: page fault
> cpuid = 1
> Uptime: 1m51s
> Physical memory: 8185 MB
> Dumping 328 MB: 313 297 281 265 249 233 217 201 185 169 153 137 121 105 
> 89 73 57 41 25 9
> 
> #0  doadump () at pcpu.h:195
> 195     pcpu.h: No such file or directory.
>       in pcpu.h
> (kgdb) where
> #0  doadump () at pcpu.h:195
> #1  0xffffff000fc14000 in ?? ()
> #2  0xffffffff8025eba9 in boot (howto=260) at 
> /usr/src-7.1/sys/kern/kern_shutdown.c:418
> #3  0xffffffff8025efb2 in panic (fmt=0x104 <Address 0x104 out of 
> bounds>) at /usr/src-7.1/sys/kern/kern_shutdown.c:574
> #4  0xffffffff803df5c3 in trap_fatal (frame=0xffffff000fc14000, 
> eva=Variable "eva" is not available.
> ) at /usr/src-7.1/sys/amd64/amd64/trap.c:764
> #5  0xffffffff803e018f in trap (frame=0xffffffff9cbae9c0) at 
> /usr/src-7.1/sys/amd64/amd64/trap.c:290
> #6  0xffffffff803c5c4e in calltrap () at 
> /usr/src-7.1/sys/amd64/amd64/exception.S:209
> #7  0xffffffff80293faf in turnstile_broadcast (ts=0x0, queue=0) at 
> /usr/src-7.1/sys/kern/subr_turnstile.c:836
> #8  0xffffffff8025256a in _mtx_unlock_sleep (m=0xffffffff80593538, 
> opts=Variable "opts" is not available.
> ) at /usr/src-7.1/sys/kern/kern_mutex.c:619
> #9  0xffffffff80275ed3 in __umtx_op_cv_wait (td=0x1ee, uap=Variable 
> "uap" is not available.
> ) at /usr/src-7.1/sys/kern/kern_umtx.c:312
> #10 0xffffffff803dfb78 in syscall (frame=0xffffffff9cbaec80) at 
> /usr/src-7.1/sys/amd64/amd64/trap.c:907
> #11 0xffffffff803c5e5b in Xfast_syscall () at 
> /usr/src-7.1/sys/amd64/amd64/exception.S:330
> #12 0x0000000800f5354c in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)
> 
> The dump was difficult to acquire--the system would often lock up after 
> dumping only a portion of the memory it wanted to save. I can also now 
> trigger the panic pretty reliably using this bit of script:
> 
> #!/usr/local/bin/bash
> 
> for i in {1..900}
> do
> wget --quiet -O /dev/null http://acm.poly.edu/wiki/Hosting &
> done
> 
> ...where the URL is a MediaWiki installation on the afflicted machine.

Can you, please, recompile the kernel with debugging options, and
provoke the panic on it ?

We need at least options INVARIANTS, INVARIANT_SUPPORT and WITNESS.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090307/e1bb2ebb/attachment.pgp
From bettina at apoteelia.net  Sat Mar  7 10:37:28 2009
From: bettina at apoteelia.net (Bettina Schmidtberger)
Date: Sat Mar  7 10:37:41 2009
Subject: Der versprochene Geheimtipp
Message-ID: <d1e4116bdff4e5fbe25ad86318ef4a5c@localhost.localdomain>

Hi Du!

Wie ich es Dir versprochen habe, wollte ich Dir ja noch die Adresse
sagen wo wir die Dinger bestellt haben. Gibt ja viele Seiten wo man
echt nur ?bers Ohr gehauen wird. Aber bei der Adresse bekommen wir
immer nur Originalware und das innheralb k?rzester Zeit zugeschickt.

Mit dem Zoll hatten wir da auch nie Probleme, da der Versand direkt
aus Europa erfolgt. Klasse oder?

Also hier nun die Adresse:

http://www.apoteelia.net

Viel Spass w?nsch ich Dir und das es gut funktioniert!

Gru?,

Deine Bettina

.

.

-

.

.

.

.

.

.

.

.

.

.

:

.

Gib Acht! Man hatte dir eingeredet, du h?ttest es schwer, dein Leben
sei verpfuscht, das Leben sei eine Schuld, sei schlecht, ohne Sinn,
ohne Wert; man wollte dich ducken, dich in die gro?e Armee der
Leidenden schmuggeln, du solltest bemitleidenswert werden und
bemitleiden: und du glaubtest ihnen ? wie ungern! ? und wieder
nicht ? wie gern! Denn du bist stark, aber warst krank ? wo? wie?
was wei? ich. Und deine Sehnsucht war, herauszukommen aus allen
diesen m?den Verneinungen, diesen t?richten Formeln, die im Nein ihr
Ja haben, diesen t?nenden Wissenschaften, diesen Worten ?. Deswegen
sprangst du von Buch zu Buch, spieltest mit ihren Formeln und lie?est
sie wieder fallen, die Neins und Wenns, um selber eine zu finden, aber
ein Ja! sollte sie klingen ? denn du wolltest leben! Aber nicht wie
der P?bel lebt ? einen Grund, ein Ziel, eine Lebensformel suchtest
du. Nun, hier ist sie:

Wei?t du: das Himmelsweinglas, das du ausschl?rfen wolltest ? ?
nun niete dir die Formel: Die Welt schaffst du.

Du vergeistigst das Chaos zur Welt; das Andere, das Noch-nicht-Du,
das alte Ding an sich, ist nur das, was von dir noch nicht geschaffen,
vermenschlicht, noch nicht dein Eigentum geworden ist. ? Du schaffst
die Welt: nun lebe, lebe! ?

Die kleine blaue Blume l?utete so froh und stark ? warum soll ich
ihr nicht glauben?

Und dann bin ich baden gegangen ? ? ? und habe stundenlang im
Grase gelegen; und w?hrend die wei?en Wolken durch den Himmel
segelten und der Flu? geruhig durch Schilfduft und Ried und
schwatzendes Vogelvolk hinstr?mte, habe ich das Ding an sich, den
Intellekt und den Willen verlacht und mir ein Ich-wei?-nicht-was?
gew?nscht.

Gegen Abend entstiegen Schw?rme von Eintagsfliegen dem Flu?, an den
Gr?sern, Halmen und Pfosten kletterten sie hoch und warfen aus der
H?lle sich in die Luft zum kurzen Hochzeitsleben. Die Luft war wei?
?ber den Wassern von den auf und nieder tanzenden Massen ? und die
sinkende Sonne in dem H?henrauch, den der Nordwind gebracht hatte,
rot wie ein Rubin: das h?tte mich fast bezwungen, da? ich schon
begann, die stundenkurze Existenz der Imago zu beklagen und daran
sentimentale Folgerungen zu kn?pfen ? aber da h?rte ich den Enzian
l?uten und ich lachte: Das Tier freut sich jahrelang seines
R?uberlebens, und dieser Liebesflug ist sein taumelnder H?hepunkt.
Es lebe das Leben und seine ewige Br?cke: Venus genetrix!

Vor acht Tagen h?tte ich ihr geflucht und geklagt: Was ist das
Leben? So ist das Leben: es flie?t dahin wie Wellenschaum, kommt u



  

From rizzo at icir.org  Sat Mar  7 17:06:26 2009
From: rizzo at icir.org (Luigi Rizzo)
Date: Sat Mar  7 17:06:34 2009
Subject: updated geom_sched code
Message-ID: <20090308005515.GA68934@onelab2.iet.unipi.it>

Hi all,
this is an update on the work that Fabio Checconi and I are doing
on disk scheduling, which was first announced here a couple of
months ago:

    http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047597.html

Since the previous version, we have done some massive cleanup and
consolidation of the code, fixed a bug in the system's disksort,
and added amd64 support.

We believe the code is now ready for some wider testing
(as long as you are not using g_journal, see below).

Full source code can be downloaded from

    http://info.iet.unipi.it/~luigi/FreeBSD/geom_sched-20090307.tgz

(the archive also includes pre-built RELENG_7/i386 modules).

Instructions on how to install and use the scheduler are included in
the source code, along with some notes on the implemented schedulers.

The major changes from the previous version are the following:

  - support for early loading of scheduler modules, allowing their
    use on root devices;

  - support for the geom 'retaste' function;

  - general cleanup of the code, simplification of the internal
    interfaces, some bugs fixed;

  - support for the ugly binary patching hack on amd64;

  - support for multiple dispatches in RR;

  - support for on-the-fly scheduler switches;

  - support for unloading schedulers in-use.

NOTE: due to the way we store classification info, the schedulers
are probably incompatible with g_journal.

Apart from that (which needs to be fixed by adding a field to the
struct bio), we believe the code to be quite stable now, so future
work will be mainly focused on adding more scheduling algorithms
and doing a thorough performance evaluation under various workloads.
In the meantime we'd really appreciate any comment from you on the
approach we took, and anyone testing the code.

	cheers
	Luigi and Fabio
From pyunyh at gmail.com  Sat Mar  7 18:38:51 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sat Mar  7 18:38:57 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <200903071717.57915.ianjhart@ntlworld.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<200901191833.51320.jkim@FreeBSD.org>
	<20090120024519.GB79785@cdnetworks.co.kr>
	<200903071717.57915.ianjhart@ntlworld.com>
Message-ID: <20090308023642.GB1531@michelle.cdnetworks.co.kr>

On Sat, Mar 07, 2009 at 05:17:57PM +0000, ian j hart wrote:
> On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote:
> > On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote:
> >  > On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote:
> >  > > I found something interesting.  I have another RTL8169SC that works
> >  > > perfectly fine without the patch.  The hardware revision is
> >  > > 0x18000000.  After reading Linux driver (drivers/net/r8169c), I
> >  > > realised they use different masks for hardware revisions.  With
> >  > > their logic, non-working chip seems to be 0x98000000 (8110SCe)
> >  > > while working chip seems to be 0x18000000 (8110SCd) with
> >  > > 0xfc800000. FYI...
> >  >
> >  > Now armed with the information, I made it work without reverting
> >  > memory mapped I/O. :-)
> >  >
> >  > http://people.freebsd.org/~jkim/re/re.current2.diff
> >  > http://people.freebsd.org/~jkim/re/re.stable2.diff
> >
> > I like the patch. Since only RTL8169 family uses mask 0xfc800000
> > it would be even better we can limit checking scope for RTL8169SC
> > by comparing PCI device id. I don't know what other side effect
> > would happen if the mask 0xfc800000 would be used on 8101/8168
> > controllers.
> > If the patch works on RTL8169SC would you commit the patch?
> > I'd like to see multiple commits separated by each enhancements
> > as the patch contains several fixes which are not directly related
> > with the issue.
> 
> Where are we on this?
> 
> I have a headless firewall box which is not happy with 7.1-RELEASE. I've upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY read failed' errors, although the network did come up, which was an improvement.
> 
> Is there a patch I can try?
> 
> http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174&proname=AD3RTLAN-G
> 
> re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0
> re0: Chip rev. 0x18000000
> re0: MAC rev. 0x00000000
> re0: Ethernet address: 00:30:18:ae:1a:1b
> re0: [FILTER]
> re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0
> re1: Chip rev. 0x18000000
> re1: MAC rev. 0x00000000
> re1: Ethernet address: 00:30:18:ae:1a:1c
> re1: [FILTER]
> re2: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0
> re2: Chip rev. 0x18000000
> re2: MAC rev. 0x00000000
> re2: Ethernet address: 00:30:18:ae:1a:1d
> re2: [FILTER]
> 
> re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00
> re1@pci0:0:11:0:        class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00
> re2@pci0:0:12:0:        class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00
> 

Have you tried re(4) in HEAD?
I had one report that re(4) in HEAD still does not fix the issue so
I posted a possible workaround for that. Unfortunately he didn't
report back so I don't know whether it was right workaround or not. 
If re(4) in HEAD does not fix the issue, would you try attached
patch and let me know how it goes?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: re.8169sc.diff
Type: text/x-diff
Size: 2034 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090308/feaef35d/re.8169sc.bin
From tinderbox at freebsd.org  Sat Mar  7 18:50:16 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Sat Mar  7 18:50:23 2009
Subject: [releng_7 tinderbox] failure on powerpc/powerpc
Message-ID: <20090308025012.53DA11B5060@freebsd-stable.sentex.ca>

TB --- 2009-03-08 01:42:02 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2009-03-08 01:42:02 - starting RELENG_7 tinderbox run for powerpc/powerpc
TB --- 2009-03-08 01:42:02 - cleaning the object tree
TB --- 2009-03-08 01:42:25 - cvsupping the source tree
TB --- 2009-03-08 01:42:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile
TB --- 2009-03-08 01:42:33 - building world
TB --- 2009-03-08 01:42:33 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-03-08 01:42:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-03-08 01:42:33 - TARGET=powerpc
TB --- 2009-03-08 01:42:33 - TARGET_ARCH=powerpc
TB --- 2009-03-08 01:42:33 - TZ=UTC
TB --- 2009-03-08 01:42:33 - __MAKE_CONF=/dev/null
TB --- 2009-03-08 01:42:33 - cd /src
TB --- 2009-03-08 01:42:33 - /usr/bin/make -B buildworld
>>> World build started on Sun Mar  8 01:42:34 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Sun Mar  8 02:48:04 UTC 2009
TB --- 2009-03-08 02:48:04 - generating LINT kernel config
TB --- 2009-03-08 02:48:04 - cd /src/sys/powerpc/conf
TB --- 2009-03-08 02:48:04 - /usr/bin/make -B LINT
TB --- 2009-03-08 02:48:04 - building LINT kernel
TB --- 2009-03-08 02:48:04 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-03-08 02:48:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-03-08 02:48:04 - TARGET=powerpc
TB --- 2009-03-08 02:48:04 - TARGET_ARCH=powerpc
TB --- 2009-03-08 02:48:04 - TZ=UTC
TB --- 2009-03-08 02:48:04 - __MAKE_CONF=/dev/null
TB --- 2009-03-08 02:48:04 - cd /src
TB --- 2009-03-08 02:48:04 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sun Mar  8 02:48:04 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
--------------------------------------------------------------
cd /obj/powerpc/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/powerpc  MACHINE_ARCH=powerpc  MACHINE=powerpc  CPUTYPE=  GROFF_BIN_PATH=/obj/powerpc/src/tmp/legacy/usr/bin  GROFF_FONT_PATH=/obj/powerpc/src/tmp/legacy/usr/share/groff_font  GROFF_TMAC_PATH=/obj/powerpc/src/tmp/legacy/usr/share/tmac  _SHLIBDIRPREFIX=/obj/powerpc/src/tmp  VERSION="FreeBSD 7.0-BETA2 i386 700055"  INSTALL="sh /src/tools/install.sh"  PATH=/obj/powerpc/src/tmp/legacy/usr/sbin:/obj/powerpc/src/tmp/legacy/usr/bin:/obj/powerpc/src/tmp/legacy/usr/games:/obj/powerpc/src/tmp/usr/sbin:/obj/powerpc/src/tmp/usr/bin:/obj/powerpc/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 /usr/bin/make KERNEL=kernel all -DNO_MODULES_OBJ
cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -Werror /src/sys/powerpc/powerpc/locore.S
/src/sys/powerpc/powerpc/trap_subr.S: Assembler messages:
/src/sys/powerpc/powerpc/trap_subr.S:522: Error: undefined symbol `TMPSTKSZ' in operation
/src/sys/powerpc/powerpc/trap_subr.S:523: Error: undefined symbol `TMPSTKSZ' in operation
*** Error code 1

Stop in /obj/powerpc/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-03-08 02:50:12 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-03-08 02:50:12 - ERROR: failed to build lint kernel
TB --- 2009-03-08 02:50:12 - 3423.20 user 347.83 system 4089.30 real


http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full
From ehrmann at gmail.com  Sat Mar  7 21:34:16 2009
From: ehrmann at gmail.com (David Ehrmann)
Date: Sat Mar  7 21:34:22 2009
Subject: vge0 not autonegotiating to 1000baseTX full duplex in 7.1
Message-ID: <49B355FA.2090906@gmail.com>

It's been reported before, but I haven't seen anything new.  vge devices 
won't autonegotiate to gigabit speeds, and if I set the media to 
1000baseTX, ifconfig reports "no carrier."  This was with two different 
interfaces on the other end, one a switch, the other another computer 
(but not a vge one).

Any ideas?
From pyunyh at gmail.com  Sun Mar  8 00:17:55 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Mar  8 00:18:02 2009
Subject: vge0 not autonegotiating to 1000baseTX full duplex in 7.1
In-Reply-To: <49B355FA.2090906@gmail.com>
References: <49B355FA.2090906@gmail.com>
Message-ID: <20090308081550.GC1531@michelle.cdnetworks.co.kr>

On Sat, Mar 07, 2009 at 09:22:02PM -0800, David Ehrmann wrote:
> It's been reported before, but I haven't seen anything new.  vge devices 

Because I don't have access to the hardware it looks like hard to
fix.

> won't autonegotiate to gigabit speeds, and if I set the media to 
> 1000baseTX, ifconfig reports "no carrier."  This was with two different 
> interfaces on the other end, one a switch, the other another computer 
> (but not a vge one).
> 
> Any ideas?

Would you show me the output of dmesg?(Only vge(4) related one)
Also show me the output of "devinfo -rv | grep phy".
From ota at j.email.ne.jp  Sun Mar  8 00:40:18 2009
From: ota at j.email.ne.jp (Yoshihiro Ota)
Date: Sun Mar  8 00:40:27 2009
Subject: Where is nfsiod now?
Message-ID: <20090308044012.0a666ff6.ota@j.email.ne.jp>

Hello.

I thought rc used to start nfsiod if you set nfs_cilent_enable
back years ago.
Now, on my 7.1-RELEASE machine, it sets up a couple of sysctls
in /etc/rc.d/nfsclient script but not nfsiod.

Is nfsiod obsolete by now?
It is still on the system; does it still improve nfs performance?

Thanks,
Hiro
From beat.siegenthaler at beatsnet.com  Sun Mar  8 01:08:03 2009
From: beat.siegenthaler at beatsnet.com (Beat Siegenthaler)
Date: Sun Mar  8 01:08:10 2009
Subject: fxp unusable after make world
In-Reply-To: <1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com>
References: <49B1AC25.3000700@onetel.com>	<27998819.871236382003017.JavaMail.HALO$@halo>
	<1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com>
Message-ID: <49B38AEF.8070909@beatsnet.com>

Hi,

last week I made a rebuild on my system (7.1 RELENG_7 amd64).

After this i could not reach my system from outside the LAN. It was
extremely slow. I suspected Modem, Firewall and so on, because inside my
LAN I could work. But then with tshark I found, that also there where
many retransmissions and checksum errors.

Then, short in time I replaced the dual EtherExpress PRO/100

fxp0@pci0:2:4:0:        class=0x020000 card=0x10158086 chip=0x12298086
rev=0x0d hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
    class      = network
    subclass   = ethernet
fxp1@pci0:2:5:0:        class=0x020000 card=0x10158086 chip=0x12298086
rev=0x0d hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
    class      = network
    subclass   = ethernet

With two cheap Realtek cards and the problem was gone...

re0@pci0:0:12:0:        class=0x020000 card=0x001a6409 chip=0x816910ec
rev=0x10 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller'
    class      = network
    subclass   = ethernet
re1@pci0:0:13:0:        class=0x020000 card=0x001a6409 chip=0x816910ec
rev=0x10 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller'
    class      = network
    subclass   = ethernet


I see that the fxp-code was touched short time ago.

P.S This is the first time since Years, that make world made one of my
Systems unusable....
From beat.siegenthaler at beatsnet.com  Sun Mar  8 01:20:58 2009
From: beat.siegenthaler at beatsnet.com (Beat Siegenthaler)
Date: Sun Mar  8 01:21:05 2009
Subject: fxp unusable after make world
Message-ID: <49B38DF6.7010805@beatsnet.com>

Hi,

last week I made a rebuild on my system (7.1 RELENG_7 amd64).

After this i could not reach my system from outside the LAN. It was
extremely slow. I suspected Modem, Firewall and so on, because inside my
LAN I could work. But then with tshark I found, that also there where
many retransmissions and checksum errors.

Then, short in time I replaced the dual EtherExpress PRO/100

fxp0@pci0:2:4:0:        class=0x020000 card=0x10158086 chip=0x12298086
rev=0x0d hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
    class      = network
    subclass   = ethernet
fxp1@pci0:2:5:0:        class=0x020000 card=0x10158086 chip=0x12298086
rev=0x0d hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
    class      = network
    subclass   = ethernet

With two cheap Realtek cards and the problem was gone...

re0@pci0:0:12:0:        class=0x020000 card=0x001a6409 chip=0x816910ec
rev=0x10 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller'
    class      = network
    subclass   = ethernet
re1@pci0:0:13:0:        class=0x020000 card=0x001a6409 chip=0x816910ec
rev=0x10 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller'
    class      = network
    subclass   = ethernet


I see that the fxp-code was touched short time ago.

P.S This is the first time since Years, that make world made one of my
Systems unusable....

From zanchey at ucc.gu.uwa.edu.au  Sun Mar  8 01:22:26 2009
From: zanchey at ucc.gu.uwa.edu.au (David Adam)
Date: Sun Mar  8 01:22:35 2009
Subject: 7.1 new install halts on BTX error
In-Reply-To: <200903021210.39757.jhb@freebsd.org>
References: <alpine.DEB.1.10.0901142326370.12175@martello.ucc.gu.uwa.edu.au>
	<200903021210.39757.jhb@freebsd.org>
Message-ID: <alpine.DEB.1.10.0903081819460.24502@martello.ucc.gu.uwa.edu.au>

On Mon, 2 Mar 2009, John Baldwin wrote:
> On Wednesday 28 January 2009 10:13:46 pm David Adam wrote:
> > I upgraded my 7.0 system to 7.1-RELEASE with freebsd-update only to find 
> > that it no longer boots correctly, instead crashing with a BTX backtrace. 
> > If I break to the loader prompt and use 'ls /boot', I also get a 
> > backtrace.
> > 
<snip>
> I wonder if your stack is growing into the heap (the GPT stuff made the
> loader a bit bigger).  You can try something like this:

Hi John,

I tired -CURRENT when the previous changes were committed (see my previous 
email on Mar 1). I can confirm that -CURRENT with that patch applied now 
boots fine on my system.

Thanks,

David Adam
zanchey@ucc.gu.uwa.edu.au

From pyunyh at gmail.com  Sun Mar  8 01:39:01 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Mar  8 01:39:08 2009
Subject: fxp unusable after make world
In-Reply-To: <49B38AEF.8070909@beatsnet.com>
References: <49B1AC25.3000700@onetel.com>
	<27998819.871236382003017.JavaMail.HALO$@halo>
	<1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com>
	<49B38AEF.8070909@beatsnet.com>
Message-ID: <20090308093653.GD1531@michelle.cdnetworks.co.kr>

On Sun, Mar 08, 2009 at 10:07:59AM +0100, Beat Siegenthaler wrote:
> Hi,
> 
> last week I made a rebuild on my system (7.1 RELENG_7 amd64).
> 
> After this i could not reach my system from outside the LAN. It was
> extremely slow. I suspected Modem, Firewall and so on, because inside my
> LAN I could work. But then with tshark I found, that also there where
> many retransmissions and checksum errors.
> 
> Then, short in time I replaced the dual EtherExpress PRO/100
> 
> fxp0@pci0:2:4:0:        class=0x020000 card=0x10158086 chip=0x12298086
> rev=0x0d hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
>     class      = network
>     subclass   = ethernet
> fxp1@pci0:2:5:0:        class=0x020000 card=0x10158086 chip=0x12298086
> rev=0x0d hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
>     class      = network
>     subclass   = ethernet
> 
> With two cheap Realtek cards and the problem was gone...
> 
> re0@pci0:0:12:0:        class=0x020000 card=0x001a6409 chip=0x816910ec
> rev=0x10 hdr=0x00
>     vendor     = 'Realtek Semiconductor'
>     device     = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller'
>     class      = network
>     subclass   = ethernet
> re1@pci0:0:13:0:        class=0x020000 card=0x001a6409 chip=0x816910ec
> rev=0x10 hdr=0x00
>     vendor     = 'Realtek Semiconductor'
>     device     = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller'
>     class      = network
>     subclass   = ethernet
> 
> 
> I see that the fxp-code was touched short time ago.
> 

I touched fxp(4) to add more hardware assistance so it could cause
problems on your box. Please show me dmesg output and
"ifconfig fxp0"
output.

If you doubt checksum offloading or TSO issues, try
"ifconfig fxp0 -tso -txcsum -rxcsum".

> P.S This is the first time since Years, that make world made one of my
> Systems unusable....
From ruben at verweg.com  Sun Mar  8 03:57:12 2009
From: ruben at verweg.com (Ruben van Staveren)
Date: Sun Mar  8 03:57:19 2009
Subject: Various route locking fixes merged to stable/7 (was: Re: Big
	problems with 7.1 locking up :-()
In-Reply-To: <alpine.OSX.2.00.0902252027450.509@freemac.nat.fasttrackmonkey.com>
References: <E1LcGMf-000Om9-Ey@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0902251051230.64866@fledge.watson.org>
	<alpine.BSF.2.00.0902251130240.64866@fledge.watson.org>
	<alpine.OSX.2.00.0902252027450.509@freemac.nat.fasttrackmonkey.com>
Message-ID: <E0513803-2580-4187-8BB2-1C0EA449A4EA@verweg.com>

Hi,
On 26 Feb 2009, at 2:28, Charles Sprickman wrote:

> On Wed, 25 Feb 2009, Robert Watson wrote:
>
>> Just a minor heads up: I've merged both Kip Macy's lock order fixes  
>> to the kernel routing code, and the route locking and reference  
>> counting fixes from kern/130652 to stable/7.  These fixes should  
>> correct a number of reported network-related hangs.  We might want  
>> to release a subset of these as an errata patch to 7.1 if they  
>> shake out well in 7-stable.
>
> +1
>
> Charles

Unfortunately these changes let my system panic during early boot,  
around the time when ppp/routing is started. Backing out these changes  
prevents the panic.

I've filed this with some textdumps as: kern/132404: panic sleeping  
thread after 25th Feb src/sys/net commits

http://www.freebsd.org/cgi/query-pr.cgi?pr=132404

Regards,
	Ruben
From rwatson at FreeBSD.org  Sun Mar  8 04:24:56 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sun Mar  8 04:25:04 2009
Subject: Panics involving ppp following routing fixes
In-Reply-To: <E0513803-2580-4187-8BB2-1C0EA449A4EA@verweg.com>
References: <E1LcGMf-000Om9-Ey@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0902251051230.64866@fledge.watson.org>
	<alpine.BSF.2.00.0902251130240.64866@fledge.watson.org>
	<alpine.OSX.2.00.0902252027450.509@freemac.nat.fasttrackmonkey.com>
	<E0513803-2580-4187-8BB2-1C0EA449A4EA@verweg.com>
Message-ID: <alpine.BSF.2.00.0903081123310.1340@fledge.watson.org>

On Sun, 8 Mar 2009, Ruben van Staveren wrote:

>>> Just a minor heads up: I've merged both Kip Macy's lock order fixes to the 
>>> kernel routing code, and the route locking and reference counting fixes 
>>> from kern/130652 to stable/7.  These fixes should correct a number of 
>>> reported network-related hangs.  We might want to release a subset of 
>>> these as an errata patch to 7.1 if they shake out well in 7-stable.
>
> Unfortunately these changes let my system panic during early boot, around 
> the time when ppp/routing is started. Backing out these changes prevents the 
> panic.
>
> I've filed this with some textdumps as: kern/132404: panic sleeping thread 
> after 25th Feb src/sys/net commits
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=132404

Hi Ruben--

I've had a number of similar reports, but this one contained enough 
information for me to (hopefully) track it down.  I've merged a fix from head 
as r189531 that corrects lock leak in error-handling in the routing socket 
code.  Could you let me know if that helps with the problem?

Robert N M Watson
Computer Laboratory
University of Cambridge
From rwatson at FreeBSD.org  Sun Mar  8 05:18:55 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sun Mar  8 05:19:01 2009
Subject: Where is nfsiod now?
In-Reply-To: <20090308044012.0a666ff6.ota@j.email.ne.jp>
References: <20090308044012.0a666ff6.ota@j.email.ne.jp>
Message-ID: <alpine.BSF.2.00.0903081214230.1340@fledge.watson.org>

On Sun, 8 Mar 2009, Yoshihiro Ota wrote:

> I thought rc used to start nfsiod if you set nfs_cilent_enable back years 
> ago. Now, on my 7.1-RELEASE machine, it sets up a couple of sysctls in 
> /etc/rc.d/nfsclient script but not nfsiod.
>
> Is nfsiod obsolete by now?
> It is still on the system; does it still improve nfs performance?

In the historic BSD kernel, kernel threads for services such as asynchronous 
NFS write-behind worker (which is what nfsiod is) were created via user 
processes that "donated" their thread context to the kernel by blocking in a 
syscall.  In modern FreeBSD kernels, kernel threads can be created and 
destroyed arbitrarily within the kernel as required, so the size of the worker 
thread pool is controlled by sysctls -- by default there will be none unless 
required for an NFS mount, and then a pool will be maintained based on use 
with a limit.  For example, on my box without NFS active, I see:

robert@fledge:/usr/src/sbin/nfsiod> sysctl vfs.nfs | grep iod
vfs.nfs.iodmax: 20
vfs.nfs.iodmin: 0
vfs.nfs.iodmaxidle: 120

We have a minimum of 0, a maximum of 20 workers, and idle workers are killed 
off after a timeout of 120 seconds.  When using an NFS client with 
write-behind, you should see kernel threads named "nfsiod X" where X is the 
worker thread number.  Take a look at src/sys/nfsclient/nfs_nfsiod.c for 
details.

Robert N M Watson
Computer Laboratory
University of Cambridge
From ruben at verweg.com  Sun Mar  8 06:23:25 2009
From: ruben at verweg.com (Ruben van Staveren)
Date: Sun Mar  8 06:23:32 2009
Subject: Panics involving ppp following routing fixes
In-Reply-To: <alpine.BSF.2.00.0903081123310.1340@fledge.watson.org>
References: <E1LcGMf-000Om9-Ey@dilbert.ticketswitch.com>
	<alpine.BSF.2.00.0902251051230.64866@fledge.watson.org>
	<alpine.BSF.2.00.0902251130240.64866@fledge.watson.org>
	<alpine.OSX.2.00.0902252027450.509@freemac.nat.fasttrackmonkey.com>
	<E0513803-2580-4187-8BB2-1C0EA449A4EA@verweg.com>
	<alpine.BSF.2.00.0903081123310.1340@fledge.watson.org>
Message-ID: <19AFC979-C6A3-4ACA-BE7F-92FFD174D662@verweg.com>

Hi Robert,

On 8 Mar 2009, at 12:24, Robert Watson wrote:

> On Sun, 8 Mar 2009, Ruben van Staveren wrote:
>
>>>> Just a minor heads up: I've merged both Kip Macy's lock order  
>>>> fixes to the kernel routing code, and the route locking and  
>>>> reference counting fixes from kern/130652 to stable/7.  These  
>>>> fixes should correct a number of reported network-related hangs.   
>>>> We might want to release a subset of these as an errata patch to  
>>>> 7.1 if they shake out well in 7-stable.
>>
>> Unfortunately these changes let my system panic during early boot,  
>> around the time when ppp/routing is started. Backing out these  
>> changes prevents the panic.
>>
>> I've filed this with some textdumps as: kern/132404: panic sleeping  
>> thread after 25th Feb src/sys/net commits
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=132404
>
> Hi Ruben--
>
> I've had a number of similar reports, but this one contained enough  
> information for me to (hopefully) track it down.  I've merged a fix  
> from head as r189531 that corrects lock leak in error-handling in  
> the routing socket code.  Could you let me know if that helps with  
> the problem?

Yes, Using rev 1.143.2.9 of src/sys/net/rtsock.c indeed solves the  
problem, thanks!


> Robert N M Watson
> Computer Laboratory
> University of Cambridge


Regards,
	Ruben

>


From beat.siegenthaler at beatsnet.com  Sun Mar  8 10:04:41 2009
From: beat.siegenthaler at beatsnet.com (Beat Siegenthaler)
Date: Sun Mar  8 10:04:51 2009
Subject: fxp unusable after make world
In-Reply-To: <20090308093653.GD1531@michelle.cdnetworks.co.kr>
References: <49B1AC25.3000700@onetel.com>
	<27998819.871236382003017.JavaMail.HALO$@halo>
	<1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com>
	<49B38AEF.8070909@beatsnet.com>
	<20090308093653.GD1531@michelle.cdnetworks.co.kr>
Message-ID: <49B3FAA3.9010302@beatsnet.com>

Pyun YongHyeon wrote:

> 
> I touched fxp(4) to add more hardware assistance so it could cause
> problems on your box. Please show me dmesg output and
> "ifconfig fxp0"
> output.
> 
> If you doubt checksum offloading or TSO issues, try
> "ifconfig fxp0 -tso -txcsum -rxcsum".
> 

As I remember this Dual card is out of a "Symantec/RaQ/Raptor/Firewall"
and has a 3DES CryptoChip onboard.

[root@atom:~] # ifconfig fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:02:b3:b8:e5:7f
        inet6 fe80::202:b3ff:feb8:e57f%fxp0 prefixlen 64 scopeid 0x3
        media: Ethernet autoselect (none)
        status: no carrier
[root@atom:~] # ifconfig fxp1
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:02:b3:b8:e5:80
        inet6 fe80::202:b3ff:feb8:e580%fxp1 prefixlen 64 scopeid 0x4
        media: Ethernet autoselect (none)
        status: no carrier


[root@atom:~] # dmesg
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #3: Thu Mar  5 17:03:54 CET 2009
    root@atom.beatsnet.com:/usr/obj/usr/src/sys/ATOM_amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 Processor 3200+ (2002.57-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x10ff0  Stepping = 0

Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
  AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
  AMD Features2=0x1<LAHF>
usable memory = 2137423872 (2038 MB)
avail memory  = 2061045760 (1965 MB)
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <VIA K8T800Pro host to PCI bridge> on hostb0
pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pci0: <network, ethernet> at device 10.0 (no driver attached)
re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
port 0x8800-0x88ff mem 0xfb400000-0xfb4000ff irq 17 at device 12.0 on pci0
re0: Chip rev. 0x10000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
re0: Ethernet address: 00:30:4f:60:3e:16
re0: [FILTER]
re1: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
port 0x9000-0x90ff mem 0xfb600000-0xfb6000ff irq 18 at device 13.0 on pci0
re1: Chip rev. 0x10000000
re1: MAC rev. 0x00000000
miibus1: <MII bus> on re1
rgephy1: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus1
rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
re1: Ethernet address: 00:30:4f:60:3e:2b
re1: [FILTER]
pcib2: <PCI-PCI bridge> at device 14.0 on pci0
pci2: <PCI bus> on pcib2
fxp0: <Intel 82550 Pro/100 Ethernet> port 0xe400-0xe43f mem
0xfbd00000-0xfbd00fff,0xfbc00000-0xfbc1ffff irq 19 at device 4.0 on pci2
miibus2: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> PHY 1 on miibus2
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:02:b3:b8:e5:7f
fxp0: [ITHREAD]
fxp1: <Intel 82550 Pro/100 Ethernet> port 0xe800-0xe83f mem
0xfbf00000-0xfbf00fff,0xfbe00000-0xfbe1ffff irq 16 at device 5.0 on pci2
miibus3: <MII bus> on fxp1
inphy1: <i82555 10/100 media interface> PHY 1 on miibus3
inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1: Ethernet address: 00:02:b3:b8:e5:80
fxp1: [ITHREAD]
From ianjhart at ntlworld.com  Sun Mar  8 10:05:32 2009
From: ianjhart at ntlworld.com (ian j hart)
Date: Sun Mar  8 10:05:39 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090308023642.GB1531@michelle.cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<200903071717.57915.ianjhart@ntlworld.com>
	<20090308023642.GB1531@michelle.cdnetworks.co.kr>
Message-ID: <200903081705.12523.ianjhart@ntlworld.com>

On Sunday 08 March 2009 02:36:42 Pyun YongHyeon wrote:
> On Sat, Mar 07, 2009 at 05:17:57PM +0000, ian j hart wrote:
> > On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote:
> > > On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote:
> > >  > On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote:
> > >  > > I found something interesting.  I have another RTL8169SC that
> > >  > > works perfectly fine without the patch.  The hardware revision is
> > >  > > 0x18000000.  After reading Linux driver (drivers/net/r8169c), I
> > >  > > realised they use different masks for hardware revisions.  With
> > >  > > their logic, non-working chip seems to be 0x98000000 (8110SCe)
> > >  > > while working chip seems to be 0x18000000 (8110SCd) with
> > >  > > 0xfc800000. FYI...
> > >  >
> > >  > Now armed with the information, I made it work without reverting
> > >  > memory mapped I/O. :-)
> > >  >
> > >  > http://people.freebsd.org/~jkim/re/re.current2.diff
> > >  > http://people.freebsd.org/~jkim/re/re.stable2.diff
> > >
> > > I like the patch. Since only RTL8169 family uses mask 0xfc800000
> > > it would be even better we can limit checking scope for RTL8169SC
> > > by comparing PCI device id. I don't know what other side effect
> > > would happen if the mask 0xfc800000 would be used on 8101/8168
> > > controllers.
> > > If the patch works on RTL8169SC would you commit the patch?
> > > I'd like to see multiple commits separated by each enhancements
> > > as the patch contains several fixes which are not directly related
> > > with the issue.
> >
> > Where are we on this?
> >
> > I have a headless firewall box which is not happy with 7.1-RELEASE. I've
> > upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY read
> > failed' errors, although the network did come up, which was an
> > improvement.
> >
> > Is there a patch I can try?
> >
> > http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174&proname=AD3RT
> >LAN-G
> >
> > re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0:
> > Chip rev. 0x18000000
> > re0: MAC rev. 0x00000000
> > re0: Ethernet address: 00:30:18:ae:1a:1b
> > re0: [FILTER]
> > re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0
> > re1: Chip rev. 0x18000000
> > re1: MAC rev. 0x00000000
> > re1: Ethernet address: 00:30:18:ae:1a:1c
> > re1: [FILTER]
> > re2: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0
> > re2: Chip rev. 0x18000000
> > re2: MAC rev. 0x00000000
> > re2: Ethernet address: 00:30:18:ae:1a:1d
> > re2: [FILTER]
> >
> > re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10
> > hdr=0x00 re1@pci0:0:11:0:        class=0x020000 card=0x10ec16f3
> > chip=0x816710ec rev=0x10 hdr=0x00 re2@pci0:0:12:0:        class=0x020000
> > card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00
>
> Have you tried re(4) in HEAD?
> I had one report that re(4) in HEAD still does not fix the issue so
> I posted a possible workaround for that. Unfortunately he didn't
> report back so I don't know whether it was right workaround or not.
> If re(4) in HEAD does not fix the issue, would you try attached
> patch and let me know how it goes?

Firstly IANAKH, my expertise in this area stops after "make kernel".

I updated

/usr/src/sys/dev/re/if_re.c
/usr/src/sys/pci/if_rlreg.h

to HEAD

I still get "PHY read failed" with and without the patch.

-- 
ian j hart
From ivoras at freebsd.org  Sun Mar  8 11:39:04 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Sun Mar  8 11:39:12 2009
Subject: updated geom_sched code
In-Reply-To: <20090308005515.GA68934@onelab2.iet.unipi.it>
References: <20090308005515.GA68934@onelab2.iet.unipi.it>
Message-ID: <gp13bt$o06$1@ger.gmane.org>

Luigi Rizzo wrote:
> Hi all,
> this is an update on the work that Fabio Checconi and I are doing
> on disk scheduling, which was first announced here a couple of
> months ago:
> 
>     http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047597.html
> 
> Since the previous version, we have done some massive cleanup and
> consolidation of the code, fixed a bug in the system's disksort,
> and added amd64 support.

> NOTE: due to the way we store classification info, the schedulers
> are probably incompatible with g_journal.
> 
> Apart from that (which needs to be fixed by adding a field to the
> struct bio), we believe the code to be quite stable now, so future
> work will be mainly focused on adding more scheduling algorithms
> and doing a thorough performance evaluation under various workloads.
> In the meantime we'd really appreciate any comment from you on the
> approach we took, and anyone testing the code.

Hi,

Do you have some documentation about the long-term plans? You will have
to add an additional field to bio, of course, but there is one more
thing: the schedulers will have to be integrated into the GEOM in an
"invisible" way. I.e. instead of /dev/ad0-sched-s1f the users should see
only /dev/ad0 like they're used to, and get the schedulers by default.
Otherwise, your work will not get much use.

This is not the only case where "invisible" classes are needed. Back
when I was working on GEOM logging (what has since turned into
gjournal), there was also a need to be able to insert a class
transparently in between two classes in a tree without disturbing either
(so for example you could turn IO request logging if needed on a "hot"
server). IIRC Pawel had some similar needs and maybe some ideas but I
don't know much there.

I've CC-ed freebsd-geom@ so the discussion can get more technical there :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090308/4e2b92ea/signature.pgp
From rizzo at iet.unipi.it  Sun Mar  8 13:33:05 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Sun Mar  8 13:33:12 2009
Subject: updated geom_sched code
In-Reply-To: <gp13bt$o06$1@ger.gmane.org>
References: <20090308005515.GA68934@onelab2.iet.unipi.it>
	<gp13bt$o06$1@ger.gmane.org>
Message-ID: <20090308203811.GA4042@onelab2.iet.unipi.it>

On Sun, Mar 08, 2009 at 07:38:30PM +0100, Ivan Voras wrote:
> Luigi Rizzo wrote:
...
> > Apart from that (which needs to be fixed by adding a field to the
> > struct bio), we believe the code to be quite stable now, so future
...
> Hi,
> 
> Do you have some documentation about the long-term plans? You will have
> to add an additional field to bio, of course, but there is one more
> thing: the schedulers will have to be integrated into the GEOM in an
> "invisible" way. I.e. instead of /dev/ad0-sched-s1f the users should see
> only /dev/ad0 like they're used to, and get the schedulers by default.
> Otherwise, your work will not get much use.

well, if one is comfortable with the schedulers he can just
put the right names in /etc/fstab.

I think the usefulness of 'invisible' classes is more when adding
or removing geom classes on the fly, but perhaps this requires
support in the geom nodes themselves.

In any case I was hoping to discuss this issue later,
either at bsdcan or in the mailing list, once I understand
the implications a bit more.

	cheers
	luigi
From aoyama at peach.ne.jp  Sun Mar  8 13:34:40 2009
From: aoyama at peach.ne.jp (Daisuke Aoyama)
Date: Sun Mar  8 13:34:59 2009
Subject: Tester wanted for multipath failover iSCSI target software
Message-ID: <CF4D70B440A74ADFAE9BB4DEA8BF2B09@artemis>

Hello,

I'm looking for test users for new iSCSI target software designed
for multipath failover cluster nodes.
I'm very interested in the virtual machine such as Hyper-V.
So I'm also tuning the target for using VMs.
I need an environmental report in particular other than FreeBSD 7.1
RELEASE p3 i386/PAE kernel w/ZFS.
I welcome the report with other initiators below.
If you are interested in this software, please download it from the
following site.
The tarball contains configure script to build it.
Please read README and INSTALL in the tarball for more detail.

Tested Initiators:
 o Microsoft Windows Server 2008 (builtin)
 o Microsoft iSCSI Initiator 2.08 on WS2003
 o Intel iSCSI Remote Boot 2.1.22
 o Sun VirtualBOX 2.1.2 (builtin)
 o VMware ESXi 3.5 Update 3 (builtin)

Key Features:
 o MCS/MPIO for failover (up to 255 concurrent sessions)
 o SPC-3 Persistent Reservation for cluster nodes
 o 64bit LBA for over 2TB
 o Header/Data digest by CRC32C
 o CHAP w/Mutual authentication
 o Multiple LUNs and ACLs for portals
(experimental features)
 o iSCSI boot with Intel PRO/1000 Server Adapters
 o virtual DVDROM/DLT emulator
 o pass-through device via CAM

Known Issues:
 o globalSAN iSCSI Initiator for Mac OSX does not establish data I/O
   because of unexpected data segment length.
   I will plan to fix it in the near future.
 o FreeBSD initiator can't connect to the target because of StatSN error.
   I don't know a reason.

Here is release 20090308:
http://shell.peach.ne.jp/aoyama/archives/342
Later version will be uploaded in this blog.
If you need anything other than Japanese, please use translator service.

Thanks,

--
Daisuke Aoyama

From pyunyh at gmail.com  Sun Mar  8 17:08:07 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Mar  8 17:08:14 2009
Subject: fxp unusable after make world
In-Reply-To: <49B3FAA3.9010302@beatsnet.com>
References: <49B1AC25.3000700@onetel.com>
	<27998819.871236382003017.JavaMail.HALO$@halo>
	<1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com>
	<49B38AEF.8070909@beatsnet.com>
	<20090308093653.GD1531@michelle.cdnetworks.co.kr>
	<49B3FAA3.9010302@beatsnet.com>
Message-ID: <20090309000610.GA5039@michelle.cdnetworks.co.kr>

On Sun, Mar 08, 2009 at 06:04:35PM +0100, Beat Siegenthaler wrote:
> Pyun YongHyeon wrote:
> 
> > 
> > I touched fxp(4) to add more hardware assistance so it could cause
> > problems on your box. Please show me dmesg output and
> > "ifconfig fxp0"
> > output.
> > 
> > If you doubt checksum offloading or TSO issues, try
> > "ifconfig fxp0 -tso -txcsum -rxcsum".
> > 

And the command above fixed your issue?

> 
> As I remember this Dual card is out of a "Symantec/RaQ/Raptor/Firewall"
> and has a 3DES CryptoChip onboard.
> 

Your controller looks like i82550. 82550/82551 has nice hardware
cryptographic capability for IPSec acceleration but it's not used
at all under FreeBSD. Intel's open source developer manual didn't
even mention the existence of cryptographic capability.

> [root@atom:~] # ifconfig fxp0
> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>         ether 00:02:b3:b8:e5:7f
>         inet6 fe80::202:b3ff:feb8:e57f%fxp0 prefixlen 64 scopeid 0x3
>         media: Ethernet autoselect (none)
>         status: no carrier
> [root@atom:~] # ifconfig fxp1
> fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>         ether 00:02:b3:b8:e5:80
>         inet6 fe80::202:b3ff:feb8:e580%fxp1 prefixlen 64 scopeid 0x4
>         media: Ethernet autoselect (none)
>         status: no carrier
> 
> 
> [root@atom:~] # dmesg
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>         The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 7.1-STABLE #3: Thu Mar  5 17:03:54 CET 2009
>     root@atom.beatsnet.com:/usr/obj/usr/src/sys/ATOM_amd64
> Timecounter "i8254" frequency 1193182 Hz quality 0
> CPU: AMD Athlon(tm) 64 Processor 3200+ (2002.57-MHz K8-class CPU)
>   Origin = "AuthenticAMD"  Id = 0x10ff0  Stepping = 0
> 
> Features=0x78bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
>   AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
>   AMD Features2=0x1<LAHF>
> usable memory = 2137423872 (2038 MB)
> avail memory  = 2061045760 (1965 MB)
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci0: <ACPI PCI bus> on pcib0
> agp0: <VIA K8T800Pro host to PCI bridge> on hostb0
> pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
> pci1: <ACPI PCI bus> on pcib1
> pci0: <network, ethernet> at device 10.0 (no driver attached)
> re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
> port 0x8800-0x88ff mem 0xfb400000-0xfb4000ff irq 17 at device 12.0 on pci0
> re0: Chip rev. 0x10000000
> re0: MAC rev. 0x00000000
> miibus0: <MII bus> on re0
> rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
> rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> re0: Ethernet address: 00:30:4f:60:3e:16
> re0: [FILTER]
> re1: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet>
> port 0x9000-0x90ff mem 0xfb600000-0xfb6000ff irq 18 at device 13.0 on pci0
> re1: Chip rev. 0x10000000
> re1: MAC rev. 0x00000000
> miibus1: <MII bus> on re1
> rgephy1: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus1
> rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> re1: Ethernet address: 00:30:4f:60:3e:2b
> re1: [FILTER]
> pcib2: <PCI-PCI bridge> at device 14.0 on pci0
> pci2: <PCI bus> on pcib2
> fxp0: <Intel 82550 Pro/100 Ethernet> port 0xe400-0xe43f mem
> 0xfbd00000-0xfbd00fff,0xfbc00000-0xfbc1ffff irq 19 at device 4.0 on pci2
> miibus2: <MII bus> on fxp0
> inphy0: <i82555 10/100 media interface> PHY 1 on miibus2
> inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> fxp0: Ethernet address: 00:02:b3:b8:e5:7f
> fxp0: [ITHREAD]
> fxp1: <Intel 82550 Pro/100 Ethernet> port 0xe800-0xe83f mem
> 0xfbf00000-0xfbf00fff,0xfbe00000-0xfbe1ffff irq 16 at device 5.0 on pci2
> miibus3: <MII bus> on fxp1
> inphy1: <i82555 10/100 media interface> PHY 1 on miibus3
> inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> fxp1: Ethernet address: 00:02:b3:b8:e5:80
> fxp1: [ITHREAD]
From pyunyh at gmail.com  Sun Mar  8 18:00:53 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Mar  8 18:01:02 2009
Subject: vge0 not autonegotiating to 1000baseTX full duplex in 7.1
In-Reply-To: <49B45E92.1080607@gmail.com>
References: <49B355FA.2090906@gmail.com>
	<20090308081550.GC1531@michelle.cdnetworks.co.kr>
	<49B45E92.1080607@gmail.com>
Message-ID: <20090309005857.GE5039@michelle.cdnetworks.co.kr>

On Sun, Mar 08, 2009 at 05:10:58PM -0700, David Ehrmann wrote:
> Pyun YongHyeon wrote:
> >On Sat, Mar 07, 2009 at 09:22:02PM -0800, David Ehrmann wrote:
> >  
> >>It's been reported before, but I haven't seen anything new.  vge devices 
> >>    
> >
> >Because I don't have access to the hardware it looks like hard to
> >fix.
> >
> >  
> >>won't autonegotiate to gigabit speeds, and if I set the media to 
> >>1000baseTX, ifconfig reports "no carrier."  This was with two different 
> >>interfaces on the other end, one a switch, the other another computer 
> >>(but not a vge one).
> >>
> >>Any ideas?
> >>    
> >
> >Would you show me the output of dmesg?(Only vge(4) related one)
> >Also show me the output of "devinfo -rv | grep phy".
> >  
> 
> dmesg:
> 
> vge0: <VIA Networking Gigabit Ethernet> port 0xe800-0xe8ff mem 
> 0xfeaffc00-0xfeaf
> fcff irq 28 at device 0.0 on pci3
> vge0: Reserved 0x100 bytes for rid 0x14 type 3 at 0xfeaffc00
> miibus0: <MII bus> on vge0
> ip1000phy0: <IC Plus IP1001 10/100/1000 media interface> PHY 22 on miibus0
> ip1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 
> 1000bas
> eTX-FDX, auto
> vge0: WARNING: using obsoleted if_watchdog interface
> vge0: bpf attached
> vge0: Ethernet address: 00:40:63:xx:xx:xx
> ioapic1: routing intpin 4 (PCI IRQ 28) to vector 49
> vge0: [MPSAFE]
> vge0: [ITHREAD]
> 
> 
> devinfo -rv | grep phy
>                ip1000phy0 pnpinfo oui=0x90c3 model=0x19 rev=0x0 at phyno=22
>            ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1
> 

Would you try attached patch? Due to lack of hardware access I
don't know whether it helps or not(Just compilation tested).
-------------- next part --------------
Index: sys/dev/mii/ip1000phy.c
===================================================================
--- sys/dev/mii/ip1000phy.c	(revision 189548)
+++ sys/dev/mii/ip1000phy.c	(working copy)
@@ -118,7 +118,6 @@
 	sc->mii_phy = ma->mii_phyno;
 	sc->mii_service = ip1000phy_service;
 	sc->mii_pdata = mii;
-	sc->mii_anegticks = MII_ANEGTICKS_GIGE;
 	sc->mii_flags |= MIIF_NOISOLATE;
 
 	mii->mii_instance++;
@@ -126,37 +125,14 @@
 	isc->model = MII_MODEL(ma->mii_id2);
 	isc->revision = MII_REV(ma->mii_id2);
 
+	sc->mii_capabilities = PHY_READ(sc, MII_BMSR) & ma->mii_capmask;
+	if (sc->mii_capabilities & BMSR_EXTSTAT)
+		sc->mii_extcapabilities = PHY_READ(sc, MII_EXTSR);
 	device_printf(dev, " ");
 
-#define	ADD(m, c)	ifmedia_add(&mii->mii_media, (m), (c), NULL)
-
-	ADD(IFM_MAKEWORD(IFM_ETHER, IFM_NONE, 0, sc->mii_inst),
-	    BMCR_ISO);
-
-	ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, 0, sc->mii_inst),
-	    IP1000PHY_BMCR_10);
-	printf("10baseT, ");
-	ADD(IFM_MAKEWORD(IFM_ETHER, IFM_10_T, IFM_FDX, sc->mii_inst),
-	    IP1000PHY_BMCR_10 | IP1000PHY_BMCR_FDX);
-	printf("10baseT-FDX, ");
-	ADD(IFM_MAKEWORD(IFM_ETHER, IFM_100_TX, 0, sc->mii_inst),
-	    IP1000PHY_BMCR_100);
-	printf("100baseTX, ");
-	ADD(IFM_MAKEWORD(IFM_ETHER, IFM_100_TX, IFM_FDX, sc->mii_inst),
-	    IP1000PHY_BMCR_100 | IP1000PHY_BMCR_FDX);
-	printf("100baseTX-FDX, ");
-	/* 1000baseT half-duplex, really supported? */
-	ADD(IFM_MAKEWORD(IFM_ETHER, IFM_1000_T, 0, sc->mii_inst),
-	    IP1000PHY_BMCR_1000);
-	printf("1000baseTX, ");
-	ADD(IFM_MAKEWORD(IFM_ETHER, IFM_1000_T, IFM_FDX, sc->mii_inst),
-	    IP1000PHY_BMCR_1000 | IP1000PHY_BMCR_FDX);
-	printf("1000baseTX-FDX, ");
-	ADD(IFM_MAKEWORD(IFM_ETHER, IFM_AUTO, 0, sc->mii_inst), 0);
-	printf("auto\n");
-#undef ADD
-
 	ip1000phy_reset(sc);
+	mii_phy_add_media(sc);
+	printf("\n");
 
 	MIIBUS_MEDIAINIT(sc->mii_dev);
 	return(0);
@@ -296,7 +272,7 @@
 		 * Only retry autonegotiation every mii_anegticks seconds.
 		 */
 		if (sc->mii_ticks <= sc->mii_anegticks)
-			return (0);
+			break;
 
 		sc->mii_ticks = 0;
 		ip1000phy_mii_phy_auto(sc);
@@ -353,6 +329,9 @@
 		case IP1000PHY_LSR_SPEED_1000:
 			mii->mii_media_active |= IFM_1000_T;
 			break;
+		default:
+			mii->mii_media_active |= IFM_NONE;
+			return;
 		}
 		if ((stat & IP1000PHY_LSR_FULL_DUPLEX) != 0)
 			mii->mii_media_active |= IFM_FDX;
@@ -373,6 +352,9 @@
 		case PC_LinkSpeed_1000:
 			mii->mii_media_active |= IFM_1000_T;
 			break;
+		default:
+			mii->mii_media_active |= IFM_NONE;
+			return;
 		}
 		if ((stat & PC_PhyDuplexStatus) != 0)
 			mii->mii_media_active |= IFM_FDX;
@@ -409,18 +391,24 @@
 }
 
 static int
-ip1000phy_mii_phy_auto(struct mii_softc *mii)
+ip1000phy_mii_phy_auto(struct mii_softc *sc)
 {
+	struct ip1000phy_softc *isc;
 	uint32_t reg;
 
-	PHY_WRITE(mii, IP1000PHY_MII_ANAR,
-	    IP1000PHY_ANAR_10T | IP1000PHY_ANAR_10T_FDX |
+	isc = (struct ip1000phy_softc *)sc;
+	reg = 0;
+	if (isc->model == MII_MODEL_ICPLUS_IP1001)
+		reg = PHY_READ(sc, IP1000PHY_MII_ANAR);
+	reg |= IP1000PHY_ANAR_10T | IP1000PHY_ANAR_10T_FDX |
 	    IP1000PHY_ANAR_100TX | IP1000PHY_ANAR_100TX_FDX |
-	    IP1000PHY_ANAR_PAUSE | IP1000PHY_ANAR_APAUSE);
+	    IP1000PHY_ANAR_PAUSE | IP1000PHY_ANAR_APAUSE;
+	PHY_WRITE(sc, IP1000PHY_MII_ANAR, reg | IP1000PHY_ANAR_CSMA);
+
 	reg = IP1000PHY_1000CR_1000T | IP1000PHY_1000CR_1000T_FDX;
 	reg |= IP1000PHY_1000CR_MASTER;
-	PHY_WRITE(mii, IP1000PHY_MII_1000CR, reg);
-	PHY_WRITE(mii, IP1000PHY_MII_BMCR, (IP1000PHY_BMCR_FDX |
+	PHY_WRITE(sc, IP1000PHY_MII_1000CR, reg);
+	PHY_WRITE(sc, IP1000PHY_MII_BMCR, (IP1000PHY_BMCR_FDX |
 	    IP1000PHY_BMCR_AUTOEN | IP1000PHY_BMCR_STARTNEG));
 
 	return (EJUSTRETURN);
Index: sys/dev/mii/ip1000phyreg.h
===================================================================
--- sys/dev/mii/ip1000phyreg.h	(revision 189548)
+++ sys/dev/mii/ip1000phyreg.h	(working copy)
@@ -61,6 +61,7 @@
 
 /* Autonegotiation advertisement register */
 #define	IP1000PHY_MII_ANAR		0x04
+#define	IP1000PHY_ANAR_CSMA		0x0001
 #define	IP1000PHY_ANAR_10T		0x0020
 #define	IP1000PHY_ANAR_10T_FDX		0x0040
 #define	IP1000PHY_ANAR_100TX		0x0080
From STEVE at stevenwills.com  Sun Mar  8 18:52:28 2009
From: STEVE at stevenwills.com (Steve Wills)
Date: Sun Mar  8 18:52:41 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <20090303120734.GB84434@michelle.cdnetworks.co.kr>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
	<20090226041023.GD63173@michelle.cdnetworks.co.kr>
	<594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com>
	<20090226042732.GE63173@michelle.cdnetworks.co.kr>
	<22F5A82D-290D-4B84-92AB-670EDB49AF22@stevenwills.com>
	<20090303120734.GB84434@michelle.cdnetworks.co.kr>
Message-ID: <26A74AAD-1556-4BA7-8E89-72BE36C667A7@stevenwills.com>

Hi,

Sorry for the late reply.

On Mar 3, 2009, at 7:07 AM, Pyun YongHyeon wrote:
> Ok, when you plug UTP cable can you see "re0: link state changed to
> UP" in dmesg output? Or if you unplug the cable, you should see
> "re0: link state changed to DOWN"(With "tail -f /var/log/message",
> you can easily check this.)

Nope.

>
> If this is not the case something is wrong on RTL8168D. Since
> you've said re0 works for a short time, can you see "re0: link
> state changed to DOWN" on your dmesg output right before seeing
> "re0: PHY read failed" message?

After boot and DHCP, it works for about a minute, then I see "PHY read  
failed" for a few seconds, network continues to work, then I see "link  
state changed to DOWN", network stops working and frequency of read  
failed message increases. Unplugging the cable and plugging it back in  
doesn't change anything or cause the system to log any messages beyond  
"PHY read failed".

> I've also attached patch which may apply to your case. Would you
> give it spin? Note, the patch was generated against CURRENT, so
> you should use re(4) in CURRENT. Just save your old re(4)/rl(4)
> files and download if_re.c, if_rl.c and if_rlreg.h from CURRENT
> and apply the patch.
> <re.RTL8168D.patch>

Unfortunately, for me, this patch doesn't change things.

Thanks,
Steve

From pyunyh at gmail.com  Sun Mar  8 20:58:06 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Mar  8 20:58:15 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <26A74AAD-1556-4BA7-8E89-72BE36C667A7@stevenwills.com>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
	<20090226041023.GD63173@michelle.cdnetworks.co.kr>
	<594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com>
	<20090226042732.GE63173@michelle.cdnetworks.co.kr>
	<22F5A82D-290D-4B84-92AB-670EDB49AF22@stevenwills.com>
	<20090303120734.GB84434@michelle.cdnetworks.co.kr>
	<26A74AAD-1556-4BA7-8E89-72BE36C667A7@stevenwills.com>
Message-ID: <20090309035613.GF5039@michelle.cdnetworks.co.kr>

On Sun, Mar 08, 2009 at 09:52:19PM -0400, Steve Wills wrote:
> Hi,
> 
> Sorry for the late reply.
> 
> On Mar 3, 2009, at 7:07 AM, Pyun YongHyeon wrote:
> >Ok, when you plug UTP cable can you see "re0: link state changed to
> >UP" in dmesg output? Or if you unplug the cable, you should see
> >"re0: link state changed to DOWN"(With "tail -f /var/log/message",
> >you can easily check this.)
> 
> Nope.
> 
> >
> >If this is not the case something is wrong on RTL8168D. Since
> >you've said re0 works for a short time, can you see "re0: link
> >state changed to DOWN" on your dmesg output right before seeing
> >"re0: PHY read failed" message?
> 
> After boot and DHCP, it works for about a minute, then I see "PHY read  
> failed" for a few seconds, network continues to work, then I see "link  
> state changed to DOWN", network stops working and frequency of read  
> failed message increases. Unplugging the cable and plugging it back in  
> doesn't change anything or cause the system to log any messages beyond  
> "PHY read failed".
> 
> >I've also attached patch which may apply to your case. Would you
> >give it spin? Note, the patch was generated against CURRENT, so
> >you should use re(4) in CURRENT. Just save your old re(4)/rl(4)
> >files and download if_re.c, if_rl.c and if_rlreg.h from CURRENT
> >and apply the patch.
> ><re.RTL8168D.patch>
> 
> Unfortunately, for me, this patch doesn't change things.
> 

Ok, please try again with attached patch.
-------------- next part --------------
Index: sys/dev/re/if_re.c
===================================================================
--- sys/dev/re/if_re.c	(revision 189551)
+++ sys/dev/re/if_re.c	(working copy)
@@ -1266,6 +1266,8 @@
 		/* FALLTHROUGH */
 	case RL_HWREV_8168CP:
 	case RL_HWREV_8168D:
+		if (hw_rev->rl_rev == RL_HWREV_8168D)
+			sc->rl_flags |= 0x10000;
 		sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
 		    RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP;
 		/*
@@ -2061,6 +2063,8 @@
 
 	RL_LOCK_ASSERT(sc);
 
+	if ((sc->rl_flags & 0x10000) != 0)
+		re_miibus_writereg(sc->rl_dev, 1, 0x1f, 0);
 	mii = device_get_softc(sc->rl_miibus);
 	mii_tick(mii);
 	if ((sc->rl_flags & RL_FLAG_LINK) == 0)
From g.stone-tolcher at its.uq.edu.au  Sun Mar  8 22:02:10 2009
From: g.stone-tolcher at its.uq.edu.au (Gavin Stone-Tolcher)
Date: Sun Mar  8 22:02:44 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090308023642.GB1531@michelle.cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com><200901191833.51320.jkim@FreeBSD.org><20090120024519.GB79785@cdnetworks.co.kr><200903071717.57915.ianjhart@ntlworld.com>
	<20090308023642.GB1531@michelle.cdnetworks.co.kr>
Message-ID: <93D48C8BEA0F954FA6569C8A853EF79C02CE62E0@UQEXMB1.soe.uq.edu.au>

> Have you tried re(4) in HEAD?
> I had one report that re(4) in HEAD still does not fix the issue so
> I posted a possible workaround for that. Unfortunately he didn't
> report back so I don't know whether it was right workaround or not. 
> If re(4) in HEAD does not fix the issue, would you try attached
> patch and let me know how it goes?

Hi, Just some more feedback on your patch.
I have a Jetway J7F4K1G2E board with dual embedded 
RealteK RTL8110SC. I tried using the 19 January 2009 jkim 
patches:

> > >  > http://people.freebsd.org/~jkim/re/re.stable2.diff

And also tried using what I believe are same changes he made
to HEAD via if_re.c, if_rl.c and if_rlreg.h(187483), and
still had issues with the controllers at system startup.

I have been using your patch above originally proffered on 
Feb 13 since Feb 18 and the system has been working fine 
since then. 

controllers:

re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10
hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
    class      = network
    subclass   = ethernet
re1@pci0:0:11:0:        class=0x020000 card=0x10ec16f3 chip=0x816710ec
rev=0x10 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8169/8110 Family Gigabit Ethernet NIC'
    class      = network
    subclass   = ethernet

re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
0xf000-0xf0ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0
re0: Chip rev. 0x18000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
re0: Ethernet address: 00:30:18:a6:26:ff
re0: [FILTER]

re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
0xf200-0xf2ff mem 0xfdffe000-0xfdffe0ff irq 19 at device 11.0 on pci0
re1: Chip rev. 0x18000000
re1: MAC rev. 0x00000000
miibus1: <MII bus> on re1
rgephy1: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus1
rgephy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
re1: Ethernet address: 00:30:18:a6:27:00
re1: [FILTER]


Cheers,
Gavin Stone-Tolcher                    g.stone-tolcher@its.uq.edu.au
Incident Response Team               Information Technology Services
The University of Queensland                  Phone: +61 7 336 54407
Queensland 4072    AUSTRALIA                    Fax,: +61 7 336 57539
From pyunyh at gmail.com  Sun Mar  8 23:05:39 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Mar  8 23:05:46 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <93D48C8BEA0F954FA6569C8A853EF79C02CE62E0@UQEXMB1.soe.uq.edu.au>
References: <20090308023642.GB1531@michelle.cdnetworks.co.kr>
	<93D48C8BEA0F954FA6569C8A853EF79C02CE62E0@UQEXMB1.soe.uq.edu.au>
Message-ID: <20090309060346.GG5039@michelle.cdnetworks.co.kr>

On Mon, Mar 09, 2009 at 02:51:41PM +1000, Gavin Stone-Tolcher wrote:
> > Have you tried re(4) in HEAD?
> > I had one report that re(4) in HEAD still does not fix the issue so
> > I posted a possible workaround for that. Unfortunately he didn't
> > report back so I don't know whether it was right workaround or not. 
> > If re(4) in HEAD does not fix the issue, would you try attached
> > patch and let me know how it goes?
> 
> Hi, Just some more feedback on your patch.
> I have a Jetway J7F4K1G2E board with dual embedded 
> RealteK RTL8110SC. I tried using the 19 January 2009 jkim 
> patches:
> 
> > > >  > http://people.freebsd.org/~jkim/re/re.stable2.diff
> 
> And also tried using what I believe are same changes he made
> to HEAD via if_re.c, if_rl.c and if_rlreg.h(187483), and
> still had issues with the controllers at system startup.
> 
> I have been using your patch above originally proffered on 
> Feb 13 since Feb 18 and the system has been working fine 
> since then. 
> 

Thanks a lot! This is the report I had been waiting for. I've
committed the patch to HEAD(r189555).
From pyunyh at gmail.com  Sun Mar  8 23:10:33 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Mar  8 23:10:53 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <200903081705.12523.ianjhart@ntlworld.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<200903071717.57915.ianjhart@ntlworld.com>
	<20090308023642.GB1531@michelle.cdnetworks.co.kr>
	<200903081705.12523.ianjhart@ntlworld.com>
Message-ID: <20090309060841.GH5039@michelle.cdnetworks.co.kr>

On Sun, Mar 08, 2009 at 05:05:12PM +0000, ian j hart wrote:
> On Sunday 08 March 2009 02:36:42 Pyun YongHyeon wrote:
> > On Sat, Mar 07, 2009 at 05:17:57PM +0000, ian j hart wrote:
> > > On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote:
> > > > On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote:
> > > >  > On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote:
> > > >  > > I found something interesting.  I have another RTL8169SC that
> > > >  > > works perfectly fine without the patch.  The hardware revision is
> > > >  > > 0x18000000.  After reading Linux driver (drivers/net/r8169c), I
> > > >  > > realised they use different masks for hardware revisions.  With
> > > >  > > their logic, non-working chip seems to be 0x98000000 (8110SCe)
> > > >  > > while working chip seems to be 0x18000000 (8110SCd) with
> > > >  > > 0xfc800000. FYI...
> > > >  >
> > > >  > Now armed with the information, I made it work without reverting
> > > >  > memory mapped I/O. :-)
> > > >  >
> > > >  > http://people.freebsd.org/~jkim/re/re.current2.diff
> > > >  > http://people.freebsd.org/~jkim/re/re.stable2.diff
> > > >
> > > > I like the patch. Since only RTL8169 family uses mask 0xfc800000
> > > > it would be even better we can limit checking scope for RTL8169SC
> > > > by comparing PCI device id. I don't know what other side effect
> > > > would happen if the mask 0xfc800000 would be used on 8101/8168
> > > > controllers.
> > > > If the patch works on RTL8169SC would you commit the patch?
> > > > I'd like to see multiple commits separated by each enhancements
> > > > as the patch contains several fixes which are not directly related
> > > > with the issue.
> > >
> > > Where are we on this?
> > >
> > > I have a headless firewall box which is not happy with 7.1-RELEASE. I've
> > > upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY read
> > > failed' errors, although the network did come up, which was an
> > > improvement.
> > >
> > > Is there a patch I can try?
> > >
> > > http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174&proname=AD3RT
> > >LAN-G
> > >
> > > re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > > 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0 re0:
> > > Chip rev. 0x18000000
> > > re0: MAC rev. 0x00000000
> > > re0: Ethernet address: 00:30:18:ae:1a:1b
> > > re0: [FILTER]
> > > re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > > 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0
> > > re1: Chip rev. 0x18000000
> > > re1: MAC rev. 0x00000000
> > > re1: Ethernet address: 00:30:18:ae:1a:1c
> > > re1: [FILTER]
> > > re2: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > > 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0
> > > re2: Chip rev. 0x18000000
> > > re2: MAC rev. 0x00000000
> > > re2: Ethernet address: 00:30:18:ae:1a:1d
> > > re2: [FILTER]
> > >
> > > re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10
> > > hdr=0x00 re1@pci0:0:11:0:        class=0x020000 card=0x10ec16f3
> > > chip=0x816710ec rev=0x10 hdr=0x00 re2@pci0:0:12:0:        class=0x020000
> > > card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00
> >
> > Have you tried re(4) in HEAD?
> > I had one report that re(4) in HEAD still does not fix the issue so
> > I posted a possible workaround for that. Unfortunately he didn't
> > report back so I don't know whether it was right workaround or not.
> > If re(4) in HEAD does not fix the issue, would you try attached
> > patch and let me know how it goes?
> 
> Firstly IANAKH, my expertise in this area stops after "make kernel".
> 
> I updated
> 
> /usr/src/sys/dev/re/if_re.c
> /usr/src/sys/pci/if_rlreg.h
> 
> to HEAD
> 

And after updating to HEAD did you apply my patch?

> I still get "PHY read failed" with and without the patch.
> 

That's odd. Another user who has the same controller reports the
fix fixed the issue. I also committed the patch to HEAD so would
you give it spin again (without applying any patches)?
From cliftonr at lava.net  Sun Mar  8 23:41:48 2009
From: cliftonr at lava.net (Clifton Royston)
Date: Sun Mar  8 23:41:56 2009
Subject: re/rl for 6-STABLE (Was Re: FreeBSD 7.1 Breaks re and rl Network
	Interface Drivers)
In-Reply-To: <20090309060346.GG5039@michelle.cdnetworks.co.kr>
References: <20090308023642.GB1531@michelle.cdnetworks.co.kr>
	<93D48C8BEA0F954FA6569C8A853EF79C02CE62E0@UQEXMB1.soe.uq.edu.au>
	<20090309060346.GG5039@michelle.cdnetworks.co.kr>
Message-ID: <20090309064144.GA18180@lava.net>

On Mon, Mar 09, 2009 at 03:03:46PM +0900, Pyun YongHyeon wrote:
...
> Thanks a lot! This is the report I had been waiting for. I've
> committed the patch to HEAD(r189555).

  As long as you're thinking about the re/rl driver, I have been
meaning to report to you that the patch you've posted for 6-STABLE
has been working fine on 6.4-RELEASE with a Gigabyte motherboard using
an onboard RTL8168 Gigabit Ethernet chip.

  It was unidentified with 6.4-RELEASE, but after I applied the patches
I found described at 
  http://people.freebsd.org/~yongari/re/6.x/README 
and rebuilt the kernel, it was detected and worked properly.  (I don't
have a Gigabit switch, so I'm only running at 100baseTX at present.)

  -- Clifton

uname -v:
FreeBSD 6.4-RELEASE #0: Thu Mar  5 21:32:53 HST 2009 root@oz.volcano.org:/var/tmp/usr.obj/usr/src/sys/SMP

dmesg output:
...
re0: <RealTek 8168/8168B/8168C/8168CP/8111B/8111C/8111CP PCIe Gigabit Ethernet>
port 0xd000-0xd0ff mem 0xe1110000-0xe1110fff,0xe1100000-0xe110ffff irq 17 at dev ice 0.0 on pci2
re0: Chip rev. 0x3c000000
re0: MAC rev. 0x00400000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

pciconf -lv output:
...
re0@pci2:0:0:   class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
    class      = network
    subclass   = ethernet

ifconfig output:
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
        inet x.y.z.w ...
        inet x.y.z.v ...
        ether 00:1f:d0:cd:3c:9c
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

-- 
    Clifton Royston  --  cliftonr@iandicomputing.com / cliftonr@lava.net
       President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
From ehrmann at gmail.com  Sun Mar  8 23:57:28 2009
From: ehrmann at gmail.com (David Ehrmann)
Date: Sun Mar  8 23:57:35 2009
Subject: vge0 not autonegotiating to 1000baseTX full duplex in 7.1
In-Reply-To: <20090309005857.GE5039@michelle.cdnetworks.co.kr>
References: <49B355FA.2090906@gmail.com>
	<20090308081550.GC1531@michelle.cdnetworks.co.kr>
	<49B45E92.1080607@gmail.com>
	<20090309005857.GE5039@michelle.cdnetworks.co.kr>
Message-ID: <49B4BDA9.302@gmail.com>

Pyun YongHyeon wrote:
> On Sun, Mar 08, 2009 at 05:10:58PM -0700, David Ehrmann wrote:
>   
>> Pyun YongHyeon wrote:
>>     
>>> On Sat, Mar 07, 2009 at 09:22:02PM -0800, David Ehrmann wrote:
>>>  
>>>       
>>>> It's been reported before, but I haven't seen anything new.  vge devices 
>>>>    
>>>>         
>>> Because I don't have access to the hardware it looks like hard to
>>> fix.
>>>
>>>  
>>>       
>>>> won't autonegotiate to gigabit speeds, and if I set the media to 
>>>> 1000baseTX, ifconfig reports "no carrier."  This was with two different 
>>>> interfaces on the other end, one a switch, the other another computer 
>>>> (but not a vge one).
>>>>
>>>> Any ideas?
>>>>    
>>>>         
>>> Would you show me the output of dmesg?(Only vge(4) related one)
>>> Also show me the output of "devinfo -rv | grep phy".
>>>  
>>>       
>> dmesg:
>>
>> vge0: <VIA Networking Gigabit Ethernet> port 0xe800-0xe8ff mem 
>> 0xfeaffc00-0xfeaf
>> fcff irq 28 at device 0.0 on pci3
>> vge0: Reserved 0x100 bytes for rid 0x14 type 3 at 0xfeaffc00
>> miibus0: <MII bus> on vge0
>> ip1000phy0: <IC Plus IP1001 10/100/1000 media interface> PHY 22 on miibus0
>> ip1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 
>> 1000bas
>> eTX-FDX, auto
>> vge0: WARNING: using obsoleted if_watchdog interface
>> vge0: bpf attached
>> vge0: Ethernet address: 00:40:63:xx:xx:xx
>> ioapic1: routing intpin 4 (PCI IRQ 28) to vector 49
>> vge0: [MPSAFE]
>> vge0: [ITHREAD]
>>
>>
>> devinfo -rv | grep phy
>>                ip1000phy0 pnpinfo oui=0x90c3 model=0x19 rev=0x0 at phyno=22
>>            ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1
>>
>>     
>
> Would you try attached patch? Due to lack of hardware access I
> don't know whether it helps or not(Just compilation tested).
>   
I have no idea how you did it, but the patch seems to have worked.  
ifconfig reports 1000baseTX, and I can nc zeros at more than 50 MB/s.

Is this patch "stable?"  Should it break any existing functionality?  
What was the problem that it fixed?  Will it be in the next 7.x 
release?  8.0?

Here's the link to the bug id for it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=130846

Thank you!
From pyunyh at gmail.com  Sun Mar  8 23:59:04 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Mar  8 23:59:12 2009
Subject: re/rl for 6-STABLE (Was Re: FreeBSD 7.1 Breaks re and rl
	Network Interface Drivers)
In-Reply-To: <20090309064144.GA18180@lava.net>
References: <20090308023642.GB1531@michelle.cdnetworks.co.kr>
	<93D48C8BEA0F954FA6569C8A853EF79C02CE62E0@UQEXMB1.soe.uq.edu.au>
	<20090309060346.GG5039@michelle.cdnetworks.co.kr>
	<20090309064144.GA18180@lava.net>
Message-ID: <20090309065713.GI5039@michelle.cdnetworks.co.kr>

On Sun, Mar 08, 2009 at 08:41:45PM -1000, Clifton Royston wrote:
> On Mon, Mar 09, 2009 at 03:03:46PM +0900, Pyun YongHyeon wrote:
> ...
> > Thanks a lot! This is the report I had been waiting for. I've
> > committed the patch to HEAD(r189555).
> 
>   As long as you're thinking about the re/rl driver, I have been
> meaning to report to you that the patch you've posted for 6-STABLE
> has been working fine on 6.4-RELEASE with a Gigabyte motherboard using
> an onboard RTL8168 Gigabit Ethernet chip.
> 
>   It was unidentified with 6.4-RELEASE, but after I applied the patches
> I found described at 
>   http://people.freebsd.org/~yongari/re/6.x/README 
> and rebuilt the kernel, it was detected and worked properly.  (I don't
> have a Gigabit switch, so I'm only running at 100baseTX at present.)
> 

Thanks for reporting/testing! Unfortunately I don't have 6.x box
anymore so it's somewhat hard to maintain re(4)/rl(4) for 6-stable.
The files in 6.x directory were posted when an user eagerly wanted
to use his unrecognized controller at that time.

>   -- Clifton
> 
> uname -v:
> FreeBSD 6.4-RELEASE #0: Thu Mar  5 21:32:53 HST 2009 root@oz.volcano.org:/var/tmp/usr.obj/usr/src/sys/SMP
> 
> dmesg output:
> ...
> re0: <RealTek 8168/8168B/8168C/8168CP/8111B/8111C/8111CP PCIe Gigabit Ethernet>
> port 0xd000-0xd0ff mem 0xe1110000-0xe1110fff,0xe1100000-0xe110ffff irq 17 at dev ice 0.0 on pci2
> re0: Chip rev. 0x3c000000
> re0: MAC rev. 0x00400000
> miibus0: <MII bus> on re0
> rgephy0: <RTL8169S/8110S/8211B media interface> on miibus0
> rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
> 
> pciconf -lv output:
> ...
> re0@pci2:0:0:   class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x02 hdr=0x00
>     vendor     = 'Realtek Semiconductor'
>     device     = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC'
>     class      = network
>     subclass   = ethernet
> 
> ifconfig output:
> re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
>         inet x.y.z.w ...
>         inet x.y.z.v ...
>         ether 00:1f:d0:cd:3c:9c
>         media: Ethernet autoselect (100baseTX <full-duplex>)
>         status: active
From pyunyh at gmail.com  Mon Mar  9 00:13:01 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Mon Mar  9 00:13:35 2009
Subject: vge0 not autonegotiating to 1000baseTX full duplex in 7.1
In-Reply-To: <49B4BDA9.302@gmail.com>
References: <49B355FA.2090906@gmail.com>
	<20090308081550.GC1531@michelle.cdnetworks.co.kr>
	<49B45E92.1080607@gmail.com>
	<20090309005857.GE5039@michelle.cdnetworks.co.kr>
	<49B4BDA9.302@gmail.com>
Message-ID: <20090309071110.GJ5039@michelle.cdnetworks.co.kr>

On Sun, Mar 08, 2009 at 11:56:41PM -0700, David Ehrmann wrote:
> Pyun YongHyeon wrote:
> >On Sun, Mar 08, 2009 at 05:10:58PM -0700, David Ehrmann wrote:
> >  
> >>Pyun YongHyeon wrote:
> >>    
> >>>On Sat, Mar 07, 2009 at 09:22:02PM -0800, David Ehrmann wrote:
> >>> 
> >>>      
> >>>>It's been reported before, but I haven't seen anything new.  vge 
> >>>>devices 
> >>>>        
> >>>Because I don't have access to the hardware it looks like hard to
> >>>fix.
> >>>
> >>> 
> >>>      
> >>>>won't autonegotiate to gigabit speeds, and if I set the media to 
> >>>>1000baseTX, ifconfig reports "no carrier."  This was with two different 
> >>>>interfaces on the other end, one a switch, the other another computer 
> >>>>(but not a vge one).
> >>>>
> >>>>Any ideas?
> >>>>   
> >>>>        
> >>>Would you show me the output of dmesg?(Only vge(4) related one)
> >>>Also show me the output of "devinfo -rv | grep phy".
> >>> 
> >>>      
> >>dmesg:
> >>
> >>vge0: <VIA Networking Gigabit Ethernet> port 0xe800-0xe8ff mem 
> >>0xfeaffc00-0xfeaf
> >>fcff irq 28 at device 0.0 on pci3
> >>vge0: Reserved 0x100 bytes for rid 0x14 type 3 at 0xfeaffc00
> >>miibus0: <MII bus> on vge0
> >>ip1000phy0: <IC Plus IP1001 10/100/1000 media interface> PHY 22 on miibus0
> >>ip1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 
> >>1000bas
> >>eTX-FDX, auto
> >>vge0: WARNING: using obsoleted if_watchdog interface
> >>vge0: bpf attached
> >>vge0: Ethernet address: 00:40:63:xx:xx:xx
> >>ioapic1: routing intpin 4 (PCI IRQ 28) to vector 49
> >>vge0: [MPSAFE]
> >>vge0: [ITHREAD]
> >>
> >>
> >>devinfo -rv | grep phy
> >>               ip1000phy0 pnpinfo oui=0x90c3 model=0x19 rev=0x0 at 
> >>               phyno=22
> >>           ukphy0 pnpinfo oui=0x4063 model=0x32 rev=0xa at phyno=1
> >>
> >>    
> >
> >Would you try attached patch? Due to lack of hardware access I
> >don't know whether it helps or not(Just compilation tested).
> >  
> I have no idea how you did it,

Hmm... it was just a guess and this time I was lucky. :-)

>                                but the patch seems to have worked.  

Glad to hear that.

> ifconfig reports 1000baseTX, and I can nc zeros at more than 50 MB/s.
> 
> Is this patch "stable?"  Should it break any existing functionality?  

As you might guess, only you can say "how stable" for this patch. 

> What was the problem that it fixed?  Will it be in the next 7.x 

I guess newer IC Plus PHYs require correct next page bit so I
just read the autonegotiation advertisement register to cache the
next page capability. All other changes are to use
mii_phy_add_media() KPI which will remove duplicated codes in phy
drivers.

> release?  8.0?
> 

Yes, I'll commit the patch soon and make sure to MFC to 7-stable.

> Here's the link to the bug id for it:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=130846
> 

Ok, I'll handle the PR.

> Thank you!

No problem. Thanks for testing!
From gerrit at pmp.uni-hannover.de  Mon Mar  9 01:21:35 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Mon Mar  9 01:21:43 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090308023642.GB1531@michelle.cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<200901191833.51320.jkim@FreeBSD.org>
	<20090120024519.GB79785@cdnetworks.co.kr>
	<200903071717.57915.ianjhart@ntlworld.com>
	<20090308023642.GB1531@michelle.cdnetworks.co.kr>
Message-ID: <20090309092131.790f719d.gerrit@pmp.uni-hannover.de>

On Sun, 8 Mar 2009 11:36:42 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
about Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers:

PY> Have you tried re(4) in HEAD?
PY> I had one report that re(4) in HEAD still does not fix the issue so
PY> I posted a possible workaround for that. Unfortunately he didn't
PY> report back so I don't know whether it was right workaround or not. 
PY> If re(4) in HEAD does not fix the issue, would you try attached
PY> patch and let me know how it goes?

Are you talking about me? ;-)
I put the first system with the patched patch to work last week. It
definitely fixes the problems I had with the first patch (HEAD, I
suppose), as the interface attaches fine now (even a lot faster than
before).
I cannot say if the actual issue I had with 7.1-stable has gone away, too,
because this only occured after a longer time of operation. However, up to
now everything looks nice.


cu
  Gerrit
From gerrit at pmp.uni-hannover.de  Mon Mar  9 01:25:30 2009
From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=)
Date: Mon Mar  9 01:25:37 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <93D48C8BEA0F954FA6569C8A853EF79C02CE62E0@UQEXMB1.soe.uq.edu.au>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<200901191833.51320.jkim@FreeBSD.org>
	<20090120024519.GB79785@cdnetworks.co.kr>
	<200903071717.57915.ianjhart@ntlworld.com>
	<20090308023642.GB1531@michelle.cdnetworks.co.kr>
	<93D48C8BEA0F954FA6569C8A853EF79C02CE62E0@UQEXMB1.soe.uq.edu.au>
Message-ID: <20090309092526.769037ac.gerrit@pmp.uni-hannover.de>

On Mon, 9 Mar 2009 14:51:41 +1000 "Gavin Stone-Tolcher"
<g.stone-tolcher@its.uq.edu.au> wrote about RE: FreeBSD 7.1 Breaks re and
rl Network Interface Drivers:

GST> Hi, Just some more feedback on your patch.
GST> I have a Jetway J7F4K1G2E board with dual embedded 
GST> RealteK RTL8110SC. I tried using the 19 January 2009 jkim 
GST> patches:

And I just want to add that I am using the same mainboard series here (A,
D and E versions, I think).

GST> I have been using your patch above originally proffered on 
GST> Feb 13 since Feb 18 and the system has been working fine 
GST> since then. 

If that's the patch pyunyh posted here in answer to my issue (should have
been around the same time, my kernel is from Feb 13), that's the same I am
using here now (and it also works for me up to now).


cu
  Gerrit
From pyunyh at gmail.com  Mon Mar  9 01:34:58 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Mon Mar  9 01:35:05 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090309092131.790f719d.gerrit@pmp.uni-hannover.de>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<200901191833.51320.jkim@FreeBSD.org>
	<20090120024519.GB79785@cdnetworks.co.kr>
	<200903071717.57915.ianjhart@ntlworld.com>
	<20090308023642.GB1531@michelle.cdnetworks.co.kr>
	<20090309092131.790f719d.gerrit@pmp.uni-hannover.de>
Message-ID: <20090309083306.GL5039@michelle.cdnetworks.co.kr>

On Mon, Mar 09, 2009 at 09:21:31AM +0100, Gerrit K?hn wrote:
> On Sun, 8 Mar 2009 11:36:42 +0900 Pyun YongHyeon <pyunyh@gmail.com> wrote
> about Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers:
> 
> PY> Have you tried re(4) in HEAD?
> PY> I had one report that re(4) in HEAD still does not fix the issue so
> PY> I posted a possible workaround for that. Unfortunately he didn't
> PY> report back so I don't know whether it was right workaround or not. 
> PY> If re(4) in HEAD does not fix the issue, would you try attached
> PY> patch and let me know how it goes?
> 
> Are you talking about me? ;-)

If my memory serve me right, yes.

> I put the first system with the patched patch to work last week. It
> definitely fixes the problems I had with the first patch (HEAD, I
> suppose), as the interface attaches fine now (even a lot faster than
> before).
> I cannot say if the actual issue I had with 7.1-stable has gone away, too,
> because this only occured after a longer time of operation. However, up to
> now everything looks nice.
> 

Ok, if you find any re(4) instability feel free to contact me.
From spara at online.fr  Mon Mar  9 04:32:19 2009
From: spara at online.fr (spara)
Date: Mon Mar  9 04:32:29 2009
Subject: Page fault panic in scioctl and console-kit-daemon
Message-ID: <DB49F4B8-9E0E-4219-BB58-04F6644D10A5@online.fr>

Hello,
I'm experiencing the same (http://www.mail-archive.com/freebsd-stable@freebsd.org/msg101997.html 
) after updating to last hald in 6.4-STABLE.
Anyone tried to fix it with the Kostik Belousov patch as in http://lists.freebsd.org/pipermail/freebsd-current/2008-January/082581.html 
  ?
Any other fix ?

cheers
---------------original message-----------------
Hello everybody, I'm reporting a problem that looks _very_ similar to  
one reported on freebsd-current@ last year, by Pawel Worach: http://lists.freebsd.org/pipermail/freebsd-current/2008-January/082581.html 
  My system is a 6.4-STABLE, with up-to-date /usr/src and /usr/ports:  
$ uname -a FreeBSD diavoletto 6.4-STABLE FreeBSD 6.4-STABLE #19: Mon  
Feb 16 12:01:24 CET 2009 r...@diavoletto:/usr/obj/usr/src/sys/GENERIC  
i386 In /etc/rc.conf I have the following lines: > dbus_enable="YES" >  
hald_enable="YES" Every time dbus is started, if consolekit-0.3.0 is  
installed then a page fault occurs just after the login screen is  
shown. If I "make deinstall" the port in single-user-mode, then the  
system boots and works fine. If I boot with consolekit uninstalled,  
then install it and restart dbus, I get a panic. I'm reporting here  
the same information that Pawel Worach reported last year for his  
problem. Please tell me if I can provide any more information; this is  
my very first problem report here!  
----8 
<--------8<--------8<--------8<--------8<--------8<--------8<---------  
Script started on Fri Feb 20 12:47:10 2009 # cd /usr/obj/usr/src/sys/ 
GENERIC # kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1  
[FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free  
software, covered by the GNU General Public License, and you are  
welcome to change it and/or distribute copies of it under certain  
conditions. Type "show copying" to see the conditions. There is  
absolutely no warranty for GDB. Type "show warranty" for details. This  
GDB was configured as "i386-marcel-freebsd"... Unread portion of the  
kernel message buffer:   Fatal trap 12: page fault while in kernel  
mode fault virtual address = 0x4 fault code = supervisor read, page  
not present instruction pointer = 0x20:0xc09dfaef stack pointer =  
0x28:0xe85a8bf8 frame pointer = 0x28:0xe85a8c40 code segment = base  
0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1  
processor eflags = interrupt enabled, resume, IOPL = 0 current process  
= 14500 (console-kit-daemon) trap number = 12 panic: page fault  
Uptime: 30m41s Dumping 1471 MB (2 chunks) chunk 0: 1MB (155 pages) ...  
ok chunk 1: 1471MB (376496 pages) (CTRL-C to abort) 1455 1439 1423  
1407 (CTRL-C to abort) 1391 1375 1359 1343 1327 1311 1295 1279 1263  
1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039  
1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767  
751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495  
479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223  
207 191 175 159 143 127 111 95 79 63 47 31 15 Reading symbols from / 
boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko  
Reading symbols from /boot/kernel/snd_hda.ko...done. Loaded symbols  
for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/ 
sound.ko...done. Loaded symbols for /boot/kernel/sound.ko Reading  
symbols from /boot/kernel/acpi.ko...done. Loaded symbols for /boot/ 
kernel/acpi.ko Reading symbols from /usr/local/modules/fuse.ko...done.  
Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from / 
boot/kernel/green_saver.ko...done. Loaded symbols for /boot/kernel/ 
green_saver.ko #0 doadump () at pcpu.h:165 165 __asm __volatile("movl % 
%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:165  
#1 0xc072b274 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c: 
410 #2 0xc072b5a6 in panic (fmt=0xc0a66e6f "%s") at /usr/src/sys/kern/ 
kern_shutdown.c:566 #3 0xc0a02f2c in trap_fatal (frame=0xe85a8bb8,  
eva=0) at /usr/src/sys/i386/i386/trap.c:838 #4 0xc0a02c32 in  
trap_pfault (frame=0xe85a8bb8, usermode=0, eva=4) at /usr/src/sys/i386/ 
i386/trap.c:745 #5 0xc0a027e2 in trap (frame= {tf_fs = 8, tf_es = 40,  
tf_ds = 40, tf_edi = 9, tf_esi = -977926144, tf_ebp = -396719040,  
tf_isp = -396719132, tf_ebx = -1061927328, tf_edx = -978051584, tf_ecx  
= 2000, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1063388433,  
tf_cs = 32, tf_eflags = 66182, tf_esp = -978051584, tf_ss =  
-977926144}) at /usr/src/sys/i386/i386/trap.c:435 #6  0xc09ec99a in  
calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc09dfaef in  
scioctl (dev=0xc5b63200, cmd=9, data=0xe85a8cbc "\n", flag=1,  
td=0xc6416900) at /usr/src/sys/dev/syscons/syscons.c:1060 #8  
0xc06f489c in giant_ioctl (dev=0xc5b63200, cmd=0, data=0x0, fflag=0,  
td=0x0) at /usr/src/sys/kern/kern_conf.c:330 #9 0xc06c8f19 in  
devfs_ioctl_f (fp=0xc60fdc60, com=537163270, data=0xe85a8cbc,  
cred=0xc7845280, td=0xc6416900) at /usr/src/sys/fs/devfs/devfs_vnops.c: 
480 #10 0xc0755007 in ioctl (td=0xc6416900, uap=0xe85a8d04) at file.h: 
265 #11 0xc0a03302 in syscall (frame= ---Type <return> to continue, or  
q <return> to quit--- {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi =  
10, tf_esi = 134714152, tf_ebp = -1081716952, tf_isp = -396718748,  
tf_ebx = 134627884, tf_edx = 135049216, tf_ecx = -1, tf_eax = 54,  
tf_trapno = 12, tf_err = 2, tf_eip = 675581607, tf_cs = 51, tf_eflags  
= 642, tf_esp = -1081717012, tf_ss = 59}) at /usr/src/sys/i386/i386/ 
trap.c:984 #12 0xc09ec9ef in Xint0x80_syscall () at /usr/src/sys/i386/ 
i386/exception.s:200 #13 0x00000033 in ?? () Previous frame inner to  
this frame (corrupt stack?) (kgdb) frame 7 #7 0xc09dfaef in scioctl  
(dev=0xc5b63200, cmd=9, data=0xe85a8cbc "\n", flag=1, td=0xc6416900)  
at /usr/src/sys/dev/syscons/syscons.c:1060 1060 scp =  
sc_get_stat(SC_DEV(sc, i)); (kgdb) print sc $1 = (sc_softc_t *)  
0xc0ba20c0 (kgdb) print *sc $2 = {unit = 0, config = 768, flags =  
196608, keyboard = 1, kbd = 0xc59fc700, adapter = 0, adp = 0xc0b7e3a0,  
initial_mode = 24, first_vty = 0, vtys = 16, dev = 0xc0b9a440, cur_scp  
= 0xc0b9a300, new_scp = 0xc0b9a300, old_scp = 0xc0b9a300,  
delayed_next_scr = 0, font_loading_in_progress = 0 '\0',  
switch_in_progress = 0 '\0', videoio_in_progress = 0 '\0',  
write_in_progress = 0 '\0', blink_in_progress = 0 '\0',  
scrn_time_stamp = 1841, dflt_curs_attr = { flags = 0, base = 1, height  
= 2}, curs_attr = {flags = 0, base = 1, height = 2}, scr_map =  
"\000\001\002\003\004\005\006\a\b\t\n\v\f\r 
\016 
\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 ! 
\"#$%&'()*+,-./0123456789:;<=>?...@abcdefghijklmnopqrstuvwxyz[\ 
\]^_`abcdefghijklmnopqrstuvwxyz{|}~ 
\177 
\200 
\201 
\202 
\203 
\204 
\205 
\206 
\207 
\210 
\211 
\212 
\213 
\214 
\215 
\216 
\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237 ?? 
?????????? ??????????????????????????"..., scr_rmap =  
"\000\001\002\003\004\005\006\a\b\t\n\v\f\r 
\016 
\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 ! 
\"#$%&'()*+,-./0123456789:;<=>?...@abcdefghijklmnopqrstuvwxyz[\ 
\]^_`abcdefghijklmnopqrstuvwxyz{|}~ 
\177 
\200 
\201 
\202 
\203 
\204 
\205 
\206 
\207 
\210 
\211 
\212 
\213 
\214 
\215 
\216 
\217\220\221\222\223\224\225\226\227\230\231\232\233\234\235\236\237 ?? 
?????????? ??????????????????????????"..., palette =  
"\000\000\000\000\000?\000?\000\000???\000\000?\000???\000???\000\000T 
\000\000?\000?T\000???\000T?\000???T???\000T\000\000T?\000?\000\000???T 
\000?T???\000???\000TT\000T?\000?T\000???TT?T???T???T\000\000T\000?T? 
\000T???\000\00---Type <return> to continue, or q <return> to quit---  
0?\000???\000???T\000TT\000?T?TT???\000T?\000???T???TT\000TT?T? 
\000T???T\000?T???\000???TTTTT?T?TT???TT?T???T????||?\234|??"...,  
fonts_loaded = 8, font_8 = 0xc0b97ce0 "", font_14 = 0xc0b984e0 "",  
font_16 = 0xc0b992e0 "", font_22 = 0x0, cursor_char = 7 '\a',  
mouse_char = 208 '?'} (kgdb) list 1055 s = spltty(); 1056 error =  
sc_clean_up(sc->cur_scp); 1057 splx(s); 1058 if (error) 1059 return  
error; 1060 scp = sc_get_stat(SC_DEV(sc, i)); 1061 if (scp == scp->sc- 
 >cur_scp) 1062 return 0; 1063 error = tsleep(&scp->smode, PZERO |  
PCATCH, "waitvt", 0); 1064 return error; (kgdb) print i $3 = 9 (kgdb)  
print sc->dev $4 = (struct cdev **) 0xc0b9a440 (kgdb) print *sc->dev  
$5 = (struct cdev *) 0xc5b52100 (kgdb) print **sc->dev $6 = {si_priv =  
0xc5b52100, si_flags = 4, si_atime = {tv_sec = 1235125168, tv_nsec =  
0}, si_ctime = {tv_sec = 1235125168, tv_nsec = 0}, si_mtime = { tv_sec  
= 1235125168, tv_nsec = 0}, si_uid = 0, si_gid = 0, si_mode = 384,  
si_cred = 0x0, si_drv0 = 0, si_refcount = 2, si_list = {le_next = 0x0,  
le_prev = 0xc5b52238}, si_clone = {le_next = 0x0, le_prev = 0x0},  
si_children = {lh_first = 0x0}, si_siblings = {le_next = 0x0, le_prev  
= 0x0}, si_parent = 0x0, si_name = 0xc5b52178 "ttyv0", si_drv1 =  
0xc0b9a300, si_drv2 = 0x0, si_devsw = 0xc0b44660, si_iosize_max =  
65536, si_usecount = 2, si_threadcount = 2, __si_u = { __sit_tty =  
0xc5b58400, __sid_snapdata = 0xc5b58400},    __si_namebuf = "ttyv0",  
'\0' <repeats 58 times>} (kgdb) print sc->first_vty $7 = 0 (kgdb)  
----8 
<--------8<--------8<--------8<--------8<--------8<--------8<---------  
-- rigo http://rigo.altervista.org
From varga.michal at gmail.com  Mon Mar  9 07:42:00 2009
From: varga.michal at gmail.com (Michal Varga)
Date: Mon Mar  9 07:42:07 2009
Subject: SCHED_ULE + SMP Phenom freeze
Message-ID: <3f1fd1ea0903090716k79ca91bemb21aff9db0073e6e@mail.gmail.com>

Guys, I'd like to point out a still present (rather serious I guess)
problem with SCHED_ULE, possibly triggered when Phenom X3 CPUs are
used.

First time I encountered this problem in early January, it took me
quite a while to narrow the freeze down to ULE with SMP support, well,
after eliminating every other possibility one by one. After that, it
wasn't that hard to find that I'm not the only one seeing this:

http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044167.html
http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/045714.html
(continued)
http://lists.freebsd.org/pipermail/freebsd-amd64/2008-December/011722.html
(there were few more with the same symptoms back then, but sadly I
can't figure out the right keywords to google them at the moment)

Basically, the system can't get past the boot stage with ULE + SMP
support in kernel and hangs after "SMP: AP CPU #X Launched!" (see the
linked October thread for details).

But it gets better - there are absolutely no problems with either
uniprocessor SCHED_ULE, nor SCHED_4BSD (both UP and SMP). No interrupt
storms, no suspicious behaviour, no crashes, everything acts rock
solid. I've been running this system with SCHED_ULE minus SMP support
for more than a month under heavy load, tested SCHED_4BSD minus SMP
for a brief moment, and then another month with SCHED_4BSD + SMP.
Everything works perfectly and also all three cores behave correctly
with 4BSD + SMP. It only gets messy when ULE + SMP combo is used.

I was also wondering why only Phenom X3 people report this problem,
but this may be just a coincidence, who knows. Still, I'm also one of
them:

FreeBSD 7.1-STABLE #0: Sat Mar  7 21:37:27 CET 2009
    root@xenon:/usr/obj/usr/src/sys/KERNEL

Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Phenom(tm) 8450 Triple-Core Processor (2109.74-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f23  Stepping = 3
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x802009<SSE3,MON,CX16,POPCNT>
  AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
  AMD Features2=0x7ff<LAHF,CMP,SVM,ExtAPIC,CR8,<b5>,<b6>,<b7>,Prefetch,<b9>,<b10>>
  TSC: P-state invariant
  Cores per package: 3

Same as with other reports, with SCHED_ULE + SMP, as soon as I hit the
"SMP: AP CPU Launched" stage, the system is dead.

m.
From oliver.pntr at gmail.com  Mon Mar  9 08:13:06 2009
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Mon Mar  9 08:13:13 2009
Subject: locking error in ERR msg
Message-ID: <6101e8c40903090813n44252344we2324d1cd081cc5f@mail.gmail.com>

Hi all!

When remove the mobile from system or restarted/halted the PC, then
this printf - locking error / bug:

I think, it is affected with lockig in TTY layer or in ERR msg code:

arplookup 0.0.0.0 failed: host is not on local network
GEOM_LABEL: Label for provider da0s1 is msdosfs/PHONE CARD.
umass0: at uhub4 port 1 (addr 3) disconnected
(da0:umass-sim0:0:0:0): lost device
>>>>>>>>> (da0:umass-sim0:0:0:G0E)O:M _rLeAmBoEvLi:n gL adbeevli cmes deonsfs/PHONE CARDt rryem <<<<<<<<<
oved.
umass0: detached
arplookup 0.0.0.0 failed: host is not on local network
From bms at incunabulum.net  Mon Mar  9 09:01:12 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Mon Mar  9 09:01:19 2009
Subject: fxp unusable after make world
In-Reply-To: <20090309000610.GA5039@michelle.cdnetworks.co.kr>
References: <49B1AC25.3000700@onetel.com>	<27998819.871236382003017.JavaMail.HALO$@halo>	<1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com>	<49B38AEF.8070909@beatsnet.com>	<20090308093653.GD1531@michelle.cdnetworks.co.kr>	<49B3FAA3.9010302@beatsnet.com>
	<20090309000610.GA5039@michelle.cdnetworks.co.kr>
Message-ID: <49B538BC.3080108@incunabulum.net>

Pyun YongHyeon wrote:
> Your controller looks like i82550. 82550/82551 has nice hardware
> cryptographic capability for IPSec acceleration but it's not used
> at all under FreeBSD. Intel's open source developer manual didn't
> even mention the existence of cryptographic capability.
>   

I had a crack at this about 5-6 years ago.

Now that the descriptor ring format is fairly well known for fxp, reverse
engineering is feasible, as the setup uses the normal NDIS hooks which
Microsoft added for offloading cryptographic operations. Those *are*
documented.

Making it work is another matter entirely...
From beat.siegenthaler at beatsnet.com  Mon Mar  9 09:22:01 2009
From: beat.siegenthaler at beatsnet.com (Beat Siegenthaler)
Date: Mon Mar  9 09:22:35 2009
Subject: fxp unusable after make world
In-Reply-To: <49B538BC.3080108@incunabulum.net>
References: <49B1AC25.3000700@onetel.com>	<27998819.871236382003017.JavaMail.HALO$@halo>	<1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com>	<49B38AEF.8070909@beatsnet.com>	<20090308093653.GD1531@michelle.cdnetworks.co.kr>	<49B3FAA3.9010302@beatsnet.com>	<20090309000610.GA5039@michelle.cdnetworks.co.kr>
	<49B538BC.3080108@incunabulum.net>
Message-ID: <49B54219.8020607@beatsnet.com>



Bruce Simpson wrote:
> 
> Now that the descriptor ring format is fairly well known for fxp, reverse
> engineering is feasible, as the setup uses the normal NDIS hooks which
> Microsoft added for offloading cryptographic operations. Those *are*
> documented.
> 
> Making it work is another matter entirely...

Cryptographic functions where never a needed option. I had this card 
running for maybe three Years. And my observations are for the records, 
if somebody have the same issues since one month or so...

I will also check the commands from Pyun. I will post the results here 
too..

From pluknet at gmail.com  Mon Mar  9 10:01:52 2009
From: pluknet at gmail.com (pluknet)
Date: Mon Mar  9 10:02:00 2009
Subject: locking error in ERR msg
In-Reply-To: <6101e8c40903090813n44252344we2324d1cd081cc5f@mail.gmail.com>
References: <6101e8c40903090813n44252344we2324d1cd081cc5f@mail.gmail.com>
Message-ID: <a31046fc0903091001k5d32c5d0l2af0b721f6fe7377@mail.gmail.com>

2009/3/9 Oliver Pinter <oliver.pntr@gmail.com>:
> Hi all!
>
> When remove the mobile from system or restarted/halted the PC, then
> this printf - locking error / bug:
>
> I think, it is affected with lockig in TTY layer or in ERR msg code:
>
> arplookup 0.0.0.0 failed: host is not on local network
> GEOM_LABEL: Label for provider da0s1 is msdosfs/PHONE CARD.
> umass0: at uhub4 port 1 (addr 3) disconnected
> (da0:umass-sim0:0:0:0): lost device
>>>>>>>>>> (da0:umass-sim0:0:0:G0E)O:M _rLeAmBoEvLi:n gL adbeevli cmes deonsfs/PHONE CARDt rryem <<<<<<<<<
> oved.
> umass0: detached
> arplookup 0.0.0.0 failed: host is not on local network

This is due to the (long standing) nature of simultaneous *unbuffered* output
from two or more threads (usb and geom run paths interaction here).

-- 
wbr,
pluknet
From sascha at holzleiter.name  Mon Mar  9 10:03:42 2009
From: sascha at holzleiter.name (Sascha Holzleiter)
Date: Mon Mar  9 10:03:52 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090309060346.GG5039@michelle.cdnetworks.co.kr>
References: <20090308023642.GB1531@michelle.cdnetworks.co.kr>
	<93D48C8BEA0F954FA6569C8A853EF79C02CE62E0@UQEXMB1.soe.uq.edu.au>
	<20090309060346.GG5039@michelle.cdnetworks.co.kr>
Message-ID: <49B54BE8.7010105@holzleiter.name>

Pyun YongHyeon wrote:
> Thanks a lot! This is the report I had been waiting for. I've
> committed the patch to HEAD(r189555).
>   
Hi,

with the files in HEAD i could also fix the occasional:

re0: watchdog timeout (missed Tx interrupts) -- recovering

on a rented server. Any chance this will be MFC'd to RELENG_7 soon?


From ghelmer at palisadesys.com  Mon Mar  9 12:46:23 2009
From: ghelmer at palisadesys.com (Guy Helmer)
Date: Mon Mar  9 12:46:40 2009
Subject: 7.1 hangs in cache_lookup mutex?
In-Reply-To: <49ABE8FB.3060202@palisadesys.com>
References: <49A46AB4.3080003@palisadesys.com>	<200902261648.32845.jhb@freebsd.org>	<49A7173B.4030608@palisadesys.com>	<200902261753.29607.jhb@freebsd.org>	<49A80A55.5070004@palisadesys.com>
	<49ABE8FB.3060202@palisadesys.com>
Message-ID: <49B57208.4000601@palisadesys.com>

Guy Helmer wrote:
> Guy Helmer wrote:
>> John Baldwin wrote:
>>> On Thursday 26 February 2009 5:27:07 pm Guy Helmer wrote:
>>>  
>>>> John Baldwin wrote:
>>>>   
>>>>> On Thursday 26 February 2009 4:22:15 pm Guy Helmer wrote:
>>>>>       
>>>>>> db> show sleepchain 23110
>>>>>> thread 100181 (pid 23110, vmstat) blocked on sx "user map" XLOCK
>>>>>> thread 100208 (pid 23092, kvoop) is on a run queue
>>>>>> db> show sleepchain 23092
>>>>>> thread 100208 (pid 23092, kvoop) is on a run queue
>>>>>>             
>>>>> Ah, so this is normal (well, mostly) in that kvoop is simply on 
>>>>> the run       
>>> queue 
>>>>> waiting for a CPU.  Can you find the thread pointer for kvoop and 
>>>>> check on things such as if it is pinned and if so to which CPU 
>>>>> (td_pinned will tell you the first, and td_sched->ts_cpu will tell 
>>>>> you the second with ULE).
>>>>>         
>>>> (kgdb) print td->td_pinned
>>>> $2 = 0
>>>>     
>>>
>>> Ok, not pinned.
>>>
>>>  
>>>>  From my captured ddb run:
>>>> cpuid        = 3
>>>> curthread    = 0xc5e2f000: pid 23090 "filter"
>>>> curpcb       = 0xe6f90d90
>>>> fpcurthread  = none
>>>> idlethread   = 0xc442daf0: pid 11 "idle: cpu3"
>>>> APIC ID      = 7
>>>> currentldt   = 0x50
>>>> spin locks held:
>>>>     
>>>
>>> At http://www.freebsd.org/~jhb/gdb/ you can find my kgdb scripts.  
>>> If you source gdb6 you can run 'runtds' which will show you what 
>>> each CPU is doing (more or less) in ps-style output.
>>>
>>>  
>>>> I sure wish I could find the root cause of the hangs.  On a hunch, 
>>>> I tried setting "machdep.cpu_idle_hlt=0" on the amd64 machine, and 
>>>> it has run 32 hours without a hang.  It could just be coincidence, 
>>>> though...
>>>>     
>>>
>>> Ahhh, that actually could explain it perhaps.  Do your CPUs support 
>>> C2 or higher sleep states for idle?  You can try limiting it to only 
>>> C1 (or disable C1E in your BIOS if it has an option for that) to see 
>>> if that fixes it.
>>>
>>>   
>> I don't think the CPUs support anything lower than C1 - there is no 
>> hw.acpi.cpu.cx_supported sysctl node, and hw.cpi.cpu.cx_lowest is 
>> C1.  C1-Enhanced was already disabled in the BIOS, at least on the 
>> machine running amd64.  48 hours of runtime, and no hangs seen yet.  
>> I did reboot it this morning to check the sleep settings in the BIOS.
> Despite having machdep.cpu_idle_hlt=0, the machine wedged for 40 hours 
> over the weekend but came back to life by itself.  Could this be lost 
> IPIs, or a bug in the scheduler?
To finish off this thread, after I disabled hyperthreading in the BIOS 
on this machine (dual Nocona Xeons in a Supermicro X6DHR-8G) it was 
stable for 96 hours.  I applied rev 189023 
(machdep.hyperthreading_allowed=0 disables HT cores at boot) to 
7.1-release, set machdep.hyperthreading_allowed=0 in /boot/loader.conf, 
re-enabled hyperthreading the BIOS to verify the effect of r189023, and 
the machine has been stable for 92 hours.

Guy

From ianjhart at ntlworld.com  Mon Mar  9 14:00:39 2009
From: ianjhart at ntlworld.com (ian j hart)
Date: Mon Mar  9 14:00:47 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <20090309060841.GH5039@michelle.cdnetworks.co.kr>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<200903081705.12523.ianjhart@ntlworld.com>
	<20090309060841.GH5039@michelle.cdnetworks.co.kr>
Message-ID: <200903092100.20436.ianjhart@ntlworld.com>

On Monday 09 March 2009 06:08:41 Pyun YongHyeon wrote:
> On Sun, Mar 08, 2009 at 05:05:12PM +0000, ian j hart wrote:
> > On Sunday 08 March 2009 02:36:42 Pyun YongHyeon wrote:
> > > On Sat, Mar 07, 2009 at 05:17:57PM +0000, ian j hart wrote:
> > > > On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote:
> > > > > On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote:
> > > > >  > On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote:
> > > > >  > > I found something interesting.  I have another RTL8169SC that
> > > > >  > > works perfectly fine without the patch.  The hardware revision
> > > > >  > > is 0x18000000.  After reading Linux driver
> > > > >  > > (drivers/net/r8169c), I realised they use different masks for
> > > > >  > > hardware revisions.  With their logic, non-working chip seems
> > > > >  > > to be 0x98000000 (8110SCe) while working chip seems to be
> > > > >  > > 0x18000000 (8110SCd) with 0xfc800000. FYI...
> > > > >  >
> > > > >  > Now armed with the information, I made it work without reverting
> > > > >  > memory mapped I/O. :-)
> > > > >  >
> > > > >  > http://people.freebsd.org/~jkim/re/re.current2.diff
> > > > >  > http://people.freebsd.org/~jkim/re/re.stable2.diff
> > > > >
> > > > > I like the patch. Since only RTL8169 family uses mask 0xfc800000
> > > > > it would be even better we can limit checking scope for RTL8169SC
> > > > > by comparing PCI device id. I don't know what other side effect
> > > > > would happen if the mask 0xfc800000 would be used on 8101/8168
> > > > > controllers.
> > > > > If the patch works on RTL8169SC would you commit the patch?
> > > > > I'd like to see multiple commits separated by each enhancements
> > > > > as the patch contains several fixes which are not directly related
> > > > > with the issue.
> > > >
> > > > Where are we on this?
> > > >
> > > > I have a headless firewall box which is not happy with 7.1-RELEASE.
> > > > I've upgraded to 7.1-STABLE as of yesterday and now I'm getting 'PHY
> > > > read failed' errors, although the network did come up, which was an
> > > > improvement.
> > > >
> > > > Is there a patch I can try?
> > > >
> > > > http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174&proname=A
> > > >D3RT LAN-G
> > > >
> > > > re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > > > 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on pci0
> > > > re0: Chip rev. 0x18000000
> > > > re0: MAC rev. 0x00000000
> > > > re0: Ethernet address: 00:30:18:ae:1a:1b
> > > > re0: [FILTER]
> > > > re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > > > 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on pci0
> > > > re1: Chip rev. 0x18000000
> > > > re1: MAC rev. 0x00000000
> > > > re1: Ethernet address: 00:30:18:ae:1a:1c
> > > > re1: [FILTER]
> > > > re2: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > > > 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on pci0
> > > > re2: Chip rev. 0x18000000
> > > > re2: MAC rev. 0x00000000
> > > > re2: Ethernet address: 00:30:18:ae:1a:1d
> > > > re2: [FILTER]
> > > >
> > > > re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec
> > > > rev=0x10 hdr=0x00 re1@pci0:0:11:0:        class=0x020000
> > > > card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 re2@pci0:0:12:0:   
> > > >     class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00
> > >
> > > Have you tried re(4) in HEAD?
> > > I had one report that re(4) in HEAD still does not fix the issue so
> > > I posted a possible workaround for that. Unfortunately he didn't
> > > report back so I don't know whether it was right workaround or not.
> > > If re(4) in HEAD does not fix the issue, would you try attached
> > > patch and let me know how it goes?
> >
> > Firstly IANAKH, my expertise in this area stops after "make kernel".
> >
> > I updated
> >
> > /usr/src/sys/dev/re/if_re.c
> > /usr/src/sys/pci/if_rlreg.h
> >
> > to HEAD
>
> And after updating to HEAD did you apply my patch?
>
> > I still get "PHY read failed" with and without the patch.
>
> That's odd. Another user who has the same controller reports the
> fix fixed the issue. I also committed the patch to HEAD so would
> you give it spin again (without applying any patches)?

Clarification:
Updated the two files listed to HEAD
build/install/reboot
Still getting PHY read failed
Patch file
build/install/reboot
Still getting PHY read failed

If HEAD is the now same as the patched version I can't see how this will be 
any different, but I'll try it tomorrow.

-- 
ian j hart
From adrianalopez at conocimientofiscal.com  Mon Mar  9 14:11:51 2009
From: adrianalopez at conocimientofiscal.com (Sarahi Gameros)
Date: Mon Mar  9 14:12:05 2009
Subject: Manejo Integral de las CAJAS y FONDOS de AHORRO
Message-ID: <1192d85bb9100046b8c25492001e3420@conocimientofiscal.com>



   Manejo Integral de las CAJAS Y FONDOS 


   

   Corporacion Legal y Fiscal, le ofrece novedosas    seminarios impartidos por los mas prestigiados consultores de negocios
   en    practicos y    dinamico y competido medio  empresarial de hoy.


   ?Cuales son las  caracteristicas, integracion, implementacion y
   operacion de una Caja y    colaboradores y a su 
   La  implantacion del Plan de Caja o Fondo de Ahorro en la compa?ia
      recibiendo una    brindarles acceso a financiamiento personal    necesidad del ahorro, independientemente del beneficio de la    empresa  al reflejar el costo fiscal en sus contratos laborales.

   Si    organizacion para  evaluar los alcances y posible  implementacion
   de     esta 


   Confirme Ahora!!!







   Esta Magnifica Conferencia se 

   Mexico  DF            &   2009       
   
   Monterrey,  N.L.               
   Horario: 9:00 a 14:00  hrs





    PARA ADQUIRIR LA 


   Solicite un folleto via telefonica  Tel.    Lineas



   Solicite un folleto via correo electronico.    con los siguientes datos:



   Conferencia:  Manejo Integral de las 
   Nombre :



   Puesto :



   Empresa :



   Ciudad :



   Telefonos :



   Extension :



   Fax :







   Le interesa que esta conferencia sea impartida en    Solicite una cotizacion INCOMPANY...





   Se han omitido intencionalmente los acentos para    deformacion del texto en algunos equipos.





   Si no desea recibir invitaciones en el futuro    de CLF envie un correo con asunto ex2.  Gracias
From oliver.pntr at gmail.com  Mon Mar  9 17:58:40 2009
From: oliver.pntr at gmail.com (Oliver Pinter)
Date: Mon Mar  9 17:58:47 2009
Subject: locking error in ERR msg
In-Reply-To: <a31046fc0903091001k5d32c5d0l2af0b721f6fe7377@mail.gmail.com>
References: <6101e8c40903090813n44252344we2324d1cd081cc5f@mail.gmail.com>
	<a31046fc0903091001k5d32c5d0l2af0b721f6fe7377@mail.gmail.com>
Message-ID: <6101e8c40903091758i7f33bb7bu25bb1bcc04e585a2@mail.gmail.com>

hmm, when it is unbuffered, then clear, but embarrassing

On 3/9/09, pluknet <pluknet@gmail.com> wrote:
> 2009/3/9 Oliver Pinter <oliver.pntr@gmail.com>:
>> Hi all!
>>
>> When remove the mobile from system or restarted/halted the PC, then
>> this printf - locking error / bug:
>>
>> I think, it is affected with lockig in TTY layer or in ERR msg code:
>>
>> arplookup 0.0.0.0 failed: host is not on local network
>> GEOM_LABEL: Label for provider da0s1 is msdosfs/PHONE CARD.
>> umass0: at uhub4 port 1 (addr 3) disconnected
>> (da0:umass-sim0:0:0:0): lost device
>>>>>>>>>>> (da0:umass-sim0:0:0:G0E)O:M _rLeAmBoEvLi:n gL adbeevli cmes
>>>>>>>>>>> deonsfs/PHONE CARDt rryem <<<<<<<<<
>> oved.
>> umass0: detached
>> arplookup 0.0.0.0 failed: host is not on local network
>
> This is due to the (long standing) nature of simultaneous *unbuffered*
> output
> from two or more threads (usb and geom run paths interaction here).
>
> --
> wbr,
> pluknet
>
From pyunyh at gmail.com  Mon Mar  9 21:32:40 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Mon Mar  9 21:32:46 2009
Subject: fxp unusable after make world
In-Reply-To: <49B538BC.3080108@incunabulum.net>
References: <49B1AC25.3000700@onetel.com>
	<27998819.871236382003017.JavaMail.HALO$@halo>
	<1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com>
	<49B38AEF.8070909@beatsnet.com>
	<20090308093653.GD1531@michelle.cdnetworks.co.kr>
	<49B3FAA3.9010302@beatsnet.com>
	<20090309000610.GA5039@michelle.cdnetworks.co.kr>
	<49B538BC.3080108@incunabulum.net>
Message-ID: <20090310043059.GC9482@michelle.cdnetworks.co.kr>

On Mon, Mar 09, 2009 at 03:41:48PM +0000, Bruce Simpson wrote:
> Pyun YongHyeon wrote:
> >Your controller looks like i82550. 82550/82551 has nice hardware
> >cryptographic capability for IPSec acceleration but it's not used
> >at all under FreeBSD. Intel's open source developer manual didn't
> >even mention the existence of cryptographic capability.
> >  
> 
> I had a crack at this about 5-6 years ago.
> 
> Now that the descriptor ring format is fairly well known for fxp, reverse
> engineering is feasible, as the setup uses the normal NDIS hooks which
> Microsoft added for offloading cryptographic operations. Those *are*
> documented.
> 

I don't think the descriptor format is well known for IPSec
processing. Intel didn't even show VLAN related bit in 82550/82551
Rx descriptor format.

What might be hard to know would be
  o what kind of acceleration is done by hardware and how to active
    specific features
  o how SAs are managed in hardware
  o errata information

> Making it work is another matter entirely...

AFAIK hardware supported by fxp(4) and txp(4) can offload IPSec
processing. Sun's Cassini+ also seems to have rudimentary support
for IPSec packets but I'm not sure how useful it is. Because I
don't use IPSec at all I have no interests in IPSec acceleration
at this moment. 3Com's Typhoon2 datasheet gives more information on
IPSec acceleration so it would be easier to start with txp(4).
From olli at lurza.secnetix.de  Tue Mar 10 10:17:00 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Tue Mar 10 10:17:08 2009
Subject: impossible packet length ...
In-Reply-To: <20090208112259.GW9427@deviant.kiev.zoral.com.ua>
Message-ID: <200903101716.n2AHGsji059931@lurza.secnetix.de>

Kostik Belousov wrote (on 2009-02-08):
 > Danny Braniss wrote:
 > > going through the logs, after it happened again, I got a glimps of this:
 > > 
 > > Feb  6 18:00:13 warhol-00.cs.huji.ac.il kernel: bce0: discard frame w/o 
 > > leading ethernet header (len 0 pkt len 0)
 > > Feb  6 18:00:19 klee-05.cs.huji.ac.il kernel: nfs: server warhol-00 not 
 > > responding, timed out
 > > ...
 > > Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: More than a single value for 
 > > /defaults in hesiod.local
 > > Feb  6 19:00:00 warhol-00.cs.huji.ac.il amd[715]: Unknown $ sequence in 
 > > "rhost:=${RHOST};type:=nfsl;fs:=${FS};rfs:=$huldig<C0>#^ZM-^KoM- abase"
 > > Feb  6 19:00:00 warhol-00.cs.huji.ac.il kernel: impossible packet length 
 > > (2068989523) from nfs server sunfire:/dist
 > > 
 > > which seems to point fingers at bce...
 > 
 > bce(4) is broken in stable, your best option is to revert to the
 > driver in releng 7.1.

Is anybody working on fixing bce(4) in stable?  As far as
I can see in the repository, nothing happened recently.
The last commit in releng 7 was in December last year.

Otherwise, I suggest to revert the source to the same
version as in releng 7.1.  Unfortunately, bce(4) hardware
is not that uncommon; I have it in several dozen machines
at customers.  Having a known broken driver in -stable
for several months is bad.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"C++ is to C as Lung Cancer is to Lung."
        -- Thomas Funke
From petefrench at ticketswitch.com  Tue Mar 10 10:30:11 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Tue Mar 10 10:30:18 2009
Subject: impossible packet length ...
In-Reply-To: <200903101716.n2AHGsji059931@lurza.secnetix.de>
Message-ID: <E1Lh5mC-000Foo-EQ@dilbert.ticketswitch.com>

>  > bce(4) is broken in stable, your best option is to revert to the
>  > driver in releng 7.1.
>
> Is anybody working on fixing bce(4) in stable?  As far as
> I can see in the repository, nothing happened recently.
> The last commit in releng 7 was in December last year.

I am slightly surprised by all of this, as I have a lot of
machines with bce inerfaces, and they all work properly
in STABLE. I realise that everyones situation is different,
but I wouldnt say it's entirely broken. Certainly they work
well enough on HP servers. I wouldnt be too afraid of deploying
on this hardware.

-pete.
From BORJAMAR at SARENET.ES  Tue Mar 10 10:37:07 2009
From: BORJAMAR at SARENET.ES (Borja Marcos)
Date: Tue Mar 10 10:37:52 2009
Subject: ZFS root file system fun, flash USB, swap
Message-ID: <0295B0E5-EAE8-4317-A2F8-F93F6F9CCF1E@SARENET.ES>


Hello,

I have a couple of questions, I'm using ZFS on FreeBSD 7.1/amd64.

To avoid issues with sharing the disks with ZFS and UFS, I am using a  
USB pendrive on which I copy the /boot directory.

My first problem is: the presence of the /boot/zfs/zpool.cache file is  
critical. Without it the kernel won't recognise the pool, so it stalls  
on boot.

Is it possible to avoid it? Please note that I'm not using any disk  
partitioning scheme, I'm creating the pools using the complete disk. / 
dev/da0, /dev/da1.

Somewhere I've read about GEOM provider and a ZFS improvement. Should  
I partition the disks in a given way so that ZFS would recognise the  
device? My goal is to have a box of configuration independent boot  
flash pendrives, with a pretty much generic kernel for different Dell  
models. But having the pendrives tied to particular machines would be  
a pain in the ass.

As all the Dell machines are not the same, I need generic kernels with  
support for a pool created over a "mfi" raid5, or using individual  
disks, etc.

Second question. Ivan Voras mentions in his wiki that swap on FreeBSD  
7.1 over ZFS doesn't work. The post is from 2007. Is it still _not_  
working? It seems that documentation over this issue is very sparse.

Regarding the method to create the root filesystem, etc, what I'm  
doing is:

zpool create pool/root
zpool create pool/root/usr
zpool create pool/root/var

zpool create pool/home
zpool create pool/whatever

 From a minimal FreeBSD installed on the flash,

tar -c --exclude "./pool/" -f - | ( cd /pool/root && tar xpf -)

#with that I have the system files in their proper place

I edit the fstab in pool/root/etc so that /, /usr and /var point to  
pool/root, pool/root/usr and pool/root/var

zpool set mountpoint=legacy pool/root

For the rest of the datasets I set the proper mountpoints, and boot  
from the flash with a loader.conf instructing the kernel to get the  
root file system from "zfs:pool/root".

It's quite simple, actually.







Borja.

From sem at FreeBSD.org  Tue Mar 10 11:08:12 2009
From: sem at FreeBSD.org (Sergey Matveychuk)
Date: Tue Mar 10 11:08:19 2009
Subject: computer with USB keyboard hangs in loader boot prompt after a time
Message-ID: <49B6A662.7060600@FreeBSD.org>

Hi.

I have a machine with Intel DX58SO X58 mother board (no ps/2 ports). 
I've installed FreeBSD 7.1 on it without any problem and it works fine. 
Till I need boot from another device. I press 6 in boot menu, get loader 
prompt and the computer hangs after a time. Quite random time. From 
second to tens seconds. I thought it just keyboard froze, but once the 
computer started beeping, so it looks like a memory corruption or 
something like that.

-- 
Dixi.
Sem.
From sem at FreeBSD.org  Tue Mar 10 12:30:23 2009
From: sem at FreeBSD.org (Sergey Matveychuk)
Date: Tue Mar 10 12:30:31 2009
Subject: computer with USB keyboard hangs in loader boot prompt after
 a time
In-Reply-To: <49B6A662.7060600@FreeBSD.org>
References: <49B6A662.7060600@FreeBSD.org>
Message-ID: <49B6BFC1.8060200@FreeBSD.org>

Sergey Matveychuk wrote:
> Hi.
> 
> I have a machine with Intel DX58SO X58 mother board (no ps/2 ports). 
> I've installed FreeBSD 7.1 on it without any problem and it works fine. 
> Till I need boot from another device. I press 6 in boot menu, get loader 
> prompt and the computer hangs after a time. Quite random time. From 
> second to tens seconds. I thought it just keyboard froze, but once the 
> computer started beeping, so it looks like a memory corruption or 
> something like that.
> 

As kib@ has told me, it was fixed with r189017 | jhb | 2009-02-25, and 
was MFCed with r189307 | jhb | 2009-03-03. Yeap, it works in STABLE now.

-- 
Dixi.
Sem.
From rick-freebsd2008 at kiwi-computer.com  Tue Mar 10 13:23:26 2009
From: rick-freebsd2008 at kiwi-computer.com (Rick C. Petty)
Date: Tue Mar 10 13:23:38 2009
Subject: cd ripping to flac
In-Reply-To: <20090307071228.GA1134@faust.net>
References: <20090307071228.GA1134@faust.net>
Message-ID: <20090310195644.GA86727@keira.kiwi-computer.com>

On Sat, Mar 07, 2009 at 08:12:28AM +0100, Zoran Kolic wrote:
> Howdy!
> I'd like to rip my cd-s to flac files using some
> command line app, like cdda2wav or cdparanoia.
> Using pipe to flac utility would be nice and the
> way I'd take. What program acts in that matter?

What does this have to do with FreeBSD-stable?  This question is better
asked on freebsd-questions.

> Since cdda2wav is in the base, I suppose people
> use it regurarly. Something like:

What do you mean by "base"?  It is a port and not in the base system.

-- Rick C. Petty
From ianjhart at ntlworld.com  Tue Mar 10 13:47:18 2009
From: ianjhart at ntlworld.com (ian j hart)
Date: Tue Mar 10 13:47:25 2009
Subject: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
In-Reply-To: <200903092100.20436.ianjhart@ntlworld.com>
References: <8dfae1c10901070639x67945324jeeecfcac647d7976@mail.gmail.com>
	<20090309060841.GH5039@michelle.cdnetworks.co.kr>
	<200903092100.20436.ianjhart@ntlworld.com>
Message-ID: <200903102046.59311.ianjhart@ntlworld.com>

On Monday 09 March 2009 21:00:20 ian j hart wrote:
> On Monday 09 March 2009 06:08:41 Pyun YongHyeon wrote:
> > On Sun, Mar 08, 2009 at 05:05:12PM +0000, ian j hart wrote:
> > > On Sunday 08 March 2009 02:36:42 Pyun YongHyeon wrote:
> > > > On Sat, Mar 07, 2009 at 05:17:57PM +0000, ian j hart wrote:
> > > > > On Tuesday 20 January 2009 02:45:19 Pyun YongHyeon wrote:
> > > > > > On Mon, Jan 19, 2009 at 06:33:46PM -0500, Jung-uk Kim wrote:
> > > > > >  > On Monday 19 January 2009 04:33 pm, Jung-uk Kim wrote:
> > > > > >  > > I found something interesting.  I have another RTL8169SC
> > > > > >  > > that works perfectly fine without the patch.  The hardware
> > > > > >  > > revision is 0x18000000.  After reading Linux driver
> > > > > >  > > (drivers/net/r8169c), I realised they use different masks
> > > > > >  > > for hardware revisions.  With their logic, non-working chip
> > > > > >  > > seems to be 0x98000000 (8110SCe) while working chip seems to
> > > > > >  > > be 0x18000000 (8110SCd) with 0xfc800000. FYI...
> > > > > >  >
> > > > > >  > Now armed with the information, I made it work without
> > > > > >  > reverting memory mapped I/O. :-)
> > > > > >  >
> > > > > >  > http://people.freebsd.org/~jkim/re/re.current2.diff
> > > > > >  > http://people.freebsd.org/~jkim/re/re.stable2.diff
> > > > > >
> > > > > > I like the patch. Since only RTL8169 family uses mask 0xfc800000
> > > > > > it would be even better we can limit checking scope for RTL8169SC
> > > > > > by comparing PCI device id. I don't know what other side effect
> > > > > > would happen if the mask 0xfc800000 would be used on 8101/8168
> > > > > > controllers.
> > > > > > If the patch works on RTL8169SC would you commit the patch?
> > > > > > I'd like to see multiple commits separated by each enhancements
> > > > > > as the patch contains several fixes which are not directly
> > > > > > related with the issue.
> > > > >
> > > > > Where are we on this?
> > > > >
> > > > > I have a headless firewall box which is not happy with 7.1-RELEASE.
> > > > > I've upgraded to 7.1-STABLE as of yesterday and now I'm getting
> > > > > 'PHY read failed' errors, although the network did come up, which
> > > > > was an improvement.
> > > > >
> > > > > Is there a patch I can try?
> > > > >
> > > > > http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=174&proname
> > > > >=A D3RT LAN-G
> > > > >
> > > > > re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > > > > 0xf200-0xf2ff mem 0xfdfff000-0xfdfff0ff irq 18 at device 9.0 on
> > > > > pci0 re0: Chip rev. 0x18000000
> > > > > re0: MAC rev. 0x00000000
> > > > > re0: Ethernet address: 00:30:18:ae:1a:1b
> > > > > re0: [FILTER]
> > > > > re1: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > > > > 0xf000-0xf0ff mem 0xfdffd000-0xfdffd0ff irq 19 at device 11.0 on
> > > > > pci0 re1: Chip rev. 0x18000000
> > > > > re1: MAC rev. 0x00000000
> > > > > re1: Ethernet address: 00:30:18:ae:1a:1c
> > > > > re1: [FILTER]
> > > > > re2: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port
> > > > > 0xec00-0xecff mem 0xfdffc000-0xfdffc0ff irq 16 at device 12.0 on
> > > > > pci0 re2: Chip rev. 0x18000000
> > > > > re2: MAC rev. 0x00000000
> > > > > re2: Ethernet address: 00:30:18:ae:1a:1d
> > > > > re2: [FILTER]
> > > > >
> > > > > re0@pci0:0:9:0: class=0x020000 card=0x10ec16f3 chip=0x816710ec
> > > > > rev=0x10 hdr=0x00 re1@pci0:0:11:0:        class=0x020000
> > > > > card=0x10ec16f3 chip=0x816710ec rev=0x10 hdr=0x00 re2@pci0:0:12:0:
> > > > >     class=0x020000 card=0x10ec16f3 chip=0x816710ec rev=0x10
> > > > > hdr=0x00
> > > >
> > > > Have you tried re(4) in HEAD?
> > > > I had one report that re(4) in HEAD still does not fix the issue so
> > > > I posted a possible workaround for that. Unfortunately he didn't
> > > > report back so I don't know whether it was right workaround or not.
> > > > If re(4) in HEAD does not fix the issue, would you try attached
> > > > patch and let me know how it goes?
> > >
> > > Firstly IANAKH, my expertise in this area stops after "make kernel".
> > >
> > > I updated
> > >
> > > /usr/src/sys/dev/re/if_re.c
> > > /usr/src/sys/pci/if_rlreg.h
> > >
> > > to HEAD
> >
> > And after updating to HEAD did you apply my patch?
> >
> > > I still get "PHY read failed" with and without the patch.
> >
> > That's odd. Another user who has the same controller reports the
> > fix fixed the issue. I also committed the patch to HEAD so would
> > you give it spin again (without applying any patches)?
>
> Clarification:
> Updated the two files listed to HEAD
> build/install/reboot
> Still getting PHY read failed
> Patch file
> build/install/reboot
> Still getting PHY read failed
>
> If HEAD is the now same as the patched version I can't see how this will be
> any different, but I'll try it tomorrow.

Patched version was the same, excepting the cardbus removal, so it's no 
surprise it's still broken.

Still on cvs here.
/usr/src/sys/dev/re/if_re.c rev 1.155
/usr/src/sys/pci/if_rlreg.h rev 1.95

-- 
ian j hart
From stimbrown at fastmail.com.au  Tue Mar 10 15:37:34 2009
From: stimbrown at fastmail.com.au (Timothy Brown)
Date: Tue Mar 10 15:37:42 2009
Subject: SCHED_ULE + SMP Phenom freeze
In-Reply-To: <3f1fd1ea0903090716k79ca91bemb21aff9db0073e6e@mail.gmail.com>
References: <3f1fd1ea0903090716k79ca91bemb21aff9db0073e6e@mail.gmail.com>
Message-ID: <22445089.post@talk.nabble.com>



Michal Varga wrote:
> 
> Guys, I'd like to point out a still present (rather serious I guess)
> problem with SCHED_ULE, possibly triggered when Phenom X3 CPUs are
> used.
> 

I had the same problem. I searched the FreeBSD problem report database and
came across this:

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120138

After manually applying the patch and recompiling the kernel, I am able to
boot with SCHED_ULE and SMP enabled.

Cheers,
Tim
-- 
View this message in context: http://www.nabble.com/SCHED_ULE-%2B-SMP-Phenom-freeze-tp22414759p22445089.html
Sent from the freebsd-stable mailing list archive at Nabble.com.

From varga.michal at gmail.com  Tue Mar 10 16:04:35 2009
From: varga.michal at gmail.com (Michal Varga)
Date: Tue Mar 10 16:04:42 2009
Subject: SCHED_ULE + SMP Phenom freeze
In-Reply-To: <22445089.post@talk.nabble.com>
References: <3f1fd1ea0903090716k79ca91bemb21aff9db0073e6e@mail.gmail.com>
	<22445089.post@talk.nabble.com>
Message-ID: <3f1fd1ea0903101604j3219ab08ib6a2c777a2891535@mail.gmail.com>

On Tue, Mar 10, 2009 at 11:37 PM, Timothy Brown
<stimbrown@fastmail.com.au> wrote:
> I had the same problem. I searched the FreeBSD problem report database and
> came across this:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120138
>
> After manually applying the patch and recompiling the kernel, I am able to
> boot with SCHED_ULE and SMP enabled.
>
> Cheers,
> Tim

Wow, thank you for this, going to apply in a moment (but I guess it's
pretty obvious that this is the same issue and also explains the X3
mystery).

Adding Jeff Roberson to cc: to remind about the issue, I think it
wouldn't be a bad idea to get this committed eventually.

m.
From varga.michal at gmail.com  Tue Mar 10 16:52:14 2009
From: varga.michal at gmail.com (Michal Varga)
Date: Tue Mar 10 16:52:21 2009
Subject: SCHED_ULE + SMP Phenom freeze [SOLVED]
Message-ID: <3f1fd1ea0903101652v30984572kfa1f2d3057313359@mail.gmail.com>

Just a quick success report - kern/120138 does indeed solve the Phenom
X3 SCHED_ULE problem.

Attached patch against recent -STABLE in case someone else runs into
it in the near future:


--- sys/kern/sched_ule.c.orig	2008-12-08 05:07:30.000000000 +0100
+++ sys/kern/sched_ule.c	2009-03-11 00:09:43.000000000 +0100
@@ -1399,7 +1399,7 @@
 	 * prevents excess thrashing on large machines and excess idle on
 	 * smaller machines.
 	 */
-	steal_thresh = min(ffs(mp_ncpus) - 1, 4);
+	steal_thresh = min(fls(mp_ncpus) - 1, 4);
 	affinity = SCHED_AFFINITY_DEFAULT;
 #endif
 }
From freebusy at microsoft.com  Tue Mar 10 18:11:59 2009
From: freebusy at microsoft.com (=?UTF-8?B?NSAg6ZmI?=)
Date: Tue Mar 10 18:12:06 2009
Subject: 4 =?utf-8?b?6ZW35pyf?=
Message-ID: <200903101848.n2AImZ90040389@w2.mtf.tpc.yahoo.com>


   5 é å¯äºä¸åæç« çµ¦ä½ å!!
   ------------------------------------------------------------
   給æ¨ççè¨ï¼

   ï¼è¯·ä¸è¦åå¤å件人ï¼è°¢è°¢ï¼
   â 大家好ï¼
   â æå¬å¸é·ææç¼/票代éï¼å¹æ ¼ä¼æ ï¼
   ãã
   å¯æ¶å°ç¥¨ç¡®è®¤å¾ä»æ¬¾ï¼
   â é³ãçï¼13928451175
   â æ¥åQQï¼970378804
   â é® ç®±ï¼yhsy111168@163.com
   注æï¼è¯·ä¸è¦åå¤å件人ï¼è°¢è°¢ï¼
   http://tw.myblog.yahoo.com/jw!iV9BKgmcREN60IDib4WZboFctsvn6aw-/guestbo
   ok

   4 é·æ
   [1]http://tw.myblog.yahoo.com/jw!iV9BKgmcREN60IDib4WZboFctsvn6aw-/gues
   tbook

   Yahoo!å¥æ©æå° ä½ çæå°.åå³.çæ´»æ°é«é©ã
   [2]http://tw.fashion.yahoo.com/
   çæ¬ææ Yahoo!å¥æ©

References

   1. http://tw.myblog.yahoo.com/jw!iV9BKgmcREN60IDib4WZboFctsvn6aw-/guestbook
   2. http://tw.fashion.yahoo.com/
From ivoras at freebsd.org  Tue Mar 10 19:27:11 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Tue Mar 10 19:27:18 2009
Subject: Performance with hundreds of nullfs mounts?
Message-ID: <9bbcef730903101927l3134ce66vf959354914fe4754@mail.gmail.com>

hi,
I seem to remember hearing an anecdote somewhere that using hundreds
(or thousands?) nullfs mounts for jails results in unreasonably bad
file system access performance. Does somebody have this kind of setup
/ is it true?
From andrew at modulus.org  Tue Mar 10 19:31:51 2009
From: andrew at modulus.org (Andrew Snow)
Date: Tue Mar 10 19:31:58 2009
Subject: Performance with hundreds of nullfs mounts?
In-Reply-To: <9bbcef730903101927l3134ce66vf959354914fe4754@mail.gmail.com>
References: <9bbcef730903101927l3134ce66vf959354914fe4754@mail.gmail.com>
Message-ID: <49B72201.7050409@modulus.org>

Ivan Voras wrote:
> I seem to remember hearing an anecdote somewhere that using hundreds
> (or thousands?) nullfs mounts for jails results in unreasonably bad
> file system access performance. Does somebody have this kind of setup
> / is it true?

I'm using about several readonly nullfs mounts per jail: usr, bin sbin, 
lib, libexec, with ~20 jails per machine, and the speed is just fine, on 
7.0-STABLE.


- Andrew
From cliftonr at lava.net  Tue Mar 10 20:26:00 2009
From: cliftonr at lava.net (Clifton Royston)
Date: Tue Mar 10 20:26:08 2009
Subject: Installing FreeBSD from USB flash drive - some experiments
Message-ID: <20090311032557.GA7735@lava.net>

  It seems like questions about installing FreeBSD from a USB drive
come up at regular intervals.  With the low price of flash drives these days, it would
be sort of nice to be able to offer a way for users to conveniently
roll their own USB installer images, or even to offer them for download
as well as the ISOs.

  I spent some time working on it this weekend, initially because I was
trying to get the current pfSense 1.2.2 (based on FreeBSD 7.0) to
install on the Geode-based fit-PC box.  (I eventually got there with
pfSense 1.2.3, based on 7.1.)

  While troubleshooting problems with installing pfSense from USB, I
ended up also building USB images from the 7.1-RELEASE bootonly and the
7.1-RELEASE disc1 ISOs.  To do this I've been hacking on Dario Freni's
fbsd-installiso2img.sh script from 2006, to convert FreeBSD or
FreeBSD-based ISOs to image files.  Initially I thought everything was
working fine, because the bootonly image came right up into sysinstall,
but when I dug a little deeper and tried with a USB image built from
the disc1 liveCD/install ISO, I found that it actually seems not to be
workable as it stands.

  I think I have found some limitations of the current sysinstall which
currently make it currently difficult to convert a working FreeBSD ISO
to an installable or live-disk flash image.   Booting the kernel is
easy.  Getting the rest of the way is harder.

  Background: AFAICT the release ISOs don't currently mount the media
they were booted from (da0a in this case.) Instead they load
boot/mfsroot.gz (compressed memory image) as the root fs, which is fine
and makes good sense, but they don't then mount the boot media anywhere
under it.  (My guess is that this was probably originally done to
support the floppy boot case.)

  So how can you direct it to install from the USB media?

  1) If you try to select media via the menu options, you can't select
USB specifically, nor specify an arbitrary device as the source
(/dev/da0a in this case), so you can't get the booted medium mounted to
install from, so you can't get the distributions accessible, so install
doesn't work.  Picking CD as the media seems to mean specifically an
cd or acd device.

  3) "Aha!" you say, "No problem.  If you're using a USB system, you
can instead choose install from filesystem." Good point, but the file
system on the USB flash is not mounted, and you can't mount it via the
menu.

  4) "So, the LiveCD, then?" The LiveCD function in sysinstall seems to
also currently require the install/liveCD image to be on a cd or acd
device.  With no such device, it won't mount anything and remains stuck
at the "Please insert a LiveCD or DVD" prompt until you cancel.

  5) "The emergency holographic shell, then?"  Yes, you can get into
the emergency holographic shell, with the very limited set of commands
from the mfsroot bin/sbin/stand.  However, if you try using the
emergency holographic shell to mount da0a - as far as I can tell, you
can't do so, because there is no mount in mfsboot's stand, only
mount_nfs.  (I'm guessing the "mount" operation for acd0 or cd0 is
coded into sysinstall?)  The usual mount command of course exists on the
media, but it's on the LiveCD portion which isn't mounted at this
point...

  As far as I could tell, from the state you're in after the system
boots, it's not possible to bootstrap up to where you can access the
contents of the flash drive.  Perhaps I'm just not creative enough.

  I'm looking for the simplest way to make this workable, so that one
could automatically generate a bootable flash drive image from a given
FreeBSD ISO.  Would adding an /etc/fstab mount entry for da0a (inside a
modified version of mfsroot.gz) be honored after loading the root, to
get the install medium premounted for bootstrapping?

  I'm attaching my hacked-up fbsd-installiso2img.sh in case anyone else
is interested in playing with it further.

  -- Clifton
----- cut here ----
#!/bin/sh
# fbsd-install-iso2img.sh
# Original version by Dario Freni 9/2006
# Enhancements by Clifton Royston 3/2009.
# License: Beerware

# You can set some variables here. Edit them to fit your needs.

# Set serial variable to 0 if you don't want serial console at all,
# 1 if you want comconsole and 2 if you want comconsole and vidconsole
serial=0

# Set nofstab=1 to not create any initial fstab on the USB drive;
# this makes the next two settings largely irrelevant.
nofstab=0

# Set rootperm=rw for root fs to mount r/w from the USB drive
#  (Should be unnecessary.)
rootperm=ro

# Set USBLABEL here or with -L label to label the image file system, 
#  to help the loader find the root file system when booting; 
#  otherwise the USB must come up as da0 to finish loading successfully.
USBLABEL=
lbparams=

# Set dopause=1 here or with -p to pause and allow review or editing of
#  the flash image before finalizing the image.
dopause=0

pause() {
 echo "Press enter to continue"
 read foo
}


set -u

if [ $# -ge 3 ]; then
  flag=$1
  if [ ${flag} = "-p" ]; then
    dopause=1
    shift
    flag=$1
  fi
  if [ ${flag} = "-n" ]; then
    nofstab=1
    shift
    flag=$1
  fi
  if [ ${flag} = "-L" ]; then
    shift;
    USBLABEL=$1; shift
    lbparams="-L ${USBLABEL}"
  fi
fi
if [ $# -lt 2 ]; then
  echo "Usage: $0 [-p] [-n] [-L vollabel] source-iso-path output-img-path"
  echo "	-p	pause for review before finalizing image"
  echo "	-n	don't update the /etc/fstab within the image"
  echo "	-L	set file system label on image, to help loader find it"
  exit 1
fi

isoimage=$1; shift
imgoutfile=$1; shift

export tmpdir=$(mktemp -d -t fbsdmount)

# Temp file and directory to be used later
export tmpfile=$(mktemp -t bsdmount)

export isodev=$(mdconfig -a -t vnode -f ${isoimage})

echo "#### Building bootable UFS image ####"

ISOSIZE=$(du -k ${isoimage} | awk '{print $1}')
SECTS=$((($ISOSIZE + ($ISOSIZE/5))*2))

# Root partition size

echo "Initializing image..."
dd if=/dev/zero of=${imgoutfile} count=${SECTS}
ls -l ${imgoutfile}
export imgdev=$(mdconfig -a -t vnode -f ${imgoutfile})

bsdlabel -w -B ${imgdev}
newfs -O1 ${lbparams} /dev/${imgdev}a

mkdir -p ${tmpdir}/iso ${tmpdir}/img

mount -r -t cd9660 /dev/${isodev} ${tmpdir}/iso
mount /dev/${imgdev}a ${tmpdir}/img

echo "Copying files to the image via cpio"
( cd ${tmpdir}/iso && find . -print -depth | cpio -dump ${tmpdir}/img )
# Dump doesn't work from an ISO file system, too bad.
# echo "Copying files to the image via dump/restore..."
## dump -0f - /dev/${isodev} | (cd ${tmpdir}/img && restore -r -f - ) 

#bzcat ${tmpdir}/iso/dist/root.dist.bz2 | mtree -PUr -p ${tmpdir}/img 2>&1 > /dev/null

if [ ${nofstab} -ne 1 ]; then
  echo "Saving original /etc/fstab as /etc/fstab.orig"
  mv ${tmpdir}/img/etc/fstab  ${tmpdir}/img/etc/fstab.orig
  echo "Replacing /etc/fstab, so loader can find root filesystem on flash!"
  if [ "${USBLABEL}" != "" ]; then
    echo "/dev/ufs/${USBLABEL} / ufs ${rootperm} 0 0" > ${tmpdir}/img/etc/fstab
    ## echo "devfs /dev devfs rw 0 0" >> ${tmpdir}/img/etc/fstab
  else 
    echo "/dev/da0a / ufs ${rootperm} 0 0" > ${tmpdir}/img/etc/fstab
    ## echo "devfs /dev devfs rw 0 0" >> ${tmpdir}/img/etc/fstab
  fi
else
  echo "Skipping write of image /etc/fstab"

fi

if [ ${serial} -eq 2 ]; then
        mv ${tmpdir}/img/boot.config ${tmpdir}/img/boot.config.orig
        mv ${tmpdir}/img/boot/loader.conf ${tmpdir}/img/boot/loader.conf.orig
        echo "-D" > ${tmpdir}/img/boot.config
        echo 'console="comconsole, vidconsole"' >> ${tmpdir}/img/boot/loader.conf
elif [ ${serial} -eq 1 ]; then
        mv ${tmpdir}/img/boot.config ${tmpdir}/img/boot.config.orig
        mv ${tmpdir}/img/boot/loader.conf ${tmpdir}/img/boot/loader.conf.orig
        echo "-h" > ${tmpdir}/img/boot.config
        echo 'console="comconsole"' >> ${tmpdir}/img/boot/loader.conf
fi

if [ ${dopause} -eq 1 ]; then
  echo "Pausing to allow manual review and modification of image file:"
  echo "Image is located in ${tmpdir}/img"
  echo "If you need to fix up ${tmpdir}/img/etc/fstab, now is the time."
  pause
fi


cleanup() {
    umount ${tmpdir}/iso
    mdconfig -d -u ${isodev}
    umount ${tmpdir}/img
    mdconfig -d -u ${imgdev}
    rm -rf ${tmpdir} ${tmpfile}
}

cleanup

ls -lh ${imgoutfile}

echo "To write the image to flash, use dd, for example:"
echo "   dd if=${imgoutfile} of=/dev/da0 bs=4M"
----- cut here ----
-- 
    Clifton Royston  --  cliftonr@iandicomputing.com / cliftonr@lava.net
          I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
From doconnor at gsoft.com.au  Tue Mar 10 21:11:06 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Mar 10 21:11:15 2009
Subject: Installing FreeBSD from USB flash drive - some experiments
In-Reply-To: <20090311032557.GA7735@lava.net>
References: <20090311032557.GA7735@lava.net>
Message-ID: <200903111441.01578.doconnor@gsoft.com.au>

On Wednesday 11 March 2009 13:55:58 Clifton Royston wrote:
>   I think I have found some limitations of the current sysinstall which
> currently make it currently difficult to convert a working FreeBSD ISO
> to an installable or live-disk flash image.   Booting the kernel is
> easy.  Getting the rest of the way is harder.

I have a working USB installer for 7.1 but it is not terribly straightfoward.

>   Background: AFAICT the release ISOs don't currently mount the media
> they were booted from (da0a in this case.) Instead they load
> boot/mfsroot.gz (compressed memory image) as the root fs, which is fine
> and makes good sense, but they don't then mount the boot media anywhere
> under it.  (My guess is that this was probably originally done to
> support the floppy boot case.)

Yes, I think so.

>   So how can you direct it to install from the USB media?
>
>   1) If you try to select media via the menu options, you can't select
> USB specifically, nor specify an arbitrary device as the source
> (/dev/da0a in this case), so you can't get the booted medium mounted to
> install from, so you can't get the distributions accessible, so install
> doesn't work.  Picking CD as the media seems to mean specifically an
> cd or acd device.

For some reason the "Install from UFS" thing doesn't let you mount anything, I 
think this would be fairly easy to fix.

I didn't actually attempt to fix this, instead I split my USB stick in 2. The 
first partition was 2.5Gb FAT32, the last 1.5Gb was UFS. I put the CD image on 
there and did boot0cfg etc..

The reason FAT goes first is that otherwise when you put it into a Windows PC 
(as I'd like people to be able to do to edit the install.cfg) Windows gets 
confused and wants to format the disk.. Putting UFS last gets around this and 
it still works fine.

>   5) "The emergency holographic shell, then?"  Yes, you can get into
> the emergency holographic shell, with the very limited set of commands
> from the mfsroot bin/sbin/stand.  However, if you try using the
> emergency holographic shell to mount da0a - as far as I can tell, you
> can't do so, because there is no mount in mfsboot's stand, only
> mount_nfs.  (I'm guessing the "mount" operation for acd0 or cd0 is
> coded into sysinstall?)  The usual mount command of course exists on the
> media, but it's on the LiveCD portion which isn't mounted at this
> point...

Yeah, the lack of mount in /stand on the install disk is a big caveat.

I suspect you could go into label and add /dev/da0a (also, argh, DD is bad, 
use an MBR) and tell it not to newfs it and then sysinstall will mount it for 
you.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090311/71b77682/attachment.pgp
From andrew at modulus.org  Tue Mar 10 21:21:42 2009
From: andrew at modulus.org (Andrew Snow)
Date: Tue Mar 10 21:21:49 2009
Subject: Installing FreeBSD from USB flash drive - some experiments
In-Reply-To: <20090311032557.GA7735@lava.net>
References: <20090311032557.GA7735@lava.net>
Message-ID: <49B73BBE.3020302@modulus.org>


Here's the steps I use to create a 1GB USB image:

# dd if=/dev/zero of=bootable.image bs=1m count=1 oseek=1000 conv=sparse
# mdconfig -a -t vnode -f bootable.image -u 0
# newfs -m 0 -o space -n /dev/md0
# mount /dev/md0 /mnt

# cd /usr/src
# make installworld DESTDIR=/mnt
# make distribution DESTDIR=/mnt
# make installkernel DESTDIR=/mnt
# umount /mnt

At this point you have a file "bootable.image" but instead of actually 
making that a bootable dd image, I choose to create a dump file which is 
a bit more flexible as you can restore it to a USB stick of any size.

# dump -0 -C 8 -f - /dev/md0 | gzip -9 > bootable.dump.gz
# mdconfig -d -u 0


At this point, you have a dump file which you can use to create a 
bootable USB as follows:

Assuming the USB stick is /dev/da0 !

# dd if=/dev/zero of=/dev/da0 bs=16k
# fdisk -BI /dev/da0
# disklabel -B -w /dev/da0s1
# newfs -m 0 -o space -n /dev/da0s1a
# mount -o noatime,async /dev/da0s1a /mnt
# gzcat bootable.dump.gz | ( cd /mnt ; restore -rvf - )
# umount /mnt



Hope that helps


- Andrew
From pluknet at gmail.com  Wed Mar 11 01:37:16 2009
From: pluknet at gmail.com (pluknet)
Date: Wed Mar 11 01:37:23 2009
Subject: Performance with hundreds of nullfs mounts?
In-Reply-To: <9bbcef730903101927l3134ce66vf959354914fe4754@mail.gmail.com>
References: <9bbcef730903101927l3134ce66vf959354914fe4754@mail.gmail.com>
Message-ID: <a31046fc0903110137y2644b53ck1c322a1ffd057774@mail.gmail.com>

2009/3/10 Ivan Voras <ivoras@freebsd.org>:
> hi,
> I seem to remember hearing an anecdote somewhere that using hundreds
> (or thousands?) nullfs mounts for jails results in unreasonably bad
> file system access performance. Does somebody have this kind of setup
> / is it true?


~600-700 null mount points (without using jails) on 6.2. No visible fs
slowdowns.

-- 
wbr,
pluknet
From aoyama at peach.ne.jp  Wed Mar 11 03:26:12 2009
From: aoyama at peach.ne.jp (Daisuke Aoyama)
Date: Wed Mar 11 03:26:25 2009
Subject: Tester wanted for multipath failover iSCSI target software
References: <CF4D70B440A74ADFAE9BB4DEA8BF2B09@artemis>
Message-ID: <E23438AFF5F840699D8A6D4116F390E1@artemis>

Hi all,

Now istgt is a part of ports. (net/istgt)
FreeBSD issue is solved by danny's patch.
After applying the patch, iscontrol can connect to istgt.

Here is release 20090309 latest committed to ports.
http://shell.peach.ne.jp/aoyama/archives/345

If you need anything other than Japanese, please use translation
such as google translate.

Thanks,
--
Daisuke Aoyama

From petefrench at ticketswitch.com  Wed Mar 11 03:52:25 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Wed Mar 11 03:52:32 2009
Subject: Tester wanted for multipath failover iSCSI target software
In-Reply-To: <E23438AFF5F840699D8A6D4116F390E1@artemis>
Message-ID: <E1LhM2m-000G5r-2V@dilbert.ticketswitch.com>

> Now istgt is a part of ports. (net/istgt)
> FreeBSD issue is solved by danny's patch.
> After applying the patch, iscontrol can connect to istgt.

I am interested in giving this a try, though not immediately as I
am away from the office at the moment. Do I need to apply a patch
to iscontrol to make it work though ? I can't work it out from your
statement above.

> Here is release 20090309 latest committed to ports.
> http://shell.peach.ne.jp/aoyama/archives/345

Than ks. Is the intent to integrate with the base system eventually
rather than have it in ports ? It would be nice to have a native
implementation which could then be integrated with ZFS.

Will let you know how I get on...

-pete.
From danny at cs.huji.ac.il  Wed Mar 11 04:39:52 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Wed Mar 11 04:40:02 2009
Subject: Tester wanted for multipath failover iSCSI target software 
In-Reply-To: <E1LhM2m-000G5r-2V@dilbert.ticketswitch.com> 
References: <E1LhM2m-000G5r-2V@dilbert.ticketswitch.com>
Message-ID: <E1LhMmp-000Jpi-LB@kabab.cs.huji.ac.il>

> > Now istgt is a part of ports. (net/istgt)
> > FreeBSD issue is solved by danny's patch.
> > After applying the patch, iscontrol can connect to istgt.
> 
> I am interested in giving this a try, though not immediately as I
> am away from the office at the moment. Do I need to apply a patch
> to iscontrol to make it work though ? I can't work it out from your
> statement above.

english version: (ungoogled :-)
the latest is in:
	http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz
and if you already have 2.1, apply:

--- iscsi.c.orig        2008-09-21 10:01:50.000000000 +0300
+++ iscsi.c     2009-03-11 13:29:04.250472000 +0200
@@ -62,7 +62,7 @@
 #include <dev/iscsi/initiator/iscsi.h>
 #include <dev/iscsi/initiator/iscsivar.h>
 
-static char *iscsi_driver_version = "2.1.0";
+static char *iscsi_driver_version = "2.1.1";
 
 static struct isc_softc isc;
 
--- isc_sm.c.orig       2008-07-19 14:04:23.000000000 +0300
+++ isc_sm.c    2009-03-11 13:30:20.672791000 +0200
@@ -508,7 +508,7 @@
                    sn->cmd++;
 
          case ISCSI_WRITE_DATA:
-              bhs->ExpStSN = htonl(sn->stat);
+              bhs->ExpStSN = htonl(sn->stat + 1);
               break;
 
          default:

----------------------------------------------------------------------------

danny


From aoyama at peach.ne.jp  Wed Mar 11 05:13:03 2009
From: aoyama at peach.ne.jp (Daisuke Aoyama)
Date: Wed Mar 11 05:13:21 2009
Subject: Tester wanted for multipath failover iSCSI target software
References: <E1LhM2m-000G5r-2V@dilbert.ticketswitch.com>
Message-ID: <34849EA9C0D3417C9784824CC0080090@artemis>

>I am interested in giving this a try, though not immediately as I
>am away from the office at the moment. Do I need to apply a patch
>to iscontrol to make it work though ? I can't work it out from your
>statement above.

Yes, you need.

>Than ks. Is the intent to integrate with the base system eventually
>rather than have it in ports ? It would be nice to have a native
>implementation which could then be integrated with ZFS.

istgt is still under development.
so I don't think integration.
before thinking, I should work to fix more bugs.

thank you.

--
Daisuke Aoyama

From army.of.root at googlemail.com  Wed Mar 11 09:00:50 2009
From: army.of.root at googlemail.com (army.of.root)
Date: Wed Mar 11 09:00:57 2009
Subject: Installing FreeBSD from USB flash drive - some experiments
In-Reply-To: <49B73BBE.3020302@modulus.org>
References: <20090311032557.GA7735@lava.net> <49B73BBE.3020302@modulus.org>
Message-ID: <49B7DA31.9@googlemail.com>

Andrew Snow wrote:
> 
> Here's the steps I use to create a 1GB USB image:
> 
> # dd if=/dev/zero of=bootable.image bs=1m count=1 oseek=1000 conv=sparse
> # mdconfig -a -t vnode -f bootable.image -u 0
> # newfs -m 0 -o space -n /dev/md0
> # mount /dev/md0 /mnt
> 
> # cd /usr/src
> # make installworld DESTDIR=/mnt
> # make distribution DESTDIR=/mnt
> # make installkernel DESTDIR=/mnt
> # umount /mnt
> 
> At this point you have a file "bootable.image" but instead of actually 
> making that a bootable dd image, I choose to create a dump file which is 
> a bit more flexible as you can restore it to a USB stick of any size.
> 
> # dump -0 -C 8 -f - /dev/md0 | gzip -9 > bootable.dump.gz
> # mdconfig -d -u 0
> 
> 
> At this point, you have a dump file which you can use to create a 
> bootable USB as follows:
> 
> Assuming the USB stick is /dev/da0 !
> 
> # dd if=/dev/zero of=/dev/da0 bs=16k
> # fdisk -BI /dev/da0
> # disklabel -B -w /dev/da0s1
> # newfs -m 0 -o space -n /dev/da0s1a
> # mount -o noatime,async /dev/da0s1a /mnt
> # gzcat bootable.dump.gz | ( cd /mnt ; restore -rvf - )
> # umount /mnt
> 
> 
> 
> Hope that helps
> 
> 
> - Andrew

Hi,

I didnt test this specific soulution, but I did something similar some time 
ago. Could you put this sketch somewhere visible on the web? - Like the Wiki or 
maybe open a thread in the Forum.

Thanks :)
From squirrel at mail.isot.com  Wed Mar 11 11:44:56 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Wed Mar 11 11:45:03 2009
Subject: Site down after recompile Apache
Message-ID: <4c0d89f999bb9950a373a470b8ea2292@mail.isot.com>

I've made Apache 2.2.11 port yesterday:
 ...# make clean
 ...# make
 ...# make deinstall
 ...#make install

And all went well and all my normal websites come up without a problem.  But since then non of my Joomla 1.0.15 sites are coming up. The log shows:

PHP Warning: Wrong parameter count for chr() in ..../includes/phpInputFilter/class.inputfilter.php(457) : regexp code on line 1
PHP Parse error: syntax error, unexpected T_STRING in ..../includes/phpInputFilter/class.inputfilter.php(459) : regexp code on line 1
PHP Fatal error: preg_replace(): Failed evaluating code: \nchr(0x) in ..../includes/phpInputFilter/class.inputfilter.php on line 459

It seems all of sudden after recompiling Apache, it developed a problem with chr(\\1) and chr(0x\\1).   I didn't touch PHP or MySQL, just recompile of Apache, and it still has all same configurations and host info.

Below is the code that's causing it.

function decode($source)
       {
               // url decode
               $source = html_entity_decode($source, ENT_QUOTES, "ISO-8859-1");
               // convert decimal
               $source = preg_replace('/&#(\d+);/me', "chr(\\1)", $source); // decimal notation
               // convert hex
               $source = preg_replace('/&#x([a-f0-9]+);/mei', "chr(0x\\1)", $source); // hex notation
               return $source;
       }

I've googled and tried all suggestions but nothings helping. I'm using FreeBSD 6.2, Apache 2.2.11, PHP 5.1.6_3, MySQL 5.0.27.  Should I missed a something during remake of Apache?

Please help!!!

From squirrel at mail.isot.com  Wed Mar 11 12:21:51 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Wed Mar 11 12:22:01 2009
Subject: Site down after recompile Apache
Message-ID: <ec1845c79225012a24cb2668015aefa2@mail.isot.com>

I have restarted Apache many time before remaking it, and everything was fine.  Apparently, php 5.1.6_3 was parsing that preg_replace() just fine.  So could I've missed a tick when recompiling Apache?

Meanwhile, I will try installing php 5.2.8.

 

-----Original message-----
From: Jille Timmermans jille@quis.cx
Date: Wed, 11 Mar 2009 20:06:03 -0600
To: Squirrel squirrel@mail.isot.com
Subject: Re: Site down after recompile Apache

> Squirrel schreef:
> > I've made Apache 2.2.11 port yesterday:
> >  ...# make clean
> >  ...# make
> >  ...# make deinstall
> >  ...#make install
> > 
> > And all went well and all my normal websites come up without a problem.  But since then non of my Joomla 1.0.15 sites are coming up. The log shows:
> > 
> > PHP Warning: Wrong parameter count for chr() in ..../includes/phpInputFilter/class.inputfilter.php(457) : regexp code on line 1
> > PHP Parse error: syntax error, unexpected T_STRING in ..../includes/phpInputFilter/class.inputfilter.php(459) : regexp code on line 1
> > PHP Fatal error: preg_replace(): Failed evaluating code: \nchr(0x) in ..../includes/phpInputFilter/class.inputfilter.php on line 459
> > 
> > It seems all of sudden after recompiling Apache, it developed a problem with chr(\\1) and chr(0x\\1).   I didn't touch PHP or MySQL, just recompile of Apache, and it still has all same configurations and host info.
> By restarting apache you also reload mod_php, so if you have upgraded
> your PHP between your last apache restart and this one that might be it.
> and IIRC by restarting apache you also reload php.ini.
> 
> Another thing is that php5-pcre is now part of php5, and not an extra
> extension. I don't know whether that is also for 5.1.
> 
> The function below seems working on 5.2.8 and 5.3.0-beta1.
> 
> -- Jille
> > 
> > Below is the code that's causing it.
> > 
> > function decode($source)
> >        {
> >                // url decode
> >                $source = html_entity_decode($source, ENT_QUOTES, "ISO-8859-1");
> >                // convert decimal
> >                $source = preg_replace('/&#(\d+);/me', "chr(\\1)", $source); // decimal notation
> >                // convert hex
> >                $source = preg_replace('/&#x([a-f0-9]+);/mei', "chr(0x\\1)", $source); // hex notation
> >                return $source;
> >        }
> > 
> > I've googled and tried all suggestions but nothings helping. I'm using FreeBSD 6.2, Apache 2.2.11, PHP 5.1.6_3, MySQL 5.0.27.  Should I missed a something during remake of Apache?
> > 
> > Please help!!!
> > 
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
From jille at quis.cx  Wed Mar 11 12:25:47 2009
From: jille at quis.cx (Jille Timmermans)
Date: Wed Mar 11 12:25:57 2009
Subject: Site down after recompile Apache
In-Reply-To: <4c0d89f999bb9950a373a470b8ea2292@mail.isot.com>
References: <4c0d89f999bb9950a373a470b8ea2292@mail.isot.com>
Message-ID: <49B80B8E.7000808@quis.cx>

Squirrel schreef:
> I've made Apache 2.2.11 port yesterday:
>  ...# make clean
>  ...# make
>  ...# make deinstall
>  ...#make install
> 
> And all went well and all my normal websites come up without a problem.  But since then non of my Joomla 1.0.15 sites are coming up. The log shows:
> 
> PHP Warning: Wrong parameter count for chr() in ..../includes/phpInputFilter/class.inputfilter.php(457) : regexp code on line 1
> PHP Parse error: syntax error, unexpected T_STRING in ..../includes/phpInputFilter/class.inputfilter.php(459) : regexp code on line 1
> PHP Fatal error: preg_replace(): Failed evaluating code: \nchr(0x) in ..../includes/phpInputFilter/class.inputfilter.php on line 459
> 
> It seems all of sudden after recompiling Apache, it developed a problem with chr(\\1) and chr(0x\\1).   I didn't touch PHP or MySQL, just recompile of Apache, and it still has all same configurations and host info.
By restarting apache you also reload mod_php, so if you have upgraded
your PHP between your last apache restart and this one that might be it.
and IIRC by restarting apache you also reload php.ini.

Another thing is that php5-pcre is now part of php5, and not an extra
extension. I don't know whether that is also for 5.1.

The function below seems working on 5.2.8 and 5.3.0-beta1.

-- Jille
> 
> Below is the code that's causing it.
> 
> function decode($source)
>        {
>                // url decode
>                $source = html_entity_decode($source, ENT_QUOTES, "ISO-8859-1");
>                // convert decimal
>                $source = preg_replace('/&#(\d+);/me', "chr(\\1)", $source); // decimal notation
>                // convert hex
>                $source = preg_replace('/&#x([a-f0-9]+);/mei', "chr(0x\\1)", $source); // hex notation
>                return $source;
>        }
> 
> I've googled and tried all suggestions but nothings helping. I'm using FreeBSD 6.2, Apache 2.2.11, PHP 5.1.6_3, MySQL 5.0.27.  Should I missed a something during remake of Apache?
> 
> Please help!!!
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
From peter at simons-rock.edu  Wed Mar 11 12:41:42 2009
From: peter at simons-rock.edu (Peter C. Lai)
Date: Wed Mar 11 12:41:50 2009
Subject: Site down after recompile Apache
In-Reply-To: <ec1845c79225012a24cb2668015aefa2@mail.isot.com>
References: <ec1845c79225012a24cb2668015aefa2@mail.isot.com>
Message-ID: <20090311192331.GN13398@cesium.hyperfine.info>

I believe the Makefile for PHP5 states to use internal pcre library when
building with APR2

On 2009-03-11 01:21:49PM -0600, Squirrel wrote:
> I have restarted Apache many time before remaking it, and everything was fine.  Apparently, php 5.1.6_3 was parsing that preg_replace() just fine.  So could I've missed a tick when recompiling Apache?
> 
> Meanwhile, I will try installing php 5.2.8.
> 
>  
> 
> -----Original message-----
> From: Jille Timmermans jille@quis.cx
> Date: Wed, 11 Mar 2009 20:06:03 -0600
> To: Squirrel squirrel@mail.isot.com
> Subject: Re: Site down after recompile Apache
> 
> > Squirrel schreef:
> > > I've made Apache 2.2.11 port yesterday:
> > >  ...# make clean
> > >  ...# make
> > >  ...# make deinstall
> > >  ...#make install
> > > 
> > > And all went well and all my normal websites come up without a problem.  But since then non of my Joomla 1.0.15 sites are coming up. The log shows:
> > > 
> > > PHP Warning: Wrong parameter count for chr() in ..../includes/phpInputFilter/class.inputfilter.php(457) : regexp code on line 1
> > > PHP Parse error: syntax error, unexpected T_STRING in ..../includes/phpInputFilter/class.inputfilter.php(459) : regexp code on line 1
> > > PHP Fatal error: preg_replace(): Failed evaluating code: \nchr(0x) in ..../includes/phpInputFilter/class.inputfilter.php on line 459
> > > 
> > > It seems all of sudden after recompiling Apache, it developed a problem with chr(\\1) and chr(0x\\1).   I didn't touch PHP or MySQL, just recompile of Apache, and it still has all same configurations and host info.
> > By restarting apache you also reload mod_php, so if you have upgraded
> > your PHP between your last apache restart and this one that might be it.
> > and IIRC by restarting apache you also reload php.ini.
> > 
> > Another thing is that php5-pcre is now part of php5, and not an extra
> > extension. I don't know whether that is also for 5.1.
> > 
> > The function below seems working on 5.2.8 and 5.3.0-beta1.
> > 
> > -- Jille
> > > 
> > > Below is the code that's causing it.
> > > 
> > > function decode($source)
> > >        {
> > >                // url decode
> > >                $source = html_entity_decode($source, ENT_QUOTES, "ISO-8859-1");
> > >                // convert decimal
> > >                $source = preg_replace('/&#(\d+);/me', "chr(\\1)", $source); // decimal notation
> > >                // convert hex
> > >                $source = preg_replace('/&#x([a-f0-9]+);/mei', "chr(0x\\1)", $source); // hex notation
> > >                return $source;
> > >        }
> > > 
> > > I've googled and tried all suggestions but nothings helping. I'm using FreeBSD 6.2, Apache 2.2.11, PHP 5.1.6_3, MySQL 5.0.27.  Should I missed a something during remake of Apache?
> > > 
> > > Please help!!!
> > > 
> > > _______________________________________________
> > > freebsd-stable@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

-- 
===========================================================
Peter C. Lai                 | Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

From raj at csub.edu  Wed Mar 11 13:46:19 2009
From: raj at csub.edu (Russell Jackson)
Date: Wed Mar 11 13:46:26 2009
Subject: Performance with hundreds of nullfs mounts?
In-Reply-To: <9bbcef730903101927l3134ce66vf959354914fe4754@mail.gmail.com>
References: <9bbcef730903101927l3134ce66vf959354914fe4754@mail.gmail.com>
Message-ID: <49B81C01.1080007@csub.edu>

Ivan Voras wrote:
> hi,
> I seem to remember hearing an anecdote somewhere that using hundreds
> (or thousands?) nullfs mounts for jails results in unreasonably bad
> file system access performance. Does somebody have this kind of setup
> / is it true?

I was doing this with jails --before we moved to VMware ESX (for better or worse)-- and
didn't see any noticeable performance degradation at the time (6.x series).

For those interested, the biggest plus for going to the ESX model is that it decoupled low
utilization Windows boxes from over-spec'ed hardware and made it available for FreeBSD to
use ;-). The downsides are that it's proprietary, it's expensive, it's inefficient (e.g.
duplicated files and kernel instances everywhere), and you need freak'in Windows boxes to
manage it.

-- 
Russell A. Jackson <raj@csub.edu>
Network Analyst
California State University, Bakersfield

The first thing I do in the morning
is brush my teeth and sharpen my tongue.
		-- Dorothy Parker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090311/5b465e1f/signature.pgp
From squirrel at mail.isot.com  Wed Mar 11 13:51:17 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Wed Mar 11 13:51:25 2009
Subject: Site down after recompile Apache
Message-ID: <69694e2cf4896e916701e5bc181015f1@mail.isot.com>

phpinfo shows that I do have pcre enabled with version 6.6 06-Feb-2006.

I've also noticed another error on differnet hosts:

ALERT - canary mismatch on efree() - heap overflow or double efree detected (attacker 'xx.xx.xx.xx', file '/..../public_html/libs/modOsDate/db_class.php', line 329)

function field_name($string) {   
           
    return "`" . preg_replace("/[^A-Za-z0-9_\-]/",'',$string) . "`";
}

So it definitely has to do with preg_replace function.  But what could be changed in Apache that would cause this?

Forgot to mention, when I recompiled Apache, I added suexec module, and that's the only thing changed.  Now httpd process is eating up all my CPU...

I'm in process of installing PHP 5.2.8.  If this doesn't fix, then I'll recompile Apache without suexec.


-------------------
PCShare.Com


-----Original message-----
From: "Peter C. Lai" peter@simons-rock.edu
Date: Wed, 11 Mar 2009 20:42:40 -0600
To: Squirrel squirrel@mail.isot.com
Subject: Re: Site down after recompile Apache

> I believe the Makefile for PHP5 states to use internal pcre library when
> building with APR2
> 
> On 2009-03-11 01:21:49PM -0600, Squirrel wrote:
> > I have restarted Apache many time before remaking it, and everything was fine.  Apparently, php 5.1.6_3 was parsing that preg_replace() just fine.  So could I've missed a tick when recompiling Apache?
> > 
> > Meanwhile, I will try installing php 5.2.8.
> > 
> >  
> > 
> > -----Original message-----
> > From: Jille Timmermans jille@quis.cx
> > Date: Wed, 11 Mar 2009 20:06:03 -0600
> > To: Squirrel squirrel@mail.isot.com
> > Subject: Re: Site down after recompile Apache
> > 
> > > Squirrel schreef:
> > > > I've made Apache 2.2.11 port yesterday:
> > > >  ...# make clean
> > > >  ...# make
> > > >  ...# make deinstall
> > > >  ...#make install
> > > > 
> > > > And all went well and all my normal websites come up without a problem.  But since then non of my Joomla 1.0.15 sites are coming up. The log shows:
> > > > 
> > > > PHP Warning: Wrong parameter count for chr() in ..../includes/phpInputFilter/class.inputfilter.php(457) : regexp code on line 1
> > > > PHP Parse error: syntax error, unexpected T_STRING in ..../includes/phpInputFilter/class.inputfilter.php(459) : regexp code on line 1
> > > > PHP Fatal error: preg_replace(): Failed evaluating code: \nchr(0x) in ..../includes/phpInputFilter/class.inputfilter.php on line 459
> > > > 
> > > > It seems all of sudden after recompiling Apache, it developed a problem with chr(\\1) and chr(0x\\1).   I didn't touch PHP or MySQL, just recompile of Apache, and it still has all same configurations and host info.
> > > By restarting apache you also reload mod_php, so if you have upgraded
> > > your PHP between your last apache restart and this one that might be it.
> > > and IIRC by restarting apache you also reload php.ini.
> > > 
> > > Another thing is that php5-pcre is now part of php5, and not an extra
> > > extension. I don't know whether that is also for 5.1.
> > > 
> > > The function below seems working on 5.2.8 and 5.3.0-beta1.
> > > 
> > > -- Jille
> > > > 
> > > > Below is the code that's causing it.
> > > > 
> > > > function decode($source)
> > > >        {
> > > >                // url decode
> > > >                $source = html_entity_decode($source, ENT_QUOTES, "ISO-8859-1");
> > > >                // convert decimal
> > > >                $source = preg_replace('/&#(\d+);/me', "chr(\\1)", $source); // decimal notation
> > > >                // convert hex
> > > >                $source = preg_replace('/&#x([a-f0-9]+);/mei', "chr(0x\\1)", $source); // hex notation
> > > >                return $source;
> > > >        }
> > > > 
> > > > I've googled and tried all suggestions but nothings helping. I'm using FreeBSD 6.2, Apache 2.2.11, PHP 5.1.6_3, MySQL 5.0.27.  Should I missed a something during remake of Apache?
> > > > 
> > > > Please help!!!
> > > > 
> > > > _______________________________________________
> > > > freebsd-stable@freebsd.org mailing list
> > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > > 
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
> -- 
> ===========================================================
> Peter C. Lai                 | Bard College at Simon's Rock
> Systems Administrator        | 84 Alford Rd.
> Information Technology Svcs. | Gt. Barrington, MA 01230 USA
> peter AT simons-rock.edu     | (413) 528-7428
> ===========================================================
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
From squirrel at mail.isot.com  Wed Mar 11 17:20:16 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Wed Mar 11 17:20:24 2009
Subject: Site down after recompile Apache
Message-ID: <ea53eaec010fc0e5d8cdc83479e7f466@mail.isot.com>

After recompiling PHP5.2.8 and php5-extensions, the sites are back up again!!!  Heewww!

Funny thing though, I selected GD option in php5-extensions, and it went without a hitch, but phpinfo() does not show GD2 support.  I've checked the pkg_info and gd2 and php5-gd are both there, and also in extensions.ini contains the line extension=gd.so.  Any ideas please?



-----Original message-----
From: Squirrel squirrel@mail.isot.com
Date: Wed, 11 Mar 2009 21:52:00 -0600
To: "Peter C. Lai" peter@simons-rock.edu
Subject: Re: Site down after recompile Apache

> phpinfo shows that I do have pcre enabled with version 6.6 06-Feb-2006.
> 
> I've also noticed another error on differnet hosts:
> 
> ALERT - canary mismatch on efree() - heap overflow or double efree detected (attacker 'xx.xx.xx.xx', file '/..../public_html/libs/modOsDate/db_class.php', line 329)
> 
> function field_name($string) {   
>            
>     return "`" . preg_replace("/[^A-Za-z0-9_\-]/",'',$string) . "`";
> }
> 
> So it definitely has to do with preg_replace function.  But what could be changed in Apache that would cause this?
> 
> Forgot to mention, when I recompiled Apache, I added suexec module, and that's the only thing changed.  Now httpd process is eating up all my CPU...
> 
> I'm in process of installing PHP 5.2.8.  If this doesn't fix, then I'll recompile Apache without suexec.
> 
> 
> -------------------
> PCShare.Com
> 
> 
> -----Original message-----
> From: "Peter C. Lai" peter@simons-rock.edu
> Date: Wed, 11 Mar 2009 20:42:40 -0600
> To: Squirrel squirrel@mail.isot.com
> Subject: Re: Site down after recompile Apache
> 
> > I believe the Makefile for PHP5 states to use internal pcre library when
> > building with APR2
> > 
> > On 2009-03-11 01:21:49PM -0600, Squirrel wrote:
> > > I have restarted Apache many time before remaking it, and everything was fine.  Apparently, php 5.1.6_3 was parsing that preg_replace() just fine.  So could I've missed a tick when recompiling Apache?
> > > 
> > > Meanwhile, I will try installing php 5.2.8.
> > > 
> > >  
> > > 
> > > -----Original message-----
> > > From: Jille Timmermans jille@quis.cx
> > > Date: Wed, 11 Mar 2009 20:06:03 -0600
> > > To: Squirrel squirrel@mail.isot.com
> > > Subject: Re: Site down after recompile Apache
> > > 
> > > > Squirrel schreef:
> > > > > I've made Apache 2.2.11 port yesterday:
> > > > >  ...# make clean
> > > > >  ...# make
> > > > >  ...# make deinstall
> > > > >  ...#make install
> > > > > 
> > > > > And all went well and all my normal websites come up without a problem.  But since then non of my Joomla 1.0.15 sites are coming up. The log shows:
> > > > > 
> > > > > PHP Warning: Wrong parameter count for chr() in ..../includes/phpInputFilter/class.inputfilter.php(457) : regexp code on line 1
> > > > > PHP Parse error: syntax error, unexpected T_STRING in ..../includes/phpInputFilter/class.inputfilter.php(459) : regexp code on line 1
> > > > > PHP Fatal error: preg_replace(): Failed evaluating code: \nchr(0x) in ..../includes/phpInputFilter/class.inputfilter.php on line 459
> > > > > 
> > > > > It seems all of sudden after recompiling Apache, it developed a problem with chr(\\1) and chr(0x\\1).   I didn't touch PHP or MySQL, just recompile of Apache, and it still has all same configurations and host info.
> > > > By restarting apache you also reload mod_php, so if you have upgraded
> > > > your PHP between your last apache restart and this one that might be it.
> > > > and IIRC by restarting apache you also reload php.ini.
> > > > 
> > > > Another thing is that php5-pcre is now part of php5, and not an extra
> > > > extension. I don't know whether that is also for 5.1.
> > > > 
> > > > The function below seems working on 5.2.8 and 5.3.0-beta1.
> > > > 
> > > > -- Jille
> > > > > 
> > > > > Below is the code that's causing it.
> > > > > 
> > > > > function decode($source)
> > > > >        {
> > > > >                // url decode
> > > > >                $source = html_entity_decode($source, ENT_QUOTES, "ISO-8859-1");
> > > > >                // convert decimal
> > > > >                $source = preg_replace('/&#(\d+);/me', "chr(\\1)", $source); // decimal notation
> > > > >                // convert hex
> > > > >                $source = preg_replace('/&#x([a-f0-9]+);/mei', "chr(0x\\1)", $source); // hex notation
> > > > >                return $source;
> > > > >        }
> > > > > 
> > > > > I've googled and tried all suggestions but nothings helping. I'm using FreeBSD 6.2, Apache 2.2.11, PHP 5.1.6_3, MySQL 5.0.27.  Should I missed a something during remake of Apache?
> > > > > 
> > > > > Please help!!!
> > > > > 
> > > > > _______________________________________________
> > > > > freebsd-stable@freebsd.org mailing list
> > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > > > 
> > > _______________________________________________
> > > freebsd-stable@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > 
> > -- 
> > ===========================================================
> > Peter C. Lai                 | Bard College at Simon's Rock
> > Systems Administrator        | 84 Alford Rd.
> > Information Technology Svcs. | Gt. Barrington, MA 01230 USA
> > peter AT simons-rock.edu     | (413) 528-7428
> > ===========================================================
> > 
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
From squirrel at mail.isot.com  Wed Mar 11 19:05:46 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Wed Mar 11 19:05:53 2009
Subject: Site down after recompile Apache - SOLVED
Message-ID: <2e9243ac24564f419346e503377d4669@mail.isot.com>

Solved!!

Although, specified during make of php5-extensions, for some reason it had to be specified during make of php5 as well.  After I recompiled php5 --with-gd, it all worked out ok.

Another thing was I had to specify --with-jpeg-dir=/usr/local/lib to have GD support jpeg.  Strangely, path for png and gif didn't to be specified.  Little weir, but works.

Thanks for your help.

------------------
PCShare.Com

-----Original message-----
From: Squirrel squirrel@mail.isot.com
Date: Thu, 12 Mar 2009 01:21:29 -0600
To: "Peter C. Lai" peter@simons-rock.edu
Subject: Re: Site down after recompile Apache

> After recompiling PHP5.2.8 and php5-extensions, the sites are back up again!!!  Heewww!
> 
> Funny thing though, I selected GD option in php5-extensions, and it went without a hitch, but phpinfo() does not show GD2 support.  I've checked the pkg_info and gd2 and php5-gd are both there, and also in extensions.ini contains the line extension=gd.so.  Any ideas please?
> 
> 
> 
> -----Original message-----
> From: Squirrel squirrel@mail.isot.com
> Date: Wed, 11 Mar 2009 21:52:00 -0600
> To: "Peter C. Lai" peter@simons-rock.edu
> Subject: Re: Site down after recompile Apache
> 
> > phpinfo shows that I do have pcre enabled with version 6.6 06-Feb-2006.
> > 
> > I've also noticed another error on differnet hosts:
> > 
> > ALERT - canary mismatch on efree() - heap overflow or double efree detected (attacker 'xx.xx.xx.xx', file '/..../public_html/libs/modOsDate/db_class.php', line 329)
> > 
> > function field_name($string) {   
> >            
> >     return "`" . preg_replace("/[^A-Za-z0-9_\-]/",'',$string) . "`";
> > }
> > 
> > So it definitely has to do with preg_replace function.  But what could be changed in Apache that would cause this?
> > 
> > Forgot to mention, when I recompiled Apache, I added suexec module, and that's the only thing changed.  Now httpd process is eating up all my CPU...
> > 
> > I'm in process of installing PHP 5.2.8.  If this doesn't fix, then I'll recompile Apache without suexec.
> > 
> > 
> > -------------------
> > PCShare.Com
> > 
> > 
> > -----Original message-----
> > From: "Peter C. Lai" peter@simons-rock.edu
> > Date: Wed, 11 Mar 2009 20:42:40 -0600
> > To: Squirrel squirrel@mail.isot.com
> > Subject: Re: Site down after recompile Apache
> > 
> > > I believe the Makefile for PHP5 states to use internal pcre library when
> > > building with APR2
> > > 
> > > On 2009-03-11 01:21:49PM -0600, Squirrel wrote:
> > > > I have restarted Apache many time before remaking it, and everything was fine.  Apparently, php 5.1.6_3 was parsing that preg_replace() just fine.  So could I've missed a tick when recompiling Apache?
> > > > 
> > > > Meanwhile, I will try installing php 5.2.8.
> > > > 
> > > >  
> > > > 
> > > > -----Original message-----
> > > > From: Jille Timmermans jille@quis.cx
> > > > Date: Wed, 11 Mar 2009 20:06:03 -0600
> > > > To: Squirrel squirrel@mail.isot.com
> > > > Subject: Re: Site down after recompile Apache
> > > > 
> > > > > Squirrel schreef:
> > > > > > I've made Apache 2.2.11 port yesterday:
> > > > > >  ...# make clean
> > > > > >  ...# make
> > > > > >  ...# make deinstall
> > > > > >  ...#make install
> > > > > > 
> > > > > > And all went well and all my normal websites come up without a problem.  But since then non of my Joomla 1.0.15 sites are coming up. The log shows:
> > > > > > 
> > > > > > PHP Warning: Wrong parameter count for chr() in ..../includes/phpInputFilter/class.inputfilter.php(457) : regexp code on line 1
> > > > > > PHP Parse error: syntax error, unexpected T_STRING in ..../includes/phpInputFilter/class.inputfilter.php(459) : regexp code on line 1
> > > > > > PHP Fatal error: preg_replace(): Failed evaluating code: \nchr(0x) in ..../includes/phpInputFilter/class.inputfilter.php on line 459
> > > > > > 
> > > > > > It seems all of sudden after recompiling Apache, it developed a problem with chr(\\1) and chr(0x\\1).   I didn't touch PHP or MySQL, just recompile of Apache, and it still has all same configurations and host info.
> > > > > By restarting apache you also reload mod_php, so if you have upgraded
> > > > > your PHP between your last apache restart and this one that might be it.
> > > > > and IIRC by restarting apache you also reload php.ini.
> > > > > 
> > > > > Another thing is that php5-pcre is now part of php5, and not an extra
> > > > > extension. I don't know whether that is also for 5.1.
> > > > > 
> > > > > The function below seems working on 5.2.8 and 5.3.0-beta1.
> > > > > 
> > > > > -- Jille
> > > > > > 
> > > > > > Below is the code that's causing it.
> > > > > > 
> > > > > > function decode($source)
> > > > > >        {
> > > > > >                // url decode
> > > > > >                $source = html_entity_decode($source, ENT_QUOTES, "ISO-8859-1");
> > > > > >                // convert decimal
> > > > > >                $source = preg_replace('/&#(\d+);/me', "chr(\\1)", $source); // decimal notation
> > > > > >                // convert hex
> > > > > >                $source = preg_replace('/&#x([a-f0-9]+);/mei', "chr(0x\\1)", $source); // hex notation
> > > > > >                return $source;
> > > > > >        }
> > > > > > 
> > > > > > I've googled and tried all suggestions but nothings helping. I'm using FreeBSD 6.2, Apache 2.2.11, PHP 5.1.6_3, MySQL 5.0.27.  Should I missed a something during remake of Apache?
> > > > > > 
> > > > > > Please help!!!
> > > > > > 
> > > > > > _______________________________________________
> > > > > > freebsd-stable@freebsd.org mailing list
> > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > > > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > > > > 
> > > > _______________________________________________
> > > > freebsd-stable@freebsd.org mailing list
> > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > > 
> > > -- 
> > > ===========================================================
> > > Peter C. Lai                 | Bard College at Simon's Rock
> > > Systems Administrator        | 84 Alford Rd.
> > > Information Technology Svcs. | Gt. Barrington, MA 01230 USA
> > > peter AT simons-rock.edu     | (413) 528-7428
> > > ===========================================================
> > > 
> > > _______________________________________________
> > > freebsd-stable@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > > 
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
From peter.jeremy at alcatel-lucent.com.au  Wed Mar 11 22:36:05 2009
From: peter.jeremy at alcatel-lucent.com.au (Peter Jeremy)
Date: Wed Mar 11 22:36:12 2009
Subject: 7.1 panic "vm_page_startup: inconsistent page counts"
Message-ID: <20090312043646.GB8352@pjdesk.au.alcatel-lucent.com>

I'm trying to upgrade an 11 month old FreeBSD 7 image in a VMware
4.5.2 guest to an up-to-date -stable and it panics as above.  I've
added a printf to report the two counts and there's a difference of
one page.  I don't have any problems with the old 7-stable image or
up-to-date 6-stable or -current using the same VMware version.

A screendump for a verbose boot can be found at
http://imagebin.ca/img/wahNNw.gif

Can I safely delete the assert?
-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090312/433f713c/attachment.pgp
From antik at bsd.ee  Thu Mar 12 00:00:41 2009
From: antik at bsd.ee (Andrei Kolu)
Date: Thu Mar 12 00:00:48 2009
Subject: mergemaster annoyance or not?
Message-ID: <49B8AB66.9080408@bsd.ee>

Hello!

As long time FreeBSD user I am concerned about RELEASE and STABLE 
configuration files inconsistency. No big deal but really annoying if 
you want to upgrade systems occassionally. The problem is that there is 
huge amount of old files between RELEASE and STABLE config files- more 
precisely lots of older config files in STABLE that is really strange 
considered that it should be much newer than RELEASE.

FE:

-# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25 02:59:29 
kensmith Exp $
+# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $

-# $FreeBSD: src/etc/rc.d/newsyslog,v 1.5.2.1.2.1 2008/11/25 02:59:29 
kensmith Exp $
+# $FreeBSD: src/etc/rc.d/newsyslog,v 1.5.2.1 2008/01/28 07:55:44 dougb 
Exp $

-# $FreeBSD: src/etc/rc.d/nfsclient,v 1.6.6.1 2008/11/25 02:59:29 
kensmith Exp $
+# $FreeBSD: src/etc/rc.d/nfsclient,v 1.6 2006/12/31 10:37:18 yar Exp $

-# $FreeBSD: src/etc/rc.d/nfsd,v 1.13.10.1.2.1 2008/11/25 02:59:29 
kensmith Exp $
+# $FreeBSD: src/etc/rc.d/nfsd,v 1.13.10.1 2008/01/28 07:55:44 dougb Exp $

-# $FreeBSD: src/etc/crontab,v 1.32.32.1 2008/11/25 02:59:29 kensmith Exp $
+# $FreeBSD: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $


Oh, and why I have to remove myself from the system? I don't get it. 
Same problem with master.password file- why the hell I have to change that?

-# $FreeBSD: src/etc/group,v 1.35.6.1 2008/11/25 02:59:29 kensmith Exp $
+# $FreeBSD: src/etc/group,v 1.35 2007/06/11 18:36:39 ceri Exp $
 #
-wheel:*:0:root,antik
+wheel:*:0:root
 daemon:*:1:
 kmem:*:2:
 sys:*:3:
@@ -29,4 +29,3 @@
 www:*:80:
 nogroup:*:65533:
 nobody:*:65534:
-antik:*:1001:



How comes that difference is 4 years? Of course files are identical but 
this is annoying to go through files that is not changed at all. Some 
files are newer- that's expected BTW. Please syncronize your cvs between 
releases.
From dougb at FreeBSD.org  Thu Mar 12 00:22:24 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Thu Mar 12 00:22:31 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <49B8AB66.9080408@bsd.ee>
References: <49B8AB66.9080408@bsd.ee>
Message-ID: <alpine.BSF.2.00.0903120015420.1054@ync.qbhto.arg>

On Thu, 12 Mar 2009, Andrei Kolu wrote:

> Hello!
>
> As long time FreeBSD user I am concerned about RELEASE and STABLE 
> configuration files inconsistency.

This topic was covered recently, you might want to check the archives.

> -# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25 02:59:29 
> kensmith Exp $
> +# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp $

What you're seeing is an artifact of the way that CVS deals with cutting a 
release. Even though the content of the files is the same, the CVS Id is 
updated in the release branch so that you can track revisions to that file 
that occur within that branch (e.g., RELENG_6_4), as opposed to the 
changes that occur in the parent branch (RELENG_6). This is a feature.

You can easily deal with this in mergemaster by using the -U option 
(please see the man page). If you're dealing with the problem of a clean 
installation from a -RELEASE CD (or similar) upgrading to the stable 
branch for the first time, -U won't help you unfortunately. But it will 
help you on each successive update. For that first update what I usually 
do is 'rm -r /etc/rc.d/* /etc/periodic/* /etc/defaults/*' and then use 
mergemaster's -i option. That will cover the majority of the problem.


hope this helps,

Doug

-- 

     This .signature sanitized for your protection

From antik at bsd.ee  Thu Mar 12 00:31:01 2009
From: antik at bsd.ee (Andrei Kolu)
Date: Thu Mar 12 00:31:09 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <alpine.BSF.2.00.0903120015420.1054@ync.qbhto.arg>
References: <49B8AB66.9080408@bsd.ee>
	<alpine.BSF.2.00.0903120015420.1054@ync.qbhto.arg>
Message-ID: <49B8BA35.802@bsd.ee>

Doug Barton wrote:
> On Thu, 12 Mar 2009, Andrei Kolu wrote:
>
>> Hello!
>>
>> As long time FreeBSD user I am concerned about RELEASE and STABLE 
>> configuration files inconsistency.
>
> This topic was covered recently, you might want to check the archives.
>
>> -# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25 
>> 02:59:29 kensmith Exp $
>> +# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm 
>> Exp $
>
> What you're seeing is an artifact of the way that CVS deals with 
> cutting a release. Even though the content of the files is the same, 
> the CVS Id is updated in the release branch so that you can track 
> revisions to that file that occur within that branch (e.g., 
> RELENG_6_4), as opposed to the changes that occur in the parent branch 
> (RELENG_6). This is a feature.
>
> You can easily deal with this in mergemaster by using the -U option 
> (please see the man page). If you're dealing with the problem of a 
> clean installation from a -RELEASE CD (or similar) upgrading to the 
> stable branch for the first time, -U won't help you unfortunately. But 
> it will help you on each successive update. For that first update what 
> I usually do is 'rm -r /etc/rc.d/* /etc/periodic/* /etc/defaults/*' 
> and then use mergemaster's -i option. That will cover the majority of 
> the problem.
>
I am upgrading from 7.1-RELEASE (cd) to 7.1-STABLE, anyway it does not 
make any sense to "upgrade" to older version of config files. I hope 
this issue will be resolved.

FreeBSD 7.1-STABLE #0: Wed Mar 11 22:29:33 EET 2009 amd64
From antik at bsd.ee  Thu Mar 12 00:47:19 2009
From: antik at bsd.ee (Andrei Kolu)
Date: Thu Mar 12 00:47:27 2009
Subject: Tester wanted for multipath failover iSCSI target software
In-Reply-To: <34849EA9C0D3417C9784824CC0080090@artemis>
References: <E1LhM2m-000G5r-2V@dilbert.ticketswitch.com>
	<34849EA9C0D3417C9784824CC0080090@artemis>
Message-ID: <49B8BE06.1010105@bsd.ee>

Daisuke Aoyama wrote:
>> I am interested in giving this a try, though not immediately as I
>> am away from the office at the moment. Do I need to apply a patch
>> to iscontrol to make it work though ? I can't work it out from your
>> statement above.
>
> Yes, you need.
>
>> Than ks. Is the intent to integrate with the base system eventually
>> rather than have it in ports ? It would be nice to have a native
>> implementation which could then be integrated with ZFS.
>
> istgt is still under development.
> so I don't think integration.
> before thinking, I should work to fix more bugs.
>
>
I have tested "net/istgt" for couple of days with Windows XP and it
works more reliable than NetBSD "net/iscsi-target".
With NetBSD implementation sometimes I lost partition filesystem
information after disconnecting server from network or rebooting my
computer.

Is there any particular testcases you want to perform?

Tested on FreeBSD 7.1-STABLE #0: Wed Mar 11 22:29:33 EET 2009

P.S. Strange, but I can't find istgt in ports anymore...

From dougb at FreeBSD.org  Thu Mar 12 00:48:00 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Thu Mar 12 00:48:07 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <49B8BA35.802@bsd.ee>
References: <49B8AB66.9080408@bsd.ee>	<alpine.BSF.2.00.0903120015420.1054@ync.qbhto.arg>
	<49B8BA35.802@bsd.ee>
Message-ID: <49B8BE29.3050604@FreeBSD.org>

Andrei Kolu wrote:
> Doug Barton wrote:
>>> -# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25
>>> 02:59:29 kensmith Exp $
>>> +# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm
>>> Exp $
>>
>> What you're seeing is an artifact of the way that CVS deals with
>> cutting a release. Even though the content of the files is the same,
>
> I am upgrading from 7.1-RELEASE (cd) to 7.1-STABLE, anyway it does not
> make any sense to "upgrade" to older version of config files.

Please read what I said above more carefully, especially the bit about
the content of the files being the same.

> I hope this issue will be resolved.

What you're seeing is a mildly annoying side effect of how CVS works.
There is nothing to resolve.

On the other hand, if we follow through with cutting releases on the
8.x branch with subversion we won't have this problem. So perhaps that
will help in your situation.


Doug

-- 

    This .signature sanitized for your protection

From eugen at kuzbass.ru  Thu Mar 12 01:10:04 2009
From: eugen at kuzbass.ru (Eugene Grosbein)
Date: Thu Mar 12 01:10:16 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <alpine.BSF.2.00.0903120015420.1054@ync.qbhto.arg>
References: <49B8AB66.9080408@bsd.ee>
	<alpine.BSF.2.00.0903120015420.1054@ync.qbhto.arg>
Message-ID: <20090312073003.GA81921@svzserv.kemerovo.su>

On Thu, Mar 12, 2009 at 12:22:19AM -0700, Doug Barton wrote:

> What you're seeing is an artifact of the way that CVS deals with cutting a 
> release. Even though the content of the files is the same, the CVS Id is 
> updated in the release branch so that you can track revisions to that file 
> that occur within that branch (e.g., RELENG_6_4), as opposed to the 
> changes that occur in the parent branch (RELENG_6). This is a feature.

I think these days we need (by default) /etc/mergemaster.rc filled in
with something like this:

DIFF_OPTIONS='-I$FreeBSD:.*[$] -I$NetBSD:.*[$]'
IGNORE_FILES='/etc/motd'

Else there is lots of annoyance running mergemaster first time
and after each release and there will be lots of questions/complains
about this.

Eugene Grosbein
From ivoras at freebsd.org  Thu Mar 12 03:40:08 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Thu Mar 12 03:40:46 2009
Subject: Performance with hundreds of nullfs mounts?
In-Reply-To: <49B81C01.1080007@csub.edu>
References: <9bbcef730903101927l3134ce66vf959354914fe4754@mail.gmail.com>
	<49B81C01.1080007@csub.edu>
Message-ID: <gpaopm$jo4$1@ger.gmane.org>

Russell Jackson wrote:
> Ivan Voras wrote:
>> hi,
>> I seem to remember hearing an anecdote somewhere that using hundreds
>> (or thousands?) nullfs mounts for jails results in unreasonably bad
>> file system access performance. Does somebody have this kind of setup
>> / is it true?
> 
> I was doing this with jails --before we moved to VMware ESX (for better or worse)-- and
> didn't see any noticeable performance degradation at the time (6.x series).

Thanks, everyone. I've tracked it down and I heard it from a collegue,
only he was talking about unionfs not nullfs.

> For those interested, the biggest plus for going to the ESX model is that it decoupled low
> utilization Windows boxes from over-spec'ed hardware and made it available for FreeBSD to
> use ;-). The downsides are that it's proprietary, it's expensive, it's inefficient (e.g.
> duplicated files and kernel instances everywhere), and you need freak'in Windows boxes to
> manage it.

Yes, ESX is nice. I've also tried XenServer (the "official" Xen) and
it's been terrible - both slow and clunky. Any other experiences?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090312/a8fea995/signature.pgp
From doconnor at gsoft.com.au  Thu Mar 12 03:45:39 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Thu Mar 12 03:45:47 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <49B8BE29.3050604@FreeBSD.org>
References: <49B8AB66.9080408@bsd.ee> <49B8BA35.802@bsd.ee>
	<49B8BE29.3050604@FreeBSD.org>
Message-ID: <200903122112.31928.doconnor@gsoft.com.au>

On Thursday 12 March 2009 18:17:53 Doug Barton wrote:
> > I hope this issue will be resolved.
>
> What you're seeing is a mildly annoying side effect of how CVS works.
> There is nothing to resolve.

I wouldn't classify it as mildly annoying that you need to manually intervene 
in every single file..

Eugene's idea for the default diff options makes a lot of sense to me - I 
don't think any "normal" user gives a hoot about the CVS Id of a file.
(even devs!)

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090312/f1b91693/attachment.pgp
From petefrench at ticketswitch.com  Thu Mar 12 06:09:04 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Thu Mar 12 06:09:11 2009
Subject: Tester wanted for multipath failover iSCSI target software
In-Reply-To: <49B8BE06.1010105@bsd.ee>
Message-ID: <E1Lhked-000DtH-Mr@dilbert.ticketswitch.com>

> I have tested "net/istgt" for couple of days with Windows XP and it
> works more reliable than NetBSD "net/iscsi-target".
> With NetBSD implementation sometimes I lost partition filesystem
> information after disconnecting server from network or rebooting my
> computer.

I am just trying it against the latest FreeBSD initiator. One thing I
have noticed compared to the netbsd target is that it appears to have
somewhat higer performance. cerrainly the speed that gstat says data is
comming off the disc during a scrub is faster than with iscsi_target.

On the other hand I have got some errors that I am trying to get to the
bottom of. I set up a zpool laast night on a remote disc using the
netbsd initiator and copied about 50 gig of data to it as lots of small
files. I then switched to the istgt initiator this morning and am running
a scrub on the pool. But it is telling me that there are a sigificant number
of errors on the disc, which I wasnt expecting. I am now trying to find
out if that is due to write errors using the taret last night, or read errors
with the new target this morning.

BTW, is there any way to get istgt to accept connections without needing to
specify the initator string ? I am new to all these options for iSCSI
having only used the simple netbsd one before.

cheers,

-pete.
From aoyama at peach.ne.jp  Thu Mar 12 06:21:56 2009
From: aoyama at peach.ne.jp (Daisuke Aoyama)
Date: Thu Mar 12 06:22:04 2009
Subject: Tester wanted for multipath failover iSCSI target software
References: <E1LhM2m-000G5r-2V@dilbert.ticketswitch.com><34849EA9C0D3417C9784824CC0080090@artemis>
	<49B8BE06.1010105@bsd.ee>
Message-ID: <A01838D2B0434CB1950FBFCF808BD3BE@artemis>

Hi,

Thank you for reporting.

>I have tested "net/istgt" for couple of days with Windows XP and it
>works more reliable than NetBSD "net/iscsi-target".
>With NetBSD implementation sometimes I lost partition filesystem
>information after disconnecting server from network or rebooting my
>computer.

Yes, it is one of differences.
istgt reports connected information such as SCSI port to the initiator
for discriminating multipath and failover path.
As a side effect, perhaps more accurate identification is possible.

>Is there any particular testcases you want to perform?
If you use it as usual, it is tested enough.
If I had to say, I want to know how much a CPU usage on the target machine.
Because istgt is more complicated than iscsi-target.

>Tested on FreeBSD 7.1-STABLE #0: Wed Mar 11 22:29:33 EET 2009
Did you use the target with ZFS? or UFS?
Did you use MCS feature?

Thanks,
--
Daisuke Aoyama

From aoyama at peach.ne.jp  Thu Mar 12 06:42:54 2009
From: aoyama at peach.ne.jp (Daisuke Aoyama)
Date: Thu Mar 12 06:43:07 2009
Subject: Tester wanted for multipath failover iSCSI target software
References: <E1Lhked-000DtH-Mr@dilbert.ticketswitch.com>
Message-ID: <8F8EA08BAC924788A58736AADB2849BA@artemis>

Thank you for reporting.

>On the other hand I have got some errors that I am trying to get to the
>bottom of. I set up a zpool laast night on a remote disc using the
>netbsd initiator and copied about 50 gig of data to it as lots of small
>files. I then switched to the istgt initiator this morning and am running
>a scrub on the pool. But it is telling me that there are a sigificant 
>number
>of errors on the disc, which I wasnt expecting. I am now trying to find
>out if that is due to write errors using the taret last night, or read 
>errors
>with the new target this morning.

I'm very interested in this case.

>BTW, is there any way to get istgt to accept connections without needing to
>specify the initator string ? I am new to all these options for iSCSI
>having only used the simple netbsd one before.

sorry for no documents.
special word "ALL" matches any initiator name/IPs.
you can find more sample in istgt.large.conf.sample.

[InitiatorGroup256]
  Comment "ALL initiators from ALL IP"
  InitiatorName ALL
  Netmask ALL

Thanks,

--
Daisuke Aoyama

From petefrench at ticketswitch.com  Thu Mar 12 06:55:38 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Thu Mar 12 06:55:45 2009
Subject: Tester wanted for multipath failover iSCSI target software
In-Reply-To: <8F8EA08BAC924788A58736AADB2849BA@artemis>
Message-ID: <E1LhlNj-000E81-IQ@dilbert.ticketswitch.com>

> Thank you for reporting.
...
> I'm very interested in this case.

Well, I just finihsed doing a 'zpool scrub' on the disc image mounted
locally on the machine which was running istgt. That still shows some
errors - but only 36 of them, compares to the 9000+ I get when running the
scrub mounted remotely!

I am going to do the whole test again just using istgt this time to
see what happens. Some more information about my setup:

Both machines are amd64 - running kernels from March 9th. The client
has the latest version of iscsi_initiator on it as well. The server is
using a file as the disc image, and the file is stored on a pair of
terrabyte SATA drives in a mirrored zpool.

> special word "ALL" matches any initiator name/IPs.
> you can find more sample in istgt.large.conf.sample.

Ah, thanks, thats helps a lot :-) I will let you know what happens
witha  new test.

-pete.
From jhb at freebsd.org  Thu Mar 12 06:58:54 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Mar 12 06:59:07 2009
Subject: 7.1 panic "vm_page_startup: inconsistent page counts"
In-Reply-To: <20090312043646.GB8352@pjdesk.au.alcatel-lucent.com>
References: <20090312043646.GB8352@pjdesk.au.alcatel-lucent.com>
Message-ID: <200903120846.50630.jhb@freebsd.org>

On Thursday 12 March 2009 12:36:46 am Peter Jeremy wrote:
> I'm trying to upgrade an 11 month old FreeBSD 7 image in a VMware
> 4.5.2 guest to an up-to-date -stable and it panics as above.  I've
> added a printf to report the two counts and there's a difference of
> one page.  I don't have any problems with the old 7-stable image or
> up-to-date 6-stable or -current using the same VMware version.
> 
> A screendump for a verbose boot can be found at
> http://imagebin.ca/img/wahNNw.gif
> 
> Can I safely delete the assert?

I don't think so, I would report it to Alan.  The one earlier report of this 
didn't include the detail that it was only off by one page.

-- 
John Baldwin
From jhb at freebsd.org  Thu Mar 12 06:58:59 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Mar 12 06:59:08 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <alpine.BSF.2.00.0903120015420.1054@ync.qbhto.arg>
References: <49B8AB66.9080408@bsd.ee>
	<alpine.BSF.2.00.0903120015420.1054@ync.qbhto.arg>
Message-ID: <200903120849.06549.jhb@freebsd.org>

On Thursday 12 March 2009 3:22:19 am Doug Barton wrote:
> On Thu, 12 Mar 2009, Andrei Kolu wrote:
> 
> > Hello!
> >
> > As long time FreeBSD user I am concerned about RELEASE and STABLE 
> > configuration files inconsistency.
> 
> This topic was covered recently, you might want to check the archives.
> 
> > -# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37.18.1 2008/11/25 02:59:29 
> > kensmith Exp $
> > +# $FreeBSD: src/etc/rc.d/network_ipv6,v 1.37 2004/10/07 13:55:26 mtm Exp 
$
> 
> What you're seeing is an artifact of the way that CVS deals with cutting a 
> release. Even though the content of the files is the same, the CVS Id is 
> updated in the release branch so that you can track revisions to that file 
> that occur within that branch (e.g., RELENG_6_4), as opposed to the 
> changes that occur in the parent branch (RELENG_6). This is a feature.

No, it's a bug in our SVN -> CVS importer that when the branch is created in 
SVN, all the files get forced checkins on the CVS branch which gratuitously 
bumps all the CVS IDs.  Go compare RELENG_6_3 and RELENG_6 (at the time of 
the branch) IDs vs what happened with 6.4 and 7.1.  It does create a _lot_ of 
noise for later /etc merges.  Probably our SVN -> CVS importer could simply 
ignore commits that create a new branch to avoid this problem.

-- 
John Baldwin
From petefrench at ticketswitch.com  Thu Mar 12 07:39:11 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Thu Mar 12 07:39:18 2009
Subject: Tester wanted for multipath failover iSCSI target software
In-Reply-To: <8F8EA08BAC924788A58736AADB2849BA@artemis>
Message-ID: <E1LhlmY-000EFM-Io@dilbert.ticketswitch.com>

Oh dear.... doing the test again caused the client machine to panic,
with the following message:

panic: solaris assert: 0 == dmu_buf_hold(os, lr->lr_foid, boff, zgd, &db), file /usr/src/sys/modules/zfs/../../cddl/controb/opensolaris/uts/common/fs/zfs/zfs_nops.c, line: 955

(that was copied out by hand so there might be typos).

Since that was on the client side it makes me think there is a mproblem
with the initiator. But the same test to the netbsd-target works fine,
so it's some interaction between the two bits of software I guess.

-pete.
From olli at lurza.secnetix.de  Thu Mar 12 08:05:51 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Thu Mar 12 08:05:57 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <49B8AB66.9080408@bsd.ee>
Message-ID: <200903121505.n2CF5RXx047734@lurza.secnetix.de>

This is what I have in my /etc/mergemaster.rc; it will
probably help in your case:

DIFF_FLAG='-Bub'
DIFF_OPTIONS='-I$FreeBSD:.*[$]'
IGNORE_MOTD=yes

The first line causes diff to not display changes that
only affect whitespace.  The second line ignores the CVS
id lines, so that files will compare equal that only differ
in the CVS ids.  The third line lets me keep my motd file
without being asked for it every time.

There are options to keep other files, too, so you might
want to add the master.passwd and group files to that list.
However, sometines a new group or user needs to be created
for proper operation -- that's why I prefer to see those
files whenever they change.

Please refer to the mergemaster(8) manual page for details.
You might also want so set AUTO_INSTALL and AUTO_UPGRADE.

Best regards
   Oliver

PS:  I think the above options should _not_ be on by
default, because that would be a POLA violation.
Those people who want them can easily add them to their
mergemaster.rc file.

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Perl will consistently give you what you want,
unless what you want is consistency."
        -- Larry Wall
From bms at incunabulum.net  Thu Mar 12 09:31:10 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu Mar 12 09:31:18 2009
Subject: HEADS UP: Atheros HAL merged to RELENG_7
Message-ID: <49B938CB.3030501@incunabulum.net>

Hello all,

This is just a note to let you all know that the open source Atheros HAL 
has been merged from HEAD to -STABLE.

I tested it out OK on an IBM/Lenovo ThinkPad T43 with an AR5212 in 
HostAP and STA mode, and on an
ASUS EeePC 701 with AH5424 (PCI-express) in STA mode.

The ath_rate* modules have been removed as kernel modules, however the 
options remain, as these
are now knobs for the HAL as it gets built into if_ath.ko itself.

Furthermore, the ath_hal module should no longer be required.

regards,
BMS
From nealhogan at gmail.com  Thu Mar 12 11:40:54 2009
From: nealhogan at gmail.com (Neal Hogan)
Date: Thu Mar 12 11:41:00 2009
Subject: HEADS UP: Atheros HAL merged to RELENG_7
In-Reply-To: <49B938CB.3030501@incunabulum.net>
References: <49B938CB.3030501@incunabulum.net>
Message-ID: <ab7b49bc0903121111h57500fc2s834f0d8e4ac923a1@mail.gmail.com>

Wondering . . . did you mean 'AR5424', not 'AH5424'?

I'm asking because I have an atheros AR5424 and am (patiently) waiting for
support and can't find info on an atheros AH5424.

Thanks.

On Thu, Mar 12, 2009 at 11:31 AM, Bruce Simpson <bms@incunabulum.net> wrote:

> Hello all,
>
> This is just a note to let you all know that the open source Atheros HAL
> has been merged from HEAD to -STABLE.
>
> I tested it out OK on an IBM/Lenovo ThinkPad T43 with an AR5212 in HostAP
> and STA mode, and on an
> ASUS EeePC 701 with AH5424 (PCI-express) in STA mode.
>
> The ath_rate* modules have been removed as kernel modules, however the
> options remain, as these
> are now knobs for the HAL as it gets built into if_ath.ko itself.
>
> Furthermore, the ath_hal module should no longer be required.
>
> regards,
> BMS
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>



-- 
www.nealhogan.net          www.lambdaserver.com
From cptsalek at gmail.com  Thu Mar 12 16:12:57 2009
From: cptsalek at gmail.com (Christian Walther)
Date: Thu Mar 12 16:13:04 2009
Subject: vpn1411 in Laptop (Thinkpad T31)
Message-ID: <14989d6e0903121550w72115e34ra30f552561209bac@mail.gmail.com>

Hi,

this might seem like a strange question, but I wonder if there would
be any benefit by using a vpn1411 minipci card to encrypt/decrypt geli
encrypted partitions on the fly. I'm using a Thinkpad T31 with a P4 at
2GHz and playing back HD Videos doesn't work flawlessly from the
encrypted partition. I might use a 2nd HDD connected to the media bay,
but this would mean that I need to copy the data to this disk.
Using a vpn1411 seems like a good option. I don't use the minipci slot
for WLAN (I've a PCMCIA card that I only insert if I need to use it),
so it's free. But I wonder if the traffic to and from the card would
saturate the PCI bus and lead to other problems.

What do you think?

Cheers
Christian Walther
From doconnor at gsoft.com.au  Thu Mar 12 17:25:04 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Thu Mar 12 17:25:11 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <200903121505.n2CF5RXx047734@lurza.secnetix.de>
References: <200903121505.n2CF5RXx047734@lurza.secnetix.de>
Message-ID: <200903131054.40000.doconnor@gsoft.com.au>

On Friday 13 March 2009 01:35:27 Oliver Fromme wrote:
> PS:  I think the above options should _not_ be on by
> default, because that would be a POLA violation.
> Those people who want them can easily add them to their
> mergemaster.rc file.

Perhaps they should be suggested in the man page..

I agree it's a POLA violation, but it is rather annoying they can't be made 
the default as it is very much more pleasant to use with those options - the 
defaults can be a recipe for either extreme tedium, or errors depending on how 
patient you are :)

I wonder how hard it would be to add 3 way merging (like sysutils/etcmerge) to 
mergemaster..

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090313/f0dddd70/attachment.pgp
From eugen at kuzbass.ru  Thu Mar 12 21:18:32 2009
From: eugen at kuzbass.ru (Eugene Grosbein)
Date: Thu Mar 12 21:18:40 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <200903121505.n2CF5RXx047734@lurza.secnetix.de>
References: <49B8AB66.9080408@bsd.ee>
	<200903121505.n2CF5RXx047734@lurza.secnetix.de>
Message-ID: <20090313041825.GA56699@svzserv.kemerovo.su>

On Thu, Mar 12, 2009 at 04:05:27PM +0100, Oliver Fromme wrote:

> This is what I have in my /etc/mergemaster.rc; it will
> probably help in your case:
> 
> DIFF_FLAG='-Bub'
> DIFF_OPTIONS='-I$FreeBSD:.*[$]'
> IGNORE_MOTD=yes

Yes, it helps and I like it. But I'm forced to put it to each and every
box I install; that does not annoy me so much
but other people are annoyed.

> PS:  I think the above options should _not_ be on by
> default, because that would be a POLA violation.
> Those people who want them can easily add them to their
> mergemaster.rc file.

I see this as POLA recovery because there where no such problem
with mergemaster before switch to SVN.

Eugene Grosbein
From dougb at FreeBSD.org  Thu Mar 12 21:55:07 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Thu Mar 12 21:55:15 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <20090313041825.GA56699@svzserv.kemerovo.su>
References: <49B8AB66.9080408@bsd.ee>	<200903121505.n2CF5RXx047734@lurza.secnetix.de>
	<20090313041825.GA56699@svzserv.kemerovo.su>
Message-ID: <49B9E727.3070609@FreeBSD.org>

Eugene Grosbein wrote:
> On Thu, Mar 12, 2009 at 04:05:27PM +0100, Oliver Fromme wrote:
> 
>> This is what I have in my /etc/mergemaster.rc; it will
>> probably help in your case:
>>
>> DIFF_FLAG='-Bub'
>> DIFF_OPTIONS='-I$FreeBSD:.*[$]'
>> IGNORE_MOTD=yes

Newer versions of mergemaster prefer the following:
IGNORE_FILES='/etc/motd'

Other files can be added to that list as desired.

> Yes, it helps and I like it. But I'm forced to put it to each and every
> box I install; that does not annoy me so much
> but other people are annoyed.

There is no reason to install this permanently. You can use this
option the first time you upgrade, then use the -U option subsequently.

>> PS:  I think the above options should _not_ be on by
>> default, because that would be a POLA violation.
>> Those people who want them can easily add them to their
>> mergemaster.rc file.
> 
> I see this as POLA recovery because there where no such problem
> with mergemaster before switch to SVN.

IMO this should be fixed at the CVS importer level personally. However
there are workarounds available for the time being.


Doug

-- 

    This .signature sanitized for your protection

From nick at nickwithers.com  Thu Mar 12 22:14:44 2009
From: nick at nickwithers.com (Nick Withers)
Date: Thu Mar 12 22:14:52 2009
Subject: NICs locking up, "*tcp_sc_h"
Message-ID: <1236920519.1490.30.camel@localhost>

Hello all,

I recently installed my first amd64 system (currently running RELENG_7
from 2009-03-11) to replace an aged ppc box and have been having dramas
with the network locking up.

Breaking into the debugger manually and ps-ing shows the network card
(e.g., "[irq20:  fxp0+]") in state "LL" in "*tcp_sc_h". It seems the
process(es) trying to access the card at the time is / are in state "L"
in "*tcp".

I thought this may have been something-or-other in the fxp driver, so
installed an rl card and sadly ran into the issue again.

The console appears unresponsive, but I can get into the debugger (and
as soon as I have, input I'd sent seems to "go through", e.g., if I hit
"Enter" a couple o' times, nothing happens; when I <Ctrl>+<Alt>+<Esc>
into the debugger a few login prompts pop up before the debugger
output).

A "where" on the fxp / rl process (thread?) gives (transcribed from the
console):
____

Tracing PID 31 tid 100030 td 0xffffff00012016e0
sched_switch() at sched_switch+0xf1
mi_switch() at mi_switch+0x18f
turnstile_wait() at turnstile_wait+0x1cf
_mtx_lock_sleep() at _mtx_lock_sleep+0x76
syncache_lookup() at syncache_lookup+0x176
syncache_expand() at syncache_expand+0x38
tcp_input() at tcp_input+0xa7d
ip_input() at ip_input+0xa8
ether_demux() at ether_demux+0x1b9
ether_input() at ether_input+0x1bb
fxp_intr() at fxp_intr+0x233
ithread_loop() at ithread_loop+0x17f
fork_exit() at fork_exit+0x11f
fork_trampoline() at fork_trampoline+0xe
____

A "where" on a process stuck in "*tcp", in this case "[swi4: clock]",
gave the somewhat similar:
____

sched_switch() at sched_switch+0xf1
mi_switch() at mi_switch+0x18f
turnstile_wait() at turnstile_wait+0x1cf
_rw_rlock() at _rw_rlock+0x8c
ipfw_chk() at ipfw_chk+0x3ab2
ipfw_check_out() at ipfw_check_out+0xb1
pfil_run_hooks() at pfil_run_hooks+0x9c
ip_output() at ip_output+0x367
syncache_respond() at syncache_respond+0x2fd
syncache_timer() at syncache_timer+0x15a
(...)
____

In this particular case, the fxp0 card is in a lagg with rl0, but this
problem can be triggered with either card on their own...

The scheduler is SCHED_ULE.

I'm not too sure how to give more useful information that this, I'm
afraid. It's a custom kernel, too... Do I need to supply information on
what code actually exists at the relevant addresses (I'm not at all
clued in on how to do this... Sorry!)? Should I chuck WITNESS,
INVARIANTS et al. in?

I *think* every time this has been triggered there's been a "python2.5"
process in the "*tcp" state. This machine runs net-p2p/deluge and
generally has at least 100 TCP connections on the go at any given time.

Can anyone give me a clue as to what I might do to track this down?
Appreciate any pointers.
-- 
Nick Withers
email: nick@nickwithers.com
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090313/c8ce88cd/attachment.pgp
From nick at nickwithers.com  Thu Mar 12 22:19:44 2009
From: nick at nickwithers.com (Nick Withers)
Date: Thu Mar 12 22:19:52 2009
Subject: NICs locking up, "*tcp_sc_h"
Message-ID: <1236920519.1490.30.camel@localhost>

Hello all,

I recently installed my first amd64 system (currently running RELENG_7
from 2009-03-11) to replace an aged ppc box and have been having dramas
with the network locking up.

Breaking into the debugger manually and ps-ing shows the network card
(e.g., "[irq20:  fxp0+]") in state "LL" in "*tcp_sc_h". It seems the
process(es) trying to access the card at the time is / are in state "L"
in "*tcp".

I thought this may have been something-or-other in the fxp driver, so
installed an rl card and sadly ran into the issue again.

The console appears unresponsive, but I can get into the debugger (and
as soon as I have, input I'd sent seems to "go through", e.g., if I hit
"Enter" a couple o' times, nothing happens; when I <Ctrl>+<Alt>+<Esc>
into the debugger a few login prompts pop up before the debugger
output).

A "where" on the fxp / rl process (thread?) gives (transcribed from the
console):
____

Tracing PID 31 tid 100030 td 0xffffff00012016e0
sched_switch() at sched_switch+0xf1
mi_switch() at mi_switch+0x18f
turnstile_wait() at turnstile_wait+0x1cf
_mtx_lock_sleep() at _mtx_lock_sleep+0x76
syncache_lookup() at syncache_lookup+0x176
syncache_expand() at syncache_expand+0x38
tcp_input() at tcp_input+0xa7d
ip_input() at ip_input+0xa8
ether_demux() at ether_demux+0x1b9
ether_input() at ether_input+0x1bb
fxp_intr() at fxp_intr+0x233
ithread_loop() at ithread_loop+0x17f
fork_exit() at fork_exit+0x11f
fork_trampoline() at fork_trampoline+0xe
____

A "where" on a process stuck in "*tcp", in this case "[swi4: clock]",
gave the somewhat similar:
____

sched_switch() at sched_switch+0xf1
mi_switch() at mi_switch+0x18f
turnstile_wait() at turnstile_wait+0x1cf
_rw_rlock() at _rw_rlock+0x8c
ipfw_chk() at ipfw_chk+0x3ab2
ipfw_check_out() at ipfw_check_out+0xb1
pfil_run_hooks() at pfil_run_hooks+0x9c
ip_output() at ip_output+0x367
syncache_respond() at syncache_respond+0x2fd
syncache_timer() at syncache_timer+0x15a
(...)
____

In this particular case, the fxp0 card is in a lagg with rl0, but this
problem can be triggered with either card on their own...

The scheduler is SCHED_ULE.

I'm not too sure how to give more useful information that this, I'm
afraid. It's a custom kernel, too... Do I need to supply information on
what code actually exists at the relevant addresses (I'm not at all
clued in on how to do this... Sorry!)? Should I chuck WITNESS,
INVARIANTS et al. in?

I *think* every time this has been triggered there's been a "python2.5"
process in the "*tcp" state. This machine runs net-p2p/deluge and
generally has at least 100 TCP connections on the go at any given time.

Can anyone give me a clue as to what I might do to track this down?
Appreciate any pointers.
-- 
Nick Withers
email: nick@nickwithers.com
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090313/c8ce88cd/attachment-0001.pgp
From perryh at pluto.rain.com  Fri Mar 13 00:55:31 2009
From: perryh at pluto.rain.com (perryh@pluto.rain.com)
Date: Fri Mar 13 00:55:37 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <200903131054.40000.doconnor@gsoft.com.au>
References: <200903121505.n2CF5RXx047734@lurza.secnetix.de>
	<200903131054.40000.doconnor@gsoft.com.au>
Message-ID: <49ba0a99.zRpbA1XAX3ZA0YOG%perryh@pluto.rain.com>

"Daniel O'Connor" <doconnor@gsoft.com.au> wrote:

> I wonder how hard it would be to add 3 way merging (like
> sysutils/etcmerge) to mergemaster..

One complication: to do a 3-way merge you have to have the common
ancestor.  To ensure the initial availability of such would require
some infrastructure which AFAIK does not currently exist:

* A standardized place to keep the original contents of /etc --
  /origEtc or /etc-<versionId> anyone?

* A way to ensure that installation populates that place with
  the needed redundant copy of the bits, either by including the
  additional instance within the distributions or by generating
  it in the course of installation.  The former would likely be
  easier, if only because the latter would need to work for all
  installation methods.
From dougb at FreeBSD.org  Fri Mar 13 01:39:13 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Fri Mar 13 01:39:20 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <200903121505.n2CF5RXx047734@lurza.secnetix.de>
References: <200903121505.n2CF5RXx047734@lurza.secnetix.de>
Message-ID: <49BA1BAA.3080905@FreeBSD.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

The attached patch adds a -F option to automatically install files
when only the FreeBSD $Ids differ. I've tested this and it seems to do
what the people concerned about this issue are asking for.

If someone affected by this issue could please test this patch and
report back I'd appreciate it.


Doug

- --

    This .signature sanitized for your protection

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)

iEYEAREDAAYFAkm6G6oACgkQyIakK9Wy8PsUXwCg5hPG8G2swKOC0uhRA5L7Q6xb
a7kAn3DKCxL30ggNzTC9EKBhhjMfgpWq
=8U1J
-----END PGP SIGNATURE-----
-------------- next part --------------
Index: mergemaster.sh
===================================================================
--- mergemaster.sh	(revision 189761)
+++ mergemaster.sh	(working copy)
@@ -263,11 +265,14 @@
 
 # Check the command line options
 #
-while getopts ":ascrvhipCPm:t:du:w:D:A:U" COMMAND_LINE_ARGUMENT ; do
+while getopts ":ascrvhipCPm:t:du:w:D:A:FU" COMMAND_LINE_ARGUMENT ; do
   case "${COMMAND_LINE_ARGUMENT}" in
   A)
     ARCHSTRING='TARGET_ARCH='${OPTARG}
     ;;
+  F)
+    FREEBSD_ID=yes
+    ;;
   U)
     AUTO_UPGRADE=yes
     ;;
@@ -1020,6 +1025,20 @@
       # Use more if not.
       # Use unified diffs by default.  Context diffs give me a headache. :)
       #
+
+      # XXX
+      if [ -n "$FREEBSD_ID" ]; then
+	if diff -q -I$FreeBSD:.*[$] "${DESTDIR}${COMPFILE#.}" "${COMPFILE}" > \
+	  /dev/null 2>&1; then
+          if mm_install "${COMPFILE}"; then
+            echo "*** Updated revision control Id for ${DESTDIR}${COMPFILE#.}"
+          else
+            echo "*** Problem installing ${COMPFILE}, it will remain to merge by hand later"
+          fi
+	  continue
+	fi
+      fi
+
       case "${AUTO_RUN}" in
       '')
         # prompt user to install/delete/merge changes
From doconnor at gsoft.com.au  Fri Mar 13 02:01:34 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Fri Mar 13 02:01:41 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <49ba0a99.zRpbA1XAX3ZA0YOG%perryh@pluto.rain.com>
References: <200903121505.n2CF5RXx047734@lurza.secnetix.de>
	<200903131054.40000.doconnor@gsoft.com.au>
	<49ba0a99.zRpbA1XAX3ZA0YOG%perryh@pluto.rain.com>
Message-ID: <200903131931.28854.doconnor@gsoft.com.au>

On Friday 13 March 2009 17:56:17 perryh@pluto.rain.com wrote:
> "Daniel O'Connor" <doconnor@gsoft.com.au> wrote:
> > I wonder how hard it would be to add 3 way merging (like
> > sysutils/etcmerge) to mergemaster..
>
> One complication: to do a 3-way merge you have to have the common
> ancestor.  To ensure the initial availability of such would require
> some infrastructure which AFAIK does not currently exist:
>
> * A standardized place to keep the original contents of /etc --
>   /origEtc or /etc-<versionId> anyone?

etcmerge keeps it in /var/db/etc

> * A way to ensure that installation populates that place with
>   the needed redundant copy of the bits, either by including the
>   additional instance within the distributions or by generating
>   it in the course of installation.  The former would likely be
>   easier, if only because the latter would need to work for all
>   installation methods.

IMO it is OK to fall back to a 2 way diff if it doesn't exist (ie the first 
time you run it)

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090313/800fa5de/attachment.pgp
From rwatson at FreeBSD.org  Fri Mar 13 02:37:22 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Fri Mar 13 02:37:29 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <1236920519.1490.30.camel@localhost>
References: <1236920519.1490.30.camel@localhost>
Message-ID: <alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>


On Fri, 13 Mar 2009, Nick Withers wrote:

> I recently installed my first amd64 system (currently running RELENG_7 from 
> 2009-03-11) to replace an aged ppc box and have been having dramas with the 
> network locking up.
>
> Breaking into the debugger manually and ps-ing shows the network card (e.g., 
> "[irq20:  fxp0+]") in state "LL" in "*tcp_sc_h". It seems the process(es) 
> trying to access the card at the time is / are in state "L" in "*tcp".
>
> I thought this may have been something-or-other in the fxp driver, so 
> installed an rl card and sadly ran into the issue again.
>
> The console appears unresponsive, but I can get into the debugger (and as 
> soon as I have, input I'd sent seems to "go through", e.g., if I hit "Enter" 
> a couple o' times, nothing happens; when I <Ctrl>+<Alt>+<Esc> into the 
> debugger a few login prompts pop up before the debugger output).
>
> A "where" on the fxp / rl process (thread?) gives (transcribed from the 
> console): ____

Sounds like a lock leak -- if you're running INVARIANTS, then "show allocks" 
and "show allchains" would be useful.  I've had a report of a TCP lock leak 
possibly in tcp_input(), but haven't managed to track it down yet -- this 
could well be it as well.

Robert N M Watson
Computer Laboratory
University of Cambridge


>
> Tracing PID 31 tid 100030 td 0xffffff00012016e0
> sched_switch() at sched_switch+0xf1
> mi_switch() at mi_switch+0x18f
> turnstile_wait() at turnstile_wait+0x1cf
> _mtx_lock_sleep() at _mtx_lock_sleep+0x76
> syncache_lookup() at syncache_lookup+0x176
> syncache_expand() at syncache_expand+0x38
> tcp_input() at tcp_input+0xa7d
> ip_input() at ip_input+0xa8
> ether_demux() at ether_demux+0x1b9
> ether_input() at ether_input+0x1bb
> fxp_intr() at fxp_intr+0x233
> ithread_loop() at ithread_loop+0x17f
> fork_exit() at fork_exit+0x11f
> fork_trampoline() at fork_trampoline+0xe
> ____
>
> A "where" on a process stuck in "*tcp", in this case "[swi4: clock]",
> gave the somewhat similar:
> ____
>
> sched_switch() at sched_switch+0xf1
> mi_switch() at mi_switch+0x18f
> turnstile_wait() at turnstile_wait+0x1cf
> _rw_rlock() at _rw_rlock+0x8c
> ipfw_chk() at ipfw_chk+0x3ab2
> ipfw_check_out() at ipfw_check_out+0xb1
> pfil_run_hooks() at pfil_run_hooks+0x9c
> ip_output() at ip_output+0x367
> syncache_respond() at syncache_respond+0x2fd
> syncache_timer() at syncache_timer+0x15a
> (...)
> ____
>
> In this particular case, the fxp0 card is in a lagg with rl0, but this
> problem can be triggered with either card on their own...
>
> The scheduler is SCHED_ULE.
>
> I'm not too sure how to give more useful information that this, I'm
> afraid. It's a custom kernel, too... Do I need to supply information on
> what code actually exists at the relevant addresses (I'm not at all
> clued in on how to do this... Sorry!)? Should I chuck WITNESS,
> INVARIANTS et al. in?
>
> I *think* every time this has been triggered there's been a "python2.5"
> process in the "*tcp" state. This machine runs net-p2p/deluge and
> generally has at least 100 TCP connections on the go at any given time.
>
> Can anyone give me a clue as to what I might do to track this down?
> Appreciate any pointers.
> -- 
> Nick Withers
> email: nick@nickwithers.com
> Web: http://www.nickwithers.com
> Mobile: +61 414 397 446
>
From rwatson at FreeBSD.org  Fri Mar 13 02:50:00 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Fri Mar 13 02:50:06 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
References: <1236920519.1490.30.camel@localhost>
	<alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
Message-ID: <alpine.BSF.2.00.0903130949210.61873@fledge.watson.org>


On Fri, 13 Mar 2009, Robert Watson wrote:

> Sounds like a lock leak -- if you're running INVARIANTS, then "show allocks"
                                                  ^^^^ should read WITNESS
> and "show allchains" would be useful.  I've had a report of a TCP lock leak 
> possibly in tcp_input(), but haven't managed to track it down yet -- this 
> could well be it as well.

Robert N M Watson
Computer Laboratory
University of Cambridge
From nick at nickwithers.com  Fri Mar 13 02:56:36 2009
From: nick at nickwithers.com (Nick Withers)
Date: Fri Mar 13 02:56:43 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
References: <1236920519.1490.30.camel@localhost>
	<alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
Message-ID: <1236938184.1490.40.camel@localhost>

On Fri, 2009-03-13 at 09:37 +0000, Robert Watson wrote:
> On Fri, 13 Mar 2009, Nick Withers wrote:
> 
> > I recently installed my first amd64 system (currently running RELENG_7 from 
> > 2009-03-11) to replace an aged ppc box and have been having dramas with the 
> > network locking up.
> >
> > Breaking into the debugger manually and ps-ing shows the network card (e.g., 
> > "[irq20:  fxp0+]") in state "LL" in "*tcp_sc_h". It seems the process(es) 
> > trying to access the card at the time is / are in state "L" in "*tcp".
> >
> > I thought this may have been something-or-other in the fxp driver, so 
> > installed an rl card and sadly ran into the issue again.
> >
> > The console appears unresponsive, but I can get into the debugger (and as 
> > soon as I have, input I'd sent seems to "go through", e.g., if I hit "Enter" 
> > a couple o' times, nothing happens; when I <Ctrl>+<Alt>+<Esc> into the 
> > debugger a few login prompts pop up before the debugger output).
> >
> > A "where" on the fxp / rl process (thread?) gives (transcribed from the 
> > console): ____
> 
> Sounds like a lock leak -- if you're running INVARIANTS, then "show allocks" 
> and "show allchains" would be useful.  I've had a report of a TCP lock leak 
> possibly in tcp_input(), but haven't managed to track it down yet -- this 
> could well be it as well.

Righto, I'll recompile the kernel with INVARIANTS (hell, I'll go bananas
and include everything listed in
http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html - anything else I might include?).

Sorry for the original double-post, by the way, not quite sure how that
happened...

I can reproduce this problem relatively easily, by the way (every 3
days, on average). I meant to say this before, too, but it seems to
happen a lot more often on the fxp than on rl.

I'm sorry to ask what is probably a very simple question, but is there
somewhere I should look to get clues on debugging from a manually
generated dump? I tried "panic" after manually envoking the kernel
debugger but proved highly inept at getting from the dump the same
information "ps" / "where" gave me within the debugger live.

Ta for your help!

> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> 
> 
> >
> > Tracing PID 31 tid 100030 td 0xffffff00012016e0
> > sched_switch() at sched_switch+0xf1
> > mi_switch() at mi_switch+0x18f
> > turnstile_wait() at turnstile_wait+0x1cf
> > _mtx_lock_sleep() at _mtx_lock_sleep+0x76
> > syncache_lookup() at syncache_lookup+0x176
> > syncache_expand() at syncache_expand+0x38
> > tcp_input() at tcp_input+0xa7d
> > ip_input() at ip_input+0xa8
> > ether_demux() at ether_demux+0x1b9
> > ether_input() at ether_input+0x1bb
> > fxp_intr() at fxp_intr+0x233
> > ithread_loop() at ithread_loop+0x17f
> > fork_exit() at fork_exit+0x11f
> > fork_trampoline() at fork_trampoline+0xe
> > ____
> >
> > A "where" on a process stuck in "*tcp", in this case "[swi4: clock]",
> > gave the somewhat similar:
> > ____
> >
> > sched_switch() at sched_switch+0xf1
> > mi_switch() at mi_switch+0x18f
> > turnstile_wait() at turnstile_wait+0x1cf
> > _rw_rlock() at _rw_rlock+0x8c
> > ipfw_chk() at ipfw_chk+0x3ab2
> > ipfw_check_out() at ipfw_check_out+0xb1
> > pfil_run_hooks() at pfil_run_hooks+0x9c
> > ip_output() at ip_output+0x367
> > syncache_respond() at syncache_respond+0x2fd
> > syncache_timer() at syncache_timer+0x15a
> > (...)
> > ____
> >
> > In this particular case, the fxp0 card is in a lagg with rl0, but this
> > problem can be triggered with either card on their own...
> >
> > The scheduler is SCHED_ULE.
> >
> > I'm not too sure how to give more useful information that this, I'm
> > afraid. It's a custom kernel, too... Do I need to supply information on
> > what code actually exists at the relevant addresses (I'm not at all
> > clued in on how to do this... Sorry!)? Should I chuck WITNESS,
> > INVARIANTS et al. in?
> >
> > I *think* every time this has been triggered there's been a "python2.5"
> > process in the "*tcp" state. This machine runs net-p2p/deluge and
> > generally has at least 100 TCP connections on the go at any given time.
> >
> > Can anyone give me a clue as to what I might do to track this down?
> > Appreciate any pointers.
> > -- 
> > Nick Withers
> > email: nick@nickwithers.com
> > Web: http://www.nickwithers.com
> > Mobile: +61 414 397 446
> >
-- 
Nick Withers
email: nick@nickwithers.com
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090313/e7f6c711/attachment.pgp
From rwatson at FreeBSD.org  Fri Mar 13 03:10:24 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Fri Mar 13 03:10:30 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <1236938184.1490.40.camel@localhost>
References: <1236920519.1490.30.camel@localhost>
	<alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
	<1236938184.1490.40.camel@localhost>
Message-ID: <alpine.BSF.2.00.0903131006080.61873@fledge.watson.org>

On Fri, 13 Mar 2009, Nick Withers wrote:

> Sorry for the original double-post, by the way, not quite sure how that 
> happened...
>
> I can reproduce this problem relatively easily, by the way (every 3 days, on 
> average). I meant to say this before, too, but it seems to happen a lot more 
> often on the fxp than on rl.
>
> I'm sorry to ask what is probably a very simple question, but is there 
> somewhere I should look to get clues on debugging from a manually generated 
> dump? I tried "panic" after manually envoking the kernel debugger but proved 
> highly inept at getting from the dump the same information "ps" / "where" 
> gave me within the debugger live.

If this is, in fact, a TCP input lock leak of some sort, then most likely some 
particular property of a host your system talks to, or a network it runs over, 
triggers this (presumably) unusual edge case -- perhaps a firewall that mucks 
with TCP in a funny way, etc.  Of course, it might be something completely 
different -- the fact that everything is blocked on *tcp_sc_h and *tcp, simply 
means that something holding TCP locks hasn't released them, and this could 
happen for a number of reasons.

Once you've acquired a crashdump, you can run crashinfo(8), which will produce 
a summary of useful debugging information.  There are some things that are a 
bit easier to do in the run-time debugger, such as lock analysis, as the 
run-time debugger is more up-close and personal with in-kernel data 
structures; other things are easier in kgdb, which has complete source code 
and C type access.  I find kgdb works pretty well for everything but "show 
much what locks are held".  Many of our system monitoring tools, including ps 
and portions of netstat, can actually be run on crashdumps to report the state 
of the system at the time it crashed -- take a look at the -M and -N command 
line arguments, which respectively allow you to point those tools at the 
crashdump and at a kernel with debugging symbols (typically kernel.debug or 
kernel.symbols) matching the kernel that was booted at the time of the crash.

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> Ta for your help!
>
>> Robert N M Watson
>> Computer Laboratory
>> University of Cambridge
>>
>>
>>>
>>> Tracing PID 31 tid 100030 td 0xffffff00012016e0
>>> sched_switch() at sched_switch+0xf1
>>> mi_switch() at mi_switch+0x18f
>>> turnstile_wait() at turnstile_wait+0x1cf
>>> _mtx_lock_sleep() at _mtx_lock_sleep+0x76
>>> syncache_lookup() at syncache_lookup+0x176
>>> syncache_expand() at syncache_expand+0x38
>>> tcp_input() at tcp_input+0xa7d
>>> ip_input() at ip_input+0xa8
>>> ether_demux() at ether_demux+0x1b9
>>> ether_input() at ether_input+0x1bb
>>> fxp_intr() at fxp_intr+0x233
>>> ithread_loop() at ithread_loop+0x17f
>>> fork_exit() at fork_exit+0x11f
>>> fork_trampoline() at fork_trampoline+0xe
>>> ____
>>>
>>> A "where" on a process stuck in "*tcp", in this case "[swi4: clock]",
>>> gave the somewhat similar:
>>> ____
>>>
>>> sched_switch() at sched_switch+0xf1
>>> mi_switch() at mi_switch+0x18f
>>> turnstile_wait() at turnstile_wait+0x1cf
>>> _rw_rlock() at _rw_rlock+0x8c
>>> ipfw_chk() at ipfw_chk+0x3ab2
>>> ipfw_check_out() at ipfw_check_out+0xb1
>>> pfil_run_hooks() at pfil_run_hooks+0x9c
>>> ip_output() at ip_output+0x367
>>> syncache_respond() at syncache_respond+0x2fd
>>> syncache_timer() at syncache_timer+0x15a
>>> (...)
>>> ____
>>>
>>> In this particular case, the fxp0 card is in a lagg with rl0, but this
>>> problem can be triggered with either card on their own...
>>>
>>> The scheduler is SCHED_ULE.
>>>
>>> I'm not too sure how to give more useful information that this, I'm
>>> afraid. It's a custom kernel, too... Do I need to supply information on
>>> what code actually exists at the relevant addresses (I'm not at all
>>> clued in on how to do this... Sorry!)? Should I chuck WITNESS,
>>> INVARIANTS et al. in?
>>>
>>> I *think* every time this has been triggered there's been a "python2.5"
>>> process in the "*tcp" state. This machine runs net-p2p/deluge and
>>> generally has at least 100 TCP connections on the go at any given time.
>>>
>>> Can anyone give me a clue as to what I might do to track this down?
>>> Appreciate any pointers.
>>> --
>>> Nick Withers
>>> email: nick@nickwithers.com
>>> Web: http://www.nickwithers.com
>>> Mobile: +61 414 397 446
>>>
> -- 
> Nick Withers
> email: nick@nickwithers.com
> Web: http://www.nickwithers.com
> Mobile: +61 414 397 446
>
From ardovm at yahoo.it  Fri Mar 13 05:25:01 2009
From: ardovm at yahoo.it (Arrigo Marchiori)
Date: Fri Mar 13 05:25:08 2009
Subject: Page fault panic in scioctl and console-kit-daemon
In-Reply-To: <DB49F4B8-9E0E-4219-BB58-04F6644D10A5@online.fr>
References: <DB49F4B8-9E0E-4219-BB58-04F6644D10A5@online.fr>
Message-ID: <20090313122457.GD20585@snail.casa>

On Mon, Mar 09, 2009 at 12:15:15PM +0100, spara wrote:

> Hello,
> I'm experiencing the same 
> (http://www.mail-archive.com/freebsd-stable@freebsd.org/msg101997.html) 
> after updating to last hald in 6.4-STABLE.
> Anyone tried to fix it with the Kostik Belousov patch as in 
> http://lists.freebsd.org/pipermail/freebsd-current/2008-January/082581.html 
> ?

You mean the patch attached to this message:
http://lists.freebsd.org/pipermail/freebsd-current/2008-February/083586.html
? If so, I didn't try because the message says "committed to all
branches". But I can try, if it's necessary...

> Any other fix ?

It seems to me that no package has been depending on consolekit, since
a couple of days. At least, portupgrade is not showing any more "stale
dependencies" when I try to "portupgrade -aR" without having
consolekit installed. So I'm living happily without it. :-)
-- 
rigo

http://rigo.altervista.org
From to.my.trociny at gmail.com  Fri Mar 13 08:47:34 2009
From: to.my.trociny at gmail.com (Mikolaj Golub)
Date: Fri Mar 13 08:47:41 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <1236938184.1490.40.camel@localhost> (Nick Withers's message of
	"Fri\, 13 Mar 2009 20\:56\:24 +1100")
References: <1236920519.1490.30.camel@localhost>
	<alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
	<1236938184.1490.40.camel@localhost>
Message-ID: <813adha1tw.fsf@zhuzha.ua1>

On Fri, 13 Mar 2009 20:56:24 +1100 Nick Withers wrote:

> I'm sorry to ask what is probably a very simple question, but is there
> somewhere I should look to get clues on debugging from a manually
> generated dump? I tried "panic" after manually envoking the kernel
> debugger but proved highly inept at getting from the dump the same
> information "ps" / "where" gave me within the debugger live.

You can capture ddb session in capture buffer and then extract it from the
dump. In ddb run

capture on

do your debugging

then run "panic" or "call doadump" and after reboot:

ddb capture -M /var/crash/vmcore.X print > out

I would recommend to increase debug.ddb.capture.bufsize sysctl variable to be
sure all the ddb session will be captured.

-- 
Mikolaj Golub
From aoyama at peach.ne.jp  Fri Mar 13 09:04:17 2009
From: aoyama at peach.ne.jp (Daisuke Aoyama)
Date: Fri Mar 13 09:04:28 2009
Subject: Tester wanted for multipath failover iSCSI target software
References: <E1LhlmY-000EFM-Io@dilbert.ticketswitch.com>
Message-ID: <9D628199E66F424A80D214FA277EEEA3@artemis>

> Oh dear.... doing the test again caused the client machine to panic,
> with the following message:
>
> panic: solaris assert: 0 == dmu_buf_hold(os, lr->lr_foid, boff, zgd, &db), 
> file 
> /usr/src/sys/modules/zfs/../../cddl/controb/opensolaris/uts/common/fs/zfs/zfs_nops.c, 
> line: 955
>

I have not read the message in my experience.
Do you have encountered frequency?

--
Daisuke Aoyama

From petefrench at ticketswitch.com  Fri Mar 13 09:30:25 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri Mar 13 09:30:32 2009
Subject: Tester wanted for multipath failover iSCSI target software
In-Reply-To: <9D628199E66F424A80D214FA277EEEA3@artemis>
Message-ID: <E1LiAGx-000JwA-Ho@dilbert.ticketswitch.com>

> I have not read the message in my experience.
> Do you have encountered frequency?

Only once. I did not try it again because that is our work server.
I did two testrs, copying files.

1) Using iscsi-target ... copies OK, but ZFS pool has errors
2) Using istgt - causes the panic described.

The copy is 53 gigabytes of small files.

-pete.
From scf at FreeBSD.org  Fri Mar 13 13:49:17 2009
From: scf at FreeBSD.org (Sean C. Farley)
Date: Fri Mar 13 13:49:24 2009
Subject: Panic in radeon_get_vblank_counter()
Message-ID: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>

After upgrading my laptop (Dell 600m) yesterday, I have begun to 
experience panics on it probably related to the DRM update.

Killing the X server by Ctrl-Alt-Backspace is a good way to lock the 
system.  Reboot to get a core dump.

Piece of Xorg.log concerning the hardware using the 
xf86-video-ati-6.11.0 driver:
(--) PCI:*(0@1:0:0) ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] rev 1, Mem @ 0xe8000000/0, 0xfcff0000/0, I/O @ 0x0000c000/0, BIOS @ 0x????????/65536
...
(--) RADEON(0): Chipset: "ATI Radeon Mobility 9000 (M9) Lf (AGP)" (ChipID = 0x4c66)


Special options in xorg.conf:
Section "Device"
     ...
     Option     "EnablePageFlip"             "true"
     Option     "AccelMethod"                "EXA"
EndSection

Section "Screen"
     ...
     Option "AddARGBGLXVisuals" "True"
     Option "DisableGLXRootClipping" "True"
     Option "XAANoOffscreenPixmaps" "True"
     ...
EndSection


pciconf -lv of the device:
vgapci0@pci0:1:0:0:     class=0x030000 card=0x011e1028 chip=0x4c661002 rev=0x01 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'ATI MOBILITY RADEON 9000 (Microsoft Corporation - Radeon Mobility M9'
     class      = display
     subclass   = VGA


/var/log/messages about drm:
Mar 13 15:41:51 baba kernel: drm0: <ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI> on vgapci0
Mar 13 15:41:51 baba kernel: vgapci0: child drm0 requested pci_enable_busmaster
Mar 13 15:41:51 baba kernel: info: [drm] AGP at 0xe0000000 128MB
Mar 13 15:41:51 baba kernel: info: [drm] Initialized radeon 1.29.0 20080613
Mar 13 15:41:52 baba kernel: info: [drm] Setting GART location based on new memory map
Mar 13 15:41:52 baba kernel: info: [drm] Loading R200 Microcode
Mar 13 15:41:52 baba kernel: info: [drm] writeback test succeeded in 1 usecs
Mar 13 15:41:52 baba kernel: drm0: [ITHREAD]


Panic attached.

Sean
-- 
scf@FreeBSD.org
-------------- next part --------------
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0x10
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc341eb48
stack pointer	        = 0x28:0xc2b2bc3c
frame pointer	        = 0x28:0xc2b2bc4c
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 13 (swi4: clock sio)
trap number		= 12
panic: page fault
cpuid = 0
Uptime: 12h18m28s
Physical memory: 503 MB
Dumping 99 MB: 84 68 52 36 20 4

Reading symbols from /boot/kernel/if_tap.ko...Reading symbols from /boot/kernel/if_tap.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_tap.ko
Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/kernel/snd_ich.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_ich.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/atapicam.ko
Reading symbols from /boot/kernel/aio.ko...Reading symbols from /boot/kernel/aio.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/aio.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/linsysfs.ko...Reading symbols from /boot/kernel/linsysfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linsysfs.ko
Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /boot/kernel/pflog.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pflog.ko
Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pf.ko
Reading symbols from /boot/kernel/daemon_saver.ko...Reading symbols from /boot/kernel/daemon_saver.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/daemon_saver.ko
Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/kernel/radeon.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/radeon.ko
Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/drm.ko
#0  doadump () at pcpu.h:196
196	pcpu.h: No such file or directory.
	in pcpu.h
(kgdb) where
#0  doadump () at pcpu.h:196
#1  0xc05b6fe7 in boot (howto=260) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_shutdown.c:418
#2  0xc05b72b9 in panic (fmt=Variable "fmt" is not available.
) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_shutdown.c:574
#3  0xc082417c in trap_fatal (frame=0xc2b2bbfc, eva=16) at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/trap.c:939
#4  0xc08243e0 in trap_pfault (frame=0xc2b2bbfc, usermode=0, eva=16) at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/trap.c:852
#5  0xc0824d72 in trap (frame=0xc2b2bbfc) at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/trap.c:530
#6  0xc0809e3b in calltrap () at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/exception.s:159
#7  0xc341eb48 in radeon_get_vblank_counter (dev=0xc2dec800, crtc=0) at /usr/FreeBSD/RELENG_7/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:308
#8  0xc3445f7b in vblank_disable_fn (arg=0xc2dec800) at /usr/FreeBSD/RELENG_7/src/sys/modules/drm/drm/../../../dev/drm/drm_irq.c:91
#9  0xc05c9a4a in softclock (dummy=0x0) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_timeout.c:274
#10 0xc0594fdb in ithread_loop (arg=0xc2c95350) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_intr.c:1088
#11 0xc0591b29 in fork_exit (callout=0xc0594e20 <ithread_loop>, arg=0xc2c95350, frame=0xc2b2bd38) at /usr/FreeBSD/RELENG_7/src/sys/kern/kern_fork.c:810
#12 0xc0809eb0 in fork_trampoline () at /usr/FreeBSD/RELENG_7/src/sys/i386/i386/exception.s:264
(kgdb) frame 7
#7  0xc341eb48 in radeon_get_vblank_counter (dev=0xc2dec800, crtc=0) at /usr/FreeBSD/RELENG_7/src/sys/modules/drm/radeon/../../../dev/drm/radeon_irq.c:308
308				return RADEON_READ(RADEON_CRTC_CRNT_FRAME);
(kgdb) p *dev
$1 = {driver = 0xc33d6700, id_entry = 0xc3434930, pci_device = 19558, pci_vendor = 4098, unique = 0x0, unique_len = 0, device = 0xc2d5b080, devnode = 0xc33d6800, if_version = 677316843, flags = 3, vbl_lock = {
    lock_object = {lo_name = 0xc3449f37 "drmvbl", lo_type = 0xc3449f37 "drmvbl", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 3267987088, 
    mtx_recurse = 0}, dma_lock = {lock_object = {lo_name = 0xc3449bc1 "drmdma", lo_type = 0xc3449bc1 "drmdma", lo_flags = 16908288, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, 
    mtx_lock = 6, mtx_recurse = 0}, irq_lock = {lock_object = {lo_name = 0xc3449f30 "drmirq", lo_type = 0xc3449f30 "drmirq", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, 
        lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, dev_lock = {lock_object = {lo_name = 0xc3449f29 "drmdev", lo_type = 0xc3449f29 "drmdev", lo_flags = 16973824, lo_witness_data = {lod_list = {
          stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, drw_lock = {lock_object = {lo_name = 0xc3449f3e "drmdrw", lo_type = 0xc3449f3e "drmdrw", lo_flags = 16973824, lo_witness_data = {
        lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, open_count = 0, buf_use = 8, counters = 6, types = {_DRM_STAT_LOCK, _DRM_STAT_OPENS, _DRM_STAT_CLOSES, 
    _DRM_STAT_IOCTLS, _DRM_STAT_LOCKS, _DRM_STAT_UNLOCKS, _DRM_STAT_LOCK, _DRM_STAT_LOCK, _DRM_STAT_LOCK, _DRM_STAT_LOCK, _DRM_STAT_LOCK, _DRM_STAT_LOCK, _DRM_STAT_LOCK, _DRM_STAT_LOCK, _DRM_STAT_LOCK}, 
  counts = {0, 10, 10, 1935582, 1854, 78, 0, 0, 0, 0, 0, 0, 0, 0, 0}, files = {tqh_first = 0x0, tqh_last = 0xc2dec920}, magiclist = {{head = 0x0, tail = 0x0} <repeats 16 times>}, maplist = {tqh_first = 0x0, 
    tqh_last = 0xc2dec9a8}, context_sareas = 0xc2eee450, max_context = 4, lock = {hw_lock = 0x0, file_priv = 0x0, lock_queue = 0, lock_time = 5360133}, dma = 0x0, irq = 11, irq_enabled = 0, msi_enabled = 0, 
  irqrid = 0, irqr = 0xc315c480, irqh = 0xc33cc800, pcir = {0xc2d69c40, 0x0, 0xc2d69b80}, pcirid = {16, 0, 24}, pci_domain = 0, pci_bus = 1, pci_slot = 0, pci_func = 0, context_flag = 0, last_context = 0, 
  vblank_disable_allowed = 1, vbl_signal_pending = 0, vblank_disable_timer = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0xc29a6e08}}, c_time = 44312063, c_arg = 0xc2dec800, 
    c_func = 0xc3445ef0 <vblank_disable_fn>, c_mtx = 0xc2dec824, c_flags = 0}, max_vblank_count = 2097151, vblank = 0xc315c680, num_crtcs = 2, buf_sigio = 0x0, sysctl = 0xc2eee520, agp = 0xc315c6c0, sg = 0x0, 
  ctx_bitmap = 0xc3239000, dev_private = 0xc2da4800, agp_buffer_token = 3759153152, agp_buffer_map = 0x0, drw_unrhdr = 0xc315c740, drw_head = {rbh_root = 0x0}}
(kgdb) quit
From invite at scour.com  Fri Mar 13 14:54:14 2009
From: invite at scour.com (Scour)
Date: Fri Mar 13 14:54:50 2009
Subject: S. M. Ibrahim lavlu's Member Invite
Message-ID: <49bacc04c996b@scour.com>

Hey there,

Not too long ago S. M. Ibrahim lavlu sent you an invite to join the Scour
search community and your invite is still open!

The Scour search engine is shaped by a community of users just like you,
and your contributions are what make it a success!

Why use Scour?
1. Get Yahoo, Google and MSN results in one search
2. Vote on result relevancy
3. Read user comments
4. Get paid for searching!

Create your profile at http://scour.com/invite/lavluda/r/ and enjoy
searching the web through your favorite search engines. With time, you?ll
get paid like these loyal users: http://www.scour.com/leaderboard page.

Come and be part of the largest Social Search community and help make the
results better!

See you soon,
The Scour Team
www.scour.com





This message was sent to you as a friend referral to join scour.com, please
feel free to review our http://scour.com/privacy page and our
http://scour.com/communityguidelines/antispam page.
If you prefer not to receive invitations from ANY scour members,
please click here - http://www.scour.com/unsub/e/ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc=
-OR-
Write to us at:
Scour, Inc., 15303 Ventura Blvd. Suite 860, Sherman Oaks, CA 91403, USA.

campaignid: scour200903130002

From rnoland at FreeBSD.org  Fri Mar 13 19:30:47 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Fri Mar 13 19:30:54 2009
Subject: Panic in radeon_get_vblank_counter()
In-Reply-To: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>
References: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>
Message-ID: <1236997834.1735.30.camel@balrog.2hip.net>

On Fri, 2009-03-13 at 15:49 -0500, Sean C. Farley wrote:
> After upgrading my laptop (Dell 600m) yesterday, I have begun to 
> experience panics on it probably related to the DRM update.
> 
> Killing the X server by Ctrl-Alt-Backspace is a good way to lock the 
> system.  Reboot to get a core dump.
> 
> Piece of Xorg.log concerning the hardware using the 
> xf86-video-ati-6.11.0 driver:
> (--) PCI:*(0@1:0:0) ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] rev 1, Mem @ 0xe8000000/0, 0xfcff0000/0, I/O @ 0x0000c000/0, BIOS @ 0x????????/65536
> ...
> (--) RADEON(0): Chipset: "ATI Radeon Mobility 9000 (M9) Lf (AGP)" (ChipID = 0x4c66)
> 
> 
> Special options in xorg.conf:
> Section "Device"
>      ...
>      Option     "EnablePageFlip"             "true"
>      Option     "AccelMethod"                "EXA"
> EndSection
> 
> Section "Screen"
>      ...
>      Option "AddARGBGLXVisuals" "True"
>      Option "DisableGLXRootClipping" "True"
>      Option "XAANoOffscreenPixmaps" "True"
>      ...
> EndSection
> 
> 
> pciconf -lv of the device:
> vgapci0@pci0:1:0:0:     class=0x030000 card=0x011e1028 chip=0x4c661002 rev=0x01 hdr=0x00
>      vendor     = 'ATI Technologies Inc'
>      device     = 'ATI MOBILITY RADEON 9000 (Microsoft Corporation - Radeon Mobility M9'
>      class      = display
>      subclass   = VGA
> 
> 
> /var/log/messages about drm:
> Mar 13 15:41:51 baba kernel: drm0: <ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI> on vgapci0
> Mar 13 15:41:51 baba kernel: vgapci0: child drm0 requested pci_enable_busmaster
> Mar 13 15:41:51 baba kernel: info: [drm] AGP at 0xe0000000 128MB
> Mar 13 15:41:51 baba kernel: info: [drm] Initialized radeon 1.29.0 20080613
> Mar 13 15:41:52 baba kernel: info: [drm] Setting GART location based on new memory map
> Mar 13 15:41:52 baba kernel: info: [drm] Loading R200 Microcode
> Mar 13 15:41:52 baba kernel: info: [drm] writeback test succeeded in 1 usecs
> Mar 13 15:41:52 baba kernel: drm0: [ITHREAD]

Ok, I'll try to look at this soon... It would be useful if you could
enable hw.dri.0.debug=1 and send me the debug output as well, if you can
get anything useful before it locks up.

robert.

> 
> Panic attached.
> 
> Sean
> -- 
> scf@FreeBSD.org
> _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090314/ea730599/attachment.pgp
From scf at FreeBSD.org  Fri Mar 13 21:33:05 2009
From: scf at FreeBSD.org (Sean C. Farley)
Date: Fri Mar 13 21:33:12 2009
Subject: Panic in radeon_get_vblank_counter()
In-Reply-To: <1236997834.1735.30.camel@balrog.2hip.net>
References: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>
	<1236997834.1735.30.camel@balrog.2hip.net>
Message-ID: <alpine.BSF.2.00.0903132318050.1220@baba.farley.org>

On Fri, 13 Mar 2009, Robert Noland wrote:

> On Fri, 2009-03-13 at 15:49 -0500, Sean C. Farley wrote:
>> After upgrading my laptop (Dell 600m) yesterday, I have begun to 
>> experience panics on it probably related to the DRM update.
>>
>> Killing the X server by Ctrl-Alt-Backspace is a good way to lock the 
>> system.  Reboot to get a core dump.
>>
>> Piece of Xorg.log concerning the hardware using the
>> xf86-video-ati-6.11.0 driver:
>> (--) PCI:*(0@1:0:0) ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] rev 1, Mem @ 0xe8000000/0, 0xfcff0000/0, I/O @ 0x0000c000/0, BIOS @ 0x????????/65536
>> ...
>> (--) RADEON(0): Chipset: "ATI Radeon Mobility 9000 (M9) Lf (AGP)" (ChipID = 0x4c66)
>>
>>
>> Special options in xorg.conf:
>> Section "Device"
>>      ...
>>      Option     "EnablePageFlip"             "true"
>>      Option     "AccelMethod"                "EXA"
>> EndSection
>>
>> Section "Screen"
>>      ...
>>      Option "AddARGBGLXVisuals" "True"
>>      Option "DisableGLXRootClipping" "True"
>>      Option "XAANoOffscreenPixmaps" "True"
>>      ...
>> EndSection
>>
>>
>> pciconf -lv of the device:
>> vgapci0@pci0:1:0:0:     class=0x030000 card=0x011e1028 chip=0x4c661002 rev=0x01 hdr=0x00
>>      vendor     = 'ATI Technologies Inc'
>>      device     = 'ATI MOBILITY RADEON 9000 (Microsoft Corporation - Radeon Mobility M9'
>>      class      = display
>>      subclass   = VGA
>>
>>
>> /var/log/messages about drm:
>> Mar 13 15:41:51 baba kernel: drm0: <ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI> on vgapci0
>> Mar 13 15:41:51 baba kernel: vgapci0: child drm0 requested pci_enable_busmaster
>> Mar 13 15:41:51 baba kernel: info: [drm] AGP at 0xe0000000 128MB
>> Mar 13 15:41:51 baba kernel: info: [drm] Initialized radeon 1.29.0 20080613
>> Mar 13 15:41:52 baba kernel: info: [drm] Setting GART location based on new memory map
>> Mar 13 15:41:52 baba kernel: info: [drm] Loading R200 Microcode
>> Mar 13 15:41:52 baba kernel: info: [drm] writeback test succeeded in 1 usecs
>> Mar 13 15:41:52 baba kernel: drm0: [ITHREAD]
>
> Ok, I'll try to look at this soon... It would be useful if you could 
> enable hw.dri.0.debug=1 and send me the debug output as well, if you 
> can get anything useful before it locks up.

I have not had luck reproducing a panic, but I can get the computer to 
lock up at startup of the X server (rarely) and shutdown (often).

This may not be accurate, but I think I am able to shutdown safely if I 
switch to a tty and wait until this debug line is printed:
[drm:pid13:vblank_disable_fn] vblank_disable_allowed=1

If I start rebooting before it is printed, the system locks up.  Of 
course, this is only after rebooting several times.

Here is a successful start and shutdown:
http://people.freebsd.org/~scf/drm-dmesg.log
http://people.freebsd.org/~scf/Xorg.0.log

Does that help?

Sean
-- 
scf@FreeBSD.org
From rnoland at FreeBSD.org  Sat Mar 14 00:38:57 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sat Mar 14 00:39:04 2009
Subject: Panic in radeon_get_vblank_counter()
In-Reply-To: <alpine.BSF.2.00.0903132318050.1220@baba.farley.org>
References: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>
	<1236997834.1735.30.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903132318050.1220@baba.farley.org>
Message-ID: <1237016323.1789.13.camel@balrog.2hip.net>

On Fri, 2009-03-13 at 23:33 -0500, Sean C. Farley wrote: 
> On Fri, 13 Mar 2009, Robert Noland wrote:
> 
> > On Fri, 2009-03-13 at 15:49 -0500, Sean C. Farley wrote:
> >> After upgrading my laptop (Dell 600m) yesterday, I have begun to 
> >> experience panics on it probably related to the DRM update.
> >>
> >> Killing the X server by Ctrl-Alt-Backspace is a good way to lock the 
> >> system.  Reboot to get a core dump.
> >>
> >> Piece of Xorg.log concerning the hardware using the
> >> xf86-video-ati-6.11.0 driver:
> >> (--) PCI:*(0@1:0:0) ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] rev 1, Mem @ 0xe8000000/0, 0xfcff0000/0, I/O @ 0x0000c000/0, BIOS @ 0x????????/65536
> >> ...
> >> (--) RADEON(0): Chipset: "ATI Radeon Mobility 9000 (M9) Lf (AGP)" (ChipID = 0x4c66)
> >>
> >>
> >> Special options in xorg.conf:
> >> Section "Device"
> >>      ...
> >>      Option     "EnablePageFlip"             "true"
> >>      Option     "AccelMethod"                "EXA"
> >> EndSection
> >>
> >> Section "Screen"
> >>      ...
> >>      Option "AddARGBGLXVisuals" "True"
> >>      Option "DisableGLXRootClipping" "True"
> >>      Option "XAANoOffscreenPixmaps" "True"
> >>      ...
> >> EndSection
> >>
> >>
> >> pciconf -lv of the device:
> >> vgapci0@pci0:1:0:0:     class=0x030000 card=0x011e1028 chip=0x4c661002 rev=0x01 hdr=0x00
> >>      vendor     = 'ATI Technologies Inc'
> >>      device     = 'ATI MOBILITY RADEON 9000 (Microsoft Corporation - Radeon Mobility M9'
> >>      class      = display
> >>      subclass   = VGA
> >>
> >>
> >> /var/log/messages about drm:
> >> Mar 13 15:41:51 baba kernel: drm0: <ATI Radeon Lf RV250 Mobility 9000 M9 / FireMV 2400 PCI> on vgapci0
> >> Mar 13 15:41:51 baba kernel: vgapci0: child drm0 requested pci_enable_busmaster
> >> Mar 13 15:41:51 baba kernel: info: [drm] AGP at 0xe0000000 128MB
> >> Mar 13 15:41:51 baba kernel: info: [drm] Initialized radeon 1.29.0 20080613
> >> Mar 13 15:41:52 baba kernel: info: [drm] Setting GART location based on new memory map
> >> Mar 13 15:41:52 baba kernel: info: [drm] Loading R200 Microcode
> >> Mar 13 15:41:52 baba kernel: info: [drm] writeback test succeeded in 1 usecs
> >> Mar 13 15:41:52 baba kernel: drm0: [ITHREAD]
> >
> > Ok, I'll try to look at this soon... It would be useful if you could 
> > enable hw.dri.0.debug=1 and send me the debug output as well, if you 
> > can get anything useful before it locks up.
> 
> I have not had luck reproducing a panic, but I can get the computer to 
> lock up at startup of the X server (rarely) and shutdown (often).
> 
> This may not be accurate, but I think I am able to shutdown safely if I 
> switch to a tty and wait until this debug line is printed:
> [drm:pid13:vblank_disable_fn] vblank_disable_allowed=1

Actually, vblank_disable_allowed should be 0 when you have switched out
to a vt..

> If I start rebooting before it is printed, the system locks up.  Of 
> course, this is only after rebooting several times.
> 
> Here is a successful start and shutdown:
> http://people.freebsd.org/~scf/drm-dmesg.log
> http://people.freebsd.org/~scf/Xorg.0.log

Ok, I'll spend some time staring at the current code... Thanks for the
backtrace too, it's nice to get those...

robert.

> Does that help?
> 
> Sean
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090314/c2568820/attachment.pgp
From nick at nickwithers.com  Sat Mar 14 01:51:07 2009
From: nick at nickwithers.com (Nick Withers)
Date: Sat Mar 14 01:51:14 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <alpine.BSF.2.00.0903130949210.61873@fledge.watson.org>
References: <1236920519.1490.30.camel@localhost>
	<alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
	<alpine.BSF.2.00.0903130949210.61873@fledge.watson.org>
Message-ID: <1237020646.1532.24.camel@localhost>

On Fri, 2009-03-13 at 09:49 +0000, Robert Watson wrote:
> On Fri, 13 Mar 2009, Robert Watson wrote:
> 
> > Sounds like a lock leak -- if you're running INVARIANTS, then "show allocks"
>                                                   ^^^^ should read WITNESS
> > and "show allchains" would be useful.  I've had a report of a TCP lock leak 
> > possibly in tcp_input(), but haven't managed to track it down yet -- this 
> > could well be it as well.

Right, here we go!

Here's "show alllocks"' output:
____

Process 31 (irp20: fxp0+) thread 0xffffff00012016e0 (100030)
exclusive rw tcpinp r = 0 (0xffffff000392d570) locked
@ /usr/src/sys/netinet/tcp_input.c:480
exclusive rw tcp r = 0 (0xffffffff806dcbe8) locked
@ /usr/src/sys/netinet/tcp_input.c:400
Process 17 (swi6: Giant taskq) thread 0xffffff0001173000 (100016)
exclusive sleep mutex Giant r = 0 (0xffffffff80652520) locked
@ /usr/src/sys/kern/kern_intr.c:1087
Process 12 (swi4: clock) thread 0xffffff00010c6370 (100003)
shared rw IPFW static rules r = 0 (0xffffffff806db2b8) locked
@ /usr/src/sys/netinet/ip_fw2.c:2460
shared rw PFil hoow read/write mutex r = 0 (0xffffffff806dba28) locked
@ /usr/src/sys/net/pfil.c:73
exclusive sleep mutex tcp_sc_head r = 0 (0xfffffffe8036c8f8) locked
@ /usr/src/sys/kern/kern_timeout.c:241
____

...and here's "show allchains"':
____

chain 1:
 thread 100031 (pid 32, irp22: rl0) blocked on lock 0xffffffff806dcbe8
(rw) "tcp"
 thread 100030 (pid 31, irq20: fxp0+) blocked on lock 0xfffffffe8036c8f8
(sleep mutex) "tcp_sc_head"
 thread 100003 (pid 12, swi4: clock) blocked on lock 0xffffffff806dcbe8
(rw) "tcp"
 thread 100030 (pid 31, irq20: fxp0+) blocked on lock 0xfffffffe8036c8f8
(sleep mutex) "tcp_sc_head"
 thread 100003 (pid 12, swi4: clock) blocked on lock 0xffffffff806dcbe8
(rw) "tcp"
 thread 100030 (pid 31, irq20: fxp0+) blocked on lock 0xfffffffe8036c8f8
(sleep mutex) "tcp_sc_head"
 thread 100003 (pid 12, swi4: clock) blocked on lock 0xffffffff806dcbe8
(rw) "tcp"
(...and so on, these last two seeming to go on forever.)
____

This is with fxp0 and rl0 lagg(4)-ed

For completeness...
  - "ps" in DDB shows that:
    - PID 32 ("[irp22: rl0]") is in state "LL" on "*tcp"
    - PID 31 ("[irq20: fxp0+]") is in state "LL" on "*tcp_sc_h"
    - PID 12 ("[swi4: clock]") is in state "LL" on "*tcp"
  - "where 32" gives:
____

sched_switch() at sched_switch+0xdf
mi_switch() at mi_switch+0x18b
turnstile_wait() at turnstile_wait+0x1c4
_rw_lock_hard() at _rw_lock_hard+0xa3
_rw_wlock() at _rw_wlock+0x54
tcp_input() at tcp_input+0x318
ip_input() at ip_input+0xaf
ether_demux() at ether_demux+0x1b9
ether_input() at ether_input+0x1bb
rl_rxeof() at rl_rxeof+0x1c8
rl_intr() at rl_intr+0x138
ithread_loop() at ithread_loop+0xe9
fork_exit() at fork_exit+0x112
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffe91e0cd30, rbp = 0 ---
____

  - "where 31" gives:
____

Tracing PID 31 tid 100030 td 0xffffff00012016e0
sched_switch() at sched_switch+0xdf
mi_switch() at mi_switch+0x18b
turnstile_wait() at turnstile_wait+0x1c4
_mtx_lock_sleep() at _mtx_lock_sleep+0x76
_mtx_lock_flags() at _mtx_lock_flags+0x95
syncache_lookup() at syncache_lookup+0xee
syncache_expand() at syncache_expand+0x38
tcp_input() at tcp_input+0x99b
ip_input() at ip_input+0xaf
ether_demux() at ether_demux+0x1b9
ether_input() at ether_input+0x1bb
fxp_intr() at fxp_intr+0x224
ithread_loop() at ithread_loop+0xe9
fork_exit() at fork_exit+0x112
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffe80174d30, rbp = 0 ---
____

  - "where 12" gives:
____

sched_switch() at sched_switch+0xdf
mi_switch() at mi_switch+0x18b
turnstile_wait() at turnstile_wait+0x1c4
_rw_rlock() at _rw_rlock+0x9c
ipfw_chk() at ipfw_chk+0x3ac1
ipfw_check_out() at ipfw_check_out+0xb1
pfil_run_hooks() at pfil_run_hooks+0xac
ip_output() at ip_output+0x357
syncache_respond() at syncache_respond+0x2fd
syncache_timer() at syncache_timer+0x15a
softclock() at softclock+0x270
ithread_loop() at ithread_loop+0xe9
fork_exit() at fork_exit+0x112
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffe80017d30, rbp = 0 ---
____

  - Before having entered the debugger, the following were logged:
____

lock order reversal:
 1st 0xffffff00032947b0 tcpinp (tcpinp)
@ /usr/src/sys/netinet/tcp_timer.c:169
 2nd 0xffffffff806dba28 PFil hook read/write mutex (PFil hook read/write
mutex) @ /usr/src/sys/net/pfil.c:73
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
witness_checkorder() at witness_checkorder+0x565
_rw_rlock() at _rw_rlock+0x25
pfil_run_hooks() at pfil_run_hooks+0x44
ip_output() at ip_output+0x357
tcp_output() at tcp_output+0xa1d
tcp_timer_delack() at tcp_timer_delack+0xc7
softclock() at softclock+0x270
ithread_loop() at ithread_loop+0xe9
fork_exit() at fork_exit+0x112
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffe80017d30, rbp = 0 ---
____

...and:
____

lock order reversal:
 1st 0xfffffffe80365df0 tcp_sc_head (tcp_sc_head)
@ /usr/src/sys/kern/kern_timeout.c:241
 2nd 0xffffffff806dba28 PFil hook read/write mutex (PFil hook read/write
mutex) @ /usr/src/sys/net/pfil.c:73
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
witness_checkorder() at witness_checkorder+0x565
_rw_rlock() at _rw_rlock+0x25
pfil_run_hooks() at pfil_run_hooks+0x44
ip_output() at ip_output+0x357
syncache_respond() at syncache_respond+0x2fd
syncache_timer() at syncache_timer+0x15a
softclock() at softclock+0x270
ithread_loop() at ithread_loop+0xe9
fork_exit() at fork_exit+0x112
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffe80017d30, rbp = 0 ---
____

On reboot:
____

lock order reversal:
 1st 0xffffffff806db2b8 IPFW static rules (IPFW static rules)
@ /usr/src/sys/netinet/ip_fw2.c:2460
 2nd 0xffffffff806dcbe8 tcp (tcp) @ /usr/src/sys/netinet/ip_fw2.c:2009
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
witness_checkorder() at witness_checkorder+0x565
_rw_rlock() at _rw_rlock+0x25
ipfw_chk() at ipfw_chk+0x3ac1
ipfw_check_out() at ipfw_check_out+0xb1
pfil_run_hooks() at pfil_run_hooks+0xac
ip_output() at ip_output+0x357
tcp_respond() at tcp_respond+0x33a
tcp_dropwithreset() at tcp_dropwithreset+0x131
tcp_do_segment() at tcp_do_segment+0xd93
tcp_input() at tcp_input+0x8dd
ip_input() at ip_input+0xaf
ether_demux() at ether_demux+0x1b9
ether_input() at ether_input+0x1bb
fxp_intr() at fxp_intr+0x224
ithread_loop() at ithread_loop+0xe9
fork_exit() at fork_exit+0x112
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xfffffffe80174d30, rbp = 0 ---
____

(Haven't actually checked whether any of these are known innocuous).

Anything else that might be useful?

> Robert N M Watson
> Computer Laboratory
> University of Cambridge
-- 
Nick Withers
email: nick@nickwithers.com
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090314/19098c4f/attachment.pgp
From rwatson at FreeBSD.org  Sat Mar 14 11:01:33 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sat Mar 14 11:01:41 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <1237020646.1532.24.camel@localhost>
References: <1236920519.1490.30.camel@localhost>
	<alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
	<alpine.BSF.2.00.0903130949210.61873@fledge.watson.org>
	<1237020646.1532.24.camel@localhost>
Message-ID: <alpine.BSF.2.00.0903141756100.27597@fledge.watson.org>


On Sat, 14 Mar 2009, Nick Withers wrote:

> Right, here we go!
...

Turns out that the problem is a lock cycle triggered by the syncache calling, 
indirectly, the firewall during output, and the firewall trying to look up the 
connection for the packet.  Thread one:

> Tracing PID 31 tid 100030 td 0xffffff00012016e0
> sched_switch() at sched_switch+0xdf
> mi_switch() at mi_switch+0x18b
> turnstile_wait() at turnstile_wait+0x1c4
> _mtx_lock_sleep() at _mtx_lock_sleep+0x76
> _mtx_lock_flags() at _mtx_lock_flags+0x95
> syncache_lookup() at syncache_lookup+0xee
> syncache_expand() at syncache_expand+0x38
> tcp_input() at tcp_input+0x99b
> ip_input() at ip_input+0xaf
> ether_demux() at ether_demux+0x1b9
> ether_input() at ether_input+0x1bb
> fxp_intr() at fxp_intr+0x224
> ithread_loop() at ithread_loop+0xe9
> fork_exit() at fork_exit+0x112
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xfffffffe80174d30, rbp = 0 ---

This thread holds TCP locks and is trying to acquire the syncache lock. 
Thread two:

> sched_switch() at sched_switch+0xdf
> mi_switch() at mi_switch+0x18b
> turnstile_wait() at turnstile_wait+0x1c4
> _rw_rlock() at _rw_rlock+0x9c
> ipfw_chk() at ipfw_chk+0x3ac1
> ipfw_check_out() at ipfw_check_out+0xb1
> pfil_run_hooks() at pfil_run_hooks+0xac
> ip_output() at ip_output+0x357
> syncache_respond() at syncache_respond+0x2fd
> syncache_timer() at syncache_timer+0x15a
> softclock() at softclock+0x270
> ithread_loop() at ithread_loop+0xe9
> fork_exit() at fork_exit+0x112
> fork_trampoline() at fork_trampoline+0xe

This is the syncache timer holding syncache locks, calling IP output, and IPFW 
trying to acquire TCP locks.

Am I right in thinking that you are using uid/gid/jail firewall rules?  They 
suffer from a fundamental architectural problem in that they require reaching 
"up" to a higher level of the stack at times when it's not always a good idea 
to do so.  In general we solve the problem by passing "down" the inpcb for a 
connection in the output path so that TCP doesn't have to look it up -- 
however, in the case of the syncache we actually don't have the inpcb easily 
in hand (or at least, we have it, but we can't just lock it because syncache 
locks are after TCP locks in the lock order...).  It transpires that what the 
firewall really wants is not the inpcb, but the credential, but those are 
interfaces we can't change right now.

I'll need to think a bit about a proper fix for this, but you'll find the 
problem likely goes away if you eliminate all uid/gid/jail rules from your 
firewall.  You could also tweak the syncache logic not to use a retransmit 
timer, which might slightly extend the time it takes for systems to connect to 
your host in the presence of packet loss, but would eliminate this 
transmission path entirely.  We'll need a real and more general fix, however, 
to commit, and I'll look and see what I can come up with.

Robert N M Watson
Computer Laboratory
University of Cambridge
From nick at nickwithers.com  Sat Mar 14 18:43:23 2009
From: nick at nickwithers.com (Nick Withers)
Date: Sat Mar 14 18:43:35 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <alpine.BSF.2.00.0903141756100.27597@fledge.watson.org>
References: <1236920519.1490.30.camel@localhost>
	<alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
	<alpine.BSF.2.00.0903130949210.61873@fledge.watson.org>
	<1237020646.1532.24.camel@localhost>
	<alpine.BSF.2.00.0903141756100.27597@fledge.watson.org>
Message-ID: <1237081381.1581.2.camel@localhost>

On Sat, 2009-03-14 at 18:01 +0000, Robert Watson wrote:
> On Sat, 14 Mar 2009, Nick Withers wrote:
> 
> > Right, here we go!
> ...
> 
> Turns out that the problem is a lock cycle triggered by the syncache calling, 
> indirectly, the firewall during output, and the firewall trying to look up the 
> connection for the packet.  Thread one:
> 
> > Tracing PID 31 tid 100030 td 0xffffff00012016e0
> > sched_switch() at sched_switch+0xdf
> > mi_switch() at mi_switch+0x18b
> > turnstile_wait() at turnstile_wait+0x1c4
> > _mtx_lock_sleep() at _mtx_lock_sleep+0x76
> > _mtx_lock_flags() at _mtx_lock_flags+0x95
> > syncache_lookup() at syncache_lookup+0xee
> > syncache_expand() at syncache_expand+0x38
> > tcp_input() at tcp_input+0x99b
> > ip_input() at ip_input+0xaf
> > ether_demux() at ether_demux+0x1b9
> > ether_input() at ether_input+0x1bb
> > fxp_intr() at fxp_intr+0x224
> > ithread_loop() at ithread_loop+0xe9
> > fork_exit() at fork_exit+0x112
> > fork_trampoline() at fork_trampoline+0xe
> > --- trap 0, rip = 0, rsp = 0xfffffffe80174d30, rbp = 0 ---
> 
> This thread holds TCP locks and is trying to acquire the syncache lock. 
> Thread two:
> 
> > sched_switch() at sched_switch+0xdf
> > mi_switch() at mi_switch+0x18b
> > turnstile_wait() at turnstile_wait+0x1c4
> > _rw_rlock() at _rw_rlock+0x9c
> > ipfw_chk() at ipfw_chk+0x3ac1
> > ipfw_check_out() at ipfw_check_out+0xb1
> > pfil_run_hooks() at pfil_run_hooks+0xac
> > ip_output() at ip_output+0x357
> > syncache_respond() at syncache_respond+0x2fd
> > syncache_timer() at syncache_timer+0x15a
> > softclock() at softclock+0x270
> > ithread_loop() at ithread_loop+0xe9
> > fork_exit() at fork_exit+0x112
> > fork_trampoline() at fork_trampoline+0xe
> 
> This is the syncache timer holding syncache locks, calling IP output, and IPFW 
> trying to acquire TCP locks.
> 
> Am I right in thinking that you are using uid/gid/jail firewall rules?

You are indeed.

> They 
> suffer from a fundamental architectural problem in that they require reaching 
> "up" to a higher level of the stack at times when it's not always a good idea 
> to do so.  In general we solve the problem by passing "down" the inpcb for a 
> connection in the output path so that TCP doesn't have to look it up -- 
> however, in the case of the syncache we actually don't have the inpcb easily 
> in hand (or at least, we have it, but we can't just lock it because syncache 
> locks are after TCP locks in the lock order...).  It transpires that what the 
> firewall really wants is not the inpcb, but the credential, but those are 
> interfaces we can't change right now.

Thanks for the explanation!

> I'll need to think a bit about a proper fix for this, but you'll find the 
> problem likely goes away if you eliminate all uid/gid/jail rules from your 
> firewall.  You could also tweak the syncache logic not to use a retransmit 
> timer, which might slightly extend the time it takes for systems to connect to 
> your host in the presence of packet loss, but would eliminate this 
> transmission path entirely.  We'll need a real and more general fix, however, 
> to commit, and I'll look and see what I can come up with.

Brilliant, thanks very much. I'll work without uid rules for the time
being, then.

Ta for your time and help on this!

> Robert N M Watson
> Computer Laboratory
> University of Cambridge
-- 
Nick Withers
email: nick@nickwithers.com
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090315/c3eddc24/attachment.pgp
From jashari at live.co.uk  Sun Mar 15 00:48:32 2009
From: jashari at live.co.uk (jashari)
Date: Sun Mar 15 00:49:09 2009
Subject: visit dhis baners
Message-ID: <20090315074830.AA896808F8A@everest.scorpionshops.com>


   [1]Musicload 
   [2]First Affair - Erotische Abenteuer & Seitensprünge 
   [3]www.s-partnerclub.de 
   [4]C-Date your casual dating site 
   [5]Liebe.de - Die Datingplattform 
   [6]Erotikabenteuer gesucht? Dann kommen sie zu LOVEPOINT.de 
   [7]PARSHIP.de - Die Online Partneragentur 
   [8]girls.parship.de 
   [9]StayFriends - Die Freundesuchmaschine 
   [10]Das groÃe iPhone Gewinnspiel 
   [11]Hummer Gewinnspiel 
   [12]Spanien Gewinnspiel 

References

   1. http://partners.webmasterplan.com/click.asp?ref=480282&site=3752&type=b74&bnb=74
   2. http://partners.webmasterplan.com/click.asp?ref=480282&site=3211&type=b8&bnb=8
   3. http://partners.webmasterplan.com/click.asp?ref=480282&site=5615&type=b18&bnb=18
   4. http://partners.webmasterplan.com/click.asp?ref=480282&site=5597&type=b16&bnb=16
   5. http://partners.webmasterplan.com/click.asp?ref=480282&site=5704&type=b14&bnb=14
   6. http://partners.webmasterplan.com/click.asp?ref=480282&site=623&type=b50&bnb=50
   7. http://partners.webmasterplan.com/click.asp?ref=480282&site=3629&type=b1&bnb=1
   8. http://partners.webmasterplan.com/click.asp?ref=480282&site=4150&type=b9&bnb=9
   9. http://partners.webmasterplan.com/click.asp?ref=480282&site=3735&type=b33&bnb=33
  10. http://partners.webmasterplan.com/click.asp?ref=480282&site=5671&type=b101&bnb=101
  11. http://partners.webmasterplan.com/click.asp?ref=480282&site=5567&type=b10&bnb=10
  12. http://partners.webmasterplan.com/click.asp?ref=480282&site=5566&type=b9&bnb=9
From jashari at live.co.uk  Sun Mar 15 00:48:39 2009
From: jashari at live.co.uk (jashari)
Date: Sun Mar 15 00:49:10 2009
Subject: visit dhis baners
Message-ID: <20090315074838.02E07808FA7@everest.scorpionshops.com>


   [1]Musicload 
   [2]First Affair - Erotische Abenteuer & Seitensprünge 
   [3]www.s-partnerclub.de 
   [4]C-Date your casual dating site 
   [5]Liebe.de - Die Datingplattform 
   [6]Erotikabenteuer gesucht? Dann kommen sie zu LOVEPOINT.de 
   [7]PARSHIP.de - Die Online Partneragentur 
   [8]girls.parship.de 
   [9]StayFriends - Die Freundesuchmaschine 
   [10]Das groÃe iPhone Gewinnspiel 
   [11]Hummer Gewinnspiel 
   [12]Spanien Gewinnspiel 

References

   1. http://partners.webmasterplan.com/click.asp?ref=480282&site=3752&type=b74&bnb=74
   2. http://partners.webmasterplan.com/click.asp?ref=480282&site=3211&type=b8&bnb=8
   3. http://partners.webmasterplan.com/click.asp?ref=480282&site=5615&type=b18&bnb=18
   4. http://partners.webmasterplan.com/click.asp?ref=480282&site=5597&type=b16&bnb=16
   5. http://partners.webmasterplan.com/click.asp?ref=480282&site=5704&type=b14&bnb=14
   6. http://partners.webmasterplan.com/click.asp?ref=480282&site=623&type=b50&bnb=50
   7. http://partners.webmasterplan.com/click.asp?ref=480282&site=3629&type=b1&bnb=1
   8. http://partners.webmasterplan.com/click.asp?ref=480282&site=4150&type=b9&bnb=9
   9. http://partners.webmasterplan.com/click.asp?ref=480282&site=3735&type=b33&bnb=33
  10. http://partners.webmasterplan.com/click.asp?ref=480282&site=5671&type=b101&bnb=101
  11. http://partners.webmasterplan.com/click.asp?ref=480282&site=5567&type=b10&bnb=10
  12. http://partners.webmasterplan.com/click.asp?ref=480282&site=5566&type=b9&bnb=9
From fk at fabiankeil.de  Sun Mar 15 06:37:45 2009
From: fk at fabiankeil.de (Fabian Keil)
Date: Sun Mar 15 06:37:54 2009
Subject: Panic in radeon_get_vblank_counter()
In-Reply-To: <1237016323.1789.13.camel@balrog.2hip.net>
References: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>
	<1236997834.1735.30.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903132318050.1220@baba.farley.org>
	<1237016323.1789.13.camel@balrog.2hip.net>
Message-ID: <20090315142706.16ffca16@fabiankeil.de>

Robert Noland <rnoland@FreeBSD.org> wrote:

> On Fri, 2009-03-13 at 23:33 -0500, Sean C. Farley wrote: 
> > On Fri, 13 Mar 2009, Robert Noland wrote:

> > If I start rebooting before it is printed, the system locks up.  Of 
> > course, this is only after rebooting several times.
> > 
> > Here is a successful start and shutdown:
> > http://people.freebsd.org/~scf/drm-dmesg.log
> > http://people.freebsd.org/~scf/Xorg.0.log
> 
> Ok, I'll spend some time staring at the current code... Thanks for the
> backtrace too, it's nice to get those...

This seems to be the same panic I mentioned in the
"Filesystems being eaten?" thread on freebsd-current.

I reproducible got this panic on:
FreeBSD 8.0-CURRENT #39: Sat Mar  7 20:37:29 CET 2009
when shutting Xorg down. I can no longer reproduce it with:
FreeBSD 8.0-CURRENT #42: Sat Mar 14 00:47:09 CET 2009

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090315/89d36657/signature.pgp
From rnoland at FreeBSD.org  Sun Mar 15 10:07:25 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sun Mar 15 10:07:32 2009
Subject: Panic in radeon_get_vblank_counter()
In-Reply-To: <20090315142706.16ffca16@fabiankeil.de>
References: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>
	<1236997834.1735.30.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903132318050.1220@baba.farley.org>
	<1237016323.1789.13.camel@balrog.2hip.net>
	<20090315142706.16ffca16@fabiankeil.de>
Message-ID: <1237136828.1774.4.camel@balrog.2hip.net>

On Sun, 2009-03-15 at 14:27 +0100, Fabian Keil wrote:
> Robert Noland <rnoland@FreeBSD.org> wrote:
> 
> > On Fri, 2009-03-13 at 23:33 -0500, Sean C. Farley wrote: 
> > > On Fri, 13 Mar 2009, Robert Noland wrote:
> 
> > > If I start rebooting before it is printed, the system locks up.  Of 
> > > course, this is only after rebooting several times.
> > > 
> > > Here is a successful start and shutdown:
> > > http://people.freebsd.org/~scf/drm-dmesg.log
> > > http://people.freebsd.org/~scf/Xorg.0.log
> > 
> > Ok, I'll spend some time staring at the current code... Thanks for the
> > backtrace too, it's nice to get those...
> 
> This seems to be the same panic I mentioned in the
> "Filesystems being eaten?" thread on freebsd-current.
> 
> I reproducible got this panic on:
> FreeBSD 8.0-CURRENT #39: Sat Mar  7 20:37:29 CET 2009
> when shutting Xorg down. I can no longer reproduce it with:
> FreeBSD 8.0-CURRENT #42: Sat Mar 14 00:47:09 CET 2009

Hrm, ok... let's do this....

The only thing that I have that is in that window that isn't past the
MFC date I set, is the r600 code.  It's been in for a little over a week
now and hasn't killed anyone that I'm aware of, so I'll go ahead and
merge everything outstanding from -CURRENT.

robert.

> Fabian
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090315/23678e73/attachment.pgp
From rnoland at FreeBSD.org  Sun Mar 15 10:29:39 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sun Mar 15 10:29:46 2009
Subject: Panic in radeon_get_vblank_counter()
In-Reply-To: <20090315142706.16ffca16@fabiankeil.de>
References: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>
	<1236997834.1735.30.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903132318050.1220@baba.farley.org>
	<1237016323.1789.13.camel@balrog.2hip.net>
	<20090315142706.16ffca16@fabiankeil.de>
Message-ID: <1237138163.1774.5.camel@balrog.2hip.net>

On Sun, 2009-03-15 at 14:27 +0100, Fabian Keil wrote:
> Robert Noland <rnoland@FreeBSD.org> wrote:
> 
> > On Fri, 2009-03-13 at 23:33 -0500, Sean C. Farley wrote: 
> > > On Fri, 13 Mar 2009, Robert Noland wrote:
> 
> > > If I start rebooting before it is printed, the system locks up.  Of 
> > > course, this is only after rebooting several times.
> > > 
> > > Here is a successful start and shutdown:
> > > http://people.freebsd.org/~scf/drm-dmesg.log
> > > http://people.freebsd.org/~scf/Xorg.0.log
> > 
> > Ok, I'll spend some time staring at the current code... Thanks for the
> > backtrace too, it's nice to get those...
> 
> This seems to be the same panic I mentioned in the
> "Filesystems being eaten?" thread on freebsd-current.
> 
> I reproducible got this panic on:
> FreeBSD 8.0-CURRENT #39: Sat Mar  7 20:37:29 CET 2009
> when shutting Xorg down. I can no longer reproduce it with:
> FreeBSD 8.0-CURRENT #42: Sat Mar 14 00:47:09 CET 2009

Ok, everything from HEAD is merged... Give it a little while for the
mirrors to catch up and give it a shot.

robert.

> Fabian
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090315/a6db0b07/attachment.pgp
From rnoland at FreeBSD.org  Sun Mar 15 11:49:27 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sun Mar 15 11:49:33 2009
Subject: Radeon r6/7xx support merged to -STABLE
Message-ID: <1237142952.1774.22.camel@balrog.2hip.net>

I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago.

The current xorg drivers will not enable it by default on R600+ chips.
You will need to be using xf86-video-ati-6.12.0,
xf86-video-radeonhd-devel or possibly even better git master of either.

You will need to add the following to the Device section of your
xorg.conf to enable it.  If you are experiencing issues, commenting
these two options out, will prevent Xorg from auto-loading the kernel
module.

Options "DRI"
Options "AccelMethod" "EXA"

robert.

-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090315/76071ae8/attachment.pgp
From kostikbel at gmail.com  Sun Mar 15 14:33:29 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Mar 15 14:33:36 2009
Subject: Radeon r6/7xx support merged to -STABLE
In-Reply-To: <1237142952.1774.22.camel@balrog.2hip.net>
References: <1237142952.1774.22.camel@balrog.2hip.net>
Message-ID: <20090315213323.GH41617@deviant.kiev.zoral.com.ua>

On Sun, Mar 15, 2009 at 01:49:12PM -0500, Robert Noland wrote:
> I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago.
> 
> The current xorg drivers will not enable it by default on R600+ chips.
> You will need to be using xf86-video-ati-6.12.0,
> xf86-video-radeonhd-devel or possibly even better git master of either.
> 
> You will need to add the following to the Device section of your
> xorg.conf to enable it.  If you are experiencing issues, commenting
> these two options out, will prevent Xorg from auto-loading the kernel
> module.
> 
> Options "DRI"
> Options "AccelMethod" "EXA"

With this code and ati 6.12.0, I get the awful performance.
Kernel says
drm0: <ATI Radeon HD 2600 XT> on vgapci0
vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xd0020000
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.29.0 20080528
vgapci0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xc0000000
info: [drm] Setting GART location based on new memory map
error: [drm:pid1494:r600_do_init_cp] *ERROR* Need gart offset from userspace

Then, the Xorg.0.log
...
(II) RADEON(0): [drm] register handle = 0xd0020000
(II) RADEON(0): [dri] Visual configs initialized
(II) RADEON(0): RADEONRestoreMemMapRegisters() :
(II) RADEON(0):   MC_FB_LOCATION   : 0x00df00c0 0x00df00c0
(II) RADEON(0):   MC_AGP_LOCATION  : 0x003f0000
(==) RADEON(0): Backing store disabled
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] removed 1 reserved context for kernel
(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc731d000 at 0x286fd000
(II) RADEON(0): [drm] Closed DRM master.
(WW) RADEON(0): Direct rendering disabled
(EE) RADEON(0): Acceleration initialization failed
...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090315/f019286d/attachment.pgp
From peter.jeremy at alcatel-lucent.com.au  Sun Mar 15 19:14:17 2009
From: peter.jeremy at alcatel-lucent.com.au (Peter Jeremy)
Date: Sun Mar 15 19:14:25 2009
Subject: 7.1 panic "vm_page_startup: inconsistent page counts"
In-Reply-To: <200903120846.50630.jhb@freebsd.org>
References: <20090312043646.GB8352@pjdesk.au.alcatel-lucent.com>
	<200903120846.50630.jhb@freebsd.org>
Message-ID: <20090316021412.GI5857@pjdesk.au.alcatel-lucent.com>

On 2009-Mar-12 08:46:50 -0400, John Baldwin <jhb@freebsd.org> wrote:
>On Thursday 12 March 2009 12:36:46 am Peter Jeremy wrote:
>> I'm trying to upgrade an 11 month old FreeBSD 7 image in a VMware
>> 4.5.2 guest to an up-to-date -stable and it panics as above.  I've
>> added a printf to report the two counts and there's a difference of
>> one page.  I don't have any problems with the old 7-stable image or
>> up-to-date 6-stable or -current using the same VMware version.
>> 
>> A screendump for a verbose boot can be found at
>> http://imagebin.ca/img/wahNNw.gif
>> 
>> Can I safely delete the assert?
>
>I don't think so, I would report it to Alan.  The one earlier report of this 
>didn't include the detail that it was only off by one page.

This is a bit moot now since you've disabled the test but rolling back
to a kernel from 26th Feb (before the superpages MFC) doesn't have the
page count discrepancy.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090316/6869fb97/attachment.pgp
From rnoland at FreeBSD.org  Sun Mar 15 20:28:08 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Sun Mar 15 20:28:20 2009
Subject: Radeon r6/7xx support merged to -STABLE
In-Reply-To: <20090315213323.GH41617@deviant.kiev.zoral.com.ua>
References: <1237142952.1774.22.camel@balrog.2hip.net>
	<20090315213323.GH41617@deviant.kiev.zoral.com.ua>
Message-ID: <1237174073.18826.9.camel@balrog.2hip.net>

On Sun, 2009-03-15 at 23:33 +0200, Kostik Belousov wrote:
> On Sun, Mar 15, 2009 at 01:49:12PM -0500, Robert Noland wrote:
> > I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago.
> > 
> > The current xorg drivers will not enable it by default on R600+ chips.
> > You will need to be using xf86-video-ati-6.12.0,
> > xf86-video-radeonhd-devel or possibly even better git master of either.
> > 
> > You will need to add the following to the Device section of your
> > xorg.conf to enable it.  If you are experiencing issues, commenting
> > these two options out, will prevent Xorg from auto-loading the kernel
> > module.
> > 
> > Options "DRI"
> > Options "AccelMethod" "EXA"
> 
> With this code and ati 6.12.0, I get the awful performance.
> Kernel says
> drm0: <ATI Radeon HD 2600 XT> on vgapci0
> vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xd0020000
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] Initialized radeon 1.29.0 20080528
> vgapci0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xc0000000
> info: [drm] Setting GART location based on new memory map
> error: [drm:pid1494:r600_do_init_cp] *ERROR* Need gart offset from userspace

Your card was agp right?

What happens if you force pci mode?

Options "BusType" "PCI"

robert.

> Then, the Xorg.0.log
> ...
> (II) RADEON(0): [drm] register handle = 0xd0020000
> (II) RADEON(0): [dri] Visual configs initialized
> (II) RADEON(0): RADEONRestoreMemMapRegisters() :
> (II) RADEON(0):   MC_FB_LOCATION   : 0x00df00c0 0x00df00c0
> (II) RADEON(0):   MC_AGP_LOCATION  : 0x003f0000
> (==) RADEON(0): Backing store disabled
> (II) RADEON(0): [DRI] installation complete
> (II) RADEON(0): [drm] removed 1 reserved context for kernel
> (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc731d000 at 0x286fd000
> (II) RADEON(0): [drm] Closed DRM master.
> (WW) RADEON(0): Direct rendering disabled
> (EE) RADEON(0): Acceleration initialization failed
> ...
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090316/f86ef4e8/attachment.pgp
From kostikbel at gmail.com  Mon Mar 16 02:43:29 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Mon Mar 16 02:43:42 2009
Subject: Radeon r6/7xx support merged to -STABLE
In-Reply-To: <1237174073.18826.9.camel@balrog.2hip.net>
References: <1237142952.1774.22.camel@balrog.2hip.net>
	<20090315213323.GH41617@deviant.kiev.zoral.com.ua>
	<1237174073.18826.9.camel@balrog.2hip.net>
Message-ID: <20090316094312.GI41617@deviant.kiev.zoral.com.ua>

On Sun, Mar 15, 2009 at 10:27:53PM -0500, Robert Noland wrote:
> On Sun, 2009-03-15 at 23:33 +0200, Kostik Belousov wrote:
> > On Sun, Mar 15, 2009 at 01:49:12PM -0500, Robert Noland wrote:
> > > I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago.
> > > 
> > > The current xorg drivers will not enable it by default on R600+ chips.
> > > You will need to be using xf86-video-ati-6.12.0,
> > > xf86-video-radeonhd-devel or possibly even better git master of either.
> > > 
> > > You will need to add the following to the Device section of your
> > > xorg.conf to enable it.  If you are experiencing issues, commenting
> > > these two options out, will prevent Xorg from auto-loading the kernel
> > > module.
> > > 
> > > Options "DRI"
> > > Options "AccelMethod" "EXA"
> > 
> > With this code and ati 6.12.0, I get the awful performance.
> > Kernel says
> > drm0: <ATI Radeon HD 2600 XT> on vgapci0
> > vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xd0020000
> > vgapci0: child drm0 requested pci_enable_busmaster
> > info: [drm] Initialized radeon 1.29.0 20080528
> > vgapci0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xc0000000
> > info: [drm] Setting GART location based on new memory map
> > error: [drm:pid1494:r600_do_init_cp] *ERROR* Need gart offset from userspace
> 
> Your card was agp right?
No, this is PCIe card. It is reported correctly as Radeon HD 2600 XT.
Motherboard chipset is Intel P43, if this makes any useful information.

> 
> What happens if you force pci mode?
> 
> Options "BusType" "PCI"
> 
> robert.
> 
> > Then, the Xorg.0.log
> > ...
> > (II) RADEON(0): [drm] register handle = 0xd0020000
> > (II) RADEON(0): [dri] Visual configs initialized
> > (II) RADEON(0): RADEONRestoreMemMapRegisters() :
> > (II) RADEON(0):   MC_FB_LOCATION   : 0x00df00c0 0x00df00c0
> > (II) RADEON(0):   MC_AGP_LOCATION  : 0x003f0000
> > (==) RADEON(0): Backing store disabled
> > (II) RADEON(0): [DRI] installation complete
> > (II) RADEON(0): [drm] removed 1 reserved context for kernel
> > (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc731d000 at 0x286fd000
> > (II) RADEON(0): [drm] Closed DRM master.
> > (WW) RADEON(0): Direct rendering disabled
> > (EE) RADEON(0): Acceleration initialization failed
> > ...
> -- 
> Robert Noland <rnoland@FreeBSD.org>
> FreeBSD


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090316/6a1e55dc/attachment.pgp
From pluknet at gmail.com  Mon Mar 16 03:36:19 2009
From: pluknet at gmail.com (pluknet)
Date: Mon Mar 16 03:36:26 2009
Subject: bge0: EEPROM read timed
Message-ID: <a31046fc0903160336y58fd5e85le898dddd2c1d8aae@mail.gmail.com>

Hi.

I got this on today's RELENG_6 with Broadcom BCM5722 A0, ASIC rev. 0xa200.

>From dmesg (bge related):

bge0: <Broadcom BCM5722 A0, ASIC rev. 0xa200> mem
0xe8400000-0xe840ffff irq 16 at device 0.0 on pci2
bge0: firmware handshake timed out, found 0x4b657654
bge0: firmware handshake timed out, found 0x4b657654
bge0: EEPROM read timed out
bge0: failed to read EEPROM
device_attach: bge0 attach returned 6
bge1: <Broadcom BCM5703 B0, ASIC rev. 0x1100> mem
0xe8600000-0xe860ffff irq 21 at device 1.0 on pci3
miibus0: <MII bus> on bge1
brgphy0: <BCM5703 10/100/1000baseTX PHY> on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bge1: Ethernet address: 00:21:5e:4d:05:c8


any hints?

P.S. I see EEPROM timeout fixes were already merged to RELENG_6 (I
have post-fix version certainly).
May that issue be somehow related?

-- 
wbr,
pluknet
From olli at lurza.secnetix.de  Mon Mar 16 03:55:43 2009
From: olli at lurza.secnetix.de (Oliver Fromme)
Date: Mon Mar 16 03:55:51 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <49BA1BAA.3080905@FreeBSD.org>
Message-ID: <200903161055.n2GAtHkt077732@lurza.secnetix.de>

Doug Barton wrote:
 > The attached patch adds a -F option to automatically install files
 > when only the FreeBSD $Ids differ. I've tested this and it seems to do
 > what the people concerned about this issue are asking for.

That seems to be a useful feature.  You need to quote the
dollar signs, though.

However, maybe the best solution is to add a new keyword
for mergemaster.rc, so the user can exactly specify which
kind of changes should be always installed.

So the new -L option (which could still exist as a short-cut)
would be the same as the following line in mergemaster.rc:

AUTO_INSTALL_DIFF='-I[$]FreeBSD:.*[$]'

For example, if someone is not interested in pure white-
space changes and changes to #-style comments, he could
let those be auto-installed thusly:

AUTO_INSTALL_DIFF='-Bb -I#.* -I[$]FreeBSD:.*[$]'

What do you think?

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch?ftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n-
chen, HRB 125758,  Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"I have stopped reading Stephen King novels.
Now I just read C code instead."
        -- Richard A. O'Keefe
From pluknet at gmail.com  Mon Mar 16 05:08:40 2009
From: pluknet at gmail.com (pluknet)
Date: Mon Mar 16 05:08:48 2009
Subject: bge0: EEPROM read timed
In-Reply-To: <a31046fc0903160336y58fd5e85le898dddd2c1d8aae@mail.gmail.com>
References: <a31046fc0903160336y58fd5e85le898dddd2c1d8aae@mail.gmail.com>
Message-ID: <a31046fc0903160508v7bfdf087r777b5b79390538fa@mail.gmail.com>

2009/3/16 pluknet <pluknet@gmail.com>:
> Hi.
>
> I got this on today's RELENG_6 with Broadcom BCM5722 A0, ASIC rev. 0xa200.
>
> From dmesg (bge related):
>
> bge0: <Broadcom BCM5722 A0, ASIC rev. 0xa200> mem
> 0xe8400000-0xe840ffff irq 16 at device 0.0 on pci2
> bge0: firmware handshake timed out, found 0x4b657654
> bge0: firmware handshake timed out, found 0x4b657654
> bge0: EEPROM read timed out
> bge0: failed to read EEPROM
> device_attach: bge0 attach returned 6
> bge1: <Broadcom BCM5703 B0, ASIC rev. 0x1100> mem
> 0xe8600000-0xe860ffff irq 21 at device 1.0 on pci3
> miibus0: <MII bus> on bge1
> brgphy0: <BCM5703 10/100/1000baseTX PHY> on miibus0
> brgphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX, auto
> bge1: Ethernet address: 00:21:5e:4d:05:c8
>
>
> any hints?
>
> P.S. I see EEPROM timeout fixes were already merged to RELENG_6 (I
> have post-fix version certainly).
> May that issue be somehow related?
>

I guess it's a regression. Below are my speculations.

I tried to build on 6.2-R the bge(4) sources checked from later RELENG_6
just after BCM5722 support (from if_bgereg.h 1.36.2.11/ if_bge.c1.91.2.26)
in order to backport BCM5722 support into 6.2-R. After some tweaks it
was built, so..

What I got in dmesg (after native statically built bge(4) replacement
in boot loader prompt) is:
FreeBSD 6.2-RELEASE-p8 #13: Thu Feb 19 14:52:30 MSK 2009
[..snip..]
bgex0: <Broadcom BCM5722 A0, ASIC rev. 0xa200> mem
0xe8400000-0xe840ffff irq 16 at device 0.0 on pci2
bgex0: Ethernet address: 00:21:5e:4d:05:c7

Whoohoo..

So, here it even reached macaddr designation. (and going to panic at
nfs boot time (probably
to different locking scheme between 6.2 and 6.4, but it's an another story)).


-- 
wbr,
pluknet
From h.schmalzbauer at OmniLAN.de  Mon Mar 16 10:02:14 2009
From: h.schmalzbauer at OmniLAN.de (Harald Schmalzbauer)
Date: Mon Mar 16 10:02:21 2009
Subject: FIB (routing table) question with jailed service
Message-ID: <49BE8389.8010805@OmniLAN.de>

Hello,

I set up a second routingtable and told rc.d/jail to use the FIB1.
Now I wonder why the SSHd in the jail isn't responding. I set the 
default router to a local address and the second default router in FIB1 
to the ISP router, reachable via a second NIC.
Does the FIb only work for outgoing, intiating connections?

Best regards,

-Harry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090316/a903f9d6/signature.pgp
From rnoland at FreeBSD.org  Mon Mar 16 10:33:41 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon Mar 16 10:33:53 2009
Subject: Radeon r6/7xx support merged to -STABLE
In-Reply-To: <20090316094312.GI41617@deviant.kiev.zoral.com.ua>
References: <1237142952.1774.22.camel@balrog.2hip.net>
	<20090315213323.GH41617@deviant.kiev.zoral.com.ua>
	<1237174073.18826.9.camel@balrog.2hip.net>
	<20090316094312.GI41617@deviant.kiev.zoral.com.ua>
Message-ID: <1237224806.1865.72.camel@balrog.2hip.net>

On Mon, 2009-03-16 at 11:43 +0200, Kostik Belousov wrote:
> On Sun, Mar 15, 2009 at 10:27:53PM -0500, Robert Noland wrote:
> > On Sun, 2009-03-15 at 23:33 +0200, Kostik Belousov wrote:
> > > On Sun, Mar 15, 2009 at 01:49:12PM -0500, Robert Noland wrote:
> > > > I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago.
> > > > 
> > > > The current xorg drivers will not enable it by default on R600+ chips.
> > > > You will need to be using xf86-video-ati-6.12.0,
> > > > xf86-video-radeonhd-devel or possibly even better git master of either.
> > > > 
> > > > You will need to add the following to the Device section of your
> > > > xorg.conf to enable it.  If you are experiencing issues, commenting
> > > > these two options out, will prevent Xorg from auto-loading the kernel
> > > > module.
> > > > 
> > > > Options "DRI"
> > > > Options "AccelMethod" "EXA"
> > > 
> > > With this code and ati 6.12.0, I get the awful performance.
> > > Kernel says
> > > drm0: <ATI Radeon HD 2600 XT> on vgapci0
> > > vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xd0020000
> > > vgapci0: child drm0 requested pci_enable_busmaster
> > > info: [drm] Initialized radeon 1.29.0 20080528
> > > vgapci0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xc0000000
> > > info: [drm] Setting GART location based on new memory map
> > > error: [drm:pid1494:r600_do_init_cp] *ERROR* Need gart offset from userspace
> > 
> > Your card was agp right?
> No, this is PCIe card. It is reported correctly as Radeon HD 2600 XT.
> Motherboard chipset is Intel P43, if this makes any useful information.

Ok, let me look over the code again and figure out how we get into this
state.  I may need more details, let me figure out what I need.

robert.

> > 
> > What happens if you force pci mode?
> > 
> > Options "BusType" "PCI"
> > 
> > robert.
> > 
> > > Then, the Xorg.0.log
> > > ...
> > > (II) RADEON(0): [drm] register handle = 0xd0020000
> > > (II) RADEON(0): [dri] Visual configs initialized
> > > (II) RADEON(0): RADEONRestoreMemMapRegisters() :
> > > (II) RADEON(0):   MC_FB_LOCATION   : 0x00df00c0 0x00df00c0
> > > (II) RADEON(0):   MC_AGP_LOCATION  : 0x003f0000
> > > (==) RADEON(0): Backing store disabled
> > > (II) RADEON(0): [DRI] installation complete
> > > (II) RADEON(0): [drm] removed 1 reserved context for kernel
> > > (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc731d000 at 0x286fd000
> > > (II) RADEON(0): [drm] Closed DRM master.
> > > (WW) RADEON(0): Direct rendering disabled
> > > (EE) RADEON(0): Acceleration initialization failed
> > > ...
> > -- 
> > Robert Noland <rnoland@FreeBSD.org>
> > FreeBSD
> 
> 
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090316/2b6afe06/attachment.pgp
From scf at FreeBSD.org  Mon Mar 16 10:41:01 2009
From: scf at FreeBSD.org (Sean C. Farley)
Date: Mon Mar 16 10:41:07 2009
Subject: Panic in radeon_get_vblank_counter()
In-Reply-To: <1237138163.1774.5.camel@balrog.2hip.net>
References: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>
	<1236997834.1735.30.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903132318050.1220@baba.farley.org>
	<1237016323.1789.13.camel@balrog.2hip.net>
	<20090315142706.16ffca16@fabiankeil.de>
	<1237138163.1774.5.camel@balrog.2hip.net>
Message-ID: <alpine.BSF.2.00.0903161239480.70151@thor.farley.org>

On Sun, 15 Mar 2009, Robert Noland wrote:

> On Sun, 2009-03-15 at 14:27 +0100, Fabian Keil wrote:
>> Robert Noland <rnoland@FreeBSD.org> wrote:
>>> On Fri, 2009-03-13 at 23:33 -0500, Sean C. Farley wrote:
>>>> On Fri, 13 Mar 2009, Robert Noland wrote:
>>
>>>> If I start rebooting before it is printed, the system locks up.  Of
>>>> course, this is only after rebooting several times.
>>>>
>>>> Here is a successful start and shutdown:
>>>> http://people.freebsd.org/~scf/drm-dmesg.log
>>>> http://people.freebsd.org/~scf/Xorg.0.log
>>>
>>> Ok, I'll spend some time staring at the current code... Thanks for 
>>> the backtrace too, it's nice to get those...
>>
>> This seems to be the same panic I mentioned in the
>> "Filesystems being eaten?" thread on freebsd-current.
>>
>> I reproducible got this panic on:
>> FreeBSD 8.0-CURRENT #39: Sat Mar  7 20:37:29 CET 2009
>> when shutting Xorg down. I can no longer reproduce it with:
>> FreeBSD 8.0-CURRENT #42: Sat Mar 14 00:47:09 CET 2009
>
> Ok, everything from HEAD is merged... Give it a little while for the 
> mirrors to catch up and give it a shot.

I tried several times, and I was unable to get it to panic again.

Thank you!

Sean
-- 
scf@FreeBSD.org
From nakal at web.de  Mon Mar 16 10:59:44 2009
From: nakal at web.de (Martin)
Date: Mon Mar 16 10:59:52 2009
Subject: IPv6 gif(4) MTU: manpage vs src inconsistency?
Message-ID: <20090316183609.2b948933@zelda.local>


Hi,

it seems I have trouble to reach some websites using IPv6 through a gif
tunnel. Most websites work, except for these two:

www.freebsd.org
www.kame.net

I've searched for problems and it seems, I cannot send ping packets
larger than 1232 from the host behind my router. That's why I wanted to
decrease the MTU on gif from 1280 to 1240, as the manpage gif(4)
suggests:

"If the outer protocol is IPv6, path MTU discovery for encapsulated
packets may affect communication over the interface.  The first
bigger-than- pmtu packet may be lost.  To avoid the problem, you may
want to set the interface MTU for gif to 1240 or smaller, when the
outer header is IPv6 and the inner header is IPv4."

And I tried it:

# ifconfig gif0 mtu 1240
ifconfig: ioctl (set mtu): Invalid argument

It does not work, because in source, you can find:
if_gif.h:

#define GIF_MTU		(1280) /* Default MTU */
#define	GIF_MTU_MIN	(1280) /* Minimum MTU */
#define GIF_MTU_MAX	(8192) /* Maximum MTU */

What now? One of the values is wrong, in my opinion.


I still don't know the exact cause of the IPv6 website
problems. Is there anyone who has a solution for this? I can access ALL
WEBSITES from my router directly that has configured the gif tunnel.
But all hosts that use the router for default route cannot access the
two websites. I have also no issues with traffic to IRC server and so
on. I've just found these two hosts that are "different" somehow.

This is confusing.


Router configuration:
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1492
	inet xx.xx.xx.xx --> yy.yy.yy.yy netmask 0xffffffff 
	Opened by PID 433
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
	tunnel inet xx.xx.xx.xx --> 192.88.99.1
	inet6 2002:xxxx:xxxx::1 prefixlen 64 

Host behind the router that chokes on the two websites:
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500
	options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
	ether zz:zz:zz:zz:zz:zz
	inet6 fe80::zzzz:zzzz:zzzz:zzzz%re0 prefixlen 64 scopeid 0x1 
	inet 192.168.0.12 netmask 0xffffff00 broadcast 192.168.0.255
	inet6 fde2:zzzz:zzzz:zzzz:zzzz:zzzz:zzzz:zzzz prefixlen 64
	autoconf 
	inet6 2002:xxxx:xxxx:1:zzzz:zzzz:zzzz:zzzz prefixlen 64
	autoconf 
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active

--
Martin
From danallen46 at airwired.net  Mon Mar 16 11:02:27 2009
From: danallen46 at airwired.net (Dan Allen)
Date: Mon Mar 16 11:02:47 2009
Subject: GCC build causes panic: page already inserted
Message-ID: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>

I saw that someone else had this happen last week...  It is not a  
hardware failure.

While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a  
core dump with the message

	vm_page_insert: page already inserted

I build this port every week on a Toshiba laptop (1.8GHz Core 2 Duo, 1  
GB RAM, 160 GB HD, plenty of free space, RELENG_7).  I have never seen  
this until today.  Just before building this port I completely built  
the kernel and world and installed them, so I am as up-to-date as you  
could be.

I suspect recent changes to vm code... perhaps in /usr/src/sys/vm/ 
vm_meter.c or vm_page.c ?

The compressed core dump is 41 MB.

Dan



From rnoland at FreeBSD.org  Mon Mar 16 11:20:10 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon Mar 16 11:20:16 2009
Subject: Panic in radeon_get_vblank_counter()
In-Reply-To: <alpine.BSF.2.00.0903161239480.70151@thor.farley.org>
References: <alpine.BSF.2.00.0903131534040.6590@thor.farley.org>
	<1236997834.1735.30.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903132318050.1220@baba.farley.org>
	<1237016323.1789.13.camel@balrog.2hip.net>
	<20090315142706.16ffca16@fabiankeil.de>
	<1237138163.1774.5.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903161239480.70151@thor.farley.org>
Message-ID: <1237227594.1865.89.camel@balrog.2hip.net>

On Mon, 2009-03-16 at 12:40 -0500, Sean C. Farley wrote:
> On Sun, 15 Mar 2009, Robert Noland wrote:
> 
> > On Sun, 2009-03-15 at 14:27 +0100, Fabian Keil wrote:
> >> Robert Noland <rnoland@FreeBSD.org> wrote:
> >>> On Fri, 2009-03-13 at 23:33 -0500, Sean C. Farley wrote:
> >>>> On Fri, 13 Mar 2009, Robert Noland wrote:
> >>
> >>>> If I start rebooting before it is printed, the system locks up.  Of
> >>>> course, this is only after rebooting several times.
> >>>>
> >>>> Here is a successful start and shutdown:
> >>>> http://people.freebsd.org/~scf/drm-dmesg.log
> >>>> http://people.freebsd.org/~scf/Xorg.0.log
> >>>
> >>> Ok, I'll spend some time staring at the current code... Thanks for 
> >>> the backtrace too, it's nice to get those...
> >>
> >> This seems to be the same panic I mentioned in the
> >> "Filesystems being eaten?" thread on freebsd-current.
> >>
> >> I reproducible got this panic on:
> >> FreeBSD 8.0-CURRENT #39: Sat Mar  7 20:37:29 CET 2009
> >> when shutting Xorg down. I can no longer reproduce it with:
> >> FreeBSD 8.0-CURRENT #42: Sat Mar 14 00:47:09 CET 2009
> >
> > Ok, everything from HEAD is merged... Give it a little while for the 
> > mirrors to catch up and give it a shot.
> 
> I tried several times, and I was unable to get it to panic again.

Cool, glad it worked out.

robert.

> Thank you!
> 
> Sean
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090316/9ba303c3/attachment.pgp
From alan.l.cox at gmail.com  Mon Mar 16 12:01:42 2009
From: alan.l.cox at gmail.com (Alan Cox)
Date: Mon Mar 16 12:01:50 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
Message-ID: <ca3526250903161201w303977beg446c6623b49b2ce4@mail.gmail.com>

On Mon, Mar 16, 2009 at 12:59 PM, Dan Allen <danallen46@airwired.net> wrote:

> I saw that someone else had this happen last week...  It is not a hardware
> failure.
>

I have not seen that.  I have only seen an assertion failure that would have
nothing to do with your reported panic.


>
> While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a core
> dump with the message
>
>        vm_page_insert: page already inserted
>
> I build this port every week on a Toshiba laptop (1.8GHz Core 2 Duo, 1 GB
> RAM, 160 GB HD, plenty of free space, RELENG_7).  I have never seen this
> until today.  Just before building this port I completely built the kernel
> and world and installed them, so I am as up-to-date as you could be.
>
> I suspect recent changes to vm code... perhaps in
> /usr/src/sys/vm/vm_meter.c or vm_page.c ?
>
> The compressed core dump is 41 MB.
>


For now, can you just provide the stack trace?

Regards,
Alan
From alc at cs.rice.edu  Mon Mar 16 12:11:33 2009
From: alc at cs.rice.edu (Alan Cox)
Date: Mon Mar 16 12:11:40 2009
Subject: 7.1 panic "vm_page_startup: inconsistent page counts"
In-Reply-To: <20090316021412.GI5857@pjdesk.au.alcatel-lucent.com>
References: <20090312043646.GB8352@pjdesk.au.alcatel-lucent.com>
	<200903120846.50630.jhb@freebsd.org>
	<20090316021412.GI5857@pjdesk.au.alcatel-lucent.com>
Message-ID: <49BE9F2A.7040901@cs.rice.edu>

Peter Jeremy wrote:
> On 2009-Mar-12 08:46:50 -0400, John Baldwin <jhb@freebsd.org> wrote:
>   
>> On Thursday 12 March 2009 12:36:46 am Peter Jeremy wrote:
>>     
>>> I'm trying to upgrade an 11 month old FreeBSD 7 image in a VMware
>>> 4.5.2 guest to an up-to-date -stable and it panics as above.  I've
>>> added a printf to report the two counts and there's a difference of
>>> one page.  I don't have any problems with the old 7-stable image or
>>> up-to-date 6-stable or -current using the same VMware version.
>>>
>>> A screendump for a verbose boot can be found at
>>> http://imagebin.ca/img/wahNNw.gif
>>>
>>> Can I safely delete the assert?
>>>       
>> I don't think so, I would report it to Alan.  The one earlier report of this 
>> didn't include the detail that it was only off by one page.
>>     
>
> This is a bit moot now since you've disabled the test but rolling back
> to a kernel from 26th Feb (before the superpages MFC) doesn't have the
> page count discrepancy.
>
>   

It's useful to know that the older kernel doesn't fail the assertion.  
Thanks.

Alan

From kostikbel at gmail.com  Mon Mar 16 12:49:58 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Mon Mar 16 12:50:10 2009
Subject: Radeon r6/7xx support merged to -STABLE
In-Reply-To: <1237224806.1865.72.camel@balrog.2hip.net>
References: <1237142952.1774.22.camel@balrog.2hip.net>
	<20090315213323.GH41617@deviant.kiev.zoral.com.ua>
	<1237174073.18826.9.camel@balrog.2hip.net>
	<20090316094312.GI41617@deviant.kiev.zoral.com.ua>
	<1237224806.1865.72.camel@balrog.2hip.net>
Message-ID: <20090316194949.GP41617@deviant.kiev.zoral.com.ua>

On Mon, Mar 16, 2009 at 12:33:26PM -0500, Robert Noland wrote:
> On Mon, 2009-03-16 at 11:43 +0200, Kostik Belousov wrote:
> > On Sun, Mar 15, 2009 at 10:27:53PM -0500, Robert Noland wrote:
> > > On Sun, 2009-03-15 at 23:33 +0200, Kostik Belousov wrote:
> > > > On Sun, Mar 15, 2009 at 01:49:12PM -0500, Robert Noland wrote:
> > > > > I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago.
> > > > > 
> > > > > The current xorg drivers will not enable it by default on R600+ chips.
> > > > > You will need to be using xf86-video-ati-6.12.0,
> > > > > xf86-video-radeonhd-devel or possibly even better git master of either.
> > > > > 
> > > > > You will need to add the following to the Device section of your
> > > > > xorg.conf to enable it.  If you are experiencing issues, commenting
> > > > > these two options out, will prevent Xorg from auto-loading the kernel
> > > > > module.
> > > > > 
> > > > > Options "DRI"
> > > > > Options "AccelMethod" "EXA"
> > > > 
> > > > With this code and ati 6.12.0, I get the awful performance.
> > > > Kernel says
> > > > drm0: <ATI Radeon HD 2600 XT> on vgapci0
> > > > vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xd0020000
> > > > vgapci0: child drm0 requested pci_enable_busmaster
> > > > info: [drm] Initialized radeon 1.29.0 20080528
> > > > vgapci0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xc0000000
> > > > info: [drm] Setting GART location based on new memory map
> > > > error: [drm:pid1494:r600_do_init_cp] *ERROR* Need gart offset from userspace
> > > 
> > > Your card was agp right?
> > No, this is PCIe card. It is reported correctly as Radeon HD 2600 XT.
> > Motherboard chipset is Intel P43, if this makes any useful information.
> 
> Ok, let me look over the code again and figure out how we get into this
> state.  I may need more details, let me figure out what I need.
> 
> robert.
> 
> > > 
> > > What happens if you force pci mode?
> > > 
> > > Options "BusType" "PCI"
For the record. It appeared that I already had this option in the xorg.conf,
and it was the cause of the problem. DRI works after removing this line.

> > > 
> > > robert.
> > > 
> > > > Then, the Xorg.0.log
> > > > ...
> > > > (II) RADEON(0): [drm] register handle = 0xd0020000
> > > > (II) RADEON(0): [dri] Visual configs initialized
> > > > (II) RADEON(0): RADEONRestoreMemMapRegisters() :
> > > > (II) RADEON(0):   MC_FB_LOCATION   : 0x00df00c0 0x00df00c0
> > > > (II) RADEON(0):   MC_AGP_LOCATION  : 0x003f0000
> > > > (==) RADEON(0): Backing store disabled
> > > > (II) RADEON(0): [DRI] installation complete
> > > > (II) RADEON(0): [drm] removed 1 reserved context for kernel
> > > > (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc731d000 at 0x286fd000
> > > > (II) RADEON(0): [drm] Closed DRM master.
> > > > (WW) RADEON(0): Direct rendering disabled
> > > > (EE) RADEON(0): Acceleration initialization failed
> > > > ...
> > > -- 
> > > Robert Noland <rnoland@FreeBSD.org>
> > > FreeBSD
> > 
> > 
> -- 
> Robert Noland <rnoland@FreeBSD.org>
> FreeBSD


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090316/fbe55192/attachment.pgp
From danallen46 at airwired.net  Mon Mar 16 13:49:47 2009
From: danallen46 at airwired.net (Dan Allen)
Date: Mon Mar 16 13:49:54 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <ca3526250903161201w303977beg446c6623b49b2ce4@mail.gmail.com>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
	<ca3526250903161201w303977beg446c6623b49b2ce4@mail.gmail.com>
Message-ID: <F5D70E08-3496-4D81-9E57-E0E53223A88A@airwired.net>


On 16 Mar 2009, at 1:01 PM, Alan Cox wrote:

> For now, can you just provide the stack trace?

How do I do this?  Is there a tool that I run against the core dump?

BTW, I just did the same gcc-4.4 build on my Mac and it built fine  
without any core dumps...

Dan

From patfbsd at davenulle.org  Mon Mar 16 14:42:04 2009
From: patfbsd at davenulle.org (Patrick =?ISO-8859-15?Q?Lamaizi=E8re?=)
Date: Mon Mar 16 14:42:24 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <F5D70E08-3496-4D81-9E57-E0E53223A88A@airwired.net>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
	<ca3526250903161201w303977beg446c6623b49b2ce4@mail.gmail.com>
	<F5D70E08-3496-4D81-9E57-E0E53223A88A@airwired.net>
Message-ID: <20090316224203.0781a280@baby-jane.lamaiziere.net>

Le Mon, 16 Mar 2009 14:49:43 -0600,
Dan Allen <danallen46@airwired.net>:

> > For now, can you just provide the stack trace?
> 
> How do I do this?  Is there a tool that I run against the core dump?

See
http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html

Regards.
From danallen46 at airwired.net  Mon Mar 16 16:23:12 2009
From: danallen46 at airwired.net (Dan Allen)
Date: Mon Mar 16 16:23:29 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <20090316224203.0781a280@baby-jane.lamaiziere.net>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
	<ca3526250903161201w303977beg446c6623b49b2ce4@mail.gmail.com>
	<F5D70E08-3496-4D81-9E57-E0E53223A88A@airwired.net>
	<20090316224203.0781a280@baby-jane.lamaiziere.net>
Message-ID: <F45354D5-B9EE-42A9-80CA-59234B2FF496@airwired.net>


On 16 Mar 2009, at 3:42 PM, Patrick Lamaizi?re wrote:

> Le Mon, 16 Mar 2009 14:49:43 -0600,
> Dan Allen <danallen46@airwired.net>:
>
>>> For now, can you just provide the stack trace?
>>
>> How do I do this?  Is there a tool that I run against the core dump?
>
> See
> http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html
>
> Regards.

Thanks!

It turns out that one must have a debug kernel around.  I use STABLE  
as a production system.  There is no "kernel.debug" on my system.  I  
guess I therefore cannot provide a stack trace.

Sorry.

Dan

From doconnor at gsoft.com.au  Mon Mar 16 17:31:17 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Mon Mar 16 17:31:25 2009
Subject: Calling NUT users in America (and other 110V countries)
Message-ID: <200903171101.02846.doconnor@gsoft.com.au>

Does anyone have a 110V MGE Pulsar connected to NUT via RS232?

The reason I am asking is that we ship systems overseas (from Australia land 
of 230V) and typically have the customer purchase a UPS (or arrange for one to 
be delivered to the site) and I find that I can't communicate with them using 
NUT.

All of the MGE UPSs we have shipped from Australia work fine, and the hardware 
and software is identical to 110V sites (Super micro C2SBA, FreeBSD 6.3).

I have talked to the NUT maintainers but they are primarily Linux oriented  
and haven't yet cranked up a FreeBSD box to have a look at it.

The symptoms are that it can talk to the UPS but there are frequent drops in 
communication (very annoying as it fills the logs with crap), yet 230V units 
work flawlessly.

I am not using USB because it was not reliable until very recently (and still 
reconnects alarmingly often..)

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090317/576ac82f/attachment.pgp
From danallen46 at airwired.net  Mon Mar 16 17:47:32 2009
From: danallen46 at airwired.net (Dan Allen)
Date: Mon Mar 16 17:47:39 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <ca3526250903161201w303977beg446c6623b49b2ce4@mail.gmail.com>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
	<ca3526250903161201w303977beg446c6623b49b2ce4@mail.gmail.com>
Message-ID: <C52C353F-437B-4FFC-87A3-A25DDBF36505@airwired.net>


On 16 Mar 2009, at 1:01 PM, Alan Cox wrote:

> For now, can you just provide the stack trace?

As I mentioned, I am unable to do so - I have no kernel.debug.

However, I am trying to reproduce the bug again.  (It takes a while.)   
Although it has not yet crashed, I noticed another unusual behavior:

Normally during my gcc builds the 1 GB of swap space is never  
touched.  My main 1 GB of RAM is sufficient and there is always at  
least 100 MB of free memory.

Today I saw a STATE listed when running top that I have never seen,  
called "wdrain".  This happened when I saw my free memory plummet down  
to only 20 MB free (out of 1 GB).  This state appears to be set in / 
usr/src/sys/kern/vfs_bio.c in a routine called waitrunningbufspace().   
This file also was modified March 1st.  I do not know if there is a  
connection...

The last time I built gcc-4.4 was probably just before this.  (I build  
gcc whenever there is a new version, within a couple of days of it  
being added to ports.  There was about two weeks with no new versions  
this first half of March so it has been a couple of weeks...)

I am tempted to go back to about Feb 28th kernel-wise and try the gcc  
build again and see if it works or panics.

Any suggestions as to how I can help narrow this down?

Dan
From ardovm at yahoo.it  Tue Mar 17 02:31:14 2009
From: ardovm at yahoo.it (Arrigo Marchiori)
Date: Tue Mar 17 02:31:21 2009
Subject: Page fault panic in scioctl and console-kit-daemon
In-Reply-To: <20090313122457.GD20585@snail.casa>
References: <DB49F4B8-9E0E-4219-BB58-04F6644D10A5@online.fr>
	<20090313122457.GD20585@snail.casa>
Message-ID: <20090317093106.GA16813@snail.casa>

Hello,

On Fri, Mar 13, 2009 at 01:24:57PM +0100, Arrigo Marchiori wrote:

> On Mon, Mar 09, 2009 at 12:15:15PM +0100, spara wrote:
[...]
> > Any other fix ?
> 
> It seems to me that no package has been depending on consolekit, since
> a couple of days. At least, portupgrade is not showing any more "stale
> dependencies" when I try to "portupgrade -aR" without having
> consolekit installed. So I'm living happily without it. :-)

I answer to myself: after upgrading to hal-0.5.11_21 consolekit is
required again. This problem has returned. :-(
-- 
rigo

http://rigo.altervista.org
From spara at online.fr  Tue Mar 17 04:22:20 2009
From: spara at online.fr (spara)
Date: Tue Mar 17 04:22:28 2009
Subject: Page fault panic in scioctl and console-kit-daemon
In-Reply-To: <20090317093106.GA16813@snail.casa>
References: <DB49F4B8-9E0E-4219-BB58-04F6644D10A5@online.fr>
	<20090313122457.GD20585@snail.casa>
	<20090317093106.GA16813@snail.casa>
Message-ID: <16E92772-CF8A-46F0-8757-97C38FF952A8@online.fr>

I switched to xfce myself and did not reinstall consolekit? don't know  
how armfull it could be though?

Le 17 mars 09 ? 10:31, Arrigo Marchiori a ?crit :

> Hello,
>
> On Fri, Mar 13, 2009 at 01:24:57PM +0100, Arrigo Marchiori wrote:
>
>> On Mon, Mar 09, 2009 at 12:15:15PM +0100, spara wrote:
> [...]
>>> Any other fix ?
>>
>> It seems to me that no package has been depending on consolekit,  
>> since
>> a couple of days. At least, portupgrade is not showing any more  
>> "stale
>> dependencies" when I try to "portupgrade -aR" without having
>> consolekit installed. So I'm living happily without it. :-)
>
> I answer to myself: after upgrading to hal-0.5.11_21 consolekit is
> required again. This problem has returned. :-(
> -- 
> rigo
>
> http://rigo.altervista.org
>

From rwatson at FreeBSD.org  Tue Mar 17 04:52:46 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Tue Mar 17 04:52:53 2009
Subject: Appeal for active bug reports relating to TCP, UDP, routing locking
 in 7-STABLE
Message-ID: <alpine.BSF.2.00.0903171146090.32289@fledge.watson.org>


Dear all:

With 7.2 approaching, I wanted to review the set of known network bug reports 
(especially panics, hangs, lock order reversals) relating to TCP, UDP, 
sockets, and routing in 7-STABLE.

If you are aware of problems along these that you can confirm definitely occur 
with 7-STABLE checked out no earlier than 17 March, 2009, please drop me a 
private e-mail with a pointer to the thread, PR, or a reminder that you've 
sent me the details already.  If you don't have a PR open on the problem, 
opening one and forwarding me the receipt so I can grab ownership would be 
most welcome.

I don't promise I can get them fixed by the release, but doing a review and 
prioritizing the bugs that are known is a useful step in that direction.  I am 
specifically not interested in device driver-related problems, not because 
they shouldn't be fixed, but because there's only so much time in the day and 
it appears folks like Pyun have it well in hand :-).

Robert N M Watson
Computer Laboratory
University of Cambridge
From marck at rinet.ru  Tue Mar 17 05:09:44 2009
From: marck at rinet.ru (Dmitry Morozovsky)
Date: Tue Mar 17 05:09:51 2009
Subject: RELENG_7/i386: ZFS panic on reboot
Message-ID: <alpine.BSF.2.00.0903171507180.68960@woozle.rinet.ru>


while rebooting:

(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0x80514298 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0x80514575 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0x806a74d4 in trap_fatal (frame=0xbf5b9a24, eva=12) at 
/usr/src/sys/i386/i386/trap.c:939
#4  0x806a771d in trap_pfault (frame=0xbf5b9a24, usermode=0, eva=12) at 
/usr/src/sys/i386/i386/trap.c:852
#5  0x806a808a in trap (frame=0xbf5b9a24) at /usr/src/sys/i386/i386/trap.c:530
#6  0x8069016b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0x80806610 in gfs_dir_create (struct_size=132, pvp=0x87b388a0, 
vfsp=0x87a93b40, ops=0x808817a0, entries=0x0, inode_cb=0, maxlen=256, 
    readdir_cb=0x808636c6 <zfsctl_snapdir_readdir_cb>, lookup_cb=0) at 
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:420
#8  0x80863420 in zfsctl_mknode_snapdir (pvp=0x87b388a0) at 
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:783
#9  0x808069e9 in gfs_dir_lookup (dvp=0x87b388a0, nm=0x8087dfae "snapshot", 
vpp=0xbf5b9b60) at 
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/gfs.c:630
#10 0x808630bc in zfsctl_root_lookup (dvp=0x87b388a0, nm=0x8087dfae "snapshot", 
vpp=0xbf5b9b60, pnp=0x0, flags=0, rdir=0x0, cr=0x85e84000)
    at 
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:396
#11 0x808638fa in zfsctl_umount_snapshots (vfsp=0x87a93b40, fflags=524288, 
cr=0x85e84000)
    at 
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c:1063
#12 0x8086b1dc in zfs_umount (vfsp=0x87a93b40, fflag=524288, td=0x85e8ecc0) at 
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:692
#13 0x80586ea4 in dounmount (mp=0x87a93b40, flags=524288, td=0x85e8ecc0) at 
/usr/src/sys/kern/vfs_mount.c:1293
#14 0x8058a4e8 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2944
#15 0x80514005 in boot (howto=16392) at /usr/src/sys/kern/kern_shutdown.c:400
#16 0x8051445d in reboot (td=0x85e8ecc0, uap=0xbf5b9cfc) at 
/usr/src/sys/kern/kern_shutdown.c:172
#17 0x806a7a60 in syscall (frame=0xbf5b9d38) at 
/usr/src/sys/i386/i386/trap.c:1090
#18 0x806901d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255
#19 0x00000033 in ?? ()

Any additional info needed? Thanks!

-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
------------------------------------------------------------------------
From yanefbsd at gmail.com  Tue Mar 17 05:52:53 2009
From: yanefbsd at gmail.com (Garrett Cooper)
Date: Tue Mar 17 05:53:02 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <C52C353F-437B-4FFC-87A3-A25DDBF36505@airwired.net>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
	<ca3526250903161201w303977beg446c6623b49b2ce4@mail.gmail.com>
	<C52C353F-437B-4FFC-87A3-A25DDBF36505@airwired.net>
Message-ID: <7d6fde3d0903170522l6c7d7df8w3bff02ba5eee560f@mail.gmail.com>

On Mon, Mar 16, 2009 at 5:47 PM, Dan Allen <danallen46@airwired.net> wrote:
>
> On 16 Mar 2009, at 1:01 PM, Alan Cox wrote:
>
>> For now, can you just provide the stack trace?
>
> As I mentioned, I am unable to do so - I have no kernel.debug.
>
> However, I am trying to reproduce the bug again. ?(It takes a while.)
> ?Although it has not yet crashed, I noticed another unusual behavior:
>
> Normally during my gcc builds the 1 GB of swap space is never touched. ?My
> main 1 GB of RAM is sufficient and there is always at least 100 MB of free
> memory.
>
> Today I saw a STATE listed when running top that I have never seen, called
> "wdrain". ?This happened when I saw my free memory plummet down to only 20
> MB free (out of 1 GB). ?This state appears to be set in
> /usr/src/sys/kern/vfs_bio.c in a routine called waitrunningbufspace(). ?This
> file also was modified March 1st. ?I do not know if there is a connection...
>
> The last time I built gcc-4.4 was probably just before this. ?(I build gcc
> whenever there is a new version, within a couple of days of it being added
> to ports. ?There was about two weeks with no new versions this first half of
> March so it has been a couple of weeks...)
>
> I am tempted to go back to about Feb 28th kernel-wise and try the gcc build
> again and see if it works or panics.
>
> Any suggestions as to how I can help narrow this down?

- Which platform are you using: i386 or amd64?
- Is there a particular file that it tries to compile when it runs out
of memory?
- What are your CFLAGS in make.conf?

Thanks,
-Garrett
From ns at got2get.net  Tue Mar 17 07:07:58 2009
From: ns at got2get.net (Nicolai)
Date: Tue Mar 17 07:08:05 2009
Subject: Crazy "interrupt storm detected" on atapic0
Message-ID: <a0deb29de23c70305123faf1a9d0bae6@relay.dk>



Hi all, 

I have had this problem since day 1 on my new server. 

It has run since November 15th 2008, and serve approx. 10 GB worth of web
traffic per month for the main site and then some 40 domains with mail and
small web pages. (hence - it's NOT that busy yet) 

I started with 7.1-RELEASE-pX since I didn't have problems straight off -
but it didn't last long. 

After a few days of running, the interrupt storm on atapci0 starts to
show. It slowly builds up and continues. When it reaches 150-200k/sec. I
reboot just to be on the safe side. 

I have also upgraded to 7.1-STABLE to get all the ATA driver changes
S.O.S. have been including. Still no visible change. 

To give you an impression of its impact, I will let the numbers speak for
thmeselves: 

$ uname -v
FreeBSD 7.1-STABLE #1: Thu Mar 12 14:22:49 CET 2009 

$ uname -m
amd64 

$ uptime
 2:36PM up 4 days, 22:12, 5 users, load averages: 0.28, 0.40, 0.19 

$ tail -10 messages
Mar 17 13:42:37 box last message repeated 600
times
Mar 17 13:52:37 box last message repeated 600 times
Mar 17 14:02:37 box last message repeated 600 times
Mar 17 14:12:37 box last message repeated 600 times
Mar 17 14:22:37 box last message repeated 600 times
Mar 17 14:32:22 box last message repeated 585 times
Mar 17 14:32:23 box kernel: pid 78195 (try), uid 0: exited on signal 10
(core dumped)
Mar 17 14:32:23 box kernel: interrupt storm detected on "irq22:";
throttling interrupt source
Mar 17 14:32:54 box last message repeated 31 times
Mar 17 14:34:55 box last message repeated 121 times 

$ vmstat -i
interrupt total rate
irq1: atkbd0 3 0
irq9: acpi0 1 0
irq16: ohci0 1 0
irq17: ohci1 ohci3 1 0
irq18: ohci2 ohci4 1 0
irq22: atapci0 57317362717 134713
cpu0: timer 850996016 2000
cpu1: timer 850995703 2000
Total 59019354443 138713 

[root@box /etc]# atacontrol mode ad4
current mode = SATA300
[root@box /etc]# atacontrol mode ad6
current mode = SATA300 

Some relevant lines from dmesg: 

atapci0: 
port
0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem
0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0
atapci0: [ITHREAD]
atapci0: AHCI Version 01.10 controller with 4 ports detected
ata2:  on atapci0
ata2: [ITHREAD]
ata3:  on atapci0
ata3: [ITHREAD]
ata4:  on atapci0
ata4: [ITHREAD]
ata5:  on atapci0
ata5: [ITHREAD] 

And a few lines from pciconf: 

atapci0@pci0:0:18:0: class=0x01018f card=0x73271462 chip=0x43801002
rev=0x00 hdr=0x00
 vendor = 'ATI Technologies Inc'
 device = 'IXP SB600 Serial ATA Controller'
 class = mass storage
 subclass = ATA 

...so - this is where I'm at. Interrupt storm raises through the roof in
just 3 days, and continues to raise. 

Just for kicks I tried disabling AHCI with nextboot, but that made the box
not boot. Also - I'm 1000 KM. away from the box - so I'm a little limited
to testing fancy boot options - apart from things that can go in
nextboot.conf. 

If anyone have any hints on how to proceed, I would be grateful.


Thank you in advance 

 - Nicolai
From kensmith at cse.Buffalo.EDU  Tue Mar 17 07:32:48 2009
From: kensmith at cse.Buffalo.EDU (Ken Smith)
Date: Tue Mar 17 07:32:55 2009
Subject: FreeBSD 7.2 Release process starting...
Message-ID: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>


We're starting the release process for FreeBSD 7.2-RELEASE.  The major
highlights of the schedule are:

        Code Freeze:            March 23rd
        BETA1                   March 30th
        Branch                  April 10th
        RC1                     April 13th
        RC2                     April 20th
        Release:                May 4th

The full schedule is here:

  http://www.freebsd.org/releases/7.2R/schedule.html

though most of "the other events" haven't been given specific dates yet.

Since it's often the case that developers process quite a few
outstanding MFCs during the last couple days before a code freeze starts
I have changed RELENG_7 to say it is 7.2-PRERELEASE now as a bit of a
heads-up that the release cycle is imminent.  You might need to be a
tiny bit more careful using RELENG_7 right now because the odds of you
getting a snapshot of the tree taken part way through someone doing
something that required multiple commits goes up during this phase of a
release.

Thanks.

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090317/b9b7d7d0/attachment.pgp
From ns at got2get.net  Tue Mar 17 08:17:13 2009
From: ns at got2get.net (Nicolais)
Date: Tue Mar 17 08:17:20 2009
Subject: Crazy "interrupt storm detected" on atapci0
In-Reply-To: <a0deb29de23c70305123faf1a9d0bae6@relay.dk>
References: <a0deb29de23c70305123faf1a9d0bae6@relay.dk>
Message-ID: <22561413.post@talk.nabble.com>


Also - this was extracted from kenv:

LINES="24"
acpi_load="YES"
bootfile="kernel"
comconsole_speed="9600"
console="vidconsole"
currdev="disk0s1a:"
hint.acpi.0.oem="ACPIAM"
hint.acpi.0.revision="1"
hint.acpi.0.rsdp="0xf98a0"
hint.acpi.0.rsdt="0x7dfd0000"
hint.atkbd.0.at="atkbdc"
hint.atkbd.0.irq="1"
hint.atkbdc.0.at="isa"
hint.atkbdc.0.port="0x060"
hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.fd.1.at="fdc0"
hint.fd.1.drive="1"
hint.fdc.0.at="isa"
hint.fdc.0.drq="2"
hint.fdc.0.irq="6"
hint.fdc.0.port="0x3F0"
hint.ppc.0.at="isa"
hint.ppc.0.irq="7"
hint.psm.0.at="atkbdc"
hint.psm.0.irq="12"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
hint.sio.0.at="isa"
hint.sio.0.flags="0x10"
hint.sio.0.irq="4"
hint.sio.0.port="0x3F8"
hint.sio.1.at="isa"
hint.sio.1.irq="3"
hint.sio.1.port="0x2F8"
hint.sio.2.at="isa"
hint.sio.2.disabled="1"
hint.sio.2.irq="5"
hint.sio.2.port="0x3E8"
hint.sio.3.at="isa"
hint.sio.3.disabled="1"
hint.sio.3.irq="9"
hint.sio.3.port="0x2E8"
hint.vga.0.at="isa"
interpret="OK"
kernel="kernel"
kernel_options=""
kernelname="/boot/kernel/kernel"
loaddev="disk0s1a:"
mac_ifoff="NO"
module_path="/boot/kernel;/boot/modules"
smbios.bios.reldate="10/31/2007"
smbios.bios.vendor="American Megatrends Inc."
smbios.bios.version="V1.5B2"
smbios.chassis.maker="To Be Filled By O.E.M."
smbios.chassis.serial="To Be Filled By O.E.M."
smbios.chassis.tag="To Be Filled By O.E.M."
smbios.chassis.version="To Be Filled By O.E.M."
smbios.planar.maker="MICRO-STAR INTERANTIONAL CO.,LTD"
smbios.planar.product="MS-7368"
smbios.planar.serial="To be filled by O.E.M."
smbios.planar.version="1.0"
smbios.socket.enabled="1"
smbios.socket.populated="1"
smbios.system.maker="MICRO-STAR INTERANTIONAL CO.,LTD"
smbios.system.product="MS-7368"
smbios.system.serial="To Be Filled By O.E.M."
smbios.system.version="1.0"
vfs.root.mountfrom="ufs:/dev/mirror/gm0s1a"

(sorry for spelling error in subject s/atapic/atapci/)
-- 
View this message in context: http://www.nabble.com/Crazy-%22interrupt-storm-detected%22-on-atapic0-tp22560101p22561413.html
Sent from the freebsd-stable mailing list archive at Nabble.com.

From amarat at ksu.ru  Tue Mar 17 08:26:54 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Tue Mar 17 08:27:03 2009
Subject: Crazy "interrupt storm detected" on atapic0
In-Reply-To: <a0deb29de23c70305123faf1a9d0bae6@relay.dk>
References: <a0deb29de23c70305123faf1a9d0bae6@relay.dk>
Message-ID: <49BFBE10.50309@ksu.ru>

Nicolai wrote:
> 
> Hi all, 
> 
> I have had this problem since day 1 on my new server. 
> 
> It has run since November 15th 2008, and serve approx. 10 GB worth of web
> traffic per month for the main site and then some 40 domains with mail and
> small web pages. (hence - it's NOT that busy yet) 
> 
> I started with 7.1-RELEASE-pX since I didn't have problems straight off -
> but it didn't last long. 
> 
> After a few days of running, the interrupt storm on atapci0 starts to
> show. It slowly builds up and continues. When it reaches 150-200k/sec. I
> reboot just to be on the safe side. 
> 
> I have also upgraded to 7.1-STABLE to get all the ATA driver changes
> S.O.S. have been including. Still no visible change. 
> 
> To give you an impression of its impact, I will let the numbers speak for
> thmeselves: 
> 
> $ uname -v
> FreeBSD 7.1-STABLE #1: Thu Mar 12 14:22:49 CET 2009 
> 
> $ uname -m
> amd64 
> 
> $ uptime
>  2:36PM up 4 days, 22:12, 5 users, load averages: 0.28, 0.40, 0.19 
> 
> $ tail -10 messages
> Mar 17 13:42:37 box last message repeated 600
> times
> Mar 17 13:52:37 box last message repeated 600 times
> Mar 17 14:02:37 box last message repeated 600 times
> Mar 17 14:12:37 box last message repeated 600 times
> Mar 17 14:22:37 box last message repeated 600 times
> Mar 17 14:32:22 box last message repeated 585 times
> Mar 17 14:32:23 box kernel: pid 78195 (try), uid 0: exited on signal 10
> (core dumped)
> Mar 17 14:32:23 box kernel: interrupt storm detected on "irq22:";
> throttling interrupt source
> Mar 17 14:32:54 box last message repeated 31 times
> Mar 17 14:34:55 box last message repeated 121 times 
> 
> $ vmstat -i
> interrupt total rate
> irq1: atkbd0 3 0
> irq9: acpi0 1 0
> irq16: ohci0 1 0
> irq17: ohci1 ohci3 1 0
> irq18: ohci2 ohci4 1 0
> irq22: atapci0 57317362717 134713
> cpu0: timer 850996016 2000
> cpu1: timer 850995703 2000
> Total 59019354443 138713 
> 
> [root@box /etc]# atacontrol mode ad4
> current mode = SATA300
> [root@box /etc]# atacontrol mode ad6
> current mode = SATA300 
> 
> Some relevant lines from dmesg: 
> 
> atapci0: 
> port
> 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem
> 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0
> atapci0: [ITHREAD]
> atapci0: AHCI Version 01.10 controller with 4 ports detected
> ata2:  on atapci0
> ata2: [ITHREAD]
> ata3:  on atapci0
> ata3: [ITHREAD]
> ata4:  on atapci0
> ata4: [ITHREAD]
> ata5:  on atapci0
> ata5: [ITHREAD] 
> 
> And a few lines from pciconf: 
> 
> atapci0@pci0:0:18:0: class=0x01018f card=0x73271462 chip=0x43801002
> rev=0x00 hdr=0x00
>  vendor = 'ATI Technologies Inc'
>  device = 'IXP SB600 Serial ATA Controller'
>  class = mass storage
>  subclass = ATA 
> 
> ...so - this is where I'm at. Interrupt storm raises through the roof in
> just 3 days, and continues to raise. 
> 
> Just for kicks I tried disabling AHCI with nextboot, but that made the box
> not boot. Also - I'm 1000 KM. away from the box - so I'm a little limited
> to testing fancy boot options - apart from things that can go in
> nextboot.conf. 
> 
> If anyone have any hints on how to proceed, I would be grateful.
> 
> 
> Thank you in advance 
> 
>  - Nicolai
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
take a look of our 'interrupt storm issue' in January, I "resolved" 
similar case by installing KDB/DDB enabled kernel

i suppose that MB is Microstar?

-- 
SY, Marat
From amarat at ksu.ru  Tue Mar 17 09:54:36 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Tue Mar 17 09:54:44 2009
Subject: Crazy "interrupt storm detected" on atapci0
In-Reply-To: <22561413.post@talk.nabble.com>
References: <a0deb29de23c70305123faf1a9d0bae6@relay.dk>
	<22561413.post@talk.nabble.com>
Message-ID: <49BFD57C.5010301@ksu.ru>

Nicolais wrote:
> Also - this was extracted from kenv:
> 
> smbios.system.maker="MICRO-STAR INTERANTIONAL CO.,LTD"
> smbios.system.product="MS-7368"

as I supposed in previous message your MB is MicroStar product. So I 
insist that you read thread [1] in freebsd-stable named 'Interrupt 
storm' started by Dan Langille

[1] 
http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047645.html

-- 
SY, Marat
From gcr+freebsd-stable at tharned.org  Tue Mar 17 10:20:30 2009
From: gcr+freebsd-stable at tharned.org (Greg Rivers)
Date: Tue Mar 17 10:20:37 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1231599679.1837.13.camel@wombat.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
Message-ID: <alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>

On Sat, 10 Jan 2009, Robert Noland wrote:

> I just merged drm (Direct Rendering) from HEAD.
>
>        - Support for latest Intel chips
>        - Support and fixes for many AMD/ATI chips r500 and below
>        - Support AMD/ATI IGP based chips (rs690/rs485)
>        - Lots of code cleanups
>        - Lots of other fixes and changes since the existing drm
>          is 2+ years old
>
> If you are experiencing a "garbled" screen with certain pci/pci-e based
> radeons, I have another patch in HEAD that isn't included yet.
>

I have a workstation with a [Radeon X600 (PCIE)] card.  The X display has 
been garbled since these DRM updates went in in January, and remains 
garbled with 7.1-STABLE as of yesterday.  As a work-around, I'm running 
the up-to-date 7.1-STABLE system (both world and ports) with a 
7.1-RELEASE-p2 kernel.  The display is fine with the old kernel and X 
works great; I even see dramatically improved performance with the new 
Xorg and EXA acceleration.  Your work is much appreciated.

But the garbled display with the recent DRM still plagues me.

Here's how pciconf identifies the card:
vgapci0@pci0:1:0:0:	class=0x030000 card=0x06021002 chip=0x5b621002 rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'RV380 RADEON X600 Series 265MB'
     class      = display
     subclass   = VGA
vgapci1@pci0:1:0:1:	class=0x038000 card=0x06031002 chip=0x5b721002 rev=0x00 hdr=0x00
     vendor     = 'ATI Technologies Inc'
     device     = 'Radeon X600 Series - Secondary'
     class      = display

The old DRM probe:
vgapci0: <VGA-compatible display> port 0x2000-0x20ff mem 0xe0000000-0xe7ffffff,0xe8500000-0xe850ffff irq 16 at device 0.0 on pci1
drm0: <ATI Radeon RV370 X600 Pro> on vgapci0
info: [drm] Initialized radeon 1.25.0 20060524
vgapci1: <VGA-compatible display> mem 0xe8510000-0xe851ffff at device 0.1 on pci1
...
vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xe8500000
vgapci0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xe0000000
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R300 Microcode
info: [drm] writeback test succeeded in 1 usecs
ioapic0: Assigning PCI IRQ 16 to local APIC 0
ioapic0: routing intpin 16 (PCI IRQ 16) to vector 60
drm0: [MPSAFE]

The new DRM probe:
vgapci0: <VGA-compatible display> port 0x2000-0x20ff mem 0xe0000000-0xe7ffffff,0xe8500000-0xe850ffff irq 16 at device 0.0 on pci1
drm0: <ATI Radeon RV370 X600 Pro> on vgapci0
vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xe8500000
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.29.0 20080528
vgapci1: <VGA-compatible display> mem 0xe8510000-0xe851ffff at device 0.1 on pci1
...
vgapci0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xe0000000
info: [drm] Setting GART location based on new memory map
info: [drm] Loading R300 Microcode
info: [drm] Num pipes: 1
info: [drm] writeback test succeeded in 1 usecs
ioapic0: Assigning PCI IRQ 16 to local APIC 0
ioapic0: routing intpin 16 (PCI IRQ 16) to vector 59
drm0: [MPSAFE]
drm0: [ITHREAD]
info: [drm] Num pipes: 1

Difference between the Xorg logs when it's working and when it's not:
--- ok/Xorg.0.log	2009-03-16 14:39:40.000000000 -0500
+++ garbled/Xorg.0.log	2009-03-16 14:46:13.000000000 -0500
@@ -6 +6 @@
-Current Operating System: FreeBSD xxx.xxx.xxxxx.xxx 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #0: Fri Jan 16 18:00:35 CST 2009     root@xxx.xxx.xxxxx.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386
+Current Operating System: FreeBSD xxx.xxx.xxxxx.xxx 7.1-STABLE FreeBSD 7.1-STABLE #0: Mon Mar 16 11:42:42 CDT 2009     root@xxx.xxx.xxxxx.xxx:/usr/obj/usr/src/sys/SMALL-SMP i386
@@ -14 +14 @@
-(==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 16 14:39:34 2009
+(==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 16 14:22:00 2009
@@ -407 +407 @@
-(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.25.0
+(II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.29.0
@@ -774,5 +774,5 @@
-(II) RADEON(0): [pci] 32768 kB allocated with handle 0xc56d4000
-(II) RADEON(0): [pci] ring handle = 0xc56d4000
-(II) RADEON(0): [pci] Ring mapped at 0x90a00000
-(II) RADEON(0): [pci] Ring contents 0x00000000
-(II) RADEON(0): [pci] ring read ptr handle = 0xc57d5000
+(II) RADEON(0): [pci] 32768 kB allocated with handle 0xe7732000
+(II) RADEON(0): [pci] ring handle = 0xe7732000
+(II) RADEON(0): [pci] Ring mapped at 0x88a00000
+(II) RADEON(0): [pci] Ring contents 0xff7d8c94
+(II) RADEON(0): [pci] ring read ptr handle = 0xe7833000
@@ -780,6 +780,6 @@
-(II) RADEON(0): [pci] Ring read ptr contents 0x00000000
-(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xc57d6000
-(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x90b01000
-(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000
-(II) RADEON(0): [pci] GART texture map handle = 0xc59d6000
-(II) RADEON(0): [pci] GART Texture map mapped at 0x90d01000
+(II) RADEON(0): [pci] Ring read ptr contents 0xff180000
+(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xe7834000
+(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x90c00000
+(II) RADEON(0): [pci] Vertex/indirect buffers contents 0xff100049
+(II) RADEON(0): [pci] GART texture map handle = 0xe7a34000
+(II) RADEON(0): [pci] GART Texture map mapped at 0x90e34000
@@ -806 +805,0 @@
-(WW) RADEON(0): Failed to determine num pipes from DRM, falling back to manual look-up!

I tried setting hw.dri.0.debug=1.  That produced a lot of output, but 
nothing that looked like an error or warning.  Do you have any idea what 
might be causing this, or how to troubleshoot further?

-- 
Greg Rivers
From torfinn.ingolfsen at broadpark.no  Tue Mar 17 10:35:04 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Tue Mar 17 10:35:12 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <F45354D5-B9EE-42A9-80CA-59234B2FF496@airwired.net>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
	<ca3526250903161201w303977beg446c6623b49b2ce4@mail.gmail.com>
	<F5D70E08-3496-4D81-9E57-E0E53223A88A@airwired.net>
	<20090316224203.0781a280@baby-jane.lamaiziere.net>
	<F45354D5-B9EE-42A9-80CA-59234B2FF496@airwired.net>
Message-ID: <20090317183502.11d8575b.torfinn.ingolfsen@broadpark.no>

On Mon, 16 Mar 2009 17:23:09 -0600
Dan Allen <danallen46@airwired.net> wrote:

> It turns out that one must have a debug kernel around.  I use STABLE  
> as a production system.  There is no "kernel.debug" on my system.  I  
> guess I therefore cannot provide a stack trace.

Have you disbled building of the kernel.debug then? It is enabled as
default on -STABLE.
root@kg-work2# uname -a
FreeBSD kg-work2.kg4.no 7.1-STABLE FreeBSD 7.1-STABLE #4: Sun Feb  8 20:56:08 CET 2009     root@kg-work2.kg4.no:/usr/obj/usr/src/sys/SX270  i386
root@kg-work2# locate kernel.debug
/usr/obj/usr/src/sys/GENERIC/kernel.debug
/usr/obj/usr/src/sys/SX270/kernel.debug

HTH
-- 
Regards,
Torfinn Ingolfsen

From squirrel at mail.isot.com  Tue Mar 17 11:31:45 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Tue Mar 17 11:31:52 2009
Subject: general: warning: max open files (3636) is smaller than max sockets
	(4096)
Message-ID: <e0836f3fad4cf498156082eb15e1ece2@mail.isot.com>

This happend since I've upgraded bind 9.21 to 9.6.0.  I've increased the max open files to 4096:

   sysctl -w kern.maxfiles=4096

which shows it resized from 4040->4096

But I guess it's different for bind?  I've googled and found several references to this warning message, but everyone states it's not a problem and shouldn't be concerned.  Some real advice would be appreciated.
From dkelly at hiwaay.net  Tue Mar 17 12:30:35 2009
From: dkelly at hiwaay.net (David Kelly)
Date: Tue Mar 17 12:30:42 2009
Subject: general: warning: max open files (3636) is smaller than max
	sockets (4096)
In-Reply-To: <e0836f3fad4cf498156082eb15e1ece2@mail.isot.com>
References: <e0836f3fad4cf498156082eb15e1ece2@mail.isot.com>
Message-ID: <20090317190352.GA38038@Grumpy.DynDNS.org>

On Tue, Mar 17, 2009 at 12:31:43PM -0600, Squirrel wrote:
> This happend since I've upgraded bind 9.21 to 9.6.0.  I've increased
> the max open files to 4096:
> 
>    sysctl -w kern.maxfiles=4096
> 
> which shows it resized from 4040->4096
> 
> But I guess it's different for bind?  I've googled and found several
> references to this warning message, but everyone states it's not a
> problem and shouldn't be concerned.  Some real advice would be
> appreciated.

Depends a lot as to how busy your name server is, I guess.

Mine is a lightly loaded in internal office use. When my PII 450 MHz
192MB machine issued similar complaint on upgrade of bind I was tricked
into rebooting a machine with over 800 days uptime only to get the exact
same message again.

So I limited the number of sockets named would ask for using this in
/etc/rc.conf:

named_flags="-4 -S 1024"

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.
From hk at alogis.com  Tue Mar 17 12:33:59 2009
From: hk at alogis.com (Holger Kipp)
Date: Tue Mar 17 12:34:06 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
Message-ID: <20090317193341.GA77837@intserv.int1.b.intern>

On Tue, Mar 17, 2009 at 10:19:11AM -0400, Ken Smith wrote:
> 
> We're starting the release process for FreeBSD 7.2-RELEASE.  The major
> highlights of the schedule are:

Is there a chance the latest ZFS bugfixes from CURRENT will make it
into 7.2-RELEASE?

Regards,
Holger


From rnoland at FreeBSD.org  Tue Mar 17 12:38:08 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Mar 17 12:38:23 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
Message-ID: <1237318671.1728.7.camel@balrog.2hip.net>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090317/bec28f85/attachment.pgp
From squirrel at mail.isot.com  Tue Mar 17 13:41:39 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Tue Mar 17 13:41:52 2009
Subject: general: warning: max open files (3636) is smaller than
	maxsockets (4096)
Message-ID: <1ab6f1a2ff9684e6f3df38b015305ba1@mail.isot.com>

Nice!!!

Thank you.

-----------------------
PCShare.Com

-----Original message-----
From: David Kelly dkelly@hiwaay.net
Date: Tue, 17 Mar 2009 20:32:10 -0600
To: Squirrel squirrel@mail.isot.com
Subject: Re: general: warning: max open files (3636) is smaller than maxsockets (4096)

> On Tue, Mar 17, 2009 at 12:31:43PM -0600, Squirrel wrote:
> > This happend since I've upgraded bind 9.21 to 9.6.0.  I've increased
> > the max open files to 4096:
> > 
> >    sysctl -w kern.maxfiles=4096
> > 
> > which shows it resized from 4040->4096
> > 
> > But I guess it's different for bind?  I've googled and found several
> > references to this warning message, but everyone states it's not a
> > problem and shouldn't be concerned.  Some real advice would be
> > appreciated.
> 
> Depends a lot as to how busy your name server is, I guess.
> 
> Mine is a lightly loaded in internal office use. When my PII 450 MHz
> 192MB machine issued similar complaint on upgrade of bind I was tricked
> into rebooting a machine with over 800 days uptime only to get the exact
> same message again.
> 
> So I limited the number of sockets named would ask for using this in
> /etc/rc.conf:
> 
> named_flags="-4 -S 1024"
> 
> -- 
> David Kelly N4HHE, dkelly@HiWAAY.net
> ========================================================================
> Whom computers would destroy, they must first drive mad.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
From pluknet at gmail.com  Tue Mar 17 14:26:14 2009
From: pluknet at gmail.com (pluknet)
Date: Tue Mar 17 14:26:21 2009
Subject: KLD cbb.ko: depends on exca - not available
Message-ID: <a31046fc0903171426w16c1ae01l1fe51d579a08dd9c@mail.gmail.com>

Hi.

FreeBSD 7-STABLE.

Subj message appears when I try to kldload cbb.ko and kernel
cannot find exca due to its non-existence.
The pccbb(4) manpage doesn't mention exca.

make install exca helps with kldload, now:
cbb0: <TI4510 PCI-CardBus Bridge> at device 1.0 on pci1
cbb0: [ITHREAD]

Would it be correct to add a new entry to the pccbb synopsis?

--- src/share/man/man4/pccbb.4.orig        2009-03-18 00:22:09.000000000 +0300
+++ src/share/man/man4/pccbb.4     2009-03-18 00:22:42.000000000 +0300
@@ -34,6 +34,7 @@
 .Cd device cbb
 .Cd device pccard
 .Cd device cardbus
+.Cd device exca
 .Sh DESCRIPTION
 The
 .Nm


-- 
wbr,
pluknet
From squirrel at mail.isot.com  Tue Mar 17 14:40:47 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Tue Mar 17 14:40:55 2009
Subject: rndc: connect failed: 127.0.0.1#953: connection refused
Message-ID: <a035ff0bce7803787bd454078722a2a9@mail.isot.com>

My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:

   root@ns2# named -4 -S 1024 -c /etc/namedb/named.conf

But it won't start on boot and no error messages or log.  And it won't start using rndc, it cause error message.  Why does the error shows port 953 when I specified for port 53 in the config?

   rndc: connect failed: 127.0.0.1#953: connection refused


Below are parts of my configs:

/etc/rc.conf:
   named_enable="YES"
   named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
   ....

/etc/rndc.key:
   key "rndc-key" {
        algorithm hmac-md5;
        secret "y9eca/WZydNfi.......................";
   };

/etc/namedb/rndc.conf:
   include "/etc/namedb/rndc.key";  
   options {
        default-server  localhost;
        default-key     "rndc-key";
   };
   server localhost {
        key     "rndc-key";
   };
   ...

/etc/namedb/named.conf:
   include "/etc/namedb/rndc.key";
   acl internals {  
               aa.bb.cc.0/20;
               192.168.1.0/24;
               127.0.0.0/8;
   };
   controls {
        inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
   };
   options {
        pid-file "/var/run/named.pid";
        directory "/etc/namedb";
        statistics-file "/var/log/named/named.stats";
        dump-file "/var/log/named/named.dump";
        zone-statistics yes;
        allow-query { 127.0.0.1; 66.187.80.0/20; };
   };
   logging {
        category "default"   { simple_log; };
        channel simple_log {
                file "/var/log/named/named.log" versions 5 size 20m;
                severity warning;
                print-time yes;
                print-category yes;
                print-severity yes;
   };
   ...


-----------------------
PCShare.Com

From squirrel at mail.isot.com  Tue Mar 17 15:35:53 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Tue Mar 17 15:36:02 2009
Subject: rndc: connect failed: 127.0.0.1#953: connection refused
Message-ID: <e445554a4595ab43dfdf3b85b8b5fb4d@mail.isot.com>

Will, just for heck of it, I've changed the default ports to 953 on both named.conf and rndc.conf, but still same error.


-----Original message-----
From: Squirrel squirrel@mail.isot.com
Date: Tue, 17 Mar 2009 22:41:26 -0600
To: freebsd-stable freebsd-stable@freebsd.org
Subject: rndc: connect failed: 127.0.0.1#953: connection refused

> My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
> 
>    root@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
> 
> But it won't start on boot and no error messages or log.  And it won't start using rndc, it cause error message.  Why does the error shows port 953 when I specified for port 53 in the config?
> 
>    rndc: connect failed: 127.0.0.1#953: connection refused
> 
> 
> Below are parts of my configs:
> 
> /etc/rc.conf:
>    named_enable="YES"
>    named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
>    ....
> 
> /etc/rndc.key:
>    key "rndc-key" {
>         algorithm hmac-md5;
>         secret "y9eca/WZydNfi.......................";
>    };
> 
> /etc/namedb/rndc.conf:
>    include "/etc/namedb/rndc.key";  
>    options {
>         default-server  localhost;
>         default-key     "rndc-key";
>    };
>    server localhost {
>         key     "rndc-key";
>    };
>    ...
> 
> /etc/namedb/named.conf:
>    include "/etc/namedb/rndc.key";
>    acl internals {  
>                aa.bb.cc.0/20;
>                192.168.1.0/24;
>                127.0.0.0/8;
>    };
>    controls {
>         inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
>    };
>    options {
>         pid-file "/var/run/named.pid";
>         directory "/etc/namedb";
>         statistics-file "/var/log/named/named.stats";
>         dump-file "/var/log/named/named.dump";
>         zone-statistics yes;
>         allow-query { 127.0.0.1; 66.187.80.0/20; };
>    };
>    logging {
>         category "default"   { simple_log; };
>         channel simple_log {
>                 file "/var/log/named/named.log" versions 5 size 20m;
>                 severity warning;
>                 print-time yes;
>                 print-category yes;
>                 print-severity yes;
>    };
>    ...
> 
> 
> -----------------------
> PCShare.Com
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
From Mark_Andrews at isc.org  Tue Mar 17 16:21:15 2009
From: Mark_Andrews at isc.org (Mark Andrews)
Date: Tue Mar 17 16:21:23 2009
Subject: rndc: connect failed: 127.0.0.1#953: connection refused 
In-Reply-To: Your message of "Tue, 17 Mar 2009 15:40:47 MDT."
	<a035ff0bce7803787bd454078722a2a9@mail.isot.com> 
Message-ID: <200903172321.n2HNL9u8047856@drugs.dv.isc.org>


In message <a035ff0bce7803787bd454078722a2a9@mail.isot.com>, Squirrel writes:
> My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
> 
>    root@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
> 
> But it won't start on boot and no error messages or log.  And it won't start 
> using rndc, it cause error message.  Why does the error shows port 953 when I
> specified for port 53 in the config?

	Port 53 is for DNS.
	Port 952 is the default port for RNDC.
 
>    rndc: connect failed: 127.0.0.1#953: connection refused
	
	Run "named -4 -S 1024 -c /etc/namedb/named.conf -g" and read the
	messages.

> Below are parts of my configs:
> 
> /etc/rc.conf:
>    named_enable="YES"
>    named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
>    ....
> 
> /etc/rndc.key:
>    key "rndc-key" {
>         algorithm hmac-md5;
>         secret "y9eca/WZydNfi.......................";
>    };
> 
> /etc/namedb/rndc.conf:
>    include "/etc/namedb/rndc.key";  
>    options {
>         default-server  localhost;
>         default-key     "rndc-key";
>    };
>    server localhost {
>         key     "rndc-key";
>    };
>    ...
> 
> /etc/namedb/named.conf:
>    include "/etc/namedb/rndc.key";
>    acl internals {  
>                aa.bb.cc.0/20;
>                192.168.1.0/24;
>                127.0.0.0/8;
>    };
>    controls {
>         inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
>    };
>    options {
>         pid-file "/var/run/named.pid";
>         directory "/etc/namedb";
>         statistics-file "/var/log/named/named.stats";
>         dump-file "/var/log/named/named.dump";
>         zone-statistics yes;
>         allow-query { 127.0.0.1; 66.187.80.0/20; };
>    };
>    logging {
>         category "default"   { simple_log; };
>         channel simple_log {
>                 file "/var/log/named/named.log" versions 5 size 20m;
>                 severity warning;
>                 print-time yes;
>                 print-category yes;
>                 print-severity yes;
>    };
>    ...
> 
> 
> -----------------------
> PCShare.Com
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
From gcr+freebsd-stable at tharned.org  Tue Mar 17 16:24:31 2009
From: gcr+freebsd-stable at tharned.org (Greg Rivers)
Date: Tue Mar 17 16:24:39 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1237318671.1728.7.camel@balrog.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
Message-ID: <alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>

On Tue, 17 Mar 2009, Robert Noland wrote:

> On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote:
>> On Sat, 10 Jan 2009, Robert Noland wrote:
>>
>>> I just merged drm (Direct Rendering) from HEAD.
>>>
>>>        - Support for latest Intel chips
>>>        - Support and fixes for many AMD/ATI chips r500 and below
>>>        - Support AMD/ATI IGP based chips (rs690/rs485)
>>>        - Lots of code cleanups
>>>        - Lots of other fixes and changes since the existing drm
>>>          is 2+ years old
>>>
>>> If you are experiencing a "garbled" screen with certain pci/pci-e based
>>> radeons, I have another patch in HEAD that isn't included yet.
>>>
>>
>> I have a workstation with a [Radeon X600 (PCIE)] card.  The X display has
>> been garbled since these DRM updates went in in January, and remains
>> garbled with 7.1-STABLE as of yesterday.  As a work-around, I'm running
>> the up-to-date 7.1-STABLE system (both world and ports) with a
>> 7.1-RELEASE-p2 kernel.  The display is fine with the old kernel and X
>> works great; I even see dramatically improved performance with the new
>> Xorg and EXA acceleration.  Your work is much appreciated.
>>
>> But the garbled display with the recent DRM still plagues me.
>>
>> [snip]
>
> Could you try the attached patch.
>

Unfortunately, there is no noticeable difference with this patch.


> Also, I'm guessing that this is a PCI based card, right?  Also, it isn't 
> an integrated model?
>

Yes, this is a PCIEx16 card in a HP Compaq dc7600 desktop PC, not a 
motherboard integrated adapter.

Thanks for your help.  I'm willing to spend some time debugging this; 
please let me know if there's more information I can provide or other 
tests or patches I can try.

-- 
Greg Rivers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drm_bufs.patch
Type: text/x-patch
Size: 315 bytes
Desc: 
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090317/43b059bc/drm_bufs.bin
From ronald-freebsd8 at klop.yi.org  Tue Mar 17 17:03:12 2009
From: ronald-freebsd8 at klop.yi.org (Ronald Klop)
Date: Tue Mar 17 17:03:26 2009
Subject: Radeon r6/7xx support merged to -STABLE
In-Reply-To: <1237142952.1774.22.camel@balrog.2hip.net>
References: <1237142952.1774.22.camel@balrog.2hip.net>
Message-ID: <op.uqym1htm8527sy@82-170-177-25.ip.telfort.nl>

On Sun, 15 Mar 2009 19:49:12 +0100, Robert Noland <rnoland@freebsd.org>  
wrote:

> I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago.
>
> The current xorg drivers will not enable it by default on R600+ chips.
> You will need to be using xf86-video-ati-6.12.0,
> xf86-video-radeonhd-devel or possibly even better git master of either.
>
> You will need to add the following to the Device section of your
> xorg.conf to enable it.  If you are experiencing issues, commenting
> these two options out, will prevent Xorg from auto-loading the kernel
> module.
>
> Options "DRI"
> Options "AccelMethod" "EXA"
>
> robert.

Thanks. I currently have EXA accel on my system with  
xf86-video-ati-6.12.0, which makes KDE 4 a lot better already.

drm0: <Radeon HD 2400 XT> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized radeon 1.29.0 20080528
info: [drm] Setting GART location based on new memory map
info: [drm] Loading RV610 CP Microcode
info: [drm] Loading RV610 PFP Microcode
info: [drm] Resetting GPU
info: [drm] writeback test succeeded in 1 usecs
drm0: [ITHREAD]

Cheers,

Ronald.
From squirrel at mail.isot.com  Tue Mar 17 17:10:44 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Tue Mar 17 17:10:52 2009
Subject: rndc: connect failed: 127.0.0.1#953: connection refused
Message-ID: <62de997279f74262f2f10e7f96604867@mail.isot.com>

I realized that default for RNDC was 953, and forced it to 53, but was still getting the same error.

As you recommended, I used the '-g' and noticed only unusual thing was:

   /etc/namedb/named.conf:23: couldn't add command channel 127.0.0.1#53: address in use

So I took out the port 53 out of the named.conf and let it use the default.  But left port 53 on rdnc.conf.  When I restarted with '-g', that message above is gone and all looks good.  Strangely, two doesn't make sense are:

   listening on IPv4 interface rl0, 66.187.80.4#53
   command channel listening on 127.0.0.1#953

By default is #53, and in rndc.conf forced to port #53, but the named displays port #953 for command channel.  Is the RNDC supposed run on port 953 in addition to named running on 53?  I can't seem to get rndc to run on #53.   I've also tried removoing port to default on rndc.conf.

And reboot still won't load named.  And manual rndc load still errors with original message.

Below are the current messages:

root@ns2# named -4 -S 1024 -c /etc/namedb/named.conf -g
17-Mar-2009 19:04:50.001 starting BIND 9.6.0-P1 -4 -S 1024 -c /etc/namedb/named.conf -g
17-Mar-2009 19:04:50.001 built with '--localstatedir=/var' '--disable-linux-caps' '--with-randomdev=/dev/random' '--with-openssl=/usr/local' '--with-libxml2=/usr/local' '--without-idn' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--disable-threads' '--sysconfdir=/etc/namedb' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info/' '--build=i386-portbld-freebsd6.2' 'build_alias=i386-portbld-freebsd6.2' 'CC=cc' 'CFLAGS=-O2 -fno-strict-aliasing -pipe' 'LDFLAGS= -rpath=/usr/local/lib' 'CXX=c++' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe'
17-Mar-2009 19:04:50.001 using up to 1024 sockets
17-Mar-2009 19:04:50.068 loading configuration from '/etc/namedb/named.conf'
17-Mar-2009 19:04:50.124 using default UDP/IPv4 port range: [49152, 65535]
17-Mar-2009 19:04:50.124 using default UDP/IPv6 port range: [49152, 65535]
17-Mar-2009 19:04:50.127 no IPv6 interfaces found
17-Mar-2009 19:04:50.127 listening on IPv4 interface rl0, aa.bb.cc.4#53
17-Mar-2009 19:04:50.128 listening on IPv4 interface rl0, aa.bb.cc.10#53
17-Mar-2009 19:04:50.128 listening on IPv4 interface lo0, 127.0.0.1#53
17-Mar-2009 19:04:50.143 automatic empty zone: 0.IN-ADDR.ARPA
17-Mar-2009 19:04:50.143 automatic empty zone: 127.IN-ADDR.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 254.169.IN-ADDR.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 2.0.192.IN-ADDR.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: D.F.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 8.E.F.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: 9.E.F.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: A.E.F.IP6.ARPA
17-Mar-2009 19:04:50.144 automatic empty zone: B.E.F.IP6.ARPA
17-Mar-2009 19:04:50.146 command channel listening on 127.0.0.1#953
17-Mar-2009 19:04:50.147 ignoring config file logging statement due to -g option
17-Mar-2009 19:04:50.168 zone 0.0.127.IN-ADDR.ARPA/IN: loaded serial 20060213
....


-----Original message-----
From: Mark Andrews Mark_Andrews@isc.org
Date: Wed, 18 Mar 2009 00:21:52 -0600
To: Squirrel squirrel@mail.isot.com
Subject: Re: rndc: connect failed: 127.0.0.1#953: connection refused

> 
> In message <a035ff0bce7803787bd454078722a2a9@mail.isot.com>, Squirrel writes:
> > My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
> > 
> >    root@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
> > 
> > But it won't start on boot and no error messages or log.  And it won't start 
> > using rndc, it cause error message.  Why does the error shows port 953 when I
> > specified for port 53 in the config?
> 
> 	Port 53 is for DNS.
> 	Port 952 is the default port for RNDC.
>  
> >    rndc: connect failed: 127.0.0.1#953: connection refused
> 	
> 	Run "named -4 -S 1024 -c /etc/namedb/named.conf -g" and read the
> 	messages.
> 
> > Below are parts of my configs:
> > 
> > /etc/rc.conf:
> >    named_enable="YES"
> >    named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
> >    ....
> > 
> > /etc/rndc.key:
> >    key "rndc-key" {
> >         algorithm hmac-md5;
> >         secret "y9eca/WZydNfi.......................";
> >    };
> > 
> > /etc/namedb/rndc.conf:
> >    include "/etc/namedb/rndc.key";  
> >    options {
> >         default-server  localhost;
> >         default-key     "rndc-key";
> >    };
> >    server localhost {
> >         key     "rndc-key";
> >    };
> >    ...
> > 
> > /etc/namedb/named.conf:
> >    include "/etc/namedb/rndc.key";
> >    acl internals {  
> >                aa.bb.cc.0/20;
> >                192.168.1.0/24;
> >                127.0.0.0/8;
> >    };
> >    controls {
> >         inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
> >    };
> >    options {
> >         pid-file "/var/run/named.pid";
> >         directory "/etc/namedb";
> >         statistics-file "/var/log/named/named.stats";
> >         dump-file "/var/log/named/named.dump";
> >         zone-statistics yes;
> >         allow-query { 127.0.0.1; 66.187.80.0/20; };
> >    };
> >    logging {
> >         category "default"   { simple_log; };
> >         channel simple_log {
> >                 file "/var/log/named/named.log" versions 5 size 20m;
> >                 severity warning;
> >                 print-time yes;
> >                 print-category yes;
> >                 print-severity yes;
> >    };
> >    ...
> > 
> > 
> > -----------------------
> > PCShare.Com
> > 
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
From peter at simons-rock.edu  Tue Mar 17 17:13:15 2009
From: peter at simons-rock.edu (Peter C. Lai)
Date: Tue Mar 17 17:13:25 2009
Subject: rndc: connect failed: 127.0.0.1#953: connection refused
In-Reply-To: <62de997279f74262f2f10e7f96604867@mail.isot.com>
References: <62de997279f74262f2f10e7f96604867@mail.isot.com>
Message-ID: <20090318001311.GW13398@cesium.hyperfine.info>

Yes that is exactly the point. RNDC is supposed to run on 953 and the name
service itself is on 53. Think about it, if tcp/53 is used for real DNS
(jumbo RR) traffic, how can rndc be listening for commands on the same
channel?

On 2009-03-17 06:10:44PM -0600, Squirrel wrote:
> I realized that default for RNDC was 953, and forced it to 53, but was still getting the same error.
> 
> As you recommended, I used the '-g' and noticed only unusual thing was:
> 
>    /etc/namedb/named.conf:23: couldn't add command channel 127.0.0.1#53: address in use
> 
> So I took out the port 53 out of the named.conf and let it use the default.  But left port 53 on rdnc.conf.  When I restarted with '-g', that message above is gone and all looks good.  Strangely, two doesn't make sense are:
> 
>    listening on IPv4 interface rl0, 66.187.80.4#53
>    command channel listening on 127.0.0.1#953
> 
> By default is #53, and in rndc.conf forced to port #53, but the named displays port #953 for command channel.  Is the RNDC supposed run on port 953 in addition to named running on 53?  I can't seem to get rndc to run on #53.   I've also tried removoing port to default on rndc.conf.
> 
> And reboot still won't load named.  And manual rndc load still errors with original message.
> 
> Below are the current messages:
> 
> root@ns2# named -4 -S 1024 -c /etc/namedb/named.conf -g
> 17-Mar-2009 19:04:50.001 starting BIND 9.6.0-P1 -4 -S 1024 -c /etc/namedb/named.conf -g
> 17-Mar-2009 19:04:50.001 built with '--localstatedir=/var' '--disable-linux-caps' '--with-randomdev=/dev/random' '--with-openssl=/usr/local' '--with-libxml2=/usr/local' '--without-idn' 'STD_CDEFINES=-DDIG_SIGCHASE=1' '--disable-threads' '--sysconfdir=/etc/namedb' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info/' '--build=i386-portbld-freebsd6.2' 'build_alias=i386-portbld-freebsd6.2' 'CC=cc' 'CFLAGS=-O2 -fno-strict-aliasing -pipe' 'LDFLAGS= -rpath=/usr/local/lib' 'CXX=c++' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe'
> 17-Mar-2009 19:04:50.001 using up to 1024 sockets
> 17-Mar-2009 19:04:50.068 loading configuration from '/etc/namedb/named.conf'
> 17-Mar-2009 19:04:50.124 using default UDP/IPv4 port range: [49152, 65535]
> 17-Mar-2009 19:04:50.124 using default UDP/IPv6 port range: [49152, 65535]
> 17-Mar-2009 19:04:50.127 no IPv6 interfaces found
> 17-Mar-2009 19:04:50.127 listening on IPv4 interface rl0, aa.bb.cc.4#53
> 17-Mar-2009 19:04:50.128 listening on IPv4 interface rl0, aa.bb.cc.10#53
> 17-Mar-2009 19:04:50.128 listening on IPv4 interface lo0, 127.0.0.1#53
> 17-Mar-2009 19:04:50.143 automatic empty zone: 0.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.143 automatic empty zone: 127.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 254.169.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 2.0.192.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: D.F.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 8.E.F.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: 9.E.F.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: A.E.F.IP6.ARPA
> 17-Mar-2009 19:04:50.144 automatic empty zone: B.E.F.IP6.ARPA
> 17-Mar-2009 19:04:50.146 command channel listening on 127.0.0.1#953
> 17-Mar-2009 19:04:50.147 ignoring config file logging statement due to -g option
> 17-Mar-2009 19:04:50.168 zone 0.0.127.IN-ADDR.ARPA/IN: loaded serial 20060213
> ....
> 
> 
> -----Original message-----
> From: Mark Andrews Mark_Andrews@isc.org
> Date: Wed, 18 Mar 2009 00:21:52 -0600
> To: Squirrel squirrel@mail.isot.com
> Subject: Re: rndc: connect failed: 127.0.0.1#953: connection refused
> 
> > 
> > In message <a035ff0bce7803787bd454078722a2a9@mail.isot.com>, Squirrel writes:
> > > My BIND9.6.0 on FreeBSD 6.2 works fine when I manually start with:
> > > 
> > >    root@ns2# named -4 -S 1024 -c /etc/namedb/named.conf
> > > 
> > > But it won't start on boot and no error messages or log.  And it won't start 
> > > using rndc, it cause error message.  Why does the error shows port 953 when I
> > > specified for port 53 in the config?
> > 
> > 	Port 53 is for DNS.
> > 	Port 952 is the default port for RNDC.
> >  
> > >    rndc: connect failed: 127.0.0.1#953: connection refused
> > 	
> > 	Run "named -4 -S 1024 -c /etc/namedb/named.conf -g" and read the
> > 	messages.
> > 
> > > Below are parts of my configs:
> > > 
> > > /etc/rc.conf:
> > >    named_enable="YES"
> > >    named_flags="-4 -S 1024 -c /etc/namedb/named.conf"
> > >    ....
> > > 
> > > /etc/rndc.key:
> > >    key "rndc-key" {
> > >         algorithm hmac-md5;
> > >         secret "y9eca/WZydNfi.......................";
> > >    };
> > > 
> > > /etc/namedb/rndc.conf:
> > >    include "/etc/namedb/rndc.key";  
> > >    options {
> > >         default-server  localhost;
> > >         default-key     "rndc-key";
> > >    };
> > >    server localhost {
> > >         key     "rndc-key";
> > >    };
> > >    ...
> > > 
> > > /etc/namedb/named.conf:
> > >    include "/etc/namedb/rndc.key";
> > >    acl internals {  
> > >                aa.bb.cc.0/20;
> > >                192.168.1.0/24;
> > >                127.0.0.0/8;
> > >    };
> > >    controls {
> > >         inet 127.0.0.1 port 53 allow { 127.0.0.1; } keys { rndc-key; };
> > >    };
> > >    options {
> > >         pid-file "/var/run/named.pid";
> > >         directory "/etc/namedb";
> > >         statistics-file "/var/log/named/named.stats";
> > >         dump-file "/var/log/named/named.dump";
> > >         zone-statistics yes;
> > >         allow-query { 127.0.0.1; 66.187.80.0/20; };
> > >    };
> > >    logging {
> > >         category "default"   { simple_log; };
> > >         channel simple_log {
> > >                 file "/var/log/named/named.log" versions 5 size 20m;
> > >                 severity warning;
> > >                 print-time yes;
> > >                 print-category yes;
> > >                 print-severity yes;
> > >    };
> > >    ...
> > > 
> > > 
> > > -----------------------
> > > PCShare.Com
> > > 
> > > _______________________________________________
> > > freebsd-stable@freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

-- 
===========================================================
Peter C. Lai                 | Bard College at Simon's Rock
Systems Administrator        | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu     | (413) 528-7428
===========================================================

From scrappy at hub.org  Tue Mar 17 17:38:14 2009
From: scrappy at hub.org (Marc G. Fournier)
Date: Tue Mar 17 17:38:20 2009
Subject: vmstat memory: avm vs fre
Message-ID: <20090317211357.B97234@hub.org>


I'm getting a really odd condition on one of my servers (and I suspect its 
happening on one of my other servers as well) ... after a period of time 
(<3 days), the server hangs solid ...

Running vmstat in an xterm, the one thing I'm noticing is that when it 
hangs, my avm == 12455M and fre == 22M ... when I start the system, it 
looks like: avm == 246M vs fre == 197M ...

I'm suspecting that the lock up is that fre hit 0 at some point, but I'm 
at a loss as to why, or where to look, for this ...

top in another xterm when it hangs shows it appears to have more then 
enough VM:

last pid: 87005;  load averages:  8.57,  7.29,  4.46    up 0+17:25:13  20:45:00
1140 processes:317 running, 774 sleeping, 10 zombie, 39 lock
CPU: 23.3% user,  0.0% nice, 11.1% system,  0.4% interrupt, 65.1% idle
Mem: 4610M Active, 440M Inact, 489M Wired, 13M Cache, 214M Buf, 9624K Free
Swap: 8192M Total, 1055M Used, 7137M Free, 12% Inuse, 564K In, 272K Out
kvm_open: cannot open /proc/90106/mem
   PID JID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU 
COMMAND
30625   0 root        1  96    0   588M   166M RUN    0  14:54  0.10% 
/usr/local/bin/qemu-system-x86_64 -m 512M -net nic,macadd
86866  20   1200      1  96    0 60888K  1140K RUN    0   0:00  0.15% 
postgres: autovacuum worker process    (postgres)
86844   1 root        1  96    0 15080K  1028K RUN    1   0:00  0.05% 
sshd: [accepted] (sshd)
45533  20 root        1  96    0 15044K   456K RUN    1   0:00  0.05% 
/usr/sbin/sshd
86895   0 root        1  96    0 15092K   428K RUN    0   0:00  0.05% 
/usr/sbin/sshd
15131  15 root        1  96    0 19692K   376K RUN    1   0:00  0.15% 
/usr/sbin/sshd
95911   4 www         1   4    0   106M     0K accept 0   0:01  0.00% 
/usr/local/sbin/httpd (<httpd>)


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
From imb at protected-networks.net  Tue Mar 17 19:09:52 2009
From: imb at protected-networks.net (Michael Butler)
Date: Tue Mar 17 19:09:59 2009
Subject: drm change breaks old ATI?
Message-ID: <49C057E9.6010402@protected-networks.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seems that the new drm schema requires an interrupt to attach.

"dmesg" returns:

pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
agp0: <Intel 82443BX (440 BX) host to PCI bridge> on hostb0
pcib1: <PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0x9000-0x90ff mem
	0xd1000000-0xd1ffffff,0xd0100000-0xd0100fff at device 0.0
	on pci1
drm0: <3D Rage Pro AGP 1X/2X> on vgapci0
device_attach: drm0 attach returned 2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 .. which corresponds to ENOENT and "lspci -vvv" gives:


01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP
		1X/2X (rev 5c) (prog-if 00 [VGA controller])
        Subsystem: ATI Technologies Inc Rage Pro Turbo AGP 2X
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
		ParErr- Stepping+ SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
		<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 66 (2000ns min), Cache Line Size: 32 bytes

** ---> Interrupt: pin ? routed to IRQ 255

        Region 0: Memory at d1000000 (32-bit, non-prefetchable)
        Region 1: I/O ports at 9000
        Region 2: Memory at d0100000 (32-bit, non-prefetchable)
        Capabilities: [50] AGP version 1.0
                Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
			HTrans- 64bit- FW- AGP3- Rate=x1,x2
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW-
			Rate=<none>

Didn't this used to work?

	Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAknAV+gACgkQQv9rrgRC1JIiAwCdEmwDBPcTjd97vV3q3kz5kO8R
qA0An3RjPS/ra7CVRd6KfeuOuQoARaVm
=h2qo
-----END PGP SIGNATURE-----
From kama at pvp.se  Wed Mar 18 02:50:56 2009
From: kama at pvp.se (kama)
Date: Wed Mar 18 02:51:04 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
Message-ID: <20090318102134.D55869@ns1.as.pvp.se>



On Tue, 17 Mar 2009, Ken Smith wrote:

>
> We're starting the release process for FreeBSD 7.2-RELEASE.  The major
> highlights of the schedule are:
>
>         Code Freeze:            March 23rd
>         BETA1                   March 30th
>         Branch                  April 10th
>         RC1                     April 13th
>         RC2                     April 20th
>         Release:                May 4th
>
> The full schedule is here:
>
>   http://www.freebsd.org/releases/7.2R/schedule.html
>
> though most of "the other events" haven't been given specific dates yet.
>
> Since it's often the case that developers process quite a few
> outstanding MFCs during the last couple days before a code freeze starts
> I have changed RELENG_7 to say it is 7.2-PRERELEASE now as a bit of a
> heads-up that the release cycle is imminent.  You might need to be a
> tiny bit more careful using RELENG_7 right now because the odds of you
> getting a snapshot of the tree taken part way through someone doing
> something that required multiple commits goes up during this phase of a
> release.
>

Is it possible to get back the todo page during this release phase?

/Bjorn
From rwatson at FreeBSD.org  Wed Mar 18 04:38:11 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Mar 18 04:38:18 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <20090318102134.D55869@ns1.as.pvp.se>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
Message-ID: <alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>


On Wed, 18 Mar 2009, kama wrote:

>> Since it's often the case that developers process quite a few outstanding 
>> MFCs during the last couple days before a code freeze starts I have changed 
>> RELENG_7 to say it is 7.2-PRERELEASE now as a bit of a heads-up that the 
>> release cycle is imminent.  You might need to be a tiny bit more careful 
>> using RELENG_7 right now because the odds of you getting a snapshot of the 
>> tree taken part way through someone doing something that required multiple 
>> commits goes up during this phase of a release.
>
> Is it possible to get back the todo page during this release phase?

One of the most important things for us to keep an eye on in this release is 
that the boot loader now works on a number of pieces of hardware on which it 
reressed for 6.4/7.1.  If it proves successful, we'll likely also do errata 
notes and roll new ISOs for 6.4.

Since superpage support was MFC'd, keeping an eye out for new VM problems is 
important.

A number of audit-related changes have been merged improving support for audit 
pipes, so extra testing of that functionality would be welcome.

It would probably be worth skimming svn logs for stable/7 to see what other 
testing focuses would be particularly useful.

Robert N M Watson
Computer Laboratory
University of Cambridge
From rwatson at FreeBSD.org  Wed Mar 18 04:52:37 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Mar 18 04:52:46 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <1237081381.1581.2.camel@localhost>
References: <1236920519.1490.30.camel@localhost>
	<alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
	<alpine.BSF.2.00.0903130949210.61873@fledge.watson.org>
	<1237020646.1532.24.camel@localhost>
	<alpine.BSF.2.00.0903141756100.27597@fledge.watson.org>
	<1237081381.1581.2.camel@localhost>
Message-ID: <alpine.BSF.2.00.0903181151240.99720@fledge.watson.org>


On Sun, 15 Mar 2009, Nick Withers wrote:

>> I'll need to think a bit about a proper fix for this, but you'll find the 
>> problem likely goes away if you eliminate all uid/gid/jail rules from your 
>> firewall.  You could also tweak the syncache logic not to use a retransmit 
>> timer, which might slightly extend the time it takes for systems to connect 
>> to your host in the presence of packet loss, but would eliminate this 
>> transmission path entirely.  We'll need a real and more general fix, 
>> however, to commit, and I'll look and see what I can come up with.
>
> Brilliant, thanks very much. I'll work without uid rules for the time being, 
> then.

Could I ask you to file a PR on this problem, btw, with the two traces I 
singled out as interesting included, then forward me the PR receipt?  That 
will make the problem easier to keep track of.

We're currently pondering ways to fix the problem that don't disturb the 
stability of the ABI, and may have a workaround patch available shortly that's 
appropriate for MFC.

Robert N M Watson
Computer Laboratory
University of Cambridge
From kama at pvp.se  Wed Mar 18 04:55:26 2009
From: kama at pvp.se (kama)
Date: Wed Mar 18 04:55:43 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
Message-ID: <20090318124806.K55869@ns1.as.pvp.se>


On Wed, 18 Mar 2009, Robert Watson wrote:

>
> On Wed, 18 Mar 2009, kama wrote:
>
> >> Since it's often the case that developers process quite a few outstanding
> >> MFCs during the last couple days before a code freeze starts I have changed
> >> RELENG_7 to say it is 7.2-PRERELEASE now as a bit of a heads-up that the
> >> release cycle is imminent.  You might need to be a tiny bit more careful
> >> using RELENG_7 right now because the odds of you getting a snapshot of the
> >> tree taken part way through someone doing something that required multiple
> >> commits goes up during this phase of a release.
> >
> > Is it possible to get back the todo page during this release phase?
>
> One of the most important things for us to keep an eye on in this release is
> that the boot loader now works on a number of pieces of hardware on which it
> reressed for 6.4/7.1.  If it proves successful, we'll likely also do errata
> notes and roll new ISOs for 6.4.
>
> Since superpage support was MFC'd, keeping an eye out for new VM problems is
> important.
>
> A number of audit-related changes have been merged improving support for audit
> pipes, so extra testing of that functionality would be welcome.
>
> It would probably be worth skimming svn logs for stable/7 to see what other
> testing focuses would be particularly useful.

What I meant was the todo page on www.freebsd.org.

Like: http://www.freebsd.org/releases/7.2R/TODO.html

Where problems and showstoppers where brought up. I found that information
very valueble. Especially when the release went overdue I could easily see
what caused the delay.

The last release I did not really get information about why the release
was delayed. At least not as easily as reloading a webpage.

Well, just my $0.02...

/Bjorn
From matheus at eternamente.info  Wed Mar 18 04:59:19 2009
From: matheus at eternamente.info (Nenhum_de_Nos)
Date: Wed Mar 18 05:00:03 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
Message-ID: <31fb04d6406bd862c0e2a31286ef532a.squirrel@cygnus.homeunix.com>


On Wed, March 18, 2009 08:38, Robert Watson wrote:
>
> On Wed, 18 Mar 2009, kama wrote:
>
>>> Since it's often the case that developers process quite a few
>>> outstanding
>>> MFCs during the last couple days before a code freeze starts I have
>>> changed
>>> RELENG_7 to say it is 7.2-PRERELEASE now as a bit of a heads-up that
>>> the
>>> release cycle is imminent.  You might need to be a tiny bit more
>>> careful
>>> using RELENG_7 right now because the odds of you getting a snapshot of
>>> the
>>> tree taken part way through someone doing something that required
>>> multiple
>>> commits goes up during this phase of a release.
>>
>> Is it possible to get back the todo page during this release phase?
>
> One of the most important things for us to keep an eye on in this release
> is
> that the boot loader now works on a number of pieces of hardware on which
> it
> reressed for 6.4/7.1.  If it proves successful, we'll likely also do
> errata
> notes and roll new ISOs for 6.4.

from cdrom or the installed one ? I had problems (still have as it doesn't
boot) from usb using via mini itx. would be worth trying again ? (I must
use current, as my usb nic just works under head)

thanks,

matheus

> Since superpage support was MFC'd, keeping an eye out for new VM problems
> is
> important.
>
> A number of audit-related changes have been merged improving support for
> audit
> pipes, so extra testing of that functionality would be welcome.
>
> It would probably be worth skimming svn logs for stable/7 to see what
> other
> testing focuses would be particularly useful.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>


-- 
We will call you cygnus,
The God of balance you shall be

From nick at nickwithers.com  Wed Mar 18 05:33:54 2009
From: nick at nickwithers.com (Nick Withers)
Date: Wed Mar 18 05:34:00 2009
Subject: NICs locking up, "*tcp_sc_h"
In-Reply-To: <alpine.BSF.2.00.0903181151240.99720@fledge.watson.org>
References: <1236920519.1490.30.camel@localhost>
	<alpine.BSF.2.00.0903130935290.61873@fledge.watson.org>
	<alpine.BSF.2.00.0903130949210.61873@fledge.watson.org>
	<1237020646.1532.24.camel@localhost>
	<alpine.BSF.2.00.0903141756100.27597@fledge.watson.org>
	<1237081381.1581.2.camel@localhost>
	<alpine.BSF.2.00.0903181151240.99720@fledge.watson.org>
Message-ID: <1237379619.85532.55.camel@localhost>

On Wed, 2009-03-18 at 11:52 +0000, Robert Watson wrote:
> On Sun, 15 Mar 2009, Nick Withers wrote:
> 
> >> I'll need to think a bit about a proper fix for this, but you'll find the 
> >> problem likely goes away if you eliminate all uid/gid/jail rules from your 
> >> firewall.  You could also tweak the syncache logic not to use a retransmit 
> >> timer, which might slightly extend the time it takes for systems to connect 
> >> to your host in the presence of packet loss, but would eliminate this 
> >> transmission path entirely.  We'll need a real and more general fix, 
> >> however, to commit, and I'll look and see what I can come up with.
> >
> > Brilliant, thanks very much. I'll work without uid rules for the time being, 
> > then.
> 
> Could I ask you to file a PR on this problem, btw, with the two traces I 
> singled out as interesting included, then forward me the PR receipt?  That 
> will make the problem easier to keep track of.

Done - Please see newborn kern/132774!

> We're currently pondering ways to fix the problem that don't disturb the 
> stability of the ABI, and may have a workaround patch available shortly that's 
> appropriate for MFC.

Wow! Must admit I'd assumed this one was going to take a while to sort
out, so I'm certainly happy to hear this.

Cheers very much!

> Robert N M Watson
> Computer Laboratory
> University of Cambridge
-- 
Nick Withers
email: nick@nickwithers.com
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/e3a32eef/attachment.pgp
From kensmith at cse.Buffalo.EDU  Wed Mar 18 05:40:25 2009
From: kensmith at cse.Buffalo.EDU (Ken Smith)
Date: Wed Mar 18 05:40:32 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <20090318102134.D55869@ns1.as.pvp.se>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
Message-ID: <1237380019.30298.3.camel@bauer.cse.buffalo.edu>

On Wed, 2009-03-18 at 10:23 +0100, kama wrote:
> Is it possible to get back the todo page during this release phase?

During the last couple of releases I simply didn't have time to do
everything and this was one of the things that fell by the wayside.

After the dust from 7.1 settled we started to make arrangements for
someone else to set this up and watch over it for us during the release.
It might take him a little time to get rolling with it (as in it might
not appear immediately upon the release cycle starting) but hopefully we
will have something along these lines come back at some point during
this release.

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith@cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/cc86cfda/attachment.pgp
From petefrench at ticketswitch.com  Wed Mar 18 06:01:08 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Wed Mar 18 06:01:14 2009
Subject: Crazy "interrupt storm detected" on atapci0
In-Reply-To: <49BFD57C.5010301@ksu.ru>
Message-ID: <E1LjvOF-000Biu-IM@dilbert.ticketswitch.com>

> as I supposed in previous message your MB is MicroStar product. So I 
> insist that you read thread [1] in freebsd-stable named 'Interrupt 
> storm' started by Dan Langille

I (still) have the same problem on my MSI Platinum .... and having re-read
all of those threads in case I missed somehting, there still isn't a
solution there. All the suggested ones (using 'Linux" as ACPI name, moving
com interrupt ports, disabling onboard ether) are reported as failing
after a few days. Luckily I have a colleague who can reboot the remote
machine, and that has been my solution - but it is not really workable
long term.

(actually this has reminded me to check dmesg, and it seems I need to
reboot this machine due to an interrupt storm right now).

-pete.
From m.e.sanliturk at gmail.com  Wed Mar 18 06:26:34 2009
From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk)
Date: Wed Mar 18 06:26:41 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <20090318124806.K55869@ns1.as.pvp.se>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
	<20090318124806.K55869@ns1.as.pvp.se>
Message-ID: <a333b2be0903180557w12020ad1v689fdc289e729157@mail.gmail.com>

>
> On Wed, 18 Mar 2009, Robert Watson wrote:
>
>
> What I meant was the todo page on www.freebsd.org.
>
> Like: http://www.freebsd.org/releases/7.2R/TODO.html
>
>


The above link is giving Error 404 : Not found .

http://www.freebsd.org/releases/<http://www.freebsd.org/releases/7.2R/TODO.html>page
does NOT have a link to 7.2R . Therefore , it is NOT possible
to reach that page from .../releases/ page .


Thank you very much .

Mehmet Erol Sanliturk
From rwatson at FreeBSD.org  Wed Mar 18 06:38:17 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Wed Mar 18 06:38:24 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <1237380019.30298.3.camel@bauer.cse.buffalo.edu>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
	<1237380019.30298.3.camel@bauer.cse.buffalo.edu>
Message-ID: <alpine.BSF.2.00.0903181335160.99720@fledge.watson.org>

On Wed, 18 Mar 2009, Ken Smith wrote:

> On Wed, 2009-03-18 at 10:23 +0100, kama wrote:
>> Is it possible to get back the todo page during this release phase?
>
> During the last couple of releases I simply didn't have time to do 
> everything and this was one of the things that fell by the wayside.
>
> After the dust from 7.1 settled we started to make arrangements for someone 
> else to set this up and watch over it for us during the release. It might 
> take him a little time to get rolling with it (as in it might not appear 
> immediately upon the release cycle starting) but hopefully we will have 
> something along these lines come back at some point during this release.

While such lists do have downsides ("you shipped even though problem X on your 
showstopper list wasn't fixed!") they also have some nice advantages -- one is 
focusing user community testing time and developer community fixing time.  At 
least in the case of 7.2, though, I'm not aware of any major outstanding 
problems, so focuses for testing are presumably just in the areas of major 
change from 7.1.

Robert N M Watson
Computer Laboratory
University of Cambridge
From amarat at ksu.ru  Wed Mar 18 07:30:26 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Wed Mar 18 07:30:34 2009
Subject: Crazy "interrupt storm detected" on atapci0
In-Reply-To: <E1LjvOF-000Biu-IM@dilbert.ticketswitch.com>
References: <E1LjvOF-000Biu-IM@dilbert.ticketswitch.com>
Message-ID: <49C1055E.7000303@ksu.ru>

Pete French wrote:
>> as I supposed in previous message your MB is MicroStar product. So I 
>> insist that you read thread [1] in freebsd-stable named 'Interrupt 
>> storm' started by Dan Langille
> 
> I (still) have the same problem on my MSI Platinum .... and having re-read
> all of those threads in case I missed somehting, there still isn't a
> solution there. All the suggested ones (using 'Linux" as ACPI name, moving
> com interrupt ports, disabling onboard ether) are reported as failing
> after a few days. Luckily I have a colleague who can reboot the remote
> machine, and that has been my solution - but it is not really workable
> long term.
> 
> (actually this has reminded me to check dmesg, and it seems I need to
> reboot this machine due to an interrupt storm right now).
> 
> -pete.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
did you try to make a kernel with KDB and DDB? DEBUG-kernel? it seems 
that turning off optimization and place a debugging stuff in kernel 
solved my problem.

-- 
SY, marat
From wolfgang at lyxys.ka.sub.org  Wed Mar 18 07:56:49 2009
From: wolfgang at lyxys.ka.sub.org (Wolfgang Zenker)
Date: Wed Mar 18 07:56:57 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <alpine.BSF.2.00.0903181335160.99720@fledge.watson.org>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
	<1237380019.30298.3.camel@bauer.cse.buffalo.edu>
	<alpine.BSF.2.00.0903181335160.99720@fledge.watson.org>
Message-ID: <20090318145633.GA24687@lyxys.ka.sub.org>

* Robert Watson <rwatson@freebsd.org> [090318 14:38]:
> On Wed, 18 Mar 2009, Ken Smith wrote:
>> On Wed, 2009-03-18 at 10:23 +0100, kama wrote:
>>> Is it possible to get back the todo page during this release phase?

>> During the last couple of releases I simply didn't have time to do 
>> everything and this was one of the things that fell by the wayside.

>> After the dust from 7.1 settled we started to make arrangements for 
>> someone else to set this up and watch over it for us during the release. 
>> It might take him a little time to get rolling with it (as in it might not 
>> appear immediately upon the release cycle starting) but hopefully we will 
>> have something along these lines come back at some point during this 
>> release.

> While such lists do have downsides ("you shipped even though problem X on 
> your showstopper list wasn't fixed!") they also have some nice advantages 
> -- one is focusing user community testing time and developer community 
> fixing time.  At least in the case of 7.2, though, I'm not aware of any 
> major outstanding problems, so focuses for testing are presumably just in 
> the areas of major change from 7.1.

One change I have not seen mentioned on stable yet is that we now have
localized libc messages. Might be a good idea to have a look at scripts
that expect to see certain outputs from commands.

Wolfgang
From petefrench at ticketswitch.com  Wed Mar 18 08:09:19 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Wed Mar 18 08:09:26 2009
Subject: Crazy "interrupt storm detected" on atapci0
In-Reply-To: <49C1055E.7000303@ksu.ru>
Message-ID: <E1LjxOK-0000jG-Ku@dilbert.ticketswitch.com>

> did you try to make a kernel with KDB and DDB? DEBUG-kernel? it seems 
> that turning off optimization and place a debugging stuff in kernel 
> solved my problem.

I turned off all optimisation, but I didnt try compiling in the debuggers,
no. I will give that a try and see if it gets rid of the problem. A bit
worrying if so though!

-pete.
From rnoland at FreeBSD.org  Wed Mar 18 10:01:01 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Mar 18 10:01:14 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
Message-ID: <1237395643.1738.3.camel@balrog.2hip.net>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/19e042e3/attachment.pgp
From josep at bellera.cat  Wed Mar 18 10:10:21 2009
From: josep at bellera.cat (Josep Pujadas i Jubany)
Date: Wed Mar 18 10:10:29 2009
Subject: Can't compile rtmpdump source
In-Reply-To: <20090317213903.M57690@bellera.cat>
References: <20090317213903.M57690@bellera.cat>
Message-ID: <20090318163944.M277@bellera.cat>

Hello!

I can't compile rtmpdump source on FreeBSD:

http://sourceforge.net/projects/rtmpdump/

I obtain the following output:

# gmake 
g++ -Wall -c -o bytes.o bytes.cpp 
In file included from bytes.cpp:25: 
bytes.h:37:20: endian.h: No such file or directory 
bytes.h:38:22: byteswap.h: No such file or directory 
bytes.h:45:2: #error "Undefined byte and float word order!" 
bytes.cpp: In function `void WriteNumber(char*, double)': 
bytes.cpp:34: warning: converting to `uint64_t' from `double' 
bytes.cpp: In function `int ReadInt32LE(const char*)': 
bytes.cpp:96: error: `__bswap_32' was not declared in this scope 
bytes.cpp:96: warning: unused variable '__bswap_32' 
bytes.cpp: In function `int EncodeInt32LE(char*, int)': 
bytes.cpp:107: error: `__bswap_32' was not declared in this scope 
bytes.cpp:107: warning: unused variable '__bswap_32' 
gmake: *** [bytes.o] Error 1

The developper told me:

Currently the endian support does not include FreeBSD automatically, but you 
can compile for any system by defining the correct byte order and float word 
order. You also need to make sure the swap macros are compiled as well (they 
are in the Windows setion so far). I will add FreeBSD support in the next 
release, but it shouldn't be to hard to compile v1.4 on your own. 
Btw, uncomment _DEBUG in log.h to compile in release mode (I forgot to do 
that). 

I have no idea how to do the changes.

Here is the source code:

http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/r
/rt/rtmpdump/rtmpdump-v1.4.tar.gz

Regards,

Josep Pujadas

From pluknet at gmail.com  Wed Mar 18 10:38:35 2009
From: pluknet at gmail.com (pluknet)
Date: Wed Mar 18 10:38:42 2009
Subject: Can't compile rtmpdump source
In-Reply-To: <20090318163944.M277@bellera.cat>
References: <20090317213903.M57690@bellera.cat>
	<20090318163944.M277@bellera.cat>
Message-ID: <a31046fc0903181038x7dd03ac7j8a1ed4873e17edfa@mail.gmail.com>

Hi, Josep. Try an attached patch.

2009/3/18 Josep Pujadas i Jubany <josep@bellera.cat>:
> Hello!
>
> I can't compile rtmpdump source on FreeBSD:
>
> http://sourceforge.net/projects/rtmpdump/
>
> I obtain the following output:
>
> # gmake
> g++ -Wall -c -o bytes.o bytes.cpp
> In file included from bytes.cpp:25:
> bytes.h:37:20: endian.h: No such file or directory
> bytes.h:38:22: byteswap.h: No such file or directory
> bytes.h:45:2: #error "Undefined byte and float word order!"
> bytes.cpp: In function `void WriteNumber(char*, double)':
> bytes.cpp:34: warning: converting to `uint64_t' from `double'
> bytes.cpp: In function `int ReadInt32LE(const char*)':
> bytes.cpp:96: error: `__bswap_32' was not declared in this scope
> bytes.cpp:96: warning: unused variable '__bswap_32'
> bytes.cpp: In function `int EncodeInt32LE(char*, int)':
> bytes.cpp:107: error: `__bswap_32' was not declared in this scope
> bytes.cpp:107: warning: unused variable '__bswap_32'
> gmake: *** [bytes.o] Error 1
>
> The developper told me:
>
> Currently the endian support does not include FreeBSD automatically, but you
> can compile for any system by defining the correct byte order and float word
> order. You also need to make sure the swap macros are compiled as well (they
> are in the Windows setion so far). I will add FreeBSD support in the next
> release, but it shouldn't be to hard to compile v1.4 on your own.
> Btw, uncomment _DEBUG in log.h to compile in release mode (I forgot to do
> that).
>
> I have no idea how to do the changes.
>
> Here is the source code:
>
> http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/r
> /rt/rtmpdump/rtmpdump-v1.4.tar.gz
>
> Regards,
>
> Josep Pujadas
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>



-- 
wbr,
pluknet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtmpdump_fbsd.patch
Type: application/octet-stream
Size: 726 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/b42e657f/rtmpdump_fbsd.obj
From stef-list at memberwebs.com  Wed Mar 18 10:43:51 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Wed Mar 18 10:43:57 2009
Subject: FreeBSD 7.2 Release process starting...
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>	<20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
Message-ID: <20090318172222.B4B08EFB6DA@mx.npubs.com>

Robert Watson wrote:
> One of the most important things for us to keep an eye on in this
> release is that the boot loader now works on a number of pieces of
> hardware on which it reressed for 6.4/7.1.  If it proves successful,
> we'll likely also do errata notes and roll new ISOs for 6.4.

I have a machine that I updated to 7-STABLE the other day. The boot
loader didn't work until I copied /boot files from an old FreeBSD. I'd
like to participate in getting this fixed. Is there a place that work is
being done on this? Bug reports, info needed, person to contact etc.?

Cheers,

Stef


From jhb at freebsd.org  Wed Mar 18 11:07:47 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Mar 18 11:08:06 2009
Subject: 7.1 panic "vm_page_startup: inconsistent page counts"
In-Reply-To: <20090316021412.GI5857@pjdesk.au.alcatel-lucent.com>
References: <20090312043646.GB8352@pjdesk.au.alcatel-lucent.com>
	<200903120846.50630.jhb@freebsd.org>
	<20090316021412.GI5857@pjdesk.au.alcatel-lucent.com>
Message-ID: <200903181156.58853.jhb@freebsd.org>

On Sunday 15 March 2009 10:14:12 pm Peter Jeremy wrote:
> On 2009-Mar-12 08:46:50 -0400, John Baldwin <jhb@freebsd.org> wrote:
> >On Thursday 12 March 2009 12:36:46 am Peter Jeremy wrote:
> >> I'm trying to upgrade an 11 month old FreeBSD 7 image in a VMware
> >> 4.5.2 guest to an up-to-date -stable and it panics as above.  I've
> >> added a printf to report the two counts and there's a difference of
> >> one page.  I don't have any problems with the old 7-stable image or
> >> up-to-date 6-stable or -current using the same VMware version.
> >> 
> >> A screendump for a verbose boot can be found at
> >> http://imagebin.ca/img/wahNNw.gif
> >> 
> >> Can I safely delete the assert?
> >
> >I don't think so, I would report it to Alan.  The one earlier report of 
this 
> >didn't include the detail that it was only off by one page.
> 
> This is a bit moot now since you've disabled the test but rolling back
> to a kernel from 26th Feb (before the superpages MFC) doesn't have the
> page count discrepancy.

Ok.  I think the discrepancy is due to the memory being reserved for the 
reservation table not being accounted for in 'npages'.  I'm just going to 
remove the assertion in 7 to match what is in 8.

-- 
John Baldwin
From jhb at freebsd.org  Wed Mar 18 11:07:53 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Mar 18 11:08:08 2009
Subject: bge0: EEPROM read timed
In-Reply-To: <a31046fc0903160508v7bfdf087r777b5b79390538fa@mail.gmail.com>
References: <a31046fc0903160336y58fd5e85le898dddd2c1d8aae@mail.gmail.com>
	<a31046fc0903160508v7bfdf087r777b5b79390538fa@mail.gmail.com>
Message-ID: <200903181201.17975.jhb@freebsd.org>

On Monday 16 March 2009 8:08:26 am pluknet wrote:
> 2009/3/16 pluknet <pluknet@gmail.com>:
> > Hi.
> >
> > I got this on today's RELENG_6 with Broadcom BCM5722 A0, ASIC rev. 0xa200.
> >
> > From dmesg (bge related):
> >
> > bge0: <Broadcom BCM5722 A0, ASIC rev. 0xa200> mem
> > 0xe8400000-0xe840ffff irq 16 at device 0.0 on pci2
> > bge0: firmware handshake timed out, found 0x4b657654
> > bge0: firmware handshake timed out, found 0x4b657654
> > bge0: EEPROM read timed out
> > bge0: failed to read EEPROM
> > device_attach: bge0 attach returned 6
> > bge1: <Broadcom BCM5703 B0, ASIC rev. 0x1100> mem
> > 0xe8600000-0xe860ffff irq 21 at device 1.0 on pci3
> > miibus0: <MII bus> on bge1
> > brgphy0: <BCM5703 10/100/1000baseTX PHY> on miibus0
> > brgphy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> > 1000baseT-FDX, auto
> > bge1: Ethernet address: 00:21:5e:4d:05:c8
> >
> >
> > any hints?
> >
> > P.S. I see EEPROM timeout fixes were already merged to RELENG_6 (I
> > have post-fix version certainly).
> > May that issue be somehow related?
> >
> 
> I guess it's a regression. Below are my speculations.
> 
> I tried to build on 6.2-R the bge(4) sources checked from later RELENG_6
> just after BCM5722 support (from if_bgereg.h 1.36.2.11/ if_bge.c1.91.2.26)
> in order to backport BCM5722 support into 6.2-R. After some tweaks it
> was built, so..

Can you further narrow down where the regression occurs?

-- 
John Baldwin
From jhb at freebsd.org  Wed Mar 18 11:07:59 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Mar 18 11:08:09 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
Message-ID: <200903181202.40634.jhb@freebsd.org>

On Monday 16 March 2009 1:59:25 pm Dan Allen wrote:
> I saw that someone else had this happen last week...  It is not a  
> hardware failure.
> 
> While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a  
> core dump with the message
> 
> 	vm_page_insert: page already inserted
> 
> I build this port every week on a Toshiba laptop (1.8GHz Core 2 Duo, 1  
> GB RAM, 160 GB HD, plenty of free space, RELENG_7).  I have never seen  
> this until today.  Just before building this port I completely built  
> the kernel and world and installed them, so I am as up-to-date as you  
> could be.
> 
> I suspect recent changes to vm code... perhaps in /usr/src/sys/vm/ 
> vm_meter.c or vm_page.c ?
> 
> The compressed core dump is 41 MB.

When I have seen this panic on machines in the past it was caused by bad RAM 
or another hardware problem.

-- 
John Baldwin
From rnoland at FreeBSD.org  Wed Mar 18 11:10:48 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Mar 18 11:10:55 2009
Subject: drm change breaks old ATI?
In-Reply-To: <49C057E9.6010402@protected-networks.net>
References: <49C057E9.6010402@protected-networks.net>
Message-ID: <1237399830.1738.11.camel@balrog.2hip.net>

On Tue, 2009-03-17 at 22:09 -0400, Michael Butler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Seems that the new drm schema requires an interrupt to attach.
> 
> "dmesg" returns:
> 
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci0: <ACPI PCI bus> on pcib0
> agp0: <Intel 82443BX (440 BX) host to PCI bridge> on hostb0
> pcib1: <PCI-PCI bridge> at device 1.0 on pci0
> pci1: <PCI bus> on pcib1
> vgapci0: <VGA-compatible display> port 0x9000-0x90ff mem
> 	0xd1000000-0xd1ffffff,0xd0100000-0xd0100fff at device 0.0
> 	on pci1
> drm0: <3D Rage Pro AGP 1X/2X> on vgapci0
> device_attach: drm0 attach returned 2
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>  .. which corresponds to ENOENT and "lspci -vvv" gives:
> 
> 
> 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP
> 		1X/2X (rev 5c) (prog-if 00 [VGA controller])
>         Subsystem: ATI Technologies Inc Rage Pro Turbo AGP 2X
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> 		ParErr- Stepping+ SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> 		<TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 66 (2000ns min), Cache Line Size: 32 bytes
> 
> ** ---> Interrupt: pin ? routed to IRQ 255
> 
>         Region 0: Memory at d1000000 (32-bit, non-prefetchable)
>         Region 1: I/O ports at 9000
>         Region 2: Memory at d0100000 (32-bit, non-prefetchable)
>         Capabilities: [50] AGP version 1.0
>                 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
> 			HTrans- 64bit- FW- AGP3- Rate=x1,x2
>                 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW-
> 			Rate=<none>
> 
> Didn't this used to work?

Not that I'm aware of... I looked back to the code before I enabled msi
and that part didn't change... so if it ever worked, it was a long time
ago.

robert.

> 	Michael
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (FreeBSD)
> 
> iEYEARECAAYFAknAV+gACgkQQv9rrgRC1JIiAwCdEmwDBPcTjd97vV3q3kz5kO8R
> qA0An3RjPS/ra7CVRd6KfeuOuQoARaVm
> =h2qo
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/15b0ee27/attachment.pgp
From imp at bsdimp.com  Wed Mar 18 11:42:16 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Wed Mar 18 11:42:24 2009
Subject: KLD cbb.ko: depends on exca - not available
In-Reply-To: <a31046fc0903171426w16c1ae01l1fe51d579a08dd9c@mail.gmail.com>
References: <a31046fc0903171426w16c1ae01l1fe51d579a08dd9c@mail.gmail.com>
Message-ID: <20090318.123813.232926411.imp@bsdimp.com>

In message: <a31046fc0903171426w16c1ae01l1fe51d579a08dd9c@mail.gmail.com>
            pluknet <pluknet@gmail.com> writes:
: Hi.
: 
: FreeBSD 7-STABLE.
: 
: Subj message appears when I try to kldload cbb.ko and kernel
: cannot find exca due to its non-existence.
: The pccbb(4) manpage doesn't mention exca.
: 
: make install exca helps with kldload, now:
: cbb0: <TI4510 PCI-CardBus Bridge> at device 1.0 on pci1
: cbb0: [ITHREAD]
: 
: Would it be correct to add a new entry to the pccbb synopsis?

Yes.  exca has been required since at least 5.4, and likely as far
back as 5.0.

Warner

: --- src/share/man/man4/pccbb.4.orig        2009-03-18 00:22:09.000000000 +0300
: +++ src/share/man/man4/pccbb.4     2009-03-18 00:22:42.000000000 +0300
: @@ -34,6 +34,7 @@
:  .Cd device cbb
:  .Cd device pccard
:  .Cd device cardbus
: +.Cd device exca
:  .Sh DESCRIPTION
:  The
:  .Nm
: 
: 
: -- 
: wbr,
: pluknet
: _______________________________________________
: freebsd-stable@freebsd.org mailing list
: http://lists.freebsd.org/mailman/listinfo/freebsd-stable
: To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
From dougb at FreeBSD.org  Wed Mar 18 11:59:18 2009
From: dougb at FreeBSD.org (Doug Barton)
Date: Wed Mar 18 11:59:25 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <200903161055.n2GAtHkt077732@lurza.secnetix.de>
References: <200903161055.n2GAtHkt077732@lurza.secnetix.de>
Message-ID: <49C1447C.6060002@FreeBSD.org>

Oliver Fromme wrote:
> Doug Barton wrote:
>  > The attached patch adds a -F option to automatically install files
>  > when only the FreeBSD $Ids differ. I've tested this and it seems to do
>  > what the people concerned about this issue are asking for.
> 
> That seems to be a useful feature. 

Thanks.

> You need to quote the dollar signs, though.

Well, not only would that defeat the purpose they are there for, it
wouldn't work. Perhaps you missed the bit where I said that I actually
tested this? :)

> However, maybe the best solution is to add a new keyword
> for mergemaster.rc, so the user can exactly specify which
> kind of changes should be always installed.

That's an interesting idea, but I think that the number of times that
there is a nonfunctional change other than to the VCS Id are very
small, and I don't want to complicate this more than it needs to be.

Please remember that we're dealing with two very different groups of
users. One is the "power user" who updates frequently and can
certainly hack this sort of thing themselves if they really want it.
The other is the "average" user who only updates once or twice a year,
usually to a new release, occasionally to a new patch level, etc. The
vast majority of our users are in the latter category, and they need a
simple tool with a minimum of foot-shooting capacity.


Doug

-- 

    This .signature sanitized for your protection

From cswiger at mac.com  Wed Mar 18 12:04:12 2009
From: cswiger at mac.com (Chuck Swiger)
Date: Wed Mar 18 12:04:18 2009
Subject: Can't compile rtmpdump source
In-Reply-To: <a31046fc0903181038x7dd03ac7j8a1ed4873e17edfa@mail.gmail.com>
References: <20090317213903.M57690@bellera.cat>
	<20090318163944.M277@bellera.cat>
	<a31046fc0903181038x7dd03ac7j8a1ed4873e17edfa@mail.gmail.com>
Message-ID: <829202F5-E196-4911-90CD-5BB56DD48D31@mac.com>

On Mar 18, 2009, at 10:38 AM, pluknet wrote:
> Hi, Josep. Try an attached patch.

FreeBSD runs on both big and little-endian architectures; please  
include <sys/endian.h> instead, which will pull in machine-specific  
headers and #define _BYTE_ORDER to _LITTLE_ENDIAN or _BIG_ENDIAN as  
appropriate.

Regards,
-- 
-Chuck

From pluknet at gmail.com  Wed Mar 18 12:41:16 2009
From: pluknet at gmail.com (pluknet)
Date: Wed Mar 18 12:41:23 2009
Subject: bge0: EEPROM read timed
In-Reply-To: <200903181201.17975.jhb@freebsd.org>
References: <a31046fc0903160336y58fd5e85le898dddd2c1d8aae@mail.gmail.com>
	<a31046fc0903160508v7bfdf087r777b5b79390538fa@mail.gmail.com>
	<200903181201.17975.jhb@freebsd.org>
Message-ID: <a31046fc0903181241q46852f2mc4f3b58bdb3c215c@mail.gmail.com>

2009/3/18 John Baldwin <jhb@freebsd.org>:
> On Monday 16 March 2009 8:08:26 am pluknet wrote:
>> 2009/3/16 pluknet <pluknet@gmail.com>:
>> > Hi.
>> >
>> > I got this on today's RELENG_6 with Broadcom BCM5722 A0, ASIC rev. 0xa200.
>> >
>> > From dmesg (bge related):
>> >
>> > bge0: <Broadcom BCM5722 A0, ASIC rev. 0xa200> mem
>> > 0xe8400000-0xe840ffff irq 16 at device 0.0 on pci2
>> > bge0: firmware handshake timed out, found 0x4b657654
>> > bge0: firmware handshake timed out, found 0x4b657654
>> > bge0: EEPROM read timed out
>> > bge0: failed to read EEPROM
>> > device_attach: bge0 attach returned 6
>> > bge1: <Broadcom BCM5703 B0, ASIC rev. 0x1100> mem
>> > 0xe8600000-0xe860ffff irq 21 at device 1.0 on pci3
>> > miibus0: <MII bus> on bge1
>> > brgphy0: <BCM5703 10/100/1000baseTX PHY> on miibus0
>> > brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
>> > 1000baseT-FDX, auto
>> > bge1: Ethernet address: 00:21:5e:4d:05:c8
>> >
>> >
>> > any hints?
>> >
>> > P.S. I see EEPROM timeout fixes were already merged to RELENG_6 (I
>> > have post-fix version certainly).
>> > May that issue be somehow related?
>> >
>>
>> I guess it's a regression. Below are my speculations.
>>
>> I tried to build on 6.2-R the bge(4) sources checked from later RELENG_6
>> just after BCM5722 support (from if_bgereg.h 1.36.2.11/ if_bge.c1.91.2.26)
>> in order to backport BCM5722 support into 6.2-R. After some tweaks it
>> was built, so..
>
> Can you further narrow down where the regression occurs?

I'm sorry, John. Today we moved to native 7.1-R installed from CD.
I can only confirm now that there is no any visible problems now.

bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev.
0xa200> mem 0xe8400000-0xe840ffff irq 16 at device 0.0 on pci2
miibus0: <MII bus> on bge0
brgphy0: <BCM5722 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bge0: Ethernet address: 00:21:5e:4d:05:c7
bge0: [ITHREAD]
bge1: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev.
0x1100> mem 0xe8600000-0xe860ffff irq 21 at device 1.0 on pci3
miibus1: <MII bus> on bge1
brgphy1: <BCM5703 10/100/1000baseTX PHY> PHY 1 on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bge1: Ethernet address: 00:21:5e:4d:05:c8
bge1: [ITHREAD]
bge0: link state changed to UP
bge1: link state changed to UP

[root@ ~]# sysctl -a | grep bge
hw.bge.allow_asf: 0
dev.bge.0.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC
rev. 0xa200
dev.bge.0.%driver: bge
dev.bge.0.%location: slot=0 function=0 handle=\_SB_.PCI0.EXP5.PXS5
dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x165a subvendor=0x1014
subdevice=0x0378 class=0x020000
dev.bge.0.%parent: pci2
dev.bge.1.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC
rev. 0x1100
dev.bge.1.%driver: bge
dev.bge.1.%location: slot=1 function=0
dev.bge.1.%pnpinfo: vendor=0x14e4 device=0x16c7 subvendor=0x1014
subdevice=0x026f class=0x020000
dev.bge.1.%parent: pci3
dev.bge.1.stats.FramesDroppedDueToFilters: 0
dev.bge.1.stats.DmaWriteQueueFull: 0
dev.bge.1.stats.DmaWriteHighPriQueueFull: 0
dev.bge.1.stats.NoMoreRxBDs: 0
dev.bge.1.stats.InputDiscards: 0
dev.bge.1.stats.InputErrors: 0
dev.bge.1.stats.RecvThresholdHit: 15574
dev.bge.1.stats.DmaReadQueueFull: 0
dev.bge.1.stats.DmaReadHighPriQueueFull: 0
dev.bge.1.stats.SendDataCompQueueFull: 0
dev.bge.1.stats.RingSetSendProdIndex: 0
dev.bge.1.stats.RingStatusUpdate: 15604
dev.bge.1.stats.Interrupts: 15604
dev.bge.1.stats.AvoidedInterrupts: 0
dev.bge.1.stats.SendThresholdHit: 0
dev.bge.1.stats.rx.Octets: 3478478
dev.bge.1.stats.rx.Fragments: 0
dev.bge.1.stats.rx.UcastPkts: 0
dev.bge.1.stats.rx.MulticastPkts: 0
dev.bge.1.stats.rx.FCSErrors: 0
dev.bge.1.stats.rx.AlignmentErrors: 0
dev.bge.1.stats.rx.xonPauseFramesReceived: 0
dev.bge.1.stats.rx.xoffPauseFramesReceived: 0
dev.bge.1.stats.rx.ControlFramesReceived: 0
dev.bge.1.stats.rx.xoffStateEntered: 0
dev.bge.1.stats.rx.FramesTooLong: 0
dev.bge.1.stats.rx.Jabbers: 0
dev.bge.1.stats.rx.UndersizePkts: 0
dev.bge.1.stats.rx.inRangeLengthError: 0
dev.bge.1.stats.rx.outRangeLengthError: 0
dev.bge.1.stats.tx.Octets: 0
dev.bge.1.stats.tx.Collisions: 0
dev.bge.1.stats.tx.XonSent: 0
dev.bge.1.stats.tx.XoffSent: 0
dev.bge.1.stats.tx.flowControlDone: 0
dev.bge.1.stats.tx.InternalMacTransmitErrors: 0
dev.bge.1.stats.tx.SingleCollisionFrames: 0
dev.bge.1.stats.tx.MultipleCollisionFrames: 0
dev.bge.1.stats.tx.DeferredTransmissions: 0
dev.bge.1.stats.tx.ExcessiveCollisions: 0
dev.bge.1.stats.tx.LateCollisions: 0
dev.bge.1.stats.tx.UcastPkts: 0
dev.bge.1.stats.tx.MulticastPkts: 0
dev.bge.1.stats.tx.BroadcastPkts: 0
dev.bge.1.stats.tx.CarrierSenseErrors: 0
dev.bge.1.stats.tx.Discards: 0
dev.bge.1.stats.tx.Errors: 0
dev.miibus.0.%parent: bge0
dev.miibus.1.%parent: bge1


FreeBSD 7.1-RELEASE

-- 
wbr,
pluknet
From danallen46 at airwired.net  Wed Mar 18 12:45:03 2009
From: danallen46 at airwired.net (Dan Allen)
Date: Wed Mar 18 12:45:13 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <200903181202.40634.jhb@freebsd.org>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
	<200903181202.40634.jhb@freebsd.org>
Message-ID: <875B312A-89DA-4E32-8505-FAF32670C871@airwired.net>


On 18 Mar 2009, at 10:02 AM, John Baldwin wrote:

> On Monday 16 March 2009 1:59:25 pm Dan Allen wrote:
>> I saw that someone else had this happen last week...  It is not a
>> hardware failure.
>>
>> While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a
>> core dump with the message
>>
>> 	vm_page_insert: page already inserted
>>
>> I build this port every week on a Toshiba laptop (1.8GHz Core 2  
>> Duo, 1
>> GB RAM, 160 GB HD, plenty of free space, RELENG_7).  I have never  
>> seen
>> this until today.  Just before building this port I completely built
>> the kernel and world and installed them, so I am as up-to-date as you
>> could be.
>>
>> I suspect recent changes to vm code... perhaps in /usr/src/sys/vm/
>> vm_meter.c or vm_page.c ?
>>
>> The compressed core dump is 41 MB.
>
> When I have seen this panic on machines in the past it was caused by  
> bad RAM
> or another hardware problem.

Well, I have not been able to reproduce it.  I ran builds on two  
different
machines, and everything now works fine.  I will keep my eye open for  
another
occurrence, but for now we are at the end of the line on this.  At  
least I am...

Thanks to everyone for their help and ideas.

Dan


From tinderbox at freebsd.org  Wed Mar 18 13:02:04 2009
From: tinderbox at freebsd.org (FreeBSD Tinderbox)
Date: Wed Mar 18 13:02:17 2009
Subject: [releng_7 tinderbox] failure on i386/i386
Message-ID: <20090318200158.9314F1B5060@freebsd-stable.sentex.ca>

TB --- 2009-03-18 18:47:47 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2009-03-18 18:47:47 - starting RELENG_7 tinderbox run for i386/i386
TB --- 2009-03-18 18:47:47 - cleaning the object tree
TB --- 2009-03-18 18:48:22 - cvsupping the source tree
TB --- 2009-03-18 18:48:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile
TB --- 2009-03-18 18:48:32 - building world
TB --- 2009-03-18 18:48:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-03-18 18:48:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-03-18 18:48:32 - TARGET=i386
TB --- 2009-03-18 18:48:32 - TARGET_ARCH=i386
TB --- 2009-03-18 18:48:32 - TZ=UTC
TB --- 2009-03-18 18:48:32 - __MAKE_CONF=/dev/null
TB --- 2009-03-18 18:48:32 - cd /src
TB --- 2009-03-18 18:48:32 - /usr/bin/make -B buildworld
>>> World build started on Wed Mar 18 18:48:34 UTC 2009
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Wed Mar 18 19:52:08 UTC 2009
TB --- 2009-03-18 19:52:08 - generating LINT kernel config
TB --- 2009-03-18 19:52:08 - cd /src/sys/i386/conf
TB --- 2009-03-18 19:52:08 - /usr/bin/make -B LINT
TB --- 2009-03-18 19:52:08 - building LINT kernel
TB --- 2009-03-18 19:52:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2009-03-18 19:52:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2009-03-18 19:52:08 - TARGET=i386
TB --- 2009-03-18 19:52:08 - TARGET_ARCH=i386
TB --- 2009-03-18 19:52:08 - TZ=UTC
TB --- 2009-03-18 19:52:08 - __MAKE_CONF=/dev/null
TB --- 2009-03-18 19:52:08 - cd /src
TB --- 2009-03-18 19:52:08 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Mar 18 19:52:08 UTC 2009
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/fs/smbfs/smbfs_vnops.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/fs/udf/osta.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/fs/udf/udf_iconv.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/fs/udf/udf_vfsops.c
cc1: warnings being treated as errors
/src/sys/fs/udf/udf_vfsops.c: In function 'udf_vget':
/src/sys/fs/udf/udf_vfsops.c:703: warning: implicit declaration of function 'VN_LOCK_ASHARE'
/src/sys/fs/udf/udf_vfsops.c:703: warning: nested extern declaration of 'VN_LOCK_ASHARE'
*** Error code 1

Stop in /obj/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2009-03-18 20:01:57 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2009-03-18 20:01:57 - ERROR: failed to build lint kernel
TB --- 2009-03-18 20:01:57 - 3716.00 user 388.73 system 4450.12 real


http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full
From per.otterstrom at gmail.com  Wed Mar 18 14:43:20 2009
From: per.otterstrom at gmail.com (=?ISO-8859-1?Q?Per_Otterstr=F6m?=)
Date: Wed Mar 18 14:43:42 2009
Subject: Gigabit cardbus re nic fails to attach
Message-ID: <ac3c3950903181412t40488e7fue27702dee5758024@mail.gmail.com>

Hi all.

I'm running 7.1-RELEASE.

When I plug in my D-Link DGE-660TD gigabit cardbus adapter I get:

re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet> port
0x4000-0x40ff mem 0xd0201000-0xd02011ff irq 11 at device 0.0 on cardbus1
re0: Chip rev. 0x10000000
re0: MAC rev. 0x00000000
re0: PHY write failed
re0: PHY write failed
re0: PHY read failed
re0: MII without any phy!
device_attach: re0 attach returned 6

Relevant part from pciconf -lv:

re0@pci0:6:0:0: class=0x020000 card=0x43011186 chip=0x816910ec rev=0x10
hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller'
    class      = network
    subclass   = ethernet

I've seen several patches for similar problems provided by Pyun YongHyeon,
but I don't think any one of them are applicable in my case.

Any advice appreciated.

regards, Pelle
From squirrel at mail.isot.com  Wed Mar 18 15:22:18 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Wed Mar 18 15:22:26 2009
Subject: Crash!!!
Message-ID: <6a6f24080afb0b1cc84cc145b674c58c@mail.isot.com>

My webserver was working just fine on FreeBSD 6.2 Apache 2.2.11, MySQL 5.0.27.  All of sudden MySQL quit and won't start.  At the same time when logged in using SSH, it's looking for .bash_login and .bash_logout which it never did before, and will not chroot to user's home.

Trying to manual start mysql causes:

090318 17:09:52  mysqld started
090318 17:09:52  InnoDB: Started; log sequence number 2 2195718579
090318 17:09:52 [ERROR] bdb:  /home/mysql: Permission denied
090318 17:09:52 [ERROR] bdb:  /home/mysql/log.0000000001: Permission denied
090318 17:09:52 [ERROR] bdb:  PANIC: Permission denied
090318 17:09:52 [ERROR] bdb:  PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
090318 17:09:52 [ERROR] bdb:  fatal region error detected; run recovery
090318 17:09:52 [ERROR] bdb:  /home/mysql: Permission denied
090318 17:09:52 [ERROR] /usr/local/libexec/mysqld: Can't create/write to file '/home/mysql/webserver.isot.com.pid' (Errcode: 13)
090318 17:09:52 [ERROR] Can't start server: can't create PID file: Permission denied
090318 17:09:52  mysqld ended

I tried db_recover, but it's not found.  HELP!!!
From squirrel at mail.isot.com  Wed Mar 18 15:44:31 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Wed Mar 18 15:44:40 2009
Subject: Crash!!!
Message-ID: <3e7f8d174bb6d9b691683a7e9a93aed7@mail.isot.com>

Another thing, why is the error log shows bdb?  Isn't that Berkerly DB?  I didn't think I was using it.  I went ahead and removed it, but rebooted the server.  Only thing I can think is that I've installed virtualmin few days ago before this problem started.

These are my file premissions:

/home/
drwxrwxrwx  33 mysql           mysql            1024 Mar 18 17:18 mysql
..

/home/mysql/
[root@webserver /home/mysql]# ls -la
total 143848
drwxrwxrwx  33 mysql  mysql       1024 Mar 18 17:18 .
drw-r--r--      71 felix  felix       1536 Mar 18 16:44 ..
drwxrw-rw-   2 mysql  mysql       2560 Nov 21  2007 centexhomes
drwxrw-rw-   2 mysql  mysql       2560 Oct 31  2007 centexrealtors
drwxrw-rw-   2 mysql  mysql      18432 Mar  9 15:08 devildates
drwxrw-rw-   2 mysql  mysql      14848 Feb 10  2008 dolphin
drwxrw-rw-   2 mysql  mysql       2048 Mar  3  2008 drugal2
drwxrw-rw-   2 mysql  mysql      13824 Feb 28  2008 drup
...
drwxrw-rw-   2 mysql  mysql       1024 Oct 31  2007 treasure
-rw-rw----   1 mysql  mysql       3785 Mar 18 17:18 webserver.isot.com.err
-rwxrw-rw-   1 mysql  mysql      83676 Mar 18 16:30 webserver.isot.com.err.bak
-rwxrw-rw-   1 mysql  mysql          5 Mar 17 11:27 webserver.isot.com.pid.bak
drwxrw-rw-   2 mysql  mysql       7168 Jun 11  2008 yourshows
drwxrw-rw-   2 mysql  mysql       2048 Mar 28  2008 yourshows_g2



-----Original message-----
From: Squirrel squirrel@mail.isot.com
Date: Wed, 18 Mar 2009 23:22:50 -0600
To: freebsd-stable freebsd-stable@freebsd.org
Subject: Crash!!!

> My webserver was working just fine on FreeBSD 6.2 Apache 2.2.11, MySQL 5.0.27.  All of sudden MySQL quit and won't start.  At the same time when logged in using SSH, it's looking for .bash_login and .bash_logout which it never did before, and will not chroot to user's home.
> 
> Trying to manual start mysql causes:
> 
> 090318 17:09:52  mysqld started
> 090318 17:09:52  InnoDB: Started; log sequence number 2 2195718579
> 090318 17:09:52 [ERROR] bdb:  /home/mysql: Permission denied
> 090318 17:09:52 [ERROR] bdb:  /home/mysql/log.0000000001: Permission denied
> 090318 17:09:52 [ERROR] bdb:  PANIC: Permission denied
> 090318 17:09:52 [ERROR] bdb:  PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
> 090318 17:09:52 [ERROR] bdb:  fatal region error detected; run recovery
> 090318 17:09:52 [ERROR] bdb:  /home/mysql: Permission denied
> 090318 17:09:52 [ERROR] /usr/local/libexec/mysqld: Can't create/write to file '/home/mysql/webserver.isot.com.pid' (Errcode: 13)
> 090318 17:09:52 [ERROR] Can't start server: can't create PID file: Permission denied
> 090318 17:09:52  mysqld ended
> 
> I tried db_recover, but it's not found.  HELP!!!
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
From josep at bellera.cat  Wed Mar 18 16:07:43 2009
From: josep at bellera.cat (Josep Pujadas i Jubany)
Date: Wed Mar 18 16:07:49 2009
Subject: Can't compile rtmpdump source
In-Reply-To: <a31046fc0903181038x7dd03ac7j8a1ed4873e17edfa@mail.gmail.com>
References: <20090317213903.M57690@bellera.cat>
	<20090318163944.M277@bellera.cat>
	<a31046fc0903181038x7dd03ac7j8a1ed4873e17edfa@mail.gmail.com>
Message-ID: <20090318230322.M3845@bellera.cat>

On Wed, 18 Mar 2009 20:38:32 +0300, pluknet wrote
> Hi, Josep. Try an attached patch.

It works!

Many thanks, pluknet !!!!

A member of Spanish FreeBSD list sent me another patch. It works also. I 
attached it to this e-mail.

Regards,

Josep Pujadas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtmpdump.patch
Type: application/octet-stream
Size: 1188 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/a3335034/rtmpdump.obj
From gcr+freebsd-stable at tharned.org  Wed Mar 18 16:18:45 2009
From: gcr+freebsd-stable at tharned.org (Greg Rivers)
Date: Wed Mar 18 16:18:58 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1237395643.1738.3.camel@balrog.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
Message-ID: <alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>

On Wed, 18 Mar 2009, Robert Noland wrote:

> On Tue, 2009-03-17 at 18:24 -0500, Greg Rivers wrote:
>> On Tue, 17 Mar 2009, Robert Noland wrote:
>>
>>> On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote:
>>>> On Sat, 10 Jan 2009, Robert Noland wrote:
>>>>
>>>>> I just merged drm (Direct Rendering) from HEAD.
>>>>>
>>>>>        - Support for latest Intel chips
>>>>>        - Support and fixes for many AMD/ATI chips r500 and below
>>>>>        - Support AMD/ATI IGP based chips (rs690/rs485)
>>>>>        - Lots of code cleanups
>>>>>        - Lots of other fixes and changes since the existing drm
>>>>>          is 2+ years old
>>>>>
>>>>> If you are experiencing a "garbled" screen with certain pci/pci-e based
>>>>> radeons, I have another patch in HEAD that isn't included yet.
>>>>>
>>>>
>>>> I have a workstation with a [Radeon X600 (PCIE)] card.  The X display has
>>>> been garbled since these DRM updates went in in January, and remains
>>>> garbled with 7.1-STABLE as of yesterday.  As a work-around, I'm running
>>>> the up-to-date 7.1-STABLE system (both world and ports) with a
>>>> 7.1-RELEASE-p2 kernel.  The display is fine with the old kernel and X
>>>> works great; I even see dramatically improved performance with the new
>>>> Xorg and EXA acceleration.  Your work is much appreciated.
>>>>
>>>> But the garbled display with the recent DRM still plagues me.
>>>>
>>>> [snip]
>>>
>>> Could you try the attached patch.
>>>
>>
>> Unfortunately, there is no noticeable difference with this patch.
>>
>>
>>> Also, I'm guessing that this is a PCI based card, right?  Also, it isn't
>>> an integrated model?
>>>
>>
>> Yes, this is a PCIEx16 card in a HP Compaq dc7600 desktop PC, not a
>> motherboard integrated adapter.
>>
>> Thanks for your help.  I'm willing to spend some time debugging this;
>> please let me know if there's more information I can provide or other
>> tests or patches I can try.
>
> Ok, try this patch... I asked the folks from AMD and they agree that
> this shouldn't be needed on an RV370, but we will give it a try... This
> is what fixed the garbled display on the IGP chips.
>

The display is still garbled with this patch too.

I'm curious about why the drm driver calls this card a RV370, while pciconf
and the X server call it a RV380:
 	pciconf: "RV380 RADEON X600 Series 265MB"
 	X server: "ATI Technologies Inc RV380 [Radeon X600 (PCIE)]"
 	drm driver: "ATI Radeon RV370 X600 Pro"

Could it be that the drm driver has the wrong chip set or configuration for
this PCI ID?

-- 
Greg Rivers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drm-rv370-test.patch
Type: text/x-patch
Size: 470 bytes
Desc: 
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/1642b572/drm-rv370-test.bin
From kama at pvp.se  Wed Mar 18 16:21:32 2009
From: kama at pvp.se (kama)
Date: Wed Mar 18 16:21:39 2009
Subject: mergemaster annoyance or not?
In-Reply-To: <49C1447C.6060002@FreeBSD.org>
References: <200903161055.n2GAtHkt077732@lurza.secnetix.de>
	<49C1447C.6060002@FreeBSD.org>
Message-ID: <20090319001829.U55869@ns1.as.pvp.se>



On Wed, 18 Mar 2009, Doug Barton wrote:

> Oliver Fromme wrote:
> > Doug Barton wrote:
> >  > The attached patch adds a -F option to automatically install files
> >  > when only the FreeBSD $Ids differ. I've tested this and it seems to do
> >  > what the people concerned about this issue are asking for.
> >
> > That seems to be a useful feature.
>
> Thanks.
>
> > You need to quote the dollar signs, though.
>
> Well, not only would that defeat the purpose they are there for, it
> wouldn't work. Perhaps you missed the bit where I said that I actually
> tested this? :)
>
> > However, maybe the best solution is to add a new keyword
> > for mergemaster.rc, so the user can exactly specify which
> > kind of changes should be always installed.
>
> That's an interesting idea, but I think that the number of times that
> there is a nonfunctional change other than to the VCS Id are very
> small, and I don't want to complicate this more than it needs to be.
>
> Please remember that we're dealing with two very different groups of
> users. One is the "power user" who updates frequently and can
> certainly hack this sort of thing themselves if they really want it.
> The other is the "average" user who only updates once or twice a year,
> usually to a new release, occasionally to a new patch level, etc. The
> vast majority of our users are in the latter category, and they need a
> simple tool with a minimum of foot-shooting capacity.

One thing that really bother me is the fact that it patches passwd.

I would rather only have mergemaster to use the pw command to add and
delete users and groups instead.

Its especially annoying when it updated passwd without my content on a
remote update.

/Bjorn
From rabe at uugrn.org  Wed Mar 18 16:47:58 2009
From: rabe at uugrn.org (Raphael Becker)
Date: Wed Mar 18 16:48:22 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
Message-ID: <20090318233456.GA95898@ma.sigsys.de>

On Mon, Mar 16, 2009 at 11:59:25AM -0600, Dan Allen wrote:
> I saw that someone else had this happen last week...  It is not a  
> hardware failure.
> 
> While building the latest GCC 4.4 from /usr/ports/lang/gcc44 I got a  
> core dump with the message
> 
> 	vm_page_insert: page already inserted

I had the same thing on 7.1-STABLE with sources @2009-03-14 (last
Saturday). The machine had no hardware failures running 6.x...6.4 in 
the last 3 years running about 20..25 Jails.

Therefore I don't think it is a hardware error.

The crash happened during someone recompiling most of his packages in
jail while running cvsup on /usr/ports in another jail. So there was 
pretty much I/O and CPU usage. After crash the geom_mirror was degraded 
on ad4 (ad6 working).

I guess 
  a) the vmcore was successfully written to the SWAP 
  b) geom_mirror is unstable under heavy load, maybe it's the 
     origin of the crash. swap resides on that geom_mirror, too. 

I'm not yet able to get some useful information out of the 230MB vmcore.0
Maybe I may provide useful information about the crash if someone can
tell me about how to get theese from vmcore.0.

info.0 says:
Dump header from device /dev/label/TOPSWAP
  Architecture: i386
  Architecture Version: 2
  Dump Length: 246185984B (234 MB)
  Blocksize: 512
  Dumptime: Sat Mar 14 22:43:46 2009
  Hostname: top.uugrn.org
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 7.1-STABLE #0: Sat Mar 14 20:06:04 CET 2009
    root@top.uugrn.org:/usr/obj/usr/src_RELENG_7/sys/TOP
  Panic String: vm_page_insert: page already inserted
  Dump Parity: 31664128
  Bounds: 0
  Dump Status: good


Regards
Raphael Becker

-- 
Raphael Becker          <rabe@uugrn.org>          http://rabe.uugrn.org/
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/fbf63adc/attachment.pgp
From rabe at uugrn.org  Wed Mar 18 16:59:27 2009
From: rabe at uugrn.org (Raphael Becker)
Date: Wed Mar 18 16:59:35 2009
Subject: GCC build causes panic: page already inserted
In-Reply-To: <20090318233456.GA95898@ma.sigsys.de>
References: <7381363A-9B55-4A3B-99BF-A05B2F879403@airwired.net>
	<20090318233456.GA95898@ma.sigsys.de>
Message-ID: <20090318235931.GB95898@ma.sigsys.de>

On Thu, Mar 19, 2009 at 12:34:56AM +0100, Raphael Becker wrote:
> info.0 says:
> Dump header from device /dev/label/TOPSWAP
>   Architecture: i386
>   Architecture Version: 2
>   Dump Length: 246185984B (234 MB)
>   Blocksize: 512
>   Dumptime: Sat Mar 14 22:43:46 2009
>   Hostname: top.uugrn.org
>   Magic: FreeBSD Kernel Dump
>   Version String: FreeBSD 7.1-STABLE #0: Sat Mar 14 20:06:04 CET 2009
>     root@top.uugrn.org:/usr/obj/usr/src_RELENG_7/sys/TOP
>   Panic String: vm_page_insert: page already inserted
>   Dump Parity: 31664128
>   Bounds: 0
>   Dump Status: good

Some more details ... maybe someone will get somethin interesing from
this:

[root@top /usr/obj/usr/src_RELENG_7/sys/TOP]# kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: vm_page_insert: page already inserted
cpuid = 1
Uptime: 1h41m26s
Physical memory: 2034 MB
Dumping 234 MB: 219 203 187

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x186a0
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0x186a0
stack pointer           = 0x28:0xe571da48
frame pointer           = 0x28:0xe571da68
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 4 (g_down)
trap number             = 12
panic: page fault
cpuid = 1
 171 155 139 123 107 91 75 59 43 27 11

Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from
/boot/kernel/geom_mirror.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_mirror.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from
/boot/kernel/ipfw.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ipfw.ko
Reading symbols from /boot/kernel/logo_saver.ko...Reading symbols from
/boot/kernel/logo_saver.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/logo_saver.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/boot/kernel/fdescfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/fdescfs.ko
#0  doadump () at pcpu.h:196
196             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb)
(kgdb) where
#0  doadump () at pcpu.h:196
#1  0xc07d3a87 in boot (howto=260) at /usr/src_RELENG_7/sys/kern/kern_shutdown.c:418
#2  0xc07d3d59 in panic (fmt=Variable "fmt" is not available.) at /usr/src_RELENG_7/sys/kern/kern_shutdown.c:574
#3  0xc0a1d4ca in vm_page_insert (m=0xc3735b20, object=0xc1461200, pindex=Unhandled dwarf expression opcode 0x93) at /usr/src_RELENG_7/sys/vm/vm_page.c:665
#4  0xc0a1da29 in vm_page_alloc (object=0xc1461200, pindex=5785959, req=546) at /usr/src_RELENG_7/sys/vm/vm_page.c:1171
#5  0xc083bd6b in allocbuf (bp=0xc51fe0c8, size=16384) at /usr/src_RELENG_7/sys/kern/vfs_bio.c:2895
#6  0xc083f62d in getblk (vp=0xc58969b4, blkno=46287648, size=16384, slpflag=0, slptimeo=0, flags=Variable "flags" is not available.) at /usr/src_RELENG_7/sys/kern/vfs_bio.c:2666
#7  0xc083ffe4 in breadn (vp=0xc58969b4, blkno=Unhandled dwarf expression opcode 0x93) at /usr/src_RELENG_7/sys/kern/vfs_bio.c:786
#8  0xc084011c in bread (vp=0xc58969b4, blkno=Unhandled dwarf expression opcode 0x93) at /usr/src_RELENG_7/sys/kern/vfs_bio.c:734
#9  0xc09edecb in ffs_vgetf (mp=0xc5852b40, ino=2897024, flags=2, vpp=0xe83338e8, ffs_flags=Variable "ffs_flags" is not available.) at /usr/src_RELENG_7/sys/ufs/ffs/ffs_vfsops.c:1477
#10 0xc09ee09e in ffs_vget (mp=0xc5852b40, ino=2897024, flags=2, vpp=0xe83338e8) at /usr/src_RELENG_7/sys/ufs/ffs/ffs_vfsops.c:1379 #11 0xc09fa44b in ufs_lookup (ap=0xe8333930) at /usr/src_RELENG_7/sys/ufs/ufs/ufs_lookup.c:600
#12 0xc0aeada2 in VOP_CACHEDLOOKUP_APV (vop=0xc0c5ff00, a=0xe8333930) at vnode_if.c:153
#13 0xc084178c in vfs_cache_lookup (ap=0xe83339b4) at vnode_if.h:83
#14 0xc0aeca76 in VOP_LOOKUP_APV (vop=0xc0c60420, a=0xe83339b4) at vnode_if.c:99
#15 0xc08481b1 in lookup (ndp=0xe8333b7c) at vnode_if.h:57
#16 0xc0848eff in namei (ndp=0xe8333b7c) at /usr/src_RELENG_7/sys/kern/vfs_lookup.c:215
#17 0xc08600c7 in vn_open_cred (ndp=0xe8333b7c, flagp=0xe8333c78, cmode=0, cred=0xc635cb00, fp=0xca134804) at /usr/src_RELENG_7/sys/kern/vfs_vnops.c:188
#18 0xc0860393 in vn_open (ndp=0xe8333b7c, flagp=0xe8333c78, cmode=0, fp=0xca134804) at /usr/src_RELENG_7/sys/kern/vfs_vnops.c:94
#19 0xc085dab7 in kern_open (td=0xc7326230, path=0x8265910 <Address 0x8265910 out of bounds>, pathseg=UIO_USERSPACE, flags=1, mode=0) at /usr/src_RELENG_7/sys/kern/vfs_syscalls.c:1042
#20 0xc085e020 in open (td=0xc7326230, uap=0xe8333cfc) at /usr/src_RELENG_7/sys/kern/vfs_syscalls.c:1009
#21 0xc0ad6ab5 in syscall (frame=0xe8333d38) at /usr/src_RELENG_7/sys/i386/i386/trap.c:1090
#22 0xc0abb830 in Xint0x80_syscall () at /usr/src_RELENG_7/sys/i386/i386/exception.s:255
#23 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)

HTH!

Raphael


PS: I'd need some assistance from here to get more that this out of the
vmcore.  


-- 
Raphael Becker          <rabe@uugrn.org>          http://rabe.uugrn.org/
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090318/734a0d42/attachment-0001.pgp
From squirrel at mail.isot.com  Wed Mar 18 17:17:02 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Wed Mar 18 17:17:09 2009
Subject: Crash!!!
Message-ID: <676b8088f93aa6155abc614674d85dba@mail.isot.com>

And if it's a file permission problem, why is it able to write *.err file on same directory?

I've set:

  innodb_force_recovery = 6

And now the PANIC (fatal error) is gone, but still got this permission denied:

090318 19:09:53  mysqld started
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
090318 19:09:54  InnoDB: Started; log sequence number 0 0
InnoDB: !!! innodb_force_recovery is set to 6 !!!
090318 19:09:54 [ERROR] /usr/local/libexec/mysqld: Can't create/write to file '/home/mysql/mysqld.pid' (Errcode: 13)
090318 19:09:54 [ERROR] Can't start server: can't create PID file: Permission denied
090318 19:09:54  mysqld ended

Please help...


-----Original message-----
From: Squirrel squirrel@mail.isot.com
Date: Wed, 18 Mar 2009 23:45:49 -0600
To: freebsd-stable freebsd-stable@freebsd.org
Subject: Re: Crash!!!

> Another thing, why is the error log shows bdb?  Isn't that Berkerly DB?  I didn't think I was using it.  I went ahead and removed it, but rebooted the server.  Only thing I can think is that I've installed virtualmin few days ago before this problem started.
> 
> These are my file premissions:
> 
> /home/
> drwxrwxrwx  33 mysql           mysql            1024 Mar 18 17:18 mysql
> ..
> 
> /home/mysql/
> [root@webserver /home/mysql]# ls -la
> total 143848
> drwxrwxrwx  33 mysql  mysql       1024 Mar 18 17:18 .
> drw-r--r--      71 felix  felix       1536 Mar 18 16:44 ..
> drwxrw-rw-   2 mysql  mysql       2560 Nov 21  2007 centexhomes
> drwxrw-rw-   2 mysql  mysql       2560 Oct 31  2007 centexrealtors
> drwxrw-rw-   2 mysql  mysql      18432 Mar  9 15:08 devildates
> drwxrw-rw-   2 mysql  mysql      14848 Feb 10  2008 dolphin
> drwxrw-rw-   2 mysql  mysql       2048 Mar  3  2008 drugal2
> drwxrw-rw-   2 mysql  mysql      13824 Feb 28  2008 drup
> ...
> drwxrw-rw-   2 mysql  mysql       1024 Oct 31  2007 treasure
> -rw-rw----   1 mysql  mysql       3785 Mar 18 17:18 webserver.isot.com.err
> -rwxrw-rw-   1 mysql  mysql      83676 Mar 18 16:30 webserver.isot.com.err.bak
> -rwxrw-rw-   1 mysql  mysql          5 Mar 17 11:27 webserver.isot.com.pid.bak
> drwxrw-rw-   2 mysql  mysql       7168 Jun 11  2008 yourshows
> drwxrw-rw-   2 mysql  mysql       2048 Mar 28  2008 yourshows_g2
> 
> 
> 
> -----Original message-----
> From: Squirrel squirrel@mail.isot.com
> Date: Wed, 18 Mar 2009 23:22:50 -0600
> To: freebsd-stable freebsd-stable@freebsd.org
> Subject: Crash!!!
> 
> > My webserver was working just fine on FreeBSD 6.2 Apache 2.2.11, MySQL 5.0.27.  All of sudden MySQL quit and won't start.  At the same time when logged in using SSH, it's looking for .bash_login and .bash_logout which it never did before, and will not chroot to user's home.
> > 
> > Trying to manual start mysql causes:
> > 
> > 090318 17:09:52  mysqld started
> > 090318 17:09:52  InnoDB: Started; log sequence number 2 2195718579
> > 090318 17:09:52 [ERROR] bdb:  /home/mysql: Permission denied
> > 090318 17:09:52 [ERROR] bdb:  /home/mysql/log.0000000001: Permission denied
> > 090318 17:09:52 [ERROR] bdb:  PANIC: Permission denied
> > 090318 17:09:52 [ERROR] bdb:  PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
> > 090318 17:09:52 [ERROR] bdb:  fatal region error detected; run recovery
> > 090318 17:09:52 [ERROR] bdb:  /home/mysql: Permission denied
> > 090318 17:09:52 [ERROR] /usr/local/libexec/mysqld: Can't create/write to file '/home/mysql/webserver.isot.com.pid' (Errcode: 13)
> > 090318 17:09:52 [ERROR] Can't start server: can't create PID file: Permission denied
> > 090318 17:09:52  mysqld ended
> > 
> > I tried db_recover, but it's not found.  HELP!!!
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> > 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
From doconnor at gsoft.com.au  Wed Mar 18 17:38:55 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Mar 18 17:39:05 2009
Subject: Crash!!!
In-Reply-To: <6a6f24080afb0b1cc84cc145b674c58c@mail.isot.com>
References: <6a6f24080afb0b1cc84cc145b674c58c@mail.isot.com>
Message-ID: <200903191108.50507.doconnor@gsoft.com.au>

On Thursday 19 March 2009 08:52:18 Squirrel wrote:
> My webserver was working just fine on FreeBSD 6.2 Apache 2.2.11, MySQL
> 5.0.27.  All of sudden MySQL quit and won't start.  At the same time when
> logged in using SSH, it's looking for .bash_login and .bash_logout which it
> never did before, and will not chroot to user's home.
>
> Trying to manual start mysql causes:
>
> 090318 17:09:52  mysqld started
> 090318 17:09:52  InnoDB: Started; log sequence number 2 2195718579
> 090318 17:09:52 [ERROR] bdb:  /home/mysql: Permission denied
> 090318 17:09:52 [ERROR] bdb:  /home/mysql/log.0000000001: Permission denied
> 090318 17:09:52 [ERROR] bdb:  PANIC: Permission denied
> 090318 17:09:52 [ERROR] bdb:  PANIC: DB_RUNRECOVERY: Fatal error, run
> database recovery 090318 17:09:52 [ERROR] bdb:  fatal region error
> detected; run recovery 090318 17:09:52 [ERROR] bdb:  /home/mysql:
> Permission denied
> 090318 17:09:52 [ERROR] /usr/local/libexec/mysqld: Can't create/write to
> file '/home/mysql/webserver.isot.com.pid' (Errcode: 13) 090318 17:09:52
> [ERROR] Can't start server: can't create PID file: Permission denied 090318
> 17:09:52  mysqld ended
>
> I tried db_recover, but it's not found.  HELP!!!

There are db_recover tools installed with BDB but they're called db41_recover 
or db_recover-4.2 etc.

The other error is that it doesn't appear to be able to write to /home/mysql 
but in your next email the perms look OK (well they are bad because 777 is 
insecure but they won't result in permission denied)

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090319/09fec987/attachment.pgp
From squirrel at mail.isot.com  Wed Mar 18 18:06:28 2009
From: squirrel at mail.isot.com (Squirrel)
Date: Wed Mar 18 18:06:35 2009
Subject: Crash!!!  --  Permission Error
Message-ID: <fa5dabb61f49658b4ec91026575b57e4@mail.isot.com>

I'm currently re-installing db41 port.  Earlier using  'innodb_force_recovery = 6' seemed to fix that PANIC error.  But I don't understand this permission error.  I've tried various permissions as well 777, 766, 666, 760, etc etc.  I've also ran mysqld_safe as root user, but with same permission error.  Also tried different directories without luck.

When I log in to the server shell, it won't chroot me to my home directory.  Instead it puts me in '/' with error message "no .bash_login.  And when I log out I get message "no .bash_logout".  I've never had these files in any of my users' directories.  Another strange thing just discovered is IE or FireFox display "Forbidden - You don't have permission to access / on this server", on all web sites.

So it seems that I have permission problem globally not just within MySQL.  What can possibly cause this permission problem?  Hard drive corruption?


-----Original message-----
From: "Daniel O'Connor" doconnor@gsoft.com.au
Date: Thu, 19 Mar 2009 01:39:30 -0600
To: freebsd-stable@freebsd.org
Subject: Re: Crash!!!

> On Thursday 19 March 2009 08:52:18 Squirrel wrote:
> > My webserver was working just fine on FreeBSD 6.2 Apache 2.2.11, MySQL
> > 5.0.27.  All of sudden MySQL quit and won't start.  At the same time when
> > logged in using SSH, it's looking for .bash_login and .bash_logout which it
> > never did before, and will not chroot to user's home.
> >
> > Trying to manual start mysql causes:
> >
> > 090318 17:09:52  mysqld started
> > 090318 17:09:52  InnoDB: Started; log sequence number 2 2195718579
> > 090318 17:09:52 [ERROR] bdb:  /home/mysql: Permission denied
> > 090318 17:09:52 [ERROR] bdb:  /home/mysql/log.0000000001: Permission denied
> > 090318 17:09:52 [ERROR] bdb:  PANIC: Permission denied
> > 090318 17:09:52 [ERROR] bdb:  PANIC: DB_RUNRECOVERY: Fatal error, run
> > database recovery 090318 17:09:52 [ERROR] bdb:  fatal region error
> > detected; run recovery 090318 17:09:52 [ERROR] bdb:  /home/mysql:
> > Permission denied
> > 090318 17:09:52 [ERROR] /usr/local/libexec/mysqld: Can't create/write to
> > file '/home/mysql/webserver.isot.com.pid' (Errcode: 13) 090318 17:09:52
> > [ERROR] Can't start server: can't create PID file: Permission denied 090318
> > 17:09:52  mysqld ended
> >
> > I tried db_recover, but it's not found.  HELP!!!
> 
> There are db_recover tools installed with BDB but they're called db41_recover 
> or db_recover-4.2 etc.
> 
> The other error is that it doesn't appear to be able to write to /home/mysql 
> but in your next email the perms look OK (well they are bad because 777 is 
> insecure but they won't result in permission denied)
> 
> -- 
> 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
> 
> 
> 
From doconnor at gsoft.com.au  Wed Mar 18 19:10:01 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Mar 18 19:10:08 2009
Subject: Crash!!!  --  Permission Error
In-Reply-To: <fa5dabb61f49658b4ec91026575b57e4@mail.isot.com>
References: <fa5dabb61f49658b4ec91026575b57e4@mail.isot.com>
Message-ID: <200903191239.52808.doconnor@gsoft.com.au>

On Thursday 19 March 2009 11:36:27 Squirrel wrote:
> I'm currently re-installing db41 port.  Earlier using 
> 'innodb_force_recovery = 6' seemed to fix that PANIC error.  But I don't
> understand this permission error.  I've tried various permissions as well
> 777, 766, 666, 760, etc etc.  I've also ran mysqld_safe as root user, but
> with same permission error.  Also tried different directories without luck.

I think you need to _understand_ the permissions before you blindly change 
them.

> When I log in to the server shell, it won't chroot me to my home directory.
>  Instead it puts me in '/' with error message "no .bash_login.  And when I
> log out I get message "no .bash_logout".  I've never had these files in any
> of my users' directories.  Another strange thing just discovered is IE or
> FireFox display "Forbidden - You don't have permission to access / on this
> server", on all web sites.

Does the user have permission to access all the elements in the path of their 
home directory?

ie if their home directory is /usr/home/foo can then cd into /usr, /usr/home 
and /usr/home/foo? If not you will get odd errors.

> So it seems that I have permission problem globally not just within MySQL. 
> What can possibly cause this permission problem?  Hard drive corruption?

Given you are blindly changing perms without really understanding, I suspect 
PEBKAC.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090319/6005d296/attachment.pgp
From rnoland at FreeBSD.org  Wed Mar 18 19:22:55 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Mar 18 19:23:02 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
Message-ID: <1237429357.1738.61.camel@balrog.2hip.net>

On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote:
> On Wed, 18 Mar 2009, Robert Noland wrote:
> 
> > On Tue, 2009-03-17 at 18:24 -0500, Greg Rivers wrote:
> >> On Tue, 17 Mar 2009, Robert Noland wrote:
> >>
> >>> On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote:
> >>>> On Sat, 10 Jan 2009, Robert Noland wrote:
> >>>>
> >>>>> I just merged drm (Direct Rendering) from HEAD.
> >>>>>
> >>>>>        - Support for latest Intel chips
> >>>>>        - Support and fixes for many AMD/ATI chips r500 and below
> >>>>>        - Support AMD/ATI IGP based chips (rs690/rs485)
> >>>>>        - Lots of code cleanups
> >>>>>        - Lots of other fixes and changes since the existing drm
> >>>>>          is 2+ years old
> >>>>>
> >>>>> If you are experiencing a "garbled" screen with certain pci/pci-e based
> >>>>> radeons, I have another patch in HEAD that isn't included yet.
> >>>>>
> >>>>
> >>>> I have a workstation with a [Radeon X600 (PCIE)] card.  The X display has
> >>>> been garbled since these DRM updates went in in January, and remains
> >>>> garbled with 7.1-STABLE as of yesterday.  As a work-around, I'm running
> >>>> the up-to-date 7.1-STABLE system (both world and ports) with a
> >>>> 7.1-RELEASE-p2 kernel.  The display is fine with the old kernel and X
> >>>> works great; I even see dramatically improved performance with the new
> >>>> Xorg and EXA acceleration.  Your work is much appreciated.
> >>>>
> >>>> But the garbled display with the recent DRM still plagues me.
> >>>>
> >>>> [snip]
> >>>
> >>> Could you try the attached patch.
> >>>
> >>
> >> Unfortunately, there is no noticeable difference with this patch.
> >>
> >>
> >>> Also, I'm guessing that this is a PCI based card, right?  Also, it isn't
> >>> an integrated model?
> >>>
> >>
> >> Yes, this is a PCIEx16 card in a HP Compaq dc7600 desktop PC, not a
> >> motherboard integrated adapter.
> >>
> >> Thanks for your help.  I'm willing to spend some time debugging this;
> >> please let me know if there's more information I can provide or other
> >> tests or patches I can try.
> >
> > Ok, try this patch... I asked the folks from AMD and they agree that
> > this shouldn't be needed on an RV370, but we will give it a try... This
> > is what fixed the garbled display on the IGP chips.
> >
> 
> The display is still garbled with this patch too.
> 
> I'm curious about why the drm driver calls this card a RV370, while pciconf
> and the X server call it a RV380:
>  	pciconf: "RV380 RADEON X600 Series 265MB"

I'm not sure where pciconf gets it's data.  I would actaully like to
look at that.

>  	X server: "ATI Technologies Inc RV380 [Radeon X600 (PCIE)]"

This comes from /usr/local/share/pciids/pci.ids

>  	drm driver: "ATI Radeon RV370 X600 Pro"

This comes from drm's own internal tables. (drm_pciids.h)

> Could it be that the drm driver has the wrong chip set or configuration for
> this PCI ID?

I don't think so, all of those should be about the same.

Ok, so it isn't the gart caching... Can you get me a pointer to a
screenshot?  What is garbled exactly?  Is the damage constrained to
specific windows or it it the entire framebuffer?

robert.

> -- 
> Greg Rivers
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090319/f44b2ff5/attachment.pgp
From ertr1013 at student.uu.se  Wed Mar 18 23:14:43 2009
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Wed Mar 18 23:14:50 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1237429357.1738.61.camel@balrog.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
	<1237429357.1738.61.camel@balrog.2hip.net>
Message-ID: <20090319061438.GA48484@owl.midgard.homeip.net>

On Wed, Mar 18, 2009 at 09:22:37PM -0500, Robert Noland wrote:
> On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote:

[snip]

> > 
> > I'm curious about why the drm driver calls this card a RV370, while pciconf
> > and the X server call it a RV380:
> >  	pciconf: "RV380 RADEON X600 Series 265MB"
> 
> I'm not sure where pciconf gets it's data.  I would actaully like to
> look at that.

According to the pciconf(8) manpage:

     The PCI vendor/device information database is normally read from
     /usr/share/misc/pci_vendors.  This path can be overridden by setting
     the environment variable PCICONF_VENDOR_DATABASE.





-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From rnoland at FreeBSD.org  Thu Mar 19 00:04:35 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Mar 19 00:04:47 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <20090319061438.GA48484@owl.midgard.homeip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
	<1237429357.1738.61.camel@balrog.2hip.net>
	<20090319061438.GA48484@owl.midgard.homeip.net>
Message-ID: <1237446254.6146.45.camel@balrog.2hip.net>

On Thu, 2009-03-19 at 07:14 +0100, Erik Trulsson wrote:
> On Wed, Mar 18, 2009 at 09:22:37PM -0500, Robert Noland wrote:
> > On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote:
> 
> [snip]
> 
> > > 
> > > I'm curious about why the drm driver calls this card a RV370, while pciconf
> > > and the X server call it a RV380:
> > >  	pciconf: "RV380 RADEON X600 Series 265MB"
> > 
> > I'm not sure where pciconf gets it's data.  I would actaully like to
> > look at that.
> 
> According to the pciconf(8) manpage:
> 
>      The PCI vendor/device information database is normally read from
>      /usr/share/misc/pci_vendors.  This path can be overridden by setting
>      the environment variable PCICONF_VENDOR_DATABASE.

Right, that is just the vendor id though, not the device name string.
The reason that I'm curious is that I was trying to extract device name
info from Nvidia cards the other day, without using a static data
source.

robert.

> 
> 
> 
> 
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090319/8662212e/attachment.pgp
From jack at jarasoft.net  Thu Mar 19 01:47:25 2009
From: jack at jarasoft.net (Jack Raats)
Date: Thu Mar 19 01:47:32 2009
Subject: FreeBSD 7.2 Release process starting...
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu><20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
Message-ID: <91210A8474CD444786833AFD3542BCCA@jarasoft.net>

----- Original Message ----- 
From: "Robert Watson" <rwatson@FreeBSD.org>

> One of the most important things for us to keep an eye on in this release 
> is that the boot loader now works on a number of pieces of hardware on 
> which it reressed for 6.4/7.1.  If it proves successful, we'll likely also 
> do errata notes and roll new ISOs for 6.4.

About FreeBSD 6.4. If you consider to make new 6.4 iso's, perhaps it would 
be better to think about an 6.5 release????

Jack Raats 

From ertr1013 at student.uu.se  Thu Mar 19 02:02:38 2009
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Thu Mar 19 02:02:45 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1237446254.6146.45.camel@balrog.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
	<1237429357.1738.61.camel@balrog.2hip.net>
	<20090319061438.GA48484@owl.midgard.homeip.net>
	<1237446254.6146.45.camel@balrog.2hip.net>
Message-ID: <20090319090219.GA49247@owl.midgard.homeip.net>

On Thu, Mar 19, 2009 at 02:04:14AM -0500, Robert Noland wrote:
> On Thu, 2009-03-19 at 07:14 +0100, Erik Trulsson wrote:
> > On Wed, Mar 18, 2009 at 09:22:37PM -0500, Robert Noland wrote:
> > > On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote:
> > 
> > [snip]
> > 
> > > > 
> > > > I'm curious about why the drm driver calls this card a RV370, while pciconf
> > > > and the X server call it a RV380:
> > > >  	pciconf: "RV380 RADEON X600 Series 265MB"
> > > 
> > > I'm not sure where pciconf gets it's data.  I would actaully like to
> > > look at that.
> > 
> > According to the pciconf(8) manpage:
> > 
> >      The PCI vendor/device information database is normally read from
> >      /usr/share/misc/pci_vendors.  This path can be overridden by setting
> >      the environment variable PCICONF_VENDOR_DATABASE.
> 
> Right, that is just the vendor id though, not the device name string.

Have you actually looked at the contents of that file?
All the strings describing vendor and device name that pciconf prints can
be found in that file.


> The reason that I'm curious is that I was trying to extract device name
> info from Nvidia cards the other day, without using a static data
> source.
> 
> robert.
> 




-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From torfinn.ingolfsen at broadpark.no  Thu Mar 19 02:24:42 2009
From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen)
Date: Thu Mar 19 02:24:50 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
Message-ID: <20090319102439.cd75b2a0.torfinn.ingolfsen@broadpark.no>

On Wed, 18 Mar 2009 18:18:41 -0500 (CDT)
Greg Rivers <gcr+freebsd-stable@tharned.org> wrote:

> I'm curious about why the drm driver calls this card a RV370, while
> pciconf and the X server call it a RV380:

You could always install the pciutils (sysutils/pciutils) port and find
out what 'lspci' says, for one more data point.
-- 
Torfinn Ingolfsen

From rwatson at FreeBSD.org  Thu Mar 19 02:34:13 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Thu Mar 19 02:34:20 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <91210A8474CD444786833AFD3542BCCA@jarasoft.net>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu><20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
	<91210A8474CD444786833AFD3542BCCA@jarasoft.net>
Message-ID: <alpine.BSF.2.00.0903190927320.99520@fledge.watson.org>


On Thu, 19 Mar 2009, Jack Raats wrote:

>> One of the most important things for us to keep an eye on in this release 
>> is that the boot loader now works on a number of pieces of hardware on 
>> which it reressed for 6.4/7.1.  If it proves successful, we'll likely also 
>> do errata notes and roll new ISOs for 6.4.
>
> About FreeBSD 6.4. If you consider to make new 6.4 iso's, perhaps it would 
> be better to think about an 6.5 release????

It's a question of bandwidth for the release engineering team, ports team, 
security officer team, etc -- I think a 6.5 is pretty much out of the question 
right now with 8.0 preparing to ramp up and 7.2 now in flight.  That gives us 
a short menu of options:

- Errata patches
- Errata patches + ISO reroll
- Point release

Because of the boot loader issues, errata patches don't really cut it alone, 
as if you can't install, you definitely can't apply errata patches :-).  This 
suggests a reroll or a point release.

For me the distinction remains fuzzy, but I think a key to either approach 
would be avoiding having to fully re-QA, do BETAs, build new packages, etc. 
This suggests taking RELENG_6_4 on some date, perhaps rebranching if it's a 
point release, or not if it's an ISO reroll, and bundling it with exactly the 
same packages we shipped in 6.4 (etc) and bumping a few documentation parts. 
We'd cut a release candidate just to make sure we had the bits right, ask 
people to test install it, etc, but as there would be no new features, we'd 
expect relatively little change. I think I wouldn't even change the proposed 
EoL date of the branch -- 7.x is doing very well, and we need developers to 
focus on getting 8.0 ready to ship.

Robert N M Watson
Computer Laboratory
University of Cambridge
From jack at jarasoft.net  Thu Mar 19 02:51:47 2009
From: jack at jarasoft.net (Jack Raats)
Date: Thu Mar 19 02:51:54 2009
Subject: FreeBSD 7.2 Release process starting...
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu><20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
	<91210A8474CD444786833AFD3542BCCA@jarasoft.net>
	<alpine.BSF.2.00.0903190927320.99520@fledge.watson.org>
Message-ID: <997A6168643B453CB90D2A25AD7AE563@jarasoft.net>

From: "Robert Watson" <rwatson@FreeBSD.org>

>> About FreeBSD 6.4. If you consider to make new 6.4 iso's, perhaps it 
>> would be better to think about an 6.5 release????
>
> It's a question of bandwidth for the release engineering team, ports team, 
> security officer team, etc -- I think a 6.5 is pretty much out of the 
> question right now with 8.0 preparing to ramp up and 7.2 now in flight. 
> That gives us a short menu of options:
>
> - Errata patches
> - Errata patches + ISO reroll
> - Point release
>
> Because of the boot loader issues, errata patches don't really cut it 
> alone, as if you can't install, you definitely can't apply errata patches 
> :-).  This suggests a reroll or a point release.

This reminds me of FreeBSD 4.6 and FreeBSD 4.6.2 (The first FreeBSD I ever 
used was 4.6, that's why I remember)

> For me the distinction remains fuzzy, but I think a key to either approach 
> would be avoiding having to fully re-QA, do BETAs, build new packages, 
> etc. This suggests taking RELENG_6_4 on some date, perhaps rebranching if 
> it's a point release, or not if it's an ISO reroll, and bundling it with 
> exactly the same packages we shipped in 6.4 (etc) and bumping a few 
> documentation parts.

Indeed, that's a lot of work for an errata patch.

Jack

From mlfreebsd at streamingedge.com  Thu Mar 19 05:28:03 2009
From: mlfreebsd at streamingedge.com (Jacques Manukyan)
Date: Thu Mar 19 05:28:11 2009
Subject: Crash!!!  --  Permission Error
In-Reply-To: <fa5dabb61f49658b4ec91026575b57e4@mail.isot.com>
References: <fa5dabb61f49658b4ec91026575b57e4@mail.isot.com>
Message-ID: <49C23639.5050109@streamingedge.com>

The first thing that pops into my mind is that you may not be running 
mysql as the mysql user. Are you using a custom startup script? Did you 
change the mysql_user variable in the startup script? Do you have a 
custom my.cnf perhaps?

-- Jacques Manukyan


Squirrel wrote:
> I'm currently re-installing db41 port.  Earlier using  'innodb_force_recovery = 6' seemed to fix that PANIC error.  But I don't understand this permission error.  I've tried various permissions as well 777, 766, 666, 760, etc etc.  I've also ran mysqld_safe as root user, but with same permission error.  Also tried different directories without luck.
>
> When I log in to the server shell, it won't chroot me to my home directory.  Instead it puts me in '/' with error message "no .bash_login.  And when I log out I get message "no .bash_logout".  I've never had these files in any of my users' directories.  Another strange thing just discovered is IE or FireFox display "Forbidden - You don't have permission to access / on this server", on all web sites.
>
> So it seems that I have permission problem globally not just within MySQL.  What can possibly cause this permission problem?  Hard drive corruption?
>
>
> -----Original message-----
> From: "Daniel O'Connor" doconnor@gsoft.com.au
> Date: Thu, 19 Mar 2009 01:39:30 -0600
> To: freebsd-stable@freebsd.org
> Subject: Re: Crash!!!
>
>   
>> On Thursday 19 March 2009 08:52:18 Squirrel wrote:
>>     
>>> My webserver was working just fine on FreeBSD 6.2 Apache 2.2.11, MySQL
>>> 5.0.27.  All of sudden MySQL quit and won't start.  At the same time when
>>> logged in using SSH, it's looking for .bash_login and .bash_logout which it
>>> never did before, and will not chroot to user's home.
>>>
>>> Trying to manual start mysql causes:
>>>
>>> 090318 17:09:52  mysqld started
>>> 090318 17:09:52  InnoDB: Started; log sequence number 2 2195718579
>>> 090318 17:09:52 [ERROR] bdb:  /home/mysql: Permission denied
>>> 090318 17:09:52 [ERROR] bdb:  /home/mysql/log.0000000001: Permission denied
>>> 090318 17:09:52 [ERROR] bdb:  PANIC: Permission denied
>>> 090318 17:09:52 [ERROR] bdb:  PANIC: DB_RUNRECOVERY: Fatal error, run
>>> database recovery 090318 17:09:52 [ERROR] bdb:  fatal region error
>>> detected; run recovery 090318 17:09:52 [ERROR] bdb:  /home/mysql:
>>> Permission denied
>>> 090318 17:09:52 [ERROR] /usr/local/libexec/mysqld: Can't create/write to
>>> file '/home/mysql/webserver.isot.com.pid' (Errcode: 13) 090318 17:09:52
>>> [ERROR] Can't start server: can't create PID file: Permission denied 090318
>>> 17:09:52  mysqld ended
>>>
>>> I tried db_recover, but it's not found.  HELP!!!
>>>       
>> There are db_recover tools installed with BDB but they're called db41_recover 
>> or db_recover-4.2 etc.
>>
>> The other error is that it doesn't appear to be able to write to /home/mysql 
>> but in your next email the perms look OK (well they are bad because 777 is 
>> insecure but they won't result in permission denied)
>>
>> -- 
>> 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
>>
>>
>>
>>     
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
>   

From tim at chase2k.com  Thu Mar 19 06:09:32 2009
From: tim at chase2k.com (Tim Chase)
Date: Thu Mar 19 06:09:40 2009
Subject: in recent 7-STABLE: VOP_WRITE...is not exclusive locked but should
 be
Message-ID: <alpine.LFD.2.00.0903190639450.9228@cardinal>

Hello,

I have a system that had been running quite well with an oldish 7-STABLE
(from around August 7, 2008) but has started deadlocking within the past
week or so.

I updated the kernel to a newer 7-STABLE (Mar 15, 2009) and enabled
INVARIANTS, INVARIANT_SUPPORT, WITNESS, DEBUG_LOCKS DEBUG_VFS_LOCKS and
DIAGNOSTIC and the message indicated in the subject line has now appeared
3 times as shown below.  Is this something to be terribly concerned about?
Is there anything I can to to further track down the cause?  Since the
system is a production mail server, I have it set to not drop into DDB
when this happens.

The machine is a 4-core Xeon X5450 with 8G of RAM running FreeBSD
amd64 and in userland it's pretty much just cyrus imapd and apache/php.
The file systems are all ZFS on a bunch of SAS drives connected to a
LSI Logic 1068 controller.

As to the deadlock that started this exercise, if the machine follows its
recent pattern, that should happen within the next 2-4 hours.

 	Thanks,
 	Tim

-- kernel messages and dmesg.boot below --
Mar 18 14:46:56 xx kernel: KDB: stack backtrace:
Mar 18 14:46:56 xx kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
Mar 18 14:46:56 xx kernel: vfs_badlock() at vfs_badlock+0x95
Mar 18 14:46:56 xx kernel: assert_vop_elocked() at assert_vop_elocked+0x64
Mar 18 14:46:56 xx kernel: VOP_WRITE_APV() at VOP_WRITE_APV+0x155
Mar 18 14:46:56 xx kernel: vn_write() at vn_write+0x1ce
Mar 18 14:46:56 xx kernel: dofilewrite() at dofilewrite+0x85
Mar 18 14:46:56 xx kernel: kern_writev() at kern_writev+0x4c
Mar 18 14:46:56 xx kernel: write() at write+0x54
Mar 18 14:46:56 xx kernel: syscall() at syscall+0x1f6
Mar 18 14:46:56 xx kernel: Xfast_syscall() at Xfast_syscall+0xab
Mar 18 14:46:56 xx kernel: --- syscall (4, FreeBSD ELF64, write), rip = 0x8015aad3c, rsp = 0x7fffffffa658,rbp = 0x803df2fa0 ---
Mar 18 23:56:45 xx kernel: KDB: stack backtrace:
Mar 18 23:56:45 xx kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
Mar 18 23:56:45 xx kernel: vfs_badlock() at vfs_badlock+0x95
Mar 18 23:56:45 xx kernel: assert_vop_elocked() at assert_vop_elocked+0x64
Mar 18 23:56:45 xx kernel: VOP_WRITE_APV() at VOP_WRITE_APV+0x155
Mar 18 23:56:45 xx kernel: vn_write() at vn_write+0x1ce
Mar 18 23:56:45 xx kernel: dofilewrite() at dofilewrite+0x85
Mar 18 23:56:45 xx kernel: kern_writev() at kern_writev+0x4c
Mar 18 23:56:45 xx kernel: write() at write+0x54
Mar 18 23:56:45 xx kernel: syscall() at syscall+0x1f6
Mar 18 23:56:45 xx kernel: Xfast_syscall() at Xfast_syscall+0xab
Mar 18 23:56:45 xx kernel: --- syscall (4, FreeBSD ELF64, write), rip = 0x8015aad3c, rsp = 0x7fffffffa658,rbp = 0x803e1427c ---
Mar 18 23:56:45 xx kernel: VOP_WRITE: 0xffffff0106e9c290 is not exclusive locked but should be
Mar 18 23:56:58 xx kernel: KDB: stack backtrace:
Mar 18 23:56:58 xx kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
Mar 18 23:56:58 xx kernel: vfs_badlock() at vfs_badlock+0x95
Mar 18 23:56:58 xx kernel: assert_vop_elocked() at assert_vop_elocked+0x64
Mar 18 23:56:58 xx kernel: VOP_WRITE_APV() at VOP_WRITE_APV+0x155
Mar 18 23:56:58 xx kernel: vn_write() at vn_write+0x1ce
Mar 18 23:56:58 xx kernel: dofilewrite() at dofilewrite+0x85
Mar 18 23:56:58 xx kernel: kern_writev() at kern_writev+0x4c
Mar 18 23:56:58 xx kernel: write() at write+0x54
Mar 18 23:56:58 xx kernel: syscall() at syscall+0x1f6
Mar 18 23:56:58 xx kernel: Xfast_syscall() at Xfast_syscall+0xab
Mar 18 23:56:58 xx kernel: --- syscall (4, FreeBSD ELF64, write), rip = 0x8015aad3c, rsp = 0x7fffffffa658,rbp = 0x803e1740c ---
Mar 18 23:56:58 xx kernel: VOP_WRITE: 0xffffff0106e9c290 is not exclusive locked but should be

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-STABLE #1: Sun Mar 15 12:20:02 CDT 2009
     root@xx:/root/stable7-working/src/sys/amd64/compile/SWMAIL
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU           X5450  @ 3.00GHz (2992.52-MHz K8-class CPU)
   Origin = "GenuineIntel"  Id = 0x10676  Stepping = 6
   Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
   Features2=0xce3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,<b19>>
   AMD Features=0x20100800<SYSCALL,NX,LM>
   AMD Features2=0x1<LAHF>
   Cores per package: 4
usable memory = 8580468736 (8182 MB)
avail memory  = 8283054080 (7899 MB)
ACPI APIC Table: <042908 APIC1058>
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
  cpu2 (AP): APIC ID:  2
  cpu3 (AP): APIC ID:  3
WITNESS: spin lock cpuset not in order list
This module (opensolaris) contains code covered by the
Common Development and Distribution License (CDDL)
see http://opensolaris.org/os/licensing/opensolaris_license/
WITNESS: spin lock intrcnt not in order list
ioapic0 <Version 2.0> irqs 0-23 on motherboard
ioapic1 <Version 2.0> irqs 24-47 on motherboard
ioapic2 <Version 2.0> irqs 48-71 on motherboard
kbd1 at kbdmux0
acpi0: <042908 XSDT1058> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of fed1c000, 4000 (3) failed
acpi0: reservation of fed20000, 25000 (3) failed
acpi0: reservation of fed45000, 5b000 (3) failed
acpi0: reservation of feda0000, 20000 (3) failed
acpi0: reservation of fec01000, 7f000 (3) failed
acpi0: reservation of fec80000, 6000 (3) failed
acpi0: reservation of fec86000, a000 (3) failed
acpi0: reservation of ff000000, 400000 (3) failed
acpi0: reservation of ff400000, 400000 (3) failed
acpi0: reservation of ff800000, 400000 (3) failed
acpi0: reservation of ffc00000, 400000 (3) failed
acpi0: reservation of fec00000, 1000 (3) failed
acpi0: reservation of fee00000, 1000 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, dff00000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 48 at device 1.0 on pci0
pci11: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> irq 52 at device 5.0 on pci0
pci10: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> irq 56 at device 9.0 on pci0
pci5: <ACPI PCI bus> on pcib3
pcib4: <ACPI PCI-PCI bridge> irq 16 at device 0.0 on pci5
pci7: <ACPI PCI bus> on pcib4
pcib5: <ACPI PCI-PCI bridge> at device 0.0 on pci7
pci9: <ACPI PCI bus> on pcib5
pcib6: <ACPI PCI-PCI bridge> at device 2.0 on pci7
pci8: <ACPI PCI bus> on pcib6
em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xe880-0xe89f mem 0xfdfa0000-0xfdfbffff irq 18 at device 0.0 on pci8
em0: Using MSI interrupt
em0: [FILTER]
em0: Ethernet address: 00:22:15:88:38:fc
em1: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xec00-0xec1f mem 0xfdfe0000-0xfdffffff irq 19 at device 0.1 on pci8
em1: Using MSI interrupt
em1: [FILTER]
em1: Ethernet address: 00:22:15:88:38:fd
pcib7: <ACPI PCI-PCI bridge> at device 0.3 on pci5
pci6: <ACPI PCI bus> on pcib7
mpt0: <LSILogic SAS/SATA Adapter> port 0xd000-0xd0ff mem 0xfdefc000-0xfdefffff,0xfdee0000-0xfdeeffff irq 26 at device 3.0 on pci6
mpt0: [ITHREAD]
mpt0: MPI Version=1.5.16.0
mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
mpt0: 0 Active Volumes (2 Max)
mpt0: 0 Hidden Drive Members (14 Max)
pci0: <base peripheral> at device 15.0 (no driver attached)
pcib8: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci4: <ACPI PCI bus> on pcib8
pcib9: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
pci3: <ACPI PCI bus> on pcib9
em2: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xcc00-0xcc1f mem 0xfdae0000-0xfdafffff irq 18 at device 0.0 on pci3
em2: Using MSI interrupt
em2: [FILTER]
em2: Ethernet address: 00:22:15:88:39:93
pcib10: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
pci2: <ACPI PCI bus> on pcib10
em3: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xbc00-0xbc1f mem 0xfd9e0000-0xfd9fffff irq 19 at device 0.0 on pci2
em3: Using MSI interrupt
em3: [FILTER]
em3: Ethernet address: 00:22:15:88:39:61
pci0: <serial bus, USB> at device 29.0 (no driver attached)
pci0: <serial bus, USB> at device 29.1 (no driver attached)
pci0: <serial bus, USB> at device 29.7 (no driver attached)
pcib11: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci1: <ACPI PCI bus> on pcib11
vgapci0: <VGA-compatible display> port 0xac00-0xac7f mem 0xf8000000-0xfbffffff,0xfd8c0000-0xfd8fffff at device 2.0 on pci1
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel 63XXESB2 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
atapci1: <Intel 63XXESB2 SATA300 controller> port 0x9c00-0x9c07,0x9880-0x9883,0x9800-0x9807,0x9480-0x9483,0x9400-0x940f mem 0xfd7ffc00-0xfd7fffff irq 19 at device 31.2 on pci0
atapci1: [ITHREAD]
ata2: <ATA channel 0> on atapci1
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci1
ata3: [ITHREAD]
pci0: <serial bus, SMBus> at device 31.3 (no driver attached)
acpi_button0: <Power Button> on acpi0
fdc0: <floppy drive controller (FDE)> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse Explorer, device ID 4
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x30 on acpi0
sio0: type 16550A, console
sio0: [FILTER]
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
sio1: [FILTER]
cpu0: <ACPI CPU> on acpi0
est0: failed to enable SpeedStep
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: failed to enable SpeedStep
p4tcc1: <CPU Frequency Thermal Control> on cpu1
cpu2: <ACPI CPU> on acpi0
est2: failed to enable SpeedStep
p4tcc2: <CPU Frequency Thermal Control> on cpu2
cpu3: <ACPI CPU> on acpi0
est3: failed to enable SpeedStep
p4tcc3: <CPU Frequency Thermal Control> on cpu3
orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xd0000-0xd0fff,0xd1000-0xd1fff on isa0
ppc0: cannot reserve I/O port range
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x100>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
WARNING: ZFS is considered to be an experimental feature in FreeBSD.
Timecounters tick every 1.000 msec
ZFS filesystem version 6
ZFS storage pool version 6
acd0: DMA limited to UDMA33, controller found non-ATA66 cable
acd0: DVDROM <MATSHITADVD-ROM SR-8178/PZ16> at ata0-master UDMA33
da0 at mpt0 bus 0 target 0 lun 0
da0: <SEAGATE ST31000640SS 0001> Fixed Direct Access SCSI-5 device 
da0: 300.000MB/s transfers
da0: Command Queueing Enabled
da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da1 at mpt0 bus 0 target 1 lun 0
da1: <SEAGATE ST31000640SS 0001> Fixed Direct Access SCSI-5 device 
da1: 300.000MB/s transfers
da1: Command Queueing Enabled
da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da2 at mpt0 bus 0 target 2 lun 0
da2: <SEAGATE ST31000640SS 0001> Fixed Direct Access SCSI-5 device 
da2: 300.000MB/s transfers
da2: Command Queueing Enabled
da2: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da3 at mpt0 bus 0 target 3 lun 0
da3: <SEAGATE ST31000640SS 0001> Fixed Direct Access SCSI-5 device 
da3: 300.000MB/s transfers
da3: Command Queueing Enabled
da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da4 at mpt0 bus 0 target 4 lun 0
da4: <SEAGATE ST31000640SS 0001> Fixed Direct Access SCSI-5 device 
da4: 300.000MB/s transfers
da4: Command Queueing Enabled
da4: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da5 at mpt0 bus 0 target 5 lun 0
da5: <SEAGATE ST31000640SS 0001> Fixed Direct Access SCSI-5 device 
da5: 300.000MB/s transfers
da5: Command Queueing Enabled
da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da6 at mpt0 bus 0 target 6 lun 0
da6: <SEAGATE ST31000640SS 0001> Fixed Direct Access SCSI-5 device 
da6: 300.000MB/s transfers
da6: Command Queueing Enabled
da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
da7 at mpt0 bus 0 target 7 lun 0
da7: <SEAGATE ST31000640SS 0001> Fixed Direct Access SCSI-5 device 
da7: 300.000MB/s transfers
da7: Command Queueing Enabled
da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)
SMP: AP CPU #1 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #2 Launched!
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
Trying to mount root from zfs:tank/root
em1: link state changed to UP
From jhb at freebsd.org  Thu Mar 19 08:58:41 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Mar 19 08:58:59 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <alpine.BSF.2.00.0903190927320.99520@fledge.watson.org>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<91210A8474CD444786833AFD3542BCCA@jarasoft.net>
	<alpine.BSF.2.00.0903190927320.99520@fledge.watson.org>
Message-ID: <200903190958.11440.jhb@freebsd.org>

On Thursday 19 March 2009 5:34:12 am Robert Watson wrote:
> For me the distinction remains fuzzy, but I think a key to either approach 
> would be avoiding having to fully re-QA, do BETAs, build new packages, etc. 
> This suggests taking RELENG_6_4 on some date, perhaps rebranching if it's a 
> point release, or not if it's an ISO reroll, and bundling it with exactly 
the 
> same packages we shipped in 6.4 (etc) and bumping a few documentation parts. 
> We'd cut a release candidate just to make sure we had the bits right, ask 
> people to test install it, etc, but as there would be no new features, we'd 
> expect relatively little change. I think I wouldn't even change the proposed 
> EoL date of the branch -- 7.x is doing very well, and we need developers to 
> focus on getting 8.0 ready to ship.

Actually, a point release shouldn't be a rebranch, it would just be a new tag 
on the existing RELENG_6_4 branch.  The only difference in a point release 
vs. an errata patch is what you change the release name to 
(6.4-RELEASE-p(X+1) vs 6.4.1-RELEASE)) and whether or not you upload bits to 
the ftp servers.  If the goal is to generate ISOs that we put up for ftp, I 
think it should be a point release, but it would certainly reuse 6.4 packages 
(or have no packages).  That is, I think "ISO reroll" == "point release".  I 
also think we shouldn't upload things to ftp that aren't actual releases 
(that is, I wouldn't upload 6.4-RELEASE-p10 to ftp since we don't upload new 
release bits for every security advisory we do).

-- 
John Baldwin
From jhb at freebsd.org  Thu Mar 19 08:58:43 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Mar 19 08:59:01 2009
Subject: in recent 7-STABLE: VOP_WRITE...is not exclusive locked but
	should be
In-Reply-To: <alpine.LFD.2.00.0903190639450.9228@cardinal>
References: <alpine.LFD.2.00.0903190639450.9228@cardinal>
Message-ID: <200903191001.44491.jhb@freebsd.org>

On Thursday 19 March 2009 8:05:34 am Tim Chase wrote:
> Hello,
> 
> I have a system that had been running quite well with an oldish 7-STABLE
> (from around August 7, 2008) but has started deadlocking within the past
> week or so.
> 
> I updated the kernel to a newer 7-STABLE (Mar 15, 2009) and enabled
> INVARIANTS, INVARIANT_SUPPORT, WITNESS, DEBUG_LOCKS DEBUG_VFS_LOCKS and
> DIAGNOSTIC and the message indicated in the subject line has now appeared
> 3 times as shown below.  Is this something to be terribly concerned about?
> Is there anything I can to to further track down the cause?  Since the
> system is a production mail server, I have it set to not drop into DDB
> when this happens.
> 
> The machine is a 4-core Xeon X5450 with 8G of RAM running FreeBSD
> amd64 and in userland it's pretty much just cyrus imapd and apache/php.
> The file systems are all ZFS on a bunch of SAS drives connected to a
> LSI Logic 1068 controller.
> 
> As to the deadlock that started this exercise, if the machine follows its
> recent pattern, that should happen within the next 2-4 hours.

Err, the vn_write() routine should be using an exclusive vnode lock:

vn_write()
{

	...
	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
	if ((flags & FOF_OFFSET) == 0)
		uio->uio_offset = fp->f_offset;
	ioflag |= sequential_heuristic(uio, fp);
#ifdef MAC
	error = mac_check_vnode_write(active_cred, fp->f_cred, vp);
	if (error == 0)
#endif
		error = VOP_WRITE(vp, uio, ioflag, fp->f_cred);
	...
}

Can you check your /sys/kern/vfs_vnops.c and verify that LK_EXCLUSIVE is 
present in your vn_write() routine?  If so, then perhaps run memtest?

-- 
John Baldwin
From kostikbel at gmail.com  Thu Mar 19 09:02:57 2009
From: kostikbel at gmail.com (Kostik Belousov)
Date: Thu Mar 19 09:03:04 2009
Subject: in recent 7-STABLE: VOP_WRITE...is not exclusive locked but
	should be
In-Reply-To: <200903191001.44491.jhb@freebsd.org>
References: <alpine.LFD.2.00.0903190639450.9228@cardinal>
	<200903191001.44491.jhb@freebsd.org>
Message-ID: <20090319160251.GJ7716@deviant.kiev.zoral.com.ua>

On Thu, Mar 19, 2009 at 10:01:44AM -0400, John Baldwin wrote:
> On Thursday 19 March 2009 8:05:34 am Tim Chase wrote:
> > Hello,
> > 
> > I have a system that had been running quite well with an oldish 7-STABLE
> > (from around August 7, 2008) but has started deadlocking within the past
> > week or so.
> > 
> > I updated the kernel to a newer 7-STABLE (Mar 15, 2009) and enabled
> > INVARIANTS, INVARIANT_SUPPORT, WITNESS, DEBUG_LOCKS DEBUG_VFS_LOCKS and
> > DIAGNOSTIC and the message indicated in the subject line has now appeared
> > 3 times as shown below.  Is this something to be terribly concerned about?
> > Is there anything I can to to further track down the cause?  Since the
> > system is a production mail server, I have it set to not drop into DDB
> > when this happens.
> > 
> > The machine is a 4-core Xeon X5450 with 8G of RAM running FreeBSD
> > amd64 and in userland it's pretty much just cyrus imapd and apache/php.
> > The file systems are all ZFS on a bunch of SAS drives connected to a
> > LSI Logic 1068 controller.
> > 
> > As to the deadlock that started this exercise, if the machine follows its
> > recent pattern, that should happen within the next 2-4 hours.
> 
> Err, the vn_write() routine should be using an exclusive vnode lock:
> 
> vn_write()
> {
> 
> 	...
> 	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
> 	if ((flags & FOF_OFFSET) == 0)
> 		uio->uio_offset = fp->f_offset;
> 	ioflag |= sequential_heuristic(uio, fp);
> #ifdef MAC
> 	error = mac_check_vnode_write(active_cred, fp->f_cred, vp);
> 	if (error == 0)
> #endif
> 		error = VOP_WRITE(vp, uio, ioflag, fp->f_cred);
> 	...
> }
> 
> Can you check your /sys/kern/vfs_vnops.c and verify that LK_EXCLUSIVE is 
> present in your vn_write() routine?  If so, then perhaps run memtest?

Note that this happens on the ZFS. Might be, ZFS unlocks the vnode and
then relocks it with some invalid flags ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090319/3564ce94/attachment.pgp
From rnoland at FreeBSD.org  Thu Mar 19 09:27:09 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Mar 19 09:27:16 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <20090319090219.GA49247@owl.midgard.homeip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
	<1237429357.1738.61.camel@balrog.2hip.net>
	<20090319061438.GA48484@owl.midgard.homeip.net>
	<1237446254.6146.45.camel@balrog.2hip.net>
	<20090319090219.GA49247@owl.midgard.homeip.net>
Message-ID: <1237480008.1732.0.camel@balrog.2hip.net>

On Thu, 2009-03-19 at 10:02 +0100, Erik Trulsson wrote:
> On Thu, Mar 19, 2009 at 02:04:14AM -0500, Robert Noland wrote:
> > On Thu, 2009-03-19 at 07:14 +0100, Erik Trulsson wrote:
> > > On Wed, Mar 18, 2009 at 09:22:37PM -0500, Robert Noland wrote:
> > > > On Wed, 2009-03-18 at 18:18 -0500, Greg Rivers wrote:
> > > 
> > > [snip]
> > > 
> > > > > 
> > > > > I'm curious about why the drm driver calls this card a RV370, while pciconf
> > > > > and the X server call it a RV380:
> > > > >  	pciconf: "RV380 RADEON X600 Series 265MB"
> > > > 
> > > > I'm not sure where pciconf gets it's data.  I would actaully like to
> > > > look at that.
> > > 
> > > According to the pciconf(8) manpage:
> > > 
> > >      The PCI vendor/device information database is normally read from
> > >      /usr/share/misc/pci_vendors.  This path can be overridden by setting
> > >      the environment variable PCICONF_VENDOR_DATABASE.
> > 
> > Right, that is just the vendor id though, not the device name string.
> 
> Have you actually looked at the contents of that file?
> All the strings describing vendor and device name that pciconf prints can
> be found in that file.

Hrm, Ok... I only glanced at it, it lists only the vendors first.

robert.

> 
> > The reason that I'm curious is that I was trying to extract device name
> > info from Nvidia cards the other day, without using a static data
> > source.
> > 
> > robert.
> > 
> 
> 
> 
> 
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090319/53b3c7f7/attachment.pgp
From rnoland at FreeBSD.org  Thu Mar 19 10:04:02 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Mar 19 10:04:09 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <20090319102439.cd75b2a0.torfinn.ingolfsen@broadpark.no>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
	<20090319102439.cd75b2a0.torfinn.ingolfsen@broadpark.no>
Message-ID: <1237482221.1732.35.camel@balrog.2hip.net>

On Thu, 2009-03-19 at 10:24 +0100, Torfinn Ingolfsen wrote:
> On Wed, 18 Mar 2009 18:18:41 -0500 (CDT)
> Greg Rivers <gcr+freebsd-stable@tharned.org> wrote:
> 
> > I'm curious about why the drm driver calls this card a RV370, while
> > pciconf and the X server call it a RV380:

FWIW, despite the text description, drm treats this as CHIP_RV380.

robert.

> You could always install the pciutils (sysutils/pciutils) port and find
> out what 'lspci' says, for one more data point.
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090319/2acdc91a/attachment.pgp
From jhb at freebsd.org  Thu Mar 19 10:55:06 2009
From: jhb at freebsd.org (John Baldwin)
Date: Thu Mar 19 10:55:15 2009
Subject: in recent 7-STABLE: VOP_WRITE...is not exclusive locked but
	should be
In-Reply-To: <20090319160251.GJ7716@deviant.kiev.zoral.com.ua>
References: <alpine.LFD.2.00.0903190639450.9228@cardinal>
	<200903191001.44491.jhb@freebsd.org>
	<20090319160251.GJ7716@deviant.kiev.zoral.com.ua>
Message-ID: <200903191246.05641.jhb@freebsd.org>

On Thursday 19 March 2009 12:02:51 pm Kostik Belousov wrote:
> On Thu, Mar 19, 2009 at 10:01:44AM -0400, John Baldwin wrote:
> > On Thursday 19 March 2009 8:05:34 am Tim Chase wrote:
> > > Hello,
> > > 
> > > I have a system that had been running quite well with an oldish 7-STABLE
> > > (from around August 7, 2008) but has started deadlocking within the past
> > > week or so.
> > > 
> > > I updated the kernel to a newer 7-STABLE (Mar 15, 2009) and enabled
> > > INVARIANTS, INVARIANT_SUPPORT, WITNESS, DEBUG_LOCKS DEBUG_VFS_LOCKS and
> > > DIAGNOSTIC and the message indicated in the subject line has now 
appeared
> > > 3 times as shown below.  Is this something to be terribly concerned 
about?
> > > Is there anything I can to to further track down the cause?  Since the
> > > system is a production mail server, I have it set to not drop into DDB
> > > when this happens.
> > > 
> > > The machine is a 4-core Xeon X5450 with 8G of RAM running FreeBSD
> > > amd64 and in userland it's pretty much just cyrus imapd and apache/php.
> > > The file systems are all ZFS on a bunch of SAS drives connected to a
> > > LSI Logic 1068 controller.
> > > 
> > > As to the deadlock that started this exercise, if the machine follows 
its
> > > recent pattern, that should happen within the next 2-4 hours.
> > 
> > Err, the vn_write() routine should be using an exclusive vnode lock:
> > 
> > vn_write()
> > {
> > 
> > 	...
> > 	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
> > 	if ((flags & FOF_OFFSET) == 0)
> > 		uio->uio_offset = fp->f_offset;
> > 	ioflag |= sequential_heuristic(uio, fp);
> > #ifdef MAC
> > 	error = mac_check_vnode_write(active_cred, fp->f_cred, vp);
> > 	if (error == 0)
> > #endif
> > 		error = VOP_WRITE(vp, uio, ioflag, fp->f_cred);
> > 	...
> > }
> > 
> > Can you check your /sys/kern/vfs_vnops.c and verify that LK_EXCLUSIVE is 
> > present in your vn_write() routine?  If so, then perhaps run memtest?
> 
> Note that this happens on the ZFS. Might be, ZFS unlocks the vnode and
> then relocks it with some invalid flags ?

Hmm, it depends on where the check is I guess (before or after zfs_write()).  
Tim, can you do 'l *VOP_WRITE_APV+0x155' on your kernel from gdb?

-- 
John Baldwin
From tim at chase2k.com  Thu Mar 19 12:15:54 2009
From: tim at chase2k.com (Tim Chase)
Date: Thu Mar 19 12:16:01 2009
Subject: in recent 7-STABLE: VOP_WRITE...is not exclusive locked but
 should be
In-Reply-To: <200903191246.05641.jhb@freebsd.org>
References: <alpine.LFD.2.00.0903190639450.9228@cardinal>
	<200903191001.44491.jhb@freebsd.org>
	<20090319160251.GJ7716@deviant.kiev.zoral.com.ua>
	<200903191246.05641.jhb@freebsd.org>
Message-ID: <alpine.LFD.2.00.0903191333410.11981@cardinal>

Hello,

Regarding:

>>>> As to the deadlock that started this exercise, if the machine follows
> its
>>>> recent pattern, that should happen within the next 2-4 hours.

FWIW, it did _not_ deadlock this morning and there haven't been any more of the 
"is exclusive locked" messages have come out, either.

John Baldwin asked:

> Hmm, it depends on where the check is I guess (before or after zfs_write()).
> Tim, can you do 'l *VOP_WRITE_APV+0x155' on your kernel from gdb?

(kgdb) l *VOP_WRITE_APV+0x155
0xffffffff8048f4b5 is in VOP_WRITE_APV (vnode_if.c:704).
699			ASSERT_VOP_ELOCKED(a->a_vp, "VOP_WRITE");
700		} else {
701			ASSERT_VI_UNLOCKED(a->a_vp, "VOP_WRITE");
702			ASSERT_VOP_ELOCKED(a->a_vp, "VOP_WRITE");
703		}
704		VOP_WRITE_POST(a, rc);
705		return (rc);
706	}
707 
708	struct vnodeop_desc vop_write_desc = {
(kgdb)

Line 704 would appear to be after the ZFS write which I guess means ZFS
is doing something it shouldn't be?

 	- Tim
From gcr+freebsd-stable at tharned.org  Thu Mar 19 13:01:43 2009
From: gcr+freebsd-stable at tharned.org (Greg Rivers)
Date: Thu Mar 19 13:01:56 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1237429357.1738.61.camel@balrog.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
	<1237429357.1738.61.camel@balrog.2hip.net>
Message-ID: <alpine.BSF.2.00.0903191419320.58165@roadkill.tharned.org>

On Wed, 18 Mar 2009, Robert Noland wrote:

> Ok, so it isn't the gart caching... Can you get me a pointer to a 
> screenshot?
>

fetch http://www.tharned.org/rv380-drm-issue.tbz
This archive contains various logs and system configuration files as well 
as screen shot images.  Look at the README file for a description of the 
images.


> What is garbled exactly?  Is the damage constrained to specific windows 
> or it it the entire framebuffer?
>

The entire frame buffer is garbled; switching to syscons and back seems to 
change the way it's garbled.  However, the interior of an xterm window is 
never garbled.  I'm running a dual-head configuration with the frame 
buffer spanning both monitors.

-- 
Greg Rivers
From rnoland at FreeBSD.org  Thu Mar 19 14:53:37 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Mar 19 14:53:49 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <alpine.BSF.2.00.0903191419320.58165@roadkill.tharned.org>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
	<1237429357.1738.61.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903191419320.58165@roadkill.tharned.org>
Message-ID: <1237499597.1732.329.camel@balrog.2hip.net>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090319/09fe202e/attachment.pgp
From pyunyh at gmail.com  Thu Mar 19 18:21:55 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Thu Mar 19 18:22:03 2009
Subject: 7.1-R to RELENG_7 upgrade breaks re nic
In-Reply-To: <20090309035613.GF5039@michelle.cdnetworks.co.kr>
References: <AE144701-409A-4D9F-9947-A725B0810ACA@STEVENWILLS.COM>
	<20090226003842.GB63173@michelle.cdnetworks.co.kr>
	<95AD32AC-93AE-4945-A18E-CE7099BEC3CA@stevenwills.com>
	<20090226041023.GD63173@michelle.cdnetworks.co.kr>
	<594BAC6A-498A-4B82-A18B-EB09FEA2F322@stevenwills.com>
	<20090226042732.GE63173@michelle.cdnetworks.co.kr>
	<22F5A82D-290D-4B84-92AB-670EDB49AF22@stevenwills.com>
	<20090303120734.GB84434@michelle.cdnetworks.co.kr>
	<26A74AAD-1556-4BA7-8E89-72BE36C667A7@stevenwills.com>
	<20090309035613.GF5039@michelle.cdnetworks.co.kr>
Message-ID: <20090320012223.GA50100@michelle.cdnetworks.co.kr>

On Mon, Mar 09, 2009 at 12:56:13PM +0900, Pyun YongHyeon wrote:
> On Sun, Mar 08, 2009 at 09:52:19PM -0400, Steve Wills wrote:
> > Hi,
> > 
> > Sorry for the late reply.
> > 
> > On Mar 3, 2009, at 7:07 AM, Pyun YongHyeon wrote:
> > >Ok, when you plug UTP cable can you see "re0: link state changed to
> > >UP" in dmesg output? Or if you unplug the cable, you should see
> > >"re0: link state changed to DOWN"(With "tail -f /var/log/message",
> > >you can easily check this.)
> > 
> > Nope.
> > 
> > >
> > >If this is not the case something is wrong on RTL8168D. Since
> > >you've said re0 works for a short time, can you see "re0: link
> > >state changed to DOWN" on your dmesg output right before seeing
> > >"re0: PHY read failed" message?
> > 
> > After boot and DHCP, it works for about a minute, then I see "PHY read  
> > failed" for a few seconds, network continues to work, then I see "link  
> > state changed to DOWN", network stops working and frequency of read  
> > failed message increases. Unplugging the cable and plugging it back in  
> > doesn't change anything or cause the system to log any messages beyond  
> > "PHY read failed".
> > 
> > >I've also attached patch which may apply to your case. Would you
> > >give it spin? Note, the patch was generated against CURRENT, so
> > >you should use re(4) in CURRENT. Just save your old re(4)/rl(4)
> > >files and download if_re.c, if_rl.c and if_rlreg.h from CURRENT
> > >and apply the patch.
> > ><re.RTL8168D.patch>
> > 
> > Unfortunately, for me, this patch doesn't change things.
> > 
> 
> Ok, please try again with attached patch.

Any progress here?
I've checked changes made in RELENG7 but I failed to see what
revision broke RTL8168D support. Can you narrow down which revision 
broke RTL8168D support if previous patch have no effect?

> Index: sys/dev/re/if_re.c
> ===================================================================
> --- sys/dev/re/if_re.c	(revision 189551)
> +++ sys/dev/re/if_re.c	(working copy)
> @@ -1266,6 +1266,8 @@
>  		/* FALLTHROUGH */
>  	case RL_HWREV_8168CP:
>  	case RL_HWREV_8168D:
> +		if (hw_rev->rl_rev == RL_HWREV_8168D)
> +			sc->rl_flags |= 0x10000;
>  		sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
>  		    RL_FLAG_DESCV2 | RL_FLAG_MACSTAT | RL_FLAG_CMDSTOP;
>  		/*
> @@ -2061,6 +2063,8 @@
>  
>  	RL_LOCK_ASSERT(sc);
>  
> +	if ((sc->rl_flags & 0x10000) != 0)
> +		re_miibus_writereg(sc->rl_dev, 1, 0x1f, 0);
>  	mii = device_get_softc(sc->rl_miibus);
>  	mii_tick(mii);
>  	if ((sc->rl_flags & RL_FLAG_LINK) == 0)

From gcr+freebsd-stable at tharned.org  Thu Mar 19 20:32:26 2009
From: gcr+freebsd-stable at tharned.org (Greg Rivers)
Date: Thu Mar 19 20:32:34 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <1237499597.1732.329.camel@balrog.2hip.net>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
	<1237429357.1738.61.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903191419320.58165@roadkill.tharned.org>
	<1237499597.1732.329.camel@balrog.2hip.net>
Message-ID: <alpine.BSF.2.00.0903192221540.1006@packrat.tharned.org>

On Thu, 19 Mar 2009, Robert Noland wrote:

> On Thu, 2009-03-19 at 15:01 -0500, Greg Rivers wrote:
>> On Wed, 18 Mar 2009, Robert Noland wrote:
>>
>>> Ok, so it isn't the gart caching... Can you get me a pointer to a
>>> screenshot?
>>>
>>
>> fetch http://www.tharned.org/rv380-drm-issue.tbz
>> This archive contains various logs and system configuration files as well
>> as screen shot images.  Look at the README file for a description of the
>> images.
>>
>>
>>> What is garbled exactly?  Is the damage constrained to specific windows
>>> or it it the entire framebuffer?
>>>
>>
>> The entire frame buffer is garbled; switching to syscons and back seems to
>> change the way it's garbled.  However, the interior of an xterm window is
>> never garbled.  I'm running a dual-head configuration with the frame
>> buffer spanning both monitors.
>
> Ok, I thought that I had already fixed this up, but I missed this
> spot...  Please try this patch.
>

It's still garbled with this patch too.  Any other ideas?  Just let me 
know when it's time for me to buy a different video card.  :-)

-- 
Greg Rivers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drm-ati_pcigart.patch
Type: text/x-patch
Size: 1446 bytes
Desc: 
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090320/2fe1b06f/drm-ati_pcigart.bin
From profiles at yahoo-inc.com  Thu Mar 19 21:28:56 2009
From: profiles at yahoo-inc.com (=?utf-8?b?RmFubnkgU2FudG9z?=)
Date: Thu Mar 19 21:29:02 2009
Subject: Fanny Santos wants to connect to you on Yahoo!
Message-ID: <20090320042855.B94158FC19@mx1.freebsd.org>

<html>
<body style="margin:0;padding:0;">
<table border="0" cellpadding="0" cellspacing="0" width="100%">
  <tr>
    <td style="background:#F1F1F1 url(http://us.i1.yimg.com/us.yimg.com/i/us/mash/gr/cnt-grd-1px.gif) 0 100% repeat-x;padding-left:3px;padding-top:6px;" valign="top" bgcolor="#F1F1F1" height="48">
      <img src="http://us.i1.yimg.com/us.yimg.com/i/us/nt/b/ma_01.gif" alt="Yahoo!" width="147" height="31">
    </td>
  </tr>
</table>
<div style="margin:0 0 30px 18px;">
<table border="0" cellpadding="0" cellspacing="0" width="600" style="margin-top:9px;">
  <tr>
    <td colspan="2">
       <div style="margin-bottom:13px;font-family:arial,verdana,helvetica;font-size:30px;">Let's connect on Yahoo!</div>
    </td>
  </tr>
  <tr>
    <td valign="top" style="padding-right:50px;">
       <div><a href="http://profiles.yahoo.com/accept/I.ejmTiYK8zY_ZoGndxQPwReiM.aLUDMi5lGA1ge5t34rjgoWwq1VlVgbJDV?q=0"><img src="http://us.i1.yimg.com/us.yimg.com/i/us/mash/gr/accept_button.png" border="0" alt="Accept Invitation" width="235" height="33"></a></div>
       <div style="margin:16px 0;line-height:1.11em;font-family:arial,verdana,helvetica;font-size:18px;">Connecting makes it easy to keep up with friends and family</div>
       <div style="margin-bottom:18px;font-family:arial,verdana,helvetica;font-size:14px;color:#333333;">&bull;&nbsp;You get automatically updated when I share stuff online - including my photos and reviews</div>
       <div style="margin-bottom:18px;font-family:arial,verdana,helvetica;font-size:14px;color:#333333;">&bull;&nbsp;You can see my profile on Yahoo!</div>
       <div style="margin-bottom:18px;font-family:arial,verdana,helvetica;font-size:14px;color:#333333;">&bull;&nbsp;You'll get earlier access to <a href="http://overview.mail.yahoo.com/whatsnew/smarterinbox">cool new Yahoo! Mail features</a></div>
       <div style="font-family:arial,verdana,helvetica;font-size:16px;">And much more coming soon!</div>
       <div style="font-family:arial,verdana,helvetica;font-size:16px;"><a href="http://profiles.yahoo.com/accept/I.ejmTiYK8zY_ZoGndxQPwReiM.aLUDMi5lGA1ge5t34rjgoWwq1VlVgbJDV?q=0">Click here to accept</a></div>
    </td>
    <td valign="top" style="background:url(http://us.i1.yimg.com/us.yimg.com/i/us/mash/gr/photo_bg.gif) -6px -2px no-repeat;padding:5px;">
       <a href="http://profiles.yahoo.com/u/DCEFZAFBVVJVJ5URVNPRIZ2W7Q"><img src="http://l.yimg.com/us.yimg.com/i/identity/nopic_192.gif" border="0" alt="" width="192" height="192"></a>
       <div style="margin-top:8px;font-family:arial,verdana,helvetica;font-size:18px;"><a href="http://profiles.yahoo.com/u/DCEFZAFBVVJVJ5URVNPRIZ2W7Q">Fanny Santos (FannyS)</a></div>
    </td>
  </tr>
</table>
</div>
<hr noshade size="1" color="#B5B5B5">
<div style="margin:-5px 0 0 23px;width:600px;" width="600">
   <div style="font-family:arial,verdana,helvetica;font-size:11px;color:#333333;">
      This invitation will expire after 90 days.
      <br>
      Want to control which emails you receive about your connections and your profile on Yahoo!?
      <br>
      Go to: <a href="http://profiles.yahoo.com/settings/notifications">http://profiles.yahoo.com/settings/notifications</a>
    </div>
</div>
</body>
</html>
From rnoland at FreeBSD.org  Thu Mar 19 21:28:59 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Thu Mar 19 21:29:13 2009
Subject: [HEADS UP] drm merged to -STABLE
In-Reply-To: <alpine.BSF.2.00.0903192221540.1006@packrat.tharned.org>
References: <1231599679.1837.13.camel@wombat.2hip.net>
	<alpine.BSF.2.00.0903171011540.30152@roadkill.tharned.org>
	<1237318671.1728.7.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903171801250.34773@roadkill.tharned.org>
	<1237395643.1738.3.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903181749330.47320@roadkill.tharned.org>
	<1237429357.1738.61.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903191419320.58165@roadkill.tharned.org>
	<1237499597.1732.329.camel@balrog.2hip.net>
	<alpine.BSF.2.00.0903192221540.1006@packrat.tharned.org>
Message-ID: <1237523319.1777.407.camel@balrog.2hip.net>

On Thu, 2009-03-19 at 22:32 -0500, Greg Rivers wrote:
> On Thu, 19 Mar 2009, Robert Noland wrote:
> 
> > On Thu, 2009-03-19 at 15:01 -0500, Greg Rivers wrote:
> >> On Wed, 18 Mar 2009, Robert Noland wrote:
> >>
> >>> Ok, so it isn't the gart caching... Can you get me a pointer to a
> >>> screenshot?
> >>>
> >>
> >> fetch http://www.tharned.org/rv380-drm-issue.tbz
> >> This archive contains various logs and system configuration files as well
> >> as screen shot images.  Look at the README file for a description of the
> >> images.
> >>
> >>
> >>> What is garbled exactly?  Is the damage constrained to specific windows
> >>> or it it the entire framebuffer?
> >>>
> >>
> >> The entire frame buffer is garbled; switching to syscons and back seems to
> >> change the way it's garbled.  However, the interior of an xterm window is
> >> never garbled.  I'm running a dual-head configuration with the frame
> >> buffer spanning both monitors.
> >
> > Ok, I thought that I had already fixed this up, but I missed this
> > spot...  Please try this patch.
> >
> 
> It's still garbled with this patch too.  Any other ideas?  Just let me 
> know when it's time for me to buy a different video card.  :-)

So, what I noticed today is that the difference between your ok and
garbled xorg.logs seems to be the ring pointer contents not being
empty...  I haven't really figured out why that is yet...

robert.

> -- 
> Greg Rivers
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090320/b655b8c8/attachment.pgp
From delphij at delphij.net  Thu Mar 19 21:32:46 2009
From: delphij at delphij.net (Xin LI)
Date: Thu Mar 19 21:32:55 2009
Subject: bce: unable to fix media
In-Reply-To: <20090304011019.GA87142@michelle.cdnetworks.co.kr>
References: <d8a4930a0903030202u5e965e3o9a630529de375f8d@mail.gmail.com>	<20090303123156.GC84434@michelle.cdnetworks.co.kr>	<d8a4930a0903030526m4807cc3hc0b5df2d41696ffc@mail.gmail.com>
	<20090304011019.GA87142@michelle.cdnetworks.co.kr>
Message-ID: <49C31C5F.9070402@delphij.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Pyun,

Pyun YongHyeon wrote:
> On Tue, Mar 03, 2009 at 02:26:11PM +0100, Cristiano Deana wrote:
>> 2009/3/3 Pyun YongHyeon <pyunyh@gmail.com>:
>>
>>>> # ifconfig bce0 media 1000baseSX
>>>> ifconfig: SIOCSIFMEDIA (media): Device not configured
>>> I don't have experience on bce(4) hardwares so I'm not sure but how
>>> about adding full-duplex?
>>> e.g. ifconfig bce0 media 1000baseSX mediaopt full-duplex
>> Thanks, that works. But put the card in "no carrier".
>> I will let in autoselect
>>
> 
> Yeah, that would be the reason why you always have to rely on
> auto-negotiation.

IIRC bce(4) has some problem when 1000baseSX not being auto-negotiated
so I believe that your analysis is right.

>>>> or (according to bce(4)):
>>>>
>>>> # ifconfig bce0 media 1000baseTX
>>>> ifconfig: SIOCSIFMEDIA (media): Device not configured
>>>>
>>> I guess your PHY type is not for 1000baseT. That's not valid option
>>> for your controller.
>> I think there is a typo o incomplete description in bce(4):
>>
>>      1000baseTX   Set 1000baseTX operation over twisted pair.  Only
>>                   full-duplex mode is supported.
>>
>> No entry for "1000baseSX".
> 
> bce(4) man page should reflect reality. I think the man page was
> written when there was no support for TBI. Things has changed since
> then(e.g BCM5709, 1000baseSX/2500baseSX support etc).
> Xin Li, would you take care of this?(CCed)

Yes.  I'll give this a shoot, thanks for pointing out!

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)

iEYEARECAAYFAknDHF8ACgkQi+vbBBjt66D6UQCbBoAJjHQIuUxs6Dzjz38Razqj
5EkAoKYQnzKsTtE6sdPPpi15+1XXwS0n
=bE5N
-----END PGP SIGNATURE-----
From eugen at kuzbass.ru  Thu Mar 19 23:35:43 2009
From: eugen at kuzbass.ru (Eugene Grosbein)
Date: Thu Mar 19 23:35:50 2009
Subject: sysctl lock in RELENG_6
References: <498FAA2A.7423AC15@kuzbass.ru>
	<20090209214822.GH9427@deviant.kiev.zoral.com.ua>
	<20090210040125.GA80054@svzserv.kemerovo.su>
	<20090210062757.GK9427@deviant.kiev.zoral.com.ua>
Message-ID: <49C339AE.E4254A0C@kuzbass.ru>

Kostik Belousov wrote:
> 
> On Tue, Feb 10, 2009 at 11:01:25AM +0700, Eugene Grosbein wrote:
> > On Mon, Feb 09, 2009 at 11:48:22PM +0200, Kostik Belousov wrote:
> >
> > > > I've digged commit logs a bit and found this change MFC'd to RELENG_7
> > > > but not RELENG_6:
> > > >
> > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_sysctl.c#rev1.177.6.2
> > > >
> > > > It seems RELENG_6 needs this too, doesn't it?
> > > > I'm going to merge the change to RELENG_6 and give it a try.
> > >
> > > Yes, please give it a try. In fact, it was quite specific situation
> > > that I observed and produced a fix for. You need execing process that
> > > needs to grab Giant, e.g. due to image being located on !MPSAFE fs, and
> > > simultaneous sysctl issued that inspects this process.
> >
> > Well, my 6.3-STABLE locked very often (sometimes every hour).
> > Yesterday I've upgraded it to 6.4-STABLE, applied 1.177.2.1 of the file
> > to sources, rebuilt NanoBSD image and ran it. It has not locked yet.
> Can you be slightly more scientific in your tests ?
> Try RELENG_6 without my patch to see whether it is needed at all.

Well, there was pretty long testing period (over a month) and I conclude:

1. 6.4-STABLE without your patch hangs.
2. 6.4-STABLE with your patch does not.

Eugene Grosbein
From ltning at anduin.net  Fri Mar 20 03:36:23 2009
From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=)
Date: Fri Mar 20 03:36:30 2009
Subject: ugen and Gemplus SC reader
Message-ID: <722EA5AE-82F1-4ED0-9F45-9951BF41AE4F@anduin.net>

Hi,

whenever I try to use openct/opensc to use my gemplus USB smartcard  
readers, I get the following in dmesg:

ugenioctl: USB_SET_SHORT_XFER, no pipe

The readers work fine on MacOS X and (reportedly) Linux, and the  
driver included in openct should support it. I can't find any PC/SC  
driver bundles for it though, only the serial readers.

Is this a problem in ugen?

With best regards,
/Eirik
From stefan.lambrev at moneybookers.com  Fri Mar 20 09:57:08 2009
From: stefan.lambrev at moneybookers.com (Stefan Lambrev)
Date: Fri Mar 20 09:57:14 2009
Subject: gemor mirror and priority
Message-ID: <0E486099-ED60-43E6-A86E-75B2CBC1DC00@moneybookers.com>

Greetings,

Is this still correct:

Note that you want to insert the remote disk into the mirror first.  
The disk in the mirror with the highest priority gets used first if  
you set the balance algorithm to 'prefer'--it seems like a good idea  
to make sure that's the local disk... The first item inserted in the  
mirror automatically gets a priority of 0. There is a documented  
limitation of gmirror--you can't change the priority of a component  
after it's added. If you add the local disk first and the filesystem  
is live (being changed), you'll need to do a full sync, then remove  
the local disk, and then add the local disk back with a higher  
priority and complete another full sync--which can take some time over  
the network.

Or in other words - priority=0 means lowest or highest priority for  
reading from geom mirror?

--
Best Wishes,
Stefan Lambrev
ICQ# 24134177





From petefrench at ticketswitch.com  Fri Mar 20 10:00:24 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri Mar 20 10:00:31 2009
Subject: gemor mirror and priority
In-Reply-To: <0E486099-ED60-43E6-A86E-75B2CBC1DC00@moneybookers.com>
Message-ID: <E1Lki4u-000BHk-Fw@dilbert.ticketswitch.com>

> Is this still correct:

Yup - I made a patch to start the priorities in the middle of the
range and to add a 'prefer-low' to reverse the way it is selected
to get round the problem though. You can try it out if you want...

-pete.
From stefan.lambrev at moneybookers.com  Fri Mar 20 10:06:34 2009
From: stefan.lambrev at moneybookers.com (Stefan Lambrev)
Date: Fri Mar 20 10:06:41 2009
Subject: gemor mirror and priority
In-Reply-To: <E1Lki4u-000BHk-Fw@dilbert.ticketswitch.com>
References: <E1Lki4u-000BHk-Fw@dilbert.ticketswitch.com>
Message-ID: <21FD4FB4-7BD8-4FDD-878F-7D7F2158AD4B@moneybookers.com>


On Mar 20, 2009, at 7:00 PM, Pete French wrote:

>> Is this still correct:
>
> Yup - I made a patch to start the priorities in the middle of the
> range and to add a 'prefer-low' to reverse the way it is selected
> to get round the problem though. You can try it out if you want...
>
> -pete.

If it can apply to 7-stable or 7.1-release I'll be even grateful to  
have it ;)

--
Best Wishes,
Stefan Lambrev
ICQ# 24134177





From petefrench at ticketswitch.com  Fri Mar 20 10:11:38 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri Mar 20 10:11:44 2009
Subject: gemor mirror and priority
In-Reply-To: <21FD4FB4-7BD8-4FDD-878F-7D7F2158AD4B@moneybookers.com>
Message-ID: <E1LkiFn-000BJv-3s@dilbert.ticketswitch.com>

> If it can apply to 7-stable or 7.1-release I'll be even grateful to  
> have it ;)

Find it here: http://www.freebsd.org/cgi/query-pr.cgi?pr=123630

That was relative to 7.0 - I havent tried it on 7.1. I was hopinh
that the changes would be incorporated, but pjd didn't like the solution
and said he would prefer it if someone extended the configure sub-command to
change disc priorities in an existing config. I didn't have time to do
do that thought (and I dont like that as a solution, as it means changing
the array priorities rather than having fixed ones and changing which is
used - I think we should have both).

One day, when I get some time, I will have another look at it.

-pete.
From stefan.lambrev at moneybookers.com  Fri Mar 20 10:24:43 2009
From: stefan.lambrev at moneybookers.com (Stefan Lambrev)
Date: Fri Mar 20 10:24:50 2009
Subject: gemor mirror and priority
In-Reply-To: <E1LkiFn-000BJv-3s@dilbert.ticketswitch.com>
References: <E1LkiFn-000BJv-3s@dilbert.ticketswitch.com>
Message-ID: <B1A41ABF-538C-49F3-A10C-F1E60D56467E@moneybookers.com>

Thanks for the patch.

I'll try it and report after the weekend :)

On Mar 20, 2009, at 7:11 PM, Pete French wrote:

>> If it can apply to 7-stable or 7.1-release I'll be even grateful to
>> have it ;)
>
> Find it here: http://www.freebsd.org/cgi/query-pr.cgi?pr=123630
>
> That was relative to 7.0 - I havent tried it on 7.1. I was hopinh
> that the changes would be incorporated, but pjd didn't like the  
> solution
> and said he would prefer it if someone extended the configure sub- 
> command to
> change disc priorities in an existing config. I didn't have time to do
> do that thought (and I dont like that as a solution, as it means  
> changing
> the array priorities rather than having fixed ones and changing  
> which is
> used - I think we should have both).
>
> One day, when I get some time, I will have another look at it.
>
> -pete.

--
Best Wishes,
Stefan Lambrev
ICQ# 24134177





From petefrench at ticketswitch.com  Fri Mar 20 10:39:15 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Fri Mar 20 10:39:22 2009
Subject: gemor mirror and priority
In-Reply-To: <B1A41ABF-538C-49F3-A10C-F1E60D56467E@moneybookers.com>
Message-ID: <E1Lkigc-000BOY-HL@dilbert.ticketswitch.com>

> I'll try it and report after the weekend :)

It should be OK - we ran it here on the main database server until
a couple of months ago, which I went back to using vanilla 7.1 in an attempt to
try and track down a bug. I will probably continue to use the patch in
future though - it's very stable, and very useful if you haave some
kind of "homemade clustering" solution with a local and remote drive.

-pete.
From lambert at lambertfam.org  Fri Mar 20 13:09:12 2009
From: lambert at lambertfam.org (Scott Lambert)
Date: Fri Mar 20 13:09:19 2009
Subject: Is some combination of gmirror, md file systems, snapshots and,
	maybe, quotas considered harmful?
Message-ID: <20090320194157.GB80292@sysmon.tcworks.net>

I have a previously stable machine, other than a one time panic in
soft-updates which I could never reproduce, running RELENG_7 from July
23, 2008.

Starting update: Wed Jul 23 01:29:47 CDT 2008
Finished update: Wed Jul 23 01:31:13 CDT 2008

I had the userquota option in the fstab for /home, but I did not yet
have anything in /etc/rc.conf to enable them.  I have been running an
unmodified GENERIC kernel config.

/dev/mirror/gm0s1g on /home (ufs, local, soft-updates)

It runs a few jails, using ezjails.  Two of them were image based jails,
1GB and 2GB.  There is also one non-image file jail.  The jails live in
/home/ezjails.

I added another image based jail, 3GB image, on March 12th.

I added this machine to our AMANDA setup on March 13, 2009.  

Things seemed to be okay until the 19th.  On the 19th, during the dump
of /home, things gradually started to hang.  Nagios paged me about
services not responding.  

I did not find any explanation for it.  The disks were idle according to
systat -vm.  I was able to grep the log files on /var for a while, and
then I could no longer do anything with it.

I eventually had to go to the office and power cycle it.  I tried C-A-D
first, but shutdown timed out after 30 seconds.

Just to make sure it wasn't something that had since been fixed, I
updated to RELENG_7 as of Mar 19th.

Starting update: Thu Mar 19 03:40:41 CDT 2009
Finished update: Thu Mar 19 03:48:45 CDT 2009

I rebooted to the new kernel and installed the world just after midnight
on the 20th.  I started getting paged by Nagios again at 3:40am.  

I noticed that mksnap_ffs was running on /home, cpu time used: 0:00.77,
as things began to circle the drain.  That was about 30 minutes after
the dump attempt had been started by AMANDA.  There were many processes
waiting in state D.  This time I did a reboot -n -q and the box rebooted
but was still fscking when I got to the office.

# ls -l /home/.snap
-r--------   1 root  operator  117285093376 Mar 20 03:18 dump_snapshot

# df /home
Filesystem            Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0s1g    106G     11G     86G    11%    /home

I removed userquota from the fstab entry for /home and rebooted, just
to be sure.  The last danger combination I remember for snapshots was
in combination with quotas.  Am I even in the danger zone for quotas
without having them compiled into the kernel?

It looks like removing the .snap directory should be enough to prevent
any future snapshots during the backup process.  Does that sound like a
reasonable workaround?  It would at least remove one variable from the
trouble shooting process.

Any other suggestions?

Thank you for any help you may be able to provide,

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert@lambertfam.org

From rwatson at FreeBSD.org  Sat Mar 21 04:49:31 2009
From: rwatson at FreeBSD.org (Robert Watson)
Date: Sat Mar 21 04:49:38 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <20090318124806.K55869@ns1.as.pvp.se>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
	<20090318124806.K55869@ns1.as.pvp.se>
Message-ID: <alpine.BSF.2.00.0903211148430.99520@fledge.watson.org>


On Wed, 18 Mar 2009, kama wrote:

> What I meant was the todo page on www.freebsd.org.
>
> Like: http://www.freebsd.org/releases/7.2R/TODO.html
>
> Where problems and showstoppers where brought up. I found that information 
> very valueble. Especially when the release went overdue I could easily see 
> what caused the delay.
>
> The last release I did not really get information about why the release was 
> delayed. At least not as easily as reloading a webpage.

We do plan to create such a page, but are currently finding things to populate 
it with since we're early in the release process yet.  We'll send out an 
e-mail once it's up.

Robert N M Watson
Computer Laboratory
University of Cambridge
From tom.hurst at clara.net  Sat Mar 21 09:43:17 2009
From: tom.hurst at clara.net (Thomas Hurst)
Date: Sat Mar 21 09:43:24 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
Message-ID: <20090321160150.GA12802@voi.aagh.net>

* Robert Watson (rwatson@FreeBSD.org) wrote:

> It would probably be worth skimming svn logs for stable/7 to see what
> other testing focuses would be particularly useful.

In case it's of use, I have full searchable SVN history here:

  http://beta.freshbsd.org/?q=branch:RELENG_7

-- 
Thomas 'Freaky' Hurst
    http://hur.st/
From cliftonr at lava.net  Sat Mar 21 11:44:45 2009
From: cliftonr at lava.net (Clifton Royston)
Date: Sat Mar 21 11:44:53 2009
Subject: gemor mirror and priority
In-Reply-To: <E1Lkigc-000BOY-HL@dilbert.ticketswitch.com>
References: <B1A41ABF-538C-49F3-A10C-F1E60D56467E@moneybookers.com>
	<E1Lkigc-000BOY-HL@dilbert.ticketswitch.com>
Message-ID: <20090321184440.GA29399@lava.net>

On Fri, Mar 20, 2009 at 05:39:14PM +0000, Pete French wrote:
> > I'll try it and report after the weekend :)
> 
> It should be OK - we ran it here on the main database server until
> a couple of months ago, which I went back to using vanilla 7.1 in an attempt to
> try and track down a bug. I will probably continue to use the patch in
> future though - it's very stable, and very useful if you haave some
> kind of "homemade clustering" solution with a local and remote drive.

  Even if you don't, I think it's quite useful to make the *default*
priority set when creating a mirror be some value which allows both
higher and lower values to be specified.  I hadn't known about that
issue until I read the original thread here a while back.If the default
were set to some mid-range value, or even to 2, for example, then at
least creating a new mirror and adding drives without setting a
priority would continue to behave as usual, while it would be possible
to explicitly insert new components with a lower priority.  (I see why
one wouldn't want to change the default interpretation of existing
priority values for POLA reasons.)

  There are lots of reasons one could want to control priorities of
mirrored drives in various ways.  One is to use gmirror as a long-term
backup approach: mirror with three drives, periodically disconnecting
one from the mirror to swap it with a fresh drive from a pool of backup
drives.  I haven't tried this, but it's been on my mind to mess around
with soon.

  In this case, I would want the designated backup drive to always be
lowest-priority, to ensure the mirror never accidentally started
rebuilding from a newly reinserted backup.  (This probably wouldn't
happen anyway, but it would be nice to be sure...)
 
  -- Clifton

-- 
    Clifton Royston  --  cliftonr@iandicomputing.com / cliftonr@lava.net
       President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services
From petefrench at ticketswitch.com  Sat Mar 21 12:55:29 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sat Mar 21 12:55:36 2009
Subject: KDB+DDB make interrupt storm on MSI motherboards go away it seems
Message-ID: <E1Ll7Hp-000Kqr-1P@dilbert.ticketswitch.com>

I admit I was scepticle of this suggestion - but it actually seems to
have worked. COmpiling a straight GENERIC kernel with KDB and DDB
included do seem to have made my irq22 interrupt storms go away.
Certainly I have spent some time trying to provoke the problem and not
managed to make it read it's ugly head again.

The thing is though, this doen't make me particularly happy - as I am
sure that KDB and DDB are not supposed to make any major changes to
how the kernel functions are they ?

-pete.
From ari at ish.com.au  Sat Mar 21 15:33:04 2009
From: ari at ish.com.au (Aristedes Maniatis)
Date: Sat Mar 21 15:33:19 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <alpine.BSF.2.00.0903211148430.99520@fledge.watson.org>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
	<20090318124806.K55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903211148430.99520@fledge.watson.org>
Message-ID: <BDE0D8E8-ED58-46B1-BC09-8DF6AB5B1B39@ish.com.au>


On 21/03/2009, at 10:49 PM, Robert Watson wrote:

>
> On Wed, 18 Mar 2009, kama wrote:
>
>> What I meant was the todo page on www.freebsd.org.
>>
>> Like: http://www.freebsd.org/releases/7.2R/TODO.html
>>
>> Where problems and showstoppers where brought up. I found that  
>> information very valueble. Especially when the release went overdue  
>> I could easily see what caused the delay.
>>
>> The last release I did not really get information about why the  
>> release was delayed. At least not as easily as reloading a webpage.
>
> We do plan to create such a page, but are currently finding things  
> to populate it with since we're early in the release process yet.   
> We'll send out an e-mail once it's up.


Is there any way to automatically create such a page from the bug  
tracker?

Ari Maniatis


-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A


From linimon at lonesome.com  Sat Mar 21 19:09:15 2009
From: linimon at lonesome.com (Mark Linimon)
Date: Sat Mar 21 19:09:23 2009
Subject: FreeBSD 7.2 Release process starting...
In-Reply-To: <BDE0D8E8-ED58-46B1-BC09-8DF6AB5B1B39@ish.com.au>
References: <1237299551.80881.16.camel@bauer.cse.buffalo.edu>
	<20090318102134.D55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903181134380.99720@fledge.watson.org>
	<20090318124806.K55869@ns1.as.pvp.se>
	<alpine.BSF.2.00.0903211148430.99520@fledge.watson.org>
	<BDE0D8E8-ED58-46B1-BC09-8DF6AB5B1B39@ish.com.au>
Message-ID: <20090322015050.GC2990@lonesome.com>

On Sun, Mar 22, 2009 at 09:18:03AM +1100, Aristedes Maniatis wrote:
> Is there any way to automatically create such a page from the bug  
> tracker?

Not that fills in the dates, no.  We are working on a prototype to
track particular PRs.

mcl
From uspoerlein at gmail.com  Sun Mar 22 02:07:50 2009
From: uspoerlein at gmail.com (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Sun Mar 22 02:07:58 2009
Subject: gemor mirror and priority
In-Reply-To: <20090321184440.GA29399@lava.net>
References: <B1A41ABF-538C-49F3-A10C-F1E60D56467E@moneybookers.com>
	<E1Lkigc-000BOY-HL@dilbert.ticketswitch.com>
	<20090321184440.GA29399@lava.net>
Message-ID: <20090322090740.GA1519@roadrunner.spoerlein.net>

On Sat, 21.03.2009 at 08:44:42 -1000, Clifton Royston wrote:
>   Even if you don't, I think it's quite useful to make the *default*
> priority set when creating a mirror be some value which allows both
> higher and lower values to be specified.  I hadn't known about that
> issue until I read the original thread here a while back.If the default
> were set to some mid-range value, or even to 2, for example, then at
> least creating a new mirror and adding drives without setting a
> priority would continue to behave as usual, while it would be possible
> to explicitly insert new components with a lower priority.  (I see why
> one wouldn't want to change the default interpretation of existing
> priority values for POLA reasons.)
> 
>   There are lots of reasons one could want to control priorities of
> mirrored drives in various ways.  One is to use gmirror as a long-term
> backup approach: mirror with three drives, periodically disconnecting
> one from the mirror to swap it with a fresh drive from a pool of backup
> drives.  I haven't tried this, but it's been on my mind to mess around
> with soon.

I did this for 2-3 years and it has worked very well. Of course I took
care of using the right priorities from the start. This setup has now
been replaced by a ZFS mirror. The resilver time is just so much better :)

>   In this case, I would want the designated backup drive to always be
> lowest-priority, to ensure the mirror never accidentally started
> rebuilding from a newly reinserted backup.  (This probably wouldn't
> happen anyway, but it would be nice to be sure...)

This will not happen. Besides, I would strongly encourage you to disable
automatic rebuilding for this type of setup.

Cheers,
Ulrich Sp?rlein
-- 
None are more hopelessly enslaved than those who falsely believe they are free
-- Johann Wolfgang von Goethe
From lambert at lambertfam.org  Sun Mar 22 02:31:57 2009
From: lambert at lambertfam.org (Scott Lambert)
Date: Sun Mar 22 02:32:05 2009
Subject: Is some combination of gmirror, md file systems, snapshots and,
	maybe, quotas considered harmful?
In-Reply-To: <20090320194157.GB80292@sysmon.tcworks.net>
References: <20090320194157.GB80292@sysmon.tcworks.net>
Message-ID: <20090322093156.GE80292@sysmon.tcworks.net>

On Fri, Mar 20, 2009 at 02:41:57PM -0500, Scott Lambert wrote:
> I have a previously stable machine, other than a one time panic in
> soft-updates which I could never reproduce, running RELENG_7 from July
> 23, 2008.
> 
> Starting update: Wed Jul 23 01:29:47 CDT 2008
> Finished update: Wed Jul 23 01:31:13 CDT 2008
> 
> I had the userquota option in the fstab for /home, but I did not yet
> have anything in /etc/rc.conf to enable them.  I have been running an
> unmodified GENERIC kernel config.
> 
> /dev/mirror/gm0s1g on /home (ufs, local, soft-updates)
> 
> It runs a few jails, using ezjails.  Two of them were image based jails,
> 1GB and 2GB.  There is also one non-image file jail.  The jails live in
> /home/ezjails.
> 
> I added another image based jail, 3GB image, on March 12th.
> 
> I added this machine to our AMANDA setup on March 13, 2009.  
> 
> Things seemed to be okay until the 19th.  On the 19th, during the dump
> of /home, things gradually started to hang.  Nagios paged me about
> services not responding.  
> 
> I did not find any explanation for it.  The disks were idle according to
> systat -vm.  I was able to grep the log files on /var for a while, and
> then I could no longer do anything with it.
> 
> I eventually had to go to the office and power cycle it.  I tried C-A-D
> first, but shutdown timed out after 30 seconds.
> 
> Just to make sure it wasn't something that had since been fixed, I
> updated to RELENG_7 as of Mar 19th.
> 
> Starting update: Thu Mar 19 03:40:41 CDT 2009
> Finished update: Thu Mar 19 03:48:45 CDT 2009
> 
> I rebooted to the new kernel and installed the world just after midnight
> on the 20th.  I started getting paged by Nagios again at 3:40am.  
> 
> I noticed that mksnap_ffs was running on /home, cpu time used: 0:00.77,
> as things began to circle the drain.  That was about 30 minutes after
> the dump attempt had been started by AMANDA.  There were many processes
> waiting in state D.  This time I did a reboot -n -q and the box rebooted
> but was still fscking when I got to the office.
> 
> # ls -l /home/.snap
> -r--------   1 root  operator  117285093376 Mar 20 03:18 dump_snapshot
> 
> # df /home
> Filesystem            Size    Used   Avail Capacity  Mounted on
> /dev/mirror/gm0s1g    106G     11G     86G    11%    /home
> 
> I removed userquota from the fstab entry for /home and rebooted, just
> to be sure.  The last danger combination I remember for snapshots was
> in combination with quotas.  Am I even in the danger zone for quotas
> without having them compiled into the kernel?
> 
> It looks like removing the .snap directory should be enough to prevent
> any future snapshots during the backup process.  Does that sound like a
> reasonable workaround?  It would at least remove one variable from the
> trouble shooting process.
> 
> Any other suggestions?
> 
> Thank you for any help you may be able to provide,

Did it to me again tonight.  I was unable to get in to look at anything.
Just pushed the power button.  It did give me the same "shutdown timed
out after 30 seconds."

So, I tuned the /home fs to disable softupdates.  I also removed the
.snap directory.

I would appreciate any suggestions...
 
-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert@lambertfam.org

From danny at cs.huji.ac.il  Sun Mar 22 03:55:04 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sun Mar 22 03:55:12 2009
Subject: 7.2-PRERELEASE/sunx2200/bge/msi broken
Message-ID: <E1LlLKY-0007bm-8B@kabab.cs.huji.ac.il>

Hi,
	between March 16 and now, bge on a Sun X2200 stopped working,
turning off msi (via hw..pci.enable_msi=0) got it working again.
I tried first replacing bge with an older version but that did not help.

please advice :-)

Danny

From amarat at ksu.ru  Sun Mar 22 04:38:23 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Sun Mar 22 04:38:30 2009
Subject: KDB+DDB make interrupt storm on MSI motherboards go away it
	seems
In-Reply-To: <E1Ll7Hp-000Kqr-1P@dilbert.ticketswitch.com>
References: <E1Ll7Hp-000Kqr-1P@dilbert.ticketswitch.com>
Message-ID: <49C622F7.2030503@ksu.ru>

Pete French wrote:
> I admit I was scepticle of this suggestion - but it actually seems to
> have worked. COmpiling a straight GENERIC kernel with KDB and DDB
> included do seem to have made my irq22 interrupt storms go away.
> Certainly I have spent some time trying to provoke the problem and not
> managed to make it read it's ugly head again.
> 
> The thing is though, this doen't make me particularly happy - as I am
> sure that KDB and DDB are not supposed to make any major changes to
> how the kernel functions are they ?
> 
> -pete.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
no major changes, indeed, but a couple of small changes, e.g. implicit 
turning off all optimizations.

-- 
SY, Marat
From to.my.trociny at gmail.com  Sun Mar 22 06:10:12 2009
From: to.my.trociny at gmail.com (Mikolaj Golub)
Date: Sun Mar 22 06:10:58 2009
Subject: 7.2-PRERELEASE/sunx2200/bge/msi broken
In-Reply-To: <E1LlLKY-0007bm-8B@kabab.cs.huji.ac.il> (Danny Braniss's message
	of "Sun\, 22 Mar 2009 12\:55\:02 +0200")
References: <E1LlLKY-0007bm-8B@kabab.cs.huji.ac.il>
Message-ID: <868wmx3dqo.fsf@kopusha.onet>


On Sun, 22 Mar 2009 12:55:02 +0200 Danny Braniss wrote:

 DB> Hi,
 DB>         between March 16 and now, bge on a Sun X2200 stopped working,
 DB> turning off msi (via hw..pci.enable_msi=0) got it working again.
 DB> I tried first replacing bge with an older version but that did not help.

It looks like related to this report:

http://www.freebsd.org/cgi/getmsg.cgi?fetch=1253844+1263253+/usr/local/www/db/text/2009/freebsd-bugs/20090322.freebsd-bugs

-- 
Mikolaj Golub
From marius at alchemy.franken.de  Sun Mar 22 07:31:24 2009
From: marius at alchemy.franken.de (Marius Strobl)
Date: Sun Mar 22 07:31:32 2009
Subject: 7.2-PRERELEASE/sunx2200/bge/msi broken
In-Reply-To: <868wmx3dqo.fsf@kopusha.onet>
References: <E1LlLKY-0007bm-8B@kabab.cs.huji.ac.il>
	<868wmx3dqo.fsf@kopusha.onet>
Message-ID: <20090322135643.GA18284@alchemy.franken.de>

On Sun, Mar 22, 2009 at 03:10:07PM +0200, Mikolaj Golub wrote:
> 
> On Sun, 22 Mar 2009 12:55:02 +0200 Danny Braniss wrote:
> 
>  DB> Hi,
>  DB>         between March 16 and now, bge on a Sun X2200 stopped working,
>  DB> turning off msi (via hw..pci.enable_msi=0) got it working again.
>  DB> I tried first replacing bge with an older version but that did not help.
> 
> It looks like related to this report:
> 
> http://www.freebsd.org/cgi/getmsg.cgi?fetch=1253844+1263253+/usr/local/www/db/text/2009/freebsd-bugs/20090322.freebsd-bugs
> 

Could you please give the following patch a try?
http://people.freebsd.org/~marius/bge_intx.diff

Marius

From petefrench at ticketswitch.com  Sun Mar 22 07:58:03 2009
From: petefrench at ticketswitch.com (Pete French)
Date: Sun Mar 22 07:58:10 2009
Subject: gemor mirror and priority
In-Reply-To: <20090322090740.GA1519@roadrunner.spoerlein.net>
Message-ID: <E1LlP7b-000OqQ-CW@dilbert.ticketswitch.com>

> I did this for 2-3 years and it has worked very well. Of course I took
> care of using the right priorities from the start. This setup has now
> been replaced by a ZFS mirror. The resilver time is just so much better :)

How do you find ZFS performance in an asymetric mirror, and does it
seem to cope OK if the remote disc fails ? One of the reaons I have stuck
with gmirror is that it seems extremely tolerant to having one of the
drives vanish from underneath it (as sometimes happens with a remote disc).
When I experimented doing this with ZFS I found that it did not work well
at all (lock ups until the disc I had taken away came back).

-pete.
From danny at cs.huji.ac.il  Sun Mar 22 08:40:24 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Sun Mar 22 08:40:33 2009
Subject: 7.2-PRERELEASE/sunx2200/bge/msi broken 
In-Reply-To: <20090322135643.GA18284@alchemy.franken.de> 
References: <E1LlLKY-0007bm-8B@kabab.cs.huji.ac.il> 
	<868wmx3dqo.fsf@kopusha.onet>
	<20090322135643.GA18284@alchemy.franken.de>
Message-ID: <E1LlPmf-000BKs-Dn@kabab.cs.huji.ac.il>

> On Sun, Mar 22, 2009 at 03:10:07PM +0200, Mikolaj Golub wrote:
> > 
> > On Sun, 22 Mar 2009 12:55:02 +0200 Danny Braniss wrote:
> > 
> >  DB> Hi,
> >  DB>         between March 16 and now, bge on a Sun X2200 stopped working,
> >  DB> turning off msi (via hw..pci.enable_msi=0) got it working again.
> >  DB> I tried first replacing bge with an older version but that did not help.
> > 
> > It looks like related to this report:
> > 
> > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1253844+1263253+/usr/local/www/db/text/2009/freebsd-bugs/20090322.freebsd-bugs
> > 
> 
> Could you please give the following patch a try?
> http://people.freebsd.org/~marius/bge_intx.diff
> 
> Marius
> 
it works!
thanks,
	danny


From kris at FreeBSD.org  Sun Mar 22 11:03:55 2009
From: kris at FreeBSD.org (Kris Kennaway)
Date: Sun Mar 22 11:04:04 2009
Subject: Is some combination of gmirror, md file systems, snapshots and, 
 maybe, quotas considered harmful?
In-Reply-To: <20090322093156.GE80292@sysmon.tcworks.net>
References: <20090320194157.GB80292@sysmon.tcworks.net>
	<20090322093156.GE80292@sysmon.tcworks.net>
Message-ID: <49C67D8A.5070505@FreeBSD.org>

Scott Lambert wrote:
> On Fri, Mar 20, 2009 at 02:41:57PM -0500, Scott Lambert wrote:
>> I have a previously stable machine, other than a one time panic in
>> soft-updates which I could never reproduce, running RELENG_7 from July
>> 23, 2008.
>>
>> Starting update: Wed Jul 23 01:29:47 CDT 2008
>> Finished update: Wed Jul 23 01:31:13 CDT 2008
>>
>> I had the userquota option in the fstab for /home, but I did not yet
>> have anything in /etc/rc.conf to enable them.  I have been running an
>> unmodified GENERIC kernel config.
>>
>> /dev/mirror/gm0s1g on /home (ufs, local, soft-updates)
>>
>> It runs a few jails, using ezjails.  Two of them were image based jails,
>> 1GB and 2GB.  There is also one non-image file jail.  The jails live in
>> /home/ezjails.
>>
>> I added another image based jail, 3GB image, on March 12th.
>>
>> I added this machine to our AMANDA setup on March 13, 2009.  
>>
>> Things seemed to be okay until the 19th.  On the 19th, during the dump
>> of /home, things gradually started to hang.  Nagios paged me about
>> services not responding.  
>>
>> I did not find any explanation for it.  The disks were idle according to
>> systat -vm.  I was able to grep the log files on /var for a while, and
>> then I could no longer do anything with it.
>>
>> I eventually had to go to the office and power cycle it.  I tried C-A-D
>> first, but shutdown timed out after 30 seconds.
>>
>> Just to make sure it wasn't something that had since been fixed, I
>> updated to RELENG_7 as of Mar 19th.
>>
>> Starting update: Thu Mar 19 03:40:41 CDT 2009
>> Finished update: Thu Mar 19 03:48:45 CDT 2009
>>
>> I rebooted to the new kernel and installed the world just after midnight
>> on the 20th.  I started getting paged by Nagios again at 3:40am.  
>>
>> I noticed that mksnap_ffs was running on /home, cpu time used: 0:00.77,
>> as things began to circle the drain.  That was about 30 minutes after
>> the dump attempt had been started by AMANDA.  There were many processes
>> waiting in state D.  This time I did a reboot -n -q and the box rebooted
>> but was still fscking when I got to the office.
>>
>> # ls -l /home/.snap
>> -r--------   1 root  operator  117285093376 Mar 20 03:18 dump_snapshot
>>
>> # df /home
>> Filesystem            Size    Used   Avail Capacity  Mounted on
>> /dev/mirror/gm0s1g    106G     11G     86G    11%    /home
>>
>> I removed userquota from the fstab entry for /home and rebooted, just
>> to be sure.  The last danger combination I remember for snapshots was
>> in combination with quotas.  Am I even in the danger zone for quotas
>> without having them compiled into the kernel?
>>
>> It looks like removing the .snap directory should be enough to prevent
>> any future snapshots during the backup process.  Does that sound like a
>> reasonable workaround?  It would at least remove one variable from the
>> trouble shooting process.
>>
>> Any other suggestions?
>>
>> Thank you for any help you may be able to provide,
> 
> Did it to me again tonight.  I was unable to get in to look at anything.
> Just pushed the power button.  It did give me the same "shutdown timed
> out after 30 seconds."
> 
> So, I tuned the /home fs to disable softupdates.  I also removed the
> .snap directory.
> 
> I would appreciate any suggestions...
>  

http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html

Kris
From barbara.xxx1975 at libero.it  Sun Mar 22 12:42:04 2009
From: barbara.xxx1975 at libero.it (barbara)
Date: Sun Mar 22 12:42:12 2009
Subject: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
Message-ID: <KGXA5X$0EC1E19669F729D4A18D2E54F1F3BEED@libero.it>


Any news about that?

http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047527.html


From ns at got2get.net  Sun Mar 22 15:23:22 2009
From: ns at got2get.net (Nicolais)
Date: Sun Mar 22 15:23:29 2009
Subject: Crazy "interrupt storm detected" on atapci0
In-Reply-To: <49BFD57C.5010301@ksu.ru>
References: <a0deb29de23c70305123faf1a9d0bae6@relay.dk>
	<22561413.post@talk.nabble.com> <49BFD57C.5010301@ksu.ru>
Message-ID: <22651491.post@talk.nabble.com>



Marat N.Afanasyev wrote:
> 
> Nicolais wrote:
>> Also - this was extracted from kenv:
>> 
>> smbios.system.maker="MICRO-STAR INTERANTIONAL CO.,LTD"
>> smbios.system.product="MS-7368"
> 
> as I supposed in previous message your MB is MicroStar product. So I 
> insist that you read thread [1] in freebsd-stable named 'Interrupt 
> storm' started by Dan Langille
> 
> [1] 
> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047645.html
> 

Hi Marat,

Thank you for pointing this out. After posting I looked in more archives and
found the same threads are you listed.

I have now run with DDB and KDB more than 5 days, and the interrupt storms
have ceased it seems.

This is truly wonderful news, even though I don't really like the solution.

I will leave the options on for now, but will continue to monitor the lists
for better solutions. I would lie if I said I had not hoped a driver update
would have solved the situation, but I guess that is coming sooner or later.

Thanks again

Best regards

 - Nicolai
-- 
View this message in context: http://www.nabble.com/Crazy-%22interrupt-storm-detected%22-on-atapic0-tp22560101p22651491.html
Sent from the freebsd-stable mailing list archive at Nabble.com.

From aoyama at peach.ne.jp  Sun Mar 22 17:31:20 2009
From: aoyama at peach.ne.jp (Daisuke Aoyama)
Date: Sun Mar 22 17:31:33 2009
Subject: istgt now supports command queuing in disk type
Message-ID: <B6937FAAAA444B9F855D8F62AB13AF17@artemis>

Hello.

New release was uploaded in my blog.
The command queuing improves especially sequential read
by MCS(multiple connections per session) round robin.
In my post, I uploaded the screen shots using CrystalDiskMark
which is one of popular benchmark in Japan.

You can download CrystalDiskMark(multilingual) from:
http://crystalmark.info/?lang=en

I got the result about 1.5x-3x faster than previous 20090314.
If test data was cached, it reached over 200MB/s.

Known Issue and Limitations:
 o queuing is only supported in single initiator environment.
 o LUN thread might have deadlock when an error has occurred.
 o write command is still slow.
 o timeout may occur when using MCS.
 o single connection may be slower than without queuing.

Here is release 20090323:
http://shell.peach.ne.jp/aoyama/archives/376

The screen shots show difference between QueueDepth 16 and 0
(disabled queuing).

The command queuing is disabled by default.
If you want to use it, please add QueueDepth key in the LogicalUnit
section of your configuration. for example:

[LogicalUnit1]
  # Queuing 0=disabled, 1-255=enabled with specified depth.
  QueueDepth 16

Thanks.
--
Daisuke Aoyama

From pyunyh at gmail.com  Sun Mar 22 17:52:07 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Sun Mar 22 17:52:14 2009
Subject: Lock enabling onboard lan (Attansic L1 GbE) on 7.1-PRERELEASE
In-Reply-To: <KGXA5X$0EC1E19669F729D4A18D2E54F1F3BEED@libero.it>
References: <KGXA5X$0EC1E19669F729D4A18D2E54F1F3BEED@libero.it>
Message-ID: <20090323004932.GA5083@michelle.cdnetworks.co.kr>

On Sun, Mar 22, 2009 at 08:29:57PM +0100, barbara wrote:
> 
> Any news about that?
> 
> http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047527.html
> 

I'm sorry, I forgot this issue which was caused by my disk crash
happened in the end of Jan, 2009.
I've updated age(4) patch in the following URL.
http://people.freebsd.org/~yongari/age/age.diff

Please test the with
1. shutdown your box
2. remove power cable and wait 5 min.
3. unplug UTP cabble
4. boot and see whether age(4) does not lockup your box
5. plug UTP cable and see whether age(4) can send/receive traffics

And please do
1. reboot your box with UTP cable plugged in
2. check whether age(4) works

Please also see whether ethernet MAC address is correctly detected
in both cases.

Thanks for reminder.
From wsk at gddsn.org.cn  Sun Mar 22 21:34:15 2009
From: wsk at gddsn.org.cn (wsk)
Date: Sun Mar 22 21:34:30 2009
Subject: [PREVIEW] Nouveau on FreeBSD (Take 2)
In-Reply-To: <49B8AC04.10508@gddsn.org.cn>
References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn>
Message-ID: <49C6E5C6.60306@gddsn.org.cn>

>Ok, this patch should work on NV50 chips also.

>What you get is EXA and Xv.

>You still need:

>A recent -CURRENT or -STABLE.

>git master of libdrm and xf86-video-nouveau.

>This patch.

>Things I've figured out since the last patch...

>On NV50 class hardware you need to have a compositing manager running
>for Xv to work.  That means xcompmgr, metacity with composite enabled,
>xfce (rumored to work as well, haven't tried).  If your running Gnome
>with metacity, open gconf-editor and go to apps->metacity->general and
>check the composite box.

>On NV40 class hardware, you don't need the composite manager.  In fact
>(at least with Xserver 1.6 which I'm running now), if a composite
>manager is enabled, I'm seeing high cpu utilization from Xorg under some
>circumstances.  I don't think this is a drm issue, but still an issue.
>For me, if I start a video using mplayer in an xterm, cpu is fine as
>long as that xterm is the foreground window.  If it is not the
>foreground window, even if it isn't obscured I see the cpu utilization.
>Disabling the composite manager makes everything fine.

>http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch <http://people.freebsd.org/%7Ernoland/drm-nouveau-032109.patch>

>robert.

get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.5.99.902 (1.6.0 RC 2)
Release Date: 2009-1-30
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 7.1-STABLE amd64
Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE
RELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/sr
c/sys/WSK amd64
Build Date: 06 February 2009  04:22:44PM

        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
ing config file: "xorg.conf1"
error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
drm0: [ITHREAD]
info: [drm] Allocating FIFO number 1
info: [drm] nouveau_fifo_alloc: initialised FIFO 1
info: [drm] PFIFO_DMA_PUSHER - Ch 1
(EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional informati
on.

info: [drm] nouveau_fifo_free: freeing fifo 1
error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before
destroy.Prepare for strangeness..
vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1

what can i do ?




-------------- next part --------------

This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.5.99.902 (1.6.0 RC 2)
Release Date: 2009-1-30
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 7.1-STABLE amd64 
Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64
Build Date: 06 February 2009  04:22:44PM
 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
(++) Using config file: "xorg.conf1"
(==) No Layout section.  Using the first Screen section.
(==) No screen section available. Using defaults.
(**) |-->Screen "Default Screen Section" (0)
(**) |   |-->Monitor "<default monitor>"
(==) No device specified for screen "Default Screen Section".
	Using the first device section listed.
(**) |   |-->Device "Card0"
(==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(==) No FontPath specified.  Using compiled-in default.
(==) FontPath set to:
	built-ins
(==) ModulePath set to "/usr/local/lib/xorg/modules"
(II) Cannot locate a core pointer device.
(II) Cannot locate a core keyboard device.
(II) The server relies on HAL to provide the list of input devices.
	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
(II) Loader magic: 0xb20
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.4
	X.Org Video Driver: 5.0
	X.Org XInput driver : 4.0
	X.Org Server Extension : 2.0
(II) Loader running on freebsd
(--) Using syscons driver with X support (version 2.0)
(--) using VT number 9

(--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536
(II) System resource ranges:
	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) LoadModule: "extmod"
(II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 1.5.99.902, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"
(II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 1.5.99.902, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"
(II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
	compiled for 1.5.99.902, module version = 1.0.0
	ABI class: X.Org Server Extension, version 2.0
(==) AIGLX disabled
(==) Exporting typical set of GLX visuals
(II) Loading extension GLX
(II) LoadModule: "record"
(II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
(II) Module record: vendor="X.Org Foundation"
	compiled for 1.5.99.902, module version = 1.13.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension RECORD
(II) LoadModule: "dri"
(II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.5.99.902, module version = 1.0.0
	ABI class: X.Org Server Extension, version 2.0
(II) Loading extension XFree86-DRI
(II) LoadModule: "nouveau"
(II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so
(II) Module nouveau: vendor="X.Org Foundation"
	compiled for 1.5.99.902, module version = 0.0.10
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 5.0
(II) NOUVEAU driver Date:   Wed Mar 18 09:36:33 2009 +1000
(II) NOUVEAU driver for NVIDIA chipset families :
	RIVA TNT    (NV04)
	RIVA TNT2   (NV05)
	GeForce 256 (NV10)
	GeForce 2   (NV11, NV15)
	GeForce 4MX (NV17, NV18)
	GeForce 3   (NV20)
	GeForce 4Ti (NV25, NV28)
	GeForce FX  (NV3x)
	GeForce 6   (NV4x)
	GeForce 7   (G7x)
	GeForce 8   (G8x)
(II) Primary Device is: PCI 01@00:00:0
(II) resource ranges after probing:
	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(--) NOUVEAU(0): Chipset: "NVIDIA NV86"
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/local/lib/xorg/modules//libint10.so
(II) Module int10: vendor="X.Org Foundation"
	compiled for 1.5.99.902, module version = 1.0.0
	ABI class: X.Org Video Driver, version 5.0
(II) NOUVEAU(0): Initializing int10
(==) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already clear
(==) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already clear
(II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000
(==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 10, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 10, (OK)
drmOpenByBusid: Searching for BusID pci:0000:01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 10, (OK)
drmOpenByBusid: drmOpenMinor returns 10
drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
(II) [drm] DRM interface version 1.2
(II) [drm] DRM open master succeeded.
(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12
(--) NOUVEAU(0): [drm] kernel modesetting not available
(--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3
(II) NOUVEAU(0): Creating default Display subsection in Screen section
	"Default Screen Section" for depth/fbbpp 24/32
(==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32
(==) NOUVEAU(0): RGB weight 888
(==) NOUVEAU(0): Default visual is TrueColor
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/local/lib/xorg/modules//libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
	compiled for 1.5.99.902, module version = 0.1.0
	ABI class: X.Org Video Driver, version 5.0
(==) NOUVEAU(0): Randr1.2 support enabled
(==) NOUVEAU(0): Using HW cursor
(EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
(==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
(II) UnloadModule: "nouveau"
(II) UnloadModule: "vgahw"
(II) Unloading /usr/local/lib/xorg/modules//libvgahw.so
(II) UnloadModule: "int10"
(II) Unloading /usr/local/lib/xorg/modules//libint10.so
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.
From lambert at lambertfam.org  Sun Mar 22 22:36:32 2009
From: lambert at lambertfam.org (Scott Lambert)
Date: Sun Mar 22 22:36:39 2009
Subject: Is some combination of gmirror, md file systems, snapshots and,
	maybe, quotas considered harmful?
In-Reply-To: <49C67D8A.5070505@FreeBSD.org>
References: <20090320194157.GB80292@sysmon.tcworks.net>
	<20090322093156.GE80292@sysmon.tcworks.net>
	<49C67D8A.5070505@FreeBSD.org>
Message-ID: <20090323053630.GH80292@sysmon.tcworks.net>

On Sun, Mar 22, 2009 at 06:03:54PM +0000, Kris Kennaway wrote:
> http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html

I guess that means, "We are not aware of issues with any combinations
of the features in the Subject: at this time.  Please recompile your
kernel with debugging options so you can figure out what is going on
next time."

I'm going to guess the Debugging Deadlocks section is what you mostly
want since the kernel does not panic.  

I think I better remove the /home disk from AMANDA's list while I try
to figure out how to accomplish what I think you want on a production
server.

-- 
Scott Lambert                    KC5MLE                       Unix SysAdmin
lambert@lambertfam.org

From security at jim-liesl.org  Sun Mar 22 23:09:00 2009
From: security at jim-liesl.org (security)
Date: Sun Mar 22 23:09:08 2009
Subject: filesystem corruption freebsd 7.1 release guest on virtualpc
 2007/windowsXP host system
Message-ID: <49C7212C.9090006@jim-liesl.org>

I'm writing this more as a heads up to those using freebsd as a guest
under virtualpc 2007 on Win XP sp3 host.

I created a fixed size virtual disk (8gig). Just to be sure, I ran the
XP disk check on the underlying disk before hand.  I then installed
freebsd 7.1 from cd image.  Next I csup'ed to get the latest updates.  I
then did a make buildworld and a make kernel.  I ran into trouble when
it rebooted and went to run make installworld.  Part way through, I
started getting a bunch of FS errors and then a kernel panic.  I
rebooted and manually fsck'ed /usr.  It did recover, but was unusable. 
I tried the same thing again (fresh install), but I used dd and fsck to
read /usr first to see if I could generate errors. It was clean but died
again while it was writing lots of files to /usr during installworld.

I had my suspicions that freebsd and the XP filesystems we getting out
of sync under a large number of updates.  I rebuilt a third time, but
for this round, I set hw.ata.wc="0" in loader.conf.  I haven't seen any
other corruption since turning off write caching and the installworld
runs clean now (multiple passes).  I'm not sure who maintains the
virtualization pages, but they may want to add that as a suggestion for
virtualpc or other VM's that run into disk corruption problems.

jim
From rnoland at FreeBSD.org  Mon Mar 23 02:02:18 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Mon Mar 23 02:02:38 2009
Subject: [PREVIEW] Nouveau on FreeBSD (Take 2)
In-Reply-To: <49C6E5C6.60306@gddsn.org.cn>
References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn>
	<49C6E5C6.60306@gddsn.org.cn>
Message-ID: <1237798914.2110.24.camel@balrog.2hip.net>

On Mon, 2009-03-23 at 09:28 +0800, wsk wrote:
> >Ok, this patch should work on NV50 chips also.
> 
> >What you get is EXA and Xv.
> 
> >You still need:
> 
> >A recent -CURRENT or -STABLE.
> 
> >git master of libdrm and xf86-video-nouveau.
> 
> >This patch.
> 
> >Things I've figured out since the last patch...
> 
> >On NV50 class hardware you need to have a compositing manager running
> >for Xv to work.  That means xcompmgr, metacity with composite enabled,
> >xfce (rumored to work as well, haven't tried).  If your running Gnome
> >with metacity, open gconf-editor and go to apps->metacity->general and
> >check the composite box.
> 
> >On NV40 class hardware, you don't need the composite manager.  In fact
> >(at least with Xserver 1.6 which I'm running now), if a composite
> >manager is enabled, I'm seeing high cpu utilization from Xorg under some
> >circumstances.  I don't think this is a drm issue, but still an issue.
> >For me, if I start a video using mplayer in an xterm, cpu is fine as
> >long as that xterm is the foreground window.  If it is not the
> >foreground window, even if it isn't obscured I see the cpu utilization.
> >Disabling the composite manager makes everything fine.
> 
> >http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch <http://people.freebsd.org/%7Ernoland/drm-nouveau-032109.patch>
> 
> >robert.
> 
> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation.
> It is not supported in any way.
> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> Select the "xorg" product for bugs you find in this release.
> Before reporting bugs in pre-release versions please check the
> latest version in the X.Org Foundation git repository.
> See http://wiki.x.org/wiki/GitPage for git access instructions.
> 
> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> Release Date: 2009-1-30
> X Protocol Version 11, Revision 0
> Build Operating System: FreeBSD 7.1-STABLE amd64
> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE
> RELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/sr
> c/sys/WSK amd64
> Build Date: 06 February 2009  04:22:44PM
> 
>         Before reporting problems, check http://wiki.x.org
>         to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
>         (++) from command line, (!!) notice, (II) informational,
>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> ing config file: "xorg.conf1"
> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> drm0: [ITHREAD]
> info: [drm] Allocating FIFO number 1
> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
> info: [drm] PFIFO_DMA_PUSHER - Ch 1
> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> (EE) Screen(s) found, but none have a usable configuration.
> 
> Fatal server error:
> no screens found
> 
> Please consult the The X.Org Foundation support
>          at http://wiki.x.org
>  for help.
> Please also check the log file at "/var/log/Xorg.0.log" for additional informati
> on.
> 
> info: [drm] nouveau_fifo_free: freeing fifo 1
> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before
> destroy.Prepare for strangeness..
> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> 
> what can i do ?
> 
> 
> 
> 
> plain text document attachment (Xorg.0.log)
> This is a pre-release version of the X server from The X.Org Foundation.
> It is not supported in any way.
> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> Select the "xorg" product for bugs you find in this release.
> Before reporting bugs in pre-release versions please check the
> latest version in the X.Org Foundation git repository.
> See http://wiki.x.org/wiki/GitPage for git access instructions.
> 
> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> Release Date: 2009-1-30
> X Protocol Version 11, Revision 0
> Build Operating System: FreeBSD 7.1-STABLE amd64 
> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64
> Build Date: 06 February 2009  04:22:44PM
>  
> 	Before reporting problems, check http://wiki.x.org
> 	to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
> 	(++) from command line, (!!) notice, (II) informational,
> 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> (++) Using config file: "xorg.conf1"
> (==) No Layout section.  Using the first Screen section.
> (==) No screen section available. Using defaults.
> (**) |-->Screen "Default Screen Section" (0)
> (**) |   |-->Monitor "<default monitor>"
> (==) No device specified for screen "Default Screen Section".
> 	Using the first device section listed.
> (**) |   |-->Device "Card0"
> (==) No monitor specified for screen "Default Screen Section".
> 	Using a default monitor configuration.
> (==) Automatically adding devices
> (==) Automatically enabling devices
> (==) No FontPath specified.  Using compiled-in default.
> (==) FontPath set to:
> 	built-ins
> (==) ModulePath set to "/usr/local/lib/xorg/modules"
> (II) Cannot locate a core pointer device.
> (II) Cannot locate a core keyboard device.
> (II) The server relies on HAL to provide the list of input devices.
> 	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
> (II) Loader magic: 0xb20
> (II) Module ABI versions:
> 	X.Org ANSI C Emulation: 0.4
> 	X.Org Video Driver: 5.0
> 	X.Org XInput driver : 4.0
> 	X.Org Server Extension : 2.0
> (II) Loader running on freebsd
> (--) Using syscons driver with X support (version 2.0)
> (--) using VT number 9
> 
> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536

Ok, thats a new one...

> (II) System resource ranges:
> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> (II) LoadModule: "extmod"
> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
> (II) Module extmod: vendor="X.Org Foundation"
> 	compiled for 1.5.99.902, module version = 1.0.0
> 	Module class: X.Org Server Extension
> 	ABI class: X.Org Server Extension, version 2.0
> (II) Loading extension MIT-SCREEN-SAVER
> (II) Loading extension XFree86-VidModeExtension
> (II) Loading extension XFree86-DGA
> (II) Loading extension DPMS
> (II) Loading extension XVideo
> (II) Loading extension XVideo-MotionCompensation
> (II) Loading extension X-Resource
> (II) LoadModule: "dbe"
> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
> (II) Module dbe: vendor="X.Org Foundation"
> 	compiled for 1.5.99.902, module version = 1.0.0
> 	Module class: X.Org Server Extension
> 	ABI class: X.Org Server Extension, version 2.0
> (II) Loading extension DOUBLE-BUFFER
> (II) LoadModule: "glx"
> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
> (II) Module glx: vendor="X.Org Foundation"
> 	compiled for 1.5.99.902, module version = 1.0.0
> 	ABI class: X.Org Server Extension, version 2.0
> (==) AIGLX disabled
> (==) Exporting typical set of GLX visuals
> (II) Loading extension GLX
> (II) LoadModule: "record"
> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
> (II) Module record: vendor="X.Org Foundation"
> 	compiled for 1.5.99.902, module version = 1.13.0
> 	Module class: X.Org Server Extension
> 	ABI class: X.Org Server Extension, version 2.0
> (II) Loading extension RECORD
> (II) LoadModule: "dri"
> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
> (II) Module dri: vendor="X.Org Foundation"
> 	compiled for 1.5.99.902, module version = 1.0.0
> 	ABI class: X.Org Server Extension, version 2.0
> (II) Loading extension XFree86-DRI
> (II) LoadModule: "nouveau"
> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so
> (II) Module nouveau: vendor="X.Org Foundation"
> 	compiled for 1.5.99.902, module version = 0.0.10
> 	Module class: X.Org Video Driver
> 	ABI class: X.Org Video Driver, version 5.0
> (II) NOUVEAU driver Date:   Wed Mar 18 09:36:33 2009 +1000
> (II) NOUVEAU driver for NVIDIA chipset families :
> 	RIVA TNT    (NV04)
> 	RIVA TNT2   (NV05)
> 	GeForce 256 (NV10)
> 	GeForce 2   (NV11, NV15)
> 	GeForce 4MX (NV17, NV18)
> 	GeForce 3   (NV20)
> 	GeForce 4Ti (NV25, NV28)
> 	GeForce FX  (NV3x)
> 	GeForce 6   (NV4x)
> 	GeForce 7   (G7x)
> 	GeForce 8   (G8x)
> (II) Primary Device is: PCI 01@00:00:0
> (II) resource ranges after probing:
> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> (--) NOUVEAU(0): Chipset: "NVIDIA NV86"

Hrm, NV86... I'll have to ask around about that.  Meanwhile can you send
me a pciconf -lvb which should at least show us the BAR configuration.

Ok, my sources are telling me that this should work and that it is an
NV50, or at least should work the same...

Also, just to be safe, please rebuild/reinstall devel/libpciaccess.  I'm
not sure if it may be trashing the BARs somehow.

robert.

> (II) Loading sub module "int10"
> (II) LoadModule: "int10"
> (II) Loading /usr/local/lib/xorg/modules//libint10.so
> (II) Module int10: vendor="X.Org Foundation"
> 	compiled for 1.5.99.902, module version = 1.0.0
> 	ABI class: X.Org Video Driver, version 5.0
> (II) NOUVEAU(0): Initializing int10
> (==) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already clear
> (==) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already clear
> (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000
> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 10, (OK)
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 10, (OK)
> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 10, (OK)
> drmOpenByBusid: drmOpenMinor returns 10
> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
> (II) [drm] DRM interface version 1.2
> (II) [drm] DRM open master succeeded.
> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12
> (--) NOUVEAU(0): [drm] kernel modesetting not available
> (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3
> (II) NOUVEAU(0): Creating default Display subsection in Screen section
> 	"Default Screen Section" for depth/fbbpp 24/32
> (==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32
> (==) NOUVEAU(0): RGB weight 888
> (==) NOUVEAU(0): Default visual is TrueColor
> (II) Loading sub module "vgahw"
> (II) LoadModule: "vgahw"
> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so
> (II) Module vgahw: vendor="X.Org Foundation"
> 	compiled for 1.5.99.902, module version = 0.1.0
> 	ABI class: X.Org Video Driver, version 5.0
> (==) NOUVEAU(0): Randr1.2 support enabled
> (==) NOUVEAU(0): Using HW cursor
> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
> (II) UnloadModule: "nouveau"
> (II) UnloadModule: "vgahw"
> (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so
> (II) UnloadModule: "int10"
> (II) Unloading /usr/local/lib/xorg/modules//libint10.so
> (EE) Screen(s) found, but none have a usable configuration.
> 
> Fatal server error:
> no screens found
> 
> Please consult the The X.Org Foundation support 
> 	 at http://wiki.x.org
>  for help. 
> Please also check the log file at "/var/log/Xorg.0.log" for additional information.
> 
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090323/bae1fc9d/attachment.pgp
From danny at cs.huji.ac.il  Mon Mar 23 07:10:57 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Mon Mar 23 07:11:05 2009
Subject: 7.2 and iir stuck on boot.
Message-ID: <E1LlkZx-000PNY-Vj@kabab.cs.huji.ac.il>

Hi,
after upgrading to 7.2, booting the kernel gets stuck with:
  run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config

from a 7.1 dmesg, it seems that it's in the iir driver.

danny


From lev at FreeBSD.org  Mon Mar 23 13:16:42 2009
From: lev at FreeBSD.org (Lev Serebryakov)
Date: Mon Mar 23 13:16:54 2009
Subject: istgt now supports command queuing in disk type
In-Reply-To: <B6937FAAAA444B9F855D8F62AB13AF17@artemis>
References: <B6937FAAAA444B9F855D8F62AB13AF17@artemis>
Message-ID: <754391506.20090323225858@serebryakov.spb.ru>

Hello, Daisuke.
You wrote 23 ????? 2009 ?., 03:31:12:

> I got the result about 1.5x-3x faster than previous 20090314.
> If test data was cached, it reached over 200MB/s.
  I have one question: what do you mean when write, that this software
is intended to use with ZFS? Could it be used to provide access to raw
(disk) devices? Is it safe? Ok, it can have bugs, but is it as safe
as access to file placed on ZFS (you test it in such configuration, am
I right?)?

-- 
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>

From mi+thun at aldan.algebra.com  Mon Mar 23 19:02:47 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Mon Mar 23 19:02:54 2009
Subject: dump | restore fails: unknown tape header type 1853384566
Message-ID: <49C83673.3000604@aldan.algebra.com>

Hello!

I'm trying to migrate a filesystem from one disk to another using:

    dump a0hCf 0 32 - /old | restore -rf -

(/old is already mounted read-only). The process runs for a while and 
then stops with:

    [...]
      DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
      DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
      DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
    unknown tape header type 1853384566
    abort? [yn]

Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's 
dump's output?

The system runs 7.0-STABLE from July 6th, i386. I just tried updating 
the dump and restore from source (latest 7.x) -- the error is the same...

Please, advise. Thanks!

    -mi

From wsk at gddsn.org.cn  Mon Mar 23 21:19:29 2009
From: wsk at gddsn.org.cn (wsk)
Date: Mon Mar 23 21:19:38 2009
Subject: [PREVIEW] Nouveau on FreeBSD (Take 2)
In-Reply-To: <1237798914.2110.24.camel@balrog.2hip.net>
References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn>	
	<49C6E5C6.60306@gddsn.org.cn>
	<1237798914.2110.24.camel@balrog.2hip.net>
Message-ID: <49C85F4E.5050002@gddsn.org.cn>

Robert Noland wrote:
> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote:
>   
>>> Ok, this patch should work on NV50 chips also.
>>>       
>>> What you get is EXA and Xv.
>>>       
>>> You still need:
>>>       
>>> A recent -CURRENT or -STABLE.
>>>       
>>> git master of libdrm and xf86-video-nouveau.
>>>       
>>> This patch.
>>>       
>>> Things I've figured out since the last patch...
>>>       
>>> On NV50 class hardware you need to have a compositing manager running
>>> for Xv to work.  That means xcompmgr, metacity with composite enabled,
>>> xfce (rumored to work as well, haven't tried).  If your running Gnome
>>> with metacity, open gconf-editor and go to apps->metacity->general and
>>> check the composite box.
>>>       
>>> On NV40 class hardware, you don't need the composite manager.  In fact
>>> (at least with Xserver 1.6 which I'm running now), if a composite
>>> manager is enabled, I'm seeing high cpu utilization from Xorg under some
>>> circumstances.  I don't think this is a drm issue, but still an issue.
>>> For me, if I start a video using mplayer in an xterm, cpu is fine as
>>> long as that xterm is the foreground window.  If it is not the
>>> foreground window, even if it isn't obscured I see the cpu utilization.
>>> Disabling the composite manager makes everything fine.
>>>       
>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch <http://people.freebsd.org/%7Ernoland/drm-nouveau-032109.patch>
>>>       
>>> robert.
>>>       
>> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation.
>> It is not supported in any way.
>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
>> Select the "xorg" product for bugs you find in this release.
>> Before reporting bugs in pre-release versions please check the
>> latest version in the X.Org Foundation git repository.
>> See http://wiki.x.org/wiki/GitPage for git access instructions.
>>
>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
>> Release Date: 2009-1-30
>> X Protocol Version 11, Revision 0
>> Build Operating System: FreeBSD 7.1-STABLE amd64
>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE
>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/sr
>> c/sys/WSK amd64
>> Build Date: 06 February 2009  04:22:44PM
>>
>>         Before reporting problems, check http://wiki.x.org
>>         to make sure that you have the latest version.
>> Markers: (--) probed, (**) from config file, (==) default setting,
>>         (++) from command line, (!!) notice, (II) informational,
>>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
>> ing config file: "xorg.conf1"
>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>> drm0: [ITHREAD]
>> info: [drm] Allocating FIFO number 1
>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
>> (EE) Screen(s) found, but none have a usable configuration.
>>
>> Fatal server error:
>> no screens found
>>
>> Please consult the The X.Org Foundation support
>>          at http://wiki.x.org
>>  for help.
>> Please also check the log file at "/var/log/Xorg.0.log" for additional informati
>> on.
>>
>> info: [drm] nouveau_fifo_free: freeing fifo 1
>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before
>> destroy.Prepare for strangeness..
>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>
>> what can i do ?
>>
>>
>>
>>
>> plain text document attachment (Xorg.0.log)
>> This is a pre-release version of the X server from The X.Org Foundation.
>> It is not supported in any way.
>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
>> Select the "xorg" product for bugs you find in this release.
>> Before reporting bugs in pre-release versions please check the
>> latest version in the X.Org Foundation git repository.
>> See http://wiki.x.org/wiki/GitPage for git access instructions.
>>
>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
>> Release Date: 2009-1-30
>> X Protocol Version 11, Revision 0
>> Build Operating System: FreeBSD 7.1-STABLE amd64 
>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64
>> Build Date: 06 February 2009  04:22:44PM
>>  
>> 	Before reporting problems, check http://wiki.x.org
>> 	to make sure that you have the latest version.
>> Markers: (--) probed, (**) from config file, (==) default setting,
>> 	(++) from command line, (!!) notice, (II) informational,
>> 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
>> (++) Using config file: "xorg.conf1"
>> (==) No Layout section.  Using the first Screen section.
>> (==) No screen section available. Using defaults.
>> (**) |-->Screen "Default Screen Section" (0)
>> (**) |   |-->Monitor "<default monitor>"
>> (==) No device specified for screen "Default Screen Section".
>> 	Using the first device section listed.
>> (**) |   |-->Device "Card0"
>> (==) No monitor specified for screen "Default Screen Section".
>> 	Using a default monitor configuration.
>> (==) Automatically adding devices
>> (==) Automatically enabling devices
>> (==) No FontPath specified.  Using compiled-in default.
>> (==) FontPath set to:
>> 	built-ins
>> (==) ModulePath set to "/usr/local/lib/xorg/modules"
>> (II) Cannot locate a core pointer device.
>> (II) Cannot locate a core keyboard device.
>> (II) The server relies on HAL to provide the list of input devices.
>> 	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
>> (II) Loader magic: 0xb20
>> (II) Module ABI versions:
>> 	X.Org ANSI C Emulation: 0.4
>> 	X.Org Video Driver: 5.0
>> 	X.Org XInput driver : 4.0
>> 	X.Org Server Extension : 2.0
>> (II) Loader running on freebsd
>> (--) Using syscons driver with X support (version 2.0)
>> (--) using VT number 9
>>
>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536
>>     
>
> Ok, thats a new one...
>
>   
>> (II) System resource ranges:
>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
>> (II) LoadModule: "extmod"
>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
>> (II) Module extmod: vendor="X.Org Foundation"
>> 	compiled for 1.5.99.902, module version = 1.0.0
>> 	Module class: X.Org Server Extension
>> 	ABI class: X.Org Server Extension, version 2.0
>> (II) Loading extension MIT-SCREEN-SAVER
>> (II) Loading extension XFree86-VidModeExtension
>> (II) Loading extension XFree86-DGA
>> (II) Loading extension DPMS
>> (II) Loading extension XVideo
>> (II) Loading extension XVideo-MotionCompensation
>> (II) Loading extension X-Resource
>> (II) LoadModule: "dbe"
>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
>> (II) Module dbe: vendor="X.Org Foundation"
>> 	compiled for 1.5.99.902, module version = 1.0.0
>> 	Module class: X.Org Server Extension
>> 	ABI class: X.Org Server Extension, version 2.0
>> (II) Loading extension DOUBLE-BUFFER
>> (II) LoadModule: "glx"
>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
>> (II) Module glx: vendor="X.Org Foundation"
>> 	compiled for 1.5.99.902, module version = 1.0.0
>> 	ABI class: X.Org Server Extension, version 2.0
>> (==) AIGLX disabled
>> (==) Exporting typical set of GLX visuals
>> (II) Loading extension GLX
>> (II) LoadModule: "record"
>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
>> (II) Module record: vendor="X.Org Foundation"
>> 	compiled for 1.5.99.902, module version = 1.13.0
>> 	Module class: X.Org Server Extension
>> 	ABI class: X.Org Server Extension, version 2.0
>> (II) Loading extension RECORD
>> (II) LoadModule: "dri"
>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
>> (II) Module dri: vendor="X.Org Foundation"
>> 	compiled for 1.5.99.902, module version = 1.0.0
>> 	ABI class: X.Org Server Extension, version 2.0
>> (II) Loading extension XFree86-DRI
>> (II) LoadModule: "nouveau"
>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so
>> (II) Module nouveau: vendor="X.Org Foundation"
>> 	compiled for 1.5.99.902, module version = 0.0.10
>> 	Module class: X.Org Video Driver
>> 	ABI class: X.Org Video Driver, version 5.0
>> (II) NOUVEAU driver Date:   Wed Mar 18 09:36:33 2009 +1000
>> (II) NOUVEAU driver for NVIDIA chipset families :
>> 	RIVA TNT    (NV04)
>> 	RIVA TNT2   (NV05)
>> 	GeForce 256 (NV10)
>> 	GeForce 2   (NV11, NV15)
>> 	GeForce 4MX (NV17, NV18)
>> 	GeForce 3   (NV20)
>> 	GeForce 4Ti (NV25, NV28)
>> 	GeForce FX  (NV3x)
>> 	GeForce 6   (NV4x)
>> 	GeForce 7   (G7x)
>> 	GeForce 8   (G8x)
>> (II) Primary Device is: PCI 01@00:00:0
>> (II) resource ranges after probing:
>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86"
>>     
>
> Hrm, NV86... I'll have to ask around about that.  Meanwhile can you send
> me a pciconf -lvb which should at least show us the BAR configuration.
>
> Ok, my sources are telling me that this should work and that it is an
> NV50, or at least should work the same...
>
> Also, just to be safe, please rebuild/reinstall devel/libpciaccess.  I'm
> not sure if it may be trashing the BARs somehow.
>
> robert.
>   

hostb0@pci0:0:0:0: class=0x060000 card=0x01fe1028 chip=0x2a008086
rev=0x0c hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile PM965/GM965/GL960 Express Processor to DRAM Controller'
class = bridge
subclass = HOST-PCI
pcib1@pci0:0:1:0: class=0x060400 card=0x01fe1028 chip=0x2a018086
rev=0x0c hdr=0x01
vendor = 'Intel Corporation'
device = 'Mobile PM965/GM965/GL960 Express PCIe Root Port'
class = bridge
subclass = PCI-PCI
uhci0@pci0:0:26:0: class=0x0c0300 card=0x01fe1028 chip=0x28348086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class = serial bus
subclass = USB
bar [20] = type I/O Port, range 32, base 0x6f20, size 32, enabled
uhci1@pci0:0:26:1: class=0x0c0300 card=0x01fe1028 chip=0x28358086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class = serial bus
subclass = USB
bar [20] = type I/O Port, range 32, base 0x6f00, size 32, enabled
ehci0@pci0:0:26:7: class=0x0c0320 card=0x01fe1028 chip=0x283a8086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '81EC1043 (?) ICH8 Enhanced USB2 Enhanced Host Controller'
class = serial bus
subclass = USB
bar [10] = type Memory, range 32, base 0xfed1c400, size 1024, enabled
hdac0@pci0:0:27:0: class=0x040300 card=0x01fe1028 chip=0x284b8086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H &SUBSYS_81EC1043&REV_02\3&11583659&0&D8'
class = multimedia
subclass = HDA
bar [10] = type Memory, range 64, base 0xfebfc000, size 16384, enabled
pcib2@pci0:0:28:0: class=0x060400 card=0x01fe1028 chip=0x283f8086
rev=0x02 hdr=0x01
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) PCIe Port 1'
class = bridge
subclass = PCI-PCI
pcib3@pci0:0:28:1: class=0x060400 card=0x01fe1028 chip=0x28418086
rev=0x02 hdr=0x01
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) PCIe Port 2'
class = bridge
subclass = PCI-PCI
pcib4@pci0:0:28:3: class=0x060400 card=0x01fe1028 chip=0x28458086
rev=0x02 hdr=0x01
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) PCIe Port 4'
class = bridge
subclass = PCI-PCI
pcib5@pci0:0:28:5: class=0x060400 card=0x01fe1028 chip=0x28498086
rev=0x02 hdr=0x01
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) PCIe Port 6'
class = bridge
subclass = PCI-PCI
uhci2@pci0:0:29:0: class=0x0c0300 card=0x01fe1028 chip=0x28308086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class = serial bus
subclass = USB
bar [20] = type I/O Port, range 32, base 0x6f80, size 32, enabled
uhci3@pci0:0:29:1: class=0x0c0300 card=0x01fe1028 chip=0x28318086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class = serial bus
subclass = USB
bar [20] = type I/O Port, range 32, base 0x6f60, size 32, enabled
uhci4@pci0:0:29:2: class=0x0c0300 card=0x01fe1028 chip=0x28328086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB UHCI'
class = serial bus
subclass = USB
bar [20] = type I/O Port, range 32, base 0x6f40, size 32, enabled
ehci1@pci0:0:29:7: class=0x0c0320 card=0x01fe1028 chip=0x28368086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) USB2 EHCI'
class = serial bus
subclass = USB
bar [10] = type Memory, range 32, base 0xfed1c000, size 1024, enabled
pcib6@pci0:0:30:0: class=0x060401 card=0x01fe1028 chip=0x24488086
rev=0xf2 hdr=0x01
vendor = 'Intel Corporation'
device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge'
class = bridge
subclass = PCI-PCI
isab0@pci0:0:31:0: class=0x060100 card=0x01fe1028 chip=0x28158086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = 'ICH8M-E (ICH8 Family) LPC Interface Controller'
class = bridge
subclass = PCI-ISA
atapci0@pci0:0:31:1: class=0x01018a card=0x01fe1028 chip=0x28508086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) Ultra ATA Storage Controllers'
class = mass storage
subclass = ATA
bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled
bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled
bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled
bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled
bar [20] = type I/O Port, range 32, base 0x6fa0, size 16, enabled
atapci1@pci0:0:31:2: class=0x01018f card=0x01fe1028 chip=0x28288086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = 'ICH8M (ICH8 Family) 3 port SATA Controller'
class = mass storage
subclass = ATA
bar [10] = type I/O Port, range 32, base 0x6eb0, size 8, enabled
bar [14] = type I/O Port, range 32, base 0x6eb8, size 4, enabled
bar [18] = type I/O Port, range 32, base 0x6ec0, size 8, enabled
bar [1c] = type I/O Port, range 32, base 0x6ec8, size 4, enabled
bar [20] = type I/O Port, range 32, base 0x6ee0, size 16, enabled
bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled
ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086
rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82801H (ICH8 Family) SMBus Controller'
class = serial bus
subclass = SMBus
bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled
bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled
vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de
rev=0xa1 hdr=0x00
vendor = 'Nvidia Corp'
device = 'Unknown nVidia Quadro FX 570M'
class = display
subclass = VGA
bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled
bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled
bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled
ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4
rev=0x03 hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM94321KFBG Broadcom 4321AGN 802.11a/b/g/draft-n Wi-Fi Solution'
class = network
bar [10] = type Memory, range 64, base 0xf9ffc000, size 16384, enabled
bar [18] = type Prefetchable Memory, range 64, base 0xf0000000, size
1048576, enabled
bge0@pci0:9:0:0: class=0x020000 card=0x01fe1028 chip=0x167314e4 rev=0x02
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'B57xx Broadcom NetXtreme Gigabit Ethernet'
class = network
subclass = ethernet
bar [10] = type Memory, range 64, base 0xf9bf0000, size 65536, enabled
cbb0@pci0:3:1:0: class=0x060700 card=0x01fe1028 chip=0x71351217 rev=0x21
hdr=0x02
vendor = 'O2 Micro Inc'
device = 'OZ711EZ1 MemoryCardBus Controller'
class = bridge
subclass = PCI-CardBus
bar [10] = type Memory, range 32, base 0xf9a00000, size 4096, enabled
fwohci0@pci0:3:1:4: class=0x0c0010 card=0x01fe1028 chip=0x00f71217
rev=0x02 hdr=0x00
vendor = 'O2 Micro Inc'
device = '0x00f71217 1394 Open Host Controller Interface'
class = serial bus
subclass = FireWire
bar [10] = type Memory, range 32, base 0xf9aff000, size 4096, enabled
bar [14] = type Memory, range 32, base 0xf9afe800, size 2048, enabled

and follow your intrudction.still pain me :(

(++) Using config file: "xorg.conf1"
drm0: <NVidia Display Adapter> on vgapci0
info: [drm] Detected an NV50 generation card (0x086900a2)
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] Initialized nouveau 0.0.12 20060213
error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
drm0: [ITHREAD]
info: [drm] Allocating FIFO number 1
error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII,
invalid/inactiv
e channel id 128
info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo:
[drm] , nSt
atus:info: [drm]
info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data
0x00000000:0x00
000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1:
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2:
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000
error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000
info: [drm] nouveau_fifo_alloc: initialised FIFO 1
info: [drm] PFIFO_DMA_PUSHER - Ch 1
(EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional
informati
on.

info: [drm] nouveau_fifo_free: freeing fifo 1
error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1
before d
estroy.Prepare for strangeness..
info: [drm] PFIFO_DMA_PUSHER - Ch 127
vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1

>   
>> (II) Loading sub module "int10"
>> (II) LoadModule: "int10"
>> (II) Loading /usr/local/lib/xorg/modules//libint10.so
>> (II) Module int10: vendor="X.Org Foundation"
>> 	compiled for 1.5.99.902, module version = 1.0.0
>> 	ABI class: X.Org Video Driver, version 5.0
>> (II) NOUVEAU(0): Initializing int10
>> (==) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already clear
>> (==) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already clear
>> (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000
>> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
>> drmOpenDevice: node name is /dev/dri/card0
>> drmOpenDevice: open result is 10, (OK)
>> drmOpenDevice: node name is /dev/dri/card0
>> drmOpenDevice: open result is 10, (OK)
>> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
>> drmOpenDevice: node name is /dev/dri/card0
>> drmOpenDevice: open result is 10, (OK)
>> drmOpenByBusid: drmOpenMinor returns 10
>> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
>> (II) [drm] DRM interface version 1.2
>> (II) [drm] DRM open master succeeded.
>> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12
>> (--) NOUVEAU(0): [drm] kernel modesetting not available
>> (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3
>> (II) NOUVEAU(0): Creating default Display subsection in Screen section
>> 	"Default Screen Section" for depth/fbbpp 24/32
>> (==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32
>> (==) NOUVEAU(0): RGB weight 888
>> (==) NOUVEAU(0): Default visual is TrueColor
>> (II) Loading sub module "vgahw"
>> (II) LoadModule: "vgahw"
>> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so
>> (II) Module vgahw: vendor="X.Org Foundation"
>> 	compiled for 1.5.99.902, module version = 0.1.0
>> 	ABI class: X.Org Video Driver, version 5.0
>> (==) NOUVEAU(0): Randr1.2 support enabled
>> (==) NOUVEAU(0): Using HW cursor
>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
>> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
>> (II) UnloadModule: "nouveau"
>> (II) UnloadModule: "vgahw"
>> (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so
>> (II) UnloadModule: "int10"
>> (II) Unloading /usr/local/lib/xorg/modules//libint10.so
>> (EE) Screen(s) found, but none have a usable configuration.
>>
>> Fatal server error:
>> no screens found
>>
>> Please consult the The X.Org Foundation support 
>> 	 at http://wiki.x.org
>>  for help. 
>> Please also check the log file at "/var/log/Xorg.0.log" for additional information.
>>
>>     

From doconnor at gsoft.com.au  Mon Mar 23 22:07:49 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Mon Mar 23 22:07:57 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C83673.3000604@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
Message-ID: <200903241537.36515.doconnor@gsoft.com.au>

On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
> I'm trying to migrate a filesystem from one disk to another using:
>
>     dump a0hCf 0 32 - /old | restore -rf -
>
> (/old is already mounted read-only). The process runs for a while and
> then stops with:
>
>     [...]
>       DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
>       DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
>       DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
>     unknown tape header type 1853384566
>     abort? [yn]
>
> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
> dump's output?

What happens if you don't use the cache?
Also, do you really want -h 0? That means you skip nodump marked files at a 
level 0 dump.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090324/380d8cc3/attachment.pgp
From doconnor at gsoft.com.au  Mon Mar 23 22:41:36 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Mon Mar 23 22:41:49 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C83673.3000604@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
Message-ID: <200903241537.36515.doconnor@gsoft.com.au>

On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
> I'm trying to migrate a filesystem from one disk to another using:
>
>     dump a0hCf 0 32 - /old | restore -rf -
>
> (/old is already mounted read-only). The process runs for a while and
> then stops with:
>
>     [...]
>       DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
>       DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
>       DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
>     unknown tape header type 1853384566
>     abort? [yn]
>
> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
> dump's output?

What happens if you don't use the cache?
Also, do you really want -h 0? That means you skip nodump marked files at a 
level 0 dump.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090324/380d8cc3/attachment-0001.pgp
From mi+thun at aldan.algebra.com  Tue Mar 24 00:02:47 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 00:02:55 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <200903241537.36515.doconnor@gsoft.com.au>
References: <49C83673.3000604@aldan.algebra.com>
	<200903241537.36515.doconnor@gsoft.com.au>
Message-ID: <49C87E0D.5090501@aldan.algebra.com>

Daniel O'Connor ???????(??):
> On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
>   
>> I'm trying to migrate a filesystem from one disk to another using:
>>
>>     dump a0hCf 0 32 - /old | restore -rf -
>>
>> (/old is already mounted read-only). The process runs for a while and
>> then stops with:
>>
>>     [...]
>>       DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
>>       DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
>>       DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
>>     unknown tape header type 1853384566
>>     abort? [yn]
>>
>> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
>> dump's output?
>>     
>
> What happens if you don't use the cache?
>   
No big difference:

    dump a0f  - /old | restore -rf -
    [...]
      DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
      DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
      DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
    unknown tape header type -621260722
    abort? [yn]

Looks like a junk value somewhere... Unitialized variable or some such.

    -mi

From spork at bway.net  Tue Mar 24 00:31:47 2009
From: spork at bway.net (Charles Sprickman)
Date: Tue Mar 24 00:31:54 2009
Subject: setting quotas from inside a jail
Message-ID: <alpine.OSX.2.00.0903240253550.75858@office-dhcp-35.bway.net>

Hello all,

The subject describes my goal.  I'm aware of the usual caveats - if 
there's more than one jail, no UID overlap, this will really only work in 
one jail if all jails are on the same filesystem, etc.

I found a very, very old post that has an... interesting... technique:

http://groups.google.com/group/mpc.lists.freebsd.hackers/msg/2b92fc66ac72efa6?hl=en

It actually works.  "It" being I suppose the fstab trickery in the jail. 
I need to test this some more, but it does seem possible to edit quotas 
inside the jail, which is my basic goal.  I don't want my provisioning box 
to have to hit the host just to alter quotas in one jail that needs them.

Just looking for any warnings/caveats about the above and what might be 
different 6+ years later...

Thanks,

Charles

___
Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet - www.bway.net
spork@bway.net - 212.655.9344

From danny at cs.huji.ac.il  Tue Mar 24 00:44:28 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Tue Mar 24 00:44:36 2009
Subject: dump | restore fails: unknown tape header type 1853384566 
In-Reply-To: <49C87E0D.5090501@aldan.algebra.com> 
References: <49C83673.3000604@aldan.algebra.com>
	<200903241537.36515.doconnor@gsoft.com.au>
	<49C87E0D.5090501@aldan.algebra.com>
Message-ID: <E1Lm1J9-000Ah6-Kf@kabab.cs.huji.ac.il>

> Daniel O'Connor ???????(??):
> 
> On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
> 
>   
> >> I'm trying to migrate a filesystem from one disk to another using:
> >>
> >>     dump a0hCf 0 32 - /old | restore -rf -
> >>
> >> (/old is already mounted read-only). The process runs for a while and> >> then stops with:
> >>
> >>     [...]
> >>       DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
> >>       DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
> >>       DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
> >>     unknown tape header type 1853384566> >>     abort? [yn]
> >>
> >> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
> >> dump's output?
> >>     
> >>
 > What happens if you don't use the cache?
> >   
> No big difference:
> >     dump a0f  - /old | restore -rf -
>     [...]
>       DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>       DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>       DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>     unknown tape header type -621260722>     abort? [yn]
> 
> Looks like a junk value somewhere... Unitialized variable or some such.
> 
can you try splitting it in 2, ie no pipe?
	dump a0f some.file /old (or dump 0f - /old | gzip -c > file.dump.gz)
	restore rf some.file

danny


From rnoland at FreeBSD.org  Tue Mar 24 01:16:58 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Mar 24 01:17:19 2009
Subject: [PREVIEW] Nouveau on FreeBSD (Take 2)
In-Reply-To: <49C85F4E.5050002@gddsn.org.cn>
References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn>
	<49C6E5C6.60306@gddsn.org.cn>
	<1237798914.2110.24.camel@balrog.2hip.net>
	<49C85F4E.5050002@gddsn.org.cn>
Message-ID: <1237882591.1771.26.camel@balrog.2hip.net>

On Tue, 2009-03-24 at 12:19 +0800, wsk wrote:
> Robert Noland wrote:
> > On Mon, 2009-03-23 at 09:28 +0800, wsk wrote:
> >   
> >>> Ok, this patch should work on NV50 chips also.
> >>>       
> >>> What you get is EXA and Xv.
> >>>       
> >>> You still need:
> >>>       
> >>> A recent -CURRENT or -STABLE.
> >>>       
> >>> git master of libdrm and xf86-video-nouveau.
> >>>       
> >>> This patch.
> >>>       
> >>> Things I've figured out since the last patch...
> >>>       
> >>> On NV50 class hardware you need to have a compositing manager running
> >>> for Xv to work.  That means xcompmgr, metacity with composite enabled,
> >>> xfce (rumored to work as well, haven't tried).  If your running Gnome
> >>> with metacity, open gconf-editor and go to apps->metacity->general and
> >>> check the composite box.
> >>>       
> >>> On NV40 class hardware, you don't need the composite manager.  In fact
> >>> (at least with Xserver 1.6 which I'm running now), if a composite
> >>> manager is enabled, I'm seeing high cpu utilization from Xorg under some
> >>> circumstances.  I don't think this is a drm issue, but still an issue.
> >>> For me, if I start a video using mplayer in an xterm, cpu is fine as
> >>> long as that xterm is the foreground window.  If it is not the
> >>> foreground window, even if it isn't obscured I see the cpu utilization.
> >>> Disabling the composite manager makes everything fine.
> >>>       
> >>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch <http://people.freebsd.org/%7Ernoland/drm-nouveau-032109.patch>
> >>>       
> >>> robert.
> >>>       
> >> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation.
> >> It is not supported in any way.
> >> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> >> Select the "xorg" product for bugs you find in this release.
> >> Before reporting bugs in pre-release versions please check the
> >> latest version in the X.Org Foundation git repository.
> >> See http://wiki.x.org/wiki/GitPage for git access instructions.
> >>
> >> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> >> Release Date: 2009-1-30
> >> X Protocol Version 11, Revision 0
> >> Build Operating System: FreeBSD 7.1-STABLE amd64
> >> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE
> >> RELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/sr
> >> c/sys/WSK amd64
> >> Build Date: 06 February 2009  04:22:44PM
> >>
> >>         Before reporting problems, check http://wiki.x.org
> >>         to make sure that you have the latest version.
> >> Markers: (--) probed, (**) from config file, (==) default setting,
> >>         (++) from command line, (!!) notice, (II) informational,
> >>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> >> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> >> ing config file: "xorg.conf1"
> >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >> drm0: [ITHREAD]
> >> info: [drm] Allocating FIFO number 1
> >> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
> >> info: [drm] PFIFO_DMA_PUSHER - Ch 1
> >> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> >> (EE) Screen(s) found, but none have a usable configuration.
> >>
> >> Fatal server error:
> >> no screens found
> >>
> >> Please consult the The X.Org Foundation support
> >>          at http://wiki.x.org
> >>  for help.
> >> Please also check the log file at "/var/log/Xorg.0.log" for additional informati
> >> on.
> >>
> >> info: [drm] nouveau_fifo_free: freeing fifo 1
> >> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before
> >> destroy.Prepare for strangeness..
> >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>
> >> what can i do ?
> >>
> >>
> >>
> >>
> >> plain text document attachment (Xorg.0.log)
> >> This is a pre-release version of the X server from The X.Org Foundation.
> >> It is not supported in any way.
> >> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> >> Select the "xorg" product for bugs you find in this release.
> >> Before reporting bugs in pre-release versions please check the
> >> latest version in the X.Org Foundation git repository.
> >> See http://wiki.x.org/wiki/GitPage for git access instructions.
> >>
> >> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> >> Release Date: 2009-1-30
> >> X Protocol Version 11, Revision 0
> >> Build Operating System: FreeBSD 7.1-STABLE amd64 
> >> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64
> >> Build Date: 06 February 2009  04:22:44PM
> >>  
> >> 	Before reporting problems, check http://wiki.x.org
> >> 	to make sure that you have the latest version.
> >> Markers: (--) probed, (**) from config file, (==) default setting,
> >> 	(++) from command line, (!!) notice, (II) informational,
> >> 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> >> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> >> (++) Using config file: "xorg.conf1"
> >> (==) No Layout section.  Using the first Screen section.
> >> (==) No screen section available. Using defaults.
> >> (**) |-->Screen "Default Screen Section" (0)
> >> (**) |   |-->Monitor "<default monitor>"
> >> (==) No device specified for screen "Default Screen Section".
> >> 	Using the first device section listed.
> >> (**) |   |-->Device "Card0"
> >> (==) No monitor specified for screen "Default Screen Section".
> >> 	Using a default monitor configuration.
> >> (==) Automatically adding devices
> >> (==) Automatically enabling devices
> >> (==) No FontPath specified.  Using compiled-in default.
> >> (==) FontPath set to:
> >> 	built-ins
> >> (==) ModulePath set to "/usr/local/lib/xorg/modules"
> >> (II) Cannot locate a core pointer device.
> >> (II) Cannot locate a core keyboard device.
> >> (II) The server relies on HAL to provide the list of input devices.
> >> 	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
> >> (II) Loader magic: 0xb20
> >> (II) Module ABI versions:
> >> 	X.Org ANSI C Emulation: 0.4
> >> 	X.Org Video Driver: 5.0
> >> 	X.Org XInput driver : 4.0
> >> 	X.Org Server Extension : 2.0
> >> (II) Loader running on freebsd
> >> (--) Using syscons driver with X support (version 2.0)
> >> (--) using VT number 9
> >>
> >> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536
> >>     
> >
> > Ok, thats a new one...
> >
> >   
> >> (II) System resource ranges:
> >> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> >> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> >> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> >> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> >> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> >> (II) LoadModule: "extmod"
> >> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
> >> (II) Module extmod: vendor="X.Org Foundation"
> >> 	compiled for 1.5.99.902, module version = 1.0.0
> >> 	Module class: X.Org Server Extension
> >> 	ABI class: X.Org Server Extension, version 2.0
> >> (II) Loading extension MIT-SCREEN-SAVER
> >> (II) Loading extension XFree86-VidModeExtension
> >> (II) Loading extension XFree86-DGA
> >> (II) Loading extension DPMS
> >> (II) Loading extension XVideo
> >> (II) Loading extension XVideo-MotionCompensation
> >> (II) Loading extension X-Resource
> >> (II) LoadModule: "dbe"
> >> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
> >> (II) Module dbe: vendor="X.Org Foundation"
> >> 	compiled for 1.5.99.902, module version = 1.0.0
> >> 	Module class: X.Org Server Extension
> >> 	ABI class: X.Org Server Extension, version 2.0
> >> (II) Loading extension DOUBLE-BUFFER
> >> (II) LoadModule: "glx"
> >> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
> >> (II) Module glx: vendor="X.Org Foundation"
> >> 	compiled for 1.5.99.902, module version = 1.0.0
> >> 	ABI class: X.Org Server Extension, version 2.0
> >> (==) AIGLX disabled
> >> (==) Exporting typical set of GLX visuals
> >> (II) Loading extension GLX
> >> (II) LoadModule: "record"
> >> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
> >> (II) Module record: vendor="X.Org Foundation"
> >> 	compiled for 1.5.99.902, module version = 1.13.0
> >> 	Module class: X.Org Server Extension
> >> 	ABI class: X.Org Server Extension, version 2.0
> >> (II) Loading extension RECORD
> >> (II) LoadModule: "dri"
> >> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
> >> (II) Module dri: vendor="X.Org Foundation"
> >> 	compiled for 1.5.99.902, module version = 1.0.0
> >> 	ABI class: X.Org Server Extension, version 2.0
> >> (II) Loading extension XFree86-DRI
> >> (II) LoadModule: "nouveau"
> >> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so
> >> (II) Module nouveau: vendor="X.Org Foundation"
> >> 	compiled for 1.5.99.902, module version = 0.0.10
> >> 	Module class: X.Org Video Driver
> >> 	ABI class: X.Org Video Driver, version 5.0
> >> (II) NOUVEAU driver Date:   Wed Mar 18 09:36:33 2009 +1000
> >> (II) NOUVEAU driver for NVIDIA chipset families :
> >> 	RIVA TNT    (NV04)
> >> 	RIVA TNT2   (NV05)
> >> 	GeForce 256 (NV10)
> >> 	GeForce 2   (NV11, NV15)
> >> 	GeForce 4MX (NV17, NV18)
> >> 	GeForce 3   (NV20)
> >> 	GeForce 4Ti (NV25, NV28)
> >> 	GeForce FX  (NV3x)
> >> 	GeForce 6   (NV4x)
> >> 	GeForce 7   (G7x)
> >> 	GeForce 8   (G8x)
> >> (II) Primary Device is: PCI 01@00:00:0
> >> (II) resource ranges after probing:
> >> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> >> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> >> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> >> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> >> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> >> (--) NOUVEAU(0): Chipset: "NVIDIA NV86"
> >>     
> >
> > Hrm, NV86... I'll have to ask around about that.  Meanwhile can you send
> > me a pciconf -lvb which should at least show us the BAR configuration.
> >
> > Ok, my sources are telling me that this should work and that it is an
> > NV50, or at least should work the same...
> >
> > Also, just to be safe, please rebuild/reinstall devel/libpciaccess.  I'm
> > not sure if it may be trashing the BARs somehow.
> >
> > robert.
> >   
> 
> hostb0@pci0:0:0:0: class=0x060000 card=0x01fe1028 chip=0x2a008086
> rev=0x0c hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Mobile PM965/GM965/GL960 Express Processor to DRAM Controller'
> class = bridge
> subclass = HOST-PCI
> pcib1@pci0:0:1:0: class=0x060400 card=0x01fe1028 chip=0x2a018086
> rev=0x0c hdr=0x01
> vendor = 'Intel Corporation'
> device = 'Mobile PM965/GM965/GL960 Express PCIe Root Port'
> class = bridge
> subclass = PCI-PCI
> uhci0@pci0:0:26:0: class=0x0c0300 card=0x01fe1028 chip=0x28348086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) USB UHCI'
> class = serial bus
> subclass = USB
> bar [20] = type I/O Port, range 32, base 0x6f20, size 32, enabled
> uhci1@pci0:0:26:1: class=0x0c0300 card=0x01fe1028 chip=0x28358086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) USB UHCI'
> class = serial bus
> subclass = USB
> bar [20] = type I/O Port, range 32, base 0x6f00, size 32, enabled
> ehci0@pci0:0:26:7: class=0x0c0320 card=0x01fe1028 chip=0x283a8086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '81EC1043 (?) ICH8 Enhanced USB2 Enhanced Host Controller'
> class = serial bus
> subclass = USB
> bar [10] = type Memory, range 32, base 0xfed1c400, size 1024, enabled
> hdac0@pci0:0:27:0: class=0x040300 card=0x01fe1028 chip=0x284b8086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801H &SUBSYS_81EC1043&REV_02\3&11583659&0&D8'
> class = multimedia
> subclass = HDA
> bar [10] = type Memory, range 64, base 0xfebfc000, size 16384, enabled
> pcib2@pci0:0:28:0: class=0x060400 card=0x01fe1028 chip=0x283f8086
> rev=0x02 hdr=0x01
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) PCIe Port 1'
> class = bridge
> subclass = PCI-PCI
> pcib3@pci0:0:28:1: class=0x060400 card=0x01fe1028 chip=0x28418086
> rev=0x02 hdr=0x01
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) PCIe Port 2'
> class = bridge
> subclass = PCI-PCI
> pcib4@pci0:0:28:3: class=0x060400 card=0x01fe1028 chip=0x28458086
> rev=0x02 hdr=0x01
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) PCIe Port 4'
> class = bridge
> subclass = PCI-PCI
> pcib5@pci0:0:28:5: class=0x060400 card=0x01fe1028 chip=0x28498086
> rev=0x02 hdr=0x01
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) PCIe Port 6'
> class = bridge
> subclass = PCI-PCI
> uhci2@pci0:0:29:0: class=0x0c0300 card=0x01fe1028 chip=0x28308086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) USB UHCI'
> class = serial bus
> subclass = USB
> bar [20] = type I/O Port, range 32, base 0x6f80, size 32, enabled
> uhci3@pci0:0:29:1: class=0x0c0300 card=0x01fe1028 chip=0x28318086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) USB UHCI'
> class = serial bus
> subclass = USB
> bar [20] = type I/O Port, range 32, base 0x6f60, size 32, enabled
> uhci4@pci0:0:29:2: class=0x0c0300 card=0x01fe1028 chip=0x28328086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) USB UHCI'
> class = serial bus
> subclass = USB
> bar [20] = type I/O Port, range 32, base 0x6f40, size 32, enabled
> ehci1@pci0:0:29:7: class=0x0c0320 card=0x01fe1028 chip=0x28368086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) USB2 EHCI'
> class = serial bus
> subclass = USB
> bar [10] = type Memory, range 32, base 0xfed1c000, size 1024, enabled
> pcib6@pci0:0:30:0: class=0x060401 card=0x01fe1028 chip=0x24488086
> rev=0xf2 hdr=0x01
> vendor = 'Intel Corporation'
> device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge'
> class = bridge
> subclass = PCI-PCI
> isab0@pci0:0:31:0: class=0x060100 card=0x01fe1028 chip=0x28158086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'ICH8M-E (ICH8 Family) LPC Interface Controller'
> class = bridge
> subclass = PCI-ISA
> atapci0@pci0:0:31:1: class=0x01018a card=0x01fe1028 chip=0x28508086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) Ultra ATA Storage Controllers'
> class = mass storage
> subclass = ATA
> bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled
> bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled
> bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled
> bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled
> bar [20] = type I/O Port, range 32, base 0x6fa0, size 16, enabled
> atapci1@pci0:0:31:2: class=0x01018f card=0x01fe1028 chip=0x28288086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'ICH8M (ICH8 Family) 3 port SATA Controller'
> class = mass storage
> subclass = ATA
> bar [10] = type I/O Port, range 32, base 0x6eb0, size 8, enabled
> bar [14] = type I/O Port, range 32, base 0x6eb8, size 4, enabled
> bar [18] = type I/O Port, range 32, base 0x6ec0, size 8, enabled
> bar [1c] = type I/O Port, range 32, base 0x6ec8, size 4, enabled
> bar [20] = type I/O Port, range 32, base 0x6ee0, size 16, enabled
> bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled
> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086
> rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82801H (ICH8 Family) SMBus Controller'
> class = serial bus
> subclass = SMBus
> bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled
> bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled
> vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de
> rev=0xa1 hdr=0x00
> vendor = 'Nvidia Corp'
> device = 'Unknown nVidia Quadro FX 570M'
> class = display
> subclass = VGA
> bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled

Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up.  BAR 1
should be your framebuffer and should be where most of your memory is.
(This is the memory the tell you about when you buy the card, 256M,
512M, etc.)  It should probably be a 64bit BAR, which is why BAR 2 isn't
there.  We are going to need more details on your card...

> bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled

This one is BAR 3, which is used when it doesn't find BAR 1.

robert.

> bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled
> ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4
> rev=0x03 hdr=0x00
> vendor = 'Broadcom Corporation'
> device = 'BCM94321KFBG Broadcom 4321AGN 802.11a/b/g/draft-n Wi-Fi Solution'
> class = network
> bar [10] = type Memory, range 64, base 0xf9ffc000, size 16384, enabled
> bar [18] = type Prefetchable Memory, range 64, base 0xf0000000, size
> 1048576, enabled
> bge0@pci0:9:0:0: class=0x020000 card=0x01fe1028 chip=0x167314e4 rev=0x02
> hdr=0x00
> vendor = 'Broadcom Corporation'
> device = 'B57xx Broadcom NetXtreme Gigabit Ethernet'
> class = network
> subclass = ethernet
> bar [10] = type Memory, range 64, base 0xf9bf0000, size 65536, enabled
> cbb0@pci0:3:1:0: class=0x060700 card=0x01fe1028 chip=0x71351217 rev=0x21
> hdr=0x02
> vendor = 'O2 Micro Inc'
> device = 'OZ711EZ1 MemoryCardBus Controller'
> class = bridge
> subclass = PCI-CardBus
> bar [10] = type Memory, range 32, base 0xf9a00000, size 4096, enabled
> fwohci0@pci0:3:1:4: class=0x0c0010 card=0x01fe1028 chip=0x00f71217
> rev=0x02 hdr=0x00
> vendor = 'O2 Micro Inc'
> device = '0x00f71217 1394 Open Host Controller Interface'
> class = serial bus
> subclass = FireWire
> bar [10] = type Memory, range 32, base 0xf9aff000, size 4096, enabled
> bar [14] = type Memory, range 32, base 0xf9afe800, size 2048, enabled
> 
> and follow your intrudction.still pain me :(
> 
> (++) Using config file: "xorg.conf1"
> drm0: <NVidia Display Adapter> on vgapci0
> info: [drm] Detected an NV50 generation card (0x086900a2)
> vgapci0: child drm0 requested pci_enable_busmaster
> info: [drm] Initialized nouveau 0.0.12 20060213
> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> drm0: [ITHREAD]
> info: [drm] Allocating FIFO number 1
> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII,
> invalid/inactiv
> e channel id 128
> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo:
> [drm] , nSt
> atus:info: [drm]
> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data
> 0x00000000:0x00
> 000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1:
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2:
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000
> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000
> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
> info: [drm] PFIFO_DMA_PUSHER - Ch 1
> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> (EE) Screen(s) found, but none have a usable configuration.
> 
> Fatal server error:
> no screens found
> 
> Please consult the The X.Org Foundation support
> at http://wiki.x.org
> for help.
> Please also check the log file at "/var/log/Xorg.0.log" for additional
> informati
> on.
> 
> info: [drm] nouveau_fifo_free: freeing fifo 1
> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1
> before d
> estroy.Prepare for strangeness..
> info: [drm] PFIFO_DMA_PUSHER - Ch 127
> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> 
> >   
> >> (II) Loading sub module "int10"
> >> (II) LoadModule: "int10"
> >> (II) Loading /usr/local/lib/xorg/modules//libint10.so
> >> (II) Module int10: vendor="X.Org Foundation"
> >> 	compiled for 1.5.99.902, module version = 1.0.0
> >> 	ABI class: X.Org Video Driver, version 5.0
> >> (II) NOUVEAU(0): Initializing int10
> >> (==) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already clear
> >> (==) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already clear
> >> (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000
> >> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
> >> drmOpenDevice: node name is /dev/dri/card0
> >> drmOpenDevice: open result is 10, (OK)
> >> drmOpenDevice: node name is /dev/dri/card0
> >> drmOpenDevice: open result is 10, (OK)
> >> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
> >> drmOpenDevice: node name is /dev/dri/card0
> >> drmOpenDevice: open result is 10, (OK)
> >> drmOpenByBusid: drmOpenMinor returns 10
> >> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
> >> (II) [drm] DRM interface version 1.2
> >> (II) [drm] DRM open master succeeded.
> >> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12
> >> (--) NOUVEAU(0): [drm] kernel modesetting not available
> >> (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3
> >> (II) NOUVEAU(0): Creating default Display subsection in Screen section
> >> 	"Default Screen Section" for depth/fbbpp 24/32
> >> (==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32
> >> (==) NOUVEAU(0): RGB weight 888
> >> (==) NOUVEAU(0): Default visual is TrueColor
> >> (II) Loading sub module "vgahw"
> >> (II) LoadModule: "vgahw"
> >> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so
> >> (II) Module vgahw: vendor="X.Org Foundation"
> >> 	compiled for 1.5.99.902, module version = 0.1.0
> >> 	ABI class: X.Org Video Driver, version 5.0
> >> (==) NOUVEAU(0): Randr1.2 support enabled
> >> (==) NOUVEAU(0): Using HW cursor
> >> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> >> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
> >> (II) UnloadModule: "nouveau"
> >> (II) UnloadModule: "vgahw"
> >> (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so
> >> (II) UnloadModule: "int10"
> >> (II) Unloading /usr/local/lib/xorg/modules//libint10.so
> >> (EE) Screen(s) found, but none have a usable configuration.
> >>
> >> Fatal server error:
> >> no screens found
> >>
> >> Please consult the The X.Org Foundation support 
> >> 	 at http://wiki.x.org
> >>  for help. 
> >> Please also check the log file at "/var/log/Xorg.0.log" for additional information.
> >>
> >>     
> 
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090324/d390e9eb/attachment.pgp
From danny at cs.huji.ac.il  Tue Mar 24 02:57:50 2009
From: danny at cs.huji.ac.il (Danny Braniss)
Date: Tue Mar 24 02:58:01 2009
Subject: Intel Integrated RAID iir not working under 7.2
Message-ID: <E1Lm3OG-000Cze-Mj@kabab.cs.huji.ac.il>

Hi,
After turning debuging on, it seems that the iir driver
is loosing an interrupt while probing:
...
gdt_next(0xc7666000)
gdt_mpr_test_busy(0xc7666000) gdt_intr(0xc7666000)
gdt_mpr_get_status(0xc7666000) gdt_mpr_intr(0xc7666000) 
gdt_free_ccb(0xc7666000, 0xc767e444)
gdt_sync_event(0xc7666000, 3, 5, 0xc767e444)
gdt_next(0xc7666000)
gdt_mpr_test_busy(0xc7666000) run_interrupt_driven_hooks: still waiting after 
60 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
panic: run_interrupt_driven_config_hooks: waited too long

btw, older (7.0/7.1) still works.
any ideas?
thanks,
	danny


From peter at pean.org  Tue Mar 24 05:56:15 2009
From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=)
Date: Tue Mar 24 05:56:22 2009
Subject: LSI Logic raid status
Message-ID: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>

Hi,

I have a LSI Logic sata/sas raid running, is there a way to see the  
state of
the volume, like optimal, degraded or resyncing?

I've tried several commands with camcontrol but I cant figure it out.

--
Peter Ankerst?l
peter@pean.org
http://www.pean.org/

From ruben at verweg.com  Tue Mar 24 06:08:23 2009
From: ruben at verweg.com (Ruben van Staveren)
Date: Tue Mar 24 06:08:30 2009
Subject: LSI Logic raid status
In-Reply-To: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>
Message-ID: <61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>


On 24 Mar 2009, at 13:40, Peter Ankerst?l wrote:

> Hi,
>
> I have a LSI Logic sata/sas raid running, is there a way to see the  
> state of
> the volume, like optimal, degraded or resyncing?

There is sysutils/linux-megacli

Yes, looks like ports/130505 is still pending unfortunately

>
> I've tried several commands with camcontrol but I cant figure it out.
>
> --
> Peter Ankerst?l
> peter@pean.org
> http://www.pean.org/
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "
>

Regards,
	Ruben
From peter at pean.org  Tue Mar 24 06:20:35 2009
From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=)
Date: Tue Mar 24 06:20:41 2009
Subject: LSI Logic raid status
In-Reply-To: <61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>
	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>
Message-ID: <F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>


On Mar 24, 2009, at 2:08 PM, Ruben van Staveren wrote:

>
> On 24 Mar 2009, at 13:40, Peter Ankerst?l wrote:
>
>> Hi,
>>
>> I have a LSI Logic sata/sas raid running, is there a way to see the  
>> state of
>> the volume, like optimal, degraded or resyncing?
>
> There is sysutils/linux-megacli
>
Sorry about that. This is not megaraid its the mpt driver.
LSI SAS3041E-R PCI-e

mpt0: <LSILogic SAS/SATA Adapter> port 0x2000-0x20ff mem  
0xd0210000-0xd0213fff,0xd0200000-0xd020ffff irq 16 at device 0.0 on pci3
mpt0: [ITHREAD]
mpt0: MPI Version=1.5.19.0
mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
mpt0: 1 Active Volume (2 Max)
mpt0: 2 Hidden Drive Members (14 Max)

--
Peter Ankerst?l
peter@pean.org
http://www.pean.org/

From nathanael at webair.com  Tue Mar 24 08:39:24 2009
From: nathanael at webair.com (Nathanael Jean-Francois)
Date: Tue Mar 24 08:39:31 2009
Subject: 7.1 stable panics 
Message-ID: <60041.24.103.225.18.1237908126.squirrel@staff.webair.com>

Hello all,

I've been getting some panics with a 7.1 stable machine from March 14th.
I've not been able to determine the cause nor reproduce them at will.
Here's a backtrace from the latest panic on March 23rd. Let me know if any
more information is needed. Thanks.

Unread portion of the kernel message buffer:
panic: lock (sleep mutex) Giant not locked @
/usr/src/sys/kern/kern_ntptime.c:965
cpuid = 1
Uptime: 1d15h34m6s
Physical memory: 2034 MB
Dumping 377 MB: 362 346 330 314 298 282 266 250 234 218 202 186 170 154
138 122 106 90 74 58 42em0: watchdog timeout -- resetting
<5>em0: link state changed to DOWN
 26 10

#0  doadump () at pcpu.h:195
195             __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) list
190     static __inline struct thread *
191     __curthread(void)
192     {
193             struct thread *td;
194
195             __asm __volatile("movq %%gs:0,%0" : "=r" (td));
196             return (td);
197     }
198     #define curthread               (__curthread())
199
(kgdb) backtrace
#0  doadump () at pcpu.h:195
#1  0x0000000000000104 in ?? ()
#2  0xffffffff804e6fc2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418
#3  0xffffffff804e73f2 in panic (fmt=0x104 <Address 0x104 out of bounds>)
at /usr/src/sys/kern/kern_shutdown.c:574
#4  0xffffffff805218b6 in witness_unlock (lock=0xffffffff80b0a400,
flags=8, file=0x0, line=965) at /usr/src/sys/kern/subr_witness.c:1284
#5  0xffffffff804dadb2 in _mtx_unlock_flags (m=0xffffffff80b0a400, opts=0,
file=0xffffffff8087a008 "/usr/src/sys/kern/kern_ntptime.c", line=965)
    at /usr/src/sys/kern/kern_mutex.c:203
#6  0xffffffff804dc062 in kern_adjtime (td=0xffffffff80884bd0,
delta=0x674, olddelta=Variable "olddelta" is not available.
) at /usr/src/sys/kern/kern_ntptime.c:965
#7  0xffffff00019cf870 in ?? ()
#8  0x00000000000005a8 in ?? ()
#9  0xffffffff805430b6 in soreceive_generic (so=0xffffff0078a9f600,
psa=0x0, uio=0xfffffffebe695b10, mp0=Variable "mp0" is not available.
) at /usr/src/sys/kern/uipc_socket.c:1652
#10 0xffffffff80523e6d in dofileread (td=0xffffff000181b000, fd=3,
fp=0xffffff00016af200, auio=0xfffffffebe695b10, offset=Variable "offset"
is not available.
) at file.h:245
#11 0xffffffff805241de in kern_readv (td=0xffffff000181b000, fd=3,
auio=0xfffffffebe695b10) at /usr/src/sys/kern/sys_generic.c:192
#12 0xffffffff805242cc in read (td=0x0, uap=0x0) at
/usr/src/sys/kern/sys_generic.c:108
#13 0xffffffff8079d0dc in syscall (frame=0xfffffffebe695c80) at
/usr/src/sys/amd64/amd64/trap.c:907
#14 0xffffffff80781cbb in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:330
#15 0x000000080076ad7c in ?? ()
Previous frame inner to this frame (corrupt stack?)



From pluknet at gmail.com  Tue Mar 24 08:59:59 2009
From: pluknet at gmail.com (pluknet)
Date: Tue Mar 24 09:00:06 2009
Subject: sysctl net.isr overflow
Message-ID: <a31046fc0903240859uc4ab62fwd06fd3019a15f79e@mail.gmail.com>

Hi.

I noticed strange values in the sysctl branch net.isr:
net.isr.direct: 0
net.isr.count: -458871841
net.isr.directed: 0
net.isr.deferred: -458850991
net.isr.queued: -19290738
net.isr.drop: 0
net.isr.swi_count: -1114653647

I'm running 6.2 release.

AFAICS those oids are still defined as SYSCTL_INT in HEAD.
So it may be still applicable (Sorry, I cannot test this on HEAD).


-- 
wbr,
pluknet
From mi+thun at aldan.algebra.com  Tue Mar 24 09:20:31 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 09:20:45 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <E1Lm1J9-000Ah6-Kf@kabab.cs.huji.ac.il>
References: <49C83673.3000604@aldan.algebra.com>
	<200903241537.36515.doconnor@gsoft.com.au>
	<49C87E0D.5090501@aldan.algebra.com>
	<E1Lm1J9-000Ah6-Kf@kabab.cs.huji.ac.il>
Message-ID: <49C90813.8070705@aldan.algebra.com>

Danny Braniss ???????(??):
>> Daniel O'Connor ???????(??):
>>
>> On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
>>
>>   
>>     
>>>> I'm trying to migrate a filesystem from one disk to another using:
>>>>
>>>>     dump a0hCf 0 32 - /old | restore -rf -
>>>>
>>>> (/old is already mounted read-only). The process runs for a while and> >> then stops with:
>>>>
>>>>     [...]
>>>>       DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
>>>>       DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
>>>>       DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
>>>>     unknown tape header type 1853384566> >>     abort? [yn]
>>>>
>>>> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
>>>> dump's output?
>>>>     
>>>>
>>>>         
>  > What happens if you don't use the cache?
>   
>>>   
>>>       
>> No big difference:
>>     
>>>     dump a0f  - /old | restore -rf -
>>>       
>>     [...]
>>       DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>>       DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>>       DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>>     unknown tape header type -621260722>     abort? [yn]
>>
>> Looks like a junk value somewhere... Unitialized variable or some such.
>>
>>     
> can you try splitting it in 2, ie no pipe?
> 	dump a0f some.file /old (or dump 0f - /old | gzip -c > file.dump.gz)
> 	restore rf some.file
>
> danny
>   
Well, the first part (the dump) runs almost to the completion, but hangs 
at the very end for some reason:

    dump 0aCf 64  /ibm/ibmo.0.2009-03-24.dump /old
      DUMP: WARNING: should use -L when dumping live read-write filesystems!
      DUMP: Date of this level 0 dump: Tue Mar 24 05:59:27 2009
      DUMP: Date of last level 0 dump: the epoch
      DUMP: Dumping /dev/ad2s1e (/ibmo) to /ibm/ibmo.0.2009-03-24.dump
      DUMP: mapping (Pass I) [regular files]
      DUMP: Cache 64 MB, blocksize = 65536
      DUMP: mapping (Pass II) [directories]
      DUMP: estimated 152357442 tape blocks.
      DUMP: dumping (Pass III) [directories]
      DUMP: dumping (Pass IV) [regular files]
      DUMP: 0.83% done, finished in 9:59 at Tue Mar 24 16:04:19 2009
      DUMP: 2.74% done, finished in 5:55 at Tue Mar 24 12:05:07 2009
      DUMP: 4.66% done, finished in 5:06 at Tue Mar 24 11:21:27 2009
      DUMP: 6.58% done, finished in 4:43 at Tue Mar 24 11:03:37 2009
    ...
      DUMP: 91.54% done, finished in 0:23 at Tue Mar 24 10:38:15 2009
      DUMP: 93.41% done, finished in 0:18 at Tue Mar 24 10:38:02 2009
      DUMP: 95.27% done, finished in 0:13 at Tue Mar 24 10:37:50 2009
      DUMP: 97.15% done, finished in 0:07 at Tue Mar 24 10:37:36 2009
      DUMP: 99.03% done, finished in 0:02 at Tue Mar 24 10:37:23 2009
      DUMP: DUMP: 152769349 tape blocks on 1 volume
      DUMP: finished in 16706 seconds, throughput 9144 KBytes/sec
    [... Hang ...]
    load: 0.18  cmd: dump 10105 [sbwait] 72.53u 383.14s 0% 73048k
    load: 0.19  cmd: dump 10102 [sbwait] 164.93u 314.87s 0% 75008k
    load: 0.10  cmd: dump 10102 [running] 164.93u 314.87s 0% 75008k

The timestamp on the output file is, indeed, 10:38 and the dumping 
process is hanging ever since then (over 90 minutes already).

Yours,

    -mi

From freebsd07 at wayne47.com  Tue Mar 24 10:32:02 2009
From: freebsd07 at wayne47.com (Michael R. Wayne)
Date: Tue Mar 24 10:32:09 2009
Subject: setting quotas from inside a jail
In-Reply-To: <alpine.OSX.2.00.0903240253550.75858@office-dhcp-35.bway.net>
References: <alpine.OSX.2.00.0903240253550.75858@office-dhcp-35.bway.net>
Message-ID: <20090324165215.GA79638@manor.msen.com>

On Tue, Mar 24, 2009 at 03:05:05AM -0400, Charles Sprickman wrote:
> 
> The subject describes my goal.  I'm aware of the usual caveats - if 
> there's more than one jail, no UID overlap, this will really only work in 
> one jail if all jails are on the same filesystem, etc.
> 
> I found a very, very old post that has an... interesting... technique:
> 
> http://groups.google.com/group/mpc.lists.freebsd.hackers/msg/2b92fc66ac72efa6?hl=en
> 
> It actually works.  "It" being I suppose the fstab trickery in the jail. 
> I need to test this some more, but it does seem possible to edit quotas 
> inside the jail, which is my basic goal.  I don't want my provisioning box 
> to have to hit the host just to alter quotas in one jail that needs them.
> 
> Just looking for any warnings/caveats about the above and what might be 
> different 6+ years later...

That's my post.  Yes, we still do this.  It still works.  Over time,
sometimes things get out of sync.  If that happens, go to S, shut
off quotas, do a quotacheck, turn them back on.

/\/\ \/\/
From mi+thun at aldan.algebra.com  Tue Mar 24 11:04:05 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 11:04:17 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <E1Lm1J9-000Ah6-Kf@kabab.cs.huji.ac.il>
References: <49C83673.3000604@aldan.algebra.com>
	<200903241537.36515.doconnor@gsoft.com.au>
	<49C87E0D.5090501@aldan.algebra.com>
	<E1Lm1J9-000Ah6-Kf@kabab.cs.huji.ac.il>
Message-ID: <49C92060.4060303@aldan.algebra.com>

Danny Braniss ???????(??):
> can you try splitting it in 2, ie no pipe?
> 	dump a0f some.file /old (or dump 0f - /old | gzip -c > file.dump.gz)
> 	restore rf some.file
>
>   
Same problem:

    restore -rf ibmo.0.2009-03-24.dump
    load: 0.55  cmd: restore 11303 [nbufkv] 3.53u 3.91s 4% 27980k
    unknown tape header type 213474529
    abort? [yn]

Please, advise. Thanks! Yours,

    -mi

From spork at bway.net  Tue Mar 24 12:00:17 2009
From: spork at bway.net (Charles Sprickman)
Date: Tue Mar 24 12:00:23 2009
Subject: LSI Logic raid status
In-Reply-To: <F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>
	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>
	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>
Message-ID: <754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>


On Mar 24, 2009, at 9:20 AM, Peter Ankerst?l wrote:

>
> On Mar 24, 2009, at 2:08 PM, Ruben van Staveren wrote:
>
>>
>> On 24 Mar 2009, at 13:40, Peter Ankerst?l wrote:
>>
>>> Hi,
>>>
>>> I have a LSI Logic sata/sas raid running, is there a way to see  
>>> the state of
>>> the volume, like optimal, degraded or resyncing?
>>
>> There is sysutils/linux-megacli
>>
> Sorry about that. This is not megaraid its the mpt driver.
> LSI SAS3041E-R PCI-e
>
> mpt0: <LSILogic SAS/SATA Adapter> port 0x2000-0x20ff mem  
> 0xd0210000-0xd0213fff,0xd0200000-0xd020ffff irq 16 at device 0.0 on  
> pci3
> mpt0: [ITHREAD]
> mpt0: MPI Version=1.5.19.0
> mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
> mpt0: 1 Active Volume (2 Max)
> mpt0: 2 Hidden Drive Members (14 Max)

While I haven't found a way to actually configure the thing in  
FreeBSD, the mpt
driver does make some information available via sysctl:

[spork@uniweb ~]$ sysctl -a|grep dev.mpt
dev.mpt.0.%desc: LSILogic SAS/SATA Adapter
dev.mpt.0.%driver: mpt
dev.mpt.0.%location: slot=8 function=0
dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0054 subvendor=0x1028  
subdevice=0x1f09 class=0x010000
dev.mpt.0.%parent: pci2
dev.mpt.0.debug: 3
dev.mpt.0.role: 1
dev.mpt.0.vol_member_wce: NC
dev.mpt.0.vol_queue_depth: 128
dev.mpt.0.vol_resync_rate: 0
dev.mpt.0.nonoptimal_volumes: 0

Don't test whether the "nonoptimal_volumes" parameter works, it does -
but if you pull a drive, FreeBSD likes to panic both on the loss of a  
disk
and then again when the drive is reconnected and the rebuild completes.
This is apparently some problem in the CAM layer, not the mpt driver,  
but
it's something to be aware of.  Scott Long has noted that this is being
worked on in 8.x.

Charles


>
>
> --
> Peter Ankerst?l
> peter@pean.org
> http://www.pean.org/
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
> "

Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet www.bway.net
spork@bway.net - 212.655.9344



From peter at pean.org  Tue Mar 24 12:11:34 2009
From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=)
Date: Tue Mar 24 12:11:43 2009
Subject: LSI Logic raid status
In-Reply-To: <754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>
	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>
	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>
	<754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>
Message-ID: <0B69CE4E-CC04-445B-9E84-C8E359136CCF@pean.org>


On Mar 24, 2009, at 8:00 PM, Charles Sprickman wrote:

>
>
> dev.mpt.0.nonoptimal_volumes: 0
>
> Don't test whether the "nonoptimal_volumes" parameter works, it does -
> but if you pull a drive, FreeBSD likes to panic both on the loss of  
> a disk
> and then again when the drive is reconnected and the rebuild  
> completes.
> This is apparently some problem in the CAM layer, not the mpt  
> driver, but
> it's something to be aware of.  Scott Long has noted that this is  
> being
> worked on in 8.x.


Yes, I tried to remove a drive today. Of course I need to see if it  
works properly
before using it "for real". It did, but just as you say it paniced  
when I pulled the
drive and when is was resynced. But it sound great if someone is  
working on
this problem!

--
Peter Ankerst?l
peter@pean.org
http://www.pean.org/

From karl at denninger.net  Tue Mar 24 12:27:44 2009
From: karl at denninger.net (Karl Denninger)
Date: Tue Mar 24 12:27:51 2009
Subject: LSI Logic raid status
In-Reply-To: <754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>
	<754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>
Message-ID: <49C92ED2.3080809@denninger.net>

Charles Sprickman wrote:
>>>
>>> There is sysutils/linux-megacli
>>>
>> Sorry about that. This is not megaraid its the mpt driver.
>> LSI SAS3041E-R PCI-e
>>
>> mpt0: <LSILogic SAS/SATA Adapter> port 0x2000-0x20ff mem 
>> 0xd0210000-0xd0213fff,0xd0200000-0xd020ffff irq 16 at device 0.0 on pci3
>> mpt0: [ITHREAD]
>> mpt0: MPI Version=1.5.19.0
>> mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )
>> mpt0: 1 Active Volume (2 Max)
>> mpt0: 2 Hidden Drive Members (14 Max)
>
> While I haven't found a way to actually configure the thing in 
> FreeBSD, the mpt
> driver does make some information available via sysctl:
>
> [spork@uniweb ~]$ sysctl -a|grep dev.mpt
> dev.mpt.0.%desc: LSILogic SAS/SATA Adapter
> dev.mpt.0.%driver: mpt
> dev.mpt.0.%location: slot=8 function=0
> dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0054 subvendor=0x1028 
> subdevice=0x1f09 class=0x010000
> dev.mpt.0.%parent: pci2
> dev.mpt.0.debug: 3
> dev.mpt.0.role: 1
> dev.mpt.0.vol_member_wce: NC
> dev.mpt.0.vol_queue_depth: 128
> dev.mpt.0.vol_resync_rate: 0
> dev.mpt.0.nonoptimal_volumes: 0
>
> Don't test whether the "nonoptimal_volumes" parameter works, it does -
> but if you pull a drive, FreeBSD likes to panic both on the loss of a 
> disk
> and then again when the drive is reconnected and the rebuild completes.
> This is apparently some problem in the CAM layer, not the mpt driver, but
> it's something to be aware of.  Scott Long has noted that this is being
> worked on in 8.x.
>
> Charles
The Linux megacli program does run.  You have to mount the Linux device 
filesystem (so it can "see" the control nodes) but it is fully 
functional and gives you command-line interactivity to the board.  You 
can absolutely configure and interact with it from FreeBSD.

The program is annoying as heck as by default it writes a logfile on 
EVERY INVOCATION, but it does the job and allows you to configure and 
maintain the board, which is kinda important as if it detects an error 
(e.g. failed unit) it will start beeping - the board has an audible 
alarm on it.

I have one of these boards - its quite nice and VERY fast - if someone 
wants it I would be willing to sell it (I've got the battery-backed RAM 
option on it too, which makes it MUCH faster; that's a 
usually-rather-expensive option)

-- 
--
Karl Denninger
karl@denninger.net


From peter at pean.org  Tue Mar 24 12:33:41 2009
From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=)
Date: Tue Mar 24 12:33:49 2009
Subject: LSI Logic raid status
In-Reply-To: <49C9326E.3070108@samsco.org>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>	<754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>
	<0B69CE4E-CC04-445B-9E84-C8E359136CCF@pean.org>
	<49C9326E.3070108@samsco.org>
Message-ID: <58260D6F-FBE8-49C5-918D-5EDB57BA794B@pean.org>


On Mar 24, 2009, at 8:20 PM, Scott Long wrote:

> Peter Ankerst?l wrote:
>> On Mar 24, 2009, at 8:00 PM, Charles Sprickman wrote:
>>>
>>>
>>> dev.mpt.0.nonoptimal_volumes: 0
>>>
>>> Don't test whether the "nonoptimal_volumes" parameter works, it  
>>> does -
>>> but if you pull a drive, FreeBSD likes to panic both on the loss  
>>> of a disk
>>> and then again when the drive is reconnected and the rebuild  
>>> completes.
>>> This is apparently some problem in the CAM layer, not the mpt  
>>> driver, but
>>> it's something to be aware of.  Scott Long has noted that this is  
>>> being
>>> worked on in 8.x.
>> Yes, I tried to remove a drive today. Of course I need to see if it  
>> works properly
>> before using it "for real". It did, but just as you say it paniced  
>> when I pulled the
>> drive and when is was resynced. But it sound great if someone is  
>> working on
>> this problem!
>
> The instability during a rebuild should be fixed in 7.2 (and 7- 
> stable as
> of about the last month).  If you can, please update your sources and
> let me know if it helps.
>
> As for actually monitoring and configuring arrays, that work is in
> progress.
>
> Scott

Im running RELENG_7 cvsuped and built like 15 hours ago. I still have  
this problem.
Please come back to me if you want some additional information about  
the setup.

--
Peter Ankerst?l
peter@pean.org
http://www.pean.org/

From scottl at samsco.org  Tue Mar 24 12:39:40 2009
From: scottl at samsco.org (Scott Long)
Date: Tue Mar 24 12:39:47 2009
Subject: LSI Logic raid status
In-Reply-To: <0B69CE4E-CC04-445B-9E84-C8E359136CCF@pean.org>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>	<754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>
	<0B69CE4E-CC04-445B-9E84-C8E359136CCF@pean.org>
Message-ID: <49C9326E.3070108@samsco.org>

Peter Ankerst?l wrote:
> 
> On Mar 24, 2009, at 8:00 PM, Charles Sprickman wrote:
> 
>>
>>
>> dev.mpt.0.nonoptimal_volumes: 0
>>
>> Don't test whether the "nonoptimal_volumes" parameter works, it does -
>> but if you pull a drive, FreeBSD likes to panic both on the loss of a 
>> disk
>> and then again when the drive is reconnected and the rebuild completes.
>> This is apparently some problem in the CAM layer, not the mpt driver, but
>> it's something to be aware of.  Scott Long has noted that this is being
>> worked on in 8.x.
> 
> 
> Yes, I tried to remove a drive today. Of course I need to see if it 
> works properly
> before using it "for real". It did, but just as you say it paniced when 
> I pulled the
> drive and when is was resynced. But it sound great if someone is working on
> this problem!
> 

The instability during a rebuild should be fixed in 7.2 (and 7-stable as
of about the last month).  If you can, please update your sources and
let me know if it helps.

As for actually monitoring and configuring arrays, that work is in
progress.

Scott
From peter at pean.org  Tue Mar 24 12:54:35 2009
From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=)
Date: Tue Mar 24 12:54:43 2009
Subject: LSI Logic raid status
In-Reply-To: <49C93983.4030306@ksu.ru>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>	<754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>	<0B69CE4E-CC04-445B-9E84-C8E359136CCF@pean.org>	<49C9326E.3070108@samsco.org>
	<58260D6F-FBE8-49C5-918D-5EDB57BA794B@pean.org>
	<49C93983.4030306@ksu.ru>
Message-ID: <14047DAC-9938-4FD3-A6E8-F8E720230089@pean.org>


On Mar 24, 2009, at 8:50 PM, Marat N.Afanasyev wrote:

>>>
>>>
>>> Scott
>> Im running RELENG_7 cvsuped and built like 15 hours ago. I still  
>> have this problem.
>> Please come back to me if you want some additional information  
>> about the setup.
>> -- 
>> Peter Ankerst?l
>> peter@pean.org
>> http://www.pean.org/
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org 
>> "
> I'd rather prefer using a gmirror/gstripe instead of mpt  
> semihardware raid then ;)
>
> -- 
> SY, Marat
Well, if the boot-disk dies the machine wont boot? Am I right?
--
Peter Ankerst?l
peter@pean.org
http://www.pean.org/

From amarat at ksu.ru  Tue Mar 24 13:04:10 2009
From: amarat at ksu.ru (Marat N.Afanasyev)
Date: Tue Mar 24 13:04:21 2009
Subject: LSI Logic raid status
In-Reply-To: <58260D6F-FBE8-49C5-918D-5EDB57BA794B@pean.org>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>	<754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>	<0B69CE4E-CC04-445B-9E84-C8E359136CCF@pean.org>	<49C9326E.3070108@samsco.org>
	<58260D6F-FBE8-49C5-918D-5EDB57BA794B@pean.org>
Message-ID: <49C93983.4030306@ksu.ru>

Peter Ankerst?l wrote:
> 
> On Mar 24, 2009, at 8:20 PM, Scott Long wrote:
> 
>> Peter Ankerst?l wrote:
>>> On Mar 24, 2009, at 8:00 PM, Charles Sprickman wrote:
>>>>
>>>>
>>>> dev.mpt.0.nonoptimal_volumes: 0
>>>>
>>>> Don't test whether the "nonoptimal_volumes" parameter works, it does -
>>>> but if you pull a drive, FreeBSD likes to panic both on the loss of 
>>>> a disk
>>>> and then again when the drive is reconnected and the rebuild completes.
>>>> This is apparently some problem in the CAM layer, not the mpt 
>>>> driver, but
>>>> it's something to be aware of.  Scott Long has noted that this is being
>>>> worked on in 8.x.
>>> Yes, I tried to remove a drive today. Of course I need to see if it 
>>> works properly
>>> before using it "for real". It did, but just as you say it paniced 
>>> when I pulled the
>>> drive and when is was resynced. But it sound great if someone is 
>>> working on
>>> this problem!
>>
>> The instability during a rebuild should be fixed in 7.2 (and 7-stable as
>> of about the last month).  If you can, please update your sources and
>> let me know if it helps.
>>
>> As for actually monitoring and configuring arrays, that work is in
>> progress.
>>
>> Scott
> 
> Im running RELENG_7 cvsuped and built like 15 hours ago. I still have 
> this problem.
> Please come back to me if you want some additional information about the 
> setup.
> 
> -- 
> Peter Ankerst?l
> peter@pean.org
> http://www.pean.org/
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 
I'd rather prefer using a gmirror/gstripe instead of mpt semihardware 
raid then ;)

-- 
SY, Marat
From kenfreebsd at icarz.com  Tue Mar 24 13:17:06 2009
From: kenfreebsd at icarz.com (Ken Menzel)
Date: Tue Mar 24 13:17:14 2009
Subject: LSI Logic raid status
In-Reply-To: <49C9326E.3070108@samsco.org>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>	<754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>	<0B69CE4E-CC04-445B-9E84-C8E359136CCF@pean.org>
	<49C9326E.3070108@samsco.org>
Message-ID: <49C939DE.4070604@icarz.com>

Scott Long wrote:
> Peter Ankerst?l wrote:
> 
> The instability during a rebuild should be fixed in 7.2 (and 7-stable as
> of about the last month).  If you can, please update your sources and
> let me know if it helps.
> 
> As for actually monitoring and configuring arrays, that work is in
> progress.
> 
> Scott

Scott,  I wanted to publicly thank you again for all that you contribute 
to this project and your helpful attitude! The amount of work you get 
done and the information you gather and distribute always impresses me.

Ken
From spork at bway.net  Tue Mar 24 13:24:40 2009
From: spork at bway.net (Charles Sprickman)
Date: Tue Mar 24 13:24:48 2009
Subject: LSI Logic raid status
In-Reply-To: <49C93983.4030306@ksu.ru>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>
	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>
	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>
	<754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>
	<0B69CE4E-CC04-445B-9E84-C8E359136CCF@pean.org>
	<49C9326E.3070108@samsco.org>
	<58260D6F-FBE8-49C5-918D-5EDB57BA794B@pean.org>
	<49C93983.4030306@ksu.ru>
Message-ID: <alpine.OSX.2.00.0903241623160.49636@freemac.nat.fasttrackmonkey.com>

On Tue, 24 Mar 2009, Marat N.Afanasyev wrote:

> Peter Ankerst?l wrote:
>> 
>> On Mar 24, 2009, at 8:20 PM, Scott Long wrote:
>> 
>>> Peter Ankerst?l wrote:
>>>> On Mar 24, 2009, at 8:00 PM, Charles Sprickman wrote:
>>>>> 
>>>>> 
>>>>> dev.mpt.0.nonoptimal_volumes: 0
>>>>> 
>>>>> Don't test whether the "nonoptimal_volumes" parameter works, it does -
>>>>> but if you pull a drive, FreeBSD likes to panic both on the loss of a 
>>>>> disk
>>>>> and then again when the drive is reconnected and the rebuild completes.
>>>>> This is apparently some problem in the CAM layer, not the mpt driver, 
>>>>> but
>>>>> it's something to be aware of.  Scott Long has noted that this is being
>>>>> worked on in 8.x.
>>>> Yes, I tried to remove a drive today. Of course I need to see if it works 
>>>> properly
>>>> before using it "for real". It did, but just as you say it paniced when I 
>>>> pulled the
>>>> drive and when is was resynced. But it sound great if someone is working 
>>>> on
>>>> this problem!
>>> 
>>> The instability during a rebuild should be fixed in 7.2 (and 7-stable as
>>> of about the last month).  If you can, please update your sources and
>>> let me know if it helps.
>>> 
>>> As for actually monitoring and configuring arrays, that work is in
>>> progress.
>>> 
>>> Scott
>> 
>> Im running RELENG_7 cvsuped and built like 15 hours ago. I still have this 
>> problem.
>> Please come back to me if you want some additional information about the 
>> setup.
>> 
>> -- 
>> Peter Ankerst?l
>> peter@pean.org
>> http://www.pean.org/
>> 
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>> 
> I'd rather prefer using a gmirror/gstripe instead of mpt semihardware raid 
> then ;)

The LSI card is not "semi-hardware" RAID, it's an actual RAID controller. 
It's also in a ton of Dell products as well.  It's a decent enough 
controller and not terribly pricey.

Charles

> -- 
> SY, Marat
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From grarpamp at gmail.com  Tue Mar 24 14:03:50 2009
From: grarpamp at gmail.com (grarpamp)
Date: Tue Mar 24 14:03:57 2009
Subject: USEVC option in libc resolv [tcp DNS], how?
Message-ID: <d2e731a10903241338q3504c1c2g6908c8515f0496c4@mail.gmail.com>

How to set and use the RES_USEVC / usevc option as mentioned in:

/usr/src/lib/libc/net/resolver.3
/usr/src/include/resolv.h
/usr/src/lib/libc/net/res_debug.c
/usr/src/share/man/man5/resolver.5  # options statement / env_var

The usevc option does not work when used in place of the debug
option below. The debug option works.

env - RES_OPTIONS=debug host freebsd.org
 or
resolv.conf: options debug
env - host freebsd.org

I find usevc in these:
/usr/src/include/resolv.h:#define RES_USEVC     0x00000008      /* use
virtual circuit */
/usr/src/lib/libc/net/gethostbydns.c:           _res.options |=
RES_STAYOPEN | RES_USEVC;
/usr/src/lib/libc/net/gethostbydns.c:   _res.options &= ~(RES_STAYOPEN
| RES_USEVC);
/usr/src/lib/libc/net/getnetbydns.c:            _res.options |=
RES_STAYOPEN | RES_USEVC;
/usr/src/lib/libc/net/getnetbydns.c:    _res.options &= ~(RES_STAYOPEN
| RES_USEVC);
/usr/src/lib/libc/net/name6.c:          _res.options |= RES_STAYOPEN |
RES_USEVC;
/usr/src/lib/libc/net/name6.c:  _res.options &= ~(RES_STAYOPEN | RES_USEVC);
/usr/src/lib/libc/net/res_debug.c:      case RES_USEVC:         return "usevc";
/usr/src/lib/libc/net/res_send.c:       v_circuit = (_res.options &
RES_USEVC) || buflen > PACKETSZ;
/usr/src/lib/libc/net/res_send.c:               if ((v_circuit &&
(!(_res.options & RES_USEVC) || ns != 0)) ||
/usr/src/lib/libc/net/resolver.3:.It Dv RES_USEVC
/usr/src/lib/libc/net/resolver.3:.Dv RES_USEVC

My guess is that it is missing from res_init.c? And that res_init.c
may need to be brought fully up to date with whatever the current
option set is nowadays?

res_init.c:545 /* XXX - print a warning here? */
 On an invalid option, yes please, inform userland :)

This note refers to RELENG_4. It may also apply to RELENG_7 and HEAD.
From 000.fbsd at quip.cz  Tue Mar 24 14:28:28 2009
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Tue Mar 24 14:28:44 2009
Subject: LSI Logic raid status
In-Reply-To: <14047DAC-9938-4FD3-A6E8-F8E720230089@pean.org>
References: <91FBB56E-9B1F-469D-A83E-03396AA850FC@pean.org>	<61AAA3A1-B794-4CF5-8F16-F30DB42940D9@verweg.com>	<F0FE0D3A-7190-4877-9946-6542071EF731@pean.org>	<754A2F8B-21E7-493A-BD31-EA5691082D1E@bway.net>	<0B69CE4E-CC04-445B-9E84-C8E359136CCF@pean.org>	<49C9326E.3070108@samsco.org>	<58260D6F-FBE8-49C5-918D-5EDB57BA794B@pean.org>	<49C93983.4030306@ksu.ru>
	<14047DAC-9938-4FD3-A6E8-F8E720230089@pean.org>
Message-ID: <49C94C65.9080603@quip.cz>

Peter Ankerst?l wrote:
> 
> On Mar 24, 2009, at 8:50 PM, Marat N.Afanasyev wrote:
> 
>>>>
>>>>
>>>> Scott
>>>
>>> Im running RELENG_7 cvsuped and built like 15 hours ago. I still  
>>> have this problem.
>>> Please come back to me if you want some additional information  about 
>>> the setup.
>>> -- 
>>> Peter Ankerst?l
>>> peter@pean.org
>>> http://www.pean.org/
>>> _______________________________________________
>>> freebsd-stable@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to 
>>> "freebsd-stable-unsubscribe@freebsd.org "
>>
>> I'd rather prefer using a gmirror/gstripe instead of mpt  semihardware 
>> raid then ;)
>>
>> -- 
>> SY, Marat
> 
> Well, if the boot-disk dies the machine wont boot? Am I right?

You can still boot if gmirror is used on the whole disks, not slices / 
partitions.
gmirror lable gm0 /dev/ad0 /dev/ad1
Then both disks contains boot code. (of course, your motherboard BIOS 
must support booting from more than one disk)

Miroslav Lachman
From spork at bway.net  Tue Mar 24 14:49:45 2009
From: spork at bway.net (Charles Sprickman)
Date: Tue Mar 24 14:49:52 2009
Subject: setting quotas from inside a jail
In-Reply-To: <20090324165215.GA79638@manor.msen.com>
References: <alpine.OSX.2.00.0903240253550.75858@office-dhcp-35.bway.net>
	<20090324165215.GA79638@manor.msen.com>
Message-ID: <alpine.OSX.2.00.0903241749070.49636@freemac.nat.fasttrackmonkey.com>

On Tue, 24 Mar 2009, Michael R. Wayne wrote:

> On Tue, Mar 24, 2009 at 03:05:05AM -0400, Charles Sprickman wrote:
>>
>> The subject describes my goal.  I'm aware of the usual caveats - if
>> there's more than one jail, no UID overlap, this will really only work in
>> one jail if all jails are on the same filesystem, etc.
>>
>> I found a very, very old post that has an... interesting... technique:
>>
>> http://groups.google.com/group/mpc.lists.freebsd.hackers/msg/2b92fc66ac72efa6?hl=en
>>
>> It actually works.  "It" being I suppose the fstab trickery in the jail.
>> I need to test this some more, but it does seem possible to edit quotas
>> inside the jail, which is my basic goal.  I don't want my provisioning box
>> to have to hit the host just to alter quotas in one jail that needs them.
>>
>> Just looking for any warnings/caveats about the above and what might be
>> different 6+ years later...
>
> That's my post.  Yes, we still do this.  It still works.  Over time,
> sometimes things get out of sync.  If that happens, go to S, shut
> off quotas, do a quotacheck, turn them back on.

I seemed to knock it out of whack on my first reboot after getting it 
working.  Does checking quotas on boot "break" it?

Thanks,

C

> /\/\ \/\/
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>
From andrew at modulus.org  Tue Mar 24 18:02:47 2009
From: andrew at modulus.org (Andrew Snow)
Date: Tue Mar 24 18:02:54 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C90813.8070705@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>	<200903241537.36515.doconnor@gsoft.com.au>	<49C87E0D.5090501@aldan.algebra.com>	<E1Lm1J9-000Ah6-Kf@kabab.cs.huji.ac.il>
	<49C90813.8070705@aldan.algebra.com>
Message-ID: <49C98202.9040403@modulus.org>

Mikhail T. wrote:
>    dump 0aCf 64  /ibm/ibmo.0.2009-03-24.dump /old
>      DUMP: WARNING: should use -L when dumping live read-write filesystems!

I thought you said it was a read-only filesystem?

In my experience, restore can sometimes throw warnings if you dump a 
live filesystem.  It might be causing your errors?  If possible, can you 
try completely unmounting the filesystem you are dumping and trying again?
From ota at j.email.ne.jp  Tue Mar 24 18:15:59 2009
From: ota at j.email.ne.jp (Yoshihiro Ota)
Date: Tue Mar 24 18:16:07 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C87E0D.5090501@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
	<200903241537.36515.doconnor@gsoft.com.au>
	<49C87E0D.5090501@aldan.algebra.com>
Message-ID: <20090324211549.27e65b90.ota@j.email.ne.jp>

On Tue, 24 Mar 2009 02:30:37 -0400
"Mikhail T." <mi+thun@aldan.algebra.com> wrote:

> Daniel O'Connor ???????(??):
> > On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
> >   
> >> I'm trying to migrate a filesystem from one disk to another using:
> >>
> >>     dump a0hCf 0 32 - /old | restore -rf -
> >>
> >> (/old is already mounted read-only). The process runs for a while and
> >> then stops with:
> >>
> >>     [...]
> >>       DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
> >>       DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
> >>       DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
> >>     unknown tape header type 1853384566
> >>     abort? [yn]
> >>
> >> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
> >> dump's output?
> >>     
> >
> > What happens if you don't use the cache?
> >   
> No big difference:
> 
>     dump a0f  - /old | restore -rf -
>     [...]
>       DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>       DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>       DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>     unknown tape header type -621260722
>     abort? [yn]
> 
> Looks like a junk value somewhere... Unitialized variable or some such.
> 
>     -mi

-a option seems to be the problem.
Try without it.

Hiro
From mi+thun at aldan.algebra.com  Tue Mar 24 18:19:06 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 18:19:14 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C98202.9040403@modulus.org>
References: <49C83673.3000604@aldan.algebra.com>	<200903241537.36515.doconnor@gsoft.com.au>	<49C87E0D.5090501@aldan.algebra.com>	<E1Lm1J9-000Ah6-Kf@kabab.cs.huji.ac.il>
	<49C90813.8070705@aldan.algebra.com> <49C98202.9040403@modulus.org>
Message-ID: <49C98680.7020301@aldan.algebra.com>

Andrew Snow ???????(??):
> Mikhail T. wrote:
>>    dump 0aCf 64  /ibm/ibmo.0.2009-03-24.dump /old
>>      DUMP: WARNING: should use -L when dumping live read-write 
>> filesystems!
>
> I thought you said it was a read-only filesystem?
It was yesterday. Today I remounted it rw to remove some junk-files, 
which I don't need to transfer. I don't believe, this is causing the 
problems.
> In my experience, restore can sometimes throw warnings if you dump a 
> live filesystem.  It might be causing your errors?  If possible, can 
> you try completely unmounting the filesystem you are dumping and 
> trying again?
I don't think, restore can even figure this out, much less throw a 
warning -- it is dump, that complains... But the dump started this 
morning is still hanging (in sbwait) -- I've never seen this before. I'm 
also very troubled, that such an important functionality (dump/restore!) 
is sooo problem-prone, and yet so few people seem to care...

Is the official view, that dump is obsolete (and already bit-rotten), 
perhaps, and use of tar is encouraged instead?

    -mi


From doconnor at gsoft.com.au  Tue Mar 24 19:02:22 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Mar 24 19:02:29 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C98680.7020301@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com> <49C98202.9040403@modulus.org>
	<49C98680.7020301@aldan.algebra.com>
Message-ID: <200903251232.11418.doconnor@gsoft.com.au>

On Wednesday 25 March 2009 11:48:56 Mikhail T. wrote:
> Andrew Snow ???????(??):
> > Mikhail T. wrote:
> >>    dump 0aCf 64  /ibm/ibmo.0.2009-03-24.dump /old
> >>      DUMP: WARNING: should use -L when dumping live read-write
> >> filesystems!
> >
> > I thought you said it was a read-only filesystem?
>
> It was yesterday. Today I remounted it rw to remove some junk-files,
> which I don't need to transfer. I don't believe, this is causing the
> problems.
>
> > In my experience, restore can sometimes throw warnings if you dump a
> > live filesystem.  It might be causing your errors?  If possible, can
> > you try completely unmounting the filesystem you are dumping and
> > trying again?
>
> I don't think, restore can even figure this out, much less throw a
> warning -- it is dump, that complains... But the dump started this

restore will emit a warning if dump writes a stream that is out of order 
because of a live file system but that is not what you are seeing.

> morning is still hanging (in sbwait) -- I've never seen this before. I'm
> also very troubled, that such an important functionality (dump/restore!)
> is sooo problem-prone, and yet so few people seem to care...

Well, "works for me".

> Is the official view, that dump is obsolete (and already bit-rotten),
> perhaps, and use of tar is encouraged instead?

I've never had dump fail but it IS rather crusty and slow.. That said tar 
doesn't cover all the information I believe.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/ba15cfeb/attachment.pgp
From mi+thun at aldan.algebra.com  Tue Mar 24 19:08:14 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 19:08:21 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <200903251232.11418.doconnor@gsoft.com.au>
References: <49C83673.3000604@aldan.algebra.com> <49C98202.9040403@modulus.org>
	<49C98680.7020301@aldan.algebra.com>
	<200903251232.11418.doconnor@gsoft.com.au>
Message-ID: <49C99204.2050601@aldan.algebra.com>

Daniel O'Connor ???????(??):
>> morning is still hanging (in sbwait) -- I've never seen this before. I'm
>> also very troubled, that such an important functionality (dump/restore!)
>> is sooo problem-prone, and yet so few people seem to care...
>>     
>
> Well, "works for me".
>   
Well, would like a login on this system to take a look for yourself? I 
can reproduce the problem easily.
>> Is the official view, that dump is obsolete (and already bit-rotten),
>> perhaps, and use of tar is encouraged instead?
>>     
>
> I've never had dump fail but it IS rather crusty and slow.. That said tar 
> doesn't cover all the information I believe.
So, if dump/restore ain't it, does FreeBSD have a supported way of 
making filesystem-level backups, that's both modern and covers all 
aspects (like flags)?

That said, I point out, that for me, dump is not failing (although it 
did hang this morning). It is the restore, which fails to read dump's 
output:

    unknown tape header type 213474529
    abort? [yn] n
    resync restore, skipped 502 blocks
    expected next file 54, got 0
    unknown tape header type -954356454
    abort? [yn] n
    resync restore, skipped 29 blocks
    expected next file 54, got 0
    unknown tape header type -1754938223
    abort? [yn] n
    resync restore, skipped 482 blocks
    expected next file 54, got 0
    unknown tape header type -915868704
    abort? [yn] n
    resync restore, skipped 29 blocks
    expected next file 54, got 0
    unknown tape header type 1790084751
    abort? [yn] n
    resync restore, skipped 482 blocks
    expected next file 54, got 0
    unknown tape header type 903667267
    abort? [yn] n
    ...

Thanks!

    -mi

From mi+thun at aldan.algebra.com  Tue Mar 24 19:40:25 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 19:40:33 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <20090324211549.27e65b90.ota@j.email.ne.jp>
References: <49C83673.3000604@aldan.algebra.com>	<200903241537.36515.doconnor@gsoft.com.au>	<49C87E0D.5090501@aldan.algebra.com>
	<20090324211549.27e65b90.ota@j.email.ne.jp>
Message-ID: <49C99997.9050306@aldan.algebra.com>

Yoshihiro Ota ???????(??):
>> No big difference:
>>     dump a0f  - /old | restore -rf -
>>     [...]
>>       DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>>       DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>>       DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>>     unknown tape header type -621260722
>>     abort? [yn]
>>
>> Looks like a junk value somewhere... Unitialized variable or some such.
>>
>>     -mi
>>     
>
> -a option seems to be the problem.
> Try without it.
>   
As could be expected, it failed exactly the same without the obviously
unrelated -a option:

    root@symbion:/ibm (113) dump 0f - /ibmo | restore -rf -
    DUMP: Date of this level 0 dump: Tue Mar 24 21:31:19 2009
    DUMP: Date of last level 0 dump: the epoch
    DUMP: Dumping /dev/ad2s1e (/ibmo) to standard output
    DUMP: mapping (Pass I) [regular files]
    DUMP: mapping (Pass II) [directories]
    DUMP: estimated 152357442 tape blocks.
    DUMP: dumping (Pass III) [directories]
    DUMP: dumping (Pass IV) [regular files]
    DUMP: 0.16% done, finished in 242:05 at Sat Apr 4 00:00:21 2009
    DUMP: 4.29% done, finished in 10:24 at Wed Mar 25 08:24:02 2009
    DUMP: 8.56% done, finished in 5:52 at Wed Mar 25 03:56:43 2009
    DUMP: 11.76% done, finished in 4:35 at Wed Mar 25 02:43:29 2009
    DUMP: 16.00% done, finished in 3:38 at Wed Mar 25 01:52:05 2009
    DUMP: 19.28% done, finished in 3:15 at Wed Mar 25 01:33:43 2009
    DUMP: 22.74% done, finished in 2:55 at Wed Mar 25 01:18:49 2009
    unknown tape header type 1431655765
    abort? [yn] n
    resync restore, skipped 9 blocks
    expected next file 1599492, got 0
    DUMP: 24.50% done, finished in 3:27 at Wed Mar 25 02:05:41 2009
    unknown tape header type 1508167078
    abort? [yn] n
    resync restore, skipped 66 blocks
    expected next file 1599492, got 0
    unknown tape header type -1493630979
    abort? [yn] y
    dump core? [yn] n
    DUMP: Broken pipe
    DUMP: The ENTIRE dump is aborted.

Now can one get /real/ support for the most basic functionality of the
most advanced modern Unix in the world? Thanks,

    -mi

From andrew at modulus.org  Tue Mar 24 20:02:33 2009
From: andrew at modulus.org (Andrew Snow)
Date: Tue Mar 24 20:02:46 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C99997.9050306@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>	<200903241537.36515.doconnor@gsoft.com.au>	<49C87E0D.5090501@aldan.algebra.com>	<20090324211549.27e65b90.ota@j.email.ne.jp>
	<49C99997.9050306@aldan.algebra.com>
Message-ID: <49C99E03.9060604@modulus.org>

Mikhail T. wrote:
> Now can one get /real/ support for the most basic functionality of the
> most advanced modern Unix in the world? Thanks,

I think before this goes any further, you will need to try
rebooting/unmouting it, running fsck on it, and then dump the unmounted
partition and see how that goes.


- Andrew
From doconnor at gsoft.com.au  Tue Mar 24 20:05:03 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Mar 24 20:05:15 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C99204.2050601@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251232.11418.doconnor@gsoft.com.au>
	<49C99204.2050601@aldan.algebra.com>
Message-ID: <200903251334.38350.doconnor@gsoft.com.au>

On Wednesday 25 March 2009 12:38:04 Mikhail T. wrote:
> Daniel O'Connor ???????(??):
> >> morning is still hanging (in sbwait) -- I've never seen this before. I'm
> >> also very troubled, that such an important functionality (dump/restore!)
> >> is sooo problem-prone, and yet so few people seem to care...
> >
> > Well, "works for me".
>
> Well, would like a login on this system to take a look for yourself? I
> can reproduce the problem easily.

I don't know the internals of dump/restore :(

> >> Is the official view, that dump is obsolete (and already bit-rotten),
> >> perhaps, and use of tar is encouraged instead?
> >
> > I've never had dump fail but it IS rather crusty and slow.. That said tar
> > doesn't cover all the information I believe.
>
> So, if dump/restore ain't it, does FreeBSD have a supported way of
> making filesystem-level backups, that's both modern and covers all
> aspects (like flags)?

I would try a pax archive, eg..
tar --format pax --one-file-system -pcf - -C / . | tar -pxf - -C /mnt/newdisk

According to the libarchive-formats page this handles ACLs & flags, my testing 
shows it handles flags (at least). eg..

[midget 13:30] /tmp/test2 >touch foo
[midget 13:30] /tmp/test2 >chflags uchg foo  
[midget 13:30] /tmp/test2 >tar --format pax -zpcf /tmp/test.pax.gz foo
[midget 13:30] /tmp/test2 >rm -f foo
rm: foo: Operation not permitted
[midget 13:30] /tmp/test2 >chflags nouchg foo
[midget 13:30] /tmp/test2 >rm foo
[midget 13:30] /tmp/test2 >tar -pxf /tmp/test.pax.gz                  
[midget 13:30] /tmp/test2 >ls -lao
total 30                          
drwxr-xr-x   2 darius  wheel  -      512 Mar 25 13:30 .
drwxrwxrwt  53 root    wheel  -    28672 Mar 25 13:29 ..
-rw-r--r--   1 darius  wheel  uchg     0 Mar 25 13:30 foo
[midget 13:30] /tmp/test2 >rm -f foo
rm: foo: Operation not permitted

> That said, I point out, that for me, dump is not failing (although it
> did hang this morning). It is the restore, which fails to read dump's
> output:

You can't tell the difference between dump producing mangled output or restore 
bombing out on valid input..

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/bc00de19/attachment.pgp
From mi+thun at aldan.algebra.com  Tue Mar 24 20:05:41 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 20:05:48 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C99E03.9060604@modulus.org>
References: <49C83673.3000604@aldan.algebra.com>	<200903241537.36515.doconnor@gsoft.com.au>	<49C87E0D.5090501@aldan.algebra.com>	<20090324211549.27e65b90.ota@j.email.ne.jp>
	<49C99997.9050306@aldan.algebra.com> <49C99E03.9060604@modulus.org>
Message-ID: <49C99F7E.2010108@aldan.algebra.com>

Andrew Snow ???????(??):
> Mikhail T. wrote:
>   
>> Now can one get /real/ support for the most basic functionality of the
>> most advanced modern Unix in the world? Thanks,
>>     
>
> I think before this goes any further, you will need to try
> rebooting/unmouting it, running fsck on it, and then dump the unmounted
> partition and see how that goes.
>   
The system's uptime is only 3 days -- I had to reboot it to put in the 
new disk...

But I will try your suggestion next, after the current attempt (using 
restore's -v switch) ends. If it chokes on the same file every time, 
that would be a clue... Thanks,

    -mi

From mi+thun at aldan.algebra.com  Tue Mar 24 20:07:01 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 20:07:08 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <200903251334.38350.doconnor@gsoft.com.au>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251232.11418.doconnor@gsoft.com.au>
	<49C99204.2050601@aldan.algebra.com>
	<200903251334.38350.doconnor@gsoft.com.au>
Message-ID: <49C99FD2.50609@aldan.algebra.com>

Daniel O'Connor ???????(??):
>> That said, I point out, that for me, dump is not failing (although it
>> did hang this morning). It is the restore, which fails to read dump's
>> output:
>>     
>
> You can't tell the difference between dump producing mangled output or restore 
> bombing out on valid input..
>   
That's true. I just wanted to point out, that someone running dump only 
(to make backups) is not going to know, whether his dumps are usable 
(for whichever of the two reasons), until he needs them...

    -mi

From doconnor at gsoft.com.au  Tue Mar 24 20:59:51 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Mar 24 20:59:59 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C99997.9050306@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
	<20090324211549.27e65b90.ota@j.email.ne.jp>
	<49C99997.9050306@aldan.algebra.com>
Message-ID: <200903251429.40578.doconnor@gsoft.com.au>

On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote:
> Now can one get /real/ support for the most basic functionality of the
> most advanced modern Unix in the world? Thanks,

Maybe you should return it to the shop and ask for your money back.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/b8fd1a20/attachment.pgp
From mi+thun at aldan.algebra.com  Tue Mar 24 21:05:04 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 21:05:16 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <200903251429.40578.doconnor@gsoft.com.au>
References: <49C83673.3000604@aldan.algebra.com>
	<20090324211549.27e65b90.ota@j.email.ne.jp>
	<49C99997.9050306@aldan.algebra.com>
	<200903251429.40578.doconnor@gsoft.com.au>
Message-ID: <49C9AD6D.30305@aldan.algebra.com>

Daniel O'Connor ???????(??):
> On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote:
>   
>> Now can one get /real/ support for the most basic functionality of the
>> most advanced modern Unix in the world? Thanks,
>>     
>
> Maybe you should return it to the shop and ask for your money back.
>   
Well, if this response is the best one can get, may be I should also 
revoke my own 15 years worth of contributions to the project...

Except, why would I? I always supported people, who had problems with 
any of my work -- and the attitude of the rest of the contributors /used 
to be/ the same...

    -mi

From doconnor at gsoft.com.au  Tue Mar 24 21:22:53 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Tue Mar 24 21:23:05 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C9AD6D.30305@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251429.40578.doconnor@gsoft.com.au>
	<49C9AD6D.30305@aldan.algebra.com>
Message-ID: <200903251452.42301.doconnor@gsoft.com.au>

On Wednesday 25 March 2009 14:35:01 Mikhail T. wrote:
> Daniel O'Connor ???????(??):
> > On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote:
> >> Now can one get /real/ support for the most basic functionality of the
> >> most advanced modern Unix in the world? Thanks,
> >
> > Maybe you should return it to the shop and ask for your money back.
>
> Well, if this response is the best one can get, may be I should also
> revoke my own 15 years worth of contributions to the project...
>
> Except, why would I? I always supported people, who had problems with
> any of my work -- and the attitude of the rest of the contributors /used
> to be/ the same...

People ARE helping you, just because they haven't come up with an answer is no 
reason to send snarky comments to the list.

Outrage (fake or otherwise) that people don't seem to be taking your 
particular problem seriously is unhelpful and probably counter-productive.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/0e125c74/attachment.pgp
From mi+thun at aldan.algebra.com  Tue Mar 24 21:29:38 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 21:30:13 2009
Subject: support quality (Re: dump | restore fails: unknown tape header type
 1853384566)
In-Reply-To: <200903251452.42301.doconnor@gsoft.com.au>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251429.40578.doconnor@gsoft.com.au>
	<49C9AD6D.30305@aldan.algebra.com>
	<200903251452.42301.doconnor@gsoft.com.au>
Message-ID: <49C9B330.10500@aldan.algebra.com>

Daniel O'Connor ???????(??):
> People ARE helping you, just because they haven't come up with an answer is no 
> reason to send snarky comments to the list.
>   
No, sorry, people aren't. They are trying, yes, but not even close. The 
suggestion to eliminate the -a switch (a no-op, in fact) was 
particularly unhelpful -- and deserving of mockery. Later on someone 
with a similar problem will find this thread with a search engine and 
will be trying to follow the posted advices -- to no avail, of course, 
plunging FreeBSD further into disrepute.
> Outrage (fake or otherwise) that people don't seem to be taking your 
> particular problem seriously is unhelpful and probably counter-productive.
It is fairly obvious by now, that no real help will be forthcoming, for 
whatever reason. Thus any talk of "productivity" is moot. Thanks for trying.

    -mi

From mi+thun at aldan.algebra.com  Tue Mar 24 21:30:50 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue Mar 24 21:30:58 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C99E03.9060604@modulus.org>
References: <49C83673.3000604@aldan.algebra.com>	<200903241537.36515.doconnor@gsoft.com.au>	<49C87E0D.5090501@aldan.algebra.com>	<20090324211549.27e65b90.ota@j.email.ne.jp>
	<49C99997.9050306@aldan.algebra.com> <49C99E03.9060604@modulus.org>
Message-ID: <49C9B377.5090903@aldan.algebra.com>

Andrew Snow ???????(??):
> I think before this goes any further, you will need to try
> rebooting/unmouting it, running fsck on it, and then dump the unmounted
> partition and see how that goes.
>
>   
Rebooted, reran `fsck -y /old' (all clean). Same problem...

    -mi

From markir at paradise.net.nz  Tue Mar 24 21:54:40 2009
From: markir at paradise.net.nz (Mark Kirkwood)
Date: Tue Mar 24 21:54:52 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C99204.2050601@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com> <49C98202.9040403@modulus.org>
	<49C98680.7020301@aldan.algebra.com>
	<200903251232.11418.doconnor@gsoft.com.au>
	<49C99204.2050601@aldan.algebra.com>
Message-ID: <49C9B57F.4010403@paradise.net.nz>

Mikhail T. wrote:
>
> That said, I point out, that for me, dump is not failing (although it 
> did hang this morning). It is the restore, which fails to read dump's 
> output:
>
>    unknown tape header type 213474529
>    abort? [yn] n
>    resync restore, skipped 502 blocks
>    expected next file 54, got 0
>    unknown tape header type -954356454
>    abort? [yn] n
>    resync restore, skipped 29 blocks
>    expected next file 54, got 0
>    unknown tape header type -1754938223
>    abort? [yn] n
>    resync restore, skipped 482 blocks
>    expected next file 54, got 0
>    unknown tape header type -915868704
>    abort? [yn] n
>    resync restore, skipped 29 blocks
>    expected next file 54, got 0
>    unknown tape header type 1790084751
>    abort? [yn] n
>    resync restore, skipped 482 blocks
>    expected next file 54, got 0
>    unknown tape header type 903667267
>    abort? [yn] n
>    ...
>

Is this link any help?

http://www.mail-archive.com/freebsd-questions@freebsd.org/msg197899.html


Other than that, I'd suggest checking the disk(s) with smartmontools to 
try to rule out hardware problems.

regards

Mark
From freebsd-nospam at yaxom.com  Tue Mar 24 22:22:45 2009
From: freebsd-nospam at yaxom.com (Greg Black)
Date: Tue Mar 24 22:22:58 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C99FD2.50609@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251232.11418.doconnor@gsoft.com.au>
	<49C99204.2050601@aldan.algebra.com>
	<200903251334.38350.doconnor@gsoft.com.au>
	<49C99FD2.50609@aldan.algebra.com>
Message-ID: <nospam-1237956961.78753@joker.yaxom.com>

On 2009-03-24, Mikhail T. wrote:
> That's true. I just wanted to point out, that someone running dump only 
> (to make backups) is not going to know, whether his dumps are usable 
> (for whichever of the two reasons), until he needs them...

Such a person is not making backups and deserves what he gets.

I haven't got anything to say about dump/restore because I haven't
bothered with them for years.  I do know that dumps from mounted file
systems will often appear to work, but will fail when it matters.  This
is not a bug and is expected behaviour to which the solution is obvious.
From wsk at gddsn.org.cn  Tue Mar 24 22:34:40 2009
From: wsk at gddsn.org.cn (wsk)
Date: Tue Mar 24 22:34:50 2009
Subject: [PREVIEW] Nouveau on FreeBSD (Take 2)
In-Reply-To: <1237882591.1771.26.camel@balrog.2hip.net>
References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn>	
	<49C6E5C6.60306@gddsn.org.cn>
	<1237798914.2110.24.camel@balrog.2hip.net>	
	<49C85F4E.5050002@gddsn.org.cn>
	<1237882591.1771.26.camel@balrog.2hip.net>
Message-ID: <49C97EEB.4090607@gddsn.org.cn>

Robert Noland wrote:
> On Tue, 2009-03-24 at 12:19 +0800, wsk wrote:
>   
>> Robert Noland wrote:
>>     
>>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote:
>>>   
>>>       
>>>>> Ok, this patch should work on NV50 chips also.
>>>>>       
>>>>> What you get is EXA and Xv.
>>>>>       
>>>>> You still need:
>>>>>       
>>>>> A recent -CURRENT or -STABLE.
>>>>>       
>>>>> git master of libdrm and xf86-video-nouveau.
>>>>>       
>>>>> This patch.
>>>>>       
>>>>> Things I've figured out since the last patch...
>>>>>       
>>>>> On NV50 class hardware you need to have a compositing manager running
>>>>> for Xv to work.  That means xcompmgr, metacity with composite enabled,
>>>>> xfce (rumored to work as well, haven't tried).  If your running Gnome
>>>>> with metacity, open gconf-editor and go to apps->metacity->general and
>>>>> check the composite box.
>>>>>       
>>>>> On NV40 class hardware, you don't need the composite manager.  In fact
>>>>> (at least with Xserver 1.6 which I'm running now), if a composite
>>>>> manager is enabled, I'm seeing high cpu utilization from Xorg under some
>>>>> circumstances.  I don't think this is a drm issue, but still an issue.
>>>>> For me, if I start a video using mplayer in an xterm, cpu is fine as
>>>>> long as that xterm is the foreground window.  If it is not the
>>>>> foreground window, even if it isn't obscured I see the cpu utilization.
>>>>> Disabling the composite manager makes everything fine.
>>>>>       
>>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch <http://people.freebsd.org/%7Ernoland/drm-nouveau-032109.patch>
>>>>>       
>>>>> robert.
>>>>>       
>>>>>           
>>>> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation.
>>>> It is not supported in any way.
>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
>>>> Select the "xorg" product for bugs you find in this release.
>>>> Before reporting bugs in pre-release versions please check the
>>>> latest version in the X.Org Foundation git repository.
>>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
>>>>
>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
>>>> Release Date: 2009-1-30
>>>> X Protocol Version 11, Revision 0
>>>> Build Operating System: FreeBSD 7.1-STABLE amd64
>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE
>>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/sr
>>>> c/sys/WSK amd64
>>>> Build Date: 06 February 2009  04:22:44PM
>>>>
>>>>         Before reporting problems, check http://wiki.x.org
>>>>         to make sure that you have the latest version.
>>>> Markers: (--) probed, (**) from config file, (==) default setting,
>>>>         (++) from command line, (!!) notice, (II) informational,
>>>>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
>>>> ing config file: "xorg.conf1"
>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>>> drm0: [ITHREAD]
>>>> info: [drm] Allocating FIFO number 1
>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
>>>> (EE) Screen(s) found, but none have a usable configuration.
>>>>
>>>> Fatal server error:
>>>> no screens found
>>>>
>>>> Please consult the The X.Org Foundation support
>>>>          at http://wiki.x.org
>>>>  for help.
>>>> Please also check the log file at "/var/log/Xorg.0.log" for additional informati
>>>> on.
>>>>
>>>> info: [drm] nouveau_fifo_free: freeing fifo 1
>>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before
>>>> destroy.Prepare for strangeness..
>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>>>
>>>> what can i do ?
>>>>
>>>>
>>>>
>>>>
>>>> plain text document attachment (Xorg.0.log)
>>>> This is a pre-release version of the X server from The X.Org Foundation.
>>>> It is not supported in any way.
>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
>>>> Select the "xorg" product for bugs you find in this release.
>>>> Before reporting bugs in pre-release versions please check the
>>>> latest version in the X.Org Foundation git repository.
>>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
>>>>
>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
>>>> Release Date: 2009-1-30
>>>> X Protocol Version 11, Revision 0
>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 
>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64
>>>> Build Date: 06 February 2009  04:22:44PM
>>>>  
>>>> 	Before reporting problems, check http://wiki.x.org
>>>> 	to make sure that you have the latest version.
>>>> Markers: (--) probed, (**) from config file, (==) default setting,
>>>> 	(++) from command line, (!!) notice, (II) informational,
>>>> 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
>>>> (++) Using config file: "xorg.conf1"
>>>> (==) No Layout section.  Using the first Screen section.
>>>> (==) No screen section available. Using defaults.
>>>> (**) |-->Screen "Default Screen Section" (0)
>>>> (**) |   |-->Monitor "<default monitor>"
>>>> (==) No device specified for screen "Default Screen Section".
>>>> 	Using the first device section listed.
>>>> (**) |   |-->Device "Card0"
>>>> (==) No monitor specified for screen "Default Screen Section".
>>>> 	Using a default monitor configuration.
>>>> (==) Automatically adding devices
>>>> (==) Automatically enabling devices
>>>> (==) No FontPath specified.  Using compiled-in default.
>>>> (==) FontPath set to:
>>>> 	built-ins
>>>> (==) ModulePath set to "/usr/local/lib/xorg/modules"
>>>> (II) Cannot locate a core pointer device.
>>>> (II) Cannot locate a core keyboard device.
>>>> (II) The server relies on HAL to provide the list of input devices.
>>>> 	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
>>>> (II) Loader magic: 0xb20
>>>> (II) Module ABI versions:
>>>> 	X.Org ANSI C Emulation: 0.4
>>>> 	X.Org Video Driver: 5.0
>>>> 	X.Org XInput driver : 4.0
>>>> 	X.Org Server Extension : 2.0
>>>> (II) Loader running on freebsd
>>>> (--) Using syscons driver with X support (version 2.0)
>>>> (--) using VT number 9
>>>>
>>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536
>>>>     
>>>>         
>>> Ok, thats a new one...
>>>
>>>   
>>>       
>>>> (II) System resource ranges:
>>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
>>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
>>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
>>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
>>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
>>>> (II) LoadModule: "extmod"
>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
>>>> (II) Module extmod: vendor="X.Org Foundation"
>>>> 	compiled for 1.5.99.902, module version = 1.0.0
>>>> 	Module class: X.Org Server Extension
>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>> (II) Loading extension MIT-SCREEN-SAVER
>>>> (II) Loading extension XFree86-VidModeExtension
>>>> (II) Loading extension XFree86-DGA
>>>> (II) Loading extension DPMS
>>>> (II) Loading extension XVideo
>>>> (II) Loading extension XVideo-MotionCompensation
>>>> (II) Loading extension X-Resource
>>>> (II) LoadModule: "dbe"
>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
>>>> (II) Module dbe: vendor="X.Org Foundation"
>>>> 	compiled for 1.5.99.902, module version = 1.0.0
>>>> 	Module class: X.Org Server Extension
>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>> (II) Loading extension DOUBLE-BUFFER
>>>> (II) LoadModule: "glx"
>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
>>>> (II) Module glx: vendor="X.Org Foundation"
>>>> 	compiled for 1.5.99.902, module version = 1.0.0
>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>> (==) AIGLX disabled
>>>> (==) Exporting typical set of GLX visuals
>>>> (II) Loading extension GLX
>>>> (II) LoadModule: "record"
>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
>>>> (II) Module record: vendor="X.Org Foundation"
>>>> 	compiled for 1.5.99.902, module version = 1.13.0
>>>> 	Module class: X.Org Server Extension
>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>> (II) Loading extension RECORD
>>>> (II) LoadModule: "dri"
>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
>>>> (II) Module dri: vendor="X.Org Foundation"
>>>> 	compiled for 1.5.99.902, module version = 1.0.0
>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>> (II) Loading extension XFree86-DRI
>>>> (II) LoadModule: "nouveau"
>>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so
>>>> (II) Module nouveau: vendor="X.Org Foundation"
>>>> 	compiled for 1.5.99.902, module version = 0.0.10
>>>> 	Module class: X.Org Video Driver
>>>> 	ABI class: X.Org Video Driver, version 5.0
>>>> (II) NOUVEAU driver Date:   Wed Mar 18 09:36:33 2009 +1000
>>>> (II) NOUVEAU driver for NVIDIA chipset families :
>>>> 	RIVA TNT    (NV04)
>>>> 	RIVA TNT2   (NV05)
>>>> 	GeForce 256 (NV10)
>>>> 	GeForce 2   (NV11, NV15)
>>>> 	GeForce 4MX (NV17, NV18)
>>>> 	GeForce 3   (NV20)
>>>> 	GeForce 4Ti (NV25, NV28)
>>>> 	GeForce FX  (NV3x)
>>>> 	GeForce 6   (NV4x)
>>>> 	GeForce 7   (G7x)
>>>> 	GeForce 8   (G8x)
>>>> (II) Primary Device is: PCI 01@00:00:0
>>>> (II) resource ranges after probing:
>>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
>>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
>>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
>>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
>>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
>>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86"
>>>>     
>>>>         
>>> Hrm, NV86... I'll have to ask around about that.  Meanwhile can you send
>>> me a pciconf -lvb which should at least show us the BAR configuration.
>>>
>>> Ok, my sources are telling me that this should work and that it is an
>>> NV50, or at least should work the same...
>>>
>>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess.  I'm
>>> not sure if it may be trashing the BARs somehow.
>>>
>>> robert.
>>>   
>>>       
>> bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled
>> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086
>> rev=0x02 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = '82801H (ICH8 Family) SMBus Controller'
>> class = serial bus
>> subclass = SMBus
>> bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled
>> bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled
>> vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de
>> rev=0xa1 hdr=0x00
>> vendor = 'Nvidia Corp'
>> device = 'Unknown nVidia Quadro FX 570M'
>> class = display
>> subclass = VGA
>> bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled
>>     
>
> Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up.  BAR 1
> should be your framebuffer and should be where most of your memory is.
> (This is the memory the tell you about when you buy the card, 256M,
> 512M, etc.)  It should probably be a 64bit BAR, which is why BAR 2 isn't
> there.  We are going to need more details on your card...
>   
indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M memory.
but it recognized Quadro FX 570M with pciconfig.
>   
>> bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled
>>     
>
> This one is BAR 3, which is used when it doesn't find BAR 1.
>
> robert.
>
>   
>> bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled
>> ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4
>> rev=0x03 hdr=0x00
>> vendor = 'Broadcom Corporation'
>> device = 'BCM94321KFBG Broadcom 4321AGN 802.11a/b/g/draft-n Wi-Fi Solution'
>> class = network
>> bar [10] = type Memory, range 64, base 0xf9ffc000, size 16384, enabled
>> bar [18] = type Prefetchable Memory, range 64, base 0xf0000000, size
>> 1048576, enabled
>> bge0@pci0:9:0:0: class=0x020000 card=0x01fe1028 chip=0x167314e4 rev=0x02
>> hdr=0x00
>> vendor = 'Broadcom Corporation'
>> device = 'B57xx Broadcom NetXtreme Gigabit Ethernet'
>> class = network
>> subclass = ethernet
>> bar [10] = type Memory, range 64, base 0xf9bf0000, size 65536, enabled
>> cbb0@pci0:3:1:0: class=0x060700 card=0x01fe1028 chip=0x71351217 rev=0x21
>> hdr=0x02
>> vendor = 'O2 Micro Inc'
>> device = 'OZ711EZ1 MemoryCardBus Controller'
>> class = bridge
>> subclass = PCI-CardBus
>> bar [10] = type Memory, range 32, base 0xf9a00000, size 4096, enabled
>> fwohci0@pci0:3:1:4: class=0x0c0010 card=0x01fe1028 chip=0x00f71217
>> rev=0x02 hdr=0x00
>> vendor = 'O2 Micro Inc'
>> device = '0x00f71217 1394 Open Host Controller Interface'
>> class = serial bus
>> subclass = FireWire
>> bar [10] = type Memory, range 32, base 0xf9aff000, size 4096, enabled
>> bar [14] = type Memory, range 32, base 0xf9afe800, size 2048, enabled
>>
>> and follow your intrudction.still pain me :(
>>
>> (++) Using config file: "xorg.conf1"
>> drm0: <NVidia Display Adapter> on vgapci0
>> info: [drm] Detected an NV50 generation card (0x086900a2)
>> vgapci0: child drm0 requested pci_enable_busmaster
>> info: [drm] Initialized nouveau 0.0.12 20060213
>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>> drm0: [ITHREAD]
>> info: [drm] Allocating FIFO number 1
>> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII,
>> invalid/inactiv
>> e channel id 128
>> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo:
>> [drm] , nSt
>> atus:info: [drm]
>> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data
>> 0x00000000:0x00
>> 000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1:
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2:
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000
>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000
>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
>> (EE) Screen(s) found, but none have a usable configuration.
>>
>> Fatal server error:
>> no screens found
>>
>> Please consult the The X.Org Foundation support
>> at http://wiki.x.org
>> for help.
>> Please also check the log file at "/var/log/Xorg.0.log" for additional
>> informati
>> on.
>>
>> info: [drm] nouveau_fifo_free: freeing fifo 1
>> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1
>> before d
>> estroy.Prepare for strangeness..
>> info: [drm] PFIFO_DMA_PUSHER - Ch 127
>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>
>>     
>>>   
>>>       
>>>> (II) Loading sub module "int10"
>>>> (II) LoadModule: "int10"
>>>> (II) Loading /usr/local/lib/xorg/modules//libint10.so
>>>> (II) Module int10: vendor="X.Org Foundation"
>>>> 	compiled for 1.5.99.902, module version = 1.0.0
>>>> 	ABI class: X.Org Video Driver, version 5.0
>>>> (II) NOUVEAU(0): Initializing int10
>>>> (==) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already clear
>>>> (==) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already clear
>>>> (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000
>>>> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
>>>> drmOpenDevice: node name is /dev/dri/card0
>>>> drmOpenDevice: open result is 10, (OK)
>>>> drmOpenDevice: node name is /dev/dri/card0
>>>> drmOpenDevice: open result is 10, (OK)
>>>> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
>>>> drmOpenDevice: node name is /dev/dri/card0
>>>> drmOpenDevice: open result is 10, (OK)
>>>> drmOpenByBusid: drmOpenMinor returns 10
>>>> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
>>>> (II) [drm] DRM interface version 1.2
>>>> (II) [drm] DRM open master succeeded.
>>>> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12
>>>> (--) NOUVEAU(0): [drm] kernel modesetting not available
>>>> (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3
>>>> (II) NOUVEAU(0): Creating default Display subsection in Screen section
>>>> 	"Default Screen Section" for depth/fbbpp 24/32
>>>> (==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32
>>>> (==) NOUVEAU(0): RGB weight 888
>>>> (==) NOUVEAU(0): Default visual is TrueColor
>>>> (II) Loading sub module "vgahw"
>>>> (II) LoadModule: "vgahw"
>>>> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so
>>>> (II) Module vgahw: vendor="X.Org Foundation"
>>>> 	compiled for 1.5.99.902, module version = 0.1.0
>>>> 	ABI class: X.Org Video Driver, version 5.0
>>>> (==) NOUVEAU(0): Randr1.2 support enabled
>>>> (==) NOUVEAU(0): Using HW cursor
>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
>>>> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
>>>> (II) UnloadModule: "nouveau"
>>>> (II) UnloadModule: "vgahw"
>>>> (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so
>>>> (II) UnloadModule: "int10"
>>>> (II) Unloading /usr/local/lib/xorg/modules//libint10.so
>>>> (EE) Screen(s) found, but none have a usable configuration.
>>>>
>>>> Fatal server error:
>>>> no screens found
>>>>
>>>> Please consult the The X.Org Foundation support 
>>>> 	 at http://wiki.x.org
>>>>  for help. 
>>>> Please also check the log file at "/var/log/Xorg.0.log" for additional information.
>>>>
>>>>     
>>>>         

From rnoland at FreeBSD.org  Tue Mar 24 23:12:06 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Tue Mar 24 23:12:20 2009
Subject: [PREVIEW] Nouveau on FreeBSD (Take 2)
In-Reply-To: <49C97EEB.4090607@gddsn.org.cn>
References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn>
	<49C6E5C6.60306@gddsn.org.cn>
	<1237798914.2110.24.camel@balrog.2hip.net>
	<49C85F4E.5050002@gddsn.org.cn>
	<1237882591.1771.26.camel@balrog.2hip.net>
	<49C97EEB.4090607@gddsn.org.cn>
Message-ID: <1237961497.1828.2.camel@balrog.2hip.net>

On Wed, 2009-03-25 at 08:46 +0800, wsk wrote:
> Robert Noland wrote:
> > On Tue, 2009-03-24 at 12:19 +0800, wsk wrote:
> >   
> >> Robert Noland wrote:
> >>     
> >>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote:
> >>>   
> >>>       
> >>>>> Ok, this patch should work on NV50 chips also.
> >>>>>       
> >>>>> What you get is EXA and Xv.
> >>>>>       
> >>>>> You still need:
> >>>>>       
> >>>>> A recent -CURRENT or -STABLE.
> >>>>>       
> >>>>> git master of libdrm and xf86-video-nouveau.
> >>>>>       
> >>>>> This patch.
> >>>>>       
> >>>>> Things I've figured out since the last patch...
> >>>>>       
> >>>>> On NV50 class hardware you need to have a compositing manager running
> >>>>> for Xv to work.  That means xcompmgr, metacity with composite enabled,
> >>>>> xfce (rumored to work as well, haven't tried).  If your running Gnome
> >>>>> with metacity, open gconf-editor and go to apps->metacity->general and
> >>>>> check the composite box.
> >>>>>       
> >>>>> On NV40 class hardware, you don't need the composite manager.  In fact
> >>>>> (at least with Xserver 1.6 which I'm running now), if a composite
> >>>>> manager is enabled, I'm seeing high cpu utilization from Xorg under some
> >>>>> circumstances.  I don't think this is a drm issue, but still an issue.
> >>>>> For me, if I start a video using mplayer in an xterm, cpu is fine as
> >>>>> long as that xterm is the foreground window.  If it is not the
> >>>>> foreground window, even if it isn't obscured I see the cpu utilization.
> >>>>> Disabling the composite manager makes everything fine.
> >>>>>       
> >>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch <http://people.freebsd.org/%7Ernoland/drm-nouveau-032109.patch>
> >>>>>       
> >>>>> robert.
> >>>>>       
> >>>>>           
> >>>> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation.
> >>>> It is not supported in any way.
> >>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> >>>> Select the "xorg" product for bugs you find in this release.
> >>>> Before reporting bugs in pre-release versions please check the
> >>>> latest version in the X.Org Foundation git repository.
> >>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
> >>>>
> >>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> >>>> Release Date: 2009-1-30
> >>>> X Protocol Version 11, Revision 0
> >>>> Build Operating System: FreeBSD 7.1-STABLE amd64
> >>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE
> >>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/sr
> >>>> c/sys/WSK amd64
> >>>> Build Date: 06 February 2009  04:22:44PM
> >>>>
> >>>>         Before reporting problems, check http://wiki.x.org
> >>>>         to make sure that you have the latest version.
> >>>> Markers: (--) probed, (**) from config file, (==) default setting,
> >>>>         (++) from command line, (!!) notice, (II) informational,
> >>>>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> >>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> >>>> ing config file: "xorg.conf1"
> >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>>> drm0: [ITHREAD]
> >>>> info: [drm] Allocating FIFO number 1
> >>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
> >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
> >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> >>>> (EE) Screen(s) found, but none have a usable configuration.
> >>>>
> >>>> Fatal server error:
> >>>> no screens found
> >>>>
> >>>> Please consult the The X.Org Foundation support
> >>>>          at http://wiki.x.org
> >>>>  for help.
> >>>> Please also check the log file at "/var/log/Xorg.0.log" for additional informati
> >>>> on.
> >>>>
> >>>> info: [drm] nouveau_fifo_free: freeing fifo 1
> >>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before
> >>>> destroy.Prepare for strangeness..
> >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>>>
> >>>> what can i do ?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> plain text document attachment (Xorg.0.log)
> >>>> This is a pre-release version of the X server from The X.Org Foundation.
> >>>> It is not supported in any way.
> >>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> >>>> Select the "xorg" product for bugs you find in this release.
> >>>> Before reporting bugs in pre-release versions please check the
> >>>> latest version in the X.Org Foundation git repository.
> >>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
> >>>>
> >>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> >>>> Release Date: 2009-1-30
> >>>> X Protocol Version 11, Revision 0
> >>>> Build Operating System: FreeBSD 7.1-STABLE amd64 
> >>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64
> >>>> Build Date: 06 February 2009  04:22:44PM
> >>>>  
> >>>> 	Before reporting problems, check http://wiki.x.org
> >>>> 	to make sure that you have the latest version.
> >>>> Markers: (--) probed, (**) from config file, (==) default setting,
> >>>> 	(++) from command line, (!!) notice, (II) informational,
> >>>> 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> >>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> >>>> (++) Using config file: "xorg.conf1"
> >>>> (==) No Layout section.  Using the first Screen section.
> >>>> (==) No screen section available. Using defaults.
> >>>> (**) |-->Screen "Default Screen Section" (0)
> >>>> (**) |   |-->Monitor "<default monitor>"
> >>>> (==) No device specified for screen "Default Screen Section".
> >>>> 	Using the first device section listed.
> >>>> (**) |   |-->Device "Card0"
> >>>> (==) No monitor specified for screen "Default Screen Section".
> >>>> 	Using a default monitor configuration.
> >>>> (==) Automatically adding devices
> >>>> (==) Automatically enabling devices
> >>>> (==) No FontPath specified.  Using compiled-in default.
> >>>> (==) FontPath set to:
> >>>> 	built-ins
> >>>> (==) ModulePath set to "/usr/local/lib/xorg/modules"
> >>>> (II) Cannot locate a core pointer device.
> >>>> (II) Cannot locate a core keyboard device.
> >>>> (II) The server relies on HAL to provide the list of input devices.
> >>>> 	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
> >>>> (II) Loader magic: 0xb20
> >>>> (II) Module ABI versions:
> >>>> 	X.Org ANSI C Emulation: 0.4
> >>>> 	X.Org Video Driver: 5.0
> >>>> 	X.Org XInput driver : 4.0
> >>>> 	X.Org Server Extension : 2.0
> >>>> (II) Loader running on freebsd
> >>>> (--) Using syscons driver with X support (version 2.0)
> >>>> (--) using VT number 9
> >>>>
> >>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536
> >>>>     
> >>>>         
> >>> Ok, thats a new one...
> >>>
> >>>   
> >>>       
> >>>> (II) System resource ranges:
> >>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> >>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> >>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> >>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> >>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> >>>> (II) LoadModule: "extmod"
> >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
> >>>> (II) Module extmod: vendor="X.Org Foundation"
> >>>> 	compiled for 1.5.99.902, module version = 1.0.0
> >>>> 	Module class: X.Org Server Extension
> >>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>> (II) Loading extension MIT-SCREEN-SAVER
> >>>> (II) Loading extension XFree86-VidModeExtension
> >>>> (II) Loading extension XFree86-DGA
> >>>> (II) Loading extension DPMS
> >>>> (II) Loading extension XVideo
> >>>> (II) Loading extension XVideo-MotionCompensation
> >>>> (II) Loading extension X-Resource
> >>>> (II) LoadModule: "dbe"
> >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
> >>>> (II) Module dbe: vendor="X.Org Foundation"
> >>>> 	compiled for 1.5.99.902, module version = 1.0.0
> >>>> 	Module class: X.Org Server Extension
> >>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>> (II) Loading extension DOUBLE-BUFFER
> >>>> (II) LoadModule: "glx"
> >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
> >>>> (II) Module glx: vendor="X.Org Foundation"
> >>>> 	compiled for 1.5.99.902, module version = 1.0.0
> >>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>> (==) AIGLX disabled
> >>>> (==) Exporting typical set of GLX visuals
> >>>> (II) Loading extension GLX
> >>>> (II) LoadModule: "record"
> >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
> >>>> (II) Module record: vendor="X.Org Foundation"
> >>>> 	compiled for 1.5.99.902, module version = 1.13.0
> >>>> 	Module class: X.Org Server Extension
> >>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>> (II) Loading extension RECORD
> >>>> (II) LoadModule: "dri"
> >>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
> >>>> (II) Module dri: vendor="X.Org Foundation"
> >>>> 	compiled for 1.5.99.902, module version = 1.0.0
> >>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>> (II) Loading extension XFree86-DRI
> >>>> (II) LoadModule: "nouveau"
> >>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so
> >>>> (II) Module nouveau: vendor="X.Org Foundation"
> >>>> 	compiled for 1.5.99.902, module version = 0.0.10
> >>>> 	Module class: X.Org Video Driver
> >>>> 	ABI class: X.Org Video Driver, version 5.0
> >>>> (II) NOUVEAU driver Date:   Wed Mar 18 09:36:33 2009 +1000
> >>>> (II) NOUVEAU driver for NVIDIA chipset families :
> >>>> 	RIVA TNT    (NV04)
> >>>> 	RIVA TNT2   (NV05)
> >>>> 	GeForce 256 (NV10)
> >>>> 	GeForce 2   (NV11, NV15)
> >>>> 	GeForce 4MX (NV17, NV18)
> >>>> 	GeForce 3   (NV20)
> >>>> 	GeForce 4Ti (NV25, NV28)
> >>>> 	GeForce FX  (NV3x)
> >>>> 	GeForce 6   (NV4x)
> >>>> 	GeForce 7   (G7x)
> >>>> 	GeForce 8   (G8x)
> >>>> (II) Primary Device is: PCI 01@00:00:0
> >>>> (II) resource ranges after probing:
> >>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> >>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> >>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> >>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> >>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> >>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86"
> >>>>     
> >>>>         
> >>> Hrm, NV86... I'll have to ask around about that.  Meanwhile can you send
> >>> me a pciconf -lvb which should at least show us the BAR configuration.
> >>>
> >>> Ok, my sources are telling me that this should work and that it is an
> >>> NV50, or at least should work the same...
> >>>
> >>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess.  I'm
> >>> not sure if it may be trashing the BARs somehow.
> >>>
> >>> robert.
> >>>   
> >>>       
> >> bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled
> >> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086
> >> rev=0x02 hdr=0x00
> >> vendor = 'Intel Corporation'
> >> device = '82801H (ICH8 Family) SMBus Controller'
> >> class = serial bus
> >> subclass = SMBus
> >> bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled
> >> bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled
> >> vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de
> >> rev=0xa1 hdr=0x00
> >> vendor = 'Nvidia Corp'
> >> device = 'Unknown nVidia Quadro FX 570M'
> >> class = display
> >> subclass = VGA
> >> bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled
> >>     
> >
> > Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up.  BAR 1
> > should be your framebuffer and should be where most of your memory is.
> > (This is the memory the tell you about when you buy the card, 256M,
> > 512M, etc.)  It should probably be a 64bit BAR, which is why BAR 2 isn't
> > there.  We are going to need more details on your card...
> >   
> indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M memory.
> but it recognized Quadro FX 570M with pciconfig.

So, the nouveau folks want me to get you to either boot linux and see
what lspci shows for this card, or at least install the lspci port and
see what it says.  I don't think it is going to reveal anything, but who
knows...  This is not a driver issue at this point, the BARs just don't
appear to be present.

robert.

> >   
> >> bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled
> >>     
> >
> > This one is BAR 3, which is used when it doesn't find BAR 1.
> >
> > robert.
> >
> >   
> >> bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled
> >> ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4
> >> rev=0x03 hdr=0x00
> >> vendor = 'Broadcom Corporation'
> >> device = 'BCM94321KFBG Broadcom 4321AGN 802.11a/b/g/draft-n Wi-Fi Solution'
> >> class = network
> >> bar [10] = type Memory, range 64, base 0xf9ffc000, size 16384, enabled
> >> bar [18] = type Prefetchable Memory, range 64, base 0xf0000000, size
> >> 1048576, enabled
> >> bge0@pci0:9:0:0: class=0x020000 card=0x01fe1028 chip=0x167314e4 rev=0x02
> >> hdr=0x00
> >> vendor = 'Broadcom Corporation'
> >> device = 'B57xx Broadcom NetXtreme Gigabit Ethernet'
> >> class = network
> >> subclass = ethernet
> >> bar [10] = type Memory, range 64, base 0xf9bf0000, size 65536, enabled
> >> cbb0@pci0:3:1:0: class=0x060700 card=0x01fe1028 chip=0x71351217 rev=0x21
> >> hdr=0x02
> >> vendor = 'O2 Micro Inc'
> >> device = 'OZ711EZ1 MemoryCardBus Controller'
> >> class = bridge
> >> subclass = PCI-CardBus
> >> bar [10] = type Memory, range 32, base 0xf9a00000, size 4096, enabled
> >> fwohci0@pci0:3:1:4: class=0x0c0010 card=0x01fe1028 chip=0x00f71217
> >> rev=0x02 hdr=0x00
> >> vendor = 'O2 Micro Inc'
> >> device = '0x00f71217 1394 Open Host Controller Interface'
> >> class = serial bus
> >> subclass = FireWire
> >> bar [10] = type Memory, range 32, base 0xf9aff000, size 4096, enabled
> >> bar [14] = type Memory, range 32, base 0xf9afe800, size 2048, enabled
> >>
> >> and follow your intrudction.still pain me :(
> >>
> >> (++) Using config file: "xorg.conf1"
> >> drm0: <NVidia Display Adapter> on vgapci0
> >> info: [drm] Detected an NV50 generation card (0x086900a2)
> >> vgapci0: child drm0 requested pci_enable_busmaster
> >> info: [drm] Initialized nouveau 0.0.12 20060213
> >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >> drm0: [ITHREAD]
> >> info: [drm] Allocating FIFO number 1
> >> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII,
> >> invalid/inactiv
> >> e channel id 128
> >> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo:
> >> [drm] , nSt
> >> atus:info: [drm]
> >> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data
> >> 0x00000000:0x00
> >> 000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1:
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2:
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000
> >> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000
> >> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
> >> info: [drm] PFIFO_DMA_PUSHER - Ch 1
> >> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> >> (EE) Screen(s) found, but none have a usable configuration.
> >>
> >> Fatal server error:
> >> no screens found
> >>
> >> Please consult the The X.Org Foundation support
> >> at http://wiki.x.org
> >> for help.
> >> Please also check the log file at "/var/log/Xorg.0.log" for additional
> >> informati
> >> on.
> >>
> >> info: [drm] nouveau_fifo_free: freeing fifo 1
> >> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1
> >> before d
> >> estroy.Prepare for strangeness..
> >> info: [drm] PFIFO_DMA_PUSHER - Ch 127
> >> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>
> >>     
> >>>   
> >>>       
> >>>> (II) Loading sub module "int10"
> >>>> (II) LoadModule: "int10"
> >>>> (II) Loading /usr/local/lib/xorg/modules//libint10.so
> >>>> (II) Module int10: vendor="X.Org Foundation"
> >>>> 	compiled for 1.5.99.902, module version = 1.0.0
> >>>> 	ABI class: X.Org Video Driver, version 5.0
> >>>> (II) NOUVEAU(0): Initializing int10
> >>>> (==) NOUVEAU(0): Write-combining range (0xa0000,0x20000) was already clear
> >>>> (==) NOUVEAU(0): Write-combining range (0xc0000,0x40000) was already clear
> >>>> (II) NOUVEAU(0): Primary V_BIOS segment is: 0xc000
> >>>> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
> >>>> drmOpenDevice: node name is /dev/dri/card0
> >>>> drmOpenDevice: open result is 10, (OK)
> >>>> drmOpenDevice: node name is /dev/dri/card0
> >>>> drmOpenDevice: open result is 10, (OK)
> >>>> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
> >>>> drmOpenDevice: node name is /dev/dri/card0
> >>>> drmOpenDevice: open result is 10, (OK)
> >>>> drmOpenByBusid: drmOpenMinor returns 10
> >>>> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
> >>>> (II) [drm] DRM interface version 1.2
> >>>> (II) [drm] DRM open master succeeded.
> >>>> (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.12
> >>>> (--) NOUVEAU(0): [drm] kernel modesetting not available
> >>>> (--) NOUVEAU(0): VESA-HACK: Console VGA mode is 0x3
> >>>> (II) NOUVEAU(0): Creating default Display subsection in Screen section
> >>>> 	"Default Screen Section" for depth/fbbpp 24/32
> >>>> (==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32
> >>>> (==) NOUVEAU(0): RGB weight 888
> >>>> (==) NOUVEAU(0): Default visual is TrueColor
> >>>> (II) Loading sub module "vgahw"
> >>>> (II) LoadModule: "vgahw"
> >>>> (II) Loading /usr/local/lib/xorg/modules//libvgahw.so
> >>>> (II) Module vgahw: vendor="X.Org Foundation"
> >>>> 	compiled for 1.5.99.902, module version = 0.1.0
> >>>> 	ABI class: X.Org Video Driver, version 5.0
> >>>> (==) NOUVEAU(0): Randr1.2 support enabled
> >>>> (==) NOUVEAU(0): Using HW cursor
> >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> >>>> (==) NOUVEAU(0): Write-combining range (0x0,0x1000) was already clear
> >>>> (II) UnloadModule: "nouveau"
> >>>> (II) UnloadModule: "vgahw"
> >>>> (II) Unloading /usr/local/lib/xorg/modules//libvgahw.so
> >>>> (II) UnloadModule: "int10"
> >>>> (II) Unloading /usr/local/lib/xorg/modules//libint10.so
> >>>> (EE) Screen(s) found, but none have a usable configuration.
> >>>>
> >>>> Fatal server error:
> >>>> no screens found
> >>>>
> >>>> Please consult the The X.Org Foundation support 
> >>>> 	 at http://wiki.x.org
> >>>>  for help. 
> >>>> Please also check the log file at "/var/log/Xorg.0.log" for additional information.
> >>>>
> >>>>     
> >>>>         
> 
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/36478e38/attachment.pgp
From peterjeremy at optushome.com.au  Wed Mar 25 00:37:43 2009
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Wed Mar 25 00:37:50 2009
Subject: support quality (Re: dump | restore fails: unknown tape header
	type 1853384566)
In-Reply-To: <49C9B330.10500@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251429.40578.doconnor@gsoft.com.au>
	<49C9AD6D.30305@aldan.algebra.com>
	<200903251452.42301.doconnor@gsoft.com.au>
	<49C9B330.10500@aldan.algebra.com>
Message-ID: <20090325073732.GA77949@server.vk2pj.dyndns.org>

On 2009-Mar-25 00:29:36 -0400, "Mikhail T." <mi+thun@aldan.algebra.com> wrote:
>Daniel O'Connor ???????(??):
>> People ARE helping you, just because they haven't come up with an answer is no 
>> reason to send snarky comments to the list.
>>
>No, sorry, people aren't. They are trying, yes, but not even close.

People are _trying_ to help you.  The problem is that there's no real
leads on where the problem might be so people are clutching at straws.
It's virtually impossible to debug that sort of problem remotely and
AFAIK no-one has been able to reproduce it.  I've been using dump for
decades on a variety of different systems and don't recall ever seeing
the problem you are having.

Are you restoring to an empty (freshly newfs'd) filesystem?  The '-r'
option to restore is only supposed to be used this way (though I've
ignored this in the past).

Are there any snapshots in the source filesystem?

Are you able to reproduce the problem using a different source filesystem?
(preferably something small)

Can you rule out hardware problems?

Have you tried moving the source disk to another computer and seeing
if it will dump/restore there?

Do you have enough spare space to be able to dd the problematic FS
somewhere else for experimenting?  If so, does the problem go away
if you empty all the files (so all the files are there but all are
zero-length)?  Or if you replace all the file contents with NULs?

>It is fairly obvious by now, that no real help will be forthcoming,
>for whatever reason.

Throwing a hissy-fit won't help.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/7fc44b4a/attachment.pgp
From doconnor at gsoft.com.au  Wed Mar 25 00:58:15 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Mar 25 00:58:22 2009
Subject: support quality (Re: dump | restore fails: unknown tape header
	type 1853384566)
In-Reply-To: <49C9B330.10500@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251452.42301.doconnor@gsoft.com.au>
	<49C9B330.10500@aldan.algebra.com>
Message-ID: <200903251820.54749.doconnor@gsoft.com.au>

On Wednesday 25 March 2009 14:59:36 Mikhail T. wrote:
> Daniel O'Connor ???????(??):
> > People ARE helping you, just because they haven't come up with an answer
> > is no reason to send snarky comments to the list.
>
> No, sorry, people aren't. They are trying, yes, but not even close. The
> suggestion to eliminate the -a switch (a no-op, in fact) was
> particularly unhelpful -- and deserving of mockery. Later on someone
> with a similar problem will find this thread with a search engine and
> will be trying to follow the posted advices -- to no avail, of course,
> plunging FreeBSD further into disrepute.

I don't see how whining about it's going to change it. Insulting people for 
having a helpful attitude (even if it didn't solve your problem) is not going 
to reward them for their time and effort.

> > Outrage (fake or otherwise) that people don't seem to be taking your
> > particular problem seriously is unhelpful and probably
> > counter-productive.
>
> It is fairly obvious by now, that no real help will be forthcoming, for
> whatever reason. Thus any talk of "productivity" is moot. Thanks for
> trying.

Except that I offered you a way of transferring your files that would preserve 
file flags and so on.

Yes, dump is broken for you, deal with it. It is quite possible your FS is 
corrupt, and/or your disk is damaged.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/bb81e316/attachment.pgp
From admin at kkip.pl  Wed Mar 25 01:31:56 2009
From: admin at kkip.pl (Bartosz Stec)
Date: Wed Mar 25 01:32:04 2009
Subject: support quality (Re: dump | restore fails: unknown tape header
 type 1853384566)
In-Reply-To: <200903251820.54749.doconnor@gsoft.com.au>
References: <49C83673.3000604@aldan.algebra.com>	<200903251452.42301.doconnor@gsoft.com.au>	<49C9B330.10500@aldan.algebra.com>
	<200903251820.54749.doconnor@gsoft.com.au>
Message-ID: <49C9E635.5010106@kkip.pl>


> Yes, dump is broken for you, deal with it. It is quite possible your FS is 
> corrupt, and/or your disk is damaged.
>
>   
..and/or it is some other hardware problem, maybe you also should test 
your memory with memtest or something similiar? I'm using dump/restore 
very frequently and I had never seen such problem. Neither on -RELAESE, 
-STABLE, nor -CURRENT.
So I think you should make sure that your problem is not 
hardware/filesystem dependent before you point dump/restore as a couse 
of the problem. Peter Jeremy already gives you good hints to do that.

-- 
Bartosz Stec.

From wsk at gddsn.org.cn  Wed Mar 25 01:37:55 2009
From: wsk at gddsn.org.cn (wsk)
Date: Wed Mar 25 01:38:11 2009
Subject: [PREVIEW] Nouveau on FreeBSD (Take 2)
In-Reply-To: <1237961497.1828.2.camel@balrog.2hip.net>
References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn>	
	<49C6E5C6.60306@gddsn.org.cn>
	<1237798914.2110.24.camel@balrog.2hip.net>	
	<49C85F4E.5050002@gddsn.org.cn>
	<1237882591.1771.26.camel@balrog.2hip.net>	
	<49C97EEB.4090607@gddsn.org.cn>
	<1237961497.1828.2.camel@balrog.2hip.net>
Message-ID: <49C9ED34.20504@gddsn.org.cn>

Robert Noland wrote:
> On Wed, 2009-03-25 at 08:46 +0800, wsk wrote:
>   
>> Robert Noland wrote:
>>     
>>> On Tue, 2009-03-24 at 12:19 +0800, wsk wrote:
>>>   
>>>       
>>>> Robert Noland wrote:
>>>>     
>>>>         
>>>>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>>> Ok, this patch should work on NV50 chips also.
>>>>>>>       
>>>>>>> What you get is EXA and Xv.
>>>>>>>       
>>>>>>> You still need:
>>>>>>>       
>>>>>>> A recent -CURRENT or -STABLE.
>>>>>>>       
>>>>>>> git master of libdrm and xf86-video-nouveau.
>>>>>>>       
>>>>>>> This patch.
>>>>>>>       
>>>>>>> Things I've figured out since the last patch...
>>>>>>>       
>>>>>>> On NV50 class hardware you need to have a compositing manager running
>>>>>>> for Xv to work.  That means xcompmgr, metacity with composite enabled,
>>>>>>> xfce (rumored to work as well, haven't tried).  If your running Gnome
>>>>>>> with metacity, open gconf-editor and go to apps->metacity->general and
>>>>>>> check the composite box.
>>>>>>>       
>>>>>>> On NV40 class hardware, you don't need the composite manager.  In fact
>>>>>>> (at least with Xserver 1.6 which I'm running now), if a composite
>>>>>>> manager is enabled, I'm seeing high cpu utilization from Xorg under some
>>>>>>> circumstances.  I don't think this is a drm issue, but still an issue.
>>>>>>> For me, if I start a video using mplayer in an xterm, cpu is fine as
>>>>>>> long as that xterm is the foreground window.  If it is not the
>>>>>>> foreground window, even if it isn't obscured I see the cpu utilization.
>>>>>>> Disabling the composite manager makes everything fine.
>>>>>>>       
>>>>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch <http://people.freebsd.org/%7Ernoland/drm-nouveau-032109.patch>
>>>>>>>       
>>>>>>> robert.
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation.
>>>>>> It is not supported in any way.
>>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
>>>>>> Select the "xorg" product for bugs you find in this release.
>>>>>> Before reporting bugs in pre-release versions please check the
>>>>>> latest version in the X.Org Foundation git repository.
>>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
>>>>>>
>>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
>>>>>> Release Date: 2009-1-30
>>>>>> X Protocol Version 11, Revision 0
>>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64
>>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE
>>>>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/sr
>>>>>> c/sys/WSK amd64
>>>>>> Build Date: 06 February 2009  04:22:44PM
>>>>>>
>>>>>>         Before reporting problems, check http://wiki.x.org
>>>>>>         to make sure that you have the latest version.
>>>>>> Markers: (--) probed, (**) from config file, (==) default setting,
>>>>>>         (++) from command line, (!!) notice, (II) informational,
>>>>>>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>>>>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
>>>>>> ing config file: "xorg.conf1"
>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>>>>> drm0: [ITHREAD]
>>>>>> info: [drm] Allocating FIFO number 1
>>>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
>>>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
>>>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
>>>>>> (EE) Screen(s) found, but none have a usable configuration.
>>>>>>
>>>>>> Fatal server error:
>>>>>> no screens found
>>>>>>
>>>>>> Please consult the The X.Org Foundation support
>>>>>>          at http://wiki.x.org
>>>>>>  for help.
>>>>>> Please also check the log file at "/var/log/Xorg.0.log" for additional informati
>>>>>> on.
>>>>>>
>>>>>> info: [drm] nouveau_fifo_free: freeing fifo 1
>>>>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before
>>>>>> destroy.Prepare for strangeness..
>>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>>>>>
>>>>>> what can i do ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> plain text document attachment (Xorg.0.log)
>>>>>> This is a pre-release version of the X server from The X.Org Foundation.
>>>>>> It is not supported in any way.
>>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
>>>>>> Select the "xorg" product for bugs you find in this release.
>>>>>> Before reporting bugs in pre-release versions please check the
>>>>>> latest version in the X.Org Foundation git repository.
>>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
>>>>>>
>>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
>>>>>> Release Date: 2009-1-30
>>>>>> X Protocol Version 11, Revision 0
>>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 
>>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64
>>>>>> Build Date: 06 February 2009  04:22:44PM
>>>>>>  
>>>>>> 	Before reporting problems, check http://wiki.x.org
>>>>>> 	to make sure that you have the latest version.
>>>>>> Markers: (--) probed, (**) from config file, (==) default setting,
>>>>>> 	(++) from command line, (!!) notice, (II) informational,
>>>>>> 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>>>>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
>>>>>> (++) Using config file: "xorg.conf1"
>>>>>> (==) No Layout section.  Using the first Screen section.
>>>>>> (==) No screen section available. Using defaults.
>>>>>> (**) |-->Screen "Default Screen Section" (0)
>>>>>> (**) |   |-->Monitor "<default monitor>"
>>>>>> (==) No device specified for screen "Default Screen Section".
>>>>>> 	Using the first device section listed.
>>>>>> (**) |   |-->Device "Card0"
>>>>>> (==) No monitor specified for screen "Default Screen Section".
>>>>>> 	Using a default monitor configuration.
>>>>>> (==) Automatically adding devices
>>>>>> (==) Automatically enabling devices
>>>>>> (==) No FontPath specified.  Using compiled-in default.
>>>>>> (==) FontPath set to:
>>>>>> 	built-ins
>>>>>> (==) ModulePath set to "/usr/local/lib/xorg/modules"
>>>>>> (II) Cannot locate a core pointer device.
>>>>>> (II) Cannot locate a core keyboard device.
>>>>>> (II) The server relies on HAL to provide the list of input devices.
>>>>>> 	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
>>>>>> (II) Loader magic: 0xb20
>>>>>> (II) Module ABI versions:
>>>>>> 	X.Org ANSI C Emulation: 0.4
>>>>>> 	X.Org Video Driver: 5.0
>>>>>> 	X.Org XInput driver : 4.0
>>>>>> 	X.Org Server Extension : 2.0
>>>>>> (II) Loader running on freebsd
>>>>>> (--) Using syscons driver with X support (version 2.0)
>>>>>> (--) using VT number 9
>>>>>>
>>>>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Ok, thats a new one...
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>>> (II) System resource ranges:
>>>>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
>>>>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
>>>>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
>>>>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
>>>>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
>>>>>> (II) LoadModule: "extmod"
>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
>>>>>> (II) Module extmod: vendor="X.Org Foundation"
>>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
>>>>>> 	Module class: X.Org Server Extension
>>>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>>>> (II) Loading extension MIT-SCREEN-SAVER
>>>>>> (II) Loading extension XFree86-VidModeExtension
>>>>>> (II) Loading extension XFree86-DGA
>>>>>> (II) Loading extension DPMS
>>>>>> (II) Loading extension XVideo
>>>>>> (II) Loading extension XVideo-MotionCompensation
>>>>>> (II) Loading extension X-Resource
>>>>>> (II) LoadModule: "dbe"
>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
>>>>>> (II) Module dbe: vendor="X.Org Foundation"
>>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
>>>>>> 	Module class: X.Org Server Extension
>>>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>>>> (II) Loading extension DOUBLE-BUFFER
>>>>>> (II) LoadModule: "glx"
>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
>>>>>> (II) Module glx: vendor="X.Org Foundation"
>>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
>>>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>>>> (==) AIGLX disabled
>>>>>> (==) Exporting typical set of GLX visuals
>>>>>> (II) Loading extension GLX
>>>>>> (II) LoadModule: "record"
>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
>>>>>> (II) Module record: vendor="X.Org Foundation"
>>>>>> 	compiled for 1.5.99.902, module version = 1.13.0
>>>>>> 	Module class: X.Org Server Extension
>>>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>>>> (II) Loading extension RECORD
>>>>>> (II) LoadModule: "dri"
>>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
>>>>>> (II) Module dri: vendor="X.Org Foundation"
>>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
>>>>>> 	ABI class: X.Org Server Extension, version 2.0
>>>>>> (II) Loading extension XFree86-DRI
>>>>>> (II) LoadModule: "nouveau"
>>>>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so
>>>>>> (II) Module nouveau: vendor="X.Org Foundation"
>>>>>> 	compiled for 1.5.99.902, module version = 0.0.10
>>>>>> 	Module class: X.Org Video Driver
>>>>>> 	ABI class: X.Org Video Driver, version 5.0
>>>>>> (II) NOUVEAU driver Date:   Wed Mar 18 09:36:33 2009 +1000
>>>>>> (II) NOUVEAU driver for NVIDIA chipset families :
>>>>>> 	RIVA TNT    (NV04)
>>>>>> 	RIVA TNT2   (NV05)
>>>>>> 	GeForce 256 (NV10)
>>>>>> 	GeForce 2   (NV11, NV15)
>>>>>> 	GeForce 4MX (NV17, NV18)
>>>>>> 	GeForce 3   (NV20)
>>>>>> 	GeForce 4Ti (NV25, NV28)
>>>>>> 	GeForce FX  (NV3x)
>>>>>> 	GeForce 6   (NV4x)
>>>>>> 	GeForce 7   (G7x)
>>>>>> 	GeForce 8   (G8x)
>>>>>> (II) Primary Device is: PCI 01@00:00:0
>>>>>> (II) resource ranges after probing:
>>>>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
>>>>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
>>>>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
>>>>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
>>>>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
>>>>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86"
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Hrm, NV86... I'll have to ask around about that.  Meanwhile can you send
>>>>> me a pciconf -lvb which should at least show us the BAR configuration.
>>>>>
>>>>> Ok, my sources are telling me that this should work and that it is an
>>>>> NV50, or at least should work the same...
>>>>>
>>>>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess.  I'm
>>>>> not sure if it may be trashing the BARs somehow.
>>>>>
>>>>> robert.
>>>>>   
>>>>>       
>>>>>           
>>>> bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled
>>>> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086
>>>> rev=0x02 hdr=0x00
>>>> vendor = 'Intel Corporation'
>>>> device = '82801H (ICH8 Family) SMBus Controller'
>>>> class = serial bus
>>>> subclass = SMBus
>>>> bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled
>>>> bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled
>>>> vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de
>>>> rev=0xa1 hdr=0x00
>>>> vendor = 'Nvidia Corp'
>>>> device = 'Unknown nVidia Quadro FX 570M'
>>>> class = display
>>>> subclass = VGA
>>>> bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled
>>>>     
>>>>         
>>> Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up.  BAR 1
>>> should be your framebuffer and should be where most of your memory is.
>>> (This is the memory the tell you about when you buy the card, 256M,
>>> 512M, etc.)  It should probably be a 64bit BAR, which is why BAR 2 isn't
>>> there.  We are going to need more details on your card...
>>>   
>>>       
>> indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M memory.
>> but it recognized Quadro FX 570M with pciconfig.
>>     
>
> So, the nouveau folks want me to get you to either boot linux and see
> what lspci shows for this card, or at least install the lspci port and
> see what it says.  I don't think it is going to reveal anything, but who
> knows...  This is not a driver issue at this point, the BARs just don't
> appear to be present.
>
> robert.
>
>   
ok,here's my lspci -v messags with linux Fedora live CD :-)
and thanks your Re


01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M
(rev a1) (prog-if 00 [VGA controller])
Subsystem: Dell Device 01fe
Flags: bus master, fast devsel, latency 0, IRQ 5
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at df00 [size=128]
[virtual] Expansion ROM at fc000000 [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1
Enable-
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [100] Virtual Channel <?>
Capabilities: [128] Power Budgeting <?>
Capabilities: [600] Vendor Specific Information <?>
Kernel modules: nvidiafb

0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n
(rev 03)
Subsystem: Dell Wireless 1500 Draft 802.11n WLAN Mini-card
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
Memory at f0000000 (64-bit, prefetchable) [size=1M]
Capabilities: [40] Power Management version 2
Capabilities: [58] Vendor Specific Information <?>
Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Count=1/1
Enable-
Capabilities: [d0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSVoil-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
ECRC- UnsupReq- ACSVoil-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSVoil-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [13c] Virtual Channel <?>
Capabilities: [160] Device Serial Number 1c-00-a4-ff-ff-26-df-c0
Capabilities: [16c] Power Budgeting <?>
Kernel driver in use: b43-pci-bridge
Kernel modules: ssb

>>>   
>>>       
>>>> bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled
>>>>     
>>>>         
>>> This one is BAR 3, which is used when it doesn't find BAR 1.
>>>
>>> robert.
>>>
>>>   
>>>       
>>>> bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled
>>>> ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4
>>>> rev=0x03 hdr=0x00
>>>>
>>>> and follow your intrudction.still pain me :(
>>>>
>>>> (++) Using config file: "xorg.conf1"
>>>> drm0: <NVidia Display Adapter> on vgapci0
>>>> info: [drm] Detected an NV50 generation card (0x086900a2)
>>>> vgapci0: child drm0 requested pci_enable_busmaster
>>>> info: [drm] Initialized nouveau 0.0.12 20060213
>>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>>> drm0: [ITHREAD]
>>>> info: [drm] Allocating FIFO number 1
>>>> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII,
>>>> invalid/inactiv
>>>> e channel id 128
>>>> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo:
>>>> [drm] , nSt
>>>> atus:info: [drm]
>>>> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data
>>>> 0x00000000:0x00
>>>> 000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1:
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2:
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000
>>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000
>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
>>>> (EE) Screen(s) found, but none have a usable configuration.
>>>>
>>>> Fatal server error:
>>>> no screens found
>>>>
>>>> Please consult the The X.Org Foundation support
>>>> at http://wiki.x.org
>>>> for help.
>>>> Please also check the log file at "/var/log/Xorg.0.log" for additional
>>>> informati
>>>> on.
>>>>
>>>> info: [drm] nouveau_fifo_free: freeing fifo 1
>>>> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1
>>>> before d
>>>> estroy.Prepare for strangeness..
>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 127
>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
>>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
>>>>
>>>>     

From doconnor at gsoft.com.au  Wed Mar 25 01:55:48 2009
From: doconnor at gsoft.com.au (Daniel O'Connor)
Date: Wed Mar 25 01:56:00 2009
Subject: support quality (Re: dump | restore fails: unknown tape header
	type 1853384566)
In-Reply-To: <49C9E635.5010106@kkip.pl>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251820.54749.doconnor@gsoft.com.au>
	<49C9E635.5010106@kkip.pl>
Message-ID: <200903251925.36108.doconnor@gsoft.com.au>

On Wednesday 25 March 2009 18:37:17 Bartosz Stec wrote:
> > Yes, dump is broken for you, deal with it. It is quite possible your FS
> > is corrupt, and/or your disk is damaged.
>
> ..and/or it is some other hardware problem, maybe you also should test
> your memory with memtest or something similiar? I'm using dump/restore
> very frequently and I had never seen such problem. Neither on -RELAESE,
> -STABLE, nor -CURRENT.
> So I think you should make sure that your problem is not
> hardware/filesystem dependent before you point dump/restore as a couse
> of the problem. Peter Jeremy already gives you good hints to do that.

One other thing would be to make absolutely sure that your version of dump & 
restore are in sync, the are very machine/version dependent.

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/7feff92e/attachment.pgp
From sean at gothic.net.au  Wed Mar 25 04:56:55 2009
From: sean at gothic.net.au (Sean)
Date: Wed Mar 25 04:57:28 2009
Subject: support quality (Re: dump | restore fails: unknown tape header
	type 1853384566)
In-Reply-To: <200903251925.36108.doconnor@gsoft.com.au>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251820.54749.doconnor@gsoft.com.au>
	<49C9E635.5010106@kkip.pl>
	<200903251925.36108.doconnor@gsoft.com.au>
Message-ID: <A8C64471-92EC-49D6-9BFE-022FAA058CBA@gothic.net.au>


On 25/03/2009, at 7:55 PM, Daniel O'Connor wrote:

> On Wednesday 25 March 2009 18:37:17 Bartosz Stec wrote:
>>> Yes, dump is broken for you, deal with it. It is quite possible  
>>> your FS
>>> is corrupt, and/or your disk is damaged.
>>
>> ..and/or it is some other hardware problem, maybe you also should  
>> test
>> your memory with memtest or something similiar? I'm using dump/ 
>> restore
>> very frequently and I had never seen such problem. Neither on - 
>> RELAESE,
>> -STABLE, nor -CURRENT.
>> So I think you should make sure that your problem is not
>> hardware/filesystem dependent before you point dump/restore as a  
>> couse
>> of the problem. Peter Jeremy already gives you good hints to do that.
>
> One other thing would be to make absolutely sure that your version  
> of dump &
> restore are in sync, the are very machine/version dependent.
>

And the system is compiled without strange CFLAGS in /etc/make.conf

Great way to cause inexplicable problems because an unsafe  
optimisation ran rampant, which is really noticeable when it's two  
programs that have to be in sync.


> -- 
> 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
>

From jacks at sage-american.com  Wed Mar 25 05:32:44 2009
From: jacks at sage-american.com (Jack L. Stone)
Date: Wed Mar 25 05:32:52 2009
Subject: support quality (Re: dump | restore fails: unknown tape
 headertype 1853384566)
In-Reply-To: <200903251925.36108.doconnor@gsoft.com.au>
References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com>
	<200903251820.54749.doconnor@gsoft.com.au>
	<49C9E635.5010106@kkip.pl>
Message-ID: <3.0.1.32.20090325072137.00ee6b48@sage-american.com>

At 07:25 PM 3.25.2009 +1030, Daniel O'Connor wrote:
>On Wednesday 25 March 2009 18:37:17 Bartosz Stec wrote:
>> > Yes, dump is broken for you, deal with it. It is quite possible your FS
>> > is corrupt, and/or your disk is damaged.
>>
>> ..and/or it is some other hardware problem, maybe you also should test
>> your memory with memtest or something similiar? I'm using dump/restore
>> very frequently and I had never seen such problem. Neither on -RELAESE,
>> -STABLE, nor -CURRENT.
>> So I think you should make sure that your problem is not
>> hardware/filesystem dependent before you point dump/restore as a couse
>> of the problem. Peter Jeremy already gives you good hints to do that.
>
>One other thing would be to make absolutely sure that your version of dump & 
>restore are in sync, the are very machine/version dependent.
>
>-- 

I've been watching this thread with some interest since we've had some
similar problems with dump/restore which we use every morning via cron
scripts on a number of servers to produce bootable clones as part of our
backup program. Have been doing this for years and also never saw a problem
as most of you say. We prefer dump/restore for backups.

However, last month upon upon upgrading those servers from FBSD-6.3px
(RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers
had a similar problem as the original poster while the other half did not.
All of the servers (rackmounts) use the same (type) hardware. We spent many
hours trying to solve the problem with those that failed to dump/restore.
Also, searched for any others with the problem and only found a very few,
but without solutions to this issue. (Indeed, the only one was a reference
to any efforts to restore an older OS version which didn't apply here).

And, indeed we tried everything suggested here to fix the proble without
success. Sometimes the problem was dump which would reach 99% and never
finish -- it would stick there and would overlap with another cron start
the next day, and the next day, and the next day. (The servers that did
work fooled us and we found out about this issue on the others when the
overlaps appeared and drew our attention). That's when our work to try and
solve the issues started and went on for days.

Our script that has always worked contained this (after scraping and making
fresh FS):
/sbin/dump -D /root/dumpdates -0auL -f - / | /sbin/restore -rf -

Indeed, the first thing we did was to remove the pipe and tried to restore
from a file. However, because the dumps would not go past the 99%, no file
to restore from! There were some exceptions when the dump would complete,
but was not reliable. When these reached the restore level, restore would
go crazy with errors.

SOLUTION
The "clones" are a very important pasrt of our backup program. Since the
dump side of the problems simply stuck and provided no error message at all
and the errors from any restores were not useful, our only solution was to
revert back to FBSD-6.3 on those servers with this issue and dump/restore
went back to working again. We left those that were working on FBSD-7.0-R
and they continue to work okay.

We could only conclude that the problem was perhaps something with
hardeware, perhaps the way memory was handled in 7.0, but that is only a
guess.

Once again, every suggestion on this thread was tried during our long
efforts to fix the issue. Perhaps there is yet another suggestion? In the
meantime, we've decided to wait for 7.2R (7.1 did not fix the problems
either).

/Jack

(^_^)
Happy trails,
Jack L. Stone

System Admin
Sage-american
From antik at bsd.ee  Wed Mar 25 06:54:32 2009
From: antik at bsd.ee (Andrei Kolu)
Date: Wed Mar 25 06:54:39 2009
Subject: 32bit filesystem limitations
Message-ID: <49CA3795.609@bsd.ee>

Hi,

I have trouble to create FreeBSD 7.1 i386 partition/slice to 3Ware 8port 
raid kontroller with 8x500GB drives attached to it. Raid 5 massive is 
3,1TB in size and during sysinstall installation I select whole 
available space but after restart I can access only 1,2TB from it. What 
is the problem?
From mike at sentex.net  Wed Mar 25 07:01:22 2009
From: mike at sentex.net (Mike Tancsa)
Date: Wed Mar 25 07:01:29 2009
Subject: 32bit filesystem limitations
In-Reply-To: <49CA3795.609@bsd.ee>
References: <49CA3795.609@bsd.ee>
Message-ID: <200903251400.n2PE0lpn017999@lava.sentex.ca>

At 09:54 AM 3/25/2009, Andrei Kolu wrote:
>Hi,
>
>I have trouble to create FreeBSD 7.1 i386 partition/slice to 3Ware 
>8port raid kontroller with 8x500GB drives attached to it. Raid 5 
>massive is 3,1TB in size and during sysinstall installation I select 
>whole available space but after restart I can access only 1,2TB from 
>it. What is the problem?


Hi,
         You need to use gpart for larger partitions than 1.2TB.  eg. 
on my backup server, I have

% df
Filesystem  1K-blocks       Used      Avail Capacity  Mounted on
/dev/da0s1a    1982798    483298    1340878    26%    /
devfs                1         1          0   100%    /dev
/dev/da1s1d   30462636  10321258   17704368    37%    /usr
/dev/da1s1e   35038378   3770818   28464490    12%    /var
/dev/da0s1d   64210664  44212108   14861704    75%    /var/db
/dev/da2p1  2761826016 716207954 1824671982    28%    /backup


         ---Mike

>_______________________________________________
>freebsd-stable@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

From ivoras at freebsd.org  Wed Mar 25 07:04:37 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Wed Mar 25 07:04:44 2009
Subject: 32bit filesystem limitations
In-Reply-To: <49CA3795.609@bsd.ee>
References: <49CA3795.609@bsd.ee>
Message-ID: <gqddl4$bd2$1@ger.gmane.org>

Andrei Kolu wrote:
> Hi,
> 
> I have trouble to create FreeBSD 7.1 i386 partition/slice to 3Ware 8port
> raid kontroller with 8x500GB drives attached to it. Raid 5 massive is
> 3,1TB in size and during sysinstall installation I select whole
> available space but after restart I can access only 1,2TB from it. What
> is the problem?

MS-DOS fdisk partitions and bsdlabel partitions both have 32-bit
limitations on the file system size. You should use gpart to partition
the large volume. That is, except if you want to boot from it also -
then it's a bit problematic; it's best to create two logical drives in
your RAID controller - one small drive for the OS (something like 8 GB
to keep the ports and all) and the rest for the data.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/f637b7f2/signature.pgp
From jhb at freebsd.org  Wed Mar 25 07:20:08 2009
From: jhb at freebsd.org (John Baldwin)
Date: Wed Mar 25 07:20:16 2009
Subject: 32bit filesystem limitations
In-Reply-To: <gqddl4$bd2$1@ger.gmane.org>
References: <49CA3795.609@bsd.ee> <gqddl4$bd2$1@ger.gmane.org>
Message-ID: <200903251019.03312.jhb@freebsd.org>

On Wednesday 25 March 2009 10:03:36 am Ivan Voras wrote:
> Andrei Kolu wrote:
> > Hi,
> > 
> > I have trouble to create FreeBSD 7.1 i386 partition/slice to 3Ware 8port
> > raid kontroller with 8x500GB drives attached to it. Raid 5 massive is
> > 3,1TB in size and during sysinstall installation I select whole
> > available space but after restart I can access only 1,2TB from it. What
> > is the problem?
> 
> MS-DOS fdisk partitions and bsdlabel partitions both have 32-bit
> limitations on the file system size. You should use gpart to partition
> the large volume. That is, except if you want to boot from it also -
> then it's a bit problematic; it's best to create two logical drives in
> your RAID controller - one small drive for the OS (something like 8 GB
> to keep the ports and all) and the rest for the data.

Well, you need to use GPT, either via gpart(8) or gpt(8).  You can then use 
gptboot to boot from that volume if desired.

-- 
John Baldwin
From antik at bsd.ee  Wed Mar 25 07:50:00 2009
From: antik at bsd.ee (Andrei Kolu)
Date: Wed Mar 25 07:50:07 2009
Subject: 32bit filesystem limitations
In-Reply-To: <gqddl4$bd2$1@ger.gmane.org>
References: <49CA3795.609@bsd.ee> <gqddl4$bd2$1@ger.gmane.org>
Message-ID: <49CA4498.2020007@bsd.ee>

Ivan Voras wrote:
> Andrei Kolu wrote:
>   
>> Hi,
>>
>> I have trouble to create FreeBSD 7.1 i386 partition/slice to 3Ware 8port
>> raid kontroller with 8x500GB drives attached to it. Raid 5 massive is
>> 3,1TB in size and during sysinstall installation I select whole
>> available space but after restart I can access only 1,2TB from it. What
>> is the problem?
>>     
>
> MS-DOS fdisk partitions and bsdlabel partitions both have 32-bit
> limitations on the file system size. You should use gpart to partition
> the large volume. That is, except if you want to boot from it also -
> then it's a bit problematic; it's best to create two logical drives in
> your RAID controller - one small drive for the OS (something like 8 GB
> to keep the ports and all) and the rest for the data.
>
>   
I created 20GB slice for system and selected everything else for /data 
but after restart I see again 1,2TB /data. After second sysinstall 
attempt I created another 2TB slice and now at least I can use whole 
space. Not so good but it works.

Second attempt:
Now I reserved 20GB for "boot volume" from 3Ware 9650SE controller and 
looks like it ...oops...did it again....deem.

# df -H
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/da0s1a    2.1G    146M    1.8G     8%    /
devfs          1.0k    1.0k      0B   100%    /dev
/dev/da1s1d    1.2T    4.1k    1.1T     0%    /data
/dev/da0s1d    3.1G     12k    2.9G     0%    /tmp
/dev/da0s1f    8.3G    450M    7.2G     6%    /usr
/dev/da0s1e    4.2G    281k    3.8G     0%    /var

NOTE: during sysinstall partition creatin it showd me 3.2TB of /data...

# dmesg

da0 at twa0 bus 0 target 0 lun 0
da0: <AMCC 9650SE-8LP DISK 4.06> Fixed Direct Access SCSI-5 device
da0: 100.000MB/s transfers
da0: 20479MB (41943039 512 byte sectors: 255H 63S/T 2610C)
cd0 at umass-sim0 bus 0 target 0 lun 0
cd0: <ATAPI DVD A  DH20A3P XP5Z> Removable CD-ROM SCSI-0 device
cd0: 40.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present 
- tray closed
da1 at twa0 bus 0 target 0 lun 1
da1: <AMCC 9650SE-8LP DISK 4.06> Fixed Direct Access SCSI-5 device
da1: 100.000MB/s transfers
da1: 3317309MB (6793848833 512 byte sectors: 255H 63S/T 422897C)

From mozart at lib.uchicago.edu  Wed Mar 25 07:56:39 2009
From: mozart at lib.uchicago.edu (Peggy Wilkins)
Date: Wed Mar 25 07:56:52 2009
Subject: support quality (Re: dump | restore fails: unknown tape
	headertype 1853384566)
In-Reply-To: <3.0.1.32.20090325072137.00ee6b48@sage-american.com>
References: <49C9E635.5010106@kkip.pl> <49C83673.3000604@aldan.algebra.com>
	<200903251820.54749.doconnor@gsoft.com.au>
	<200903251925.36108.doconnor@gsoft.com.au>
	<3.0.1.32.20090325072137.00ee6b48@sage-american.com>
Message-ID: <pvfxh1ek4j.wl%mozart@lib.uchicago.edu>

>>>>>  Jack L Stone <jacks@sage-american.com> writes:

    >> I've been watching this thread with some interest since we've had some
    >> similar problems with dump/restore which we use every morning via cron
    >> scripts on a number of servers to produce bootable clones as part of our
    >> backup program. Have been doing this for years and also never saw a problem
    >> as most of you say. We prefer dump/restore for backups.

    >> However, last month upon upon upgrading those servers from FBSD-6.3px
    >> (RELEASE) to 7.0px (RELEASE) we found that about one-half of the servers
    >> had a similar problem as the original poster while the other half did not.
    >> All of the servers (rackmounts) use the same (type) hardware. We spent many
    >> hours trying to solve the problem with those that failed to dump/restore.
    >> Also, searched for any others with the problem and only found a very few,
    >> but without solutions to this issue. (Indeed, the only one was a reference
    >> to any efforts to restore an older OS version which didn't apply here).
  [snip]
    >> SOLUTION
    >> The "clones" are a very important pasrt of our backup program. Since the
    >> dump side of the problems simply stuck and provided no error message at all
    >> and the errors from any restores were not useful, our only solution was to
    >> revert back to FBSD-6.3 on those servers with this issue and dump/restore
    >> went back to working again. We left those that were working on FBSD-7.0-R
    >> and they continue to work okay.

I was seeing this same problem on all my 64-bit systems: FreeBSD-7
dump would hang at a random point.  Dump continues to work flawlessly
for me on FreeBSD-7/i386.

I ran across this which includes a patch:

http://www.freebsd.org/cgi/query-pr.cgi?pr=121684

The kernel patch linked to there solved the problem for me, but I am
running many production systems and am unwilling to apply this patch
to -RELEASE every time there is a kernel update (I just use the
standard GENERIC kernel which I get via freebsd-update).  I now live
without dump on amd64.  Apparently this fix is waiting on some related
issue; and I will be very happy when it makes it to the officially
released kernel.

plw
From ivoras at freebsd.org  Wed Mar 25 08:09:02 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Wed Mar 25 08:09:12 2009
Subject: 32bit filesystem limitations
In-Reply-To: <49CA4498.2020007@bsd.ee>
References: <49CA3795.609@bsd.ee> <gqddl4$bd2$1@ger.gmane.org>
	<49CA4498.2020007@bsd.ee>
Message-ID: <gqdhdp$qeb$1@ger.gmane.org>

Andrei Kolu wrote:
> Ivan Voras wrote:
>> Andrei Kolu wrote:
>>  
>>> Hi,
>>>
>>> I have trouble to create FreeBSD 7.1 i386 partition/slice to 3Ware 8port
>>> raid kontroller with 8x500GB drives attached to it. Raid 5 massive is
>>> 3,1TB in size and during sysinstall installation I select whole
>>> available space but after restart I can access only 1,2TB from it. What
>>> is the problem?
>>>     
>>
>> MS-DOS fdisk partitions and bsdlabel partitions both have 32-bit
>> limitations on the file system size. You should use gpart to partition
>> the large volume. That is, except if you want to boot from it also -
>> then it's a bit problematic; it's best to create two logical drives in
>> your RAID controller - one small drive for the OS (something like 8 GB
>> to keep the ports and all) and the rest for the data.
>>
>>   
> I created 20GB slice for system and selected everything else for /data
> but after restart I see again 1,2TB /data. After second sysinstall
> attempt I created another 2TB slice and now at least I can use whole
> space. Not so good but it works.
> 
> Second attempt:
> Now I reserved 20GB for "boot volume" from 3Ware 9650SE controller and
> looks like it ...oops...did it again....deem.
> 
> # df -H
> Filesystem     Size    Used   Avail Capacity  Mounted on
> /dev/da0s1a    2.1G    146M    1.8G     8%    /
> devfs          1.0k    1.0k      0B   100%    /dev
> /dev/da1s1d    1.2T    4.1k    1.1T     0%    /data
> /dev/da0s1d    3.1G     12k    2.9G     0%    /tmp
> /dev/da0s1f    8.3G    450M    7.2G     6%    /usr
> /dev/da0s1e    4.2G    281k    3.8G     0%    /var

Ok, you're on the right track. Just don't use bsdlabel or fdisk
partitions for da1 - clear the partition tables and use gpart to create
a GPT partition tables which has no 32-bit problems.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/265b5480/signature.pgp
From mi+thun at aldan.algebra.com  Wed Mar 25 09:05:02 2009
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Wed Mar 25 09:05:10 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <nospam-1237956961.78753@joker.yaxom.com>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251232.11418.doconnor@gsoft.com.au>
	<49C99204.2050601@aldan.algebra.com>
	<200903251334.38350.doconnor@gsoft.com.au>
	<49C99FD2.50609@aldan.algebra.com>
	<nospam-1237956961.78753@joker.yaxom.com>
Message-ID: <49CA5602.9050001@aldan.algebra.com>

Greg Black ???????(??):
> On 2009-03-24, Mikhail T. wrote:
>   
>> That's true. I just wanted to point out, that someone running dump only 
>> (to make backups) is not going to know, whether his dumps are usable 
>> (for whichever of the two reasons), until he needs them...
>>     
>
> Such a person is not making backups and deserves what he gets.
>   
But he *is* making backups -- kindly re-read my paragraph above... He 
just is not routinely using them and thus does not know, that they 
aren't usable... It is not unreasonable to expect the two utilities to 
"just work", so I wouldn't be blaming such a person for not testing 
restore.

That such a scenario is possible, despite the user making diligent 
regular backups, is a very bad sign...
> I haven't got anything to say about dump/restore because I haven't
> bothered with them for years.  I do know that dumps from mounted file
> systems will often appear to work, but will fail when it matters.  This
> is not a bug and is expected behaviour to which the solution is obvious.
>   
FS being mounted read-only should not be a problem. And even read-write 
mounted filesystems will be Ok, although possibly inconsistent (a file 
modified during backup may get to into dump "as of" any point). But an 
idle FS is Ok to dump. Generally, when dumping read-write mounted 
filesystems, one is supposed to use snapshots, but that is very buggy on 
its own (leading to kernel crashes), so it is safer to rely on the FS 
being "idle", if it can not be forced into read-only for some other reason.

    -mi


From dimitry at andric.com  Wed Mar 25 09:11:40 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Wed Mar 25 09:11:47 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49C87E0D.5090501@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>	<200903241537.36515.doconnor@gsoft.com.au>
	<49C87E0D.5090501@aldan.algebra.com>
Message-ID: <49CA57BB.2070409@andric.com>

On 2009-03-24 07:30, Mikhail T. wrote:
>     dump a0f  - /old | restore -rf -
>     [...]
>       DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>       DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>       DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>     unknown tape header type -621260722
>     abort? [yn]
> 
> Looks like a junk value somewhere... Unitialized variable or some such.

Hmm, I can't reproduce this at all; I use dump and restore quite
regularly in this way, and I have never encountered this issue (except
for the occasional 'expected file NNN, got file MMM', which is usually
harmless).

Maybe the dump output gets corrupted in some way?  (E.g. faulty RAM, or
disk?)  If you are dumping a live filesystem, could it possibly help to
add the -L option?
From rnoland at FreeBSD.org  Wed Mar 25 09:36:44 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Mar 25 09:37:06 2009
Subject: [PREVIEW] Nouveau on FreeBSD (Take 2)
In-Reply-To: <49C9ED34.20504@gddsn.org.cn>
References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn>
	<49C6E5C6.60306@gddsn.org.cn>
	<1237798914.2110.24.camel@balrog.2hip.net>
	<49C85F4E.5050002@gddsn.org.cn>
	<1237882591.1771.26.camel@balrog.2hip.net>
	<49C97EEB.4090607@gddsn.org.cn>
	<1237961497.1828.2.camel@balrog.2hip.net>
	<49C9ED34.20504@gddsn.org.cn>
Message-ID: <1237998972.1828.4.camel@balrog.2hip.net>

On Wed, 2009-03-25 at 16:37 +0800, wsk wrote:
> Robert Noland wrote:
> > On Wed, 2009-03-25 at 08:46 +0800, wsk wrote:
> >   
> >> Robert Noland wrote:
> >>     
> >>> On Tue, 2009-03-24 at 12:19 +0800, wsk wrote:
> >>>   
> >>>       
> >>>> Robert Noland wrote:
> >>>>     
> >>>>         
> >>>>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>>> Ok, this patch should work on NV50 chips also.
> >>>>>>>       
> >>>>>>> What you get is EXA and Xv.
> >>>>>>>       
> >>>>>>> You still need:
> >>>>>>>       
> >>>>>>> A recent -CURRENT or -STABLE.
> >>>>>>>       
> >>>>>>> git master of libdrm and xf86-video-nouveau.
> >>>>>>>       
> >>>>>>> This patch.
> >>>>>>>       
> >>>>>>> Things I've figured out since the last patch...
> >>>>>>>       
> >>>>>>> On NV50 class hardware you need to have a compositing manager running
> >>>>>>> for Xv to work.  That means xcompmgr, metacity with composite enabled,
> >>>>>>> xfce (rumored to work as well, haven't tried).  If your running Gnome
> >>>>>>> with metacity, open gconf-editor and go to apps->metacity->general and
> >>>>>>> check the composite box.
> >>>>>>>       
> >>>>>>> On NV40 class hardware, you don't need the composite manager.  In fact
> >>>>>>> (at least with Xserver 1.6 which I'm running now), if a composite
> >>>>>>> manager is enabled, I'm seeing high cpu utilization from Xorg under some
> >>>>>>> circumstances.  I don't think this is a drm issue, but still an issue.
> >>>>>>> For me, if I start a video using mplayer in an xterm, cpu is fine as
> >>>>>>> long as that xterm is the foreground window.  If it is not the
> >>>>>>> foreground window, even if it isn't obscured I see the cpu utilization.
> >>>>>>> Disabling the composite manager makes everything fine.
> >>>>>>>       
> >>>>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch <http://people.freebsd.org/%7Ernoland/drm-nouveau-032109.patch>
> >>>>>>>       
> >>>>>>> robert.
> >>>>>>>       
> >>>>>>>           
> >>>>>>>               
> >>>>>> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation.
> >>>>>> It is not supported in any way.
> >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> >>>>>> Select the "xorg" product for bugs you find in this release.
> >>>>>> Before reporting bugs in pre-release versions please check the
> >>>>>> latest version in the X.Org Foundation git repository.
> >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
> >>>>>>
> >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> >>>>>> Release Date: 2009-1-30
> >>>>>> X Protocol Version 11, Revision 0
> >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64
> >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE
> >>>>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/sr
> >>>>>> c/sys/WSK amd64
> >>>>>> Build Date: 06 February 2009  04:22:44PM
> >>>>>>
> >>>>>>         Before reporting problems, check http://wiki.x.org
> >>>>>>         to make sure that you have the latest version.
> >>>>>> Markers: (--) probed, (**) from config file, (==) default setting,
> >>>>>>         (++) from command line, (!!) notice, (II) informational,
> >>>>>>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> >>>>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> >>>>>> ing config file: "xorg.conf1"
> >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>>>>> drm0: [ITHREAD]
> >>>>>> info: [drm] Allocating FIFO number 1
> >>>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
> >>>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
> >>>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> >>>>>> (EE) Screen(s) found, but none have a usable configuration.
> >>>>>>
> >>>>>> Fatal server error:
> >>>>>> no screens found
> >>>>>>
> >>>>>> Please consult the The X.Org Foundation support
> >>>>>>          at http://wiki.x.org
> >>>>>>  for help.
> >>>>>> Please also check the log file at "/var/log/Xorg.0.log" for additional informati
> >>>>>> on.
> >>>>>>
> >>>>>> info: [drm] nouveau_fifo_free: freeing fifo 1
> >>>>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before
> >>>>>> destroy.Prepare for strangeness..
> >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>>>>>
> >>>>>> what can i do ?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> plain text document attachment (Xorg.0.log)
> >>>>>> This is a pre-release version of the X server from The X.Org Foundation.
> >>>>>> It is not supported in any way.
> >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> >>>>>> Select the "xorg" product for bugs you find in this release.
> >>>>>> Before reporting bugs in pre-release versions please check the
> >>>>>> latest version in the X.Org Foundation git repository.
> >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
> >>>>>>
> >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> >>>>>> Release Date: 2009-1-30
> >>>>>> X Protocol Version 11, Revision 0
> >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 
> >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64
> >>>>>> Build Date: 06 February 2009  04:22:44PM
> >>>>>>  
> >>>>>> 	Before reporting problems, check http://wiki.x.org
> >>>>>> 	to make sure that you have the latest version.
> >>>>>> Markers: (--) probed, (**) from config file, (==) default setting,
> >>>>>> 	(++) from command line, (!!) notice, (II) informational,
> >>>>>> 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> >>>>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> >>>>>> (++) Using config file: "xorg.conf1"
> >>>>>> (==) No Layout section.  Using the first Screen section.
> >>>>>> (==) No screen section available. Using defaults.
> >>>>>> (**) |-->Screen "Default Screen Section" (0)
> >>>>>> (**) |   |-->Monitor "<default monitor>"
> >>>>>> (==) No device specified for screen "Default Screen Section".
> >>>>>> 	Using the first device section listed.
> >>>>>> (**) |   |-->Device "Card0"
> >>>>>> (==) No monitor specified for screen "Default Screen Section".
> >>>>>> 	Using a default monitor configuration.
> >>>>>> (==) Automatically adding devices
> >>>>>> (==) Automatically enabling devices
> >>>>>> (==) No FontPath specified.  Using compiled-in default.
> >>>>>> (==) FontPath set to:
> >>>>>> 	built-ins
> >>>>>> (==) ModulePath set to "/usr/local/lib/xorg/modules"
> >>>>>> (II) Cannot locate a core pointer device.
> >>>>>> (II) Cannot locate a core keyboard device.
> >>>>>> (II) The server relies on HAL to provide the list of input devices.
> >>>>>> 	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
> >>>>>> (II) Loader magic: 0xb20
> >>>>>> (II) Module ABI versions:
> >>>>>> 	X.Org ANSI C Emulation: 0.4
> >>>>>> 	X.Org Video Driver: 5.0
> >>>>>> 	X.Org XInput driver : 4.0
> >>>>>> 	X.Org Server Extension : 2.0
> >>>>>> (II) Loader running on freebsd
> >>>>>> (--) Using syscons driver with X support (version 2.0)
> >>>>>> (--) using VT number 9
> >>>>>>
> >>>>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> Ok, thats a new one...
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> (II) System resource ranges:
> >>>>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> >>>>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> >>>>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> >>>>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> >>>>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> >>>>>> (II) LoadModule: "extmod"
> >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
> >>>>>> (II) Module extmod: vendor="X.Org Foundation"
> >>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
> >>>>>> 	Module class: X.Org Server Extension
> >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>>>> (II) Loading extension MIT-SCREEN-SAVER
> >>>>>> (II) Loading extension XFree86-VidModeExtension
> >>>>>> (II) Loading extension XFree86-DGA
> >>>>>> (II) Loading extension DPMS
> >>>>>> (II) Loading extension XVideo
> >>>>>> (II) Loading extension XVideo-MotionCompensation
> >>>>>> (II) Loading extension X-Resource
> >>>>>> (II) LoadModule: "dbe"
> >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
> >>>>>> (II) Module dbe: vendor="X.Org Foundation"
> >>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
> >>>>>> 	Module class: X.Org Server Extension
> >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>>>> (II) Loading extension DOUBLE-BUFFER
> >>>>>> (II) LoadModule: "glx"
> >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
> >>>>>> (II) Module glx: vendor="X.Org Foundation"
> >>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
> >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>>>> (==) AIGLX disabled
> >>>>>> (==) Exporting typical set of GLX visuals
> >>>>>> (II) Loading extension GLX
> >>>>>> (II) LoadModule: "record"
> >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
> >>>>>> (II) Module record: vendor="X.Org Foundation"
> >>>>>> 	compiled for 1.5.99.902, module version = 1.13.0
> >>>>>> 	Module class: X.Org Server Extension
> >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>>>> (II) Loading extension RECORD
> >>>>>> (II) LoadModule: "dri"
> >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
> >>>>>> (II) Module dri: vendor="X.Org Foundation"
> >>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
> >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> >>>>>> (II) Loading extension XFree86-DRI
> >>>>>> (II) LoadModule: "nouveau"
> >>>>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so
> >>>>>> (II) Module nouveau: vendor="X.Org Foundation"
> >>>>>> 	compiled for 1.5.99.902, module version = 0.0.10
> >>>>>> 	Module class: X.Org Video Driver
> >>>>>> 	ABI class: X.Org Video Driver, version 5.0
> >>>>>> (II) NOUVEAU driver Date:   Wed Mar 18 09:36:33 2009 +1000
> >>>>>> (II) NOUVEAU driver for NVIDIA chipset families :
> >>>>>> 	RIVA TNT    (NV04)
> >>>>>> 	RIVA TNT2   (NV05)
> >>>>>> 	GeForce 256 (NV10)
> >>>>>> 	GeForce 2   (NV11, NV15)
> >>>>>> 	GeForce 4MX (NV17, NV18)
> >>>>>> 	GeForce 3   (NV20)
> >>>>>> 	GeForce 4Ti (NV25, NV28)
> >>>>>> 	GeForce FX  (NV3x)
> >>>>>> 	GeForce 6   (NV4x)
> >>>>>> 	GeForce 7   (G7x)
> >>>>>> 	GeForce 8   (G8x)
> >>>>>> (II) Primary Device is: PCI 01@00:00:0
> >>>>>> (II) resource ranges after probing:
> >>>>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> >>>>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> >>>>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> >>>>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> >>>>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> >>>>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86"
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> Hrm, NV86... I'll have to ask around about that.  Meanwhile can you send
> >>>>> me a pciconf -lvb which should at least show us the BAR configuration.
> >>>>>
> >>>>> Ok, my sources are telling me that this should work and that it is an
> >>>>> NV50, or at least should work the same...
> >>>>>
> >>>>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess.  I'm
> >>>>> not sure if it may be trashing the BARs somehow.
> >>>>>
> >>>>> robert.
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled
> >>>> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086
> >>>> rev=0x02 hdr=0x00
> >>>> vendor = 'Intel Corporation'
> >>>> device = '82801H (ICH8 Family) SMBus Controller'
> >>>> class = serial bus
> >>>> subclass = SMBus
> >>>> bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled
> >>>> bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled
> >>>> vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de
> >>>> rev=0xa1 hdr=0x00
> >>>> vendor = 'Nvidia Corp'
> >>>> device = 'Unknown nVidia Quadro FX 570M'
> >>>> class = display
> >>>> subclass = VGA
> >>>> bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled
> >>>>     
> >>>>         
> >>> Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up.  BAR 1
> >>> should be your framebuffer and should be where most of your memory is.
> >>> (This is the memory the tell you about when you buy the card, 256M,
> >>> 512M, etc.)  It should probably be a 64bit BAR, which is why BAR 2 isn't
> >>> there.  We are going to need more details on your card...
> >>>   
> >>>       
> >> indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M memory.
> >> but it recognized Quadro FX 570M with pciconfig.
> >>     
> >
> > So, the nouveau folks want me to get you to either boot linux and see
> > what lspci shows for this card, or at least install the lspci port and
> > see what it says.  I don't think it is going to reveal anything, but who
> > knows...  This is not a driver issue at this point, the BARs just don't
> > appear to be present.
> >
> > robert.
> >
> >   
> ok,here's my lspci -v messags with linux Fedora live CD :-)
> and thanks your Re
> 
> 
> 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M
> (rev a1) (prog-if 00 [VGA controller])
> Subsystem: Dell Device 01fe
> Flags: bus master, fast devsel, latency 0, IRQ 5
> Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
> Memory at e0000000 (64-bit, prefetchable) [size=256M]
> Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
> I/O ports at df00 [size=128]
> [virtual] Expansion ROM at fc000000 [disabled] [size=128K]
> Capabilities: [60] Power Management version 2
> Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1
> Enable-
> Capabilities: [78] Express Endpoint, MSI 00
> Capabilities: [100] Virtual Channel <?>
> Capabilities: [128] Power Budgeting <?>
> Capabilities: [600] Vendor Specific Information <?>
> Kernel modules: nvidiafb

Ok, we need a little help on this one then... I don't know why we
wouldn't see BAR 1.  Time to rope jhb@ in.

robert.

> 0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n
> (rev 03)
> Subsystem: Dell Wireless 1500 Draft 802.11n WLAN Mini-card
> Flags: bus master, fast devsel, latency 0, IRQ 17
> Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
> Memory at f0000000 (64-bit, prefetchable) [size=1M]
> Capabilities: [40] Power Management version 2
> Capabilities: [58] Vendor Specific Information <?>
> Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Count=1/1
> Enable-
> Capabilities: [d0] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
> ECRC- UnsupReq- ACSVoil-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
> ECRC- UnsupReq- ACSVoil-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
> MalfTLP+ ECRC- UnsupReq- ACSVoil-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> Capabilities: [13c] Virtual Channel <?>
> Capabilities: [160] Device Serial Number 1c-00-a4-ff-ff-26-df-c0
> Capabilities: [16c] Power Budgeting <?>
> Kernel driver in use: b43-pci-bridge
> Kernel modules: ssb
> 
> >>>   
> >>>       
> >>>> bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled
> >>>>     
> >>>>         
> >>> This one is BAR 3, which is used when it doesn't find BAR 1.
> >>>
> >>> robert.
> >>>
> >>>   
> >>>       
> >>>> bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled
> >>>> ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4
> >>>> rev=0x03 hdr=0x00
> >>>>
> >>>> and follow your intrudction.still pain me :(
> >>>>
> >>>> (++) Using config file: "xorg.conf1"
> >>>> drm0: <NVidia Display Adapter> on vgapci0
> >>>> info: [drm] Detected an NV50 generation card (0x086900a2)
> >>>> vgapci0: child drm0 requested pci_enable_busmaster
> >>>> info: [drm] Initialized nouveau 0.0.12 20060213
> >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>>> drm0: [ITHREAD]
> >>>> info: [drm] Allocating FIFO number 1
> >>>> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII,
> >>>> invalid/inactiv
> >>>> e channel id 128
> >>>> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo:
> >>>> [drm] , nSt
> >>>> atus:info: [drm]
> >>>> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data
> >>>> 0x00000000:0x00
> >>>> 000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1:
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2:
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000
> >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000
> >>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
> >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
> >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> >>>> (EE) Screen(s) found, but none have a usable configuration.
> >>>>
> >>>> Fatal server error:
> >>>> no screens found
> >>>>
> >>>> Please consult the The X.Org Foundation support
> >>>> at http://wiki.x.org
> >>>> for help.
> >>>> Please also check the log file at "/var/log/Xorg.0.log" for additional
> >>>> informati
> >>>> on.
> >>>>
> >>>> info: [drm] nouveau_fifo_free: freeing fifo 1
> >>>> error: [drm:pid6493:nouveau_fifo_free] *ERROR* Failed to idle channel 1
> >>>> before d
> >>>> estroy.Prepare for strangeness..
> >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 127
> >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> >>>>
> >>>>     
> 
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090325/d97eeb28/attachment.pgp
From cpghost at cordula.ws  Wed Mar 25 09:45:43 2009
From: cpghost at cordula.ws (cpghost)
Date: Wed Mar 25 09:45:51 2009
Subject: dump | restore fails: unknown tape header type 1853384566
In-Reply-To: <49CA5602.9050001@aldan.algebra.com>
References: <49C83673.3000604@aldan.algebra.com>
	<200903251232.11418.doconnor@gsoft.com.au>
	<49C99204.2050601@aldan.algebra.com>
	<200903251334.38350.doconnor@gsoft.com.au>
	<49C99FD2.50609@aldan.algebra.com>
	<nospam-1237956961.78753@joker.yaxom.com>
	<49CA5602.9050001@aldan.algebra.com>
Message-ID: <20090325164538.GA6843@phenom.cordula.ws>

On Wed, Mar 25, 2009 at 12:04:18PM -0400, Mikhail T. wrote:
> Generally, when dumping read-write mounted filesystems, one is
> supposed to use snapshots, but that is very buggy on its own
> (leading to kernel crashes), so it is safer to rely on the FS being
> "idle", if it can not be forced into read-only for some other
> reason.

Perhaps your kernel/world is not recent enough? There used to be
problems with snapshots, including hangs or crashes, but IIRC, they
disappeared completly a couple of months ago, at least for me. (no,
sorry, I can't pinpoint the exact date, and much less the exact
revision nr).

Snapshots alone, and dump -L + restore (on RELENG_7/amd64) working
flawlessly here on 20+ rack-mounted servers; some to tape, some to
SAN, but I'm probably just lucky.

BTW, that's what makes this problem so intractable: those who could
debug it, can't reproduce it on their machines. It's scary to know
there's a bug lurking in there.

>     -mi

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
From rnoland at FreeBSD.org  Wed Mar 25 10:23:33 2009
From: rnoland at FreeBSD.org (Robert Noland)
Date: Wed Mar 25 10:23:41 2009
Subject: [PREVIEW] Nouveau on FreeBSD (Take 2)
In-Reply-To: <1237998972.1828.4.camel@balrog.2hip.net>
References: <49B88449.3000403@gddsn.org.cn> <49B8AC04.10508@gddsn.org.cn>
	<49C6E5C6.60306@gddsn.org.cn>
	<1237798914.2110.24.camel@balrog.2hip.net>
	<49C85F4E.5050002@gddsn.org.cn>
	<1237882591.1771.26.camel@balrog.2hip.net>
	<49C97EEB.4090607@gddsn.org.cn>
	<1237961497.1828.2.camel@balrog.2hip.net>
	<49C9ED34.20504@gddsn.org.cn> <1237998972.1828.4.camel@balrog.2hip.net>
Message-ID: <1238001777.1828.17.camel@balrog.2hip.net>

On Wed, 2009-03-25 at 11:36 -0500, Robert Noland wrote:
> On Wed, 2009-03-25 at 16:37 +0800, wsk wrote:
> > Robert Noland wrote:
> > > On Wed, 2009-03-25 at 08:46 +0800, wsk wrote:
> > >   
> > >> Robert Noland wrote:
> > >>     
> > >>> On Tue, 2009-03-24 at 12:19 +0800, wsk wrote:
> > >>>   
> > >>>       
> > >>>> Robert Noland wrote:
> > >>>>     
> > >>>>         
> > >>>>> On Mon, 2009-03-23 at 09:28 +0800, wsk wrote:
> > >>>>>   
> > >>>>>       
> > >>>>>           
> > >>>>>>> Ok, this patch should work on NV50 chips also.
> > >>>>>>>       
> > >>>>>>> What you get is EXA and Xv.
> > >>>>>>>       
> > >>>>>>> You still need:
> > >>>>>>>       
> > >>>>>>> A recent -CURRENT or -STABLE.
> > >>>>>>>       
> > >>>>>>> git master of libdrm and xf86-video-nouveau.
> > >>>>>>>       
> > >>>>>>> This patch.
> > >>>>>>>       
> > >>>>>>> Things I've figured out since the last patch...
> > >>>>>>>       
> > >>>>>>> On NV50 class hardware you need to have a compositing manager running
> > >>>>>>> for Xv to work.  That means xcompmgr, metacity with composite enabled,
> > >>>>>>> xfce (rumored to work as well, haven't tried).  If your running Gnome
> > >>>>>>> with metacity, open gconf-editor and go to apps->metacity->general and
> > >>>>>>> check the composite box.
> > >>>>>>>       
> > >>>>>>> On NV40 class hardware, you don't need the composite manager.  In fact
> > >>>>>>> (at least with Xserver 1.6 which I'm running now), if a composite
> > >>>>>>> manager is enabled, I'm seeing high cpu utilization from Xorg under some
> > >>>>>>> circumstances.  I don't think this is a drm issue, but still an issue.
> > >>>>>>> For me, if I start a video using mplayer in an xterm, cpu is fine as
> > >>>>>>> long as that xterm is the foreground window.  If it is not the
> > >>>>>>> foreground window, even if it isn't obscured I see the cpu utilization.
> > >>>>>>> Disabling the composite manager makes everything fine.
> > >>>>>>>       
> > >>>>>>> http://people.freebsd.org/~rnoland/drm-nouveau-032109.patch <http://people.freebsd.org/%7Ernoland/drm-nouveau-032109.patch>
> > >>>>>>>       
> > >>>>>>> robert.
> > >>>>>>>       
> > >>>>>>>           
> > >>>>>>>               
> > >>>>>> get the following errors and exitThis is a pre-release version of the X server from The X.Org Foundation.
> > >>>>>> It is not supported in any way.
> > >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> > >>>>>> Select the "xorg" product for bugs you find in this release.
> > >>>>>> Before reporting bugs in pre-release versions please check the
> > >>>>>> latest version in the X.Org Foundation git repository.
> > >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
> > >>>>>>
> > >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> > >>>>>> Release Date: 2009-1-30
> > >>>>>> X Protocol Version 11, Revision 0
> > >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64
> > >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRE
> > >>>>>> RELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/sr
> > >>>>>> c/sys/WSK amd64
> > >>>>>> Build Date: 06 February 2009  04:22:44PM
> > >>>>>>
> > >>>>>>         Before reporting problems, check http://wiki.x.org
> > >>>>>>         to make sure that you have the latest version.
> > >>>>>> Markers: (--) probed, (**) from config file, (==) default setting,
> > >>>>>>         (++) from command line, (!!) notice, (II) informational,
> > >>>>>>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> > >>>>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> > >>>>>> ing config file: "xorg.conf1"
> > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> > >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> > >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> > >>>>>> drm0: [ITHREAD]
> > >>>>>> info: [drm] Allocating FIFO number 1
> > >>>>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
> > >>>>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
> > >>>>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> > >>>>>> (EE) Screen(s) found, but none have a usable configuration.
> > >>>>>>
> > >>>>>> Fatal server error:
> > >>>>>> no screens found
> > >>>>>>
> > >>>>>> Please consult the The X.Org Foundation support
> > >>>>>>          at http://wiki.x.org
> > >>>>>>  for help.
> > >>>>>> Please also check the log file at "/var/log/Xorg.0.log" for additional informati
> > >>>>>> on.
> > >>>>>>
> > >>>>>> info: [drm] nouveau_fifo_free: freeing fifo 1
> > >>>>>> error: [drm:pid30722:nouveau_fifo_free] *ERROR* Failed to idle channel 1 before
> > >>>>>> destroy.Prepare for strangeness..
> > >>>>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> > >>>>>> error: [drm:pid30722:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> > >>>>>>
> > >>>>>> what can i do ?
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> plain text document attachment (Xorg.0.log)
> > >>>>>> This is a pre-release version of the X server from The X.Org Foundation.
> > >>>>>> It is not supported in any way.
> > >>>>>> Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
> > >>>>>> Select the "xorg" product for bugs you find in this release.
> > >>>>>> Before reporting bugs in pre-release versions please check the
> > >>>>>> latest version in the X.Org Foundation git repository.
> > >>>>>> See http://wiki.x.org/wiki/GitPage for git access instructions.
> > >>>>>>
> > >>>>>> X.Org X Server 1.5.99.902 (1.6.0 RC 2)
> > >>>>>> Release Date: 2009-1-30
> > >>>>>> X Protocol Version 11, Revision 0
> > >>>>>> Build Operating System: FreeBSD 7.1-STABLE amd64 
> > >>>>>> Current Operating System: FreeBSD lp.gddsn.org.cn 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sun Mar 22 19:44:23 CST 2009     wsk@lp.gddsn.org.cn:/usr/obj/usr/src/sys/WSK amd64
> > >>>>>> Build Date: 06 February 2009  04:22:44PM
> > >>>>>>  
> > >>>>>> 	Before reporting problems, check http://wiki.x.org
> > >>>>>> 	to make sure that you have the latest version.
> > >>>>>> Markers: (--) probed, (**) from config file, (==) default setting,
> > >>>>>> 	(++) from command line, (!!) notice, (II) informational,
> > >>>>>> 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> > >>>>>> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Mar 23 09:14:03 2009
> > >>>>>> (++) Using config file: "xorg.conf1"
> > >>>>>> (==) No Layout section.  Using the first Screen section.
> > >>>>>> (==) No screen section available. Using defaults.
> > >>>>>> (**) |-->Screen "Default Screen Section" (0)
> > >>>>>> (**) |   |-->Monitor "<default monitor>"
> > >>>>>> (==) No device specified for screen "Default Screen Section".
> > >>>>>> 	Using the first device section listed.
> > >>>>>> (**) |   |-->Device "Card0"
> > >>>>>> (==) No monitor specified for screen "Default Screen Section".
> > >>>>>> 	Using a default monitor configuration.
> > >>>>>> (==) Automatically adding devices
> > >>>>>> (==) Automatically enabling devices
> > >>>>>> (==) No FontPath specified.  Using compiled-in default.
> > >>>>>> (==) FontPath set to:
> > >>>>>> 	built-ins
> > >>>>>> (==) ModulePath set to "/usr/local/lib/xorg/modules"
> > >>>>>> (II) Cannot locate a core pointer device.
> > >>>>>> (II) Cannot locate a core keyboard device.
> > >>>>>> (II) The server relies on HAL to provide the list of input devices.
> > >>>>>> 	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
> > >>>>>> (II) Loader magic: 0xb20
> > >>>>>> (II) Module ABI versions:
> > >>>>>> 	X.Org ANSI C Emulation: 0.4
> > >>>>>> 	X.Org Video Driver: 5.0
> > >>>>>> 	X.Org XInput driver : 4.0
> > >>>>>> 	X.Org Server Extension : 2.0
> > >>>>>> (II) Loader running on freebsd
> > >>>>>> (--) Using syscons driver with X support (version 2.0)
> > >>>>>> (--) using VT number 9
> > >>>>>>
> > >>>>>> (--) PCI:*(0@1:0:0) nVidia Corporation Quadro NVS 140M rev 161, Mem @ 0xfd000000/16777216, 0x00000000/268435456, 0xfa000000/33554432, I/O @ 0x0000df00/128, BIOS @ 0x????????/65536
> > >>>>>>     
> > >>>>>>         
> > >>>>>>             
> > >>>>> Ok, thats a new one...
> > >>>>>
> > >>>>>   
> > >>>>>       
> > >>>>>           
> > >>>>>> (II) System resource ranges:
> > >>>>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> > >>>>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> > >>>>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> > >>>>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> > >>>>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> > >>>>>> (II) LoadModule: "extmod"
> > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
> > >>>>>> (II) Module extmod: vendor="X.Org Foundation"
> > >>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
> > >>>>>> 	Module class: X.Org Server Extension
> > >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> > >>>>>> (II) Loading extension MIT-SCREEN-SAVER
> > >>>>>> (II) Loading extension XFree86-VidModeExtension
> > >>>>>> (II) Loading extension XFree86-DGA
> > >>>>>> (II) Loading extension DPMS
> > >>>>>> (II) Loading extension XVideo
> > >>>>>> (II) Loading extension XVideo-MotionCompensation
> > >>>>>> (II) Loading extension X-Resource
> > >>>>>> (II) LoadModule: "dbe"
> > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
> > >>>>>> (II) Module dbe: vendor="X.Org Foundation"
> > >>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
> > >>>>>> 	Module class: X.Org Server Extension
> > >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> > >>>>>> (II) Loading extension DOUBLE-BUFFER
> > >>>>>> (II) LoadModule: "glx"
> > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so
> > >>>>>> (II) Module glx: vendor="X.Org Foundation"
> > >>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
> > >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> > >>>>>> (==) AIGLX disabled
> > >>>>>> (==) Exporting typical set of GLX visuals
> > >>>>>> (II) Loading extension GLX
> > >>>>>> (II) LoadModule: "record"
> > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
> > >>>>>> (II) Module record: vendor="X.Org Foundation"
> > >>>>>> 	compiled for 1.5.99.902, module version = 1.13.0
> > >>>>>> 	Module class: X.Org Server Extension
> > >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> > >>>>>> (II) Loading extension RECORD
> > >>>>>> (II) LoadModule: "dri"
> > >>>>>> (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so
> > >>>>>> (II) Module dri: vendor="X.Org Foundation"
> > >>>>>> 	compiled for 1.5.99.902, module version = 1.0.0
> > >>>>>> 	ABI class: X.Org Server Extension, version 2.0
> > >>>>>> (II) Loading extension XFree86-DRI
> > >>>>>> (II) LoadModule: "nouveau"
> > >>>>>> (II) Loading /usr/local/lib/xorg/modules/drivers//nouveau_drv.so
> > >>>>>> (II) Module nouveau: vendor="X.Org Foundation"
> > >>>>>> 	compiled for 1.5.99.902, module version = 0.0.10
> > >>>>>> 	Module class: X.Org Video Driver
> > >>>>>> 	ABI class: X.Org Video Driver, version 5.0
> > >>>>>> (II) NOUVEAU driver Date:   Wed Mar 18 09:36:33 2009 +1000
> > >>>>>> (II) NOUVEAU driver for NVIDIA chipset families :
> > >>>>>> 	RIVA TNT    (NV04)
> > >>>>>> 	RIVA TNT2   (NV05)
> > >>>>>> 	GeForce 256 (NV10)
> > >>>>>> 	GeForce 2   (NV11, NV15)
> > >>>>>> 	GeForce 4MX (NV17, NV18)
> > >>>>>> 	GeForce 3   (NV20)
> > >>>>>> 	GeForce 4Ti (NV25, NV28)
> > >>>>>> 	GeForce FX  (NV3x)
> > >>>>>> 	GeForce 6   (NV4x)
> > >>>>>> 	GeForce 7   (G7x)
> > >>>>>> 	GeForce 8   (G8x)
> > >>>>>> (II) Primary Device is: PCI 01@00:00:0
> > >>>>>> (II) resource ranges after probing:
> > >>>>>> 	[0] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
> > >>>>>> 	[1] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
> > >>>>>> 	[2] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
> > >>>>>> 	[3] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
> > >>>>>> 	[4] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
> > >>>>>> (--) NOUVEAU(0): Chipset: "NVIDIA NV86"
> > >>>>>>     
> > >>>>>>         
> > >>>>>>             
> > >>>>> Hrm, NV86... I'll have to ask around about that.  Meanwhile can you send
> > >>>>> me a pciconf -lvb which should at least show us the BAR configuration.
> > >>>>>
> > >>>>> Ok, my sources are telling me that this should work and that it is an
> > >>>>> NV50, or at least should work the same...
> > >>>>>
> > >>>>> Also, just to be safe, please rebuild/reinstall devel/libpciaccess.  I'm
> > >>>>> not sure if it may be trashing the BARs somehow.
> > >>>>>
> > >>>>> robert.
> > >>>>>   
> > >>>>>       
> > >>>>>           
> > >>>> bar [24] = type I/O Port, range 32, base 0xeff0, size 16, enabled
> > >>>> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x01fe1028 chip=0x283e8086
> > >>>> rev=0x02 hdr=0x00
> > >>>> vendor = 'Intel Corporation'
> > >>>> device = '82801H (ICH8 Family) SMBus Controller'
> > >>>> class = serial bus
> > >>>> subclass = SMBus
> > >>>> bar [10] = type Memory, range 32, base 0xfebfbf00, size 256, enabled
> > >>>> bar [20] = type I/O Port, range 32, base 0x10c0, size 32, enabled
> > >>>> vgapci0@pci0:1:0:0: class=0x030000 card=0x01fe1028 chip=0x042910de
> > >>>> rev=0xa1 hdr=0x00
> > >>>> vendor = 'Nvidia Corp'
> > >>>> device = 'Unknown nVidia Quadro FX 570M'
> > >>>> class = display
> > >>>> subclass = VGA
> > >>>> bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled
> > >>>>     
> > >>>>         
> > >>> Ok, this is BAR 0, BARs 1 and 2 are indeed are not showing up.  BAR 1
> > >>> should be your framebuffer and should be where most of your memory is.
> > >>> (This is the memory the tell you about when you buy the card, 256M,
> > >>> 512M, etc.)  It should probably be a 64bit BAR, which is why BAR 2 isn't
> > >>> there.  We are going to need more details on your card...
> > >>>   
> > >>>       
> > >> indeed,my DELL D830 laptop video card is Quadro NVS 140M with 256M memory.
> > >> but it recognized Quadro FX 570M with pciconfig.
> > >>     
> > >
> > > So, the nouveau folks want me to get you to either boot linux and see
> > > what lspci shows for this card, or at least install the lspci port and
> > > see what it says.  I don't think it is going to reveal anything, but who
> > > knows...  This is not a driver issue at this point, the BARs just don't
> > > appear to be present.
> > >
> > > robert.
> > >
> > >   
> > ok,here's my lspci -v messags with linux Fedora live CD :-)
> > and thanks your Re
> > 
> > 
> > 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M
> > (rev a1) (prog-if 00 [VGA controller])
> > Subsystem: Dell Device 01fe
> > Flags: bus master, fast devsel, latency 0, IRQ 5
> > Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
> > Memory at e0000000 (64-bit, prefetchable) [size=256M]
> > Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
> > I/O ports at df00 [size=128]
> > [virtual] Expansion ROM at fc000000 [disabled] [size=128K]
> > Capabilities: [60] Power Management version 2
> > Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1
> > Enable-
> > Capabilities: [78] Express Endpoint, MSI 00
> > Capabilities: [100] Virtual Channel <?>
> > Capabilities: [128] Power Budgeting <?>
> > Capabilities: [600] Vendor Specific Information <?>
> > Kernel modules: nvidiafb
> 
> Ok, we need a little help on this one then... I don't know why we
> wouldn't see BAR 1.  Time to rope jhb@ in.

Can you send a verbose boot log.

robert.

> robert.
> 
> > 0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n
> > (rev 03)
> > Subsystem: Dell Wireless 1500 Draft 802.11n WLAN Mini-card
> > Flags: bus master, fast devsel, latency 0, IRQ 17
> > Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
> > Memory at f0000000 (64-bit, prefetchable) [size=1M]
> > Capabilities: [40] Power Management version 2
> > Capabilities: [58] Vendor Specific Information <?>
> > Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Count=1/1
> > Enable-
> > Capabilities: [d0] Express Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
> > ECRC- UnsupReq- ACSVoil-
> > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP-
> > ECRC- UnsupReq- ACSVoil-
> > UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
> > MalfTLP+ ECRC- UnsupReq- ACSVoil-
> > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
> > Capabilities: [13c] Virtual Channel <?>
> > Capabilities: [160] Device Serial Number 1c-00-a4-ff-ff-26-df-c0
> > Capabilities: [16c] Power Budgeting <?>
> > Kernel driver in use: b43-pci-bridge
> > Kernel modules: ssb
> > 
> > >>>   
> > >>>       
> > >>>> bar [1c] = type Memory, range 64, base 0xfa000000, size 33554432, enabled
> > >>>>     
> > >>>>         
> > >>> This one is BAR 3, which is used when it doesn't find BAR 1.
> > >>>
> > >>> robert.
> > >>>
> > >>>   
> > >>>       
> > >>>> bar [24] = type I/O Port, range 32, base 0xdf00, size 128, enabled
> > >>>> ndis0@pci0:12:0:0: class=0x028000 card=0x000a1028 chip=0x432814e4
> > >>>> rev=0x03 hdr=0x00
> > >>>>
> > >>>> and follow your intrudction.still pain me :(
> > >>>>
> > >>>> (++) Using config file: "xorg.conf1"
> > >>>> drm0: <NVidia Display Adapter> on vgapci0
> > >>>> info: [drm] Detected an NV50 generation card (0x086900a2)
> > >>>> vgapci0: child drm0 requested pci_enable_busmaster
> > >>>> info: [drm] Initialized nouveau 0.0.12 20060213
> > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x2
> > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> > >>>> vgapci0: 0x10000000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> > >>>> error: [drm:pid6493:drm_alloc_resource] *ERROR* Couldn't find resource 0x1
> > >>>> drm0: [ITHREAD]
> > >>>> info: [drm] Allocating FIFO number 1
> > >>>> error: [drm:pid6494:nouveau_graph_trapped_channel] *ERROR* AIII,
> > >>>> invalid/inactiv
> > >>>> e channel id 128
> > >>>> info: [drm] PGRAPH_ERROR - nSource:info: [drm] PROTECTION_ERRORinfo:
> > >>>> [drm] , nSt
> > >>>> atus:info: [drm]
> > >>>> info: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data
> > >>>> 0x00000000:0x00
> > >>>> 000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 1:
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408900: 0x8000003f
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408904: 0xcf6f7f0e
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408908: 0xfff7367f
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040890c: 0x00001850
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408910: 0xafff3587
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e08: 0x800b6fad
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e0c: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e10: 0x4df4fd60
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e14: 0x000000d7
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e18: 0x3139768d
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e1c: 0xf6d69757
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e20: 0x63161650
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00408e24: 0x07220009
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* magic set 2:
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409900: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409904: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409908: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x0040990c: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409910: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e08: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e0c: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e10: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e14: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e18: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e1c: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e20: 0x00000000
> > >>>> error: [drm:pid6494:nv50_pgraph_irq_handler] *ERROR* 0x00409e24: 0x00000000
> > >>>> info: [drm] nouveau_fifo_alloc: initialised FIFO 1
> > >>>> info: [drm] PFIFO_DMA_PUSHER - Ch 1
> > >>>> (EE) NOUVEAU(0): 1296: No valid FB address in PCI config space
> > >>>> (EE) Screen(s) found, but none have a usable configuration.
> > >>>>
> > >>>> Fatal server error:
> > >>>> no screens found
> > >>>>
> > >>>> Please consult the The X.Org Foundation support
> > >>>> at http://wiki.x.org
> > >>>> for help.
> > >>>> Please also check the log file at "/var/log/Xorg.0.log" for additional
> > >>>> informati
> > >>>> on.
> > >>>>
> > >>>> info: [drm] nouveau_fifo_free: freeing fifo 1
> > >>>> error: [drm:pid6493:nouveau_fifo