5.1-RELEASE TODO
This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ | Issue | Status| Responsible | Description | |--+-+-+-| | | | | There are reports of| | ipfw/ipfw2 | | | alignment problems with | | alignment issues | In progress | Luigi Rizzo | ipfw and/or ipfw2 on| | on alpha/sparc64 | | | 64-bit platforms| | | | | (specifically alpha and | | | | | sparc64). | ++ Desired Features for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Documentation items that must be resolved for 5.1 ++ |Issue |Status |Responsible |Description | ++ Areas requiring immediate testing ++ | Issue | Status | Responsible |Description| |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| | || | PAE support allows the| | || | use of up to 64GB of RAM | | PAE support for | -- | --| on Pentium Pro and above | | i386 || | systems. Virtual | | || | addresses are still | | || | constrained to 32-bits. | |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || | is welcome. | |---++---+---| | || | For 5.1-RELEASE, the | | || | default file system type | | || | for newly created file| | || | systems is UFS2 rather| | UFS2 as || | than UFS1. newfs(8) and | | installation, | -- | Robert Watson | sysinstall(8) have been | | newfs default || | updated to use this new | | || | default. Testing to make | | || | sure all goes well after | | || | the change (committed on | | || | April 20, 2003) is vital. | |---++---+---| | |
Re: whats an UDMA ICRC error ?
On Tue, 3 Jun 2003 11:32:06 +0200 Stefan Bethke [EMAIL PROTECTED] wrote: Am Dienstag, 03.06.03, um 07:57 Uhr (Europe/Berlin) schrieb Andreas Klemm: ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying What exactly does an UDMA ICRC error mean ? I think this is simply a read error. AFAIK an IDE disk doesn't have spare sectors or am I wrong ? How severe is this error ? What do you think ?? IDE disks have (hidden) spare sectors, and will transparently remap sectors as long as they have spare ones left. If the drive reports errors (hard error reading fsbn...), then it likely has run out of spare sectors, and probably will die soon. I have experienced the same problems with a VIA IDE controller using UDMA transfer mode with two perfectly healthy hard drives. Now I use a motherboard with SiS chipset and never had these problems again. Regards, Julian Stecklina -- Reboot America. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, May 29, 2003 at 06:28:26PM -0400, James Tanis wrote: On Thu, 29 May 2003 17:39:18 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: It has been committed. Build rtld with WITH_LIBMAP defined and then setup a libmap.conf. -- Alright, I compiled and installed libthr, built rtld WITH_LIBMAP, and created the libmap.conf. I am using the example from the man page to have all programs use the libthr library. As far as I can tell my system is running perfectly fine, but there's nothing particularly special about my setup. Is there a way to find out for sure that the programs are now using libthr? As far as I can tell they should be, but I'd like to have a definitive answer. You can use ldd to check the binaries and it will show how libmap affects the library mappings. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Mon, Jun 02, 2003 at 09:04:11AM -0700, Hiten Pandya wrote: On Mon, Jun 02, 2003 at 08:17:03AM -0700, Terry Lambert wrote: Hiten Pandya wrote: My fingers have been itching to do this since the day phk@ planted this idea in my brain (re: cdevsw initialisations). Basically, it changes the vfsops to use C99 sparse format, just like cdevsw. It removes a lot of junk default initialisations, and duplication. I really dislike the changes to vfs_init(). Specifically, it's not the overhead, so much as it's the implied side effects. And how many times is vfc_register() called? Its not in the patch of an I/O operation or anything. Its just a mount time overhead which will go through -- a one time thing. Consider this going forward: someone adds a new VFSOP to the list of allowable VFSOPs, and the vfs_init() doesn't have any specific code for it. You should look at kobj, it's precisely this sort of dynamic dispatching that it was designed to support. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
buildkernel failure
cc -O -pipe -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -D__FBSDID=__RCSID -c aicasm_scan.c cc -O -pipe -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -D__FBSDID=__RCSID -c aicasm_macro_scan.c cc -O -pipe -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -D__FBSDID=__RCSID -o aicasm aicasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll cd /usr/obj/usr/src/sys/BEASTIE; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.00503 GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/libexec make KERNEL=kernel depend *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -Wash -- Odhiambo Washington [EMAIL PROTECTED] The box said 'Requires Wananchi Online Ltd. www.wananchi.com Windows 95, NT, or better,' Tel: +254 2 313985-9 +254 2 313922 so I installed FreeBSD. GSM: +254 72 743223 +254 733 744121 This sig is McQ! :-) Never put off till tomorrow what you can avoid all together. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-beta2 failed upgrade install
Are there anybody who can upgrade to 5.1-RC1 successfully with Xeon or Pentium4 ? I can newly install 5.1-RC1, but I can not upgrade from 5.1-BETA or 5.1-RC1 to 5.1-RC1 with Xeon or Pentium4 without panics. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-beta2 failed upgrade install
On Tue, 03 Jun 2003 23:52:38 +0900 (JST) Masachika ISHIZUKA [EMAIL PROTECTED] wrote: Are there anybody who can upgrade to 5.1-RC1 successfully with Xeon or Pentium4 ? I can newly install 5.1-RC1, but I can not upgrade from 5.1-BETA or 5.1-RC1 to 5.1-RC1 with Xeon or Pentium4 without panics. Here, here. I was doing installworld and got a double fault. After rebooting with the new kernel (5.1-RC1) and running fsck it installed fine. Funnyly enough, make was gone, so I had to run the one in /usr/obj. Otherwise seems to work fine so far. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] EnergyHQ :: http://www.energyhq.tk Tired of Spam? - http://www.trustic.com pgp0.pgp Description: PGP signature
Re: VFS: C99 sparse format for struct vfsops
In message: [EMAIL PROTECTED] Paul Richards [EMAIL PROTECTED] writes: : You should look at kobj, it's precisely this sort of dynamic : dispatching that it was designed to support. Too bad it is a little slow and not MP safe in its implementation. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-beta2 failed upgrade install
Are there anybody who can upgrade to 5.1-RC1 successfully with Xeon or Pentium4 ? I can newly install 5.1-RC1, but I can not upgrade from 5.1-BETA or 5.1-RC1 to 5.1-RC1 with Xeon or Pentium4 without panics. Here, here. I was doing installworld and got a double fault. After rebooting with the new kernel (5.1-RC1) and running fsck it installed fine. Funnyly enough, make was gone, so I had to run the one in /usr/obj. Otherwise seems to work fine so far. Thank you for mail. But I want to binary upgrade with CD-ROM. Is there anyone who can binary upgrade to 5.1-RC1 with CD-ROM image from ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/5.1-RC1/5.1-RC1-i386-disc1.iso. -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-beta2 failed upgrade install
Date: Tue, 03 Jun 2003 23:52:38 +0900 (JST) From: Masachika ISHIZUKA [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Are there anybody who can upgrade to 5.1-RC1 successfully with Xeon or Pentium4 ? I can newly install 5.1-RC1, but I can not upgrade from 5.1-BETA or 5.1-RC1 to 5.1-RC1 with Xeon or Pentium4 without panics. I had exactly this problem on my IBM T30 (1.8 GHz P4). Random panics, usually 4 or 12. Not repeatable.Oddly, many (most?) of the failures were not during compiles, but doing rm or chmod or something similarly trivial! Very weird. After trying for a while to get a clean build, I finally started re-starting the buildworld with -DNOCLEAN (occasionally after deleting something that was in progress) during the build. Once I got a new system build, things were fine again. I immediately rebuilt again, as it was possible that something had been messed up in one of the panics and I missed it. I could also not update some ports. I have no idea of the cause, but I have not seen it again. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
our compiler can't convert longlong to float? 5.1-RC1
I got this strange message and a core dump after installing 5.1-RC1 cdrom iso checking if c++ supports bool types... yes checking if conversion of longlong to float works... Segmentation fault (core du mped) no configure: error: Your compiler cannot convert a longlong value to a float! If you are using gcc 2.8.# you should upgrade to egcs 1.0.3 or newer and try again This happened when I tried to compile mysql-client Jiawei Ye -- Without the userland, the kernel is useless. --inspired by The Tao of Programming ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Tue, Jun 03, 2003 at 08:56:59AM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Paul Richards [EMAIL PROTECTED] writes: : You should look at kobj, it's precisely this sort of dynamic : dispatching that it was designed to support. Too bad it is a little slow and not MP safe in its implementation. Yes, but it has the right design philosophy for this sort of situation and should be researched as an example of how to solve these sorts of problems. I'm not sure the dispatch is slow enough to cause serious overhead in the context of the tasks being performed and it maybe could be improved a little. I'm not sure that kobj actually needs to be MP safe if the kobj struct is always embedded in a structure at a higher level i.e. a use of kobj in say the device driver code will not interact with it's use by say the linker code so the locking can be done on device driver or linker level structs. I think that's the case currently, though perhaps not something we've defined as part of the API, but there's no reason we could not do so and then that simplifies the use of kobj by avoiding having to add locks right at the very bottom of the structure tree where they wouldn't be needed. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_4 to RELENG_5_1
I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make buildworld compiles a while and then stops with: Question is if this is supported and if yes, what should I do differently? Pete cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include -I/usr/src/lib/libpthread/thread -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys -I/usr/src/lib/libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -c /usr/src/lib/libpthread/sys/lock.c -o lock.So building shared library libkse.so.1 thr_libc.So: In function `sigaction': thr_libc.So(.text+0x54): multiple definition of `_sigaction' thr_sigaction.So(.text+0x0): first defined here thr_libc.So: In function `sigprocmask': thr_libc.So(.text+0x34): multiple definition of `_sigprocmask' thr_sigprocmask.So(.text+0x0): first defined here *** Error code 1 Stop in /usr/src/lib/libpthread. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 to RELENG_5_1
On Tue, 03 Jun 2003 18:51:59 +0300 Petri Helenius [EMAIL PROTECTED] wrote: I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make buildworld compiles a while and then stops with: Question is if this is supported and if yes, what should I do differently? Pete Got your buildworld log saved somewhere? Could you send it to me please. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
On Mon, 2 Jun 2003, Jeff Roberson wrote: If you have had issues with libthr on SMP or umtx panics, the following patch may solve these issues. http://www.chesapeake.net/~jroberson/umtxlocks.diff This patch fixes several race conditions and other issues with umtx. Actually, no it doesn't. I was able to use kern_umtx v 1.3 only if I removed atapicam from my kernel config. These patches (now committed?) panic the system whether I use atapicam or not. With kern_umtx v1.2 there is no panic at all, with or without atapicam. Actually, I think it's cam in general that's causing the panic with these changes. Please see kern/52718 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
Bryan Liesner wrote: On Mon, 2 Jun 2003, Jeff Roberson wrote: If you have had issues with libthr on SMP or umtx panics, the following patch may solve these issues. http://www.chesapeake.net/~jroberson/umtxlocks.diff This patch fixes several race conditions and other issues with umtx. Actually, no it doesn't. I was able to use kern_umtx v 1.3 only if I removed atapicam from my kernel config. These patches (now committed?) panic the system whether I use atapicam or not. With kern_umtx v1.2 there is no panic at all, with or without atapicam. Actually, I think it's cam in general that's causing the panic with these changes. Please see kern/52718 I didn't see a backtrace in the PR. Is there one that you can share with us? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: I'm not sure that kobj actually needs to be MP safe if the kobj
: struct is always embedded in a structure at a higher level i.e.
: a use of kobj in say the device driver code will not interact with
: it's use by say the linker code so the locking can be done on device
: driver or linker level structs.
Lock lock data, not code.
The kobj dispatch tables are shared between all instances of the
object. So if you have two instances of the driver, the driver locks
protect softc for that driver. However, both softc's reference the
kobj structures, directly or indirectly, that are not MP safe. If
instance 1 takes out a lock, that doesn't prevent instance 2 from
getting screwed by the following code:
#define KOBJOPLOOKUP(OPS,OP) do { \
kobjop_desc_t _desc = OP##_##desc; \
kobj_method_t *_ce =\
OPS-cache[_desc-id (KOBJ_CACHE_SIZE-1)]; \
if (_ce-desc != _desc) { \
KOBJOPMISS; \
[1] kobj_lookup_method(OPS-cls-methods, _ce, _desc); \
} else {\
KOBJOPHIT; \
} \
[2] _m = _ce-func; \
} while(0)
Notice how OPS has a cache array. If instance 1 is calling the same
ID as instance 2, modulo KOBJ_CACHE_SIZE, then a collision occurs and
a race happens betwen [1] and [2]:
thread 1 thread 2
_ce = ...
_ce = ...
HIT
MISS
set's *_ce via kobj_lookup_method
_m gets set
_m called
_m set
_m called
Notice how thread 1's _m gets set based on the results of the kobj
lookup, and we have a race, even if thread1 and thread2 took out their
driver instance locks.
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
On Tue, 3 Jun 2003, Scott Long wrote: Actually, I think it's cam in general that's causing the panic with these changes. Please see kern/52718 I didn't see a backtrace in the PR. Is there one that you can share with us? It panics during boot and, unfortunately, no dump is produced. The best I could do is what's already there in the PR. If there is anything more I can do, just let me know. I have (using cam) 2 atapi cdroms, a 100M zip disk, and a 40G USB hard disk. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On Tue, Jun 03, 2003 at 01:54:36AM -0500, Conrad Sabatier wrote: On 02-Jun-2003 Nicolas Souchu wrote: On Sun, Jun 01, 2003 at 01:52:57AM +0200, Dag-Erling Smorgrav wrote: viapropm is seriously broken for other reasons and needs professional help. What kind of breakage? Setting resources in probe? Right. Anybody having the viapm driver loaded usually should please try the attached patch. I'm sorry to report that those patches didn't fix the problem for me. They all applied cleanly, I built a new kernel, but I still see the same messages at boot. Couldn't enable port mapping. The problem is a disagreement with the new io_method code and the viapropm chip. From Nicolas Souchu's previous email: : The datasheet states that the command bits are RW but fixed at 0. A snip of code from sys/dev/pci/pci.c:pci_enable_io_method(): pci_set_command_bit(dev, child, bit); command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); if (command bit) return (0); device_printf(child, failed to enable %s mapping!\n, error); return (ENXIO); Because the viapropm's command register bits will always read as zero, this code will always fail when trying to enable port mapping. Whatever problems viapropm may have, it is the new pci code that prevents it from attaching. It is not the fault of anything in sys/pci/viapm.c. -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Native JDK with libthr/libkse
On Mon, 2 Jun 2003, Sheldon Hearn wrote: On (2003/06/01 23:53), Narvi wrote: The absence of credible Java support in FreeBSD has lost us significant penetration in the past, and it would be disastrous if the perceptions of the past shaped the future. credible rather sounds like 'comes on the installation cd, doesn't have significantly more bugs than linux/solaris/xxx version' 8-( And I think we'll get there. I would really hope so, its increasingly a barrier. I'm currently doing some Java development on a FreeBSD-CURRENT workstation using a native jdk14. It's good enough for testing components in a J2EE application server (JBoss), and performance is comparable to that seen on an equivalent Windows workstation. java is not all just j2ee, though its an increasingly important niche. The developer side is probably in the short term more important than the number of servers deployed using it. Would I use FreeBSD as a production J2EE server reliant on 1.4.1? No. But the time is coming, so don't write FreeBSD off just yet. oh, i'm not writing off freebsd, its just not as ready in this regard as competition. Running production j2ee servers is a level above having a useful / credible java story - it would probably be something you'd do on 5.3 with a good jdk. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
vmstat -s broken
I don't know for how long this has been broken but vmstat always reports 0 (zero) for the number of system calls executed which is virtually impossible. This is on a system built FreeBSD darkstar 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Jun 3 02:48:51 CEST 2003 darkstar# vmstat -s | grep system calls 0 system calls darkstar# uptime 8:33PM up 17:03, 8 users, load averages: 1.93, 1.63, 1.27 -- Pawel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmstat -s broken
++ 03/06/03 20:47 +0200 - Pawel Worach: | I don't know for how long this has been broken but vmstat | always reports 0 (zero) for the number of system calls | executed which is virtually impossible. | | This is on a system built | FreeBSD darkstar 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Jun 3 02:48:51 | CEST 2003 | | darkstar# vmstat -s | grep system calls | | 0 system calls | darkstar# uptime FWIW, I also see this behaviour on -current built Feb 13th: knap.sac(/home/sac1/petef) [258] vmstat -s | grep system.calls 0 system calls knap.sac(/home/sac1/petef) [259] uname -a FreeBSD knap.sac.fedex.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Feb 13 16:26:14 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAC-DELL240-5 i386 knap.sac(/home/sac1/petef) [260] --pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
s4bios
Is there anyone that has succesfully used acpiconf -s 4? I'm very interested in your reports. If you haven't tried yet, but are willing to help me, please report me your findings. Thanks Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 to RELENG_5_1
On Tue, Jun 03, 2003 at 12:02:44PM -0400, Alexander Kabaev wrote: On Tue, 03 Jun 2003 18:51:59 +0300 Petri Helenius [EMAIL PROTECTED] wrote: I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make buildworld compiles a while and then stops with: Question is if this is supported and if yes, what should I do differently? Pete Got your buildworld log saved somewhere? Could you send it to me please. Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I have been getting the same failure originally quoted when building HEAD on RELENG_4 for several days now. I suggest that the original poster double-check that he has RELENG_5_1 and not HEAD. And I do have buildworld logs. I'll send in a separate mail. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s4bios
I put my test results in: http://anarcat.ath.cx/acpi-test/ I have done other tests using a build made after the recent ACPI import and bugfixes, and I will update the info there when completely done. A. On Tue Jun 03, 2003 at 05:32:05PM +0200, Mark Santcroos wrote: Is there anyone that has succesfully used acpiconf -s 4? I'm very interested in your reports. If you haven't tried yet, but are willing to help me, please report me your findings. Thanks Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Paul Richards [EMAIL PROTECTED] writes:
: I'm not sure that kobj actually needs to be MP safe if the kobj
: struct is always embedded in a structure at a higher level i.e.
: a use of kobj in say the device driver code will not interact with
: it's use by say the linker code so the locking can be done on device
: driver or linker level structs.
Lock lock data, not code.
Agreed, that's what I said :-) However, I was wondering if locking the
structure that the kobj was embedded in was enough to protect the kobj
itself. As you point out below, that's not the case.
The kobj dispatch tables are shared between all instances of the
object. So if you have two instances of the driver, the driver locks
protect softc for that driver. However, both softc's reference the
kobj structures, directly or indirectly, that are not MP safe. If
instance 1 takes out a lock, that doesn't prevent instance 2 from
getting screwed by the following code:
#define KOBJOPLOOKUP(OPS,OP) do { \
kobjop_desc_t _desc = OP##_##desc; \
kobj_method_t *_ce =\
OPS-cache[_desc-id (KOBJ_CACHE_SIZE-1)]; \
if (_ce-desc != _desc) { \
KOBJOPMISS; \
[1] kobj_lookup_method(OPS-cls-methods, _ce, _desc); \
} else {\
KOBJOPHIT; \
} \
[2] _m = _ce-func; \
} while(0)
Notice how OPS has a cache array. If instance 1 is calling the same
ID as instance 2, modulo KOBJ_CACHE_SIZE, then a collision occurs and
a race happens betwen [1] and [2]:
thread 1thread 2
_ce = ...
_ce = ...
HIT
MISS
set's *_ce via kobj_lookup_method
_m gets set
_m called
_m set
_m called
Notice how thread 1's _m gets set based on the results of the kobj
lookup, and we have a race, even if thread1 and thread2 took out their
driver instance locks.
That means we have to lock the dispatch table before every method is
looked up and hold it until the method returns (the alternative would be
to free it inside the method once it had been called but that'd be a
right mess).
Actually, in practice it doesn't matter, though that's an accident of
the kobjs we currently create. The reason being that the hashing
algorithm is really simple and just lops off some high bits of the
method id so unless we have more than 255 methods they always have an
unique slot. There's no mechanism to change the actual function
associated with the method at the moment. Even if there was, it might
not matter as long as the number of methods was still below 255, because
what you'd actually be doing is, say, changing which attach function to
call when you were indirecting through the attach method entry and by
the time thread 1 gets to actually call the method it might even be
considered correct for it to call the newly mapped one.
However, I take your point and we either have to implement locking of
the method table or redesign the caching mechanism to guarantee that
there's no race. I don't think anything other than _ce is a problem (is
there anything else?).
If we ensured that the cache entry couldn't have collisions (perhaps by
not having a hash and instead indexing a unique position in an array
using the method id) then only the latter race would exist (changing the
function associated with a method) and that might be acceptable
behaviour.
The tradeoff with using an index into an array is that there'd be a
heavy penalty for growing the array if an extra method didn't fit, but
that would be exceptionally rare and with our present usage we'd never
have that happen.
Incidentally, if we implement a lock on the method table we'd
effectively have code locks :-)
--
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 to RELENG_5_1
On Tue, 3 Jun 2003 12:56:01 -0700 Crist J. Clark [EMAIL PROTECTED] wrote: Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I have been getting the same failure originally quoted when building HEAD on RELENG_4 for several days now. I suggest that the original poster double-check that he has RELENG_5_1 and not HEAD. And I do have buildworld logs. I'll send in a separate mail. No need that. This is a bug and it needs to be fixed. I am working on this. Thanks for the reports. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmstat -s broken
On Tue, 3 Jun 2003, Pete Fritchman wrote: ++ 03/06/03 20:47 +0200 - Pawel Worach: | I don't know for how long this has been broken but vmstat | always reports 0 (zero) for the number of system calls | executed which is virtually impossible. | | This is on a system built | FreeBSD darkstar 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Jun 3 02:48:51 | CEST 2003 | | darkstar# vmstat -s | grep system calls | | 0 system calls | darkstar# uptime FWIW, I also see this behaviour on -current built Feb 13th: knap.sac(/home/sac1/petef) [258] vmstat -s | grep system.calls 0 system calls knap.sac(/home/sac1/petef) [259] uname -a FreeBSD knap.sac.fedex.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Feb 13 16:26:14 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAC-DELL240-5 i386 knap.sac(/home/sac1/petef) [260] Rev.1.67 of vm/vm_meter.c unbroke the sysctl that returns the number of syscalls, but vmstat(1) accesses cnt.v_syscalls in kmem so it is still broken. systat(1) uses the sysctl so it was unbroken. Using the sysctl updates cnt.v_syscall, but programs that read it from kmem see a stale value (the one made by the last call to the sysctl). I use a different fix which restores the previous code for the SMP case. The SMP case remains broken: the count is stored in per-CPU data (in all cases in -current but only in the SMP case in my version) so that updating it doesn't require locking or expensive atomic operations. Thus there is never any up to date copy of the full count, and programs that access it in kmem need to know how to assemble it. None do. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HD Speed Benchmark
I have made some Benchmark on my inspiron 8500 (Intel 82801DB (ICH4) - UDMA100) and i am geting very Bad results on the 5.1, i have got beter results on 5.0 dmesg -- 5.0R -- http://www.x123.info/src/i8500/dmesg.5.0R 5.1B2 -- http://www.x123.info/src/i8500/dmesg.5.1B2 Check out the output of bonnie++: 5.0R -- http://www.x123.info/src/i8500/bonnie.5.0R 5.1B2 -- http://www.x123.info/src/i8500/bonnie.5.1B2 -- /* FingerPrint: 5BF1 58B1 DE75 CBE3 6044 7098 1246 1EF6 9E78 041C @@@ @@ @@@ @@! @@@ !@@ @@! @@@ @[EMAIL PROTECTED]@!@ !@@!! @!@ [EMAIL PROTECTED] !!: !!! !:! !!: !!! :: : :: ::.: : :: : : The Power To Kill LinuX */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HD Speed Benchmark
On 2003.06.03 22:20:56 +0200, Sebastian Yepes [ESN] wrote: I have made some Benchmark on my inspiron 8500 (Intel 82801DB (ICH4) - UDMA100) and i am geting very Bad results on the 5.1, i have got beter results on 5.0 Beta2 still had all the debugging options in the kernel, so unless you have removed them, and recompiled your kernel, thats what you are seeing. -- Simon L. Nielsen pgp0.pgp Description: PGP signature
Re: umtx/libthr SMP fixes.
Bryan Liesner wrote: On Tue, 3 Jun 2003, Scott Long wrote: Actually, I think it's cam in general that's causing the panic with these changes. Please see kern/52718 I didn't see a backtrace in the PR. Is there one that you can share with us? It panics during boot and, unfortunately, no dump is produced. The best I could do is what's already there in the PR. If there is anything more I can do, just let me know. I have (using cam) 2 atapi cdroms, a 100M zip disk, and a 40G USB hard disk. It's very hard to imagine Jeff's patches causing a problem at the point that the PR mentions. Have you confirmed the problem in a kernel that was build in a totally clean environment? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Mon, 2003-06-02 at 21:04, Paul Richards wrote: The tradeoff with using an index into an array is that there'd be a heavy penalty for growing the array if an extra method didn't fit, but that would be exceptionally rare and with our present usage we'd never have that happen. I'm not sure this is actually a problem after all since the Interface doesn't change and therefore we know a-priori how many methods there can be so we can pre-allocate an array. I wonder why Doug didn't do this, perhaps he thought that there'd be very large interfaces and 255 was a reasonable compromise for a cache. However, in practice we'd save a lot of space per kobj by preallocating the actual number of entries we needed for the Interface instead and then we could do away with the _ce problem. This would actually speed up the dispatch a lot too since we wouldn't have to traverse a list looking for a matching method entry and could call the function directly from the method table. Doug, am I missing something? -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
fxp0: device timeout with 5.1BETA2
Hi I still get a fxp0: device timeout on my Thinkpad T30 with a newly installed 5.1BETA2. Browsing the archives showed that people had success with hint.fxp.0.prefer_iomap=1 on a T30 and 5.1BETA1. Any ideas why this doesn't help in my case? thx, t. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
libmap.conf has the bug or not work correct?
I am trying to get ggv link against libc_r instead libthr, but it doesn't work as expect.. Maybe, I must have done something wrong? # cat /etc/libmap.conf libc_r.so.5 libthr.so.1 libc_r.so libthr.so [/usr/X11R6/bin/ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so [ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so # uname -a FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Jun 2 20:23:45 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ i386 I even rebuilt rtld-elf (WITH_LIBMAP=yes in /etc/make.conf) and ggv then reinstall them, but no luck. The ggv is still linking to libthr instead libc_r.. Also, ggv isn't only one app that I tried. I did tried with gst- register and no luck to change the link to libc_r. # ldd /usr/X11R6/bin/ggv | grep libc libc.so.5 = /usr/lib/libc.so.5 (0x28a68000) libc_r.so.5 = /usr/lib/libthr.so.1 (0x28b49000) Do anyone have any hint? Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
In message: [EMAIL PROTECTED] Paul Richards [EMAIL PROTECTED] writes: : Doug, am I missing something? I think we can have more than 256 methods, en toto, since any object can implement multiple interface types and we don't know, a-priori, how many different interfaces a given object implements. But I've not studied things beyond a quick glance to make sure this is the case. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
On Tue, 3 Jun 2003, Scott Long wrote: It's very hard to imagine Jeff's patches causing a problem at the point that the PR mentions. Have you confirmed the problem in a kernel that was build in a totally clean environment? Scott If you mean a kernel build with standard optimizations, yes I have seen it. No local patches: cc -O -pipe -mcpu=pentiumpro The panic happens before running init. Sometimes I'm lucky and the kernel doesn't panic during boot, but it will panic shortly before or after login. It locks up tight afterwards, and doesn't do a dump. All this happened after kern_umtx.c v1.2 When I revert back, no panic... It won't panic if I turn off the USB drive, or compile a kernel without atapicam. Possible problem with EHCI? The driver finds an OHCI device, calls it umass0, detaches it, finds an EHCI device and calls it umass1. I'm sure it's not Jeffs patches that are the problem, but other potential problems are exacerbated by them. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On 02-Jun-2003 Paul Richards wrote: On Mon, 2003-06-02 at 21:04, Paul Richards wrote: The tradeoff with using an index into an array is that there'd be a heavy penalty for growing the array if an extra method didn't fit, but that would be exceptionally rare and with our present usage we'd never have that happen. I'm not sure this is actually a problem after all since the Interface doesn't change and therefore we know a-priori how many methods there can be so we can pre-allocate an array. I wonder why Doug didn't do this, perhaps he thought that there'd be very large interfaces and 255 was a reasonable compromise for a cache. However, in practice we'd save a lot of space per kobj by preallocating the actual number of entries we needed for the Interface instead and then we could do away with the _ce problem. This would actually speed up the dispatch a lot too since we wouldn't have to traverse a list looking for a matching method entry and could call the function directly from the method table. Doug, am I missing something? Well, it's dfr@ rather than doug@ :) (dfr@ cc'd) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
In message [EMAIL PROTECTED], John Baldwin writes: On 02-Jun-2003 Paul Richards wrote: On Mon, 2003-06-02 at 21:04, Paul Richards wrote: The tradeoff with using an index into an array is that there'd be a heavy penalty for growing the array if an extra method didn't fit, but that would be exceptionally rare and with our present usage we'd never have that happen. I'm not sure this is actually a problem after all since the Interface doesn't change and therefore we know a-priori how many methods there can be so we can pre-allocate an array. I thought the point in KOBJ was that it was extensible so you could KLD load stuff which added more methods ? -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
On Mon, 2 Jun 2003, Simon L. Nielsen wrote: I have an asr based RAID controller (Adaptec 2400A), though it is an IDE RAID controller, it uses the SCSI asr driver. My controller has worked very well with FreeBSD 5.x, and the server is currently running 5.1-BETA. The only thing that doesn't work, is the userland utilities to control / get status from the card, but that's not so important. I have an asr based SCSI RAID controller and I have been testing it with a 5.1 system. So far it seems to be working just fine, and the performance is generally good. The system has been running for a few weeks while I have been doing some random testing. The latest make world and kernel rebuild was a few days ago. uname -a: FreeBSD f4.berkeley.edu 5.1-BETA FreeBSD 5.1-BETA #2: Thu May 29 18:40:44 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/F4-SMP i386 from dmesg: asr0: Adaptec Caching SCSI RAID mem 0xfc00-0xfdff irq 16 at device 3.0 on pci3 asr0: major=154 asr0: ADAPTEC 2110S FW Rev. 380E, 1 channel, 256 CCBs, Protocol I2O michael ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: whats an UDMA ICRC error ?
On Tue, Jun 03, 2003 at 01:23:35AM -0500, Dan Nelson wrote: In the last episode (Jun 03), Andreas Klemm said: Hi, my console today shows the following error message from my disk: ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying What exactly does an UDMA ICRC error mean ? I think this is simply a read error. AFAIK an IDE disk doesn't have spare sectors or am I wrong ? How severe is this error ? What do you think ?? An ICRC error is an error detected by the IDE controller. It usually means a cabling problem, as a disk error would be reported by the drive, not the controller. From the ATA spec: ICRC shall be set to one if an interface CRC error has occurred during an Ultra DMA data transfer. The content of this bit is not applicable for Multiword DMA transfers. There are other error bits that indicate uncorrectable media errors. ^^ Does this mean, that data corruption occurred ?? Strange. Didn't touch the hardware since months... One idea, the cables have been very short and have been a little bit under tension after installation. Maybe this is the result now, that I have problems with the cables or contacts Thanks for the info, will check cabling. Andreas /// -- Andreas Klemm - Powered by FreeBSD 4.8-STABLE Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], John Baldwin writes: On 02-Jun-2003 Paul Richards wrote: On Mon, 2003-06-02 at 21:04, Paul Richards wrote: The tradeoff with using an index into an array is that there'd be a heavy penalty for growing the array if an extra method didn't fit, but that would be exceptionally rare and with our present usage we'd never have that happen. I'm not sure this is actually a problem after all since the Interface doesn't change and therefore we know a-priori how many methods there can be so we can pre-allocate an array. I thought the point in KOBJ was that it was extensible so you could KLD load stuff which added more methods ? Not exactly. It allows for dynamic binding of methods that implement a specified interface. It gives you 2 things mainly: 1) Not all the interface has to be implemented within a particular object, and things will just work if unimplemented parts of the interface are called on an object. 2) The actual functions called for a particular method can by dynamically changed (or at least they could be, I don't think there's actually any API that does this at the moment so in fact they just get mapped the once when the object is instantiated). The possible methods available in an interface are fixed, they're defined in the .m files. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: whats an UDMA ICRC error ?
On Tue, Jun 03, 2003 at 11:32:06AM +0200, Stefan Bethke wrote: Am Dienstag, 03.06.03, um 07:57 Uhr (Europe/Berlin) schrieb Andreas Klemm: ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying What exactly does an UDMA ICRC error mean ? I think this is simply a read error. AFAIK an IDE disk doesn't have spare sectors or am I wrong ? How severe is this error ? What do you think ?? IDE disks have (hidden) spare sectors, and will transparently remap sectors as long as they have spare ones left. If the drive reports errors (hard error reading fsbn...), then it likely has run out of spare sectors, and probably will die soon. o.k., but this is luckily not the case now ;-) On Tue, Jun 03, 2003 at 12:52:01PM +0200, Frank Nobis wrote: Andreas Klemm [EMAIL PROTECTED] writes: Hallo Andreas, Hi, my console today shows the following error message from my disk: ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying What exactly does an UDMA ICRC error mean ? I think this is simply a read error. AFAIK an IDE disk doesn't have spare sectors or am I wrong ? How severe is this error ? What do you think ?? ich hatte genau diese Fehler vor einiger Zeit, als ich auf ATA 100 Platten umgestiegen bin. Die Fehler sind sofort verschwunden als ich mit richtigen UDMA100 Kabeln die Platten angeschlossen hatte. Well, will have to check cabling, this was also an answer I got on this topic. Thanks to you all Andreas /// -- Andreas Klemm - Powered by FreeBSD 4.8-STABLE Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout with 5.1BETA2
On Tue, 2003-06-03 at 22:00, Tobias Roth wrote: Hi I still get a fxp0: device timeout I get these as well. Is it on irq9 by any chance, along with acpi0 ? -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: whats an UDMA ICRC error ?
In the last episode (Jun 03), Andreas Klemm said: On Tue, Jun 03, 2003 at 01:23:35AM -0500, Dan Nelson wrote: In the last episode (Jun 03), Andreas Klemm said: ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying What exactly does an UDMA ICRC error mean ? I think this is simply a read error. AFAIK an IDE disk doesn't have spare sectors or am I wrong ? How severe is this error ? What do you think ?? An ICRC error is an error detected by the IDE controller. It usually means a cabling problem, as a disk error would be reported by the drive, not the controller. From the ATA spec: ICRC shall be set to one if an interface CRC error has occurred during an Ultra DMA data transfer. The content of this bit is not applicable for Multiword DMA transfers. There are other error bits that indicate uncorrectable media errors. ^^ Does this mean, that data corruption occurred ?? No; I'm just saying that the ATA spec has a lot of status/error bits :) If you had physical data corruption you'd see something other than ICRC. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
In message: [EMAIL PROTECTED] Paul Richards [EMAIL PROTECTED] writes: : The possible methods available in an interface are fixed, they're : defined in the .m files. No it isn't. One can add additional interfaces at any time without breaking binary compatibility, so you don't know, a priori, the number of methods in a given interface when you build a client of that interface. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout with 5.1BETA2
On Mon, Jun 02, 2003 at 10:59:22PM +0100, Paul Richards wrote: On Tue, 2003-06-03 at 22:00, Tobias Roth wrote: fxp0: device timeout I get these as well. Is it on irq9 by any chance, along with acpi0 ? No. It's on irc 11 device 8 (as dmesg states). All irqs in bios are set to 11 (factory default). ACPI is disabled. It's a fresh 5.1-BETA2 system with the following modifications: hint.apm.0.disabled=0 hint.acpi.0.disabled=1 hint.fxp.0.prefer_iomap=1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: our compiler can't convert longlong to float? 5.1-RC1
On Tue, Jun 03, 2003 at 11:40:40PM +0800, leafy wrote: I got this strange message and a core dump after installing 5.1-RC1 cdrom iso checking if c++ supports bool types... yes checking if conversion of longlong to float works... Segmentation fault (core du mped) no configure: error: Your compiler cannot convert a longlong value to a float! If you are using gcc 2.8.# you should upgrade to egcs 1.0.3 or newer and try again This happened when I tried to compile mysql-client Post the code it's trying to run. It's possible it's buggy. Kris pgp0.pgp Description: PGP signature
Re: s4bios
On Tue, Jun 03, 2003 at 05:32:05PM +0200, Mark Santcroos wrote: Is there anyone that has succesfully used acpiconf -s 4? I'm very interested in your reports. If you haven't tried yet, but are willing to help me, please report me your findings. Hello Mark, I may not be totally correct, but it has always helped me to check if a particular ACPI state was supported by my system: # sysctl hw.acpi.supported_sleep_state hw.acpi.supported_sleep_state: S1 S4 S5 Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Paul Richards [EMAIL PROTECTED] writes: : The possible methods available in an interface are fixed, they're : defined in the .m files. No it isn't. One can add additional interfaces at any time without breaking binary compatibility, so you don't know, a priori, the number of methods in a given interface when you build a client of that interface. I don't think that's true. The interface is defined in the .m file and it's created using makeobjs. You can't do that at runtime because it creates the kobj_desc struct that uniquely represents the existence of that method globally for the whole of the kobj subsystem. The set of all kobj_desc defines all possible methods that can be implemented by an object, and yes you can extend that interface later and previously built modules will still work because they only implement a subset of those possible methods, but the set of all methods that can exist is determined at compile time from the interface definitions A class is then defined which specifies the set of methods that objects instantiated into that class *can* implement (but are note required to). The set of methods in a class is also fixed, since it's basically the method table plus some class fields and the method table is created at compile time. Again though, if you later extend the class older compiled modules will still work because if the method doesn't exist in that older module the default from the kobj_desc will be used or the kobj_error_method will be called (which is safe). So yes you can extend the interface and the class and keep backwards compatibility but that all happens at compile time, and therefore at runtime when the object is instantiated you know the maximum number of methods that the object can possibly call. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
In message [EMAIL PROTECTED], Paul Richards wr ites: On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote: I thought the point in KOBJ was that it was extensible so you could KLD load stuff which added more methods ? Not exactly. It allows for dynamic binding of methods that implement a specified interface. It gives you 2 things mainly: The possible methods available in an interface are fixed, they're defined in the .m files. Then I don't see the justification for the hashing caching when it can be resolved at compile time... -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout with 5.1BETA2
On Tue, 2003-06-03 at 23:17, Tobias Roth wrote: On Mon, Jun 02, 2003 at 10:59:22PM +0100, Paul Richards wrote: On Tue, 2003-06-03 at 22:00, Tobias Roth wrote: fxp0: device timeout I get these as well. Is it on irq9 by any chance, along with acpi0 ? No. It's on irc 11 device 8 (as dmesg states). All irqs in bios are set to 11 (factory default). ACPI is disabled. Ok, well that's a useful data point (for me anyway) since it means there's a problem with fxp losing interrupts that's not related to some other ACPI problems I've experienced, suggesting that it's therefore a fxp driver problem. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Wed, 2003-06-04 at 00:03, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Paul Richards wr ites: On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote: I thought the point in KOBJ was that it was extensible so you could KLD load stuff which added more methods ? Not exactly. It allows for dynamic binding of methods that implement a specified interface. It gives you 2 things mainly: The possible methods available in an interface are fixed, they're defined in the .m files. Then I don't see the justification for the hashing caching when it can be resolved at compile time... kobj basically provides us with some OO type functionality. The linkage can't be determined at compile time since you don't know what methods an object is going to implement or what actual function implements a particular method until the object is instantiated, it's sort of late binding. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't boot from 4.8-RELEASE distribution CD (and 5.1-BETA2)
I found the problem; it only occurs if I try to boot with my Palm cradle attached to COM1. Remove it, and everything works fine. On Fri, May 30, 2003 at 11:20:27PM -0400, Guy Middleton wrote: I'm posting a follup to -current, since I get a similar but different problem with the 5.1-BETA2 CD. With 5.1-BETA2, the boot gets a far as the Probing devices, please wait message, then hangs. The last debug output on the console is: DEBUG: Loading module if_sf.ko (Adaptec AIC-6915 PCI ethernet card) module_register: module pci/sf already exists! Module pci/sf failed to register: 17 module_register: module sf/miibus already exists! Module sf/miibus failed to register: 17 On Fri, May 30, 2003 at 09:23:25PM -0400, Guy Middleton wrote: I have a FreeBSD 4.1 system, which I am trying to upgrade to 4.8-RELEASE. Unfortunately, it can't boot from the 4.8 distribution CD. When the generic kernel boots, it hangs indefinitely after finding plip0. I have also tried the 4.3 and 4.7 CDs, the same thing happens with them. So something changed betweek 4.1 and 4.3 (I don't have a 4.2 CD to try). Anybody have any ideas? Here is dmesg output, on the system as booted with 4.1-RELEASE: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.1-RELEASE #0: Fri Jul 28 14:30:31 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (451.03-MHz 686-class CPU) Origin = GenuineIntel Id = 0x672 Stepping = 2 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 134205440 (131060K bytes) avail memory = 126386176 (123424K bytes) Preloaded elf kernel kernel at 0xc040d000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: 3Dfx Voodoo 3 graphics accelerator at 0.0 irq 11 isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xb400-0xb41f at device 4.2 on pci0 uhci0: Invalid irq 255 uhci0: Please switch on USB support and switch PNP-OS to 'No' in BIOS device_probe_and_attach: uhci0 attach returned 6 chip1: Intel 82371AB Power management controller port 0xe800-0xe80f at device 4.3 on pci0 ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter port 0xb000-0xb0ff mem 0xdd80-0xdd800fff irq 9 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: Intel Pro 10/100B/100+ Ethernet port 0xa800-0xa81f mem 0xdd00-0xdd0f,0xe100-0xe1000fff irq 5 at device 7.0 on pci0 fxp0: Ethernet address 00:e0:18:98:3b:2f pci0: unknown card (vendor=0x1274, dev=0x5000) at 10.0 irq 5 dc0: 82c169 PNIC 10/100BaseTX port 0xa000-0xa0ff mem 0xdc80-0xdc8000ff irq 10 at device 11.0 on pci0 dc0: Ethernet address: 00:a0:cc:3b:f9:c4 miibus0: MII bus on dc0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port plip0: PLIP network interface on ppbus0 acd0: CDROM ASUS CD-S500/A at ata0-master using PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-master using PIO3 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s2a cd0 at ahc0 bus 0 target 3 lun 0 cd0: YAMAHA CRW4416S 1.0f Removable CD-ROM SCSI-2 device cd0: 8.333MB/s transfers (8.333MHz, offset 31) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed da1
RE: RELENG_4 to RELENG_5_1
Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I have been getting the same failure originally quoted when building HEAD on RELENG_4 for several days now. I suggest that the original poster double-check that he has RELENG_5_1 and not HEAD. And I do have buildworld logs. I'll send in a separate mail. No need that. This is a bug and it needs to be fixed. I am working on this. Thanks for the reports. Just a quick question, what version of GCC is going to appear in FreeBSD 5.1? I heard that it maybe GCC 3.2.3 and that GCC 3.3 (depending on its stability) will be used for 5.2. Could someone either confirm or correct me on this assumption? Matthew Gardiner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 to RELENG_5_1
On Wed, Jun 04, 2003 at 10:15:41AM +1000, Matthew Gardiner wrote: Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I have been getting the same failure originally quoted when building HEAD on RELENG_4 for several days now. I suggest that the original poster double-check that he has RELENG_5_1 and not HEAD. And I do have buildworld logs. I'll send in a separate mail. No need that. This is a bug and it needs to be fixed. I am working on this. Thanks for the reports. Just a quick question, what version of GCC is going to appear in FreeBSD 5.1? I heard that it maybe GCC 3.2.3 and that GCC 3.3 (depending on its stability) will be used for 5.2. Could someone either confirm or correct me on this assumption? gcc 3.2.2 is in RELENG_5_1. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 to RELENG_5_1
On 2003-06-04 10:15 +, Matthew Gardiner wrote: Just a quick question, what version of GCC is going to appear in FreeBSD 5.1? I heard that it maybe GCC 3.2.3 and that GCC 3.3 (depending on its stability) will be used for 5.2. Could someone either confirm or correct me on this assumption? Matthew Gardiner According to the 5.2 TODO list it's GCC 3.3. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libmap.conf has the bug or not work correct?
On Tue, Jun 03, 2003 at 03:50:00PM -0500, Jeremy Messenger wrote: I am trying to get ggv link against libc_r instead libthr, but it doesn't work as expect.. Maybe, I must have done something wrong? Make sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c. It fixes a bug in the libmap.conf parsing code. # cat /etc/libmap.conf libc_r.so.5 libthr.so.1 libc_r.so libthr.so [/usr/X11R6/bin/ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so [ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so # uname -a FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Jun 2 20:23:45 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ i386 I even rebuilt rtld-elf (WITH_LIBMAP=yes in /etc/make.conf) and ggv then reinstall them, but no luck. The ggv is still linking to libthr instead libc_r.. Also, ggv isn't only one app that I tried. I did tried with gst- register and no luck to change the link to libc_r. # ldd /usr/X11R6/bin/ggv | grep libc libc.so.5 = /usr/lib/libc.so.5 (0x28a68000) libc_r.so.5 = /usr/lib/libthr.so.1 (0x28b49000) Do anyone have any hint? Cheers, Mezz -- bsdforums.org 's moderator, mezz. -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s4bios
Date: Tue, 3 Jun 2003 16:03:19 -0400 From: The Anarcat [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I put my test results in: http://anarcat.ath.cx/acpi-test/ I have done other tests using a build made after the recent ACPI import and bugfixes, and I will update the info there when completely done. Could you add the result of sysctl hw.acpi? As is, it's not clear that your platform supports S1. The output will also let you know about a number of other things. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout with 5.1BETA2
Date: Tue, 3 Jun 2003 23:00:21 +0200 From: Tobias Roth [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi I still get a fxp0: device timeout on my Thinkpad T30 with a newly installed 5.1BETA2. Browsing the archives showed that people had success with hint.fxp.0.prefer_iomap=1 on a T30 and 5.1BETA1. Any ideas why this doesn't help in my case? Odd. I have not seen this on my T30 running a CURRENT from May 29 (or almost Beta2). I do not have any hint like you suggest, either. My fxp0 has been working very well. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s4bios
On Tue Jun 03, 2003 at 06:17:10PM -0700, Kevin Oberman wrote: Date: Tue, 3 Jun 2003 16:03:19 -0400 From: The Anarcat [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I put my test results in: http://anarcat.ath.cx/acpi-test/ I have done other tests using a build made after the recent ACPI import and bugfixes, and I will update the info there when completely done. Could you add the result of sysctl hw.acpi? As is, it's not clear that your platform supports S1. The output will also let you know about a number of other things. Done! More tests results underway, I'll just have to find some time to write them down... A. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker http://www.ad-mad.co.uk/quotes/freespeech.htm pgp0.pgp Description: PGP signature
Re: s4bios on Dell Latitude C640
I gave it a final try and mounted an empty disk into my laptop. Using the MKS2D.EXE found on the Dell support site I created a hibernation partition on the beginning of the disk (It needs to be within 8 GB of the start of the disk). And guess what... I can now suspend to disk using acpiconf -s 4, no more shutting down for me! ;-) I created a nice script that modifies boot0 before and after calling acpiconf -s 4 so that the suspend partition only shows when you are rebooting after a suspend. I will post that later, it's on my other disk that is not mounted now. Happy, (Well, I still have to repartition my laptop, but ok ... ) Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: s4bios
On Tue, Jun 03, 2003 at 04:01:16PM -0700, Hiten Pandya wrote: Hello Mark, I may not be totally correct, but it has always helped me to check if a particular ACPI state was supported by my system: # sysctl hw.acpi.supported_sleep_state hw.acpi.supported_sleep_state: S1 S4 S5 Yeah, too tired right now to see where that gets decided in the code, but I knew/know that my laptop supports S4BIOS. (The S4BIOS_F flag in the FACS) Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libmap.conf has the bug or not work correct?
On Tue, 3 Jun 2003 18:01:52 -0700, David P. Reese Jr. [EMAIL PROTECTED] wrote: On Tue, Jun 03, 2003 at 03:50:00PM -0500, Jeremy Messenger wrote: I am trying to get ggv link against libc_r instead libthr, but it doesn't work as expect.. Maybe, I must have done something wrong? Make sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c. It fixes a bug in the libmap.conf parsing code. I downgrade from 1.7 - 1.6 and the problem is still there. I CVSup'ed yesterday around 30 to 45 minutes before my 'uname -a' in the bottom. Cheers, Mezz # cat /etc/libmap.conf libc_r.so.5 libthr.so.1 libc_r.so libthr.so [/usr/X11R6/bin/ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so [ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so # uname -a FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Jun 2 20:23:45 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ i386 I even rebuilt rtld-elf (WITH_LIBMAP=yes in /etc/make.conf) and ggv then reinstall them, but no luck. The ggv is still linking to libthr instead libc_r.. Also, ggv isn't only one app that I tried. I did tried with gst-register and no luck to change the link to libc_r. # ldd /usr/X11R6/bin/ggv | grep libc libc.so.5 = /usr/lib/libc.so.5 (0x28a68000) libc_r.so.5 = /usr/lib/libthr.so.1 (0x28b49000) Do anyone have any hint? Cheers, Mezz -- bsdforums.org 's moderator, mezz. -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libmap.conf has the bug or not work correct?
On Tue, 03 Jun 2003 21:04:11 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: On Tue, 3 Jun 2003 18:01:52 -0700, David P. Reese Jr. [EMAIL PROTECTED] wrote: On Tue, Jun 03, 2003 at 03:50:00PM -0500, Jeremy Messenger wrote: I am trying to get ggv link against libc_r instead libthr, but it doesn't work as expect.. Maybe, I must have done something wrong? Make sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c. It fixes a bug in the libmap.conf parsing code. I downgrade from 1.7 - 1.6 and the problem is still there. I CVSup'ed yesterday around 30 to 45 minutes before my 'uname -a' in the bottom. Here's more info It works if my libmap.conf looks like: # cat /etc/libmap.conf libc_r.so.5 libc_r.so.5 # Before was libthr libc_r.so libc_r.so # ^ [/usr/X11R6/bin/ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so [ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so Result: # ldd /usr/X11R6/bin/ggv | grep libc libc.so.5 = /usr/lib/libc.so.5 (0x28a68000) libc_r.so.5 = /usr/lib/libc_r.so.5 (0x28b49000) It seems like the [/path/to/exec] and [exec] don't work? Cheers, Mezz # cat /etc/libmap.conf libc_r.so.5 libthr.so.1 libc_r.so libthr.so [/usr/X11R6/bin/ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so [ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so # uname -a FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Jun 2 20:23:45 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ i386 I even rebuilt rtld-elf (WITH_LIBMAP=yes in /etc/make.conf) and ggv then reinstall them, but no luck. The ggv is still linking to libthr instead libc_r.. Also, ggv isn't only one app that I tried. I did tried with gst-register and no luck to change the link to libc_r. # ldd /usr/X11R6/bin/ggv | grep libc libc.so.5 = /usr/lib/libc.so.5 (0x28a68000) libc_r.so.5 = /usr/lib/libthr.so.1 (0x28b49000) Do anyone have any hint? Cheers, Mezz -- bsdforums.org 's moderator, mezz. -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libmap.conf has the bug or not work correct?
On Tue, 3 Jun 2003, Jeremy Messenger wrote: It seems like the [/path/to/exec] and [exec] don't work? ftp://ftp.jurai.net/users/winter/libmap-test.tar Untar that in src/libexec/rtld-elf/ cd test/ make ./test-libmap /path/to/exec library-name -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libmap.conf has the bug or not work correct?
On Tue, 3 Jun 2003 22:51:59 -0400 (EDT), Matthew N. Dodd [EMAIL PROTECTED] wrote: On Tue, 3 Jun 2003, Jeremy Messenger wrote: It seems like the [/path/to/exec] and [exec] don't work? ftp://ftp.jurai.net/users/winter/libmap-test.tar Untar that in src/libexec/rtld-elf/ cd test/ make ./test-libmap /path/to/exec library-name # ./test-libmap /usr/X11R6/bin/ggv libc_r.so.5 Lookup of libc_r.so.5 for /usr/X11R6/bin/ggv - libc_r.so.5 # ./test-libmap /usr/X11R6/bin/ggv libthr.so.1 [...etmpy...] # cat /etc/libmap.conf libc_r.so.5 libthr.so.1 libc_r.so libthr.so [/usr/X11R6/bin/ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so [ggv] libc_r.so.5 libc_r.so.5 libc_r.so libc_r.so Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
On Tue, 3 Jun 2003, Bryan Liesner wrote: Actually, no it doesn't. I was able to use kern_umtx v 1.3 only if I removed atapicam from my kernel config. These patches (now committed?) panic the system whether I use atapicam or not. With kern_umtx v1.2 there is no panic at all, with or without atapicam. Actually, I think it's cam in general that's causing the panic with these changes. Bizarre. Sounds like an errant pointer in some other code, and it's just a matter of the memory layout as to what gets stepped on. Alternatively, it might be affected by the insertion of the MTX sysinit event. Perhaps that revision rearranges memory a bit. Anyhow, here are some things you might consider, since this whole thing is so odd. Try merging the addition of the struct mtx declaration from 1.3 into 1.2 and see if you get the same panic. If you don't, try merging the MTX_SYSINIT line and see if that triggers the panic. The other changes probably wouldn't cause disruptive memory rearrangement, so see what happens. If the panics appear with the addition of the variable, it probably is a memory stepping thing and a bug in some other piece of code (unfortunately, probably hard to track down). If it's the addition of the initializer, it's a different class of problem. I have to admit that I'm also fairly baffled: my current reading of the change suggests there won't be a specific bug in umtx, rather, the triggering of symptoms from another bug, but I guess we can only find out with a bit of experimentation. You might also find the problem disappears if you remove INVARIANTS, although given that you can reproduce this nicely, I'm reluctant to have you do that for fear the bug will get away and not get fixed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On Tue, Jun 03, 2003 at 10:54:30AM -0700, David P. Reese Jr. wrote: [...] : The datasheet states that the command bits are RW but fixed at 0. A snip of code from sys/dev/pci/pci.c:pci_enable_io_method(): pci_set_command_bit(dev, child, bit); command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); if (command bit) return (0); device_printf(child, failed to enable %s mapping!\n, error); return (ENXIO); Because the viapropm's command register bits will always read as zero, this code will always fail when trying to enable port mapping. Whatever problems viapropm may have, it is the new pci code that prevents it from attaching. It is not the fault of anything in sys/pci/viapm.c. And I personally don't know how to fix it except by an option with an ifdef to workaround it. -- Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
Paul Richards wrote: On Mon, Jun 02, 2003 at 09:04:11AM -0700, Hiten Pandya wrote: And how many times is vfc_register() called? Its not in the patch of an I/O operation or anything. Its just a mount time overhead which will go through -- a one time thing. On Mon, Jun 02, 2003 at 08:17:03AM -0700, Terry Lambert wrote: Consider this going forward: someone adds a new VFSOP to the list of allowable VFSOPs, and the vfs_init() doesn't have any specific code for it. You should look at kobj, it's precisely this sort of dynamic dispatching that it was designed to support. I think it's inappropriate technology for the VFSOP and VOP cases. The real issue with VFSOP and VOP calls is that they are call-by-descriptor, and the descriptor reference can be proxied across a protection domain, no problem, as long as there are not weird defaults. For example, with a proxy in and out of the kernel of a top and bottem end named pipe/socket/other datia serialization interface, it's possible to do VFS stacking layer develeopement in user space, where there are better debugging tools, and where a failure is not fatal to the kernel. That means that the developement can proceed much rapidly from prototype to the finished product. It's also possible to proxy over a network; this provides a means of implementing an extensible network file system framework (like that which was prototyped by John Heidemann's students) to implement operations, as needed. One of the widely acknowledged weaknesses of NFS is it's inability to be meaningfully extended for things like extended attributes, ACLs, mandatory access controls, etc. -- all things requiring VFSOPs or VOPs to to b added to the protocol, structures defined, agreed upon by both parties, etc., etc.. With the descriptor mechanism, I may pass from the system call interface to a quiota stacking layer on a local machine, to a crypto stacking layer on a border machine, over the Internet, to a crypto layer on another border machine at the remote site, to a local machine at the remote site, and then down to FFS and from there to a local disk array. Not only that, the middle layers don't have to know all the VOPs descriptors, because they pass them through unmolested, and so the border machines are unaware of how to decode the content they are transiting. I really can't do this with kobj; with kobj, I can only pass the interface references around within a single protection domain on a single machine. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HD Speed Benchmark
Sebastian Yepes [ESN] wrote: I have made some Benchmark on my inspiron 8500 (Intel 82801DB (ICH4) - UDMA100) and i am geting very Bad results on the 5.1, i have got beter results on 5.0 dmesg -- 5.0R -- http://www.x123.info/src/i8500/dmesg.5.0R 5.1B2 -- http://www.x123.info/src/i8500/dmesg.5.1B2 ad0: 28615MB FUJITSU MHS2030AT [58140/16/63] at ata0-master BIOSDMA ad0: 28615MB FUJITSU MHS2030AT [58140/16/63] at ata0-master UDMA100 Notice the firrence in DMA messages... probably has a little to do with it, don't you think? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
Scott Long wrote: Bryan Liesner wrote: It's very hard to imagine Jeff's patches causing a problem at the point that the PR mentions. Have you confirmed the problem in a kernel that was build in a totally clean environment? The changed code is not protecting a traversal of a proc struct member with a proc lock in two places. What's hard to imagine? Even if it's weren't necessary to protect that FOREACH loop (it's necessary; but even if it weren't...), locking the proc could easily serialize a number of operations through that or other code which could save it from interference. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A possible bug?
Zbynek Houska wrote: Dear all, when I tryied to mount an iso image over network (using samba) my computer unexpectedly crashed. I issued this command : mdconfig -a -t vnode -f /path/to/my/file/mounted/on-local-machine and since that kernel crashed, no ping response, nothing at all. I've been connected to this machine via ssh. I use 5.0 RELEASE with GENERIC kernel on P3/1 Ghz, 128 MB RAM. It happens again when I issue same command and therefore I tryied to add dumpon=Yes to my /etc/rc.conf, but nothing has been written to /var/crash. So I enclose message from screen: Fatal trap 12 : page fault while in kernel mode faukt virtual address = 0x0 fault code= supervisor read, page not present instruction pointer= 0x8:0xc1c50d4a stack pointer = 0x10:0xcd1b8718 frame pointer = 0x10:0xcd1b8738 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def31 1, gran 1 processor eflags = interrupt enabled, resume,IOPL = 0 current proccess = 549 (mdconfig) trap number= 12 panic:fault page I'm seeing the same thing with 5.1-RC1. Tried to mount an ISO image with mdconfig -a -t vnode -f isofile -u 0 and FreeBSD immediately panic-ed. The iso file resided on a samba mount, which I had mounted with mount_smbfs. I'll try cp-ing the file to my local UFS filesystem, and then try mdconfig, and see if I get the panic again. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
On Tue, 3 Jun 2003, Terry Lambert wrote: Scott Long wrote: Bryan Liesner wrote: It's very hard to imagine Jeff's patches causing a problem at the point that the PR mentions. Have you confirmed the problem in a kernel that was build in a totally clean environment? The changed code is not protecting a traversal of a proc struct member with a proc lock in two places. What's hard to imagine? This is no longer the case with the latest revision. Apparently the panics in cam continue even after the proc lock issues were fixed. Even if it's weren't necessary to protect that FOREACH loop (it's necessary; but even if it weren't...), locking the proc could easily serialize a number of operations through that or other code which could save it from interference. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Missing file geom_vol_ffs on buildkernel?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 === geom/geom_vol_ffs I'm getting this error when I buildkernel: cd: can't cd to /usr/src/sys/modules/geom/geom_vol_ffs *** Error code 2 Stop in /usr/src/sys/modules/geom. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. enola# cd /usr/src/sys/modules/geom/geom_vol_ffs /usr/src/sys/modules/geom/geom_vol_ffs: No such file or directory. Google search just showed that this was added in the beginning of May '03. Any ideas? - -- Mike Loiterman grantADLER Medical Corporation Tel: 630-302-4944 Fax: 773-868-0071 Email: [EMAIL PROTECTED] PGP Key 0xD1B9D18E -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 Comment: This message has been digitally signed by Mike Loiterman iQA/AwUBPt2RXGjZbUnRudGOEQLWhwCg/wp8qGM2ZLIOOBJpVFbO7Xx53OcAoIJs uOG1MSRzudz8xa+lKvX0RLBT =DeIi -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtx/libthr SMP fixes.
On Tue, 3 Jun 2003, Robert Watson wrote: On Tue, 3 Jun 2003, Bryan Liesner wrote: Actually, no it doesn't. I was able to use kern_umtx v 1.3 only if I removed atapicam from my kernel config. These patches (now committed?) panic the system whether I use atapicam or not. With kern_umtx v1.2 there is no panic at all, with or without atapicam. Actually, I think it's cam in general that's causing the panic with these changes. Bizarre. Sounds like an errant pointer in some other code, and it's just a matter of the memory layout as to what gets stepped on. Alternatively, it might be affected by the insertion of the MTX sysinit event. Perhaps that revision rearranges memory a bit. Even more bizarre. I have cvsupped to the latest source, built a kernel with DDB and it won't panic. Without DDB, it panics. But the behavior has changed a bit. I now panics _without_ atapicam in the build, at boot time. With atapicam, it panics and dumps core if I do an init 6. Savecore refuses to grab the dump: gravy savecore: first and last dump headers disagree on /dev/ad0s1b gravy savecore: unsaved dumps found but not saved I cleared the dump and tried again with the same results. If I reboot with the USB drive mounted, it will panic on the init 6, unmounted, it reboots without trouble. Any hints on grabbing a dump without savecore complaining, please let me know. I don't have anything specific to report yet, when I have time tomorrow I'll try to get more information out. Anyhow, here are some things you might consider, since this whole thing is so odd. Try merging the addition of the struct mtx declaration from 1.3 into 1.2 and see if you get the same panic. If you don't, try merging the MTX_SYSINIT line and see if that triggers the panic. The other changes probably wouldn't cause disruptive memory rearrangement, so see what happens. If the panics appear with the addition of the variable, it probably is a memory stepping thing and a bug in some other piece of code (unfortunately, probably hard to track down). If it's the addition of the initializer, it's a different class of problem. Right now I'm at rev 1.4 of kern_umtx... I'll try reverting back and trying this time permitting... I have to admit that I'm also fairly baffled: my current reading of the change suggests there won't be a specific bug in umtx, rather, the triggering of symptoms from another bug, but I guess we can only find out with a bit of experimentation. You might also find the problem disappears if you remove INVARIANTS, although given that you can reproduce this nicely, I'm reluctant to have you do that for fear the bug will get away and not get fixed. INVARIANTS wasn't in the picture to begin with. If I put it in, it will probably disappear, as with using DDB. The code has changed sufficiently now that I can't reproduce the original panic that's in the PR, but it's still panicking... -- = = Bryan D. LiesnerLeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED] Home of the Gipper= = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On Wed, Jun 04, 2003 at 07:29:31AM +, Nicolas Souchu wrote: On Tue, Jun 03, 2003 at 10:54:30AM -0700, David P. Reese Jr. wrote: [...] : The datasheet states that the command bits are RW but fixed at 0. A snip of code from sys/dev/pci/pci.c:pci_enable_io_method(): pci_set_command_bit(dev, child, bit); command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); if (command bit) return (0); device_printf(child, failed to enable %s mapping!\n, error); return (ENXIO); Because the viapropm's command register bits will always read as zero, this code will always fail when trying to enable port mapping. Whatever problems viapropm may have, it is the new pci code that prevents it from attaching. It is not the fault of anything in sys/pci/viapm.c. And I personally don't know how to fix it except by an option with an ifdef to workaround it. How about adding another flag to bus_alloc_resource() which would signal that we are not to check the value of the command register after calling pci_set_command_bit(). RF_WILLFAIL? After pci_enable_io_method() gets swallowed into pci_alloc_resource(), this would be pretty easy because the flag would be in scope when we check the value of the command register. I can do so this weekend if anyone thinks this is worthwhile. -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: phoenix crash in libc_r on sparc64
On Mon, Jun 02, 2003 at 04:15:43PM -0700, Kris Kennaway wrote: phoenix on my sparc64 crashed while idle with the following: Fatal error '_waitq_insert: Already in queue' at line 321 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 2) Any ideas? Kris One of the libc_r tests seems to hang: Test static library: -- Test c_user c_system c_total chng passed/FAILEDh_user h_system h_total % chng -- hello_d 0.00 0.020.02 passed -- hello_s 0.00 0.020.02 passed -- join_leak_d 0.77 0.180.95 passed -- mutex_d 9.0892.42 101.50 passed -- sem_d 0.01 0.020.02 passed -- sigsuspend_d0.00 0.020.02 passed -- sigwait_d 0.00 0.020.02 *** FAILED *** -- guard_s.pl It's been sitting there for hours now. Kris P.S. Why do 3 of the tests even fail on i386? pgp0.pgp Description: PGP signature
Re: Missing file geom_vol_ffs on buildkernel?
Mike Loiterman wrote: === geom/geom_vol_ffs I'm getting this error when I buildkernel: cd: can't cd to /usr/src/sys/modules/geom/geom_vol_ffs *** Error code 2 Google search just showed that this was added in the beginning of May '03. Any ideas? cvs update -d -- Skip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Tuesday 03 June 2003 12:00 am, Paul Richards wrote: On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Paul Richards [EMAIL PROTECTED] writes: : The possible methods available in an interface are fixed, they're : defined in the .m files. No it isn't. One can add additional interfaces at any time without breaking binary compatibility, so you don't know, a priori, the number of methods in a given interface when you build a client of that interface. I don't think that's true. The interface is defined in the .m file and it's created using makeobjs. You can't do that at runtime because it creates the kobj_desc struct that uniquely represents the existence of that method globally for the whole of the kobj subsystem. The set of all kobj_desc defines all possible methods that can be implemented by an object, and yes you can extend that interface later and previously built modules will still work because they only implement a subset of those possible methods, but the set of all methods that can exist is determined at compile time from the interface definitions A class is then defined which specifies the set of methods that objects instantiated into that class *can* implement (but are note required to). The set of methods in a class is also fixed, since it's basically the method table plus some class fields and the method table is created at compile time. Again though, if you later extend the class older compiled modules will still work because if the method doesn't exist in that older module the default from the kobj_desc will be used or the kobj_error_method will be called (which is safe). So yes you can extend the interface and the class and keep backwards compatibility but that all happens at compile time, and therefore at runtime when the object is instantiated you know the maximum number of methods that the object can possibly call. It is true, I'm afraid. A class is can implement any number of interfaces so knowing the compile-time size of an interface doesn't help you reserve space for a class. The system is intended to have a robust ABI so that e.g. a class implementing an interface can be used safely by a kernel in which new methods have been added to that interface. The class is a concrete definition of a set of methods (at this level, the interfaces are mostly ignored). Objects instantiated in that class use exactly that set of methods, no more, no less. There is no choice involved. You appear to be confusing class and interface here. This incarnation of kobj uses a smallish fixed-size method dispatch table, with hashing. A previous version (embedded into 4.x's newbus) allocated space in the method dispatch table for every interface which was currently resident in the kernel. This was fine when the expected number of interfaces was small but as the number of interfaces increases, the wasted space per-class increases unacceptably. This is the sole reason for changing the method-dispatch algorithm for kobj. The only valid objection to kobj at this point is that resolving hash collisions is not SMP safe. I believe that this is a limitation which can be overcome without pessimising the dispatch mechanism. Performance is not an issue. The performance of method dispatch in kobj is very slightly slower than a vtable-style array of function pointers but the difference is barely measurable. Given the behaviour of modern caches, it is possible to make nearly as many kobj method calls per second as normal function calls. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI and PCI vs interrupt routing on Sony VAIO's
Hi, I have a Sony VAIO (PCG-R505TFP) which has an interrupts related problem (this problem was previous posted elsewhere as Weird as* sound problem). This problem has been confirmed on at least one other Sony VAIO model (I forget which). They're both Intel i830M chipset based. Basically, the LNKB interrupt configuration register is not being initialised, so the interrupt never gets routed, and so the interrupt never gets to the CPU. Result: Sound doesn't work. A really hacky solution to this is to run the command: pciconf -w -b pci0:31:0 0x61 9 which sets the i830's PCI routing register for LNKB to IRQ 9. I did a bit of digging and found the following bits of information: 1. When the ACPI PCI bus starts up, it calls all the LNKx.CRS methods to get the current resources. LNKB (amongst others) returns 0. 2. The PCI configuration space register for IRQ contains the value 9. 3. If somebody calls the LNKB.SRS method, it would all work because that writes the PCI interrupt routing register thingy like pciconf does above. But the acpi_pcib_route_interrupt() function is not being called because in pci_alloc_resource() there is a test that checks if the PCI config space register that contains the interrupt contains a valid number (which it does - 9). So, basically I think there is something wrong here, which I think is that ACPI and the generic PCI code (in pci_alloc_resource()) don't agree when it comes to interrupt management. Other than saying the BIOS is broken (which it is, providing mislead information and all), is it a fair statement to say that the ACPI CRS method should be trusted more than the PCI configuration space registers? If so, then if the PCI conf space register disagrees with the ACPI result, should the PCI conf space register be updated to show what the ACPI stuff shows? I'm happy to muddle up a patch that might do this, but I was hoping for a bit of a guide as to how to do it. I thought initially that I could update the PCI config space register at the time the LNKs CRS method was called, but quickly gave up on that because I don't know which device to update... Could I instead perhaps implement the pci_alloc_resource() method in acpi_pcib_pci.c which inspects the existing PCI configuration and the ACPI LNK information and if they differ, put the ACPI value into the PCI configuration register, then call the pci_alloc_resource() function to finish off. Then pci_alloc_resource() will see a bad value for the PCI config space IRQ, and call the PCIB_ROUTE_INTERRUPT method to do the routing. Or is there a better place (or way) to do this. (Can I even legally call pci_alloc_resource() from acpi_pcib_pci_alloc_resource()?). For extra information, here is a rather verbose dmesg and AML dump: http://starbug.ugh.net.au/~iaint/vaio/dmesg.txt http://starbug.ugh.net.au/~iaint/vaio/ruri.aml Oh yeah, not using ACPI is not an option (panics in either PCI or PnP BIOS), also I think the same problem would exist then since it would still not try to route interrupts, but I could be wrong. Iain ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Mon, 2003-06-02 at 21:04, Paul Richards wrote: On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote: Notice how thread 1's _m gets set based on the results of the kobj lookup, and we have a race, even if thread1 and thread2 took out their driver instance locks. That means we have to lock the dispatch table before every method is looked up and hold it until the method returns (the alternative would be to free it inside the method once it had been called but that'd be a right mess). Don't even think about trying to put a mutex into the kobj dispatch sequence. That would make the call several thousand times slower. We might as well write the kernel in Visual Basic. I've been thinking about this problem for a long time and I'm certain there is a way to make this safe without sacrificing performance. I have an idea I'm working on right now which should work (at least I haven't managed to disprove it so far) and which would have approximately the same performance profile as the current mechanism. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI and PCI vs interrupt routing on Sony VAIO's
Good Explain. The same problem is in my PCG-R505DC. Jun Su --- Iain Templeton [EMAIL PROTECTED] wrote: Hi, I have a Sony VAIO (PCG-R505TFP) which has an interrupts related problem (this problem was previous posted elsewhere as Weird as* sound problem). This problem has been confirmed on at least one other Sony VAIO model (I forget which). They're both Intel i830M chipset based. Basically, the LNKB interrupt configuration register is not being initialised, so the interrupt never gets routed, and so the interrupt never gets to the CPU. Result: Sound doesn't work. A really hacky solution to this is to run the command: pciconf -w -b pci0:31:0 0x61 9 which sets the i830's PCI routing register for LNKB to IRQ 9. I did a bit of digging and found the following bits of information: 1. When the ACPI PCI bus starts up, it calls all the LNKx.CRS methods to get the current resources. LNKB (amongst others) returns 0. 2. The PCI configuration space register for IRQ contains the value 9. 3. If somebody calls the LNKB.SRS method, it would all work because that writes the PCI interrupt routing register thingy like pciconf does above. But the acpi_pcib_route_interrupt() function is not being called because in pci_alloc_resource() there is a test that checks if the PCI config space register that contains the interrupt contains a valid number (which it does - 9). So, basically I think there is something wrong here, which I think is that ACPI and the generic PCI code (in pci_alloc_resource()) don't agree when it comes to interrupt management. Other than saying the BIOS is broken (which it is, providing mislead information and all), is it a fair statement to say that the ACPI CRS method should be trusted more than the PCI configuration space registers? If so, then if the PCI conf space register disagrees with the ACPI result, should the PCI conf space register be updated to show what the ACPI stuff shows? I'm happy to muddle up a patch that might do this, but I was hoping for a bit of a guide as to how to do it. I thought initially that I could update the PCI config space register at the time the LNKs CRS method was called, but quickly gave up on that because I don't know which device to update... Could I instead perhaps implement the pci_alloc_resource() method in acpi_pcib_pci.c which inspects the existing PCI configuration and the ACPI LNK information and if they differ, put the ACPI value into the PCI configuration register, then call the pci_alloc_resource() function to finish off. Then pci_alloc_resource() will see a bad value for the PCI config space IRQ, and call the PCIB_ROUTE_INTERRUPT method to do the routing. Or is there a better place (or way) to do this. (Can I even legally call pci_alloc_resource() from acpi_pcib_pci_alloc_resource()?). For extra information, here is a rather verbose dmesg and AML dump: http://starbug.ugh.net.au/~iaint/vaio/dmesg.txt http://starbug.ugh.net.au/~iaint/vaio/ruri.aml Oh yeah, not using ACPI is not an option (panics in either PCI or PnP BIOS), also I think the same problem would exist then since it would still not try to route interrupts, but I could be wrong. Iain ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Wed, Jun 04, 2003 at 10:01:07AM +0100, Doug Rabson wrote: On Tuesday 03 June 2003 12:00 am, Paul Richards wrote: On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Paul Richards [EMAIL PROTECTED] writes: : The possible methods available in an interface are fixed, they're : defined in the .m files. No it isn't. One can add additional interfaces at any time without breaking binary compatibility, so you don't know, a priori, the number of methods in a given interface when you build a client of that interface. I don't think that's true. The interface is defined in the .m file and it's created using makeobjs. You can't do that at runtime because it creates the kobj_desc struct that uniquely represents the existence of that method globally for the whole of the kobj subsystem. The set of all kobj_desc defines all possible methods that can be implemented by an object, and yes you can extend that interface later and previously built modules will still work because they only implement a subset of those possible methods, but the set of all methods that can exist is determined at compile time from the interface definitions A class is then defined which specifies the set of methods that objects instantiated into that class *can* implement (but are note required to). The set of methods in a class is also fixed, since it's basically the method table plus some class fields and the method table is created at compile time. Again though, if you later extend the class older compiled modules will still work because if the method doesn't exist in that older module the default from the kobj_desc will be used or the kobj_error_method will be called (which is safe). So yes you can extend the interface and the class and keep backwards compatibility but that all happens at compile time, and therefore at runtime when the object is instantiated you know the maximum number of methods that the object can possibly call. It is true, I'm afraid. A class is can implement any number of interfaces so knowing the compile-time size of an interface doesn't help you reserve space for a class. The system is intended to have a robust ABI so that e.g. a class implementing an interface can be used safely by a kernel in which new methods have been added to that interface. I though Warner meant adding interfaces at runtime, but he meant build time (I misread that). My comments about interfaces where therefore in rebuttal of the possibility to extend them at runtime. So yes, what Warner asserted is true but as I did also point out above and you've confirmed below, it's the class that determines the methods for an object and that is fixed when the object is instantiated into that class. The class is a concrete definition of a set of methods (at this level, the interfaces are mostly ignored). Objects instantiated in that class use exactly that set of methods, no more, no less. There is no choice involved. You appear to be confusing class and interface here. Given that we agree that the method table is fixed at object instantiation time, why isn't allocating a fixed array appropriate? -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Wed, Jun 04, 2003 at 12:09:00PM +0100, Doug Rabson wrote: On Mon, 2003-06-02 at 21:04, Paul Richards wrote: On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote: Notice how thread 1's _m gets set based on the results of the kobj lookup, and we have a race, even if thread1 and thread2 took out their driver instance locks. That means we have to lock the dispatch table before every method is looked up and hold it until the method returns (the alternative would be to free it inside the method once it had been called but that'd be a right mess). Don't even think about trying to put a mutex into the kobj dispatch I wasn't, I was just pointing out what would be necessary if the cacheing problem wasn't resolved :-) -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Wed, 2003-06-04 at 13:24, Paul Richards wrote: On Wed, Jun 04, 2003 at 10:01:07AM +0100, Doug Rabson wrote: On Tuesday 03 June 2003 12:00 am, Paul Richards wrote: On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Paul Richards [EMAIL PROTECTED] writes: : The possible methods available in an interface are fixed, they're : defined in the .m files. No it isn't. One can add additional interfaces at any time without breaking binary compatibility, so you don't know, a priori, the number of methods in a given interface when you build a client of that interface. I don't think that's true. The interface is defined in the .m file and it's created using makeobjs. You can't do that at runtime because it creates the kobj_desc struct that uniquely represents the existence of that method globally for the whole of the kobj subsystem. The set of all kobj_desc defines all possible methods that can be implemented by an object, and yes you can extend that interface later and previously built modules will still work because they only implement a subset of those possible methods, but the set of all methods that can exist is determined at compile time from the interface definitions A class is then defined which specifies the set of methods that objects instantiated into that class *can* implement (but are note required to). The set of methods in a class is also fixed, since it's basically the method table plus some class fields and the method table is created at compile time. Again though, if you later extend the class older compiled modules will still work because if the method doesn't exist in that older module the default from the kobj_desc will be used or the kobj_error_method will be called (which is safe). So yes you can extend the interface and the class and keep backwards compatibility but that all happens at compile time, and therefore at runtime when the object is instantiated you know the maximum number of methods that the object can possibly call. It is true, I'm afraid. A class is can implement any number of interfaces so knowing the compile-time size of an interface doesn't help you reserve space for a class. The system is intended to have a robust ABI so that e.g. a class implementing an interface can be used safely by a kernel in which new methods have been added to that interface. I though Warner meant adding interfaces at runtime, but he meant build time (I misread that). My comments about interfaces where therefore in rebuttal of the possibility to extend them at runtime. So yes, what Warner asserted is true but as I did also point out above and you've confirmed below, it's the class that determines the methods for an object and that is fixed when the object is instantiated into that class. Interfaces actually can be added at runtime. Existing objects (i.e. objects instantiated before the new interface was added) will continue to work as before. If methods from the new interface are called on old objects, the default method will be called. The class is a concrete definition of a set of methods (at this level, the interfaces are mostly ignored). Objects instantiated in that class use exactly that set of methods, no more, no less. There is no choice involved. You appear to be confusing class and interface here. Given that we agree that the method table is fixed at object instantiation time, why isn't allocating a fixed array appropriate? Mainly because there isn't an easy way to decide how big the array should be. The older version of this code reserved enough space for all current interfaces. This ended up wasting a lot of space (per class, not per object) and still ended up with a table size comparison in the method dispatch since interfaces might get added after existing classes had been initialised. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Additions to sys/dev/usb/usbdevs
Hi, I've added definitions for a few of the devices that I have connected up to my system at the moment. Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/--- usbdevs.origWed Jun 4 18:10:45 2003 +++ usbdevs Wed Jun 4 18:40:29 2003 @@ -497,6 +497,7 @@ product CANON N656U0x2206 CANOSCAN N656U product CANON S10 0x3041 PowerShot S10 product CANON S100 0x3045 PowerShot S100 +product CANON S200 0x3065 PowerShot S200 /* CATC products */ product CATC NETMATE 0x000a Netmate ethernet adapter @@ -814,6 +815,7 @@ product LOGITECH WMJOY 0xc281 WingMan Force joystick product LOGITECH RK53 0xc501 Cordless mouse product LOGITECH RB6 0xc503 Cordless keyboard +product LOGITECH MX700 0xc506 Cordless optical mouse product LOGITECH QUICKCAMPRO2 0xd001 QuickCam Pro /* Lucent products */ @@ -1038,6 +1040,7 @@ product SHUTTLE EUSCSI_B 0x000b eUSCSI Bridge product SHUTTLE EUSCSI_C 0x000c eUSCSI Bridge product SHUTTLE CDRW 0x0101 CD-RW Device +product SHUTTLE EUSBORCA 0x0325 eUSB ORCA Quad Reader /* Siemens products */ product SIEMENS SPEEDSTREAM0x1001 SpeedStream USB @@ -1155,6 +1158,7 @@ product WACOM CT0405U 0x CT-0405-U Tablet product WACOM GRAPHIRE 0x0010 Graphire product WACOM INTUOSA5 0x0021 Intuos A5 +product WACOM GD0912U 0x0022 Intuos 9x12 Graphics Tablet /* Xirlink products */ product XIRLINK PCCAM 0x8080 IBM PC Camera ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMBFS automounting broken?
I have opened a PR with a cleaner patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=52959 A. -- Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est pas réfutable relève de la magie ou de la mystique. - Popper, Karl pgp0.pgp Description: PGP signature
Re: our compiler can't convert longlong to float? 5.1-RC1
On Thu, Jun 05, 2003 at 09:44:38AM +0800, leafy wrote:
On Tue, Jun 03, 2003 at 03:55:47PM -0700, Kris Kennaway wrote:
Post the code it's trying to run. It's possible it's buggy.
Kris
#include stdio.h
typedef long long longlong;
main()
{
longlong ll=1;
float f;
FILE *file=fopen(conftestval, w);
f = (float) ll;
fprintf(file,%g\n,f);
close(file);
exit (0);
}
this section of code is found in configure script in mysql323-client port.
It compiles and runs here without problems.
Kris
pgp0.pgp
Description: PGP signature
RE: SU not working on fresh CVSUP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, June 03, 2003 9:09 AM Fernando Gleiser mailto:[EMAIL PROTECTED] wrote: Did you run mergemaster(8) after buildworld/installworld ? I did but, I must have skipped the pam file. My fault. Thanks for the help. - -- Email: [EMAIL PROTECTED] PGP Key 0xD1B9D18E -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 Comment: This message has been digitally signed by Mike Loiterman iQA/AwUBPtzczGjZbUnRudGOEQJiaACgpGV5yhP/m0cDzEa8l1Gfscu6CqgAn0WJ x1kgfeZ3E15g8pCTX5LEsIbb =f3Yi -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
