Re: azalia(4) resume diff
On Mon, Feb 28, 2011 at 08:56:57PM -0500, Brad wrote: On Mon, Feb 28, 2011 at 11:16:49PM +, Jacob Meuser wrote: some ATI azalia controllers are brojen after resume, as in PR 6550. the following diff gathers most of the pci conf register manipulation done in azalia_pci_attach() into a new function, azalia_configure_pci(), and calls that function in azalia_pci_attach() and azalia_resume(). this fixes one reported case of post-resume brokenness and doesn't cause any problems on other machines I've tested on, including an ATI device that was working. waiting to hear back about the PR and other reports, but wanted to get this out for testing asap. please test. thanks. This doesn't change anything about the symptom mentioned in the PR and its still broken after resume. FWIW it does fix suspend for me on my desktop. Without this diff everything comes back properly, except for audio which sounds like stuttering static. With this diff my desktop behaves like my laptop when it comes to audio, just works. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Cheers, Jasper Capable, generous men do not create victims, they nurture them.
Re: hangs on reboot
I have SoC machine (dmesg below) which hangs on reboot in most cases.
It seems that the problem was resolved by just commenting KBC_PULSE0
related case in cpu_reset() and machine successfuly rebooted by
triple fault and watchdog reset bits (follow just after).
Should we think about sysctl to give an option to switch it off?
By the way, I briefly tested NetBSD's x86 reboot quirks and found that
they may be useful too (on i386 I mean).
At least, the First case (reset via the Reset Control register)
reboots my SoC machine successfuly.
Second case (reset via the Fast A20 and Init register) don't reboot my
Soc machine alone, but not hangs, and machine still rebooted (with the
help of First). So it may be useful for someone.
I think that these two cases must be enveloped into #ifdef __i386__
--- /usr/src/sys/arch/i386/i386/machdep.c Tue Feb 22 23:47:51 2011
+++ ./machdep.c Tue Mar 1 15:28:02 2011
@@ -3271,10 +3271,10 @@
* connected to the RESET pin on the CPU in many PCs. We tell the
* keyboard controller to pulse this line a couple of times.
*/
- outb(IO_KBD + KBCMDP, KBC_PULSE0);
- delay(10);
- outb(IO_KBD + KBCMDP, KBC_PULSE0);
- delay(10);
+// outb(IO_KBD + KBCMDP, KBC_PULSE0);
+// delay(10);
+// outb(IO_KBD + KBCMDP, KBC_PULSE0);
+// delay(10);
/*
* Try to cause a triple fault and watchdog reset by setting the
@@ -3284,6 +3284,36 @@
setregion(region, idt, sizeof(idt_region) - 1);
lidt(region);
__asm __volatile(divl %0,%1 : : q (0), a (0));
+
+ /* FIRST CASE
+ * Attempt to force a reset via the Reset Control register at
+ * I/O port 0xcf9. Bit 2 forces a system reset when it
+ * transitions from 0 to 1. Bit 1 selects the type of reset
+ * to attempt: 0 selects a soft reset, and 1 selects a
+ * hard reset. We try a hard reset. The first write sets
+ * bit 1 to select a hard reset and clears bit 2. The
+ * second write forces a 0 - 1 transition in bit 2 to trigger
+ * a reset.
+ */
+ outb(0xcf9, 0x2);
+ outb(0xcf9, 0x6);
+ DELAY(50); /* wait 0.5 sec to see if that did it */
+
+ /* SECOND CASE
+ * Attempt to force a reset via the Fast A20 and Init register
+ * at I/O port 0x92. Bit 1 serves as an alternate A20 gate.
+ * Bit 0 asserts INIT# when set to 1. We are careful to only
+ * preserve bit 1 while setting bit 0. We also must clear bit
+ * 0 before setting it if it isn't already clear.
+ */
+ uint8_t b;
+ b = inb(0x92);
+ if (b != 0xff) {
+ if ((b 0x1) != 0)
+ outb(0x92, b 0xfe);
+ outb(0x92, b | 0x1);
+ DELAY(50); /* wait 0.5 sec to see if that did it */
+ }
#if 1
--
antonvm
Omiljeni proizvodi za dame uz popuste i besplatnu dostavu
BliEi se Dan Eena... Pripremili smo posebne poklone za Vas: omiljene proizvode Eena uz posebne pogodnosti! PoEurite, ponuda vaEi samo do 10. marta! Omiljeni proizvodi dama uz BESPLATNU DOSTAVU ili popuste; Relax Tone - ruD ni masaEer Besplatna dostava Relax Tone Vaša cena: 4.990 rsd Više b: Velform Enchance Bra - za podizanje grudi -29% Velform Enchance Bra Vaša cena: 2.490 rsd Višeb: Perfect Pedi - pedikir set -8% Perfect Pedi Vaša cena: 2.290 rsd Više b: Derma Seta - set za ulepšavanje Besplatna dostava Derma Seta Vaša cena: 4.990 rsd Više b: Rina's 90 1. deo + 2. deo - vodiD i za mršavljenje -15% Rina's 1. deo + 2. deo Vaša cena: 1.190 rsd Više b: Hair Do - umetak za kosu -50% Hair Do - umetak za kosu Vaša cena: 3.990 rsd Više b: Velform Perfect Legs - krema za noge Besplatna dostava Velform Perfect Legs Vaša cena: 2.690 rsd Više b: Rejuvera - set za zatezanje lica -27% Rejuvera Vaša cena: 3.990 rsd Više b: Biser maska - maska za lice -22% Biser maska Vaša cena: 990 rsd Više b: Ovu elektronsku poštu primate, ukoliko ste svojevoljno ostavili svoju e-mail adresu na nekom od sajtova Top Shop-a, uD estvovali u našoj poklon igri ili nagradnom kvizu ili se prijavili za e-D asopis Top Shop-a ili nekog od nasih brendova. Ponude date u ovom e-mailu vaEe iskljuD ivo za porudEbine upuDene putem Interneta ili broja telefona 021 489 26 60. Ukoliko ne Eelite više da primate naše elektronske poruke, za odjavljivanje sa naše e-mailing liste, kliknite ovde. Studio Moderna d.o.o., Bulevar vojvode Stepe 30, 21000 Novi Sad, Tel: 021 489 26 60, Fax: 021 489 29 08, E-mail: i...@news.top-shop.rs [IMAGE]If you would no longer like to receive our emails please unsubscribe by clicking here.
Re: USB port reset delay
It works fine on my laptop. uhub7 at uhub4 port 1 ALCOR Generic USB Hub rev 1.10/3.14 addr 2 uhidev0 at uhub7 port 1 configuration 1 interface 0 A4Tech USB KEYBOARD rev 1.10/1.00 addr 3 uhidev1 at uhub7 port 1 configuration 1 interface 1 A4Tech USB KEYBOARD rev 1.10/1.00 addr 3 uhidev2 at uhub7 port 3 configuration 1 interface 0 A4Tech PS/2+USB Mouse rev 1.10/0.02 addr 4 //Logan C-x-C-c
Gran Cierra Puertas en KEVINGSTON. publicidad le jih
[demime 1.01d removed an attachment of type image/jpeg which had a name of cbetelgeuse.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of nentomecimiento.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of alirrojo.jpg]
La Gerencia de Ventas Efectiva, Incrementando Productividad Comercial en MONTERREY - 18 de Marzo
CURSO TALLER La Gerencia de Ventas Efectiva, Incrementando Productividad Comercial Experto instructor: Lic. Carlos Gerardo Melgar Juarez ) Duracion: (1 dia) 9 hrs. Inversion: $4,400 pesos mas IVA Objetivo: El participante lograra ser un buen dirigente, mediante el diseqo de un plan de ventas efectivo que le permitira llevar a sus vendedores a ser parte de un equipo de alto rendimiento; y sobre todo a mejorar sustancialmente el desempeqo de su area o negocio. Alcance: La mejora profesional del responsable del area de ventas en la operacisn y administracisn del area comercial y de su equipo de vendedores. A quien va dirigido: Supervisores, coordinadores y todas aquellas personas interesadas en desarrollar el area comercial de su negocio o empresa y crecer profesionalmente. MONTERREY Sede: Hotel Sheraton Ambassador - Ave. Hidalgo 310 Oriente, Centro. Monterrey. 18 de Marzo Solicite Temario de Click Aqui Marketing y Ventas [IMAGE] Curso Taller La Gerencia de Ventas Efectiva, Incrementando Productividad Comercial Mexico / Guadalajara [IMAGE] Curso Taller El metodo exacto para conseguir resultados en ventas - La Venta Consultiva Mexico / Guadalajara / Monterrey [IMAGE] Curso Taller Liderazgo y Coaching Gerencial en Ventas Mexico / Guadalajara / Monterrey Consulte la Programacion por Area: Manufactura y Produccion | Credito y Cobranza | Recursos Humanos | Adquisiciones y Obras Publicas | Entrenamiento Ejecutivo | Seguridad e Higiene | Negociacion y Compras | Alimentos y Bebidas | Economia y Finanzas | Asistentes Ejecutivas | Marketing y Ventas | Si necesita mayor informacion,comuniquese un Asesor lo atendera de inmediato. SIMCA CAPACITACION Entrenamiento Especializado E-MAIL: simca_capacitac...@hotmail.com Messenger: simca_capacitac...@hotmail.com Lada sin costo: 01 800 543 32 30 Servicios de Informacion Mexicana Capacitando America Diseqamos el curso a la medida de sus necesidades..!Impartimos CURSOS de forma PRIVADA en su empresa, envienos un correo especificando el numero de participantes, el lugar donde se impartira, su nombre, cargo, empresa y telefono.SOLICITE COTIZACION de Click Aqui Si usted no desea que le enviemos mas invitaciones, de Click Aqui, gracias.
uvm_pmemrange.c questions
Hi,
I found 2 possible null pointers by clang static analyzer and I have
attached it to email later. I was also reading the code in this file
and I found out that
1) most of the time in uvm_pmr_getpages(), a newly inserted printf at
line 792 is never reached. I put that printf just to check and verify
a clang warning that search[] is uninitialized. Almost all page
allocations during boot and seen in dmesg are happening in either on
line 786 or line 789 in
if (maxseg == 1 || count == 1)
and
else if (maxseg = count (flags UVM_PLA_TRYCONTIG) == 0) {
So is that else {} block not being reached and is redundant? It looks
like it from the code, as it is only called from uvm_page.c and
uvm_pglist.c and the if () condition. Is the allocator then spending a
lot of time in the search[2] case? Or am I crazy to think that
something's off in that area?
2) another question. Most allocations are either 1 or a power of two.
But there are a few allocations of 3 pages, specifically most
allocations are either 1 page, 2 page, some 16's, some 32's, one
single 128. I printed this info by checking for value of search[try]
at label rescan: on line 901 in uvm_pmemrange.c
Would this cause fragmentation or misalignment and ultimately a
problem? There were exactly eight 3 page allocations after bios got
handed control to /bsd immediately after the lines
real mem = 8587771904 (8189MB)
avail mem = 8345174016 (7958MB)
and a single 3 page allocation after mtrr:Pentium Pro MTRR support. I
get a usb_allocmem() issue right after this line on a NVIDIA USB EHCI
controller on this Sun Ultra 40 with NVIDIA everything. I am attaching
a dmesg also. I have to keep the ehci commented in GENERIC to get it
to boot or disable ehci in UKC everytime.
Would this single odd 3 page alloc cause a problem? Or am I crazy to
think it should?
Thanks for your time,
amit
clang reports for the null pointers
https://filestogeaux.lsu.edu/public/download.php?FILE=akulka1/20861LJ6oU4
https://filestogeaux.lsu.edu/public/download.php?FILE=akulka1/32877HWMeIq
https://filestogeaux.lsu.edu/public/download.php?FILE=akulka1/12907BUBXhj
Index: uvm_pmemrange.c
===
RCS file: /cvs/src/sys/uvm/uvm_pmemrange.c,v
retrieving revision 1.18
diff -u -i uvm_pmemrange.c
--- uvm_pmemrange.c 28 Aug 2010 22:27:47 - 1.18
+++ uvm_pmemrange.c 1 Mar 2011 22:28:46 -
@@ -634,7 +634,7 @@
* uvm_page_init() may not have initialized its array sorted by
* page number.
*/
- for (iter = start; iter != end; iter = iter_end) {
+ for (iter = start; iter != NULL iter != end; iter = iter_end) {
iter_end = TAILQ_NEXT(iter, pageq);
TAILQ_REMOVE(pgl, iter, pageq);
}
@@ -1628,7 +1628,7 @@
* Ack, no hits. Walk the address tree until to find something usable.
*/
for (low = RB_NEXT(uvm_pmr_addr, pmr-addr, low);
- low != high;
+ low != high high_next != NULL;
low = RB_NEXT(uvm_pmr_addr, pmr-addr, low)) {
KASSERT(PMR_IS_SUBRANGE_OF(atop(VM_PAGE_TO_PHYS(high_next)),
atop(VM_PAGE_TO_PHYS(high_next)) + high_next-fpgsz,
OpenBSD 4.9 (GENERIC.MP) #4: Tue Mar 1 16:14:15 CST 2011
r...@rsgis02.lsu.edu:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8587771904 (8189MB)
avail mem = 8345174016 (7958MB)
XXX: search [2] = 2
XXX: search [2] = 2
XXX: search [2] = 2
XXX: search [2] = 2
XXX: search [2] = 2
XXX: search [2] = 2
XXX: search [2] = 2
XXX: search [2] = 2
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 3
XXX: search [2] = 3
XXX: search [2] = 3
XXX: search [2] = 3
XXX: search [2] = 3
XXX: search [2] = 3
XXX: search [2] = 3
XXX: search [2] = 3
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 4
XXX: search [2] = 16
XXX: search [2] = 16
XXX: search [2] = 16
XXX: search [2] = 16
XXX: search [2] = 16
XXX: search [2] = 16
XXX: search [2] = 16
XXX: search [2] = 16
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xaff64000 (40 entries)
bios0: vendor Phoenix Technologies Ltd. version 1.30 date 05/18/2006
bios0: Sun Microsystems Sun Ultra 40 Workstation
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT SRAT SPCR MCFG APIC BOOT
acpi0: wakeup devices PCI0(S5) USB0(S3) USB2(S3) MAC0(S5) P2P0(S5)
XVR0(S5) XVR1(S5) MAC0(S5) XVR0(S5) XVR1(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-129
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Dual Core AMD Opteron(tm) Processor 280, 2411.44 MHz
cpu0:
Patch to fix __cxa_finalize()
This diff fixes a bug in libc's __cxa_finalize() implementation. The
IA64 C++ ABI says that __cxa_finalize(NULL) should run all remaining
handlers registered with __cxa_atexit(); however, the current handling
of this results in a garbage argument being passed instead.
E.g., this sample program should print 0x8675309:
#include stdio.h
extern void *__dso_handle;
extern void __cxa_atexit(void (*)(void *), void *, void *);
static void foo(void *arg) {
printf(%p\n, arg);
}
int main() {
__cxa_atexit(foo, (void *) 0x8675309, __dso_handle);
return 0;
}
This doesn't seem to affect GCC (at least not in base) because it
generates trampoline code so the argument is unneeded anyway, but
Clang (LLVM) makes use of it for registering global destructors,
causing unpredictable run-time errors when the process exits.
(I'm told there's no risk in calling a no-argument function with a
superfluous void pointer argument, so the atexit.[ch] code could be
further simplified by simply always passing an argument to the handler
even if fn_dso == NULL.)
ok?
Index: lib/libc/stdlib/atexit.c
===
RCS file: /cvs/src/lib/libc/stdlib/atexit.c,v
retrieving revision 1.14
diff -u -p lib/libc/stdlib/atexit.c
--- lib/libc/stdlib/atexit.c5 Sep 2007 20:47:47 - 1.14
+++ lib/libc/stdlib/atexit.c24 Feb 2011 04:44:53 -
@@ -147,7 +147,7 @@ __cxa_finalize(void *dso)
p-fns[n].fn_ptr.cxa_func = NULL;
mprotect(p, pgsize, PROT_READ);
}
- if (dso != NULL)
+ if (fn.fn_dso != NULL)
(*fn.fn_ptr.cxa_func)(fn.fn_arg);
else
(*fn.fn_ptr.std_func)();
Patch to change va_arg/va_end to function-like macros
This diff changes stdarg.h's va_arg and va_end macros to be defined as function-like macros rather than object-like macros. The C standard does not explicitly require va_arg and va_end to be function-like macros, but some of the wording appears to implicitly require it. E.g., section 7.15.1.1.2 says: The va_arg macro expands to an expression that has the specified type and the value of the next argument in the call. Strictly speaking, if va_arg is an object-like macro, its expansion will not be an expression of the specified type (or any type, as __built_va_arg is simply a GCC-extension keyword and is not considered by itself an expression). This diff allows (questionable, but technically legal) code that uses va_arg as a local variable name to compile. ok? Index: sys/arch/arm/include/stdarg.h === RCS file: /cvs/src/sys/arch/arm/include/stdarg.h,v retrieving revision 1.7 diff -u -p sys/arch/arm/include/stdarg.h --- sys/arch/arm/include/stdarg.h 23 Oct 2008 21:25:07 - 1.7 +++ sys/arch/arm/include/stdarg.h 1 Mar 2011 00:29:48 - @@ -49,8 +49,8 @@ typedef __va_list va_list; #defineva_start(ap, last) __builtin_stdarg_start((ap), (last)) -#defineva_arg __builtin_va_arg -#defineva_end __builtin_va_end +#defineva_arg(ap, type)__builtin_va_arg((ap), type) +#defineva_end(ap) __builtin_va_end((ap)) #define__va_copy(dest, src)__builtin_va_copy((dest), (src)) #endif /* !_ARM32_STDARG_H_ */ Index: sys/arch/sh/include/stdarg.h === RCS file: /cvs/src/sys/arch/sh/include/stdarg.h,v retrieving revision 1.2 diff -u -p sys/arch/sh/include/stdarg.h --- sys/arch/sh/include/stdarg.h23 Oct 2008 21:25:07 - 1.2 +++ sys/arch/sh/include/stdarg.h1 Mar 2011 00:29:48 - @@ -49,8 +49,8 @@ typedef __va_list va_list; #endif #defineva_start(ap, last) __builtin_stdarg_start((ap), (last)) -#defineva_arg __builtin_va_arg -#defineva_end __builtin_va_end +#defineva_arg(ap, type)__builtin_va_arg((ap), type) +#defineva_end(ap) __builtin_va_end((ap)) #define__va_copy(dest, src)__builtin_va_copy((dest), (src)) #endif /* !_SH_STDARG_H_ */ Index: sys/sys/stdarg.h === RCS file: /cvs/src/sys/sys/stdarg.h,v retrieving revision 1.7 diff -u -p sys/sys/stdarg.h --- sys/sys/stdarg.h17 Sep 2009 20:46:55 - 1.7 +++ sys/sys/stdarg.h1 Mar 2011 00:29:48 - @@ -34,8 +34,8 @@ typedef __builtin_va_list __gnuc_va_list; Thus, va_arg (..., short) is not valid. */ #define va_start(ap, last) __builtin_va_start((ap), last) -#define va_end __builtin_va_end -#define va_arg __builtin_va_arg +#define va_end(ap) __builtin_va_end((ap)) +#define va_arg(ap, type) __builtin_va_arg((ap), type) #define __va_copy(dst, src)__builtin_va_copy((dst),(src)) typedef __gnuc_va_list va_list;
Patch to fix libstdc++ std::showpos
There is currently a bug with std::showpos with the older
version of libstdc++-v3 that is bundled with gcc 4.2.1
in-tree. It was exposed by the Gnash testsuite when
dates were not being formatted correctly showing
GMT0 instead of GMT+ as expected.
2007-11-26 Paolo Carlini pcarl...@suse.de
* include/bits/locale_facets.tcc (num_put::_M_insert_int): When
ios_base::showpos and the type is signed and the value is zero,
prepend +.
Index: gnu/gcc/libstdc++-v3/include/bits/locale_facets.tcc
===
RCS file: /home/cvs/src/gnu/gcc/libstdc++-v3/include/bits/locale_facets.tcc,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 locale_facets.tcc
--- gnu/gcc/libstdc++-v3/include/bits/locale_facets.tcc 15 Oct 2009 17:11:32
- 1.1.1.1
+++ gnu/gcc/libstdc++-v3/include/bits/locale_facets.tcc 6 Feb 2011 21:40:46
-
@@ -1015,13 +1015,13 @@ _GLIBCXX_BEGIN_LDBL_NAMESPACE
if (__builtin_expect(__dec, true))
{
// Decimal.
- if (__v 0)
+ if (__v = 0)
{
if (__flags ios_base::showpos
numeric_limits_ValueT::is_signed)
*--__cs = __lit[__num_base::_S_oplus], ++__len;
}
- else if (__v)
+ else
*--__cs = __lit[__num_base::_S_ominus], ++__len;
}
else if (__flags ios_base::showbase __v)
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Comment typo fix for gcc/alpha openbsd.h
On 21/01/11 12:12 AM, Brad wrote: Typo fix. Index: openbsd.h === RCS file: /home/cvs/src/gnu/usr.bin/gcc/gcc/config/alpha/openbsd.h,v retrieving revision 1.9 diff -u -p -r1.9 openbsd.h --- openbsd.h 20 Oct 2010 20:25:33 - 1.9 +++ openbsd.h 21 Jan 2011 05:09:41 - @@ -80,7 +80,7 @@ Boston, MA 02111-1307, USA. */ #undef STACK_CHECK_BUILTIN #define STACK_CHECK_BUILTIN 0 -/* OpenBSD doesn't currently supprot thread-local storage. */ +/* OpenBSD doesn't currently support thread-local storage. */ /* alpha.c undefs TARGET_HAVE_TLS and redefines it to HAVE_AS_TLS !?!?! */ #undef HAVE_AS_TLS #define HAVE_AS_TLS false Still hasn't been commited. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: azalia(4) resume diff
It works fine on my laptop: dmesg: azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x03: apic 2 int 22 (irq 4) azalia0: codecs: Realtek ALC660, ATT/Lucent/0x1040, using Realtek ALC660 audio0 at azalia0 I don't notice differences before and after applying the diffs, using mplayer to play some mp3s, and then suspending using -s or -Z with apm. //Logan C-x-C-c
Re: azalia(4) resume diff
It works fine on my laptop. dmesg: azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x03: apic 2 int 22 (irq 4) azalia0: codecs: Realtek ALC660, ATT/Lucent/0x1040, using Realtek ALC660 audio0 at azalia0 I don't notice any difference before/after applying the diffs when using mplayer to play mp3s. I tried both -z and -S passed to apm. //Logan C-x-C-c
