WRAP.1E and geode.c
Reading geode.c it appears (at least to me) that the led devices are
created for the WRAP.1C but not for the WRAP.1E.
Guessing from the dmesg output
$ dmesg
Copyright (c) 1992-2004 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 5.3-RELEASE #0: Sun Mar 20 17:12:36 CET 2005
[EMAIL PROTECTED]:/m0n0wall/kernels/wrap
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Geode(TM) Integrated Processor by National Semi (266.65-MHz 586-class
CPU)
Origin = "Geode by NSC" Id = 0x540 Stepping = 0
Features=0x808131
real memory = 134217728 (128 MB)
avail memory = 109277184 (104 MB)
npx0: [FAST]
npx0: on motherboard
npx0: INT 16 interface
pcib0: pcibus 0 on motherboard
pci0: on pcib0
sis0: port 0x1000-0x10ff mem
0x8000-0x8fff irq 10 at device 14.0 on pci0
sis0: Silicon Revision: DP83816A
miibus0: on sis0
ukphy0: on miibus0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sis0: Ethernet address: 00:0d:b9:01:12:04
sis1: port 0x1400-0x14ff mem
0x8004-0x80040fff irq 9 at device 15.0 on pci0
sis1: Silicon Revision: DP83816A
miibus1: on sis1
ukphy1: on miibus1
ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sis1: Ethernet address: 00:0d:b9:01:12:05
sis2: port 0x1800-0x18ff mem
0x8008-0x80080fff irq 11 at device 16.0 on pci0
sis2: Silicon Revision: DP83816A
miibus2: on sis2
ukphy2: on miibus2
ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
sis2: Ethernet address: 00:0d:b9:01:12:06
Geode GPIO@ = f400
isab0: port 0xf600-0xf63f,0xf400-0xf43f at device 18.0 on
pci0
isa0: on isab0
pci0: at device 18.1 (no driver attached)
atapci0: port
0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 18.2 on pci0
ata0: channel #0 on atapci0
pci0: at device 18.3 (no driver attached)
* Geode CBA@ 0x9000
* Geode rev: 06 03
Timecounter "Geode" frequency 2700 Hz quality 1000
pci0: at device 18.5 (no driver attached)
cpu0 on motherboard
pmtimer0 on isa0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0
sio0: type 16550A, console
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
Timecounters tick every 1.000 msec
Fast IPsec: Initialized Security Association Processing.
IP Filter: v3.4.35 initialized. Default = block all, Logging = enabled
md0: Preloaded image 16777216 bytes at 0xc0740624
ad0: FAILURE - SETFEATURES ENABLE RCACHE status=51
error=4
ad0: FAILURE - SETFEATURES DISABLE WCACHE status=51
error=4
ad0: 15MB [490/2/32] at ata0-master PIO4
Mounting root from ufs:/dev/md0
ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to
accept, logging disabled
I'd say the WRAP.1E has a PCI device ID 0x0515100b as it falls in
the first if-branch of the following code (from geode.c):
static int
geode_probe(device_t self)
{
if (pci_get_devid(self) == 0x0515100b) {
if (geode_counter == 0) {
/*
* The address of the CBA is written to this register
* by the bios, see p161 in data sheet.
*/
cba = pci_read_config(self, 0x64, 4);
printf("Geode CBA@ 0x%x\n", cba);
geode_counter = cba + 0x08;
outl(cba + 0x0d, 2);
printf("Geode rev: %02x %02x\n",
inb(cba + 0x3c), inb(cba + 0x3d));
tc_init(&geode_timecounter);
EVENTHANDLER_REGISTER(watchdog_list, geode_watchdog,
NULL, 0);
}
} else if (pci_get_devid(self) == 0x0510100b) {
gpio = pci_read_config(self, PCIR_BAR(0), 4);
gpio &= ~0x1f;
printf("Geode GPIO@ = %x\n", gpio);
if (NULL !=
bios_string(0xf, 0xf0100, "Soekris Engineering", 0)) {
printf("Soekris Engineering NET4801 platform\n");
led1b = 20;
led1 = led_create(led_func, &led1b, "error");
} else if (NULL !=
bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C ", 0)) {
printf("PC Engines WRAP.1C platfrom\n");
led1b = -2;
led2b = -3;
led3b = -18;
led1 = led_create(led_func, &led1b, "led1");
led2 = led_create(led_func, &led2b, "led2");
led3 = led_create(led_func, &led3b, "led3");
/*
Re: WRAP.1E and geode.c
Larry Baird writes:
> In article <[EMAIL PROTECTED]> you wrote:
> > Reading geode.c it appears (at least to me) that the led devices are
> > created for the WRAP.1C but not for the WRAP.1E.
> >
> > Reading the PC-Engines documentation it looks to me as WRAP.1C and
> > WRAP1.E were identical when it comes to the LEDs, thus it would be
> > nice to have the same entries in /dev.
> >
> > Anyone with a better understanding of this platform cares to comment
> > on this?
> The BIOS id string on the wrap board has changed. Following patch
> for geode.c should fix the problem.
>
> Larry
>
> --- geode.c.orig Fri May 20 09:41:06 2005
> +++ geode.c Fri May 20 09:42:09 2005
> @@ -145,7 +145,8 @@
> led1b = 20;
> led1 = led_create(led_func, &led1b, "error");
> } else if (NULL !=
> -bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C ", 0)) {
> +#define WRAP_BIOS_SIGNATURE "PC Engines WRAP"
> +bios_string(0xf9000, 0xf9000, WRAP_BIOS_SIGNATURE,
> sizeof(WRAP_BIOS_SIGNATURE - 1))) {
> printf("PC Engines WRAP.1C platfrom\n");
> led1b = -2;
> led2b = -3;
Are you sure about that?
Suspecting my original guessing was wrong, I took the time, while my
message was put on hold by the moderator, to make some experiments. I
changed the aforementioned string into:
"PC Engines WRAP"
and then
"PC Engines"
but no luck.
So either the string changed address or it's something totally
different from the original.
--
walter pelissero
http://www.pelissero.de
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WRAP.1E and geode.c
Larry Baird writes:
> In article <[EMAIL PROTECTED]> you wrote:
> > Reading geode.c it appears (at least to me) that the led devices are
> > created for the WRAP.1C but not for the WRAP.1E.
> >
> > Reading the PC-Engines documentation it looks to me as WRAP.1C and
> > WRAP1.E were identical when it comes to the LEDs, thus it would be
> > nice to have the same entries in /dev.
> >
> > Anyone with a better understanding of this platform cares to comment
> > on this?
> The BIOS id string on the wrap board has changed. Following patch
> for geode.c should fix the problem.
Some more good old trial-and-error activity let me come up with the
answer to my problem. The BIOS id string has indeed moved. The
following patch makes geode.c play nicely with newer versions of the
WARP boards:
--- geode.c 16 Jun 2004 09:47:07 - 1.5
+++ geode.c 20 May 2005 15:42:28 -
@@ -145,8 +145,8 @@
led1b = 20;
led1 = led_create(led_func, &led1b, "error");
} else if (NULL !=
- bios_string(0xf9000, 0xf9000, "PC Engines WRAP.1C ", 0)) {
- printf("PC Engines WRAP.1C platfrom\n");
+ bios_string(0xf9000, 0xf9010, "PC Engines WRAP", 0)) {
+ printf("PC Engines WRAP platfrom\n");
led1b = -2;
led2b = -3;
led3b = -18;
If no one has objections I'd file a PR.
--
walter pelissero
http://www.pelissero.de
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Tyan S2460 and btx.S
Apparently FreeBSD 5.x is neither able to power off nor reset a Tyan Tiger MP (S2460) motherboard. I believe it's a known problem. While the power off may be due to a broken ACPI the reset can be fixed. Revision 1.33 log of /sys/boot/i386/btx/btx/btx.S says: date: 2003/11/16 18:24:23; author: phk; state: Exp; lines: +1 -1 When rebooting the machine jump to 0xf000:0xfff0 instead of 0x:0x0. While we end up the same place, we end up with two different CS register values after the jump and 0xf000 is compatible with the hardware reset value. This makes a difference if the BIOS does a near jump before a far jump. Detective work and patch by: Adrian Steinmann <[EMAIL PROTECTED]> I tried reverting the patch and now the Tyan motherboard seems to reset as expected. My knowledge of the PC architecture intricacies is not good enough to discuss the merits of revision 1.33 patch, but I believe it could be worth having an ifdef-ed code in btx.S to accommodate motherboards like this one. -- walter pelissero http://www.pelissero.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
beastie.4th and SMP
I was wondering if anybody would care for a beastie.4th that included a boot option which turns off SMP. I personally believe it could make sense where a SMP bug or a faulty MP motherboard made a boot impossible. It would be easier than having to open up the box and remove a CPU. I personally use the following patch to switch conveniently SMP-mode on and off when I need to try DRI/DRM, which doesn't work with SMP. -- walter pelissero http://www.pelissero.de *** /boot/beastie.4th.orig Tue Aug 23 17:44:44 2005 --- /boot/beastie.4th Tue Aug 23 18:06:36 2005 *** *** 44,49 --- 44,50 variable bootsafekey variable bootverbosekey variable bootsinglekey + variable bootnosmpkey variable escapekey variable rebootkey *** *** 161,166 --- 162,168 then printmenuitem ." Boot FreeBSD in Safe Mode" bootsafekey ! printmenuitem ." Boot FreeBSD in single user mode" bootsinglekey ! + printmenuitem ." Boot FreeBSD in non-SMP mode" bootnosmpkey ! printmenuitem ." Boot FreeBSD with verbose logging" bootverbosekey ! printmenuitem ." Escape to loader prompt" escapekey ! s" arch-i386" environment? if *** *** 258,263 --- 260,269 then dup bootsinglekey @ = if s" YES" s" boot_single" setenv + 0 boot + then + dup bootnosmpkey @ = if + s" 1" s" kern.smp.disabled" setenv 0 boot then dup escapekey @ = if ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
xmovie 1.5.2 for FreeBSD
I just recently ported xmovie 1.5.2 to FreeBSD 4.0. The patch file can be found at my home page http://www.pelissero.org. It's rather big (80K) because it can be considered a fix patch for the Linux version as well. Among the other bugs, the code relied on a (sort of) misbehavior of the Linux pthreads implementation (GNU?) that allows a thread to unlock a mutex locked by another thread. I'm working on the CSS code that still doesn't work (I guess it didn't even under Linux). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SVR4 missing syscall
I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS (invalid system call) at the very beginning. Here is the kdump: 39525 ktrace RET ktrace 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x1,0x28061000,0x28061010) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL sigprocmask(0x3,0x28061010,0) 39525 ktrace RET sigprocmask 0 39525 ktrace CALL execve(0xbfbff9a3,0xbfbff880,0xbfbff88c) 39525 ktrace NAMI "./scobin" 39525 ktrace NAMI "/compat/svr4/usr/lib/libc.so.1" 39525 scobin RET execve 0 39525 scobin CALL getuid 39525 scobin RET getuid 1001/0x3e9 39525 scobin CALL getuid 39525 scobin RET getuid 1001/0x3e9 39525 scobin CALL getgid 39525 scobin RET getgid 0 39525 scobin CALL getgid 39525 scobin RET getgid 0 39525 scobin CALL setlogin(0x72,0x805056c) 39525 scobin RET setlogin 0 39525 scobin CALL setlogin(0x28,0x280a9764) 39525 scobin RET setlogin 0 39525 scobin CALL break(0x8051580) 39525 scobin RET break 0 39525 scobin CALL setlogin(0x68,0x8049830) 39525 scobin RET setlogin 0 39525 scobin CALL getpid 39525 scobin RET getpid 39525/0x9a65 39525 scobin CALL old.lstat 39525 scobin PSIG SIGSYS SIG_DFL 39525 scobin NAMI "scobin.core" Which call is it about? I see an "old.lstat" but I couldn't find any reference in the kernel source tree. Is there any doc I could read to see if I can hack this syscall in the emulator? Thanks, -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 missing syscall
Mark Newton writes: > On Mon, Nov 20, 2000 at 05:05:39PM +0000, Walter C. Pelissero wrote: > > > I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS > > (invalid system call) at the very beginning. Here is the kdump: > > Which call is it about? I see an "old.lstat" but I couldn't find any > > reference in the kernel source tree. Is there any doc I could read to > > see if I can hack this syscall in the emulator? > > It's syscall 40, which is from XENIX. Yay, Microsoft UNIX :-) > > Do you know what the system call is supposed to actually do? No idea, sorry. > With that info I can update the emulation to include it. I wish I could do it for you. If only someone could give me the right hints on how to hack the IBCS2. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 missing syscall
Dan Nelson writes: > In the last episode (Nov 20), Walter C. Pelissero said: > > I'm trying to run a SCO SVR4 executable on FreeBSD but I get a SIGSYS > > (invalid system call) at the very beginning. Here is the kdump: > > > > Which call is it about? I see an "old.lstat" but I couldn't find any > > reference in the kernel source tree. Is there any doc I could read > > to see if I can hack this syscall in the emulator? > > old.lstat is syscall #40, which is the ibcs2_xenix syscall on SCO. May I ask you where you got this information from? I was grep-ing around in the kernel source tree but I couldn't figure out that this old.lstat is syscall #40, let alone that it was a Xenix syscall. Is there any doc that can help me hacking this syscall into the ibcs2 emulator? > You can add hooks from the svr4 emulation code back to the ibcs2 > code, but the svr4 module was really written for Solaris x86 > instead of SCO. You'll have to make a lot of changes to get SCO > binaries to run under it. I tried to get an SCO SVR4 binary to > work about 6 months ago but gave up and simply got the vendor to > send me a Linux binary instead. Runs fine under the Linuxulator :) Are you telling me that the IBCS emulator is not really working? Unfortunately I can't ask for a Linux version. Have you ever had a look at the NetBSD one? Is it usable? Thanks for your help. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCMCIA hot swap
Having recently upgraded from 4.0 to 4.3 on my laptop I've noticed that PCMCIA insertion and extraction doesn't work as it used to. The system (Vaio PCG-XG9) just freezes. Some time I'm able to rescue the situation inserting and extracting several times the offending card. Some time I have to power off and reboot. Normally, if a card is insert before the bootstrap it's correctly detected and configured. My question is: "Has the hot swap feature been somehow dropped from the PCCARD code?" -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCMCIA hot swap
As suggested it was a problem with the new polling mode. Assigning an interrupt to the pcic0 controller solved the problem. Thanks to Warner Losh and Ian Dowse. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
4.4-RC NFS panic
[ it seems my original article didn't get through ]
I recently upgraded to 4.4-RC.
Now my Vaio panics when I use NFS volumes (as client).
The panic is reproducible with a:
find /some/NFS/mount/point -type f -exec cat {} \; >/dev/null
Sometime I got a "page fault", sometime a "lockmgr: locking against myself"
Here is a kgdb session:
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
Reading symbols from kernel.debug...done.
IdlePTD 3612672
initial pcb at 2bb8a0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x33693d55
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc016dbdd
stack pointer = 0x10:0xc7834c58
frame pointer = 0x10:0xc7834c64
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 180 (nfsiod)
interrupt mask = net
trap number = 12
panic: page fault
syncing disks... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
done
Uptime: 3m58s
dumping to dev #ad/0x30001, offset 272736
dump ata0: resetting devices .. done
127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107
106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81
80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52
51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23
22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../kern/kern_shutdown.c:472
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:472
#1 0xc015250f in boot (howto=256) at ../../kern/kern_shutdown.c:312
#2 0xc01528dc in poweroff_wait (junk=0xc027b66c, howto=-1071140465)
at ../../kern/kern_shutdown.c:580
#3 0xc023b4b2 in trap_fatal (frame=0xc7834c18, eva=862534997)
at ../../i386/i386/trap.c:956
#4 0xc023b185 in trap_pfault (frame=0xc7834c18, usermode=0, eva=862534997)
at ../../i386/i386/trap.c:849
#5 0xc023ad6f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = 6684672, tf_esi = 862534981, tf_ebp = -947696540,
tf_isp = -947696572, tf_ebx = 862534981, tf_edx = 6684672,
tf_ecx = -1066162108, tf_eax = 6684672, tf_trapno = 12, tf_err = 0,
tf_eip = -1072243747, tf_cs = 8, tf_eflags = 66054,
tf_esp = -1066172160, tf_ss = -1066172160}) at ../../i386/i386/trap.c:448
#6 0xc016dbdd in m_freem (m=0x33693d45) at ../../kern/uipc_mbuf.c:618
#7 0xc016dbfc in m_freem (m=0xc0738a00) at ../../kern/uipc_mbuf.c:618
#8 0xc0b59652 in ?? ()
#9 0xc0b66b92 in ?? ()
#10 0xc0b3fe37 in ?? ()
#11 0xc0b606de in ?? ()
#12 0xc0b5f11b in ?? ()
#13 0xc023b75d in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936680, tf_esi = 0, tf_ebp = -1077936776,
tf_isp = -947695660, tf_ebx = 2, tf_edx = 1, tf_ecx = 19, tf_eax = 155,
tf_trapno = 12, tf_err = 2, tf_eip = 134515664, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077936852, tf_ss = 47})
at ../../i386/i386/trap.c:1155
#14 0xc022fae5 in Xint0x80_syscall ()
#15 0x8048135 in ?? ()
(kgdb)
--
walter pelissero
http://www.pelissero.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
4.4-RC freezes during boot
Upgrading to 4.4-RC a couple of new problems have shown up on my laptop (Vaio PCG-XG9). Beside the already mentioned NFS panic (see freebsd-hackers or freebsd-net), now the bootstrap phase freezes somewhere after: pcic1: Event mask 0x9 The system seems to be frozen beside that if I remove or insert the PCMCIA card on that slot I see appear messages of the same type (sometime the mask is 0x4 or 0x2). If I switch off the machine (Ctrl-Alt-DEL doesn't work) and then on, usually the problem goes away. I couldn't figure out if the problem is really in the PCCARD driver, but you may be interested to know that usually after that message, during a successful bootstrap, I see this one: ata1-slave: ata_command: timeout waiting for intr Another problem after the upgrade to 4.4-RC has been a "broken" sound coming from the speakers. At boot time the driver says: pcm0: port 0xfc8c-0xfc8f,0xfcc0-0xfcff mem 0xfedf8000-0xfedf irq 9 at device 9.0 on pci0 The playing of MP3 files seems to be all right, but the playing of mono wav files often results in a small gap short after the beginning of the sound. This problem wasn't there in 4.3-STABLE. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.4-RC NFS panic
[ third time I retry to post this message on the mailing list ]
Peter Pentchev writes:
> On Mon, Aug 20, 2001 at 12:27:24PM +0100, Walter C. Pelissero wrote:
> All those ??'s are the result of kgdb being unable to look inside
> a kernel module. Are you loading NFS as a module?
Yep. I recompiled a kernel with almost all modules linked in. I
forgot some of them but I guess those don't hurt.
Now kldstat says:
Id Refs AddressSize Name
14 0xc010 298698 kernel
21 0xc0399000 30e0 splash_bmp.ko
31 0xc039d000 5458 vesa.ko
41 0xc0b63000 19000usb.ko
The panic is still easily reproducible and therefore I've got some
more details to show you:
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
Reading symbols from kernel.debug...done.
IdlePTD 4009984
initial pcb at 311680
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x65746e69
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc028782e
stack pointer = 0x10:0xc780bccc
frame pointer = 0x10:0xc780bd08
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 179 (nfsiod)
interrupt mask = none
trap number = 12
panic: page fault
syncing disks... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
done
Uptime: 3m35s
dumping to dev #ad/0x30001, offset 272736
dump ata0: resetting devices .. done
127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107
106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81
80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52
51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23
22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../kern/kern_shutdown.c:472
472 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:472
#1 0xc0159b17 in boot (howto=256) at ../../kern/kern_shutdown.c:312
#2 0xc0159ee4 in poweroff_wait (junk=0xc02cd40c, howto=-1070805201)
at ../../kern/kern_shutdown.c:580
#3 0xc0289002 in trap_fatal (frame=0xc780bc8c, eva=1702129257)
at ../../i386/i386/trap.c:956
#4 0xc0288cd5 in trap_pfault (frame=0xc780bc8c, usermode=0, eva=1702129257)
at ../../i386/i386/trap.c:849
#5 0xc02888bf in trap (frame={tf_fs = 16, tf_es = -1019805680,
tf_ds = -1062076400, tf_edi = -1003117116, tf_esi = 1702129257,
tf_ebp = -947864312, tf_isp = -947864392, tf_ebx = 6716,
tf_edx = -947864124, tf_ecx = 1679, tf_eax = 1589720923, tf_trapno = 12,
tf_err = 0, tf_eip = -1071089618, tf_cs = 8, tf_eflags = 66066,
tf_esp = 1397686380, tf_ss = 6716}) at ../../i386/i386/trap.c:448
#6 0xc028782e in generic_bcopy ()
#7 0xc01f994a in nfs_readrpc (vp=0xc78dc300, uiop=0xc780bdc4, cred=0xc0bc9d80)
at ../../nfs/nfs_vnops.c:1118
#8 0xc01d3393 in nfs_doio (bp=0xc3373e60, cr=0xc0bc9d80, p=0x0)
at ../../nfs/nfs_bio.c:1410
#9 0xc01f348e in nfssvc_iod (p=0xc77baf20) at ../../nfs/nfs_syscalls.c:970
#10 0xc01f1ed3 in nfssvc (p=0xc77baf20, uap=0xc780bf80)
at ../../nfs/nfs_syscalls.c:166
#11 0xc02892ad in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936680, tf_esi = 0, tf_ebp = -1077936776,
tf_isp = -947863596, tf_ebx = 2, tf_edx = 1, tf_ecx = 19, tf_eax = 155,
tf_trapno = 12, tf_err = 2, tf_eip = 134515664, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077936852, tf_ss = 47})
at ../../i386/i386/trap.c:1155
#12 0xc027d635 in Xint0x80_syscall ()
#13 0x8048135 in ?? ()
Side note. I experienced another panic not directly related to NFS.
During a high resolution print of a big image (something around 30MB
postscript file) on a remote host (the NFS server) I got a panic,
which might suggest the problem (if related) is in a deeper level than
NFS. The remote printing panic is not so easy to reproduce so I gave
up on that front.
A nicer remark. The NFS server is up and running with a 4.4-RC (the
same as my Vaio) since Friday without a single problem. I'm currently
using a 4.3-STABLE and I don't get a panic whatsoever, so I assume the
hardware is still all right.
--
walter pelissero
http://www.pelissero.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.4-RC NFS panic
John Baldwin writes: > > fault virtual address = 0x65746e69 > "etni" > > Looks like a string has gotten spammed across a data structure or a > weird pointer, etc. Whatever mess happend, I've got some news for you that should remove the NFS module from the list of possible causes. Currently I'm running an old 4.3-STABLE kernel and kldstat shows: Id Refs AddressSize Name 16 0xc000 4000 kernel 21 0xc0ae d000 msdos.ko 31 0xc0b0f000 6000 procfs.ko 41 0xc0b18000 4000 kernfs.ko 51 0xc0b3b000 4d000nfs.ko <--- ! 61 0xc0bae000 12000linux.ko That is, since my /modules is new, I've loaded the brand new 4.4-RC's NFS module, and it works without a glitch (at least for now). This enforces my belief that there is something broken in some deeper layer of the network code (see the remote printing issue). The time stamp of the older kernel is -r-xr-xr-x 1 root wheel 2408052 Jul 29 15:19 /kernel.good It's a pretty long period (almost a month) but maybe is possible to track down the mods to the network code till now. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.4-RC NFS panic
David Malone writes: > On Mon, Aug 20, 2001 at 07:51:17PM +0100, Walter C. Pelissero wrote: > > This enforces my belief that there is something broken in some deeper > > layer of the network code (see the remote printing issue). > > Just out of curiosity, what sort of network card is your Vaio using? > Someone else is seeing network related panics that might be related > to freeing an mbuf that's in use, and it's possible this might be > related. Mmmm, you might be right. I'm using a 3com 589, therefore I'm using the ep driver. Unfortunately I don't have a different PCMCIA network card at hand, but I can try to reverse the crash test with my server. Yes, the server is running exactly the same version (4.4-RC) but uses the de driver. So I did and, guess what, the find/cat test on my server over an NFS mounted directory from my Vaio ran without a problem. I've just done a further test. I've mounted a directory tree from Vaio to Vaio using localhost (lo driver) and the test has run smoothly. So chances would be good the bug is in the ep driver. Unfortunately... $ ls -l /sys/dev/ep total 70 -rw-r--r-- 1 root wheel 23554 Jul 17 2000 if_ep.c -rw-r--r-- 1 root wheel 6202 Jan 14 2000 if_ep_eisa.c -rw-r--r-- 1 root wheel 10046 Dec 16 2000 if_ep_isa.c -rw-r--r-- 1 root wheel 4584 Oct 27 1999 if_ep_mca.c -rw-r--r-- 1 root wheel 6950 Aug 9 2000 if_ep_pccard.c -rw-r--r-- 1 root wheel 13935 Jan 12 2000 if_epreg.h -rw-r--r-- 1 root wheel 2667 May 24 2000 if_epvar.h none of the modules belonging to the ep driver has been touched for a long time. Side note. Regarding a different problem I've mentioned in freebsd-hackers I've been told 4.4-RC has got problems with the PCCARD code. Whether that can influence the ep driver is beyond my knowledge. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.4-RC NFS panic
Warner Losh writes: > After talking with Ian Dowse, I think that we've hammered out what may > cause this. Basically, the problem is I'm afraid your patch didn't fix the problem on my laptop. It certainly changed the behaviour and the system doesn't crash any more, but I'm almost unable to use the net. A ping to my server yelds the IP address to be resolved but no ping activity is carried on. Even worse, now the pcm driver fails to detect any sound device. 8-| Regarding the warm boot, I can confirm the same behavior (already pointed out in another mail of mine). My impression it's not a PCCARD issue as it happens even with no card inserted. The system looks as frozen but if I press the "Pause" key and then type something and then press again the "Pause" key I get the the cursor moved of the amount of typing I did. No echo though. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Serious i386 interrupt mask bug in RELENG_4 (was Re: 4.4-RC NFS panic)
Ian Dowse writes: > In message <[EMAIL PROTECTED]>, Warner Losh writes: > > > >I think that might be due to a bug in the shared interrupt code that > >Ian Dowse sent me about earlier today. > > Just to add a few details - there is a bug in the update_masks() > function in i386/isa/intr_machdep.c that can cause some interrupts > to occur at times when they should be masked. The problem only > occurs with certain configurations of shared interrupts and devices, > and this code is only present in RELENG_4. Congratulations! I've applied your patch together with the one posted by Warner Losh and now the PCMCIA card is working again and the find/cat test passed without panic. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
tar and nodump flag
How about adding the nodump flag processing in tar?
Something like:
--- /usr/src/gnu/usr.bin/tar/create.c Wed Aug 11 09:03:39 1999
+++ create.cWed Nov 21 13:52:54 2001
@@ -817,6 +817,8 @@
strcpy (namebuf + len, d->d_name);
if (f_exclude && check_exclude (namebuf))
continue;
+ if (hstat.st_flags & UF_NODUMP)
+ continue;
dump_file (namebuf, our_device, 0);
}
Or something like this patch I've submited to the GNU tar mailing
list:
diff -r -u tar-1.13.orig/src/common.h tar-1.13/src/common.h
--- tar-1.13.orig/src/common.h Tue Nov 20 15:04:26 2001
+++ tar-1.13/src/common.h Tue Nov 20 15:14:49 2001
@@ -143,6 +143,9 @@
/* Boolean value. */
GLOBAL int dereference_option;
+/* Boolean value. */
+GLOBAL int honor_nodump_option;
+
/* Patterns that match file names to be excluded. */
GLOBAL struct exclude *excluded;
diff -r -u tar-1.13.orig/src/create.c tar-1.13/src/create.c
--- tar-1.13.orig/src/create.c Tue Nov 20 15:04:25 2001
+++ tar-1.13/src/create.c Tue Nov 20 15:18:14 2001
@@ -1483,6 +1483,12 @@
if (is_dot_or_dotdot (entry->d_name)
|| excluded_filename (excluded, entry->d_name))
continue;
+#ifdef __FreeBSD__
+ /* If file has NODUMP flag set, ignore it. Accordingly skip
+the whole tree under a directory. */
+ if (honor_nodump_option && (current_stat.st_flags & UF_NODUMP))
+ continue;
+#endif
if ((int) NAMLEN (entry) + len >= buflen)
{
diff -r -u tar-1.13.orig/src/tar.c tar-1.13/src/tar.c
--- tar-1.13.orig/src/tar.c Tue Nov 20 15:04:26 2001
+++ tar-1.13/src/tar.c Tue Nov 20 15:21:57 2001
@@ -187,6 +187,7 @@
{"gunzip", no_argument, NULL, 'z'},
{"gzip", no_argument, NULL, 'z'},
{"help", no_argument, &show_help, 1},
+ {"honor-nodump", no_argument, NULL, 'H'},
{"ignore-failed-read", no_argument, &ignore_failed_read_option, 1},
{"ignore-zeros", no_argument, NULL, 'i'},
/* FIXME: --ignore-end as a new name for --ignore-zeros? */
@@ -416,7 +417,7 @@
Y per-block gzip compression */
#define OPTION_STRING \
- "-01234567ABC:F:GK:L:MN:OPRST:UV:WX:Zb:cdf:g:hiklmoprstuvwxz"
+ "-01234567ABC:F:GHK:L:MN:OPRST:UV:WX:Zb:cdf:g:hiklmoprstuvwxz"
static void
set_subcommand_option (enum subcommand subcommand)
@@ -623,6 +624,12 @@
/* Follow symbolic links. */
dereference_option = 1;
+ break;
+
+ case 'H':
+ /* Honor NODUMP flag. */
+
+ honor_nodump_option = 1;
break;
case 'i':
BTW, the ancient GNU tar (1.11.2) FreeBSD has bundled with the system
happens to have a bug that makes it inconvenient with modern tapes.
The tape length (option -L) is stored in a signed integer; a DAT DDS-2
is already too big for that.
I would recommend to upgrade to the new 1.13, which, together with a
brand new set of bugs, introduces the TARLONG type to store such
informations as tape length.
--
walter pelissero
http://www.pelissero.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: tar and nodump flag
David O'Brien writes: > On Wed, Nov 21, 2001 at 02:18:42PM +, Walter C. Pelissero wrote: > > How about adding the nodump flag processing in tar? > > This would be a *bad* idea. It would diverge our tar even more > than it already is -- which is so bad it isn't trival to update to > the latest version (ours is many years behind). Does it mean we can't modify the BSD tar because it's already too different from the GNU tar, but at the same time we don't upgrade to the new GNU tar because it might require too much work adapting the old mods to the new code? Am I wrong or this means the BSD tar code is frozen? Do you have a list of discrepancies (not a diff) between the current BSD tar and the version of GNU tar it's based on? We might find out the new GNU tar doesn't need as much hacking as the old one needs. -- walter pelissero http://www.pelissero.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
apmd fixes
Here are a couple of patches to apmd (as of FreeBSD 4.4-STABLE) to fix
a bug and add a feature necessary on my Vaio PCG-XG9.
The fix is to handle properly termination signals (currently ignored).
The feature is the -s option that lets you fake POWERSTATECHANGE when
the BIOS doesn't report it. This enables you to do fancy things like
reducing the LCD backlight brightness when you unplug the power
supply. Something like this in apmd.conf:
apm_event POWERSTATECHANGE {
exec "/bin/sh /usr/local/bin/my-preferred-power-state-change-script";
}
Here is the patch:
--- /usr/home/wcp/tmp/apmd/apmd.c Fri Oct 12 20:22:34 2001
+++ /usr/src/usr.sbin/apmd/apmd.c Sat Oct 13 14:58:35 2001
@@ -55,7 +55,7 @@
extern int yyparse(void);
intdebug_level = 0;
-intverbose = 0;
+intverbose = 0, soft_power_state_change = 0;
const char *apmd_configfile = APMD_CONFIGFILE;
const char *apmd_pidfile = APMD_PIDFILE;
int apmctl_fd = -1, apmnorm_fd = -1;
@@ -464,7 +464,6 @@
int
proc_signal(int fd)
{
- int rc = -1;
int sig;
while (read(fd, &sig, sizeof sig) == sizeof sig) {
@@ -476,8 +475,7 @@
break;
case SIGTERM:
syslog(LOG_NOTICE, "going down on signal %d", sig);
- rc = 1;
- goto out;
+ return -1;
case SIGCHLD:
wait_child();
break;
@@ -486,9 +484,7 @@
break;
}
}
- rc = 0;
- out:
- return rc;
+ return 0;
}
void
proc_apmevent(int fd)
@@ -548,6 +544,8 @@
* the event-caught state.
*/
if (last_state != AC_POWER_STATE) {
+ if (soft_power_state_change && fork() == 0)
+ exit(exec_event_cmd(&events[PMEV_POWERSTATECHANGE]));
last_state = AC_POWER_STATE;
for (p = battery_watch_list ; p!=NULL ; p = p -> next)
p->done = 0;
@@ -642,7 +640,7 @@
char*prog;
int logopt = LOG_NDELAY | LOG_PID;
- while ((ch = getopt(ac, av, "df:v")) != EOF) {
+ while ((ch = getopt(ac, av, "df:vs")) != EOF) {
switch (ch) {
case 'd':
daemonize = 0;
@@ -653,6 +651,9 @@
break;
case 'v':
verbose = 1;
+ break;
+ case 's':
+ soft_power_state_change = 1;
break;
default:
(void) err(1, "unknown option `%c'", ch);
--
walter pelissero
http://www.pelissero.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
USB -> PS/2
I just bought a USB -> PS/2 keyboard and mouse converter for my
laptop. It's a Sitecom brand and it gets recognised as MCT Corp.
addr 1: UHCI root hub, Intel
addr 2: Generic USB Hub, ALCOR
addr 4: HID-compliant Mouse (USB), Mitsumi
addr 3: PS/2 - USB Interface Adaptor, MCT Corp.
Although the keyboard works, the mouse doesn't. I tried to plug two
types of mice (a Micro$oft 2 buttons and a Trust 3 buttons) but both,
while generating traffic on the USB bus (the converter LED blinks),
don't move the pointer.
This is the usbd log:
uhub1: ALCOR Generic USB Hub, class 9/0, rev 1.10/3.12, addr 2
uhub1: 4 ports with 4 removable, bus powered
ums0: Mitsumi HID-compliant Mouse (USB), rev 1.00/1.10, addr 3, iclass 3/1
ums0: 2 buttons
ukbd0: MCT Corp. PS/2 - USB Interface Adaptor, rev 1.10/1.00, addr 4, iclass 3/1
kbd1 at ukbd0
ums1: MCT Corp. PS/2 - USB Interface Adaptor, rev 1.10/1.00, addr 4, iclass 3/1
ums1: 3 buttons and Z dir.
Moused is there:
179 ?? Ss 0:05.83 /usr/sbin/moused -3 -p /dev/ums0 -I /var/run/moused.ums0.pid
209 ?? Ss 0:05.57 moused -3 -p /dev/psm0 -t auto
237 ?? Is 0:00.01 /usr/sbin/moused -p /dev/jogdial -t jogdial
370 ?? Ss 0:10.21 /usr/sbin/moused -3 -p /dev/ums1 -I /var/run/moused.ums1.pid
(The PS/2 mouse is either the first or the last one.)
This is on a FreeBSD 4.9-PRERELASE. On Windoze the converter works
out of the box, with keyboard and mouse, without additional drivers.
Does anybody know how to make the PS/2 mouse work?
BTW, usbd, as it is, is not suitable to handle devices like this PS/2
adapter because it matches and executes only one entry in the
usbd.conf. USB devices implementing multiple features are in my
humble opinion better handled matching multiple entries in usbd.conf.
Below I attached a patch to usbd.c to change this behaviour (hence the
crossposting to the hackers list).
Cheers,
--
walter pelissero
http://www.pelissero.de
--- /usr/src/usr.sbin/usbd/usbd.c Tue Dec 31 10:05:27 2002
+++ usbd.c Sat Aug 30 13:43:23 2003
@@ -102,6 +102,7 @@
int lineno;
int verbose = 0; /* print message on what it is doing */
+int single_action = 0;
typedef struct event_name_s {
int type; /* event number (from usb.h) */
@@ -204,8 +205,7 @@
void print_event __P((struct usb_event *event));
void print_action __P((action_t *action, int i));
void print_actions __P((void));
-int find_action __P((struct usb_device_info *devinfo,
- action_match_t *action_match));
+void execute_command __P((char *cmd));
void
@@ -697,9 +697,8 @@
return(-1);
}
-
-int
-find_action(struct usb_device_info *devinfo, action_match_t *action_match)
+void
+execute_actions (struct usb_device_info *devinfo, int event_type)
{
action_t *action;
char *devname = NULL;
@@ -722,6 +721,8 @@
(match = match_devname(action, devinfo)) != -1)) {
/* found match !*/
+ if (verbose >= 2)
+ print_action(action, 0);
/* Find a devname for pretty printing. Either
* the matched one or otherwise, if there is only
* one devname for that device, use that.
@@ -735,21 +736,37 @@
if (verbose) {
printf("%s: Found action '%s' for %s, %s",
- __progname, action->name,
- devinfo->udi_product, devinfo->udi_vendor);
+ __progname, action->name,
+ devinfo->udi_product, devinfo->udi_vendor);
if (devname)
printf(" at %s", devname);
printf("\n");
}
- action_match->action = action;
- action_match->devname = devname;
+ if (devname) {
+ int error;
+ if (verbose >= 2)
+ printf("%s: Setting DEVNAME='%s'\n",
+ __progname, devname);
+ error = setenv("DEVNAME", devname, 1);
+ if (error)
+ fprintf(stderr, "%s: setenv(\"DEVNAME\",
+ \"%s\",1) failed, %s\n",
+ __progname, devname, strerror(errno));
+ }
- return(1);
+ if (USB_EVENT_IS_ATTACH(event_type) && action->attach)
+ execute_command(action->attach);
+ if (USB_EVENT_IS_DETACH(event_type) && action->detach)
+ execute_
Re: USB -> PS/2
Just noticed that the patch to usbd.c I proposed yesterday shows an
undesirable behaviour. That is, usbd executes the actions in
usbd.conf of all matching devices, which is not exactly what I meant
to do. In fact, usbd should execute for every device name the "best"
matching action in usbd.conf.
Supposed usbd.conf is sorted in a way that the most specific entries
precede the less specific ones, the following patch should do the
trick.
Cheers,
--
walter pelissero
http://www.pelissero.de
--- usbd.c.orig Sun Aug 31 17:24:14 2003
+++ usbd.c Sun Aug 31 17:08:19 2003
@@ -102,6 +102,7 @@
int lineno;
int verbose = 0; /* print message on what it is doing */
+int single_action = 0;
typedef struct event_name_s {
int type; /* event number (from usb.h) */
@@ -204,8 +205,7 @@
void print_event __P((struct usb_event *event));
void print_action __P((action_t *action, int i));
void print_actions __P((void));
-int find_action __P((struct usb_device_info *devinfo,
- action_match_t *action_match));
+void execute_command __P((char *cmd));
void
@@ -674,37 +674,19 @@
int
-match_devname(action_t *action, struct usb_device_info *devinfo)
+match_devname(regex_t *regex, char *name)
{
- int i;
- regmatch_t match;
- int error;
-
- for (i = 0; i < USB_MAX_DEVNAMES; i++) {
- if (devinfo->udi_devnames[i][0] == '\0')
- break;
-
- error = regexec(&action->devname_regex, devinfo->udi_devnames[i],
- 1, &match, 0);
- if (error == 0) {
- if (verbose >= 2)
- printf("%s: %s matches %s\n", __progname,
- devinfo->udi_devnames[i], action->devname);
- return(i);
- }
- }
-
- return(-1);
+ return regexec(regex, name, 0, 0, 0) == 0;
}
-
-int
-find_action(struct usb_device_info *devinfo, action_match_t *action_match)
+void
+execute_actions (struct usb_device_info *devinfo, int event_type)
{
action_t *action;
char *devname = NULL;
- int match = -1;
+ int i;
+ for (i = 0; i < USB_MAX_DEVNAMES && devinfo->udi_devnames[i][0] != '\0'; i++) {
STAILQ_FOREACH(action, &actions, next) {
if ((action->vendor == WILDCARD_INT ||
action->vendor == devinfo->udi_vendorNo) &&
@@ -719,15 +701,15 @@
(action->protocol == WILDCARD_INT ||
action->protocol == devinfo->udi_protocol) &&
(action->devname == WILDCARD_STRING ||
-(match = match_devname(action, devinfo)) != -1)) {
- /* found match !*/
-
+match_devname(&action->devname_regex,
devinfo->udi_devnames[i]))) {
+ if (verbose >= 2)
+ print_action(action, 0);
/* Find a devname for pretty printing. Either
* the matched one or otherwise, if there is only
* one devname for that device, use that.
*/
- if (match >= 0)
- devname = devinfo->udi_devnames[match];
+ if (action->devname != WILDCARD_STRING)
+ devname = devinfo->udi_devnames[i];
else if (devinfo->udi_devnames[0][0] != '\0' &&
devinfo->udi_devnames[1][0] == '\0')
/* if we have exactly 1 device name */
@@ -742,16 +724,37 @@
printf("\n");
}
- action_match->action = action;
- action_match->devname = devname;
+ if (devname) {
+ int error;
+ if (verbose >= 2)
+ printf("%s: Setting DEVNAME='%s'\n",
+ __progname, devname);
+ error = setenv("DEVNAME", devname, 1);
+ if (error)
+ fprintf(stderr, "%s:
setenv(\"DEVNAME\",
+ \"%s\",1) failed, %s\n",
+ __progname, devname,
strerror(errno));
+ }
- return(1);
+ if (USB_EVENT_IS_ATTACH(event_type) && action->attach)
+ execute_command(action->attach);
+ if (USB_EVENT_IS_DETACH(event_type) && action->detach)
+
Re: USB -> PS/2
Ok, today I spent some time deciphering the ums log and came up
with this patch.
--- /sys/dev/usb/ums.c Wed Nov 6 21:23:50 2002
+++ ums.c Sun Aug 31 15:08:52 2003
@@ -428,10 +428,8 @@
}
ibuf = sc->sc_ibuf;
- if (sc->sc_iid) {
- if (*ibuf++ != sc->sc_iid)
- return;
- }
+ if (sc->sc_iid)
+ ibuf++;
dx = hid_get_data(ibuf, &sc->sc_loc_x);
dy = -hid_get_data(ibuf, &sc->sc_loc_y);
Unfortunately my knowledge (or rather lack of it) of the USB/UMS
driver doesn't give me very much confidence that I didn't break
something else.
What was that conditional return suposed to protect from?
Is it safe to remove it?
The PS/2 mouse works now and the USB one as well.
Cheers,
--
walter pelissero
http://www.pelissero.de
Bruce M Simpson writes:
> On Sat, Aug 30, 2003 at 01:51:27PM +0200, Walter C. Pelissero wrote:
> > I just bought a USB -> PS/2 keyboard and mouse converter for my
> > laptop. It's a Sitecom brand and it gets recognised as MCT Corp.
>
> I had similar problems with a Tangtop USB->PS/2 k+m adapter.
>
> In the end it turned out that this device was causing uhci to report
> an error, even though the movement data coming in looked fine. I never
> got round to fixing it.
>
> Perhaps you could try throwing all the debug switches on in the usb drivers
> and usbd and seeing if you get similar behaviour?
>
> Thanks for the patch, this was the other thing that needed fixing!
>
> BMS
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
don't dump core dumps
I don't know if this a widespread opinion, but I believe that saving core files in backup tapes is a waste of time and space, often a big waste. Consider that Emacs itself can fill hundred of megs of disk space with just one core dump, that if you don't bother to debug, it will likely sit there for months before getting noticed and deleted straight away. Forbidding the creation of core files by means such as "sysctl kern.coredump=0" or "limits -c 0 big-fat-program", is not an option, because most of the times I do like to have a peek in those core files. My idea was to create core files with a NODUMP flag. A patch like the following would do the trick: diff -c /.amd_mnt/daemon/host/usr/warehouse/src/sys/kern/kern_sig.c /usr/home/wcp/tmp/buffer-content-51635BT *** /.amd_mnt/daemon/host/usr/warehouse/src/sys/kern/kern_sig.c Mon May 19 16:41:42 2003 --- /usr/home/wcp/tmp/buffer-content-51635BTFri Sep 19 01:20:20 2003 *** *** 119,124 --- 119,128 SYSCTL_INT(_kern, OID_AUTO, coredump, CTLFLAG_RW, &do_coredump, 0, "Enable/Disable coredumps"); + static int set_coredump_nodump_flag = 1; + SYSCTL_INT(_kern, OID_AUTO, coredump, CTLFLAG_RW, + &set_coredump_nodump_flag, 0, "Enable/Disable setting of NODUMP flag on coredump files"); + /* * Signal properties and actions. * The array below categorizes the signals and their default actions *** *** 1655,1660 --- 1659,1666 VATTR_NULL(&vattr); vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); vattr.va_size = 0; + if (set_coredump_nodump_flag) + vattr.va_flags |= UF_NODUMP; VOP_LEASE(vp, p, cred, LEASE_WRITE); VOP_SETATTR(vp, &vattr, cred, p); p->p_acflag |= ACORE; Before someone comes up with this: no, excluding files ending in .core from backups is not an option either. Dump(8) doesn't have this option and not all files ending in .core are core dumps (see the CMUCL image). Cheers, -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
auto-patching the system
I keep my src tree updated with cvsup, but I start to accumulate patches to kernel or programs that I'd like to include automatically each time I recompile the kernel (pretty often) or I do a "make world" (much less often). Those are usually patches that have been already put forward to the attention of the maintainers with a send-pr, but got forgotten or simply ignored possibly because considered not interesting. At the moment I simply manually copy the modified files into the source tree before recompiling, but, of course, next time I do a cvsup, the changes are gone, requiring me to repeat the process next time I compile (and likely forgetting some stuff). Is there already any pre-canned way to include those patches at compile time? (A parallel source tree, for instance.) Cheers, -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CAM suspend
Having noticed that there is not a big interest in it, among the fellow FreeBSDers, I was about to set off and hack up the scsi subsystem to implement spindown on suspend and spinup on resume of the da devices, when I realized that there seems to be no hook in the SCSI code for this events. I'm not a device driver expert, so I'm looking for clues. What I mean is that the ata-pci driver, for instance, specifies hooks via the device_method_t structure which is not available in the scsi_all or scsi_da modules. I understand that they are simply different kind of beasts (sitting on different layers of the kernel code), but I was wondering if there might be a similar mechanism to do what I want. So, what is the recommended way (if there is one), to hook a function of the SCSI subsystem to an event like suspend/resume? I would most appreciate if anyone could point me to a suitable document or even anything related to FreeBSD kernel hacking. Cheers, -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SCSI spin down on suspend (patch)
I eventually got around to hack scsi_da.c to implement spin down/up on
suspend/resume events of APM or ACPI. Actually the ACPI stuff is
untested and the APM once didn't work properly on my system: one of
the disks, after resume, was misbehaving (hardware errors). A power
toggle fixed the problem, though.
I suspect this code could be improved introducing a delay after the
spin up of each HD (I've got 6 HD hooked to a 350W power supply, this
might explain the hardware error), but not being a kernel hacker
myself, I don't know how to proceed. Suggestions are welcome.
Please note you need to define CAM_APM_COOP or CAM_ACPI_COOP.
--- scsi_da.c.orig Mon Nov 3 00:15:55 2003
+++ scsi_da.c Mon Nov 3 00:18:04 2003
@@ -72,6 +72,15 @@
#include
#endif /* !_KERNEL */
+#ifdef CAM_ACPI_COOP
+# include
+# include
+# include
+#endif /* CAM_ACPI_COOP */
+#ifdef CAM_APM_COOP
+# include
+#endif
+
#ifdef _KERNEL
typedef enum {
DA_STATE_PROBE,
@@ -142,6 +151,40 @@
da_quirks quirks;
};
+#ifdef CAM_APM_COOP
+static void da_start_stop_all(int start);
+
+static int
+da_apm_suspend (void *junk)
+{
+ da_start_stop_all (0);
+ return 0;
+}
+
+static int
+da_apm_resume (void *junk)
+{
+ da_start_stop_all (1);
+ return 0;
+}
+
+struct apmhook da_suspend_hook = {
+ 0, /* next */
+ da_apm_suspend, /* fun */
+ 0, /* arg */
+ "da_suspend", /* name */
+ 0 /* order */
+};
+
+struct apmhook da_resume_hook = {
+ 0, /* next */
+ da_apm_resume, /* fun */
+ 0, /* arg */
+ "da_resume",/* name */
+ 0 /* order */
+};
+#endif /* CAM_APM_COOP */
+
static const char quantum[] = "QUANTUM";
static const char microp[] = "MICROP";
@@ -213,6 +256,12 @@
{T_DIRECT, SIP_MEDIA_FIXED, quantum, "LPS525S", "*"},
/*quirks*/ DA_Q_NO_SYNC_CACHE
},
+ { {T_DIRECT, SIP_MEDIA_FIXED, quantum, "LPS540S", "*"},
+ DA_Q_NO_SYNC_CACHE },
+ { {T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CP3500*", "*"},
+ DA_Q_NO_SYNC_CACHE },
+ { {T_DIRECT, SIP_MEDIA_REMOVABLE, "DataFab*", "*", "*"},
+ DA_Q_NO_6_BYTE | DA_Q_NO_SYNC_CACHE },
{
/*
* Doesn't work correctly with 6 byte reads/writes.
@@ -935,6 +984,71 @@
return (0);
}
+/*
+ * Step through all DA peripheral drivers and spin them up/down.
+ */
+static void
+da_start_stop_all(int start)
+{
+ struct cam_periph *periph;
+ struct da_softc *softc;
+
+ for (periph = TAILQ_FIRST(&dadriver.units); periph != NULL;
+periph = TAILQ_NEXT(periph, unit_links)) {
+ union ccb ccb;
+ softc = (struct da_softc *)periph->softc;
+
+ xpt_setup_ccb(&ccb.ccb_h, periph->path, /*priority*/1);
+
+ ccb.ccb_h.ccb_state = DA_CCB_DUMP;
+ scsi_start_stop(&ccb.csio,
+ /*retries*/1,
+ /*cbfcnp*/dadone,
+ MSG_SIMPLE_Q_TAG,
+ start,
+ /*load_eject*/ 0,
+ /*immediate*/ FALSE,
+ /*sense_len*/ SSD_FULL_SIZE,
+ /*timeout*/ 5);
+
+ xpt_polled_action(&ccb);
+
+ if ((ccb.ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_CMP) {
+ if (((ccb.ccb_h.status & CAM_STATUS_MASK) ==
+CAM_SCSI_STATUS_ERROR)
+&& (ccb.csio.scsi_status == SCSI_STATUS_CHECK_COND)){
+ int error_code, sense_key, asc, ascq;
+
+ scsi_extract_sense(&ccb.csio.sense_data,
+ &error_code, &sense_key,
+ &asc, &ascq);
+
+ if (sense_key != SSD_KEY_ILLEGAL_REQUEST)
+ scsi_sense_print(&ccb.csio);
+ } else {
+ xpt_print_path(periph->path);
+ printf("Suspend disk failed, status "
+ "== 0x%x, scsi status == 0x%x\n",
+ ccb.ccb_h.status, ccb.csio.scsi_status);
+ }
+ }
+ }
+}
+
+#ifdef CAM_ACPI_COOP
+static void
+da_start_all(void *arg, int state)
+{
+ da_start_stop_all(1);
+}
+
+static void
+da_stop_all(void *arg, int state)
+{
+ da_start_stop_all(0);
+}
+#endif /* CAM_ACPI_COOP */
+
static void
dainit(void)
{
@@ -987,6 +1101,14 @@
if ((EVENTHANDLER_REGISTER(shutdown_post_sync, dashutdown,
SCSI spin down on suspend (patch)
I amended the patch. Now:
- the behaviour is controlled by a sysctl (off by default)
. - a 1s delay is done after each drive spin up, making things
easier for the system power supply
- no need to define anything; APM or ACPI methods are chosen
according to what has been made available in the kernel
configuration file; if neither APM or ACPI is selcted the code
is (mostly) removed
I tried to introduce a cache flush before the spin down, but it didn't
work (system panic), so the code is there but ifdef-ed out. Maybe
somebody with a deeper knowledge of the CAM layer could shed a light.
Once I get some confidence about the stability of the patch, and if
anybody is interested, I could submit a pr.
One thing I forgot to mention in my former message: the patch has
been tested on 4.9-STABLE only.
Enjoy.
--
walter pelissero
http://www.pelissero.de
--- scsi_da.c.orig Mon Nov 3 00:15:55 2003
+++ scsi_da.c Tue Nov 4 20:20:54 2003
@@ -72,6 +72,21 @@
#include
#endif /* !_KERNEL */
+#include
+#include
+/* to get DELAY declaration */
+#include
+
+#if NAPM > 0
+# include
+#endif
+
+#if NACPICA > 0
+# include
+# include
+# include
+#endif
+
#ifdef _KERNEL
typedef enum {
DA_STATE_PROBE,
@@ -414,6 +435,8 @@
struct scsi_read_capacity_data * rdcap);
static timeout_t dasendorderedtag;
static voiddashutdown(void *arg, int howto);
+static voiddasync(struct cam_periph *periph);
+static voiddaspin(struct cam_periph *periph, int up);
#ifndef DA_DEFAULT_TIMEOUT
#define DA_DEFAULT_TIMEOUT 60 /* Timeout in seconds */
@@ -435,6 +458,11 @@
SYSCTL_INT(_kern_cam_da, OID_AUTO, default_timeout, CTLFLAG_RW,
&da_default_timeout, 0, "Normal I/O timeout (in seconds)");
TUNABLE_INT("kern.cam.da.default_timeout", &da_default_timeout);
+#if NAPM > 0 || NACPICA > 0
+static int da_spindown_on_suspend = 0;
+SYSCTL_INT(_kern_cam_da, OID_AUTO, spindown_on_suspend, CTLFLAG_RW,
+ &da_spindown_on_suspend, 0, "Spindown hard disks on system suspend");
+#endif
/*
* DA_ORDEREDTAG_INTERVAL determines how often, relative
@@ -490,6 +518,95 @@
static SLIST_HEAD(,da_softc) softc_list;
static struct extend_array *daperiphs;
+#if NAPM > 0 || NACPICA > 0
+/* Step through all DA peripheral drivers and spin them up/down. */
+static void
+da_spin_all(int up)
+{
+ struct cam_periph *periph;
+
+ for (periph = TAILQ_FIRST(&dadriver.units); periph != NULL;
+periph = TAILQ_NEXT(periph, unit_links)) {
+#if 0 /* this panics the system -wcp4/11/03. */
+ /* if spinning down, it might be safer to synchronise
+* the cache before */
+ if (!up)
+ dasync(periph);
+#endif
+ daspin(periph, up);
+ /* If spinning up, wait a moment to avoid overloading
+* the power supply. A better solution would be to
+* check until the device is ready. I don't know how
+* to do it, though. */
+ if (up)
+ DELAY(1000 * 1000);
+ }
+}
+
+static void
+da_suspend(void)
+{
+ if (da_spindown_on_suspend)
+ da_spin_all(0);
+}
+
+static void
+da_resume(void)
+{
+ if (da_spindown_on_suspend)
+ da_spin_all(1);
+}
+#endif /* NAPM > 0 || NACPICA > 0 */
+
+/* The mechanism to hook functions to certain events in the APM and
+ * ACPI code are different for no apparent reason. */
+
+#if NAPM > 0
+static int
+da_apm_suspend (void *junk)
+{
+ da_suspend();
+ return 0;
+}
+
+static int
+da_apm_resume (void *junk)
+{
+ da_resume();
+ return 0;
+}
+
+struct apmhook da_apm_suspend_hook = {
+ 0, /* next */
+ da_apm_suspend, /* fun */
+ 0, /* arg */
+ "da_suspend", /* name */
+ 0 /* order */
+};
+
+struct apmhook da_apm_resume_hook = {
+ 0, /* next */
+ da_apm_resume, /* fun */
+ 0, /* arg */
+ "da_resume",/* name */
+ 0 /* order */
+};
+#endif /* NAPM > 0 */
+
+#if NACPICA > 0
+static void
+da_acpi_resume(void *arg, int state)
+{
+ da_resume();
+}
+
+static void
+da_acpi_suspend(void *arg, int state)
+{
+ da_suspend();
+}
+#endif /* NACPICA > 0 */
+
static int
daopen(dev_t dev, int flags, int fmt, struct proc *p)
{
@@ -987,6 +1104,14 @@
if ((EVENTHANDLER_REGISTER(shutdown_post_sync, dashutdown,
NULL, SHUTDOWN_PRI_DEFAULT)) == NULL)
printf("dainit: shutdown event registration failed!\n");
+#if NACPICA > 0
+ EVENTHANDLER_REGISTER(acpi_sleep_event, da_acpi_suspend, NULL,
ACPI_EVENT_PRI_DEFAULT);
+ EVENTHANDLER_REGISTER(acpi_wakeup
