Re: RELENG_8: panic: wrong offset 4096 for sectorsize 2352
As Jeremy Chadwick wrote: Just an informational note about inducing a panic: I tend to, once at the db prompt, do bt then immediately call doadump. That induces memory being written to swap, then do reboot. OK, reproduced the panic (which was easy ;), and did it that way. Now, the stack trace makes sense: (kgdb) bt #0 doadump () at pcpu.h:231 #1 0xc0475049 in db_fncall (dummy1=249790, dummy2=0, dummy3=0, dummy4=0xc69b8914 \220#\003) at /usr/src/sys/ddb/db_command.c:548 #2 0xc0475441 in db_command (last_cmdp=0xc08780fc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #3 0xc047559a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xc04774bd in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229 #5 0xc05a9422 in kdb_trap (type=3, code=0, tf=0xc69b8ac0) at /usr/src/sys/kern/subr_kdb.c:548 #6 0xc079a25e in trap (frame=0xc69b8ac0) at /usr/src/sys/i386/i386/trap.c:721 #7 0xc077fcbc in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #8 0xc05a92aa in kdb_enter (why=0xc07f7e81 panic, msg=0xc07f7e81 panic) at cpufunc.h:71 #9 0xc05796f4 in panic (fmt=0xc07eeafc wrong offset %jd for sectorsize %u) at /usr/src/sys/kern/kern_shutdown.c:575 #10 0xc051d28c in g_io_request (bp=0xc82f4d20, cp=0xc8cf0780) at /usr/src/sys/geom/geom_io.c:427 #11 0xc051daa1 in g_read_data (cp=0xc8cf0780, offset=4096, length=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/geom/geom_io.c:704 #12 0xc09c5692 in gv_read_header (cp=0xc8cf0780, m_hdr=0xc69b8c08) at /usr/src/sys/modules/geom/geom_vinum/../../../geom/vinum/geom_vinum_drive.c:129 #13 0xc09c0e1b in gv_taste (mp=0xc09d75a0, pp=0xcbab9600, flags=0) at /usr/src/sys/modules/geom/geom_vinum/../../../geom/vinum/geom_vinum.c:613 #14 0xc05209df in g_new_provider_event (arg=0xcbab9600, flag=0) at /usr/src/sys/geom/geom_subr.c:551 #15 0xc051cb44 in g_run_events () at /usr/src/sys/geom/geom_event.c:212 #16 0xc051e52a in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:140 #17 0xc054f948 in fork_exit (callout=0xc051e4a0 g_event_procbody, arg=0x0, frame=0xc69b8d28) at /usr/src/sys/kern/kern_fork.c:865 #18 0xc077fd34 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) up 10 #10 0xc051d28c in g_io_request (bp=0xc82f4d20, cp=0xc8cf0780) at /usr/src/sys/geom/geom_io.c:427 427 KASSERT(bp-bio_offset % cp-provider-sectorsize == 0, (kgdb) up #11 0xc051daa1 in g_read_data (cp=0xc8cf0780, offset=4096, length=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/geom/geom_io.c:704 704 g_io_request(bp, cp); (kgdb) up #12 0xc09c5692 in gv_read_header (cp=0xc8cf0780, m_hdr=0xc69b8c08) at /usr/src/sys/modules/geom/geom_vinum/../../../geom/vinum/geom_vinum_drive.c:129 129 d_hdr = g_read_data(cp, GV_HDR_OFFSET, pp-sectorsize, NULL); (kgdb) l 124 KASSERT(m_hdr != NULL, (gv_read_header: null m_hdr)); 125 KASSERT(cp != NULL, (gv_read_header: null cp)); 126 pp = cp-provider; 127 KASSERT(pp != NULL, (gv_read_header: null pp)); 128 129 d_hdr = g_read_data(cp, GV_HDR_OFFSET, pp-sectorsize, NULL); 130 if (d_hdr == NULL) 131 return (-1); 132 off = 0; 133 m_hdr-magic = GV_GET64(be); (kgdb) p cp-provider-sectorsize $1 = 2352 (kgdb) up #13 0xc09c0e1b in gv_taste (mp=0xc09d75a0, pp=0xcbab9600, flags=0) at /usr/src/sys/modules/geom/geom_vinum/../../../geom/vinum/geom_vinum.c:613 613 error = gv_read_header(cp, vhdr); So the panic happens because gvinum is being asked to taste the audio CD device when it's being opened, and gvinum in turn tries to read the header (at offset 4096) from it. Well, the workaround is easy (just return -1 from gv_taste() when noticing the offset is not on a sector boundary - this can never be a valid gvinum device anyway), but I'm curious about why this panic now happens in RELENG_8 when it didn't before. I see Ulf Lilleengen changed a lot there in the gvinum code (thus cc'ing him), maybe he's got an explanation. Previously, gvinum used to have three different taste methods for drives, plexes, and volumes, respectively, while now everything appears to be unified in a single gv_taste() method. Somehow, therein must lie the actual problem. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8: panic: wrong offset 4096 for sectorsize 2352
On 25.05.2011 13:36, Joerg Wunsch wrote: Well, the workaround is easy (just return -1 from gv_taste() when noticing the offset is not on a sector boundary - this can never be a valid gvinum device anyway), but I'm curious about why this panic now happens in RELENG_8 when it didn't before. I see Ulf Lilleengen Are you sure that it is RELENG_8? Or maybe you added options INVARIANTS to your kernel? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: RELENG_8: panic: wrong offset 4096 for sectorsize 2352
As Andrey V. Elsukov wrote: Are you sure that it is RELENG_8? Yes, I am. Or maybe you added options INVARIANTS to your kernel? I did (for other rasons, which you can read about in the freebsd-scsi list). Anyway, it appears to be a software bug. Ah, OK, it's quite possible the bug has always been there, even in RELENG_7 ... I just never tested that one against INVARIANTS. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8: panic: wrong offset 4096 for sectorsize 2352
On 25.05.2011 15:15, Joerg Wunsch wrote: Or maybe you added options INVARIANTS to your kernel? I did (for other rasons, which you can read about in the freebsd-scsi list). Anyway, it appears to be a software bug. Ah, OK, it's quite possible the bug has always been there, even in RELENG_7 ... I just never tested that one against INVARIANTS. I committed the fix in the r83, can you test it? -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: RELENG_8: panic: wrong offset 4096 for sectorsize 2352
As Andrey V. Elsukov wrote: Anyway, it appears to be a software bug. Ah, OK, it's quite possible the bug has always been there, even in RELENG_7 ... I just never tested that one against INVARIANTS. I committed the fix in the r83, can you test it? Спасибо, I'll test it tonight when I'm back at the machine. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: modem support MT9234ZPX-PCIE-NV
Hello Jeremy and FreeBSD friends, On Sun, May 22, 2011 at 12:16:42AM -0700, Jeremy Chadwick wrote: On Sat, May 21, 2011 at 11:20:37AM +0200, Willy Offermans wrote: Dear FreeBSD friends, I need support with a MultiTech modem, MT9234ZPX-PCIE-NV (http://www.multitech.com/en_US/PRODUCTS/Families/MultiModemZPX/) The modem is recognised during the boot event: snip pci6: simple comms, UART at device 0.0 (no driver attached) /snip and also appears in the list of found hardware over the PCI bus: snip none1@pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8 rev=0x02 hdr=0x00 vendor = 'Exar Corp.' device = 'XR17C/D152 Dual PCI UART' class = simple comms subclass = UART /snip However, as the boot process already mentions, there is no driver attached and I cannot get the modem to appear as an accessible and functional device. Is there someone, who can help me to get this modem to work? It would be helpful if you could specify what FreeBSD version you're using. Assuming 8.2 or RELENG_8: no promises, but puc(4) is probably what you're looking for. I would try adding: puc_load=yes To your /boot/loader.conf, then see what happens after booting. uart(4) may auto-attach to that. Again, no promises. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | I'm using FreeBSD 7.2-RELEASE-p2. I have enclosed the dmesg.boot file. puc was already incorporated into the kernel: kosmos# kldload -v puc kldload: can't load puc: File exists So I assume puc has already been loaded. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy * Dr. W.K. Offermans CAT Postdoctoral Fellow CAT Catalytic Center Institut f�r Technische und Makromolekulare Chemie RWTH Aachen Worringerweg 1, Raum 38C-150 D-52074 Aachen, Germany Phone: +49 241 80 28592 Fax:+49 241 80 22593 Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl e-mail: willy.offerm...@catalyticcenter.rwth-aachen.de Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. Copyright (c) 1992-2009 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 7.2-RELEASE-p2 #3: Thu May 12 16:15:47 CEST 2011 wi...@kosmos.rompen.nl:/usr/obj/usr/src/sys/KOSMOS Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3360 @ 2.83GHz (2266.76-MHz K8-class CPU) Origin = GenuineIntel Id = 0x1067a Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x408e3fdSSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,b19,XSAVE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 usable memory = 4285059072 (4086 MB) avail memory = 4116738048 (3926 MB) ACPI APIC Table: 082608 APIC0956 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 082608 RSDT0956 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, dff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci5: ACPI PCI bus on pcib1 pcib2: PCI-PCI bridge at device 0.0 on pci5 pci6: PCI bus on pcib2 pci6: simple comms, UART at device 0.0 (no driver attached)
Re: modem support MT9234ZPX-PCIE-NV
Dear Daniel and FreeBSD friends, On Sun, May 22, 2011 at 10:48:03AM +0200, Daniel O'Connor wrote: On 22/05/2011, at 9:16, Jeremy Chadwick wrote: However, as the boot process already mentions, there is no driver attached and I cannot get the modem to appear as an accessible and functional device. Is there someone, who can help me to get this modem to work? It would be helpful if you could specify what FreeBSD version you're using. Assuming 8.2 or RELENG_8: no promises, but puc(4) is probably what you're looking for. I would try adding: puc_load=yes To your /boot/loader.conf, then see what happens after booting. uart(4) may auto-attach to that. Again, no promises. I have my doubts it would work though, most likely it's a soft modem which will only work with proprietary drivers. I couldn't find any details on the web page though so you might get lucky I suppose :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C According to the manufacturer (http://www.multitech.com/en_US/PRODUCTS/Families/MultiModemZPX/) it is not a soft modem, but a ``hardware'' modem. It says: Built-in processor does the work, so your computer doesn't have to. I do not know if this is sufficient to work under FreeBSD, but it seems to indicate that it does not need any proprietary driver. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, Willy * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: modem support MT9234ZPX-PCIE-NV
On 25/05/2011, at 16:10, Willy Offermans wrote: According to the manufacturer (http://www.multitech.com/en_US/PRODUCTS/Families/MultiModemZPX/) it is not a soft modem, but a ``hardware'' modem. It says: Built-in processor does the work, so your computer doesn't have to. I do not know if this is sufficient to work under FreeBSD, but it seems to indicate that it does not need any proprietary driver. Ahh, sounds promising.. You could just try adding the device IDs to the PUC driver and seeing what happens. Failing that ask Multitech if they can help you out. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: modem support MT9234ZPX-PCIE-NV
On 25/05/2011, at 16:04, Willy Offermans wrote: I'm using FreeBSD 7.2-RELEASE-p2. I have enclosed the dmesg.boot file. puc was already incorporated into the kernel: kosmos# kldload -v puc kldload: can't load puc: File exists So I assume puc has already been loaded. You could try editing /usr/src/sys/dev/puc/pucdata.c to add your card's ID and then rebuild reload the puc module. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: modem support MT9234ZPX-PCIE-NV
On Saturday, May 21, 2011 5:20:37 am Willy Offermans wrote:
Dear FreeBSD friends,
I need support with a MultiTech modem, MT9234ZPX-PCIE-NV
(http://www.multitech.com/en_US/PRODUCTS/Families/MultiModemZPX/)
The modem is recognised during the boot event:
snip
pci6: simple comms, UART at device 0.0 (no driver attached)
/snip
and also appears in the list of found hardware over the PCI bus:
snip
none1@pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8
rev=0x02 hdr=0x00
vendor = 'Exar Corp.'
device = 'XR17C/D152 Dual PCI UART'
class = simple comms
subclass = UART
/snip
However, as the boot process already mentions, there is no driver attached
and I cannot get the modem to appear as an accessible and functional
device. Is there someone, who can help me to get this modem to work?
Try this patch to sys/dev/uart/uart_bus_pci.c:
Index: uart_bus_pci.c
===
--- uart_bus_pci.c (revision 48)
+++ uart_bus_pci.c (working copy)
@@ -110,6 +110,7 @@ static struct pci_id pci_ns8250_ids[] = {
{ 0x1415, 0x950b, 0x, 0, Oxford Semiconductor OXCB950 Cardbus 16950
UART,
0x10, 16384000 },
{ 0x151f, 0x, 0x, 0, TOPIC Semiconductor TP560 56k modem, 0x10 },
+{ 0x13a8, 0x0152, 0x2205, 0x2026, MultiTech MultiModem ZPX, 0x10 },
{ 0x9710, 0x9820, 0x1000, 1, NetMos NM9820 Serial Port, 0x10 },
{ 0x9710, 0x9835, 0x1000, 1, NetMos NM9835 Serial Port, 0x10 },
{ 0x9710, 0x9865, 0xa000, 0x1000, NetMos NM9865 Serial Port, 0x10 },
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8: panic: wrong offset 4096 for sectorsize 2352
As Andrey V. Elsukov wrote: Anyway, it appears to be a software bug. Ah, OK, it's quite possible the bug has always been there, even in RELENG_7 ... I just never tested that one against INVARIANTS. I committed the fix in the r83, can you test it? Works fine! -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [poll] hyperthreading_allowed, hlt_logical_cpus, mp_watchdog
Le Tue, 24 May 2011 16:21:08 +0300, Andriy Gapon a...@freebsd.org a écrit : Hello, I am planning on some changes in head and would like to see if people use the following features: - machdep.hyperthreading_allowed tunable and sysctl If I remember well, these tunables were introduced because the paper of Colin Percival about the HTT security flaw on intel processors : http://www.daemonology.net/hyperthreading-considered-harmful/ http://security.freebsd.org/advisories/FreeBSD-SA-05:09.htt.asc I guess this is still a concern?. Best regards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [poll] hyperthreading_allowed, hlt_logical_cpus, mp_watchdog
On Tue, 24 May 2011 18:27:47 +0200, Josh Carroll josh.carr...@gmail.com wrote: Whatever you do, please leave at least some way (at least a tunable) to enable/disable HTT - some workloads are better with, and some without it, and some BIOSes are unreliable in enabling/disabling it :) I noticed that disabling HTT via the machdep.hyperthreading_allowed tunable resulted in worse performance than disabling HTT via the BIOS. I'm not sure if that is to be expected due to how the scheduler ignores those cores or what, but just an observation I found while testing my i7 2600k to see if I should leave HTT on or off for my particular workloads. I was expecting only certain workloads to perform better with HTT on and others better with it off. However, I haven't found a task that performed better with HTT off. Some are almost equal (within a margin of error), but most are faster with HTT enabled (see below for the testing I did). For the tests below, I used an mdmfs for /usr/obj for all buildworld/buildkernel tests and they were all performed after caching the contents of /usr/src. I also ran each test 5 times and for each data point, I took the best run time. For the ffmpeg tests, I used -threads 0 to let it pick the number of threads to use. It seems hyperthreading on the Sandy Bridge i7 may be worth leaving enabled, though of course what I've tested below is just a small sample of possible tasks. So as with any benchmark, the only relevant tests are the things you use your machine for :) My workloads happen to all benefit from having HTT enabled. Josh buildworld (w/o HTT=-j5, w/HTT=-j11) === HTT off: 558.65 seconds HTT on: 501.01 seconds buildkernel (w/o HTT=-j5, w/HTT=-j7) === HTT off: 188.80 seconds HTT on: 187.03 seconds ffmpeg (10 min SD input - xvid/mp3) === HTT off: 7.75 seconds HTT on: 6.28 seconds ffmpeg (5 min 720p input - h264/aac) === HTT off: 20.08 seconds HTT on: 12.97 seconds ffmpeg (1 min 1080p input - h264/aac) === HTT off: 38.91 seconds HTT on: 30.79 seconds ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I ones read about progress Intel made with HTT in newer cpu's. So it might very well depend on cpu type if the rumors about worse performance with HTT are true or not. Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
