Re: possible deadlocks?
one more. This falls into the very improbable category. Ordinarily, I don't think this is possible because FreeBSD doesn't support hotplug PCI, so sk attachment can't be raced. However, assuming I had some hot plug sk card, it seems like running ifconfig sk0 at just the wrong point during sk1 attach will deadlock. If it absolutely can not happen (for a reason other than sk is attached before init runs) please explain. sk.c: sk_attach_xmac() SK_LOCK(sc); /* grabs */ ether_ifattach() ifattach() IFNET_WLOCK() /* waits for 2 */ in6_ifattach.c: in6_nigroup_attach() IFNET_RLOCK() /* grabs */ in6_addmulti() if_addmulti() sk_ioctl() SK_IF_LOCK(); /* waits for 1 */ -- First, it was not a strip bar, it was an erotic club. And second, what can I say? I'm a night owl. - M. Barry, Mayor of Washington, DC ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM Gate.
In message [EMAIL PROTECTED], Pawel Jakub Dawidek writes : --Dx9iWuMxHO1cCoFc Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello hackers... I've done something what will be called GEOM Gate. This software provide disk devices mounting through the network. COOL http://garage.freebsd.pl/geom_gate.tbz I'll look over it when I have a second. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Adding device IDs to if_wi?
I bought a Microsoft MN-520 WLAN card (Prism 2 chipset). It works well under Linux, but I want to use it with FreeBSD. The card does not currently exist in the pccarddevs database, so the if_wi drive doesn't recognize it. I've added it with this patch: Index: sys/dev/pccard/pccarddevs === RCS file: /usr/cvs/src/sys/dev/pccard/pccarddevs,v retrieving revision 1.3.2.1 diff -u -u -r1.3.2.1 pccarddevs --- sys/dev/pccard/pccarddevs 23 May 2000 03:57:00 - 1.3.2.1 +++ sys/dev/pccard/pccarddevs 5 Aug 2003 01:49:55 - @@ -68,6 +68,7 @@ vendor IODATA 0x01bf I-O DATA vendor BAY 0x01eb Bay Networks vendor NOKIA 0x023d Nokia Communications +vendor MICROSOFT 0x02d2 Microsoft Corporation vendor LASAT 0x3401 Lasat Communications A/S vendor LEXARMEDIA 0x4e01 Lexar Media vendor COMPEX 0x8a01 Compex Corporation @@ -151,6 +152,9 @@ /* Melco Products */ product MELCO LPC3_TX 0xc1ab Melco LPC3-TX + +/* Microsoft Products */ +product MICROSOFT MN_520 0x0001 Microsoft MN-520 WLAN Card /* Nokia Products */ product NOKIA C020_WLAN0x20c0 Nokia C020 WLAN Card Then, I regenerated the .h files with make -f Makefile.pccarddevs. Finally, I added the card's data to the if_wi driver: Index: sys/dev/wi/if_wi_pccard.c === RCS file: /usr/cvs/src/sys/dev/wi/if_wi_pccard.c,v retrieving revision 1.8.2.2 diff -u -u -r1.8.2.2 if_wi_pccard.c --- sys/dev/wi/if_wi_pccard.c 2 Aug 2002 07:11:34 - 1.8.2.2 +++ sys/dev/wi/if_wi_pccard.c 5 Aug 2003 01:36:10 - @@ -148,6 +148,7 @@ PCMCIA_CARD2(LUCENT, WAVELAN_IEEE, SMC_2632W, 0), /* Must be after other LUCENT ones because it is less specific */ PCMCIA_CARD(LUCENT, WAVELAN_IEEE, 0), + PCMCIA_CARD(MICROSOFT, MN_520, 0), PCMCIA_CARD(NETGEAR2, MA401RA, 0), PCMCIA_CARD(NOKIA, C110_WLAN, 0), PCMCIA_CARD(PROXIM, RANGELANDS_8430, 0), and then recompiled the kernel. Unfortunately, the driver still doesn't seem to attach to the card (when I kldload if_wi.ko from sysinstall's holographic shell, with a floppy with the corrected driver). What else can I do? Is there anything else I should edit? -- Kirk Strauser pgp0.pgp Description: PGP signature
Re: Why is ATAPI DMA disabled by default ?
On Thu, Aug 14, 2003 at 01:45:45AM +0300, Alexander Serkov wrote: I use 5.1-current and have found that by default FreeBSD disables ATAPI's support for DMA transfers and thus uses CPU hungry PIO modes. It even makes sysctl used to change this read-only. I had changed the default value of atapi_dma to 1 in dev/ata/atapi-all.c to 1 and it worked fine for me. Can someone explain why it is disabled? Lots of drives, even fairly new ones be well know vendors, hang the system during boot if ATAPI DMA is enabled because they lie about supporting it. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
GEOM Gate.
Hello hackers... I've done something what will be called GEOM Gate. This software provide disk devices mounting through the network. http://garage.freebsd.pl/geom_gate.tbz Installation is quite trivial: # tar -jvxf geom_gate.tbz # cd geom_gate # make # make install For example we got two machine: 'client' and 'server' and we want to mount device /dev/ad0s1a from 'server' machine on 'client' machine. server# ggd -f /dev/ad0s1a client# kldload geom_gate client# ggc -a -h 'server' -s sizeof(/dev/ad0s1a) -u 5 client# mount /dev/gg5 /mnt/foo And that's all. Of course we can also export files and treat them as devices: server# truncate -s 256M test.img server# ggd -f ./test.img -p 1234 client# ggc -a -h 'server' -p 1234 -s 256M -u 6 client# newfs -O2 -U /dev/gg6 client# mount /dev/gg6 /mnt/bar This isn't finished yet, so it also isn't bugs free. For example don't try to run client and server stuff on this same machine, this could case a deadlock. Comments, etc. are of course welcome. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Missing system call in linux emulation ( patch )
Send a PR. On Thu, 14 Aug 2003, Steven Hartland wrote: I've created a patch for the linux emulation which adds a dummy for the exit_group syscall along with defining all functions up to 252 this fixes a crash in the BattleField 1942 server. How do I go about getting this into the various FreeBSD streams so others can benifit. Steve / K ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM Gate.
BTW, QNX had this for a long time, it's called QNet in there. Allows transparently to mount or use anything in /dev. Even a soundcard! PJD Hello hackers... PJD I've done something what will be called GEOM Gate. PJD This software provide disk devices mounting through the network. PJD http://garage.freebsd.pl/geom_gate.tbz ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
increasing number of buffers in BSD4.4
Hi, In McKusick's book The design and Implementation of the 4.4BSD Operating system, in the Buffer Management subsection of the I/O system overview, there is a a sentence that says ...depending on available memory, a system is configured with from 100 to 1000 buffers.. referring to the number of struct buf* in the integrated VM/IO buffer cache. I have plenty of RAM in my computer, but it seems like there are always 1000 buffers configured (empirical observation, if I try to allocate one more after that the system freezes). How do I increase the nubmer of buffers? More consicely, how do I allocate more memory to the buffer management subsystem? Thanks Eno ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tuning HZ for semi-realtime applications
On Tue, 5 Aug 2003, David Schultz wrote: On Tue, Aug 05, 2003, Roderick van Domburg wrote: There's this Linux kernel patch that allows for timeslice tuning. It's got the following rules of the thumb: * The optimal setting is your CPU's speed in MHz's / 2 * ...but there is no point in going above 1000 Hz * ...and be sure to use multiples of 100 Hz I am everything but an expert at scheduling, but somehow this makes sense: i.e. one jiffy for the scheduler and one jiffy for the process. Does all of this make any sense or is it just a load of hooey? There might be some rationale behind that suggestion, but my first guess would be that someone pulled those numbers out of a hat. In general, doing a context switch has negative cache effects, in addition to the overhead that you pay up front. For optimum throughput, you want to set HZ to the smallest number that still gives acceptable resolution. 100 Hz works just fine for interactive jobs; humans can't tell the difference.[1] For many real-time applications, a higher value is needed. [1] In terms of overhead, I think 100 Hz is well into the noise these days, so bumping that up a little bit would result in negligible difference. I measured 100 vs. 500 a little while ago, and couldn't find a realistic benchmark that was negatively impacted by the higher frequency. I used to run my old Pentium I (200MHz) laptop at 1000Hz without any problems. I ran it this way for years until I retired it a few months ago. I'd support raising our default rate from 100Hz to 1000Hz. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: COW and mprotect on non-shared memory
Luoqi Chen [EMAIL PROTECTED] writes:
[Ed writes]
That means that if I do this:
for (i = 0; i n; ++i) {
assert(!mprotect(p, pgsiz, PROT_NONE));
assert(!mprotect(p, pgsiz, PROT_READ|PROT_WRITE|PROT_EXEC));
p[i] = i 0xff;
}
... I get n minor page faults! Pretty amazing, but I guess they
figured nobody does that.
...
The first mprotect() removes the physical mapping from the page
table, the second mprotect() doesn't do anything because the mapping
isn't there. So when the page is accessed, a fault is needed to
insert the mapping back to the page table.
OK, thanks. I can see that in sys/i386/i386/pmap.c. It leaves me
wondering what MAP_ENTRY_COW is for, though.
--
--Ed L Cashin| PGP public key:
[EMAIL PROTECTED]| http://noserose.net/e/pgp/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible deadlocks?
On Thu, 7 Aug 2003, Robert Watson wrote: On Wed, 6 Aug 2003, Ted Unangst wrote: My advisor Dawson Engler has written a deadlock detector, and we'd like some verification. They look like bugs, unless there is some other reason why two call chains cannot happen at the same time. Neat -- sounds like two good catches given the responses so far. Can we expect more such reports forthcoming? This kind of help will be invaluable in finishing up the fine-grained locking work. Alternatively, do you plan to post the software? Is this static or dynamic analysis? etc, etc? :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories Just for everyone's info, any locking problems that I introduce over the next few months will not be mistakes, they will be test cases for the deadlock detector. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible deadlocks?
On Fri, 8 Aug 2003, David Schultz wrote: On Wed, Aug 06, 2003, Ted Unangst wrote: My advisor Dawson Engler has written a deadlock detector, and we'd like some verification. They look like bugs, unless there is some other reason why two call chains cannot happen at the same time. Cool! Is this a new checker for Metal? Is there a chance that it will be released other than as a commercial product through Coverity? It's pretty much independent of Metal. No idea what the release plans are going to be, but it certainly won't be soon. -- I read a funny story about how the Republicans freed the slaves. The Republicans are the ones who created slavery by law in the 1600's. Abraham Lincoln freed the slaves and he was not a Republican. - M. Barry, Mayor of Washington, DC ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
In message [EMAIL PROTECTED], John Birrell writes : I'm not convinced that any hacking is required other than passing the device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says. I traced the boot on my system and the MMCR is initialised early (when the Timecounter ELAN output occurs). Immediately following that initialisation, 'pcib' is added as a child of 'nexus'. I don't see why 'mmcr' couldn't be added as a child of 'nexus' too. At this point, nexus isn't walking through it's children so there shouldn't be a problem. Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'. This seems straight forward. Maybe I'm missing something. 8-) That's my take too. And MMCR belongs on nexus not on legacy from an architectural point of view. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ucom not in MAKEDEV in 4.8-STABLE
Hi People, I was wondering, is there a reason why the 4.8-STABLE version of MAKEDEV does not have the ability to generate ucom. (I was wondering because I have to back port a bit of code on every machine I want to do it on). Thanks, Jacob Jacob Rhoden - http://rhoden.id.au/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
In message [EMAIL PROTECTED], Bernd Walter writes: I need to add I2C support for a Elan520 based soekris system. The system has the required GPIO pins and there is the iicbb driver to handle generic bitbang code - just needing a simple layer driver to enable, disable and read pins. But unlike normal isa/pci hardware probing the existence of the GPIO line is a bit difficult. The current elan-mmcr.c gets started from i386/pci/pci_bus.c at host bridge probing, because that's seems to be the only place to safely detect this special CPU. That's my doing, based on my reading of the datasheet from AMD. It would be better if we could detect the Elan in the normal CPU identification stuff, but I couldn't seem to find a reliable way. From the logicaly standpoint the extensions had to be attached to nexus, but nowhere is the current code path there is a handle for nexus or any other device_t. In fact what you may want to do is hang the entire MMCR off the nexus as a bus, and hang the various drivers off that bus. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic during nfs operations in 4.8S on Dell 2650
On Thu, 7 Aug 2003, Mark Powell wrote: We've recently got a couple of Dell Poweredge 2650's with 2x2.8GHz Xeons, 4GB RAM, PERC 3/Di (aac) RAID controller. They are mounting a 700GB fs over NFS from a NetAPP. They are connected to a Cisco 3550-12T gigabit over copper switch. I tried them first on the intel em cards and they panicked and also the internal bge adapters with the same result. Thought everything was fine until I was rsyncing the POP3 mail stores from the old machines onto these. Rsync runs for about an hour or so and get's large. In the 300M-600M region the system will always panic. This happens on both systems, so doesn't seem a hardware fault. This is a 4.8S kernel and world rebuilt as of today. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic during nfs operations in 4.8S on Dell 2650
On 8 Aug 2003, at 11:52, Mark Powell wrote: #6 0xc0312ea3 in generic_bzero () FWIW, I think this is where the problem occurred. Probably tried to zero a page that didn't exist because of a failed KVA allocation. I probably don't have my terminology correct since I'm a system admin and not a programmer (just a wannabe for the moment). The programmers on this list will likely correct me if I'm wrong. We had several panics on one of our 4GB machines at the same point. Our solution was to increase the KVA space to 2GB from 1GB and rebuild the whole world with the new KVA setting. The panics disappeared. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM Gate.
Bruce M Simpson wrote: On Thu, Aug 14, 2003 at 09:52:25PM +0400, Buckie wrote: BTW, QNX had this for a long time, it's called QNet in there. Allows transparently to mount or use anything in /dev. Even a soundcard! Whatever next? PCI-over-IP? *shudder* Not new: http://www.isi.edu/div7/netstation/ Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Ultra ATA card doesn't seem to provide Ultra speeds. - SOLVED
It seems Buckie wrote: Hello folks. Some of you may remember my trouble with SI0680-based ULTRADMA ATA controller card. Well, the problem was obvivously the faulty card. After replacing it works fine. I don't know what magic Soeren has put in the SI driver, but unlike Windows it never crashed, never hang, it even tried to use UDMA modes. So kudos to Soeren for writing quality drivers like that one. I also remember Peter Kiesser has had some issues with drives falling back to PIO with SIS controller. I had this too on the drive that FreeBSD5.1_RELEASE used to start from. So now we know this can be an issue with a broken controller. (It doesn't fall back to PIO here after replacement is made). Again, thanks to Soeren it just magically worked (as best as it could obvivously) in spite of all the fish. That's all! OK! then I dont need to spend more time looking for trouble on that one :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tuning HZ for semi-realtime applications
There's this Linux kernel patch that allows for timeslice tuning. It's got the following rules of the thumb: * The optimal setting is your CPU's speed in MHz's / 2 * ...but there is no point in going above 1000 Hz * ...and be sure to use multiples of 100 Hz I am everything but an expert at scheduling, but somehow this makes sense: i.e. one jiffy for the scheduler and one jiffy for the process. Does all of this make any sense or is it just a load of hooey? Regards, Roderick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tuning HZ for semi-realtime applications
On Sunday 03 August 2003 16:54, Sean Hamilton wrote: Greetings, [...wants to send out a lot of traffic, then read responses 1000 times per second...is currently using select(2) in a loop...] Should I set HZ to 1000 (the frequency of my application) or should I set it to a much higher value? The CPU is running at around 2 GHz, and I set it as high as 50,000 with no problems. However, the granularity of my timeout appears to be restricted to 1/1000th of a second. harti@ already answered this. I have no experience playing with HZ settings, but his response sounds reasonable enough. I would like to use poll(2) instead of select, but it appears to take its timeout parameter in milliseconds, which aren't precise enough to keep my timing reasonable, especially if I ever need to increase my frequency. Another option would be calling poll/select with no timeout, in a loop. However, this seems like a waste of CPU time. You could insert an appropriately-sized nanosleep(2) into such a loop. -- Chris BeHanna Software Engineer (Remove bogus before responding.) [EMAIL PROTECTED] Turning coffee into software since 1990. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: hang in sio driver when interrupt occurs while in siocnputc()
From: Don Bowman I find that if the kernel is in the middle of a printf, is using a serial console, and a key is pressed, that i may end up stuck in the siointr. I added a counter to siointr1() so that if it receives more than 100 characters in a single interrupt it panics. What I find happens is that the chip (a winbond w83627HF in this case, 16550 compat) claims to have more characters to read (the fifo is not empty), but no interrupt is pending. The siointr1() loops forever on this, reading the com_data register. I created a simple kernel module that, on command from a sysctl, outputs many characters in a callout. When this is going, I hit enter a few times, and my panic occurs. Debugger(c03093aa) at Debugger+0x35 panic(c0330173,ce098000,3f8,ff807e60,8) at panic+0xb8 siointr1(ce098000,c0382788,3f8,ff807e44,c02c1e40) at siointr1+0x146 siointr(ce098000) at siointr+0x17 Xfastintr4(ff807e60,3f8,1c200,45,0) at Xfastintr4+0x20 siocnputc(c0362c44,45) at siocnputc+0x4d cnputc(45,1,63,0,ff807f40) at cnputc+0x4c putchar(45,ff807f60) at putchar+0x9d kvprintf(ce3bd75c,c01cb490,ff807f60,a,ff807f7c) at kvprintf+0x38e printf(ce3bd75c,45,0,ce3bd670,ff807fa8) at printf+0x44 so_timeout(0,4000,,0,) at so_timeout+0x3b softclock(0,ff800018,c02e0010,ce090010,) at softclock+0xfe doreti_swi(0,ff808000,0,0,f323a000) at doreti_swi+0xf idle_loop() at idle_loop+0x44 siocnputc() just takes spltty(), which doesn't prevent the interrupt from happening. this doesn't seem right, do you think that the siocn* routines should take COM_LOCK()? This is on RELENG_4. The system is SMP. Further, it appears the intent of siocnopen() is to disable interrupts on the particular uart, since its overwriting other registers: sp-ier = inb(iobase + com_ier); outb(iobase + com_ier, 0); /* spltty() doesn't stop siointr() */ but i'm nonetheless getting an interrupt. @ the offset I'm at in siocnputc siocnputc+0x48: callsiocnopen siocnputc+0x4d: pushl %ebx i'm in the process of calling siocnopen(), so it hasn't got to that interrupt disable code yet. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] Re: getfsent(3) and spaces in fstab
imho - expensive algorithm... i want to see anything more simple...
like gtok() instead es_strsep() + remove_escapes()?
I have adopted my patch to use your neat gtok() function, but I came to
the conclusion that a two-pass algorithm is necessary:
The first pass detects whether a line from fstab is the old or the new
style format (old style lines may only have unescaped white spaces
before a trailing #-comment).
Then, the second pass extracts the information.
I admit this is rather complicated, but I don't how to handle two sets
of delimiters (:\n and \n\r\t) with only one pass. Using gtok() to
detect the style of line is not an option IMO, since it would convert
escape sequences.
Now, the following lines can be processed:
1) old style:
file system:mount point:mount type:dump:passno([' ','\t']*#comment)*
2) new style
format as described in fstab(5) + an optional #-comment at the end of the line
3) empty lines, white space lines, deliberately many white spaces + comment
In both the old and the new style lines, white spaces can be written as
escape sequences or in double quotes.
Could somebody please review my patch - if there are no objections (but
I am sure there are some more details that can be improved), I will
write a PR in order
Regards,
Simon
--- fstab.c.origFri Aug 1 17:18:00 2003
+++ fstab.c Thu Aug 7 15:46:39 2003
@@ -84,6 +84,60 @@
_fs_fstab.fs_spec = buf;
}
+/*
+ * Gets a token from a string *s, that is either empty or is separated by
+ * a set of delimiters *delim.
+ * Characters that are in *delim, can occur in the token if the are escaped,
+ * i.e. have a '\' prepended. The character '\' itself is encoded as '\\'.
+ * *s can have a trailing comment (indicated by a '#'), which will cause the
+ * characters after the '#' to be ignored. To encode a '#' within a token,
+ * use '\#'.
+ *
+ * If a token is found, gtok sets the last character after its end
+ * to '\0' and returns a pointer it. Otherwise the return value is NULL.
+ * As a side effect, the input string *s modified and points to the next
+ * character after the end of the current token, i.e. after the '\0'.
+ */
+char *gtok(char **s, char const *delim)
+{
+ int quoted, escaped;
+ static char const esc_set[] = { 't', 'r', 'n', 'a', 0 };
+ static char const esc_rep[] = { '\t', '\r', '\n', '\a', 0 };
+ char *tok, *r, *w, *p;
+
+ if (!s || !*s || !*(tok = *s + strspn(*s, delim)) || *tok == '#')
+ return NULL;
+
+ for (quoted = escaped = 0, r = w = tok; *r; r++) {
+ if (!escaped) {
+ if (*r == '\\') {
+ escaped = 1;
+ continue;
+ }
+ if (*r == '\') {
+ quoted ^= -1;
+ continue;
+ }
+ if (!quoted) {
+ if (strchr(delim, *r)) {
+ r++;
+ break;
+ }
+ }
+ } else {
+ escaped = 0;
+ if ((p = strchr(esc_set, *r)) != NULL) {
+ *w++ = esc_rep[p - esc_set];
+ continue;
+ }
+ }
+ *w++ = *r;
+ }
+ *w = 0;
+ *s = r;
+ return tok;
+}
+
static int
fstabscan()
{
@@ -91,21 +145,73 @@
#defineMAXLINELENGTH 1024
static char line[MAXLINELENGTH];
char subline[MAXLINELENGTH];
- int typexx;
+ int typexx, escaped=0, quoted=0, ws_sep=0;
for (;;) {
if (!(p = fgets(line, sizeof(line), _fs_fp)))
return(0);
-/* OLD_STYLE_FSTAB */
++LineNo;
- if (*line == '#' || *line == '\n')
- continue;
- if (!strpbrk(p, \t)) {
- _fs_fstab.fs_spec = strsep(p, :\n);
- _fs_fstab.fs_file = strsep(p, :\n);
+
+ /* Detect whether line is in old or new fstab style */
+ for (cp=p; *cp != '\n'; ++cp) {
+ if (*cp == '\\') {
+ escaped = (escaped ? 0 : 1);
+ continue;
+ }
+ if (!escaped) {
+ /* Quotes */
+ if (*cp == '\') {
+ quoted = (quoted ? 0 : 1);
+ continue;
+ }
+ if (quoted)
+ continue;
+ /* new white separator found */
+ if (cp p strspn (cp, \n\r\t)
+ !strspn(cp-1, \t))
+
Re: USB versus SMP and Epson printers.
Don Lewis wrote: Unless someone snuck it in while I wasn't looking, our ulpt implementation doesn't support reading data from the printer, so it's not possible to check the ink levels. I've had to boot Linux in order to do this. Hmm. Okay... Unfortunately, the straight printing didn't work, either. I tried the check the ink levels trick only after my test page never printed. I'm using CUPS, could this be a limitation of the ulpt driver? Should I be using another device? -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : Back to the original question: : How do I get the device_t from nexus? You don't. You are assigned one. : Is there a get_nexus() function somewhere? No. You don't need it. Chances are you could create an identify routine that would attach the bus to. The identify routine should be all you need. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tuning HZ for semi-realtime applications
On Tue, Aug 05, 2003, Roderick van Domburg wrote: There's this Linux kernel patch that allows for timeslice tuning. It's got the following rules of the thumb: * The optimal setting is your CPU's speed in MHz's / 2 * ...but there is no point in going above 1000 Hz * ...and be sure to use multiples of 100 Hz I am everything but an expert at scheduling, but somehow this makes sense: i.e. one jiffy for the scheduler and one jiffy for the process. Does all of this make any sense or is it just a load of hooey? There might be some rationale behind that suggestion, but my first guess would be that someone pulled those numbers out of a hat. In general, doing a context switch has negative cache effects, in addition to the overhead that you pay up front. For optimum throughput, you want to set HZ to the smallest number that still gives acceptable resolution. 100 Hz works just fine for interactive jobs; humans can't tell the difference.[1] For many real-time applications, a higher value is needed. [1] In terms of overhead, I think 100 Hz is well into the noise these days, so bumping that up a little bit would result in negligible difference. I measured 100 vs. 500 a little while ago, and couldn't find a realistic benchmark that was negatively impacted by the higher frequency. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Missing system call in linux emulation
On Tue, Aug 12, 2003 at 05:42:51PM +0100, Steven Hartland wrote: Any one know how I can track down what function is missing and hence look at fixing it? In the linux kernel source tree, look in arch/i386/kernel/entry.S. There you'll find all the syscall entry points. Currently they go all the way to 271. Also look at arch/alpha/kernel/entry.S... Then, in /sys/i386/linux look in syscalls.master. There you'll see we only have syscalls up to 221. See also /sys/alpha/linux... One could: o Add proper prototypes to syscalls.master of the 50 new syscalls we don't know about, o Declare all these syscalls as dummies (see linux_dummy.c) to begin with, o Really implement those syscalls that are used in practice. Syscall 252 is exit_group(2). FYI, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: possible deadlocks?
On 06-Aug-2003 Ted Unangst wrote: My advisor Dawson Engler has written a deadlock detector, and we'd like some verification. They look like bugs, unless there is some other reason why two call chains cannot happen at the same time. deadlock between ktrace_mtx and sema_mtx. is it possible to call sema_timewait on ktrace_sema? call chain below. thread 1: _sema_timedwait(sema, ...) mtx_lock(sema-sema_mtx) /* gets this lock */ cv_timewait() ktrcsw() ktr_getrequest() mtx_lock(ktrace_mtx) /* waits for thread 2 */ thread 2: ktr_submitrequest mtx_lock(ktrace_mtx) /* gets this lock */ _sema_post(ktrace_sema) mtx_lock(sema-sema_mtx) /* waits for thread 1 */ Yes, the lock isn't needed around the post anyways. Fixed. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using CVS diff to find out what has changed, including new files
Hi, Artem 'Zazoobr' Ignatjev wrote: On Mon, 04.08.2003, at 17:04, Rolf Grossmann wrote: I'm using cvsup for a while now to get a copy of the FreeBSD CVS repository and I have a (slightly modified) version of -STABLE checked out from there. Now there are certain areas where I'd like to see what changed before doing a cvs update. Currently I'm using cvs diff -u -N -r BASE -r RELENG_4 to do that. However this has one drawback that I'm hoping you'll be able to help me with: If files have been removed from the distribution, these files continue to show up as getting readded (even though they won't when doing an update). To see the problem, you can go to /usr/src/sbin/md5 and run the above cvs diff command. Maybe server looks for those files in attic? Yes, it does. And rightfully so, because the given revision may still be present. However, I think it errs when it's not. as far as I understand logics of cvs update, it won't rub out your local changes - all you can get with cvs update are conflicts. Why not do cvs -n update -d, and then cvs update -d, or even cvs update -d -I your/changed/file1 -I another/changed/file, and then you can diff through this small (I suppose (: ) set of files Sorry, I think you didn't quite understand what I'm trying to achive. I'd like to get a diff of what has changed in the repository *before* I update my sources (and without making a copy of any files). Rolf ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How to get a device_t
I need to add I2C support for a Elan520 based soekris system. The system has the required GPIO pins and there is the iicbb driver to handle generic bitbang code - just needing a simple layer driver to enable, disable and read pins. But unlike normal isa/pci hardware probing the existence of the GPIO line is a bit difficult. The current elan-mmcr.c gets started from i386/pci/pci_bus.c at host bridge probing, because that's seems to be the only place to safely detect this special CPU. From the logicaly standpoint the extensions had to be attached to nexus, but nowhere is the current code path there is a handle for nexus or any other device_t. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
USB versus SMP and Epson printers.
On Monday I received my brand-new Epson C82, a replacement for a 900N with a dead print head. I had already configured CUPS so I imagined that I would just hook it up with USB and everything would be happy. Well, that's not how it turned out. I tried two different machines, both with Tyan dual-CPU motherboards. One is a Thunder 2500 (S1867) with dual PIII 866, my gateway/fax/server box and the one I preferred. The other is my main desktop box, a Tiger MPX (2466N-4M) with dual Athlon MP 1900+. Both displayed essentially the same problem, although the Tiger MPX seemed to come a little bit closer to working than the Thunder 2500. Basically, although usbdevs would show the device, when I tried to do, say, an 'escputil -s -r /dev/ulpt0' (to show the ink levels), the process would seem to send something to the printer (I say seem to because I saw no evidence of it on the printer side), then sit in the USB code forever, timing out and looping. On the Tiger MPX I did see the port disabled message when I connected the printer (although nothing when I disconnected it). The Thunder 2500 didn't do that much. I've attached the dmesg from the Thunder 2500; I don't have one handy for the MPX. If anyone can give me any hints about this, I would be very grateful. Thanks. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-STABLE #1: Mon Aug 4 14:54:45 PDT 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/TINKER Timecounter i8254 frequency 1193182 Hz CPU: Intel Pentium III (868.64-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 2147483648 (2097152K bytes) avail memory = 2087452672 (2038528K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor motherboard: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000 Preloaded elf kernel kernel at 0xc0406000. Pentium Pro MTRR support enabled Using $PIR table, 12 entries at 0xc00fdf00 npx0: math processor on motherboard npx0: INT 16 interface pcib0: ServerWorks LE host to PCI bridge on motherboard IOAPIC #1 intpin 13 - irq 2 IOAPIC #1 intpin 12 - irq 16 IOAPIC #1 intpin 0 - irq 17 IOAPIC #1 intpin 2 - irq 18 IOAPIC #1 intpin 4 - irq 19 IOAPIC #1 intpin 7 - irq 20 pci0: PCI bus on pcib0 pci0: unknown card (vendor=0x1166, dev=0x0005) at 0.1 sym0: 896 port 0xf800-0xf8ff mem 0xfeafe000-0xfeaf,0xfeaf8c00-0xfeaf8fff irq 2 at device 1.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-40, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym1: 896 port 0xf400-0xf4ff mem 0xfeafc000-0xfeafdfff,0xfeaf8800-0xfeaf8bff irq 16 at device 1.1 on pci0 sym1: Symbios NVRAM, ID 7, Fast-40, SE, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: handling phase mismatch from SCRIPTS. pci0: unknown card (vendor=0x11cb, dev=0x2000) at 3.0 irq 17 tl0: Compaq Netelligent 10/100 port 0xfc90-0xfc9f mem 0xfeafbc00-0xfeafbc0f irq 18 at device 4.0 on pci0 tl0: Ethernet address: 00:08:c7:b1:93:c3 miibus0: MII bus on tl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto tlphy0: ThunderLAN 10baseT media interface on miibus0 tlphy0: 10base2/BNC, 10base5/AUI fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0xfca0-0xfcbf mem 0xfe80-0xfe8f,0xfceff000-0xfcef irq 19 at device 5.0 on pci0 fxp0: Ethernet address 00:90:27:1c:5e:6a inphy0: i82555 10/100 media interface on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0xfcc0-0xfcff mem 0xfe90-0xfe9f,0xfeaf7000-0xfeaf7fff irq 20 at device 7.0 on pci0 fxp1: Ethernet address 00:e0:81:01:ff:6c inphy1: i82555 10/100 media interface on miibus2 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: ServerWorks IB6566 PCI to ISA bridge at device 15.0 on pci0 isa0: ISA bus on isab0 pci0: Unknown PCI ATA controller at 15.1 ohci0: OHCI (generic) USB controller mem 0xfeaf6000-0xfeaf6fff irq 17 at device 15.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4
RE: hang in sio driver when interrupt occurs while in siocnputc()
I propose this patch, which solves my issue. Comments?
$ cvs diff -U3 sio.c
Index: sio.c
===
RCS file: /usr/cvs/src/sys/isa/Attic/sio.c,v
retrieving revision 1.291.2.33.1000.4
diff -U3 -r1.291.2.33.1000.4 sio.c
--- sio.c 13 May 2003 23:51:23 - 1.291.2.33.1000.4
+++ sio.c 10 Aug 2003 18:11:37 -
@@ -274,6 +274,7 @@
struct termios lt_in; /* should be in struct tty */
struct termios lt_out;
+ bool_t in_polled_mode;
bool_t do_timestamp;
bool_t do_dcd_timestamp;
struct timeval timestamp;
@@ -1985,6 +1986,10 @@
struct timecounter *tc;
u_int count;
+ if (com-in_polled_mode) {
+ return;
+ }
+
int_ctl = inb(com-intr_ctl_port);
int_ctl_new = int_ctl;
@@ -3085,6 +3090,9 @@
sp-ier = inb(iobase + com_ier);
outb(iobase + com_ier, 0); /* spltty() doesn't stop siointr()
*/
siocntxwait(iobase);
+ if (com_addr(comconsole)) {
+ (com_addr(comconsole))-in_polled_mode = TRUE;
+ }
sp-cfcr = inb(iobase + com_cfcr);
outb(iobase + com_cfcr, CFCR_DLAB | CFCR_8BITS);
sp-dlbl = inb(iobase + com_dlbl);
@@ -3132,6 +3140,9 @@
*/
outb(iobase + com_mcr, sp-mcr | MCR_DTR | MCR_RTS);
outb(iobase + com_ier, sp-ier);
+ if (com_addr(comconsole)) {
+ (com_addr(comconsole))-in_polled_mode = FALSE;
+ }
}
static void
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
On Thu, Aug 07, 2003 at 10:23:03AM -0400, John Baldwin wrote: On 07-Aug-2003 M. Warner Losh wrote: In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : The host bridge is not available yet at probing time of the host bridge. : What we have is the host bridges parent (nexus) in the calling function. : Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or : we find it out later. Don't you mean legacy_pcib_is_host_bridge? That's where the matching is done in current right now (well, at least as of my last sync) If so, passing the host bridge's device down to it would be trivial to add. It would also allow other CPUs with builtin host bridges to do similar tricks to the one that is done for the ELAN. These sorts of features have been very common in other CPU families, and there's no reason to think that there won't be more of them in the x86 family as time goes on. I'm not sure that adding it to nexus at this stage of the boot would truly work. Since the legacy device has decided to attach, the nexus bus is already walking through its children. Adding a child during that walk strikes me as dangerous, since we have no locking on the children element of the device_t. Hmmm, looks I just found a source of problems in my newbus locking code that might explain some weird things happening when I enable it Thanks for making me go look :-) You would add it to legacy, not nexus. What you probably really want to do is to write a host-PCI bridge driver that attaches to the actual PCI device like 'hostb' and 'agp' do that creates a suitable child bus for the MMCR stuff. This works for both ACPI and non-ACPI and doesn't require hacking the legacy_pcib stuff. I'm not convinced that any hacking is required other than passing the device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says. I traced the boot on my system and the MMCR is initialised early (when the Timecounter ELAN output occurs). Immediately following that initialisation, 'pcib' is added as a child of 'nexus'. I don't see why 'mmcr' couldn't be added as a child of 'nexus' too. At this point, nexus isn't walking through it's children so there shouldn't be a problem. Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'. This seems straight forward. Maybe I'm missing something. 8-) -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
On Wed, Aug 06, 2003 at 05:52:57PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : Back to the original question: : How do I get the device_t from nexus? You don't. You are assigned one. : Is there a get_nexus() function somewhere? No. You don't need it. Chances are you could create an identify routine that would attach the bus to. The identify routine should be all you need. The point is that this special CPU can only be identified by its host bridge. That's the place were the MMCR bus has to be attached to nexus, so we need the handle within this function. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible deadlocks?
On Thu, 7 Aug 2003, Robert Watson wrote: Neat -- sounds like two good catches given the responses so far. Can we expect more such reports forthcoming? This kind of help will be invaluable in finishing up the fine-grained locking work. Alternatively, do you plan to post the software? Is this static or dynamic analysis? etc, etc? :-) First, thanks Sam and John for confirmation. More reports should be coming as we find things, though this is still early. It's being done using static analysis, though I'm not really involved in writing the checker. I just happen to know some about the kernel and help interpret results. :) Good to know you're interested though. -- People have criticized me because my security detail is larger than the president's. But you must ask yourself: are there more people who want to kill me than who want to kill the president? I can assure you there are. - M. Barry, Mayor of Washington, DC ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
On Fri, Aug 08, 2003 at 04:32:43PM -0400, John Baldwin wrote:
On 08-Aug-2003 Bernd Walter wrote:
On Fri, Aug 08, 2003 at 03:48:22PM -0400, John Baldwin wrote:
On 08-Aug-2003 Bernd Walter wrote:
On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote:
Well, that would be a major pain on current since nexus is already
finished attaching many of its drivers by the time it gets to here.
Also, if you use ACPI and if ACPI exists, then this function _won't_
_ever_ _be_ _called_. If you use a hostb PCI driver, then it will
work both for ACPI and legacy.
I agree with this point and if I understood correct this is what
John Birrel already had done.
No, he is still working in the nexus/pcib driver's identify routine,
not in a separate 'hostb' PCI driver.
However - I would still like to know why
device_add_child(nexus, elanbb, -1);
results in an elanbb instance numer 1 connected to pci0.
And why I don't get any iicbb childs.
I would have to see your code changes in order to try to tell you that.
http://www.cosmo-project.de/~bernd/elanbb.diff
First off, the iicbb driver does not know have an elanbb attachment.
You need a set of driver methods and corresponding
DRIVER_MODULE(iicbb, elanbb, ...)
For the iicbb child of elanbb to get a driver that probes it and attaches
to it.
Hmm, what you want to do is not hijack the legacy/pcib identify
routine I think, but add an identify routine to your elanbb driver
and have elanbb live off the nexus (so DRIVER_MODULE(elan, nexus))
and have its identify routine use pci_cfgreg() to get the devid for
device 0 and if it is the right one call init_AMD_Elan_sc520() and
add it's probe routine. Or rather. I've fixed all this and you can
get the changes (whcih should fix bogus elanbb0 and make iicbb0 show
up) at http://www.freebsd.org/~jhb/patches/elan.patch It includes
your patch above but fixes a few things. One other bug I fixed is
that since yout elan was hung off of pci and had an empty probe
routine, any unclaimed PCI device got claimed by your elanbb driver,
hence your bogus elanbb0. Note that the version of elanbb in
elan.patch uses a private identify routine that calls
init_AMD_Elan_sc250(), so it will work both with and without ACPI.
However, the warning printf about CPU_ELAN won't show up with ACPI.
I left the printf in pci_bus.c for now. A better place to put it would
be in the hostb driver itself. Well, I went ahead and did that too,
so now the warning will show up both for ACPI and non-ACPI systems.
After adding you patch and some includes (machine/pci_cfgreg.h,
dev/pci/pcireg.h)
[...]
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a): mode1res=0x8000 (0x8000)
pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=30001022)
pcibios: BIOS version 2.00
Doing h0h0magic for AMD Elan sc520
sysctl machdep.i8254_freq=1189161 returns 0
Timecounter ELAN frequency 833 Hz
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x78363029
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc029d05b
stack pointer = 0x10:0xc03cdcc4
frame pointer = 0x10:0xc03cdcd4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at BUS_ADD_CHILD+0x2b: pushl 0x4(%eax)
db trace
BUS_ADD_CHILD(c0307fb8,0,c02c9f2f,) at BUS_ADD_CHILD+0x2b
elanbb_identify(c0307fb8,c05ad800,c05a72b0,c05ad800,c03cdd1c) at elanbb_identify+0x3b
DEVICE_IDENTIFY(c0307fb8,c05ad800) at DEVICE_IDENTIFY+0x3e
bus_generic_probe(c05ad800,c0db7098,c03cdd40,c01b24da,c05ad800) at
bus_generic_probe+0x28
nexus_attach(c05ad800,c05ad800,c05adb80,c03cdd5c,c01b0f01) at nexus_attach+0xd
DEVICE_ATTACH(c05ad800,1,c05ad800,c0305efc,3d2000) at DEVICE_ATTACH+0x3a
device_probe_and_attach(c05ad800) at device_probe_and_attach+0x81
root_bus_configure(c05adb80,c02e4cb8,0,4) at root_bus_configure+0x16
configure(0,3cac00,3ca000,0,c0123825) at configure+0x22
mi_startup() at mi_startup+0xb2
begin() at begin+0x2c
db
c029d030 BUS_ADD_CHILD:
typedef device_t bus_add_child_t(device_t _dev, int _order, const char *_name,
int _unit);
static __inline device_t BUS_ADD_CHILD(device_t _dev, int _order,
const char *_name, int _unit)
{
c029d030: 55 push %ebp
c029d031: 89 e5 mov%esp,%ebp
c029d033: 56 push %esi
c029d034: 53 push %ebx
c029d035: 8b 75 08mov0x8(%ebp),%esi
kobjop_t _m;
KOBJOPLOOKUP(((kobj_t)_dev)-ops,bus_add_child);
c029d038: b8 00 00 00 00 mov$0x0,%eax
c029d03d:
Missing system call in linux emulation ( patch )
I've created a patch for the linux emulation which adds a dummy for the exit_group syscall along with defining all functions up to 252 this fixes a crash in the BattleField 1942 server. How do I go about getting this into the various FreeBSD streams so others can benifit. Steve / K ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic during nfs operations in 4.8S on Dell 2650
On Fri, 8 Aug 2003, Mark Powell wrote: On Thu, 7 Aug 2003, Kip Macy wrote: Can you get a backtrace? Isn't that what I included at the bottom of my first message? I tried bumping nmbclusters up to 65536 from 32768. Still got a panic. Here's another backtrace of the latest panic: Script started on Fri Aug 8 11:49:19 2003 /var/crash # gdb -k kernel.debug.4 vmcore.4 GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf SMP 2 cpus IdlePTD at phsyical address 0x004ad000 initial pcb at physical address 0x003f8d00 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode mp_lock = 01000290; cpuid = 1; lapic.id = 0200 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0312ea3 stack pointer = 0x10:0xff487ca0 frame pointer = 0x10:0xff487ccc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 230 (rsync) interrupt mask = none - SMP: XXX trap number = 12 panic: page fault mp_lock = 01000290; cpuid = 1; lapic.id = 0200 boot() called on cpu#1 syncing disks... 2 1 done Uptime: 1h1m1s dumping to dev #aacd/0x20001, offset 524636 dump 3839 3838 3837 3836 3835 3834 3833 3832 3831 3830 3829 3828 3827 3826 3825 3824 3823 3822 3821 3820 3819 3818 3817 3816 3815 3814 3813 3812 3811 3810 3809 3808 3807 3806 3805 3804 3803 3802 3801 3800 3799 3798 3797 3796 3795 3794 3793 3792 3791 3790 3789 3788 3787 3786 3785 3784 3783 3782 3781 3780 3779 3778 3777 3776 3775 3774 3773 3772 3771 3770 3769 3768 3767 3766 3765 3764 3763 3762 3761 3760 3759 3758 3757 3756 3755 3754 3753 3752 3751 3750 3749 3748 3747 3746 3745 3744 3743 3742 3741 3740 3739 3738 3737 3736 3735 3734 3733 3732 3731 3730 3729 3728 3727 3726 3725 3724 3723 3722 3721 3720 3719 3718 3717 3716 3715 3714 3713 3712 3711 3710 3709 3708 3707 3706 3705 3704 3703 3702 3701 3700 3699 3698 3697 3696 3695 3694 3693 3692 3691 3690 3689 3688 3687 3686 3685 3684 3683 3682 3681 3680 3679 3678 3677 3676 3675 3674 3673 3672 3671 3670 3669 3668 3667 3666 3665 3664 3663 3662 3661 3660 3659 3658 3657 3656 3655 3654 3653 3652 3651 3650 3649 3648 3647 3646 3645 3644 3643 3642 3641 3640 3639 3638 3637 3636 3635 3634 3633 3632 3631 3630 3629 3628 3627 3626 3625 3624 3623 3622 3621 3620 3619 3618 3617 3616 3615 3614 3613 3612 3611 3610 3609 3608 3607 3606 3605 3604 3603 3602 3601 3600 3599 3598 3597 3596 3595 3594 3593 3592 3591 3590 3589 3588 3587 3586 3585 3584 3583 3582 3581 3580 3579 3578 3577 3576 3575 3574 3573 3572 3571 3570 3569 3568 3567 3566 3565 3564 3563 3562 3561 3560 3559 3558 3557 3556 3555 3554 3553 3552 3551 3550 3549 3548 3547 3546 3545 3544 3543 3542 3541 3540 3539 3538 3537 3536 3535 3534 3533 3532 3531 3530 3529 3528 3527 3526 3525 3524 3523 3522 3521 3520 3519 3518 3517 3516 3515 3514 3513 3512 3511 3510 3509 3508 3507 3506 3505 3504 3503 3502 3501 3500 3499 3498 3497 3496 3495 3494 3493 3492 3491 3490 3489 3488 3487 3486 3485 3484 3483 3482 3481 3480 3479 3478 3477 3476 3475 3474 3473 3472 3471 3470 3469 3468 3467 3466 3465 3464 3463 3462 3461 3460 3459 3458 3457 3456 3455 3454 3453 3452 3451 3450 3449 3448 3447 3446 3445 3444 3443 3442 3441 3440 3439 3438 3437 3436 3435 3434 3433 3432 3431 3430 3429 3428 3427 3426 3425 3424 3423 3422 3421 3420 3419 3418 3417 3416 3415 3414 3413 3412 3411 3410 3409 3408 3407 3406 3405 3404 3403 3402 3401 3400 3399 3398 3397 3396 3395 3394 3393 3392 3391 3390 3389 3388 3387 3386 3385 3384 3383 3382 3381 3380 3379 3378 3377 3376 3375 3374 3373 3372 3371 3370 3369 3368 3367 3366 3365 3364 3363 3362 3361 3360 3359 3358 3357 3356 3355 3354 3353 3352 3351 3350 3349 3348 3347 3346 3345 3344 3343 3342 3341 3340 3339 3338 3337 3336 3335 3334 3332 3331 3330 3329 3328 3327 3326 3325 3324 3323 3322 3321 3320 3319 3318 3317 3316 3315 3314 3313 3312 3311 3310 3309 3308 3307 3306 3305 3304 3303 3302 3301 3300 3299 3298 3297 3296 3295 3294 3293 3292 3291 3290 3289 3288 3287 3286 3285 3284 3283 3282 3281 3280 3279 3278 3277 3276 3275 3274 3273 3272 3271 3270 3269 3268 3267 3266 3265 3264 3263 3262 3261 3260 3259 3258 3257 3256 3255 3254 3253 3252 3251 3250 3249 3248 3247 3246 3245 3244 3243 3242 3241 3240 3239 3238
RE: COW and mprotect on non-shared memory
For that reason, when you mprotect an area of non-shared, anonymous
memory to no access and then back to writable, Linux has no way of
knowing that the memory wasn't set for COW before you make it
unwritable. It goes ahead and makes all the pages in the area COW.
That means that if I do this:
for (i = 0; i n; ++i) {
assert(!mprotect(p, pgsiz, PROT_NONE));
assert(!mprotect(p, pgsiz, PROT_READ|PROT_WRITE|PROT_EXEC));
p[i] = i 0xff;
}
... I get n minor page faults! Pretty amazing, but I guess they
figured nobody does that.
More surprising is that the same test program has the same behavior on
FreeBSD. (At least, the /usr/bin/time -l ... output shows the
number of page reclaims increasing at the same rate that I increase
the value of n in the loop.)
I thought that in FreeBSD any COW area would have its own vm_map_entry
with the MAP_ENTRY_COW bit set. That way, you could run this test
without any minor faults at all. Now I suspect I was incorrect.
Could anyone help clarify the situation for me?
Thanks.
--
--Ed L Cashin| PGP public key:
[EMAIL PROTECTED]| http://noserose.net/e/pgp/
The first mprotect() removes the physical mapping from the page table,
the second mprotect() doesn't do anything because the mapping isn't
there. So when the page is accessed, a fault is needed to insert the
mapping back to the page table.
-lq
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding device IDs to if_wi?
I've added this to current. Thanks for the data. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ucom not in MAKEDEV in 4.8-STABLE
On Thu, 7 Aug 2003 06:39 pm, Peter Pentchev wrote: Err, are you sure you mean -STABLE, and not -RELEASE here? ucom was added to -STABLE's MAKEDEV three weeks ago, in rev. 1.243.2.57 by Kris Kennaway. Oops, I did my last cvsup on my machines about 3 weeks ago. I assumed it hadnt been added since then (: My mistake! Jacob Rhoden - http://rhoden.id.au/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
IP Network Multipathing failover on FreeBSD..??
Hi all, Is it there have IP Network Multipathing failover on FreeBSD..?? how to do so?? Thanks ³Ì·s¹aÁn±À¤¶:¤Q±®I¥ñ¡A¦hÁÂ¥¢ÅÊ¡A¤ß²H... http://ringtone.yahoo.com.hk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Broadcom 440x
Hi all. A few months ago I saw that some people were having probs finding a driver for the 440x network card installed on some onboard motherboards. Has anyone had any luck in finding drivers for these cards as I now have a dell laptop that I cant connect to the network (Not very useful). If anyone is aware of drivers for either the 4.x or 5.x strands of freebsd I would be most interested Regards Michael Day Electrical Engineer Paterson Flood Engineers Tel: +61 7 3871 0533 Fax: +61 7 3871 0538 Mob: +61 400 369 355 Email: [EMAIL PROTECTED] Web: www.pfe.com.au ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
system move
Hi, I've bought a new disk and tried to move my FreeBSD 5.1 release on it. Even I'm a real newbie I've followed all the steps from faq/disks 9.2 carrefuly /*eg. dump 0af - / | restore xf -*/ and finally set bootable in sysinstall. All the data are there when I tried to mount it but it is still bugging me with 'invalid partition' message during boot. Here are some data that might help you to help me: ad1s1 and ad1s3 are just data. /,/var,/tmp,/swp are all on ad1s2 --- Sysinstall-fdisk output: Disk name: ad1 FDISK Partition Editor DISK Geometry: 4863 cyls/255 heads/63 sectors = 78124095 sectors (38146MB) Offset Size(ST)End Name PType Desc SubtypeFlags 0 63 62- 12 unused0 63 27262242 27262304ad1s2 8freebsd 165 27262305 26073495 53335799ad1s3 8freebsd 165 53335800 24788295 78124094ad1s1 8freebsd 165 78124095905 78124999- 12 unused0 'Boot0cfg -v ad1' output: # flag start chs type end chs offset size 1 0x00 1023:255:63 0xa5 1023:254:63 53335800 24788295 2 0x80 0: 1: 1 0xa5 1023:254:63 63 27262242 3 0x00 1023:255:63 0xa5 1023:254:63 27262305 26073495 version=1.0 drive=0x80 mask=0xf ticks=182 options=packet,update,nosetdrv default_selection=F2 (Slice 2) Thanks for any suggestion. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
syscalls
I'm sorry if this is slightly offtopic, or too general for this particular list, but I can't think of a better place to ask. Also, I've been sent here from Undernet's FreeBSD channel. I am looking for a somewhat more detailed list of the FreeBSD syscalls than what is in '/usr/src/sys/kern/syscalls.master'. Basically, I would also want to know when registers are changed, when I have to look out for it, and any other information that might be useful. I searched on the lists and with google, and found nothing conclusive. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Missing system call in linux emulation
When running the BattleField 1942 server under FreeBSD 5.0-RELEASE / 5.1-RELEASE I get the following when the server terminates or changes map ( which I understand forks exec's then parent quits ) Core was generated by `bf1942_lnxded.stati'. Program terminated with signal 12, Bad system call. #0 0x086cc7cf in _exit () (gdb) bt #0 0x086cc7cf in _exit () #1 0x08695a2f in __pthread_manager () Running under truss I get: write(56,0xbfbff8e0,148) = 148 (0x94) linux_rt_sigprocmask(0x2,0x0,0xbfbff840,0x8) = 0 (0x0) SIGNAL 32 linux_rt_sigsuspend(0xbfbff840,0x8) ERR#4 'Interrupted system call' SIGNAL 32 SIGNAL 32 linux_sigreturn(0xbfbff54c) ERR#4 'Interrupted system call' SIGNAL 20 linux_wait4(0x12421,0x0,0x8000,0x0) = 74785 (0x12421) -- UNKNOWN SYSCALL 252 -- (null)() ERR#78 'Function not implemented' SIGNAL 12 SIGNAL 12 Process stopped because of: 16 process exit, rval = 140 Any one know how I can track down what function is missing and hence look at fixing it? Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broadcom 440x
On Wednesday, 13 August 2003 at 10:36:01 +1000, Michael Day wrote: Hi all. A few months ago I saw that some people were having probs finding a driver for the 440x network card installed on some onboard motherboards. Has anyone had any luck in finding drivers for these cards as I now have a dell laptop that I can\222t connect to the network (Not very useful). If anyone is aware of drivers for either the 4.x or 5.x strands of freebsd I would be most interested Duncan Barclay is working on a driver, but it's not finished yet. Do you want to help? Which model laptop do you have? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Why is ATAPI DMA disabled by default ?
On Thu, 14 Aug 2003, 01:45+0300, Alexander Serkov wrote: I use 5.1-current and have found that by default FreeBSD disables ATAPI's support for DMA transfers and thus uses CPU hungry PIO modes. It even makes sysctl used to change this read-only. I had changed the default value of atapi_dma to 1 in dev/ata/atapi-all.c to 1 and it worked fine for me. Hint: put hw.ata.atapi_dma=1 in /boot/loader.conf. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Possible patch for vm/vm_glue.c
Hello,
I've been reading vm_glue.c and I think I've found a bug regarding the
lock of `proc.p_sflag' inside `scheduler' function.
From proc.h, int p_sflag; /* (j) PS_* flags. */ and (j) - locked by
sched_lock mtx; but the access is done without having the lock.
Take a look at the attached patch and tell me if this is ok.
Patch made against $FreeBSD: src/sys/vm/vm_glue.c,v 1.172 2003/05/13
20:36:02 jhb Exp $, but this is also present in current 1.182.
Regards,
Rui Lopes
# we should only access `proc.p_sflag' when `sched_lock' is locked.
# From proc.h:
#int p_sflag;/* (j) PS_* flags. */
# and j means: (j) - locked by sched_lock mtx
# -- Rui Lopes [EMAIL PROTECTED]
--- vm_glue.c.orig Mon Aug 11 12:41:33 2003
+++ vm_glue.c Mon Aug 11 12:45:58 2003
@@ -596,10 +596,11 @@
sx_slock(allproc_lock);
FOREACH_PROC_IN_SYSTEM(p) {
struct ksegrp *kg;
+ mtx_lock_spin(sched_lock);
if (p-p_sflag (PS_INMEM | PS_SWAPPINGOUT | PS_SWAPPINGIN)) {
+ mtx_unlock_spin(sched_lock);
continue;
}
- mtx_lock_spin(sched_lock);
FOREACH_THREAD_IN_PROC(p, td) {
/*
* An otherwise runnable thread of a process
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Patch for Alladin dallas (ALi) AGP kernel panic [long]
Hallo,
first of all: I am completely new to both FreeBSD kernel internals and
to
PC-Intel hardware stuff, and the last time I put my hands on a *BSD
kernel
was a few years ago, so I might be wrong but still: it works and for
sure fixed an existing bug.
My machine did not like to go beyond 4.7. Kernel panic after AGP
probing,
trying to contigmalloc1() with size = 0; the problem seem to be shared
by
several machines based on the ALi chipset. Compiling a custom kernel
without the agp device worked.
Looking into the code and several panic outputs I found these issues:
- I am almost sure that the box here does not have an AGP bus at all
(it has an onboard video, maybe an internal AGP bus is there but there
is not a connector for sure). 4.7 did not show any agp* device at
boot,
4.8 and 5.* without agp* just see the vga* on isa* and work.
So *maybe* someone could investigate if the device is really an AGP
bus... (or give me a clue on how to check it).
- If it is an agp bus then for some reason it reports an aperture size
of zero, does this make any sense ? Again: my knowledge of agp stuff
is NULL. Could we leave the device attached without allocating
anything
there ?
- In /src/sys/pci/agp_ali.c and others there is a loop that supposedly
tries to alloc smaller apertures until it either fails reaching zero
size or manages to allocate something: no matter what the two points
above result to be the thing is just broken (as is will either alloc
the requested size at the first shot, crash if it was zero, or fail if
it ever tries to reduce the aperture), this is what I patched.
The attached patch fixes the said loop to make it do something
meaningful
(try to malloc a progressively smaller aperture, until it reaches zero
or
succeeds, if it fails detaches the device and returns ENOMEM).
As said: whatever the real origin of the problem was this thing was just
broken and now does what the original code probably intended to do so
that
at least now the system boots.
Maybe this helps also others having troubles with some Toshiba laptops
using that chipset and that reported the same panic on several lists.
Pasted down here the patch -rc3 for pci_ali.c. The same loop should be
fixed on several other pci_*.c sources, let me know what patch style is
preferred and if the list supports attachments and I'll be glad to send
the complete diff for all pertinent files.
Also let me know if returning ENOMEM when we are requested to have an
aperture size of 0 is ok or I should better have it return EINVAL (this
option looks better to me).
Then is up to someone knowing a bit better the hardware and kernel
internals
to work on the real solution (understand if we fail the probe and this
is
not really an agp bus, or find a way to know correctly the aperture
size).
Ciao,
A.
= CUT HERE ==
*** agp_ali.c.unpatched Mon Aug 4 09:25:13 2003
--- agp_ali.c Mon Aug 4 12:13:44 2003
***
*** 101,121
return error;
sc-initial_aperture = AGP_GET_APERTURE(dev);
! for (;;) {
gatt = agp_alloc_gatt(dev);
if (gatt)
break;
!
! /*
!* Probably contigmalloc failure. Try reducing the
!* aperture so that the gatt size reduces.
!*/
! if (AGP_SET_APERTURE(dev, AGP_GET_APERTURE(dev) / 2)) {
agp_generic_detach(dev);
return ENOMEM;
- }
}
sc-gatt = gatt;
/* Install the gatt. */
--- 101,120
return error;
sc-initial_aperture = AGP_GET_APERTURE(dev);
+ gatt = NULL;
! while (AGP_GET_APERTURE(dev) != 0) {
gatt = agp_alloc_gatt(dev);
if (gatt)
break;
! AGP_SET_APERTURE(dev, AGP_GET_APERTURE(dev) / 2);
! }
!
! if (!gatt) {
agp_generic_detach(dev);
return ENOMEM;
}
+
sc-gatt = gatt;
/* Install the gatt. */
= CUT HERE ==
PS: cc: me on the replies please, I'm not on the list, thanks.
--
Andrea Cocito [EMAIL PROTECTED]
IEO -- European Institute of Oncology - Bioinformatics group
tel: +39 02 57489 857 fax: +39 02 57489 851
Imagination is more important than knowledge
-Albert Einstein
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
On Wed, Aug 06, 2003 at 07:27:42PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : The host bridge is not available yet at probing time of the host bridge. : What we have is the host bridges parent (nexus) in the calling function. : Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or : we find it out later. Don't you mean legacy_pcib_is_host_bridge? That's where the matching Yes - I looked at 5.1-RELEASE code. Layering seems to have been changed since then. is done in current right now (well, at least as of my last sync) If so, passing the host bridge's device down to it would be trivial to add. It would also allow other CPUs with builtin host bridges to do How? legacy_pcib_is_host_bridge is called before BUS_ADD_CHILD. similar tricks to the one that is done for the ELAN. These sorts of features have been very common in other CPU families, and there's no reason to think that there won't be more of them in the x86 family as time goes on. point taken. I'm not sure that adding it to nexus at this stage of the boot would truly work. Since the legacy device has decided to attach, the nexus bus is already walking through its children. Adding a child during that walk strikes me as dangerous, since we have no locking on the children element of the device_t. Hmmm, looks I just found a source of problems in my newbus locking code that might explain some weird things happening when I enable it Thanks for making me go look :-) OK - that's an argument to avoid nexus. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
In message: [EMAIL PROTECTED] John Birrell [EMAIL PROTECTED] writes: : On Wed, Aug 06, 2003 at 07:45:32PM -0600, M. Warner Losh wrote: : Well, I don't know. The PC Cards that we have in the system are : mapped into the I/O and memory ranges traditionally reserved for the : ISA bus. In ISA systems, this made sense because pccard was attached : to pcic was attached to isa. However, now we have situations where : pccard is attached to cbb which is attached to pci. There may be a : isab device with isa bus hanging off of it that makes the relationship : between the pccard devices cousins rather than nephews in the tree. : And there isn't any harm from that. Wouldn't this be a similar : situation? : : The flash I'm talking about is not pccard related. Sorry if I gave that : impression. No. The pccard mention was to argue by analogy only :-) : The SC520 has onboard support to control 3 flash chips. : The board I have has 2 Mb NOR flash chip containing BIOS plus a DOS : file system (at the moment) where I keep a copy of an etherboot : executable. The board also has a 64Mb NAND flash chip which I've : written a FreeBSD UFS image into. Our standard bootloader happily : loads the kernel from that. Now I need to get a flash driver working : for the root file system. I've got an existing read-only flash driver : that I used to use on an Intel 386EX board, but that had the entire : flash chip memory mapped. This new board maps the NAND flash in 4K : pages. That would be very very cool. There's a number of new SBCs that I've seen that have this sort of setup. Timing Solutions might be very interesting in something like this because we're currently buying CF cards to do our OS. : This URL lists the relevent docs: : : http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_8634_8635%5E8641,00.html : : The ones you want are the ElanSC520 Users Manual and ElanSC520 : Register Set Manual Downloading now. : If you have time, I'd be interested. This is a hot topic for me because : it is exactly where I'm up to. I have everything else working on the : board. I'm thinking that it wouldn't take too long. Lemme see what I can throw together. It would be a sketch only... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM Gate.
On Thu, Aug 14, 2003 at 09:52:25PM +0400, Buckie wrote: + BTW, QNX had this for a long time, it's called QNet in there. Allows + transparently to mount or use anything in /dev. Even a soundcard! I think this isn't really hard to implement. But there are two problems: 1. Device major numbers. 2. Handle network errors. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Tuning HZ for semi-realtime applications
On Wed, Aug 06, 2003, Jan Grant wrote: On Tue, 5 Aug 2003, David Schultz wrote: 100 Hz works just fine for interactive jobs; humans can't tell the difference.[1] They can if they're using X :-) I gave Denim* a trial recently; it was unusable at 100Hz and fine at 1000. Yes, polling a tablet device is an interesting case where it matters. If you reread my last message carefully, you'll noticed that I suggested bumping up the default HZ a bit, since the overhead appears to be well into the noise even at 500 Hz. An alternative would be to implement a high-resolution timer facility similar to the Solaris cyclics implementation. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getting from bio to buf in dastrategy()
In message [EMAIL PROTECTED], Eno Thereska writes: in /sys/cam/scsi/scsi_da.c the dastrategy() function takes as an argument struct bio* bp Now I need to get to the struct *buf that bp belongs to. You can't do that, there may not be any struct buf. How can a bio exist on it's own, unrelated to any buf? Would that be a special case or does that happen all the time? A concrete example would help. struct buf represents a block in the cache/VM system. struct bio represents a disk I/O request. For historical reasons, a buf contains a bio, but that is by no means the only way to create a bio. Throughout geom bio's are created a destroyed which have no relation to any specific buf, for instance to read the key sectors in gbde. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
On Fri, Aug 08, 2003 at 06:03:38PM +1000, John Birrell wrote: On Fri, Aug 08, 2003 at 09:44:08AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], John Birrell writes : I'm not convinced that any hacking is required other than passing the device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says. I traced the boot on my system and the MMCR is initialised early (when the Timecounter ELAN output occurs). Immediately following that initialisation, 'pcib' is added as a child of 'nexus'. I don't see why 'mmcr' couldn't be added as a child of 'nexus' too. At this point, nexus isn't walking through it's children so there shouldn't be a problem. Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'. This seems straight forward. Maybe I'm missing something. 8-) That's my take too. And MMCR belongs on nexus not on legacy from an architectural point of view. It turns out that my comment about device_t parent being passed into nexus_pcib_is_host_bridge (in STABLE) was a bit off target. I found that if I created a device elanmmcr that would attach to nexus and implement a bus, the code in nexus_pcib_is_host_bridge that detects the host to PCI bridge only needs to warn if there is no elanmmcr device in the kernel. It doesn't need to initialise the Timecounter since it can rely on the elanmmcr doing that. The elanmmcr device can grok the PCI config to see the host to PCI bridge itself in it's identify method. Then the GPIO and flash devices can attach to elanmmcr. This all works fine in my experiment, up to the point where the child devices try to access their resources. Then it all ends in tears. I find (using STABLE as a base) that the elanmmcr device needs it's own add_child method because the nexus one doesn't get called. I guess that's because add_child methods aren't inherited? I've never implemented a bus driver before. 8-( I asume you need a call to bus_generic_attach after adding a bus child. But this thematic is still full of questions for me. Under 5.1-RELEASE the following in init_AMD_Elan_sc520(): devclass_t nexusdc = devclass_find(nexus); device_t nexus = devclass_get_device(nexusdc, 0); device_t dev = device_add_child(nexus, elanbb, -1); bus_generic_attach(dev); results in: [...] npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.00 Timecounter ELAN frequency 833 Hz pcib0: AMD Elan SC520 host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 elanbb1 at device 0.0 on pci0 hifn0 mem 0xa0001000-0xa0001fff,0xa000-0xafff irq 10 at device 16.0 on pci0 hifn0: Hifn 7951, rev 0, 128KB sram, 193 sessions [...] # devinfo nexus0 legacy0 pcib0 pci0 elanbb1 hifn0 ohci0 usb0 uhub0 ohci1 usb1 uhub1 sis0 miibus0 ukphy0 sis1 miibus1 ukphy1 sis2 miibus2 ukphy2 isa0 ata0 sio0 npx0 If someone has an explanation to this. The full change is available under http://www.cosmo-project.de/~bernd/elanbb.diff Having decided that an add_child method is required in the elanmmcr device, all the resource allocation and activation functions break. Grumble. What resources does your elanmmcr device manage? There is a lots of different stuff to manage: timers, pio pins, ... Just managing exclusive mmcr adresses will not be enough because different pio pins share registers. On the other hand it's questionable if those resources should be managed anyway. What I'm not sure of, is how many of the nexus methods (such as those for resource allocation) can be shared, and how many need to be implemented. Can anyone suggest a driver that is a suitable example? It's a bit like the three bears this one is too soft... and this one is too hard but where is the one that is just right? 8-) Nexus can't know about mmcr resource types. If you manage addresses then you'll need to allow sharing too. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
COW and mprotect on non-shared memory
Hi. I've noticed that in FreeBSD, the struct vm_map_entry has an
eflags member that can have the MAP_ENTRY_COW bit set.
In the vm_map_protect function, which is used by mprotect, it looks
like this bit is used to determine whether or not to set the page
table entries for write access or not:
if (current-protection != old_prot) {
#define MASK(entry) (((entry)-eflags MAP_ENTRY_COW) ? ~VM_PROT_WRITE : \
VM_PROT_ALL)
pmap_protect(map-pmap, current-start,
current-end,
current-protection MASK(current));
#undef MASK
}
... so if this vm_map_entry describes a VM region that is set for COW,
then the page table entries will not allow writes. If it's not COW,
though, the page table entries will be set to allow writes. Is that
correct so far?
The reason I'm interested in this is that I'm doing some VM work on
Linux, where they might have COW pages sprinkled throughout a VM
region. The Linux VM region descriptor analogous to FreeBSD's
vm_map_entry is the vm_area_struct, and it doesn't have any special
bit for COW.
In Linux, COW is recognizable only by the situation where for a given
page in a region of VM, the vm_area_struct has the VM_WRITE bit set
and the page table entry is write protected.
For that reason, when you mprotect an area of non-shared, anonymous
memory to no access and then back to writable, Linux has no way of
knowing that the memory wasn't set for COW before you make it
unwritable. It goes ahead and makes all the pages in the area COW.
That means that if I do this:
for (i = 0; i n; ++i) {
assert(!mprotect(p, pgsiz, PROT_NONE));
assert(!mprotect(p, pgsiz, PROT_READ|PROT_WRITE|PROT_EXEC));
p[i] = i 0xff;
}
... I get n minor page faults! Pretty amazing, but I guess they
figured nobody does that.
More surprising is that the same test program has the same behavior on
FreeBSD. (At least, the /usr/bin/time -l ... output shows the
number of page reclaims increasing at the same rate that I increase
the value of n in the loop.)
I thought that in FreeBSD any COW area would have its own vm_map_entry
with the MAP_ENTRY_COW bit set. That way, you could run this test
without any minor faults at all. Now I suspect I was incorrect.
Could anyone help clarify the situation for me?
Thanks.
--
--Ed L Cashin| PGP public key:
[EMAIL PROTECTED]| http://noserose.net/e/pgp/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds. - SOLVED
Hello folks. Some of you may remember my trouble with SI0680-based ULTRADMA ATA controller card. Well, the problem was obvivously the faulty card. After replacing it works fine. I don't know what magic Soeren has put in the SI driver, but unlike Windows it never crashed, never hang, it even tried to use UDMA modes. So kudos to Soeren for writing quality drivers like that one. I also remember Peter Kiesser has had some issues with drives falling back to PIO with SIS controller. I had this too on the drive that FreeBSD5.1_RELEASE used to start from. So now we know this can be an issue with a broken controller. (It doesn't fall back to PIO here after replacement is made). Again, thanks to Soeren it just magically worked (as best as it could obvivously) in spite of all the fish. That's all! Z ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getting from bio to buf in dastrategy()
Hi, To: Eno Thereska [EMAIL PROTECTED] Date: Mon, 04 Aug 2003 07:43:44 +0200 In message [EMAIL PROTECTED], Eno Thereska writes: Hi all, I am hacking into the FreeBSD 5.0 code. I jumped from using 4.4 to 5.0 and a couple of things have changed. Here is my question: in /sys/cam/scsi/scsi_da.c the dastrategy() function takes as an argument struct bio* bp Now I need to get to the struct *buf that bp belongs to. You can't do that, there may not be any struct buf. How can a bio exist on it's own, unrelated to any buf? Would that be a special case or does that happen all the time? A concrete example would help. Thanks Eno ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: porting a webcam
--- John-Mark Gurney [EMAIL PROTECTED] wrote: I wouldn't write a kernel driver for a camera and use ugen(4) instead. I am terribly sorry for posting this, but I cannot find documentation about implementing with ugen except for the man page. Does anyone indicate a good site? TIA PAulo Roberto __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: porting a webcam
Paulo Roberto wrote this message on Wed, Aug 13, 2003 at 17:23 -0700: --- John-Mark Gurney [EMAIL PROTECTED] wrote: I wouldn't write a kernel driver for a camera and use ugen(4) instead. I am terribly sorry for posting this, but I cannot find documentation about implementing with ugen except for the man page. Does anyone indicate a good site? Take a look at: http://groups.yahoo.com/group/usb-bsd/ That is the group that does most of the devel for USB. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
In message: [EMAIL PROTECTED] John Birrell [EMAIL PROTECTED] writes: : On Wed, Aug 06, 2003 at 05:50:45PM -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Poul-Henning Kamp [EMAIL PROTECTED] writes: : : In fact what you may want to do is hang the entire MMCR off the nexus : : as a bus, and hang the various drivers off that bus. : : I have a card based on the SC520 too. (Note to Warner: this is the card I : needed the higher port numbers for) I gotta get me one of these :-)... : I need to access the GPIO pins too. But before that, I need to get flash : drivers working. Access to the flash chips also requires the MMCR. Does : it really make sense to hang the flash devices off the MMCR bus when they : are mapped into ISA bus space? Well, I don't know. The PC Cards that we have in the system are mapped into the I/O and memory ranges traditionally reserved for the ISA bus. In ISA systems, this made sense because pccard was attached to pcic was attached to isa. However, now we have situations where pccard is attached to cbb which is attached to pci. There may be a isab device with isa bus hanging off of it that makes the relationship between the pccard devices cousins rather than nephews in the tree. And there isn't any harm from that. Wouldn't this be a similar situation? : From my reading of the AMD docs, only the CPU core is identifiable : via the CPUID instruction. The docs say that the first two bytes of : the MMCR are the REVID and those can be used to identify the device : itself. The second byte is set to zero to identify the product as : the ElanSC520 microcontroller. So if you know the MMCR is there, : you can go to that byte and get confirmation! Thanks AMD. It seems : that the discovery via the host to PCI bridge is the only reliable : way to go. Can you send me a URL for that document? I thought I understood things, but making sure by reading it would sure help. : My local hack is to make my flash drivers require the elan_mmcr : option and then they can just go use the elan_mmcr global : variable. I just need the elan device to be initialised earlier. But adding it as a child of nexus in the host bridge code wouldn't make it probe any earlier. To do that you'd need to make it a true child of nexus with a identify routine that would go out and try to find the host bridge at a certain address and use the right kind of bridge there to add the device. You could then map the mmcr space to a convenient location, and then dole it out to child drivers such that the bus_space macros would do the right thing. Since it is memory mapped, this would be relatively easy to do. This would also allow you to make it known earlier in the boot process. This is also very much analygous to what pccard and cardbus does. You wouldn't have the problems that we have with picking resources in the cardbus bridge code because it looks like the mmcr is at a fixed address (either by design of the chip or by phk's big stick). If you'd like, I can sketch out in code what I'm trying to say in words here. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[no subject]
Dear Sir, I'm required to run a.out binaries like foxplus in a recent Intel based hardware. I have chosen FreeBSD 5.1 and successfuly installed. But I could not run a.out binaries like Foxplus. I tried it by load ibcs modules and aout modules in /boot/kernel directory. My foxplus did not work. I require your suggestions regarding this. I may not use FreeBSD 2.1 version as I require driver for Adaptec 7902 (Ultra Wide SCSI 320). Please help me. Thanks, S.Gopinath Chennai, INDIA ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
In message [EMAIL PROTECTED], Bernd Walter writes: On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bernd Walter writes: I need to add I2C support for a Elan520 based soekris system. The system has the required GPIO pins and there is the iicbb driver to handle generic bitbang code - just needing a simple layer driver to enable, disable and read pins. But unlike normal isa/pci hardware probing the existence of the GPIO line is a bit difficult. The current elan-mmcr.c gets started from i386/pci/pci_bus.c at host bridge probing, because that's seems to be the only place to safely detect this special CPU. That's my doing, based on my reading of the datasheet from AMD. It would be better if we could detect the Elan in the normal CPU identification stuff, but I couldn't seem to find a reliable way. I could reread the datasheet, but don't give it much hope if you hadn't find anything usefull. From the logicaly standpoint the extensions had to be attached to nexus, but nowhere is the current code path there is a handle for nexus or any other device_t. In fact what you may want to do is hang the entire MMCR off the nexus as a bus, and hang the various drivers off that bus. What needs to be in *_probe() to conditionalize on elan existence? Well, my idea was to hang the mmcr bus on nexus when we find out it is an elan. It may be that you are not allowed to attach a bus to the nexus when we find out it is an elan in the host/pci bridge probe, but then I guess you could just hang it off that instead. Pressumably some newbus magic will then probe that bus. If its not an elan, there is no mmcr bus and nothing will get probed. I'm not the worlds greatest newbus specialist, so check this concept with somebody who know what they are talking about before you do it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM Gate.
On Thu, Aug 14, 2003 at 09:52:25PM +0400, Buckie wrote: BTW, QNX had this for a long time, it's called QNet in there. Allows transparently to mount or use anything in /dev. Even a soundcard! Whatever next? PCI-over-IP? *shudder* BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
On 08-Aug-2003 Bernd Walter wrote: On Fri, Aug 08, 2003 at 03:48:22PM -0400, John Baldwin wrote: On 08-Aug-2003 Bernd Walter wrote: On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote: Well, that would be a major pain on current since nexus is already finished attaching many of its drivers by the time it gets to here. Also, if you use ACPI and if ACPI exists, then this function _won't_ _ever_ _be_ _called_. If you use a hostb PCI driver, then it will work both for ACPI and legacy. I agree with this point and if I understood correct this is what John Birrel already had done. No, he is still working in the nexus/pcib driver's identify routine, not in a separate 'hostb' PCI driver. However - I would still like to know why device_add_child(nexus, elanbb, -1); results in an elanbb instance numer 1 connected to pci0. And why I don't get any iicbb childs. I would have to see your code changes in order to try to tell you that. http://www.cosmo-project.de/~bernd/elanbb.diff First off, the iicbb driver does not know have an elanbb attachment. You need a set of driver methods and corresponding DRIVER_MODULE(iicbb, elanbb, ...) For the iicbb child of elanbb to get a driver that probes it and attaches to it. Hmm, what you want to do is not hijack the legacy/pcib identify routine I think, but add an identify routine to your elanbb driver and have elanbb live off the nexus (so DRIVER_MODULE(elan, nexus)) and have its identify routine use pci_cfgreg() to get the devid for device 0 and if it is the right one call init_AMD_Elan_sc520() and add it's probe routine. Or rather. I've fixed all this and you can get the changes (whcih should fix bogus elanbb0 and make iicbb0 show up) at http://www.freebsd.org/~jhb/patches/elan.patch It includes your patch above but fixes a few things. One other bug I fixed is that since yout elan was hung off of pci and had an empty probe routine, any unclaimed PCI device got claimed by your elanbb driver, hence your bogus elanbb0. Note that the version of elanbb in elan.patch uses a private identify routine that calls init_AMD_Elan_sc250(), so it will work both with and without ACPI. However, the warning printf about CPU_ELAN won't show up with ACPI. I left the printf in pci_bus.c for now. A better place to put it would be in the hostb driver itself. Well, I went ahead and did that too, so now the warning will show up both for ACPI and non-ACPI systems. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: porting a webcam
Bernd Walter wrote this message on Fri, Aug 08, 2003 at 18:06 +0200: On Fri, Aug 08, 2003 at 07:56:26AM -0700, Paulo Roberto wrote: * You guys think it is too difficult and I should just give up due to my lack of experience? And if I manage to code properly, is it too bureaucratic to get it into the FreeBSD kernel? I wouldn't write a kernel driver for a camera and use ugen(4) instead. The state of ugen is similar in 4.x and 5.x so you don't have to worry about a special version. The most important part is getting informations about the protocol used by your camera. I second this. Another feature of using the ugen userland interface is that you will get portability to Net/Open for free, and you won't have to rewrite for -stable/-current either. I believe that isochornous transfers do not work on -stable currently. Now that PAE has been back ported to -stable, I will be working on back porting the usb and busdma changes to -stable. This would also include the isochornous support fixes. (btw, isochronous support was working in 4.5-stable) I have started work on defining a new multimedia interface, but I would go ahead and write your driver and not wait for this. I'm a bit busy, and haven't worked on it recently. Another advantage of doing a userland program is that you can make a simple port out of it, and don't have to work to get it into the kernel. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Missing system call in linux emulation ( patch )
On Thu, 14 Aug 2003, Steven Hartland wrote: I've created a patch for the linux emulation which adds a dummy for the exit_group syscall along with defining all functions up to 252 this fixes a crash in the BattleField 1942 server. How do I go about getting this into the various FreeBSD streams so others can benifit. File a PR, please. BTW, I saw this on the OpenBSD source-changes list recently and remembered the missing system call thread here: CVSROOT:/cvs Module name:src Changes by: [EMAIL PROTECTED] 2003/08/14 12:34:15 Modified files: sys/compat/linux: syscalls.master Log message: add more syscalls. implement exit_group (which is actually an alias for sys_exit), needed for newer glibc's binaries. from marius aamodt eriksen marius at monkey dot org Assuming that this is the right approach to solving the problem, we could probably pull that change into our linux emulator. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
On Fri, Aug 08, 2003 at 02:35:36PM +0200, Bernd Walter wrote: What resources does your elanmmcr device manage? There is a lots of different stuff to manage: timers, pio pins, ... Just managing exclusive mmcr adresses will not be enough because different pio pins share registers. On the other hand it's questionable if those resources should be managed anyway. My main focus is on the flash drivers. For them I need ISA hints. The MMCR registers are required to access the flash controller. The flash maps into the same memory space as the ISA devices, so I keep asking myself why they can't _just_ _be_ _ISA_ _devices_. I'm still working on a STABLE source base because I need the stability that provides. So the legacy device isn't an option. I've looked at what I need to do to support the ISA style resources that the flash drivers need if the mmcr is implemented as a bus. I don't see the need to cobble up code for managing the resources in an MMCR pseudo-bus when they are perfectly well implemented in the ISA code. For my purposes, I find that I can leave PHK's elan-mmcr stuff virtually as it is and just get my flash drivers to check the MMCR map pointer in their probes to determine if on an Elan SC520. When it comes to writing to the MMCR, the option CPU_ELAN code can just provide a function to do that. I see no need to write more code than is absolutely required. The bus stuff is neat when it works in your favour, but in this case it's just a hassle. The SC520 is intended as a chip for embedded systems. I don't want/need any bells and whistles when I've only got 2 executables in the entire operating system (the kernel and init). I'll go the simple way. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Fw: your mail
- Original Message - From: S.Gopinath [EMAIL PROTECTED] To: Kris Kennaway [EMAIL PROTECTED] Sent: Thursday, August 14, 2003 7:39 PM Subject: Re: your mail Dear Sir, As per your suggestion, I installed the packages Compat 2.x, 3.x, and 4.x But still I'm unable to use Foxplus which is a a.out binary. Here is what I get -- -- -- $ foxplus /usr/lib/foxplus/no87: 1: Syntax error: newline unexpected (expecting )) /usr/lib/foxplus/foxplus.pr: 1: Syntax error: word unexpected (expecting )) $ file /usr/lib/foxplus/no87 /usr/lib/foxplus/no87: Microsoft a.out separate pure segmented word-swapped V2.3 V3.0 286 small model executable Large Text Large Data $ file /usr/lib/foxplus/foxplus.pr /usr/lib/foxplus/foxplus.pr: Microsoft a.out separate pure segmented word-swapped not-stripped V2.3 V3.0 386 small model executable not stripped $ -- -- - Please suggest. Thanks, S.Gopinath - Original Message - From: Kris Kennaway [EMAIL PROTECTED] To: S.Gopinath [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, August 14, 2003 6:25 PM Subject: Re: your mail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM Gate.
On Thu, Aug 14, 2003 at 01:03:27PM +0200, Pawel Jakub Dawidek wrote: Hello hackers... I've done something what will be called GEOM Gate. This software provide disk devices mounting through the network. http://garage.freebsd.pl/geom_gate.tbz Cute...! reminds me of RFS on SysV. W/ -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
3Com 3C940 gigabit ethernet adapter
While poking around looking for support for this chip on the ASUS P4P800, I happened to find that our friends over in OpenBSD-land have added support for the 3c940, which is a variant of the SysKonnect Marvell chipset. This seems to have been added in r1.32 of if_sk.c in the OpenBSD sources. If you have some hardware, you may wish to poke into this. Good luck. -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Missing system call in linux emulation
Hmm I couldn't even find these until I got to 2.5.X kernel so most strange they would be using these but I'll contact the dev at DICE to double check. Thanks for the info. Steve / K - Original Message - From: Marcel Moolenaar [EMAIL PROTECTED] To: Steven Hartland [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 5:56 PM Subject: Re: Missing system call in linux emulation On Tue, Aug 12, 2003 at 05:42:51PM +0100, Steven Hartland wrote: Any one know how I can track down what function is missing and hence look at fixing it? In the linux kernel source tree, look in arch/i386/kernel/entry.S. There you'll find all the syscall entry points. Currently they go all the way to 271. Also look at arch/alpha/kernel/entry.S... Then, in /sys/i386/linux look in syscalls.master. There you'll see we only have syscalls up to 221. See also /sys/alpha/linux... One could: o Add proper prototypes to syscalls.master of the 50 new syscalls we don't know about, o Declare all these syscalls as dummies (see linux_dummy.c) to begin with, o Really implement those syscalls that are used in practice. Syscall 252 is exit_group(2). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible deadlocks?
On Mon, Aug 11, 2003 at 03:50:26PM -0700, Ted Unangst wrote: On Mon, 11 Aug 2003, John Baldwin wrote: Also, SK_LOCK != SK_IF_LOCK, or is that a typo? If it is a typo, then the lock order should still be fixed in some fashion. They are the same. SK_IF_LOCK is called on the sk_if_softc, but just locks the shared sk_softc mutex. Does that make sense? #define SK_LOCK(_sc)mtx_lock((_sc)-sk_mtx) #define SK_IF_LOCK(_sc) mtx_lock((_sc)-sk_softc-sk_mtx) This strikes me as a particularly poor selection of macros. They look like they are different locks and I'm sure John won't be the only person who gets caught believing they really are different. Getting locking right is difficult enough without having the same lock called different things in different places. This is an area where C++ would be cleaner - you have two (inline) functions with the same name and the compiler picks the appropriate one based on the argument type. Failing that, I think the code would be cleaner without the macros or with SK_IF_LOCK() references replaced by SK_LOCK(). Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: your mail
On Thu, Aug 14, 2003 at 03:14:27PM +0530, S.Gopinath wrote: Dear Sir, I'm required to run a.out binaries like foxplus in a recent Intel based hardware. I have chosen FreeBSD 5.1 and successfuly installed. But I could not run a.out binaries like Foxplus. I tried it by load ibcs modules and aout modules in /boot/kernel directory. My foxplus did not work. I require your suggestions regarding this. Do you have the FreeBSD 2.x/3.x/4.x compatibility libraries installed (via sysinstall, or by setting the appropriate COMPAT* variable in /etc/make.conf)? If so, then please post an exact description of the commands you have run and the errors you receive. Kris pgp0.pgp Description: PGP signature
Driver to Driver Communication
Hi All, Could anybody help me to know how a driver to driver communication is done in FreeBSD ? My exact problem is something like this. In the current implementation of scsi_target mode driver, there is a associated userland application polling the target device and data is read from target device to user space and then written to a file. In stead, I want to do it in the scsi_target driver itself such that all I/O queues are redirected to a disk device. For this purpose, How can I interface with the scsi disk driver i.e. scsi_da.c from the scsi_target driver? Thanks Regards, Jaya SMS using the Yahoo! Messenger;Download latest version. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Why is ATAPI DMA disabled by default ?
I use 5.1-current and have found that by default FreeBSD disables ATAPI's support for DMA transfers and thus uses CPU hungry PIO modes. It even makes sysctl used to change this read-only. I had changed the default value of atapi_dma to 1 in dev/ata/atapi-all.c to 1 and it worked fine for me. Can someone explain why it is disabled? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is ATAPI DMA disabled by default ?
It seems Maxim Konovalov wrote: I use 5.1-current and have found that by default FreeBSD disables ATAPI's support for DMA transfers and thus uses CPU hungry PIO modes. It even makes sysctl used to change this read-only. I had changed the default value of atapi_dma to 1 in dev/ata/atapi-all.c to 1 and it worked fine for me. Hint: put hw.ata.atapi_dma=1 in /boot/loader.conf. Or just use atacontrol to change the mode once the system is running... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM Gate.
On Thu, Aug 14, 2003 at 01:03:27PM +0200, Pawel Jakub Dawidek wrote: This software provide disk devices mounting through the network. maaan you're amazing. i hope some day you'll write remote terminal emulator. that would be great. -- klub milosnikow czeskiego techno ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Broadcom 440x
Would be more than willing to help with testing and if there is any coding I can help with I will give it a try (Never done a *nix driver before). My laptop is a Dell Inspiron 8500 for the record. Regards Michael Day Electrical Engineer Paterson Flood Engineers Tel: +61 7 3871 0533 Fax:+61 7 3871 0538 Mob: +61 400 369 355 Email: [EMAIL PROTECTED] Web: www.pfe.com.au -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg 'groggy' Lehey Sent: Wednesday, 13 August 2003 13:19 To: [EMAIL PROTECTED]; Michael Day Cc: [EMAIL PROTECTED] Subject: Re: Broadcom 440x On Wednesday, 13 August 2003 at 10:36:01 +1000, Michael Day wrote: Hi all. A few months ago I saw that some people were having probs finding a driver for the 440x network card installed on some onboard motherboards. Has anyone had any luck in finding drivers for these cards as I now have a dell laptop that I can\222t connect to the network (Not very useful). If anyone is aware of drivers for either the 4.x or 5.x strands of freebsd I would be most interested Duncan Barclay is working on a driver, but it's not finished yet. Do you want to help? Which model laptop do you have? Greg -- See complete headers for address and phone numbers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing number of buffers in BSD4.4
On Thu, Aug 14, 2003, Eno Thereska wrote: In McKusick's book The design and Implementation of the 4.4BSD Operating system, in the Buffer Management subsection of the I/O system overview, there is a a sentence that says ...depending on available memory, a system is configured with from 100 to 1000 buffers.. referring to the number of struct buf* in the integrated VM/IO buffer cache. I have plenty of RAM in my computer, but it seems like there are always 1000 buffers configured (empirical observation, if I try to allocate one more after that the system freezes). How do I increase the nubmer of buffers? More consicely, how do I allocate more memory to the buffer management subsystem? In FreeBSD, you get 1 buffer for every megabyte of memory up to 64 MB of RAM, and 1 buffer for every 2.5 megabytes after that. See kern_vfs_bio_buffer_alloc() in vfs_bio.c. On i386 and amd64, there's a cap of about 1000 due to KVA limits, although that cap should not be needed for amd64. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PR bin/55539] getfsent(3) and spaces in fstab
Could somebody please review my patch - if there are no objections (but I am sure there are some more details that can be improved), I will write a PR. I have filed a PR in order to preserve this patch. It can be found here: http://www.freebsd.org/cgi/query-pr.cgi?pr=55539 Regards, Simon signature.asc Description: Digital signature
Re: Missing system call in linux emulation
Marcel Moolenaar wrote: On Tue, Aug 12, 2003 at 05:42:51PM +0100, Steven Hartland wrote: Any one know how I can track down what function is missing and hence look at fixing it? In the linux kernel source tree, look in arch/i386/kernel/entry.S. There you'll find all the syscall entry points. Currently they go all the way to 271. Also look at arch/alpha/kernel/entry.S... Then, in /sys/i386/linux look in syscalls.master. There you'll see we only have syscalls up to 221. See also /sys/alpha/linux... One could: o Add proper prototypes to syscalls.master of the 50 new syscalls we don't know about, o Declare all these syscalls as dummies (see linux_dummy.c) to begin with, o Really implement those syscalls that are used in practice. Syscall 252 is exit_group(2). Most of them are of the sime kind of immature API as for example the whole Linux kvect trash. Don't worry it's very unlikeley they will ever be seriously used and it will be a long time still until kernel 2.6 first will be released at all and second widely deployed. I would vote for dealing with them case by case. Thus keeping to the paramount principle of: don't do interfaces on the heap. FYI, ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic during nfs operations in 4.8S on Dell 2650
On 12 Aug 2003, at 9:44, Mark Powell wrote: On Fri, 8 Aug 2003, Andrew Kinney wrote: On 8 Aug 2003, at 11:52, Mark Powell wrote: #6 0xc0312ea3 in generic_bzero () FWIW, I think this is where the problem occurred. Probably tried to zero a page that didn't exist because of a failed KVA allocation. We had several panics on one of our 4GB machines at the same point. Our solution was to increase the KVA space to 2GB from 1GB and rebuild the whole world with the new KVA setting. The panics disappeared. Yep, that was it. Well I upped KVA_PAGES from the default of 260 (in LINT?) to 384 and rebuilt the kernel. Sysctl shows it now has plenty to spare when running the rsyncs. Why did you have to rebuild world when changing this and not just the kernel? Well, it's been awhile since I did this, but it seems like we were having some trouble with some applications or system utilities. It could have just been that we had some stuff out of synch on that system since it had been upgraded from 4.5-RELEASE to 4.7- RELEASE and then to 4.8-RELEASE. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Pent@NET drivers for FreeBSD
Hi, FreeBSD hackers! Is there some ongoing work on drivers for [EMAIL PROTECTED] and other DVB cards from http://www.pentamedia.com? Any efforts to port Linux drivers? If no, what DVB card is preferable for production use with FreeBSD? TNX, -- WBR, Alex Lukin, RIPE NIC HDL: LEHA1-RIPE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 3Com 3C940 gigabit ethernet adapter
On Tue, Aug 12, 2003 at 12:52:43PM -0700, Wes Peters wrote: While poking around looking for support for this chip on the ASUS P4P800, I happened to find that our friends over in OpenBSD-land have added support for the 3c940, which is a variant of the SysKonnect Yes, a patch had been floating around for some time already. Marvell chipset. This seems to have been added in r1.32 of if_sk.c in the OpenBSD sources. If you have some hardware, you may wish to poke into this. I will, given some time, and reasonable temperatures. 35gr C is too hot yuck for .nl Wilko -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic during nfs operations in 4.8S on Dell 2650
On Tue, 12 Aug 2003, Andrew Kinney wrote: Well, it's been awhile since I did this, but it seems like we were having some trouble with some applications or system utilities. It could have just been that we had some stuff out of synch on that system since it had been upgraded from 4.5-RELEASE to 4.7- RELEASE and then to 4.8-RELEASE. Ok. Many thanks for the pointer. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Possible patch for vm/vm_glue.c
On 11-Aug-2003 Rui Lopes wrote: Hello, I've been reading vm_glue.c and I think I've found a bug regarding the lock of `proc.p_sflag' inside `scheduler' function. From proc.h, int p_sflag; /* (j) PS_* flags. */ and (j) - locked by sched_lock mtx; but the access is done without having the lock. Take a look at the attached patch and tell me if this is ok. Patch made against $FreeBSD: src/sys/vm/vm_glue.c,v 1.172 2003/05/13 20:36:02 jhb Exp $, but this is also present in current 1.182. The lock isn't needed in this case for these flags because the proc lock is already held and for these flags, both the proc lock and sched lock are always held when they are set or cleared, so only one of those locks have to be held to check the flags. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic during nfs operations in 4.8S on Dell 2650
On Fri, 8 Aug 2003, Andrew Kinney wrote: On 8 Aug 2003, at 11:52, Mark Powell wrote: #6 0xc0312ea3 in generic_bzero () FWIW, I think this is where the problem occurred. Probably tried to zero a page that didn't exist because of a failed KVA allocation. We had several panics on one of our 4GB machines at the same point. Our solution was to increase the KVA space to 2GB from 1GB and rebuild the whole world with the new KVA setting. The panics disappeared. Yep, that was it. Well I upped KVA_PAGES from the default of 260 (in LINT?) to 384 and rebuilt the kernel. Sysctl shows it now has plenty to spare when running the rsyncs. Why did you have to rebuild world when changing this and not just the kernel? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
lock order reversal - in many places
I get this often now with 5.1-current on my Dell Inspiron 8000 notebook but I tend to believe it's not notebook related: This seemed to occur when the nvidia.ko module is loaded: Aug 11 11:15:58 kukubook kernel: nvidia0: GeForce2 Go mem 0xe000-0xe7ff,0xfc00-0xfcff irq 11 at device 0.0 on pci1 Aug 11 11:16:02 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:02 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:02 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:02 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:02 kukubook kernel: malloc() of 4096 with the following non-sleepable locks held: Aug 11 11:16:02 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:03 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:03 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:03 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:03 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:03 kukubook kernel: malloc() of 4096 with the following non-sleepable locks held: Aug 11 11:16:03 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 4096 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of VM OBJECT with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of DP fakepg with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex ctl.mtx_api r = 0 (0xc2c1e18c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 4096 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 32 with the following non-sleepable locks held: Aug 11 11:16:04 kukubook kernel: exclusive sleep mutex dev.mtx_api r = 0 (0xc2a6818c) locked @ /home/home/kuku/NVIDIA-FreeBSD-x86-1.0-4365/src/nvidia_subr.c:753 Aug 11 11:16:04 kukubook kernel: malloc() of 32 with
Re: How to get a device_t
On Fri, Aug 08, 2003 at 03:48:22PM -0400, John Baldwin wrote: On 08-Aug-2003 Bernd Walter wrote: On Fri, Aug 08, 2003 at 02:27:30PM -0400, John Baldwin wrote: Well, that would be a major pain on current since nexus is already finished attaching many of its drivers by the time it gets to here. Also, if you use ACPI and if ACPI exists, then this function _won't_ _ever_ _be_ _called_. If you use a hostb PCI driver, then it will work both for ACPI and legacy. I agree with this point and if I understood correct this is what John Birrel already had done. No, he is still working in the nexus/pcib driver's identify routine, not in a separate 'hostb' PCI driver. However - I would still like to know why device_add_child(nexus, elanbb, -1); results in an elanbb instance numer 1 connected to pci0. And why I don't get any iicbb childs. I would have to see your code changes in order to try to tell you that. http://www.cosmo-project.de/~bernd/elanbb.diff -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sysctl kern.ipc.shm* description ?
Is there a good explanation of what those variables are and the dangers/advantages of changing them ? I ask because I determined one port (multimedia/nuppelvideo) needs more shared memory to run (on my system). But when I changed some of the kern.ipc.shm* sysctl, the program ran for 15 sec and then the system froze and rebooted after a couple seconds. bruno ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
porting a webcam
Hello, I am about to code my first kmod. I am trying to port an usb camera to FreeBSD, and since I am new at system development, I hope you don't mind helping me out. If this is not the correct list I should post, please point me what list I should post to. I got a few questions: * Does the 5 series differs too much to from the 4-stable to write a device driver? I am planning to code for 4.8 (the one I am using now) and I wonder how hard would it be to port it later to the 5 series. * I am reading the developers handbook, is there another good reference recommended? Any good point of reference for usb/camera protocols/device drivers? * You guys think it is too difficult and I should just give up due to my lack of experience? And if I manage to code properly, is it too bureaucratic to get it into the FreeBSD kernel? thanks, Paulo Roberto __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : On Wed, Aug 06, 2003 at 05:52:57PM -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Bernd Walter [EMAIL PROTECTED] writes: : : Back to the original question: : : How do I get the device_t from nexus? : : You don't. You are assigned one. : : : Is there a get_nexus() function somewhere? : : No. You don't need it. : : Chances are you could create an identify routine that would attach the : bus to. The identify routine should be all you need. : : The point is that this special CPU can only be identified by its : host bridge. : That's the place were the MMCR bus has to be attached to nexus, so : we need the handle within this function. Then why not just hang the bus off the host bridge? There's really no compelling reason to have it on the nexus. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
On Wed, Aug 06, 2003 at 06:37:10PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : On Wed, Aug 06, 2003 at 05:52:57PM -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Bernd Walter [EMAIL PROTECTED] writes: : : Back to the original question: : : How do I get the device_t from nexus? : : You don't. You are assigned one. : : : Is there a get_nexus() function somewhere? : : No. You don't need it. : : Chances are you could create an identify routine that would attach the : bus to. The identify routine should be all you need. : : The point is that this special CPU can only be identified by its : host bridge. : That's the place were the MMCR bus has to be attached to nexus, so : we need the handle within this function. Then why not just hang the bus off the host bridge? There's really no compelling reason to have it on the nexus. The host bridge is not available yet at probing time of the host bridge. What we have is the host bridges parent (nexus) in the calling function. Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or we find it out later. I thought it would be cleaner to not extend nexus_pcib_is_host_bridge arguments for a specialised case. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
On Wed, Aug 06, 2003 at 08:39:37PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] John Birrell [EMAIL PROTECTED] writes: : On Wed, Aug 06, 2003 at 07:45:32PM -0600, M. Warner Losh wrote: : The SC520 has onboard support to control 3 flash chips. : The board I have has 2 Mb NOR flash chip containing BIOS plus a DOS : file system (at the moment) where I keep a copy of an etherboot : executable. The board also has a 64Mb NAND flash chip which I've : written a FreeBSD UFS image into. Our standard bootloader happily : loads the kernel from that. Now I need to get a flash driver working : for the root file system. I've got an existing read-only flash driver : that I used to use on an Intel 386EX board, but that had the entire : flash chip memory mapped. This new board maps the NAND flash in 4K : pages. That would be very very cool. There's a number of new SBCs that I've seen that have this sort of setup. Timing Solutions might be very interesting in something like this because we're currently buying CF cards to do our OS. The soekris board seems to be designed to boot from soldered flash too. At least there is PCB place under the CF socket that looks like flash pads. : If you have time, I'd be interested. This is a hot topic for me because : it is exactly where I'm up to. I have everything else working on the : board. I'm thinking that it wouldn't take too long. Lemme see what I can throw together. It would be a sketch only... That would be great. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : The host bridge is not available yet at probing time of the host bridge. : What we have is the host bridges parent (nexus) in the calling function. : Either we hand out the parents device_t to nexus_pcib_is_host_bridge, or : we find it out later. Don't you mean legacy_pcib_is_host_bridge? That's where the matching is done in current right now (well, at least as of my last sync) If so, passing the host bridge's device down to it would be trivial to add. It would also allow other CPUs with builtin host bridges to do similar tricks to the one that is done for the ELAN. These sorts of features have been very common in other CPU families, and there's no reason to think that there won't be more of them in the x86 family as time goes on. I'm not sure that adding it to nexus at this stage of the boot would truly work. Since the legacy device has decided to attach, the nexus bus is already walking through its children. Adding a child during that walk strikes me as dangerous, since we have no locking on the children element of the device_t. Hmmm, looks I just found a source of problems in my newbus locking code that might explain some weird things happening when I enable it Thanks for making me go look :-) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to get a device_t
In message [EMAIL PROTECTED], Bernd Walter writes: On Wed, Aug 06, 2003 at 12:45:43PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bernd Walter writes: On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bernd Walter writes: From the logicaly standpoint the extensions had to be attached to nexus, but nowhere is the current code path there is a handle for nexus or any other device_t. In fact what you may want to do is hang the entire MMCR off the nexus as a bus, and hang the various drivers off that bus. What needs to be in *_probe() to conditionalize on elan existence? Well, my idea was to hang the mmcr bus on nexus when we find out it is an elan. Back to the original question: How do I get the device_t from nexus? Is there a get_nexus() function somewhere? That's were I don't know enough newbus :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: x86 Disassembler
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : On Tue, Aug 12, 2003 at 05:18:12PM -0400, Ryan Sommers wrote: : Are there any tools to disassemble an x86 binary file? objdump does a nice : job on most files. However, I'm messing with some machine-code binary : files that don't have ELF headers or anything other then the machine-code : (ie MBR's). I'd like to disassemble them on FreeBSD, possibly to a format : that G(as) could reassemble. Then I don't have to use something like : debug.exe. : If you need something more elaborate, try the trial version of DataRescue's : IDA. The console version works well under WINE. sourcer even runs with doscmd last time I checked. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: x86 Disassembler
On Tue, Aug 12, 2003, Ryan Sommers wrote: Are there any tools to disassemble an x86 binary file? objdump does a nice job on most files. However, I'm messing with some machine-code binary files that don't have ELF headers or anything other then the machine-code (ie MBR's). I'd like to disassemble them on FreeBSD, possibly to a format that G(as) could reassemble. Then I don't have to use something like debug.exe. One kludge that may work is to use objcopy --add-section to insert the machine code into an ELF file. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
