Mutui cambializzati
Mutuo Ipotecario cambializzato anche in seconda ipoteca ( finalit`) Mutuo anche per segnalati in banche dati Acquisto casa Per acquistare la 1* o la 2* casa con un mutuo estremamente vantaggioso. Ristrutturazione Per ristrutturare casa con un mutuo fino all'80% del valore dell'immobile. Completamento costruzione Per completare la costruzione di una casa gi` accatastata. Liquidit` Per ottenere liquidit` da utilizzare per qualsiasi finalit`. Sostituzione + Liquidit` Per sostituire il tuo mutuo e richiedere liquidit` aggiuntiva. Anche per segnalati in banche dati
Sony linea W
Sony DSC-W320 USD 201,40 Sony DSC-W330 USD 210,94 Sony DSC-W350 USD 245
Re: A tiny feature for mg(1): beginning-of-line
Overloading goto-bol is a terrible idea. If it's really desirable, it should become a function (back-to-indentation), and get bound go M-m... On Wed, Oct 6, 2010 at 5:43 AM, Jasper Lievisse Adriaanse jas...@humppa.nlwrote: On Wed, Oct 06, 2010 at 11:37:39AM +, Christian Weisgerber wrote: Jasper Lievisse Adriaanse jas...@humppa.nl wrote: Would this be OK with anyone? -Move cursor to the beginning of the line. +Move cursor to the beginning of the line. Calling this function again moves +the cursor to the first non-whitespace character of the line. That's not the way emacs behaves and mg is supposed to be finger-compatible with emacs. -- Christian naddy Weisgerber na...@mips.inka.de Actually, Ingo forwarded me some mails from Kjell about this and that it subtly breaks c-mode.. So it can't go in as is. -- Cheers, Jasper Stay Hungry. Stay Foolish.
4.8-current, tcpdump pflog, unaligned libpcap packets
Synopsis: 4.8-current, tcpdump on pflog with the latest snapshot problems
Category: system, library
Environment:
System : OpenBSD 4.8
Details : OpenBSD 4.8-current (GENERIC) #271: Mon Oct 4 12:19:02
MDT 2010
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
Architecture: OpenBSD.amd64
Machine : amd64
Description:
This problem comes up in 4.8-current snapshot from 2010.10.04 and the
-current from CVS dated 2010.10.06. When performing tcpdump on pflog0
the output complains about unaligned packets and does not decode the
packets properly. Please see the output below. It appears to be that
'bad-ip-version' in the output below usually changes based on the
size of the packets.
The interface that generated entries in the pflog does not seem to
matter as well. The problem was reproduced successfully on em, bge
and re interfaces. This problem also appears on VMs and real hardware.
However, if performing tcpdump on the actual interface (not pflog0)
everything works as expected and the packets are properly decoded.
CVS checkout from 2010.08.02 works as expected.
-
# tcpdump -i pflog0 -venlt
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
tcpdump: WARNING: compensating for unaligned libpcap packets
rule 2/(match) [uid 0, pid 28096] block in on em0: bad-ip-version 5
rule 2/(match) [uid 0, pid 28096] block in on em0: bad-ip-version 5
rule 2/(match) [uid 0, pid 28096] block in on em0: bad-ip-version 5
rule 2/(match) [uid 0, pid 28096] block out on em0: bad-ip-version 1
rule 2/(match) [uid 0, pid 28096] block in on em0: bad-ip-version 5
rule 2/(match) [uid 0, pid 28096] block out on em0: bad-hlen 20
rule 2/(match) [uid 0, pid 28096] block out on em0: bad-ip-version 0
rule 2/(match) [uid 0, pid 28096] block out on em0: bad-ip-version 3
^C
8 packets received by filter
0 packets dropped by kernel
-
How-To-Repeat:
1) use a simple pf.conf like the one below
2) run 'tcpdump -i pflog0 -venlt'
3) ping the host
-
# cat /etc/pf.conf
ctrl_if = em0
set block-policy return
set skip on { lo0 }
match in all scrub (no-df)
block quick inet6 all
block log all
pass on $ctrl_if proto tcp from any to any port ssh
-
Fix:
None at the moment, CVS checkout from 2010.08.02 works as expected.
dmesg:
OpenBSD 4.8-current (GENERIC) #271: Mon Oct 4 12:19:02 MDT 2010
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 535756800 (510MB)
avail mem = 507650048 (484MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (5 entries)
bios0: vendor innotek GmbH version VirtualBox date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2964.71 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,MWAIT,SSSE3,NXE,LONG
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: apic clock running at 999MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
acpibat0 at acpi0: BAT0 not present
acpiac0 at acpi0: AC unit online
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 82441FX rev 0x02
pcib0 at pci0 dev 1 function 0 Intel 82371SB ISA rev 0x00
pciide0 at pci0 dev 1 function 1 Intel 82371AB IDE rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
wd0 at pciide0 channel 0 drive 0: VBOX HARDDISK
wd0: 128-sector PIO, LBA, 32768MB, 67108864 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: VBOX, CD-ROM, 1.0 ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
vga1 at pci0 dev 2 function 0 InnoTek VirtualBox Graphics Adapter rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 Intel PRO/1000MT (82540EM) rev 0x02:
apic 1 int 19 (irq 10), address 08:00:27:ed:64:54
InnoTek
Los mejores modelos de Notebooks están aca!
[IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] En caso de no querer recibir mas este correo por favor presione AQUI .
Re: update pms driver
On Wed, Oct 06, 2010 at 11:40:45PM -0400, Ian Darwin wrote: Also found a new bug: wsmoused + X don't work (suspend/resume) 1) wsmoused 2) startx 3) suspend/resume 4) in X mouse don't work 5) suspend/resume 6) in X mouse work Urm, I did say I'd test it later today, and I did so - just after the diff got committed :-( So, I just updated pms.c to the committed version and built a kernel. Fortunately, as reported in my earlier test, I do not have the above problems on the Dell Studio 1558 laptop. However, in the process of this testing, I found two problems, one related and one maybe related. Both have to do with running two X sessions one after another. 1) (might or might not be related to pms) When I terminate X and try to re-start it (either under XDM or by running sudo startx twice), the second X does not always start - it tries, but it hangs just after the basket weave background and the X cursor, before any apps or the XDM login screen. Other times it works fine. Since restarting X is not something I normally do (I'm usually the only user of this machine, and I usually either suspend or power it off when not using), I cannot say if this started when the pms/pmsi merger went in. The last time I can be sure that I had several X's in a row without rebooting is Sept 20, according to last(1). So I can try triaging (actually we're bisecting, not triaging, when we do this :-) ) on the weekend when I am home and have a cvsync repo to build multiple kernels against, and time to do so. 2) (probably related to pms) With wsmoused running, the second X session (as above) fails to get /dev/wsmouse. Sadly I captured the wrong Xorg.log on this one so I'll have to replicate, but I'm out of time for tonight. this error does not pms driver, but failure mechanism is similar to one that I found. At first I will finish with pms, and then take over these problems. I think the objection would not be? :) This machine is Intel core i7, amd64 mode, and running -current (userland + X updated earlier today to Oct 6 userland, Oct 3 X snapshot). BIOS is up to date. Dmesg below; longer dmesg with ACPI_DEBUG, and acpidump, on request. More later, sorry... Ian -- Alexandr Shadchin
Re: update pms driver
On Wed, Oct 06, 2010 at 09:53:47PM -0400, Kenneth R Westerback wrote:
Committed. Next? :-)
Ken
Removed unnecessary code, as the same thing does pms_change_state() when
the device enters a state of PMS_STATE_ENABLED
--
Alexandr Shadchin
Index: pms.c
===
RCS file: /cvs/src/sys/dev/pckbc/pms.c,v
retrieving revision 1.8
diff -u -p -r1.8 pms.c
--- pms.c 7 Oct 2010 01:52:25 - 1.8
+++ pms.c 7 Oct 2010 18:46:59 -
@@ -167,29 +167,11 @@ pmsattach(parent, self, aux)
struct pms_softc *sc = (void *)self;
struct pckbc_attach_args *pa = aux;
struct wsmousedev_attach_args a;
- u_char cmd[1], resp[2];
- int res;
sc-sc_kbctag = pa-pa_tag;
sc-sc_kbcslot = pa-pa_slot;
printf(\n);
-
- /* Flush any garbage. */
- pckbc_flush(pa-pa_tag, pa-pa_slot);
-
- /* reset the device */
- cmd[0] = PMS_RESET;
- res = pckbc_poll_cmd(pa-pa_tag, pa-pa_slot, cmd, 1, 2, resp, 1);
-#ifdef DEBUG
- if (res || resp[0] != PMS_RSTDONE || resp[1] != 0) {
- printf(pmsattach: reset error\n);
- return;
- }
-#endif
-
- sc-inputstate = 0;
- sc-oldbuttons = 0;
pckbc_set_inputhandler(sc-sc_kbctag, sc-sc_kbcslot,
pmsinput, sc, sc-sc_dev.dv_xname);
Re: OpenCVS - new RCS parser
On Wed, Oct 06, 2010 at 04:27:44PM +0200, Maurizio Boriani wrote: I've successfully parsed a cvs repo of about 196000 files and obtained the same (good) result with old opencvs, patched opencvs and gnu cvs Thank you for testing, good feedback is even better than bugreports. :) I have improved rcsparse.c in some more areas: - comment @@; and expand @@; are optional, set it to OPTIONAL. - added dummy support for commitid ...;, reported by Joerg Sonnenberger for OpenCVS and it was in for OpenRCS already. - rewrote switch() into more readable if() statement. - plugged a memory leak - adjusted some comments And best part: - generalized rcsparse enough to get it into OpenRCS and OpenCVS with only two lines diff (cvs_vlog instead of vwarnx and its include)! Our trees (ports, src, www, xenocara) work fine as of today, 10:00 o'clock. I don't want to put these two diffs (57K/~2500 lines each) in this mail, please download here: http://www.stoeckmann.org/opencvs-rcsparse.diff http://www.stoeckmann.org/openrcs-rcsparse.diff You can also download an OpenCVS export of mine. I have used it to identify any possible differences between current and new parser. It parses a supplied RCS file fully with current and new parser and compares the data structures in memory. If you see ANY output, PLEASE send me the RCS file! Usage: opencvs /path/to/RCS/file,v http://www.stoeckmann.org/cvs.tar.gz With kind regards, Tobias Stoeckmann
Re: 4.8-current, tcpdump pflog, unaligned libpcap packets
On 2010/10/07 14:30, Peter Bisroev wrote: This problem comes up in 4.8-current snapshot from 2010.10.04 and the -current from CVS dated 2010.10.06. When performing tcpdump on pflog0 the output complains about unaligned packets and does not decode the packets properly. Please see the output below. It appears to be that 'bad-ip-version' in the output below usually changes based on the size of the packets. Are your kernel and tcpdump in sync?
Re: update pms driver
1) (might or might not be related to pms) When I terminate X and try to re-start it (either under XDM or by running sudo startx twice), the second X does not always start - it tries, but it hangs just after the basket weave background and the X cursor, before any apps or the XDM login screen. Other times it works fine. Since restarting X is not something I normally do (I'm usually the only user of this machine, and I usually either suspend or power it off when not using), I cannot say if this started when the pms/pmsi merger went in. The last time I can be sure that I had several X's in a row without rebooting is Sept 20, according to last(1). So I can try triaging (actually we're bisecting, not triaging, when we do this :-) ) on the weekend when I am home and have a cvsync repo to build multiple kernels against, and time to do so. 2) (probably related to pms) With wsmoused running, the second X session (as above) fails to get /dev/wsmouse. Sadly I captured the wrong Xorg.log on this one so I'll have to replicate, but I'm out of time for tonight. this error does not pms driver, but failure mechanism is similar to one that I found. At first I will finish with pms, and then take over these problems. I think the objection would not be? :) I really doubt if anyone would object to your fixing problems! :-) Thanks for your contributions. Keep at it! Ian
Re: more assertwaitok() love
On Thu, Sep 30, 2010 at 12:29:54AM +, Thordur Bjornsson wrote:
Hi.
Try to catch more places where we sleep and are not allowed.
One thing of note, msleep() is missing in this diff, but there
it is needed to call to sleep_setup routines with the mutex
held, and after we release it we _will_ sleep so a sleep there
with another mutex held will be caught by the assertwaitok()
in mi_switch().
Also, define assertwaitok() out for !DIAGNOSTIC kernels.
Comments/OKs?
Index: kern/kern_rwlock.c
===
RCS file: /home/cvs/src/sys/kern/kern_rwlock.c,v
retrieving revision 1.16
diff -u -p -r1.16 kern_rwlock.c
--- kern/kern_rwlock.c24 Sep 2010 13:21:30 - 1.16
+++ kern/kern_rwlock.c30 Sep 2010 00:12:12 -
@@ -87,6 +87,8 @@ rw_enter_read(struct rwlock *rwl)
{
unsigned long owner = rwl-rwl_owner;
+ assertwaitok();
+
if (__predict_false((owner RWLOCK_WRLOCK) ||
rw_cas(rwl-rwl_owner, owner, owner + RWLOCK_READ_INCR)))
rw_enter(rwl, RW_READ);
@@ -97,6 +99,8 @@ rw_enter_write(struct rwlock *rwl)
{
struct proc *p = curproc;
+ assertwaitok();
+
if (__predict_false(rw_cas(rwl-rwl_owner, 0,
RW_PROC(p) | RWLOCK_WRLOCK)))
rw_enter(rwl, RW_WRITE);
These two are fine
@@ -190,6 +194,9 @@ rw_enter(struct rwlock *rwl, int flags)
struct sleep_state sls;
unsigned long inc, o;
int error;
+
+ if (!(flags RW_NOSLEEP))
+ assertwaitok();
Suppose this is ok (for interlocking with mutexen), still need to be in
process context, though.
op = rw_ops[flags RW_OPMASK];
Index: kern/kern_synch.c
===
RCS file: /home/cvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.95
diff -u -p -r1.95 kern_synch.c
--- kern/kern_synch.c 29 Jun 2010 00:28:14 - 1.95
+++ kern/kern_synch.c 29 Sep 2010 21:55:58 -
@@ -121,6 +121,8 @@ tsleep(const volatile void *ident, int p
return (0);
}
+ assertwaitok();
+
sleep_setup(sls, ident, priority, wmesg);
sleep_setup_timeout(sls, timo);
sleep_setup_signal(sls, priority);
Index: kern/subr_pool.c
===
RCS file: /home/cvs/src/sys/kern/subr_pool.c,v
retrieving revision 1.98
diff -u -p -r1.98 subr_pool.c
--- kern/subr_pool.c 26 Sep 2010 21:03:57 - 1.98
+++ kern/subr_pool.c 30 Sep 2010 00:03:15 -
@@ -455,10 +455,8 @@ pool_get(struct pool *pp, int flags)
KASSERT(flags (PR_WAITOK | PR_NOWAIT));
-#ifdef DIAGNOSTIC
if ((flags PR_WAITOK) != 0)
assertwaitok();
-#endif /* DIAGNOSTIC */
mtx_enter(pp-pr_mtx);
v = pool_do_get(pp, flags);
Index: kern/subr_xxx.c
===
RCS file: /home/cvs/src/sys/kern/subr_xxx.c,v
retrieving revision 1.12
diff -u -p -r1.12 subr_xxx.c
--- kern/subr_xxx.c 28 Sep 2010 20:27:56 - 1.12
+++ kern/subr_xxx.c 29 Sep 2010 21:55:03 -
@@ -156,13 +156,15 @@ blktochr(dev_t dev)
/*
* Check that we're in a context where it's okay to sleep.
*/
+
+#ifdef DIAGNOSTIC
void
assertwaitok(void)
{
splassert(IPL_NONE);
-#ifdef DIAGNOSTIC
+
if (curcpu()-ci_mutex_level != 0)
panic(assertwaitok: non-zero mutex count: %d,
curcpu()-ci_mutex_level);
-#endif
}
+#endif
Index: sys/systm.h
===
RCS file: /home/cvs/src/sys/sys/systm.h,v
retrieving revision 1.86
diff -u -p -r1.86 systm.h
--- sys/systm.h 21 Sep 2010 01:09:10 - 1.86
+++ sys/systm.h 30 Sep 2010 00:02:51 -
@@ -179,7 +179,11 @@ void ttyprintf(struct tty *, const char
void splassert_fail(int, int, const char *);
extern int splassert_ctl;
+#ifdef DIAGNOSTIC
void assertwaitok(void);
+#else
+#define assertwaitok() do { /* nothing */ } while (0)
+#endif
void tablefull(const char *);
I'm ok with this.
-0-
--
It is better never to have been born. But who among us has such luck?
One in a million, perhaps.
Re: more assertwaitok() love
On Wed, Oct 6, 2010 at 12:41 PM, Thordur Bjornsson t...@openbsd.org wrote: No one wants to OK/comment on this besides matthew@ ? It looked good on review and I've been running with it for a while without problems, so theory and practice seem to line up. ok guenther
