Re: mount_mfs panics (Was: ``65536-byte tape record bigger than suplied buffer'')
On Wed, May 19, 1999 at 10:16:52PM -0500, Joel Ray Holveck wrote: > >> Well, I'll recheck mine... > > It'd be interesting to see if you (and others) can reproduce this too. Fwiw, my home system (and that of a few others' as well) has been fixed by Luoqi's commit to kern_conf.c on the 18th. Cheers, -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
USB home page update
I've added two new sections to the USB home pages. http://www.etla.net/~n_hibma/usb/usb.pl One is the section on the project status. The most significant change is that it is an included document I can edit at home and upload once in a while. Much easier. The second thing is more down the page: a list of patches I have not been able to commit or are half way through (like the suspend one we saw lately). As I am not everyday working on the USB stuff, I would not like to deprive you of any improvements anyone else has made but I have not yet committed. Let me know if you have idea's on how to restyle the pages a bit so they become more readable. The pages is a bit of a mess. Please be sure to read the usb-...@egroups.com mailing list if you are interested. (to subscribe, go to www.egroups.com) Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
UPDATE8: : ATA/ATAPI driver new version available.
Eigth update to the new ATA/ATAPI driver: Fixed problems: LS120/ZIP drives still currupted data. Reworked once again, buffered I/O is just ignoring any sizehints it is given :( Now the atapifd driver splits up requests for devices that has limitted transfer size. ISA only configs fails on boot with interrupt timeouts. The new-bus integration introduced a bug where the softc ptr was lost during the probe. Some minor cleanups and rearrangements as well. As usual USE AT YOUR OWN RISK!!, this is still pre alpha level code. Especially the DMA support can hose your disk real bad if anything goes wrong, again you have been warned :) Notebook owners should be carefull that their machines dont suspend as this might cause trouble... But please tell me how it works for you! Enjoy! -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
mmap() on raw devices
Dear All, I am trying to mmap a raw device (/dev/rda0) yet mmap() keeps returning EINVAL. From what I have read on the list archives, mmap() should be able to map a character device (just not a block device), am I missing something here? I have tried this on 3.1-STABLE and 4.0-CURRENT, but no luck. TIA, Matt Matt Hamiltonmatt.hamil...@acm.org Hamilton Computing +44 (0)797 909 2482 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mount_mfs panics
On 19 May 1999 22:16:52 EST, Joel Ray Holveck wrote: > Using a May 17 15:00 CDT -current, I also have gotten a panic mounting > MFS. The line from fstab is: > > /dev/da0s2b /tmpmfs rw 0 0 Fixed on Tuesday, a little after 1 o'clock in the afternoon (GMT). Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 xsetpointer causes silo overflows (Was: Re: Fixed my MAMEd sio problem.)
On Wed, May 19, 1999 at 11:37:51PM +0930, Matthew Thyer wrote: >The big problem is that the silo overflows continue after I have >returned the pointer to the mouse (with "xsetpointer pointer"). > >This should close the joystick device shouldn't it ? No. I've had a look through some of the XInput code, and it seems that it isn't unusual for an Xserver to open all devices at server startup, and not close them until server exit. There are provisions for delaying the open until the device is referenced, and for closing it before the server exits. The XFree86-specific XInput code does the former, but not the latter. Here are some comments from the Xserver/Xi code (which is not XFree86-specific): * Caller: ProcXOpenDevice * * This is the implementation-dependent routine to open an input device. * Some implementations open all input devices when the server is first * initialized, and never close them. Other implementations open only * the X pointer and keyboard devices during server initialization, * and only open other input devices when some client makes an * XOpenDevice request. This entry point is for the latter type of * implementation. * * If the physical device is not already open, do it here. In this case, * you need to keep track of the fact that one or more clients has the * device open, and physically close it when the last client that has * it open does an XCloseDevice. * * The default implementation is to do nothing (assume all input devices * are opened during X server initialization and kept open). * Caller: ProcXCloseDevice * * Take care of implementation-dependent details of closing a device. * Some implementations may actually close the device, others may just * remove this clients interest in that device. * * The default implementation is to do nothing (assume all input devices * are initialized during X server initialization and kept open). There is one aspect of XFree86's XInput support that I do consider a bug, and that is that it doesn't close the extended input devices when VT switching away from the server. We'll probably fix that in 4.0. >If it doesn't then there is a problem with either the X server >or FreeBSD. > >Bruce has already indicated that there is a problem with the >FreeBSD joystick driver but he thought it should stop when the >joystick device is closed but I see that the problem continues >until I restart the X server so that would seem to indicate a >problem with the X server. IMHO the problem is in the joystick driver and in your assumptions. By configuring the joystick in your Xserver config file, you're giving the server exclusive use of the device for the lifetime of the X server process. Implementing more agressive closing might solve your particular problem, but it doesn't deal with the real problem of the joystick driver causing the silo overflows. David To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: UPDATE8: : ATA/ATAPI driver new version available.
Soren Schmidt wrote: > ISA only configs fails on boot with interrupt timeouts. > The new-bus integration introduced a bug where the softc ptr > was lost during the probe. Thank you, now it finaly works on my laptop (ISA only config)! Sincerely, Maxim ? ? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Plip almost unusable :(
Is anybody have experience with plip usage on -current? For me it seems broken - generally it works, but when I trying to make more or less massive transfer (1-2 MB is sufficient for most cases) any of two system dying in panic. Also "ping -f -s 8000 " kills remote or local host in several seconds :( Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
"Carlos C. Tapang" wrote: > Thanks to all who pitched in their input to this issue. Most users of my > system are running Windows and don't want to have to reformat or repartition > their hard disk. So I am stuck with the DOS file system. I think the best > solution is to have my users use a FreeBSD boot floppy. The floppy will have > /boot/loader which I will point to the DOS-formatted hard disk in which the > kernel resides. Correct me if I'm wrong, but loader is unable to directly load kernel from non-FreeBSD partition (DOS in your case), so problem is slightly more complicated but I though your can take PicoBSD (FreeBSD on floppy) and tweak it to match your needs. Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mmap() on raw devices
Matt Hamilton wrote... > Dear All, > > I am trying to mmap a raw device (/dev/rda0) yet mmap() keeps returning > EINVAL. From what I have read on the list archives, mmap() should be able > to map a character device (just not a block device), am I missing > something here? > > I have tried this on 3.1-STABLE and 4.0-CURRENT, but no luck. You'll only be able to mmap a device node if it supports mmaping. The da(4) driver, like the sd(4) driver before it, doesn't support mmapping. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Problem with ATA/ATAPI driver new version (update8)
I just tried the new ATA driver on my old ISA only notebook. After correct recognition of the hard disk: ad0: invalid primary partition table: no magic error 22: panic:. what does that mean? Thanx, Val _ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problem with ATA/ATAPI driver new version (update8)
It seems Valentin Shopov wrote: > I just tried the new ATA driver on my old ISA only > notebook. > After correct recognition of the hard disk: > > > ad0: invalid primary partition table: no magic > error 22: panic:. Hmm, sounds like it has trouble talking to the disk, try changeing the two #if 0's in ata-disk.c so that it uses 16 bit transfers.. If that fails, try to make it only use singlesector transfers, quite a lot older disks messes up there... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 xsetpointer causes silo overflows (Was: Re: Fixed my MAMEd sio problem.)
> David Dawes writes: > IMHO the problem is in the joystick driver and in your assumptions. By > configuring the joystick in your Xserver config file, you're giving the > server exclusive use of the device for the lifetime of the X server > process. Implementing more agressive closing might solve your particular > problem, but it doesn't deal with the real problem of the joystick driver > causing the silo overflows. All interrupts are blocked when you read the joystick position, and this is the reason of the silo overflows. It is almost impossible to avoid (it could be possible to use a very high frequency timer and to check the joystick status during the interrupts, but this has an impact on the precision of the position). However keeping the device opened can't cause silo overflows. It seems rather than the X server continues to read the joystick position after the client stops using it. This can be considered as a bug in the X server. Jean-Marc -- Jean-Marc ZucconiPGP Key: finger j...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problem with ATA/ATAPI driver new version (update8)
--- Soren Schmidt wrote: > It seems Valentin Shopov wrote: > > I just tried the new ATA driver on my old ISA only > > notebook. > > After correct recognition of the hard disk: > > > > > > ad0: invalid primary partition table: no magic > > error 22: panic:. > > Hmm, sounds like it has trouble talking to the disk, > try changeing the > two #if 0's in ata-disk.c so that it uses 16 bit > transfers.. > If that fails, try to make it only use singlesector > transfers, quite > a lot older disks messes up there... > > -Søren > you're right, it's 16 bit transfer. After changing #if 0's it's working. Thanks. BTW, is it possible to define this in the "flags" of ata[12]? Val _ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Problem with ATA/ATAPI driver new version (update8)
It seems Valentin Shopov wrote: > > > > Hmm, sounds like it has trouble talking to the disk, > > try changeing the > > two #if 0's in ata-disk.c so that it uses 16 bit > > transfers.. > > If that fails, try to make it only use singlesector > > transfers, quite > > a lot older disks messes up there... > > > > -Søren > > > > you're right, it's 16 bit transfer. After changing #if > 0's it's working. Thanks. > BTW, is it possible to define this in the "flags" of > ata[12]? When I get the time, I'll put in code that figures it out automagically, but a flag value to override could be handy... -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
priorities
You set a 'low' priority for the ide match as -100. I suggest we use a much lower value for that: -1. With USB we have 15 levels already, spaced ten apart (welcome back BASIC :) makes 150. Has anyone come up with a decent set of levels yet, or is the best bet still Mike's example (can; #define PRIORITY_STUB -1 #define PRIORITY_GENERIC-100 #define PRIORITY_BEST 1 #define PRIORITY_DEVICE 0 #define PRIORITY_FAIL -1 It sounds like we can loads of haggling about the names there... The last one is to take out the dependency on errno being greater than zero. Nick -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
The problem which remains unsolved is how to boot FreeBSD from DOS/Windows without the ability to use a boot floppy or boot CD. Perhaps a DOS/Windows utility which installs boot blocks? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
40% Off Sale on Black Books
Quantities Are Limited . . . Place Your Order Today. 800-305-1458 - MUST MENTION SALE WHEN ORDERING TO GET DISCOUNT Disounted Books --- "Pulpit Confessions: Exposing The Black Church" by N. Moore (0965829928) Was $16.00 - NOW $9.60 __ "Brothers Beware: Games Black Women Play" by A. Marshall (0965829936) Was $12.00 - NOW $7.20 __ "Louis Farrakhan: Made In America" by A. Marshall (0965572900) Was $19.95 - NOW $11.97 __ "How To Juggle Women Without Getting Killed or Going Broke" (0965829944) Was $12.00 - NOW $7.20 __ Also Available $50 for 50,000 African American Email Addresses (Free Black Entreprneur list included for a limited time) CALL TODAY - (800) 305-1458 MUST MENTION THIS SALE WHEN ORDERING FREE COD CHARGES - $3 SHIPPING To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Maxim writes, >Correct me if I'm wrong, but loader is unable to directly load kernel from >non-FreeBSD partition (DOS in your case), so problem is slightly more >complicated but I though your can take PicoBSD (FreeBSD on floppy) and tweak it >to match your needs. > I have tried booting /boot/loader from a floppy, and then have loader boot a kernel that resides in a DOS file system. As far as I can tell, it works flawlessly. Carlos C. Tapang http://www.genericwindows.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
Anthony writes, > >The problem which remains unsolved is how to boot FreeBSD from >DOS/Windows without the ability to use a boot floppy or boot CD. > >Perhaps a DOS/Windows utility which installs boot blocks? > Such a utility may be useful in most cases, but I do not want to have to mess around with my users' boot blocks at this point. When Generic Windows is stable enough and is ready for prime-time, then I will have a use for such a utility. The idea is to minimize the changes done to a user's system so that uninstalling Generic Windows (name to change later) will be easy. It's just too risky to modify the boot blocks and then have to put it in its original state during uninstall. Carlos C. Tapang http://www.genericwindows.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FBSDBOOT.EXE
Lets also consider the case of a root partition exists on a device which the BIOS does not support, but DOS and FreeBSD do. A good example of this may be a SCSI controller without a BIOS, or maybe a network style load. A person could have just the kernel on the DOS parition, or have the driver for the device loaded and boot off of it that way. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Plip almost unusable :(
On Thursday, 20 May 1999 at 16:54:37 +0300, Maxim Sobolev wrote: > Is anybody have experience with plip usage on -current? For me it seems > broken - generally it works, but when I trying to make more or less > massive transfer (1-2 MB is sufficient for most cases) any of two system > > dying in panic. Also "ping -f -s 8000 " kills remote or > local host in several seconds :( What was the panic? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: MTRR support for AMD K6-2?
> > > > Do we have MTRR support for the AMD K6-2, and how's it done (e.g., if I > > want > > to allow mtrr support for my Voodoo Banshee) > > It's being worked on. The K6 is a problematic device, as it only > supports two memory ranges, as opposed to the eight the P6 does. > OK - give me a yell once it's ready for testing. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 xsetpointer causes silo overflows (Was: Re: Fixed my MAMEd sio problem.)
On Thu, May 20, 1999 at 07:23:49PM +0200, Jean-Marc Zucconi wrote: >> David Dawes writes: > > > IMHO the problem is in the joystick driver and in your assumptions. By > > configuring the joystick in your Xserver config file, you're giving the > > server exclusive use of the device for the lifetime of the X server > > process. Implementing more agressive closing might solve your particular > > problem, but it doesn't deal with the real problem of the joystick driver > > causing the silo overflows. > >All interrupts are blocked when you read the joystick position, and >this is the reason of the silo overflows. It is almost impossible to >avoid (it could be possible to use a very high frequency timer and to >check the joystick status during the interrupts, but this has an >impact on the precision of the position). > >However keeping the device opened can't cause silo overflows. It >seems rather than the X server continues to read the joystick >position after the client stops using it. This can be considered as a >bug in the X server. That's implicit in the device remaining open. In the context of the X server's input device handling, "Open" means make active, and "Close" means make inactive. For most devices, the fd is added to the list of fds to select() on. For the joystick device, a timer callback is installed to check the device at regular intervals. This is never disabled once it has been started. If someone has a fix for this, please submit it to pa...@xfree86.org and it can be included in our next 3.3.x release. I'll keep this issue in mind while working on the input device code for XFree86 4.0. David To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Plip almost unusable :(
>Is anybody have experience with plip usage on -current? For me it seems >broken - generally it works, but when I trying to make more or less >massive transfer (1-2 MB is sufficient for most cases) any of two system > >dying in panic. Also "ping -f -s 8000 " kills remote or >local host in several seconds :( This is normal if you don't use the current workaround of configuring ppp. New-bus broke the previous workarounds of configuring slip or putting ppbus in device class "net". I haven't checked that configuring ppp actually helps for plip. The workaround provided by configuring slip was slightly stronger. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "hanging root device to da0s1a"
>> I'm not sure why it happens like this; try putting a DELAY() just >> before we actually set the root device and see if you can put it off. > >Why not just spl() protect that printf call so that its output is >dumped contiguously into the console buffer? This would just move the race. It is probably already elsewhere for serial consoles. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message