Make cron supply valid RFC822 From: and To: headers
Since I switched to SMTPD I noticed a few cron emails being marked as
spam by spamassassin, largely caused by the From: and To: headers not
containing a domain part.
If I read RFC822 correctly, the domain part is not optional, and thus
we should append one, unless MAILTO already specifies one.
Historical reasons from the land of pre-smtp why I'm wrong?
Comments?
OK's?
/Alexander
(Indentation style sucks balls in there. I kept it up.)
Index: do_command.c
===
RCS file: /data/openbsd/cvs/src/usr.sbin/cron/do_command.c,v
retrieving revision 1.36
diff -u -p -r1.36 do_command.c
--- do_command.c22 Aug 2011 19:32:42 - 1.36
+++ do_command.c13 Nov 2012 09:48:53 -
@@ -412,8 +412,13 @@ child_process(entry *e, user *u) {
perror(mailcmd);
(void) _exit(EXIT_FAILURE);
}
- fprintf(mail, From: root (Cron Daemon)\n);
- fprintf(mail, To: %s\n, mailto);
+ fprintf(mail, From: root@%s (Cron Daemon)\n,
+ hostname);
+ if (strchr(mailto, '@') == NULL)
+ fprintf(mail, To: %s@%s\n, mailto,
+ hostname);
+ else
+ fprintf(mail, To: %s\n, mailto);
fprintf(mail, Subject: Cron %s@%s %s\n,
usernm, first_word(hostname, .),
e-cmd);
Re: agp(4): agpmmap fix
Date: Tue, 13 Nov 2012 11:55:07 +0100
From: Martin Pieuchot mpieuc...@nolizard.org
After loosing some hairs trying to figure out where I screw up in
mmaping the AGP aperture, here's a trivial fix.
Diff below corrects the first argument of the agpmmap() function that
should be a dev_t and not a pointer to the driver's descriptor.
ok kettenis@ if you fix the spaces vs. tab issue.
Index: agp.c
===
RCS file: /cvs/src/sys/dev/pci/agp.c,v
retrieving revision 1.34
diff -u -p -r1.34 agp.c
--- agp.c 26 Dec 2010 15:41:00 - 1.34
+++ agp.c 12 Nov 2012 18:20:48 -
@@ -60,7 +60,7 @@ int agp_generic_free_memory(struct agp_s
void agp_attach(struct device *, struct device *, void *);
int agp_probe(struct device *, void *, void *);
int agpbusprint(void *, const char *);
-paddr_t agpmmap(void *, off_t, int);
+paddr_t agpmmap(dev_t, off_t, int);
int agpioctl(dev_t, u_long, caddr_t, int, struct proc *);
int agpopen(dev_t, int, int, struct proc *);
int agpclose(dev_t, int, int , struct proc *);
@@ -206,9 +206,12 @@ struct cfdriver agp_cd = {
};
paddr_t
-agpmmap(void *v, off_t off, int prot)
+agpmmap(dev_t dev, off_t off, int prot)
{
- struct agp_softc* sc = (struct agp_softc *)v;
+ struct agp_softc *sc = agp_find_device(AGPUNIT(dev));
+
+if (sc == NULL || sc-sc_chipc == NULL)
+return (-1);
if (sc-sc_apaddr) {
agp(4): release unbinded memory
While experimenting with the agp(4) interface I found that if you
release the interface (AGPIOC_RELEASE) before closing its file
descriptor you'll end up with allocated but unbinded memory blocks.
This behavior is due to the fact that the agp_release_helper() function
doesn't free the memory associated to each block and this is incoherent
with what it says it does:
/*
* Clear out the aperture and free any
* outstanding memory blocks.
*/
...
So the diff below correct this by freeing all the memory block when
releasing the interface, this is what happens currently if you close
the file descriptor without releasing the interface.
However it doesn't change the behavior of the interface that looks
busted to me because we don't keep track of who allocated some memory
block and end up unbindind and freeing everything.
Ok?
Index: agp.c
===
RCS file: /cvs/src/sys/dev/pci/agp.c,v
retrieving revision 1.34
diff -u -p -r1.34 agp.c
--- agp.c 26 Dec 2010 15:41:00 - 1.34
+++ agp.c 12 Nov 2012 18:20:48 -
@@ -290,20 +310,13 @@ int
agpclose(dev_t dev, int flags, int devtype, struct proc *p)
{
struct agp_softc *sc = agp_find_device(AGPUNIT(dev));
- struct agp_memory *mem;
/*
* Clear the GATT and force release on last close
*/
- if (sc-sc_state == AGP_ACQUIRE_USER) {
- while ((mem = TAILQ_FIRST(sc-sc_memory)) != 0) {
- if (mem-am_is_bound) {
- agp_unbind_memory(sc, mem);
- }
- agp_free_memory(sc, mem);
- }
+ if (sc-sc_state == AGP_ACQUIRE_USER)
agp_release_helper(sc, AGP_ACQUIRE_USER);
- }
+
sc-sc_opened = 0;
return (0);
@@ -658,25 +671,26 @@ int
agp_release_helper(void *dev, enum agp_acquire_state state)
{
struct agp_softc *sc = (struct agp_softc *)dev;
- struct agp_memory* mem;
+ struct agp_memory *mem, *tmp;
if (sc-sc_state == AGP_ACQUIRE_FREE)
return (0);
- if (sc-sc_state != state)
+ if (sc-sc_state != state)
return (EBUSY);
/*
* Clear out the aperture and free any
* outstanding memory blocks.
*/
- TAILQ_FOREACH(mem, sc-sc_memory, am_link) {
+ TAILQ_FOREACH_SAFE(mem, sc-sc_memory, am_link, tmp) {
if (mem-am_is_bound) {
- printf(agp_release_helper: mem %d is bound\n,
- mem-am_id);
+ AGP_DPF(mem %d is bound\n, mem-am_id);
agp_unbind_memory(sc, mem);
}
+ agp_free_memory(sc, mem);
}
+
sc-sc_state = AGP_ACQUIRE_FREE;
return (0);
}
Re: agp(4): release unbinded memory
Date: Tue, 13 Nov 2012 12:30:29 +0100 From: Martin Pieuchot mpieuc...@nolizard.org While experimenting with the agp(4) interface I found that if you release the interface (AGPIOC_RELEASE) before closing its file descriptor you'll end up with allocated but unbinded memory blocks. That behaviour is documented in agp(4). So if we change it, we should change the documentation as well. That said, the documentation also says that the AGPIOC_RELEASE ioctl doesn't unbind any allocated memory. And that doesn't seem to be true. This behavior is due to the fact that the agp_release_helper() function doesn't free the memory associated to each block and this is incoherent with what it says it does: /* * Clear out the aperture and free any * outstanding memory blocks. */ ... So the diff below correct this by freeing all the memory block when releasing the interface, this is what happens currently if you close the file descriptor without releasing the interface. I;m not sure this is right. I think the idea here is that an application could release control to hand things over to drm, and later reacquire control. The comment in xenocara/xserver/hw/xfree86/os-support/bsd/bsd_agp.c:xf86ReleaseGART() suggests that this behaviour is desired.
Re: Make cron supply valid RFC822 From: and To: headers
On 11/13/12 13:49, Christian Weisgerber wrote: Alexander Hall alexan...@beard.se wrote: Since I switched to SMTPD I noticed a few cron emails being marked as spam by spamassassin, largely caused by the From: and To: headers not containing a domain part. If I read RFC822 correctly, the domain part is not optional, and thus we should append one, unless MAILTO already specifies one. This looks like a problem in smtpd. Sendmail and compatible MTAs have always fully qualified any incomplete addresses. Ok, no matter how we parse the rfc's, since old sendmail and friends rewrites those headers, I guess it's already a de-facto standard, in practice forcing us to make smtpd do it too. In the meantime, would the diff hurt anyone? Or is it just a lousy workaround? /Alexander
Re: Make cron supply valid RFC822 From: and To: headers
On Tue, Nov 13, 2012 at 03:14:06PM +0100, Alexander Hall wrote: On 11/13/12 13:49, Christian Weisgerber wrote: Alexander Hall alexan...@beard.se wrote: Since I switched to SMTPD I noticed a few cron emails being marked as spam by spamassassin, largely caused by the From: and To: headers not containing a domain part. If I read RFC822 correctly, the domain part is not optional, and thus we should append one, unless MAILTO already specifies one. This looks like a problem in smtpd. Sendmail and compatible MTAs have always fully qualified any incomplete addresses. Ok, no matter how we parse the rfc's, since old sendmail and friends rewrites those headers, I guess it's already a de-facto standard, in practice forcing us to make smtpd do it too. In the meantime, would the diff hurt anyone? Or is it just a lousy workaround? /Alexander I believe sendmail has options to add a specific domain to unqualified names. I think you want the sendmail (like) mechanism here, not a specific one for cron only. -Otto
Re: agp(4): release unbinded memory
On 13/11/12(Tue) 13:45, Mark Kettenis wrote:
Date: Tue, 13 Nov 2012 12:30:29 +0100
From: Martin Pieuchot mpieuc...@nolizard.org
While experimenting with the agp(4) interface I found that if you
release the interface (AGPIOC_RELEASE) before closing its file
descriptor you'll end up with allocated but unbinded memory blocks.
That behaviour is documented in agp(4). So if we change it, we should
change the documentation as well. That said, the documentation also
says that the AGPIOC_RELEASE ioctl doesn't unbind any allocated
memory. And that doesn't seem to be true.
This behavior is due to the fact that the agp_release_helper() function
doesn't free the memory associated to each block and this is incoherent
with what it says it does:
/*
* Clear out the aperture and free any
* outstanding memory blocks.
*/
...
So the diff below correct this by freeing all the memory block when
releasing the interface, this is what happens currently if you close
the file descriptor without releasing the interface.
I;m not sure this is right. I think the idea here is that an
application could release control to hand things over to drm, and
later reacquire control. The comment in
xenocara/xserver/hw/xfree86/os-support/bsd/bsd_agp.c:xf86ReleaseGART()
suggests that this behaviour is desired.
Fair enough, so here's a diff that removes the chunk of code unbinding
the memory block from the release routine. This makes the code match
what the manual says.
Ok?
Index: agp.c
===
RCS file: /cvs/src/sys/dev/pci/agp.c,v
retrieving revision 1.34
diff -u -p -r1.34 agp.c
--- agp.c 26 Dec 2010 15:41:00 - 1.34
+++ agp.c 13 Nov 2012 13:41:43 -
@@ -658,25 +678,13 @@ int
agp_release_helper(void *dev, enum agp_acquire_state state)
{
struct agp_softc *sc = (struct agp_softc *)dev;
- struct agp_memory* mem;
if (sc-sc_state == AGP_ACQUIRE_FREE)
return (0);
- if (sc-sc_state != state)
+ if (sc-sc_state != state)
return (EBUSY);
- /*
-* Clear out the aperture and free any
-* outstanding memory blocks.
-*/
- TAILQ_FOREACH(mem, sc-sc_memory, am_link) {
- if (mem-am_is_bound) {
- printf(agp_release_helper: mem %d is bound\n,
- mem-am_id);
- agp_unbind_memory(sc, mem);
- }
- }
sc-sc_state = AGP_ACQUIRE_FREE;
return (0);
}
Re: agp(4): release unbinded memory
Date: Tue, 13 Nov 2012 16:15:59 +0100
From: Martin Pieuchot mpieuc...@nolizard.org
On 13/11/12(Tue) 13:45, Mark Kettenis wrote:
Date: Tue, 13 Nov 2012 12:30:29 +0100
From: Martin Pieuchot mpieuc...@nolizard.org
While experimenting with the agp(4) interface I found that if you
release the interface (AGPIOC_RELEASE) before closing its file
descriptor you'll end up with allocated but unbinded memory blocks.
That behaviour is documented in agp(4). So if we change it, we should
change the documentation as well. That said, the documentation also
says that the AGPIOC_RELEASE ioctl doesn't unbind any allocated
memory. And that doesn't seem to be true.
This behavior is due to the fact that the agp_release_helper() function
doesn't free the memory associated to each block and this is incoherent
with what it says it does:
/*
* Clear out the aperture and free any
* outstanding memory blocks.
*/
...
So the diff below correct this by freeing all the memory block when
releasing the interface, this is what happens currently if you close
the file descriptor without releasing the interface.
I;m not sure this is right. I think the idea here is that an
application could release control to hand things over to drm, and
later reacquire control. The comment in
xenocara/xserver/hw/xfree86/os-support/bsd/bsd_agp.c:xf86ReleaseGART()
suggests that this behaviour is desired.
Fair enough, so here's a diff that removes the chunk of code unbinding
the memory block from the release routine. This makes the code match
what the manual says.
Ok?
Hmm, I think it currently pretty much a bug if a process calls
AGPIOC_RELEASE while it still has stuff bound to the aperture as we
don't restore the bindings when we resume. So I think we should keep
the printf's and perhaps keep unbinding the memory as well. I'm not
sure how much damage stale mappings can do during a suspend/resume
cycle.
It seems that the xf86-video-intel driver is the only userland code
that actually uses /dev/agp (through the xserver interfaces). And
because of the FreeBSD hack I mentioned in my previous mail, I don't
think it actually ever invokes the AGPIOC_RELEASE ioctl after it
starts using the GART. It's a great bloody mess :(. But fortunately
that usage goes away as soon as we implement KMS.
Index: agp.c
===
RCS file: /cvs/src/sys/dev/pci/agp.c,v
retrieving revision 1.34
diff -u -p -r1.34 agp.c
--- agp.c 26 Dec 2010 15:41:00 - 1.34
+++ agp.c 13 Nov 2012 13:41:43 -
@@ -658,25 +678,13 @@ int
agp_release_helper(void *dev, enum agp_acquire_state state)
{
struct agp_softc *sc = (struct agp_softc *)dev;
- struct agp_memory* mem;
if (sc-sc_state == AGP_ACQUIRE_FREE)
return (0);
- if (sc-sc_state != state)
+ if (sc-sc_state != state)
return (EBUSY);
- /*
- * Clear out the aperture and free any
- * outstanding memory blocks.
- */
- TAILQ_FOREACH(mem, sc-sc_memory, am_link) {
- if (mem-am_is_bound) {
- printf(agp_release_helper: mem %d is bound\n,
- mem-am_id);
- agp_unbind_memory(sc, mem);
- }
- }
sc-sc_state = AGP_ACQUIRE_FREE;
return (0);
}
usr.bin/mail: use F_OK instead of 0 in access()
hi, use F_OK macro instead of 0 in access() when cheching by file existence. make de code easier to read. no funcional change. OK ? Index: cmd2.c === RCS file: /cvs/src/usr.bin/mail/cmd2.c,v retrieving revision 1.18 diff -u -p -r1.18 cmd2.c --- cmd2.c 6 Apr 2011 11:36:26 - 1.18 +++ cmd2.c 13 Nov 2012 18:54:35 - @@ -166,7 +166,7 @@ save1(char *str, int mark, char *cmd, st return(1); printf(\%s\ , file); fflush(stdout); - if (access(file, 0) = 0) + if (access(file, F_OK) = 0) disp = [Appended]; else disp = [New file];
Re: Major dhclient(8) changes - no more dhclient-script
2012/11/9 Kenneth R Westerback kwesterb...@rogers.com Those of you following -current or running very recent snaps may have noticed a lot of changes to dhclient in the last couple of weeks. Aside from some major clean up, these changes revolve around the elimination of the dhclient-script as both detrimental to sanity and our ability to move forward to better network configuration automation. So far a couple of uses for dhclient-script have been reported and workarounds have to be developed for these scenarios. But now that most of the changes are committed we are very interested in making sure that scenarios that lead people to modify dhclient-script are identified sooner rather than later. So please test the new dhclient(8) in as many situations as possible and report both 'noraml' bugs/regressions and problems you have not been able to solve without dhclient-script. Thanks. Ken Is it possible to ignore route pushed by the server ? -- - () ascii ribbon campaign - against html e-mail /\
Re: add intel 6235 support to iwn(4)
I was actually able to add support myself with the following diff.
--
James Turner
ja...@calminferno.net
Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.115
diff -u -p if_iwn.c
--- if_iwn.c11 Nov 2012 20:45:31 - 1.115
+++ if_iwn.c14 Nov 2012 02:00:52 -
@@ -639,7 +639,8 @@ iwn5000_attach(struct iwn_softc *sc, pci_product_id_t
break;
case IWN_HW_REV_TYPE_6005:
sc-limits = iwn6000_sensitivity_limits;
- if (pid == PCI_PRODUCT_INTEL_WL_6235_1) {
+ if (pid == PCI_PRODUCT_INTEL_WL_6235_1 ||
+ pid == PCI_PRODUCT_INTEL_WL_6030_2) {
sc-fwname = iwn-6030;
/* XXX: The 6235 generates a fatal firmware error when
Re: add intel 6235 support to iwn(4)
This fixes iwn(4) for me too. Where previously I would get iwn0:
fatal firmware error I now get a working setup with:
iwn0 at pci1 dev 0 function 0 Intel Centrino Advanced-N 6030 rev 0x34: msi,
MIMO 2T2R, MoW, address 88:53:2e:d9:dd:9d
Full dmesg (including a boot with the previous kernel and the error I
got) included at the end of this mail.
Thanks Joshua and James, that fixes one of the remaining issues on my
laptop. This e-mail sent via that iwn(4) ;)
Paul 'WEiRD' de Weerd
On Tue, Nov 13, 2012 at 09:02:24PM -0500, James Turner wrote:
| I was actually able to add support myself with the following diff.
|
| --
| James Turner
| ja...@calminferno.net
| Index: if_iwn.c
| ===
| RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
| retrieving revision 1.115
| diff -u -p if_iwn.c
| --- if_iwn.c 11 Nov 2012 20:45:31 - 1.115
| +++ if_iwn.c 14 Nov 2012 02:00:52 -
| @@ -639,7 +639,8 @@ iwn5000_attach(struct iwn_softc *sc, pci_product_id_t
| break;
| case IWN_HW_REV_TYPE_6005:
| sc-limits = iwn6000_sensitivity_limits;
| - if (pid == PCI_PRODUCT_INTEL_WL_6235_1) {
| + if (pid == PCI_PRODUCT_INTEL_WL_6235_1 ||
| + pid == PCI_PRODUCT_INTEL_WL_6030_2) {
| sc-fwname = iwn-6030;
|
| /* XXX: The 6235 generates a fatal firmware error when
|
OpenBSD 5.2-current (GENERIC.MP) #0: Sun Nov 11 22:19:14 CET 2012
we...@banana.alm.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8501063680 (8107MB)
avail mem = 8252280832 (7869MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe6020 (18 entries)
bios0: vendor INSYDE version R1010H5 date 07/28/2011
bios0: Sony Corporation VPCZ23C5E
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA ASF! HPET APIC MCFG SLIC WDAT SSDT BOOT SSDT ASPT
SSDT SSDT SSDT SSDT
acpi0: wakeup devices EHC1(S3) EHC2(S3) HDEF(S0) WLAN(S0) RP01(S0) RMSC(S0)
RP02(S0) NXUC(S3) RP03(S3) RLAN(S3) RP04(S3) RP07(S3) PEG0(S0) PEGP(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2794.10 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2793.66 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2793.66 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2793.66 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC
cpu3: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus 3 (RP02)
acpiprt3 at acpi0: bus 4 (RP03)
acpiprt4 at acpi0: bus 5 (RP04)
acpiprt5 at acpi0: bus 8 (RP07)
acpiprt6 at acpi0: bus -1 (PEG0)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpitz0 at acpi0: critical temperature is 98 degC
acpibat0 at acpi0: BAT1 type Lion oem Sony Corporation
acpibat1 at acpi0: BAT2 type Lion oem Sony Corporation
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpidock0 at acpi0: DOCK not docked (0)
acpivideo0 at acpi0: DD01
acpivideo1 at acpi0: DD02
acpivideo2 at acpi0: DD03
acpivideo3 at acpi0: DD04
acpivideo4 at acpi0: DD05
acpivideo5 at acpi0: DD06
acpivideo6 at acpi0: DD07
acpivideo7 at acpi0: DD08
acpivideo8 at acpi0: GFX0
acpivout0 at acpivideo8: DD02
cpu0: Enhanced SpeedStep 2794 MHz:
