Re: New IPv6 settings in rc.conf
On Sunday 25 April 2010 02:55:16 Doug Barton wrote: > On 04/24/10 17:54, Bruce Cran wrote: > > # if_bridge doesn't have a link-local address by default, so add one > > ifconfig_bridge0_ipv6="fe80::2%bridge0 prefixlen 64" > > It's likely that you need to add inet6 before fe80 there: > ifconfig_bridge0_ipv6="inet6 fe80::2%bridge0 prefixlen 64" Thanks, adding 'inet6' before all the IPv6 addresses fixed the problem. -- 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
AK-san, PseudoCylon wrote: > Hello, > > Thank you for all the info. > This one shall work. > http://projects.nasreddine.com/projects/run/repository/revisions/mips_fix/show/dev/usb/wlan > Please update if_run.c and if_runvar.h (2 files). > > Just in case, after kldload, please issue > # sysctl hw.usb.run.debug=1 > Now it prints out very little messages, and no need to issue wlandebug. > > Thank you very much. However it still panics when I tried to use bridge. ... run0: flags=8843 metric 0 mtu 2290 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running wlan0: flags=8943 metric 0 mtu 1500 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid bsd channel 6 (2437 MHz 11g) bssid 00:22:cf:03:e0:30 country US authmode OPEN privacy OFF txpower 0 scanvalid 60 protmode CTS wme dtimperiod 1 -dfs bridge0: flags=8843 metric 0 mtu 1500 ether 06:ba:f8:33:07:6d id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: arge0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 20 member: wlan0 flags=143 ifmaxaddr 0 port 9 priority 128 path cost 370370 ... wlan0: Ethernet address: 00:22:cf:03:e0:30 run_vap_create: rvp_id=0 bmap=1 rvp_cnt=1 run_media_change: called run_init_locked: called run_stop: All Tx cleared run_newstate: INIT -> INIT run_newstate: INIT -> SCAN run_newstate: SCAN -> RUN run_enable_tsf_sync: rvp_id=0 ic_opmode=4 bridge0: Ethernet address: 06:ba:f8:33:07:6d panic: Trying sleep, but thread marked as sleeping prohibited KDB: enter: panic [ thread pid 11 tid 100031 ] Stopped at kdb_enter+0x50: lui at,0x8054 db> bt Tracing pid 11 tid 100031 td 0xc0c96720 db_trace_thread+30 (?,?,?,?) ra 800ac688 sp c7967558 sz 24 800ac56c+11c (0,?,,?) ra 800abd30 sp c7967570 sz 32 800ab99c+394 (?,?,?,?) ra 800abec0 sp c7967590 sz 168 db_command_loop+78 (?,?,?,?) ra 800ae4d8 sp c7967638 sz 24 800ae3d0+108 (?,?,?,?) ra 80208060 sp c7967650 sz 424 kdb_trap+108 (?,?,?,?) ra 80407380 sp c79677f8 sz 32 trap+d50 (?,?,?,?) ra 803ff090 sp c7967818 sz 168 MipsKernGenException+134 (0,a,806c8fe4,109) ra 802082e8 sp c79678c0 sz 200 kdb_enter+50 (?,?,?,?) ra 801d1a04 sp c7967988 sz 24 panic+f8 (?,4,80480eb8,120) ra 80212f10 sp c79679a0 sz 40 sleepq_add+120 (?,?,?,?) ra 8018f174 sp c79679c8 sz 56 _cv_wait+1f0 (?,?,?,?) ra 80147ba8 sp c7967a00 sz 64 usbd_do_request_flags+540 (?,?,?,?) ra c7e56358 sp c7967a40 sz 104 PC 0xc7e56358: not in kernel 0+c7e56358 (?,?,?,?) ra 0 sp c7967aa8 sz 0 pid 11 db> thanks, Ganbold > Thanks > AK > > >> Got another panic. Maybe it is >> something else. >> >> run_rx_frame: rx done >> run_rx_frame: rx done >> run_rx_frame: rx done >> run_rx_frame: rx done >> run_rx_frame: rx done >> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) >> [ thread pid 0 tid 100062 ] >> Stopped at run_drain_fifo+0xd8:lw v0,6444(a1) >> db> bt >> Tracing pid 0 tid 100062 td 0xc0f88be0 >> db_trace_thread+30 (?,?,?,?) ra 800ac688 sp c7e83970 sz 24 >> 800ac56c+11c (0,?,,?) ra 800abd30 sp c7e83988 sz 32 >> 800ab99c+394 (?,?,?,?) ra 800abec0 sp c7e839a8 sz 168 >> db_command_loop+78 (?,?,?,?) ra 800ae4d8 sp c7e83a50 sz 24 >> 800ae3d0+108 (?,?,?,?) ra 80208060 sp c7e83a68 sz 424 >> kdb_trap+108 (?,?,?,?) ra 80407624 sp c7e83c10 sz 32 >> trap+ff4 (?,?,?,?) ra 803ff090 sp c7e83c30 sz 168 >> MipsKernGenException+134 (1a3,0,0,21c) ra c7e5bd24 sp c7e83cd8 sz 200 >> PC 0xc7e5bd24: not in kernel >> 0+c7e5bd24 (?,?,?,?) ra 0 sp c7e83da0 sz 0 >> pid 0 >> db> >> >> Ganbold >> > > > > -- As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls. -- Matt Cartmill ___ 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"
usb/da vs sata geometry calculations (was Re: Switchover to CAM ATA?)
Hi all, Sorry to interrupt this thread with an off-topic question, but it seems vaguely related, and you folk seem to be the right ones to ask: I've recently done a drive upgrade in a 1U rack machine that only had space for the two active drives that were in it, and I couldn't afford the down-time that it would take to install from scratch. So I formatted and populated the first replacement drive in an external USB cradle, and when it was looking like a good replacement for the (gmirror'd) image that was running, I did the physical swap, and all was good, as expected. All except that that the identical drive that I inserted as the second element of the mirror would *not* accept a copy of the first disk's MBR block (with fdisk). It said that the calculated geometry was incompatible. Luckily for me (I think) the calculated geometry was a megabyte or so *larger* than the first drive, so I was still able to bsdlabel it to match, and slot it into the gmirror as planned. Was this the result of the umass/da driver having a different synthetic geometry calculation routine than the SATA driver? This was all on an 8-STABLE system about 400 days old, fwiw. Should I expect any on-going badness as a result of this difference in "geometry" between two identical drives? Cheers, -- Andrew ___ 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: [CFT]: ClangBSD is selfhosting, we need testers now
Roman Divacky schrieb am 2010-04-24:
> ping any progress on this? :)
sorry it took some time, but i've been rather busy. i was able to pinpoint the
exact function which is causing the problem:
it's snd_xbytes().
[snip]
> > > Great stuff to have narrowed it down so much. Next logical step
> > > would
> > > be
> > > to do the bisect on function-level scope.
> > > Copy one half of buffer.c to buffer-clang.c, the other half to
> > > buffer-gcc.c,
> > > adjust the Makefile to use buffer-{gcc,clang}.c instead of
> > > buffer.c
> > > and
> > > compile them accordingly. Redo your tests till we know the single
> > > function(s)
> > > where clang produces bad code.
[snip]
--
Alexander Best
___
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: Switchover to CAM ATA?
Jaakko Heinonen schrieb am 2010-04-23: > On 2010-04-23, Alexander Best wrote: > > has anybody thought about adding scsi support to burncd(8)? i've > > been using > > ATA CAM for quite a while now and really love it. however i miss > > burncd(8). > I have thought about it. The mail I posted in December didn't > generate > any interest. i'm sorry i didn't notice your mail back then. i'm very interested in using burncd on a pass(4) device and would like to test any patches you may have. another option would be to have a ata(4)->cam(4)->ata(4) emulation. layer (the opposite of the current ATA_CAM option). that way all ata binaries would continue to work. what /dev/ata* would be used for is to receive ata commands, convert them to cam commands and then send them to pass. i wrote a mail with the idea to freebsd-questions@, but also got no response [1]. [1]: http://www.mail-archive.com/freebsd-questi...@freebsd.org/msg229439.html > http://docs.freebsd.org/cgi/mid.cgi?20091214182645.GA2764 -- Alexander Best ___ 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"
sysinstall core dumps when using gsched
There seems to be something about the conftxt that geom produces when gsched is being used that libdisk doesn't like. sysinstall segfaults on startup when it's being used, with a NULL pointer being passed to strchr in open_disk.c:55 (Int_Open_Disk). -- 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: kern+world / ports make options
On Sat, 24.04.2010 at 16:42:37 +, Pegasus Mc Cleaft wrote:
> Hello Hackers & Current,
>
> I was wondering it if is possible, or if it can be done so a separate
> set
> of CC, CXX, etc can be specified for building the world and kernel
> independently of a ports build?
>
> Right now, I use the base GCC to compile the world and kernel, and
> GCC44
> for most of the other ports (when it complies cleanly). But I have to keep
> editing the /etc/make.conf file to switch between the two.
>
> It may already be implemented, but it would be nice if there was
> something defined while the kernel and/or world is being built to that a
> nested block of ifdefs can select which env variables to be set.
src.conf has already been mentioned, I don't use it myself but have the
following set in make.conf
.if ${.CURDIR:M*/usr/ports/*}
NOCLEANDEPENDS= true
WRKDIRPREFIX= /usr/obj
.include "/etc/ports.conf"
.endif
I guess you can figure it out from there ...
hth
Ulrich Spörlein
___
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: HEADS UP: SUJ Going in to head today
On Sat, 24 Apr 2010 16:57:59 -1000 (HST) Jeff Roberson wrote: > On Sun, 25 Apr 2010, Alex Keda wrote: > > > try in single user mode: > > > > tunefs -j enable / > > tunefs: Insuffient free space for the journal > > tunefs: soft updates journaling can not be enabled > > > > tunefs -j enable /dev/ad0s2a > > tunefs: Insuffient free space for the journal > > tunefs: soft updates journaling can not be enabled > > tunefs: /dev/ad0s2a: failed to write superblock > > There is a bug that prevents enabling journaling on a mounted filesystem. > So for now you can't enable it on /. I see that you have a large / volume > but in general I would also suggest people not enable suj on / anyway as > it's typically not very large. I only run it on my /usr and /home > filesystems. > > I will send a mail out when I figure out why tunefs can't enable suj on / > while it is mounted read-only. > Jeff - One thing which surprised me was that I couldn't reuse the existing .sujournal files on my disks. I did notice that there are now more flags set on them. Was that the reason? Or were you just being careful? -- Gary Jennejohn ___ 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"
State of tun(4) in -CURRENT? No buffer space available
Hello, I'm running r203753 (i386) for some time on my IPv6 router. This box uses net/sixxs-aiccu to establish an IPv6 tunnel to one of the SixXS POPs. Unfortunately, tun(4) interface exhibits strange behaviour: after some traffic burst (like opening a ncurses application via ssh) the interface stops delivering packets. I manually restart the sixxs-aiccu utility and then it usually works, sometimes for few packets only, sometimes for minutes or hours. When the link is mostly idle (e.g. overnight) it stays up. aiccu (when stopped with SIGQUIT) exhibits three threads, One of them is the tunnel watchdog thread (probably unreladed). The other one waits from the data encapsulated via IPv4: [Switching to thread 1 (Thread 28240ec0 (LWP 100074))]#0 0x2814c797 in recvfrom () from /lib/libc.so.7 (gdb) bt #0 0x2814c797 in recvfrom () from /lib/libc.so.7 #1 0x280a04d1 in recvfrom () from /lib/libthr.so.3 #2 0x0804fee3 in ayiya_writer (arg=0x2822c300) at ../common/ayiya.c:177 #3 0x2809e244 in pthread_getprio () from /lib/libthr.so.3 #4 0x in ?? () ayiya.c:177: n = recvfrom(ayiya_socket->socket, (char *)buf, sizeof (buf), 0, (struct sockaddr *)&ci, &cl); Third thread is waiting for packets from tun(4): [Switching to thread 2 (Thread 28241140 (LWP 100053))]#0 0x28194869 in read () from /lib/libc.so.7 (gdb) bt #0 0x28194869 in read () from /lib/libc.so.7 #1 0x280a0576 in read () from /lib/libthr.so.3 #2 0x0804a2fa in tun_reader (arg=0x8055944) at ../common/tun.c:185 #3 0x2809e244 in pthread_getprio () from /lib/libthr.so.3 #4 0x in ?? () tun.c:185: n = read(tun_fd, buf, sizeof(buf)); When the tunnel is "hung" ping6 packets to the other tunnel end do not go out and after a while: ping6: sendmsg: No buffer space available IPv4 connectivity to the tunnel provider is fine, (ping over IPv4 to the tunnel destination works fine), I didn't notice any intermittent connectivity failures that could cause this. Packets neither come in or come out (checked looking using some other IPv6 on the network as I don't control the other end of the tunnel). I know there has been updates to the tun(4) code since r203753, but a friend of mine doing the same on his box with kernel as of April 13th has the same problem. Any ideas what's wrong? --Marcin ___ 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: kern+world / ports make options
On Sunday 25 April 2010 11:17:40 Ulrich Spörlein wrote:
> On Sat, 24.04.2010 at 16:42:37 +, Pegasus Mc Cleaft wrote:
> > It may already be implemented, but it would be nice if there was
> > something defined while the kernel and/or world is being built to that a
> > nested block of ifdefs can select which env variables to be set.
>
> src.conf has already been mentioned, I don't use it myself but have the
> following set in make.conf
>
> .if ${.CURDIR:M*/usr/ports/*}
> NOCLEANDEPENDS= true
> WRKDIRPREFIX= /usr/obj
> .include "/etc/ports.conf"
> .endif
Hi Ulrich,
Thank you for that. This is pretty much what I was looking for as I can
use the .if block to add in only the pieces I want. The src.conf solution was
an option, but since both make.conf and src.conf are called, I ended up
basically undoing everything in src.conf that I did in make.conf; and that
didn't work so well as I kept breaking the build (couldn't find headers and
all sorts of thing). No doubt, it was the way that I did it.. Your solution is
cleaner and makes sense to me.
Thanks again,
Peg
___
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: Switchover to CAM ATA?
On Apr 25, 2010, at 4:23 AM, Alexander Best wrote: > Jaakko Heinonen schrieb am 2010-04-23: >> On 2010-04-23, Alexander Best wrote: >>> has anybody thought about adding scsi support to burncd(8)? i've >>> been using >>> ATA CAM for quite a while now and really love it. however i miss >>> burncd(8). > >> I have thought about it. The mail I posted in December didn't >> generate >> any interest. > > i'm sorry i didn't notice your mail back then. i'm very interested in using > burncd on a pass(4) device and would like to test any patches you may have. > > another option would be to have a ata(4)->cam(4)->ata(4) emulation. layer (the > opposite of the current ATA_CAM option). that way all ata binaries would > continue to work. what /dev/ata* would be used for is to receive ata > commands, convert them to cam commands and then send them to pass. i wrote a > mail with the idea to freebsd-questions@, but also got no response [1]. > Compatibility is a good thing, and I see nothing wrong with adding a simple ioctl module to the pass or cd driver that achieves this. The only thing that I'd worry about is that there might be semantics to the old ata ioctls that rely on quirky operations of the old ata driver. It's really going to be counter-productive to try too hard to emulate the old driver; the whole point of CAM_ATA is to move on from the sins of it. Also, other than burncd, what else exists to justify this emulation layer? If it's just burncd, have you considered writing a CAM-oriented replacement for it? Maybe something that is as versatile as cdrecord, but with an unencumbered BSD license so it can exist in the base system? Scott ___ 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: HEADS UP: SUJ Going in to head today
On Apr 24, 2010, at 8:57 PM, Jeff Roberson wrote: > On Sun, 25 Apr 2010, Alex Keda wrote: > >> try in single user mode: >> >> tunefs -j enable / >> tunefs: Insuffient free space for the journal >> tunefs: soft updates journaling can not be enabled >> >> tunefs -j enable /dev/ad0s2a >> tunefs: Insuffient free space for the journal >> tunefs: soft updates journaling can not be enabled >> tunefs: /dev/ad0s2a: failed to write superblock > > There is a bug that prevents enabling journaling on a mounted filesystem. So > for now you can't enable it on /. I see that you have a large / volume but > in general I would also suggest people not enable suj on / anyway as it's > typically not very large. I only run it on my /usr and /home filesystems. > > I will send a mail out when I figure out why tunefs can't enable suj on / > while it is mounted read-only. > This would preclude enabling journaling on / on an existing system, but I would think that you could enable it on / on a system that is being installed, since (at least in theory) the target / filesystem won't be the actual root of the system, and therefore can be unmounted at will. Scott ___ 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: HEADS UP: SUJ Going in to head today
On Sunday 25 April 2010 19:47:00 Scott Long wrote: > On Apr 24, 2010, at 8:57 PM, Jeff Roberson wrote: > > On Sun, 25 Apr 2010, Alex Keda wrote: > >> try in single user mode: > >> > >> tunefs -j enable / > >> tunefs: Insuffient free space for the journal > >> tunefs: soft updates journaling can not be enabled > >> > >> tunefs -j enable /dev/ad0s2a > >> tunefs: Insuffient free space for the journal > >> tunefs: soft updates journaling can not be enabled > >> tunefs: /dev/ad0s2a: failed to write superblock > > > > There is a bug that prevents enabling journaling on a mounted filesystem. > > So for now you can't enable it on /. I see that you have a large / > > volume but in general I would also suggest people not enable suj on / > > anyway as it's typically not very large. I only run it on my /usr and > > /home filesystems. > > > > I will send a mail out when I figure out why tunefs can't enable suj on / > > while it is mounted read-only. > > This would preclude enabling journaling on / on an existing system, but I > would think that you could enable it on / on a system that is being > installed, since (at least in theory) the target / filesystem won't be the > actual root of the system, and therefore can be unmounted at will. It worked here - it's shown as enabled after I booted in single-user mode and enabled it yesterday: core# dumpfs / | grep -i journal flags soft-updates+journal -- 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: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> I've been testing the driver for a few time with AMD64/CURRENT. A >> few time ago I started to see messages like : >> >> bwn0: unsupported rate 0 >> >> I've checked the code and I found it seems to fail when trying to >> check the TX rate at if_bw.c:9561 (in bwn_ieeerate2hwrate >> routine the rate parameter is 0). I checked where bwn_ieeerate2hwrate >> is called, to see how 'rate' is calculated. This is where I got lost :( >> >> My AP is FreeBSD 8.0 box with an atheros card. My hostapd works >> with both WPA2-PSK and WPA2-EAP (although >> I thinks this is not the problem) but with default values for rates >> and friends. I then forced my hostapd to use only a subset of transmit >> rates (with supported_rates and basic_rates) with no luck. >> >> My laptop is a DELL D630 with a BCM4310 UART adapter. >> >> Any need info will be provided and any help will be appreciated. > > First I think we need to know that where rate == 0 comes from. Rate > information on TX could be got from the following points: > > tp->mgmtrate > tp->mcastrate > tp->ucastrate > ni->ni_txrate > Added some device_printf to test those values. This is what I got : bwn0: tp->mgmtrate : 2 bwn0: tp->mcastrate : 2 bwn0: tp->ucastrate : 255 bwn0: ni->ni_txrate : 0 I didn't have time to follow the code to find out why it has a 0 value. If you need more info let me know. Regards, Gus - -- PGP KEY : http://www-entel.upc.edu/gus/gus.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL1KknAAoJEH+VVM1WSYnPAPUQAJrpVOOJ4KzUAe6GQHwFnM15 bUiuUeL+5b7sujjLY9j/zuCHQxPDak+/F7eG5AeaJ1bQFkuexG1oDJDLx3oTR06x xhSOKUPZuabrqVeX9xT2d9h8PHa8soEG1GtOPgKzLLfbP8emaimwEnNTlp9G+typ IFxI/LOGzSkpXsqupsXzHTjNiHOxjkijj7e2tEvU8qHh133JebrxBX0jpqSBrZKg +TAC6QnKxh+Mygumsc/5nVQiOPFJEQEEXXdSLXZbr2SqczDeDw98MXxiR4M7TnF/ 20j5fQQE65r6YoPx4X5h2IvaBz2f9aeXlP/t3XIepwuVl3cjL+7B9/CRkV5+T4B1 C5u1Je3tZU0c6fcXOAVOVo7A2c6d+tHXP014CKONPrsTUR2HmLHYNuCQZ+d9LBKx luMcPlqTeRjo+L+VxsM+P+2feegJ7/eV6gweYt3bWsbYzMwfPvjpX2HqgqDtx3DO IT/V8mO76GyCZ21MOdfDQC/1UTHztJVUEGTIXw1HO3aAn3LOsKMPegvF0ZdFyU+5 xv8xkgtbrIBxSA6TzsAu6E+JhksJw9KeEQ4bcaKND7EttnGGelawBB+FeRQiNDYt 6hlSdaX/hHn76tGGx0eJZ/qpdESo8WJvOgaQrt41s1RlfCFnMWmQxDeRY6Dj47LN aB2pONw41gG9OfrPcGi/ =f70p -END PGP SIGNATURE- ___ 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: HEADS UP: SUJ Going in to head today
Hi Jeff, thank you for your effort in implementing the soft update journaling. I tried to test SUJ on a provider with 4 kB block size. My system runs 9-CURRENT r207195 (i386). Unfortunately, tunefs is unable to cope with the device. It can easily reproduced with these steps: # mdconfig -s 128M -S 4096 0 # newfs -U /dev/md0 /dev/md0: 128.0MB (262144 sectors) block size 16384, fragment size 4096 using 4 cylinder groups of 32.02MB, 2049 blks, 2112 inodes. with soft updates # tunefs -j enable /dev/md0 Using inode 4 in cg 0 for 4194304 byte journal tunefs: Failed to read dir block: Invalid argument tunefs: soft updates journaling can not be enabled The bread() in tunefs.c:701 fails as the requested block size (512) is smaller than the provider's block size (4096 bytes). As a simply attempt to fix it, I changed tunefs.c:760 to "if (dir_extend(blk, nblk, size, ino) == -1)", as I thought that this made more sense. Then, tunefs succeeded, but mounting the file system resulted in a panic: panic: ufs_dirbad: /mnt/md-test: bad dir ino 2 at offset 512: mangled entry db:0:kdb.enter.default> bt Tracing pid 2714 tid 100262 td 0xc7ea6480 kdb_enter(c0a21226,c0a21226,c0a49886,eb1e6714,0,...) at kdb_enter+0x3a panic(c0a49886,c688f468,2,200,c0a498df,...) at panic+0x136 ufs_dirbad(c81bb000,200,c0a498df,0,eb1e67b0,...) at ufs_dirbad+0x46 ufs_lookup_ino(c81d5990,0,eb1e67d8,eb1e6800,0,...) at ufs_lookup_ino+0x367 softdep_journal_lookup(c688f288,eb1e68c4,c0a45eca,750,eb1e6834,...) at softdep_journal_lookup+0xb0 softdep_mount(c7e3fbb0,c688f288,c8165000,c7bdf900,c7bdf900,...) at softdep_mount+0xdb ffs_mount(c688f288,0,c0a2df89,3d6,0,...) at ffs_mount+0x23e1 vfs_donmount(c7ea6480,0,c7bc6100,c7bc6100,c8031000,...) at vfs_donmount+0x1000 nmount(c7ea6480,eb1e6cf8,c,c,207,...) at nmount+0x64 syscall(eb1e6d38) at syscall+0x1da Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280f205b, esp = 0xbfbfdcec, ebp = 0xbfbfe248 --- ... so this attempt did not succeed, but was worth a try ;-) But it would be nice to use SUJ even on such a unusual configuration. Lucius ___ 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: SVN rev 206755 breakage
On 04/19/10 02:30, Alexander Motin wrote:
> Rui Paulo wrote:
>> On 18 Apr 2010, at 14:05, Alexander Motin wrote:
>>> Most of AHCI controllers could also work as usual PCI ATA, but not every
>>> PCI ATA could work as AHCI. It would be nice to compare `pciconf -lvbc`
>>> output in both working (Rui) and not working (Michael) cases.
>>
>> ah...@pci0:0:31:2: class=0x01018f card=0x72708086 chip=0x27c48086 rev=0x02
>> hdr=0x00
>> vendor = 'Intel Corporation'
>> device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller'
>> class = mass storage
>> subclass = ATA
>
>^^^
> It doesn't report itself as AHCI.
>
>> bar [10] = type I/O Port, range 32, base 0x20d8, size 8, enabled
>> bar [14] = type I/O Port, range 32, base 0x20fc, size 4, enabled
>> bar [18] = type I/O Port, range 32, base 0x20d0, size 8, enabled
>> bar [1c] = type I/O Port, range 32, base 0x20f8, size 4, enabled
>> bar [20] = type I/O Port, range 32, base 0x2020, size 16, enabled
>> bar [24] = type Memory, range 32, base 0x90445000, size 1024, enabled
>
> This resource (BAR(5)) is absent on Michael's system. It is needed to
> work in AHCI mode, but not required for legacy PCI ATA. Probably some
> kind of BIOS magic in your case makes it appear in this mode with this
> chip ID.
More for my own amusement than anything, I came up with an _horrible_
patch to force my ICH7M into AHCI mode (attached). It has two issues:
1) I haven't figured out how to automagically determine which
address(es) I can use without colliding with anything else. Simply
letting bus_allocate_any() decide where to point BAR(5) doesn't appear
to work. I suspect I have to dig through the SMAP stuff to find out what
the BIOS has already claimed and use something outside of those ranges.
2) Since my laptop has both a SATA drive and a PATA DVD-R/W, the
manufacturer commissioned a BIOS which brings the ICH7M up in "combined
mode" with D31-F1 completely disabled. Since it can't (per Intel spec)
be re-enabled without a "platform reset", flipping into AHCI mode
effectively removes the DVD.
However - on the "up side", I now get NCQ ;-)
ahci0: port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18b0-0x18bf
at device 31.2 on pci0
ahci0: BAR(5): 0xf0d44400 AHCI_CAP: 0xdf12ff03 PI: 0x1
pcib0: matched entry for 0.31.INTB
pcib0: slot 31 INTB hardwired to IRQ 19
ahci0: [MPSAFE]
ahci0: [ITHREAD]
ahci0: AHCI v1.10 with 4 1.5Gbps ports, Port Multiplier supported
ahci0: Caps: 64bit NCQ MPS SS ALP AL CLO 1.5Gbps PM PMD SSC PSC
32cmd 4ports
ahci0: Caps2:
ahcich0: at channel 0 on ahci0
ahcich0: [MPSAFE]
ahcich0: [ITHREAD]
ahcich0: Caps:
[ .. ]
ada0 at ahcich0 bus 0 scbus1 target 0 lun 0
ada0: ATA-8 SATA 2.x device
ada0: Serial Number K82BT89256VDGEOM: new disk ada0
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)
*** sys/dev/ahci/ahci.c.origSat Apr 24 21:36:42 2010
--- sys/dev/ahci/ahci.c Sun Apr 25 21:30:57 2010
***
*** 126,131
--- 126,132
{0x26838086, 0x00, "Intel ESB2",0},
{0x27c18086, 0x00, "Intel ICH7",0},
{0x27c38086, 0x00, "Intel ICH7",0},
+ {0x27c48086, 0x00, "Intel ICH7M", 0},
{0x27c58086, 0x00, "Intel ICH7M", 0},
{0x27c68086, 0x00, "Intel ICH7M", 0},
{0x28218086, 0x00, "Intel ICH8",0},
***
*** 321,331
--- 322,353
ctlr->quirks = ahci_ids[i].quirks;
resource_int_value(device_get_name(dev),
device_get_unit(dev), "ccc", &ctlr->ccc);
+
+ #define AHCI_MEM_HACK 0xF0D44400 /* 0xf0d443ff is the last used by
others on Toshiba A105 */
+
+ /* Need to set the SCRAE bit and ensure SCRD not set */
+ pci_write_config(dev, 0x94, (pci_read_config(dev, 0x94, 4) | 0x200) &
~0x4000, 4);
+ /* enable MSE */
+ pci_write_config(dev, 0x4, (pci_read_config(dev, 0x4, 2) | 2), 2);
+ pci_write_config(dev, 0x24, AHCI_MEM_HACK, 4);
+ pci_write_config(dev, 0x90, 0x40, 1); /* AHCI + non-combined */
+
+ /* allocate a free memory window for BAR(5) */
+ ctlr->r_rid = PCIR_BAR(5);
+ bus_set_resource(dev, SYS_RES_MEMORY, ctlr->r_rid, AHCI_MEM_HACK,
0x400);
+
/* if we have a memory BAR(5) we are likely on an AHCI part */
ctlr->r_rid = PCIR_BAR(5);
if (!(ctlr->r_mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY,
&ctlr->r_rid, RF_ACTIVE)))
return ENXIO;
+
+ /* enable ICH7M ports in AHCI space */
+ ATA_OUTL(ctlr->r_mem, AHCI_PI, ATA_INL(ctlr->r_mem, AHCI_PI) | 5);
+ #if 0
+ device_printf(dev, "BAR(5): 0x%lx AHCI_CAP: 0x%lx PI: 0x%lx\n",
(unsigned long)pci_read_config(dev, 0x24, 4),
+ (unsigned long)ATA_INL(ctlr->r_mem, 0), (unsigned
long)ATA_INL(ctlr->r_mem, AHCI_PI));
+ #end
Re: Switchover to CAM ATA?
On 04/25/10 03:23, Alexander Best wrote: > another option would be to have a ata(4)->cam(4)->ata(4) emulation. What would be the value of doing all of that work as opposed to just using one of the available options that already work with cam such as cdrecord? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: New IPv6 settings in rc.conf
On 04/25/10 00:00, Bruce Cran wrote: > On Sunday 25 April 2010 02:55:16 Doug Barton wrote: >> On 04/24/10 17:54, Bruce Cran wrote: > >>> # if_bridge doesn't have a link-local address by default, so add one >>> ifconfig_bridge0_ipv6="fe80::2%bridge0 prefixlen 64" >> >> It's likely that you need to add inet6 before fe80 there: >> ifconfig_bridge0_ipv6="inet6 fe80::2%bridge0 prefixlen 64" > > Thanks, adding 'inet6' before all the IPv6 addresses fixed the problem. I'm glad to hear that, although now I have a sinking feeling about the state of the -current code. In your OP you said you "updated to -current," what version of FreeBSD did you upgrade from? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: Switchover to CAM ATA?
On Apr 25, 2010, at 7:58 PM, Doug Barton wrote: > On 04/25/10 03:23, Alexander Best wrote: >> another option would be to have a ata(4)->cam(4)->ata(4) emulation. > > What would be the value of doing all of that work as opposed to just > using one of the available options that already work with cam such as > cdrecord? > I think that there's a valid argument for having a cd recording program in the base system. cdrecord is an excellent program, but I don't believe that it's a good candidate to try to import into FreeBSD. Scoot ___ 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: Switchover to CAM ATA?
On 04/25/10 19:03, Scott Long wrote: > On Apr 25, 2010, at 7:58 PM, Doug Barton wrote: >> On 04/25/10 03:23, Alexander Best wrote: >>> another option would be to have a ata(4)->cam(4)->ata(4) >>> emulation. >> >> What would be the value of doing all of that work as opposed to >> just using one of the available options that already work with cam >> such as cdrecord? >> > > I think that there's a valid argument for having a cd recording > program in the base system. I'm not sure I agree with you, but that's orthogonal to the OP. :) > cdrecord is an excellent program, but I > don't believe that it's a good candidate to try to import into > FreeBSD. Agreed on that ... and I'm not opposed to your previous idea of rewriting burncd to work with the new world order. I'm just not sure that the multi-layer idea to make the old burncd work is a good idea. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: New IPv6 settings in rc.conf
On Monday 26 April 2010 03:01:39 Doug Barton wrote: > On 04/25/10 00:00, Bruce Cran wrote: > > On Sunday 25 April 2010 02:55:16 Doug Barton wrote: > >> On 04/24/10 17:54, Bruce Cran wrote: > >>> # if_bridge doesn't have a link-local address by default, so add one > >>> ifconfig_bridge0_ipv6="fe80::2%bridge0 prefixlen 64" > >> > >> It's likely that you need to add inet6 before fe80 there: > >> ifconfig_bridge0_ipv6="inet6 fe80::2%bridge0 prefixlen 64" > > > > Thanks, adding 'inet6' before all the IPv6 addresses fixed the problem. > > I'm glad to hear that, although now I have a sinking feeling about the > state of the -current code. In your OP you said you "updated to > -current," what version of FreeBSD did you upgrade from? It was an earlier version of -CURRENT from maybe a couple of months ago. -- 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"
