Re: interesting problem
* Tony Johnson [EMAIL PROTECTED] [000928 17:54] wrote: I really did not want to reply to this but since some people believe that I am just see-ing things, then I will set this straight. No we don't Tony, we aren't claiming any stability in -current, I'm sure people will remeber your initial bug report and eventually work out a fix. Unfortunatly for you they may also remeber how you continued to hammer on this issue while completely deluding yourself. I have a dual PPro-200 systems. aha-3950u2 scsi card. Teflon cables from scsi-cables.com. Segate cheetah 4.5gig drive that runs FreeBSD5.0-Current since it came out. I have been running FreeBSD for years... I ran 3.0 and 4.0 when they were /current and I never had these problems. You were obviously luckier than I was at times. I cannot even get the thing (5.0-Current in recent days) to boot from boot floppies that you put on ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386. If you are producing an OS that does not boot on /current then say this publicly and not curse me out for your production of a non functional product. We do, read on. I'm sure I could produce a set of non-functioning asm code that just crashes peoples machines, if your idea of development is this. I don't believe that I need to write an email list for this. Actually Tony, I'm unsure if you're able to produce _any_ code because so I really can't remeber seeing any code produced by you. You also seriously need to read the handbook, http://www.freebsd.org/handbook/current-stable.html: 18.2.1.1. What is FreeBSD-CURRENT? FreeBSD-CURRENT is, quite literally, nothing more than a daily snapshot of the working sources for FreeBSD. These include work in progress, experimental changes and transitional mechanisms that may or may not be present in the next official release of the software. While many of us compile almost daily from FreeBSD-CURRENT sources, there are periods of time when the sources are literally un-compilable. These problems are generally resolved as expeditiously as possible, but whether or not FreeBSD-CURRENT sources bring disaster or greatly desired functionality can literally be a matter of which part of any given 24 hour period you grabbed them in! It goes on to say: 18.2.1.3. What is FreeBSD-CURRENT not? 1.A fast-track to getting pre-release bits because you heard there is some cool new feature in there and you want to be the first on your block to have it. 2.A quick way of getting bug fixes. 3.In any way ``officially supported'' by us. We do our best to help people genuinely in one of the 3 ``legitimate'' FreeBSD-CURRENT categories, but we simply do not have the time to provide tech support for it. This is not because we are mean and nasty people who do not like helping people out (we would not even be doing FreeBSD if we were), it is literally because we cannot answer 400 messages a day and actually work on FreeBSD! I am sure that, if given the choice between having us answer lots of questions or continuing to improve FreeBSD, most of you would vote for us improving it. Can you imagine that! Yup, you were warned, you were told, the only thing we couldn't do (unfortunatly) is fly someone over to fwap you with a rolled up newspaper when you initially thought of running -current. I think all three points are reason enough for you to stop using -current. I have a better idea, how about an option on the install to save buffer cache to a floppy disk , or atleast the portion that caused the automatic reboot??? Gdb anyone? Sure, send patches, follow my previous advice or simply piss off. jeez, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: interesting problem
* Thomas David Rivers [EMAIL PROTECTED] [000928 03:34] wrote: Alfred, Just playing `devils advocate' here. But, in some initial install situations, exactly how is the user, even the most knowledgeable one, supposed to do much of anything if the install itself doesn't work? Not too much chance of building a kernel, getting a crashdump, etc... I think I just detailed how one could do that in my first two responses. Although it may be something we want to put off for awhile, being able to gather debugging information during a failed install would be rather nice. I'm not sure how this could happen; perhaps a crashdump to an MSDOS file system (if available)? Or, straight to a partition with some recovery program that reads the dump? Or, over a serial line? [Just tossing out ideas.] Maybe ficl can get involved and manage this? I would keep this as one of those "maybe nice to have in the ideal future" ideas - but it's something to ponder... Yes, it's a very good idea. I've brought up changing the default panic to output a traceback so that the user could post it, but bringing it up is a far cry from implementing it. * even without debug symbols a traceback can be very helpful if one can locate the IP and text addresses of the kernel. However, he shouldn't have been using -current in the first place, and when someone offers to reach out and help it's not the time to get snippy about it. (seriously, refusing to read the handbook?) I've been guilty of this sort of cluelessness and arrogance in the past and I'm glad that a few people came down on me about my attitude while at the same time offering extremely useful advice. Jordan, Mike Smith and John Polstra to name a few, all in one incident actually. I think without their application of knowledge and smack-down I wouldn't have learned nearly as much. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: Avoiding version checking of CD-ROM (patch included)
Speaking about sysinstall, would you please check my PR (bin/21423, URL:http://www.freebsd.org/cgi/query-pr.cgi?pr=21423) ? Done and fixed, thanks! It should be in the next (2930) -current snapshot in ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/ - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: Avoiding version checking of CD-ROM (patchincluded)
jkh Done and fixed, thanks! Wow, thank you ^_^ But.. maybe my PR is not clearly described, it does not fix current situation; very sorry for my poor presentations. Here is a current directory structure (just extracted tarballs) of 5-current as of Sep/29/2000. % cd ~ftp/pub/FreeBSD/snapshots/i386/livetree/5-LATEST/ % ls COPYRIGHT cdrom.inf kernel.GENERIC roottmp bin dev mnt sbinusr bootetc procsys var % ls boot/kernel/kernel* zsh: no matches found: boot/kernel/kernel* % We can easily found that: * Generic kernel is /kernel.GENERIC. (and sysinstall copies /kernel.GENERIC to /kernel when installed) * There is no /boot/kernel/kernel. We cannot boot without kernel:) So, it should be: * Generic kernel go to /boot/kernel directory (I have no idea of about its filename). * After installation, /boot/kernel/kernel exists. To do that, we can: * modify src/release/Makefile to put generic kernel under /boot/kernel. * modify src/release/install.c to copy generic kernel to /boot/kernel/kernel. or, * modify src/release/Makefile to put generic kernel to /boot/kernel/kernel. * modify src/release/install.c, not to do copying generic kernel. (this is done by rev. 1.283) Sorry if I'm wrong, -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My system hang with ACPI kernel thread
From: Takanori Watanabe [EMAIL PROTECTED] Date: Thu, 28 Sep 2000 13:38:57 +0900 ::With the addition of ACPI kernel thread, my system hangs in about ::10 miniutes use after boot up. By disabling kernel thread, system ::runs just fine. :: ::Do you have any idea where to look at? ::I'll try and see what I can do myself. :: ::Please set debug.aml_debug and debug.acpi_debug to 1 and ::see what will happen. I'm sorry, there was a fault on my side. I had old /modules directory (Pre SMPng patch), and for some reason if enabled ACPI kernel thread, system hang. I've removed everything under /modules and system seems to be happy! So sorry for the false alarm. Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI megapatch
Here's the latest ACPI megapatch:
- Move all the register I/O into a separate file
- Made all the I/O spaces use proper bus resources
- Allocate the resources in machine-dependant code
- Map ACPI-used memory in machine-dependant code
- Create a machine-dependant "acpiprobe" device which just knows
how to find and set up ACPI for the machine-independant code
- Remove all the ACPI #ifdefs from non-ACPI code
- Minor style and commenting fixes
Issues outstanding:
- Need to remove superfluous headers
- Need to decide the correct split between sys/acpi.h and
sys/dev/acpi/acpi.h in terms of functionality.
Comments, etc. all welcome as usual.
Index: conf/files
===
RCS file: /host/fs/local0/cvs/src/sys/conf/files,v
retrieving revision 1.416
diff -u -r1.416 files
--- conf/files 2000/09/23 22:21:39 1.416
+++ conf/files 2000/09/27 10:17:04
@@ -75,7 +75,8 @@
#dev/aac/aac_debug.c optional aac
dev/aac/aac_disk.c optional aac
dev/aac/aac_pci.c optional aac pci
-dev/acpi/acpi.ccount acpi
+dev/acpi/acpi.coptional acpi
+dev/acpi/acpi_io.c optional acpi
dev/acpi/acpi_powerres.c optionalacpi
dev/acpi/aml/aml_amlmem.c optionalacpi
dev/acpi/aml/aml_common.c optionalacpi
Index: dev/acpi/acpi.c
===
RCS file: /host/fs/local0/cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.14
diff -u -r1.14 acpi.c
--- dev/acpi/acpi.c 2000/09/27 05:43:53 1.14
+++ dev/acpi/acpi.c 2000/09/29 07:54:01
@@ -52,7 +52,6 @@
#include sys/rman.h
#include sys/acpi.h
-
#include dev/acpi/acpi.h /* for softc */
#include dev/acpi/aml/aml_amlmem.h
@@ -63,38 +62,14 @@
#include dev/acpi/aml/aml_parse.h
#include dev/acpi/aml/aml_memman.h
-#include machine/acpi_machdep.h /* for ACPI_BUS_SPACE_IO */
-
-/*
- * ACPI pmap subsystem
- */
-#define ACPI_SMAP_MAX_SIZE 16
-
-struct ACPIaddr {
- int entries;
- struct {
- vm_offset_t pa_base;
- vm_offset_t va_base;
- vm_size_t size;
- u_int32_t type;
- } t [ACPI_SMAP_MAX_SIZE];
-};
-
-static void acpi_pmap_init(void);
-static void acpi_pmap_release(void);
-static vm_offset_t acpi_pmap_ptv(vm_offset_t pa);
-static vm_offset_t acpi_pmap_vtp(vm_offset_t va);
-static void acpi_free(struct acpi_softc *sc);
/*
* These items cannot be in acpi_softc because they are be initialized
* before probing for the device.
*/
-static struct ACPIaddr acpi_addr;
+struct ACPIaddr acpi_addr;
struct ACPIrsdp *acpi_rsdp;
-static int acpi_port;
-static int acpi_irq;
/* Character device */
@@ -122,32 +97,8 @@
};
/*
- * ACPI register I/O
+ * Miscellaneous utility functions
*/
-#defineACPI_REGISTER_INPUT 0
-#defineACPI_REGISTER_OUTPUT1
-static void acpi_register_input(u_int32_t ioaddr,
- u_int32_t *value, u_int32_t size);
-static void acpi_register_output(u_int32_t ioaddr,
-u_int32_t *value, u_int32_t size);
-static void acpi_enable_disable(acpi_softc_t *sc, boolean_t enable);
-static void acpi_io_pm1_status(acpi_softc_t *sc, boolean_t io,
- u_int32_t *a, u_int32_t *b);
-static void acpi_io_pm1_enable(acpi_softc_t *sc, boolean_t io,
- u_int32_t *a, u_int32_t *b);
-static void acpi_io_pm1_control(acpi_softc_t *sc, boolean_t io,
- u_int32_t *a, u_int32_t *b);
-static void acpi_io_pm2_control(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_pm_timer(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe0_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe0_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe1_status(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-static void acpi_io_gpe1_enable(acpi_softc_t *sc, boolean_t io, u_int32_t *val);
-
-/*
- * Miscellous utility functions
- */
-static int acpi_sdt_checksum(struct ACPIsdt * sdt);
static void acpi_handle_dsdt(acpi_softc_t *sc);
static void acpi_handle_facp(acpi_softc_t *sc, struct ACPIsdt *facp);
static int acpi_handle_rsdt(acpi_softc_t *sc);
@@ -164,8 +115,7 @@
/*
* ACPI events
*/
-static void acpi_process_event(acpi_softc_t *sc,
- u_int32_t status_a, u_int32_t status_b,
+static void acpi_process_event(acpi_softc_t *sc, u_int32_t status_e,
u_int32_t status_0, u_int32_t status_1);
static void acpi_intr(void *data);
static void acpi_enable_events(acpi_softc_t *sc);
@@ -174,22 +124,22 @@
/*
* Bus interface
*/
-static int acpi_send_pm_event(acpi_softc_t *sc, u_int8_t
Re: My system hang with ACPI kernel thread
Currently kernel thread seems broken, so mallocing storage in
acpi_queue_event() never be freed. I think number of events at a
point of tme is limited and we can have static storage for the events.
The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd)
would be a good example.
I have a megapatch for acpi.c that I am nearly ready to commit which
converts it to use bus resources for all I/O allocations. I'll fix this
in there, if you like.
I'm interested in your patch. Can I see it?
Sure. I'm not 100% sure it's going to work right, so please feel free
to tell me I've broken something...
I've just tried the patch, GREAT! it seems working for me perfectly w/o
any functional changes, much better than before. I'll do testing more.
I have some comments;
# most of them is not related with your patch :-) but I'd like to
# consult with you.
Can we separate the code which uses FreeBSD specific APIs and structs
into a other file or arrange them at one place?
Because I'm going to merge NetBSD porting effort, I want to avoid having
too many #ifdef __FreeBSD__. The patch is available at
http://www.imou.to/~AoiMoe/UNIX-at-Random/acpi/acpi-freebsd-netbsd-changes-2000-09-24.diff.gz
Because of above reason,
/*
* Debugging, console output
*
* XXX this should really be using device_printf
*/
extern int acpi_debug;
#define ACPI_DEVPRINTF(args...) printf("acpi0: " args)
I don't use device_printf() here.
# Also we don't have more than 2 instances of acpi :-)
static void
acpi_trans_sleeping_state(acpi_softc_t *sc, u_int8_t state)
:
/* XXX should be MI */
/* XXX should always be called with interrupts enabled! */
ef = read_eflags();
disable_intr();
for this, I referred the comments in ACPI spec 7.5.2.
// Required environment: Executing on the system boot
// processor. All other processors stopped. Interrupts --
// disabled. All Power Resources (and devices) are in
// corresponding device state to support NewState.
I don't know much about IA64, I'm not sure {read|write}_eflags()
inline functions will be available on IA64. Should we replace them
with save_intr() and restore_intr() ? because seems more general.
Also we need to consider SMP. There is no hack for it so far.
# I think APM BIOS Call need to be executed on the system boot
# processor too.
acpi_soft_off(void *data, int howto)
:
/* XXX Disable GPE intrrupt,or power on again in some machine */
acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, vala);
acpi_io_gpe1_enable(sc, ACPI_REGISTER_OUTPUT, vala);
This still give no effect on my PORTEGE. I think this should be done
in earlier phase. Maybe we'd better to have acpi_disable_events() and
call this at shutdown_pre_sync (or some such) for shutdown -p, also
call this in acpi_set_sleeping_state() for power button/acpiconf -s 5.
acpi_intr(void *data)
:
#if 0
/* Clear interrupt status */
val = enable; /* XXX */
acpi_io_gpe0_status(sc, ACPI_REGISTER_OUTPUT, val);
/* Re-enable interrupt */
acpi_io_gpe0_enable(sc, ACPI_REGISTER_OUTPUT, enable);
acpi_debug = 0; /* Shut up again */
#endif
GPE1 too, right? :-)
acpi_attach(device_t dev)
:
sc-iores[i].rsc = bus_alloc_resource(dev, SYS_RES_IOPORT,
sc-iores[i].rid,
0, ~0, 1, RF_ACTIVE);
^^
I didn't understand clearly for long time, but this give us more
flexibility w/o problems if we call bus_set_resource() and set count
correctly, right?
#ifndef ACPI_NO_ENABLE_ON_BOOT
acpi_enable_disable(sc, 1);
acpi_enable_events(sc);
acpi_intr((void *)sc);
#endif
Should we remove them and have acpi_enalbe="YES" in /etc/rc.conf just line APM ?
And last thing, how about header file name and location?
some poeple suggested that
/sys/dev/acpi/acpi.h should be renamed to acpivar.h. And
/sys/sys/acpi.h should be moved to /sys/dev/acpi.h (installed in
/usr/include/dev/acpi/acpi.h). We didn't care and are not interested
in this matter at all so far, but it seems quite reasonable for me and
doesn't hurt anything.
And *real* last thing :-)
msmith the code in machdep.c. Everything will move to acpi_machdep.c I'll also
msmith be deleting machine/acpi.h, as it's not necessary (and never was).
I think better to wait deleting until IA64 porting. I'm not sure if
this file really unnecessary or not.
Thanks!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
Thanks a lot mike, these are mostly acceptable for me. Here's the latest ACPI megapatch: - Move all the register I/O into a separate file Agreed. - Made all the I/O spaces use proper bus resources - Allocate the resources in machine-dependant code I prefer previous patch because most of the code in i386/acpi_machdep.c can be shared with IA64 I think. - Map ACPI-used memory in machine-dependant code Agreed. - Create a machine-dependant "acpiprobe" device which just knows how to find and set up ACPI for the machine-independant code I think only machine-dependant sub-routines should be in acpi_machdep.c, the rest common code should be moved back to dev/acpi/acpi.c. The first half of acpiprobe_identify() is trying to find rsdp, so renaming it to acpi_find_rsdp() (returns struct ACPIrsdp * or NULL), moving the rest of acpiprobe_identify() to dev/acpi/acpi.c:acpi_identify() and calling acpi_find_rsdp() from acpi_identify() would be better for me. acpiprobe_mapmem() seems machine-dependant, so just renaming (acpi_mapmem() ?) would be enough. acpiprobe_facp(), I think, is MI, should be moved dev/acpi/acpi.c and renamed (acpi_find_facp() ?). In summary, my suggestions are - i386/i386/acpi_machdep.c acpi_find_rsdp() and acpi_mapmem() - dev/acpi/acpi.c acpi_identify() and acpi_find_facp() - Remove all the ACPI #ifdefs from non-ACPI code - Minor style and commenting fixes Completely agreed. Issues outstanding: - Need to remove superfluous headers - Need to decide the correct split between sys/acpi.h and sys/dev/acpi/acpi.h in terms of functionality. I'd like to move and rename them as I said in my previous mail, sys/acpi.h - sys/dev/acpi/acpi.h shared by both kernel and userland programs sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h shared within kernel code (acpi stuff and related drivers) That's my rough understanding, but I could be wrong :-) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
From: Mitsuru IWASAKI [EMAIL PROTECTED] Subject: [acpi-jp 691] Re: ACPI megapatch Date: Fri, 29 Sep 2000 22:05:17 +0900 Message-ID: [EMAIL PROTECTED] Issues outstanding: - Need to remove superfluous headers - Need to decide the correct split between sys/acpi.h and sys/dev/acpi/acpi.h in terms of functionality. I'd like to move and rename them as I said in my previous mail, sys/acpi.h - sys/dev/acpi/acpi.h shared by both kernel and userland programs sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h shared within kernel code (acpi stuff and related drivers) IMHO, it's desirable to use the name "acpi.h", because of conflict with the file dumped by /usr/sbin/config. I love : fooreg.h : device dependent and implementation independent structures, macros, and others. foovar.h : implementation dependent ones. -- Takuya SHIOZAKI To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 692] Re: ACPI megapatch
From: "T.SHIOZAKI" [EMAIL PROTECTED] Subject: [acpi-jp 692] Re: ACPI megapatch Date: Fri, 29 Sep 2000 22:41:39 +0900 (JST) Message-ID: [EMAIL PROTECTED] IMHO, it's desirable to use the name "acpi.h", because of conflict Sorry, "it's desirable to avoid using ...". -- Takuya SHIOZAKI To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
Hi, I'd like to move and rename them as I said in my previous mail, sys/acpi.h - sys/dev/acpi/acpi.h shared by both kernel and userland programs sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h shared within kernel code (acpi stuff and related drivers) IMHO, it's desirable to use the name "acpi.h", because of conflict with the file dumped by /usr/sbin/config. I love : fooreg.h : device dependent and implementation independent structures, macros, and others. foovar.h : implementation dependent ones. Thanks Shiozaki-san, I think `reg' is short for registers of the target chip, correct? In ACPI's case, PM1 register and some such and maybe definitions for ACPI tables. How about kernel/userland shareable stuff like ioctl? for example, usb(4) has this kind of definitions in dev/usb/usb.h, not in usbreg.h. Is this a special case violating the guideline? I think we can distinguish them like "usb.h" and dev/usb/usb.h, also we will stop generating acpi.h in kernel build directory. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
In summary, my suggestions are - i386/i386/acpi_machdep.c acpi_find_rsdp() and acpi_mapmem() - dev/acpi/acpi.c acpi_identify() and acpi_find_facp() Here is a patch for your megapatch at http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff I'll be happy if you accept and commit this :-) Thanks! 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 wrote: In summary, my suggestions are - i386/i386/acpi_machdep.c acpi_find_rsdp() and acpi_mapmem() - dev/acpi/acpi.c acpi_identify() and acpi_find_facp() Here is a patch for your megapatch at http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff I'll be happy if you accept and commit this :-) I think it is better bus attachment code is in MD part than in MI part. And MD bus attachment code calls MI bus attachment code. For example,Current acpi_probe code rename to acpi_probesubr and call it from acpi_probe in acpi_machdep.c . And probe method and identify method should not be confused. Memory area check etc can be in MD acpi probe code. Takanori Watanabe a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IPX requires 'device random'
I am not aware of the full status of IPX networking support in -current, but I migrated my -stable kernel config as best I could. Kernel compilation completes, but linking fails due to a rand_ function not being present ( I do not have the exact error handy, but can generate for anyone who wants it.) A simple 'device random' to compile the support in statically rectifies the problem. -- :Kevin M. Dulzo: eyes betray a soul and bear its thinking beyond words they say so many things to me --vnvnation To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
setting device permissions for DEVFS
Hello! What is the suggested best way to set permissions on devices in DEVFS? (I want to chmod 664 /dev/acd0c to let users in the group operator burn CD-R's). Do we already have a common way that I missed? Or is the best way to put it into rc.local (or similar)? Thanks 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
procfs info.
Ciao. I need to know the exact format of the /proc/*/cmdline of FreeBSD. Actually I'm using 4.1 and I have discovered that at the end of cmdline file there are always 2 NULL characters. Is this a standard behaviour of FBSD cmdline ? From 3.0 is it changed or it will change ? Thanks. -- Bye, Mirko [EMAIL PROTECTED] (NeXTmail, MIME) PS: please include my email when reply. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: procfs info.
In the last episode (Sep 29), [EMAIL PROTECTED] said: I need to know the exact format of the /proc/*/cmdline of FreeBSD. Actually I'm using 4.1 and I have discovered that at the end of cmdline file there are always 2 NULL characters. You sure? $ uname -v FreeBSD 5.0-CURRENT #69: Tue Sep 5 18:59:54 CDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/DANSMP $ hd /proc/curproc/cmdline 68 64 00 2f 70 72 6f 63 2f 63 75 72 70 72 6f 63 |hd./proc/curproc| 0010 2f 63 6d 64 6c 69 6e 65 00 |/cmdline.| 0019 $ uname -v FreeBSD 4.0-STABLE #6: Tue Aug 8 18:35:09 CDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/EMSSRV5 $ hd /proc/curproc/cmdline 68 64 00 2f 70 72 6f 63 2f 63 75 72 70 72 6f 63 |hd./proc/curproc| 0010 2f 63 6d 64 6c 69 6e 65 00 |/cmdline.| 0019 -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
Here is a patch for your megapatch at http://people.FreeBSD.org/~iwasaki/acpi/patch-for-megapatch.diff I'll be happy if you accept and commit this :-) I think it is better bus attachment code is in MD part than in MI part. And MD bus attachment code calls MI bus attachment code. For example,Current acpi_probe code rename to acpi_probesubr and call it from acpi_probe in acpi_machdep.c . Hmm, I think you're talking about BI/BD. Most of ACPI code must be shared between IA32/IA64 (even bus interface code). Difference between them is very limited, we can put them in acpi_machdep.c. I like this model. NetBSD's pci code take this one (dev/pci/pci.c has MI code like pcimattach(), arch/*/pci/pci_machdep.c have a set of MD sub-routines for the specific machine architecture such as pci_conf_read().). I'm not sure this is correct or not, but it seems reasonable for me. And probe method and identify method should not be confused. Memory area check etc can be in MD acpi probe code. Yes, I think it's in acpi_machdep.c :-) if not, which one? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: procfs info.
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: I need to know the exact format of the /proc/*/cmdline of FreeBSD. Actually I'm using 4.1 and I have discovered that at the end of cmdline file there are always 2 NULL characters. I'm not seeing that on my 4.x-stable system from about a month ago: austin$ sleep 100 [1] 67372 austin$ hd 67372/cmdline 73 6c 65 65 70 00 31 30 30 00|sleep.100.| 000a As you can see, there's just a single NUL at the end. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: setting device permissions for DEVFS
On Fri, 29 Sep 2000, Alexander Langer wrote: What is the suggested best way to set permissions on devices in DEVFS? (I want to chmod 664 /dev/acd0c to let users in the group operator burn CD-R's). Do we already have a common way that I missed? /etc/rc.devfs - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sysinstall: Avoiding version checking of CD-ROM (patch included)
% ls boot/kernel/kernel* zsh: no matches found: boot/kernel/kernel* That's a different problem - there should be a boot/kernel/kernel.ko file and I'm not sure why there isn't. I'll talk to David O'Brien about fixing it. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: procfs info.
You wrote: I need to know the exact format of the /proc/*/cmdline of FreeBSD. Actually I'm using 4.1 and I have discovered that at the end of cmdline file there are always 2 NULL characters. I'm not seeing that on my 4.x-stable system from about a month ago: Sorry, I just found a bug in the code. :( -- Bye, Mirko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: procfs info.
On Fri, Sep 29, 2000 at 08:49:06PM +, [EMAIL PROTECTED] wrote: You wrote: I need to know the exact format of the /proc/*/cmdline of FreeBSD. Actually I'm using 4.1 and I have discovered that at the end of cmdline file there are always 2 NULL characters. I'm not seeing that on my 4.x-stable system from about a month ago: Hmm, but look at this: [panic:/root]# uname -a FreeBSD panic.localdomain 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Sep 16 16:24:39 PDT 2000 [EMAIL PROTECTED]:/usr/obj/usr/local/cvs up/current/src/sys/PANIC i386 [panic:/root]# hd /proc/0/cmdline 73 77 61 70 70 65 72 00 00 00 00 00 00 00 00 00 |swapper.| 0010 [panic:/root]# hd /proc/10/cmdline 69 64 6c 65 00 65 72 00 00 00 00 00 00 00 00 00 |idle.er.| 0010 [panic:/root]# hd /proc/11/cmdline 73 6f 66 74 69 6e 74 65 72 72 75 70 74 00 00 00 |softinterrupt...| 0010 [panic:/root]# hd /proc/12/cmdline 69 72 71 31 34 3a 20 61 74 61 30 00 00 00 00 00 |irq14: ata0.| 0010 [panic:/root]# hd /proc/13/cmdline 69 72 71 31 35 3a 20 61 74 61 31 00 00 00 00 00 |irq15: ata1.| 0010 [panic:/root]# hd /proc/14/cmdline 69 72 71 31 31 3a 20 75 68 63 69 30 2b 00 00 00 |irq11: uhci0+...| 0010 [panic:/root]# hd /proc/15/cmdline 69 72 71 36 3a 20 66 64 63 30 00 00 00 00 00 00 |irq6: fdc0..| 0010 [panic:/root]# hd /proc/16/cmdline 69 72 71 31 3a 20 61 74 6b 62 64 30 00 00 00 00 |irq1: atkbd0| 0010 There seem to be lots of nulls at the end of the names of kernel threads (padding their names to 16 bytes). Not that it matters, but it's strange. -brian -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: interesting problem
On Thu, Sep 28, 2000 at 21:45 -0500, Tony Johnson wrote: Since I am complaining then I need to figure out what U have done to make 5.0-CURRENT crash?? Well atleast U admit that U do not know and U do not care. So anyone who is using FreeBSD should also not care?? This is more screwed up then I thought and people @FreeBSD have made this much harder then necessary. irony mode on It seems you finally got it. Somebody thought about "what can I do to break _his_ system? I have some spare time and I feel bored ...". irony mode off But it could be just as well the way the handbook told you: -CURRENT is the place where development takes place. Using -CURRENT you're supposed to know what you do and how to help yourself. What the participants in the past thread wanted you to do is to provide some more info to make them able to help you better. Claiming "you broke it somewhere - guess where - , fix it or I'll leave" will make you get answers like "feel free to choose the second". Chances are that the "broken code" works for other people. Only you and nobody else can provide the info what exactly breaks things for _you_ -- nobody else has the system to repeat and explore it. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
I'd like to move and rename them as I said in my previous mail, sys/acpi.h - sys/dev/acpi/acpi.h shared by both kernel and userland programs sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h shared within kernel code (acpi stuff and related drivers) IMHO, it's desirable to use the name "acpi.h", because of conflict with the file dumped by /usr/sbin/config. I love : fooreg.h : device dependent and implementation independent structures, macros, and others. foovar.h : implementation dependent ones. Thanks Shiozaki-san, I think `reg' is short for registers of the target chip, correct? In ACPI's case, PM1 register and some such and maybe definitions for ACPI tables. How about kernel/userland shareable stuff like ioctl? for example, usb(4) has this kind of definitions in dev/usb/usb.h, not in usbreg.h. Is this a special case violating the guideline? I think we can distinguish them like "usb.h" and dev/usb/usb.h, also we will stop generating acpi.h in kernel build directory. Typically you would have: acpivar.h Data structures defined by implementation acpireg.h Data structures defined by interface acpiio.hInterface to userland Since we're all in agreement, I'll move to these. -- ... 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: ACPI megapatch
Thanks a lot mike, these are mostly acceptable for me. - Made all the I/O spaces use proper bus resources - Allocate the resources in machine-dependant code I prefer previous patch because most of the code in i386/acpi_machdep.c can be shared with IA64 I think. I'm not so sure about that. I suspect that the IA64 code is going to be using the 'generic address' structures and the x-fields in eg. the FACT. It won't be using the bios signature search either, or the int15 interface. Realistically, the code in acpi_machdep.c is very simple.a I also think that if I'm going to continue to use a private identify method to attach ACPI (IMO a good idea) then I want to keep its implementation as separate from the 'generic' ACPI code as possible. The pmap interface and one checksum routine is all that the current division uses, and that's fairly clean. - Create a machine-dependant "acpiprobe" device which just knows how to find and set up ACPI for the machine-independant code I think only machine-dependant sub-routines should be in acpi_machdep.c, the rest common code should be moved back to dev/acpi/acpi.c. The first half of acpiprobe_identify() is trying to find rsdp, so renaming it to acpi_find_rsdp() (returns struct ACPIrsdp * or NULL), moving the rest of acpiprobe_identify() to dev/acpi/acpi.c:acpi_identify() and calling acpi_find_rsdp() from acpi_identify() would be better for me. acpiprobe_mapmem() seems machine-dependant, so just renaming (acpi_mapmem() ?) would be enough. acpiprobe_facp(), I think, is MI, should be moved dev/acpi/acpi.c and renamed (acpi_find_facp() ?). That would be possible, but as I mentioned above, adding support for the generic-address formats is going to make things *very* messy. I get a strong feeling that whoever was responsible for making sure that ACPI stayed sensible has quit or been fired. There are a lot of recent changes that are just plain *stupid*. -- ... 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: ACPI megapatch
And probe method and identify method should not be confused. Memory area check etc can be in MD acpi probe code. Can you explain what you mean here a bit more? The FACT lookup and resource establishment need to be done in the identify routine, not the probe routine... -- ... 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: ACPI megapatch
Hi, I prefer previous patch because most of the code in i386/acpi_machdep.c can be shared with IA64 I think. I'm not so sure about that. I suspect that the IA64 code is going to be using the 'generic address' structures and the x-fields in eg. the FACT. It won't be using the bios signature search either, or the int15 interface. Realistically, the code in acpi_machdep.c is very simple.a I also think that if I'm going to continue to use a private identify method to attach ACPI (IMO a good idea) then I want to keep its implementation as separate from the 'generic' ACPI code as possible. The pmap interface and one checksum routine is all that the current division uses, and that's fairly clean. OK, understood. How about having MD sub-routine in the same interface (say acpi_set_resources() or acpi_create_instance() or whatever) for i386 and ia64? Then generic ACPI identify method calls suitable sub-routine depending on machine architecture. - i386/i386/acpi_machdep.c acpi_set_resources() (ex-acpiprobe_identify()) - ia64/ia64/acpi_machdep.c acpi_set_resources() - dev/acpi/acpi.c acpi_identify() this is quite simple, just do simple error checking and call acpi_set_resources() then return. Is this good for you too? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
OK, understood. How about having MD sub-routine in the same interface (say acpi_set_resources() or acpi_create_instance() or whatever) for i386 and ia64? Then generic ACPI identify method calls suitable sub-routine depending on machine architecture. - i386/i386/acpi_machdep.c acpi_set_resources() (ex-acpiprobe_identify()) - ia64/ia64/acpi_machdep.c acpi_set_resources() - dev/acpi/acpi.c acpi_identify() this is quite simple, just do simple error checking and call acpi_set_resources() then return. Is this good for you too? It's closer. I just realised that we need a way of creating resources for SystemIO and SystemMemory AML objects as well. I think I've worked this out too; I'll try to get it worked out today and send you a patch this evening. I'm following your request to get the bus-dependant parts split out, but I do *not* think that we should be committing any of the NetBSD code to the FreeBSD source tree (this has been a failure in the past), or vice versa. Meanwhile, my laptop is getting very hot. 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
Re: Repeated panic out of chgsbsize
On Sep 29, 11:30am, Greg Lehey wrote: } Subject: Repeated panic out of chgsbsize } In the past couple of days, I've had a couple of panics out of chgsbsize: } } (kgdb) bt [ snip ] } #12 0xc01cbac9 in panic (fmt=0xc0356920 "reducing sbsize: lost count, uid = %d") at ../../kern/kern_shutdown.c:553 } #13 0xc01c8d7b in chgsbsize (uid=50, diff=-17520, max=9223372036854775807) at ../../kern/kern_proc.c:206 } #14 0xc01ee6aa in sbrelease (sb=0xcdc091f4, so=0xcdc09180) at ../../kern/uipc_socket2.c:453 } #15 0xc01eb9fb in sofree (so=0xcdc09180) at ../../kern/uipc_socket.c:261 } #16 0xc0221e0b in in_pcbdetach (inp=0xce1c3aa0) at ../../netinet/in_pcb.c:542 } #17 0xc022c462 in tcp_close (tp=0xce1c3b60) at ../../netinet/tcp_subr.c:711 } #18 0xc0229bf6 in tcp_input (m=0xc0e96500, off0=20, proto=6) at ../../netinet/tcp_input.c:2012 } #19 0xc02247ee in ip_input (m=0xc0e96500) at ../../netinet/ip_input.c:756 } #20 0xc022484b in ipintr () at ../../netinet/ip_input.c:784 } #21 0xc0309195 in swi_net_next () That version of the per-uid accounting implementation has some race conditions between the kernel top and bottom halves. I'd recommend upgrading to PRE_SMPNG. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fwd: [cvs commit: src/lib/libc/net hesiod.c]
If you have machines running -CURRENT from September 9 - September 29, _and_ you created an /etc/nsswitch.conf with any of `passwd: dns', `group: dns', `passwd_compat: dns', `group_compat: dns', then you are vulnerable to a local attack. So upgrade :-) (or just apply the small patch) -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] - Forwarded message from Jacques Vidrine [EMAIL PROTECTED] - Date: Fri, 29 Sep 2000 05:56:34 -0700 (PDT) From: Jacques Vidrine [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/lib/libc/net hesiod.c nectar 2000/09/29 05:56:34 PDT Modified files: lib/libc/net hesiod.c Log: Ignore HESIOD_CONFIG and HES_DOMAIN environmental variables for set-user-ID and set-group-ID programs. Suggested by: Danny Braniss [EMAIL PROTECTED] Revision ChangesPath 1.2 +13 -3 src/lib/libc/net/hesiod.c - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPX requires 'device random'
On Fri, 29 Sep 2000, Kevin M. Dulzo wrote: I am not aware of the full status of IPX networking support in -current, but I migrated my -stable kernel config as best I could. Kernel compilation completes, but linking fails due to a rand_ function not being present ( I do not have the exact error handy, but can generate for anyone who wants it.) A simple 'device random' to compile the support in statically rectifies the problem. Yes, 'device random' is required for now. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI megapatch
Ok. Based on all the suggestions, received today, and some more ideas besides, here's the latest megapatch. - Move all register I/O into a new file - Move event handling into a new file - Move headers to acpivar/acpireg/acpiio - Move find-RSDT and find-ACPI-owened-memory into acpi_machdep - Allocate all resources (except OperationRegions in AML) using real resources. AML fix will now be easy though. - Remove all ACPI #ifdefs - Minor style and commenting fixes - Removed unnecessary #includes Please test this; there are lots of opportunities for error in these changes. In particular, I am afraid that I may have broken I/O from AML bytecode. Hopefully with this committed I can finally get to work on the thermal management. 8) acpi.diff.gz ... 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
Re: ACPI megapatch
As Iwasaki-san pointed out, I left acpi_event.c out of the previous megapatch. Rather than resend the entire thing, you can fetch the complete patch from: http://people.freebsd.org/~msmith/acpi-2929.diff.gz Regards, -- ... 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
