Re: config(8) weirdness
EEK! I will take a look at this right now... Motomichi Matsuzaki wrote: Hi. At Sun, 27 Aug 2000 15:16:01 +0200 (CEST), Alexander Leidinger [EMAIL PROTECTED] wrote: Can anyone success compiling kernel with the following config? # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #optionsATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices I've the same problem. This is obvous BUG of config(8), newly introduced 'count' feature. In /sys/conf/files.i386 : dev/ata/atapi-all.c count atapicd dev/ata/atapi-all.c count atapifd dev/ata/atapi-all.c count atapist On the current implementation, the first line is only effective, i.e. same as: dev/ata/atapi-all.c count atapicd #dev/ata/atapi-all.c count atapifd #dev/ata/atapi-all.c count atapist Then, atapi-all.c will be copiled only when atapicd is enabled. To exchange the lines of files.i386 takes effect as a symptomatic therapy. But..., fix for config(8) is needed. -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
On Sun, Oct 01, 2000 at 12:20:04AM -0500, Tony Johnson wrote: Run 4.0 or piss off... Tony, I suggest you apologise to Mr Choi for this extremely insulting message. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
Run 4.0 or piss off... That's totally inappropriate. He's reporting a BUILD ERROR which is an occasional fact of life in -current and should be reported so that whomever broke AMD can go fix the build. He's also a developer of FreeBSD and simply reporting this to the other developers. I'm getting very tired of you, Tony. I think it's time for you to go off the air for awhile before all of us feel the same way. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setting device permissions for DEVFS
Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
You guys are overlooking something about DEVFS: devices may appear
post-boot.
Ah, yes.
BTW: Devices don't disappear if you unload devices.
This happens for example with bktr.ko.
When I then reload bktr.ko, I get the following:
WARNING: Driver mistake: repeat make_dev("bktr0")
WARNING: Driver mistake: repeat make_dev("tuner0")
WARNING: Driver mistake: repeat make_dev("vbi0")
We need a generic "devd" which finds out that devices have appeared,
set their perms (if needed/wanted) and executes any commands needed
(getty, mount, etc etc) by the device.
Hmm. A technical question: How would the devd be notifed about an
event in the devfs?
Does it open a (new) device as for example the usbd does, or how would
you solve that?
Alex
--
cat: /home/alex/.sig: No such file or directory
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: setting device permissions for DEVFS
In message [EMAIL PROTECTED], Alexander Langer write s: Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]): You guys are overlooking something about DEVFS: devices may appear post-boot. Ah, yes. BTW: Devices don't disappear if you unload devices. This happens for example with bktr.ko. That is because the bktr driver fails to call destroy_dev() when it unloads. Hmm. A technical question: How would the devd be notifed about an event in the devfs? There are many ways to do this, a kqueue() or poll() based solution is probably the correct way, monitoring the sysctl vfs.devfs.generation is the QD way. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
Cool. On some machine, thermal management requires Embedded Controller I/O. Anybody working on this? Yeah. I just discovered that I need this. I haven't look at how operation regions are handled, so I'm not sure how hard it's going to be to implement the hooks necessary for this. Some VAIOs, ThinkPads require this too, luckily my PORTEGE doesn't. I can test the thermal management code earlier :-) Swine. 8) Yes :-) PowerResource code keeps pointers to the PowerResource objects, then finds a pointer to methods of the object dynamically. Can we do it in similar way for thermal management? Well, yes, but you have to go back and re-parse the actual AML. I'm not even sure if it's safe to assume that the thermal zone is in the same place in the bytecode (it should be, I guess). I also think it shoud be... I went reading through the ACPICA documentation to work this out. They acually have a very nice technique where they attach the I/O handlers to a point in the namespace, and then when something attempts I/O, they travel back up the namespace to the root, looking for the first matching I/O handler. This means that when your EC driver finds an embedded controller, you just attach your I/O handler to the EC object. Then anytime someone tries to do I/O to the EC, your handler gets called. Yes, we can have large benefit by migrating to ACPICA. I suggest that we make ACPICA version of AML interpreter run in userland as a debugger for the first evaluation. By doing this work we can make sure it works actually on FreeBSD and estimate the work volume of kernel porting. Also we know the amldb is very useful from our development experience. Another suggestion is that this migration should be done prudently. During ACPICA porting, we add ACPICA compatible wrappers to current aml code (e.g. AcpiWalkNamespace() - aml_apply_foreach_found_objects()) and modify acpi driver code so that we migrate to ACPICA smoothly. BTW, last time Watanabe-san tried to write EC stuff, but unfortunately his laptop was broken *twice* by testing. Be careful, otherwise your Dell will go to the hospital 8) I can write the driver easily enough, but I don't know how I/O is currently handled in the AML interpreter. The more I look at ACPICA, the more I like the idea of using it, presuming that it actually works... Last time I compared only few files and found many differences between them not only for naming. I think these two used the same code originally, but enhanced separately. Now that it's difficult to compare them... Hmm. I guess I should spend some more time looking at this. I don't mean to devalue all the work that's been put into the current AML code, but ACPICA has already solved a lot of the problems that we haven't even touched yet (Notify, locking, etc...) OK, before making our decision, I want to make sure something. - Licence Linux folks apply GPL for it. Is it possible to apply BSD style licence for FreeBSD version of ACPICA? or should we put it sys/contrib? - Support from Intel My major concern is this one. I wonder whether our local changes for ACPICA can feed back to original code. If not, maintenance will become hard... Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Oddity after SMPNG kernel
Hi. I've upgraded my -current box from a pre-SMPNG kernel (an August vintage) to a post-SMPNG kernel (built today), and have noticed behaviour I haven't seen discussed in -current. I followed the instructions in UPDATING as well as discussed on the -current list, and the system boots with nothing out of the ordinary. There is no /modules, and the host is a UP machine. However, after approximately 20-30 minutes, it appears to slow down immensely, until it basically halts. Keyboard input at the console appears not to have any effect (although Caps, Scroll and Num lock work). The machine is pingable, and I can change VT's, but no input is accepted. All services on the box get as far as the Connected stage, but no banner appears. I left it for several minutes, and saw microuptime() went backwards (2757.4076411 - 2757.992648), with the right hand side number increasing periodically. After I hard-boot the machine it carries on as normal again for 20-30 minutes before reverting to it's zombie state. Booting a kernel prior to the SMPNG changes does not have the same problems. Should I revert to PRE_SMPNG days, with a cvsup tag of *default release=cvs tag=PRE_SMPNG ? Here is the output of dmesg : 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 5.0-CURRENT #0: Sun Oct 1 13:41:45 SAST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/CHAIN Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 200456354 Hz CPU: Pentium/P54C (200.46-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 117440512 (114688K bytes) config port sbc 0x220 config q avail memory = 110428160 (107840K bytes) Preloaded elf kernel "kernel" at 0xc039d000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc039d09c. Intel Pentium detected, installing workaround for F00F bug ccd0-1: Concatenated disk drivers VESA: v1.2, 2048k memory, flags:0x0, mode table:0xc00c1bfc (c0001bfc) VESA: S3 Incorporated. Trio64V+ npx0: math processor on motherboard npx0: INT 16 interface pcib0: SiS 5591 host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 atapci0: SiS 5591 ATA33 controller port 0x4000-0x400f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 irq 14 at devic e 0.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 isab0: SiS 85c503 PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pci0: unknown card (vendor=0x1039, dev=0x0009) at 1.1 pcib1: PCI to PCI bridge (vendor=1039 device=0001) at device 2.0 on pci0 pci1: PCI bus on pcib1 pci0: S3 Trio graphics accelerator at 9.0 irq 5 de0: Digital 21041 Ethernet port 0xe000-0xe07f mem 0xea00-0xea7f irq 9 at device 11.0 on pci0 de0: SMC 21041 [10Mb/s] pass 1.1 de0: address 00:00:c0:f9:2f:c8 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 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 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 plip0: PLIP network interface on ppbus0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 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 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0f13 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0400 can't assign resources unknown: PNP0501 can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default IPsec: Initialized Security Association Processing. de0: enabling 10baseT port ad0: 8693MB WDC AC29100D [17662/16/63] at ata0-master UDMA33 ad1: 1033MB WDC AC21000H [2100/16/63] at ata1-master WDMA2 Mounting root from ufs:/dev/ad0s1a Khetan Gajjar. --- [EMAIL PROTECTED] * [EMAIL PROTECTED]* PGP Key, contact UUNET South Africa * FreeBSD enthusiast * details and other http://www.uunet.co.za * http://www.freebsd.org * information at System Administration * http://office.os.org.za * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
At 1 Oct 2000 04:24:14 GMT, CHOI Junho [EMAIL PROTECTED] wrote: I have cvsup'ed today, build stopped with the following error: I got same one, reported by my nightly buildworld failure. I think this happened between 9/30 00:00 JST and 10/1 00:00 JST... -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
In message [EMAIL PROTECTED] "Tony Johnson" writes: : Run 4.0 or piss off... Tony, this is an *UN*acceptible attitude. CHOI-san is reporting a problem. He didn't rail against anything, nor did he demand a fix. This is 100% acceptible. Your message, however, was rude and inappropriate. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
In message [EMAIL PROTECTED] Mitsuru IWASAKI writes: : Thanks Shiozaki-san, I think `reg' is short for registers of the : target chip, correct? Yes. Traditionally fooreg.h has "hardware" definitions on it. Device registers, flag masks and other such things. Both OLDCARD and NEWCARD do this. : How about kernel/userland shareable stuff like ioctl? Traditionally, these have been placed in fooio.h. The reason that foo.h hasn't been used more is, as pointed out earlier, foo.h is generated by config. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
On Sun, 01 Oct 2000 11:35:32 -0600, Warner Losh [EMAIL PROTECTED] said: Tony, this is an *UN*acceptible attitude. CHOI-san is reporting a problem. He didn't rail against anything, nor did he demand a fix. This is 100% acceptible. Your message, however, was rude and inappropriate. I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "It is dangerous to be right in matters on which the established authorities are wrong." -- Voltaire To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setting device permissions for DEVFS
In message [EMAIL PROTECTED] Alexander Langer writes:
: No - instead we should add something like devfs_permission{0,1,2,etc}
: (and maybe ownership) to rc.conf, which can be modified there and
: then rc.devfs sets them - similar to the ifconfig stuff.
:
: Opinions?
devd? We need it for other reasons (think removable devices).
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: setting device permissions for DEVFS
In message 11056.970344237@critter Poul-Henning Kamp writes: : We need a generic "devd" which finds out that devices have appeared, : set their perms (if needed/wanted) and executes any commands needed : (getty, mount, etc etc) by the device. ifconfig and dhclient are likely the most often executed ones now. I agree we need a generic devd. Does devfs use the kqueue interface? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kthread_create()
In message [EMAIL PROTECTED] Alan Cox writes: : Does anyone know if it's by design or by accident that kthread_create : specifies RFFDG to fork1? It seems odd to ask for the file descriptor : table to be copied and not shared. I think that I did that, or Peter didn't change it. I copied it from NetBSD of the time. I think it made sense to me since I wanted stdout to be the console. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setting device permissions for DEVFS
In message [EMAIL PROTECTED], Warner Losh writes: In message 11056.970344237@critter Poul-Henning Kamp writes: : We need a generic "devd" which finds out that devices have appeared, : set their perms (if needed/wanted) and executes any commands needed : (getty, mount, etc etc) by the device. ifconfig and dhclient are likely the most often executed ones now. I agree we need a generic devd. Does devfs use the kqueue interface? Not right now, but it could. Right now you can tell something happened by examining the sysctl vfs.devfs.generation -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setting device permissions for DEVFS
In message 14852.970422933@critter Poul-Henning Kamp writes: : Not right now, but it could. Right now you can tell something happened : by examining the sysctl vfs.devfs.generation OK. As soon as I get NEWCARD attaching devices, I'll revisit this as it is needed for pccard stuff. If things go well, this will be before BSDcon, but I keep hitting new problems with newer -current that weren't there in earlier versions :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setting device permissions for DEVFS
Thus spake Warner Losh ([EMAIL PROTECTED]): Don't you mean pccard.conf? You can do the mounting now. I think that umount -f would work for dismounting on eject, but haven't tested it. No, I meant /etc/pccard_ether :) It works just fine. I don't unmount, though. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
Mike Smith [EMAIL PROTECTED] wrote: I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. Thing is, I for one can't figure out what just changed. I've been manually following all the ways sys/callout.h would be included, and none seem to apply here. For example, sys/systm.h isn't included in any way I can tell by this amd file, and sys/callout.h isn't explicitly either. This is really annoying. So, sys/callout.h should be in #ifdef _KERNEL #endif /* _KERNEL */, but I just can't find out what broke it in the first place so I didn't want to fix anything. It would be nice to have the system Mozilla uses for this where we can pinpoint automatically what commit broke things. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. It wasn't clear to me if it was clashing with the internal typedef or something else - the namespace issues with gcc are a little unclear to me here (at least it's not VMS C, with a global member name space :). In any case, we can certainly revert the change if it transpires that the pollution came from elsewhere and for now, at least, -current is working again. clock.c includes a butt-load of system headers through am_defs.h and I can't immediately tell if the callout stuff is being exposed inappropriately or not. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote: I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. This commit also took a file off the vendor branch and the maintainer of src/contrib was not consulted. The committer that committed something w/o testing `make world' should have backed out their commit and then discussed that they wanted a change made in Amd or taken a different approach in their commit. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
PowerResource code keeps pointers to the PowerResource objects, then finds a pointer to methods of the object dynamically. Can we do it in similar way for thermal management? Well, yes, but you have to go back and re-parse the actual AML. I'm not even sure if it's safe to assume that the thermal zone is in the same place in the bytecode (it should be, I guess). I also think it shoud be... /me crosses his fingers I went reading through the ACPICA documentation to work this out. They acually have a very nice technique where they attach the I/O handlers to a point in the namespace, and then when something attempts I/O, they travel back up the namespace to the root, looking for the first matching I/O handler. This means that when your EC driver finds an embedded controller, you just attach your I/O handler to the EC object. Then anytime someone tries to do I/O to the EC, your handler gets called. Yes, we can have large benefit by migrating to ACPICA. I suggest that we make ACPICA version of AML interpreter run in userland as a debugger for the first evaluation. By doing this work we can make sure it works actually on FreeBSD and estimate the work volume of kernel porting. Also we know the amldb is very useful from our development experience. Indeed. I've just taken the hard path to start with, and got the kernel integration (mostly) resolved. Fortunately, the ACPICA code includes a complete user-space ACPI interpreter for just this purpose. I think some of their test code has rotted a bit (eg. their AcpiDump tool), but it shouldn't be too hard to get this going. Another suggestion is that this migration should be done prudently. During ACPICA porting, we add ACPICA compatible wrappers to current aml code (e.g. AcpiWalkNamespace() - aml_apply_foreach_found_objects()) and modify acpi driver code so that we migrate to ACPICA smoothly. This would be very difficult. BTW, last time Watanabe-san tried to write EC stuff, but unfortunately his laptop was broken *twice* by testing. Be careful, otherwise your Dell will go to the hospital 8) Ack. I'll bear that in mind. Hmm. I guess I should spend some more time looking at this. I don't mean to devalue all the work that's been put into the current AML code, but ACPICA has already solved a lot of the problems that we haven't even touched yet (Notify, locking, etc...) OK, before making our decision, I want to make sure something. - Licence Linux folks apply GPL for it. Is it possible to apply BSD style licence for FreeBSD version of ACPICA? or should we put it sys/contrib? The Intel licence on the "generic Unix" version of ACPICA is suitable for direct inclusion in FreeBSD. I'm not sure that the Intel code shouldn't be in sys/contrib *anyway*. - Support from Intel My major concern is this one. I wonder whether our local changes for ACPICA can feed back to original code. If not, maintenance will become hard... If we do things right, we should have little trouble with this. We have some pretty good relations with the right parts of Intel, and as long as we keep the code changes clean, they should be happy to accept them. Given how much work the Intel people went through just to get their code into the Linux kernel, I think they will find us *much* more friendly. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Interesting AML bug... recommended workaround?
Here's what seems to be an interesting AML or AML parser bug.
OperationRegion(PSRG, SystemMemory, 0x0410, 0x1)
Field(PSRG, DWordAcc, NoLock, Preserve) {
, 2,
PS2E, 1
}
The field is marked for 32-bit access, but the region is only 1 byte
wide. What's the correct thing to do here? Expand the region to
accomodate the field's access requirements? Constrain the access size of
the field to that of the region?
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
This is better than watching the soaps. I'll be waiting anxiously for the next installment. ;) On Sun, 1 Oct 2000 12:47:16 -0700, "David O'Brien" [EMAIL PROTECTED] said: On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote: I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. This commit also took a file off the vendor branch and the maintainer of src/contrib was not consulted. The committer that committed something w/o testing `make world' should have backed out their commit and then discussed that they wanted a change made in Amd or taken a different approach in their commit. -- -- David ([EMAIL PROTECTED]) -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "Doing bad things is not evangelism." -- Ann Hafften To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
subscribe [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
"WL" == Warner Losh [EMAIL PROTECTED] writes: WL this is an *UN*acceptible attitude. CHOI-san is reporting a -san is Japanese word, and I am Korean. Due to historical reason, most Korean do not want to be treated as Japanese and most of them will be angry. Please don't call me 'CHOI-san'. Equivalent word is '-nim' in Korean online community. But it should be after his given name, not surname. 'Junho-nim' is good, but you don't have to always. -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho [EMAIL PROTECTED] [EMAIL PROTECTED] KFUG http://www.kr.FreeBSD.org Web Data Bank http://www.wdb.co.kr FreeBSD, GNU/Linux Developer http://people.FreeBSD.org/~cjh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] ncv, nsp, stg SCSI drivers
Sorry, the files colud not fetch. I think you can now fetch them. // Noriaki Mitsunaga From: [EMAIL PROTECTED] Date: Sat, 30 Sep 2000 15:20:07 +0900 From: Poul-Henning Kamp [EMAIL PROTECTED] Date: Wed, 27 Sep 2000 15:25:42 +0200 Use a normal timeout ? I changed to use timeout() and now they do not change clock.c. Updated files can be obtained from, http://home.jp.freebsd.org/~non/scsi_low-2930.tar.gz (added files) http://home.jp.freebsd.org/~non/scsi_low-2930.diff.gz (diff to current) http://home.jp.freebsd.org/~non/scsi_low4-2930.diff.gz (diff to stable) You will need the tar.gz file and one of diff.gz file. Or you can obtain the diff from, http://home.jp.freebsd.org/~non/scsi_low-2926-2930.diff.gz To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sendmail related changes
Gregory Neil Shapiro writes: sendmail's version of vacation is completely backwards compatible with the existing version. It also contains new features and bug fixes that are not in the current FreeBSD version. This will take care of PR bin/15227. 2. Copy cf config building tree into /usr/share/sendmail/cf Yes to all three! For #2, we can maybe go a step further.. the README in that directory is somewhat daunting. For example, we could also copy the /usr/src/etc/sendmail directory into /usr/share/sendmail/cf/freebsd or something like that (maybe with a simpler Makefile) and include a few more example config files besides "freefall.mc" that demonstrate how to configure in various scenarios. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
adv0 - panic
I get a "Panic: Page fault while in supervisor mode" just after adv0 is displayed during boot. If I just remove the card, I can boot. Current current. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATA disk support broken for PC-CARD in 5.0-CURRENT??
Hi,
PC-CARD IDE hard disk and compact flash card support is broken
in recent 5.0-CURRENT. Does anyone have an idea what the problem is?
Please copy reply to me. I don't subscribe to the 'current' mailing list.
Thanks,
-chain
I have been using compact flash card and ATA disks on my
Toshiba 3440CT running FreeBSD 4.0 release without problem.
Recently I updated my system to 5.0-CURRENT (I use cvsup
every now and then and rebuild and install). Now whenever I
plug in a compact flash card or a 2.5 inch ide disk I get the following:
-
pccard: card inserted, slot 0
Sep 30 23:49:37 alice pccardd[33545]: Card "Microtech International
Inc."("IDE PCCARD") [(C) ARCHOS S.A. 1995-98 Fax +33 1 60
13 99 18] [(null)] matched "Microtech International Inc." ("IDE PCCARD")
[(null)] [(null)]
ata4 at port 0x250-0x25f irq 5 slot 0 on pccard0
ata4-master: ata_command: timeout waiting for intr
ata4-master: identify failed
Sep 30 23:49:52 alice pccardd[33545]: ata4: Microtech International Inc.
(IDE PCCARD) inserted.
-
I cannot use any of the PCCARD device using the ATA driver any more.
Do you have any idea what is going on? I would appreciate your help in
getting
this working again.
I also have same problem. I could use compact flash under
5-current last month.. I think this problem is related to
sys/dev/ata changes.
Would you ask this problem in [EMAIL PROTECTED] mailing list?
---
MIHIRA, Sanpei Yoshiro
Yokohama, Japan.
Re: ACPI megapatch
Yes, we can have large benefit by migrating to ACPICA. I suggest that we make ACPICA version of AML interpreter run in userland as a debugger for the first evaluation. By doing this work we can make sure it works actually on FreeBSD and estimate the work volume of kernel porting. Also we know the amldb is very useful from our development experience. Indeed. I've just taken the hard path to start with, and got the kernel integration (mostly) resolved. Fortunately, the ACPICA code includes a complete user-space ACPI interpreter for just this purpose. I think some of their test code has rotted a bit (eg. their AcpiDump tool), but it shouldn't be too hard to get this going. I and acpi-jp folks discussed ACPICA migration last night, there is no objections so far. Most of them agreed that evaluation must be done at least. Some people already started lerning ACPICA with documents and source code. Mike, I'm feeling we need to have a migration plan. Do you have any plan on this? # I have to learn first before my participation to the discussion :-) Another suggestion is that this migration should be done prudently. During ACPICA porting, we add ACPICA compatible wrappers to current aml code (e.g. AcpiWalkNamespace() - aml_apply_foreach_found_objects()) and modify acpi driver code so that we migrate to ACPICA smoothly. This would be very difficult. OK, but I'll try, this will be my private project. I won't complain anything if most of the code is deleted after migration. I hope I'll get some understanding on ACPICA programming. OK, before making our decision, I want to make sure something. - Licence Linux folks apply GPL for it. Is it possible to apply BSD style licence for FreeBSD version of ACPICA? or should we put it sys/contrib? The Intel licence on the "generic Unix" version of ACPICA is suitable for direct inclusion in FreeBSD. I'm not sure that the Intel code shouldn't be in sys/contrib *anyway*. I see. I found that we may have additional license terms, but I leave it to your discretion. - Support from Intel My major concern is this one. I wonder whether our local changes for ACPICA can feed back to original code. If not, maintenance will become hard... If we do things right, we should have little trouble with this. We have some pretty good relations with the right parts of Intel, and as long as we keep the code changes clean, they should be happy to accept them. OK. Given how much work the Intel people went through just to get their code into the Linux kernel, I think they will find us *much* more friendly. 8) # Welcome new committers from Intel :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interesting AML bug... recommended workaround?
Here's what seems to be an interesting AML or AML parser bug.
OperationRegion(PSRG, SystemMemory, 0x0410, 0x1)
Field(PSRG, DWordAcc, NoLock, Preserve) {
, 2,
PS2E, 1
}
The field is marked for 32-bit access, but the region is only 1 byte
wide. What's the correct thing to do here? Expand the region to
accomodate the field's access requirements? Constrain the access size of
the field to that of the region?
I thought read 32-bit, update target bits, write back whole 32-bit for
updating. For reading value, read 32-bit and shift mask bits as well.
I hope I could understand description in Spec 15.2.3.3.1.9; "If desired,
AccessType can be used to force minimum access width."
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
