Re: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT
On Sun, Mar 29, 2015 at 2:27 AM, Wolfgang Zenker wolfg...@lyxys.ka.sub.org wrote: Hi, * bsdml pietro.bs...@gmail.com [150329 01:34]: since I tried to install FreeBSD 10.1 on my recently purchased T40 I got stuck at this annoying bootloop that says ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM status: Command timeout. I have also tried latest 11-CURRENT snapshot and it did not make any difference at all, it is affected from the same exact bootloop. [..] It seems like there might be an issue with the CAM ATA stack that is clashing with the PATA controller on my T40. I had the same problem on an ancient T42p. In my case, disabling the second ata channel allowed me to boot. I added the following line to /boot/device.hints: hint.ata.1.disabled=1 This is an annoying side-effect of the brain-dead SATA-PATA converter in that generation of ThinkPads. The Intel ICH6 chipset is SATA, but, for reasons known ot IBM/Lenovo, the systems used PATA drives! So they has a SATA-PATA converter built in that screwed up a LOT of things, mostly compromising performance and generating assorted log entries. Looks like that also is broken in modern ATA support if a drive is not present. This was always my biggest complaint with this laptop (T42) which I used for several years until I retired and returned to so it could be excessed legally as it was government property (and, I didn't really want it, even if I could have kept it). Not an awful system, but this one issue was really annoying to me. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.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: Is a high witness refcount indicative of a missing unlock?
On 30/03/2015 05:59, Lars wrote: Hi, I am poking around for a cause for my repeating deadlock issues on my system based on r 279869. ddb show witness show the “vnode interlock†and the “zfs†locks both with reference counts over 200K. Obviously they are related, and there is a find running (all the filesystems on this machine are zfs ( minus the specialty ones like devfs). I don’t see any other withness entry with reference counts even in the ballpark of these two, so does this indicate that we have a vnode/zfs path were we don’t unlock? I am running 10.1-STABLE and have bad locking issues. Running a witness kernel I got a duplicate lock from nvidia and lock order reversals involving zfs. Any chance your issue is related to mine? What command can give me the witness lock counts? The debug data I have collected so far is at - http://shaneware.biz/freebsddebugdata/ The lock reversal output I had was (after uptime of about 12 mins) - Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Mar 24 00:24:25 leader kernel: Waiting (max 60 seconds) for system process `syncer' to stop... Mar 24 00:24:25 leader kernel: Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 done Mar 24 00:24:25 leader kernel: All buffers synced. Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xf800224555f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1229 Mar 24 00:24:25 leader kernel: 2nd 0xf800222d67c8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2268 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022df6e4c0 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022df6e570 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe022df6e600 Mar 24 00:24:25 leader kernel: __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfe022df6e740 Mar 24 00:24:25 leader kernel: vop_stdlock() at vop_stdlock+0x3c/frame 0xfe022df6e760 Mar 24 00:24:25 leader kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe022df6e790 Mar 24 00:24:25 leader kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfe022df6e800 Mar 24 00:24:25 leader kernel: vputx() at vputx+0x232/frame 0xfe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x301/frame 0xfe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffe6d8, rbp = 0x7fffe7d0 --- Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xf800222d6b78 zfs (zfs) @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1814 Mar 24 00:24:25 leader kernel: 2nd 0x818514a8 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:2872 Mar 24 00:24:25 leader kernel: KDB: stack backtrace: Mar 24 00:24:25 leader kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022df6e690 Mar 24 00:24:25 leader kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022df6e740 Mar 24 00:24:25 leader kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfe022df6e7d0 Mar 24 00:24:25 leader kernel: _sx_slock() at _sx_slock+0x76/frame 0xfe022df6e810 Mar 24 00:24:25 leader kernel: mountcheckdirs() at mountcheckdirs+0x47/frame 0xfe022df6e860 Mar 24 00:24:25 leader kernel: dounmount() at dounmount+0x36f/frame 0xfe022df6e8e0 Mar 24 00:24:25 leader kernel: vfs_unmountall() at vfs_unmountall+0x61/frame 0xfe022df6e910 Mar 24 00:24:25 leader kernel: kern_reboot() at kern_reboot+0x540/frame 0xfe022df6e980 Mar 24 00:24:25 leader kernel: sys_reboot() at sys_reboot+0x5a/frame 0xfe022df6e9a0 Mar 24 00:24:25 leader kernel: amd64_syscall() at amd64_syscall+0x25a/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022df6eab0 Mar 24 00:24:25 leader kernel: --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x40f1bc, rsp = 0x7fffe6d8, rbp = 0x7fffe7d0 --- Mar 24 00:24:25 leader kernel: lock order reversal: Mar 24 00:24:25 leader kernel: 1st 0xf8001ca8e240 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1229 Mar 24 00:24:25 leader kernel: 2nd 0xf8001ca8e5f0 devfs (devfs) @
Re: Libreboot X200 and FreeBSD
On 28 Mar 2015, at 17:42, Adrian Chadd adr...@freebsd.org wrote: Oh, in that case, someone should send me one so I can use it to verify that my frame-buffer bootloader hack will work correctly on it. Why don't you reflash your existing one? :) Sevan / Venture37 ___ 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: Libreboot X200 and FreeBSD
On 28 Mar 2015, at 15:57, Piotr Kubaj pku...@riseup.net wrote: It's a modified Thinkpad X200, so it uses the same chipset, i.e. GM45. Hi Piotr, Unfortunately its not possible to boot freebsd with the libreboot images due to libreboot not have a binary blob vga bios seabios payload. You should be able to run freebsd without issue using coreboot however (libreboot is a consumer of coreboot which produces images without any close components). I've managed to reflash a stock x60s with coreboot run net/free dragonflybsd on there. I don't believer the laptops are modified physically in anyway just have their bios reflashed, might be worth asking them if you can get a laptop with coreboot+vgabios+seabios. Alternatively, just get a thinkpad x200 diy. You may have to resort to using linux for the initial flash. If it goes wrong provided you made backup images before starting, you can recover without issue using a raspberry pi or a beaglebone black as your reprogrammer the flashrom utility. Dmesg of the x60s running coreboot is on the wiki freebsd-acpi@ Regards Sevan / Venture37 ___ 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: Libreboot X200 and FreeBSD
On 03/29/2015 15:01, Sevan / Venture37 wrote: On 28 Mar 2015, at 15:57, Piotr Kubaj pku...@riseup.net wrote: It's a modified Thinkpad X200, so it uses the same chipset, i.e. GM45. Hi Piotr, Unfortunately its not possible to boot freebsd with the libreboot images due to libreboot not have a binary blob vga bios seabios payload. You should be able to run freebsd without issue using coreboot however (libreboot is a consumer of coreboot which produces images without any close components). I've managed to reflash a stock x60s with coreboot run net/free dragonflybsd on there. I don't believer the laptops are modified physically in anyway just have their bios reflashed, might be worth asking them if you can get a laptop with coreboot+vgabios+seabios. Alternatively, just get a thinkpad x200 diy. You may have to resort to using linux for the initial flash. If it goes wrong provided you made backup images before starting, you can recover without issue using a raspberry pi or a beaglebone black as your reprogrammer the flashrom utility. Dmesg of the x60s running coreboot is on the wiki freebsd-acpi@ Regards Sevan / Venture37 So, based on this information, are you able and willing to rewrite necessary code to make it work with Libreboot? signature.asc Description: OpenPGP digital signature
Build failed in Jenkins: Build-UFS-image #1450
See https://jenkins.freebsd.org/job/Build-UFS-image/1450/ -- Started by upstream project Build_Image_and_Run_Tests_in_Bhyve_HEAD build number 949 originally caused by: Started by upstream project FreeBSD_HEAD build number 2606 originally caused by: Started by an SCM change Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace https://jenkins.freebsd.org/job/Build-UFS-image/ws/ git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository git config remote.origin.url https://github.com/freebsd/freebsd-ci # timeout=10 Fetching upstream changes from https://github.com/freebsd/freebsd-ci git --version # timeout=10 git -c core.askpass=true fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/heads/*:refs/remotes/origin/* ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://github.com/freebsd/freebsd-ci at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016) at hudson.scm.SCM.checkout(SCM.java:484) at hudson.model.AbstractProject.checkout(AbstractProject.java:1270) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531) at hudson.model.Run.execute(Run.java:1751) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: hudson.plugins.git.GitException: Command git -c core.askpass=true fetch --tags --progress https://github.com/freebsd/freebsd-ci +refs/heads/*:refs/remotes/origin/* returned status code 128: stdout: stderr: fatal: unable to access 'https://github.com/freebsd/freebsd-ci/': Unknown SSL protocol error in connection to github.com:443 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ..remote call to jenkins-10.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1360) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:753) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131) at com.sun.proxy.$Proxy57.execute(Unknown Source) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733) ... 11 more ERROR: Error fetching remote repo 'origin' ___ 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: T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT
Hi, * bsdml pietro.bs...@gmail.com [150329 01:34]: since I tried to install FreeBSD 10.1 on my recently purchased T40 I got stuck at this annoying bootloop that says ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM status: Command timeout. I have also tried latest 11-CURRENT snapshot and it did not make any difference at all, it is affected from the same exact bootloop. [..] It seems like there might be an issue with the CAM ATA stack that is clashing with the PATA controller on my T40. I had the same problem on an ancient T42p. In my case, disabling the second ata channel allowed me to boot. I added the following line to /boot/device.hints: hint.ata.1.disabled=1 Wolfgang ___ 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: umass, Verbatim STORE N GO drive, CAM status 0x50
I did not find where the product ID goes ...
is that everything I have to consider?
At the end of sys/dev/usb/usbdevs you'll find the product IDs.
I tried and failed to get Verbatim Store N Go working.
This included the following attempts
1) include the quirk UQ_MSC_NO_SYNC_CACHE
2) include the quirk UQ_MSC_NO_SYNC_CACHE and UQ_MSC_NO_TEST_UNIT_READY
3) I found
http://randominfo.pyret.net/index.php?controller=postaction=viewid_post=10
where some Verbatim Store N Go worked with quirks=0x2NO_6_BYTE
but there is no NO_6_BYTE quirk in dev/usb/quirk/usb_quirk.c
instead I found a NO_6_BYTE quirk in cam/scsi/scsi_da.c so I changed
scsi_da.c, as follows
--- ./cam/scsi/scsi_da.c.orig 2015-03-28 21:33:12.001813000 +0100
+++ ./cam/scsi/scsi_da.c2015-03-28 21:37:24.196604000 +0100
@@ -413,6 +413,14 @@
},
{
/*
+* Verbatim Verbatim STORE N GO
+* dwe...@htwsaar.de
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, Verbatim, *,
+ *}, /*quirks*/ DA_Q_NO_6_BYTE
+ },
+ {
+ /*
* Sigmatel USB Flash MP3 Player
* PR: kern/57046
*/
so in that case, the scsi_da.c quirk and the usb_quirk.c-quirks
were in place, resulting in failed to attach to device
4) I removed the usb_quirks from the picture, leaving only the
scsi_da.c quirk (NO_6_BYTE) in place, the result being the
output below
ugen2.2: Verbatim at usbus2
umass0: Verbatim STORE N GO, class 0/0, rev 2.10/1.00, addr 2 on usbus2
umass0: SCSI over Bulk-Only; quirks = 0x8100
umass0:4:0: Attached to scbus4
Trying to mount root from ufs:/dev/ada0p2 [rw]...
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00
(probe0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed
(probe0:umass-sim0:0:0:0): Error 5, Unretryable error
(da0:umass-sim0:0:0:0): got CAM status 0x50
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device
= = ==
anything I should try next?
Below the patches I tried, the version 4) being active,
version 3) commented out with a #if 0 ... #endif
Best wishes
Damian
= = ==
kernel patches of system FreeBSD 11.0-CURRENT #4 r280370M as of Sun Mar 29
12:06:02 CEST 2015
--- ./cam/scsi/scsi_da.c.orig 2015-03-28 21:33:12.001813000 +0100
+++ ./cam/scsi/scsi_da.c2015-03-28 21:37:24.196604000 +0100
@@ -413,6 +413,14 @@
},
{
/*
+* Verbatim Verbatim STORE N GO
+* dwe...@htwsaar.de
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, Verbatim, *,
+ *}, /*quirks*/ DA_Q_NO_6_BYTE
+ },
+ {
+ /*
* Sigmatel USB Flash MP3 Player
* PR: kern/57046
*/
--- ./dev/usb/quirk/usb_quirk.c.orig2015-03-28 16:15:07.980503000 +0100
+++ ./dev/usb/quirk/usb_quirk.c 2015-03-29 10:42:14.931664000 +0200
@@ -523,6 +523,9 @@
USB_QUIRK(FEIYA, DUMMY, 0x, 0x, UQ_MSC_NO_SYNC_CACHE,
UQ_MATCH_VENDOR_ONLY),
USB_QUIRK(REALTEK, DUMMY, 0x, 0x, UQ_MSC_NO_SYNC_CACHE,
UQ_MATCH_VENDOR_ONLY),
USB_QUIRK(INITIO, DUMMY, 0x, 0x, UQ_MSC_NO_SYNC_CACHE,
UQ_MATCH_VENDOR_ONLY),
+#if 0 /* didn't work, we try patching ./cam/scsi/scsi_da.c */
+ USB_QUIRK(VERBATIM, STORENGO, 0x, 0x, UQ_MSC_NO_SYNC_CACHE,
UQ_MSC_NO_TEST_UNIT_READY, UQ_MATCH_VENDOR_ONLY),
+#endif
};
#undef USB_QUIRK_VP
#undef USB_QUIRK
--- ./dev/usb/usbdevs.orig 2015-03-28 15:55:34.870376000 +0100
+++ ./dev/usb/usbdevs 2015-03-28 16:27:37.709561000 +0100
@@ -689,6 +689,7 @@
vendor DISPLAYLINK 0x17e9 DisplayLink
vendor LENOVO 0x17ef Lenovo
vendor WAVESENSE 0x17f4 WaveSense
+vendor VERBATIM0x18a5 Verbatim
vendor VAISALA 0x1843 Vaisala
vendor AMIT0x18c5 AMIT
vendor GOOGLE 0x18d1 Google
@@ -4467,6 +4468,9 @@
/* Vaisala products */
product VAISALA CABLE 0x0200 USB Interface cable
+/* Verbatim products */
+product VERBATIM STORENGO 0x0243 Verbatim Store N Go
+
/* Vertex products */
product VERTEX VW110L 0x0100 Vertex VW110L modem
___
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: Libreboot X200 and FreeBSD
So, the loader needs updating to have VGA framebuffer support. I have started that as an investigation but I don't have anything tidy enough to start pushing into -HEAD. But yes, as long as they expose the VGA framebuffer in some meaningful way (read: either they pre-initialise a dumb framebuffer, or they provide basic BIOS services for it) then it'll eventually happen. -adrian ___ 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
Is a high witness refcount indicative of a missing unlock?
Hi, I am poking around for a cause for my repeating deadlock issues on my system based on r 279869. ddb show witness show the “vnode interlock” and the “zfs” locks both with reference counts over 200K. Obviously they are related, and there is a find running (all the filesystems on this machine are zfs ( minus the specialty ones like devfs). I don’t see any other withness entry with reference counts even in the ballpark of these two, so does this indicate that we have a vnode/zfs path were we don’t unlock? Thanks, Lars ___ 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
