headers
Sean McNeil | 1 Dec 2004 03:23

panic today when doing shutdown and boot warnings

I haven't noticed these before so I thought I would mention them:

Nov 30 18:01:39 server kernel: Timecounters tick every 1.000 msec
Nov 30 18:01:39 server kernel: WARNING: attempt to net_add_domain(local) after domainfinalize()
Nov 30 18:01:39 server kernel: WARNING: attempt to net_add_domain(internet6) after domainfinalize()
Nov 30 18:01:39 server kernel: WARNING: attempt to net_add_domain(route) after domainfinalize()
Nov 30 18:01:39 server kernel: WARNING: attempt to net_add_domain(internet) after domainfinalize()

I have no idea what they mean.

Plus, with an amd64 kernel compiled just a little while ago I get a drop
into the debugger on shutdown:

I typed "reboot"...

Nov 30 17:56:55 server reboot: rebooted by root
Nov 30 18:01:39 server syslogd: kernel boot file is /boot/kernel/kernel
Nov 30 18:01:39 server kernel: interrupt                   total
Nov 30 18:01:39 server kernel: irq1: atkbd0                         826
Nov 30 18:01:39 server kernel: irq0: clk                        3441687
Nov 30 18:01:39 server kernel: irq4: sio0                             6
Nov 30 18:01:39 server kernel: irq8: rtc                         220405
Nov 30 18:01:39 server kernel: irq14: ata0                       162189
Nov 30 18:01:39 server kernel: irq15: ata1                          172
Nov 30 18:01:39 server kernel: irq16: re0                         42589
Nov 30 18:01:39 server kernel: irq17: fwohci0                         1
Nov 30 18:01:39 server kernel: irq19: dc0                             2
Nov 30 18:01:39 server kernel: irq20: atapci0                    121462
Nov 30 18:01:39 server kernel: irq21: uhci0 uhci1+                  379
Nov 30 18:01:39 server kernel: Total                     3989718
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pawel Worach | 1 Dec 2004 03:27
Picon

page fault panic in device_get_softc/acpi_pcib_route_interrupt

Got this during boot on an IBM x345, three hour old kernel.
Last working kernel is from 5 days ago, later than that hangs
after probing the mpt controller (don't have the details on
that now since this happened while I was about the debug the
mpt issue).

Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
pcib0: <ACPI Host-PCI bridge> on acpi0
pci0: <ACPI PCI bus> on pcib0

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x48
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc051b827
stack pointer           = 0x10:0xc08208f4
frame pointer           = 0x10:0xc08209f8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 0 (swapper)
[thread pid 0 tid 0 ]
Stopped at      device_get_softc+0x7:   movl    0x48(%eax),%eax
db> tr
Tracing pid 0 tid 0 td 0xc06e4080
device_get_softc(0,0,c0820a28,c0820a3c,2) at device_get_softc+0x7
acpi_pcib_route_interrupt(c1f17d00,c1f8b780,1,c1f7f1d4,1) at
(Continue reading)

Permalink | Reply | 0 comments |
headers
animecowboy | 1 Dec 2004 05:12

smbfs and setuid in 5.3

I am running 5.3r11 and I am having difficulty with mount_smbfs.  Basically I
have a permissions problem that I cannot track down.  The remote filesystem
mounts correctly, and as root I can view and write to it correctly.  The
permissions to the base directory were originally 700, and sued to the owner of
the base I cannot stat the directory.  

I have tried changing the owner to another user, but had the same effect.  After
trying a few things I set the permissions to 750, and I could view and stat the
directory.  So I think it is some kind of UID bit not getting set correctly. 
The GID seems to set correctly, and for the moment is being used for a work
around.

I have mounted this filesystem on a FreeBSD 4.10(almost identical kernel) with
no problem using the 700 permission settings. So I'm fairly certain its not the
remote server, but just in case, the remote is a win2k pro machine.

Thank you.
-Brian Bailey

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Permalink | Reply | 3 comments |
headers
Kris Kennaway | 1 Dec 2004 05:42

panic: Lock ACPI PCI link not exclusively locked

Rebuilt 6.0 kernel tonight, panics at boot:

pci_link0: <ACPI PCI Link LNKB> irq 6 on acpi0
panic: Lock ACPI PCI link not exclusively locked  <at>  /a/portbuild/i386/src-client/sys/dev/acpica/acpi_pci_link.c:153

KDB: enter: panic
[thread pid 0 tid 0 ]
Stopped at      kdb_enter+0x32: leal    0(%esi),%esi
db>
db> tr
Tracing pid 0 tid 0 td 0xc07b8260
kdb_enter(c07551c4,c07ba540,c07558db,c0c20a7c,c07b8260) at kdb_enter+0x32
panic(c07558db,c0740d53,c0740d88,99,c0c20b00) at panic+0x14d
_sx_assert(c07b4a60,4,c0740d88,99,c1a2e9c0) at _sx_assert+0xfe
link_add_crs(c1a2e9c0,c0c20b00,c0c20ac8,2c,c1a2e9c0) at link_add_crs+0x35
AcpiWalkResources(c1950900,c073db16,c047e620,c0c20b00,c195c980) at AcpiWalkResources+0x8d
acpi_pci_link_attach(c1a28380,c19bd04c,c077a96c,c0756dc5,0) at acpi_pci_link_attach+0x251
device_attach(c1a28380,c0475100,c0c20b78,c0c20b80,0) at device_attach+0x2c9
prt_attach_devices(c1a08800,c195c400,c195c980,c195c400,c1a0f994) at prt_attach_devices+0xe6
prt_walk_table(c195c400,c0771297,0,c0c20bcc,0) at
prt_walk_table+0x3c
acpi_pcib_attach(c195c400,c1a0f994,0,c0c20c04,c0473fb7,c0764021,c1945970,c077a96c,c19494a0)
at acpi_pcib_attach+0xe4
acpi_pcib_acpi_attach(c195c400,c19b104c,c077a96c,c0756dc5,0) at acpi_pcib_acpi_attach+0xf9
device_attach(c195c400,1fefffff,c0c20cbc,c0476474,c195c980) at device_attach+0x2c9
bus_generic_attach(c195c980,100000,1fefffff,c1a0f9e8,100000) at bus_generic_attach+0x18
acpi_attach(c195c980,c19ca04c,c077a96c,c0756dc5,0) at acpi_attach+0x7b4
device_attach(c195c980,c195ca00,c0c20d18,c070d6da,c195ca00) at device_attach+0x2c9
bus_generic_attach(c195ca00,c195ca4c,c0c20d54,c0574679,c195ca00) at bus_generic_attach+0x18
nexus_attach(c195ca00,c19e084c,c077a96c,c0756dc5,0) at nexus_attach+0x1a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kenneth D. Merry | 1 Dec 2004 05:42
Picon
Favicon

Re: -current hang during boot on SMP machine

[ resend from the address that is actually subscribed to -current ]
On Tue, Nov 30, 2004 at 08:12:29 -0500, Andrew Gallatin wrote:
> 
> Have you tried disabling ACPI via hint.acpi.0.disabled="1" in
> /boot/loader.conf
> 
> The ACPI on these older machines is pretty bad.  I have a very similar
> SuperMicro machine w/o SCSI at work which runs 5.3-R fine w/ACPI
> disabled.  I discovered early in the 5.0 cycle that enabling ACPI
> would lead to a console message for each fxp0 interrupt..

That seems to get it working, thanks!  It looks like all the devices are
probed properly without ACPI.  Will I be missing anything important with
ACPI disabled?

Ken
--

-- 
Kenneth Merry
ken <at> FreeBSD.org
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
JINMEI Tatuya / 神明達哉 | 1 Dec 2004 06:19
Picon

malloc(0) returns an invalid address

On FreeBSD 5.3 Release (for i386), malloc(3) seems to return an
invalid pointer, while the man page says:

     V       Attempting to allocate zero bytes will return a NULL pointer
             instead of a valid pointer.  (The default behavior is to make a
             minimal allocation and return a pointer to it.)  This option is
             provided for System V compatibility.  This option is incompatible
             with the ``X'' option.

In fact, if you compile the following code,

#include <stdlib.h>
#include <stdio.h>

main()
{
	char *p = malloc(0);

	printf("address of p is %p\n", p);
	*p = 0;			/* XXX */
}

the result of the execution would be as follows:

% ./a.out
address of p is 0x800
zsh: 794 segmentation fault (core dumped)  ./a.out

Is this a malloc bug?  Or is this the intended behavior and the man
page description is old?
(Continue reading)

Permalink | Reply | 9 comments |
headers
Nate Lawson | 1 Dec 2004 06:40

Re: panic: Lock ACPI PCI link not exclusively locked

Kris Kennaway wrote:
> Rebuilt 6.0 kernel tonight, panics at boot:
> 
> pci_link0: <ACPI PCI Link LNKB> irq 6 on acpi0
> panic: Lock ACPI PCI link not exclusively locked  <at>  /a/portbuild/i386/src-client/sys/dev/acpica/acpi_pci_link.c:153
> 
> KDB: enter: panic
> [thread pid 0 tid 0 ]
> Stopped at      kdb_enter+0x32: leal    0(%esi),%esi
> db>
> db> tr
> Tracing pid 0 tid 0 td 0xc07b8260
> kdb_enter(c07551c4,c07ba540,c07558db,c0c20a7c,c07b8260) at kdb_enter+0x32
> panic(c07558db,c0740d53,c0740d88,99,c0c20b00) at panic+0x14d
> _sx_assert(c07b4a60,4,c0740d88,99,c1a2e9c0) at _sx_assert+0xfe
> link_add_crs(c1a2e9c0,c0c20b00,c0c20ac8,2c,c1a2e9c0) at link_add_crs+0x35
> AcpiWalkResources(c1950900,c073db16,c047e620,c0c20b00,c195c980) at AcpiWalkResources+0x8d
> acpi_pci_link_attach(c1a28380,c19bd04c,c077a96c,c0756dc5,0) at acpi_pci_link_attach+0x251
> device_attach(c1a28380,c0475100,c0c20b78,c0c20b80,0) at device_attach+0x2c9
> prt_attach_devices(c1a08800,c195c400,c195c980,c195c400,c1a0f994) at prt_attach_devices+0xe6
> prt_walk_table(c195c400,c0771297,0,c0c20bcc,0) at prt_walk_table+0x3c
>
acpi_pcib_attach(c195c400,c1a0f994,0,c0c20c04,c0473fb7,c0764021,c1945970,c077a96c,c19494a0)
at acpi_pcib_attach+0xe4
> acpi_pcib_acpi_attach(c195c400,c19b104c,c077a96c,c0756dc5,0) at acpi_pcib_acpi_attach+0xf9
> device_attach(c195c400,1fefffff,c0c20cbc,c0476474,c195c980) at device_attach+0x2c9
> bus_generic_attach(c195c980,100000,1fefffff,c1a0f9e8,100000) at bus_generic_attach+0x18
> acpi_attach(c195c980,c19ca04c,c077a96c,c0756dc5,0) at acpi_attach+0x7b4
> device_attach(c195c980,c195ca00,c0c20d18,c070d6da,c195ca00) at device_attach+0x2c9
> bus_generic_attach(c195ca00,c195ca4c,c0c20d54,c0574679,c195ca00) at bus_generic_attach+0x18
(Continue reading)

Permalink | Reply | 0 comments |
headers
NAKATA Maho | 1 Dec 2004 06:39
Picon

Re: REPORT_KEY ILLEGAL REQUEST: encrypted DVD's under FreeBSD?

In Message-ID: <20040923032045.GA52428 <at> crodrigues.org> 
Craig Rodrigues <rodrigc <at> crodrigues.org> wrote:

Hello,

> I tried installing mplayer, xine, and ogle from ports to play
> DVD's on my FreeBSD-CURRENT box.  All these packages use libdvdcss.
> 
> For some reason, when playing certain encrypted DVD's, things
> fail.  I am seeing a lot of messages like this in my dmesg:
> 
> acd0: FAILURE - REPORT_KEY ILLEGAL REQUEST asc=0x6f ascq=0x04 error=4<ABORTED>
> 
> This is my brand of DVD player:
> acd0: <LITE-ON DVDRW LDW-811S/HS06> CDRW drive at ata0 as slave

I also encountered the exact problem.
acd0: DVDR <MATSHITADVD-RAM UJ-812/K103> at ata1-master UDMA33
-- NAKATA, Maho

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Permalink | Reply | 5 comments |
headers
David Schwartz | 1 Dec 2004 06:40
Favicon
Gravatar

RE: malloc(0) returns an invalid address


> In fact, if you compile the following code,
>
> #include <stdlib.h>
> #include <stdio.h>
>
> main()
> {
> 	char *p = malloc(0);
>
> 	printf("address of p is %p\n", p);
> 	*p = 0;			/* XXX */
> }
>
> the result of the execution would be as follows:
>
> % ./a.out
> address of p is 0x800
> zsh: 794 segmentation fault (core dumped)  ./a.out
>
> Is this a malloc bug?  Or is this the intended behavior and the man
> page description is old?

	This is the intended behavior but the man page description is correct. The
problem is not that the pointer is invalid but that you assumed that it was
large enough to hold a 'char' and it is not.

	DS

_______________________________________________
(Continue reading)

Permalink | Reply | 8 comments |
headers
Daniel O'Connor | 1 Dec 2004 07:30
Picon
Favicon

Re: REPORT_KEY ILLEGAL REQUEST: encrypted DVD's under FreeBSD?

On Wed, 1 Dec 2004 16:09, NAKATA Maho wrote:
> > This is my brand of DVD player:
> > acd0: <LITE-ON DVDRW LDW-811S/HS06> CDRW drive at ata0 as slave
>
> I also encountered the exact problem.
> acd0: DVDR <MATSHITADVD-RAM UJ-812/K103> at ata1-master UDMA33

Does it actually _play_ after this or not?
It could be searching for a key (maybe)

--

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Permalink | Reply | 0 comments |

Gmane