"Intel Centrino Advanced-N + WiMAX 6250" doesn't work
Hi, I have a lenovo X201s with a "Intel Centrino Advanced-N + WiMAX 6250" bundled. The device seems recognized as iwn0 correctly but it just doesn't work. The command "ifconfig wlan0 up scan" return immediately and nothing showed. Is the device not supported, or do I miss something? Any suggestion is welcome, thanks. Here is some information: $ uname -a FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 dmesg -a: http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt rc.conf: http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf kldstat -v http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt Tz-Huan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RELENG_8 / mpt / zpool Errors
> What are the drives exactly? You may have issues like TLER or > frequent head parking. Are these SATA, SCSI or SAS and are port > multipliers in use? root@bsd-03: dmesg | grep da6 da6 at mpt0 bus 0 scbus1 target 1 lun 0 da6: Fixed Direct Access SCSI-5 device da6: 300.000MB/s transfers da6: Command Queueing enabled da6: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) The drives are housed in two of the following enclosures: ses0 at mpt0 bus 0 scbus1 target 32 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 300.000MB/s transfers ses0: Command Queueing enabled ses0: SCSI-3 SES Device Each enclosure is directly connected by a dedicated cable to the 2-port controller: mps0: port 0xfc00-0xfcff mem 0xef5f-0xef5f,0xef58-0xef5b irq 44 at device 0.0 on pci1 mps0: Firmware: 07.15.04.00 mps0: IOCCapabilities: 185c mps0: [ITHREAD] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RELENG_8 / mpt / zpool Errors
On Sep 7, 2011 8:53 AM, "Tim Gustafson" wrote: > > Hi all, > > I'm running RELENG_8: > > -- > root@bsd-03: uname -a > FreeBSD bsd-03 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon Aug 22 14:58:58 PDT 2011 root@bsd-03:/usr/obj/usr/src/sys/GENERIC amd64 > -- > > We've got an MPT controller installed with 32 drives attached: > > -- > root@bsd-03: dmesg | grep mpt > mpt0: port 0xec00-0xecff mem 0xef3fc000-0xef3f,0xef3e-0xef3e irq 32 at device 0.0 on pci3 > mpt0: [ITHREAD] > mpt0: MPI Version=1.5.19.0 > ses0 at mpt0 bus 0 scbus1 target 32 lun 0 > ses1 at mpt0 bus 0 scbus1 target 33 lun 0 > da5 at mpt0 bus 0 scbus1 target 0 lun 0 > .SNIP. > da36 at mpt0 bus 0 scbus1 target 31 lun 0 > -- > > We have a zpool on those drives configured into one large zfs file system: [snip] > We're seeing some occasional oddness. About every two weeks it seems the controller temporarily loses connectivity with the drives and the zpool goes a bit bonkers and reports a dozen or so corrupted files. A "zpool scrub" goes through and reports that everything's been fixed and everything seems OK again (although I have not 100% confirmed that there is no file corruption yet, but I'm giving ZFS's check-summing logic the benefit of the doubt here). [snip] > So, is this an OS/driver issue? Is it a bad controller? Bad cables? Bad disks? > > As always, any help is greatly appreciated. Thanks! > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Tim Gustafson t...@soe.ucsc.edu > Baskin School of Engineering 831-459-5354 > UC Santa Cruz Baskin Engineering 317B > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- What are the drives exactly? You may have issues like TLER or frequent head parking. Are these SATA, SCSI or SAS and are port multipliers in use? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RELENG_8 / mpt / zpool Errors
On 9/6/2011 4:04 PM, Tim Gustafson wrote: Hi all, I'm running RELENG_8: -- ... So, is this an OS/driver issue? Is it a bad controller? Bad cables? Bad disks? As always, any help is greatly appreciated. Thanks! Likely some problem in the external box. Note that you get a 'POR' check condition- something reset out there. Possibly cables. Remotely possible firmware. Very unlikely to be an OS or driver issue. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 9.0 BETA2 gpart resize -s uses whole disk on first resize
Hi gurus, FreeBSD freebsd9.mg8.tmtowtdi.se 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Wed Aug 31 18:07:44 UTC 2011 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 When resizing a partition, on first attempt it uses up the whole disk. Only on second attempt it resizes to the correct target size. Resizing from any smaller size to a larger size initially uses up the whole disk, like if -s was not used at all even if it's as little as one logical disk block. I'm wondering if anyone else can reproduce. I just tried to perform the same on an old 8.2-STABLE machine and it did not behave the same. Growing a partition worked fine on initial attempts. See excerpt from session below: freebsd9# gpart show ada0 =>34 3907029101 ada0 GPT (1.8T) 34 30- free - (15k) 64 128 1 freebsd-boot (64k) 192 8388608 2 freebsd-swap (4.0G) 8388800 3898640335- free - (1.8T) freebsd9# expr 8388608 \* 4 33554432 freebsd9# gpart resize -i 2 -s 33554432 ada0 ada0p2 resized freebsd9# gpart show ada0 =>34 3907029101 ada0 GPT (1.8T) 34 30- free - (15k) 64 128 1 freebsd-boot (64k) 192 3907028936 2 freebsd-swap (1.8T) 3907029128 7- free - (3.5k) freebsd9# gpart resize -i 2 -s 33554432 ada0 ada0p2 resized freebsd9# gpart show ada0 =>34 3907029101 ada0 GPT (1.8T) 34 30- free - (15k) 64 128 1 freebsd-boot (64k) 19233554432 2 freebsd-swap (16G) 33554624 3873474511- free - (1.8T) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fsid change of ZFS?
Hi Rick, Rick Macklem wrote in <468764384.310026.1314219682612.javamail.r...@erie.cs.uoguelph.ca>: rm> It sounds like people have agreed that this is a reasonable solution. rm> If hrs@ can confirm that testing shows it fixes the original problem rm> (the ZFS file handles don't change when it's loaded at different times), rm> I'll pass it along to re@. I am sorry for the delay, but I tried the patch on several boxes and it worked fine: [old (fixed array) patch] % lsvfs Filesystem Num Refs Flags --- - --- ufs2 3 oldnfs15 0 network zfs7 4 jail, delegated-administration nfs6 1 network cd9660 1 0 read-only procfs 3 0 synthetic devfs 4 1 synthetic msdosfs5 0 [new (hash-based) patch] Filesystem Num Refs Flags --- - --- ufs 53 3 oldnfs77 0 network zfs 222 4 jail, delegated-administration nfs 58 0 network cd9660 189 0 read-only procfs 2 0 synthetic devfs113 1 synthetic msdosfs 50 0 [new patch, different loading order of kld modules] Filesystem Num Refs Flags --- - --- ufs 53 3 zfs 222 4 jail, delegated-administration cd9660 189 0 read-only procfs 2 0 synthetic devfs113 1 synthetic msdosfs 50 0 nfs 58 0 network Thanks a lot for the patch. I think it should be committed before 9.0R is released. Even for 8-STABLE this is useful but there is a problem that it will make an incomptibility of the fsid calculation between 8.N and 8.(N+1). What do you think about adding a loader tunable (something like vfs.fsidhash) to control this and making it disable by default? It would help sysadmins who will try a upgrade from 8.X to 9.X in the future, I think. -- Hiroki pgpqylKNsLgiT.pgp Description: PGP signature
RELENG_8 / mpt / zpool Errors
Hi all, I'm running RELENG_8: -- root@bsd-03: uname -a FreeBSD bsd-03 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon Aug 22 14:58:58 PDT 2011 root@bsd-03:/usr/obj/usr/src/sys/GENERIC amd64 -- We've got an MPT controller installed with 32 drives attached: -- root@bsd-03: dmesg | grep mpt mpt0: port 0xec00-0xecff mem 0xef3fc000-0xef3f,0xef3e-0xef3e irq 32 at device 0.0 on pci3 mpt0: [ITHREAD] mpt0: MPI Version=1.5.19.0 ses0 at mpt0 bus 0 scbus1 target 32 lun 0 ses1 at mpt0 bus 0 scbus1 target 33 lun 0 da5 at mpt0 bus 0 scbus1 target 0 lun 0 .SNIP. da36 at mpt0 bus 0 scbus1 target 31 lun 0 -- We have a zpool on those drives configured into one large zfs file system: -- root@bsd-03: zpool status pool: jails state: ONLINE scan: resilvered 5.51M in 0h12m with 0 errors on Tue Sep 6 15:10:23 2011 config: NAMESTATE READ WRITE CKSUM jails ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 da5 ONLINE 0 0 0 da6 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 da9 ONLINE 0 0 0 da10ONLINE 0 0 0 da11ONLINE 0 0 0 da12ONLINE 0 0 0 raidz1-1 ONLINE 0 0 0 da13ONLINE 0 0 0 da14ONLINE 0 0 0 da15ONLINE 0 0 0 da16ONLINE 0 0 0 da17ONLINE 0 0 0 da18ONLINE 0 0 0 da19ONLINE 0 0 0 da20ONLINE 0 0 0 raidz1-2 ONLINE 0 0 0 da21ONLINE 0 0 0 da22ONLINE 0 0 0 da23ONLINE 0 0 0 da24ONLINE 0 0 0 da25ONLINE 0 0 0 da26ONLINE 0 0 0 da27ONLINE 0 0 0 da28ONLINE 0 0 0 raidz1-3 ONLINE 0 0 0 da29ONLINE 0 0 0 da30ONLINE 0 0 0 da31ONLINE 0 0 0 da32ONLINE 0 0 0 da33ONLINE 0 0 0 da34ONLINE 0 0 0 da35ONLINE 0 0 0 da36ONLINE 0 0 0 errors: No known data errors -- We're seeing some occasional oddness. About every two weeks it seems the controller temporarily loses connectivity with the drives and the zpool goes a bit bonkers and reports a dozen or so corrupted files. A "zpool scrub" goes through and reports that everything's been fixed and everything seems OK again (although I have not 100% confirmed that there is no file corruption yet, but I'm giving ZFS's check-summing logic the benefit of the doubt here). When we have problems, it tends to be accompanied by the following in my dmesg: -- (da20:mpt0:0:15:0): READ(10). CDB: 28 0 90 b0 6b dd 0 0 9 0 (da20:mpt0:0:15:0): CAM status: SCSI Status Error (da20:mpt0:0:15:0): SCSI status: Check Condition (da20:mpt0:0:15:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (da17:mpt0:0:12:0): READ(10). CDB: 28 0 90 b0 6c e 0 0 2 0 (da17:mpt0:0:12:0): CAM status: SCSI Status Error (da17:mpt0:0:12:0): SCSI status: Check Condition (da17:mpt0:0:12:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) mpt0: request 0xff800080b520:10990 timed out for ccb 0xff013227b000 (req->ccb 0xff013227b000) mpt0: attempting to abort req 0xff800080b520:10990 function 0 mpt0: mpt_wait_req(1) timed out mpt0: mpt_recover_commands: abort timed-out. Resetting controller mpt0: mpt_cam_event: 0x0 mpt0: mpt_cam_event: 0x0 mpt0: completing timedout/aborted req 0xff800080b520:10990 mpt0: mpt_cam_event: 0x1b mpt0: mpt_cam_event: 0x1b mpt0: SAS discovery error: Port: 0x00 Status: 0x4002 mpt0: SAS discovery error: Port: 0x00 Status: 0x0010 mpt0: request 0xff8000811310:54341 timed out for ccb 0xff000897a000 (req->ccb 0xff000897a000) mpt0: attempting to abort req 0xff8000811310:54341 function 0 mpt0: mpt_wait_req(1) timed out mpt0: mpt_recover_commands: abort timed-out. Resetting controller mpt0: mpt_cam_event: 0x0 mpt0: completing timedout/aborted req 0xff8000811310:54341 mpt0: mpt_cam_event: 0x1b mpt0: mpt_cam_event: 0x1b -- So, is this an OS/driver issue? Is it a bad controller? Bad cables? Bad disks? As always, any help is greatly appreciated. Thanks! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafson
Re: BETA2 panic
On 05-09-2011 9:02, Bernhard Schmidt wrote: > On Mon, Sep 5, 2011 at 08:24, Joel Dahl wrote: > > On 05-09-2011 5:09, Adrian Chadd wrote: > >> On 5 September 2011 01:04, Joel Dahl wrote: > >> > Hi, > >> > > >> > I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop > >> > panics just a few minutes after booting. This is 100% reproducible, it > >> > panics every time. > >> > > >> > I've got a pic with the backtrace here: > >> > http://www.vnode.se/sc/panic_20110904.jpg > >> > >> Hi, > >> > >> There weren't many commits between BETA1 and -HEAD in the wireless > >> area; would you please do a binary search of the kernel revisions (no > >> need to do full buildworlds) to find which commit broke it? > > > > Yes, I'll do that tonight. > > While doing so, can you enable at least some debugging? > wlandebug +state > or even better > wlandebug 0x > > It smells like that something is poking the SW bmiss handler while not > in RUN state and therefore you're hitting a KASSERT(). Question is if > the bmiss timer isn't stopped/drained somewhere or if there is too > excessive call. Exactly what in the wlandebug output are you looking for? I've posted a pic at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like right before the panic. This is with "wlandebug 0x". I've also installed kernels all the way back to revision 222980, but they all panic, which I think is somewhat odd. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0 no longer attaches, cardbus problems?
On Tuesday, September 06, 2011 3:34:58 pm Daniel Eischen wrote: > On Tue, 6 Sep 2011, John Baldwin wrote: > > > On Friday, September 02, 2011 12:27:02 pm Daniel Eischen wrote: > >> On Thu, 25 Aug 2011, Daniel Eischen wrote: > >> > > [ snip ] > > >> Any hopes of getting this cardbus problem fixed? > > > > Hmm, the dmesg for the 'hostres' case shows the 'hostres' code as still > > being active. (And it does look like that is the root cause in your > > case perhaps.) Granted, we are asking for resources that your BIOS says > > work just fine, so I'm not sure why it is failing in the first place. > > > > Looks like I had a typo in my original e-mail, try "debug.acpi.disabled=hostres" > > rather than "debug.acpi.disable=hostres". > > Ok, I'll try that. > > FYI, I tried a few different kernels. So far, this is what > I've found (I'm using source from a local CVS repo since it's > easier than having to be online all the time): > >cvs -d /opt/FreeBSD/cvs checkout -D "15 Mar 2011" src > Works (ath0 loads) > >cvs -R update -P -d -A -D "22 Mar 2011" sys > Works (ath0 loads) > >cvs -R update -P -d -A -D "1 Apr 2011" sys > kernel panics > >cvs -R update -P -d -A -D "10 Apr 2011" sys > kernel panics > >cvs -R update -P -d -A -D "14 Apr 2011" sys > kernel panics > >cvs -R update -P -d -A -D "15 Apr 2011" sys > kernel panics > >cvs -R update -P -d -A -D "15 May 2011" sys > Fails (kernel works, ath0 doesn't load) > > I have not had the chance to find the exact endpoints of > where the kernel panics, and to test ath outside of > those endpoints. But somewhere between March 22 and > May 15 ath stopped working. Yes, there was a panic with cardbus with some of the PCI changes when they first went in. I wonder why the cardbus bit didn't work though. I wonder if there is a chance that the cardbus resources need to specifically not fit into the decoding windows of the parent bridge. Warner, does that ring a bell at all? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0 no longer attaches, cardbus problems?
On Tue, 6 Sep 2011, John Baldwin wrote: On Friday, September 02, 2011 12:27:02 pm Daniel Eischen wrote: On Thu, 25 Aug 2011, Daniel Eischen wrote: [ snip ] Any hopes of getting this cardbus problem fixed? Hmm, the dmesg for the 'hostres' case shows the 'hostres' code as still being active. (And it does look like that is the root cause in your case perhaps.) Granted, we are asking for resources that your BIOS says work just fine, so I'm not sure why it is failing in the first place. Looks like I had a typo in my original e-mail, try "debug.acpi.disabled=hostres" rather than "debug.acpi.disable=hostres". Ok, I'll try that. FYI, I tried a few different kernels. So far, this is what I've found (I'm using source from a local CVS repo since it's easier than having to be online all the time): cvs -d /opt/FreeBSD/cvs checkout -D "15 Mar 2011" src Works (ath0 loads) cvs -R update -P -d -A -D "22 Mar 2011" sys Works (ath0 loads) cvs -R update -P -d -A -D "1 Apr 2011" sys kernel panics cvs -R update -P -d -A -D "10 Apr 2011" sys kernel panics cvs -R update -P -d -A -D "14 Apr 2011" sys kernel panics cvs -R update -P -d -A -D "15 Apr 2011" sys kernel panics cvs -R update -P -d -A -D "15 May 2011" sys Fails (kernel works, ath0 doesn't load) I have not had the chance to find the exact endpoints of where the kernel panics, and to test ath outside of those endpoints. But somewhere between March 22 and May 15 ath stopped working. I don't have traceback for the panics, but I believe it was cardbus related. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Unusually high LA without any load at FreeBSD9-BETA2
In message <4e66547d.2030...@cran.org.uk>, Bruce Cran writes:
>On 06/09/2011 18:05, Garrett Cooper wrote:
>> What is "LA"?
>
>Load Average?
We should kille the load avarage as a measure for system activity,
it only has any relevance if you run heavy CPU bound processes.
If the majority of your threads yield their quantum, load average
contains absolutely no information of any relevance to system
capacity.
Try this:
main()
for (i = 0; i < 1; i++)
start thread {
calculate time until top of next second
sleep (until then)
}
You'll see a monster load-avg on idle cpus.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Unusually high LA without any load at FreeBSD9-BETA2
On Tue, Sep 06, 2011 at 05:22:02PM +, Poul-Henning Kamp wrote:
> In message <4e66547d.2030...@cran.org.uk>, Bruce Cran writes:
>>On 06/09/2011 18:05, Garrett Cooper wrote:
>>> What is "LA"?
>>Load Average?
> We should kille the load avarage as a measure for system activity,
> it only has any relevance if you run heavy CPU bound processes.
It may be true, but in current kernel from beginning of june I would
see la about 0,01 in this situation.
Note that cpu idling:
dev.cpu.0.freq: 300
dev.cpu.0.freq_levels: 2200/35000 1925/30625 1650/26250 1600/23000 1400/20125
1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 150/1875
dev.cpu.0.cx_supported: C1/1 C2/1 C3/17
[...]
11 root2 155 ki31 0K32K CPU11 29.4H 200.00% idle
I think process accounting get broken or something like this.
> If the majority of your threads yield their quantum, load average
> contains absolutely no information of any relevance to system
> capacity.
>
> Try this:
>
> main()
> for (i = 0; i < 1; i++)
> start thread {
> calculate time until top of next second
> sleep (until then)
> }
>
> You'll see a monster load-avg on idle cpus.
--
Adios
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Unusually high LA without any load at FreeBSD9-BETA2
On 09/06/2011 10:05, Garrett Cooper wrote: > On Tue, Sep 6, 2011 at 9:30 AM, Alex Kozlov wrote: >> Hi, current >> >> I see an unusually high LA for more than 10 hours without slightest load. >> Any ideas? > > What is "LA"? Load Average. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Unusually high LA without any load at FreeBSD9-BETA2
On 06/09/2011 18:05, Garrett Cooper wrote: What is "LA"? Load Average? -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Unusually high LA without any load at FreeBSD9-BETA2
On Tue, Sep 6, 2011 at 9:30 AM, Alex Kozlov wrote: > Hi, current > > I see an unusually high LA for more than 10 hours without slightest load. > Any ideas? What is "LA"? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Unusually high LA without any load at FreeBSD9-BETA2
Hi, current I see an unusually high LA for more than 10 hours without slightest load. Any ideas? FreeBSD 9-BETA2 r225400 amd64 $sysctl cpu HAMMER kern.ccpu: 0 kern.sched.cpusetsize: 8 0, 1 0, 1 kern.smp.cpus: 2 kern.smp.maxcpus: 64 dev.cpu.0.freq: 300 dev.cpu.0.freq_levels: 2200/35000 1925/30625 1650/26250 1600/23000 1400/20125 1200/15000 1050/13125 900/11250 750/9375 600/7500 450/5625 300/3750 150/1875 dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 0.00% 100.00% 0.00% last 240us dev.cpu.1.cx_supported: C1/1 C2/1 C3/17 dev.cpu.1.cx_lowest: C2 dev.cpu.1.cx_usage: 0.00% 100.00% 0.00% last 857us $vmstat -i interrupt total rate irq1: atkbd0 160 0 irq9: acpi044432 0 irq12: psm09 0 irq17: ath0 uhci3 45696 0 irq20: hpet0 uhci0* 4920185 92 irq23: uhci2 ehci1 9276 0 irq256: hdac0 8 0 irq257: ahci0 26674 0 Total5046440 94 $top# last pid changes very slowly last pid: 4814; load averages: 0.75, 0.72, 0.73up 0+14:48:02 19:10:51 36 processes: 2 running, 33 sleeping, 1 waiting CPU: 0.2% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.8% idle Mem: 23M Active, 376M Inact, 246M Wired, 120K Cache, 309M Buf, 2256M Free Swap: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 11 root2 155 ki31 0K32K CPU11 29.4H 200.00% idle 4808 kozlov 1 200 16616K 2164K CPU00 0:01 0.20% top 12 root 16 -84- 0K 256K WAIT1 3:33 0.00% intr 1316 root1 200 12096K 1308K select 0 0:26 0.00% powerd 16 root1 -16- 0K16K tzpoll 1 0:20 0.00% acpi_thermal 14 root1 -16- 0K16K - 0 0:12 0.00% yarrow 15 root 32 -68- 0K 512K - 0 0:09 0.00% usb 13 root3 -8- 0K48K - 1 0:06 0.00% geom 1453 kozlov 1 200 47996K 4644K select 0 0:05 0.00% sshd 0 root 10 -520 0K 160K - 1 0:04 0.00% kernel 8 root1 16- 0K16K syncer 0 0:03 0.00% syncer 1363 root1 210 14176K 1644K nanslp 1 0:03 0.00% cron 1440 root1 200 412M 347M select 0 0:02 0.00% Xorg 9 root1 -16- 0K16K sdflus 1 0:01 0.00% softdepflush 1454 kozlov 1 200 16456K 3024K wait1 0:01 0.00% bash 7 root1 -16- 0K16K vlruwt 0 0:01 0.00% vnlru 6 root1 -16- 0K16K psleep 1 0:01 0.00% bufdaemon 1091 root1 200 12228K 1484K select 0 0:01 0.00% syslogd 1694 root1 -8- 0K16K mdwait 0 0:01 0.00% md4 121 root1 -8- 0K16K mdwait 0 0:00 0.00% md1 3 root1 -16- 0K16K psleep 0 0:00 0.00% pagedaemon 1451 root1 440 47996K 4304K sbwait 0 0:00 0.00% sshd 1445 root1 260 71764K 6224K select 0 0:00 0.00% xdm 1350 root1 210 28916K 3508K select 1 0:00 0.00% sshd 1438 root1 260 41068K 2916K pause 0 0:00 0.00% xdm 945 root1 200 10372K 3412K select 0 0:00 0.00% devd 1142 root1 -8- 0K16K mdwait 1 0:00 0.00% md2 1280 root1 -8- 0K16K mdwait 0 0:00 0.00% md3 5 root1 155 ki31 0K16K pgzero 0 0:00 0.00% pagezero 1 root1 200 6276K 600K wait0 0:00 0.00% init 1437 root1 520 12100K 1352K ttyin 1 0:00 0.00% getty 1436 root1 520 12100K 1352K ttyin 0 0:00 0.00% getty 109 root1 -8- 0K16K mdwait 0 0:00 0.00% md0 2 root1 -16- 0K16K ccb_sc 1 0:00 0.00% xpt_thrd 4 root1 -16- 0K16K psleep 1 0:00 0.00% vmdaemon 10 root1 -16- 0K16K audit_ 0 0:00 0.00% audit ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
06.09.2011 16:25, Olivier Smedts wrote: Can you compile the Host.cpp file referenced in : http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024499.html And see which arch the resulting binary detects ? %clang++ Host.cpp -o Host %./Host cpu = corei7 cpu = athlon-xp > Also, do you have the same problem for a clean buildworld with > "-march=athlon-xp" instead of "-march=native" in your make.conf ? I'm proceeding with buildworld but I don't think this would get you anyway: [limbo] ~> clang++ -v -march=athlon-xp Host.cpp FreeBSD clang version 3.0 (trunk 135360) 20110717 Target: i386-unknown-freebsd9.0 Thread model: posix "/usr/bin/clang++" -cc1 -triple i386-unknown-freebsd9.0 -emit-obj -mrelax-all -disable-free -main-file-name Host.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu athlon-xp -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 144 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Cq9USc.o -x c++ Host.cpp clang -cc1 version 3.0 based upon llvm 3.0svn hosted on i386-unknown-freebsd9.0 ignoring nonexistent directory "/usr/include/c++/4.2/backward/backward" ignoring nonexistent directory "/usr/bin/../lib/clang/3.0/include" ignoring duplicate directory "/usr/include/c++/4.2" ignoring duplicate directory "/usr/include/c++/4.2/backward" ignoring duplicate directory "/usr/include/c++/4.2/backward" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/backward /usr/include/clang/3.0 /usr/include End of search list. "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 -m elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/cc-Cq9USc.o -lstdc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o [limbo] ~> clang++ -v -march=native Host.cpp FreeBSD clang version 3.0 (trunk 135360) 20110717 Target: i386-unknown-freebsd9.0 Thread model: posix "/usr/bin/clang++" -cc1 -triple i386-unknown-freebsd9.0 -emit-obj -mrelax-all -disable-free -main-file-name Host.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu athlon-xp -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length 144 -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-7bAsbw.o -x c++ Host.cpp clang -cc1 version 3.0 based upon llvm 3.0svn hosted on i386-unknown-freebsd9.0 ignoring nonexistent directory "/usr/include/c++/4.2/backward/backward" ignoring nonexistent directory "/usr/bin/../lib/clang/3.0/include" ignoring duplicate directory "/usr/include/c++/4.2" ignoring duplicate directory "/usr/include/c++/4.2/backward" ignoring duplicate directory "/usr/include/c++/4.2/backward" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/backward /usr/include/clang/3.0 /usr/include End of search list. "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 -m elf_i386_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/cc-7bAsbw.o -lstdc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
06.09.2011 15:01, Dimitry Andric wrote: Hm, sorry that I did not notice it before, but maybe you are having the issue described here: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026594.html What is your current kernel revision? I'm very sorry, my kernel is somewhat older then I thought: # uname -a FreeBSD limbo.lan 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Mon Aug 29 09:56:12 EEST 2011 arc...@limbo.lan:/usr/obj/usr/src/sys/MINIMAL i386 Not subject to the bug though... -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath0 no longer attaches, cardbus problems?
On Friday, September 02, 2011 12:27:02 pm Daniel Eischen wrote: > On Thu, 25 Aug 2011, Daniel Eischen wrote: > > > On Thu, 25 Aug 2011, John Baldwin wrote: > > > >> On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote: > >>> Hello, > >>> > >>> I have an older Dell 4150 laptop that takes forever to build > >>> world, so I don't update it that often. The last time I > >>> updated it was March 1, 2010. I just updated the system > >>> yesterday and ath0 (a Linksys PCCard) no longer attaches. > >>> > >>> The interesting thing is that ath0 is detected at different > >>> addresses between the working kernel and the non-working > >>> kernel: > >>> > >>>March 1, 2010 kernel > >>> > >>>ath0: mem 0x8800-0x8800 irq 11 > >>>at device 0.0 on cardbus0 > >>>ath0: [ITHREAD] > >>>ath0: AR5212 mac 5.9 RF5112 phy 4.3 > >>> > >>> > >>>Aug 23, 2011 kernel > >>>--- > >>>ath0: mem 0xf8f1-0xf8f1 irq 11 > >>>at device 0.0 on cardbus0 > >>> > >>> > >>> I've tried forcing successful returns from > >>> ar5212SetPowerModeAwake() and ar5212SetResetReg() > >>> but it doesn't help (diffs below). > >>> > >>> Any suggestions on how to get this to work? > >>> Full dmesg from working and non-working kernels at > >>> > >>>http://people.freebsd.org/~deischen/ath/ath.dmesg > >> > >> You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a > >> test. If that doesn't work, a verbose dmesg from the broken case as well > >> as > >> devinfo -u and devinfo -r output from the working and broken cases would be > >> most useful. > > > > Setting debug.acpi.disable=hostres did not work. Strange thing is > > that ath0 is now at mem 0x8800-0x8800 for both working > > and non-working kernels (with and without debug.acpi.disable=hostres). > > ath0 still doesn't attach, but it seems funny that the memory > > address changes. These are all soft reboots, not hard reboots, > > after a working kernel. > > > > All the information you requested is here: > > > > http://people.freebsd.org/~deischen/ath/ > > > > There are verbose boots and devinfo -u/-r output for the > > working kernel and the non-working kernel (with and without > > debug.acpi.disable=hostres). > > > > Anything else you'd like me to try? > > Any hopes of getting this cardbus problem fixed? Hmm, the dmesg for the 'hostres' case shows the 'hostres' code as still being active. (And it does look like that is the root cause in your case perhaps.) Granted, we are asking for resources that your BIOS says work just fine, so I'm not sure why it is failing in the first place. Looks like I had a typo in my original e-mail, try "debug.acpi.disabled=hostres" rather than "debug.acpi.disable=hostres". -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lock order reversal
Thanks, K. Macy Ok Sorry to disturb K. Macy wrote: When WITNESS support was added to lockmgr locks a number of longstanding LORs were exposed in the process. I can't comment on whether or not they'll be fixed or the warnings will some day be silenced. On Tue, Sep 6, 2011 at 2:58 PM, Vadim Denisov wrote: I install current on last week I have some messages in dmesg -a: lock order reversal: 1st 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425 2nd 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 3rd 0xc7d89168 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546 KDB: stack backtrace: db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,a363435,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c088dd7b,c0c38d9c,c7535098,c75385d0,ef9e1404,...) at kdb_backtrace+0x2a _witness_debugger(c0c38d9c,c7d89168,c0c2816c,c75385d0,c0c56442,...) at _witness_debugger+0x25 witness_checkorder(c7d89168,9,c0c56442,222,0,...) at witness_checkorder+0x839 __lockmgr_args(c7d89168,80100,c7d89188,0,0,...) at __lockmgr_args+0x824 ffs_lock(ef9e152c,c0ecca08,c7dc1c30,80100,c7d89110,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d3c680,ef9e152c,ef9e154c,c0d4caa0,c7d89110,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c7d89110,80100,c0c56442,222,c755ce80,...) at _vn_lock+0x5e ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x14fc ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13 vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at vfs_donmount+0x1219 nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84 syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at syscallenter+0x263 syscall(ef9e1d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp = 0xbfbfea9c, ebp = 0xbfbfede8 --- lock order reversal: 1st 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818 KDB: stack backtrace: db_trace_self_wrapper(c0c353ac,662f7366,735f7366,7370616e,2e746f68,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c088dd7b,c0c38d83,c7535098,c7538978,ef9e1404,...) at kdb_backtrace+0x2a _witness_debugger(c0c38d83,c7563c9c,c0c564a4,c7538978,c0c56442,...) at _witness_debugger+0x25 witness_checkorder(c7563c9c,9,c0c56442,332,c81ba298,...) at witness_checkorder+0x839 __lockmgr_args(c7563c9c,80400,c81ba298,0,0,...) at __lockmgr_args+0x824 ffs_lock(ef9e152c,e0ef5790,10,80400,c81ba220,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d3c680,ef9e152c,e0ef57ec,c0d4caa0,c81ba220,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c81ba220,80400,c0c56442,332,0,...) at _vn_lock+0x5e ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x298e ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13 vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at vfs_donmount+0x1219 nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84 syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at syscallenter+0x263 syscall(ef9e1d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp = 0xbfbfea9c, ebp = 0xbfbfede8 --- lock order reversal: 1st 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:307 2nd 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1620 KDB: stack backtrace: db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,30323631,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c088dd7b,c0c38d83,c7538978,c75385d0,ef9e16c8,...) at kdb_backtrace+0x2a _witness_debugger(c0c38d83,c81ba278,c0c2816c,c75385d0,c0c56442,...) at _witness_debugger+0x25 witness_checkorder(c81ba278,9,c0c56442,654,0,...) at witness_checkorder+0x839 __lockmgr_args(c81ba278,8,0,0,0,...) at __lockmgr_args+0x824 ffs_snapremove(c81ba220,8,c0c3e10a,5e8,c7535098,...) at ffs_snapremove+0x11f ffs_truncate(c81ba220,0,0,c00,0,...) at ffs_truncate+0x577 ufs_inactive(ef9e1a9c,c81ba298,c81ba220,c81ba298,ef9e1ab4,...) at ufs_inactive+0x1f8 VOP_INACTIVE_APV(c0d3c680,ef9e1a9c,c0c40a67,94e,c0d4ca60,...) at VOP_INACTIVE_APV+0xa5 vinactive(c0d3c680,ef9e1ad0,c0c40a67,8a5,0,...) at vinactive+0x8e vputx(ef9e1b38,c08febda,c81ba220,ef9e1b14,c0c41f00,...) at vputx+0x2f8 vput(c81ba220,ef9e1b14,c0c41f00,133,0,...) at vput+0x10 vn_close(c81ba220,1,c755ce00,c7dc1b80,0,...) at vn_close+0x19a vn_closefile(c7c300a8,c7dc1b80,c0c2706c,0,c7c300a8,...) at vn_closefile+0xe4 _fdrop(c7c300a8,c7dc1b80,0,ef9e1bfc,0,c0ecc9d8,c7dc1c30,c0d28da0,c0ecc9d8,c0c2af54,c7dc1b80,c7b05d2c,4ce,ef9e1c0c,c085d087,c7b05d2c,8,c0c2af54,c7c300a8) at _fdrop+0x43 closef(c7c300a8,c7dc1b80,4ce,ef9e1c30,c7b05d2c,...) at closef+0x2b0 kern_close(c7dc1b80,4,ef9e1c7c,c0897ff3,c7dc1b80,...) at kern_close+0x139 close(c7dc1b80,ef9e1cec,ef9e1d28,c0c3767a,0,...) at close+0x1a syscallenter(c7dc1b80,ef9e1ce4,ef9e1ce4,0,c0d819f0,...) at syscallenter+0x263 syscall(ef9e1d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_
Re: Compiling BETA2 with clang fails
06.09.2011 16:25, Olivier Smedts wrote: What is your processor ? Athlon XP 2500+ I noticed breakage on recent intel processors too, but haven't yet stumbled upon them using -march=native on this one. Can you compile the Host.cpp file referenced in : http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024499.html Ah, thanks for the link. Missed that one. I'll post results when I'll have access to that machine. And see which arch the resulting binary detects ? %clang++ Host.cpp -o Host %./Host cpu = corei7 Also, do you have the same problem for a clean buildworld with "-march=athlon-xp" instead of "-march=native" in your make.conf ? You mean like fully rebuilding system with gcc and -march=athlon-xp and then try again? -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
06.09.2011 15:01, Dimitry Andric wrote: Hm, sorry that I did not notice it before, but maybe you are having the issue described here: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026594.html What is your current kernel revision? Can't remember and the machine is offline right now. I just can say it's running BETA2 from Sep 2 now. -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lock order reversal
When WITNESS support was added to lockmgr locks a number of longstanding LORs were exposed in the process. I can't comment on whether or not they'll be fixed or the warnings will some day be silenced. On Tue, Sep 6, 2011 at 2:58 PM, Vadim Denisov wrote: > I install current on last week > I have some messages in dmesg -a: > lock order reversal: > 1st 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425 > 2nd 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 > 3rd 0xc7d89168 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546 > KDB: stack backtrace: > db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,a363435,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c088dd7b,c0c38d9c,c7535098,c75385d0,ef9e1404,...) at > kdb_backtrace+0x2a > _witness_debugger(c0c38d9c,c7d89168,c0c2816c,c75385d0,c0c56442,...) at > _witness_debugger+0x25 > witness_checkorder(c7d89168,9,c0c56442,222,0,...) at > witness_checkorder+0x839 > __lockmgr_args(c7d89168,80100,c7d89188,0,0,...) at __lockmgr_args+0x824 > ffs_lock(ef9e152c,c0ecca08,c7dc1c30,80100,c7d89110,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0d3c680,ef9e152c,ef9e154c,c0d4caa0,c7d89110,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c7d89110,80100,c0c56442,222,c755ce80,...) at _vn_lock+0x5e > ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x14fc > ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13 > vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at > vfs_donmount+0x1219 > nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84 > syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at > syscallenter+0x263 > syscall(ef9e1d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp = > 0xbfbfea9c, ebp = 0xbfbfede8 --- > lock order reversal: > 1st 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 > 2nd 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818 > KDB: stack backtrace: > db_trace_self_wrapper(c0c353ac,662f7366,735f7366,7370616e,2e746f68,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c088dd7b,c0c38d83,c7535098,c7538978,ef9e1404,...) at > kdb_backtrace+0x2a > _witness_debugger(c0c38d83,c7563c9c,c0c564a4,c7538978,c0c56442,...) at > _witness_debugger+0x25 > witness_checkorder(c7563c9c,9,c0c56442,332,c81ba298,...) at > witness_checkorder+0x839 > __lockmgr_args(c7563c9c,80400,c81ba298,0,0,...) at __lockmgr_args+0x824 > ffs_lock(ef9e152c,e0ef5790,10,80400,c81ba220,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0d3c680,ef9e152c,e0ef57ec,c0d4caa0,c81ba220,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c81ba220,80400,c0c56442,332,0,...) at _vn_lock+0x5e > ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x298e > ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13 > vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at > vfs_donmount+0x1219 > nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84 > syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at > syscallenter+0x263 > syscall(ef9e1d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp = > 0xbfbfea9c, ebp = 0xbfbfede8 --- > lock order reversal: > 1st 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:307 > 2nd 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1620 > KDB: stack backtrace: > db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,30323631,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c088dd7b,c0c38d83,c7538978,c75385d0,ef9e16c8,...) at > kdb_backtrace+0x2a > _witness_debugger(c0c38d83,c81ba278,c0c2816c,c75385d0,c0c56442,...) at > _witness_debugger+0x25 > witness_checkorder(c81ba278,9,c0c56442,654,0,...) at > witness_checkorder+0x839 > __lockmgr_args(c81ba278,8,0,0,0,...) at __lockmgr_args+0x824 > ffs_snapremove(c81ba220,8,c0c3e10a,5e8,c7535098,...) at ffs_snapremove+0x11f > ffs_truncate(c81ba220,0,0,c00,0,...) at ffs_truncate+0x577 > ufs_inactive(ef9e1a9c,c81ba298,c81ba220,c81ba298,ef9e1ab4,...) at > ufs_inactive+0x1f8 > VOP_INACTIVE_APV(c0d3c680,ef9e1a9c,c0c40a67,94e,c0d4ca60,...) at > VOP_INACTIVE_APV+0xa5 > vinactive(c0d3c680,ef9e1ad0,c0c40a67,8a5,0,...) at vinactive+0x8e > vputx(ef9e1b38,c08febda,c81ba220,ef9e1b14,c0c41f00,...) at vputx+0x2f8 > vput(c81ba220,ef9e1b14,c0c41f00,133,0,...) at vput+0x10 > vn_close(c81ba220,1,c755ce00,c7dc1b80,0,...) at vn_close+0x19a > vn_closefile(c7c300a8,c7dc1b80,c0c2706c,0,c7c300a8,...) at vn_closefile+0xe4 > _fdrop(c7c300a8,c7dc1b80,0,ef9e1bfc,0,c0ecc9d8,c7dc1c30,c0d28da0,c0ecc9d8,c0c2af54,c7dc1b80,c7b05d2c,4ce,ef9e1c0c,c085d087,c7b05d2c,8,c0c2af54,c7c300a8) > at _fdrop+0x43 > closef(c7c300a8,c7dc1b80,4ce,ef9e1c30,c7b05d2c,...) at closef+0x2b0 > kern_close(c7dc1b80,4,ef9e1c7c,c0897ff3,c7dc1b80,...) at kern_close+0x139 > close(c7dc1b80,ef9e1cec,ef9e1d28,c0c3767a,0,...) at close+0x1a > syscallenter(c7dc1b80,ef
lock order reversal
I install current on last week I have some messages in dmesg -a: lock order reversal: 1st 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425 2nd 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 3rd 0xc7d89168 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546 KDB: stack backtrace: db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,a363435,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c088dd7b,c0c38d9c,c7535098,c75385d0,ef9e1404,...) at kdb_backtrace+0x2a _witness_debugger(c0c38d9c,c7d89168,c0c2816c,c75385d0,c0c56442,...) at _witness_debugger+0x25 witness_checkorder(c7d89168,9,c0c56442,222,0,...) at witness_checkorder+0x839 __lockmgr_args(c7d89168,80100,c7d89188,0,0,...) at __lockmgr_args+0x824 ffs_lock(ef9e152c,c0ecca08,c7dc1c30,80100,c7d89110,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d3c680,ef9e152c,ef9e154c,c0d4caa0,c7d89110,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c7d89110,80100,c0c56442,222,c755ce80,...) at _vn_lock+0x5e ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x14fc ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13 vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at vfs_donmount+0x1219 nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84 syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at syscallenter+0x263 syscall(ef9e1d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp = 0xbfbfea9c, ebp = 0xbfbfede8 --- lock order reversal: 1st 0xe0f566d0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818 KDB: stack backtrace: db_trace_self_wrapper(c0c353ac,662f7366,735f7366,7370616e,2e746f68,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c088dd7b,c0c38d83,c7535098,c7538978,ef9e1404,...) at kdb_backtrace+0x2a _witness_debugger(c0c38d83,c7563c9c,c0c564a4,c7538978,c0c56442,...) at _witness_debugger+0x25 witness_checkorder(c7563c9c,9,c0c56442,332,c81ba298,...) at witness_checkorder+0x839 __lockmgr_args(c7563c9c,80400,c81ba298,0,0,...) at __lockmgr_args+0x824 ffs_lock(ef9e152c,e0ef5790,10,80400,c81ba220,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d3c680,ef9e152c,e0ef57ec,c0d4caa0,c81ba220,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c81ba220,80400,c0c56442,332,0,...) at _vn_lock+0x5e ffs_snapshot(c7beba20,c7b753e0,c0c59850,1a2,0,...) at ffs_snapshot+0x298e ffs_mount(c7beba20,c7bf5d00,ff,394,c7dc1c30,...) at ffs_mount+0x1c13 vfs_donmount(c7dc1b80,211000,c7787780,c7787780,c7dbb588,...) at vfs_donmount+0x1219 nmount(c7dc1b80,ef9e1cec,c087a16c,ef9e1d80,0,...) at nmount+0x84 syscallenter(c7dc1b80,ef9e1ce4,ef9e1d1c,c0acbf86,c0d90c80,...) at syscallenter+0x263 syscall(ef9e1d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280fb61b, esp = 0xbfbfea9c, ebp = 0xbfbfede8 --- lock order reversal: 1st 0xc7563c9c snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:307 2nd 0xc81ba278 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1620 KDB: stack backtrace: db_trace_self_wrapper(c0c353ac,616e735f,6f687370,3a632e74,30323631,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c088dd7b,c0c38d83,c7538978,c75385d0,ef9e16c8,...) at kdb_backtrace+0x2a _witness_debugger(c0c38d83,c81ba278,c0c2816c,c75385d0,c0c56442,...) at _witness_debugger+0x25 witness_checkorder(c81ba278,9,c0c56442,654,0,...) at witness_checkorder+0x839 __lockmgr_args(c81ba278,8,0,0,0,...) at __lockmgr_args+0x824 ffs_snapremove(c81ba220,8,c0c3e10a,5e8,c7535098,...) at ffs_snapremove+0x11f ffs_truncate(c81ba220,0,0,c00,0,...) at ffs_truncate+0x577 ufs_inactive(ef9e1a9c,c81ba298,c81ba220,c81ba298,ef9e1ab4,...) at ufs_inactive+0x1f8 VOP_INACTIVE_APV(c0d3c680,ef9e1a9c,c0c40a67,94e,c0d4ca60,...) at VOP_INACTIVE_APV+0xa5 vinactive(c0d3c680,ef9e1ad0,c0c40a67,8a5,0,...) at vinactive+0x8e vputx(ef9e1b38,c08febda,c81ba220,ef9e1b14,c0c41f00,...) at vputx+0x2f8 vput(c81ba220,ef9e1b14,c0c41f00,133,0,...) at vput+0x10 vn_close(c81ba220,1,c755ce00,c7dc1b80,0,...) at vn_close+0x19a vn_closefile(c7c300a8,c7dc1b80,c0c2706c,0,c7c300a8,...) at vn_closefile+0xe4 _fdrop(c7c300a8,c7dc1b80,0,ef9e1bfc,0,c0ecc9d8,c7dc1c30,c0d28da0,c0ecc9d8,c0c2af54,c7dc1b80,c7b05d2c,4ce,ef9e1c0c,c085d087,c7b05d2c,8,c0c2af54,c7c300a8) at _fdrop+0x43 closef(c7c300a8,c7dc1b80,4ce,ef9e1c30,c7b05d2c,...) at closef+0x2b0 kern_close(c7dc1b80,4,ef9e1c7c,c0897ff3,c7dc1b80,...) at kern_close+0x139 close(c7dc1b80,ef9e1cec,ef9e1d28,c0c3767a,0,...) at close+0x1a syscallenter(c7dc1b80,ef9e1ce4,ef9e1ce4,0,c0d819f0,...) at syscallenter+0x263 syscall(ef9e1d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (6, FreeBSD ELF32, close), eip = 0x281a3283, esp = 0xbfbfea9c, ebp = 0xbfbfede8 --- Sep 5 12:38:10 su: denisov to root on /dev/pts/0 lock order reversal: 1st 0xe10fbc60 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xc7c5d600 dirhash
Re: Where did the 9.0 BETA1 images go?
On 09/06/11 07:07, Vincent Hoffman wrote: On 06/09/2011 09:44, Kurt Jaeger wrote: Hi! But sadly they seem to be gone from the FTP servers. The system has beside its harddisks only a floppy drive (no space for a CD-ROM) so I would need the memstick image Any idea where I could get FreeBSD-9.0-BETA1-amd64-memstick.img from? There is BETA2 at ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0/FreeBSD-9.0-BETA2-amd64-memstick.img but I think this directory name (amd64/amd64) is a mishap. Is it ? I believe that its been changed due to the introduction of platforms where uname -m and uname -p arent the same. To do with the new installer I imagine. Vince When this came up in another conversation, I found: http://lists.freebsd.org/pipermail/freebsd-hubs/2011-September/002380.html -- Sam Cassiba ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
2011/9/6 Volodymyr Kostyrko : > 06.09.2011 16:04, Olivier Smedts wrote: > I think it's more like the following issue, which is not new : http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024509.html >>> >>> Nope, my current world was built by gcc. >> >> The problem is not the current world but the bootstrap clang built >> with -march=native (or -march=recent_cpu) on some recent CPUs. >> >> What is your processor ? > > Athlon XP 2500+ > > I noticed breakage on recent intel processors too, but haven't yet stumbled > upon them using -march=native on this one. Can you compile the Host.cpp file referenced in : http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024499.html And see which arch the resulting binary detects ? %clang++ Host.cpp -o Host %./Host cpu = corei7 Also, do you have the same problem for a clean buildworld with "-march=athlon-xp" instead of "-march=native" in your make.conf ? Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
06.09.2011 16:04, Olivier Smedts wrote: I think it's more like the following issue, which is not new : http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024509.html Nope, my current world was built by gcc. The problem is not the current world but the bootstrap clang built with -march=native (or -march=recent_cpu) on some recent CPUs. What is your processor ? Athlon XP 2500+ I noticed breakage on recent intel processors too, but haven't yet stumbled upon them using -march=native on this one. -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
2011/9/6 Volodymyr Kostyrko : > 06.09.2011 15:34, Olivier Smedts wrote: >>> >>> Hm, sorry that I did not notice it before, but maybe you are having the >>> issue described here: >>> >>> >>> http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026594.html >> >> I think it's more like the following issue, which is not new : >> http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024509.html > > Nope, my current world was built by gcc. The problem is not the current world but the bootstrap clang built with -march=native (or -march=recent_cpu) on some recent CPUs. What is your processor ? >> I personally avoid -march=native with clang on recent CPUs, and use >> -march=core2 instead on a Core2 and a Corei7. > > -- > Sphinx of black quartz judge my vow. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
06.09.2011 15:34, Olivier Smedts wrote: Hm, sorry that I did not notice it before, but maybe you are having the issue described here: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026594.html I think it's more like the following issue, which is not new : http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024509.html Nope, my current world was built by gcc. I personally avoid -march=native with clang on recent CPUs, and use -march=core2 instead on a Core2 and a Corei7. -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
2011/9/6 Dimitry Andric : > On 2011-09-05 06:01, Volodymyr Kostyrko wrote: > ... >>> >>> You should not unconditionally add -fPIC. Remove it, and try again. >>> (The -Qunused-arguments is fine, btw.) >> >> 0k, here you go. Just as you say - no -fPIC, no ccache, no anything. > > ... >> >> /usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start1': >> /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x7d): undefined reference to >> `atexit' >> /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x84): undefined reference to >> `_init_tls' >> /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x90): undefined reference to >> `atexit' >> /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xad): undefined reference to >> `exit' > > Hm, sorry that I did not notice it before, but maybe you are having the > issue described here: > > http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026594.html I think it's more like the following issue, which is not new : http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024509.html I personally avoid -march=native with clang on recent CPUs, and use -march=core2 instead on a Core2 and a Corei7. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Serial Port Configuration does not work
Hi List, the port does not work as expected (at least as per The Handbook, 26.2.5 Serial Port Configuration). Nether "init" nor "lock" devices can be used: - # uname -a FreeBSD host1.ipt.ru 9.0-BETA2 FreeBSD 9.0-BETA2 #14 r225395: Mon Sep 5 18:10:43 MSK 2011 b...@bb.ipt.ru:/usr/obj/usr/src/sys/HOSTS i386 # ls -l /dev/ttyu5* crw--- 1 root wheel0, 56 Sep 5 18:50 /dev/ttyu5 crw--- 1 root wheel0, 57 Sep 5 18:50 /dev/ttyu5.init crw--- 1 root wheel0, 58 Sep 5 18:50 /dev/ttyu5.lock # stty -f /dev/ttyu5.init 57600 stty: /dev/ttyu5.lock isn't a terminal # stty -f /dev/ttyu5.lock cs7 stty: /dev/ttyu5.lock isn't a terminal - -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Where did the 9.0 BETA1 images go?
On 06/09/2011 09:44, Kurt Jaeger wrote: > Hi! > >> But sadly they seem to be gone from the FTP servers. The system has >> beside its harddisks only a floppy drive (no space for a CD-ROM) so >> I would need the memstick image >> Any idea where I could get FreeBSD-9.0-BETA1-amd64-memstick.img from? > There is BETA2 at > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0/FreeBSD-9.0-BETA2-amd64-memstick.img > > > but I think this directory name (amd64/amd64) is a mishap. Is it ? > I believe that its been changed due to the introduction of platforms where uname -m and uname -p arent the same. To do with the new installer I imagine. Vince ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
On 2011-09-05 06:01, Volodymyr Kostyrko wrote: ... You should not unconditionally add -fPIC. Remove it, and try again. (The -Qunused-arguments is fine, btw.) 0k, here you go. Just as you say - no -fPIC, no ccache, no anything. ... /usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start1': /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x7d): undefined reference to `atexit' /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x84): undefined reference to `_init_tls' /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x90): undefined reference to `atexit' /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xad): undefined reference to `exit' Hm, sorry that I did not notice it before, but maybe you are having the issue described here: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026594.html What is your current kernel revision? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Where did the 9.0 BETA1 images go?
Hi! > But sadly they seem to be gone from the FTP servers. The system has > beside its harddisks only a floppy drive (no space for a CD-ROM) so > I would need the memstick image > Any idea where I could get FreeBSD-9.0-BETA1-amd64-memstick.img from? There is BETA2 at ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0/FreeBSD-9.0-BETA2-amd64-memstick.img but I think this directory name (amd64/amd64) is a mishap. Is it ? -- p...@opsec.eu+49 171 3101372 9 years to go ! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Where did the 9.0 BETA1 images go?
Hi,
I don't know why the directory layout changed, but here it is.
ftp://{FTP
mirror}/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0/FreeBSD-9.0-BETA2-amd64-memstick.img
Regards.
--
Gen O.
On Tue, 06 Sep 2011 09:41:04 +0200
Oliver Lehmann wrote:
> Hi,
>
> I'm about to replace some harddisks in my fileserver and plan to
> reinstall FreeBSD this weekend on it. I'll also switch from i386 to amd64
> as the hardware the system runs on has changed last year as well.
> I don't want to install 8 again as I don't want to reinstall / upgrade
> 8 -> 9 later when 9 is finally released. I did this as well when 8 was
> about to be released and used images from some japanese snapshot server
> back those days (as far as I can remember).
>
> I now saw announces from august, that some BETA1 images of 9.0 where
> "released" and wanted to use those:
>
> http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026181.html
> http://www.freebsdnews.net/2011/08/01/freebsd-9-beta1-testing/
>
> But sadly they seem to be gone from the FTP servers. The system has
> beside its harddisks only a floppy drive (no space for a CD-ROM) so
> I would need the memstick image
> Any idea where I could get FreeBSD-9.0-BETA1-amd64-memstick.img from?
>
> I'd like to do the upgrade this weekend as the system runs actually a
> degraded gmirror (2 already broken drives and no spare drive left...)
> and who knows when the last remaining drive fails as well...
>
>Greetings, Oliver
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> FLAGS (\Seen)
--
Gen O.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Where did the 9.0 BETA1 images go?
On Tue, Sep 6, 2011 at 10:41 AM, Oliver Lehmann wrote: > Hi, > > I'm about to replace some harddisks in my fileserver and plan to > reinstall FreeBSD this weekend on it. I'll also switch from i386 to amd64 > as the hardware the system runs on has changed last year as well. > I don't want to install 8 again as I don't want to reinstall / upgrade > 8 -> 9 later when 9 is finally released. I did this as well when 8 was > about to be released and used images from some japanese snapshot server > back those days (as far as I can remember). > > I now saw announces from august, that some BETA1 images of 9.0 where > "released" and wanted to use those: > > http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026181.html > http://www.freebsdnews.net/2011/08/01/freebsd-9-beta1-testing/ > > But sadly they seem to be gone from the FTP servers. The system has > beside its harddisks only a floppy drive (no space for a CD-ROM) so > I would need the memstick image > Any idea where I could get FreeBSD-9.0-BETA1-amd64-memstick.img from? > > I'd like to do the upgrade this weekend as the system runs actually a > degraded gmirror (2 already broken drives and no spare drive left...) > and who knows when the last remaining drive fails as well... > > Greetings, Oliver http://ftp.ntua.gr/pub/FreeBSD/releases/amd64/ISO-IMAGES/9.0/ Regards, George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Where did the 9.0 BETA1 images go?
Hi, I'm about to replace some harddisks in my fileserver and plan to reinstall FreeBSD this weekend on it. I'll also switch from i386 to amd64 as the hardware the system runs on has changed last year as well. I don't want to install 8 again as I don't want to reinstall / upgrade 8 -> 9 later when 9 is finally released. I did this as well when 8 was about to be released and used images from some japanese snapshot server back those days (as far as I can remember). I now saw announces from august, that some BETA1 images of 9.0 where "released" and wanted to use those: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026181.html http://www.freebsdnews.net/2011/08/01/freebsd-9-beta1-testing/ But sadly they seem to be gone from the FTP servers. The system has beside its harddisks only a floppy drive (no space for a CD-ROM) so I would need the memstick image Any idea where I could get FreeBSD-9.0-BETA1-amd64-memstick.img from? I'd like to do the upgrade this weekend as the system runs actually a degraded gmirror (2 already broken drives and no spare drive left...) and who knows when the last remaining drive fails as well... Greetings, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compiling BETA2 with clang fails
On 09/06/11 00:14, Olivier Smedts wrote: 2011/9/6 Olivier Smedts: 2011/9/6 Volodymyr Kostyrko: 05.09.2011 10:43, Olivier Smedts wrote: ===>libexec/atrun (all) clang -O2 -pipe -march=native -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c Try removing "-march=native" from your CFLAGS. I have the exact same problem since months on my Core i7 CPU when using "-march=native" or "-march=corei7". No problems for me with "-march=core2" though. It so nice you have noted that. I'll be much happier if you also spare some time reading my previous emails. Or you could search this mailing list for the exact same problem reported some time ago. Sorry for double-post. My point was : this does not seem to be a buildworld problem, but rather a clang problem with coreiX's latest instructions. Should be reported upstream IMO. On my Dell Latitude E6510 notebook, equipted with one of the former Core-i5 "Lynnfield" CPUs, I got into a even worse situation. I can build the whole system with -march=native (buildworld), install it and at least run it. But then in multiuser mode, hitting the tab key, always ends up in a forced logout (it is with every shell, but only in multiuser mode, noct when starting the box in single user mode). Well, so far. Thought it was a fair chance, tried to revert what I've done and start compiling the OS again with either -march=core2 ore simply omit this. No chance! Shortly after start building world, I receive a weird error that cc1 failed compiling something, I need to make a report. When switching back to the legacy gcc 4.2, the same error occurs. The system isn't usable anymore. The OS is instable, hitting TAB key always ends up "logged out". I guess the only way to revert this is to install the box from scratch. I tried installing a base system from an installation DVD, it works so far. Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
