similar to: [Bug 478] New: Kernel panic - not syncing: Aiee, killing interrupt handler!

I''m experimenting with xen + iscsi, and I founded that under heavy stress domU''s can crash entire system, I''ve reproduced this many many times. My system is like this Software: - iSCSI Enterprise Target v0.4.13 - RedHat AS4 update 4 64bit + Xen 3.0.3-0 Kernel 2.6.16.29 + Open iSCSI v2.0.730 (Initiator) - Bonnie++ v1.03a VM: - Debian 3.1r3 + Open iSCSI v2.0.730

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=478 ------- Additional Comments From kaber@trash.net 2006-05-22 09:32 MET ------- The exact same problem was reported on LKML, also with 2.6.16.13 and Xen. Since we've had no reports of similar problems without Xen, I doubt that the problem really is within the netfilter code, especially since we haven't had any problems in that

Hi everybody ! I'll try to explain first what I would like to do with the functionalities of tap and bridge interfaces, qemu, some isos(I used slax(slackware live cd)) and the forwarding mechanisms of the Linux kernel. I'd like to simulate such a network: Internet | (eth0:@public address) * host * | br0 (@192.168.0.254)

On 10/13/2014 12:50 AM, Michael S. Tsirkin wrote: > virtio spec 0.9.X requires DRIVER_OK to be set before > VQs are used, but some drivers use VQs before probe > function returns. > Since DRIVER_OK is set after probe, this violates the spec. > > Even though under virtio 1.0 transitional devices support this > behaviour, we want to make it possible for those early callers to

Hi, after I saw that my machine was having problems to forward more than 200 Mbit/s, I decided to profile the kernel and find out the hotspots. This is what I found: [...] 1028 bridge.ko __br_forward 1033 bridge.ko br_nf_forward_finish 1074 bridge.ko ip_sabotage_in 1119 ebtable_filter.ko ebt_hook 1177 sky2.ko

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=42 Summary: Kernel panic in PSD Product: netfilter/iptables Version: patch-o-matic Platform: i386 OS/Version: other Status: NEW Severity: major Priority: P2 Component: ip_tables (kernel) AssignedTo: laforge@netfilter.org

http://bugzilla.mindrot.org/show_bug.cgi?id=478 Summary: add search function to website Product: Portable OpenSSH Version: older versions Platform: All URL: http://ant.apache.org OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Documentation AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=478 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From djm at mindrot.org 2003-02-24 13:28

Well, it has been a long saga over here trying to get a TDM400P to work with an Intel D845HV motherboard, and the towel is close to being thrown in. Does anyone know of a (few) motherboards that work well with the TDM400P and are socket 478? --Brent

Hi, all : Today my laptop shows the following messages during booting: udevb[478]: add_to_rules: unknown key 'ATTRS{idProduct}' udevb[478]: add_to_rules: unknown key 'ATTRS{idVendor}' ..... ..... .... These many lines are repeated over and over filling the whole screen. But after a few seconds booting continues as usual and the system works fine. But what is it with this

Full_Name: Thomas Hoffmann Version: 1.0.0 OS: OS/2 Warp 4.0 FP 11 Submission from: (NULL) (141.30.125.20) I autoconfigured/configured the src'es w/o having XDR (#undef HAVE_RPC_XDR_H). In saveload.c , at the beginning of the file the XDR code is enclosed by matching #ifdefs. But in the NEW_SAVE_FORMAT section, there are no #ifdefs around the XDR code. Does this imply that using the new

http://bugzilla.netfilter.org/show_bug.cgi?id=714 Summary: Kernel panics in same_src() Product: netfilter/iptables Version: linux-2.6.x Platform: x86_64 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: NAT AssignedTo: netfilter-buglog at lists.netfilter.org ReportedBy:

virtio spec 0.9.X requires DRIVER_OK to be set before VQs are used, but some drivers use VQs before probe function returns. Since DRIVER_OK is set after probe, this violates the spec. Even though under virtio 1.0 transitional devices support this behaviour, we want to make it possible for those early callers to become spec compliant and eventually support non-transitional devices. Add API for

virtio spec 0.9.X requires DRIVER_OK to be set before VQs are used, but some drivers use VQs before probe function returns. Since DRIVER_OK is set after probe, this violates the spec. Even though under virtio 1.0 transitional devices support this behaviour, we want to make it possible for those early callers to become spec compliant and eventually support non-transitional devices. Add API for

Changes from v4: rename virtio_enable_vqs_early() to virtio_device_ready() Note: Rusty requested we add a BUG_ON in the virtio_ring code. This can be done by a separate patch on top. Good for bisectability in case BUG_ON starts triggering :) Rusty, please review this, and consider for this merge window. This fixes the following virtio spec compliance issues: 1. on restore, drivers use device

Changes from v4: rename virtio_enable_vqs_early() to virtio_device_ready() Note: Rusty requested we add a BUG_ON in the virtio_ring code. This can be done by a separate patch on top. Good for bisectability in case BUG_ON starts triggering :) Rusty, please review this, and consider for this merge window. This fixes the following virtio spec compliance issues: 1. on restore, drivers use device