Re: Very imprecise watchdogd(8) timeout
In message , Arnaud Lacombe writes: >I do not really care actually, but the manpage is wrong, and the code >needlessly complicated. As I said: Feel free to improve. -- 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: Thinkpad CD-ROM hotplug with ATA_CAM
On Fri, 16 Sep 2011, Kevin Oberman wrote: I fear that BIOS may have some issue. I have a T43 and found that, if I booted with the DVD installed, atacontrol (this was prior to ATA-CAM) would allow me to detach, but if I then inserted a hard drive and tried to attach it, the system would lock up. If I booted with a hard drive in the bay, I could detach, change drives, and attach with no problems. I don't recall if I could replace the hard drive with a DVD, though and I don't have physical access to that system ATM. Still, this sounds rather similar to what I saw and it was unique to the T43. I have had several other ThinkPads, all of which allow me to swap out the DVD for a different drive including the T520 I am using to enter this reply. It's not entirely clear that this is relevant, but my T400 has very odd behavior with the CD drive either disappearing or taking a very long time to probe on warm boots. Linux (or grub? I don't remember.) also has some trouble finding the root device (hard disk) on warm boots, but FreeBSD does fine. -Ben Kaduk ___ 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"
Crashes in world built w/ clang: FP registers?
Hi everyone,
Using clang as the default compiler, the kernel and drivers will work
fine, but a lot of programs in the base system and ports will crash w/
SIGBUS. In fact, so much of the stuff in the chroot'ed world will
crash (everything from csh to gcc) that it's basically unusable. I
finally got around to building w/ debug symbols, and ran gdb on a
coredump generated while I was trying to use tab completion in csh:
(gdb) bt
#0 tw_collect (command=dwarf2_read_address: Corrupted DWARF expression.)
at /usr/src/bin/csh/../../contrib/tcsh/tw.parse.c:1308
#1 0x0042777b in t_search (word=Unhandled dwarf expression opcode 0x0)
at /usr/src/bin/csh/../../contrib/tcsh/tw.parse.c:1725
#2 0x00426829 in tenematch (inputline=Variable "inputline" is
not avail able.)
at /usr/src/bin/csh/../../contrib/tcsh/tw.parse.c:301
#3 0x0043545d in Inputl ()
at /usr/src/bin/csh/../../contrib/tcsh/ed.inputl.c:415
#4 0x00417a90 in readc (wanteof=Variable "wanteof" is not available.)
at /usr/src/bin/csh/../../contrib/tcsh/sh.lex.c:1653
#5 0x00416f37 in lex (hp=Variable "hp" is not available.)
at /usr/src/bin/csh/../../contrib/tcsh/sh.lex.c:162
#6 0x00405afb in process (catch=Unhandled dwarf expression opcode 0x0)
at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1922
#7 0x00404b51 in main (argc=Variable "argc" is not available.)
at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1289
gdb) disas
Dump of assembler code for function tw_collect:
0x004288b0 : push %rbp
0x004288b1 : mov%rsp,%rbp
0x004288b4 : push %r15
0x004288b6 : push %r14
0x004288b8 : push %r13
0x004288ba : push %r12
0x004288bc : push %rbx
0x004288bd : sub$0x2e8,%rsp
0x004288c4 : mov%r9,-0x308(%rbp)
0x004288cb : mov%r8,-0x300(%rbp)
0x004288d2 : mov%rcx,-0x2f8(%rbp)
0x004288d9 : mov%rdx,-0x2f0(%rbp)
0x004288e0 : mov%esi,-0x2e8(%rbp)
0x004288e6 : mov%edi,-0x2e4(%rbp)
0x004288ec : movl $0x0,-0x1d4(%rbp)
0x004288f6 : movaps 0x23115b(%rip),%xmm0
# 0x6 59a58
0x004288fd : lea-0x2(%rdi),%eax
0x00428900 : mov%eax,-0x2e0(%rbp)
0x00428906 : test %edi,%edi
0x00428908 : movaps %xmm0,-0x210(%rbp)
0x0042890f : sete %al
---Type to continue, or q to quit---q
Quit
(gdb) info line tw.parse.c:1308
Line 1308 of "/usr/src/bin/csh/../../contrib/tcsh/tw.parse.c"
starts at address 0x4288f6
and ends at 0x4288fd .
Looks like it's crashing as soon as it tries to use the XMM registers.
I'm not sure if all of the crashes I'm getting are like this one, but
I was surprised to see FP registers in code like this.
I'm using march=corei7 and -O2 for both world and kernel, but using
march=nocona or just leaving out CPUTYPE has no effect (actual CPU is
Nehalem Xeon 5520)
Here's the relevant part of make.conf for completeness:
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang -E
.endif
NO_WERROR=
WERROR=
NO_FSCHG=
CPUTYPE?=corei7
CFLAGS= -O2 -pipe
COPTFLAGS= -O2 -pipe
Any thoughts? Is there some simple fix for this I'm missing?
Thanks,
Jason
___
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: Queue drop not accounted ?
Hi, On Fri, Sep 16, 2011 at 3:40 PM, YongHyeon PYUN wrote: > On Thu, Sep 15, 2011 at 09:25:19PM -0400, Arnaud Lacombe wrote: >> Hi, >> >> Shouldn't packet freed in IFQ_ENQUEUE() because the queue is full be >> accounted as dropped, cf attached patch ? >> > > Hmm, I think err would be set to ENOBUFS for queue full case and > this err will crease ifq_drops. > oh, yeah, I missed the increment not using the accessors after the branch. A. >> Thanks, >> - Arnaud > ___ 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: Very imprecise watchdogd(8) timeout
Hi, On Fri, Sep 16, 2011 at 4:03 PM, Poul-Henning Kamp wrote: > In message > > , Arnaud Lacombe writes: > >>I just had a look to the way the timeout specified to watchdogd is >>passed to the kernel. watchdogd(8) says: > > The API was designed for simplicity, not precision. > > Watchdog hardware often have weird and strange limitations on the > actual values you can set. > yes. > A very typical, the most typical in my experience, is "some > frequency, a binary prescaler, possibly with a counter. > > It is also not uncommon to have more than one watchdog > mechanism in the same system. > in which case the current notifier-based architecture is broken. You may want to have a soft-watchdog triggering after 5s, and a fallback hardware watchdog triggering after 60s. > It would be overkill to design and implement a complex API to > communicate these limitations to userland. > Linux is going this way, at least for a min/max seconds timeount info, did not check the rest. > So the API was designed around the power-of-two scale to give it > a wide range, and with the semantics "no shorter than", to make > it easy to use, and for multiple watchdogs to be engaged to the > best of their ability. > wide range ? 50% of the possibility are unusable (every value below 29) and the rest is limited by what the device support anyway. Take the geodewdt, a max timeout of 2h26, so with the actual sparse range, you will only be able to set timeout to 1s, 2s, 4s, 8s, 17s, 34s, 68s, 274s, 549s, 1099s, 2199s, 4398s. That's 20% of the original range... > If this is not precise enough for you, come up with something > better. > I do not really care actually, but the manpage is wrong, and the code needlessly complicated. You can just rip all the double-to-int-log-of-nanosecond-timeout mambo-jumbo, and advertise in watchdogd(8) that only power of two timeout are supported, or have an option to directly specify the shift, that'll be simpler and correct. - Arnaud ___ 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: Very imprecise watchdogd(8) timeout
In message , Arnaud Lacombe writes: >I just had a look to the way the timeout specified to watchdogd is >passed to the kernel. watchdogd(8) says: The API was designed for simplicity, not precision. Watchdog hardware often have weird and strange limitations on the actual values you can set. A very typical, the most typical in my experience, is "some frequency, a binary prescaler, possibly with a counter. It is also not uncommon to have more than one watchdog mechanism in the same system. It would be overkill to design and implement a complex API to communicate these limitations to userland. So the API was designed around the power-of-two scale to give it a wide range, and with the semantics "no shorter than", to make it easy to use, and for multiple watchdogs to be engaged to the best of their ability. If this is not precise enough for you, come up with something better. -- 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"
Very imprecise watchdogd(8) timeout
Hi, I just had a look to the way the timeout specified to watchdogd is passed to the kernel. watchdogd(8) says: The -t timeout specifies the desired timeout period in seconds. The default timeout is 16 seconds. So as a dumb user, I would expect `-t 30' to set the timeout to 30s. You can imagine my surprise when the watchdog ends up being set to 34s, result of the convoluted conversion from double to integer from the log base 2 of the timeout converted to nanosecond. That's more than 10% of error on this timeout to what the manual page says it would, and at the end, you can only set the watchdog to 62 different value. Folks, I'm definitively not impressed... - Arnaud ___ 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: Queue drop not accounted ?
On Thu, Sep 15, 2011 at 09:25:19PM -0400, Arnaud Lacombe wrote: > Hi, > > Shouldn't packet freed in IFQ_ENQUEUE() because the queue is full be > accounted as dropped, cf attached patch ? > Hmm, I think err would be set to ENOBUFS for queue full case and this err will crease ifq_drops. > Thanks, > - Arnaud ___ 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: 9.0-BETA2 do not support SpeedStep on E5420
On Thursday 15 September 2011 05:19 pm, Arnaud Lacombe wrote: > Hi, > > On Thu, Sep 15, 2011 at 12:20 PM, Arnaud Lacombe wrote: > > Hi, > > > > From today's -CURRENT: > > > > Copyright (c) 1992-2011 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, > > 1993, 1994 � � � �The Regents of the University of California. > > All rights reserved. FreeBSD is a registered trademark of The > > FreeBSD Foundation. FreeBSD 9.0-BETA2 #17 r225560+be1f8b9: Thu > > Sep 15 12:05:41 EDT 2011 � > > �al@shai-hulud:/data/src/freebsd/obj/master/i386.i386/data/src/fr > >eebsd/src/sys/GENERIC i386 > > CPU: Intel(R) Xeon(R) CPU � � � � � E5420 �@ 2.50GHz (2493.80-MHz > > 686-class CPU) �Origin = "GenuineIntel" �Id = 0x1067a �Family = 6 > > �Model = 17 �Stepping = 10 > > �Features=0xbfebfbff >MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS, > >HTT,TM,PBE> > > �Features2=0x40ce3bd >6,xTPR,PDCM,DCA,SSE4.1,XSAVE> �AMD Features=0x2010 > > �AMD Features2=0x1 > > �TSC: P-state invariant, performance statistics > > real memory �= 6442450944 (6144 MB) > > avail memory = 3677458432 (3507 MB) > > Event timer "LAPIC" quality 400 > > ACPI APIC Table: <100509 APIC1714> > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > FreeBSD/SMP: 2 package(s) x 4 core(s) > > �cpu0 (BSP): APIC ID: �0 > > �cpu1 (AP): APIC ID: �1 > > �cpu2 (AP): APIC ID: �2 > > �cpu3 (AP): APIC ID: �3 > > �cpu4 (AP): APIC ID: �4 > > �cpu5 (AP): APIC ID: �5 > > �cpu6 (AP): APIC ID: �6 > > �cpu7 (AP): APIC ID: �7 > > [...] > > est0: failed to enable SpeedStep > > p4tcc0: on cpu0 > > est1: failed to enable SpeedStep > > p4tcc1: on cpu1 > > est2: failed to enable SpeedStep > > p4tcc2: on cpu2 > > est3: failed to enable SpeedStep > > p4tcc3: on cpu3 > > est4: failed to enable SpeedStep > > p4tcc4: on cpu4 > > est5: failed to enable SpeedStep > > p4tcc5: on cpu5 > > est6: failed to enable SpeedStep > > p4tcc6: on cpu6 > > est7: failed to enable SpeedStep > > p4tcc7: on cpu7 > > different issue, same config, still est(4) related, bot on a Q9650: > > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-BETA2 #16 r225462+e068e24-dirty: Sat Sep 10 14:50:17 > EDT 2011 > al@shai-hulud:/data/src/freebsd/obj/master/i386.i386/data/src/freeb >sd/src/sys/GENERIC i386 > CPU: Pentium III/Pentium III Xeon/Celeron (2666.72-MHz 686-class > CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 > Stepping = 10 > Features=0xbfebfbffR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,T >M,PBE> > Features2=0x408e3fd16,xTPR,PDCM,SSE4.1,XSAVE> AMD Features=0x2010 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 2147483648 (2048 MB) > avail memory = 2084757504 (1988 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > [...] > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 616082506000825 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 616082506000825 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > est2: on cpu2 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 616082506000825 > device_attach: est2 attach returned 6 > p4tcc2: on cpu2 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 616082506000825 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 est depends on acpi_perf to get frequency/voltage information to get/set MSRs. Your BIOS does not export _PSS mothods and that's why it's failing. If you can find SSDT dump with _PSS methods for the *exact* CPU model from "somewhere", you can insert it into your DSDT and override. There are many possible causes. Some BIOS do not care about workstation/server class CPUs. Some BIOS only exports _PSS methods when it "thinks" the OS supports it. Some (broken) BIOS dynamically constructs/loads/unloads _PSS methods during cold boot to limit boot-time frequency (usually for mobile processors), then acpi_perf misses it. Some times calibrated frequency at boot-time is too wild and it does not match any frequency from probed _PSS. Newer models are more complicated because of dynamic FSB switching, Turbo Boost, etc. It goes on and on... Intel did not publish vital information to support any CPUs beyond Pentium M family but you may find some clues from Intel BITS source. http://biosbits.org/ Also, Linux ACPI validation test may help, too. http://www.lesswatts.org/projects/acpi/validation.php Some time ago, I have written an ugly patch to support newer
ia64 r221488: panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562
I know it's not exactly current anymore, but.. ia64 r221488 panic: blockable sleep lock (sleep mutex) process lock @ /usr/src/sys/ia64/ia64/trap.c:562 cpuid = 1 KDB: enter: panic [ thread pid 43327 tid 101615 ] Stopped at kdb_enter+0x92: [I2]addl r14=0xffe1fe38,gp ;; db> db> show proc Process 43327 (automoc4) at 0xe0001e91ba70: state: NORMAL uid: 0 gids: 0, 5 parent: pid 43326 at 0xe0001258d1a0 ABI: FreeBSD ELF64 arguments: /usr/local/bin/automoc4 threads: 2 104746 RunQautomoc4 101615 Run CPU 1 initial thread db> show thread Thread 101615 at 0xe000128339e0: proc (pid 43327): 0xe0001e91ba70 name: initial thread stack: 0xa000c8358000-0xa000c835 flags: 0x4 pflags: 0 state: RUNNING (CPU 1) priority: 142 container lock: sched lock 1 (0x9ffc00a31140) db> thread 101615 [ thread pid 43327 tid 101615 ] kdb_enter+0x92: [I2]addl r14=0xffe1fe38,gp ;; db> db> bt Tracing pid 43327 tid 101615 td 0xe000128339e0 kdb_enter(0x9ffc00913e38, 0x9ffc00913e38, 0x9ffc00351990, 0x793) at kdb_enter+0x92 panic(0x9ffc0091cbd8, 0x9ffc00912538, 0x9ffc00912518, 0x9ffc00953490, 0x232, 0x9ffc00953490) at panic+0x2e0 witness_checkorder(0xe0001e91bb68, 0x9, 0x9ffc00953490, 0x232, 0x0) at witness_checkorder+0x1b0 _mtx_lock_flags(0xe0001e91bb68, 0x0, 0x9ffc00953490, 0x232, 0x9ffc007e1160, 0x716, 0x9ffc0091d410) at _mtx_lock_flags+0x130 trap(0x14, 0xa000c835f000) at trap+0x940 ivt_Data_TLB() at ivt_Data_TLB+0x1d0 --- trapframe at 0xa000c835f000 uma_zalloc_arg(0xe001ab40, 0x0, 0x2) at uma_zalloc_arg+0x121 vm_map_entry_create(0xe00010c100cd, 0x9ffc0076f680, 0x48d, 0xe00010c1) at vm_map_entry_create+0x80 _vm_map_clip_start(0xe00010c1, 0xe0001e14d680, 0xa000b4a32000, 0xe0001e14d6c8) at _vm_map_clip_start+0x2a0 vm_map_delete(0xe00010c1, 0xa000b4a32000, 0xa000b4a36000) at vm_map_delete+0xd0 vm_map_remove(0xe00010c1, 0xa000b4a32000, 0xa000b4a36000) at vm_map_remove+0x80 pipe_free_kmem(0xe00011be4708, 0xe00011be4718, 0x9ffc003f73d0, 0x590, 0xe000128339e0) at pipe_free_kmem+0x110 pipeclose(0xe00011be4708) at pipeclose+0x660 pipe_close(0xe000127f3a90, 0xe00011be4708, 0x9ffc002e0410) at pipe_close+0x50 _fdrop(0xe000127f3a90, 0xe000128339e0, 0x9ffc002e13f0, 0xb9b) at _fdrop+0xb0 closef(0xe000127f3a90, 0xe000128339e0, 0x4a0, 0xe000128339e0) at closef+0x570 kern_close(0xe000128339e0, 0x9ffc0090c938) at kern_close+0x250 close(0xe000128339e0, 0xa000c835f4e8, 0x9ffc003dc9c0, 0x50e) at close+0x30 syscallenter(0xe000128339e0, 0xa000c835f3a0, 0xa000c835f3a8) at syscallenter+0x4e0 syscall(0xa000c835f4c8, 0xe000128339e0, 0x1208a5290, 0x9ffc007dd880, 0x8, 0x0) at syscall+0x60 epc_syscall_return() at epc_syscall_return db> -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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"
[PATCH: iwn(4)] Fix channel switching in monitor mode
Hi!
I just got a "Centrino Advanced-N 6230" half-size mini-pcie card
(using iwn6000g2bfw.ko firmware, my Dell Precision M4500 laptop
came with an unsupported Broadcom BCM4313:
https://laptop.bsdgroup.de/freebsd/index.html?action=show_laptop_detail&laptop=13061
), and found channel switching didn't work in monitor mode, the
patch below seems to fix it - also at:
http://people.freebsd.org/~nox/tmp/patch-iwn-channel-monitor.txt
(I also applied the two patches from the `"Intel Centrino Advanced-N +
WiMAX 6250" doesn't work' thread tho I'm not 100% sure they are needed
for this nic:
http://markmail.org/message/exik7phjs2j7pnsi
and
http://docs.freebsd.org/cgi/mid.cgi?CAAgh0_bL7K3PZVAZxPV8JwdhnopOvdRp0Z+xHU-CfGba5bz1Kw
)
And here is the channel switching patch:
--- src/sys/dev/iwn/if_iwn.c.orig
+++ src/sys/dev/iwn/if_iwn.c
@@ -6984,12 +6984,24 @@ iwn_set_channel(struct ieee80211com *ic)
const struct ieee80211_channel *c = ic->ic_curchan;
struct ifnet *ifp = ic->ic_ifp;
struct iwn_softc *sc = ifp->if_softc;
+ int error;
IWN_LOCK(sc);
sc->sc_rxtap.wr_chan_freq = htole16(c->ic_freq);
sc->sc_rxtap.wr_chan_flags = htole16(c->ic_flags);
sc->sc_txtap.wt_chan_freq = htole16(c->ic_freq);
sc->sc_txtap.wt_chan_flags = htole16(c->ic_flags);
+
+ /*
+* Only need to set the channel in Monitor mode. AP scanning and auth
+* are already taken care of by their respective firmware commands.
+*/
+ if (ic->ic_opmode == IEEE80211_M_MONITOR) {
+ error = iwn_config(sc);
+ if (error != 0)
+ device_printf(sc->sc_dev,
+ "error %d settting channel\n", error);
+ }
IWN_UNLOCK(sc);
}
___
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: Thinkpad CD-ROM hotplug with ATA_CAM
On Fri, Sep 16, 2011 at 6:30 AM, Andriy Gapon wrote: > on 16/09/2011 15:55 Boris Kochergin said the following: >> On 09/14/11 12:15, Andriy Gapon wrote: >>> on 14/09/2011 18:11 Boris Kochergin said the following: camcontrol rescan all >>> I think that this command may screw up communication between kernel and HDD >>> from >>> which the OS runs. >> >> It works under normal circumstances--I can run "camcontrol rescan all" on a >> system >> with ATA_CAM and the root filesystem isn't disturbed. >> >>> Perhaps using a specific bus number would work better. >>> >> >> Somewhat, but results are still undesirable. "camcontrol rescan 1" (the >> CD-ROM is >> listed as being on scbus1) executes, stays in the cbwait state for 30 >> seconds, >> then the system locks up. >> >> "camcontrol reset 1" has the same behavior as "camcontrol rescan all" in >> that the >> system locks up instantly. > > Weird. Can you provoke a panic when that happens? > Maybe you can contact mav@ directly and he'd be interested in debugging this > case. I fear that BIOS may have some issue. I have a T43 and found that, if I booted with the DVD installed, atacontrol (this was prior to ATA-CAM) would allow me to detach, but if I then inserted a hard drive and tried to attach it, the system would lock up. If I booted with a hard drive in the bay, I could detach, change drives, and attach with no problems. I don't recall if I could replace the hard drive with a DVD, though and I don't have physical access to that system ATM. Still, this sounds rather similar to what I saw and it was unique to the T43. I have had several other ThinkPads, all of which allow me to swap out the DVD for a different drive including the T520 I am using to enter this reply. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@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: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
On Sep 16, 2011, at 8:07 AM, John Baldwin wrote: > I think the "right" way for an admin to disable HTT is to disable it in the > BIOS so that it doesn't show up in the MADT. Back when we were doing the > MPTABLE_FORCE_HTT hack having a separate tunable made sense (and it possibly > made some limited sense if you were worried about the vulnerability on running > machines). However, at this point I think the tunable should just go away and > admins should configure HTT on or off in the BIOS like they would for any > other OS. > > -- > John Baldwin To do it this way (leave SMT enabled in the BIOS but disabled in the OS) makes it easier to release a future upgrade to take advantage of those cores. Once systems are distributed to customer sites it becomes very difficult to do BIOS maintenance. -Andrew -- Andrew Boyerabo...@averesystems.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: ataidle + notebook hdd + 9.0-BETA2
On Wed, September 14, 2011 04:11, Bruce Cran wrote: > On 14/09/2011 04:59, Nenhum_de_Nos wrote: >> rush# ataidle -P 243 /dev/ada0 >> (pass0:ata2:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 40 00 00 00 00 f3 >> 00 >> (pass0:ata2:0:0:0): CAM status: CCB request completed with an error >> Failed to configure APM: No error: 0 > > Can you post the output of "ataidle /dev/ada0" to see what features the > disk supports? On Wed, September 14, 2011 04:11, Bruce Cran wrote: > On 14/09/2011 04:59, Nenhum_de_Nos wrote: >> rush# ataidle -P 243 /dev/ada0 >> (pass0:ata2:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 40 00 00 00 00 f3 >> 00 >> (pass0:ata2:0:0:0): CAM status: CCB request completed with an error >> Failed to configure APM: No error: 0 > > Can you post the output of "ataidle /dev/ada0" to see what features the > disk supports? > > -- > Bruce Cran sorry for the delay, there it goes: macgyver# ataidle /dev/ada0 Model: WDC WD1600BEVS-60RST0 Serial: WD-WXC807304918 Firmware Rev: 04.01G04 ATA revision: ATA-7 LBA 48: yes Geometry: 16383 cyls, 16 heads, 63 spt Capacity: 149GB SMART Supported:yes SMART Enabled: yes Write Cache Supported: yes Write Cache Enabled:yes APM Supported: yes APM Enabled:yes APM Value: 128 AAM Supported: no Pieter, thanks: macgyver# camcontrol idle /dev/ada0 -t 0 macgyver# camcontrol standby /dev/ada0 -t 0 the only way to be sure its ok is to use smarttools ? mav, I think I don't know how to patch: macgyver# patch < /root/ataidle.c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- ataidle.c.prev 2010-11-04 16:17:28.0 +0200 |+++ ataidle.c 2011-09-09 19:30:14.0 +0300 -- Patching file ataidle.c using Plan A... patch: malformed patch at line 11: sizeof(struct ccb_hdr)); thanks for all, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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: Thinkpad CD-ROM hotplug with ATA_CAM
on 16/09/2011 15:55 Boris Kochergin said the following: > On 09/14/11 12:15, Andriy Gapon wrote: >> on 14/09/2011 18:11 Boris Kochergin said the following: >>> camcontrol rescan all >> I think that this command may screw up communication between kernel and HDD >> from >> which the OS runs. > > It works under normal circumstances--I can run "camcontrol rescan all" on a > system > with ATA_CAM and the root filesystem isn't disturbed. > >> Perhaps using a specific bus number would work better. >> > > Somewhat, but results are still undesirable. "camcontrol rescan 1" (the > CD-ROM is > listed as being on scbus1) executes, stays in the cbwait state for 30 seconds, > then the system locks up. > > "camcontrol reset 1" has the same behavior as "camcontrol rescan all" in that > the > system locks up instantly. Weird. Can you provoke a panic when that happens? Maybe you can contact mav@ directly and he'd be interested in debugging this case. -- Andriy Gapon ___ 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: Thinkpad CD-ROM hotplug with ATA_CAM
On 09/14/11 12:15, Andriy Gapon wrote: on 14/09/2011 18:11 Boris Kochergin said the following: camcontrol rescan all I think that this command may screw up communication between kernel and HDD from which the OS runs. It works under normal circumstances--I can run "camcontrol rescan all" on a system with ATA_CAM and the root filesystem isn't disturbed. Perhaps using a specific bus number would work better. Somewhat, but results are still undesirable. "camcontrol rescan 1" (the CD-ROM is listed as being on scbus1) executes, stays in the cbwait state for 30 seconds, then the system locks up. "camcontrol reset 1" has the same behavior as "camcontrol rescan all" in that the system locks up instantly. -Boris ___ 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: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
On Wednesday, September 14, 2011 4:02:41 pm Andrew Boyer wrote: > > On Sep 14, 2011, at 3:56 PM, Andriy Gapon wrote: > > > on 14/09/2011 20:59 Andrew Boyer said the following: > >> When FreeBSD examines the CPU topology using CPUID leaf 11 in > >> topo_probe_0xb(), it never sets hyperthreading_cpus. At the end of > >> topo_probe_0x4() it sets hyperthreading_cpus = cpu_logical. > >> > >> Adding that assignment to line 316 of sys/amd64/amd64/mp_machdep.c seems to > >> do the right thing on a system with two quad-core E5620 CPUs. The APIC IDs > >> that appear when SMT is enabled in the BIOS get marked AP/HT. > >> > >> Do you agree? > > > > I agree, but... > > But see this: > > http://thread.gmane.org/gmane.os.freebsd.devel.hackers/44007/focus=44024 > > > > Someone long ago has decided that new HTT is not the same as old HTT and > > that > > some rules that apply to old HTT should not apply to new HTT. Even the > > name. > > I think that that's not correct. > > But it doesn't seem that I am able to engage into a discussion the person > > who > > made that decision. Also I can not find any other interested developer > > either. > > > > Anyway, hyperthreading_cpus variable is useless beyond dmesg cosmetics. > > And I don't think that any of my changes affected the dmesg output. > > > > In my "avgBSD" I have different SMP topology code, but it's not ready yet > > to be > > submitted for merge into the main tree. > > > > -- > > Andriy Gapon > > > Actually, it's not useless. If you don't set it to something other than zero > the machdep.hyperthreading_allowed tunable doesn't do anything, since it can't tell which CPUs are actually HTT. The reason the machdep.hyperthreading_allowed tunable was added was to disable HTT on Pentium4's due to a security issue Colin found that was specific to the HTT on Pentium4's. The second generation HTT is not (AFAIK) subject to the same vulnerability. Thus, people disabling HTT because they are paranoid about RSA keys being sniffed shouldn't end up disabling HTT on newer CPUs unnecessarily. In my opinion, though, the old HTT stuff is water way under the bridge at this point (and I'm a bit skeptical about the practical vulnerability of the old HTT stuff anyway). I think the "right" way for an admin to disable HTT is to disable it in the BIOS so that it doesn't show up in the MADT. Back when we were doing the MPTABLE_FORCE_HTT hack having a separate tunable made sense (and it possibly made some limited sense if you were worried about the vulnerability on running machines). However, at this point I think the tunable should just go away and admins should configure HTT on or off in the BIOS like they would for any other OS. -- 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: SSD - TRIM, SU and SUJ - Installer Options
On Thu, Sep 08, 2011 at 06:21:40PM +0200, Nathan Whitehorn wrote: > On 09/08/11 16:22, mysph...@web.de wrote: > >Hi there, > > > >first off all I have to say, that your new Installer in FBSD v9.0 is > >very well done. > >I just found an option, which is not activated at this time. So I wanted > >to ask, if it???s possible a bug or something like that. > > > >I???ve tried to change the in the section Partition Editor with > >the subsection Add Partition and wanted to save my changes: Softupdates > >= disabled, Softupdates journaling = disabled, TRIM = enabled with the > > button. > >But if I reenter the menu, so my changes will be overwritten > >with the default values: SU = enabled, SUJ = enabled ([UFS1 +] TRIM = > >disabled). > > > >I???ve tried this without success in FBSD v9.0 BETA1+2 (amd64) with the > >ISO- and the IMG Images. > > > >My workaround is, that I run in single-user-mode and change the values > >with tunefs. > > > >Would you please check, that point ??? if my act is accurate. > > > >Thanks in advance and have a nice day! > > This is an interesting point that I hadn't tested. The options do work > -- the state of the dialog is just not restored when the Options menu is > reentered and so a second trip to Options resets the defaults, unless > you then change it again. I'm traveling at the moment, so am not able to > fix it at the moment. The internal architecture may also make it > slightly tricky to fix. In my experience the filesystem options menu doesn't work at all, i.e. the options select there are just ignored also when selecting them just once and not re-entering that menu. I've tried to create a filesystem with SUJ disabled and TRIM enabled twice now, last time with BETA2 on amd64, and I always end up with a filesystem that has SUJ enabled but TRIM disabled. Marius ___ 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: SSD - TRIM, SU and SUJ - Installer Options
On 09/16/11 11:11, Marius Strobl wrote: On Thu, Sep 08, 2011 at 06:21:40PM +0200, Nathan Whitehorn wrote: On 09/08/11 16:22, mysph...@web.de wrote: Hi there, first off all I have to say, that your new Installer in FBSD v9.0 is very well done. I just found an option, which is not activated at this time. So I wanted to ask, if it???s possible a bug or something like that. I???ve tried to change the in the section Partition Editor with the subsection Add Partition and wanted to save my changes: Softupdates = disabled, Softupdates journaling = disabled, TRIM = enabled with the button. But if I reenter the menu, so my changes will be overwritten with the default values: SU = enabled, SUJ = enabled ([UFS1 +] TRIM = disabled). I???ve tried this without success in FBSD v9.0 BETA1+2 (amd64) with the ISO- and the IMG Images. My workaround is, that I run in single-user-mode and change the values with tunefs. Would you please check, that point ??? if my act is accurate. Thanks in advance and have a nice day! This is an interesting point that I hadn't tested. The options do work -- the state of the dialog is just not restored when the Options menu is reentered and so a second trip to Options resets the defaults, unless you then change it again. I'm traveling at the moment, so am not able to fix it at the moment. The internal architecture may also make it slightly tricky to fix. In my experience the filesystem options menu doesn't work at all, i.e. the options select there are just ignored also when selecting them just once and not re-entering that menu. I've tried to create a filesystem with SUJ disabled and TRIM enabled twice now, last time with BETA2 on amd64, and I always end up with a filesystem that has SUJ enabled but TRIM disabled. It used to work -- looks like a typo recently broke it. Should be fixed shortly. -Nathan ___ 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: 9.0 beta2 & the new bsdinstaller
> Wiki, gnats, scrap of paper on someones desk, etc? I've put a link to the few existing PRs in GNATS onto the wiki page. mcl ___ 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: ZFS: i/o error - all block copies unavailable after upgrading to r225312
I've discovered another issue with both the current code and the previous
versions of the patch. So another version is at the same URL:
http://people.freebsd.org/~avg/zfs-boot-gang.diff
The problem was with gang blocks on a raidz vdev. zio_read_gang would pass a
NULL bp to vdev_raidz_read, but that function doesn't expect that and really
needs a valid bp.
Pawel, I also understood the code in zio_read that does size rounding up based
on v_ashift. That code is for vdev_raidz_read which needs the size to be
multiple of 1 << v_ashift. And, again, this would have posed a problem for
zio_read_gang, which always passed SPA_GANGBLOCKSIZE when reading a gang block
header.
So, a list of fixes and logical changes:
- correctly read gang header from raidz [*]
- decompress assembled gang block data if compressed
- verify checksum of a gang header
- verify checksum of assembled gang block data
- verify checksum of uber block
[*] - new in this version of patch.
Description of the code changes:
- remove offset parameter from zio_checksum_error
This parameter has only been used for the case of verifying checksum of a vdev
label. The offset is now passed via DVA offset field in a made up bp pointing
to the label.
zio_checksum_error now gets all checksum parameters from the bp.
- zio_read_gang new uses an artificial bp to read a gang header via zio_read
This solves all the problems with gang blocks on raidz as zio_read already has
all the code to handle raidz correctly.
- zio_read performs size rounding only if v_read == vdev_raidz_read
This is to make the intention of the code more clear. And also to slightly
optimize non-raidz cases with non-default ashift where an unnecessary
intermediate buffer would otherwise be used.
Some inline comments (marked with %):
Index: sys/cddl/boot/zfs/zfssubr.c
===
--- sys/cddl/boot/zfs/zfssubr.c (revision 225581)
+++ sys/cddl/boot/zfs/zfssubr.c (working copy)
@@ -181,14 +181,17 @@
}
static int
-zio_checksum_error(const blkptr_t *bp, void *data, uint64_t offset)
+zio_checksum_error(const blkptr_t *bp, void *data)
{
- unsigned int checksum = BP_IS_GANG(bp) ? ZIO_CHECKSUM_GANG_HEADER :
BP_GET_CHECKSUM(bp);
- uint64_t size = BP_GET_PSIZE(bp);
+ uint64_t size;
+ unsigned int checksum;
zio_checksum_info_t *ci;
zio_cksum_t actual_cksum, expected_cksum, verifier;
int byteswap;
+ checksum = BP_GET_CHECKSUM(bp);
+ size = BP_GET_PSIZE(bp);
+
%
% checksum type and size are always taken from the bp.
% Note that BP_IS_GANG(bp) doesn't imply that the caller wants to verify
% the gang header (as was assumed before); the caller want want to verify
% the whole assembled data as well.
%
if (checksum >= ZIO_CHECKSUM_FUNCTIONS)
return (EINVAL);
ci = &zio_checksum_table[checksum];
@@ -206,7 +209,8 @@
if (checksum == ZIO_CHECKSUM_GANG_HEADER)
zio_checksum_gang_verifier(&verifier, bp);
else if (checksum == ZIO_CHECKSUM_LABEL)
- zio_checksum_label_verifier(&verifier, offset);
+ zio_checksum_label_verifier(&verifier,
+ DVA_GET_OFFSET(BP_IDENTITY(bp)));
%
% label offset is taken from the bp now.
%
else
verifier = bp->blk_cksum;
@@ -224,7 +228,6 @@
byteswap_uint64_array(&expected_cksum,
sizeof (zio_cksum_t));
} else {
- ASSERT(!BP_IS_GANG(bp));
%
% the assert is no longer valid as we pass a gang block bp
% when verifying checksum of assembled data
%
expected_cksum = bp->blk_cksum;
ci->ci_func[0](data, size, &actual_cksum);
}
@@ -1248,7 +1251,7 @@
raidz_checksum_verify(const blkptr_t *bp, void *data)
{
- return (zio_checksum_error(bp, data, 0));
+ return (zio_checksum_error(bp, data));
}
/*
Index: sys/boot/zfs/zfsimpl.c
===
--- sys/boot/zfs/zfsimpl.c (revision 225581)
+++ sys/boot/zfs/zfsimpl.c (working copy)
@@ -347,7 +347,7 @@
rc = vdev->v_phys_read(vdev, vdev->v_read_priv, offset, buf, psize);
if (rc)
return (rc);
- if (bp && zio_checksum_error(bp, buf, offset))
+ if (bp && zio_checksum_error(bp, buf))
%
% the bp can still be NULL here: when raidz code reads blocks of data
% it doesn't pass any bp, because there is really no bp for that data.
% this should be the only case, in all other cases a valid bp must be provided.
%
return (EIO);
return (0);
@@ -800,6 +800,7 @@
BP_SET_PSIZE(&bp, sizeof(vdev_phys_t));
BP_SET_CHECKSUM(&bp, ZIO_CHECKSUM_LABEL);
BP_SET_COMPRESS(&bp, ZIO_COMPRESS_OFF);
+ DVA_SET_OFFSET(BP_IDENTITY(&bp), off);
%
% as described above, the offset is now passed via
