Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
Hi all, I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: #sshfs usern...@hostname:/home/username local_mountpoint/ This mounts the remote filesystem fine. However, when i edit and save a file in say vi on the remote sshfs i get the following panic everytime: FreeBSD/amd64 (hostname.com) (ttyu0) login: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff80e9d1d9d0 frame pointer = 0x28:0xff80e9d1db50 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1749 (vim) trap number = 12 panic: page fault cpuid = 2 Uptime: 17m11s Physical memory: 8096 MB Dumping 1591 MB: It then seems to hang and not actually do a dump and i need to physically reset the box. If there is anything i can do to further assist in debugging please let me know. -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mouse problems....
On Wed, Oct 13, 2010 at 11:11:22PM +0200, Polytropon wrote:
> On Wed, 13 Oct 2010 10:29:31 -0700, Gary Kline wrote:
> > I just noticed that in rc.conf is:
> >
> >
> > # -- sysinstall generated deltas -- # Wed Oct 13 08:03:06 2010
> > moused_port="/dev/ums0"
> > moused_type="auto"
> > moused_enable="NO"
> >
> > and yet the console mouse is present. Strange... .
>
> Explaination: USB mice are handled by devd. So if the system
> detects the presence of a ums device, devd "remote-controls"
> moused to activate this mouse.
>
> # The entry below starts moused when a mouse is plugged in. Moused
> # stops automatically (actually it bombs :) when the device disappears.
> attach 100 {
> device-name "ums[0-9]+";
> action "/etc/rc.d/moused start $device-name";
> };
>
> This is from /etc/devd.conf.
>
>
Thanks for the pointer. It got me curious about what parsed
this file and I'm scanning devd.cc. ...
>
> --
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...
--
Gary Kline kl...@thought.org http://www.thought.org Public Service Unix
The 7.90a release of Jottings: http://jottings.thought.org/index.php
http://journey.thought.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
On Wed, Oct 13, 2010 at 01:43:24PM -0700, Kevin Oberman wrote: ... > > > It sounds like the only way to solve this issue is to improve/fix the > > > msgbuf code. ?Alternatively, you could consider moving from ipfw to > > > pf(4) and use pflog(4) / pflogd(8). > > > > or you can use the log option of ipfw and run tcpdump on the "ipfw0" > > pseudo interface > > which will give you all the traffic that matches a 'log' rule (there > > is a sysctl variable that > > controls whether log goes to syslog or to the ipfw pseudo interface) > > Is the any real documentation on the ipfw0 device and how to use it? I > can see it as being very handy. documentation ? what's that :) thanks for the reminder, just committed some text to ipfw.8 in HEAD to document the feature. cheers luigi > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: ober...@es.netPhone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: need help with BElkin KVM and USB mouse problems.
On Wed, Oct 13, 2010 at 08:48:08AM -0400, Boris Kochergin wrote: > I have a USB KVM whose mouse and keyboard work both on the console > and in X. My xorg.conf is attached. I am running moused. I am *not* > running hald. > > -Boris > Appreciate your xorg posting, thanks.. What did the trick was to turn off half in /etc/rc.conf and add the following to the Server Layout block: Option "AutoAddDevices" "Off" I just checked: the mouse daemon is not running; the pointer works in both console and X modes. Why? no clue. The help was from Warren Block's site. http://www.wonkity.com/~wblock/docs/html/aei.html cheers, gary -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix The 7.90a release of Jottings: http://jottings.thought.org/index.php http://journey.thought.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mouse problems....
On Wed, 13 Oct 2010 10:29:31 -0700, Gary Kline wrote:
> I just noticed that in rc.conf is:
>
>
> # -- sysinstall generated deltas -- # Wed Oct 13 08:03:06 2010
> moused_port="/dev/ums0"
> moused_type="auto"
> moused_enable="NO"
>
> and yet the console mouse is present. Strange... .
Explaination: USB mice are handled by devd. So if the system
detects the presence of a ums device, devd "remote-controls"
moused to activate this mouse.
# The entry below starts moused when a mouse is plugged in. Moused
# stops automatically (actually it bombs :) when the device disappears.
attach 100 {
device-name "ums[0-9]+";
action "/etc/rc.d/moused start $device-name";
};
This is from /etc/devd.conf.
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mouse problems....
On Wed, 13 Oct 2010 09:03:21 -0600 (MDT), Warren Block wrote: > I've followed only parts of this thread, and there are multiple > problems. First is installing X on a server. And first + one half is running X as root. :-) As it is only for testing, no big deal, but I did want to just mention it. > Second is a KVM switch, > many of which are problematic. That's true. The key problem is the switching from / to a particular machine, and how it handles this process. On the early models where wires were switched "purely electrically", this caused the system to lose a device. Some more modern KVM switches seem to provide a "dummy" signal so the device isn't lost (as in the view of the system), but I doubt this is a standard method. > Next is that the KVM converts USB to > PS/2, which... well, maybe it's fine. Erm, no. As far as I understood now, the KVM switch is USB only, or to be more precise: At least the mouse is USB - no PS/2 handling in between. > Finally, a "jumpy mouse" problem > with moused on console screams that it's the KVM, not moused or USB or > xorg config. I'm not 100% sure about that. Your article located at http://www.wonkity.com/~wblock/docs/html/aei.html states: Other times, particularly if hald is running, typed characters don't show up on the screen until the mouse is moved, and mouse movement itself is jerky and doesn't react smoothly. I thought about something like that. > My suggestion would be to *not* install X on a server. And this would eliminate the problem, as the keyboard (the main input method for console-driven dialog) seems to work as inteded through the KVM switch. > If it's really > required, use an actual keyboard and monitor on that server for those > times when ssh -X/-Y aren't enough, and avoid the KVM. Often the best solution, at least im ny experience. I have used KVM switches in the past, but found them often problematic (as shown in this thread), so my first choice is networked access, and if neccessary, "hardware access". In some cases, a serial line with a terminal (or an old laptop resembling a terminal, using DOS and the KERMIT terminal emulator) is fully sufficient, and VERY well supported by FreeBSD. > USB mice cause moused to be run anyway, but there are differences. If > you want switching between X and console to be fast, enable moused. And this is possible in combination with devd that "remote-contols" moused for USB mice? And does moused handle "disappearing" and "reappearing" devices properly? -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
> Date: Wed, 13 Oct 2010 11:55:19 +0200 > From: Luigi Rizzo > Sender: owner-freebsd-sta...@freebsd.org > > On Wed, Oct 13, 2010 at 11:23 AM, Jeremy Chadwick > wrote: > > On Wed, Oct 13, 2010 at 11:03:36AM +0200, Marcin wrote: > >> 2010/10/13 Jeremy Chadwick : > >> > On Tue, Oct 12, 2010 at 10:50:28PM +0200, Marcin wrote: > >> >> Hi folks, > >> >> > >> >> For some time in the file / var / log / security appear illegible > >> >> entries: > >> >> kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 > >> >> .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 > >> >> > >> >> How to get rid of it? Please help... > >> > > >> > There isn't a 100% reliable way to get rid of this problem. I've been > >> > harping about this for years (sorry to sound like a jerk, but this > >> > really is a major problem that keeps coming up and annoys users/admins > >> > to no end. There are solutions -- Linux solved it by implementing a > >> > lockless circular ring buffer[1] used by kmsg). > >> > > >> > The """workaround""" -- which again, does not solve the problem, only > >> > decreases the regularity of it happening (and when it does happen, can > >> > sometimes decrease how much interspersed output there is) -- is to add > >> > the following line to your kernel config and rebuild/reinstall your > >> > kernel: > >> > > >> > options PRINTF_BUFR_SIZE=128 # Prevent printf output being > >> > interspersed. > >> > > >> > This option became part of the GENERIC kernel configuration file at the > >> > following times: > >> > > >> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/conf/GENERIC#rev1.529 > >> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/GENERIC#rev1.517 > >> > > >> > Depending on what release/tag you follow, you may or may not find the > >> > above commit/change in your GENERIC file. I can't be bothered to track > >> > down what time the CVS tagging was done, for multiple architectures, > >> > etc... > >> > > >> > [1]: > >> > http://www.mjmwired.net/kernel/Documentation/trace/ring-buffer-design.txt > >> > >> Hi Jeremy, > >> I have compiled kernel with this option and unfortunately problem still > >> exist... > >> Do you have another idea how can i improve my log file? :) > > > > I was incorrect in my understanding/prognosis, so as Andriy pointed out, > > the option won't solve your problem. > > > > It sounds like the only way to solve this issue is to improve/fix the > > msgbuf code. Alternatively, you could consider moving from ipfw to > > pf(4) and use pflog(4) / pflogd(8). > > or you can use the log option of ipfw and run tcpdump on the "ipfw0" > pseudo interface > which will give you all the traffic that matches a 'log' rule (there > is a sysctl variable that > controls whether log goes to syslog or to the ipfw pseudo interface) Is the any real documentation on the ipfw0 device and how to use it? I can see it as being very handy. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Label question...why does ufs label vanish on mount?
> Date: Wed, 13 Oct 2010 13:26:30 +0200 > From: Pawel Jakub Dawidek > Sender: owner-freebsd-sta...@freebsd.org > > On Wed, Oct 13, 2010 at 11:47:41AM +0200, Stefan Bethke wrote: > > Am 13.10.2010 um 10:20 schrieb Pawel Jakub Dawidek: > > > > > On Tue, Oct 12, 2010 at 11:33:11PM -0700, Jeremy Chadwick wrote: > > >> On Wed, Oct 13, 2010 at 08:29:06AM +0200, Stefan Bethke wrote: > > >>> That explains the mechanism, but not the rationale. Or is it just an > > >>> unintended consequence? And how is da2p1 different from ufs/mylabel? > > >>> (Mount da2p1 and ufs/mylabel is removed, but not the other way around.) > > >> > > >> Pulling in pjd@ who can probably shed some light on this. > > > > > > The ufs/mylabel provider is based on da2p1, that's why opening da2p1 > > > makes ufs/mylabel to be removed and not the other way around. > > > > > > The ufs/mylabel provider was created, because when da2p1 provider was > > > created and LABEL class tasted it, it discovered that this provider > > > contains UFS file system with 'mylabel' volume label, so the LABEL class > > > created ufs/mylabel provider. Now when you open da2p1 for writing, the > > > LABEL class destroys ufs/mylabel, because you may decide to change > > > metadata on da2p1, for example you may choose to destroy UFS in there or > > > change the volume label. When write open count on da2p1 goes down to > > > zero, the LABEL class will be given da2p1 provider for tasting once > > > again, so it can rediscover (possibly modified) volume label. > > > > > > The class may choose to ignore the spoil event from GEOM (it is send on > > > first open for write), but if it isn't based on autodiscovering > > > metadata. For example the NOP class ignores this event, because it > > > doesn't care about metadata of provider it is based on. > > > > > > If we choose to ignore the spoil event in the LABEL class we will end up > > > with stale info, eg. open da2p1 for writing, change its volume label and > > > mount it and you will still have old label in /dev/ufs/. > > > > Thanks a lot (and also to Andrey), that really makes it clear to me! > > > > I just wish there was an easy way to keep the labels around even while > > someone has the provider open for writing, but I now understand that this > > requires some significant changes. > > The changes aren't significant. We could eventually ignore spoil event > and keep labels around even when underlying provider is opened for > writing risking the label is stale. We could then only update or remove > the label on retaste event (when underlying provider's open write count > goes down to zero). > > Currently when we do, eg. > > # dd if=/dev/zero of=/dev/da2p1 bs=1m > > This is happening: > > # dd(1) opens da2p1 for writing > # GEOM sends spoil event to all consumers of da2p1 > # LABEL class destroys /dev/ufs/mylabel provider > # dd(1) finishes and closes da2p1 > # GEOM sends taste event to all GEOM classes > # LABEL class finds no metadata and ignores da2p1 > > With the new world order this would look like this: > > # dd(1) opens da2p1 for writing > # GEOM sends spoil event to all consumers of da2p1 > # LABEL class ignores spoil event > # dd(1) finishes and closes da2p1 > # GEOM sends taste event to all GEOM classes > # LABEL class finds no metadata on da2p1 and destroys /dev/ufs/mylabel Thanks! Thi explains most of what I see, but there is one thing that is not explained. That is the devd showing a CREATE for the partition (e.g. da0s2d) every time the partition is either mounted or umounted, regardless of whether it is mounted by device or label. There is never a DESTROY event. this is both counter-intuitive, but hard to program around. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mouse problems....
On Wed, Oct 13, 2010 at 09:03:21AM -0600, Warren Block wrote: > On Wed, 13 Oct 2010, Polytropon wrote: > > >Correct. If you disable HAL, and your X is configured to run *WITH* > >HAL, it won't run anymore. Edit /etc/X11/xorg.conf (and if not > >present, create it) to make X work *WITHOUT* HAL. > > > >How it is to be done is described here: > > > >http://www.wonkity.com/~wblock/docs/html/aei.html > > I've followed only parts of this thread, and there are multiple > problems. First is installing X on a server. Second is a KVM > switch, many of which are problematic. Next is that the KVM > converts USB to PS/2, which... well, maybe it's fine. Finally, a > "jumpy mouse" problem with moused on console screams that it's the > KVM, not moused or USB or xorg config. Interesting that the mouse jumpiness has disappeared. I can switch to <-> computers by KVM and no problem. I'm about to add: Option "AutoAddDevices" "Off" to my xorg.conf Done. I just noticed that in rc.conf is: # -- sysinstall generated deltas -- # Wed Oct 13 08:03:06 2010 moused_port="/dev/ums0" moused_type="auto" moused_enable="NO" and yet the console mouse is present. Strange... . > > My suggestion would be to *not* install X on a server. If it's > really required, use an actual keyboard and monitor on that server > for those times when ssh -X/-Y aren't enough, and avoid the KVM. > > >If you use a USB mouse, set moused_enable="NO", as the USB subsystem > >will call moused with the correct settings automatically. > > USB mice cause moused to be run anyway, but there are differences. > If you want switching between X and console to be fast, enable > moused. I vastly prefer X11 because it allows xterms and more. X is necessary on my server because of my UPS as well as because it will be my new printserver. okay, time for the big reboot... . > ___ > freebsd-questi...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix The 7.90a release of Jottings: http://jottings.thought.org/index.php http://journey.thought.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mouse problems....
On Wed, 13 Oct 2010, Polytropon wrote: Correct. If you disable HAL, and your X is configured to run *WITH* HAL, it won't run anymore. Edit /etc/X11/xorg.conf (and if not present, create it) to make X work *WITHOUT* HAL. How it is to be done is described here: http://www.wonkity.com/~wblock/docs/html/aei.html I've followed only parts of this thread, and there are multiple problems. First is installing X on a server. Second is a KVM switch, many of which are problematic. Next is that the KVM converts USB to PS/2, which... well, maybe it's fine. Finally, a "jumpy mouse" problem with moused on console screams that it's the KVM, not moused or USB or xorg config. My suggestion would be to *not* install X on a server. If it's really required, use an actual keyboard and monitor on that server for those times when ssh -X/-Y aren't enough, and avoid the KVM. If you use a USB mouse, set moused_enable="NO", as the USB subsystem will call moused with the correct settings automatically. USB mice cause moused to be run anyway, but there are differences. If you want switching between X and console to be fast, enable moused. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Label question...why does ufs label vanish on mount?
On Wednesday, October 13, 2010 7:26:30 am Pawel Jakub Dawidek wrote: > On Wed, Oct 13, 2010 at 11:47:41AM +0200, Stefan Bethke wrote: > > Am 13.10.2010 um 10:20 schrieb Pawel Jakub Dawidek: > > > > > On Tue, Oct 12, 2010 at 11:33:11PM -0700, Jeremy Chadwick wrote: > > >> On Wed, Oct 13, 2010 at 08:29:06AM +0200, Stefan Bethke wrote: > > >>> That explains the mechanism, but not the rationale. Or is it just an > > >>> unintended consequence? And how is da2p1 different from ufs/mylabel? (Mount da2p1 and ufs/mylabel is removed, but not the other way around.) > > >> > > >> Pulling in pjd@ who can probably shed some light on this. > > > > > > The ufs/mylabel provider is based on da2p1, that's why opening da2p1 > > > makes ufs/mylabel to be removed and not the other way around. > > > > > > The ufs/mylabel provider was created, because when da2p1 provider was > > > created and LABEL class tasted it, it discovered that this provider > > > contains UFS file system with 'mylabel' volume label, so the LABEL class > > > created ufs/mylabel provider. Now when you open da2p1 for writing, the > > > LABEL class destroys ufs/mylabel, because you may decide to change > > > metadata on da2p1, for example you may choose to destroy UFS in there or > > > change the volume label. When write open count on da2p1 goes down to > > > zero, the LABEL class will be given da2p1 provider for tasting once > > > again, so it can rediscover (possibly modified) volume label. > > > > > > The class may choose to ignore the spoil event from GEOM (it is send on > > > first open for write), but if it isn't based on autodiscovering > > > metadata. For example the NOP class ignores this event, because it > > > doesn't care about metadata of provider it is based on. > > > > > > If we choose to ignore the spoil event in the LABEL class we will end up > > > with stale info, eg. open da2p1 for writing, change its volume label and > > > mount it and you will still have old label in /dev/ufs/. > > > > Thanks a lot (and also to Andrey), that really makes it clear to me! > > > > I just wish there was an easy way to keep the labels around even while > > someone has the provider open for writing, but I now understand that this requires some significant changes. > > The changes aren't significant. We could eventually ignore spoil event > and keep labels around even when underlying provider is opened for > writing risking the label is stale. We could then only update or remove > the label on retaste event (when underlying provider's open write count > goes down to zero). We really should fix this. The current behavior is highly non-intuitive and confusing. For example, if you label a filesystem because you want to switch over to labels, you can't verify that the labels exist in /dev/ufs when you go to edit your fstab (if the filesystems are mounted via existing non-label mounts). > Currently when we do, eg. > > # dd if=/dev/zero of=/dev/da2p1 bs=1m > > This is happening: > > # dd(1) opens da2p1 for writing > # GEOM sends spoil event to all consumers of da2p1 > # LABEL class destroys /dev/ufs/mylabel provider > # dd(1) finishes and closes da2p1 > # GEOM sends taste event to all GEOM classes > # LABEL class finds no metadata and ignores da2p1 > > With the new world order this would look like this: > > # dd(1) opens da2p1 for writing > # GEOM sends spoil event to all consumers of da2p1 > # LABEL class ignores spoil event > # dd(1) finishes and closes da2p1 > # GEOM sends taste event to all GEOM classes > # LABEL class finds no metadata on da2p1 and destroys /dev/ufs/mylabel What happens if you change the label of a filesystem? I suppose in the UFS case we don't let you use tunefs to change the label of a mounted filesystem? Do we have any filesystems where that is the case? If not, I think this approach sounds fine. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: need help with BElkin KVM and USB mouse problems.
I have a USB KVM whose mouse and keyboard work both on the console and in X. My xorg.conf is attached. I am running moused. I am *not* running hald. -Boris On 10/12/10 19:48, Gary Kline wrote: On Tue, Oct 12, 2010 at 10:09:43PM +0200, Stefan Bethke wrote: Am 12.10.2010 um 20:17 schrieb Gary Kline: The USB keyboard works fine everywhere. But my USB mouse fails on the FreeBSD platforms when I try to run X11. I *have* managed to get the mouse working without X [i.e., in console mode]; and yes, the cursor and the buttons work fine. But once I launch X--even simple apps like twm or ctwm, the mouse pointer is dead. It doesn't sound like this issue is connected to your using a KVM at all, but rather your X configuration. If you have a second USB mouse, try plugging that in in addition to the KVM and see if there's any difference; I'm guessing not. Check you X config, and make sure dbus and hald are enabled in rc.conf and started. A friend on -questions suggested that hal might be interfering. I axed it from /etc/rc.conf. Given that both mouse+keyboard are USB, what port should I be using... ? I have tried editing my xorg.conf file. Zip so far. I'll have my wife switch from my "Logitech" to an el-cheapo M$ USB mouse. See if anything happens... thanks, gary Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" Option "AllowEmptyInput" "off" EndSection Section "Files" ModulePath "/usr/local/lib/xorg/modules" FontPath "/usr/local/lib/X11/fonts/misc/" FontPath "/usr/local/lib/X11/fonts/TTF/" FontPath "/usr/local/lib/X11/fonts/OTF" FontPath "/usr/local/lib/X11/fonts/Type1/" FontPath "/usr/local/lib/X11/fonts/100dpi/" FontPath "/usr/local/lib/X11/fonts/75dpi/" EndSection Section "Module" Load "extmod" Load "record" Load "dbe" Load "glx" Load "dri" Load "dri2" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "Dac6Bit" # [] #Option "Dac8Bit" # [] #Option "BusType" # [] #Option "CPPIOMode" # [] #Option "CPusecTimeout" # #Option "AGPMode" # #Option "AGPFastWrite" # [] #Option "AGPSize" # #Option "GARTSize" # #Option "RingSize" # #Option "BufferSize"# #Option "EnableDepthMoves" # [] #Option "EnablePageFlip"# [] #Option "NoBackBuffer" # [] #Option "DMAForXv" # [] #Option "FBTexPercent" # #Option "DepthBits" # #Option "PCIAPERSize" # #Option "AccelDFS" # [] #Option "IgnoreEDID"# [] #Option "DisplayPriority" # [] #Option "PanelSize" # [] #Option "ForceMinDotClock" # #Option "ColorTiling" # [] #Option "VideoKey" # #Option "RageTheatreCrystal"# #Option "RageTheatreTunerPort" # #Option "RageTheatreCompositePort" # #Option "RageTheatreSVideoPort" # #Option "TunerType" # #Option "RageTheatreMicrocPath" # #Option "RageTheatreMicrocType" # #Option "ScalerWidth" # #Option "RenderAccel" # [] #Option "SubPixelOrd
Re: Label question...why does ufs label vanish on mount?
On Wed, Oct 13, 2010 at 11:47:41AM +0200, Stefan Bethke wrote: > Am 13.10.2010 um 10:20 schrieb Pawel Jakub Dawidek: > > > On Tue, Oct 12, 2010 at 11:33:11PM -0700, Jeremy Chadwick wrote: > >> On Wed, Oct 13, 2010 at 08:29:06AM +0200, Stefan Bethke wrote: > >>> That explains the mechanism, but not the rationale. Or is it just an > >>> unintended consequence? And how is da2p1 different from ufs/mylabel? > >>> (Mount da2p1 and ufs/mylabel is removed, but not the other way around.) > >> > >> Pulling in pjd@ who can probably shed some light on this. > > > > The ufs/mylabel provider is based on da2p1, that's why opening da2p1 > > makes ufs/mylabel to be removed and not the other way around. > > > > The ufs/mylabel provider was created, because when da2p1 provider was > > created and LABEL class tasted it, it discovered that this provider > > contains UFS file system with 'mylabel' volume label, so the LABEL class > > created ufs/mylabel provider. Now when you open da2p1 for writing, the > > LABEL class destroys ufs/mylabel, because you may decide to change > > metadata on da2p1, for example you may choose to destroy UFS in there or > > change the volume label. When write open count on da2p1 goes down to > > zero, the LABEL class will be given da2p1 provider for tasting once > > again, so it can rediscover (possibly modified) volume label. > > > > The class may choose to ignore the spoil event from GEOM (it is send on > > first open for write), but if it isn't based on autodiscovering > > metadata. For example the NOP class ignores this event, because it > > doesn't care about metadata of provider it is based on. > > > > If we choose to ignore the spoil event in the LABEL class we will end up > > with stale info, eg. open da2p1 for writing, change its volume label and > > mount it and you will still have old label in /dev/ufs/. > > Thanks a lot (and also to Andrey), that really makes it clear to me! > > I just wish there was an easy way to keep the labels around even while > someone has the provider open for writing, but I now understand that this > requires some significant changes. The changes aren't significant. We could eventually ignore spoil event and keep labels around even when underlying provider is opened for writing risking the label is stale. We could then only update or remove the label on retaste event (when underlying provider's open write count goes down to zero). Currently when we do, eg. # dd if=/dev/zero of=/dev/da2p1 bs=1m This is happening: # dd(1) opens da2p1 for writing # GEOM sends spoil event to all consumers of da2p1 # LABEL class destroys /dev/ufs/mylabel provider # dd(1) finishes and closes da2p1 # GEOM sends taste event to all GEOM classes # LABEL class finds no metadata and ignores da2p1 With the new world order this would look like this: # dd(1) opens da2p1 for writing # GEOM sends spoil event to all consumers of da2p1 # LABEL class ignores spoil event # dd(1) finishes and closes da2p1 # GEOM sends taste event to all GEOM classes # LABEL class finds no metadata on da2p1 and destroys /dev/ufs/mylabel -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpTrU4szvZxZ.pgp Description: PGP signature
Re: Problem with security log
On Wed, Oct 13, 2010 at 11:23 AM, Jeremy Chadwick wrote: > On Wed, Oct 13, 2010 at 11:03:36AM +0200, Marcin wrote: >> 2010/10/13 Jeremy Chadwick : >> > On Tue, Oct 12, 2010 at 10:50:28PM +0200, Marcin wrote: >> >> Hi folks, >> >> >> >> For some time in the file / var / log / security appear illegible entries: >> >> kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 >> >> .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 >> >> >> >> How to get rid of it? Please help... >> > >> > There isn't a 100% reliable way to get rid of this problem. I've been >> > harping about this for years (sorry to sound like a jerk, but this >> > really is a major problem that keeps coming up and annoys users/admins >> > to no end. There are solutions -- Linux solved it by implementing a >> > lockless circular ring buffer[1] used by kmsg). >> > >> > The """workaround""" -- which again, does not solve the problem, only >> > decreases the regularity of it happening (and when it does happen, can >> > sometimes decrease how much interspersed output there is) -- is to add >> > the following line to your kernel config and rebuild/reinstall your >> > kernel: >> > >> > options PRINTF_BUFR_SIZE=128 # Prevent printf output being >> > interspersed. >> > >> > This option became part of the GENERIC kernel configuration file at the >> > following times: >> > >> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/conf/GENERIC#rev1.529 >> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/GENERIC#rev1.517 >> > >> > Depending on what release/tag you follow, you may or may not find the >> > above commit/change in your GENERIC file. I can't be bothered to track >> > down what time the CVS tagging was done, for multiple architectures, >> > etc... >> > >> > [1]: >> > http://www.mjmwired.net/kernel/Documentation/trace/ring-buffer-design.txt >> >> Hi Jeremy, >> I have compiled kernel with this option and unfortunately problem still >> exist... >> Do you have another idea how can i improve my log file? :) > > I was incorrect in my understanding/prognosis, so as Andriy pointed out, > the option won't solve your problem. > > It sounds like the only way to solve this issue is to improve/fix the > msgbuf code. Alternatively, you could consider moving from ipfw to > pf(4) and use pflog(4) / pflogd(8). or you can use the log option of ipfw and run tcpdump on the "ipfw0" pseudo interface which will give you all the traffic that matches a 'log' rule (there is a sysctl variable that controls whether log goes to syslog or to the ipfw pseudo interface) cheers luigi > -- > | Jeremy Chadwick j...@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Label question...why does ufs label vanish on mount?
Am 13.10.2010 um 10:20 schrieb Pawel Jakub Dawidek: > On Tue, Oct 12, 2010 at 11:33:11PM -0700, Jeremy Chadwick wrote: >> On Wed, Oct 13, 2010 at 08:29:06AM +0200, Stefan Bethke wrote: >>> That explains the mechanism, but not the rationale. Or is it just an >>> unintended consequence? And how is da2p1 different from ufs/mylabel? >>> (Mount da2p1 and ufs/mylabel is removed, but not the other way around.) >> >> Pulling in pjd@ who can probably shed some light on this. > > The ufs/mylabel provider is based on da2p1, that's why opening da2p1 > makes ufs/mylabel to be removed and not the other way around. > > The ufs/mylabel provider was created, because when da2p1 provider was > created and LABEL class tasted it, it discovered that this provider > contains UFS file system with 'mylabel' volume label, so the LABEL class > created ufs/mylabel provider. Now when you open da2p1 for writing, the > LABEL class destroys ufs/mylabel, because you may decide to change > metadata on da2p1, for example you may choose to destroy UFS in there or > change the volume label. When write open count on da2p1 goes down to > zero, the LABEL class will be given da2p1 provider for tasting once > again, so it can rediscover (possibly modified) volume label. > > The class may choose to ignore the spoil event from GEOM (it is send on > first open for write), but if it isn't based on autodiscovering > metadata. For example the NOP class ignores this event, because it > doesn't care about metadata of provider it is based on. > > If we choose to ignore the spoil event in the LABEL class we will end up > with stale info, eg. open da2p1 for writing, change its volume label and > mount it and you will still have old label in /dev/ufs/. Thanks a lot (and also to Andrey), that really makes it clear to me! I just wish there was an easy way to keep the labels around even while someone has the provider open for writing, but I now understand that this requires some significant changes. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
2010/10/13 Andriy Gapon : > on 13/10/2010 12:01 Marcin said the following: >> 2010/10/13 Andriy Gapon : >>> on 12/10/2010 23:50 Marcin said the following: Hi folks, For some time in the file / var / log / security appear illegible entries: kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 How to get rid of it? Please help... >>> >>> Add buffering to msgbuf-writing routines in kernel. >>> >>> -- >>> Andriy Gapon >>> ___ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >>> >> >> Hi Andiry, >> How can i do that? Please give me an advice... :) > > http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_prf.c?view=markup > http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_msgbuf.c?view=markup > > Use the source, Luke :) > > -- > Andriy Gapon > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > Hi, Thanks for advice, I don't have enought power (C programmers knowledge) to use the sources... Maybe there is more simply solution... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
On Wed, Oct 13, 2010 at 11:03:36AM +0200, Marcin wrote: > 2010/10/13 Jeremy Chadwick : > > On Tue, Oct 12, 2010 at 10:50:28PM +0200, Marcin wrote: > >> Hi folks, > >> > >> For some time in the file / var / log / security appear illegible entries: > >> kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 > >> .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 > >> > >> How to get rid of it? Please help... > > > > There isn't a 100% reliable way to get rid of this problem. I've been > > harping about this for years (sorry to sound like a jerk, but this > > really is a major problem that keeps coming up and annoys users/admins > > to no end. There are solutions -- Linux solved it by implementing a > > lockless circular ring buffer[1] used by kmsg). > > > > The """workaround""" -- which again, does not solve the problem, only > > decreases the regularity of it happening (and when it does happen, can > > sometimes decrease how much interspersed output there is) -- is to add > > the following line to your kernel config and rebuild/reinstall your > > kernel: > > > > options PRINTF_BUFR_SIZE=128 # Prevent printf output being > > interspersed. > > > > This option became part of the GENERIC kernel configuration file at the > > following times: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/conf/GENERIC#rev1.529 > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/GENERIC#rev1.517 > > > > Depending on what release/tag you follow, you may or may not find the > > above commit/change in your GENERIC file. I can't be bothered to track > > down what time the CVS tagging was done, for multiple architectures, > > etc... > > > > [1]: > > http://www.mjmwired.net/kernel/Documentation/trace/ring-buffer-design.txt > > Hi Jeremy, > I have compiled kernel with this option and unfortunately problem still > exist... > Do you have another idea how can i improve my log file? :) I was incorrect in my understanding/prognosis, so as Andriy pointed out, the option won't solve your problem. It sounds like the only way to solve this issue is to improve/fix the msgbuf code. Alternatively, you could consider moving from ipfw to pf(4) and use pflog(4) / pflogd(8). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
on 13/10/2010 12:01 Marcin said the following: > 2010/10/13 Andriy Gapon : >> on 12/10/2010 23:50 Marcin said the following: >>> Hi folks, >>> >>> For some time in the file / var / log / security appear illegible entries: >>> kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 >>> .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 >>> >>> How to get rid of it? Please help... >> >> Add buffering to msgbuf-writing routines in kernel. >> >> -- >> Andriy Gapon >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > > Hi Andiry, > How can i do that? Please give me an advice... :) http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_prf.c?view=markup http://svn.freebsd.org/viewvc/base/head/sys/kern/subr_msgbuf.c?view=markup Use the source, Luke :) -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
2010/10/13 Jeremy Chadwick : > On Tue, Oct 12, 2010 at 10:50:28PM +0200, Marcin wrote: >> Hi folks, >> >> For some time in the file / var / log / security appear illegible entries: >> kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 >> .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 >> >> How to get rid of it? Please help... > > There isn't a 100% reliable way to get rid of this problem. I've been > harping about this for years (sorry to sound like a jerk, but this > really is a major problem that keeps coming up and annoys users/admins > to no end. There are solutions -- Linux solved it by implementing a > lockless circular ring buffer[1] used by kmsg). > > The """workaround""" -- which again, does not solve the problem, only > decreases the regularity of it happening (and when it does happen, can > sometimes decrease how much interspersed output there is) -- is to add > the following line to your kernel config and rebuild/reinstall your > kernel: > > options PRINTF_BUFR_SIZE=128 # Prevent printf output being > interspersed. > > This option became part of the GENERIC kernel configuration file at the > following times: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/conf/GENERIC#rev1.529 > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/GENERIC#rev1.517 > > Depending on what release/tag you follow, you may or may not find the > above commit/change in your GENERIC file. I can't be bothered to track > down what time the CVS tagging was done, for multiple architectures, > etc... > > [1]: http://www.mjmwired.net/kernel/Documentation/trace/ring-buffer-design.txt > > -- > | Jeremy Chadwick j...@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > Hi Jeremy, I have compiled kernel with this option and unfortunately problem still exist... Do you have another idea how can i improve my log file? :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
2010/10/13 Andriy Gapon : > on 12/10/2010 23:50 Marcin said the following: >> Hi folks, >> >> For some time in the file / var / log / security appear illegible entries: >> kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 >> .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 >> >> How to get rid of it? Please help... > > Add buffering to msgbuf-writing routines in kernel. > > -- > Andriy Gapon > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > Hi Andiry, How can i do that? Please give me an advice... :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Label question...why does ufs label vanish on mount?
On 13.10.2010 10:29, Stefan Bethke wrote: >> When you are opening provider for writing (i.e. mount FS) GEOM(4) >> initiates SPOILING and all consumers that are attached to this provider >> except one will self-destroyed. When you are closing provider GEOM(4) >> initiates TASTING and consumers can return back. Look at man 4 geom >> for details. > > That explains the mechanism, but not the rationale. Or is it just an > unintended consequence? And how is da2p1 different from ufs/mylabel? > (Mount da2p1 and ufs/mylabel is removed, but not the other way around.) This is by design. Any provider's entries in /dev are created by GEOM_DEV class. GEOM_PART serves partition tables. GEOM_PART_GPT as part of GEOM_PART serves GPT. GEOM_PART creates new provider for each entry in GPT. For example: da2 has GPT. da2p1 - first entry in GPT. GEOM_PART creates da2p1 provider and GEOM initiate tasting. GEOM_DEV creates new consumer for da2p1 and /dev/da2p1 entry in devfs. At the same time GEOM_LABEL checks this provider and if it found "labels" it creates new consumer and new provider with name ufs/mylabel via slicer interface. After creating new provider GEOM initiate tasting again. And GEOM_DEV creates new consumer and /dev/ufs/mylabel entry. So, now we have two providers through we can get access to one device. But ufs/mylabel's is on top of da2p1. When we do first open one of them for writing GEOM initiate spoiling for protecting from stale metadata. When we do open da2p1 then GEOM_LABEL receives spoil event and destroys own provider. If I'm wrong Pawel can correct me. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Label question...why does ufs label vanish on mount?
On Tue, Oct 12, 2010 at 11:33:11PM -0700, Jeremy Chadwick wrote: > On Wed, Oct 13, 2010 at 08:29:06AM +0200, Stefan Bethke wrote: > > Am 13.10.2010 um 06:56 schrieb Andrey V. Elsukov: > > > > > On 12.10.2010 22:51, Kevin Oberman wrote: > > >> For some reason the /dev/ufs/label entry that geom creates for every UFS > > >> formatted partition is deleted when the device is mounted. This is not > > >> the case for other file systems, though I have not tried them all. It > > >> makes the drive much harder to deal with when you have to keep track of > > >> which physical drive contains the labeled media. It is a particular > > >> issue for hald and the tools which depend on it. > > >> > > >> Is there a good reason for this odd behavior of UFS? If there is not a > > >> good reason, could it be changed? > > > > > > When you are opening provider for writing (i.e. mount FS) GEOM(4) > > > initiates SPOILING and all consumers that are attached to this provider > > > except one will self-destroyed. When you are closing provider GEOM(4) > > > initiates TASTING and consumers can return back. Look at man 4 geom > > > for details. > > > > That explains the mechanism, but not the rationale. Or is it just an > > unintended consequence? And how is da2p1 different from ufs/mylabel? > > (Mount da2p1 and ufs/mylabel is removed, but not the other way around.) > > Pulling in pjd@ who can probably shed some light on this. The ufs/mylabel provider is based on da2p1, that's why opening da2p1 makes ufs/mylabel to be removed and not the other way around. The ufs/mylabel provider was created, because when da2p1 provider was created and LABEL class tasted it, it discovered that this provider contains UFS file system with 'mylabel' volume label, so the LABEL class created ufs/mylabel provider. Now when you open da2p1 for writing, the LABEL class destroys ufs/mylabel, because you may decide to change metadata on da2p1, for example you may choose to destroy UFS in there or change the volume label. When write open count on da2p1 goes down to zero, the LABEL class will be given da2p1 provider for tasting once again, so it can rediscover (possibly modified) volume label. The class may choose to ignore the spoil event from GEOM (it is send on first open for write), but if it isn't based on autodiscovering metadata. For example the NOP class ignores this event, because it doesn't care about metadata of provider it is based on. If we choose to ignore the spoil event in the LABEL class we will end up with stale info, eg. open da2p1 for writing, change its volume label and mount it and you will still have old label in /dev/ufs/. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpc69f2JFX41.pgp Description: PGP signature
Re: Problem with security log
On Wed, Oct 13, 2010 at 11:24:48AM +0300, Andriy Gapon wrote: > on 13/10/2010 11:17 Jeremy Chadwick said the following: > > The """workaround""" -- which again, does not solve the problem, only > > decreases the regularity of it happening (and when it does happen, can > > sometimes decrease how much interspersed output there is) -- is to add > > the following line to your kernel config and rebuild/reinstall your > > kernel: > > > > options PRINTF_BUFR_SIZE=128# Prevent printf output being > > interspersed. > > This option only affects printing to actual console (e.g. ttyv0). > It changes nothing (zero, nada) for writing to msgbuf, and consequently for > syslogd. Ahhh, I see. Yes you're right, and I'm incorrect (as usual). I thought msgbuf and /dev/console were basically tied together (or maybe I'm thinking of /dev/klog?), but from reviewing dmesg(8) I can see that's obviously not the case (-a flag). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
on 13/10/2010 11:17 Jeremy Chadwick said the following: > The """workaround""" -- which again, does not solve the problem, only > decreases the regularity of it happening (and when it does happen, can > sometimes decrease how much interspersed output there is) -- is to add > the following line to your kernel config and rebuild/reinstall your > kernel: > > options PRINTF_BUFR_SIZE=128# Prevent printf output being > interspersed. This option only affects printing to actual console (e.g. ttyv0). It changes nothing (zero, nada) for writing to msgbuf, and consequently for syslogd. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
On Tue, Oct 12, 2010 at 10:50:28PM +0200, Marcin wrote: > Hi folks, > > For some time in the file / var / log / security appear illegible entries: > kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 > .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 > > How to get rid of it? Please help... There isn't a 100% reliable way to get rid of this problem. I've been harping about this for years (sorry to sound like a jerk, but this really is a major problem that keeps coming up and annoys users/admins to no end. There are solutions -- Linux solved it by implementing a lockless circular ring buffer[1] used by kmsg). The """workaround""" -- which again, does not solve the problem, only decreases the regularity of it happening (and when it does happen, can sometimes decrease how much interspersed output there is) -- is to add the following line to your kernel config and rebuild/reinstall your kernel: options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. This option became part of the GENERIC kernel configuration file at the following times: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/conf/GENERIC#rev1.529 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/conf/GENERIC#rev1.517 Depending on what release/tag you follow, you may or may not find the above commit/change in your GENERIC file. I can't be bothered to track down what time the CVS tagging was done, for multiple architectures, etc... [1]: http://www.mjmwired.net/kernel/Documentation/trace/ring-buffer-design.txt -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
on 12/10/2010 23:50 Marcin said the following: > Hi folks, > > For some time in the file / var / log / security appear illegible entries: > kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 > .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 > > How to get rid of it? Please help... Add buffering to msgbuf-writing routines in kernel. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Label question...why does ufs label vanish on mount?
on 13/10/2010 09:29 Stefan Bethke said the following: > Am 13.10.2010 um 06:56 schrieb Andrey V. Elsukov: >> When you are opening provider for writing (i.e. mount FS) GEOM(4) initiates >> SPOILING and all consumers that are attached to this provider except one >> will self-destroyed. When you are closing provider GEOM(4) initiates >> TASTING and consumers can return back. Look at man 4 geom for details. > > That explains the mechanism, but not the rationale. Or is it just an > unintended consequence? And how is da2p1 different from ufs/mylabel? (Mount > da2p1 and ufs/mylabel is removed, but not the other way around.) da2p1 is a "real" underlying provider, "ufs/mylabel" is a "convenience" provider on _top_ of it. When you open a top-most provider it doesn't affect provides under it. If you open a provider down the chain, then the providers above it are spoiled. Does it make sense now? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problem with security log
On Tue, 12 Oct 2010 22:50:28 +0200, Marcin wrote: Hi folks, For some time in the file / var / log / security appear illegible entries: kernel: ipfw: 200 Deny UDiPp f1w9:2 .168.10.5:5230503 D22e4n.y0 .U0D.P25 1:15923.5136 o8.u10t. 5va5 3r5e03 224.0.0.251:5353 in via re0 How to get rid of it? Please help... Thanks, Nickson Looks like 2 messages scrambled. I think multiple threads are logging/writing at the same time. Although that might be a bug in itself it can explain what you see. Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: / full (107% !!)
Morning, On Wed, Oct 13, 2010 at 01:50:31PM +1100, Jeff Dowsley wrote: > Just did a csup and rebuilt world and kernel, as usual. > Rebooted to single user mode, and kicked off the installkernel. > This bombed with an "unable to write to device", and "device full". > On rebooting, df shows / at 107%. You might want to set INSTALL_NODEBUG=yes in /etc/make.conf HTH, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
