Re: Bug found in latest -current on amd64 with bigmem = 1
On Sat, 6 Mar 2010 17:36:37 -0500 Jason Crawford ja...@purebsd.net wrote: I was testing out the latest snapshot on my amd64 laptop, and compiling latest sources, when I came across a bug. It appears that with the latest -current, the kernel floods dmesg with errors if bigmem = 1, because of this commit: http://marc.info/?l=openbsd-cvsm=126742779701386w=2 Got similar output caused by this commit. As I understand it this change is supposed to croak for certain bugs when spl-locks are not set appropriately. If I roll sys/arch/amd64/amd64/machdep.c back to 1.102, the flood goes away. If bigmem = 0, the dmesg flood does not happen. dmesgs for my laptop are at the bottom of the email. The message I get flooded with is: splassert: pool_do_put: want 10 have 13 for me it is splassert: if_up: want 5 have 7 but only one time at startup when setting up pppoe. I set splassert_ctl=2 in subr_prf.c to get some debugging info. Below you find the relevant parts from the dmesg. Notice that I ported an unofficial FreeBSD driver for my SIS190 ethernet chip. Still the trace looks like the problem is in the pppoe part. If you don't think so and want to have a look at the driver, I can post it. Christopher === OpenBSD 4.7 (sys) #0: Sun Mar 7 11:39:42 CET 2010 madro...@pundit:/var/obj/sys real mem = 1071841280 (1022MB) avail mem = 103196 (984MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf04b0 (57 entries) bios0: vendor American Megatrends Inc. version 0603 date 03/31/2006 bios0: ASUSTeK Computer INC. K8S-MV-P [...] sgb0 at pci0 dev 4 function 0 SiS 190 rev 0x00invalid EEPROM signature (0) : apic 1 int 19 (irq 5), address 00:15:f2:64:0c:83 rlphy0 at sgb0 phy 1: RTL8201L 10/100 PHY, rev. 1 [...] splassert: if_up: want 5 have 7 Starting stack trace... if_up() at if_up+0x2a sppp_ioctl() at sppp_ioctl+0x8f in_ifinit() at in_ifinit+0x7c sppp_set_ip_addrs() at sppp_set_ip_addrs+0x108 sppp_ipcp_tlu() at sppp_ipcp_tlu+0x44 sppp_cp_input() at sppp_cp_input+0x3e0 sppp_input() at sppp_input+0x38b pppoeintr() at pppoeintr+0xd4 Xsoftnet() at Xsoftnet+0x7d --- interrupt --- (null)() at 0x8 end of kernel end trace frame: 0x7, count: 247 End of stack trace.
Re: Add rEFIt bootloader to FAQ4
Lars Nooden wrote: rEFIt can be used with OpenBSD, especially when dual booting OS X, or when triple booting OS X and Linux. Good suggestion, just added it. two issues about your diff, however: 1) gmail mangled it. (and oddly. I'm sure they have a reason for what they did to it, but I'm at a loss as to what it would be). 2) the translations are handled separately -- while the effort is appreciated, if we commit them, we screw up the translators. Thank goodness...I'm hopefully monolingual, if I had to make changes and write new material in ten languages, we'll, I guess I'd have more free time. :) Nick. Index: faq4.html === RCS file: /cvs/www/faq/faq4.html,v retrieving revision 1.294 diff -u -p -r1.294 faq4.html --- faq4.html 12 Feb 2010 03:12:21 - 1.294 +++ faq4.html 5 Mar 2010 19:47:20 - @@ -2554,7 +2554,8 @@ Website for more current information. D p Some other bootloaders OpenBSD users have used successfully include a href=http://gag.sourceforge.net/;GAG/a, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, and a href=http://www.gnu.org/software/grub/;GRUB/a. p Index: ./cs/faq4.html === RCS file: /cvs/www/faq/cs/faq4.html,v retrieving revision 1.33 diff -u -p -r1.33 faq4.html --- ./cs/faq4.html28 Feb 2010 08:37:46 - 1.33 +++ ./cs/faq4.html5 Mar 2010 19:47:21 - @@ -2517,7 +2517,8 @@ a web str??nku pro aktu??ln??j infor p N??kter?? dal boot loadery, kter?? OpenBSD u??ivatel?? ??spn?? pou??ili v??etn?? a href=http://gag.sourceforge.net/;GAG/a, -a href=http://www.ranish.com/part/;Ranish Partition Manager/a +a href=http://www.ranish.com/part/;Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, a a href=http://www.gnu.org/software/grub/;GRUB/a. p Index: ./de/faq4.html === RCS file: /cvs/www/faq/de/faq4.html,v retrieving revision 1.125 diff -u -p -r1.125 faq4.html --- ./de/faq4.html1 Dec 2008 07:52:51 - 1.125 +++ ./de/faq4.html5 Mar 2010 19:47:22 - @@ -2109,7 +2109,8 @@ Zu einigen anderen Bootloadern, die von eingesetzt worden sind, geh?ren a href=http://gag.sourceforge.net/;GAG/a, OS-BS, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, und a href=http://www.gnu.org/software/grub/;GRUB/a. p Index: ./es/faq4.html === RCS file: /cvs/www/faq/es/faq4.html,v retrieving revision 1.77 diff -u -p -r1.77 faq4.html --- ./es/faq4.html11 Sep 2004 08:20:12 - 1.77 +++ ./es/faq4.html5 Mar 2010 19:47:24 - @@ -2176,7 +2176,8 @@ Otros cargadores de arranque que se han OpenBSD son: a href=http://gag.sourceforge.net/;GAG/a, OSBS, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, y a href=http://www.gnu.org/software/grub/;GRUB/a. p Index: ./fr/faq4.html === RCS file: /cvs/www/faq/fr/faq4.html,v retrieving revision 1.95 diff -u -p -r1.95 faq4.html --- ./fr/faq4.html16 Feb 2010 09:19:53 - 1.95 +++ ./fr/faq4.html5 Mar 2010 19:47:25 - @@ -2663,7 +2663,8 @@ modifi?s. D'autres utilisateurs de chargeurs de d?marrage OpenBSD ont inclus avec succ?s a href=http://gag.sourceforge.net/;GAG/a, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, et a href=http://www.gnu.org/software/grub/;GRUB/a. p Index: ./hu/faq4.html === RCS file: /cvs/www/faq/hu/faq4.html,v retrieving revision 1.29 diff -u -p -r1.29 faq4.html --- ./hu/faq4.html10 May 2006 21:50:16 - 1.29 +++ ./hu/faq4.html5 Mar 2010 19:47:26 - @@ -2085,7 +2085,8 @@ arra, hogy a m?sodik merevlemezr?l t?lts Az OpenBSD felhaszn?l?k sok egy?b rendszerbet?lt?t haszn?lnak sikeresen, mint pl. a a href=http://gag.sourceforge.net/;GAG/a, -a href=http://www.ranish.com/part/;The Ranish Partition Manager/a +a href=http://www.ranish.com/part/;The Ranish Partition Manager/a, +a href=http://refit.sourceforge.net/;rEFIt/a, ?s a a href=http://www.gnu.org/software/grub/;GRUB/a. p Index: ./nl/faq4.html === RCS file:
SiS 7002 lockup using USB2.0 'legacy' mode
Hi,
I get a complete lock-up while booting during initialisation of my
SIS7002 EHCI controller.
When enabling USB2.0 support, but disabling 'legacy' mode everything
is fine. I just can't use my usb keyboard to talk to the boot prompt.
When I enable legacy mode, but set USB2.0 to 'FullSpeed' I just get
this:
ehci0: timed out waiting for BIOS
I had a look at the source, but don't really get it whether this is
bad. I could not find corresponding code in the Linux kernel.
It seems to be about handing over the host controler to the OS after
the bios used it for 'legacy' mode. Why is this only needed for
USB2.0? I thought my keyboard and mouse were USB1.0 devices!?
When I enable legacy mode and set USB2.0 to 'HighSpeed' I get the
above message and the kernel locks up completely.
I added some DPRINTF()s to the relevant sections. (See below)
The strange thing is that the last thing the kernel prints out is
ehci: before loop
so the kernel manages to do the printf, but doesn't manage to do the
funtion call to usb_delay_ms and another printf.
Now I had a look at the linux ehci driver, because with knoppix I have
no problems using USB2.0. You can find the corresponding section of
the linux driver below.
The linux kernel protects itself by write-locking the call to
ehci_writel, but I have no clue what this means and no clue how to
achieve this in OpenBSD. The call to down_write() seems to lock a
semaphore. Any help to fix this is appreciated.
Christopher
P.S.
Another interesting observation: When removing my AGB graphics adaptor
and using the onboard graphics chip I have no problems with USB at
all.
= LINUX =
drivers/usb/host/ehci-hcd.c:662
/*
* Start, enabling full USB 2.0 functionality ... usb 1.1 devices
* are explicitly handed to companion controller(s), so no TT is
* involved with the root hub. (Except where one is integrated,
* and there's no companion controller unless maybe for USB OTG.)
*
* Turning on the CF flag will transfer ownership of all ports
* from the companions to the EHCI controller. If any of the
* companions are in the middle of a port reset at the time, it
* could cause trouble. Write-locking ehci_cf_port_reset_rwsem
* guarantees that no resets are in progress. After we set CF,
* a short delay lets the hardware catch up; new resets shouldn't
* be started before the port switching actions could complete.
*/
down_write(ehci_cf_port_reset_rwsem);
hcd-state = HC_STATE_RUNNING;
ehci_writel(ehci, FLAG_CF, ehci-regs-configured_flag);
ehci_readl(ehci, ehci-regs-command); /* unblock posted writes */
msleep(5);
up_write(ehci_cf_port_reset_rwsem);
ehci-last_periodic_enable = ktime_get_real();
= OpenBSD ===
dev/usb/ehci.c:505
/* Take over port ownership */
EOWRITE4(sc, EHCI_CONFIGFLAG, EHCI_CONF_CF);
DPRINTFN(2, (ehci: before loop\n));
/* LOCKUP HAPPENS HERE */
for (i = 0; i 100; i++) {
usb_delay_ms(sc-sc_bus, 1);
DPRINTFN(2, (ehci: after sleep %d\n, i));
= OpenBSD
dev/usb/usb_subr.c:336
/* Delay for a certain number of ms */
void
usb_delay_ms(usbd_bus_handle bus, u_int ms)
{
/* Wait at least two clock ticks so we know the time has passed. */
if (bus-use_polling || cold) {
DPRINTF((usb_delay_ms: delaying for %u ms\n, ms));
delay((ms+1) * 1000);
}
else {
DPRINTF((usb_delay_ms: tsleeping for %u ms\n, ms));
tsleep(ms, PRIBIO, usbdly, (ms*hz+999)/1000 + 1);
}
}
==
dmesg with 'legacy' turned on, but only 'FullSpeed':
OpenBSD 4.7 (sys) #6: Sun Mar 7 16:14:48 CET 2010
madro...@pundit:/var/obj/sys
real mem = 1071841280 (1022MB)
avail mem = 1031872512 (984MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf04b0 (57 entries)
bios0: vendor American Megatrends Inc. version 0603 date 03/31/2006
bios0: ASUSTeK Computer INC. K8S-MV-P
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC OEMB
acpi0: wakeup devices PS2K(S4) PS2M(S4) EUSB(S4) USB_(S4) USB2(S4) USB3(S4)
AC97(S4) MC97(S4) PCI1(S4) PCI2(S4) MAC_(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Sempron(tm) Processor 3000+, 1795.72 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 128KB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: AMD erratum 89 present, BIOS upgrade may be required
cpu0: apic clock running at 199MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 14, 24
i386 bsd.rd snapshot ftp set install error
I downloaded a snapshot i386 bsd.rd this morning to update a box. Things are OK until I try to install sets via ftp or http. I get this error: No such file or directory. The installer then asks for the location of sets again (looping). It's looking for path [pub/OpenBSD/4.7/i386] by default. I've tried ftp5.usa.openbsd.org as well as ftp.openbsd.org. It's probably user error, just wanted to let @tech know. Brad
Re: i386 bsd.rd snapshot ftp set install error
I downloaded a snapshot i386 bsd.rd this morning to update a box. Things are OK until I try to install sets via ftp or http. I get this error: No such file or directory. The installer then asks for the location of sets again (looping). It's looking for path [pub/OpenBSD/4.7/i386] by default. I've tried ftp5.usa.openbsd.org as well as ftp.openbsd.org. It's probably user error, just wanted to let @tech know. There is nothing surprising here at all. This happens late in every release cycle, and you are not paying attention.
Re: i386 bsd.rd snapshot ftp set install error
On Sun, 07 Mar 2010 10:52 -0700, Theo de Raadt dera...@cvs.openbsd.org wrote: I downloaded a snapshot i386 bsd.rd this morning to update a box. Things are OK until I try to install sets via ftp or http. I get this error: No such file or directory. The installer then asks for the location of sets again (looping). It's looking for path [pub/OpenBSD/4.7/i386] by default. I've tried ftp5.usa.openbsd.org as well as ftp.openbsd.org. It's probably user error, just wanted to let @tech know. There is nothing surprising here at all. This happens late in every release cycle, and you are not paying attention. Yes. My fault. Sorry for the noise. I'm working now. Brad
Re: SiS 7002 lockup using USB2.0 'legacy' mode
On Sun, 7 Mar 2010 17:24:07 +0100 Christopher Zimmermann madro...@zakweb.de wrote: Hi, I get a complete lock-up while booting during initialisation of my SIS7002 EHCI controller. When enabling USB2.0 support, but disabling 'legacy' mode everything is fine. I just can't use my usb keyboard to talk to the boot prompt. When I enable legacy mode, but set USB2.0 to 'FullSpeed' I just get this: ehci0: timed out waiting for BIOS I had a look at the source, but don't really get it whether this is bad. I could not find corresponding code in the Linux kernel. It seems to be about handing over the host controler to the OS after the bios used it for 'legacy' mode. Why is this only needed for USB2.0? I thought my keyboard and mouse were USB1.0 devices!? When I enable legacy mode and set USB2.0 to 'HighSpeed' I get the above message and the kernel locks up completely. I added some DPRINTF()s to the relevant sections. (See below) The strange thing is that the last thing the kernel prints out is ehci: before loop so the kernel manages to do the printf, but doesn't manage to do the funtion call to usb_delay_ms and another printf. Now I had a look at the linux ehci driver, because with knoppix I have no problems using USB2.0. You can find the corresponding section of the linux driver below. The linux kernel protects itself by write-locking the call to ehci_writel, but I have no clue what this means and no clue how to achieve this in OpenBSD. The call to down_write() seems to lock a semaphore. Any help to fix this is appreciated. Christopher P.S. Another interesting observation: When removing my AGB graphics adaptor and using the onboard graphics chip I have no problems with USB at all. The x86 BIOS sucks to begin with, and worse, the use of various terms is highly inconsistent... In other words, take this with a grain of salt, if not a whole shaker of salt, tequila and a lime. When you enable Legacy Mode in the BIOS of many systems, you're actually telling the system to find and use the keyboard and mouse on serial ports (includng PS/2 and similar ports). Of course, this means if you're actually using USB based keyboard/mouse and you've turned on Legacy Mode, you've just made a real mess. --The system believes it does not have a keyboard or mouse attached because it does not find them where you told it to find them (serial). Is the kernel locked up? --Possibly No. The kernel may be ignoring the USB mouse/keyboard that you specifically told the bios to ignore by turning on Legacy Mode. When the BIOS tells the kernel that it has no mouse or keyboard installed, then the kernel thinks, Ah, we're running headless, and adjusts accordingly. jcr
Re: SiS 7002 lockup using USB2.0 'legacy' mode
On Sun, 7 Mar 2010 12:49:00 -0800 J.C. Roberts wrote: On Sun, 7 Mar 2010 17:24:07 +0100 Christopher Zimmermann madro...@zakweb.de wrote: Hi, I get a complete lock-up while booting during initialisation of my SIS7002 EHCI controller. When enabling USB2.0 support, but disabling 'legacy' mode everything is fine. I just can't use my usb keyboard to talk to the boot prompt. When I enable legacy mode, but set USB2.0 to 'FullSpeed' I just get this: ehci0: timed out waiting for BIOS I had a look at the source, but don't really get it whether this is bad. I could not find corresponding code in the Linux kernel. It seems to be about handing over the host controler to the OS after the bios used it for 'legacy' mode. Why is this only needed for USB2.0? I thought my keyboard and mouse were USB1.0 devices!? When I enable legacy mode and set USB2.0 to 'HighSpeed' I get the above message and the kernel locks up completely. I added some DPRINTF()s to the relevant sections. (See below) The strange thing is that the last thing the kernel prints out is ehci: before loop so the kernel manages to do the printf, but doesn't manage to do the funtion call to usb_delay_ms and another printf. Now I had a look at the linux ehci driver, because with knoppix I have no problems using USB2.0. You can find the corresponding section of the linux driver below. The linux kernel protects itself by write-locking the call to ehci_writel, but I have no clue what this means and no clue how to achieve this in OpenBSD. The call to down_write() seems to lock a semaphore. Any help to fix this is appreciated. Christopher P.S. Another interesting observation: When removing my AGB graphics adaptor and using the onboard graphics chip I have no problems with USB at all. The x86 BIOS sucks to begin with, and worse, the use of various terms is highly inconsistent... In other words, take this with a grain of salt, if not a whole shaker of salt, tequila and a lime. When you enable Legacy Mode in the BIOS of many systems, you're actually telling the system to find and use the keyboard and mouse on serial ports (includng PS/2 and similar ports). Of course, this means if you're actually using USB based keyboard/mouse and you've turned on Legacy Mode, you've just made a real mess. --The system believes it does not have a keyboard or mouse attached because it does not find them where you told it to find them (serial). ok, you misunderstood me. My BIOS needs 'legacy' to be turned on to use the USB-keyboard. Thats actually consistent with the BSD terminology in dev/usb/ehcireg.h. See the EHCI_LEGSUP_* and dev/pci/ehci_pci.c: ehci_pci_takecontroller() Is the kernel locked up? --Possibly No. The kernel may be ignoring the USB mouse/keyboard that you specifically told the bios to ignore by turning on Legacy Mode. When the BIOS tells the kernel that it has no mouse or keyboard installed, then the kernel thinks, Ah, we're running headless, and adjusts accordingly. the kernel stops while booting. Read my orignal post again. I found the very line of code causing this problem, but still don't know exactly how to fix it. Christopher
faq14.html
Initially, I just wanted to fix the use create typo, but decided to make it shorter, more accurate, and more clear in the process. Index: faq14.html === RCS file: /cvs/www/faq/faq14.html,v retrieving revision 1.198 diff -N -u -p faq14.html --- faq14.html 4 Mar 2010 01:14:13 - 1.198 +++ faq14.html 7 Mar 2010 22:17:07 - @@ -2274,10 +2274,9 @@ You will, of course, be unable to test your work until USB bootable system. libGoing from IDE to USB interfaces:/b -As the media will be readable and writable from both USB and IDE -adapters, you can use create the media for booting in an IDE adapter but -maintain it in a USB adapter on a different machine (or the other way -around). +Since flash media can be readable and writable through USB, IDE and +other adapters, you can create bootable media with one type of adapter +but maintain or use it with another type of adapter. libMixing OpenBSD and other partitions on one device:/b OpenBSD treats the flash disk as any other disk so one can use
