Sea-River
Title: Untitled Document Bonjour, vous aimez la pêche et le milieu aquatique ? Hi, you like the fishing and the environment ? Gratuit, chaque semaine en français : La Lettre de Sea-River Gratuit, chaque mois : La Lettre européenne de Sea-River Free, every month : The Sea-River's European Letter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Death sentence to KLD screen savers? Comments?
This is to propose to abolish KLD screen saver modules. KLD screen savers have the following problems/deficiencies. - It is too easy to abuse the power of being run in the kernel mode. The screen saver is invoked periodically once the console becomes idle. It should not spend long time to draw something to the screen. But, we may be tempted to do a bit more elaborate drawing so that we get "interesting" effects. It's too easy to degrade the system performance by staying in the screen saver too long. - While it is easy to manipulate the video board in the KLD module (because we can go anywhere and access anything :-), there are limitations. If you want to perform file I/O (to obtain some bitmaps from files), or want to read some sort of configuration file, there is no straight forward way to do so. I propose to have user-land screen savers instead of KLD screen savers. - The user-land screen saver won't degrade system performance. We can run it at lower priority. Even if we write very complicated graphical screen saver, we have no fear of breaking the system. (Unless we write a buggy program which directly manipulates video card hardware...) - The user-land screen saver can access files if necessary. We shall provide the "screen saver daemon" and a set of "screen saver programs." The screen saver daemon will run in the background and periodically checks if the console is idle. When it finds no activity in the console, it will launch a specified "screen saver program." Screen saver programs are ordinaly user programs which act just like our current KLD screen savers, such as daemon_saver, log_saver, blank_saver, etc, which draw something interesting in the screen. The text-mode screen savers (deamon_saver, snake_saver, star_saver) are written by using ncurses. The graphics-mode screen savers (logo_saver, warp_saver, fire_saver, rain_saver) will be written with libvgl. Blank_saver, apm_saver, fade_saver and green_saver are replaced by programs which performs ioctl to the console to implement the same effect as the current KLD version. I will publish sample implementation once VESA support in -CURRENT stabilizes. Any comments? Kazu PS: the splash screen support has to remain in syscons as the splash screen is put up when the kernel starts up... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
Hi, a friend of mine just forwarded this to me. I've just been looking at writing graphical stuff, firstly screen savers for the console using vgl. In fact we were talking about this exact idea just last week. (As my code doesn't like being run in the kernel - because while it's in devel it still does the occasioanal segfault - oops!) So, I've got some work in progress for the application part of this. Are there any plans on how the kernel might go about calling the userland side of this, any docs, need proposals etc ? Personally, I'm in favour, I *hate* the kld interface for screensavers! However, I'm still using 4.3, is there a huge difference with vgl/vesa in -current ? (I assume the userland end would want to use vgl ?) Oh one other thing, it would be nice if a screensaver could be linked to a syscons vty and vgl access could be done without root perms. Or something like that. I particularly like the idea that one could choose their own screensaver if they are logged in and the system can have a default of something else when the tty is waiting on getty. So, I am VERY interested in seeing this move forward and can test things, or perhaps code things, once I've reread the style guide! > I will publish sample implementation once VESA support in -CURRENT > stabilizes. I've got a sample vgl screensaver type app that does a similar thing to fire_saver.c, just not wrapped as a screensaver yet. (It does however use al available CPU right now =)) Steve Roome P.S. I'm not subscribed to this list, so please include me in any replies. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
$B:#$N@83h!"JQ$($F$_$^$;$s$+!)(B
ËRÌ[¸çvµÜ·B
±Ì[ÍDMNÐÉæèzM³êĨèÜ·B
zMðͱ±©ç¨è¢vµÜ·B
http://dmn.tripod.com/?[EMAIL PROTECTED]
±Ì[ÉÖ·éêîÍA±Ì[ÉÔM¹¸A
[EMAIL PROTECTED] ÜŨè¢vµÜ·B
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
ËRÌ[åϸ碽µÜ·BǤ¼¨µº³¢B
±Ì²ÄàÍrngnETChrWlXwüÌûü¯ÌàeÅ·ÌÅA»¡ÌÈ¢ûÍåÏ\µó èܹñA¨èÅ·ªíȳÁĺ³¢B
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
±Ìæ¤ÈûÉÅK¾ÆvíêÜ·B(ÂlIÈl¦ðÜñŢܷB)
ÌÆWJðáXNÅnß½¢û(àÂlÆÒÅQ{ÚÌƵÄnßܵ½B)
¡Ì¶©çXÉXebvAbvµ½¢û(¸_IAoÏIÉL©ÉÈé½ßÉI)
¬³¢¨q³ñðçÄȪçàûüð¾½¢û(lEUßlª¦ÍIÅ êά÷É1àOiµÜ·B)
«Ì²©ªÌ¶ðSzµÄ¢éû(NàâèE¸Æ¦UPÈÇ)
|Cg(ÈɵܷÆ)
@ ûü(ãXÌÝæ¾Â\)
A¤iªUOOO_Èã
B¼ÌTChrWlX©çÌ]üÒ½(M«)
CO[vàÅÍvwÅÌQÁª½¢(Æë~£iH)
D¬Êv½ªùÉN±ÁÄ¢éB(lbgrWlX)
¡¡¡¢EÅåÌC^[lbgEVbsO[ªú{ã¤I¡¡¡
Mûà±ÌVbsO[ÌãXÉÈÁÄA¶UÉnè
á¢Ì¾ð¾±¯é±ÆªoÜ·B
»ÝA}Kâf¦ÂÉfÚ³êÄ¢éLÌñQߪ±ÌrWlXÉQÁ³êÄ¢éûXÌfÚLÅ·B
±ê©ç̬ʪǤÈÁÄ¢©ð¢¿ðµã̬êðImÉÍñŨçêé½ÌûXª±ÌdðxµQÁ³êÄ¢éÌÅ·B
QÁȳÁ½ûXÍFêlÉ©ªÌÔÌ·ÍÍŲÉü©ÁÄæ£ÁĨçêÜ·B
¡ÈçܾQÁ·éÌÉxÍ èܹñA¥ñ¿ð²¿¢½¾«å¨Ìûª^ÊÚÉæègñÅ¢é±ÌrWlXðmÁľ³¢B
V
ÈãÌûà[ªÉÂ\Å·B
µÄ¢¢Á¸ÈrWlXÅÍ èܹñB
rWlXÉgp·éMûêpÌz[y[Wà²pÓ¢½µÜ·B
z[y[W©{@http://www.jp.bigplanet.com
ãLÌz[y[Wª ȽêpÉpÓ³êÜ·Aà¿ëñT[o[à¢èܹñµeiXâXVà·×Ä{ÐÅs¢Ü·B
MûªãXƵĬ÷·é½ßÉBͦÍðɵÝܹñB
±ÌrWlXÖÌQÁÍÂlE@lðâ¢Ü¹ñBPúROª`PÔöAp\Rðg¤ÔªæêêÎnjÅ·I
XgŸƵ½ûâåwET[}E¬éÆÌI[i[³ñª±XÆ
QÁµÄ¢Ü·B(»ÀÉl¶ÏªÏíéÙÇ̾ð¾Ä¢Ü·)
±ÌrWlXÍu¨ðévªûüÉÂȪéÆ¢¤¾¯ÌPÈrWlXÅ
Í èܹñAÚ×Í¿ð²¿Ìã²¾³¢B
ûüÉ¢ÄÚµLÚµÄ èÜ·B
åWúÔÍÀè³êĢܷÌÅ»¡ª èܵ½çA·®É¿ð²¿º³¢B
Ú×ȿͺLz[y[WÌÉ¿¿tH[ªLèÜ·ÌÅKv
ðäLüÌã²Mº³¢B
¡rWlXTv¿z[y[W
@@http://www.ts-network.ne.jp/~ts-net/
¡¡±ÌrWlXÌÁ¥¡¡@åéƪrWlXvðñ
@ ¢EÅåÌuC^[lbgEVbsO[v
A ¢EÌê¬éƪ¤Þðñ
B XNEm}EÝÉEKâÌ@êسµ
C Åæ[ÌlklrWlX(ê´åw¼Å³®ÉöÆÉæèüêĢܷ)
D ¾Í¶Up±(Æ ÍÆ°ÉÌݱÂ\)
E ȘÍ̧
F@rngn(X[ItBXEz[ItBX)âTChrWlXÅÂ\
G@QÁÉÁÊÈiÍKvȵ
Ú׿𲸢½ãÅA^â_ⲿ⪲´¢Üµ½ç¨CyɺLÜÅ
¨ â ¢í¹¾³¢B
ÅãÜŨÇÝ¢½¾«A½É èªÆ¤²´¢Üµ½B
Ts-NET i`o`mCb
S@àVÄéq
Lp@z[y[W@ http://www.ts-network.ne.jp/~ts-net/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
build problem ?
hi ! i cvsuped 20 minutes ago. when i try to build (-j 6), it says: -- lex -t -I /usr/build/src/usr.sbin/pcvt/kbdio/lex.l > lex.c yacc: 2 shift/reduce conflicts cp y.tab.c kbdio.c rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/build/obj/usr/build/src/usr.sbin/pcvt/kbdio -I/usr/build/src/usr.sbin/pcvt/kbdio -I/usr/obj/usr/build/src/i386/usr /include kbdio.c lex.c cd /usr/build/src/usr.sbin/pcvt/kbdio; make _EXTRADEPEND echo kbdio: /usr/obj/usr/build/src/i386/usr/lib/libc.a /usr/obj/usr/build/src/i386/usr/lib/libm.a /usr/obj/usr/build/src/i386/usr/lib/liby.a /usr/obj/usr /build/src/i386/usr/lib/libl.a >> .depend ===> usr.sbin/pcvt/demo rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/pcvt/demo/playvt.c cd /usr/build/src/usr.sbin/pcvt/demo; make _EXTRADEPEND echo playvt: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/pcvt/Misc ===> usr.sbin/pcvt/Misc/Doc ===> usr.sbin/pcvt/Misc/Etc ===> usr.sbin/sgsc rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/sgsc/sgsc.c cd /usr/build/src/usr.sbin/sgsc; make _EXTRADEPEND echo sgsc: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/sicontrol rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/build/src/usr.sbin/sicontrol/../../sys -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/sicontro l/sicontrol.c cd /usr/build/src/usr.sbin/sicontrol; make _EXTRADEPEND echo sicontrol: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/spkrtest ===> usr.sbin/stallion ===> usr.sbin/stallion/bootcode ===> usr.sbin/stallion/stlload rm -f .depend mkdep -f .depend -a -nostdinc -DBOOTDIR=\"/usr/libdata/stallion\" -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/stallion/stlload/s tlload.c cd /usr/build/src/usr.sbin/stallion/stlload; make _EXTRADEPEND echo stlload: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/stallion/stlstats rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/stallion/stlstats/stlstats.c cd /usr/build/src/usr.sbin/stallion/stlstats; make _EXTRADEPEND echo stlstats: /usr/obj/usr/build/src/i386/usr/lib/libc.a /usr/obj/usr/build/src/i386/usr/lib/libncurses.a >> .depend ===> usr.sbin/wlconfig rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/wlconfig/wlconfig.c cd /usr/build/src/usr.sbin/wlconfig; make _EXTRADEPEND echo wlconfig: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/boot0cfg rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/boot0cfg/boot0cfg.c cd /usr/build/src/usr.sbin/boot0cfg; make _EXTRADEPEND echo boot0cfg: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend 1 error *** Error code 2 1 error *** Error code 2 1 error -- i couln't find the exact error point... i have a full make.out (make -j 6 buildworld) at http://www.deep-ocean.net/~olive/files/make.out if you want to look at it. i know broken builds are frequent under -CURRENT, but i couldn't figure the source of this one. advises are welcome. (at http://www.deep-ocean.net/~olive/files/, i'll put a dmesg.out, my kernel file (renamed kernel.out ; otherwise it is NEPTUNE). It's always good to have them near.) and sorry for my approximate english, it's not my native language. regards, --- Olivier Cortes To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: build problem ?
From: "Olivier Cortes" <[EMAIL PROTECTED]> > i cvsuped 20 minutes ago. > > when i try to build (-j 6), it says: > > > i couln't find the exact error point... i have a full make.out (make > -j 6 buildworld) at http://www.deep-ocean.net/~olive/files/make.out if > you want to look at it. > > i know broken builds are frequent under -CURRENT, but i couldn't > figure the source of this one. advises are welcome. > When you have a build failure using -j x (x > 1), you need to restart the build without -j in order to get any meaningful info from the build failure. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
In standard FreeBSD the moving of screen savers to userland may not be a big deal. In Embedded applications it is nice to be able to create very lightweight (read size) screen savers. Hopefully this new mechanism will still allow this. (-; Larry -- Larry Baird| http://www.gnatbox.com Global Technology Associates, Inc. | Orlando, FL Email: [EMAIL PROTECTED] | TEL 407-380-0220, FAX 407-380-6080 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
device.hints
I want to experiment with current. All went well on the build, but when I try and install the kernel it stops telling me to install a "device.hints" file. What do I need to do? I tried re-compiling the kernel with the "static" line uncomented, but same problem on install. TIA, Beech -- Micro$oft: "Where can we make you go today?" --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: device.hints
On Tue, 24 Jul 2001, Beech Rintoul wrote: > I want to experiment with current. All went well on the build, but when I try > and install the kernel it stops telling me to install a "device.hints" file. > What do I need to do? I tried re-compiling the kernel with the "static" line > uncomented, but same problem on install. What you need to do is before installing the kernel... cp -p /usr/src/sys/i386/conf/GENERIC.hints /boot/device.hints Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: device.hints
On Tue, Jul 24, 2001 at 11:23:16AM -0800, Beech Rintoul wrote: > I want to experiment with current. All went well on the build, but when I try > and install the kernel it stops telling me to install a "device.hints" file. > What do I need to do? I tried re-compiling the kernel with the "static" line > uncomented, but same problem on install. The short answer is that you can copy sys/i386/conf/GENERIC.hints to /boot/device.hints. If you have devices that you have needed to configured in your kernel or with userconfig you may need to add or modify this file somewhat. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: device.hints
On Tue, Jul 24, 2001 at 11:23:16AM -0800, Beech Rintoul wrote: > I want to experiment with current. All went well on the build, but when I try > and install the kernel it stops telling me to install a "device.hints" file. > What do I need to do? I tried re-compiling the kernel with the "static" line > uncomented, but same problem on install. Do what it asks you: copy GENERIC.hints into the right spot as boot.hints -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte "Youth is not a time in life, it is a state of mind" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: device.hints
On Tuesday 24 July 2001 11:23 am, Beech Rintoul wrote: > I want to experiment with current. All went well on the build, but when I > try and install the kernel it stops telling me to install a "device.hints" > file. What do I need to do? I tried re-compiling the kernel with the > "static" line uncomented, but same problem on install. > > TIA, > > Beech Thanks much :-) Beech -- Micro$oft: "Where can we make you go today?" --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re: build problem ?
On Tue, Jul 24, 2001 at 01:47:07PM -0500, Scot W. Hetzel wrote: > When you have a build failure using -j x (x > 1), you need to restart the > build without -j in order to get any meaningful info from the build failure. fool, fool, fool am i. here it is : -- mkdep -f .depend -a -nostdinc -DDISASSEMBLER -DNO_X -I/usr/obj/usr/build/src/i 386/usr/include /usr/build/src/usr.bin/doscmd/AsyncIO.c /usr/build/src/usr.bin/ doscmd/ParseBuffer.c /usr/build/src/usr.bin/doscmd/bios.c /usr/build/src/usr.bin /doscmd/callback.c /usr/build/src/usr.bin/doscmd/cpu.c /usr/build/src/usr.bin/do scmd/dos.c /usr/build/src/usr.bin/doscmd/cmos.c /usr/build/src/usr.bin/doscmd/co nfig.c /usr/build/src/usr.bin/doscmd/cwd.c /usr/build/src/usr.bin/doscmd/debug.c /usr/build/src/usr.bin/doscmd/disktab.c /usr/build/src/usr.bin/doscmd/doscmd.c /usr/build/src/usr.bin/doscmd/ems.c /usr/build/src/usr.bin/doscmd/emuint.c /usr/ build/src/usr.bin/doscmd/exe.c /usr/build/src/usr.bin/doscmd/i386-pinsn.c /usr/b uild/src/usr.bin/doscmd/int.c /usr/build/src/usr.bin/doscmd/int10.c /usr/build/s rc/usr.bin/doscmd/int13.c /usr/build/src/usr.bin/doscmd/int14.c /usr/build/src/u sr.bin/doscmd/int16.c /usr/build/src/usr.bin/doscmd/int17.c /usr/build/src/usr.b in/doscmd/int1a.c /usr/build/src/usr.bin/doscmd/int2f.c /usr/build/src/usr.bin/d oscmd/intff.c /usr/build/src/usr.bin/doscmd/mem.c /usr/build/src/usr.bin/doscmd/ mouse.c /usr/build/src/usr.bin/doscmd/net.c /usr/build/src/usr.bin/doscmd/port.c /usr/build/src/usr.bin/doscmd/setver.c /usr/build/src/usr.bin/doscmd/signal.c / usr/build/src/usr.bin/doscmd/timer.c /usr/build/src/usr.bin/doscmd/trace.c /usr/ build/src/usr.bin/doscmd/trap.c /usr/build/src/usr.bin/doscmd/tty.c /usr/build/s rc/usr.bin/doscmd/video.c /usr/build/src/usr.bin/doscmd/xms.c /usr/build/src/usr.bin/doscmd/tty.c:66: font8x8.h: No such file or directory /usr/build/src/usr.bin/doscmd/tty.c:67: font8x14.h: No such file or directory /usr/build/src/usr.bin/doscmd/tty.c:68: font8x16.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/build/src/usr.bin/doscmd. *** Error code 1 Stop in /usr/build/src/usr.bin. *** Error code 1 Stop in /usr/build/src. *** Error code 1 Stop in /usr/build/src. *** Error code 1 Stop in /usr/build/src. - yesterday, the kernel didn't compile, but world did. today it's the contrary... thanks for the advice. sure i must have done it BEFORE sending the mail. sorry. Olivier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
This look familiar to anyone? (bug in 4.11 maybe)
I know this is not a -current problem, but if it was fixed by someone they
are likely to be reading here, and not in -stable..
We have a hybrid (4.11+patches) kernel that sometimes crashes.
The crash always has teh same symptoms and I'm hoping that
they look familiar to someone...
The message is below, followed by analysis.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xe6b95cc8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01846d9
stack pointer = 0x10:0xc954de64
frame pointer = 0x10:0xc954de84
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 = 10326 (qftListener)
interrupt mask = none
trap number = 12
In a VFS operation, %ecx get's corrupted (maybe from an interrupt?)
betweeen the instruction where it's loaded with a constant,
and the instruction where it's used... It'always the same instruction,
though often in DIFFERENT VFS instructions (fsync, bwrite so far)
the trap frame usually looks like:
#4 0xc0251813 in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10,
tf_edi = 0x0, tf_esi = 0x1, tf_ebp = 0xc954de84,
tf_isp = 0xc954de50, tf_ebx = 0xc27d6d80, tf_edx = 0xc1344600,
tf_ecx = 0xc96145b2, tf_eax = 0xc954de78, tf_trapno = 0xc,
tf_err = 0x0, tf_eip = 0xc01846d9, tf_cs = 0x8, tf_eflags = 0x10286,
tf_esp = 0xc954de78, tf_ss = 0xc27d6d80})
at /usr/src/sys/i386/i386/trap.c:443
#5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923
#6 0xc0189be2 in vop_stdbwrite (ap=0xc954deb4) at
/usr/src/sys/kern/vfs_default.c:319
the code there looks like:
(kgdb) up 5
#5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923
923 rc = VCALL(vp, VOFFSET(vop_strategy), &a);
(kgdb) list
918 struct vop_strategy_args a;
919 int rc;
920 a.a_desc = VDESC(vop_strategy);
921 a.a_vp = vp;
922 a.a_bp = bp;
923 rc = VCALL(vp, VOFFSET(vop_strategy), &a); <---here
924 return (rc);
925 }
926 struct vop_print_args {
927 struct vnodeop_desc *a_desc;
In Assembler:
0xc01846cc :mov0xc029dcc0,%ecx
0xc01846d2 :mov0x18(%eax),%edx
0xc01846d5 :lea0xfff4(%ebp),%eax
0xc01846d8 :push %eax
0xc01846d9 :mov(%edx,%ecx,4),%eax < **POW**
0xc01846dc :call *%eax
0xc01846de :add$0x4,%esp
0xc01846e1 :mov0xfff0(%ebp),%eax
looking at the regs,
dx = 0xc1344600,
cx = 0xc96145b2,
and
C1344600+(4*C96145B2) = 3E6B95CC8
the lower 32 bits of which is the same as the fault address
but in the code above we see that %cx was just loaded from
location 0xc029dcc0 which contains:
(kgdb) x/x 0xc029dcc0
0xc029dcc0 : 0x12
0x12 is the correct offset for a strategy call.
so cx got corrupted between the instruction at 0xc01846cc
and that at 0xc01846d9.
Note that the contents of cx (0xc96145b2) is an address
somewhat higher than the kernel stack at the time in question.
a dump of ram in that area shows:
(kgdb) x/64xw 0xc96145a0
0xc96145a0: 0xc954e900 0xc9709c00 0x 0xc96145a8
0xc96145b0:[0xc9580660] 0xc95c7370 0xc04d7504 0xc04d47d4
0xc96145c0: 0xaa26 0x0020 0x 0x
0xc96145d0: 0xfc812c38 0x0002 0x00040010 0x0020
0xc96145e0: 0x 0x 0x 0x
0xc96145f0: 0x 0xc9636a40 0x0001fc93 0x
0xc9614600: 0xc02ed7c0 0xc95b4120 0x 0xc9614608
0xc9614610: 0x 0xc948 0x 0xc9614618
0xc9614620: 0x3f5b 0x0003 0x 0x
0xc9614630: 0xfe37c115 0x2188 0x000e 0x
0xc9614640: 0x 0x 0x 0x
0xc9614650: 0x 0x 0x 0x
0xc9614660: 0xc9722ae0 0xc961c600 0x 0xc9614668
0xc9614670: 0xc9690660 0xc97091f0 0x 0xc9614678
0xc9614680: 0xcabf 0x0012 0x 0x
0xc9614690: 0xfc8189f2 0x0002 0x001d 0x
This is obviously SOMETHING, but what? And why does %cx point HALF WAY
THROUGH an obvious 32 bit pointer?
Thoughts of hardware problems do come to mind... but..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: This look familiar to anyone? (bug in 4.11 maybe)
On 24-Jul-01 Julian Elischer wrote:
>
> In a VFS operation, %ecx get's corrupted (maybe from an interrupt?)
> betweeen the instruction where it's loaded with a constant,
> and the instruction where it's used... It'always the same instruction,
> though often in DIFFERENT VFS instructions (fsync, bwrite so far)
>
> the trap frame usually looks like:
>
>#4 0xc0251813 in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10,
> tf_edi = 0x0, tf_esi = 0x1, tf_ebp = 0xc954de84,
> tf_isp = 0xc954de50, tf_ebx = 0xc27d6d80, tf_edx = 0xc1344600,
> tf_ecx = 0xc96145b2, tf_eax = 0xc954de78, tf_trapno = 0xc,
> tf_err = 0x0, tf_eip = 0xc01846d9, tf_cs = 0x8, tf_eflags = 0x10286,
> tf_esp = 0xc954de78, tf_ss = 0xc27d6d80})
> at /usr/src/sys/i386/i386/trap.c:443
>#5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923
>#6 0xc0189be2 in vop_stdbwrite (ap=0xc954deb4) at
> /usr/src/sys/kern/vfs_default.c:319
>
>
> the code there looks like:
>
> (kgdb) up 5
>#5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923
> 923 rc = VCALL(vp, VOFFSET(vop_strategy), &a);
> (kgdb) list
> 918 struct vop_strategy_args a;
> 919 int rc;
> 920 a.a_desc = VDESC(vop_strategy);
> 921 a.a_vp = vp;
> 922 a.a_bp = bp;
> 923 rc = VCALL(vp, VOFFSET(vop_strategy), &a); <---here
> 924 return (rc);
> 925 }
> 926 struct vop_print_args {
> 927 struct vnodeop_desc *a_desc;
>
> In Assembler:
>
> 0xc01846cc : mov0xc029dcc0,%ecx
> 0xc01846d2 : mov0x18(%eax),%edx
> 0xc01846d5 : lea0xfff4(%ebp),%eax
> 0xc01846d8 : push %eax
> 0xc01846d9 : mov(%edx,%ecx,4),%eax < **POW**
> 0xc01846dc : call *%eax
> 0xc01846de : add$0x4,%esp
> 0xc01846e1 : mov0xfff0(%ebp),%eax
>
> looking at the regs,
> dx = 0xc1344600,
> cx = 0xc96145b2,
> and
> C1344600+(4*C96145B2) = 3E6B95CC8
> the lower 32 bits of which is the same as the fault address
>
> but in the code above we see that %cx was just loaded from
> location 0xc029dcc0 which contains:
> (kgdb) x/x 0xc029dcc0
> 0xc029dcc0 : 0x12
>
> 0x12 is the correct offset for a strategy call.
>
> so cx got corrupted between the instruction at 0xc01846cc
> and that at 0xc01846d9.
Very weird. Note that traps and interrupts will save %ecx in the trapframe,
so you aren't going to end up with those getting corrupted unless we somehow
screw up ecx after popping the frame (or before pushing it).
> Note that the contents of cx (0xc96145b2) is an address
> somewhat higher than the kernel stack at the time in question.
Could be a stack of some other thread. All the 0xc9X addresses are
pointers to automatic variables. The 0xc0[2-4]X are return addresses.
> a dump of ram in that area shows:
> (kgdb) x/64xw 0xc96145a0
> 0xc96145a0: 0xc954e900 0xc9709c00 0x 0xc96145a8
> 0xc96145b0:[0xc9580660] 0xc95c7370 0xc04d7504 0xc04d47d4
> 0xc96145c0: 0xaa26 0x0020 0x 0x
> 0xc96145d0: 0xfc812c38 0x0002 0x00040010 0x0020
> 0xc96145e0: 0x 0x 0x 0x
> 0xc96145f0: 0x 0xc9636a40 0x0001fc93 0x
> 0xc9614600: 0xc02ed7c0 0xc95b4120 0x 0xc9614608
> 0xc9614610: 0x 0xc948 0x 0xc9614618
> 0xc9614620: 0x3f5b 0x0003 0x 0x
> 0xc9614630: 0xfe37c115 0x2188 0x000e 0x
> 0xc9614640: 0x 0x 0x 0x
> 0xc9614650: 0x 0x 0x 0x
> 0xc9614660: 0xc9722ae0 0xc961c600 0x 0xc9614668
> 0xc9614670: 0xc9690660 0xc97091f0 0x 0xc9614678
> 0xc9614680: 0xcabf 0x0012 0x 0x
> 0xc9614690: 0xfc8189f2 0x0002 0x001d 0x
>
> This is obviously SOMETHING, but what? And why does %cx point HALF WAY
> THROUGH an obvious 32 bit pointer?
>
> Thoughts of hardware problems do come to mind... but..
Is it just one machine that does this reliably?
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: build problem ?
Olivier Cortes <[EMAIL PROTECTED]> writes: > fool, fool, fool am i. here it is : > > -- > mkdep -f .depend -a -nostdinc -DDISASSEMBLER -DNO_X -I/usr/obj/usr/build/src/i >386/usr/include Make sure you have usr.bin/doscmd/Makefile version 1.28 (or higher). /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: device.hints
On Tue, Jul 24, 2001 at 12:51:39PM -0800, Beech Rintoul wrote: > > I want to experiment with current. All went well on the build, but when I > > try and install the kernel it stops telling me to install a "device.hints" You should have also read UPDATING. Please start a habit of checking this document if you are going to run -current. 2825: /boot/device.hints is now required for installkernel to succeed. You should copy GENERIC.hints for your architecture into /boot/device.hints. If and only if you compile hints into your kernel, then this file may be empty. Please note, if you have an empty or missing /boot/device.hints file and you neglected to compile hints into your kernel, no boot messages will appear after the boot loader tries to start the kernel. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current logjammed?
I sent a message to here this morning and didn't see it, then again this afternoon. Still haven't seen it come back to me (and no answers) I wonder if I'll see this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpica malfunctions
> > > 1. Acpica modules hangs in > > > AcpiRsCalculateByteStreamLength() called from > > > AcpiRsCreateByteStream() called from > > > AcpiRsSetSrsMethodData() called from > > > AcpiSetCurrentResources() from somewhere in acpi_pcib.c . > > > > > > The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length > == 0 > > > . > > > > Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484? > > I think I should be passing a pointer to the buffer, not a pointer to a > > pointer. > > There's no &crsbuf in line 484 (not in rev 1.10, nor 1.11). > > Assuming you're talking about the one in line 478, it doesn't compile if you > change it to crsbuf from &crsbuf, since crsbuf is an ACPI_BUFFER, not > an (ACPI_BUFFER *). Um. Sorry about the line numbers, and yes, sorry about the confusion there; I just looked at it and it seemed wrong. I'd still like to know the allocation length for that buffer though; my last suspicion is that it doesn't contain any resources at all, and so we're overrunning it when we go to try to stuff an interrupt resource into it. If that's the case, it's easy to fix. If not, then we will have to go hunting snarks. Thanks. Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
On Tue, Jul 24, 2001 at 21:07:40 +0900, Kazutaka YOKOTA wrote: > I propose to have user-land screen savers instead of KLD > screen savers. Good idea. > We shall provide the "screen saver daemon" and a set of "screen saver > programs." The screen saver daemon will run in the background and > periodically checks if the console is idle. When it finds no > activity in the console, it will launch a specified "screen saver > program." No "periodical checks" please. It must wait on poll/select or kqevent or something like, event based, event provided by syscons. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
>> We shall provide the "screen saver daemon" and a set of "screen saver >> programs." The screen saver daemon will run in the background and >> periodically checks if the console is idle. When it finds no >> activity in the console, it will launch a specified "screen saver >> program." > >No "periodical checks" please. It must wait on poll/select or kqevent or >something like, event based, event provided by syscons. Because there already is the CONS_IDLE ioctl, I thought it's easy for the screen saver daemon to use this ioctl. But, if kqevent is preferred, we can do that. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Death sentence to KLD screen savers? Comments?
On Tue, Jul 24, 2001 at 21:34:40 +0900, Kazutaka YOKOTA wrote: > > >> We shall provide the "screen saver daemon" and a set of "screen saver > >> programs." The screen saver daemon will run in the background and > >> periodically checks if the console is idle. When it finds no > >> activity in the console, it will launch a specified "screen saver > >> program." > > > >No "periodical checks" please. It must wait on poll/select or kqevent or > >something like, event based, event provided by syscons. > > Because there already is the CONS_IDLE ioctl, I thought it's > easy for the screen saver daemon to use this ioctl. But, if > kqevent is preferred, we can do that. Maybe I am not clear, but periodical checks is time/resources waste. Sleeping on event wait, swapped out is more preferred, not occupes memory, etc. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
This look familiar to anyone? (bug in 4.11 maybe)
I know this is not a -current problem, but if it was fixed by someone they
are likely to be reading here, and not in -stable..
We have a hybrid (4.11+patches) kernel that sometimes crashes.
The crash always has teh same symptoms and I'm hoping that
they look familiar to someone...
The message is below, followed by analysis.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xe6b95cc8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01846d9
stack pointer = 0x10:0xc954de64
frame pointer = 0x10:0xc954de84
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 = 10326 (qftListener)
interrupt mask = none
trap number = 12
In a VFS operation, %ecx get's corrupted (maybe from an interrupt?)
betweeen the instruction where it's loaded with a constant,
and the instruction where it's used... It'always the same instruction,
though often in DIFFERENT VFS instructions (fsync, bwrite so far)
the trap frame usually looks like:
#4 0xc0251813 in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10,
tf_edi = 0x0, tf_esi = 0x1, tf_ebp = 0xc954de84,
tf_isp = 0xc954de50, tf_ebx = 0xc27d6d80, tf_edx = 0xc1344600,
tf_ecx = 0xc96145b2, tf_eax = 0xc954de78, tf_trapno = 0xc,
tf_err = 0x0, tf_eip = 0xc01846d9, tf_cs = 0x8, tf_eflags = 0x10286,
tf_esp = 0xc954de78, tf_ss = 0xc27d6d80})
at /usr/src/sys/i386/i386/trap.c:443
#5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923
#6 0xc0189be2 in vop_stdbwrite (ap=0xc954deb4) at
/usr/src/sys/kern/vfs_default.c:319
the code there looks like:
(kgdb) up 5
#5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923
923 rc = VCALL(vp, VOFFSET(vop_strategy), &a);
(kgdb) list
918 struct vop_strategy_args a;
919 int rc;
920 a.a_desc = VDESC(vop_strategy);
921 a.a_vp = vp;
922 a.a_bp = bp;
923 rc = VCALL(vp, VOFFSET(vop_strategy), &a); <---here
924 return (rc);
925 }
926 struct vop_print_args {
927 struct vnodeop_desc *a_desc;
In Assembler:
0xc01846cc :mov0xc029dcc0,%ecx
0xc01846d2 :mov0x18(%eax),%edx
0xc01846d5 :lea0xfff4(%ebp),%eax
0xc01846d8 :push %eax
0xc01846d9 :mov(%edx,%ecx,4),%eax < **POW**
0xc01846dc :call *%eax
0xc01846de :add$0x4,%esp
0xc01846e1 :mov0xfff0(%ebp),%eax
looking at the regs,
dx = 0xc1344600,
cx = 0xc96145b2,
and
C1344600+(4*C96145B2) = 3E6B95CC8
the lower 32 bits of which is the same as the fault address
but in the code above we see that %cx was just loaded from
location 0xc029dcc0 which contains:
(kgdb) x/x 0xc029dcc0
0xc029dcc0 : 0x12
0x12 is the correct offset for a strategy call.
so cx got corrupted between the instruction at 0xc01846cc
and that at 0xc01846d9.
Note that the contents of cx (0xc96145b2) is an address
somewhat higher than the kernel stack at the time in question.
a dump of ram in that area shows:
(kgdb) x/64xw 0xc96145a0
0xc96145a0: 0xc954e900 0xc9709c00 0x 0xc96145a8
0xc96145b0:[0xc9580660] 0xc95c7370 0xc04d7504 0xc04d47d4
0xc96145c0: 0xaa26 0x0020 0x 0x
0xc96145d0: 0xfc812c38 0x0002 0x00040010 0x0020
0xc96145e0: 0x 0x 0x 0x
0xc96145f0: 0x 0xc9636a40 0x0001fc93 0x
0xc9614600: 0xc02ed7c0 0xc95b4120 0x 0xc9614608
0xc9614610: 0x 0xc948 0x 0xc9614618
0xc9614620: 0x3f5b 0x0003 0x 0x
0xc9614630: 0xfe37c115 0x2188 0x000e 0x
0xc9614640: 0x 0x 0x 0x
0xc9614650: 0x 0x 0x 0x
0xc9614660: 0xc9722ae0 0xc961c600 0x 0xc9614668
0xc9614670: 0xc9690660 0xc97091f0 0x 0xc9614678
0xc9614680: 0xcabf 0x0012 0x 0x
0xc9614690: 0xfc8189f2 0x0002 0x001d 0x
This is obviously SOMETHING, but what? And why does %cx point HALF WAY
THROUGH an obvious 32 bit pointer?
Thoughts of hardware problems do come to mind... but..
My present line of attack is to change the page-fault handler
to leave a 500 byte window untouched on the stack (except for the
frame) so that I can try see if an interrupt occured
recently, and if so, what it was
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Progress report: KSEs.
David O'Brien wrote: > > On Mon, Jul 23, 2001 at 12:42:49AM -0700, Julian Elischer wrote: > > step 1: get proc structure broken up, with system still running: done (twice) > > Can you post your diff to the proc structure? > > ... > > > -random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct proc *p) > > +random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct thread *td) > > This implies `struct thread' has replaced `struct proc'. (I could be > wrong, but cannot be sure until you post the `struct proc' and related > structure changes/additions) A thread is blockable and anything that might block (e.g. a syscall,( e.g. ioctl)) needs to talk in terms of the thread rather than the process. so, yes, maybe > 50% of uses of "struct proc *p" get changed to "struct thread *td". The proc structure however still exists. > There is no `struct thread' in Jason's KSE paper. > Why aren't you > following the paper > http://people.freebsd.org/~jasone/refs/freebsd_kse/freebsd_kse.html? Well since I made up the terminology in the paper,... because I changed my mind about it? My original posts said.. "lets call these KSEs etc. tillwe are completely sure what they do and can give them better names. The basic unit turns out to be the thread which can be blocked so calling it a KSEC is plain confusing. As you requested, I include my current version of proc.h at http://www.freebsd.org/~julian this is NOT the version that ran under step #1 but rather as it looks now, half way through step #2. > > -- > -- David ([EMAIL PROTECTED]) -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: mutex blocking queues..
this strikes me as avoidable. I'll think about it.. Until then
I guess I'll just have two lists in the thread.. one for sleep and one for
mutexes.
On Mon, 23 Jul 2001, John Baldwin wrote:
>
> On 23-Jul-01 Julian Elischer wrote:
> > Why does the mutex not link blocked processes though the
> > sleep queue linked list entry? Why does it use the run queue entry?
> > In KSEs the sleep queue and run queue enties go into different
> > sub structures and ahve different types so this breaks...
> > do I need to do something sleazy or can I just link them together using the
> > equivalemt of the p_slpq entry?
>
> You can block on a mutex when processing signals in the catch case in msleep()
> after you have put the process on the sleep queue:
>
> int
> msleep(ident, mtx, priority, wmesg, timo)
> {
> ...
> p->p_wchan = ident;
> p->p_wmesg = wmesg;
> p->p_slptime = 0;
> p->p_pri.pri_level = priority & PRIMASK;
> CTR5(KTR_PROC, "msleep: proc %p (pid %d, %s) on %s (%p)", p, p->p_pid,
> p->p_comm, wmesg, ident);
> TAILQ_INSERT_TAIL(&slpque[LOOKUP(ident)], p, p_slpq);
> ...
> /*
> * We put ourselves on the sleep queue and start our timeout
> * before calling CURSIG, as we could stop there, and a wakeup
> * or a SIGCONT (or both) could occur while we were stopped.
> * A SIGCONT would cause us to be marked as SSLEEP
> * without resuming us, thus we must be ready for sleep
> * when CURSIG is called. If the wakeup happens while we're
> * stopped, p->p_wchan will be 0 upon return from CURSIG.
> */
> if (catch) {
> CTR3(KTR_PROC, "msleep caught: proc %p (pid %d, %s)", p,
> p->p_pid, p->p_comm);
> p->p_sflag |= PS_SINTR;
> mtx_unlock_spin(&sched_lock);
> PROC_LOCK(p);
> sig = CURSIG(p);
> mtx_lock_spin(&sched_lock);
> PROC_UNLOCK_NOSWITCH(p);
> ...
>
> If that proc_lock blocks then we don't want to clobber the sleep queue.
>
> --
>
> John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
>
> 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: mutex blocking queues..
Jake Burkholder wrote: > > > Why does the mutex not link blocked processes though the > > sleep queue linked list entry? Why does it use the run queue entry? > > Because in some cases its necessary for a process to acquire > mutexes while its on the sleep queue. If they used the same > linkage the queues would get corrupted. can this be fixed? > > > In KSEs the sleep queue and run queue enties go into different > > sub structures and ahve different types so this breaks... > > do I need to do something sleazy or can I just link them together using the > > equivalemt of the p_slpq entry? > > It seems to me that whatever gets placed on the run queues > should also be what goes on the mutex queues. it would at first glance, but it is not the case when you think about it.. threads sleep/block, but the process is still on the run queue If you put all threads in the run queue, then when one runs you need to remove all the others from the queue and then add them again if they didn't get run at that quanta.. better to add the 'kse' onto the queue once, and hang all it's runnable threads off it.. > > > > > -- > > ++ __ _ __ > > | __--_|\ Julian Elischer | \ U \/ / hard at work in > > | / \ [EMAIL PROTECTED] +-->x USA\ a very strange > > | ( OZ)\___ ___ | country ! > > +- X_.---._/presently in San Francisco \_/ \\ > > v > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current logjammed?
never mind.. found a logjam in an intermediate host.. On Tue, 24 Jul 2001, Julian Elischer wrote: > > I sent a message to here this morning and didn't see it, > then again this afternoon. Still haven't seen it come back to me > (and no answers) I wonder if I'll see this? > > > > 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
Suspend/resume + pccard
A while back there was a thread on one of the lists (-developers maybe?) about someone's laptop having issues with newcard and suspend/resume. Today I tested a patch to fix suspend/resume for ACPI and went ahead and tested all the combinations. All of the following worked perfectly fine on my Inspiron 5000e: - APM + oldcard - APM + newcard - ACPI + oldcard - ACPI + newcard This is all with top of the tree -current. All the tests used a wavelan (wi0) for the test pccard (didn't try cardbus with newcard) and suspend/resume was tested both with Fn-Esc (suspend hotkey) and by holding down and releasing the lid switch (equivalent to shutting and opening the lid). -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpi malfunctions
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Mon, Jul 23, 2001 at 01:37:59PM -0700 On Mon, Jul 23, 2001 at 01:37:59PM -0700, Mike Smith wrote: > > > > 1. Acpica modules hangs in > > > > AcpiRsCalculateByteStreamLength() called from > > > > AcpiRsCreateByteStream() called from > > > > AcpiRsSetSrsMethodData() called from > > > > AcpiSetCurrentResources() from somewhere in acpi_pcib.c . > > > > > > > > The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length > > == 0 > > > > . > > > > > > Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484? > > > I think I should be passing a pointer to the buffer, not a pointer to a > > > pointer. > > > > There's no &crsbuf in line 484 (not in rev 1.10, nor 1.11). > > > > Assuming you're talking about the one in line 478, it doesn't compile if you > > change it to crsbuf from &crsbuf, since crsbuf is an ACPI_BUFFER, not > > an (ACPI_BUFFER *). > > Um. Sorry about the line numbers, and yes, sorry about the confusion > there; I just looked at it and it seemed wrong. > > I'd still like to know the allocation length for that buffer though; my > last suspicion is that it doesn't contain any resources at all, and so > we're overrunning it when we go to try to stuff an interrupt resource > into it. If that's the case, it's easy to fix. If not, then we will > have to go hunting snarks. Attached are what I got from dmesg, and two patches to obtain the dmesg output. The patches are to be applied against acpi_pcib.c and /sys/contrib/dev/acpica/rscalc.c, respectively. The latter lets you go past the RsCalculateByteStreamLength(), but of course the interrupt routing fails. Let me know if there are other places I had to put the printf()'s. Regards. Shop Smart Compare Prices on Name-Brand Products from Name-Brand Stores!! http://www.smartshop.com/cgi-bin/main.cgi?ssa=4099 dmesg acpi_pcib.c.diff rscalc.c.diff
