Re: HELP WANTED: buildworld shortening options.
On Mon, Oct 21, 2002 at 07:49:13PM +0200, Poul-Henning Kamp wrote: A number of us go into release crunching mode now, and that means running make release a lot. I have totally lost track of which /etc/make.conf options we have which cuts things out of the build, so I could use some help: If somebody would make a skeleton /etc/make.conf which pulls out as much stuff as possible, UUCP, I4B, Profiled libs and all that sort of stuff, but no more than make release would still complete it would be a help for us at this point. I'm not asking for new options to be added, all I want is a list of which of the current ones I can use to save time. They should all be documented in /usr/share/examples/etc/make.conf Kris msg44961/pgp0.pgp Description: PGP signature
Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation
I've recalled that FreeBSD used RTC to determine base memory size in
old days. I've tested this method on my machines and confirmed it's
working well.
If this is done, then FreeBSD won't work on many laptops and other
desktops, which report 640K for memory, but the BIOS actually steals
some of the memory for things like APM, so when the VM86 call is done
the reported memory size is actually like (like 637K or something).
This change may break FreeBSD on these 'newer' hardware as well.
Nate
I'll commit this coming weekend if no objections.
Thanks
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.541
diff -u -r1.541 machdep.c
--- machdep.c 5 Oct 2002 14:36:14 - 1.541
+++ machdep.c 21 Oct 2002 15:27:02 -
@@ -1284,8 +1284,14 @@
/*
* Perform base memory related probes setup
*/
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ if ((basemem = rtcin(RTC_BASELO) + (rtcin(RTC_BASEHI)8)) 640)
+ basemem = 640;
+
+ if (basemem == 0) {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
+
if (basemem 640) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
basemem);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
HELP WANTED: buildworld shortening options.
A number of us go into release crunching mode now, and that means running make release a lot. I have totally lost track of which /etc/make.conf options we have which cuts things out of the build, so I could use some help: If somebody would make a skeleton /etc/make.conf which pulls out as much stuff as possible, UUCP, I4B, Profiled libs and all that sort of stuff, but no more than make release would still complete it would be a help for us at this point. I'm not asking for new options to be added, all I want is a list of which of the current ones I can use to save time. Thanks in advance, -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- === lib/libdisk /h/des/src/lib/libdisk/disk.c: In function `assignToDisk': /h/des/src/lib/libdisk/disk.c:409: structure has no member named `d_nheads' /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include/ctype.h: At top level: /h/des/src/lib/libdisk/disk.c:430: warning: `assignToPartition' defined but not used *** Error code 1 Stop in /h/des/src/lib/libdisk. *** Error code 1 Stop in /h/des/src/lib. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: zombies from linux binaries
Duncan, Duncan Barclay wrote: On 01-Oct-2002 Lars Eggert wrote: I've been running the guidescope web ad blocker (http://www.guidescope.com/home/) as a Linux binary under FreeBSD for a long time. The thing seems to fork a child for each web request it proxies. Under -current, it seems that the child processes become zombies, and the proxy stops working once 1024 or so accumulate. The zombies don't go away when parent process finishes, they stick around until reboot. Is this http://www.freebsd.org/cgi/query-pr.cgi?pr=42457 related? It is for stable but I belive that the same behaviour is present in -current and it may manifest itself differently. I have finally applied your patch from the PR, but unfortunately it does not fix the problem with guidescope I am seeing. Looks like something else is broken WRT Linux forking: [larse@nik: ~] ps -auxww | grep guide larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 2117 0.0 0.2 40128 2200 ?? I 1:56PM 0:00.09 /nfs/ruby/larse/bin/guide.new /nfs/ruby/larse/bin/guide/guide.conf larse 2762 0.0 0.2 40128 2200 ?? S 1:59PM 0:00.01 /nfs/ruby/larse/bin/guide.new /nfs/ruby/larse/bin/guide/guide.conf larse 2763 0.0 0.2 40128 2200 ?? S 1:59PM 0:00.22 /nfs/ruby/larse/bin/guide.new /nfs/ruby/larse/bin/guide/guide.conf larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 2861 0.0 0.0 316 184 p0 L+2:03PM 0:00.00 grep guide larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) larse 0 0.0 0.0 00 ?? ZW - 0:00.00 (guide.new) Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: zombies from linux binaries
Lars Eggert wrote: I've been running the guidescope web ad blocker (http://www.guidescope.com/home/) as a Linux binary under FreeBSD for a long time. The thing seems to fork a child for each web request it proxies. Under -current, it seems that the child processes become zombies, and the proxy stops working once 1024 or so accumulate. The zombies don't go away when parent process finishes, they stick around until reboot. Is this http://www.freebsd.org/cgi/query-pr.cgi?pr=42457 related? It is for stable but I belive that the same behaviour is present in -current and it may manifest itself differently. I have finally applied your patch from the PR, but unfortunately it does not fix the problem with guidescope I am seeing. Looks like something else is broken WRT Linux forking: Linux has the SVR4 behaviour in that, if SIGCHLD is not caught, zombies are reaped automatically, without the parent needing to explicitly reap their exit status. Most likely, they are installing a signal handler of SIG_IGN for SIGCHLD, and expecting the standard behaviour for auto-reaping. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation
Hmmm, actually no. I know that some machines get panic with fatal trap
12 if we do 0x12 call. The worst case is getting panic, not losing
640K memory.
Where does the panic occur? I checked that there is no problem here if
the result of INT 0x12 is ignored and basemem is set to 0.
panic messages attached. It seems to be within BIOS routine after reti
jumped from vm86_bioscall.
Strangely, this panic can be recovered by continue command in DDB,
FreeBSD continues its boot process after this. So, this panic problem
is not serious for me :)
OTOH, the same problem in boot program is very critical, completely stops
with register dump...
FYI: On RELENG_4, this problem is critical too because this panic
isn't recoverable. This means that it's impossible to install onto
some newer machines.
And it seems that today's Linux don't have 0x12 calling any more,
so I didn't see any problem on the machines.
Now I have some ideas on this issue;
- 0x15/0xe820 call in getmemsize() to determine base mem size. (But how?)
- 0x15/0xe820 call in locore.s before calling init386().
- specify the size by loader tunable (e.g. hw.basememsize).
I would first fix all the broken code that doesn't check for errors
and see if the problem goes away. Then recover any low memory not
reported by int 0x12 in the int 0x15/0xe820 code in i386/machdep.c,
like libi386/biosmem.c does it (I think machdep.c intentionally skips
the low memory, while biosmem.c tries to find it).
Cool. Thanks!
Stopped at 0xf842:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xf842
fault code= supervisor read, page not present
instruction pointer = 0x8:0xc03b5108
stack pointer = 0x10:0xc0a68e90
frame pointer = 0x10:0xc0a68e94
code segment = base 0x0,limit 0xf, type 0x1b
= DPL 0, press 1, def32 1, gran 1
processor eflags = resume,IOPL = 0
current process = 0 ()
kernel:type 12 trap,code=0
db t
Fatal trap 12: page fault while in kernel mode
I've recalled that FreeBSD used RTC to determine base memory size in
old days. I've tested this method on my machines and confirmed it's
working well.
I'll commit this coming weekend if no objections.
Thanks
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.541
diff -u -r1.541 machdep.c
--- machdep.c 5 Oct 2002 14:36:14 - 1.541
+++ machdep.c 21 Oct 2002 15:27:02 -
@@ -1284,8 +1284,14 @@
/*
* Perform base memory related probes setup
*/
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ if ((basemem = rtcin(RTC_BASELO) + (rtcin(RTC_BASEHI)8)) 640)
+ basemem = 640;
+
+ if (basemem == 0) {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
+
if (basemem 640) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
basemem);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HELP WANTED: buildworld shortening options.
In message [EMAIL PROTECTED], Kris Kennaway writes: --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2002 at 07:49:13PM +0200, Poul-Henning Kamp wrote: =20 A number of us go into release crunching mode now, and that means running make release a lot. =20 I have totally lost track of which /etc/make.conf options we have which cuts things out of the build, so I could use some help: =20 If somebody would make a skeleton /etc/make.conf which pulls out as much stuff as possible, UUCP, I4B, Profiled libs and all that sort of stuff, but no more than make release would still complete it would be a help for us at this point. =20 I'm not asking for new options to be added, all I want is a list of which of the current ones I can use to save time. They should all be documented in /usr/share/examples/etc/make.conf Yes, but it doesn't document if they are compatible with use in make release... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: mtx_lock() of spin mutex
John Baldwin wrote: On 18-Oct-2002 Lars Eggert wrote: John Baldwin wrote: What is line 488 of src/sys/kern/kern_descrip.c? fhold(fp) in do_dup(). Hrm. You can try adding some KASSERT()'s that the reference count of that struct file isn't zero or negative. fd_refcnt is an u_short, but I've added a KASSERT that makes sure it's not zero, and will test. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic: mtx_lock() of spin mutex
Lars Eggert wrote:
John Baldwin wrote:
On 18-Oct-2002 Lars Eggert wrote:
John Baldwin wrote:
What is line 488 of src/sys/kern/kern_descrip.c?
fhold(fp) in do_dup().
Hrm. You can try adding some KASSERT()'s that the reference
count of that struct file isn't zero or negative.
fd_refcnt is an u_short, but I've added a KASSERT that makes sure it's
not zero, and will test.
Just got the panic again, the KASSERT didn't fire, so the ref count is
0. Here's a backtrace with today's -current:
[root@nik: /etc] gdb -k /usr/obj/usr/src/sys/KERNEL-1.10/kernel.debug
/var/crash/vmcore.2
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: from debugger
panic messages:
---
panic: mtx_lock() of spin mutex duI\M-@\M-4qI\M-@`\M^NN\M-@\^D @
/usr/src/sys/kern/kern_descrip.c:486
cpuid = 1; lapic.id = 0200
panic: from debugger
cpuid = 1; lapic.id = 0200
boot() called on cpu#1
Uptime: 19m11s
pfs_vncache_unload(): 6 entries remaining
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
224 dumpsys(dumper);
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:224
#1 0xc02779de in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:355
#2 0xc0277fd7 in panic (fmt=0xc0413704 from debugger) at
/usr/src/sys/kern/kern_shutdown.c:508
#3 0xc01509d2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc015080c in db_command (last_cmdp=0xc047bce0, cmd_table=0x0,
aux_cmd_tablep=0xc04732dc,
aux_cmd_tablep_end=0xc04732e0) at /usr/src/sys/ddb/db_command.c:346
#5 0xc0150a4a in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc01536f5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc03d47f7 in kdb_trap (type=3, code=0, regs=0xeb73dbe8) at
/usr/src/sys/i386/i386/db_interface.c:166
#8 0xc03ec35a in trap (frame=
{tf_fs = 24, tf_es = -1069350896, tf_ds = 16, tf_edi =
-955428240, tf_esi = 256, tf_ebp = -344728524, tf_isp = -344728556,
tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err =
0, tf_eip = -1069724870, tf_cs = 8, tf_eflags = 658, tf_esp =
-1069144858, tf_ss = -1069294790}) at /usr/src/sys/i386/i386/trap.c:605
#9 0xc03d5fc8 in calltrap () at {standard input}:99
#10 0xc0277fbf in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:494
#11 0xc026da07 in _mtx_lock_flags (m=0xc0497574, opts=0, file=0xc043acbf
/usr/src/sys/kern/kern_descrip.c, line=486)
at /usr/src/sys/kern/kern_mutex.c:318
#12 0xc0259541 in do_dup (td=0xc70d5270, type=DUP_FIXED, old=-1, new=4,
retval=0xc70d5304)
at /usr/src/sys/kern/kern_descrip.c:486
#13 0xc0258793 in dup2 (td=0x0, uap=0x0) at
/usr/src/sys/kern/kern_descrip.c:174
#14 0xc03ed066 in syscall (frame=
{tf_fs = 135594031, tf_es = -1078067153, tf_ds = -1078067153,
tf_edi = 4, tf_esi = 135637504, tf_ebp = -1078036088, tf_isp =
-344728204, tf_ebx = -1, tf_edx = -1078037360, tf_ecx = 136126464,
tf_eax = 90, tf_trapno = 12, tf_err = 2, tf_eip = 134842063, tf_cs = 31,
tf_eflags = 646, tf_esp = -1078037316, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1071
#15 0xc03d601d in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
(kgdb) up 12
#12 0xc0259541 in do_dup (td=0xc70d5270, type=DUP_FIXED, old=-1, new=4,
retval=0xc70d5304)
at /usr/src/sys/kern/kern_descrip.c:486
486 fhold(fp);
(kgdb) list
481 FILEDESC_UNLOCK(fdp);
482 return (0);
483 }
484 fp = fdp-fd_ofiles[old];
485 KASSERT(fdp-fd_refcnt != 0, (reference count is zero));
486 fhold(fp);
487
488 /*
489 * Expand the table for the new descriptor if needed. This may
490 * block and drop and reacquire the filedesc lock.
Lars
--
Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute
smime.p7s
Description: S/MIME Cryptographic Signature
GLX cmd X server crash
Failure: Xlib: extension GLX missing on display :0.0 The system did not lock; X crashed clear out. another major ongoing problem: PS/2 mouse does not track; it appears to be missing motion 'hits' and interprets some as button 1. It is impossible to use on drop down menus unless they also support up-down keys. Usability for cut-paste, move, etc. is a total non-starter. OS Rev: 5.0-CURRENT base on 1200 GMT 20 Oct 2002 (100%) System: Tyan 2642 SMP 1.2G w/ onboard dual SCSI-160 and dual 3C595 NIC dual 10,000 RPM IBM 9G SCSI 160 MB/sec drives Matrox Millennium II w/ 8 MB onboard 250MHz horizontal x 95Hz vertical Diamond Scan monitor PS/2 mouse reporting sysmouse compatible to moused -i all After I discovered an old ccp from 1998 in an obscure /usr/local/lib/unknown-freebsd-freebsd2.2.8 directory, I trashed everything (1.4 GB of applications plus X) that was not installed by installworld, except Apache and Postfix, and reinstalled (by hand) from packages on snapshot (shows dates within the last few days). X has generally been stable; no lockups since a 07 Oct build from ports; then reinstalled on 20 Oct from packages: Xemacs will lock with auto-repeat on left, up, or page-up which can be avoided with frequent saves. Not ideal, but it works. Mozilla has been stable since I built it from ports on 07 Oct; reinstalled from packages on snapshot on 20 Oct. Suggestions appreciated, particularly on the mouse problem! Attachments: 2 39 lines Text/PLAIN (Name: crash.log) 3 ~674 lines Text/PLAIN (Name: XFree86.0.log) 4 ~100 lines Text/PLAIN (Name: XFree86Config) 5~52 lines Text/PLAIN (Name: .xinitrc) 10 times: Xlib: extension GLX missing on display :0.0. 5 times: GetModeLine - scrn: 0 clock: 202500 GetModeLine - hdsp: 1600 hbeg: 1664 hend: 1856 httl: 2160 vdsp: 1200 vbeg: 1201 vend: 1204 vttl: 1250 flags: 5 10 times: Xlib: extension GLX missing on display :0.0. endgame: display :0.0 does not support the GLX extension. xscreensaver: 0: child pid 8936 (endgame) exited abnormally (code 1). 40 times: GetModeLine - scrn: 0 clock: 202500 GetModeLine - hdsp: 1600 hbeg: 1664 hend: 1856 httl: 2160 vdsp: 1200 vbeg: 1201 vend: 1204 vttl: 1250 flags: 5 xscreensaver: 0: unrecognised ClientMessage WM_CHANGE_STATE received xscreensaver: 0: for window 0x1600066 (emacs / Emacs) xscreensaver: couldn't grab pointer! (AlreadyGrabbed) 23 times: GetModeLine - scrn: 0 clock: 202500 GetModeLine - hdsp: 1600 hbeg: 1664 hend: 1856 httl: 2160 vdsp: 1200 vbeg: 1201 vend: 1204 vttl: 1250 flags: 5 Fatal server error: Caught signal 10. Server aborting When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] xinit: connection to X server lost. xscreensaver: SIGHUP received: restarting... X connection to :0.0 broken (explicit kill or server shutdown). XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: FreeBSD 5.0-CURRENT i386 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Mon Oct 21 06:10:16 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor Primary Monitor (**) | |--Device Matrox Millennium II 8MB (**) |--Input Device Mouse1 (**) |--Input Device Keyboard1 (**) Option AutoRepeat 500 15 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc104 (**) XKB: model: pc104 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (WW) `fonts.dir' not found (or not valid) in /usr/X11R6/lib/X11/fonts/local/. Entry deleted from font path. (Run 'mkfontdir' on /usr/X11R6/lib/X11/fonts/local/). (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) Module ABI versions: XFree86 ANSI C
Re: [PATCH] re-attach cards after resume
I reported the same(+different fix) to Warner a while ago. He had troubles with his tree and didn't want to commit before he had the issues sorted out. However, it seems to me a very crucial fix. Hopefully it can be committed now. Btw, your patch is alot smaller than mine :-) (Mine was explicitly calling the reattaching code again) Mark On Mon, Oct 21, 2002 at 11:04:29PM +0900, Mitsuru IWASAKI wrote: Hi, warner. My laptops (FIVA and Toshiba 3110CT) doesn't re-attach cards after resume. ata1: resetting devices .. done cbb0: card inserted: event=0x, state=3010 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: CARD_VCC_0V and CARD_VPP_0V [44] cbb0: Unknown card voltage pccard0: read_cis pccard0: check_cis_quirks pccard0: Card has no functions! It seems that doing only cbb_setb(sc, CBB_SOCKET_FORCE, CBB_SOCKET_EVENT_CD) doesn't work on many CBB, so I've made following patch. This is working well so far in both cases of 16-bits cards and Cardbus cards. Could you review and commit this if OK? Thanks Index: pccbb.c === RCS file: /home/ncvs/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.59 diff -u -r1.59 pccbb.c --- pccbb.c 11 Oct 2002 04:30:59 - 1.59 +++ pccbb.c 21 Oct 2002 11:41:12 - @@ -1918,7 +1918,10 @@ cbb_setb(sc, CBB_SOCKET_MASK, CBB_SOCKET_MASK_CD); /* Force us to go query the socket state */ - cbb_setb(sc, CBB_SOCKET_FORCE, CBB_SOCKET_EVENT_CD); + mtx_lock(sc-mtx); + sc-flags = ~CBB_CARD_OK; + cv_signal(sc-cv); + mtx_unlock(sc-mtx); error = bus_generic_resume(self); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic when booting with USB CF reader
Bernd Walter wrote: On Sat, Sep 28, 2002 at 07:20:08PM -0700, Lars Eggert wrote: I'm seeing a kernel panic on -current (9/26) when booting with a SanDisk ImageMate II USB comact flash reader plugged in. The panic occurs after the kernel has loaded when the first rc.d scripts execute (dumpon, vinum, etc). If I boot with the device disconnected, I can plug it in and unplug it without problems later. Attached is a boot trace and a gdb backtrace. ... I'm seeing the same with a SCSI mo drive. As a short term work around I inserted a media. src from 31th Aug did run and from 21th Sep does not. That workaround is OK. But can you actually mount the USB CF reader? Mine shows up as da2 umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 5 umass0: Get Max Lun not supported (STALLED) da2 at umass-sim0 bus 0 target 0 lun 0 da2: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: 1027MB (2104705 512 byte sectors: 0H 0S/T 0C) but there's only /dev/da2 under /dev, and no entries for the slices. Shouldn't devfs or usbd or something create them automatically, since MAKEDEV is no more? Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: kernel panic when booting with USB CF reader
In message [EMAIL PROTECTED], Lars Eggert writes: umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 5 umass0: Get Max Lun not supported (STALLED) da2 at umass-sim0 bus 0 target 0 lun 0 da2: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: 1027MB (2104705 512 byte sectors: 0H 0S/T 0C) but there's only /dev/da2 under /dev, and no entries for the slices. Shouldn't devfs or usbd or something create them automatically, since MAKEDEV is no more? You can probably trigger a re-examination of the device by opening it for write and closing again. Something as simple as sh -c true 4/dev/da2 may do the trick. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel: lock order reversal
Alex Zepeda wrote: I see this on a fairly regular basis (at least once per 24 hour period): lock order reversal 1st 0xc0490ca0 spechash (spechash) @ ../../../kern/vfs_subr.c:2748 2nd 0xc1ed2818 vnode interlock (vnode interlock) @ ../../../kern/vfs_subr.c:2751 Dunno if it's any help, but it happened at 03:08:50, so right towards the midle of the daily scripts (takes about 20mins here), fairly heavy disk access. FWIW, I'm seeing the exact same issue here, too. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Mon Oct 21 16:04:24 PDT 2002 -- === xe /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:489: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:527: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:604: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards qualifiers from pointer target type /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/ia64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used /home/tinderbox/ia64/src/sys/fs/msdosfs/msdosfs_vfsops.c: In function `mountmsdosfs': /home/tinderbox/ia64/src/sys/fs/msdosfs/msdosfs_vfsops.c:342: structure has no member named `bsPBP' *** Error code 1 Stop in /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
another lock order reversal
lock order reversal 1st 0xc6f47a68 vnode interlock (vnode interlock) @ /usr/src/sys/nfsclient/nfs_vnops.c:2629 2nd 0xc04b8640 vm page queue mutex (vm page queue mutex) @ /usr/src/sys/vm/vm_kern.c:424 Debugger(witness_lock) Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0 db trace Debugger(c0440ebb,c04b8640,c045b97b,c045b97b,c045a890) at Debugger+0x5a witness_lock(c04b8640,8,c045a890,1a8,666a) at witness_lock+0x142 _mtx_lock_flags(c04b8640,0,c045a890,1a8,c6569000) at _mtx_lock_flags+0x63 kmem_malloc(c0832078,1000,1,1,c2389624) at kmem_malloc+0x2cf slab_zalloc(c2389600,1,c6e48000,5c2,c043cc46) at slab_zalloc+0xbd uma_zalloc_internal(c2389600,0,1,c23b3a00,0) at uma_zalloc_internal+0x28e uma_zalloc_arg(c2389600,0,1,c026b13c,c2389600) at uma_zalloc_arg+0x26c malloc(dcc,c0498920,1,a45,c04e8398) at malloc+0x75 nfs_flush(c6f47a68,c7444f00,1,c67d6ea0,1) at nfs_flush+0x8b4 nfs_fsync(eb5b7840,0,c0445ac2,449,200246) at nfs_fsync+0x31 vinvalbuf(c6f47a68,1,c7444f00,c67d6ea0,100) at vinvalbuf+0x380 nfs_vinvalbuf(c6f47a68,1,c7444f00,c67d6ea0,1) at nfs_vinvalbuf+0x16d nfs_open(eb5b79c8,c04e9018,eb5b79ac,100,c67d6ea0) at nfs_open+0x7e vn_open_cred(eb5b7bd4,eb5b7cd4,0,c7444f00,eb5b7cc0) at vn_open_cred+0x306 vn_open(eb5b7bd4,eb5b7cd4,0,28f,c04e8398) at vn_open+0x29 kern_open(c67d6ea0,89e2000,0,1,0) at kern_open+0x197 open(c67d6ea0,eb5b7d10,c0464b1d,42d,c6b7c3e8) at open+0x30 syscall(2f,2f,bfa8002f,4,28d97998) at syscall+0x406 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x28d11673, esp = 0xbfa87cfc, ebp = 0xbfa87d18 --- Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: zombies from linux binaries
Terry Lambert wrote: Linux has the SVR4 behaviour in that, if SIGCHLD is not caught, zombies are reaped automatically, without the parent needing to explicitly reap their exit status. Most likely, they are installing a signal handler of SIG_IGN for SIGCHLD, and expecting the standard behaviour for auto-reaping. Makes sense. This seems to be a bug in -current's Linux emulator then, since the Linux binary works fine under -stable. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
yet another lock order reversal
lock order reversal 1st 0xc791bc00 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 2nd 0xc04974e0 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2156 Debugger(witness_lock) Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0 db trace Debugger(c0440ebb,c04974e0,c043af10,c043af10,c043dc59) at Debugger+0x5a witness_lock(c04974e0,8,c043dc59,86c,eb68bbe8) at witness_lock+0x142 _mtx_lock_flags(c04974e0,0,c043dc59,86c,c029a151) at _mtx_lock_flags+0x63 pgsigio(c7d13ae8,17,0,1ad,0) at pgsigio+0x2d pipe_read(c75a4b04,eb68bc78,c76e6b00,0,c6d24b60) at pipe_read+0x290 dofileread(c6d24b60,c75a4b04,3,bfbfb837,1) at dofileread+0xd7 read(c6d24b60,eb68bd10,c0464b1d,42d,c6d23e68) at read+0x7b syscall(2f,2f,2f,2811ba2b,bfbfb850) at syscall+0x406 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (3, FreeBSD ELF32, read), eip = 0x281666b3, esp = 0xbfbfb81c, ebp = 0xbfbfb878 --- Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] Workaround for bogus INT 12H BIOS service implementation
On Tue, 22 Oct 2002, Mitsuru IWASAKI wrote:
Hmmm, actually no. I know that some machines get panic with fatal trap
12 if we do 0x12 call. The worst case is getting panic, not losing
640K memory.
...
...
FYI: On RELENG_4, this problem is critical too because this panic
isn't recoverable. This means that it's impossible to install onto
some newer machines.
...
I've recalled that FreeBSD used RTC to determine base memory size in
old days. I've tested this method on my machines and confirmed it's
working well.
I'll commit this coming weekend if no objections.
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.541
diff -u -r1.541 machdep.c
--- machdep.c 5 Oct 2002 14:36:14 - 1.541
+++ machdep.c 21 Oct 2002 15:27:02 -
@@ -1284,8 +1284,14 @@
/*
* Perform base memory related probes setup
*/
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ if ((basemem = rtcin(RTC_BASELO) + (rtcin(RTC_BASEHI)8)) 640)
+ basemem = 640;
+
+ if (basemem == 0) {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
+
if (basemem 640) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
basemem);
This would reintroduce a large bug. The RTC gives the hardware memory
size, but the interrupt gives the software memory size. These differ
for one of two machines under my desk (both have Award BIOSes). The
BIOS often steals some of the base memory. It's hard to tell whether
this memory will be used after FreeBSD determines the memory size. It
might be used for VM86 or (much more magically) for SMM.
Reading the memory size from BIOS RAM (offset 0x413) would be safer.
I'm not sure how standard this is. I thought that it is less standard
than INT 0x12.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
rl driver lock order reversal
rl0: RealTek 8139 10/100BaseTX port 0xe800-0xe8ff mem 0xd900-0xd9ff irq 11 at device 12.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 lock order reversal 1st 0xc0f3b1c0 rl0 (network driver) @ ../../../pci/if_rl.c:872 2nd 0xc038a0e0 allproc (allproc) @ ../../../kern/kern_fork.c:316 ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 ../../../vm/uma_core.c:1307: could sleep with rl0 locked from ../../../pci/if_rl.c:872 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rl driver lock order reversal
How recent is your kernel? I thought I'd fixed this in recent current (at least the could sleep with rl0 part). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Building -CURRENT with 4.5-RELEASE
Is it possible, or do I need to use a more recent installation to be able to build -CURRENT? -- Gerhard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rl driver lock order reversal
today's source code David - Original Message - From: M. Warner Losh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 22, 2002 10:20 AM Subject: Re: rl driver lock order reversal How recent is your kernel? I thought I'd fixed this in recent current (at least the could sleep with rl0 part). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Tue Oct 22 01:49:54 GMT 2002 -- === msdosfs /tinderbox/sparc64/src/sys/fs/msdosfs/msdosfs_vfsops.c: In function `mountmsdosfs': /tinderbox/sparc64/src/sys/fs/msdosfs/msdosfs_vfsops.c:342: structure has no member named `bsPBP' *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules/msdosfs. *** Error code 1 Stop in /tinderbox/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rl driver lock order reversal
In message: 00bd01c27972$5eea20f0$ef01a8c0@davidwnt
David Xu [EMAIL PROTECTED] writes:
: today's source code
Looks like I've not committed it. :-(. Also looks like p4 told me
there were no diffs for reasons unknown...
This removes the lock around the attach routine. It isn't needed,
since we can't possibly be reentered until after we register an ISR.
Warner
--- /dell/imp/FreeBSD/src/sys/pci/if_rl.c Mon Oct 7 00:15:08 2002
+++ /dell/imp/p4/newcard/src/sys/pci/if_rl.cFri Oct 18 00:33:53 2002
@@ -869,7 +869,6 @@
mtx_init(sc-rl_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
MTX_DEF | MTX_RECURSE);
- RL_LOCK(sc);
/*
* Handle power management nonsense.
@@ -952,18 +951,6 @@
goto fail;
}
- error = bus_setup_intr(dev, sc-rl_irq, INTR_TYPE_NET,
- rl_intr, sc, sc-rl_intrhand);
-
- if (error) {
- bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
- bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
- printf(rl%d: couldn't set up irq\n, unit);
- goto fail;
- }
-
- callout_handle_init(sc-rl_stat_ch);
-
/* Reset the adapter. */
rl_reset(sc);
sc-rl_eecmd_read = RL_EECMD_READ_6BIT;
@@ -999,7 +986,6 @@
sc-rl_type = RL_8129;
else {
printf(rl%d: unknown device ID: %x\n, unit, rl_did);
- bus_teardown_intr(dev, sc-rl_irq, sc-rl_intrhand);
bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
error = ENXIO;
@@ -1045,7 +1031,6 @@
if (sc-rl_cdata.rl_rx_buf == NULL) {
printf(rl%d: no memory for list buffers!\n, unit);
- bus_teardown_intr(dev, sc-rl_irq, sc-rl_intrhand);
bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
bus_dma_tag_destroy(sc-rl_tag);
@@ -1061,7 +1046,6 @@
if (mii_phy_probe(dev, sc-rl_miibus,
rl_ifmedia_upd, rl_ifmedia_sts)) {
printf(rl%d: MII without any phy!\n, sc-rl_unit);
- bus_teardown_intr(dev, sc-rl_irq, sc-rl_intrhand);
bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
bus_dmamem_free(sc-rl_tag,
@@ -1089,11 +1073,23 @@
* Call MI attach routine.
*/
ether_ifattach(ifp, ETHER_BPF_SUPPORTED);
- RL_UNLOCK(sc);
- return(0);
+ error = bus_setup_intr(dev, sc-rl_irq, INTR_TYPE_NET,
+ rl_intr, sc, sc-rl_intrhand);
+
+ if (error) {
+ printf(rl%d: couldn't set up irq\n, unit);
+ bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
+ bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
+ bus_dmamem_free(sc-rl_tag,
+ sc-rl_cdata.rl_rx_buf, sc-rl_cdata.rl_rx_dmamap);
+ bus_dma_tag_destroy(sc-rl_tag);
+ goto fail;
+ }
+
+ callout_handle_init(sc-rl_stat_ch);
+ return(0);
fail:
- RL_UNLOCK(sc);
mtx_destroy(sc-rl_mtx);
return(error);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: yet another lock order reversal
On 21 Oct, Lars Eggert wrote: lock order reversal 1st 0xc791bc00 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 2nd 0xc04974e0 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2156 I've been complaining about that one for ages. I think I know how I want to attack it, but I still need to do some more analysis. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rl driver lock order reversal
- Original Message -
From: M. Warner Losh [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, October 22, 2002 10:40 AM
Subject: Re: rl driver lock order reversal
In message: 00bd01c27972$5eea20f0$ef01a8c0@davidwnt
David Xu [EMAIL PROTECTED] writes:
: today's source code
Looks like I've not committed it. :-(. Also looks like p4 told me
there were no diffs for reasons unknown...
This removes the lock around the attach routine. It isn't needed,
since we can't possibly be reentered until after we register an ISR.
Warner
--- /dell/imp/FreeBSD/src/sys/pci/if_rl.c Mon Oct 7 00:15:08 2002
+++ /dell/imp/p4/newcard/src/sys/pci/if_rl.c Fri Oct 18 00:33:53 2002
@@ -869,7 +869,6 @@
mtx_init(sc-rl_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK,
MTX_DEF | MTX_RECURSE);
- RL_LOCK(sc);
/*
* Handle power management nonsense.
@@ -952,18 +951,6 @@
goto fail;
}
- error = bus_setup_intr(dev, sc-rl_irq, INTR_TYPE_NET,
- rl_intr, sc, sc-rl_intrhand);
-
- if (error) {
- bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
- bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
- printf(rl%d: couldn't set up irq\n, unit);
- goto fail;
- }
-
- callout_handle_init(sc-rl_stat_ch);
-
/* Reset the adapter. */
rl_reset(sc);
sc-rl_eecmd_read = RL_EECMD_READ_6BIT;
@@ -999,7 +986,6 @@
sc-rl_type = RL_8129;
else {
printf(rl%d: unknown device ID: %x\n, unit, rl_did);
- bus_teardown_intr(dev, sc-rl_irq, sc-rl_intrhand);
bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
error = ENXIO;
@@ -1045,7 +1031,6 @@
if (sc-rl_cdata.rl_rx_buf == NULL) {
printf(rl%d: no memory for list buffers!\n, unit);
- bus_teardown_intr(dev, sc-rl_irq, sc-rl_intrhand);
bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
bus_dma_tag_destroy(sc-rl_tag);
@@ -1061,7 +1046,6 @@
if (mii_phy_probe(dev, sc-rl_miibus,
rl_ifmedia_upd, rl_ifmedia_sts)) {
printf(rl%d: MII without any phy!\n, sc-rl_unit);
- bus_teardown_intr(dev, sc-rl_irq, sc-rl_intrhand);
bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
bus_dmamem_free(sc-rl_tag,
@@ -1089,11 +1073,23 @@
* Call MI attach routine.
*/
ether_ifattach(ifp, ETHER_BPF_SUPPORTED);
- RL_UNLOCK(sc);
- return(0);
+ error = bus_setup_intr(dev, sc-rl_irq, INTR_TYPE_NET,
+ rl_intr, sc, sc-rl_intrhand);
+
+ if (error) {
+ printf(rl%d: couldn't set up irq\n, unit);
+ bus_release_resource(dev, SYS_RES_IRQ, 0, sc-rl_irq);
+ bus_release_resource(dev, RL_RES, RL_RID, sc-rl_res);
+ bus_dmamem_free(sc-rl_tag,
+ sc-rl_cdata.rl_rx_buf, sc-rl_cdata.rl_rx_dmamap);
+ bus_dma_tag_destroy(sc-rl_tag);
+ goto fail;
+ }
+
+ callout_handle_init(sc-rl_stat_ch);
+ return(0);
fail:
- RL_UNLOCK(sc);
mtx_destroy(sc-rl_mtx);
return(error);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Thanks, it works fine.
David
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
if_dc: ethernet address now reported as 00:00:00:00:00:00
I upgraded one of my older boxes with a Linksys ethernet card this evening, and was a bit surprised to see this in dmesg: dc0: LC82C115 PNIC II 10/100BaseTX port 0xe800-0xe8ff mem 0xfebfff00-0xfebf irq 9 at device 19.0 on pci0 dc0: Ethernet address: 00:00:00:00:00:00 miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto This wasn't the case a month or two ago when the box was last upgraded. I'm going to look into backing out some of the recent commits to if_dc and see if that helps, but I have to say this result isn't thrilling :-). Interestingly, IP works, although it's probably making a mess of the CPU load on the surrounding machines: curry:~ arp -a ... ? (192.168.11.227) at 00:00:00:00:00:00 on xl0 [ethernet] Another problem I've had with this card for years is that it can't properly negotiation 100mbps, although around 3.0-current, it could. No time to track that down either. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
+ if ((basemem = rtcin(RTC_BASELO) + (rtcin(RTC_BASEHI)8)) 640)
+ basemem = 640;
+
+ if (basemem == 0) {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
+
if (basemem 640) {
printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
basemem);
This would reintroduce a large bug. The RTC gives the hardware memory
size, but the interrupt gives the software memory size. These differ
for one of two machines under my desk (both have Award BIOSes). The
BIOS often steals some of the base memory. It's hard to tell whether
this memory will be used after FreeBSD determines the memory size. It
might be used for VM86 or (much more magically) for SMM.
Reading the memory size from BIOS RAM (offset 0x413) would be safer.
I'm not sure how standard this is. I thought that it is less standard
than INT 0x12.
OK, RELENG_3 GENERIC kernel might have problems with base memory, RTC
was used there...
How about this? It's my original idea.
Thanks
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.542
diff -u -r1.542 machdep.c
--- machdep.c 12 Oct 2002 05:32:23 - 1.542
+++ machdep.c 22 Oct 2002 03:04:15 -
@@ -1281,49 +1281,7 @@
bzero(vmf, sizeof(struct vm86frame));
bzero(physmap, sizeof(physmap));
-
- /*
-* Perform base memory related probes setup
-*/
- vm86_intcall(0x12, vmf);
- basemem = vmf.vmf_ax;
- if (basemem 640) {
- printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
- basemem);
- basemem = 640;
- }
-
- /*
-* XXX if biosbasemem is now 640, there is a `hole'
-* between the end of base memory and the start of
-* ISA memory. The hole may be empty or it may
-* contain BIOS code or data. Map it read/write so
-* that the BIOS can write to it. (Memory from 0 to
-* the physical end of the kernel is mapped read-only
-* to begin with and then parts of it are remapped.
-* The parts that aren't remapped form holes that
-* remain read-only and are unused by the kernel.
-* The base memory area is below the physical end of
-* the kernel and right now forms a read-only hole.
-* The part of it from PAGE_SIZE to
-* (trunc_page(biosbasemem * 1024) - 1) will be
-* remapped and used by the kernel later.)
-*
-* This code is similar to the code used in
-* pmap_mapdev, but since no memory needs to be
-* allocated we simply change the mapping.
-*/
- for (pa = trunc_page(basemem * 1024);
-pa ISA_HOLE_START; pa += PAGE_SIZE)
- pmap_kenter(KERNBASE + pa, pa);
-
- /*
-* if basemem != 640, map pages r/w into vm86 page table so
-* that the bios can scribble on it.
-*/
- pte = (pt_entry_t *)vm86paddr;
- for (i = basemem / 4; i 160; i++)
- pte[i] = (i PAGE_SHIFT) | PG_V | PG_RW | PG_U;
+ basemem = 0;
/*
* map page 1 R/W into the kernel page table so we can use it
@@ -1391,6 +1349,60 @@
physmap[physmap_idx + 1] = smap-base + smap-length;
next_run: ;
} while (vmf.vmf_ebx != 0);
+
+ /*
+* Perform base memory related probes setup
+*/
+ for (i = 0; i = physmap_idx; i += 2) {
+ if (physmap[i] == 0x) {
+ basemem = physmap[i + 1] / 1024;
+ break;
+ }
+ }
+
+ /* Fall back to the old compatibility function for base memory */
+ if (basemem == 0) {
+ vm86_intcall(0x12, vmf);
+ basemem = vmf.vmf_ax;
+ }
+
+ if (basemem 640) {
+ printf(Preposterous BIOS basemem of %uK, truncating to 640K\n,
+ basemem);
+ basemem = 640;
+ }
+
+ /*
+* XXX if biosbasemem is now 640, there is a `hole'
+* between the end of base memory and the start of
+* ISA memory. The hole may be empty or it may
+* contain BIOS code or data. Map it read/write so
+* that the BIOS can write to it. (Memory from 0 to
+* the physical end of the kernel is mapped read-only
+* to begin with and then parts of it are remapped.
+* The parts that aren't remapped form holes that
+* remain read-only and are unused by the kernel.
+* The base memory area is below the physical end of
+* the kernel and right now forms a read-only hole.
+* The part of it from PAGE_SIZE to
+* (trunc_page(biosbasemem * 1024) - 1) will be
+* remapped and used by the kernel
Re: if_dc: ethernet address now reported as 00:00:00:00:00:00
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : dc0: LC82C115 PNIC II 10/100BaseTX port 0xe800-0xe8ff mem : 0xfebfff00-0xfebf irq 9 at device 19.0 on pci0 : dc0: Ethernet address: 00:00:00:00:00:00 Maybe this is due to if_dcreg.h 1.27 and/or if_dc.c 1.80. Can you back out those and try again? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_dc: ethernet address now reported as 00:00:00:00:00:00
I have the same problem using a Linksys LNE100TX which uses the dc driver. I also started having problems crashing when using an SMP kernel with the same cvsup. I'm not sure if they're in anyway related. -- scott - Original Message - From: Robert Watson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 21, 2002 11:11 PM Subject: if_dc: ethernet address now reported as 00:00:00:00:00:00 I upgraded one of my older boxes with a Linksys ethernet card this evening, and was a bit surprised to see this in dmesg: dc0: LC82C115 PNIC II 10/100BaseTX port 0xe800-0xe8ff mem 0xfebfff00-0xfebf irq 9 at device 19.0 on pci0 dc0: Ethernet address: 00:00:00:00:00:00 miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto This wasn't the case a month or two ago when the box was last upgraded. I'm going to look into backing out some of the recent commits to if_dc and see if that helps, but I have to say this result isn't thrilling :-). Interestingly, IP works, although it's probably making a mess of the CPU load on the surrounding machines: curry:~ arp -a ... ? (192.168.11.227) at 00:00:00:00:00:00 on xl0 [ethernet] Another problem I've had with this card for years is that it can't properly negotiation 100mbps, although around 3.0-current, it could. No time to track that down either. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_dc: ethernet address now reported as 00:00:00:00:00:00
I have the same problem using a Linksys LNE100TX which uses the dc driver. I also started having problems crashing when using an SMP kernel with the same cvsup. I'm not sure if they're in anyway related. -- scott - Original Message - From: Robert Watson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 21, 2002 11:11 PM Subject: if_dc: ethernet address now reported as 00:00:00:00:00:00 I upgraded one of my older boxes with a Linksys ethernet card this evening, and was a bit surprised to see this in dmesg: dc0: LC82C115 PNIC II 10/100BaseTX port 0xe800-0xe8ff mem 0xfebfff00-0xfebf irq 9 at device 19.0 on pci0 dc0: Ethernet address: 00:00:00:00:00:00 miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto This wasn't the case a month or two ago when the box was last upgraded. I'm going to look into backing out some of the recent commits to if_dc and see if that helps, but I have to say this result isn't thrilling :-). Interestingly, IP works, although it's probably making a mess of the CPU load on the surrounding machines: curry:~ arp -a ... ? (192.168.11.227) at 00:00:00:00:00:00 on xl0 [ethernet] Another problem I've had with this card for years is that it can't properly negotiation 100mbps, although around 3.0-current, it could. No time to track that down either. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: yet another lock order reversal
On Mon, 21 Oct 2002, Lars Eggert wrote: lock order reversal 1st 0xc791bc00 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 2nd 0xc04974e0 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2156 It strikes me that, for better or for worse, the reported reversal is the right way around, and the prior access was the wrong one. It may be possible to extract the locking locations of the prior order using 'show witness' in ddb. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_dc: ethernet address now reported as 00:00:00:00:00:00
On Mon, 21 Oct 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : dc0: LC82C115 PNIC II 10/100BaseTX port 0xe800-0xe8ff mem : 0xfebfff00-0xfebf irq 9 at device 19.0 on pci0 : dc0: Ethernet address: 00:00:00:00:00:00 Maybe this is due to if_dcreg.h 1.27 and/or if_dc.c 1.80. Can you back out those and try again? Backing out to 1.77 restored the ethernet address: dc0: LC82C115 PNIC II 10/100BaseTX port 0xe800-0xe8ff mem 0xfebfff00-0xfebf irq 9 at device 19.0 on pci0 dc0: Ethernet address: 00:a0:cc:35:3e:56 miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 I'll try sliding forward until things don't work so well anymore.. I don't suppose anyone has any thoughts on the failure to negotiate 100mbps? That's a long term problem I've had with this line of cards, which used to work fine. The switch light flashes on and off rapidly, but I have't worked on it much more than that. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dedicating an interrupt to a PC-Card slot
In message: [EMAIL PROTECTED]
Kenneth P. Stox [EMAIL PROTECTED] writes:
: Well, I decided to have some fun and see if I could get a Novatel Merlin
: C-201 wireless modem running under FreeBSD. It seems I have run into a
: bit of a roadblock. It appears that the C-201 will only speak, through
: it's 16550 UART, at a speed of 230400. As such it need to have fast
: interrupt support, which only seems possible with a dedicated interrupt.
: ACPI and NEWCARD assigns the same interrupt to both of the Cardbus
: bridges and to other PCI devices.
No, the cbb and cardbus drivers do it. You aren't allowed to not
share. Non-fast interrupts would be fine on a fast enough machine, or
if our interrupt mechanism didn't use Giant. You might be able to get
some machines to work with ISA interrupts, but it would be a lot of
work to make work with NEWCARD. You can test this hypothesis by
running an OLDCARD kernel, which has some support for doing this.
However, I don't plan on supporting that in NEWCARD because it is a
royal pain in the backside and generally not needed. As the interrupt
latency gets smaller in current, the need will become even less.
Also, you don't have to talk to the UART at 230400. I didn't think
that sio supported such a fast baud rate, since the standard clock
divisor maxes at at 115200, or have you hacked sio to have a faster
baud clock?
However, you can also hack pccbb to allow the fast interrupt. Given
that the card isn't coming and going, it should be safe to have
pccbb's interrupt be fast. Since pccbb does the calling of the
ISR(s), it wouldn't really be sharing things and could likely be made
to work. Since we do at most 2 PCI reads in the ISR (and typically
one), the delay should be well within the tolerance of the device.
There are some issues with purity of doing this that shouldn't matter
in this case so long as there's only one CardBus Bridge in the system.
So long as you don't have a second card, it should work.
There are those that have a different view, but maybe you should try
the above. I think that it would be about 10 lines of diffs to pccbb.
However, if you can't assign a dedicated interrupt to the cardbus
bridge, it might work. This compiles, but I've not tried it out.
Have fun.
//depot/user/imp/newcard/dev/pccbb/pccbb.c#31 -
/dell/imp/p4/newcard/src/sys/dev/pccbb/pccbb.c
@@ -662,8 +662,8 @@
return (ENOMEM);
}
- if (bus_setup_intr(brdev, sc-irq_res, INTR_TYPE_AV, cbb_intr, sc,
- sc-intrhand)) {
+ if (bus_setup_intr(brdev, sc-irq_res, INTR_TYPE_AV | INTR_FAST,
+ cbb_intr, sc, sc-intrhand)) {
device_printf(brdev, couldn't establish interrupt);
goto err;
}
@@ -782,6 +782,7 @@
struct cbb_intrhand *ih;
struct cbb_softc *sc = device_get_softc(dev);
+#if 0
/*
* You aren't allowed to have fast interrupts for pccard/cardbus
* things since those interrupts are PCI and shared. Since we use
@@ -790,6 +791,7 @@
*/
if ((flags INTR_FAST) != 0)
return (EINVAL);
+#endif
ih = malloc(sizeof(struct cbb_intrhand), M_DEVBUF, M_NOWAIT);
if (ih == NULL)
return (ENOMEM);
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: yet another lock order reversal
On 21 Oct, Robert Watson wrote: On Mon, 21 Oct 2002, Lars Eggert wrote: lock order reversal 1st 0xc791bc00 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 2nd 0xc04974e0 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2156 It strikes me that, for better or for worse, the reported reversal is the right way around, and the prior access was the wrong one. It may be possible to extract the locking locations of the prior order using 'show witness' in ddb. I did that back in July and posted it to the list: sigio - process group - process - filedesc - pipe The recent locking changes in the kqueue code run into the same problem. I think it is probably easier to fix this in the pipe code by dropping the pipe lock before calling pipeselwakeup() and relocking afterwards if necessary. The nasty bits are recovering if another process mucks with the pipe while the lock was dropped and figuring out how to rejigger the locking of the pipe_state flags that pipeselwakeup() plays with. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_dc: ethernet address now reported as 00:00:00:00:00:00
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : : On Mon, 21 Oct 2002, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Robert Watson [EMAIL PROTECTED] writes: : : dc0: LC82C115 PNIC II 10/100BaseTX port 0xe800-0xe8ff mem : : 0xfebfff00-0xfebf irq 9 at device 19.0 on pci0 : : dc0: Ethernet address: 00:00:00:00:00:00 : : Maybe this is due to if_dcreg.h 1.27 and/or if_dc.c 1.80. Can you back : out those and try again? : : I stepped from 1.77 forwards, and when I hit 1.80, the ethernet zeroing : returned, so that seems to be the culprit. I'm heading to bed, but can : diagnose more in the morning. OK. I'll take a look to see if I can see anything... It fixed a few cards, but alas broke yours :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Bad system call: aio_read()
On Sat, Oct 12, 2002 at 09:26:52PM +0200, Philipp Mergenthaler wrote: Where is stuff like this documented for end-users? AFAIK right now it is only documented in sys/conf/NOTES. I've sent PR docs/39748 some time back which has a patch similar to yours (I forgot about the module, though). I submitted a followup to your PR: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=102141+0+current/freebsd-doc The patch I submitted gives information for adding the kernel config option VFS_AIO, or doing a kldload aio in order to get aio. Hopefully this patch is OK enough to be applied. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
