RE: Sharing data between user space and kernel
>sleeping(). What you probably want to do is >actually allocate wired kernel pages and export them to >userspace. Take a >look at the GEOM gstat(8) implementation, which does >exactly that. >However, you have to make sure that if you ever decide >to reuse that >kernel memory for something else (i.e., free it back to >the allocator), >you've GC'd all userspace references to it. Could you please point me to the place where "GEOM gstat" is implemented ? I don't seem to find it :-( Thanks a lot, neo Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: smartmontools vs HP Smart Array 642 controller
On Thu, Feb 24, 2005 at 03:24:17PM -0600 I heard the voice of Chris Dillon, and lo! it spake thus: > > Your problem with smartmontools doesn't seem to be limited to the > Smart Array 642, I just tried it on a DL380 G3 with the Smart Array > 5i+ and got the same error you did. It appears to be a > driver-specific problem. It's been failing on me on RELENG_5 since I updated from ~5.1 to ~5.3+, on an ahc controller: (pass5:ahc1:0:5:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass5:ahc1:0:5:0): CAM Status: SCSI Status Error (pass5:ahc1:0:5:0): SCSI Status: Check Condition (pass5:ahc1:0:5:0): UNIT ATTENTION asc:29,3 (pass5:ahc1:0:5:0): Bus device reset function occurred device Test Unit Ready [Operation not permitted] and the like. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4bsd.c Quantum change
On Thu, 24 Feb 2005 16:49:59 -0800, Ashwin Chandra <[EMAIL PROTECTED]> wrote: > Quick question for you hackers! > > If i wanted to change the scheduler to have a certain marked bad process have > a higher time quantum than everyone elses (because it is behaving bad, high > mem usage and context switching) to let it run longer to finish faster and > avoid context switches and swapping, is this possible in the current > scheduler without major changes to it? Right now the scheduler works by > having a uniform quantum for all processes, am i correct? anything wrong with nice(1)? -- If I write a signature, my emails will appear more personalised. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: giving up on 1 buffers error messsage
Although I am not exactly an expert on the field, I'll try to explain. The disk write procedures should wait for the disk to be ready, and this involves (soft)interrupts. When rebooting, the system can only wait for the device drivers to empty the write buffers, since it is not in interrupt context. If, for some reason, a disk device does not empty its buffer after some time, you will receive this "give up" message. In your case, one last buffer did not get to its destination, but 53 did. I get this message mostly on hard disk failures or panics related to disk devices. Note that sync will not solve the problem. What sync does is exactly what the reboot is doing: asks the system to empty its buffers. The only difference is that sync() does not wait for return. Indeed, this was the behaviour on pre-softupdate ages, this may not be true anymore. ;-) Andriy Tkachuk wrote: It is interesting why threre is no answer for this question so long time, regardless that it was posted 2 times :) For me it is also interesting to get the answer for this question since from time to time i also confused by such msgs on shutdown. syncing disks... 54 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up on 1 buffers Hi, I am referring to the message when the code in kern_shutdown.c in bsd 4.10 is called at the time of boot() system call My understanding is that this message tells us that 1 buffer from the buffer cache was not successfully flushed to disk, since the last call to sync(). Is that right? In that case what happens to this buffer? Is it discarded and assume that fsck will fix this on reboot? Since the syncer process runs periodically, can this error message be avoided if we wait long enough to guarantee flushing to disk (I have tried with DELAYS upto 30 seconds but I still get the error sometimes). I am actually trying to use this same code at a different point in time (not during shutdown, but to take a checkpoint), so I am not sure if that contributes to this error message? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" Jonny -- João Carlos Mendes Luís - Networking Engineer - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Install Free BSD without floppy, without bootable CD-ROM-drive, without boot from LAN etc.
On Fri, 25 Feb 2005 11:50:47 +0300 àÒÉÊ <[EMAIL PROTECTED]> wrote: > Hardvare configuration: > Compaq 5280 > Intel Pentium 120MHz > 80Mb RAM > 4,3 Gb HDD Hitachi > CD-ROM -8x Panasonic (I CAN NOT boot from it) > > NO able boot from LAN, NO FDD, > 2,5" HDD - I can't connect this HDD to desktop and install FreeBSD on > it. there are a few more options : - use a laptop-hdd-2-IDE converter (i have one and it works well!) - ask a friend with a laptop which has a cdrom, and put your hdd in that laptop during install and after install put it back in your laptop ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Install Free BSD without floppy, without bootable CD-ROM-drive, without boot from LAN etc.
Hello hackers, I wrote to @questions, but as result, I have advised to address the help to you. Sorry, if I spend your time I have notebook IP-120MHz without FDD He is NOT BOOT from CD. How can i install FreeBSD on it? Hardvare configuration: Compaq 5280 Intel Pentium 120MHz 80Mb RAM 4,3 Gb HDD Hitachi CD-ROM -8x Panasonic (I CAN NOT boot from it) NO able boot from LAN, NO FDD, 2,5" HDD - I can't connect this HDD to desktop and install FreeBSD on it. I try to load a kernen from DOS-partition usin "bsdboot.com kernel", but it have called a panic because of impossibility to mount root partition BUT I read in file /tools/00_index.txt (line 1): setup.exe Prepare for installation from a DOS partition. I hope it help me, but I can not FOUND IT - I can't found setup.exe in the installatoin CD-ROM, in the ftp-server on freebsd.org Where I can found this utilite??? Whether there is any other way of installation? How can i install FreeBSD? -- Best regards, Юрий mailto:[EMAIL PROTECTED] P.S. Sorry for my English. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc question
On 2005-02-25 11:34, Kathy Quinlan <[EMAIL PROTECTED]> wrote:
>Daniel O'Connor wrote:
>>On Thu, 24 Feb 2005 17:57, Kathy Quinlan wrote:
>>> ATM it is written in codevisionAVR which is where the function is
>>> called, so I guess for now I will just break the AVR support;)
>>
>> Ahh..
>> So.. are you talking about getting the coding running _in FreeBSD_ or
>> compiled on FreeBSD and running on an AVR?
>
> I am talking about getting the same code running under FreeBSD AND the
> AVR with minimal changes.
The easiest way is to hide the differences of the two platforms under a
properly designed abstraction layer. IIRC, it was putchar() that was
giving you trouble. Don't call it as putchar(), then. Write a wrapper
function, which gets properly defined either for either system. The
header that defines the wrapped functions' API can be common, i.e.:
#ifndef __WRAPPER_H
#define __WRAPPER_H
#ifdef __cplusplus
extern "C" {
#endif
int sendbyte(int val);
#ifdef __cplusplus
}
#endif
#endif /* __WRAPPER_H */
The implementation of the sendbyte() function may be in either a common
file sprinkled with #ifdef's for othe various platforms, or in separate
files that are conditionally added to the build depending on the current
platform.
I hope this helps,
Giorgos
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
iSCSI initiator driver beta version, testers wanted
hi, drop me a line if you are willing/interested in trying out the iSCSI initiator driver. Also if you are willing to just look at it and provide some feedback. So far I have tested it against: NetAPP, Intransa and Linux, so if you have other targets it would help. BTW, I've been using 5.3 rel, both UP and SMP processors. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Driver Update Disk discussion
On Thu, 2005-Feb-24 17:59:19 -0700, Scott Long wrote: >- kernel option support. How do we support vendor modules in a kernel >that might be compiled with PAE (rather common these days), SMP, MAC, >etc. The loader and /boot infrastructure has no concept of this. It's >highly important, though. AFAIK, PAE is only relevant on iA32. I second the suggestion that PAE be treated as a distinct architecture for these purposes. INVARIANTS and WITNESS are the other options that impact ABI. These are probably unnecessary on -RELEASE but it would be nice if people could build a kernel with WITNESS and not have it panic if they loaded a module that wasn't compiled with WITNESS (which I think it the current behaviour). >- kernel api/abi. We are trying to keep the kernel api/abi stable now, ... >don't have the right hash. Should we follow with something similar, or >should we have runtime checks that check symbol/structure signatures? It would be wonderful if we could have a mechanism that did load-time validation that the module was compatible with the kernel. Unfortunately, I don't think there's any sane way to verify data structure compatability. (Verifying function call APIs is reasonably easy). Run-time checking adds overheads which may be significant for commonly used interfaces. >Or should we say that we make no guarantees about a binary-only module >working on anything but a -RELEASE kernel? At the very least we need to support errata branches. The RE team has expended a lot of effort to provide a mechanism to handle critical problems found post-release. We don't want to negate this by telling users that they have a choice of either using driver X or fixing hole Y. Unfortunately, in the rare case where an errata fix affects a kernel API/ABI, the change is probably critical to fixing the problem. This would require the FreeBSD fix to be co-ordinated with the driver vendor. I think that guaranteeing operation in -STABLE is probably impractical - though API/ABI changes would need to be flagged to vendors so they could test drivers for the next FreeBSD release. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: giving up on 1 buffers error messsage
It is interesting why threre is no answer for this question so long time, regardless that it was posted 2 times :) For me it is also interesting to get the answer for this question since from time to time i also confused by such msgs on shutdown. > > syncing disks... 54 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up on 1 > buffers > > > Hi, > > I am referring to the message when the code in kern_shutdown.c in bsd > 4.10 is called at the time of boot() system call > > My understanding is that this message tells us that 1 buffer from the > buffer cache was not successfully flushed to disk, since the last call to > sync(). Is that right? In that case what happens to this buffer? Is it > discarded and assume that fsck will fix this on reboot? > > Since the syncer process runs periodically, can this error message be > avoided if we wait long enough to guarantee flushing to disk (I have tried > with DELAYS upto 30 seconds but I still get the error sometimes). > > I am actually trying to use this same code at a different point in time > (not during shutdown, but to take a checkpoint), so I am not sure if that > contributes to this error message? > > > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
