Re: SCSI tape minor device numbers
Can anyone interpret this for me: HARDWARE FAILURE asc:0,4 What does it mean? It this just the numeric code for ``Buy another tape drive''? :-) Yes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ATAPI tape drive (wst0) problem.
Hello, I've got some problem and I need your help to solve it. uname -mrs FreeBSD 3.3-STABLE i386 dmesg output: wdc1: unit 1 (atapi): SuperStation-Int/1.06, removable, accel, iordy I've added such strings to kernel configuration file: options ATAPI device wst0 Of course, I did: cd /dev ./MAKEDEV wst0 ls -al /dev/rwst0 crw-r- 1 root operator 90, 0 Dec 12 12:05 /dev/rwst0 When I'm trying to do: mt -f /dev/rwst0 status I'm getting: mt: /dev/rwst0: Device not configured and Dec 12 12:27:20 zzz-oz /kernel: ENXIO lun=0, wstnlun=0, im=0xc01d0b34 Please, be so kind to let me know where is my mistake and what I'm doing incorrect. `man wst` didn't help, - besides, it refers to wst(1) but I was failed to find such. Thank you very much and looking forward your help. -- Alexander Prohorenko ([EMAIL PROTECTED]) ..."Death is God's way of telling you not to be such a wise guy." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
timezone var vs timezone() function
On my FreeBSD 3.3R system, /usr/include/time.h includes a prototype for the timezone() function. The timezone(3) manual page indicates that this function is for compatibility purposes only and notes that the timezone() function first appeared in ATT Unix V7. Version 2 of the Single Unix Specification (www.opengroup.org) states that time.h defines a global variable named timezone which indicates the difference in seconds between the local timezone and UTC. It also notes that this is, "Derived from Issue 1 of the SVID." I don't know what that means. I realize that I can work around this in an application a number of ways. For example, use FreeBSD's tm_gmtoff member of struct tm. However, is it a long-term goal for FreeBSD to conform to the Single Unix Specification? Charles To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATAPI tape drive (wst0) problem.
It seems Alexander Prohorenko wrote: Hello, I've got some problem and I need your help to solve it. uname -mrs FreeBSD 3.3-STABLE i386 dmesg output: wdc1: unit 1 (atapi): SuperStation-Int/1.06, removable, accel, iordy Hmm, I've gotten a failure report on one of these before, I'm afraid we dont have support for this drive, it seems as if Sony didn't follow the ATAPI spec on the model (same goes for Onstream btw). Until I get some docs out of Sony, or a drive to experiment with, there really isn't much I can do... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ATAPI tape support - how to format?
Hi folks, Well, I'm in for it now ;-) I'm going to have to start supporting ATAPI tape drives on FreeBSD for some business associates - they're too cheap to go SCSI. Some of these (if not all) require formatting, right? This leads to the obvious question: How do you format a tape for these drives under FreeBSD? :-) Anything else I should know offhand other than "plug it in and use dump like everything else"? -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATAPI tape drive (wst0) problem.
Alexander Prohorenko wrote, Hello, I've got some problem and I need your help to solve it. uname -mrs FreeBSD 3.3-STABLE i386 dmesg output: wdc1: unit 1 (atapi): SuperStation-Int/1.06, removable, accel, iordy I've added such strings to kernel configuration file: options ATAPI device wst0 And you did rebuild the kernel and reboot right? The dmesg output should contain references to this device, wst0, besides just the fact wcd1 found _something,_ no? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: silo overflows
what kind of disk to you have? and the chipset? (this may seem irrelevant but misconfigured DMA devices can block the cpu for long enough to cause this sort of thing in some cases). ALSO check systat -vmstat while this is happenning and check that you don't have a source of spurious interrupts. Julian On Sun, 12 Dec 1999, Egervary Gergely wrote: hy, i still can't get rid of silo overflows :( 3.3-STABLE, a simple pentium2 system w/ external 33.6 rockwell modem attached to sio0. i see nothing special. and the overflows just still come :( what should i check/ look after? --mauzi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: silo overflows
what kind of disk to you have? and the chipset? (this may seem irrelevant but misconfigured DMA devices can block the cpu for long enough to cause this sort of thing in some cases). ALSO check systat -vmstat while this is happenning and check that you don't have a source of spurious interrupts. Julian intel 440bx chipset (abit-bh6 mainboard) quantum cx13.0a ata4 disk actually i don't see any spurious interrupts :) anyway... the raw disk read access speed (not fs!) is about 3MB/sec this disk reads more than 10MB/secs with other OS'es... any ideas? -- mauzi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Reminder - changes to sources and such
Hi folks, Just something to keep in mind I am trying to update from a Juneish -CURRENT to a current -CURRENT. I've run into two instances (the latest being the use of "colldef" in /usr/src/share/colldef) where older binaries are INCOMPATIBLE with the newer files they are processing, AND the "make buildworld" target uses the OLD binary in an attempt to read the NEW file. This blows up, obviously. Isn't this a dependancy that should be caught? More specifically, shouldn't the "buildworld" target build /usr/src/usr.bin, bin, sbin, etc FIRST - and THEN rebuild things in share USING THE OBJECTS IT JUST BUILT? I've run into this before with the control files for make in /usr/share/mk being read for a "buildworld", and if they are far enough out of date you get screwed by them - but this is the first time I've seen it with general utilities and share directory where things have to be run through a table processor. Having been bit twice now in my most recent attempt to update by this, I thought I'd post here and see if this is expected behavior or not, and if I'm missing something in the "correct" steps to take to run a buildworld. I would *expect* that in general I should be able to rm -rf /usr/src and /usr/obj, "cvs co src" from the /usr directory, cd into there, and type "make buildworld" and have it complete with *NO* outside dependancies except what is necessary to bootstrap the compiler initially (that is, a working compiler to build the compiler with.) If I can't do this then updating a system in the general case to the current software simply isn't possible without manual intervention. Am I missing something here? -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reminder - changes to sources and such
Karl Denninger wrote: Hi folks, Just something to keep in mind I am trying to update from a Juneish -CURRENT to a current -CURRENT. I've run into two instances (the latest being the use of "colldef" in /usr/src/share/colldef) where older binaries are INCOMPATIBLE with the newer files they are processing, AND the "make buildworld" target uses the OLD binary in an attempt to read the NEW file. This blows up, obviously. This would appear to be another thing Marcel has broken.. colldef used to have special treatment, but it no longer has. peter@overcee[5:29am]~src-124 cvs up -p -r1.89 Makefile.inc1 | grep colldef usr.bin/colldef \ peter@overcee[5:29am]~src-125 grep colldef Makefile.inc1 peter@overcee[5:29am]~src-126 Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reminder - changes to sources and such
On Mon, Dec 13, 1999 at 05:31:17AM +0800, Peter Wemm wrote: Karl Denninger wrote: Hi folks, Just something to keep in mind I am trying to update from a Juneish -CURRENT to a current -CURRENT. I've run into two instances (the latest being the use of "colldef" in /usr/src/share/colldef) where older binaries are INCOMPATIBLE with the newer files they are processing, AND the "make buildworld" target uses the OLD binary in an attempt to read the NEW file. This blows up, obviously. This would appear to be another thing Marcel has broken.. colldef used to have special treatment, but it no longer has. peter@overcee[5:29am]~src-124 cvs up -p -r1.89 Makefile.inc1 | grep colldef usr.bin/colldef \ peter@overcee[5:29am]~src-125 grep colldef Makefile.inc1 peter@overcee[5:29am]~src-126 Cheers, -Peter Thanks Peter. This kind of thing is an issue that is very real; I've run into it before, and for a while I had trouble with this kind of thing when I was at MCS (usually the problem there was in the /usr/share/mk directory, but the same principle applies) Can I ask why the makefiles for the world don't build in this order? 1. Build the "basic" GNU kit necessary to compile things. 2. Build the LIBRARIES necessary to LINK things. 3. Rebuild the gnu kid using (2); you now have a self-consistent development system regardless of what you started with. 4. Build the world's binaries. 5. Process anything in /usr/share or other places that requires the use of those binaries, using the OBJECTS compiled in step (4). This way all you need to build the world is a compiler that kinda works. If include files have changed, or binaries that read files have changed, it doesn't matter and won't bite you. As long as you can get executable code in step (1) the build will complete AND the completed build will be up to date using the current headers and libraries. (I may be missing a step or two here but I think the question I'm asking is fairly clear) :-) Special-casing things like this looks rather evil to me; shouldn't we fix the general case instead? -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reminder - changes to sources and such
Karl Denninger wrote: Can I ask why the makefiles for the world don't build in this order? 1. Build the "basic" GNU kit necessary to compile things. 2. Build the LIBRARIES necessary to LINK things. 3. Rebuild the gnu kid using (2); you now have a self-consistent development system regardless of what you started with. This won't work in all cases, because the libraries don't always match the kernel. You need to build your tools against the includes and libraries that correspond to the machine your building on. 4. Build the world's binaries. 5. Process anything in /usr/share or other places that requires the use of those binaries, using the OBJECTS compiled in step (4). This won't work if you're cross-building. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: silo overflows
On Sun, 12 Dec 1999, Gergely EGERVARY wrote: what kind of disk to you have? and the chipset? (this may seem irrelevant but misconfigured DMA devices can block the cpu for long enough to cause this sort of thing in some cases). ALSO check systat -vmstat while this is happenning and check that you don't have a source of spurious interrupts. Julian intel 440bx chipset (abit-bh6 mainboard) quantum cx13.0a ata4 disk actually i don't see any spurious interrupts :) (that had happenned to me) If you can get the disk working right it may even solve the silo problem. (it did for me) It turned out that the disk system was blocking the PCI bus during DMA Julian anyway... the raw disk read access speed (not fs!) is about 3MB/sec this disk reads more than 10MB/secs with other OS'es... Do you have UDMA turned on? any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: timezone var vs timezone() function
On Sun, Dec 12, 1999 at 12:40:06PM -0700, Charles Randall wrote: On my FreeBSD 3.3R system, /usr/include/time.h includes a prototype for the timezone() function. The timezone(3) manual page indicates that this function is for compatibility purposes only and notes that the timezone() function first appeared in ATT Unix V7. Version 2 of the Single Unix Specification (www.opengroup.org) states that time.h defines a global variable named timezone which indicates the difference in seconds between the local timezone and UTC. It also notes that this is, "Derived from Issue 1 of the SVID." I don't know what that means. SVID == System V Interface Definition. -- Wilko Bulte Arnhem, The Netherlands - The FreeBSD Project WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: silo overflows
Julian Elischer wrote: On Sun, 12 Dec 1999, Gergely EGERVARY wrote: what kind of disk to you have? and the chipset? (this may seem irrelevant but misconfigured DMA devices can block the cpu for long enough to cause this sort of thing in some cases). ALSO check systat -vmstat while this is happenning and check that you don't have a source of spurious interrupts. Julian intel 440bx chipset (abit-bh6 mainboard) quantum cx13.0a ata4 disk actually i don't see any spurious interrupts :) (that had happenned to me) If you can get the disk working right it may even solve the silo problem. (it did for me) It turned out that the disk system was blocking the PCI bus during DMA Julian For what it's worth, your problem is a wdc driver and/or a configuration problem. outback# dd if=/dev/ad0s1b of=/dev/null bs=256k count=512 512+0 records in 512+0 records out 134217728 bytes transferred in 6.868476 secs (19541122 bytes/sec) That's a 440bx and a quantum cx drive (slightly smaller, 10MB), but under -current. You have remembered to set flags 0xa0ffa0ff on the wdc controller right? Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: timezone var vs timezone() function
From: Wilko Bulte [mailto:[EMAIL PROTECTED]] Charles Randall wrote: ... It also notes that this is, "Derived from Issue 1 of the SVID." SVID == System V Interface Definition. Interesting, my Solaris 2.6 box defines timezone as the global variable (in accordance with the Single Unix Spec). See the tzset() manpage for their description. Charles To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vi screws up relative tag paths (with patch).
Submitter-Id: current-users
Originator: Frank Mayhar
Organization: Subversive Atheists -R- Us
Confidential: no
Synopsis: The name of the tagfile is left in the path.
Severity: serious
Priority: high
Category: bin
Release:FreeBSD 3.4-RC i386
Class: sw-bug
Environment:
3.4-RC, 4.0-current, etc.
Description:
The routine ctag_file(), when constructing the path to the file from
a relative path in the tagfile, leaves the name of the tagfile in the
path.
How-To-Repeat:
Create a tagfile with relative entries, go to a different directory,
and do a "vi -t existing tag".
Fix:
Index: ex_tag.c
===
RCS file: /cvs/repos/src/contrib/nvi/ex/ex_tag.c,v
retrieving revision 1.2
diff -c -r1.2 ex_tag.c
*** ex_tag.c1997/04/18 23:36:43 1.2
--- ex_tag.c1999/06/25 20:59:29
***
*** 1339,1349
stat(name, sb) (p = strrchr(tfp-name, '/')) != NULL) {
*p = '\0';
len = snprintf(buf, sizeof(buf), "%s/%s", tfp-name, name);
- *p = '/';
if (stat(buf, sb) == 0) {
*dirp = tfp-name;
*dlenp = strlen(*dirp);
}
}
}
--- 1339,1349
stat(name, sb) (p = strrchr(tfp-name, '/')) != NULL) {
*p = '\0';
len = snprintf(buf, sizeof(buf), "%s/%s", tfp-name, name);
if (stat(buf, sb) == 0) {
*dirp = tfp-name;
*dlenp = strlen(*dirp);
}
+ *p = '/';
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Developer's Interface Guide for IA-64 Servers (DIG64) Adopter
Attention, all FreeBSD, OpenBSD and NetBSD developers.. This is a chance we cannot ignore.. Please form up a development team with a central tram leader and get signed up for this offer. The Documentation personnel should sign up for the Contributors link to add BSD's voice in setting the guidelines for future BSD development for all three forms... Please read below.. (also, team leaders, send me a e-mail when you sign-up to keep me informed as to the process and to get an idea on how many teams there is involved) About the DIG64 Leading hardware and software vendors have formed an industry group to develop the DIG64 guidelines. These guidelines establish basic system building blocks, interfaces, and programming conventions for upcoming IA-64 based servers and their system-level software in order to define hardware and software compatibility and interoperability. DIG64 is... an industry-driven set of technical guidelines that define hardware, firmware and operating system's compatibility for IA-64 servers providing IT with systems built on common, stabilized interfaces that improve reliability and interoperability, lower qualification and support costs developed and backed by the key IA-64 OEMs, OSVs, and BIOS vendors who are contributing to its development and are building compliant products allowing the industry to accelerate the pace of IA-64 technology adoption By defining common building blocks and interfaces and proactively addressing legacy issues, the DIG64 provides an array of benefits for both developers and IT organizations. For developers, the DIG64: Increases the efficiency of the design process, freeing developers to focus design resources of features that add unique value and differentiate their products in the marketplace. Gives firmware and OS vendors a known set of interfaces to build to, enabling them to confidentially develop their products concurrently with the hardware and shrink time to markets. Provides a technology migration roadmap that extends the planning horizon for developers and allows them to create designs with increased longevity. For business users and Information Technology (IT) departments: Standard interfaces and interoperable layers enhance the reliability and robustness of the resulting servers as well as lowering qualification costs. Since developers find it easier to build components that work together, customers can enjoy a greater choice of robust, innovative server solutions. Because the DIG64 addresses the migration of support-intensive, obsolete technologies to newer, more robust choices, IT departments can control or reduce the cost of server support. DIG64 Defined The DIG64 specification defines basic system building blocks, interfaces and programming conventions between IA-64 based servers and system-level software such as the operating system and device drivers. The specification covers: Core system components such as the processor, chipset, memory, I/O bus, and server management hardware. Interfaces to peripheral devices for networking, communications and storage. Low-level firmware interfaces to the operating system for system configuration, boot and runtime services. The guide does not create new standards and interfaces, but selects components and interfaces from already existing technologies. To ensure interoperability, the DIG64 also specifies implementation requirements for each specification or standard. The DIG64 spells out a roadmap for eliminating obsolete technologies. Release 1.0, which is currently available http://www.dig64.org/download1.htm, pertains to servers based on the Intel® Itanium processor. Subsequent versions will address future processors as they are developed. A three-level hierarchy of required, recommended and optional features enables vendors to choose how quickly they want to remove older technologies. The DIG64 is operating-system independent, promoting cross-platform interoperability among servers running Windows 2000*, Linux and other UNIX* operating systems. Join Other Industry Leaders Already Building Compatible IA-64 Server Solutions! There is still time to get involved by becoming a DIG64 Adopter member. To find out more about the advantages of becoming a DIG64 Adopter, take look at the DIG64 www site http://www.dig64.org/ To sign up as a Developer's Interface Guide for IA-64 Servers (DIG64) Adopter, complete all of the information at the link listed below and hit the submit button. You will then be able to download a "DIG64 Adopters Agreement". http://www.dig64.org/signup.htm By becoming a DIG64 Contributor, you will be able to provide technical input into the development of the DIG64 guidelines in addition to gaining access to the latest published draft. All input will be reviewed by the
patches to always have getfh as syscall
Hi, in PR kern/15452 I have sent in patches to make getfh always be in the system call table. Details are also included in the PR. Any thoughts/comments/flames? /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
technical info needed
-BEGIN PGP SIGNED MESSAGE- Dear hackers, How can I find how often is particular routine (say wdintr()) called. Is it called once an year or 50 times a second ? Is there a way how can I determine it by myself ? Regards, (îÁÉÌÕÞÛÉÅ ÐÏÖÅÌÁÎÉÑ) Ilia Chipitsine (éÌØÑ ûÉÐÉÃÉÎ) -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQB1AwUBOFR+zuRxlWKN2EXhAQGiCgL/eVeEiTu9iEZPGWzIEyaucA4+PZq6anW4 g9jqKehLKG0apK613kl92uiuS5XnyddKrCoOya1blBe9ywJDR3Pl3Wrhr+fMBxUT DyQ35FPk5wIEWKbCw9vkt6NFvN36DY5t =k66v -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: technical info needed
On Mon, Dec 13, 1999, Ilia Chipitsine wrote:
Is it called once an year or 50 times a second ?
Is there a way how can I determine it by myself ?
Add a statement like
printf("somefunc() being called!\n");
to the top of the function you want to 'measure'.
--
|Chris Costello [EMAIL PROTECTED]
|Nobody has ever, ever, EVER learned all of WordPerfect.
`---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: technical info needed
It seems like using gprof would be a little bit more useful than
potentially having something print to the screen 50k times. I guess printf
would be fine if you only care if something is called a lot or not at all.
-Kip
On Mon, 13 Dec 1999, Chris Costello wrote:
On Mon, Dec 13, 1999, Ilia Chipitsine wrote:
Is it called once an year or 50 times a second ?
Is there a way how can I determine it by myself ?
Add a statement like
printf("somefunc() being called!\n");
to the top of the function you want to 'measure'.
--
|Chris Costello [EMAIL PROTECTED]
|Nobody has ever, ever, EVER learned all of WordPerfect.
`---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: technical info needed
You can compile the kernel with -p -g and use the profiling.
On Mon, 13 Dec 1999, Chris Costello wrote:
On Mon, Dec 13, 1999, Ilia Chipitsine wrote:
Is it called once an year or 50 times a second ?
Is there a way how can I determine it by myself ?
Add a statement like
printf("somefunc() being called!\n");
to the top of the function you want to 'measure'.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: technical info needed
On Sun, 12 Dec 1999, Julian Elischer wrote:
On Mon, 13 Dec 1999, Chris Costello wrote:
On Mon, Dec 13, 1999, Ilia Chipitsine wrote:
Is it called once an year or 50 times a second ?
Is there a way how can I determine it by myself ?
Add a statement like
printf("somefunc() being called!\n");
to the top of the function you want to 'measure'.
You can compile the kernel with -p -g and use the profiling.
Julian's way is the best however a quick 'n dirty would be just
to create a sysctl node for your counter, useful if you only have
a couple of things you want to track.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ATAPI tape support - how to format?
It seems Karl Denninger wrote: Hi folks, Well, I'm in for it now ;-) I'm going to have to start supporting ATAPI tape drives on FreeBSD for some business associates - they're too cheap to go SCSI. Some of these (if not all) require formatting, right? This leads to the obvious question: How do you format a tape for these drives under FreeBSD? :-) You dont, they "just works" out of the box. Anything else I should know offhand other than "plug it in and use dump like everything else"? Not really... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
2questions
Hi all, I have posted this email for [EMAIL PROTECTED] but I didn't got any answer. I am running FreeBSD 3.3 Release on one laptop Toshiba and as XServer the Accelerated X 5.0.2. I am curious about one fact. Everytime when I exit from XServer I 've got: pid 8971 (Xaccel): trap 12 with interrupts disabled What it is about ? Anyway on AccelX box it is said that FreeBSD OS is supported but only inside in box I have found that only 2.x are supported, according with members of FreeBSD project. Why ? Why not 3.x? On the other hand using FreeBSD 3.3 on another box (Compaq Desktop, AMD K6-333, 80MBRAM; 4GB, Voodoo3 PCI 2000) I ran top and the SIZE of XF86_SVGA goes to 54MB and RSIZE the same. Why ? Thanks, Stef To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: loader hacks (was: Re: easyboot far into disk)
I thought rootdev was fixed a long time back. If it's not, please tell me and I'll fix it again. 8) Alright I finally got around testing this with a later kern.flp (3.3-R actually), and it still didn't work. ... Well i played with this once more yesterday and now i know what was wrong: Unlike currdev, rootdev needs a `:' at the end... So either I'm blind or the manpage needs fixing. :) The manpage is probably wrong. $rootdev is obsolete and will be removed for 4.x (if I remember). I also actually started making that FAQ entry (yeah!), and then wondered if you could also make an automagic boot floppy for a root disk that is entirely invisible to the BIOS, like when its on a BIOS-less (but otherwise supported) SCSI controller. I didn't find a way to do it with the original (-stable) loader, but when i made this patch, 4.x does this differently (better) by passing in a complete identifier. I need to update the online help and manpage for it. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
loader hacks (was: Re: easyboot far into disk)
(Cc'd to -hackers because, well, it contains hacks...)
On Thu, Nov 11, 1999 at 10:47:30PM +0100, nox wrote:
On Sun, Nov 07, 1999 at 11:57:26AM -0800, Mike Smith wrote:
Rootdev ought to work, actually. But if you get it wrong, the loader
will fall back to using currdev.
Hmm then thats strange. I first tried rootdev, which didn't work, and
then later currdev, which did work, and i believe i used the same value
both times! Or was rootdev fixed only recently, the boot floppies i
had lying around and tested this on weren't the latest...
I thought rootdev was fixed a long time back. If it's not, please tell
me and I'll fix it again. 8)
Alright I finally got around testing this with a later kern.flp
(3.3-R actually), and it still didn't work. ...
Well i played with this once more yesterday and now i know what was
wrong: Unlike currdev, rootdev needs a `:' at the end... So either
I'm blind or the manpage needs fixing. :)
I also actually started making that FAQ entry (yeah!), and then
wondered if you could also make an automagic boot floppy for a root
disk that is entirely invisible to the BIOS, like when its on a
BIOS-less (but otherwise supported) SCSI controller. I didn't find
a way to do it with the original (-stable) loader, but when i made
this patch,
Index: biosdisk.c
===
RCS file: /home/cvs/cvs/src/sys/boot/i386/libi386/biosdisk.c,v
retrieving revision 1.20.2.7
diff -u -u -r1.20.2.7 biosdisk.c
--- biosdisk.c 1999/08/29 16:20:59 1.20.2.7
+++ biosdisk.c 1999/12/12 00:14:52
@@ -785,23 +785,45 @@
int
bd_getdev(struct i386_devdesc *dev)
{
-struct open_disk *od;
+struct open_disk *od = NULL;
intbiosdev;
intmajor;
introotdev;
char *nip, *cp;
intunitofs = 0, i, unit;
+/* XXX kludge to allow the type of the root disk to be specified */
+cp = getenv("root_disk_type");
biosdev = bd_unit2bios(dev-d_kind.biosdisk.unit);
DEBUG("unit %d BIOS device %d", dev-d_kind.biosdisk.unit, biosdev);
-if (biosdev == -1) /* not a BIOS device */
+if (biosdev == -1) { /* not a BIOS device */
+ int lastbiosdev;
+ /*
+* BIOS doesn't know about this disk, this is not an error
+* when root_disk_type is set unless the number is
+* completely bogus
+* (set root_disk_type=da and you may e.g. have the root
+* disk hanging off a BIOS-less SCSI controller...)
+*/
+ if (!cp || dev-d_kind.biosdisk.unit 0 ||
+ dev-d_kind.biosdisk.unit = 256)
+ return(-1);
+ /*
+* numbering of unknown-to-BIOS units starts with the first
+* hard disk above the last one the BIOS saw, this is 0x80
+* if the BIOS only saw floppies
+*/
+ lastbiosdev = bd_unit2bios(nbdinfo - 1);
+ biosdev = dev-d_kind.biosdisk.unit - nbdinfo +
+ (lastbiosdev 0x80 ? 0x80 : lastbiosdev + 1);
+} else if (bd_opendisk(od, dev) != 0) /* oops, not a viable device */
return(-1);
-if (bd_opendisk(od, dev) != 0)/* oops, not a viable device */
- return(-1);
-if (biosdev 0x80) {
+/* only assume floppy if root_disk_type is not set or is *fd* */
+if ((biosdev 0x80 !cp) || strstr(cp, "fd")) {
/* floppy (or emulated floppy) or ATAPI device */
- if (bdinfo[dev-d_kind.biosdisk.unit].bd_type == DT_ATAPI) {
+ if ((cp !strcmp(cp, "wfd")) ||
+ bdinfo[dev-d_kind.biosdisk.unit].bd_type == DT_ATAPI) {
/* is an ATAPI disk */
major = WFDMAJOR;
} else {
@@ -810,8 +832,10 @@
}
} else {
/* harddisk */
- if ((od-od_flags BD_LABELOK) (od-od_disklabel.d_type == DTYPE_SCSI)) {
- /* label OK, disk labelled as SCSI */
+ if ((cp !strcmp(cp, "da")) ||
+ (od (od-od_flags BD_LABELOK)
+(od-od_disklabel.d_type == DTYPE_SCSI))) {
+ /* label OK or root_disk_type set, disk labelled as SCSI */
major = DAMAJOR;
/* check for unit number correction hint, now deprecated */
if ((nip = getenv("num_ide_disks")) != NULL) {
@@ -820,23 +844,24 @@
if ((cp != nip) (*cp == 0))
unitofs = i;
}
- } else if ((od-od_flags BD_LABELOK)
- (od-od_disklabel.d_type == DTYPE_DOC2K)) {
+ } else if ((cp !strcmp(cp, "fla")) ||
+ (od (od-od_flags BD_LABELOK)
+(od-od_disklabel.d_type == DTYPE_DOC2K))) {
major = FLAMAJOR;
} else {
/* assume an IDE disk */
major = WDMAJOR;
}
}
+/* allow for #wd compenstation in da case */
+unit = (biosdev
