Re: shmget (No space left on device) issue with firefox
All 3 mozilla-based ports that I have installed (Firefox, Seamonkey, Thunderbird) crash immediately. * Does anyone else on 11 have this problem or is it just me? * I had been merging the linux-c6 ports into my tree for some time (now part of the official tree) - could this have any relation to the problem (due to flash-player)? This does not explain Thunderbird however. Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/shmget-No-space-left-on-device-issue-with-firefox-tp5938162p5951793.html Sent from the freebsd-current mailing list archive at Nabble.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: Panic - uma_zfree_arg - zone argument is NULL
On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote: H #7 0x80b07863 in uma_zfree_arg (zone=0x0, item=0xf800114ee000, H udata=0x81484760) udata here is uma_slab_t. Can you look at it? btw, is that reproducible on stable/10 or head? -- Totus tuus, Glebius. ___ 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: [PATCHES] Convert various pc98 drivers from timeout() to callout()
In article 2960329.sjarrui...@ralph.baldwin.cx John Baldwin j...@freebsd.org writes: I have three patches to convert various pc98 drivers from timeout() to callout(). For the fdc driver I took a more drastic approach and have attempted to port the PC98 support into the main fdc driver: Great! Unfortunately, I don't have enough time to review and test your patches so please feel free to commit them. When I have time, I'll check. Thanks for your work. --- TAKAHASHI Yoshihiro n...@freebsd.org ___ 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
AHCI after 271145 does not work for me
Hi, on my Acer Aspire V5, AHCI does not complete device_attach after 271145. Am I the only one experiencing this? Can I help fixing it? Thank you. BR, -- José Pérez Arauzo ___ 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: AHCI after 271145 does not work for me
Hi! 271146 was Warner's AHCI probe/attach changes. Maybe he'll have some ideas. :) Warner? -a On 25 September 2014 08:48, José Pérez Arauzo f...@aoek.com wrote: Hi, on my Acer Aspire V5, AHCI does not complete device_attach after 271145. Am I the only one experiencing this? Can I help fixing it? Thank you. BR, -- José Pérez Arauzo ___ 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-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: AHCI after 271145 does not work for me
On Thu, Sep 25, 2014 at 05:48:13PM +0200, José Pérez Arauzo wrote: Hi, on my Acer Aspire V5, AHCI does not complete device_attach after 271145. Am I the only one experiencing this? Can I help fixing it? Thank you. ... Well, I am not experiencing such a problem on my Dell M4400; you can see nearly a year's worth of (mostly daily) uname -vp entries for head at http://www.catwhisker.org/~david/FreeBSD/history/laptop_i386_11.txt. Today's uname -a is: FreeBSD g1-235.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1378 r272099M/272101:1100036: Thu Sep 25 06:30:23 PDT 2014 r...@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 As for 271145, I bracketed that one in early September: FreeBSD 11.0-CURRENT #1360 r271089M/271091:1100030: Thu Sep 4 06:31:23 PDT 2014 r...@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1361 r271156M/271156:1100030: Fri Sep 5 07:47:32 PDT 2014 root@localhost:/common/S4/obj/usr/src/sys/CANARY i386 (Second one was recorded while I was on the train during my commute to work.) As for debugging, a start will be to collect the AHCI controller information for pciconf -lv, as well as dmesg information -- e.g.: ahci0@pci0:0:31:2: class=0x010601 card=0x02501028 chip=0x29298086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'ICH9M/M-E SATA AHCI Controller' class = mass storage subclass = SATA ahci0: Intel ICH9M AHCI SATA controller port 0x6e70-0x6e77,0x6e78-0x6e7b,0x6e80-0x6e87,0x6e88-0x6e8b,0x6ea0-0x6ebf mem 0xfed1c800-0xfed1cfff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich1: AHCI channel at channel 1 on ahci0 ahcich4: AHCI channel at channel 4 on ahci0 ahcich5: AHCI channel at channel 5 on ahci0 ahciem0: AHCI enclosure management bridge on ahci0 But you'll undoubtedly get better information from folks who are more familiar with the hardware and the code than I am. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpQSeywjo1Zd.pgp Description: PGP signature
Re: installworld broken - osreldate.h: permission denied
Bezüglich Ian Lepore's Nachricht vom 28.09.2013 19:19 (localtime):
On Sat, 2013-09-28 at 15:09 +0200, Joel Dahl wrote:
Hi,
Fresh HEAD. installworld from read-only /usr/obj and /usr/src:
/usr/src/include/iconv.h osreldate.h /usr/include
install: osreldate.h: Permission denied
*** Error code 71
Stop.
make[4]: stopped in /usr/src/include
*** Error code 1
Everything was working fine 2 weeks ago, so it's a recent breakage.
Okay, I just accidentally created conditions for this error on my
system... I checked in a change to newvers.sh while a buildworld was
running, which led to a situation where newvers.sh was newer than
osreldate.h at the end of the buildworld. Then an installworld tried to
regenerate osreldate.h due to its dependency on newvers.sh, which would
fail if the obj was readonly at that point.
I think we could see if something similar applies for you if you use
this command:
make -dm installworld SUBDIR_OVERRIDE=include
And we'd be looking for the end of the output to be something like:
Examining _libiconv_compat.h...
modified 10:51:18 Sep 28, 2013...up-to-date
Make_Update: _libiconv_compat.h
inspect parent buildincludes: flags 0, type 18001, made 0, unmade 95 - not
needed
inspect parent _INCSINS: flags 9, type b01, made 1, unmade 1 - unmade
children
Examining osreldate.h...
modified 10:39:21 Sep 28, 2013...modified before source
/local/build/staging/freebsd/head/src/include/../sys/conf/newvers.sh...out-of-date
env ECHO=echo
MAKE=/local/build/staging/freebsd/head/obj/local/build/staging/freebsd/head/src/make.i386/bmake
NEWVERS_SH=/local/build/staging/freebsd/head/src/include/../sys/conf/newvers.sh
PARAM_H=/local/build/staging/freebsd/head/src/include/../sys/sys/param.h
SYSDIR=/local/build/staging/freebsd/head/src/include/../sys sh
/local/build/staging/freebsd/head/src/include/mk-osreldate.sh
env: not found
*** [osreldate.h] Error code 127
The env: not found is what I got instead of a permission denied, and
probably has something to do with me cross-building amd64 10.0 from an
i386 8.x machine. I think that's where you'd see the permission error.
If the same sort of thing is happening for you, then all that's left is
to figure out why osreldate.h is out of date at install time, and how to
handle things if that's the case.
Thanks for your suggestion how to best find out what's going on.
I have the same problem you observed (env: not found), not the
permission problem the thread opener had.
For any reason, not relevant at this point, my
${src}/sys/conf/newvers.sh is newer than 'include/osreldate.h' under
$OBJDIRPREFIX/i386.i386/….
Now in 'include/Makefile', sh ${MK_OSRELDATE_SH} should be called by
'env' in target 'osreldate.h vers.c:'.
Problem is, that PATH has sevaral bin-sbin directories under
$OBJDIRPREFIX/…/tmp/ _and_ $INSTALLTMP, and none of them provides 'env'.
The latter is filled with target 'distributeworld installworld:' in
Makefile.inc1, with $ITOOLS.
The following additional tools are missing in ITOOLS
to make recreating osreldate.h work at installworld stage:
env, hostname, mktemp and touch
So a patch to work arround that issue looks like this:
--- src/Makefile.inc1.orig 2014-09-25 17:36:16.0 +0200
+++ src/Makefile.inc1 2014-09-25 17:47:14.0 +0200
@@ -697,9 +697,9 @@
.endif
ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
- date echo egrep find grep id install ${_install-info} \
- ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ date echo egrep env find grep hostname id install ${_install-info} \
+ ln lockf make mkdir mktemp mtree ${_nmtree_itools} mv pwd_mkdb \
+ rm sed sh sysctl test touch true uname wc ${_zoneinfo}
#
# distributeworld
I have no idea if there's a better way, but if these tools are not to be
added, the check for outdated osreldate.h should be disabled because
recreation at install stage is not possible without. At least this is
true for compiling 9.3-i386 on 10-stable-amd64.
-Harry
signature.asc
Description: OpenPGP digital signature
Re: [PATCHES] Convert various pc98 drivers from timeout() to callout()
On Thursday, September 25, 2014 11:15:51 am TAKAHASHI Yoshihiro wrote: In article 2960329.sjarrui...@ralph.baldwin.cx John Baldwin j...@freebsd.org writes: I have three patches to convert various pc98 drivers from timeout() to callout(). For the fdc driver I took a more drastic approach and have attempted to port the PC98 support into the main fdc driver: Great! Unfortunately, I don't have enough time to review and test your patches so please feel free to commit them. When I have time, I'll check. Thanks for your work. Ok. I'm mostly nervous about the fdc(4) patch, but I will move forward. Thanks! -- 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: Poor state of the build infrastructure.
On Wednesday, September 24, 2014 7:33:46 pm Marcel Moolenaar wrote: On Sep 24, 2014, at 12:54 PM, John Baldwin j...@freebsd.org wrote: On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: What is going on here? Are we still in some kind of flux and people aren't done yet or is this the intended state by virtue of noone having anything left on there TODO list? Sorry to ask a dumb question, but are you sure you did the make buildworld first? Shouldn't that have errored if it couldn't build crt1? The root cause problem was that MAKEOBJDIRPREFIX was not set to whatever it was set to during buildworld. That was easy enough to figure out when a bunch of things don't add up. Ok. But neither problem mentioned in the email had anything to do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE as part of an install is a bug. Entering a powerpc buildenv and having a compiler that builds for the host (or maybe just some default) is a regression. Agreed on COMPILER_TYPE, but I think the path thing has always been true in make buildenv because we don't build cross-tools for things like 'cp'. -- 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: Poor state of the build infrastructure.
On Thu, 2014-09-25 at 14:50 -0400, John Baldwin wrote: On Wednesday, September 24, 2014 7:33:46 pm Marcel Moolenaar wrote: On Sep 24, 2014, at 12:54 PM, John Baldwin j...@freebsd.org wrote: On Tuesday, September 23, 2014 09:29:48 AM Marcel Moolenaar wrote: What is going on here? Are we still in some kind of flux and people aren't done yet or is this the intended state by virtue of noone having anything left on there TODO list? Sorry to ask a dumb question, but are you sure you did the make buildworld first? Shouldn't that have errored if it couldn't build crt1? The root cause problem was that MAKEOBJDIRPREFIX was not set to whatever it was set to during buildworld. That was easy enough to figure out when a bunch of things don't add up. Ok. But neither problem mentioned in the email had anything to do with MAKEOBJDIRPREFIX. Having to set the COMPILER_TYPE as part of an install is a bug. Entering a powerpc buildenv and having a compiler that builds for the host (or maybe just some default) is a regression. Agreed on COMPILER_TYPE, but I think the path thing has always been true in make buildenv because we don't build cross-tools for things like 'cp'. Just to be clear, all the problems in the original mail, including failure to detect COMPILER_TYPE automatically and building the wrong type of binaries, were fallout from the original problem of not setting MAKEOBJDIRPREFIX correctly. It turns out if you use the build system correctly, it works! (Unfortunately, using it correctly requires knowing about a whole lotta knobs to be set these days if your needs are not vanilla.) -- Ian ___ 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: AHCI after 271145 does not work for me
On Thu, 25 Sep 2014 09:26:56 -0700, David Wolfskill wrote On Thu, Sep 25, 2014 at 05:48:13PM +0200, José Pérez Arauzo wrote: Hi, on my Acer Aspire V5, AHCI does not complete device_attach after 271145. Am I the only one experiencing this? Can I help fixing it? Thank you. [...] As for debugging, a start will be to collect the AHCI controller information for pciconf -lv, as well as dmesg information -- e.g.: Thank you David, here are pciconf and dmesg: ahci0@pci0:0:17:0: class=0x01018f card=0x080d1025 chip=0x78001022 rev=0x40 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson SATA Controller [IDE mode]' class = mass storage subclass = ATA dmesg | fgrep -i ahci ahci0: AMD Hudson-2 AHCI SATA controller port 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS ahcich0: AHCI channel at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ahci0: AMD Hudson-2 AHCI SATA controller port 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS ahcich0: AHCI channel at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ahci0: AMD Hudson-2 AHCI SATA controller port 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS ahcich0: AHCI channel at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 For the sake of completeness: there's a BIOS option to either set the hw to present itself as legacy ISA or AHCI, but the kernel hangs in any case. BR, -- José Pérez Arauzo ___ 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: IXP700 AHCI fails to initialize
On Mon, Mar 3, 2014 at 2:22 PM, Roger Pau Monné roger@citrix.com wrote: On 01/03/14 19:00, Yuriy Taraday wrote: Hello. I currently have FreeBSD 8.3 on my home server and it works fine but it's time to upgrade at last (new ath and new ipfw especially allure me). I've decided to go straight to 10.0 and reinstall system from scratch to purge all legacy unrelated configs and other stuff. The problem I faced is as follows. I have a (rather old) motherboard with integrated SATA controller that presents in the OS as IXP700. In 8.3 it works fine. I have 2 disks attached to it: one with all my data and another one destined to be new system disk. I also have one IDE disk installed that is currently used as system disk. When I booted from USB stick with 10.0, I couldn't see any SATA disks in the system. I dug into dmesg and found this: http://pastebin.com/wv2A0MUE As it seems AHCI controller or disks are not responding to commands and timeouts eventually. A friend suggested to try CURRENT image. I went with FreeBSD-11.0-CURRENT-amd64-VT-20140222-r262336-mini-memstick.img and got almost the same error: http://pastebin.com/0iGaSWUD The error repeats and never stops (looks like CURRENT images have different config) but it is essentially the same. I've googled the problem but found only notes about how IXP700 is really bad and pointers that cabling might be the problem. But I have absolutely no problems with 8.3, so it looks like some regression during further development (shift to CAM, maybe?). Please help me to identify and fix the problem. This is just a shot in the dark, I'm not familiar with the AHCI driver, but since you seem to be loosing interrupts (or I would say so based on the timeout messages), you could try to disable MSI/MSI-X and fallback to PCI intline IRQs. Could you try to boot with hw.pci.enable_msix=0,hw.pci.enable_msi=0? A flood of RC news in my feed forced me to get back to upgrading my homeserver. I've tried out 10.1-BETA2 image and got the same results. Then I've tried to provide these options you suggested, and although there were some hickup (HDDs didn't respond well at first, I guess), I got to bsdinstall prompt. Thank you very much for suggestion! Now I wonder what would be the impact of having these options disabled permanently. Will there be a huge slowdown of all PCI cards? Or should it be negligible? -- Kind regards, Yuriy. ___ 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: Cam panic on r271170
On 9/17/2014 10:39 AM, Bryan Drewery wrote: On 9/16/2014 9:28 PM, Bryan Drewery wrote: I've been getting this quite frequently on head recently. I have dumps if anyone is interested in more information. Fatal trap 9: general protection fault while in kernel mode cpuid = 10; Memory modified after free 0xf8003e0b0800(2040) val= @ 0xf8003e0b0808 apanic: Most recently used by CAM CCB cpuid = 6 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe124735b4c0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe124735b570 vpanic() at vpanic+0x189/frame 0xfe124735b5f0 panic() at panic+0x43/frame 0xfe124735b650 mtrash_ctor() at mtrash_ctor+0x8a/frame 0xfe124735b680 uma_zalloc_arg() at uma_zalloc_arg+0x4f1/frame 0xfe124735b6f0 malloc() at malloc+0x192/frame 0xfe124735b740 xpt_run_allocq() at xpt_run_allocq+0xb5/frame 0xfe124735b780 adastrategy() at adastrategy+0x117/frame 0xfe124735b7b0 g_io_request() at g_io_request+0x3b7/frame 0xfe124735b810 g_part_start() at g_part_start+0x2b7/frame 0xfe124735b890 g_io_request() at g_io_request+0x3b7/frame 0xfe124735b8f0 g_io_request() at g_io_request+0x3b7/frame 0xfe124735b950 vdev_geom_io_start() at vdev_geom_io_start+0x137/frame 0xfe124735b970 zio_vdev_io_start() at zio_vdev_io_start+0x49f/frame 0xfe124735b9d0 zio_execute() at zio_execute+0x204/frame 0xfe124735ba30 vdev_queue_io_done() at vdev_queue_io_done+0x180/frame 0xfe124735ba80 zio_vdev_io_done() at zio_vdev_io_done+0x11d/frame 0xfe124735bac0 zio_execute() at zio_execute+0x204/frame 0xfe124735bb20 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfe124735bb80 taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xfe124735bbb0 fork_exit() at fork_exit+0x84/frame 0xfe124735bbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe124735bbf0 --- trap 0, rip = 0, rsp = 0xfe124735bcb0, rbp = 0 --- KDB: enter: panic [ thread pid 0 tid 100571 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why Not sure about this one. We've been getting it at work as well based on a stable/10ish tree. I also had this one recently: #8 0x80d1a162 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #9 0x802e52c4 in xpt_path_periph (path=0xdeadc0dedeadc0de) at /usr/src/sys/cam/cam_xpt.c:3738 #10 0x802dfe62 in cam_periph_error (ccb=0xf8003e0b6000, camflags=CAM_FLAG_NONE, sense_flags=0, save_ccb=0x0) at /usr/src/sys/cam/cam_periph.c:1602 #11 0x803057e4 in adadone (periph=0xf8003e09b700, done_ccb=0xf8003e0b6000) at /usr/src/sys/cam/ata/ata_da.c:1877 #12 0x802e6e44 in xpt_done_process (ccb_h=0xf8003e0b6000) at /usr/src/sys/cam/cam_xpt.c:5245 #13 0x80394d59 in ahci_ch_intr_direct (arg=value optimized out) at /usr/src/sys/dev/ahci/ahci.c:1132 #14 0x80390ff1 in ahci_intr (data=value optimized out) at /usr/src/sys/dev/ahci/ahci.c:417 #15 0x808ea5d3 in intr_event_execute_handlers (p=value optimized out, ie=0xf8000f725d00) at /usr/src/sys/kern/kern_intr.c:1252 #16 0x808eafb6 in ithread_loop (arg=0xf8000f6dea60) at /usr/src/sys/kern/kern_intr.c:1265 #17 0x808e7fc4 in fork_exit (callout=0x808eaf10 ithread_loop, arg=0xf8000f6dea60, frame=0xfe1245083c00) at /usr/src/sys/kern/kern_fork.c:977 #18 0x80d1a69e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 This one however (and all subsequent traces I posted) was resolved by r271201. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: AHCI after 271145 does not work for me
I’m afraid I have no clue. I’ll need hardware to debug this, since I don’t have any, or someone that can provide some feedback or even probe messages with it going off the rails (before/after). Warner On Sep 25, 2014, at 9:12 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! 271146 was Warner's AHCI probe/attach changes. Maybe he'll have some ideas. :) Warner? -a On 25 September 2014 08:48, José Pérez Arauzo f...@aoek.com wrote: Hi, on my Acer Aspire V5, AHCI does not complete device_attach after 271145. Am I the only one experiencing this? Can I help fixing it? Thank you. BR, -- José Pérez Arauzo ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: AHCI after 271145 does not work for me
Also r271201 fixes an issue with interrupts. Have you tried anything newer? Warner On Sep 25, 2014, at 9:12 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! 271146 was Warner's AHCI probe/attach changes. Maybe he'll have some ideas. :) Warner? -a On 25 September 2014 08:48, José Pérez Arauzo f...@aoek.com wrote: Hi, on my Acer Aspire V5, AHCI does not complete device_attach after 271145. Am I the only one experiencing this? Can I help fixing it? Thank you. BR, -- José Pérez Arauzo ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: AHCI after 271145 does not work for me
On Sep 25, 2014, at 1:59 PM, José Pérez Arauzo f...@aoek.com wrote: On Thu, 25 Sep 2014 09:26:56 -0700, David Wolfskill wrote On Thu, Sep 25, 2014 at 05:48:13PM +0200, José Pérez Arauzo wrote: Hi, on my Acer Aspire V5, AHCI does not complete device_attach after 271145. Am I the only one experiencing this? Can I help fixing it? Thank you. [...] As for debugging, a start will be to collect the AHCI controller information for pciconf -lv, as well as dmesg information -- e.g.: Thank you David, here are pciconf and dmesg: ahci0@pci0:0:17:0: class=0x01018f card=0x080d1025 chip=0x78001022 rev=0x40 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Hudson SATA Controller [IDE mode]' class = mass storage subclass = ATA dmesg | fgrep -i ahci ahci0: AMD Hudson-2 AHCI SATA controller port 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS ahcich0: AHCI channel at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ahci0: AMD Hudson-2 AHCI SATA controller port 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS ahcich0: AHCI channel at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ahci0: AMD Hudson-2 AHCI SATA controller port 0x2118-0x211f,0x2124-0x2127,0x2110-0x2117,0x2120-0x2123,0x2100-0x210f mem 0xf094f000-0xf094f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.30 with 1 6Gbps ports, Port Multiplier supported with FBS ahcich0: AHCI channel at channel 0 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 For the sake of completeness: there's a BIOS option to either set the hw to present itself as legacy ISA or AHCI, but the kernel hangs in any case. Do you have before messages too? Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Boot failure with r272146
With r272146 my SATA controller fails to attach, preventing the kernel from mounting root. I've attached a log of as much as dconschat would allow. The relevant portion is pcib10: atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 pcib10: allocated memory range (0xfa40-0xfa400fff) for rid 10 of pci1:3:14:0 atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 ata0: Shasta Kauai ATA Controller mem 0xfa404000-0xfa407fff at device 13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384 ata0: unable to allocate interrupt device_attach: ata0 attach returned 6 It works fine with r271697 kernel (latest I have booting). I haven't yet tried bisecting. Hardware is a PowerMac G5 (last generation). - Justin kernel_boot.fail Description: Binary data ___ 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: Panic - uma_zfree_arg - zone argument is NULL
On 09/25/14 11:19, Gleb Smirnoff wrote:
On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H #7 0x80b07863 in uma_zfree_arg (zone=0x0, item=0xf800114ee000,
H udata=0x81484760)
udata here is uma_slab_t. Can you look at it?
btw, is that reproducible on stable/10 or head?
Yes, it is reproducible. I have not tried stable/10 or head yet.
(kgdb) print *(uma_slab_t)udata
$3 = {
us_keg = 0xf8085696d680,
us_type = {
_us_link = {
le_next = 0xf80856970a80,
le_prev = 0x3
},
_us_size = 18446735313429006976
},
us_hlink = {
sle_next = 0x0
},
us_data = 0x81484778 ,
us_free = {
__bits = {0, 0, -2125969520, 0}
},
us_freecount = 0,
us_flags = 0 '\0',
us_pad = 0 '\0'
}
--HPS
___
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
