kernel panic: vm_object_reference
Hi. As i informed you earler the bug exists in freebsd 4.5. Kernel panics with `vm_object_reference: delay in getting object' when i copy files from a partition and at the same time dismount this partition (umount -f /cdrom). The sutuation is following. I mount /cdrom. Then start too many `cp' processes that copy some files from /cdrom. In other tty i umount -f /cdrom and kernel panics. Sorry if it's known bug. -- email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: jail + mount_union problem
Victor Polyakov wrote: > Unfortunately, NULLFS filesystem does not permit users to modify files. > We want do give each user a copy of /usr and to permit installation of > software etc... You mean "on a per user basis". It permits modification. In general, you would mount / and /usr read-only, and mount some other area (e.g. /usr/local) as read/write, and they would install their private stuff there. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: jail + mount_union problem
Good morning, So UNIONFS is broken in 4.5? Is it fixed in -STABLE? In -CURRENT? Best regards, Vadim. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: jail + mount_union problem
On Tue, Mar 26, 2002 at 12:04:57PM +0300, Vadim Kolontsov wrote: > Good morning, > > So UNIONFS is broken in 4.5? Is it fixed in -STABLE? In -CURRENT? I dont believe union should be used anywhere. Its broken, its always been broken (withinn the context of FreeBSD). As far as I know that hasn't changed recently. Read `man mount_union`. > Best regards, > Vadim. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Dominic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: jail + mount_union problem
> I dont believe union should be used anywhere. Its broken, its > always been broken (withinn the context of FreeBSD). > As far as I know that hasn't changed recently. Read `man mount_union`. Surely I read it. But what's about PR docs/30253 and kern/27250? Best regards, Vadim. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
In local.freebsd-hackers, you wrote: > Speaking of idprio... I liked the good old days (3.x) when you didn't have > to be root to use the command. Given that idprio can be used to raise > priorities as well as lower them, I can see the point of having some > restrictions, but shouldn't it be possible to structure the code such that a > non-root user can lower but not raise the priority on a process they own? It's in the "BUGS" section: BUGS ... Under FreeBSD system calls are currently never preempted, therefore non- realtime processes can starve realtime processes, or idletime processes can starve normal priority processes. -- Wonderful \hbox (0.80312pt too nice) in paragraph at lines 16--18 Volker Stolz * [EMAIL PROTECTED] Please use PGP or S/MIME for correspondence! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: jail + mount_union problem
On Tue, Mar 26, 2002 at 01:16:45PM +0300, Vadim Kolontsov wrote: > > I dont believe union should be used anywhere. Its broken, its > > always been broken (withinn the context of FreeBSD). > > As far as I know that hasn't changed recently. Read `man mount_union`. > > Surely I read it. But what's about PR docs/30253 and kern/27250? The state of of these is open and analyzed respectively. Since the originator of the doc PR is now a committer I've added him to the CC list. Perhaps he can now close his own PR. Does seem like union was fixed, partially at least. > Best regards, > Vadim. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Dominic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
On Tue, 26 Mar 2002, Volker Stolz wrote: > Under FreeBSD system calls are currently never preempted, therefore non- > realtime processes can starve realtime processes, or idletime processes > can starve normal priority processes. Even so an idprio process can't be worse than a normal process. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel panic: vm_object_reference
Hello, Forcibly unmounting a file system that is in use will panic your system. It's not exactly a bug, it's just how it works. :) On Tue, Mar 26, 2002 at 10:24:01AM +0200, Apache Man wrote: > Hi. > > As i informed you earler the bug exists in freebsd 4.5. > Kernel panics with `vm_object_reference: delay in getting object' > when i copy files from a partition and at the same time dismount > this partition (umount -f /cdrom). > > The sutuation is following. > I mount /cdrom. Then start too many `cp' processes that copy > some files from /cdrom. In other tty i umount -f /cdrom and > kernel panics. > > Sorry if it's known bug. > > -- > email: [EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CanSecWest/core02 reminder
Hello to those of you I haven't talked in a while, and last two years conference attendees. (Sorry if you get two copies of this, it means you've either got two ids in my addressbook or my perl hash script-foo is not leet enough. :-) This is a quick note to remind you that the deadline for reduced fares for travel to Vancouver for the CanSecWest/core02 conference in Vancouver is coming up so if you haven't booked your ticket, or taken advantage of the lower registration rates this month Also agenda details and a schedule will be posted shortly at http://www.cansecwest.com cheers, --dr -- --drhttp://dragos.com/dr-dursec.asc CanSecWest/core02 - May 1-3 2002 - Vancouver B.C. - http://cansecwest.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel panic: vm_object_reference
That is a bug. The system is supposed to iterate through all the vnodes hanging off the mount point and vgone them. According to Kirk at least this used to work. -Kip On Tue, 26 Mar 2002, Michael Lucas wrote: > Hello, > > Forcibly unmounting a file system that is in use will panic your > system. It's not exactly a bug, it's just how it works. :) > > On Tue, Mar 26, 2002 at 10:24:01AM +0200, Apache Man wrote: > > Hi. > > > > As i informed you earler the bug exists in freebsd 4.5. > > Kernel panics with `vm_object_reference: delay in getting object' > > when i copy files from a partition and at the same time dismount > > this partition (umount -f /cdrom). > > > > The sutuation is following. > > I mount /cdrom. Then start too many `cp' processes that copy > > some files from /cdrom. In other tty i umount -f /cdrom and > > kernel panics. > > > > Sorry if it's known bug. > > > > -- > > email: [EMAIL PROTECTED] > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] > my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons > > http://www.blackhelicopters.org/~mwlucas/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel panic: vm_object_reference
OK. That's not what I was told but back in 96 or so,but I suppose the code is allowed to change. My apologies. :-) Could you please prepare a dump of this? See the developers' handbook for details, or follow the pointers from the FAQ. Thanks! On Tue, Mar 26, 2002 at 07:20:37AM -0800, Kip Macy wrote: > That is a bug. The system is supposed to iterate through all the vnodes hanging > off the mount point and vgone them. According to Kirk at least this used to > work. > > -Kip > > > On Tue, 26 Mar 2002, Michael Lucas wrote: > > > Hello, > > > > Forcibly unmounting a file system that is in use will panic your > > system. It's not exactly a bug, it's just how it works. :) > > > > On Tue, Mar 26, 2002 at 10:24:01AM +0200, Apache Man wrote: > > > Hi. > > > > > > As i informed you earler the bug exists in freebsd 4.5. > > > Kernel panics with `vm_object_reference: delay in getting object' > > > when i copy files from a partition and at the same time dismount > > > this partition (umount -f /cdrom). > > > > > > The sutuation is following. > > > I mount /cdrom. Then start too many `cp' processes that copy > > > some files from /cdrom. In other tty i umount -f /cdrom and > > > kernel panics. > > > > > > Sorry if it's known bug. > > > > > > -- > > > email: [EMAIL PROTECTED] > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > -- > > Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] > > my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons > > > > http://www.blackhelicopters.org/~mwlucas/ > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel panic: vm_object_reference
No apologies neccessary :-). You may be right with respect to FreeBSD. In his BSD class Kirk describes a forcible unmount as a perfectly legitimate thing to do (albeit a bit traumatic for the users). It may just be a regression that crept in and, seeing as it is something that people seldom want to do, no one saw a need to fix it. -Kip > OK. That's not what I was told but back in 96 or so,but I suppose the > code is allowed to change. My apologies. :-) > > Could you please prepare a dump of this? See the developers' handbook > for details, or follow the pointers from the FAQ. Thanks! > > On Tue, Mar 26, 2002 at 07:20:37AM -0800, Kip Macy wrote: > > That is a bug. The system is supposed to iterate through all the vnodes hanging > > off the mount point and vgone them. According to Kirk at least this used to > > work. > > > > -Kip > > > > > > On Tue, 26 Mar 2002, Michael Lucas wrote: > > > > > Hello, > > > > > > Forcibly unmounting a file system that is in use will panic your > > > system. It's not exactly a bug, it's just how it works. :) > > > > > > On Tue, Mar 26, 2002 at 10:24:01AM +0200, Apache Man wrote: > > > > Hi. > > > > > > > > As i informed you earler the bug exists in freebsd 4.5. > > > > Kernel panics with `vm_object_reference: delay in getting object' > > > > when i copy files from a partition and at the same time dismount > > > > this partition (umount -f /cdrom). > > > > > > > > The sutuation is following. > > > > I mount /cdrom. Then start too many `cp' processes that copy > > > > some files from /cdrom. In other tty i umount -f /cdrom and > > > > kernel panics. > > > > > > > > Sorry if it's known bug. > > > > > > > > -- > > > > email: [EMAIL PROTECTED] > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > -- > > > Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] > > > my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons > > > > > > http://www.blackhelicopters.org/~mwlucas/ > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > -- > Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] > my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons > > http://www.blackhelicopters.org/~mwlucas/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
Andrew wrote: >> Under FreeBSD system calls are currently never preempted, therefore >> non- realtime processes can starve realtime processes, or idletime >> processes can starve normal priority processes. > > Even so an idprio process can't be worse than a normal process. Practically this means "you will still see a drop in your foreground performance." Theoretically, however, you can construct scenarios where your foreground stuff is starved ad infinitum due to priority inversion. (Since some/most non-CPU resources don't support priorities and preemption.) Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California smime.p7s Description: S/MIME Cryptographic Signature
Re: idprio
In the last episode (Mar 26), Andrew said: > On Tue, 26 Mar 2002, Volker Stolz wrote: > > Under FreeBSD system calls are currently never preempted, therefore > > non- realtime processes can starve realtime processes, or idletime > > processes can starve normal priority processes. > > Even so an idprio process can't be worse than a normal process. Sure it can, if the idprio process has locked a vnode trying to update the contents of a file, and another non-idprio process starts consuming 100% CPU. The idprio process never gets a chance to run again, and if that vnode happened to be an important one (say for /), you may not be able to kill the other process without rebooting. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Help with getting load information
> > Also, I want to get the information about the load, > and also process information. > you may get the load averages through getloadavg(3) or through kvm_getloadavg(3). process information may be retrieved through kvm_getprocs(3). Good luck, -Anthony. --- PGP key at: http://www.keyserver.net/ http://www.anthonydotcom.com/gpgkey/key.txt Home: http://www.anthonydotcom.com --- msg33097/pgp0.pgp Description: PGP signature
Re: jail + mount_union problem
Vadim Kolontsov wrote: > > Good morning, > > So UNIONFS is broken in 4.5? Is it fixed in -STABLE? In -CURRENT? There are two types of "union"; one is intrinsic, and one is a seperate FS type. There are also uncommitted patches that have been sitting around for a while now. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel panic: vm_object_reference
Michael Lucas wrote: > Forcibly unmounting a file system that is in use will panic your > system. It's not exactly a bug, it's just how it works. :) "Forcibly trapping a butterfly with the provided butterfly net will destroy civilization. It's not exactly a bug, it's just how it works." Sheesh. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
Dan Nelson wrote: > In the last episode (Mar 26), Andrew said: > > On Tue, 26 Mar 2002, Volker Stolz wrote: > > > Under FreeBSD system calls are currently never preempted, therefore > > > non- realtime processes can starve realtime processes, or idletime > > > processes can starve normal priority processes. > > > > Even so an idprio process can't be worse than a normal process. > > Sure it can, if the idprio process has locked a vnode trying to update > the contents of a file, and another non-idprio process starts consuming > 100% CPU. The idprio process never gets a chance to run again, and if > that vnode happened to be an important one (say for /), you may not be > able to kill the other process without rebooting. You meant that when you use priorities, you risk priority inversion? 8-p -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
> Dan Nelson wrote: >> In the last episode (Mar 26), Andrew said: >>> On Tue, 26 Mar 2002, Volker Stolz wrote: Under FreeBSD system calls are currently never preempted, therefore non- realtime processes can starve realtime processes, or idletime processes can starve normal priority processes. >>> >>> Even so an idprio process can't be worse than a normal process. >> >> Sure it can, if the idprio process has locked a vnode trying to update >> the contents of a file, and another non-idprio process starts consuming >> 100% CPU. The idprio process never gets a chance to run again, and if >> that vnode happened to be an important one (say for /), you may not be >> able to kill the other process without rebooting. > > You meant that when you use priorities, you risk priority inversion? > > 8-p > > -- Terry > Well, I think the upshot is that if you use priorities that can result in a process never getting any cycles you risk priority inversion. If you use normal "nice" priorities rather than those in the idprio range, then (I assume...) this priority inversion can't happen, because the nice'd process will eventually get some cycles. I think this amounts to "a good policy reason why idprio is a root-only command"... there is a potential "You'd better know what you're doing or the system locks up" factor involved. On the practical side of things, I'll continue to manually set my seti@home process to idprio 30, because it makes a noticible difference in buildworld performance. (Not dramatic, but noticible.) -- Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: apache13-ssl wiped out my Web pages
Try looking in /usr/local/share/doc/apache for your web tree /usr/local/www/data used to be linked to this directory, it seems that now it is not. Chances are all your stuff is there, all you have to do is either move it to the newly created data directory or re-create the link to point to it's current location. Sean. Sean Page Network Analyst Information Technology Services Edmonton Public Schools -Original Message- From: Mike Carr [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 23, 2002 12:29 AM To: [EMAIL PROTECTED] Subject: apache13-ssl wiped out my Web pages I Have recently installed the Horde port to my machine. I did not have Apache+mod_ssl, PHP, or MySql installed on my system, just Apache serving up my companies files. The installation went fine up to the point when I went to check the installation and found that the Apahe13-ssl port had wiped out my web directories. This definitely needs to change! Here are some ideas 1) Show a warning prior to installing Apache, that the installation will wipe out the users current web pages 2) Make a backup of the files prior to wiping them out 3) leave all the data in data.default directory alone apache13-ssl/ pkg-plist This is the problem area @exec [ -d %D/www/data/ ] || ln -fs %B %D/www/data Line 131 -rw-r--r--1 root wheel 22804 Dec 2 15:17 pkg-plist # New ports collection makefile for:Apache + mod_ssl # Date created: Sat Aug 22 12:00:00 CDT 1998 # Whom: [EMAIL PROTECTED] # # $FreeBSD: ports/www/apache13-modssl/Makefile,v 1.94 2002/01/22 22:29:24 sf Exp $ # To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
On Tue, 26 Mar 2002, Terry Lambert wrote: > > Sure it can, if the idprio process has locked a vnode trying to update But if system calls aren't preempted under what circumstances can a process hold a vnode lock and then be usurped for processor? Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
* Andrew <[EMAIL PROTECTED]> [020326 14:27] wrote: > > > On Tue, 26 Mar 2002, Terry Lambert wrote: > > > > Sure it can, if the idprio process has locked a vnode trying to update > > But if system calls aren't preempted under what circumstances can a > process hold a vnode lock and then be usurped for processor? While sleeping for IO. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
On Tue, 26 Mar 2002, Alfred Perlstein wrote: > While sleeping for IO. Oh yeah...rather obvious now you mention it :-) Thanks, Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
In the last episode (Mar 27), Andrew said: > > On Tue, 26 Mar 2002, Terry Lambert wrote: > > > > Sure it can, if the idprio process has locked a vnode trying to update Careful; I wrote the above line, not Terry. > But if system calls aren't preempted under what circumstances can a > process hold a vnode lock and then be usurped for processor? System calls aren't preempted, but if while processing a syscall, the kernel decides to tsleep(), say because of disk I/O (a very common thing when dealing with vnodes :), then another process is free to start running. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: olympus c-1 (d-150)
i am being directed to this list for assistance.
the problem is an Olympus camera as follows:
(please Cc off list - i am not subscribed)
>NO it is no in this line! Maybe its the same like the C-1, but the name
>of it is D-150. So it gets detected by the next line of this file:
>
>* Olympus digital cameras (D-370)
>*/
> {T_DIRECT, SIP_MEDIA_REMOVABLE, "OLYMPUS", "D-*", "*"},
> /*quirks*/ DA_Q_NO_6_BYTE
>
>And if you look closer you see that there's no "DA_Q_NO_SYNC_CACHE".
>Add it and try again.
ok - i have done as suggested as follows (before & after dmesg):
(i don't not any difference - camera is plugged in at boot time)
===
usbdevs -v reports:
Controller /dev/usb0:
addr 1: self powered, config 1, OHCI root hub(0x),
OPTi(0x), rev 0x0100 port 1
addr 2: self powered, config 1, C-1 Digital Camera(0x0102),
Olympus(0x07b4), rev 0x1015 port 2 powered
usbd -d reports:
usbd:doing timeout discovery on /dev/usb0
usbd:processing event queue due to timeout on /dev/usb
/etc/usbd.conf:
device "SmartMedia"
devname "/dev/da0s1"
attach "/sbin/mount -t msdos /dev/da0s1 /mnt"
===
/usr/src/sys/dev/usb/umass.c:
if (UGETW(dd->>idVendor) == USB_VENDOR_OLYMPUS) { /* && */
/* UGETW(dd->>idProduct) == USB_PRODUCT_OLYMPUS_C1) { */
/*
* The Olympus C-1 camera uses a different command-status
* signature.
*/
sc->>quirks |= WRONG_CSWSIG;
}
Copyright (c) 1992-2002 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.5-RELEASE #5: Mon Mar 25 16:33:16 AKST 2002
[EMAIL PROTECTED]:/usr/src/sys/compile/MYKERN
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 167045919 Hz
CPU: Pentium/P54C (167.05-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52c Stepping = 12
Features=0x1bf
real memory = 33554432 (32768K bytes)
avail memory = 30072832 (29368K bytes)
Preloaded elf kernel "kernel" at 0xc02b6000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc02b609c.
Intel Pentium detected, installing workaround for F00F bug
Using $PIR table, 5 entries at 0xc00fdc70
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
pci0: on pcib0
isab0: at device 7.0 on pci0
isa0: on isab0
atapci0: port 0xf000-0xf00f at device 7.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: at 17.0
ohci0: mem 0xe100-0xe1000fff irq
10 at device 19.0 on pci0
usb0: OHCI version 1.0, legacy support
usb0: on ohci0
usb0: USB revision 1.0
uhub0: OPTi OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
umass0: OLYMPUS C-1Z,D-150Z, rev 1.10/10.15, addr 2, SCSI over Bulk-Only
umass0: Max Lun is 0
umass-sim:0:-1:-1:XPT_PATH_INQ:.
umass0:0:0:-1: Attached to scbus0 as device 0
umass0: Attach finished
orm0: at iomem 0xc-0xc7fff on isa0
sc0: on isa0
sc0: VGA <9 virtual consoles, flags=0x200>
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: irq 1 on atkbdc0
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio0 at port 0x3f8-0x3ff irq 4 on isa0
sio0: type 16550A
ed0 at port 0x340-0x35f irq 9 on isa0
ed0: address 00:00:1b:35:06:76, type NE2000 (16 bit)
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
ppc0: at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: on ppbus0
lpt0: on ppbus0
lpt0: Interrupt-driven port
ppi0: on ppbus0
ad0: 4112MB [8912/15/63] at ata0-master WDMA2
acd0: CDROM at ata0-slave using PIO4
umass-sim:0:-1:-1:XPT_PATH_INQ:.
umass-sim:0:-1:-1:XPT_PATH_INQ:.
umass-sim:0:-1:-1:XPT_PATH_INQ:.
umass0:0:0:0:XPT_PATH_INQ:.
umass0:0:0:0:XPT_PATH_INQ:.
umass-sim:0:1:0:func_code 0x0004: Invalid target (no wildcard)
umass-sim:0:2:0:func_code 0x0004: Invalid target (no wildcard)
umass0:0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense
umass0: CBW 1: cmd = 6b (0x12002400), data = 36 bytes, dir = in
umass0: Handling BBB state 1 (BBB CBW), xfer=0xc07f1300, TIMEOUT
umass0: failed to send CBW
umass0: Bulk Reset
umass0: Handling BBB state 7 (BBB Reset), xfer=0xc07f7d80, TIMEOUT
umass0: BBB reset failed, TIMEOUT
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 8 (BBB bulk-in clear stall), xfer=0xc07f7d00,
TIMEOUT
umass0: BBB bulk-in clear stall failed, TIMEOUT
umass0: Clear endpoint 0x01 stall
umass0: Handling BBB state 9 (BBB bulk-out clear stall), xfer=0xc07f7c80,
TIMEOUT
umass0: BBB bulk-out clear stall failed, TIMEOUT
umass0:0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense
umass0: CBW 2: cmd = 6b (0x120
Re: kernel panic: vm_object_reference
Michael Lucas wrote: > > Hello, > > Forcibly unmounting a file system that is in use will panic your > system. It's not exactly a bug, it's just how it works. :) > I don't agree. I know this is a little "foolproof" programming but I should return something like busy FS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
Andrew wrote: > On Tue, 26 Mar 2002, Terry Lambert wrote: > > > Sure it can, if the idprio process has locked a vnode trying to update > > But if system calls aren't preempted under what circumstances can a > process hold a vnode lock and then be usurped for processor? I didn't say that. But yes, locking in FreeBSD is a mess right now. Live with it: priority inversion won't be fixed until priority lending is supported. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idprio
Alfred Perlstein wrote: > > But if system calls aren't preempted under what circumstances can a > > process hold a vnode lock and then be usurped for processor? > > While sleeping for IO. Ideal systems release and reacquire locks when they are going to suspend for a long time (Djikstra's "Banker's Algorithm"). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
